Modelo espiral: historia, características, etapas, ejemplo
El modelo espiral es un arquetipo del proceso de desarrollo de aplicaciones. Se basa 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 para brindar soporte a la gestión de riesgos. Como su nombre indica, este modelo se muestra como 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.
Índice del artículo
El modelo espiral 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 el desarrollo de 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 de 1988 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, tales 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.
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 modelo 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 que las ve 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.
Lo que diferencia en gran medida este modelo de los demás modelos de proceso de software es que 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 otros modelos de desarrollo del software.
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 que falle el proceso de desarrollo.
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.
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.
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.
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.
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.
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.
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.
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 que surgieron recortes presupuestarios, sin poderse probar los beneficios del modelo espiral en esta misión
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.
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 tan grande que tiene el 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.
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.
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.
Puede ser bastante costoso, ya que requiere un alto nivel de experiencia para el análisis de riesgos. Además, los proyectos necesitan una gran cantidad de tiempo para desarrollarse, lo cual puede aumentar los gastos generales.
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 así 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.
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.
No siempre resulta favorable realizar muchos pasos en el desarrollo de software por el hecho que, a pesar de la versatilidad de las pruebas, pueden llegar al sistema terminado partes sin terminar del programa.
Como consecuencia, siempre existe el peligro que cualquier error o inconsistencia conceptual afecte al producto final.
- Victor Font Jr (2019). The Spiral Model. The Ultimate Guide to the SDLC. Tomado de: ultimatesdlc.com.
- Ionos (2019). Spiral model: the risk-driven software development process model. Tomado de: ionos.com.
- Techuz (2018). What is Spiral Model? A Simple Explanation of Spiral Software Development Life Cycle (SDLC). Tomado de: techuz.com.
- One Stop Testing (2020). Spiral Model. Tomado de: onestoptesting.com.
- Geeks for Geeks (2020). Software Engineering – Spiral Model. Tomado de: geeksforgeeks.org.
- Chandu (2019). Spiral Model in Software Engineering. Tomado de: medium.com.