-
Notifications
You must be signed in to change notification settings - Fork 1
05. Gestión de Riesgos
germancubillos edited this page Oct 1, 2020
·
1 revision
- Introducción
- Identificación de riesgos
- Análisis cuantitativo de los riesgos
- Análisis cualitativo de los riesgos
- Planificación de respuesta a los riesgos
En esta sección se presentan la gestión de riesgos identificados para la ejecución del proyecto y los riesgos inherentes del producto.
Para la gestión de los riesgos se tiene en cuenta el impacto a los objetivos del proyecto y la matriz de severidad de impacto presentada a continuación:
| Nivel | Descripción |
|---|---|
| Catastrófico | Detiene la implementación del proyecto o tiene alta posibilidad de impactar severamente uno o mas de los siguientes factores: costos, cronograma, producto, proyecto . |
| Critico | Retrasa la implementación del proyecto y afecta directamente la fecha de entrega del proyecto o tiene alta posibilidad de impactar moderadamente uno o mas de los siguientes factores: costos, cronograma, producto, proyecto. |
| Marginal | Retrasa el cronograma interno del proyecto pero no afecta su fecha de entrega o tiene posibilidades de impactar muy poco uno o más de los siguientes factores: costos, cronograma, producto, proyecto. |
Matriz de severidad de impacto
| Probabilidad | Descripción |
|---|---|
| Muy Probable | Probabilidad de ocurrencia > 70% |
| Probable | Probabilidad de ocurrencia entre 30% y 70% |
| Improbable | Probabilidad de ocurrencia < 30% |
Matriz de probabilidad de impacto
Para la identificación de los riesgos para la ejecución del proyecto se toma como base la siguiente RBS (Risk Breakdown Structure)
De las cuales se desglosan en la siguiente tabla:
Lista de riesgos negativos o amenazas
| Código | Riesgo | Probabilidad | Impacto | Calif. del riesgo | Acciones de mitigación |
|---|---|---|---|---|---|
| A001 | Alcance del proyecto es muy ambicioso | PROBABLE | Catastrófico | ALTO | Es necesario mitigar el riesgo o si ya se mitigó comunicar claramente a los patrocinadores |
| A002 | Inflación de requisitos | PROBABLE | Critico | ALTO | A medida que el proyecto avanza, surgen más y más características que no se identificaron al comienzo del proyecto y que amenazan las estimaciones y los plazos. Los cambios y la inflación de requisitos se aceptan como un hecho de los proyectos de software. En lugar de utilizar mecanismos de supresión de cambios, se programan sesiones de priorización que permiten que se realicen cambios que valgan la pena y que las características inicialmente previstas sean reemplazadas si la empresa da su autorización. |
| A003 | El personal clave sale del proyecto llevándose información crítica que retrasa o descarrila significativamente el proyecto. | IMPROBABLE | Critico | ALTO | Utilizar técnicas de intercambio de información como la programación por pares, la propiedad de código común y la presentación de informes frecuentes en reuniones diarias específicamente para reducir el "factor de bus". Cuando este "factor de autobús" (el impacto en el proyecto de un miembro clave golpeado por un autobús) se reduce, varios miembros del equipo comparten información clave y el riesgo debido a la rotación de empleados es pequeño. |
| A004 | Baja productividad | PROBABLE | Marginal | MEDIO | reconocer la ley de Parkinson y el síndrome del estudiante se aplican a proyectos de software. La Ley de Parkinson dice que: "El trabajo se expande para cubrir el tiempo disponible" y el Síndrome del estudiante: "Dada una fecha límite, la gente tiende a esperar hasta que la fecha límite esté casi aquí antes de comenzar a trabajar". Al tener iteraciones cortas, el trabajo se encajona en una iteración manejable (generalmente de una semana) y siempre hay una sensación de urgencia. |
| A005 | Integraciones | PROBABLE | Critico | MEDIO | Identificar en etapas de diseño las interfaces entre los diferentes componentes de la aplicación. Utilizar técnicas de desglose de funcionalidades como DDD para reconocer contextos limitados y sus entidades. |
| A006 | Dependencias del proyecto | PROBABLE | Critico | MEDIO | La construcción de una WBS puede ayudar a identificar componentes y tareas que dependan de la culminación exitosa de otras tareas. Al identificar esto en etapas tempranas del ciclo de desarrollo ayuda a minimizar el riesgo de retrasar el cronograma. En el caso de encontrar dependencias una vez iniciado el desarrollo el equipo en constante comunicación con los patrocinadores creará sesiones de priorización y limitación del alcance. |
| A007 | Falta de habilidades | PROBABLE | Critico | ALTO | Los integrantes del equipo a pesar de tener experiencia en desarrollo se enfrentará en este proyecto con tecnologías y arquitecturas con las cuales no han trabajado antes. Para reducir este riesgo se trabajará de la mano con Arquitectos (Profesores de la materia PICA y Ingeniería de Software en la PUJ) experimentados que guiará al equipo en la realización de pruebas de concepto o talleres que permitan a los integrantes adquirir las habilidades necesarias para cubrir con los requisitos del negocio. |
| A008 | Diseño y arquitectura inapropiadas | IMPROBABLE | Catastrofico | ALTO | Identificar los requerimientos funcionales y no funcionales ademas de los atributos de calidad y validarlos con los patrocinadores de negocio y los Arquitectos asignados al proyecto de forma que la comunicación y el entendimiento de la solución sea el adecuado. Usar técnicas como ATAM para realizar la evaluación de la arquitectura y su ajuste a las necesidades del negocio. También se recomienda usar arquitecturas de referencia que puedan servir de guía y acotar el espacio de soluciones usando recomendaciones y buenas practicas reportadas en la literatura o en diferentes canales de comunicación de la comunidad de desarrollo y arquitectura de software. |
| A009 | Deuda Técnica | MUY PROBABLE | MARGINAL | MEDIO | Debido a la presión del equipo por garantizar el cumplimiento del cronograma y de los compromisos pactados, puede incurrir en una disminución de la calidad del software generado, que para el alcance inicial del proyecto no supone mayor peligro, pero puede manifestarse si en etapas tardías del cronograma se materializan riesgos como A005 y A006. Una forma de mitigar este riesgo es generar el entendimiento colectivo de la importancia de las buenas practicas y realizar evaluaciones constantemente del software generado a través de herramientas de análisis de código estático y finalmente usando programación en parejas. |
lista riesgos positivos u oportunidades
| Código | Riesgo | Probabilidad | Impacto | Acciones |
|---|---|---|---|---|
| O001 | El diseño de una arquitectura que facilite la hiper-escalabilidad habilitará el crecimiento comercial de Toures Balón | PROBABLE | ALTO | El equipo se centrará en el diseño de una arquitectura que se ajuste a los requerimientos de negocio enfocandose en la escalabilidad y disponibilidad de la aplicación. |
| O002 | Crecimiento del sector de turismo post covid-19 | PROBABLE | ALTO | La salida al mercado de una aplicación 100% digital con capacidades diferenciales a la competencia en un momento en el que la demanda de planes de viajes de viaje aumente considerablemente. El equipo trabajará en una solución fácilmente extensible que se adapta a las nuevas regulaciones y requerimientos de los usuarios en un mundo post-covid. |
El análisis cuantitativo se llevará a cabo a través de la matriz de cuantificación de riesgos.
| Severidad\Probabilidad | Muy probable | Probable | Improbable |
|---|---|---|---|
| Catastrófico | Alto | Alto | Medio |
| Critico | Alto | Medio | Bajo |
| Marginal | Medio | Bajo | Bajo |
Tabla de exposición al riesgo global:
| Código | Riesgo | Ponderación del item | Probabilidad de ocurrencia | Exposición al riesgo |
|---|---|---|---|---|
| A001 | Alcance del proyecto es muy ambicioso | 100% | 30% | 30% |
| A002 | Inflación de requisitos | --% | 50% | 50% |
| A003 | El personal clave sale del proyecto | --% | 10% | 20% |
| A004 | Baja productividad | --% | 20% | 20% |
| A005 | Integraciones | --% | 45% | 30% |
| A006 | Dependencias del proyecto | 50% | --% | 30% |
| A007 | Falta de habilidades | --% | 30% | 20% |
| A008 | Diseño y arquitectura inapropiadas | --% | 20% | 10% |
| O001 | El diseño de una arquitectura que facilite la hiper-escalabilidad habilitará el crecimiento comercial de Toures Balón | --% | 50% | 30% |
| O002 | Crecimiento del sector de turismo post covid-19 | --% | 30% | 20% |
La estrategia para riesgos negativos o amenazas:
- Evitar: aislar los objetivos del proyecto al riesgo o relajar el objetivo.
- Transferir: a un tercero (seguros).
- Mitigarla: tomar acción para reducir el impacto.
La estrategia para riesgos positivos u oportunidades:
- Explotar: Que se haga realidad.
- Compartir: asignar a un tercero para que la explote mejor.
- Mejorar: Ir a las fuerzas impulsoras para aumentar el impacto o la probabilidad de ocurrencia.