2010

Modelo en Espiral
Ingeniería de Software
Modelo de ciclo de vida del software se basa en el análisis de los riesgos que
aparecen a la hora de desarrollar. Modelo de mejora continúa.

John Danilo Sánchez Valencia

UNEMI
28/07/2010
 MODELO EN ESPIRAL
INGENIERIA DE SOFTWARE.

La Ingeniería de Software es un conjunto de estrategias que deben realizar los Ingenieros de Sistemas para
la recopilación de los requerimientos, el desarrollo y ejecución para obtener software de calidad.

El software desempeña una función muy importante a nivel global y se ha ido introduciendo en las
diferentes áreas como son: medicina, banca, producción, financieras, investigación, control de tráfico,
meteorología, logística, internet, intranet, etc.

El objetivo de la Ingeniería de Software es aportar con herramientas y procedimientos que apoyan a la

construcción y desarrollo de software para optimizar la calidad y aumentar la productividad y el trabajo a los
ingenieros de software facilitando el control del proceso de desarrollo de software que son suministrados por
el área de desarrollo de las bases para construir software de alta calidad en forma eficiente.

VARIACIONES DE MODELO EN ESPIRAL.

 Modelo de cuatro regiones o Modelo original de Boehm.

 Modelo en espiral típico de seis regiones.
 Modelo en espiral WIN WIN.

MODELO EN ESPIRAL.

El Modelo Evolutivo Espiral fue diseñado por el informático estadounidense Barry Boehm en 1988, este
modelo es utilizado comúnmente en la Ingeniería de Software, el modelo tiene la forma de manera de una
espiral o caracol, atraviesa por cuatro cuadrantes que representan las actividades que se deben cumplir o
elaborar y está compuesto por cuatro actividades que se van a realizar en cada bucle o interacción, la cual
gira en la dirección de las agujas del reloj, y cada vuelta o ciclo tiene dos dimensiones que son:

La Radial.-Mide el avance del proyecto en un ciclo.

La Angular.-Mide el aumento del costo del proyecto en cada bucle que se va dando.
El modelo espiral conocido también como modelo de ciclo de vida del software se basa en el análisis de los
riesgos que aparecen a la hora de desarrollar software, o sea las causas o problemas que se pueden
presentar durante el proceso de la creación de software, de los posibles daños, amenazas y consecuencias
que este podría tener.

El modelo también determina si el proyecto se está desarrollando correctamente, sí hay algo de modificar se
lo realice en el momento oportuno o caso contrario se suspende el desarrollo de dicho proyecto, de esta
manera evita que no se siga gastando, ni empleando recursos en el proyecto.

Este tipo de modelo espiral es muy utilizado para el desarrollo de grandes sistemas como es el desarrollo
de Sistemas Operativos, por ser sistemas altamente complejos en donde la evaluación de riesgos requiere
la intervención de profesionales de gran experiencia.

En cada vuelta o interacción se debe considerar:

 Objetivo
 Alternativas
 Desarrollar y Verificar

Objetivo.- Se establece las necesidades que debe cumplir el software.

Alternativas.- Se define los métodos y técnicas para lograr los objetivos tomando en cuenta la experiencia
del personal, y las formas de gestionar el sistema, los riesgos que pueden ocasionar cada alternativa.

Desarrollar y verificar.-Es la puesta en desarrollo y prueba de software.

El modelo espiral consta de cuatro cuadriculas y las cuales contienen actividades que son:

 Planificación.-Se determinan los objetivos, recopilación de requerimientos, alternativas y

restricciones del proyecto.
 Análisis de Riesgo.-Se analizan las alternativas para identificar cuáles son los riesgos que pueden
ocasionar, y luego poder resolverlo de manera oportuna utilizando métodos y técnicas que se
emplearan para evitarlo.
 Desarrollo y prueba.-Tarea de diseñar, probar, validación del software y proporcionar soporte
técnico al usuario.
 Evaluación.-Se evalúa el proyecto por parte del cliente y se planifica las siguientes actividades o
modificaciones basadas en la opinión del cliente.

MODELO EN ESPIRAL TÍPICO DE SEIS REGIONES.

El modelo está dividido en actividades en marco de trabajo, conocidas como Regiones de Tareas, en
común 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, pequeño 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 técnicos en todas las etapas del proyecto, para
reducirlos antes que sea un verdadero problema.
Las regiones definidas en el modelo son:

 Región 1.-Tareas requerida 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 de los software.
 Región 5.-Tareas para construir la aplicación, instalarla, probarla y proporcionar soporte al usuario
o cliente.
 Región 6.- Tareas para obtener la reacción del cliente, según la evolución de lo creado e instalado
en los ciclos anteriores.

El primero giro de la espiral produce el desarrollo de una especificación del producto, los pasos siguientes
podrían generar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso por la
región de planificación provoca ajustes en el plan del proyecto y por consecuencia aumenta el coste y la
planificación se realimenta en función de la evaluación del cliente. El gestor del proyecto debe ajustar el
número de interacciones requeridas para completar el desarrollo del proyecto.

MODELO EN ESPIRAL WIN-WIN.

En los modelos clásicos surge en la comunicación con los clientes para determinar los requisitos, en este
modelo se basa en la negociación entre el cliente y el desarrollador, se negocia coste frente a
funcionalidades, rendimiento, calidad, etc. Simplemente el gestor del proyecto le pregunta al cliente qué
necesita y él proporciona la información para continuar, pero esto rara vez ocurre.

En otras palabras, se refiere que a la obtención de requisitos requieren de una negociación, que tiene éxito
cuando ambas partes ganan.

Es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane
consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes
habilidades de negociación.
El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de
la espiral; se definen las siguientes actividades:

 Identificación del sistema o subsistemas clave del cliente escogido con interés directo en el
producto, que puede ser premiado por la organización si tiene éxito o criticado si no. (saber qué
quieren).
 Determinación de "condiciones de victoria" de los directivos (saber qué necesitan y los satisface)
 Negociación de las condiciones "victoria" de los directivos para obtener condiciones "Victoria &
Victoria" (negociar para que ambos ganen).

VENTAJAS.

 El análisis de riesgo se lo hace de forma explícita y clara.

 Integra el desarrollo con el mantenimiento de software.etc.
 Mejoras y nuevos requerimientos sin romper la metodología, ya que este ciclo de vida no es rígido ni
estático.
 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 técnico.
 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 reacción mejor ante riesgos en cada uno de los niveles
evolutivos.
 Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de
evolución del producto.
 Mantiene el enfoque del ciclo de vida clásico pero lo incorpora al marco de trabajo interactivo que
refleja un mundo más realista de la naturaleza del proyecto.
 Hace una consideración directa de los riesgos técnicos en todas las etapas del proyecto de tal
manera que si se aplica adecuadamente reduce los riesgos antes de convertirse en problemáticos.
 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 construcción de prototipos en cualquier etapa de
evolución del producto.
 Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
 Reduce los riesgos antes de que se conviertan en problemáticos.
 Es nuevo y no se ha utilizado tanto como otros modelos de ciclo de vida.
 Requiere una considerable habilidad para la evaluación del riesgo, y cuenta con esta habilidad para
el éxito

DESVENTAJAS.

 Genera mucho tiempo en el desarrollo del sistema

 E s un modelo costoso
 Requiere experiencia en la identificación de riesgos
 Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para
el éxito del proyecto.
 Es difícil 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 visión global del problema.
 Aquí nos dice que los prototipos se van validando, lo cual es muy negativo porque como ya se ha
dicho ningún software debe empezar como un prototipo.
 Como es un modelo relativamente nuevo no es muy utilizado como los paradigmas lineales
secuenciales o de construcción de prototipos.
 Debido a su elevada complejidad no se aconseja utilizarlo en sistemas pequeños (sobre-costo de
gestión).