Atributos de Calidad para Componentes COTS

Manuel F. Bertoa y Antonio Vallecillo

Departamento de Lenguajes y Ciencias de la Computacin o Universidad de Mlaga. 29071 Mlaga, Espaa a a n {bertoa,av}@lcc.uma.es

Resumen
Conforme cobra auge el desarrollo de aplicaciones basadas en componentes COTS, y empiezan a aparecen las primeras casas comerciales que venden componentes COTS con xito, aumenta la necesidad de e disponer de parmetros de calidad que permitan evala uarlos y seleccionarlos de acuerdo a los requisitos de calidad de los usuarios. Partiendo de las distintas propuestas existentes sobre caracter sticas de calidad para los productos genricos software (especialmente e las recogidas por ISO e IEEE), este trabajo ofrece una lista de atributos y de sus posibles mtricas que son e aplicables espec camente a los componentes COTS, y que permiten describir (y medir) no slo su funo cionalidad, sino tambin muchas de sus propiedades e extra-funcionales. El modelo de calidad propuesto se contrasta tambin con los ya existentes, cuyo carcter e a demasiado generalista diculta su implantacin y utio lizacin efectiva para el caso concreto de los compoo nentes COTS.

1.

Introduccin o

Actualmente asistimos a grandes cambios en la forma en la que se desarrollan las aplicaciones software. La creciente necesidad de realizar sistemas complejos en cortos periodos de tiempo, a la vez que con menores esfuerzos tanto humanos como econmicos, o est favoreciendo el desarrollo de lo que se conoce coa mo Ingenier del Software Basada en Componentes a (ISBC). Esta nueva disciplina se apoya en componentes software ya desarrollados y de ndole comercial, que se conocen como componentes COTS (commercial o-the-shelf ). Construir una aplicacin se convierte por tanto en o la bsqueda y emsamblaje de piezas prefabricadas, u desarrolladas en su mayor por terceras casas, y a cuyo cdigo no puede modicarse. Bajo este nuevo o planteamiento, cobran especial inters los procesos e de bsqueda y seleccin de los componentes COTS u o apropiados para construir las aplicaciones. Los principales esfuerzos de la comunidad de software en estos temas se han basado hasta ahora en los aspectos funcionales de los componentes, es decir, en 1

la funcionalidad que ofrecen. Sin embargo, por lo general se han venido obviando muchos de los aspectos de calidad que intervienen a la hora de seleccionar componentes y ensamblarlos para construir aplicaciones que satisfagan los requisitos del cliente. Este tipo de aspectos, que llamaremos extra-funcionales cada vez acaparan ms la atencin de los arquiteca o tos e ingenieros del software. Por un lado, los requisitos extra-funcionales por su naturaleza global pueden afectar a varias partes del sistema, y por ello tendrn prioridad si entran en conicto con los a requisitos funcionales. Adems, el cuidadoso anlisis a a de los atributos de calidad puede mejorar el proceso de discriminacin de los productos COTS candidatos o que cumplan el ncleo de requisitos funcionales. Por u ejemplo, si dos componentes implementan misma funcionalidad, sus atributos extra-funcionales pueden ser el criterio decisivo en el proceso de seleccin. o Podemos considerar varias causas para esta omisin de la valoracin en los requisitos extrao o funcionales. La primera es que no existe una denicin consensuada de las caracter o sticas o atributos de calidad que hay que medir. As podemos encon, trar diversas clasicaciones en la literatura: desde los factores de calidad propuestos en 1.977 por McCall [12], el modelo de calidad de Boehm de 1.976 [3], los estndares internacionales ISO 9126 [11] e ISO 14598 a [10], la lista de atributos para la valoracin citada o para el modelo COCOTS en [1] basada en estndares a de IEEE [6], y otras varias [4, 14]. La siguiente causa de dicultad es la falta de informacin acerca de este tipo de atributos que sumo inistran los vendedores de componentes COTS. Una visita virtual a los portales de los principales vendedores lo pone en evidencia, como ocurre con Componentsource (www.componentsource.com), o Flashline (www.flashline.com). Aadido a todo esto, podemos encontrar una n ausencia casi total de mtricas que pudieran dar una e estimacin ms objetiva de estos atributos. Este heo a cho se ve empeorado por la situacin actual de los o estndares internacionales relativos a la calidad del a producto software. Las normas ISO 9126 e ISO 14598, encargadas de especicar estos temas, se encuentran ahora mismo en proceso de revisin. El proyecto o SquaRE [2] es el encargado de tratar de hacerlas con-

Caracter sticas Sub-caracter sticas verger, eliminando algunas de las lagunas e inconsisFuncionalidad Adecuacin o tencias que presentan. Por otro lado, es importante Correccin o sealar que los estndares internacionales proporcion a Interoperatividad nan gu y modelos de calidad para temas muy genas Conformidad erales y su aplicacin se suele centrar en temas de o Seguridad un gran espectro. Por tanto, no suelen estar penFiabilidad Madurez sadas para ofrecer soluciones en temas muy concretos. Recuperabilidad En este sentido, nuestro trabajo se concentra en un Tolerancia a Fallos a mbito muy particular, el de las mtricas para los e componentes COTS. Facilidad de Uso Facilidad de Aprendizaje Facilidad de Comprensin o Nuestro objetivo en este articulo es caracterizar los Operatividad atributos de calidad para que sirvan de ayuda en la Eciencia Comportamiento Temporal seleccin de componentes COTS y proponer algunas o Utilizacin de Recursos o mtricas en los casos en los que esto sea posible. e Mantenibilidad Estabilidad Este documento est estructurado en 7 secciones. a Analizabilidad Tras esta introduccin, la seccin 2 dene los trmio o e Cambiabilidad nos utilizados y presentan las distintas clasicaciones Facilidad de Prueba de caracter sticas de calidad para productos software. Portabilidad Facilidad de Instalacin o En la seccin 3 se clasican las caracter o sticas de calAdecuacin o idad particulizndolas para los componentes COTS y a Remplazabilidad se propone un modelo de calidad para componentes. Adaptabilidad La seccin 4 describe un conjunto de atributos de calio dad con sus posibles mtricas segn las clasicaciones e u sticas de calidad segn ISO 9126 u vistas. La seccin 5 propone la documentacin de los Cuadro 1: Caracter o o atributos utilizando plantillas XML. Finalmente, en la seccin 6 se comentan algunos trabajos relaciona- de calidad para componentes software, que desarrolo dos con la presente propuesta y en la seccin 7 se lamos en la seccin 3. o o presentan las conclusiones. Nuestro principal objetivo es detectar los atributos pueden describir los proveedores (externos o internos) de componentes COTS en la informacin que sumino 2. Caracter sticas de Calidad istran acerca de los mismos y que, por tanto, permitir facilitar su valoracin y seleccin por parte de an o o de Componentes los diseadores y desarrolladores de productos softn En general, no existe un consenso a la hora de ware. Las caracter sticas y sub-caracter sticas que dedenir y clasicar las caracter sticas de calidad que nen el modelo general de calidad del software de debe presentar un producto software. Por tanto, hemos basado nuestra propuesta en los estndares in- la ISO 9126 se muestra en la Tabla 1. a Partiendo de ese modelo de calidad, vamos a tratar ternacionales, fundamentalmente el ISO 9126. Sigude particularizarlo realizando distintos tipos de clasiiendo su terminolog entendemos por caracter a, stica de calidad de un producto software a un conjunto caciones. de propiedades mediante las cuales se evala y deu scribe su calidad. Un caracter stica se puede renar en mltiples niveles de sub-caracter u sticas. Llamaremos atributo a una propiedad de calidad a la que puede asignrsele una mtrica, donde una a e mtrica es un procedimiento que examina un come ponente y produce un dato simple, un s mbolo (p.e. Excelente, S No) o un nmero . Hay que tener en , u cuenta que no todas las propiedades que son medibles (p.e. la demostrabilidad). Un modelo de calidad es el conjunto de caracter sticas y sub-caracter sticas, y de cmo estas se relacioo nan entre s Por supuesto, el modelo de calidad a . utilizar va a depender del tipo de producto a evaluar. En este sentido, los estndares y propuestas exisa tentes denen modelos de calidad generales. Una de nuestras contribuciones es la denicin de un modelo o 2 1. En primer lugar, necesitamos discriminar entre aquellas caracter sticas que tienen sentido para los componentes aislados (caracter sticas locales) o bien deben ser valoradas a nivel de la arquitectura software de la aplicacin (que llamaremos o caracter sticas globales). Por ejemplo, la tolerancia a fallos es una t pica caracter stica que va a depender de la arquitectura de la aplicacin, o mientras que la madurez es ms propia de los a componentes. El instante en el cual una caracter stica puede ser observada o medida, permite establecer otra clasicacin de las caracter o sticas de un producto. As tenemos dos posibles categor dependi, as endo de si la caracter stica es observable en tiempo de ejecucin (p.e. el rendimiento) o durante o

2.

el ciclo de vida del producto (p.e. la mantenibil- dad y Complejidad. Es importante observar que alguidad) [13]. nas de ellas cambian de sentido, como detallamos a continuacin (las caracter o sticas que cambian su sen3. Como se menciona en los estndares de ISO, tido aparecen en negrita en la tabla). a es importante identicar los usuarios a los que se dirige el modelo. En nuestra propuesta, los Funcionalidad Esta caracter stica mantiene el misusuarios son fundamentalmente los arquitectos mo sentido para los componentes que para un software, que necesitan evaluar los componentes producto software. Podr amos expresarla como COTS que van a formar parte de su aplicacin. o la capacidad del componente para proporcionar As las interfaces de los componentes objeto , las funciones que satisfagan las necesidades esde nuestro estudio son ms las interfaces proa tablecidas o impl citas cuando se usa bajo las gramticas (es decir, las APIs que denen las a condiciones especicadas. formas de acceder desde otros programas a los Se aade la Compatibilidad que indica con que n servicios que ofrecen los componentes), que las versiones predecesoras es compatible un compointerfaces de usuario. nente, es decir, si se mantiene la funcionalidad del mismo al integrarse en el contexto donde es4. Para componentes COTS, es fundamental distintaba la versin anterior que se desea sustituir. o guir entre mtricas internas y externas. Las intere nas miden los atributos internos del producto Fiabilidad Es aplicable directamente a los componal o de los productos intermedios (p.e. la especinentes, y fundamental para su reutilizacin. La o cacin o el cdigo fuente) durante el diseo y la o o n sub-caracter stica de Madurez la medimos en codicacin. Las externas son las que realizan o funcin de los cambios que sufren las versiones o las mediciones en funcin del comportamiento o comerciales y la velocidad a la que aparecen. del sistema durante las pruebas y la operacin o La Recuperabilidad, en funcin de una serie de o del componente. Por tanto, debido al carcter a atributos que pueden estar presentes o no en de caja negra de los componentes COTS, son las su diseo, indicando los mtodos que se utilizan n e mtricas externas las que interesan. Esto no quie para implementarlos. ta que algunas de las caracter sticas internas den una medida indirecta de las externas, e incluso Facilidad de Uso Esta caracter stica, y todas sus que puedan tener efectos sobre la arquitectura sub-caracter sticas cambian de sentido, dado que nal. As por ejemplo, el tamao de un compo n un componente no ser utilizado por un usuario a nente puede ser importante a la hora de tener en nal directamente sino por los diseadores y den cuenta los requisitos de espacio de la aplicacin. o sarrolladores de aplicaciones software. La facilidad de uso real de un componente debe interPor ultimo, es importante resear que adems de n a pretarse como la capacidad del componente para las caracter sticas de calidad en un componente, hay ser utilizado en la construccin de un producto o otro conjunto de caracter sticas no relacionadas dio sistema software. rectamente con la calidad como pueden ser el precio, En este sentido buscaremos atributos que midan la asistencia tcnica, las condiciones de licencia, etc., e la facilidad de uso del componente durante el que tambin son necesarias a la hora de valorar el e diseo de las aplicaciones, aadiendo la Comn n componente ms adecuado. En este art a culo nos cenplejidad como una nueva sub-caracter stica cuyo tramos inicialmente en las caracter sticas de calidad, sentido es dar una medida de la complejidad del dejando su extensin a otro tipo de caracter o sticas uso e integracin del componente en un producto o para trabajos futuros. o sistema software.

3.

Clasicacin de las caraco ter sticas de calidad

Como hemos indicado anteriormente, no todas las caracter sticas de un producto software son aplicables a un componente COTS. La tabla 2 muestra el modelo de calidad que proponemos para este tipo de componentes. Bsicamente se trata del modelo de calidad de ISO a (ver Tabla 1), donde desaparecen la caracter stica Portabilidad y las sub-caracter sticas Tolerancia a Mantenibilidad La facilidad de mantenimiento o Fallos, Estabilidad y Analizabilidad. Adems, aparea mantenibilidad mide la capacidad de un procen como nuevas las sub-caracter sticas Compatibiliducto software de ser modicado, entendiendo 3

Eciencia Vamos a respetar la denicin y clasio cacin que hace la ISO de esta caracter o stica (en Comportamiento Temporal y Utilizacin de o Recursos), aunque la mayor de las propuestas a de otros autores preeren hablar de Rendimiento (Performance) y usan otra sub-clasicacin. En o cualquier caso, los atributos que vamos a denir para medir estas caracter sticas son aplicables de forma independiente al nombre y clasicacin o que se utilice.

Caracter sticas Funcionalidad

Sub-caracter sticas (Tiempo de ejecucin) o Correccin o

Sub-caracter sticas (ciclo de vida) Idoneidad Interoperatividad Conformidad

Seguridad Fiabilidad Recuperabilidad Facilidad de Uso Facilidad de Aprendizaje Facilidad de Comprensin o Operatividad Complejidad Comportamiento Temporal Utilizacin de Recursos o Compatibilidad Madurez

Eciencia Mantenibilidad

Cambiabilidad Facilidad de Prueba Cuadro 2: Modelo de Calidad para componentes COTS por modicacin cualquier correccin, mejora Presencial Esta mtrica indica si un atributo o o e est presente en el componente o no. Para ello a o adaptacin del software. En este sentido y o utilizaremos una variable booleana y una variaunque las modicaciones internas no sern reala izadas por el usuario del componente (desarrolable de tipo string que especique como o con que mtodo, formato etc..., se implementa el e lador), s necesitar probar el componente antes a atributo en cuestin en caso de estar presente. o de incluirlo en su aplicacin o cambiar alguno de o las parmetros que se pueden particularizar. Por a e ello, las sub-caracter sticas Cambiabilidad y Fa- Tiempo Esta mtrica se utiliza para medir intervalos de tiempo, utiliza una variable de tipo entero cilidad de Prueba son las que deben ser medidas para indicar el valor absoluto y una variable de para los componentes. tipo string para indicar las unidades, por ejemplo, 10 segundos o 4 meses. Portabilidad Esta caracter stica se dene como la capacidad de poder ser reutilizado en distintos entornos. En COTS, esa es la esencia misma de Nivel Se utiliza para indicar un grado de esfuerzo, habilidad, etc... cuando se da una medida subjelos componentes, que son diseados y desarroln tiva dentro de una escala de valores. Es una varilados espec camente para ser reutilizados. (Es able entera que puede tomar el siguiente rango importante observar que en la Ingenier del softa de valores: 0 (Muy Bajo), 1 (Bajo), 2 (Medio), ware Basada en Componentes, reutilizar signica 3 (Alto), 4 (Muy Alto). no slo usar ms de una vez, sino usar en distino a tos contextos [14]). Ratio Se utiliza para dar un porcentaje (entre 0 y 100) mediante una variable de tipo entero.

4.

Atributos de los Componentes

En esta seccin vamos a describir los atributos de o calidad para medir las distintas caracter sticas que forman parte del modelo de calidad que proponemos. Para ello vamos a dividirlos segn sean medibles duu rante la ejecucin de los componentes, o formen parte o de su ciclo de vida. Para medir los atributos utilizaremos varias mtrie cas que describimos a continuacin: o 4

Adems de estas mtricas bsicas, para medir ala e a gunos atributos utilizaremos tambin e ndices, que se obtienen a partir de dos mtricas bsicas, generane a do un indicador. Un ejemplo de este tipo de medidas lo encontramos en el ndice de complejidad, un atributo que relaciona el nmero de parmetros conu a gurables de un componente con el nmero de interu faces que implementa. En general, es conveniente distinguir entre mtricas bsicas e indicadores, pues ese a tos ultimos son valores derivados de los primeros. Sin embargo, la expresividad de alguno de estos ndices

justica que los hayamos incluido en nuestro modelo de calidad.

Capacidad de Control (Controllability) Indica si el componente permite realizar un control sobre el acceso a los servicios que proporciona. Ejemplos son componentes que proporcionen interfaces con funciones para realizar identicacin o o autenticacin de los usuarios. o Utilizaremos una mtrica de tipo Presencial, ine dicando el mecanismo de control implementado. Capacidad para Auditar (Auditability) Este atributo indica si el componente tiene la posibilidad de registrar las operaciones que lleva a cabo y qu usuario las realiza. e Por ejemplo, el componente puede proporcionar funciones que permitan abrir, escribir y cerrar un archivo de registro (log le), anotando el usuario, el tipo de operacin, los datos implicados o el o instante en el cual se realiza cada operacin. o

4.1.

Atributos medibles en tiempo de ejecucin o

La tabla 3 resume los atributos de calidad para componentes COTS que son observables durante la ejecucin del componente, agrupados segn la subo u caracter stica que miden e indicando el tipo de variable que utilizan. 4.1.1. Atributos asociados (Accuracy) a Correccin o

Precisin (Precision) o Este atributo evala el porcentaje de resultados u obtenidos con precisin insuciente respecto a los o requisitos del usuario.

Aparte de medir la precisin computacional de o Utilizaremos una mtrica de tipo Presencial, que e las operaciones del componente, este atributo indique como realiza el registro de operaciones y tambin va a permitir medir, por ejemplo, el e como recuperarlo. nivel de actualizacin (freshness) de la inforo macin que devuelven las operaciones invocadas. o 4.1.3. Atributos asociados a RecuperabiliEste es el caso de un componente que devuelve dad datos que mantiene en la cache en aras de in Secuencializable (Serializable) crementar la eciencia, en detrimento del grado de actualizacinde la informacin que proporo o Indica si el componente es capaz de secuenciar ciona. su cdigo y su estado, para transferirlo entre dio versos agentes y recuperarlos con posterioridad. Este atributo se mide con una variable de tipo Ratio, calculada dividiendo el nmero de resulu Utilizaremos una mtrica de tipo Presencial. e tados imprecisos obtenidos entre el nmero tou Persistente (Persistent) tal de resultados que devuelven las operaciones del componente al ser invocadas un determinado Este atributo sealar si el componente puede n a nmero de veces. u almacenar su estado de forma persistente. Exactitud Computacional (Computational Accuracy) Este atributo evala el nmero de resultados inu u correctos que devuelven las operaciones del componente, respecto a sus especicaciones. Se mide mediante una variable de tipo Ratio, calculada dividiendo el nmero de resultados inu correctos encontrados entre el nmero total de u operaciones invocadas. 4.1.2. Atributos asociados a Seguridad (Security) Utilizaremos una mtrica de tipo Presencial. e Transaccional (Transactional) Este atributo debe indicar si el componente suministra alguna interfaz que permita que sus operaciones estn sujetas a transacciones (p.e. un e componente CORBA que implemente el interfaz Resource). Utilizaremos una mtrica de tipo Presencial. e Tratamiento de Errores (Error Handling) Este atributo debe indicar si se realiza algn tipo u de tratamiento de errores y en su caso el tipo de tratamiento de errores que lleva a cabo el componente. Se utiliza un a variable Presencial que deber ina dicar el nivel de tratamiento de los errores, p.e. siguiendo un modelo clsico como el siguiente: a Detectar Los detecta pero no realiza ninguna accin o 5

Cifrado de datos (Data Encryption) El atributo seala si el componente es capaz de n manejar los datos de forma cifrada, y si es as , que mtodo utiliza. e Utilizaremos por tanto una mtrica de tipo Prese encial.

Detectar y avisar Los detecta y avisa de ello Tratar Los detecta e implementa un mecanismo de excepciones 4.1.4. Atributos asociados al Comportamiento Temporal (Time Behavior)

componente es adecuado para los productos software donde un requisito importante sea la limitacin de memoria. o Este atributo mide el consumo de recursos respecto a las necesidades de memoria (no de kilobytes) que necesita el componente para su ejecucin. Se puede indicar un tamao m o n nimo, mxia mo o medio (o recomendable, en el sentido de un rendimiento ptimo). o Se utiliza una variable de tipo Entero que indique el nmero de kilobytes necesarios. u Utilizacin de Disco (Disk utilization) o En algn caso espec u co de diseo de un producn to software puede ser necesario limitar el espacio que se utiliza en disco. Por tanto, se mide el tamao de disco que ocupa el componente de n forma esttica, y se debe aadir el que ocupa a n de forma dinmica cuando se invocan sus operaa ciones. Este atributo mide el espacio en disco (no de kilobytes) que necesita el componente tanto para almacenarse y como para ser utilizadas sus operaciones o servicios. Se utiliza una variable de tipo Entero que indique el nmero de kilobytes necesarios. u

En estos atributos distinguiremos entre los que son apropiados para valores discretos y los que se pueden asociar a un ujo continuo de datos (data streaming). En primer lugar, indicamos los atributos relacionados con el tratamiento de datos discretos. Tiempo de Respuesta (Response Time) Este atributo se asocia a los mtodos que ime plementa un componente en cualquiera de sus interfaces, y evala el tiempo transcurrido desde u que se recibe la peticin, hasta que se emite la o respuesta. Como este tiempo normalmente depender de los a parmetros de entrada, ser preciso especicar si a a se trata del tiempo mejor, peor, o medio. Este atributo puede asociarse tambin a intere faces, entendiendo entonces el tiempo peor (resp. mejor, o medio) como el peor (mejor, o medio) de los tiempos de las operaciones que forman parte de la interfaz. Se mide con una variable de tipo Tiempo. En segundo lugar, describimos los atributos relacionados con el tratamiento de un ujo continuo de datos:

4.2.

Atributos medibles durante el ciclo de vida

Los atributos de calidad para componentes COTS que son observables durante el ciclo de vida del componente se detallan en los siguientes apartados y se Capacidad en Emisin (Throughput) o muestran resumidos en la tabla 4, agrupados segn u Este atributo mide la cantidad de informacin o la sub-caracter stica que miden e indicando el tipo de que es capaz de emitir el componente en un inmtrica que utilizan. e tervalo de observacin dado. o

Se mide mediante un /emphEntero que in4.2.1. Atributos asociados a Idoneidad dique el nmero de kilobytes de informacin por u o (Suitability) unidad de tiempo. Un componente ser ms idneo cuanto ms se a a o a Capacidad en Recepcin (Capacity) o ajuste a los requisitos funcionales que necesita o esEste atributo mide la cantidad de informacin pecica el comprador. Por tanto, se deben medir el o que es capaz de admitir y procesar el componente nmero de interfaces que se utilizan frente a las que u en un intervalo de observacin dado. o se ofrecen, es decir, que porcentaje se aprovechan; y Se mide mediante un /emphEntero que in- cuantas interfaces de las que se necesitan no las sumdique el nmero de kilobytes de informacin por inistra el componente. u o La dicultad en recoger este tipo de atributo unidad de tiempo. est en que no puede ser medido inicialmente por a el proveedor del componente, sino en funcin de los o 4.1.5. Atributos asociados a Utilizacin de o requisitos de sus potenciales compradores. Recursos (Resource utilization) Requisitos de Memoria (Memory utilization) La cantidad de memoria que necesita un componente para ejecutarse puede determinar si el 6 Cobertura (Coverage) Relaciona el nmero de interfaces que necesita el u usuario del componente con el nmero de interu faces que ofrece.

Sub-caracter stica Correccin o Seguridad

Recuperabilidad

Comportamiento Temporal

Utilizacin de Recursos o

Atributo 1. Precisin o 2. Exactitud computacional 3. Cifrado de Datos 4. Capacidad de Control 5. Capacidad para Auditar 6. Secuencializable 7. Persistente 8. Transaccional 9. Tratamiento de Errores 10. Tiempo de Respuesta 11. Capacidad en Emisin o 12. Capacidad en Recepcin o 13. Requisitos de Memoria 14. Utilizacin de Disco o

Tipo Ratio Ratio Presencial Presencial Presencial Presencial Presencial Presencial Presencial Tiempo Entero Entero Entero Entero

Cuadro 3: Atributos de calidad para componentes COTS medibles durante tiempo de ejecucin o Se puede expresar con una mtrica de tipo Ratio e segn la siguiente frmula: u o Interfaces Necesarias Interfaces Ofrecidas 100 Interfaces Necesarias Exceso (Excess) Relaciona el nmero de interfaces del compou nente que se van a utilizar en la aplicacin con o las que este ofrece. Se puede expresar mediante una mtrica de tipo e Ratio segn la siguiente frmula: u o Interfaces Utilizadas Interface Ofrecidas Interfaces Ofrecidas 4.2.2. Atributos asociados a Interoperatividad (Interoperability)

Compatibilidad de los datos (Data compatibility) Este atributo seala si la representacin de los n o datos de entrada y salida es conforme a algn u estndar de facto o internacional. Por ejemplo, si a los resultados los produce en un formato propietario, o bien en XML o similar. Se utilizar una mtrica de tipo Presencial para a e indicar si maneja los datos en un formato propietario o estndar y, en su caso, cual. a 4.2.3. Atributos asociados a Conformidad (Compliance)

100

Cobertura de la Implementacin (Service o implementation coverage) Es posible que algunas implementaciones de componentes que proveen servicios no cubran el total de los servicios descritos en la especicacin. Este atributo pretende medir el nmero o u de operaciones que se han implementado respecto al nmero total de operaciones que se indican u en la especicacin. o Por ejemplo, muchos proveedores de servicios para plataformas como EJB o CORBA no implementan toda la funcionalidad descrita en la especicacin del servicio. Este atributo mide el o grado de cobertura de la implementacin frente o a la especicacin. o Se mide con un mtrica de tipo Ratio segn la e u siguiente frmula: o 100 Operaciones Implementadas Operaciones Especicadas 7

Conformidad con estndares (Standarda ization) Este atributo indica si el componente cumple algn estndar internacional. u a Utilizaremos una mtrica de tipo Presencial, e para indicar si cumple algn estndar y, de ser u a cierto, qu estndares cumple el componente. e a Certicaciones (Certication) De forma similar al anterior atributo, si la componente puede acreditar algn tipo de certiu cacin, tanto por organizaciones externas o de o forma interna, puede indicarlo con este atributo. Se utiliza una mtrica de tipo Presencial para e indicar si tiene algn tipo de certicacin. u o 4.2.4. Atributos asociados a Compatibilidad (Compatibility)

Compatibilidad hacia atrs (Backwards a Compatibilidad)

Este atributo indica si existe compatibilidad de 4.2.6. Atributos asociados a Facilidad de la versin actual del componente con las vero Aprendizaje (Learnability) siones anteriores del mismo. Es decir, una nueEn relacin con la capacidad de ser aprendido, hay o va versin del componente qu versin anterior o e o un conjunto de atributos relativos al tiempo necepuede sustituir sin necesidad de ningn tipo de u sario para poder llevar a cabo una determina funcin o adaptacin. o usar, congurar, etc. de forma correcta. Estos Se utiliza una mtrica de tipo Presencial, que tiempos, asignados inicialmente por el vendedor o ese permita indicar con qu versin anterior existe timados por terceros, dan una indicacin de la facilie o o compatibilidad. dad de aprendizaje que presenta un componente. Estos tiempos se entendern como tiempos medios para a una persona tcnica con un cierto grado de experiene 4.2.5. Atributos asociados a Madurez (Macia y preparacin, sin ser un experto ni un novato. o turity) Periodo para usar correctamente (time to La madurez de componente se mide en funcin o use) del nmero de versiones comerciales que han salido u Este atributo mide el tiempo medio que necesial mercado y en funcin del tiempo que una vero tar un desarrollador de aplicaciones para poder a sin permanece en activo, es decir, vamos a medir un o utilizar de forma correcta el componente. tiempo medio entre versiones comerciales del compoSe mide utilizando una mtrica de tipo Tiempo. e nente. A esta atributo lo hemos denominado volatilidad porque da un indicacin del tiempo que dura la o Periodo para congurar correctamente version en el mercado. (time to congure) Volatilidad (Volatility) Este atributo mide el promedio de tiempo entre cada nueva version comercializada y su versin o predecesora. Nos referiremos a el como Tiempo medio entre versiones. Se utiliza una variable de tipo Tiempo, que indique el tiempo medio entre versiones. Evolucionabilidad (Evolvability) El nmero de versiones puede dar una indicacin u o de la madurez de un producto, y de cmo ha o ido evolucionando desde que estaba disponible su primera versin. Puede ser interesante en conjuno cin con la volatilidad para indicarnos si debeo mos esperar posibles cambios en un periodo corto de tiempo. Este atributo se mide mediante un /emphEntero el nmero absoluto de versiones del componente u que han sido distribuidas comercialmente. Fallos Eliminados (Failure removal) Una medida de madurez es el nmero de errores u corregidos en cada versin. Aunque en principio o un alto nmero de errores corregidos puede pareu cer que estabiliza la nueva versin, la experiencia o de los autores en el desarrollo de productos software nos lleva a armar que el nmero de errores u corregidos es muchas veces un buen indicador del nmero de errores que quedan por descubrir. u Mide el tiempo medio que necesitar un desarrola lador para poder congurar de forma adecuada los parmetros que el componente permite para ticularizar, comprendiendo el signicado correcto de los valores que se pueden utilizar. Se mide utilizando una mtrica de tipo Tiempo. e Periodo para administrar correctamente (time to admin) Se relaciona con el tiempo medio para poder realizar las operaciones de administracin que reo quiera el componente de forma correcta. Se mide utilizando una mtrica de tipo Tiempo. e Periodo para dominar (time to expertise) Se relaciona con el tiempo medio para llegar a dominar de forma precisa la gran mayor de las a posibilidades que ofrece el componente. Se mide utilizando una mtrica de tipo Tiempo. e 4.2.7. Atributos asociados a Facilidad de Comprensin (Understandability) o

Este tipo de atributos se relacionan con las descripciones del componente, las demostraciones o tutorials disponibles y con la comprensin directa de los servio cios e interfaces que el componente ofrece. Es importante sealar que esta caracter n stica esta muy relacionada con la Facilidad de Aprendizaje, ya que, para que un componente puede ser aprendido es necesario que antes sea comprendido por sus posibles usuarios. Por tanto, incluimos aqu los atributos Se utiliza una mtrica de tipo Entero para in- que permiten calicar la facilidad de comprensin del e o dicar el nmero medio de errores eliminados en componente que inuirn en la facilidad de aprenu a las ultimas versiones. dizaje del mismo por parte del usuario. 8

 Documentacin de Usuario (User Docu- 4.2.8. o mentation) Este atributo indica la calidad de la documentacin suministrado junto con el compoo nente. Al ser una medida subjetiva utilizaremos una mtrica con varias categor e as. Se utiliza una mtrica de tipo Nivel que indique e la calidad de la documentacin. o Sistema de Ayuda (Help System) Este atributo indica la calidad del sistema de ayuda asociado con el componente y disponibles por el usuario para localizar informacin acerca o de los servicios e interfaces del componente. Al igual que en el caso de la documentacin, se mide o asignndole un grado de calidad. a Se utiliza una mtrica de tipo Nivel que calique e la calidad del sistema de ayuda. Documentacin computacional (Computo er Documentation) Este atributo indica la existencia de algn tipo u de documentacin suministrada con el compoo nente que permita a las herramientas y plataformas de componentes con facilidades reexivas, la identicacin del signicado de sus servicios y su o posterior invocacin de forma dinmica. o a Ejemplos de este tipo de documentacin ser o an las descripciones usando UML o MOF (MetaObject Facilities) del meta-modelo del componente, de sus servicios y de su contexto. Se utiliza una mtrica de tipo Presencial que e indique si estn disponibles este tipo de docua mentacin y, en su caso, en que formato. o Formacin (Training) o

Atributos asociados a Operatividad (Operability)

Esfuerzo para operar (Eort for operating) Este atributo indicar el grado de esfuerzo que a se considera necesario para operar con el componente. Se puede medir utilizando una variable de tipo Nivel. Esfuerzo para congurar (Tailorability) Este atributo indicar el grado de esfuerzo que a se considera necesario para congurar adecuadamente el componente, mediante la particularizacin de sus parmetros. o a Un componente puede tener pocos o muchos parmetros que se puedan modicar se mide a con el atributo Modicabilidad pero tambin e se debe tener en cuenta la cantidad de valores diferentes que estos parmetros pueden tomar, a as como el signicado y las implicaciones que esos valores pueden tener en el comportamiento del componente. Por tanto, se debe dar una idea de la dicultad que esto representa independientemente del nmero absoluto de parmetros. u a Se puede medir utilizando una variable de tipo Nivel que indique el esfuerzo necesario para congurar el componente. Esfuerzo para administrar (Administrability) Este atributo indicar el grado de esfuerzo que se a considera necesario para realizar las operaciones de administracin del componente. o

Se puede medir utilizando una variable de tipo Si existe alguna forma de realizar un aprendizaNivel. je o cursos de formacin sobre el uso y congo uracin del componente que sea ofrecida por el o proveedor del mismo, se indicar con este atrib- 4.2.9. Atributos asociados a Complejidad a (Complexity) uto. Se utiliza una mtrica de tipo Presencial. e

El objetivo de esta sub-caracter sticas es dar una medida de la complejidad del uso de un componente y Cobertura de la Demostracin (Demon- de su integracin en un producto o sistema software. o o stration Coverage) Medimos el nmero total de interfaces que tiene y el u u Este atributo mide el porcentaje de interfaces nmero medio de operaciones por interfaz. (servicios) que estn disponibles en una dea Interfaces Ofrecidas (Provided Interfaces) mostracin del componente respecto al total de o interfaces (servicios) que se suministran. Medida de la cantidad de interfaces que ofrece el Se mide con una mtrica de tipo Ratio, segn la e u siguiente frmula: o 100 Interfaces Demostradas Interfaces Suministradas 9 componente como medida indirecta de la complejidad. Cuanto mayor sea este nmero mayor u ser la complejidad de uso, y posiblemente, tama bin su complejidad funcional. e Se mide con una variable de tipo /emphEntero.

 Interfaces Externas Utilizadas (Required 4.2.11. Interfaces)

Atributos asociados a Facilidad de Prueba (Testability)

Medida de la cantidad de interfaces de otros comEstos atributos indican si el componente suminisponentes que necesita el componente para oper- tra algn tipo de prueba que se le pueda realizar de u ar. Este atributo da una indicacin de la com- forma independiente y sin tener que integrarlo previo plejidad de la integracin de este componente en amente en una aplicacin. o o un sistema, as como el nivel de dependencia con respecto a otros componentes. Auto-test de Arranque (Start-up self-test) Se mide con una variable de tipo /emphEntero. Este atributo se relaciona con la capacidad que puede tener el componente para comprobar su Indice de Complejidad (Complexity Rapropio estado y del entorno que necesita para tio) ejecutarse correctamente. Este atributo mide el nmero medio de operau Se utiliza una mtrica de tipo Presencial que ine ciones por interfaz ofrecida que presenta el comdique si se suministran auto-test de arranque y, ponente. en su caso, de que tipo. Se utiliza una mtrica de tipo Indice segn la e u frmula siguiente: o Bater de pruebas(Tests suite provided) a Operaciones en todas las Interfaces Ofrecidas Interfaces Ofrecidas 4.2.10. Atributos asociados a Cambiabilidad (Changeability) Este atributo indica si el usuario puede disponer de algn tipo de pruebas que se le puedan pasar u al componente de forma aislada para comprobar su funcionamiento o realizar medidas, sin tener que integrarlo en la aplicacin nal. o Se puede utilizar una variable de tipo Presencial que indique si se suministran pruebas para el componente y, en su caso, cules y de qu tipo. a e

Modicabilidad (Customizability) Este atributo mide el nmero de parmetros que u a son modicables por el usuario (diseador) del n componente. Se utiliza una mtrica con una variable de tipo e Entero que indique el nmero de parmetros que u a ofrece el componente.

5.

Documentacin de los como ponentes

Una vez disponemos de un conjunto de atributos de calidad que permiten evaluar componentes COTS, Indice de Modicabilidad (Customizabilinos planteamos en esta seccin los mecanismos ms o a ty Ratio) adecuados para documentarlos. Este atributo relaciona el nmero de parmetros u a Entre las posibles opciones nos hemos decantado que tiene un componente con el nmero de inter- por el modelo de propiedades de ODP [9], en el u faces ofrecidas del mismo. Esta medida nos pro- que cada atributo se identica mediante un par (nomporciona un indicador de la capacidad de modi- bre,valor), y cada nombre de atributo tiene asociado cacin del componente. As un componente que un tipo. Luego, estas propiedades pueden describirse o , ofrece pocas interfaces y muchos parmetros nor- fcilmente mediante plantillas XML, puesto que se a a malmente ser muy modicable, aunque dif a cil trata de un lenguaje neutro e intermedio, y que acde manejar, mientras que uno con muchas inter- tualmente es de fcil conexin con todo tipo de hera o faces y pocos parmetros es poco modicable. a ramientas. Ms an, cuando nuestro objetivo es poder a u Se utiliza una variable de tipo de Indice, segn utilizar esta informacin para implementar procesos u o la siguiente frmula: o de seleccin automtica o semi-automtica de como a a ponentes. Numero de Parametros El siguiente ejemplo muestra una descripcin del o valor de dos atributos en nuestra notacin. o Numero de Interfaces Ofrecidas Capacidad de Control del (Change Control Capability) Cambio
<property name="Computational Accuracy"> <type>xsd:ratio</type> <value>100</value> </property> <property name="Help Documentation"> <type>xsd:level</type> <value>3</value> </property>

Este atributo indica la capacidad del usuario para identicar fcilmente la versin utilizada de a o cada componente. Se puede medir utilizando una variable de tipo Nivel. 10

Sub-caracter stica Idoneidad

Interoperatividad Conformidad Compatibilidad Madurez

Facilidad de Aprendizaje

Facilidad de Comprensin o

Operatividad

Complejidad

Cambiabilidad

Facilidad de Prueba

Atributo 1. Cobertura 2. Exceso 3. Cobertura de la Implementacin o 4. Compatibilidad de los Datos 5. Conformidad con Estndares a 6. Certicaciones 7. Compatibilidad hacia atrs a 8. Volatilidad 9. Evulocionabilidad 10. Fallos Eliminados 11. Periodo para Usar Correctamente 12. Periodo para Congurar Correctamente 13. Periodo para Administrar Correctamente 14. Periodo para Dominar 15. Documentacin de Usuario o 16. Sistema de Ayuda 17. Documentacin Computacional o 18. Formacin o 19. Cobertura de la Demostracin o 20. Esfuerzo para Operar 21. Esfuerzo para Congurar 22. Esfuerzo para Administrar 23. Interfaces Ofrecidas 24. Interfaces Externas Utilizadas 25. Indice de Complejidad 26. Modicabilidad 27. Indice de Modicabilidad 28. Capacidad de Control de Cambio 29. Auto-test de Arranque 30. Bater de Pruebas a

Tipo Ratio Ratio Ratio Presencial Presencial Presencial Presencial Tiempo Entero Entero Tiempo Tiempo Tiempo Tiempo Nivel Nivel Presencial Presencial Ratio Nivel Nivel Nivel Entero Entero Indice Entero Indice Nivel Presencial Presencial

Cuadro 4: Atributos de calidad para componentes COTS medibles durante el ciclo de vida Esta notacin es adems consistente con alguno de sin profundizar hasta el nivel de mtricas, dejando o a e los traders existentes para componentes COTS [7, 8]. por tanto sin detallar los atributos que se necesitan medir. En este sentido, nuestro trabajo realiza una aportacin intentando concretar dichas mtricas. o e 6. Trabajos Relacionados Parte del trabajo futuro que pretendemos acometer es la fusin de ambos aspectos, los de proceso y los de o Hay dos tipos de propuestas relacionadas con el producto, en torno al modelo de calidad aqu denido. presente trabajo. En primer lugar se encuentran aque- Para ello pretendemos hacer uso de XML, lo que nos llos trabajos que realizan una clasicacin de las car- va a permitir integrar las herramientas existentes de o acter sticas de calidad de los productos software, en- bsqueda y evaluacin de componentes COTS de foru o tre los que mencionaremos las normas ISO 9126 [11] ma que la mayor parte del proceso se pueda automae IEEE/ANSI 830-1993 [6], y diferentes propuestas tizar. [3, 4, 12, 13] . Quiz la principal diferencia con nuea stro trabajo es el mbito de aplicacin, mucho ms a o a general en todos ellos, lo que diculta su utilizacin 7. o Discusin y Conclusiones o de forma efectiva para componentes (ms an en ena u tornos comerciales). En ese sentido nuestra propuesEn este art culo hemos presentado una particuta se restringe a un mbito muy particular, cindose larizacin del modelo general de calidad de ISO, a ne o a las caracter sticas particulares de los componentes ajustndolo a los aspectos de calidad espec a cos de COTS. componentes COTS. Asimismo, hemos identicado Otros trabajos y estndares [1, 5, 10] se centran en un conjunto de atributos de calidad que son aplicaa el proceso de evaluacin de los componentes COTS bles a este tipo de componentes, junto con una serie o y de los sistemas desarrollados en base a ellos, pero de mtricas para evaluarlos. Es importante la relacin e o 11

que establecemos entre el modelo de calidad y los atributos que denimos, un tema que la mayor de a las propuestas y estndares dejan sin claricar. a Nuestra motivacin principal es la mejora de los o procesos de evaluacin y seleccin de componentes o o COTS para construir con ellos aplicaciones comerciales. Si bien son claras las ventajas que reporta disponer de esas mtricas, tambin somos conscientes e e de las dicultades que conllevan. En primer lugar, no pensamos que los fabricantes de componentes alcancen fcilmente un consenso sobre los parmetros de a a calidad que hay que medir en ellos, y menos que estn e dispuestos a facilitar toda esa informacin. Razones o comerciales, de marketing y de imagen van a dicultar que parmetros negativos (como el tiempo de a fallos, o la ausencia de alguna cualidad importante) sean publicados por los fabricantes. Por otro lado, cada empresa est ms interesada en resaltar aquellos a a atributos en los que sus componentes sean competitivos, restndole importancia a aquellos que no se a implementen o para los que no se alcancen buenos valores. Personalmente creemos que esos factores son principalmente los que ocasionan gran parte de las dicultades con las que se est encontrando ISO a la a hora de aprobar las normas sobre mtricas aparte e de porque sean demasiado genricas, por supuesto. e Sin embargo, tambin pensamos que sin mtricas e e para evaluar componentes no se puede conseguir una verdadera ingenier del software. Para resolver este a conicto, una posible solucin a largo plazo puede o basarse en dos factores principales. En primer lugar, no puede haber consenso sobre temas demasiado genricos. Por ello, es preciso denir y consensuar e modelos de calidad para productos muy espec cos. Nuestro trabajo pretende ser una primer aportacin o a este respecto. Y en segundo lugar, quiz la evalua acin de la calidad de los componentes (es decir, las o medidas que se realizan sobre sus atributos de calidad) debiera hacerse por entidades independientes, al menos hasta que los fabricantes de componentes software adquieran la madurez de los de hardware. Para estos ultimos existen catlogos (data sheet) que a publican los propios fabricantes con los valores de sus atributos de calidad. Hoy en d es todav una utop a a a disponer de catlogos as para los componentes softa ware, pero pensamos que es algo hacia lo que habr a que tender si realmente queremos hacer una ingenier del software basada en componentes. a

[2] Motoei Azuma. Square the next generation of the ISO/IEC 9126 and 14598 international standards series on software product quality. ESCOM (European Software Control and Metrics conference), April 2001. Available at http://www.escom.co.uk/ conference2001/papers/azuma.pdf. [3] B.W. Boehm and al. Qualitative evaluation of software quality. In Proc. 2nd ICSE, pages 592605, 1976. [4] Jan Bosch. Design & Use of Software Architectures. Addison Wesley, 2000. [5] Wilfred J. Hansen. A generic process and terminology for evaluating COTS software. Available at http://www.sei.cmu.edu/staff/wjh/Qesta.html, August 2001. [6] IEEE/ANSI. Recommended practice for software requirements specications. International Standard 830-1993, IEEE, 1993. [7] Luis Iribarne, Carina Alves, Jaelson Castro, and Antonio Vallecillo. A non-functional approach for COTS-components trading. In Proc. of WER 2001, Buenos Aires, Argentina, November 2001. [8] Luis Iribarne, Jos M. Troya, and Antonio Vallecile lo. Trading for COTS components in open environments. In Proc. of the 27th Euromicro Conference, pages 3037, Warsaw, Poland, September 2001. IEEE CS Press. [9] ISO/IEC. RM-ODP. Reference Model for Open Distributed Processing. Rec. ISO/IEC 10746-1 to 107464, ITU-T X.901 to X.904, ISO/ITU-T, 1997. [10] ISO/IEC-14598. Software Engineering - Product evaluation. International Standard ISO/IEC 14598, ISO. [11] ISO/IEC-9126. Information technology - Software product evaluation - Quality characteristics and guidelines for their use. International Standard ISO/IEC 9126, ISO, December 1991. [12] James A. McCall, Paul K. Richards, and Gene F. Walters. Factors in software quality, volume III: Preliminary handbook on software quality for an acquisition manager. Technical Report RADC-TR-77-369, vol. III, Hanscom AFB, MA 01731, 1977. [13] Otto Preiss, Alain Wegmann, and Jason Wong. On quality attribute based software engineering. In Proc. of the 27th Euromicro Conference, pages 114120, Warsaw, Poland, September 2001. IEEE CS Press. [14] Clemens Szyperski. Component Software Beyond Object-Oriented Programming. Addison-Wesley and ACM Press, Boston, 1998.

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 ndings. Available at sunset.usc.edu/publications/TECHRPTS/2000/ usccse2000-501/usccse2000-501%.pdf, 2000.

12