INGENIERIA DEL SOFTWARE:

GESTION DE RIESGOS EN PROYECTOS DE
SOFTWARE

1 1
Baez Roberto , Campuzano Cinthia 1, Esperguin Enzo

1
 Universidad Tecnológica Nacional – Facultad Regional Resistencia, calle French 414
Chaco­Argentina
{Baez, Campuzano, Esperguin}@frre.utn
http://www.frre.utn.edu.ar

Resumen.  En   la   actualidad   las   organizaciones   que   desarrollan   software

enfrentan   un   elemento   crítico   en   el   proceso   de   desarrollo   de   productos   de
software: los Riesgos. Estos se presentan a nivel de cada una de las fases del
desarrollo, y deben ser objeto de una gestión adecuada para evitar que estos se
puedan llegar a materializar durante el desarrollo, provocando así, un impacto
negativo en el proyecto o el producto final. La gestión de riesgos en proyectos
de software es una actividad expresada en múltiples metodologías, pero en la
práctica se aplican de forma particular de­pendiendo la lógica del negocio de
cada organización.
El presente trabajo es una investigación exploratoria de los principales riesgos
que   se   presentan   en   proyectos   de   desarrollo   de   software,   en   distintas
Organizaciones   de   nuestra   región.   La   cuestión   de   esta   investigación   se
responde   a través de  un experimento   que  implica distribuir  un  cuestionario
online a distintos profesionales del área de desarrollo de software. El objetivo
de   este   estudio   es   determinar   la   importancia   que   tiene,   para   estas
Organizaciones, la identificación de riesgos en sus proyectos. 

1   Introducción

La   gestión   de   riesgos   es   una   actividad   de   protección   dentro   de   la   gestión   de

proyectos, encargada de identificar, mitigar y monitorear los riesgos que pudieran
afectar   a   la   ejecución   y   viabilidad   del   proyecto.   Los   riesgos   conllevan   cambios,
elecciones   y   dudas.   Podremos   conocer   o   no   los   riesgos,   o   simplemente   son
impredecibles. 

[1] La Guía de los fundamentos para la dirección de proyectos (PMBOK Guide) es un libro
en el que se presentan estándares, pautas y normas para la gestión de proyectos. 
 Según la Guía de los fundamentos para la dirección de proyectos [1], el riesgo de
un proyecto es un evento o condición incierta que, de producirse, tiene un efecto
positivo o negativo en uno o más de los objetivos del proyecto, tales como el alcance,
el cronograma, el costo y la calidad. Un riesgo puede tener una o más causas y, de
materializarse, uno o más impactos. Una causa puede ser un requisito especificado o
potencial, un supuesto, una restricción o una condición que crea la posibilidad de
consecuencias tanto negativas como positivas. Por lo tanto, es de vital importancia
realizar una adecuada gestión de riesgos donde se dé inicio en la primera fase del
proyecto, para llevar seguimiento y controles adecuados de estos en cada una de las
fases del desarrollo del software, hasta la aceptación del producto del proyecto. 
El   desarrollo de software en la actualidad,   cuenta con gran importancia en la
parte   financiera   del   país,   debido   al   crecimiento   de   transacciones   electrónicas,
generadas por la evolución de la tecnología y los sistemas, esto genera una serie de
desarrollos de software que satisfacen estas necesidades, pero se ve con preocupación
que en muchos de los proyectos de desarrollo de software actualmente no se tiene
una cultura de  ser prevenidos en realizar una adecuada gestión de riesgos a pesar de
saber que un riesgo es un gran  problema donde quiera que éste llegue a ocurrir. 

2 Encuestas

Se realizaron 16 encuestas a distintas personas que trabajan en desarrollo de software
y los resultados fueron los siguientes:

¿En qué tipo de empresa trabajan? 

El 93.8% (15 personas) trabaja en empresas privadas mientras que el otro 6,2%(1
persona) trabaja en empresa pública.
 Figura 1

¿Cuántos años hace que trabaja en desarrollo de software? 

La   mayoría   de   las   personas   encuestadas,   eran   personas   jóvenes   o   que   recién

empezaban a trabajar, por lo cual el 62.5% (10 personas) trabajan hace menos de 5
años y el 37.5% (6 personas) hace más de 5 pero menos de 10 años.

Figura 2

¿En qué tipos de proyectos software trabaja?

Se caracterizaron con el 50% (8 personas) web, 37.5% (6 personas) aplicaciones para
PC o dispositivo móviles, 6.3%(1 persona) multimedia y juegos y 6.3%( 1 persona)
Interoperabilidad en Salud.
 Figura 3

¿En qué rama de negocios se encuadran sus desarrollos? 

*Bancarios.
*Venta de tickets de una aerolínea.
*Entidades bancarias o estatales.
*Aplicaciones Web de Gestión Corporativa.
*Gestión.
*Logística.
*Automation.
*Ventas.
*Aplicaciones.
*Publicidad.
*Gestión de negocios empresariales.
*Sistemas de gestión y facturación para comercios.
*Desarrollo de videojuegos.

¿Qué metodología de desarrollo utiliza habitualmente según el tipo de proyecto
de desarrollo? 
Las metodologías que se utiliza habitualmente son: con el 68.8% Scrum  y 31.3%
Iterativo, las otras metodologías no fueron seleccionadas.

Figura 4

¿Cómo perciben los riesgos los distintos integrantes de un mismo proyecto de
desarrollo software?

el 6.3% (1 persona) Desconoce de las medidas a tener en cuenta a lo que se refiere a
riesgos, 18.8% Conoce metodologías de Gestión de Proyectos, 31.3% Le preocupan
los riesgos en los proyectos y con el 43.8% Conocen alguna definición de riesgos y
ninguno tiene experiencia profesional en gestión de riesgos en proyectos.
 Figura 5

¿En   su   grupo   de   trabajo   se   utiliza   alguna   herramienta   para   la   gestión   de

riesgos?

El 56.3% no utiliza y el 43.8% sí. Algunas de las herramientas que utilizan son: 
*Aplicativo de gestión de Ti/Si
*Base de Datos, Hojas de Cálculos
*Repositorios.

Figura 6
¿Se usa alguna herramienta de estimación para dimensionar el proyecto?

El 75% si usa herramientas para estimar los costes, tiempos y recursos, tales como
Project, Jira, Sinnaps o Wrike.

Figura 7

1.1   Proyectos de Software

Al terminar un proyecto, ¿se lleva a cabo algún informe del desarrollo donde
puedan indicarse problemas aparecidos y su impacto, o cómo se combatieron?

En esta pregunta el 50% contestó que sí y el otro 50% que tal vez se lleve a cabo
algún informe del desarrollo.
 Figura 8

¿Con qué personas le parece positivo hablar de riesgos en un proyecto? 

La mayoría desearía hablar de los riesgos del proyecto con sus superiores ya que el
75% selecciono esta opción, mientras que el 18.8% hablaría con sus compañeros del
proyecto y solo una persona voto hablar con el cliente­usuario que sería el 6.3%.

Figura 9

¿Su proyecto tiene disponible información de riesgos de proyectos pasados de la
organización?
El 43.8% si tiene disponible información de riesgos de proyectos pasados el 31.3%
no lo tiene y el 25% desconoce si cuenta con esa información.

Figura 10

¿Cuáles son las razones de los riesgos?

*No efectuar una evaluación formal un 56.3%.
*Falencias   en   la   comunicación…   Antes,   durante   y   después   de   la   evaluación   de
riesgos un 12.5%.
*No definir el contexto y objetivos de la evaluación, *No comprender el nivel de
riesgos   aceptables   para   una   organización,   *No   usar   las   mejores   técnicas   de
evaluación de riesgos, *No ser objetivo y racional en el proceso de evaluación de
riesgos y *No considerar la jerarquía de los controles ni establecer prioridades según
el riesgo 6.3%.
 Figura 11

¿Qué rol cumple habitualmente en el proyecto?

Los 16 encuestados forman parte del equipo de proyecto.

Figura 12

¿Qué concepto entiende por éxito de un proyecto? 
Satisfacer los requisitos fijados en el tiempo y coste acordado con el 87.5% es el que
sobresale.

Figura 13

A   su   criterio   ¿qué   influencia   tienen   las   prácticas   de   gestión   de   riesgo   en   el

proyecto? 

Tienen una influencia objetiva en el éxito del proyecto tiene el 68.8%, mientras que
tener   una   influencia   objetiva   en   la   percepción   del   éxito   del   proyecto   por   sus
miembros   12.5%   y   también   que,   es   mejor   para   el   éxito   del   proyecto   que   los
miembros del proyecto hablen de riesgos y se autogestionen, aunque sus prácticas no
sean del todo ortodoxas comparte el mismo porcentaje que el anterior.

Figura 14

Identificar los riesgos es positivo, medir los riesgos y abordarlos sistemáticamente no
tiene demasiados efectos, solo una persona seleccionó esta respuesta.
 Un proyecto ágil está en riesgo....

*Si las ceremonias no se cumplen.
*Cuando la gestión de recursos es inadecuada
*Si   la   comunicación   con   el   cliente   (usuario   final)   no   es   la   adecuada   para   el
relevamiento correcto de las necesidades del mismo.
*Cuando afectan a la planificación temporal o al coste del proyecto
*Cuando identifican problemas potenciales de presupuesto
*Cuando no hay una buena comunicación con el cliente
*No se siguen "buenas prácticas"
*cuando  se identifican  posibles  problemas  de diseño,  implementación,  interfaz,
etc.
*si se pone en riesgo la viabilidad del sw
*no hay un compromiso adecuado entre los miembros del equipo
*Si se producen fallos en la planificación
*Si se hace una planificación demasiado optimista
*si no cuenta con un buen presupuesto
*cuando hay una mala definición de las tareas.

¿Qué riesgos por tipo de proyecto se han presentado en su experiencia?

*Personal   poco   capacitado,   lentitud   en   la   entrega   de   módulos   con   fechas   de

entregas ya predefinidas
*No se presentaron riesgos
*Acceso a datos privados
*Ningún riesgo
*Problemas de presupuesto y tiempo, con respecto a lo planificado
*Mala estimación de costes y tiempo
 *Poca comunicación con el cliente
*Retraso para la aprobación del proyecto
*Falta de recursos
*Recorte de personal de un cliente sin fondos, Tareas que no se pueden lograr por
x motivo y atraso o cancelación de un proyecto, tiempos de entrega atrasados,
incorporación de nuevo personal a mitad de un proyecto.

Un proyecto está en riesgo si…

La tecnología cambia solo tiene el 6.3%
El ámbito del proyecto no se delimita correctamente cuenta con el 37.5%
No se gestionan correctamente los cambios tiene el 43.8%
El equipo carece de las habilidades necesarias se encuentra en el segundo lugar con
el 56.3%
Los plazos son poco realistas con el 43.8%
Los usuarios se resisten al cambio tiene el 12.5%
El proyecto carece de “patrocinador” solo el 6.3%
Los gestores olvidan el uso de “buenas prácticas” con el 25%
No se  comprenden  bien  las  necesidades  del  cliente  es  con  el  75%  el  que  mayor
coincidencia tuvo.

Figura 15
Si nos enfocamos en Elaboración de la Planificación ¿cuáles serían los riesgos? 

Las   definiciones   de   la   planificación,   de   los   recursos   y   del   producto   han   sido

impuestas por el cliente o un directivo superior, y no están equilibradas es el que
mayores coincidencias tuvo con el 62.5%
Planificación optimista, «mejor caso» (en lugar de realista, «caso esperado»).
La planificación no incluye tareas necesarias tiene el 25%
La planificación se ha basado en la utilización de personas específicas de un equipo,
pero estas personas no están disponibles con el 31.3%
No se puede construir un producto de tal envergadura en el tiempo asignado.
El producto es más grande que el estimado (en líneas de código, en el número de
puntos función, o en relación con el tamaño del proyecto anterior) tiene el 25%.
El   esfuerzo   es   mayor   que   el   estimado   (por   líneas   de   código,   número   de   puntos
función, módulos, etc.) cuenta con el 25%
La reestimación debida  a un retraso en la planificación es demasiado optimista o
ignora la historia del proyecto con el 25%
La presión excesiva en la planificación reduce la productividad tiene el 18.8%
La fecha final ha cambiado sin ajustarse al ámbito del producto o a los recursos
disponibles con el 12.5%
Un retraso en una tarea produce retrasos en cascada en las tareas dependientes tiene
el 37.5%
Las áreas desconocidas del producto llevan más tiempo del esperado en el diseño y
en la implementación cuenta con el 12.5%
 Figura 16

En el área de Organización y Gestión ¿cuáles serían los riesgos? 

El proyecto carece de un promotor efectivo en los superiores tiene el 12.5%
El proyecto languidece demasiado en el inicio difuso cuenta con el 6.3%
Los despidos y las reducciones de la plantilla reducen la capacidad del equipo con el
6.3%
Dirección   o   marketing   insisten   en   tomar   decisiones   técnicas   que   alargan   la
planificación con el 18.8%
La estructura inadecuada de un equipo reduce la productividad se encuentra en el
segundo lugar de coincidencias con el 43.8%
El ciclo de revisión/decisión de la directiva es más lento de lo esperado con el 12.5%
El   presupuesto   varía   el   plan   del   proyecto   cuenta   con   el   mayor   número   de
coincidencias 56.3%
La dirección toma decisiones que reducen  la motivación del  equipo de desarrollo
tiene el mayor porcentaje junto al anterior 56.3%
Las   tareas   no   técnicas   encargadas   a   terceros   necesitan   más   tiempo   del   esperado
(aprobación  del  presupuesto,  aprobación  de  la  adquisición  de  material,  revisiones
legales, seguridad, etc.) solo cuenta con el 6.3%
La   planificación   es   demasiado   mala   para   ajustarse   a   la   velocidad   de   desarrollo
deseada cuenta con el 31.3%
Los   planes   del   proyecto   se   abandonan   por   la   presión,   llevando   al   caos   y   a   un
desarrollo ineficiente el 6.3%
La dirección pone más énfasis en las heroicidades que en informarse exactamente del
estado, lo que reduce su habilidad para detectar y corregir problemas solo el 6.3%

Figura 17

¿En cuánto a Ambiente/Infraestructura de Desarrollo cuales serían los riesgos? 

*Los espacios no están disponibles en el momento necesario solo con el 6.3%
*Los espacios están sobre utilizados, son ruidosos o distraen se encuentra en el
segundo lugar con el 18.8%
*Las herramientas de desarrollo no están disponibles en el momento deseado es el
que mayor porcentaje tiene de coincidencia con el 37.5%
*Las herramientas de desarrollo no funcionan como se esperaba; el personal de
desarrollo necesita tiempo para resolverlo o adaptarse a las nuevas herramientas se
encuentra en el segundo lugar con el 18.8%
*Las herramientas de desarrollo no se han elegido en función de sus características
técnicas, y no proporcionan las prestaciones previstas cuenta con el 12.5%
*La curva de aprendizaje para la nueva herramienta de desarrollo es más larga de
lo esperado solo con el 6.3%
 Figura 18

Respecto de los usuarios finales, ¿dónde están los riesgos? 

Los usuarios finales insisten en nuevos requisitos solo el 6.3% de los encuestados
seleccionaron esta opción.
En el último momento, a los usuarios finales no les gusta el producto, por lo que hay
que volver a diseñarlo y a construirlo es el mayor número de coincidencia con el
43.8%
Los usuarios no han realizado la compra del material necesario para el proyecto y,
por tanto, no tienen la infraestructura necesaria con el 12.5%
No se ha solicitado información al usuario, por lo que el producto al final no se ajusta
a las necesidades del usuario, y hay que volver a crear el producto, se encuentra en el
segundo lugar con el 37.5%

Figura 19
Si nos enfocamos en el cliente ¿cuáles serían los riesgos? 

El cliente insiste en nuevos requisitos, con el 25% 
Los   ciclos   de   revisión/decisión   del   cliente   para   los   planes,   prototipos   y
especificaciones son más lentos de lo esperado con el 6.3%
El   cliente   no   participa   en   los   ciclos   de   revisión   de   los   planes,   prototipos   y
especificaciones, o es incapaz de hacerlo, resultando unos requisitos inestables y la
necesidad de realizar unos cambios que consumen tiempo, con el mayor número de
coincidencia, un 75%.
El tiempo de comunicación del cliente (por ejemplo, tiempo para responder a las
preguntas para aclarar los requisitos) es más lento del esperado, con el segundo lugar
en coincidencias con el 37.5%.
El   cliente   insiste   en   las   decisiones   técnicas'   que   alargan   la   planificación,   con   el
18.8%
El cliente intenta controlar el proceso de desarrollo, con lo que el progreso es más
lento de lo esperado, tiene el 18.8%
Los componentes suministrados por el cliente no son adecuados para el producto que
se está  desarrollando, por  lo que  se tiene que hacer un trabajo  extra  de  diseño e
integración, cuenta con el 25%.
Los componentes suministrados por el cliente tienen poca calidad, por lo que tienen
que hacerse trabajos extra de comprobación, diseño e integración, con el 25%.
Las herramientas de soporte y entornos impuestos por el cliente son incompatibles,
tienen un bajo rendimiento o no funcionan de forma adecuada, con lo que se reduce
la productividad, cuenta con el 18.8%
El cliente no acepta el software entregado, incluso aunque cumpla todas sus
especificaciones, tiene el 18.8%
El cliente  piensa en una velocidad  de desarrollo que el personal  de desarrollo no
puede alcanzar, cuenta con el 25%.
 Figura 20

Si tuviera Personal Contratado ¿cuáles serían los riesgos? 

El personal contratado no suministra los componentes en el período establecido, en el
segundo lugar con el 37.5%
El personal contratado proporciona material de una calidad inaceptable, por lo que
hay que añadir un tiempo extra para mejorar la calidad, con el mayor porcentaje de
coincidencia de 69.8%
Los proveedores no se integran en el proyecto, con lo que no se alcanza el nivel de
rendimiento que se necesita, por último, con el 31.3%

Figura 21

Respecto de los Requisitos, ¿cuáles serían los riesgos? 
Los requisitos no se han definido correctamente. y su redefinición aumenta el ámbito
del proyecto, el mayor porcentaje de coincidencia con el 93.8%
Se añaden requisitos extra, con solo el 6.3%
Las partes  del  proyecto que  se no se han especificado  claramente consumen más
tiempo del esperado, tiene el 31.3%

Figura 22

Y pensando en el Producto, ¿dónde están los riesgos? 

Los   módulos   propensos   a   tener   errores   necesitan   más   trabajo   de   comprobación,

diseño e implementación, con el 12.5%
Una calidad no aceptable requiere de un trabajo de comprobación, diseño e
implementación superior al esperado, cuenta con el 37.5%
El desarrollo de funciones software erróneas requiere volver a diseñarlas y a
implementarlas con el 31.3%
El desarrollo de una interfaz de usuario inadecuada requiere volver a diseñarla y a
implementarla, cuenta con el 25%
El desarrollo de funciones software innecesarias alarga la planificación con el 50% 
Unos   requisitos   rígidos   de   compatibilidad   con   el   sistema   existente   necesitan   un
trabajo extra de comprobación, diseño e implementación, con el 12.5%
El   requisito   de   trabajar   con   varios   sistemas   operativos   necesita   más   tiempo   del
esperado, con el 6.3%
El trabajo con un entorno software desconocido causa problemas no previstos, tiene
el 31.3%
El trabajo con un entorno hardware desconocido causa problemas imprevistos, cuenta
con el 31.3%
El desarrollo de un tipo de componente nuevo para la organización consume más
tiempo del esperado, tiene el 6.3%.
Depender de una tecnología que aún está en fase de desarrollo alarga la planificación,
con el 6.3%

Figura 23

Si de Fuerzas mayores se trata ¿cuáles son los riesgos? 

El producto depende de las normativas del gobierno, que pueden cambiar de forma
inesperada, es el mayor porcentaje de coincidencia con el 75%
El producto depende de estándares técnicos provisionales, que pueden cambiar de
forma inesperada, cuenta con el 43.8%
 Figura 24

En cuanto al Personal, los riesgos se presentan en: 

La contratación tarda más de lo esperado, con el 25%
Las tareas preliminares (por ejemplo, formación, finalización de otros proyectos,
adquisición de licencias) no se han completado a tiempo, con el 50%
La falta de relaciones entre la dirección y el equipo de desarrollo ralentiza la toma de
decisiones, cuenta con el 31.3%
Los miembros del equipo no se implican en el proyecto, y por lo tanto no alcanzan el
nivel de rendimiento deseado, con el 50%
La falta de motivación y de moral reduce la productividad, tiene el 56.3%
La falta de la especialización necesaria aumenta los defectos y la necesidad de repetir
el trabajo, con el 31.3%
El personal necesita un tiempo extra para acostumbrarse a trabajar con herramientas
o entornos nuevos, con el 18.8%
El  personal  necesita  un  tiempo   extra  para  acostumbrarse  a trabajar  con  hardware
nuevo, tiene el 25%
El  personal  necesita  un  tiempo  extra  para  aprender  un  lenguaje  de  programación
nuevo, cuenta con el 43.8%
El personal contratado abandona el proyecto antes de su finalización, con el 31.3%
Alguien de la plantilla abandona el proyecto antes de su finalización, tiene el 12.5%
La   incorporación   de   nuevo   personal   de   desarrollo   al   proyecto   ya   avanzado,   y   el
aprendizaje   y   comunicaciones   extra   imprevistas   reducen   la   eficiencia   de   los
miembros del equipo existentes, con el 43.8%
Los miembros del equipo no trabajan bien juntos, tiene el 25%
Los   conflictos   entre   los   miembros   del   equipo   conducen   a   problemas   en   la
comunicación   y   en   el   diseño,   errores   en   la   interfaz   y   tener   que   repetir   algunos
trabajos, tiene el 25%
Los   miembros   problemáticos   de   un   equipo   no   son   apartados,   influyendo
negativamente en la motivación del resto del equipo, cuenta con el 12.5%
Las personas más apropiadas para trabajar en el proyecto no están disponibles, con el
12.5%
Se necesitan personas para el proyecto con habilidades muy específicas y no se
encuentran, tiene el 18.8%
Las personas clave sólo están disponibles una parte del tiempo, cuenta con el 6.3%
No hay suficiente personal disponible para el proyecto, con el 25%
Las tareas asignadas al personal no se ajustan a sus posibilidades, con el 12.5%
El personal trabaja más lento de lo esperado, cuenta con el 6.3%
El sabotaje por parte del personal técnico deriva en una pérdida de trabajo o en un
trabajo de poca calidad, por lo que hay que repetir algunos trabajos, con el 6.3%
 Figura 25

Diseño e Implementación pueden presentar los siguientes riesgos: 

Un diseño demasiado sencillo no cubre las cuestiones principales, con lo que hay que
volver a diseñar e implementar, con el 75%
Un diseño demasiado complejo exige tener en cuenta complicaciones innecesarias e
improductivas en la implementación, con el 31.3%
Un mal diseño implica volver a diseñar e implementar, con el 37.5%
La utilización de metodologías desconocidas deriva en un periodo extra de formación
y   tener   que   volver   atrás   para   corregir   los   errores   iniciales   cometidos   en   la
metodología, con el 12.5%
No   se   puede   implementar   la   funcionalidad   deseada  con   el   lenguaje   o  bibliotecas
utilizados: el personal de desarrollo tiene que utilizar otras bibliotecas, o crearlas él
mismo para conseguir la funcionalidad deseada, con el 6.3%
Las bibliotecas de código o clases tienen poca calidad, y generan una comprobación
extra, corrección de errores y la repetición de algunos trabajos, con el 25%
Se ha sobreestimado el ahorro en la planificación derivado del uso de herramientas
para mejorar la productividad, cuenta con el 18.8%
Los componentes desarrollados por separado no se pueden integrar de forma sencilla,
teniendo que volver a diseñar y repetir algunos trabajos, tiene el 18.8%.

Figura 26

En el Proceso pueden estar los siguientes riesgos:

La burocracia produce un progreso más lento del esperado, con el 18.8%
La   falta   de   un   seguimiento   exacto   del   progreso   hace   que   se   desconozca   que   el
proyecto esté retrasado hasta que está muy avanzado, tiene el 43.8%
Las actividades iniciales de control de calidad son recortadas, haciendo que se tenga
que repetir el trabajo, cuenta con el 37.5%
Un control de calidad inadecuado hace que los problemas de calidad que afectan a la
planificación se conozcan tarde, con el 68.8%
La falta de rigor (ignorar los fundamentos y estándares del desarrollo de software)
conduce a fallos de comunicación, problemas de calidad y repetición del trabajo. Un
consumo de tiempo innecesario, con el 18.8%.
El exceso de rigor (aferramiento burocrático a las políticas y estándares de software)
lleva a gastar más tiempo en gestión del necesario, tiene el 6.3%
La   creación   de   informes   de   estado   a   nivel   de   directiva   lleva   más   tiempo   al
desarrollador de lo esperado, con el 6.3%
La falta de entusiasmo en la gestión de riesgos impide detectar los riesgos más
importantes del proyecto, tiene el 18.8%
La   gestión   de   riesgos   del   proyecto   software   consume   más   tiempo   del   esperado,
cuenta con el 12.5%

Figura 27

Algunos otros riesgos que le resulte importante agregar:

*La falta de motivación ante la ausencia de un líder de proyecto en el área
*Lo único que me gustaría agregar es que, si bien hay riesgos en todos lados, el
cliente lo sabe y hay un contrato para eso, siempre hay algo firmado, y cuando pasa
algo inesperado se habla, se comunica, se pacta, se arregla, se negocia, es decir ese
sería el peor de los riesgos, la falta de comunicación con el cliente. Y quiero aclarar
que las habilidades de una persona con respecto a herramientas y problemas, y cosas,
nunca van a afectar al proyecto, porque antes de ingresar a alguien a un proyecto
tiene que tener sus skills con las herramientas que se van a utilizar y si un arquitecto
decide usar una herramienta que no tiene soporte y además no existe nadie que pueda
manejarlo aparte de él, entonces se va a tener que tomar la molestia de iniciar un
tiempo después el proyecto y armar un equipo especializado en eso. Es un riesgo
porque para ese entonces el cliente ya pudo haber encontrado a alguien mejor que le
hace precio en una tecnología o usando herramientas que ya todos conocemos

Teniendo   en   cuenta   estos   resultados,   que   en   algunos   de   los  proyectos   se  nota   la

ausencia de una gestión de riesgos y los riesgos existentes de hoy en día en cada uno
de   los   proyectos   desarrollados   a   nivel   software,   se   evidencia   la   necesidad   de
desarrollar   métodos   que   nos   permitan   identificar   la   probabilidad   de   ocurrencia   e
impacto de un evento atípico, facilitando el control de los mismos en el caso de que
se presenten en las diferentes etapas de desarrollo.
3   Conclusiones

 Es importante entender de forma específica y clara cada una de las fases del
desarrollo de software, ya que de estas se deben identificarlos riesgos más
importantes que las afectan.
 La   identificación   de   los   riesgos   es   de   suma   importancia   ya   que   permitirá
concentrarse en los riesgos que se pueden llegar a materializar en cada fase
del desarrollo del software.
 Al definir el nivel de la probabilidad de ocurrencia y el nivel de impacto de
los riesgos,  permitirá hallar  el  nivel  de riesgo  y así  focalizarse  con mayor
grado de atención a los que den niveles críticos.
 Se debe realizar una adecuada determinación del nivel del riesgo por cada uno
de los riesgos para proponer el plan de respuesta que más se ajuste al riesgo.
 Es   importante   proponer   planes   de   respuesta   de   riesgos   que   garanticen   un
adecuado control y seguimiento sobre estos.
 Es necesario contar con personal que maneje el tema de tratamiento, control y
seguimiento de los riesgos presentados en las diferentes fases del desarrollo
del proyecto de software.
 Se   deben   tener   planes   de   respuesta   claros,   actualizados   y   efectivos,   que
permitan   el   control   y   un   adecuado   manejo   de   los   riesgos   para   reducir   la
probabilidad y/o impacto de ocurrencia.
 Se debe tener un sistema gestor de riesgos para tener un control y seguimiento
sobre los riesgos encontrados analizados y mitigados en cada una de las fases
del desarrollo de software. 

4   Referencias

1. Project Management Institute I. Guía de los Fundamentos para la Dirección de Proyectos
(Guía del PMBOK). Sexta Edición.
2. Roger S. Pressman. Ingeniería del Software. Mc Graw Hill.
3. Ian Sommerville. (2005). Ingeniería de Software. Pearson Educación, S.A.