Modelo construye y compone

Este es el primer modelo de ciclo de vida que se usó y probablemente el más usado. El software se desarrolla sin especificar requerimientos y sin diseño. Luego el software cambia tantas veces como sea necesario hasta que satisface al cliente. Esto trabaja muy bien para programas pequeños y sencillos, pero es completamente insatisfactorio para sistemas de software de cualquier tamaño. Ha sido demostrado que el costo de cambiar un producto de software es relativamente pequeño si el cambio se hace en las fases de requerimientos o diseño y crece mucho en fases posteriores. El mantenimiento también puede ser muy problemático para un sistema desarrollado bajo este escenario.

Modelo de cascada modificado

• Se inventó para permitir retroalimentación y encimamiento entre fases.
• Es un modelo iterativo y no lineal.
• Para facilitar la terminación de metas y tareas, es normal congelar partes del desarrollo después de cierto punto en la iteración.
• Se agregaron los pasos de verificación (checar que el sistema es correcto, construir el sistema correctamente) y validación (checar que el sistema cumple con los deseos del cliente, construir el sistema correcto).

El modelo de la cascada (y el de la cascada modificada) son inflexibles en el particionamiento del proyecto en sus distintas fases. Sin embargo, generalmente reflejan la práctica de la ingeniería.

Modelo de construcción de prototipos

El paradigma de construcción de prototipos tiene tres pasos:

1. Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las áreas donde es obligatorio más definición.
2. Construir y revisar la maqueta (prototipo).
3. El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software.

• El cliente no identifica los requisitos detallados.
• El responsable del desarrollo no está seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-máquina.

Modelo RAD (Diseño Rápido de Aplicaciones)

Es un modelo de proceso de desarrollo de software de cascada que enfatiza un ciclo de desarrollo extremadamente corto. Este modelo se puede usar si:

• Se comprenden bien los requisitos y se limita el ámbito del proyecto.
• Es fácil dividir al sistema en módulos.
• Se utiliza un enfoque de construcción basado en objetos reusables.

• Requiere recursos humanos suficientes como para crear el número correcto de equipos.
• Necesita que el cliente y el desarrollador se comprometan en las actividades necesarias para completar un sistema en un tiempo corto.

Modelos evolutivos

Esta familia de modelos se utilizan en las siguientes circunstancias:

• Si los requisitos cambian conforme el desarrollo avanza.
• Si las fechas de mercado hacen imposible tener un producto completo y hay que introducir una versión limitada.
• Si los requisitos centrales están bien definidos pero todavía hay que definir los detalles de las extensiones del producto.

1. Modelo incremental
   • Combina elementos del modelo de cascada (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos.
   • El primer incremento es un producto esencial (núcleo), se afrontan requisitos básicos y muchas funciones extras (conocidas o no) quedan para los siguientes incrementos.
   • El cliente usa el producto central y en base a la utilización y/o evaluación se desarrolla un plan para el incremento siguiente.
   • Este proceso se repite hasta que se elabora el producto completo.
   • Es interactivo, al igual que el de construcción de prototipos y otros enfoques evolutivos. Pero a diferencia del modelo de construcción de prototipos, el modelo incremental entrega un producto operacional en cada incremento.
   • Es útil cuando la dotación de personal no está disponible para una implementación completa. El primer incremento se pueden implementar con pocas personas. Si el producto central es bien recibido, se puede añadir mas personal.

2. Modelo de la espiral de Boehm
   • Combina los elementos controlados y sustemáticos del modelo de cascada con la filosofía interactiva de construcción de prototipos.
   • Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. El software se desarrolla en una serie de versiones incrementales.
   • Durante las primera iteraciones, la versión incremental puede ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema.
   • El modelo se divide en un número de actividades estructurales llamadas regiones de tareas que pueden ser de tres a seis. Pressman define las siguientes regiones de tareas:
     • Comunicación con el cliente.
     • Planeación. Define recursos, tiempo y otras informaciones relacionadas con el proyecto.
     • Análisis de riesgos. Evalúa riesgos técnicos y de administración.
     • Ingeniería. Construye una o más representaciones de la aplicación.
     • Construcción y adaptación. Construye, prueba, instala y proporciona soporte al usuario (p.e. documentación).
     • Evaluación del cliente.
   • Cada región tiene tareas que se adaptan a las características del proyecto.
   • El primer circuito de la espiral produce una especificación de productos; los pasos siguientes en la espiral se podrían usar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software.
   • Cada paso por la región de planificación produce ajustes en el plan del proyecto.
   • El costo y la planificación se ajustan según la reacción ante la evaluación del cliente.
   • A diferencia del modelo de vida clásico que termina cuando se entrega el software, el modelo en espiral se puede adaptar y aplicarse a lo largo de toda la vida del software.

   Su principal desventaja es que es nuevo (1988) y no se ha utilizado tanto como otros modelos de ciclo de vida. Además puede resultar difícil convencer a algunos clientes que el proceso es controlable.

Modelo de métodos formales

• Permiten especificar, desarrollar y verificar un sistema aplicando una notación rigurosa y matemática.
• Eliminan muchos de los problemas que son difíciles de superar con otros paradigmas. La ambiguedad, la incompletez y la inconsistencia se pueden descubrir y corregir, no mediante una revisión, sino mediante la aplicación del análisis matemático.
• Su principal desventaja es que requiere que el desarrollador y el cliente tengan conocimientos formales para poderlos aplicar y comunicarse entre sí.

Técnicas de cuarta generación (4GT)

• Permite especificar el software usando lenguajes especializados o notaciones gráficas que describan el problema.
• Requiere usar alguna herramienta CASE (Computer-aided Software Engineering) con herramientas tales como: SQL (Structured Query Language), generador de reportes, base de datos, definidores de pantallas, generadores de código, generador de gráficas, hoja de cálculo, etc.
• Idealmente el cliente describe los requisitos, que son traducidos inmediatamente a un prototipo operativo.
• En aplicaciones pequeñas, se puede ir directamente a la implementación usando un lenguaje de cuarta generación (4GL).
• El aplicaciones grandes, el uso de 4GL sin diseño provocará los mismos problemas que los otros paradigmas (poca calidad, mantenimiento pobre y mala aceptación del cliente).
• El uso de 4GL permite al desarrollador centrarse en la representación de los resultados deseados.
• Para transformar una implementación 4GT en un producto, el desarrollador debe dirigir una prueba completa, hacer una buena documentación y ejecutar el resto de las actividades de integración requeridas en los otros paradigmas. Además, el software desarrollado con 4GT debe ser construido de modo que facilite el mantenimiento.