METODOLOGAS PARA LA GESTIN DE RIESGOS EN PROYECTOS DE

SOFTWARE Y SU ADAPTACIN EN STEFANINI

AUTOR:
RUTH ALEXANDRA FAJARDO BUITRAGO

UNIVERSIDAD MILITAR NUEVA GRANADA

ESPECIALIZACIN EN GERENCIA INTEGRAL DE PROYECTOS
ARTICULO DE GRADO
BOGOTA, AGOSTO DE 2014
 METODOLOGAS PARA LA GESTIN DE RIESGOS EN PROYECTOS DE
SOFTWARE Y SU ADAPTACIN EN STEFANINI

METHODOLOGIES FOR RISK MANAGEMENT IN SOFTWARE PROJECTS AND

ITS ADAPTATION IN STEFANINI

Ruth Alexandra Fajardo Buitrago

Ingeniera en Redes de Computadores
Technical Consultant
Sophos Banking
Bogot, Colombia
rualfabu@gmail.com

RESUMEN
Los proyectos de software al igual que cualquier otro tipo de proyectos tienen riesgos
que pueden ser materializados durante su ejecucin. El desarrollo de software es una
actividad muy compleja e impredecible. El Standish International en el 2013 indicaba
que el 43% de los proyectos de software no se pudieron entregar a tiempo, dentro del
presupuesto, y con la funciones requeridas, mientras que el 18% de los proyectos de
software fueron cancelados (Standish Group International, 2012).
Las empresas invierten recursos sustanciales y esfuerzo en el desarrollo de software,
en consecuencia, el control de los riesgos asociado a los proyectos es vital para
garantizar resultados exitosos. La comprensin de la naturaleza de los distintos riesgos
y su relacin con el rendimiento del proyecto es cada vez ms importante.
Este artculo recopila las metodologas ms conocidas para la gestin de riesgos,
validando la existencia de mtodos cuantitativos y cualitativos, estadsticos,
matemticos, sistemticos que guen todo este proceso y evalundolos en funcin de
la implementacin del ms acertado para una empresa de desarrollo de Software
como Informtica & Tecnologa Stefanini, en donde sus gerentes de proyectos
reconocen constantemente la necesidad de mejorar la manera de hacer dicha gestin,
como parte de las lecciones aprendidas.
Palabras clave: Gestin de Proyectos de Software, Riesgo, Gestin de Riesgos,
Mtodos sistemticos, incertidumbre.

ABSTRACT
Software projects, like any other type of projects, have risks that can be materialized
during their implementation. Software development is a complex and unexpected
activity. In 2013, The Standish International indicated that 43% of software projects
could not be presented on time, required more budget or did not match the required
features, while 18% of such projects were canceled (Standish Group International,
2013). Companies invest substantial resources and efforts in software development,
consequently, control risks related with the projects becomes vital to ensure successful
results. Understanding the nature of the different risks and their relevance in project
performance is becoming a very important topic.
This article collects the most known methodologies for risk management validating the
existence of statistical, mathematical and systematical methods for guiding all this
process, and evaluating them by implementation of the most accurate one for a
software development company such as Informtica & Tecnologa Stefanini, where
project managers have recognized the need of improve the way they do risk
management, as part of their own experience.
Keywords: Software project management, risk, risk management, systematic
methods, uncertainty.

INTRODUCCIN
Los Proyectos de desarrollo de software a menudo se enfrentan a problemas
imprevistos que plantean riesgos potenciales dentro del entorno de desarrollo. El
control de estos riesgos surge tanto de los componentes tcnicos y no tcnicos del
desarrollo y tener control de ellos desde las primeras etapas del desarrollo es crucial
para lograr un proyecto exitoso. Por lo tanto, la gestin del riesgo de desarrollo de
software est siendo reconocido como la mejor prctica en la industria del software
para reducir estos riesgos antes de que ocurran. (Islam, 2009)
El software es un componente crucial del entorno empresarial de hoy en da, por ello
se requiere un esfuerzo superior de gestin de riesgos para dirigir con habilidad los
proyectos de desarrollo del mismo.
En la comunidad acadmica se genera un interrogante: La gestin de riesgos
contribuye al desarrollo exitoso de los proyectos de TI? .En los ltimos 10 aos, mucho
se ha conocido sobre las causas que hacen que los proyectos de TI fallen, sin
embargo, todava hay muy poca evidencia emprica de que este conocimiento se utiliza
realmente como apoyo a la gestin de riesgos en los proyectos de TI. (De Bakker,
Boonstra, & Wortmann, 2010)
El anlisis de diferentes investigaciones realizadas en la Universidad de las Ciencias
Informticas (UCI) ofrece como resultado que, el desarrollo de la Gestin de Riesgos
(GR) en muchos de los proyectos productivos es ineficiente, pues estos no tienen en
cuenta alguna de las metodologas o modelos establecidos y reconocidos
mundialmente para realizar este proceso. (Infante, Rab, & Daz, 2013)
Informtica & Tecnologa Stefanini S.A., se ha consolidado como una empresa de
servicios de tecnologa con nfasis en el desarrollo, soporte y administracin de
sistemas de informacin en Colombia. Ellos entienden la calidad en el desarrollo de
software como el conjunto de caractersticas asociadas al producto final pero logrado
durante su proceso, por tal razn, al igual que muchas empresas del sector, han
implementado un sistema de calidad evaluado con el modelo CMMI DEV vs 1.3,
otorgado por el Software Engineering Institute SEI y la universidad Carnegie Mellon,
el cual proporciona un conjunto completo e integrado de guas para desarrollar
productos y servicios (Padilla, 2014).
Durante este proceso de evaluacin y como parte de las oportunidades de mejora
sugeridas por la empresa evaluadora, se confirma la necesidad de realizar mejoras
sustanciales en la definicin de estrategias para gestin de riesgos, por tal razn se
requiere conocer y validar cuales son las metodologas existentes e identificar cual es
la ms adecuada.

2. MATERIALES Y MTODOS

La investigacin desarrollada es de tipo exploratoria considerando que aunque la

importancia de gestionar los riesgos en proyectos de Software es conocida, no lo son
las metodologas para realizar esta labor y no se conoce como las empresas en
Colombia realizan esta gestin. Por tal razn fuentes de informacin trabajadas son:

La fuente primaria de la investigacin son las entrevistas a los gerentes de

proyectos que trabajan en Informtica & Tecnologa Stefanini para establecer de
qu manera realizan la identificacin y gestin de riesgos y las sugerencias frente
al tema junto con entrevistas a personas del rea de Calidad que se encargan de
levantar, documentar y socializar las polticas y procedimientos a seguir en todos
los proyectos.
La segunda fuente ha sido la bsqueda en Internet de publicaciones, referencia de
libros, artculos y metodologas en las cuales se pueda evidenciar resultados de
proyectos que incluyeron el uso o no de metodologas en la gestin de riesgos
detectando rasgos comunes, sugerencias y guas para su implementacin los
cuales puedan ser considerados como experiencia para la adaptacin en
Informtica & Tecnologa Stefanini

3. MARCO TERICO

3.1. Definicin de Riesgo

Segn el PMBOOK, el riesgo de un proyecto es un evento o condicin incierta que, de

producirse, tiene un efecto positivo o negativo en uno o ms de los objetivos del
proyecto, tales como el alcance, el cronograma, el costo y la calidad. Un riesgo puede
tener una o ms causas y, de materializarse, uno o ms impactos. Una causa puede
ser un requisito especificado o potencial, un supuesto, una restriccin o una condicin
que crea la posibilidad de consecuencias tanto negativas como positivas.

3.2. Que es la gestin de Riesgos

Comprende todas las actividades que se realizan para reducir las incertidumbres
asociadas con ciertas tareas, o eventos. En el contexto de los proyectos, la gestin del
riesgo reduce los impactos de los eventos no deseados en el proyecto. La gestin de
riesgos en cualquier proyecto requiere la realizacin de las actividades del proceso de
toma de decisiones.

3.3. Categorizacin de Riesgos en proyectos de Software

Los riesgos pueden ser agrupados en 3 categoras:
3.3.1. Riesgos del Negocio
Comprenden todo lo que puede afectar el cumplimiento de los objetivos del proyecto,
deben ser gestionados por la empresa y no se pueden trasferir, tales como riesgos de
mercado, de estrategia, de ventas, de gestin y/o de presupuesto.

3.3.2. Riesgos Tcnicos:

Son aquellos que se pueden identificar de acuerdo al ciclo de vida de desarrollo de
software (SDLC) y deben ser gestionados por las personas responsables de cada
etapa del SDLC.

3.3.3. Riesgos Externos

Corresponden todos los riesgos que no se pueden controlar desde el proyecto como
los es la legislacin.

3.4. Mediciones de Riesgo

El desarrollo de una gestin de riesgos eficaz y adecuada depende de la comprensin
de dos componentes bsicos: probabilidad de ocurrencia y el impacto en el proyecto.
La probabilidad de ocurrencia de cada riesgo en proyectos de software es diferente y
su grado de impacto en el costo del proyecto. Por lo tanto, estos dos componentes del
riesgo de software Son de vital importancia para desarrollar una buena gestin de
riesgos.
3.5. Evaluacin de Riesgos en Proyectos de Software
Los avances en las tcnicas de gestin del riesgo han permito a algunas
organizaciones de software implementarlas y fortalecer su gestin de riesgo. Tcnicas
de modelado y mtodos de pensamiento como lluvia de ideas son las ms usadas para
dicha gestin. Estas tcnicas se utilizan para comprender el riesgo e incluyen tcnicas
cualitativas, semi-cuantitativas y cuantitativas. Estos mtodos se aplican con
frecuencia en el lugar de trabajo por si mismos o en conjunto con otras tcnicas.
3.5.1 Mtodos Cualitativos.
Se caracterizan por no recurrir a clculos numricos. Pueden ser mtodos
comparativos y mtodos generalizados.
- Lluvia de ideas
- Anlisis SWOT tambin conocido como anlisis DOFA
- Mapas
- Listas de verificacin y cuestionarios
- Entrevistas con pares

3.5.2. Mtodos Cuantitativos

Introducen una valoracin cuantitativa respecto a las frecuencias de ocurrencia de un
determinado suceso y se denominan mtodos para la determinacin de frecuencias, o
bien se caracterizan por recurrir a una clasificacin de las reas de una instalacin con
base a una serie de ndices que cuantifican daos: ndices de riesgo.
Modelos Simblicos
Hacen uso de enunciados matemticos y estadsticos para presentar el problema

Anlisis de probabilidad
El clculo de riesgo requiere el uso de datos de probabilidad la cual es calculada con
base a informacin histrica y la experiencia. Dado que hay incertidumbre (definida
esta como ausencia de informacin) es importante que todos los riesgos que afectan
el desarrollo del proyecto y por ende el proceso de toma de decisiones sean evaluados.
Este mtodo se basa en eventos y el clculo de la probabilidad de ocurrencia de esos
eventos. Un evento es algo que puede o no ocurrir en donde si se tiene la certeza que
ocurrir la probabilidad es 1.0 y, si dicho evento sin duda no pasara la probabilidad es
=0. En muchos casos los eventos no ocurren por s mismos y dependen de otros
eventos, para lo cual se calcula la probabilidad en funcin del evento del cual depende.

Anlisis de consecuencias
Consiste en la realizacin de una evaluacin inicial de los hechos y los posibles
problemas y/o causas para posteriormente analizar las consecuencias.

Consecuencia 1
Evento
Anlisis
Consecuencia 2

Consecuencia 3
Problema Causas
Figura 1: Ilustracin de la tcnica de anlisis de consecuencias
Fuente: McManus, J. (2012). Risk management in software development projects:
Routledge.

Arboles de decisin
Ofrecen una es estructura especfica para la exploracin de alternativas de accin para
resolver situaciones complejas. Los pasos para construir un rbol de decisin son:
- Describir y comprender el problema
- Identificar todas las opciones posibles
- Identificar todos los posibles resultados derivados de cada opcin.
- Plasmarlos en estructura de rbol (Nodos de decisin, ramas, nodos de
posibilidad, resultados)
- Asignar a cada resultado la probabilidad de que ocurran (0-1) y una
preferencia por que ocurran la cual est dada entre o y 100
P(Satisfactorio)= 0.60

Realizar Valor esperado $ 400 M

P(Falla)= 0.40

PROYECTO Y

P(Satisfactorio)= 0.60

Abandonar Valor esperado $ 300 M

P(Falla)= 0.40

Figura 2: Ilustracin arboles de decisin

Fuente: McManus, J. (2012). Risk management in software development projects:
Routledge.

Anlisis de Monte Carlo

Es un mtodo que permite incorporar detalles sobre la incertidumbre. Se inicia
seleccionando las variables inciertas definiendo un rango de valores posibles con una
distribucin de probabilidad la cual se determina de acuerdo a las condiciones que
rodean a cada variable. El tipo de distribucin de probabilidad puede ser normal,
triangular, uniforme o logartmica, sin desconocer que existen otras distribuciones de
probabilidad las cuales se emplean con base al anlisis que se requiera.
Con este mtodo los gerentes pueden por ejemplo determinar la probabilidad que una
actividad se encuentre en la ruta crtica.

3.6. Monetizacin de Riesgos

La capacidad de monetizar los riesgos en proyectos de desarrollo de software puede
beneficiar en diversos aspectos la toma de decisiones. (Appari & Benaroch, 2010) los
autores presentan un mtodo de valoracin del riesgo que estima dos parmetros para
cada factor de riesgo individual: costo adicional incurrido por unidad de exposicin, y
la sensibilidad del proyecto. Dado que la variabilidad es una medida ampliamente
utilizada de riesgo en finanzas y ciencias, el mtodo de fijacin de precios se deriva de
parmetros de riesgo al relacionar la variabilidad en los factores de riesgo a la variacin
de los costos del proyecto. (Appari & Benaroch, 2010)

4. RESULTADOS

El Standish International en el 2013 indicaba que el 43% de los proyectos de software

no se pudieron entregar a tiempo, dentro del presupuesto, y con la funciones
requeridas, mientras que el 18% de los proyectos de software fueron cancelados
(Standish Group International, 2013).

Figura 3: Resultado en proyectos de Software en el 2012

Fuente: CHAOS MANIFESTO 2013, The Standish Group International
Existen factores de alta importancia que afectan de forma general los productos que
se desarrollan en los proyectos informticos, como son el desconocimiento de las
herramientas y lenguajes de programacin empleados, incumplimiento del
cronograma de trabajo por parte de los desarrolladores, uso de las tecnologas de
forma indebida, inexistencia de informacin histrica en el proyecto, necesidad de
mayores recursos de hardware, mal desempeo por parte de los miembros del equipo
de los roles asignados a los mismos, estos factores pueden ocasionar consecuencias
no previstas inicialmente y que por tanto alterarn el buen trmino del proyecto. Estas
sorpresas o eventos que pueden ocasionar daos no son ms que los riesgos. (Infante
et al., 2013)
La gestin de riesgos permite definir en forma estructurada, operacional y
organizacional, una serie de actividades para darle tratamiento a los riesgos de los
proyectos a lo largo de todas las fases de su ciclo de vida de desarrollo de software.
En la mayor parte de los casos, esto se traduce en la creacin de planes tendientes a
impedir que los riesgos se transformen en problemas o a minimizar su probabilidad de
ocurrencia o impacto (Maniasi, Britos, & Diez, 2006)
La preparacin de una evaluacin detalla del riesgo de un proyecto de software es
costoso y consume mucho tiempo, sin embargo en el largo plazo los beneficios que se
obtienen normalmente superan los costos involucrados. Expertos en gestin de
riesgos de software coinciden en que los costos asociados con la toma de algunas
medidas preventivas desde el comienzo son insignificantes en comparacin con los
costos dramticos en los que se puede incurrir cuando se descuidan las tcnicas
adecuadas de gestin de riesgos. (McManus, 2012).
Existen varios modelos de administracin de riesgos y las empresas e su mayora
coinciden en seguir principalmente los pasos especificados en la figura 2.

Identificacin

Control Anlisis

Documentacin y
Comunicacin

Seguimiento Planificacin

Figura 4: Modelo de administracin de Riesgos

Fuente: Autor de acuerdo a la investigacin e informacin publicada.

4.1. Gestin de Riesgos en CCMI

El CMMI (Capability Maturity Model Integrated) se ha convertido en el nuevo estndar
a nivel mundial para la medicin de la calidad de los procesos de desarrollo de software
y presenta como una de sus reas de proceso fundamentales la Administracin de
Riesgos. El propsito de la Gestin de Riesgos (RSKM) es identificar problemas
potenciales antes que presenten, para que las actividades de tratamiento de riesgos
puedan planificarse e invocarse segn sea necesario a lo largo de la vida del producto
o del proyecto para mitigar los impactos adversos sobre la consecucin de objetivos.
La gestin de riesgos se puede dividir en las siguientes partes:
Definir una estrategia de gestin de riesgos.
Identificar y analizar los riesgos.
Tratar los riesgos identificados, incluyendo la implementacin de planes de
mitigacin, segn sea necesario
Las metas y prcticas que especifica CMMI que se deben cumplir son:
Meta 1: Preparar la gestin de riesgos.
Practica 1.1 Determinar las fuentes y las categoras de riesgos.
Practica 1.2 Definir los parmetros de riesgos.
Practica 1.3 Establecer una estrategia de gestin de riesgos.
Meta 2: Identificar y analizar los riesgos.
Practica 2.1 Identificar los riesgos.
Practica 2.2 E valuar, clasificar y priorizar los riesgos.
Meta 3: Mitigar los riesgos.
Practica 3.1 Desarrollar los planes de mitigacin de riesgos.
Practica 3.2 Implementar los planes de mitigacin de riesgos.

Tabla 1: rea de proceso Gestin de Riesgos

Fuente: SEI Administrative Agent,(2009) Spanish Technical Report CMMI V 1 3

El rea de proceso Gestin de riesgos describe una evolucin de estas prcticas

especficas para planificar, prevenir y mitigar los riesgos sistemticamente a fin de
minimizar proactivamente su impacto sobre el proyecto.
Aunque el nfasis principal del rea de proceso Gestin de Riesgos se realiza sobre
el proyecto, estos conceptos tambin pueden aplicarse para gestionar los riesgos de
la organizacin.

4.2. Gestin de Riesgos bajo la metodologa Microsoft Solutions Framework

Microsoft Solutions Framework (MSF) ha desarrollado un proceso para identificar y
valorar ininterrumpidamente los riesgos de un proyecto, dar prioridad a estos riesgos
e implementar las estrategias para tratar estos riesgos de forma proactiva a lo largo
del ciclo de vida del proyecto, tal como se define en el Modelo de procesos de MSF.
Las principales caractersticas de la disciplina de administracin de riesgos de MSF
son las siguientes:
 Carcter global que incluye todos los elementos de un proyecto: personas,
procesos y elementos de tecnologa.
Incorpora un proceso intuitivo, sistemtico y reproducible para la administracin
de riesgos de los proyectos.
Se aplica ininterrumpidamente durante el ciclo de vida de los proyectos.
Su tendencia es proactiva en lugar de reactiva.
Fomenta el aprendizaje individual y colectivo.
Es muy flexible y puede adaptarse a una gran variedad de anlisis de riesgos
cuantitativos y cualitativos.

4.3. Gestin de Riesgos con Rational Unified Process (RUP)

Uno de los objetivos de RUP, metodologa implementada por la empresa Rational
Software, actualmente propiedad de IBM, es asegurar que las expectativas de todas
las partes son sincronizadas y consistentes. Esto es asegurado a travs de
evaluaciones peridicas durante el ciclo de vida del proyecto, y es documentado en el
Reporte de Evaluacin de Status. Este reporte es utilizado para hacer un seguimiento
a informacin acerca de recursos (humano y financiero), mayores riesgos, progreso
tcnico medido a travs de mtricas y resultados de hitos principales. (Romero,
Lovera, & YARINGANO, 2007)
El equipo se junta para crear una lista de todos los posibles riesgos que en algn
momento pudieran afectar al proyecto. Esta lista nace a partir de un anlisis del
proyecto, tanto general como por cada paquete de trabajo, y as localizar las
principales fuentes generadoras de riesgo.
En RUP existen dos tipos de riesgos:
- Directos: el personal tiene cierto control sobre ellos.
- Indirectos: no pueden ser controlados.
Adems se cuenta con los riesgos generados a partir de los recursos del proyecto:
Organizacin
Falta de compromiso del personal hacia el proyecto.
Falta de planeacin y definicin en el proceso de ingeniera de software.
El proyecto es el ms largo antes intentado.
Recursos
Falta de recursos para completar el proyecto.
Limitaciones de presupuesto: el sistema debe ser entregado en un costo fijo o
se va a cancelar.
Los estimados de costos sean inexactos.
Personal
Falta de personal disponible para el proyecto.
El personal no tiene las habilidades y experiencia necesarias.
El personal no cree en el proyecto. -no hay expertos en el rea disponibles.
Tiempo
La agenda no es realista.
No hay tiempo para hacerlo bien.
Otros de los riesgos que pueden aparecer en el proyecto son los tcnicos, dentro de
los cuales se consideran:

Alcance. El xito no puede ser medido. Los requerimientos no son estables ni

entendibles. Los tiempos de desarrollo son inflexibles y limitados.
Tecnolgicos. El xito del proyecto dependa de productos, servicios, tecnologas
nuevos que no hayan sido probados antes.
Dependencias del sistema con otros sistemas externos, y que estos fallen.
Requerimientos de disponibilidad y seguridad inflexibles.
El proyecto es inalcanzable (muy complejo o enorme como para trabajar
apropiadamente).
Dependencia externa. El proyecto depende de proyectos en desarrollo paralelo.
El xito depende de la integracin de herramientas de desarrollo (compiladores,
herramientas de diseo, etc.), tecnologas de implementacin (sistema operativo,
bases de datos, etc.).
RUP propone la construccin de una matriz de respuesta a riesgos la cual contiene la
respuesta que se le dara al riesgo en caso de materializarse, el plan de acciones que
se llevara a cabo en caso de ser activado y la persona responsable del riesgo.
4.4. Gestin de Riesgos con segn las Norma ISO 31000
En noviembre de 2009, la Organizacin Internacional de Normalizacin (ISO) publico
la norma ISO 31000 Gestin de Riesgos la cual ofrece principios y directrices
genricas sobre gestin de riesgos. La norma no es especfica de ninguna industria o
sector y puede ser utilizada por cualquier organizacin pblica o privada y aplicarse a
cualquier tipo de riesgo en una amplia serie de actividades y operaciones. ISO 31000
es la referencia mundial en sistemas de gestin de riesgos
De acuerdo a la norma la gestin de riesgos es considerada como el proceso de
ponderacin de las distintas opciones en base a los resultados de la valoracin de
riesgos. Procesos para aumentar la probabilidad e impacto de las oportunidades y
reducir la probabilidad e impacto de las amenazas. (Purdy, 2010)
El enfoque est estructurado en tres elementos claves para una efectiva gestin de
riesgos:
Los principios de gestin del riesgo
El marco de trabajo (framework) para la gestin del riesgo
El proceso de gestin del riesgo
Los principios bsicos para la gestin del Riesgo son:
- Crear valor
- Est integrada en los procesos de una organizacin
- Forma parte de la toma de decisiones
- Trata explcitamente la incertidumbre
- Es sistemtica, estructurada y adecuada
- Est basada en la mejor informacin disponible
- Est hecha a medida
- Tiene en cuenta factores humanos y culturales
- Es transparente e inclusiva
- Es dinmica, iterativa y sensible al cambio
- Facilita la mejora continua de la organizacin

5. DISCUSIN

Los tericos y muchos profesionales estn de acuerdo en que hay una creciente
necesidad de mtodos ms sistemticos y herramientas para complementar el
conocimiento individual, juicio y experiencia, en relacin con el manejo del riesgo.
Los estndares de la industria pueden ayudar en el momento de determinar cmo
prevenir o mitigar riesgos especficos comnmente encontrados en una industria
particular. Ciertos riesgos pueden ser gestionados o mitigados proactivamente
mediante la revisin de buenas prcticas y las lecciones aprendidas considerando la
prevencin como una de las principales herramientas en nuevos proyectos.
Un reciente estudio de PricewaterhouseCoopers (Pwc) revela que el 75% de los
ejecutivos reporta un incremento de riesgos en la organizacin, eso significa que si
hasta el ao pasado tena 5 riesgos identificados hoy tiene el doble.
Dado lo mencionado anteriormente es importante crear una cultura de concientizacin
del riesgo y las empresas pueden adaptarse de acuerdo a su negocio y a las
caractersticas propias de cada proyecto.
La importancia de la priorizacin de los riesgos se hace necesaria si se quiere tener
un mayor grado de exactitud y eficiencia en un proyecto dado. Sin embargo, no existe
una solucin adecuada para que las organizaciones apliquen de manera sencilla la
priorizacin de riesgos. Para realizarla es necesario determinar el impacto y
probabilidad de ocurrencia para priorizarlos riesgos, y as controlar mejor los
imprevistos del proyecto.
Informtica & Tecnologa Stefanini ha definido un procedimiento para la gestin de
riesgos: PC-PP-03 Gestin de Riesgos y Problemas el cual se ha complementado a
lo largo del proceso de certificacin que la compaa ha llevado a cabo en los ltimos
aos.
En la tabla No. 2 se presentan los riesgos ms comunes que se presentan en proyectos
de software y como Stefanini los considera dentro de su gestin:
NR. RIESGO APLICA OBSERVACIONES
Planeacin: SI NO
1 Manejo ineficiente de recursos X La obtencin de los recursos siempre
es acordes al desarrollo del proyecto.
2 Estimaciones imprecisas X Las estimaciones en gran medida son
a juicio de expertos y la realidad de los
proyectos ha demostrado que las
desviaciones entre lo estimado y lo
ejecutado son considerables.
3 Planeacin inadecuada X Los gerentes de proyecto establecen
cada uno de los planes requeridos:
Plan de comunicacin, Plan de gestin
de la configuracin, entre otros.
4 Problemas de comunicacin X Se realizan seguimientos continuos
para garantizar una comunicacin
constante entre los involucrados en el
proyecto.
5 Personal no preparado X Depende de la disponibilidad de los
adecuadamente para las recursos. En algunas ocasiones los
actividades de la fase recursos no son propios de un nico
proyecto.
6 Mala definicin de entregables X Estos son definidos en conjunto con el
cliente al inicio del proyecto.
7 Gestin contractual no X La responsabilidad de la gestin
apropiada contractual recae en personas distintas
a los ejecutores del proyecto.
8 Deficiencias en la definicin e X Es comn y el riesgo principalmente se
involucramiento de los presenta cuando el cliente no asigna a
interesados del proyecto. las personas indicadas.
9 Discrepancias entre los lderes X Cuando se presentan diferencias en
del proyecto conjunto se hace un anlisis de pros y
contras de cada alternativa y para los
casos que sean decisiones
importantes se sigue un proceso de
toma de decisiones establecido por la
empresa.
Anlisis de requerimientos:

10 Desconocimiento de X Se ha presentado porque en algunos

metodologas y mejores proyectos se debe seguir la
practicas metodologa del cliente que ha
implicado un mayor impacto en tiempo
y costo.
11 Herramientas Case X Las herramientas que actualmente se
inadecuadas manejan son reconocidas en el
mercado.
12 Personal no preparado X Cada vez que un nuevo integrante
adecuadamente para las ingresa al equipo de trabajo del
actividades de la fase proyecto se evala su desempeo y
 resultados de acuerdo al rol que
cumple.
13 El tamao del equipo no es el X Depende de la disponibilidad de
adecuado recursos y la empresa cuenta con un
alto grado de rotacin de personal.
14 Falta de conocimiento de X Los usuarios pueden ser personas que
procesos de negocio no llevan mucho tiempo en la
compaa o no tienen un perfil que
tiene claro lo que necesita el cliente.
15 Los usuarios que participan no X Desde el inicio del proyecto se explica
son los indicados al cliente la importancia de que los
usuarios que participen en el proyecto
sean los indicados.
16 Falta de claridad en la definicin X Como parte del proceso se establece
de requerimientos por parte de que un lder del rea debe ser la
los usuarios persona que realice la aprobacin del
documento de requerimientos con el
fin de corroborar la informacin
entregada por los usuarios.
17 No especificacin de X Como parte de la plantilla del
requerimientos no funcionales documento de requerimientos est
incluida la seccin de Requerimientos
No funcionales.
18 Informacin no real X Como parte del proceso se establece
suministrada por los usuarios que un lder del rea debe ser la
persona que realice la aprobacin del
documento de requerimientos con el
fin de corroborar la informacin
entregada por los usuarios.
Diseo
19 Arquitectura inapropiada X Puede suceder que el cliente ya tiene
establecida esta arquitectura por tal
razn una de las actividades iniciales
es hacer una evaluacin de la misma.
20 Herramientas inapropiadas X Las herramientas que actualmente se
manejan son reconocidas en el
mercado.
21 Diseo lgico pobremente X El diseo lgico es sometido a revisin
definido de pares y aprobacin del cliente.
22 Diseo fsico pobremente X El diseo fsico es sometido a revisin
definido de pares y aprobacin del cliente.
23 Diseo de interfaces X El diseo de interfaces es sometido a
pobremente definido revisin de pares y aprobacin del
cliente.
24 Falta de visin X El lder del proyecto asignado siempre
es una persona con experiencia
comprobada en su rol ya sea en la
misma empresa o en otras.
Desarrollo
25 Lenguaje de desarrollo X Las herramientas que actualmente se
inapropiado manejan son reconocidas en el
mercado.
26 Estndares de documentacin X Se tiene definido estndares y
inapropiados lineamientos de codificacin.
27 Falta de conocimiento del X La empresa promueve capacitaciones
conjunto de herramientas a usar continuas para mitigar este riesgo.
28 Dependencia de una X La empresa cuenta con diversas lneas
herramienta en particular de negocio que garantiza el
conocimiento y experticia en distintas
herramientas.
29 Manejo de liberacin de X Actualmente se est implementando el
versiones inadecuado uso de nuevas herramientas para el
control de versiones que mejoren esta
gestin.
30 Gestin de configuracin X Como parte de la metodologa esta
inadecuada definido el proceso de gestin de la
configuracin y al inicio de cada
proyecto se acuerda con el cliente y se
incluye en el plan de proyecto.
31 Malas especificaciones de X Se programan inspecciones de cdigo
construccin para que el lder o un par del equipo
puedan validar el cumplimiento de los
lineamientos definidos.
Pruebas
32 Criterios de aceptacin X Como parte de la metodologa criterios
inadecuados de aceptacin son definidos en
conjunto con el cliente.
33 Herramientas de pruebas X Las herramientas con las cuales
inadecuadas trabaja actualmente la compaa son
de licenciamiento libre.
34 Metodologa de pruebas X Como parte de la metodologa se
inadecuada establece un plan de pruebas donde se
define todo el proceso de las pruebas
como los tipos de pruebas que se
realiza, el registro de incidentes, entre
otras.
35 No se involucra al usuario en las X Las pruebas de aceptacin las realiza
pruebas de aceptacin el cliente. El equipo del proyecto
realizar una labor de acompaamiento.
36 Falta de soporte interno X Los ambientes pueden ser
compartidos por varios proyectos lo
cual genera inconvenientes.
37 No se realizan pruebas de X Se ha iniciado la implementacin de
stress herramientas que apoyen la ejecucin
de pruebas de stress, la empresa es
consciente de la importancia de
realizarlas.
38 Sobre dependencia de las X No hace parte de los proyectos la
pruebas Beta generacin de una versin beta.
 39 Dependencia de analistas de X Siempre se busca que el equipo de
pruebas por su experiencia trabajo sea el apropiado para el
proyecto considerando que cada
proyecto es nico y la dependencia de
un nico recurso no es lo ms
conveniente.
Implementacin.
40 Problemas de comunicacin X Se realizan seguimientos continuos
para garantizar una comunicacin
constante entre los involucrados en el
proyecto.
41 Falta de planeacin X Estas actividades se definen en
conjunto con el cliente y su
disponibilidad.
42 No hay una definicin de la X La empresa incluye un plan de gestin
estrategia de implementacin del cambio el cual est en proceso de
definicin para determinar su alcance.
43 Falta de capacitacin a los X Siempre se incluye un plan de
usuarios capacitaciones: Tcnica y funcional.
44 Falta de tiempo para la X Antes de iniciar la implementacin se
implementacin reevala el tiempo establecido y si no
es suficiente se acuerda con el cliente
los ajustes necesarios.
45 No se completan las X Se acuerda con el cliente segn el
transferencias entre los grupos proyecto si hace parte del alcance del
mismo o no.
46 Manuales de usuario X La empresa tiene establecidos
deficientes formatos con el contenido de los
manuales y estos son validados por
pares del proyecto.
47 Manuales Tcnicos deficientes X La empresa tiene establecidos
formatos con el contenido de los
manuales y estos son validados por
pares del proyecto
48 No se realizan pruebas en sitio X Se busca garantizar que el ambiente
o son muy deficientes de pruebas que proporciona el cliente
para pruebas de aceptacin sea lo
ms similar posible al ambiente de
produccin.
49 El Soporte posterior a la X En conjunto con el cliente se
implementacin es pobre. establecen Acuerdos de Niveles de
Servicio para estas actividades de
soporte.

El proceso definido por Stefanini para la gestin de riesgos es sistemtico, no se basa

nicamente en una sola metodologa, cubre los pasos de identificacin, clasificacin,
cuantificacin y definicin del plan de respuesta estableciendo probabilidad e impacto
como se presenta a continuacin:
 MA
Probabilidad A X
M
B
MB
MB B M A MA
Impacto
Donde MB= Muy Bajo, B= Bajo, M= Medio, A= Alto, MA= Muy Alto
Tabla No. 3
Fuente: PC-PP-03 Gestin de Riesgos y Problemas Informtica & tecnologa

Los gerentes de proyecto que trabajan en la compaa coinciden que realizar el

seguimiento a los riesgos es una de las tareas que toma mucho tiempo dado la
magnitud de los mismos.
Dado el tamao de los proyectos en donde la cantidad de riesgos es alta, el
seguimiento debe ser constante y considerando la importancia de hacer una medicin
de riesgos se propone hacer una priorizacin de los riesgos con el fin de tener un
mayor control sobre aquello riesgos cuyo impacto es alto considerando el mtodo de
anlisis de probabilidad descrito anteriormente para lo cual se asigna una calificacin
la probabilidad:

Probabilidad Calificacin
Muy Alta 90%
Alta 70%
Moderado 50%
Baja 30%
Muy Baja 10%
No ocurre 0%

Tabla No. 4
Fuente: Autor basada enPC-PP-03 Gestin de Riesgos y Problemas Informtica &
tecnologa

Y una escala numrica al impacto como se muestra a continuacin:

 Escala relativa o
Descripcin
numrica
Muy Bajo (1) Insignificante incremento en costo, alcance, calidad

Bajo (2) Incremento en el costo <5% en costo, alcance, calidad

Moderado (3) Incremento en el costo 5% - 10% en costo, alcance, calidad

Incremento en el costo 10% - 20% en costo, alcance,

Alto (4)
calidad

Muy Alto (5) Incremento en el costo >20% en costo, alcance, calidad

Tabla No. 5
Fuente: Autor basada enPC-PP-03 Gestin de Riesgos y Problemas Informtica &
tecnologa

Para realizar la priorizacin de los riesgos se toma la informacin obtenida para la

valoracin del impacto y la probabilidad de ocurrencia, realizando el siguiente calculo:
Prioridad = Probabilidad *Impacto
Como referencia se puede utilizar la siguiente definicin para la priorizacin, la cual
puede ser modificada para un proyecto en particular:
Prioridad Lmite Inferior Lmite Superior
Muy Baja 0,01 0,03
Baja 0,04 0,09
Media 0,1 0,25
Alta 0,26 0,49
Muy Alta 0,5 0,81

Tabla No. 6
Fuente: Autor basada enPC-PP-03 Gestin de Riesgos y Problemas Informtica &
tecnologa
Los riesgos clasificados con una prioridad muy alta y alta requieren la definicin de un
plan de contingencia y mitigacin. Para los riesgos de prioridad media deber
realizarse una valoracin y determinar si se establece o no un plan de contingencia.
En el caso de los riesgos de prioridad baja aunque no se definan estos planes deben
ser tenidos en cuenta en los seguimientos para detectar cambios en su probabilidad
de ocurrencia e impacto.
Complementar la metodologa actual de la compaa con esta priorizacin permitir
realizar otros anlisis o acciones posteriores, evaluando y combinando su probabilidad
de ocurrencia y su impacto.

6. CONCLUSIONES Y RECOMENDACIONES

El Proceso de Gestin de Riesgos de Proyectos describe las necesidades de

identificar, evaluar, documentar y administrar los riesgos de un proyecto que
pueden o no tener un impacto en los costos, tiempos, recursos y el plan del
proyecto.
La aplicacin de la metodologa de gestin de riesgos en todas las empresas
permitir que se preparen proactivamente contra las amenazas que afectan el
xito del proyecto y por ende la rentabilidad.
La poltica de riesgos de la empresa nace desde la intencin de la gerencia y la
participacin de todos los integrantes de la organizacin basados en procesos de
concienciacin y concientizacin sobre el manejo del riesgo.
Informtica & Tecnologa Stefanini es una empresa consiente de la necesidad de
un mejoramiento de procesos para la gestin de proyectos, por ello se preocupa
de manera sistemtica y permanente en adelantar un excelente proceso de gestin
de riesgos
La informacin obtenida mediante la aplicacin de metodologas para adelantar la
gestin de riesgos permite a cualquier empresa hacer un adecuado proceso de
toma de decisiones favorable a los objetivos de la empresa
Es recomendable que la compaa implemente un sistema para el registro de toda
la gestin de riesgos, que permita generar estadsticas de los ms comunes o los
que ms impactan dado que se evidencia que algunos son reiterativos, esto
tambin permitir cuantificar y valorar el riesgo ms acertadamente con el fin de
evitar sobrecostos en los que se debe incurrir durante la mitigacin de los mismos.
Tambin es recomendable que la compaa incluya dentro del proceso la
priorizacin de los riesgos de acuerdo al impacto y probabilidad establecidos con
el fin de controlar en mayor medida aquellos de gran incertidumbre y que puedan
afectar significativamente el avance del proyecto.

7. REFERENCIAS BIBLIOGRFICAS

Appari, A., & Benaroch, M. (2010). Monetary pricing of software development risks: A
method and empirical illustration. Journal of Systems and Software, 83(11),
2098-2107.
De Bakker, K., Boonstra, A., & Wortmann, H. (2010). Does risk management contribute
to IT project success? A meta-analysis of empirical evidence. International
Journal of Project Management, 28(5), 493-503.
Infante, L. M. I., Rab, D. E. A., & Daz, M. M. (2013). Exposicin a los Riesgos en un
proyecto de Software: aplicacin del modelo Mogeri. Serie Cientfica, 6(6).
Islam, S. (2009). Software development risk management model: a goal driven
approach. Paper presented at the Proceedings of the doctoral symposium for
ESEC/FSE on Doctoral symposium.
Maniasi, S., Britos, M. I. P., & Diez, M. I. E. (2006). Identificacin de Riesgos de
Proyectos de Software en Base a Taxonomas. Tesis de Magister en Ingeniera
del Software. Escuela de Postgrado. ITBA.
McManus, J. (2012). Risk management in software development projects: Routledge.
Padilla, N. Y. L. (2014). Ranking mundial en certificaciones CMMI-DEV ver. 1.3 ao
2013. Revista Iberoamericana de Produccin Acadmica y Gestin Educativa,
1(1).
Purdy, G. (2010). ISO 31000: 2009setting a new standard for risk management. Risk
analysis, 30(6), 881-886.
Romero, A., Lovera, D., & YARINGANO, S. (2007). Gestin de riesgos con CMMI, RUP
e ISO en Ingeniera de Software Minero. Rev. Inst. investig. Fac. minas metal
cienc. geogr, 10(19), 55-61.
SEI Administrative Agent,(2009) Spanish Technical Report CMMI V 1 3
Standish Group International, Inc., (2013).Third Quarter Research Report.