Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Destacado
Destacado (20)
Similar a sesión 14
Similar a sesión 14 (20)
Último
Último (20)
sesión 14
- 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.
- 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.
- 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
- 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
- 36. Número de cambios de requisitos previstos antes y después de la entrega
- 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
- 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
- 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
- 89. Gestores
- 93. Pasos para mitigar el riesgo
- 94. Monitorización
- 97. Gestión
- 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
- 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
- 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?