Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Uce3896225 0122
Uce3896225 0122
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA
JULIO 2014
1
PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO
FACULTAD DE INGENIERÍA
ESCUELA DE 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
5
ÍNDICE DE TABLAS
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.
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.
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.
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.
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].
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.
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
Determinar métricas, indicadores clave, a partir de objetivos organizacionales, para cuantificar el desempeño
de proyectos de desarrollo de software.
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.
12
2.1.1. Objetivos Organizacionales
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].
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.
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.
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.
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]
16
Definir e implementar planificaciones más realistas: Las métricas sirven como historial de otros proyectos.
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 ?
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
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
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]
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
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].
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.
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.
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 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
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.
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.
27
Proceso Productivo Nombre(String), Descripción(String), Actividades (ActividadDeProceso)
3. 4. C A P A O N T O L Ó G I C A
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].
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.
[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.
[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.
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.
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
Tipo de métrica Métrica cuantitativa
Entidad medible Recursos humanos
Horas -Hombre asignadas al proyecto
Atributos medibles
Horas -Hombre necesarias para el proyecto
Unidad de medida Porcentaje
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
Característica Definició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
Tipo de métrica Métrica cuantitativa
Entidad medible Producto Software
Atributos medibles Artefactos, diagramas, código, scripts, interfaces, informes
Unidad de medida Porcentaje
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.
Característica Definición
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
Unidad de medida Porcentaje
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.
Proceso de medición
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
Característica Definición
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
Entidad medible Producto Software
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.
Característica Definición
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
Entidad medible Producto Software
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
Proceso de medición
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
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.
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].
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é.
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.
WHERE{
WHERE{
38
3. 6. S I S T E M A DE IN FER ENCI A
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].
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.
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
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
Característica Definición
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
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 a 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.
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
Tipo de métrica Métrica cuantitativa
Entidad medible Recursos humanos
Horas -Hombre asignadas al proyecto
Atributos medibles
Horas -Hombre necesarias para el proyecto
Unidad de medida Porcentaje
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.
Característica Definició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
Tipo de métrica Métrica cuantitativa
Entidad medible Producto Software
Atributos medibles Artefactos, diagramas, código, scripts, interfaces, informes.
Unidad de medida Porcentaje
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.
Característica Definición
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
Unidad de medida Porcentaje
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.
Proceso de medición
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
Característica Definición
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.
Entidad medible Producto Software
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.
Característica Definición
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.
Entidad medible Producto Software
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
Proceso de medición
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
Característica Definición
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.
Característica Definición
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
Unidad de medida Porcentaje
Personas capacitadas
Atributos medibles
Certificaciones otorgadas
47
Tecnologías aprendidas
Herramientas aprendidas
Obtener porcentaje del total de personas capacitadas en base al total de
Proceso de medición
personas de la empresa.
Característica Definición
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
Característica Definición
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
Característica Definición
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
Característica Definición
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
Característica Definición
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
Característica Definición
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
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
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
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
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
Luego de interpretado el análisis de las asociaciones métrica-objetivo generado por el sistema se obtiene lo
siguiente:
52
Asociaciones realizadas por el sistema: 6
Asociaciones correctas: 5 (83.4%)
Asociaciones incorrectas: 1 (16.6%)
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 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.
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
[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.
[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.
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">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>objeto, entregable, producto,valorizable</rdfs:comment>
</EntidadMedible>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="ProcesoProductivo">
<sinonimo>
<ProcesoProductivo rdf:ID="ProcesoProductivo_9">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
58
>producción, actividad productiva</rdfs:comment>
</ProcesoProductivo>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="UnidadDeMedida">
<sinonimo>
<UnidadDeMedida rdf:ID="UnidadDeMedida_13">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>unidad de medición</rdfs:comment>
</UnidadDeMedida>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="AtributoMedible">
<sinonimo>
<AtributoMedible rdf:ID="AtributoMedible_2">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>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>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>especie de métrica</rdfs:comment>
</TipoDeMetrica>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="ProcesoDeMedicion">
<sinonimo>
<ProcesoDeMedicion rdf:ID="ProcesoDeMedicion_8">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>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">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>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">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>deseo, enganche, estimulación</rdfs:comment>
</Motivacion>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="Producto">
<sinonimo>
<Producto rdf:ID="Producto_10">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>elemento,finalidad</rdfs:comment>
</Producto>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="Organizacion">
<sinonimo>
<Organizacion rdf:ID="Organizacion_7">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>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">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>especie de objetivo</rdfs:comment>
</TipoDeObjetivo>
</sinonimo>
</owl:Class>
<owl:Class rdf:about="#Objetivo">
<sinonimo>
<Objetivo rdf:ID="Objetivo_6">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>meta, final, objetivo, goal,fin</rdfs:comment>
</Objetivo>
</sinonimo>
</owl:Class>
<owl:Class rdf:ID="ActividadDeMedicion">
<sinonimo>
<ActividadDeMedicion rdf:ID="ActividadDeMedicion_17">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>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>
<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>
<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>
<owl:ObjectProperty rdf:about="#lo_motiva">
<rdfs:domain rdf:resource="#Objetivo"/>
<rdfs:range rdf:resource="#Motivacion"/>
<owl:inverseOf rdf:resource="#motiva_a"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="tiene_tipo">
<rdfs:range rdf:resource="#TipoDeObjetivo"/>
<rdfs:domain rdf:resource="#Objetivo"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="posee">
<rdfs:domain rdf:resource="#Metrica"/>
<rdfs:range rdf:resource="#Objetivo"/>
</owl:ObjectProperty>
<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>
<owl:ObjectProperty rdf:ID="produce">
<rdfs:range rdf:resource="#Producto"/>
<rdfs:domain rdf:resource="#Organizacion"/>
62
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="es_producido_por"/>
</owl:inverseOf>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#tiene_actividad">
<rdfs:domain rdf:resource="#ProcesoProductivo"/>
<owl:inverseOf rdf:resource="#pertenece_a"/>
<rdfs:range rdf:resource="#ActividadDeProceso"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="tiene_unidad">
<rdfs:range rdf:resource="#UnidadDeMedida"/>
<rdfs:domain rdf:resource="#Metrica"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#es_producido_por">
<rdfs:domain rdf:resource="#Producto"/>
<owl:inverseOf rdf:resource="#produce"/>
<rdfs:range rdf:resource="#Organizacion"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#es_utilizado">
<owl:inverseOf rdf:resource="#utiliza"/>
<rdfs:range rdf:resource="#Organizacion"/>
<rdfs:domain rdf:resource="#ProcesoProductivo"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="se_mide_con">
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="mide"/>
</owl:inverseOf>
<rdfs:range rdf:resource="#ProcesoDeMedicion"/>
<rdfs:domain rdf:resource="#Metrica"/>
</owl:ObjectProperty>
<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"/>
</owl:ObjectProperty>
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>
<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>
<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>
<owl:ObjectProperty rdf:ID="tiene">
<rdfs:range rdf:resource="#Objetivo"/>
<owl:inverseOf>
<owl:ObjectProperty rdf:ID="es_de"/>
</owl:inverseOf>
<rdfs:domain rdf:resource="#Organizacion"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#mide">
<rdfs:range rdf:resource="#Metrica"/>
<rdfs:domain rdf:resource="#ProcesoDeMedicion"/>
<owl:inverseOf rdf:resource="#se_mide_con"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#es_de">
<rdfs:domain rdf:resource="#Objetivo"/>
<owl:inverseOf rdf:resource="#tiene"/>
<rdfs:range rdf:resource="#Organizacion"/>
</owl:ObjectProperty>
<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">
<rdfs:domain rdf:resource="#Organizacion"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="vision">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:domain rdf:resource="#Organizacion"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="metodologia">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:domain rdf:resource="#ProcesoDeMedicion"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="nombre">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<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>
<owl:DatatypeProperty rdf:ID="valor">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:domain rdf:resource="#AtributoMedible"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="abreviacion">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:domain rdf:resource="#UnidadDeMedida"/>
</owl:DatatypeProperty>
<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).
67
Figura 7.2: Pantalla de gestión de métricas
68
Figura 7.4: Pantalla de ingreso de métricas.
69
Figura 7.5: Pantalla de ingreso de objetivos.
70
Figura 7.7: Pantalla de visualización de objetivos
71