Modelo espiral - Spiral model
.svg)
| Desarrollo de software |
|---|
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 dado, el modelo en espiral guía a un equipo para que adopte 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 artículos presentan un diagrama que se ha reproducido en muchas publicaciones posteriores que discuten el modelo en espiral.
Estos primeros artículos utilizan el término "modelo de proceso" para referirse al modelo en espiral, así como a los enfoques incrementales, en cascada, de creación de prototipos y otros. Sin embargo, la combinación basada en el riesgo característica del modelo en espiral de las características de otros modelos de proceso ya está presente:
El subconjunto impulsado por [R] isk de los pasos del modelo en espiral permite que el modelo se adapte a cualquier combinación apropiada de un 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.
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 espiral original. Dice que los más peligrosos de estos conceptos erróneos son:
- que la espiral es simplemente una secuencia de incrementos en cascada;
- que todas las actividades del proyecto sigan una única secuencia en espiral;
- que todas las actividades del diagrama deben realizarse y en el orden que se muestra.
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, este modelo se amplió para incluir los riesgos relacionados con los usuarios humanos.
Para distinguirlos mejor de los "peligrosos similares a espirales", Boehm enumera seis características comunes a todas las aplicaciones auténticas del modelo en espiral.
Los 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 un "parecido a una espiral peligrosa" que viola el invariante.
Definir artefactos al mismo tiempo
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" de las partes interesadas (objetivos y limitaciones).
Este invariante excluye los procesos de "similitud en espiral peligrosa" que utilizan una secuencia de pasos de cascada incrementales en entornos donde no se aplican los supuestos subyacentes del modelo de cascada. Boehm enumera estos supuestos de la siguiente manera:
- Los requisitos se conocen antes de la implementación.
- Los requisitos no tienen implicaciones no resueltas de alto riesgo, como riesgos debidos al costo, cronograma, desempeño, seguridad, interfaces de usuario, impactos organizacionales, etc.
- La naturaleza de los requisitos no cambiará mucho durante el desarrollo o la evolución.
- Los requisitos son compatibles con las expectativas de todas las partes interesadas del sistema clave, incluidos los usuarios, clientes, desarrolladores, mantenedores e inversores.
- Se comprende bien la arquitectura adecuada para implementar los requisitos.
- Hay suficiente tiempo calendario para proceder secuencialmente.
En situaciones en las que se aplican estos supuestos, es un riesgo del proyecto no especificar los requisitos y proceder secuencialmente. El modelo de cascada se convierte así en un caso especial impulsado por el riesgo del modelo en espiral.
Realiza cuatro actividades básicas en cada ciclo.
Este invariante identifica las cuatro actividades que deben ocurrir en cada ciclo del modelo en espiral:
- Considere las condiciones favorables de todas las partes interesadas críticas para el éxito.
- Identificar y evaluar enfoques alternativos para satisfacer las condiciones ganadoras.
- Identificar y resolver los riesgos que se derivan de los enfoques seleccionados.
- Obtenga la aprobación de todas las partes interesadas fundamentales para el éxito, además del compromiso de continuar con el siguiente ciclo.
Los ciclos de proyectos 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.
Algunos procesos de "similitud en espiral peligrosa" violan este invariante al excluir a las partes interesadas clave de ciertas fases o ciclos secuenciales. Por ejemplo, es posible que no se invite a los administradores y encargados del mantenimiento del sistema a participar en la definición y desarrollo del sistema. Como resultado, el sistema corre el riesgo de no satisfacer sus condiciones ganadoras.
El riesgo determina el nivel de esfuerzo
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 proceso en espiral, estas decisiones se toman minimizando el riesgo general.
Por ejemplo, invertir tiempo adicional para probar un producto de software a menudo reduce el riesgo debido a que el mercado rechaza un producto de mala calidad. Sin embargo, el tiempo de prueba adicional podría aumentar el riesgo debido a la entrada temprana 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.
Las "similitudes en espiral peligrosas" que violan este 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 acomodar incrementos futuros del producto.
El riesgo determina el grado de detalles
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ántos detalles son suficientes. En auténticos ciclos de proceso 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 el riesgo se reduce 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 en las que la especificación precisa aumenta el riesgo (por ejemplo, diseños de pantallas gráficas, el comportamiento de componentes estándar).
Utilice 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.
- Objetivos del ciclo de vida. ¿Existe una definición suficiente de un enfoque técnico y de gestión para satisfacer las condiciones ganadoras de todos? Si las partes interesadas están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha superado este hito de LCO. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse con otro ciclo para intentar llegar al "Sí".
- Arquitectura del ciclo de vida. ¿Existe una definición suficiente del enfoque preferido para satisfacer las condiciones ganadoras de todos y se eliminan o mitigan todos los riesgos importantes? Si las partes interesadas están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha superado este hito de LCA. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse con otro ciclo para intentar llegar al "Sí".
- Capacidad operativa inicial. ¿Existe una preparación suficiente del software, el sitio, los usuarios, los operadores y los encargados del mantenimiento para satisfacer las condiciones de victoria de todos al iniciar el sistema? Si las partes interesadas están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha superado el hito del COI y se pone en marcha. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse con otro ciclo para intentar llegar al "Sí".
Los "similitudes de espirales peligrosas" que violan este invariante incluyen procesos evolutivos e incrementales que comprometen recursos significativos para implementar una solución con una arquitectura mal definida.
Los tres hitos de los puntos de anclaje encajan fácilmente en el Proceso Unificado Racional (RUP), con LCO marcando el límite entre las fases de Incepción 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.
Centrarse en el sistema y su ciclo de vida
Este invariante destaca la importancia del sistema en general y las preocupaciones a largo plazo que abarcan todo su ciclo de vida. Excluye las "simulaciones en espiral peligrosas" 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, mientras se descuidan otros aspectos de las necesidades del proceso del proyecto.