Identificación y Evaluación de Riesgos y la definición de Planes de contingencia

Ingeniería de Software Grupo 6

Identificación y Evaluación de Riesgos y la definición de Planes de contingencia

Objetivo:

Conocer los factores necesarios para la Identificación y Evaluación de Riesgos y establecer planes de contingencia y gestión de riesgos.

Introducción:

Riesgo:

Un riesgo es cualquier suceso que pueda afectar negativamente a la marcha del proyecto en el futuro. El riesgo, acompaña a todo cambio y está presente en cada decisión. Por tanto, el riesgo, como la muerte y los impuestos, es una de las pocas cosas inevitables en la vida.

Cuando se considera el riesgo en el contexto de la ingeniería del software, podemos distinguir que el futuro es lo que nos preocupa, “” ¿qué riesgos podrían hacer que nuestro proyecto fracasara?”. El cambio es nuestra preocupación, “¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desarrollo, en las computadoras a las que va dirigido el proyecto y a todas las entidades relacionadas con él, al cumplimiento de la planificación temporal y al éxito en general?”. Para terminar, debemos enfrentarnos a decisiones, “¿qué métodos y herramientas deberíamos emplear, cuánta gente debería estar implicada, cuánta importancia hay que darle a la calidad?”.

Riesgo del Software

El riesgo siempre implica dos características:

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no ocurrir; por ejemplo, no hay riesgos de un 100% de probabilidad.

Pérdida: si el riesgo se convierte en una realidad ocurrirán consecuencias no deseadas o pérdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.

Identificación y Evaluación de Riesgos y Planes de Contingencia


Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costes aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos, cliente y requisitos y su impacto en un proyecto de software.

Los riesgos técnicos amenazan la calidad, la planificación o desempeño del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz, verificación y de mantenimiento. Además, las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las “tecnologías punta” son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos.

Los riesgos del negocio amenaza la viabilidad del software a construir. Los riesgos del negocio a menudo ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:

1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado).

2. Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico).

3. Construir un producto que el departamento de ventas no sabe cómo vender (riesgo de comercialización).

4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección).

5. Perder presupuesto o personal asignado (riesgos de presupuesto).

Es extremadamente importante recalcar que no siempre funciona una categorización tan sencilla. Algunos riesgos son simplemente imposibles de predecir.



Los riesgos conocidos son todos aquellos que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial en el que se desarrolla el proyecto y otras fuentes de información fiables (por ejemplo: fechas de entrega poco realistas, falta de especificación de requisitos o de ámbito del software, o un entorno pobre de desarrollo). Los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (por ejemplo: cambio de personal, mala comunicación con el cliente, disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento). Los riesgos impredecibles son el comodín de la baraja. Pueden ocurrir, pero son extremadamente difíciles de identificar por adelantado.

Identificación del RiesgoLa identificación del riesgo es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones, planificación temporal, carga de recursos, etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario.

Es importante identificar los riesgos potenciales lo más pronto posible, pero también se debe continuar con la identificación de los riesgos basados en los cambios en el entorno del proyecto. Se cuenta con varias herramientas y técnicas para identificar riesgos. Los administradores de proyectos a menudo empiezan el proceso de identificación de los riesgos revisando la documentación, y la información reciente e histórica



relacionada a la organización, y los supuestos que pueden afectar el proyecto.

Existen dos tipos diferenciados de riesgos para cada categoría presentada anteriormente:

Riesgos genéricos: son una amenaza potencial para todos los proyectos de software.

Riesgos específicos de producto: sólo pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión. Para identificar los riesgos específicos del producto, se examinan el plan del proyecto y la declaración del ámbito del software y se desarrolla una respuesta a la siguiente pregunta: “¿Qué características especiales de este producto pueden estar amenazadas por nuestro plan del proyecto?”

Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo. La lista de comprobación se centra en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:

Tamaño del producto: riesgos asociados con el tamaño general del software a construir o modificar.

Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o por el mercado.

Características del cliente: riesgos asociados con el cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos.

o Requerimientos (requisitos) confusos o incompletoso Cambios frecuentes a los requerimientos del proyecto

durante la ejecución del mismo.o Cliente y/o usuario que no cumple sus responsabilidades del

proyecto.o Cliente y/o usuario no disponible o sin conocimientos para

proporcionar información precisa de los requerimientos.o Cliente sin expectativas realistas sobre los resultados del

proyecto.o Restricciones contractuales como penalizaciones por no

lograr fechas límites o penalizaciones de la terminación.



Definición del proceso: riesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construcción del producto.

o Recursos no disponibleso Equipo faltante o inadecuado

Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la tecnología punta que contiene el sistema.

Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de proyectos de los ingenieros del software que van a realizar el trabajo.

o Nueva tecnologíao Nuevo ambiente de desarrolloo Nuevo hardwareo Habilidades y/o conocimientos requeridos no satisfechos o

inadecuados

Lista de comprobación de elementos de riesgo

La lista de comprobación de elementos de riesgo puede organizarse de diferentes maneras. Se pueden responder a cuestiones relevantes de cada uno de los temas apuntados anteriormente para cada proyecto de software. Las respuestas a estas preguntas permiten al planificador del proyecto estimar el impacto del riesgo. Un formato diferente de lista de comprobación de elementos de riesgo contiene simplemente las características relevantes para cada subcategoría genérica. Finalmente, se lista un conjunto de “componentes y controladores del riesgo” junto con sus probabilidades de aparición. Los controladores del rendimiento, el soporte, el coste y la planificación temporal del proyecto se estudian como respuesta a preguntas posteriores.

Análisis cualitativo de riesgos

El análisis cuantitativo de riesgos involucra evaluar la probabilidad y el impacto de la identificación de riesgos, para determinar su magnitud y prioridad. Para poder evaluar cuantitativamente los riesgos se cuenta fundamentalmente con tres herramientas: La matriz de probabilidad e impacto para calcular los factores de riesgos, la técnica de seguimiento de los diez factores de riesgo más importantes, y la evaluación del juicio de expertos.

Análisis cuantitativo de los riesgos



El análisis cuantitativo del riesgo a menudo procede al análisis cualitativo del riesgo, aunque ambos procesos pueden llevarse por separado o en forma simultánea. En algunos proyectos, el equipo puede solamente ejecutar el análisis cualitativo. La naturaleza del proyecto y la disponibilidad de tiempo y dinero influyen en el tipo de técnica a utilizar. Los proyectos grandes y complejos que involucran tecnología de punta requieren la aplicación de técnicas cuantitativas. Las principales técnicas para el análisis cuantitativo exigen la recolección de datos, la aplicación de técnicas cuantitativas, y técnicas de modelamiento. Las técnicas de análisis cuantitativo más utilizadas son: el análisis de árboles de decisión, la simulación, y el análisis de sensibilidad.

Planificación de la respuesta de los riesgos

Después que una organización identifica y cuantifica los riesgos, debe desarrollar una apropiada estrategia para poder enfrentarlos.

Las cuatro estrategias de respuesta riesgos negativos son:

1. Evitar los riesgos o eliminar una amenaza específica, generalmente se logra al eliminar sus causas.

2. Aceptar los riesgos o aceptar las consecuencias si el riesgo ocurriese.

3. Transferir los riesgos o trasladar la consecuencia de un riesgo y la responsabilidad por su administración a terceros.

4. Mitigar los riesgos o reducir el impacto de un evento riesgoso al reducir la probabilidad de su ocurrencia.

Las cuatro estrategias para enfrentar los riesgos positivos son:

1. Explotación del riesgo para asegurarnos que el riesgo positivo ocurra.

2. Compartir el riesgo o asignar la propiedad del riesgo a un tercero.

3. Mejora del riesgo o cambiar el tamaño de la oportunidad al identificar y maximizar los inductores claves de un riesgo positivo.

4. Aceptar el riesgo también se aplica a los riesgos positivos cuando el equipo del proyecto no puede o escoge no tomar ninguna acción para enfrentar el riesgo.

Monitoreo y control de los riesgos



El monitoreo y control de los riesgos involucra la ejecución de los procesos de la administración de riesgo para responder a los eventos riesgosos. Ejecutar los procesos de la administración de riesgos significa asegurar que el reconocimiento de los riesgos es una actividad permanente ejecutada por todos los miembros del equipo a lo largo de la vida del proyecto.

Evaluación Global del Riesgo del ProyectoLas siguientes preguntas son algunas de las muchas que podemos tomar en cuenta para el éxito del proyecto:

1. ¿Cómo están definidos los requerimientos del Proyecto? (Bien definidos, globalmente, mal)

2. ¿Cuál es la extensión en tiempo del Proyecto?3. ¿Cuál es la composición del Grupo de Trabajo?4. ¿Cómo es la motivación de la gerencia usuaria? (Fuerte, positiva,

poca)5. ¿Cuál es la disponibilidad de recursos técnicos?6. ¿Cuán nueva es la aplicación?

Estas entre otras preguntas nos serán de utilidad para la evaluación Global de los Riesgos del Proyecto.



Componentes y Controladores del Riesgo

Los controladores del riesgo que afectan a los componentes de riesgo del software se definen de la siguiente manera:

1. Riesgo de Rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido.

2. Riesgo de Coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto.

3. Riesgo de Soporte: el grado de incertidumbre de la facilidad del software para corregirse, adaptarse y ser mejorado.

4. Riesgo de Planificación: el grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo.

El impacto de cada controlador del riesgo en el componente de riesgo se divide en cuatro categorías de impacto (despreciable, leve, crítico y catastrófico).



Riesgos Probabilidad

Impacto

La estimación del tamaño puede ser significativamente baja

60% 2

Mayor número de usuarios de los previstos

30% 3

Menos reutilización de la prevista

70% 2

Los usuarios finales se resisten al sistema

40% 3

La fecha de entrega estará muy ajustada

50% 2

Se perderán los presupuestos

40% 1

El cliente cambiará los requisitos

80% 2

La tecnología no alcanzará las expectativas

30% 1

Falta de formación en las herramientas

80% 3

Personal sin experiencia

30% 2

Habrá muchos cambios de personal

60% 2

Valores de Impacto:

1. Catastrófico 2. Crítico 3. Leve 4.Despreciable

Probabilidad de ocurrenciaDescripción Probabilidad de

ocurrenciaMuy altamente

probable>= 90%

Altamente probable >= 70% y < 90%Muy probable >= 50% y < 70%

Probable >= 20% y < 50%Poco probable >= 5% y < 20%

Improbable <= 5%



Ejemplo de una tabla de riesgo

Proyección del RiesgoLa proyección del riesgo, también denominada estimación del riesgo, intenta medir cada riesgo de dos maneras (la probabilidad de que el riesgo sea real y las consecuencias de los problemas asociados con el riesgo, si ocurriera).

Se realizan cuatro actividades en esta etapa:

1. Establecer una escala que refleje la probabilidad percibida del riesgo.

2. Definir las consecuencias del riesgo.3. Estimar el impacto del riesgo en el proyecto y en el producto.



4. Apuntar la exactitud general de la proyección del riesgo de manera que no haya confusiones.

Se empieza por listar todos los riesgos, se puede hacer con la ayuda de la lista de comprobación. Cada riesgo es categorizado (riesgos de tamaño, de negocio, etc.). Se establece probabilidad de aparición de cada riesgo. A continuación se valora el impacto de cada riesgo.

Una vez completados las cuatro primeras columnas de la tabla de riesgo, esta se ordena por probabilidad y por impacto. Los riesgos de alta probabilidad y de alto impacto pasan a lo alto de la tabla, y los riesgos de baja probabilidad caen a la parte de abajo. Esto consigue la priorización del riesgo de primer orden.

La probabilidad de riesgo puede determinarse haciendo estimaciones individuales y desarrollando después un único valor de consenso.

Evaluación del impacto del riesgo

Tres factores afectan a las consecuencias probables de un riesgo: su naturaleza, su alcance y cuando ocurre.

La naturaleza nos indica los problemas probables que aparecerán si ocurre. El alcance combina la severidad (¿Cómo es de serio el problema?) con su distribución (¿Qué proporción del proyecto se verá afectado y cuantos clientes se verán perjudicados?).

Evaluación del riesgoDurante la evaluación del riesgo, se sigue examinando la exactitud de las estimaciones que fueron hechas durante la proyección del riesgo, se intenta dar prioridades a los riesgos que sea más probable que aparezcan.

Para que sea útil la evaluación, se debe definir un nivel de referencia de riesgo. Para la mayoría de los proyectos, los componentes de riesgos estudiados anteriormente (rendimiento, coste, soporte, planificación), también representan niveles de referencia de riesgos. Es decir hay un nivel para la degradación del rendimiento, exceso de coste, dificultades de soporte o retrasos de la planificación.

Si una combinación de riesgos crea problemas de manera que uno o más de estos niveles de referencia se excedan, se parará el trabajo.



Durante la evaluación del riesgo, se realizan los siguientes pasos:

1. Definir los niveles de referencia de riesgo para el proyecto.2. Predecir el conjunto de puntos de referencia que definan la

regin de abandono, limitado por una curva o áreas de incertidumbre.

3. Intentar predecir como afectarán las combinaciones compuestas de riesgos a un nivel de referencia

Reducción, Supervisión y Gestión de RiesgosTodas las actividades de análisis de riesgo presentadas tienen como objetivo ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos.

Una estrategia eficaz debe considerar tres aspectos:

Evitar el riesgo Supervisar el riesgo Gestionar el riesgo y planes de contingencia



Si un equipo de software adopta un enfoque proactivo frente al riesgo, evitarlo es siempre la mejor estrategia. Esto se consigue desarrollando un plan de reducción del riesgo.

La gestión del riesgo y los planes de contingencia asumen que los esfuerzos de reducción han fracasado y que el riesgo se ha convertido en una realidad.

Los pasos RSGR provocan aumentos del coste del proyecto. Parte de la gestión de riesgos es evaluar cuando los beneficios obtenidos por los pasos RSGR superan los costes asociados con su implementación. En esencia quien planifique el proyecto realiza el clásico análisis coste/beneficio.

Una vez que se ha desarrollado el plan y el proyecto ha comenzado, empiezan los procedimientos de reducción y supervisión del riesgo. Como ya se menciono antes, la reducción del riesgo es una actividad para evitar problemas. La supervisión es de seguimiento del proyecto con tres objetivos: (1) evaluar cuando un riesgo previsto ocurre de hecho, (2) asegurarse de que los procedimientos para reducir el riesgo definido para el riesgo en cuestión se están aplicando apropiadamente, (3) recoger información que pueda emplearse en el futuro para analizar riesgos.

En muchos casos, los problemas que ocurren durante un proyecto pueden afectar a más de un riesgo. Otro trabajo de la supervisión es intentar determinar el origen (que riesgos ocasionaron tal problema a lo largo de todo el proyecto).

Ejemplo Plan de contingenciaDe acuerdo a los Siguientes riesgos Se plantean los respectivos planes de contingencia:

Riesgo

Dado que el sistema es centralizado, entonces una falla en el servidor central puede causar la inutilización parcial o total del sistema.

Plan de mitigación: Tener un aprovisionamiento de energía eléctrica suplementario, utilizando UPS y generador eléctrico. Como así también, el monitoreo por parte de un operador.



Plan de contingencia: Tener disponible ambiente de contingencia alternativo.

Evento Trigger: Falta de suministro de energía en la central por falla de la UPS y del generador eléctrico.

Riesgo

Dado que no se determinó correctamente el tamaño y la complejidad del sistema, entonces el proyecto tiene muchas posibilidades de fracaso.

Plan de mitigación: Dedicar el tiempo y recursos suficientes para realizar un análisis detallado de la información disponible al momento de determinar el alcance del proyecto.

Plan de contingencia: Renegociar las características del proyecto con el Cliente entregando la mínima funcionalidad solicitada.

Evento Trigger: al detectar errores de estimación en las primeras etapas del proyecto.

Riesgo

Dado que el sistema es una aplicación web, entonces puede ser que haya lugares de hemoderivados que no posean Internet.

Plan de mitigación: No aplica

Plan de contingencia: Establecer tratados con ISPs que alcancen cualquier punto del país.

Evento Trigger: La notificación de la no conectividad en algún punto del país.

Riesgo

Dado que se manejan datos sensibles, entonces es probable la necesidad de mantenimiento inmediato, por sanción de decretos o leyes, produciéndose un retraso en las fechas de entrega.

Plan de mitigación

Dedicar tiempo de recursos, a mantenerse al día con la sanción de leyes o decretos referidos a Habeas Data y otros relacionados.



Plan de contingencia

Asignar recursos a desarrollar para implementar la nueva imposición por parte del gobierno y organismo gubernamental que fuere.

Evento Trigger: Descubrimiento de una omisión por desconocimiento o por sanción de una nueva ley.

Riesgo

Dado que no hay sistemas similares, y pocos datos, entonces es posible que el almacenamiento estimado sea escaso, teniendo esto un impacto sobre el coste total del proyecto

Plan de mitigación: Contemplar un margen de holgura superior al 20% en la asignación de almacenamiento.

Plan de contingencia: Tener medios de almacenamiento alternativos.

Evento Trigger: Mal funcionamiento del sistema por falta de espacio en el almacenamiento de los datos.

Riesgo

Dado que no se ha asignado el tiempo adecuado a integración y testeo, entonces pueden encontrarse errores en la interacción entre componentes del sistema.

Plan de mitigación: Implementación del V-Model en el staff completo de desarrollo y testing.

Plan de contingencia: Realizar el testing correspondiente a la etapa de desarrollo en cuestión.

Evento Trigger: Demoras en la etapa de desarrollo.

Riesgo

Dado que se verá afectada la operatoria de los profesionales a la hora de cargar datos de los estudios de sangre, entonces el sistema no reflejará la realidad deseada.

Plan de mitigación: Capacitación previa a la implementación, de los usuarios finales.



Plan de contingencia: Tener un staff de instructores disponibles.

Riesgo

Dado que no se realizan las debidas tareas de testing, entonces el software puede no presentar todas las funcionalidades requeridas.

Plan de mitigación: Respetar el cronograma estipulado para el testing. Y dedicar tiempo extra si es necesario.

Plan de contingencia: Renegociar tiempos para futuras funcionalidades. Mantener presente mediante métricas cuando se vea un atraso considerable, hablar con el sponsor.

Evento Trigger: Demoras en el cronograma.

Riesgo

Dado que no se dedica el 100% del tiempo al proyecto, entonces la calendarización se ve afectada.

Plan de mitigación: Realizar un buen cronograma de compromisos de parte de los integrantes del equipo, contemplando el esfuerzo que cada uno puede asumir. Incluir fechas de finales, salidas de vacaciones y compromisos de otras índoles.

Plan de contingencia: Reasignar tareas entre los integrantes y dedicación de horas extras.

Evento Trigger: Aviso de ausencia del recurso.

Riesgo

Dado que las actividades laborales demandan tiempos dinámicamente cambiantes, entonces es probable que el proyecto se retrase.

Plan de mitigación: Disminución de tiempo de sueño.


Evento Trigger: Aviso de ausencia del recurso.



Riesgo

Dado que el ambiente de desarrollo no es igual al entorno de producción, entonces se pueden presentar bugs al momento de la implementación.

Plan de mitigación: Conseguir o generar una imagen lo más parecida posible al ambiente de producción

Plan de contingencia: Contar siempre con Baselines para dejar operativo el sistema aunque sea con funcionalidades reducidas.

Evento Trigger: Detección del bug.

Riesgo

Dado que el sistema será para uso nacional, entonces puede haber demoras en la respuesta del sistema

Plan de mitigación: Realizar un estudio minucioso del uso que se le dará al sistema, pero en relación con el Ministerio de Salud.

Plan de contingencia: Tener un servidor backup secundario, listo para ser utilizado con información redundante. Poseer a posibilidad de un ancho de banda mayor de subida

Evento Trigger: Detección de demoras del sistema.

Riesgo

Dado que todos los integrantes están en pareja, entonces el asumir compromisos que luego no puedan cumplir produce un retraso en las fechas de entrega.

Plan de mitigación: Aviso prematuro del incumplimiento de las tareas asignadas.


Evento Trigger: Aviso o no cumplimiento de la tarea.



Conclusión:El análisis de riesgo es parte fundamental para el éxito de un proyecto por lo tanto es importante invertir tiempo identificando, analizando y gestionando los riesgos y así nos evitaremos problemas durante el proyecto, y deberíamos tener la precaución de planificar los problemas antes de que ocurran. Se requiere de mayor esfuerzo pero es un esfuerzo que vale la pena.


Identificación y Evaluación de Riesgos y la definición de Planes de contingencia

Documents

Transcript of Identificación y Evaluación de Riesgos y la definición de Planes de contingencia