Iterativo e Incremental-3.ppt

•
•
•
•
•
•
La aproximación iterativa está dirigida por
los riesgos
Las iteraciones alivian los riesgos técnicos
La dirección es responsable de los riesgos
no técnicos
Tratamiento de los riesgos
La iteración genérica
Lo que es una iteración
•
•
•
•
•
•
Un riesgo es una variable del proyecto que pone en peligro o
impide el éxito del proyecto.
Es la “probabilidad de que un proyecto experimente sucesos
no deseables, como retrasos en las fechas, excesos de coste, o
la cancelación directa”.
Identificamos, priorizamos, y llevamos a cabo las iteraciones
sobre la base de los riesgos y su orden de importancia.
Esto se hace así cuando evaluamos tecnologías nuevas, y
cuando trabajamos para cumplir con las necesidades de los
usuarios —los requisitos—, sean éstos funcionales o no
funcionales.
También es así cuando, en las primeras fases, vamos
estableciendo una arquitectura que será robusta, es decir, que
podrá incorporar los cambios con un riesgo bajo de tener que
rediseñar algo.
Sí, organizamos las iteraciones para conseguir una reducción
del riesgo.
•
•
•
•
Otros riesgos importantes son temas de
rendimiento (velocidad, capacidad, precisión),
Habilidad, disponibilidad, integridad de las
interfaces
de
usuario,
adaptabilidad,
y
portabilidad.
Muchos de estos riesgos no son visibles hasta
que se implementa y prueba el software que
implementa las funciones subyacentes.
Éste es el motivo por el cual se deben llevar a
cabo iteraciones que examinen los riesgos,
incluso en las fases de inicio y elaboración, y
hasta la codificación y la prueba.
El objetivo es acabar con los riesgos en una
iteración temprana.
•
•
•
Una observación interesante sobre esto es que, en
principio, todos los riesgos técnicos pueden hacerse
corresponder con un caso de uso o un escenario de
un caso de uso. Aquí, correspondencia quiere
decir que el riesgo se atenúa si se desarrolla el
caso de uso con sus requisitos funcionales y no
funcionales.
Esto es cierto no sólo para los riesgos relativos a
los requisitos y a la arquitectura, sino también para
la verificación del hardware y del software
subyacentes.
Mediante una cuidadosa selección de los casos de
uso, podemos probar todas las funciones de la
arquitectura subyacente.
•
•
•
•
La reducción del riesgo es un eje central de las
iteraciones que hacemos en las fases de inicio y
de elaboración.
Más adelante, en la fase de construcción, la
mayoría de los riesgos se han reducido hasta
un nivel de rutina, queriendo decir con esto que
se someten a prácticas de desarrollo ordinarias.
Intentamos ordenar las iteraciones de manera
que cada una de ellas se construya sobre la
anterior.
Intentamos reducir así el riesgo concreto de
que si no ordenamos bien las iteraciones,
podríamos tener que rehacer varias iteraciones
previas.
Regresar
•
•
•
•
Los riesgos han sido clasificados en muchas
categorías.
Sin embargo, es suficiente para nuestros propósitos
el dar sugerencias, sin ser exhaustivos. Hemos
identificado cuatro categorías amplias:
1.
Riesgos relacionados con nuevas
tecnologías:
Puede que haya que distribuir los procesos en
muchos nodos, lo cual posiblemente origine
problemas de sincronización.
Algunos casos de uso pueden depender de técnicas
informáticas que aún no están bien conseguidas,
como el reconocimiento del lenguaje natural o el
uso de la tecnología Web.
Riesgos relativos a la arquitectura.
Estos riesgos son tan importantes que hemos diseñado el
Proceso Unificado para que los trate de manera estándar; es
decir, la fase de elaboración y las iteraciones para la
arquitectura dentro de ella proporcionan un lugar explícito en
el proceso para tratarlos.
Mediante el establecimiento temprano de una arquitectura
que acomode los riesgos, eliminamos el riesgo de no ser
capaces de incorporar fácilmente los cambios.
Eliminamos el riesgo de tener que rehacer después una
buena parte del trabajo.
Esta arquitectura resistente a los riesgos es robusta.
La adaptación elegante al cambio es característica de la
robustez
(Apéndice
C)
de
la
arquitectura.
2.
•
•
•
•
•
•
•
•
•
•
•
Otra ventaja de obtener pronto una arquitectura robusta incluye el
mostrar dónde encajan los componentes reutilizables, lo que nos permite
pensar en comprar en lugar de desarrollar al principio del proyecto.
También reduce el riesgo de descubrir demasiado tarde que el sistema es
demasiado caro de construir. Por ejemplo,
Los casos de uso que seleccionamos inicialmente no sirven para
ayudarnos a obtener la estructura de subsistemas que necesitamos para
hacer evolucionar el sistema con los casos de uso que irán llegando.
En las primeras iteraciones, digamos durante la fase de elaboración,
puede que no nos demos cuenta de que varios actores utilizan el mismo
caso de uso a través de diferentes interfaces.
Un ejemplo de esta situación es la de tener varios interfaces para sacar
dinero: uno emplea un interfaz gráfico de usuario y un computador
personal; y otro utiliza un protocolo de comunicaciones sobre una red.
Si nuestro diseño trata de cumplir sólo uno de estos casos de uso,
podemos acabar con una arquitectura que no tenga un interfaz interno
que nos permita añadir nuevos tipos de interacción.
El riesgo reside en que será difícil hacer que un sistema de ese tipo
evolucione.
•
•
•
•
Ciertos marcos de trabajo planificados para su
reutilización, puede que en realidad no se hayan
usado fuera del proyecto original para el cual se
construyeron.
El riesgo reside en que un marco de trabajo como
ese no funcionará bien con otros marcos de
trabajo, o en que no será fácil de reutilizar.
La nueva versión del sistema operativo que
pretendemos utilizar puede no haber alcanzado el
nivel de calidad necesario para que confiemos en
él.
El riesgo reside en que podemos vernos obligados a
retrasar la entrega de nuestro propio software
mientras esperamos que el fabricante actualice el
sistema operativo.
3. Riesgos relativos a construir el sistema adecuado,
es decir, que cumpla con su misión y sus usuarios.
• Este riesgo subraya la importancia de identificar los
requisitos funcionales y no funcionales, lo cual significa
esencialmente identificar los casos de uso correctos con
las interfaces de usuario correctas.
• Es importante encontrar las funciones más importantes
al principio para estar seguros de que se implementan al
principio.
• Para ello, disponemos los casos de uso por orden de
importancia relativa al cumplimiento de las necesidades
de los clientes y de los requisitos de rendimiento.
• Consideramos
tanto el comportamiento como las
capacidades,
tales
como
el
rendimiento.
•
•
•
•
•
Cuando seleccionamos casos de uso, basamos el orden en que
los tratamos en su riesgo potencial, como la posibilidad de
encontrar problemas con el rendimiento del caso de uso.
Especialmente en las fases de inicio y de elaboración, existe
una
estrecha
relación
entre ciertos requisitos (y los casos de uso que los expresan) y
los riesgos que descansan en su interior.
Los casos de uso que el equipo seleccione tendrán su impacto
en la arquitectura que están desarrollando. Por ejemplo:
El caso de uso Sígueme permite a un abonado a una línea
redirigir sus llamadas a otro número.
¿Debería aplicarse esta redirección a todas las llamadas? ¿Qué
se debe hacer con las llamadas del despertador?
El abonado estará en esos casos probablemente en su número
básico, y no querrá que se redireccione la llamada.
4. Algunos riesgos son relativos al rendimiento.
Por ejemplo,
• El tiempo de respuesta de un caso de uso debe ser menor de
1 segundo.
• El número de instancias concurrentes de un caso de uso
sobrepasa las 100.000 en una hora.
• La identificación de áreas problemáticas como éstas depende
en gran medida de personas con una dilatada experiencia.
• Debido a que es probable que ninguna persona tenga la
experiencia necesaria, tendrán que estudiar el sistema varias
personas, hacer listas de posibles problemas, y reunirse en
sesiones de identificación de riesgos.
• No se pretende que estas aes resuelvan los problemas,
simplemente que los identifiquen y priorizen el orden en que
se van a estudiar más en profundidad en iteraciones dentro de
las fases de inicio y elaboración.
Regresar
•
•
•
•
•
•
•
Riesgos no técnicos son aquellos que una dirección atenta
puede detectar y desviar.
Los siguientes son ejemplos de esta categoría:
La organización a fecha de hoy no cuenta con gente con
experiencia en ciertos aspectos poco usuales del proyecto
propuesto.
La organización pretende implementar partes del sistema
propuesto en un lenguaje que le es nuevo.
El calendario propuesto por el cliente parece ser demasiado
corto, a menos que cada paso encaje en su lugar sin
problemas.
La organización sólo puede cumplir sus plazos si terceras
empresas subcontratadas, con las que no se ha trabajado
antes, pueden entregar a tiempo ciertos subsistemas.
Puede que el cliente no sea capaz de devolver ciertas
aprobaciones dentro de los límites de tiempo necesarios para
llegar a la fecha de entrega.
•
•
Los riesgos de este tipo caen fuera del
propósito de este trabajo.
Baste decir que la organización de
desarrollo debería identificarlos, poner los
medios administrativos necesarios para
seguir los desarrollos en cada una de las
áreas de riesgo, y garantizar que los
directivos
responsables
emprendan
acciones cuando uno de estos riesgos
aparece.
Regresar
•
•
•
•
•
•
Una vez que se han identificado y priorizado los riesgos, a
continuación el equipo decide cómo tratar cada uno de ellos.
Cuentan fundamentalmente con cuatro elecciones: evitarlo,
limitarlo, atenuarlo, o controlarlo.
Algunos riesgos pueden y deberían evitarse, quizá mediante
una replanificación del proyecto o un cambio en los requisitos.
Otros riesgos deberían limitarse, es decir, restringirse de modo
que sólo afecten a una pequeña parte del proyecto.
Algunos riesgos pueden atenuarse ejercitándolos y observando
si aparecen o no.
Si aparece, el aspecto positivo es que el equipo ha aprendido
más sobre él. Puede que el equipo esté en disposición de
encontrar una forma de evitarlo, limitarlo o controlarlo.
•
•
•
•
•
•
Sin embargo, hay riesgos que no pueden atenuarse. Lo
único que puede hacer el equipo es controlarlos y
observar si aparecen.
Si esto ocurre, el equipo debe seguir sus planes de
contingencia.
Si aparece un riesgo “asesino de proyectos”, debemos
respirar hondo y analizar la situación.
¿Queremos continuar, o deberíamos parar el proyecto
Hasta el momento sólo hemos gastado un tiempo y
dinero limitados.
Sabíamos que podía suceder uno de estos riesgos —éste
es el motivo por el cual estamos haciendo las primeras
iteraciones—.
Por tanto, hicimos un buen trabajo encontrando un
riesgo de esta magnitud antes de poner a trabajar a
todos los desarrolladores en el proyecto.
•
•
•
•
•
•
•
El tratamiento de un riesgo lleva su tiempo. Evitarlo o limitarlo
conlleva hacer una recreación, o rehacer algún trabajo.
La atenuación de un riesgo podría requerir que el equipo
construyese algo que lo haga evidente.
El controlar un riesgo implica la selección de un mecanismo de
control, su puesta en marcha, y su ejecución.
A su vez, la atenuación o control de los riesgos lleva un
esfuerzo de desarrollo importante, es decir, tiempo.
Debido a que el tratamiento de los riesgos consume tiempo,
una organización raramente puede tratarlos todos a la vez.
Este es el motivo por el cual es necesaria la priorización de las
iteraciones.
Esto es lo que queremos expresar con desarrollo iterativo
dirigido por los riesgos. Y es una gestión de riesgos sólida.
Regresar


Como hemos visto, las iteraciones difieren marcadamente
en las diferentes fases del ciclo de desarrollo, como
consecuencia de que los desafíos que afrontan los
desarrolladores son diferentes en cada fase.
Nuestra intención en esta sección es presentar el concepto
de iteración a un nivel genérico: qué es, cómo planificarla,
cómo organizarla, y cuál es su resultado.
Regresar





Una iteración es un miniproyecto —un recorrido más o
menos completo a lo largo de todo los flujos de trabajo
fundamentales— que obtiene como resultado una versión
interna.
Ésta es una explicación intuitiva de lo que es una iteración.
Sin embargo, hemos ampliado esta definición para ser
capaces de describir el trabajo que tiene lugar en una
iteración por debajo de su superficie.
Podemos imaginar una iteración como un flujo de trabajo,
lo cual significa que es una elaboración entre trabajadores
que utilizan y producen artefactos.
En el Proceso Unificado distinguimos entre flujos de
trabajo fundamentales y flujos de trabajo de
iteración.




Por ahora, nos son familiares los cinco flujos de trabajo
fundamentales: requisitos, análisis, diseño, implementación
y prueba.
Estos flujos de trabajo fundamentales sólo sirven para
ayudarnos a describir los flujos de trabajo de iteración, por
razones pedagógicas.
Por tanto, no hay nada mágico en lo que constituye un flujo
de trabajo fundamental; fácilmente podríamos haber
utilizado otro conjunto de flujos de trabajo fundamentales,
como por ejemplo, uno que integrase el análisis y el diseño.
Se utilizan para simplificar la descripción de flujos de
trabajo más concretos, de igual forma que una clase
abstracta nos ayuda a describir clases concretas.






Estos flujos de trabajo más concretos son los flujos de
trabajo de iteración. Los flujos de trabajo fundamentales se
describen en detalle en los Capítulos 6 al 11, y los flujos de
trabajo de iteración en los Capítulos 12 al 16, partiendo de
los fundamentales.
En la Figura 5.3, se describen los elementos genéricos del
flujo de trabajo de cada iteración.
Todas pasan por los cinco flujos de trabajo fundamentales.
Todos comienzan con una actividad de planificación y
terminan con un análisis.
En la Parte III, describiremos cuatro iteraciones
arquetípicas, una por cada fase del Proceso Unificado.
Cada una de ellas reutiliza las descripciones de los flujos de
trabajo fundamentales, pero de forma diferente.
Regresar