Uce3896225 0122

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA
INDICADORES CLAVE DE RENDIMIENTO EN PROYECTOS

DE DESARROLLO DE SOFTWARE A PARTIR DE UN
OBJETIVO ORGANIZACIONAL
WASHINGTON ANÍBAL SEGURA MIGUELES
TESIS DE GRADO PARA OPTAR AL GRADO DE

MAGÍSTER EN INGENIERÍA INFORMÁTICA
JULIO 2014
1
PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA
INDICADORES CLAVE DE RENDIMIENTO EN PROYECTOS

DE DESARROLLO DE SOFTWARE A PARTIR DE UN
OBJETIVO ORGANIZACIONAL
WASHINGTON ANÍBAL SEGURA MIGUELES
Profesor Guía: Rodolfo Villarroel Acevedo
Programa: Magíster en Ingeniería Informática
JULIO 2014
2
ÍNDICE DE CONTENIDOS
1. INTRODUCCIÓN ......................................................................................................................... 8
1.1. Problemática .................................................................................................................... 10
1.2. Objetivos .......................................................................................................................... 11
1.2.1. Objetivo General ............................................................................... 11
1.2.2. Objetivos Específicos ........................................................................ 11
2. MARCO TEÓRICO .................................................................................................................... 12
2.1. Dirección Estratégica y Objetivos Organizacionales ........................................................ 12
2.1.1. Objetivos Organizacionales ............................................................... 13
2.2. Métricas............................................................................................................................ 13
2.2.1. Recursos medibles por métricas de software ..................................... 14
2.2.2. Indicadores clave de desempeño ....................................................... 15
2.3. ¿Por qué medir? ............................................................................................................... 16
2.4. ¿Qué se puede medir en un proyecto de desarrollo de software? ....................................... 18
2.5. Trabajos Relacionados...................................................................................................... 19
2.5.1. Objetivos, Preguntas y Métricas GQM .............................................. 19
2.5.2. Sistema de Catalogación de Métricas e Indicadores con Potencia de
Web Semántica ........................................................................................... 21
2.5.3. Cuadro de mando integral. ................................................................ 22
2.6. Adaptable Domain and Process Technology Engineering, A.D.A.P.T.E. ............................ 22
3. SOLUCIÓN PROPUESTA ......................................................................................................... 24
3.1. Búsqueda Semántica ......................................................................................................... 25
3.2. Ontología Informática ....................................................................................................... 25
3.3. Capa Lógica: reglas de inferencia..................................................................................... 26
3.4. Capa Ontológica............................................................................................................... 28
3.4.1. Relaciones Conceptuales ................................................................... 28
3.4.2. Diagrama de clases de ontología Métricas-Objetivos ........................ 31
3.4.3. Métricas instanciables en el modelo .................................................. 32
3.5. Capa Programación.......................................................................................................... 36
3.5.1. Framework Apache Jena ................................................................... 36
3.5.2. Framework de Descripción de recursos, RDF .................................. 36
3.5.3. Descripción RDF de Ontología ......................................................... 36
3.5.4. Lenguaje de consulta SPARQL ......................................................... 37
3.5.5. Querys SPARQL ............................................................................... 38
3.6. Sistema de Inferencia ........................................................................................................ 39
3.6.1. Tecnologías utilizadas ....................................................................... 39
3.6.2. Arquitectura del sistema .................................................................... 39
3.6.3. Modelo de datos ................................................................................ 40
3.6.4. Interfaces de usuario ......................................................................... 41
3
4. CASO DE ESTUDIO................................................................................................................... 42
4.1. Metodología de Validación ............................................................................................... 42
4.2. Datos de la empresa participante del caso de estudio ....................................................... 42
4.3. Métricas Pre-ingresadas al sistema ................................................................................... 43
4.4. Métricas ingresadas por usuario ....................................................................................... 47
4.5. Objetivos ingresados por usuario ...................................................................................... 48
4.6. Relaciones encontradas Métricas-Objetivo........................................................................ 50
4.7. Análisis de Resultados....................................................................................................... 51
4.7.1. Análisis 1 .......................................................................................... 51
4.7.2. Análisis 2 .......................................................................................... 51
4.7.3. Análisis 3 .......................................................................................... 51
4.7.4. Análisis 4 .......................................................................................... 52
4.7.5. Análisis 5 .......................................................................................... 52
4.7.6. Análisis 6 .......................................................................................... 52
4.7.7. Resultados Obtenidos ........................................................................ 52
5. CONCLUSIONES ....................................................................................................................... 54
6. REFERENCIAS .......................................................................................................................... 56
7. ANEXOS ...................................................................................................................................... 58
7.1. Descripción RDF de Ontología de Métricas y Objetivos .................................................... 58
7.2. Anexo Interfaces de usuario .............................................................................................. 67
4
ÍNDICE DE FIGURAS
Figura 2.1: La empresa y su contexto ......................................................................................... 12

Figura 2.2: Modelo de relaciones de elementos de medición ...................................................... 15
Figura 2.3: Diagrama de retroalimentación de información medible .......................................... 18
Figura 2.4: Pasos del método GQM ........................................................................................... 20
Figura 2.5: Ejemplo de objetivos-preguntas-métricas de GQM .................................................. 21
Figura 3.1: Diagrama de solución .............................................................................................. 24
Figura 3.2: Arquitectura ontológica de la solución ..................................................................... 26
Figura 3.3: Relaciones conceptuales de la ontología................................................................... 30
Figura 3.4: Diagrama de clases ontología métricas-objetivos ..................................................... 31
Figura 3.5: Software de desarrollo ontológico Protegé. .............................................................. 37
Figura 3.6: Arquitectura de la solución ...................................................................................... 40
Figura 3.7: Modelo relacional de base de datos .......................................................................... 41
Figura 4.1: Gráfico de Resultados .............................................................................................. 53
Figura 7.1: Pantalla de inicio al sistema de inferencia ................................................................ 67
Figura 7.2: Pantalla de gestión de métricas ................................................................................ 68
Figura 7.3: Pantalla de gestión de objetivos. .............................................................................. 68
Figura 7.4: Pantalla de ingreso de métricas. ............................................................................... 69
Figura 7.5: Pantalla de ingreso de objetivos. .............................................................................. 70
Figura 7.6: Pantalla de visualización de métricas. ...................................................................... 70
Figura 7.7: Pantalla de visualización de objetivos ...................................................................... 71
Figura 7.8: Pantalla de la organización ...................................................................................... 71
5
ÍNDICE DE TABLAS
Tabla 3.1: Sintaxis de entidades de ontología ............................................................................. 27

Tabla 3.2: Definición de conceptos de capa ontológica .............................................................. 28
Tabla 3.3: Definición de métrica Progreso del proyecto ............................................................. 32
Tabla 3.4: Definición de métrica Recursos utilizados ................................................................. 33
Tabla 3.5: Definición de métrica Trabajo repetido, no reutilización ........................................... 33
Tabla 3.6: Definición de métrica Reutilización de componentes ................................................ 34
Tabla 3.7: Definición de métrica Tiempo de respuesta de soporte .............................................. 35
Tabla 3.8: Definición de métrica Número de bugs por programador........................................... 35
Tabla 4.1: Datos de empresa participante en caso de estudio ...................................................... 42
Tabla 4.2: Métrica pre-ingresada al sistema, Progreso del Proyecto ........................................... 43
Tabla 4.3: Métrica pre-ingresada al sistema, Recursos utilizados ............................................... 44
Tabla 4.4: Métrica pre-ingresada al sistema, Trabajo repetido .................................................... 44
Tabla 4.5: Métrica pre-ingresada al sistema, Reutilización de componentes ............................... 45
Tabla 4.6: Métrica pre-ingresada al sistema, Tiempo de respuesta de soporte............................. 46
Tabla 4.7 Métrica pre-ingresada al sistema, Número de bugs por programador .......................... 46
Tabla 4.8: Métrica ingresada por usuario, Ventas anuales .......................................................... 47
Tabla 4.9: Métrica ingresada por usuario, Personal capacitado al año ........................................ 47
Tabla 4.10: Métrica ingresada por usuario, Objetivo visión Zeke ............................................... 48
Tabla 4.11: Métrica ingresada por usuario, Mantener una tasa de crecimiento ........................ 48
Tabla 4.12: Métrica ingresada por usuario, Impulsar la mejora técnica en el personal ................ 48
Tabla 4.13: Métrica ingresada por usuario, Incorporar nuevas áreas de negocio en la empresa ... 49
Tabla 4.14: Métrica ingresada por usuario, Disminuir los defectos en el software entregado a
clientes ...................................................................................................................................... 49
Tabla 4.15: Métrica ingresada por usuario, Reducir tiempos extra en desarrollo de proyectos .... 49
Tabla 4.16: Relaciones encontradas Métrica-Objetivo................................................................ 50
6
RESUMEN
Para poder mejorar la gestión del negocio, los gerentes cuentan con diversas herramientas, las cuales tienen
algo en común: basarse en los Indicadores Claves de Rendimiento o Key Performance Indicators (KPI), éstos son
métricas que cuantifican el desempeño de un proceso indicando su rendimiento. Sin embargo, para que éstos sean
eficaces deben estar alineados con los objetivos, estrategias, visión y misión de la organización. Se propone
determinar la relación existente entre objetivos y métricas e implementar un modelo conceptual a través de una
ontología para inferir qué métricas utilizar dado un objetivo organizacional y con esto ayudar al control de proyectos
de desarrollo de software.
Palabras Clave: Control, Desarrollo de Software, Objetivo Organizacional, KPI.
ABSTRACT
In order to improve business management, managers have several tools, which have something in
common, they are based on key performance indicators (KPI), these are metrics that quantify the performance of a
process showing it’s performance. However, to be effective they must be aligned with the objectives, strategies,
vision and mission of the organization. It is proposed to determine the relationship between goals and metrics and
implement a conceptual model through an ontology to infer which KPIs to use as an organizational goal and
thereby help control software development projects.
Key Words: Control, Software Development, Organizational Objective, KPI.
7
1. INTRODUCCIÓN
Toda empresa, independiente del sector o rubro en que se desenvuelva, consiste en la transformación de
insumos en un producto o servicio a través de un proceso productivo. En este proceso existen tareas lógicamente
relacionadas para obtener ya sea un producto (físico), un servicio o una combinación de ambos. Este proceso
productivo debe utilizar los recursos de manera eficiente, es decir, que se están usando de la mejor manera posible,
para garantizar la competitividad y sostenibilidad de la organización. La norma internacional ISO-9001 define un
proceso como “Una actividad que utiliza recursos y que se gestiona con el fin de permitir que los elementos de
entrada se transformen en resultados” [1].
Una empresa dirige sus recursos y esfuerzos para cumplir su propósito, también llamado
objetivo organizacional, éste es una situación deseada que la empresa intenta alcanzar, es una imagen de sí
misma que la organización pretende para el futuro, cercano o lejano. A su vez, puede poseer una visión estratégica
que se define como la dinámica de la organización, cómo se articulan las diferentes áreas hacia la búsqueda del
objetivo organizacional, junto con esta se definen la visión y misión. Estos objetivos están íntimamente relacionados
con los procesos productivos de la empresa, ya que es a través de ellos que se transmite la estrategia de negocio de la
organización, implementándola en cada uno hasta el producto final. Una empresa crece a medida que su producto es
mejor valorado por los consumidores en comparación a la competencia. Existen variadas dimensiones en las que un
producto puede destacarse para atraer a los consumidores, por ejemplo; precio, calidad, utilidad, diseño entre otras.
Para posicionar una empresa entre los consumidores es necesario potenciar estas características en su producto. Para
lograr esto, el proceso productivo de la empresa debe ser eficiente, eficaz y de calidad. Para garantizar que un
proceso cumple con estas características es necesario realizar un seguimiento y control del proceso. Tom DeMarco
afirma que “No se puede controlar lo que no se puede medir” [2], es necesario entonces, definir métricas que
cuantifiquen el desempeño del proceso, y ayuden a determinar la calidad del proceso y tomar acciones correctivas en
el mismo en caso de que esto no sea así.
En estos últimos años, uno de los problemas de la industria del software fue el bajo nivel de calidad,
productividad, y los altos costos [3]. Esta problemática representa cantidad de esfuerzo perdido en el desarrollo
donde los productos, a menudo, son entregados con errores significativos que producen costos y posibles problemas
y/o inconvenientes.
Los principales problemas en el área de software son:

 Calidad insuficiente del producto final.
 Estimaciones de duración de proyectos y asignación de recursos inexactos.
 Retrasos para entregar los productos terminados.
 Costos de desarrollo y mantenimiento de productos fuera de control.
8
 Escasez de personal calificado en un mercado laboral de alta demanda.
 Tendencia de crecimiento del volumen y complejidad de los productos.
A pesar del indiscutible valor de los avances logrados por investigaciones en la definición de métricas, a la
hora de aplicar dicha información en el ámbito de Ingeniería de Software, se encuentran los siguientes problemas [4]:
 No se cuenta con un catálogo suficientemente completo y estructurado con información clasificada
relacionada a métricas e indicadores que sirva como base para la selección de las mismas y como apoyo al
diseño del proceso de medición o evaluación.
 La información disponible sobre métricas, indicadores y modelos de evaluación no está basada en criterios
comunes, y en muchos casos está definida para dominios específicos, dificultando su aplicación a
procesos de evaluación genéricos y su reutilización en distintos proyectos de evaluación y/o medición.
La siguiente tesis corresponde a la recopilación de conceptos clave para la determinación de métricas y

objetivos organizacionales, generando modelos conceptuales con sus principales entidades y atributos e
implementando una solución, basada en una ontología, para consultar y determinar que métricas son más adecuadas
para realizar medición en proyectos de desarrollo de software y así controlar el avance hacia el cumplimiento de los
objetivos organizacionales.
Esta tesis se enmarca dentro del proyecto FONDEF “A.D.A.P.T.E. Adaptable Domain And Process
Technology Engineering”, plataforma metodológica y tecnológica que apoya el mejoramiento de procesos en
PyMES de TICs [6].
El siguiente documento se divide en 7 capítulos, el primero corresponde a la introducción a la temática,

incluyendo la problemática descubierta, los objetivos y la planificación del proyecto. El segundo capítulo
corresponde al marco teórico en donde se recopila la información relacionada, explicando los conceptos principales y
los trabajos relacionados. El tercer capítulo corresponde a la descripción de la solución propuesta junto a su
implementación, incluyendo el modelado de la misma y la programación. El cuarto capítulo corresponde a la
validación y prueba de la solución propuesta en una empresa, indicando analizando el proceso y resultados
obtenidos. El quinto capítulo corresponde a las conclusiones del trabajo y el sexto capítulo a las referencias del
mismo. Finalmente el capítulo 7 corresponde a un anexo con la descripción RDF de la ontología de métricas y
objetivos organizacionales.
9
1. 1. P R O B L E M ÁT I C A
Los objetivos organizacionales pueden ser cuantificados a través del proceso productivo de la empresa y
medidos mediante los KPI, sin embargo se debe identificar qué KPI es el indicado dado un objetivo. Esta
identificación es compleja ya que se necesita generar un conocimiento, basarse en la experiencia y poseer cierto nivel
de involucramiento en la organización y en sus proyectos para poder decidir qué métrica y qué KPI utilizar para
lograr un objetivo. Existen muchas variables que determinan la selección de una métrica u otra, esta decisión
depende de la estrategia a seguir y el control necesario para lograrlo, sin embargo, existe una desconexión entre los
objetivos organizacionales y la medición de procesos, ya que unos son de tipo cualitativo y otros cuantitativos.
De esto se desprenden dos problemas principales, estos son:

 Inadecuada determinación de Objetivos Organizacionales, las empresas no saben qué hacer y por qué.
 Incorrecta y a veces nula selección de métricas para medición de procesos, inexistente o inadecuado control
de procesos.
Estos dos problemas están relacionados el uno con el otro, ya que para el cumplimiento del objetivo
organizacional es necesario realizar mediciones del proceso productivo. Al determinar el objetivo, es necesario
determinar cuáles son los atributos a medir y controlar para lograrlo, por lo tanto, es necesario cuantificar estos
objetivos y su cumplimiento a través de métricas y estas convertirlas en indicadores clave para determinar el
desempeño de los procesos productivos de la empresa para su posterior mejora.
El principal problema de la mayor parte de los procesos de la empresa es que el proceso sólo se mide al final.
En la generalidad de los casos, lo anterior proporciona poca o nula retroalimentación relativa sobre las actividades
individuales dentro del proceso, o cuando lo proporciona es demasiado tarde. Es necesario establecer puntos de
medida aproximados a cada actividad, de manera que las personas que la realizan reciban una retroalimentación
directa, inmediata y pertinente para establecer las correcciones en tiempo real.
10
1. 2. O B J E T I VO S
1.2.1. Objetivo General
Determinar métricas, indicadores clave, a partir de objetivos organizacionales, para cuantificar el desempeño
de proyectos de desarrollo de software.
1.2.2. Objetivos Específicos
 Identificar motivaciones de empresas para determinar objetivos organizacionales.

 Identificar métricas aplicadas a proyectos de desarrollo de software.
 Determinar relaciones entre métricas de proyectos de software y objetivos organizacionales.
 Formular un esquema conceptual (ontología) que represente la relación métrica-objetivo.
 Implementar la ontología.
 Desarrollar un sistema web que consulte e infiera métricas en base a la ontología desarrollada.
 Validar la propuesta en una empresa informática.
Estos objetivos están relacionados, por un lado, con la identificación de motivaciones de empresas para
determinar el contexto sobre el cual una organización determina sus metas, por otro lado es necesario conocer cuáles
son las métricas medibles en proyectos de desarrollo de software para generar un catálogo de métricas a utilizar y sus
respectivos métodos de medición. Se debe, a su vez, determinar la relación existente entre los objetivos a cumplir y
las mediciones necesarias para realizar el seguimiento y control de estas metas. Esta relación debe plasmarse en una
ontología que conceptualice y materialice estas relaciones en un modelo instanciable e implementable en una
ontología para luego ser procesado por computador, con lo que se podrá realizar consultas sobre el modelo a través
de un sistema web con una interfaz amigable que realice una abstracción de los detalles de las consultas semánticas
en lenguaje natural al usuario final.
11
2. MARCO TEÓRICO
2. 1. D I R E C C I Ó N E S T R AT É G I C A Y O B J E T I VO S O R G A N I Z AC I O N A L E S
Para que los esfuerzos de una empresa tengan éxito es necesario que la mayor parte de los integrantes de la
organización estén alineados en un propósito común, formando parte de una única visión, con una misión, unos
valores y una estrategia organizacional clara y compartida. La dirección estratégica consiste en la planificación,
organización y control con el fin de alcanzar un objetivo propuesto y aún más; se preocupa de anticipar eventos y
responder a estos de la mejor manera posible.
Los objetivos que intenta cumplir la dirección estratégica se llaman comúnmente Objetivos Organizacionales y
son metas que al ser alcanzadas proporcionarán un estado de beneficio a la empresa. Estos beneficios pueden ser
tanto materiales como ingresos monetarios o inmateriales, reconocimiento, reputación y valoración.
Un objetivo organizacional es una situación deseada que la empresa intenta lograr, es una imagen que la
organización pretende para el futuro. Al alcanzar el objetivo, la imagen deja de ser ideal y se convierte en real y
actual, por lo tanto, el objetivo deja de ser deseado y se busca otro para ser alcanzado.
Los gerentes de las empresas utilizan distintas herramientas para gestionar sus negocios, estas herramientas se
basan en Indicadores Claves de Rendimiento o Key Performance Indicators (KPI), estos medirán el desempeño de un
proceso productivo de la empresa y determinarán su rendimiento respecto a ciertas dimensiones como pueden ser
costos, tiempos, recursos, etc. Sin embargo, para que éstos sean eficaces deben estar alineados con los objetivos,
estrategias, visión y misión de la organización. Esta relación se puede apreciar en la figura 2.1, donde a través de los
objetivos se definen métricas que retroalimentan el proceso productivo para su mejora.
Figura 2.1: La empresa y su contexto
12
2.1.1. Objetivos Organizacionales
Algunas características de los objetivos organizacionales son:

 Son enunciados escritos sobre resultados a ser alcanzados en un periodo determinado.
 Son los fines hacia los cuales está encaminada la actividad de una empresa, los puntos finales de la planeación.
 Se conciben como el punto final de un programa administrativo, bien sea que se establezca en términos
generales o específicos.
 Tienen jerarquías, y también forman una red de resultados y eventos deseados. Una compañía u otra empresa es
un sistema. Si las metas no están interconectadas y se sustentan mutuamente, la gente seguirá caminos que
pueden parecer buenos para su propia función pero que pueden ser dañinos para la compañía como un todo.
 Deben ser racionalmente alcanzables y deben estar en función de la estrategia que se elija.
 Son una obligación que se impone una empresa porque es necesaria, esencial para su existencia.
Algunas funciones de los objetivos organizacionales son:

 Presentación de una situación futura: se establecen objetivos que sirven como una guía para la etapa de
ejecución de las acciones.
 Fuente de legitimidad: los objetivos justifican las actividades de una empresa.
 Sirven como estándares: sirven para evaluar las acciones y la eficacia de la organización.
 Unidad de medida: para verificar la eficiencia y comparar la productividad de la organización.
La estructura de los objetivos establece la base de relación entre la organización y su medio ambiente. Es
preferible establecer varios objetivos para satisfacer la totalidad de necesidades de la empresa.
Los objetivos no son estáticos, pues están en continua evolución, modificando la relación de la empresa con
su medio ambiente. Por ello, es necesario revisar continuamente la estructura de los objetivos frente a las alteraciones
del medio y de la organización.
Para lograr el objetivo organizacional es necesario realizar un correcto seguimiento y control de ciertos
aspectos que ayudarán al cumplimiento de las metas propuestas. Este control se realiza utilizando métricas.
2. 2. M É T R I C A S
Las métricas, en gestión de proyectos informáticos, se pueden definir como una herramienta de ayuda para la
planificación, desarrollo y mantenimiento de sistemas de información. Las métricas son un buen medio para
entender, monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de mantenimiento [8].
13
En general, estas mediciones persiguen tres objetivos fundamentales:
 Entender qué ocurre durante el desarrollo y el mantenimiento.
 Controlar qué es lo que ocurre en los proyectos.
 Mejorar los procesos y productos.
Las métricas pueden ser utilizadas para que los profesionales e investigadores puedan tomar las mejores
decisiones y como medio para asegurar la calidad en los productos/procesos/ proyectos de software [9].
2.2.1. Recursos medibles por métricas de software
Algunos recursos sobre los que se pueden utilizar métricas de software son [12]:
 Procesos de ingeniería del software; por ejemplo, actividades del análisis, diseño, codificación, etc.
 Productos de ingeniería del software; por ejemplo, diseños, código fuente, casos de prueba, entre otros.
 Tareas realizadas por personas; por ejemplo, la eficiencia de una persona que realiza las pruebas, o la
productividad de un diseñador individual.
Las métricas sirven para identificar eventos y tendencias importantes en los proyectos y otorgan a la
organización la información necesaria para la toma de decisiones. Además, ayudan como vocabulario común entre el
grupo de personas que participa de la implementación de los proyectos, y el grupo que los patrocina (sponsors,
stakeholders) y funcionan como motivación para el equipo, porque relacionan el esfuerzo personal de los miembros
con los resultados generales del proyecto.
La acción de recopilar los datos de métricas se denomina medición. Cuando se habla de medición, se hace
referencia a determinar la dimensión de la magnitud de una variable en relación con una unidad de medida
prestablecida y convencional. Se realiza una comparación de lo que hay con lo que había o debería haber.
Existen cuatro elementos básicos que interactúan en la medición [12]:

 La(s) Entidad(es) a ser medida(s)
 La variable a medir denominada atributo
 El valor de la medición
 La escala o unidad de medida
14
La figura 2.2 [12] representa las relaciones entre los cuatro elementos básicos que interactúan en la medición
haciendo una separación entre el mundo empírico que es el cual será medido y el matemático que cuantifica la
medición en valores y unidades.
Figura 2.2: Modelo de relaciones de elementos de medición
Como se puede ver en la imagen, el mundo real o empírico posee una entidad medida sobre la que se
realizará la medición y un atributo que será medido; por otro lado el mundo formal o matemático posee los datos que
serán cuantificados a unidades y aplicados por su valor.
2.2.2. Indicadores clave de desempeño
Las siglas K.P.I. vienen de las palabras Key Performance Indicators que traducido a español se define como
Indicadores claves de desempeño [13]. Son métricas financieras o no financieras usadas para ayudar a una
organización a definir y medir el progreso que se da según las metas planteadas, se utilizan para
cuantificar objetivos que reflejan el rendimiento de una organización, y que generalmente se recogen en su plan
estratégico. Es un tema del que se suele hablar con frecuencia en el mundo de la gestión.
Los KPIs suelen estar atados a la estrategia de la organización. Los KPIs son "vehículos de comunicación";
permiten que los ejecutivos de alto nivel comuniquen la misión y visión de la empresa a los niveles jerárquicos más
bajos, involucrando directamente a todos los colaboradores en realización de los objetivos estratégicos de la empresa.
15
Así los KPIs tienen como objetivos principales: medir el nivel de servicio, realizar un diagnóstico de la situación,
comunicar e informar sobre la situación y los objetivos, motivar los equipos responsables del cumplimiento de los
objetivos reflejados en el KPI, progresar constantemente [10].
2. 3. ¿P O R QUÉ MEDIR?
Dada la gran inversión realizada por las compañías para desarrollar y mantener información crítica, hay una
demanda creciente de más evaluaciones objetivas y gestión de proyectos de software. Todas las organizaciones
software exitosas tienen implementadas métricas como parte de sus actividades diarias tanto de gestión como
técnicas. Las métricas proporcionan información objetiva necesaria para tomar decisiones que tengan un impacto
positivo en el negocio y en el rendimiento. En estas organizaciones, la información derivada de las métricas es
tratada como un recurso importante utilizado en todos los niveles de gestión.
La manera en que la medición es llevada a cabo y utilizada en una organización de software determina el
valor que la organización recibirá en términos de rendimiento. La medición es más efectiva cuando es implementada
de tal forma que dé soporte a los objetivos técnicos y de negocio de la organización y cuando se integra con el resto
de actividades de gestión y técnicas ya definidas en la organización. Las métricas son de gran utilidad sobre todo
cuando proporcionan información objetiva relacionada con los riesgos y problemas que pueden impactar con los
objetivos definidos para un proyecto.
Las métricas ayudan a responder a preguntas cruciales como: ¿El proyecto está dentro de la planificación?, ¿El
software está listo para ser entregado al usuario/cliente?, ¿El software cumple con los requisitos de calidad
necesarios? [14]
A nivel de proyecto las métricas realizan los siguientes aportes [14]:

 Identificar y corregir problemas de manera temprana: Las métricas facilitan una estrategia de gestión activa
porque ayudan a la identificación y la gestión de los riesgos. Fomentan la temprana recuperación y corrección de
problemas técnicos y de gestión que pueden ser más difíciles y costosos de resolver en fases avanzadas del ciclo
de vida de desarrollo. Los responsables de la organización utilizan métricas como fuente para anticiparse a los
problemas tomando así un enfoque proactivo.
 Tomar decisiones informadas o basadas en datos: Todo proyecto de software está sujeto a ciertas
restricciones de presupuesto, agenda, calidad técnica, etc., que deben ser compensadas entre sí y gestionadas
para cumplir los objetivos establecidos del proyecto. Las decisiones que se toman sobre un área casi siempre
impactan en otras, incluso aunque parezca que no están relacionadas. Las métricas ayudan a la persona que tiene
que tomar las decisiones a evaluar estos impactos de forma objetiva y a optimizar el rendimiento del proyecto.
 Justificar decisiones: Las métricas dan soporte para defender las bases de estimaciones y planificaciones.
 Relacionar e integrar la información derivada de otros proyectos: Esto ayuda al jefe de proyecto a tomar
decisiones utilizando información objetiva.
16
 Definir e implementar planificaciones más realistas: Las métricas sirven como historial de otros proyectos.
A nivel de la organización la medición proporcionará los siguientes beneficios [14]:

 Identificar las oportunidades de mejora.
 Mejorar el flujo de trabajo de los procesos.
 Fomentar la visión de la empresa.
 Mejorar la satisfacción del cliente.
 Mejorar la posición de la empresa en el mercado.
 Mejorar la visibilidad sobre la situación de los proyectos basada en datos objetivos
 Saber si ha mejorado
 Aumentar el Retorno de Inversión.
En definitiva, un proceso efectivo de medición proporciona una base adecuada de entendimiento de las
capacidades de desarrollo, lo que permite definir planes viables para el desarrollo de productos y la prestación de
servicios de calidad. Las medidas permiten detectar tendencias y anticipar problemas y, por lo tanto, permiten
establecer un mejor control de los costos, una reducción de los riesgos, mejorar la calidad y asegurar la consecución
de los objetivos de negocio.
La figura 2.3 [14] representa un diagrama que incluye desde la definición de objetivos organizacionales, una
visión estratégica, misión empresarial y valores representativos de la agrupación para llegar hasta la medición de
estos para retroalimentar a los primeros y evaluar el cumplimiento de las metas. Esta Medición se realiza sobre el
proceso.
17
Figura 2.3: Diagrama de retroalimentación de información medible
Según indica la imagen, identificación la misión y visión la empresa se pondrá una meta y una imagen
futura que espera de sí misma. Diagnosticando la organización en su ámbito interno y externo podrá identificar tanto
amenazas, oportunidades, debilidades y fortalezas que puedan afectar el cumplimiento de las metas. Al fijar los
objetivos y estrategias y tomando como base el punto anterior, podrá fijar acciones y mediciones para cumplir la
meta propuesta. Realizando un control y seguimiento de estas variables se podrá retroalimentar el proceso productivo
de la empresa con información real de la situación actual y cumplimiento de las metas propuestas y así las ramas
directivas fijar los cursos de acción correctivos al proceso para su mejora.
2. 4. ¿Q U É S E P U E D E M E D I R E N U N P R O Y E C T O D E D E S AR R O L L O D E S O F T W A R E ?
Algunas mediciones posibles para un proyecto de software son [14]:

 Líneas de código fuente escritas
 Horas-programador diarias
 Costo por hora-programador, en unidades monetarias
 Horas-programador totales
 Líneas de código fuente por hora de programador
18
 Costo total actual del proyecto, en unidades monetarias
 Costo por línea de código fuente
 Revisiones por caso de uso
 Correcciones a casos de uso
 Reescritura de módulos por errores
 Costo total de proyecto.
Estas dimensiones medibles de un proyecto de software son inútiles si no se alinean con un objetivo claro.
Responder las preguntas ¿Por qué es necesario medir? y ¿Qué se medirá? ayuda a dirigir los esfuerzos en cumplir un
objetivo claro y definido como visión estratégica de la organización.
2. 5. T R A B AJ O S R E L A C I O N A D O S
2.5.1. Objetivos, Preguntas y Métricas GQM
Objetivos, Preguntas y Métricas; en inglés Goal Question and Metrics o abreviado a GQM, es un método
dirigido por objetivos para desarrollar y mantener un programa de medidas significativas que se basa en tres niveles:
objetivos, preguntas y métricas. El enfoque utiliza métricas para mejorar el proceso de desarrollo de software (y sus
productos de software resultantes), manteniendo la alineación con el negocio de la organización y objetivos técnicos
[14].
GQM se puede aplicar a todo ciclo de vida de productos, procesos y recursos. El enfoque fue desarrollado por
el Dr. Victor Basili y sus colegas durante la década de 1980, en relación con su trabajo en el Laboratorio de
Ingeniería de Software de la NASA (SEL), se perfeccionó en la década de 1990, y actualmente, sirve como marco
base para las iniciativas de medición. Es un medio adecuado para lograr datos empíricos fiables y conocimientos
acerca de las prácticas de software de la organización para impulsar el proceso de mejora sistemática. En este
contexto, es particularmente útil para los siguientes propósitos:
 Comprender y alinear las prácticas de una organización de software
 Orientar y supervisar los procesos de software
 Evaluación de las nuevas tecnologías de ingeniería de software
 Evaluación y certificación de las actividades de mejora
Aunque el objetivo principal de la práctica es la definición de métricas, el enfoque también se ocupa de la

recopilación de datos y experiencias y análisis e interpretación para su uso en futuras iniciativas. Estas actividades
son tan importantes como la definición de las métricas, ya que guían cómo los datos se utilizan realmente.
19
GQM sigue un proceso de seis pasos donde los tres primeros tratan de identificar las métricas a partir de las
metas del negocio y los tres últimos se basan en la recopilación de los datos de las medidas y su utilización eficaz en
la toma de decisiones. Los 6 pasos del proceso GQM se pueden ver en la figura 2.4 [14]
Figura 2.4: Pasos del método GQM
Para cada meta, puede haber varias preguntas y la misma pregunta se puede ligar a múltiples metas. De la
misma forma, para cada pregunta puede haber múltiples métricas y una métrica puede ser aplicable a más de una
pregunta. La figura 2.5 presenta un ejemplo de preguntas y métricas relacionadas con una meta [14].
20
Figura 2.5: Ejemplo de objetivos-preguntas-métricas de GQM
2.5.2. Sistema de Catalogación de Métricas e Indicadores con Potencia de Web Semántica
En las últimas décadas han surgido numerosas propuestas que definen conjuntos de métricas de calidad para la
evaluación de productos y procesos de software en distintos dominios de aplicación. También existen en la
actualidad algunos trabajos que proponen marcos conceptuales para la documentación de dichas métricas y catálogos
que brindan información de utilidad en los proyectos de medición y/o evaluación de software.
Sin embargo, no existe un consenso general sobre cómo ha de documentarse la información de métricas e
indicadores en forma efectiva, de manera de facilitar su explotación y aplicación a los procesos de medición y
evaluación, de manera consistente. Además, si bien existen documentos estándares que definen parcialmente la
terminología usada para el ámbito de modelos de calidad, métricas, y procesos de medición y evaluación [ISO9126,
ISO14598, ISO15939], no existe una terminología universal consensuada entre los investigadores del área, y en
consecuencia, la información relacionada proveniente de distintas fuentes no usa un mismo vocabulario, dificultando
su aplicación en forma generalizada.
El “Sistema de Catalogación de Métricas e Indicadores con potencia de Web Semántica”, intenta dar solución
a dichos problemas. Proporciona una ontología de métricas e indicadores que especifica un vocabulario común, con
una semántica bien definida, facilitando la interpretación de la información de métricas e indicadores en forma
uniforme, y permitiendo que puedan ser comparados los resultados obtenidos en distintos proyectos en forma
consistente. Además entrega la implementación de un sistema uniforme, permitiendo que puedan ser comparados los
resultados obtenidos en distintos proyectos en forma consistente. Por otro lado, la implementación de un sistema de
21
catalogación con potencia de web semántica, basado en dicha ontología, facilita la explotación e intercambio
consistente de información de métricas e indicadores tanto por parte de usuarios como por parte de aplicaciones,
agentes y herramientas automáticas en la Web. Dicho sistema de catalogación, fue implementado con tecnologías de
web semántica, adecuadas para proporcionar búsqueda y navegación semántica de modo de proveer “entendimiento”
automático de la información [11].
2.5.3. Cuadro de mando integral.
El concepto de Cuadro de Mando Integral – CMI (Balanced Scorecard – BSC) fue presentado en el número de
enero/febrero de 1992 de la revista Harvard Business Review, con base en un trabajo realizado para una empresa de
semiconductores. Sus autores, Robert Kaplan y David Norton, plantean que el CMI es un sistema de gestión o
sistema administrativo (management system), que va más allá de la perspectiva financiera con la que los gerentes
acostumbran evaluar la marcha de una empresa. [5]
El cuadro de mando intregral es un método para medir las actividades de una compañía en términos de su
visión y estrategia. Proporciona a los gerentes una mirada global del desempeño del negocio. Es una herramienta de
gestión de empresas que muestra continuamente cuándo una compañía y sus empleados alcanzan los resultados
definidos por el plan estratégico. También es una herramienta que ayuda a la compañía a expresar los objetivos e
iniciativas necesarias para cumplir con la estrategia. Es una herramienta para movilizar a la gente hacia el pleno
cumplimiento de la misión a través de canalizar las energías, habilidades y conocimientos específicos de la gente en
la organización hacia el logro de metas estratégicas de largo plazo. Permite tanto guiar el desempeño actual como
apuntar al desempeño futuro. Usa medidas en cuatro categorías -desempeño financiero, conocimiento del cliente,
procesos internos de negocios y, aprendizaje y crecimiento- para alinear iniciativas individuales, organizacionales y
trans-departamentales e identifica procesos enteramente nuevos para cumplir con objetivos del cliente y accionistas.
[5]
2. 6. A D AP T AB L E D O M AI N AN D P R O C E S S T E C H N O L O G Y E N GI N E E R I N G , A. D. A. P. T. E.
Esta tesis se enmarca dentro del proyecto FONDEF “A.D.A.P.T.E. Adaptable Domain and Process
Technology Engineering” Plataforma metodológica y tecnológica que apoya el mejoramiento de procesos en
PyMES de TICs[6].
A.D.A.P.T.E. es un proyecto I+D financiado por Fondef en el cual su principal objetivo es crear un
mecanismo de adaptación de procesos organizacionales de empresas de desarrollo de software a proyectos
específicos, para así entre, otras cosas, reducir los costos de realizar esta adaptación.
En A.D.A.P.T.E. participan tres universidades, éstas son:
22
 Universidad Técnica Federico Santa María
 Universidad de Chile
 Pontificia Universidad Católica de Valparaíso
A.D.A.P.T.E. se contextualiza en un amplio consenso acerca del valor de contar con procesos organizacionales
de desarrollo de software tanto para lograr procesos más controlables, como para mejorar la calidad de los productos.
Pero la conceptualización, definición e institucionalización de estos procesos en las organizaciones es un proceso
costoso y largo. La mayor parte de las empresas desarrolladoras de software en Chile son PyMEs, y si bien una
amplia mayoría de ellas coincide con el valor que los procesos podrían aportarles, sólo algunas pocas de ellas han
contado con los recursos para su definición. Más aún, contar con un proceso organizacional permite alcanzar los
beneficios de una certificación ISO o una evaluación CMMI, pero aún un único proceso no es apropiado para
abordar todos los proyectos de desarrollo dado que el proceso óptimo depende de las particularidades de cada
proyecto. Las variaciones pueden provenir del dominio de aplicación, la complejidad del sistema a desarrollar, las
competencias del equipo humano o el tiempo disponible. Por ello, aun teniendo procesos organizacionales definidos,
las empresas pueden no alcanzar todos los beneficios potenciales que podrían traer.
ADAPTE propone crear un mecanismo de definición de procesos organizacionales tal que capture la
variabilidad potencial, de modo que la adaptación a contextos específicos de proyectos de desarrollo sea rápida y no
requiera de personal altamente capacitado en ingeniería de procesos. También es necesario contar con la plataforma
tecnológica apropiada para dar soporte a cada proceso adaptado antes de poder ponerlo en práctica. La propuesta
también incluye un mecanismo para describir la plataforma tecnológica disponible dentro de una organización, y la
definición de un mecanismo para la selección del conjunto de estas herramientas que serán necesarias para ejecutar el
proceso específico del proyecto. El proyecto propone usar técnicas de Ingeniería Dirigida por Modelos (MDE) para
las distintas facetas de la solución.
Se definirán lenguajes específicos de dominio para:

 Definición de los procesos organizacionales incluyendo variabilidad.
 Caracterización de los contextos que permitan describir las particularidades de los proyectos.
Se definirán transformaciones de modelos para:
 Transformar procesos organizacionales a procesos adaptados a proyectos
 Definir plataformas específicas que permitan ejecutar el proceso adaptado.
Tanto para la definición de los modelos como para las transformaciones se construirán herramientas de apoyo
que facilitarán la adopción de los mecanismos propuestos por parte de las PyMEs. La propuesta se validará en cinco
PyMEs de software de Chile, y todo el conocimiento generado, así como las herramientas desarrolladas, serán de
dominio público [6].
23
3. SOLUCIÓN PROPUESTA
Parte importante de un proyecto de desarrollo de software es la medición y el control que se puede realizar
sobre éste. Es por esto que dado ciertos objetivos organizacionales se debe determinar que métricas medir y sobre
que entidades, para para poder medir distintas dimensiones del proyecto para controlar de mejor forma el
cumplimiento de los objetivos organizacionales.
Se propone generar la selección de métricas para un objetivo organizacional automática o semi-

automáticamente. Esta generación se realizará a través de una ontología que utilizando el concepto de semántica, y
recibiendo ciertos parámetros del objetivo y/o métricas, pueda inferir que métricas para utilizar realizar mediciones y
controlar el rendimiento del proyecto. Las métricas serán extraídas de un repositorio de métricas de software tal
como lo indica la figura 3.1.
Figura 3.1: Diagrama de solución
24
El sistema de inferencia se compone de una ontología que representa los conceptos de métricas y objetivos,
esta ontología se instancia en distintas entidades para lograr una interacción e instanciación de la misma y así generar
la comunicación e interpretación de los conceptos a nivel semántico.
3. 1. B Ú S Q U E D A S E M ÁN T I C A
La búsqueda semántica es un proceso utilizado para mejorar la búsqueda, en un contexto

específico, mediante el uso de datos de las redes semánticas para resolver las consultas y el texto de la web con la
finalidad de encontrar los resultados más relevantes en relación a la demanda del usuario [15].
La dificultad de este tipo de búsqueda recae en que para los seres humanos es fácil establecer equivalencias
semánticas entre diferentes expresiones pero este proceso no es evidente para los sistemas automatizados. Un sistema
de búsqueda semántica ideal tendría que emular un hipotético sistema de búsqueda humano con una memoria
suficientemente grande para recordar y relacionar todas las preguntas y respuestas anteriormente consultadas. Es
cierto que diferentes personas pueden dar diferentes respuestas a una misma pregunta pero por mucho que se
reformule la consulta la respuesta será similar ya que semánticamente serán consultas equivalentes.
Finalmente, el objetivo definitivo para un sistema artificial de búsqueda semántica será obtener los mismos
resultados y en el mismo orden de relevancia respecto a diferentes consultas semánticamente equivalentes.
3. 2. O N T O L O G Í A I N F O R M ÁT I C A
El término ontología en informática hace referencia a la formulación de un exhaustivo y riguroso esquema

conceptual dentro de uno o varios dominios dados; con la finalidad de facilitar la comunicación y el intercambio de
información entre diferentes sistemas y entidades. Aunque toma su nombre por analogía, ésta es la diferencia con el
punto de vista filosófico de la palabra ontología [17].
Un uso común tecnológico actual del concepto de ontología, en este sentido semántico, se encuentra en
la inteligencia artificial y en la representación del conocimiento. En algunas aplicaciones, se combinan
varios esquemas en una estructura de facto completa de datos, que contiene todas las entidades relevantes y sus
relaciones dentro del dominio.
Los programas informáticos pueden utilizar así, este punto de vista de la ontología, para una variedad de
propósitos, incluyendo el razonamiento inductivo, la clasificación, y una variedad de técnicas de resolución de
problemas.
25
Para que un computador interprete el modelo conceptual de la ontología es necesario programar las clases,
restricciones y reglas en un lenguaje de programación que pueda ser comprendido e interpretado en un software que
utilizándolo como base lógica de negocio genere información.
La ontología trabajada se basa en la arquitectura descrita en la figura 3.2, posee cuatro capas, la primera
incorpora las reglas y restricciones de inferencia, también llamada capa sintáctica donde se definen las entidades y
sus atributos, la segunda capa agrupa en forma de diagrama los conceptos y sus relaciones, se define también la
taxonomía de la ontología, la tercera capa incluye código de programación en RDF y SPARQL, éste es el que será
interpretado por el computador y proporciona la estructura base de los elementos pertenecientes a la ontología
definiendo su estructura, la última capa corresponde al sistema de software que lo interprete y genere una
visualización.
Figura 3.2: Arquitectura ontológica de la solución
3. 3. C A P A L Ó G I C A : R E GL AS DE IN FER ENCI A
En lógica, una regla de inferencia es un esquema para construir inferencias válidas. Estos esquemas establecen
relaciones sintácticas entre un conjunto de fórmulas llamados premisas y una aserción llamada conclusión [16].
Estas relaciones sintácticas son usadas en el proceso de inferencia, por el que se llega a nuevas aserciones
verdaderas a partir de otras ya conocidas. Las reglas también se aplican a la lógica informal y a las discusiones, pero
la formulación es mucho más difícil y polémica.
26
Como se mencionó, la aplicación de una regla de inferencia es un procedimiento puramente sintáctico. Sin
embargo, debe también ser válido, o mejor dicho, preservar la validez. Para que el requisito de preservación de la
validez tenga sentido, es necesaria una cierta forma semántica para las aserciones de las reglas de inferencia y las
reglas de inferencia en sí mismas.
Para el sistema de métricas y objetivos organizacionales se define la estructura de cada entidad-concepto

perteneciente al contexto y alcance de la ontología. Para cada entidad se define la sintaxis, la forma como está
definida. Un concepto es clasificado como una u otra entidad en base a si cumple o no la sintaxis especificada.
La sintaxis de cada entidad de la ontología se define en la siguiente tabla:
Tabla 3.1: Sintaxis de entidades de ontología
Entidad Atributos(Tipo de datos)
Métrica Nombre(String), Descripción(String), Tipo de Métrica(TipoDeMétrica), Proceso de

Medición(ProcesoDeMedición), Unidad de Medida(UnidadDeMedida), Objetivo de
Métrica (Objetivo)
Proceso de Nombre(String), Descripción(String), Metodología(String), Actividades

Medición (ActividadDeMedición)
Actividad de Nombre(String), Descripción(String), Entidad Medible (EntidadMedible)

Medición
Entidad Medible Nombre(String), Descripción(String), Atributo Medible(AtributoMedible)
Atributo Medible Nombre(String), Descripción(String), Valor atributo (String), Unidad de Medida

(UnidadDeMedida)
Unidad de Medida Nombre(String), Descripción(String), abreviación (String)
Objetivo Nombre(String), Descripción(String), Motivación (Motivación)
Motivación Nombre(String), Descripción(String)
Organización Nombre(String), Descripción(String), Visión(String), Misión(String),

Objetivos(Objetivo), Productos(Producto)
27
Proceso Productivo Nombre(String), Descripción(String), Actividades (ActividadDeProceso)
Actividad de Nombre(String), Descripción(String), Entregable(EntidadMedible)

Proceso
Producto Nombre(String), Descripción(String), Proceso Productivo(ProcesoProductivo)
3. 4. C A P A O N T O L Ó G I C A
3.4.1. Relaciones Conceptuales
Las relaciones conceptuales son los vínculos que conectan a los conceptos entre sí. Hay dos de ellas que tienen
particular relevancia para la organización del conocimiento conceptual: las taxonómicas y las temáticas.
Los conceptos son construcciones o imágenes mentales, por medio de las cuales se
comprenden las experiencias que emergen de la interacción con el entorno. En este contexto, se utiliza la palabra
“Concepto” para referirse a cada entidad perteneciente a la ontología. Cada entidad descrita, hace referencia
lógicamente a un concepto del dominio tratado.
En la siguiente tabla se definen las relaciones entre los conceptos y la descripción de esta relación. Cada
concepto estará encerrado por paréntesis corchetes, por ejemplo: [concepto].
Tabla 3.2: Definición de conceptos de capa ontológica
Relación Descripción
[Métrica] se mide [Proceso de Relación entre la métrica y el proceso de medición que provee el método
medición] para que la métrica sea aplicada.
[Métrica] se expresa en Relación entre la métrica y la unidad de medida en la que se expresa la

[Unidad de medida] misma.
[Métrica] tiene [Objetivo] Relación entre la métrica y el objetivo de medición de ésta.
[Proceso de Medición] Relación entre el proceso de medición y las actividades del proceso, un
contiene [Actividad de Medición] proceso puede tener muchas actividades.
28
[Actividad de Medición] se Relación entre la actividad y la entidad sobre la cual se aplica la
aplica sobre [Entidad Medible] medición.
[Entidad Medible] posee Relación entre la entidad medible y los atributos de la entidad que son
[Atributos Medibles] parte del proceso de medición.
[Atributos Medibles] se Relación entre los atributos y la unidad de medida de los mismos.
expresa en [Unidad de Medida]
[Objetivo] tiene [Motivación] Relación entre los objetivos y la motivación de cada uno de ellos.
[Organización] tiene Relación entre la organización y los objetivos de ésta.

[Objetivo]
[Organización] Utiliza Relación entre la organización y el proceso productivo que utiliza.

[Proceso Productivo]
[Organización] produce Relación entre la organización y los productos que produce.

[Producto]
[Proceso Productivo] produce Relación entre el proceso productivo y el producto que produce éste.
[Producto]
[Proceso Productivo] contiene Relación entre el proceso productivo y las actividades o tareas del mismo.
[Actividad de Proceso]
[Producto] Entrega [Entidad Relación entre el producto y la entidad medible y cuantificable para
Medible] obtener métricas.
Representando las relaciones conceptuales en un diagrama tipo árbol se obtiene la figura 3.3, a través de esta
representación se puede distinguir a simple vista como los conceptos se relacionan unos con otros para dar origen a
una ontología en un dominio dado: medición y objetivos organizacionales.
29
Figura 3.3: Relaciones conceptuales de la ontología
30
3.4.2. Diagrama de clases de ontología Métricas-Objetivos
El siguiente diagrama representa en clases, las descripciones sintácticas y conceptuales de los elementos de
la ontología, describe la estructura relacional y cardinalidad entre las entidades. Cabe destacar que este modelo será
utilizado para representar las entidades en la aplicación Java, a través de entidades de negocio, como en la capa
programación RDF a través de nodos.
Figura 3.4: Diagrama de clases ontología métricas-objetivos
31
3.4.3. Métricas instanciables en el modelo
Existen distintos tipos de métricas medibles en un proyecto de software. Para lograr medir efectivamente, se
debe tener un marco de referencia de la medición, es decir con qué se está comparando la medición.
Dependiendo del tipo de métrica se puede determinar por ejemplo: el avance del proyecto, recursos destinados,
trabajo repetido, la calidad del producto desarrollado. Estas métricas se deben comparar con el marco de referencia
para hacerlas objetivas y obtener información útil para la toma de decisiones.
Métricas de Proyecto de Software
Tabla 3.3: Definición de métrica Progreso del proyecto
Característica Definición
Nombre Progreso del proyecto (general)
Descripción % de avance (retraso) del proyecto expresado en tiempo
Objetivo Controlar progreso del proyecto
Motivación Mejorar gestión de los proyectos
Tipo de métrica Métrica cuantitativa
Plan de trabajo del Proyecto
Entidad medible
Artefactos de construcción
Número total de actividades del proyecto
Atributos medibles Número de actividades del proyecto completas
Número de módulos construidos
Unidad de medida Porcentaje
Se debe comparar la planificación esperada con el avance real del
proyecto de software. Por cada actividad del proceso de desarrollo.Para esto se
debe evaluar el número de actividades/módulos desarrollados en base al total
del proyecto.
Proceso de medición
Calcular en porcentaje el número de actividades completadas sobre el
total de ellas y comparar el resultado con el porcentaje de avance esperado a la
fecha, basado en la estimación inicial. En base a eso determinar el grado de
adelanto, retraso o cumplimiento de la planificación y tomar, en caso de ser
necesario, las medidas correctivas
32
Tabla 3.4: Definición de métrica Recursos utilizados
Característica
Nombre Recursos utilizados expresados en hora-hombre (HH)
Descripción % de uso de recursos humanos en el proyecto
Objetivo Controlar avance del proyecto
Motivación Mejorar la gestión de los recursos humanos para los proyectos
Entidad medible Recursos humanos
Horas -Hombre asignadas al proyecto
Atributos medibles
Horas -Hombre necesarias para el proyecto
Se debe determinar el número de HH usadas en comparación con las
Proceso de medición necesarias, para determinar el uso y falta de recursos, además de tiempos
muertos en la asignación
Métricas de Desarrollo de Software
Tabla 3.5: Definición de métrica Trabajo repetido, no reutilización
Nombre Trabajo repetido, no reutilización, sobre uso de recursos
Determinar % de trabajo repetido en el desarrollo para evaluar posibles
Descripción mejoras en proceso de desarrollo tales como etapa de diseño para aplicar
reutilización de componentes
Objetivo Controlar trabajo repetido en el desarrollo
Entidad medible Producto Software
Atributos medibles Artefactos, diagramas, código, scripts, interfaces, informes
Para determinar el trabajo repetido se deben tomar datos de entrada de las
versiones del artefacto a medir, estas versiones pueden ser de 2 tipos, versiones
Proceso de medición evolutivas en las cuales se mejoró o avanzó, y versiones correctivas donde se
detectaron defectos que fue necesario reparar, estas versiones correctivas son las
que entran en la categoría de trabajo repetido, también puede aplicarse a los
33
errores (bugs) de análisis, diseño o programación.
Se debe contar el número de revisiones del encargado o superior y en

base a eso calcular el tiempo usado en repetición de tareas, intersectar la
dimensión tiempo repetido con tiempo planificado. Se pueden obtener 2
mediciones: Trabajo repetido dentro de plazo y trabajo repetido fuera del plazo.
Tabla 3.6: Definición de métrica Reutilización de componentes
Nombre Reutilización de componentes
Descripción % de reutilización en el desarrollo
Determinar rendimiento del proceso a partir de reutilización de
Objetivo
componentes
Motivación Mejorar procesos de desarrollo a partir de la reutilización y planificación
Entidad medible Productos Software
Artefactos de desarrollo
Diagramas de diseño
Atributos medibles
Códigos fuente y scripts
Entregables tipo informe
Identificar para cada elemento del proyecto software si se utilizó algún %
de elementos de otro proyecto anterior. Se deben calcular todos los % de
reutilización para luego obtener el % total del proyecto y con esto el % de
recursos ahorrados.
Se debe identificar el % de módulos, diagramas, código que reutilizaron
respecto al total de la entidad. Es decir, de 100 diagramas se reutilizan 5 (5%).
Al determinar el % de reutilización se puede determinar las HH ahorradas y los
recursos no usados.
34
Métricas de Mantenimiento/Soporte de Software
Tabla 3.7: Definición de métrica Tiempo de respuesta de soporte
Nombre Tiempo de respuesta de soporte, post venta
El tiempo de respuesta post venta determina la calidad del servicio luego
Descripción de entregar el producto al cliente. Medido en base al tiempo utilizado en
corrección de bugs y resolución del problema
Controlar tiempo de resolución de problemas post venta, soporte y
Objetivo
garantía
Motivación Aumentar satisfacción del cliente para mantener relación comercial
Unidad de medida Tiempo
Número de Bugs reportados
Atributos medibles
Tiempo de resolución por bug
Identificar la calidad del servicio post venta a través del registro de
tiempo en solucionar problemas al cliente.
Se debe documentar la fecha/tiempo de entrada de la corrección y de la

salida del producto corregido, con esto determinar el tiempo de corrección para
obtener un indicador de la calidad del servicio. Además, se puede determinar
por qué surgió el error, en qué etapa de desarrollo, quién es el responsable y
cuántos recursos se desperdiciaron.
Tabla 3.8: Definición de métrica Número de bugs por programador
Nombre Número de bugs por programador
Determina el número de errores de programación luego de que el sistema
Descripción software es puesto en producción o dicho de otra forma pasa uso oficial del
cliente
Objetivo Trazar bugs para mejorar habilidades de programadores
Motivación Aumentar calidad de producto final
35
Unidad de medida Bugs por programador
Atributos medibles Número de Bugs reportados
Identificar qué programador(es) participan en desarrollo de módulos de
sistema que presentan bugs reportados por área QA o por el cliente
3. 5. C A P A P R O G R AM AC I Ó N
3.5.1. Framework Apache Jena
Apache Jena es un framework Java para construir aplicaciones basadas en ontologías. Jena se desarrolló en
HP Labs en el 2000, en 2009 HP cedió el proyecto a la fundación Apache que decidió adoptarlo en noviembre de
2010.
Su Arquitectura incluye [18]:

 API para trabajar (leer, procesar, escribir) ontologías RDF y OWL
 Motor de inferencia para razonar sobre ontologías RDF y OWL
 Estrategias de almacenamiento flexible para almacenar tripletas RDF en memoria o fichero
 Motor de queries compatible con especificación SPARQL
3.5.2. Framework de Descripción de recursos, RDF
RDF es un formato de datos para grafos dirigidos etiquetados, que permite representar información en la
Web. Normalmente, RDF se utiliza, entre otros usos, para representar información personal, redes sociales,
metadatos sobre objetos digitales, así como para proporcionar un medio para la integración de fuentes de
información dispares. Esta especificación define la sintaxis y la semántica de SPARQL, un lenguaje de consulta para
RDF [19].
3.5.3. Descripción RDF de Ontología
La Ontología fue definida utilizando el software Protegé de la figura 3.5 [20] , a partir de él se genera el XML
descrito en el anexo de la sección 7 de este informe.
36
Figura 3.5: Software de desarrollo ontológico Protegé.
3.5.4. Lenguaje de consulta SPARQL
SPARQL es un acrónimo recursivo del inglés SPARQL Protocol and RDF Query Language. Se trata de un
lenguaje estandarizado para la consulta de grafos RDF, normalizado por el RDF Data Access Working Group
(DAWG) del World Wide Web Consortium (W3C). Es una tecnología clave en el desarrollo de la Web Semántica
que se constituyó como Recomendación oficial del W3C el 15 de Enero de 2008 [21].
Al igual que sucede con SQL, es necesario distinguir entre el lenguaje de consulta y el motor para el
almacenamiento y recuperación de los datos. Por este motivo, existen múltiples implementaciones de SPARQL,
generalmente ligados a entornos de desarrollo y plataforma tecnológicas.
En un principio SPARQL únicamente incorporó funciones para la recuperación sentencias RDF. Sin
embargo, algunas propuestas también incluyen operaciones para el mantenimiento (creación, modificación y
borrado) de datos.
37
3.5.5. Querys SPARQL
El lenguaje de consulta SPARQL utiliza consultas tipo SQL clásico, en las siguientes consultas se busca
un objetivo y una métrica respectivamente.
Query de búsqueda de objetivos al ingresar Métrica de medición

Para la siguiente consulta determina un objetivo en el modelo RDF, define un objetivo como sujeto y sobre
el cual posee, organización, motivación, nombre de la métrica, descripción y tipo de métrica, dado estos parámetros,
la consulta debe devolver los objetivos que cumplen las condiciones especificadas.
PREFIX rdf: <http://www.owl-ontologies.com/OntologiaMetricasObjetivos.owl>
SELECT ?objetivo dcterms:subject rdf:Objetivo
WHERE{
? objetivo rdf:es_de rdf:Organizacion
? objetivo rdf:lo_motiva rdf:Motivacion
? objetivo rdf:nombre rdf:Metrica:nombre
? objetivo rdf:descripción rdf:Metrica:descripcion
? objetivo rdf:tiene_tipo rdf:Metrica:tipoMetrica
Query de búsqueda de métricas al ingresar Objetivo Organizacional

Para la siguiente consulta, se buscan las métricas en el modelo RDF de la ontología, para ello se le entregan
los parámetros, proceso de medición, unidad de medida, objetivo de la métrica, nombre del objetivo y descripción
del objetivo.
PREFIX rdf: <http://www.owl-ontologies.com/OntologiaMetricasObjetivos.owl>
SELECT ?metrica dcterms:subject rdf:Metrica
WHERE{
?metrica rdf:se_mide_con rdf:procesoDeMedicion
?metrica rdf:tiene_unidad rdf:unidadDeMedida
?metrica rdf:posee rdf:objetivo
?metrica rdf:nombre rdf:Objetivo:nombre
?metrica rdf:descripción rdf:Objetivo:descripcion
38
3. 6. S I S T E M A DE IN FER ENCI A
3.6.1. Tecnologías utilizadas
Para el desarrollo del sistema de inferencia de utilizaron las siguientes tecnologías:
 JavaServer Faces (JSF) es una tecnología y framework para aplicaciones Java basadas en web que simplifica el
desarrollo de interfaces de usuario en aplicaciones Java EE. JSF incluye: un conjunto de APIs para representar
componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entrada, definir un
esquema de navegación de las páginas y dar soporte para internacionalización y accesibilidad, componentes para
la interfaz de usuario, dos bibliotecas de etiquetas personalizadas para JavaServer Pages que permiten expresar
una interfaz JavaServer Faces dentro de una página JSP, un modelo de eventos en el lado del servidor y Beans
administrados [22].
 PrimeFaces: es un componente para JavaServer Faces (JSF) de código abierto que cuenta con un conjunto de
componentes ricos que facilitan la creación de las aplicaciones web. Provee un conjunto de componentes ricos
(Editor de HTML, autocompletar, cartas, gráficas o paneles, entre otros), soporte de AJAX con despliegue
parcial, lo que permite controlar cuáles componentes de la página actual se actualizarán y cuáles no y
componentes para desarrollar aplicaciones web para móviles-celulares, especiales para Iphones,
Palm, Android y teléfonos móviles Nokia [23].
 MySQL: es un sistema de gestión de bases de datos relacional, multihilo y multiusuario con más de seis
millones de instalaciones. Permite comunicación con Java a través de una implementación nativa del driver de
Java para MySql [24].
3.6.2. Arquitectura del sistema
La arquitectura del sistema de inferencia se basa en 3 capas que dividen la carga de la aplicación. Estas capas
corresponden a las descritas en la figura 3.6.
a. Presentación: Es la capa encargada de presentar los datos, controlar la navegación del sistema, validar las
entradas de datos, informar al usuario con alertas, etc. En el Sistema se ordena de la siguiente forma:
 Las paginas JSF (XHTML) arman como se ve una vista, utilizando principalmente componentes de
Primefaces. La lógica Java de las páginas se realiza en unos componentes llamados Beans.
 Las validaciones se logran principalmente por el Framework JSF que se integra con la tecnología de
Beans Validators, la cual permite a través de anotaciones centralizar la validación de datos en el
modelo de la aplicación.
39
b. Lógica de Negocio: Recibe las solicitudes de la presentación y las responde, realiza toda la funcionalidad
de negocio del sistema (validaciones de negocio, manejo de transacciones, etc.). Accede a la capa de
accesos a datos.
c. Base de Datos: Todo el manejo de tablas, registros, índices y datos almacenados.
Figura 3.6: Arquitectura de la solución
3.6.3. Modelo de datos
La capa de datos consiste en una instancia del modelo relacional de datos que soporta la persistencia de las
entidades de la ontología. El modelo se basa en 3 tablas principales: Métricas, Objetivos y Códigos. Una métrica
puede poseer muchos códigos y un código relacionarse con muchas métricas por lo que existe una tabla relación
Met_Cod que normaliza la relación. Esta misma lógica se aplica a las tablas Objetivos y Códigos en donde se crea
una tabla relación Obj_Cod. Al momento de relacionar una métrica con un objetivo esto se persiste en la tabla
relación Met_Obj, ver figura 3.7.
40
Figura 3.7: Modelo relacional de base de datos
3.6.4. Interfaces de usuario
Las interfaces de usuario corresponden a la capa de interacción con los usuarios del sistema de inferencia.
Estas pueden ser revisadas en el capítulo 7 ANEXOS.
41
4. CASO DE ESTUDIO
4. 1. M E T O D O L O G Í A DE V AL I D AC I Ó N
Para realizar la validación de la propuesta, se prueba la solución en una empresa para comprobar el correcto
funcionamiento de las relaciones ontológicas determinadas e implementadas en el sistema de inferencia. Para ello se
realiza una prueba en una empresa informática, esta empresa es ZEKE Ltda. Cabe destacar que las pruebas se
realizan con la finalidad de validar la ontología y su correcto sentido de inferencia y no evaluar entre otras cosas,
usabilidad de la aplicación, rendimiento ni diseño.
El sistema de inferencia para métricas y objetivos está orientado para usuarios que trabajan en el diseño de
planes estratégicos, determinación de objetivos empresariales, y confección de planes de acciones futuras. El
usuario seleccionado corresponde al Gerente General de Zeke Ltda. Sr. Gonzalo Romero. La prueba realizada
comprende la utilización del sistema con datos reales ingresados por el Sr. Gonzalo Romero.
Las secciones del caso de estudio están divididas en los datos de la empresa participante correspondiente a la
sección 4.2, la sección 4.3 de métricas pre-ingresadas al sistema, 4.4 corresponde a las métricas ingresadas por el
usuario de prueba, 4.5 corresponden a los objetivos ingresados por el usuario, la sección 4.6 corresponde a las
relaciones encontradas por el sistema, y la sección 4.7 corresponde al análisis de las relaciones encontradas.
4. 2. D A T O S D E L A E M P R E S A P AR T I C I P A N T E D E L C A S O D E E S T U D I O
Tabla 4.1: Datos de empresa participante en caso de estudio
Nombre Organización Zeke Ltda.
ZEKE es una empresa dedicada al desarrollo de software a medida,
implantación de soluciones de Inteligencia de Negocios, Sistemas de Gestión
Documental, Soporte y Mantención de Sistemas, y Automatización de
Procesos de Negocios, además de entregar asesorías a proyectos de
Descripción
diversa índole. El principal compromiso con los clientes es entregar un servicio
con altos estándares de eficiencia y calidad, lo que ha impulsado a ZEKE a
certificar todos sus procesos. Actualmente ZEKE se encuentra certificado en
la Norma ISO 9001:2008 por parte del Grupo Bureau Veritas.
Proveer a nuestros clientes de soluciones innovadoras y servicios
Misión
informáticos de calidad, que permitan agregar valor a su negocio.
42
Ser una empresa confiable y reconocida por la calidad de sus soluciones,
Visión con una gestión que se anticipe y adapte al cambio, aprenda de la experiencia e
innove permanentemente.
4. 3. M É T R I C A S P R E - I N G R E S A D A S AL SI ST EM A
Tabla 4.2: Métrica pre-ingresada al sistema, Progreso del Proyecto
Nombre Progreso del proyecto (general)
Descripción % de avance (retraso) del proyecto expresado en tiempo
Objetivo Controlar progreso del proyecto
Motivación Mejorar gestión de los proyectos
Plan de trabajo del Proyecto
Entidad medible
Artefactos de construcción
Número total de actividades del proyecto
Atributos medibles Número de actividades del proyecto completas
Número de módulos construidos
Se debe comparar la planificación esperada con el avance real del
proyecto de software, por cada actividad del proceso de desarrollo.
Para esto se debe evaluar el número de actividades/módulos desarrollados
en base a al total del proyecto.
Calcular en porcentaje el número de actividades completadas sobre el
total de ellas y comparar el resultado con el porcentaje de avance esperado a la
fecha, basado en la estimación inicial. En base a eso determinar el grado de
adelanto, retraso o cumplimiento de la planificación y tomar, en caso de ser
necesario, las medidas correctivas.
43
Tabla 4.3: Métrica pre-ingresada al sistema, Recursos utilizados
Característica
Nombre Recursos utilizados expresados en hora-hombre (HH)
Descripción % de uso de recursos humanos en el proyecto
Objetivo Controlar avance del proyecto
Motivación Mejorar gestión de los recursos humanos para los proyectos
Entidad medible Recursos humanos
Horas -Hombre asignadas al proyecto
Atributos medibles
Horas -Hombre necesarias para el proyecto
Se debe determinar el número de HH usadas en comparación con las
Proceso de medición necesarias, para determinar el uso y falta de recursos, además de tiempos
muertos en la asignación.
Tabla 4.4: Métrica pre-ingresada al sistema, Trabajo repetido
Nombre Trabajo repetido, no reutilización, sobre uso de recursos
Determinar % de trabajo repetido en el desarrollo para evaluar posibles
Descripción mejoras en proceso de desarrollo tales como etapa de diseño para aplicar
reutilización de componentes.
Objetivo Controlar trabajo repetido en el desarrollo
Atributos medibles Artefactos, diagramas, código, scripts, interfaces, informes.
Para determinar el trabajo repetido se deben tomar datos de entrada de las
versiones del artefacto a medir, estas versiones pueden ser de 2 tipos, versiones
evolutivas en las cuales se mejoró o avanzó, y versiones correctivas donde se
Proceso de medición detectaron defectos que fue necesario reparar, estas versiones correctivas son las
que entran en la categoría de trabajo repetido, también puede aplicarse a los
errores (bugs) de análisis, diseño o programación.
Se debe contar el número de revisiones del encargado o superior y en
44
base a eso calcular el tiempo usado en repetición de tareas, intersectar la
dimensión tiempo repetido con tiempo planificado. Se pueden obtener 2
mediciones: Trabajo repetido dentro de plazo y trabajo repetido fuera del plazo.
Tabla 4.5: Métrica pre-ingresada al sistema, Reutilización de componentes
Nombre Reutilización de componentes
Descripción % de reutilización en el desarrollo
Determinar rendimiento del proceso a partir de reutilización de
Objetivo
componentes.
Motivación Mejorar procesos de desarrollo a partir de la reutilización y planificación.
Entidad medible Productos Software
Artefactos de desarrollo
Diagramas de diseño
Atributos medibles
Códigos fuente y scripts
Entregables tipo informe
Identificar para cada elemento del proyecto software si se utilizó algún %
de elementos de otro proyecto anterior. Se deben calcular todos los % de
reutilización para luego obtener el % total del proyecto y con esto el % de
recursos ahorrados.
Se debe identificar el % de módulos, diagramas, código que se reutilizó
respecto al total de la entidad. Es decir, de 100 diagramas se reutilizan 5 (5%).
Al determinar el % de reutilización se puede determinar las HH ahorradas y los
recursos no usados.
45
Tabla 4.6: Métrica pre-ingresada al sistema, Tiempo de respuesta de soporte
Nombre Tiempo de respuesta de soporte, post venta.
El tiempo de respuesta post venta determina la calidad del servicio luego
Descripción de entregar el producto al cliente. Medido en base al tiempo utilizado en
corrección de bugs y resolución del problema.
Controlar tiempo de resolución de problemas post venta, soporte y
Objetivo
garantía.
Motivación Aumentar satisfacción del cliente para mantener relación comercial.
Unidad de medida Tiempo
Número de Bugs reportados
Atributos medibles
Tiempo de resolución por bug
Identificar la calidad del servicio post venta a través del registro de
tiempo en solucionar problemas al cliente.
Se debe documentar la fecha/tiempo de entrada de la corrección y de la

salida del producto corregido, con esto determinar el tiempo de corrección para
obtener un indicador de la calidad del servicio. Además, se puede determinar
por qué surgió el error, en qué etapa de desarrollo, quién es el responsable y
cuántos recursos se desperdiciaron.
Tabla 4.7 Métrica pre-ingresada al sistema, Número de bugs por programador
Nombre Número de bugs por programador
Determina el número de errores de programación luego de que el sistema
Descripción software es puesto en producción o dicho de otra forma para uso oficial del
cliente.
Objetivo Trazar bugs para mejorar habilidades de programadores.
Motivación Aumentar calidad de producto final.
Unidad de medida Bugs por programador
Atributos medibles Número de Bugs reportados
46
Identificar qué programador(es) participan en desarrollo de módulos de
sistema que presentan bugs reportados por área QA o por el cliente.
4. 4. M É T R I C A S I N G R E S A D A S P O R U S U AR I O
Tabla 4.8: Métrica ingresada por usuario, Ventas anuales
Nombre Ventas anuales
Descripción Número de proyectos en pesos vendidos en un año en particular
Objetivo Determinar crecimiento a nivel de desarrollo de proyectos de la empresa.
Motivación Controlar y comparar el crecimiento de la empresa.
Entidad medible Proyectos vendidos
Unidad de medida Pesos
Cantidad de proyectos vendidos
Atributos medibles
Costo de proyectos vendidos
Suma de todos los proyectos generados en un año y de su costo, se debe
Proceso de medición realizar la comparación con igual período anterior para determinar aumento o
reducción de crecimiento de la empresa.
Tabla 4.9: Métrica ingresada por usuario, Personal capacitado al año
Nombre Personal capacitado en el año
Considera el número de personas que se han enviado a cursos externos
Descripción
para mejorar su desempeño
Objetivo Determinar número de personas capacitadas y en qué tecnologías.
Ayudar a desarrolladores a mejorar su trabajo para aumentar calidad del
Motivación
producto.
Entidad medible Recursos humanos capacitados en el período
Personas capacitadas
Atributos medibles
Certificaciones otorgadas
47
Tecnologías aprendidas
Herramientas aprendidas
Obtener porcentaje del total de personas capacitadas en base al total de
personas de la empresa.
4. 5. O B J E T I VO S I N GRE S ADOS PO R U SU ARIO
Tabla 4.10: Métrica ingresada por usuario, Objetivo visión Zeke
Nombre Visión Zeke
Ser una empresa confiable y reconocida por la calidad de sus soluciones,
Descripción con una gestión que se anticipe y adapte al cambio, aprenda de la experiencia e
innove permanentemente.
Motivación Guía a largo plazo de acciones a seguir por Zeke
Tipo Cualitativo
Tabla 4.11: Métrica ingresada por usuario, Mantener una tasa de crecimiento
Nombre Mantener una tasa de crecimiento constante en número de proyectos
Se espera tener un incremento en los proyectos que permita a la empresa
Descripción ir creciendo en el tiempo, y que este incremento pueda ser absorbido con los
recursos que actualmente cuenta la empresa.
Motivación Tener un crecimiento sustentable en el tiempo
Tipo Cuantitativo
Tabla 4.12: Métrica ingresada por usuario, Impulsar la mejora técnica en el personal
Nombre Impulsar la mejora técnica en cada uno de los integrantes de Zeke
Es necesario contar con personal que pueda hacer frente a los distintos
Descripción
tipos de tecnologías con que se deben realizar los proyectos. Además se deben
48
poder adaptar a tecnologías, frameworks o lenguajes desconocidos
Permitir a la empresa adaptarse a los cambios tecnológicos, poder
Motivación
ejecutar proyectos demandados por el mercado.
Tipo Cualitativo
Tabla 4.13: Métrica ingresada por usuario, Incorporar nuevas áreas de negocio en la empresa
Nombre Incorporar nueva áreas de negocio en la empresa
Tiene como propósito diversificar la fuente de ingresos de la empresa,
Descripción
para explorar otras áreas diferentes al desarrollo de software.
Motivación Contar con fuentes alternativas de ingreso.
Tipo Cualitativo
Tabla 4.14: Métrica ingresada por usuario, Disminuir los defectos en el software entregado a clientes
Nombre Disminuir los defectos en el software entregado a clientes
Se requiere generar una nueva estrategia de revisión de los productos
Descripción entregados que vaya más allá de las pruebas funcionales y que considere la
estructura interna de los entregables.
Se desea disminuir los defectos en el software entregado para evitar los
Motivación
problemas de recursos con los proyectos nuevos ejecución.
Tipo Cualitativo
Tabla 4.15: Métrica ingresada por usuario, Reducir tiempos extra en desarrollo de proyectos
Reducir tiempos extra en desarrollo de proyectos, controlar y estimar
Nombre
correctamente duración y fuera de plazo.
Se requiere implementar estrategias de control para aumentar la eficacia
Descripción de la planificación y reducir costos de proyecto en tiempo y en recursos
humanos.
49
Se desea disminuir costos de proyectos realizando una mejor
Motivación
planificación y controlándola adecuadamente.
Tipo Cualitativo
4. 6. R E L A C I O N E S ENC ONTR AD AS M É T R I C A S -O B J E T I V O
Tabla 4.16: Relaciones encontradas Métrica-Objetivo
Nombre Métrica Nombre Objetivo

Disminuir los defectos en el software entregado
Reutilización
a clientes.
Mantener una tasa de crecimiento constante en
Ventas anuales.
número de proyectos.
Impulsar la mejora técnica en cada uno de los
Personal capacitado en el año
integrantes de Zeke.
Trabajo repetido Incorporar nueva áreas de negocio en la empresa
Reducir tiempos extra en desarrollo de

Reutilización proyectos, controlar y estimar correctamente duración
y fuera de plazo.
Disminuir los defectos en el software entregado
Número de bugs por programador.
a clientes
50
4. 7. A N ÁL I S I S DE R E S U L T AD O S
El usuario de prueba realiza 2 ingresos de métricas al sistema y 5 de objetivos organizacionales de Zeke Ltda.
Al realizar estas acciones el sistema logra generar asociación entre algunas métricas y su análisis se detalla a
continuación:
4.7.1. Análisis 1
Métrica: Reutilización
Objetivos: Disminuir los defectos en el software entregado a clientes.
El objetivo ingresado hace relación a la calidad de los productos desarrollados por la empresa y para esto el
sistema infiere que se necesita utilizar una métrica de reutilización. Se entiende que el sistema asume que reutilizar
componentes en distintos sistema proporciona un conjunto probado de elementos que carecen de defectos y favorece
al cumplimiento del objetivo propuesto.
4.7.2. Análisis 2
Métrica: Ventas anuales

Objetivo: Mantener una tasa de crecimiento constante en número de proyectos.
Mantener una tasa de crecimiento constante, estable y controlable se ha asociado con la métrica de ventas
anuales. Esta relación se asume correcta desde el punto de vista de que la tasa de crecimiento está relacionada con el
valor de ventas anuales.
4.7.3. Análisis 3
Métrica: Personal capacitado en el año

Objetivo: Impulsar la mejora técnica en cada uno de los integrantes de Zeke.
El sistema infiere que para impulsar la mejora de los integrantes desarrolladores de software en la empresa es
necesario realizar un control sobre el personal capacitado en el año, cuántos son y dependiendo de la especificación
de la medición determinar el grado de conocimientos adquiridos.
51
4.7.4. Análisis 4
Métrica: Trabajo repetido

Objetivo: Incorporar nuevas áreas de negocio en la empresa
El sistema infiere que para incorporar nuevas áreas de negocio es necesario controlar el trabajo repetido, se
puede interpretar esta asociación como una asignación errónea por parte del sistema.
4.7.5. Análisis 5
Métrica: Reutilización
Objetivo: Reducir tiempos extra en desarrollo de proyectos, controlar y estimar correctamente duración
y fuera de plazo.
El sistema infiere que medir reutilización es una estrategia de control adecuada para reducir tiempos de
desarrollo, lo que es completamente válido.
4.7.6. Análisis 6
Métrica: Número de bugs por programador.

Objetivo: Disminuir los defectos en el software entregado a clientes
Al ingresar una nueva métrica, “Número de bugs por programador”, el sistema infiere que ésta se relaciona
con un objetivo determinado anteriormente “Disminuir los defectos en el software entregado a clientes”, esta
determinación desde métrica a objetivo es correcta ya que controlando los bugs por programador es posible aumentar
la calidad del producto de software final.
4.7.7. Resultados Obtenidos
Luego de interpretado el análisis de las asociaciones métrica-objetivo generado por el sistema se obtiene lo
siguiente:
Número de métricas pre-ingresadas al sistema: 6

Número de métricas ingresadas por el usuario: 2
Numero de objetivos ingresados por el usuario: 6
52
Asociaciones realizadas por el sistema: 6
Asociaciones correctas: 5 (83.4%)
Asociaciones incorrectas: 1 (16.6%)
Figura 4.1: Gráfico de Resultados
Según los resultados obtenidos el 83,4 % de las relaciones obtenidas a partir del sistema de inferencia, se
realizaron correctamente, y sólo el 16,6% fue incorrecto.
Al determinar por qué el sistema realiza asociaciones incorrectas se llega a la conclusión de que existen
atributos-palabras dentro del modelo que podrían “confundir” al sistema de inferencia. Una posible solución a esto
corresponde a pre-procesar los datos indicando al sistema si existen las denominadas ”palabras vacías” que
corresponden a palabras sin significado como artículos, pronombres, preposiciones, etc. que son filtradas antes o
después del procesamiento de datos en lenguaje natural (texto). En un trabajo futuro es posible abordar dentro del
modelo palabras determinadas que interfieren con la semántica.
Por otro lado, la conceptualización del dominio dado en la ontología detallada en el capítulo 3, provee del
marco conceptual necesario para encapsular los requerimientos de información acerca de métricas de una
organización y cumplir el objetivo de determinarlas automáticamente a partir de una meta organizacional. Si bien
hacen falta aún más experimentos y diversificar las empresas participantes, es destacable que se obtenga un 83,4% de
aceptación en pruebas iniciales, con un bajo número de datos de prueba. Lo que indica lo certero de la tecnología
ontológica y a búsqueda semántica. Cabe destacar que el calce de objetivos-métricas es semántico, lo que quiere
decir que es por significado.
53
5. CONCLUSIONES
El cumplimiento de objetivos, es sin duda la finalidad de toda organización. Dependiendo de la madurez

alcanzada por la organización y su nivel de complejidad, ésta puede poseer objetivos simples o complejos y tras ellos
un completo plan estratégico para lograrlos. Pero para ello es necesario monitorear constantemente el avance y los
logros obtenidos por la organización. Dada la naturaleza cualitativa de los objetivos es necesario realizar un proceso
de medición cuantitativo para interpretar los valores de avance y realizar un correcto control.
El control es una de las etapas más importantes de la gestión, y a su vez la medición. La determinación de qué
se va a medir y cuándo es casi un arte. Es necesario identificar que métricas utilizar y como estas van a
retroalimentar a los ejecutivos de información de la empresa, el activo más valioso de la organización.
Para resolver este problema se pueden utilizar distintos enfoques y tecnologías, pero se opta por una ontología
ya que a través de la conceptualización del domino del problema, es posible realizar consultar semánticas que
permiten una mejor interacción entre el usuario y el sistema de recuperación de información. Al asumir relaciones
conceptuales en la ontología y utilizando un lenguaje de consulta para las mismas, es posible realizas inferencias y
aportar información útil, independiente del lenguaje e interpretación del usuario hacia un concepto.
Si bien el uso de una ontología necesita una excesiva cantidad de diseño, en el largo plazo este diseño ayuda a
abstraer de mejor manera el problema y darle una perspectiva del negocio y de la solución mucho más ingenieril al
desarrollador.
La metodología de desarrollo de este proyecto es iterativa por lo que es posible que lo ya realizado sea
modificado en el futuro para ajustarlo de mejor forma a los requerimientos del problema, y también agregar o definir
nuevos elementos o funcionalidades que permitan una solución más completa. Esto es de vital importancia ya que se
puede diseñar el funcionamiento del sistema de una forma determinada, pero al implementar uno puede darse cuenta
que tal implementación es imposible. E incluso, debido a lo avanzado que puede ser el lenguaje de programación, se
podría simplificar el diseño gracias a componentes que resuelven muchos de los problemas, es el caso del framework
Primefaces para la capa vista.
Luego de implementar bastante código, se agradece la gran cantidad de componentes que JENA pone a
disposición de los desarrolladores, ya que soluciona problemas básicos y permite concentrarse de lleno en la
implementación misma del sistema. Pero JENA no es perfecto, la documentación de sus componentes menos usados
está bastante mezclada y hay algunas cosas que no se encuentran en los tutoriales. Por otra parte, el uso de un IDE de
desarrollo ha permitido detectar muchos errores antes de compilar la aplicación, y no sólo eso, sino que también
propone en algunos casos como resolver estos problemas.
54
La aplicación es capaz de trazar indicadores a objetivos, que permiten visualizar el nivel de sanidad de los
requisitos, de forma tal que los riesgos pueden ser identificados en etapas más tempranas, lo que permitirá tomar
decisiones a tiempo para corregir situaciones no deseadas, reduciendo de esta forma el esfuerzo requerido para la
gestión del proyecto.
Los indicadores clave de rendimiento pueden ser una herramienta importante para la conducción de proyecto
de comportamientos y medición del proyecto éxito, ya sean para los proyectos que son grandes y complejos con
múltiples partes interesadas. Es la clave obtener estas métricas que se acuerdan tempranamente, pensar
cuidadosamente para asegurar que son prácticas y viables.
Finalmente, se podría decir que los objetivos del proyecto se han alcanzado, ya que con los productos
obtenidos, tanto documentación como prototipo, ya es posible apoyar a la dirección de una organización ayudando a
determinar métricas de control en línea con los requerimientos de crecimiento de la organización.
Algunos trabajos futuros son:
 Integrar la ontología de procesos de desarrollo de software para que el sistema de inferencia determine a su
vez qué medir (métricas), cuándo (planificación) y dónde (proceso).
 Agregar mantenedores de proceso para soportar la búsqueda semántica de métricas por proceso y no solo
por objetivo.
 Escalar el sistema de inferencia para múltiples organizaciones.
55
6. REFERENCIAS
[1] ISO, Estándar ISO-9001. www.iso.org. Consultado en marzo de 2012.
[2] DeMarco, Tom: “Controlling Software Projects: Management, Measurement, and Estimation”, 1982.
[3] Andrade, Gómez, Beobide, Gutierrez de Mesa: “Desde ISO 9001 Hacia CMMI, Pasos para la mejora de los
procesos y métricas”, Editorial España, 2006.
[4] Peralta, Mario Luis: “Asistente para la evaluación de CMMI-SW”. Tesis de Maestría. ITBA. Buenos Aires, 2004.
[5] Kaplan, Robert; Norton, David. “El Cuadro de Mando Integral. Barcelona”, Editorial Gestión 2000, 1997.
[6] Proyecto FONDEF A.D.A.P.T.E. Adaptable Domain and Process Technology Engineering. www.adapte.cl
Consultado en Julio de 2012.
[7] Resource Description Framework (RDF). www.w3.org/RDF Consultado en Septiembre de 2012
[8] O’Regan, Gerard: “A Practical Approach to Software Quality”, Editorial Springer, 2002.
[9] González, de Cuadra García, “Calidad del software (II)”, procedentes de “Anales de Mecánica y Electricidad”,
2001.
[10] Gareth Byatt, Gary Hamilton y Jeff Hodgkinson, ¿Qué hace un buen KPI en el marco del proyecto?, 2003.
[11] Martín, María de los Ángeles: “Sistema de Catalogación de Métricas e Indicadores con Potencia de Web
Semántica”. Tesis de Maestría, UNLP, 2004
[12] Kitchenham, Barbara, Software Metrics: Measurement for Software Process Improvement, 1996.
[13] Olsina, Luis, “Métricas e Indicadores: Dos Conceptos Claves para Medición y Evaluación”, Facultad de
Ingeniería, Universidad nacional La Pampa Argentina.
[14] Instituto Nacional Español de Tecnologías de la Comunicación, “Guía Avanzada de Medición y Análisis” 2009
[15] Francisco José García Peñalvo, “Web Semántica y Ontologías”, Departamento de Informática y Automática –
Facultad de Ciencias, Universidad de Salamanca.
56
[16] Del Valle, Ricardo, Reglas de inferencia. ESIME Zacatenco, Instituto Politécnico Nacional de México.
[17] Sanz, Ismael; Jiménez-Ruiz, Ernesto Ontologías en Informática, Editorial Peter Lang, 2009.
[18] Apache Jena https://jena.apache.org Consultado en octubre de 2012.
[19] Resource Description Framework RDF http://www.w3.org/RDF Consultado en noviembre de 2012.
[20] Protegé http://protege.stanford.edu Consultado en noviembre de 2012.
[21] SPARQL RDF QUERY http://www.w3.org/TR/rdf-sparql-query Consultado en noviembre de 2012.
[22] Framework Java Server Faces https://javaserverfaces.java.net/ Consultado en diciembre de 2012.
[23] Framework Primafaces http://www.primefaces.org/ Consultado en diciembre de 2012.
[24] MySQL http://www.mysql.com/ Consultado en diciembre de 2012.
57
7. ANEXOS
7. 1. D E S C R I P C I Ó N RD F DE O N T O L O GÍ A DE MÉTRIC AS Y O B J E T I VO S
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:protege="http://protege.stanford.edu/plugins/owl/protege#"
xmlns:xsp="http://www.owl-ontologies.com/2005/08/07/xsp.owl#"
xmlns="http://www.owl-ontologies.com/Onto_metricas.owl#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:swrl="http://www.w3.org/2003/11/swrl#"
xmlns:swrlb="http://www.w3.org/2003/11/swrlb#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xml:base="http://www.owl-ontologies.com/Onto_metricas.owl">
<owl:Ontology rdf:about=""/>
<owl:Class rdf:ID="Metrica">
<sinonimo>
<Metrica rdf:ID="Metrica_4">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>indicador, medidor,controlador, gestionador</rdfs:comment>
</Metrica>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="EntidadMedible">
<sinonimo>
<EntidadMedible rdf:ID="EntidadMedible_3">
>objeto, entregable, producto,valorizable</rdfs:comment>
</EntidadMedible>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="ProcesoProductivo">
<sinonimo>
<ProcesoProductivo rdf:ID="ProcesoProductivo_9">
58
>producción, actividad productiva</rdfs:comment>
</ProcesoProductivo>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="UnidadDeMedida">
<sinonimo>
<UnidadDeMedida rdf:ID="UnidadDeMedida_13">
>unidad de medición</rdfs:comment>
</UnidadDeMedida>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="AtributoMedible">
<sinonimo>
<AtributoMedible rdf:ID="AtributoMedible_2">
>propiedad, valorizable, característica</rdfs:comment>
</AtributoMedible>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="TipoDeMetrica">
<sinonimo>
<TipoDeMetrica rdf:ID="TipoDeMetricaCuantitativa">
<descripcion xml:lang="es">Métrica expresable en cantidad, cuantificable</descripcion>
<nombre xml:lang="es">Métrica Cuantitativa</nombre>
>especie de métrica</rdfs:comment>
</TipoDeMetrica>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="ProcesoDeMedicion">
<sinonimo>
<ProcesoDeMedicion rdf:ID="ProcesoDeMedicion_8">
>medición, metodología de medición, fórmula de medida</rdfs:comment>
</ProcesoDeMedicion>
</sinonimo>
59
</owl:Class>
<owl:Class rdf:ID="ActividadDeProceso">
<sinonimo>
<ActividadDeProceso rdf:ID="ActividadDeProceso_1">
>actividad, tarea, trabajo,acción, producción, producir</rdfs:comment>
</ActividadDeProceso>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="Motivacion">
<sinonimo>
<Motivacion rdf:ID="Motivacion_5">
>deseo, enganche, estimulación</rdfs:comment>
</Motivacion>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="Producto">
<sinonimo>
<Producto rdf:ID="Producto_10">
>elemento,finalidad</rdfs:comment>
</Producto>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="Organizacion">
<sinonimo>
<Organizacion rdf:ID="Organizacion_7">
>empresa, agrupación, negocio, compañia</rdfs:comment>
</Organizacion>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="ObjetivoOrganizacional">
<rdfs:subClassOf>
<owl:Class rdf:ID="Objetivo"/>
</rdfs:subClassOf>
60
</owl:Class>
<owl:Class rdf:ID="TipoDeObjetivo">
<sinonimo>
<TipoDeObjetivo rdf:ID="TipoDeObjetivo_12">
>especie de objetivo</rdfs:comment>
</TipoDeObjetivo>
</sinonimo>
</owl:Class>
<owl:Class rdf:about="#Objetivo">
<sinonimo>
<Objetivo rdf:ID="Objetivo_6">
>meta, final, objetivo, goal,fin</rdfs:comment>
</Objetivo>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="ActividadDeMedicion">
<sinonimo>
<ActividadDeMedicion rdf:ID="ActividadDeMedicion_17">
>actividad, medición,tarea,trabajo,evaluación,acción</rdfs:comment>
</ActividadDeMedicion>
</sinonimo>
</owl:Class>
<owl:ObjectProperty rdf:ID="pertenece_a">
<rdfs:domain rdf:resource="#ActividadDeProceso"/>
<rdfs:range rdf:resource="#ProcesoProductivo"/>
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="tiene_actividad"/>
</owl:inverseOf>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="es_medida_en">
<rdfs:domain rdf:resource="#EntidadMedible"/>
<rdfs:range rdf:resource="#ActividadDeMedicion"/>
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="mide_sobre"/>
61
</owl:inverseOf>
<owl:ObjectProperty rdf:ID="motiva_a">
<rdfs:range rdf:resource="#Objetivo"/>
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="lo_motiva"/>
</owl:inverseOf>
<rdfs:domain rdf:resource="#Motivacion"/>
<owl:ObjectProperty rdf:about="#mide_sobre">
<rdfs:range rdf:resource="#EntidadMedible"/>
<owl:inverseOf rdf:resource="#es_medida_en"/>
<rdfs:domain rdf:resource="#ActividadDeMedicion"/>
<owl:ObjectProperty rdf:about="#lo_motiva">
<rdfs:domain rdf:resource="#Objetivo"/>
<rdfs:range rdf:resource="#Motivacion"/>
<owl:inverseOf rdf:resource="#motiva_a"/>
<owl:ObjectProperty rdf:ID="tiene_tipo">
<rdfs:range rdf:resource="#TipoDeObjetivo"/>
<owl:ObjectProperty rdf:ID="posee">
<rdfs:domain rdf:resource="#Metrica"/>
<owl:ObjectProperty rdf:ID="utiliza">
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="es_utilizado"/>
</owl:inverseOf>
<rdfs:domain rdf:resource="#Organizacion"/>
<rdfs:range rdf:resource="#ProcesoProductivo"/>
<owl:ObjectProperty rdf:ID="produce">
<rdfs:range rdf:resource="#Producto"/>
62
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="es_producido_por"/>
</owl:inverseOf>
<owl:ObjectProperty rdf:about="#tiene_actividad">
<rdfs:domain rdf:resource="#ProcesoProductivo"/>
<owl:inverseOf rdf:resource="#pertenece_a"/>
<rdfs:range rdf:resource="#ActividadDeProceso"/>
<owl:ObjectProperty rdf:ID="tiene_unidad">
<rdfs:range rdf:resource="#UnidadDeMedida"/>
<owl:ObjectProperty rdf:about="#es_producido_por">
<rdfs:domain rdf:resource="#Producto"/>
<owl:inverseOf rdf:resource="#produce"/>
<rdfs:range rdf:resource="#Organizacion"/>
<owl:ObjectProperty rdf:about="#es_utilizado">
<owl:inverseOf rdf:resource="#utiliza"/>
<rdfs:domain rdf:resource="#ProcesoProductivo"/>
<owl:ObjectProperty rdf:ID="se_mide_con">
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="mide"/>
</owl:inverseOf>
<rdfs:range rdf:resource="#ProcesoDeMedicion"/>
<owl:ObjectProperty rdf:ID="pertenece_a_entidad">
<rdfs:domain rdf:resource="#AtributoMedible"/>
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="posee_atributo"/>
</owl:inverseOf>
<rdfs:range rdf:resource="#EntidadMedible"/>
63
<owl:ObjectProperty rdf:about="#posee_atributo">
<rdfs:domain rdf:resource="#EntidadMedible"/>
<rdfs:range rdf:resource="#AtributoMedible"/>
<owl:inverseOf rdf:resource="#pertenece_a_entidad"/>
<owl:ObjectProperty rdf:ID="pertenece_a_proceso">
<rdfs:range rdf:resource="#ProcesoDeMedicion"/>
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="tiene_actividad_medicion"/>
</owl:inverseOf>
<rdfs:domain rdf:resource="#ActividadDeMedicion"/>
<owl:ObjectProperty rdf:about="#tiene_actividad_medicion">
<owl:inverseOf rdf:resource="#pertenece_a_proceso"/>
<rdfs:domain rdf:resource="#ProcesoDeMedicion"/>
<rdfs:range rdf:resource="#ActividadDeMedicion"/>
<owl:ObjectProperty rdf:ID="tiene">
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="es_de"/>
</owl:inverseOf>
<owl:ObjectProperty rdf:about="#mide">
<rdfs:range rdf:resource="#Metrica"/>
<owl:inverseOf rdf:resource="#se_mide_con"/>
<owl:ObjectProperty rdf:about="#es_de">
<owl:inverseOf rdf:resource="#tiene"/>
<owl:DatatypeProperty rdf:ID="descripcion">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:domain>
64
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Producto"/>
<owl:Class rdf:about="#EntidadMedible"/>
<owl:Class rdf:about="#ProcesoDeMedicion"/>
<owl:Class rdf:about="#Metrica"/>
<owl:Class rdf:about="#Objetivo"/>
<owl:Class rdf:about="#UnidadDeMedida"/>
<owl:Class rdf:about="#AtributoMedible"/>
<owl:Class rdf:about="#TipoDeMetrica"/>
<owl:Class rdf:about="#Organizacion"/>
<owl:Class rdf:about="#TipoDeObjetivo"/>
<owl:Class rdf:about="#ActividadDeMedicion"/>
<owl:Class rdf:about="#Motivacion"/>
<owl:Class rdf:about="#ProcesoProductivo"/>
<owl:Class rdf:about="#ActividadDeProceso"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="mision">
<owl:DatatypeProperty rdf:ID="vision">
<owl:DatatypeProperty rdf:ID="metodologia">
<owl:DatatypeProperty rdf:ID="nombre">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
65
<owl:Class rdf:about="#Producto"/>
<owl:Class rdf:about="#EntidadMedible"/>
<owl:Class rdf:about="#Metrica"/>
<owl:Class rdf:about="#Objetivo"/>
<owl:Class rdf:about="#UnidadDeMedida"/>
<owl:Class rdf:about="#AtributoMedible"/>
<owl:Class rdf:about="#TipoDeMetrica"/>
<owl:Class rdf:about="#Organizacion"/>
<owl:Class rdf:about="#TipoDeObjetivo"/>
<owl:Class rdf:about="#ActividadDeMedicion"/>
<owl:Class rdf:about="#Motivacion"/>
<owl:Class rdf:about="#ProcesoProductivo"/>
<owl:Class rdf:about="#ActividadDeProceso"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
<owl:DatatypeProperty rdf:ID="valor">
<rdfs:domain rdf:resource="#AtributoMedible"/>
<owl:DatatypeProperty rdf:ID="abreviacion">
<rdfs:domain rdf:resource="#UnidadDeMedida"/>
<owl:AnnotationProperty rdf:ID="sinonimo">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
</owl:AnnotationProperty>
<rdf:Description rdf:ID="TipoDeMetrica_16">
<nombre xml:lang="es">Métrica Cualitativa</nombre>
</rdf:Description>
<TipoDeMetrica rdf:ID="TipoDeMetricaCualitativa">
<descripcion xml:lang="es">Métrica no expresable en cantidad numérica.</descripcion>
<nombre xml:lang="es">Métrica Cualitativa</nombre>
</TipoDeMetrica>
</rdf:RDF>
66
7. 2. A N E X O I N T E R F A C E S D E U SU ARIO
Las interfaces de usuario corresponde a la capa de interacción con los usuarios del sistema de inferencia. Éstas
son: gestionar métricas (figura 7.2), gestionar objetivos (figura 7.3), gestionar códigos (figura 7.4), agregar métricas
(figura 7.5), agregar objetivo (figura 7.6), ver resultados de métrica (figura 7.7) y ver resultados objetivo (figura 7.8).
Figura 7.1: Pantalla de inicio al sistema de inferencia
67
Figura 7.2: Pantalla de gestión de métricas
Figura 7.3: Pantalla de gestión de objetivos.
68
Figura 7.4: Pantalla de ingreso de métricas.
69
Figura 7.5: Pantalla de ingreso de objetivos.
Figura 7.6: Pantalla de visualización de métricas.
70
Figura 7.7: Pantalla de visualización de objetivos
Figura 7.8: Pantalla de la organización
71

Uce3896225 0122

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Uce3896225 0122

Cargado por

Copyright:

Formatos disponibles

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO

INDICADORES CLAVE DE RENDIMIENTO EN PROYECTOS

WASHINGTON ANÍBAL SEGURA MIGUELES

TESIS DE GRADO PARA OPTAR AL GRADO DE

INDICADORES CLAVE DE RENDIMIENTO EN PROYECTOS

WASHINGTON ANÍBAL SEGURA MIGUELES

Profesor Guía: Rodolfo Villarroel Acevedo

Programa: Magíster en Ingeniería Informática

Figura 2.1: La empresa y su contexto ......................................................................................... 12

Tabla 3.1: Sintaxis de entidades de ontología ............................................................................. 27

Palabras Clave: Control, Desarrollo de Software, Objetivo Organizacional, KPI.

Key Words: Control, Software Development, Organizational Objective, KPI.

Los principales problemas en el área de software son:

La siguiente tesis corresponde a la recopilación de conceptos clave para la determinación de métricas y

El siguiente documento se divide en 7 capítulos, el primero corresponde a la introducción a la temática,

De esto se desprenden dos problemas principales, estos son:

1.2.1. Objetivo General

1.2.2. Objetivos Específicos

 Identificar motivaciones de empresas para determinar objetivos organizacionales.

Figura 2.1: La empresa y su contexto

Algunas características de los objetivos organizacionales son:

Algunas funciones de los objetivos organizacionales son:

2.2.1. Recursos medibles por métricas de software

Existen cuatro elementos básicos que interactúan en la medición [12]:

Figura 2.2: Modelo de relaciones de elementos de medición

2.2.2. Indicadores clave de desempeño

A nivel de proyecto las métricas realizan los siguientes aportes [14]:

A nivel de la organización la medición proporcionará los siguientes beneficios [14]:

Algunas mediciones posibles para un proyecto de software son [14]:

2.5.1. Objetivos, Preguntas y Métricas GQM

Aunque el objetivo principal de la práctica es la definición de métricas, el enfoque también se ocupa de la

Figura 2.4: Pasos del método GQM

2.5.2. Sistema de Catalogación de Métricas e Indicadores con Potencia de Web Semántica

2.5.3. Cuadro de mando integral.

Se definirán lenguajes específicos de dominio para:

Se propone generar la selección de métricas para un objetivo organizacional automática o semi-

Figura 3.1: Diagrama de solución

La búsqueda semántica es un proceso utilizado para mejorar la búsqueda, en un contexto

El término ontología en informática hace referencia a la formulación de un exhaustivo y riguroso esquema

Figura 3.2: Arquitectura ontológica de la solución

Para el sistema de métricas y objetivos organizacionales se define la estructura de cada entidad-concepto

La sintaxis de cada entidad de la ontología se define en la siguiente tabla:

Tabla 3.1: Sintaxis de entidades de ontología

Entidad Atributos(Tipo de datos)

Métrica Nombre(String), Descripción(String), Tipo de Métrica(TipoDeMétrica), Proceso de

Proceso de Nombre(String), Descripción(String), Metodología(String), Actividades

Actividad de Nombre(String), Descripción(String), Entidad Medible (EntidadMedible)

Entidad Medible Nombre(String), Descripción(String), Atributo Medible(AtributoMedible)

Atributo Medible Nombre(String), Descripción(String), Valor atributo (String), Unidad de Medida

Unidad de Medida Nombre(String), Descripción(String), abreviación (String)

Objetivo Nombre(String), Descripción(String), Motivación (Motivación)

Motivación Nombre(String), Descripción(String)

Organización Nombre(String), Descripción(String), Visión(String), Misión(String),

Actividad de Nombre(String), Descripción(String), Entregable(EntidadMedible)

Producto Nombre(String), Descripción(String), Proceso Productivo(ProcesoProductivo)

3.4.1. Relaciones Conceptuales

Tabla 3.2: Definición de conceptos de capa ontológica

[Métrica] se expresa en Relación entre la métrica y la unidad de medida en la que se expresa la

[Métrica] tiene [Objetivo] Relación entre la métrica y el objetivo de medición de ésta.

[Organización] tiene Relación entre la organización y los objetivos de ésta.

[Organización] Utiliza Relación entre la organización y el proceso productivo que utiliza.

[Organización] produce Relación entre la organización y los productos que produce.