Transcript Iterativo e Incremental-2

•
•
•
•
•
•
•
¿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 integració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 construcciones 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á disponible 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