administracionriesgos - extra

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




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




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.




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




5

Identificación - Tareas

Identificar el riesgo

Documentar el riesgo

Documentar información de contexto

Fuentes del riesgo

Interrelaciones

Eventos




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


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.



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?



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.



10

Análisis - Tareas

Evaluar Riesgos

ImpactoProbabilidad

Tiempo

Clasificar Riesgos

Definir prioridades



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



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



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



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



15

Lista de Riesgos (SEI)



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



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



18

Hoja de Riesgo (SEI)



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



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



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!



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)



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




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




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




26

Chart de “semáforos”




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




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



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

administracionriesgos - extra

Documents