.svg/1280px-Spiral_model_(Boehm,_1988).svg.png)
El modelo en espiral es un modelo de proceso de desarrollo de software basado en riesgos . Basado en los patrones de riesgo únicos de un proyecto determinado, el modelo en espiral guía a un equipo para adoptar elementos de uno o más modelos de procesos, como la creación de prototipos incrementales , en cascada o evolutivos .
Este modelo fue descrito por primera vez por Barry Boehm en su artículo de 1986, "Un modelo en espiral de desarrollo y mejora de software". [2] En 1988, Boehm publicó un artículo similar [3] dirigido a una audiencia más amplia. Estos artículos presentan un diagrama que se ha reproducido en muchas publicaciones posteriores que analizan el modelo en espiral.
Estos primeros artículos utilizan el término "modelo de proceso" para referirse al modelo en espiral, así como a enfoques incrementales, en cascada, de creación de prototipos y otros. Sin embargo, la característica combinación impulsada por el riesgo del modelo en espiral de características de otros modelos de procesos ya está presente:
El subconjunto de pasos del modelo en espiral basado en riesgos permite que el modelo se adapte a cualquier combinación apropiada de enfoque orientado a especificaciones, orientado a prototipos, orientado a simulación, orientado a transformación automática u otro enfoque para el desarrollo de software. [3]
En publicaciones posteriores, [1] Boehm describe el modelo en espiral como un "generador de modelos de procesos", donde las elecciones basadas en los riesgos de un proyecto generan un modelo de proceso apropiado para el proyecto. Por lo tanto, los modelos incremental, en cascada, de creación de prototipos y otros modelos de procesos son casos especiales del modelo en espiral que se ajustan a los patrones de riesgo de ciertos proyectos.
Boehm también identifica una serie de conceptos erróneos que surgen de simplificaciones excesivas en el diagrama del modelo espiral original. Dice que los más peligrosos de estos conceptos erróneos son:
Si bien estos conceptos erróneos pueden ajustarse a los patrones de riesgo de algunos proyectos, no son ciertos para la mayoría de los proyectos.
En un informe del Consejo Nacional de Investigación [4], este modelo se amplió para incluir riesgos relacionados con los usuarios humanos.
Para distinguirlos mejor de los "peligrosos imitadores de espirales", Boehm enumera seis características comunes a todas las aplicaciones auténticas del modelo de espiral. [ cita necesaria ]
Las aplicaciones auténticas del modelo en espiral están impulsadas por ciclos que siempre muestran seis características. Boehm ilustra cada uno con un ejemplo de una "peligrosa espiral parecida" que viola la invariante. [1]
La definición secuencial de los artefactos clave de un proyecto a menudo aumenta la posibilidad de desarrollar un sistema que cumpla con las "condiciones ganadoras" de las partes interesadas (objetivos y limitaciones).
Esta invariante excluye procesos de “espiral peligrosa” que utilizan una secuencia de pasos incrementales en cascada en entornos donde los supuestos subyacentes del modelo en cascada no se aplican. Boehm enumera estos supuestos de la siguiente manera:
En situaciones donde estos supuestos sí se aplican, es un riesgo del proyecto no especificar los requisitos y proceder de manera secuencial. El modelo en cascada se convierte así en un caso especial del modelo en espiral impulsado por el riesgo.
Esta invariante identifica las cuatro actividades que deben ocurrir en cada ciclo del modelo en espiral:
Los ciclos de proyectos que omiten o interrumpen cualquiera de estas actividades corren el riesgo de desperdiciar esfuerzos al buscar opciones que son inaceptables para las partes interesadas clave o que son demasiado arriesgadas.
Algunos procesos que parecen "espirales peligrosas" violan esta invariante al excluir a partes interesadas clave de ciertas fases o ciclos secuenciales. Por ejemplo, es posible que no se invite a los administradores y mantenedores del sistema a participar en la definición y el desarrollo del sistema. Como resultado, el sistema corre el riesgo de no satisfacer sus condiciones de victoria.
Para cualquier actividad del proyecto (por ejemplo, análisis de requisitos, diseño, creación de prototipos, pruebas), el equipo del proyecto debe decidir cuánto esfuerzo es suficiente. En auténticos ciclos de procesos en espiral, estas decisiones se toman minimizando el riesgo general.
Por ejemplo, invertir tiempo adicional en probar un producto de software a menudo reduce el riesgo de que el mercado rechace un producto de mala calidad. Sin embargo, un tiempo de prueba adicional podría aumentar el riesgo debido a la entrada temprana de un competidor al mercado. Desde la perspectiva del modelo en espiral, las pruebas deben realizarse hasta que se minimice el riesgo total, y nada más. [ cita necesaria ]
Las "peligrosas imitaciones de espirales" que violan esta invariante incluyen procesos evolutivos que ignoran el riesgo debido a problemas de escalabilidad y procesos incrementales que invierten mucho en una arquitectura técnica que debe rediseñarse o reemplazarse para adaptarse a futuros incrementos del producto.
Para cualquier artefacto del proyecto (por ejemplo, especificación de requisitos, documento de diseño, plan de prueba), el equipo del proyecto debe decidir cuánto detalle es suficiente. En auténticos ciclos de procesos en espiral, estas decisiones se toman minimizando el riesgo general.
Considerando la especificación de requisitos como ejemplo, el proyecto debe especificar con precisión aquellas características en las que se reduce el riesgo mediante una especificación precisa (por ejemplo, interfaces entre hardware y software, interfaces entre contratistas principales y subcontratistas). Por el contrario, el proyecto no debe especificar con precisión aquellas características donde una especificación precisa aumenta el riesgo (por ejemplo, diseños de pantalla gráfica, el comportamiento de componentes disponibles en el mercado).
La descripción original de Boehm del modelo en espiral no incluía ningún hito del proceso. En refinamientos posteriores, introduce tres hitos de puntos de anclaje que sirven como indicadores de progreso y puntos de compromiso. Estos hitos de los puntos de anclaje pueden caracterizarse por preguntas clave.
Las "peligrosas imitaciones de espirales" que violan esta invariante incluyen procesos evolutivos e incrementales que comprometen importantes recursos para implementar una solución con una arquitectura mal definida. [ se necesita aclaración ]
Los tres hitos del punto de anclaje encajan fácilmente en el Proceso Unificado Racional (RUP), con LCO marcando el límite entre las fases de Inicio y Elaboración de RUP, LCA marcando el límite entre las fases de Elaboración y Construcción, y IOC marcando el límite entre las fases de Construcción y Transición.
Esta invariante resalta la importancia del sistema general y las preocupaciones a largo plazo que abarcan todo su ciclo de vida. Excluye las "peligrosas imitaciones en espiral" que se centran demasiado en el desarrollo inicial del código de software. Estos procesos pueden resultar de seguir enfoques publicados para el análisis y diseño de software estructurado o orientado a objetos, descuidando otros aspectos de las necesidades del proceso del proyecto.