Capitulo II - Gestion de Riesgos

Un proyecto que lleve un control efectivo de riesgos reduce:
• El miedo de decirle al jefe del proyecto que se retrasará por un error no

previsto.
• No trabajará noches y fines de semanas a tiempo completo por seis meses.
Control de crisis.- Controlar los riesgos solo cuando se han convertido en
problemas.
Arreglar cada error.- Detectar y reaccionar rápidamente ante cualquier riesgo,

pero solo después de que se haya producido.
Mitigación de riesgos.- Planificar con antelación el tiempo que necesitara para

cubrir riesgos en el caso de que ocurran pero no intentar eliminarlos
inicialmente.
Prevención.- Crear y llevar acabo un plan como parte del proyecto de
software para identificar riesgos y evitar que se conviertan en problemas.
Eliminación de las causas principales.- Identificar y eliminar los factores

que puedan hacer posibles la presencia de algún tipo de riesgo.
• La identificación de riesgos
• El análisis de riesgos
• La asignación de prioridad a los riesgos

• La planificación de la gestión de riesgos
• La resolución de riesgos
• La monitorización de riesgos
Es el primer paso en la gestión de riesgos, existen 3 riesgos generales en
un proyecto de desarrollo:
1. Cometer uno de los errores típicos, llamados también

“Errores clásicos”.
2. Ignorar las “Bases del desarrollo de software”.
3. Fallar en la gestión activa de riesgos.
Unas de las formas más fáciles de identificar los riesgos es
comprobar nuestro proyecto frente a una lista de riesgos de
la planificación.
En cuanto a la Planificación.
• No se puede construir un producto de tal envergadura en el tiempo
asignado.
• El esfuerzo es mayor que el estimado (por líneas de código, puntos
de función, módulos, etc.)
• La presión excesiva en la planificación reduce la productividad.
• La fecha final ha cambiado sin ajustarse al ámbito del producto o a
los recursos disponibles.
En cuanto al Entorno de desarrollo:
• Los espacios físicos no están disponibles en el momento necesario, o no

son adecuados.
• Las herramientas de desarrollo no están disponibles, o no funcionan
como se esperaba.
• El aprendizaje de la nueva herramienta de desarrollo es mas larga de lo
esperado.
En cuanto a los Usuarios Finales, Clientes:
• El cliente no acepta el software entregado.

• El cliente piensa en una velocidad de desarrollo que el personal no
puede alcanzar.
• El cliente intenta controlar el proceso de desarrollo, con lo que el
proceso es más lento.
• Los usuarios finales insisten en nuevos requerimientos.
• Al final a los usuarios no les gusta el producto desarrollado, hay que
volver a diseñarlo y construirlo.
En cuánto al personal contratado:
• La contratación tarda más de lo esperado.

• El personal necesita de tiempo para aprender un lenguaje de
programación nuevo.
• Las personas claves solo están disponibles una parte del tiempo.
• El personal no suministra los componentes en el periodo establecido.
• El personal proporciona material de una calidad inaceptable.
En cuanto al Diseño e Implementación:
• Un diseño demasiado sencillo no cubre las cuestiones principales.

• Un diseño demasiado complejo exige tener en cuenta
complicaciones innecesarias e improductivas en el
implementación.
• Las bibliotecas de código o clases tienen poca calidad y genera una
comprobación extra, corrección de errores y la repetición de
trabajo.
• Los componentes desarrollados por separado no se pueden
integrar de forma sencilla.
Identificado los riesgos de planificación se debe analizar cada riesgo para
determinar su impacto.
• Exposición a riesgos (ER)

La exposición a riesgos es igual a la probabilidad de pérdida no
esperada multiplicada por la magnitud de la pérdida
ER = (probabilidad de pérdida no esperada)(magnitud de la pérdida)

Ejemplo:
La probabilidad puede ser del 15% y puede haber un retraso de tres semanas
sobre la duración del proyecto.
E R = (15/100) (3)
E R = 0.75 semanas
Magnitud Exposición
Probabilidad
Riesgo de la pérdida a riesgo
de pérdida
(semanas) (semanas)
Planificación demasiado optimista 50% 5 2,5
Añadir un requisito para la actualización automática
5% 20 1
desde el mainframe
Añadir nuevas características desde marketing 35% 8 2,8
Interfaz del subsistema de formato de gráficos inestable 25% 4 1
Diseño inadecuado (hay que volver a diseñar) 15% 15 2,3
La aprobación del proyecto tarda mas de lo esperado 25% 4 1
* * * *
* * * *
* * * *
En el caso de que la magnitud de pérdida no sea fácil de estimar
directamente, se puede dividir la pérdida en pérdidas más pequeñas.
• Estimación de la probabilidad de pérdida

Es más subjetiva que la estimación de la magnitud de la pérdida.
• Disponer de la persona que esté familiarizada con el sistema
• Usar técnicas Delphi o de consenso en grupo
• Realizar analogías con apuestas
• Utilizar la calibración mediante adjetivos

Ejemplo:
Si los recursos están disponibles en su momento, persona A gana 500 dólares,

si no lo están, persona B gana 400 dólares
Probabilidad de riesgo = 400 / (400+500)

Probabilidad de riesgo = 0.44 = 44%
A partir de la lista de riegos de planificación se puede priorizar los riesgos de
forma que se sepa dónde centrar el esfuerzo para la gestión de riegos. Los
proyectos generalmente gastan el 80% de su presupuesto en arreglar el 20%
de sus problemas.
Una vez calculado la exposición de riesgos, se ordena los riegos según la

exposición a riesgos en la tabla de estimación de riesgos.
Magnitud Exposición
Probabilidad
Riesgo de la pérdida a riesgo
de pérdida
(semanas) (semanas)
Añadir nuevas características desde marketing 35% 8 2,8
Planificación demasiado optimista 50% 5 2,5
Diseño inadecuado (hay que volver a diseñar) 15% 15 2,3
Las nuevas herramientas de programación no producen
30% 5 1,5
el ahorro prometido
Añadir un requisito para la actualización automática
5% 20 1
desde el mainframe
Interfaz del subsistema de formato de gráficos inestable 25% 4 1
La aprobación del proyecto tarda mas de lo esperado 25% 4 1

* * * *
* * * *
* * * *
• La ordenación de prioridades sólo es aproximada
• La exactitud de los números de la exposición a riesgos y el orden de las
prioridades depende de la precisión de las estimaciones de la probabilidad
y de la magnitud del riesgo.
• La priorización sólo puede llegar a ser tan exacta como la exactitud de las
estimaciones de entrada
• La priorización es algo subjetivo
• Realizar una priorización de riesgos para informar de los riesgos que se
pueden ignorar.
• Desarrollar un plan que controle los riesgos de alta prioridad.
• Plan sencillo que describa de forma detallada como se van a gestionar

los riesgos.
• Descartar riesgos resueltos, monitorear los que se van presentando.

• Evitar el riesgo: Responsabilidad en el desarrollo del sistema.
• Trasladar el riesgo de una parte del sistema a otra: Trasladar el riesgo a

una parte del proyecto donde no afecte el desarrollo del mismo
• Conseguir información acerca del riesgo: Identificar el verdadero peligro

de un riesgo.
• Eliminar origen del riesgo: Se debe cambiar parte del sistema a un
proyecto de investigación.
• Asumir el riego: Hay que aceptar que los riesgos dentro de un proyecto
pueden existir.
• Controlar el riesgo: desarrollar planes de contingencia.
• Recordar el riesgo: colección de planes de gestión de riesgo para poderlos

utilizar en el futuro en otros proyectos.
• Sirve para comprobar como progresa el control de un riesgo e identificar
como aparecen los nuevos.
• Para realizar una mejor monitorización se recomienda

crear una lista con los 10 riesgos principales del proyecto.
• Realizar comprobaciones intermedias dentro del proyecto.

Capitulo II - Gestion de Riesgos

Cargado por

Copyright:

Formatos disponibles

Capitulo II - Gestion de Riesgos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capitulo II - Gestion de Riesgos

Cargado por

Copyright:

Formatos disponibles

Un proyecto que lleve un control efectivo de riesgos reduce:

• El miedo de decirle al jefe del proyecto que se retrasará por un error no

Arreglar cada error.- Detectar y reaccionar rápidamente ante cualquier riesgo,

Mitigación de riesgos.- Planificar con antelación el tiempo que necesitara para

Eliminación de las causas principales.- Identificar y eliminar los factores

• La asignación de prioridad a los riesgos

1. Cometer uno de los errores típicos, llamados también

• Los espacios físicos no están disponibles en el momento necesario, o no

• El cliente no acepta el software entregado.

• La contratación tarda más de lo esperado.

• Un diseño demasiado sencillo no cubre las cuestiones principales.

• Exposición a riesgos (ER)

ER = (probabilidad de pérdida no esperada)(magnitud de la pérdida)

Añadir nuevas características desde marketing 35% 8 2,8

Interfaz del subsistema de formato de gráficos inestable 25% 4 1

Diseño inadecuado (hay que volver a diseñar) 15% 15 2,3

La aprobación del proyecto tarda mas de lo esperado 25% 4 1

• Estimación de la probabilidad de pérdida

• Usar técnicas Delphi o de consenso en grupo

• Realizar analogías con apuestas

• Utilizar la calibración mediante adjetivos

Si los recursos están disponibles en su momento, persona A gana 500 dólares,

Probabilidad de riesgo = 400 / (400+500)

Una vez calculado la exposición de riesgos, se ordena los riegos según la

La aprobación del proyecto tarda mas de lo esperado 25% 4 1

• Plan sencillo que describa de forma detallada como se van a gestionar

• Descartar riesgos resueltos, monitorear los que se van presentando.

• Trasladar el riesgo de una parte del sistema a otra: Trasladar el riesgo a

• Conseguir información acerca del riesgo: Identificar el verdadero peligro

• Controlar el riesgo: desarrollar planes de contingencia.

• Recordar el riesgo: colección de planes de gestión de riesgo para poderlos

• Para realizar una mejor monitorización se recomienda

• Realizar comprobaciones intermedias dentro del proyecto.

También podría gustarte