METODOLOGIA DE RUP

(1)
El Rational Unified Process o Proceso Unificado de Racional.Es un
proceso de ingeniera de software que suministra un enfoque para asignar
tareas y responsabilidades dentro de una organizacin de desarrollo. Su
objetivo es asegurar la produccin de software de alta y de mayor calidad para
satisfacer las necesidades de los usuarios que tienen un cumplimiento al final
dentro de un limite de tiempo y presupuesto previsible.Es una metodologa
de desarrollo iterativo que es enfocada hacia diagramas de los casos de uso,
y manejo de los riesgos y el manejo de la arquitectura como tal.
El RUP mejora la productividad del equipo ya que permite que cada miembro
del grupo sin importar su responsabilidad especfica pueda acceder a la misma
base de datos incluyendo sus conocimientos. Esto hace que todos compartan
el mismo lenguaje, la misma visin y el mismo proceso acerca de cmo
desarrollar un software.

METODOLOGIA DE RUP
(2)
Es una metodologa cuyo fin es entregar un producto de software. Se
estructura todos los procesos y se mide la eficiencia de la organizacin.
Es un proceso de desarrollo de software el cual utiliza el lenguaje
unificado de modelado UML, constituye la metodologa estndar ms
utilizada para el anlisis, implementacin y documentacin de sistemas
orientados a objetos.
El RUP es un conjunto de metodologas adaptables al contexto y
necesidades de cada organizacin.
Describe como aplicar enfoques para el desarrollo del software,
llevando a cabo unos pasos para su realizacin.
Se centra en la produccin y mantenimiento de modelos del sistema.

METODOLOGIA DE RUP
(3)
El Proceso Racional Unificado es un proceso de desarrollo de
software y junto con el Lenguaje Unificado de ModeladoUML,
constituye la metodologa estndar ms utilizada para el
anlisis, implementacin y documentacin de sistemas
orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos,
sino un conjunto de metodologas adaptables al contexto y
necesidades de cada organizacin. Originalmente se dise un
proceso genrico y de dominio pblico, elProceso Unificado, y
una especificacin ms detallada, el Rational Unified Process,
que se vendiera como producto independiente.

METODOLOGIA
DE RUP (4)
El ciclo de vida RUP es una implementacin del Desarrollo
en espiral. Fue creado ensamblando los elementos en
secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en 4 fases e iteraciones en nmero variable segn el
proyecto y en las que se hace un mayor o menor hincapi
en los distintas actividades.

METODOLOGIA DE RUP
(5)
RUP (Rational Unified Process) es una secuencia de pasos
necesarios para el desarrollo y/o mantenimiento de gran cantidad
de sistemas, en diferentesreasdeaplicacin diferentes
organizaciones, diferentes medios de competencia y en proyectos
de tamaos variables (desde el masbsicoal mas complejo).
Actualmente es propiedad de International Business Machines
(IBM) y esta basado en un enfoque disciplinado deasignacinde
tareas y responsabilidades dentro de unaorganizacinde
desarrollo con la finalidad deasegurarlaobtencinde un
software de alta calidad que satisfagan la necesidad de los
usuarios finales dentro de un calendario y tiempo predecible.

FASES DE RUP (1)

RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el
proyecto y en las que se hace un mayor o menor hincapi en los distintas actividades.
Inicio
Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos
asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el
de iteraciones posteriores.
Elaboracin
En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se
desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio
del problema, se disea la solucin preliminar.
Construccin
El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos
pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras
para el proyecto.
Transicin
El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y
defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se
debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

FASES DE RUP (2)

Inicio (Inception)
El objetivo general de esta fase esestablecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto.
Es significativamente importante para el desarrollo de nuevo software, ya quese asegura de identificar los riesgos relacionados
con el negocio y requerimientos.
Para proyectos de mejora de software existente, esta fase es ms breve y se centra en asegurar la viabilidad de desarrollar el proyecto.
Elaboracin
El objetivo en esta fase esestablecer la arquitectura base del sistemapara proveer bases estables para el esfuerzo de diseo e
implementacin en la siguiente fase.
La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluacin del riesgo.
Construccin
El objetivo de la fase de construccin esclarificar los requerimientos faltantes y completar el desarrollo del sistemabasados en
la arquitectura base.
Vista de cierta forma esta fase es un proceso de manufactura, en el cual el nfasis se torna hacia la administracin de recursos y control
de la operaciones para optimizar costos, tiempo y calidad.
Transicin
Esta fase se enfoca enasegurar que el software est disponible para sus usuarios.
Se puede subdividir en varias iteraciones, adems incluye pruebas del producto para poder hacer el entregable del mismo, as como
realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario.
En este punto, la retroalimentacin de los usuarios se centra en depurar el producto, configuraciones, instalacin y aspectos sobre
utilizacin.

FASES DE RUP (3)

1.Fase de Inicio:Esta fase tiene como propsito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura
de software y producir el plan de las fases y el de iteraciones posteriores.
2.Fase de elaboracin:En la fase de elaboracin se seleccionan los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso
seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar.
3.Fase de Desarrollo:El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben
clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por
los usuarios y se realizan las mejoras para el proyecto.
4.Fase de Cierre:El propsito de esta fase es asegurar que el software est disponible para los usuarios
finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y
proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones
entregadas por las personas

FASES DE RUP (4)

Las fases del ciclo de vida del RUP son:
1. Inicio.-define el alcance de los objetivos del proyecto,
identifica los riesgos del negocio y sus requerimientos.
2. Elaboracin.-contempla el plan del proyecto, la especificacin
de sus caractersticas y su arquitectura base.
3.Construccin.-clarifica
construirel producto.

los

requerimientos

faltantes

para

4. Transicin.-asegura que producto llegue a las manos del

usuario.

FASES DE RUP (5)

Las fases del ciclo de vida del RUP son:
1. Inicio.-define el alcance de los objetivos del proyecto,
identifica los riesgos del negocio y sus requerimientos.
2. Elaboracin.-contempla el plan del proyecto, la especificacin
de sus caractersticas y su arquitectura base.
3.Construccin.-clarifica
construirel producto.

los

requerimientos

faltantes

para

4. Transicin.-asegura que producto llegue a las manos del

usuario.

Planeamiento Dirigido por Riezgo (1)

El xito en el campo de la gestin de riesgos, como en el juego
del ajedrez, exige inteligencia, experiencia y estrategia. As
como jugar ajedrez sin un plan es sinnimo de una derrota
segura, administrar un proyecto sin un plan riguroso de manejo
de riesgos es la cuota inicial para el fracaso del proyecto.
Es bien sabido que la planeacin de la contingencia y otras
estrategias de manejo de riesgos, no solamente aseguran la
continuidad del proyecto en momentos de crisis, sino que
tambin ahorran tiempo y dinero y aumentan la credibilidad.

Planeamiento Dirigido por Riezgo (2)

Un buen gerente de proyectos enfoca su gestin de riesgos de la
misma forma en que un Gran Maestro orienta su juego de ajedrez. El
Gran Maestro constantemente se anticipa, en profundidad, a las
jugadas de su oponente, a las cientos o miles de combinaciones
posibles que en unas cuantas jugadas ms adelante pueden
terminar con un jaque mate.
Para ello, el gerente de proyectos (el Gran Maestro) debe tener una
estrategia definida, porque as como un juego de ajedrez no deja de
ser un conjunto de trucos tcticos si el jugador no define una
estrategia, el proyecto no dejar de ser una pila de actividades que
no conducen a ningn lado si el gerente no define un buen plan de
manejo de riesgos.

Planeamiento Dirigido por Riezgo (3)

El equipo de desarrollo se junta para crear una lista de todos
los posibles riesgos que en algn momento pudieran afectar
al proyecto. Esta lista nace a partir de un anlisis del
proyecto, tanto general como por cada paquete de trabajo, y
as localizar las principales fuentes generadoras de riesgo.
En RUP existen dos tipos de riesgos:
Directos: el personal tiene cierto control sobre ellos.
Indirectos: no pueden ser controlados.

Planeamiento Dirigido por Riezgo (4)

Adems se cuenta con los riesgos generados a partir de los recursos del proyecto:
Organizacin
Falta de compromiso del personal hacia el proyecto.
Falta de planeacin y definicin en el proceso de ingeniera de software.
El proyecto es el ms largo antes intentado.
Recursos
Falta de recursos para completar el proyecto.
Limitaciones de presupuesto: el sistema debe ser entregado en un costo fijo o se va a cancelar.
Los estimados de costos sean inexactos.
Personal
Falta de personal disponible para el proyecto.
El personal no tiene las habilidades y experiencia necesarias.
El personal no cree en el proyecto.-no hay expertos en el rea disponibles.
Tiempo
La agenda no es realista.
No hay tiempo para hacerlo bien.

Planeamiento Dirigido por Riezgo (5)

Otros de los riesgos que pueden aparecer en el proyecto son los tcnicos, dentro de ellos
encontramos:
Alcance. El xito no puede ser medido. Los requerimientos no son estables ni entendibles.
Los tiempos de desarrollo son inflexibles y limitados.
Tecnolgicos. El xito del proyecto dependa de productos, servicios, tecnologas nuevos
que no hayan sido probados antes.
Dependencias del sistema con otros sistemas externos, y que estos fallen.
Requerimientos de disponibilidad y seguridad inflexibles.
El proyecto es inalcanzable (muy complejo o enorme como para trabajar apropiadamente).
Dependencia externa. El proyecto depende de proyectos en desarrollo paralelo.
El xito depende de la integracin de herramientas de desarrollo (compiladores,
herramientas de diseo, etc.), tecnologas de implementacin (sistema operativo, bases de
datos, etc.).

Disciplina (1)
QU SON ?

Un conjunto de actividades relacionadas con un rea especifica dentro del proyecto.

Estn inspiradas en las etapas de un proceso de desarrollo en cascada
Es una secuencia parcialmente ordenada de actividades que son realizadas para lograr un resultado particular, representado en un conjunto de artefactos.

CULES SON ?
- Modelado de Negocios, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Transicin, Configuracin y Administracin del Cambio, Administracin de
Proyectos y Ambiente.
En proyectos de nuevos productos de software
En ciclos de desarrollo subsecuentes

Disciplina (2)
Unadisciplinaes una coleccin de actividades relacionadas con un rea de atencin dentro de
todo el proyecto.
El grupo de actividades que se encuentran dentro de una disciplina principalmente son una ayuda
para entender el proyecto desde la perspectiva clsica de cascada.
Estn inspiradas en las etapas de un proceso de desarrollo en cascada
Es una secuencia parcialmente ordenada de actividades que son realizadas para lograr un
resultado particular, representado en un conjunto de artefactos.
y las Disciplinas son:
Modelado de Negocios Requerimientos
Anlisis y Diseo Implementacin
Pruebas Transicin
Configuracin y Administracin del Cambio Administracin de Proyectos
Ambiente

Disciplina (3)
Las disciplinas estn muy
apegadas a lo que son los roles,
pues cada rol debe abarcar y
especializarse en ciertas
actividades del proceso. Las
disciplinas son precisamente
eso:una coleccin
deactividadesrelacionadas
con un rea de atencin
dentro de todo el proyecto.

Disciplina (4)
Unadisciplinaes una coleccin de actividades relacionadas con un rea de atencin dentro de
todo el proyecto.
El grupo de actividades que se encuentran dentro de una disciplina principalmente son una ayuda
para entender el proyecto desde la perspectiva clsica de cascada.
Estn inspiradas en las etapas de un proceso de desarrollo en cascada
Es una secuencia parcialmente ordenada de actividades que son realizadas para lograr un
resultado particular, representado en un conjunto de artefactos.
y las Disciplinas son:
Modelado de Negocios Requerimientos
Anlisis y Diseo Implementacin
Pruebas Transicin
Configuracin y Administracin del Cambio Administracin de Proyectos
Ambiente

Disciplina (5)
Durante el ciclo de vida RUP, cada iteracion es llevada a cabo por dos disciplinas que son disciplina de Desarrollo y
disciplina de Soporte
La disciplina de Desarrollo esta estructurada de la siguiente manera:
Ingenierade negocios:es aplicada para entender las necesidades y la cultura empresarial dentro de laorganizacin.
Requerimientos:para trasladar las necesidades a un sistema automatizado.
Anlisisy Diseo:permite representar los requerimientos obtenidos en una arquitectura de software.
Implementacin:se crea un software que se ajuste a la arquitectura alcanzada y que tenga el comportamiento
deseado.
Pruebas:permite asegurar que el comportamiento requerido sea el correcto y que todo lo lo solicitado este presente.
La disciplina de Soporte se estructura del modo siguiente:
ConfiguracinyAdministracindel Cambio:guarda todas las versiones delproyecto.
AdministracinDirecta del Proyecto:administra los horarios y recursos.
Ambiente:gestiona todo el entorno de desarrollo.
Distribucin:hace todo lo necesario para la salida del proyecto

Beneficio Iterativo e Incremental (1)

Desarrollo iterativo y creciente(o incremental) es un proceso de
desarrollo de software creado en respuesta a las debilidades del modelo
tradicional de cascada.
Bsicamente este modelo de desarrollo, que no es ms que un conjunto
de tareas agrupadas en pequeas etapas repetitivas (iteraciones),1es
uno de los ms utilizados en los ltimos tiempos ya que, como se
relaciona con novedosas estrategias de desarrollo de software y una
programacin extrema, es empleado en metodologas diversas.
El modelo consta de diversas etapas de desarrollo en cada incremento,
las cuales inician con el anlisis y finalizan con la instauracin y
aprobacin del sistema.

Beneficio Iterativo e Incremental (2)

Desarrollo iterativo y creciente(o incremental) es un proceso de
desarrollo de software creado en respuesta a las debilidades del modelo
tradicional de cascada.
Bsicamente este modelo de desarrollo, que no es ms que un conjunto
de tareas agrupadas en pequeas etapas repetitivas (iteraciones),1es
uno de los ms utilizados en los ltimos tiempos ya que, como se
relaciona con novedosas estrategias de desarrollo de software y una
programacin extrema, es empleado en metodologas diversas.
El modelo consta de diversas etapas de desarrollo en cada incremento,
las cuales inician con el anlisis y finalizan con la instauracin y
aprobacin del sistema.

Beneficio Iterativo e Incremental (3)

El ciclo de vida iterativo e incremental es una de las buenas prcticas
de ingeniera del software ms antiguas, su primer uso en el software se
data en los 50 (te dejoeste post donde hablamos del tema ).
Adems, el ciclo de vida iterativo e incrementales una de las bases de un
proyecto gil, ms concretamente, con iteraciones cortas en tiempo, de pocas
semanas, normalmente un mes y raramente ms de dos.
Normalmente se habla, se lee, etc., el ciclo de vida iterativo e incremental (o
incluso por defecto slo el el ciclo de vida iterativo). Pero ellono quiere decir
que iterativo e incremental sea lo mismo.De hecho, el desarrollo iterativo
no implica, ni presupone el uso del incremental, y viceversa.
El problema es que muchas veces se olvida la parte iterativa, del ciclo de
vida iterativo e incremental. Pero veamos antes qu implica incremental y qu
iterativo.

Beneficio Iterativo e Incremental (4)

La principal caracterstica de estos modelos es que permite crear cada vez versiones ms completas de software, para esto construimos versiones sucesivas de un producto. Se crea una
primera versin que es utilizada por el usuario donde se provee retroalimentacin al desarrollador, y segn los requerimientos especificados de ste usuario se crea una segunda versin.
Modelo Incremental.Como vimos este era un modelo tipo cascada el cual origina una primera versin con su respectiva funcionalidad, aplicamos de nuevo cascada sobre aquella versin 1 y obtenemos como
resultado una versin 2 ms una funcionalidad 2. Este proceso aplicamos cada vez que deseamos crear una versin ms completa segn los requerimientos de nuestro cliente.
El modelo incremental se aplica cuando en un proyecto tenemos un tiempo lmite y no disponemos del personal suficiente para que nuestro propsito sea implementado completamente.
Adems existen altos riesgos en este modelo pero se los puede reducir si tan solo construimos una parte del sistema y dejamos lo dems para complementarlo en versiones posteriores.
Modelo Iterativo.A diferencia del modelo incremental, al modelo iterativo no se le agrega funcionalidad si no que en cada iteracin se mejora su funcionalidad.
Ventajas
Las ventajas que ofrece un desarrollo iterativo e incremental son varias y variadas, pero debe quedar claro que es muy difcil obtener todas juntas ya que depende del contexto en el que se
implemente el proceso. En general las ventajas son:
Resolucin de problemas de alto riesgo en tiempos tempranos del proyecto.
Visin de avance en el desarrollo desde las etapas iniciales del desarrollo.
Obtencin del feedback del usuario lo antes posible, para orientar el desarrollo al cumplimiento de sus necesidades y realizar todas las adaptaciones identificadas para cumplir con los
objetivos planteados.
Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad de defectos, segn demuestran estudios realizados sobre proyectos que han aplicado esta tcnica.
Permite manejar la complejidad del proyecto, apuntando a la resolucin de los problemas por partes, y no caer en la inanicin del sper anlisis del producto.
El aprendizaje y experiencia del equipo iteracin tras iteracin, mejora exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso en el corto plazo.
El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando las planificaciones, logrando menores desvos en la duracin total del proyecto.
Su adopcin, con ciertos recaudos, no presenta grandes inversiones.
DESVENTAJAS
Hasta el momento se podra decir que no existen grandes desventajas, pero s hay puntos a manejar con sumo cuidado:
El uso de un desarrollo iterativo e incremental no garantiza por s solo el xito de su uso.
Hay costos ocultos en su implementacin, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento.

Beneficio Iterativo e Incremental (5)

Se puedegestionar las expectativas del cliente(requisitos desarrollados, velocidad de desarrollo, calidad)de maneraregular, puede tomar decisiones en cada
iteracin. Esto es especialmente interesante cuando:
El cliente no sabe exactamente qu es lo que necesita, lo va sabiendo conforme va viendo cuales son los resultados del proyecto.
El cliente necesita hacercambios a corto plazo(nuevos requisitos o a cambios en los ya realizados) por:
Cambios en las condiciones del mercado(por un cambio de necesidades, por un nuevo producto que ha lanzado la competencia, urgencias).
La reaccin y aceptacin del mercadorespecto al uso de los primeros resultados del proyecto.
Cualquier cambio en el entorno (recursos, etc.), que pueda incluso finalizar el proyecto manteniendo como mnimo los resultados alcanzados hasta ese momento.

El equipo necesita saber si lo que ha entendido es lo que el cliente espera.

El cliente puedecomenzar el proyecto con requisitos de alto nivel, quizs no del todo completos, de manera que se vayan refinando en sucesivas iteraciones.Slo es
necesario conocer con ms detalle los requisitos de las primeras iteraciones, los que ms valor aportan. No es necesario realizar una recoleccin completa y
detallada de todos los requisitos antes de empezar el desarrollo del proyecto.
El cliente puedeobtener resultados importantes y usables ya desde las primeras iteraciones.
Se puedegestionar de manera natural los cambiosque van apareciendo durante el proyecto. La finalizacin de cada iteracin es el lugar natural donde el cliente puede
proporcionar su feedback tras examinar el resultado obtenido (vercontrol empricoydemostracin). Con esta informacin 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 mximo puede perder los recursos dedicados a una iteracin, no los de todo el proyecto.
La finalizacin de cada iteracin es ellugar natural donde el equipo puede decidir cmo mejorar su proceso de trabajo, en funcin de la experiencia obtenida. Con
esta informacin ya es posibleplanificar los cambios necesarios para aumentar la productividad y calidaddesde las primeras iteraciones. VerRetrospectiva.
Permiteconocer el progreso real del proyectodesde las primeras iteraciones y extrapolar si sufinalizacin es viable en la fecha prevista. El cliente puede decidir
repriorizar los requisitos del proyecto, aadir nuevos equipos, cancelarlo, etc.
Permitemitigar desde el inicio los riesgosdel proyecto. Desde la primera iteracin el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del
proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigacin de manera anticipada.
Permitegestionar la complejidad del proyecto.
En una iteracin slo se trabaja en los requisitos que aportan ms valor en ese momento.
Se puede dividir la complejidad para que cada parte sea resuelta en diferentes iteraciones.

Dado que cada iteracin debe dar como resultado requisitos terminados,se minimiza el nmero de erroresque se producen en el desarrollo yse aumentar la calidad.

Restricciones
Ladisponibilidad del clientedebe ser alta durante todo el proyecto dado que participa de manera continua:
El inicio de una iteracin, el cliente ha de detallar (o haber detallado previamente) los requisitos que se van a desarrollar.
En la finalizacin de cada iteracin, el cliente ha de revisar los requisitos desarrollados.

La relacin con el cliente ha de estar basada en los principios decolaboracin y ganar/ganarms que tratarse de una relacin
contractual en la cual cada parte nicamente defiende su beneficio a corto plazo.
Cada iteracin debe dar como resultadorequisitos terminados, de manera que el resultado sea realmente til para el
cliente y no deje tareas pendientes para futuras iteraciones o para la finalizacin del proyecto.
Cada iteracin ha de aportar un valoral cliente, entregar unos resultados cerrados que sean susceptibles de ser
utilizados por l.
Es necesariodisponer de tcnicas y herramientas que permitan hacer cambios fcilmente en el producto, de manera que
pueda crecer en cada iteracin de manera incremental sin hacer un gran esfuerzoadicional, manteniendo su complejidad
minimizada y su calidad.
Recomendaciones
Utilizariteraciones cortasde 2 a 4 semanasincrementa laproductividaddel proyecto, dado que el equipo trabaja de
forma ms eficiente cuando tieneobjetivos a corto plazo. Asmismo, con iteraciones cortasla precisin de las
estimaciones aumenta.El tamao depende de:
Loscondicionantes del proyecto.
La necesidad de tener feedback ms o menos rpido.
Que nose degrade la relacin trabajo til / gestin operativa (por ejemplo reuniones, actividadesnecesarias queno producen valor directo,
etc.).

Utilizariteraciones regulares, de manera que todas sean untimeboxde la misma duracin.

El equipo aprende acalcularla velocidadde desarrollo, la cantidad de trabajo que puede hacer en una iteracin(sin tener que hacer
extrapolaciones si las iteraciones no fuesen regulares).
El cliente puedeproyectar cuantas iteraciones se necesitan para tener cada entrega, en funcin de la velocidad de desarrollo del
equipo (el trabajo que pudo completar en iteraciones anteriores del mismo tamao), y tomar decisiones al respecto.
Permite gestionar ysincronizarde manera sencilla las necesidades del proyecto con respecto a las deotros proyectos(integracin con el
trabajo realizado por otros equipos, comparticin de personas que son difciles de asignar a un nico equipo).
Lasiteraciones coincidiendo con meses naturalespermiten sincronizar el trabajo del equipo con el de otros departamentos y con el
resto de la organizacin (por ejemplo, la organizacin puede tener medidas de resultados y objetivos a nivel trimestral o cuatrimestral).