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 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 como para entenderla 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 nuevas características que se implementarán 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.
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.
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 "claramente fomenta 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 ]
Las pautas que impulsan la implementación y el análisis de software incluyen: [ cita requerida ]
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 la 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]
Ya en 1957, en Los Ángeles, estábamos haciendo desarrollo incremental bajo la dirección de Bernie Dimsdale [en ServiceBureau Corporation de IBM]. Era colega de John von Neumann , así que quizás lo aprendió allí o lo asumió como algo totalmente natural. Recuerdo a Herb Jacobs (principalmente, aunque todos participamos) desarrollando una gran simulación para Motorola, donde la técnica utilizada fue, hasta donde puedo decir...
Elegir el modelo incremental para proyectos con requisitos estables puede generar una ampliación del alcance y una mayor complejidad, mientras que seleccionar el modelo en cascada puede causar rigidez e ineficiencia a la hora de adaptarse a los cambios.
El primer cohete de combustible líquido desarrollado de forma privada que alcanzó con éxito la órbita.
El rápido aumento de alternativas de bajo costo, como el cohete Falcon 9 de SpaceX, ha provocado que el número de lanzamientos de Proton en un año determinado disminuya de ocho o más a solo uno o dos.
Pero SpaceX siempre se consideró una empresa tecnológica, y sus enfrentamientos con la NASA a menudo adoptaron una forma que los desarrolladores informáticos (o cualquiera que estuviera familiarizado con la problemática implementación de healthcare.gov) reconocerían como generacional. SpaceX siguió un proceso de diseño iterativo, mejorando continuamente los prototipos en respuesta a las pruebas. La gestión de productos tradicional exige un plan sólido ejecutado hasta el final, una receta para los sobrecostos.
El anuncio del 13 de abril de ULA de que desarrollaría un cohete denominado Vulcan utilizando un enfoque incremental cuya primera iteración es esencialmente un Atlas 5 equipado con una nueva primera etapa.