Metodologia Agiles

1. METODOLOGÍAS PARA LA GESTIÓN DE RIESGOS EN PROYECTOS DE
SOFTWARE Y SU ADAPTACIÓN EN STEFANINI
AUTOR:
RUTH ALEXANDRA FAJARDO BUITRAGO
UNIVERSIDAD MILITAR NUEVA GRANADA
ESPECIALIZACIÓN EN GERENCIA INTEGRAL DE PROYECTOS
ARTICULO DE GRADO
BOGOTA, AGOSTO DE 2014

2. METODOLOGÍAS PARA LA GESTIÓN DE RIESGOS EN PROYECTOS DE
SOFTWARE Y SU ADAPTACIÓN 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 ejecución. 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 comprensión de la naturaleza de los distintos riesgos
y su relación con el rendimiento del proyecto es cada vez más importante.
Este artículo recopila las metodologías más conocidas para la gestión de riesgos,
validando la existencia de métodos cuantitativos y cualitativos, estadísticos,
matemáticos, sistemáticos que guíen todo este proceso y evaluándolos en función de
la implementación del más acertado para una empresa de desarrollo de Software
como Informática & Tecnología Stefanini, en donde sus gerentes de proyectos
reconocen constantemente la necesidad de mejorar la manera de hacer dicha gestión,
como parte de las lecciones aprendidas.
Palabras clave: Gestión de Proyectos de Software, Riesgo, Gestión de Riesgos,
Métodos sistemáticos, 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,

3. 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 Informática & Tecnología 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.
INTRODUCCIÓN
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 técnicos y no técnicos del
desarrollo y tener control de ellos desde las primeras etapas del desarrollo es crucial
para lograr un proyecto exitoso. Por lo tanto, la gestión del riesgo de desarrollo de
software está siendo reconocido como la mejor práctica 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 día, por ello
se requiere un esfuerzo superior de gestión de riesgos para dirigir con habilidad los
proyectos de desarrollo del mismo.
En la comunidad académica se genera un interrogante: ¿La gestión de riesgos
contribuye al desarrollo exitoso de los proyectos de TI? .En los últimos 10 años, mucho
se ha conocido sobre las causas que hacen que los proyectos de TI fallen, sin
embargo, todavía hay muy poca evidencia empírica de que este conocimiento se utiliza
realmente como apoyo a la gestión de riesgos en los proyectos de TI. (De Bakker,
Boonstra, & Wortmann, 2010)
El análisis de diferentes investigaciones realizadas en la Universidad de las Ciencias
Informáticas (UCI) ofrece como resultado que, el desarrollo de la Gestión de Riesgos
(GR) en muchos de los proyectos productivos es ineficiente, pues estos no tienen en
cuenta alguna de las metodologías o modelos establecidos y reconocidos
mundialmente para realizar este proceso. (Infante, Rabí, & Díaz, 2013)
Informática & Tecnología Stefanini S.A., se ha consolidado como una empresa de
servicios de tecnología con énfasis en el desarrollo, soporte y administración de
sistemas de información en Colombia. Ellos entienden la calidad en el desarrollo de
software como el conjunto de características asociadas al producto final pero logrado
durante su proceso, por tal razón, al igual que muchas empresas del sector, han
implementado un sistema de calidad evaluado con el modelo CMMI DEV vs 1.3,

4. otorgado por el Software Engineering Institute – SEI y la universidad Carnegie Mellon,
el cual proporciona un conjunto completo e integrado de guías para desarrollar
productos y servicios (Padilla, 2014).
Durante este proceso de evaluación y como parte de las oportunidades de mejora
sugeridas por la empresa evaluadora, se confirma la necesidad de realizar mejoras
sustanciales en la definición de estrategias para gestión de riesgos, por tal razón se
requiere conocer y validar cuales son las metodologías existentes e identificar cual es
la más adecuada.
2. MATERIALES Y MÉTODOS
La investigación desarrollada es de tipo exploratoria considerando que aunque la
importancia de gestionar los riesgos en proyectos de Software es conocida, no lo son
las metodologías para realizar esta labor y no se conoce como las empresas en
Colombia realizan esta gestión. Por tal razón fuentes de información trabajadas son:
 La fuente primaria de la investigación son las entrevistas a los gerentes de
proyectos que trabajan en Informática & Tecnología Stefanini para establecer de
qué manera realizan la identificación y gestión 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 políticas y procedimientos a seguir en todos
los proyectos.
 La segunda fuente ha sido la búsqueda en Internet de publicaciones, referencia de
libros, artículos y metodologías en las cuales se pueda evidenciar resultados de
proyectos que incluyeron el uso o no de metodologías en la gestión de riesgos
detectando rasgos comunes, sugerencias y guías para su implementación los
cuales puedan ser considerados como experiencia para la adaptación en
Informática & Tecnología Stefanini
3. MARCO TEÓRICO
3.1. Definición de Riesgo
Según el PMBOOK, 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.
3.2. Que es la gestión de Riesgos

5. Comprende todas las actividades que se realizan para reducir las incertidumbres
asociadas con ciertas tareas, o eventos. En el contexto de los proyectos, la gestión del
riesgo reduce los impactos de los eventos no deseados en el proyecto. La gestión de
riesgos en cualquier proyecto requiere la realización de las actividades del proceso de
toma de decisiones.
3.3. Categorización de Riesgos en proyectos de Software
Los riesgos pueden ser agrupados en 3 categorías:
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 gestión y/o de presupuesto.
3.3.2. Riesgos Técnicos:
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 legislación.
3.4. Mediciones de Riesgo
El desarrollo de una gestión de riesgos eficaz y adecuada depende de la comprensión
de dos componentes básicos: 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 gestión de
riesgos.
3.5. Evaluación de Riesgos en Proyectos de Software
Los avances en las técnicas de gestión del riesgo han permito a algunas
organizaciones de software implementarlas y fortalecer su gestión de riesgo. Técnicas
de modelado y métodos de pensamiento como lluvia de ideas son las más usadas para
dicha gestión. Estas técnicas se utilizan para comprender el riesgo e incluyen técnicas
cualitativas, semi-cuantitativas y cuantitativas. Estos métodos se aplican con
frecuencia en el lugar de trabajo por si mismos o en conjunto con otras técnicas.
3.5.1 Métodos Cualitativos.

6. Se caracterizan por no recurrir a cálculos numéricos. Pueden ser métodos
comparativos y métodos generalizados.
- Lluvia de ideas
- Análisis SWOT también conocido como análisis DOFA
- Mapas
- Listas de verificación y cuestionarios
- Entrevistas con pares
3.5.2. Métodos Cuantitativos
Introducen una valoración cuantitativa respecto a las frecuencias de ocurrencia de un
determinado suceso y se denominan métodos para la determinación de frecuencias, o
bien se caracterizan por recurrir a una clasificación de las áreas de una instalación con
base a una serie de índices que cuantifican daños: índices de riesgo.
 Modelos Simbólicos
Hacen uso de enunciados matemáticos y estadísticos para presentar el problema
 Análisis de probabilidad
El cálculo de riesgo requiere el uso de datos de probabilidad la cual es calculada con
base a información histórica y la experiencia. Dado que hay incertidumbre (definida
esta como ausencia de información) es importante que todos los riesgos que afectan
el desarrollo del proyecto y por ende el proceso de toma de decisiones sean evaluados.
Este método se basa en eventos y el cálculo 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 función del evento del cual depende.
 Análisis de consecuencias
Consiste en la realización de una evaluación inicial de los hechos y los posibles
problemas y/o causas para posteriormente analizar las consecuencias.
Evento
Análisis
Problema Causas
Consecuencia 1
Consecuencia 2
Consecuencia 3

7. Figura 1: Ilustración de la técnica de análisis de consecuencias
Fuente: McManus, J. (2012). Risk management in software development projects:
Routledge.
 Arboles de decisión
Ofrecen una es estructura específica para la exploración de alternativas de acción para
resolver situaciones complejas. Los pasos para construir un árbol de decisión son:
- Describir y comprender el problema
- Identificar todas las opciones posibles
- Identificar todos los posibles resultados derivados de cada opción.
- Plasmarlos en estructura de árbol (Nodos de decisión, 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
Figura 2: Ilustración arboles de decisión
Fuente: McManus, J. (2012). Risk management in software development projects:
Routledge.
 Análisis de Monte Carlo
Es un método que permite incorporar detalles sobre la incertidumbre. Se inicia
seleccionando las variables inciertas definiendo un rango de valores posibles con una
distribución de probabilidad la cual se determina de acuerdo a las condiciones que
rodean a cada variable. El tipo de distribución de probabilidad puede ser normal,
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

8. triangular, uniforme o logarítmica, sin desconocer que existen otras distribuciones de
probabilidad las cuales se emplean con base al análisis que se requiera.
Con este método los gerentes pueden por ejemplo determinar la probabilidad que una
actividad se encuentre en la ruta crítica.
3.6. Monetización 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 método de valoración del riesgo que estima dos parámetros para
cada factor de riesgo individual: costo adicional incurrido por unidad de exposición, y
la sensibilidad del proyecto. Dado que la variabilidad es una medida ampliamente
utilizada de riesgo en finanzas y ciencias, el método de fijación de precios se deriva de
parámetros de riesgo al relacionar la variabilidad en los factores de riesgo a la variación
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 informáticos, como son el desconocimiento de las
herramientas y lenguajes de programación empleados, incumplimiento del
cronograma de trabajo por parte de los desarrolladores, uso de las tecnologías de
forma indebida, inexistencia de información histórica en el proyecto, necesidad de
mayores recursos de hardware, mal desempeño por parte de los miembros del equipo
de los roles asignados a los mismos, estos factores pueden ocasionar consecuencias

9. no previstas inicialmente y que por tanto alterarán el buen término del proyecto. Estas
sorpresas o eventos que pueden ocasionar daños no son más que los riesgos. (Infante
et al., 2013)
La gestión 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 creación 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 preparación de una evaluación 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 gestión de
riesgos de software coinciden en que los costos asociados con la toma de algunas
medidas preventivas desde el comienzo son insignificantes en comparación con los
costos dramáticos en los que se puede incurrir cuando se descuidan las técnicas
adecuadas de gestión de riesgos. (McManus, 2012).
Existen varios modelos de administración de riesgos y las empresas e su mayoría
coinciden en seguir principalmente los pasos especificados en la figura 2.
Figura 4: Modelo de administración de Riesgos
Fuente: Autor de acuerdo a la investigación e información publicada.
4.1. Gestión de Riesgos en CCMI
El CMMI (Capability Maturity Model Integrated) se ha convertido en el nuevo estándar
a nivel mundial para la medición de la calidad de los procesos de desarrollo de software
Documentación y
Comunicación
Identificación
Análisis
PlanificaciónSeguimiento
Control

10. y presenta como una de sus Áreas de proceso fundamentales la Administración de
Riesgos. El propósito de la Gestión de Riesgos (RSKM) es identificar problemas
potenciales antes que presenten, para que las actividades de tratamiento de riesgos
puedan planificarse e invocarse según sea necesario a lo largo de la vida del producto
o del proyecto para mitigar los impactos adversos sobre la consecución de objetivos.
La gestión de riesgos se puede dividir en las siguientes partes:
 Definir una estrategia de gestión de riesgos.
 Identificar y analizar los riesgos.
 Tratar los riesgos identificados, incluyendo la implementación de planes de
mitigación, según sea necesario
Las metas y prácticas que especifica CMMI que se deben cumplir son:
Tabla 1: Área de proceso Gestión de Riesgos
Fuente: SEI Administrative Agent,(2009) Spanish Technical Report CMMI V 1 3
El área de proceso Gestión de riesgos describe una evolución de estas prácticas
específicas para planificar, prevenir y mitigar los riesgos sistemáticamente a fin de
minimizar proactivamente su impacto sobre el proyecto.
Aunque el énfasis principal del área de proceso Gestión de Riesgos se realiza sobre
el proyecto, estos conceptos también pueden aplicarse para gestionar los riesgos de
la organización.
4.2. Gestión de Riesgos bajo la metodología 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 características de la disciplina de administración de riesgos de MSF
son las siguientes:
Meta 1: Preparar la gestión de riesgos.
Practica 1.1 Determinar las fuentes y las categorías de riesgos.
Practica 1.2 Definir los parámetros de riesgos.
Practica 1.3 Establecer una estrategia de gestión 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 mitigación de riesgos.
Practica 3.2 Implementar los planes de mitigación de riesgos.

11.  Carácter global que incluye todos los elementos de un proyecto: personas,
procesos y elementos de tecnología.
 Incorpora un proceso intuitivo, sistemático y reproducible para la administración
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 análisis de riesgos
cuantitativos y cualitativos.
4.3. Gestión de Riesgos con Rational Unified Process (RUP)
Uno de los objetivos de RUP, metodología 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 través de
evaluaciones periódicas durante el ciclo de vida del proyecto, y es documentado en el
Reporte de Evaluación de Status. Este reporte es utilizado para hacer un seguimiento
a información acerca de recursos (humano y financiero), mayores riesgos, progreso
técnico medido a través de métricas y resultados de hitos principales. (Romero,
Lovera, & YARINGANO, 2007)
El equipo se junta para crear una lista de todos los posibles riesgos que en algún
momento pudieran afectar al proyecto. Esta lista nace a partir de un análisis 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.
Además se cuenta con los riesgos generados a partir de los recursos del proyecto:
Organización
 Falta de compromiso del personal hacia el proyecto.
 Falta de planeación y definición en el proceso de ingeniería de software.
 El proyecto es el más 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.

12. Tiempo
 La agenda no es realista.
 No hay tiempo para hacerlo “bien”.
Otros de los riesgos que pueden aparecer en el proyecto son los técnicos, 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.
Tecnológicos. El éxito del proyecto dependa de productos, servicios, tecnologías
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 integración de herramientas de desarrollo (compiladores,
herramientas de diseño, etc.), tecnologías de implementación (sistema operativo,
bases de datos, etc.).
RUP propone la construcción de una matriz de respuesta a riesgos la cual contiene la
respuesta que se le daría al riesgo en caso de materializarse, el plan de acciones que
se llevaría a cabo en caso de ser activado y la persona responsable del riesgo.
4.4. Gestión de Riesgos con según las Norma ISO 31000
En noviembre de 2009, la Organización Internacional de Normalización (ISO) publico
la norma ISO 31000 Gestión de Riesgos la cual ofrece principios y directrices
genéricas sobre gestión de riesgos. La norma no es específica de ninguna industria o
sector y puede ser utilizada por cualquier organización pública 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 gestión de riesgos
De acuerdo a la norma la gestión de riesgos es considerada como el proceso de
ponderación de las distintas opciones en base a los resultados de la valoración 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 gestión de
riesgos:
 Los principios de gestión del riesgo
 El marco de trabajo (framework) para la gestión del riesgo
 El proceso de gestión del riesgo

13. Los principios básicos para la gestión del Riesgo son:
- Crear valor
- Está integrada en los procesos de una organización
- Forma parte de la toma de decisiones
- Trata explícitamente la incertidumbre
- Es sistemática, estructurada y adecuada
- Está basada en la mejor información disponible
- Está hecha a medida
- Tiene en cuenta factores humanos y culturales
- Es transparente e inclusiva
- Es dinámica, iterativa y sensible al cambio
- Facilita la mejora continua de la organización
5. DISCUSIÓN
Los teóricos y muchos profesionales están de acuerdo en que hay una creciente
necesidad de métodos más sistemáticos y herramientas para complementar el
conocimiento individual, juicio y experiencia, en relación con el manejo del riesgo.
Los estándares de la industria pueden ayudar en el momento de determinar cómo
prevenir o mitigar riesgos específicos comúnmente encontrados en una industria
particular. Ciertos riesgos pueden ser gestionados o mitigados proactivamente
mediante la revisión de buenas prácticas y las lecciones aprendidas considerando la
prevención 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 organización, eso significa que si
hasta el año pasado tenía 5 riesgos identificados hoy tiene el doble.
Dado lo mencionado anteriormente es importante crear una cultura de concientización
del riesgo y las empresas pueden adaptarse de acuerdo a su negocio y a las
características propias de cada proyecto.
La importancia de la priorización 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 solución adecuada para que las organizaciones apliquen de manera sencilla la
priorización de riesgos. Para realizarla es necesario determinar el impacto y
probabilidad de ocurrencia para priorizarlos riesgos, y así controlar mejor los
imprevistos del proyecto.
Informática & Tecnología Stefanini ha definido un procedimiento para la gestión de
riesgos: PC-PP-03 Gestión de Riesgos y Problemas el cual se ha complementado a
lo largo del proceso de certificación que la compañía ha llevado a cabo en los últimos
años.
En la tabla No. 2 se presentan los riesgos más comunes que se presentan en proyectos
de software y como Stefanini los considera dentro de su gestión:

14. NR. RIESGO APLICA OBSERVACIONES
Planeación: SI NO
1 Manejo ineficiente de recursos X La obtención 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 Planeación inadecuada X Los gerentes de proyecto establecen
cada uno de los planes requeridos:
Plan de comunicación, Plan de gestión
de la configuración, entre otros.
4 Problemas de comunicación X Se realizan seguimientos continuos
para garantizar una comunicación
constante entre los involucrados en el
proyecto.
5 Personal no preparado
adecuadamente para las
actividades de la fase
X Depende de la disponibilidad de los
recursos. En algunas ocasiones los
recursos no son propios de un único
proyecto.
6 Mala definición de entregables X Estos son definidos en conjunto con el
cliente al inicio del proyecto.
7 Gestión contractual no
apropiada
X La responsabilidad de la gestión
contractual recae en personas distintas
a los ejecutores del proyecto.
8 Deficiencias en la definición e
involucramiento de los
interesados del proyecto.
X Es común y el riesgo principalmente se
presenta cuando el cliente no asigna a
las personas indicadas.
9 Discrepancias entre los líderes
del proyecto
X Cuando se presentan diferencias en
conjunto se hace un análisis 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.
Análisis de requerimientos:
10 Desconocimiento de
metodologías y mejores
practicas
X Se ha presentado porque en algunos
proyectos se debe seguir la
metodología del cliente que ha
implicado un mayor impacto en tiempo
y costo.
11 Herramientas Case
inadecuadas
X Las herramientas que actualmente se
manejan son reconocidas en el
mercado.
12 Personal no preparado
adecuadamente para las
actividades de la fase
X Cada vez que un nuevo integrante
ingresa al equipo de trabajo del
proyecto se evalúa su desempeño y

15. resultados de acuerdo al rol que
cumple.
13 El tamaño del equipo no es el
adecuado
X Depende de la disponibilidad de
recursos y la empresa cuenta con un
alto grado de rotación de personal.
14 Falta de conocimiento de
procesos de negocio
X Los usuarios pueden ser personas que
no llevan mucho tiempo en la
compañía o no tienen un perfil que
tiene claro lo que necesita el cliente.
15 Los usuarios que participan no
son los indicados
X Desde el inicio del proyecto se explica
al cliente la importancia de que los
usuarios que participen en el proyecto
sean los indicados.
16 Falta de claridad en la definición
de requerimientos por parte de
los usuarios
X Como parte del proceso se establece
que un líder del área debe ser la
persona que realice la aprobación del
documento de requerimientos con el
fin de corroborar la información
entregada por los usuarios.
17 No especificación de
requerimientos no funcionales
X Como parte de la plantilla del
documento de requerimientos está
incluida la sección de Requerimientos
No funcionales.
18 Información no real
suministrada por los usuarios
X Como parte del proceso se establece
que un líder del área debe ser la
persona que realice la aprobación del
documento de requerimientos con el
fin de corroborar la información
entregada por los usuarios.
Diseño
19 Arquitectura inapropiada X Puede suceder que el cliente ya tiene
establecida esta arquitectura por tal
razón una de las actividades iniciales
es hacer una evaluación de la misma.
20 Herramientas inapropiadas X Las herramientas que actualmente se
manejan son reconocidas en el
mercado.
21 Diseño lógico pobremente
definido
X El diseño lógico es sometido a revisión
de pares y aprobación del cliente.
22 Diseño físico pobremente
definido
X El diseño físico es sometido a revisión
de pares y aprobación del cliente.
23 Diseño de interfaces
pobremente definido
X El diseño de interfaces es sometido a
revisión de pares y aprobación del
cliente.
24 Falta de visión X El líder del proyecto asignado siempre
es una persona con experiencia
comprobada en su rol ya sea en la
misma empresa o en otras.
Desarrollo

16. 25 Lenguaje de desarrollo
inapropiado
X Las herramientas que actualmente se
manejan son reconocidas en el
mercado.
26 Estándares de documentación
inapropiados
X Se tiene definido estándares y
lineamientos de codificación.
27 Falta de conocimiento del
conjunto de herramientas a usar
X La empresa promueve capacitaciones
continuas para mitigar este riesgo.
28 Dependencia de una
herramienta en particular
X La empresa cuenta con diversas líneas
de negocio que garantiza el
conocimiento y experticia en distintas
herramientas.
29 Manejo de liberación de
versiones inadecuado
X Actualmente se está implementando el
uso de nuevas herramientas para el
control de versiones que mejoren esta
gestión.
30 Gestión de configuración
inadecuada
X Como parte de la metodología esta
definido el proceso de gestión de la
configuración y al inicio de cada
proyecto se acuerda con el cliente y se
incluye en el plan de proyecto.
31 Malas especificaciones de
construcción
X Se programan inspecciones de código
para que el líder o un par del equipo
puedan validar el cumplimiento de los
lineamientos definidos.
Pruebas
32 Criterios de aceptación
inadecuados
X Como parte de la metodología criterios
de aceptación son definidos en
conjunto con el cliente.
33 Herramientas de pruebas
inadecuadas
X Las herramientas con las cuales
trabaja actualmente la compañía son
de licenciamiento libre.
34 Metodología de pruebas
inadecuada
X Como parte de la metodología se
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
pruebas de aceptación
X Las pruebas de aceptación las realiza
el cliente. El equipo del proyecto
realizar una labor de acompañamiento.
36 Falta de soporte interno X Los ambientes pueden ser
compartidos por varios proyectos lo
cual genera inconvenientes.
37 No se realizan pruebas de
stress
X Se ha iniciado la implementación de
herramientas que apoyen la ejecución
de pruebas de stress, la empresa es
consciente de la importancia de
realizarlas.
38 Sobre dependencia de las
pruebas Beta
X No hace parte de los proyectos la
generación de una versión beta.

17. 39 Dependencia de analistas de
pruebas por su experiencia
X Siempre se busca que el equipo de
trabajo sea el apropiado para el
proyecto considerando que cada
proyecto es único y la dependencia de
un único recurso no es lo más
conveniente.
Implementación.
40 Problemas de comunicación X Se realizan seguimientos continuos
para garantizar una comunicación
constante entre los involucrados en el
proyecto.
41 Falta de planeación X Estas actividades se definen en
conjunto con el cliente y su
disponibilidad.
42 No hay una definición de la
estrategia de implementación
X La empresa incluye un plan de gestión
del cambio el cual está en proceso de
definición para determinar su alcance.
43 Falta de capacitación a los
usuarios
X Siempre se incluye un plan de
capacitaciones: Técnica y funcional.
44 Falta de tiempo para la
implementación
X Antes de iniciar la implementación se
reevalúa el tiempo establecido y si no
es suficiente se acuerda con el cliente
los ajustes necesarios.
45 No se completan las
transferencias entre los grupos
X Se acuerda con el cliente según el
proyecto si hace parte del alcance del
mismo o no.
46 Manuales de usuario
deficientes
X La empresa tiene establecidos
formatos con el contenido de los
manuales y estos son validados por
pares del proyecto.
47 Manuales Técnicos 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
o son muy deficientes
X Se busca garantizar que el ambiente
de pruebas que proporciona el cliente
para pruebas de aceptación sea lo
más similar posible al ambiente de
producción.
49 El Soporte posterior a la
implementación es pobre.
X En conjunto con el cliente se
establecen Acuerdos de Niveles de
Servicio para estas actividades de
soporte.
El proceso definido por Stefanini para la gestión de riesgos es sistemático, no se basa
únicamente en una sola metodología, cubre los pasos de identificación, clasificación,
cuantificación y definición del plan de respuesta estableciendo probabilidad e impacto
como se presenta a continuación:

18. Probabilidad
MA
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 Gestión de Riesgos y Problemas Informática & tecnología
Los gerentes de proyecto que trabajan en la compañía 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 tamaño de los proyectos en donde la cantidad de riesgos es alta, el
seguimiento debe ser constante y considerando la importancia de hacer una medición
de riesgos se propone hacer una priorización de los riesgos con el fin de tener un
mayor control sobre aquello riesgos cuyo impacto es alto considerando el método de
análisis de probabilidad descrito anteriormente para lo cual se asigna una calificación
la probabilidad:
Probabilidad Calificación
Muy Alta 90%
Alta 70%
Moderado 50%
Baja 30%
Muy Baja 10%
No ocurre 0%
Tabla No. 4
Fuente: Autor basada enPC-PP-03 Gestión de Riesgos y Problemas Informática &
tecnología
Y una escala numérica al impacto como se muestra a continuación:

19. Escala relativa o
numérica
Descripción
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
Alto (4)
Incremento en el costo 10% - 20% en costo, alcance,
calidad
Muy Alto (5) Incremento en el costo >20% en costo, alcance, calidad
Tabla No. 5
Fuente: Autor basada enPC-PP-03 Gestión de Riesgos y Problemas Informática &
tecnología
Para realizar la priorización de los riesgos se toma la información obtenida para la
valoración del impacto y la probabilidad de ocurrencia, realizando el siguiente calculo:
Prioridad = Probabilidad *Impacto
Como referencia se puede utilizar la siguiente definición para la priorización, la cual
puede ser modificada para un proyecto en particular:
Prioridad Límite Inferior Límite 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 Gestión de Riesgos y Problemas Informática &
tecnología
Los riesgos clasificados con una prioridad muy alta y alta requieren la definición de un
plan de contingencia y mitigación. Para los riesgos de prioridad media deberá
realizarse una valoración 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.

20. Complementar la metodología actual de la compañía con esta priorización permitirá
realizar otros análisis o acciones posteriores, evaluando y combinando su probabilidad
de ocurrencia y su impacto.
6. CONCLUSIONES Y RECOMENDACIONES
El Proceso de Gestión 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 aplicación de la metodología de gestión 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 política de riesgos de la empresa nace desde la intención de la gerencia y la
participación de todos los integrantes de la organización basados en procesos de
concienciación y concientización sobre el manejo del riesgo.
Informática & Tecnología Stefanini es una empresa consiente de la necesidad de
un mejoramiento de procesos para la gestión de proyectos, por ello se preocupa
de manera sistemática y permanente en adelantar un excelente proceso de gestión
de riesgos
La información obtenida mediante la aplicación de metodologías para adelantar la
gestión 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 compañía implemente un sistema para el registro de toda
la gestión de riesgos, que permita generar estadísticas de los más comunes o los
que más impactan dado que se evidencia que algunos son reiterativos, esto
también permitirá cuantificar y valorar el riesgo más acertadamente con el fin de
evitar sobrecostos en los que se debe incurrir durante la mitigación de los mismos.
También es recomendable que la compañía incluya dentro del proceso la
priorización 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 BIBLIOGRÁFICAS
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.

21. 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., & Díaz, M. M. (2013). Exposición a los Riesgos en un
proyecto de Software: aplicación del modelo Mogeri. Serie Científica, 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). Identificación de Riesgos de
Proyectos de Software en Base a Taxonomías. Tesis de Magister en Ingeniería
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 año
2013. Revista Iberoamericana de Producción Académica y Gestión Educativa,
1(1).
Purdy, G. (2010). ISO 31000: 2009—setting a new standard for risk management. Risk
analysis, 30(6), 881-886.
Romero, A., Lovera, D., & YARINGANO, S. (2007). Gestión de riesgos con CMMI, RUP
e ISO en Ingeniería 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.