Download - Modelo incremental
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).