Calidad en el Desarrollo Software Basado en Componentes
| ||||||
Calidad en el Desarrollo Software Basado en Componentes. La palabra calidad tiene varios significados, aunque dentro de la Ingeniería del Software podemos adoptar la definición de la norma ISO-8402, que luego se repite en otras (por ejemplo en ISO-14598): “La totalidad de aspectos y características de un producto o servicio que tienen que ver con su habilidad para satisfacer las necesidades declaradas o implícitas”. Aunque la calidad es un objetivo importante para cualquier producto, no debemos olvidar que los productos, y también los productos software, se construyen para ser utilizados.
Por tanto, el principal objetivo de un producto es satisfacer una necesidad (o varias) de un usuario y, por consiguiente, ofrecer al usuario algún beneficio por su utilización. Es decir, la calidad no es el objetivo último del producto, sino satisfacer las necesidades de un cliente. También es importante señalar que esto implica que la calidad de un producto software no se puede referir únicamente a obtener un producto sin errores. La especificación de la calidad del software debe ser más detallada y exacta, y el camino para ello es la formalización de la calidad mediante un modelo de calidad que, como veremos a continuación, define las características de un producto que influyen a la hora de medir su calidad.
Sumario
Características de Calidad en Componentes
En general, no existe un consenso a la hora de definir y clasificar las características de calidad que debe presentar un producto software. Por tanto, utilizaremos los estándares internacionales, fundamentalmente el ISO-9126. Aunque actualmente en proceso de revisión, ha sido el primero en definir y concretar este tipo de características.
Siguiendo su terminología, entendemos por característica de calidad de un producto software a un conjunto de propiedades mediante las cuales se evalúa y describe su calidad. Una característica se puede refinar en múltiples niveles de sub-características. Ejemplos de características son la funcionalidad, la fiabilidad o la facilidad de uso. A su vez, la característica funcionalidad se puede descomponer en sub-características como corrección, interoperatividad y seguridad, entre otras.
Llamaremos atributo a una propiedad de calidad a la que puede asignársele una métrica, entendiendo por métrica un procedimiento que examina un componente y produce un dato simple, un símbolo (p.e. Excelente, Sí, No) o un número. Hay que tener en cuenta que no todas las propiedades son medibles (p.e. la “demostrabilidad”).
Con todo esto, un modelo de calidad se define como “un conjunto de características y sub-características, junto con las relaciones que existen entre ellas”. Por supuesto, el modelo de calidad a utilizar va a depender del tipo de producto a evaluar. En este sentido, los estándares y propuestas existentes definen modelos de calidad generales, válidos para grandes familias de productos. Sin embargo, su alto grado de generalización y abstracción hacen difícil su aplicación a temas concretos. También, es importante tratar de “refinar” esos modelos generales, particularizándolos a casos concretos. Por ello, resultaría de gran interés y utilidad poder contar con un modelo de calidad particularizado para componentes. Desde nuestro punto de vista, dicho modelo de calidad ha de ser simple y concreto si queremos que pueda ser utilizado con ciertas garantías de éxito.
Uno de los principales objetivos de tal modelo de calidad para componentes es el de detectar los atributos que pueden describir los proveedores (externos o internos) de componentes COTS en la información que suministran acerca de los mismos y que, por tanto, permitirían facilitar su valoración y selección por parte de los diseñadores y desarrolladores de productos software.
Clasificación de los atributos de calidad
Para los componentes, y tendiendo en cuenta como posible objetivo la definición de un modelo de calidad específico, es fundamental primero realizar una taxonomía, tratando de clasificar las características de calidad de acuerdo a su naturaleza y a distintos parámetros que intervienen en su medida. Se pueden realizar distintos tipos de clasificaciones.
1. En primer lugar, necesitamos discriminar entre aquellas características que tienen sentido para los componentes aislados (características locales) o bien deben ser valoradas a nivel de la arquitectura software de la aplicación (que llamaremos 7 características globales). Por ejemplo, la “tolerancia a fallos” es una típica característica que va a depender de la arquitectura de la aplicación, mientras que la “madurez” es más propia de los componentes.
2. El instante en el cual una característica puede ser observada o medida, permite establecer otra clasificación de las características de un producto. Así, tenemos dos posibles categorías dependiendo de si la característica es observable en tiempo de ejecución (p.e. el rendimiento) o durante el ciclo de vida del producto (p.e. la mantenibilidad).
3. Como se menciona en los estándares de ISO, es importante identificar los usuarios a los que se dirige el modelo. En el ámbito del DSBC, los usuarios son fundamentalmente los arquitectos software, que necesitan evaluar los componentes COTS que van a formar parte de su aplicación. Así, las interfaces de los componentes objeto de nuestro estudio son más las interfaces programáticas (es decir, las APIs que definen las formas de acceder desde otros programas a los servicios que ofrecen los componentes), que las interfaces de usuario.
4. Para componentes COTS, es fundamental distinguir entre métricas internas y externas. Las internas miden los atributos internos del producto final o de los productos intermedios (p.e. la especificación o el código fuente) durante el diseño y la codificación. Las externas son las que realizan las mediciones en función del comportamiento del sistema durante las pruebas y la operación del componente. Por tanto, debido al carácter de caja negra de los componentes COTS, son las métricas externas las que interesan. Esto no quita que algunas de las características internas den una medida indirecta de las externas, e incluso que puedan tener efectos sobre la arquitectura final. Así, por ejemplo, el tamaño de un componente puede ser importante a la hora de tener en cuenta los requisitos de espacio de la aplicación.
Otras características
Por último, es importante señalar que, además de las características de calidad en un componente, hay otro conjunto de características no relacionadas directamente con la calidad como pueden ser el precio, la asistencia técnica, las condiciones de licencia, etc., que también son necesarias a la hora de valorar el componente más adecuado.
Todas estas características técnicas y no técnicas deben estar documentadas en un formato aceptado por los participantes en el desarrollo de software. Una forma adecuada de implementar la documentación de componentes es utilizar el modelo de “propiedades” de ODP [RM-ODP 1997] donde cada atributo se describe mediante un par (nombre, valor), con un tipo asociado a cada nombre. Estas propiedades se pueden describir mediante plantillas XML, lo cual facilita la conexión con cualquier tipo de herramientas. Además, esta forma de documentar los componentes abre la posibilidad de implementar procesos de selección automática o semiautomática, facilitando el proceso de valoración de los componentes software.
Otro tema, muy relacionado con este, es el de la Calidad de Servicio (QoS). En su normativa, ISO define la QoS] como “un conjunto de calidades relacionadas con el comportamiento colectivo de uno o más objetos”. En este sentido es importante señalar que fundamentalmente este tipo de atributos van a coincidir con los atributos de calidad que pueden ser medidos durante la ejecución del sistema o de los componentes. Sin embargo, suelen ser más al nivel de sistema que de componentes, pues la QoS se mide con respecto al comportamiento global del sistema y a los resultados que éste produce.
Por tanto, no es suficiente con disponer de los valores de los atributos de calidad de los componentes de un sistema, sino también influye la forma en la que están conectados, el medio de transporte que utilizan para comunicarse, la complejidad de los protocolos de interacción entre ellos, etc. En general este es un tema complejo y en el cual se trabaja de forma muy activa Pal et al., 2000; Cukier et al., 1998; Schmitdt et al., 1998; Zinky et al., 1997.
Fuente
- Bertoa, Manuel F., Troya, José M. y Vallecillo, Antonio. Aspectos de Calidad en el Desarrollo de Software Basado en Componentes. Universidad de Málaga.
