ANÁLISIS Y GESTIÓN DEL RIESGO

CAPÍTULO

ANÁLISIS Y GESTIÓN DEL RIESGO

N su libro sobre análisis y gestión del riesgo, Robert Charette [CHA89] presenta la E siguiente definición de riesgo:

En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más

allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente

con nuestras acciones del pasado. La pregunta es, podemos, por tanto, cambiando nuestras

acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para

nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede

venir dado por cambios de opinión, de acciones, de lugares ... [En tercer lugar,] el riesgo

implica elección, y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muerte

y los impuestos, es una de las pocas cosas inevitables en la vida.

Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares

conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa

-¿qué riesgos podrían hacer que nuestro proyecto fracasara?-. El cambio es nuestra preocupación

¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desarrollo,

en las computadoras a las que va dirigido el proyecto y a todas las entidades relacionadas

con él, al cumplimiento de la planificación temporal y al éxito en general?. Para terminar, debemos

enfrentarnos a decisiones -¿qué métodos y herramientas deberíamos emplear, cuánta gente

debería estar implicada, cuánta importancia hay que darle a la calidad?-.

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

¿Quien 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 gestionarl-

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 bcurre. 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 revisado 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.

Peter Drucker [DRU75] dijo una vez: «Mientras que es inútil intentar eliminar el riesgo y

cuestionable el poder minimizarlo, es esencial que los riesgos que se tomen sean los riesgos

adecuados». Antes de poder identificar los «riesgos adecuados» a tener en cuenta en un proyecto

de software, es importante poder identificar todos los riesgos que sean obvios a jefes de

proyecto y profesionales del software.

97

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

Las estrategias se han denominado humorísticamente

«Escuela de gestión del riesgo de Indiana Jones»

[TH092]. En las películas, Indiana Jones, cuando se

enfrentaba a una dificultad insuperable, siempre decía,

«¡No te preocupes, pensaré en algo!». Nunca se preocupaba

de los problemas hasta que ocurrían, entonces

Indy reaccionaba de alguna manera heroica.

Desgraciadamente, el jefe del proyecto de software

normalmente no es Indiana Jones y los miembros de su

equipo no son sus fiables colaboradores. Sin embargo,

la mayoría de los equipos de software confían solamente

en las estrategias de riesgo reactivas. 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.

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.

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

[HIG95]:

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.

Cuando se analizan los riesgos es importante cuantificar

el nivel de incertidumbre y el grado de pérdidas

asociado con cada riesgo. Para hacerlo, se consideran

diferentes categorías de riesgos.

¿Qué tipo de riesgos es problable

que nos encontremos en el

software que se construye?

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

I Un riesgo del 100 por 100 es una limitación del proyecto de software.

98

CAPfTULO

...