ANÁLISIS Y GESTIÓN DEL RIESGO

AGENDA

1. INTRODUCCIÓN

2. RIESGO DEL SOFTWARE

3. IDENTIFICACIÓN DEL RIESGO

4. ANÁLISIS DEL RIESGO

5. PLANIFICACIÓN DEL RIESGO

6. SUPERVISIÓN DEL RIESGO

7. EL PLAN RSGR

1. INTRODUCCIÓN

Definición de riesgo:

Es un problema potencial – puede o no ocurrir.

El riesgo afecta futuros acontecimientos - ¿qué riesgos podrían hacer que nuestro proyecto
fracasara?

El riesgo implica cambio. ¿Cómo afectarán los cambios en los requisitos del cliente, en las
tecnologías de desarrollo, al cumplimiento de la planificación y al éxito en general?

El riesgo nos enfrenta a elecciones. ¿Qué métodos y herramientas deberíamos emplear, cuánta
gente debería estar implicada, cuánta importancia hay que darle a la calidad?

Análisis y gestión del riesgo:

¿Qué es?
Una serie de pasos que ayudan al equipo del software a comprender y gestionar la
incertidumbre.

¿Quién lo hace?
Todos los que están involucrados en el proceso del software – gestores, ingenieros y clientes.

¿Por qué es importante?

El SW es una empresa difícil. Muchas cosas pueden ir mal y a menudo salen mal. Estos
problemas pueden tener un impacto significativo en la fecha de entrega o en el presupuesto.
¿Cuál es el producto obtenido?
Se realiza un Plan de Reducción, Supervisión y Gestión del Riesgo (RSGR) o un informe de riesgos.

¿Cómo podemos estar seguros de que lo hemos hecho correctamente?

El RSGR debe ser revisado mientras el proyecto se realiza para asegurar que los riesgos están
siendo controlados. Los planes de contingencia deben ser realistas.

RIESGO DEL SOFTWARE

Características del riesgo de SW

Incertidumbre: Puede o no ocurrir, no hay riesgos del 100% de probabilidad.

Pérdida: Si el riesgo ocurre, hay pérdidas.

IDENTIFICACIÓN DEL RIESGO

Es un intento sistemático para especificar las amenazas al plan del proyecto.

Hay dos tipos de riesgo para cada categoría de riesgo de SW (proyecto, producto y negocio).

Riesgos genéricos: Amenaza potencial para todos los proyectos de SW.

Riesgos específicos: De la tecnología, el personal y el entorno específico del proyecto en cuestión.

3. IDENTIFICACIÓN DEL RIESGO

 Nos basamos en una lista de comprobación de elementos de riesgo. Es un

subconjunto de riesgos conocidos y predecibles de las siguientes categorías:

 Tamaño del producto. Tamaño del SW a construir.

Ejemplos:

• ¿Tamaño estimado del producto en LDC o FP?

• ¿Grado de seguridad en la estimación del tamaño?

• ¿Tamaño estimado del producto en número de programas,

archivos y transacciones?

 Impacto en el negocio. Limitaciones impuestas por la gestión o

por el mercado.

• ¿Efecto de este producto en los ingresos de la compañía?

• ¿Sofisticación del usuario final?

• ¿Limitaciones gubernamentales en la construcción del

producto?
3. IDENTIFICACIÓN DEL RIESGO

 Nos basamos en una lista de comprobación de elementos de riesgo.

 Características del cliente. Sofisticación del cliente.

• ¿Hemos trabajado con el cliente anteriormente?

• ¿Está dispuesto el cliente a participar en las revisiones?

• ¿Entiende el cliente el proceso del software?

 Definición del proceso. Grado de uso de metodologías de la

organización.

• ¿Ha desarrollado su organización una descripción escrita

del proceso del software a emplear en este proyecto?

• ¿Se llevan a cabo regularmente revisiones técnicas

formales de las especificaciones de requisitos, diseño y
código?

3. IDENTIFICACIÓN DEL RIESGO

 Nos basamos en una lista de comprobación de elementos de riesgo.

 Entorno de desarrollo. Disponibilidad y calidad de herramientas

de desarrollo de software.

 ¿Tenemos disponible una herramienta de gestión de

proyectos de software?

 ¿Existen herramientas de análisis y diseño disponibles?

 ¿Proporcionan las herramientas de análisis y diseño,

métodos apropiados para el producto a construir?

 Tecnología a construir. Complejidad del sistema a construir.

 ¿Es nueva para su organización la tecnología a construir?

 ¿Demandan los requisitos del cliente la creación de

nuevos algoritmos o tecnología de entrada o salida?

 ¿El software interactúa con hardware nuevo o no

probado?
 3. IDENTIFICACIÓN DEL RIESGO

 Nos basamos en una lista de comprobación de elementos de riesgo.

 Tamaño y experiencia de la plantilla. Experiencia técnica y

documentación anterior de los ingenieros de SW que van a realizar
el trabajo.

 ¿Disponemos de la mejor gente?

 ¿Tiene el personal todos los conocimientos adecuados?

 ¿Ha recibido el personal la formación adecuada?

3. IDENTIFICACIÓN DEL RIESGO

 Luego, en un grupo, se utiliza un enfoque de tormenta de ideas para responder a

las cuestiones de las listas de comprobación de elementos de riesgo.

 Tambien se usa la experiencia de proyectos anteriores.

3. IDENTIFICACIÓN DEL RIESGO

• Factores principales de daño o cancelación de Proyectos de software (Fuente:

Standish Group, “The Chaos Report”, 2003)

Factores de Daño o cancelación %

Requerimientos incompletos 13.1

Deficiencia en el involucramiento del usuario 12.4

Deficiencia de recursos 10.6

Expectativas no realistas 9.9

Deficiencia en soporte ejecutivo 9.3

Cambios en los requerimientos y especificaciones 8.7

Deficiencia en la planeación 8.1

Ya no se necesita más 7.5

Deficiencia en administración de TI 6.2

Desconocimiento en tecnología 4.3

Otros 9.9
4. ANÁLISIS DEL RIESGO

• Estimación del riesgo:

1. Establecer una escala que refleje la probabilidad percibida del riesgo;

cualitativa y/o cuantitativa. Por ejemplo:
 • <10%  muy bajo

• 10-25%  bajo

• 25-50% moderado

• 50-75%  alto

• >75%  muy alto

2. Estimar la probabilidad.
Consejos:

• Técnica Delphi: Cada quien hace una estimación individual. Luego

se discute el origen de cada estimación, hasta hacer converger las
estimaciones.

• Utilizar <<calibración mediante adjetivos>>. Definir un valor

cualitativo y luego establecer un valor cuantitativo.

4. ANÁLISIS DEL RIESGO

• Estimación del riesgo:

3. Estimar la magnitud de la pérdida.

Cuantitativamente, la pérdida puede ser medida en unidades de tiempo o
de costo.

 Para determinar la magnitud en tiempo se recurre a la experiencia

o se toma la medida de algo pequeño y se combina para hallar la
magnitud total (por ejemplo, para LCDs).

 Para determinar la magnitud en costo: Si es código, se estima

cuántas LDC o FP se requieren, se averigua el valor promedio de
cada una y se multiplica.
PLANIFICACIÓN DEL RIESGO

 Se establece un plan de gestión del riesgo para cada uno de los riesgos clave
identificados.

 Depende del conocimiento y la experiencia del gestor del proyecto.

 Estrategias para atacar los riesgos:

1. Prevención. Reducir la probabilidad.

2. Minimización. Reducir el impacto.

3. Planes de contingencia. Estar preparado para lo peor y planificar como

solucionar la pérdida.
PLANIFICACIÓN DEL RIESGO

 Resolución de riesgos:

 Evite el riesgo.

 Traslade el riesgo de una parte del sistema a otra.

 Consiga información acerca del riesgo.

 Elimine el origen del riesgo.

 Asuma el riesgo.

 Comunique el riesgo.

 Controle el riesgo (plan de contingencia).

 Recuerde el riesgo.

6. SUPERVISIÓN DEL RIESGO

 Valor cada riesgo: decidir si han cambiado sus efectos.

 Se hace una valoración después de alcanzar cada hito principal.

 Encargado de riesgos:
  Alertar sobre los riesgos del proyecto y evitar que los admin. y
desarrolladores los ignoren en la planificación.

 Buscar todas las razones por las cuales el proyecto puede fallar.

 Supervisar la efectividad de los planes de reducción de riesgos.

 Realizar el clásico análisis costo-beneficio para la prevención o el plan de

contingencia del riesgo.

7. EL PLAN DE REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO (RSGR)

I. Introducción
1. Alcance y propósito del documento
2. Visión general de los riesgos principales
3. Responsabilidades
a. Gestión
b. Personal técnico
II. Tabla de riesgo del proyecto.
1. Descripción de todos los riesgos por encima de la línea de corte
2. Factores que influyen en la probabilidad e impacto
III. Reducción, supervisión y gestión del riesgo
n. Riesgo # n
a. Reducción
i.Estrategia general.
ii. Pasos específicos.
b. Supervisión
i. Factores a supervisar
ii. Enfoque de supervisión
c. Gestión
i. Plan de contingencia
ii. Consideraciones especiales.
IV. Planificación temporal de revisión del Plan RSGR
V. Resumen