|
|
 ANTERIOR
INICIO
UNIVERSIDAD DE MURCIA
FACULTAD DERECHO
ESCUELA UNIVERSITARIA TRABAJO SOCIAL
|
|
|
|
|
|
Gestión de riesgos en ingeniería del software "Acceda a la versión actualizada de estos apuntes |
1.- Introducción En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente con nuestras acciones del pasado. La pregunta es, podemos por tanto, cambiando nuestras acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede venir dado por cambios de opinión, de acciones, de lugares... En tercer lugar, el riesgo implica elección y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muerte, es una de las pocas cosas inevitables de la vida.
Cuando se considera el riesgo en el contexto de la ingeniería del
software, los tres pilares conceptuales de Charette se hacen
continuamente evidentes. 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 los ordenadores a las que van dirigidas, el
proyecto y todas las entidades relacionadas con él, al
cumplimiento de la planificación temporal y al éxito en
general? Para terminar, nos enfrentamos con elecciones ¿qué
métodos y herramientas deberíamos emplear, cuánta
gente debería estar implicada, qué importancia hay
que darle a la calidad?
• Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad.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. 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 costos 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 y la planificación temporal 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 amenazan la viabilidad del software a construir Los riesgos del negocio a menudo ponen en peligro ei proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:
2. Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico), 3. Construir un producto que ei departamento de ventas no sabe cómo vender 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.
Otra categorización general de los riesgos ha sido propuesta por
Charette. 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 fíables
(p. ej.: 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 (ej.: cambio de personal, mala
comunicación con el cliente. disminución del esfuerzo
del personal a medida que atienden peticiones de mantenimiento).
Pueden ocurrir pero son extremadamente difíciles de
identificar por adelantado.
• Tamaño del producto: riesgos asociados con el tamaño general del software a construir o a modificar. 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. 3.1.- Riesgos del tamaño del producto Pocos gestores experimentados discutirían la siguiente frase: El riesgo del proyecto es directamente proporcional al tamaño dcl producto. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con el tamaño del producto (software): • ¿Tamaño estimado del producto en LDC o FP?En cada caso, la información del producto a desarrollar debe compararse con la experiencia anterior. Si ocurre una gran desviación del porcentaje o si las magnitudes son similares. pero si los resultados anteriores fueron poco satisfactorios, el riesgo es grande. 3.2.- Riesgos del impacto en el negocio Un gestor de ingeniería (algo magufo) de una gran compañía de software colocó una placa con el texto: "¡dios me concedió el cerebro para ser un buen jefe de proyectos y el sentido común para correr como un diablo cuando marketing establece las fechas límite del proyecto!". Al departamento de marketing le guían las consideraciones del negocio, y éstas entran a veces en conflicto directo con las realidades técnicas. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con el impacto en el negocio: • ¿Efecto de este producto en los ingresos de la compañía?Cada respuesta para el producto a desarrollar debe compararse con la experiencia anterior. Si se obtiene una gran desviación del porcentaje o si las magnitudes son similares, pero los resultados anteriores fueron poco satisfactorios, el riesgo es grande. 3.3.- Riesgos relacionados con el cliente No todos los clientes son iguales. Pressman y Herron tratan este aspecto cuando dicen: Los clientes tienen diferentes necesidades. Algunos saben lo que quieren; otros saben lo que no quieren. Algunos están deseando saber todos los detalles, mientras que otros se quedan satisfechos con vagas promesas. Los clientes tienen diferentes personalidades. Algunos disfrutan siendo clientes (la tensión, la negociación, las recompensas psicológicas de un buen producto). Otros preferirían no ser clientes en absoluto. Algunos aceptarían felizmente cualquier cosa que se les entregara y le sacarían el mejor provecho a un producto pobre. Otros se quejarán amargamente cuando les falte calidad; algunos darán las gracias cuando la calidad es buena; unos pocos se quejarán por todo. Los clientes también tienen varios tipos de asociaciones con sus suministradores. Algunos conocen bien a sus proveedores y sus productos; otros no se han visto nunca las caras y se comunican siempre mediante correspondencia escrita y algunas llamadas telefónicas breves. Los clientes se contradicen a menudo. Quieren todo para ayer y gratis. A menudo, el producto se ve cogido entre las propias contraindicaciones del cliente. 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. Un mal cliente representa una amenaza significativa al plan del proyecto y un sustancial riesgo para el jefe del proyecto. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con diferentes clientes: • ¿Ha trabajado con el cliente anteriormente? 3.4.- Riesgos del proceso Si el proceso del software no está bien definido; si el análisis, diseño y pruebas se realizan sobre la marcha; si la calidad es un concepto que todo el mundo estima importante, pero por la que nadie actúa de manera tangible para alcanzarla, entonces el proyecto está en peligro. Las siguientes preguntas se han extraído sobre la evaluación de la ingeniería del software desarrollado por R. S. Pressman & Associates. Inc. Las preguntas se han adaptado del cuestionario de evaluación del proceso del software del Instituto de Ingeniería del Software (IIS). Aspectos del proceso • ¿Apoyan sus gestores senior unas normas escritas que hagan hincapié en la importancia de un proceso estándar para el desarrollo del software? Aspectos técnicos • ¿Se emplean técnicas de especificación de aplicaciones para ayudar en la comunicación entre el cliente y el desarrollador?Si la mayoría de las cuestiones anteriores se han respondido negativamente, el proceso del software es débil y el riesgo es alto. 3.5.- Riesgos tecnológicos Alcanzar los límites de la tecnología es un reto excitante. Es el sueño de casi todos los técnicos, porque fuerza al profesional a emplear su talento al máximo. Pero también es muy arriesgado. La ley de Murphy parece mantener su imperio en esta parte del universo del desarrollo, haciendo extremadamente difícil predecir los riesgos, y mucho menos hacer ningún plan sobre ellos. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con la técnica a construir. • ¿Es nueva para su organización la tecnología a construir? Si la respuesta a alguna de estas preguntas es afirmativa, se debería realizar una investigación más profundidad para valorar el riesgo potencial. 3.6.- Riesgos del entorno de desarrollo Si a un carpintero se le pidiera que construyera un mueble de calidad con una simple sierra de mano, se dudaría de la calidad del producto final. Las herramientas inapropiadas o ineficaces pueden estropear los esfuerzos de incluso un experimentado profesional. El entorno de ingeniería del software soporta al equipo del proyecto. al proceso y al producto. Pero si el entomo es malo. puede ser una fuente de riesgos significativa. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados com el entomo de desarrollo: • ¿Tenemos disponible una herramienta de gestión de proyectos de software? Si se ha contestado negativamente a la mayoría de las preguntas anteriores, el entomo de desarrollo es débil y el riesgo es alto. 3.7.- Riesgos asociados con el tamaño de la plantilla de personal y su experiencia: Bohem sugiere las siguientes cuestiones para valorar los riesgos asociados con el tamaño de la plantilla de personal y su experiencia: • ¿Disponemos de la mejor gente?Si la respuesta a alguna de estas preguntas es "no", se debería hacer una investigación más profunda para valorar el potencial de riesgo. 3.8.- Componentes y controladores del riesgo Las Fuerzas Aéreas de Estados Unidos han redactado un documento que contiene excelentes directrices para identificar riesgos software y evitarlos. El enfoque de las Fuerzas Aéreas requiere que el gestor del proyecto identifique los controladores del riesgo que afectan a los componentes de riesgo software (rendimiento, coste, soporte y planificación temporal). En el contexto de este estudio, los componentes de riesgo se definen de la siguiente manera: • Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido. El impacto de cada controlador de riesgo en el componente de riesgo se divide en cuatro categorías de impacto -despreciable. marginal, crítico y catastrófico. La figura indica las consecuencias potenciales de errores (filas etiquetadas con 1) o la imposibilidad de conseguir el producto deseado (filas etiquetadas con 2) La categoría de impacto es elegida basándose en la caracterización que mejor encaja con la descripción de la tabla. 
4.- Proyección del riesgo La 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. El jefe del proyecto, junto con otros gestores y personal técnico, realiza cuatro actividades de proyección del riesgo: (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; y (4) apuntar la exactitud general de la proyección del riesgo de manera que no haya confusiones. 4.1.- Desarrollo de una tabla de riesgo Una tabla de riesgo le proporciona al jefe del proyecto una sencilla técnica para la proyección del riesgo'. En la Figura se ilustra una tabla de riesgo como ejemplo. 
Un equipo de proyecto empieza por listar todos los riesgos (no importa lo remotos que sean) en la primera columna de la tabla. Se puede hacer con la ayuda de la lista de comprobación de elementos de riesgo presentada en la Sección 6.3. Cada riesgo es categorizado en la segunda columna (p. ej.: PS implica un riesgo del tamaño del proyecto. BU implica un riesgo de negocio). La probabilidad de aparición de cada riesgo se introduce en. la siguiente columna de la tabla. El valor de la probabilidad de cada riesgo puede estimarse por cada miembro del equipo individualmente. De los valores individuales se obtiene la media para obtener una probabilidad consensuada. A continuación se valora el impacto de cada riesgo. Cada componente de riesgo se valora usando la caracterización presentada en la primera figura, y se determina una categoría de impacto. Las categorías para cada uno de los cuatro componentes de riesgo -rendimiento, soporte, coste y planificación temporal- son promediados para determinar un valor general de impacto. Una vez que se han completado las cuatro primeras columnas de la tabla de riesgo, la tabla es ordenada 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 una priorización del riesgo de primer orden. El jefe del proyecto estudia la tabla ordenada resultante y define una línea de corte. La línea de corte (dibujada horizontalmente)implica que sólo a los riesgos que quedan por encima de la línea se les prestará atención en adelante. Los riesgos que caen por debajo de la línea son reevaluados para conseguir una priorización de segundo orden. El impacto del riesgo y la probabilidad tienen diferente influencia en la gestión como se ve en la siguiente figura. Un factor de riesgo que tenga un gran impacto pero muy poca probabilidad de que ocurra, no debería absorber una cantidad significativa de tiempo de gestión. Sin embargo, los riesgos de gran impacto con una probabilidad , moderada a alta y los riesgos de poco impacto pero de gran probabilidad deberían tenerse en cuenta en los procedimientos de gestión que se estudian a continuación. Todos los riesgos que se encuentran por encima de la línea de corte deben ser considerados. La columna etiquetada RSGR contiene una referencia que apunta hacia un plan de reducción, supervisión y gestión del riesgo desarrollado para todos los que se encuentran por encima de la línea de corte. La probabilidad de riesgo puede determinarse haciendo estimaciones individuales y desarrollando después un único valor de consenso. Aunque este enfoque es factible, se han desarrollado técnicas más sofisticadas para determinar la probabilidad de riesgo. Los controladores de riesgo pueden valorarse en una escala de probabilidad cualitativa que tiene los siguientes valores: imposible, improbable, probable y frecuente. Después puede asociarse una probabilidad matemática con cada valor cualitativo (p. ej: una probabilidad del 0.7 al 1.0 implica un riesgo muy probable). 
4.2.- Evaluación del impacto del riesgo Tres factores afectan a las consecuencias probables de un riesgo, si ocurre: su naturaleza, su alcance y cuando ocurre. La naturaleza del riesgo indica los problemas probables que aparecerán si ocurre. Por ejemplo, una interfaz externa mal definida para el hardware del cliente (un riesgo técnico) impedirá un diseño y pruebas tempranas y probablemente lleve a problemas de integración más adelante en el proyecto. El alcance de un riesgo combina la severidad (¿cómo de serio es el problema?) con su distribución general (¿qué proporción del proyecto se verá afectado y cuantos clientes se verán perjudicados?). Finalmente, la temporización de un riesgo considera cuándo y por cuánto tiempo se dejará sentir el impacto. En la mayoría de los casos, un jefe de proyecto prefiere las "malas noticias" cuanto antes, pero en algunos casos, cuanto más tarden, mejor. Volviendo una vez más al enfoque del análisis de riesgo propuesto por las Fuerzas Aéreas de Estados Unidos, se recomiendan los siguientes pasos para determinar las consecuencias generales de un riesgo: 1. Determinar la probabilidad media de que ocurra un valor para cada componente de riesgo.La proyección del riesgo y las técnicas de análisis descritas en las Secciones 5.4.1 y 5.4.2 se aplican reiteradamente a medida que progresa el proyecto de software. El equipo del proyecto debería volver a la tabla de riesgo a intervalos regulares, volver a evaluar cada riesgo para determinar qué nuevas circunstancias hayan podido cambiar su impacto o probabilidad. Como consecuencia de esta actividad, puede ser necesario añadir nuevos riesgos a la tabla, quitar algunos que ya no sean relevantes y cambiar la posición relativa de otros. 4.3.- Evaluación del riesgo En este punto del proceso de gestión del riesgo, hemos establecido un conjunto de ternas de la forma: [ri,li,xi] donde r es el riesgo, l la probabilidad del riesgo y x el impacto del riesgo. Durante 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 no se habían cubierto y se empieza a pensar las maneras de controlar y/o impedir los riesgos que sean más probables 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 riesgo estudiados anteriormente -rendimiento, coste, soporte y planificación temporal- 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 temporal (o cualquier combinación de los cuatro) que provoquen que se termine el proyecto. 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. En el contexto del análisis de riesgos del software, un nivel de referencia de riesgo tiene un solo punto, denominado punto de referencia o punto de ruptura, en el que la decisión de seguir con el proyecto o dejarlo (los problemas son demasiado graves) son igualmente aceptables. La figura representa esta situación gráficamente. Si una combinación de riesgos lleva a problemas que provocan excesos de coste y retrasos de la planificación temporal, habrá un nivel representado por la curva en la figura que (cuando se exceda) provocará la terminación del proyecto (la región sombreada). En el punto de referencia, las decisiones de seguir o abandonar son igualmente válidas. En realidad, el nivel de referencia puede raramente representarse como una línea nítida en el gráfico. En la mayoría de los casos es una región en la que hay áreas de incertidumbre (ej.: intentar predecir una decisión de gestión basándose en la combinación de valores de referencia es a menudo imposible). Por tanto, durante la evaluación del riesgo, se realizan los siguientes pasos: 1. Definir los niveles de referencia de riesgo para el proyecto.5.- 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 el riesgo.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. Por ejemplo, asuma que se ha detectado mucha movilidad de la plantilla como un riesgo del proyecto, n. Basándose en casos anteriores y en la intuición de gestión, la probabilidad, li, de mucha movilidad se estima en un 0.70 (70 por ciento, bastante alto) y el impacto, si está previsto que tenga un impacto crítico en el coste y planificación temporal del proyecto. Para reducir el riesgo, la gestión del proyecto debe desarrollar una estrategia para reducir la movilidad. Entre los pasos que se pueden tomar están estos: • Reunirse con la plantilla actual y determinar las causas de la movilidad (por ej.: malas condiciones de trabajo, salarios bajos, mercado laboral competitivo).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 de si el riesgo se está haciendo más o menos probable. En el caso de gran movilidad del personal, se pueden supervisar los siguientes factores: • Actitud general de los miembros del equipo basándose en las presiones del proyecto.Además de supervisar los factores apuntados anteriormente, el jefe del proyecto debería supervisar también la efectividad de los pasos de reducción del riesgo. Por ejemplo. un paso de reducción del riesgo apuntado anteriormente instaba a la definición de "estándares de documentación y mecanismos para asegurarse de que los documentos se cumplimenten puntualmente". Este es un mecanismo para asegurarse la continuidad, en caso de que un individuo crítico abandone el proyecto. El jefe del proyecto debería comprobar los documentos cuidadosamente para asegurarse de que son válidos y de que cada uno contiene la información necesaria en caso de que un miembro nuevo se viera obligado a unirse al proyecto. 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. Continuando con el ejemplo, suponga que el proyecto va muy retrasado y un número de personas anuncia que se va. Si se ha seguido la estrategia de reducción. tendremos reservas. 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 planificación temporal del proyecto) desde las funciones que tienen todo su personal, permitiendo a los recién llegados que deben unirse al equipo que vayan "cogiendo el ritmo". A los individuos que se van se les pide que dejen lo que estén haciendo y dediquen sus últimas semanas a "transferir sus conocimientos". Esto podría incluir la adquisición de conocimientos por medio de vídeos, el desarrollo de "documentos con comentarios" y/o reuniones con otros miembros del equipo que permanezcan en el proyecto. Es importante advertir que los pasos RSGR provocan aumentos del coste del proyecto. Por ejemplo, emplear tiempo en conseguir una reserva de cada técnico crítico cuesta dinero. 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. Si los procedimientos para evitar el riesgo de gran movilidad aumentan el coste y duración del proyecto aproximadamente en un 15 por ciento, pero el factor coste principal es la copia de seguridad (backup), el gestor puede decidir no implementar este paso. Por otra parte si los pasos para evitar el riesgo llevan a una proyección de un aumento de costes del 5 por ciento y de la duración en un 3 por ciento, la gestión probablemente lo haga. Para un proyecto grande se pueden identificar unos 30 o 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 el 80 por ciento del riesgo total de un proyecto (p. ej.: el 80 por ciento del potencial de fracaso del proyecto) se debe solamente al 20 por ciento 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 ciento. Por este motivo, algunos de los riesgos identificados, valorados y previstos pueden no pasar por el plan RSGR -no pertenecen al 20 por ciento crítico (los riesgos con la mayor prioridad del proyecto). 6.- Riesgos y peligros para la seguridad El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos después de haber desarrollado con éxito el software y de haberlo entregado al cliente. Estos riesgos están típicamente asociados con las consecuencias del fallo del software una vez en el mercado. Aunque la probabilidad de fallo de un sistema de alta ingeniería es pequeña, un defecto no detectado en un sistema de control y supervisión basados en ordenador podría provocar unas pérdidas económicas enormes, o peor, daños físicos significativos o pérdida de vidas humanas. Pero el coste y beneficios funcionales del control y supervisión basados en computadora a rnenudo superan al riesgo. Hoy en día, se emplean regularmente hardware y software para el control de sistemas de seguridad crítica. Cuando se emplea software como parte del sistema de control, la complejidad puede aumentar del orden de una magnitud o más. Sutiles defectos de diseño inducidos por error humano -algo que puede descubrirse y eliminarse con controles convencionales basados en hardware- se convierten en mucho más difíciles de descubrir cuando se emplea software. La seguridad del software y el análisis del peligro son actividades para garantizar la calidad del software que se centra en la identificación y evaluación de peligros potenciales que pueden impactar al software negativamente y provocar que falle el sistema entero. Si se pueden identificar los peligros al principio del proceso de ingeniería del software, se pueden especificar características de diseño software que eliminen o controlen esos peligros potenciales. 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 jefe del proyecto como parte del Plan del Proyecto general. A continuación se expone un es;quema del Plan RSGR. I. Introducción 1. Alcance y propósito del documento.II. Tabla de riesgo del proyecto. 1. Descripción de todos los riesgos por encima de la línea de corte.
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 cuando un riesgo previsto ocurre de hecho;
(2) asegurarse de que los procedimientos para evitar el riesgo
definidos para el riesgo en cuestión se están
aplicando apropiadamente; y (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 de riesgos es
intentar determinar el "origen" (qué riesgos
ocasionaron tal problema) a lo largo de todo el proyecto. |
|
|
|
Página de apuntes de la asignatura Informática Aplicada a la Gestión Pública(GAP). Universidad de Murcia Correo electrónico: barzana@um.es |
|
|
| www.google.es |