7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 1/29
Ingeniería de Software II
Primer Cuatrimestre de 2008
Buenos Aires, 17 de Abril 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... se hacen fáciles dereconocer y difíciles de curar.”
N. Maquiavelo, El Príncipe
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 2/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
2
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 riesgoestá presente
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 3/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
3
El paradigma según el Software Engineering Institute (SEI)
Fuente: Software Ray Williams et al. Risk Evaluation (SRE) Method Description, verion 2.0. Technical ReportCMU/SEI-99-TR-029. Software Engineering Institute. Carnegie Mellon University.
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 4/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
4
Descripción de las tareas
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 yacciones para mitigarlos, definir prioridades de estas acciones,y llevarlas a un plan
Seguir : monitorear el estado de los riesgos y las acciones paramitigarlos usando métricas
Controlar : ejecutar las acciones planificadas, y corregir lasdesviaciones de las acciones para mitigar riesgos
Comunicar : intercambiar información sobre riesgos con todoslos niveles de la organización
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 5/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
5
Identificación - Tareas
Identificar el riesgo
Documentar el riesgo
Documentar información de contexto
Fuentes del riesgo
Interrelaciones
Eventos
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 6/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
6
Identificación - Métodos
Brainstorms
Reporte periódico de riesgos
Cuestionario de identificación taxonómica
Reportes voluntarios de riesgos
Listas de riesgos comunes
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 7/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
7
Taxonomía de riesgos del SEI
Riesgos del Software
Clase
Elemento
Atributo
Entorno de
Desarrollo
Restricciones
del Proyecto
Ingeniería del
Producto
Recursos .... externasEntorno
Trabajo
Proceso
desarrolloReqs ..... testing
Cronograma ... LogísticaControl ProductoFormalidadEstabilidad ... Escala
Fuente: M. Carr, S. Konda y otros. “Taxonomy Based Risk Identification”. CMU/SEI-93-TR06. Software EngineeringInstitute, 1993.
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 8/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
8
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ónde los usuarios?
¿Entiende el usuario los aspectos técnicos del proyecto?
¿La gente del equipo de trabajo ha implementado sistemas deeste tipo?
¿El proyecto depende de un pequeño grupo de personas clave?
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 9/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
9
Documentando riesgos
Para asegurar que están bien expresados se recomienda
usar la representación de GluchEn la condición están las fuentes del riesgo
Condición
Consecuencia
Dado que...
Entonces (posiblemente)...
Ejemplo: dado que la GUI debe sercodificada usando X Windows, y nohay experiencia en el proyecto en XWindows, entonces (posiblemente) el
código no se complete a tiempo y elproyecto 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.
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 10/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
10
Análisis - Tareas
Evaluar Riesgos
ImpactoProbabilidad
Tiempo
Clasificar Riesgos
Definir prioridades
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 11/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
11
Análisis - Métodos
Para evaluar
Evaluación binariaImpacto: significativo, insignificante
Probabilidad: muy probable, poco probable
Tiempo: corto plazo, mediano plazo
Evaluación con tres nivelesImpacto: Crítico, medio, marginal
Probabilidad: Muy probable, probable, pocoprobable
Tiempo: inmediato, corto plazo, mediano plazo
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 12/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
12
Análisis - Métodos (2)
Para clasificar los riesgos
ConsolidaciónAgrupación por afinidad
Clasificación taxonómica
Para definir prioridades
Top 5 - votos de los involucrados y consolidaciónPareto - Top n - Según evaluación
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 13/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
13
Matriz de Magnitudes
Para evaluación usaremos el método de 3 niveles del SEI(*)
(*) Cambiamos los niveles de severidad, sacando el nivel “catastrófico”
Muy Probable Probable Poco Probable
AltaCrítica
Media Media
Marginal Baja
Probabilidad
Severidad
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 14/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
14
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 accionescorrectivas con más urgencia
si aún persiste el empate, “desempatamos” con elnivel de impacto
si es necesario se abren más categorías de impacto
Siempre tratamos de quedarnos con los 5 o 10 riesgoscon mayor exposición
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 15/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
15
Lista de Riesgos (SEI)
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 16/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
16
Planificación - Métodos
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
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 17/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
17
Flowchart de Planificación
Definición del
Riesgo
Contexto
Probabilidad
Impacto
Tiempo
Clasificación
Ranking
Revisar
Riesgo
Es mi trabajo tratar
con este riesgoSi
No
Es interno a mi
organización
No
Transferir
Delegar Si
Mantener Sé suficiente
sobre este riesgo
Investigar
No
Puedo aceptar
el riesgo
Si
Responsabilidad -
¿Es mi riesgo?
Aproximación -
¿Puedo hacer algo?
No
Evitar /
Cancelar
Puedo actuar
sobre el riesgoSi
No
Controlar
Alcance y acciones
¿Qué debo hacer?
Si
Mitigar Es suficiente una
lista de acciones
Si
Lista de Acciones de
Riesgos
Item 1 - hacer xx
Item 2 - hacer yy
No
Plan de Acción
Cronograma
WBS
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 18/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
18
Hoja de Riesgo (SEI)
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 19/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
19
Areas de Mitigación
Ejemplo de áreas de mitigación
Administración de Requerimientos del SistemaPlanificación y Tracking del Proyecto
Coordinación de grupos
Administración de la Configuración
Verificación y ValidaciónNo tienen por qué coincidir con las taxonomías
Ventaja: con un mismo plan atacamos varios riesgos
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 20/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
20
Mecanismos de Tracking
Recordemos el proceso de las métricas...
ObjetivoEn este caso, es “saber si debo actuar ante el riesgo xxx”
Pregunta
¿Qué preguntas debo responder para saber si deboactuar?
Medición¿Qué números responden mis preguntas?
Ejemplo
Riesgo: falta de repuesta del proveedor puede provocaratrasos
Pregunta: ¿Cuánto está tardando el proveedor enresponder?
Medición: Tiempo promedio de respuesta del proveedor
Umbral: más de 1 día
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 21/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
21
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 demitigación
Debe preverse el impacto en el plan general
Debe ser implementable!
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 22/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
22
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 sistematiene fallas u otros problemas de calidad)
3. Atrasos en los plazos4. Costos demasiado altos
5. Funcionalidad incompleta (falta algo)
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 23/29© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
23
Seguimiento - Tareas
Reporte y Seguimiento
Recibir reportes de estado de los riesgosAnalizarlos
Repetir identificación de riesgos
Al avanzar el proyecto aparecen nuevos riesgos
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 24/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
24
Seguimiento - Métodos
Reporte y seguimiento
Reporte de estado de mitigación para todos los planesen 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óninicial
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 25/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
25
Reportes de estado
Hacer reuniones quincenales de seguimiento de riesgos
Incluir seguimiento de riesgos en reuniones deseguimiento del proyecto (recomendado)
Usar charts de semáforos
Verde: el plan de mitigación marcha como esperado y
no se requieren acciones del managementAmarillo: el plan no marcha como esperado pero no se
requieren acciones del management
Rojo: se requieren acciones del management
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 26/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
26
Chart de “semáforos”
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 27/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
27
Gráficos temporales de métricas
Cantidad de Problemas de Performance Críticos
Reportados en UAT
13
5
333
0
2
4
6
8
10
12
14
Marzo Abril Mayo Junio Julio
Horas
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 28/29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
28
Control - Tareas
Analizar
tendencias, desviaciones y anomalías
Decidir
determinar cómo proceder con los riesgos
replanificar
cerrar el riesgoinvocar el plan de contingencia
continuar el tracking y ejecución del plan actual
Ejecutar
las decisiones tomadas
7/17/2019 AdministracionRiesgos - Extra
http://slidepdf.com/reader/full/administracionriesgos-extra 29/29
29
Comunicar - Tareas
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 losafectados
grupo de desarrollo
usuarios
proveedores, management