Está en la página 1de 29
Ingeniería de Software II Segundo Cuatrimestre de 2008 Clase 8 – Gestión de Riesgos “Algunas

Ingeniería de Software II

Segundo Cuatrimestre de 2008

Clase 8 Gestión de Riesgos

“Algunas enfermedades, como dicen los médicos, son al

principio fáciles de curar pero difíciles de reconocer

pero, a medida que pasa el tiempo reconocer y difíciles de curar.”

se hacen fáciles de

N. Maquiavelo, El Príncipe

Buenos Aires, 25 de Septiembre de 2008

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Definiciones

Un riesgo es un problema que todavía no ocurrió.

Un problema es un riesgo que se manifestó.

Los riesgos tratan sobre eventos posibles del futuro, caracterizados por:

Probabilidad de que ocurran impacto (negativo) si ocurren

La exposición al riesgo se mide con:

probabilidad * impacto

Una fuente de riesgo es algo que me indica que un riesgo está presente

2

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

El paradigma según el Software Engineering Institute (SEI)

El paradigma según el Software Engineering Institute (SEI) Fuente: Software Ray Williams et al. Risk Evaluation

Fuente: Software Ray Williams et al. Risk Evaluation (SRE) Method Description, verion 2.0. Technical Report CMU/SEI-99-TR-029. Software Engineering Institute. Carnegie Mellon University.

3

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Descripción de las tareas

Descripción de las tareas  Identificar : llevar a la superficie riesgos relacionados con el software

Identificar: llevar a la superficie riesgos relacionados con el software antes de que afecten el proyecto

Analizar: estudiar fuentes de riesgos, probabilidad e impacto

Planificar: transformar la información de riesgos en decisiones y acciones para mitigarlos, definir prioridades de estas acciones, y llevarlas a un plan

Seguir: monitorear el estado de los riesgos y las acciones para mitigarlos usando métricas

Controlar: ejecutar las acciones planificadas, y corregir las desviaciones de las acciones para mitigar riesgos

Comunicar: intercambiar información sobre riesgos con todos los niveles de la organización

4

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Identificación - Tareas

Identificación - Tareas  Identificar el riesgo  Documentar el riesgo  Documentar información de contexto

Identificar el riesgo

Documentar el riesgo

Documentar información de contexto Fuentes del riesgo Interrelaciones Eventos

5

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Identificación - Métodos

Identificación - Métodos  Brainstorms  Reporte periódico de riesgos  Cuestionario de identificación

Brainstorms Reporte periódico de riesgos Cuestionario de identificación taxonómica Reportes voluntarios de riesgos Listas de riesgos comunes

6

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Taxonomía de riesgos del SEI

Riesgos del Software

Riesgos del Software Clase Ingeniería del Entorno de Restricciones Producto Desarrollo del Proyecto
Riesgos del Software Clase Ingeniería del Entorno de Restricciones Producto Desarrollo del Proyecto

Clase

Ingeniería del

Entorno de

Restricciones

Producto

Desarrollo

del Proyecto

Restricciones Producto Desarrollo del Proyecto Elemento Reqs testing Proceso desarrollo Entorno
Restricciones Producto Desarrollo del Proyecto Elemento Reqs testing Proceso desarrollo Entorno
Restricciones Producto Desarrollo del Proyecto Elemento Reqs testing Proceso desarrollo Entorno
Restricciones Producto Desarrollo del Proyecto Elemento Reqs testing Proceso desarrollo Entorno
Restricciones Producto Desarrollo del Proyecto Elemento Reqs testing Proceso desarrollo Entorno
Restricciones Producto Desarrollo del Proyecto Elemento Reqs testing Proceso desarrollo Entorno

Elemento

Reqs

testing

Proceso

desarrollo

Entorno

Trabajo

Recursos

externas

desarrollo Entorno Trabajo Recursos externas Atributo Estabilidad Escala Formalidad Control
desarrollo Entorno Trabajo Recursos externas Atributo Estabilidad Escala Formalidad Control
desarrollo Entorno Trabajo Recursos externas Atributo Estabilidad Escala Formalidad Control
desarrollo Entorno Trabajo Recursos externas Atributo Estabilidad Escala Formalidad Control

Atributo

Estabilidad

Escala

Formalidad Control Producto

Cronograma

Logística

Fuente: M. Carr, S. Konda y otros. “Taxonomy Based Risk Identification”. CMU/SEI-93-TR06. Software Engineering Institute, 1993.

7

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

El cuestionario del SEI

Consta de 194 preguntas ordenadas según la taxonomía

Las respuestas son si o no

Existen repreguntas

No todas las preguntas aplican en cualquier momento

Cuidado con el “sesgo waterfall”

Pensado para un gran proyecto

Ejemplos:

¿Sigue usted adelante alguna vez, antes de recibir la aprobación de los usuarios?

¿Entiende el usuario los aspectos técnicos del proyecto?

¿La gente del equipo de trabajo ha implementado sistemas de este tipo?

¿El proyecto depende de un pequeño grupo de personas clave?

8

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Documentando riesgos

Para asegurar que están bien expresados se recomienda usar la representación de Gluch En la condición están las fuentes del riesgo

Dado que Condición Entonces (posiblemente) Consecuencia
Dado que
Condición
Entonces (posiblemente)
Consecuencia

Ejemplo: dado que la GUI debe ser

codificada usando X Windows, y no hay experiencia en el proyecto en X Windows, entonces (posiblemente) el código no se complete a tiempo y el

proyecto se atrase.

Fuente: David Glutch. “A Construct for Describing Software development risks”. Technical Report CMU/SEI- 94-TR-014. Software Engineering Institute. Carnegie Mellon University.

9

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Análisis - Tareas

Evaluar Riesgos Impacto Probabilidad Tiempo

Clasificar Riesgos

Definir prioridades

 Tiempo  Clasificar Riesgos  Definir prioridades 10 © Cátedra de Ingeniería de Software II

10

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Análisis - Métodos

Análisis - Métodos  Para evaluar  Evaluación binaria  Impacto: significativo, insignificante 

Para evaluar Evaluación binaria Impacto: significativo, insignificante Probabilidad: muy probable, poco probable Tiempo: corto plazo, mediano plazo Evaluación con tres niveles Impacto: Crítico, medio, marginal Probabilidad: Muy probable, probable, poco probable Tiempo: inmediato, corto plazo, mediano plazo

11

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Análisis - Métodos (2)

Para clasificar los riesgos Consolidación Agrupación por afinidad Clasificación taxonómica

Para definir prioridades Top 5 - votos de los involucrados y consolidación Pareto - Top n - Según evaluación

12

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Matriz de Magnitudes

Para evaluación usaremos el método de 3 niveles del SEI(*)

Probabilidad Muy Probable Probable Poco Probable Severidad Crítica Alta Media Media Marginal Baja
Probabilidad
Muy Probable
Probable
Poco Probable
Severidad
Crítica
Alta
Media
Media
Marginal
Baja

(*) Cambiamos los niveles de severidad, sacando el nivel “catastrófico”

13

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Definición de Prioridades

Ordenamos los riesgos según la matriz de magnitudes, ignorando los bajos

Para aquellos con la misma magnitud ponemos primero los que requieran acciones correctivas con más urgencia si aún persiste el empate, “desempatamos” con el nivel de impacto si es necesario se abren más categorías de impacto

Siempre tratamos de quedarnos con los 5 o 10 riesgos con mayor exposición

14

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Lista de Riesgos (SEI)

Lista de Riesgos (SEI) 15 © Cátedra de Ingeniería de Software II – FCEN – UBA,

15

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Planificación - Métodos

Planificación - Métodos  Planificación general  Flowchart de planificación, hoja de riesgo  Determinar

Planificación general Flowchart de planificación, hoja de riesgo

Determinar aproximación Selección de estrategia (evitar, reducir impacto, reducir probabilidad) Agrupación por áreas de mitigación

Definir alcance y acciones Lista de acciones, Plan

Definir mecanismos de tracking Objetivo - pregunta - medición

16

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Flowchart de Planificación

Definición del Riesgo Contexto Probabilidad Revisar Impacto Investigar Riesgo Tiempo Clasificación Ranking N
Definición del
Riesgo
Contexto
Probabilidad
Revisar
Impacto
Investigar
Riesgo
Tiempo
Clasificación
Ranking
N
o
Es mi trabajo tratar
Sé suficiente
Si
Mantener
con este riesgo
sobre este riesgo
Si
N
o
Si
Es interno a mi
Puedo aceptar
Puedo actuar
Si
Delegar
Si
organización
el riesgo
sobre el riesgo
N
o
N
o
N
o
Evitar /
Transferir
Controlar
Cancelar
Responsabilidad -
Aproximación -
¿Es mi riesgo?
¿Puedo hacer algo?
Lista de Acciones de Riesgos Item 1 - hacer xx Item 2 - hacer yy
Lista de Acciones de
Riesgos
Item 1 - hacer xx
Item 2 - hacer yy
Si
Es suficiente una
lista de acciones
N
o
Plan de Acción
Cronograma
Alcance y acciones
¿Qué debo hacer?
Mitigar
Mitigar
suficiente una lista de acciones N o Plan de Acción Cronograma Alcance y acciones ¿Qué debo
WBS
WBS

17

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Hoja de Riesgo (SEI)

Hoja de Riesgo (SEI) 18 © Cátedra de Ingeniería de Software II – FCEN – UBA,

18

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Areas de Mitigación

Ejemplo de áreas de mitigación Administración de Requerimientos del Sistema Planificación y Tracking del Proyecto Coordinación de grupos Administración de la Configuración Verificación y Validación

No tienen por qué coincidir con las taxonomías

Ventaja: con un mismo plan atacamos varios riesgos

19

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Mecanismos de Tracking

Recordemos el proceso de las métricas

Objetivo En este caso, es “saber si debo actuar ante el riesgo xxx”

Pregunta ¿Qué preguntas debo responder para saber si debo actuar?

Medición ¿Qué números responden mis preguntas?

Ejemplo

Riesgo: falta de repuesta del proveedor puede provocar atrasos Pregunta: ¿Cuánto está tardando el proveedor en responder?

Medición: Tiempo promedio de respuesta del proveedor

Umbral: más de 1 día

20

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Planificación de Contingencia

Los planes de contingencia son como cualquier otro plan

Algunas consideraciones:

Debe quedar claro, con los mecanismos de tracking, cuándo se los pone en práctica

Su nivel de detalle depende de la exposición al riesgo y la urgencia de la aplicación de las acciones de mitigación

Debe preverse el impacto en el plan general Debe ser implementable!

21

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Riesgos Comunes en Proyectos

Los riesgos más comunes en proyectos de desarrollo son:

1.

Desarrollar el producto incorrecto (el sistema no

hace lo que el usuario quería que hiciera)

2.

Desarrollar el producto incorrectamente (el sistema tiene fallas u otros problemas de calidad)

3.

Atrasos en los plazos

4.

Costos demasiado altos

5.

Funcionalidad incompleta (falta algo)

22

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Seguimiento - Tareas

Seguimiento - Tareas  Reporte y Seguimiento  Recibir reportes de estado de los riesgos 

Reporte y Seguimiento Recibir reportes de estado de los riesgos Analizarlos

Repetir identificación de riesgos Al avanzar el proyecto aparecen nuevos riesgos

23

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Seguimiento - Métodos

Seguimiento - Métodos  Reporte y seguimiento  Reporte de estado de mitigación para todos los

Reporte y seguimiento Reporte de estado de mitigación para todos los planes en curso Hoja de riesgos Chart de semáforos Gráficos temporales para métricas Gráficos combinados de métricas de dos riesgos

Repetir identificación usamos los mismos métodos que para la identificación inicial

24

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Reportes de estado

Hacer reuniones quincenales de seguimiento de riesgos

Incluir seguimiento de riesgos en reuniones de seguimiento del proyecto (recomendado)

Usar charts de semáforos Verde: el plan de mitigación marcha como esperado y no se requieren acciones del management Amarillo: el plan no marcha como esperado pero no se requieren acciones del management Rojo: se requieren acciones del management

25

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Chart de “semáforos”

Chart de “semáforos” 26 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008

26

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Gráficos temporales de métricas

Cantidad de Problemas de Performance Críticos

14

12

10

8

6

4

2

0

Reportados en UAT

13

5

13 5
3 3 3

3

3

3

3 3 3
3 3 3
3 3 3
3 3 3
3 3 3
3 3 3

Marzo

Abril

Mayo

Junio

Julio

Horas
Horas

27

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Control - Tareas

Control - Tareas  Analizar  tendencias, desviaciones y anomalías  Decidir  determinar cómo proceder

Analizar tendencias, desviaciones y anomalías

Decidir determinar cómo proceder con los riesgos replanificar cerrar el riesgo invocar el plan de contingencia continuar el tracking y ejecución del plan actual

Ejecutar las decisiones tomadas

28

© Cátedra de Ingeniería de Software II FCEN UBA, 2008

Comunicar - Tareas

Comunicar - Tareas  La comunicación es parte de todas las tareas  Objetivos:  los

La comunicación es parte de todas las tareas

Objetivos:

los riesgos y planes de mitigación son comprendidos se presta adecuada atención a los riesgos

Tarea: comunicar los riesgos más importantes a todos los afectados grupo de desarrollo usuarios proveedores, management

29

© Cátedra de Ingeniería de Software II FCEN UBA, 2008