BIOGRAFIA DEL CREADOR M.E.6.

El creador del modelo en espiral fue Barry Boehm quien recibi su grado de B.A. de
Harvard en 1957, y sus grados de M.S. y de Ph.D. de UCLA en 1961 y 1964, todo en
matemticas.
Entre los aos de 1989 y 1992, sirvi dentro del departamento de ESTADOS UNIDOS de
la defensa (DoD) como director de la oficina de las ciencias y de la tecnologa de la
informacin de DARPA, y como director del software de DDR&E y de la oficina de la
informtica, trabaj en TRW a partir de 1973 a 1989, culminando como principal cientfico
del grupo de los sistemas de la defensa, y en el Rand Corporation a partir de 1959 a
1973, culminando como jefe del departamento de las ciencias de la informacin.
Barry Boehm era un Programador-Analista en General Dynamics entre 1955 y 1959, sus
intereses actuales de la investigacin incluyen modelar de proceso del software,
ingeniera de requisitos del software, las arquitecturas del software, mtrica del software y
los modelos del coste, los ambientes de la tecnologa de dotacin lgica, y tecnologa de
dotacin lgica basada en el conocimiento. Sus contribuciones al campo incluyen el
modelo constructivo del coste (COCOMO), el modelo espiral del proceso del software, el
acercamiento de la teora W (ganar-gane) a la determinacin de la gerencia y de los
requisitos del software y a dos ambientes avanzados de la tecnologa de dotacin lgica:
el sistema y el quantum de la productividad del software de TRW saltan el ambiente.

MODELO ESPIRAL DE 6 REGIONES

DEFINICION:
El Modelo en Espiral es un modelo de proceso de software evolutivo que conjuga la
naturaleza iterativa de construccin de prototipos con los aspectos controlados y
sistemticos del modelo lineal secuencial. Ideal para realizar versiones incrementales de
manera rpida, que no se basa en fases claramente definidas y separadas para crear un
sistema. Se divide en un nmero de actividades de marco de trabajo, tambin llamadas
regiones de tareas, Cada una de las regiones Estn compuestas por un conjunto de
tareas del trabajo llamado conjunto de tareas.
En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.
Durante las primeras iteraciones la versin incremental podra ser un modelo en papel o
un prototipo, durante las ltimas iteraciones se producen versiones cada vez mas
completas del sistema diseado.
Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los
aspectos controlados y sistemticos del Modelo Cascada. Proporciona potencial para
desarrollo rpido de versiones incrementales. En el modelo Espiral el software se
construye en una serie de versiones incrementales. En las primeras iteraciones la versin
incremental podra ser un modelo en papel o bien un prototipo. En las ltimas iteraciones
se producen versiones cada vez ms completas del sistema diseado.
A diferencia del modelo de proceso clsico 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 visin alternativa del modelo en espiral puede ser considerada
examinando el eje de punto de entrada en el proyecto.
El modelo est dividido en actividades en marco de trabajo, conocidas como Regiones de
Tareas, en comn existen entre tres y seis regiones de tareas.
Las actividades para el marco de trabajo son generales y son aplicables en cualquier
proyecto, ya sea grande, mediano, pequeo y no importa si es complejo o no. Las
regiones que definen esas actividades se comprenden un conjunto de tareas de trabajo.

El modelo espiral da un enfoque realista, que evoluciona igual que el software, de manera que se adapta bien
al desarrollo de software, por considerar los riesgos tcnicos en todas las etapas del proyecto, para reducirlos
antes que sea un verdadero.
CICLO DE VIDA

MODELO ESPIRAL PARA EL CICLO DE VIDA DEL SOFTWARE

Las regiones definidas en el modelo de la figura son:
Regin 1 - Tareas requeridas para establecer la comunicacin entre el cliente y el
desarrollador.
Regin 2 - Tareas inherentes a la definicin de los recursos, tiempo y otra informacin
relacionada con el proyecto.
Regin 3 - Tareas necesarias para evaluar los riesgos tcnicos y de gestin del proyecto.
Regin 4 - Tareas para construir una o ms representaciones de la aplicacin software.
Regin 5 - Tareas para construir la aplicacin, instalarla, probarla y proporcionar soporte
al usuario o cliente (Ej. documentacin y prctica).
Regin 6 - Tareas para obtener la reaccin del cliente, segn la evaluacin de lo creado e
instalado en los ciclos anteriores.
Las actividades enunciadas para el marco de trabajo son generales y se aplican a
cualquier proyecto, grande, mediano o pequeo, complejo o no.
Las regiones que definen esas actividades comprenden un conjunto de tareas del
trabajo: ese conjunto s se debe adaptar a las caractersticas del proyecto en particular a
emprender. Ntese que lo listado en los tems de 1 a 6 son conjuntos de tareas, algunas
de las ellas normalmente dependen del proyecto o desarrollo en si. Proyectos pequeos
requieren baja cantidad de tareas y tambin de formalidad. En proyectos mayores o
crticos cada regin de tareas contiene labores de ms alto nivel de formalidad. En
cualquier caso se aplican actividades de proteccin (por ejemplo, gestin de configuracin
del software, garanta de calidad, etc.).
Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniera gira alrededor del espiral
(metafricamente hablando) comenzando por el centro (marcado con en la figura) y en
el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de una
especificacin del producto; los pasos siguientes podran generar un prototipo y
progresivamente versiones ms sofisticadas del software.
Cada paso por la regin de planificacin provoca ajustes en el plan del proyecto; el
coste y planificacin se realimentan en funcin de la evaluacin del cliente. El gestor de
proyectos debe ajustar el nmero de iteraciones requeridas para completar el desarrollo.
El modelo espiral puede ir adaptndose y aplicarse a lo largo de todo el Ciclo de vida del
software (en el modelo clsico, o cascada, el proceso termina a la entrega del software).

Una visin alternativa del modelo puede observarse examinando el eje de punto de
entrada de proyectos. Cada uno de los circulitos () fijados a lo largo del eje representan
puntos de arranque de los distintos proyectos (relacionados); a saber:
Un proyecto de desarrollo de conceptos comienza al inicio de la espiral, hace mltiples
iteraciones hasta que se completa, es la zona marcada con verde.
Si lo anterior se va a desarrollar como producto real, se inicia otro proyecto: Desarrollo
de nuevo Producto. Que evolucionar con iteraciones hasta culminar; es la zona
marcada en color azul.
Eventual y anlogamente se generarn proyectos de mejoras de productos y de
mantenimiento de productos, con las iteraciones necesarias en cada rea (zonas roja y
gris, respectivamente).
Cuando la espiral se caracteriza de esta forma, est operativa hasta que el software se
retira, eventualmente puede estar inactiva (el proceso), pero cuando se produce un
cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo, en
mejora del producto).
El modelo espiral da un enfoque realista, que evoluciona igual que el software; se adapta
muy bien para desarrollos a gran escala.
El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la
evolucin. Mantiene el enfoque clsico (cascada) pero incorpora un marco de trabajo
iterativo que refleja mejor la realidad.
Este modelo requiere considerar riesgos tcnicos en todas las etapas del proyecto;
aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de
Sistemas Operativos (complejos); tambin en sistemas de altos riesgos o crticos (Ej.
navegadores y controladores aeronuticos) y en todos aquellos en que sea necesaria una
fuerte gestin del proyecto y sus riesgos, tcnicos o de gestin.
Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no
se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difcil de
implementar y controlar.
A diferencia del modelo de proceso clsico 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 visin 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:

Comunicacin con el cliente: las tareas requeridas para establecer comunicacin entre
el desarrollador y el cliente.
Planificacin: las tareas requeridas para definir recursos, el tiempo y otras informaciones
relacionadas con el proyecto. Son todos los requerimientos.
Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras
informaciones relacionadas con el proyecto.
Ingeniera: las tareas requeridas para construir una o ms representaciones de la
aplicacin.
Construccin y adaptacin: las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario.
Evaluacin del cliente: las tareas requeridas para obtener la reaccin del cliente segn
la evaluacin de las representaciones del software creadas durante la etapa de ingeniera
e implementacin durante la etapa de instalacin.
En cada vuelta o iteracin hay que tener en cuenta:
Los Objetivos: Que necesidad debe cubrir el producto.
Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde
diferentes puntos de vista como pueden ser:
Caractersticas: experiencia del personal, requisitos a cumplir, etc.
Formas de gestin del sistema.
Riesgo asumido con cada alternativa.
Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades
[editar] 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:
Angular: Indica el avance del proyecto software dentro de un ciclo.
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:

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 o previa.
ANALISIS DEL RIESGO
Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas
propuestas para reducir o eliminar los riesgos. Desarrollar, verificar y validar (probar)
Tareas de la actividad propia y de prueba.
ANALISIS DE ALTERNATIVAS E IDENTIFICACION Y RESOLUCION 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.
PLANIFICAR
Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases
siguientes y planificamos la prxima actividad.
MECANISMOS DE CONTROL
La dimensin radial mide el coste.
La dimensin angular mide el grado de avance del proyecto.
VARIACIONES DEL MODELO EN ESPIRAL
Modelo en Espiral Tpico de seis regiones.
Modelo en espiral WIN WIN.
VENTAJAS
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software
de computadora.
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
construccin de prototipos en cualquier etapa de evolucin del producto.
El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en
todas las etapas del proyecto y si se aplica adecuadamente debe reducir los
riesgos antes de que se conviertan en problemas.

En la utilizacin de grandes sistemas a doblado la productividad.

El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos
de los restantes modelos.
Reduce riesgos del proyecto.
Incorpora objetivos de calidad.
Integra el desarrollo con el mantenimiento, etc.
Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper
con la metodologa, ya que este ciclo de vida no es rgido ni esttico.
El anlisis de riesgo se lo hace de forma explcita y clara.
Integra el desarrollo con el mantenimiento de software.etc.
Mejoras y nuevos requerimientos sin romper la metodologa, ya que este ciclo de
vida no es rgido ni esttico.
Prevenir los errores que se nos pueden presentar en un futuro, lo cual es muy
positivo para poder mejorar la calidad del software.
Utiliza los prototipos para disminuir los riegos desde el punto de vista tcnico.
Si nos tardamos mucho tiempo en pasar a otro nivel superior el proyecto se lo
puede abandonar para no gastar ni tiempo ni dinero en vano.
El desarrollador y el cliente comprenden y reaccin mejor ante riesgos en cada uno
de los niveles evolutivos.
Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en
cualquier etapa de evolucin del producto.
Mantiene el enfoque del ciclo de vida clsico pero lo incorpora al marco de trabajo
interactivo que refleja un mundo ms realista de la naturaleza del proyecto.
Hace una consideracin directa de los riesgos tcnicos en todas las etapas del
proyecto de tal manera que si se aplica adecuadamente reduce los riesgos antes
de convertirse en problemticos.
El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del
software de computadora, no terminal cuando se entrega el software.
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.
Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en
cualquier etapa de evolucin del producto.
Demanda una consideracin directa de los riesgos tcnicos en todas las etapas del
proyecto.
Reduce los riesgos antes de que se conviertan en problemticos.
Es nuevo y no se ha utilizado tanto como otros modelos de ciclo de vida.
Requiere una considerable habilidad para la evaluacin del riesgo, y cuenta con
esta habilidad para el xito.

DESVENTAJAS
Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es
controlable.

Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas.

Genera mucho tiempo en el desarrollo del sistema.
Modelo costoso.
Requiere experiencia en la identificacin de riesgos.
Requiere mucha experiencia y habilidad para la evaluacin de los riesgos, lo cual
es requisito para el xito del proyecto.
Es difcil convencer a los grandes clientes que se podr controlar este enfoque
evolutivo.
Como se va planificando ciclo por ciclo (vuelta por vuelta) no sabemos cuanto
tiempo nos demandar en realizar el software, por lo tanto este modelo no es
recomendable para realizar un proyecto de software bajo contrato.
Al elaborarlo por partes no tenemos una visin global del problema.
Aqu nos dice que los prototipos se van validando, lo cual es muy negativo porque
como ya se ha dicho ningn software debe empezar como un prototipo.
Como es un modelo relativamente nuevo no es muy utilizado como los paradigmas
lineales secuenciales o de construccin de prototipos.
Debido a su elevada complejidad no se aconseja utilizarlo en sistemas pequeos
(sobre-costo de gestin).

PUNTOS FUERTES
Permite el desarrollo de proyectos en donde los objetivos finales estn
perfectamente definidos pero todos los detalles no pueden ser completamente
establecidos al principio.
Es adaptable: algunos de los requerimientos (que no los objetivos) pueden cambiar
durante el ciclo de desarrollo.
Permite la especializacin de los equipos de trabajo.
Apela a una gestin de proyecto ordenada.
Facilita la distribucin de recursos de desarrollo.
Economa: es posible mantener constantes los recursos de desarrollo.
Permite conseguir funcionalidad en etapas tempranas.
PRINCIPIOS BSICOS
Decidir qu problema se quiere resolver antes de viajar a resolverlo.
Examinar tus mltiples alternativas de accin y elegir una de las ms convenientes.
Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer
algo.
No ser tan ingenuo para pensar que el sistema que ests construyendo ser "EL"
sistema que el cliente necesita, y
Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.
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.
El modelo espiral de 6 regiones se utiliza en los siguientes ejemplos:
Navegadores y controladores aeronuticos