Modelo espiral

Este artículo se basa excesivamente en referencias a fuentes primarias . Por favor, mejore este artículo añadiendo fuentes secundarias o terciarias . Buscar fuentes:  «Modelo espiral» – noticias  · periódicos  · libros  · académico  · JSTOR ( febrero de 2017 ) ( Aprenda cómo y cuándo eliminar este mensaje )

El modelo en espiral es un modelo de proceso de desarrollo de software basado en riesgos . Según los patrones de riesgo únicos de un proyecto determinado, el modelo en espiral guía a un equipo para que adopte elementos de uno o más modelos de proceso, como el prototipado incremental , en cascada o evolutivo .

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] para un público más amplio. Estos artículos presentan un diagrama que se ha reproducido en muchas publicaciones posteriores que analizan el modelo en espiral.

En estos primeros artículos se utiliza 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 característica del modelo en espiral, basada en el riesgo, ya está presente:

[L]a subdivisión basada en riesgos de los pasos del modelo en espiral permite que el modelo se adapte a cualquier combinación apropiada de un enfoque orientado a especificaciones, prototipos, simulación, transformación automática u otro enfoque para el desarrollo de software. ^[3]

En publicaciones posteriores, ^[1] Boehm describe el modelo espiral como un "generador de modelos de proceso", donde las decisiones basadas en los riesgos de un proyecto generan un modelo de proceso apropiado para el proyecto. Por lo tanto, los modelos de proceso incrementales, en cascada, de creación de prototipos y otros son casos especiales del modelo 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 siguen una única secuencia en espiral;
• que cada actividad en el diagrama debe realizarse y en el orden indicado.

Si bien estos conceptos erróneos pueden aplicarse a los patrones de riesgo de unos pocos 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 los riesgos relacionados con los usuarios humanos.

Para distinguirlos mejor de los "modelos espirales peligrosos", Boehm enumera seis características comunes a todas las aplicaciones auténticas del modelo espiral. ^{[ cita requerida ]}

Las aplicaciones auténticas del modelo espiral se basan en ciclos que siempre presentan seis características. Boehm ilustra cada una de ellas con un ejemplo de una "espiral parecida a otra peligrosa" que viola la invariante. ^[1]

Definir secuencialmente los artefactos clave para un proyecto a menudo aumenta la posibilidad de desarrollar un sistema que cumpla con las "condiciones de ganancia" de las partes interesadas (objetivos y restricciones).

Este invariante excluye los procesos “peligrosos que imitan la espiral” que utilizan una secuencia de pasos en cascada incrementales en entornos en los que no se aplican los supuestos subyacentes del modelo en cascada. Boehm enumera estos supuestos de la siguiente manera:

1. Los requisitos se conocen de antemano de su implementación.
2. Los requisitos no tienen implicaciones no resueltas de alto riesgo, como riesgos debidos a costos, cronograma, desempeño, seguridad, interfaces de usuario, impactos organizacionales, etc.
3. La naturaleza de los requisitos no cambiará mucho durante el desarrollo o la evolución.
4. Los requisitos son compatibles con las expectativas de todos los actores clave del sistema, incluidos usuarios, clientes, desarrolladores, mantenedores e inversores.
5. Se entiende bien cuál es la arquitectura adecuada para implementar los requisitos.
6. Hay suficiente tiempo en el calendario 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 en cascada se convierte así en un caso especial del modelo en espiral, impulsado por el riesgo.

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

1. Considere las condiciones de ganancia de todas las partes interesadas críticas para el éxito.
2. Identificar y evaluar enfoques alternativos para satisfacer las condiciones de victoria.
3. Identificar y resolver los riesgos que surgen de los enfoques seleccionados.
4. Obtener la aprobación de todas las partes interesadas críticas para el éxito, además del compromiso de continuar con el siguiente ciclo.

Los ciclos de proyecto que omiten o descuidan alguna 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 que "se parecen a espirales peligrosas" 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 satisfacer sus condiciones de éxito.

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 los ciclos de procesos en espiral auténticos, estas decisiones se toman minimizando el riesgo general.

Por ejemplo, invertir tiempo adicional en probar un producto de software suele reducir el riesgo de que el mercado rechace un producto de mala calidad. Sin embargo, el tiempo adicional de prueba puede aumentar el riesgo debido a la entrada temprana de un competidor en el mercado. Desde la perspectiva del modelo en espiral, las pruebas deben realizarse hasta que se minimice el riesgo total, y no más. ^{[ cita requerida ]}

Las "espirales peligrosas similares" que violan esta invariante incluyen procesos evolutivos que ignoran el riesgo debido a problemas de escalabilidad y procesos incrementales que invierten fuertemente en una arquitectura técnica que debe rediseñarse o reemplazarse para dar cabida a futuros incrementos del producto.

Para cualquier artefacto del proyecto (por ejemplo, especificación de requisitos, documento de diseño, plan de pruebas), el equipo del proyecto debe decidir cuánto detalle es suficiente. En los ciclos de procesos en espiral auténticos, estas decisiones se toman minimizando el riesgo general.

Si se considera la especificación de requisitos como ejemplo, el proyecto debería 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 contratista principal y subcontratistas). Por el contrario, el proyecto no debería 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).

La descripción original del modelo espiral de Boehm no incluía ningún hito de proceso. En mejoras posteriores, introduce tres hitos de anclaje que sirven como indicadores de progreso y puntos de compromiso. Estos hitos de anclaje se pueden caracterizar mediante preguntas clave.

1. Objetivos del ciclo de vida. ¿Existe una definición suficiente de un enfoque técnico y de gestión para satisfacer las condiciones de beneficio de todos? Si las partes interesadas están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha superado este hito del LCO. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse con otro ciclo para intentar llegar al "Sí".
2. Arquitectura del ciclo de vida. ¿Existe una definición suficiente del enfoque preferido para satisfacer las condiciones de beneficio de todos y se eliminan o mitigan todos los riesgos significativos? Si las partes interesadas están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha superado este hito del ACV. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse con otro ciclo para intentar llegar al "Sí".
3. Capacidad operativa inicial. ¿Existe suficiente preparación del software, el sitio, los usuarios, los operadores y los encargados del mantenimiento para satisfacer las condiciones de beneficio de todos al lanzar el sistema? Si las partes interesadas están de acuerdo en que la respuesta es "Sí", entonces el proyecto ha superado el hito de la capacidad operativa inicial y se lanza. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse con otro ciclo para intentar llegar al "Sí".

Entre los procesos evolutivos e incrementales que comprometen recursos significativos para implementar una solución con una arquitectura mal definida se encuentran los que violan esta invariante. ^{[ aclaración necesaria ]}

Los tres puntos 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, e IOC marcando el límite entre las fases de Construcción y Transición.

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