GESTIN DEL RIESGO

En primer lugar, el riesgo se relaciona con los conocimientos futuros. El hoy y el ayer estn ms all de esta relacin, pues ya se ha
cosechado lo que previamente se sembr con nuestras acciones pasadas. La pregunta es: podemos, por tanto, al cambiar nuestras
acciones presentes, crear en lo futuro una oportunidad para una situacin diferente, y esperanzadoramente mejor, para nosotros
mismos? Esto significa, en segundo lugar, que riesgo implica el cambio, como cambios de mentalidad, opinin, acciones o lugares[en
tercer lugar] el riesgo implica eleccin y la incertidumbre que esta conlleva. Por ende, paradjicamente, el riesgo, al igual que la muerte
y los impuestos, es una de las pocas certezas en la vida.
Cuando el riesgo se considera en el contexto de la ingeniera de software, las tres bases conceptuales de Charette siempre se
evidencian. El futuro es una preocupacin de primer orden: qu riesgos causaran que el proyecto de software salga mal? El cambio es
una preocupacin central: cmo afectaran la actualidad y el xito global los cambios en los requisitos del cliente, las tecnologas de
desarrollo los entornos que se tienen como objetivo y todas las otras entidades vinculadas con el proyecto? Por ltimo, es necesario
enfrentar las opciones: qu mtodos y herramientas se deben usar, cuntas personas deben estar involucradas, cunto nfasis sobre
la calidad es suficiente?
Peter Druker dijo una vez: Aunque es en vano intentar eliminar el riesgo, y cuestionable intentar minimizarlo, es esencial que los
riesgos tomados sean riesgos correctos. Antes de identificar los riesgos correctos que se tomarn durante un proyecto de software, es
importante identificar los riesgos que son obvios para los gestores y profesionales.
Un vistazo rpido
Qu es? El anlisis y la gestin del riesgo son una serie de pasos que ayudan a un equipo de software a comprender y manejar la
incertidumbre. Muchos problemas pueden desbordar un proyecto de software. Un riesgo es un problema potencial: puede ocurrir o no.
Pero, sin importar el resultado, en realidad es una buena idea identificarlo, evaluar la probabilidad de que ocurra, estimar su impacto y
establecer un plan de contingencia en caso de que el problema se presente.
Quin lo hace? Todos los involucrados en el proceso de software (gestores, ingenieros y participantes) intervienen en el anlisis y la
gestin del riesgo.
Por qu es importante? Piense en el lema de los boy scout: estar preparado. El software es una empresa difcil. Muchas cosas
pueden salir mal y, francamente lo hacen. Por esta razn estar preparados (al comprender los riesgos y tomar medidas proactivas para
evitarlos o gestionarlos) es un elemento clave de una buena gestin de proyecto de software.
Cules son los pasos? Reconocer que puede salir mal es el primer paso, llamado Identificacin del riesgo. A continuacin se analiza
cada riesgo para determinar la probabilidad de que ocurrir y el dao que causar si en efecto ocurre. Una vez establecida esta
informacin, los riesgos se clasifican segn su probabilidad e impacto. Finalmente, se desarrolla un plan para gestionar aquellos riesgos
con gran probabilidad y alto impacto.
Cul es el producto obtenido? Se produce un plan de reduccin, supervisin y gestin del riesgo (RSGR)o un conjunto de hojas
informativas del riesgo.
Cmo estar seguro de que lo he hecho correctamente? Los riesgos que se analizan y gestionan deben proceder de un estudio amplio
del personal, el producto, el proceso y el proyecto. El plan RSGR debe revisarse conforme el proyecto avanza para asegurarse de que los
riesgos estn actualizados. Los planes de contingencia para la gestin del riesgo deben ser realistas.
ESTRATEGIAS DE RIESGO REACTIVAS Y PROACTIVAS
Las estrategias de riesgo reactivas han sido jocosamente denominadas la escuela Indiana Jones de gestin del riesgo. En las pelculas
de la dcada de 1980 que llevaban su nombre, Indiana Jones, cuando enfrentaba alguna dificultad abrumadora, invariablemente deca:
No te preocupes, pensar en algo!. Al no preocuparse nunca por los problemas, sino hasta que ocurran, reaccionaba en alguna
forma heroica.
Si usted no ataca activamente los riesgos, ellos lo atacarn activamente. (Tom Gilb)
La mayora de los equipos de software se apoya exclusivamente en las estrategias de riesgo reactivas. Los riesgos se apartan para
tratarlos, lo que puede convertirlos en problemas reales. Ms usualmente, el equipo de software no hace nada acerca de los riesgos
hasta que algo sale mal. Entonces el equipo se precipita en la accin con la finalidad de corregir el problema rpidamente. Con
frecuencia a esto se le llama modo bombero. Cuando esto falla, la gestin de crisis asume el control y el proyecto est en un
verdadero peligro.
Una estrategia considerablemente ms inteligente para la gestin del riesgo es ser proactivo. Una estrategia comienza mucho antes de
que se inicie el trabajo tcnico. Se identifican los riesgos potenciales, se valoran su probabilidad e impacto, y se les clasifica segn su
importancia. Luego, el equipo de software establece un plan para gestionar el riesgo. El objetivo principal es evitar el riesgo, pero
debido a que no todos lo riesgos pueden evitarse, el equipo trabaja para desarrollar un plan de contingencia
Riesgos del software
Aunque hay un considerable debate en torno a la definicin propia para el resto de software, existe un acuerdo general en que el riesgo
siempre involucra de caractersticas[]:
Incertidumbre: El riesgo puede o no ocurrir, esto es, no existen riesgos 100% probables.+
Perdida: Si el riesgo se convierten realidad, ocurrirn consecuencias o prdidas indeseables.
Cuando se analizan los riesgos es importante cuantificar el grado de incertidumbre y el grado de perdida asociado cada riesgo. Esto se
logra considerando diferentes categoras de riesgos.
Los riesgos del proyecto amenazan el plan del proyecto. Es decir, si los riesgos del proyecto se vuelven reales es probable que la
calendarizacin del proyecto se altere y que los costos aumenten. Los riesgos del proyecto identifican potenciales problemas en
presupuesto, calendarizacin, personal (plantillas y organizacin), recursos, participantes y requisitos, y su impacto sobre un proyecto
de software. En el captulo 23 la complejidad, tamao y grado de incertidumbre estructural del proyecto tambin se definieron como
factores de riesgos del proyecto (y de la estimacin.)
Los riegos tcnicos amenazan la calidad y actualidad del software que se producir. Si un riesgo tcnico se vuelve real, la
implementacin se torna difcil o imposible. Los riegos tcnicos identifican potenciales, problemas en diseo, implementacin, interfaz,
verificacin y mantenimiento. Adems, tambin son factores de riesgo la ambigedad de la especificacin, la incertidumbre tcnica, la
obsolescencia tcnica y la tecnologa de punta. Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que en
un principio se pens que sera.
Los riesgos de negocios amenazan la viabilidad del software que se construir. Estos riesgos con frecuencia ponen en peligro o el
producto. Los candidatos para los cinco mayores riesgos de negocios son
1) La construccin de un producto o sistema excelente que en realidad nadie quiere (riesgo de mercado).
2) La construccin de un producto que ya no encaja en la estrategia comercial global de la compaa (riesgo de estrategia)
3) La construccin de un producto que la fuerza de ventas no sabe cmo vender (riesgo de ventas).
4) La prdida del apoyo de los altos ejecutivos debido a un cambio en el enfoque o en el personal (riesgo administrativo).
5) La prdida presupuestaria o del personal asignado (riesgo presupuestal).
Es extremadamente importante destacar que la simple clasificacin de los riesgos no siempre funciona. Algunos riesgos simplemente
son impredecibles.
Charette ha propuesto otra categorizacin general de los riesgos. Los riesgos conocidos son aquellos susceptibles de descubrirse
despus de una evaluacin cuidadosa del plan del proyecto, del entorno de negocios y tcnico dentro de los cuales se desarrollara el
proyecto, y otras fuentes de informacin confiables (por ejemplo, fechas de entrega irreales, falta de requisitos documentados o de
mbito de software, pobre entorno de desarrollo). Los riesgos predecibles se extrapolan de la experiencia con proyectos previos (por
ejemplo, cambios en el personal, mala comunicacin con el cliente, disminucin del esfuerzo del personal conforme se atienden las
solicitudes de mantenimiento). Los riesgos impredecibles son el comodn de la baraja. Pueden y de hecho ocurren, pero son
extremadamente difciles de identificar con antelacin.
Siete principios de la gestin de riesgos
El Software Engineering Institute (SEI) identifica siete principios que ofrecen un marco de trabajo para lograr una gestin de riesgos
efectiva. Dichos principios son:
Mantenimiento de una perspectiva global: ver los riesgos de software dentro del contexto del sistema en el que est un componente y
el problema de negocios que se intenta resolver.
Tener una misin previsora: pensar en los riesgos que pudieran surgir en lo futuro (por ejemplo, debido a cambios en el software);
establecer planes de contingencia de modo que los eventos futuros sean manejables.
Alentar la comunicacin abierta: si alguien establece un riesgo potencia, no lo descarte. Si un riesgo se propone de una manera
informal, considrelo. Aliente a todos los participantes y usuarios a sugerir riesgos en cualquier momento.
Integracin: en el proceso del software debe estar integrada una consideracin de los riesgos.
Enfatizar un proceso continuo: el equipo debe estar atento a lo largo de todo proceso de software, modificar los riesgos identificados
conforme se tenga ms informacin y agregar unos nuevos a medida que se logre un mejor criterio.
Desarrollo de una visin conjunta del producto: si todos los participantes comparten la misma visin del software, es probable que
ocurra mejor identificacin y evaluacin de riesgos.
Alentar el trabajo en equipo: los talentos, habilidades y conocimiento de los participantes se deben mezclar cuando se lleven a cabo
actividades de gestin de riesgos.
Identificacin de riesgos
La identificacin de riesgos es un intento sistemtico encaminado a especificar las amenazas al plan de proyecto (estimaciones,
calendarizacin, carga de recursos, etc.). al identificar los riesgos conocidos y predecibles, el gestor de proyecto da un primer paso para
cuando sea posible y a controlarlos cundo es necesario.
Existen dos tipos distintos de riesgos : los riesgos genricos y los riesgos especficos del producto. Los riesgos genricos son una
amenaza potencial para todo el proyecto de software. Los riesgos especficos del producto los pueden identificar slo aquellos con Un
claro conocimiento de la tecnologa, el personal y el entorno especifico del software que se construir. Los riesgos especficos del
producto se identifican examinando el plan del proyecto y la declaracin del mbito del software, as como desarrollando una
respuesta para la siguiente pregunta: Qu caractersticas especiales de este producto podran amenazar el plan del proyecto?
Los proyectos sin riesgos reales son perdedores. Estos proyectos casi siempre estas desprovistos de beneficios; por ello no fueron
realizados aos atras. Tom DeMarco y Tim Lister
Un mtodo para identificar riesgos consiste en crear una lista de verificacin de riesgos. Con esta se pueden identificar riesgos y
enfocarse en algn subconjunto de riesgos conocidos y predecibles en las siguientes subcategorias genricas:
Tamao del producto: riesgos asociados con el tamao global del software que se construir o se modificara.
Impacto en el negocio: riesgos asociados con las restricciones que impone la gerencia o el mercado.
Caractersticas del cliente: riesgos asociados con la sofisticacin del cliente y la habilidad del desarrollador para comunicarse
con l en una forma oportuna.
Definicin del proceso: riesgos asociados con el grado en el que se ha definido el proceso de software y en que le da
seguimiento la organizacin que lo desarrolla.
Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se usarn en la construccin
del producto.
Tecnologa que construir: riesgos asociados con la complejidad del sistema que se contruira y la novedad de la tecnologa
que esta empaquetada en el sistema.
Tamao y experiencia de la plantilla del personal: riesgos asociados con la experiencia global tcnica y en el proyecto de los
ingenieros de software que harn el trabajo.
La lista de verificacin de riesgos se puede organizar en diferentes formas. Las preguntas relevantes respecto de cada uno de los
tpicos se pueden responder para cada proyecto de software. Las respuestas a estas preguntas permiten que el planificador estime el
impacto del riesgo. Un formato diferente de lista de verificacin de riesgos simplemente menciona las caractersticas relevantes para
cada subcategoria genrica. Finalmente se menciona un conjunto de componentes y controladores de riesgo junto con su probabilidad
de ocurrencia. Los controladores de desempeo, soporte, costo y calendarizacin se estudian como respuesta a las ultimas preguntas.
Evaluacin del riesgo global del proyecto
Las siguientes preguntas se basan en los datos de riesgo obtenidos al entrevistar, en diferentes partes del mundo, a gestores de
proyecto de software experimentados. Las preguntas estn ordenadas segn su importancia relativa en el xito de un proyecto.
1. los altos ejecutivos de software y del cliente se han comprometido formalmente para apoyar el proyecto?
2. Los usuarios finales estn comprometidos con el proyecto y el sistema/producto que se contruir?
3. Los requisitos los han comprendido completamente el equipo de ingeniera de software y sus clientes?
4. Los clientes estuvieron completamente involucrados en la definicin de los requisitos?
5. Los usuarios finales tienen expectativas realistas?
6. El mbito del proyecto es estable?
7. El equipo de ingeniera de software tiene la mezcla correcta de habilidades?
8. Los requisitos del proyecto son estables?
9. El equipo del proyecto tiene experiencia con la tecnologa que se implementara?
10. El nmero de personas en el equipo de proyecto es adecuado para realizar el trabajo?
11. Todos los votantes del cliente/usuario estn de acuerdo en la importancia del proyecto y en los requisitos para el
sistema/producto que se construir?
La gestin de riesgos es la gestin de proyectos para adultos Tim Lister
Si la respuesta a alguna de estas preguntas es negativa, se deben instituir sin demora los pasos de reduccin, supervisin y gestin. El
grado en el que el proyecto est en riesgo es directamente proporcional al nmero de respuestas negativas a estas preguntas.
Componente y controladores del riesgo.
La Fuerza Area de Estados Unidos escribi directrices para la identificacin y supresin del riesgo de software. Este enfoque requiere
que el gestor del proyecto identifique los controladores del riesgo que afectan los componentes de riesgo del software: desempeo,
costo, soporte y calendarizacin. En el contexto de este estudio los componentes de riesgo se definen en la forma siguiente:
Riesgo de desempeo: grado de incertidumbre de que el producto satisfaga los requisitos y se ajuste al uso que se pretende
darle.
Riesgo de costo: grado de incertidumbre de que se mantenga el presupuesto del proyecto.
Riesgo de soporte: grado de incertidumbre de que el software resultante ser fcil de corregir, adaptar y mejorar.
Riesgo de calendarizacin: grado de incertidumbre del que se mantenga la calendarizacin del proyecto y de que el producto
se entregue a tiempo.
El impacto de cada controlador de riesgo sobre el componente de riesgos se divide en cuatro categoras de impacto: despreciable,
marginal critico o catastrfico.
PROYECCIN DEL RIESGO
La proyeccin del riesgo tambin llamada estimacin del riego, intentas clasificar cada riesgo en dos formas:
1) La posibilidad o probabilidad de que el riesgo sea real.
2) Las consecuencias de los problemas asociados con el riesgo, en caso de que ocurra.
El planificador del proyecto, junto con otros gestores y personal tcnico, realizan cuatro pasos en la proyeccin del riesgo:
1. Establecimiento de una escala que refleje la posibilidad percibida de una riesgo.
2. Delineado de las consecuencias del riesgo.
3. Estimacin del impacto del riesgo en el proyecto y el producto.
4. Tomar nota de la precisin global de la proyeccin del riesgo de modo que no haya malas interpretaciones.
La finalidad de estos pasos es considerar los riesgos en tal forma que conduzcan al establecimiento de prioridades. Ningn equipo de
software tiene los recursos para enfrentar todos los riesgos potenciales con el mismo grado de rigor. Al priorizar los riesgos el quipo
puede asignar los recursos donde tenga el mayor impacto.
Desarrollo de una tabla en riesgos
Una tabla de riesgos ofrece al gestor de un proyecto una tcnica simple para la proyeccin de riesgos.
Un equipo de proyecto comienza una lista de todos los riesgos (sin importar cun remotos sean) en la primera columna de la tabla. Esto
se logra con la ayuda de la lista de verificacin de riesgos. A continuacin se evala el impacto de cada riesgo. Cada componente de
riesgo se evala, y se determina una categora de impacto. Las categoras para cada uno de los cuatro componentes de riesgo
(desempeo, soporte, costo y calendarizacin) se promedian para determinar un valor de impacto global.
El gestor del proyecto estudia la tabla ordenada resultante y define una lnea de corte. La lnea de corte (dibujada horizontalmente en
algn punto de la tabla) implica que slo los riesgos ubicados sobre la lnea tendrn una atencin posterior. Los riesgos debajo de la
lnea se reevalan para lograr una priorizacin de segundo orden.
Un factor de riesgo que tiene un alto impacto, pero una probabilidad de que suceda muy baja, no debe absorber una cantidad
significativa de tiempo de gestin. Sin embargo, los riesgos de bajo impacto con alta probabilidad deben trasladarse a los pasos de
anlisis de riesgo que siguen.
*en la actualidad+ nadie tiene el lujo de llegar a conocer una tarea tan bien que no se lleve a sorpresas, y las sorpresas significan
riesgo. Stephen Grey
La probabilidad del riesgo se determina realizando estimaciones individuales y luego desarrollando un solo valor de consenso. Aunque
dicho enfoque es valioso, se han desarrollado tcnicas ms elaboradas con las cuales determinar la probabilidad del riesgo. Los
controladores de riesgo se pueden evaluar sobre una escala de probabilidad cualitativa que tiene los siguientes valores: imposible,
improbable, probable y frecuente. Entonces se asocia la probabilidad matemtica con cada valor cualitativo (por ejemplo, una
probabilidad de 0.7 a 0.95 implica un riesgo enormemente probable).
Evaluacin del impacto del riesgo
Tres factores afectan las consecuencias que son probables si un riesgo ocurre: su naturaleza, mbito y tiempo. La naturaleza indica los
problemas que son probables si ocurre El mbito combina la seriedad (cun serio es?) con su distribucin global. Finalmente el tiempo
de cundo y durante qu periodo se sentir el impacto
Regresando una vez ms al enfoque de anlisis de riesgo que propuso la Fuerza Area de los Estados Unidos, se recomiendan los
siguientes pasos para determinar las consecuencias globales de un riesgo:
1. Determinar el valor promedio de la probabilidad de que ocurra para cada componente de riesgo.
2. Empleando la figura, determinar el impacto para cada componente, con base en los criterios mostrados.
3. Completar la tabla de riesgos y analizar los resultados como se describe en las secciones precedentes.
La exposicin al riesgo global, ER, se determina mediante la siguiente relacin:
ER = P x C
Donde P es la probabilidad de que ocurra un riesgo, y C , el costo al proyecto en caso de que ocurra el riesgo.
Por ejemplo, suponga que el equipo de software define un riesgo de proyecto en la forma siguiente:
Identificacin del riesgo: de hecho, slo 70 por ciento de los componentes de software calendarizados para reutilizacin se integra en la
aplicacin. La funcionalidad restante tendr que desarrollarse de modo personalizado.
Probabilidad de riesgo: 80 por ciento (quiz).
Impacto del riesgo: se planificaron 60 componentes de software reutilizables. Si solo se pueden emplear el 70 por ciento, 18
componentes tendran que desarrollarse desde cero (adems de otro software que se ha calendarizado para desarrollo). Puesto que el
componente promedio es de 100 LDC y los datos locales indican que el costo de ingeniera del software para cada uno es de 14.00
dlares, el costo (impacto) global del desarrollo de los componentes seria 18 x 100 x 14 = 25 200 dlares.
Exposicin al riesgo. ER = 0.80 = 25 200 dlares 20 200 dlares.
La exposicin al riesgo se puede calcular para cada riesgo en la tabla de riesgos, una vez que se estime el costo del riesgo. La exposicin
al riesgo total para todos los riesgos (sobre la lnea del corte en la tabla) puede ofrecer un medio con que ajustar la estimacin del costo
final de un proyecto. Tambin se emplea para predecir el aumento probable en los recursos de personal que se requieran en varios
puntos durante la calendarizacin del proyecto.
La proyeccin del riesgo y las tcnicas de anlisis se aplican de manera iterativa conforme avanza el proyecto de software. El equipo del
proyecto debe revisar de nuevo la tabla de riesgos en intervalos regulares, reevaluar cada riesgo para determinar cundo nuevas
circunstancias cambiaran su probabilidad e impacto. Como consecuencia, tal vez sea necesario agregar nuevos riesgos a la tabla,
eliminar algunos riesgos que ahora son irrelevantes y cambiar las posiciones relativas de otros.