1. UNIVERSIDAD ESTATAL DE MILAGRO
MODELOS DE DESARROLLO DE SOFTWARE
SUBTEMA:
MODELO ESPIRAL
SEMESTRE:
9NO A1 INGENIERÍA EN SISTEMAS
PROFESOR:
MSC. RICHARD RAMÍREZ
ASIGNATURA:
ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS
AUTOR:
LORENA MURILLO YÉPEZ

2. INTRODUCCIÓN:
El Modelo Espiral creado por Barry Boehm, sirve para la construcción de software, basado en el Modelo de
Prototipos que no es más una técnica que nos facilita conocer no los objetivos sino los requisitos del
software de una forma detallada.
Se le llama así porque el sistema se lo desarrolla de esta manera, es decir
PROBLEMAS:
 Demostrarle a cliente que el proceso evolutivo si es manejable
 Se lo cataloga como un modelo muy complejo, y esto hace que sea más difícil darnos cuenta de los
peligros que puedan suceder durante el proceso evolutivo.
En la primera vuelta que se realiza en este modelo definimos los objetivos, examinamos las posibles
consecuencias si aquí nos damos cuenta que las exigencias del cliente no están correctamente
establecidas podemos involucrar aquí al cliente y hacerlo partícipe para que este valore la labor e incluso
indique innovaciones.
Se puede ir viendo un avance tanto del desarrollador como del cliente en cada proceso evolutivo
Si hay algo que no es necesario cuando empezamos a modelar estos pueden ser eliminados
VENTAJAS:
 Aparte del desarrollo, interviene el mantenimiento
 Lo principal es los objetivos de calidad
 Desarrollo no solo del hardware sino también del software
DESVENTAJAS:
 Aún no es muy reconocido por ser nuevo
 Se necesita ser un buen analizador de los riesgos, ya que de esto depende el éxito
 Su costo elevado.
Podemos decir que aunque toma tiempo y es un poco costoso pues lo que se obtiene al final es un producto
de calidad, claro está teniendo los recursos necesarios para su utilización
Podría decirse que el Modelo espiral es el modelo en cascada pero mejorado
A demás debemos recordar que no tenemos que dejar la resolución de los riesgos de desarrollo para el
final
● Antes que nada, detectar las posibles fuentes de riesgo
● Proponer inmediatamente una estrategia de resolución de los riesgos
● La aplicación de estas estrategias podrá llevarnos a:
– Encontrar soluciones viables, ó
– A abandonar el proyecto a tiempo.
Hay tres clases del modelo espiral:
1.-El modelo espiral Win &Win(Victoria y Victoria) que se basa en llenar las expectativas del cliente y del
desarrollador del software, es decir ambas partes ganan. El cliente obtiene el software que necesita y el
usuario obtiene una buena remuneración si el cliente queda satisfecho.
2.-El modelo espiral de 6 regiones:
Debe existir una buena organización de la información que va a ser dada cliente- desarrollador y viceversa,
es decir, debemos ser muy cautelosos porque esta es la base para lograr obtener los resultados esperados.

3. Hacer una precisa proyección de todo lo que vamos a realizar, cada labor, para poder así establecer un
correcto uso del tiempo, de los medios y todo aquello que vamos a utilizar para la elaboración del proyecto
Luego tenemos que hacer otra parte fundamental para que nuestro proyecto no fracase, debemos analizar
todas las posibles amenazas que nos impidan alcanzar los objetivos propuestos, en lo técnico y todo
aquello que se encuentre involucrado con el proyecto.
Tener muy en claro todos los procesos del software, para construirlo de una manera adecuada, como son
los de probar, instalarlo, darle mantenimiento y soporte al usuario. Es utilizado para modelar desarrollos de
grandes sistemas.
Las regiones definidas en el modelo de la figura son:
 Región 1 - Tareas requeridas para establecer la comunicación entre el cliente y el desarrollador.
 Región 2 - Tareas inherentes a la definición de los recursos, tiempo y otra información relacionada
con el proyecto.
 Región 3 - Tareas necesarias para evaluar los riesgos técnicos y de gestión del proyecto.
 Región 4 - Tareas para construir una o más representaciones de la aplicación software.
 Región 5 - Tareas para construir la aplicación, instalarla, probarla y proporcionar soporte al usuario
o cliente (Ej. documentación y práctica).
 Región 6 - Tareas para obtener la reacción del cliente, según la evaluación de lo creado e instalado
en los ciclos
3.-El Modelo espiral de cuatro regiones o modelo original de Boehm:
Muchas veces se puede llegar a confundir el modelo cascada con el modelo espiral pero la diferencia
principal entre el modelo de cascada y el modelo en espiral es que el proyecto del sistema se mueve hacia
la realización ciclo de desarrollo posible, tanto en los modelos, pero en el modelo en espiral de los ciclos
volver varias veces a etapas anteriores en una secuencia repetitiva.
Bohem(1988)examinó el proceso de desarrollo del software a la luz de los riesgos involucrados, sugiriendo
que un modelo en espiral podía combinar las actividades del desarrollo con la gestión del riesgo, para
minimizar y controlar el riesgo.
El modelo en espiral, es en cierto sentido semejante al desarrollo iterativo. Comenzando con los
requerimientos y un plan inicial para el desarrollo (que incluye el presupuesto, las restricciones y las
alternativas para el personal, el diseño y el ambiente de desarrollo) el proceso inserta un paso para evaluar
riesgos y construir prototipos de las alternativas, antes de escribir el “concepto de las operaciones” en un
documento que describe al más alto nivel cómo debe trabajar el sistema.
Desde este documento se especifica un conjunto de requerimientos, que son minuciosamente
inspeccionados para asegurar que sean tan completos y consistentes como sea posible. Así, el concepto de
operaciones es el producto de la primera iteración y los requerimientos son el principal producto de la
segunda. En la tercera iteración y los requerimientos son el principal producto de la segunda. En la tercera
iteración el desarrollo del sistema produce el diseño, y en la cuarta habilita las pruebas.
Con cada iteración, el análisis de riesgos pondera diferentes alternativas a la luz de los requerimientos y
restricciones, y el prototipado verifica el grado de factibilidad o de deseo antes de seleccionar una
alternativa en particular. Cuando se identifican riesgos, los gerentes puedan seleccionar.
Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque
evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán
problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas
lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de
que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.

4. Una visión 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 múltiples
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 análogamente se generarán 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 inactivo (el proceso), pero cuando se produce un cambio el proceso arranca
nuevamente en el punto de entrada apropiado (por ejemplo, en "Mejora del Producto").
Usos:
El modelo espiral se utiliza lo más a menudo posible en proyectos grandes. Para proyectos más pequeños,
el concepto de desarrollo ágil del software se está convirtiendo un alternativa viable. Militares de los
E.E.U.U. ha adoptado el modelo espiral para su Sistemas futuros del combate programa.
Los pasos en el modelo espiral pueden ser generalizados como sigue:
El nuevo requisito del sistema se define en tanto detalle como sea posible. Esto implica generalmente el
entrevistarse con de un número de usuarios que representan todos los usuarios externos o internos y otros
aspectos del sistema existente.
Un diseño preliminar se crea para el nuevo sistema.
Un primer prototipo del nuevo sistema se construye del diseño preliminar. Esto es generalmente un sistema
scaled-down, y representa una aproximación de las características del producto final.
Un segundo prototipo 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 diseñando el segundo prototipo;
construyendo y probando el segundo prototipo.
En la opción del cliente, el proyecto entero puede ser abortado si el riesgo se juzga demasiado grande. Los
factores de riesgo pudieron implicar los sobrantes de coste del desarrollo, cálculo erróneo del funcionar-
coste, o cualquier otro factor que podría, en el juicio del cliente, da lugar a un producto final menos-que-
satisfactorio.
El prototipo existente se evalúa de manera semejante al igual que el prototipo anterior, y, en caso de
necesidad, otro prototipo se desarrolla de él según el procedimiento cuádruple contorneado arriba.
Se iteran los pasos precedentes hasta que el cliente está satisfecho que el prototipo refinado representa el
producto final deseado.
Se construye el sistema final, basado en el prototipo refinado.
El sistema final se evalúa y se prueba a fondo. El mantenimiento general se realiza sobre una base continua
para prevenir faltas en grande y para reducir al mínimo tiempo muerto.
Conclusión:
En conclusión el modelo espiral es una muy buena idea, a pesar de su complejidad, para empresas
grandes que cuentan con los recursos necesarios para implantar un software desarrollado bajo este modelo
ya que este su objetivo principal es la calidad, ya que al final de realizar el modelo sedarán cuenta que si les
convendría invertir en un software que brinde enormes beneficios a toda la organización.
Pero hay una diferencia si hablamos de pequeñas empresas, aquí no es recomendado ya que sería una
pérdida de dinero, y varios recursos para la misma.

5. Este modelo es muy parecido a los anteriores lo nuevo que trae y que lo hace más complicado es un
exhaustivo análisis de riegos en cada avance, y que además aquí el cliente puede intervenir de manera
directa dando sugerencias al modelo.
FUENTES: Internet, libro de Ingeniería de Software (Autor Shari Lawrence Pfleeger)
ANEXOS:
MODELO DE CUATRO REGIONES DE
BOHEM
MODELO ESPIRAL DE SEIS
RIESGOS
MODELO ESPIRAL WIN & WIN