Subido por Maria Elena Solórzano

Gestion-Riesgo

Anuncio
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
Descargar