sesión 14: Gestión de Riesgos en proyectos telemáticos

1. 26/10/2009 Universidad del Cauca Departamento de Telemática GESTIÓN DE RIESGOS EN PROYECTOS SOFTWARE Ambientes de Desarrollo

2. 26/10/2009 Consideraciones Generales El riesgo del proyecto tiene su origen en la incertidumbre que está presente en todos los proyectos. Amenaza al éxito de todo proyecto. Gestión de riesgos = serie de pasos que ayudan a comprender y manejar la incertidumbre que implica el desarrollo de todo proyecto.

4. No se cumplen los plazos de entrega.

7. Requerimientos Cambiantes.

8. Tardó demasiado para el mercado.

9. Estimaciones inadecuadas.

10. Oficinas de trabajo muy llenas.

11. Salarios inadecuados.

13. El análisis, diseño y pruebas se realizan sobre la marcha.

14. La calidad es un concepto que todo el mundo estima importante, pero nadie actúa para alcanzarla.

15. Experiencia inadecuada de los desarrolladores.

16. Costes altos de mantenimiento.

18. Un riesgo tiene una o más causas y si se produce tiene uno o más impactos

19. Algunos riesgos son simplemente imposibles de predecir.

21. 26/10/2009 ¿Porque hacer Gestión de Riesgos? Proceso formal de identificar y analizar los riesgos y la consecuente gestión para eliminar, reducir o abordar dichos riesgos. “Incrementar las posibilidades de éxito de un proyecto” Maximizar las probabilidades y consecuencias de eventos positivos. Minimizar las probabilidades y consecuencias de eventos negativos. “Si no atacas activamente a los riesgos, ellos te atacarán activamente a ti” Tom Gilb

22. 26/10/2009 Estrategias de riesgo Reactivas El equipo software no hace nada respecto a los riesgos hasta que algo va mal (Técnica de los bomberos) Actuar en consecuencia => Proyecto en peligro. Proactivas Evaluación previa (antes de los trabajos técnicos) y sistemática de riesgos, y sus consecuencias. Plan de contingencia=>Evasión del riesgo y menor tiempo de reacción

24. Riesgos del negocio* De mercado * De estrategia * De ventas * De gestión * De presupuesto

26. Verificación y mantenimiento.

27. Ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las "tecnologías punta”. Ocurren porque el problema es más difícil de resolver de lo que pensábamos.

28. 26/10/2009 Riesgos del software: Negocio Amenazan la viabilidad del software a construir. Los 5 riesgos son: Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado). Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico), Construir un producto que el departamento de ventas no sabe cómo vender (riesgo ventas). Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de gestión) Perder presupuesto o personal asignado (riesgos de presupuesto).

29. 26/10/2009 Plan RSGR o RMMM Gestión de riesgos ACTIVIDADES Identificación Análisis Planeación Seguimiento Control Soporte Comunicación y Documentación

30. 26/10/2009 1. Identificación del riesgo Objetivo: especificar los riesgos al plan del proyecto Para identificarlos se examina el plan del proyecto y la declaración del ámbito del software. Tipos de riesgos: Genéricos son para todos los proyectos de software. Específicos de producto (tecnología, el personal y el entorno) Plan RSGR o RMMM

31. 26/10/2009 1. Identificación del riesgo Crear una lista de comprobación de elementos de riesgo conocidos y predecibles para cada una de las categorías: 2. Impacto en el negocio 1. Tamaño del producto 4. Definición del proceso 3. El cliente 5. Entorno de desarrollo 7. Tamaño y experiencia del equipo 6. Tecnología a construir

33. Número de programas, archivos y transacciones

34. Tamaño de la base de datos

35. Número de usuarios

36. Número de cambios de requisitos previstos antes y después de la entrega

38. Fecha límite de entrega razonable

39. Número de clientes que usarán el producto

40. Límites legales y gubernamentales

41. Costos asociados por retrasos en la entrega o producto defectuoso

42. Número de otros productos/sistemas con los que este producto debe tener interoperatividad

44. Un "mal" cliente puede tener un profundo impacto en la habilidad del equipo de software para completar el proyecto a tiempo y dentro de presupuesto.

46. ¿Tiene el cliente una idea formal de lo que se requiere?¿Se ha molestado en escribirlo?

47. ¿Aceptará el cliente gastar su tiempo en reuniones formales de requisitos para identificar el ámbito del proyecto?

48. ¿Está dispuesto el cliente a establecer una comunicación fluida con el desarrollador?

49. ¿Está dispuesto el cliente a participar en las revisiones?

50. ¿Es sofisticado técnicamente el área del producto?

52. ¿Se documentan todos los resultados de las revisiones técnicas, incluyendo los errores encontrados y recursos empleados?

53. ¿Ha desarrollado o adquirido su organización cursos de formación de ingeniería del software para jefes de proyecto y personal técnico?

54. ¿Se llevan a cabo regularmente revisiones técnicas formales de las especificaciones de requisitos, diseño, código y pruebas ?

56. ¿Está escrito su código en más de un 90% en lenguaje de alto nivel?

57. ¿Se emplean herramientas de software para apoyar los procesos de análisis, diseño, pruebas y gestión de la documentación?

58. ¿Se emplean herramientas de software de gestión de configuración para controlar y seguir los cambios a lo largo de todo el proceso del software?

60. ¿Demandan los requisitos del cliente la creación de nuevos algoritmos o tecnología de entrada o salida?

61. ¿Demandan los requisitos del producto una interfaz de usuario especial y el empleo de nuevos métodos de análisis, diseño o pruebas?

62. ¿El software interactúa con hardware nuevo o no probado?

63. ¿Imponen excesivas restricciones de rendimiento los requisitos del producto?

65. ¿Tenemos disponible herramientas de gestión de proceso, proyectos, configuración y pruebas apropiadas para el producto?

66. ¿Proporcionan las herramientas de análisis y diseño, métodos apropiados para el producto a construir?

67. ¿Existen expertos disponibles para responder todas las preguntas que surjan sobre las herramientas?

69. ¿Tiene el personal todos los conocimientos adecuados?

70. ¿Tenemos suficiente personal?

71. ¿Se ha asignado al personal para toda la duración del proyecto?

72. ¿ Ha recibido el personal la formación adecuada?

73. ¿Será mínimo el movimiento del personal para permitir la continuidad? ?

75. Clasificación: según su probabilidad de ocurrencia y el impacto que pudiesen causar

76. Priorización.C Y D

80. Poca motivación Contratos bajos n 1 0,n 0,n Huida del personal sin el proyecto finalizado n Crítico n Planificación 2. Análisis de riesgos: Ejemplo Equipo

83. Cómo evitarlos

84. Cómo supervisarlos

85. Cómo gestionarlos y plan de contingenciaPlan RSGR o RMMM Estrategias * Actuar * Aceptar * Eliminar * Mitigar *Transferir *Delegar * Investigar*Poner bajo observación 26/10/2009

87. Descripción de los principales riesgos

88. Responsabilidades

89. Gestores

92. Estrategia general

93. Pasos para mitigar el riesgo

94. Monitorización

95. Factores a monitorizar

96. Modo de monitorización

97. Gestión

98. Plan de contingencias

99. Consideraciones especiales26/10/2009

101. Se evalúa el progreso del plan de mitigación.

102. Mantiene la búsqueda de nuevos riesgos.C Y D 26/10/2009

104. Decidir como proceder.

105. Implementar la decisión.C Y D Decisiones * Cerrar el riesgo * Ejecutar plan contingencia * Seguir con el plan actual. * Re-planear 26/10/2009

107. Documentación formal.

108. Convocar reuniones de revisión26/10/2009

110. Si un equipo de software adopta un enfoque proactivo hacia el riesgo, evitarlo siempre es la mejor estrategia.

111. Es importante señalar que los pasos de reducción, supervisión y gestión del riesgo (RSGR) generan costos adicionales en el proyecto.

112. Analizar lecciones aprendidas.“Cuando un proyecto tienen éxito, no es porque no haya tenido problemas, sino porque se han superado.” 26/10/2009

113. Conclusiones El riesgo de un proyecto es producto de su grado de innovación, su complejidad, viabilidad de los plazos exigidos y en que medida el producto cambiará el negocio. Una persona ilustrada no debe buscar más precisión que la que permita la naturaleza misma del objeto de estudio. Aristóteles 26/10/2009

114. ¿Preguntas?