Proceso para gestionar riesgos en proyectos de desarrollo de software

Process to manage risks in software development project

Osiris Pérez Moya ^1*, Yeleny Zulueta Véliz ²

¹ Facultad 1. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP.: 19370. *E-mail: operez@uci.cu
² Facultad 6. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP.: 19370 ]]>  

RESUMEN

Se propone un proceso para gestionar riesgos en proyectos de desarrollo de software a partir de los enfoques planteados por SEI 2006 y las descripciones de PMI 2008. El proceso propuesto incluye la descripción de las técnicas aplicables, así como de los roles que intervienen y los subprocesos planificación de la gestión de riesgos, identificación y análisis de los riesgos, definición y aplicación de acciones para la resolución de eventualidades, comunicación y control de los riesgos y, evaluación del proceso de gestión de riesgos, que conforman la propuesta. Se propone además la utilización de la técnica de análisis lingüístico virtual de riesgos en el proceso. La utilización del método de expertos Delphi para el refinamiento de la propuesta mostró que el 84,8% de los participantes están de acuerdo con que el proceso para gestionar riesgos en los proyectos de desarrollo de software del Centro de Informatización Universitaria es muy adecuado y el 15,2%, afirma que es bastante adecuado. Su aplicación en proyectos reales demuestra que se puede reducir en más de un 50% la exposición a los riesgos.

Palabras clave: análisis lingüístico virtual, gestión de riesgos, proyectos, riesgos.

ABSTRACT

It proposeS a process to manage risks in software development projects from the approaches presented by SEI 2006 and descriptions of PMI 2008. The proposed process includes a description of the techniques applied, and of the roles involved and thread management planning, risk identification and risk analysis, definition and implementation of actions to resolve contingencies, communication and control and risks, evaluation of risk management process. It also proposes the use of THE virtual linguistic analysis technique in the process of risk.the use of the Delphi expert method for THE refinement of the proposal showed that 84.8% of participants agree that the process for managing risks in software development projects the University Computerization Centre (CENIA, for its acronym in spanish) is very appropriate and 15.2% said that it is quite APPROPRIATE. Its application in real projects shows that the exposure to risks can be reduced more than 50%..

Key words: projects, risks, risk management, virtual linguistic analysis.

Para el desarrollo de software se organizan proyectos, los cuales son guiados por objetivos definidos entre el cliente y el equipo de trabajo. Estos proyectos tienen gran impacto y significación económica, política y social. En ellos siempre existe la posibilidad de que un contratiempo pueda presentarse y produzca desviaciones en los objetivos pactados. Para gestionar un proyecto de desarrollo de software con éxito, debe comprenderse qué puede ir mal y cómo hacerlo bien (Pressman, 2010; Pressman y Maier, 2005).

Según el informe The Chaos Report¹ (2011) del Standish Group², aproximadamente el 37% de los proyectos que se inician son completados con el alcance esperado, en el tiempo planificado y dentro del presupuesto asignado. El 42% son completados con menor alcance, y/o sobrecosto y/o fuera de término. El resto de los proyectos (21%) son cancelados antes de terminar (The Standish Group, 2011).

Por otra parte, en un estudio de eGovernment for Development (2010) de la Universidad de Manchester, se plantea que sólo el 15% de los proyectos son considerados exitosos, el 35% de los proyectos que se inician no se culminan  y el 50% restante se consideran como fracaso parcial. En ese mismo informe se plantea que los principales factores del fracaso de los proyectos son (eGovernment for Development, 2010):

- especificaciones y requerimientos cambiantes o incompletos,
- falta de involucramiento de usuarios,
- pocos conocimientos técnicos del equipo de proyecto
- uso inadecuado de métodos y herramientas,
- expectativas poco realistas,
- falta se soporte gerencial, ]]> - gestión de proyectos débil, lo que incluye no identificación de riesgos, falta de planificación, comunicación deficiente.

En el informe emitido en el 2009 por el Standish Group se plantean algunos de los factores de éxito de los proyectos de desarrollo de software (The Standish Group, 2009):

- participación de los usuarios (15,9%),
- apoyo de la gestión ejecutiva (13,9%),
- declaración clara de las necesidades (13,0%),
- planificación adecuada (9,6%),
- expectativas realistas (8,2%),
- personal competente (7,2%).

Con el objetivo de facilitar la gestión de las eventualidades que surgen en los proyectos se han definido varios modelos asociados a la gestión de riesgos. Algunos de ellos son:

- la visión holística del Instituto de Ingeniería de Software (SEI, por sus siglas en inglés; del inglés, Software Engineering Institute) que incluye el Paradigma de Gestión de Riesgos (del inglés, Risk Management Paradigm) (SEI, 1992), ]]> - una taxonomía para la identificación de riesgos (del inglés, A Taxonomy-Based Risk Identification) (SEI, 1993),
- la estructura para describir los riesgos de desarrollo de software(del inglés, A Construct for Describing Software Development Risks)  (SEI, 1994),
- la definición del proceso de Gestión de Riesgo en Equipo(TRM, por sus siglas en inglés;del inglés, Team Risk Management)(SEI, 1994),
- la definición de una guía para la Gestión de Riesgos Continua(CRM, por sus siglas en inglés;del inglés, Continuous Risk Management) (SEI, 1996),
- un método para la evaluación de riesgos de software (SER, por sus siglas en inglés;del inglés, Software Risk Evaluation) (SEI, 1999),
- el área de proceso de gestión de riesgos definida en el Modelo de Capacidad y Madurez Integrado (CMMI, por sus siglas en inglés; del inglés, Capability Maturity Model Integration) (SEI, 2006),
- los procesos de gestión de riesgos descritos en la Guía de los Fundamentos de la Dirección de Proyectos (PMBoK, por sus siglas en inglés;del inglés, Project Management Body of Knowledge) (PMI, 2004), y (PMI, 2008) del Instituto de Gestión de Proyectos (PMI, por sus siglas en inglés;del inglés, Project Management Institute).

La Universidad de las Ciencias Informáticas (UCI), universidad innovadora de excelencia científica, académica y productiva que forma de manera continua profesionales integrales comprometidos con la patria (UCI, 2010a), ha creado dentro de su estructura organizativa una red de centros de desarrollo de software que favorece la producción. Uno de los centros creados es el Centro de Informatización Universitaria (CENIA), que tiene la misión de conducir el programa de informatización de la UCI con el desarrollo de productos, servicios y soluciones informáticas de alto valor agregado, basados en la soberanía tecnológica, que contribuye a la excelencia en los procesos universitarios.

MATERIALES Y MÉTODOS ]]> Las líneas de desarrollo que trabaja el CENIA son Las líneas de desarrollo – producción que trabaja son: gestión universitaria, gestión documental y archivística, intranet y portales, redes sociales y comercio electrónico, gestión bibliotecaria y ciudad digital (CENIA, 2011).

En el CENIA los riesgos son identificados a través de la plataforma GESPRO³ (Laboratorio de Gestión de Proyectos, 2010). En ella se tienen definidos los riesgos que los miembros del equipo de desarrollo consideran importantes o significativos. No tienen definido un plan de mitigación del riesgo orientado a disminuir su probabilidad de ocurrencia y un plan de acciones preventivas y/o correctivas que defina los pasos para minimizar su impacto si este llega a producirse. Además, no se analizan los elementos que influyen en el logro de los objetivos definidos en el proyecto y que pueden representar oportunidades.

Después de analizar varios modelos definidos para gestionar eventualidades, se comprobó que estos no se pueden aplicar al CENIA. A partir de las definiciones realizadas por PMI (2008) y SEI (2006) se propone la elaboración de un proceso que permita gestionar los riesgos en los proyectos de desarrollo de software del CENIA y que incluya además la comunicación de los riesgos, la evaluación del proceso de gestión de riesgos para identificarle mejoras y el aprendizaje de las prácticas aplicadas e incluya una técnica para el análisis de los riesgos basada en la información lingüística que se emite para el análisis de la incertidumbre.

RESULTADOS Y DISCUSIÓN

Proceso de gestión de riesgos en proyectos de desarrollo de sistemas de información

El proceso para gestionar riesgos en los proyectos de desarrollo de software del Centro de informatización Universitaria, CENIA, incluye los subprocesos: planificar la gestión de riesgos, identificar los riesgos, analizar los riesgos, definir y aplicar actividades para la resolución de eventualidades, comunicar los riesgos, controlar los riesgos y evaluar el proceso de gestión de riesgos. En la Figura 1 se muestra la representación gráfica de estos procesos.

Durante el proceso de gestión de riesgos que se propone, se utilizan como elementos de entrada para cada uno de los subprocesos artefactos tomados del expediente de proyectos de la UCI. Los artefactos propios del proceso para gestionar riesgos en los proyectos de desarrollo de software del CENIA son el plan de gestión de riesgos, la lista de riesgos y el registro de lecciones aprendidas. Todos desarrollados con la herramienta GESPRO (Laboratorio de Gestión de Proyectos, 2012).

Planificar la gestión de riesgos

La planificación es importante para proporcionar los recursos y el tiempo suficientes para las actividades de gestión de riesgos. Se inicia tan pronto se concibe el proyecto y debe completarse en las fases tempranas de la planificación. Define cómo realizar las actividades de gestión de riesgos, los elementos que guiarán su proceso de gestión así como las técnicas, notaciones a utilizar y rangos de valores válidos para las categorías de riesgos.

Durante la planificación de los riesgos se identifican los responsables de aplicar las respuestas definidas para cada riesgo. La definición de los formatos de los informes, el calendario y algunas especificaciones que relacionen el modelo de desarrollo con el proceso de gestión de riesgos que se aplicará son otros elementos que se definen.

En este subproceso se propone la utilización de las reuniones de planificación y análisis descrita en (PMI, 2008) como técnicas y el openproj o Microsoft project como herramientas para realizar la planificación, ya sea en Linux o en Windows.

Identificar los riesgos

En este subproceso se identifican los riesgos para dar soporte a la planificación del proyecto. Consiste en determinar qué riesgos tienen probabilidad de afectar el proyecto y documentar las características de cada uno. Este subproceso responde a las preguntas ¿dónde?, ¿quién?, ¿qué?, ¿cuándo?, ¿cómo? y ¿por qué? se pueden originar hechos que influyen en la obtención de resultados. Durante este subproceso se actualiza la lista de riesgos y, se identifican los riesgos críticos. La identificación de riesgos es un subproceso iterativo pues se pueden descubrir nuevos riesgos que pueden evolucionar conforme el proyecto avanza a lo largo de su ciclo de vida. Al comenzar la identificación es necesario un encuentro donde participen todos los involucrados en la identificación de riesgos. La identificación, independientemente de la técnica que se utilice, está guiada por el criterio de éxito del proyecto.

Para facilitar la categorización se recomienda utilizar las definiciones propuestas en el capítulo anterior.

Los roles que ejecutan este subproceso son el jefe de proyecto y el equipo de gestión de riesgos. En la Figura 3 se muestran los artefactos de entrada y salida así como los roles y actividades involucradas.

Para la identificación de los riesgos se utilizan los análisis de las listas de chequeo, análisis de supuestos, diagramas de causa y efecto, diagramas de flujo, diagramas de influencias y análisis DAFO, propuestas por (PMI, 2008) como técnicas del subproceso.

Al concluir la identificación de los riesgos, estos deben estar documentados, organizados y categorizados de acuerdo a la taxonomía propuesta para el desarrollo de software.

Se coincide con lo que propone Clusif (2009) sobre las secciones que debe tener la documentación del riesgo identificado. Estas son:

- descripción del riesgo: en esta sección se documenta lo referente al origen del riesgo, causa que lo provoca, impactos y consecuencias que genera;
- probabilidad de ocurrencia: se recopila la información relacionada con la probabilidad de ocurrencia con que se presenta el factor de riesgo identificado; ]]> - intensidad del riesgo: esta sección recoge la información relativa a la relación del riesgo con otras actividades u otros riesgos;
- impacto: se refiere al impacto del factor de riesgo;
- nivel de dominio: está asociado al conocimiento del equipo de trabajo en el manejo de un riesgo identificado;
- tipo de riesgo: esta variable está asociada a la clasificación del riesgo;
- acción de corrección o prevención: en esta sección se orientarán las diferentes acciones que se pueden realizar para gestionar un riesgo y su impacto. Para un riesgo se pueden aplicar una o más estrategias; estas pueden estar encaminadas a mitigar, transferir, evitar, explotar, compartir y mejorar el riesgo;
- exposición al factor de riesgo: esta sección recoge la cuantificación de la exposición al riesgo resultado de la probabilidad por la criticidad.

Analizar los riesgos

El análisis de un riesgo consiste en determinar los valores de probabilidad, impacto, frecuencia y certidumbre de la información con el uso de las técnicas definidas en el plan de gestión de riesgos para posteriormente ordenarlos.

El análisis de los riesgos permite detener los riesgos de comunicación con el cliente. Se realiza con el objetivo de evaluar, caracterizar y priorizar los riesgos, para luego determinar su exposición. Para adelantarse a los riesgos es necesario diseñar escalas que pueden ser cuantitativas, cualitativas o una combinación de ambas.

El análisis cualitativo comienza al concluir la identificación de los riesgos. Tiene como meta identificar los riesgos críticos para el proyecto e iniciar la planificación de las respuestas. Durante esta actividad se evalúan cualitativamente las propiedades o elementos de los riesgos.

El análisis cuantitativo se ejecuta después del análisis cualitativo o cuando se considere necesario revaluar los riesgos. Tiene la meta de determinar los valores numéricos de probabilidad e impacto para cada riesgo. Centra la atención en la cuantificación de los riesgos de forma objetiva. Permite analizar numéricamente el efecto de los riesgos identificados sobre los objetivos del proyecto.

Los roles responsables de ejecutarlo son el jefe de proyecto y el equipo de gestión de riesgos. En la Figura 4 se muestran los artefactos de entrada y salida así como los roles y las actividades involucradas.

Se proponen utilizar como técnicas para el análisis de los riesgos la evaluación de probabilidad e impacto de los riesgos, la matriz de probabilidad e impacto, la entrevista, el análisis del valor monetario esperado, todos propuestos y descritos en (PMI, 2008) y, el análisis lingüístico virtual de riesgos, propuesto en esta investigación. En este mismo subproceso se propone como herramienta la guía para identificar desviaciones significativas que se propone en el expediente de proyecto, propuesto por (UCI, 2010b).

Definir y aplicar actividades para la resolución de eventualidades

Es el subproceso en el cual se generan y aplican las acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Las respuestas a los riesgos planificados deben adecuarse según la importancia del riesgo, ser rentables con relación al desafío por cumplir, realistas dentro del contexto del proyecto, acordadas por todas las partes involucradas y deben estar a cargo de una persona responsable.

Durante este subproceso se analiza el conocimiento histórico en busca de guías y recomendaciones para las decisiones que se tomarán.

Los roles responsables de ejecutarlo son el jefe de proyecto, el equipo de gestión de riesgos y, el cliente. En la Figura 5 se muestran los artefactos de entrada y salida así como los roles y las actividades involucradas.

En este subproceso se propone como técnicas la utilización de las estrategias de respuestas para amenazas, estrategias de respuestas para oportunidades y estrategias de respuestas para contingencias descritas por PMI (2008).

Las respuestas a los riesgos incluyen una valoración de la estrategia para enfrentar el riesgo, la actualización de los planes de mitigación de riesgos y la implementación de esos planes. Teniendo en cuenta las estrategias de respuestas a los riesgos propuestas por SEI (1996), en la elaboración de la propuesta, las estrategias que se tendrán en cuenta para aplicar en el proceso de gestión de riesgos que se propondrá son: mitigar, transferir, evitar, compartir, mejorar, prevenir y aceptar. A continuación en la Tabla 1 se enuncian los tipos de estrategias que se pueden aplicar en el proceso de gestión de riesgos:

Comunicar los riesgos

Los roles responsables de ejecutarlo son el jefe de proyecto, el equipo de gestión de riesgos y, el cliente. En la Figura 6 se muestran los artefactos de entrada y salida así como los roles y las actividades involucradas.

El análisis de los involucrados, análisis de requisitos de comunicaciones, la comunicación interactiva, la comunicación de tipo push (empujar) y, la comunicación de tipo pull (halar,) como técnicas aplicables en este subproceso y que están descritas en PMI (2008).

Controlar los riesgos

En este subproceso debe determinarse si las respuestas planificadas han sido ejecutadas como fue previsto, si han sido eficaces o si han provocado nuevas respuestas. Además debe determinarse si los supuestos del proyecto continúan siendo válidos, verificar si la exposición al riesgo ha cambiado y además analizar si se siguen las políticas y procedimientos adecuados. Se realizan además controles del cumplimiento de los hitos de gestión de riesgos. Aplicación de métricas para valoración de la calidad de procesos. Para ello se deben revisar periódicamente la documentación de los riesgos en el contexto del estado y de las circunstancias actuales del proyecto; corregir la documentación de los riesgos a medida que se dispone de información adicional para incorporar los cambios; comunicar el estado de los riesgos a las partes interesadas relevantes.

Durante este subproceso se identificarán condiciones para iniciar planes de respuesta y se emitirán criterios valorativos sobre el estado de los riesgos en el proyecto. Al concluir se obtienen los planes de respuesta actualizados y un resumen evaluativo con las impresiones de la gestión de riesgos hasta el momento. Se debe calcular la efectividad de los planes de respuesta y analizar su efectividad.

Los roles responsables de ejecutarlo son el jefe de proyecto, el equipo de gestión de riesgos y, el cliente. En la Figura 7 se muestran los artefactos de entrada y salida así como los roles y las actividades involucradas.

La reevaluación de los riesgos, las auditorías de los riesgos, y los análisis de variación y de tendencias son técnicas que el PMI (2008) describe  y se proponen en esta investigación. ]]> Evaluar y aprender del proceso de gestión de riesgos

Este subproceso tiene como objetivo analizar la gestión de riesgos y apoderarse del conocimiento adquirido y las experiencias, así como documentarlo para su uso en otros proyectos. Incluye acciones organizativas, operativas, externas a la gestión de riesgos, actividades y técnicas de la gestión de riesgos.

Las sesiones de lecciones aprendidas se centran en identificar los elementos de éxito y fracaso del proyecto. Durante el ciclo de vida del proyecto, el equipo de gestión del proyecto identifica las lecciones aprendidas y analiza cuáles pueden ser aplicadas al proyecto actual. Las lecciones aprendidas se compilan, formalizan y almacenan durante todo el ciclo de vida del proyecto.

El centro de atención de las reuniones de lecciones aprendidas puede centrarse en los procesos técnicos o en los que contribuyeron al rendimiento del trabajo o lo dificultaron. Los directores del proyecto tienen la obligación profesional de llevar a cabo las sesiones de lecciones aprendidas con los interesados internos y externos al proyecto, sobre todo si se han producido resultados inferiores a los deseados.

Los roles responsables de ejecutarlo son el jefe de proyecto, el equipo de gestión de riesgos y, el cliente. En la Figura 8 se muestran los artefactos de entrada y salida así como los roles y actividades involucradas.

Este subproceso provee una base de datos de los proyectos que contiene información sobre el desempeño, informes de estado, análisis del comportamiento y proyecciones sobre los riesgos en proyectos anteriores. De ahí la necesidad de archivar las prácticas aplicadas en la gestión de riesgos para que puedan ser usadas en otros escenarios. En este sentido el GESPRO tiene una base de datos de proyectos terminados que puede ser utilizada con este fin.

En este subproceso se proponen como técnicas las auditorías de los riesgos y, los análisis de variación y de tendencias propuestas por (PMI, 2008).

RESULTADOS

La aplicación del proceso en proyectos reales puede reducir en más de un 50% la exposición a los riesgos. Esta aplicación identificó que las categorías de riesgos más comunes en los proyectos del CENIA son los riesgos de negocio, riesgos asociados a la gestión, riesgos humanos y riesgos tecnológicos. A continuación se muestran estos resultados.

Después de analizar los resultados, se afirma la validez de la propuesta realizada, concluyendo que los expertos plantean que el 84,4% plantean que el proceso es muy adecuado, o sea, que el proceso tiene calidad y que sirve de apoyo a las actividades de seguimiento y control de los proyectos, mientras que el 15,6% plantea que es bastante adecuado. Los resultados obtenidos de la validación pueden observarse en la Figura 9.

En la Figura 10 se muestra un resumen del comportamiento la dimensión definida para evaluar la calidad del proceso. Esto quiere decir que la propuesta es fácil de aplicar y que sus resultados son fáciles de interpretar; de igual modo su modificación resulta sencilla para adaptarse a diferentes entornos. Permite que se pueda adherir a los modelos de desarrollo de software. Tiene buena claridad en su contenido lo que facilita un buen nivel de ejecución o desempeño. Además su aplicación permite al gestor de riesgos ampliar sus conocimientos.

Al analizar el apoyo de la propuesta a la facilidad que brinda al proceso de seguimiento y control de proyectos se concluye que influye en la gestión del cumplimiento del tiempo; contribuye a la identificación de desviaciones en el proyecto, apoya las actividades de seguimiento y control y puede ser integrado a la herramienta de seguimiento y control de proyectos GESPRO. A continuación se muestra en la Figura 11 un resumen del comportamiento.

A continuación se muestra un resumen estadístico del comportamiento de las variables definidas en la investigación.

En un análisis descriptivo de estos indicadores se muestra como el más bajo valor de la media lo tiene el criterio mejora el proceso de gestión de proyectos. Esto puede estar dado por la poca experiencia en la implementación del proceso, donde los subprocesos involucrados se han visto conectados al uso del GESPRO como herramienta de seguimiento y control de proyectos. La desviación estándar es una forma de saber los puntos de vistas de los expertos sobre los criterios abordados. Si se observa la Tabla 2, se nota que la desviación estándar oscila entre 16,993 y 19, 384 lo que indica un índice relativamente alto de dispersión entre los criterios de los encuestados, lo que significa que hubo mayor consenso entre los entrevistados.

Como se puede apreciar los mejores resultados evaluativos se concentran en el criterio de apoyo a las actividades de seguimiento y control. En este grupo se encuentran los indicadores con mejores resultados. Esto se refleja en altos valores de la media que alcanzó.

El otro criterio, aunque tiene buenos resultados, manifiesta de alguna forma bajo nivel de consenso entre los entrevistados pues los valores de desviación estándar son altos. Este fenómeno puede estar dado por la diversidad del personal entrevistado.

De la aplicación del proceso propuesto se concluye que en el proyecto Biblioteca (SIGB BUCI) el 73,81% de los riesgos identificados estaban dados por las categorías de negocio, asociados a la gestión y humanos. Por otra parte en el proyecto Entérate el 69,05% de los riesgos lo dieron estas mismas categorías más la de riesgos tecnológicos. Estas últimas cuatro categorías en los proyectos de Postgrado y ABAD representaron el 77,78% y el 76,74% respectivamente, de los riesgos identificados en cada uno. La Figura 13 resume los datos anteriormente expuestos.

CONCLUSIONES

De manera general, los proyectos incluidos en el estudio presentaron problemas que implicó que el proceso de gestión de riesgos no se realizara con la madurez requerida. Algunos de los problemas detectados estuvieron relacionados con la planificación del proyecto, la indefinición de los elementos o componentes resultantes de cada una de las iteraciones o sprint, la asociación de valores a los riesgos identificados y registrados en los proyectos, la indefinición de los roles encargados de gestionar los riesgos en los proyectos, la indefinición de los criterios de calidad para medir la satisfacción del cliente, de los elementos e interfaces esenciales de integración entre los componentes y del proceso de gestión de cambios.

Culminando el tema de la aplicación, se puede decir que en los proyectos estudiados el 28,6% definió un rol para la gestión de riesgo mientras que en el 71,4% restante esa responsabilidad recayó sobre el propio jefe del proyecto. En los proyectos que se definió un rol para esta actividad se inició con un entrenamiento para gestionar riesgos que les permite mantener la actividad durante el ciclo de vida del proyecto e iniciar la gestión de riesgos en proyectos futuros.

La comunicación entre los miembros de los equipos de trabajo en los diferentes proyectos estuvo adecuada a la metodología de desarrollo de software definida. Se tomó la iniciativa de definir un momento en la semana que permita analizar el rendimiento diario de las personas a partir del cumplimiento de las actividades asignadas y chequear el avance del proyecto. Esto facilitó la identificación de los riesgos y el logro de una buena comunicación del equipo de desarrollo.

La planificación de las respuestas se realizó adecuadamente y las acciones se incluyeron en el plan del proyecto y se relacionaron con las actividades que implicaban una desviación del proyecto y que podrían representar un riesgo. Sin embargo su ejecución no fue totalmente seguida pues no se logró el compromiso necesario de la dirección del proyecto. Los planes de mitigación relacionados con la definición de las políticas y estándares y los programas de formación del equipo, fueron los ejecutados con mayor rigor. A pesar de estas limitaciones la exposición al riesgo se redujo en más de un 50% en todos los proyectos analizados.

Se considera que el principal problema que atentó contra la aplicación de la propuesta en los proyectos fue que la necesidad de gestionar riesgos pasó a un segundo nivel, los encuentros para realizar el trabajo de mesa se planificaron varias veces, esto influyó en la disminución del alcance del proceso de seguimiento y control de los riesgos. No existían experiencias en la aplicación de métricas, lo que dificultó la recolección de datos para la incorporación e interpretación de los datos.

REFERENCIAS BIBLIOGRÁFICAS

CENTRO DE INFORMATIZACIÓN UNIVERSITARIA. Presentación al Frente Universitario. La Habana: Centro de Informatización Universitaria. Universidad de las Ciencias Informáticas. Dirección de desarrollo institucional. 2011.

CLUSIF - CLUB DE LA SECURITE DE L'INFORMATION FRANÇAIS. La gestion des risques. Concepts et méthodes. [Paris]: Club de la Sécurité de l'Information Français. [en línea] 2009 [Consultado en 2010]. Disponible en: [http://www.clusif.asso.fr/fr/production/ouvrages/pdf/CLUSIF-Gestion-des-risques-2009.pdf].

eGOVERNMENT FOR DEVELOPMENT. Comportamiento de proyectos TI: Están en deuda [en línea], 2010. Consultado en 2011. Disponible en: [http://www.egov4dev.org/success/sfrates.shtml].

LABORATORIO DE GESTIÓN DE PROYECTOS. ¿Qué es GESPRO 11.05? La Habana: Universidad de las Ciencias Informáticas Dirección General de Producción. 2012. Consultado en octubre de 2012. Disponible en [http://gespro.maestriagp.prod.uci.cu/].

PMI - PROJECT MANAGEMENT INSTITUTE. Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK). Norma americana ANSI/PMI 99-001-2004 (Tercera ed.). Newtown Square, Pennsylvania, Estados Unidos Americanos: Project Management Institute, Inc. Pennsylvania. 2004

PMI - PROJECT MANAGEMENT INSTITUTE. Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK) (4ª ed.). Newtown Square, Pennsylvania: Project Management Institute, Inc. ISBN: 978-1-933890-72-2. 2008.

PRESSMAN, Roger. Ingeniería del software. Un enfoque práctico. (7ª ed.). McGraw-Hill. New York. ISBN 978-0-07-337597-7. 2010.

PRESSMAN, Roger S. MAIER, MARK W. Endorsements. Competitive Engineering, p. ix-xi, [en línea] 2005  [Consultado en 2011]. Disponible en: [http://pdn.sciencedirect.com/science?_ob=MiamiImageURL&_cid=275924&_user=2342189&_pii=B9780750665070500015&_check=y&_origin=search&_zone=rslt_list_item&_coverDate=2005-12-31&_idxType=GenInfo&wchp=dGLbVlB-zSkzV&md5=0235fdc0fb81a450dae5dcb13c8759dd&pid=3-s2.0-B9780750665070500015-main.pdf].

SEI - SOFTWARE ENGINEERING INSTITUTE. Software Development Risk: Opportunity, Not Problem. Technical Report CMU/SEI-92-TR-30, ESC-TR-92-030. Pittsburgh, Pennsylvania: SEI. 1992.

SEI - SOFTWARE ENGINEERING INSTITUTE. Taxonomy-Based Risk Identification. Technical Report CMU/SEI-93-TR-6, ESC-TR-93-183.Pittsburgh, Pennsylvania: SEI. 1993.

SEI - SOFTWARE ENGINEERING INSTITUTE. A Construct for Describing Software Development Risks. Technical Report CMU/SEI-94-TR-14, ESC-TR-94-014. Pennsylvania: SEI. (C. M. University, Ed.) Pittsburgh, Pennsylvania, United Sates of America. 1994.

SEI - SOFTWARE ENGINEERING INSTITUTE. Continuous Risk Management Guidebook. Pennsylvania: SEI. 1996. ]]>

SEI - SOFTWARE ENGINEERING INSTITUTE. Software Risk Evaluation (SRE) Method Description (Version 2.0. Technical Report CMU/SEI-99-TR-029, ESC-TR-99-029. Pennsylvania: SEI. 1999.

SEI - SOFTWARE ENGINEERING INSTITUTE. CMMI® for Development, CMMI-DEV, V1.2, Technical Report CMU/SEI-2006-TR-008, ESC-TR-2006-008. Improving processes for better products, CMMI Product Team. United Sates of America. 2006.

THE STANDISH GROUP. The CHAOS Manifesto 2011. Trends in IT Value. [en línea] 2011 [Consultado en: 2012]. Disponible en: [https://secure.standishgroup.com/reports/reports.php#reports. The Standish Group International, Incorporated].

THE STANDISH GROUP. Chaos Report 2009. [en línea] 2009. Disponible en: [http://www1.standishgroup.com/newsroom/chaos_2009.php. The Standish Group International, Incorporated].

UNIVERSIDAD DE LAS CIENCIAS INFORMÁTICAS. Proyecto estratégico 2008-2012 (Selección de Contenidos Revisada). La Habana: Universidad de las Ciencias Informáticas. Dirección de desarrollo institucional. 2010a [en línea]. Consultado en octubre de 2012. Disponible en: [http://intranet2.uci.cu/sites/default/files/proyeccion_estrategica/pdf/Proyecto_Estrategico_2008%20-%202012.pdf].

UNIVERSIDAD DE LAS CIENCIAS INFORMÁTICAS. Expediente del programa de mejoras de la UCI. La Habana: Universidad de las Ciencias Informáticas. CALISOFT. 2010b [en línea] Consultado en 2011. Disponible en: [http://calisoft.uci.cu/index/documento].

¹ Informes basados en los conocimientos adquiridos en el desarrollo de software. Incluyen buenas prácticas, cómo implementarlas, gráficos que muestran los resultados de la aplicación de estas prácticas en proyectos reales, estudios de casos y otros documentos de apoyo.
² El Standish Group proporciona informes de inversiones y servicios de planificación. Muestra mejoras en los proyectos de inversiones de tecnologías de la información y acelera el valor de la tecnología de la información. Web en: www.standishgroup.com
³Paquete para la Gestión de Proyectos desarrollado por la Universidad de las Ciencias Informáticas y comercializable desde las empresas comercializadoras asociadas a la Universidad. Producto registrado en el Centro Nacional de Derecho de Autor (CENDA) Nº Registro 1540-2010. Conocida en la comunidad universitaria como Redmine.

Recibido:13/9/2011
Aceptado: 3/12/2011