Reconozca los riesgos que pueden matarle

1. 3-Oct-07
Riesgos

2. 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. 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. 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. 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. 6
Actividades
• Planificar
• Identificar
• Analizar
• Prioritizar
• Controlar

7. 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. 8
Actividades
• Planificar
• Identificar
• Analizar
• Prioritizar
• Controlar

9. 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. 10
Identificación de Riesgos
• 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 internos
como los externos.

11. 11
Identificación de Riesgos
• 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. 12
Identificación de Riesgos
• 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. 13
Identificación de Riesgos
• 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. 14
Identificación de Riesgos
• 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 innecesarias
5. Trabajo con un entorno de software
desconocido causa problemas imprevistos.

15. 15
Identificación de Riesgos
• 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. 16
Identificación de Riesgos
• 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. 17
Identificación de Riesgos
• 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. 18
Actividades
• Planificar
• Identificar
• Analizar
• Prioritizar
• Controlar

19. 19
Analizar y Priorizar Riesgos
• Usualmente los riesgos más importantes
se identifican en base a la probabilidad de
su ocurrencia y a la severidad de su
impacto si se presenta.

20. 20
Actividades
• Planificar
• Identificar
• Analizar
• Prioritizar
• Controlar

21. 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. 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. 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. 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. 25
Controlar Riesgos
• Incluye los procesos de identificación,
análisis y planificación de las actividades
a 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. 26
Controlar Riesgos
• Implica planificar estrategias alternativas,
planes de contingencia y acciones
correctivas al Plan de Gerencia del
Proyecto.

27. 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. 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. 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. 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. 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.

32. 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?

33. 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.

34. 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.