Iterativo e Incremental-1.ppt







Los miniproyectos
Los beneficios de un proceso iterativo
controlado
Los Hitos
Iterativo e incremental en pocas palabras
Desarrollo en pequeños pasos
Lo que no es una iteración
•
•
•
•
•
El desarrollo de un producto software comercial supone
un gran esfuerzo que puede durar entre varios meses
hasta posiblemente un año o más.
Es práctico dividir el trabajo en partes más pequeñas o
miniproyectos.
Cada miniproyecto es una iteración que resulta en un
incremento.
Las iteraciones hacen referencia a pasos en el flujo de
trabajo, y los incrementos, al crecimiento del producto.
Para una efectividad máxima, las iteraciones deber estar
controladas; esto es, deben seleccionarse y ejecutarse
de una forma planificada.
Es por esto por lo que son miniproyectos.
•
•
•
•
•
Los desarrolladores basan la selección de lo que se
implementará en una iteración en dos factores.
En primer lugar, la iteración trata un grupo de casos de uso
que juntos amplían la utilidad del producto desarrollado hasta
ahora.
En segundo lugar, la iteración trata los riesgos más
importantes. Las iteraciones sucesivas se construyen sobre los
artefactos de desarrollo tal como quedaron al final de la última
iteración.
Al ser miniproyectos, comienzan con los casos de uso y
continúan a través del trabajo de desarrollo subsiguiente —
análisis, diseño, implementación y prueba—, que termina
convirtiendo en código ejecutable los casos de uso que se
desarrollaban en la iteración.
Por supuesto, un incremento no necesariamente es aditivo.
Especialmente en las primeras fases del ciclo de vida, los
desarrolladores pueden tener que reemplazar un diseño
superficial por uno más detallado o sofisticado.
En fases posteriores, los incrementos son típicamente
aditivos.
•
•
•
•
•
•
En cada iteración, los desarrolladores identifican y especifican los
casos de uso relevantes, crean un diseño utilizando la arquitectura
seleccionada como guía, implementan el diseño mediante
componentes, y verifican que los componentes satisfacen los casos de
uso.
Si una iteración cumple con sus objetivos —como suele suceder— el
desarrollo continúa con la siguiente iteración.
Cuando una iteración no cumple sus objetivos, los desarrolladores
deben revisar sus decisiones previas y probar con un nuevo enfoque.
Para alcanzar el mayor grado de economía en el desarrollo, un equipo
de proyecto intentará seleccionar sólo las iteraciones requeridas para
lograr el objetivo del proyecto.
Intentará secuenciar las iteraciones en un orden lógico. Un proyecto
con éxito se ejecutará de una forma directa, sólo con pequeñas
desviaciones del curso que los desarrolladores planificaron
inicialmente.
Por supuesto, en la medida en que se añadan iteraciones o se altere
el orden de las mismas por problemas inesperados, el proceso de
desarrollo consumirá más esfuerzo y tiempo.
Uno de los objetivos de la reducción del riesgo es minimizar los
problemas inesperados.
Regresar
•
•
•
•
•
La iteración controlada reduce el coste del riesgo a los
costes de un solo incremento.
Si los desarrolladores tienen que repetir la iteración, la
organización sólo pierde el esfuerzo mal empleado de la
iteración, no el valor del producto entero.
La iteración controlada reduce el riesgo de no sacar al
mercado el producto en el calendario previsto.
Mediante la identificación de riesgos en fases tempranas
del desarrollo, el tiempo que se gasta en resolverlos se
emplea al principio de la planificación, cuando la gente
está menos presionada por cumplir los plazos.
En el método "tradicional", en el cual los problemas
complicados se revelan por primera vez en la prueba del
sistema,
el
tiempo
necesario
para
resolverlos
normalmente es mayor que el tiempo que queda en la
planificación, y casi siempre obliga a retrasar la entrega.
•
•
•
La iteración controlada acelera el ritmo del esfuerzo
de desarrollo en su totalidad debido a que los
desarrolladores trabajan de manera más eficiente
para obtener resultados claros a corto plazo, en
lugar de tener un calendario largo, que se prolonga
eternamente.
La iteración controlada reconoce una realidad que a
menudo se ignora —que las necesidades del
usuario y sus correspondientes requisitos no
pueden definirse completamente al principio.
Típicamente, se refinan en iteraciones sucesivas.
Esta forma de operar hace más fácil la
adaptación a los requisitos cambiantes.
•
•
•
•
Estos conceptos —los de desarrollo dirigido por
los casos de uso, centrado en la arquitectura,
iterativo e incremental— son de igual
importancia.
La arquitectura proporciona la estructura sobre
la cual guiar las iteraciones, mientras que los
casos de uso definen los objetivos y dirigen el
trabajo de cada iteración.
La eliminación de una de las tres ideas
reduciría drásticamente el valor del Proceso
Unificado.
Es como un taburete de tres patas.
Sin una de ellas, el taburete se cae.
Regresar
•
•
Un proceso de desarrollo de software debe
tener una secuencia de hitos claramente
articulados
para
ser
eficaz,
que
proporcionen a los directores y al resto del
equipo del proyecto los criterios que
necesitan para autorizar el paso de una fase
a la siguiente dentro del ciclo del producto.
Dentro de cada fase, el proceso pasa por
una serie de iteraciones e incrementos que
nos conducen a esos criterios.





En la fase de inicio el criterio esencial es la viabilidad, que
llevamos a cabo mediante:
La identificación y la reducción de los riesgos (Sección
12.5) críticos para la viabilidad del sistema.
La creación de una arquitectura candidata a partir del
desarrollo de un subconjunto clave de los requisitos,
pasando por el modelado de los casos de uso.
La realización de una estimación inicial de coste, esfuerzo,
calendario y calidad del producto con límites amplios.
El inicio del análisis del negocio (Capítulos 12 a 16) por el
cual
el
proyecto
parece
que
merece
la
pena
económicamente, una vez más con límites amplios.
•
•
•
•
•
En la fase de elaboración, el criterio esencial es la
capacidad de construir el sistema dentro de un
marco de trabajo económico, que llevamos a cabo
mediante:
La identificación y la reducción de los riesgos que
afectan de manera significativa a la construcción del
sistema.
La especificación de la mayoría de los casos de uso que
representan la funcionalidad que ha de desarrollarse.
La extensión de la arquitectura candidata hasta las
proporciones de una línea base.
La preparación del plan del proyecto con suficiente
detalle como para guiar la fase de construcción.
La realización de una estimación con unos límites
suficientemente ajustados como para justificar la
inversión.



La terminación del análisis del negocio —el
proyecto merece la pena.
En la fase de construcción, el criterio esencial es
un sistema capaz de una operatividad inicial en el
entorno del usuario, y lo llevamos a cabo
mediante:
Una serie de iteraciones, que llevan a
incrementos y entregas periódicos, de forma que
a lo largo de esta fase, la viabilidad del sistema
siempre es evidente en la forma de ejecutables.
•
•
•
•
•
•
En la fase de transición, el criterio esencial es un sistema que
alcanza una operatividad final, llevado a cabo mediante:
La modificación del producto para subsanar problemas que no se
identificaron en fases anteriores.
La corrección de defectos (Sección 11.3.6).
Uno de los objetivos del Proceso Unificado es hacer que los
arquitectos, desarrolladores e interesados en general comprendan la
importancia de las primeras fases. Acerca de esto, no podemos hacer
nada mejor que citar el consejo de Barry Boehm de hace unos años:
«No puedo recalcar suficiente cuan crítico es para su proyecto y para
su carrera el hito de la Arquitectura del Ciclo de Vida (ACV) [que se
corresponde con nuestro hito de la fase de elaboración].
Si no ha cumplido con el criterio del hito ACV, no prosiga en un
desarrollo a escala completa.
Reúna de nuevo a los usuarios y obtenga un nuevo plan de! proyecto
que cumpla con éxito los criterios ACV.
•
•
•
•
•
Como indicamos en los Capítulos 3 y 4, dos de las tres
claves del Proceso Unificado son que el proceso de
desarrollo software debería estar dirigido por los casos
de uso y centrado en la arquitectura.
Estos aspectos tienen un impacto técnico evidente sobre
el producto del proceso.
El estar dirigido por los casos de uso significa que cada
fase en el camino al producto final está relacionada con
lo que los usuarios hacen realmente.
Lleva a los desarrolladores a garantizar que el sistema
se ajusta a las necesidades reales del usuario.
El estar centrado en la arquitectura significa que el
trabajo de desarrollo se centra en obtener el patrón de
la arquitectura que dirigirá la construcción del sistema
en las primeras fases, garantizando un progreso
continuo no sólo para la versión en curso del producto,
sino para la vida entera del mismo.
Regresar
•
•
•
•
•
Conseguir el equilibrio correcto entre los casos de uso y
la arquitectura es algo muy parecido al equilibrado de la
forma y la función en el desarrollo de cualquier
producto.
Se consigue con el tiempo. Lo que nos encontramos
primero, como dijimos en la Sección 4.3, es un
problema de la “gallina y el huevo”.
La gallina y el huevo se consiguen a lo largo de
iteraciones casi sin fin durante el largo proceso de la
evolución.
De manera similar, durante el más corto proceso de
desarrollo de software, los desarrolladores elaboran
conscientemente este equilibrio (entre casos de uso y
arquitectura) a lo largo de una serie de iteraciones.
Por tanto, la técnica de desarrollo iterativo e incremental
constituye el tercer aspecto clave del Proceso Unificado.
Regresar
•
•
•
•
•
•
•
•
La tercera clave proporciona la estrategia para
desarrollar un producto software en pasos pequeños
manejables:
Planificar un poco.
Especificar, diseñar, e implementar un poco.
Integrar, probar, y ejecutar un poco cada iteración.
Si estamos contentos con un paso, continuamos con el
siguiente.
Entre cada paso, obtenemos retroalimentación que nos
permite ajustar nuestros objetivos para el siguiente
paso.
Después se da el siguiente paso, y después otro.
Cuando se han dado todos los pasos que habíamos
planificado, tenemos un producto desarrollado que
podemos distribuir a nuestros clientes y usuarios.
•
•
•
•
•
•
Las iteraciones en las primeras fases tratan en su mayor parte con la
determinación del ámbito del proyecto, la eliminación de los riesgos
críticos, y la creación de la línea base de la arquitectura.
Después, a medida que avanzamos a lo largo del proyecto y vamos
reduciendo gradualmente los riesgos restantes e implementando los
componentes, la forma de las iteraciones cambia, dando incrementos
como resultados.
Un proyecto de desarrollo software transforma una “delta” (un
cambio) de los requisitos de usuario en una delta del producto
software (Sección 2.2).
Con el método de desarrollo iterativo e incrementa] esta adaptación
de los cambios se realiza poco a poco.
Dicho de otra forma, dividimos el proyecto en un número de
miniproyectos, siendo cada uno de ellos una iteración.
Cada iteración tiene todo lo que tiene un proyecto de desarrollo de
software: planificación, desarrollo en una serie de flujos de trabajo
(requisitos, análisis y diseño, implementación y prueba), y una
preparación para la entrega.
•
•
•
•
•
•
•
Pero una iteración no es una entidad completamente
independiente.
Es una etapa dentro de un proyecto, y se ve fuertemente
condicionada por ello.
Decimos que es un miniproyecto porque no es por sí misma
algo que nuestros usuarios nos hayan pedido que hagamos.
Además, cada uno de estos miniproyectos se parece al antiguo
ciclo de vida en cascada debido a que se desarrolla a través de
actividades en cascada.
Podríamos llamar una “minicascada” a cada iteración.
El ciclo de vida iterativo produce resultados tangibles en forma
de versiones internas (aunque preliminares), y cada una de
ellas aporta un incremento y demuestra la reducción de los
riesgos con los que se relaciona.
Estas versiones pueden presentarse a los clientes y usuarios,
en cuyo caso proporcionan una retroalimentación valiosa para
la validación de) trabajo.
•
•
•
•
Los jefes de proyecto tratarán de ordenar las iteraciones para
conseguir una vía directa en la cual las primeras iteraciones
proporcionen la base de conocimiento para las siguientes.
Las primeras iteraciones del proyecto consiguen incrementar la
comprensión de los requisitos, el problema, los riesgos y el
dominio de la solución mientras que las restantes añaden
incrementos que al final conformarán la versión externa, es
decir, el producto para el cliente.
El éxito fundamental —para los jefes de proyecto— es
conseguir una serie de iteraciones que siempre avanzan; es
decir, que nunca hay que volver dos o tres iteraciones atrás
para corregir el modelo debido a algo que hemos aprendido en
la última iteración.
No queremos escalar una montaña de nieve que se funde,
dando dos pasos adelante y resbalando uno hacia atrás.
•
•
•
•
•
•
En resumen, un ciclo de vida se compone de una secuencia de
iteraciones.
Algunas de ellas, especialmente las primeras, nos ayudan a
comprender los riesgos, determinar la viabilidad, construir el
núcleo interno del software, y realizar el análisis del negocio.
Otras, en especial las últimas, incorporan incrementos hasta
conseguir un producto preparado para su entrega.
Las iteraciones ayudan a la dirección a planificar, a organizar, a
hacer el seguimiento y a controlar el proyecto.
Las iteraciones se organizan dentro de las cuatro fases, cada
una de ellas con necesidades concretas de personal,
financiación y planificación, y con sus propios criterios de
comienzo y fin.
Al comienzo de cada fase, la dirección puede decidir cómo
llevarla a cabo, los resultados que deben entregarse, y los
riesgos que deben reducirse.
Regresar
•
•
•
•
•
•
Algunos directores creen que “iterativo e incrementar’ es
un eufemismo de “hacking”’, y temen que esas palabras
solamente ocultan la realidad de que los desarrolladores
no saben lo que están haciendo.
En la fase de inicio, e incluso al principio de la fase de
elaboración, puede que haya algo de verdad en ello.
Por ejemplo, si los desarrolladores no han resuelto
riesgos críticos o significativos, entonces la proposición
es cierta.
Si aún no han probado el concepto subyacente, o no han
establecido la línea base de la arquitectura, también es
cierta.
Lo es también si aún no han decidido cómo implementar
los requisitos más importantes.
En realidad, podría ser que no supieran lo que están
haciendo.
•
•
•
•
•
•
•
•
¿Ayuda en algo el pretender que saben lo que están
haciendo?
¿Es de algún provecho basar un plan sobre una
información insuficiente?
¿Sirve para algo comenzar ese plan no fiable?
Por supuesto que no.
Para concretar, vamos a recalcar lo que no es un ciclo de vida
iterativo:
No es un desarrollo aleatorio.
No es un parque de juegos para los desarrolladores.
No es algo que afecte sólo a los desarrolladores.
No es rediseñar una y otra vez lo mismo hasta que al final los
desarrolladores prueben algo que funciona.
No es algo impredecible.
No es una excusa para fracasar en la planificación y en la
gestión.
•
•
•
•
De hecho, la iteración controlada está muy
lejos de ser aleatoria.
Se planifica
Es una herramienta que pueden utilizar los
directores para controlar el proyecto.
Reduce, al principio del ciclo de vida, los
riesgos que pueden amenazar el progreso del
desarrollo.
Las versiones internas tras las iteraciones
posibilitan la retroalimentación de los usuarios,
y esto lleva a su vez a una corrección temprana
de la trayectoria del proyecto.
Regresar