Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 8 Parte 1: 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 de reconocer y difíciles de curar. N. Maquiavelo, El Príncipe Buenos Aires, 17 de Septiembre de 2007

2 Definiciones 8Un riesgo es un problema que todavía no ocurrió. 8Un problema es un riesgo que se manifestó. 8Los riesgos tratan sobre eventos posibles del futuro, caracterizados por: 8Probabilidad de que ocurran 8impacto (negativo) si ocurren 8La exposición al riesgo se mide con: 8probabilidad * impacto 8Una fuente de riesgo es algo que me indica que un riesgo está presente 2

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 Report CMU/SEI-99-TR-029. Software Engineering Institute. Carnegie Mellon University. 3

4 Descripción de las tareas 8 Identificar: llevar a la superficie riesgos relacionados con el software antes de que afecten el proyecto 8 Analizar: estudiar fuentes de riesgos, probabilidad e impacto 8 Planificar: transformar la información de riesgos en decisiones y acciones para mitigarlos, definir prioridades de estas acciones, y llevarlas a un plan 8 Seguir: monitorear el estado de los riesgos y las acciones para mitigarlos usando métricas 8 Controlar: ejecutar las acciones planificadas, y corregir las desviaciones de las acciones para mitigar riesgos 8 Comunicar: intercambiar información sobre riesgos con todos los niveles de la organización 4

5 Identificación - Tareas 8Identificar el riesgo 8Documentar el riesgo 8Documentar información de contexto 8 Fuentes del riesgo 8 Interrelaciones 8Eventos 5

6 Identificación - Métodos 8Brainstorms 8Reporte periódico de riesgos 8Cuestionario de identificación taxonómica 8Reportes voluntarios de riesgos 8Listas de riesgos comunes 6

7 Taxonomía de riesgos del SEI Riesgos del Software Clase Ingeniería del Producto Entorno de Desarrollo Restricciones del Proyecto Elemento Reqs... testing Proceso desarrollo Entorno Trabajo Recursos... externas 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,

8 El cuestionario del SEI 8 Consta de 194 preguntas ordenadas según la taxonomía 8 Las respuestas son si o no 8 Existen repreguntas 8 No todas las preguntas aplican en cualquier momento 8 Cuidado con el sesgo waterfall 8 Pensado para un gran proyecto 8 Ejemplos: 8 Sigue usted adelante alguna vez, antes de recibir la aprobación de los usuarios? 8 Entiende el usuario los aspectos técnicos del proyecto? 8 La gente del equipo de trabajo ha implementado sistemas de este tipo? 8 El proyecto depende de un pequeño grupo de personas clave? 8

9 Documentando riesgos 8Para asegurar que están bien expresados se recomienda usar la representación de Gluch 8En la condición están las fuentes del riesgo 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

10 Análisis - Tareas 8Evaluar Riesgos 8Impacto 8Probabilidad 8Tiempo 8Clasificar Riesgos 8Definir prioridades 10

11 Análisis - Métodos 8Para evaluar 8Evaluación binaria 8Impacto: significativo, insignificante 8Probabilidad: muy probable, poco probable 8Tiempo: corto plazo, mediano plazo 8 Evaluación con tres niveles 8Impacto: Crítico, medio, marginal 8Probabilidad: Muy probable, probable, poco probable 8Tiempo: inmediato, corto plazo, mediano plazo 11

12 Análisis - Métodos (2) 8Para clasificar los riesgos 8Consolidación 8Agrupación por afinidad 8Clasificación taxonómica 8Para definir prioridades 8Top 5 - votos de los involucrados y consolidación 8Pareto - Top n - Según evaluación 12

13 Matriz de Magnitudes Para evaluación usaremos el método de 3 niveles del SEI(*) Probabilidad Severidad Muy Probable Probable Poco Probable Crítica Alta Media Media Marginal Baja (*) Cambiamos los niveles de severidad, sacando el nivel catastrófico 13

14 Definición de Prioridades 8Ordenamos los riesgos según la matriz de magnitudes, ignorando los bajos 8Para aquellos con la misma magnitud 8ponemos primero los que requieran acciones correctivas con más urgencia 8si aún persiste el empate, desempatamos con el nivel de impacto 8si es necesario se abren más categorías de impacto 8Siempre tratamos de quedarnos con los 5 o 10 riesgos con mayor exposición 14

15 Lista de Riesgos (SEI) 15

16 Planificación - Métodos 8Planificación general 8 Flowchart de planificación, hoja de riesgo 8Determinar aproximación 8Selección de estrategia (evitar, reducir impacto, reducir probabilidad) 8 Agrupación por áreas de mitigación 8Definir alcance y acciones 8 Lista de acciones, Plan 8Definir mecanismos de tracking 8Objetivo -pregunta -medición 16

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

18 Hoja de Riesgo (SEI) 18

19 Areas de Mitigación 8Ejemplo de áreas de mitigación 8 Administración de Requerimientos del Sistema 8 Planificación y Tracking del Proyecto 8Coordinación de grupos 8 Administración de la Configuración 8 Verificación y Validación 8No tienen por qué coincidir con las taxonomías 8Ventaja: con un mismo plan atacamos varios riesgos 19

20 Mecanismos de Tracking 8 Recordemos el proceso de las métricas... 8 Objetivo 8En este caso, es saber si debo actuar ante el riesgo xxx 8 Pregunta 8 Qué preguntas debo responder para saber si debo actuar? 8 Medición 8 Qué números responden mis preguntas? 8 Ejemplo 8 Riesgo: falta de repuesta del proveedor puede provocar atrasos 8 Pregunta: Cuánto está tardando el proveedor en responder? 8 Medición: Tiempo promedio de respuesta del proveedor 8 Umbral: más de 1 día 20

21 Planificación de Contingencia 8Los planes de contingencia son como cualquier otro plan 8Algunas consideraciones: 8Debe quedar claro, con los mecanismos de tracking, cuándo se los pone en práctica 8Su nivel de detalle depende de la exposición al riesgo y la urgencia de la aplicación de las acciones de mitigación 8Debe preverse el impacto en el plan general 8 Debe ser implementable! 21

22 Riesgos Comunes en Proyectos 8 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

23 Seguimiento - Tareas 8Reporte y Seguimiento 8 Recibir reportes de estado de los riesgos 8 Analizarlos 8Repetir identificación de riesgos 8 Al avanzar el proyecto aparecen nuevos riesgos 23

24 Seguimiento - Métodos 8Reporte y seguimiento 8Reporte de estado de mitigación para todos los planes en curso 8Hoja de riesgos 8 Chart de semáforos 8 Gráficos temporales para métricas 8 Gráficos combinados de métricas de dos riesgos 8Repetir identificación 8usamos los mismos métodos que para la identificación inicial 24

25 Reportes de estado 8Hacer reuniones quincenales de seguimiento de riesgos 8Incluir seguimiento de riesgos en reuniones de seguimiento del proyecto (recomendado) 8Usar charts de semáforos 8Verde: el plan de mitigación marcha como esperado y no se requieren acciones del management 8Amarillo: el plan no marcha como esperado pero no se requieren acciones del management 8 Rojo: se requieren acciones del management 25

26 Chart de semáforos 26

27 Gráficos temporales de métricas Cantidad de Problemas de Performance Críticos Reportados en UAT Horas Marzo Abril Mayo Junio Julio 27

28 Gráficos combinados de métricas de dos riesgos 28

29 Control - Tareas 8Analizar 8 tendencias, desviaciones y anomalías 8Decidir 8 determinar cómo proceder con los riesgos 8replanificar 8cerrar el riesgo 8invocar el plan de contingencia 8continuar el tracking y ejecución del plan actual 8Ejecutar 8 las decisiones tomadas 29

30 Comunicar - Tareas 8La comunicación es parte de todas las tareas 8Objetivos: 8 los riesgos y planes de mitigación son comprendidos 8 se presta adecuada atención a los riesgos 8Tarea: comunicar los riesgos más importantes a todos los afectados 8grupo de desarrollo 8usuarios 8proveedores, management 30