gestion del riesgo

PROCESOS DE INGENIERÍA DE SOFTWAREDocente: Ing. Armando Cabrera Alumnos: Luis Enrique Castillo

Luis Eduardo Cuenca Mayo/2008

Universidad Técnica Particular de Loja

PreviewLos objetivos de la

gestión de riesgo son identificar, controlar y eliminar las fuentes de riesgo antes de que empiecen a afectar el cumplimiento de los objetivos del proyecto

Procesos de Ingeniería de Software - ECC 2

FUENTE: http://tinyurl.com/4u4owq

!!!!RIESGO¡¡¡¡


Estrategias de riesgo reactivas y proactivasReactivo

El equipo de SW no hace nada hasta que sucede algo mal.

Modo Bombero → Tratar de remediar el problema al apuro ¿¿Y si falla el bombero ??? R: Aparece la Gestión de Crisis para tomar el control, y es cuando el

proyecto esta en verdadero peligro

Ser proactivoInicia antes del trabajo técnico.Identificar los riesgos potenciales, valorando su probabilidad e

impactoSe clasifican según su importanciaEstablecer un plan.


Riesgos del SoftwareLos riesgos involucran dos características:

Incertidumbre: Se desconoce si puede suceder.Pérdida: El riesgo se convierte en realidad.

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

Tipos de riesgos que se encuentran:1.Riesgos del Proyecto (Amenazan el plan del proyecto)

2.Riesgos Técnicos (Amenaza la calidad y actualidad del SW que se producirá)

3.Riesgos de Negocios (Amenaza la viabilidad del SW que se construirá)



Riesgo Tipo Descripción

Rotación del personal Proyecto Personal con experiencia abandona el proyecto antes de que finalice

Cambio de gestión Proyecto Habrá un cambio de gestión 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 especificación

Proyecto y producto

Las especificaciones de las interfaces esenciales no estarán a tiempo

Subestimación del tamaño

Proyecto y producto

El tamaño 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 tecnología Negocio Un producto competitivo se pone en venta antes de que el sistema se complete

Competencia del producto

Negocio La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología

Posibles Riesgos del SW genéricos

INGENIERÍA DEL SOFTWARE, Ian Sommerville, 7ma ed, Pag: 96


Etapas:1.Identificación de riesgos: Identificar los posibles riesgos para el proyecto, el producto y los negocios2.Análisis de riesgos: Valorar las probabilidades y consecuencias de estos riesgos.3.Planeación de riesgos: Crear planes para abordar los riesgos, ya sea para evitarlos i minimizar sus efectos en el proyecto4.Supervisión de riesgos: Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos esté disponible

INGENIERÍA DEL SOFTWARE, Ian Sommerville, 7ma ed, Pag: 97

Identificación de riesgosIdentificar los riesgos es una tarea sistemática

orientándose a especificar las amenazas al plan del proyecto.Al identificarlos se puede estar un paso adelante.

Dos tipos de riesgos para (R. Proyectos, R. Técnicos y R. Negocios)

Riesgos Genéricos: Amenaza potencial para todo el proyecto de SW

Riesgos específicos del producto: Se los puede identificar con un buen conocimiento de tecnología, el personal y el entorno especifico del SW. ¿¿¿Como???

Examinando el plan del proyecto y la declaración del ámbito del SW. “Qué características especiales de este producto podrían

amenazar el plan del proyecto”Procesos de Ingeniería de Software - ECC 9

Tipos de riesgos que pueden aparecerRiesgos de tecnologíaRiesgos de personalRiesgos organizacionalesRiesgos de herramientasRiesgos de requerimientosRiesgos de estimación


El método para identificar es crear una lista de verificación (Check list) de riesgos.

Sub categorías de riesgos:Tamaño del Producto: Riesgos asociados con el tamaño global del

SW.Impacto en el Negocio: Asociados con las restricciones que impone la

gerencia o el mercado.

Características del cliente: Asociados con la satisfacción del cliente.

Definición del proceso: Riesgos con el grado en que se ha definido el proceso

Entorno de desarrollo: Asociado con disponibilidad y calidad de las herramientas.

Tecnología que construir: Asociado con la complejidad del sistema que se construirá.

Tamaño y experiencia de la plantilla de personal: Relacionado con la experiencia técnica del personal.


Identificación de riesgos (Cont…)

1. ¿Los altos ejecutivos de SW y del cliente se han comprometido formalmente para apoyar el proyecto?

2. ¿Los usuarios finales están comprometidos con el proyecto y el sistema/producto que se construirá?

3. ¿Los requisitos los han entendido completamente el equipo de ingeniería de SW y sus clientes?

4. ¿Los clientes estuvieron completamente involucrados en la definición de los requisitos?

5. ¿Los usuarios finales tienen expectativas realistas?6. ¿El ámbito del proyecto es estable?7. ¿El equipo de ingeniería del SW tiene la mezcla correcta de habilidades?8. ¿Los requisitos del proyecto son estables?9. ¿El equipo del proyecto tiene experiencia con la tecnología que se

implementara?10. ¿El numero de personas en el equipo de proyecto es adecuado para

realizar el trabajo?11. ¿Todos los votantes del cliente/usuario están de acuerdo en la

importancia del proyecto y en los requisitos para el sistema/producto que se construirá?


Identificación de riesgos (Cont…)Evaluación del riesgo

Componentes y controladores del riesgo

El gestor debe identificar los controladores del riesgo que afectan los componentes de riesgo del SW como:Riesgo de desempeño: Grado de incertidumbre de

que el producto satisfaga los requisitos y se ajuste y se ajuste al uso que se pretende darle.

Riesgo de costo: Grado de incertidumbre de que se mantenga el presupuesto del proyecto.

Riesgo de soporte: Grado de incertidumbre de que el SW resultante será fácil de corregir, adaptar y mejorar.

Riesgo de calendarización: Grado de incertidumbre de que se mantenga la calendarización del proyecto y de que el producto se entregue a tiempo.


Identificación de riesgos (Cont…)


Componentes Categoría

Desempeño Soporte Costo Calendarización

Catastrófico

1 El fracaso en la satisfacción de los requisitos resultaría en un fracaso de la misión.

El fracaso resulta en el aumento de costos y en demoras en la calendarización con valores esperados que superan 500K día.

2 Cierta reducción en el desempeño técnico

SW que no responde o no se puede soportar

Recortes financieros significativos, probable superación del presupuesto

COI inalcanzable

Critica

1 El fracaso para satisfacer los requisitos resultaría en un desempeño degradado del sistema hasta un punto donde el éxito de la misión es cuestionable

El fracaso resulta en demoras operativas o incrementos de costos con valor esperado de 100K a 500K dólares

2 Cierta reducción en el desempeño técnico

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 resultaría en degradación de la misión secundaria

Deslizamiento de costos, impactos o calendarización recuperable con valor esperado de 1K a 100K dólares

2 Mínima o pequeña reducción en le desempeño técnico

Respuesta de soporte de SW

Suficientes recursos financieros

Calendarización alcanzable y realistas

Despreciable

1 El fracaso al satisfacer los requisitos crearía inconvenientes o impactos no operativos

El error resulta en costo menor o impacto en la calendarización con valores esperado de menos de 1K dólares

2 Ninguna reducción en le desempeño técnico

SW al que fácilmente se le da soporte

Posible superávit presupuestal

COI facialmente alcanzable

INGENIERÍA DEL SOFTWARE, UN ENFOQUE PRACTICO, Roger Pressman, 6ta ed., PAG: 753

Proyección del Riesgo ó Estimación del RiesgoIntenta clasificar el riesgo de dos formas:

La posibilidad que el riesgo sea real Las consecuencias de los problemas asociados con el

riesgo en caso de que ocurra.El planificador del proyecto con los gestores y personal

técnico, realizan 4 pasos en la proyección del riesgo.1.Establecimiento de una escala que refleje la posibilidad

percibida de un riesgo.2.Delineado de las consecuencias del riesgo.3.Estimación del impacto del riesgo en el proyecto y el

producto.4.Tomar nota de la precisión global de la proyección del

riesgo de modo que no haya malas interpretaciones.

“La finalidad de estos pasos es considerar los riesgos en tal forma que conduzcan al establecimiento de

prioridades”.Procesos de Ingeniería de Software - ECC 15

Desarrollo de tabla de riesgosLa tabla de riesgos ofrece al gestor de un proyecto una

técnica simple para la proyección de riesgos.


Riegos Categoría

Probabilidad Impacto RSGR

La estimación del tamaño puede ser significativamente baja.Mayor numero de usuarios de los previstos.Menos reutilización que la prevista.Los usuarios finales se resisten al sistema.La fecha limite de entrega estará muy ajustada.Pérdida de fondos.El cliente cambiara requisitos.La tecnología no satisfará las expectativas.Falta de entrenamiento acerca de las herramientas.Personal inexperto.Elevada movilidad del personal.

………..

TP

TPTPCOCO

CLTPRTED

PEPE

60 %

30 %70%40 %50 %

40 %80 %30 %80 %

30 %60 %|

2

3232

1213

22

INGENIERÍA DEL SOFTWARE, UN ENFOQUE PRACTICO, Roger Pressman, 6ta ed.: PAG: 754

Valores de

impacto:

1: catastrófico

2: crítico

3: marginal

4: despreciable

Línea de Corte implica que solo los riesgos ubicados sobre la línea tendrán

una atención posterior

Evaluación del impacto de riesgo3 factores afectan las consecuencias que son

probables si un riesgo ocurre:Naturaleza (indica los problemas que son probables si ocurre)

Ámbito (combinación de la severidad con su distribución global)

Tiempo (consideración de cuándo y durante qué periodo se sentirá el impacto)

¿Cómo 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


Cuándo desistir y finalizar el proyecto

Se debe definir un punto de referenciaSe debe marcar la relación entre cada factor

de riesgo enumerado y el punto de referenciaDefinir el área de incertidumbre, donde será

tan válido continuar como interrumpir el trabajo

Predecir cómo la combinación de riesgos afectará a los niveles de referencia


ER = P x C

EXPOSICIÓN AL RIESGOEXPOSICIÓN 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.


Como define un equipo de SW un riesgoIdentificación del riesgo: Solo 70% de los componentes de SW calendarizados para reutilización se integra en la aplicación.Probabilidad de riesgo: 80%Impacto del riesgo: Se planificaron 60 componentes de SW reutilizables. Si sólo se puede emplear el 70%, 18 componentes tendrán que desarrollarse desde cero. Puesto que el componente promedio es 100 LDC y los datos locales indican que el costo de ingeniería de SW para cada uno es de 14000USD, el costo(impacto) global del desarrollo de los componentes sería de 18 x 100 x 14 = 25200USD.Exposición al riesgo: ER = 0.80 x 25200 dólares ~ 20 200 dólares.

Refinamiento del riesgoDurante 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 Condición-Transición–

Consecuencia. Dado que <condición> entonces existe una

preocupación de que (posiblemente) <consecuencia>

Dado que los componentes de SW reutilizables deben ajustarse con estándares de diseño específicos y como algunos no lo hace, entonces existe una preocupación de que (posiblemente) sólo 70% de los módulos reutilizables planeados pueden en realidad integrarse al sistema que se construirá, lo que resulta en la necesidad de ingeniería personalizada para el restante 30% de componentes.


Reducción, supervisión y gestión del riesgo

Una estrategia para luchar con el riesgo debe considerar:Evitar el riesgoEvitar el riesgoSupervisar el riesgoSupervisar el riesgoGestionar el riesgo y los planes de Gestionar el riesgo y los planes de

contingenciacontingencia..

Es un pecado capital dejar pasar el riesgo por alto luego de haberlo identificado y no tratarlo


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 técnicas que aseguren la continuidad cuando la gente se aleje.

Organizar equipos de proyectos de modo que la información acerca de cada actividad de desarrollo se disperse con amplitud.

Definir estándares de documentación 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. Procesos de Ingeniería de Software - ECC 22

RSGR [1 paso adelante]

La gestión del riesgo y los planes de contingencia suponen que los esfuerzos de reducción han fracasado y que el riesgo se ha vuelto una realidad.No hay problema si se hizo las actividades de la reducción

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 reducción, supervisión y gestión del riesgo generan costos adicionales en el proyecto.

El riesgo no está limitado al proyecto de SW. Los riesgos pueden ocurrir después de que el SW se ha

desarrollado exitosamente y entregado al cliente. Estos riesgos están típicamente asociados con las

consecuencias de la falla de SW en el campo.Procesos de Ingeniería de Software - ECC 23

El plan RSGREl plan de RSGR documenta todo el trabajo realizado como

parte del análisis 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 información del riesgo.

Una vez documentado el plan de RSGR y que el proyecto ha comenzado, se inician los pasos de reducción y supervisión del riesgo.

La reducción del riesgo es una actividad encaminada a evitar el problema.

La supervisión del riesgo es una actividad de seguimiento del proyecto con tres objetivos:1. Valorar si los riesgos predichos de hecho ocurren2. Asegurar que los pasos para evitar el riesgo definidos para

éste se están aplicando con propiedad3. Recopilar información que pueda usarse en futuros análisis de

riesgo.Procesos de Ingeniería de Software - ECC 24


Hoja de información del riesgoID de riesgo: PO2 – 4-32 Fecha: 9/5/04 Prob: 80% Impacto: alto

Descripción:Solo el 70% de los componentes del SW calendarizados para reutilización de hecho se integraran a la aplicación. La funcionalidad restante tendrá que desarrollarse de manera personalizada.

Refinamiento/contexto:Subcomisión 1: Ciertos componentes de reutilización fueron desarrollados por un tercer participante sin conocimiento de los estándares de diseño interno.Subcomisión 2: El estándar de diseño para los componentes de interfaces no ha sido solidificado y tal vez no concuerdan con ciertos componentes reutilizables existentes.Subcomisión 3: Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino.

Reducción/supervisión:1.Contactar con el tercer participante para determinar la concordancia con los estándares de diseño.2.Presionar para completar los estándares 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 categoría 3 de subcomisión; verificar para determinar si se puede adquirir el soporte para el lenguaje.

Gestión/plan de contingencia/disparador:La ER se calcula en $ 20 200. Asignar esta cantidad dentro del costo de contingencia del proyecto. Desarrollar una calendarización revisada suponiendo que se tendrán que construir 18 componentes adicionales; asignar el personal en concordancia,Disparador: Los pasos de reducción son improductivos al 1/7/04.

Estado Actual:12/5/04: Inicia los pasos de reducción

Elaboró: D. Gagne Asignado a : B. Laster

INGENIERÍA DEL SOFTWARE, UN ENFOQUE PRACTICO, Roger Pressman, 6ta ed. PAG: 762

ConclusionesLa gestión 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 RSGREl plan RSGR debe revisarse conforme el

proyecto avanzaRecordar que los riesgos se relacionan con

los acontecimientos futuros.Procesos de Ingeniería de Software - ECC 26

BibliografíaINGENIERÍA DEL SOFTWARE, Ian

Sommerville, 7ma edINGENIERIA DEL SOFTWARE, UN

ENFOQUE PRACTICO, Roger Pressman, 6ta ed.


Luis Enrique CastilloE-mail:

[email protected]:

http://lecastillox.blogspot.com Luis Eduardo Cuenca

E-mail: [email protected]


gestion del riesgo

Education