Sie sind auf Seite 1von 53

UNIDAD III:

GESTION DEL RIESGO


2
El anlisis y la gestin del riesgo son una serie de
pasos que ayudan a un equipo de SW a
comprender y manejar la incertidumbre.

Un riesgo es un problema potencial que puede
ocurrir o no.

No olvide identificar, evaluar la probabilidad de
que ocurra, estimar el impacto y establecer un plan
de contingencia en caso de que el problema se
presente.

PREVENIR -> RIESGO
3
4
Las estrategias de riesgo reactivas se han
denominado humorsticamente "Escuela
de gestin del riesgo de Indiana Jones".
En las pelculas, Indiana Jones, cuando
se enfrentaba a una dificultad
insuperable, siempre deca "No te
preocupes, pensar en algo!". Nunca se
preocupaba de los problemas hasta que
ocurran, entonces reaccionaba como
un hroe.

4
ESTRATEGIAS DE RIESGO REACTIVAS
Y PROACTIVAS
5
En el mejor de los casos, la estrategia
reactiva supervisa el proyecto en
previsin de posibles riesgos. Los recursos
se ponen aparte, en caso de que
pudieran convertirse en problemas
reales. Pero lo ms frecuente es que el
equipo de software no haga nada
respecto a los riesgos hasta que algo va
mal.
5
ESTRATEGIAS DE RIESGO REACTIVAS
Y PROACTIVAS
Despus el equipo vuela para corregir
el problema rpidamente. Este es el
mtodo denominado a menudo "de
bomberos". Cuando falla, "la gestin
de crisis" entra en accin y el proyecto
se encuentra en peligro real.




6
ESTRATEGIAS DE RIESGO REACTIVAS
Y PROACTIVAS
Una estrategia considerablemente ms
inteligente para el control del riesgo es
ser proactivo. La estrategia proactiva
empieza mucho antes de que
comiencen los trabajos tcnicos. Se
identifican los riesgos potenciales, se
valoran su probabilidad y su impacto y
se establece una prioridad segn su
importancia,


7
ESTRATEGIAS DE RIESGO REACTIVAS
Y PROACTIVAS
Despus el equipo de software
establece un plan para controlar el
riesgo. El primer objetivo es evitar el
riesgo, poco comn no se pueden
evitar todos los riesgos, el equipo
trabaja para desarrollar un plan de
contingencia que le permita responder
de una manera eficaz y controlada.
8
ESTRATEGIAS DE RIESGO REACTIVAS
Y PROACTIVAS







RIESGOS DEL SOFTWARE
Aunque hay un considerable debate en torno a la
definicin propia para el riesgo de software, existe
un acuerdo general en que el riesgo siempre
involucra dos caractersticas:

Incertidumbre: el riesgo puede o no ocurrir, esto
es, no existen riesgos 100% probables.
Prdida: Si el riesgo se convierte en realidad,
ocurrirn consecuencias o prdidas indeseables.

Cuando se analizan los riesgos es importante
cuantificar el grado de incertidumbre y el grado
de perdida asociado con el riesgo,





9
10
11
12
13
14
15
16
17
18
19
20
Si la respuesta a alguna de estas preguntas
es negativa se deben instituir sin demora los
pasos de reduccin, supervisin y gestin. El
grado en el que el proyecto esta en riesgo es
directamente proporcional al numero de
respuestas negativas a estas preguntas.

21
Las Fuerzas Areas de Estados Unidos han
redactado un documento que contiene
excelentes directrices para identificar riesgos
software y evitarlos. El enfoque de las
Fuerzas Areas requiere que el gestor del
proyecto identifique los controladores del
riesgo que afectan a los componentes de
riesgo software (rendimiento, coste,
soporte y planificacin temporal).
22
COMPONENTES Y CONTROLADORES DEL
RIESGO
COMPONENTES Y CONTROLADORES DEL RIESGO
22 22
En el contexto de este estudio, los
componentes de riesgo se definen de la
siguiente manera:
23 23 23
Componentes
Categora

Desempeo

Soporte

Costo

Calendarizacin


Catastrfico

1 El fracaso en la satisfaccin de los requisitos
resultara en un fracaso de la misin.
El fracaso resulta en el aumento de costos y en
demoras en la calendarizacin con valores
esperados que superan 500K da.
2 Cierta reduccin en el
desempeo tcnico
SW que no responde o
no se puede soportar
Recortes financieros
significativos, probable
superacin del
presupuesto
COI inalcanzable


Critica

1 El fracaso para satisfacer los requisitos
resultara en un desempeo degradado del
sistema hasta un punto donde el xito de la
misin es cuestionable
El fracaso resulta en demoras operativas o
incrementos de costos con valor esperado de
100K a 500K dlares
2 Cierta reduccin en el
desempeo tcnico

Demoras menores en
las modificaciones del
SW
Cierto recorte de
recursos financieros,
posibles excesos
Posible deslizamiento
en el COI


Marginal

1 El fracaso para satisfacer los requisitos
resultara en degradacin de la misin
secundaria
Deslizamiento de costos, impactos o
calendarizacin recuperable con valor esperado
de 1K a 100K dlares
2 Mnima o pequea
reduccin en le
desempeo tcnico
Respuesta de soporte
de SW
Suficientes recursos
financieros
Calendarizacin
alcanzable y realistas

Despreciable
1 El fracaso al satisfacer los requisitos creara
inconvenientes o impactos no operativos
El error resulta en costo menor o impacto en la
calendarizacin con valores esperado de menos
de 1K dlares
2 Ninguna reduccin en
le desempeo tcnico
SW al que fcilmente
se le da soporte
Posible supervit
presupuestal
COI facialmente
alcanzable
Nota: 1- Consecuencia potencial de errores o fallas de software no detectados
2- Consecuencia potencial si el resultado deseado no se alcanza
Evaluacin del impacto
24 24
Riesgo Tipo Descripcin
Rotacin del personal Proyecto Personal con experiencia abandona el proyecto
antes de que finalice.
Cambio de gestin Proyecto Habr un cambio de gestin organizacional con
diferentes prioridades.
No disponibilidad de HW Proyecto El HW esencial para el proyecto no ser entregado a
tiempo.
Cambio de
requerimientos
Proyecto y
producto
Habr mas cambios en los requerimientos de lo
esperado
Retrasos en la
especificacin
Proyecto y
producto
Las especificaciones de las interfaces esenciales no
estarn a tiempo.
Subestimacin del
tamao
Proyecto y
producto
El tamao del proyecto se ha subestimado.
Bajo rendimiento de la
herramienta CASE
Producto Las herramientas CASE que ayudan al proyecto no
tienen el rendimiento esperado.
Cambio de tecnologa Negocio Un producto competitivo se pone en venta antes de
que el sistema se complete.
Competencia del
producto
Negocio La tecnologa fundamental sobre la que se construir
el sistema se sustituye por nueva tecnologa.
Ejemplo de Posibles Riesgos del SW genricos
INGENIERA DEL SOFTWARE, Ian Sommerville, 7ma ed, Pag: 96
25
Ejemplos de Tipos de Riesgo y Posibles Riegos
26
Ejemplos de Tipos de Riesgo y Posibles Riegos
27
28 28
EVALUACIN DEL RIESGO
GLOBAL DEL PROYECTO
Las siguientes preguntas se basan en los
datos de riesgo obtenidos al entrevistar, en
diferentes partes del mundo a gestores de
proyecto de software experimentados
[KEI98]. Las preguntas estn ordenadas
segn su importancia relativa en el xito de
un proyecto.

29 29
EVALUACIN DEL RIESGO
GLOBAL DEL PROYECTO
Los altos ejecutivos de software y del cliente se han comprometidos
formalmente para apoyar el proyecto?
Los usuarios finales estn comprometidos con el proyecto y el
sistema/producto que se construir?
Los requisitos los han entendido completamente el equipo de ingeniera de
software y sus clientes?
Los clientes estuvieron completamente involucrados en la definicin de los
requisitos?
Los usuarios finales tienen expectativas realistas?
El mbito del proyecto es estable?
El equipo de ingeniera del software tiene la mezcla correcta de habilidades?
Los requisitos del proyecto son estables?
El equipo del proyecto tiene experiencia con la tecnologa que se
implementar?
El nmero de personas en el equipo de proyecto es adecuado para realizar el
trabajo?
Todos los votantes del cliente/usuario estn de acuerdo en la importancia del
proyecto y en los requisitos para el sistema/producto que se construir?

30 30
EVALUACIN DEL RIESGO
GLOBAL DEL PROYECTO
Si la respuesta a alguna de estas preguntas
es negativa se deben instituir sin demora los
pasos de reduccin, supervisin y gestin. El
grado en el que el proyecto esta en riesgo es
directamente proporcional al numero de
respuestas negativas a estas preguntas.

31 31
COMPONENTES Y CONTROLADORES
DEL RIESGO
Las Fuerzas Areas de Estados Unidos han
redactado un documento que contiene
excelentes directrices para identificar riesgos
software y evitarlos. El enfoque de las
Fuerzas Areas requiere que el gestor del
proyecto identifique los controladores del
riesgo que afectan a los componentes de
riesgo software (rendimiento, coste,
soporte y planificacin temporal).
32 32
COMPONENTES Y CONTROLADORES
DEL RIESGO
En el contexto de este estudio, los
componentes de riesgo se definen de la
siguiente manera:
33 33
COMPONENTES Y CONTROLADORES
DEL RIESGO
El impacto de cada controlador de riesgo en el
componente de riesgo se divide en cuatro
categoras de impacto -despreciable,
marginal, crtico y catastrfico. La siguiente
figura indica las consecuencias potenciales de
errores (filas etiquetadas con 1) o la
imposibilidad de conseguir el producto
deseado (filas etiquetadas con 2) La categora
de impacto es elegida basndose en la
caracterizacin que mejor encaja con la
descripcin de la tabla.
34 34
El gestor debe identificar los controladores del
riesgo que afectan los componentes de riesgo del
SW como:
o Riesgo de desempeo: Grado de incertidumbre de
que el producto satisfaga los requisitos y se ajuste al
uso que se pretende darle.
o Riesgo de costo: Grado de incertidumbre de que se
mantenga el presupuesto del proyecto.
o Riesgo de soporte: Grado de incertidumbre de que el
SW resultante ser fcil de corregir, adaptar y
mejorar.
o Riesgo de calendarizacin: Grado de incertidumbre
de que se mantenga la calendarizacin del
proyecto y de que el producto se entregue a tiempo.
34
COMPONENTES Y CONTROLADORES
DEL RIESGO
35
36
La finalidad de estos pasos es
considerar los riesgos en tal
forma que conduzcan al
establecimiento de
prioridades.
37
38
39
40
41
42 42
42
Desarrollo de tabla de riesgos
La tabla de riesgos ofrece al gestor de un proyecto una tcnica
simple para la proyeccin de riesgos.
Riegos Categora Probabilidad Impacto RSGR
La estimacin del tamao puede ser
significativamente baja.
Mayor numero de usuarios de los previstos.
Menos reutilizacin que la prevista.
Los usuarios finales se resisten al sistema.
La fecha limite de entrega estar muy
ajustada.
Prdida de fondos.
El cliente cambiara requisitos.
La tecnologa no satisfar las expectativas.
Falta de entrenamiento acerca de las
herramientas.
Personal inexperto.
Elevada movilidad del personal.

..
TP

TP
TP
CO
CO

CL
TP
RT
ED

PE
PE
60 %

30 %
70 %
40 %
50 %

40 %
80 %
30 %
80 %

30 %
60 %|
2

3
2
3
2

1
2
1
3

2
2
Lnea de Corte implica que solo los riesgos
ubicados sobre la lnea tendrn una atencin
posterior
43
Evaluacin del impacto de riesgo
Tres factores afectan las consecuencias que son
probables si un riesgo ocurre:
Naturaleza (indica los problemas que son probables si ocurre)
mbito (combinacin de la severidad con su distribucin
global)
Tiempo (consideracin de cundo y durante qu periodo se
sentir el impacto)
Cmo se valoran las consecuencias de un riesgo?
1. Determinar el valor promedio de la probabilidad de que
ocurra para cada componente de riesgo.
2. Empleando los Componentes y controladores del riesgo,
determinar el impacto para cada componente, con base
en los criterios mostrados.
3. Completar la tabla de riesgos y analizar los resultados.
44
Cundo desistir y finalizar el proyecto
o Se debe definir un punto de referencia.
o Se debe marcar la relacin entre cada factor
de riesgo enumerado y el punto de
referencia.
o Definir el rea de incertidumbre, donde ser
tan vlido continuar como interrumpir el
trabajo.
o Predecir cmo la combinacin de riesgos
afectar a los niveles de referencia.

44
45
EXPOSICIN AL RIESGO global ER, donde P es la
probabilidad de que ocurra un riesgo y C el costo al
proyecto en caso de que ocurra el riesgo.

ER = P * C


Como define un equipo de SW un riesgo
Identificacin del riesgo: Solo 70% de los componentes de SW
calendarizados para reutilizacin se integra en la aplicacin.
Probabilidad de riesgo: 80%
Impacto del riesgo: Se planificaron 60 componentes de SW reutilizables.
Si slo se puede emplear el 70%, 18 componentes tendrn que desarrollarse
desde cero. Puesto que el componente promedio es 100 LDC y los datos
locales indican que el costo de ingeniera de SW para cada uno es de
14000USD, el costo(impacto) global del desarrollo de los componentes
sera de 18 x 100 x 14 = 25200USD.
Exposicin al riesgo: ER = 0.80 x 25200 dlares ~ 20 200 dlares.
46
Refinamiento del riesgo
Durante las primeras etapas se generan descripciones
de riesgos muy superficiales y a medida que se
avanza en el proyecto se los va detallando de mejor
manera.
Una buena forma de describir un riesgo es:
Representar el riesgo en formato de Condicin-Transicin
Consecuencia.
Dado que <condicin> entonces existe una
preocupacin de que (posiblemente) <consecuencia>

Dado que los componentes de SW reutilizables deben ajustarse con
estndares de diseo especficos y como algunos no lo hace, entonces
existe una preocupacin de que (posiblemente) slo 70% de los
mdulos reutilizables planeados pueden en realidad integrarse al
sistema que se construir, lo que resulta en la necesidad de ingeniera
personalizada para el restante 30% de componentes.
46
47
Reduccin, supervisin y gestin del
riesgo
Una estrategia para luchar con el riesgo debe
considerar:
Evitar el riesgo
Supervisar el riesgo
Gestionar el riesgo y los planes de contingencia.

Es un pecado capital dejar pasar el riesgo por alto
luego de haberlo identificado y no tratarlo
47
48
RSGR [Reduciendo el riesgo]
El gestor del proyecto debe recurrir una estrategia para
reducir la movilidad.
Los posibles pasos que se puede seguir son:
Reunirse con el personal actual para determinar las causas de
la movilidad
Reducir aquellas causas que se controlan antes de que
comience el proyecto.
Una vez iniciado el proyecto suponer que la movilidad ocurrir
y entonces desarrollar tcnicas que aseguren la continuidad
cuando la gente se aleje.
Organizar equipos de proyectos de modo que la informacin
acerca de cada actividad de desarrollo se disperse con
amplitud.
Definir estndares de documentacin y establecer
mecanismos que aseguren que los documentos se desarrollen
en una forma oportuna.
Llevar a cabo revisiones por pares de todo el trabajo.
Asignar un miembro de respaldo para las actividades criticas.
48
49
RSGR [1 paso adelante]
La gestin del riesgo y los planes de contingencia suponen que
los esfuerzos de reduccin han fracasado y que el riesgo se ha
vuelto una realidad.
No hay problema si se hizo las actividades de la reduccin
Hay el personal de respaldo
El gestor puede reenfocar los recursos hacia aquellas funciones
completamente estructuradas.
Los individuos a salir se les pide que traspasen el conocimiento
Los pasos de reduccin, supervisin y gestin del riesgo generan
costos adicionales en el proyecto.

El riesgo no est limitado al proyecto de SW. Los riesgos pueden
ocurrir despus de que el SW se ha desarrollado exitosamente y
entregado al cliente. Estos riesgos estn tpicamente asociados
con las consecuencias de la falla de SW en el campo.
49
50
El plan RSGR
El plan de RSGR documenta todo el trabajo realizado como
parte del anlisis del riesgo y el gestor del proyecto lo
emplea como parte del plan global del proyecto.
Algunos equipos de SW no elaboran un documento RSGR
formal. En su lugar cada riesgo se documenta
individualmente mediante una hoja de informacin del
riesgo.
Una vez documentado el plan de RSGR y que el proyecto
ha comenzado, se inician los pasos de reduccin y
supervisin del riesgo.
La reduccin del riesgo es una actividad encaminada a
evitar el problema.
La supervisin del riesgo es una actividad de seguimiento
del proyecto con tres objetivos:
1. Valorar si los riesgos predichos de hecho ocurren
2. Asegurar que los pasos para evitar el riesgo definidos para ste se estn
aplicando con propiedad
3. Recopilar informacin que pueda usarse en futuros anlisis de riesgo.
50
51
Hoja de informacin del riesgo
ID de riesgo: PO2 4-32 Fecha: 9/5/04 Prob: 80% Impacto: alto
Descripcin:
Solo el 70% de los componentes del SW calendarizados para reutilizacin de hecho se integraran a la aplicacin. La
funcionalidad restante tendr que desarrollarse de manera personalizada.
Refinamiento/contexto:
Subcomisin 1: Ciertos componentes de reutilizacin fueron desarrollados por un tercer participante sin conocimiento
de los estndares de diseo interno.
Subcomisin 2: El estndar de diseo para los componentes de interfaces no ha sido solidificado y tal vez no
concuerdan con ciertos componentes reutilizables existentes.
Subcomisin 3: Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno
destino.
Reduccin/supervisin:
1. Contactar con el tercer participante para determinar la concordancia con los estndares de diseo.
2. Presionar para completar los estndares de interfaz; considerar la estructura del componente cuando se decida
acerca del protocolo de la interfaz.
3. Verificar para determinar el numero de componentes en la categora 3 de subcomisin; verificar para determinar
si se puede adquirir el soporte para el lenguaje.
Gestin/plan de contingencia/disparador:
La ER se calcula en $ 20 200. Asignar esta cantidad dentro del costo de contingencia del proyecto.
Desarrollar una calendarizacin revisada suponiendo que se tendrn que construir 18 componentes adicionales;
asignar el personal en concordancia,
Disparador: Los pasos de reduccin son improductivos al 1/7/04.
Estado Actual:
12/5/04: Inicia los pasos de reduccin
Elabor: D. Gagne Asignado a : B. Laster
52
Conclusiones
La gestin del riesgo es crucial en el proyecto de
SW.
El gestionar los riesgos implica identificar todos los
factores que pueden llevar al proyecto al fracaso.
Elaborar los planes de RSGR.
El plan RSGR debe revisarse conforme el proyecto
avanza.
Recordar que los riesgos se relacionan con los
acontecimientos futuros.
52
53

Bibliografa
INGENIERA DEL SOFTWARE, Ian Sommerville, 7ma
ed
INGENIERIA DEL SOFTWARE, UN ENFOQUE
PRACTICO, Roger Pressman, 6ta ed.
53

Das könnte Ihnen auch gefallen