El documento habla sobre la gestión de riesgos en proyectos de software. Explica que un riesgo es un evento con probabilidad incierta que puede afectar los objetivos de un proyecto. Describe los procesos de identificación, análisis, planeación y monitoreo de riesgos, así como categorías de riesgos como los del proyecto, producto y negocio. Finalmente, provee ejemplos de riesgos específicos y estrategias para manejarlos.

1. M.Sc. Javier David Chávez Centeno
DEPARTAMENTO ACADÉMICO DE INFORMÁTICA
jdchavez5@hotmail.com
CUSCO – PERÚ
2013

2. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 2Dpto Académico de Informática
Gestión de Riesgos
«Si usted conoce al enemigo y se conoce a sí mismo, no
necesita temer el resultado de cien batallas»
Sun Tzu
El enemigo del gestor del proyecto de software es el riesgo.

3. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 3Dpto Académico de Informática
CONTENIDO
4.1 Riesgos del software
Categorías de riesgos
Categorías de riesgos según Charette
4.2 Gestión del riesgo
Proceso de gestión del riesgo
Actividad para la gestión del riesgo
a) Identificación de riesgos
b) Análisis de riesgos
c) Planeación de riesgos
d) Monitorización del riesgo
Bibliografía
Lecturas

4. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 4Dpto Académico de Informática
 Un riesgo, es un evento o circunstancia cuya
probabilidad de ocurrencia es incierta, pero
que, en caso de aparecer, tiene un efecto
(positivo o negativo) sobre los objetivos de un
proyecto.
 Un riesgo, es una probabilidad de que una
circunstancia adversa ocurra.
 Un riesgo, puede ocurrir o no. Pero, sin importar
el resultado, es buena idea identificarlo, evaluar
la probabilidad que ocurra, estimar su impacto y
establecer un plan de contingencia en caso de
que el problema se presente.

5. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 5Dpto Académico de Informática
El riesgo siempre involucra dos características:
Incertidumbre: el riesgo puede o no ocurrir; no existen
riesgos 100% probables.
Pérdida: si el riesgo se convierte en realidad, ocurrirán
consecuencias o pérdidas indeseables.
Cuando se analizan los riesgos es importante cuantificar el
grado de incertidumbre y el grado de pérdida asociado con
cada riesgo. Esto se logra considerando diferentes
categorías de riesgos.
a) Riesgos del proyecto
b) Riesgos del producto (técnicos)
c) Riesgos de negocios (empresariales)

6. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 6Dpto Académico de Informática
Amenazan el plan del proyecto, inciden en el
presupuesto, calendarización, personal, recursos, participant
es y requisitos.
Del
proyecto
Afectan la calidad o el rendimiento del software a
desarrollar, se traducen en problemas en
diseño, implementación, interfaz, verificación y
mantenimiento, ambigüedad de la
especificación, obsolescencia técnica entre otros.
Del
producto
Riesgos que afectan a la organización que desarrolla o
adquiere el software, pueden ser: riesgo de mercado (producto
demasiado bueno), riesgo de estrategia (producto que no
encaja), riesgo de ventas (producto poco vendible), riesgo
administrativo (falta de apoyo), riesgo presupuestal (producto fuera
de presupuesto).
De
negocios

7. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 7Dpto Académico de Informática
Otra categorización de los riesgos en función de su
facilidad de detección [Charette, 1989]:
- Riesgos conocidos: son aquellos que se pueden
predecir después de una evaluación del plan del
proyecto, del entorno técnico y otras fuentes de
información fiables (fechas de entrega irreales, falta de
requisitos documentados, etc.).
- Riesgos predecibles: se extrapolan de la experiencia
de proyectos anteriores (cambios en el personal, mala
comunicación con el cliente).
- Riesgos impredecibles: pueden ocurrir, pero es
extremadamente difícil identificarlos por adelantado.

8. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 8Dpto Académico de Informática
Identificación
del riesgo
Análisis
de riesgos
Planeación
del riesgo
Monitorización
del riesgo
Lista de
riesgos
potenciales
Lista de
riesgos
prioritarios
Planes para
evitar el riesgo
y de
contingencia
Valoración del
riesgo
Administrador del proyecto o equipo

9. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 9Dpto Académico de Informática
 Identificación del riesgo: Identificar los posibles riesgos para el
proyecto, el producto y los negocios.
 Análisis de riesgos: Valorar la probabilidad y consecuencias de
dichos riesgos.
 Planeación del riesgo: Es indispensable elaborar planes para
enfrentar el riesgo, evitarlo o minimizar sus efectos en el
proyecto.
 Monitorización del riesgo: Valorar regularmente el riesgo y los
planes para atenuarlo, y revisarlos cuando se aprenda más sobre
el riesgo.

10. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 10Dpto Académico de Informática

11. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 11Dpto Académico de Informática
Un método para identificar los riesgos es crear una lista de
verificación de diferentes tipos de riesgo.
 Riesgos tecnológicos: tecnologías de software o hardware usadas para
desarrollar el sistema.
 Riesgos personales: personas en el equipo de desarrollo.
 Riesgos organizacionales: entorno organizacional donde se desarrolla el
software.
 Riesgos de herramientas: resultan de las herramientas de software y otro
software de soporte que se usa para desarrollar el sistema.
 Riesgos de requerimientos: proceden de cambios a los requerimientos
del cliente y del proceso de gestionarlos.
 Riesgos de estimación: surgen de las estimaciones administrativas de
los recursos requeridos para construir el sistema.

12. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 Dpto Académico de Informática 12
Tipo Riesgo Descripción
Proyecto Rotación del personal
Cambio de gestión
No disponibilidad de Hardware
Personal con experiencia abandona el proyecto
antes de que finalice
Habrá un cambio de gestión organizacional con
diferentes prioridades
El Hardware esencial para el proyecto no será
entregado a tiempo
Proyecto y
producto
Cambio de requerimientos
Retrasos en la especificación
Subestimación del tamaño
Habrá mas cambios en los requerimientos de lo
esperado
Las especificaciones de las interfaces esenciales
no estarán a tiempo
El tamaño del proyecto se ha subestimado
Producto Bajo rendimiento de la
herramienta CASE
Las herramientas CASE que ayudan al proyecto
no tienen el rendimiento esperado
Negocio Cambio de tecnología
Competencia del producto
Un producto competitivo se pone en venta antes
de que el sistema se complete
La tecnología fundamental sobre la que se
construirá el sistema se sustituye por nueva
tecnología

13. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 Dpto Académico de Informática 13
Tipo de riesgo Riesgos posibles
Tecnológico La BD que se usa en el sistema no puede procesar tantas transacciones por
segundo como se esperaba. (1)
Los componentes de software de reutilización contienen defectos que hacen que
no puedan reutilizarse como se planeó. (2)
Personal Es imposible reclutar personal con las habilidades requeridas. (3)
El personal clave está enfermo e indispuesto en momentos críticos. (4)
No está disponible la capacitación requerida para el persona. (5)
De organización La organización se reestructura de modo que diferentes administraciones son
responsables del proyecto. (6)
Problemas financieros de la organización fuerzan reducciones en el presupuesto
del proyecto. (7)
Herramientas El código elaborado por las herramientas de generación de código de software es
ineficiente. (8)
Las herramientas de software no pueden trabajar en una forma integrada. (9)
Requerimientos Se propone cambios a los requerimientos que demandan mayor trabajo de
rediseño. (10)
Los clientes no entienden las repercusiones de los cambios a los requerimientos.
(11)
Estimación Se subestima el tiempo requerido para desarrollar el software. (12)
Se subestima la tasa de reparación de defectos. (13)
Se subestima el tamaño del software. (14)

14. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 14Dpto Académico de Informática
Considerar cada riesgo identificado y realizar un juicio acerca de la
probabilidad y gravedad de dicho riesgo. Apóyese en su propio juicio y en la
experiencia de proyectos anteriores. No es posible hacer valoraciones
precisas y numéricas de la probabilidad y gravedad de cada riesgo.
- En lugar de ello se estiman en intervalos:
 Muy baja (< 10%)
 Baja (del 10 al 25%)
 Moderada (del 25 al 50%)
 Alta (del 50 al 75%)
 Muy alta (> 75%)
- Los efectos del riesgo pueden ser: catastrófico (amenazan la supervivencia
del proyecto), graves (causarían grandes demoras), tolerables (demoras
dentro de la contingencia permitida) o insignificantes.

15. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 Dpto Académico de Informática 15
Riesgo Probabilidad Efecto
Problemas financieros de la organización fuerzan reducciones en el
presupuesto del proyecto. (7)
Baja Catastrófico
Es imposible reclutar personal con las habilidades requeridas. (3) Alta Catastrófico
El personal clave está enfermo e indispuesto en momentos críticos. (4) Moderada Grave
Los componentes de software de reutilización contienen defectos que
hacen que no puedan reutilizarse como se planeó. (2)
Moderada Grave
Se propone cambios a los requerimientos que demandan mayor
trabajo de rediseño. (10)
Moderada Grave
La organización se reestructura de modo que diferentes
administraciones son responsables del proyecto. (6)
Alta Grave
La BD que se usa en el sistema no puede procesar tantas
transacciones por segundo como se esperaba. (1)
Moderada Grave
Se subestima el tiempo requerido para desarrollar el software. (12) Alta Grave
Las herramientas de software no pueden trabajar en una forma
integrada. (9)
Alta Tolerable
Los clientes no entienden las repercusiones de los cambios a los
requerimientos. (11)
Moderada Tolerable

16. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 Dpto Académico de Informática 16
Riesgo Probabilidad Efecto
No está disponible la capacitación requerida para el persona. (5) Moderada Tolerable
Se subestima la tasa de reparación de defectos. (13) Moderada Tolerable
Se subestima el tamaño del software. (14) Alta Tolerable
El código elaborado por las herramientas de generación de código de
software es ineficiente. (8)
Moderada Insignificante
El número de riesgos a monitorizar debe depender del proyecto.
Pueden ser 5 o 15 (debe ser manejable).
En general, los riesgos catastróficos deben considerarse siempre,
así como los riesgos graves con más de una probabilidad moderada
de ocurrencia.

17. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 Dpto Académico de Informática 17
 Considerar cada riesgo clave identificado y desarrolla estrategias para
manejarlos.
 Las estrategias se establecen entre categorías:
 Estrategias de prevención, reducir la probabilidad de que surja el
riesgo. Por ejemplo la estrategia de enfrentar los componentes
defectuosos.
 Estrategias de minimización, reducir el efecto del riesgo. Por ejemplo
la estrategia para las enfermedades del personal.
 Planes de contingencia, estar preparado para lo peor y tener una
estrategia para hacer frente a ello. Por ejemplo la estrategia para los
problemas financieros de la organización.

18. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 Dpto Académico de Informática 18
Riesgo Estrategia
Problemas
Financieros
de la organización
Prepare un documento informativo para altos ejecutivos en el que muestre
cómo el proyecto realiza una aportación muy importante a las metas de la
empresa y presente razones por las que los recortes al presupuesto del
proyecto no serían efectivos en costo.
Problemas
de reclutamiento
Alerte al cliente de dificultades potenciales y de la posibilidad de demoras;
investigue la compra de componentes.
Enfermedad
del personal
Reorganice los equipos de manera que haya más traslape de trabajo y, así,
las personas comprendan las labores de los demás.
Componentes
defectuosos
Sustituya los componentes potencialmente defectuosos con la compra de
componentes de conocida fiabilidad.
Cambio de
requerimientos
Obtenga información de seguimiento para valorar el efecto de cambiar los
requerimientos; maximice la información que se oculta en el diseño.
Reestructuración
de la organización
Prepare un documento informativo para altos ejecutivos en el que muestre
cómo el proyecto realiza una aportación muy importante a las metas de la
empresa.
Rendimiento
de la base de datos
Investigue la posibilidad de comprar una base de datos de mayor
rendimiento.
Subestimación del
tiempo de desarrollo
Investigue los componentes comprados; indague el uso de un generador
de programa.

19. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 Dpto Académico de Informática 19
 Valorar regularmente cada uno de los riesgos identificados para decidir si
este riesgo se vuelve más o menos probable. Considerar si los efectos del
riesgo han cambiado o no.
 Los riesgos deben monitorizarse comúnmente en todas las etapas del
proyecto.
 En cada revisión, es necesario reflexionar y estudiar cada uno de los
riesgos clave por separado.

20. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 Dpto Académico de Informática 20
Tipo de riesgo Indicadores potenciales
Tecnológico Entrega tardía de hardware o software de soporte; muchos problemas
tecnológicos reportados.
Personal Baja moral del personal; malas relaciones entre miembros del equipo;
alta rotación de personal.
De organización Chismes en la organización falta de acción de los altos ejecutivos.
Herramientas Renuencia de los miembros del equipo para usar herramientas; quejas
acerca de las herramientas CASE; demandas por estaciones de trabajo
mejor equipadas.
Requerimientos Muchas peticiones de cambio de requerimientos; quejas de los
clientes.
Estimación Falla para cumplir con el calendario acordado; falla para corregir los
defectos reportados.

21. UNIVERSIDAD DE SAN ANTONIO ABAD DEL CUSCO – PERÚ - 2013
JAVIER DAVID CHÁVEZ CENTENO 27/08/2013 21Dpto Académico de Informática
Bibliografía
1. Pressman, R. (2005). Ingeniería del Software. México:
McGraw-Hill. 6ta ed. cap. 25.
2. Sommerville, I. (2011). Ingeniería de Software. México:
Pearson. 9na ed. cap. 22.
Lecturas obligatorias
McConnell, S. (1997). Desarrollo y gestión de proyectos
informáticos. McGraw-Hill. cap. 5.