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 Se dividen en Riesgos de negocio

categorías

Identifican Riesgos técnicos Están orientados

Potenciales problema Descubren

en presupuesto, A la administración,
calendarización, Potenciales problema contabilidad y
personal, recursos, en diseño, mercadotecnia del
participantes y su implementación, negocio software.
impacto sobre un interfaz, verificación y
proyecto de software. mantenimiento.
 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 Los riesgos del
proyecto alteran la negocio
calendarización del amenazan la
proyecto y propicia viabilidad del
que los costos Efectos de las
categorías de software, ponen
aumenten en peligro el
riesgos cuando se
vuelven reales proyecto o el
producto
 Riesgos del Software
Gestión de Riesgo

Ejemplos:

•El director no apoya el •El cliente no especifico •Se tienen ambigüedad

proyecto. bien las requisitos. en las especificaciones.
•Se diseño un software •Los equipos de trabajo •Perdida de la datos.
que nadie quiere. creados no son los •Problemas en la
•Perdida de adecuados. interfaz del usuario.
presupuesto o personal •Se excede el •Desconocimientos de
•Construcción de un presupuesto obtenido. tecnologías de punta.
producto que ventas no •No se cumple con las •Dudas o de la técnica
pude vender. fechas especuladas. utilizadas.
•Un producto que no •Falta de comunicación •Las técnicas utilizadas
encaja en la estrategia entre el personal. se encuentran en
comercial de la desuso.
compañía.
 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 •??????????? •Fecha de entrega

personal irreales.
•Mala comunicación •Falta de requisitos
con el cliente. documentados
•Disminución del •Pobre entorno de
esfuerzo del personal. 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 Controlar los riegos

posible. 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

•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
Riesgos amenazar el plan del proyecto?.
específicos •Un método para identificarlos es crear una lista de
del verificación de riesgos.
producto •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:

las consecuencias de los

La probabilidad de que problemas asociados con el
el riesgo sea real 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.

2. Delineado de las consecuencias Priorizar los

del riesgo. Riesgos para
4 pasos que el equipo
en la
proyección 3. Estimación del impacto del Finalidad: pueda asignar
riesgo en el proyecto y el los recursos
del riesgo,
producto. donde tengan el
realizados por el
planificador del mayor impacto.
proyecto,
otros gestores y 4. Tomar nota de la precisión
personal técnico
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 RSGR
La estimación del tamaño puede ser TP 60% 2
significativamente baja.
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 ED 80% 3
herramientas
Personal inexperto PE 30% 2
Elevada movilidad del personal PE 60% 2

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

Riesgos Categoría Probabilidad Impacto RSGR

Los riesgos ubicados
sobre la línea tendrán
una atención posterior y
todos deben gestionarse.

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 Indica los problemas que son probables si

ocurre.
¿cuán serio es? ¿cuánto del proyecto se
Ámbito afectará, o cuántos clientes resultarán
dañados?

Tiempo 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