Archivo de la categoría: Desarrollo de Sistemas
Modelo Orientado a Objetos – James Martin
Modelando el mundo real
Cuando se analizan sistemas se crean modelos del área de la aplicación en cuestión. El modelo representa un aspecto del mundo real y se construye de modo que ayude a comprender a éste. El modelo debe ser mucho más sencillo que la realidad, es una abstracción de ésta, se puede lidiar con el modelo, cosa en muchas situaciones no sería posible hacer en el mundo real.
En el análisis orientado a objetos se modela en el mundo real en términos de tipos de objetos y lo que les ocurre a éstos, la forma de construir sistemas:
- El análisis crea un modelo en el dominio de la aplicación.
- El modelo se convierte en un diseño
- El diseño se convierte en código.
El modelo debe representar la forma en que los usuarios finales perciben el área de dominio en cuestión, en la medida de lo posible el modelo debe ser presentado de forma que sea comprensible para los usuarios finales.
Los modelos construidos en el análisis orientado a objetos reflejan la entidad del mundo real de forma más natural que en el análisis tradicional de sistemas, ya que el mundo está formado por objetos y eventos que cambian el estado de dichos objetos. Utilizando las técnicas orientadas a objetos, se construye software que modela el mundo real de manera más fiel, entonces, cuando el mundo real cambia, el software es más fácil de cambiar, lo que representa una verdadera ventaja.
Modelo Orientado a Objetos
Este Modelo para el desarrollo de Software es mejor conocido como Modelo RAD (Rapid Application Development) o Desarrollo Rápido de Aplicaciones, y fue creado por James Martin en 1991. Está orientado a disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas de Información, el RAD cuenta con una participación intensa del usuario, sesiones JAD, prototipaje, herramientas CASE integradas y generadores de código. El RAD requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y herramientas.
Este Modelo consta de 4 etapas
- Etapa de Planificación de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compañía determinen cuáles serán las funciones del sistema. Debe darse una discusión estructurada sobre los problemas de la compañía que necesitan solución.
- Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la compañía en relación al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informática. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el análisis se crean los diagramas que definen las alteraciones entre los procesos y la data.
- Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseño y la construcción del sistema. La construcción de la aplicación consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.
- Implementación: Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.
Ventajas de su aplicación en organizaciones
- Ahorro dramático de tiempo durante el desarrollo del sistema. Mayor velocidad y menores costos pueden repercutir en la calidad del sistema (p.e., debido a falta de atención en controles internos).
- Permite cambiar rápidamente el diseño de los sistemas cuando los usuarios lo demandan
- Poca diferencia entre los requerimientos del usuario y las especificaciones del sistema.
- Une a los usuarios y a los diseñadores. Permite proporcionar una descripción completa del problema, legible y revisable por las partes interesadas y verificables contra la realidad.
- Utiliza el diagrama orientado a objetos como representación gráfica del sistema.
Referencias
Consultados el día 20 de mayo de 2016 de la WWW:
- http://mundoinformatico321.blogspot.com/2012/12/metodologia-de-james-martin-y-uml.html
- http://indalics.com/consultoria-informatica-paradigma-del-software-orientado-a-objetos
- http://www.itlalaguna.edu.mx/
- https://lcorientadoaobjetos.wordpress.com/
XP – Kent Beck
La programación extrema o extreme programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.
¿Qué es?
Siguiendo el mismo orden de ideas, es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios, XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
Objetivos
Por otra parte los objetivos son:
- Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos.
- Mejorar la productividad de los proyectos.
- Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente,
Contexto
En relación al contexto está:
- cliente bien definido;
- los requisitos pueden (y van a) cambiar;
- grupo pequeño y muy integrado (máximo 12 personas);
- equipo con formación elevada y capacidad de aprender.
Características
Sus principales características son: Metodología basada en prueba y error; fundamentada en valores y prácticas; expresada en forma de 12 prácticas; conjunto completo; se soportan unas a otras; son conocidas desde hace tiempo. La novedad es juntarlas. Ahora bien el estilo XP está orientado hacia quien produce y usa el software, reduce el costo del cambio en todas las etapas del ciclo de vida del sistema, Combina las que han demostrado ser las mejores prácticas para desarrollar software, y las lleva al extremo.
Prácticas básicas
Es importante destacar que para que todo esto funcione, la programación extrema se basa en doce «prácticas básicas» que deben seguirse al pie de la letra:
- Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.
- Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente.
- Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
- Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando.
- Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.
- Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
- Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.
- Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.
- El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.
- Normas de codificación: Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.
- Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el «recolector de basura» de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.
- Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión.
Ventajas y Desventajas
Para finalizar sus principales ventajas son:
- Programación organizada.
- Menor tasa de errores.
- Satisfacción del programador
Sus desventajas:
- Es recomendable emplearlo solo en proyectos a corto plazo.
- Altas comisiones en caso de fallar.
Referencias
Consultados el día 21 de Mayo de 2016 de la WWW:
- https://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema
- http://blogs.unellez.edu.ve/dsilva/files/2014/07/Metodologia-XP.pdf
- http://ingenieriadesoftware.mex.tl/52753_XP—Extreme-Programing.html
Modelo RUP – IBM
Modelo RUP
El Proceso Racional Unificado de o RUP (de sus siglas en inglés Rational Unified Process), es una metodología desarrollo de software que consiste en suministrar un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo. El objetivo es garantizar la producción de software de alta calidad, cumpliendo con las necesidades de los usuarios. Trabaja, mancomunadamente con el Lenguaje Unificado de Modelado (UML), y se constituye como la metodología estándar más utilizada para analizar, diseñar, implementar y documentar de sistemas orientados a objetos.
Características del Modelo RUP
El RUP es un producto de Rational (IBM), con un enfoque orientado a objetos que se caracteriza por ser iterativo e incremental, manejando una serie de entregas ejecutables e integrando constantemente la arquitectura para una evolución continua del mismo, produciendo versiones mejoradas. Asimismo, se centra en la arquitectura para conceptualizar, construir y gestionar el sistema que se está desarrollando.
Otras de sus características son:
- Es conceptualmente amplio y diverso.
- Busca implementar las mejores prácticas en Ingeniería de Software.
- Maneja una forma disciplinada de asignar tareas y responsabilidades.
- Permite mediciones, tales como: Estimación de costos y tiempo, nivel de avance, entre otras.
- Está dirigido por Casos de Uso, permitiendo establecer el comportamiento deseado del sistema.
Principios de Desarrollo RUP
Para el desarrollo de RUP existen seis (6) principios clave que son:
- Adaptación del proceso,
- Balancear prioridades,
- Colaboración entre equipos,
- Demostrar valor iterativamente,
- Elevar el nivel de abstracción y por último pero no menos importante,
- Enfocarse en la calidad.
Ciclo de Vida y Fases del Modelo RUP
El ciclo de vida RUP se desarrolla en forma secuencial (en espiral), y al concluir cada fase se verifica con una evaluación si se cumplieron los objetivos de la misma, o no. Se divide en cuatro (4) fases en las que a su vez se realizan iteraciones (el número varía) según el proyecto que sea. Estas fases son:
Inicio: consiste en especificar y delimitar los objetivos del proyecto y su alcance con las partes interesadas, describir los riesgos relacionados al mismo y asegurar que el proyecto sea viable, dando un enfoque general de la arquitectura de software.
Elaboración: se establece la arquitectura base del sistema para brindar una plataforma segura, se definen los casos de uso escogidos para ello, teniendo en consideración los aspectos de mayor relevancia y se realiza una evaluación de riesgo.
Construcción: la finalidad de esta fase es culminar con la funcionalidad del sistema, esclareciendo las dudas que puedan existir, verificando que se cumplan los requerimientos pendientes, todo en función de la arquitectura base definida previamente.
Transición o Cierre: el propósito de esta fase es garantizar la disponibilidad del software para los usuarios finales, hacer cambios menores solicitados por el usuario, depurar el producto en relación a los errores encontrados en las pruebas, brindar la capacitación concerniente a los usuarios y verificar que el producto final cumpla con los requerimientos entregados por las partes interesadas.
¿A quién va dirigido el Modelo RUP?
Va dirigido principalmente a Profesionales en el desarrollo y/o administración de procesos de software y personas con interés en productos de software.
Referencias
Consultado el día 28 de mayo de 2016 de la WWW:
- https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
- http://metodologiadesoftware.blogspot.com/2012/11/fases-del-modelo-rup_27.html
- https://softwarerecopilation.wordpress.com/modelo-rup/
Ciclo de Vida de James Senn
Las metodologías utilizadas para la generación de productos informáticos y de sistemas, presentan ventajas a través del dinamismo y flexibilidad de las mismas para la corrección de errores en los productos a lo largo de su aplicación, a su vez son estrategias que facilitan a los desarrolladores el establecimiento de una propuesta basada en las necesidades de los clientes; es común que en las empresas se utilicen las propuestas de autores del área para dar respuesta a las necesidades de los clientes.
Todas las metodologías existentes, así como la que se presenta, se basan en la metodología clásica o en cascada, en Venezuela se enseñan, en los recintos universitarios y centros de educación especializada, propuestas por diversos autores, teniendo como principales lo sugerido por James Senn y a Kendall & Kendall. Por otra parte, se presentan, en algunos recintos, las metodologías de Jonás Montilva y de Juan Lloréns Fabregás, como parte de las propuestas hechas para el desarrollo de productos informáticos.
Sin embargo, lo que normalmente se hace es presentar las metodologías para que el analista ponga en práctica la que más le sea conveniente, tomando elementos de cada una de ellas; esto se debe a que en una organización o empresa, el análisis y diseño de sistemas de información incluye el estudio de la situación de dicho sistema, con la finalidad de observar cómo trabaja y a partir de ello decidir si es necesaria una mejora; el encargado de llevar a cabo esta acción es el analista de sistemas quien determina todos los aspectos de la situación actual de la empresa y levanta la información que sirve de base para la formulación de distintas estrategias de diseño.
A continuación se presenta la Metodología para el Análisis, desarrollo y diseño de Sistemas de Información propuesta por el autor James Senn, producto de esa recopilación y de su experiencia.
Dicho autor expresa que un sistema como tal, se conoce como un todo unitario y organizado de procesos, procedimientos, tareas y métodos a nivel de tecnología y recursos humanos interdependientes, con los cuales una organización alcanza un objetivo organizado con el fin de generar información histórica actual y proyecciones futuras inclusive; por lo cual se plantea su desarrollo a través de seis fases funcionales:
- Investigación preliminar,
- determinación de requerimientos,
- diseño del sistema,
- desarrollo del sistema,
- pruebas del sistema, e
- implantación.
A su vez, plantea que existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tienen un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada. Estas estrategias ofrecen una serie de características que son importantes destacar:
- Se define el sistema como un medio organizado de proporcionar información pasada, presente y hasta futura (proyecciones) relacionada con las operaciones internas y el conocimiento externo de la organización
- Se establece que el sistema sigue una estructura bien organizada y claramente planteada con el fin de emitir y generar información histórica, actual y proyecciones futuras inclusive, todo esto con la espina vertebral de las operaciones llevadas a cabo por la organización.
- El sistema se considera como un todo unitario y organizado de procesos, procedimientos, tareas, métodos y recursos materiales, tecnológicos y humanos interdependientes, de que se vale una organización para alcanzar un objetivo, y es fácilmente identificable por los límites de su medio ambiente.
Referencias
- https://sisteminformacii.wikispaces.com/METODOLOG%C3%8DA+DE+JAMES+SENN?responseToken=0aeb43cc12d0ee5af6fe04fbab69a9273
- http://iset2.blogspot.com/2015/08/analisis-y-diseno-de-sistemas-de.html
- http://metodologiaysistema.blogspot.com/2013/01/metodologia-de-james-senn-parte-i.html
- http://catalogo.econo.unlp.edu.ar/meran/opac-detail.pl?id1=2056
Ciclo de Vida de Desarrollo de Sistemas – Kendall & Kendall
Kenneth E. Kendall es un distinguido profesor de Management en la Escuela de Negocios-Camden, la Universidad de Rutgers. Él es uno de los fundadores de la Conferencia Internacional sobre Sistemas de Información (ICIS) y miembro del Instituto de Ciencias de la Decisión (DSI). Kendall ha sido nombrado como uno de los 60 mejores investigadores de MIS más productivos del mundo, y fue galardonado con la base de plata de IFIP. Kendall ha publicado más de 90 artículos de investigación. Se desempeñó como Presidente del Programa para ambos (Conferencia de las Américas sobre Sistemas de Información) DSI y AMCIS. Recientemente ha participado como co-autor de un texto, Análisis de Sistemas y Diseño, octava edición, publicado por Prentice Hall y Planificación de Proyectos y Análisis de Requerimientos de Sistemas de Información para el Desarrollo. Se ha desempeñado como editor asociado de Ciencias de la Decisión y el Diario de Gestión de Recursos de Información. La investigación del profesor Kendall se centra en el estudio de empujar y tirar las tecnologías, las estrategias de comercio electrónico y el desarrollo de nuevas herramientas para el análisis y diseño de sistemas.
Julie E. Kendall fue honrada como miembro del Círculo inaugural de Compadres para el Proyecto de doctorado iniciado por la Fundación KPMG, que ayuda a los estudiantes de doctorado de las minorías. Ella co-editó el volumen humano, organizacional, y las dimensiones sociales de los Sistemas de Información para el Desarrollo. Los intereses de la enseñanza de la Dra. Julie Kendall incluyen cuestiones estratégicas globales en el comercio electrónico y el análisis y el diseño para el comercio electrónico y los sistemas de información tradicionales sistemas. Julie se desempeñó como miembro del Consejo Asesor del Centro de Excelencia en la Enseñanza, la Universidad de Rutgers-Camden, de 1992 a 2003. Julie recibió un Premio de Ciencias de la Decisión Instituto de Innovación Docente en 1992.
“El ciclo de vida del desarrollo de sistemas (SDLC, Systems Development Life Cycle) es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario.” (Kendall & Kendall).
Según esta metodología el ciclo de vida de un Sistema creada por estos dos autores consta de siete partes: Cada fase se explica por separado pero nunca se realizan como pasos aislados, más bien es posible que algunas actividades se realicen de manera simultánea, y algunas de ellas podrían repetirse. Estas etapas son:
- Identificación de problemas, oportunidades y objetivos:en esta etapa se deberá descubrir lo que la organización intenta realizar, luego determinar si el uso de los sistemas de información apoyaría a la organización para alcanzar sus metas.
- Determinación de los requerimientos de información:Esto se hace a partir de los usuarios particularmente involucrados, para determinar los requerimientos de información dentro de una organización pueden utilizarse diversos instrumentos, los cuales incluyen: muestreo, el estudio de los datos y formas usadas para la organización, la entrevista, los cuestionarios; la observación de la conducta de quien tomó las decisiones.
- Análisis de las necesidades del sistema:Se analizan las necesidades propias del sistema. También se analizan las decisiones estructuradas por realizar, que son decisiones donde las condiciones, condiciones alternativas, acciones y reglas de acción podrán determinarse.
- Diseño del sistema recomendado:Se usa la información recolectada con anterioridad y se elabora el diseño lógico de sistemas de información, esta etapa también incluye el diseño de los archivos o la base de datos que almacenará aquellos datos requeridos por quien toma las decisiones en la organización.
- Desarrollo y documentación del software:Dentro de las técnicas estructuradas para el diseño y documentación del software se tienen: el método HIPO, los diagramas de flujo, los diagramas Nassi-Schneiderman, los diagramas Warnier-Orr y el pseudocódigo es aquí donde se transmite al programador los requerimientos de programación.
- Pruebas y mantenimiento del sistema:Todo sistema de información debe probarse antes de ser utilizado, ya que el costo es menor si se detectan los problemas antes de que entre en funcionamiento.
- Implantación y evaluación del sistema:Esta es la última etapa del desarrollo del sistema, esto incluye el adiestramiento que el usuario requerirá. Uno de los criterios fundamentales que debe satisfacerse, es que el futuro usuario utilice el sistema desarrollado.
De esta forma, los sistemas de información generalmente automáticos se elaborarían de una forma más sencilla, estructurada y ordenada, siguiendo un mismo patrón como herramienta para solucionar los problemas existentes en las diferentes organizaciones.
Referencias
Revisados en la WWW el 20 de mayo del 2016
- http://analisideinformacion.blogspot.com/2012/09/metodologia-kendall-kendall.html
- https://sisteminformacii.wikispaces.com/METODOLOG%C3%8DA+DE+KENDALL+%26+KENDALL
Desarrollo de Sistemas de Información bajo enfoque Incremental – Luis Castellanos
Una metodología incremental presenta la ventaja de ser dinámica y flexible. Permite usar las salidas de las etapas precedentes, como entradas en las etapas sucesivas, y facilita corregir cualquier error detectado o llevar a cabo mejoras en los distintos productos que se generan a lo largo de su aplicación.
La Metodología Incremental presenta 6 etapas claramente definidas:
1 Estudio de Factibilidad
Es el determinar si es posible o no ofrecer solución automatizada a los problemas actuales.
A su vez comprende los siguientes pasos: Descripción del Entorno; Identificación del Problema; Identificación de los Procedimientos Actuales; Presentación de las Posibles Soluciones al Problema; Validación de las Posibles Soluciones; Ventajas y Desventajas de cada Posible Solución; Cuadro comparativo de Costos y Tiempos de Ejecución; Recomendación
2 Acciones Preliminares
Son las acciones que llevamos a cabo antes de empezar el proyecto formalmente. Comprende dos pasos: Designación del equipo de Proyecto; y Elaboración de la Planificación del Proyecto
3 Análisis de Sistemas
El Análisis de Sistemas amplía resultados del Estudio de Factibilidad y define QUÉ va a hacer el nuevo Sistema. Presenta el Modelo del Sistema Actual.
Llevar a cabo el análisis de un sistema no es más que conocer la situación actual. De hecho, se amplían los resultados del Estudio de Factibilidad, y se hace un Modelo Lógico del Sistema Actual. La idea es “retratar” o tomar una “foto” del Sistema Actual.
Comprende la identificación de: Objetivo General y Objetivos Específicos del Sistema Propuesto; Usuarios; Diagrama de Flujo de Datos del Sistema Actual (DFD) o Lenguaje Unificado de Modelado (UML); Diccionario de Datos del Sistema Actual (DD); Recopilación de Reportes del Sistema Actual; Elaboración de Procedimientos Propuestos.
4 Diseño de Sistemas
Es la etapa en la cual se presenta el Modelo del Sistema Propuesto.Es donde se pone de manifiesto la creatividad del Analista, para solucionar el problema planteado en el Estudio de Factibilidad, y cumplir con los Objetivos establecidos en el Análisis del Sistema.
Se elaboran de los siguientes instrumentos: Diagrama de Flujo de Datos del Sistema Propuesto (DFD) o UML; Diccionario de Datos del Sistema Propuesto (DD); Diagrama Entidad Relación (DER); Diagrama Estructurado de Datos (DED); Carta Estructurada (CE); Diagramas de Acción (DA); Diseño de Interfases; Selección de la plataforma de desarrollo
5 Programación
Es la construcción de la aplicación de Software. Comprende la generación del Código fuente y código objeto, y la Creación de la Base de Datos.
6 Implantación
Incluye todas las actividades para poner un sistema en producción (entregar al usuario). Sus etapas son:
- Prueba;
- Conversión;
- Instalación de Hardware y Software;
- Adiestramiento de Usuarios;
- Elaboración de la Documentación;
- Entrega al Usuario.
Referencias
Desarrollo de Sistemas de Información bajo enfoque Incremental
Método Blue Watch – Jonás Montilva
Modalidades y enfoques actuales del desarrollo de software
El desarrollo de software es un proceso complejo y altamente especializado. Varios factores determinan la complejidad de este proceso. Dos de ellos son la amplia variedad de lenguajes y herramientas de programación que existen y la diversidad de tipos de aplicaciones que pueden desarrollarse con ellos. Esta diversidad va desde aplicaciones móviles, aplicaciones Web, software para redes sociales, videojuegos, hasta llegar a los sistemas de software de mayor complejidad, tales como los sistemas operativos y los compiladores.
Factores como los mencionados han hecho que el desarrollo de software requiera, por un lado, personal altamente capacitado y con niveles de especialidad cada vez mayores y, por el otro, métodos de desarrollo que sean efectivos y estén bien probados y debidamente documentados. En la actualidad, y en función del uso de métodos, el desarrollo de software se lleva a cabo bajo una de dos modalidades opuestas: artesanal o ingenieril. Dentro de la modalidad ingenieril, el desarrollo de software sigue, a su vez, dos enfoques diferentes: ágil y disciplinado.
El desarrollo artesanal sigue siendo ampliamente utilizado por programadores solitarios (hackers) y organizaciones que desarrollan software para uso interno, en las cuales el software no es considerado un activo empresarial. Dos de sus características más distintivas son:
- no emplear método alguno o utilizar incorrectamente uno de los métodos conocidos y
- asumir erróneamente que un programador, por sí solo, tiene la capacidad, o es suficientemente competente, para ejecutar apropiadamente todas las actividades que van desde la identificación de requisitos hasta la prueba de aceptación del producto. El resultado de esta modalidad es impredecible y depende enteramente del programador.
El desarrollo ingenieril emplea principios, conceptos, métodos, prácticas y técnicas basadas en la Ingeniería del Software. Esta modalidad tiene las siguientes características:
- el desarrollo de software, visto como un proceso, es de carácter grupal y no individual;
- este proceso se divide en sub-procesos claramente diferenciados, por ejemplo: especificación de requisitos, diseño arquitectónico, programación, pruebas y gestión del proyecto;
- cada sub-proceso demanda personal altamente especializado y capacitado para ejecutar debidamente sus actividades y
- el proceso es guiado por un método, modelo de procesos o marco metodológico que establece claramente que hacer, quien debe hacerlo y cómo debe hacerse. Los resultados de esta modalidad son claramente predecibles: productos de software de alta calidad.
Bajo la modalidad ingenieril existen dos enfoques contrapuestos: disciplinado y ágil. El enfoque disciplinado, también denominado pesado, hace énfasis en la calidad del producto, en el proceso de desarrollo y en la gestión del proyecto, a través de un plan claramente definido y previamente elaborado. Dos representantes de este enfoque son el método RUP y el marco metodológico Gray WATCH. El enfoque ágil o ligero, por el contrario, le da mayor importancia a cuatro aspectos, descritos en el Manifiesto Ágil: el individuo y sus interacciones, el software funcionando, la colaboración con el cliente y la respuesta al cambio. XP y SCRUM son los dos representantes más conocidos de este enfoque.
Estos dos enfoques tienen sus virtudes y sus deficiencias. En Ingeniería del Software, al igual que en otras disciplinas blandas, no existen “balas de plata” y tampoco son buenos los extremos. Por ello, ha emergido en los últimos años un enfoque intermedio que equilibra agilidad y disciplina. A este enfoque, lo hemos denominado enfoque balanceado, ágilmente disciplinado o disciplinadamente ágil. El Método Basado en Riesgos de Barry Boehm es el precursor de esta corriente.
En la Universidad de Los Andes (Venezuela) hemos creado un método denominado Blue WATCH basado, también, en el enfoque balanceado. Este marco combina lo mejor de los enfoques ágil y disciplinado. Su versión más reciente es de conocimiento abierto y se describe en el portal http://www.e-praxis.com.ve.
Blue WATCH y el desarrollo de software ágilmente disciplinado
En las líneas anteriores describimos las características y diferencias de los enfoques de desarrollo de software ágil y disciplinado. Destacamos allí la importancia de encontrar un balance entre ambos enfoques. Blue WATCH es un marco metodológico creado con la intención expresa de lograr dicho balance. Está orientado al desarrollo de aplicaciones Web y puede ser aplicado por grupos de desarrollo de mediano tamaño (3 – 10 personas).
Blue WATCH está compuesto de tres modelos que describen los elementos fundamentales del desarrollo de software: productos, procesos y actores. El modelo de productos identifica cada uno de los productos intermedios y finales que los actores elaboran durante el desarrollo de software. El modelo de procesos muestra el orden en que los procesos técnicos, de gestión y soporte deben ser ejecutados. El modelo de actores identifica y describe los roles que se requieren para producir software y las responsabilidades que ellos tienen en la ejecución de los procesos.
El desarrollo de una aplicación se inicia con dos procesos de gestión: Inicio del Proyecto y Planificación Inicial del Proyecto, los cuales producen, respectivamente, los informes de Visión del Producto y Plan Inicial del Proyecto. Continúa con un conjunto de tres procesos técnicos: Análisis del Contexto o Dominio, Desarrollo Inicial de Requisitos y Diseño Inicial de la Aplicación. Estos procesos dividen la arquitectura de la aplicación en incrementos y producen los informes de Descripción del Problema, Documento de Requisitos y Documento de Diseño, respectivamente. Los dos últimos son refinados o actualizados en cada ciclo del conjunto de procesos iterativos denominado Desarrollo de Incrementos.
Siguen dos procesos de gestión encargados de planificar e iniciar el desarrollo de los incrementos: Planificación de Entregas y Planificación de la Iteración i-ésima. El desarrollo de los incrementos de la aplicación es un conjunto de procesos iterativos. Cada iteración produce un incremento o una parte de él. Cada iteración tiene una duración fija (1 – 6 semanas) y se inicia con el Refinamiento de Requisitos del Incremento y continúa con los procesos de Diseño Detallado del Incremento, Construcción del Incremento y Pruebas del Incremento. Una vez que el incremento ha sido codificado y probado, este es entregado a sus usuarios para que ellos ejecuten el proceso de Verificación y Validación, el cual cierra la i-ésima iteración, dando inicio a la siguiente iteración o a la Entrega Final de la Aplicación y el Cierre del Proyecto.
En paralelo a los procesos descritos anteriormente, se lleva a cabo un conjunto de procesos transversales que dan soporte a la gestión del proyecto; estos son: Gestión de Requisitos, Verificación y Validación de Productos, Gestión de la Configuración del Software y Gestión de Requisitos.
El carácter ágil del método surge de adoptar y adaptar las propiedades incremental e iterativa del método SCRUM. El carácter disciplinado está en la integración de los procesos de planificación ágil de SCRUM y los procesos disciplinados de gestión de proyectos, tal como se definen en el cuerpo de conocimientos de la Gestión de Proyectos (PMBOK). Los procesos técnicos y de soporte del Blue WATCH se han tomado y adaptado del marco metodológico Gray WATCH.
Blue WATCH fue desarrollado por el Grupo de Investigación GIDYC de la Universidad de Los Andes y está descrito, con mayor detalle, en el portal educativo http://www.e-praxis.com.ve; portal dedicado a la capacitación profesional de ingenieros de software.
Referencias
- http://www.agilemanifesto.org/iso/es/
- https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
- http://people.cs.aau.dk/~jeremy/SOE2011/resources/Boehm.pdf
- http://e-praxis.com.ve/portal/recursos/recursos-metodologicos/blue-watch/
- http://e-praxis.com.ve/portal/recursos/recursos-metodologicos/gray-watch/
- https://www.scrum.org/
- http://www.pmi.org/PMBOK-Guide-and-Standards.aspx
Desarrollo de Sistemas de Información – Introducción
Históricamente se habla de 4 generaciones de Computadores [de acuerdo a Tanembaum], a saber:
- 1ra Generación: Tubos al vacío
- 2da Generación: Transistores
- 3ra Generación: Circuitos Integrados
- 4ta Generación: Microprocesadores
Durante las 3 primeras generaciones, se hablaba de “Procesamiento de Datos”, al estar trabajando el personal del nivel “operativo” con las computadoras.
A partir de la aparición de los microprocesadores, se involucra el nivel “táctico” o medio, y empiezan a ser desarrollados los primeros sistemas de información, que podían ser consultados en computadoras de escritorio, más manejables que los mainframes usados hasta el momento.
Al evolucionar la Tecnología de Información, el nivel gerencial “estratégico” (alta gerencia) también requiere de herramientas para manejar el negocio, desarrollándose los “Sistemas de Información Gerencial” (SIG) y luego los “ERP’s”.
- Nivel Operativo: Procesamiento de Datos
- Nivel Táctico: Sistemas de Información
- Nivel Estratégico: ERP’s / SIG
Un Sistema de Información (SI) es un conjunto interrelacionado de elementos que proveen información para el apoyo de las funciones de operación, gerencia y toma de decisiones en una organización.
Veamos a continuación algunas metodologías existentes para desarrollar Sistemas de Información.
Referencias
Desarrollo de Sistemas de Información
Año 03 Número 09: Desarrollo de Sistemas de Información
Editorial
La edición de Junio es una edición de lujo, ya que cuenta con el aporte de un invitado de lujo: Jonás Montilva. Y cómo no llamar a Jonás para que hable él mismo del Método Watch, dentro del tema de portada “Desarrollo de Sistemas de Información”. Por supuesto que los demás escritores no se quedaron atrás y también presentaron material de lujo.
En las columnas habituales: “A mí también me gusta el chocolate” con “Marquesa de Oreo”, se podrá conocer acerca de “Carol” en “el Séptimo Arte”, “10° Mandamiento” en “Enfoque de Sistemas”, “Humphrey Bogart” en “Ensalada de Ideas”, “Posada Sol, Luna y Estrellas” en “Mundo en Diapositivas”, “NeoTelling” en el “Rincón de las TICs”, “la Supervivencia de los más Ineptos” con “a 30 años de Chernóbil”, acerca de “Remando sincronizados” en la columna “Y otras cosas”, “¿Arquitectura?” en “Merodeando desde la Arquitectura”, “Vía Saludable” acerca de “Caminar 30 minutos”, “Parábola de los Deseos” en Reflexiones Diarias.
Lo más probable que el último número por los momentos será la edición 12 del año 3 (septiembre 2016).
Coordinación General y Edición: Luis Castellanos H.
Tabla de Contenidos: Tema de Portada
- Introducción
- Método Watch de Jonás Montilva
- Desarrollo Incremental de Sistemas de Información de Luis Castellanos
- Ciclo de Vida de Kendall & Kendall
- Ciclo de Vida de James Senn
- Método RUP de IBM
- Método XP de Kent Beck
- Modelo Orientado a Objetos de James Martin
Tabla de Contenidos: Secciones Fijas
- A mi también me gusta el Chocolate
- Del Séptimo Arte
- El Rincón de las TIC’s
- Enfoque de Sistemas
- Ensalada de Ideas
- Humor
- Merodeando desde la Arquitectura
- Mundo en Diapositivas
- Supervivencia de los más Ineptos
- Vía Saludable
- Y otras cosas
- Tecnología al Día
- Reflexiones Diarias
(Haga click en el banner para leer la Revista)
Co-produced by :
DTyOC 