INTRODUCCIÓN
En este artículo se establecen los supuestos teóricos que sustentan esta investigación. Se esclarece el lugar que ocupa la GR como parte de la Gestión de Proyectos. Se describen elementos fundamentales sobre los riesgos en proyectos de desarrollo de software; se analizan algunos estudios sobre modelos para la GR y se define la posición de la autora al respecto. Por último se ofrecen datos sobre análisis muy recientes de la importancia del tema y se plantean valoraciones sobre su trascendencia y perspectivas futuras.

DESARROLLO
Un proyecto es definido por el Project Management Institute (PMI 2004) como el esfuerzo temporal emprendido para crear un producto o servicio único. Además, los proyectos se caracterizan por:
· ser realizados por personas,
· estar restringidos por recursos limitados,
· ser planificados, ejecutados y controlados,
· ser temporales (tienen un comienzo y un final definidos, y acaban cuando los objetivos declarados han sido alcanzados),
· y estar dirigidos a crear un producto o servicio único que no ha sido realizado antes y cuyas características deben ser elaboradas progresivamente.
Un proyecto suele descomponerse temporalmente en fases o etapas con el fin de:
· tener un mejor control de la gestión,
· y contar con enlaces adecuados con las operaciones habituales de la organización, es decir, con una mejor interacción con dichos trabajos rutinarios.

Cada fase de un proyecto supone la realización completa de un entregable, que es un producto tangible y comprobable como, por ejemplo, un estudio de viabilidad, un diseño detallado o un prototipo.

Además, la conclusión de una fase de un proyecto supone la revisión del entregable y de la ejecución del proyecto para determinar si el proyecto debe continuar y detectar y corregir errores con un costo asumible.

La gestión de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas para proyectar actividades destinadas a satisfacer las necesidades y expectativas de los beneficiarios de un proyecto (PMI 2004).

En el cumplimiento de este objetivo, juega un papel invaluable el ejercicio de prácticas que permitan determinar continuamente qué puede ir mal en el proyecto, cuáles son los riesgos que acechan el proyecto, sus posibles consecuencias y estrategias ante ellos, pero… ¿qué es un riesgo?

1.1. Riesgos de Software.
De forma general debe aclararse que un riesgo es un evento o situación posible en el futuro, pero no seguro y que de concretarse puede transformarse en un problema. Un riesgo no es un problema hoy, pues un problema ya es un riesgo hecho realidad.

En su libro sobre análisis y gestión del riesgo, Robert Charette presenta la siguiente definición de riesgo:
En primer lugar, el riesgo afecta a los futuros acontecimientos (…) La pregunta es, podemos por tanto, cambiando nuestras acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede venir dado por cambios de opinión, de acciones, de lugares... En tercer lugar, el riesgo implica elección y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muerte, es una de las pocas cosas inevitables de la vida (CHARETTE 1989).

Para que un riesgo sea entendible debe ser expresado claramente y su declaración, según el Software Engineering Institute (SEI 2000), debe incluir:
· Una descripción de las condiciones actuales que pueden conducir a la pérdida.
· Una descripción de la pérdida.

Otras definiciones se presentan a continuación:
El riesgo es la posibilidad de sufrir una pérdida (SEI 2000).
Una medida de la exposición a la que está sujeta un sistema o sistema potencial (CRAMM 2003).
Un evento o una condición que, si ocurre, tiene un efecto positivo o negativo sobre los objetivos de un proyecto (PMI 2004).
La posibilidad de que una amenaza dada impacte las vulnerabilidades de un activo o grupo de activos y cause así, daños a la organización (ISO/IEC 2004).

Posibilidad de que se produzca un impacto determinado en un activo, en un dominio o en toda la Organización (MAP 2006).
Cuando se considera el riesgo en el contexto de la gestión de proyectos, los tres pilares conceptuales de Charette se hacen continuamente evidentes. Aunque se han producido amplios debates sobre la definición adecuada para riesgo de software, aun cuando el orden de las palabras de los diferentes criterios puede variar, hay acuerdo común en que el riesgo siempre implica dos dimensiones:
· Incertidumbre: El acontecimiento que caracteriza al riesgo puede, o no, ocurrir.
· Efecto en los objetivos: Si el riesgo se convierte en una realidad, esto tendrá consecuencias para el proyecto.

Es común utilizar los términos “probabilidad” e “impacto” para describir estas dos dimensiones, refiriéndose la “probabilidad” a la posibilidad con que un evento o condición puede ocurrir (la dimensión de incertidumbre), y el “impacto”, al alcance de lo que sucedería si el riesgo se materializa (la dimensión efecto). Cuando se evalúa el significado de un riesgo en particular, es necesario considerar ambas dimensiones. Claramente, un evento incierto que posiblemente puede ocurrir (o sea, con alta probabilidad), pero que tendría poco o ningún efecto sobre los objetivos (un bajo impacto), sería poco significativo. Igualmente un riesgo podría resultar despreciable si su probabilidad de ocurrencia fuese baja, aun cuando su impacto, de cierta importancia, fuese teóricamente posible.

En cuanto al efecto en los objetivos, como puede apreciarse en las definiciones, algunos autores solo consideran las consecuencias negativas en estos, mientras que otros, reflexionan sobre los beneficios que también puede entrañar un riesgo para el proyecto. En esta investigación el riesgo se refiere a los eventos que pueden ocasionar daños a objetivos del proyecto de desarrollo de software.

Sobre esta base, los objetivos de la GR deben estar encaminados a aumentar el nivel de certeza de que los objetivos de un proyecto podrán ser alcanzados y para ello habrá que tener en cuenta cómo balancear la exposición a los riesgos y la respuesta ante ellos según el costo de aceptarlos, evitarlos, transferirlos, mitigarlos, planear contingencias o hasta ignorarlos.

1.1.1. Estrategias de riesgo reactivas y proactivas
Las estrategias a seguir ante los riesgos en proyectos de desarrollo de software dependen en gran medida de la toma de decisiones con alto nivel de incertidumbre (o sea falta de información en zonas más o menos amplias). Este alto nivel de incertidumbre se debe a la falta de series históricas en la información utilizada, la experiencia limitada sobre los problemas relativos a riesgos, la poca madurez comercial de los métodos disponibles para su solución y la propia idiosincrasia de los conceptos manejados.

Las estrategias reactivas son aquellas que se dan cuando se deja que los riesgos produzcan sus efectos (en este momento ya no es un riesgo, es una realidad) y entonces se actúa en consecuencia. En estas condiciones lo único que cabe es tomar medidas correctoras (apagar incendios), lo que produce muchos tiempos perdidos, retrasos en el proyecto, gabinetes de crisis... Las estrategias reactivas no son aconsejables porque ponen en grave peligro el proyecto.

Las estrategias proactivas, pasan por la evaluación previa y sistemática de todos los riesgos inherentes al proyecto, evaluando sus consecuencias. Esto produce la creación de un Plan de GR, con sus planes de evitación, minimización de consecuencias, planes de contingencia... En estas condiciones el objetivo es la evasión del riesgo, con menor tiempo de reacción frente a los efectos negativos y una mejor gestión del proyecto en su conjunto: menor tiempo y menor coste.

1.1.2. Clasificación de los Riesgos
Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociados con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.

A continuación se presenta un resumen de la clasificación de los riesgos relacionados con proyectos de software. La Tabla 1, es el resultado del estudio y análisis de otros trabajos citados oportunamente.


Tabla 1. Clasificación de los Riesgos de Software.

1.1.3. Factores de riesgo.
Los factores de riesgo son los elementos que determinan el riesgo. Su medición y monitorización determina el grado de acercamiento al riesgo. Por cada riesgo es necesario identificar los factores que lo determinan. Un riesgo puede ser, a su vez, factor de riesgo en otros riesgos.
En la Tabla 2, se muestran diferentes enfoques sobre los factores de riesgos consultados en la literatura para proyectos de desarrollo de software.



Tabla 2. Resumen de factores de riesgos en proyectos de desarrollo de software.

1.2. Definiendo la GR.
Diferentes definiciones de la GR, pueden ayudar a tomar partido por una posición u otra, a continuación se citan algunas:
Enfoque sistemático para reducir la probabilidad de riesgos y/o limitar los daños causados por el riesgo mediante el uso de contramedidas adecuadas o acciones preventivas (MAP 1996b).

El proceso formal en el que los factores de riesgos son sistemáticamente identificados, evaluados y mitigados (SEI 2000).
La identificación, análisis y mitigación de riesgos en sistemas de información, a un nivel acorde al valor de los activos protegidos (CIAO 2000).

La Gestión del Riesgo es una técnica que maneja los recursos empleables en el proyecto para limitar la diferencia entre su Estado Final Deseado (EFD) y su Estado Final Conseguido (EFC). Si la diferencia supera un límite establecido, se materializa un riesgo de incumplimiento del objetivo. Para asegurar la pertinencia del resultado suelen requerirse decisiones de realización de nuevas acciones que permitan reducir esa diferencia. Si el EFC está muy alejado del EFD, el proyecto incumplirá el objetivo; hasta su misma consecución puede resultar imposible (COCHO et al. 2003).

Selección e implantación de las medidas o ‘salvaguardas’ de seguridad adecuadas para conocer, prevenir, impedir, reducir o controlar los riesgos identificados y así reducir al mínimo su potencialidad o sus posibles perjuicios. La GR se basa en los resultados obtenidos en el análisis de los riesgos (MAP 2006).

Sobre la utilización del término Gestión de Riesgos, cabe señalar que existen posiciones que separan las actividades de análisis de las de gestión y también se utilizan los términos tratamiento y administración de riesgos. En esta investigación GR se refiere a los procesos que se encargan tanto de planificar, identificar y analizar, como de responder al riesgo y seguir y controlar las actividades planificadas al respecto (PMI 2004).

La investigación en la GR en el ámbito del software procura formalizar conocimiento orientado a la minimizar y/o evitar los riesgos en proyectos de desarrollo de software, mediante la generación de principios y buenas prácticas de aplicación realista (ROPPPONEN and LYYTINEN 2000). Hasta el momento se han propuesto y utilizado diferentes perspectivas de GR desde que Boehm (BOEHM, B. 1988) atrajo a la comunidad de ingeniería del software hacia esta rama. Sin embargo, es evidente que pocas organizaciones utilizan todavía de una forma explícita y sistemática métodos específicos para gestionar los riesgos en sus proyectos software (KONTIO 1997; KULIK and WEBER 2001).

Aunque los diversos enfoques de GR aparecieron hace varias décadas, sigue siendo evidente la poca utilización de sus técnicas en los proyectos de desarrollo de software actuales (ESTÉVES and PASTOR 2005).

Durante el año 2001, KLCI realizó y publicó un estudio con más de 260 organizaciones de todo el mundo y el resultado arrojó que la inmensa mayoría de los participantes estaban enfrascados en la búsqueda e implementación de prácticas para la GR. La gráfica muestra otras conclusiones del estudio:


Figura 1: Utilización de algún marco para la GR

Como puede apreciarse en la Figura 1, el 3% no utilizaba ningún marco de gestión del riesgo, el 18% utilizaba algún marco caótico para identificar sus riesgos, el 37% de los participantes habían utilizado algún marco informal, el 28% utilizaban procedimientos repetitivos y sólo un 14% utilizaba un enfoque formal para identificar riesgos (KULIK and WEBER 2001). Según este estudio, las razones más comunes para utilizar un marco informal son: la falta de procedimientos, las necesidades del proyecto mal definidas, la organización inexperta o inmadura y el compromiso del equipo.

Según Hoffman (HOFFMAN 1998), aunque algunas organizaciones usen procesos formales de GR para otras partes de su negocio, demuestran una GR pobre en el ámbito general de los sistemas de información. Kontio y Basili (KONTIO 1997) enumeran tres razones principales para la baja tasa de divulgación de tecnologías de GR: falta de conocimiento sobre posibles métodos y herramientas, limitaciones prácticas y teóricas de los marcos de GR que entorpecen la facilidad de uso de estos métodos, y tercero, todavía hay pocos informes con evaluaciones sistemáticas o científicas que proporcionen feedback empírico sobre su viabilidad y beneficios.

El riesgo en un proyecto de desarrollo de software incluye componentes técnicos y de conocimiento del riesgo (JIANG et al. 2001). Diferentes estudios han mostrado que la mayoría de los proyectos fallan sobre todo en gestión, no tecnológicamente.

Además, son los temas de naturaleza organizacional los factores de riesgos del proyecto más dominantes a la vez que son los que se tratan satisfactoriamente en menos de la tercera parte de los proyectos de desarrollo (DOHERTY N. 2001). Schmidt (SCHMIDT et al. 2001) plantea que los jefes de proyecto exitosos puntúan bajo aquellos factores sobre los que no tienen control o influencia como: conflictos entre departamentos usuarios, cambio del propietario o responsable ejecutivo del proyecto, volatilidad del personal, número de unidades de la organización implicadas y proyectos que involucran a múltiples proveedores.

Otro aspecto que influye en estos temas es la falta de reconocimiento sobre la importancia de los aspectos organizacionales que existe en gran parte de la comunidad profesional y académica vinculada a las tecnologías de la información y la comunicación, como muestran Doherty y King (DOHERTY N. 2001).

1.3. Marcos para la GR.
Varios autores han trabajado en temas como la evolución de las teorías sobre Riesgos y la comparación de modelos, métodos y metodologías. Por ejemplo, se ha divido la GR en generaciones, para exponer mejor las características y evolución de cada una. Por supuesto que la adscripción a una generación puede diferir para los autores debido a que la evolución es continua y no a saltos y también porque los modelos estudiados pueden variar en el tiempo, es decir, no solo puede cambiar la forma general en que se aborda la GR sino que, puede cambiar la forma en que un modelo aborda la GR.

En su Estudio exploratorio sobre los métodos de gestión de proyectos de alto riesgo, Marcelo, Rodenes y Torralba (MARCELO et al. 2003) plantean la evolución de los modelos de gestión de los riesgos de los en forma de sucesivas generaciones:
La primera generación: G1

Es la generación casuística o tradicional, donde se limitaban las tareas a la identificación de riesgos en los proyectos con técnicas basadas en cuestionarios, listas de incidencias y de las medidas para contrarrestarlas. Se identificaban casos de riesgo y se extrapolaban a otros proyectos. No hay una planificación específica. En esta generación se definen los Riesgos tecnológicos y las Listas de comprobación de riesgos.

Autores como A. Juan y J. Cueva, exponen datos sobre la historia del surgimiento de los riesgos tecnológicos (ORTEGÓN et al. 2005) y hacen referencia a:

· Años 40s: Con la teoría de la fiabilidad, arranque de la Teoría del Riesgo en Sistemas Complejos con el Teorema de Lusser: “la probabilidad de éxito (no fallo) de una cadena de componentes es el producto de las probabilidades de éxito de sus elementos”.
· Años 60s: Análisis de riesgos cuantitativo (procesos markovianos) para describir el comportamiento de sistemas complejos con fallos ensayables y sin intervención manual (aleatoria); o cualitativo como los árboles de fallos para sistemas híbridos con la incertidumbre de la intervención humana y la imposibilidad de probar los impactos salvo por simulación.

· Años 70s: Método general de Rasmussen con 6 etapas: Definición del proyecto de seguridad y su sistema objetivo, análisis funcional de éste, identificación de riesgos, modelización del sistema, evaluación de consecuencias, síntesis y decisiones finales.
La segunda generación: G2

Es la generación taxonómica de análisis de riesgos en los proyectos, traduce a ese sector el análisis de riesgos en los sistemas, desarrollado en los ochenta junto a intentos poco articulados de análisis de riesgo en los negocios.

Marcelo, Rodenes y Torralba (COCHO et al. 2003), apuntan que los modelos de la G2 se han limitado a analizar los riesgos al inicio del proyecto y a planificar medidas y definen esta visión como “preventiva”, “teorizante” y de medidas “curativas”, improvisadas en mayor o menor medida, durante el avance del proyecto, para paliar los riesgos según se presentan. Posteriormente califican a los modelos de la G2 como “meramente reactivos, con unas relaciones de causa-efecto basadas sólo en una confianza que parte de experiencias poco validadas”. Los marcos contenidos en esta generación:
1. Modelo de Boehm.
2. Modelo de Hall.
3. Modelo del SEI.
4. Modelo SPR de mejora de capacidad en la GR.
5. Modelo SERIM (Software Engineering Risk Management) de Karolak: IEEE.
6. Modelo del PMI.
7. Modelo de McFarlan (adelantos de G3 )

Se coincide con los modelos adscritos, no así con su caracterización, pues modelos tan internacionalmente utilizados, validados y reconocidos como los del SEI y PMI, son efectivamente preventivos pero ¿no puede una buena GR estar basada en el arte de prevenir y evitar su ocurrencia? Por otra parte, hay una contradicción en la utilización de los términos preventivo y reactivo.
La tercera generación: G3

Es la generación causal o emergente, nacida a mediados de los 90 y referida en particular a proyectos informáticos. Surge de forma simultánea en Europa y en EEUU, partiendo de la preocupación por proyectos de tanto riesgo como la adquisición o el desarrollo de software. Aprovecha los métodos de GR usados en los sistemas. Articula también una causalidad más explicativa -y por lo tanto más predictiva entre los elementos del modelo, sobre todo entre los factores de riesgo y sus medidas reductoras o salvaguardas. Esta cuasi-causidad prepara el paso a la gestión de proyectos por los riesgos. Se apoya en modelos sistémicos, relacionales (redes de causas-efectos) y proactivos en el aseguramiento de los proyectos. Los marcos incluidos en esta generación (COCHO et al. 2003):
1. Euromethod
2. MAGERIT: Metodología de Análisis y GR de los Sistemas de Información, Consejo Superior de la Administración Electrónica. España (MAP 2006).
3. Information Services Procurement Library (ISPL).
4. Proyectos de investigación europeos RiskMan, DriveSPI, RiskDriver, Moynihan, Barki, Schmidt e INSEAD.
Estéves (ESTÉVES and PASTOR 2005), propone un estudio de varios de los modelos que son utilizados para la GR. La Tabla 3, muestra algunos modelos ampliamente conocidos y fácilmente accesibles por sus nombres o por las organizaciones que los avalan, cada uno establece categorías para las funciones del riesgo en diferentes fases.


Tabla 3. Modelos para la Gestión de Riesgo.
Además pueden citarse otras adecuaciones basadas en los modelos ya citados como el MSF: disciplina planteada por la Microsoft Solutions Framework (MFS 2002 ).

1.4. Valoraciones sobre las perspectivas de la GR.
Dedolph, reflexiona sobre la GR en el ámbito del software y la figura como una actividad olvidada (DEDOLPH 2003), pudiera ser esta una de las más fieles descripciones de la situación actual de la GR. Sin embargo otros autores apuestan por el protagonismo que ya alcanza el tema.

Alberts y Dorofee, plantean la necesidad del uso de mejores técnicas de análisis de requerimientos basados en la complejidad que adquieren hoy los ambientes operacionales y enumeran nuevas fuentes de riesgos que emanan hoy de esta complejidad como por ejemplo: los riesgos heredados, nuevos recursos de riegos, riesgos por efectos combinatorios y riesgos por consecuencias en cascada (ALBERTS and DOROFEE 2006).

En el Reporte Anual del Software Engineering Institute del pasado año (SEI 2000), se referencia investigaciones desarrolladas por este centro hasta la culminación de su año fiscal en septiembre de 2006. Entre ellas pueden citarse los estudios en taxonomía de riesgos, una serie de indicadores de riesgos para diagnóstico así como un caso de estudio. Además se desarrollaron estrategias de reducción de riesgos para la adquisición de software.

La Escuela de Negocios de la Universidad de Québec en Montreal, publica nuevamente una encuesta (UQAM 2007) que forma parte de la segunda fase de una investigación conjunta realizada con el PMI Research Department. Cada encuestado recibe un resumen de la edición anterior (BESNER and HOBBS 2004) y un resumen de los resultados arrojados hasta el momento en la presente edición. El objetivo del cuestionario en el estudio del uso e importancia en la gestión de proyectos, de 70 herramientas y técnicas específicas (no se enfocan procesos generales y se ofrece una definición). Para cada herramienta o técnica, se plantearon las siguientes preguntas:
1. Nivel de uso.
2. Soporte de la organización.
3. Contribución potencial ante un uso mayor o mejor (de la herramienta o técnica) en los resultados de los proyectos.

Si se analizan los datos que Agueda (AGUEDA 2006) expone sobre la presente edición de la encuesta (julio 2006), puede notarse que las técnicas y herramientas relacionadas con la palabra “riesgos” no aparecen entre las 10 más utilizadas actualmente. Sin embargo, como muestra la Tabla 4, 3 de las 4 técnicas incluidas en la lista, están entre las 10 con un potencial mayor de contribución.


Tabla 4. Lugar ocupado en la lista de las 70 técnicas y herramientas.
Se coincide con los criterios de este autor, sin embargo, cuando se refiere a las técnicas o herramientas que contienen el término, deja fuera el Plan de Contingencias, que está estrechamente relacionado con la GR y la Asignación de responsables de Riesgos (1). Otros datos que muestran la importancia que debe tomar este campo en un futuro no muy lejano, se muestran en las Tablas 5 y 6.




Tabla 6. Contribución Potencial de las técnicas o herramientas.

La contribución a las mejoras en la Gestión de Proyectos que se esperan a partir del uso adecuado y mejor, puede tomarse como considerable.

CONCLUSIONES
Los interesados en la gestión de proyectos de software -y nótese que no se hace referencia solo a los ingenieros o a los certificados como “Project Managers” o entendidos en estos temas- reconocen la importancia de cualquier marco para el tratamiento de los riesgos, investigan sobre sus fuentes e impactos, cada vez mayores en ambos casos y avizoran su aporte vital a la mejora de los proyectos si estos marcos se usan con mayor frecuencia, organización y profundidad… entonces, es necesario, que tanto a nivel mundial, como nacional y muy inexcusablemente, en los proyectos de la Universidad de las Ciencias Informáticas, se trabaje sobre la base de:
1. Cambiar y ampliar la óptica con que se ven los perfiles del Riesgo, no puede continuar siendo sujeto omitido en nuestra Gestión de Proyectos
2. Educar a los equipos de desarrollo de software a comenzar la Gestión del Proyecto con la Gestión de sus Riesgos.
3. El esfuerzo y el tiempo que empleen los equipos de desarrollo de software, en comprender la GR y aplicarla a su trabajo concienzudamente, devendrá en la calidad de sus procesos, la calidad de sus productos y en la satisfacción de sus clientes.
4. Y por último, un objetivo difícil pero necesario y alcanzable, ir desde la Gestión de los Riesgos del Proyecto hasta la Gestión del Proyecto por sus Riesgos.

REFERENCIAS BIBLIOGRÁFICAS
AGUEDA, A. La realidad de la práctica del Project Management, 2006. [Disponible en: http://legnita.wordpress.com/2006/08/07/la-realidad-de-la-practica-del-project-management/#comment-92
ALBERTS, C. and A. DOROFEE. Advanced Risk Analysis for High-Performing Organizations, SEI, 2006.
BARKI, H. A. Toward an assessment of sw development risk. Journal of Management Informatio System Risk, 1993, Vol 10.
BESNER, C. and B. HOBBS. An Empirical Investigation of Project Management Practice. A Summary of the Survey Results. Montreal, University of Quebec at Montreal. School of Bussines Administration, 2004. 24.
CARR, M. J.; S. L. KONDA, et al. Taxonomy-Based Risk Identification. Pittsburgh, Software Engineering Institute, 1993.
CIAO. Practices for Securing Critical Information Assets. Critical Infrastructure Assurance Office, 2000. p.
COCHO, J. M.; M. R. ADAM, et al. Estudio exploratorio sobre los métodos de gestión de proyectos de alto riesgo. Primer Congreso SOporte del COnocimiento con la TEcnología, SOCOTE, Valencia. España, 2003. p.
CRAMM CCTA Risk Analysis and Management Method (CRAMM) v5.0, 2003.
CHARETTE, R. N. Software Engineering Risk Analysis and Management. McGraw–Hill/Intertext, 1989. p.
DOHERTY N., K., M. An investigation of the factors affecting the successful treatment of organizational issues in systems development projects European Journal of Information Systems, 2001, 10: 147-160.
ESTÉVES, J. and J. A. PASTOR. Implementación y Mejora del Método de Gestión Riesgos del SEI en un proyecto universitario de desarrollo de software, 2005.
---. Towards the Unification of Critical Success Factors for ERP implementations. 10th Annual BIT Conference, Manchester UK, 2000. p.
HIGUERA, R. P. and Y. Y. HAIMES. Software Risk Management. Pittsburgh, Pennsylvania, Carnegie Mellon University. Software Engineering Institute, 1996. 48.
HOFFMAN, T. Risk management still a wild frontier Computerworld, 1998, 32: 10.
ISO/IEC. Information technology. Security techniques. Management of information and communications technology security, 2004. 13335-1.
JIANG, J.; G. KLEIN, et al. Information Systems Success as impacted by risks and development strategies IEEE transactions on Engineering Management, 2001, 48: 46-55.
JONES, C. Minimizing the risks of sw development. Cutter IT Journal 1998, Vol 11.
KONTIO, J. Empirical Evaluation of a risk management Method. SEI conference on risk management, 1997. p.
KULIK, P. and C. WEBER. Software Risk Management Practices 2001.
MAP El proyecto Eurométodo. Ejercicio de validación de EM v0, 1996a.
---. Eurométodo v1.0. Diccionario. 1996b. p.
---. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Método. (v 1.1). PÚBLICAS, M. D. A., Catálogo general de publicaciones oficiales, 2006.
MARCELO, J.; M. RODENES, et al. Estudio exploratorio sobre los métodos de gestión de proyectos de alto riesgo. Primer Congreso SOporte del COnocimiento con la TEcnología, SOCOTE, Valencia. España, 2003. p.
MFS Disciplina de administración de riesgos v.1.1, 2002
PMI. Project Management Body of Knowledge. PMI Communications, 2004. p.
ROPPPONEN, J. and K. LYYTINEN Components of Software Development Risk: Hot to address Them? IEEE transactions on software engineering, 2000, 26: 98-111.
SCHMIDT, R.; K. LYYTINEN, et al. Identifying software project risks, an international Delphi study Journal of Management Information Systems, 2001, 17: 5-36.
SEI. Risk Management, 2000. [2007]. Disponible en: http://www.sei.cmu.edu/news-at-sei/columns/the_cots_spot/2000/march/cots-mar00.htm
UQAM. Welcome to the study on The Reality of Project Management Practice 2007. [2007]. Disponible en: http://www.surveymonkey.com/DisplaySummary.asp?SID=1993451&U=199345126557

REFERENCIA
1. En el original Assignment of risk ownership que según la definición especificada para el estudio, es “La situación cuando a un miembro del personal del proyecto se le da la responsabilidad fundamental de algunos riesgos del proyecto.”

AUTORAS
Ing. Yeleny Zulueta Véliz.
Ingeniera Informática.
Profesora de la Universidad de las Ciencias Informáticas. Cuba.
yeleny@uci.cu
Ing. Yadira Ruíz Contanten
Ingeniera Informática.
Profesora de la Universidad de las Ciencias Informáticas. Cuba.
yadirar@uci.cu

Enviado por Ing. Yeleny Zulueta Véliz y Ing. Yadira Ruíz Contanten
Contactar mailto:yeleny@gmail.com

Código ISPN de la Publicación: EElkuyFZuAkrUVZhMc
Publicado Thursday 21 de June de 2007