1.1. Existen ocasiones en que los requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal. Esta situación se encuentra aveces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente (por ejemplo, una adaptación a un software contable debido a los cambios en las regulaciones del gobierno).Esto puede ocurrir también en un número limitado de proyectos de nuevos desarrollos,pero sólo cuando los requerimientos están bien definidos y son estables en forma razonable,
1.2. El modelo en cascada,algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado.
1.3. Desventajas -Inflexibilidad : al dividir el proyecto en distintas etapas. -Es difícil responder a cambios en los requerimientos del cliente.
1.4. Ventajas: - Se tiene todo bien organizado y no se mezclan las fases. - Es perfecto para proyectos que son rígidos. - Ideal para proyectos donde se especifiquen muy bien los requerimientos. - Ideal para proyectos en que se conozca muy bien la herramienta a utilizar. -Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el Software.
2. El modelo incremental
2.1. En muchas situaciones los requisitos iniciales del software están bien definidos enforma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un procesopuramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar demanera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla yexpandirla en las entregas posteriores del software. En estos casosse elige un modelo de proceso diseñado para producir el software en forma incremental.
2.2. Combina elementos del modelo en cascada aplicado en forma iterativa. El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del software [MCD93]. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podría realizar funciones básicas de administración de archivos, edición y producción de documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer incremento, funciones de corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas de configuración de página. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos que se expone más adelante.
2.3. Ventajas -Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. -También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software. -El modelo proporciona todas las ventajas del modelo en Cascada re-alimentado, reduciendo sus desventajas sólo al ámbito de cada incremento. -Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
2.4. Desventajas -El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de riesgos. -Requiere de mucha planeación, tanto administrativa como técnica. -Requiere de metas claras para conocer el estado del proyecto
3. El modelo DRA
3.1. El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción basado en componentes. Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a 90 días).
3.2. Como otros modelos de proceso, el enfoque DRA cumple con las actividades genéricas del marco de trabajo que ya se han presentado. La comunicación trabaja para entender el problema de negocios y las características de información que debe incluir el software. La planeación es esencial porque varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema.
3.3. Ventajas -Es muy rápido. -Permite trabajar en él a varias personas a la vez
3.4. Desventajas -Enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje. -Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA. -No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. -La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. -No es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes.
4. El modelo en espiral
4.1. El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería del software concurrente y con múltiples usuarios. Tiene dos características distintivas principales. Una de ellas es un enfoque cíclico para el crecimiento incrementa! del grado de definición e implementación de un sistema, mientras disminuye su grado de riesgo. La otra es un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
4.2. Cuando se aplica el modelo en espiral, el software se desarrolla en una serie déentregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documentodel modelo o un prototipo. Durante las últimas iteraciones se producen versiones cada vezmás completas del sistema desarrollado.
4.3. Un proceso en espiral se divide en un conjunto de actividades del marco de trabajoque define el equipo de ingeniería delsoftware. Para propósitos ilustrativos seaprovechan las actividades genéricas delmarco de trabajo expuestas páginas atrás. Cada una de las actividades del marco detrabajo representa un segmento de la ruta enespiral que se presenta en la figura. Cuandocomienza este proceso evolutivo el equipo desoftware realiza actividades implicadas en uncircuito alrededor de la espiral que tiene unadirección en el sentido del movimiento de lasmanecillas del reloj, y que se inicia desde elcentro. El riesgo es un factor considerado en cada revolución.
4.4. Ventajas -No necesita una definición completa de los requisitos para empezara funcionar. -Al entregar productos desdeel final de la primera iteración es más fácil validar los requisitos. -El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursosinvertidos en una iteración (las anteriores iteraciones estánbien). -El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempode subsanarlos.
4.5. Desventajas. - Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. - No se ha utilizado tanto como otros modelos de ciclo de vida.
5. El modelo de desarrollo concurrente
5.1. El modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, se representa en forma esquemática como una serie de actividades del marco de trabajo, acciones y tareas de la ingeniería del software y sus estados asociados. Por ejemplo, la actividad de modelado, definida para el modelo en espiral, se lleva cabo al invocar las acciones siguientes: construcción de prototipos o modelado y especificación del análisis y diseño.
5.2. El modelo de proceso concurrente define una serie de eventos que dispararántransiciones de estado a estado para cada una de las actividades, acciones o tareas de laingeniería del software. Por ejemplo, durante los primeros estados del diseño (una acciónde la ingeniería del software que ocurre en el curso de la actividad de modelación) no sedetecta una inconsistencia en el modelo del análisis. Esto genera el evento corrección del análisis del modelo, el cual disparará la creación del análisis desde el estado realizado hasta el estado de en espera de cambios.
5.3. El modelo de proceso concurrente se aplica a todos los tipos de desarrollo de soft-ware y proporciona una visión exacta del estado actual de un proyecto. En lugar de confinar las actividades, acciones y tareas de la ingeniería del software a una secuencia de eventos, define una red de actividades. Cada actividad, acción o tarea en la red existe de manera simultánea con otras actividades, acciones o tareas. Los eventos generados en un punto de la red del proceso disparan transiciones entre los estados.
5.4. Ventajas -Excelente para proyectos en los que se conforman grupos de trabajo independientes. -Proporciona una imagen exacta del estado actual de un proyecto.
5.5. Desventajas -Si no se dan las condiciones señaladas no es aplicable. -Si no existen grupos de trabajo no se puede trabajar en este método
