Modelo para el análisis de riesgos en Líneas de Productos de Software

Model for risk analysis of Software Product Lines

]]> Vladimir Martell-Fernández^*1, Yeleny Zulueta-Veliz²

¹ Centro de Geoinformática y Señales Digitales. 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
² Decana. 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

* Autor para correspondencia: yvalrod@uci.cu

RESUMEN

En la actualidad, existen diferentes propuestas para gestionar los riesgos en un proyecto, la mayoría están compuestas por cuatro procesos principales, el análisis de los riesgos, en particular, forma parte de cualquiera de estas propuestas. No obstante los múltiples modelos, procedimientos, procesos, métodos y técnicas que pueden ser consultados para desarrollar el análisis de riesgos en particular, aún hoy para las Líneas de Productos de Software no existe un enfoque propio que enfatice en el análisis de los riesgos asociados a los “activos”, concepto muy vinculado al modelo de producción basado en Líneas de Productos de Software. Este artículo pretende elaborar un modelo para desarrollar el proceso de análisis de riesgos en Líneas de Productos de Software, que incluya, una solución de toma de decisiones multicriterio y multicriterio dinámica, para evaluar adecuadamente los riesgos con influencia sobre uno o varios activos y donde un activo pueda a su vez influir sobre otro, además de incluir las evaluaciones históricas de los riesgos y el concepto de facilidad de detección de un riesgo. El análisis de los resultados evidencia diferencias significativas una vez aplicado el modelo en las Líneas de Productos de Software seleccionadas.

]]> Palabras clave: Análisis dinámico, evaluación de riesgos, líneas de productos de software.

ABSTRACT

Currently, there are different approaches to managing risks in a project, most are composed of four main processes, the analysis of risks, in particular part of any of these proposals. Despite the multiple models, procedures, processes, methods and techniques that can be consulted to develop risk analysis in particular still for Software Product Lines there is no unique approach that emphasizes the analysis of the risks associated with the "active" concept closely linked to the production model based on Software Product Lines. This article aims to develop a model to develop the risk analysis process in Software Product Lines, including a solution of multicriteria decision making and multi dynamic to adequately assess the risks to influence one or more assets and where an asset to your time influence another, and includes historical assessments of the risks and the concept of ease of detection of a risk. The analysis of the results shows significant differences after applying the selected Software Product Lines model.

Key words: Dynamic analysis; evaluation, risks, software product lines.

INTRODUCCIÓN

]]> La reutilización de software ha aumentado en los últimos años como consecuencia de la demanda creciente de productos con mayor calidad, con menores costos y desarrollados en menor tiempo y la necesidad de las empresas productoras de software de satisfacer la demanda sin disminuir la calidad de sus producciones.  Su evolución creciente y acelerada en los últimos años indica un giro de atención importante y necesario hacia lo que significa desarrollar software “reutilizando” (Olalde, 2006).

Las Líneas de Productos de Software (LPS) se presentan como un modelo de producción dirigido a obtener productos y servicios informáticos en menor tiempo, con menores costos de producción y de alta calidad (Bastarrica 2008). Para obtener lo anterior es necesario comprender qué puede ir mal y cómo hacerlo bien, regla primordial según Pressman para gestionar cualquier proyecto con éxito (Pressman, 2005). Varios autores le denominan riesgos a estos eventos que pueden ocurrir o no y que ocasionan cambios en los objetivos de un proyecto u organización (Boehm, 1989; Ciao, 2000; Colectivo_de_autores 2005; Charette, 1989; Dorofee, Audrey and Alberts, 2009; Dorofee, et al., 1996; Heredia, 1995).

En la actualidad, existen diferentes propuestas para gestionar los riesgos en un proyecto (BSI 2002), (APM 2004), (IEC 1995) y (IEEE 2001), la mayoría están compuestas por cuatro procesos principales: la identificación de los riesgos, el análisis de los riesgos, la preparación de la respuesta a los riesgos y el seguimiento y control de estos. El análisis de los riesgos, en particular, forma parte de cualquiera de estas propuestas.

No obstante los múltiples modelos, procedimientos, procesos, métodos y técnicas que pueden ser consultados para desarrollar la gestión de riesgos y el análisis de riesgos en particular, aún hoy para las Líneas de Productos de Software (LPS) no existe un enfoque propio que enfatice en el análisis de los riesgos asociados a los “activos”, concepto muy vinculado al modelo de producción basado en LPS. Por otra parte, tampoco se utilizan las evaluaciones pasadas otorgadas a un riesgo en el análisis y evaluación posterior lo cual provoca que se obtenga una evaluación representativa del momento pero no representativa de la evolución del riesgo en cuestión. Finalmente, y como consecuencia de la gestión simultanea de gran cantidad de riesgos de distintos proyectos, no se considera la facilidad de detección de la materialización de un riesgo en la LPS para otorgar una criterio de exposición al riesgo integralmente.

Este artículo pretende elaborar un modelo para desarrollar el proceso de análisis de riesgos en LPS, que incluya, una solución de toma de decisiones multicriterio para la evaluación de los riesgos con influencia sobre uno o varios activos y donde un activo pueda a su vez influir sobre otro, la propuesta contiene además una solución de toma de decisiones multicriterio y dinámica que permite utilizar las evaluaciones pasadas de los riesgos en el proceso de evaluación actual. Finalmente, se propone la inclusión del valor de facilidad de detección del riesgo que permite evaluar justamente al riesgo que es más difícil de detectar.

MATERIALES Y MÉTODOS

]]> La evaluación de los riesgos en las principales LPS

Modelo de LPS presentado por el Instituto de Ingeniería de Software (SEI, por sus siglas en inglés)
El principal esfuerzo en la gestión de riesgos para el SEI debe estar al momento de la puesta en marcha de la LPS debido a que las principales decisiones se toman al inicio. La propuesta concreta del SEI se denomina Paradigma de Gestión de Riesgos Continuo y en él los riesgos se identifican por primera vez y luego se analizan para determinar su probabilidad de ocurrencia y el impacto (exposición al riesgo) sobre la organización, los planes de mitigación se desarrollan en las áreas de riesgo más importantes, y las decisiones de control (cierre, re-planificación, u otras) están debidamente documentadas.

Este enfoque de riesgos para LPS requiere una íntima asociación entre los desarrolladores de activos de software y los desarrolladores de productos, de ahí que esta propuesta introduzca el concepto de Equipo de Gestión de Riesgos que afecte a toda la línea y “escuche” todas las partes. La evaluación de los riesgos no queda definida explícitamente, aún cuando se evidencia una tendencia a la utilización de la probabilidad y el impacto para su cálculo. No contiene las actividades de evaluación de riesgos formalmente descritas, además, no incluye las evaluaciones históricas ni considera el impacto de los activos y su importancia dentro de la LPS (Sei, 2009).

Proceso Ingenieril Evolutivo de LPS (ESPLEP por sus siglas en ingles)

ESPLEP es un modelo de desarrollo de software donde los productos evolucionan a través de iteraciones, el modelo elimina la distinción tradicional entre el desarrollo y mantenimiento de software.

Este modelo no contempla actividades relacionadas con la gestión del alcance y el costo de la línea ni la gestión o evaluación de los riesgos, tampoco incluye actividades relacionadas con la gestión de recursos humanos.

WATCH

Es un modelo de procesos o marco metodológico orientado al desarrollo de aplicaciones empresariales, y de proyectos de software de pequeño o mediano tamaño. Integra aspectos de los modelos y métodos: ingeniería de software basada en componentes, modelo espiral, desarrollo incremental y por versiones.

Las principales deficiencias radican en la no especificación de actividades asociadas a la gestión de riesgos, de costos, ni a la mejora continua, no contempla explícitamente la reutilización de componentes y las actividades asociadas a la gestión de los recursos humanos contempla únicamente el adiestramiento de la fuerza laboral (Pino, 2011). ]]> TWIN

Este modelo incorpora explícitamente la reutilización de software en el proceso de desarrollo de aplicaciones. La esencia de este modelo son los procesos de desarrollo de activos reutilizables y de desarrollo de aplicaciones basadas en la reutilización. Sus principales elementos negativos radican, en sintonía con las limitaciones de los modelos anteriores, en las actividades asociadas a los recursos humanos y la gestión de costos (Jonás, et al., 2004). La evaluación de riesgos ni siquiera es tenida en cuenta dentro de estas actividades.

La base de datos relacional maneja los requerimientos de almacenamiento de datos, y el motor ROLAP proporciona la funcionalidad analítica. El nivel de base de datos usa bases de datos relacionales para el manejo, acceso y obtención del dato. El nivel de aplicación es el motor que ejecuta las consultas multidimensionales de los usuarios.

CAFÉ

Proyecto europeo resultado de la combinación de tres modelos diferentes: ciclo de vida de una organización que trabaja en el campo de las Tecnologías de la Información, Entorno de Procesos ISO/IEC 15504 y Modelo de referencia CAFE (CAFE CRM).

El modelo no define actividades que incluyan la gestión del repositorio de los activos generados, no incluye explícitamente elementos de retroalimentación a partir de los activos o productos desarrollados. Este modelo, a diferencia de todos los anteriores, ni siquiera incluye actividades referidas a la Gestión o Evaluación de los riesgos dentro de su propuesta.

Modelo para LPS de la Universidad de las Ciencias Informáticas

Este modelo está basado en los principios de LPS y el proceso de desarrollo está representado por seis entidades que lo soportan completamente como proceso de producción. Cada una de estas entidades cubre un área importante dentro de la línea y garantizan que se involucren todos los miembros en el modelo y las responsabilidades individuales de cada miembro de la organización en la calidad y la productividad.

Las actividades referidas a los riesgos son tratadas con exhaustividad y profundidad, identificándose acciones para la planificación, identificación análisis, seguimiento y control de los riesgos en cada una de las fases que propone.

La actividad referida a la conformación del expediente de la Línea tiene en cuenta la gestión de riesgos y asegura el espacio necesario para su documentación. ]]> Otro elemento importante en la atención a los riesgos de la propuesta de (Pino, 2011) es la definición de los reportes requeridos para la toma de decisiones, dentro de los cuales se definieron a nivel de proyecto los reportes de estado de los riesgos y criticidad de los riesgos.

Las actividades referidas a la Evaluación de los riesgos se desarrollan de acuerdo a las especificaciones del PMI (PMI, 2009) por lo cual están expuestas a sus limitaciones, al mismo tiempo que no se desarrollan con un enfoque claro hacia LP.

RESULTADOS Y DISCUSIÓN

El modelo está dividido en cuatro actividades fundamentales, cada una de ellas con entradas, salidas e involucrados así como las acciones necesarias para ser ejecutadas.

Actividades y acciones del modelo

Actividad 1: Estimación de la facilidad de detección de los riesgos

Técnicas y Herramientas:

Se utilizará la técnica de Tormenta de ideas (Hurtado, 2010) para, a través de un taller técnico, reunir al Equipo de Gestión de Riesgos (en lo adelante EGR), y dirigidos por el Analista de riesgos, determinar por cada uno de los riesgos identificados su facilidad de detección.

Definición 1: La facilidad de detección de un riesgo (Fd) se define como un valor en el intervalo normalizado [0,1] que indica en mayor o menor medida qué tan fácil es detectar la materialización de un riesgo como una situación inminente en la organización.

Descripción:

El Analista de riesgos enunciará cada riesgo y de conjunto con el EGR determinarán los valores de Fd para cada uno.

Debe utilizarse la escala de valores propuesta en la Tabla 1:

Actividad 2: Estimación de la probabilidad de ocurrencia de los riesgos ]]> Acción 2.1: Determinación de la probabilidad de ocurrencia de cada riesgo.

Técnicas y Herramientas:

Se utilizará la técnica de Tormenta de ideas (Hurtado, 2010). A través de un taller técnico, se reúne al EGR y dirigidos por el Analista de riesgos se determina por cada uno de los riesgos identificados su probabilidad de ocurrencia.

Definición 2: La probabilidad de ocurrencia (Po) se refiere a la probabilidad de un riesgo de materializarse en la práctica como un hecho real, tiene implícito en su cálculo la cantidad de veces que debe ocurrir.

Descripción:

El Analista de riesgos enuncia cada riesgo y se determina para cada uno su valor de Po durante la ejecución del proyecto. Debe utilizarse la escala de valores de la Tabla 1.

Actividad 3: Estimación del impacto de los riesgos sobre los activos

Acción 3.1: Estimación del impacto de los activos del proyecto.

Esta acción está dirigida a establecer los valores de impacto de los activos del proyecto de acuerdo a su relevancia. Es desarrollada por el EGR y dirigida por el Analista de riesgos.

Técnicas y Herramientas: ]]> Se utilizará la técnica de Análisis AHP diseñada para obtener una escala numérica y dar prioridades a las alternativas de decisión, permitiendo determinar soluciones (Jiménez and Cuesta, 2010).

La estructura jerárquica, de acuerdo a lo que propone AHP, queda como se muestra en la Figura 1 donde el segundo nivel corresponde a los activos y el tercer nivel corresponde a los riesgos que afectan a cada uno de los activos.

Descripción:

El Analista de riesgos ubica en la estructura anterior cada uno de los activos identificados y los riesgos que afectan esos activos. Luego de ubicados, el EGR desarrolla una comparación binaria que no es más que evaluar la importancia relativa de un activo frente a otro para el proyecto. El grado de importancia relativa o preferencia se expresa a través de la escala de la Tabla 2.

Suponiendo que el EGR es consciente de la emisión de juicios sobre cualquier par de activos se denominará aij al valor obtenido de la comparación del activo Ai con respecto al activo Aj (grado de importancia relativa o preferencia). Cada uno de los valores aij deben ubicarse en la matriz siguiente:

Una vez obtenida esta matriz, los valores deben ser normalizados y ubicados en la matriz normalizada siguiente: ]]>

Finalmente, el peso de cada activo (WA) se obtiene a partir del promedio de la fila correspondiente de la matriz normalizada.

Definición 3: El impacto de los activos del proyecto (IA) se corresponde con el peso (WA) que se obtiene de la matriz normalizada.

Acción 3.2: Determinación del impacto de los riesgos sobre los activos del proyecto.

Esta acción está dirigida a determinar el impacto de los riesgos sobre los activos del proyecto incluyendo el impacto de los activos de la acción anterior. Es desarrollada por el EGR y dirigida por el Analista de riesgos.

Técnicas y Herramientas:

Se utilizará la técnica de Análisis AHP diseñada para obtener una escala numérica y dar prioridades a las alternativas de decisión, permitiendo determinar soluciones (Jiménez and Cuesta, 2010).

Descripción:

Igualmente los datos deben ser ubicados en la matriz recíproca de comparaciones como la que se muestra en la Matriz.

1. Una vez obtenidos los valores se completa la matriz normalizada de la Matriz 2, calculándose el peso de los riesgos sobre el activo. (WRA). A partir del cálculo de WRA se calcula el Impacto de los Riesgos sobre los activos (IRA).

Definición 4: El impacto de un riesgo sobre los activos del proyecto es la acumulación del impacto de todos los activos que afecta y el peso obtenido por el riesgo en el análisis comparativo del activo correspondiente.

Actividad 4: Priorización de los riesgos

Acción 4.1: Obtención de la exposición a cada riesgo.

Esta acción está diseñada para determinar el valor de exposición a cada uno de los riesgos en el proyecto, es desarrollada por el Analista de riesgos a través de una de las dos formas siguientes:

Variante 1: A través de la Suma ponderada

Técnicas y Herramientas:

Descripción:

El cálculo de la exposición a cada riesgo (ER) se determina con los valores de facilidad de detección (Fd), probabilidad de ocurrencia (Po) e impacto sobre los activos (IRA); no obstante, debido a lo variable que puede ser el nivel de importancia que tengan estos tres parámetros de un proyecto a otro, se propone valorizar esta importancia a través de un peso de manera que sea posible establecer diferencias entre ellos de acuerdo al proyecto.

Definición 5: Se le denomina peso asociado al parámetro (wFd, wPo o wIRA) al nivel de importancia de éste dentro del proyecto. Estos valores son normalizados en la escala [0,1] y pueden variar de acuerdo al criterio del EGR de un proyecto a otro.

Definición 6: La exposición al riesgo (ER) se determina como la combinación de los pesos asociados al parámetro con el valor del parámetro en cada caso.

Variante 2: A través del Análisis dinámico

Herramientas y técnicas:

Se utilizará la técnica de Análisis dinámico para obtener la evaluación de cada riesgo principalmente durante el proceso de re-estimación de que son objeto cada uno de ellos una vez que se han ejecutado las acciones de mitigación y/o contingencia

Siendo:

La Función de análisis dinámico se define formalmente como:

Una vez calculada la exposición dinámica de los riesgos, estos podrán ser ordenados por el valor descendente de Et.

Esta acción está encaminada a definir los umbrales de atención (inmediata, rápida, moderada y ninguna) de los riesgos definidos de acuerdo al valor de exposición establecido en la acción anterior.

Técnicas y Herramientas:

Se utilizará la técnica de evaluación de los umbrales de atención. Es desarrollada por el Analista de riesgos de conjunto con el Líder de la LPS y pretende establecer los umbrales dentro del listado ordenado de los riesgos según su exposición.

Descripción:

En la determinación de los umbrales de atención a los riesgos pueden utilizarse dos variantes: según la prioridad de los activos y según la prioridad de los riesgos. El Analista de riesgos y el Líder de la LPS son los encargados de determinar la variante.

Variante 1: Según la prioridad de los activos

Esta variante consiste en utilizar los valores de prioridad de los activos para atender a los riesgos que los afectan. El Analista de riesgos, de conjunto con el Líder de la LPS, determinan los activos que deben ser atendidos teniendo en cuenta la implicación dentro del proyecto.

Una vez realizado lo anterior, se especificarán todos los riesgos contenidos dentro de los activos seleccionados respetando el orden de prioridad de los activos y luego el de los riesgos por cada activo.

Confeccionada la lista, el Líder de la LPS y el Analista de riesgos determinan los riesgos que recibirán atención inmediata, rápida o moderada además de los riesgos que no recibirán atención.

Esta variante consiste en utilizar los valores de exposición de los riesgos ordenándolos en orden descendente. Una vez ordenados el Líder de la LPS y el Analista de riesgos determinan los riesgos que recibirán atención inmediata, rápida o moderada además de los riesgos que no recibirán atención.

En cualquiera de las dos variantes los umbrales pueden ser delimitados de acuerdo a varios criterios: el impacto del proyecto en la LPS, las condiciones adversas o no del desarrollo, motivación y/o compromiso del equipo y del cliente, la composición del EGR y de los implicados en la atención a los riesgos.

Análisis de los resultados

La validación de la propuesta se realizó en tres LPS del Departamento de Geoinformática en la Universidad de las Ciencias Informáticas: Aplicativos SIG, SIG-Desktop y SIG-Móviles.

Estas tres LPS tienen como misión desarrollar productos y soluciones informáticas que sirvan de apoyo a la toma de decisiones y contribuyan al seguimiento y control de la información socioeconómica de cualquier sector de la sociedad a partir de su representación y análisis espacial en la web, en ambiente de escritorio o para dispositivos móviles respectivamente. Cada una de ellas cuenta con una organización similar dividida en áreas de trabajo, coincidiendo en grupos de análisis, arquitectura, codificación y gestión.

En este análisis se utilizó el método de conjuntos borrosos con números borrosos triangulares a través de la encuesta como instrumento de recopilación de información. Fueron encuestados todos los miembros de las tres LPS del Departamento, en total 21 personas. Los 21 participantes fueron encuestados a través de un cuestionario con 7 criterios a valorar referidos a la usabilidad del modelo y su enfoque hacia LPS. Luego de tabulados y normalizados, y al ser ubicados en la escala nominal propuesta resulta como se muestra en la Tabla 3:

El resultado anterior obtenido indica una valoración alta del indicador Usabilidad basado en la comprensión, la complejidad y la completitud de la propuesta. Se considera una valoración apropiada y de acuerdo con la opinión y aceptación de los autores.

Se definieron además, tres indicadores que fueron medidos a través de un quasi experimento, la desviación de los cronogramas, la correspondencia del alcance pactado con el alcance final obtenido y los riesgos gestionados. Estos tres indicadores, en resumen, pretenden demostrar la contribución de la propuesta en función del cumplimiento de los objetivos del proyecto (alcance, costo y tiempo) (PMI, 2009).

Indicador desviación de los cronogramas

En el análisis y evaluación de la desviación de los cronogramas se utilizaron los datos referidos a los tiempos de desarrollo propuestos y los tiempos de desarrollo reales empleados por los proyectos de ambos grupos de comparación. Se define como desviación de los cronogramas al porciento que representa el excedente consumido en los proyectos con respecto al tiempo de producción pactado.

En la Figura 2 se muestra la considerable disminución de la desviación de los cronogramas luego de aplicada la propuesta. No obstante, se desarrolló el test de Mann-Whitney para su demostración estadística.

Indicador correspondencia del alcance pactado con el alcance final obtenido

En el análisis de la correspondencia del alcance pactado con el alcance final obtenido se utilizaron los datos de cada proyecto relacionados con la cantidad de Requisitos Funcionales (RF) que fueron pactados y la cantidad de RF aceptados sin modificación durante el desarrollo, obteniendo una medida del cumplimiento del alcance propuesto. Se define como desviación del alcance al porciento que representa la cantidad de requisitos modificados contra la cantidad de requisitos pactados.

Las significativas diferencias entre las desviaciones de los dos grupos pueden corroborarse a partir de la Figura 3.

Igualmente, se desarrolló el test de Mann-Whitney para la demostración estadística.

En la evaluación y análisis del indicador que mide la cantidad de riesgos gestionados se utilizaron los datos con respecto a la gestión de los riesgos archivados en los expedientes de cada uno de los proyectos desarrollados antes de aplicado el modelo; igualmente, se obtuvieron los datos de los proyectos que se desarrollaron aplicándolo.

El análisis graficado que se presenta en la Figura 4 muestra el significativo aumento de las posibilidades de gestión de un riesgo desde el inicio hasta el fin del ciclo de vida de los proyectos una vez implementado el modelo.

CONCLUSIONES

El desarrollo de productos de software bajo el esquema de producción basado en LPS proporciona beneficios considerables en cuanto a la calidad de los productos obtenidos, el costo y el tiempo.

para su obtención. No obstante, introduce elementos distintivos en su construcción referidos fundamentalmente al factor de reutilización y la gestión organizacional concebida para todos los productos a la vez. ]]> La evaluación de los riesgos en las propuestas de gestión de riesgos actuales no contienen un enfoque hacia activos de software que permita evaluarlos de acuerdo a su impacto dentro de la LPS, la mayoría de las propuestas utilizan únicamente los tradicionales probabilidad e impacto para evaluar el efecto de un riesgo para una organización, algunas, incluso, no comprenden las actividades referidas a la evaluación, limitándose únicamente a destacar la importancia de la gestión de riesgos como parte del proceso de Gestión de Proyectos.

La propuesta de modelo para la evaluación de los riesgos, que centra la atención en los activos, el riesgo para los activos y su impacto dentro del proyecto y la LPS proporciona un acercamiento real y una estimación más acertada de las consecuencias en cada caso al no tener en cuenta únicamente los tradicionales “probabilidad e impacto” sino también el impacto asociado a los activos considerando los niveles de importancia relativos a ellos.

La facilidad de detección permite desarrollar la exposición al riesgo de manera más acertada al considerar el factor sorpresa del riesgo como elemento de peso. El Análisis Dinámico permite contar con la evolución histórica del riesgo y su evaluación considera esta evolución al momento de su priorización, obteniéndose una prioridad más integral.

El proceso de validación de la solución evidencia niveles de aceptación altos y una real contribución a la obtención de los objetivos a alcanzar en los proyectos de la LPS evidenciados en la disminución promedio de un 5% en la desviación de los cronogramas pactados, reduciendo los máximos locales desde 37.1 % del grupo de control hasta 16.3% del grupo experimental.

Por otra parte, se aumenta un 12.8 % en la coherencia entre el alcance pactado y el alcance entregado, logrando máximos locales desde 37.5 % en el Grupo de Control hasta 25 % de desviación en el Grupo Experimental. Finalmente, la introducción del modelo permite identificar 11 riesgos como promedio más que desarrollando el proceso de evaluación de riesgos sin él.

BIBLIOGRAFÍA

APM. Project Risk Analysis and Management (PRAM) Guide. 2da edición. Ohio, Association for Project Management, 2004. p. 157.

BASTARRICA, M. C. Desarrollo de Líneas de Productos de Software. [en línea] Universidad Católica del Maule, Descargas. 2008 [Consultado el: 10 de noviembre de 2012]. Disponible en: [http://www.eici.ucm.cl/Academicos/R_Villarroel/descargas/ing_sw_1/DesarrolloLineasProductosSoftware.pdf].

BOEHM, B. Tutorial: Software Risk Management. Los Alamitos, CA, IEEE Computer Society Press, 1989. p. 97.

BSI. ISO/IEC Guide 73: 2002 Risk Management–Vocabulary–Guidelines for Use in Standards. Londres, British Standard Institute, 2002. p. 36.

CIAO. Practices for Securing Critical Information Assets. [en línea] Critical Infrastructure Assurance Office. [Consultado el: 17 de noviembre de 2012]. Disponible en: [http://www.infragard.net/library/pdfs/securing_critical_assets.pdf].

COLECTIVO_DE_AUTORES. Control Interno. Programa de preparación económica para cuadros. Ciudad de La Habana. 2005. p. 74.

CHARETTE, R. Software Engineering Risk Analysis and Management. Pittsburgh. Mcgraw Hill Software Engineering Series, 1989. p. 26.

DOROFEE, A. and C. ALBERTS. Rethinking Risk Management. NDIA Systems Engineering Conference, 2009. p. 211.

DOROFEE, A.; J. WALKER, et al. Continuous Risk Management Guidebook.  Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1996. p. 187.

HEREDIA, R. D. Dirección Integrada de Proyectos. Madrid, Gráficas MAR CAR S.A, 1995.

HURTADO, G. P. G. Metodología de Gestión de Riesgos para la Adquisición de Software en Pequeños Entorno. Tesis de Doctorado. Universidad Politécnica de Madrid. Madrid. 2010.

EC. Part 3–Guide to Risk Analysis of Technological Systems. En: CEI/IEC 300–3–9:1995 Risk Management. Geneva, International Electrotechnical Commission, 1995.

IEEE. Standard 1540–2001: Standard for Software Life Cycle Processes–Risk Management. [en línea]. IEEE Standards Association. 2001. [Consultado el: 15 de marzo de 2012]. Disponible en: [http://standards.ieee.org/findstds/standard/1540-2001.html].

JIMÉNEZ, L. M. and C. D. L. T. CUESTA. Valoración de riesgos de un proyecto utilizando el Proceso de Análisis Jerárquico. [en línea]. Rect@, 2010 [Consultado el: 20 de abril del 2012]. Disponible en: [http://www.uv.es/asepuma/VI/20.pdf].

OLALDE, C. L. Calidad y reutilización de Software. En: IV Ciclo de Conferencias Sistemas de Cara al Futuro. Centro de Investigación en Matemáticas, Guanajuato, México, 2006. p. 17-22.

PINO, H. P. Propuesta de modelo de desarrollo para líneas de productos de software en centros de producción. Tesis de Máster en Gestión de Proyectos Informáticos. Universidad de las Ciencias Informáticas. La Habana. 2011.

PMI. Guía de los Fundamentos para la dirección de proyectos (Guía del PMBOK).  Pennsylvania, EE.UU. Project Management Institute, Inc., 2009. p. 502.

PRESSMAN, R. S. Ingeniería de Software. Un enfoque práctico. Madrid, Mc Graw-Hill/Interamericana de España, S.A, 2001. p. 601.

SEI. A Framework for Software Product Line Practice. [en línea] 2009 [Consultado el: 10 de octubre de 2012]. Disponible en: [http://www.sei.cmu.edu/productlines/frame_report/index.html].

Recibido: 07/01/2013
Aceptado: 01/03/2014 ]]> APM 2004 2da edición 157 2008 1989 97 BSI 2002 36 CIAO COLECTIVO_DE_AUTORES 2005 74 1989 26 2009 211 1996 187 1995 2010 EC 1995 IEEE 2001 2010 2004 33-47 2006 17-22 2011 PMI 2009 502 2001 601 SEI 2009