• ¿Por qué un desarrollo iterativo e incremental?

• Atenuación de riesgos• Obtención de una Arquitectura robusta• Gestión de requisitos cambiantes• Permitir cambios tácticos• Conseguir una integración continua• Conseguir un aprendizaje temprano

• En dos palabras: para obtener un “software mejor”. • Dicho con unas cuantas palabras más, para cumplir los hitos

principales y secundarios con los cuales controlamos el desarrollo. Y dicho con algunas palabras más:

• Para tomar las riendas de los riesgos críticos y significativos desde el principio.

• Para poner en marcha una arquitectura que guíe el desarrollo del software.

• Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables cambios en los requisitos y en otros aspectos.

• Para construir el sistema a lo largo del tiempo en lugar de hacerlo de una sola vez cerca del final, cuando el cambiar algo se ha vuelto costoso.

• Para proporcionar un proceso de desarrollo a través del cual el personal puede trabajar de manera más eficaz.

Regresar

• El desarrollo de software se enfrenta con riesgos, al igual que cualquier otra actividad de ingeniería.

• Según la visión del profeta de la dirección Peter F. Drucker: “El riesgo es inherente en el empleo de los recursos disponibles para las expectativas futuras.”

• En el desarrollo de software, afrontamos esta realidad identificando los riesgos tan pronto como sea posible dentro del desarrollo y tratándolos rápidamente.

• Un riesgo es una exposición que nos puede acarrear pérdidas o daños.

• El riesgo es un factor, cosa, elemento o camino que constituye un peligro, cuyo grado es incierto.

• En el desarrollo de software, podemos definir un riesgo como un asunto que tiene cierto grado de probabilidad de poner en peligro el éxito de un proyecto.

Por ejemplo• El object request broker que consideramos inicialmente,

puede que no sea capaz de dar servicio a 1.000 búsquedas de objetos remotos, que representan cuentas de cliente, por segundo.

• Un sistema de tiempo real puede tener que tomar un cierto número de entradas de datos que no se especificaron en la fase de inicio.

• Puede que tenga que procesar los datos mediante cálculos intensivos que aún no se han definido con detalle, o puede que tenga que enviar una señal de control en un tiempo corto que aún no se ha especificado.

• Un sistema de conmutación telefónica puede tener que responder a varias entradas en un número de milisegundos especificado por la empresa de operación de telecomunicaciones cliente.

• Lo que necesita la disciplina del software, como escribió Barry Boehm, es un modelo de proceso que “cree una aproximación al proceso de desarrollo de software dirigida por los riesgos en lugar de un proceso fundamentalmente dirigido por los documentos o dirigido por el código”.

• El Proceso Unificado cumple con estos criterios porque trata los riesgos importantes en las dos primeras fases, inicio y elaboración, y cualquier riesgo restante al principio de la fase de construcción, por orden de importancia.

• Identifica, gestiona, y reduce los riesgos en las primeras fases mediante las iteraciones.

• En consecuencia, los riesgos no identificados o ignorados no emergen más tarde, poniendo en peligro el proyecto entero.

• La técnica iterativa para la reducción de los riesgos recuerda muy poco al método en cascada.

• El modelo en cascada muestra el desarrollo pasando en un solo sentido por una serie de pasos: requisitos, análisis, diseño, implementación y prueba.

• En este método, el proyecto debe implicar a todos sus desarrolladores cuando llega a la implementación, la integración y la prueba.

• Durante la integración y la prueba, los problemas pueden empezar a estallar a su alrededor.

• El jefe de proyecto se verá entonces forzado a reasignar personas —habitualmente a los desarrolladores con más experiencia— para resolver esos problemas antes de que el trabajo pueda continuar.

• Sin embargo, como todos los desarrolladores ya están ocupados, los jefes de proyecto tendrán difícil el “liberar” a los pocos que estén más preparados para resolver los problemas que se acaban de descubrir.

• Para tratar estas dificultades, la reasignación de los desarrolladores con más experiencia para “resolver los problemas” suele dejar a los desarrolladores con menos experiencia sentados esperando.

• Los plazos pasan, y los costes se rebasan. • En el peor caso, nuestra competencia se hace

con el mercado antes que nosotros.

• Si realizamos un gráfico del riesgo comparándolo con el tiempo de desarrollo, como en la Figura 5.1., el desarrollo iterativo empieza a reducir riesgos importantes en las primeras iteraciones.

• En el momento en que el trabajo alcanza la fase de construcción, quedan pocos riesgos importantes, y el trabajo prosigue sin problemas.

• En contraste, si utilizamos el modelo en cascada, los riesgos importantes no se tratan hasta la integración del código al estilo de un “big bang”.

• Cerca de las dos terceras partes de los proyectos software grandes fracasan en la realización de un análisis de riesgos adecuado, según Capers Jones, por tanto, ¡hay lugar para grandes mejoras! Atacar los riesgos al comienzo del proceso de desarrollo es el primer paso.

Regresar

• La consecución de una arquitectura robusta es en sí misma el resultado de las iteraciones en las primeras fases.

• En la fase de inicio, por ejemplo, encontramos una arquitectura esencial que satisface los requisitos clave, evita los riesgos críticos, y resuelve los problemas de desarrollo principales.

• En la fase de elaboración, establecemos la línea base de la arquitectura que guiará el resto del desarrollo.

• Por un lado, la inversión en esas fases es todavía pequeña, y podemos permitirnos las iteraciones que garantizan que la arquitectura es robusta.

• Por ejemplo, después de la primera iteración en la fase de elaboración, estamos en disposición de hacer una evaluación inicial de la arquitectura.

• En este momento, aún podemos permitirnos cambiarla, si eso es lo que hemos decidido, para ajustaría a las necesidades de los casos de uso significativos y a los requisitos no funcionales.

• Si seguimos el método en cascada, en el momento en que descubrimos la necesidad de un cambio en la arquitectura, ya hemos invertido tanto en el desarrollo que hacer un cambio en la arquitectura supone un revés económico importante.

• Además, podríamos estar cerca de la fecha de entrega comprometida.

• Atrapados entre los costes y el calendario, no tendremos la motivación necesaria para hacer un cambio en la arquitectura, podemos evitar este dilema centrándonos en la arquitectura en la fase de elaboración.

• Estabilizamos la arquitectura hasta un nivel de línea base al principio del ciclo de vida, cuando los costes aún son bajos y el calendario todavía es generoso con nosotros.

Regresar

• Los usuarios pueden comprender más fácilmente un sistema en funcionamiento, aunque aún no funcione perfectamente, que un sistema que sólo existe en forma de cientos de páginas de documentos.

• Además, tienen dificultades en reconocer el avance del proyecto si todo lo que existe son documentos.

• Por tanto, desde la perspectiva de los usuarios y de otros interesados, es más productivo hacer evolucionar el producto a lo largo de una serie de versiones ejecutables, o “construcciones”, que presentar montañas de documentación difíciles de leer.

• Una construcción es una versión operativa de parte de un sistema que demuestra un subconjunto de posibilidades del sistema.

• Cada iteración debe progresar mediante una serie de construcciones hasta alcanzar el resultado esperado, es decir, el incremento.

• El tener un sistema con un funcionamiento parcial en una fase inicial permite que los usuarios y otros interesados hagan sugerencias sobre él o señalen requisitos que se nos pueden haber escapado.

• El plan —presupuesto y calendario— aún no es inamovible, de forma que los desarrolladores pueden incorporal” revisiones con más facilidad.

• En el modelo unidireccional en cascada, los usuarios no ven un sistema funcionando hasta la integración y la prueba.

• En ese momento, los cambios, incluso aquellos que son valiosos o parecen ser pequeños, introducen una desviación en el presupuesto o en el calendario de manera casi inevitable.

• Por tanto, el ciclo de vida iterativo hace más sencillo a los clientes el observar la necesidad de requisitos adicionales o modificados pronto dentro del ciclo de desarrollo, y hace más sencillo también a los desarrolladores el trabajar en ellos.

• No en vano, están construyendo el sistema mediante una serie de iteraciones, por lo que responder a una retroalimentación o incluir una revisión sólo significa un cambio incremental.

Regresar

• Con el método iterativo e incrementa!, los desarrolladores pueden resolver los problemas y los aspectos no cubiertos por las primeras construcciones e incluir cambios para corregirlos casi a la vez.

• Mediante esta técnica, los problemas se van descubriendo con un ritmo de goteo constante que los desarrolladores pueden tratar fácilmente.

• La tromba de informes de fallo que aparece en la inte gración en “big bang” del ciclo en cascada a menudo rompe la marcha del proyecto.

• Si la ruptura es grave, el proyecto puede llegar a pararse, con los desarrolladores aplastados por la presión, los jefes de proyecto dando vueltas en círculo, y con el pánico de otros directivos.

• En contraste, una serie de construcciones funcionales ofrece a todos la sensación de que las cosas van bien.

• Los ingenieros de prueba, los escritores de manuales, los encargados de las herramientas, el personal de gestión de configuración, y los encargados del aseguramiento de la calidad pueden adaptar sus propios planes al calendario en evolución del proyecto.

• Tienen conocimiento de la existencia de retrasos serios en las primeras fases del proyecto, cuando los desarrolladores encuentran por primera vez los problemas que los originan.

• Tienen tiempo de adaptar sus propios calendarios. • Cuando los problemas descansan ocultos hasta la

prueba, es demasiado tarde para que aquéllos puedan rehacer sus calendarios de forma eficaz.

• Cuando la iteración ha sido validada por el aseguramiento de la calidad, los jefes de proyecto, los arquitectos, y otros interesados pueden evaluarla según los criterios preestablecidos.

• Pueden decidir si la iteración ha obtenido el incremento correcto y si los riesgos se han tratado adecuadamente.

• Esta evaluación permite a los directores determinar si la iteración tuvo éxito.

• Si fue así, pueden autorizar la siguiente. • Si la iteración sólo tuvo un éxito parcial, pueden

ampliarla para cubrir aspectos no resueltos o para realizar las correcciones necesarias para la siguiente iteración.

• En un caso extremo, cuando la evaluación sea totalmente negativa, pueden cancelar el proyecto entero.

Regresar

• Al final de cada iteración, el equipo del proyecto demuestra que ha reducido algunos riesgos.

• El equipo entrega nuevas funcionalidades en cada iteración, que se hacen evidentes para los usuarios, los cuales pueden observar el progreso del proyecto.

• Las construcciones frecuentes fuerzan a los desarrolladores a concretar a intervalos regulares —concreción en forma de un fragmento de código ejecutable—.

• La experiencia de las cons trucciones les hace difícil a ellos o a cualquiera sostener la actitud del “90 por ciento completo”.

• Esta actitud aparece cuando un número de fragmentos de código o de otros artefactos hace parecer que el producto está casi terminado.

• Sin embargo, en ausencia de construcciones funcionales, es posible que la parte más difícil aún esté por venir.

• Puede que aún no se hayan descubierto los problemas mediante intentos de integrar y probar el sistema.

• En contraste, las sucesivas iteraciones, debido a que funcionan, producen una serie de resultados que nos indican exactamente el estado del proyecto.

• Incluso sí los desabolladores no consiguen obtener los resultados previstos en una de las primeras iteraciones, todavía tienen tiempo de intentarlo de nuevo y mejorar los modelos en las subsiguientes versiones internas.

• Ya que primero trabajan sobre los aspectos más críticos, cuentan con varias oportunidades para mejorar sus resultados.

• La línea gruesa de la Figura 5.2 muestra cómo funciona el desarrollo iterativo.

• En puntos al comienzo del calendario, en este caso con sólo del 2 al 4 por ciento del proyecto codificado, se consigue un incremento (o construcción).

• Este intento muestra algunos problemas, que se denotan en la figura por los pequeños descensos en la línea del avance, pero se resuelven rápidamente y el avance continúa.

Después de ello, el proyecto realiza construcciones frecuentes.

Cada una de ellas puede llevar a una parada temporal del avance.

Debido a que los incrementos son relativamente pequeños, comparados con la integración final del producto entero (en la línea inferior), la recuperación se lleva a cabo rápidamente.

• Como sugiere el diagrama, en el método en cascada, una sola integración cercana a la fecha de entrega descubre una legión de problemas.

• El gran volumen de problemas y la precipitación inevitable del momento tiene como resultado el que muchas de las correcciones no estén bien pensadas.

• Apresurarse a corregir los problemas suele retrasar la entrega más allá de la fecha planificada.

• En consecuencia, el desarrollo iterativo termina en mucho menos tiempo que el desarrollo en cascada.

• Es más, el producto de un “proyecto en cascada” puede ser frágil, es decir, difícil de mantener.

• Después de un par de iteraciones, todas las personas del equipo tienen una buena comprensión de lo que significan los diferentes flujos de trabajo.

• Saben lo que viene después de los requisitos y lo que viene después del análisis.

• Se reduce en gran medida el riesgo de “parálisis del análisis” (demasiado tiempo gastado en el análisis).

• Además, es fácil formar a gente nueva debido a que pueden formarse con el propio trabajo.

• El proyecto no está forzado a diseñar proyectos piloto especiales sólo para que la gente entienda qué es el proceso.

• Pueden comenzar directamente con el trabajo real.

• Dado que han recibido la formación adecuada y que trabajan con alguien que ya lo ha hecho antes, rápidamente se ajustan a la velocidad adecuada.

• Si alguien nuevo no consigue entender algo o comete un error, su fallo no es crítico para el progreso a largo plazo del proyecto, debido a que se revela en el siguiente intento de hacer una construcción.

• El método iterativo también ayuda al proyecto a tratar los riesgos de naturaleza no técnica, como los riesgos de la organización. Por ejemplo, puede que los desarrolladores no aprendan suficientemente rápido:

• A construir aplicaciones utilizando un object request broker.• A utilizar las herramientas de prueba de gestión de la

configuración (Apéndice C).• A trabajar de acuerdo al proceso de desarrollo de software.

• A medida que itera un proyecto, un grupo pequeño se pone al día con esas tecnologías, herramientas y procesos nuevos.

• En las siguientes iteraciones, a medida que el grupo las utiliza más, adquiere más habilidad.

• El equipo va creciendo gradualmente a medida que el proyecto pasa por las iteraciones, quizá empezando con unas 5 a 10 personas, pasando a 25, y finalmente a unas 100 personas.

• A medida que el grupo va creciendo paso a paso, el equipo inicial está dis ponible para tutelar a los nuevos miembros que suben a bordo.

• El método iterativo permite al equipo inicial ajustar el proceso y las herramientas antes de que la mayoría de los desarrolladores se unan al equipo.

• Mediante el trabajo dividido en fases e iteraciones, los desarrolladores son más capaces de cumplir con las necesidades reales de los clientes y de reducir los riesgos.

• Mediante la construcción por incrementos, todos los implicados pueden observar su nivel de progreso.

• Mediante la reducción de los problemas de última hora, aceleran el tiempo de salida al mercado.

• Es más, este método iterativo es beneficioso, no sólo para los desarrolladores, y fundamentalmente para los clientes, sino también para los directores.

• Los directores pueden notar el verdadero avance fijándose en las iteraciones terminadas.

Regresar