
¿Qué es el modelo espiral?
El modelo espiral es un modelo de desarrollo de software basado en la hipótesis de que el desarrollo de software es un ciclo iterativo que se repite hasta alcanzar los objetivos establecidos. Tiene la capacidad de manejar la gran cantidad de riesgos que pudieran ocurrir al desarrollar cualquier software.
Es uno de los modelos más importantes que apoyan la gestión de riesgos. Como su nombre indica, este modelo se muestra en forma de espiral, donde las diferentes etapas del modelo se distribuyen en diferentes ciclos. El número de ciclos en el modelo no es fijo y puede variar de un proyecto a otro.
Historia del modelo espiral
- Creación. Fue definido por el matemático y profesor de ingeniería de software estadounidense Barry Boehm. Después de presentar su concepto en 1986 para desarrollar aplicaciones complejas, publicó su modelo en 1988 en un marco más completo en su artículo “Un modelo espiral de desarrollo y mejora del software“. Parte de esta publicación representaba gráficamente el modelo espiral, mostrando de manera íntegra cómo se ve el proceso de desarrollo de software en forma de espiral y respaldado por ciclos. Boehm es conocido por sus numerosas contribuciones a la ingeniería de software, como el modelo de costo constructivo (COCOMO), el modelo espiral del proceso de software, el enfoque de la Teoría G (ganar-ganar) para la determinación de requerimientos y gestión del software.
- Alternativa al modelo de cascada. En su publicación, Boehm describía el modelo espiral como una posible alternativa al modelo de cascada previamente establecido, que también servía como base para su práctica. El modelo espiral no fue el primero en plantear el desarrollo cíclico, pero sí fue el primer en explicar por qué la iteración es importante. Como fue previsto originalmente, se ha destinado a proyectos grandes y complejos cuyas iteraciones van típicamente de 6 meses a 2 años. Este modelo no asume que las tareas de desarrollo de software estén diseñadas linealmente, a diferencia del modelo de cascada, sino como tareas iterativas. Este modelo cíclico influyó en la arquitectura de ingeniería de software basada en modelos (MBASE) y en la programación extrema.
Características del modelo espiral
– Control del riesgo. Reconoce explícitamente los riesgos. Por tanto, reduce considerablemente que fallen los proyectos grandes de software, ya que evalúa repetidamente los riesgos y verifica cada vez el producto en desarrollo. Este modelo informático contiene componentes de casi cualquier otro modelo del ciclo de vida del software, como el modelo de cascada, el modelo de creación de prototipos, el modelo iterativo, el modelo evolutivo, etc. Debido a esto, es capaz de manejar casi cualquier tipo de riesgo que por lo general no manejan los otros modelos. Sin embargo, debido a tener tantos componentes, este modelo es mucho más complejo que los demás.
– Descripción de la espiral. Cada giro de la espiral representa un ciclo completo por donde siempre pasan los cuatro cuadrantes, que representan las cuatro etapas del modelo. A medida que aumenta el tamaño de la espiral, también lo hace el progreso ejecutado. Por tanto, las etapas no se ejecutan solo una vez, sino varias veces, en forma de espiral. Aunque esta repetición cíclica hace que el proyecto se acerque lentamente a los objetivos establecidos, se minimiza contundentemente el riesgo de que falle el proceso de desarrollo.
– Genérico. Las cuatro etapas solo implantan los objetivos básicos de un ciclo, pero no tienen que manifestarse en cada ciclo. El orden de cada ciclo tampoco está estrictamente determinado. Por tanto, el modelo se puede combinar en cualquier momento con otros modelos.
– Flexible. Es bastante flexible al realizar por separado para cada fase del proyecto los procesos de definición de objetivos, análisis de riesgos, desarrollo y planificación.
– Metamodelo. Se considera metamodelo por incluir a los demás modelos. Por ejemplo, si la espiral fuera de un solo ciclo representaría al modelo de cascada, ya que incorpora el enfoque gradual de este modelo clásico. También utiliza el enfoque del modelo de creación de prototipos, ya que al comienzo de cada ciclo monta un prototipo para manejar los riesgos. Además, es compatible con el modelo evolutivo, porque las iteraciones de la espiral se pueden considerar niveles evolutivos, a través de los cuales se construye el sistema final.
Etapas del modelo espiral
- Determinar objetivos, alternativas y restricciones. Los requerimientos del sistema se definen con el mayor detalle posible, incluyendo rendimiento, interfaces de hardware/software, indicadores claves de éxito, etc. y se consideran cuáles objetivos se deben asociar con el ciclo actual de desarrollo. Además, se examinan diferentes alternativas para su implementación, como construir vs. comprar, reutilizar componentes existentes o subcontratar, etc. Igualmente, se determinan las restricciones como el costo, cronograma e interfaces, consumo de tiempo, etc.
- Evaluación de riesgos. Se evalúan todas las alternativas propuestas. Los objetivos y restricciones sirven como referencias determinantes para seleccionar la mejor solución. Además, se identifican los riesgos que pueden dificultar el éxito del proyecto, tales como falta de experiencia, nuevas tecnologías, cronogramas ajustados, procesos deficientes, etc., implantando las estrategias más rentables y con menor riesgo. Finalmente, se utilizan métodos como creación de prototipos, simulaciones, modelos analíticos y encuestas de usuarios.
- Desarrollo y prueba. Se realiza todo el desarrollo necesario, utilizando la tecnología y solución seleccionada. Con cada iteración se va creando una mejor versión de la aplicación. Se escribe y se prueba el código real varias veces hasta alcanzar el resultado deseado, que luego servirá como base para futuros pasos del desarrollo.
- Planificación del siguiente ciclo. Al completar un ciclo, se comienza la planificación del siguiente. Esta planificación podría ser seguir normalmente con el proyecto si se alcanzó el objetivo del ciclo, planteándose la definición del próximo objetivo. También podría ser encontrar otras soluciones, si la etapa anterior de desarrollo resultó defectuosa. La estrategia existente podría reemplazarse por una de las alternativas previamente definidas o una nueva. Con esto, se comenzaría un nuevo intento para alcanzar el objetivo dado.
Ejemplo de modelo espiral
El ejército de Estados Unidos adoptó el modelo espiral para el desarrollo y actualización del programa de modernización de los Sistemas de Combates Futuros (SCF).
Lanzado oficialmente en 2003, se preveía que los SCF equiparan a las tropas con vehículos conectados en tiempo real a una red de campos de batalla extraordinariamente rápida y flexible.
El proyecto se dividía en cuatro espirales de desarrollo de unos dos años cada una. La espiral 1 estaba programada que comenzara para 2008 y entregara prototipos para su uso y evaluación.
Tras finalizar la espiral 1, estaba programado comenzar la espiral 2 para 2010. El desarrollo final del producto se tenía previsto entregar para 2015.
En agosto 2005, Boeing anunciaba la finalización del primer hito importante del proyecto, que era la revisión funcional de los sistemas. Boeing y Science Applications International Corporation eran los colíderes del proyecto.
Sin embargo, para octubre de 2005 el Pentágono recomendó retrasar el proyecto debido al alto impacto en los costos por la guerra de Irak y la ayuda por el huracán Katrina.
El proyecto fue cancelado en 2009 después de que surgieron recortes presupuestarios, sin poderse probar los beneficios del modelo espiral en esta misión
Ventajas y desventajas del modelo espiral
Ventajas
- Estructura cíclica. Debido a este tipo de estructura se eliminan tácitamente los problemas entre el diseño y los requerimientos técnicos del software, gracias a las comprobaciones periódicas.
- Gestión de riesgos. Los riesgos se analizan en cada una de las etapas del producto antes de seguir adelante. Esto ayuda a superar o mitigar los posibles riesgos. Todos los colaboradores se benefician de la importancia del análisis de riesgos en este modelo, representando posiblemente su mayor ventaja sobre otros modelos de proceso. La evaluación periódica de los riesgos cobra valor cuando se utilizan entornos técnicos novedosos, que generalmente están asociados con un potencial de riesgo particular debido a la ausencia de valores empíricos.
- Participación y retroalimentación del cliente. En cada etapa del proyecto están involucrados los clientes, hasta completar el proyecto. Por tanto, se pueden reunir diferentes retroalimentaciones para así mejorar la próxima versión del proyecto. Además, se puede obtener retroalimentación en cualquier momento debido al avance en forma de espiral. Así, los clientes y usuarios se pueden integrar desde el principio en el proceso de desarrollo.
- Ideal para proyectos grandes. Es particularmente popular y destacado para proyectos grandes y complejos, donde el control del presupuesto es prioritario para los clientes y desarrolladores. Se tiene un control máximo sobre los costos, recursos y calidad del proyecto de software.
Desventajas
- Costoso. Requiere un alto nivel de experiencia para el análisis de riesgos. Además, los proyectos necesitan mucho tiempo para desarrollarse, lo cual puede aumentar los gastos generales.
- Bastante complejo. Se requiere una gestión previa muy activa y compleja del proyecto, donde se controle y documente cada ciclo de forma continua y cuidadosa. Es comparativamente más complejo que otros modelos, porque hay muchos ciclos, pasando cada uno por las diferentes etapas, aumentando el esfuerzo del proceso de documentación. Resulta esencial tener conocimientos en análisis y gestión de riesgos, que a menudo no están disponibles.
- Gestión del tiempo. Es difícil gestionar el tiempo, ya que se desconoce el número de ciclos. Además, en cualquier momento puede retrasarse el proceso de desarrollo si dentro de un ciclo se deben tomar decisiones importantes o por acciones adicionales al planificar el ciclo siguiente.
- Muchos pasos. No siempre resulta favorable realizar muchos pasos en el desarrollo de software por el hecho de que, a pesar de la versatilidad de las pruebas, pueden llegar al sistema terminado partes sin terminar del programa. En consecuencia, siempre existe el peligro de que cualquier error o inconsistencia conceptual afecte al producto final.
Referencias
- Font, V. The Spiral Model. Recuperado de ultimatesdlc.com.
- Spiral model: the risk-driven software development process model. Recuperado de ionos.com.
- Spiral Model. Recuperado de onestoptesting.com.
- Software Engineering – Spiral Model. Recuperado de geeksforgeeks.org.
- Spiral Model in Software Engineering. Recuperado de medium.com.