Está en la página 1de 37

QA: news N10

Antonio lvarez Analista Funcional Sogeti Espaa Septiembre 2012

Los Atributos de Calidad del Software


En este artculo se revisan y comparan los modelos de calidad ms usados para especificar los atributos de calidad del software y las mtricas para medirlos, en contraste con las pruebas cuyo objetivo es validar o verificar el buen funcionamiento y el cumplimiento de las especificaciones.

Indice de contenidos

Descomposicin de la calidad del software en factores o atributos de calidad ..................... 4 Paradigma GQM (Objetivo-pregunta-mtrica) ................................................................ 9 El modelo de McCall (1977) ....................................................................................... 10 El modelo de Boehm (1978) ..................................................................................... 18 Modelo de FURPS (1987) ........................................................................................... 20 Modelo de DROMEY (1996) ........................................................................................ 21 ISO 9126 Software Engineering Product Quality (2001) .............................................. 23 TMap Next (2006) .................................................................................................... 30 Catlogos de Atributos .............................................................................................. 31 Conclusin............................................................................................................... 36 Bibliografa consultada .............................................................................................. 37 De forma general, el conjunto de las pruebas (Testing) tiene como objetivo evaluar la calidad de un producto, mejorndolo si cabe, mediante la identificacin de defectos, problemas y discrepancias. Para este conjunto de pruebas existen muchas clasificaciones, por ejemplo, tradicionalmente se han dividido las pruebas en Funcionales, que son aquellas basadas en el anlisis de las especificaciones y funcionalidades de un componente o sistema, es decir, en aquello que hace; y las pruebas No funcionales, que se ocupan de cmo el sistema se comporta en su interaccin con el usuario y su entorno.

QA: news N10

Fig.1 Clasificacin tradicional de las pruebas en Funcionales y No funcionales. stas ltimas son las ms relacionadas con lo que aqu denominamos atributos de calidad.

Sin dejar del todo esta perspectiva basada en la verificacin de funcionalidades o de comportamientos, podramos ubicar las pruebas en dos grandes tipos: Tipo I: Las que nos sirven para comprobar que el software hace lo que tiene que hacer (siguiendo las especificaciones y requerimientos) y que lo hace correctamente. Se centra en la bsqueda de errores o discrepancias (respecto a los requerimientos y especificaciones). Tipo II: Las que nos sirven para comprobar que el software opera ptimamente, de acuerdo con los atributos de calidad estndares y especficos. Se centra en la performance y el funcionamiento ptimo en la interaccin con el usuario y con el entorno.

QA: news N10

El primer tipo tambin se suele denominar como V&V (Verificacin y Validacin). La verificacin responde a la pregunta Estamos construyendo correctamente el software?, es decir, hemos de demostrar que la aplicacin es conforme a su especificacin, y que los productos de cada fase del ciclo de vida satisfacen las condiciones (requisitos, especificaciones, normas) impuestas al comienzo de la fase. Tiene que ver tpicamente con el testing para la deteccin de errores. Por otro lado, la validacin responde a la pregunta Estamos construyendo el software correcto?, es decir, la aplicacin hace exactamente lo que el usuario quiere que haga?. Se determina la correccin del producto respecto a las necesidades del usuario. Tiene que ver tpicamente con la adecuacin con las necesidades del usuario final, detectando posibles malinterpretaciones (lo que no implica necesariamente que sean errores). Las actividades de V&V, tal como se describen en IEEE 1012, no se llevan a cabo puntualmente, sino que se realizan de forma iterativa a lo largo del ciclo de vida del software, desde su diseo hasta su retirada, pasando por su construccin.

Fig.2 Modelo en V de Evaluacin del Software, relacionado fundamentalmente con las pruebas de V&V.

QA: news N10

El segundo tipo de pruebas no se caracteriza por la deteccin de errores o discrepancias, sino por la verificacin de que, en las condiciones en que el software ha sido desarrollado, en el entorno en el que est implantado y con los requisitos funcionales que debe cumplir, el software se comporta de la mejor forma posible, y que su comportamiento ser igualmente ptimo si se ve sometido a un rango de cambios especificado. Por tanto, la perspectiva de este segundo conjunto de pruebas es sustancialmente diferente al primero. Podemos encontrarnos con una aplicacin que entre sus funcionalidades est la de buscar registros en una base de datos. Esta tarea la puede hacer correctamente, pero puede tardar varios minutos, enlentenciendo as el trabajo de los usuarios. Una prueba del Tipo I no detectara errores en esta funcin, mientras que una prueba del Tipo II dara un resultado negativo, indicando que esta funcin tendra que mejorarse. Otra aplicacin puede funcionar correctamente y presentar las pantallas y los datos con la velocidad suficiente, pero las opciones para el manejo de la aplicacin se pueden presentar en mens muy complicados, siendo difcil encontrar las opciones o teniendo el usuario que pasar por numerosas pantallas para llegar a la informacin que busca. En este caso tampoco se encontraran errores en las pruebas del primer tipo, pero algunas de las pruebas del segundo tipo nos daran resultados negativos.

El presente artculo est dedicado a los modelos de calidad que se centran en este segundo gran tipo de pruebas, en ocasiones difciles de concretar, o de hacer tangibles, como pueden ser la Facilidad de uso, la Idoneidad o la Facilidad de aprendizaje, por ejemplo.

Descomposicin de la calidad del software en factores o atributos de calidad A menudo, cuando se habla de calidad del software 1, tenemos que concretar cules son las propiedades que hacen que podamos decir que un software es de buena calidad. Por eso, para concretar en qu nos hemos de fijar para evaluar el software, se divide el concepto de calidad en una serie de caractersticas, atributos o factores, como por ejemplo:

Segn el IEEE Std. 1061: Software quality is the degree in which software possesses a desired combination of quality attributes. The purpose of software metrics is to make assessments throughout the software life cycle as to whether the software quality requiremen ts are being met. The use of software metrics reduces subjectivity in the assesment and control of software quality by providing a quantitative basis for making decisions about software quality.However, the use of metrics does not eliminate the need for human judgment in software assessment.

QA: news N10

Fiabilidad Habilidad del software para mantenerse operativo (funcionando). Eficiencia Habilidad del software para responder a una peticin de usuario con la velocidad apropiada. Usabilidad Habilidad del software para satisfacer al usuario. Mantenibilidad Habilidad del software para poder realizar cambios en l fcilmente y con una adecuada proporcin cambio/costo. Portabilidad Habilidad del software para operar en diferentes entornos informticos. , etc.

El estndar ISO/IEC 15939 define una Entidad como un objeto que puede ser caracterizado mediante la medicin del conjunto de sus atributos, y un Atributo como una caracterstica medible de una entidad. Para nosotros, en este artculo, una aplicacin o software o sistema informtico es una entidad 2.

Segn IEEE Std 1061 3 una Mtrica de calidad de un software es una funcin cuyas entradas son datos del software y cuyas salidas son valores numricos que pueden interpretarse como el grado en el cual el sofware posee un atributo que afecta a su calidad.

Segn ISO 9126 una Caracterstica (atributo) de calidad de un software es aquello que:
2

Se muestra externamente al usar el software y es el resultado de atributos internos. Es aplicable a cualquier tipo de software. Puede descomponerse en subcaractersticas, dependiendo de sus atributos o complejidad. Proporciona una terminologa consistente para la calidad del producto software. Proporciona un marco para especificar requisitos de calidad del software.

Para ms detalles se puede consulta el estndar ISO/IEC Guide 99:2007 (ms comnmente conocido como VIM), que recopila un conjunto de definiciones y trminos relacionados con la ciencia de la medicin (metrologa) en general y no slo de la ingeniera del software.
3

El IEEE 1061 Standard for a Software Quality Metrics Methodology , define una metodologa para llevar a cabo la identificacin, implementacin, y evaluacin de mtricas para procesos y productos software, vlida para todas las fases del ciclo de vida del software, independientemente del modelo de desarrollo y del tipo de ciclo de vida (cascada, iterativo e incremental, etc.).Este estndar no prescribe explcitamente las mtricas que tienen que utilizarse, sino que se limina sugerir el uso de mtricas en la gestin de proyectos de desarrollo e implantacin de software, con objeto de mejorar la calidad del producto obtenido.

QA: news N10

Permite definir compromisos en cuanto a capacidades del producto software.

Segn TMap (Sogeti) una caracterstica de calidad es un descriptor de una propiedad de un sistema informtico.

Las caractersticas de calidad pueden subdividirse en: Calidad del proceso. Que sirven para supervisar la ejecucin del proyecto, midiendo tiempos y fases, y para evaluar y hacer el seguimiento de los riesgos. Calidad del producto. Que se centran en las caractersticas del software, en lugar de en el proceso seguido para su produccin.

Fig.3 Divisin bsica de las caractersticas de Calidad en propias del producto y propias del proceso.

Para determinar de qu forma se pueden medir estas caractersticas o atributos de calidad se confeccionan las mtricas, que nos indican qu parmetros concretos hemos de detectar y cmo hemos de operar con ellos para llegar a algn tipo de valor indicativo del grado de cumplimiento de la caracterstica de calidad.

Una caracterstica o factor de calidad se puede evaluar utilizando varias mtricas, de manera que constituye una combinacin de stas, y podra expresarse en una frmula como la siguiente:

QA: news N10

Fc= c1 * m1 + c2 * m2 + + cn * mn ci factor de ponderacin de la mtrica i, que depender de cada aplicacin especfica mi mtrica i

Segn Pressman (1998) las mtricas para determinar los factores de calidad pueden ser: Facilidad de auditoria Exactitud Normalizacin de las comunicaciones Completitud Concisin Consistencia Estandarizacin de los datos Tolerancia de errores Eficiencia de la ejecucin Facilidad de expansin Generalidad Independencia del hardware Instrumentacin Modularidad Facilidad de operacin Seguridad Auto-documentacin Simplicidad Independencia del sistema software Facilidad de traza Formacin

QA: news N10

De todas formas, no siempre es fcil determinar en qu atributos de calidad hemos de fijarnos para evaluar correctamente nuestro software. Para ayudarnos en este punto existen los llamados Modelos de calidad, que nos guan en la descomposicin de nuestra idea genrica de calidad en una serie de propiedades (factores, atributos, caractersticas) medibles y evaluables. Los modelos ms difundidos son: Modelo de Boehm [Boehm et al., 1978]. Modelo de McCall [McCall et al., 1977]. ISO 9126 (2001-2004). Paradigma GQM (Goal-Question-Metric) [Basili y Rombach, 1988]. Modelo de Gilb [Gilb, 1988]. Modelo CMM (Capability Maturity Model), del SEI. TMap (SOGETI) Modelo FURPS (1987) Modelo de Dromey (1996)

Fig.4. Cronologa aproximada de aparicin de los principales modelos de calidad del software.

QA: news N10

De todos ellos, el modelo GQM est dirigido exclusivamente a la elucidacin de estos atributos de calidad, y no a su medicin.

Por otra parte, el estndar CMM (Capability Maturity Model), elaborado por el SEI (Universidad Carnegie Mellon), permite determinar la madurez de los procesos de calidad relacionados con las tecnologas de la informacin en una organizacin e identifica las prcticas clave requeridas para incrementar la madurez de los mismos. El estndar ISO/IEC 15504 (SPICE) est basado en este modelo. Sin embargo, CMM y sus derivados, como SPICE, CMMi o TMMi, no entran a considerar los atributos de calidad y las mtricas, por lo que caen fuera del mbito del presente artculo.

Paradigma GQM (Objetivo-pregunta-mtrica)

El GQM constituye una metodologa para la definicin de los objetivos de calidad de un proyecto de desarrollo de un software y de la forma de evaluarlos. Para ello considera tres niveles: 1. Nivel conceptual (objetivos, goals): determinacin de los objetivos de calidad de alto nivel. 2. Nivel operacional (preguntas, questions): determinacin de las preguntas que hay que hacerse para comprobar que se estn cumpliendo los objetivos. Cada objetivo se descompone en una serie de preguntas. Las preguntas intentan caracterizar el objeto a ser medido con respecto a una caracterstica de calidad desde un punto de vista especificado. Se procura llegar a plantear, para cada objetivo, preguntas simples, asociadas cada una directamente a un factor o atributo de calidad. 3. Nivel cuantitativo (mtricas, metrics): se asocia un conjunto de mtricas a cada pregunta, de manera que pueda responderse adecuadamente (preferiblemente de forma cuantitativa). En este paso se define cada uno de los atributos y los criterios que se usarn para su medicin, as como el rango de aceptabilidad. Fig.5. Esquema que muestra las similitudes entre los modelos GQM e ISO 9126, en cuanto a la descomposicin de las caractersticas o atributos bsicos de calidad (objetivos o goals en GQM) en subcaractersticas (Questions para GQM), y a la determinacin de las mtricas a utilizar para medirlas.

QA: news N10

Habitualmente, los atributos se normalizan, de manera que su valor queda comprendido entre 0 y 1, sea cual sea el atributo y la forma de medirlo. 0 significa que el valor del atributo no satisface el requerimiento de calidad (el valor del atributo es menor o igual que el menor grado de aceptabilidad). La frmula empleada es como la siguiente:

Los valores men y may corresponden al menor y mayor grado de satisfaccin para cada atributo medido; el valor v corresponde al valor obtenido en la medicin del atributo; s viene a ser el grado de satisfaccin.

El modelo de McCall (1977)

Este modelo de calidad organiza los llamados Factores determinantes de la calidad del software en tres ejes (11 en total). En cada uno de estos ejes se aplican un conjunto de criterios o propiedades (23 en total), y finalmente se especifica para

QA: news N10

cada criterio las mtricas para evaluarlo, indicando los valores mximo y mnimo aceptables.

Ejes, Factores y Criterios de McCall:

Factor / Propiedad

Descripcin

Operacin del Producto (caractersticas operativas) Es fcil y cmodo de manejar?. El esfuerzo requerido para aprender el manejo de una aplicacin, trabajar con ella, introducir datos y conseguir resultados. Facilidad de Operacin Facilidad de Comunicacin Facilidad de Aprendizaje 2 Integridad Es seguro? Puedo controlar su uso?. Grado con que puede controlarse el acceso al software o a los datos a personal no autorizado Facilidad de Auditora Control de Acceso Hace el software lo que yo quiero?. Grado en que una aplicacin satisface sus especificaciones y consigue los objetivos encomendados por el cliente Completitud Consistencia Trazabilidad Lo hace de forma exacta todo el tiempo?. Grado que se puede esperar de una aplicacin lleve a cabo las operaciones especificadas y con la precisin requerida Precisin Consistencia Tolerancia a fallos

1 Usabilidad

3 Correccin

4 Fiabilidad

QA: news N10

Factor / Propiedad Modularidad Simplicidad

Descripcin

5 Eficiencia

Se ejecutar sobre mi hardware y software lo mejor posible?. Cantidad de recursos hardware y software que necesita una aplicacin para realizar las operaciones con los tiempos de respuesta adecuados. Eficiencia en Ejecucin Eficiencia en Almacenamiento

Revisin del Producto (capacidad para soportar cambios) 6 Mantenibilidad Puedo arreglarlo? Es fcil localizar los fallos?. Esfuerzo requerido para localizar y reparar errores

Modularidad Simplicidad Consistencia Concisin Autodescripcin 7 Facilidad Prueba de Puedo probarlo?. Esfuerzo requerido para probar que la aplicacin cumple con los requisitos especificados. Modularidad Simplicidad Autodescripcin Instrumentacin 8 Flexibilidad Puedo modificarlo?. Esfuerzo requerido para modificar una aplicacin en funcionamiento

Autodescripcin Capacidad de expansin Generalidad

QA: news N10

Factor / Propiedad Modularidad

Descripcin

Transicin del Producto (adaptabilidad a nuevos entornos) 9 Reusabilidad Podr reutilizar parte del software en otra aplicacin?. Grado en que partes de una aplicacin pueden utilizarse en otras aplicaciones.

Autodescripcin Generalidad Independencia del software Independencia del hardware 1 Interoperabilidad 0 Puede comunicarse con otros sistemas?. esfuerzo necesario para comunicar la aplicacin con otras aplicaciones o sistemas informticos.

Modularidad Compatibilidad de comunicaciones Compatibilidad de datos 1 Portabilidad 1 Podr utilizarlo en otra mquina?. Esfuerzo requerido para transferir la aplicacin a otro hardware o sistema operativo.

Autodescripcin Modularidad Independencia del software Independencia del hardware

En cuanto a las mtricas, McCall propuso 41 mtricas, la mayora cualitativas o subjetivas. En general, estas mtricas se evalan entre 0 y 10, aunque tratndose de mediciones subjetivas dos evaluadores pueden proponer puntuaciones diferentes para una misma mtrica de un mismo sistema.

Mtrica Auto

Descripcin Que el componente ejecutable proporcione documentacin significativa.

QA: news N10

documentacin Completitud Concisin Implementacin de todas las funciones requeridas. Programa deber ser compacto en lneas de cdigo, con un mnimo de elementos superfluos o no significativos. Uso de mtodos y procedimientos de diseo documentacin estandarizados durante el desarrollo. en la y tcnicas de

Consistencia Eficiencia ejecucin

El tiempo de ejecucin es el ptimo en funcin de la tarea ejecutada. La aplicacin incorpora y maneja correctamente tipos abstractos de datos (TAD) a travs del programa. Precisin en clculos y control

Estandarizacin los datos Exactitud Facilidad auditora Facilidad expansin Facilidad operacin Facilidad seguimiento

de

de

Comprobar la conformidad con los estndares. Facilidad de ampliar procedimientos. diseos arquitectnicos, de datos o

de

de

Facilidad con la que el usuario puede operar el sistema. Facilidad para poder realizar ingeniera en reversa de tareas y funcionalidades. Facilidad para chequear la implementacin correcta de los requerimientos. Debe poseer un buen sistema de ayudas para que los nuevos usuarios no encuentren muchas dificultades para aprender el manejo del sistema. Grado en que las funciones y componentes del sistema pueden ser tiles en otras aplicaciones.

de

Formacin

Generalidad Independencia hardware Independencia sistema software Instrumentacin Modularidad Normalizacin de del

Grado en que el software es independiente del entorno de hardware en el que se ejecuta. Grado en que el software es independiente del entorno de software en que se ejecuta (especialmente en lo referente al sistema operativo). Grado en que el programa funciona correctamente e identifica errores. Divisin del programa en componentes funcionales. Grado en que se emplean estndares, interfaces, protocolos en la

del de

QA: news N10

las comunicaciones Seguridad Simplicidad Tolerancia errores de

implementacin de la comunicacin con otros sistemas y con el usuario. Proteccin contra usuarios no registrados, y acceso correcto de los usuarios autorizados. Facilidad de entendimiento del sistema para el usuario estndar. Grado de prdida o corrupcin de datos cuando se produce un fallo.

Fig. 6. Esquema de las relaciones entre las mtricas y los factores en el modelo de McCall.

QA: news N10

En adaptaciones y mejoras posteriores del modelo se han agrupado los factores en dos grupos: Factores de calidad Externos: Integridad, Fiabilidad, Usabilidad, Correccin, Eficiencia, Interoperabilidad. Factores de calidad Internos: Mantenibilidad, Testabilidad, Flexibilidad, Reusabilidad, Portabilidad.

Tabla 2. Mtricas aplicables a los diferentes factores de calidad propuestos por McCall:

QA: news N10

Por ejemplo, para aplicar las mtricas asociadas al criterio de calidad completitud, dentro del factor de calidad correccin tendramos que usar la siguiente lista de comprobacin:

1. No hay referencias ambiguas [R,D,I] 2. Todas las referencias a datos definidas son calculadas u obtenidas de una fuente externa [R,D,I] 3. Todas las funciones definidas son utilizadas [R,D,I] 4. Todas las referencias a funciones estn definidas [R,D,I] 5. Se han definido todas las condiciones y procesamientos para cada punto de decisin [R,D,I] 6. Concuerdan todos los parmetros de llamada a funciones definidos y referenciados [D,I] 7. Todos los informes de problemas se han resuelto [R,D,I] 8. El diseo concuerda con los requisitos [D] 9. El cdigo concuerda con el diseo [I] Las letras R, D e I indican si la cuestin es aplicable a los requisitos (R), al diseo (D) y/o a la implementacin (I). Se contesta a estas preguntas con un SI o NO, y luego se aplica la siguiente frmula que da como resultado el grado o nivel de calidad para dicho atributo:

De esta forma, la medida para la completitud es un nmero entre 0 y 1.

Fig.7. Grado de correlacin entre los distintos factores. Circulos blancos indican alta correlacin (un alto grado de calidad en un factor implica probablemente un alto grado de calidad en el otro) y circulos negros indican baja correlacin.

QA: news N10

El modelo de Boehm (1978)

Este modelo define a la calidad de software mediante un conjunto de atributos organizados jerrquicamente como caractersticas de alto nivel, de nivel intermedio y de nivel primitivo. Incluye caractersticas de desempeo (performance) del hardware (omitidas en McCall).

En resumen, desde este modelo se considera que un software de buena calidad debe: Hacer lo que el Usuario quiere que haga. Utilizar recursos de la computadora correcta y eficientemente. Ser fcil de aprender y de usar para los usuarios habituales. Estar bien diseado, bien codificado y puede ser probado y mantenido fcilmente.

Las caractersticas de alto nivel representan las tres preguntas bsicas que los usuarios del software se hacen:
4

http://sunset.usc.edu/Research_Group/barry.html.

QA: news N10

1. Utilidad: Cumple adecuadamente su funcin?. 2. Mantenimiento: Es fcil de entender, modificar y volver a probar?. 3. Portabilidad: Se puede seguir usando cuando cambia su entorno de funcionamiento?. Las caractersticas de nivel intermedio representan los siete factores de calidad de Boehm, que juntos conforman la calidad global que se espera del sistema: Portabilidad. Confiabilidad. Eficiencia. Usabilidad. Fcil de entender. Fcil de probar. Flexibilidad.

Fig.8. Jerarqua de Constructores de calidad en el modelo de Boehm.

QA: news N10

Modelo de FURPS (1987)

El modelo de FURPS fue presentado por Robert Grady, responsable de calidad de HP, y deriva del modelo de McCall, organizando los factores de calidad y sus atributos de la siguiente forma: Funcionalidad: que incluye Conjuntos, Capacidades y Seguridad. Usabilidad: que incluye Factores humanos, Consistencia de la interfaz, Ayuda en lnea y sensitiva al contexto, Material de entrenamiento, Documentacin del usuario y del administrador. Reliability (Confiabilidad): que incluye Frecuencia y Severidad de fallos, Capacidad de recuperacin, Capacidad de predecir fallos, Exactitud y Tiempo entre fallos. Performance (Rendimiento): Impone condiciones sobre los requerimientos funcionales como Velocidad, Eficiencia, Disponibilidad, Tiempo de respuesta, Tiempo de recuperacin, Uso de recursos, Exactitud y Salidas (outputs). Supportability (soporte): que incluye las Testabilidad, Extensibilidad, Adaptabilidad, Mantenibilidad, Compatibilidad, Configurabilidad, Capacidad de servicio, Instalabilidad y Capacidad de internacionalizacin.

En general el modelo divide las llamadas categoras (equivalente a atributos o factores de calidad) en dos tipos: Funcionales y No Funcionales. Estas categoras pueden ser usadas tanto como requerimientos para el desarrollo, como parametros de seguimiento de la calidad del producto.

Derivado de este modelo encontramos el FURPS+, que incluye categoras relacionadas con el cumplimiento de normativas, con la implementacin/distribucin y con la percepcin del usuario (interfaz, operatividad), como se ve en la tabla siguiente. De hecho, el (+) en el acrnimo FURPS+ se ha incluido para especificar restricciones, como restricciones de diseo, implementacin e interfaces.

QA: news N10

Tabla 3. Factores y atributos del modelo FURPS.

Modelo de DROMEY (1996)

Este modelo se propuso como un framework para emplearse en la aplicacin de criterios de calidad tanto durante la verificacin/validacin del software como durante su desarrollo, y especialmente hace nfasis en su uso como ayuda para

QA: news N10

dirigir el desarrollo del producto de software 5. Por este motivo se centra en hacer corresponder una serie de atributos internos del software con su implicacin en atributos externos observables y medibles. Es decir, atributos de alto nivel, como la fiabilidad no pueden aplicarse directamente durante el desarrollo de un software; en su lugar hay que considerar una serie de propiedades cuya resultante sea un comportamiento fiable del software. De esta forma, a diferencia del modelo de McCall, la calidad se construye de abajo hacia arriba (bottom-up), desde las propiedades tangibles de bajo nivel hacia los atributos de calidad de alto nivel.

Se sugiere el uso de cuatro categoras o propiedades para determinar la calidad de un producto: 1. 2. 3. 4. Correccin Cualidades internas Cualidades contextuales Cualidades descriptivas

Fig.9. Organizacin jerrquica de las relaciones de los elementos del modelo de Dromey.

Fig. 10. Organizacin jerrquica de las propiedades (Factores) y atributos (criterios) del modelo de Dromey.

De hecho, Dromey propone el uso de diferentes modelos de calidad para cada etapa de desarrollo del software. As tenemos un modelo de calidad para los requerimientos, un modelo de calidad para el diseo y un modelo de calidad para la implementeacin. Cada uno de estos modelos tiene su propio conjunto de atributos de calidad de algo nivel y subatributos.

QA: news N10

ISO 9126 Software Engineering Product Quality (2001)

ISO/IEC 9126

se subdivide en cuatro partes: IS 9126-1:2001 QualityModel TR 9126-2:2003 External Metrics TR 9126-3:2003 InternalMetrics TR 9126-4:2004 Quality in use Metrics

ISO/IEC ISO/IEC ISO/IEC ISO/IEC

El modelo ISO/IEC 9126-1 se bas inicialmente en los modelos anteriores, como el de McCall y Boehm, y se define mediante la especificacin de caractersticas generales del software que progresivamente se descomponen en subcaractersticas, que a su vez se componen de atributos, de manera que en la base de la jerarqua tendremos atributos del software medibles mediante algn tipo de mtrica.
6

Desde el 2005 el estndar ISO/IEC 94126 fue asumido e integrado en el proyecto SQuaRE (Software product Quality Requirements and Evaluation), desarrollado con la ISO 25000.

QA: news N10

Una de las novedades de la ISO 9126, respecto a los modelos anteriores, es que incluye la Funcionalidad como caracterstica de calidad 7. Adems se hace una distincin entre calidad interna, calidad externa y calidad en uso. Los atributos que pueden medirse durante el proceso de desarrollo se consideran internos, mientras que los atributos externos son los que se pueden medir durante el proceso de testing. Por otro lado la calidad en uso es la que es percibida por el usuario.

Fig.11. Esquema conceptual de las relaciones entre los diferentes tipos de calidad en ISO 9126.

Fig.12. Jerarqua de caractersticas y atributos de calidad externa/interna.

En el enfoque del presente artculo, los atributos y las pruebas relacionadas con la funcionalidad los consideraramos como de Tipo I (enfocados principalmente en la deteccin de errores y discrepancias, en lugar de centrarse en la mejora u optimizacin).

QA: news N10

Fig.13. Caractersticas para la calidad en uso.

Tabla 4. Definiciones de las caractersticas de calidad de ISO/IEC 9126-1

Nombre 1 Funcionality
8

Descripcin Caractersticas relativas al cumplimiento del propsito bsico para el cual el software ha sido desarrollado Adecuacin. La funcin se ajusta al conjunto de tareas para las que fue creada. Precisin. La funcin acordados. proporciona los resultados correctos, o

Suitability

Accuracy

Interoperabilit Interoperabilidad. El software puede interactuar correctamente con y otros sistemas previamente especificados. Seguridad. Habilidad para prevenir el acceso no autorizado a programas y datos, y para facilitar el acceso a los usuarios debidamente autorizados. Conformidad de la Funcionalidad. Cumplimiento de los estndares relacionados con la aplicacin, con las convenciones y con las regulaciones establecidas por leyes y procedimientos. Confiabilidad. Caractersticas relativas a la capacidad del software para mantener su nivel de desempeo bajo determinadas condiciones y durante un periodo de tiempo establecido. Madurez. Capacidad del software para evitar su cada como

Security

Compliance

2 Reliability

Maturity

Esta caracterstica se evala con pruebas que en general son de lo que aqu hemos denominado tipo I, es decir, buscan la existencia de errores respecto al funcionamiento requerido.

QA: news N10

resultado de fallos o errores. Fault tolerance Tolerancia a fallos. Habilidad para mantener un determinado nivel de desempeo en caso de fallo o entradas no esperadas (manipulacin inapropiada de su interfaz de usuario).

Capacidad de recuperacin. Capacidad y esfuerzo necesario para Recoverability reestablecer el nivel de rendimiento, recuperando los datos afectados tras un posible fallo. Conformidad de la Confiabilidad. Cumplimiento de los estndares relacionados con la aplicacin, con las convenciones y con las regulaciones establecidas por leyes y procedimientos. Usabilidad. Capacidad del software para ser entendido, aprendido y usado con facilidad, as como su capacidad para ser atractivo para el usuario, bajo unas condiciones especficas.

Compliance

3 Usability

Comprensibilidad. Esfuerzo que un usuario tiene que hacer para Understandabi entender la lgica y para usar el software para determinadas tareas lity y condiciones de uso. Learnability Facilidad de aprendizaje. Esfuerzo que un usuario tiene que hacer para aprender el manejo de la aplicacin. Operatividad. La facilidad con que puede ser manejado y controlado por los usuarios. Atractivo. Capacidad del software para resultar atractivo para el usuario. Conformidad de la Usabilidad. Cumplimiento de los estndares relacionados con la aplicacin, con las convenciones y con las regulaciones establecidas por leyes y procedimientos. Eficiencia. Caractersticas referentes a las relaciones entre el rendimiento y la cantidad de recursos empleados en unas condiciones determinadas.

Operability

Attractiveness

Compliance

4 Efficiency

Tiempo de respuesta. La rapidez con que se produce la respuesta y Time behavior los tiempos de procesamiento, as como tasas de rendimiento para el desempeo de una funcin. Resource utilization Uso de recursos. Cantidad y tipo de recursos usados y duracin de este uso para el desempeo de una funcin bajo determinadas condiciones.

QA: news N10

Compliance

Conformidad de la Eficiencia. Cumplimiento de los estndares relacionados con la aplicacin, con las convenciones y con las regulaciones establecidas por leyes y procedimientos. Mantenibilidad. Caractersticas relacionadas con el esfuerzo necesario para hacer modificaciones, incluyendo correcciones, mejoras o adaptaciones a cambios en el entorno, nuevos requisitos o especificaciones funcionales. Analizabilidad. El esfuerzo necesario para el diagnstico de las deficiencias or causas de los fallos, o para la identificacin de las partes que deben ser modificadas. El esfuerzo necesario para la modificacin destinada a la eliminacin del fallo o para un cambio en el entorno. Facilidad para implementar una modificacin especfica. Capacidad de evitar efectos inesperados implementacin de modificaciones. resultantes de la

Maintainabilit y

Analyzability

Changeability

Stability Testability

El esfuerzo necesario para la validacin de las modificaciones. Conformidad de la Mantenibilidad. Cumplimiento de los estndares relacionados con la aplicacin, con las convenciones y con las regulaciones establecidas por leyes y procedimientos. Portabilidad. Caractersticas relacionadas con la capacidad de transferir el software desde una organizacin o hardware o entorno a otra/o. Facilidad para la adaptacin a diferentes entornos especificados. Esfuerzo necesario especfico. para instalar el software en un entorno

Compliance

6 Portability

Adaptability Installability

Coexistence

Capacidad del software para coexistir independientes en un entorno comn.

con

otros

softwares

Replaceability

Facilidad y esfuerzo necesario para su uso en lugar de otro software para el mismo propsito y en el mismo entorno. Conformidad de la Portabilidad. Cumplimiento de los estndares relacionados con la aplicacin, con las convenciones y con las regulaciones establecidas por leyes y procedimientos.

Compliance

QA: news N10

Tabla. 5. Ejemplo de caractersticas y mtricas planteadas para evaluar la Calidad externa de un producto de software.

QA: news N10

Tabla 6. Correspondencia aproximada entre las caractersticas de calidad de ISO 9126 y los criterios del modelo de McCall.

QA: news N10

TMap Next (2006)

TMap (Test Management Approach) fue originalmente creado por Sogeti en 1995, adaptando los modelos de calidad ms comunes, y fue actualizado en el 2006 con un enfoque ms dirigido a procesos de negocio (TMap Next). Se trata en definitiva de una aproximacin adaptable y estructurada a los procedimientos y fases de testing, centrada en los procesos organizativos (business-driven test management, o BDTM), que incluye un conjunto de herramientas para la planificacin, el anlisis, la especificacin, la ejecucin y el reporte de las pruebas a las que puede someterse un software para detectar la presencia de errores y para verificar el cumplimiento de los parmetros de calidad establecidos. En cuanto a las caractersticas de calidad que TMap considera decisivas y ms utilizadas, sea cual sea el software que estemos evaluando, se muestran en la figura siguiente: Fig. 14 Caractersticas de calidad de TMap.

QA: news N10

Tabla 7. Correspondencia entre las caractersticas de calidad de TMap e ISO 9126.

Catlogos de Atributos Algunos autores, en lugar de proponer nuevos modelos de calidad se han limitado a estudiar cules han de ser los atributos de calidad que hemos de tener en cuenta como criterios de evaluacin del software o como guas durante el desarrollo del mismo.

QA: news N10

Barbacci ha propuesto una taxonoma de atributos para Performance (Desempeo), Dependability (Fiabilidad), Security (Proteccin) y Safety (Seguridad) que tiene en cuenta: Concerns: Parmetros bajo los cuales se evalan los atributos, especificados y medidos. Los requerimientos se expresan en trminos de estos parmetros, equivalente a los atributos de bajo nivel de los modelos vistos anteriormente. Attribute-specific factors: Propiedades del sistema (polticas, macanismos desarrollados dentro del sistema) y de su entorno que impactan en los Concerns. Methods: Mecanismos que se suelen usar para el manejo de los Concerns. general de los atributos de calidad segn Barbacci y

Fig. 15. Esquema colaboradores.

QA: news N10

Fig.16 Desglose de parmetros para Performance

QA: news N10

Fig. 17. Desglose de parmetros para Dependability

QA: news N10

Fig. 18. Desglose de parmetros para Security

Fig. 19. Desglose de parmetros para Safety

QA: news N10

Conclusin

Prcticamente todos los modelos establecen una jerarqua de componentes, donde los niveles altos representan objetivos de calidad a alcanzar, los niveles intermedios son las propiedades y atributos en las que pueden descomponerse los objetivos, o que pueden usarse como indicadores del grado de alcance de estos objetivos, y los componentes de bajo nivel suelen ser propiedades atmicas, muy concretas, o mtricas para poder medir o evaluar objetivamente (cuantitativamente si es posible) una propiedad o caracterstica determinada. Algunos modelos aportan como enfoque novedoso la separacin entre la calidad durante el desarrollo y el testing, y la calidad percibida por el usuario, o calidad en uso. ste es el caso de la ISO 9126. En todos los casos existe un esfuerzo clasificador que nos permita concretar y hacer medible aspectos del software que pueden llegar a ser muy subjetivos.

Tabla 8. Comparativa de los modelos ms utilizados de calidad de software.

QA: news N10

Bibliografa consultada o ISO/IEC 15939 (2002): Software Engineering Software Measurement Process. o IEEE Std 1061-1998 IEEE Standard for a Software Quality Metrics Methodology o IEEE 730 2002: Standard for Software Quality Assurance Plans. o IEEE 829 1998: Standard for Software Test Documentation. o IEEE 1012 2004: Standard for Software Verification and Validation. o IEEE 1061 1998: Standard for a Software Quality Metrics Methodology. o ISO/IEC 9126-2001 Software engineering Product quality. 2001. o Boehm, B. W., Brown, J. R., Kaspar, H., Lipow, M., McLeod, G., and Merritt, M., Characteristics of Software Quality, North Holland, 1978. o McCall, J. A., Richards, P. K., and Walters, G. F., "Factors in Software Quality", Nat.Tech.Information Service, no. Vol. 1, 2 and 3, 1977. o Dromey, R. G., "A model for software product quality", IEEE Transactions on Software Engineering, no. 2,pp. 146-163, 1995. Pressman 1998, captulo 18] R. S. Pressman. Ingeniera del software. Un enfoque prctico. 4 Edicin. McGrawHill (1998) TMap Next, for result-driven testing (Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon). UTN Publishers (Second Ed. 2007).

o Barbacci, Mario, Mark Klein, Thomas Longstaff, and Charles Weinstock. "Quality Attributes." Technical Report CMU/SEI-95-TR-021 ESC-TR-95-021. 1995. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA. o Wiegers, Karl E. Software Requirements, Second Edition. Redmond, WA: Microsoft Press, 2003

Para ms informacin: Antonio lvarez Analista Funcional Sogeti Espaa

antonio.alvarez@sogeti.com

También podría gustarte