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

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

Conceptos sobre Componentes Software

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

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

Desarrollo de Software Basado en Componentes (DSBC)

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

Desarrollo (simplificado) Basado en COTS Calidad de Componentes Software

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

Mercado de Componentes COTS

Calidad de Componentes Software www.componentsource.com Calidad de Componentes Software

Calidad de Componentes Software www.componentsource.com Calidad de Componentes Software

Calidad de Componentes Software www.componentsource.com Calidad de Componentes Software

Calidad de Componentes Software www.componentsource.com Calidad de Componentes Software

Calidad de Componentes Software www.componentsource.com Calidad de Componentes Software

Calidad de Componentes Software www.componentsource.com Calidad de Componentes Software

Selección de Componentes ¿Comprar o Construir?

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

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

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

Modelo de Calidad ISO 9126

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

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

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

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

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

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

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

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

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

La Usabilidad en DSBC

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

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

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 9241-10: 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

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 9241-10: 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

Proceso de medición de la Usabilidad de Componentes Software

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

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

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

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

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

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

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

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

¿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

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

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

Calidad de Componentes Software Gracias y Preguntas Preguntas: Antonio Vallecillo av@lcc.uma.es 952 13 27 94 Calidad de Componentes Software

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

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

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

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

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

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

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

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

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

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

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

Ampliaciones del dibujo

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

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

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

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

Subcaracterísticas de Usabilidad

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 9241-10: 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

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 9241-10: 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

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 9241-10: 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

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 9241-10: 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

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 9241-10: 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