Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
ChacoArgentina
{Baez, Campuzano, Esperguin}@frre.utn
http://www.frre.utn.edu.ar
1 Introducción
[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?
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
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 clienteusuario 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
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?
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?
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?
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
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.