1. 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 problemas.
2. Puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
3. Ventajas
4. Modelo Original de Boehm
5. No hay un número definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestión de proyecto
6. Cada vuelta se divide en 4 sectores:
6.1. Planeación
6.1.1. Determinación de los objetivos, alternativas y restricciones
6.2. Análisis de Riesgo
6.2.1. Análisis de alternativas e identificación/resolución de riesgos
6.3. Ingeniería
6.3.1. Desarrollo del producto hasta "el siguiente nivel".
6.4. Evaluación
6.4.1. Valoración por parte del cliente de los resultados obtenidos.
7. Espiral
8. Es una adaptación del modelo de espiral y define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral
9. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:
9.1. Identificación
9.1.1. Del sistema o subsistemas clave de los directivos.
9.2. Determinación
9.2.1. De las condiciones de victoria de los directivos.
9.3. Negociación
9.3.1. De las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).
10. Modelo WINWIN
11. Es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en la ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades.
12. Espiral
13. Desventajas
14. Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
15. 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 de computadora.
16. No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.
17. Modelo Típico de Seis Regiones
18. Las regiones de tareas que componen este modelo son:
18.1. Comunicación con el cliente
18.1.1. Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
18.2. Planificación
18.2.1. Las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
18.3. Análisis de riesgos
18.3.1. Las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
18.4. Construcción y adaptación
18.4.1. Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
18.5. Ingeniería
18.5.1. Las tareas requeridas para construir una o más representaciones de la aplicación.
18.6. Evaluación del cliente
18.6.1. Las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.