MODELO EN ESPIRAL

1. Historia

El modelo en espiral fue propuesto originalmente en 1986 por Barry Boehm (Ingeniero informático
estadounidense egresado de Harvard en 195, conocido por sus aportes en los campos de modelos
de procesos software, ingeniería de requisitos y arquitecturas de software). Se ha ido desarrollado
distintas variantes del modelo original buscando reflejar de forma más realista el proceso software

2. Introducción

Los modelos de proceso de software son una perspectiva de las actividades que ocurren durante el
diseño y el desarrollo del software, fueron desarrollados debido a la poca fiabilidad histórica en el
resultado de proyectos de desarrollo software, que condujo al interés internacional en aspectos
técnicos y administrativos del desarrollo y mantenimiento de productos software. En particular el
modelo en espiral fue pensado buscando desarrollar la gestión de riesgos, la interacción continúa
entre desarrollador y cliente, y la posibilidad de crear versiones cada vez más completas en base a
prototipos de desarrollo.

3. Definición
El modelo en espiral es un modelo de proceso de software evolutivo que conjuga la naturaleza de
construcción de prototipos (naturaleza iterativa) con los aspectos controlados y sistemáticos del
modelo lineal y secuencial.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Las primeras
iteraciones de la versión incremental se consideran un prototipo, mientras que las últimas iteraciones
producen versiones cada vez más completas del sistema diseñado. Logrando una refinación en el
sistema con cada iteración.

El modelo en espiral se divide (define) en un número de actividades de marco de trabajo (también

llamadas regiones de tareas). Cada una de las regiones está compuestas por un conjunto de tareas
del trabajo llamado conjunto de tareas que se adaptan a las características del proyecto.

4. Características

 Al ser un modelo evolutivo tiene facilidad para adaptarse a la evolución que sufren los
requisitos en función del tiempo.
 El modelo enfatiza fuertemente en la naturaleza iterativa del proceso de desarrollo.
 Proporciona el potencial para el desarrollo rápido de versiones incrementales del software.
 Se dice en espiral porque en el punto donde culmina un esfuerzo de desarrollo, empieza
otro.
 Implementa análisis, reducción y en general gestión de riesgos.
 Su éxito radica en la experiencia del equipo, sus habilidades de trabajo en conjunto, y su
habilidad para detectar y catalogar de forma correcta los riesgos.
 5. Actividades (modelo de Boehm)

El modelo espiral define cuatro actividades principales en cada ejecución del desarrollo. Cabe aclarar
que hay distintas variantes del modelo en espiral, cada una de las cuales define

6. Identificación
En ésta fase se define los objetivos concernientes a la parte del producto que está siendo elaborada
(rendimiento, funcionalidad, adaptación, etc.), posteriormente se identifica las estrategias o
alternativas principales (usar un diseño A o un diseño B, etc.) para la implementación de ésta porción
del producto. Finalmente se estipula las limitaciones o restricciones de cada alternativa (costos,
interfaces, etc.). Por estos dos últimos pasos se dice que implementa gestión y reducción de riesgos.

7. Análisis de riesgo

En este paso se efectúa un análisis detallado de las alternativas planteadas teniendo en cuenta los
objetivos a conseguir y las restricciones impuestas. Buscando identificar áreas de incertidumbre del
proyecto con sus correspondientes riesgos (identificación de riesgos).
Una vez identificados se analiza los riesgos del proyecto a fin de definir estrategias efectivas y viables
(prototipos, simulación, bancos de prueba, etc.) para la reducción de los riesgos identificados.

8. Ingeniería
Según los riesgos y estrategias para su reducción identificadas, se elige un modelo de procesos
adecuado para el desarrollo de todas las tareas requeridas para la construcción del producto
(sistema software). Estas tareas incluyen su desarrollo, verificación y validación (prueba), por ello se
dice que en este paso se realiza toda la parte de la ingeniería. El modelo de procesos software puede
ser uno de los ya definidos, por ejemplo, si los riesgos en la interfaz de usuario son dominantes se
elige un modelo de construcción de prototipos evolutivos, si los riesgos dominantes son de
protección se elige un modelo basado en transformaciones formales, si los riesgos de principal
consideración.
9. Evaluación y planificación
En esta fase se hace una evaluación conjunta entre del producto entre desarrolladores y clientes
(para versiones muy tempranas del producto no es de carácter estricto la evaluación con e cliente).
Tras dicha evaluación se decide si se ha de continuar con un ciclo posterior de la espiral (es decir si
se ha de continuar con el desarrollo del producto); en caso de no haya que continuar el desarrollo
termina la espiral, y en caso de que deba continuar su desarrollo, se planifica la siguiente fase del
proyecto, dando inicio a una nueva espiral.

10. Conclusión modelo en espiral de Boehm

El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez
se van construyendo versiones sucesivas del software, cada vez más completa, pues con cada
iteración se agregan funcionalidades.

Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las
actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente
de los resultados del software.

11. MODELO TIPICO DE SEIS REGIONES

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. Una visión alternativa del modelo en espiral puede ser considerada
examinando el eje de punto de entrada en el proyecto.

Las regiones de tareas que componen este modelo son:

 Comunicación con el cliente: las tareas requeridas para establecer comunicación

entre el desarrollador y el cliente.

 Planificación: las tareas requeridas para definir recursos, el tiempo y otras

informaciones relacionadas con el proyecto. Son todos los requerimientos.

 Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras
informaciones relacionadas con el proyecto.

 Ingeniería: las tareas requeridas para construir una o más representaciones de la

aplicación.

 Construcción y adaptación: las tareas requeridas para construir, probar, instalar y

proporcionar soporte al usuario.

 Evaluación del cliente: 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 instalac
cada uno de los cubos situados a lo largo del eje pueden usarse para representar el punto
de arranque para diferentes tipos de proyecto.

Cada una de las regiones están compuestas por un conjunto de tareas del trabajo, llamado
conjunto de tareas, que se adaptan a las características del proyecto que va a emprenderse.
Para proyectos pequeños, el número de tareas de trabajo y su formalidad es bajo. Para
proyectos mayores y más críticos cada región de tareas contiene tareas de trabajo que se
definen para lograr un nivel más alto de formalidad.

Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor
de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer
circuito de la espiral puede producir el desarrollo de una especificación de productos; los
pasos siguientes en la espiral se podrían utilizar 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 coste y la planificación se ajustan
con la realimentacion 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 de
computadora. Una visión alternativa del modelo en espiral puede ser considerada
examinando el eje de punto de entrada en el proyecto también reflejado en la Figura 2.5.
Cada uno de los cubos situados a lo largo del eje pueden usarse para representar el punto
de arranque para diferentes tipos de proyectos. Un "proyecto de desarrollo de conceptos"
comienza en el centro de la espiral y continuará (aparecen múltiples iteraciones a lo largo
de la espiral que limita la región sombreada central) hasta que se completa el desarrollo del
concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso continúa
a través del cubo siguiente (punto de entrada del proyecto de desarrollo del producto
nuevo) y se inicia un "nuevo proyecto de desarrollo". El producto nuevo evolucionará a
través de iteraciones alrededor de la espiral siguiendo el camino que limita la región algo
más brillante que el centro.En esencia, la espiral, cuando se caracteriza de esta forma,
permanece operativa hasta que el software se retira. Hay veces en que el proceso está
inactivo, pero siempre que se inicie un cambio, el proceso arranca en el punto de entrada
adecuado (por ejemplo: mejora del producto).

El modelo en espiral es 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 riesgos en cada uno de los niveles
evolutivos. El modelo en espiral 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 iterativo 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.

Modelo en espiral winwin

 ¿Qué es?

El modelo en espiral WinWin

Fri, 07/09/2010 - 20:15 — hygorys

Esta es una adaptación del modelo de espiral que se hace hincapié explícitamente situados en la
participación del cliente en un proceso de negociación en la génesis del desarrollo de productos.
Idealmente, el desarrollador simplemente preguntar al cliente lo que se requiere y el cliente
proporcionaría el suficiente detalle para proceder. Por desgracia esto rara vez sucede y
negociaciones significativas entre ambas partes son necesarias para equilibrar la funcionalidad,
rendimiento, etc ... con los costos y de salida al mercado razones de tiempo.

El modelo “win-win”. deriva su nombre del objetivo de estas negociaciones, es decir, de "ganar-
ganar". El cliente recibe el producto que satisface la mayoría de sus necesidades, y el desarrollador
trabaja para alcanzar presupuestos y fechas de entrega. Para lograr este objetivo, el modelo define
un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral.

 Origen:
  Características:

Directivo: es alguien en la organización que tiene un interés directo por el negocio en el sistema o
producto a construir, y puede ser premiado por un resultado con éxito, o criticado si el esfuerzo falla.

1.- Identificar el siguiente nivel para los directivos: Es necesario definir los interlocutores que serán de áreas
que se verán afectadas por el resultado final de la nueva versión. Estos interlocutores serán del área del cliente
(puede haber más de uno) y del proveedor.
2.-Identificar las condiciones de victoria de los directivos: Se concreta cuáles son las condiciones que
requiere cada parte para que se sienta satisfecha una vez realizada esta versión.

3a.- Reunir las condiciones de victoria: Con las etapas anteriores se han definido unos objetivos generales
para la versión y se obtiene conocimiento de los objetivos particulares de cada parte. Ahora toca negociar hasta
dónde realmente se va a llegar y cómo, intentando llegar a una solución en la que todos ganen (cliente y
proveedor).

Las siguientes etapas tienen una correspondencia con algunas variantes, con la versión inicial del ciclo de vida
en espiral:
3b.- Establecer los objetivos, restricciones y alternativas del segundo nivel: Teniendo en cuenta los
objetivos y acuerdos de las fases anteriores, se definirían los requisitos de esta versión, además de
especificarse diversas alternativas en el caso de que existan.

4.- Evaluar las alternativas del producto y del proceso y resolución de riesgos: Se realizaría el análisis
del riesgo típico de los modelos en espiral.

5.- Definir el siguiente nivel del producto y del proceso, incluyendo particiones: Esta etapa completaría el
proceso de análisis y realizaría el diseño y la construcción.
6.- Validar las definiciones del producto y del proceso: Comprendería la implantación y aceptación de la
versión, verificándose si el resultado de la iteración satisface el alcance indicado.

7.- Revisión y comentarios: Tocaría hacer inventario, medir el nivel de satisfacción de las partes, el nivel de
cumplimiento de objetivos con el objetivo sobre todo de intentar aprender de los errores para mejorar en
versiones sucesivas y de detectar correcciones y mejoras a realizar en el producto.

Hitos del proceso (puntos de fijación):

Ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar
el proyecto de desarrollo del software.
Lo más interesante del modelo es que se especifique de forma explícita la necesidad de que las partes negocien
para llegar a un acuerdo satisfactorio para todos, por eso esta variante recibe el nombre de Win Win. Aunque
es complicado alcanzar un equilibrio en el que ambas partes ganen a un 50%, sí que es fundamental que
independientemente de si uno es un poco más ganador que el otro, todas las partes estén convencidas en que
el acuerdo es bueno.

En cualquier caso sigue sin ser absolutamente realista con respecto al transcurso normal de un proyecto de
desarrollo de software, donde la negociación se extiende en muchos proyectos hasta el mismo proceso de
construcción del sistema de información, no obstante, si los incrementos no son muy grandes no tendría por
qué extenderse tanto la negociación, no obstante, como en este tipo de modelos de ciclo de vida, en cada
iteración (incluida la primera) se intenta tener un producto funcionando, salvo que éste sea trivial, las primera
etapa por lo menos tendrá tamaño suficiente para que en muchos casos nos encontremos con casos donde se
estén negociando aspectos del proyecto hasta el final.

Ventajas y desventajas:

Ventajas del modelo en espiral win win

• Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente

comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.

• El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en

cualquier etapa de evolución del producto.

• 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
problemas.

Desventajas del modelo en espiral win win

• Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

 • Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.

VENTAJAS

• Puede adaptarse y aplicarse a lo largo de la vida del software de computadora.

• Mejor reacción entes ante riesgos de desarrolladores y cliente, permitiendo una

interacción constante entre ambos entes en cada uno de los niveles evolutivos.

• Mantiene los pasos sugeridos por el ciclo de vida clásico + al marco de trabajo iterativo
que refleja de forma más realista el mundo real.

• Es un enfoque realista del desarrollo de sistemas y de software a gran escala.

• El desarrollador construye prototipos en cualquier etapa de evolución del producto como

mecanismo de reducción de riesgos.

• reducir los riesgos antes de que se conviertan en problemáticos.

• Incorpora objetivos de calidad

• Integra el desarrollo con el mantenimiento

• No requiere una definición completa de los requerimientos del software a desarrollar para
comenzar su funcionalidad.

• Sufrir retrasos corre un riesgo menor, por que se comprueban los conflictos presentados
tempranamente y existe la forma de poder corregirlos a tiempo.

DESVENTAJAS

• Necesita de mucha habilidad y experiencia al momento de hacer el análisis de riesgos.

• Es nuevo y no se ha utilizado tanto como otros modelo de ciclos de vida.

• Los clientes lo consideran complicado y es difícil convencerlos de que el enfoque evolutivo

es controlable

• No se aconseja utilizarlo en pequeños sistemas.

• Existe complicación cuando se evalúa los riesgos.

• Se requiere la participación continua por parte del cliente.

• Se pierde tiempo al volver producir inicialmente una especificación completa de los
requerimientos cuando se modifica o mejora el software.

ACOPLAMIENTOS DEL MODELO ESPIRAL

Los nuevos requerimientos del sistema se definen en todo los detalles posibles, esto implica
generalmente el entrevistarse con un número determinado de usuarios que representarán a
todos los usuarios tanto externos como internos y otros aspectos del sistema existente. Un
prototipo preliminar se crea para el desarrollo del nuevo software partiendo de un diseño
hecho del sistema que se construyó del prototipo inicial. Esto es generalmente un sistema
scaled-down, y representa una aproximación de las características del producto final. Un
segundo diseño de software es desarrollado por un procedimiento cuádruple:

Evaluación del primer prototipo en términos de sus fuerzas, debilidades, y riesgos;

Definir los requisitos del segundo prototipo;

Planeando y desarrollando el segundo prototipo;

Construyendo y probando el segundo prototipo.

En la opción del cliente, el proyecto completado puede ser abortado si el riesgo se juzga
demasiado grande. Los factores de riesgo pudieron implicar los excesos de coste del
desarrollo, cálculo erróneo del fusionar los costes, o cualquier otro factor que podría, en el
juicio del cliente, dar lugar a un producto final menos que satisfactorio. El diseño existente se
evalúa de manera semejante al igual que el diseño anterior, y, en caso de necesidad, otro
prototipo se desarrolla de él según el procedimiento cuádruple expuesto anteriormente.

Se iteran los pasos precedentes hasta que el cliente está satisfecho sabiendo que el diseño
mejorado representa el producto final deseado. Además, se construye el sistema final, basado
en el diseño mejorado. El sistema final se evalúa y se prueba con todas las de ley. El
mantenimiento general se realiza sobre una base continua para prevenir fallas en grande y
para reducir al mínimo el tiempo perdido.