Está en la página 1de 14

Gestión de Riesgos en Ingeniería de

Sistemas Software

Prof. Mary Carlota Bernal


Gestión de Riesgos

• Definiciones
– Riesgo
• Un posible evento futuro que, si ocurre, puede provocar resultados inesperados.
– Riesgos del Proyecto
• Efecto acumulado de los sucesos con resultado incierto que afectan
negativamente a los objetivos del proyecto.
– Gestión del riesgo
• Conjunto de actividades realizadas para la identificación, análisis y control de los
riesgos de un proyecto.
Proceso de Manejo de Riesgos

Identificación de Análisis de Identificación de Identificación de


riesgos riesgos riesgos riesgos

Listado de Anulación de
Listado de riesgos Valoración de
Priorización de Riesgos y planes
potenciales riesgos
riesgos contingencia
Gestión de Riesgos

• Por que es necesaria la gestión del Riesgo?


– Los proyectos tienen tendencia a complicarse y a crecer
– Cada vez son necesarias más y diversas tecnologías
– El número de usuarios es mayor
– Los cambios en los negocios cada vez son más radicales
• Hechos que afectan a la gestión del Riesgo
– Construir software es un negocio arriesgado.
– Es estándar de la industria es ignorar los riesgos.
– La gestión de riesgos cuesta dinero y no se puede demostrar, de antemano, que sea
necesaria.
– La tendencia natural es posponer las partes más complejas del proyecto.
Valoración y Control

Identificación de Riesgos
Valoración
de Riesgos Análisis de Riesgos

Priorización de Riesgos
Gestión de
Riesgos
Planificación de la Gestión
Control de
Riesgos Resolución de Riesgos

Monitorización de Riesgos
Gestión de Riesgo. Identificación y Análisis

• Identificación de los Riesgos


– Se debe mantener un inventario de los riesgos identificando la causa y el efecto
que tendrá.
– Las fuentes pueden ser muy diversas, como sesiones de Brainstorming, datos de
Consultores, Análisis Causa-Efecto, Herramientas, etc.
– Nuestras fuentes son las Suposiciones realizadas al recoger los requerimientos, el
plan de trabajo (camino crítico) y el análisis de los Costes esperados.
• Análisis de los Riesgos
– Se identifica cuándo puede ocurrir, el impacto que puede tener, la probabilidad de
que ocurra y la proximidad al núcleo del proyecto.
– Nosotros utilizamos un método cualitativo, asignando las letras A (bueno) a D
(malo) a cada concepto.
Valor Debo hacer algo? Cuando?
D Si Ahora
C Si Pronto
B Puede ser Revisar
A No Aparcar
Gestión de Riesgo. Priorización

Probability
“D”

“C”
D
(Lejos “B”

del “A”
Núcleo)
C
Riesgo con 
alto Impacto
B
Proximidad Primer 
Riesgo  B
a mirar
A
C
D
B Riesgo de 
(Cerca del Bajo Impacto
Núcleo) A
Tiempo 
Estamos aquí
Análisis Cuantitativo. Estructura de Desglose de
Trabajo
1. Proyecto de 
Sistema de 
Información

1.3 Software 
1.1 Documento  1.2 Documento  1.4 Reportes de  1.5 Entrega a 
Desarrollado e 
de Análisis de Diseño Prueba Operaciones
Instalado

1.1.1  1.5.1 Reporte 
1.2.1 Diseño  1.3.1 Ambiente  1.4.1 Ambiente 
Especificación  de Puesta en 
Funcional de Desarrollo de Pruebas
Funcional Producción

1.1.2 
1.2.2 Diseño  1.4.2 Pruebas  1.5.2 Pruebas 
Requerimientos  1.3.2 Módulo 1
Técnico Integrales Posproducción
Funcionales

1.1.3  1.4.3 Pruebas 
1.2.3 Casos de 
Requerimientos  1.3.3 Módulo 2 de Aceptación  1.5.3 Garantía
Prueba
No Funcionales de Usuario

1.4.4 
1.2.4 
1.3.4 Módulo 3 Certificaciones 
Planificación 
Técnicas

1.3.5 Módulo 4
Análisis Cuantitativo. Estructura de Desglose de
Riesgo
Análisis Cuantitativo. Matriz de Distribución de
Riesgos
La combinación de la estructura de desglose del trabajo (WBS) y 
estructura de desglose riesgo (RBS), da lugar a la Matriz de Distribución 
de Riesgos (Risk Breakdown Matrix ‐ RBM). 
Análisis Cualitativo

Riesgo = Probabilidad de Ocurrencia x Impacto
Riesgo 1: Baja probabilidad y bajo impacto
Riesgo 2: Probabilidad media y bajo impacto
Riesgo 3: Alta probabilidad y bajo impacto

Riesgo 4: Baja probabilidad e impacto medio
Riesgo 5: Probabilidad media e impacto medio
Riesgo 6: Alta probabilidad e impacto medio

Riesgo 7: Baja probabilidad y alto impacto
Riesgo 8: Probabilidad media y alto impacto
Riesgo 9: Alta probabilidad y alto impacto
Proceso para Clasificar los Riesgos

1. A partir del conocimiento del dominio del 
proyecto, crear categorías de riesgos. Por 
ejemplo, la siguiente tabla presenta una 
tabla de riesgos relacionados con madurez 
tecnológica.
2. Determine el grado de aceptación para 
cada riesgo en caso de que se presente

3. Asignar a cada celda en la matriz de riesgo de 5x5 un valor, según la clase de riesgos 
de la Tabla.
4. Ahora se debe dejar en manos de los expertos y su conocimiento del dominio del 
proyecto la asignación de colores ROJO, AMARILLO, VERDE y es las recomendaciones 
en cuanto a pruebas, y evaluaciones externas
Gestión de Riesgo. Control y Monitorización

• Planificación de la gestión de riesgos


– Contiene qué acciones se realizarán para Estabilizar o Desensibilizar el
proyecto de los efectos de, al menos, los 10 riesgos principales, quién las
ejecutará y en que momento.
– Adicionalmente el plan deberá contener los criterios de éxito de la acción
así como los procedimientos de monitorización y los eventos que deben
disparar las alarmas.

• Monitorización de riesgos
– Se realiza una revisión continua e individualizada de las acciones
planificadas para eliminar o mitigar los riesgos principales.
– Se realizan revisiones periódicas para ver si aparecen nuevos riesgos o
se pueden modificar los resultados del análisis de los riesgos
– Los encargados de riesgos deben estar alerta sobre los riesgos y evitar
que estos sean ignorados.
Gestión de Riesgo. Trabajo en Grupo

• Problemas más comunes en proyectos de desarrollo de Software


– Estimaciones inferiores
• Si no se valoran los proyectos de forma adecuada, el resultado final puede
ser entre un 100% y un 250% mayor de lo previsto.
– Gestión del ámbito
• Los proyectos de software tienden a crecer durante el tiempo. Se puede
esperar un crecimiento del tamaño de un 1% mensual.
– Pérdida de esfuerzo
• Puede que todo el tiempo invertido no sea productivo por una baja calidad
del tiempo (interrupciones, ruido ambiental, etc.), por rotación o por realizar
reuniones demasiado largas
– Bajo rendimiento
• La productividad es un factor clave que puede verse alterada por la
complejidad del proyecto, uso de nuevos lenguajes y tecnologías,
herramientas de soporte no adecuadas o necesidad de invertir en procesos
de mejora.

También podría gustarte