Desarrollo iterativo e incremental

El 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 ^[1] que se ha sugerido ampliamente para grandes esfuerzos de desarrollo. Por ejemplo, la norma DOD-STD-2167 de 1985 ^[2] 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 un enfoque de 'adquisición evolutiva' o 'construcción incremental'". En software, la relación entre iteraciones e incrementos está determinada por el proceso general de desarrollo de software .

La idea básica detrás de este método es desarrollar un sistema a través de ciclos repetidos (iterativo) y en porciones más pequeñas a la vez (incremental), 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. ^[3]

El procedimiento en sí consta de un paso de inicialización, un paso de iteración y una 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 sencilla como para comprenderla e implementarla fácilmente. 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 como las nuevas características que se implementarán y las áreas de rediseño de la solución existente. La lista de control se revisa constantemente como resultado de la fase de análisis.

Una iteración implica un rediseño y una implementación, que se supone que deben ser simples, directos y modulares, lo que permite el rediseño en esa etapa o como una tarea futura agregada a la lista de control del proyecto. ^{[ aclaración necesaria ]} El nivel de detalle del diseño no está determinado 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 la retroalimentación del usuario y las instalaciones de análisis de programas disponibles. Implica el análisis de la estructura, la modularidad, la usabilidad , la confiabilidad, la eficiencia y el logro de los objetivos. La lista de control del proyecto se modifica a la luz de los resultados del análisis.

El desarrollo incremental divide la funcionalidad del sistema en partes (porciones). En cada parte, se entrega una porción de funcionalidad mediante un trabajo interdisciplinario , desde los requisitos hasta la implementación . El proceso unificado agrupa las partes/iteraciones en fases: inicio, elaboración, construcción y transición.

• El inicio identifica el alcance del proyecto, los requisitos (funcionales y no funcionales) y los riesgos a un alto nivel pero con suficiente detalle como para que se pueda estimar el trabajo.
• Elaboration ofrece una arquitectura funcional que mitiga los principales riesgos y cumple con los requisitos no funcionales.
• La construcción llena progresivamente la arquitectura con código listo para producción, producido 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 una o más iteraciones, que suelen estar limitadas por tiempo en lugar de por características. Los arquitectos y analistas trabajan una iteración antes que los desarrolladores y evaluadores para mantener completa su cartera de trabajo.

En el artículo de Craig Larman y Victor Basili "Iterative and Incremental Development: A Brief History", ^[4] se ofrecen muchos ejemplos de usos tempranos, siendo uno de los primeros el Proyecto Mercury de la NASA de los años 1960 .

Algunos de esos ingenieros de Mercury formaron posteriormente 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 primario, que [ellos] construyeron entre 1977 y 1980. El equipo aplicó IID en una serie de 17 iteraciones a lo largo de 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 del transbordador cambiaron durante el proceso de desarrollo del software". ^[4]

Algunas organizaciones, como el Departamento de Defensa de los EE. UU., tienen preferencia por metodologías iterativas, empezando por la MIL-STD-498, que "incentiva claramente la adquisición evolutiva y la IID".

La Instrucción 5000.2 del Departamento de Defensa publicada en 2000 estableció una clara preferencia por el IID:

Existen dos enfoques para alcanzar la capacidad total: el evolutivo y el de un solo paso [en cascada]. Se prefiere el enfoque evolutivo. … [En este] enfoque, la capacidad final entregada al usuario se divide en dos o más bloques, con incrementos crecientes de capacidad... el desarrollo de software debe seguir un proceso de desarrollo en espiral iterativo en el que las versiones de software en constante expansión se basan en el aprendizaje de desarrollos anteriores. También se puede realizar en fases.

Las revisiones recientes de DoDI 5000.02 ya no hacen referencia al "desarrollo en espiral", pero sí abogan por el enfoque general como base para programas de desarrollo y adquisición intensivos en software. ^[5] Además, la Agencia de los Estados Unidos para el Desarrollo Internacional (USAID) también emplea un enfoque de desarrollo iterativo e incremental para 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 centra en incorporar estrategias de colaboración, aprendizaje y adaptación para iterar y adaptar la programación. ^[6]

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. ^{[ vago ] [7]}

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 sucesivo. El valor comercial se entrega de una sola vez, y solo al final del proyecto, mientras que el retroceso ^{[ aclaración necesaria ]} es posible en un enfoque iterativo. Al comparar los dos enfoques, comienzan a surgir algunos patrones: ^{[ cita requerida ]}

• Participación del usuario : en el modelo en cascada, el usuario participa en dos etapas del modelo, es decir, las pruebas de requisitos y aceptación, y posiblemente la creación de material educativo para el usuario. Mientras que en el modelo incremental, el cliente participa en todas y cada una de las etapas.
• Variabilidad : el software se entrega al usuario solo después de que se completa la etapa de creación del ciclo de vida, para que el usuario pueda realizar pruebas de aceptación. Por otro lado, cada incremento se entrega al usuario y, después de la aprobación del usuario, el desarrollador puede avanzar al siguiente módulo.
• Recursos humanos : En el modelo incremental se requiere potencialmente menos personal en comparación con el modelo en cascada.
• Limitación de tiempo : un producto operativo se entrega después de meses, mientras que en el modelo incremental el producto se entrega al usuario en unas pocas semanas.
• Tamaño del proyecto : el modelo en cascada no es adecuado para proyectos pequeños, mientras que el modelo incremental es adecuado tanto para proyectos pequeños como grandes.

Las pautas que impulsan la implementación y el análisis de software incluyen: ^{[ cita requerida ]}

• Cualquier dificultad en el diseño, codificación y prueba de una modificación debería indicar la necesidad de rediseñarla o recodificarla.
• Las modificaciones deberían encajar fácilmente en módulos aislados y fáciles de encontrar. Si no es así, es posible que sea necesario rediseñarlas.
• Las modificaciones de las tablas deben ser especialmente fáciles de realizar. Si alguna modificación de la tabla no se realiza de forma rápida y sencilla, es recomendable rediseñarla.
• Las modificaciones deberían ser más fáciles de realizar a medida que avanzan las iteraciones. Si no es así, existe un problema básico, como un fallo de diseño o una proliferación de parches .
• Normalmente, los parches deberían permitirse solo durante una o dos iteraciones. Pueden ser necesarios para evitar rediseñar durante una fase de implementación.
• La implementación existente debe analizarse con frecuencia para determinar qué tan bien se ajusta a los objetivos del proyecto.
• Siempre que estén disponibles, se deben utilizar facilidades de análisis de programas para ayudar en el análisis de implementaciones parciales.
• Se debe solicitar y analizar la reacción de los usuarios para detectar indicios de deficiencias en la implementación actual.

Si bien el término desarrollo iterativo e incremental comenzó 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 lanzamiento espacial , con nuevas fuerzas competitivas sustanciales en juego provocadas por una innovación tecnológica más rápida y más amplia impulsada por la formación de empresas privadas que buscan el lanzamiento espacial. Estas empresas, como SpaceX ^[8] y Rocket Lab ^[9] , ahora están proporcionando servicios de lanzamiento orbital comercial en la última década, algo que solo seis naciones habían hecho antes de una década atrás ^[10] . Las nuevas innovaciones en los enfoques de desarrollo de tecnología, precios y ofertas de servicios, incluida la capacidad que ha existido solo desde 2016 de volar al espacio en una etapa de refuerzo previamente volada (reutilizable) , reducen aún más el precio de obtener acceso al espacio. ^{[11] [8]}

SpaceX ha sido explícito acerca de su esfuerzo por incorporar prácticas de diseño iterativas 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 operacional. ^[12]

A medida que la industria ha comenzado a cambiar, otros competidores en materia de lanzamiento también están empezando a modificar sus prácticas de desarrollo a largo plazo con las agencias gubernamentales . Por ejemplo, el gran proveedor de servicios de lanzamiento estadounidense United Launch Alliance (ULA) comenzó en 2015 un proyecto de una década de duración para reestructurar su negocio de lanzamiento (reduciendo dos vehículos de lanzamiento a uno) utilizando un enfoque iterativo e incremental para llegar a un sistema de lanzamiento parcialmente reutilizable y de mucho menor costo en la próxima década. ^[13]

This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (September 2010) (Learn how and when to remove this message)

• Dr. Alistair Cockburn (mayo de 2008). "Usando tanto el desarrollo incremental como el iterativo" (PDF) . STSC CrossTalk . 21 (5). Centro de soporte de tecnología de software de la USAF : 27–30. ISSN  2160-1593. Archivado desde el original (PDF) el 2012-05-26 . Consultado el 20 de julio de 2011 .
• Craig Larman, Victor R. Basili (junio de 2003). "Iterative and Incremental Development: A Brief History" (PDF) . IEEE Computer . 36 (6). IEEE Computer Society: 47–56. doi :10.1109/MC.2003.1204375. ISSN  0018-9162. S2CID  9240477. Consultado el 10 de enero de 2009 .