Monitorear los riesgos del proyecto

Plan de gestión de riesgos

Según OBS Business School “la gestión de riesgo es una parte de la gestión de proyectos
que consiste en identificar y analizas los problemas a los cuales un proyecto podría
enfrentarse durante su desarrollo, para así poder evaluar los daños que supondría, y poder
diseñar una estrategia para prevenirlos y mitigarlos“ (Pérez, 2021).

La gestión de riesgo es una parte integral del proyecto siendo un elemento clave para la
toma de decisiones ya que como dice la OBS consiste en identificar y analizar los posibles
problemas que podría enfrentarse el desarrollo del proyecto. Estos riesgos pueden ser
positivos o negativos, es por ello que es necesario gestionar estos riesgos de manera que su
efecto sea mínimo o nulo.

Para el plan de gestión de riesgos del proyecto de desarrollo de software para la empresa
Agencia de Viajes Cosmotravels se utilizará la siguiente metodología en cuanto, a los
procesos de identificación, análisis, plan de respuesta y control y seguimiento de los riesgos
formulados.

Identificacion
de posibles
riesgos

Analisis
Control y
cualitativo y
seguimiento
cuantitativo

Plan de
respuesta a
riesgos

1
Identificación de riesgo

En este sub proceso se identifican los riesgos para dar soporte a la planificación del
proyecto, “Consiste en determinar qué riesgo tiene probabilidad de afectar el proyecto y
documentar las características de cada uno” (Anonimo, 2013).

El propósito de identificar lo riesgo es determinar qué riesgo y/o amenazas podría afectar al
proyecto, para ello nos apoyaremos con la documentación anteriormente presentada, se
realizará un listado de los posibles riesgos que se pudieran presentar en cada una de las
fases de un sistema de desarrollo a la medida y se analizara la causa raíz que cada riesgo
puede contener.

Posibles riesgos y causa

Área de análisis

- Miembros con experiencia abandonando el Proyecto o pocos miembros del equipo

de desarrolladores.
- Causa, rotación o renuncia del personal.
- Entendimiento errado o poca comprensión en las especificaciones del cliente.
- Causa, insatisfacción de las expectativas del trabajo.
- Objetivos del trabajo a desarrollar incompletos o ambiguos.
- Causa, los objetivos no se definieron de manera clara y complete.

Área de Diseño.

- Falta de experiencia en el manejo de las herramientas de software a utilizar.

- Causa, subestimació n del trabajo a desarrollar.
- Diseñ o de interfaces incomplete.
- Causa, equipo en desacuerdo sobre el desarrollo de los diseñ os de
interfaces.
- Desconocimiento de la ló gica del negocio.
- Causa, mala interpretació n de los requisitos para el desarrollo del
diseñ o del Sistema.

2
Área de Codificación

- Programació n compleja.
- Causa, subestimació n del trabajo a desarrollar.
- Miembros con experiencia abandonando el proyecto o pocos miembros del
equipo de desarrolladores.
- Causa, rotació n o renuncia del personal.
- No disponibilidad de hardware y/o software.
- Causa, las herramientas necesarias para desarrollo de codificació n no se
encuentran disponibles y/o son entregadas tarde.

Área de Pruebas

- Má s usuarios de lo previsto conectados simultá neamente al Sistema.

- Causa, má s usuarios de lo previsto conectados simultá neamente al
Sistema.
- Má s usuarios de lo previsto conectados simultá neamente al Sistema.
- Causa, mala comunicació n entre el equipo.

Área de Entrega.

- Incumplimiento del tiempo acordado para presentar el entregable o el sistema

en su totalidad.
- Planificació n demasiado optimista.
- El software contiene errores al momento de la entrega.
- Agilizació n de entrega por parte del cliente.

Análisis cualitativo y cuantitativo

“El análisis del riesgo permite detener los riesgos de comunicación con el cliente, se realiza
con el objetivo de caracterizar y priorizar los riesgos, para luego determinar su exposición
para ello es necesario que realicemos un análisis cualitativo y cuantitativo” (Anonimo,
2013).

Estos análisis permiten determinar cuál es la probabilidad de ocurrencia del riesgo, así
como el impacto de estos, en el caso de que finalmente lleguen a producirse
3
Una vez identificados los riesgos deben ser estudiados, para ello se tomó como entrada la
lista de riesgos previamente identificados y analizados en cada una de sus fases, se utilizó
una tabla de probabilidad de ocurrencia de evento en donde se le asignaron valores o
niveles a cada uno de los cinco niveles los cuales son: Muy alta, Alta, Medio, Escaso, Muy
escaso; al mismo tiempo se trabajó una tabla de Impacto que puede generar un evento de
riesgo para poder medir el impacto causado por los riesgos en el momento de que se
materializasen en pleno desarrollo de software, para establecer esta medida se especificaron
cinco niveles, Muy elevado, Elevado, Medio, Bajo e Ínfimo; a continuación se
representaran las tablas trabajadas.

ESCALA

Probabilidad de ocurrencia de Impacto que puede generar un

un evento de riesgo evento de riesgo

Escala Condiciones Valor Escala Condiciones Valor

Es casi Implica serios

seguro que le problemas o
Muy
Muy Alta evento se 5 grandes 20
elevado
llevará a ventajas para
cabo la empresa

Alto
porcentaje de Produce
que ocurra, situaciones
Alta 4 Elevado 15
pero con un críticas o
bajo % de prosperas
que no

Ambas
probabilidade Genera
Medio s con el 3 Medio inconveniente 10
mismo % de s o beneficios
ocurrencia

Poca Bajo impacto

probabilidad de problemas
Escaso 2 Bajo 5
de existencia o ventajas
del evento limitadas

4
 Evento
1 Es
inexistente en
Muy imperceptible
el pasado en Ínfimo 1
escaso por la
condiciones
empresa
similares
Tabla 34 Escala de probabilidad e impacto

Como lo mostramos en nuestra tabla escala, nos explica un poco lo que son las escalas de la
probabilidad e impacto, así como el valor de cada una de las escalas.

La matriz de impacto permite priorizar diferentes tendencias o señales de cambio visibles,

se basa en dos dimensiones esenciales, relativas al nivel de riesgo/oportunidad que cada
uno de los temas implican para la organización como son:

1. La probabilidad de que el evento suceda

2. El impacto que provocaría en caso de que sucediese

Para medir cada uno de los riesgos identificados se realizó una matriz de probabilidad e
impacto, en donde se refleja la multiplicación del valor numérico del nivel de probabilidad
de ocurrencia de un evento o riesgo por el nivel numérico de impacto del riesgo sobre las
fases de desarrollo del software, este proceso se realizó con la herramienta de Excel
guiados con un video de YouTube. Este resultado es el que determinó nuestro nivel de
riesgo.

MATRIZ DE RIESGO

Impacto

Mínima Menor Moderada Mayor Máxima

Probabilidad 2 4 6 8 10

Muy Alta 5 10 20 30 40 50

Alta 4 8 16 24 32 40

Media 3 6 12 18 24 30

Baja 2 4 8 12 16 20

Muy Baja 1 2 4 6 8 10
Tabla 35 Matriz de riesgo

5
Con base al resultado de la matriz de probabilidad e impacto, se propone una escala
numérica la cual permite clasificar el riesgo según su nivel por rango numérico, se
presentan cada uno de los rangos en las siguientes tablas.

Significado de los colores de nuestra matriz

  Riesgo Extremo Requiere atención urgente

  Riesgo Alto Requiere estrategia y plan de contingencia

  Riesgo Tolerable Requiere seguimiento constante

  Riesgo Aceptable No requiere acciones de mitigación

Tabla 36 Significado de colores de la matriz de impacto

Nivel de riesgo – rango

Nivel de riesgo Color

Riesgo Aceptable 2a8

Riesgo Tolerable 10 a 18

Riesgo Alto 20 a 24

Riesgo Extremo 30 a 50
Tabla 37 Nivel de riesgo

Plan de respuestas a riesgos

El plan de respuesta a riesgos permitirá reducir la probabilidad de sufrir un impacto

negativo producido por las amenazas, y de este modo se asegurar el logro de los objetivos
del proyecto.

Se procedió a priorizar los riesgos según su nivel de riesgo crítico para proponer el plan de
contingencia por cada uno de los riesgos priorizados, haciendo uso de las estrategias para
amenazas las cuales son evitar, transferir, mitigar y aceptar.

Control y seguimiento

6
 El proyecto debe de ser supervisado continuamente para detectar nuevos riesgos y
monitorear los riesgos que se han producido. Este proceso es continuo que se debe de
realizar durante la vida del proyecto.

A cada uno de los riesgos que se les dio respuesta se les asigno un responsable quien será el
encargado en supervisar la correcta ejecución del plan de contingencia a riesgos, al igual
que este personaje deberá replantearse los riesgos existentes y/o avaluar la identificación de
nuevos riesgos, se recomienda realizar una revisión periódica para validar el estado y/o
afectación sobre cada fase de desarrollo de software.

Registro de los riesgos

El proceso de desarrollo (o ciclo de vida de un software),

“contemplan las fases necesarias para validar el desarrollo del software y así
garantizar que se cumplan los requisitos para la aplicación y verificación de los
procedimientos de desarrollo, asegurándose de que los métodos usados son
apropiados” (Intelequia news, 2020)

Para la realización del registro de los riesgos debemos de saber cuáles son las fases
necesarias para validar el desarrollo del software, a continuación, presentaremos cuales son
las fases que conllevan un desarrollo de sistema a la medida para proseguir con las tablas de
listado de riesgos encontrados y su plan de continencia.

Analisis Diseñ o Codificacion Pruebas Entrega

Una vez establecidas las fases de desarrollo se procedió a hacer un registro de todos los
posibles riesgos que influirían en el desarrollo del sistema; lo anterior generado por la
matriz de evaluación de riesgos por cada una de las fases de desarrollo de software arrojo

7
un listado de 13 riesgos donde los niveles de riesgos que se arrojaron fueron Critico,
tolerable y aceptable, teniendo relevancia y aceptando únicamente a los riesgos de nivel
Critico a los cuales se les sugirió su respectivo plan de contingencia, cabe resaltar que todos
los riesgos encontrados son afectaciones negativas para la empresa.

Para la fase de análisis se identificaron tres riesgos, dos de nivel crítico y uno de nivel
tolerable, en la fase de diseño se identificaron tres riesgos, uno de nivel crítico y dos de
nivel tolerable, en la fase de codificación se identificaron tres riesgos, dos de nivel crítico y
uno de nivel tolerable, en la fase de pruebas se identificaron dos riesgos ambos de nivel
crítico al igual que en la última fase que es entrega del producto en la cual se identificaron
dos riesgos de nivel crítico.

8
 Análisis
Estimació
Código
Descripción Fase Entregables n Total de Nivel de
del Causa raíz Probabilidad Impacto
del riesgo afectada afectados probabilid Riesgo riesgo
riesgo
ad

Miembros con
experiencia
abandonando
Rotación o
el proyecto o Documento de
R1 renuncia del Análisis 2 3 6 18 Tolerable
pocos requerimientos
personal
miembros del
equipo de
desarrolladores

Entendimiento
errado o poca Insatisfacció
comprensión en n de las Documento de
R2 Análisis 3 5 10 50 Extremo
las expectativas requerimientos
especificacione del trabajo
s del cliente

R3 Objetivos del Los objetivos Análisis Documento de 4 4 8 32 Extremo

trabajo a no se requerimientos
desarrollar definieron de
incompletos o manera clara
ambiguos y completa

9
10
Diseño

Código Estimación
Descripción del Fase Entregables Probabilida Total de Nivel de
del Causa raíz probabilida Impacto
riesgo afectada afectados d Riesgo riesgo
riesgo d

Falta de
experiencia en el
Subestimació
manejo de las Documento de
R4 n del trabajo Diseño 2 3 8 24 Alto
herramientas de diseño detallado
a desarrollar
software a
utilizar

Equipo en
desacuerdo
Diseño de
sobre el Documento de
R5 interfaces Diseño 1 3 8 24 Alto
desarrollo de diseño detallado
incompleto
los diseños
de interfaces

Mala
interpretación
de los
Desconocimient
requisitos Documento de
R6 o de la lógica del Diseño 1 4 10 40 Extremo
para el requerimientos
negocio
desarrollo del
diseño del
sistema

11
Codificación

Código
Descripción del Fase Entregables Estimación Probabilida Total de Nivel de
del Causa raíz Impacto
riesgo afectada afectados probabilidad d Riesgo riesgo
riesgo

Subestimación
Programación Codificació Implementación
R7 del trabajo a 4 3 6 18 Tolerable
compleja n del software
desarrollar

Miembros con
experiencia
abandonando el Rotación o
Codificació Implementación
R8 proyecto o renuncia del 2 1 6 6 Aceptable
n del software
pocos miembros personal
del equipo de
desarrolladores

Las
herramientas
necesarias
No para
disponibilidad de desarrollo de Codificació Implementación
R9 1 2 8 16 Tolerable
hardware y/o codificación n del software
software no se
encuentran
disponibles
y/o son

12
entregadas
tarde

13
Pruebas
Estimación
Código Descripción del Fase Entregables Probabilida Total de Nivel de
Causa raíz probabilida Impacto
del riesgo riesgo afectada afectados d Riesgo riesgo
d

Más usuarios de
Saturación
lo previsto
de Aseguramiento de
R10 conectados Pruebas 4 4 10 40 Extremo
transaccione calidad del software
simultáneamente
s
al sistema

Mala
No se ejecutó
comunicació Aseguramiento de
R11 prioridad en las Pruebas 3 4 8 32 Extremo
n entre el calidad del software
pruebas
equipo

14
Entrega
Estimación
Código Descripción del Fase Entregables Probabilida Total de Nivel de
Causa raíz probabilida Impacto
del riesgo riesgo afectada afectados d Riesgo riesgo
d

3 10 30 Extremo
Incumplimiento
del tiempo
Planificació Puesta en        
acordado para
n Entrega del
R12 presentar el producción 4
demasiado producto        
entregable o el del software
optimista
sistema en su
       
totalidad

       

5 10 50 Extremo

       
El software Agilización Puesta en        
contiene errores de entrega Entrega del
R13 producción 2
al momento de la por parte producto        
entrega del cliente del software
       

       

15
16
Plan de contingencia

Un plan de contingencia detalla las medidas que se debe de tomar para garantizar que una
empresa pueda continuar operando en caso de alguna crisis o emergencia. Afirmamos que
el plan de contingencia debe de basarse en los efectos de los riesgos a los que se expone la
organización.

Para ello analizamos la matriz evaluación de riesgos, se priorizaron nueve riesgos en total,
para la fase de análisis se seleccionaron los riegos de nivel crítico R2 y R3, para la fase de
diseño se seleccionó el único riesgo de nivel crítico R4, para la fase de codificación R7 Y
R8, para la fase de pruebas los riegos R10 y R11 y finalmente para la fase de entrega del
producto los riesgos de nivel crítico seleccionados fueron el R12 y R13.

Es necesario señalar que en la realidad se debe realizar un plan de contingencia para cada
uno de los riesgos, como consecuencia de la ocurrencia de sucesos imprevistos. No
podemos crear un plan para cada eventualidad. Sin embargo, muchas de ellas tienen
consecuencias comunes que permiten proponer medidas extrapolables. En este trabajo por
efectos académicos únicamente se les brindara respuesta a los riesgos de nivel crítico como
anteriormente se había señalado.

Nombre del proyecto Actividad

Estudio de factibilidad de desarrollo a

la medida de un sistema de registro de Plan de mitigación de riesgos con nivel
capacitación a profesionales en el área Crítico en las fases de desarrollo de
centro de formación empresarial software en una empresa privada
(CADIN)

17
Código Amenaza / Nivel
Tipo de
del Descripción del riesgo Fase de Responsable Plan de mitigación
Oportunidad respuesta
riesgo riesgo

Entendimiento errado o ● Reuniones con los interesados para

poca comprensión en Equipo de obtener más información
R2 Amenaza Análisis Critico Mitigar ● Reuniones periódicas con el cliente
las especificaciones del desarrollo
cliente ● Listado de preguntas sobre los
temas en los cuales se tiene duda
Objetivos del trabajo a ● Realizar un aclara visualización
Equipo de
R3 Amenaza desarrollar incompletos Análisis Critico Mitigar acerca de los que se desea obtener
desarrollo ● Reunión con el cliente
o ambiguos
● Definir las herramientas con las que
Falta de experiencia en se puede trabajar y apegarse a ellas
el manejo de las Equipo de ● Tomar sesiones de aprendizaje
R4 Amenaza Diseño Critico Mitigar avanzado con un experto en el tema
herramientas de desarrollo
software a utilizar ● Apoyo por parte de un personaje
externo que sea experto en la
temática
● Distribuir correctamente las
actividades de desarrollo
Programación Codificació Equipo de
R7 Amenaza Critico Mitigar ● Apoyo por parte de un experto en el
Compleja n desarrollo
tema al equipo de desarrollo

R8 Amenaza Miembros con Codificació Critico Mitigar Director de ● Reasignar las actividades a los
experiencia n proyecto miembros del equipo
abandonando el ● Contratación de nuevo personal
proyecto o pocos capacitado
miembros del equipo de

18
 desarrolladores

Mas usuarios de lo ● Tener como alternativa un servidor

previsto conectados de base de datos
simultáneamente al Equipo de ● Configuración del software por
R11 Amenaza Pruebas Critico Mitigar
sistema desarrollo parte de los desarrolladores
● Ampliar el rango de usuarios
conectados
● Usar técnicas de pruebas y tener
No se ejecutó prioridad buenas prácticas para cubrir el total
R12 Amenaza en las pruebas Pruebas Critico Mitigar Proveedor de pruebas
● Asignar analistas y profesionales en
el aspecto con conocimiento y
experiencia sobre el tema
● Adquisición de tiempo o acceso a
Incumplimiento del
que se finalice el desarrollo del
tiempo acordado para software
Entrega del Director de
R13 Amenaza presentar el entregable Critico Mitigar ● Calendarización de una nueva
producto proyecto
o el sistema en su fecha para trabajar real en donde se
totalidad cumplan los acuerdos de entrega
establecidos
El software contiene ● Realizar pruebas en ambiente de
Entrega del preproducción
errores al momento de Equipo de
R14 Amenaza producto Critico Mitigar ● Realizar pruebas piloto en ambiente
la entrega desarrollo de producción
● Acceso a más tiempo para finalizar
el software en su plenitud

19