1. 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

2. 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

3. 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.

4. 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 software Objeto
13 Modelo de diseño Objeto

5. 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ón
 Es 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

6. Noción
 Es 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ón
 Es 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ón
 Es 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ón
 Es el encargado de realizar el modelo de diseño.
 Es el encargado de realizar el modelo de arquitectura de software.

7. 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ón
 Es 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ón
 Es 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.

8. Símbolo Nº:
8
Tipo: Objeto
Nombre/s Especificación de requisitos
Noción
 Es 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ón
 Es 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ón
 Indica 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.

9.  Se vuelven a realizar las actividades de análisis y codificación.
Símbolo
Nº:11
Tipo: Estado
Nombre/s Incremento validado
Noción
 Indica 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ón
 Es 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ón
 Es 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.

10. Símbolo Nº:
14
Tipo: Objeto
Nombre/s Núcleo
Noción
 Es 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ón
 Documento 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ón
 Es 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

11. considera producto incompleto.
Símbolo
Nº:17
Tipo: Estado
Nombre/s Producto completo
Noción
 Sucede 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ón
 Sucede 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ón
 Es 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.

12. Símbolo
Nº:20
Tipo: Verbo
Nombre/s Prueba de aceptación
Noción
 Sucede 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ón
 Sucede 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ón
 Sucede 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.

13.  El desarrollador se encarga de corregir los errores detectados.
Símbolo
Nº:23
Tipo: Sujeto
Nombre/s Tester
Noción
 Es 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.

14. 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.
Lo s m odelos “Iterativo Incremental” y “Espira l” (entre otros) son dos de los más co nocidos 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

15. 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

16. 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

17. 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.

18. 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.

19. 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.

20. 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.

21. 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).