Unidad III Gestion Del Riesgo 2013

UNIDAD III: GESTION DEL RIESGO

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


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


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


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


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

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

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


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


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


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


En el contexto de este estudio, los

componentes de riesgo se definen de la

siguiente manera:

33 33


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


36

La finalidad de estos pasos es considerar los riesgos en tal

forma que conduzcan al

establecimiento de

prioridades.

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.

oDefinir 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 entonces existe una preocupacin de que (posiblemente)

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

Unidad III Gestion Del Riesgo 2013

Documents

Transcript of Unidad III Gestion Del Riesgo 2013