Modelo espiral

Modelo espiral (Boehm, 1988). Varias ideas erróneas se derivan de sobresimplificaciones en este diagrama ampliamente distribuido (hay algunos errores en este diagrama).

El modelo en espiral es un modelo de proceso de desarrollo de software basado en el riesgo. Basado en los patrones de riesgo únicos de un proyecto dado, el modelo en espiral guía a un equipo a adoptar elementos de uno o más modelos de proceso, como prototipos incrementales, en cascada o evolutivos.

Historia

Este modelo fue descrito por primera vez por Barry Boehm en su artículo de 1986, "A Spiral Model of Software Development and Enhancement". En 1988, Boehm publicó un artículo similar para una audiencia más amplia. Estos documentos presentan un diagrama que se ha reproducido en muchas publicaciones posteriores que analizan el modelo en espiral.

Estos primeros documentos 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 otros modelos de procesos. características ya está presente:

[R]isk-driven subsetting of the espiral model steps allows the model to accommodate any appropriate combination of a specification-oriented, prototipo-oriented, simulation-oriented, automatic transformation-oriented, or other approach to software development.

En publicaciones posteriores, Boehm describe el modelo en espiral como un "generador de modelo de proceso", donde las elecciones basadas en los riesgos de un proyecto generan un modelo de proceso apropiado para el proyecto. Por lo tanto, los modelos de proceso incremental, en cascada, de creación de prototipos y otros 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 en espiral original. Él dice que los más peligrosos de estos conceptos erróneos son:

• que la espiral es simplemente una secuencia de incrementos de cascada;
• que todas las actividades del proyecto siguen una única secuencia espiral;
• que toda actividad en el diagrama debe realizarse, y en el orden mostrado.

Si bien estos conceptos erróneos pueden encajar en 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, este modelo se amplió para incluir los riesgos relacionados con los usuarios humanos.

Para distinguirlos mejor de los "parecidos en espiral peligrosos", Boehm enumera seis características comunes a todas las aplicaciones auténticas del modelo en espiral.

Las seis invariantes del modelo espiral

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 apariencia de espiral" que viola el invariante.

Definir artefactos simultáneamente

La definición secuencial de los artefactos clave para un proyecto a menudo aumenta la posibilidad de desarrollar un sistema que cumpla con las "condiciones ganadoras" (objetivos y limitaciones).

Este invariante excluye los procesos "parecidos a una espiral peligrosa" que utilizan una secuencia de pases de cascada incrementales en entornos en los que no se aplican las suposiciones subyacentes del modelo de cascada. Boehm enumera estos supuestos de la siguiente manera:

1. Los requisitos se conocen antes de la aplicación.
2. Los requisitos no tienen consecuencias no resueltas y de alto riesgo, como los riesgos debido a costos, calendario, desempeño, seguridad, interfaces de usuario, impactos organizativos, etc.
3. La naturaleza de los requisitos no cambiará mucho durante el desarrollo o la evolución.
4. Los requisitos son compatibles con todas las expectativas de los interesados del sistema clave, incluyendo usuarios, clientes, desarrolladores, mantenedores e inversores.
5. La arquitectura adecuada para la implementación de los requisitos es bien comprendida.
6. Hay tiempo suficiente para proceder secuencialmente.

En situaciones en las que se aplican estos supuestos, es un riesgo del proyecto no especificar los requisitos y proceder de forma secuencial. El modelo de cascada se convierte así en un caso especial del modelo en espiral impulsado por el riesgo.

Realizar cuatro actividades básicas en cada ciclo

Este invariante identifica las cuatro actividades que deben ocurrir en cada ciclo del modelo espiral:

1. Considere las condiciones de ganancia de todos los actores críticos del éxito.
2. Identificar y evaluar enfoques alternativos para satisfacer las condiciones de ganancia.
3. Identificar y resolver los riesgos que se derivan del enfoque(es) seleccionado.
4. Obtener la aprobación de todos los interesados críticos de éxito, más el compromiso de proseguir el próximo ciclo.

Los ciclos de proyecto que omiten o reducen 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 riesgosas.

Algunas "peligrosas espirales parecidas" Los procesos violan esta invariante al excluir a las partes interesadas clave de ciertas fases o ciclos secuenciales. Por ejemplo, es posible que no se invite a los encargados del mantenimiento y los administradores del sistema a participar en la definición y el desarrollo del sistema. Como resultado, el sistema corre el riesgo de no cumplir con sus condiciones ganadoras.

El riesgo determina el nivel de esfuerzo

Para cualquier actividad de proyecto (p. ej., 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 más tiempo en probar un producto de software a menudo reduce el riesgo de que el mercado rechace un producto de mala calidad. Sin embargo, el tiempo de prueba adicional podría aumentar el riesgo debido a la entrada anticipada al mercado de un competidor. Desde la perspectiva del modelo en espiral, las pruebas deben realizarse hasta que se minimice el riesgo total y no más.

"Espirales peligrosas parecidas" 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 ser rediseñada o reemplazada para adaptarse a futuros incrementos del producto.

El riesgo determina el grado de detalle

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 un ejemplo, el proyecto debe especificar con precisión aquellas características donde el riesgo se reduce a través de 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 en las que la especificación precisa aumenta el riesgo (por ejemplo, diseños de pantalla gráfica, el comportamiento de los componentes listos para usar).

Usar hitos de puntos de anclaje

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 puntos de anclaje se pueden caracterizar por preguntas clave.

1. Objetivos del ciclo de vida. ¿Hay una definición suficiente de un enfoque técnico y de gestión para satisfacer las condiciones de ganancia de todos? Si los interesados están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha aclarado este hito de la LCO. De lo contrario, el proyecto puede ser abandonado, o los interesados pueden comprometerse a otro ciclo para tratar de llegar a "Sí".
2. Life Cycle Architecture. ¿Hay una definición suficiente del enfoque preferido para satisfacer las condiciones de ganancia de todos, y son todos los riesgos significativos eliminados o mitigados? Si los interesados están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha aclarado este hito de la LCA. De lo contrario, el proyecto puede ser abandonado, o los interesados pueden comprometerse a otro ciclo para tratar de llegar a "Sí".
3. Capacidad operacional inicial. ¿Hay suficiente preparación del software, el sitio, los usuarios, los operadores y los usuarios para satisfacer las condiciones de ganancia de todos lanzando el sistema? Si los interesados están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha aclarado el hito de la COI y es lanzado. De lo contrario, el proyecto puede ser abandonado, o los interesados pueden comprometerse a otro ciclo para tratar de llegar a "Sí".

"Espirales peligrosas parecidas" que violan esta invariante incluyen procesos evolutivos e incrementales que comprometen recursos significativos para implementar una solución con una arquitectura pobremente definida.

Los tres hitos de puntos de anclaje encajan fácilmente en Rational Unified Process (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, e IOC marcando el límite entre las fases de Construcción y Transición.

Enfóquese en el sistema y su ciclo de vida

Esta invariante destaca la importancia del sistema general y las preocupaciones a largo plazo que abarcan todo su ciclo de vida. Excluye "parecidos en espiral peligrosos" que se centran demasiado en el desarrollo inicial del código de software. Estos procesos pueden ser el resultado de seguir enfoques publicados para el análisis y diseño de software estructurado o orientado a objetos, mientras se descuidan otros aspectos de las necesidades del proceso del proyecto.