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: plani ficació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