Análisis y Gestión de Riesgo

¿Qué es?

El análisis y la gestión del riesgo son una serie de pasos que ayudan al equipo del software a comprender y a gestionar la incertidumbre.

Un proyecto de software puede estar lleno de problemas. Un riesgo es un problema potencial –puede ocurrir o no-. Pero sin tener en cuenta el resultado, realmente es una buena idea identificarlo, evaluar su probabilidad de aparición, estimar su impacto, y establecer un plan de contingencia por si ocurre el problema.

¿Quién lo hace?

Todos los que estén involucrados en el proceso del software

-gestores, ingenieros de software y clientes- participan en el análisis y la gestión del riesgo.

¿Por qué es importante?

Pensemos en el lema de los boys scout: «estar preparados». El software es una empresa difícil.

Muchas cosas pueden ir mal, y francamente, a menudo van mal. Esta es la razón para estar preparados –comprendiendo los riesgos y tomando las medidas proactivas para evitarlo o gestionarlo- es un elemento clave de una buena gestión de proyectos de software.

¿Cuáles son los pasos?

El reconocimiento de que algo puede ir mal es el primer puso, llamado identificación del riesgo. A continuación, cada riesgo es analizado para determinar la probabilidad de que pueda ocurrir y el daño que puede causar si ocurre. Una vez establecida esta información, se priorizan los riesgos, en función de la probabilidad y del impacto. Por último, se desarrolla un plan para gestionar aquellos riesgos con gran probabilidad e impacto.

¿Cuál es el producto obtenido?

Se realiza un Plan de Reducción, Supervisión y Gestión del Riesgo (RSGR) o un informe de riesgos.

¿Cómo puedo estar seguro de que lo he hecho correctamente?

Los riesgos analizados y gestionados deberían derivarse del estudio del personal, del producto, del proceso y del proyecto.

El RSGR debe ser revisa do mientras el proyecto se realiza para asegurar que los riesgos están siendo controlados hasta la fecha. Los planes de contingencia para la gestión del riesgo deben ser realistas.

Estrategias:

Reactivo

En el mejor de los casos, la estrategia reactiva supervisa el proyecto en previsión de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. Pero lo más frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Después el equipo vuela para corregir el problema rápidamente. Este es el método denominado a menudo «de bomberos». Cuando falla, «la gestión de crisis» [CHA92] entra en acción y el proyecto se encuentra en peligro real.

Proactiva

Una estrategia considerablemente más inteligente para el control del riesgo es ser proactivo. La estrategia proactiva empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece una prioridad según su importancia. Después, el equipo de Software establece un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden evitar todos los riesgos, el equipo trabaja para desarrollar un plan de contingencia que le permita responder de una manera eficaz y controlada. A lo largo de lo que queda de este capítulo, estudiamos la estrategia proactiva para el control de riesgos.

Características

Aunque ha habido amplios debates sobre la definición adecuada para riesgo de software, hay acuerdo común en que el riesgo siempre implica dos características

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de probabilidad'.

Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Tipos de riesgos

Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costes aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos, cliente y requisitos y su impacto en un proyecto de software. En el Capítulo 5, la complejidad del proyecto, tamaño y el grado de incertidumbre estructural fueron también definidos como factores (y estimados) de riesgo del proyecto.

Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz, verificación y de mantenimiento. Además, las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las «tecnologías punta» son también factores de riesgo.

Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos.

Los riesgos del negocio amenazan la viabilidad del software a construir. Los riesgos del negocio a menudo ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:

1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado).

2. Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico).

3. Construir un producto que el departamento de ventas no sabe cómo vender.

4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección).

5. Perder presupuesto o personal asignado (riesgos de presupuesto).

Es extremadamente importante recalcar que no siempre funciona una categorización tan sencilla. Algunos riesgos son simplemente imposibles de predecir.

Otra categorización general de los riesgos ha sido pre puesta por Charette. Los riesgos conocidos son todos aquellos que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial en el que se desarrolla el proyecto y otras fuentes de información fiables (por ejemplo: fechas de entrega poco realistas, falta de especificación de requisitos o de ámbito del software, o un entorno pobre de desarrollo).

Los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (por ejemplo: cambio de personal, mala comunicación con el cliente, disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento).

Los riesgos impredecibles son el comodín de la baraja. Pueden ocurrir, pero son extremadamente difíciles de identificar por adelantado.

¿Qué es la identificación de un riesgo y cuál es su clasificación?

La identificación del riesgo es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones, planificación temporal, carga de recursos,

etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario.

Existen dos tipos diferenciados de riesgos para cada categoría presentada:

Riesgos genéricos y riesgos específicos del producto.

Los riesgos genéricos son una amenaza potencial para todos los proyectos de software.

Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión. Para identificar los riesgos específicos del producto, se examinan el plan del proyecto y la declaración del ámbito del software y se desarrolla una respuesta a la siguiente pregunta:

«¿Qué características especiales de este producto pueden estar amenazadas por nuestro plan del proyecto?»

¿Cuál es la evaluación global del riesgo del proyecto, los componentes y controladores del riesgo?

Evaluación Global del Riesgo del Proyecto

Las siguientes preguntas provienen de los datos del riesgo obtenidos mediante las encuestas realizadas a gestores de proyectos de software expertos de diferentes partes del mundo [KEI98]. Las preguntas están ordenadas por su importancia relativa para el éxito de un proyecto.

¿Corre un riesgo grave el proyecto de software en el que estamos trabajando?

1. ¿Se han entregado los gestores del software y clientes formalmente para dar soporte al proyecto?

2. ¿Están completamente entusiasmados los usuarios finales con el proyecto y con el sistema/producto a construir?

3. ¿Han comprendido el equipo de ingenieros de software y los clientes todos los requisitos?

4. ¿Han estado los clientes involucrados por completo en la definición de los requisitos?

5. ¿Tienen los usuarios finales expectativas realistas?

6. ¿Es estable el ámbito del proyecto?

7. ¿Tiene el ingeniero de software el conjunto adecuado de habilidades?

8. ¿Son estables los requisitos del proyecto?

9. ¿Tiene experiencia el equipo del proyecto con la tecnología a implementar?

10. ¿Es adecuado el número de personas del equipo del proyecto para realizar el trabajo?

11. ¿Están de acuerdo todos los clientes/usuarios en la importancia del proyecto y en los requisitos del sistema/ producto a construir?

Componentes y controladores del riesgo

Se requiere que el gestor del proyecto identifique los controladores del riesgo que afectan a los componentes de riesgo del software, rendimiento, coste, soporte y planificación temporal-.

En el contexto de este estudio, los componentes de riesgo se definen de la siguiente manera:

Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido;

Riesgo de coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto;

Riesgo de soporte: el grado de incertidumbre de la facilidad del software para corregirse, adaptarse y ser mejorado;

Riesgo de la planificación temporal: el grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo.

El impacto de cada controlador del riesgo en el componente de riesgo se divide en cuatro categorías de impacto

¿Cómo se realiza la estimación del riesgo?

La proyección del riesgo, también denominada estimación del riesgo, intenta medir cada riesgo de dos maneras

-la probabilidad de que el riesgo sea real

-las consecuencias de los problemas asociados con el riesgo, si ocurriera-.

El jefe del proyecto, junto con otros gestores y personal técnico, realiza cuatro actividades de proyección del riesgo:

-establecer una escala que refleje la probabilidad percibida del riesgo;

-definir las consecuencias del riesgo;

-estimar el impacto del riesgo en el proyecto y en el producto

-apuntar la exactitud general de la proyección del riesgo de manera que no haya confusiones.

¿Cuáles son los beneficios de realizar una estimación de proyectos?

El tiempo invertido identificando, analizando y gestionando el riesgo merece la pena por muchas razones:

-menos trastornos durante el proyecto

-una mayor habilidad de seguir y controlar el proyecto

-la confianza que da planificar los problemas antes de que ocurran.

El análisis de riesgos puede absorber una cantidad significativa del esfuerzo de planificación del proyecto.