CAPITULO II

EL MODELO EN ESPIRAL

 

Este modelo, propuesto por Bohem en 1988 [BOE88], es un modelo de proceso de software evolutivo que acompaña la naturaleza evolutiva de con los aspectos controlados y sistemáticos del ciclo de vida tradicional. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En este modelo, el sistema 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 de ingeniería del sistema. .

El Modelo en Espiral se divide en un número de actividades estructurales, también llamadas "regiones de tareas" . Generalmente existen entre tres y seis regiones de tareas:

Comunicación con el cliente.- Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc.

Planificación.- Las tareas requeridas para definir recursos, tiempos e información relacionada con el proyecto.

Análisis de riesgos.- Las tareas requeridas para evaluar riesgos técnicos y de gestión.

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 implementada durante la etapa de instalación

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

Cuando empieza este proceso evolutivo, el equipo de trabajo gira alrededor de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce 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 de la región de planificación produce ajustes en el plan del proyecto. . El coste y la planificación se ajustan en función de la evaluación del cliente. Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas para completar el proyecto o el producto software de que se trate.

La siguiente figura muestra gráficamente el Modelo Espiral, para las seis regiones de tareas y suponiendo un proyecto tal que forzosamente requiere iniciar en la conceptualización previa a la vuelta de desarrollo, aún cuando hemos dicho que frecuentemente se puede iniciar desde esta tarea. Asimismo, se presenta la terminación del proyecto en la última vuelta, como mantenimiento del mismo proyecto, pareciese que ahí terminase el ciclo, sin embargo, la vuelta siguiente existe y correspondería al inicio de un nuevo proyecto que puede o no tomar como base el proyecto anterior.

MODELO EN ESPIRAL

 

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software en gran escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el usuario 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 interactivo que refleja mejor el mundo real. El modelo 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. Pero al igual que otros modelos, éste no es la panacéa. Puede resultar difícil convencer a grandes clientes, (particularmente en situaciones bajo contrato) de que el enfoque evolutivo que presenta este modelo es controlable. Requiere una considerable habilidad para la evaluación del riesgo, y de ello depende el éxito.

Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas.

Finalmente, en sÍ mismo, el modelo es relativamente nuevo y no se ha utilizado tanto como otros. Todavía tendrá que pasar muchas pruebas para certificar los beneficios que la utilización de este prometedor modelo parece ofrecer para el desarrollo de sistemas de información.