Hispanopedia Wiki
Articulo de referencia

Modelo espiral

Modelo espiral (Boehm, 1988). Este diagrama, ampliamente difundido, transmite varias ideas erróneas debido a simplificaciones excesivas y algunos errores. [ 1 ] El modelo espira...

Hispanopedia WikiContenido en espanolLectura gratuita
Modelo espiral (Boehm, 1988). Este diagrama, ampliamente difundido, transmite varias ideas erróneas debido a simplificaciones excesivas y algunos errores. [ 1 ]

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

Historia

Este modelo fue descrito por primera vez por Barry Boehm en su artículo de 1986, «Un modelo espiral de desarrollo y mejora de software». [ 2 ] En 1988, Boehm publicó un artículo similar [ 3 ] dirigido a un público más amplio. Estos artículos presentan un diagrama que se ha reproducido en numerosas publicaciones posteriores que abordan el modelo espiral.

Estos primeros artículos utilizan el término "modelo de proceso" para referirse tanto al modelo espiral como a los enfoques incrementales, en cascada, de creación de prototipos y otros. Sin embargo, la característica del modelo espiral, que combina rasgos de otros modelos de proceso en función del riesgo, ya está presente:

[E]l subconjunto impulsado por el riesgo de los pasos del modelo espiral permite que el modelo se adapte a cualquier combinación apropiada de un enfoque orientado a la especificación, orientado al prototipo, orientado a la simulación, orientado a la 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 mismo. Así, los modelos de proceso incremental, en cascada, de prototipado y otros son casos especiales del modelo espiral que se ajustan a los patrones de riesgo de ciertos proyectos.

Boehm también identifica varias ideas erróneas derivadas de simplificaciones excesivas en el diagrama del modelo espiral original. Afirma que las más peligrosas de estas ideas erróneas 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 cada actividad del diagrama debe realizarse, y en el orden mostrado.

Si bien estas ideas erróneas pueden ajustarse a los patrones de riesgo de algunos proyectos, no son ciertas para la mayoría de ellos.

En un informe del Consejo Nacional de Investigación [ 4 ] este modelo se amplió para incluir riesgos relacionados con los usuarios humanos.

Para distinguirlas mejor de las "espirales peligrosas que se parecen", Boehm enumera seis características comunes a todas las aplicaciones auténticas del modelo espiral.

Los seis invariantes del modelo espiral

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

Definir artefactos simultáneamente

Definir de forma secuencial los elementos clave de un proyecto suele aumentar la posibilidad de desarrollar un sistema que cumpla con las "condiciones de éxito" de las partes interesadas (objetivos y restricciones).

Esta invariante excluye los procesos de “apariencia espiral peligrosa” que utilizan una secuencia de pasadas incrementales en cascada en entornos donde no se aplican los supuestos subyacentes del modelo de cascada. Boehm enumera estos supuestos de la siguiente manera:

  1. Los requisitos se conocen antes de la implementación.
  2. Los requisitos no presentan implicaciones de alto riesgo sin resolver, como riesgos relacionados con el coste, el cronograma, el rendimiento, la seguridad, las interfaces de usuario, el impacto organizativo, 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 todas las partes interesadas clave del sistema, incluidos los usuarios, los clientes, los desarrolladores, los responsables del mantenimiento y los inversores.
  5. La arquitectura adecuada para implementar los requisitos se comprende perfectamente.
  6. Hay tiempo suficiente en el calendario para proceder de forma secuencial.

En situaciones donde se cumplen estos supuestos, no especificar los requisitos y proceder de forma secuencial supone un riesgo para el proyecto. Por lo tanto, el modelo en cascada se convierte en un caso particular del modelo en espiral, condicionado por el riesgo.

Realizar cuatro actividades básicas en cada ciclo.

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

  1. Considere las condiciones de éxito de todas las partes interesadas que son fundamentales para el resultado.
  2. Identificar y evaluar enfoques alternativos para cumplir las condiciones de victoria.
  3. Identificar y resolver los riesgos que se deriven del enfoque o enfoques seleccionados.
  4. Obtener la aprobación de todas las partes interesadas clave para el éxito, además del compromiso de continuar con el siguiente ciclo.

Los ciclos de proyecto que omiten o reducen cualquiera de estas actividades corren el riesgo de desperdiciar esfuerzos al perseguir opciones inaceptables para las partes interesadas clave o demasiado arriesgadas.

Algunos procesos que se asemejan a una espiral peligrosa 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 responsables del mantenimiento y a los administradores del sistema a participar en su definición y desarrollo. Como resultado, el sistema corre el riesgo de no cumplir con sus condiciones de éxito.

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 los ciclos de proceso 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 defectuoso. Sin embargo, un mayor tiempo de prueba podría aumentar el riesgo debido a la entrada temprana de un competidor en el mercado. Desde la perspectiva del modelo espiral, las pruebas deben realizarse hasta que el riesgo total se minimice, y no más.

Entre los "procesos espirales peligrosos similares" que violan esta invariante se incluyen los procesos evolutivos que ignoran el riesgo debido a problemas de escalabilidad, y los procesos incrementales que invierten fuertemente en una arquitectura técnica que debe rediseñarse o reemplazarse para dar cabida a futuras versiones del producto.

El riesgo determina el grado de detalle.

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

Tomando como ejemplo la especificación de requisitos, el proyecto debe especificar con precisión aquellas características donde 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 donde una especificación precisa aumenta el riesgo (por ejemplo, diseños de pantallas gráficas, el comportamiento de componentes comerciales).

Utilice puntos de referencia

La descripción original del modelo espiral de Boehm no incluía hitos del proceso. En refinamientos posteriores, introdujo tres hitos clave que sirven como indicadores de progreso y puntos de compromiso. Estos hitos clave se caracterizan por preguntas fundamentales.

  1. Objetivos del ciclo de vida. ¿Existe una definición suficiente de un enfoque técnico y de gestión que permita satisfacer las condiciones de éxito de todos? Si las partes interesadas coinciden en que la respuesta es "Sí", el proyecto ha superado este hito de los objetivos del ciclo de vida. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse a un nuevo ciclo para intentar alcanzar el objetivo "Sí".
  2. Arquitectura del ciclo de vida. ¿Existe una definición suficiente del enfoque preferido para satisfacer las condiciones de éxito de todos, y se han eliminado o mitigado todos los riesgos significativos? Si las partes interesadas coinciden en que la respuesta es "Sí", el proyecto ha superado este hito de la ACV. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse a un nuevo ciclo para intentar alcanzar el "Sí".
  3. Capacidad Operativa Inicial. ¿Existe suficiente preparación del software, el sitio, los usuarios, los operadores y el personal de mantenimiento para que el lanzamiento del sistema cumpla con las condiciones de éxito de todos? Si las partes interesadas coinciden en que la respuesta es "Sí", el proyecto supera el hito de Capacidad Operativa Inicial y se lanza. De lo contrario, el proyecto puede abandonarse o las partes interesadas pueden comprometerse a un nuevo ciclo para intentar alcanzar la capacidad operativa inicial.

Entre los "procesos espirales peligrosos similares" que violan esta invariante se incluyen los procesos evolutivos e incrementales que destinan recursos significativos a la implementación de 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), donde LCO marca el límite entre las fases de Inicio y Elaboración del RUP, LCA marca el límite entre las fases de Elaboración y Construcción, e IOC marca el límite entre las fases de Construcción y Transición.

Centrarse en el sistema y su ciclo de vida.

Esta invariante resalta la importancia del sistema en su conjunto y las consideraciones a largo plazo que abarcan todo su ciclo de vida. Excluye los procesos que se asemejan a espirales peligrosas y que se centran demasiado en el desarrollo inicial del código de software. Estos procesos pueden derivarse de seguir enfoques publicados para el análisis y diseño de software orientado a objetos o estructurado, descuidando otros aspectos de las necesidades del proceso del proyecto.

Referencias

  1. 1 2 3 Boehm, B. (julio de 2000). "Desarrollo en espiral: experiencia, principios y refinamientos" (PDF) . Informe especial . Software Engineering Institute. CMU/SEI-2000-SR-008.
  2. ↑ Boehm, B (agosto de 1986). "Un modelo espiral de desarrollo y mejora de software". ACM SIGSOFT Software Engineering Notes . 11 (4): 14– 24. doi : 10.1145/12944.12948 . S2CID 207165409 . 
  3. 1 2 Boehm, B (mayo de 1988). "Un modelo espiral de desarrollo y mejora de software" (PDF) . IEEE Computer . 21 (5): 61– 72. doi : 10.1109/2.59 . S2CID 1781829 . Archivado el 6 de marzo de 2023 en Wayback Machine .
  4. ↑ Pew, RW; Mavor, AS, eds. (2007). Integración humano-sistema en el proceso de desarrollo de sistemas: Una nueva perspectiva . Washington, DC: National Academy Press. doi : 10.17226/11893 . ISBN 978-0-309-10720-4.