QA: news – N10

Antonio Álvarez– Analista Funcional – Sogeti España

Septiembre 2012

Los Atributos de Calidad del Software

En este artículo se revisan y comparan los modelos de calidad más usados para
especificar los atributos de calidad del software y las métricas 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

Descomposición de la calidad del software en factores o atributos de calidad ..................... 4

Paradigma GQM (Objetivo-pregunta-métrica) ................................................................ 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
Catálogos de Atributos .............................................................................................. 31
Conclusión............................................................................................................... 36
Bibliografía consultada .............................................................................................. 37

De forma general, el conjunto de las pruebas (Testing) tiene como objetivo evaluar
la calidad de un producto, mejorándolo si cabe, mediante la identificación 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 análisis 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 cómo el sistema se comporta en su interacción con el usuario y su
entorno.
 QA: news – N10

Fig.1 Clasificación tradicional de las pruebas en Funcionales y No funcionales. Éstas

últimas son las más relacionadas con lo que aquí denominamos atributos de
calidad.

Sin dejar del todo esta perspectiva basada en la verificación de funcionalidades o de

comportamientos, podríamos 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 búsqueda 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 estándares y
específicos. Se centra en la performance y el funcionamiento óptimo en la
interacción con el usuario y con el entorno.
 QA: news – N10

El primer tipo también se suele denominar como V&V (Verificación y Validación). La

verificación responde a la pregunta “Estamos construyendo correctamente el
software?”, es decir, hemos de demostrar que la aplicación es conforme a su
especificación, 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 típicamente con el testing para la detección de errores.
Por otro lado, la validación responde a la pregunta “Estamos construyendo el
software correcto?”, es decir, la aplicación hace exactamente lo que el usuario
quiere que haga?. Se determina la corrección del producto respecto a las
necesidades del usuario. Tiene que ver típicamente con la adecuación 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 diseño hasta su retirada, pasando por su construcción.

Fig.2 Modelo en V de Evaluación del Software, relacionado fundamentalmente con

las pruebas de V&V.
 QA: news – N10

El segundo tipo de pruebas no se caracteriza por la detección de errores o

discrepancias, sino por la verificación 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 aplicación 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 detectaría errores en esta función, mientras que una
prueba del Tipo II daría un resultado negativo, indicando que esta función tendría
que mejorarse.

Otra aplicación puede funcionar correctamente y presentar las pantallas y los datos
con la velocidad suficiente, pero las opciones para el manejo de la aplicación se
pueden presentar en menús muy complicados, siendo difícil encontrar las opciones
o teniendo el usuario que pasar por numerosas pantallas para llegar a la
información que busca. En este caso tampoco se encontrarían errores en las
pruebas del primer tipo, pero algunas de las pruebas del segundo tipo nos darían
resultados negativos.

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

Descomposición de la calidad del software en factores o atributos de

calidad

A menudo, cuando se habla de calidad del software 1, tenemos que concretar cuáles
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 características, atributos o
factores, como por ejemplo:

1
Según 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 requirements 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 petición de
usuario con la velocidad apropiada.
 Usabilidad – Habilidad del software para satisfacer al usuario.
 Mantenibilidad – Habilidad del software para poder realizar cambios
en él fácilmente y
 con una adecuada proporción cambio/costo.
 Portabilidad – Habilidad del software para operar en diferentes
entornos informáticos.
 …, etc.

El estándar ISO/IEC 15939 define una Entidad como un objeto que puede ser
caracterizado mediante la medición del conjunto de sus atributos, y un Atributo
como una característica medible de una entidad. Para nosotros, en este artículo,
una aplicación o software o sistema informático es una entidad 2.

Según IEEE Std 1061 3 una Métrica de calidad de un software es una función
cuyas entradas son datos del software y cuyas salidas son valores numéricos que
pueden interpretarse como el grado en el cual el sofware posee un atributo que
afecta a su calidad.

Según ISO 9126 una Característica (atributo) de calidad de un software es

aquello que:

 Se muestra externamente al usar el software y es el resultado de atributos

internos.
 Es aplicable a cualquier tipo de software.
 Puede descomponerse en “subcaracterísticas”, dependiendo de sus atributos
o complejidad.
 Proporciona una terminología consistente para la calidad del producto
software.
 Proporciona un marco para especificar requisitos de calidad del software.

2
Para más detalles se puede consulta el estándar ISO/IEC Guide 99:2007 (más comúnmente conocido
como VIM), que recopila un conjunto de definiciones y términos relacionados con la ciencia de la
medición (metrología) en general y no sólo de la ingeniería del software.
3
El IEEE 1061 Standard for a Software Quality Metrics Methodology , define una metodología para llevar
a cabo la identificación, implementación, y evaluación de métricas para procesos y productos software,
válida 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 estándar no prescribe explícitamente
las métricas que tienen que utilizarse, sino que se limina sugerir el uso de métricas en la gestión de
proyectos de desarrollo e implantación de software, con objeto de mejorar la calidad del producto
obtenido.
 QA: news – N10

 Permite definir compromisos en cuanto a capacidades del producto software.

Según TMap (Sogeti) una característica de calidad es un descriptor de una

propiedad de un sistema informático.

Las características de calidad pueden subdividirse en:

 Calidad del proceso. Que sirven para supervisar la ejecución del proyecto,
midiendo tiempos y fases, y para evaluar y hacer el seguimiento de los
riesgos.
 Calidad del producto. Que se centran en las características del software, en
lugar de en el proceso seguido para su producción.

Fig.3 División básica de las características de Calidad en propias del producto y

propias del proceso.

Para determinar de qué forma se pueden medir estas características o atributos de

calidad se confeccionan las métricas, que nos indican qué parámetros concretos
hemos de detectar y cómo hemos de operar con ellos para llegar a algún tipo de
valor indicativo del grado de cumplimiento de la característica de calidad.

Una característica o factor de calidad se puede evaluar utilizando varias métricas,

de manera que constituye una combinación de éstas, y podría expresarse en una
fórmula como la siguiente:
 QA: news – N10

Fc= c1 * m1 + c2 * m2 + … + cn * mn

– ci factor de ponderación de la métrica i, que dependerá de cada aplicación

específica

– mi métrica i

Según Pressman (1998) las métricas para determinar los factores de calidad
pueden ser:

– Facilidad de auditoria

– Exactitud

– Normalización de las comunicaciones

– Completitud

– Concisión

– Consistencia

– Estandarización de los datos

– Tolerancia de errores

– Eficiencia de la ejecución

– Facilidad de expansión

– Generalidad

– Independencia del hardware

– Instrumentación

– Modularidad

– Facilidad de operación

– Seguridad

– Auto-documentación

– Simplicidad

– Independencia del sistema software

– Facilidad de traza

– Formación
 QA: news – N10

De todas formas, no siempre es fácil 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 guían en la descomposición
de nuestra idea genérica de calidad en una serie de propiedades (factores,
atributos, características) medibles y evaluables. Los modelos más 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. Cronología aproximada de aparición de los principales modelos de calidad del

software.
 QA: news – N10

De todos ellos, el modelo GQM está dirigido exclusivamente a la elucidación de

estos atributos de calidad, y no a su medición.

Por otra parte, el estándar CMM (Capability Maturity Model), elaborado por el SEI
(Universidad Carnegie Mellon), permite determinar la madurez de los procesos de
calidad relacionados con las tecnologías de la información en una organización e
identifica las prácticas clave requeridas para incrementar la madurez de los
mismos. El estándar 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 métricas, por lo que caen fuera del ámbito del
presente artículo.

Paradigma GQM (Objetivo-pregunta-métrica)

El GQM constituye una metodología para la definición 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): determinación de los objetivos de calidad

de alto nivel.
2. Nivel operacional (preguntas, questions): determinación de las preguntas que
hay que hacerse para comprobar que se están 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 característica 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 (métricas, metrics): se asocia un conjunto de métricas 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 usarán para su medición, así como el rango
de aceptabilidad.

Fig.5. Esquema que muestra las similitudes entre los modelos GQM e ISO 9126, en
cuanto a la descomposición de las características o atributos básicos de calidad
(objetivos o goals en GQM) en subcaracterísticas (Questions para GQM), y a la
determinación de las métricas 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 fórmula
empleada es como la siguiente:

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

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 métricas para evaluarlo, indicando los valores máximo y mínimo
aceptables.

Ejes, Factores y Criterios de McCall:

Factor / Propiedad Descripción

Operación del Producto (características operativas)

¿Es fácil y cómodo de manejar?. El esfuerzo requerido para aprender el

1 Usabilidad manejo de una aplicación, trabajar con ella, introducir datos y conseguir
resultados.

Facilidad de Operación

Facilidad de Comunicación

Facilidad de Aprendizaje

¿Es seguro? Puedo controlar su uso?. Grado con que puede controlarse
2 Integridad
el acceso al software o a los datos a personal no autorizado

Facilidad de Auditoría

Control de Acceso

¿Hace el software lo que yo quiero?. Grado en que una aplicación

3 Corrección 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
4 Fiabilidad de una aplicación lleve a cabo las operaciones especificadas y con la
precisión requerida

Precisión

Consistencia

Tolerancia a fallos
 QA: news – N10

Factor / Propiedad Descripción

Modularidad

Simplicidad

¿Se ejecutará sobre mi hardware y software lo mejor posible?. Cantidad

5 Eficiencia de recursos hardware y software que necesita una aplicación para
realizar las operaciones con los tiempos de respuesta adecuados.

Eficiencia en Ejecución

Eficiencia en Almacenamiento

Revisión del Producto (capacidad para soportar cambios)

¿Puedo arreglarlo? Es fácil localizar los fallos?. Esfuerzo requerido para

6 Mantenibilidad
localizar y reparar errores

Modularidad

Simplicidad

Consistencia

Concisión

Autodescripción

Facilidad de ¿Puedo probarlo?. Esfuerzo requerido para probar que la aplicación

7
Prueba cumple con los requisitos especificados.

Modularidad

Simplicidad

Autodescripción

Instrumentación

¿Puedo modificarlo?. Esfuerzo requerido para modificar una aplicación en

8 Flexibilidad
funcionamiento

Autodescripción

Capacidad de expansión

Generalidad
 QA: news – N10

Factor / Propiedad Descripción

Modularidad

Transición del Producto (adaptabilidad a nuevos entornos)

¿Podré reutilizar parte del software en otra aplicación?. Grado en que

9 Reusabilidad
partes de una aplicación pueden utilizarse en otras aplicaciones.

Autodescripción

Generalidad

Independencia del software

Independencia del hardware

1 ¿Puede comunicarse con otros sistemas?. esfuerzo necesario para

Interoperabilidad
0 comunicar la aplicación con otras aplicaciones o sistemas informáticos.

Modularidad

Compatibilidad de comunicaciones

Compatibilidad de datos

1 ¿Podré utilizarlo en otra máquina?. Esfuerzo requerido para transferir la

Portabilidad
1 aplicación a otro hardware o sistema operativo.

Autodescripción

Modularidad

Independencia del software

Independencia del hardware

En cuanto a las métricas, McCall propuso 41 métricas, la mayoría cualitativas o

subjetivas. En general, estas métricas se evalúan entre 0 y 10, aunque tratándose
de mediciones subjetivas dos evaluadores pueden proponer puntuaciones diferentes
para una misma métrica de un mismo sistema.

Métrica Descripción

Que el componente ejecutable proporcione documentación significativa.

Auto
 QA: news – N10

documentación

Completitud Implementación de todas las funciones requeridas.

Programa deber ser compacto en líneas de código, con un mínimo de

Concisión
elementos superfluos o no significativos.

Uso de métodos y procedimientos de diseño y técnicas de

Consistencia
documentación estandarizados durante el desarrollo.

Eficiencia en la
El tiempo de ejecución es el óptimo en función de la tarea ejecutada.
ejecución

Estandarización de La aplicación incorpora y maneja correctamente tipos abstractos de

los datos datos (TAD) a través del programa.

Exactitud Precisión en cálculos y control

Facilidad de
Comprobar la conformidad con los estándares.
auditoría

Facilidad de Facilidad de ampliar diseños arquitectónicos, de datos o

expansión procedimientos.

Facilidad de
Facilidad con la que el usuario puede operar el sistema.
operación

Facilidad para poder realizar ingeniería en reversa de tareas y

Facilidad de
funcionalidades. Facilidad para chequear la implementación correcta de
seguimiento
los requerimientos.

Debe poseer un buen sistema de ayudas para que los nuevos usuarios
Formación no encuentren muchas dificultades para aprender el manejo del
sistema.

Grado en que las funciones y componentes del sistema pueden ser

Generalidad
útiles en otras aplicaciones.

Independencia del Grado en que el software es independiente del entorno de hardware en

hardware el que se ejecuta.

Independencia del
Grado en que el software es independiente del entorno de software en
sistema de
que se ejecuta (especialmente en lo referente al sistema operativo).
software

Instrumentación Grado en que el programa funciona correctamente e identifica errores.

Modularidad División del programa en componentes funcionales.

Normalización de Grado en que se emplean estándares, interfaces, protocolos en la

 QA: news – N10

las comunicaciones implementación de la comunicación con otros sistemas y con el usuario.

Protección contra usuarios no registrados, y acceso correcto de los

Seguridad
usuarios autorizados.

Simplicidad Facilidad de entendimiento del sistema para el usuario estándar.

Tolerancia de
Grado de pérdida o corrupción de datos cuando se produce un fallo.
errores

Fig. 6. Esquema de las relaciones entre las métricas 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, Corrección,

Eficiencia, Interoperabilidad.
 Factores de calidad Internos: Mantenibilidad, Testabilidad, Flexibilidad,
Reusabilidad, Portabilidad.

Tabla 2. Métricas aplicables a los diferentes factores de calidad propuestos por

McCall:
 QA: news – N10

Por ejemplo, para aplicar las métricas asociadas al criterio de calidad “completitud”,
dentro del factor de calidad “corrección” tendríamos que usar la siguiente lista de
comprobación:

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 están definidas [R,D,I]
5. Se han definido todas las condiciones y procesamientos para cada punto de
decisión [R,D,I]
6. Concuerdan todos los parámetros de llamada a funciones definidos y
referenciados [D,I]
7. Todos los informes de problemas se han resuelto [R,D,I]
8. El diseño concuerda con los requisitos [D]
9. El código concuerda con el diseño [I]

Las letras R, D e I indican si la cuestión es aplicable a los requisitos (R), al diseño

(D) y/o a la implementación (I).

Se contesta a estas preguntas con un SI o NO, y luego se aplica la siguiente

fórmula que da como resultado el grado o nivel de calidad para dicho atributo:

De esta forma, la medida para la completitud es un número entre 0 y 1.

Fig.7. Grado de correlación entre los distintos factores. Circulos blancos indican
alta correlación (un alto grado de calidad en un factor implica probablemente un
alto grado de calidad en el otro) y circulos negros indican baja correlación.
 QA: news – N10

4
El modelo de Boehm (1978)

Este modelo define a la calidad de software mediante un conjunto de atributos

organizados jerárquicamente como características de alto nivel, de nivel intermedio
y de nivel primitivo.

Incluye características de desempeño (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 fácil de aprender y de usar para los usuarios habituales.
 Estar bien diseñado, bien codificado y puede ser probado y mantenido
fácilmente.

Las características de alto nivel representan las tres preguntas básicas que los
usuarios del software se hacen:

4
http://sunset.usc.edu/Research_Group/barry.html.
 QA: news – N10

1. Utilidad: ¿Cumple adecuadamente su función?.

2. Mantenimiento: ¿Es fácil de entender, modificar y volver a probar?.
3. Portabilidad: ¿Se puede seguir usando cuando cambia su entorno
de funcionamiento?.
Las características 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.
 Fácil de entender.
 Fácil de probar.
 Flexibilidad.

Fig.8. Jerarquía 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 línea y sensitiva al contexto, Material de entrenamiento,
Documentación del usuario y del administrador.
 Reliability (Confiabilidad): que incluye Frecuencia y Severidad de fallos,
Capacidad de recuperación, 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 recuperación, 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 internacionalización.

En general el modelo divide las llamadas categorías (equivalente a atributos o

factores de calidad) en dos tipos: Funcionales y No Funcionales. Estas categorías
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 categorías

relacionadas con el cumplimiento de normativas, con la
implementación/distribución y con la percepción del usuario (interfaz,
operatividad), como se ve en la tabla siguiente. De hecho, el (+) en el acrónimo
FURPS+ se ha incluido para especificar restricciones, como restricciones de diseño,
implementación 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 aplicación de

criterios de calidad tanto durante la verificación/validación 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 implicación 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 categorías o propiedades para determinar la calidad de

un producto:

1. Corrección
2. Cualidades internas
3. Cualidades contextuales
4. Cualidades descriptivas

Fig.9. Organización jerárquica de las relaciones de los elementos del modelo de

Dromey.

Fig. 10. Organización jerárquica de las propiedades (Factores) y atributos (criterios)

del modelo de Dromey.

5
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 diseño
y un modelo de calidad para la implementeación. 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)

6
ISO/IEC 9126 se subdivide en cuatro partes:

 ISO/IEC IS 9126-1:2001 QualityModel

 ISO/IEC TR 9126-2:2003 External Metrics
 ISO/IEC TR 9126-3:2003 InternalMetrics
 ISO/IEC TR 9126-4:2004 Quality in use Metrics

El modelo ISO/IEC 9126-1 se basó inicialmente en los modelos anteriores, como el

de McCall y Boehm, y se define mediante la especificación de características
generales del software que progresivamente se descomponen en subcaracterísticas,
que a su vez se componen de atributos, de manera que en la base de la jerarquía
tendremos atributos del software medibles mediante algún tipo de métrica.

6
Desde el 2005 el estándar 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 característica de calidad 7. Además se hace una
distinción 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. Jerarquía de características y atributos de calidad externa/interna.

7
En el enfoque del presente artículo, los atributos y las pruebas relacionadas con la funcionalidad los
consideraríamos como de Tipo I (enfocados principalmente en la detección de errores y discrepancias, en
lugar de centrarse en la mejora u optimización).
 QA: news – N10

Fig.13. Características para la calidad en uso.

Tabla 4. Definiciones de las características de calidad de ISO/IEC 9126-1

Nombre Descripción

8 Características relativas al cumplimiento del propósito básico para el

1 Funcionality
cual el software ha sido desarrollado

Adecuación. La función se ajusta al conjunto de tareas para las que

Suitability
fue creada.

Precisión. La función proporciona los resultados correctos, o

Accuracy
acordados.

Interoperabilit Interoperabilidad. El software puede interactuar correctamente con

y otros sistemas previamente especificados.

Seguridad. Habilidad para prevenir el acceso no autorizado a

Security programas y datos, y para facilitar el acceso a los usuarios
debidamente autorizados.

Conformidad de la Funcionalidad. Cumplimiento de los estándares

Compliance relacionados con la aplicación, con las convenciones y con las
regulaciones establecidas por leyes y procedimientos.

Confiabilidad. Características relativas a la capacidad del software

2 Reliability para mantener su nivel de desempeño bajo determinadas
condiciones y durante un periodo de tiempo establecido.

Maturity Madurez. Capacidad del software para evitar su caída como

8
Esta característica se evalúa 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.

Tolerancia a fallos. Habilidad para mantener un determinado nivel

Fault
de desempeño en caso de fallo o entradas no esperadas
tolerance
(manipulación inapropiada de su interfaz de usuario).

Capacidad de recuperación. 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 estándares

Compliance relacionados con la aplicación, con las convenciones y con las
regulaciones establecidas por leyes y procedimientos.

Usabilidad. Capacidad del software para ser entendido, aprendido y

3 Usability usado con facilidad, así como su capacidad para ser atractivo para el
usuario, bajo unas condiciones específicas.

Comprensibilidad. Esfuerzo que un usuario tiene que hacer para

Understandabi
entender la lógica y para usar el software para determinadas tareas
lity
y condiciones de uso.

Facilidad de aprendizaje. Esfuerzo que un usuario tiene que hacer

Learnability
para aprender el manejo de la aplicación.

Operatividad. La facilidad con que puede ser manejado y controlado

Operability
por los usuarios.

Atractivo. Capacidad del software para resultar atractivo para el

Attractiveness
usuario.

Conformidad de la Usabilidad. Cumplimiento de los estándares

Compliance relacionados con la aplicación, con las convenciones y con las
regulaciones establecidas por leyes y procedimientos.

Eficiencia. Características referentes a las relaciones entre el

4 Efficiency rendimiento y la cantidad de recursos empleados en unas
condiciones determinadas.

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 desempeño de una función.

Uso de recursos. Cantidad y tipo de recursos usados y duración de

Resource
este uso para el desempeño de una función bajo determinadas
utilization
condiciones.
 QA: news – N10

Conformidad de la Eficiencia. Cumplimiento de los estándares

Compliance relacionados con la aplicación, con las convenciones y con las
regulaciones establecidas por leyes y procedimientos.

Mantenibilidad. Características relacionadas con el esfuerzo

Maintainabilit necesario para hacer modificaciones, incluyendo correcciones,
5
y mejoras o adaptaciones a cambios en el entorno, nuevos requisitos
o especificaciones funcionales.

Analizabilidad. El esfuerzo necesario para el diagnóstico de las

Analyzability deficiencias or causas de los fallos, o para la identificación de las
partes que deben ser modificadas.

El esfuerzo necesario para la modificación destinada a la eliminación

Changeability del fallo o para un cambio en el entorno. Facilidad para implementar
una modificación específica.

Capacidad de evitar efectos inesperados resultantes de la

Stability
implementación de modificaciones.

Testability El esfuerzo necesario para la validación de las modificaciones.

Conformidad de la Mantenibilidad. Cumplimiento de los estándares

Compliance relacionados con la aplicación, con las convenciones y con las
regulaciones establecidas por leyes y procedimientos.

Portabilidad. Características relacionadas con la capacidad de

6 Portability transferir el software desde una organización o hardware o entorno
a otra/o.

Adaptability Facilidad para la adaptación a diferentes entornos especificados.

Esfuerzo necesario para instalar el software en un entorno

Installability
específico.

Capacidad del software para coexistir con otros softwares

Coexistence
independientes en un entorno común.

Facilidad y esfuerzo necesario para su uso en lugar de otro software

Replaceability
para el mismo propósito y en el mismo entorno.

Conformidad de la Portabilidad. Cumplimiento de los estándares

Compliance relacionados con la aplicación, con las convenciones y con las
regulaciones establecidas por leyes y procedimientos.
 QA: news – N10

Tabla. 5. Ejemplo de características y métricas planteadas para evaluar la Calidad

externa de un producto de software.
 QA: news – N10

Tabla 6. Correspondencia aproximada entre las características 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 más comunes, y fue actualizado en el 2006 con
un enfoque más dirigido a procesos de negocio (TMap Next).

Se trata en definitiva de una aproximación 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 planificación, el análisis, la especificación, la ejecución 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 parámetros de calidad
establecidos.

En cuanto a las características de calidad que TMap considera decisivas y más

utilizadas, sea cual sea el software que estemos evaluando, se muestran en la
figura siguiente:

Fig. 14 Características de calidad de TMap.

 QA: news – N10

Tabla 7. Correspondencia entre las características de calidad de TMap e ISO 9126.

Catálogos de Atributos

Algunos autores, en lugar de proponer nuevos modelos de calidad se han limitado a

estudiar cuáles han de ser los atributos de calidad que hemos de tener en cuenta
como criterios de evaluación del software o como guías durante el desarrollo del
mismo.
 QA: news – N10

Barbacci ha propuesto una taxonomía de atributos para Performance (Desempeño),

Dependability (Fiabilidad), Security (Protección) y Safety (Seguridad) que tiene en
cuenta:

 Concerns: Parámetros bajo los cuales se evalúan los atributos, especificados

y medidos. Los requerimientos se expresan en términos de estos
parámetros, equivalente a los atributos de bajo nivel de los modelos vistos
anteriormente.
 Attribute-specific factors: Propiedades del sistema (políticas, 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.

Fig. 15. Esquema general de los atributos de calidad según Barbacci y

colaboradores.
 QA: news – N10

Fig.16 Desglose de parámetros para Performance

 QA: news – N10

Fig. 17. Desglose de parámetros para Dependability

 QA: news – N10

Fig. 18. Desglose de parámetros para Security

Fig. 19. Desglose de parámetros para Safety

 QA: news – N10

Conclusión

Prácticamente todos los modelos establecen una jerarquía 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 atómicas, muy concretas, o
métricas para poder medir o evaluar objetivamente (cuantitativamente si es
posible) una propiedad o característica determinada.

Algunos modelos aportan como enfoque novedoso la separación 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 más utilizados de calidad de software.

 QA: news – N10

Bibliografía 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.

o Pressman 1998, capítulo 18] R. S. Pressman. Ingeniería del software. Un

enfoque práctico. 4ª Edición. McGrawHill (1998)

o 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 más información:

Antonio Álvarez – Analista Funcional – Sogeti España

antonio.alvarez@sogeti.com