Desarrollo iterativo e incremental
Desarrollo iterativo e incremental es cualquier combinación de diseño iterativo o método iterativo y modelo de construcción incremental para el desarrollo.
El uso del término comenzó en el desarrollo de software, con una combinación de larga data de los dos términos iterativo e incremental que ha sido ampliamente sugerida para grandes esfuerzos de desarrollo. Por ejemplo, el DOD-STD-2167 de 1985 menciona (en la sección 4.1.2): "Durante el desarrollo de software, más de una iteración del ciclo de desarrollo de software puede estar en progreso al mismo tiempo." y "Este proceso puede describirse como una 'adquisición evolutiva' o 'construcción incremental' enfoque." En software, la relación entre iteraciones e incrementos está determinada por el proceso general de desarrollo de software.
Resumen
La idea básica detrás de este método es desarrollar un sistema a través de ciclos repetidos (iterativos) y en porciones más pequeñas a la vez (incrementales), lo que permite a los desarrolladores de software aprovechar lo aprendido durante el desarrollo de partes o versiones anteriores del sistema. El aprendizaje proviene tanto del desarrollo como del uso del sistema, donde los posibles pasos clave en el proceso comienzan con una implementación simple de un subconjunto de los requisitos del software y mejoran iterativamente las versiones en evolución hasta que se implementa el sistema completo. En cada iteración, se realizan modificaciones de diseño y se agregan nuevas capacidades funcionales.
El procedimiento en sí consta del paso de inicialización, el paso de iteración y la Lista de control del proyecto. El paso de inicialización crea una versión base del sistema. El objetivo de esta implementación inicial es crear un producto al que el usuario pueda reaccionar. Debe ofrecer una muestra de los aspectos clave del problema y proporcionar una solución que sea lo suficientemente simple para comprender e implementar con facilidad. Para guiar el proceso de iteración, se crea una lista de control del proyecto que contiene un registro de todas las tareas que deben realizarse. Incluye elementos tales como nuevas funciones a implementar y áreas de rediseño de la solución existente. La lista de control se revisa constantemente como resultado de la fase de análisis.
La iteración implica el rediseño y la implementación de la iteración debe ser simple, directa y modular, apoyando el rediseño en esa etapa o como una tarea agregada a la lista de control del proyecto. El nivel de detalle del diseño no está dictado por el enfoque iterativo. En un proyecto iterativo ligero, el código puede representar la principal fuente de documentación del sistema; sin embargo, en un proyecto iterativo crítico se puede utilizar un Documento de diseño de software formal. El análisis de una iteración se basa en los comentarios de los usuarios y las funciones de análisis del programa disponibles. Implica el análisis de la estructura, la modularidad, la facilidad de uso, la fiabilidad, la eficiencia y & consecución de objetivos. La lista de control del proyecto se modifica a la luz de los resultados del análisis.
Fases
El desarrollo incremental divide la funcionalidad del sistema en incrementos (porciones). En cada incremento, se entrega una parte de la funcionalidad a través del trabajo interdisciplinario, desde los requisitos hasta la implementación. El Proceso Unificado agrupa incrementos/iteraciones en fases: inicio, elaboración, construcción y transición.
- Inception identifies project scope, requirements (functional and non-functional) and risks at a high level but in enough detail that work can be estimated.
- La elaboración ofrece una arquitectura de trabajo que mitiga los principales riesgos y cumple los requisitos no funcionales.
- La construcción llena progresivamente la arquitectura con código de producción elaborado a partir del análisis, diseño, implementación y prueba de los requisitos funcionales.
- La transición entrega el sistema al entorno operativo de producción.
Cada una de las fases se puede dividir en 1 o más iteraciones, que generalmente tienen un límite de tiempo en lugar de un recuadro de funciones. Los arquitectos y analistas trabajan una iteración por delante de los desarrolladores y evaluadores para mantener completa su cartera de productos de trabajo.
Uso/Historial
En el artículo de Craig Larman y Victor Basili "Desarrollo iterativo e incremental: una breve historia", uno de los primeros es el Proyecto de la década de 1960 de la NASA. Mercurio.
Algunos de esos ingenieros de Mercury formaron más tarde una nueva división dentro de IBM, donde "otro ejemplo temprano y sorprendente de un gran éxito de IID [fue] el corazón mismo del software del transbordador espacial de la NASA: el sistema de software de aviónica principal, que [ellos] construyeron entre 1977 y 1980. El equipo aplicó IID en una serie de 17 iteraciones durante 31 meses, con un promedio de alrededor de ocho semanas por iteración. Su motivación para evitar el ciclo de vida en cascada fue que los requisitos del programa de transporte cambiaron durante el proceso de desarrollo del software."
Algunas organizaciones, como el Departamento de Defensa de EE. UU., prefieren las metodologías iterativas, comenzando con MIL-STD-498 "que fomenta claramente la adquisición evolutiva y la IID".
La Instrucción 5000.2 del DoD publicada en 2000 establecía una clara preferencia por IID:
Hay dos enfoques, evolutivos y únicos, a plena capacidad. Se prefiere un enfoque evolutivo.... [En este] enfoque, la capacidad máxima entregada al usuario se divide en dos o más bloques, con aumentos de capacidad...El desarrollo de software seguirá un proceso de desarrollo de espiral iterativo en el que las versiones de software en expansión se basan en el aprendizaje desde el desarrollo anterior. También se puede hacer en fases.
Las revisiones recientes de DoDI 5000.02 ya no se refieren a "desarrollo en espiral" pero defienda el enfoque general como base para los programas de adquisición/desarrollo intensivos en software. Además, la Agencia de los Estados Unidos para el Desarrollo Internacional (USAID) también emplea un enfoque de desarrollo iterativo e incremental en su ciclo de programación para diseñar, monitorear, evaluar, aprender y adaptar proyectos de desarrollo internacional con un enfoque de gestión de proyectos que se enfoca en incorporar la colaboración, el aprendizaje y estrategias de adaptación para iterar y adaptar la programación.
Contraste con desarrollo en cascada
La principal causa del fracaso de los proyectos de desarrollo de software es la elección del modelo, por lo que debe hacerse con mucho cuidado.
Por ejemplo, el paradigma de desarrollo en cascada completa los productos de trabajo de todo el proyecto de cada disciplina en un paso antes de pasar a la siguiente disciplina en un paso posterior. El valor comercial se entrega de una vez, y solo al final del proyecto, mientras que el retroceso es posible en un enfoque iterativo. Al comparar los dos enfoques, comienzan a surgir algunos patrones:
- Participación del usuario: En el modelo de cascada, el usuario está involucrado en dos etapas del modelo, es decir, requisitos y pruebas de aceptación, y posiblemente la creación de material educativo del usuario. Mientras que en el modelo incremental, el cliente está involucrado en cada etapa.
- Variabilidad: El software se entrega al usuario sólo después de que se complete la etapa de construcción del ciclo de vida, para las pruebas de aceptación del usuario. Por otro lado, cada aumento se entrega al usuario y después de la aprobación del usuario, se permite al desarrollador avanzar hacia el siguiente módulo.
- Recursos humanos: En el modelo incremental se requieren menos personal en comparación con el modelo de cascada.
- Limitación del tiempo: Un producto operativo se entrega después de meses mientras que en el modelo incremental el producto se da al usuario dentro de unas pocas semanas.
- Tamaño del proyecto: Modelo de cascada no es adecuado para pequeños proyectos, mientras que el modelo incremental es adecuado para pequeños, así como grandes proyectos.
Directrices de implementación
Las pautas que impulsan la implementación y el análisis del software incluyen:
- Cualquier dificultad en el diseño, codificación y prueba de una modificación debe indicar la necesidad de rediseño o recodificación.
- Las modificaciones deben encajar fácilmente en módulos aislados y fáciles de encontrar. Si no lo hacen, es posible que se necesite algún rediseño.
- Las modificaciones a las tablas deben ser especialmente fáciles de hacer. Si cualquier modificación de la tabla no se hace rápida y fácilmente, se indica rediseño.
- Las modificaciones deben ser más fáciles de hacer a medida que avanzan las iteraciones. Si no lo son, hay un problema básico como un defecto de diseño o una proliferación de parches.
- Los parches normalmente deben ser permitidos para existir sólo por una o dos iteraciones. Es posible que sean necesarios parches para evitar rediseños durante una fase de aplicación.
- La implementación existente debe analizarse con frecuencia para determinar qué tan bien mide hasta los objetivos del proyecto.
- Las instalaciones de análisis de programas deben utilizarse siempre que estén disponibles para ayudar en el análisis de las implementaciones parciales.
- La reacción del usuario debe ser solicitada y analizada para indicar deficiencias en la implementación actual.
Uso en hardware y sistemas embebidos
Si bien el término desarrollo iterativo e incremental se inició en la industria del software, muchos esfuerzos de desarrollo de hardware y software integrado utilizan técnicas iterativas e incrementales.
Ejemplos de esto se pueden ver en una serie de industrias. Un sector que recientemente se ha visto sustancialmente afectado por este cambio de pensamiento ha sido la industria de los lanzamientos espaciales, con nuevas fuerzas competitivas sustanciales en el trabajo provocadas por una innovación tecnológica más rápida y más extensa que se ha producido mediante la formación de empresas privadas que persiguen los lanzamientos espaciales. Estas compañías, como SpaceX y Rocket Lab, ahora brindan servicios comerciales de lanzamiento orbital en la última década, algo que solo seis naciones habían hecho antes de hace una década. Nueva innovación en enfoques de desarrollo de tecnología, precios y ofertas de servicios, incluida la capacidad que existe solo desde 2016 para volar al espacio en una etapa de refuerzo (reutilizable) volada anteriormente, lo que reduce aún más el precio de obtener acceso al espacio.
SpaceX ha sido explícito acerca de su esfuerzo por llevar prácticas de diseño iterativo a la industria espacial y utiliza la técnica en naves espaciales, vehículos de lanzamiento, electrónica y aviónica, y operaciones de hardware de vuelo operativo.
A medida que la industria ha comenzado a cambiar, otros competidores de lanzamiento también están comenzando a cambiar sus prácticas de desarrollo a largo plazo con agencias gubernamentales. Por ejemplo, el gran proveedor de servicios de lanzamiento de EE. UU. United Launch Alliance (ULA) inició en 2015 un proyecto de una década para reestructurar su negocio de lanzamiento, reduciendo dos vehículos de lanzamiento a uno, utilizando un enfoque iterativo e incremental para llegar a un modelo parcialmente reutilizable y sistema de lanzamiento mucho más económico durante la próxima década.