Está en la página 1de 8

136 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO.

2, APRIL 2006

Medidas de Usabilidad de Componentes


Software
Manuel F. Bertoa y Antonio Vallecillo, Member IEEE

concretos tales como el DSBC o los componentes COTS. En


Resumen La ltima dcada ha marcado el primer intento real este sentido, han aparecido nuevas propuestas que tratan de
de convertir el desarrollo software en una ingeniera usando los definir modelos de calidad para componentes COTS o para
conceptos de Desarrollo Software Basado en Componentes (DSBC) sistemas basados en componentes [4, 5, 6, 7, 8, 9].
y de Componentes COTS (Commercial Off-The-Shelf) cuyo
El objetivo del presente trabajo es definir un conjunto de
objetivo es crear elementos de alta calidad que se puedan
ensamblar para construir un sistema funcional. Uno de los procesos medidas objetivas, realistas y fciles de automatizar para
crticos dentro del DSBC es la seleccin de los componentes que, componentes software, que se puedan usar para describir y
cumpliendo los requisitos de funcionalidad definidos por el usuario, valorar sus caractersticas de calidad y que puedan ayudar en
formarn parte del producto final. Sin embargo, existe una falta de el proceso de seleccin de componentes. Estas medidas
modelos de calidad y de medidas que ayuden en la evaluacin de las podran ofrecer una informacin similar a la que proporcionan
caractersticas de calidad de los componentes software durante este
proceso de seleccin. Este trabajo presenta un conjunto de medidas
actualmente los catlogos de componentes hardware, los
para valorar la Usabilidad de los componentes COTS, y describe el cuales son muy tiles para seleccionarlos y para buscar
mtodo seguido para obtenerlas y validarlas empricamente. sustitutos si se necesita una solucin alternativa o de respaldo.
La valoracin de la calidad de un componente software
Palabras clave Software Metrics, Software Quality. industrial es en general un objetivo demasiado amplio y
ambicioso. As, el Modelo de Calidad de ISO/IEC 9126 define
la calidad de un producto software en trminos de seis
I. INTRODUCCIN caractersticas principales (Funcionalidad, Fiabilidad,

E l Desarrollo de Software Basado en Componentes


(DSBC) se ha convertido en una importante alternativa
para el desarrollo de aplicaciones software, en particular para
Usabilidad, Eficiencia, Mantenibilidad y Portabilidad), las
cuales se refinan en 27 subcaractersticas. Esto nos obliga a
centrar nuestro esfuerzo en una caracterstica concreta, la
sistemas distribuidos. Uno de los de pilares en este proceso de Usabilidad, debido a su importancia dentro del DSBC. La
DSBC es la adecuada seleccin de los componentes COTS. Usabilidad es inherente a la calidad del software porque
Actualmente, la mayora de las cuestiones tcnicas y expresa la relacin entre el software y su dominio de
tecnolgicas del DSBC parecen haber sido abordadas aplicacin. Por lo tanto, en este trabajo presentamos un
satisfactoriamente. Es por tanto ahora cuando en mejores conjunto de medidas para valorar la Usabilidad de los
condiciones se encuentra la comunidad de Ingeniera del componentes software. Adems, describimos el proceso
Software para tratar en profundidad los aspectos extra- seguido para obtenerlas y validarlas, proceso que puede
funcionales del DSBC, y la evaluacin de su calidad, temas reutilizarse para la definicin y validacin de medidas de otras
que cada da cobran mayor importancia por el impacto caractersticas de calidad.
industrial que comienza a tener el DSBC.
Hasta hace relativamente poco tiempo, exista una falta II. CONCEPTOS BSICOS
absoluta de mtricas que pudieran ayudar a evaluar
objetivamente lo atributos de calidad de los componentes A. Desarrollo de Software Basado en Componentes (DSBC)
software. Los estndares internacionales a cargo de estos En primer lugar, es necesario definir que se entiende por
temas (p.e. ISO/IEC 14598 [1] y la serie ISO/IEC 9126 [2]) componente software. En este trabajo vamos a utilizar la
estn actualmente bajo revisin. El proyecto SQuaRE [3] se definicin de Szyperski: Los componentes software son
ha creado especficamente para hacerlos converger, intentando unidades binarias desarrolladas, adquiridas e incorporadas al
eliminar las lagunas, conflictos y ambigedades que presentes sistema de forma independiente, y que interactan para formar
actualmente en ellos. Un inconveniente de estos estndares un sistema funcional [11].
internacionales es que proporcionan modelos y directrices de El adjetivo COTS har referencia a una clase especial de
calidad muy generales, pero difciles de aplicar en dominios componentes: entidades comerciales (es decir, que se pueden
vender o licenciar) que permiten el empaquetado, distribucin,
almacenamiento, recuperacin y particularizacin por parte
SM. F. Bertoa y A. Vallecillo son Profesores del Departamento de
Lenguajes y Ciencias de la Computacin de la Universidad de Mlaga,
del usuario, que generalmente son de grano grueso, y que
Espaa. (e-mail: bertoa@lcc.uma.es, av@lcc.uma.es). residen en repositorios software [6].
BERTOA AND VALLECILLO : USABILITY MEASURES FOR SOFTWARE 137

Actualmente, grandes organizaciones como el ejrcito sern los miembros de los equipos software que desarrollan y
estadounidense ya han decidido utilizar los componentes mantienen sistemas basados en componentes. Los usuarios de
COTS con objeto de mantener el coste y esfuerzo de sus componentes necesitan: identificarlos, localizarlos y
desarrollos software bajo control [12]. Igualmente, estn seleccionarlos de acuerdo con las restricciones de la
proliferando los vendedores de componentes software, con arquitectura del sistema y con los requisitos de los propietarios
compaas como ComponentSource, que estn empezando a del sistema; integrarlos para construir el sistema; y,
distribuir, vender y licenciar componentes de terceras casas posteriormente, continuar con el mantenimiento del sistema
[10, 13]. Por ltimo, tambin las grandes compaas de cuando aparezcan nuevas versiones o cuando los componentes
software tradicional estn empaquetando sus productos como se actualizan para corregir errores. Por brevedad, en adelante
componentes (p.e., Sun, Microsoft, SAP, etc.). para referirnos a esta clase de usuarios usaremos el trmino
desarrollador de sistemas, aunque este trmino abarque en
B. Medicin del Software
nuestro caso a diseadores, evaluadores de componentes,
Al ms alto nivel, el objetivo principal de un proceso de constructores e integradores del sistema y mantenedores de un
medicin del software es satisfacer ciertas necesidades de sistema basado en componentes. Debemos recalcar que no
informacin mediante la identificacin de las entidades y de los hemos incluido ni a los usuarios finales del sistema basado en
atributos de estas entidades (los cuales sern el objeto del proceso componentes, ni a los desarrolladores de los propios
de medicin). Los atributos y las necesidades de informacin se componentes individuales. En nuestra opinin, ninguno de
relacionan a travs de los conceptos mensurables (los cuales ellos puede ser calificado como usuario de componente: los
pertenecen a un Modelo de Calidad). usuarios finales usan un sistema final, sin conocer (ni
En este trabajo nos vamos a concentrar en una necesidad de necesitarlo) si ha sido desarrollado utilizando componentes
informacin particular: la valoracin de la Usabilidad de un software u otra metodologa; anlogamente, los
conjunto de componentes software que son candidatos a ser desarrolladores de componentes fabrican componentes
integrados en un sistema software, con el objetivo de seleccionar individuales, pero no necesariamente usan componentes para
el mejor entre ellos. Como Modelo de Calidad hemos construirlos. ISO/IEC 9126 y COTS-QM definen la
seleccionado una adaptacin del modelo de calidad de ISO/IEC Usabilidad en trminos de cinco subcaractersticas que en el
9126. Como ese modelo de calidad es genrico para cualquier caso de los componentes, se pueden definir como sigue:
producto software, requiere cierta particularizacin para el caso Comprensibilidad: capacidad del componente para
concreto de los componentes software. El modelo permitir al desarrollador de sistemas comprender si el
particularizado, denominado COTS-QM, fue presentado en [4]. componente es adecuado, y cmo puede usarse en tareas
Las entidades de nuestro estudio sern los componentes y condiciones de uso particulares.
software, sin importar si estn desarrollados internamente o Aprendibilidad: capacidad del componente para permitir
adquiridos como componentes COTS. Los atributos se evalan al desarrollador de sistemas aprender su utilizacin. Una
utilizando medidas. Una medida relaciona una forma de medir y medida de Aprendibilidad debe ser capaz de valorar el
una escala de medicin. Una forma de medir es la secuencia esfuerzo que necesitarn los desarrolladores de sistemas
lgica de operaciones, descrita de forma general, usada para para aprender como se usan las funciones particulares
cuantificar un atributo con respecto a una escala especificada (interfaces, operaciones, etc.) o valorar la eficacia de la
[14]. documentacin suministrada.
Se pueden distinguir tres clase de medidas: medidas base,
Operabilidad: capacidad del componente para permitir al
medidas derivadas e indicadores. Las medidas base no dependen
desarrollador de sistemas operar con l y controlarlo.
de ninguna otra medida (p.e., el nmero de figuras en el manual).
Atraccin: capacidad del componente para resultar
Una medida derivada se obtiene de otras medidas base o
atractivo a los usuarios. Como los usuarios considerados
derivadas (p.e., la ratio de mtodos por interfaz). Un indicador es
no son usuarios finales del sistema, esta subcaracterstica
una medida que se obtiene a partir de otras medidas usando un
no parece ser relevante en este contexto.
modelo de anlisis (basado en unos criterios de decisin) para
Conformidad de Usabilidad: capacidad de un
obtener un resultado de la medicin que satisfaga una necesidad
componente para adherirse a estndares, convenciones,
de informacin.
guas de estilo o regulaciones relacionadas con la
Usabilidad. Actualmente no conocemos ningn estndar
III. USABILIDAD EN EL DSBC
que afecte a la Usabilidad de los componentes y, por
Como mencionbamos en la introduccin, en este trabajo tanto, no vamos a considerar esta subcaracterstica.
nos vamos a centrar en la Usabilidad y adoptaremos la
definicin de ISO/IEC 9126, adaptndola al caso particular de En resumen, la Usabilidad de un componente Software ser
los componentes software, de acuerdo a COTSQM [4]. As, valorada en trminos de su Comprensibilidad, Aprendibilidad
definimos Usabilidad como la capacidad de un componente y Operabilidad.
software para ser entendido, aprendido, usado y atractivo para
los usuarios, cuando se usa bajo condiciones concretas.
Desde nuestro punto de vista, los usuarios de componentes
138 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006

IV. MEDIDAS DE USABILIDAD interrogar los componentes y obtener informacin sobre sus
Al buscar en la literatura medidas relacionadas con el elementos funcionales (interfaces, operaciones, parmetros
DSBC, hemos descubierto que la relacin entre las medidas y configurable, etc.). Anlogamente, podemos utilizar el hecho
las caractersticas de calidad que tratan de evaluar no est bien de que la documentacin suele estar en formato electrnico en
definida. Esto es un problema habitual en la mayora de las la mayora de los componentes y, por tanto, la podremos
propuestas y estndares internacionales que definen medidas analizar detalladamente. As, de nuestro conjunto de medidas
para componentes software. iniciales, nicamente las que se pueden obtener de forma
Nuestro objetivo en este trabajo es resolver este problema, objetiva y reproducible aparecen en la columna izquierda de
intentando definir adecuadamente un conjunto de medidas los Cuadros 4 y 5. En total hemos trabajado y evaluado 19
basadas en los atributos que evalan, y determinando de qu medidas base y 21 medidas derivadas.
forma estas medidas valoran las caractersticas de calidad de
un componente software, de acuerdo a un modelo de calidad. V. VALIDACIN DE LAS MEDIDAS
Adems, vamos a exigir algunos requisitos a las medidas
A. Validacin Emprica
usadas para que sean prcticas en un entorno industrial:
primero, que sean objetivas y reproducibles; segundo, que El objetivo de la validacin es demostrar que una medida
sean fciles de calcular (mejor an si se pueden calcular de proporciona realmente una informacin til para evaluar una
forma automtica); y, por ltimo, que permitan identificar un caracterstica de calidad. Con objeto de validar empricamente
conjunto mnimo de medidas que proporcionen la mxima nuestras medidas hemos realizado una familia de
experimentos. Estos experimentos nos proporcionaron algunos
cantidad de informacin sobre los conceptos mensurables que
datos (valores numricos) sobre la Comprensibilidad,
estamos intentando evaluar (i.e, optimizar el nmero de
Aprendibilidad y Operabilidad de un conjunto de
medidas representativas).
componentes:
Como ya hemos mencionado, de los tres conceptos
como percibida por un conjunto de usuarios conforme
mensurables relacionados con la Usabilidad de los
a las definiciones de Comprensibilidad, Aprendibilidad
componentes software (Calidad de la Documentacin,
y Operabilidad, que les fueron dadas;
Complejidad de la Solucin y Complejidad del Problema), como percibida por un conjunto de usuarios cuando se
solo vamos a considerar los dos primeros, puesto que al les pregunta indirectamente sobre la
comparar componentes que proporcionan una misma o muy Comprensibilidad, Aprendibilidad y Operabilidad de
parecida funcionalidad, la Complejidad del Problema ser los componentes que han analizado;
similar en todos ellos. Estos conceptos mensurables y sus objetivamente, como el resultado de un cuestionario
atributos relacionados se muestran en el Cuadro 1. La forma que peda a los sujetos que realizaran una serie de
en la cual los conceptos mensurables influyen en la Usabilidad tareas con los componentes, para posteriormente
de un componente y en las subcaractersticas que la componen valorar las respuestas de acuerdo a la correccin y al
se trata posteriormente en la seccin 5. tiempo necesario para contestar las preguntas.
Generalmente, cada atributo puede tener una o ms Entre Junio y Diciembre de 2004 se realizaron cinco
medidas (indicadores, medidas derivadas o medidas base) que experimentos. La idea era simular el proceso de seleccin de
lo evalen. Un resumen de las medidas propuestas para los un componente software de entre un conjunto de potenciales
atributos de la Calidad de la Documentacin se muestra en el candidatos. Se seleccionaron 12 componentes de un dominio
Cuadro 2, y las medidas propuestas para los atributos de aplicacin (Print and Preview). Todos los componentes
relacionados con la Complejidad del Diseo en el Cuadro 3. eran productos COTS disponibles en vendedores comerciales,
En ambas tablas, debera existir una ltima columna con las y anunciados en repositorios de componentes como
medidas base a partir de las cuales se calculan las medidas ComponentSource. Estos componentes usaban diferentes
derivadas. Esta columna se ha omitido por razones de espacio modelos y tecnologas de componentes: Java, ActiveX y
y porque la mayora de las medidas base son evidentes. En .NET.
total se han definido 34 medidas derivadas y 35 medidas base. El primer experimento se enfoc ms hacia la valoracin
Sin embargo, proponer un conjunto de medidas, que es subjetiva de de la Usabilidad percibida de los componentes,
justo lo que actualmente aparece en la mayora de las con el objetivo de obtener los primeros datos sobre la Calidad
propuestas e incluso de los estndares [4, 5, 6, 7, 8, 9], no nos de la Documentacin y la Complejidad de la Solucin de cada
parece suficiente. En primer lugar, no todas las medidas uno de ellos. Bsicamente, los sujetos tenan que asignar un
propuestas en los Cuadros 2 y 3 son fciles de calcular. Por valor dentro de una escala semntica de siete valores
ejemplo, la medida Porcentaje de elementos funcionales (posteriormente estos valores se convertan en un entero entre
correctamente usados tras leer el manual es muy difcil de (-3 y +3) a un conjunto de preguntas segn su valoracin
calcular. Estas medidas se muestran en itlica en estas tablas. subjetiva. Los dos ltimos experimentos se enfocaron hacia
las cuestiones objetivas (aunque se mantuvieron unas pocas
Por contra, otras medidas que son difciles de computar en
preguntas de valoracin subjetiva) sobre si el componente
productos software generales se pueden obtener fcilmente, y
ofreca determinados servicios o no, y sobre cmo se
hasta automatizar, en el caso de los componentes software:
implementaban esas funcionalidades con cierto detalle.
usando tcnicas de reflexin computacional se puede
BERTOA AND VALLECILLO : USABILITY MEASURES FOR SOFTWARE 139
140 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006
BERTOA AND VALLECILLO : USABILITY MEASURES FOR SOFTWARE 141

largas ni deben contener excesiva informacin.


La evaluacin de estas cuestiones objetivas se realiz teniendo Muy pocas medidas base son representativas.
en cuenta el tiempo que se tardaba en encontrar la respuesta y Bsicamente, el tamao del manual (medido en numero
en la correccin de la propia respuesta. Un valor numrico de palabras o de archivos) tiene alguna influencia sobre
entre -3 y +3 se le asignaba a cada una de las respuestas. la Usabilidad (R2 = 0;92). Por otra parte, el nmero de
Un total de 68 sujetos participaron en los experimentos de Valores de Retorno influye sobre la Comprensibilidad
valoracin de la Usabilidad de la muestra de componentes. El (R = -0;95;R2 = 0;90), lo cual parece indicar que tener
nmero de sujetos en cada experimento vari entre 9 y 18 muchos mtodos que no devuelven ningn valor
personas. produce componentes ms difciles de comprender.
Con un menor grado de influencia, el nmero de
interfaces y de argumentos de los mtodos influyen en
B. Resultado (directo) de los experimentos
la Usabilidad directamente percibida (mejor cuanto
El resultado de estos experimentos se resume en seis variables menos clases y argumentos) y que la ratio de
(cuyos valores estn en el rango -3 a +3) para los componentes argumentos por mtodo tiene un impacto negativo
muestreados: Usabilidad Percibida Directa (Usab_D), Usabilidad sobre la Usabilidad percibida indirectamente.
Percibida Indirecta (Usab_I), Comprensibilidad Objetiva
(Comp_O), Aprendibilidad Objetiva (Apren_O), Operabilidad Tambin aparecen algunos resultados inesperados:
Objetiva (Oper_O) y Usabilidad Objetiva (Usab_O). Las dos Por ejemplo, el nmero de figuras y tablas en el manual
primeras corresponden a la Usabilidad percibida, medida directa no parece tener una influencia directa sobre la
e indirectamente; las siguientes tres se obtienen como resultado Usabilidad percibida de los componentes. Esto sugiere
de la valoracin de las preguntas objetivas en los ltimos que los usuarios (tcnicos) no aprecian los dibujos y
experimentos; y la Usabilidad Objetiva es el promedio de las tablas en los manuales cuando evalan subjetivamente
otras tres variables objetivas. la Usabilidad (aunque este medida s es influyente en la
Hemos encontrado una correlacin (aunque no evaluacin objetiva de la Comprensibilidad, como
estadsticamente relevante) entre la Usabilidad percibida y la veremos ms adelante).
objetiva. Curiosamente, hemos visto que los valores de la Originalmente, los autores pensamos que la
usabilidad son similares para valores altos ( 1,3) pero difieren completitud de los manuales iba a tener una importante
ms cuanto peor es la Usabilidad percibida. influencia en la Usabilidad. Sin embargo, el porcentaje
Una vez cuantificada la informacin sobre la Usabilidad de de clases, mtodos y EF que aparecen descritos en los
los componentes muestreados, el siguiente paso es medir los manuales no parece tener una fuerte influencia sobre
componentes usando las medidas definidas y buscar ninguno de los valores de la Usabilidad (an cuando
correlaciones entre los resultados de la medicin obtenidos y los alguno de los manuales solo describen el 50% de las
datos de Usabilidad de los cuestionarios. Una fuerte correlacin clases y mtodos pblicos del componente.)
(p.e., R > 0; 97) significara que esa medida explica bien los Por ltimo, pensbamos que la longitud de los nombres
datos de Usabilidad y, por tanto, demostrara que esa medida es de las clases, mtodos, campos, etc., podra influir en la
representativa y vlida para medir la correspondiente Aprendibilidad y la Comprensibilidad del componente.
subcaracterstica. Sin embargo, estas impresiones no han sido
Los Cuadros 4 y 5 muestran, respectivamente, las matrices de corroboradas por los datos obtenidos.
correlacin obtenidas para nuestras medidas base y derivadas.
Observndolos podemos sacar algunas conclusiones Una de las conclusiones ms interesantes que se puede
interesantes:. sacar de las tablas de correlaciones es que no hay una medida
El nmero de palabras por interfaz (anlogamente, el individual que proporcione una explicacin realmente buena
nmero de palabras por elemento funcional (EF) o por (R2 1) de la Comprensibilidad, Aprendibilidad u
mtodo) explica bien la Usabilidad del componente (R2 Operabilidad de un componente, ni tampoco de la Usabilidad
= 0,95). Este resultado es consistente con la idea globalmente. Slo hay una medida que por s misma explica
intuitiva que la Usabilidad de un componente es mejor mas de un 95% de una caracterstica de calidad (la ratio de
si su manual contiene abundante informacin sobre sus palabras por clase, con R = 0,97; R2 = 0,95). El resto de las
interfaces, operaciones y otros EF. medidas estn por debajo de esos valores.
La Comprensibilidad (Comp_O) se puede explicar
adecuadamente (R2 = 0,90) mediante el nmero de C. Anlisis de Regresin Lineal
ficheros HTML por EF del manual. Bsicamente, esto En este punto debemos recordar lo expuesto en la
significa que la estructura, organizacin y introduccin del trabajo como un defecto comn en la mayora
navegabilidad de la pginas electrnicas del manual de las propuestas de medicin software: las medidas definidas
(cada pgina se almacena como un fichero HTML) por la mayora de los autores y estndares internacionales
influyen directamente sobre la Comprensibilidad que el aparecen generalmente asignadas a una nica subcaracterstica de
usuario tiene del componente. En concreto, para calidad, aunque en teora podran evaluar ms de una
mejorar la Comprensibilidad del componente, las caracterstica. De hecho, no creemos que exista una nica
pginas electrnicas (pantallas) no deben ser muy relacin directa entre una medida y una subcaracterstica, si no
142 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 2, APRIL 2006

que hay diferentes grados de relacin entre cada medida y cada Ntese tambin que estos resultados son totalmente
subcaracterstica. consistentes con las definiciones de las tres subcaractersticas
de Usabilidad y, adems, tienen sentido segn nuestras

Cuadro 6. Explicacin de las subcaractersticas por parte de las medidas.

Partiendo de esa premisa y usando los datos obtenidos en intuiciones. Por ejemplo, la controlabilidad de un componente
nuestros experimentos y las medidas observadas en los y su adecuacin para ser particularizado fueron dos de los
componentes, hemos utilizado un anlisis de regresin lineal requisitos de la Operabilidad (Seccin 3). Para un componente
para buscar combinaciones de medidas que suministren software, normalmente esto se consigue mediante los
mejores explicaciones de las tres subcaracterstica. Nuestros parmetros configurables. Precisamente, lo que hemos
resultados son buenos: todas las subcaractersticas de encontrado es que la Ratio de de parmetros configurables por
Usabilidad pueden ser explicadas correctamente mediante la mtodo tiene una fuerte influencia sobre esta subcaracterstica
combinaciones lineales de dos medidas, obtenindose valores (cuando se combina con la densidad de valores de retorno).
para R2 cercanos al 0,99.
Estas combinaciones se muestran en el Cuadro 6 y, entre
otras cosas, proporciona una informacin muy interesante VI. CONCLUSIONES
sobre la existencia de relaciones entre los atributos de los
Este trabajo ha presentado un conjunto de medidas base y
componentes y el Modelo de Calidad, es decir, la conexin
derivadas que se pueden utilizar para evaluar la Usabilidad de
entre la Calidad de la Documentacin y la Complejidad del
los componentes software. Adems, se ha mostrado cmo
Diseo por un lado y, por el otro, la Comprensibilidad,
validar estas medidas, calculando cmo influyen
Aprendibilidad y Operabilidad de un componente software:
individualmente sobre las subcaractersticas de la Usabilidad y
La Comprensibilidad tiene una fuerte dependencia
cules son las combinaciones de medidas ms representativas
tanto de la Ratio de ficheros HTML por EF como del
para evaluara estas subcaractersticas.
Porcentaje de mtodos sin argumentos. Esto significa
Se ha visto como la combinacin apropiada de medidas
que tanto la Calidad de los Manuales como la
puede evaluar mejor la Usabilidad de un componente que
Complejidad del Diseo influyen en la
cualquier medida individual. Bsicamente, esto ocurre porque
Comprensibilidad del componente.
las caractersticas de calidad no dependen de un concepto
La Aprendibilidad depende tanto de la Ratio de
mensurable determinado, sino de una combinacin de ellos.
palabras por Interfaz (o palabras por clase, en el caso
Nuestro planes son ahora realizar ms experimentos con
de componentes Java) como del Porcentaje de mtodos
ms componentes (p.e., con otros dominios de aplicacin) y
sin valores de retorno. Ambas, la Calidad de los
en el entorno de la industria, con el objeto de recopilar ms
Manuales y la Complejidad del Diseo influyen en esta
datos que nos ayuden a corroborar nuestros resultados y a
subcaracterstica.
refinar nuestras ecuaciones. Basndonos en estas ecuaciones,
Finalmente, la Operabilidad depende de la Ratio de
tenemos pensado trabajar en modelos de anlisis que nos
parmetros configurables por mtodo (o campos por
puedan ayudar a definir los indicadores de calidad apropiados
clase, en el caso de componentes Java) y del
para la Usabilidad. Finalmente, estamos integrando las
Porcentaje de mtodos sin valores de retorno. En este
herramientas que hemos desarrollado para automatizar las
caso, ambas medidas estn relacionadas con la
medidas de los componentes (es decir, los programas que
Complejidad del Diseo (y por tanto el concepto
analizan los manuales y los programas que interrogan los
mensurable aparentemente con ms influencia sobre la
componentes usando reflexin) de tal forma que en corto
Operabilidad).
plazo podamos ofrecer un servicio de evaluacin de
Es destacable que algunas ecuaciones del Cuadro 6 no
componentes para la industria software que ayude en la
contienen medidas que sean muy relevantes por s solas. Esto
seleccin de los componentes que se adecan mejor a sus
significa que una combinacin de medidas menos
aplicaciones con un esfuerzo menor y con mayor precisin.
representativas puede llegar a ser ms representativa que las
propias medidas individuales y que cualquier otra medida
individual.
BERTOA AND VALLECILLO : USABILITY MEASURES FOR SOFTWARE 143

REFERENCIAS

[1] ISO/IEC 14598:2001. Software Engineering Product Evaluation. June


2001.
[2] ISO/IEC 9126-1:2001. Software Engineering Product Quality Part
1:Quality model. June 2001.
[3] ISO/IEC FDIS 25000:2005. Software Engineering Software Product
Quality Requirements and Evaluation (SQuaRE) Guide to SQuaRE.
Jan 2005.
[4] Manuel F. Bertoa and Antonio Vallecillo. Quality attributes for COTS
components. I+D Computacin, 1(2):128144, Nov 2002.
[5] Pere Botella, Xavi Burgus, et al. Using quality models for assessing
COTS selection. In Proc. of WER02, pp. 263277, Nov 2002.
[6] Allan W. Brown and Kurt Wallnau. The current state of CBSE. IEEE
Software, 15(5):3746, Sep-Oct 1999.
[7] S. Sedigh Ali, A. Ghafoor y R.A. Paul. Software engineering metrics
for COTS based systems. IEEE Computer, 34(5):4450, 2001.
[8] R. Simao and A. Belchior. Quality characteristics for software
components: Hierarchy and quality guides. In Component-Based
Software Quality: Methods and Techniques, LNCS 2963, pp. 188211,
2003.
[9] H. Washizaki, H. Yamamoto y Y. Fukazawa. A metrics suite for
measuring reusability of software components. In Proc. of METRICS
03, pp. 221225, Sep 2003.
[10] M. F. Bertoa, J. M. Troya y A. Vallecillo. A survey on the quality
information provided by software component vendors. In Proc. of
QAOOSE 2003, pp. 2530, July 2003.
[11] C. Szyperski. Component Software. Beyond Object-Oriented
Programming. Addison-Wesley, 2 ed, 2002.
[12] L.E. Sweeney, E.V. Kortright y R.J. Buckley. Developing an RM-ODP
based architecture for the defense integrated military human resources
system. In Proc. of WOODPECKER 01, pp. 110124, July 2001.
[13] V. Seppanen and N. Helander. Original software component
manufacturing: Survey of the state of the practice. In Proc. of the 27th
Euromicro Conference, pp. 138145, Sep 2001. IEEE CS Press.
[14] ISO/IEC 15939:2002. Software engineering Software measurement
process. Jan 2002.
[15] Barry Boehm, J. R. Brown, J.R. Kaspar, et al. Characteristics of
Software Quality. North Holland, 1978.

BIOGRAFAS

Manuel F. Bertoa es Profesor Colaborador del


Departamento de Lenguajes y Ciencias de la
Computacin de la Universidad de Mlaga, Espaa. Su
investigacin se centra en el Desarrollo de software
basado en componentes y en la Medicin del software.
Es Ingeniero de Telecomunicacin por la Universidad Politcnica de Madrid.

Antonio Vallecillo es Profesor Titular de Universidad


del Departamento de Lenguajes y Ciencias de la
Computacin de la Universidad de Mlaga, Espaa. Sus
principales reas de investigacin se centran en el
desarrollo de software dirigido por modelos, Software
basado en Componente, Procesamiento distribuido
abierto, y el uso industrial de los mtodos formales. Obtuvo su ttulo de
Licenciado en Matemticas y de Doctor en Informtica en la Universidad de
Mlaga. Es el representante de la Universidad de Mlaga en ISO y en OMG,
asimismo, es miembro de ACM, IEEE e IEEE Computer Society.