I. Metodologías de desarrollo de software El alumno elegirá la metodología para desarrollar un sistema de información Tema I Metodologías de desarrollo de software Uno de los grandes problemas con los cuales se enfrenta el Desarrollo de software es la proliferación de modelos en una empresa, si la madurez de la organización en materia de sistemas no es mucha, se puede dar que exista una metodología por cada equipo de desarrollo. Por ello es importante que una organización defina el modelo de ciclo de vida que va a emplear para desarrollar software. Ingeniería e Ingeniería de Software. La ingeniería se define como un “conjunto de conocimientos y técnicas cuya aplicación permite la utilización racional de los materiales y de los recursos naturales, mediante invenciones, construcciones u otras realizaciones provechosas para el hombre” ¿En que difiere la ingeniería de software de otros tipos de ingeniería y en que es similar? Una propiedad que la ingeniería de software comparte con las otras es la necesidad de una descripción exhaustiva de lo que debe producirse, un proceso llamado “análisis de requerimientos”. Por otra parte, los proyectos de software están sujetos a cambios frecuentes durante todo el proceso de desarrollo. La ingeniería de software es “la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software, es decir, la aplicación de ingeniería al software” (IEEE, 1993). Ingeniería del software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollarlo, operarlo, y mantenerlo. Se conoce también como desarrollo de software o producción de software. La ingeniería de software se puede dividir en tres fases: 1. Fase de Definición: ¿Qué? Ingeniería de sistemas, planificación del proyecto y análisis de requisitos. 2. Fase de Desarrollo: ¿Cómo? Diseño, construcción (programación) y prueba. 3. Fase de Mantenimiento: El cambio. Se aplican fases anteriores sobre software ya existente. Modelo Lineal Secuencial o de Cascada El modelo lineal secuencial para la ingeniería de software sugiere un enfoque sistemático, secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento. La figura 1.1 muestra este modelo. Figura 1.1 El modelo Lineal Secuencial Ingeniería de sistemas/ información Análisis Diseño Código Prueba Modelado según el ciclo de ingeniería convencional, el modelo lineal secuencial, llamado algunas veces “ciclo de vida básico” o “modelo en cascada” consta de las siguientes actividades: Ingeniería de sistemas: como el software siempre forma parte de un sistema más grande, hay que establecer los requisitos de todos los elementos del sistema: hardware, bases de datos, personas, etc. Análisis de los requisitos del software: para entender la naturaleza del software a construir se debe comprender el dominio de información del software, así como la función requerida, comportamiento, rendimiento e interconexión. Diseño: el proceso de diseño traduce requisitos en una representación del software que se pueda evaluar por calidad antes de que comience la generación del código. Generación de código: El diseño se debe traducir en una forma legible por la máquina, si el diseño se realizó en forma detallada la generación de código se realiza mecánicamente. Pruebas: esta etapa se centra en los procesos lógicos internos del software para la detección de errores y asegurarse que la entrada definida produzca resultados reales de acuerdo con los resultados requeridos. Mantenimiento: el software indudablemente sufrirá cambios después de ser entregado al cliente, ya sea porque se encuentren errores, para acoplarse a cambios de su entorno externo o porque el cliente requiere mejoras funcionales o de rendimiento. El modelo lineal es el paradigma más antiguo que existe y el más extensamente utilizado en la ingeniería del software. Sin embargo ha recibido muchas críticas poniendo en duda su eficacia. Entre los problemas que se encuentran algunas veces en este modelo se encuentran: 1. Los proyectos reales rara vez siguen el modelo secuencial que propone el modelo. Este modelo omite la interacción, que en realidad se lleva a cabo. 2. A menudo es difícil que el cliente exponga explícitamente todos los requisitos. Este modelo lo requiere y se presenta siempre cierta incertidumbre al comienzo de muchos proyectos. 3. El cliente debe tener paciencia. Esto es porque una versión del trabajo realizado no estará disponible hasta que el proyecto este avanzado, propiciando esto un fracaso en las relaciones con el cliente. Además de que encontrar errores hasta que se revise el programa puede resultar desastroso. 4. Los responsables del desarrollo del software siempre se retrasan innecesariamente. Esto es porque en el ciclo de vida clásico algunos miembros del equipo del proyecto deben esperar a otros miembros para completar tareas dependientes. Modelo de prototipos El modelo de construcción de prototipos puede ofrecer el mejor enfoque cuando: • Un cliente a menudo define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento, o salida. • En otros casos, el responsable del desarrollo de software puede o no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-máquina. Refinamiento de requisitos Diseño rápido Escuchar al usuario/cliente Construir/revisar prototipo Refinamiento Pruebas Aprobación u observaciones del usuario/cliente Figura 1.2 El modelo de construcción de prototipos El proceso de este modelo comienza con la recolección de requisitos con un encuentro del desarrollador con el cliente, definiendo los objetivos globales para el software, identificando los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Posteriormente se genera un diseño rápido que se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo que es evaluado por el usuario/cliente y lo utiliza para refinar los requisitos del software a desarrollar. Aunque el prototipo puede servir como una visión idealizada del sistema, es un modelo que gusta mucho a los clientes y desarrolladores, sin embargo, la construcción de prototipos también puede ser problemática por las razones siguientes: 1. Con la prisa de hacer que funcione, no se tiene en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. 2. El cliente y el desarrollador se deben poner de acuerdo en que el prototipo se construya para servir como un mecanismo de definición de requisitos. Entonces se descarta el prototipo (al menos en parte) y se realiza la ingeniería del software con una visión hacia la calidad y la facilidad de mantenimiento. 3. El desarrollador a menudo hace compromisos de implementación para hacer que el prototipo funciones rápidamente, utilizando un sistema operativo o lenguaje de programación inadecuado simplemente porque esta disponible o porque es conocido. Aunque pueden surgir problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería de software. La clave esta en definir las reglas del juego al comienzo, es decir, establecer que el prototipo se construirá sólo como un mecanismo de definición de requisitos. Modelo de desarrollo rápido de aplicaciones Es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación de “alta velocidad” del modelo lineal secuencial en el que se logra el desarrollo rápido, utilizando un enfoque de construcción basado en componentes. Permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases: Modelado de gestión: El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión?, ¿Qué información se genera?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa? Modelado de datos: La información se refina como un conjunto de objetos de datos, se definen las características de cada uno de los objetos y las relaciones entre estos objetos. Modelado del proceso: Se transforman los datos para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos. Generación de aplicaciones: El DRA asume la utilización de técnicas de 4ª. Generación en lugar de crear software con lenguajes de programación de 3ª. Generación. Este modelo trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software. Pruebas y entrega: Como DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce el tiempo de pruebas, sin embargo hay que probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo. Equipo no.3 Equipo no. 2 Equipo no. 1 Modelado de gestión Modelado de gestión Modelado de gestión Modelado de datos Modelado de datos Modelado de datos Modelado de procesos Modelado de procesos Modelado de procesos Generación de aplicaciones Pruebas y volúmenes Generación de aplicaciones Pruebas y volúmenes Generación de aplicaciones Pruebas y volúmenes De 60 a 90 días Las limitaciones de tiempo impuestas en un proyecto demandan ámbito en escalas. Si una aplicación de gestión puede modularse de forma que permita completarse cada una de las funciones principales en menos de 3 meses, es un candidato del DRA. Cada una de las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un solo conjunto. Al igual que otros modelos, el enfoque DRA tiene algunos inconvenientes: 1. Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA. 2. Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un periodo corto de tiempo. Si no hay compromiso, los proyectos fracasarán. No todos los tipos de aplicaciones son apropiadas para DRA. Si un sistema no se puede modularizar adecuadamente, la construcción de los componentes necesarios para DRA será problemático. Este modelo tampoco es apropiado cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere de un alto grado de interoperatividad con programas de computadora ya Modelo de Desarrollo evolutivos El modelo lineal secuencial se diseña para el desarrollo en línea recta y se asume que se va a entregar un sistema completo una vez que la secuencia lineal se haya finalizado. El modelo de construcción de prototipos se diseña para ayudar al cliente (o al que desarrolla) a comprender los requisitos. En ninguno de los paradigmas se tiene en cuenta la naturaleza evolutiva del software. Los modelos evolutivos son interactivos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez más completas del software. Modelo incremental Combina elementos del modelo lineal secuencial con la filosofía interactiva de construcción de prototipos. El modelo incremental aplica secuencias lineales de la misma forma que progresa el tiempo en el calendario, cada secuencia lineal produce un “incremento” del software. Durante el flujo del proceso de cualquier incremento se puede incorporar el paradigma de construcción de prototipos. Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial (núcleo). Es decir se afrontan requisitos básicos, pero muchas funciones suplementarias quedan sin implementar hasta los siguientes incrementos. Como resultado de la utilización y/o evaluación de los incrementos, se desarrolla un plan para el siguiente incremento. El plan incluye la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones y características adicionales. A diferencia de la construcción de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. El desarrollo incremental es particularmente útil cuando la dotación de personal no esta disponible para una implementación completa en cuanto a de la fecha límite de gestión que se haya establecido para el proyecto. Los incrementos se pueden planear para gestionar riesgos técnicos, que tengan que ver con software o hardware. Ingeniería de sistemas/información Incremento 1 Análisis Análisis Análisis Análisis Diseño Diseño Diseño Diseño Código Código Código Código Tiempo de Calendario Prueba Entrega del 1er. incremento Prueba Entrega del 2do. incremento Prueba Entrega del 3er. incremento Prueba Entrega del 4to. incremento Modelo de Espiral Es un modelo de proceso de software evolutivo que acompaña la naturaleza interactiva de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Esta metodología proporciona el potencial para el desarrollo rápido de versiones incrementales del software. Durante las primeras iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema. La figura 1.5 ilustra el método de espiral. Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación del producto, los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Figura 1.5 El modelo en espiral Cada paso de la región de planificación produce ajustes en el plan de proyecto. El costo y la planificación se ajustan según la reacción ante la evaluación del cliente. Además el gestor del proyecto ajusta el número planificado de iteraciones requeridas para completar el software. A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software. Este modelo representa un enfoque realista del desarrollo de sistemas y de software a gran escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante un riesgo en cada uno de los niveles evolutivos. Utiliza la construcción de prototipos como mecanismo de reducción de riesgos, pero lo que es más importante, permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo incorpora al marco de trabajo interactivo que refleja de forma más realista el mundo real. El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos. Pero por igual que otros paradigmas, el modelo en espiral no es la solución perfecta. Puede resultar difícil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es controlable. Requiere una considerable habilidad para la evaluación del riesgo, y cuenta con esta habilidad para el éxito. Si un riesgo importante no es descubierto y gestionado, indudablemente habrá problemas.
