Un Marco Conceptual para la Definición y Explotación de Métricas de Calidad L. A. Olsina1 , M. F. Bertoa2, G. J. Lafuente1 , M. A. Martín1 , M. Katrib3 , A. Vallecillo 2 . 1

Universidad Nac. de La Pampa. Argentina. {olsinal, lafuente, martinma}@ing.unlpam.edu.ar Universidad de Málaga. España. {bertoa, av}@lcc.uma.es 3 Universidad de la Habana. Cuba. [email protected] 2

Resumen. Aunque actualmente existen numerosas propuestas de modelos de calidad para distintos dominios de aplicación, hemos observado que no existe un consenso general sobre cómo han de documentarse o explotarse de forma efectiva las métricas de calidad que cada una de estas propuestas define. El presente trabajo propone un marco general (framework) para permitir la definición, documentación y explotación de métricas de calidad desde una perspectiva común. El objetivo de tal framework es el de proporcionar una infraestructura genérica que facilite la especificación y uso de tales métricas, y que permita el desarrollo de herramientas industriales para tratar de automatizar los procesos de especificación, consulta y análisis de métricas basado en estándares de amplia aceptación como pueden ser UML, XML, RDF y tecnologías de Web Semántica. Esto favorecerá procesos de catalogación, consulta, análisis de información, evaluación y selección para distintos dominios de software.

1 Introducción En los últimos años han surgido diversas propuestas de modelos de calidad para ciertos dominios de aplicación, como por ejemplo para modelar y evaluar requisitos no funcionales de sitios y aplicaciones Web [10], o para el desarrollo de Software Basado en Componentes (CSBD) [2]. Dichas propuestas (entre otras [1], [5]), definen conjuntos de métricas de calidad y/o metodologías de evaluación y selección para los productos software propios de cada uno de estos dominios. Incluso en algunos casos se proponen repositorios de tales métricas, así como herramientas que hacen uso de ellas para tratar de automatizar dentro de lo posible dichos procesos [11]. Es decir, asistimos a la aparición de propuestas de calidad que tratan de acercar el desarrollo y aseguramiento de calidad de software hacia una verdadera ingeniería. A pesar del valor in cuestionable de dichas propuestas, el hecho de haber sido desarrolladas de una forma independiente y para dominios muy específicos hace que, al contemplarlas desde una perspectiva más general, presenten ciertas limitaciones a la hora de poder ser utilizadas de forma genérica. En particular, hemos observado que: (a) la mayoría de las propuestas existentes en la literatura no están estructuradas de una forma común y consistentes entre sí, (b) la terminología que utilizan, tanto del punto de vista sintáctico como semántico, no suele estar

unificada (a pesar de basarse en estándares internacionales); (c) la documentación asociada a cada métrica no es uniforme, lo que impide su posible reutilización en otros ámbitos y la construcción de herramientas que hagan uso de ellas por terceros; y (d) los trabajos sobre métricas suelen estar completamente disociadas a las propuestas y métodos de selección y evaluación de la calidad, como QESTA [5], COCOTS [1], entre otras. En resumen, vemos como por un lado se realizan esfuerzos repetidos a la hora de definir modelos y herramientas, mientras que por otro lado aparecen lagunas en algunas de las propuestas al no hacer uso de los beneficios y avances que proporcionan otras. En este sentido, disponer de un marco conceptual capaz de proporcionar un vocabulario, modelo e infraestructura común (en adelante, framework), permitiría solucionar muchos de los inconvenientes mencionados anteriormente. El presente artículo presenta las bases para tal framework, analiza los requisitos generales que debería cumplir, y propone una arquitectura concreta para su implementación. En particular, se proponen una serie de tecnologías (por ejemplo, esquemas XML) para documentar métricas basadas en las plantillas de Olsina [11], la estructura de un repositorio general de métricas (basado en un modelo conceptual de métricas), así como la definición de un conjunto de servicios que permitan la explotación de dicho repositorio, tanto por parte de potenciales usuarios del mismo como por parte de herramientas. Asimismo, hemos querido contemplar la explotación del repositorio desde distintas perspectivas, aunque haciendo especial hincapié en el acceso a sus servicios a través de Internet, mediante la definición e implementación de una serie de Servicios Web (WebServices). Es importante señalar que el modelo de métricas se ha definido de forma genérica, con independencia de dominios de software específicos. Cabe destacar los esfuerzos recientes realizados por Kitchenham et. al. [3] en la definición de un modelo conceptual y una infraestructura (basados en el modelo Entidad-Relación) para especificar entes, atributos y relaciones en medición de proyectos de software, e instanciar proyectos, con el fin de analizar métricas y conjuntos de datos de un modo consistente. Este modelo sirve de punto de partida a nuestra propuesta, el cual intentamos robustecer tanto desde el punto de vista del modelado conceptual y navegacional (utilizando enfoques Orientados a Objetos –similares, por ejemplo, al enfoque OOWS [12]), como de las tecnologías para catalogación, consulta y servicios. Hasta el presente, los servicios de catalogación de métricas han sido procesos muy poco tenidos en cuenta en la comunidad de software [11]. La estructura de este artículo es la siguiente. Tras esta introducción, la sección 2 describe los conceptos principales sobre los que se apoya este artículo, incluyendo las nociones de modelo de calidad, atributos y sus métricas asociadas, y analiza brevemente los requisitos que debería tener un framework como el que proponemos para combinar adecuadamente los conceptos descritos y permitir su explotación. Seguidamente, la sección 3 recoge la principal contribución de este artículo, especificando un modelo para el dominio de métricas y describiendo una propuesta concreta de implementación del mismo. Finalmente, la sección 4 extrae las conclusiones de nuestro trabajo y discute algunas líneas de trabajo futuro.

2 De los Modelos de Calidad, las Métricas y los Requisitos del Framework Varios de los enfoques sobre métodos de evaluación y selección de productos software proponen una fase de evaluación donde se deben caracterizar los posibles atributos candidatos bajo un conjunto de propiedades o características y de otros componentes como sub características (que en definitiva representa el modelo de calidad). Con la intención de utilizar estas propiedades de un modo uniforme y consistente, hemos empleado estándares internacionales [6], [8] que nos indican (prescriben o informan) el conjunto de características y sub-características que intervendrían para nuestro objetivo de evaluación. Sin embargo, nos surgieron problemas cuando intentamos aplicar estos estándares generalistas a un dominio específico de aplicaciones, por ejemplo a los componentes COTS o a los sitios y aplicaciones Web. Estos estándares no definen atributos y métricas para diferentes dominios y metas de evaluación, ni establecen por lo tanto cómo ciertos atributos se factorizarían en sub características y características. El estándar ISO/IEC 9126 [8] presenta un modelo de calidad para productos software, heredero de los factores de calidad de McCall [9]. Aunque en permanente estado de revisión, hemos utilizado su terminología y su modelo de calidad como base de nuestro trabajo. Dicho estándar define un modelo de calidad, formado por características, sub-características y atributos. Debido a que las características y sub-características están definidas a un alto nivel de abstracción, es preciso calcular sus valores por medio de propiedades de un nivel de abstracción más bajo, como son los atributos. Un atributo puede ser directa o indirectamente cuantificable y representa una propiedad tangible o intangible de un ente (proceso, proyecto, producto, etc.). Una vez seleccionado el modelo de calidad para un producto software (por ejemplo el modelo ISO 9126) es necesario personalizarlo para dominios específicos como pueden ser el de los sitios y aplicaciones Web [10], los componentes COTS [2], u otros. Sin embargo, nos hemos encontrado con serios inconvenientes a la hora de realizar esta especialización. En primer lugar, el estándar citado no define atributos y métricas para diferentes dominios y metas de evaluación (ni ningún otro de los actualmente existente relativos a la calidad). Tampoco se ha contado con catálogos de atributos, métricas y criterios de medición documentados. Particularmente, la falta de información consistente sobre los atributos y métricas (como definición, alias, utilidad, reglas de conteo, unidades de medición, tipos de escala, etc.) la consideramos un obstáculo importante al momento de realizar un proceso de evaluación, comparación y/o selección. Por tanto, nuestra motivación principal es la de definir un modelo conceptual que permita dar solución a muchos de estos problemas. Este modelo y, principalmente su infraestructura subyacente, deberá soportar no sólo un mecanismo de trabajo colaborativo para incorporar al repositorio la información de atributos y métricas de un modo consensuado, sino también brindar servicios de consulta y reutilización tanto para usuarios como para herramientas. Consideramos entre algunos objetivos (requisitos de alto nivel) de este framework, los siguientes: ?? Interoperabilidad: que facilite el intercambio de información entre distintas aplicaciones de usuario o herramientas, aun cuando estén implementadas en plataformas distintas. Para garantizar la interoperabilidad en nuestra arquitectura, se propone la implementación bajo

estándares de marcado (XML, SXML), estándares de Web semántica (como RDF, RDFS, DAML+OIL) y de arquitecturas de ambientes distribuidos de amplia difusión. ?? Generalidad: que proporcione un marco común de trabajo en la documentación de atributos y métricas que pueda ser aprovechado en distintos ámbitos y desde distintas perspectivas. Para este fin, proponemos un modelo que no está comprometido con un dominio de software específico. ?? Simplicidad: que el uso del repositorio, ya sea por parte de los administradores, usuarios o herramientas finales deba hacerse a través de interfaces y operaciones estándares simples, como por ejemplo: Registro, Búsqueda, Exploración, etc. con el fin de proveer un entorno fácil de usar, aprender y operar. ?? Seguridad: que el acceso a los servicios, datos y meta-datos del repositorio provean distintos niveles de seguridad conforme a distintos roles bien definidos. ?? Autoritativo: que responda a normas establecidas en la manera de discutir y acordar atributos y métricas candidatas, así como en los procedimientos para registrar, actualizar y publicar la información.

3 Propuesta de un Marco Conceptual para la Definición y Explotación de Métricas

3.1 El Modelo Conceptual de Métricas A continuación describimos el modelo conceptual, de utilidad para diseñar e implementar repositorios de métricas, en el cual representamos todos los elementos y relaciones necesarias para definir y explotar información de distintas métricas de atributos para diferentes dominios software. En el presente modelo conceptual no se ha previsto guardar instancias de métricas con sus valores respectivos para los diferentes atributos intervinientes para cada ente en distintos proyectos de software específicos. Esta ampliación del modelo será motivo de un avance futuro. En la Figura 1 representamos (mediante un diagrama de clases y relaciones especificado en UML) los principales elementos del modelo conceptual [11], y que parcialmente analizamos (por razones de espacio) a seguir: Las Clases Entidad y Atributo. Una entidad (o ente) representa un objeto, tangible o intangible, que exhibe un comportamiento observable en el mundo real (o dominio empírico). Desde el punto de vista del dominio del software, entes de interés a un alto nivel de abstracción son: Proyecto, Proceso, Recurso, Producto y Producto en Uso. A su vez, los entes se pueden subdividir en sub-entes de diferentes tipos. Los entes no se pueden medir directamente, sino a través de las propiedades atribuidas. Por lo tanto, los atributos representan las propiedades de los entes que son de interés para fines de medición. La Figura 1 muestra la relación entre la clase Ente y Atributo, así como su cardinalidad.

Como hemos indicado anteriormente, las entidades se componen de sub-entes. Por ejemplo, un sitio web (producto) contiene páginas web, las páginas pueden contener aplicaciones (funcionalidad de programas), imágenes y enlaces, entre otros. Las aplicaciones también se pueden descomponer en sub-entes como scripts y applets, formando de esta manera una jerarquía de entidades en donde la entidad de más alto nivel podría ser el proyecto con sus distintos componentes (recursos, productos y procesos). Desde el punto de vista de la medición, a todas las entidades (independientemente del nivel de la jerarquía en que estén) se les puede asociar atributos. Así podemos decir, por ejemplo, que Cantidad de Paginas (estáticas ) es un atributo de la entidad Sitio Web mientras que Tamaño de la Página es un atributo de la entidad Página Web. De esta manera, el modelo representa tanto a los atributos relacionados con las entidades, como a la relación jerárquica de los entes entre sí, que desde la perspectiva del repositorio nos podrá permitir una navegación que facilite la exploración de atributos (y métricas) por jerarquías. Por ejemplo, una consulta puede ser “obtener información de todas los atributos relacionados a un proyecto, producto, recurso, proceso o producto en uso”. Por otra parte, en la Figura 1 se observan las clases Atributo Directo e Indirecto. Los atributos directos son atómicos, no se descomponen en nuevos atributos, en tanto que un atributo indirecto se puede representar por una relación de atributos. Por ejemplo, la Cantidad de Interfaces Especificadas de un componente COTS, es un atributo directo, mientras que el Grado de Cobertura de Implementación de Interfaces es la relación inversa entre la Cantidad de Interfaces Implementadas y las Especificadas. Por último, dentro de la clase Atributo especificamos campos1 como nombre, palabras clave, definición, objetivo/motivación para utilizar el atributo, entre otros. La Clase Métrica y Clases Relacionadas. Antes de comentar las clases se observa que un atributo puede ser cuantificado por una o varias métricas. Por ejemplo, el atributo Tamaño del Texto Visible de una Página puede ser medido por una métrica m1 que cuantifique el tamaño por la cantidad de palabras, o por una métrica m2 que la cuantifique en bytes. La idea de métrica no es un concepto simple de desarrollar, si no se comprenden y analizan sus componentes y relaciones. Se la debe comprender en consideración de los atributos a los que cuantifica y a los entes a los que se asocia. Asimismo, es preciso identificar el tipo de valor que se obtiene, la unidad en la que se expresa, y el tipo de escala que se usa, con el fin de poder realizar una apropiada interpretación y un análisis matemático y/o estadístico. Además, un aspecto fundamental para garantizar la repetitividad y replicabilidad del proceso de medición [7], es conocer las reglas de conteo y procedimientos (que denominaremos en este ámbito como “protocolo”), y determinar si el proceso de recolección de datos y cálculo se puede automatizar mediante un instrumento de medición. Como se observa en la Figura 1, las clases Métrica Directa e Indirecta son un tipo de Métrica. El concepto de métrica directa e indirecta (en el dominio formal) está estrechamente relacionado a la cuantificación de atributos directos e indirectos respectivamente (en el dominio empírico). 1

Utilizamos la palabra campo, en reemplazo de atributo de una clase, para no sobrecargar el concepto de Atributo utilizado en el ámbito de las métricas.

subEntidad

?

Proyecto es el nivel más alto en una jerarquía de Entidad - SubEntidad y puede estar compuesto por entidades como Procesos Productos, Recursos y Productos en Uso.

valor={Simbolo, Entero, Real}

0..* Entidad 1

?

1

nombre descripción

Protocolo aplica_a

Medida

especificación comentario

valor

1..*

1..*

1 ? MétricaRelacionada

1..*

1..*

Métrica

Atributo 1..* 1..*

0..*

nombre palabrasClave definición objetivo/motivacion nivelIndependencia tipo

? cuantifica

1

1..*

2..* 1..*

rangoAceptabilidad valorMinimo valorMáximo interpretaciónValor tipoRecolecciónDatos referencias exactitud

HerramientaMedición

? descripción 1..* automatizada_por 0..* versión proveedor comentario

2..*

Ecuación AtributoDirecto

MétricaDirecta

AtributoIndirecto

MétricaIndirecta 1

especificación pertenece_a

?

1 ModeloCalidad nombreModelo

1..*

1

?

1

Característica nombre descripción

expresada_en

especificación comentario

1..* tipo

Unidad nombre descripción

comentario

usa ? 1..* 2..*

TipoEscala

1

nombre

1 0..*

1..* Subcaracterística

0..*

UnidadSimple

UnidadCompuesta

nombre descripción

tipo={Fijo, Define su propio modelo, Mixto}

Rango descripción númeroOrden

nombre={Nominal, Ordinal restringida, Ordinal no restringida, Intervalo, Proporción, Absoluta}

Fig. 1. Modelo Conceptual para el dominio de métricas. En el caso de una métrica indirecta, es necesario saber cual es la Ecuación que formaliza y especifica al atributo indirecto. Para el ejemplo de atributo indirecto: Grado (o Porcentaje) de Cobertura de Implementación de Interfaces la ecuación matemática que formaliza la relación empírica “X es inversamente proporcional a Y” queda forma lizada como: ? # Interfaces_Implementadas ? Porcentaje_de_Cobertura_de_Implementación_de_Interfaces ? 100* ?? ?? ? # Interfaces_Especificadas ?

Una medida (cuyo valor puede ser de distintos tipos como Símbolo -cadena de caracteres, entero o real), es parte de una métrica. La métrica no puede ser interpretada sin una unidad de medida y un tipo de escala, como se ilustró anteriormente con el atributo Tamaño del Texto Visible de una Página , que podía ser medido por dos métricas distintas dependiendo si la unidad de medida era cantidad de palabras, o número de bytes. A su vez, podemos modelizar unidades simples y compuestas como se observa en la Figura 1. Por otra parte, es importante remarcar que una métrica puede tener uno o más protocolos de medición. La clase Protocolo especifica los mecanismos y procedimientos a ser tenidos en cuenta al momento de recolectar los datos con el fin de obtener el valor de una métrica. Así, las reglas de conteo para las dos métricas del ejemplo anterior varían según el caso. Además, si la métrica es automatizable (o semi-automatizable) desde el punto de vista de la recolección de datos, se puede indicar en el campo “especificación” el algoritmo correspondiente (por ejemplo, en pseudocódigo u otro formalismo) para que sirva como guía en el proceso con el fin de garantizar repetitividad y replicabilidad. Además, para este tipo de métricas se puede usar herramientas de medición tal como se ilustra en el modelo. Por último, desde el punto de vista de consulta al repositorio de métricas catalogadas, puede ser útil navegar por métricas relacionadas como se aprecia en la Figura 1.

3.2 Documentación de Métricas con Esquemas XML Una vez descrito el modelo de métricas de utilidad para el repositorio, en esta sección discutiremos sobre algunos detalles de su implementación. En concreto, nos centraremos en la documentación de los atributos de calidad y las métricas que permiten evaluarlos, de forma que nos permita construir, de forma modular y progresiva, el framework descrito en la sección 2, manteniendo los objetivos expuestos anteriormente. Para documentar y manejar los atributos de calidad y las métricas utilizaremos XML. Esto va a favorecer la independencia de tecnologías de la implementación final, a la vez que permitirá construir fácilmente herramientas que manejen esta información [4]. Siguiendo el modelo propuesto en el punto anterior, hemos definido dos esquemas XML, uno para describir atributos y otro para métricas. Para ilustrarlos haremos uso de un ejemplo, el atributo que mide las páginas huérfanas (Orphan Pages) de una aplicación web: Orphan Pages Dead-end Page Web Metric

An orphan page has no internal link to the site where is included in (or it has all internal links broken). Counts the number of pages that have no internal links to the Web site where they are included in. Totally Independent external Orphan Page Count 0 10 x>=0, the closer to 0 the better To be determined from a site sample J.Nielsen, www.useit.com/alertbox79605.htm

Como se puede observar, el esquema sigue el modelo conceptual discutido anteriormente para describir los elementos que componen un atributo y los valores que éstos toman (dentro del tag “ ”). Las métricas que pueden utilizarse para medir este atributo se expresan como una secuencia de tags “” (una sola en este ejemplo). Una métrica puede indicar el repositorio en donde está definida (nombre, unidad, escala, etc.). En la plantilla del atributo sólo es preciso particularizar los valores concretos de la métrica para el atributo “Orphan Pages”. Obsérvese que los tipos de los valores que definen las métricas se han definido en un esquema XML separado ( xmlns:qlMetrics="http://www.cotsmetric.com/Metrics.xsd"). Es importante señalar la potencia que ofrece XML para describir las métricas y sus elementos asociados, que nos permite hasta expresar en este ejemplo la invocación remota de un protocolo para realizar automáticamente la medida.

3.3 Arquitectura y Servicios de Acceso al Repositorio La Figura 2 muestra el esquema de lo que constituye la arquitectura genérica del framework. En la parte superior se muestran los distintos tipos (roles) de usuarios, que serán descritos en la siguiente sección. Los servicios del framework se ofrecen fundamentalmente a través de WebServices, siendo XML la lingua-franca en la que se expresa toda la información. Esto, añadido a la capas semánticas, va a permitir satisfacer los requisitos de interoperabilidad y generalidad que imponíamos al framework en la sección 2.

Fig. 2. Arquitectura general del framework. La definición de la arquitectura se ha realizado de forma ambiciosa, incluyendo un camino de crecimiento hacia los aspectos semánticos de las búsquedas y el tratamiento de información mediante capas semánticas (RDF/S y DAML+OIL). Sin embargo, un primer paso consiste en la implementación de los niveles más bajos del esquema, en donde se accede a través de Servicios Web a la base (o bases) de datos de las métricas. Los servicios que se ofrecen a este nivel a las aplicaciones que hacen uso del repositorio son inicialmente los propios de un repositorio, es decir, la consulta y actualización de los datos. Las posibilidades y herramientas que ofrece actualmente la tecnología .NET para el desarrollo de este tipo de aplicaciones son más que suficientes para nuestras necesidades. Aun más, el uso de XM L facilita en parte las cosas pues la mayoría de los fabricantes de bases de datos ofrecen mecanismos para acceder a ellas a través de este lenguaje, y devolver las respuestas de preguntas SQL en páginas XML construidas dinámicamente. Otra de las ventajas del uso de la tecnología que ofrecen los servicios Web es la fácil integración con aplicaciones construidas en las principales plataformas de desarrollo, como pueden ser CORBA, DCOM, o J2EE. Ahora mismo todas ofrecen herramientas para la invocación de este tipo de servicios.

Actualmente estamos diseñando y construyendo una herramienta de catalogación para el repositorio de métricas que proporciona estos servicios básicos. Por encima de ella, nuestro siguiente paso es la provisión de mecanismos de discusión y trabajo colaborativo basado en la Web para la aceptación y agregado de métricas al repositorio, y por otro lado un robusto sistema de consulta y reuso. La descripción general de estos servicios se muestra en la siguiente sección, en donde se describen los aspectos de uso y administración del repositorio sobre la base de los distintos roles de usuario que ha de soportar.

3.4 Funcionalidad del Repositorio y Roles de sus Usuarios Desde el punto de vista del diseño de los usuarios para el entorno de catalogación, hemos identificado cuatro tipos de roles con responsabilidades y permisos de acceso diferentes. Estos roles son: Administrador, Moderador, Revisor y Usuario Final (como se observa en la parte superior de la Figura 2). Para cada uno de ellos describimos sus responsabilidades, así como la funcionalidad que debe ofrecerles el framework para el desempeño de sus tareas. El (rol de) Administrador es el responsable final que tiene acceso total al repositorio de métricas. El administrador es el único con capacidad de agregar métricas que han sido aprobadas o, si fuera necesario, eliminar instancias de éstas. Por otro lado, tiene a su cargo la gestión y coordinación de los moderadores (los cuales son responsables para los foros de discusión de métricas candidatas). El administrador ha de actualizar el repositorio con las métricas aprobadas entre los revisores y moderadores, o bien vetarlas y proponerlas de nuevo a consideración. El Moderador es el responsable de la selección y coordinación del grupo de revisores, de la puesta en discusión de las métricas candidatas, y del establecimiento de un calendario de trabajo. Tanto el moderador como los revisores deberán trabajar en un área compartida privada (temporal) que no es el repositorio en sí, ambos con su respectiva visibilidad y permisos de acceso. Para estas actividades se usarán mecanismos colaborativos sincrónicos y asincrónicos basados en la Web. El Revisor es el responsable de discutir y contribuir en la definición de la métrica en los diferentes elementos (meta-datos) definidos en el marco conceptual y esquemas. Cada revisor deberá tener acceso de sólo lectura al área de discusión de otros revisores pues, en definitiva, será el moderador el responsable de aprobar las métricas acordadas, notificando a su vez al administrador de este evento. El usuario final puede ser una persona o una aplicación de software que usa los servicios del repositorio. Los usuarios deberán ser capaces de acceder a las métricas del catálogo por medio de funcionalidades de búsqueda y navegación con permisos de accesos de sólo lectura, utilizando los servicios descritos anteriormente.

4 Conclusiones y trabajos futuros Una de las principales carencias en aspectos del aseguramiento de la calidad es la falta de estrategias y herramientas que soporten el desarrollo, la explotación y la administración de las

métricas de cada dominio. El trabajo aquí presentado nace de la experiencia de los autores del mismo, al detectar las similitudes que presentaban los modelos de calidad que habían definido para distintos dominios de aplicación, así como la carencia de herramientas y repositorios (es decir, un framework) para la definición y explotación de métricas de calidad. El modelo conceptual presentado aquí describe los fundamentos para construir tal framework, y va a permitir sentar las bases para un trabajo de colaboración entre los grupos de investigación implicados en el mismo. En este artículo hemos definido el modelo conceptual como pieza clave para diseñar e implementar el repositorio, así como la arquitectura general y funcionalidad esperada del framework. Asimismo, se han analizado las ventajas del uso de XML como notación para la documentación y especificación de atributos de calidad y sus métricas asociadas. Tras estos primeros pasos, pretendemos abordar los aspectos semánticos mediante el uso de las tecnologías emergentes en el área. Aunque se trata de una tarea ambiciosa, pensamos que son temas críticos a la hora de disponer de catálogos para la definición y explotación de las métricas de calidad. Hasta hace poco era una utopía disponer de tales catálogos, pero pensamos que es algo con lo que los ingenieros del software deberían poder contar si realmente se desea hablar de una “ingeniería” del software. Reconocimientos . Este trabajo es tá soportados por el proyecto UNLPam-09/F022, y el proyecto VII.18. WEST http://www.dsic.upv.es/~west/, CYTED http://www.cyted.org/Nueva.asp.

Referencias 1. Chris Abts, Barry W. Boehm, and Elizaberth Bailey Clark. “Cocots: A cots software integration lifecycle cost model - model overview and preliminary data collection findings”, 2000. Disponible en http://sunset.usc.edu/publications/TECHRPTS/2000/usccse2000-501/usccse2000-501.pdf 2. M. F. Bertoa and A. Vallecillo. “Quality Attributes for COTS Components”. In Proc. of the Sixth ECOOP International Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2002), pages 54-66. Málaga, Spain, June 2002. 3. B.A. Kitchenham, R.T. Hughes and S.G. Linkman. “Modeling Software Measurement Data”. IEEE Transactions on Software Engineering, 27(9), September 2001, pp. 788-804. 4. L. Iribarne, A. Vallecillo, C. Alves and J. Castro. “A non-functional approach for COTS-components trading”. In Proc. of WER 2001, pages 124-138. Buenos Aires, Argentina, November 2001. 5. W. Hansen. “A Generic Process and Terminology for Evaluating COTS Software”. Disponible en http://www.sei.cmu.edu/staff/wjh/Qesta.html 6. IEEE Std 1061-1992, “IEEE Standard for a Software Quality Metrics Methodology”, IEEE Press. 7. ISO/IEC-14598-5:1998. “Information Technology – Software Product Evaluation – Part”. July 1998. 8. ISO/IEC 9126-1:2001 “Software engineering -- Product quality -- Part 1: Quality model”. June, 2001. 9. J.A. McCall, P.K. Richards y G.F. Walters. “Factors in software quality”. Informe técnico RADC-TR77-369, vol. III, Hanscom AFB, MA 01731, 1977. 10. L. Olsina y G. Rossi, “Measuring Web Application Quality with WebQEM”, IEEE Multimedia, Vol. 9, Nº 4, 2002. 11. L. Olsina, G.J. Lafuente y O. Pastor. “Designing a Catalogue for Metrics”, In 2nd Ibero American Conference on Web Engineering (ICWE´02), Sta Fe, Argentinapp. 108-122, ISSN 1666-6526, 2002. 12. Pastor, O.; Abrahão, S. M.; Fons, J. J. “Object-Oriented Approach to Automate Web Applications Development”, 2nd Int. Conference on Electronic Commerce and Web Technologies (EC-Web'01), Munich, Germany, Springer Verlag, 2001, 16-28.