Gestión del Riesgo Ingenieria de Software Company LOGO Introducción Gestión de Riesgo Robert Charette en su definición de riesgo lo divide en tres bases: -El riesgo se relaciona con los acontecimientos futuros. -El riesgo implica cambios. -El riesgo implica elección y la incertidumbre que ésta conlleva. Cuando el riesgo se considera en el contexto de la Ingeniería de Software las tres bases se evidencian. -El futuro es una preocupación de primer orden. -El cambio es una preocupación central. -Es necesario enfrentar las opciones. Peter Drucker en su opinión menciona: “Aunque es en vano intentar eliminar el riesgo, y cuestionablemente intentar minimizarlo, es esencial que los riesgos tomados sean los correctos”. Antes de identificar los riesgos correctos es importante identificar los riesgos que son obvios para los gestores y profesionales. Introducción Gestión de Riesgo Gestión de riesgos. El análisis y la gestión son una serie de pasos ayudan a un equipo de software a comprender y manejar la incertidumbre. Lo realizan todos los involucrados en el proceso del software. Es importante por que estar preparados es un elemento clave de una buena gestión de proyectos de software. Los pasos para análisis y gestión de riesgos son: -Reconocer que puede salir mal. -Analizar cada riesgo y determinar la probabilidad de que ocurra . -Clasificar los riesgos por probabilidad e impacto. -Desarrollar un plan para gestionar aquellos riesgos con gran probabilidad y alto impacto. El análisis y gestión de riesgos produce un plan de reducción, supervisión y gestión del riesgo. Estrategias de Riesgo Reactivas y Proactivas Gestión de Riesgo Estrategias de Riesgo Reactivas y Proactivas Estrategias de Riesgo Reactivas y Proactivas Gestión de Riesgo Estrategias Reactivas. -Se denominan “escuela Indiana Jones de Gestión de riesgo”. -No se recomiendo su uso. -Los riesgos son apartados para tratarlos. -Usualmente no se hace nada acerca de los riesgos hasta que algo sale mal. -Cuando algo sale mal el equipo se precipita en la acción para corregir el problema rápidamente (modo bombero). -Cuando falla el modo bombero, la gestión de crisis asume el control y el proyecto esta en un verdadero peligro. “No se preocupen pensare en algo” Indiana Jones. Estrategias de Riesgo Reactivas y Proactivas Gestión de Riesgo Estrategias Proactivas -Es una estrategia mas inteligente y recomendable. -Comienza mucho antes de que se inicie el trabajo técnico. -En esta estrategia se identifican riesgos potenciales, se valoran su probabilidad e impacto y se clasifican según su importancia. -El equipo de software establece un plan para gestionar el riesgo. -El objetivo principal es evitar el riesgo. -Se desarrolla un plan de contingencia que le permita responder de una forma controlada y efectiva cuando un riesgo no puede evitarse. “Equipo de Software Precavido, vale por dos” Riesgos del Software Gestión de Riesgo Riesgos del Software Riesgos del Software Gestión de Riesgo El riesgo siempre involucra dos características Incertidumbre Perdidas Es importante cuantificar el grado de incertidumbre y el grado de perdida de cada riesgo. Riesgos del Software Gestión de Riesgo Riesgos del software Riesgos del proyecto Identifican Potenciales problema en presupuesto, calendarización, personal, recursos, participantes y su impacto sobre un proyecto de software. Se dividen en categorías Riesgos técnicos Riesgos de negocio Están orientados Descubren Potenciales problema en diseño, implementación, interfaz, verificación y mantenimiento. A la administración, contabilidad y mercadotecnia del negocio software. Riesgos del Software Gestión de Riesgo Los riesgos técnicos afectan la calidad y actualidad del software, imposibilita o hace mas difícil la implementación Los riesgos del proyecto alteran la calendarización del proyecto y propicia que los costos aumenten Efectos de las categorías de riesgos cuando se vuelven reales Los riesgos del negocio amenazan la viabilidad del software, ponen en peligro el proyecto o el producto Riesgos del Software Gestión de Riesgo Ejemplos: •El director no apoya el proyecto. •Se diseño un software que nadie quiere. •Perdida de presupuesto o personal •Construcción de un producto que ventas no pude vender. •Un producto que no encaja en la estrategia comercial de la compañía. •El cliente no especifico bien las requisitos. •Los equipos de trabajo creados no son los adecuados. •Se excede el presupuesto obtenido. •No se cumple con las fechas especuladas. •Falta de comunicación entre el personal. •Se tienen ambigüedad en las especificaciones. •Perdida de la datos. •Problemas en la interfaz del usuario. •Desconocimientos de tecnologías de punta. •Dudas o de la técnica utilizadas. •Las técnicas utilizadas se encuentran en desuso. Riesgos del Software Gestión de Riesgo Charette ha propuesto otra categorización de los riesgos. Conocidos Se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del medio ambiente comercial y técnico y otras fuentes de información fiables. Predecibles Se calculan u obtienen con la experiencia de proyectos anteriores. Impredecibles Pueden ocurrir, pero son muy difíciles de identificar por adelantado. Riesgos del Software Gestión de Riesgo Ejemplos: •Cambios en el personal •Mala comunicación con el cliente. •Disminución del esfuerzo del personal. •??????????? •Fecha de entrega irreales. •Falta de requisitos documentados •Pobre entorno de desarrollo •Falta de requisitos en el ámbito del software. Identificación de riesgos Gestión de Riesgo Identificación de Riesgos Evaluación del riesgo global del proyecto. Componentes y controladores del riesgo. Identificación de riesgos Gestión de Riesgo “La identificación de los riesgos es un intento sistematizado y encaminado a especificar las amenazas al plan del proyecto”. Con el fin Evitar los riegos cuando es posible. Controlar los riegos cuando es necesario. Cada una de las categorías de riesgos se dividen en dos tipos: •Riesgos genéricos: Amenazan a todo el proyecto de software. •Riesgos específicos del producto: Los riesgos específicos de producto sólo los 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. Identificación de riesgos Gestión de Riesgo Riesgos específicos del producto •Se identifican examinando el plan del proyecto y la declaración del ámbito del software. •Se busca responder al siguiente cuestionamiento: ¿Qué características especiales de este producto podrían amenazar el plan del proyecto?. •Un método para identificarlos es crear una lista de verificación de riesgos. •Con la lista de verificación se pueden identificar riesgos y enfocarse a un subconjunto de riesgos conocidos y predecibles en las subcategorías genérica enseguida mencionadas. Identificación de riesgos Gestión de Riesgo •Tamaño del producto: riesgos asociados al tamaño global del software que se construirá o modificara. •Impacto en el negocio: riesgos asociados a las restricciones que imponen la gerencia o el mercado. •Características del cliente: riesgos asociados a la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos. •Definición del proceso: riesgos asociados al grado en que se ha definido el proceso del software y en que le da seguimiento la organización que lo desarrolla. •Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se usaran en la construcción del producto. •Tecnología que construir: riesgos asociados con la complejidad del sistema a construir y la tecnología de punta que contiene el sistema. •Tamaño y experiencia de la plantilla del personal: Riesgos asociados con la experiencia técnica y de proyectos de los ingenieros de software que van a realizar el trabajo. Identificación de riesgos Gestión de Riesgo Lista de verificación de riesgos •Puede organizarse de diferentes formas. •Las preguntas relevantes se pueden responder para cada proyecto de software. •Permite que el planificador estime el impacto del riesgo. •También se pueden mencionar las características relevantes para cada subcategoría genérica. •Al final se debe de mencionar un conjunto de componentes y controladores de riesgo junto con su probabilidad de ocurrencia. •Los controladores del desempeño, soporte, costo y calendarización se estudian en las ultimas respuestas. Identificación de riesgos Gestión de Riesgo EVALUACION DEL RIESGO GLOBAL DEL PROYECTO. Esta se puede realiza mediante un cuestionario basados en datos de riesgo. El siguiente cuestionario se basa en los datos de riesgo de gestores de proyecto de software experimentados. 1. Los altos ejecutivos del software y del cliente se han comprometido formalmente. 2. Los usuarios finales están comprometidos con el proyecto y el producto que se construirá. 3. Los requisitos han sido entendidos por el equipo de ingenieros y sus clientes. 4. Los clientes estuvieron completamente involucrados en la definición de requisitos. 5. Los usuarios finales tienen expectativas realistas. 6. El ámbito del proyecto es estable. 7. El equipo tiene la mezcla de correcta de actividades. 8. Los requisitos del proyecto son estables. 9. El equipo tiene experiencia con la tecnología que se implementara. 10. El numero de personas es adecuado para realizar el proyecto. 11. Todos los involucrados están de acuerdo en la importancia del proyecto y los requisitos del sistema. Identificación de riesgos Gestión de Riesgo COMPONENTES y CONTROLADORES DEL TIEMPO. En este enfoque se requiere que el gestor del proyecto identifique los controladores del riesgo que afectan los componentes de riesgo del software. Riesgo de desempeño: el grado de incertidumbre de que el producto satisfaga y se ajuste al uso que se pretende. Riesgo de costo: El grado de incertidumbre que mantendrá el presupuesto del proyecto. Riesgo de soporte: El grado de incertidumbre de que el software final será fácil de corregir, adaptar y mejorar. Riesgo de calendarización: El grado de incertidumbre de que se respete la calendarización y entrega a tiempo del software. Identificación de riesgos Gestión de Riesgo www.themegallery.com 25.4 PROYECCIÓN DEL RIESGO Company Logo 25.4 Proyección del riesgo www.themegallery.com En la proyección o estimación de riesgos se intenta clasificar cada riesgo en 2 formas: La probabilidad de que el riesgo sea real las consecuencias de los problemas asociados con el riesgo, en caso de que ocurra Company Logo 25.4 Proyección del riesgo www.themegallery.com 1. Establecimiento de una escala que refleje la posibilidad percibida de un riesgo. 4 pasos en la proyección del riesgo, realizados por el planificador del proyecto, otros gestores y personal técnico Priorizar los Riesgos para 2. Delineado de las consecuencias del riesgo. 3. Estimación del impacto del riesgo en el proyecto y el producto. Finalidad: que el equipo pueda asignar los recursos donde tengan el mayor impacto. 4. Tomar nota de la precisión global de la proyección del riesgo de modo que no haya malas interpretaciones. Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Una tabla de riesgos ofrece al gestor de un proyecto una técnica simple para la proyección de riesgos Riesgos Categoría Probabilidad Impacto RSGR Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Un equipo de proyecto comienza una lista de todos los riesgos (sin importar cuán remotos sean) con la ayuda de la lista de verificación de riesgos. Riesgos Categoría Probabilidad Impacto RSGR Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Cada riesgo se clasifica (por ejemplo, TP implica un riesgo de tamaño del proyecto, NE implica un riesgo de negocios). Riesgos Categoría Probabilidad Impacto RSGR Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos El valor de la probabilidad de cada riesgo lo pueden estimar individualmente los miembros del equipo. Éstos se encuestan en una forma de "todos contra todos", desarrollando un solo valor de consenso. Riesgos Categoría Probabilidad Impacto RSGR Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Los controladores de riesgo se pueden evaluar sobre una escala de probabilidad cualitativa que tiene los siguientes valores: imposible, improbable, probable y frecuente. Entonces se asocia la probabilidad matemática con cada valor cualitativo (por ejemplo, una probabilidad de 0.7 a 0.95 implica un riesgo enormemente probable). Riesgos Categoría Probabilidad Impacto RSGR Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Se evalúa el impacto de cada riesgo. Cada componente de riesgo se evalúa y se determina una categoría de impacto. Las categorías para cada uno de los cuatro componentes de riesgo (desempeño, soporte, costo y calendarización) se promedian para determinar un valor de impacto global. Riesgos Categoría Probabilidad Impacto RSGR Valores de impacto: 1. catastrófico 2. crítico 3. marginal 4.despreciable Company Logo 25.4 Proyección del riesgo www.themegallery.com Ejemplo . . . Riesgos Categoría Probabilidad Impacto La estimación del tamaño puede ser significativamente baja. TP 60% 2 Mayor numero de usuarios de los previstos TP 30% 3 Los usuarios finales se resisten al sistema CO 40% 3 La fecha limite de entrega estará muy ajustada CO 50% 2 Perdida de fondos CL 40% 1 El cliente cambiara los requisitos TP 80% 2 La tecnología no satisfará las expectativas RT 30% 1 Falta de entrenamiento acerca de las herramientas ED 80% 3 Personal inexperto PE 30% 2 Elevada movilidad del personal PE 60% 2 RSGR Company Logo Valores de impacto: 1. catastrófico 2. crítico 3. marginal 4.despreciable 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Una vez completadas las cuatro primeras columnas de la tabla de riesgos, ésta se ordena según la probabilidad y el impacto. Los riesgos de alta probabilidad y alto impacto se filtran hacia lo alto de la tabla , y los riesgos de baja probabilidad caen al fondo. Esto logra una priorización del riesgo de primer orden. Riesgos Categoría Probabilidad Impacto RSGR Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Riesgos Categoría Probabilidad Impacto RSGR Se estudia la tabla ordenada resultante y define una línea de corte. Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Los riesgos ubicados sobre la línea tendrán una atención posterior y todos deben gestionarse. Riesgos Categoría Probabilidad Impacto RSGR Los riesgos debajo de la línea se reevalúan para lograr una priorización de segundo orden. Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.1 Desarrollo de una tabla de riesgos Contiene una referencia que apunta hacia un Plan de reducción, supervisión y gestión de riesgo o, alternativamente, una colección de hojas de infamación de riesgo desarrolladas para todos los riesgos que están sobre el corte. Riesgos Categoría Probabilidad Impacto RSGR Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.2 Evaluación del impacto del riesgo. Tres factores afectan las consecuencias que son probables si un riesgo ocurre: Su naturaleza Ámbito Tiempo Indica los problemas que son probables si ocurre. ¿cuán serio es? ¿cuánto del proyecto se afectará, o cuántos clientes resultarán dañados? Cuándo y durante qué periodo se sentirá el impacto Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.2 Evaluación del impacto del riesgo. La exposición al riesgo global, ER, se determina mediante la siguiente relación: ER = P x C P es la probabilidad de que ocurra un riesgo. C el costo al proyecto en caso de que ocurra el riesgo. Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.2 Evaluación del impacto del riesgo. Por ejemplo, suponga que el equipo de software define un riesgo de proyecto en la forma siguiente: Identificación del riesgo. Sólo 70 % de los componentes de sw calendarizados para reutilización se integra en la aplicación. Probabilidad de riesgo. 80 % (quizá). Impacto del riesgo. •Se planificaron 60 componentes de sw reutilizables, solo se usaran el 70% •18 componentes tendrían que desarrollarse desde cero. •El componente promedio es 100 LDC y el costo por cada LCD es de 14.00 dólares Costo (impacto) global del desarrollo de los componentes = 18 x 100 x 14 = 25 200 dólares. Exposición al riesgo = 0.80 x 25 200 dólares = 20 200 dólares. Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.2 Evaluación del impacto del riesgo. La exposición al riesgo total para todos los riesgos (sobre la línea de corte en la tabla) puede ofrecer un medio con que ajustar la estimación del costo final de un proyecto. Se emplea para predecir el aumento probable en los recursos de personal que se requieran en varios puntos durante la calendarización del proyecto. La proyección del riesgo y las técnicas de análisis se aplican de manera iterativa conforme avanza el proyecto de software, el equipo del proyecto debe revisar de nuevo la tabla de riesgos en intervalos regulares. Company Logo 25.4 Proyección del riesgo www.themegallery.com 25.4.2 Evaluación del impacto del riesgo. Consejo Compárese la ER de todos los riesgos con la estimación de costos para el proyecto. Si la ER es mayor de 50% del costo del proyecto, la viabilidad del proyecto debe reevaluarse. Company Logo www.themegallery.com 25.5 REFINAMIENTO DEL RIESGO Company Logo 25.5 Refinamiento del riesgo www.themegallery.com Es posible refinar el riesgo en un conjunto de riesgos más detallados, cada uno un poco más sencillo de refinar, supervisar y gestionar. Una forma de hacer esto es representar el riesgo en el formato condición-transición-consecuencia Dado que <condición> entonces existe una preocupación de que (posiblemente) <consecuencia> Company Logo 25.5 Refinamiento del riesgo www.themegallery.com Ejemplo... Dado que todos los componentes de software reutilizables deben ajustarse con estándares de diseño especificas, y como algunos no 10 hacen, entonces existe una preocupación de que (posiblemente) sólo 70 % de los módulos reutilizables planeados puedan en realidad integrarse al sistema que se construirá, por lo que resulta en la necesidad de ingeniería personalizada para el restante 30 % de componentes. Company Logo 25.5 Refinamiento del riesgo www.themegallery.com Ejemplo... Esta condición general se puede refinar en la forma siguiente: Subcondición 1 . Ciertos componentes reutilizables fueron desarrollados por terceras personas sin conocimiento de los estándares de diseño internos. Subcondición 2. El estándar de diseño para el componente de interfases no se ha concretado y tal vez no se ajuste con ciertos componentes reutilizables existentes. Subcondición 3. Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino. Las consecuencias asociadas con estas subcondiciones refinadas siguen siendo las mismas , pero el refinamiento ayuda a aislar los riesgos subyacentes y puede conducir a un análisis y respuestas más sencillos. Company Logo 25.6.-Reducción, Supervisión y Gestión del Riesgo Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo: ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos: •Evitar o Reducir el riesgo. •Supervisar el riesgo. •Gestionar el riesgo y planes de contingencia. 25.6.-Reducción, Supervisión y Gestión del Riesgo •Evitar o Reducir el riesgo. Si un equipo de software adopta un enfoque proactivo hacia el riesgo, evitarlo siempre es la mejor estrategia. Esto ser logra desarrollando un plan para reducir el riesgo. 25.6.-Reducción, Supervisión y Gestión del Riesgo •Supervisar el riesgo. A medida que progresa el proyecto, comienzan las actividades de supervisión del riesgo. El jefe del proyecto supervisa factores que pueden proporcionar una indicación sobre si el riesgo se está haciendo más o menos probable. 25.6.-Reducción, Supervisión y Gestión del Riesgo •Gestionar el riesgo y planes de contingencia. 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. 25.6.-Reducción, Supervisión y Gestión del Riesgo •Ejemplo: Asuma que se ha detectado mucha movilidad del personal como un riesgo del proyecto, r1. Basándose en casos anteriores y en la intuición de administrativa, la probabilidad, l1, de mucha movilidad se estima en un 0.70 (70 por ciento, bastante alto) y el impacto, x1, se proyecta como crítico. Esto es un gran cambio, puede tener un impacto crítico en el costo y planificación temporal del proyecto. 25.6.-Reducción, Supervisión y Gestión del Riesgo Este riesgo se reduce si el gestor del proyecto desarrolla una estrategia para reducir la movilidad. Entre los posibles casos se toman en cuenta: •Reunirse con el personal actual y determinar las causas de la movilidad (por ejemplo: malas condiciones de trabajo, salarios bajos, mercado laboral competitivo). •Actuar para reducir esas causas que estén al alcance de nuestro control antes de que comience el proyecto. •Una vez que comienza el proyecto, asumir que habrá movilidad y desarrollar técnicas que aseguren la continuidad cuando se vaya la gente. •Organizar los equipos del proyecto de manera que la información sobre cada actividad de desarrollo esté ampliamente dispersa. •Definir estándares de documentación y establecer mecanismos para estar seguro de que los documentos se cumplimentan puntualmente. 25.6.-Reducción, Supervisión y Gestión del Riesgo En este caso se pueden supervisar los siguientes factores: •Actitud general de los miembros del equipo basándose en las presiones del proyecto. •Grado de compenetración del equipo. •Relaciones interpersonales entre los miembros del equipo. •Problemas potenciales con compensaciones y beneficios. •Disponibilidad de empleo dentro y fuera de la compañía. 25.6.-Reducción, Supervisión y Gestión del Riesgo Continuando con el ejemplo, el proyecto va muy avanzado y un número de personas anuncia que renunciaran. Si se ha seguido la estrategia de reducción, tendremos copias de seguridad disponibles, la información está documentada y el conocimiento del proyecto se ha dispersado por todo el equipo. Además, el jefe del proyecto puede temporalmente volver a reasignar los recursos (y reajustar la calendarización temporal del proyecto) hacia aquellas funciones completamente estructuradas, así permite que los nuevos elementos que deben agregarse al equipo "tomen el ritmo". 25.6.-Reducción, Supervisión y Gestión del Riesgo Es importante advertir que los pasos reducción, supervisión y gestión del riesgo (RSGR) provocan aumentos del costo 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, el planificador del proyecto realiza un clásico análisis costo-beneficio. Si los pasos RSGR para evitar un riesgo, aumentan lo siguiente en nuestro proyecto: Para un proyecto grande se pueden identificar unos 30 ó 40 riesgos. Si se pueden identificar entre tres y siete pasos de gestión de riesgo para cada uno, la gestión del riesgo puede convertirse en un proyecto por sí misma! Por este motivo, adaptamos la regla de Pareto 80/20 al riesgo del software. La experiencia dice que: 80% del riesgo total de un proyecto, se puede explicar solo con 20% de los riesgos identificados. El trabajo realizado durante procesos de análisis de riesgo anteriores ayudará al jefe de proyecto a determinar qué riesgos pertenecen a ese 20% (por ejemplo, riesgos que conducen a una mayor exposición al riesgo). Algunos riesgos no se incluyen en el RSGR porque no se ubican en el crítico 20%. 25.6.-Reducción, Supervisión y Gestión del Riesgo El riesgo no está limitado al proyecto de software. Los riesgos pueden ocurrir después de que el software se ha desarrollado exitosamente y entregado al cliente. Estos riesgos están típicamente asociados con las consecuencias de la falla de software en el campo. El análisis de seguridad y peligros de software son actividades de aseguramiento de la calidad del software (capítulo 26) que se enfocan en la identificación y evaluación de los peligros potenciales que pudieran afectar al software negativamente y provocar una falla en todo el sistema. Si los peligros se pueden identificar temprano en el proceso de ingeniería del software, las características de diseño de software se pueden especificar de modo que eliminen o controlen los peligros potenciales. 25.7.-El plan RSGR Se puede incluir una estrategia de gestión de riesgo en el plan del proyecto de software o se podrían organizar los pasos de gestión del riesgo en un Plan diferente de reducción, supervisión y gestión del riesgo (Plan RSGR). Todos los documentos del plan RSGR se llevan a cabo como parte del análisis de riesgo y son empleados por el gestor del proyecto como parte del Plan Global del Proyecto. Algunos equipos de software no desarrollan un documento RSGR formal. Más bien, cada riesgo se documenta utilizando una Hoja de Información de Riesgo (HIR). En la mayoría de los casos, la HIR se mantiene utilizando un sistema de base de datos, por lo que la creación y entrada de información, ordenación por prioridad, búsquedas y otros análisis pueden ser realizados con facilidad. 25.6.-Reducción, Supervisión y Gestión del Riesgo 25.7.-El plan RSGR Una vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan los procedimientos de reducción y supervisión del riesgo. Como ya hemos dicho antes: -La reducción del riesgo es una actividad para evitar problemas. - La supervisión del riesgo es una actividad de seguimiento del proyecto con tres objetivos principales: 1.-Valorar si los riesgos predichos de hecho ocurren. 2.-Asegurarse de que los procedimientos para reducir el riesgo definidos para el riesgo en cuestión se están aplicando apropiadamente. 3.-Recoger información que pueda emplearse en el futuro para analizar riesgos. 25.7.-El plan RSGR HERRAMIENTAS DE SOFTWARE El objetivo de las herramientas de gestión del riesgo es ayudar al equipo del proyecto a definir los riesgos, valorar su impacto y probabilidad, y seguir los riesgos a través de todo el proyecto del software. 25.8.-Resumen Siempre que en un proyecto de software esté mucho en Juego, el sentido común dicta el análisis de riesgos. Sin embargo, muchos gestores de proyecto de software lo hacen informal y superficialmente, si es que lo hacen. El tiempo empleado en identificar, analizar y gestionar el riesgo paga por si mismo dividendos en muchas formas: menos trastornos durante el proyecto, una mayor habilidad para seguir y controlar un proyecto, y la confianza que llega cuando se planifican los problemas antes de que ocurran. 25.8.-Resumen Para citar a Sun Tzu, el general chino que vivió hace 2 500 años: “Si usted conoce al enemigo y se conoce a si mismo, no necesita temer el resultado de cien batallas". El enemigo del gestor del proyecto de software es el riesgo. 25.-GESTION DEL RIESGO
