ANÁLISIS Y GESTIÓN DEL RIESGO
Enviado por gaborockerote • 15 de Julio de 2015 • Síntesis • 7.192 Palabras (29 Páginas) • 407 Visitas
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
...