Modelo Incremental

 Editar 16 134 …

Modelo Incremental

Introducción:

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:

Método de las comparaciones limitadas sucesivas. Ciencia de salir del paso. Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.

En una visión genérica, el proceso se divide en 4 partes:

Análisis Diseño Código Prueba

Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminará siendo la solución completa requerida por el cliente, pero éstas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con más urgencia, de los puntos más importantes del proyecto, los requerimientos más básicos, difíciles y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versión.De este modo podemos terminar una aplicación ejecutable (primera versión) que podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la siguiente versión junto con los demás requerimientos que no fueron tomados en cuenta en la versión anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del

sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo de requisitos funcionales y será el cliente quien se encarga de priorizar que funcionalidades son mas importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregará. La asignación de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Características:

Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.

El usuario se involucra mas. Dificil de evaluar el costo total. Dificil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar

como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde. El resultado puede ser positivo.

Ventajas:

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.

También 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 sólo al ámbito de cada incremento.

Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

Desventajas:

El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de riesgos.

Requiere de mucha planeación, tanto administrativa como técnica. Requiere de metas claras para conocer el estado del proyecto.

Conclusión:

Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto Software denominados "incrementos" del sistema, que son escogidos en base a prioridades predefinidas de algún modo.El modelo permite una implementación con refinamientos sucesivos (ampliación y/o mejoras).Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software.

Léxico Extendido del Lenguaje (LEL)

Número Símbolo Tipo

1 Análisis Verbo

2 Analista Sujeto

3 Codificación Verbo

4 Desarrollador Sujeto

5 Diseñador Sujeto

6 Diseño Verbo

7 Entregar el incremento Verbo

8 Especificación de requisitos Objeto

9 Incremento Objeto

10 Incremento rechazado Estado

11 Incremento validado Estado

12 Modelo de arquitectura de softwareObjeto

13 Modelo de diseño Objeto

14 Núcleo Objeto

15 Plan de incremento Objeto

16 Producto Objeto

17 Producto completo Estado

18 Producto incompleto Estado

19 Prueba Verbo

20 Prueba de aceptación Verbo

21 Prueba de integración Verbo

22 Prueba unitaria Verbo

23 Tester Sujeto

Definición de Símbolos

Símbolo Nº: 1

Tipo: Verbo

Nombre/s Análisis

NociónEs la actividad en la que se obtienen e interpretan los requisitos de un incremento.Es llevada a cabo por el analista.

Impacto Se elicitan los requisitos del incremento con el cliente.Se interpretan los requisitos obtenidos.Se realiza el documento de especificación de requisitos.Se validan los requisitos elicitados con cliente.

Símbolo Nº: 2

Tipo: Sujeto

Nombre/s Analista

NociónEs el encargado de realizar el análisis de los requisitos que corresponden a un incremento.

Impacto Define cuales son las necesidades del cliente.Se encarga de elicitar requisitos con el cliente.Realiza el análisis de los requisitos de cada incremento.Se encarga de realizar el documento de especificación de requisitos.

Símbolo Nº: 3

Tipo: Verbo

Nombre/s Codificación

NociónEs la actividad en la que se elabora la funcionalidad de un incremento.Es realizada por el desarrollador.Sucede luego de la actividad de análisis.

Impacto Se desarrolla en base a los requisitos registrados en el documento de especificación de requisitos que corresponden a un incremento.Agrega funcionalidad al producto.

Símbolo Nº: 4

Tipo: Sujeto

Nombre/s Desarrollador

NociónEs el encargado de realizar la codificación que corresponde a un incremento.

Impacto Toma los requisitos del documento de especificación de requisitos que corresponden al incremento que se está elaborando.Revisa el documento de especificación de requisitos.Revisa el documento de modelo de diseño.Realiza la codificación correspondiente a los requisitos de un incremento teniendo en cuenta el modelo de diseño detallado.

Símbolo Nº: 5

Tipo: Sujeto

Nombre/s Diseñador

NociónEs el encargado de realizar el modelo de diseño.Es el encargado de realizar el modelo de arquitectura de software.

Impacto Define el modelo de diseño en base al documento de especificación de requisitos.Define el modelo de arquitectura del software en base al documento de especificación de requisitos.Toma los requisitos que corresponden al incremento que se está elaborando.Revisa el documento de especificación de requisitos.Se encarga de llevar a cabo la actividad de diseño.

Símbolo Nº: 6

Tipo: Verbo

Nombre/s Diseño

NociónEs la actividad que permite llevar a cabo el modelo de diseño de un incremento.Es la actividad que permite llevar a cabo el modelo de arquitectura de software de un incremento.Es realizada por el diseñador.Sucede luego de la actividad de análisis.

Impacto Se revisan los requisitos del incremento que se encuentran en el documento de especificación de requisitos.Se determina la estructura requerida para el incremento, la cual es realizada con el modelo de arquitectura de software.Se detallan los componentes que se van utilizar para el incremento, los cuales se realizan con el modelo de arquitectura de software.Se definen los diagramas a utilizar para el modelo de diseño del incremento.

Símbolo Nº: 7

Tipo: Verbo

Nombre/s Entregar el incremento

NociónEs la actividad que corresponde a la entrega del producto al cliente de la funcionalidad solicitada.

Impacto Se realiza la instalación del incremento en el cliente.Se realiza la prueba de aceptación con el cliente.Se verifica que los requisitos del documento de especificación de requisitos coincidan con el incremento entregado.

El incremento es utilizado por el cliente.

Símbolo Nº: 8

Tipo: Objeto

Nombre/s Especificación de requisitos

NociónEs un documento que se confecciona durante la actividad de análisis.Es toda la información necesaria para comprender la necesidad del cliente.

Impacto Es confeccionado por el analista.Contiene los requisitos del sistema que surgen en cada incremento.El primer documento generado da origen al núcleo.Es utilizado por el desarrollador para la codificación.Es utilizado por el diseñador para realizar el modelo de diseño.Es utilizado por el diseñador para realizar el modelo de arquitectura de software.

Símbolo Nº: 9

Tipo: Objeto

Nombre/s Incremento

NociónEs una porción del software que cumple con un conjunto de funcionalidades requeridas por el cliente.Toda la documentación relevante del incremento y que es proporcionada por el cliente se vuelca en el plan de incremento.

Impacto Cada incremento pasa por las siguientes actividades: análisis, diseño, codificación y prueba.Es aceptado o rechazado en base a los resultados de la prueba de aceptación.Cumple con un conjunto de requisitos solicitados por el cliente y que se encuentran documentados en la especificación de requisitos.

Símbolo Nº: 10

Tipo: Estado

Nombre/s Incremento rechazado

NociónIndica que un incremento no representa lo esperado por el cliente.Se determina luego de realizar las pruebas de aceptación con el cliente.

Impacto Se deben redefinir los requisitos que no fueron bien interpretados hasta que el incremento pase a ser un incremento validado.Se vuelven a realizar las actividades de análisis y codificación.

Símbolo Nº:11

Tipo: Estado

Nombre/s Incremento validado

NociónIndica que un incremento representa lo esperado por el cliente.Se determina luego de realizar las pruebas de aceptación con el cliente.

Impacto Se puede proceder a la elaboración del siguiente incremento.Si luego surgen nuevos requisitos los mismos se tendrán en cuenta en futuros incrementos y se deberá armar un nuevo plan de incremento.

Símbolo Nº: 12

Tipo: Objeto

Nombre/s Modelo de arquitectura del software

NociónEs un documento donde se indica la estructura e interacción entre las partes que componen el producto software.

Impacto Es realizada por el diseñador.Se realiza durante la actividad de diseño.Se utiliza para elaborar la estructura general de la implementación del producto.Define la relación entre los elementos estructurales del producto software.Es utilizado para la actividad de codificación.

Símbolo Nº: 13

Tipo: Objeto

Nombre/s Modelo de diseño

NociónEs la representación de la solución en el desarrollo del producto.

Impacto Es creado por el diseñador.Se realiza durante la actividad de diseño.Define las funcionalidades, los componentes y las interfaces que forman parte del producto.Es utilizado para la actividad de codificación.

Símbolo Nº: 14

Tipo: Objeto

Nombre/s Núcleo

NociónEs el primer incremento entregado.Es la base para futuros incrementos.Contiene las principales funcionalidades del sistema.

Impacto Genera una versión estable del producto.Genera un producto completo.Es determinado por el cliente luego de que éste haya seleccionado cuales requisitos de la especificación de requisitos formarán parte del primer incremento.

Símbolo Nº: 15

Tipo: Objeto

Nombre/s Plan de incremento

NociónDocumento que contiene toda la información del incremento a elaborar.Contiene las funcionalidades, fechas y responsables a incluir en el incremento.

Impacto Se utiliza para organizar el próximo incremento a elaborar.Lo lleva a cabo el analista.Se elabora en conjunto con el cliente.

Símbolo Nº:16

Tipo: Objeto

Nombre/s Producto

NociónEs el software construido por el desarrollador.Es la documentación que acompaña al software.

Son los datos que configuran el software.Es lo que se entrega al finalizar un incremento.

Impacto Se lo puede modificar en cualquiera de las fases del proceso de software.Su creación comienza desde la actividad de análisis.Si las pruebas de aceptación con el cliente son exitosas se lo considera producto completo.Si las pruebas de aceptación con el cliente no son exitosas se lo considera producto incompleto.

Símbolo Nº:17

Tipo: Estado

Nombre/s Producto completo

NociónSucede luego de que el producto cumple con los requisitos establecidos por el cliente.

Impacto El producto puede ser entregado al cliente.El producto es utilizado por el cliente.

Símbolo Nº:18

Tipo: Estado

Nombre/s Producto incompleto

NociónSucede luego de que el producto no cumple con los requisitos establecidos por el cliente.Indica que el producto no se encuentra apto para ser entregado.

Impacto El producto no puede ser entregado al cliente.El producto se debe corregir para poder concluir el incremento.Una vez corregido, probado y aceptado por el cliente mediante las pruebas de aceptación, pasa a ser un producto completo y el incremento pasa a ser un incremento validado.

Símbolo Nº:19

Tipo: Verbo

Nombre/s Prueba

NociónEs la actividad que permite evaluar el funcionamiento del producto.

Sucede luego de la actividad de codificación.Es realizada por el desarrollador.Es realizada por el tester.Es realizada por el cliente.

Impacto El desarrollador puede llevar a cabo una prueba unitaria del producto.El tester puede llevar a cabo una prueba de integración del producto.El cliente puede llevar a cabo una prueba de aceptación del producto.

Símbolo Nº:20

Tipo: Verbo

Nombre/s Prueba de aceptación

NociónSucede al momento de hacer la entrega del incremento al cliente.Permite validar si el producto cumple con el funcionamiento esperado por el cliente.Es realizada por el cliente.

Impacto Identificar errores en el producto.Utiliza diversos juegos de datos para llevar a cabo el ensayo.Si el producto cumple con todos los requisitos esperados por el cliente, entonces el incremento pasa a ser un incremento validado.Si el producto no cumple con todos los requisitos esperados por el cliente, entonces el incremento pasa a ser un incremento rechazado.

Símbolo Nº:21

Tipo: Verbo

Nombre/s Prueba de integración

NociónSucede durante la actividad de codificación.Se lleva a cabo sobre el producto a entregar teniendo en cuenta que la nueva funcionalidad se integre con lo que actualmente se encuentra funcionando.Es realizada por el tester.

Impacto Identificar errores en el producto.Utiliza diversos juegos de datos para llevar a cabo el ensayo.Los errores detectados son reportados al desarrollador para su corrección.

Símbolo Nº:22

Tipo: Verbo

Nombre/s Prueba unitaria

NociónSucede durante la actividad de codificación.Se lleva a cabo sobre el producto a entregar teniendo en cuenta solamente la funcionalidad que se agrega.Es la actividad realizada por el desarrollador.

Impacto Identifica errores en el producto.Utiliza diversos juegos de datos para llevar a cabo el ensayo.El desarrollador se encarga de corregir los errores detectados.

Símbolo Nº:23

Tipo: Sujeto

Nombre/s Tester

NociónEs el encargado de realizar las pruebas de integración del producto.

Impacto Asegura que la funcionalidad que está probando se integre correctamente con el resto del producto.Realiza la documentación de las pruebas de integración.Informa los errores detectados para luego ser corregidos por el desarrollador.Verifica las correcciones realizadas al producto por el desarrollador.

MODELO INCREMENTAL EVOLUTIVO

El software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar conforme se

desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el

mercado un producto absolutamente completo, por lo que se debe introducir una versión funcional limitada de

alguna forma para aliviar las presiones competitivas.

En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estén diseñados para

acomodarse a una evolución temporal o progresiva, donde los requisitos centrales son conocidos de antemano,

aunque no estén bien definidos a nivel detalle.

En el modelo Cascada y Cascada Realimentado no se tiene en cuenta la naturaleza evolutiva del software, se

plantea como estático con requisitos bien conocidos y definidos desde el inicio.

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta

llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación.

Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los más conocidos y utilizados del tipo

evolutivo.

http://www.bibliojuridica.org/libros/2/516/7.pdf

El modelo incremental

�� Combina elementos del modelo lineal con la filosofía de creación de prototipos

�� El primer incremento a menudo es un producto esencial (núcleo)

�� A partir de la evaluación se planea el siguiente incremento y así sucesivamente

�� Es interactivo por naturaleza

�� Es útil cuando el personal no es suficiente para la implementación completa

El modelo incremental

Incremento 1

Análisis-Diseño-Código-Pruebas Entrega de 1er incremento

Análisis-Diseño-Código-Pruebas Entrega de

2º incremento

Análisis-Diseño-Código-Pruebas Entrega de

3er incremento

Análisis-Diseño-Código-Pruebas Entrega de

4o incremento

Tiempo de calendario

�� Ventajas �� Se puede financiar el proyecto por partes �� Apropiado para proyectos

grandes de larga duración �� No se necesita tanto personal al principio como para una

implementación completa �� Inconvenientes �� Se necesitan pruebas de regresión ��

Pueden aumentar el coste debido a las pruebas

perteneciente a la familia de los procesos evolutivos. el Modelo Incremental combina elementos

del MLS con la filosofía interactiva de construcción de prototipos. En una visión genérica, el

proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la

producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en

muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto

con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha

elementos al final de cada incremento a fin de que el software se adapte mejor a sus

necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta

forma el tiempo de entrega se reduce considerablemente. Al igual que los otros métodos de

modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en

que al final de cada incremento se entrega un producto completamente operacional. El Modelo

Incremental es particularmente útil cuando no se cuenta con una dotación de personal

suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada

incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden

planear para gestionar riesgos técnicos.

Modelos evolutivos: Incremental

Modelo incremental

Combina: modelo lineal + la construcción de prototipos

Incorporación incremental de funcionalidades

Problemas:

Los sistemas están pobremente especificados

Poca visibilidad en el proceso de desarrollo

Modelo De Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces den

ominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un

producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto

completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los

requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son

bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen

una implementación parcial del sistema que recibe sólo estos requerimientos.

El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los

desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es

actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se

repite indefinidamente.

Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo

evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así,

el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente,

el desarrollo incremental y evolutivo puede ser combinado también.

Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos

(incremental), y comprender al principio que muchos nuevos requerimientos es probable que

aparezcan cuando el sistema sea desplegado o desarrollado.

El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de

documentos, programas, datos de test, etc. desarrollados para distintas versiones del software.

Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios

deben ser efectuados de una manera controlada.

video modelo incremental evolutivo

http://www.slideshare.net/boreasH/ingenieria-de-softwaremodelo-incremental-victor-mamani-

catachura-boreash

El modelo Incremental parte de una consideración en cuanto a la solución de los problemas, y es

tomar el asunto en consideración por las ramas, es decir contrario a como comúnmente se

expresa popularmente “coger el toro por los cachos”.Este planteamiento flexibiliza la posibilidad

en cuanto a recursos, tiempos, y permite ganar experiencia en las diferentes etapas del

desarrollo de software; para percibir las bondades del modelo incremental es interesante

plantear una comparación con el modelo lineal. En el modelo lineal se plantea un proyecto con

sus diferentes etapas de desarrollo, con un presupuesto especifico, proyectado a una fecha

especifica de cumplimiento, con un objetivo a conseguir, se plantean unas etapas de análisis,

diseño, desarrollo de código, pruebas, rediseño, y finalmente puesta en marcha del producto.En

la etapa de pruebas surgen muchos de los problemas que no se contemplaron al comienzo del

proyecto, pues en el acople de los diferentes módulos surgen variables que probablemente no se

habían contemplado, de igual forma surgen inconvenientes al momento de implementarlo en el

usuario final, todas estas variables no contempladas y todos los inconvenientes presentados a

nivel de usuario, se multiplican en la medida que los módulos a acoplar sean mayores.Como se

percibe, un proyecto de este tipo requiere de un buen análisis previo al mismo diseño, con el

animo de reducir la cantidad de variables no contempladas, ya que la etapa de rediseño podría

perfectamente requerir de cambios bruscos que afecten gravemente el proyecto llegando

inclusive a requerir de un cambio total .En contraste en el modelo incremental el desarrollo de

software se lleva a cabo por módulos, es decir que el proyecto se entrega por etapas .En el

modelo incremental se plantea un proyecto con sus diferentes etapas de desarrollo, con un

presupuesto global indefinido, proyectado en fechas especificas únicamente para cada modulo,

se plantean unas etapas de análisis, diseño, desarrollo de código, pruebas, rediseño, y

finalmente puesta en marcha de cada modulo.La ventaja de desarrollar el proyecto por etapas,

es que permite adquirir experiencia en la medida que se va entregando cada modulo, los

inconvenientes surgidos en la puesta en marcha de las primeras etapas del proceso van dejando

experiencias que permiten diseñar la siguientes partes del proceso con menores posibilidades de

error entre estos el acople entre los mismos.

Desarrollo iterativo e incremental

En un desarrollo iterativo e incremental el proyecto se planifica en diversos bloques temporales (en el caso de Scrum de un mes natural o hasta de dos semanas, si así se necesita) llamados iteraciones.

Las iteraciones se pueden entender como miniproyectos: en todas las iteraciones se repite un proceso de trabajo similar (de ahí el nombre “iterativo”) para proporcionar un resultado completo sobre producto final, de manera que el cliente pueda obtener los beneficios del proyecto de forma incremental. Para ello, cada requisito se debe completar en una única iteración: el equipo debe realizar todas las tareas necesarias para completarlo (incluuyendo pruebas y documentación) y que esté preparado para ser entregado al cliente con el mínimo esfuerzo necesario. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos.

En cada iteración el equipo evoluciona el producto (hace una entrega incremental) a partir de los resultados completados en las iteraciones anteriores, añadiendo nuevos objetivos/requisitos o mejorando los que ya fueron completados. Un aspecto fundamental para guiar el desarrollo iterativo e incremental es la priorización de los objetivos/requisitos en función del valor que aportan al cliente.

 

 

Beneficios

Se puede gestionar las expectativas del cliente (requisitos desarrollados, velocidad de desarrollo, calidad) de manera regular, puede tomar decisiones en cada iteración. Esto es especialmente interesante cuando:o El cliente no sabe exactamente qué es lo que necesita, lo va sabiendo

conforme va viendo cuales son los resultados del proyecto.o El cliente necesita hacer cambios a corto plazo (nuevos requisitos o a cambios

en los ya realizados) por:o Cambios en las condiciones del mercado (por un cambio de

necesidades, por un nuevo producto que ha lanzado la competencia, urgencias).

o La reacción y aceptación del mercado respecto al uso de los primeros resultados del proyecto.

o Cualquier cambio en el entorno (recursos, etc.), que pueda incluso finalizar el proyecto manteniendo como mínimo los resultados alcanzados hasta ese momento.

o El equipo necesita saber si lo que ha entendido es lo que el cliente espera. El cliente puede comenzar el proyecto con requisitos de alto nivel, quizás no

del todo completos, de manera que se vayan refinando en sucesivas iteraciones. Sólo es necesario conocer con más detalle los requisitos de las primeras iteraciones, los que más valor aportan. No es necesario realizar una recolección completa y detallada de todos los requisitos antes de empezar el desarrollo del proyecto.

El cliente puede obtener resultados importantes y usables ya desde las primeras iteraciones.

Se puede gestionar de manera natural los cambios que van apareciendo durante el proyecto. La finalización de cada iteración es el lugar natural donde el cliente puede proporcionar su feedback tras examinar el resultado obtenido (ver control empírico ydemostración). Con esta información ya es posible planificar los cambios necesarios para alinearse con las expectativas del cliente desde las primeras iteraciones, de manera que al finalizar el proyecto el cliente obtenga los objetivos esperados.

El cliente como máximo puede perder los recursos dedicados a una iteración, no los de todo el proyecto.

La finalización de cada iteración es el lugar natural donde el equipo puede decidir cómo mejorar su proceso de trabajo, en función de la experiencia obtenida. Con esta información ya es posible planificar los cambios necesarios para aumentar la productividad y calidad desde las primeras iteraciones. Ver Retrospectiva.

Permite conocer el progreso real del proyecto desde las primeras iteraciones y extrapolar si su finalización es viable en la fecha prevista. El cliente puede decidir repriorizar los requisitos del proyecto, añadir nuevos equipos, cancelarlo, etc.

Permite mitigar desde el inicio los riesgos del proyecto. Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos  riesgos, es posible iniciar su mitigación de manera anticipada.

Permite gestionar la complejidad del proyecto.o En una iteración sólo se trabaja en los requisitos que aportan más valor en ese

momento.o Se puede dividir la complejidad para que cada parte sea resuelta en diferentes

iteraciones.  Dado que cada iteración debe dar como resultado requisitos terminados, se

minimiza el número de errores que se producen en el desarrollo y se aumentar la calidad.

 Restricciones

La disponibilidad del cliente debe ser alta durante todo el proyecto dado que participa de manera continua:o El inicio de una iteración, el cliente ha de detallar (o haber detallado

previamente) los requisitos que se van a desarrollar. o En la finalización de cada iteración, el cliente ha de revisar los requisitos

desarrollados. La relación con el cliente ha de estar basada en los principios de colaboración y

ganar/ganarmás que tratarse de una relación contractual en la cual cada parte únicamente defiende su beneficio a corto plazo.

Cada iteración debe dar como resultado requisitos terminados, de manera que el resultado sea realmente útil para el cliente y no deje tareas pendientes para futuras iteraciones o para la finalización del proyecto.

Cada iteración ha de aportar un valor al cliente, entregar unos resultados cerrados que sean susceptibles de ser utilizados por él.

Es necesario disponer de técnicas y herramientas que permitan hacer cambios fácilmente en el producto, de manera que pueda crecer en cada

iteración de manera incremental sin hacer un gran esfuerzo adicional, manteniendo su complejidad minimizada y su calidad.

 Recomendaciones

Utilizar iteraciones cortas de 2 a 4 semanas incrementa la productividad del proyecto, dado que el equipo trabaja de forma más eficiente cuando tiene objetivos a corto plazo. Asímismo, con iteraciones cortas la precisión de las estimaciones aumenta. El tamaño depende de:o Los condicionantes del proyecto.o La necesidad de tener feedback más o menos rápido.o Que no se degrade la relación trabajo útil / gestión operativa (por ejemplo

reuniones, actividades necesarias que no producen valor directo, etc.). Utilizar iteraciones regulares, de manera que todas sean un timebox de la misma

duración.o El equipo aprende a calcular la velocidad de desarrollo, la cantidad de

trabajo que puede hacer en una iteración (sin tener que hacer extrapolaciones si las iteraciones no fuesen regulares).

o El cliente puede proyectar cuantas iteraciones se necesitan para tener cada entrega, en función de la velocidad de desarrollo del equipo (el trabajo que pudo completar en iteraciones anteriores del mismo tamaño), y tomar decisiones al respecto.

o Permite gestionar y sincronizar de manera sencilla las necesidades del proyecto con respecto a las de otros proyectos (integración con el trabajo realizado por otros equipos, compartición de personas que son difíciles de asignar a un único equipo).

o Las iteraciones coincidiendo con meses naturales permiten sincronizar el trabajo del equipo con el de otros departamentos y con el resto de la organización (por ejemplo, la organización puede tener medidas de resultados y objetivos a nivel trimestral o cuatrimestral).