La aproximación iterativa está dirigida por los riesgos 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 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.

2. 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.

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 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