Universidad Católica del Maule

Facultad de Ciencias de la Ingeniería

Escuela de Ingeniería Civil Informática

Modelo Espiral

Integrantes:
Julio Ibarra Leyton
Camilo Rojas Campos
Profesor: Rodrigo Cofré Loyola
Asignatura: Sistemas de Información II
Fecha: 04 – 06 – 2018
 Introducción

El desarrollo de software cuando no es planificado ni se usa una base se vuelve

realmente caótico y, por tanto, muy difícil de manipular. Aquí es cuando cobra una gran
relevancia las metodologías y herramientas para el desarrollo de software, pero… ¿qué es
un método? ¿qué es una metodología? ¿en qué consisten las metodologías de desarrollo
de software? ¿cuántos modelos hay?

Se define un método como un conjunto de herramientas, técnicas y procesos que facilitan

la obtención de un objetivo.

Una metodología hace cierto énfasis al entorno en el cual se plantea y estructura el

desarrollo de un sistema.

Por lo tanto, una metodología de desarrollo de software consiste principalmente en hacer

uso de diversas herramientas, técnicas, métodos y modelos para el desarrollo.
Regularmente este tipo de metodología tiene la necesidad de ir documentada, para que los
programadores que estarán en la planificación del proyecto comprendan la metodología y/o
el ciclo de vida del software que se pretende seguir.

Existe una gran cantidad de metodologías o modelos para el desarrollo, dentro de los cuales
destacan: el modelo cascada, la metodología de prototipo, RUP, modelo espiral, entre
muchos otros. En el trabajo que se presenta a continuación, se pondrá énfasis en el modelo
espiral, el cual en una breve descripción refleja la relación de tareas con prototipos rápidos,
mayor paralelismo y concurrencia en las actividades de diseño y construcción.
 Historia:

Para comenzar, se debe conocer a Barry Boehm quien fue el creador del modelo
espiral. Fue un ingeniero informático estadounidense, quien recibió su grado de Bachelor
of Arts (B.A.) de Harvard en 1957, y sus grados de M.S. y de Ph.D. de UCLA en 1961 y
1964, todo en matemáticas.

Barry era un programador-analista en General Dynamics entre 1955 y 1959, sus intereses
actuales de la investigación incluyen modelar de proceso de software, métrica del software
y los modelos del coste, los ambientes de la tecnología de dotación lógica, y tecnología de
dotación lógica basada en el conocimiento.

Modelo Espiral:

El modelo espiral, propuesto originalmente en 1976 por Barry Boehm como ya se

ha mencionado anteriormente, es un modelo de proceso de software evolutivo donde se
conjuga la naturaleza de construcción de prototipos con los aspectos controlados y
sistemáticos del modelo lineal secuencial.

Proporciona el potencial para el desarrollo rápido de versiones incrementales del software

que no se basa en fases claramente definidas y separadas por un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.

Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un
prototipo, durante las últimas iteraciones se producen versiones cada vez más completas
del sistema diseñado.

Este modelo ha presentado varias modificaciones, dando como resultado tres tipos:

• El modelo original de Boehm.

• Modelo típico de seis regiones.
• Modelo de WINWIN
Representación gráfica de la espiral:

Modelo original de Boehm:

El proceso es representado como una espiral en lugar de una secuencia de

actividades con retrocesos, cada giro en la espiral representa una fase en el proceso, no
hay fases fijas tales como la especificación o diseño (se gira en la espiral dependiendo de
qué se requiere). Los riesgos son explícitamente identificados y resueltos durante el
proceso. Las actividades son:
Determinar objetivos:

o Se identifican objetivos específicos para la fase.

o Fijar los productos definidos a obtener: requerimientos, especificaciones,
manual de usuario.
o Fijar las restricciones.
o Identificación de riesgos del proyecto y estrategias alternativas para
evitarlos.
o Hay una cosa que se realiza solo una vez: planificación inicial o previa.

Análisis del riesgo:

o Los riesgos son identificados y se realizan actividades para reducir riesgos

clave.
o Se estudian todos los riesgos potenciales y se seleccionan una o varias
alternativas propuestas para reducir o eliminar los registros.

Desarrollo, verificar y validar:

o Se escoge un modelo de desarrollo para el sistema que puede ser cualquiera

de los modelos genéricos.
o Identificación de resolución de riesgos.
o Tareas de la actividad propia se prueban.

Planificar:

o Se revisa el proyecto y se planifica la siguiente fase de la espiral.

o Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos
con las siguientes fases y planificamos la próxima actividad.
Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el
exterior), se construyen sucesivas versiones del software, cada vez más completas.
Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y
las restricciones, y se analizan e identifican los riesgos. Si el análisis de riesgo indica que
hay una incertidumbre en lo requisitos, se puede usar la creación de prototipos en el
cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo, como al
cliente. Se pueden usar simulaciones y otros modelos para definir más el problema y refinar
los requisitos.

El cliente evalúa el trabajo de ingeniería (cuadrante de desarrollo y pruebas) y sugiere

modificaciones. En base a los comentarios del cliente se produce la siguiente fase de
planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación
del análisis de riesgo resulta en una decisión de “seguir o no seguir”.

Sin embargo, en la mayoría de los casos, se sigue avanzando alrededor del camino de la
espiral, y ese camino lleva a los desarrolladores hacia afuera, hacia un modelo más
completo del sistema, y al final, al propio sistema operacional. Cada vuelta alrededor de la
espiral requiere ingeniería, que se puede llevar a cabo mediante el enfoque del ciclo de vida
clásico o de la creación de prototipos. Debe tenerse en cuenta que el número de actividades
de desarrollo que ocurren en el cuadrante inferior derecho aumenta al alejarse del centro
de la espiral.

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.
Modelo típico de seis regiones:

Este modelo de ciclo de vida supone una variante del que se basa en cuatro
regiones.

La principal diferencia es que se ha querido dar más relevancia a determinadas tareas

asignándoles una región específica.

En este caso la división es la siguiente:

Comunicación con el cliente:

o Obtención de los objetivos, requisitos y otra información de interés para esta

evolución del sistema.

Planificación:

o Una vez que se conoce a dónde se pretende llegar y desde donde se parte,
es realizada la estimación de tiempo y recursos.
Análisis de riesgo:

o Evaluación de alternativas y selección de la información.

Ingeniería:

o En función de la solución elegida.

o Se completa el análisis y se realiza el diseño del sistema.

Construcción y entrega:

o Construcción del sistema de información.

o Realización de las diversas pruebas.
o Implantación y aceptación del sistema y actividades relacionadas con los
usuarios y la puesta en marcha de aplicaciones y nuevas versiones.

Evaluación del cliente

o El objetivo debe ser la satisfacción del cliente, de los usuarios.

o Se recoge el feedback del usuario respecto al producto visto de una manera
global.
o La retroalimentación servirá de base para la mejora continua del proceso y
del producto.

Conceptualmente, es muy parecido el de Boehm, lo que se ha pretendido con esta variante

es hacer mayor hincapié en determinadas tareas que en el modelo original estaban
englobadas en tareas de mayor peso. Además, la definición de más regiones y la división
de las etapas propias del desarrollo en dos regiones, permite obtener una mayor precisión
en las planificaciones y facilitar el cierre de entregables.
Modelo de WINWIN:

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. Par lograr este
objetivo, el modelo define un conjunto de actividades de negociación al principio de cada
paso alrededor de la espiral.

En sencillas palabras, este modelo requiere fuertes habilidades de negociación para que:

o El cliente gane obteniendo el producto que lo satisfaga.

o El desarrollador gane consiguiendo presupuesto y fecha de entrega realista.

Su representación gráfica:

Se definen las siguientes actividades:

o Identificación del sistema o subsistemas clave de los directivos.

o Determinación de las condiciones de victoria de los directivos.
o Negociación de las condiciones de victoria de lo directivos para reunirlas en un
conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto
de software).
Ventajas y desventajas del modelo espiral:

Ventajas:

• La adaptabilidad en el diseño del modelo espiral en la ingeniería de software se

adapta a cualquier número de cambios, que pueden ocurrir durante cualquier fase
del proyecto.
• Dado que la construcción de prototipos se realiza en pequeños fragmentos o trozos,
la estimación de costos se convierte en fácil y el cliente puede obtener el control
sobre la administración del nuevo sistema.
• En la utilización de grandes sistemas, ha doblado la productividad.
• El modelo espiral permite a quien lo desarrolla aplicar el enfoque de construcción
de prototipos en cualquier etapa de evolución del producto.
• Permite acomodar otros modelos.
• Elimina errores y alternativas no atractivas al comienzo.
• Permite iteraciones, vueltas atrás y finalizaciones rápidas.
• Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan
para el siguiente.

Desventajas:

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

controlable.
• Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
• Requiere experiencia en la identificación de riesgos.
• El modelo trabaja con un protocolo que debe ser seguido correctamente para su
buen funcionamiento. A veces se hace difícil seguir el siguiente protocolo.
• Genera mucho tiempo en el desarrollo del sistema.
Diferencias entre el modelo espiral y modelos tradicionales:

• Identificación de riesgos para cada alternativa desde el comienzo.

• El modelo se adapta a cualquier tipo de actividad adicional.
• Reconocimiento explícito de las diferentes alternativas.

Relación con UML

UML (Unified Modeling Language) es un lenguaje y una metodología adecuada para

modelar el funcionamiento de una empresa, pues permite detectar posibles errores de
concepto y mejoras eventuales de los procesos, y también para diseñar procesos nuevos.

La relación existente, es que UML sigue un ciclo de vida espiral para el modelado, en
contraposición de los ciclos de vida secuenciales clásicos (en los que las tareas de
especificación, análisis, diseño, implementación y mantenimiento se realizan en estricto
orden).

El primer paso consiste en obtener los requerimientos de los procesos rediseñados, que
normalmente se le suministran al equipo de reingeniería (o genera él mismo) en forma de
enunciado. A continuación se realiza el análisis y diseño de estos procesos partiendo de
cero. En esta fase, el equipo puede construir todos los diagramas propuestos en UML, con
los que el proceso queda completamente especificado.
 Conclusión

Los ciclos de vida del software son muy diversos, en la cual, al existir una gran
variedad de estos es importante saber cuál es el que se necesita o se acomoda más en
nuestro proyecto o trabajo.

El modelo espiral posee un enfoque más realista para el desarrollo de software de gran
tamaño y escala. Este modelo utiliza un enfoque evolutivo para la ingeniería, permitiendo
tanto al desarrollador, como al cliente entender y reaccionar a los riesgos de cada nivel.

Es una metodología que necesita seguir correctamente el protocolo establecido, o de lo

contrario se volverá bastante difícil de controlar.

Incorpora objetivos de calidad y gestión de riesgos, además de intentar mejorar aquellos

ciclos de vida clásicos y prototipos.

Es una metodología que tiene poco margen de error, debido a los constantes ciclos con
revisiones que incluyen a los anteriores y planes a seguir en el siguiente.
 Bibliografía

https://okhosting.com/blog/metodologias-del-desarrollo-de-software/#Que_es_un_Metodo

http://modeloespiral.blogspot.cl/

http://lsi.ugr.es/~mvega/docis/espiral.pdf

http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.100/175/A5%20C
ap%C3%ADtulo%202.pdf?sequence=5

https://jummp.wordpress.com/2011/03/29/desarrollo-de-software-ciclo-de-vida-en-espiral-
con-6-regiones/

https://sites.google.com/site/proyectoadpmodelosdedesarrollo/home/modelos-de-
desarrollo/modelo-espiral-ventajas-y-desventajas