Está en la página 1de 16

Gestin de Proyectos de Software 1

3.5 Anlisis de riesgos


El SEI (Software Engineering Institute) define al:
Riesgo la posibilidad de sufrir una prdida.
Gestin de Riesgos como la prctica compuesta de procesos,
mtodos y herramientas que posibilita la gestin de los riesgos
en un proyecto y que provee de un entorno disciplinado para la
toma de decisiones pre activa en base a determinar
constantemente que puede ir mal (riesgos), identificar cules son
los riesgos ms importantes en los cuales enfocarse e
implementar estrategias para gestionarlos.
El modelo Moprosoft implementa la gestin de riesgos
definindolas como: acciones establecidas para corregir o
prever una desviacin o problema relacionadas con la relacin
del Plan de Ventas o con los mecanismos de Comunicacin a
los Clientes.
Aprovechamiento
Gestin de Riesgos

ptimo de los
recursos

+ Ganancias
- Perdidas

Actividad clave de todo


proyecto

El riesgo siempre implica dos caractersticas:


Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no
ocurrir; por ejemplo, no hay riesgos de un 100% de probabilidad.
Prdida: si el riesgo se convierte en una realidad ocurrirn
consecuencias no deseadas o prdidas.

Gestin de Proyectos de Software 2

Categoras

conocidos

Se identifican analizando cuidadosamente: el plan


del proyecto, el ambiente de negocios y
tcnico.

Se extrapolan de proyectos anteriores


predecibles

Difciles de anticipar.
impredecibles

3.5.1

Tipos de riesgos

Riesgos de proyecto
Amenazan al plan del proyecto; es decir, si los riesgos del proyecto se
hacen realidad, es probable que la planificacin temporal del proyecto
se retrase y que los costes aumenten. Los riesgos del proyecto
identifican los problemas potenciales de presupuesto, planificacin
temporal, personal (asignacin y organizacin), recursos, cliente y
requisitos y su impacto en un proyecto de software.
Riesgos del producto o tcnicos
Amenazan la calidad, la planificacin o desempeo del software que
hay que producir. Si un riesgo tcnico se convierte en realidad, la
implementacin puede llegar a ser difcil o imposible. Los riesgos
tcnicos identifican problemas potenciales de diseo, implementacin,
de interfaz, verificacin y de mantenimiento. Adems, las
ambigedades de especificaciones, incertidumbre tcnica, tcnicas
anticuadas y las tecnologas punta son tambin factores de riesgo.

Gestin de Proyectos de Software 3

Los riesgos tcnicos ocurren porque el problema es ms difcil de


resolver de lo que pensbamos.
Riesgos de negocio
Amenaza 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 compaa (riesgo estratgico).
3. Construir un producto que el departamento de ventas no sabe
cmo vender (riesgo de comercializacin).
4. Perder el apoyo de una gestin experta debido a cambios de
enfoque o a cambios de personal (riesgo de direccin).
5. Perder presupuesto o personal asignado (riesgos de
presupuesto).

Ejemplo de riesgos

Gestin de Proyectos de Software 4

Riesgos de Negocio

Riesgos de proyecto

Riegsos de producto

La tecnologa
fundamental se sustituye
por una nueva,
originando dudas en la
viabilidad del proyecto.
Una compaa rival ofrece
producto similar antes,
originando prdida de
mercado para el
producto.
Cambia la alta gerencia
del cliente y reduce su
inters en le proyecto,
originando problemas
financieros.

Miembros clave del


proyecto renuncian,
originando un
signiticativo.
Cambio en la
administracion generando
desconcierto en el equipo.
hardware indispensable
no esta a tiempo
oroiginado retrasos.
Cambio exesivo de
requerimientos originando
retraso y mayor costo.
Se subestimo el el
tamao, originando
mayores costos.
Se subestim el nmero
dce defectos originando
retrasos.

Cambio exesivo de
requerimientos
originando mala
funcionalidad.
Los componentes de
software elegidos no
trabajan adecuadamente.
El manejo de base de
datos no soporta el
volumen de
transacciones.
requerimientos no
verificables causan
rechazo en usuarios.
Algoritmo inadecuado no
cumple restricciones de
tiempo de respuesta.

3.5.2

Identificacin, Impacto y proyeccin del riesgo

Identificacin de riesgos

rea de
impacto
Qu
podra
ocurrir?
Consecuencia
(impactoefecto)

Fuente de riesgo

Por qu
podra
ocurrir?

Evento

Cmo
podra
ocurrir?

Causa
(Amenaza)

rea de impacto Qu puede ocurrir?


Consecuencia
Cuantificables

Impacto

Efecto

Riesgo

Gestin de Proyectos de Software 5

Prdidas de vidas (impacto en la comunidad).


Perdida Activos / Pasivos / Capital (quiebra).
Prdida de mercado (perdida cliente).
Costos reposicin o reconstruccin.
Prdida de ingresos (ventas / omisiones / intereses)
Prdida de ingresos por derecho de autor / patentes.
No aprovechamiento oportunidades / fortalezas
Sanciones legales
Indemnizaciones
Costos excesivos
Tcnicas de Identificacin de Riesgos

Existen varios mtodos y herramientas que suelen ser empleados


durante la etapa de identificacin de riesgos. Es importante destacar
que comnmente, estas tcnicas suelen emplearse de manera
combinada.

Tormenta de ideas
El uso de esta tcnica suele trasladarse adems a otras etapas (por
ejemplo, al momento de generar estrategias de mitigacin).

Encuestas
Las encuestas contienen una serie de preguntas tendientes a realizar
la identificacin de riesgos en un rea particular de inters. Un
inconveniente intrnseco de este mtodo es que la gente suele no

Gestin de Proyectos de Software 6

sentirse atrada por las mismas, motivo por el cual pueden brindar
informacin inapropiada; adems, puede ser dificultoso evaluar las
respuestas por la evidente subjetividad asociada a las mismas. Su
ventaja principal lo constituye la posibilidad de obtener una amplia
variedad de opiniones sin necesidad de organizar una reunin para
contar con todos los participantes (algunos de los cuales pueden ser
de difcil acceso).

Entrevistas
No es ms que un mecanismo de preguntas y respuestas cuyo
resultado final ser fuertemente dependiente de la capacidad del
entrevistador y de la correccin de las preguntas. Suele combinarse el
uso de entrevistas con el de la tormenta de ideas, ya sea antes o
despus de la sesin, como entrada para la generacin de ideas o
mecanismo de validacin respectivamente.

Grupos de trabajo
Estn
compuestos por personas especializadas
determinada temtica relacionada con el proyecto.

en

alguna

Conocimiento por experiencia o documentado


Coleccin de informacin que una persona ha obtenido mediante su
experiencia (en este caso particular, riesgos en una determinada rea
de inters).
Taxonomas de riesgos Lecciones aprendidas
Las taxonomas son listados de riesgos que han sido encontrados en
programas, proyectos o situaciones similares a las que se intenta
analizar. Es importante considerar que debe validarse la relevancia y
aplicabilidad de la informacin al hacer uso de esta tcnica. Las
taxonomas se basan en el uso de preguntas que hacen referencia a

Gestin de Proyectos de Software 7

situaciones o eventos sobre un rea particular de un proyecto o


programa y que pueden derivar en una serie de riesgos para el mismo;
generalmente estas preguntas se encuentran agrupadas por reas
temticas (rendimientos, costos, calendario, por ejemplo).

Salidas del Anlisis Orientado a Riesgos


Existen varios tipos de anlisis orientado a riesgos, uno de ellos se
basa en el uso de rboles de anlisis de fallas y otro en el uso de
rboles de anlisis de eventos; ambos constituyen un razonamiento de
arriba hacia abajo que intenta determinar que eventos, condiciones o
fallas pueden llevar a una situacin indeseable. Esta situacin con su
consecuencia asociada puede constituir un riesgo para el proyecto o
programa.
Informacin histrica
Es bsicamente lo mismo que la informacin documentada y suele
usarse del mismo modo, la diferencia entre ambas surge porque la
informacin histrica suele ser ampliamente considerada como un
hecho vlido.

Plantillas de ingeniera
Constituyen un conjunto de diagramas de flujo respecto a varios
aspectos del proceso de desarrollo y se usan como una gua contra la
cual validar, empleando una visin de arriba hacia abajo, las
actividades a realizar durante un proyecto.

Plantillas de camino crtico


Tambin reciben el nombre de plantillas Willoughby y se caracterizan
por mostrar reas de riesgos y proveen un mecanismo de reduccin
de los mismos para cada una de las etapas de un ciclo de vida de
desarrollo de software por el hecho de posibilitar fcilmente su
identificacin. Debido a que se realizan constantemente nuevas

Gestin de Proyectos de Software 8

publicaciones actualizadas de estas plantillas, es importante


considerar el contar con informacin reciente al emplear esta tcnica.

Modelo ms aceptado para la Gestin de Riesgos


El modelo de gestin de riesgos seleccionado consta de cinco pasos,
etapas o fases: Identificacin, Anlisis, Planificacin, Seguimiento y
Control, compartiendo como actividades comunes las de
Documentacin y Comunicacin.

Gestin de Proyectos de Software 9

Control

Identificacion

Seguimiento

Anlisis

Planificacin
Identificacin
Comprende el descubrimiento de los posibles riesgos del proyecto.
No

se

les

debe valorar

priorizar

en esta etapa.

Esta identificacin se puede llevar a cabo mediante una lluvia de ideas


o basarse en la experiencia del administrador.

Anlisis
En esta etapa se considera por separado cada riesgo identificado.
Se decide acerca de la probabilidad de ocurrencia y la seriedad del
mismo: el impacto

Gestin de Proyectos de Software 10

La valoracin recae en la opinin y experiencia del administrador de


proyectos

Valoracin de la probabilidad:
Muy bajo

10 %

Bajo

10 25 %

Moderad (medio)

25 50 %

Alto

50 75 %

Muy alto

75 %

Valoracin del efecto: Insignificante, tolerable, serio, catastrfico.


Los resultados de este anlisis deben registrarse en una tabla, que
debe ser ordenada de acuerdo al valor del riesgo.

Consideraciones
- Si una
situacin que se percibe
como riesgo es segura
(probabilidad 1 100%. Entonces no es un riesgo, es un
problema que debe resolver
- Si una situacin es imposible (probabilidad casi cero). No es un
riesgo, ni importa.
- Si algo indeseable no causa problemas al negocio, el proyecto o
el producto. No es un riesgo, si acaso es una molestia
Tabla de Anlisis de Riesgos
Riesgo

Probabilidad

Efectos

Gestin de Proyectos de Software 11

1 Los problemas financieros de la


organizacin fuerzan a reducir el
presupuesto del proyecto.

Baja

Catastrfico

2 El personal clave est enfermo y no


disponible para momentos crticos.

Media

Serio

3 Los clientes no comprenden el


impacto de los cambios en los
requerimientos.

Media

Tolerante

Alta

Tolerante

Media

Insignificante

4 El tamao del software esta


subestimado.
5 Es ineficiente el cdigo generado por
las herramientas CASE.

Tabla grafica de riesgos


Insignificante

Tolerante

Serio

Catastrfico

Muy alto
Alto
Moderado
Bajo

4
5

2
1

Muy bajo

Las bandas de color indican una forma de priorizar los riesgos: en rojo
son los ms crticos y los verdes los menos.
Exposicin al riesgo
Ejemplo:

Gestin de Proyectos de Software 12

Para Fuerza Area de EU:


- Probabilidad por Costo para el proyecto
Un riesgo con probabilidad 75% y que puede producir una prdida de
$150,000.
Tendr una exposicin al riesgo de: 150000 X .75 = $112,500.
No siempre se puede cuantificar tan exacto.

Planificacin
En esta esta se realiza la planeacin de riesgos, se transforma a la
informacin relacionada con los riesgos en decisiones y acciones
presentes y futuras. La planificacin involucra tanto el desarrollo de
acciones individuales para cada uno de los riesgos como la
priorizacin de dichas acciones y la creacin de un plan integral de
administracin.

Supervisin
En esta parte normalmente se valora cada uno de los riesgos
identificados para decidir si son ms o menos probables y cundo sus
efectos han cambiado.
La supervisin de riesgos debe ser un proceso continuo, cada riesgo
clave debe ser considerado por separado y discutido.
Se vigilan factores de riesgo (indicadores de que se acerca su
ocurrencia)
Seguimiento consiste en monitorizar constantemente tanto del estado
de los riesgos como de las acciones tomadas con el propsito de
evitarlos o mitigar su impacto negativo.
Control de riesgos posibilita el corregir las desviaciones que puedan
producirse a los planes de accin implementados.
Ejemplo de factores de riesgo

Gestin de Proyectos de Software 13

Tipo de riesgo

Indicadores potenciales

Tecnolgico

Entrega retrasada del hardware o de la ayuda al


software, muchos problemas tecnolgicos reportados

Personas

Baja moral del personal, malas relaciones entre


miembros, disponibilidad de empleo

Organizacional

Chismorreo organizacional, falta de acciones por el


administrador principal

Herramientas

Rechazo de los miembros del equipo para utilizar


herramientas, quejas acerca de herramientas
CASE

Requerimientos

Peticiones de muchos cambios en los


requerimientos, quejas del cliente

Estimacin

Fracaso en el cumplimiento de los tiempos


acordados, y en la eliminacin de defectos
reportados

Comunicacin y Documentacin son claves en el modelo debido a


que una falta de efectividad en las mismas impide la viabilidad de
cualquier estrategia de administracin aplicable.

Gestin de Proyectos de Software 14

3.5.3

Evaluacin Global del Riesgo del Proyecto

Las siguientes preguntas son algunas de las muchas que podemos


tomar en cuenta para el xito del proyecto:
1.
Cmo estn definidos los requerimientos del Proyecto? (Bien
definidos, globalmente, mal)
2.

Cul es la extensin en tiempo del Proyecto?

3.

Cul es la composicin del Grupo de Trabajo?

4.
Cmo es la motivacin de la gerencia usuaria? (Fuerte,
positiva, poca)
5.

Cul es la disponibilidad de recursos tcnicos?

6.

Cun nueva es la aplicacin?

Estas entre otras preguntas nos sern de utilidad para la evaluacin


Global de los Riesgos del Proyecto.

Componentes y Controladores del Riesgo


Los controladores del riesgo que afectan a los componentes de riesgo
del software se definen de la siguiente manera:
1.
Riesgo de Rendimiento: el grado de incertidumbre con el que el
producto encontrar sus requisitos y se adecue para su empleo
pretendido.
2.
Riesgo de Coste: el grado de incertidumbre que mantendr el
presupuesto del proyecto.
3.
Riesgo de Soporte: el grado de incertidumbre de la facilidad del
software para corregirse, adaptarse y ser mejorado.
4.
Riesgo de Planificacin: el grado de incertidumbre con que se
podr mantener la planificacin temporal y de que el producto se
entregue a tiempo.

Gestin de Proyectos de Software 15

El impacto de cada controlador del riesgo en el componente de riesgo


se divide en cuatro categoras de impacto (despreciable, leve, crtico y
catastrfico).
Valores de Impacto:
1. Catastrfico

3.5.4

2. Crtico

3. Leve

4. Despreciable

Estrategias frente al riesgo

Para cada uno de los riesgos identificados se puede seleccionar una


estrategia diferente de igual manera pueden ser reemplazadas por una
diferente a medida que se producen revisiones sucesivas de los
riesgos.

Aceptar:
Es una tcnica pasiva que se enfoca en la admisin de cualquier
consecuencia derivada de un riesgo sin tratar de prevenirla. Se
emplea generalmente para riesgos considerados de baja o muy baja
importancia donde no es posible detectar una ganancia significativa al
intentar
lograr
una
reduccin
de
riesgo

Evitar:
Esta estrategia, implica la realizacin de cambios sobre las
condiciones inicialmente pautadas para el proyecto, por ejemplo:
Reduccin del alcance del trabajo.
Cambios de requerimientos y/o especificaciones.
Cambios en las lneas base del proyecto.

Controlar:
Esta tcnica se caracteriza por la toma de acciones concretas y
puntuales tendientes a disminuir la probabilidad de ocurrencia o el

Gestin de Proyectos de Software 16

impacto para un riesgo. Dichas acciones se llevan a cabo


generalmente a lo largo de todo el ciclo de vida del proyecto y se
constituyen en el tipo de respuesta ms comn para los riesgos. En
muchos casos, las acciones asociadas a este tipo de estrategia se
consideran como un producto del proyecto y se controlan y monitorean
como parte de las acciones normales y habituales de seguimiento.

Investigar:
En esta tcnica se difieren todas las acciones hasta que se haya
realizado una mayor cantidad de trabajo y/o hasta que se conozcan la
identificacin de Riesgos de Proyectos de Software. Es importante
destacar que no se define ningn tipo de respuesta para la reduccin
de un riesgo, simplemente porque la estrategia se emplea cuando no
es posible identificar una solucin clara y se requiere llevar a cabo una
investigacin.

Reducir:
En esta tcnica se trabaja activamente para lograr una disminucin de
los riesgos en base a la realizacin de una serie de acciones
planificadas y constantes, tales como: uso de prototipado, revisiones
con especialistas, formacin temprana de un equipo multidisciplinario,
simulaciones, modelados, reuniones del equipo de trabajo, reduccin
de dependencias, involucramiento del cliente, etc.

Transferir:
Es el proceso de mover algo de un lugar a otro o de una persona a
otra. Esta tcnica hace referencia, justamente, a esta idea o concepto,
por ejemplo: transferir un riesgo del equipo de proyecto a un cliente o
un proveedor. Tpicamente la transferencia implica el hacer uso de
proveedores especializados en una determinada rea capaces de
reducir la exposicin final del riesgo.

También podría gustarte