Departamento de Tecnologías y Sistemas de Información Medición del Software Ontología y...

Departamento de Tecnologías y Sistemas de Información

Medición del Software Ontología y Metamodelo

Mateus Ferreira a, Félix García a, Francisco Ruiz a, Manuel F. Bertoa b, Coral Calero a, Antonio Vallecillo b, Mario Piattini a,

Beatriz Mora a

a Grupo Alarcos - Universidad de Castilla-La Mancha, España. b Dep. de Lenguajes y Ciencias de la Computación – Universidad de Málaga, España.

Informe Técnico UCLM-TSI-001 noviembre 2006

VI

UNIVERSIDAD DE CASTILLA LA MANCHA Departamento de Tecnologías y Sistemas de

la Información

Informe Técnico UCLM-TSI-001 noviembre 2006

Mateus Ferreira a, Félix García a, Francisco Ruiz a, Manuel F. Bertoa b, Coral Calero a, Antonio Vallecillo b, Mario Piattini a,

Beatriz Mora a

a Grupo Alarcos - Universidad de Castilla-La Mancha, España. b Dep. de Lenguajes y Ciencias de la Computación – Universidad de Málaga, España.

Palabras clave: Medición del Software, Ontologías, Metamodelos, MOF, Medidas, Indicadores, REFSENO Este trabajo ha sido parcialmente financiado por los proyectos ENIGMAS (Consejería de Educación y Ciencia de Castilla-La Mancha, PBI-05-058), FAMOSO (Ministerio de Industria, FIT-340000-2005-161) y ESFINGE (Ministerio de Educación y Ciencia, TIN2006-15175-C05-05).

ÍÍnnddiicceess..

M. Ferreira, F. García, F. Ruiz et al.

VI

Medición del Software – Ontología y Metamodelo

V

ÍÍnnddiiccee ddee CCoonntteenniiddooss..

11.. IInnttrroodduucccciióónn.......................................................................................................... 1

22.. FFoorrmmaalliissmmoo RREEFFSSEENNOO ppaarraa RReepprreesseennttaacciióónn ddee OOnnttoollooggííaass.. ............................. 4

2.1. Introducción. ......................................................................................................... 4

2.2. Justificación. .......................................................................................................... 5

2.3. Elementos de REFSENO....................................................................................... 5 2.3.1. Conceptos.......................................................................................................................6 2.3.2. Atributos. .......................................................................................................................6

2.3.2.1. Atributos Terminales. ............................................................................................7 2.3.2.2. Atributos no Terminales. .......................................................................................8

2.3.3. Tipos. .............................................................................................................................9 2.3.4. Instancias. .................................................................................................................... 10 2.3.5. Otras Primitivas. ......................................................................................................... 11

2.4. Adaptación de REFSENO................................................................................... 11

33.. AAnnáálliissiiss ddee llaa SSiittuuaacciióónn AAccttuuaall.. ......................................................................... 14

3.1. IEEE Std. 610.12 (1992)....................................................................................... 15

3.2. VIM (1993)........................................................................................................... 15

3.3. IEEE Std. 1061 (1998). ........................................................................................ 15

3.4. Kim (1999). .......................................................................................................... 16

3.5. ISO/IEC 14598 (1999-2001) y 9126 (2001-2004). ................................................ 16

3.6. Kitchenham et al. (2001)...................................................................................... 16

3.7. Briand et al. (2002). ............................................................................................. 17

3.8. ISO/IEC 15939 (2002) y PSM (2002)................................................................... 17

3.9. Otros Modelos, Estándares y Propuestas............................................................ 18

3.10. Problemas Encontrados....................................................................................... 19

44.. UUnnaa OOnnttoollooggííaa CCoommúúnn.. ...................................................................................... 20

4.1. Ontología de la Medición del Software (SMO). .................................................. 21 4.1.1. Sub-Ontología de la Caracterización y Objetivos de la Medición Software............... 23 4.1.2. Sub-Ontología de las Medidas Software...................................................................... 27 4.1.3. Sub-Ontología de las Formas de Medir....................................................................... 29 4.1.4. Sub-Ontología de la Acción de Medir. ........................................................................ 32 4.1.5. Integración de las Sub-Ontologías............................................................................... 35

4.2. Discusión. ............................................................................................................. 36 4.2.1. “Métrica” vs “Medida”. .............................................................................................. 36 4.2.2. Indicador: ¿es un tipo de medida o no? ...................................................................... 37

4.3. Análisis Comparativo. ......................................................................................... 37

55.. UUnn MMeettaammooddeelloo ppaarraa llaa MMeeddiicciióónn ddeell SSooffttwwaarree.. ................................................ 44

5.1. Introducción. ....................................................................................................... 44

5.1. Estructura Básica. ............................................................................................... 44

5.2. Paquetes. .............................................................................................................. 46

5.2.1. Paquete Básico................................................................................................. 46


VI

5.2.2. Paquete Caracterización y Objetivos.............................................................. 47

5.2.3. Paquete Acción de Medir. ............................................................................... 48

5.2.4. Paquete Medidas ............................................................................................. 49

5.2.5. Paquete Formas de Medir ............................................................................... 50

6. Conclusiones. ..................................................................................................... 52

7. Referencias......................................................................................................... 53

A. Apéndice I: Lista de Términos ........................................................................... 57


VII

ÍÍnnddiiccee ddee FFiigguurraass.. Figura 1. Diagrama de la Sub-Ontología Caracterización y Objetivos de la Medición Software. ........... 24 Figura 2. Diagrama de la Sub-Ontología de las Medidas Software. ...................................................... 27 ..Figura 3. Diagrama de la Sub-Ontología de las Formas de Medir ...................................................... 30 Figura 4. Diagrama de la Sub-Ontología de la Acción de Medir. .......................................................... 33 Figura 5. Diagrama de la Ontología de la Medición del Software. ........................................................ 35 Figura 6. Estructura de Paquetes del Metamodelo de la Medición. ....................................................... 45 Figura 7. Paquete Básico. .................................................................................................................... 46 Figura 8. Paquete Caracterización y Objetivos. .................................................................................... 47 Figura 9. Paquete Acción de Medir. ..................................................................................................... 48 Figura 10. Paquete Medidas................................................................................................................. 49 Figura 11. Paquete Formas de Medir. .................................................................................................. 51


VIII

ÍÍnnddiiccee ddee TTaabbllaass.. Tabla 1. REFSENO: Ejemplo de una Tabla de Instancia....................................................................... 11 Tabla 2. Especificación de requisitos de la ontología de la medición del software. ................................ 22 Tabla 3. Fuentes documentales utilizadas en la ontología de la medición del software........................... 22 Tabla 4. Sub-ontología Caracterización y Objetivos de la Medición Software: glosario de conceptos. ... 25 Tabla 5. Sub-ontología Caracterización y Objetivos de la Medición Software: tabla de interrelaciones. 26 Tabla 6. Sub-ontología Caracterización y Objetivos de la Medición Software: tabla de atributos. ......... 26 Tabla 7. Sub-ontología de las Medidas Software: glosario de conceptos................................................ 28 Tabla 8. Sub-ontología de las Medidas Software: tabla de interrelaciones ............................................ 29 Tabla 9. Sub-ontología de las Formas de Medir: glosario de conceptos. ............................................... 31 Tabla 10. Sub-ontología de las Formas de Medir: tabla de interrelaciones............................................ 32 Tabla 11. Sub-ontología de la Acción de Medir: glosario de conceptos. ................................................ 34 Tabla 12. Sub-ontología de la Acción de Medir: tabla de interrelaciones. ............................................. 34 Tabla 13. Sub-ontología de la Acción de Medir: tabla de atributos........................................................ 35 Tabla 14. Comparación de los términos en la sub-ontología de la Acción de Medir............................... 38 Tabla 15. Comparación de los términos en la sub-ontología Caracterización y Objetivo de la Medición Software............................................................................................................................................... 40 Tabla 16. Comparación de los términos en la sub-ontología de las Medidas Software. .......................... 41 Tabla 17. Comparación de los términos en la sub-ontología de las Formas de Medir. ........................... 41 Tabla 18. Arquitectura en 4 niveles de MOF......................................................................................... 44 Tabla 19. Ontología de la Medición Software: Lista de Términos.......................................................... 58


1

11.. IInnttrroodduucccciióónn.. La rápida evolución de los ordenadores hizo del software una pieza clave. Cada

vez juega un papel más importante en nuestras actividades diarias. En la actualidad, el software se caracteriza por ser complejo y de difícil mantenimiento.

Como en cualquier otro producto que afecta a nuestra vida, se desea que el

software cumpla ciertos requisitos de calidad. Es necesario tener un control de su proceso de desarrollo soportado por una tecnología de ingeniería de software adecuada, con el fin de que el proceso sea preciso, predecible y repetible. Un factor clave para alcanzar estos objetivos es la medición.

La medición del software juega un papel muy importante en la Ingeniería del

Software. Actualmente, las métricas del software están demostrando ser muy eficaces en la construcción de sistemas de predicción de alta calidad para grandes proyectos de bases de datos [1], en la comprensión y mejora de los proyectos de desarrollo y mantenimiento del software [2], en la evaluación y garantía de calidad de sistemas, evidenciando las áreas problemáticas [3], en la determinación de mejores prácticas de trabajo con el fin de ayudar a los usuarios e investigadores en su trabajo [4], etc. Además, las métricas de software son herramientas importantes que ayudan en la evaluación y en la institucionalización de la Mejora del Proceso Software (Software Process Improvement) en organizaciones que lo desarrollan. De hecho, la medición del software es la pieza clave de iniciativas como SW-CMM (Capability Maturity Model for Software – Modelo de Madurez de Capacidad para Software), ISO/IEC 15504 (SPICE, Software Process Improvement and Capability dEtermination – Mejora del Proceso Software y Determinación de Capacidad) y CMMI (Capability Maturity Model Integration – Integración del Modelo de Madurez de Capacidad). El estándar ISO/IEC 90003:2004 [5] también destaca la importancia de la medición en la gestión y garantía de la calidad.

La estandarización también juega un papel clave en la Ingeniería del Software, y

en particular en el campo de la medición del software. Los estándares proporcionan a las empresas prácticas y tecnologías convenientes ampliamente aceptadas, con el fin de ayudar en el manejo y empleo de métodos de ingeniería, reforzando la ingeniería del software como una disciplina de “ingeniería” en lugar de una “artesanía”. Además, hoy en día Internet está cambiando la forma de llevar a cabo los negocios, proporcionando cooperación e interoperabilidad entre organizaciones individuales que necesitan competir en un mercado global y económico, compartiendo información y recursos. La estandarización es uno de los principales esfuerzos necesarios para alcanzar la interoperabilidad, facilitando la disposición de convenciones, terminologías y prácticas convenientes para el dominio.

Sin embargo, la medición del software sufre los síntomas típicos de cualquier

disciplina relativamente joven [2]. A pesar de los esfuerzos y de los avances en la investigación y en la estandarización internacional durante la última década, la medición del software se encuentra en una fase en que terminología, principios y métodos aún están siendo definidos, consolidados y acordados. En particular, no hay todavía consenso sobre los conceptos y terminologías utilizadas en este campo. Por ejemplo, usuarios e investigadores de la medición del software aún no lograron un acuerdo sobre el significado preciso de algunos términos comúnmente utilizados como “medición”,


2

“medida”, “métrica”, “atributo medible”, etc. Además, frecuentemente se pueden encontrar inconsistencias entre diferentes propuestas de investigación en el área de la medición.

La situación no es mucho mejor si miramos los estándares internacionales de

ingeniería del software desarrollados por las principales organizaciones e instituciones de estandarización como IEEE, ISO o IEC. Se pueden encontrar inconsistencias y conflictos de terminología entre estándares de diferentes organizaciones e incluso en algunos de una misma organización. Además, ningún estándar contiene una visión completa de la medición del software. Todos ellos ofrecen vistas parciales del dominio de la medición del software: las métricas, el proceso de medición, o las entidades y objetivos de la medición. Este problema ha sido reconocido por ISO/IEC que ha creado un grupo de trabajo para la armonización de los estándares de ingeniería de sistemas dentro del “Joint Technical Comité 1” (JTC1: “Information Technology”, www.jtc1.org). Este grupo está intentado incluir explícitamente en sus directivas procedimientos que garanticen la consistencia y coherencia entre sus estándares. El esfuerzo de ISO para armonizar la tecnología de medición empezó con la selección de la terminología del Vocabulario Internacional de Términos Básicos y Generales en Metrología de ISO (ISO International Vocabulary of Basic and General Terms in Metrology - VIM [6]) para los estándares ISO/IEC TR 14143-3 e ISO/IEC 15939 y para documentos futuros del SC7 (Sub-comité 7, dedicado a la Ingeniería del Software) relacionados con la medición. Además, hay un acuerdo desde el año 2002 entre la IEEE-Computer Society e ISO/JTC1-SC7 para armonizar sus estándares, incluyendo la terminología sobre la medición. Sin embargo, parece que la situación aún se encuentra lejos de estar resuelta.

Con el objetivo de contribuir a la armonización de los diferentes estándares de la

medición del software y propuestas de investigación, García et al. presentan en [7] un análisis comparativo de los conceptos y términos usados en los estándares más relevantes en el campo de la medición, identificando las concordancias, discrepancias y conflictos de terminología y presenta una propuesta unificada cuyo objetivo principal es contribuir para la creación de una terminología consistente para la medición del software.

Lo que se pretende en este documento es, utilizando el método de representación

REFSENO propuesto por Tautz y Von Wangenheim en [9], reestructurar la ontología presentada en [7] en cuatro sub-ontologías separadas (siguiendo el modelo propuesto por García en [8]) y traducirla al español. La principal finalidad de este abordaje es facilitar y mejorar la comprensión de la ontología mostrando cada sub-ontología de forma detallada y, al final, presentar una vista general de toda la ontología y su correspondencia con la ontología original (en inglés).

También se propone un Metamodelo de la Medición basado en la Ontología de

la Medición del Software (Software Measurement Ontology, SMO) y en un metamodelo previo propuesto en [8]. El objetivo principal de este nuevo metamodelo es dar soporte a la definición de modelos concretos de medición, facilitando así su gestión y proporcionar un marco adecuado para el proceso de medición.

Este documento está estructurado en 7 secciones, de las cuales la primera es esta

introducción, la sección 2 presenta un breve resumen del formalismo REFSENO, la


3

sección 3 presenta un análisis de la situación actual donde se comparan algunos de los estándares internacionales y propuestas de investigación más representativos, la sección 4 introduce la ontología de la medición software reestructurada según las primitivas mencionadas anteriormente y presenta un análisis comparativo de la misma con relación a las diferentes propuestas y estándares actuales, la sección 5 trata de presentar el Metamodelo de la Medición, y las secciones 6 y 7 finalizan con algunas conclusiones y con la lista de referencias bibliografías, respectivamente.

También se ha incluido al final un apéndice con la lista de términos de la

Ontología de la Medición del Software, sus sinónimos y equivalentes en inglés.


4

22.. FFoorrmmaalliissmmoo RREEFFSSEENNOO ppaarraa RReepprreesseennttaacciióónn ddee OOnnttoollooggííaass..

2.1. Introducción.

REFSENO (Representation Formalism for Software Engineering Ontologies) es, como su nombre indica, un formalismo diseñado para la representación de ontologías de ingeniería del software mediante tablas, texto y opcionalmente diagramas; por lo que las ontologías obtenidas son semi-formales. REFSENO ha sido desarrollado en el Fraunhofer-IESE por Tautz y Von Wangenheim [9].

Mediante REFSENO se puede representar el conocimiento de ingeniería del

software por una ontología (conocimiento del dominio) y por instancias de los conceptos de dicha ontología (conocimiento de contexto específico). Para ello se utilizan un conjunto de primitivas epistémicas que integran ideas de varios campos diferentes: bases de datos, razonamiento basado en casos y bases de conocimiento. Además, el formalismo es orientado a objetos. Es importante tener en cuenta que las ontologías definidas con REFSENO sirven para gestionar el conocimiento y no para implementar asistentes inteligentes.

REFSENO también propone un método de diseño de ontologías que está basado

en una adaptación de la metodología “Methontology” [10]. Methontology imita el ciclo de vida del software propuesto en el estándar IEEE 1074 [11] estableciendo las etapas principales siguientes:

1. Planificación;

2. Especificación (de los requisitos) de la ontología;

3. Conceptualización, es decir, la ontología propiamente dicha (equivalente al diseño en un sistema software); e

4. Implementación, es decir, representación y almacenamiento de la Conceptualización anterior mediante el uso de alguna herramienta informática. REFSENO también se basa en estas etapas pero no se considerará la etapa de

implementación ya que en este documento la ontología no se utiliza con esa finalidad. La especificación de la ontología indica el dominio de modelado, el propósito, el

alcance e información administrativa como autores y fuentes de conocimiento utilizadas [12].

La conceptualización o elaboración de la ontología propiamente dicha se realiza

en los siguientes pasos [9]:

1. Definir el glosario de conceptos a partir de las fuentes de conocimiento citadas.


5

2. Definir las interrelaciones semánticas entre dichos conceptos representándolas mediante un diagrama de clases UML1. A la vez, elaborar una tabla de clases de interrelaciones con las diversas clases que se van identificando.

3. Analizar los conceptos relacionados para identificar las partes comunes a dos o más conceptos. Decidir si estas partes son a su vez conceptos (introducidos por razones de modelado) y, en su caso, incluirlos en el glosario de conceptos.

4. Identificar los atributos terminales (atributos normales) de todos los conceptos e incorporarlos a la(s) tabla(s) de atributos y al diagrama de clases UML. En paralelo, cada vez que se identifica un nuevo tipo de atributo se debe incluir en la tabla de tipos.

5. Completar las tablas de atributos de conceptos incluyendo los atributos no terminales (equivalentes a las interrelaciones obtenidas en el paso segundo).

6. Comprobar la completitud de todas las tablas de atributos, indicando para cada atributo si pertenece a la capa de descripción del artefacto propiamente dicho, de su interfaz o de su contexto.

2.2. Justificación.

Con el fin de sistematizar la implementación de la ontología decidimos usar una metodología. En la literatura se proponen diferentes metodologías, por ejemplo, en [37] se utiliza una representación basada en lógica de predicados de primer orden. Otros enfoques se basan en “frames” como Ontolingua [36] que es uno de los lenguajes ontológicos más utilizados.

Después de un estudio de las diferentes metodologías se optó por utilizar la metodología REFSENO [9] debido a los siguientes motivos:

1. Como el mismo nombre indica, fue especialmente diseñada para el desarrollo de

ontologías en la ingeniería del software. 2. REFSENO hace una distinción entre los diferentes niveles de conocimiento:

conceptual y específico del contexto, en cambio los enfoques citados anteriormente representan un nivel de abstracción más alto.

3. La metodología propone diferentes técnicas para revisar la consistencia de la ontología y, además, tiene métodos para controlar la consistencia de las instancias en un nivel de implementación, característica que otras metodologías no consideran.

2.3. Elementos de REFSENO.

A continuación se definen las diversas primitivas epistémicas utilizadas en el

formalismo, haciendo especial hincapié en las utilizadas en este documento, es decir, en aquellas que no tienen utilidad únicamente para una hipotética implementación futura o para fines de consultas a una base de conocimiento que pudiera almacenar la ontología.

1 REFSENO también incluye diagramas como modos de representación alternativos, pero no se comentan en este documento porque se han sustituido por diagramas de clases UML.


6

Para cada primitiva se indican los siguientes aspectos: nombre, ejemplo, sinónimos (si son conocidos), definición, descripción (explicación de los componentes incluidos en la definición), y representación (modo de representar este tipo de primitivas, es decir, sintaxis utilizada).

2.3.1. Conceptos. Un concepto modela entidades de ingeniería del software (un plan de

aseguramiento de calidad, un modelo de proceso, un documento de diseño, un módulo de código, etc.) o es necesario para propósitos de modelado. Es sinónimo de tipo de artefacto, clase (en UML), entidad o marco (frame). Está definido por una 9-tupla con las siguientes propiedades:

• Nombre: es único en la ontología.

• Extensión: conjunto de todas las instancias pertenecientes al concepto.

• Intensión: conjunto de todos los atributos (de dos categorías, terminales y no terminales) que caracterizan a todas las instancias de la extensión. Los atributos pertenecen a una de las tres capas siguientes: artefacto, interfaz o contexto (ver apartado 2.3.2.1).

• Sim-artef, Sim-i/f, Sim-ctxt: son tres funciones de similaridad entre instancias (una por cada capa de atributos en la intensión) utilizadas con fines de consulta.

• Aserción: una condición que todas las instancias de la extensión deben cumplir.

• Precondición: una condición que se debe cumplir antes de insertar o cambiar instancias.

• Descripción: un texto que define la entidad.

• Propósito: justificación de la existencia del concepto en la ontología, es decir, las tareas que necesitan el concepto. Para los conceptos que representan a entidades de ingeniería del software suele consistir en un escenario o caso de uso.

• Usuarios: describe los roles que usarán el concepto. Los conceptos, su intensiones y sus extensiones se representan en tres tipos de

tablas diferentes llamadas, respectivamente, glosario de conceptos, tabla de atributos (apartado 2.3.2) y tabla de instancias (apartado 2.3.4).

El glosario de conceptos es una lista alfabética de todos los conceptos de la

ontología. Para cada concepto, de las diez propiedades que definen su tupla, se incluyen sólo: su nombre, descripción, propósito y usuarios.

2.3.2. Atributos. Existen dos categorías de atributos: terminales, que equivalen a los atributos de

las entidades en el modelo entidad-interrelación o de las clases en UML, y no


7

terminales, que equivalen a las interrelaciones del modelo entidad-interrelación y a las asociaciones en UML.

2.3.2.1. Atributos Terminales. Los atributos terminales modelan las propiedades de las entidades. Sus

sinónimos son dimensión, elemento de datos, característica o propiedad. Están definidos por la 9-tupla siguiente:

• Nombre: es único para la intensión de un concepto.

• Descripción: un texto con el significado del atributo.

• Cardinalidad: un rango que indica el número mínimo y máximo de valores que el atributo puede tener. Se utiliza la misma notación que en UML.

• Tipo: indica el tipo del atributo.

• Valor por defecto: utilizado cuando se insertan nuevas instancias sin haber asignado valor al atributo.

• Obligatoriedad: indica si es obligatorio que el atributo tenga valor para poder insertar una instancia nueva.

• Valor inferido: para los atributos derivados, indica la fórmula para calcular su valor.

• Atributos inferidos: lista de los atributos cuyo valor se calcula a partir del valor de este atributo. Cada atributo se indica por un par “[concepto]:[atributo]”.

• Peso estándar: utilizado por las funciones de similaridad con fines de consulta. Los atributos terminales se representan en una tabla de atributos para cada

concepto, que contiene una fila por cada atributo, indicando su capa (artefacto, interfaz o contexto) y todas las propiedades de la 9-tupla anterior. Los atributos se ordenan alfabéticamente dentro de cada capa. Además, la tabla incluye un encabezamiento con los nombres del concepto y del super-concepto. Los atributos del super-concepto son heredados por el concepto, es decir, la intensión de un concepto incluye a todos los atributos de su tabla más los incluidos en la intensión de su super-concepto. Existe un super-concepto raíz llamado “CONCEPT” para referirse a los conceptos que realmente no heredan de otro concepto. La tabla de atributos también incluye un pie con las funciones de similaridad, la precondición y la aserción.

Cada atributo de un concepto pertenece a una de las siguientes capas [13]:

a) Capa de artefacto (artef): formada por los atributos que caracterizan las instancias propiamente dichas; por ejemplo, el autor y el lenguaje de programación de un módulo de código.

b) Capa de interfaz (i/f): formada por los atributos que caracterizan cómo se puede integrar una instancia en el sistema circundante. Ejemplos de este tipo son los parámetros y las variables globales de un módulo de código.


8

c) Capa de contexto (ctxt): cuyos atributos caracterizan el entorno en el que las instancias son aplicadas; por ejemplo, la aplicación a la que pertenece un módulo de código.

2.3.2.2. Atributos no Terminales. Junto con los atributos terminales, los atributos no terminales también son parte

de la intensión de un concepto. Esta categoría de atributos modela la forma en que una entidad de ingeniería del software se relaciona con otras entidades, por ejemplo, para representar cómo un “objetivo de calidad GQM” está relacionado con un “plan de calidad”. Otros sinónimos son los punteros, los enlaces o las referencias. Un atributo no terminal está definido por una 11-tupla cuyas propiedades son:

• Nombre: es único para la intensión de un concepto.

• Clase: indica la clase de asociación, por ejemplo, “es-un” o “es-parte-de”.

• Destino: es el concepto asociado, de forma que los valores de un atributo no terminal son un conjunto de instancias de dicho concepto de destino.

• Atributo inverso: el atributo correspondiente del concepto de destino.

• Descripción, Cardinalidad, Valor por defecto, Obligatoriedad, Valor inferido, Atributos inferidos y Peso estándar: se definen igual que para los atributos terminales. Utilizado por las funciones de similaridad con fines de consulta. Los atributos no terminales se representan en la misma tabla de atributos que los

terminales, pero con la salvedad de que en la columna “tipo” se indican la clase, el concepto de destino y el atributo inverso, mediante un texto de la forma “<clase>[<destino>].[atributo inverso]”. Además, el valor por defecto se indica mediante un nombre de instancia del concepto de destino. Para mejorar la visibilidad, REFSENO recomienda representar estos atributos también mediante un diagrama de clases similar a los de UML.

Las clases de atributos no terminales son análogas a los tipos de los atributos

terminales y permiten definir la semántica de las interrelaciones entre entidades, por ejemplo, si la interrelación entre un plan de calidad y una medición es de la clase “incluye-a”, significará que un plan de calidad incluye mediciones. Estas clases están definidas por una 5-tupla con las siguientes propiedades:


• Nombre inverso: las interrelaciones modeladas por los atributos no terminales se pueden leer en dos direcciones diferentes. Este nombre se refiere a la segunda. Por ejemplo, el nombre podría ser “es-componente-de” y el nombre inverso sería “está-compuesto-por”.

• Propósito: justificación de la existencia de esta clase de atributo no terminal en la ontología. Suele consistir en un conjunto de escenarios de uso que muestran su utilidad.


9

• Estructura: las instancias de los conceptos se relacionan por medio de las clases de atributos no terminales. Si consideramos que las instancias hacen el papel de nodos, los valores de atributos no terminales son flechas apuntando desde una instancia origen a otra destino, esta propiedad indica la clase de estructura que se pueden crear: un conjunto de árboles (trees), un grafo acíclico dirigido (GAD), o un grafo (sin restricciones).

• Propiedades: relaciona otras propiedades que pueda tener la estructura creada, por ejemplo, simetría, transitividad, etc. En REFSENO existen 4 clases de atributos no terminales predefinidos, muy

similares a las clases de asociaciones en UML:

• “es-un”: su nombre inverso es “está-especializado-en”. Denota una especialización de un concepto. Su estructura es un árbol. Sus principales propiedades son la transitividad, la herencia simple y que el nodo raíz del árbol es “CONCEPT”.

• “es-instancia -de”: su inverso es “está-instanciado-en”. Es un caso especial de clase “es-un” que vincula una instancia con su concepto (en vez de dos conceptos). Su estructura es un árbol de sólo dos niveles, es decir, sin nodos intermedios.

• “incluye-a”: que tiene como inverso a “es-parte-de”. Se refiere a una descomposición en la cual las partes se pueden compartir por más de un concepto. Su estructura es un GAD y cumple la propiedad de transitividad.

• “está-compuesto-por”: cuyo nombre inverso es “es-componente-de”. Denota una agregación, es decir, una descomposición en la que los componentes sólo existen si existe el compuesto agregado. Las clases de atributos no terminales adicionales a las anteriores se representan

en una tabla de clases de atributos no terminales, que incluye una fila por cada clase con los valores de las cinco propiedades de su tupla.

2.3.3. Tipos. Todos los atributos terminales son tipados. Los tipos de atributos modelan

cualidades de las entidades de ingeniería del software (por ejemplo, número de líneas de código de un módulo) o se utilizan para especificar otras entidades (por ejemplo, el tipo “lenguaje de programación” de una entidad “módulo de código”). Un tipo está definido por la 5-tupla siguiente:

• Nombre: es único para una ontología.

• Supertipo: es el tipo del que un tipo hereda propiedades. Un tipo se puede diferenciar de su supertipo tan sólo en el rango de valores, en la unidad de medida o en la función de similaridad. El supertipo puede ser un tipo predefinido, otro tipo definido en la ontología o el tipo raíz denotado por “TYPE”.


10

• Rango de valores: posibles valores de los atributos de este tipo. Existen tres valores predefinidos especiales: “indefinido”, “desconocido” y “n/a” (no aplicable).

• Unidad de Medida: sólo es aplicable para tipos numéricos.

• Sim: función de similaridad definida con fines de consulta. Existe una colección de tipos predefinidos a partir de los cuales se pueden

derivar subtipos. Los tipos ordenados, es decir, con un orden predefinido entre sus valores son: “entero”, “real”, “texto”, “identificador”, fecha”, “tiempo”, “marca de tiempo” y “símbolo ordenado”. Los tipos no ordenados son “booleano”, “símbolo”, “taxonomía de símbolos” e “intervalo”.

Los tipos se representan en una tabla de tipos que incluye una fila por cada tipo.

Los tipos están ordenados alfabéticamente por su nombre. Para cada tipo se indican los cinco valores de su tupla de definición. El rango de valores se puede representar como una lista de rangos no solapados, siendo cada rango una pareja de valores (mínimo, máximo), donde el * representa un -8 para el mínimo y +8 para el máximo. También se puede realizar una enumeración de los posibles valores. Para tipos numéricos los valores se escriben ordenados. Para tipos simbólicos, los valores se escriben entrecomillados y en una estructura que depende del supertipo del que se hereda:

• si el supertipo es “símbolo”, los símbolos se colocan alfabéticamente;

• si el supertipo es “símbolo ordenado”, los símbolos se ordenan de menor a mayor; y

• si el supertipo es “taxonomía de símbolos”, entonces los símbolos se colocan en una jerarquía textual formateada mediante sangrados, similar al índice de un libro. Para los tipos simbólicos, es decir, aquellos cuyos valores son símbolos que

tienen semántica asociada, la representación incluye un glosario de símbolos. El glosario de símbolos es una tabla, con las columnas tipo, símbolo y descripción, que muestra todos los símbolos de una ontología agrupados por el tipo (del atributo).

2.3.4. Instancias. Afortunadamente, no es necesario que todas las instancias que forman la

extensión de cada concepto se incluyan en una ontología. De hecho, lo normal es que sólo unas pocas (o ninguna) se tengan que considerar porque aportan un conocimiento de contexto específico interesante. Por ejemplo, se podrían incluir instancias de “medición” que son obligatorias y muy importantes para el éxito de un “programa de medición”. Sus sinónimos son: caso, caracterización y objeto. Una instancia está definida por una 3-tupla con las propiedades siguientes:


• Concepto: indica el concepto a cuya extensión pertenece la instancia. La intensión de la instancia coincide con la intensión de este concepto.

• Valores: la lista de valores de los atributos de la instancia.


11

Una instancia se representa por una tabla de instancia (ver Tabla 1). Cada tabla

de instancia permite conocer los valores de cada uno de los atributos de una instancia mediante las columnas capa (ver apartado 2.3.2.1), atributo y valor. Además, en el encabezamiento de la tabla se indican el concepto y el nombre de la instancia.

Concepto: Medición GQM Instancia: Contador-Fallos-1

Capa Atributo Valor

Id Contador-Fallos-1

Definición Cuenta el número de informes de fallo recibidos antes de la entrega

Escala Entero positivo artef

Unidades Número de ocurrencias

Asunción Se supone que se recibe un informe de fallo por cada fallo detectado i/f

Procedimiento recogida datos “desconocido”

ctxt Plan GQM “desconocido” Tabla 1. REFSENO: Ejemplo de una Tabla de Instancia

2.3.5. Otras Primitivas.

Las fórmulas se utilizan, con fines de consulta, en funciones de similaridad,

aserciones, precondiciones y valores inferidos. Permiten modelar, entre otros, los aspectos siguientes:

• similaridad entre artefactos de ingeniería del software,

• similaridad entre valores, y

• dependencias entre valores. Una fórmula es similar a una regla. Consiste en un término matemático en el que

las variables son atributos de conceptos. REFSENO incluye una colección de operadores, constantes, funciones y valores especiales (por ejemplo, “n/a”) predefinidos para poder utilizarlos en las fórmulas. 2.4. Adaptación de REFSENO

El uso de UML como lenguaje de representación ontológica en ingeniería del

software ha sido propuesto por diversos autores [14]. Además, esta opción está en consonancia con los fundamentos ontológicos de UML según el estudio llevado a cabo por Guizzardi et al en [15]. Esta es la razón por la cual, como sugiere Ruiz en [16], haremos un uso importante de UML para representar gráficamente la Ontología de la Medición Software en los apartados próximos. Otra ventaja del uso de UML es que se pueden utilizar sus posibilidades de extensión, especialmente mediante estereotipos descriptivos o restrictivos y mediante extensiones, regulares o restrictivas, del


12

metamodelo UML [17]. Además, esta representación gráfica se completará con una representación textual semi-formal basada en el formalismo REFSENO.

Buscando una mayor sencillez, claridad y compactación de la información,

utilizaremos la adaptación del formalismo REFSENO propuesta por Ruiz en [16], que se basa en las siguientes consideraciones:

a) No considerar las primitivas epistémicas, tablas o columnas de tablas que se

refieren a aspectos de la etapa de implementación física de la ontología (por ejemplo, tablas de instancias o funciones de similaridad).

b) No incluir columnas de tablas que se refieren a aspectos con fines de consulta (por ejemplo, funciones de similaridad).

c) Utilizar diagramas de clases UML para representar las piezas de información principales de la ontología. En concreto se incluyen los conceptos (el nombre), sus atributos (el nombre) y sus interrelaciones (llamadas atributos no terminales en REFSENO). De estas últimas se indican el nombre, sus roles (cuando están definidos), las cardinalidades máxima y mínima de cada participante y la clase de interrelación (clase del atributo no terminal). Las clases de interrelaciones predefinidas “es-un”, “incluye-a” y “está-compuesto-por” se representan como generalizaciones, agregaciones y composiciones UML, respectivamente, mientras que las demás clases se representan como asociaciones UML indicando su clase como estereotipo de la asociación.

d) Evitar redundancias de información entre los diagramas y las tablas, usando las tablas sólo para indicar información adicional a la que aparece en los diagramas. Como consecuencia de estas consideraciones, las primitivas epistémicas de

REFSENO, se modifican de la siguiente manera [16]:

• La jerarquía de herencia entre conceptos se incluye en el glosario de conceptos mediante la inclusión de una columna para el super-concepto.

• La colección de tablas de atributos terminales y no terminales de los conceptos se agrupa en dos tablas únicamente: la primera llamada tabla de atributos con los terminales y la segunda, tabla de interrelaciones, con los no terminales2.

• En las tablas anteriores se elimina la columna capa porque no aporta información de interés, además, los atributos de la capa de artefacto siempre son terminales y los de la capa de contexto no terminales, y van a sus respectivas tablas. Los atributos de la capa de interfaz o son de implementación (y entonces no interesa tratarles) o no, y por tanto van en la tabla de atributo.

• Las tablas de tipos y de clases de interrelaciones (clases de atributos no terminales) son opcionales y sólo se incluyen si se han definido por el diseñador tipos o clases de especial interés en la ontología. Igual ocurre con el glosario de símbolos.

2 Puesto que los atributos no terminales equivalen a los finales de asociación de las interrelaciones correspondientes, se ha cambiado la nomenclatura porque así se cree que resulta más evidente la semántica subyacente.


13

Con estos cambios, se hace efectiva una ganancia en legibilidad, sencillez y

claridad en comparación con la representación en REFSENO pura.


14

33.. AAnnáálliissiiss ddee llaa SSiittuuaacciióónn AAccttuuaall.. En este apartado se presentará el análisis comparativo de los estándares más

relevantes en el campo de la medición, realizado por García et al. en [7]. Para este estudio, han sido seleccionados como fuentes los estándares

internacionales y propuestas de investigación que se relacionan con la terminología y los conceptos de la medición del software.

De IEEE han sido seleccionados el IEEE Std. 610.12-1992 (Standard Glossary

of Software Engineering Terminology) [18] e IEEE Std. 1061-1998 (IEEE Standard for a Software Quality Metrics Methodology) [19]. De ISO e IEC, la serie ISO/IEC 14598:2001 (Software Engineering - Product Evaluation) [20], el ISO VIM (International Vocabulary of Basic and General Terms in Metrology [6]), y el estándar ISO/IEC 15939 (Software Engineering - Software Measurement Process) [21].

También han sido incluidas otras propuestas de investigación relevantes

relacionadas con la medición del software, como la de Lionel Briand et al. [2] y la de Barbara Kitchenham et al. [22]. La ontología general de la empresa propuesta por Henry Kim [23] ha sido también considerada en el análisis, una vez que contiene una sub-ontología para términos y conceptos de la medición. Otras propuestas que utilizan terminología de la medición (algunas veces adaptadas para sus dominios particulares) también han sido analizadas aunque no estén incluidas en el estudio comparativo porque o son muy específicas, o claramente están influenciadas por otra propuesta previamente considerada.

Analizando las fuentes seleccionadas, se ha llegado a la conclusión de que los

diferentes estándares y propuestas se pueden organizar en tres grupos principales, dependiendo del tópico particular de la medición al que hacen enfoque: medidas del software (software measures), procesos de medición (measurement processes) y objetivos-y-metas (targets-and-goals). El primer grupo de conceptos, medidas del software, se ocupa de los elementos principales implicados en la definición de las medidas del software, incluyendo términos como medida, escala, unidad de medición, etc. El segundo grupo, procesos, está relacionado con las acciones de medir procesos y productos software, incluyendo la definición de términos como medición, resultado de la medición, método de medición, etc. Finalmente, el tercer grupo, objetivos-y-metas, trata los conceptos necesarios para establecer el alcance y los objetivos del proceso de medición del software, es decir, modelo de calidad, entidad medible, atributo, necesidad de información, etc.

Ninguna fuente cubre los tres grupos. Además, el conjunto de conceptos

cubiertos por cada fuente no es homogéneo, ni el mismo para aquellas que se enfocan en el mismo grupo. Sin embargo, hay una tendencia en las fuentes para convergir hacia esos tres grupos principales, a lo largo de su evolución en el tiempo. Esta es la razón por la que las diferentes fuentes analizadas se representan en orden cronológico.


15

3.1. IEEE Std. 610.12 (1992). Este es un glosario de terminología de Ingeniería del Software. No incluye

términos relacionados específicamente con la medición del software, o términos que se pueden deducir de su significado en inglés tradicional.

Por ejemplo, los términos “entidad”, “atributo” y “métrica” están definidos pero

sin un foco especial en la medición del software. Además, no se encontró ningún otro término relacionado con la medición del software en este estándar.

3.2. VIM (1993). El Vocabulario Internacional de Términos Básicos y Generales en Metrología

(International Vocabulary of Basic and General Terms in Metrology) cubre 120 términos de temas relacionados con la medición. Aunque su propósito principal no es el software, ha sido utilizado con éxito por varios autores como Alain Abran para la definición de conceptos de la medición del software [24], y es una de las bases para los esfuerzos de armonización de la medición del software ISO-JTC1.

El VIM es una referencia muy detallada, completa y madura. Sin embargo, sus

términos aún se encuentran en un nivel muy detallado – por ejemplo, no hay definiciones para términos generales como “métrica” o “medida”. Se espera que la nueva versión del VIM, actualmente en preparación, se ocupe de las necesidades específicas de la medición del software.

3.3. IEEE Std. 1061 (1998). El IEEE Std. 1061-1998 es un estándar para una metodología de métricas de

calidad del software. Este estándar es una revisión del IEEE Std. 1061-1992. Proporciona una metodología para establecer requisitos de calidad y para identificar, implementar, analizar, y validar medidas de calidad del proceso y del producto software. Esta metodología se aplica a todo el software en todas las fases de cualquier ciclo de vida del software, pero sin prescribir métricas específicas.

Este estándar cubre conceptos de los tres grupos (medidas, procesos, y objetivos-

y-metas), pero no de una manera completa y exhaustiva – que no es la meta principal del estándar, de todas formas.

Se encontraron discrepancias entre este estándar y el del IEEE 610.12, que se

producen y mantienen por la misma organización. Por ejemplo, la definición de “métrica” en IEEE 610.12 se diferencia de la definición dada en IEEE 1061. Esto está reconocido explícitamente en el último estándar.


16

3.4. Kim (1999). Henry Kim [23] propone un modelo formal de calidad en la empresa llamado

“Ontología del modelado de la calidad en la empresa”. Su propuesta es una ontología global, cuyo objetivo principal es ayudar a evaluar la conformidad de las organizaciones con respecto a los estándares ISO/IEC 9000. Como parte de su ontología global, Kim también propone una ontología de la medición.

Aunque la ontología de la medición de Kim no es específica para procesos y

productos software, contiene muchos conceptos que se pueden aplicar dentro del contexto de la medición del software. Bajo esta perspectiva, la propuesta de Kim se centra principalmente en objetivos-y-metas, incluyendo conceptos tales como “requisito de calidad”, “entidad”, “modelo de calidad de la empresa”, y “atributo medido”. No define, sin embargo, conceptos como “medida”, “métrica” o "escala", por ejemplo.

3.5. ISO/IEC 14598 (1999-2001) y 9126 (2001-2004). El ISO/IEC 14598 (Tecnología de información – Evaluación del producto

software) es una serie de estándares internacionales que proporcionan métodos para la medición, valoración y evaluación de la calidad del producto software. Las diversas partes de esta serie dibujan un cuadro genérico del proceso de evaluación, tratado desde el punto de vista de los desarrolladores, clientes y evaluadores (terceros).

Los estándares de la serie ISO/IEC 14598 se concentran principalmente en el

conjunto de conceptos en el grupo de las medidas, y parcialmente en cubrir algunos de los aspectos del proceso de la medición. La serie ISO/IEC 14598 hace uso la serie ISO/IEC 9126 (Ingeniería del Software – Calidad del Producto – Partes 1 a 4), que propone un modelo de calidad del producto software, y métricas para la calidad interna, calidad externa y calidad en uso.

Ambas series ISO/IEC 9126 e ISO/IEC 14598 comparten una terminología

común, y están actualmente bajo revisión. El proyecto SQuaRE [25] se ha creado específicamente para que converjan, intentando eliminar puntos sin resolver, los conflictos y las ambigüedades que presentan actualmente. De hecho, se ha autorizado la publicación de ISO/IEC TR 9126-2, 9126-3 y 9126-4 como Informes Técnicos entre 2002 y 2004 sin cambiar su terminología original, con el acuerdo de que serían alineados con los nuevos términos de la medición de SC7 lo antes posible. La serie ISO/IEC 25000 será el resultado final de este proyecto de convergencia.

3.6. Kitchenham et al. (2001). Barbara Kitchenham et al. [22] propone un método para especificar modelos de

conjuntos de datos del software con el objetivo de capturar las definiciones y las relaciones entre medidas software.

Proponen un modelo conceptual con tres componentes. Primero, el componente

genérico (generic component), que define conceptos tales como atributos, unidades, y tipos de la escala, independientemente de otras consideraciones. El modelo de


17

desarrollo (development model) proporciona el enlace entre las medidas y las entidades de interés. Finalmente, el dominio del proyecto (project domain) representa los valores de los datos recogidos de proyectos reales, uniendo valores de datos a instancias actuales de las entidades que se definen en el dominio del modelo de desarrollo.

Esta propuesta enfoca principalmente medidas del software y objetivos-y-metas, pero sin considerar el proceso de medición detalladamente. Además, su terminología no está totalmente alineada con el resto de los estándares y propuestas. Por ejemplo, el concepto de “medida” (measure) se representa por el término “tipo de medida del elemento del modelo de desarrollo” (DM element measure type), que se diferencia significantemente de los términos “métrica” (metric) o “medida” (measure), probablemente los términos más comúnmente usados en el resto de las fuentes para representar este concepto.

3.7. Briand et al. (2002). Lionel Briand et al. proponen el método GQM/MEDEA para definir medidas de

atributos de productos en la ingeniería del software. Esta propuesta está regida por las metas experimentales de la medición, expresadas vía el paradigma GQM [26] y un conjunto de hipótesis empíricas.

Esta propuesta provee un diagrama de clase UML con los conceptos implicados

en el proceso GQM/MEDEA. Esos conceptos GQM/MEDEA relacionados con la medición del software enfocan principalmente en objetivos-y-metas de la medición (por ejemplo, entidad, atributo). No considera, por ejemplo, los conceptos “medición” o “escala”, y no distingue entre medidas base y derivadas.

Una de las características específicas de esta propuesta es que sus conceptos no

están definidos, apenas presentados para su uso en el proceso GQM/MEDEA.

3.8. ISO/IEC 15939 (2002) y PSM (2002). El estándar ISO/IEC 15939 identifica las actividades y las tareas necesarias para

identificar, definir, seleccionar, aplicar y mejorar con éxito la medición del software dentro de un proyecto o una estructura de medición organizacional. También provee definiciones para términos de medición comúnmente usados dentro de la industria del software.

Los dos componentes clave incluidos en este estándar son proceso de medición

del software (software measurement process) y modelo de información de la medición (measurement information model). El proceso de medición del software está dirigido por las necesidades de información de la organización. Por cada necesidad de información este proceso produce un producto de información que intenta satisfacerlo.

El modelo de información de la medición establece el vínculo entre medidas y

necesidades de información. Las entidades de la medición incluyen procesos, productos, proyectos y recursos. El modelo describe cómo los atributos relevantes se cuantifican y se convierten en indicadores que proporcionan una base para la toma de decisión.


18

ISO/IEC 15939 enfoca principalmente los conceptos del proceso de medición, aunque también cubre muchos de los conceptos de los otros dos grupos (medidas del software y objetivo-y-metas). Para medidas del software se apoya básicamente en los conceptos de ISO/IEC 14598 y de ISO/IEC 9126, aunque cambia algunos de los términos para alinearse lo máximo posible con ISO VIM. Por lo tanto, no utiliza el término “métrica” relacionando directamente los términos “medición” y “medida”.

ISO/IEC 15939, junto con VIM, se ha convertido en el estándar usado por ISO-

JTC1 como la base para sus esfuerzos de armonización de la terminología de la medición del software [27].

Otra referencia clave, el PSM (Practical Software Measurement – Medición

Práctica del Software) [28], es compatible con ISO/IEC 15939, y por lo tanto utiliza la misma terminología.

3.9. Otros Modelos, Estándares y Propuestas. La medición del software también forma parte de otros modelos y estándares.

Probablemente los ejemplos más representativos incluyen la valoración del proceso y los modelos de madurez, como por ejemplo CMMI e ISO/IEC 15504, el estándar 12207 del Ciclo de Vida del Software y la familia de estándares de la medición funcional del tamaño de ISO/IEC. Estas propuestas no se han considerado en el análisis de la comparación porque, o bien utilizan la terminología definida por otras propuestas ya incluidas en este estudio, o bien definen un vocabulario muy específico para dominios particulares.

Este documento tampoco menciona otros estándares e informes técnicos de

ISO/IEC relacionados con la medición, tal como la serie ISO/IEC 14143 (Partes 1 a 6) que está alineada con el VIM, y otros cuatro estándares de ISO/IEC para métodos de Medición Funcional del Tamaño, incluyendo ISO/IEC 19761 (COSMIC-FFP) que también está totalmente alineado con el VIM.

• En CMMI, la medición se trata en un área de proceso clave, a saber “Medición y

Análisis”. CMMI adopta la terminología de ISO/IEC 15939, en particular “medidas base” y “medidas derivadas”. También adapta algunos términos para la valoración del proceso, como por ejemplo, “medición del proceso” y “objetivo cuantitativo”.

• ISO/IEC 15504 utiliza su propia terminología de la medición adaptada al dominio de valoración del proceso. Incluye términos tales como “Meta del Proceso Software”, “Métrica del Proceso Software”, “Objetivo del Proceso Software” y “Medición Actual del Proceso Software”. También utiliza “Medida”, “Medición” y “Técnicas de Medición”, aunque sin establecer definiciones explícitas para estos términos.

• La terminología de medición del software usada en ISO/IEC 12207 se adopta directamente de la serie ISO/IEC 9126.

• La familia de estándares de la medición funcional del tamaño de ISO/IEC (incluyendo la serie 14143 e ISO/IEC 19761, COSMIC-FFP) está totalmente alineada con el VIM.


19

• Finalmente, algunos autores han intentado adaptar los conceptos de la teoría de la medición al dominio de la medición del software. Sin embargo, el uso de la teoría de la medición no ha contribuido para reducir los problemas de terminología. Por ejemplo, la teoría de la medición distingue entre los conceptos “medida” y “métrica” (una medida es “un homomorfismo que es un trazado del mundo empírico al mundo de los números, preservando la estructura” y una métrica es “un criterio para determinar la distancia entre dos entidades” [29]). Sin embargo, se pierde esta distinción cuando aplicada a la medición del software; algunos autores apoyan la idea de que las medidas se pueden considerar como métricas, y por lo tanto, la diferencia entre estos dos conceptos no es esencial. Los términos medida y métricas también se utilizan en matemáticas, pero con un significado matemático muy específico, y no en el sentido general usado en la medición del software (una “medida” es una función, y una “métrica” es un tipo especial de medida que sirve para calcular distancias entre puntos en un espacio métrico).

3.10. Problemas Encontrados. Tras comparar diversas fuentes se encontraron las siguientes cuestiones:

• Homonimia (por ejemplo, el término “métrica” tiene dos significados distintos en los estándares IEEE 610.12 e IEEE 1061);

• Sinonimia (por ejemplo, el término “medida” de Briand y el término “métrica” de ISO/IEC 14598 parecen representar el mismo concepto);

• No todos los términos y conceptos aparecen en todas las propuestas, incluso si las propuestas enfocan el mismo grupo de conceptos (por ejemplo, el término y el concepto de “métrica” no aparecen en ISO/IEC 15939 – parecen estar integrados dentro de otros términos y conceptos);

• No hay tratamiento uniforme de algunos de los conceptos básicos de la medición del software tales como: “medidas base”, “medidas derivadas” o “indicadores”; ni hay acuerdos en las propuestas para medirlos;

• El hecho de que ningún estándar o propuesta cubra todos los conceptos obstaculiza su integración (se encuentra el mismo problema cuando se tiene que integrar diversas vistas de una base de datos sin un esquema común). Una vez que se desarrollaron los estándares y propuestas de investigación por

separado y en períodos diferentes, es normal que existan diferencias entre ellos. Esta es la razón por la cual se requiere un esfuerzo de armonización que proporcione una vista común y que elimine las diferencias y conflictos.


20

44.. UUnnaa OOnnttoollooggííaa CCoommúúnn.. Teniendo en cuenta el análisis comparativo presentado en el apartado anterior, se

identifican las siguientes metas [7]:

• localizar e identificar los sinónimos, homónimos, lagunas y conflictos;

• generalizar las diversas propuestas para medir atributos;

• proporcionar una integración uniforme de los conceptos de los tres grupos; así se pueden construir los procesos de medición utilizando medidas claramente definidas, mientras que los modelos de calidad identifican los objetivos y las metas de los procesos de medición. Una de las formas de alcanzar tales metas es a través de una ontología común de

la medición del software, capaz de identificar todos los conceptos, proporcionar definiciones exactas para todos los términos, y clarificar las relaciones entre ellos. Tal ontología común puede servir como base para comparar los diversos estándares y propuestas, ayudando, así, a alcanzar la armonización y el proceso de convergencia necesarios para todos ellos.

Otro requisito importante para tal ontología de la medición del software es que

sus términos estén de acuerdo con la terminología general aceptada en otros campos, incluyendo la medición, que es un campo bastante maduro que posee un conjunto muy amplio de términos. Esto también está de acuerdo con la posición actual de ISO/IEC y de la Sociedad Computacional IEEE que, para asegurar consenso y consistencia con otros campos de las ciencias, tomaron la decisión en el año 2002 de alinear sus terminologías en la medición con los estándares internacionalmente aceptados en este campo. En particular, ISO-JTC1-SC7 está intentando seguir tanto como sea posible el Vocabulario Internacional de términos básicos y generales en la Metrología de ISO (VIM).

En esta sección presentaremos la ontología de la medición del software

propuesta por García et al. en [7]. Para facilitar su comprensión, se ha divido en cuatro sub-ontologías, siguiendo el modelo propuesto en [8] y hemos adaptado su estructura de acuerdo con el formalismo de REFSENO (ver apartado 2).

REFSENO fue desarrollado específicamente para la ingeniería del software.

Permite varias representaciones para el conocimiento en la ingeniería del software mientras que otras propuestas, por ejemplo [30, 31, 32], sólo permiten representaciones que son menos intuitivas para gente no familiarizada con la lógica de predicados de primer orden (o similares). Además, REFSENO tiene una terminología clara, distinguiendo entre el conocimiento conceptual y contexto-específico, permitiendo así la gestión del conocimiento desde diferentes contextos. REFSENO también ayuda a construir ontologías consistentes gracias al uso de criterios de consistencia. Finalmente, REFSENO almacena experiencia en forma de documentos, y no como conocimiento codificado. Esto resulta en una importante reducción del esfuerzo de aprendizaje, a veces asociado típicamente a los sistemas basados en el conocimiento [33].

La ontología de la medición del software se basa principalmente en los

estándares ISO VIM e ISO/IEC 15939. También incluye algunos términos que no se


21

encuentran en estos dos documentos (por ejemplo, “modelo de calidad”) que son clave en la medición del software, y presenta algunas discrepancias con 15939, por ejemplo, el tratamiento de indicadores (este tema será discutido más adelante en la sección 4.2.2).

En particular, las principales propiedades y características de la Ontología de la

Medición del Software (SMO) son las siguientes:

• Utiliza el término “medida” en vez de “métrica”.

• Diferencia entre “medida”, “medición” y “resultado de la medición”.

• Distingue entre medidas base, medidas derivadas e indicadores, pero considerándolos todos como medidas y generaliza sus respectivas formas de medición (método de medición, función de cálculo y modelo del análisis).

• Integra las medidas del software con el modelo de calidad que define las necesidades de información que conducen el proceso de medición.

4.1. Ontología de la Medición del Software (SMO). En este apartado se presenta la ontología de la medición del software,

representada de acuerdo con el formalismo REFSENO. La primera etapa del proceso es la especificación de la ontología que contiene el

dominio modelado, el ámbito y el propósito de la ontología e algunas informaciones administrativas como los autores y las fuentes de conocimiento.

Aunque en la definición del alcance se recomienda incluir la lista de conceptos, por razones de claridad y extensión, se opta por dejar este detalle para la definición de cada una de las ontologías parciales, como se verá más adelante. En su lugar, en el alcance se indica la estructura básica en que ha sido organizada la ontología de la medición del software.

No se han incluido instancias porque como ya se ha dicho en el apartado 2, en

este documento no se contemplan los aspectos de implementación. Igualmente no se han definido atributos comunes a varios conceptos por separado sino que, en su caso, se añaden en cada una de las ontologías parciales.


22

En la Tabla 2 se muestra la especificación de la ontología de la medición del software:

Concepto Valor

Dominio Gestión de la Medición del Software

Autor(es)

Félix García, Coral Calero, Francisco Ruíz, Mario Piattini, Marcela Genero : Grupo Alarcos (Universidad de Castilla-La Mancha – España); Manuel F. Bertoa, Antonio Vallecillo: Dept. de Lenguajes y Ciencias de la Computación (Universidad de Málaga – España).

Propósito Proveer una terminología consistente para la medición del software, a través de la armonización de los diferentes estándares y propuestas de investigación en esta área.

Nivel de Formalidad Semi-formal (diagramas de clases UML y tablas y texto REFSENO).

Alcance

Lista de conceptos: Se han clasificado (por razones de claridad) en las siguientes sub-ontologías:

• Sub-ontología de Caracterización y Objetivos. • Sub-ontología de Medidas Software. • Sub-ontología de las Formas de Medir. • Sub-ontología de la Medición.

Lista de instancias: ninguna. Atributos de conceptos comunes: ninguno.

Fuentes de conocimiento utilizadas Ver Tabla 3

Tabla 2. Especificación de requisitos de la ontología de la medición del software.

Las fuentes documentales utilizadas para desarrollar la ontología de la medición del software se presentan en la Tabla 3:

Clave Fuente Documental

FD1 Propuesta de Ontología para la Medición del Software de García et al. [34].

FD2 Estándar IEEE 610.12-1992 (Standard Glossary of Software Engineering Terminology) [18].

FD3 Estándar IEEE 1061-1998 (IEEE Standard for a Software Quality Metrics Methodology) [19].

FD4 Estándar ISO/IEC 14598:2001 series (Software engineering - Product evaluation) [20].

FD5 Estándar ISO VIM (International Vocabulary of Basic and General Terms in Metrology) [6].

FD6 Estándar ISO/IEC 15939 (Software engineering - Software measurement process) [21].

FD7 Ontología del modelado de la calidad en la empresa de Henry Kim [23].

FD8 Método para la especificación de modelos de conjuntos de datos del software de Kitchenham et al. [22].

FD9 Método GQM/MEDEA para la definición de medidas de atributos de productos en la ingeniería del software de Briand et al. [2].

Tabla 3. Fuentes documentales utilizadas en la ontología de la medición del software.


23

Una vez concretada la especificación de los requisitos de la ontología, la etapa siguiente consiste en definir la ontología propiamente dicha (fase de conceptualización).

Para facilitar la comprensión, en el proceso de representación de la ontología de

la medición del software se optó por dividirla en cuatro sub-ontologías, basándose en el modelo propuesto en [8]. Así, la SMO se organiza de la siguiente forma:

a) Caracterización y Objetivos de la Medición Software, que incluye los

conceptos necesarios para establecer el ámbito y los objetivos del proceso de medición software. El principal objetivo del proceso de medición software es satisfacer ciertas necesidades de información identificando las entidades (que pertenecen a categoría de entidad) y los atributos de estas entidades (que son el enfoque del proceso de medición). Atributos y necesidades de información están relacionados por medio de conceptos medibles (que pertenecen a modelo de calidad).

b) Medidas Software, que trata de establecer y aclarar los elementos clave en la definición de una medida software. Una medida relaciona un método de medición definido y una escala de medición (que pertenece a tipo de escala). La mayoría de las medidas pueden ser expresadas en una unidad de medición, y pueden ser definidas para más de un atributo (Medidas nominales son ejemplos de medidas que no pueden ser expresadas en unidades de medición). Las medidas pueden ser de 3 tipos: medidas base, medidas derivadas e indicadores.

c) Formas de Medir. Esta sub-ontología introduce el concepto de forma de medir para generalizar los diferentes “métodos” usados por los tres tipos de medidas para obtener sus respectivos resultados de medición. Una medida base aplica un método de medición. Una medida derivada usa una función de cálculo (que se apoya en otra medida base y/o derivada). Por fin, un indicador utiliza un modelo de análisis (basado en un criterio de decisión) para obtener un resultado de medición que satisfaga a una necesidad de información.

d) Medición. Establece la terminología relacionada con el acto de medir el software. Una medición (que es una acción) es un conjunto de operaciones cuyo objetivo es determinar el valor de un resultado de medición para un dado atributo de una entidad, utilizando una forma de medir. Los resultados de la medición se obtienen a través de la acción de llevar a cabo una medición. Estas cuatro sub-ontologías se relacionan directamente con los tres grupos

principales de conceptos identificados anteriormente. Así, la primera sub-ontología corresponde al grupo de objetivos-y-metas. La sub-ontología de las medidas software corresponde al grupo de las medidas. Las dos últimas sub-ontologías juntas cubren el grupo de proceso de medición.

Cada una de las sub-ontologías que componen la ontología de la medición del

software se describen con mayor detalle en los siguientes apartados.

4.1.1. Sub-Ontología de la Caracterización y Objetivos de la Medición Software. Todo proceso de medición del software tiene como objetivo fundamental

satisfacer necesidades de información. Un proceso de medición no puede obtener


24

resultados útiles si éstos no satisfacen alguna necesidad de información detectada en la empresa en la que se lleva a cabo.

La Sub-Ontología de la Caracterización y Objetivos de la Medición Software

incluye los elementos necesarios para identificar las entidades sobre las que se puede aplicar un proceso de medición, los atributos de dichas entidades sobre los que se calculan las medidas software, y los objetivos fundamentales del proceso de medición mediante la definición de las necesidades a satisfacer con dicho proceso. Esta información es fundamental para definir el contexto en el que se establece la medición del software.

En la Figura 1 se muestra la representación gráfica de los conceptos y relaciones

de esta sub-ontología, utilizando el diagrama de clases UML:

Entidad0..*0..*

compuesta de

Categoría de Entidad

0..*

1..*

0..*

1..*

pertenece a

0..*

0..*

0..*

incluye

0..*

Atributo

1..*1 1..*1

tiene

Modelo de calidadclase

*

1

*

1

definido para

Concepto Medible

1..*

1..*

1..*

1..*

relaciona

1..*1..* 1..*1..*

evalúa

0..*

0..*

0..*

sub-Concepto Medible

0..*

Necesidad de Información

1..*

1

está relacionado con

1..*

1

Figura 1. Diagrama de la Sub-Ontología Caracterización y Objetivos de la Medición Software.

Los conceptos centrales de esta sub-ontología son Necesidad de Información,

Atributo y Entidad. La Tabla 4 muestra el glosario de conceptos, expresado en la variante del

formalismo REFSENO que ha sido presentada en el apartado 2.4, y está organizada de la siguiente forma: la primera y segunda columna muestran el nombre del término (concepto) que está siendo descrito y su super-concepto en la ontología, respectivamente; la columna 3 contiene la descripción del término en la SMO; la columna 4 dibuja algunos ejemplos y, finalmente, la columna 5 muestra la fuente (estándar o propuesta) de donde el término fue adoptado, de acuerdo con la Tabla 3.


25

Concepto Super Concepto Descripción Ejemplos Fuente


Concept

Información necesaria para gestionar un proyecto (sus objetivos, hitos, riesgos y

problemas).

Conocer el nivel de productividad de los programadores del

proyecto en comparación con lo habitual en otros

proyectos en la organización.

FD6

Concepto Medible Concept

Relación abstracta entre atributos y necesidades de

información.

Ratio de productividad de un equipo de desarrollo

frente a un grado de productividad objetivo.

FD6

Entidad Concept Un objeto que va a ser

caracterizado mediante una medición de sus atributos.

El programa “HolaMundo.c” FD6


Concept Una colección de entidades caracterizadas por satisfacer un cierto predicado común.

“Programas”, “Programas en C”, “Componentes

software”, “Componentes COTS”, “Componentes

software para comunicaciones”.

Nuevo

Atributo Concept

Una propiedad mensurable, física o abstracta, que

comparten todas las entidades de una categoría de entidad.

Tamaño de código fuente. Adaptado de FD4

Modelo de Calidad

Concept

Un conjunto de conceptos medibles y relaciones entre

ellos que proporciona la base para especificar requisitos de

calidad y evaluar la calidad de las entidades de una

determinada categoría de entidad.

Modelo de calidad para productos software de

ISO 9126.

Adaptado de FD4

Tabla 4. Sub-ontología Caracterización y Objetivos de la Medición Software: glosario de conceptos.

La siguiente tabla muestra las interrelaciones de esta sub-ontología. La primera columna muestra el nombre de la relación; la segunda, los conceptos que relaciona, seguidos de sus respectivas cardinalidades entre paréntesis; por fin, la tercera columna trae la descripción de la relación presentada.


26

Nombre Conceptos (Cardinalidad) Descripción

Incluye Categoría de Entidad (0..*) – Categoría de Entidad (0..*)

Una categoría de entidad puede incluir una o varias categorías de entidad, y puede estar

incluida en una o varias categorías de entidad.

Definido para Modelo de Calidad (*) – Categoría de Entidad (1)

Un modelo de calidad está definido para una determinada categoría de entidad. Una categoría de entidad puede tener definidos varios modelos

de calidad.

Evalúa Modelo de Calidad (1..*) – Concepto Medible (1..*)

Un modelo de calidad evalúa uno o varios conceptos medibles. Un concepto medible es evaluado por uno o más modelos de calidad.

Pertenece a Entidad (0..*) – Categoría de Entidad (1..*)

Una entidad puede pertenecer a una o varias categorías de entidad. Una categoría de entidad

puede caracterizar varias entidades.

Relaciona Concepto Medible (1..*) – Atributo (1..*)

Un atributo está relacionado con uno o más conceptos medibles. Un concepto medible

relaciona uno o más atributos.

Está relacionado

con

Concepto Medible (1) – Necesidad de Información

(1..*)

Un concepto medible está relacionado con una o varias necesidades de información. Una necesidad

de información se relaciona con un concepto medible.

Incluye Concepto Medible (0..*) – Concepto Medible (0..*)

Un concepto medible puede incluir a varios conceptos medibles y puede estar incluido en otros

conceptos medibles.

Compuesta de Entidad (0..*) – Entidad (0..*) Una entidad puede estar compuesta de otras entidades.

Tiene Categoría de Entidad (1) – Atributo (1..*)

Una categoría de entidad tiene uno o varios atributos. Un atributo solo puede pertenecer a una

categoría de entidad. Tabla 5. Sub-ontología Caracterización y Objetivos de la Medición Software: tabla de interrelaciones.

La tabla de atributos (Tabla 6) se organiza de la siguiente forma: la primera

columna indica el concepto al cual pertenece el atributo; las columnas 2 y 3 traen el nombre y la descripción del atributo, respectivamente; la columna 4 muestra el tipo del atributo y, finalmente, la columna 5 muestra su cardinalidad.

Concepto Atributo Descripción Tipo Card

Modelo de Calidad Clase Indica el tipo de modelo de calidad. Enumerado 1

Tabla 6. Sub-ontología Caracterización y Objetivos de la Medición Software: tabla de atributos.

En el diagrama de la Figura 1 se ha cambiado el sentido de la asociación “está

relacionado con” con respecto a la figura original del MMSGarcía. El resto del diagrama no ha sufrido ninguna mejora.


27

4.1.2. Sub-Ontología de las Medidas Software. Una vez identificados los atributos objeto de la medición, se debe definir las

medidas software necesarias para llevar a cabo el proceso de medición. La Sub-Ontología de las Medidas Software tiene como objetivo describir y

aportar el conocimiento relacionados con las medidas software, presentando sus características generales. En la definición general de una medida software se deben especificar aspectos como la unidad en la que se expresa, la escala a la que pertenece, el atributo o atributos para los que se define, etc.

La Figura 2 presenta el diagrama UML de los conceptos de esta sub-ontología e

sus relaciones, donde el concepto central es Medida:

Medida Derivada IndicadorMedida Base

Atributo(from Caracterización y Objetivos)

Unidad de Medición

Medida

0..*

1..*

se define para

0..*

se transforma en

0..*

0..1

1..*

expresada en

Tipo de Escala

Escala11..*

tiene

1

1..*pertenece a

Figura 2. Diagrama de la Sub-Ontología de las Medidas Software.

El glosario de conceptos y las interrelaciones de esta sub-ontología se muestran

en las siguientes tablas:


28


Atributo Véase Sub-Ontología “Caracterización y Objetivos”

Medida Concept

La forma de medir (método de medición, función de cálculo o modelo de análisis) y la escala

de medición.

La medida “líneas de código” puede ser

definida para realizar mediciones del “tamaño” de un “módulo en C” y

para realizar mediciones del “tamaño” de un “programa en Ada”.

Adaptado de FD4

“métrica”

Escala Concept Un conjunto de valores con propiedades definidas.

El nivel de madurez CMM: 1, 2, 3, 4, 5

(Ordinal), el tamaño de un código software

expresado en líneas de código: Conjunto de los

números naturales (Ratio), etc.

FD4

Tipo de Escala Concept

Indica la naturaleza de la relación entre los valores de la

escala

Nominal, Ordinal, Intervalo, Ratio y

Absoluta FD6

Unidad de Medición

Concept

Una cantidad particular, definida y adoptada por

convención, con la que se puede comparar otras

cantidades de la misma clase para expresar sus magnitudes

respecto a esa cantidad particular

Kilómetros, metros, millas; Líneas de código,

Páginas, Persona-mes; Número de módulos,

Número de clases.

FD5

Medida Base Medida

Una medida de un atributo que no depende de ninguna

otra medida, y cuya forma de medir es un método de

medición.

LCF (líneas de código fuente escritas), HPD (horas-programador

diarias), CHP (coste por hora-programador, en unidades monetarias).

Adaptado de FD4 “métrica directa”

Medida Derivada

Medida

Una medida que es derivada de otra medida base o

derivada, utilizando una función de cálculo como

forma de medir.

HPT (horas-programador totales, que es la

sumatoria de las HPD de cada día), LCFH (líneas

de código fuente por hora de programador), CTP (coste total actual del proyecto, en unidades monetarias, que es el

producto del coste unitario de cada hora por

el total de horas empleadas).

Adaptado de FD4 “métrica

indirecta”

Indicador Medida

Una medida que es derivada de otras medidas utilizando un

modelo de análisis como forma de medir.

PROD (productividad de los programadores), CAR

(carestía del proyecto). Nuevo

Tabla 7. Sub-ontología de las Medidas Software: glosario de conceptos.


29


Pertenece a Escala (1..*) – Tipo de Escala (1)

Toda escala pertenece a un cierto tipo de escala. Un tipo de escala puede caracterizar una o más

escalas.

Se define para Medida (0..*) – Atributo (1..*) Una medida está definida para uno o más

atributos. Un atributo puede tener varias medidas asociadas.

Se transforma en Medida (0..*) – Medida (0..*)

Dos medidas pueden relacionarse mediante una función de transformación. El tipo de dicha

función de transformación va a depender del tipo de escala de las escalas.

Expresada en Medida (1..*) – Unidad de Medición (0..1)

Una medida puede expresarse en una unidad de medición (sólo para medidas cuya escala sea de tipo intervalo o ratio). Una unidad de medición

sirve para expresar una o varias medidas cuyo tipo de escala sea intervalo o ratio.

Tiene Medida (1..*) – Escala (1) Una medida tiene una escala. Una escala puede estar relacionada con una o más medidas.

Tabla 8. Sub-ontología de las Medidas Software: tabla de interrelaciones 4.1.3. Sub-Ontología de las Formas de Medir.

La definición de las medidas software se debe realizar a distintos niveles o alcances, ya que resultaría excesivamente complejo definir de forma directa medidas a partir de las cuales se satisfagan las necesidades de información. Por ello, es fundamental definir en primer lugar medidas software que se aplican directamente sobre las características de una entidad para evaluar un determinado atributo. A partir de estas medidas base se pueden definir medidas derivadas y finalmente se podrían definir medidas con el objetivo de proporcionar información útil para la toma de decisiones, y por lo tanto, más cercanas a satisfacer las necesidades de información.

Estos aspectos se tratan en la Sub-Ontología de las Formas de Medir, en la que

se identifican los métodos concretos para definir o calcular las medidas software definidas en función de su tipo.

Esta sub-ontología tiene como objetivo describir y aportar el conocimiento

relacionado con los distintos mecanismos existentes para la medición software. En la Figura 3 se representan los conceptos de esta sub-ontología y sus relaciones:


30

Forma de Medir(from Acción de Medir)

Método de Medición

Medida Derivada(from Medidas Software)

Medida Base(from Medidas Software)

1

1..*

usa

Función de Cálculo1

1..*calculada con

0..*

0..*

usa0..*

0..*usa

Necesidad de Información(from Caracterización y Objetivos)

Indicador(from Medidas Software)

0..*

1..*

satisface

Medida(from Medidas Software)

Criterio de Decisión

Modelo de Análisis

1

1..*

calculado con

1..*

0..*

usa

1..*

1..*

usa

..Figura 3. Diagrama de la Sub-Ontología de las Formas de Medir

Como se puede observar en la Figura 3, los conceptos centrales son Método de

Medición, Función de Cálculo y Modelo de Análisis. Las tablas siguientes muestran el glosario de conceptos y las interrelaciones de

esta sub-ontología:


31


Necesidad de Información Véase Sub-Ontología “Caracterización y Objetivos”


Forma de Medir

La forma de medir una medida base. Secuencia lógica de operaciones, descritas de

forma genérica, usadas para realizar mediciones de un

atributo respecto de una escala específica.

Contar líneas de código; anotar cada día las horas

dedicadas por los programadores al

proyecto.

Adaptado de FD6

Función de Cálculo

Forma de Medir

La forma de medir una medida derivada. Algoritmo o cálculo realizado para combinar dos o

más medidas base y/o derivadas.

LCFH = LCF / HPT [medida derivada definida en base a 2 medidas base]

HPT = ∑díasHPD

[medida derivada definida en base a sólo 1 medida

base] CTP = CHP * HPT

[medida derivada definida en base a 2 medidas, una

base y otra derivada].

Adaptado de FD6

Modelo de Análisis

Forma de Medir

La forma de medir un indicador. Algoritmo o cálculo realizado para

combinar una o más medidas (base, derivadas o indicadores)

con criterios de decisión asociados.

Modelo de Análisis para obtener la medida PROD. Modelos de Análisis para obtener la medida CAR.

Adaptado de FD6

Criterio de Decisión Concept

Valores umbral, objetivos, o patrones, usados para

determinar la necesidad de una acción o investigación

posterior, o para describir el nivel de confianza de un

resultado dado.

LCFH/LCFHvm < 0’70 ?

PROD=’muy baja’. 0’70 & LCFH/LCFHvm <

0’90 ? PROD=’baja’. 0’90 & LCFH/LCFHvm < 1’10 ? PROD=’normal’.

1’10 & LCFH/LCFHvm < 1’30 ? PROD=’alta’.

1’30 & LCFH/LCFHvm ? PROD=’muy alta’.

FD6

Forma de Medir Véase Sub-Ontología “Acción de Medir”

Indicador Véase Sub-Ontología “Medidas Software”

Medida Véase Sub-Ontología “Medidas Software”

Medida Base Véase Sub-Ontología “Medidas Software”

Medida Derivada Véase Sub-Ontología “Medidas Software”

Tabla 9. Sub-ontología de las Formas de Medir: glosario de conceptos.


32


Calculada con Medida Derivada (1..*) – Función de Cálculo (1)

Una medida derivada es calculada con una función de cálculo. Una función de cálculo define una o

más medidas derivadas.

Calculado con Indicador (1..*) – Modelo de Análisis (1)

Un indicador es calculado con un modelo de análisis. Un modelo de análisis puede definir uno o

más indicadores.

Usa Medida Base (1..*) – Método de Medición (1)

Una medida base usa un método de medición. Un método de medición define una o más medidas

base.

Satisface Necesidad de Información (0..*) – Indicador (1..*)

Un indicador satisface necesidades de información. Una necesidad de información se satisface con uno

o más indicadores.

Usa Función de Cálculo (0..*) – Medida Derivada (0..*)

Una función de cálculo puede usar varias medidas derivadas. Una medida derivada puede usarse en

funciones de cálculo.

Usa Función de Cálculo (0..*) – Medida Base (0..*)

Una función de cálculo puede usar varias medidas base. Una medida base puede usarse en funciones

de cálculo.

Usa Modelo de Análisis (0..*) – Medida (1..*)

Un modelo de análisis usa una o más medidas. Una medida puede usarse en modelos de análisis.

Usa Modelo de Análisis (1..*) – Criterio de Decisión (1..*)

Un modelo de análisis usa uno o más criterios de decisión. Un criterio de decisión puede usarse en

uno o más modelos de análisis.

Tabla 10. Sub-ontología de las Formas de Medir: tabla de interrelaciones.

4.1.4. Sub-Ontología de la Acción de Medir.

Esta sub-ontología está compuesta por los elementos necesarios para describir

cómo se lleva a cabo el proceso de medición propiamente dicho, a partir de la definición de las medidas software y de la caracterización de los atributos de las entidades objeto de la medición, mediante la realización de mediciones que como resultado obtienen medidas.

En la Figura 4 se representan los conceptos de esta sub-ontología y sus

relaciones, donde el concepto central es la Medición:


33

Forma de Medir

Resultado de la Medición

valor


Entidad(from Caracterización y Objetivos)


MedicióninstanteTemporal

1 *ejecuta

1

1

produce

1

*

se realiza sobre

1

*

se realiza sobre

1

*

usa

Figura 4. Diagrama de la Sub-Ontología de la Acción de Medir.

El glosario de conceptos, las interrelaciones y los atributos de esta sub-ontología

se muestran en las siguientes tablas:


34


Atributo Véase Sub-Ontología “Caracterización y Objetivos”

Entidad Véase Sub-Ontología “Caracterización y Objetivos”

Forma de Medir

Concept

Secuencia de operaciones cuyo objeto es determinar el

valor del resultado de la medición. Una forma de medir

puede ser un método de medición, función de cálculo o

modelo de análisis.

Véanse ejemplos de método de medición, función de cálculo o

modelo de análisis, ya que la forma de medir es una generalización de ellos

(sub-ontología Formas de Medir).

Nuevo

Medición Concept

Conjunto de operaciones que permite obtener el valor del

resultado de la medición para un atributo de una entidad, usando una forma de medir.

Acción consistente en usar la forma de medir “contar el número de líneas de código” para

obtener el resultado de la medición del atributo

“tamaño” de la entidad “módulo nominas.c”.

Adaptado de FD5


Concept

Categoría o número asignado a un atributo de una entidad

como resultado de una medición.

35.000 líneas de código, 200 páginas, 50 clases, 5 meses desde el comienzo

al fin del proyecto, 0.5 fallos por cada 1000

líneas de código.

Adaptado de FD4

“Medida”

Medida Véase Sub-Ontología “Medidas Software”

Tabla 11. Sub-ontología de la Acción de Medir: glosario de conceptos.


Ejecuta Medición (*) – Forma de Medir (1)

Una medición es la acción de ejecutar una forma de medir (la clase de forma de medir será

determinada pelo tipo de medida usada para llevar a cabo la medición). Una forma de medir es utilizada

para llevar a cabo una medición.

Produce Medición (1) – Resultado de la Medición (1)

Cada medición produce un resultado de medición. Cada resultado de medición es la consecución de

llevar a cabo una medición.

Se realiza sobre Medición (*) – Atributo (1)

Una medición se realiza para un atributo de una entidad. El atributo ha de estar definido para la

categoría a la que pertenece dicha entidad.

Se realiza sobre

Medición (*) – Entidad (1)

Una medición se realiza sobre una entidad a través de uno de sus atributos. El atributo ha de estar

definido para la categoría a la que pertenece dicha entidad.

Usa Medición (*) – Medida (1) Una medición usa una medida. Una medida puede ser usada en varias mediciones.

Tabla 12. Sub-ontología de la Acción de Medir: tabla de interrelaciones.


35

Concepto Atributo Descripción Tipo Card

Medición InstanteTemporal Momento en que se realiza la medición. Fecha/Hora 1

Resultado de la Medición Valor Valor que representa el resultado de

una medición. Variant 1

Tabla 13. Sub-ontología de la Acción de Medir: tabla de atributos.

4.1.5. Integración de las Sub-Ontologías. En la Figura 5 se muestra el diagrama UML completo de la ontología de la

medición del software, mostrando todos sus términos, atributos e interrelaciones:

Medida Derivada(from Medidas Software)

Función de Cálculo(from Formas de Medir)

1

1..*

calculada con

0..*

0..*

usa

Método de Medición(from Formas de Medir)

Medida Base(from Medidas Software)

0..*

0..*

usa

1

1..*

usa

Necesidad de Información(from Caracterización y Objetivos)

Modelo de Calidad

clase

(from Caracterización y Objetivos) Concepto Medible(from Caracterización y Objetivos)

0..*

incluye

0..*

1..*1..* evalúa

1

1..*está relacionado con

Categoría de Entidad(from Caracterización y Objetivos)

0..*

incluye

0..* 1

*

definido para

Tipo de Escala(from Medidas Software)

Criterio de Decisión(from Formas de Medir)

Indicador(from Medidas Software)

0..*

1..*

satisface

Unidad de Medición(from Medidas Software)

Escala(from Medidas Software)

1

1..*

pertenece a

Modelo de Análisis(from Formas de Medir)

1..*

1..*

usa

1

1..*

calculado con


valor

(from Acción de Medir)


1..*

1..*

relaciona

1..*1 tiene

Entidad(from Caracterización y Objetivos)

0..*

compuesta de

1..*

0..*

pertenece a


0..*1..*

se define para

0..1

1..*

expresada en

1

1..*

tiene

0..*

se transforma en

0..*

1..*

0..*

usa

Forma de Medir(from Acción de Medir)

Medición

instanteTemporal

(from Acción de Medir)

11produce

1

*

se realiza sobre

1 *

se realiza sobre

1

*

usa

1

*

ejecuta

Figura 5. Diagrama de la Ontología de la Medición del Software.

A través de esta ontología se establecen y clarifican los conceptos y relaciones

relevantes relacionados con la medición del software, a partir de los cuales se puede definir la información necesaria que hay que recoger y establecer para llevar a cabo un proceso de medición adecuado y efectivo. Además, se proporciona una forma de comunicación en una empresa en el contexto de sus procesos de medición, basada en el uso de una terminología común, lo que facilita no sólo el entendimiento entre miembros del equipo responsables de realizar dichas actividades de medición, sino también la posibilidad de registrar los resultados de dicho proceso de una forma consistente e integrada [8].

Caracterización y Objetivos

Medidas Software

Formas de Medir

Acción de Medir


36

4.2. Discusión. De todas las cuestiones relacionadas con la medición del software, hay dos que

merecen una discusión especial: 1. El uso del término “métrica”, que actualmente está siendo desvinculado del

medio por parte de muchos expertos en medición;

2. La cuestión de los “indicadores”: ¿son un tipo de medida o no? Los siguientes apartados tratan de tentar responder a estas preguntas.

4.2.1. “Métrica” vs “Medida”. Actualmente una de las cuestiones más polémicas entre los expertos en la

medición del software es uso del término métrica. Aunque está ampliamente utilizado y aceptado por muchos estudiosos e investigadores, este término también cuenta con muchos detractores que defienden las siguientes razones en contra de su uso: primero, hablando formalmente, una métrica es una función que mide la distancia entre dos entidades y por lo tanto se define con propiedades matemáticas precisas de una distancia; en segundo lugar, la definición de métrica proporcionada por ambos diccionarios, general y técnico, no refleja el significado con el cual se utiliza informalmente en la medición del software. Además, métrica es un término que no está presente en la terminología de medición de ninguna otra disciplina de ingeniería, por lo menos no con el significado que se utiliza comúnmente en la medición del software. Por lo tanto, el uso del término “métrica software” parece ser impreciso, mientras que el término “medida software” parece ser más apropiado para representar este concepto.

Todos los nuevos esfuerzos de armonización de ISO/IEC e IEEE están

intentando evitar el uso de métrica con el objetivo de alinearse con el resto de las disciplinas de medición que utilizan normalmente el vocabulario definido en Metrología.

Sin embargo, el uso del término medida tampoco está libre de controversia en la

medición del software y esto es lo que probablemente está obstaculizando una aceptación más amplia por parte de los expertos que actualmente apoyan el uso de “métrica”. Por ejemplo, ISO/IEC 15939 (hasta ahora el estándar mejor alineado con la terminología VIM) define medida como resultado de la medición. Este estándar define los términos medida base y medida derivada como tipos particulares de medida. Como se observa, el concepto de medida usado en estos dos últimos conceptos no parece representar el resultado de la medición, sino que representa la combinación de escala de medición y del método de medición (es decir, lo que ISO/IEC 14598 define como métrica). El problema con este concepto no está definido en ISO/IEC 15939.

La situación no es mejor en ISO/IEC 14598. Este estándar define métrica como

la combinación de escala de medición y de método de medición, y define medida como resultado de la medición. Sin embargo, inconsistentemente utiliza también medida directa y medida indirecta. Es decir, aunque ISO/IEC 14598 los define como tipos de medidas, en realidad se utilizan como tipos de métricas.


37

La SMO presentada en este documento propone superar este problema

distinguiendo entre medida y resultado de la medición. Se cree que es una solución acertada,. El término medida agrega la escala de medición y el método de medición (y, por lo tanto, medida base y medida derivada pueden ser definidas y utilizadas consistentemente), mientras que el término resultado de la medición contiene el producto de la realización de una medición. Así, el término métrica no es necesario en la ontología presentada.

4.2.2. Indicador: ¿es un tipo de medida o no? ISO/IEC 15939 e ISO/IEC 14598 introducen el término indicador. Aunque en

ambos estándares este término parece representar el mismo concepto, las definiciones dadas en ellos difieren significantemente (véase Tabla 16).

ISO/IEC 15939 no utiliza ningún término predefinido (por ejemplo, medida)

para definir indicador. En este estándar, indicador se define como “una estimación o evaluación de los atributos específicos derivados de un modelo con respecto a necesidades de información definidas”. Sin embargo, está directamente relacionado con medidas base y derivada de ISO/IEC 15939.

En ISO/IEC 14598, un indicador se define como tipo de medida (no una

métrica, es decir, es un resultado de la medición en los términos de la SMO), aunque parece compartir las mismas propiedades de una métrica en la terminología de ISO/IEC 14598 (es decir, una medida en los términos de la SMO).

Lo que se percibe es que ambos estándares parecen estar de acuerdo en que los

indicadores son tipos de medidas, pero fallan en la definición del término como tal y lo utilizan constantemente (en ISO/IEC 14598 se define como medida, pero después se utiliza como métrica, y en ISO/IEC 15939 incluso no se define como medida). La razón parece ser otra vez los términos métrica y medida mal definidos en ambos estándares (como discutido en la sección anterior).

En la SMO, la definición de medida permite definir indicadores de una manera

consistente. Comparten las características de medidas (en los términos de la SMO) porque tienen una escala y un método de medición. En el caso de los indicadores, el método de medición es un modelo del análisis. En este sentido, los indicadores son medidas (según la definición de medida de la SMO).

4.3. Análisis Comparativo. La Ontología de la Medición del Software se utilizó como base para el análisis

comparativo de la terminología usada en las diversas propuestas. El análisis comparativo, extraído de [7], se presenta en cuatro tablas, una para cada sub-ontología (Tabla 14 a la Tabla 17).

Cada tabla está indexada por su columna izquierda que contiene el término de la

ontología que es descrito. La segunda columna muestra la fuente (estándar o propuesta)


38

donde aparece el término, de acuerdo con la Tabla 3. La definición propuesta del concepto representado por el término se muestra en la columna 3.

Para cada término, puede haber más de una fila en caso de conflictos o

discrepancias entre las diferentes fuentes. La primera fila contiene la definición del concepto según la SMO. En general, el término ha sido adoptado de uno de los estándares que aparecerán como la fuente del término. El resto de las filas asociadas a un término describe las definiciones alternativas para ese término.

En aquellos casos en que el concepto representado esté nombrado de forma

distinta (sinonimia), el término se incluye en la tercera columna entre corchetes, antes de la definición del concepto.

Puede también ser el caso de filas sin la definición para un término si la fuente lo

utiliza pero no proporciona una definición explícita para él.

Término Fuente Definición

Forma de Medir

Secuencia de operaciones cuyo objeto es determinar el valor del resultado de la medición. Una forma de medir puede ser un método de

medición, función de cálculo o modelo de análisis.

Medición Conjunto de operaciones que permite obtener el valor del resultado de

la medición para un atributo de una entidad, usando una forma de medir.

FD5, FD6 Conjunto de operaciones que tienen como objetivo determinar un valor de una medida.

FD4 El uso de una métrica para asignar un valor (que puede ser un número o una categoría) de una escala a un atributo de una entidad.

FD7

Proceso por el cual números o símbolos son asignados a atributos de entidades del mundo real de forma a describirlos según reglas

claramente definidas. La medición puede ser interpretada como los medios por los cuales se determina si una entidad está conforme con la

calidad.

FD3 La acción o proceso de asignación de un número o categoría a una entidad para describir un atributo de esta entidad. Una figura, un

grado, o una cantidad obtenida a través de la acción de medir.

Resultado de la Medición FD4 [Medida] Categoría o número asignado a un atributo de una entidad

como resultado de una medición.

FD6 [Medida] Variable para la cual un valor es asignado como el resultado de una medición.

FD8 [Valor Grabado]

FD7 [Punto de Medición] Un valor para un atributo medido de una entidad en un dado momento del tiempo.

FD9

FD3 (A) Una manera de comprobar o estimar el valor, comparándolo a una norma. (B) Aplicar una métrica.

FD3 [Valor de la Métrica] La salida (resultado) de una métrica o un elemento que está en el rango de una métrica.

Tabla 14. Comparación de los términos en la sub-ontología de la Acción de Medir.


39


Necesidad de Información FD6 Información necesaria para gestionar un proyecto (sus objetivos, hitos,

riesgos y problemas).

FD9 [Objetivo Corporativo]

FD7 [Requisito de Calidad] Una restricción organizacional que se refiere a la calidad de una entidad.

Concepto Medible FD6 Relación abstracta entre atributos y necesidades de información.

Entidad FD6 Un objeto que va a ser caracterizado mediante la medición de sus atributos.

FD9

FD8 [Ocurrencia de Objeto de Proyecto]

FD7

FD2 En programación computacional, cualquier ítem que puede ser

nombrado o denotado en un programa. Por ejemplo, un ítem de dato, una declaración del programa, o un subprograma.

Categoría de Entidad Una colección de entidades caracterizadas por satisfacer un cierto

predicado común.

FD8 [Tipo de Elemento del Modelo de Desarrollo]

Atributo Una propiedad mensurable, física o abstracta, que comparten todas las entidades de una categoría de entidad.

FD4 Una propiedad mensurable, física o abstracta, de una entidad.

FD5 [Cantidad Mensurable] Atributo de un fenómeno, cuerpo o sustancia que puede distinguir cualitativamente y determinar cuantitativamente.

FD6 Propiedad o característica de una entidad que puede ser distinguida cuantitativamente o cualitativamente por un ser humano o de forma

automática.

FD2 Una característica de un ítem; por ejemplo, el color, tamaño o tipo.

FD9

FD8 [Atributo Genérico]

FD7 [Atributo Medido] Característica física de entidades que son medidas. Son atributos que adquieren un valor a través de la medición.

FD3 Una propiedad mensurable, física o abstracta, de una entidad.

Modelo de Calidad

Un conjunto de conceptos medibles y relaciones entre ellos que

proporciona la base para especificar requisitos de calidad y evaluar la calidad de las entidades de una determinada categoría de entidad.

FD4 Conjunto de características y de relaciones entre ellas que proporciona la base para especificar requisitos de calidad y evaluar la calidad

FD8 [Modelo de Desarrollo]

FD7

[Modelo de Calidad de la Empresa] Modelo que puede ser usado para responder cuestiones sobre la calidad de los productos y procesos de

una empresa. También puede ser usado para identificar oportunidades de mejora en la calidad y sugerir medios para llevar a cabo las

mejoras.


40


FD3

[Marco de Trabajo de las Métricas] Una asistencia a la decisión usada para organizar, seleccionar, comunicar, y evaluar los atributos de

calidad requeridos para un sistema software. Una clasificación jerárquica de los factores de calidad, de los sub-factores de calidad, y

de las métricas para un sistema software. Tabla 15. Comparación de los términos en la sub-ontología Caracterización y Objetivo de la Medición

Software.


Medida La forma de medir (método de medición, función de cálculo o modelo de análisis) y la escala de medición.

FD4 [Métrica] el método definido de medición y la escala de medición.

FD2 [Métrica] Una medida cuantitativa de un grado para el cual un sistema, un componente o un proceso poseen un dado atributo

FD9

FD8 [Tipo de Elemento de Medición del Modelo de Desarrollo]

FD3 [Métrica] Una función cuya entrada son datos software y cuya salida

es un valor numérico simple, que puede ser interpretado como el grado para el cual el software posee un dado atributo que afecta su calidad.

Escala FD4 Un conjunto de valores con propiedades definidas.

FD5

[Escala de valor-referencia ] Para cantidades particulares de un dado tipo, un conjunto de valores ordenados, continuos y discretos,

definidos por convención como una referencia para organizar las cantidades de aquél tipo en orden de magnitud.

FD6 Conjunto de valores ordenados, continuos o discretos, o un conjunto de categorías para las cuales un atributo es asignado.

FD8 [Rango de Escala Genérico]

Tipo de Escala FD6 Indica la naturaleza de la relación entre los valores de la escala

Unidad de Medición FD5, FD6

Una cantidad particular, definida y adoptada por convención, con la que se puede comparar otras cantidades de la misma clase para

expresar sus magnitudes respecto a esa cantidad particular

FD4 [Unidad] Una cantidad adoptada como un estándar de medición

FD8 [Unidad Genérica]

FD7

Medida Base Una medida de un atributo que no depende de ninguna otra medida, y cuya forma de medir es un método de medición.

FD5 [Cantidad Base] Una de las cantidades que, en un sistema de

cantidades, son convencionalmente aceptadas como funcionalmente independientes una de las otras.

FD6 Medida definida en términos de un atributo y del método para

cuantificarlo. (Nota: Una medida base es funcionalmente independiente de otras medidas).

FD4 [Medida Directa] Medida de un atributo que no depende de la medida de ningún otro atributo.

FD3 [Métrica Directa] Una métrica que no depende de ninguna medida de otro atributo


41


Medida Derivada Una medida que es derivada de otra medida base o derivada,

utilizando una función de cálculo como forma de medir.

FD5 [Cantidad Derivada] Cantidad definida, en un sistema de cantidades, como una función de cantidades base de aquél sistema.

FD6 Medida que está definida como una función de dos o más valores de medidas base.

FD4 [Medida Indirecta] Una medida de un atributo que es derivada de otras medidas de uno o más atributos.

Indicador Una medida que es derivada de otras medidas utilizando un modelo de análisis como forma de medir.

FD6 Una estimativa o evaluación de atributos específicos derivados de un modelo con respecto a una determinada necesidad de información.

FD4 Una medida que puede ser usada para estimar o predecir otra medida.

Tabla 16. Comparación de los términos en la sub-ontología de las Medidas Software.



La forma de medir una medida base. Secuencia lógica de operaciones, descritas de forma genérica, usadas para realizar mediciones de un

atributo respecto de una escala específica.

FD5 Secuencia lógica de operaciones, descritas genéricamente, usadas para llevar a cabo las mediciones.

FD6 Secuencia lógica de operaciones, descritas genéricamente, usadas para

cuantificar un atributo con respecto a una escala específica.

Función de Cálculo La forma de medir una medida derivada. Algoritmo o cálculo

realizado para combinar dos o más medidas base y/o derivadas.

FD6 Un algoritmo o cálculo realizado para combinar dos o más “medidas base”.

Modelo de Análisis

La forma de medir un indicador. Algoritmo o cálculo realizado para

combinar una o más medidas (base, derivadas o indicadores) con criterios de decisión asociados.

FD6 Algoritmo o cálculo combinando una o más medidas base y/o derivadas con un criterio de decisión asociado.

Criterio de Decisión FD6

Valores umbral, objetivos, o patrones, usados para determinar la necesidad de una acción o investigación posterior, o para describir el

nivel de confianza de un resultado dado.

FD4 [Nivel de Valoración] Un punto de la escala en una escala ordinal, que se utiliza para categorizar una escala de medición.

Tabla 17. Comparación de los términos en la sub-ontología de las Formas de Medir.

Resumiendo estos resultados, se puede concluir que se analizaron ocho fuentes (5 estándares internacionales y 3 propuestas de investigación académicas), y se ha presentado una ontología común (SMO [7]) que se puede utilizar como punto de partida para armonizar y unificar todas ellas.

Se identificaron un total de 20 conceptos de medición del software diferentes,

para los cuales 77 definiciones diferentes fueron encontradas (que da un promedio de


42

3.85 definiciones distintas por concepto). Los términos con más definiciones son la atributo (9), medida (7), métrica (6), medición (6), unidad (6), entidad (5), métrica directa (5) y modelo de la calidad (5). Éstos son, por supuesto, los conceptos más esenciales, que demuestran claramente el desacuerdo entre las fuentes originales a la hora de definirlos (incluso los más básicos). Además, se encontraron 28 casos de sinonimia, que también confirma la falta de consenso en la terminología.

De acuerdo con los términos cubiertos por las diversas propuestas, ISO/IEC

15939 (FD6) es el que define más conceptos (16 de los 20). Después, la serie ISO/IEC 14598 (FD4) que cubre 11 conceptos, seguida por las propuestas de Kitchenham (FD8) (8), VIM (FD5) (7), Kim (FD7) (7), IEEE 1061 (FD3) (7), Briand (FD9) (5), y finalmente IEEE 610.12 (FD2), que cubre apenas 3 de los 20 conceptos. El alto número de términos adoptados directamente de ISO/IEC 15939 (FD6) se debe al hecho de que es un estándar de medición, mientras que las otras fuentes y estándares definen términos de medición solamente para sus propósitos y dominios de aplicación particulares.

Es importante también analizar el origen de los términos propuestos en la SMO.

Se pueden distinguir cuatro casos distintos:

• Conceptos adoptados, que se han tomado directamente de una fuente, sin ningún cambio en sus definiciones o en los términos usados para identificarlos (por ejemplo, entidad).

• Conceptos adaptados, que se han tomado prestados de una propuesta pero se han cambiados por consistencia o integridad (véase las tablas de comparación para identificar los cambios). En cada entidad adaptada, se podrían modificar el término original o la definición original, lo que hace necesario distinguir entre:

− Conceptos con definición adaptada, si el término ha sido tomado de la fuente pero se ha cambiado ligeramente su definición original en la SMO (por ejemplo, atributo).

− Conceptos con término adaptado, si se ha tomado la definición del concepto de la fuente pero el término usado en la SMO es diferente (por ejemplo, medida).

• Conceptos nuevos, que son entidades introducidas por la SMO y que no se encuentra en ninguna de las fuentes (por ejemplo, forma de medir), o cuyo significado final no corresponde exactamente a ninguna de las fuentes (por ejemplo, indicador). De acuerdo con estas clasificaciones, hay tres nuevos conceptos el SMO (15%),

ocho conceptos adoptados (40%) y nueve conceptos adaptados (45%). Los nuevos conceptos son formas de medir, categoría de entidad y indicador.

Una forma de medir es un concepto abstracto que representa la generalización del método de medición, función de cálculo y modelo de análisis. Es abstracto en el sentido de UML, es decir, es un concepto general que no tiene instancias – solo sirve para generalizar las características comunes de un grupo de otros conceptos.


43

El concepto categoría de entidad representa la clase de todas las entidades del mismo tipo. Es necesario en la ontología porque los atributos son definidos, en general, por categorías de entidad, y no por entidades particulares. Por ejemplo, tamaño es un atributo definido para la clase de todos los programas en C.

Finalmente, aunque el término indicador no es nuevo, hablando estrictamente se

considera como nuevo: ambos, ISO/IEC 15939 e ISO/IEC 14598 lo definen pero con un significado diferente del utilizado en la SMO (véase sección 4.2.2).

Se han adoptados, sin ningún cambio, ocho términos (40%), con sus respectivas

definiciones. Seis de ellos son de ISO/IEC 15939 (necesidad de información, concepto medible, tipo de escala, criterio de decisión y método de medición), uno de ISO VIM (unidad de medición) y uno de ISO/IEC 14598 (escala).

Se adapataron nueve de los veinte conceptos de la SMO (45%): seis de ISO/IEC

14598 (modelo de calidad, atributo, medida, medida base, medida derivada, resultado de la medición), dos de ISO/IEC 15939 (función de cálculo y modelo de análisis) y una de ISO VIM (medición).


44

55.. UUnn MMeettaammooddeelloo ppaarraa llaa MMeeddiicciióónn ddeell SSooffttwwaarree..

5.1. Introducción.

MOF (OMG, 2002a) es el estándar definido por OMG (Object Management Group) para la definición, representación y gestión de metadatos. MOF y sus especificaciones asociadas incluyen:

- La arquitectura MOF de 4 niveles de metadatos, que proporciona un patrón genérico para la construcción de sistemas centrados en los metadatos.

- El modelo MOF es el lenguaje estándar y abstracto para los metamodelos que definen diferentes clases de metadatos.

- El repositorio de metamodelos MOF proporciona un servicio estándar para crear, modificar, validar y acceder a los metamodelos.

- La especificación XMI define las correspondencias que soportan el intercambio de metadatos y metamodelos basados en MOF.

El marco de trabajo establecido por el estándar MOF se describe típicamente como

una arquitectura conceptual de cuatro capas de metadatos como la mostrada en la Tabla 18:

Nivel MOF Ejemplo M3 Modelo MOF

(Meta-metamodelo)

M2 Meta-Modelo UML Entidad/Interrelación M1 Modelo Modelo Coche en UML M0 Datos Coche concreto (real)

Tabla 18. Arquitectura en 4 niveles de MOF Como se puede observar en la tabla anterior, el nivel tres está formado por el

modelo MOF, que constituye el metalenguaje para la definición de metamodelos y que es lo que distingue esta especificación de otras basadas en este tipo de arquitecturas conceptuales. Los tres elementos principales de modelado proporcionados por MOF son: Clase, Asociación y Paquete. Estos conceptos son similares a los correspondientes en UML, pero con algunas simplificaciones. El modelo MOF proporciona la sintaxis abstracta necesaria para definir distintos metamodelos, lo que permite la gestión integrada de los mismos. 5.1. Estructura Básica.

Lo primero es tener en cuenta la diferencia entre una ontología y un

metamodelo. Las ontologías son conceptualizaciones de un dominio identificando qué conceptos existen y cuáles son sus relaciones. Los metamodelos son modelos para crear otros modelos y se usan en el contexto de la arquitectura de MOF (pertenecen a nivel M2). Las ontologías son independientes de arquitecturas conceptuales y tecnologías mientras que los metamodelos no. Una ontología podría por ejemplo tener conceptos de M2 y M1 en la arquitectura MOF.


45

Debido a la importancia de se derivar modelos concretos de medida, hemos adaptado el Metamodelo de la Medición del Software propuesto por García en [8] a la nueva Ontología de Medición del Software presentada en la sección 4.1.

La Figura 6 muestra la estructura de paquetes en la que se basa el metamodelo

de la medición:

Básico

Caracterización y Objetivos

Acción de Medir

Formas de Medir

Medidas

Figura 6. Estructura de Paquetes del Metamodelo de la Medición.

Tal y como se puede observar en la Figura 6, el metamodelo de la medición está

compuesto de un paquete básico que representa las características generales de los constructores básicos de modelos de medición, y de otros cuatro paquetes (Caracterización y Objetivos, Acción de Medir, Formas de Medir y Medidas), de acuerdo con las cuatro sub-ontologías de la SMO. Para la construcción de este metamodelo, se tuvo en cuenta la conceptualización establecida en la Ontología de la Medición Software, pero añadiendo los constructores específicos desde el punto de vista de la implementación.

Como la mayoría de los conceptos de la SMO pertenecen al nivel de

metamodelado M2, no ha sido necesario realizar una transformación significativa de la misma para la construcción del metamodelo, excepto a la hora de incorporar un paquete orientado a la implementación de los conceptos de la ontología, mediante su definición como constructores de medición.

A la hora de elaborar la ontología de la medición la mayoría de los conceptos

que se identifican (medida, necesidad de información, concepto medible, etc.. ) son candidatos a ser elementos de un metamodelo. En el metamodelo de la medición corresponden con elementos de modelado a nivel M2 porque permiten construir instancias en un modelo de medición concreto a nivel M1. Sin embargo en el mundo del metamodelado es difícil que una ontología pueda traducirse tal cual a un metamodelo sin incluir elementos específicos de implementación. Es por eso que se ha añadido un paquete llamado básico que utiliza el estilo de UML para definir sus elementos como


46

elementos de modelado y asociarle propiedades típicas de un metamodelo y no del dominio de conceptualización.

A continuación se describen los paquetes que componen el metamodelo de la

medición. Como la estructura de los paquetes casi siempre coincide con los conceptos y relaciones de las sub-ontologías, sólo se describen sus características más relevantes. 5.2. Paquetes. 5.2.1. Paquete Básico.

El paquete básico se ha definido con el objetivo de identificar y establecer las características generales de los constructores necesarios para definir modelos de medición. La Figura 7 muestra el diagrama de clases UML que representa la estructura de este paquete:


Entidad

AtributoModelo de

Calidadclase


Medición


Forma de Medir

MedidaUnidad

EscalaTipo

Criterio de Decisión

Descripciónnombre : Stringcontenido : String

Elemento de Mediciónnombre : String

0..* 1

descrito con

Concepto Medible

Figura 7. Paquete Básico.

Como se puede observar en la Figura 7, el elemento general a partir del cual se

construyen modelos de medición es el constructor “Elemento de Medición”. Un elemento de medición tiene un nombre y puede ser descrito mediante elementos de tipo “Descripción”, que aportan información adicional a los elementos de la medición, lo que facilita un mejor entendimiento de los modelos de medición desarrollados. A partir del elemento de medición se especializan los constructores fundamentales de la medición, obtenidos a partir de los conceptos de la Ontología de la Medición del Software.

Las diferencias con relación al Metamodelo de la Medición del Software

propuesto por García en [8] (en adelante simplemente MMSGarcía) son las siguientes:

• Se elimina el constructor Instrumento de Medición;

• Se cambia la nomenclatura de los constructores Métrica y Medición para Medición y Resultado de la Medición, respectivamente.


47

Tales cambios fueron realizados para adaptar el metamodelo a la nueva estructura de la SMO. 5.2.2. Paquete Caracterización y Objetivos.

Este paquete incluye los constructores necesarios para la definición de una vista fundamental del proceso de medición, basada en establecer los objetivos y en identificar y caracterizar los elementos necesarios para cumplir con dichos objetivos.

Para ello se incluyen los constructores que permiten definir los objetivos o

“Necesidades de Información” que se pretenden, las “Categorías de Entidad” y “Atributos” de dichas categorías que es necesario medir para cumplir con los objetivos, las “Entidades” concretas sobre las que se aplica el proceso de medición y los “Conceptos Medibles” que se corresponden con las necesidades de información, junto con los “Modelos de Calidad” en los que se evalúan y que permiten encuadrar el proceso de medición en un contexto de mejora de la calidad. La Figura 8 muestra los elementos que componen este paquete:

Necesidad de Información(from Básico)

Concepto Medible(from Básico)

1

1..*

está relacionado con

0..*

incluye

0..*Modelo de Calidad

clase(from Básico) 1..*1..* evalúa

Entidad(from Básico)

0..*

compuesta de

Atributo(from Básico)

1..*

1..*

relaciona

Categoría de Entidad(from Básico)

0..*

incluye

0..*1

*

definido para

1..*

0..*

pertenece a

1..*1 tiene

Figura 8. Paquete Caracterización y Objetivos.

Como muestra la Figura 8, la estructura de este paquete coincide con las

estructuras de la sub-ontología “Caracterización y Objetivos” (véase apartado 4.1.1) y del “Paquete Caracterización y Objetivos” del MMSGarcía, por lo que se ha podido hacer una correspondencia directa.

Los elementos centrales de este paquete son “Entidad”, “Atributo” y

“Necesidad de Información”.


48

5.2.3. Paquete Acción de Medir.

Este paquete incluye los constructores necesarios que permiten representar la forma de llevar a cabo el proceso de medición. El constructor clave para definir la acción de medir es “Medición”, que representa la acción a partir de la que se obtiene un “Resultado de la Medición” (con su valor correspondiente perteneciente al nivel M0), como consecuencia de aplicar una “Forma de Medir”, para medir el “Atributo” de una “Entidad” sobre el que se han definido al menos una “Medida”, que es la que se utiliza en la acción de medir. En la Figura 9 se muestra la estructura de este paquete:

Forma de Medir(from Básico)

Resultado de la Medición(from Básico)


Entidad(from Básico)

Medida

Unidad(from Básico)

Medición(from Básico)

1 *

ejecuta

1

1

produce

1

*

se realiza sobre

1

*

se realiza sobre

1

*

usa

Los Atributos han de estar definidos para la Categoría de Entidad a la que pertenece la Entidad y la Forma de Medir usada en la Medición ha de estar definida para este Atributo

Figura 9. Paquete Acción de Medir.

Como se puede observar en la Figura 9, para definir la vista de la medición

representada en este paquete es fundamental definir las mediciones y resultados de medición obtenidos y las relaciones de estos constructores con las entidades y atributos, que han sido definidos usando los constructores del paquete “Caracterización y Objetivos” (véase apartado 5.2.2), la forma de medir definida en el paquete “Formas de Medir” (véase apartado 5.2.5) y la medida que se define usando los constructores del paquete “Medidas” (véase apartado 5.2.4).

Una restricción importante que se establece en el uso de los constructores de este

metamodelo es que el atributo sobre el que se realiza la medición debe estar definido como atributo de la categoría de entidad a la que pertenece la entidad objeto de la medición. Además, la forma de medir utilizada en la medición debe estar definida para el atributo objeto de la medición. Esta relación se representa de forma indirecta, es


49

decir, la forma de medir debe estar relacionada con la medida utilizada en la medición, y a su vez la medida debe estar relacionada con el atributo sobre el que se realiza dicha medición.

Este paquete se diferencia del “Paquete Acción de Medir” del MMSGarcía en la

nomenclatura de los constructores Métrica y Medida, que cambian a Medida y Resultado de la Medición, respectivamente, respectando la estructura de la SMO.. Se han realizado estos cambios con el fin de adaptar con SMO.

El elemento central de este paquete es Medición.

5.2.4. Paquete Medidas

El paquete “Medidas” incluye los constructores necesarios para definir las características generales de las medidas. Con los constructores de este paquete se definen las diferentes “Medidas” y las “Escalas” que se pueden utilizar en el modelo de medición. Para cada medida se debe especificar su unidad (si la tiene) y se debe indicar la escala a la que pertenece, la cual puede tener uno de los siguientes tipos: ordinal, nominal, intervalo, ratio y absoluta. Además, es fundamental identificar el atributo o atributos de la entidad sobre la que se define la medida. El constructor medida se puede especializar en los siguientes tipos. “Medida Base”, “Medida Derivada” o “Indicador”. La Figura 10 muestra la estructura de este paquete, cuyo elemento central es Medida:

Medida Derivada IndicadorMedida Base


Escala

Tipo(from Básico)

Medida


0..*

1..*

se define para

0..*

se transforma en

0..*

11..*

tiene

Unidad sólo aplicable a escalas de intervalo o ratio

Tipo: Nominal, Ordinal, Intervalo, Ratio, Absoluta

Figura 10. Paquete Medidas.

Una restricción a considerar en la definición de la unidad de una medida, es que

sólo se pueden definir unidades en medidas cuyo tipo de escala sea intervalo o ratio, por


50

lo que en caso contrario se debería asignar al atributo de medida “unidad” un valor etiquetado como “no aplicable”.

Este paquete corresponde al “Paquete Métricas” en el MMSGarcía y tienen las

siguientes diferencias de nomenclatura:

• Donde se lee “Métrica” en el MMSGarcía, aquí llamamos “Medida”;

• Los constructores “Métrica Directa” y “Métrica Indirecta” del MMSGarcía corresponden, respectivamente, a los constructores “Medida Base” y “Medida Derivada” de nuestro metamodelo.

Estos cambios se realizaron para garantizar la conformidad con la SMO.

5.2.5. Paquete Formas de Medir

Este paquete incluye los elementos de modelado necesarios para la representación de la formas de medir de los diferentes tipos de medidas. Para ello se deben definir los siguientes tipos de “Formas de Medir”: “Métodos de Medición”, para la medición de medidas base; “Funciones de Cálculo” para el cálculo de medidas derivadas a partir de medidas base y/o derivadas; y “Modelos de Análisis” para la definición de “Indicadores” mediante el uso de “Medidas” y “Criterios de Decisión”. Los indicadores constituyen el tipo de medida cuya información aportada permite satisfacer “Necesidades de Información”. Estos son los constructores y las relaciones que son necesarios definir para representar esta vista del modelo de medición. La Figura 11 muestra la estructura de este paquete:


51

Forma de Medir(from Básico)


Medida Derivada(from Medidas)

Medida Base(from Medidas)

1

1..*usa

Función de Cálculo1

1..*

calculada con

0..*

0..*

usa0..*

0..*usa

Necesidad de Información(from Básico)

Indicador(from Medidas)

0..*

1..*

satisface

Medida


Criterio de Decisión(from Básico)

Modelo de Análisis

1

1..*

calculado con

1..*

0..*

usa

1..*

1..*usa

Figura 11. Paquete Formas de Medir.

Como se puede observar en la Figura 11, la estructura de este paquete es una

correspondencia directa de la estructura de la sub-ontología de las formas de medir (véase apartado 4.1.3), al no incluirse en esta sub-ontología elementos de niveles M1 o M0. Respectando la estructura de la SMO, se realizaron los siguientes cambios con relación al “Paquete Formas de Medir” del MMSGarcía:

• Se ha eliminado el constructor Instrumentos de Medición;

• Se ha cambiado la nomenclatura de los constructores Métrica, Métrica Directa y Métrica Indirecta para Medida, Medida Base y Medida Derivada, respectivamente. Una restricción aplicable a este paquete es que toda función de cálculo debe al

menos usar una medida, sea base o derivada. Los elementos centrales son: Método de Medición, Función de Cálculo y Modelo de Análisis.


52

6. Conclusiones. La evolución de la estandarización internacional en la ingeniería del software es

la consecuencia del aumento continuo de la importancia de las Tecnologías de Información y Comunicación (ICT – Information and Communication Technologies) y de los servicios, productos y sistemas basados en ICT en la economía global, como también el incremento en la madurez de las disciplinas de ingeniería de software y de sistemas [35].

Sin embargo, la carencia de una terminología común y de inconsistencias entre

los diversos estándares puede comprometer seriamente la utilidad y los potenciales beneficios de estos esfuerzos de estandardización. Una terminología de medición del software consistente puede poner al alcance de las compañías un importante vehículo de comunicación que viabiliza la interoperabilidad con otros sectores.

En este trabajo hemos presentado la Ontología de la Medición del Software

propuesta en [7] que proporciona un vocabulario común para intentar resolver el problema de integridad e inconsistencia identificados en los diversos estándares internacionales y propuestas de investigación.

También hemos propuesto un Metamodelo para la Medición del Software que

servirá como base para la representación de modelos concreto de medición. Con esto esperamos contribuir para el desarrollo sistemático y efectivo de los

procesos de medición proporcionando el esquema adecuado para el almacenamiento de los datos y metadatos relacionados, facilitando la gestión adecuada de la medición del proceso, que es especialmente compleja ante la diversidad de entidades a considerar.

Los planes futuros incluyen el desarrollo de una notación gráfica basada en

UML que permita representar modelos de medición y, posteriormente, la implementación de una herramienta de definición de modelos de medición que dé soporte a dicha notación.


53

7. Referencias. 1. MacDonell, S., Sheppered, M., and Sallis, P., Metrics for Database Systems: An

Empirical Study, in Proceedings of the 4th International Symposium on Software Metrics, IEEE Computer Society: Albuquerque. May, 1997.

2. Briand, L.C., Morasca, S., and Basili, V.R., An Operational Process for Goal-Driven Definition of Measures. IEEE Trans. Softw. Eng., December, 2002. 28(12): p. 1106-1125.

3. Champeaux, D., Object-oriented Development Process and Metrics. Prentice- Hall. 1997.

4. Pfleeger, S.L., Guest Editor's Introduction: Assessing Measurement. IEEE Software, March/April, 1997. 14(2): p. 25-26.

5. ISO/IEC, Software and Systems Engineering - Guidelines for the application of ISO/IEC 9001:2000 to Computer Software. International Standards Organization, Genova, Switzerland, 2004.

6. ISO/IEC, VIM - International Vocabulary of Basic and General Terms in Metrology. International Standards Organization, Genova, Switzerland, 1993.

7. García, F., Bertoa, M.F., Calero, C., Vallecillo, A., Ruiz, F., Piatinni, M., and Genero, M., Towards a Consistent Terminology for Software Measurement, in Information and Software Technology. June, 27, 2005.

8. García, F., FMESP: Marco de Trabajo Integrado para el Modelado y la Medición de los Procesos Software. PhD thesis, Computer Science Department. University of Castilla-La Mancha,Ciudad Real, Spain. 2004.

9. Tautz, C. and Wangenheim, C.G., REFSENO: A Representation Formalism for Software Engineering Ontologies, in Technical IESE-Report 015.98/E, Fraunhofer Institute for Experimental Software Engineering: Kaiserslautern, Germany. October, 1998.

10. Fernández, M., Gómez-Pérez, A., and Juristo, N., METHONTOLOGY: From Ontological Art Towards Ontological Engineering. Working Notes of the AAAI Spring Symposium on Ontological Engineering, University of Stanford, CA (USA), March 24-25, 1997: p. 33-40.

11.IEEE, IEEE Standard for Developing Software Life Cycle Processes. STD 1074-1995, 1995.

12.Blazquez, M., Fernandez, M., Garca-Pinar, J.M., and Gomez-Perez, A. Building Ontologies at the Knowledge Level Using the Ontology Design Environment. in Proceedings of the 11th Knowledge Acquisition Workshop (KAW’98). Banff (Canadá). April, 1998.

13.Basili, V.R. and Rombach, H.D., Support for comprehensive reuse. Softw. Eng. J., 1991. 6(5): p. 303-316.


54

14.Wang, X. and Chan, C.W., Ontology Modeling Using UML. 7th International Conference on Object Oriented Information Systems Conference (OOIS’2001), Calgary (Canada), 2001: p. 59-68.

15.Guizzardi, G., Herre, H., and Wagner, G., On the General Ontological Foundations of Conceptual Modeling. 21st International Conference on Conceptual Modeling (ER’2002), Tampere (Finlandia), October, 2002.

16.Ruiz, F., MANTIS: Definición de un Entorno para la Gestión del Mantenimiento del Software. PhD thesis, Computer Science Department. University of Castilla-La Mancha,Ciudad Real, Spain. 2003.

17.Schleicher, A. and Westfechtel, B., Beyond Stereotyping: Metamodeling Approaches for the UML. 34th Hawaii International Conference on System Sciences (HICSS’2001), Maui, Hawaii (USA), January, 2001(IEEE Computer): p. 30-51.

18.IEEE, IEEE Standard 610.12-1992: Glossary of Software Engineering Terminology. IEEE Press, New York (USA), 1992.

19.IEEE, IEEE Standard 1061-1998: Standard for a Software Quality Metrics Methodology. 1998.

20.ISO/IEC, ISO/IEC 14598:2001: Software Engineering - Product Evaluation. International Standards Organization, Genova, Switzerland, 2001.

21.ISO/IEC, ISO/IEC 15939: Software engineering - Software measurement process. International Standards Organization, Genova, Switzerland, 2002.

22.Kitchenham, B.A., Hughes, R.T., and Linkman, S.G., Modeling Software Measurement Data. IEEE Trans. Softw. Eng., September, 2001. 27(9): p. 788-804.

23.Kim, H.M., Representing and Reasoning about Quality using Enterprise Models. PhD thesis, Dept. Mechanical and Industrial Engineering. University of Toronto,Canda. 1999.

24.Abran, A. and Sellami, A. Initial Modeling of the Measurement Concepts in the ISO Vocabulary of Terms in Metrology. in IWSM 2002. Magdeburg (Germany). October, 2002.

25.Azuma, M. SQuaRE: The Next Generation of the ISO/IEC 9126 and 14598 International Standards Series on Software Product Quality. in Proc. of European Software Control and Metrics - Escom 2001. London (England). April, 2001.

26.Basili, V. and Rombach, H., The tame project: Towards improvement oriented software environments. IEEE Transactions on Software Engineering, June, 1988. 14(6): p. 758-773.

27.Jones, C., Making measurement work. CROSSTALK, January, 2001. 16(1): p. 15-19.


55

28.McGarry, J., Card, D., Jones, C., Layman, B., Clark, E., Dean, J., and Hall, F. Practical Software Measurement. Objective Information for Decision Makers. Addison-Wesley. 2002.

29.Zuse, H. A Framework of Software Measurement. Walter de Gruyter: Berlin, New York. 1998.

30.Gomez-Perez, A., Knowledge Sharing and Reuse. CRC Press, 1998.

31.Staab, S., Studer, R., Schnurr, H.-P., and Sure, Y., Knowledge Processes and Ontologies. IEEE Intelligent Systems, 2001. 16(1): p. 26-34.

32.Uschold, M. and Gruninger, M., Ontologies: Principles, Methods, and Applications. The Knowledge Engineering Review, 1996. 11(2): p. 93-196.

33.Althoff, K.D., Birk, A., Hartkopf, S., and Mller, W., Managing Software Engineering Experience for Comprehensive Reuse. Proc. 11th International Conference on Software Engineering and Knowledge Engineering, Kaiserslautern, Germany, 1999: p. 10-19.

34.García, F., Ruiz, F., Bertoa, M.F., Calero, C., Genero, M., Olsina, L., Martín, M., Quer, C., Condori, N., Abrahao, S., Vallecillo, A., and Piatinni, M., Una Ontología de la Medición del Software. Technical Report UCLM DIAB-04-02-2, Computer Science Department, University of Castilla-La Mancha, Spain, 2004.

35.Coallier, F., International standardization in software and systems engineering. CROSSTALK, February, 2003. 18: p. 15-18.

36.Gruber, T.R., A Translation Approach to Portable Ontology Specification.

Knowledge Adquisition, 1993. 5(2) pp. 199-220. 37.Hikita, T., Matsumoto, M.J., Business Process Modelling Based on the Ontology and

First-Order Logic. Proceedings Third International Conference on Enterprise Information Systems (ICEIS' 2001), 2001. 7-10 July pp. 717-723.


56

AA.. AAppéénnddiiccee II:: LLiissttaa ddee TTéérrmmiinnooss..

57

A. Apéndice I: Lista de Términos La siguiente tabla presenta una lista de sinónimos y equivalencias al inglés de

los conceptos de la Ontología de la Medición del Software. Se estructura de la siguiente manera: las columnas 1 y 2 muestran, respectivamente, la sub-ontología a que pertenece el término y el nombre del término (concepto) en español; la columna 3 muestra el sinónimo (o sinónimos) para el término en cuestión seguido de la fuente documental que lo utiliza entre paréntesis (de acuerdo con la Tabla 3) y finalmente, la columna 4 presenta su equivalente en inglés:


58

Sub-Ontología Concepto Sinónimo (Fuente) Equivalente en Inglés


Objetivo Corporativo (FD9), Requisito de Calidad (FD7) Information Need

Concepto Medible - Measurable Concept

Entidad Ocurrencia de Objeto de Proyecto (FD8) Entity

Categoría de Entidad Tipo de Elemento del Modelo de Desarrollo (FD8) Entity Class

Atributo Cantidad Mensurable (FD5),

Atributo Genérico (FD8), Atributo Medido (FD7)

Attribute

Caracterización y Objetivos de la Medición

Software

Modelo de Calidad

Modelo de Desarrollo (FD8), Modelo de Calidad de la Empresa (FD7), Marco de Trabajo de las

Métricas (FD3)

Quality Model

Medida Métrica (FD2, FD3, FD4), Tipo de elemento de Medición del Modelo

de Desarrollo (FD8) Measure

Escala Escala de valor-referencia (FD5), Rango de Escala Genérico (FD8) Scale

Tipo de Escala - Type of Scale

Unidad de Medición Unidad (FD4), Unidad Genérica (FD8) Unit of Measurement

Medida Base Cantidad Base (FD5), Medida Directa (FD3, FD4) Base Measure

Medida Derivada Cantidad Derivada (FD5), Medida Indirecta (FD4) Derived Measure

Medidas Software

Indicador - Indicator

Método de Medición - Measurement Method

Función de Cálculo - Measurement Function

Modelo de Análisis - Analysis Model

Formas de Medir

Criterio de Decisión Nivel de Valoración (FD4) Decision Criteria

Forma de Medir - Measurement Approach

Medición - Measurement Acción de Medir


Medida (FD4, FD6), Valor Grabado (FD8), Punto de

Medición (FD7), Valor de la Métrica (FD3)

Measurement Result

Tabla 19. Ontología de la Medición Software: Lista de Términos.

Departamento de Tecnologías y Sistemas de Información Medición del Software Ontología y...

Documents

Transcript of Departamento de Tecnologías y Sistemas de Información Medición del Software Ontología y...