Método para la construcción de una taxonomía: estructura base para riesgos en outsourcing de software

Method to construct a taxonomy: basic structure to risks in software outsourcing

Gloria Piedad Gasca Hurtado*, Bell Manrique Losada

Grupo de Investigación ARKADIUS, Facultad de Ingenierías. Universidad de Medellín. Carrera 87 N.° 30 - 65 Bloque 4. Medellín, Colombia.

---

Resumen

Este artículo propone una taxonomía de riesgos enfocada en el ámbito de outsourcing de software. El objetivo es definir una estructura de clasificación de riesgos, relacionada con el proceso de outsourcing de software. La motivación está dada por la importancia que tiene la identificación de riesgos, y la ayuda que prestan las taxonomías al respecto, por lo cual se les conoce como una técnica efectiva que permite desarrollar una mejor gestión de riesgos. Este artículo incluye el método para construir la taxonomía (llamado MECT) y la estructura de una taxonomía de riesgos para outsourcing de software.

Palabras clave: Mejora de procesos, gestión de riesgos, outsourcing, outsourcing de software.

---

Abstract

This paper proposes a risk taxonomy that focuses on software acquisition environment. According to this, the goal of this approach is to define an ordered risk classification structure related with to software acquisition. The proposal of a risk taxonomy of software acquisition is motivated by the importance that risks identification activity has and the contribution that a risk taxonomy gives to this activity, because it is known as a technique for effective risks identification, which it's possible to develop a better risk management starting from a better identification of them. This paper includes both the method to construct the taxonomy (called MECT) and the proposed risk taxonomy of software acquisition that was developed.

Keywords: Process Improvement, risk management, outsourcing, software outsourcing.

---

Introducción

Outsourcing de Sistemas de Información (SI) se ha convertido, en los últimos años, en una estrategia básica para poder gobernar los constantes cambios a los que se ven sometidas las Tecnologías de la Información (TI) [1]. Por esta razón, el outsourcing de SI/TI ha experimentado un alto crecimiento a lo largo de las últimas cuatro décadas [2]. Sin embargo, el éxito y la calidad de un proyecto de outsourcing es un aspecto que depende de la gestión que se lleve a cabo para dicho proyecto [2].

La situación de la gestión de los proyectos de outsourcing hoy en día destaca por los altos porcentajes de fracasos. El Software Engineering Institute (SEI) [3] asegura que del 20% al 25% de los proyectos de outsourcing de TI fallan después de dos años y que el 50% falla después de cinco años por diferentes factores, entre los que se encuentran la inadecuada gestión del proyecto, la pobre definición de requerimientos, la inadecuada selección y contratación del proveedor, deficiencias en la selección tecnología y la falta de controles de gestión de cambios.

Esto demuestra que la gestión es un factor crítico para el éxito de un proyecto de outsourcing [2, 4-6]. Es indispensable gestionar día a día las actividades del proyecto, con el fin de conseguir el cumplimiento de sus objetivos y, con ello, su éxito. Sin embargo, la gestión del proyecto por sí sola no es suficiente [5].

Para la gestión de un proyecto es necesario considerar diferentes procesos, dentro de los que se encuentra la gestión de riesgos [5], definido como un proceso por medio del cual es posible identificar problemas antes de que ocurran, de tal forma que se puedan planificar y ejecutar actividades de manejo de los riesgos del proyecto de outsourcing, en el momento que sea necesario, y mitigar los impactos adversos que puedan afectar el logro de sus objetivos [3].

La gestión de riesgos está relacionada con la toma de decisiones desde el punto de vista de los riesgos, es decir, permite decidir qué hacer sobre el riesgo después de que éste ha sido analizado. Usualmente, la gestión de riesgos consiste en llevar a cabo tres fases: planificación, control y monitorización [7], aunque diferentes autores [5, 8] definen las actividades y pasos de la gestión de riesgos según el enfoque que tengan las propuestas.

En este sentido, el SEI presenta un paradigma del proceso de gestión de riesgos [9]. Este paradigma puede considerarse como el conjunto de las actividades esenciales para llevar a cabo el proceso de gestión de riesgos aplicable a cualquier organización [9]. Este paradigma ha sido utilizado para desarrollar iniciativas enfocadas a la gestión de riesgos del outsourcing de software (Acquisition Risk Management, ARM) porque comprende las actividades básicas del proceso de gestión de riesgos [9]. Se considera el método más general para desarrollar este proceso y comprende las siguientes actividades básicas (véase figura 1) que describen de forma general el proceso de gestión de riesgos [10]: 1) Identificación: buscar y localizar riesgos antes de que se conviertan en problemas. 2) Análisis: transformar los datos de los riesgos en información para tomar decisiones. Evaluar el impacto, probabilidad y ocurrencia de los riesgos para poder clasificarlos y priorizarlos. 3) Planificación: trasladar la información a decisiones y acciones de mitigación (presente y futuro) e implementar dichas acciones. 4) Seguimiento: monitorizar los indicadores de riesgos y las acciones de mitigación. 5) Control: corregir desviaciones de los planes de mitigación de riesgos. 6) Comunicación: proporcionar información interna y externa sobre las actividades de gestión de riesgos, y actualizar los riesgos incluyendo nuevos riesgos.

La gestión de riesgos en outsourcing de software ha generado un importante interés [11], razón por la que se generan diferentes propuestas [9], algunas basadas en el modelo de capacidad y madurez de adquisición de software (SA-CMM) [12].

Además, existen diferentes estándares y modelos de procesos que tratan el outsourcing, tales como el Software Life Cycle Processes ISO/IEC 12207 [13], el CMMI Acquisition Module (CMMI-AM) [14], el eSCM [15] y el CMMI-ACQ [3]. Todos coinciden en considerar la gestión de riesgos en los proyectos de outsourcing como un proceso clave. El planteamiento de estas propuestas busca proporcionar a las organizaciones, guías, procedimientos, estructuras o modelos para desarrollar adecuadamente los procesos de gestión de los proyectos de outsourcing de software. Enmarcan la gestión de riesgos como un proceso fundamental de la gestión de proyectos, lo que indica que una buena gestión de proyectos, que incluya la gestión de riesgos, permitiría disminuir el nivel de fallos o fracasos en los proyectos de outsourcing de software.

Aún así, tanto el modelo CMMI-ACQ [3] como el paradigma de gestión de riesgos del SEI [9] y los demás modelos de procesos mencionados antes [12, 14-16], son algunos de los que se consideran de mayor utilidad para determinar qué actividades deberían realizarse. Sin embargo, no concretan sobre la forma de desarrollarlas [17]. Además, la complejidad de sus propuestas aumenta el nivel de dificultad para su implementación.

Esta dificultad genera una necesidad importante, que motiva la búsqueda de soluciones que permitan a las organizaciones facilitar la implementación del proceso de gestión de riesgos en outsourcing de software, y así contribuir a disminuir los problemas por los cuales fracasan los proyectos de outsourcing, es decir los fallos de gestión del proyecto de outsourcing.

Dentro de dichas soluciones, está la implementación de técnicas que permitan llevar a cabo, de manera eficiente, el proceso de gestión de riesgos. Y, aunque todos los modelos tienen su propia filosofía, las fases que se llevan a cabo para gestionar los riesgos son las descritas en el paradigma antes mencionado (véase figura 1) [10]. Por esta razón, se considera que este paradigma es la constante en la que se basa el proceso de gestión de riesgos.

Se inicia con la fase de identificación, en donde se concentra la principal fuente de información para la gestión de los riesgos y el buen desarrollo del proceso de gestión de riesgos, por medio del cual es posible desarrollar e implementar respuestas apropiadas de manera anticipada a las consecuencias de los riesgos [18].

Por lo tanto, es indispensable utilizar técnicas o métodos estructurados y consistentes para facilitar y hacer efectiva la fase de identificación de riesgos, con el fin de determinar los elementos de riesgos potenciales que se tratarán durante las demás fases de la gestión de riesgos.

A pesar de que los modelos antes mencionados carecen de técnicas específicas para el desarrollo de la gestión de riesgos, el estándar PRINCE2 [8] asegura que para la identificación de riesgos es indispensable establecer una categorización de los mismos que facilite la identificación de los riesgos potenciales de un proyecto [19], e incluye un listado con algunos riesgos del desarrollo de software, como punto de partida para su identificación.

Por su parte, el modelo CMMI-ACQ [3] hace referencia a que la categorización de riesgos es una actividad fundamental dentro de la identificación de riesgos y resalta la necesidad de agrupar los riesgos por medio de categorías recogidas en, por ejemplo, una taxonomía. Sin embargo, dicho modelo carece de una categorización que agrupe los riesgos propios del proceso de outsourcing de software.

Dado que las taxonomías de riesgos son una buena técnica que apoya la fase de identificación [20], se han desarrollado y propuesto algunas taxonomías que agrupan y categorizan los riesgos de diferentes disciplinas como el desarrollo de software [20]. Una taxonomía de riesgos proporciona una estructura de clasificación importante para el proceso de gestión de riesgos y un punto de partida para llevar a cabo, fácil y eficientemente, el proceso de gestión de riesgos. Este trabajo se propone una estructura de clasificación para los riesgos en outsourcing de software, organizada como una taxonomía.

Revisión de literatura

Outsourcing de software se convierte cada día más en una estrategia empresarial que establecen las organizaciones. En España, por ejemplo, las organizaciones muestran una tendencia significativa de crecimiento, relacionada con la estrategia de outsourcing [21]. De igual forma, en Colombia, el outsourcing es la categoría de mayor crecimiento respecto a otras categorías relacionadas con las tecnologías de información [22].

Este crecimiento motiva a que muchos investigadores se pregunten ¿cuál es el impacto del outsourcing para las organizaciones, y cuáles son los beneficios y riesgos de este fenómeno? En respuesta a esta pregunta, se generan áreas de estudio para investigar dicho fenómeno, lo que hace que las propuestas relacionadas con el outsourcing tiendan al crecimiento y se despierte interés por la investigación y el estudio de este tema. Sin embargo, una revisión sistemática realizada para establecer los estudios y propuestas, en cuanto a la gestión de riesgos para el outsourcing de software, ha demostrado que existen muy pocas propuestas [23]. Tampoco se han hallado referencias a alguna clasificación o estructura que recoja los riesgos específicos del outsourcing de software y sus categorías, a pesar que las clasificaciones, denominadas taxonomías, son una técnica eficaz para la identificación de riesgos.

Por el contrario, en áreas como el desarrollo de software hay propuestas muy utilizadas, como es el caso del método de identificación de riesgos basado en taxonomías [20]. Este método fue desarrollado originariamente por el SEI, y trabaja agrupando las distintas fuentes de riesgos en varias categorías y proporcionando un cuestionario llamado TBQ (Taxonomy-Based Questionnaire) para realizar un proceso sistemático de identificación. La taxonomía de riesgos presentada por el SEI sigue el tradicional ciclo de vida de desarrollo de software en cascada y provee un marco para organizar los datos y la información.

Dicha taxonomía organiza los riesgos de desarrollo de software en tres niveles, como se muestra en la figura 2. El nivel superior denominado clases, que se subdividen en elementos. Éstos, a su vez, se clasifican por atributos, siendo estos últimos los componentes más específicos de esta taxonomía.

Por los aspectos hasta ahora mencionados, es posible concluir que una taxonomía de riesgos en el área de outsourcing de software, permitirá organizar la información inicial y fundamental para la fase de identificación de riesgos, por consiguiente, apoyar una eficaz consecución del proceso de gestión de riesgos.

Esta afirmación está basada en que, la utilidad de una taxonomía la convierte en una potente herramienta en la organización del conocimiento de la mayoría de dominios [24]. Por esta razón, las disciplinas científicas se benefician de métodos para organizar su área de estudio, en muchos casos bajo el nombre de taxonomías.

Este trabajo propone una taxonomía de riesgos de outsourcing de software. El objetivo principal que se busca con el planteamiento de esta taxonomía es definir un marco de trabajo para organizar y analizar ampliamente los posibles y más comunes incidentes que se puedan presentar en un proyecto de outsourcing de software. A partir de éste, se propone una estructura que facilite la identificación y organización de los riesgos que afectan a un proyecto de outsourcing de software.

Método para construir la Taxonomía de Gestión de Riesgos para Outsourcing de Software

Hay muchos investigadores que trabajan en algoritmos y argumentos matemáticos para la construcción de taxonomías [25]. Algunos utilizan conceptos de análisis formal para extraer las relaciones. Otros utilizan algoritmos automáticos o semi-automáticos para realizar las agrupaciones [24]. Así mismo, existen otras propuestas que se caracterizan por estar basadas en métodos ricos o pobres en conocimientos, algunos utilizando algoritmos automatizados con recursos informáticos, y otros utilizan patrones lingüísticos y semánticos [26].

En general, estos métodos tienen un objetivo concreto, el estudio específico de temas relacionados con el tratamiento y análisis de inmensos repositorios de datos, como es el caso de la web semántica. Por lo tanto, estas investigaciones y propuestas sobre la construcción de taxonomías, se caracterizan porque están compuestas por grandes estructuras y composiciones matemáticas para construir definiciones formales, las cuales son difíciles de reutilizar e implementar en otras áreas de estudio.

Para generar una taxonomía de riesgos propios del outsourcing de software, se requiere un análisis conceptual que difícilmente se puede automatizar por medio de un algoritmo. Es necesario hacer otros procedimientos diferentes a los que se automatizan en los métodos de construcción de taxonomías mencionados anteriormente. Por esta razón, en este trabajo se propone el método MECT (Método para la Construcción de una Taxonomía) que se ha utilizado para desarrollar la estructura de la taxonomía de riesgos propios del outsourcing de software (véase figura 3). Los pasos que componen el método son:

Planificación del contexto, de la audiencia y del contenido: permitirá determinar cuáles son las características del área de conocimiento que se abordará y para la que se quiere desarrollar la taxonomía. Por lo tanto, se deberá hacer una planificación explícita del contexto en el que se enmarcará la taxonomía, la audiencia a la cual estará enfocada y el contenido que la comprenderá.

Delimitación del área de conocimiento: el desarrollo y construcción de una taxonomía de riesgos requiere un esfuerzo para lograr que la estructura de dicha taxonomía cumpla con los objetivos por los cuales se desarrolla. Se debe determinar y definir el enfoque de dicho esfuerzo. Determinar el área de conocimiento y limitar el área de acción de la taxonomía ayudará a centrar el esfuerzo que conlleva su construcción.

Definición de categorías que representan el área de conocimiento: un área de conocimiento suele estar representada por diferentes aspectos que satisfacen sus objetivos generales. La definición de las categorías más representativas del área de conocimiento en la que se pretende construir la taxonomía, es de vital importancia para definir la estructura de la taxonomía. Para esto, MECT propone analizar información concreta de los aspectos considerados en la delimitación (paso anterior), tales como: a) definición de las fuentes: deberán estudiarse y analizarse detenidamente las diferentes fuentes que ofrezcan información útil para la definición de la base fundamental de una taxonomía, llamada en este caso "categorías". Uno de los factores que ayudan a determinar y comprender la información existente sobre el área de conocimiento a tratar son: las fuentes personales, las fuentes documentales y el trabajo relacionado con el área de estudio (taxonomías y clasificaciones existentes). b) mecanismos de extracción: ayudan a organizar la información consultada para determinar las categorías. Existen diferentes mecanismos para organizar y extraer la información. Generalmente organizados en formato de tablas, donde la información puede organizarse de forma estructurada, así los elementos de la tabla se puedan analizar y seleccionar mejor [27].

Establecimiento de la relación entre las categorías: las categorías estarán definidas según la terminología que se utilice en el tema de estudio. Por lo tanto, para poder determinar y formar la estructura que se desea crear es necesario considerar los siguientes aspectos: a) identificar los términos representativos del área de estudio. Dichos términos se podrán deducir del estudio de las fuentes y del manejo del área de conocimiento que se está estudiando, y b) asignar de forma correcta y consistente todos los términos de la taxonomía, que dará lugar a las categorías que estructurarán la taxonomía.

Establecimiento del esquema y estructura de las categorías: para proporcionar un esquema y estructura de acuerdo con las categorías definidas en el paso anterior, se deberá: a) definir los criterios utilizados para dividir y agrupar las categorías, por ejemplo: temas, materias o disciplinas, personas, entidades, destinatarios, procesos, tareas o funciones, actividades, tipos de documentos, entre otros; que dependerán del área de conocimiento que se esté estudiando; y b) establecer una técnica que permita la representación gráfica de los componentes de la taxonomía. MECT propone la utilización de dos técnicas conocidas de procesamiento de información como la técnica Top-Down y la técnica Bottom-up.

Aplicación del método a los riesgos en outsourcing de software

En esta sección se muestra la aplicación del método MECT para la construcción de la taxonomía de riesgos relacionados con los procesos del outsourcing de software.

Planificación del contexto, de la audiencia y del contenido: Los aspectos de planificación del trabajo para construir la taxonomía de riesgos para outsourcing de software se describen en la tabla 1.

Delimitación del área de conocimiento: la delimitación del área de estudio está enmarcada dentro de la disciplina de outsourcing de software, como parte de una metodología de gestión de riesgos para el outsourcing de software. Con dicha metodología se buscará apoyar la gestión de los proyectos de outsourcing dado que: a) hay una tendencia creciente de las organizaciones a adquirir software y b) existen fallos críticos en la gestión en los proyectos de outsourcing [3] relacionados con la gestión de riesgos.

La gestión de riesgos es un área vital dentro de la gestión de proyectos [2], capaz de identificar oportunidades, prevenir problemas e identificar fallos de los proyectos de outsourcing a tiempo [3]; por eso se busca desarrollar una taxonomía de riesgos propios de outsourcing de software como herramienta para la fase de identificación de riesgos.

Definición de categorías que representan el área de conocimiento: para la definición de las categorías que representan la taxonomía propuesta se han llevado a cabo las siguientes actividades:

a) definición de las fuentes: se agruparon como fuentes personales, donde los expertos del equipo de trabajo, redes y grupos de investigación involucrados aportaron tanto conocimientos como experiencia profesional y académica para establecer el contexto del área de conocimiento en estudio; fuentes documentales, documentos representativos que utilizan las categorías que representan la taxonomía, obtenidas a lo largo del desarrollo de una revisión sistemática enfocada al área de conocimiento delimitada en el paso anterior [11]. Dicha revisión sistemática es la mejor fuente de información bajo la cual se sustenta la definición de las categorías por la información que aportó: taxonomías y clasificaciones existentes, encontradas en investigaciones relacionadas con la ingeniería de software [20, 28-30]. A pesar de que el outsourcing de software es un proceso relativamente antiguo [31, 32], su formalización se encuentra en un estado inicial, por lo que no se encontraron taxonomías de riesgos para el outsourcing de software útiles para la definición de las categorías. Por lo tanto, se estudiaron las taxonomías y clasificaciones relacionadas con diferentes áreas de la ingeniería de software [20, 28-30].

b) mecanismos de extracción como entrevistas con integrantes del grupo de investigación y el análisis de los registros documentales, así como clasificaciones consultadas. Además, se utilizó la información recogida del proceso de revisión sistemática [23], donde se realizó la extracción de la información utilizando formatos definidos por algunos autores y adaptados al tema concreto de la gestión de riesgos en el outsourcing de software [11]. Como resultado de este paso, se determinaron las categorías para la taxonomía de gestión de riesgos propios del outsourcing de software que se muestran en la figura 3.

Establecimiento de la relación entre las categorías: la relación entre las categorías se estableció según los siguientes criterios: a) identificación de los términos representativos del outsourcing de software. Dichos términos se deducen a partir del estudio de las fuentes; b) asignación de términos a cada componente de la taxonomía, que da lugar a las categorías que estructurarán la taxonomía; y c) revisión y análisis de documentación e información del ámbito del outsourcing y gestión de proyectos tales como: estándar ISO/IEC 12207 [13] Information Technology/Software Life Cycle Processes, modelo CMMI-ACQ [3], modelo eSCM [15], informe en el que el Standish Group [33], informes de U.S. Govermment Accountability Office (GAO) particularmente los relacionados con: Challenges in Aligning Space System Components [34], Many Analyses of Alternatives Have Not Provided a Robust Assessment of Weapon System Options [35], Opportunities Exist to Achieve Greater Commonality and Efficiencies among Unmanned Aircraft Systems [36], Issues to be Considered for Army's Modernization of Combat Systems [37], DoD Faces Substantial Challenges in Developing New Space Systems [38]. Así mismo las taxonomías y clasificaciones relacionadas con la ingeniería de software, tales como taxonomías de riesgos para el desarrollo de software [20, 28], la taxonomía relacionada con requisitos de seguridad [29], donde se define una taxonomía unificada de referencia de fallos accidentales de software crítico [30] y los estudios e información recogida en la revisión sistemática, que dieron un enfoque específico a la taxonomía de riesgos propios del outsourcing de software.

Establecimiento del esquema y estructura de las categorías: en el siguiente apartado se presenta la estructura de la taxonomía de riesgos para el outsourcing de software. El esquema fue establecido utilizando la propuesta del método MECT.

Estructura base de la Taxonomía de Riesgos del Outsourcing de Software: después de aplicar los pasos propuestos en el método MECT, y con el fin de establecer la taxonomía de riesgos de outsourcing de software que se propone en este trabajo, se define una estructura de árbol para esta taxonomía. Esta estructura se diseñó utilizando la técnica top-down, tal como se muestra en la figura 4 .

A continuación, se describe cada una de las categorías que integran la taxonomía.

Acuerdos y contratación del proveedor: se refiere a las actividades involucradas en los procesos que se llevan a cabo para conseguir los acuerdos entre el proveedor-adquiriente, además de los que se consideran para preparar el paquete de solicitud de la propuesta de outsourcing, la selección de posibles proveedores y el establecimiento de los acuerdos.

Entorno de desarrollo: cubre los aspectos relacionados con el desarrollo de los requerimientos del outsourcing y la gestión técnica de la misma, tanto contractuales como del cliente. Además, agrupa las actividades que se llevan a cabo para evaluar la solución técnica que el proveedor está desarrollando y que se usan para gestionar las interfaces de la solución que se está adquiriendo.

Ingeniería del outsourcing: cubre los procesos relacionados con la validación y verificación del producto. Esta categoría ha sido definida con el fin de agrupar las actividades que se llevan a cabo para el proceso de outsourcing de software que están relacionadas con la comprobación de que el producto software adquirido cumple con el uso previsto establecido dentro de su entorno. Además, esta categoría agrupa las actividades que se llevan a cabo para garantizar que los productos de trabajo definidos y seleccionados cumplen los requerimientos especificados.

Conclusiones

Este trabajo propone una taxonomía de riesgos para el outsourcing de software, clasificándolos por medio de categorías, elementos y atributos.

La estructura de la taxonomía que se propone, se deriva del estudio de los problemas que suelen presentarse en outsourcing de software, afectando a su calidad [39] y a la experiencia de expertos en proyectos de outsourcing.

Esta estructura inicial puede considerarse como una "taxonomía pre-elaborada" que cada vez que interactúe con los proyectos de outsourcing tendrá un refinamiento.

La gestión de riesgos es un proceso fundamental para la gestión de proyectos, que posibilita un entorno ordenado para tomar decisiones y controlar, de forma reactiva, los problemas de un proyecto de outsourcing de software, por lo que se considera que: a) La identificación de riesgos es una actividad principal del proceso de gestión de riesgos. Es el punto de partida que determina la efectividad del proceso de gestión de riesgos. Por lo tanto, es indispensable utilizar técnicas de identificación de riesgos para llevar a cabo esta actividad. b) Las taxonomías de riesgos se consideran una técnica estructurada de categorización de riesgos típicos de cualquier proyecto. c) Una taxonomía de riesgos, en el ámbito del outsourcing de software, juega un papel fundamental para conseguir categorizar y estructurar los riesgos en este ámbito.

Referencias

1. R. S. Pressman. Ingeniería de Software. Un enfoque práctico. 6^a ed. Ed. McGraw Hill. Madrid. 2006. pp.  958.         [ Links ]

2. J. Persse. Project Management Success with CMMI. Harlow. Ed. Prentice Hall. 2007. pp. 254.         [ Links ]

3. Software Engineering Institute. CMMI for Acquisition, Version 1.2, CMMI-ACQ. Ed. Carnegie Mellon. Pittsburgh. V1.2. 2007 pp. 81 - 392.         [ Links ]

4. Software Engineering Institute. CMMI for Development, Versión 1.2. Software Engineering Institute Carnegie Mellon. Carnegie Mellon. Pittsburgh. 2006. pp. 115--351.         [ Links ]

5. IEEE Computer Society. A Guide to the Project Management Body of Knowledge, IEEE Guide Adoption of PMI Standard. 2004. pp. 25-187.         [ Links ]

6. K. Dodson, H. Hofmann, G. Ramani, D. Yedlin. "Adapting CMMI for Acquisition Organizations: A Preliminary Report". SEI. Vol. 1. 2006. pp. 8-335.         [ Links ]

7. R. Charette. Software engineering risk analysis and management. Ed. McGraw-Hill. Inc. New York. 1989. pp. 325.         [ Links ]

8. Office of Government Commerce. Managing Successful Projects with PRINCE2:2009. United Kingdom and other countries. 23 September. 2009. pp. 19-51.         [ Links ]

9. R. E. Barbour, M. Carr, A. J. Dorofee, R. P. Higuera, S. L. Konda, S. L. S., J. A. Walker. "Software Acquisition Risk Management Key Process Area (KPA) - A Guidebook Version 1.0". SEI. Carnegie Mellon University. Vol. 1. 1997. pp. 18.         [ Links ]

10. Y. Y. H. Ronald, P. Higuera. "Software Risk Management". Carnegie Mellon University, Pittsburgh. 1996. Vol. 1. pp. 19-35.         [ Links ]

11. J. A. Calvo-Manzano, G. Cuevas, G. Gasca, T. A. San Feliu, V. Vega. Revisión Sistemática para la Gestión de Riesgos en la Adquisición de Software. Actas 3^a Conferencia Ibéricas de Sistemas y Tecnologías de la Información. Vol. 1. 2008. pp. 321-334.         [ Links ]

12. J. A. Cooper, M. Fisher. "Software Acquisition Capability Maturity Model v1.03". Software Engineering Institute Carnegie Mellon. Vol. 1. 2002. pp. 2-14.         [ Links ]

13. International Organization for Standarization. Systems and software engineering -Software life cycle processes, ISO/IEC 12207. Vol. 1. 2008. pp. 51-98.         [ Links ]

14. T. Bernard, B. Gallagher, R. A. Bate, H. Wilson. "CMMI Acquisition Module, Version 1.1". SEI, Carnegie Mellon. Vol. 1. 2005. pp. 11-31.         [ Links ]

15. ITSqC Carnegie Mellon. Comparing the eSCM-CL and CMMI Pittsburgh. Carnegie Meellon University. Vol. 1 2005. pp. 14-19.         [ Links ]

16. R. Singh. "International Standard ISO/IEC 12207 Software Life Cycle Processes". Federal Aviation Administration. Vol. 1. 1995. pp. 45-53.         [ Links ]

17. J. Van Bon, T. Verheijen. Frameworks for IT Management. 1^st ed. Ed. Van Haren Publishing. Amersfoort. 2006. pp. 22-117.         [ Links ]

18. R. T. Futrell, D. F. Shafer, I. L. Shafer. Quality software Project Management. Prentice Hall. United State of Amercia. 2002. pp. 73-178.         [ Links ]

19. Office of Government Commerce. Managing Successful Projects with PRINCE2. 4^a ed. Ed. Stationery Office. 2005. pp. 25-53.         [ Links ]

20. M. J. Carr, S. L. Konda, I. Monarch, F. C. A. Ulrich, C. F. Walker. "Taxonomy-Based Risk Identification". SEI. Vol. 1. 1993. pp. 7-21.         [ Links ]

21. R. Maria, G. Jose, L. Juan. "El outsourcing de sistemas de información: un estudio descriptivo y longitudinal". Universia Busness Review. Vol. 1. 2007. pp. 86-103.         [ Links ]

22. J. E. Parra. "Critical Factors of Success and Hypothesis about the Software Industry in Colombia Contextual and Academic Considerations". Revista de Avances en Sistemas e Informática. Vol. 5. 2008. pp. 185-193.         [ Links ]

23. J. A. Calvo-Manzano, G. Cuevas, G. Gasca, T. San Feliu. "State of the art for risk management in software acquisition". ACMSigSoft. Vol. 34. 2009. pp. 1-10.         [ Links ]

24. P. Kunal, R. Suju, G. Joydeep. Automatic Construction of N-ary Tree Based Taxonomies. Proceedings of the Sixth IEEE International Conference on Data Mining - Workshops: IEEE Computer Society. 2006. pp. 75-79.         [ Links ]

25. M. Neshati, L. S. Hassanbadi. "Taxonomy Construction Using Compound Similarity Measure". Lecture Notes in Computer Science. Vol. 4803. 2007. pp. 915-932.         [ Links ]

26. M. Neshati, A. Alijamaat, H. Abolhassani, A. Rahimi, M. Hoseini. "Taxonomy Learning Using Compound Similarity Measure". Proceedings of the IEEE/WIC/ACM International Conference on Web Intelligence.IEEE Computer Society. 2007. pp. 487-490.         [ Links ]

27. D. Cruzes, M. Mendonça, V. Basili, F. Shull, M. Jino. Extracting Information from Experimental Software Engineering Papers. SCCC, XXVI International Conference of the Chilean Society of Computer Science (SCCC'07). 2007. pp. 105-114.         [ Links ]

28. R. P. Kendall, D. E. Post, J. C. Carver, D. B. Henderson, D. A. Fisher. "A Proposed Taxonomy for Software Development Risks for High-Performance Computing (HPC) Scientific/Engineering Applications". Software Engineering Institute, Carnegie Mellon. Vol. 1. 2007. pp. 1-27.         [ Links ]

29. D. Firesmith. "A Taxonomy of Security-Related Requirements". Software Engineering Institute, 2005. White paper. Acceso el 03 de marzo de 2011. Disponible en: http://www.sei.cmu.edu/library/abstracts/whitepapers/taxonomysep2005.cfm         [ Links ]

30. P. López Peña. "Taxonomía Unificada de Referencia de Fallos Accidentales de Software crítico". Lenguajes, sistémas informáticos e Ingeniería de Software. PhD Madrid: Universiad Politécncia de Madrid. Vol. 1. 2005. pp. 172.         [ Links ]

31. L. Jae-Nam, Q. H. Minh, C.-w. Kwok Ron, P. Shih- Ming. "IT outsourcing evolution-: past, present, and future". Commun. ACM. Vol. 46. 2003. pp. 84-89.         [ Links ]

32. L. Jae-Nam, Q. H. Minh, C.-w. Kwok Ron, P. Shih- Ming. The Evolution of Outsourcing Research: What is the Next Issue?. Proceedings of the 33rd Hawaii International Conference on System Sciences. Vol. 7. 2000. pp. 10.         [ Links ]

33. The Standish Group International. Caos: A recipe for success. 1999. Acceso 09 de Marzo de 2011. Disponible en http://www4.informatik.tu-muenchen.de/lehre/vorlesungen/vse/WS2004/1999_Standish_Chaos.pdf         [ Links ]

34. United States Government Accountability Office. Challenges in Aligning Space System Components. Report GAO-10-55. Report to the Chairman, Subcommittee on Defense, Committee on Appropriations, House of Representatives. United State of America. 2009. pp. 1-37.         [ Links ]

35. United States Government Accountability Office. Many Analyses of Alternatives Have Not Provided a Robust Assessment of Weapon System Options. Report GA0-09-655. Report to the Chairman, Subcommittee on Defense, Committee on Appropriations, House of Representatives. 2009. pp. 1-33.         [ Links ]

36. United States Government Accountability Office. Opportunities Exist to Achieve Greater Commonality and Efficiencies among Unmanned Aircraft Systems. Report GA0-09-520. Report to the Chairman, Subcommittee on Defense, Committee on Appropriations, House of Representatives. 2009. pp. 1-68.         [ Links ]

37. United States Government Accountability Office. Issues to be Considered for Army's Modernization of Combat Systems. Report GA0-09-793T. Testimony Before the Subcommittee on Airland, Committee on Armed Services, U.S. Senate. 2009. pp. 1-14.         [ Links ]

38. United States Government Accountability Office. DOD Faces Substantial Challenges in Developing New Space Systems. Report GA0-09-705T. Testimony Before the Subcommittee on Airland, Committee on Armed Services. U.S. Senate. 2009. pp. 1-16.         [ Links ]

39. R. A. Simmons. Software quality assurance (SQA) early in the acquisition process. Aerospace and Electronics Conference. Vol. 2. 1990. pp. 664-669.         [ Links ]

(Recibido el 8 de julio de 2010. Aceptado el 14 de julio de 2011)

^*Autor de correspondencia: teléfono: + 57 + 4 + 340 5534, fax: + 57+ 4 +340 5216, correo electronico: gpgasca@udem.edu.co (G. Gasca)