Desarrollo de software. Ciclo de vida iterativo incremental
Este modelo de ciclo de vida es el que más de moda se encuentra de un tiempo a esta parte ya que es utilizado en diferentes metodologías relacionadas con la programación extrema y con estrategias ágiles de desarrollo de software.
El concepto es simple, el producto software se desarrolla por incrementos en el que cada iteración (incluida la primera) obtiene una versión funcional del producto, de esta forma el sistema se desarrolla poco a poco y obtiene un feedback continuo por parte del usuario.
En este modelo, en cada incremento se realizan las diferentes etapas de desarrollo de software, empezando por el análisis y terminando con la implantación y aceptación del sistema.
Tiene cierta similitud con el espiral, con la diferencia de que en este caso no se hace hincapié en el análisis de riesgos y si tomamos como referencia la variante Win & Win de Boehm, no tiene explícito el proceso de negociación bajo un prisma Ganar – Ganar entre las diferentes partes implicadas en el proyecto.
Las iteraciones no tienen por qué realizarse de manera secuencial, pudiendo haber varias ejecutándose simultáneamente siempre y cuando no existan incompatibilidades entre ellas (básicamente que se encuentren en fases distintas del proceso de desarrollo).
Este modelo de ciclo de vida es mi favorito, creo en él ya que estoy convencido que es el que más se aproxima a la realidad de un proyecto de desarrollo de software y sus contingencias. Tiene sus inconvenientes, como el hecho de que tal vez obtener una primera versión que se pueda considerar completa del producto puede tardar más en obtenerse y costar más que por ejemplo con un ciclo de vida en cascada, ya que en cada iteración se tiene en cuenta el feedback del usuario por lo que además de nuevas funcionalidades habrá modificaciones sobre lo de desarrollado en iteraciones anteriores.
No quiero decir con esto que el software necesariamente vaya a costar más de esta manera, ya que lo que hace es repercutir en el proceso de desarrollo parte del coste del mantenimiento, que recordemos que un autor como Robert Glass lo estima entre el 40 y el 80% del coste total del software.
Lo que sí se necesita son usuarios involucrados en el proyecto durante bastante tiempo y de manera constante, algo que no siempre es sencillo encontrar.
Pese a que es mi modelo favorito, sí que considero que es interesante tener una visión inicial del producto software más allá de las primeras iteraciones, ya que independientemente de que se definan una serie de metas intermedias creo que es interesante desde el inicio saber más o menos a dónde se quiere llegar.
Pingback: Desarrollo de software. Ciclo de vida RUP (Rational Unified Process) « Jummp's Blog
Pingback: Principio de Pareto y los ciclos de vida iterativos e incrementales « Jummp's Blog
Pingback: Desarrollo de software. La importancia de priorizar adecuadamente las funcionalidades « Jummp
Pingback: Desarrollo de software. Beta perpetua « Jummp
Pingback: Desarrollo de software. Implantación del sistema de información « Jummp
Pingback: RUP (Rational Unified Process) vs Desarrollos ágiles « Jummp
Pingback: Desarrollo de software. Ciclo de vida en cascada o clásico y otros modelos centrados en la documentación « Jummp
Pingback: Desarrollo de software. Jim Highsmith. La necesidad de reducir el tiempo necesario para el paso a producción II « Jummp
Pingback: Desarrollo de software. El analista funcional y el analista orgánico « Jummp
Pingback: Desarrollo de software. Pruebas de regresión « Jummp
Pingback: Desarrollo de software. Programación extrema (eXtreme Programming: XP) « Jummp
Pingback: Desarrollo de software. David Lorge Parnas. Feedback, adaptación y satisfacción del usuario. « Jummp
Pingback: Desarrollo de software. Pruebas de aceptación « Jummp
Pingback: Desarrollo de software. Exceso de frentes abiertos « Jummp
Pingback: Desarrollo de software. Michael Anthony Jackson. Software, percepción, realidad « Jummp
Pingback: Desarrollo de software. Usuarios, producto, evolución « Jummp
Pingback: Desarrollo de software. Objetivos generales sobre intereses particulares de los equipos « Jummp
Pingback: Desarrollo de software. El inicio del proyecto no es la programación « Jummp
Pingback: Desarrollo de software. Lo clásico « Jummp
Pingback: Desarrollo de software. La tendencia del ciclo de vida en cascada a convertirse a iterativo incremental « Jummp
Pingback: Desarrollo de software. Ciclo de vida en cascada vs Metodologías ágiles « Jummp
Pingback: Desarrollo de software. La esencia del desarrollo iterativo incremental « Jummp
Pingback: Desarrollo de software. Jeff Sutherland. Principio de incertidumbre de Scrum « Jummp
Pingback: Desarrollo de software. Jim Highsmith. Metodologías ágiles, anticipación, adaptación « Jummp
Pingback: Desarrollo de software. Daniel McCracken. Michael Anthony Jackson. Requisitos y el cambio de percepción del usuario en el proceso de desarrollo « Jummp
Pingback: Desarrollo de software. ¿De verdad que tenemos en cuenta la incertidumbre y riesgos inherentes a un proyecto? « Jummp
Pingback: Gestión de proyectos. Migraciones tecnológicas de grandes sistemas « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. El proceso también debe ser flexible « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. Las pérdidas de tiempo « Jummp
Pingback: Desarrollo de software. Crisis, problemas, asumir decisiones, mirar adelante « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. El precio de la calidad del software « Jummp
Pingback: Desarrollo de software. Sun Tzu. La importancia de ir liberando versiones operativas cuanto antes « Jummp
Pingback: Los 25 artículos más leídos de mi blog II « Jummp
Pingback: Desarrollo de software. Avance del proyecto y expectativas « Jummp
Pingback: Desarrollo de software. Antipatrón. Simulacro de incendio « Jummp
Pingback: Desarrollo de software. Enfoques iterativos incrementales y el concepto de proyecto, ¿conflicto? « Jummp
Pingback: Desarrollo de software. La agilidad y el nirvana « Jummp
Pingback: Desarrollo de software. Contratación ágil II « Jummp
Pingback: Desarrollo de software. Contratación ágil I « Jummp
Pingback: Desarrollo de software. La evolución en el enfoque del proceso de desarrollo « Jummp
Pingback: Desarrollo de software. Contratación ágil IV « Jummp
Pingback: Desarrollo de software. Agilidad, orientación al producto y orientación al proyecto « Jummp
Pingback: Desarrollo de software. La agilidad es un paraguas en la tormenta « Jummp
Pingback: Desarrollo de software. Ágil no es lo mismo que iterativo incremental « Jummp
Pingback: Desarrollo de software. Productividad y experiencia de usuario « Jummp
Pingback: Desarrollo de software. Ágil no es lo mismo que iterativo incremental « Desarrollo ágil de software
Pingback: Desarrollo de software. Milt Bryce. Especificaciones y comprensión del problema « Jummp
Pingback: Desarrollo de software. Antipatrón. Llave en mano « Jummp
Pingback: Desarrollo de software. En un enfoque iterativo incremental también se planifica « Jummp
Pingback: Desarrollo de software. Ben Shneiderman. Se entiende lo que se utiliza « Jummp
Pingback: Desarrollo de software. Jim Horning. El enfoque iterativo incremental o el mantenimiento evolutivo desde otra perspectiva « Jummp
Pingback: Desarrollo de software. ¿Son requisitos o modificaciones? « Jummp
Pingback: Andy Hunt. Enfoque evolutivo y versión final del producto « Jummp
Pingback: Malas entregas condicionan un enfoque iterativo incremental « Jummp
Pingback: Malas entregas condicionan un enfoque iterativo incremental » Yo Evoluciono
Pingback: Desarrollo de software. Los cambios en los requisitos « Jummp
Pingback: Jim Highsmith. Entrega hoy, adapta mañana « Jummp
Pingback: Joel Spolsky. La importancia del paso a producción del producto « Jummp
Pingback: Mike Cohn. El producto equivocado « Jummp
Pingback: Mike Cohn. Enfoque clásico vs Enfoque evolutivo « Jummp
Pingback: Desarrollo de software. El proceso de maduración « Jummp
Pingback: Desarrollo de software. Revisiones, requisitos y feedback. El infinito y más allá. « Jummp
Pingback: Desarrollo de software. La iteración como camino para incrementar el valor del producto « Jummp
Pingback: Desarrollo de software. ¿Plazos o valor? « Jummp
Pingback: Agilidad y documentación « Jummp
Pingback: Desarrollo de software. Incidencias e iteraciones I « Jummp
Pingback: Desarrollo de software. Incidencias e iteraciones II « Jummp
Pingback: Desarrollo de software. La dificultad de salir del enfoque clásico « Jummp
Pingback: Desarrollo de software. La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas I « Jummp
Pingback: Desarrollo de software. La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas II « Jummp
Pingback: Desarrollo de software. La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas III « Jummp
Pingback: Desarrollo de software. Estimaciones y proyecto « Jummp
Pingback: Desarrollo de software. Antipatrón. Síndrome de la última versión « Jummp
Pingback: Desarrollo de software. Antipatrón. El culto a la agenda « Jummp
Pingback: Los 25 artículos más leídos de mi blog III « Jummp
Pingback: Steven Wright. La experiencia suele llegar tarde a la primera cita « Jummp
Pingback: Desarrollo de software. Antipatrón. Modelo en avalancha « Jummp
Pingback: Diferencia entre el ciclo de vida iterativo y el ciclo de vida iterativo incremental « Jummp
Pingback: Desarrollo de software. Antipatrón. Desarrollo a la primera « Jummp
Pingback: Desarrollo de software. Agendas (presupuestos y plazos) « Jummp
Pingback: Desarrollo de software. Bienvenida a los cambios incluso en etapas tardías « Jummp
Pingback: Desarrollo de software. La visión del producto es necesaria pero no requiere una especificación detallada del sistema « Jummp
Pingback: Desarrollo de software. Modelos predictivos o cómo gestionar el desgaste V | Jummp
Pingback: Desarrollo de software. Sprints e implicación | Jummp
Pingback: Desarrollo de software. ¿Qué es un proyecto? | Jummp
Pingback: Desarrollo de software. Evitar la complejidad. Tratamiento a diferentes escalas. | Jummp
Pingback: Cuando la deuda técnica te controla | Jummp
Pingback: Yamamoto Tsunetomo. La intención | Jummp
Pingback: Desarrollo de software. Maleabilidad | Jummp
Pingback: Desarrollo de software. Maleabilidad | StackPointerBlog
Pingback: Desarrollo de software. Sacar requisitos a la superficie | Jummp
Pingback: Desarrollo de software. Software que funciona | Jummp
Pingback: Mary Poppendieck. Tom Poppendieck. Iteración y alternativas | Jummp
Pingback: Desarrollo de software. Se dan por supuestas demasiadas cosas | Jummp
Pingback: Desarrollo de Software – Se dan por supuestas demasiadas cosas | StackPointerBlog
Pingback: Ley de Gall II | Jummp
Pingback: Aplicar prácticas ágiles no convierte a tu proyecto en ágil | Jummp
Pingback: Aplicar prácticas ágiles no convierte a tu proyecto en ágil | StackPointerBlog
Pingback: El analista funcional y el analista orgánico | StackPointerBlog
Pingback: Responsable funcional | Jummp
Pingback: Responsable funcional | StackPointerBlog
Pingback: Barry Boehm. Aconsejando al cliente | Jummp
Pingback: La estrategia o metodología de desarrollo no te ofrece una solución | Jummp
Pingback: La estrategia o metodología de desarrollo no te ofrece una solución | StackPointerBlog
Pingback: Enfoque iterativo incremental y aprendizaje | Jummp
Pingback: Reestructurando el proyecto para gestionar mejor alcance y expectativas | Jummp
Pingback: Desarrollo de software. Muy probablemente las condiciones iniciales van a cambiar | Jummp
Pingback: Los 25 artículos más leídos de mi blog IV | Jummp
Pingback: Desarrollo de software. La descomposición en tareas más simples y los enfoques ágiles | Jummp
Pingback: Desarrollo de software. Expectativas y sorpresas | Jummp
Pingback: Desarrollo de software. Sprints, materia prima y área usuaria | Jummp