Calidad de Componentes Software

Presentación del tema: "Calidad de Componentes Software"— Transcripción de la presentación:

1 Calidad de Componentes Software
Manuel F. Bertoa y Antonio Vallecillo Departamento de Lenguajes y Ciencias de la Computación Universidad de Málaga

2 Calidad de Componentes Software
Agenda Conceptos sobre Componentes Software y Componentes COTS Desarrollo Software Basado en Componentes Selección de Componentes Modelos de Calidad ISO 9126 Modelo Calidad para componentes Métricas de Usabilidad Calidad de Componentes Software

3 Conceptos sobre Componentes Software

4 Calidad de Componentes Software
Componente Software “Una unidad de composición de aplicaciones software que posee un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes, de forma independiente en tiempo y espacio” [Szyperski, 1998] Calidad de Componentes Software

5 Calidad de Componentes Software
Componentes COTS Commercial Off-The-Shelf Clase especial de componentes software, normalmente de grano grueso que presentan las siguientes características Vendidos o licenciados al público en general Su código no puede ser modificado por el usuario No hay control sobre su evolución: los mantiene y actualiza el propio vendedor, quien conserva los derechos de la propiedad intelectual Están disponibles en forma de múltiples copias, todas idénticas entre sí [Bass et al., 1999] Calidad de Componentes Software

6 Desarrollo de Software Basado en Componentes (DSBC)

7 Calidad de Componentes Software
DSBC Diseño y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables Una extensión natural de la programación orienta a objetos dentro del ámbito de los sistemas abiertos y distribuidos Tecnológicamente comienza a estar maduro y usarse en la industria. ¡Hace falta medir ahora su calidad! Calidad de Componentes Software

8 Desarrollo (simplificado) Basado en COTS
Calidad de Componentes Software

9 Calidad de Componentes Software
Ciclo de Vida DSBC Gestión del Proyecto Requisitos Especificación Aprovisionamiento (Provisioning) Integración (Assembly) Prueba Despliegue (Deployment) Operación Mantenimiento Calidad de Componentes Software

10 Mercado de Componentes COTS

11 Calidad de Componentes Software
Calidad de Componentes Software

12 Calidad de Componentes Software
Calidad de Componentes Software

13 Calidad de Componentes Software
Calidad de Componentes Software

14 Calidad de Componentes Software
Calidad de Componentes Software

15 Calidad de Componentes Software
Calidad de Componentes Software

16 Calidad de Componentes Software
Calidad de Componentes Software

17 Selección de Componentes
¿Comprar o Construir?

18 La Fase de Aprovisionamiento
Usa el resultado de la fase de especificación para determinar que componentes se deben Construir desde cero Comprar a terceros Modificar (componentes o módulos existentes) Debemos tener la capacidad de valorar distintos componentes software que ofrezcan una funcionalidad similar Debemos tener la capacidad de seleccionar el mejor entre ellos, si existe Calidad de Componentes Software

19 La Fase de Aprovisionamiento
¿Cuál elegir? Calidad de Componentes Software

20 Selección de Componentes
Necesitamos poder saber valorar objetivamente un componente, es decir, “Medir su Calidad” ¿Qué es la calidad de un componente? ¿Cómo se mide eso? ¿Existe algún estándar inter- nacional que sirva de referencia? Calidad de Componentes Software

21 Modelo de Calidad ISO 9126

22 Calidad de Componentes Software
Modelo de Calidad Un Modelo de calidad es el conjunto de características y sub-características, y de cómo se relacionan entre sí. Depende del tipo de producto a evaluar Modelo de Calidad ISO-9126 Calidad de Componentes Software

23 Modelo de Calidad ISO/IEC 9126-1
Características Subcaracterísticas Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad Adecuación Corrección Interoperabilidad Seguridad Conformidad Madurez Tolerancia a Fallos Recuperabilidad Aprendibilidad Comprensibilidad Operabilidad Atractividad Comportamiento Temporal Utilización de Recursos Este es el modelo para la versión del 2001 Analizabilidad Cambiabilidad Estabilidad Facilidad de Prueba Adaptabilidad Instalabilidad Coexistencia Reemplazabilidad Calidad de Componentes Software

24 Modelo de Calidad para Componentes Software
ISO 9126 es un Modelo genérico Es necesario adaptarlo (en nuestro caso, para componentes software): Determinar qué subcaracterísticas son relevantes, y cuáles hay que particularizar Definir métricas específicas para los componentes software Definir indicadores para las características de calidad Calidad de Componentes Software

25 Modelo de Calidad para Componentes COTS: COTS-QM
Subcaracterísticas Características Recuperabilidad Adecuación Seguridad Interoperatividad Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad Madurez Tolerancia a Fallos Utilización de Recursos Comportamiento Temporal Reemplazabilidad Adaptabilidad Facilidad Instalación Idoneidad Corrección Conformidad Operatividad Facilidad de aprendizaje Facilidad de comprensión Analizabilidad Cambiabilidad Estabilidad Facilidad de Prueba Desaparecen Este es el modelo para la versión del 2001 Calidad de Componentes Software

26 Modelo de Calidad para Componentes COTS: COTS-QM
Cambian su sentido Características Subcaracterísticas Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Idoneidad Corrección Interoperatividad Seguridad Conformidad Madurez Recuperabilidad Operatividad Facilidad de aprendizaje Facilidad de comprensión Operatividad Facilidad de aprendizaje Facilidad de comprensión Utilización de Recursos Comportamiento Temporal Este es el modelo para la versión del 2001 Cambiabilidad Facilidad de Prueba Calidad de Componentes Software

27 Métricas para COTS y el proceso de medición de componentes software

28 Conceptos del “Proceso de Medición”
Trata de satisfacer unas necesidades de información sobre ciertas entidades que poseen atributos que se miden con métricas Los conceptos medibles relacionan los atributos con las necesidades de informacion Una métrica es un metodo de medición, y una escala de medición Métricas directas, indirectas, e indicadores Calidad de Componentes Software

29 Calidad de Componentes Software
Medir un componente ¿Cuál es la información disponible de un componente software? Basar las métricas en esta información disponible Definir relaciones entre las métricas y las características de calidad [¿?] Calidad de Componentes Software

30 Componentes: Información Disponible
In order to assess the Usability of a software component, we need to define: a set of measurable concepts that influence any of the quality sub-characteristics of Usability; the component attributes that can be measured in order to assess such measurable concepts and how they affect each sub-characteristic; and finally, the metrics that measure such attributes. Metrics can be direct metrics, indirect metrics, or indicators. Before we define any of those items, and in particular metrics, we need to know the kind of information that is available about the entities we plan to assess (the software components). This information will be the only measurable elements based on which metrics can be defined. The following UML class diagram shows the information that we think is relevant to the Usability of a component, from all the information that is available for a commercial component. The fact that components are black box and binary units of composition, whose internals cannot be viewed or accessed, only leaves us with the externally observable elements of the component that allow to assess its quality. In the case of Usability, we have considered the component documentation and some of its functional elements. In the following, and according to the diagram 1, the term documentation will refer to component manuals, demos, help system, and marketing information. By functional elements we will refer to the interfaces, operations, or events that a component may support or require from other components to achieve its functionality, i.e., to implement its services. Although some metrics may be defined on individual elements (e.g., number of operations per interface), sometimes it is simpler to refer to the functional elements independently of their granularity. Of course, not all this information is available for all commercial components, as we discovered in our survey [2]. However, we have tried to be realistic when defining the elements above, looking for a balance between the demand of information required by the metrics, and the difficulty we know that software component vendors have for providing that information. From our point of view and previous experience, we think that the information we require (described above) seems to be reasonable. Calidad de Componentes Software

31 La Usabilidad en DSBC

32 Calidad de Componentes Software
La Usabilidad en DSBC ISO 9126 La capacidad del componente para ser entendido, comprendido, usado y atractivo para el usuario cuando se usa bajo unas determinadas condiciones The capability of the component to be understood, learned, used and attractive to the user, when used under specified conditions Calidad de Componentes Software

33 Calidad de Componentes Software
La Usabilidad en DSBC Depende del tipo de "uso" que se espera y tipo de "usuario" que utilizará el producto ¿Usuarios de los componentes software? Desarrollador del componente Evaluador/Seleccionador Integrador (system builder) Configurador/Administrador del sistema Usuario del sistema Mantenimiento In fact, Usability is a quality characteristic that is intrinsically dependent upon the kind if “use” that is expected, and the kind of “user” that will use the product We need to clarify the users and the kind of usage of the software components whose Usability we try to assess. From our perspective, component users will be the members of the software team that develops and maintains a component-based system—but not the end-users of such a system, nor the developers of the individual components themselves. Component users need to identify, locate and select them according to the system architectural constraints and the system owners requirements, integrate them to build the system, and then proceed to the system maintenance when new versions appear, or components are upgraded to fix problems. (For brevity, in the following we will simply refer to such kinds of users as “developers”, although this term embraces in our case component-based system developers and maintainers, component evaluators, and system integrators. Basic component developers and system end-users will not be considered.) Calidad de Componentes Software

34 La Usabilidad según ISO 9126
ISO 9126 define la Usabilidad en términos de cinco sub-características Comprensión (Understandability) Aprendibilidad (Learnability) Operabilidad (Operability) Atractividad (Attractiveness) Conformidad de Usabilidad (Usability compliance) ─       Understandability: the capability of the component to enable the user (developer) to understand whether the component is suitable, and how it can be used for particular tasks and conditions of use. Developers should be able to select a component suitable for their intended use. For example, components elements (e.g. interfaces, operations) should be easy to understand or evident. ─       Learnability: the capability of the software component to enable the user (developer) to learn the application. A learnability metric should be able to assess how long it takes developers to learn how to use particular functions (interfaces, operations, …), or the effectiveness of documentation (manuals, help system, demos). For example, the user documentation and the help system should be complete, the help should be context sensitive and explain how to achieve common tasks, etc. ─       Operability: the capability of the software component to enable the user (developer) to operate and control it. An operability metric should be able to assess whether developers can operate and control the component. Operability metrics can be categorised by the dialogue principles in ISO : o       suitability of the component for the task; o       self-descriptiveness of the component; o       controllability of the component; o       conformity of the component with user expectations (requirements); o       error tolerance of the component; o       suitability of the component for individualisation. ─       Attractiveness: the capability of the software component to be attractive to the user. Since the users we consider are not end-users, this subcharacteristic is of no interest in our case. ─       Usability compliance: the capability of the software component to adhere to standards, conventions, style guides or regulations relating to usability. Currently, we don’t know of any standards or regulations for component usability. Thus, we will not define any metric for this sub-characteristic. Calidad de Componentes Software

35 La Usabilidad según ISO 9126
ISO 9126 define la Usabilidad en términos de cinco sub-características Comprensión (Understandability) Aprendibilidad (Learnability) Operabilidad (Operability) Atractividad (Attractiveness) Conformidad de Usabilidad (Usability compliance) ─       Understandability: the capability of the component to enable the user (developer) to understand whether the component is suitable, and how it can be used for particular tasks and conditions of use. Developers should be able to select a component suitable for their intended use. For example, components elements (e.g. interfaces, operations) should be easy to understand or evident. ─       Learnability: the capability of the software component to enable the user (developer) to learn the application. A learnability metric should be able to assess how long it takes developers to learn how to use particular functions (interfaces, operations, …), or the effectiveness of documentation (manuals, help system, demos). For example, the user documentation and the help system should be complete, the help should be context sensitive and explain how to achieve common tasks, etc. ─       Operability: the capability of the software component to enable the user (developer) to operate and control it. An operability metric should be able to assess whether developers can operate and control the component. Operability metrics can be categorised by the dialogue principles in ISO : o       suitability of the component for the task; o       self-descriptiveness of the component; o       controllability of the component; o       conformity of the component with user expectations (requirements); o       error tolerance of the component; o       suitability of the component for individualisation. ─       Attractiveness: the capability of the software component to be attractive to the user. Since the users we consider are not end-users, this subcharacteristic is of no interest in our case. ─       Usability compliance: the capability of the software component to adhere to standards, conventions, style guides or regulations relating to usability. Currently, we don’t know of any standards or regulations for component usability. Thus, we will not define any metric for this sub-characteristic. Calidad de Componentes Software

36 Proceso de medición de la Usabilidad de Componentes Software

37 Métricas de Usabilidad
Necesidad de Información: Evaluar la usabilidad de un conjunto de componentes software que son candidatos a ser integrados en un sistema software para seleccionar el mejor de ellos El desarrollador del sistema desea seleccionar el componente más fácil de usar (integrar) dentro de un conjunto de componentes que ofrecen una funcionalidad similar y que cumplan los requisitos solicitados For example, all metrics defined the ISO 9126 series are related to just one quality characteristic, which is not the usual case—an attribute normally influences more than one sub-characteristic Calidad de Componentes Software

38 Métricas de Usabilidad
Tres conceptos medibles relacionados con la usabilidad Calidad de la Documentación Complejidad del Problema Complejidad de la Solución (del Diseño) (Al comparar componentes que ofrecen una funcionalidad similar, podemos suponer que todos tienen la "misma complejidad del problema“) Complejidad del Problema Accordingly, there is no need to propose metrics to assess this complexity, and we will focus on the other two measurable concepts. These concepts and their related attributes are presented in Table 2. Calidad de Componentes Software

39 Atributos de Usabilidad
Entity Information Need Measurable Concept Attribute Software Component Evaluate the Usability Quality of Documentation Manuals Contents of manuals Size of Manuals Effectiveness of Manuals Demos Contents of Demos Help System Contents of Help System Size of Help System Effectiveness of Help System Marketing Info Contents of Marketing Info Effectiveness of Marketing Info Complexity of the Design Design Legibility (Readability) Interfaces Understandability I/O Understandability Ease of Learning Customisability Quality of error messages Interfaces Complexity Since each attribute may have one or more metrics (indicators, indirect or direct metrics) that evaluate it, we need to define these metrics. The following tables show the metrics proposed to measure the measurable concepts defined in Table 2. A summary of metrics for quality of the documentation attributes appears in Table 3, and those related to the complexity of design in Table 4. We use the term “functional element” to refer interfaces, operations and events as a whole. Calidad de Componentes Software

40 Atributos de Usabilidad
Entity Information Need Measurable Concept Attribute Software Component Evaluate the Usability Quality of Documentation Manuals Contents of manuals Size of Manuals Effectiveness of Manuals Demos Contents of Demos Help System Contents of Help System Size of Help System Effectiveness of Help System Marketing Info Contents of Marketing Info Effectiveness of Marketing Info Complexity of the Design Design Legibility (Readability) Interfaces Understandability I/O Understandability Ease of Learning Customisability Quality of error messages Interfaces Complexity Since each attribute may have one or more metrics (indicators, indirect or direct metrics) that evaluate it, we need to define these metrics. The following tables show the metrics proposed to measure the measurable concepts defined in Table 2. A summary of metrics for quality of the documentation attributes appears in Table 3, and those related to the complexity of design in Table 4. We use the term “functional element” to refer interfaces, operations and events as a whole. Calidad de Componentes Software

41 Atributos de Usabilidad
Entity Information Need Measurable Concept Attribute Software Component Evaluate the Usability Quality of Documentation Manuals Contents of manuals Size of Manuals Effectiveness of Manuals Demos Contents of Demos Help System Contents of Help System Size of Help System Effectiveness of Help System Marketing Info Contents of Marketing Info Effectiveness of Marketing Info Complexity of the Design Design Legibility (Readability) Interfaces Understandability I/O Understandability Ease of Learning Customisability Quality of error messages Interfaces Complexity Since each attribute may have one or more metrics (indicators, indirect or direct metrics) that evaluate it, we need to define these metrics. The following tables show the metrics proposed to measure the measurable concepts defined in Table 2. A summary of metrics for quality of the documentation attributes appears in Table 3, and those related to the complexity of design in Table 4. We use the term “functional element” to refer interfaces, operations and events as a whole. Calidad de Componentes Software

42 Atributos de Usabilidad
Entity Information Need Measurable Concept Attribute Software Component Evaluate the Usability Quality of Documentation Manuals Contents of manuals Size of Manuals Effectiveness of Manuals Demos Contents of Demos Help System Contents of Help System Size of Help System Effectiveness of Help System Marketing Info Contents of Marketing Info Effectiveness of Marketing Info Complexity of the Design Design Legibility (Readability) Interfaces Understandability I/O Understandability Ease of Learning Customisability Quality of error messages Interfaces Complexity Since each attribute may have one or more metrics (indicators, indirect or direct metrics) that evaluate it, we need to define these metrics. The following tables show the metrics proposed to measure the measurable concepts defined in Table 2. A summary of metrics for quality of the documentation attributes appears in Table 3, and those related to the complexity of design in Table 4. We use the term “functional element” to refer interfaces, operations and events as a whole. Calidad de Componentes Software

43 Ejemplo: Calidad de los Manuales
Entity Information Need Measurable Concept Attribute Software Component Evaluate the Usability Quality of Documentation Manuals Contents of manuals Size of Manuals Effectiveness of Manuals Demos Contents of Demos Help System Contents of Help System Size of Help System Effectiveness of Help System Marketing Info Contents of Marketing Info Effectiveness of Marketing Info Complexity of the Design Design Legibility (Readability) Interfaces Understandability I/O Understandability Ease of Learning Customisability Quality of error messages Interfaces Complexity Attribute Contents of manuals Size of Manuals Effectiveness of Manuals Since each attribute may have one or more metrics (indicators, indirect or direct metrics) that evaluate it, we need to define these metrics. The following tables show the metrics proposed to measure the measurable concepts defined in Table 2. A summary of metrics for quality of the documentation attributes appears in Table 3, and those related to the complexity of design in Table 4. We use the term “functional element” to refer interfaces, operations and events as a whole. Calidad de Componentes Software

44 Métricas para la Calidad de los Manuales
Attribute Indicator Indirect Metric Contents of manuals Manuals Coverage Proportion of Functional Elements Described in Manuals Manuals Consistency Proportion of Functional Elements incorrectly Described in the Manual Completeness of Manuals Difference Between the Component Version and The Manual Version Manuals Legibility Ratio of Figures per Manual Pages Ratio of Tables per Manual Pages Ratio of UML Diagrams per Manual Pages Size of Manuals Manuals Suitability Average Pages per Functional Elements Effectiveness of Manuals Effectiveness Ratio Proportion of Functional Elements Correctly Used after Reading The Manual Understandability Ratio Proportion of Functional Elements Correctly Understood after Reading The Manual Calidad de Componentes Software

45 ¿Cómo se enlazan las subcaracterísticas con los atributos?
Understandability Learnability Operability Debemos relacionar la Calidad de la documentación, la Complejidad del Problema, y la Complejidad del Diseño con la Comprensibilidad, Aprendibilidad y la Operabilidad En general, no existe una relación directa entre conceptos medibles (y métricas) y subcaracterísticas de calidad, sino grados de relación o influencia entre ellas ¿? Quality of Documentation Complexity of Problem Complexity of Solution Calidad de Componentes Software

46 Un propuesta teórica inicial para ser demostrada mediante experimentos
Attribute Understandability Learnability Operability Contents of manuals low High medium Size of Manuals high Effectiveness of Manuals Contents of Demos Contents of Help System - Size of Help System Effectiveness of Help System Contents of Marketing Info Effectiveness of Marketing Info Design’s Legibility (Readability) Interfaces Understandability Understandability of I/O ease of component Learning Customisability Contents of error message Interfaces Density Finally, we present these relations for every attribute with each subcharacteristics to finish consistently our propose. Also, note that the Quality of Documentation affect mainly to understandability and Learnability. On the other hand, Complexity of Design affects to Operability. The degree (Low, Medium, High) of these relations is showed in Table 5. Calidad de Componentes Software

47 Calidad de Componentes Software
Conclusiones DSBC Tecnología de componentes bastante madura Mercado emergente de COTS Uso en la industria cada vez mayor Calidad para DSBC en pañales todavía Pocas métricas para componentes Pocas experiencias reales Conceptos y modelos de calidad no asentados todavía Necesidad de DSBC y Calidad (CBSQ) ¡Queda mucho trabajo por hacer! Calidad de Componentes Software

48 Calidad de Componentes Software
Gracias y Preguntas Preguntas: Antonio Vallecillo Calidad de Componentes Software

49 Apéndices y Ampliaciones
Si llegas aquí, es porque diste de más un clic

50 Ciclo de Vida DSBC: Gestión del Proyecto
Es el arte de equilibrar objetivos contrapuestos, gestionar riesgos y superar restricciones para entregar con éxito un producto software que satisfaga tanto las necesidades del cliente (el que paga la factura) como del usuario final. Controla todas las tareas de un proyecto de desarrollo software Determina tanto el nivel de calidad que debe alcanzar el sistema Como aspectos de costes de inversión, tiempos producción, etc. Calidad de Componentes Software

51 Ciclo de Vida DSBC: Requisitos
El objetivo de esta fase es describir que debe hacer el sistema Pero sin indicar como debe hacerlo Permitiendo a los desarrolladores y a los clientes estar de acuerdo con esa descripción Los analistas de sistemas deben obtener, organizar y documentar la funcionalidad y las restricciones requeridas Y seguir y documentar las decisiones y acuerdos Calidad de Componentes Software

52 Ciclo de Vida DSBC: Especificación
Se concentra en el diseño y análisis de la arquitectura software del sistema De acuerdo con los requisitos funcionales y extra-funcionales identificados Describe la funcionalidad del sistema "Como" funciona el sistema y "Como" alcanza los requisitos del sistema Calidad de Componentes Software

53 Ciclo de Vida DSBC: Especificación (2)
Utiliza como entrada los requisitos funcionales y extra-funcionales, la información sobre software existente (sistemas heredados, paquetes y bases de datos), y las restricciones técnicas (uso de un estilo arquitectónico o herramienta particular) Genera un conjunto de especificaciones de componentes incluyendo las especificaciones de las interfaces ofrecidas y requeridas y una arquitectura de componentes mostrando como interactúan los componentes entre ellos Calidad de Componentes Software

54 Ciclo de Vida DSBC: Aprovisionamiento
Usa el resultado de la fase de especificación para determinar que componentes se deben Construir desde cero Comprar a terceros O modificar componentes o módulos software existentes Además, en esta fase se debe realizar las pruebas unitarias de cada componentes antes de iniciar la fase de integración Calidad de Componentes Software

55 Ciclo de Vida DSBC: Integración
Se cogen todos los componentes y el software existente y se ponen juntos con una interfaz de usuario adecuada para crear una nueva aplicación Además, se deben realizar las pruebas de integración comprobar las incompatibilidades de protocolos y los desajustes semánticos habituales cuando se conectan piezas de software desarrolladas por diferentes compañías Calidad de Componentes Software

56 Ciclo de Vida DSBC: Prueba
Evaluar el sistema para confirmar que satisface los requisitos especificados Y para identificar y corregir defectos en la implementación Proposito: Verificar La interacción entre los objetos La integración apropiada de todos los componentes del software Todos los requisitos se han implementado correctamente Identificar y asegurar que los defectos se han resuelto antes de entregarlo Calidad de Componentes Software

57 Ciclo de Vida DSBC: Despliegue
Producir una versión del producto y entregar el software a sus usuarios finales Abarca un amplio rango de actividades: Producir versiones externas del software Empaquetar el software Distribuir y equilibrar la carga del software Instalar el software Suministrar ayuda y asistencia a los usuarios finales en la configuración del software de acuerdo a las preferencias y necesidades de su entorno de trabajo Calidad de Componentes Software

58 Ciclo de Vida DSBC: Operación
Ejecución de la aplicación en su entorno de trabajo por sus usuarios finales Calidad de Componentes Software

59 Ciclo de Vida DSBC: Mantenimiento
Ofrecer los servicios y actividades de mantenimiento necesarios para el uso efectivo del software posterior a su implementación Corrección de errores Adaptación del sistema a los cambios del entorno Sustitución y actualización de componentes En esta fase incluimos tambien los procesos de Configuración y Gestión de Cambios que propone RUP Calidad de Componentes Software

60 Ampliaciones del dibujo

61 Componente Software: Información Disponible (1)
In order to assess the Usability of a software component, we need to define: a set of measurable concepts that influence any of the quality sub-characteristics of Usability; the component attributes that can be measured in order to assess such measurable concepts and how they affect each sub-characteristic; and finally, the metrics that measure such attributes. Metrics can be direct metrics, indirect metrics, or indicators. Before we define any of those items, and in particular metrics, we need to know the kind of information that is available about the entities we plan to assess (the software components). This information will be the only measurable elements based on which metrics can be defined. The following UML class diagram shows the information that we think is relevant to the Usability of a component, from all the information that is available for a commercial component. The fact that components are black box and binary units of composition, whose internals cannot be viewed or accessed, only leaves us with the externally observable elements of the component that allow to assess its quality. In the case of Usability, we have considered the component documentation and some of its functional elements. In the following, and according to the diagram 1, the term documentation will refer to component manuals, demos, help system, and marketing information. By functional elements we will refer to the interfaces, operations, or events that a component may support or require from other components to achieve its functionality, i.e., to implement its services. Although some metrics may be defined on individual elements (e.g., number of operations per interface), sometimes it is simpler to refer to the functional elements independently of their granularity. Of course, not all this information is available for all commercial components, as we discovered in our survey [2]. However, we have tried to be realistic when defining the elements above, looking for a balance between the demand of information required by the metrics, and the difficulty we know that software component vendors have for providing that information. From our point of view and previous experience, we think that the information we require (described above) seems to be reasonable. Calidad de Componentes Software

62 Información Disponible: Funcionalidad
In order to assess the Usability of a software component, we need to define: a set of measurable concepts that influence any of the quality sub-characteristics of Usability; the component attributes that can be measured in order to assess such measurable concepts and how they affect each sub-characteristic; and finally, the metrics that measure such attributes. Metrics can be direct metrics, indirect metrics, or indicators. Before we define any of those items, and in particular metrics, we need to know the kind of information that is available about the entities we plan to assess (the software components). This information will be the only measurable elements based on which metrics can be defined. The following UML class diagram shows the information that we think is relevant to the Usability of a component, from all the information that is available for a commercial component. The fact that components are black box and binary units of composition, whose internals cannot be viewed or accessed, only leaves us with the externally observable elements of the component that allow to assess its quality. In the case of Usability, we have considered the component documentation and some of its functional elements. In the following, and according to the diagram 1, the term documentation will refer to component manuals, demos, help system, and marketing information. By functional elements we will refer to the interfaces, operations, or events that a component may support or require from other components to achieve its functionality, i.e., to implement its services. Although some metrics may be defined on individual elements (e.g., number of operations per interface), sometimes it is simpler to refer to the functional elements independently of their granularity. Of course, not all this information is available for all commercial components, as we discovered in our survey [2]. However, we have tried to be realistic when defining the elements above, looking for a balance between the demand of information required by the metrics, and the difficulty we know that software component vendors have for providing that information. From our point of view and previous experience, we think that the information we require (described above) seems to be reasonable. Calidad de Componentes Software

63 Información Disponible Marketing Info.
In order to assess the Usability of a software component, we need to define: a set of measurable concepts that influence any of the quality sub-characteristics of Usability; the component attributes that can be measured in order to assess such measurable concepts and how they affect each sub-characteristic; and finally, the metrics that measure such attributes. Metrics can be direct metrics, indirect metrics, or indicators. Before we define any of those items, and in particular metrics, we need to know the kind of information that is available about the entities we plan to assess (the software components). This information will be the only measurable elements based on which metrics can be defined. The following UML class diagram shows the information that we think is relevant to the Usability of a component, from all the information that is available for a commercial component. The fact that components are black box and binary units of composition, whose internals cannot be viewed or accessed, only leaves us with the externally observable elements of the component that allow to assess its quality. In the case of Usability, we have considered the component documentation and some of its functional elements. In the following, and according to the diagram 1, the term documentation will refer to component manuals, demos, help system, and marketing information. By functional elements we will refer to the interfaces, operations, or events that a component may support or require from other components to achieve its functionality, i.e., to implement its services. Although some metrics may be defined on individual elements (e.g., number of operations per interface), sometimes it is simpler to refer to the functional elements independently of their granularity. Of course, not all this information is available for all commercial components, as we discovered in our survey [2]. However, we have tried to be realistic when defining the elements above, looking for a balance between the demand of information required by the metrics, and the difficulty we know that software component vendors have for providing that information. From our point of view and previous experience, we think that the information we require (described above) seems to be reasonable. Calidad de Componentes Software

64 Información Disponible: Documentación
In order to assess the Usability of a software component, we need to define: a set of measurable concepts that influence any of the quality sub-characteristics of Usability; the component attributes that can be measured in order to assess such measurable concepts and how they affect each sub-characteristic; and finally, the metrics that measure such attributes. Metrics can be direct metrics, indirect metrics, or indicators. Before we define any of those items, and in particular metrics, we need to know the kind of information that is available about the entities we plan to assess (the software components). This information will be the only measurable elements based on which metrics can be defined. The following UML class diagram shows the information that we think is relevant to the Usability of a component, from all the information that is available for a commercial component. The fact that components are black box and binary units of composition, whose internals cannot be viewed or accessed, only leaves us with the externally observable elements of the component that allow to assess its quality. In the case of Usability, we have considered the component documentation and some of its functional elements. In the following, and according to the diagram 1, the term documentation will refer to component manuals, demos, help system, and marketing information. By functional elements we will refer to the interfaces, operations, or events that a component may support or require from other components to achieve its functionality, i.e., to implement its services. Although some metrics may be defined on individual elements (e.g., number of operations per interface), sometimes it is simpler to refer to the functional elements independently of their granularity. Of course, not all this information is available for all commercial components, as we discovered in our survey [2]. However, we have tried to be realistic when defining the elements above, looking for a balance between the demand of information required by the metrics, and the difficulty we know that software component vendors have for providing that information. From our point of view and previous experience, we think that the information we require (described above) seems to be reasonable. Calidad de Componentes Software

65 Subcaracterísticas de Usabilidad

66 Adaptando la Usabilidad para DSBC
Comprensión: la capacidad del componente software para permitir que el usuario (desarrollador del sistema) comprenda si el componente es adecuado y como puede usarse para tareas y condiciones de uso concretas Los desarrolladores del sistema deben poder seleccionar el componente más adecuado para la utilización prevista o deseada Los elementos del componente (intefaces, operaciones …) deben ser evidentes o fáciles de comprender ─       Understandability: the capability of the component to enable the user (developer) to understand whether the component is suitable, and how it can be used for particular tasks and conditions of use. Developers should be able to select a component suitable for their intended use. For example, components elements (e.g. interfaces, operations) should be easy to understand or evident. ─       Learnability: the capability of the software component to enable the user (developer) to learn the application. A learnability metric should be able to assess how long it takes developers to learn how to use particular functions (interfaces, operations, …), or the effectiveness of documentation (manuals, help system, demos). For example, the user documentation and the help system should be complete, the help should be context sensitive and explain how to achieve common tasks, etc. ─       Operability: the capability of the software component to enable the user (developer) to operate and control it. An operability metric should be able to assess whether developers can operate and control the component. Operability metrics can be categorised by the dialogue principles in ISO : o       suitability of the component for the task; o       self-descriptiveness of the component; o       controllability of the component; o       conformity of the component with user expectations (requirements); o       error tolerance of the component; o       suitability of the component for individualisation. ─       Attractiveness: the capability of the software component to be attractive to the user. Since the users we consider are not end-users, this subcharacteristic is of no interest in our case. ─       Usability compliance: the capability of the software component to adhere to standards, conventions, style guides or regulations relating to usability. Currently, we don’t know of any standards or regulations for component usability. Thus, we will not define any metric for this sub-characteristic. Calidad de Componentes Software

67 Adaptando la Usabilidad para DSBC
Aprendibilidad: la capacidad del componente software para permitir que el usuario (desarrollador del sistema) aprenda el componente Estas métricas deben valorar cuanto tiempo le llevara a los desarrolladores aprender como se usan las interfaces, las operaciones, los eventos, … del componente. O medir la efectividad de los manuales, sistema de ayuda, las demos,… ─       Understandability: the capability of the component to enable the user (developer) to understand whether the component is suitable, and how it can be used for particular tasks and conditions of use. Developers should be able to select a component suitable for their intended use. For example, components elements (e.g. interfaces, operations) should be easy to understand or evident. ─       Learnability: the capability of the software component to enable the user (developer) to learn the application. A learnability metric should be able to assess how long it takes developers to learn how to use particular functions (interfaces, operations, …), or the effectiveness of documentation (manuals, help system, demos). For example, the user documentation and the help system should be complete, the help should be context sensitive and explain how to achieve common tasks, etc. ─       Operability: the capability of the software component to enable the user (developer) to operate and control it. An operability metric should be able to assess whether developers can operate and control the component. Operability metrics can be categorised by the dialogue principles in ISO : o       suitability of the component for the task; o       self-descriptiveness of the component; o       controllability of the component; o       conformity of the component with user expectations (requirements); o       error tolerance of the component; o       suitability of the component for individualisation. ─       Attractiveness: the capability of the software component to be attractive to the user. Since the users we consider are not end-users, this subcharacteristic is of no interest in our case. ─       Usability compliance: the capability of the software component to adhere to standards, conventions, style guides or regulations relating to usability. Currently, we don’t know of any standards or regulations for component usability. Thus, we will not define any metric for this sub-characteristic. Calidad de Componentes Software

68 Adaptando la Usabilidad para DSBC
Operabilidad: la capacidad del componente software para permitir que el usuario (desarrollador del sistema) opere con él y lo controle Estas métricas deben poder valorar si los desarrolladores del sistema pueden integrar correctamente el componente o adaptarlo ─       Understandability: the capability of the component to enable the user (developer) to understand whether the component is suitable, and how it can be used for particular tasks and conditions of use. Developers should be able to select a component suitable for their intended use. For example, components elements (e.g. interfaces, operations) should be easy to understand or evident. ─       Learnability: the capability of the software component to enable the user (developer) to learn the application. A learnability metric should be able to assess how long it takes developers to learn how to use particular functions (interfaces, operations, …), or the effectiveness of documentation (manuals, help system, demos). For example, the user documentation and the help system should be complete, the help should be context sensitive and explain how to achieve common tasks, etc. ─       Operability: the capability of the software component to enable the user (developer) to operate and control it. An operability metric should be able to assess whether developers can operate and control the component. Operability metrics can be categorised by the dialogue principles in ISO : o       suitability of the component for the task; o       self-descriptiveness of the component; o       controllability of the component; o       conformity of the component with user expectations (requirements); o       error tolerance of the component; o       suitability of the component for individualisation. ─       Attractiveness: the capability of the software component to be attractive to the user. Since the users we consider are not end-users, this subcharacteristic is of no interest in our case. ─       Usability compliance: the capability of the software component to adhere to standards, conventions, style guides or regulations relating to usability. Currently, we don’t know of any standards or regulations for component usability. Thus, we will not define any metric for this sub-characteristic. Calidad de Componentes Software

69 Adaptando la Usabilidad para DSBC
Atractividad: la capacidad del componente software para resultar atractivo a los usuarios Como estamos considerando que los usuarios del componente no son los usuarios finales, esta característica no la incluimos ─       Understandability: the capability of the component to enable the user (developer) to understand whether the component is suitable, and how it can be used for particular tasks and conditions of use. Developers should be able to select a component suitable for their intended use. For example, components elements (e.g. interfaces, operations) should be easy to understand or evident. ─       Learnability: the capability of the software component to enable the user (developer) to learn the application. A learnability metric should be able to assess how long it takes developers to learn how to use particular functions (interfaces, operations, …), or the effectiveness of documentation (manuals, help system, demos). For example, the user documentation and the help system should be complete, the help should be context sensitive and explain how to achieve common tasks, etc. ─       Operability: the capability of the software component to enable the user (developer) to operate and control it. An operability metric should be able to assess whether developers can operate and control the component. Operability metrics can be categorised by the dialogue principles in ISO : o       suitability of the component for the task; o       self-descriptiveness of the component; o       controllability of the component; o       conformity of the component with user expectations (requirements); o       error tolerance of the component; o       suitability of the component for individualisation. ─       Attractiveness: the capability of the software component to be attractive to the user. Since the users we consider are not end-users, this subcharacteristic is of no interest in our case. ─       Usability compliance: the capability of the software component to adhere to standards, conventions, style guides or regulations relating to usability. Currently, we don’t know of any standards or regulations for component usability. Thus, we will not define any metric for this sub-characteristic. Calidad de Componentes Software

70 Adaptando la Usabilidad para DSBC
Conformidad de Usabilidad: la capacidad del componente software para seguir los estándares, convenciones, guías de estilo o normativas relacionadas con la usabilidad Actualmente, no conocemos ningún estándar o norma de usabilidad para componentes software ─       Understandability: the capability of the component to enable the user (developer) to understand whether the component is suitable, and how it can be used for particular tasks and conditions of use. Developers should be able to select a component suitable for their intended use. For example, components elements (e.g. interfaces, operations) should be easy to understand or evident. ─       Learnability: the capability of the software component to enable the user (developer) to learn the application. A learnability metric should be able to assess how long it takes developers to learn how to use particular functions (interfaces, operations, …), or the effectiveness of documentation (manuals, help system, demos). For example, the user documentation and the help system should be complete, the help should be context sensitive and explain how to achieve common tasks, etc. ─       Operability: the capability of the software component to enable the user (developer) to operate and control it. An operability metric should be able to assess whether developers can operate and control the component. Operability metrics can be categorised by the dialogue principles in ISO : o       suitability of the component for the task; o       self-descriptiveness of the component; o       controllability of the component; o       conformity of the component with user expectations (requirements); o       error tolerance of the component; o       suitability of the component for individualisation. ─       Attractiveness: the capability of the software component to be attractive to the user. Since the users we consider are not end-users, this subcharacteristic is of no interest in our case. ─       Usability compliance: the capability of the software component to adhere to standards, conventions, style guides or regulations relating to usability. Currently, we don’t know of any standards or regulations for component usability. Thus, we will not define any metric for this sub-characteristic. Calidad de Componentes Software