Desarrollo iterativo y creciente

Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos ms famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es tambin una parte esencial de un tipo de programacin conocido como Extreme Programming y los dems frameworks de desarrollo rpido de software.

Ciclo de vida
La idea principal detrs de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitindole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso son comenzar con una implementacin simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo est implementado. En cada iteracin, se realizan cambios en el diseo y se agregan nuevas funcionalidades y capacidades al sistema. El proceso en s mismo consiste de: Etapa de inicializacin Etapa de iteracin Lista de control de proyecto

Etapa de inicializacin
Se crea una versin del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una solucin lo suficientemente simple para ser comprendida e implementada fcilmente. Para guiar el proceso de iteracin se crea una lista de control de proyecto, que contiene un historial de todas las tareas que necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas, y reas de rediseo de la solucin ya existente. Esta lista de control se revisa peridica y constantemente como resultado de la fase de anlisis.

Etapa de iteracin
Esta etapa involucra el rediseo e implementacin de una tarea de la lista de control de proyecto, y el anlisis de la versin ms reciente del sistema. La meta del diseo e implementacin de cualquier iteracin es ser simple, directa y modular, para poder soportar el rediseo de la etapa o como una tarea aadida a la lista de control de proyecto. El cdigo puede, en ciertos casos, representar la mayor fuente de documentacin del sistema. El anlisis de una iteracin se basa en la retroalimentacin del usuario y

en el anlisis de las funcionalidades disponibles del programa. Involucra el anlisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del proyecto se modifica bajo la luz de los resultados del anlisis. Las guas primarias que guan la implementacin y el anlisis incluyen: Cualquier dificultad en el diseo, codificacin y prueba de una modificacin debera apuntar a la necesidad de redisear o recodificar. Las modificaciones deben ajustarse fcilmente a los mdulos fciles de encontrar y a los aislados. Si no es as, entonces se requiere algn grado de rediseo. Las modificaciones a las tablas deben ser especialmente fciles de realizar. Si dicha modificacin no ocurre rpidamente, se debe aplicar algo de rediseo. Las modificaciones deben ser ms fciles de hacer conforme avanzan las iteraciones. Si no es as, hay un problema primordial usualmente encontrado en un diseo dbil o en la proliferacin excesiva de parches al sistema. Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el rediseo durante una fase de implementacin. La implementacin existente debe ser analizada frecuentemente para determinar que tan bien se ajusta a las metas del proyecto. Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el anlisis de implementaciones parciales. La opinin del usuario debe ser solicitada y analizada para indicar deficiencias en la implementacin referida por l.

Caso prctico
La mejora iterativa fue exitosamente aplicada al desarrollo de una familia extensa de compiladores para una familia de lenguajes de programacin en una gama de arquitecturas de hardware. Un conjunto de 17 versiones del sistema se desarrollaron en un lugar, generando 17 mil lneas de cdigo fuente de lenguaje de alto nivel (6500 de cdigo ejecutable). El sistema posteriormente fue desarrollado en dos sitios diferentes, llegando a dos versiones diferentes del lenguaje base: una versin esencialmente se enfocaba en aplicaciones matemticas, aadiendo nmeros reales y varias funciones matemticas, y la otra se centr en aadir capacidades para escribir del compilador. Cada iteracin fue analizada del punto de vista de los usuarios (las capacidades del lenguaje fueron determinadas en parte por las necesidades del usuario) y el punto de vista del desarrollador (el diseo del compilador evolucion para ser ms fcilmente modificable, por ejemplo, para aadir nuevos tipos de datos). Mediciones tales como acoplamiento y modularizacin fueron seguidas sobre mltiples versiones.

Caractersticas
Usando anlisis y mediciones como guas para el proceso de mejora es una diferencia mayor entre las mejoras iterativas y el desarrollo rpido de aplicaciones, principalmente por dos razones: Provee de soporte para determinar la efectividad de los procesos y de la calidad del producto. Permite estudiar y despus mejorar y ajustar el proceso para el ambiente en particular. Estas mediciones y actividades de anlisis pueden ser aadidas a los mtodos de desarrollo rpido existentes. De hecho, el contexto de iteraciones mltiples conlleva ventajas en el uso de mediciones. Las medidas

a veces son difciles de comprender en lo absoluto, aunque en los cambios relativos en las medidas a travs de la evolucin del sistema puede ser muy informativo porque proveen una base de comparacin. Por ejemplo, un vector de medidas m1, m2,..., mn puede ser definido para caracterizar varios aspectos del producto en cierto punto, como pueden ser el esfuerzo total realizado, los cambios, los defectos, los atributos lgico, fsico y dinmico, consideraciones del entorno, etctera. As el observador puede decir como las caractersticas del producto como el tamao, la complejidad, el acoplamiento y la cohesin incrementan o disminuyen en el tiempo. Tambin puede monitorearse el cambio relativo de varios aspectos de un producto o pueden proveer los lmites de las medidas para apuntar a problemas potenciales y anomalas.

Debilidades de este modelo de desarrollo

Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente no estarn dispuestos a invertir el tiempo necesario. Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente, requiriendo de profesionales sobre el promedio. Sufre fuertes penalizaciones en proyectos en los cuales los requerimientos estn previamente definidos, o para proyectos "todo/nada" en los cuales se requiere que se completen en un 100% el producto para ser implementado (por ejemplo, licitaciones)

MODELOS DE PROCESO ITERATIVOS E INCREMENTALES

La principal caracterstica de estos modelos es que permite crear cada vez versiones ms completas de software, para esto construimos versiones sucesivas de un producto. Se crea una primera versin que es utilizada por el usuario donde se provee retroalimentacin al desarrollador, y segn los requerimientos especificados de ste usuario se crea una segunda versin. Modelo Incremental.Como vimos este era un modelo tipo cascada el cual origina una primera versin con su respectiva funcionalidad, aplicamos de nuevo cascada sobre aquella versin 1 y obtenemos como resultado una versin 2 ms una funcionalidad 2. Este proceso aplicamos cada vez que deseamos crear una versin ms completa segn los requerimientos de nuestro cliente. El modelo incremental se aplica cuando en un proyecto tenemos un tiempo lmite y no disponemos del personal suficiente para que nuestro propsito sea implementado completamente. Adems existen altos riesgos en este modelo pero se los puede reducir si tan solo construimos una parte del sistema y dejamos lo dems para complementarlo en versiones posteriores. Modelo Iterativo.A diferencia del modelo incremental, al modelo iterativo no se le agrega funcionalidad si no que en cada iteracin se mejora su funcionalidad. Ventajas Las ventajas que ofrece un desarrollo iterativo e incremental son varias y variadas, pero debe quedar claro que es muy difcil obtener todas juntas ya que depende del contexto en el que se implemente el proceso. En general las ventajas son: Resolucin de problemas de alto riesgo en tiempos tempranos del proyecto. Visin de avance en el desarrollo desde las etapas iniciales del desarrollo. Obtencin del feedback del usuario lo antes posible, para orientar el desarrollo al cumplimiento de sus necesidades y realizar todas las adaptaciones identificadas para cumplir con los objetivos planteados. Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad de defectos, segn demuestran estudios realizados sobre proyectos que han aplicado esta tcnica.

 Permite manejar la complejidad del proyecto, apuntando a la resolucin de los problemas por partes, y no caer en la inanicin del sper anlisis del producto. El aprendizaje y experiencia del equipo iteracin tras iteracin, mejora exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso en el corto plazo. El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando las planificaciones, logrando menores desvos en la duracin total del proyecto. Su adopcin, con ciertos recaudos, no presenta grandes inversiones. DESVENTAJAS Hasta el momento se podra decir que no existen grandes desventajas, pero s hay puntos a manejar con sumo cuidado: El uso de un desarrollo iterativo e incremental no garantiza por s solo el xito de su uso. Hay costos ocultos en su implementacin, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento. LINKS: http://www.is.ls.fi.upm.es/UDIS/docencia/proyecto/docs/curso/06CursoOO_Diseno Evolutivo.doc - (Este link da un ejemplo de desarrollo incremental e iterativo. Una forma de desarrollo
evolutivo es el llamado desarrollo iterativo e incremental.)

http://www.unibe.edu.do/tic/ingenieria.pdf (Este link se refiere al porque de los fracasos del desarrollo de software con un Proceso Dirigido por los Casos de Uso. Proceso Iterativo e Incremental. Proceso Iterativo e Incremental. Proceso Centrado en ) Escrito por scruz334 el 31/10/2007 02:26 | Comentarios (8)

Comentarios
Veo ya un anlisis ms personal aunque sigues usando textos de otros autores, y los link tambien aportan. Lee otras opiniones pero redacta la tuya propia! Escrito por SandraP 31/10/2007 05:33 Se ve que tienes un concepto claro de los modelos te felicito ya que mencionas aspectos que no los habia tomado en cuenta buen trabajo.

Modelo iterativo incremental

En trminos generales, se puede distinguir, en la figura 4, los pasos generales que sigue el proceso de desarrollo de un producto software. En el modelo de ciclo de vida seleccionado, se identifican claramente dichos pasos. La descripcin del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al producto global y final. Las actividades concurrentes (especificacin, desarrollo y validacin) sintetizan el desarrollo pormenorizado de los incrementos, que se har posteriormente.

Fig. 4 - Diagrama genrico del desarrollo evolutivo incremental. El diagrama 4 muestra en forma muy esquemtica, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final.6 Es decir, a medida que cada incremento definido llega a su etapa de operacin y mantenimiento. Cada versin emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios. El incremental es un modelo de tipo evolutivo que est basado en varios ciclos Cascada Realimentados aplicados repetidamente, con una filosofa iterativa.10 En la figura 5 se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del modelo de ciclo de vida Iterativo Incremental, con sus actividades genricas asociadas. Aqu se observa claramente cada ciclo cascada que es aplicado para la obtencin de un incremento; estos ltimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.

Fig. 5 - Modelo iterativo incremental para el ciclo de vida del software,. Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, as por ejemplo, en la figura, mientras se realiza el diseo detalle del primer incremento ya se est realizando en anlisis del segundo. La figura 5 es slo esquemtica, un incremento no necesariamente se iniciar durante la fase de diseo del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de operacin y mantenimiento (indicada como Operacin en la figura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o dependencia entre incrementos (dos de ellos totalmente independientes

pueden ser fcilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc. Bajo este modelo se entrega software por partes funcionales ms pequeas, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.6 Como se muestra en la figura 5, se aplican secuencias Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es un sistema bsico, con muchas funciones suplementarias (conocidas o no) sin entregar. El cliente utiliza inicialmente ese sistema bsico, intertanto, el resultado de su uso y evaluacin puede aportar al plan para el desarrollo del/los siguientes incrementos (o versiones). Adems tambin aportan a ese plan otros factores, como lo es la priorizacin (mayor o menor urgencia en la necesidad de cada incremento en particular) y la dependencia entre incrementos (o independencia). Luego de cada integracin se entrega un producto con mayor funcionalidad que el previo. El proceso se repite hasta alcanzar el software final completo. Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente operacional en cada incremento, y no una parte que sea usada para reajustar los requerimientos (como si ocurre en el modelo de construccin de prototipos).10 El enfoque incremental resulta muy til cuando se dispone de baja dotacin de personal para el desarrollo; tambin si no hay disponible fecha lmite del proyecto por lo que se entregan versiones incompletas pero que proporcionan al usuario funcionalidad bsica (y cada vez mayor). Tambin es un modelo til a los fines de versiones de evaluacin. Nota: Puede ser considerado y til, en cualquier momento o incremento incorporar temporalmente el paradigma MCP como complemento, teniendo as una mixtura de modelos que mejoran el esquema y desarrollo general. Ejemplo: Un procesador de texto que sea desarrollado bajo el paradigma Incremental podra aportar, en principio, funciones bsicas de edicin de archivos y produccin de documentos (algo como un editor simple). En un segundo incremento se le podra agregar edicin ms sofisticada, y de generacin y mezcla de documentos. En un tercer incremento podra considerarse el agregado de funciones de correccin ortogrfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemticas. As sucesivamente hasta llegar al procesador final requerido. As, el producto va creciendo, acercndose a su meta final, pero desde la entrega del primer incremento ya es til y funcional para el cliente, el cual observa una respuesta rpida en cuanto a entrega temprana; sin notar que la fecha lmite del proyecto puede no estar acotada ni tan definida, lo que da margen de operacin y alivia presiones al equipo de desarrollo. Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y esperan probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software pueda evolucionar9 . Aplicable cuando los requisitos son medianamente bien conocidos pero no son completamente estticos y definidos, cuestin esa que si es indispensable para poder utilizar un modelo Cascada.

El modelo es aconsejable para el desarrollo de software en el cual se observe, en su etapa inicial de anlisis, que posee reas bastante bien definidas a cubrir, con suficiente independencia como para ser desarrolladas en etapas sucesivas. Tales reas a cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priorizar en un anlisis previo, es decir, definir cual ser la primera, la segunda, y as sucesivamente; esto se conoce como definicin de los incrementos con base en la priorizacin. Pueden no existir prioridades funcionales por parte del cliente, pero el desarrollador debe fijarlas de todos modos y con algn criterio, ya que basndose en ellas se desarrollarn y entregarn los distintos incrementos. El hecho de que existan incrementos funcionales del software lleva inmediatamente a pensar en un esquema de desarrollo modular, por tanto este modelo facilita tal paradigma de diseo. En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto software denominados incrementos del sistema, que son escogidos segn prioridades predefinidas de algn modo. El modelo permite una implementacin con refinamientos sucesivos (ampliacin o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versin previamente implementada del producto software. Este modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan cambios en los requisitos por parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse como un nuevo incremento o, eventualmente, podr constituir una mejora/adecuacin de uno ya planeado. Aunque si se produce un cambio de requisitos por parte del cliente que afecte incrementos previos ya terminados (deteccin/incorporacin tarda) se debe evaluar la factibilidad y realizar un acuerdo con el cliente, ya que puede impactar fuertemente en los costos. La seleccin de este modelo permite realizar entregas funcionales tempranas al cliente (lo cual es beneficioso tanto para l como para el grupo de desarrollo). Se priorizan las entregas de aquellos mdulos o incrementos en que surja la necesidad operativa de hacerlo, por ejemplo para cargas previas de informacin, indispensable para los incrementos siguientes.10 El modelo iterativo incremental no obliga a especificar con precisin y detalle absolutamente todo lo que el sistema debe hacer, (y cmo), antes de ser construido (como el caso del cascada, con requisitos congelados). Slo se hace en el incremento en desarrollo. Esto torna ms manejable el proceso y reduce el impacto en los costos. Esto es as, porque en caso de alterar o rehacer los requisitos, solo afecta una parte del sistema. Aunque, lgicamente, esta situacin se agrava si se presenta en estado avanzado, es decir en los ltimos incrementos. En definitiva, el modelo facilita la incorporacin de nuevos requisitos durante el desarrollo. Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa funcionalidad parcial. Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software. El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, o de alto ndice de riesgos.

Modelos Iterativos e Incrementales

[editar]

Introduccin
La elaboracin de proyectos requiere en su etapa inicial una buena planificacin, dentro del desarrollo de software existen varios parmetros en los que basarse como por ejemplo grado de definicin de requisitos, tamao del proyecto, riesgos identificados, entre otros, el reto de los desarrolladores est en saber elegir un buen modelo de desarrollo, una opcin es el modelo iterativo e incremental. Trminos importantes: Versin de Software.- es un nmero que indica el nivel de desarrollo de un programa. Es habitual que una aplicacin sufra modificaciones, mejoras o correcciones. El nmero de versin suele indicar el avance de los cambios. Suelen ser nmeros correlativos, y frecuentemente son dos cifras separadas por un punto. Por ejemplo, el paso de la versin 2 a la 3 de una aplicacin suele conllevar cambios significativos, mientras que el paso de la 3.0 a la 3.1 indica cambios de menor importancia; el siguiente grupo de mejoras fuertes llevara a la versin 4.0. Hay quien afina ms, utilizando tres cifras en vez de dos: 1.1.56. Algunos fabricantes usan el nmero de ao de lanzamiento (por ejemplo: Microsoft Office 97) en vez de nmeros consecutivos.(Fuente: http://es.wikipedia.org/wiki/Versin) Tipos de Versin: Pre-alfa Se publica a veces antes del lanzamiento de una versin alfa o beta. No tiene sus caractersticas completas. Los diseadores todava estn determinando en esta etapa exactamente Alfa o esencial La versin alfa de un producto es la primera para la que el equipo de desarrollo decide que implementa todas las funcionalidades especificadas en los requisitos. Es la primera versin del programa que se enva a los verificadores para probarla. Beta Representa generalmente la primera versin completa del programa informtico o de otro producto, que es probable que sea inestable pero til para que las demostraciones internas y las inspecciones previas seleccionen a clientes. Las versiones beta estn en un paso intermedio en el ciclo de desarrollo completo. Los probadores divulgan cualquier error que encuentran y caractersticas, a veces de menor importancia, que quisieran ver en la versin final. Versin candidata a definitiva Se refiere a un producto final, preparado para lanzarse como versin definitiva a menos que aparezcan errores que lo impidan. Iterativo.- que se repite, mejorando su funcionalidad durante el desarrollo de las nuevas versiones. Incremental.- que se aumenta, corresponde al aumento de funcionalidad del producto en las nuevas versiones. Entonces, el Modelo Iterativo e Incremental est dividido en partes pequeas o miniproyectos, donde cada mini-proyecto es una iteracin que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto, todo con el fin de obtener una nueva versin mejorada del producto. [editar]

Descripcin con Esquemas y Fases

DESCRIPCIN DEL MODELO El modelo es una evolucin del modelo cascada, ya que esta basado en el mismo, el producto final del desarrollo de software es la secuencia de una serie de versiones conformadas por mini-cascadas (mini-proyectos) las cuales van aumentando tanto en su funcionabilidad como tambin el mejoramiento de dichas funciones que suplen las necesidades del cliente. Existen dos factores para decidir que se implementar en una iteracin: -La iteracin trata un grupo de casos de uso que juntos amplan la utilidad del producto desarrollado hasta ahora. -La iteracin trata los riesgos ms importantes. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la ltima iteracin. Un proceso iterativo e incremental se denomina dirigido por el riesgo, lo que significa que cada nueva versin se ataca y reducen los riesgos ms significativos para el xito del proyecto.

ESQUEMA DEL MODELO ITERATIVO-INCREMENTAL

-Planificacin y Anlisis de la Iteracin (Estudio de riesgos): Anlisis de los Casos de Uso y escenarios. Diseo de opciones arquitectnicas. -Codificacin y Pruebas: La integracin del nuevo cdigo con el existente de iteraciones anteriores se hace gradualmente durante la construccin.

-Evaluacin de la entrega ejecutable: Evaluacin del prototipo en funcin de las pruebas y criterios definidos. -Preparacin de la entrega: Documentacin e instalacin de la versin del producto. Al finalizar se realiza una integracin de los resultados con lo obtenido de las iteraciones anteriores. Cada iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Ciclo de Vida Iterativo Incremental Est constituido en tres etapas: 1.Etapa de Inicializacin Se crea una primera versin con el objetivo de que el usuario pueda interactuar con el producto de software de manera que esta informacin pueda ser retroalimentada. Se crea una lista de control en donde se puntualizan las mejoras que el producto debe tener en la siguiente versin, adems de las funciones que se deben implementar y los rediseos de la solucin ya existente, esta debe ser supervisada constantemente como parte del proceso de anlisis. 2.Etapa de Iteracin Involucra principalmente el rediseo e implementacin de una tarea de la lista de control. El anlisis del rediseo se basa en la retroalimentacin del usuario adems de del anlisis de estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia. 3.Lista de Control del Proyecto Esta lista se crea en el proceso de anlisis del proyecto y nos sirve para aplicar las medidas correctivas a los diversos errores que se pueden generar en el transcurso de todo el ciclo de vida del software. Enfoque Iterativo Incremental

[editar]

Ventajas
Provee soporte para determinar la efectividad de los procesos y de la calidad del producto. Permite estudiar y despus mejorar y ajustar el proceso para el ambiente en particular. Se tiene una visin del producto esencial en un corto espacio de tiempo. Se puede ir corrigiendo errores con el modelo iterativo Se puede agregar ms funcionalidades con el modelo incremental [editar]

Desventajas
El desarrollo con este modelo requiere ms tiempo para entregar un producto final. El modelo no es tan sencillo como el de cascada debido a su complejidad en la planificacin. Es difcil distinguirlo del proceso "codifica y corrige", ya que son parecidos, la diferencia est que en la prctica se requiere que al construir el prototipo se aplique el anlisis y el diseo pero slo a una parte de los requerimientos, que se documente y se codifique, logrando un poco de disciplina heredada del modelo en cascada.

Historia De iterativo
Historia de la iterativa y el desarrollo incremental. Para el tema 06 2003 IEEE Computer dedicado a los procesos giles (editado por A. Cockburn y Williams L.), Vic Basili y CraigLarman escribi la historia de la iterativa / incrementales / giles los

procesos del ciclo de vida. Puede obtener la versin PDF del artculo completo de http://www.craiglarman.com Este es un extracto del principio del artculo, desde la dcada de 1950 a 1980. Iterativo e incremental para el Desarrollo: Una breve historia
Craig Larman Jefe Cientfico, Valtech EE.UU. craig@craiglarman.com

Dr. Victor R. Basili Profesor del Departamento de Ciencias de la Computacin, Universidad de Maryland basili@cs.umd.edu

Una prctica central de los mtodos giles es iterativo, desarrollo de software evolutivo y gradual. Este es un punto de mira de la historia de su larga prctica y generalizada, la promocin por thoughtleaders de ingeniera de software, y la recomendacin por parte de grupos de normas. Los grandes proyectos que van desde el Proyecto Mercury a finales de 1950 a un sistema de control de trnsito areo en la dcada de 1990 se seal. Un anlisis detallado de los diferentes mtodos es ms all del alcance de esta historia; el nfasis est cronologa en lugar de comparacin. A pesar de la evolucin, el desarrollo iterativo e incremental (IID) en el software se encuentra en el ascenso como el enfoque moderno o giles para sustituir ad hoc o cascada (ciclo de vida secuencial) de desarrollo, sus races se practica y se public volver a sorprender ahora. Por lo menos ya en mediados de 1950, como una alternativa contempornea a la incipiente modelo de cascada, en primer lugar se describe como el modelo por etapas para los EE.UU. de la defensa area SAGE proyecto HD Benington en la produccin de programas informticos de gran tamao, Actas de la ONR Simposio sobre Mtodos Programa Avanzado de Computacin Digital, junio de 1956. Winston Royce tambin opin sobre la modelwithin cascada de las restricciones de contratos con el gobierno en ese timein gestin del desarrollo de grandes sistemas de software, Actas de la IEEE Westcon, 1970. Somos conscientes de que la idea de IID viene con independencia de manycountless proyectos sin nombre y la contribucin de miles de personas. Esta breve historia poniendo de relieve algunos proyectos y las personas no tiene la intencin de disminuir la importancia reconocida de los dems. Los mtodos giles que se aplican IID como una prctica fundamental ha recibido crticas por parte de la cascada y los proponentes los requisitos de ingeniera de la insuficiencia de las primeras necesidades y el diseo. Pero, la historia muestra los requisitos de la evolucin, el diseo y desarrollo en lugar de grandes esfuerzos por adelantado especificacin ha sido comn, con xito, y recomendado por los expertos. Por supuesto, los expertos en ingeniera de software (por ejemplo, los lectores de las revistas IEEE) son muy conscientes de esto, pero sigue siendo sorprendentemente desconocido en muchos comerciales y organizaciones gubernamentales. Hay variaciones en los mtodos descritos aqu IID, y est ms all del alcance de este articlechronology en lugar de proporcionar un anlisis profundo comparisonto contraste. Sin embargo, algunos rasgos diferentes y comunes se observan, como las diferencias en los detalles del ciclo de vida. Por ejemplo, la longitud de iteraciones, y si o no se les timeboxed. Otra diferencia es el grado de trabajo por adelantado en las especificaciones. Algunos de los proyectos iniciales intent significativa por adelantado el trabajo combinado con el desarrollo timeboxed incremental. Othersthe majoritywere ms clsico de la evolucin o el feedback. Sin embargo, en cada uno, haba un tema comn para evitar un solo paso secuencial, el documento impulsado por cerrada a paso. En la terminologa: en el uso moderno de los mtodos populares IID, tales como el Proceso Unificado, Extreme Programming, Scrum, DSDM y, el desarrollo iterativo implica no slo revisar el trabajo, pero el avance ms alsoand commonlyevolutionary. Y a medida que la historia mostrar, este uso se extiende tan lejos como la dcada de 1960. Pidiendo perdn desde el ms literal-mente, el artculo sigue la convencin popular.

La mayora de los anlisis y los ejemplos estn dedicados a las dcadas de 1970 y principios de la historia 80sthe ms activo que est menos conocidos. La dcada de 1990 y ms all de la seccin es ms breve. Sigamos con la historia Pre-1970 Races iniciales para IID se encuentran en la obra de Walter Shewhart, el experto en calidad en los Laboratorios Bell, quien propuso, en la dcada de 1930, una serie de cortos Planificar-Hacer-EstudiarActuar (PDSA) ciclos de mejora de la calidad. PDSA fue entonces vigorosamente promovida por gur de la calidad W. Edwards Deming, a partir de la dcada de 1940, y descrito en su salida de la crisis en 1986. La aplicacin de PDSA al software fue explorado en Tom Gilbs principios IID mtodo de Evo (ms sobre esto ms adelante), y por Zultner en el enfoque de Deming a la Ingeniera de Calidad de Software, Quality Progress, de 21 aos (11) de 1988. Un proyecto de hito de 1950 la aplicacin de IID era el jet hipersnico X-15 (vase WH Dana, The X 15 Lecciones Aprendidas, Dryden de la NASA Centro de Investigacin, 1993): Un factor importante para el xito de X-15 s en el largo plazo fue su nfasis en el desarrollo incremental. Aunque no es un proyecto de software, podemos mencionar el X-15 por parte del personal (y por lo tanto, la experiencia IID) cabeza de serie NASA de 1960 del Proyecto Mercury, que se aplicaba en el IID softwarede parte del personal de proyectos de este ltimo cabeza de serie de la IBM Federal de la Divisin de Sistemas (FSD), otro defensor de IID temprano. Proyecto Mercurio se realiz con muy poco, pero iteraciones timeboxed estructurado, de da. No era una revisin tcnica de todos los cambios, y, curiosamente, la prctica de la prueba de Extreme Programming desarrollo previamente se aplic: las pruebas se han planificado y escrito con anterioridad a cada incremento de micro. De arriba hacia abajo con los talones de desarrollo tambin se practicaba. Recuerdos de Gerald M. Weinberg, quien trabaj en el proyecto, proporcionar una ventana a algunas de las prcticas durante este perodo (comunicacin personal): Estbamos haciendo el desarrollo incremental ya en 1957, en Los ngeles, bajo la direccin de Bernie Dimsdale [en IBM, Oficina de Servicio de la Corporacin]. l era un colega de John von Neumann, as que tal vez lo aprendi all, o asume como totalmente natural. Me acuerdo de la hierba Jacobs (principalmente, aunque todos participamos) el desarrollo de una simulacin grande para Motorola, donde la tcnica utilizada fue, en la medida que puedo decir, indistinguible de XP. Cuando gran parte del mismo equipo fue vuelto a montar en Washington, DC en 1958 para desarrollar el Proyecto Mercury, tuvimos nuestra propia mquina y el sistema de reparto de operacin nueva, cuya simblica de modificacin y de reunin nos ha permitido construir el sistema de forma incremental, lo que hicimos, con gran xito. Proyecto Mercury fue el semillero de la cual surgi la Divisin de Sistemas de IBM Federal. Por lo tanto, que la divisin comenz con una historia y una tradicin de desarrollo incremental. Todos nosotros, en la medida que puedo recordar, pens waterfalling de un gran proyecto era bastante estpido, o por lo menos ignorante de las realidades creo que lo que la descripcin de la cascada hizo por nosotros fue darnos cuenta de que estbamos haciendo algo ms, algo annimo, salvo para el desarrollo de software. La primera referencia que encontramos se centr especficamente en la descripcin y recomendar el desarrollo iterativo lleg en 1968 a partir Randell y Zurcher en el IBM TJ Watson Research Center, iterativos multi-nivel Metodologa Modelinga de diseo de sistemas informticos, Actas del Congreso IFIP, 1968 . Esta fue citado, y la promocin de un desarrollo iterativo repite, en Lehman MM 09 1969 informe interno a IBM la gestin de las recomendaciones de desarrollo, del proceso de programacin (reimpreso en EvolutionProcesses programa de cambio de software, 1985). Para citar a Lehman resumir su trabajo:

El enfoque bsico reconoce la inutilidad de la separacin de los procesos de diseo, evaluacin y documentacin en el diseo del software del sistema. El proceso de diseo est estructurado por un modelo de expansin de siembra de una definicin formal del sistema, que proporciona un primer modelo ejecutable y funcional. Ha sido probado y se expandi an ms a travs de una secuencia de modelos, que se desarrollan una cantidad cada vez mayor de la funcin y una cantidad cada vez mayor de detalle en cuanto a la forma en que la funcin se va a ejecutar. En ltima instancia, el modelo se convierte en el sistema. [Vase tambin LehmansLaws ] Otra referencia dcada de 1960 encontramos lleg desde el cristal de Robert sigue activo (columnista de IEEE Software y MCCA): Debate sobre el nivel elemental de compilador / intrprete de la escritura, ACM Encuestas Informtica, marzo 1969. Vidrio escribe: Es la opinin del autor de que el desarrollo incremental es que vale la pena, [que] conduce a una sesin de shakedown del sistema ms completo, evita ejecutor y el desaliento de gestin. La dcada de 1970 En el mencionado artculo de 1970 Royceoften (incorrectamente) citado como el parangn de una sola pasada waterfallhe realmente recomienda un enfoque algo diferente de lo que ha degenerado en la nocin de la cascada de hoy, con su secuencia estricta de anlisis de requerimientos, diseo, y fases de desarrollo. Se recomienda hacerlo dos veces a cita.: Si el programa de ordenador en cuestin est siendo desarrollado por primera vez, arreglar las cosas de modo que la versin final entregado al cliente para el despliegue operativo es en realidad la segunda versin en la medida en diseo crtico / zonas de operaciones se refiere. l va a sugerir que un proyecto de 30 meses podra tener una de 10 meses de usar y tirar modelo piloto y justifica su necesidad en que hay elementos nuevos y factores desconocidos (apenas un caso nico). As, vemos indicios de desarrollo iterativo, la retroalimentacin y la adaptacin. Esta retroalimentacin iterativa basada en el paso en un documento clsico de cascada que se ha perdido en la mayora de las descripciones de este modelo, aunque era evidente que no IID clsico. Qu Royce pensar en la cascada vs IID, como l vino a aprender de este ltimo enfoque? Su hijo, Walker Royce, un colaborador de los mtodos populares IID en la dcada de 1990, dijo de su padre y este documento (comunicacin personal): Siempre fue un defensor de la iterativa, el desarrollo incremental y evolutivo. Su trabajo se describe la cada de agua, como la descripcin ms simple, pero que no iba a funcionar para todos, pero los proyectos ms sencillos. El resto de su trabajo se describen las prcticas] [iterativos en el contexto de los modelos de contratacin 60s/70s del gobierno (un conjunto serio de restricciones). Una visin irnica, dada la influencia que este artculo tiene como parte de la borda la promocin de un ciclo de vida de estricta secuencial para proyectos grandes y complejos. La referencia ms antigua al lado en el ao 1970 proviene de Harlan Mills, un software de ingeniera de 70 aos thoughtleader que trabajaba en la FSD de IBM. En su bien conocido de arriba hacia abajo en los grandes sistemas de programacin que promueve el desarrollo iterativo. Esto fue publicado en tcnicas de depuracin en sistemas grandes (y reimpreso en Mills Collected Papers: Software de Productividad, 1988). Adems de los consejos papeles principales a desarrollar a partir del ms alto nivel las estructuras de control hacia abajo, tal vez menos apreciado es el consejo del ciclo de vida relacionada con la construccin del sistema a travs de expansiones iteradas. es posible generar una secuencia de sistemas intermedios de cdigo y subspecifications funcionales de manera que a cada paso, cada uno [intermedio] el sistema se puede verificar que es correcta, Claramente, Mills sugiere refinamiento iterativo para la fase de desarrollo, pero no hay ninguna mencin de la evitacin de un paso grande especificacin por adelantado, la longitud de iteraciones, o un nfasis en la retroalimentacin y adaptacin impulsada por el desarrollo de cada iteracin. Sin embargo, estos son los puntos que plantea ms adelante en la dcada. Teniendo en cuenta su empleo en

la FSD de IBM, sospechamos que su exposicin a los proyectos ms clsicos IID correr all en la dcada de 1970 influyeron en su pensamiento, pero no pudo confirmar esto con sus colegas. La prctica temprana de la ms moderna IID (retroalimentacin basada en el refinamiento con la participacin del cliente, iteraciones claramente delineados) provienen de la direccin de Mike Dyer, Bob McHenry ? , y Don O'Neill (y muchos otros) durante su permanencia en la FSD de IBM. Lo fascinante de la historia FSD es el alcance y el xito del uso de IID Departamento grande, la vidacrtico EE.UU. de Defensa (DoD), el espacio y los sistemas de avinica de los aos 70. La primera gran aplicacin FSD documentada de IID (que sepamos) en 1972. Esta no era una aplicacin de juguete, sino un gran, gran visibilidad de vida crtica del sistema de ms de 1 milln de lneas de cdigo: el sistema de mando y control para el primer submarino de EE.UU. Trident. El proyecto incluy Dyer, McHenry ? , y O'Neill como jefe de proyecto. ONeil concebido y planificado el uso de IID (ms tarde llamada ingeniera de integracin en la FSD) en este proyecto, fue un factor clave de xito, y fue galardonado con un premio de IBM destacada contribucin para ello. Tenga en cuenta la aprobacin visible por el liderazgo de IBM para los mtodos de IID. El proyecto no poda llegar tarde: el sistema tena que ser entregado en una fecha determinada, de lo contrario FSD enfrentan una multa de $ 100.000 por da de retraso. El proyecto fue organizado en 4 iteraciones timeboxed de alrededor de 6 meses cada uno. Todava haba un importante esfuerzo por adelantado las especificaciones, y la longitud de la iteracin fue ms larga que normalmente se recomienda en la actualidad. Aunque hubo algo de la evolucin de retroalimentacin basada en las necesidades, el enfoque de IID tambin fue visto como una forma de gestionar la complejidad y los riesgos de desarrollo a gran escala. Ver O'Neill, Integracin Ingeniera Perspectiva, El Diario de Sistemas y de Software, 3, 1983. Tambin en 1972, y fuera de la FSD de IBM, otro gran proyecto que aplicada IID proviene de un competidor FSD: TRW. Ellos aplicaron el desarrollo incremental de 100 millones de dlares TRW / Ejrcito de proyecto de sitio de software de Defensa para la defensa de misiles balsticos. El proyecto se inici en febrero de 1972 y desarroll el sistema en 5 iteraciones. Iteracin 1 tena el seguimiento de un nico objeto, y por la iteracin 5, un par de aos ms tarde, el sistema est completo. Las iteraciones no se timeboxed estrictamente, y no fue significativa por adelantado trabajo especificaciones, pero se refinaron tambin en respuesta a cada retroalimentacin iteraciones. Vase Williams, Gerente de Desarrollo de Software Fiable, Relatora de la Conferencia Internacional de Software Fiable, ACM / IEEE, abril de 1975. Al igual que IBM FSD, TRW (donde trabaj Royce) era un pionero de las prcticas de IID. De hecho, Barry Boehm, el autor de la modelo en espiral IID mediados de los 80, se sirve en TRW como Jefe Cientfico. Otra aplicacin temprana (mediados de 1970), con xito, y extremadamente grande del IID en el FSD fue los Estados Unidos de la Marina helicptero-buque LMPARAS del sistema. A 4 aos de 200 persona-aos de esfuerzo que involucra a millones de lnea de cdigo, que fue entregado de forma incremental en 45 iteraciones timeboxed (1 mes por iteracin). Este es el ejemplo ms temprano del proyecto se encontr que la longitud de la iteracin se encontraba en el rango de frecuencia recomendada por los mtodos ms populares de hoy en da la mayora de IID (asesoramiento en el rango de semana 1-6). El proyecto tuvo bastante xito: Para citar, cada una de estas entregas a tiempo y dentro del presupuesto Ver Mills, Principios de Ingeniera de Software, IBM Systems Journal, Vol. 19, n 4, 1980.. En 1975, otro documento de principios y cit ampliamente dedicado a la IID se public. El enfoque se llama iterativo de mejora y viene de Vic Basili y Joe Turner. Ver iterativo de mejora de una tcnica prctica para el Desarrollo de Software, IEEE Transactions on Software Engineering, diciembre 1975. La descripcin se describe claramente IID clsico: La idea bsica detrs de la mejora iterativa es desarrollar un sistema de software de forma incremental, permitiendo al desarrollador para tomar ventaja de lo que se aprendi durante el desarrollo de versiones anteriores, graduales, entregables del

sistema. El aprendizaje proviene tanto el desarrollo y uso del sistema, cuando sea posible. Los pasos clave en el proceso iban a comenzar con una implementacin simple de un subconjunto de los requisitos de software y de forma iterativa mejorar la secuencia de evolucin de las versiones hasta que el sistema completo se lleva a cabo. En cada iteracin, las modificaciones de diseo se hacen junto con la adicin de nuevas capacidades funcionales. Basili y Turner describir la aplicacin exitosa de los IID para el desarrollo de una familia ampliable de compiladores para una familia de lenguajes de programacin de aplicaciones especficas en una variedad de arquitecturas de hardware. La base del sistema se desarroll en 17 iteraciones ms de 20 meses. Cada iteracin se analiza desde el punto tanto a los usuarios y desarrolladores de vista y los comentarios influido tanto en los requisitos de idioma y los cambios de diseo para futuras versiones. Las medidas, tales como el acoplamiento y cohesin, se les dio seguimiento a travs de los mltiples iteraciones. 1976 vio la llegada de una voz que desde hace mucho tiempo y apasionado por el desarrollo evolutivo e iterativo. Tom Gilb publicados Mtricas de Software (acuar el trmino), en la que incluy la discusin de su prctica IID llamado la gestin de proyectos de la evolucin, y present a la evolucin de los trminos y evolutivo del lxico proceso. Este es el primer libro que pudimos encontrar que contiene una discusin clara y promocin de los IID, y sobre todo, la entrega de la evolucin. Por ejemplo: La evolucin es una tcnica para producir la apariencia de estabilidad. Un sistema complejo tendr ms xito si se lleva a cabo en pequeos pasos, y si cada paso tiene una clara medida de logro, as como la posibilidad de retirarse a un paso anterior con xito al fracaso. Usted tiene la oportunidad de recibir una retroalimentacin del mundo real antes de tirar de todos los recursos destinados a un sistema, y puede corregir los posibles errores de diseo Gilb es uno de los practicantes ms antiguos y ms activos IID y promotores, que se inici la prctica en la dcada de 1960, y como veremos, responsable de algunos hitos IID pocos. Su material fue probablemente el primero con una clara gil, ligero, rpido orientado a resultados y adaptacin iterativas sabor similar a los nuevos mtodos de IID. En 1976, Harlan Mills haba fortalecido su mensaje IID. En Desarrollo de Software, IEEE Transactions on Software Engineering, diciembre 1976, escribe: El desarrollo de software se debe hacer gradualmente, por etapas, con participacin de los usuarios continua y replanificacin, y con la programacin de diseo a costos dentro de cada etapa. En el contexto de un sistema de inventario de 3 aos de control, va a desafiar la idea y el valor de los requisitos iniciales o las especificaciones de diseo. l dice: hay peligros, tambin, particularmente en la realizacin de estos [cascada] etapas en secuencia, y no en iterationie, que el desarrollo se realiza en un circuito abierto, en lugar de un bucle cerrado con realimentacin usuario entre iteraciones. El peligro en la secuencia [enfoque en cascada] es que el proyecto pasa de ser grande a ser grandioso, y supera nuestras capacidades intelectuales humanas para la gestin y control. Y tal vez reflejo de varios aos de ver en accin en el IID FSD, Mills le pregunta: Por qu las empresas tolerar las frustraciones y las dificultades de este tipo de desarrollo [cascada]? En 1977, el enfoque de Trident IID, que incluy la integracin de todos los componentes de software al final de cada iteracin (nombrado por la ingeniera de integracin de McHenry ? ) se incorpor a las prcticas de ingeniera de software FSD, a la que el equipo Trident y Mills eran asesores clave. Ver O'Neill, La Direccin de Ingeniera de Software, IBM Systems Journal, vol 19, n 4, 1980. Ingeniera de Integracin se extendi a los ingenieros de software FSD 2500, y la idea de IID como una alternativa a la cascada estimulado el inters sustancial dentro de las divisiones comerciales, IBM, altos mandos de los clientes, y entre los competidores. Aunque desconocido para la mayora de los profesionales de software, otro ejemplo temprano y

notable de un xito IID importante es el corazn mismo del software de traslado espacial de la NASA en s: el principal sistema de avinica del software. Este fue construido por el FSD 1977 a 1980, la aplicacin de IID en una serie de 17 repeticiones de ms de 31 meses, un promedio de alrededor de 8 semanas por iteracin (vase el Desarrollo Madden y Rone, diseo, integracin: Transbordador Espacial Vuelo del software del sistema, las comunicaciones de la ACM, septiembre 1984). Su motivacin? El ciclo de vida de la cascada no era adecuado ya que los requisitos en el programa de la lanzadera se desarroll durante el proceso de desarrollo de software Irnicamente (en retrospectiva), los autores suenan casi pidiendo disculpas por tener que renunciar a la cascada ideal para un enfoque de IID.: Debido al tamao, complejidad y requerimientos evolutivos [cambiar] la naturaleza del programa, se reconoci a principios de que el ideal de desarrollo de software de ciclo de vida [el modelo de cascada] no poda ser estrictamente appliedHowever, un enfoque de aplicacin (en base a pequeas versiones incrementales ) fue diseado para la misin STS-1, que cumplieron con los objetivos mediante la aplicacin del ciclo ideal para pequeos elementos del paquete de software en general de manera iterativa. Este proyecto de traslado tambin exhibi clsicos prcticas IID: timeboxed iteraciones en el rango de 8 semanas, la retroalimentacin basada en el refinamiento de las especificaciones, y as sucesivamente. En 1978, la primera discusin del IID en la prensa popular que se poda encontrar. Tom Gilb comenz a publicar una columna semanal en Informtica (Reino Unido) que regularmente promueve la gestin del IID, el proyecto de la evolucin y el parto. Por ejemplo (6 de abril, 1978): Gestin de'' no requiere de estimaciones seguras de terminacin, tiempo y dinero para todo el proyecto. Cada [pequea iterativa] paso debe cumplir con uno de los siguientes criterios (orden de prioridad): (a) dar vuelta en la recuperacin de la inversin prevista, o, si es imposible, entonces (b) dar el punto de equilibrio (sin prdida), o, al menos, (c) algunos se benefician de usuario positiva mensurable, o, al menos, (d) algunos comentarios de los usuarios el medio ambiente y el aprendizaje''. Un documento de principios de cita a veces sobre el tema del desarrollo incremental es un desarrollo de software con xito, por Wong, en IEEE Transactions on Software Engineering, no. 3, 1984. En l se describe una exitosa defensa del proyecto de sistema de aire que corra desde 1977 hasta 1980 que el combinado significativa por adelantado specificationsbut con el desarrollo incremental y compilaciones. El proyecto estaba destinado aparentemente para caber dentro de las normas del Departamento de Defensa en cascada de un solo paso, con las pruebas y la integracin en la ltima fase. Sin embargo, los comentarios de Wong en el irrealismo de este enfoque, y su necesidad y las ventajas con el desarrollo incremental: La [cascada] modelo fue adoptado por el desarrollo de software se bas en la realidad del Departamento de Defensa standardsIn, desarrollo de software es un proceso complejo, continuo y reiterado y repetitivo. El [modelo de cascada] no refleja esta complejidad.