cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Caracterización de Proyectos de Software para Configurar su Desarrollo y Habilitar la Comparación entre Casos Almacenados

en la Memoria Organizacional

presentada por

Cindy Delgado Solis Lic. en Informática por la Universidad Autónoma de Sinaloa

Como requisito para la obtención del grado de:

Maestría en Ciencias en Ciencias de la Computación

Director de tesis: Dr. Moisés González García

Co-Director de tesis:

Dr. René Santaolaya Salgado

Cuernavaca, Morelos, México. 17 de enero de 2008

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Caracterización de Proyectos de Software para Configurar su Desarrollo y Habilitar la Comparación entre Casos Almacenados en la

Memoria Organizacional

presentada por

Cindy Delgado Solis Lic. en Informática por la Universidad Autónoma de Sinaloa

Como requisito para la obtención del grado de:

Maestría en Ciencias en Ciencias de la Computación

Director de tesis: Dr. Moisés González García

Co-Director de tesis:

Dr. René Santaolaya Salgado

Jurado: Dr. Máximo López Sánchez – Presidente

M.C. Olivia Fragoso Díaz– Secretario M.C. Reynaldo Alanis Cantú – Vocal

Dr. Moisés González García – Vocal Suplente

Cuernavaca, Morelos, México 17 de enero de 2008

DEDICATORIAS

A Dios por darme tantas cosas, sobre todo vida para cumplir mis metas.

A mi familia que aunque de lejos me apoyaron y me alentaron a culminar esta etapa de mi

vida.

A mi sobrinito Jesús Adolfo, nuevo integrante de la familia, por la alegría que nos ha dado.

A Héctor por su cariño, apoyo y compañía.

AGRADECIMIENTOS Al Consejo Nacional de Ciencia y Tecnología (CONACYT) por el importante apoyo económico durante mi estancia en el programa de maestría. Al Centro nacional de investigación y desarrollo tecnológico (CENIDET) por brindarme la oportunidad de seguir preparándome. A mis directores de tesis: Dr. Moisés González García y Dr. René Santaolaya Salgado por su apoyo, dedicación y consejos. A mis revisores MC. Olivia Fragoso Díaz, Dr. Máximo López Sánchez y MC. Reynaldo Alanís Cantú por su valiosa contribución en esta tesis. A la maestra Olivia por sus valiosas observaciones y consejos, que permitieron la realización de un mejor trabajo. Al MC. Javier Martínez Hernández y al Ing. Gabriel Gutiérrez Serralde por su apoyo en la recolección de información de proyectos de software. A todos los compañeros de la generación 2005-2007 por su amistad y compañía, muy especialmente a mis compañeros del laboratorio de Ingeniería de Software: Edna, Elvia Silvana, Jazmín, Luz, Erick y Lalo. A mis dos especiales amigas y compañeras de licenciatura y maestría: Edna y Elvia, gracias por su amistad, compañía y apoyo. A mis compañeras de casa Adriana, Claudia y Elvia; y a mis vecinos Rafa y Chavo, gracias por compartir conmigo tantos momentos agradables. A todas aquellas personas que tuve la oportunidad de conocer durante mi estancia en Cenidet.

RESUMEN

Esta investigación se ubica en el contexto del ambiente AGDE (Architectural and Group Development-Environment), el cual propone el desarrollo de un conjunto de herramientas, con el objetivo de dar soporte al desarrollo de software dirigido por modelos, incluyendo el desarrollo manual y automático del proceso de software. El presente trabajo constituye un primer resultado en la construcción de la herramienta de adecuación, incluida en el AGDE, la cual tiene el objetivo de adaptar aspectos presentes en el desarrollo de un proyecto (proceso a seguir, productos del trabajo que se obtendrán, cantidad de desarrolladores que trabajarán en el proyecto, entre otros) considerando las características particulares del proyecto a desarrollar.

La adecuación del proceso es necesaria debido a la diversidad de proyectos, condición que provoca que para un tipo de proyecto algunos procesos sean más convenientes que otros y por consecuencia de utilizarse un proceso inadecuado, se reduce la calidad del producto a desarrollar y se extiende el tiempo de desarrollo y los costos planeados.

El enfoque del ambiente AGDE para realizar la adecuación del desarrollo es la identificación de patrones de proyectos. La posibilidad de descubrir patrones de proyectos desarrollados con éxito, permitirá repetir aspectos del enfoque de desarrollo que disminuyan la probabilidad de repetir errores e incrementar la competitividad del equipo. En este trabajo de investigación se presenta un marco para la caracterización de proyectos de software, constituido por un conjunto de factores y características establecidos en base a trabajos relacionados, a la literatura sobre el producto y el proceso de software y a la recolección de de información histórica de dos organizaciones. En esta investigación se utilizó el marco de características para comparar proyectos y determinar sus semejanzas mediante medidas de distancias. La utilización del marco de características en las comparaciones, permitirá utilizarlo posteriormente, para comparar proyectos e identificar patrones de proyectos de software.

ABSTRACT This research is located in the context of the AGDE environment (Architectural and Group Development-Environment), which proposes the development of a set of tools, with the objective to give support to the model driven software development, including the manual and automatic software development of the software process. The present work constitutes the first result in the construction of the tailoring tool included in the AGDE, which has the objective to adapt present aspects in the development of a project (process to follow, work products which they will be obtained, quantity of developers that will work in the project, among others) considering the particular characteristics of the project to developing. The process tailoring is necessary due to the diversity of projects, condition that causes that for a type of project some processes are more suitable than others and by consequence, to be used an inadequate process, the quality of the product to develop is reduced and the time of development and the planned costs are extended. The approach of the AGDE environment to realize the development tailoring is the identification of project patterns. The possibility successfully of discovering patterns of project in its development, will allow to diminish the probability of repeating errors and to increase the team competitiveness of the equipment. In this research work is presented a frame for the project characterization of software, a set of factors and characteristics established on the basis of works related, to the literature about the product and the process of software and to the compilation of historical information of two organizations. In this research the frame of characteristics was used to compare projects and to determine their similarities by distance measures. The use of the frame of characteristics in the comparisons, will allow to use it later, to compare projects and to identify software project patterns.

i

CONTENIDO

Lista de figuras ………………………………………………………………………………… iiiLista de tablas …………………………………………………………………………………. ivGlosario de términos ………………………………………………………………………….. vi Capítulo 1: Introducción 1.1 Introducción………………………………………………………………………..……... 11.1 Organización de la tesis…………………………………………………………………. 2 Capítulo 2: Marco conceptual 2.1 Descripción de conceptos……………………………………………………………….. 4 Capítulo 3: Descripción de la investigación 3.1 Descripción de la investigación …..……................................................................... 13 3.1.1 Contexto del problema.………..……................................................................... 13 3.1.2 Planteamiento del problema…………................................................................. 18 3.1.3 Objetivo……………………………………………………………………………….. 18 3.1.4 Justificación…………………………………………………………………………… 18 3.1.5 Idea de solución….………………...…………………………………………………. 18 3.1.6 Alcances y limites……………………………………………………………………. 193.2 Trabajos relacionados ……………………………………………………………………. 19 3.2.1 Marcos de características para la evaluación de una metodología……………... 20 3.2.2 Utilización de experiencias pasadas del desarrollo de proyectos de software

en la adecuación del proceso ……………………………………………………… 20 3.2.3 Identificación de actividades para el desarrollo de un proyecto de software ….. 21 3.2.4 Utilización de clustering en la ingeniería de software……………………………. 22 Capítulo 4: Solución propuesta 4.1 Planteamiento de la solución……………………………………………………………. 254.2 Marco de Características de Proyectos de Software (MCPS) ………………………. 30 4.2.1 Descripción ...........…………………………………………………………………… 30 4.2.2 Estructura del marco MCPS…….…………………………………………………... 30 4.2.2.1 Factores que identifican el tipo de proyecto y al producto de software ……. 31 4.2.2.2 Factores de valoración……….………………………………………………….. 34 4.2.2.3 Factores sociológicos………….………………………………………………… 39 4.2.2.4 Factores del ambiente de ingeniería de software ……………………………. 40 4.2.2.5 Factores configurables………….……………………………………………….. 414.3 Diseño de la base de datos para proyectos de software………….....……………….. 48 Capítulo 5: Demostración 5.1 Proceso de demostración ……………………………………………………………….. 53

ii

5.1.1 Objetivo ……………………………………………………………………………….. 53 5.1.2 Alcance ………………………………………………………………………………... 545.2 Actividades realizadas en el proceso de demostración ……………………………… 54 5.2.1 Desarrollo de la forma de captura para la información de proyectos ………….. 54 5.2.1.1 Software utilizado ………………………………………………………………... 55 5.2.1.2 Estructura de la interfaz…………………………………………………………. 55 5.2.2 Determinar los casos de proyectos a almacenar ………………………………… 56 5.2.3 Recolección de la información de proyectos ……………………………………… 56 5.2.4 Descripción de la actividad de comparación de proyectos ……………………… 575.3 Comparación de proyectos de software ……………………………………………….. 58 5.3.1 Selección de atributos a considerar en el agrupamiento ………………………... 58 5.3.2 Conformación de grupos de proyectos ……………………………………………. 60 5.3.3 Cálculo del grado de similitud entre pares de proyectos ……………………... 635.4 Discusión de resultados ……………………………………………………………... 70 Capítulo 6. Conclusiones 6.1 Conclusiones …………………………………………………………………………….... 726.2 Trabajos futuros …………………………………………………………………………... 73 Anexos Anexo A: Código SQL de la base de datos historialproyectos …………………………. 76 Anexo B: Pantallas del prototipo del sistema historial de proyectos…………………… 80 Anexo C: Métrica para obtener la experiencia del equipo en el desarrollo de software 96 Anexo D: Concentrado de la información de los proyectos almacenados…………….. 98 Anexo E. Archivo de datos Arff …………………………………………………………….. 103

Referencias ………………………. ………………………. …………………………………. 105

iii

LISTA DE FIGURAS

Figura 3.1. Estructura del ambiente AGDE…………. …………………………………….. 16Figura 3.2. Contexto de la investigación en el ambiente AGDE …………………………. 17Figura 4.1. Diagrama de actividad del procedimiento Proc-Identificación-PatronesProyecto (PIPP) (paso 1) ……...…………………………………………………... 28Figura 4.2. Diagrama de actividad del procedimiento Proc-Identificación-PatronesProyecto (PIPP) (paso 2) ……………………………………...…………………... 29Figura 4.3. Documentos del conjunto de resultados……………………………………..... 43Figura 4.4. Jerarquía de elementos de un sistema [42]…….…………………………...... 44Figura 4.5. Estructura general de un sistema (ensamble/parte) ……………………....... 45Figura 4.6. Patrón de subprocesos [20]...............……......……………………................. 45Figura 4.7. Modelo relacional de la base de datos historialproyectos …………………... 50Figura 5.1. Esquema de la interfaz del prototipo “Historial de proyectos” …………….... 56Figura 5.2. Archivo arff cargado en WEKA ……………...……………...…………………. 60Figura 5.3. Resultado de la ejecución del algoritmo k-means ……………...……………. 61Figura 5.4. Visualización de los clusters ……………...……………...……………............ 62Figura B.1. Ventana principal del prototipo “historial de proyectos” ……………............. 80Figura B.2. Submenú Registro ……………...……………...……………...……………...... 81Figura B.3. Submenú Actualización ……………...……………...……………................... 81Figura B.4. Ventana de ingreso para la información general del proyecto ……………... 82Figura B.5. Listado de proyectos registrados ……………...……………...……………..... 83Figura B.6. Ventana de características del producto de software ……………................ 84Figura B.7. Ventana para el ingreso de los riesgos del proyecto ……………................. 86Figura B.8. Ventana de características del ambiente de ingeniería …………………….. 87Figura B.9. Ventana de ingreso de la información de desarrolladores …………………. 88Figura B.10. Listado de desarrolladores registrados …………….……………................. 89Figura B.11. Estructura general de un sistema (Ensamble/parte) …...……………......... 91Figura B.12. Ventana para el ingreso de la Estructura general de un sistema (Ensamble/parte) ……………...……………...……………...……………...……………...... 92Figura B.13. Ventana de productos del trabajo ……………...……………...…………….. 92Figura B.14. Ventana del catálogo de productos del trabajo ……………...……………... 93Figura B.15. Ventana para dar de baja a un proyecto……………...…………….............. 93Figura B.16. Ventana para modificar la información del proyecto ……………...……….. 94Figura B.17. Menú catálogos …………...……………...……………...……………......... 94Figura B.18. Ventana de catálogo de roles ……………...……………...……………...….. 95Figura B.19. Ventana de catálogo de roles con la opción de agregar …………….......... 95Figura C.1. Esquema de la métrica MEDS ……………...……………...……………......... 96

iv

LISTA DE TABLAS

Tabla 3.1. Resumen de trabajos relacionados…….……………………………………….. 23Tabla 4.1. Clasificación del software ……………………………………………………….. 32Tabla 4.2. Definición de medidas para factores que identifican el tipo de proyecto y al producto de software………………………………………………………………………….. 33Tabla 4.3. Definición de medidas para los factores de valoración ……………………… 38Tabla 4.4. Definición de medidas para los factores sociológicos ……………………….. 39Tabla 4.5. Definición de medidas para los factores del ambiente de ingeniería ……… 41Tabla 4.6. Patrones de la estructura de sistemas …………………………………………. 44Tabla 4.7. Definición de medidas para factores configurables [20]….………………….. 47Tabla 4.8. Elementos del marco de características y los niveles de detalle …………… 49Tabla 5.1. Datos de los proyectos recolectados …………………………………………... 57Tabla 5.2. Atributos del conjunto de factores que identifican el tipo de proyecto y al producto de software …………………………………………………………………………. 58Tabla 5.3. Atributos del conjunto de factores de valoración ……………………………… 59Tabla 5.4. Atributos del conjunto de factores del ambiente de ingeniería ……………… 59Tabla 5.5. Valor de los atributos por cluster ……………………………………………. 61Tabla 5.6. Conformación de los clusters …………………………………………………… 63Tabla 5.7. Atributos numéricos ……………………………………………………………... 64Tabla 5.8. Atributos nominales ……………………………………………………………… 65Tabla 5.9. Atributos numéricos normalizados …………………………………………….. 66Tabla 5.10. Resultado de aplicar la medida Manhattan …………………………………. 67Tabla 5.11. Resultado de aplicar las medidas de distancia a los atributos nominales ... 68Tabla 5.12. Distancia de los proyectos ……………………………………………………... 68Tabla 5.13. Resultado del cálculo de similitud …………………………………………. 69Tabla 5.14. Valores reales y normalizados de los atributos numéricos ………………… 69Tabla 5.15. Resultado de la comparación de los proyectos Pro004 y Pro005 ………… 70Tabla 5.16. Diferencias entre clusters de proyectos………………………………………. 70Tabla B.1. Campos de la ventana de Información general del proyecto ……………….. 82Tabla B.2. Campos de la ventana de características del producto de software ……….. 84Tabla B.3. Campos de la ventana de registro de los riesgos del proyecto …………….. 86Tabla B.4. Campos de la ventana de características del ambiente de ingeniería …….. 87Tabla B.5. Campos de la ventana de ingreso de información de desarrolladores …….. 89Tabla B.6. Campos de la ventana de ingreso de la arquitectura del software …………. 92Tabla C.1. Clasificación de la experiencia del equipo en el desarrollo de software ….. 97Tabla D.1. Información de los proyectos almacenados, correspondiente a los Factores que indican el tipo de proyecto y producto de software ……………………….. 98Tabla D.2. Información de los proyectos almacenados, correspondiente a los factores de valoración ………………………………………………………………………… 99Tabla D.3. Información de los proyectos almacenados, correspondiente a los factores sociológicos ………………………..………………………..………………………. 99Tabla D.4. Información de los proyectos almacenados, correspondiente a los

v

factores del ambiente de ingeniería ………………………..……………………………….. 100Tabla D.5. Información correspondiente a los factores configurables del proyecto Pro001 ………………………..………………………..………………………………………. 100Tabla D.6. Información correspondiente a los factores configurables del proyecto Pro002 ………………………..………………………..………………………………………. 101Tabla D.7. Información correspondiente a los factores configurables del proyecto Pro003 ………………………..………………………..………………………………………. 101Tabla D.8. Información correspondiente a los factores configurables del proyecto Pro004 ………………………..………………………..………………………..……………... 102Tabla D.9. Información correspondiente a los factores configurables del proyecto Pro005 ………………………..………………………..………………………………………. 102

vi

GLOSARIO DE TÉRMINOS Ambiente de ingeniería. Hardware y software usado para realizar un esfuerzo de ingeniería de software. Atributos. Representan las propiedades y características básicas de los objetos. Son también conocidos como: variables, campos o características. Atributos de Proyecto. Se refieren a las características del entorno de desarrollo de un proyecto. Atributo nominal (Cualitativo, Categórico). Los valores de un atributo nominal son variables diferentes que proveen la suficiente información para distinguir un objeto de otro. Atributo numérico. Los atributos numéricos contienen valores reales. Caracterizar. Determinar los atributos peculiares de alguien o de algo, de modo que claramente se distinga de los demás. Clustering. Técnica de minería de datos que organiza los objetos de acuerdo a rasgos particulares que los identifican y diferencian unos de otros, teniendo como resultado final conjuntos que contienen objetos con características lo mas parecidas entre ellos y lo más distintas posible con respecto a los objetos contenidos en otros grupos. Componente. Una de las partes que constituye un sistema. Desarrollador. Una persona que realiza actividades del desarrollo (análisis de requisitos, diseño, pruebas de aceptación) durante el proceso del ciclo de vida de un software Método. Conjunto de reglas y criterios razonables que establecen una forma precisa y repetible de ejecutar una tarea y llegar al resultado deseado. Metodología. Colección de métodos, procedimientos y estándares que definen una síntesis integrada de enfoques de ingeniería para el desarrollo de un producto. Modelo. Es una abstracción de un sistema orientada a la simplificación del razonamiento acerca del sistema omitiendo detalles irrelevantes. Es Una representación de uno o varios aspectos de un sistema. Modelo de proceso. Es una descripción de un proceso que se presenta desde una perspectiva particular, un modelo es una abstracción del proceso real. Módulo. Parte lógicamente separable de un programa. Objeto. Los objetos son aquellos vectores que se describen en función del conjunto de atributos. Un objeto es también conocido como punto, muestra, entidad o instancia.

vii

Procedimiento. Descripción escrita de un curso de acción para ejecutar una tarea dada. Proceso. Conjunto de actividades, técnicas, herramientas, notación y participantes, utilizados para generar un modelo o producto preestablecido. Proceso de software. Proceso a través del cual los requerimientos de usuario se traducen en especificaciones funcionales, las especificaciones funcionales en especificaciones de diseño, las especificaciones de diseño en código, el cual se prueba, documenta y libera para el usuario. Producto de software. Es un conjunto completo, o cualquiera de los elementos individuales del conjunto, de programas de computadora, procedimientos y documentación asociada, designados para liberarse a un cliente o usuario final. Producto del trabajo. Es un artefacto que se produce durante el desarrollo, como un documento o un fragmento de software para los demás desarrolladores o para el cliente. Proyecto de software. Es un esfuerzo convenido y enfocado a analizar, especificar, diseñar, desarrollar, probar y/o mantener los componentes de software y la documentación asociada de un sistema. Rol. Esta asociado con un conjunto de tareas y se asigna a un participante en el desarrollo de un proyecto de software. Un participante puede cumplir varios roles. Sistema. Colección de componentes organizados para cumplir una función específica o un conjunto de funciones. Subsistema. Un sistema secundario o subordinado de un sistema más grande.

- 1 -

Capítulo 1: Introducción 1.1 Introducción La calidad del software1 es uno de los puntos de atención de las organizaciones actuales, ya que el software se ha convertido en un activo que determina en gran medida la operatividad de una organización. Por lo que una de las metas de la Ingeniería de Software es mejorar la calidad de los productos a desarrollar y un principio aplicado para lograrlo, es mejorar la calidad del producto de software mejorando la calidad del proceso.

Sin embargo, la mejora del proceso de software se dificulta ya que los proyectos de software se desarrollan en un ambiente dinámico, debido a la presencia de cambios en el dominio de las empresas y a una creciente evolución de la tecnología, entre otros factores. Otra causa de la complejidad del proceso es la diversidad de metas de desarrollo de software que requieren organizar las actividades de diferente forma, por lo que para algún tipo de proyecto algunos procesos son más convenientes que otros. Debido a esto, si se utiliza un proceso inadecuado se reduce la calidad o utilidad del producto a desarrollar. Esta situación lleva a la necesidad de adecuar el desarrollo a las características particulares del proyecto. 1 La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad [1].

Capítulo 1

- 2 -

Este trabajo de investigación está ubicado en el contexto del ambiente AGDE (Architectural and Group Development-Environment). Este ambiente tiene el objetivo de dar soporte al desarrollo de software dirigido por modelos, incluyendo el desarrollo manual y automático del proceso de software. Los enfoques presentes en el ambiente AGDE son: la adecuación del desarrollo, en donde se establece que cada proyecto de software requiere de una forma particular de abordar el problema; y la transformación entre modelos, que habilita el desarrollo automático del desarrollo de software.

Dentro del enfoque de adecuación del desarrollo, se tiene la necesidad de identificar las

características que permitan definir el proceso a aplicar en el desarrollo de un proyecto. Mediante el conjunto de características identificadas se puede realizar un procedimiento de clasificación que posibilite empatar las características del proyecto a desarrollar con un patrón de proyecto, lo que permitirá a los líderes de proyectos tomar la decisión acerca del proceso de desarrollo a seguir. Esto debido a que un patrón de proyecto es un modelo a seguir, que se obtiene a partir de casos de proyectos exitosos con características comunes. Se reconoce la importancia de los patrones y con este fin se propone un procedimiento general para identificar patrones de proyectos (capítulo 4, sección 4.1).

El primer paso para la construcción del procedimiento para identificar patrones fue

modelar la información generada durante el desarrollo de un proyecto y estructurarla de forma que facilite su análisis e interpretación. Con este fin, el objetivo de esta investigación es caracterizar proyectos de software y diseñar una estructura de almacenamiento de la información relativa al desarrollo de proyectos pasados, con el fin de habilitar la comparación entre casos.

En este trabajo de investigación se planteó diseñar una estructura de información de

proyectos de software para dar solución a la necesidad de identificar las características requeridas para la adecuación del desarrollo, que forman la memoria organizacional del desarrollo de proyectos. Es decir, diseñar un almacén donde se mantenga el conocimiento y las experiencias del desarrollo, para utilizarse en el proceso de identificación de proyectos similares y para establecer patrones de proyectos. La identificación de patrones de proyectos permitirá aprovechar la experiencia de éxito de otros desarrolladores en el desarrollo de un proyecto con características similares.

La importancia de esta investigación es que con la base de información histórica de

proyectos de software se habilitará el desarrollo de un sistema de gestión de conocimiento capaz de procesar y almacenar la información generada durante el desarrollo de un proyecto de software, con el fin de identificar patrones a partir de casos almacenados.

1.2 Organización de la tesis En este trabajo de investigación se da a conocer un marco de características de proyectos de software, que se creó con el fin de utilizarse en la identificación de patrones de proyectos y de esta manera determinar aspectos del desarrollo a partir de las características presentadas. Para ello, esta investigación comienza con una descripción de los conceptos utilizados (capítulo 2), como lo son: memoria organizacional, proceso, producto y proyecto de software.

Capítulo 1

- 3 -

Posteriormente, en el capítulo 3, se describe el antecedente de esta investigación, se presenta el análisis de los trabajos relacionados, así como el planteamiento del problema tratado, estableciendo los objetivos, la justificación, los alcances y limites de los resultados esperados.

Después, en el capítulo 4, se presenta el producto resultado de esta investigación, el cual

constituye un primer acercamiento para el desarrollo de la herramienta de adecuación del desarrollo de software del ambiente AGDE, se presenta la caracterización de proyectos de software, que se tomó como base para estructurar la información generada en el desarrollo de proyectos, con el fin de crear un almacén para información de proyectos para utilizarse en el procedimiento de identificación de patrones en una investigación futura.

El marco de características de proyectos de software desarrollado, está dividido en 5

conjuntos de factores, en donde para la mayoría de las características de los conjuntos se establecieron: la regla de medición, el tipo de escala y las alternativas que puede tomar cada característica.

El proceso de demostración, que permitió verificar la estructura del marco de proyectos

de software, se describe en el capítulo 5. En donde el objetivo fue verificar que con la estructura de la información basada en el marco propuesto se puedan almacenar los datos requeridos de proyectos de software y que la información recopilada permita la actividad de comparación de proyectos. Para la actividad de comparación se recurrió a los algoritmos de clustering (agrupamiento), que son técnicas que agrupan objetos similares y que usan una medida para evaluar las diferencias y similitudes entre objetos.

Por último en el capítulo 6, se muestran las conclusiones obtenidas a partir del desarrollo

de esta investigación. Al final del documento se muestran los anexos correspondientes y las referencias utilizadas.

- 4 -

Capítulo 2: Marco conceptual

Existen numerosos conceptos abarcados en esta investigación, por lo que en este capítulo sólo se mostrarán algunos conceptos necesarios acerca del desarrollo de proyectos de software y en el capítulo 4 se explican, conforme se presenta la solución propuesta, otros conceptos necesarios, de acuerdo a como se va presentando la caracterización de proyectos de software. 2.1 Descripción de conceptos El conocimiento generado en el desarrollo de un proyecto de software constituye la memoria organizacional de una empresa dedicada al desarrollo de software. Las organizaciones que utilizan la experiencia obtenida del desarrollo de proyectos pueden mejorar la calidad del software en nuevos proyectos. Esto puede implicar la reutilización de técnicas, métodos, herramientas, procesos, o métricas usadas en otros proyectos. El aprendizaje no se limita sólo a proyectos exitosos, las fallas ocurridas en proyectos pasados pueden orientar el desarrollo de nuevos proyectos. Para poder reutilizar las experiencias pasadas éstas deben recolectarse y almacenarse.

Capítulo 2

- 5 -

Es importante enfatizar que el conocimiento en una empresa es un recurso que se necesita y debe ser almacenado de alguna manera. Se puede conceptualizar a la memoria organizacional como el lugar en donde se almacena el conocimiento organizacional generado en el pasado para utilizarlo de forma racional en el presente y en el futuro, con la característica de que este almacén sea fácil de accederse por todos los miembros de la organización [2].

Las principales funciones de un sistema para manejar la memoria organizacional son [3]:

Divulgación del conocimiento (por ejemplo, lecciones aprendidas, mejores prácticas, etc.) para que todos los miembros de la organización puedan utilizar el conocimiento en el contexto de sus actividades diarias. Esto reduce el costo de aprendizaje y ayuda a la adquisición y producción de nuevos conocimientos que a su vez agregan valor a la organización.

Facilitar la efectiva y eficiente generación de nuevo conocimiento (por ejemplo, actividades de investigación y desarrollo, aprendizaje a partir de casos históricos etc.)

Asegurarse que el nuevo conocimiento está disponible para aquellas personas en la organización que realizan actividades basadas en ese nuevo conocimiento.

Existen ventajas y beneficios de contar con una memoria organizacional en cualquier empresa. Entre los más importantes se encuentran los que menciona Eric Stein [6]:

Ayuda a los directivos a mantener la dirección estratégica.

Ayuda a la organización a aprovechar soluciones pasadas para resolver nuevos problemas.

El nuevo conocimiento generado por los individuos de la empresa puede ser almacenado para uso posterior.

Facilita el aprendizaje organizacional.

Provee la facilidad de acceder a la experiencia de aquellos que estuvieron en la empresa.

En esta investigación se tomó el enfoque de memoria organizacional para estructurar la

información de proyectos de software, de tal manera que al contar con información histórica se posibilite su análisis y esta información se utilice al presentarse un nuevo desarrollo. Donde un proyecto de software es un conjunto de actividades de trabajo, tanto técnicas como de dirección, requeridas para satisfacer los términos y condiciones de un acuerdo entre el cliente, el equipo del proyecto y los directivos de la empresa. Un proyecto tiene establecido una fecha de comienzo y una de final, objetivos definidos, responsabilidades establecidas, un presupuesto y una planificación [4].

Un proyecto de software es la ejecución en un momento determinado de un proceso, en

el área del desarrollo de software y un proceso de desarrollo de software es un conjunto de actividades y resultados asociados que conducen a la creación de un producto de software [29]. A través del proceso de software, los requerimientos del usuario se traducen en especificaciones funcionales, las especificaciones funcionales en especificaciones de diseño,

Capítulo 2

- 6 -

las especificaciones de diseño en código, el cual se prueba, documenta y libera para utilizarse por el usuario [4].

En el contexto de un proceso, un producto de software es un conjunto completo o

cualquiera de los elementos individuales del conjunto, de programas de computadora, procedimientos y documentación asociada, designados para liberarse a un cliente o usuario final [5].

En esta investigación la definición de producto de software se tomó como el producto

final, es decir el conjunto completo de programas de computadora, procedimientos y documentación asociada, entregable al cliente. Mientras que para hacer referencia a los productos resultantes de alguna actividad, en el proceso de ingeniería, se utilizó el término “producto de trabajo”.

Un producto del trabajo es un artefacto que se produce durante el desarrollo, como un

documento o un fragmento de software para los demás desarrolladores o para el cliente [34]. Puede ser una descripción de proceso, plan, procedimiento, programa de computadora o la documentación asociada.

Un producto del trabajo es un trozo de información que se produce, modifica o usa

durante el proceso de desarrollo de software. Los productos del trabajo son los resultados tangibles del proyecto, las cosas que se van creando y usando hasta obtener el producto final. Dentro del enfoque, para desarrollar software, de MDA (Model Driven Architecture) los productos son establecidos como modelos, un modelo es la abstracción de un sistema orientada a la simplificación del razonamiento acerca del sistema omitiendo detalles irrelevantes [32], por lo que un producto del trabajo puede ser cualquiera de los siguientes:

Un documento, como el documento de la arquitectura del software.

Un modelo, como el modelo de Casos de Uso o el modelo de diseño del sistema (descripción de alto nivel del sistema que incluye los objetivos de diseño, la descomposición en subsistemas, la estrategia de almacenamiento, entre otros [32g]).

Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un Caso de Uso o un subsistema.

Un programa de computadora.

Un documento que recopila información acerca del proceso o producto.

MDA es un marco de trabajo para el desarrollo del software, definido por la OMG (Object Management Group), que establece una arquitectura orientada a modelos y unas guías de transformación entre los mismos, para recoger las especificaciones de un sistema, donde los productos que se generan son modelos formales, que incluso pueden llegar a comprenderse por la computadora [6]. Los modelos en MDA se dividen en:

Modelos Independientes de Computación (CIM, por sus siglas en inglés). Son modelos de alto nivel de abstracción que identifican el contexto del sistema.

Capítulo 2

- 7 -

Modelos Independientes de Plataforma (PIM, por sus siglas en inglés). Proporcionan la especificación formal de la estructura y función del sistema, sin tener en cuenta aspectos de la plataforma a utilizar. Son independientes de cualquier tecnología de implementación.

Modelos de Plataforma Específica (PSM, por sus siglas en inglés). Proporcionan modelos en términos de constructores de implementación que están disponibles en una tecnología específica.

En esta investigación se enlista un conjunto de productos del trabajo, en base a estos 3

modelos y los modelos: Modelo de Implementación (IM, por sus siglas en inglés) y Modelo Operacional (OM, por sus siglas en inglés), definidos en el método AGD (ver capítulo 4, sección 4.2.2.5), que proporciona el contexto para analizar el conjunto de productos del trabajo de los proyectos desarrollados.

Retomando el enfoque de memoria organizacional, en esta investigación se propone

desarrollar un procedimiento para la obtención de patrones de proyectos de software, en el que se parte de la creación de un almacén para la información histórica del desarrollo de proyectos y de esta manera ayudar a aprovechar soluciones pasadas para resolver nuevos problemas.

Alexander (1979) hace alusión a las definiciones de un patrón de diseño precisando, que

las mismas características se presentan repetidamente una y otra vez, aunque en su aspecto detallado estas características nunca son iguales. Y define un patrón como una solución general a problemas comunes que puede derivar a soluciones específicas [7].

En los principios postulados por Martin Fowler en el libro “Analysis Patterns” se menciona

que: un patrón de diseño no es una solución en sí misma, sino la documentación de la forma en que se construyeron soluciones a problemas similares en el pasado, lo cual permite una mejor gestión de la experiencia y transferencia de conocimientos [8].

Un patrón de proyecto se define en esta investigación como una guía, que ayuda a la

construcción de software, la cual se basa en la experiencia de otros especialistas que han abordado proyectos con características similares, en los que se encontró una correlación entre las características del proyecto de software y las instancias de proceso.

Una característica de un proyecto de software, se definió como una cualidad

generalmente determinada por un conjunto de datos, por ejemplo: contexto, periodo y tiempo de desarrollo, entre otras. En esta investigación las características del proyecto se consideran como los aspectos presentes en el desarrollo de un software, o el sistema de actividades que da lugar a productos de software [4].

Clustering es una técnica que permite observar patrones de comportamiento entre

objetos [11]. Clustering consiste en la división de los datos en grupos de objetos similares [9], con el objetivo de formar grupos de objetos o entidades, de tal manera que las entidades dentro de un grupo sean similares unas con otras y diferentes de las de otros grupos [10]. La semejanza entre entidades se determina en base a sus características.

Capítulo 2

- 8 -

Ya que el objetivo de las técnicas de Clustering, es agrupar objetos similares, se requiere de alguna medida para evaluar las diferencias y similitudes entre objetos. La similitud es una medida de correspondencia o semejanza entre los objetos que van a ser agrupados, la estrategia más común para determinarla consiste en medir la equivalencia en términos de la distancia entre pares de objetos. Los objetos con distancias reducidas entre ellos son más parecidos entre sí, que aquellos que tienen distancias mayores [12]. “El concepto de distancia se puede ver como la función inversa de la similitud, con lo que las medidas de distancia son una forma de formalizar el concepto de similitud” [13].

Las medidas de distancia más tradicionales son aquellas que se aplican sobre dos

instancias u objetos, tales que todos sus atributos sean numéricos, para este caso algunas de medidas de acuerdo a [13], son:

Distancia Euclidiana. Es la distancia clásica, se define como la longitud de la recta que une dos puntos en el espacio euclidiano. Se obtiene con la raíz cuadrada de la suma de los cuadrados de la diferencias entre los valores de cada variable (atributo) de las instancias x e y. (2.1) Donde:

),( yxd es la distancia entre las instancias (x, y)

ix es el atributo i de la instancia x

iy es el atributo i de la instancia y n es el número de atributos de las instancias Distancia Manhattan o distancia por cuadras. La distancia Manhattan entre dos puntos es la suma de los valores absolutos de las diferencias de sus componentes. Se Define la distancia Manhattan entre una instancia x y otra instancia y como:

∑=

−=n

iii yxyxd

1),( (2.2)

Donde:

),( yxd es la distancia entre las instancias (x, y)

ix es el atributo i de la instancia x

iy es el atributo i de la instancia y n es el número de atributos de las instancias

El concepto de distancia no sólo existe para valores numéricos, también se puede utilizar

cuando los atributos son nominales. Para atributos nominales se suele utilizar la función

∑ =−=

n

i ii yxyxd1

2)(),(

Capítulo 2

- 9 -

delta, siendo S(x,y)=0 si y sólo si x=y y S(x,y)=1 en caso contrario. Con esta función, se puede definir la distancia de la siguiente manera:

∑=

=n

iii yxSwyxd

1),(),( (2.3)

Donde:

),( yxd es la distancia entre las instancias de proyectos (x, y)

ix es el atributo i de la instancia x

iy es el atributo i de la instancia y S( ix , iy )=0 si y sólo si ix = iy y S( ix , iy )=1 en caso contrario. n es el número total de atributos de los proyectos w es el factor de reducción El valor del factor de reducción (por ejemplo 1/n es un valor usual, donde n es el número

de elementos del conjunto a comparar) se puede elegir convenientemente cuando los atributos son nominales y numéricos.

Se puede utilizar esta función de distancia para el subconjunto de atributos nominales,

además de utilizar una de las distancias para atributos numéricos (Euclidiana, Manhattan u otra) y combinar ambos valores utilizando un factor adecuado (w) [13].

Existen 2 tipos de procedimientos de agrupación, los jerárquicos y los no jerárquicos. El

agrupamiento jerárquico se caracteriza por el desarrollo de una estructura de árbol o dendograma (representación gráfica de un grupo de relaciones basadas en la cercanía o similitud entre los datos). El árbol o dendograma, establece una relación ordenada de los grupos previamente definidos y la longitud de sus ramas es una representación de la distancia entre los distintos nodos del mismo.

En los procedimientos de agrupamiento no jerárquicos, se dividen las observaciones en un número de grupos al tratar de minimizar la función de error. Esta metodología no produce clusters que dependen de otros (como lo hace el método jerárquico). Entre los métodos de agrupamientos no jerárquicos se encuentra el algoritmo de agrupación K-means, el cual es uno de los algoritmos más utilizados para hacer clustering, que se caracteriza por su sencillez. K-means agrupa de la siguiente manera: en primer lugar se debe especificar cuántos clusters se van a crear, éste es el parámetro k, para lo cual se seleccionan k objetos aleatoriamente, que representará el centro o media de cada cluster (centroide). A continuación cada instancia, se asocia al centro del cluster más cercano de acuerdo con la distancia Euclidiana que le separa de él. Para cada uno de los clusters así construidos se obtiene el centroide de todos sus objetos (el valor de los atributos de los centroides, se calcula con la media o la moda según

Capítulo 2

- 10 -

se trate de atributos numéricos o nominales [10]). Estos centroides se toman como los nuevos centros de sus respectivos clusters. Se repite el proceso completo con los nuevos centros de los clusters. La iteración continúa hasta que se repite la asignación de las mismas instancias a los mismos clusters, ya que los puntos centrales de los clusters se han estabilizado y permanecerán invariables después de cada iteración [14].

El algoritmo de K-means es el siguiente:

1. Elegir k objetos (semillas) como centroides de los grupos 2. Asignar los objetos al grupo cuyo centroide esté más cerca 3. Recalcular los centroides 4. Reasignar cada objeto al grupo cuyo centroide sea más cercano 5. Si no se llega a un criterio de convergencia (por ejemplo, dos iteraciones no cambian las clasificaciones de los objetos), volver al paso 3. Existen herramientas que permiten automatizar la aplicación de algoritmos de clustering,

una de ellas es WEKA. WEKA es una colección de algoritmos de Máquinas de conocimiento desarrollados por la universidad de Waikato (Nueva Zelanda) implementados en Java, que contiene las herramientas necesarias para realizar transformaciones sobre los datos, tareas de clasificación, regresión, clustering, asociación y visualización [15].

La licencia de WEKA es GPL (GNU Public License), lo que significa que este programa

es de libre distribución y difusión. Además, WEKA está programado en Java y es independiente de la arquitectura, ya que funciona en cualquier plataforma sobre la que haya una máquina virtual Java disponible.

En esta investigación se utilizó el algoritmo k-meas contenido en WEKA para obtener

grupos de proyectos con características comunes. WEKA trabaja con un formato denominado arff, acrónimo de Attribute-Relation File

Format [16], por lo que se creó un archivo de este tipo, conteniendo un conjunto de características del desarrollo de proyectos de software.

El formato de los archivos arff está compuesto por una estructura claramente

diferenciada en tres partes:

1. Cabecera. Se define el nombre de la relación. Su formato es el siguiente: @relation <nombre-de-la-relación> Donde <nombre-de-la-relación> es de tipo String. Si dicho nombre contiene algún espacio será necesario expresarlo entrecomillado. 2. Declaración de atributos. En esta sección se declaran los atributos que compondrán el archivo junto a su tipo. La sintaxis es la siguiente: @attribute <nombre-del-atributo> <tipo>

Capítulo 2

- 11 -

Donde <nombre-del-atributo> es de tipo String con la mismas restricciones que el caso anterior. WEKA acepta diversos tipos, estos son: a) NUMERIC. Expresa números reales. b) INTEGER. Expresa números enteros. c) DATE. Expresa fechas, para ello este tipo debe ir precedido de una etiqueta de formato entrecomillada. La etiqueta de formato está compuesta por caracteres separadores (guiones y/o espacios) y unidades de tiempo. d) STRING. Expresa cadenas de texto, con las restricciones del tipo String comentadas anteriormente. e) ENUMERADO. El identificador (de este tipo consiste en expresar entre llaves y separados por comas los posibles valores (caracteres o cadenas de caracteres) que puede tomar el atributo. Por ejemplo, si tenemos un atributo que indica el tiempo podría definirse: @attribute tiempo {soleado,lluvioso,nublado} 3. Sección de datos. Declaramos los datos que componen la relación separando entre comas los atributos y con saltos de línea las relaciones. @data 4,3.2

En el caso de que algún dato sea desconocido se expresará con un símbolo de cerrar interrogación (“?").

Es posible añadir comentarios con el símbolo “%”, los comentarios pueden situarse en

cualquier lugar del archivo. Para concluir este capítulo es importante mencionar que uno de los productos resultado

de esta investigación es la caracterización de proyectos de software, por lo que en el siguiente capítulo están definidos otros conceptos involucrados en el desarrollo de proyectos de software. El conocimiento acerca del desarrollo de un proyecto se encuentra repartido entre: los recursos humanos que intervienen (formación, experiencia, roles desempeñados, entre otros); el ambiente de ingeniería (corresponden al hardware y software utilizados en un esfuerzo de ingeniería); el producto de software; y los productos del trabajo.

- 12 -

Capítulo 3: Descripción de la investigación En este capítulo se describe el contexto del problema tratado en esta investigación, se plantea la descripción del problema, indicando el objetivo, justificación, complejidad, alcances y límites establecidos. Se describe el AGDE (Architectural and Group Development-Environment), que es un antecedente de este trabajo de investigación. Este ambiente tiene como objetivo dar soporte al desarrollo de software dirigido por modelos, incluyendo el desarrollo manual y automático del proceso de software.

Se describen también investigaciones relacionadas con la conformación de marcos de evaluación para la adopción de una metodología en el desarrollo de software y otras corresponden a la utilización del conocimiento de experiencias previas en el desarrollo de nuevos proyectos.

Capítulo 3

- 13 -

3.1 Descripción de la investigación 3.1.1 Contexto del problema El desarrollo de software aplicando un proceso, que previamente ha dado resultados satisfactorios, bien definidos y bien entendidos, aumenta la probabilidad de entregar un producto con la calidad requerida [17].

Sin embargo, la aplicación de un proceso con tales características, se dificulta por la gran diversidad de proyectos, que provoca que para un tipo de proyecto algunos procesos sean más convenientes que otros y de utilizarse un proceso inadecuado se reducirá la calidad o utilidad del producto a desarrollar. Es necesario adaptar los aspectos del desarrollo (proceso a aplicar y productos a obtener) a las características particulares del proyecto a desarrollar (adecuación del desarrollo). Para determinar las decisiones en la adecuación, se requiere identificar las características idóneas del proyecto para determinar los valores de los atributos configurables en el desarrollo, que aumenten la probabilidad de obtener resultados favorables en el desarrollo de un proyecto.

En CENIDET (Centro Nacional de Investigación y Desarrollo Tecnológico) se está trabajando en el desarrollo de un ambiente de herramientas para el soporte del desarrollo de software dirigido por modelos, incluyendo el desarrollo manual y automático del proceso, denominado AGDE (Architectural and Group Development-Environment). Una de las herramientas incluidas en el ambiente AGDE corresponde a la adecuación del desarrollo, la cual consiste en adaptar los factores configurables del desarrollo a las características particulares de un proyecto de software, tomando en cuenta el desarrollo de otros proyectos con características similares.

La identificación de los factores configurables en esta herramienta corresponde a las 7 áreas de toma de decisión establecidas en método AGD (Architectural and Group Development) [20]:

El conjunto de resultados a obtener (cada uno construido en un paso específico, tipo PSP).

La estructura general del producto de software (conjunto de niveles ensamble-parte), en donde es necesaria la correlación de los componentes de la arquitectura del software (ubicando los componentes de la arquitectura en los niveles de la estructura a usar).

El conjunto de sub-procesos a realizar para obtener cada producto del trabajo.

La estructura del equipo de trabajo (como el número de participantes, roles).

La forma de realizar el desarrollo (colaboratívamente o individualmente), de cada resultado a obtener.

La forma de realizar el seguimiento y control del proceso (periodicidad de reuniones protocolo de reuniones, resultados a obtener).

Capítulo 3

- 14 -

La forma de realizar inspecciones (revisiones técnicas formales) y su relación con el producto y los eventos del proceso.

El método AGD es producto de la investigación doctoral del profesor Moisés González García, miembro de la línea de investigación en Ingeniería de Software de CENIDET. El AGD es un método de desarrollo de software que asigna mayor importancia al producto de software y a su estructura, asociando un proceso, a cada uno de los productos del trabajo requeridos para construir el resultado. En el AGD se asume que se pueden obtener productos de mejor calidad como resultado de: la importancia dada a los productos y a su arquitectura; y la sinergia obtenida al integrar varios modos de trabajo en grupo [19] [20].

El método AGD está compuesto por: 1. Conjunto de productos (PS, por sus siglas en inglés): estructurada en una jerarquía de subconjuntos, que en la rama de ingeniería incluye elementos que son modelos utilizados en el desarrollo de software, mediante el enfoque MDA (ver sección 2.1) a través de sus modelos (CIM, PIM, PSM) completados con los modelos IM (Modelo de Implementación) y OM (Modelo Operacional). 2. El Proceso Dirigido por Modelos (MDP, por sus siglas en inglés): está compuesto de cuatro modos de trabajo en grupo: trabajo en equipo y tres modos de trabajo en grupo complementarios (de colaboración, de cooperación y de control). El MDP es un proceso generalizado de la realización de los cuatro modos de trabajo, es sistemático e iterativo y está organizado en sub-procesos de forma que facilite el trabajo en equipo.

En la figura 3.1 se muestra la estructura general del AGDE, en donde se inicia con la identificación de las características del proyecto a desarrollar para, posteriormente, obtener la adecuación del desarrollo; después se procede a elegir el tipo de ingeniería que se seguirá ya sea directa o inversa, de tratarse de ingeniería directa, se sigue el proceso iniciando con el modelado del software, indicando si el modelado se realizará de manera automática mediante la transformación entre modelos o manual (enfoque tradicional de desarrollo). Desde el modelado hasta la integración y complementación del producto de software se realiza paralelamente el registro y monitoreo del proceso de desarrollo, mediante el Sistema de Soporte para el Proceso de Software en equipo (SiSoProS) [31]. Por último se captura la información de desarrollo del proyecto en el sistema de historial de proyectos esto para mantener un almacén que permitan identificar patrones de proyectos para utilizarse por la herramienta de adecuación. A continuación se describen los componentes de la estructura general del ambiente AGDE:

Herramienta de adecuación del desarrollo. Herramienta que ayuda en la configuración del desarrollo de proyectos de software, tomando en cuenta las características particulares de cada proyecto.

Capítulo 3

- 15 -

Sistema de Soporte para el Proceso de Software en equipo (SiSoProS). Es una herramienta que permite el registro y monitoreo del desarrollo del software en equipo, para la mejora continua del proceso y del producto [31].

Editor de modelos. Se utiliza para crear y/o modificar los modelos (CIM, PIM, PSM) realizados durante el proceso de desarrollo de un software.

Herramienta de transformación de modelo a modelo. Esta herramienta permite obtener un modelo destino a partir de un modelo origen el cual es la entrada para la transformación. La transformación se puede presentar entre modelos de distintos niveles de abstracción (CIM a PIM, PIM a PSM) o entre modelos del mismo nivel de abstracción (CIM a CIM, PIM a PIM, PSM a PSM).

Validación del modelo. Los modelos usados para la generación de otros modelos deben estar bien definidos. Por medio de las validaciones se pueden verificar los modelos en base a un conjunto de reglas (predefinido o definido por el usuario) para asegurar que los modelos origen se puedan utilizar en una transformación y que los modelos obtenidos están bien definidos.

Editor de código. Herramienta diseñada para crear o editar código de un programa. El modelo IM contiene al código del software que se puede generar con este componente, y en él se consideran los aspectos de lenguaje y otros elementos de la plataforma, es decir los aspectos de implementación para obtener el código.

Herramienta de transformación de modelo a código. Esta herramienta tiene como entrada un modelo (PSM) y por medio de una transformación (PSM-IM), se obtiene como salida el código (IM) que representa a dicho modelo.

Compilación y depuración. Traduce un programa en código fuente a su equivalente en código objeto. La depuración abarca la revisión del código, para detectar errores en el programa y la modificación del código.

Integración y complementación del producto de software. En este componente se procede a unir los elementos de la estructura del sistema.

Herramienta de transformación de código a modelo. Obtiene a partir del código (IM) el modelo (PSM) que lo represente, mediante una transformación inversa.

Sistema de historial de proyectos de software. Sistema que tiene la finalidad de permitir la captura de la información histórica del desarrollo de proyectos de software y almacenarla en una base de datos para su posterior análisis y comparación.

Capítulo 3

- 16 -

Herramienta de transformación de modelo a código

Editor de código

CodificaciónManual Automática

Herramienta de transformación de modelo a modelo

Modelo PSM suficiente

Validación del modelo

Editor de modelos

Modelo y código sin defectos

Herramienta de transformación decódigo a modelo

Modelado Manual Automático

Compilación y depuración

Integración y complementación del producto de software

Sistema de historial de proyectos de software

IngenieríaDirecta Inversa

Sistema de Soporte para el Proceso de Software en equipo(SiSoProS)

Herramienta de adecuación del desarrollo

Identificación de las características del proyecto de software

Herramienta de transformación de modelo a código

Editor de código

CodificaciónManual Automática

Herramienta de transformación de modelo a modelo

Modelo PSM suficiente

Validación del modelo

Editor de modelos

Modelo y código sin defectos

Herramienta de transformación decódigo a modelo

Modelado Manual Automático

Compilación y depuración

Integración y complementación del producto de software

Sistema de historial de proyectos de software

IngenieríaDirecta Inversa

Sistema de Soporte para el Proceso de Software en equipo(SiSoProS)

Herramienta de adecuación del desarrollo

Identificación de las características del proyecto de software

Figura 3.1. Estructura del ambiente AGDE

Con el propósito de iniciar el desarrollo de la herramienta de adecuación del ambiente AGDE, este trabajo de investigación aporta las bases requeridas para la comparación de proyectos de software.

En la figura 3.2 se muestra el ambiente completo del AGDE, en donde se ubica a la herramienta que aplica el procedimiento de adecuación, al inicio del desarrollo del proyecto. El ambiente AGDE parte de la adecuación del proceso para que posteriormente, el equipo de desarrollo aplique el proceso adaptado. En la figura 3.2, los elementos encerrados en el rectángulo de líneas punteadas corresponden a la ubicación de este trabajo en el ambiente de soporte al AGD. Este trabajo esta relacionado directamente con 3 elementos del ambiente AGDE: el procedimiento de adecuación del desarrollo, el historial de proyectos (almacén de datos) y el sistema de historial de proyectos. La adecuación del desarrollo en el ambiente AGDE consiste en adaptar el método de software a las características particulares de un proyecto tomando en cuenta el desarrollo de otros proyectos con características similares. Durante el desarrollo se realiza un seguimiento del proceso con la herramienta SiSoProS, proporcionando información al sistema de historial de proyectos. Para mantener disponible la información histórica de proyectos, al finalizar el desarrollo de cada proyecto, la información debe capturarse en el sistema de historial de proyectos.

Capítulo 3

- 17 -

act Ambiente AGDE detallado

Ingresar información delproyectos a la herramienta

de adecuación deldesarrollo

Registrar y monitoriar elproceso (SiSoProS)

Utilizar herramienta detransformación de modelo a

modeloEditar modelos

Validar modelo resultante

Editar código Utilizar herramienta detransformación de modelo a

código

Compilación y depuración

Ingresar la información delproyecto al sistema dehistorial de proyectos

Utilizar herramienta detransformación de código a

modelo

«datastore»Historial de

proyectos

«datastore»Déposito de modelos v alido

del producto destino

«datastore»Déposito de código

fuente

Se identifica el patrón del proyecto de entrada

«datastore»Depósito de

modelos (producto fuente)

«datastore»Depósito de modelos

(producto destino)

«datastore»Déposito de

definición de transformaciones

«datastore»Depósito de modelos

(producto destino v alido)

«datastore»Déposito de código

fuente

Integrar y completar elproducto de software

[Codificación automática]

[Ingeniería inversa]

[Modelo PSM es suficiente]

[Modelado manual] [Modelado automático]

[Codificación manual]

[Ingeniería directa]

[Sin defectos]

[Presencia de defectos]

[Modelo PSM insuficiente]

Figura 3.2. Contexto de la investigación en el ambiente AGDE

Capítulo 3

- 18 -

3.1.2 Planteamiento del problema Actualmente la adecuación del desarrollo para proyectos de software se hace necesaria debido a la diversidad de proyectos. En el ambiente AGDE se propone construir una herramienta de adecuación del desarrollo, en donde se asigne valor a los factores configurables a partir del desarrollo de proyectos pasados con características similares, con lo que se necesita identificar las características presentes en el desarrollo de un proyecto de software que permitan compararlo. El problema a resolver en esta investigación es: La carencia en la identificación de las características del desarrollo de proyectos que permita compararlos en el contexto de la herramienta de adecuación del AGDE.

3.1.3 Objetivo

El objetivo de esta investigación es caracterizar proyectos de software y el diseño de una estructura de almacenamiento de la información relativa al desarrollo de proyectos pasados, con el fin de habilitar la comparación entre proyectos. 3.1.4 Justificación Contar con una estructura que describa el desarrollo de proyectos de software basada en la experiencia de otros desarrolladores, que han abordado proyectos con características similares, puede ayudar a mejorar el desempeño y la calidad del producto final. El objetivo de utilizar una base de experiencias en el desarrollo de proyectos no es intentar encontrar un sólo enfoque de desarrollo aplicable universalmente, sino entender las circunstancias en las cuales es más apropiada la aplicación de: un conjunto de subprocesos, una herramienta etc. En el ambiente AGDE se propone utilizar el conocimiento generado en el desarrollo de proyectos de software almacenado y estructurado en la memoria organizacional, con el fin de aprovechar las experiencias del pasado y aplicarlas a las situaciones del presente. Para desarrollar este enfoque se requiere de la caracterización de los proyectos de software que permita recolectar observaciones de la experiencia de diferentes instituciones dedicadas al desarrollo de software. 3.1.5 Idea de solución Se pretende crear un marco de características de proyectos de software, para diseñar una base de datos que represente la memoria organizacional del desarrollo de proyectos, de una entidad o empresa.

Capítulo 3

- 19 -

3.1.6 Alcances y limites

Los alcances de esta tesis consisten en: el diseño de una estructura de características de proyectos de software, con la que se implementó una base de datos para mantener un historial de proyectos desarrollados; la elaboración de un prototipo para ingresar la información de proyectos de software desarrollados en la base de datos diseñada; y comparar los proyectos recolectados para obtener la similitud, aplicando la técnica de clustering. Las limitaciones de este trabajo de investigación son:

El producto resultado de esta investigación es el primer paso para la construcción del sistema de reconocimiento de patrones de proyectos de software. Con este fin se describe un marco de proyectos donde los conceptos y características se presentan explícitamente.

El procedimiento para identificar patrones de proyectos se describe de manera

general, sin evaluarlo. Un trabajo futuro será el encargado de detallarlo y probarlo.

La etapa de demostración se limitó a comparar los proyectos disponibles, sin identificar patrones.

3.2 Trabajos relacionados En esta investigación se realizó una revisión de trabajos relacionados con la caracterización de proyectos de software y la adecuación del proceso, en donde se encontraron coincidencias en la elección de características y en algunos casos en la importancia dada al conocimiento histórico del desarrollo de proyectos.

En el articulo “Report on MSR 2005: International Workshop on Mining Software Repositories” [21], se realiza un resumen del taller internacional acerca de la minería de repositorios de software, en donde se concluye que la investigación en este campo se está dirigiendo a descubrir los caminos en la minería de los repositorios de software para ayudar a entender el desarrollo de software y realizar predicciones. El enfoque de esta investigación se encuentra dentro de la minería de repositorios de software ya que se busca crear una estructura de una base de datos que permita la utilización de datos históricos. Para lo cual la estructura de la base de datos debe permitir asociar atributos del desarrollo con las características del proyecto.

Algunos trabajos relacionados con este trabajo de investigación se engloban en los siguientes puntos:

Marcos de características para la evaluación de una metodología

Utilización de experiencias pasadas del desarrollo de proyectos de software en la adecuación del proceso.

Identificación de actividades para el desarrollo de un proyecto de software

Utilización de clustering en la ingeniería de software

Capítulo 3

- 20 -

3.2.1 Marcos de características para la evaluación de una metodología En “Extreme programming evaluation framework for Object-Oriented Languages Version 1.4” [22] y en “Rational unified process evaluation framework version 1.0” [23] se definen marcos de evaluación donde se clasifica la información del proceso de software, de acuerdo a la metodología para la cual se desarrolló. Esta información se utiliza para establecer el grado en que se usa la metodología.

Estos marcos de características sirvieron de base para la conformación del marco

propuesto de características de proyectos de software, en donde se incluyeron algunos de sus atributos.

Sin embargo, el marco de características planteado como resultado de esta investigación

no se adaptó a una metodología en específica, sino que se diseñó una estructura para almacenar información de proyectos heterogéneos, aunque se utilizó el enfoque del método AGD. 3.2.2 Utilización de experiencias pasadas del desarrollo de proyectos de software en la adecuación del proceso. Los trabajos de investigación “Knowledge support in software process tailoring” [18], y “A tool for the capture and use of process knowledge in process tailoring” [24] definen la adecuación del proceso de software como una actividad intensiva en conocimiento y analizan los beneficios del uso de herramientas de gestión del conocimiento en este tipo de tareas. Distinguen entre el uso de conocimiento general acerca de la adecuación del proceso de software y el uso de conocimiento contextualizado acerca de experiencias previas en la empresa. Estos trabajos hacen énfasis en que el uso de estos conocimientos puede ser de gran ayuda, principalmente para los desarrolladores con poca experiencia que deben enfrentarse a esta tarea de adecuación.

Mencionan que el conocimiento almacenado en depósitos de conocimiento se considera como la memoria de la organización, siendo está el conocimiento de las experiencias y acontecimientos pasados que influyen en actividades presentes de la organización y que por esta razón es necesario construir depósitos de conocimiento que proporcionen información relevante como ayuda a la toma de decisiones, en la adecuación de procesos de software.

En el trabajo “Case-Based approach to tailoring software process” [25] se menciona que centrar la información alrededor de un almacén y un proceso de captura de experiencias del proyecto, puede prevenir la duplicación de esfuerzos, evitar cometer errores comunes y hacer más eficiente el proceso de desarrollo.

En [25] está descrito un sistema basado en reglas para adaptar una Metodología de

Desarrollo Estándar (SDM, por sus siglas en inglés) que permite encontrar las características individuales de proyectos y proporciona el conocimiento del desarrollo relevante en todas las partes del ciclo de vida.

Cada proyecto crea su propio caso de la SDM, lo adapta mediante reglas que igualan

características de proyectos a actividades SDM y crea un caso de proyecto específico para

Capítulo 3

- 21 -

cada actividad SDM asignada al proyecto. Los casos entonces se usan para describir soluciones de proyecto específicas con las actividades definidas.

Estos trabajos reconocen la importancia del conocimiento adquirido de la experiencia en

el desarrollo de proyectos para la adecuación del proceso, por lo que coinciden con el enfoque de esta investigación, de realizar una caracterización de proyectos para la definición de estructura de almacenamiento de proyectos pasados.

La diferencia de estos trabajos con el enfoque de la herramienta de adecuación del

AGDE, es que este enfoque incluye la identificación de patrones de proyectos para realizar la adecuación, la ventaja de definir patrones de proyectos es la posibilidad de establecer una clasificación de proyectos en base a ellos. 3.2.3 Identificación de actividades para el desarrollo de un proyecto de software En “Generador del mapa de actividad de un proyecto de desarrollo de software” [26] se establece que una de las formas de adaptar una metodología estándar, a un proyecto en particular, es a través del mapa de actividades para ese proyecto, dadas las características del mismo. Donde, una metodología estándar se describe como “la definición operacional de los procesos, básicos que guía el establecimiento de un proceso de software común en todos los proyectos de software de la organización”.

El mapa de actividades constituye una guía, orientación y recomendación para el

responsable del proyecto, pero no es un catálogo que se deba cumplir en forma obligatoria. Si bien el mapa recomienda las actividades que deberían llevarse a cabo, no determina las iteraciones o formas de abordar las mismas, que el proceso de software implique, de acuerdo a las particularidades del proyecto.

En este trabajo relacionado se describe un sistema basado en conocimiento que permite

ingresar las particularidades del proyecto, para inferir el mapa de actividades sobre la base de la metodología estándar Métrica Versión 3 y lo presenta en un formato electrónico estándar. “Métrica Versión 3 es una metodología flexible, con una estructura propuesta adaptable que incluye procesos y actividades que no se ejecutan siempre en su totalidad”

Sin embargo, la adaptación de la metodología estándar se limita a la selección de

actividades, es decir a los lineamientos y criterios referidos a la selección de actividades de la metodología estándar. Ese subconjunto de actividades a desarrollar, dadas las particularidades de un proyecto, se formaliza en el mapa de actividades del proyecto.

Para construir el sistema, utilizó la educción de conocimientos. La educción es, específicamente, el proceso de interactuar con un experto humano, con el propósito de construir un SBC (Sistema Basado en Conocimiento).

En “Variations in Software Development Practices” [27] se presenta el análisis de la

información de 12,000 proyectos de software recolectados entre 1984 y 2003. El análisis lo realizaron separando proyectos en categorías distintas que comparten un método de desarrollo común. Las categorías que se utilizaron se establecieron utilizando el tamaño en puntos de función y el tipo de aplicación del software.

Capítulo 3

- 22 -

Se identificaron 6 tipos principales para la clasificación de software, esta clasificación se relaciona con el lugar de aplicación del software y son software: militar, de sistemas, comercial, de outsourced, de sistemas de información y administración, de desarrollo y de usuario final.

También se establecieron las actividades estándar para analizar la aplicación de cada

actividad para cada tipo de software. En donde observaron que los tipos de software militar, de sistemas y comercial tienen actividades con mayor complejidad que los sistemas de información y administración. Siendo el software de usuario final el que presenta menor número de actividades en el desarrollo de software.

Con respecto al análisis del tamaño, profesión de los desarrolladores y el tipo de

software, este trabajo de investigación examinó las asociaciones entre las profesiones y el tamaño de los proyectos y concluye que el tamaño influye fuertemente en actividades de desarrollo y en la necesidad del personal especializado. Por lo general en el desarrollo de proyectos pequeños se usan métodos de desarrollo informales, en cambio para sistemas grandes el personal es especializado y se utiliza una metodología mucho más complicada.

En este trabajo se menciona que la reutilización de procesos de desarrollo de software

aumenta la eficacia de sus operaciones y permite a ingenieros de proceso enfocarse en realzar y adaptar el proceso.

Con lo que estos trabajos relacionados, abren la pauta de la posibilidad de encontrar

patrones de proyecto a los que se les asocie un proceso de desarrollo. 3.2.4 Utilización de clustering en la ingeniería de software En este punto se analizó la aplicabilidad de la técnica de clustering en una base de datos con información del desarrollo de software.

En “Comparación de diferentes algoritmos de clustering en la estimación de costo en el desarrollo de software” [28] se propone aplicar la técnica de clustering para segmentar una base de datos heterogénea, con el fin de lograr grupos homogéneos de manera que para cada uno de estos grupos (formados por proyectos homogéneos entre sí) se obtenga una relación matemática diferente, lo que mejora el proceso de estimación. En este trabajo se experimentó con tres algoritmos de agrupamiento diferentes: COBWEB, EM, y K-means, donde EM y K-means dieron mejores resultados para segmentar una base de datos de proyectos de software, con el fin de mejorar la estimación del costo de software.

Este trabajo aportó el enfoque de la comparación de proyectos utilizado en esta

investigación, en donde se utilizó el algoritmo K-means para agrupar. En el cuadro 3.1 se muestra un resumen de los trabajos relacionados y la presente

investigación, identificando el producto obtenido, el método que siguió cada trabajo y el objetivo de cada trabajo.

Capítulo 3

- 23 -

Tabla 3.1. Resumen de trabajos relacionados

Trabajo Objetivo Método Producto Extreme programming evaluation framework for Object-Oriented Languages Version 1.4 [22]

Definir un marco de medición para evaluar la adopción de prácticas XP y sus resultados.

Definición de características de contexto del proyecto y una métrica de adhesión para medir cómo el equipo de desarrollo sigue los principios de XP.

Marco de evaluación para la metodología XP.

Rational unified process evaluation framework version 1.0 [23]

Definir un marco de medición para evaluar la adopción de prácticas RUP y sus resultados.

Definición de características y una métrica de adhesión para medir cómo el equipo de desarrollo sigue los principios de RUP.

Marco de evaluación para la metodología RUP.

Knowledge support in software process tailoring [18]

Investigar el rol del conocimiento en el procedimiento de adecuación.

Distinguen entre el uso de conocimiento general sobre la adecuación del proceso de software y el uso de conocimiento contextualizado acerca de experiencias previas en la empresa.

Sistema basado en reglas para adaptar un una metodología estándar.

Generador del mapa de actividad de un proyecto de desarrollo de software [25]

Recomendar a los responsables de proyectos de desarrollo de software un mapa de actividades su proyecto.

Por medio del conocimiento de expertos se establecieron las reglas para asignar las actividades de acuerdo a las características de proyectos.

Sistema basado en conocimiento para la construcción de mapas de actividades para proyectos de software.

Variations in Software Development Practices [26]

Análisis de características de proyectos de software desarrollados.

Análisis de proyectos desarrollados, en base a las características: tamaño en puntos de función y al tipo de aplicación del software.

Identificación de actividades del proceso de desarrollo de software de acuerdo a la clasificación del proyecto.

Comparación de diferentes algoritmos de clustering en la estimación de costo en el desarrollo de software [27]

Analizar la bondad de las predicciones de estimaciones de costos de software utilizando estimaciones paramétricas y algoritmos de clustering.

Aplicación de diferentes algoritmos de clustering a una base de datos de proyectos de software y la evaluación de las agrupaciones.

Identificación del algoritmo de clustering con mejores resultados para segmentar una base de datos de proyectos de software, con el fin de mejorar la estimación del costo de software.

Propuesto

Caracterizar proyectos de software y el diseño de una estructura de almacenamiento para habilitar la comparación de proyectos.

Definición de características de proyectos, indicando la forma en que se obtendrán, el tipo de escala y las alternativas de valores correspondientes. Utilizando medidas de distancia para realizar comparaciones entre proyectos.

Base para la construcción de la herramienta de adecuación del desarrollo incluida en el ambiente AGDE. Marco de características de proyectos de software y una estructura de base de datos.

Capítulo 3

- 24 -

La revisión del contexto del problema planteado en esta investigación permitió realizar un análisis acerca de la caracterización de proyectos, que permite plantear una solución, retomando el enfoque de los trabajos relacionados, expuestos en este capítulo. Las ideas principales que se tomaron son:

Partir del conocimiento generado en el desarrollo de proyectos pasados, para la adaptación del proceso a las características particulares de un proyecto de software.

Segmentar una base de datos para partir de grupos homogéneos, ya que tratar de encontrar un modelo de clasificación de proyectos para asociarle un proceso de desarrollo, se dificulta por la heterogeneidad de los proyectos de software.

- 25 -

Capítulo 4: Solución propuesta En este capítulo se presenta el Marco de Características de Proyectos de Software (MCPS), el cual es el producto resultado de este trabajo de investigación. Éste satisface un paso inicial para la implementación de la herramienta de adecuación del desarrollo de software del ambiente AGDE.

La caracterización de proyectos de software se tomó como base para estructurar la información generada en el desarrollo de proyectos, con el fin de crear un almacén para la información y que se utilice en una investigación futura, para la identificación de patrones de proyectos, mediante la comparación de diferentes grupos de atributos. 4.1 Planteamiento de la solución La solución propuesta en este trabajo de investigación es el diseño de un marco de características, donde se integren los atributos relacionados con el desarrollo de un proyecto de software y de esta manera diseñar una base de datos para el almacenaje de la información de proyectos desarrollados. Con esto se pretende mantener disponible el cocimiento generado en proyectos pasados para el procedimiento de adecuación de desarrollos de nuevos productos de software.

Capítulo 4

- 26 -

En este trabajo de investigación se presenta un marco para la caracterización de proyectos de software, un conjunto de factores y características establecidos en base a trabajos relacionados, a la literatura sobre el producto y el proceso de software y a la recolección de de información histórica de dos organizaciones La identificación de las características de proyectos es necesaria para la implementación de la herramienta de adecuación del desarrollo incluida en el AGDE, cuyo objetivo es proporcionar una guía para la configuración del desarrollo mediante la identificación de patrones de proyectos, debido a que un patrón de proyecto surge de la experiencia en el desarrollo de sistemas con características similares.

En las figuras 4.1 y 4.2 se muestran los diagramas de actividad del Procedimiento

general para Identificar Patrones de Proyectos (PIPP). Para aplicar el procedimiento PIPP es necesario disponer de información histórica de

proyectos de software para almacenarla en una base de datos, que proporcione los recursos para la identificación de patrones de proyectos. En el proceso de creación de la base de datos se elaboró el modelo relacional (sección 4.3) que muestra el esquema de la información a almacenar.

Una vez establecida la base de datos, se procederá a almacenar el mayor número

posible de proyectos para identificar casos similares y posiblemente patrones de proyectos (exitosos). Cada proyecto se define mediante una serie de atributos, incluidos en el marco de características de proyectos desarrollado en esta investigación.

Para la captura de la información de proyectos de software se cree que es más factible

ingresar la información de proyectos conforme se conciben y se desarrollan, ya que cuando se ingresa la información después del desarrollo, puede haber datos faltantes o inconsistencias en sus valores.

Con la base de información histórica resultante, se habilitará el desarrollo de un sistema

de gestión de conocimiento capaz de procesar y almacenar la información generada durante el desarrollo de un proyecto de software, con el fin de identificar patrones en la configuración de proyectos, a partir de casos. La posibilidad de descubrir patrones en la configuración del proyecto exitosos, permitirá disminuir la probabilidad de repetir errores, incrementando la competitividad del equipo de trabajo.

El primer paso para la construcción del sistema de reconocimiento de patrones fue

modelar la información generada durante el proceso de desarrollo del proyecto y estructurarla de forma que facilite su interpretación. Con este fin se desarrolló en esta investigación el marco de características de proyectos de software (MCPS) cuyos conceptos y características se presentan explícitamente en la sección 4.2.

Richard Gabriel en “A Timeles Way of Hacking”, menciona que un patrón de diseño es

una regla de 3 partes, que expresa una relación entre un contexto, un sistema de fuerzas (problema) que ocurren repetidamente en ese contexto y una configuración de software (solución) que permite resolver el problema. [22]

Partiendo de esta definición, se tiene que el contexto en el que se pretende identificar

patrones es el desarrollo de software, donde se tienen diversos proyectos a desarrollar y

Capítulo 4

- 27 -

para cada proyecto es necesario establecer una configuración del desarrollo (conjunto de productos a obtener y proceso a seguir).

Para conseguir este objetivo se requiere organizar la información agrupando sus

atributos adecuadamente.

Las características de proyectos de software se agruparon en conjuntos, como sigue:

A = {Factores que identifican el tipo de proyecto y al producto de software} B = {Factores para valoración} C = {Factores sociológicos} D = {Factores del ambiente de ingeniería} E = {Factores configurables en el desarrollo}

EDCBAF ∪∪∪∪= = {Características de proyectos de software} De acuerdo a la definición de patrón de diseño en donde se reconocen 3 partes se tiene lo siguiente: El contexto es: desarrollo de proyectos de software Sistema de fuerzas que ocurre repetidamente en ese contexto: DBA ∪∪ Configuración que permita que se resuelvan esas fuerzas: EC ∪

En los principios postulados por Martin Fowler en “Analysis Patterns” [8] se menciona que

un patrón de diseño no es una solución en sí misma, sino la documentación de la forma en que se construyeron soluciones a problemas similares en el pasado, lo cual permite una mejor gestión de la experiencia y transferencia de conocimientos.

El objetivo del procedimiento PIPP es identificar patrones de proyectos que concuerden

con las características de proyectos de software. Este procedimiento se dividió en 2 pasos: El primer paso consiste en identificar los conjuntos de proyectos similares tomando en

cuenta las características de los conjunto A, B y D, con el propósito de identificar conjuntos de proyectos con características comunes sin considerar aspectos del desarrollo. Para esto se tendrá un campo en la tabla Proyecto, de la base de datos, que contendrá el conjunto asociado a cada proyecto (ver figura 4.1), lo que permitirá tener un identificador del conjunto al que pertenece cada proyecto.

Se tomó como criterio una similitud mayor o igual a 0.80 como una similitud alta por cada

par de proyecto a comparar. Una similitud alta en la comparación de 2 proyectos indica que pertenecen a mismo conjunto.

Capítulo 4

- 28 -

act PASO 1

Ingresar las características establecidas en losconjuntos A, B, C, D y E del proyecto a almacenar

Obtener los conjuntos de proyectossimilares conciderando las

caracteristicas de los conjuntos A,B y D

Guardar proyecto en labase de datos

Obtener la similitud de cada parde proyecto por conjunto

Actualizar los conjuntos deproyectos, excluyendo los

proyectos con similitud < 0.80

Actualizar el campo"conjunto_asociado" de cada

proyecto almacenado

[Base de datos con proyectos]

[Estado de la base de datos]

[Base de datos vacía]

Figura 4.1. Diagrama de actividad del Procedimiento general para Identificar

Patrones de Proyectos (PIPP) (paso 1)

El segundo paso del PIPP consiste en obtener la similitud en el conjunto C y E, que corresponde a las características sobre el desarrollo del proyecto, de los conjuntos de proyectos (ver figura 4.2.).

En el paso 2 también es necesario evaluar el proceso de desarrollo empleado en los

proyectos identificados como patrones para determinar si se trata de un patrón de éxito o de fracaso, con el propósito de considerar sólo patrones de éxito para la configuración del desarrollo de proyectos.

Capítulo 4

- 29 -

act PASO 2

Obtener el tamaño del conjunto"CONJUNTO"

Obtener la similitud de la configuración deldesarrollo (características de los cojuntos C y E)

del conjunto de proyectos "CONJUNTO"

Leer siguiente proyecto de labase de datos, con v alor del

campo conjunto_asociadodiferente a los ya analizados

Leer el v alor del campoconjunto_asociado del primer proyecto

de la base de datos "CONJUNTO"

Valoración de la configuración

Establecer el patrónde proyecto

[Base de datos con proyectos]

[Sin éxito]

[Estado de la base de datos]

[Tamaño >= NM]

[Estado de la base de datos]

[Simili tud>= 0.80]

[Exitosa]

[No existen proyectos porleer en la base de datos]

[Base de datos vacía]

[Simili tud < 0.80]

[Tamaño < NM]

[Existen proyectos porleer en la base de datos]

Figura 4.2. Diagrama de actividad Procedimiento general para Identificar

Patrones de Proyectos (PIPP) (paso 2)

Nota: NM indica el número mínimo establecido como criterio para considerar el grupo de proyectos conformado por cada proyecto y el conjunto de proyectos asociados, como un posible patrón.

Capítulo 4

- 30 -

4.2 Marco de Características de Proyectos de Software (MCPS) En esta investigación se propone estructurar la información del desarrollo de proyectos de software para que a partir de la estructura se construya una base de datos para almacenar esta información. Esta base de datos materializa la estructura de información y establece un marco de características de proyectos, en el que se almacenan los valores de un conjunto de atributos presentes en el desarrollo de un proyecto de software. 4.2.1. Descripción del marco MCPS El marco de características de proyectos que se elaboró, está dividido en 5 conjuntos de características, que describen a un proyecto de software. El objetivo de este marco, es que a partir de él se conforme la estructura en la que será almacenada la información de proyectos en la memoria organizacional, que se utilizará en una investigación posterior, para la identificación de patrones de proyectos.

Los elementos considerados para la conformación del marco de proyectos fueron: 1) los

atributos del proceso de desarrollo, en donde se determinaron algunas métricas y se identificaron atributos que pueden configurarse dependiendo de las características del proyecto a desarrollar; 2) el producto en donde se determinaron métricas y características que lo describen; 3) el ambiente de ingeniería del desarrollo del proyecto; 4) y las personas involucradas en el desarrollo del proyecto. Todos estos elementos considerados desde el punto de vista del trabajo en equipo, donde dos o mas personas trabajan de manera coordinada y cada una con un determinado rol para la ejecución del proyecto.

Un factor implícito en los elementos: proceso, producto, personas y ambiente de

ingeniería, es la posibilidad de configuración de algunas características, es decir la existencia de aspectos que se pueden cambiar en función de los resultados de proyectos previos, como el número de integrantes, o el conjunto de productos del trabajo.

La definición y selección de características que conforman el marco se establecieron en

base a los trabajos relacionados [22] [23] [27] [28] y a la literatura que trata temas acerca de las características de proyectos. Estas características resultantes se adecuaron de acuerdo a un trabajo de campo, donde se recolectó información de 5 proyectos de software, del área de sistemas de información. 4.2.2 Estructura del marco MCPS El marco de características se estructuró, en base a la asignación de valores numéricos o categorías de valores a los atributos de un proyecto de software, para describir sus cualidades. Los conceptos que maneja el marco de características son los siguientes: 1. Factores: conjuntos en los que se agruparon las características incluidas en el MCPS, los

factores permiten clasificar los proyectos tomando grupos de las características de cada proyecto de software. Los factores o conjuntos de atributos que conforman el marco de proyectos son:

Factores que indican el tipo de proyecto de proyecto y al producto de software

Factores de valoración

Capítulo 4

- 31 -

Factores sociológicos

Factores del ambiente de ingeniería

Factores configurables

2. Atributos: son las características que conforman a cada conjunto de factores. 3. Criterio para la asignación del valor: que determinan la asignación de valores a los atributos. 4. Tipo de escala de medida: es el tipo de unidad utilizada en las reglas de medición, para la

asignación de los valores a los campos. Algunos tipos principales de escalas de medición son:

Nominal: los valores son cualitativos, sin ninguna jerarquía entre los diferentes grupos, como por ejemplo: nombres de personas, tipo de software. Estas variables no tienen ningún orden inherente a sus valores ni un orden de jerarquía.

Ordinal: cuando las categorías o valores que adopta un campo cualitativo posee un orden esperado, secuencia o progresión natural, como por ejemplo: nivel socioeconómico bajo, medio o alto.

Absoluta: valor numérico que se obtiene contando los elementos (por ejemplo el número de personas en un proyecto).

5. Alternativas: es el conjunto de los posibles valores a asignar a cada atributo de acuerdo a

su escala y reglas de medición.

El objetivo de la definición de atributos, del establecimiento de criterios para la asignación del valor y alternativas a cada característica del marco es facilitar la recolección confiable de la información de proyectos y el reconocimiento de los patrones de proyectos al limitar los valores de las opciones de cada factor del marco.

Algunos de los criterios para la asignación de valor a las características, corresponden a

la información recabada en el estudio de campo, en donde se identificaron algunas clasificaciones. Otras métricas se establecieron con base a documentos estándar existentes, como el caso de la complejidad del software (IEEE Std 1045-1992) y la criticidad de proyectos (IEEE Std 610.12-1990). La mayoría de las alternativas propuestas para el conjunto de factores configurables están basadas en modelos bien conocidos, bien descritos y disponibles públicamente como las normas del IEEE, PSP y TSP, así como en el método de Desarrollo Arquitectónico en Grupo AGD.

4.2.2.1 Factores que identifican el tipo de proyecto y al producto de software El tipo de proyecto se describe a partir de varias características, como la naturaleza del proyecto, la clasificación a la que pertenece el software (producto resultado), la criticidad del software, el contexto del proyecto y los riesgos identificados para el proyecto. Estos atributos y alternativas se muestran en la tabla 4.2.

Capítulo 4

- 32 -

La naturaleza de un proyecto indica, si el proyecto tiene algún antecedente o si se va a agregar algún módulo, si se trata de una migración de lenguaje, de un mantenimiento, de un esfuerzo de reingeniería o de un nuevo proyecto.

Para la clasificación del software se presentan 5 posibles categorías: software de

sistema, software comercial, sistema de información, software militar y software de usuario final. En la tabla 4.1 se describen las categorías de clasificación.

Estas categorías fueron seleccionadas a partir del trabajo "Variations in Software

Development Practices" de Jones Copers [27], en donde se presenta el análisis de la información de 12,000 proyectos de software recolectados entre 1984 y 2003. El análisis lo realizaron separando proyectos en categorías distintas que comparten un método de desarrollo común.

Tabla 4.1. Clasificación del software

Clasificación Descripción Software de sistema

Software usado para controlar dispositivos físicos, como una computadora o interruptor telefónico.

Software comercial Estas aplicaciones de software son producidas para el control de comercialización en gran escala, a cientos o posiblemente millones de clientes.

Sistemas de información

Software producido para apoyar el negocio de una empresa y sus funciones administrativas.

Software militar Software producido para una organización militar y se adhiere a normas del Departamento de Defensa o equivalente.

Software de usuario final

Se refiere a pequeñas aplicaciones desarrolladas para uso personal.

La criticidad del software es el impacto debido al fracaso de software. ¿Cuál es la peor

cosa que puede pasar si el software falla?. Puede ser que la empresa sufra grandes o pequeñas pérdidas económicas o es posible que se ponga en peligro la vida de personas, etc. En el estándar IEEE Std 610.12-1990 la criticidad se define como el grado de impacto del requisito, el módulo, el defecto, el fracaso, la falla u otro aspecto relacionado con el desarrollo o la operación de un sistema [5].

El riesgo se define como “la posibilidad de sufrir una pérdida” [33]. Aunque ha habido

debates acerca de la definición adecuada, existe el acuerdo en que el riesgo siempre implica dos características: 1) incertidumbre, de que ocurra el acontecimiento que caracteriza al riesgo y 2) pérdida, pues si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas [34].

La primera etapa de la administración de riesgos, comprende el descubrimiento de los

posibles riesgos del proyecto, en donde se agrupan por tipos. Los tipos de riesgos se pueden definir de la siguiente manera [29]:

Riesgos de tecnología: éstos se derivan de las tecnologías de software o hardware utilizadas en el sistema que se está desarrollando.

Riesgos de personas: riesgos asociados con las personas en el equipo de desarrollo.

Capítulo 4

- 33 -

Riesgos organizacionales: éstos se derivan del entorno organizacional donde el software se está desarrollando.

Riesgos de herramientas: de derivan de herramientas de soporte utilizadas para desarrollar al sistema.

Riesgos de requerimientos: se derivan de los cambios de los requerimientos del cliente y el proceso de administrar dichos cambios.

Riesgo de estimación: se derivan de los estimados administrativos de las características del sistema y de los recursos requeridos para construir dicho sistema.

Una vez identificados los riesgos, estos se caracterizan indicando la probabilidad de que

puedan convertirse en problemas y por su impacto al proyecto cuando se conviertan en problemas. Los valores de impacto pueden clasificarse en catastrófico, serio, tolerable o insignificante.

El contexto del proyecto es otro atributo identificado para este factor que corresponde al

área de aplicación del producto de software, como medicina, educación, contabilidad, finanzas, etc.

En la tabla 4.2 se muestra una síntesis de las definiciones de las medidas para los

atributos de los factores que identifican el tipo de proyecto y producto de software. En esta tabla se indica por cada atributo, el criterio para la asignación del valor, el tipo de escala y las posibles alternativas (opciones) que puede tomar dicho atributo. Por ejemplo, para el caso del atributo clasificación del software, se tiene que el valor se requiere ubicar en algunas de las 5 clasificaciones establecidas como alternativas, por lo que la escala de medición es nominal, y las alternativas establecidas son: software de sistema, software comercial, sistema de información, software militar y software de usuario final.

Tabla 4.2. Definición de medidas para factores que identifican el tipo de proyecto y

al producto de software

Atributo Criterio para la asignación del valor

Tipo de escala Alternativas

Clasificación del software [27]

Ubicar el proyecto en alguna de las 5 clasificaciones establecidas.

Nominal a) Software de sistema b) Software comercial c) Sistema de información d) Software militar e) Software de usuario final

Contexto del proyecto

Indicar el entorno donde se utilizará el sistema.

Nominal a) Administrativo b) Bancario c) Contabilidad d) Educación e) Electrónica f) Finanzas g) Medicina h) Telecomunicaciones i) Ventas j) Otro

Naturaleza del proyecto

Identificar la naturaleza de cuerdo a las alternativas establecidas.

Nominal a) El proyecto tiene antecedentes. b) Proyecto de desarrollo de una nueva aplicación. c) Proyecto de mejora de aplicaciones. d) Proyecto de mantenimiento de aplicaciones.

Capítulo 4

- 34 -

e) Proyecto de reingeniería.

Para cada riesgo identificar su tipo

Nominal Tipos: a) Riesgo de tecnología b) Riesgo de personas c) Riesgo organizacional d) Riesgo de herramientas e) Riesgo de requerimientos f) Riesgo de estimación

Probabilidad de que ocurra

Ordinal Probabilidad: Muy bajo, bajo, moderado, alto o muy alto.

Riesgos del proyecto [29]

Impacto Ordinal Impacto: catastrófico, serio, tolerable o insignificante Criticidad del software [5]

Naturaleza del daño ocasionado por los defectos en el software.

Nominal a) Criticidad sin efecto b) Pérdida de confort c) Pérdida económica d) Daños a la salud e) Pérdidas de vidas

4.2.2.2 Factores de valoración Los factores de valoración permiten cuantificar algunas características del producto y del proceso en los proyectos, en términos de tamaño del software, costo del proyecto, complejidad de los datos y de programación, tiempo de desarrollo y defectos insertados y eliminados. Los factores de valoración se consideran importantes para evaluar la eficiencia y complejidad del desarrollo, así como la confiabilidad del producto en los proyectos, para cuantificar el grado de éxito o de fracaso del proyecto.

Cada atributo de este conjunto está conformado por los valores estimados y los reales, que permitirán determinar el nivel de eficiencia del proceso de desarrollo. Estas medidas cubren importantes características de los productos y del proceso de software, que son relevantes en la planificación, control y mejora del proceso. No son las únicas posibles, pero pueden utilizarse para describir los productos y procesos de software, además de ser medidas prácticas que producen información útil.

La medición del software se refiere a derivar un valor numérico para algún atributo de un

producto de software o un proceso de software. Comparando los valores resultados de la medición, es posible obtener conclusiones de la calidad del software y del proceso de software.

Hay cuatro razones empíricas para medir los procesos de software, los productos y los

recursos [30]:

1. Caracterizar para facilitar el entendimiento de los procesos, productos, recursos, entornos y para establecer líneas base que sirvan de referencia en estimaciones futuras.

2. Evaluar para determinar el estado actual respecto a los planes. Las medidas son los sensores que avisan cuando los proyectos y procesos se están desviando de los planes, y por tanto, poder corregir esa desviación. También se evalúa para estimar o determinar el nivel de cumplimiento de los objetivos de calidad y para determinar el

Capítulo 4

- 35 -

impacto que la mejora de la tecnología y de los procesos tiene sobre los productos y los propios procesos de software.

3. Pronosticar para posibilitar la planificación. Medir para poder pronosticar supone ganar en el entendimiento de la relación existente entre procesos y productos. Si construimos modelos de estas relaciones, los valores que recojamos de algunos atributos pueden ser usados para predecir o pronosticar otros. Esto se hace porque se quieren establecer objetivos alcanzables respecto al costo, los plazos de entrega y la calidad, asignando los recursos apropiados a cada tarea. Los datos históricos pueden ayudar a analizar las desviaciones de las estimaciones respecto de la realidad y poder corregir las desviaciones para disminuir los riesgos futuros.

4. Medir para mejorar. La información cuantitativa debe ayudar a identificar las barreras e ineficiencias de nuestro proceso, así como las oportunidades de mejora de los productos y procesos. Medidas correctas también harán más fácil la comunicación de objetivos de mejora y las razones por las que se establecen.

Una métrica es un sistema de las medidas relacionadas, que facilita la cuantificación de

alguna característica particular [35] y una métrica de software “es cualquier tipo de medida relacionada con un sistema, proceso o documentación de software” [29]. Las métricas de software se pueden clasificar en:

1) Métricas del producto 2) Métricas del proceso

Estos grupos de métricas se explican a continuación: 1) Métricas de producto Las métricas del producto se refieren a las características del software, como el tamaño, la complejidad, los atributos de calidad, como la mantenibilidad. Las métricas de producto se dividen en dos clases [29]:

1. Métricas dinámicas que son las recolectadas cuando el programa está en ejecución. 2. Métricas estáticas que son las mediciones hechas en las representaciones del

sistema como el diseño, el programa o la documentación. En el marco de proyectos se han incluido 2 métricas del producto de clase estática, el

tamaño y la complejidad. Una medida del tamaño de un proyecto son los puntos de función (PF) y otra

representación, tradicional, son las líneas de código (LOC, por sus siglas en inglés). Watts Humphrey en “A Discipline for Software Engineering” [36] pide llevar registro del número de los tipos de líneas de código fuente siguientes:

Base (B). Es el tamaño en líneas de código del programa desarrollado previamente, antes de que se haga cualquier modificación.

Borradas (Bo). Es el total de líneas de código borradas del programa base.

Capítulo 4

- 36 -

Modificadas (M). Las líneas de código cambiadas en el programa base, contadas en la conclusión del proyecto. Podría contarse cada línea de código modificada como una línea borrada y una línea añadida.

Reutilizadas (R). Las LOC de programas previamente desarrollados que son usadas sin modificación, contada en la conclusión del desarrollo.

Totales (T). El total de líneas de código del programa finalizado, medido al concluir el proyecto.

Añadidas (A). Las LOC adheridas durante el proyecto actual, calculadas como A=T-B+Bo-R.

Nuevas y Cambiadas (N). Todo el código añadido o modificado, calculado como N=A+M.

Nuevas Reutilizadas. Las LOC desarrolladas en el proyecto actual que son adheridas a la librería de reutilización, contadas en la conclusión del proyecto.

Los PF son unidades de medición de software desde una perspectiva del usuario,

dejando de lado los detalles de codificación. Es una técnica totalmente independiente de todas las consideraciones del lenguaje [37].

La técnica de PF fue introducida por Albrecht [38] y su propósito es medir el software

cualificando la funcionalidad que proporciona, basándose en el diseño lógico del sistema.

Los objetivos de los puntos de función son:

Medir lo que el usuario pide y lo que recibe.

Medir independientemente de la tecnología utilizada en la implantación del sistema.

Proporcionar una métrica de tamaño que proporcione soporte al análisis de la calidad y la productividad.

Proporcionar un medio para la estimación del software. La técnica de PF, se basa, principalmente, en la identificación de los componentes del

software en términos de transacciones y grupos de datos lógicos que son relevantes para el usuario [39].

En cuanto a la complejidad del software en el estándar sobre métricas de productividad

del software de la IEEE [40], se divide en tres tipos: complejidad de la programación, complejidad de los datos y la complejidad organizacional. Por lo que se requiere asignar un grado para los tres tipos de complejidades. 1. Complejidad de programación. La complejidad de programación trata el flujo de control del

programa de un producto de software.

Bajo, cuando existen ciclos y cálculos simples.

Medio, la comunicación entre módulos es simple, cálculos moderadamente difíciles

Alto, estructura de datos, cálculos complejos que requieren resultados exactos.

Capítulo 4

- 37 -

2. Complejidad de los datos. La complejidad de los datos se refiere al arreglo, al acceso, y a la recuperación de datos almacenados.

Baja, arreglos simples o archivos en memoria principal, pocas entradas/salidas, ninguna reestructuración de datos.

Media, múltiples entradas/salidas, reestructuración de datos, acceso a otros medios de comunicación de almacenaje (por ejemplo, la cinta, el disco duro, otras máquinas).

Alta, las estructuras de datos son sumamente acopladas y relacionadas, se aplican algoritmos optimizados de búsqueda y se realizan comprobaciones detalladas de la consistencia de los datos.

3. Complejidad de organización. La complejidad organizacional se refiere a la dificultad en la

coordinación y la comunicación con todos los participantes del equipo de proyecto.

Sólo una persona

Grupo simple de un departamento

Grupo de varios departamentos

Múltiples Sitios

Desarrollo de subcontrato(s) por terceras partes. 2) Métricas del proceso Las mediciones del proceso son datos cuantitativos acerca de los procesos del software. Se pueden recolectar tres clases de métricas del proceso:

1. El tiempo requerido para complementar un proceso en particular. Éste es el tiempo total dedicado al proceso, el tiempo de calendario, el tiempo invertido en el proceso por desarrollador.

2. Los recursos requeridos para un proceso en particular. Los recursos pueden ser los costos de viajes, los recursos de cómputo, entre otros.

3. El número de ocurrencias de un evento en particular. Ejemplos de esta clase son el número de defectos descubiertos durante la inspección de código, el número de peticiones de cambios en los requerimientos, entre otras.

Las medidas del proceso incluidas en el marco de proyectos, son los tiempos de desarrollo, el número de defectos y los costos del desarrollo del proyecto. Un defecto es un requerimiento, diseño o elemento de implementación que, si no se cambia, podría causar un diseño, implementación, pruebas, o mantenimiento inapropiado [36]. Es importante que se recolecte la información de ocurrencias de defectos por cada producto del trabajo, de esta manera se tendrá información sobre las incidencias en distintas etapas del desarrollo. En la tabla 4.3 se muestra la definición de las medidas correspondientes a aspectos del producto y proceso, incluidas en los factores de valoración. En esta tabla se indica por cada atributo, el criterio para la asignación del valor, el tipo de escala y las posibles alternativas que puede tomar dicho atributo (puede o no tener, según sea su escala). Por ejemplo, para

Capítulo 4

- 38 -

el caso del atributo tamaño, en la columna criterio para la asignación del valor, se tienen 4 reglas que: indican la cantidad de líneas de código, de puntos de función y el número de líneas de código por cada tipo. En cuanto al tipo de escala, es escala absoluta, por lo que no se establecen las posibles alternativas ya que se espera el resultado del conteo.

Tabla 4.3. Definición de medidas para los factores de valoración

Atributo Criterio para la asignación del valor Tipo de escala Alternativas

Cantidad real del total de líneas de código (sin contar comentarios y líneas en blanco) del sistema.

Absoluta

Cantidad estimada de los puntos de función.

Absoluta

Cantidad real de los puntos de función. Absoluta

Tamaño

Cantidad de líneas de código de tipo: base, borradas, reutilizadas, añadidas, modificadas, nuevas y cambiadas y nuevas reutilizadas [36].

Absoluta

Complejidad de programación Ordinal

a) Bajo: cuando existen ciclos y cálculos simples.

b) Medio: la comunicación entre módulos es simple, cálculos moderadamente difíciles.

c) Alto: estructura de datos, cálculos complejos que requieren resultados exactos.

Complejidad [40]

Complejidad en los datos Ordinal a) Bajo: arreglos simples o archivos en memoria principal, pocas entradas/salidas, ninguna reestructuración de datos.

b) Medio: múltiples entradas/salidas, reestructuración de datos, acceso a otros medios de comunicación de almacenaje (por ejemplo, la cinta, el disco duro, otras máquinas).

c) Alto: las estructuras de datos son sumamente son acoplados y relacionadas, optimizados algoritmos de búsqueda, comprobaciones de consistencia de datos de fondo.

Tiempo de duración estimado para el desarrollo del proyecto

Absoluta

Tiempo de duración real en el desarrollo del proyecto

Absoluta

Tiempo de desarrollo (en minutos)

Tiempo de desarrollo por producto de trabajo

Absoluta

Número defectos insertados por producto de trabajo.

Absoluta Defectos

Número de defectos removidos por producto de trabajo.

Absoluta

Costo estimado del desarrollo del proyecto Absoluta Costo Costo real del desarrollo del proyecto Absoluta

Capítulo 4

- 39 -

4.2.2.3 Factores sociológicos

Estos tipos de factores corresponden a las características del equipo de desarrollo que identifican las cualidades de cada desarrollador. Las características consideradas como factores sociológicos son:

Nivel de educación por cada integrante del equipo de desarrollo.

Experiencia del equipo en el dominio del proyecto, en el lenguaje de programación, en las herramientas de soporte y en la metodología de software.

Experiencia del equipo en el desarrollo de software. El número de integrantes del equipo de desarrollo y los roles emprendidos son parte del

conjunto de los factores configurables (ver sección 4.2.2.5). En la tabla 4.4 se muestra la definición de las medidas establecidas para cada atributo de

los factores sociológicos. En esta tabla se indica por cada atributo, criterio para la asignación del valor, el tipo de escala y las posibles alternativas que puede tomar dicho atributo (puede o no tener, según sea su escala). Por ejemplo, para el atributo nivel de educación se tiene establecido el criterio para la asignación del valor: “identificar el nivel de acuerdo a las alternativas establecidas”, donde el tipo de escala es ordinal, por lo que existe jerarquía en las alternativas.

Tabla 4.4. Definición de medidas para los factores sociológicos

Atributo Criterio para la asignación del valor

Tipo de escala Alternativas

Nivel de educación Identificar el nivel de educación de cada desarrollador de acuerdo a las alternativas establecidas.

Ordinal a) Técnico b) Ingeniería ó Licenciatura c) Maestría d) Doctorado e) Otro

Experiencia en años en el desarrollo de software.

Absoluta Experiencia del equipo en el desarrollo del proyecto Forma de adquirir la experiencia

por desarrollador. Ubicarla en alguna de las alternativas.

Nominal a) La obtenida en una institución educativa b) Obtenida en la industria c) Obtenida de manera independiente

Experiencia en años en implementaciones en el lenguaje de programación a medir.

Absoluta Experiencia del equipo en el lenguaje de programación

Forma de adquirir la experiencia por desarrollador. Ubicarla en alguna de las alternativas.

Nominal a) La obtenida en una institución educativa b) Obtenida en la industria c) Obtenida de manera independiente

Experiencia en años en la aplicación de la metodología a medir.

Absoluta Experiencia del equipo en la metodología de desarrollo

Forma de adquirir la experiencia por desarrollador. Ubicarla en

Nominal a) La obtenida en una institución educativa

Capítulo 4

- 40 -

alguna de las alternativas.

b) Obtenida en la industria c) Obtenida de manera independiente

Experiencia en años en el desarrollo de software.

Absoluta Experiencia del equipo en el dominio del proyecto

Forma de adquirir la experiencia por desarrollador. Ubicarla en alguna de las alternativas.

Nominal a) La obtenida en una institución educativa b) Obtenida en la industria c) Obtenida de manera independiente

Experiencia del equipo en el uso de las herramientas de soporte

Ubicar la experiencia en el uso de las herramientas de soporte en alguna de las alternativas.

Ordinal a) Ninguna b) Baja c) Media d) Alta e) Muy alta f)

Nota: para el caso de las experiencias consideradas dentro de los factores sociológicos, para obtener la experiencia del equipo se requiere la experiencia y la forma de adquirirla por cada integrante del equipo. La experiencia, se definió a partir de 2 aspectos: el promedio de años del equipo en el desarrollo de software y la forma en que se adquirió la experiencia, para este aspecto se toma en cuenta la medida de tendencia central moda (ver anexo C) 4.2.2.4 Factores del ambiente de ingeniería de software En estos factores se incluyen atributos relacionados al hardware y software utilizado en un esfuerzo de ingeniería. Entre los elementos identificados en este ámbito se encuentran las herramientas de soporte, el sistema operativo en el que correrá la aplicación, entre otras [4], las características consideradas son:

Dominio de aplicación

Lenguajes de programación

Herramientas de soporte

Manejador de base de datos

Tipo de máquina donde se utilizará el sistema

Sistema operativo en el que se ejecutará el sistema En la tabla 4.5 se muestra la definición de las medidas correspondientes a los factores

del ambiente de ingeniería. En esta tabla se indica por cada atributo, criterio para la asignación del valor, el tipo de escala y las posibles opciones que puede tomar dicho atributo. Por ejemplo, en el dominio de aplicación es necesario indicar el nombre del dominio en donde se aplica el proyecto, por lo que su escala es nominal y las posibles opciones que se tienen son: web, médico, finanzas y ventas.

Capítulo 4

- 41 -

Tabla 4.5. Definición de medidas para los factores del ambiente de ingeniería

Atributo Criterio para la asignación del valor

Tipo de escala Posibles opciones

Dominio de aplicación

Nombre del dominio en donde se aplica el proyecto

Nominal Web, medico, ventas, finanzas.

Lenguaje de programación

Nombre del lenguaje de programación principal

Nominal Java, C++, C, C#, Clipper, Cobol, JavaScript, Visual Basic, Pascal, Cobol, Delphi, otro.

Otros lenguajes

Nombres de los lenguajes de programación utilizados en la aplicación

Nominal Java, C++, C, C#, Clipper, Cobol, JavaScript, Visual Basic, Pascal, Cobol, Delphi, otro.

Herramientas de soporte

Nombre de las herramientas de planificación y modelado

Nominal Rational Rose, Microsoft Office Visio, Together, Microsoft Office Project.

Manejador de base de datos

Nombre del manejador Nominal Access, Informix, MySQL, Oracle, PostgreSQL, SQL Server, Sybase, Otro.

Sistema operativo

Nombre del sistema operativo en el que correrá la aplicación.

Nominal Apple / Macintosh, Linux, Microsoft Windows, Unix, otro.

Tipo de máquina

Nombre del tipo de máquina en la que se utilizará la aplicación.

Nominal Mainframe, Mini computadora, PC, otro.

4.2.2.5 Factores configurables Los factores configurables son aquellos aspectos que se pueden cambiar en función de los resultados de proyectos previos y de los valores de los factores del nuevo proyecto. Se requieren recolectar para analizar y tomar decisiones en el desarrollo de un software. Los factores configurables identificados son [15]:

1. Conjunto de resultados a obtener 2. Estructura general del producto de software 3. Conjunto de subprocesos 4. Estructura del equipo de trabajo 5. Forma de realizar el desarrollo 6. Forma de realizar el seguimiento y control del proceso 7. Forma de realizar inspecciones

A continuación se explica los factores configurables. 1. El conjunto de resultados a obtener (cada uno construido mediante un proceso especifico,

tipo Team Software Process). El conjunto de resultados está compuesto por los productos del trabajo creados en el desarrollo de un sistema.

Un producto o artefacto es un trozo de información que se produce, modifica o se usa

durante el proceso de desarrollo de software. Los productos son los resultados tangibles

Capítulo 4

- 42 -

del proyecto, que se van creando y usando hasta obtener el producto final. En MoProSoft2 (Modelo de Procesos para la industria de Software) el producto de software se define como el producto que se genera en el proceso de desarrollo y mantenimiento del software [41]. Un producto puede ser cualquiera de los siguientes:

Un documento, como el documento de la arquitectura del software.

Un modelo, como el modelo de Casos de Uso o el modelo de diseño.

Un elemento del modelo, como una clase, un Caso de Uso o un subsistema. En el enfoque de MDA (Model Driven Architecture, por sus siglas en ingles) un

producto es un modelo [6]. Los modelos se dividen en:

Modelos Independientes de Computación (CIM). Son modelos de alto nivel de abstracción que identifican el contexto del sistema.

Modelos Independientes de Plataforma (PIM). Proporcionan la especificación formal de la estructura y función del sistema, sin tener en cuenta aspectos de la plataforma tecnológica a utilizar.

Modelo de Plataforma Específica (PSM). Proporcionan modelos en términos de constructores de implementación que están disponibles en una tecnología específica.

El AGD utiliza, en la categoría de ingeniería, un conjunto de productos del trabajo con

los conceptos de los modelos de MDA y los complementa con los modelos:

Modelo de implementación (IM). Abarca los elementos requeridos para ejecutar la aplicación como son código fuente, código objeto, código ejecutable, librerías y servicios.

Modelos Operacionales (OM). Representa el contexto en el que el sistema va a operar.

En la figura 4.3 se muestra el conjunto resultado de productos del trabajo, en donde se

muestran los productos clasificado por modelo.

2 Moprosoft. Norma mexicana, promovida por la secretaría de economía

Capítulo 4

- 43 -

Figura 4.3. Documentos del conjunto de resultados

2. La estructura general del producto de software, relacionada con los componentes de la arquitectura del software. En el estándar IEEE 1220-1998 (Standard for Application and Management of the Systems Engineering Process) [42] se menciona que un sistema está típicamente compuesto de elementos relacionados y sus interfaces. En la figura 4.4 se muestra la jerarquía de nombres para los elementos que integran un sistema, esta jerarquía del sistema es un concepto importante, en diferentes niveles de abstracción de este estándar.

CIM

PIM

IM

OM

PSM

- Planificación - Negocio existente - Identificación de componentes - Requerimientos y prototipo del sistema -Prototipo del sistema -Revisión/inspección de requerimientos y prototipo del sistema

- Ingeniería inversa - Ingeniería directa - Prototipo del software - Revisión/inspección de prototipo - Requerimientos del software y especificación de pruebas de aceptación - Revisión/inspección de requerimientos del sistema

- Restricciones a requerimientos - Arquitectura del software (diseño de alto nivel) y especificación

de pruebas de integración - Revisión/inspección de la arquitectura de software

- Diseño detallado y especificación de pruebas de unidad - Revisión/ inspección del diseño detallado - Codificación - Revisión/ inspección de código - Pruebas de unidad - Integración y pruebas de integración

- Identificación de recursos - Distribución del producto - Pruebas de aceptación - Evaluación

Conjunto resultado

Capítulo 4

- 44 -

Producto

Subsistema

Sistema

Ensambles

Sub-ensambles

Componentes

Sub-componentes

Partes

Partes

Sub-componentes

Producto

Subsistema

Sistema

Ensambles

Sub-ensambles

Componentes

Sub-componentes

Partes

Partes

Sub-componentes

Figura 4.4. Jerarquía de elementos en un sistema [42]

Para la estructura del producto el método AGD propone definir patrones para la

estructura general del sistema tomando en cuenta las condiciones del problema, el contexto en que funcionará el producto y la experiencia en el desarrollo.

En la tabla 4.6 se muestran 5 patrones para la estructura del sistema establecidos en

el ambiente AGDE, donde la estructura se ve como un conjunto de niveles ensamble-parte. El patrón S1 corresponde al patrón de estructura más simple, está compuesto sólo por elementos tipo objeto. En cuanto al patrón S5 es la estructura mayor y se trata de una estructura que incluye: sistema, productos, componentes, módulos y objetos.

Tabla 4.6. Patrones de la estructura de sistemas

Patrón Ensamble/Parte

S1 S2 S3 S4 S5

Sistema * Producto * * Componente * * * Módulo * * * * Objeto * * * * *

Los elementos incluidos en esta estructura son: sistema, producto, componente,

módulo y objeto (ver figura 4.5), su estructura se ve como un conjunto de niveles ensamble-parte, donde un ensamble sistema está conformado por varias partes producto, los ensambles producto se forman por varias partes componente, los ensambles componente están formados por varias partes módulo y los ensamble módulo consisten de varias partes objeto.

Capítulo 4

- 45 -

Figura 4.5. Estructura general de un sistema (ensamble/parte)

3. El conjunto de subprocesos a realizar para obtener cada producto (conjunto resultado). El

método AGD aporta una simplificación para obtener cualquier producto del trabajo mediante un conjunto único de subprocesos, adaptable a las circunstancias. Se sugiere un patrón por defecto (ver figura 4.6) que se utilizará para obtener cualquier producto asociado a un ensamble/parte. Este patrón de proceso considera fijos únicamente los subprocesos de Lanzamiento & Estrategia y Postmortem (que corresponden al primer y último subproceso), los 5 subprocesos intermedios pueden realizarse en el orden que se requiera, efectuando todos o justificando si se omiten.

Figura 4.6. Patrón de subprocesos [20]

Sistema

Producto 1 Producto 2 Producto N

Componente 1 Componente N Componente N

Módulo 1 Módulo N

Objeto 1

1 Nivel

2 Nivel

3 Nivel

4 Nivel

Nivel es de Ensamble /parte

Capítulo 4

- 46 -

4. La estructura del equipo de trabajo se describe como el número de participantes y roles. La conformación de equipo es uno de los requisitos de la mayor parte de los proyectos de ingeniería. Aunque ciertos proyectos pequeños pueden ser realizados en forma individual, la complejidad de los sistemas actuales y la demanda de entrega a corto plazo, provocan que ya no sea práctico, para una sola persona, encargarse de proyectos de software.

AGD establece el trabajo en grupo como característica primordial del desarrollo de

software y en particular propone organizar la realización en equipo en forma semejante al Team Software Process (TSP). Con los roles siguientes: 1)Miembro del equipo, 2) Líder del Equipo, 3) Administrador de planeación, 4) Administrador de soporte, 5) Administrador de desarrollo y 6) Administrador de calidad/proceso.

Un elemento importante, en el trabajo en equipo, es la importancia que le da a crear

un equipo de desarrollo efectivo, determinando y definiendo de manera clara los roles de los integrantes del equipo. Las funciones de los roles son los siguientes [43]:

Líder del equipo. Guía al equipo y se asegura de que los miembros del equipo reporten las estadísticas de avance y que se complete el trabajo.

Administrador de desarrollo. Dirige al equipo en utilizar correctamente y de acuerdo a estándares las técnicas de diseño y desarrollo del producto.

Administrador de planeación. Es el responsable de generar el plan que permita dar seguimiento al producto,

Administrador de procesos y calidad. Ayudará al equipo en la definición de los procesos necesarios para la realización del sistema y en el establecimiento y administración de planes de calidad, integrando y valorando los planes individuales, de los miembros del equipo

Encargado de soporte. Ayuda al equipo a determinar, obtener y administrar las herramientas necesarias para el desarrollo del software.

5. La forma de realizar el desarrollo (en colaboración o individualmente), de cada producto

del trabajo.

Cuando se utiliza AGD hay flexibilidad en la ejecución de los subprocesos, ya que para cada producto se determina el orden y recursos a utilizar durante el primer subproceso (lanzamiento & estrategia), como se explicó en el 3er. factor configurable. Las asignaciones de trabajo durante los subprocesos se realizan en modo de trabajo colaborativo3 y cuando se requiere de proceso individual, éste se estima como un caso especial del modo colaborativo.

6. La forma de realizar el seguimiento y control del proceso (periodicidad de reuniones, protocolo de reuniones, resultados a obtener). Las reuniones de seguimiento del estado

3 En el desarrollo colaborativo la responsabilidad la comparten varios actores, representando alternativamente el rol de conductor, quien toma las decisiones mientras realiza las tareas requeridas para obtener el producto del trabajo objetivo.

Capítulo 4

- 47 -

del proyecto se realizan en modo de control. Estas reuniones se pueden programar periódicamente en un día y a una hora específica de cada semana.

La participación del administrador del proyecto es muy importante en algunas de las

reuniones de control del avance del proceso, sobre todo al inicio del mismo cuando se define el problema a resolver, la estructura del equipo, así como los lineamientos y forma de trabajo requeridos.

7. La forma de realizar inspecciones (revisiones técnicas formales) y su relación con el

producto y los eventos del proceso. La inspección es una técnica estática del análisis que confía en el examen visual de los productos del desarrollo para detectar defectos, violaciones de los estándares del desarrollo y otros problemas. Existen varios tipos que incluyen entre otras a la inspección de código e inspección de diseño [5].

En la tabla 4.7 se muestra la definición de las medidas de los factores configurables. En

esta tabla se indica por cada atributo, criterio para la asignación del valor, el tipo de escala y las posibles opciones que puede tomar dicho atributo. Por ejemplo, para el conjunto de resultados, se tiene que es necesario indicar los nombres de los elementos del conjunto resultado, por lo que su escala es nominal, las posibles opciones establecidas son las expuestas en la figura 4.3, en donde se enlista un conjunto de productos.

Tabla 4.7. Definición de medidas para factores configurables [20]

Atributo Criterio para la asignación del valor

Tipo de escala Posibles opciones

Conjunto de resultados Nombres de los elementos del conjunto resultado .

Nominal Producto del trabajo (Figura 4.3)

Estructura general del producto del software

Identificar uno de los patrones de estructura del sistema.

Nominal Ensambles/Parte (figura 4.5)

Conjunto de subprocesos

Identificar el subproceso general implementado en el desarrollo del sistema.

Nominal Subprocesos (Figura 4.6)

Número de personas que integran el equipo de desarrollo.

Absoluto Estructura del equipo de trabajo

Identificar para cada desarrollador el rol que desempeñó.

Nominal a) Miembro del equipo b) Líder del Equipo c) Administrador de planeación d) Administrador de soporte e) Administrador de desarrollo f) Administrador de

calidad/proceso g) Otro.

Forma de realizar el desarrollo

Identificar la forma en que realizó el desarrollo del proyecto.

Nominal En colaboración o individual.

Seguimiento y control del proceso

Periodicidad de las reuniones de seguimiento.

Cada dia, 1 reunión cada semana, 1 cada 15 dias, 1 cada mes, 1 cada 2 meses, mas de 2 meses entre

Capítulo 4

- 48 -

reuniones, otro.

Identificar el tipo de inspecciones que se realizaron.

Nominal Revisión técnica formal o informal. Inspecciones

Tiempo invertido y el número de defectos detectado.

Absoluto

Los factores configurables corresponden a aspectos que pueden ser establecidos en

base a las características del proyecto a desarrollar y de la experiencia adquirida en otros proyectos.

4.3 Diseño de la base de datos para proyectos de software

Una vez establecido el marco de características de los proyectos, se procedió a diseñar una base de datos para el almacenamiento de la información del desarrollo, esta base de datos se utilizará en una investigación posterior para identificar patrones de proyectos (ver sección 4.3).

Durante el diseño de la base de datos, se analizó el riesgo de no contar con toda la

información histórica del desarrollo de proyectos de software, descrita en el MCPS, por lo que se establecieron niveles de detalle para hacer flexible la captura de la información, en donde se definieron los siguientes:

- 1er. Nivel de detalle: la información de los factores de valoración (sin valores

estimados) se captura sólo a nivel de producto de software (producto final). Donde un producto de software se define como un conjunto de programas de computadora, procedimientos, documentación asociada e información para el usuario [5]. La arquitectura del producto es ingresada de manera general, sin especificar las características de cada elemento de la arquitectura. El conjunto de productos del trabajo es establecido sólo para el componente principal de la arquitectura (el de mayor jerarquía).

- 2do. Nivel de detalle: en este nivel, además de proporcionar los factores de

valoración reales, también es necesario ingresar los valores estimados. Este aspecto es lo que diferencia el nivel 1 y 2.

- 3er. Nivel de detalle: en este nivel, la información cubre todos los atributos definidos

en el marco de características, se ingresa la información del producto de software y de los productos del trabajo de manera detallada, se indica el conjunto de productos del trabajo por cada elemento de la arquitectura del producto de software y para cada producto del trabajo se establecen sus subprocesos y tamaños estimados y reales.

En la tabla 4.8 se muestra en las 2 primeras columnas los elementos del marco de

características de proyectos de software, indicando con un “*” en las 3 ultimas columnas, los niveles de detalle en que su captura es forzosa.

Capítulo 4

- 49 -

Tabla 4.8. Elementos del marco de características y los niveles de detalle. Niveles de

detalle Conjunto de factores Atributo

1er. 2do. 3er.Naturaleza del proyecto * * * Contexto del proyecto * * * Clasificación del software * * * Criticidad del software * * *

Factores que identifican al tipo de proyecto y producto de software

Riesgos del proyecto * * * Unidad de medida del tamaño. * * * Elementos totales * * * Elementos base * Elementos borrados * Elementos modificados * Elementos reutilizados * Puntos de función * * * Complejidad de programación * * * Complejidad de los datos * * * Tiempo de duración estimado * * Tiempo de duración real * * * Defectos inyectados * Defectos removidos * Costo Estimado * *

Factores de valoración

Costo Real * * Nivel de educación * * * Experiencias del equipo

Factores sociológicos

- Desarrollo de software - Lenguaje de programación - Método - Dominio del proyecto - Herramientas de soporte

* * *

Dominio de aplicación * * * Lenguajes de programación * * * Herramientas de soporte * * * Manejador de base datos * * * Sistema operativo en el que correrá el sistema * * *

Factores del ambiente de ingeniería

Tipo de máquina donde se usará el sistema. * * * Conjunto de productos del trabajo del producto de software (producto final) * * *

Estructura del producto de software * * * Estructura de los productos del trabajo * Conjunto de productos del trabajo por elemento de la estructura *

Conjunto de subprocesos para el producto de software * * * Conjunto de subprocesos para cada producto del trabajo * Estructura del equipo de desarrollo (roles) * * * Periodicidad de reuniones de seguimiento * * * Número de inspecciones * Tiempo en inspecciones * Método de desarrollo * * *

Factores configurables

Modelo de proceso * * *

Capítulo 4

- 50 -

El marco de características de proyectos se utilizó como base para la organización de la base de datos historialproyectos, cuyo modelo relacional se muestra en la figura 4.7.

Figura 4.7. Modelo relacional de la base de datos historialproyectos

Capítulo 4

- 51 -

En el modelo de la base de datos se tiene un total de 16 tablas, la tabla principal es Proyecto, a la que se relacionan las demás tablas.

A un proyecto se le asocia: el producto de software ó producto final con sus

características como tamaño, complejidad, clasificación, entre otras; los riegos, en donde se parte de un catálogo para su clasificación por tipo de riesgo, para cada riesgo identificado en el proyecto se le asigna la probabilidad de que ocurra y la clasificación de impacto; el ambiente de ingeniería, en donde los campos corresponden a información de domino, herramientas de soporte y del lenguaje de programación en el que se desarrolló el producto de software; la asignación de roles, en donde en cada proyecto se puede tener varias asignaciones de roles, para esto se requiere establecer el identificador del desarrollador y el identificador del rol que desempeñó, se considera que una persona puede desempeñar diversos roles, así como un rol puede ser representado por varias personas.

El producto de software se considera como el producto final del desarrollo y se le

relaciona con las inspecciones y los detalles de líneas de código por tipo. El producto de software está compuesto por una o más componentes, donde los componentes son parte de su arquitectura, a cada componente se le asocia uno o más productos del trabajo (modelo, programa, documento, etc.).

Para cada producto de trabajo se tienen los campos de tiempo de desarrollo, defectos

inyectados y removidos. Se parte de que el trabajo se realiza por equipos de desarrolladores que iteran continuamente los subprocesos: lanzamiento & estrategia, planificación, requerimientos, análisis & diseño, implementación, prueba y pos-término (algún subproceso con mas o menos elementos), para cada producto del trabajo, de tal manera que el producto se obtiene incrementalmente.

En este capítulo se presentó la estructura del marco de características de proyectos de

software, con el fin de diseñar una base de datos para mantener información histórica del desarrollo de proyectos.

La posibilidad de almacenar y disponer de los datos históricos necesarios permitirá

utilizarlos para lograr un trabajo más predecible y eficiente e identificar patrones de proyecto.

- 52 -

Capítulo 5: Demostración En este capítulo se describe el proceso de demostración, que permitió verificar que con la estructura de la información basada en el Marco de Características de Proyectos de Software (MCPS), propuesto en esta investigación, se pueden almacenar de manera suficiente los datos requeridos para determinar la similitud entre los proyectos almacenados. Para este fin, se utilizaron los subconjuntos del marco de características (conformados por: factores de valoración, del ambiente de ingeniería, sociológicos y los que identifican el tipo de proyecto y al producto de software), sin incluir los factores configurables.

El capítulo está organizado de la siguiente manera: se presenta una descripción del proceso seguido para la demostración, las actividades realizadas, la comparación de proyectos de software y por último la discusión de resultados.

La actividad de comparación que permitió obtener la similitud entre los proyectos

recolectados, se realizó aplicando el algoritmo de clustering (agrupamiento) K-means [13] y algunas medidas de distancia como la Euclidiana y la Manhattan.

Clustering [28] es una técnica que agrupa datos en clases (clusters) de tal forma que los

objetos de un cluster tengan una similitud alta entre ellos y baja con objetos de otras cluster. El análisis de cluster es una técnica de análisis de datos, ampliamente utilizada en

distintas áreas de conocimiento, con el propósito de identificar objetos similares a partir de las características que poseen. Por ejemplo para el caso de un proyecto de software, se pueden considerar características como tamaño, complejidad, tipo de software y plataforma, entre otras.

Capítulo 5

- 53 -

5.1 Proceso de demostración El proceso de demostración consistió en la ejecución de las actividades incluidas en el paso 1 del Procedimiento general para Identificar Patrones de Proyectos (PIPP), presentado en el capítulo 4, sección 4.1, las cuales consisten en la comparación de los proyectos de software disponibles en la base de datos para obtener conjuntos de proyectos similares, estas actividades corresponden a:

1) Ingresar la información de proyectos desarrollados en la base de datos

"historialproyectos". 2) Obtener conjuntos de proyectos similares, considerando las características

incluidas en los factores: que indican el tipo de proyecto, de producto de software, de valoración y del ambiente de ingeniería.

3) Obtener la similitud de cada par de proyecto.

4) Actualizar los conjuntos, excluyendo los proyectos con similitud < 0.80. Se tomó

una similitud > = 0.80 como requisito para considerar los proyectos como similares en el paso 2 del procedimiento PIPP.

Para cubrir estas actividades se procedió a recolectar la información del desarrollo de proyectos de software, se visitaron a 2 instituciones: la Gerencia de Análisis de Redes del Instituto de Investigaciones Eléctricas, en donde existen varios equipos de trabajo, quienes desarrollan diferentes tipos de proyectos: sistemas con base de datos, aplicaciones Web, aplicaciones de escritorio y de administración, entre otros; y la empresa Morelos Web, que desarrolla productos de los tipos siguientes: aplicaciones de comercio electrónico, así como páginas y aplicaciones Web. Una vez recolectada la información se procedió a identificar el nivel de detalle de cada proyecto, en relación a los niveles establecidos en el marco de características (ver capítulo, sección 4.3), esto con el fin de aplicar el algoritmo K-means sobre la información disponible.

La aplicación del algoritmo K-means permitió agrupar los proyectos con mayor similitud (conjuntos de proyectos similares) tomando en cuanto a la distancia Euclidiana entre los proyectos. Una vez agrupados los proyectos se procedió a obtener el grado de similitud por cada par de proyecto incluido en el mismo grupo, mediante la distancia Manhattan y la función Delta. Se utilizaron estas dos medidas de distancia debido a que la información de los proyectos corresponde a datos mixtos (nominales y numéricos) y se requiere aplicar la medida de distancia de acuerdo al tipo de datos.

En la sección 5.2 se describen las actividades realizadas en el proceso de demostración,

las cuales cubren las actividades del paso 1 del procedimiento PIPP.

5.1.1 Objetivo

El objetivo de la demostración es verificar que con la estructura de la información basada en el marco de características de proyectos propuesto, es posible almacenar los datos de proyectos de software y que estos son suficientes para realizar manualmente las

Capítulo 5

- 54 -

comparaciones entre los proyectos almacenados, para determinar el grado de semejanza existente. 5.1.2 Alcance En este proceso de demostración se considera que se ha cumplido el objetivo, cuando la información del proyecto en cuestión sea almacenada en la base de datos, siguiendo la estructura del marco de características y se utilice en el proceso de comparación, determinándose el grado de similitud con una certidumbre de valor predeterminado.

El número de proyectos con los que se realizó la comparación para identificar la similitud

entre proyectos, se limitó a los casos disponibles en la investigación de campo realizada en este trabajo de investigación (3 proyectos recolectados en la Gerencia de Análisis de Redes del Instituto de Investigaciones Eléctricas (IIE) y 2 en la empresa Morelos Web).

Las características, de los proyectos, consideradas en el proceso de comparación,

corresponden a un subconjunto de los factores, que conforman el marco de proyectos descrito en el capítulo 4, sección 4.2.

Para obtener la comparación de los proyectos, se realizó una investigación acerca de

medidas de similitud, pero no se realizó un análisis profundo sobre todo lo que implica obtener la semejanza entre objetos y la identificación del método óptimo para la comparación, pues no es parte del objetivo de esta investigación.

Para la demostración se requirió desarrollar un prototipo para la interfaz de captura de la

información de proyectos, con la finalidad de proporcionar facilidad de captura y la creación de la base de datos de los proyectos recolectados.

Para el diseño del prototipo se consideró el riesgo de no contar con la información

histórica completa del desarrollo de proyectos de software, descrita en el marco de características. Con esto en mente el diseño se realizó en base a los niveles de detalle establecidos en el marco de características (ver capítulo 4, sección 4.2) y de esta manera hacer flexible la captura de información. 5.2 Actividades realizadas en el proceso de demostración En esta sección se presentan las actividades realizadas en el proceso de demostración, describiendo: los recursos que se utilizaron y la plataforma en donde se elaboró la interfaz de captura para la información del desarrollo de proyectos; se muestran también los casos considerados para la actividad de comparación; y el análisis de la comparación de proyectos, utilizando la técnica de clustering. 5.2.1 Desarrollo de la forma de captura para la información de proyectos En esta actividad se desarrolló un prototipo para la captura de la información histórica del desarrollo de proyectos de software y su almacenaje en una base de datos para analizarla y compararla.

Capítulo 5

- 55 -

La organización de la información del prototipo está basada en el marco de características de proyectos de software propuesto en esta investigación.

La interfaz de captura está dividida en 7 secciones que se enfocan a diferentes aspectos

del desarrollo de un proyecto de software, como son: las características que identifican el tipo de proyecto, las características del producto de software, el ambiente de ingeniería de software, la información sobre el equipo de desarrolladores, los riegos que se presentaron en el proyecto, los elementos de la arquitectura del software y el conjunto de productos del trabajo. Además, se cuenta con un menú donde se administra la información de catálogos establecidos para el ingreso de la información de: riesgos, productos del trabajo, roles, subprocesos y de ensambles/partes (elementos de la estructura del producto de software). 5.2.1.1 Software utilizado El prototipo es una aplicación desarrollada en Java 1.5 que accede a una base de datos implementada en PostgreSQL 8.2 con el nombre de “historialproyectos”, en el anexo A se muestra el código SQL de la base de datos. Esta base de datos fue diseñada en base a los atributos descritos en el marco de características, mostrado en el capítulo 4, sección. 4.2.

Para realizar la conexión entre la aplicación y el manejador de la base de datos se utilizó JDBC.

JDBC es un API (Application Programming Interface) para ejecutar sentencias SQL

(Structured Query Language), que ofrece una interfaz estándar para el acceso a bases de datos. Permite establecer una conexión con una base de datos, enviar sentencias SQL y procesar los resultados. JDBC también consta de drivers que son los que permiten la conexión de una aplicación en java con una base de datos determinada.

Los programas utilizados para el desarrollo del prototipo son:

- La máquina virtual de java J2SE versión 1.5.0_03-b07 [44] - PostgreSQL 8.2 [45]

Con el usuario: CREATE USER Usuario WITH SUPERUSER PASSWORD 'cenidet2005'.

- El driver postgresql-8.0-319.jdbc3 [46][47].

5.2.1.2 Estructura de la interfaz La interfaz del prototipo está organizada en 2 menús principales 1) “Proyecto” en donde se puede acceder a los submenús “Registro” y “Actualización”. Mediante éstos, se lleva el registro y actualización de la información de los proyectos; 2) “Catálogos” en este menú se tienen las opciones de administrar la información de roles, riesgos, subprocesos, ensambles/partes, componentes y de productos del trabajo. En la figura 5.1 se muestra el esquema de la interfaz del prototipo. La descripción de las ventanas del prototipo se muestra en el Anexo B.

Capítulo 5

- 56 -

Figura 5.1. Esquema de la interfaz del prototipo “Historial de proyectos”

5.2.2 Determinar los casos de proyectos a almacenar Los casos de proyectos que se tomaron en cuenta para el proceso de demostración fueron aquellos proyectos terminados y con la información suficiente para satisfacer algún nivel de detalle establecido para el marco de características (Nivel de detalle 1, 2 y 3). 5.2.3 Recolección de información de proyectos de software Para la recolección de la información de los proyectos se procedió a visitar a las instituciones mencionadas anteriormente, en donde se les informó de la finalidad de la investigación y del tipo de información que se requería almacenar.

Prototipo Historial de Proyectos

Proyecto Catálogos

Registro

Actualización

Salir

Características generales del proyecto

Características del producto de software

Riesgos del proyecto

Ambiente de ingeniería de software

Desarrolladores

Arquitectura de software

Productos del trabajo

Modificar información

Dar de baja

Roles

Riesgos

Subproceso

Productos del trabajo

Ensambles/Partes

Componentes

Productos del trabajo

Ayuda

Contenido

Capítulo 5

- 57 -

Se recolectaron 5 proyectos con el 1er. nivel de detalle, en este nivel se carece de la totalidad de los atributos identificados en el marco, principalmente de los valores estimados. El proceso de comparación se aplicó sobre la información de los proyectos mostrados en tabla 5.1.

Tabla 5.1. Datos de los proyectos recolectados

Identificador Nombre del proyecto Fuente Pro001 Apoyo a la GPSE (Gerencia de Programación de Sistemas

Eléctricos) en el desarrollo de los módulos de evaluación de proyectos y formación de paquetes.

IIE

Pro002 Especificación del sistema de estadística del Cenace (Centro Nacional de Control de Energía).

IIE

Pro003 Desarrollo del módulo de carga para el sistema estadístico. IIE Pro004 Página web para el control de renta de bodegas privadas. Morelos Web Pro005 Desarrollo de una aplicación de Comercio electrónico. Morelos Web

Se tiene la información de un sexto proyecto que aún no ha sido terminado, pero que

presenta un nivel de detalle 3, es decir su información cubriría todos los atributos establecidos en el marco de características, pero no puede incluirse en el proceso de demostración porque no se tiene completa la información. En este proyecto se carece de los valores reales de los factores de valoración, además de sólo contar con la información de un componente de la estructura del producto final. 5.2.4 Descripción de la actividad de comparación de proyectos El objetivo de esta actividad es comparar los proyectos almacenados en la base de datos, para determinar la similitud entre ellos, para lo cual se presentará por cada par de proyectos, el grado de similitud en un rango de 0-1. Este valor mientras más se acerque a 1, más similares son los proyectos.

La comparación se realizó utilizando clustering y medidas de distancia. La técnica de

clustering permite clasificar los objetos o casos en grupos homogéneos llamados clusters, sin tener clases predefinidas [13]. Esta técnica se basa en maximizar la similitud de las instancias en cada cluster y minimizar la similitud entre clusters, asegurando que los objetos dentro de cada grupo, sean similares entre sí (alta homogeneidad interna) y diferentes a los objetos de otros clusters (alta heterogeneidad externa).

Para esta demostración, se optó por experimentar con el algoritmo K-means para

agrupar los proyectos, el cual es uno de los algoritmos más utilizados para hacer clustering y que se caracteriza por su sencillez. Sin embargo este proceso de agrupamiento no proporciona el grado de similitud entre los miembros del mismo grupo.

Para obtener el grado de similitud entre los proyectos del mismo grupo se aplicaron las

medidas de distancia: Manhattan para los atributos numéricos y la función delta para los atributos nominales, en el capítulo 2 se describen estas medidas.

Estas actividades se realizaron con el fin de proceder a obtener la comparación entre los

proyectos recolectados y analizar sus semejanzas. En la sección siguiente se muestra a detalle los pasos realizados para lograr la comparación de proyectos.

Capítulo 5

- 58 -

5.3 Comparación de proyectos de software En esta sección se presentan las actividades realizadas para la aplicación del algoritmo K-means, para la agrupación de proyectos similares y la aplicación de medidas de distancia para determinar el grado de similitud a partir de la agrupación obtenida al aplicar dicho algoritmo.

5.3.1 Selección de los atributos a considerar en el agrupamiento A partir del subconjunto de características disponibles se procedió a seleccionar las características que están directamente relacionadas al proyecto y producto, separando a las relacionadas con el proceso. En el anexo D se muestra los concentrados de la información de cada proyecto. Las características a las que se les aplicó el algoritmo de agrupamiento fueron: aquellas correspondientes a los atributos del conjunto de factores que indican el tipo de proyecto y de producto de software (tabla 5.2); a los atributos del conjunto de factores de valoración (tabla 5.3), excluyendo los valores estimados; y los atributos del ambiente de ingeniería (tabla 5.4).

Las tablas 5.2, 5.3, 5.4 están organizadas mediante las columnas: atributo, identificador y valor, por ejemplo, en el caso de la tabla 5.2, del atributo Naturaleza del proyecto, se tiene que su identificador es Naturaleza-proyecto y que su valor se obtiene mediante la aplicación regla de medición establecida en el marco de características.

La comparación de los proyectos se realizó con un conjunto de atributos, que excluyen

atributos que se relacionan con el desarrollo del proyecto. Excluyendo las características de equipo de desarrollo (factores sociológicos); y características del conjunto de productos del trabajo; estructura del producto (que son parte de los factores configurables).

Tabla 5.2. Atributos del conjunto de factores que indican el tipo de proyecto y producto de software.

Atributo Identificador(s) Valor Naturaleza del proyecto Naturaleza-proyecto Del marco de características. Contexto del proyecto contexto-proyecto Del marco de características. Clasificación del software

clasificación-software Del marco de características.

Criticidad del software Criticidad-software Del marco de características. total-riesgost, total-riesgosp total-riesgoso, total-riesgosh total-riesgosr, total-riesgose

Total de riesgos de cada tipo (tecnológico, personas, organizacionales, de herramientas, de requerimientos, de estimación).

probabilidad-riesgost probabilidad-riesgosp probabilidad-riesgoso probabilidad-riesgosh probabilidad-riesgosr probabilidad-riesgose

Moda de la probabilidad de los riesgos por tipo.

Riesgos del proyecto

Impacto-riesgost Impacto-riesgosp Impacto-riesgoso Impacto-riesgosh Impacto-riesgosr Impacto-riesgose

Moda del impacto de los riesgos por cada tipo.

Capítulo 5

- 59 -

Tabla 5.3. Atributos del conjunto de factores de valoración Atributo Identificador Valor Unidad de medida UnidadM Del marco de características. Puntos de función PF Cantidad total de puntos de función. Elementos totales ElementosT Cantidad total de elementos de acuerdo a la unidad de

medida establecida. Tiempo de desarrollo real TiempoR Tiempo en minutos de duración real en el desarrollo del

proyecto. Complejidad de los datos Complejidad Del marco de características.

Complejidad de programación

ComplejidadP Del marco de características.

Tabla 5.4. Atributos del conjunto de factores del ambiente de ingeniería

Atributo Identificador Valor Dominio de aplicación Dominio Del marco de características.

Lenguaje de programación LengProg

Ubicar la clase a la que corresponde el lenguaje [48]: a) Lenguajes dinámicos. Permiten el código y las estructuras lógicas en tiempo de ejecución. Con frecuencia son interpretados y generalmente comprueban el tipo en tiempo de ejecución. Ejemplos: PHP, Pitón, Javascript. b) Lenguajes estáticos. Tienen el código y las estructuras lógicas rígidas, son generalmente compilados y comprueban el tipo en tiempo de compilación. Ejemplos: Java, Visual Basic, C,C++.

Herramienta de planificación HerramientaPlan

Ubicar la herramienta en alguna de las siguientes opciones: a) Software-administración. La herramienta es un

software diseñado para la administración de proyectos.

b) Ninguna. c) Software-general. La herramienta no está

diseñada para la administración de proyectos.

Herramienta de programación HerramientaProg

Indicar si la herramienta se trata de un entorno de desarrollo integrado (IDE) o de una herramienta de uso general.

Herramienta de modelado HerramientaMod

Ubicar la herramienta en alguna de las siguientes opciones: a) Software-modelado. La herramienta es un

software diseñado para el modelado de sistemas. b) Ninguna. c) Software-general. La herramienta no está

diseñada para el modelado de sistemas. Manejador de base de datos MBD Del marco de características. Sistema operativo SO Del marco de características. Tipo de máquina TipoM Del marco de características. En la sección siguiente se describe la aplicación del algoritmo K-means para la

conformación de los grupos de proyectos, en donde se tomaron las características seleccionadas en esta sección.

Capítulo 5

- 60 -

5.3.2 Conformación de los grupos de proyectos

En este paso se aplicó el algoritmo de agrupamiento K-means disponible en la herramienta WEKA, para esto se creó un archivo con formato arff (Attribute-Relation File Format) con los atributos de los de factores elegidos (ver Anexo E). Un archivo con este formato, no sólo contiene los datos de donde se va a efectuar el aprendizaje, sino que además incluye meta-información acerca de los propios datos, como el nombre y tipo de cada atributo.

Una vez creado el archivo arff, con los datos del proyecto, se ingresa a WEKA en el área de pre-proceso, para posteriormente aplicar clustering. En la figura 5.2 se muestra el archivo arff cargado en WEKA. En esta figura se pueden observar detalles del conjunto de datos cargado desde el archivo arff. Por ejemplo, en esta sección de preproceso se indica que se tienen 5 registros con 36 atributos, también se indica la información de escala (nominal o numérico), valores distintos, valor máximo (sólo en atributos numéricos) y valor mínimo (sólo en atributos numéricos) de cada atributo, esto de acuerdo al atributo seleccionado.

Figura 5.2. Archivo arff cargado en WEKA

Para aplicar el algoritmo K-means, es necesario indicar el número de grupos que se

quieren formar, en este caso se eligió formar 2, porque coincidieron dos algoritmos de agrupación en formar 2 grupos de manera automática con los mismos datos. En la figura 5.3 se muestra el resultado de la agrupación, donde se observan las características de cada cluster. En la tabla 5.5, se muestra de una manera más resumida a cómo lo muestra WEKA. WEKA presenta la desviación estándar para cada atributo numérico en cada cluster, como se ve en la figura 5.3.

Capítulo 5

- 61 -

Figura 5.3. Resultado de la ejecución del algoritmo K-means.

En la tabla 5.5 se presentan los valores de promedio (atributo numérico) y moda (atributo

nominal) de los atributos por cada cluster, por ejemplo, en el atributo 1 correspondiente a la naturaleza-proyecto, se tiene que tanto en el cluster 0 como en el 1, se trata de un desarrollo de una nueva aplicación.

Tabla 5.5. Valor de los atributos por cluster

Valor del atributo No. Atributo Cluster 0 Cluster 1

1 naturaleza-proyecto Desarrollo de una nueva aplicación Desarrollo de una nueva aplicación 2 contexto-proyecto Aplicación de ventas Aplicación estadística 3 clasificación-software Sistema de información Sistema de información 4 criticidad-software Pérdida económica Criticidad sin efecto 5 total-riesgost 0 0 6 total-riesgosp 0 0 7 total-riesgoso 0 0 8 total-riesgosh 0 0 9 total-riesgosr 1 0.25

10 total-riesgose 0 1.25 11 probabilidad-riesgost Ninguno Ninguno 12 probabilidad-riesgosp Ninguno Ninguno 13 probabilidad-riesgoso Ninguno Ninguno 14 probabilidad-riesgosh Ninguno Ninguno 15 probabilidad-riesgosr Bajo Ninguno 16 probabilidad-riesgose Ninguno Moderada 17 impacto-riesgost Ninguno Ninguno 18 impacto-riesgosp Ninguno Ninguno 19 impacto-riesgoso Ninguno Ninguno

Capítulo 5

- 62 -

20 impacto-riesgosh Ninguno Ninguno 21 impacto-riesgosr Tolerable Ninguno 22 impacto-riesgose Ninguno Tolerable 23 Dominio Aplicación web Aplicación web 24 LengProg Dinámico Estático 25 HerramientaPlan Ninguna Software-administración 26 HerramientaProg IDE-Programación IDE-Programación 27 HerramientaMod Software-no-especializado Software-no-especializado 28 MBD No Si 29 SO Windows Windows 30 TipoM PC PC 31 UnidadM LOC LOC 32 PF 31 505 33 ElementosT 1225 78372 34 TiempoR 408 77985 35 Complejidad Baja Media 36 ComplejidadP Baja Media Los resultados que se obtuvieron al aplicar K-means para obtener grupos de proyectos

homogéneos, demuestran la similitud entre 4 proyectos, excluyendo sólo a 1. En la tabla 5.6 se muestra la conformación de los cluster (grupos) de proyectos, esto de acuerdo a la figura 5.4, en donde se visualiza a qué cluster pertenece cada proyecto, mediante el color de los puntos de la gráfica. La aplicación del algoritmo de Clustering en WEKA arrojó como resultado la agrupación de los proyectos con mayor semejanza, pero no proporciona explícitamente el grado de similitud entre los proyectos del mismo cluster.

Figura 5.4. Visualización de los clusters

Capítulo 5

- 63 -

Tabla 5.6. Conformación de los clusters Identificador Nombre del proyecto Fuente Cluster

Pro001 Apoyo a la GPSE (Gerencia de Programación de Sistemas Eléctricos) en el desarrollo de los módulos de evaluación de proyectos y formación de paquetes.

IIE Cluster 1

Pro002 Especificación del sistema de estadística del Cenace (Centro Nacional de Control de Energía).

IIE Cluster 1

Pro003 Desarrollo del módulo de carga para el sistema estadístico. IIE Cluster 1 Pro004 Página Web para el control de renta de bodegas privadas. Morelos Web Cluster 0 Pro005 Desarrollo de una aplicación de Comercio electrónico. Morelos Web Cluster 1

Una vez que se agruparon los proyectos recolectados, se procedió a calcular el grado de similitud entre los miembros del mismo grupo, en este caso sólo se tomó en cuenta el cluster1, porque el cluster 0 está constituido por un miembro y la comparación se realizó por pares de proyectos.

5.3.3 Cálculo del grado de similitud entre pares de proyectos

Para el cálculo de la similitud de los proyectos del cluster 1, que contiene 4 elementos, se tomó a la distancia como la función inversa de la medida de similitud. Para este cálculo se siguieron los siguientes pasos: 1) Clasificación de atributos 2) Normalización de los atributos numéricos 3) Cálculo de las distancias entre los elementos (por cluster). 4) Obtención de la similitud entre los proyectos del mismo grupo

A continuación se describe cada paso enlistado, los cuales se realizaron con el fin de obtener el grado se similitud entre los proyectos recolectados. 1) Clasificación de atributos Los atributos utilizados para la agrupación corresponden a datos mixtos (datos numéricos y nominales), por lo que se procedió a separar los atributos en nominales y numéricos, para aplicar medidas de distancias adecuadas a cada tipo. Para los datos nominales se aplicó la función delta y para los numéricos la función Manhattan.

En la tabla 5.7 se muestra el subconjunto de atributos de tipo numérico (por ejemplo

puntos de función, tiempo de desarrollo, etc.) y en la tabla 5.8 se muestran los de tipo nominal entre los que se encuentran la naturaleza y el contexto del proyecto.

Los atributos ordinales por su naturaleza se tomaron como numéricos, asignándoles un

número de manera ascendente a las posibles opciones de cada atributo, por ejemplo:

Probabilidad de los riesgos tecnológicos Ninguna = 0 Muy baja = 1 Baja = 2 Moderada =3

Capítulo 5

- 64 -

Alta = 4 Muy Alta = 5 Impacto de los riesgos Ninguno = 0 Insignificante = 1 Tolerable = 2 Serio = 3 Catastrófico = 4 Complejidad Baja = 1 Media = 2 Alta = 3

Tabla 5.7. Atributos numéricos

Atributo Pro001 Pro002 Pro003 Pro005

Riesgos tecnológicos 0 0 0 0

Riesgos de personas 0 0 0 0

Riesgos organizacionales 0 0 0 0

Riesgos de herramientas 0 0 0 0

Riesgos de requerimientos 0 1 0 0

Riesgos de estimación 1 1 2 1

Probabilidad de riesgos tecnológicos 0 0 0 0

Probabilidad de los riesgos de personas 0 0 0 0

Probabilidad de los riesgos organizacionales 0 0 0 0

Probabilidad de los riesgos de herramientas 0 0 0 0

Probabilidad de los riesgos de requerimientos 0 4 0 0

Probabilidad de los riesgos de estimación 3 5 2 1

Impacto de los riesgos tecnológicos 0 0 0 0

Impacto de los riesgos de personas 0 0 0 0

Impacto de los riesgos organizacionales 0 0 0 0

Impacto de los riesgos de herramientas 0 0 0 0

Impacto de los riesgos de requerimientos 0 2 0 0

Impacto de los riesgos de estimación 2 2 2 2

Puntos de función 453 574 683 218

Elementos totales 20,080 23,114 226,694 43,600

Tiempo de desarrollo real (Min) 66,480 74,100 123,360 48,000

Complejidad de los datos 3 2 2 1

Complejidad de programación 2 2 2 2

Capítulo 5

- 65 -

Tabla 5.8. Atributos nominales Atributo Pro001 Pro002 Pro003 Pro005

Naturaleza del proyecto

Desarrollo de una nueva aplicación

Desarrollo de una nueva aplicación

Proyecto de mantenimiento

Proyecto de mejora

Contexto del proyecto

Electrónica Estadístico Estadístico Comercio electrónico

Clasificación del software

Sistema de información

Sistema de información

Sistema de información

Sistema de información

Criticidad del software

Criticidad sin efecto Criticidad sin efecto Criticidad sin efecto Pérdida económica

Unidad de medida

LOC LOC LOC LOC

Dominio tecnológico

Procesamiento distribuido

Aplicación web Aplicación web Aplicación web

Lenguaje de programación

Estático Estático Estático Dinámico

Herramienta de planificación

Software-Administración

Software-Administración

Software-Administración

Software-Administración

Herramienta de programación

IDE-General IDE-Programación IDE-Programación IDE-Programación

Herramienta de modelado

Software-General Software-General Software-General Software-General

Manejador de base de datos

Informix Sql Server Oracle MySQL

Sistema operativo

Microsoft Windows Microsoft Windows Microsoft Windows Microsoft Windows

Tipo de máquina PC PC PC PC

2) Normalización de los atributos numéricos Como las medidas de distancia son sensibles a la diferencia de escalas o de magnitudes entre variables, es necesaria la normalización de datos para evitar que las variables con una gran dispersión tengan un mayor efecto en la similitud. Por ejemplo los atributos tamaño medido en líneas de código y número de desarrolladores, en el caso del tamaño, se puede presenta un proyecto con 1,000 líneas de código y el otro con 100,000 líneas, se tendrá una distancia considerablemente alta, pero en contraste, el número de desarrolladores tiene distancia mucho menor, pues es poco común tener valores excesivamente grandes y dispersos.

Para evitar que atributos con valores muy altos tengan mucho mayor peso que atributos

con valores bajos, se normalizarán los atributos numéricos presentados en la tabla 5.6 con la siguiente ecuación:

minmaxmin'−

−=

vv (5.1)

Donde:

`v es el valor normalizado del atributo v

Capítulo 5

- 66 -

v es el valor real del atributo min es el mínimo de los valores dados al atributo max es el máximo de los valores dados al atributo Para realizar esta normalización sólo es necesario conocer el máximo y el mínimo de los

valores dados para ese atributo, en la tabla 5.9 se muestran los atributos numéricos normalizados, con esto se tienen los valores de los atributos en un rango de 0 a 1.

Tabla 5.9. Atributos numéricos normalizados

Atributo Pro001 Pro002 Pro003 Pro005

Riesgos tecnológicos 0 0 0 0

Riesgos de personas 0 0 0 0

Riesgos organizacionales 0 0 0 0

Riesgos de herramientas 0 0 0 0

Riesgos de requerimientos 0 1 0 0

Riesgos de estimación 0 0 1 0

Probabilidad de riesgos tecnológicos 0 0 0 0

Probabilidad de los riesgos de personas 0 0 0 0Probabilidad de los riesgos organizacionales 0 0 0 0

Probabilidad de los riesgos de herramientas 0 0 0 0Probabilidad de los riesgos de requerimientos 0 1 0 0

Probabilidad de los riesgos de estimación 0.5 1 0.5 0

Impacto de los riesgos tecnológicos 0 0 0 0

Impacto de los riesgos de personas 0 0 0 0

Impacto de los riesgos organizacionales 0 0 0 0

Impacto de los riesgos de herramientas 0 0 0 0

Impacto de los riesgos de requerimientos 0 1 0 0

Impacto de los riesgos de estimación 1 1 1 1

Puntos de función 0.383378016 0.707774799 1 0

Elementos totales 0.869270066 0 1 0.100628745

Tiempo de desarrollo real (Min) 0.24522293 0.34633758 1 0

Complejidad de los datos 1 0.5 0.5 0

Complejidad de programación 1 1 1 1

3) Cálculo de las distancias entre los elementos (por cluster). En este punto se calculó solamente la distancia entre los proyectos del cluster 1, para obtener el grado de similitud entre cada par de proyectos, ya que el cluster 0 contiene un proyecto y no se requiere calcular la distancia.

En la tabla 5.10 se muestran los resultados de la aplicación de la distancia Manhattan a los atributos numéricos tomados de la tabla (5.8) y la normalización de esta distancia, ya que

Capítulo 5

- 67 -

se requiere obtenerla en el rango de 0 a 1. La normalización se obtuvo dividiendo entre el número total de atributos (numéricos + nominales), en donde se tiene un total de 36 atributos, de los cuales, 23 numéricos y 13 nominales, con esto se evita que la dispersión de los valores de los atributos influyan en el cálculo de la distancia. Para lo cual se aplicó la siguiente ecuación:

∑=

−=n

iii yxyxdNum

1),( (5.2)

Donde:

),( yxdNum es la distancia entre las instancias de proyecto (x, y)

ix es el atributo i de la instancia x

iy es el atributo i de la instancia y n es el número total de atributos de los proyectos

Tabla 5.10. Resultado de aplicar la distancia Manhattan

Proyectos comparados Distancia de Manhatan Distancia normalizada (1)

(Pro001-Pro002) 5.411403482 0.150316763 (Pro001-Pro003) 3.118750972 0.086631971 (Pro001-Pro005) 2.780620282 0.077239452 (Pro002-Pro003) 5.546516367 0.154069899 (Pro002-Pro005) 5.654741124 0.157076142 (Pro003-Pro005) 4.899371255 0.136093646

El resultado de aplicar la función delta a los atributos nominales se muestra en la tabla

5.11. El factor de reducción por el que se optó fue w =1/n, donde n = número total de atributos (numéricos y nominales). Con este factor las distancias se normalizaron en un rango de (0-1). Para lo cual se aplicó la siguiente ecuación:

∑=

=n

iii yxSwyxdNom

1),(),( (5.3)

Donde:

),( yxdNom es la distancia entre las instancias de proyectos (x, y)

ix es el atributo i de la instancia x

iy es el atributo i de la instancia y S( ix , iy )=0 si y sólo si ix = iy y S( ix , iy )=1 en caso contrario. n es el número total de atributos de los proyectos w es el factor de reducción 1/ n

Capítulo 5

- 68 -

Tabla 5.11. Resultado de aplicar las medidas de distancia a los atributos nominales

Proyectos a comparar Función delta (2)

(Pro001-Pro002) 0.11111111 (Pro001-Pro003) 0.11111111 (Pro001-Pro005) 0.19444444 (Pro002-Pro003) 0.05555555 (Pro002-Pro005) 0.13888888 (Pro003-Pro005) 0.13888888

Una vez que se obtuvieron las distancias por tipos de atributos, se procedió a sumar

estos dos resultados y así obtener las distancias entre los proyectos (d (x, y)) (ver tabla 5.12).

Tabla 5.12. Distancia de los proyectos

Proyectos a comparar d(x,y)= (1)+(2)

(Pro001-Pro002) 0.26142787 (Pro001-Pro003) 0.19450358 (Pro001-Pro005) 0.27492339 (Pro002-Pro003) 0.20962545 (Pro002-Pro005) 0.29596502 (Pro003-Pro005) 0.27498253

Las distancias entre cada par de proyectos, mostradas en la tabla 5.12, se utilizaron para

el cálculo de la similitud entre cada par de proyecto. Los resultados obtenidos muestran que los proyectos más distantes (más diferentes) son los proyectos Pro002 y Pro005.

4) Obtención de la similitud entre los proyectos del mismo grupo En este paso se procedió a obtener la similitud entre los proyectos tomando en cuenta la medida de distancia. Las medidas de distancia (disimilitud) corresponden al grado de diferencia o lejanía existente entre dos objetos: cuando dos objetos se encuentren juntos, la distancia es nula, en cambio la medida de similitud evalúa el grado de parecido o proximidad entre los elementos comparados: cuando dos elementos se encuentran juntos, el valor de la medida es el máximo.

Debido a que los valores de los atributos se encuentran normalizados entre [0,1], al presentarse una distancia cercana al 0, significa que presenta una similitud cercana 1 (alta similitud), en cambio si la distancia es cercana a 1, significa que la similitud es casi 0 (baja similitud), con lo que la similitud se puede obtener con la siguiente ecuación.

),(1),( yxdyxs −= (5.4)

Donde: s( x,y) es la similitud de las instancias x y y. d(x,y) es la distancia entre las instancias x y y.

Capítulo 5

- 69 -

En la tabla 5.13 se muestra que el grado de similitud entre los proyectos varia de (0.70 a 0.80), donde los proyectos Pro001 y Pro003 presentaron mayor semejanza, en tanto que el par de proyectos con menor similitud son el Pro002 y Pro005.

Tabla 5.13. Resultado del cálculo de similitud

Proyectos a comparar

Similitud= (1-Distancia)

(Pro001-Pro002) 0.74181163 (Pro001-Pro003) 0.80549642 (Pro001-Pro005) 0.72507661 (Pro002-Pro003) 0.79037455 (Pro002-Pro005) 0.70403498 (Pro003-Pro005) 0.72501747

Una vez calculada la similitud entre cada par de proyectos del cluster 1, se procedió a

comparar el proyecto del cluster 0 (Pro004) con el par de proyectos que presenta mas alta similitud del cluster 1 (Pro001 y Pro003), con el fin de constatar la similitud de estos proyectos.

Para realizar la comparación de estos proyectos, se siguieron los pasos realizados en la

comparación de los elementos del cluster 1. En la tabla 5.14, se muestran los datos reales y normalizados de los proyectos Pro001, Pro003 y Pro004, en la columna 1 se encuentran enlistados los atributos, en la columna 2, 3 y 4 se muestran los valores almacenados en la base de datos, mientras que en las columnas 5, 6 y 7 corresponden a los valores normalizados. Para normalizar los datos se utilizó la ecuación 5.1.

Tabla 5.14. Valores reales y normalizados de los atributos numéricos

Valores reales Valores normalizados Atributo

Pro001 Pro003 Pro004 Pro001 Pro003 Pro004

Riesgos tecnológicos 0 0 0 0 0 0 Riesgos de personas 0 0 0 0 0 0 Riesgos organizacionales 0 0 0 0 0 0 Riesgos de herramientas 0 0 0 0 0 0 Riesgos de requerimientos 0 0 1 0 0 1 Riesgos de estimación 1 2 0 0.5 1 0 Probabilidad de riesgos tecnológicos 0 0 0 0 0 0 Probabilidad de los riesgos de personas 0 0 0 0 0 0 Probabilidad de los riesgos organizacionales 0 0 0 0 0 0 Probabilidad de los riesgos de herramientas 0 0 0 0 0 0 Probabilidad de los riesgos de requerimientos 0 0 2 0 0 1 Probabilidad de los riesgos de estimación 3 2 0 1 0.666 0 Impacto de los riesgos tecnológicos 0 0 0 0 0 0 Impacto de los riesgos de personas 0 0 0 0 0 0 Impacto de los riesgos organizacionales 0 0 0 0 0 0 Impacto de los riesgos de herramientas 0 0 0 0 0 0 Impacto de los riesgos de requerimientos 0 0 2 0 0 1 Impacto de los riesgos de estimación 2 2 0 1 1 0 Puntos de función 453 683 31 0.6472 1 0

Capítulo 5

- 70 -

Elementos totales 20,080 226,694 1225 0.0832 1 0 Tiempo de desarrollo real (Min) 66,480 123,360 480 0.5371 1 0 Complejidad de los datos 3 2 1 1 0.5 0 Complejidad de programación 2 2 1 1 1 0

Una vez normalizados los datos numéricos se procedió a calcular su medida Manhattan,

utilizando la ecuación 5.2. Para los datos nominales se aplicó la función Delta (ecuación 5.3), en la tabla 5.15 se muestran los resultados de los cálculos de las distancias, así la similitud obtenida.

Tabla 5.15. Resultado de la comparación de los proyectos Pro004 y Pro005

Proyectos Comparados

Distancia Manhatan

Distancia Manhattan

normalizada (1)

Función delta

Función delta normalizada

(2)

d(x,y)= (1)+(2) Similitud= (1-d(x,y))

(Pro004-Pro001) 6.7675 0.1880 6 0.1666 0.3546 0.6454(Pro004-Pro003) 9.166 0.2546 6 0.1666 0.4212 0.5788 El resultado de la comparación del proyecto Pro004 con los proyectos Pro001 y Pro003

refleja una similitud más baja que con los elementos del grupo 1, ya que la similitud más baja en los proyectos de este grupo es de 0.7040.

5.4 Discusión de resultados

En cuanto a la conformación de los 2 grupos a partir del algoritmo de k-means, se tiene que entre los atributos en los que se diferencian, se encuentran: el tamaño, la complejidad y el tiempo de desarrollo, pero es necesario incrementar el número de proyectos a agrupar y comparar, debido a que la cantidad de proyectos y la heterogeneidad de ellos pueden influir en la cantidad de grupos a formar y en los valores de las características de cada grupo. En la tabla 5.16 se muestran los valores de los atributos por cluster, en donde se muestran sombreados los atributos en los que diferencian.

Tabla 5.16. Diferencias entre clusters de proyectos

Valor del atributo Atributo Cluster 0 Cluster 1

naturaleza-proyecto Desarrollo de una nueva aplicación Desarrollo de una nueva aplicación contexto-proyecto Aplicación de ventas Aplicación estadística clasificación-software Sistema de información Sistema de información criticidad-software Pérdida económica Criticidad sin efecto total-riesgost 0 0 total-riesgosp 0 0 total-riesgoso 0 0 total-riesgosh 0 0 total-riesgosr 1 0.25 total-riesgose 0 1.25 Probabilidad-riesgost Ninguno Ninguno Probabilidad-riesgosp Ninguno Ninguno Probabilidad-riesgoso Ninguno Ninguno Probabilidad-riesgosh Ninguno Ninguno Probabilidad-riesgosr Bajo Ninguno

Capítulo 5

- 71 -

Probabilidad-riesgose Ninguno Moderada impacto-riesgost Ninguno Ninguno impacto-riesgosp Ninguno Ninguno impacto-riesgoso Ninguno Ninguno impacto-riesgosh Ninguno Ninguno impacto-riesgosr Tolerable Ninguno impacto-riesgose Ninguno Tolerable Dominio Aplicación web Aplicación web LengProg Dinámico Estático HerramientaPlan Ninguna Software-administración HerramientaProg IDE-Programación IDE-Programación HerramientaMod Software-no-especializado Software-no-especializado MBD No Si SO Windows Windows TipoM PC PC UnidadM LOC LOC PF 31 505 ElementosT 1225 78372 TiempoR 408 77985 Complejidad Baja Media ComplejidadP Baja Media

- 72 -

Capítulo 6: Conclusiones En el presente capítulo se describen las conclusiones resultantes del análisis de los productos reportados en este trabajo de investigación, así como también los posibles trabajos futuros que se identificaron durante su realización.

6.1 Conclusiones Como producto final de esta investigación se tiene, un marco de características de proyectos, organizado en 5 conjuntos de factores, que contienen los factores relacionados con: el tipo de proyecto y producto de software, la valoración de las estimaciones realizadas, el ambiente de ingeniería, aspectos sociológicos y los factores configurables. El marco de características de proyectos de software es el punto de partida para la implementación de la herramienta de adecuación del desarrollo, ubicada en el ambiente AGDE. Esta herramienta pretende cubrir la necesidad de adecuar el desarrollo de proyectos de software y tiene el objetivo de adaptar el desarrollo mediante el uso de patrones de proyectos exitosos, adaptando las características configurables del desarrollo, en función del historial de proyectos existente en la memoria organizacional.

Capítulo 6

73 -

Unas consideraciones a tomar en cuenta son: que las características que conforman el marco fueron elegidas con el criterio de abarcar el mayor número de tipos de proyectos de software y que los factores configurables se establecieron en base al método AGD, motivo por el cual será necesario agregar o quitar características conforme evolucione el método y el área de investigación.

Una carencia detectada en el marco de características, es la ausencia de factores que

permitan identificar las cualidades de la organización, teniendo en cuenta que dos organizaciones son diferentes entre sí y que, incluso dentro de una misma organización, dos proyectos pueden ser también muy diferentes, el proceso aplicado con éxito en uno de ellos puede ser un completo fracaso en el otro. Por eso, el proceso de software debe adaptarse al contexto y características específicas de cada caso.

La aportación de esta investigación para la implementación de la herramienta de adecuación consiste en la identificación de las características presentes en el desarrollo de proyectos, las cuales se encuentran estructuradas en el marco de características, además del diseño de una base de datos de la información relativa al desarrollo de proyectos pasados, la información histórica del desarrollo de proyectos permite comparar los datos generados en su desarrollo, por lo que es importante contar con una memoria de la organización que almacene la información de los proyectos. La demostración realizada en esta investigación permitió validar el cumplimiento del objetivo de esta investigación el cual consiste en identificar las características del desarrollo de proyectos de software y el diseño de una estructura de almacenamiento de la información relativa al desarrollo de proyectos pasados, con el fin de habilitar la comparación entre proyectos. La comparación de proyectos almacenados se realizó manualmente, obteniendo el grado de semejanza existente, para iniciar con el proceso de demostración se recolectó la información del desarrollo de 5 proyectos de software.

Durante la recolección de información de proyectos, se observó que es difícil contar con toda la información que implica el desarrollo de un proyecto de software, porque no se define previamente la información a recolectar y no se lleva un registro completo del mismo. Se tuvo imprecisión en los datos que corresponden al tamaño del software utilizando casos de usos, líneas de código y puntos de función. También hubo dificultades en la captura de la información acerca de los subprocesos a realizar por cada producto. Esto sugiere que es importante que las organizaciones inicien su memoria organizacional con el mayor detalle posible, para que el desarrollo de proyectos pasados oriente en nuevos desarrollos.

El objetivo de una base de experiencias a través de la memoria organizacional en el desarrollo de proyectos no es intentar encontrar un solo enfoque de desarrollo aplicable universalmente, sino de identificar las circunstancias en las cuales es más apropiada la aplicación de: un modelo, una herramienta y los demás elementos configurables.

Para la comparación de los proyectos se utilizaron técnicas de clustering (k-means) para

agrupar proyectos similares y medidas de distancia para obtener el grado de similitud por cada par de proyecto.

Capítulo 6

74 -

Con el propósito de obtener grupos homogéneos de proyectos, la aplicación de k-medias sobre los proyectos recolectados, arrojó como resultado la conformación de 2 grupos de proyectos que se diferencian principalmente en: el tamaño medido en puntos de función y en líneas de código; en la complejidad de los datos y de programación; en el tiempo de desarrollo; y en algunos aspectos del ambiente de ingeniería como el software utilizado en el desarrollo.

Es importante mencionar que la agrupación de proyectos realizada en esta investigación

requiere de experimentación con diferentes algoritmos de clustering y contar con un número considerable de proyectos, debido a que la cantidad de proyectos y la heterogeneidad de ellos pueden influir en la cantidad de grupos a formar y en los valores de las características de cada grupo.

El resultado de la agrupación de proyectos depende en gran medida de la calidad de los

datos recopilados, de los atributos que se usaron para la comparación de los proyectos y del algoritmo de agrupamiento utilizado.

La recopilación de datos debe acompañarse de una limpieza (omisión de registros por

ausencia significativa de información o con información dudosa) e integración de los datos (si procede de diferentes organizaciones o base de datos), para que estén en condiciones para su análisis, con lo que los beneficios del análisis y de la extracción de conocimiento a partir de datos dependen, en gran medida, de la calidad de los datos recopilados.

6.2 Trabajos futuros

Durante el desarrollo de esta investigación se detectaron algunas áreas para dar continuidad a este trabajo.

Con el fin de obtener correlaciones entre los atributos establecidos en el marco de características, se requiere recolectar la información del desarrollo de un número considerable de proyectos de software. De esta manera se pueden obtener las dependencias entre los atributos de los proyectos.

Realizar experimentaciones con distintos algoritmos de agrupamiento, con una base de datos de proyectos mas nutrida, para identificar los mejores resultados para segmentar una base de datos de proyectos de software.

Aplicar el paso 2 del Procedimiento general para Identificar Patrones de Proyectos, el cual parte de las agrupaciones de los proyectos (Paso 1) y tiene el objetivo de identificar las semejanzas en los aspectos del desarrollo de los proyectos por cada grupo resultante del paso 1.

- 75 -

Anexos

Anexo A

- 76 -

Anexo A: Código SQL de la base de datos “historialproyectos” ´ En este anexo se presenta el código SQL de los comandos utilizados para la creación de la base de datos “historialproyectos” y para la creación de las 16 tablas que la conforman. CREATE DATABASE historialproyectos; CREATE USER Usuario WITH SUPERUSER PASSWORD 'cenidet2005'. CREATE TABLE Proyecto ( Id_Proyecto SERIAL primary key, Nombre character(100), Descripcion character(200), Naturaleza character(50), Fecha_Inicio date, Fecha_Termino date, Costo_Estimado real, Costo_Real real, Periodicidad_Reunion character(15), Frecuencia_Casos integer, Id_Proyecto_Similar integer, Contexto_Proyecto char(80), Metodo_desarrollo char(60), Modelo_Proceso char(60), Conjunto_asociado real, ); CREATE TABLE Catálogo_Riesgos ( Id_Riesgo SERIAL primary key, Descripcion char (80), Tipo char (30) ); CREATE TABLE Catálogo_Roles ( Id_Rol SERIAL primary key, Descripcion char (60) ); CREATE TABLE Desarrollador ( Id_Desarrollador SERIAL primary key, Nombre char (60), Nivel_Academico char (15), Experiencia_DesarrolloSW int, Experiencia_Dominio int, Experiencia_LengProg int, Experiencia_Metodologia int, Experiencia_Herramienta int ); CREATE TABLE Catálogo_Producto_Trabajo (

Anexo A

- 77 -

Id_Producto SERIAL primary key, Descripcion char (100) ); CREATE TABLE Catálogo_Subprocesos ( Id_Subproceso SERIAL primary key, Descripcion char (100) ); CREATE TABLE Riesgo ( Id_Riesgo int references Catálogo_Riesgos(Id_Riesgo), Id_Proyecto int references proyecto(Id_Proyecto) ON DELETE CASCADE, Probabilidad char (10), Impacto char (15), PRIMARY KEY (Id_Riesgo, Id_Proyecto) ); CREATE TABLE Roles ( Id_Proyecto int references proyecto(Id_Proyecto) ON DELETE CASCADE, Id_Desarrollador int references desarrollador(Id_Desarrollador) ON DELETE CASCADE, Id_Rol int references Catálogo_Roles(Id_Rol), Primary key (Id_Proyecto,Id_Desarrollador,Id_Rol) ); CREATE TABLE Catálogo_Ensambles_Partes( Id_EnsambleParte Serial Primary Key, Descripcion char(50) ); CREATE TABLE Producto_Software ( Id_Producto Serial primary key, Id_Proyecto int references proyecto(Id_Proyecto) ON DELETE CASCADE, Clasificacion char (25), Criticidad char (25), Complejidad_Programacion char (10), Complejidad_Datos char (10), Tiempo_Estimado int, Tiempo_Real int, Total_Defectos_Inyectados int, Total_Defectos_Removidos int, Total_Inspecciones int, Tiempo_Inspecciones int, Tiempo_Revisiones_Ind int, Subprocesos char(200) ); CREATE TABLE EnsambleParte( Id_Elemento Serial Primary Key, Id_Producto int references Producto_Software(Id_Producto) ON DELETE CASCADE,

Anexo A

- 78 -

Nombre char (60), Descripcion char(150), Id_Ensamble_Parte int references Catálogo_Ensambles_Partes(Id_EnsambleParte), Ensamble_Padre int, Puntos_Funcion int ); CREATE TABLE Producto_Trabajo( Id_Producto SERIAL PRIMARY KEY, Id_Elemento int references EnsambleParte(Id_Elemento) ON DELETE CASCADE, Id_Producto_Trabajo int references Catálogo_Producto_Trabajo(Id_Producto), Tiempo_Estimado int, Tiempo_Real int, Num_Defectos_Inyectados int, Num_Defectos_Removidos int, Total_Inspecciones int, Tiempo_Inspecciones int, Tiempo_Revisiones_Ind int ); CREATE TABLE Tamano( Id_Producto int Primary Key references Producto_Trabajo(Id_Producto) ON DELETE CASCADE, Unidad_Medida char (20), Elementos_Totales int, Elementos_Base int, Elementos_Borrados int, Elementos_Reutilizados int, Elementos_Modificados int ); CREATE TABLE Tamano_Acumulado( Id_Producto int Primary Key references Producto_Software(Id_Producto) ON DELETE CASCADE, Unidad_Medida char (20), Elementos_Totales int, Elementos_Base int, Elementos_Borrados int, Elementos_Reutilizados int, Elementos_Modificados int ); CREATE TABLE Subproceso( Id_Producto int references Producto_Trabajo(Id_Producto) ON DELETE CASCADE, Id_Subproceso int references Catálogo_Subprocesos(Id_Subproceso), Primary Key (Id_Producto,Id_Subproceso) ); CREATE TABLE Ambiente_Ingenieria (

Anexo A

- 79 -

Id_Proyecto int primary key references proyecto(Id_Proyecto) ON DELETE CASCADE, Dominio char (35), LenguageProg char (30), Herramienta_Plan char (40), Herramienta_Prog char (40), Herramienta_Mod char(40), ManejadorBD char (50), Sistema_Operativo char(35), Tipo_maquina char(35) );

Anexo B

- 80 -

Anexo B: Pantallas del prototipo del sistema historial de proyectos En este anexo se muestran las pantallas que conforman el prototipo “Historial de Proyectos”. Para cada pantalla se describen los campos que se requieren ingresar y las posibles alternativas que se tienen para los campos que los requieran. B.1 Descripción de las pantallas del prototipo La aplicación cuenta con una pantalla principal de donde se podrá acceder al resto de las ventanas mediante menús, como se muestra en las figura B.1.

Figura B.1. Ventana principal del prototipo “historial de proyectos”

En las siguientes secciones, para cada ventana de captura del submenú Registro se

presenta una tabla, donde se indica la instrucción para la captura de cada campo y sus posibles alternativas. B.1.1. Menú Proyecto En el menú proyecto se accede a todas las ventanas de captura de información del proyecto y se tiene la posibilidad de actualizar la información de éste, mediante los submenús Registro y Actualización tal como se muestra en la figura B.2 y B.3.

Anexo B

- 81 -

Figura B.2. Submenú Registro

Figura B3. Submenú Actualización

B.1.1.1. Submenú Registro En este submenú se tiene acceso a todas las ventanas de captura de la información de un proyecto de software, en los siguientes puntos se describen cada una de ellas.

Características generales del proyecto

Para iniciar la captura de la información del proyecto, primero se debe de ingresar su información general, como son: nombre, descripción fechas de inicio y término, entre otra (ver figura B.4). Para la mayoría de los datos a ingresar se tiene un conjunto de opciones que facilita el registro, el número identificador del proyecto se asigna de manera automática (al ser un campo de auto incremento).

Anexo B

- 82 -

Figura B.4. Ventana de ingreso para información general del proyecto

Tabla B.1. Campos de la ventana de Información general del proyecto

Campo Instrucción para la captura Alternativa(s) Id_Proyecto El valor para este campo se asigna de manera

automática. Al tratarse de un campo auto-incremental.

Nombre Escribir el nombre del proyecto. Descripción Escribir una descripción sencilla del objetivo del

proyecto.

Fecha Inicio Indicar la fecha en que se iniciaron las actividades de desarrollo del proyecto.

Fecha término Indicar la fecha en que se entregó el producto final al cliente.

Costo Estimado Indicar el costo estimado del desarrollo del proyecto.

Costo Real Indicar el costo real que se tuvo en el desarrollo del proyecto

Naturaleza del proyecto

Identificar la naturaleza del proyecto de acuerdo a las alternativas establecidas.

a) El proyecto tiene antecedentes. b) Se trata de una nueva aplicación c) Proyecto de mejora d) Proyecto de mantenimiento e) Proyecto de reingeniería

Contexto del proyecto

Indicar el entorno donde se utilizará el sistema. k) Administrativo l) Bancario m) Contabilidad

Anexo B

- 83 -

n) Educación o) Electrónica p) Finanzas q) Medicina r) Telecomunicaciones s) Ventas t) Otro

Método de desarrollo

Ingresar el paradigma utilizado durante el desarrollo del proyecto.

a) RUP b) XP c) AGD d) Ninguno e) Otro

Modelo de proceso

Indicar el modelo de proceso de software en el que se constituyeron las actividades.

a) Cascada b) Desarrollo evolutivo c) Construcción de prototipos d) Incremental e) Espiral f) Win-Win g) Otro

Periodicidad de reuniones

Ingresar con que frecuencia se reunió el equipo para darle seguimiento al proyecto. -

a) Diaria b) Semanal c) Cada 15 dias d) Mensual e) Cada 2 meses

Una vez ingresadas las características generales del proyecto y guardada la información,

se puede seguir capturando el resto de los aspectos de la información del proyecto registrado pulsando el botón siguiente, con esto, el identificador del proyecto se pasará automáticamente a la siguiente ventana de captura. Cuando se accede al resto de las ventanas a partir del menú proyecto será necesario indicar el proyecto al que se le asociará la información, para esto se debe seleccionar de la ventana de listado de proyectos, tal como se muestra en la figura B.5.

Figura B.5. Listado de proyectos registrados

Anexo B

- 84 -

Características del producto de software La información requerida en le ventana de características del producto de software, es aquella referente al producto final (ver figura B.6). En esta ventana se pide el tamaño acumulado del conjunto de productos del trabajo, en caso de contar con la información por producto del trabajo se deberá desglosar esta información al momento de la captura de cada producto del trabajo (ver figura B.13).

Figura B.6. Ventana de características del producto de software

Tabla B.2. Campos de la ventana de características del producto de software

Campos Instrucción para la captura Alternativa(s)

Id_Proyecto Elegir un proyecto del listado de los proyectos registrados.

Clasificación del software

Ubicar el producto del software en alguna de las 5 clasificaciones establecidas.

a) Software de sistema b) Software comercial c) Sistema de información d) Software militar e) Software de usuario final

Criticidad del software

La criticidad corresponde al impacto debido al fracaso del software, indicar la naturaleza del daño ocasionado por los defectos en el software.

a) Criticidad sin efecto b) Pérdida de confort c) Pérdida económica d) Daños a la salud e) Perdidas de vidas

Subprocesos Indicar el conjunto de subprocesos utilizado para el desarrollo del proyecto.

Subprocesos del PSP, TSP, otros

Anexo B

- 85 -

Cantidad estimada del total de líneas de código (sin contar comentarios y líneas en blanco) del sistema.

Cantidad real del total de líneas de código (sin contar comentarios y líneas en blanco) del sistema.

Tamaño

Líneas de código de tipo: base, borradas, reutilizadas, añadidas, modificadas, nuevas y cambiadas y nuevas reutilizadas.

Complejidad de programación d) Baja: cuando existen ciclos y cálculos simples.

e) Media: la comunicación entre módulos es simple, cálculos moderadamente difíciles.

f) Alta: estructura de datos, cálculos complejos que requieren resultados exactos.

Complejidad

Complejidad en los datos d) Baja: arreglos simples o archivos en memoria principal, pocas entradas/salidas, ninguna reestructuración de datos.

e) Media: múltiples entradas/salidas, reestructuración de datos, acceso a otros medios de comunicación de almacenaje (por ejemplo, la cinta, el disco duro, otras máquinas).

f) Alta: las estructuras de datos son sumamente son acoplados y relacionadas, optimizados algoritmos de búsqueda, comprobaciones de consistencia de datos de fondo.

Tiempo de duración estimado para el desarrollo del proyecto

Tiempo de duración real en el desarrollo del proyecto

Tiempo de desarrollo (en minutos)

Tiempo de desarrollo por producto de trabajo

Número defectos insertados por producto de trabajo.

Defectos

Número de defectos removidos por producto de trabajo.

Número total de inspecciones realizadas al producto de software.

Inspecciones

Tiempo total empleado en las inspecciones.

Revisiones individuales

Tiempo total empleado en inspecciones individuales.

Anexo B

- 86 -

Riesgos del proyecto En la ventana de la figura B.7 se captura la información sobre los riesgos que presentó el proyecto. Un riesgo implica dos características: 1) probabilidad, de que ocurra el acontecimiento que caracteriza al riesgo y 2) impacto, si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas (ver figura 7). Para la captura de los riesgos se cuenta con un catálogo (presionar el botón “Ver catálogo de riesgos”), de donde se deberá elegir o bien ingresar un nuevo riesgo de no estar en el listado.

Figura B.7. Ventana para el ingreso de los riegos del proyecto

Tabla B.3. Campos de la ventana de registro de los riesgos del proyecto

Ambiente de ingeniería de software Las características de la ventana de ambiente de ingeniería corresponden al hardware y software utilizados en un esfuerzo de ingeniería, entre los elementos identificados en este ámbito se encuentran las herramientas de soporte, el sistema operativo en el que correrá la aplicación, entre otras (ver figura B.8).

Campo Instrucción para la captura Alternativa(s)

Id_Proyecto Elegir un proyecto del listado de los proyectos registrados.

Para cada riesgo identificar su tipo

Tipos: g) Riesgo de tecnología h) Riesgo de personas i) Riesgo organizacional j) Riesgo de herramientas k) Riesgo de requerimientos l) Riesgo de estimación

Probabilidad de que ocurra

Probabilidad: Muy bajo, bajo, moderado, alto o muy alto.

Riesgos del proyecto

Impacto Impacto: catastrófico, serio, tolerable o insignificante.

Anexo B

- 87 -

Figura B.8. Ventana de características del ambiente de ingeniería

Tabla B.4. Campos de la ventana de características del ambiente de ingeniería

Atributo Instrucción para la captura Posibles opciones

Id_Proyeto Elegir un proyecto del listado de los proyectos registrados.

Dominio de aplicación

Nombre del dominio tecnológico en que se ubica el proyecto.

a) Procesamiento distribuido b) Aplicación web c) Sistema de escritorio d) e) Aplicación de base de datos f) Otro

Lenguaje de programación

Nombre del lenguaje de programación principal.

Java, C++, C, C#, Clipper, Cobol, JavaScript, Visual Basic, Pascal, Cobol, Delphi, Otro.

Otros lenguajes Indicar todos los lenguajes de programación utilizados en la aplicación, sin repetir el principal.

Java, C++, C, C#, Clipper, Cobol, JavaScript, Visual Basic, Pascal, Cobol, Delphi, Otro.

Herramientas de soporte

Nombres de las herramientas de planificación, programación y modelado.

Rational Rose, Microsoft Office Visio, Together, Microsoft Office Project., Eclipce, JBuilder, CBuilder, Borland C++, Otro.

Manejador de base de datos

Indicar si se utiliza un manejador de base de datos.

Access, Informix, MySQL, Oracle, PostgreSQL, SQL Server, Sybase, Otro.

Sistema operativo Indicar el sistema operativo en el que correrá la aplicación.

Apple / Macintosh, Linux, Microsoft Windows, Unix, Otro.

Tipo de máquina Indicar el tipo de máquina en la que se utilizará la aplicación.

Mainframe, Mini computadora, PC, Otro.

Anexo B

- 88 -

Desarrolladores Para la captura de la información del equipo de desarrolladores se tiene la ventana de Desarrolladores (ver figura B.9), en donde se debe indicar el proyecto y el desarrollador mediante los catálogos correspondientes. Para el caso del desarrollador, se utilizará el catálogo si ya se ha registrado con anterioridad al desarrollador (ver figura B.10), en caso del que no esté registrado se deberán ingresar todos sus datos en la ventana de Desarrolladores. Al elegir el nombre del desarrollador del listado se mostrará la información acerca de la experiencia última registrada, por lo que se deberá actualizar de ser necesario.

Figura B.9. Ventana de ingreso de la información de desarrolladores

Anexo B

- 89 -

Figura B.10. Listado de desarrolladores registrados

Tabla B.5. Campos de la ventana de ingreso de información de desarrolladores

Atributo Instrucción para la captura Alternativa(s)

Id_Proyecto Elegir un proyecto del listado de los proyectos registrados.

Id_Desarrollador El valor para este campo se asigna de manera automática. Al tratarse de un campo auto-incremental.

Nombre Este campo puede ingresarse de 2 forma: al elegir un desarrollador del listado o ingresarlo directamente para el caso que el desarrollador no se encuentre en el listado.

Nivel de educación

Identificar el nivel de educación de cada desarrollador de acuerdo a las alternativas establecidas.

f) Técnico g) Ingeniería ó Licenciatura h) Maestría i) Doctorado j) Otro

Experiencia del equipo en el

Experiencia en años en el desarrollo de software por desarrollador.

Anexo B

- 90 -

desarrollo del proyecto

Forma de adquirir la experiencia por desarrollador. Ubicarla en alguna de las alternativas.

a) La obtenida una institución educativa b) Obtenida en la industria c) Obtenida de manera independiente

Experiencia en años en implementaciones en el lenguaje de programación a medir, por integrante.

Experiencia del desarrollador en el lenguaje de programación

Forma de adquirir la experiencia por desarrollador. Ubicarla en alguna de las alternativas.

a) La obtenida una institución educativa b) Obtenida en la industria c) Obtenida de manera independiente

Experiencia en años y la aplicación del método de desarrollo, por desarrollador.

Experiencia del desarrollador en la método de desarrollo Forma de adquirir la experiencia por

desarrollador. Ubicarla en alguna de las alternativas.

a) La obtenida una institución educativa b) Obtenida en la industria c) Obtenida de manera independiente

Experiencia en años en el desarrollo de software, por desarrollador.

Experiencia del desarrollador en el dominio del proyecto Forma de adquirir la experiencia por

desarrollador. Ubicarla en alguna de las alternativas.

a) La obtenida una institución educativa b) Obtenida en la industria c) Obtenida de manera independiente

Experiencia en años en el uso de las herramientas de soporte. Ubicarla en alguna de las alternativas.

Experiencia del desarrollador en el uso de las herramientas de soporte

Forma de adquirir la experiencia en el uso de las herramientas de soporte. Ubicarla en alguna de las alternativas.

a) La obtenida una institución educativa b) Obtenida en la industria c) Obtenida de manera independiente

Arquitectura de software La estructura de la arquitectura del software se ve como un conjunto de niveles ensamble-parte, la estructura mayor se trata de un sistema que está conformado por varias partes producto, los ensambles productos por varias partes componente, los ensambles componente están formados por varias partes módulo y los ensamble módulo consisten de varias partes objeto. Los elementos incluidos en el catálogo de ensambles/partes son: sistema, producto, componente, modulo y objeto (ver figura. B11), si se requiere una estructura con diferentes elementos será necesario ingresar los elementos en el catálogo (accediendo en la ventana de catálogo de ensambles-partes mediante el botón “ver catálogo”).

Para ingresar la información de la arquitectura se deberá iniciar por la estructura mayor

del software y terminar con la estructura menor, esto es necesario para poder obtener la jerarquía de ensambles-partes completa. En la figura B.12 se muestra la ventana de captura

Anexo B

- 91 -

para los elementos de la arquitectura del software, del producto de software específico a capturar.

Figura B.11. Estructura general de un sistema (ensamble/parte)

Figura B.12. Ventana para el ingreso de la estructura

general de un sistema (ensamble/parte)

Sistema

Producto 1 Producto 2 Producto N

Componente 1 Componente N Componente N

Modulo 1 Modulo N

Objeto 1

1 Nivel

2 Nivel

3 Nivel

4 Nivel

Nivel es de Ensamble /parte

Anexo B

- 92 -

Tabla B.6. Campos de la ventana de ingreso de la arquitectura del software Atributo Instrucción para la captura Alternativa(s)

Id_Proyeto Elegir un proyecto del listado de los proyectos registrados.

Id_Componente El valor para este campo se asigna de manera automática. Al tratarse de un campo auto-incremental.

Nombre Indicar el nombre del componente (elemento) de la arquitectura.

Descripción Breve descripción del elemento. Parte Elegir del catálogo de ensambles partes, para este elemento. Catálogo de

Ensambles/Partes. Ensamble padre

Se deberá ingresar de manera jerárquica los elementos de la arquitectura de tal manera que el primero en ingresar será el padre del siguiente elemento a ingresar y así sucesivamente.

Catálogo de elementos registrados para el proyecto correspondiente.

Puntos de función

Indicar el total de puntos de función por cada elemento, si es que se cuenta con esta información, de no ser así indicar el estimado en el elemento de mayor jerarquía (primer registro).

Productos del trabajo La última ventana de ingreso es la de productos del trabajo, esta información es similar a la del producto de software (ver Tabla B.2) sólo se diferencia por el tamaño acumulado. Para cada elemento de la arquitectura (módulo, componente, etc.) se deberán registrar los productos asociados (si se cuenta con este nivel de detalle), por lo que se tendrá que elegir del catálogo de elementos registrados (ver figura B.13).

Para indicar el producto del trabajo se deberá seleccionar del catálogo, de no aparecer en el listado se ingresa el nombre del producto del trabajo requerido (al dar clic en el botón “Ingresar nuevo producto del trabajo”), en la figura B.14 se muestra la ventana correspondiente al catálogo de productos.

Figura B.13. Ventana de productos del trabajo

Anexo B

- 93 -

Figura B.14. Ventana del catálogo de productos del trabajo

B.1.1.2. Submenú Actualización

En el submenú Actualización se tiene las opciones de modificar la información del proyecto y de dar lo de baja, en las figuras B.15 y B.16 se muestran las ventanas correspondientes.

Figura B.15. Ventana para dar de baja a un proyecto

Anexo B

- 94 -

Figura B.16. Ventana para modificar la información del proyecto

B.1.2. Menú Catálogos En este menú se tienen las opciones de administrar los catálogos utilizados para la captura de la información de roles, riesgos, subproceso, productos de trabajo y de ensambles/partes (ver figura B.17). Las ventanas de estos catálogos son similares entre si, se presenta un listado de los registros y se tienen las opciones de modificar la información, eliminar el registro y dar de alta. En la figura B.18 se muestra la ventana de roles, sólo se mostrará en este documento la ventana de catálogos de roles al existir gran similitud con el resto de las ventanas de catálogos.

Figura B.17. Menú Catálogos

Anexo B

- 95 -

Figura B.18. Ventana de Catálogo de roles

Figura B.19. Ventana de Catálogo de roles con la opción de agrega

Anexo C

- 96 -

Anexo C: Métrica para obtener la experiencia del equipo en el desarrollo de software.

La experiencia del equipo en el desarrollo de software, se definió a partir de 2 aspectos: el promedio de años del equipo en el desarrollo de software y la forma en que se adquirió la experiencia, para este aspecto se toma en cuenta la medida de tendencia central moda.

En la forma de adquirir la experiencia se establecieron las siguientes clases: la obtenida

en la industria; la obtenida en alguna institución educativa, como parte de su formación y la obtenida de manera independiente. La métrica para obtener la Métrica de la Experiencia en el Desarrollo de Software (MEDS) queda como sigue:

MEDS = M1*M2

Donde: M1 = Peso de la opción en la que se ubica el promedio de la experiencia del equipo, conforme al esquema de la figura C.1. M2 = Peso de la opción en la que se ubica el valor de la moda en la forma de adquirir la experiencia, conforme al esquema de la figura C.1.

En la figura C.1 se presenta el esquema en el que estableció esta métrica de experiencia, en donde se presentan las opciones posibles para los 2 aspectos considerados M1 y M2.

Figura C.1. Esquema de la métrica MEDS

La clasificación para este tipo de experiencia, se dividió en 5 clases, en donde está

asociado con los posibles valores de MEDS, tal como se muestra en la tabla C.1.

MEDS: Metrica de la Experiencia en el Desarrollo de Software

M1: Promedio de años del equipo en el desarrollo de software.

M2: Moda de la forma en que adquirió la experiencia el equipo.

OP1: 100 Años>=20

OP2 : 80 20=>Años>=15

OP3 : 60 15> Años >=10

OP4 : 40 10> Años >=5

OP5 : 20 5> Años >=0

OP2: 0.50 En institución educativa

OP1: 1.0 En la industria

OP3: 0.25 Autoaprendizaje

Anexo C

- 97 -

Tabla C.1. Clasificación de la experiencia del equipo en el desarrollo de software

Clasificación Valor de MEDS Muy alta 100

Alta 80, 60,40

Media 30,20

Baja 15

Muy baja 10, 5

Anexo D

- 98 -

Anexo D.Concentrado de la información de los proyectos almacenados

En las siguientes tablas se muestra un concentrado de la información histórica de los proyectos recolectados, la información está organizada por cada conjunto de factores del marco de características. Se depositaron en la base de datos los siguientes proyectos: Proyecto Pro001. Apoyo a la GPSE en el desarrollo de los módulos de evaluación de proyectos y formación de paquetes. Proyecto Pro002. Especificación del sistema de estadística del CENACE (Centro Nacional de Control de Energía). Proyecto Pro003. Desarrollo del modulo de carga para el sistema estadístico. Proyecto Pro004. Página Web para el control de renta de bodegas privadas. Proyecto Pro005. Desarrollo de una aplicación de Comercio electrónico. Tabla D.1. Información de los proyectos almacenados, correspondiente a los factores que indican el tipo

de proyecto y producto de software.

Atributo Pro001 Pro002 Pro003 Pro004 Pro005 Naturaleza del proyecto Nueva

aplicación Nueva aplicación

Mantenimiento Nueva aplicación

Proyecto de mejora

Contexto del proyecto Electrónica Estadístico Estadístico Ventas Comercio electrónico

Clasificación del software Sistema de información

Sistema de información

Sistema de información

Sistema de información

Sistema de información

Criticidad del software Criticidad sin efecto

Criticidad sin efecto

Criticidad sin efecto

Pérdida económica

Pérdida económica

Riesgos tecnológicos 0 0 0 0 0

Riesgos de personas 0 0 0 0 0

Riesgos organizacionales 0 0 0 0 0

Riesgos de herramientas 0 0 0 0 0 Riesgos de requerimientos 0 1 0 1 0

Riesgos de estimación 1 1 2 0 1 Probabilidad de riesgos tecnológicos

Ninguno Ninguno Ninguno Ninguno Ninguno

Probabilidad de los riesgos de personas

Ninguno Ninguno Ninguno Ninguno Ninguno

Probabilidad de los riesgos organizacionales

Ninguno Ninguno Ninguno Ninguno Ninguno

Probabilidad de los riesgos de herramientas

Ninguno Ninguno Ninguno Ninguno Ninguno

Probabilidad de los riesgos de

Ninguno Alto Ninguno Bajo Ninguno

Anexo D

- 99 -

requerimientos Probabilidad de los riesgos de estimación

Moderada Muy alto Bajo, Moderada

Ninguno Muy bajo

Impacto de los riesgos tecnológicos

Ninguno Ninguno Ninguno Ninguno Ninguno

Impacto de los riesgos de personas

Ninguno Ninguno Ninguno Ninguno Ninguno

Impacto de los riesgos organizacionales

Ninguno Ninguno Ninguno Ninguno Ninguno

Impacto de los riesgos de herramientas

Ninguno Ninguno Ninguno Ninguno Ninguno

Impacto de los riesgos de requerimientos

Ninguno Tolerable Ninguno Tolerable Ninguno

Impacto de los riesgos de estimación

Tolerable Tolerable Tolerable Ninguno Tolerable

Tabla D.2. Información de los proyectos almacenados, correspondiente a los factores de valoración.

Atributo Pro001 Pro002 Pro003 Pro004 Pro005

Unidad de medida LOC LOC LOC LOC Casos de uso

Puntos de función 453 574 683 30.70 218

Elementos totales 20,080 23,114 226,694 1225 43,600 Tiempo de desarrollo real (Min) 66,480 74,100 123,360 480 48,000

Complejidad de los datos Alta Media Media Baja Baja Complejidad de programación Media Media Media Baja Media

Tabla D.3. Información de los proyectos almacenados, correspondiente a los factores sociológicos.

Atributo Pro001 Pro002 Pro003 Pro004 Pro005 Número de desarrolladores 4 3 3 1 2

Nivel de educación del equipo Ingeniería Ingeniería Ingeniería Ingeniería Ingeniería

Experiencia del equipo en el desarrollo del proyecto

Media Media Media Alta Alta

Experiencia del equipo en el lenguaje de programación

Media Media Media Alta Alta

Experiencia en la método de desarrollo

Media Alta Alta Media Alta

Experiencia en el dominio del proyecto

Media Media Media Media Alta

Experiencia en el uso de las herramientas de soporte

Alta Alta Alta Alta Alta

Anexo D

- 100 -

Tabla D.4. Información de los proyectos almacenados, correspondiente a los factores del ambiente de ingeniería.

Atributo Pro001 Pro002 Pro003 Pro004 Pro005 Dominio tecnológico

Procesamiento distribuido

Aplicación web

Aplicación web

Página Web Aplicación web

Lenguaje de programación

Visual Basic Java Java HTML PHP

Herramienta de planificación

Project Project Project Ninguna Project

Herramienta de programación

Microsoft Excel Eclipce Eclipce Dreamweaver Dreamweaver

Herramienta de modelado

Microsoft Office Microsoft Office

Microsoft Office

Ninguno Microsoft Office

Manejador de base de datos

Informix Sql Server Oracle Ninguno MySQL

Sistema operativo Microsoft Windows

Microsoft Windows

Microsoft Windows Multiplataforma Microsoft

Windows Tipo de máquina PC PC PC PC PC

Tabla D.5. Información correspondiente a los factores configurables del proyecto Pro001.

Atributo Pro001

Productos resultado

CIM: Documento de negocio existente CIM: Documento de identificación de componentes PIM: Prototipo del sistema CIM: Documento de requerimientos del sistema PIM: Documento de revisión de requerimientos del sistema PIM: Documento de ingeniería directa PIM: Documento de especificación de pruebas de aceptación PSM: Documento de restricciones en requerimientos PSM: Documento de la arquitectura de sistema PSM: Documento de especificación de las pruebas de integración OM: Documento pruebas de aceptación OM: Documento de evaluación

Estructura general del producto de software (Arquitectura) Sistema, Módulo, Funciones

Conjunto de subprocesos Planificación, Requerimientos, Análisis y diseño, Revisión de diseño de alto nivel, Implementación, Codificación, Pruebas

Estructura del equipo de trabajo Líder de equipo y desarrollador Periodicidad de reuniones de seguimiento Semanal

Número de inspecciones Tiempo en inspecciones Método de desarrollo Ninguno Modelo de proceso Cascada

Anexo D

- 101 -

Tabla D.6. Información correspondiente a los factores configurables del proyecto Pro002. Atributo Pro002

Productos resultado

CIM: Documento de identificación de componentes CIM: Documento de requerimientos del sistema PIM: Documento de revisión de requerimientos del sistema PIM: Documento de ingeniería directa PIM: Documento de requerimientos del software PIM: Documento de especificación de pruebas de aceptación PSM: Documento de la arquitectura de sistema OM: Documento identificación de recurso OM: Documento pruebas de aceptación OM: Documento de evaluación

Estructura general del producto de software (Arquitectura) Sistema, Componente, Módulo, Funciones

Conjunto de subprocesos Planificación, Requerimientos, Análisis y diseño, Revisión de diseño de alto nivel, Implementación, Codificación, Pruebas

Estructura del equipo de trabajo Líder de equipo y desarrollador Periodicidad de reuniones de seguimiento Semanal

Número de inspecciones Tiempo en inspecciones Método de desarrollo Ninguno Modelo de proceso Cascada

Tabla D.7. Información correspondiente a los factores configurables del proyecto Pro003.

Atributo Pro003

Productos resultado

CIM: Documento de negocio existente CIM: Documento de identificación de componentes CIM: Minutas de revisión en el grupo de trabajo PIM: Documento de ingeniería directa PIM: Documento de requerimientos del software PIM: Documento de especificación de pruebas de aceptación PIM: Documento de revisión de requerimientos del sistema PSM: Documento de la arquitectura de sistema IM: Documento pruebas de unidad OM: Documento pruebas de aceptación OM: Documento de evaluación OM: Manual de usuario

Estructura general del producto de software (Arquitectura) Módulo, Funciones

Conjunto de subprocesos Planificación, Requerimientos, Análisis y diseño, Diseño detallado, Revisión de diseño detallado, Implementación, Codificación, Pruebas

Estructura del equipo de trabajo Líder de equipo y desarrollador Periodicidad de reuniones de seguimiento Semanal

Número de inspecciones

Tiempo en inspecciones

Método de desarrollo Ninguno

Modelo de proceso Cascada

Anexo D

- 102 -

Tabla D.8. Información correspondiente a los factores configurables del proyecto Pro004. Atributo Pro004

Productos resultado CIM: Documento de requerimientos del sistema

PIM: Prototipo del sistema

Estructura general del producto de software (Arquitectura) Sistema, Funciones

Conjunto de subprocesos

Requerimientos, Análisis y diseño, Revisión de diseño detallado, Implementación, Revisión de codificación, Pruebas, Verificación del cliente

Estructura del equipo de trabajo Líder de equipo y desarrollador Periodicidad de reuniones de seguimiento Semanal

Número de inspecciones

Tiempo en inspecciones

Método de desarrollo Ninguno

Modelo de proceso Construcción de prototipos

Tabla D.9. Información correspondiente a los factores configurables del proyecto Pro005. Atributo Pro005

Productos resultado

CIM: Documento de identificación de componentes CIM: Prototipo del sistema CIM: Documento de requerimientos del sistema PIM: Documento de requerimientos del software IM: Documento de codificación IM: Documento pruebas de unidad OM: Manual de usuario

Estructura general del producto de software (Arquitectura) Sistema, Módulo, Funciones

Conjunto de subprocesos Requerimientos, Análisis y diseño, Revisión de diseño detallado, Implementación, Codificación, Compilación, Pruebas

Estructura del equipo de trabajo Líder de equipo y desarrollador Periodicidad de reuniones de seguimiento Semanal

Número de inspecciones

Tiempo en inspecciones

Método de desarrollo Ninguno

Modelo de proceso Construcción de prototipos

Anexo E

- 103 -

Anexo E. Archivo de datos Arff

Archivo utilizado para la obtención de los grupos de proyectos en WEKA. % 1. Titulo: subconjunto de campos de la base de datos historial de proyectos (marco de características) % Factores que identifican el tipo de proyecto y producto de software, del ambiente de ingeniería y de valoración % Autora: Cindy Delgado Solis % Institución: CENIDET % Fecha: Julio de 2007 % @RELATION proyectos @ATTRIBUTE naturaleza-proyecto {Desarrollo-nueva-aplicación,Proyecto-mantenimiento,Proyecto-mejora} @ATTRIBUTE contexto-proyecto {Electrónica,Estadistica,Ventas,Comercio-electronico} @ATTRIBUTE clasificacion-software {Sistema-información} @ATTRIBUTE criticidad-software {Criticidad-sin-efecto, Pérdida-económica} @ATTRIBUTE total-riesgost NUMERIC @ATTRIBUTE total-riesgosp NUMERIC @ATTRIBUTE total-riesgoso NUMERIC @ATTRIBUTE total-riesgosh NUMERIC @ATTRIBUTE total-riesgosr NUMERIC @ATTRIBUTE total-riesgose NUMERIC @ATTRIBUTE probabilidad-riesgost {Ninguno,Muy-Bajo,Bajo,Moderada,Alto,Muy-Alto} @ATTRIBUTE probabilidad-riesgosp {Ninguno,Muy-Bajo,Bajo,Moderada,Alto,Muy-Alto} @ATTRIBUTE probabilidad-riesgoso {Ninguno,Muy-Bajo,Bajo,Moderada,Alto,Muy-Alto} @ATTRIBUTE probabilidad-riesgosh {Ninguno,Muy-Bajo,Bajo,Moderada,Alto,Muy-Alto} @ATTRIBUTE probabilidad-riesgosr {Ninguno,Muy-Bajo,Bajo,Moderada,Alto,Muy-Alto} @ATTRIBUTE probabilidad-riesgose {Ninguno,Muy-Bajo,Bajo,Moderada,Alto,Muy-Alto} @ATTRIBUTE impacto-riesgost {Ninguno,Insignificante,Tolerable,Serio,Catastrófico} @ATTRIBUTE impacto-riesgosp {Ninguno,Insignificante,Tolerable,Serio,Catastrófico} @ATTRIBUTE impacto-riesgoso {Ninguno,Insignificante,Tolerable,Serio,Catastrófico} @ATTRIBUTE impacto-riesgosh {Ninguno,Insignificante,Tolerable,Serio,Catastrófico} @ATTRIBUTE impacto-riesgosr {Ninguno,Insignificante,Tolerable,Serio,Catastrófico} @ATTRIBUTE impacto-riesgose {Ninguno,Insignificante,Tolerable,Serio,Catastrófico} @ATTRIBUTE Dominio {Procesamiento-distribuido, Aplicación_web, Sistema-escritorio} @ATTRIBUTE LengProg {Estatico,Dinamico} @ATTRIBUTE HerramientaPlan {Software-administración, Ninguna, Software-no-especializado } @ATTRIBUTE HerramientaProg {IDE-Programación,IDE-General} @ATTRIBUTE HerramientaMod {Software-modelado, Software-no-especializado,Ninguna} @ATTRIBUTE MBD {Si,No} @ATTRIBUTE SO {Apple,Linux,Windows} @ATTRIBUTE TipoM {PC,Mainframe,Minicomputadora,Dispositivo-Movil} @ATTRIBUTE UnidadM {LOC,Caso-uso, Documento, Hoja, Modelo} @ATTRIBUTE PF NUMERIC @ATTRIBUTE ElementosT NUMERIC @ATTRIBUTE TiempoR NUMERIC @ATTRIBUTE ComplejidadD {Baja,Media,Alta} @ATTRIBUTE ComplejidadP {Baja,Media,Alta} @DATA Desarrollo-nueva-aplicación,Electrónica, Sistema-información,Criticidad-sin- efecto,0,0,0,0,0,1,Ninguno,Ninguno,Ninguno,Ninguno,Ninguno,Moderada,Ninguno, Ninguno,Ninguno,Ninguno, Ninguno,Tolerable,Procesamiento-distribuido,Estatico,Software-administración,IDE-General,Software-no-especializado,Si,Windows,PC,LOC,453,20080,66480,Alta,Media Desarrollo-nueva-aplicación,Estadistica, Sistema-información,Criticidad-sin-efecto,0,0,0,0,1,1,Ninguno,Ninguno,Ninguno,Ninguno,Alto,Muy-Alto,Ninguno,Ninguno,Ninguno, Ninguno,Tolerable, Tolerable,Aplicación_web,Estatico,Software-administración,IDE-Programación,Software-no-especializado,Si,Windows,PC,LOC,574,23114,74100,Media,Media Proyecto-mantenimiento, Estadistica,Sistema-información,Criticidad-sin-efecto,0,0,0,0,0,2,Ninguno,Ninguno,Ninguno,Ninguno, Ninguno,Moderada, Ninguno,Ninguno,Ninguno,Ninguno, Ninguno, Tolerable,Aplicación_web,Estatico,Software-administración,IDE-Programación,Software-no-especializado,Si,Windows,PC,LOC,683,226694,123360,Media,Media

Anexo E

- 104 -

Desarrollo-nueva-aplicación,Ventas,Sistema-información,Pérdida-económica,0,0,0,0,1,0,Ninguno,Ninguno,Ninguno,Ninguno,Bajo,Ninguno,Ninguno,Ninguno,Ninguno,Ninguno, Tolerable,Ninguno ,Aplicación_web,Dinamico,Ninguna,IDE-Programación,Software-no-especializado,No,Windows,PC,LOC,31,1225,480,Baja,Baja Proyecto-mejora, Comercio-electronico,Sistema-información,Pérdida-económica,0,0,0,0,0,1,Ninguno,Ninguno,Ninguno,Ninguno,Ninguno,Muy-Bajo,Ninguno,Ninguno, Ninguno,Ninguno, Ninguno, Tolerable,Aplicación_web ,Dinamico,Software-administración,IDE-Programación,Software-no-especializado,Si,Windows,PC,LOC,310,43600,48000,Baja,Media

- 105 -

Referencias

Referencias

- 106 -

[1] F. Scalone, “Estudio comparativo de los modelos y estándares de calidad del software”, tesis de maestría, Universidad tecnológica nacional facultad regional Buenos Aires, 2006. [2] A. Pérez Soltero, “Memoria organizacional basada en casos”, Revista de Ciencia y Tecnología Politécnica (RECITEC), Vol. 6 No.1, 2002. [3] A. Pérez Soltero, “El papel de las Tecnologías de Información y la memoria organizacional dentro de las Empresas Inteligentes”, Novática Revista de la Asociación de Técnicos de Informática, No. 182, 2006. [4] IEEE 100-2000, “The Authoritative Dictionary of IEEE Standards Terms”, Seventh Edition 5.6. [5] IEEE Std 610.12-1990, “IEEE Standard Glossary of Software Engineering Terminology”. [6] P. Cáceres, “Hacia un proceso metodológico dirigido por modelos para el desarrollo ágil de sistemas de información Web”, Grupo de Investigación Kybele Universidad Rey Juan Carlos, España 2003. http://www.willydev.net/descargas/prev/AgilWeb.Pdf Página vigente al: 08/09/06 [7] E. Gamma, R. Helm., R. Johnson, J. Vlissides, “Design Patterns: Elements of Reusable Object Oriented Software”, Addison Wesley, 1995. [8] L. Welicki, “Patrones y Antipatrones: una Introducción - Parte I”, MSDN Latinoamericana, 2004. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/MTJ_2864/default.aspx Página vigente al: 17/09/06 [9] Jiawei Han, Data Mining: Concepts and techniques, Morgan, ISBN 9781558609013, segunda edición, Morgan Kaufmann Publishers, USA, 2006. [10] O. Maqbool, “Hierarchical Clustering for Software Architecture Recovery”, IEEE Transactions on software engineering, vol. 33, no. 11, noviembre 2007. [11] L. Moreno García, “Obtención y validación de modelos de estimación de software mediante técnicas de minería de datos”, Revista Colombiana de Computación, Volumen 3, 2002. [12] B. Bernábe Loranca, “Estrategia Clustering en E-Commerce”, Facultad de Ciencias de la Computación, BUAP, Puebla, México, 2004. http://www.somece.org.mx/simposio2004/memorias/grupos/archivos/010.doc Página vigente al: 18/07/07 [13] J. Hernández Orallo, “Introducción a la minería de datos”, Pearson Prentice Hall, Madrid 2004. [14] J. Molina López, "Técnicas de análisis de datos, aplicaciones practicas utilizando Microsoft Excel y Weka", Universidad Carlos III de Madrid, 2004.

Referencias

- 107 -

http://galahad.plg.inf.uc3m.es/~docweb/ad/transparencias/apuntesAnalisisDatos.pdf Página vigente al: 30/07/07 [15] WEKA the University of Waikato, “Waikato Environment for Knowledge Analysis”, http://www.cs.waikato.ac.nz/~ml/index.html Página vigente al: 02/07/07 [16] D. García Morate, “Manual de Weka”. http://metaemotion.com/diego.garcia.morate/download/weka.pdf [17] F. Keenan, “Agile process tailoring and problem analysis (APTLY)”, Software Engineering, ICSE 2004, Proceedings. 26th International Conference on Volume, 2004, Page(s): 45 – 47. http://doi.ieeecomputersociety.org/10.1109/ICSE.2004.1317417 Página vigente al: 18-abr-06 [18] X. Peng, “Knowledge support in software process tailoring”, proceedings of the 38th Hawaii International Conference on System Sciences, IEEE, 2005. [19] M. González García, A. Martínez Enríquez, “The Architectural and Group Development Method: an Experimentation”, Workshop on Quantitative Techniques for Software Agile Process”, Foundations on Software Engineering, ACM, SIGSOFT, 2004. [20] M. González García, “AGD: Método de Desarrollo Arquitectónico en Grupo”, Tesis de Doctorado, Centro de Investigaciones y de Estudios Avanzados (CINVESTAV) del IPN, 2006. [21] S. Diehl “Report on MSR 2005: International Workshop on Mining Software Repositories”, ACM SIGSOFT Software Engineering Notes, 2005. [22] L. Williams, L. Layman, “Extreme programming evaluation framework for Object-Oriented LanguagesVersion 1.4”, North Carolina State University, Department of Computer Science, 2004. ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2004/TR-2004-18.pdf Página vigente al: 10-ene-2006. [23] W. Krebs, L. Williams, “Rational unified process evaluation framework version 1.0”, IBM -Coporation, North Carolina State University, 2005. ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2005/TR-2005-46.pdf Página vigente al: 15-ene-2006. [24] X. Peng, R. Balasubramaniam, “A tool for the capture and use of process knowledge in process tailoring”, proceedings of the 36th Hawaii International Conference on System Sciences, 2003. [25] H. Scott, B. Kurt, “Case-Based approach to tailoring software process”, Appears in Int’l Conf. on Case-Based Reasoning, Vancouver, British Columbia, Canada, 2001, pp. 249-262. http://csce.unl.edu/~scotth/papers/Henninger-Baumgarten_ICCBR01.pdf Página vigente al: 10-sep-2006.

Referencias

- 108 -

[26] E. Diez, “Generador del mapa de actividad de un proyecto de desarrollo de software”, tesis de maestría, ITBA, Buenos Aires, 2003. [27] J. Capers, "Variations in Software Development Practices”, IEEE Computer Society, 2003. [28] M. Garre, “Comparación de diferentes algoritmos de clustering en la estimación de costo en el desarrollo de software Miguel Garre”, Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.3, No. 1, 2007 [29] I. Sommerville, Ingeniería de Software, Pearson Educación, ISBN: 970-26-0206-8, sexta edición, México, 2002. [30] R. Pressman, “Ingeniería de Software: un enfoque moderno”, McGraw-Hill, ISBN: 0-07-709677-0, quinta edición, España, 2002. [31] Protocolo del proyecto 285.06-P, “Sistema de Soporte para el Proceso de Software en equipo (SiSoProS)”, Ingeniería de software, Departamento de ciencias computacionales, Cenidet, 2006. [32] B. Bruegge, “Ingeniería de software orientado a objetos”, Pearson educación, ISBN: 970-26-0010-3, primera edición, México, 2002 [33] Software Engineering Institute, “Continuous Risk Management Overview”, 2006. http://www.sei.cmu.edu/risk/overview.html#definition. Página vigente al: 05-nov-2006. [34] R. Higuera, “Team Risk Management, Software Engineering Institute”, 1995. http://www.stsc.hill.af.mil/crosstalk/1995/01/TeamRisk.asp. Página vigente al: 05-nov-2006. [35] http://www.wordreference.com/definition/ [36] Watts S. Humphrey, “A Discipline for Software Engineering”, Addison-Wesley, 1995. [37] Albrecht, Allan J., Gafeney Jr., John E. “Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation”, IEEE Transactions on Software Engineering, Vol. 9 Issue 6, Nov 1983. [38] Albrecht, “Measuring Application Development Productivity”, IBM Applications Development Symposium, Monterey, CA, USA, 1979. [39] J. Guerra, C. Luza, M. Coral, “Una aplicación práctica del método de análisis de puntos de función”, Revista de Investigación de Sistemas e Informática, Facultad de Ingeniería de Sistemas e Informática, Lima, Perú, 2005. http://sisbib.unmsm.edu.pe/bibvirtualdata/publicaciones/risi/n3_2005/a02.pdf Página vigente al: 12-nov-2006.

Referencias

- 109 -

[40] IEEE Std 1045-1992, “IEEE Standard for Software Productivity Metrics”, Approved September 17, 1992 by IEEE Standards Board. [41] H. Oktaba, “Modelo de Procesos para la Industria de Software (MoProSoft)”, Versión 1.3, Agosto 2005. [42] IEEE Std 1220-1998, “IEEE Standard for Application and Management of the Systems Engineering Process”, Approved 8 December 1998. [43] Watts S. Humphrey, “Introduction to the Team Software Process”, Addison Wesley, 1999. [44] Sun Developer Network, http://java.sun.com/ Página vigente al: 12/05/07 [45] PostgreSQL, http://www.postgresql.org/ Página vigente al: 08/05/07 [46] http://jdbc.postgresql.org/download.html Página vigente al: 18/05/07 [47] Java en castellano, “Acceso a Bases de Datos [JDBC]”, http://www.programacion.net/java/tutorial/jdbc/ Página vigente al: 15/05/07 [48] L. Dailey Paulson, “Developers Shift to Dynamic Programming Languages”, IEEE Computer Society, Volume 40, Febrero 2007.