Modelo de ciclo de vida en espiral

Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se
repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado
con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la
diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede
ser muchas cosas: requisitos no comprendidos, mal diseo, errores en la
implementacin, etc.
En cada iteracin Boehm recomienda recopilar la siguiente lista de informaciones:
Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios,
etc.
Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se
consideran desde dos puntos de vista
o Caractersticas del producto.
o Formas de gestionar el proyecto.
Restricciones:
o Desde el punto de vista del producto: Interfaces de tal o cual manera,
rendimiento, etc.
o Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
Riesgos: Lista de riesgos identificados.
Resolucin de riesgos: La tcnica ms usada es la construccin de prototipos.
Resultados: Son lo que realmente ha ocurrido despus de la resolucin de
riesgos.
Planes: Lo que se va a hacer en la siguiente fase.
Compromiso: Decisiones de gestin sobre como continuar.
Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente cumple
con los requisitos establecidos, tambin se verifica que funciona correctamente. El
propio cliente evala el producto. No existe una diferencia muy clara entre cuando
termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que
hacer un cambio, este puede consistir en un nuevo ciclo.
Ventajas
No necesita una definicin completa de los requisitos para empezar a
funcionar.
Al entregar productos desde el final de la primera iteracin es ms fcil validar
los requisitos.
El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el
tiempo y recursos invertidos en una iteracin (las anteriores iteraciones estn
bien).
El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en
etapas tempranas hay tiempo de subsanarlos.

Inconvenientes
Es difcil evaluar los riesgos.
Necesita de la participacin continua por parte del cliente.
Cuando se subcontrata hay que producir previamente una especificacin
completa de lo que se necesita, y esto lleva tiempo.
Dnde es adecuado
Sistemas de gran tamao.
Proyectos donde sea importante el factor riesgo.
Cuando no sea posible definir al principio todos los requisitos.
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:
Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral.
La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones,
la radial y la angular:
1. Angular: Indica el avance del proyecto del software dentro de un ciclo.
2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva
iteracin se pasa ms tiempo desarrollando.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por
ejemplo, la creacin de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno de
los aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la
necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.
Tareas
Para cada ciclo habr cuatro actividades:
1. Determinar Objetivos.
2. Anlisis del riesgo.
3. Planificacin.
4. Desarrollar y probar.

Determinar o fijar objetivos
Fijar tambin los productos definidos a obtener: requerimientos,
especificacin, manual de usuario.
Fijar las restricciones.
Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planificacin inicial.
Anlisis del riesgo
Se lleva a cabo el estudio de las causas de las posibles amenazas y probables
eventos no deseados y los daos y consecuencias que stas puedan producir.
Planificar
Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con
las fases siguientes y planificamos la prxima actividad.
Desarrollar, verificar y validar (probar)
Tareas de la actividad propia y de prueba.
Anlisis de alternativas e identificacin resolucin de riesgos.
Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo
para el desarrollo, el que puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. As si por ejemplo si los riesgos en la interfaz de
usuario son dominantes, un modelo de desarrollo apropiado podra ser la
construccin de prototipos evolutivos. Si lo riesgos de proteccin son la
principal consideracin, un desarrollo basado en transformaciones formales
podra ser el ms apropiado.
Inconvenientes
Planificar un proyecto con esta metodologa es a menudo imposible, debido a la
incertidumbre en el nmero de iteraciones que sern necesarias. En este contexto la
evaluacin de riesgos es de la mayor importancia y, para grandes proyectos, dicha
evaluacin requiere la intervencin de profesionales de gran experiencia.
El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus
clasificaciones de MCV.
Modelo de prototipos
El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de
desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los
programas adecuados y no se debe utilizar muchos recursos.
El diseo rpido se centra en una representacin de aquellos aspectos del software
que sern visibles para el cliente o el usuario final. Este diseo conduce a la
construccin de un prototipo, el cual es evaluado por el cliente para una
retroalimentacin; gracias a sta se refinan los requisitos del software que se
desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las
necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda
mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
Etapas
Plan rpido
Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, entrega y retroalimentacin
Comunicacin


Ventajas
Este modelo es til cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida.
Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del
software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debera tomar la interaccin humano-
mquina.

La construccin de prototipos se puede utilizar como un modelo del proceso
independiente, se emplea ms comnmente como una tcnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos del proceso
expuestos. Sin importar la forma en que ste se aplique, el paradigma de construccin
de prototipos ayuda al desarrollador de software y al cliente a entender de mejor
manera cul ser el resultado de la construccin cuando los requisitos estn
satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente ms
profundamente para adquirir el producto.
Inconvenientes
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al
sistema final. A causa de la intencin de crear un prototipo de forma rpida, se
suelen desatender aspectos importantes, tales como la calidad y el mantenimiento
a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez
que el prototipo ha cumplido su funcin. Es frecuente que el usuario se muestre
reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo
convertira en un prototipo evolutivo, pero partiendo de un estado poco
recomendado.
En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar
algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un
lenguaje de programacin incorrecto porque proporcione un desarrollo ms
rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le
llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas
elecciones pasen a formar parte del sistema final...
Conclusiones:
A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser un
paradigma efectivo para la ingeniera del software. La clave es definir las reglas del
juego desde el principio; es decir, el cliente y el desarrollador se deben poner de
acuerdo en:
Que el prototipo se construya y sirva como un mecanismo para la definicin de
requisitos.
Que el prototipo se descarte, al menos en parte.
Que despus se desarrolle el software real con un enfoque hacia la calidad.