Hay diferentes tipos de ciclos de desarrollo involucrados en la creación de software . Estos ciclos tienen en cuenta todas las etapas del diseño de software .
Este ciclo de desarrollo también se utiliza en la industria aeronáutica y espacial para definir sistemas, o subsistemas embarcados o terrestres, incluyan o no TI.
El modelo de cascada se hereda de la industria de la construcción . Este modelo se basa en los siguientes supuestos:
Las fases tradicionales de desarrollo se llevan a cabo simplemente una tras otra, volviendo a las anteriores, incluso al comienzo del ciclo. El proceso de desarrollo mediante un ciclo en cascada ejecuta fases que tienen las siguientes características:
El modelo del ciclo en V fue imaginado para superar el problema de reactividad del modelo en cascada. Este modelo es una mejora del modelo de cascada que permite, en caso de anomalía, limitar el retorno a los pasos anteriores. Las fases del elevador deben devolver información sobre las fases opuestas cuando se detectan fallas para mejorar el software. En proyectos delicados, cada fase comienza con una reunión inicial .
Además, el ciclo V destaca la necesidad de anticipar y preparar durante las etapas descendentes las "expectativas" de las futuras etapas ascendentes: así se definen las expectativas de las pruebas de validación durante las especificaciones, se definen las expectativas de las pruebas unitarias. al diseñar, etc. Se facilita así la revisión del proyecto de cada fase.
El desarrollo toma las diferentes etapas del ciclo V. Implementando sucesivas versiones, el ciclo comienza de nuevo ofreciendo un producto cada vez más completo y robusto.
Sin embargo, el ciclo en espiral pone más énfasis en la gestión de riesgos que el ciclo V. De hecho, el inicio de cada iteración incluye una fase de análisis de riesgos. Esto se hace necesario por el hecho de que, durante un desarrollo cíclico, existe un mayor riesgo de deshacer, durante la iteración, lo que se hizo durante la iteración anterior.
El ciclo semi-iterativo se origina en el trabajo de James Martin publicado a partir de 1989 en varias revistas norteamericanas. Este ciclo de desarrollo se formalizó por completo en 1991 en el libro RAD ( Desarrollo rápido de aplicaciones ). A partir de 1994, el trabajo adicional realizado en Francia (RAD2) y en Inglaterra ( DSDM ) trajo especializaciones a las técnicas básicas iniciales. La adopción por parte de Rational Unified Process y el Unified Process de IBM consagró el clímax de este ciclo, que todavía está vigente en proyectos más grandes.
En el ciclo semi-iterativo, las dos primeras fases clásicas (de arriba hacia abajo , por necesidad) consisten en la expresión de las necesidades y el diseño de la solución. Es durante la tercera y última fase principal, la construcción del producto (de abajo hacia arriba , por la estructura) cuando entra en juego la noción de iteraciones cortas. Fue alrededor de 2001 con la aparición de varios métodos incluyendo ASD, FDD, Crystal, Scrum o programación extrema y visión unificada de los autores en el Agile Manifesto (Agile Manifesto) y la Agile Alliance, ya que el ciclo semi-iterativo se generalizó. Todos los métodos ágiles comienzan con fases secuenciales, cortas pero muy reales, de exploración, arquitectura y planificación. Sin embargo, no se excluye un uso completamente iterativo de estos métodos, que solo se pueden aplicar a proyectos muy pequeños .
Las actividades se separan de los artefactos , siendo un artefacto el producto de una actividad. Así, un ciclo tipo rueda Deming se aplica a la producción de una documentación, un componente, una prueba, etc.
En relación con una actividad de tipo gestión de proyectos, las fases son:
El ciclo iterativo no es una biyección con el ciclo V del tipo:
La diferencia entre un PDCA y una iteración es la duración: debe ser corta y regular, mientras que una rueda de Deming aplicada a una organización de 300 personas lleva varios meses o incluso años.
El ciclo en cascada se origina en la industria pesada. La particularidad de este entorno es que la fase que sigue requiere muchos más recursos que la anterior.
Por ejemplo, para hacer un objeto de plástico ,
Debes saber que para un objeto simple como un vaso de plástico, el diseño es cuestión de unas pocas semanas (unos miles de euros ) mientras que un molde (impresión + carcasa) requiere varios meses de fabricación y varios cientos de miles de euros.
Por lo tanto, en tal contexto, para administrar bien su proyecto , es importante no descuidar la validación de cada paso bajo pena de verlo deslizarse.
Este fenómeno ocurre en proyectos de software que reúnen a decenas o incluso cientos de personas. Las decisiones del equipo de gestión o del arquitecto del proyecto tienen tal impacto en los ingenieros durante tales duraciones que es mejor asegurar la validez de cada paso.
Además, para limitar la entropía (desorden) del sistema constituido por el equipo del proyecto, es necesario formalizar a través de documentos (o incluso herramientas):
En el caso de un proyecto de software que involucra a una docena de personas durante uno o dos años, la configuración ya no es la misma; de hecho, con tales proyectos tenemos:
Además, es posible avanzar hacia los llamados métodos de desarrollo ágiles reduciendo el formalismo y multiplicando el número de ciclos (operación iterativa).