Riesgos de temible mortandad

3-Oct-07

Riesgos

2

Riesgos

• ¿Qué problemas amenazan el desarrollo?

Un riesgo es una variable del proyecto que pone en peligro o impide el éxito del

proyecto.

3

Riesgos

• Si le gusta correr riesgos, desarrolle software– La probabilidad de que un proyecto se

cancele es casi del 50% (Capers Jones, 1991)

– 35% de las empresas encuestadas por Peat Marwick han sufrido un proyecto desbocado (McConnell, 1988)

4

Dirección de Riesgos del Proyecto

• Incluye los procesos relacionados con la planificación, identificación, análisis, control, monitoreo y respuesta a los riesgos que puedan presentarse durante el desarrollo de un proyecto

5

Dirección de Riesgos del Proyecto

• Maximizar los efectos positivos de los distintos eventos y minimizar las consecuencias de sus efectos negativos.

• Un riesgo puede tener una o más causas y si estos ocurren puede producir cierto impacto en el proyecto.

6

Actividades

• Planificar• Identificar• Analizar• Prioritizar• Controlar

7

Planificación de la Gerencia de Riesgos

• Es el conjunto de procesos que pueden decidir cómo planear, conducir y ejecutar las actividades para gerenciar los riesgos del proyecto.

8

Actividades


9

Identificación de Riesgos

• En “Assessment and Control of Software Risks” Capers Jones identifica y estudia más de 60 riesgos importantes y frecuentes en el desarrollo de software.

• McConnel identifica 122 riesgos.• En “Team Leader’s Problem Solver” de

Clay Carr identifica 127 riesgos en el área de interpersonales de un equipo de trabajo.

10


• Determina qué tipo de riesgos es más probable que afecten al proyecto y además documenta las características de cada uno de ellos.

• Debe incluir tanto los riesgos internoscomo los externos.

11


• Se puede lograr identificando causas y efectos o efectos y causas.

• Es un proceso iterativo porque nuevos riesgos pueden surgir a lo largo del proyecto.

12


• Riesgos relativos a la planificación, control y seguimiento del proyecto:

1. Planificación demasiado optimista.2. La planificación omite actividades necesarias

o las subestima: Documentación, testing, depurar código.

3. Las tareas no se distribuyen equitativamente entre los miembros del equipo.

4. El esfuerzo es mayor que el estimado.

13


• Riesgos relativos a los requerimientos y relación con el cliente:

1. Cambios en los requerimientos.2. Requerimientos demasiados ambiciosos para

el tiempo disponible.3. Expectativas irreales del cliente.4. Al cliente se le consulta demasiado tarde y

éste no le gusta o no le sirve el producto.

14


• Riesgos relativos al diseño e implementación:

1. Diseño demasiado sencillo.2. Diseño demasiado complejo.3. No se especifican claramente las interfaces

entre los componentes de software.4. Se desarrollan funciones innecesarias5. Trabajo con un entorno de software

desconocido causa problemas imprevistos.

15


• Riesgos relativos al uso de herramientas y bibliotecas de código:

1. Herramientas de desarrollo/componentes externos de software no están disponibles en el momento indicado.

2. La curva de aprendizaje para la nueva herramientas de desarrollo/componente externo de software es más larga de lo esperado.

3. Se adopta una herramienta por estar de moda.4. Se decide desarrollar una herramienta propia sin medir

los costos.

16


• Riesgos relativos al equipo:1. El equipo se desmoraliza por la situación

interna, lentitud del avance, etc.2. Los miembros del equipo no logran trabajar

bien juntos.3. Problemas de comunicación entre los

miembros del equipo.4. El equipo no confía en uno de sus miembros.

17


• Listas mas completas en:– “Assessment and Control of Software

Risks” Capers Jones.– “Desarrollo y Gestión de Proyectos”, S.

McConnel.– “Team Leader’s Problem Solver”, Clay

Carr.

18

Actividades


19

Analizar y Priorizar Riesgos

• Usualmente los riesgos más importantesse identifican en base a la probabilidad de su ocurrencia y a la severidad de su impacto si se presenta.

20

Actividades


21

Controlar Riesgos

• Un proyecto de desarrollo no está expuesto con la misma intensidad a los mismos riesgos todo el tiempo.

• Revisar periódicamente cómo están los riesgos, qué nuevos riesgos han surgido y qué tan efectivas han sido las medidas tomadas para minimizar los riesgos.

22

Controlar Riesgos

• ¿Cómo manejar los riesgos que hemos identificado como prioritarios?

– Reducir la probabilidad de que se presente.

– Reducir su impacto si se presenta.

23

Controlar Riesgos

• Niveles de control de riesgos:– Reaccionar ante problemas: Monitorear

y planificar como tratarlo si ocurre.– Mitigar el riesgo: Planificar y

monitorear.– Prevenir el riesgo: Determinar orígenes

de riesgos y llevar a cabo planes para evitar que se presenten los riesgos.

24

Controlar Riesgos

Respuestas:- Evitar: eliminando una amenaza específica (eliminando la causa).- Mitigar: reduciendo el valor monetario previsto de un suceso con riesgo.- Aceptar: aceptando las consecuencias en forma pasiva o activa.

25

Controlar Riesgos

• Incluye los procesos de identificación, análisis y planificación de las actividadesa desarrollar ante nuevos riesgos que aparezcan a lo largo del proyecto, reanalizar los riesgos existentes, monitorear los planes de contingencia y revisar la ejecución de las respuestas a cada uno de los riesgos mientras se evalúa su efectividad.

26

Controlar Riesgos

• Implica planificar estrategias alternativas, planes de contingencia y acciones correctivas al Plan de Gerencia del Proyecto.

27

Riesgos en RUP

• Un precepto esencial de RUP es identificar y atacar los más altos riesgos lo más pronto posible.

• La lista de riesgos identifica los eventos, en orden decreciente de prioridad, que podrían afectar el éxito del proyecto.

• Es esencial porque se podría enfocar en aspectos erróneos ahora y explotar una mina insospechada cinco meses más tarde

28

RUP

• Fase de Inicio– Estimar los riesgos.– Artefactos a producir:

• Lista de Riesgos y Plan de Manejo–Describe y prioriza los riesgos–Describe cómo mitigar los riesgos

29

Fase de Inicio

Falla en el servidor de la base de datos: • El servidor de la base de datos puede dejar de estar

operativo y el sistema no pueda almacenar ni extraer valores en la base de datos. Esto podría causar que un proyecto importante realizado por un usuario no pueda ser almacenado en la base de datos del sistema.

• La estrategia de mitigación es colocar como servidor de base de datos una máquina con suficientes recursos para mantener ejecutando las tareas asignadas las 24 horas del día, los 365 días del año.

• En caso de que la falla ocurra, se podrá almacenar el proyecto localmente en un formato binario y posteriormente, cuando el servidor reanude su funcionamiento, el proyecto podrá ser procesado por el sistema para crear un proyecto nuevo.

30

RUP

• Fase de Elaboración– Asegurar que los riesgos están lo

suficientemente mitigados como para estimar el costo y la planificación globales del desarrollo

– Continuar la supervisión de los riesgos críticos remanentes e identificar los riesgos significativos y estimar su impacto en el proceso

– Artefactos a producir:• Una lista de riesgos revisada

31

Fase de Elaboración

• La magnitud del riesgo relacionado con la “Falla del servidor de la base de datos”, se mantuvo igual, ya que no se puede garantizar que deje de ocurrir alguna falla y la empresa no puede adquirir un servidor con mayor potencia y disponibilidad para la base de datos del sistema.

Riesgos - Ejemplo

• Una compañía de software con alta pérdida de personal

• Probabilidad de que la gente se vaya (probabilidad de riesgo) es cerca de 60%

• Impacto probable que se incremente el tiempo del proyecto es 10%, incrementando el costo en 15%

• ¿Cuáles son los pasos a tomar?

Riesgos - Ejemplo

• Pasos:1. Reunión con el staff existente y determinar la razón del

retiro.2. Superar esas causas antes del inicio del proyecto.3. Asumir que el personal continuará retirándose y tomar

medidas para asegurar que el trabajo progrese a pesar de que el personal se retire

4. Preparar equipos de proyectos y asegurar que la información del proyecto sea accesible por cada miembro

5. Iniciar procesos de documentación estándar y asegurar que los documentos sean desarrollados a tiempo.

6. Realizar revisiones de grupo de todo el trabajo que se estárealizando.

Riesgos

• Número de riesgos:– Proyecto Grande: 40-55– Proyecto pequeño: 7-9

• Suponer 4-6 pasos se identifican para cada riesgos, la administración del riesgo en sí es un proyecto.

• Aplicar la regla de Pareto 80/20: 80% de todos los riesgos del proyecto, puede ser ocasionado por el 20% de los riesgos identificados.

Engineering

Riesgos de temible mortandad