Modelo en Espiral
El desarrollo en espiral fue propuesto por Barry W. Boehm en su ensayo "A Spiral Model of Software Development and Enhancement." En ese momento, el modelo de desarrollo en cascada prevalecía, por lo que los inconvenientes asociados fueron discutidos con frecuencia.Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial.
Esquema
del Modelo Espiral
Características
En cada giro se construye un nuevo modelo del sistema completo.
Este modelo puede combinarse con otros modelos de proceso de desarrollo.
Mejor modelo para el desarrollo de grandes sistemas.
No hay un número definido de iteraciones.
Las iteraciones debe decidirlas el equipo de gestión de proyecto.
Este es el enfoque más realista actualmente.
Ventajas del Modelo
- Puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
- Es un enfoque realista del desarrollo de sistemas y de software a gran escala.
- 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.
- Utiliza la construcción de prototipos como mecanismo de reducción de riesgos.
- 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 iterativo que refleja de forma más realista el mundo real.
- 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.
Desventajas del Modelo
- Puede resultar difícil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es controlable.
- Requiere una considerable habilidad para la evaluación del riesgo.
- No se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos.
TIPOS
Modelo
winwin
El
modelo en espiral WINWIN de Boehm, define un conjunto de actividades
de negociación al principio de casa paso alrededor de la espiral.
Más que una simple actividad de comunicación con el cliente se
definen las siguientes actividades:
- Identificación del sistema o subsistemas clave de los directivos.
- Determinación de las condiciones de victoria de los directivos.
- Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).
El
modelo en espiral WINWIN introduce tres hitos en el proceso, llamados
puntos de fijación que ayudan a establecer la completitud de un
ciclo alrededor de la espiral y proporcionan hitos de decisión antes
de continuar el proyecto de software.
Modelo
original Boehm
No
hay un número definido de iteraciones. Las iteraciones debe
decidirlas el equipo de gestión de proyecto
Cada
vuelta se divide en 4 sectores:
Planeación:
determinación de los objetivos, alternativas y restricciones
Análisis de riesgo:
análisis de alternativas e identificación/resolución de riesgos
Evaluación:
valoración por parte del cliente de los resultados obtenidos.
El
movimiento de la espiral, ampliando con cada iteración su amplitud
radial, indica que cada vez se van construyendo versiones sucesivas
del software, cada vez más completas.
Uno
de los puntos más interesantes del modelo, es la introducción al
proceso de desarrollo a las actividades de análisis de los riesgos
asociados al desarrollo y a la evaluación por parte del cliente de
los resultados del software.
Modelo
típico de seis regiones
A
diferencia del modelo de proceso clásico 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 visión
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:
Comunicación con el cliente:
las tareas requeridas para establecer comunicación entre el
desarrollador y el cliente.
Planificación:
las tareas requeridas para definir recursos, el tiempo y otras
informaciones relacionadas con el proyecto. Son todos los
requerimientos.
Análisis de riesgos:
las tareas requeridas para evaluar riesgos técnicos y otras
informaciones relacionadas con el proyecto.
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 implementación durante la etapa de
instalación.
No hay comentarios.:
Publicar un comentario