CAPITVL05

CALIDAD DE PRODUCTO SOFTWARE

"Lo que ahoga a algllien no es caerse al rio, sino mantenerse sllmergido ell el"

Palilo Coelho

1. MODElOS CLAslCOS
Historicamente se han desarrollado para evaluar la calidad de los productos
software diferentes modelos que pretenden seguir las directrices de cali dad de otros tipos
de productos: descomponer la calidad en una categoria de caracteristicas mas sencillas que
facilita su estudio (Galin, 2004).

Uno de los modelos clasicos mas utilizados desde su creacion, incluso con vigencia
en nuestros dias, es el desarrollado por McCall (McCall et al., 1977), en el que la calidad
de un producto software se descompone en once caracteristicas 0 factores de calidad
agrupados en tres categorias (vease figura 5.1): Operacion de producto, Revision de
producto y transicion de producto.

A finales de los afios ochenta, fueron propuestos dos modelos altemativos a los de
McCall basados igualmente en la identificacion de factores: el modelo de factores de
Evans y Marciniak (1987) y el modelo de factores de Deutsch y Willis (1988).

En la tabla 5.1 puede encontrarse una comparativa entre los distintos modelos
donde se muestran los factores observados por cada uno de los autores en sus
correspondientes trabajos.

Otro modelo considerado como clasico es el reconocido como FURPS, acronimo

compuesto por las iniciales en ingles de las categorias Funcionalidad, Facilidad de uso,
Fiabilidad, Rendimiento y Capacidad del software; esta lista es una de las muchas
82 CAUDAD DE SISTEMAS ll\'FORt'vIATICOS ©RA-MA

adaptaciones y/o complementaciones del modelo de McCall que cada organizaclon ha

ideado para sus propios trabajos, como la dada por Grady y Caswell (1987) para Hewlett
Packard.

Vision de la direc!<.!c~i=o~n~~~~~====='V~i~s~io~n~de~l~d~e:s~a!.!.r!..!ro""I...,la",d",o,...r
Vision de usuario
Facilidad de uso- ~cr:;m~~I~~~1on
Comunicatividad
Seguridad (integrida Volumen y tasa de ElS
Operacion d Datos comunes
producto Eficiencia Control y audit. de acceso
Integridad de datos
Eficiencia de almacenam.
Eficiencia de ejecucion
Fiabilidad
Complecion
Trazabilidad
Revision de~ Facilidad de Consistencia
producto mantenimiento Precision
Facilidad de Tolerancia a errores

~~:~~~~i~li!!
P Concision
Flexibilida
rueba Autodescriptividad
Simplicidad
Modularidad
Transicion d~ Capacidad de Instrumentacion
producto reutilizacion Capacidad de ampliacion
Transportabilidat!7'"::::7C:::::::::=::~~~~ Generalidad
I Indep. maquina
Interoperabilida'lf'----------- ~~;!;jn~g:c.~eo~~t;~a

Figura 5.1. Modelo de calidad de McCall (1976).

EVA'1SY ..
FACIOR CALIDAD SOFT\VARE MCCALL (1916) l\:h:RCINIAl( I. DHJISCHyWILLrs(1988)
.. . . (1981) I .
Correccion ./ ./ ./
Fiabilidad ./ ./ ./
Eficiencia ./ ./ ./
Integridad ./ ./ ./
Usabilidad I ./ ./ ./
Mantenibilidad ./ ./ ./
Flexibilidad ./ . ./ ./
Testeabilidad ./
Portabilidad ./ I ./ ./
Reusabilidad ./ ./ ./
Interoperabilidad ./ ./ ./
Verificabilidad I ./ I ./
Expandibilidad ./ I ./
Seguridad de Uso ./
Manejabilidad ./
Capacidad de supervivencia I ./

Tabla 5.1. Comparacion entre modelos de calidad de producto software (Galin, 2004)
f:RA-MA. CAPiTULO 5: C.ALIDAD DE PRODUCTO SOFTWARE 83

En cualquier caso, todos estos modelos requieren identificar metric as para esas
caracteristicas de cali dad que penni tan medir cuantitativamente como de bueno es un
software atendiendo a esos criterios. El capitulo 9 de este libro pretende cubrir este
aspecto.

2. NORMAS ISO 25000

El SC7 de ISO esta desarrollando la familia de nonnas ISO 25000 (ISO 2005a-n)
conocida con el nombre de SQuaRE (Software product Quality Requirements and
Evaluation) que se organiza en cinco apartados (vease figura 5.2) y que sustituye y amplia
las actuales nOlmas ISO 9126 (ISO, 1991; Tecnologia de la Infonnacion -Calidad de un
producto software) y 14598 (ISO, 1999; Tecnologia de la Infonnacion- Evaluacion de un
producto software).

i i

Modelo de Calidad 2501 n

:
Requisitos de
I Evaluaci6n de
Calidad I Gesti6n de Calidad 2500n Calidad
2503n 2504n

j
Medici6n de Calidad
2502n

f~~~i~Y;!,/, 'W20T;r?!{~ ifi!3"&·'£'} ;~l;;t;? t;~~?;~'hi/';;(y':1?#J!z '%' '.i&4~

Figura 5.2. Organizacion de la familia de normas ISO 25000

@ ISOJIEC 2500n - Division de Gestion qe Calidad. Las nonnas que fonnan

este apartado definen todos los modelos, tenninos y definiciones comunes
referenciados por todas las oh"as nonnas de la serie SQUARE.
@ ISOJIEC 2501n - Division de Modelo de Calidad. La nonna de este apartado
presenta un modele de cali dad detallada incluyendo caracteristicas para calidad
interna, externa y en uso.
@ ISOJIEC 2502n - Dhision de Medici6n de Calidad. Estas nonnas incluyen
un modele de referencia de la medicion de la calidad del producto, definiciones
de medidas de calidad (interna, extern a y en uso) y guias practicas para su
aplicacion.
84 CALIDAD DE SISTEi\1AS INFORIvL~TICOS © RA.-ivLA.

e ISOIlEC 2503n - Division de Requisitos de Calidad. Estas nonnas ayudan a

especificar requisitos de calidad que pueden ser utilizados en el proceso de
elicitaci6n de requisitos de calidad del producto software a desaITollar 0 como
entrada del proceso de evaluaci6n.
e ISOIlEC 2504n -Division de Evaluacion de Calidad. Este apartado incluye
nonnas que proporcionan requisitos, recomendaciones y guias para la
evaluaci6n de productos software.

En el momento de redactar este libro, las diferentes nonnas de la familia ISO 25000
alin no se han tenninado de elaborar, por 10 que a continuaci6n se explican las nonnas
ISO 9126 e ISO 14598, ya que probablemente los conceptos basicos se mantengan con
pocos cambios significativos en las nuevas nonnas.

Necesidades
de calidad +---------- ~ Cali dad en uso
del usuario
Uso y
retroalimentaci6n
I t
Indica
Contribuye a especificar

~ I

Requisitos de Calidad
+-----------~
caUdad externa extern a
Validaci6n

I
Contribuye a especificar
i
Indica

~ I

Requisitos de
. CaUdad
+-----------~
caUdad interna interna
Verificaci6n

Figura 5.3. Perspectivas de calidad segun la norma ISO 9126

2.1. Aspectos de la calidad de un producto software

En la cali dad de un producto sofhvare, as! como en las metric as asociadas en las
diferentes etapas del cicio de vida del software, se sue len distinguir tres aspectos
diferentes (ver figura 5.3): calidad intema: medible a paItir de las caracteristicas
Q RA-tvL-\ CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 85

intlinsecas, como el c6digo fuente, extema; medible en el comportamiento del producto,

como en una pmeba; 0 en uso: medible durante la utilizaci6n efectiva por parte del
usuario en un contexto determinado.

Siguiendo la filosofia de los modelos clasicos de calidad de un producto software,

la nom1a ISO 9126 descompone la calidadjerarquicamente en una serie de caracteristicas
y subcaracteristicas que pueden usarse como una lista de comprobaci6n de aspectos
relacionados con la calidad.

2.2. Modelo de calidad interna y externa

II modelo de calidad para calidad intema y extema categoliza los atributos de
calidad software en seis caracteristicas (funcionalidad, fiabilidad, usabilidad, eficiencia,
mantenibilidad y portabilidad), que se subdividen a su vez en subcaracteristicas (figura
5.4), que se resume a continuaci6n (ISO, 2001).

Calidad externa e
interna

. :
Capacidad de ser
entendldo Capacidad de ser
Adecuaci6n Adaptabilidad
rv1adurez Capacidad de ser Comportamiento analizado
Exactitud Instalabilidact
Tolerancla a rallos aprendldo temporal Capacidad de ser
Interoperabilidad Coexistencia
Capacidad de Capacidad de ser Utilizacion de cambiado
Seguridad de Capacidad de ser
recuperac16n operado recursos Capacidad de ser
aeceSD reemplazado
Capecidad de probado
Cump!imiento de atraccion Cumplimiento de
Cumphmiento de Cumplimiento de
la fiabiHdad la eficiencia Cump!imiento de
la funclonalidad Ja portabilidad
Cumplimiento de la mantenibi!idad
la usabilidad

Figura 5.4. lVIodelo para la caUdad extern a e intern a (ISO, 2001)

2.2.1. FUNCIONALIDAD

Capacidad del producto software para proporcionar funciones que satisfacen

necesidades declaradas e implicitas cuando se usa bajo condiciones especificadas. Ista
caracteristica se subdivide a su vez en:
o Adecuacion. Capacidad del producto sofuvare para proporcionar un conjunto
apropiado de funciones para tareas y objetivos de usuario especificados.
86 CAUDAD DE SISTEMAS INFOR.!\1A.TICOS ©RA-MA

iii Exactitud. Capacidad del producto software para proporcionar los resultados 0
efectos correctos 0 acordados, con el grado necesario de precision.
iii Interoperabilidad. Capacidad del producto software para interactuar con uno
o mas sistemas especificados.
iii Seguridad de acceso. Capacidad del producto software para proteger
informacion y datos de manera que las personas 0 sistemas no autorizados no
puedan leerlos 0 modificarlos, al tiempo que no se deniega el acceso a las
personas 0 sistemas autorizados.
iii Cumplimiento funcional. Capacidad del producto software para adherirse a
normas, convenciones 0 regulaciones en leyes y prescripciones sirnilares
relacionadas con funcionalidad.

2.2.2. FIABILIDAD

Capacidad del producto software para mantener un nivel especificado de

prestaciones cuando se usa bajo condiciones especificadas. Esta caracteristica se subdivide
a su vez en:
• Madurez. Capacidad del producto software para evitar fallar como resultado
de fallos en el software.
iii Tolerancia a fallos. Capacidad del software para mantener un nivel
especificado de prestaciones en caso de fallos software 0 de infringir sus
interfaces especificados.
iii Capacidad de recuperacion. Capacidad del producto software para
reestablecer un nivel de prestaciones especificado y de recuperar los datos
directamente afectados en caso de fallo.
iii Cumplimiento de la fiabilidad. Capacidad del producto software para
adherirse a normas, convenciones 0 regulaciones relacionadas con la fiabilidad.

2.2.3. USABILIDAD

Capacidad del producto software para ser entendido, aprendido, usado y ser
atractivo para el usuario, cuando se usa bajo condiciones especificadas. Esta caracteristica
se subdivide a su vez en:
• Capacidad para ser entendido. Capacidad del producto software que permite
al usuario entender si el software es adecuado y como puede ser usado para
unas tareas 0 condiciones de uso particulares.
• Capacidad para ser aprendido. Capacidad del producto software que perrnite
al usuario aprender sobre su aplicacion.
£lRA-MA CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 87

• Capacidad para ser operado. Capacidad del producto software que pennite
al usuario operarlo y controlarlo.
• Capacidad de atracci6n. Capacidad del producto software para ser atractivo
al usuario.
• Cumplimiento de la usabilidad. Capacidad del producto software para
adherirse a nonnas, convenciones, guias de estilo 0 regulaciones relacionadas
con la usabilidad.

2.2.4. EFICIENCIA

Capacidad del producto software para proporcionar prestaciones apropiadas,

relativas a la cantidad de recursos usados, bajo condiciones determinadas. Esta
caracteristica se subdivide a su vez en:
• Comportamiento temporal. Capacidad del producto software para
proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados,
bajo condiciones determinadas.
• Utilizaci6n de recursos. Capacidad del producto software para usar las
cantidades y tipos de recursos adecuados cuando el software lleva a cabo su
funci6n bajo condiciones determinadas.
• Cumplimiento de la eficiencia. Capacidad del producto software para
adherirse a nonnas 0 convenciones relacionadas con la eficiencia.

2.2.5. MANTENmILIDAD

Capacidad del producto software para ser modificado. Las modificaciones podrian
incluir correcciones, mejoras 0 adaptaci6n del software a cambios en el entomo, y
requisitos y especificaciones funcionales. Esta caracteristica se subdivide a su vez en:
• Capacidad para ser analizado. Es la capacidad del producto software para
serle diagnostic ad as deficiencias 0 causas de los fallos en el software, 0 para
identificar las partes que han de ser modificadas.
• Capacidad para ser cambiado. Capacidad del producto software que pennite
que una detenninada modificaci6n sea implementada.
• Estabilidad. Capacidad del producto software para evitar efectos inesperados
debidos a modificaciones del software.
• Capacidad para ser probado. Capacidad del producto software que pennite
que el software modificado sea validado.
• Cumplimiento de la mantenibilidad. Capacidad del producto software para
adherirse a nonnas 0 convenciones relacionadas con la mantenibilidad.
88 CAUDAD DE SISTE?vLA.S fNrO~'vL'\TICOS © RA-?viA.

2.2.6. PORTABILIDAD

Capacidad del producto software para ser transferido de un entomo a otro. Esta
caracteristica se subdivide a su vez en:
G Adaptabilidad. Capacidad del producto software para ser adaptado a
diferentes entomos especificados, sin aplicar acciones 0 mecanismos distintos
de aquellos proporcionados para este proposito por el propio software
considerado.
G Instalabilidad. Capacidad del producto software para ser instalado en un
entomo especificado.
G Coexistencia. Capacidad del producto software para coexlstlr con otro
software independiente, en un entomo comun, compartiendo recursos
comunes.
G Capacidad para ser reemplazado. Capacidad del producto software para ser
usado en lugar de otro producto software, para el nusmo prop6sito, en el
mismo entomo.
• Cumplimiento de la portabilidad. Capacidad del producto software para
adhelirse a nonnas 0 convenciones relacionadas con la portabilidad.

2.3. Modelo de calidad en uso

La nonna ISO 9126 entiende por calidad en uso "fa capacidad def prodllcto
sofMare para pennitir a detenninados lIsliarios alcanzal' objetivos espectficados con
efectividad, prodllctividad, segllridad y satisfacci6n (figura 5.5), en contex:tos de lIS0
especificados".

La calidad en uso contempla las siguientes caracteristicas:

2.3.1. EFECTIVIDAD

Capacidad del producto software para pennitir a los usuarios alcanzar objetivos
especificados con exactitud y compleci6n, en un contexto de uso especificado.

2.3.2. PRODUCTIVIDAD

Capacidad del producto software para pennitir a los usuarios gastar una cantidad
adecuada de recursos con relaci6n a la efectividad alcanzada, en un contexto de uso
especificado.
~ RA-ivLA CAPiTIJLO 5: CAUDAD DE PRODUCTO SOFTWARE 89

Calidad de Uso

Figura 5.5. Modelo para la calidad en uso (ISO, 2005)

2.3.3. SEGURIDAD DE usa

Capacidad del producto software para alcanzar niveles aceptables del riesgo de
hacer dana a personas, al negocio, al software, a las propiedades 0 al medio ambiente en
un contexto de uso especificado.

2.3.4. SATISFACCION

Capacidad del producto software para satisfacer a los usuarios en un contexto de

uso especificado.

2.4. Evaluaci6n de un producto software

La nonna ISO 14598 da una vision general del proceso de evaluacion de un
producto software, explicando en sus diferentes partes como aplicar el proceso en
diferentes circunstancias. En la figura 5.6 (ISO, 1999) se resunie este proceso.

Esta nonna se apoya en la ISO 9126 ya que los aspectos cuantificables pueden
medirse cuantitativamente usando metricas de calidad, cuyo valor medido se sima en una
escala. La escala ha de dividirse en rangos que cOlTesponden a diferentes niveles de
satisfaccion de los requisitos. Por ejemplo:
G La division de la escala en dos categorias: satisfactOlio e insatisfactOlio.
G La division de la esc ala en cuatro categorias lirnitadas por el nivel actual de un
producto existente 0 altemativo, el peor caso y el nivel proyectado. El nivel
actual se declar·a con el fin de controlar que el nuevo sistema no suponga un
deterioro en relacion a la situacion actual. EI nivel proyectado es 10 que se
considera alcanzable con los recursos disponibles. El peor caso es la frontera
90 CAUDAD DE SISTEtvL">.S INFOR.,\V\ TICOS ©RA-MA

para aceptacion de! usuario por si acaso e! producto no cubre e! nive!

proyectado (figura 5.7).

Establecer Propos ito de fa Evaluaci6n

Establecer Requisitosl~I-_ _ _-4 Identificar los tipos de producto(s)

de Evaluaci6n

Especificar el modelo de caUdad 9126·1 Caracteristicas de Calidad

9126·2 Metricas Extemas

9126-3 Metricas Intemas
14598-6 Modulos de Evaluaci6n

Establecer niveles para las metricas

Establecer criterios de valoracion

Producir Plan de Evaluaci6n

Tomar medidas

Valorar Resultados

Figura 5.6. Proceso de evaluacion de un producto software (ISO, 1999)

niyel PlaneadO~
-
Excede los requisitos

val~~ satistbctorio
medido -=- Rango objetiyo
-
-
-
-
-
.
-
niyel actua~
-
-
- Minimanii!nte aceptabt~
-
-
el casu peo,--
insatistbctorio
-
-
-
- lnaceptabt~
-
-
-
escala de nii!dicion niveles de puntuaciOn

Figura 5.7. Rangos de una esc ala de medida (ISO, 1999)

<:: RA.-MA CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 91

3. TRABAJOS BASADOS EN LAS NORMAS ISO 9126 E

ISO 14598
Existen multitud de trabajos basados en las nonnas ISO 9126 e ISO 14598 que
puede ser de interes a la hora de plantearse la evaluacion de productos software. En este
apartado citamos algunos de los mas relevantes:
€I SQUID (Boegh, 1. et 01., 1999), pennite la especificacion, planificacion,
evaluacion y control de la calidad de software a tI'aves de los procesos de
desanollo. La calidad queda definida como un comportamiento operacional de
los productos requeridos por sus usuarios. Ofrece un metodo y una henamienta
de soporte que reciben el nombre de SQUID.
€I QUINT2 (Niessink, 2002) amplia el modelo de la ISO 9126 para evaluar la
calidad de arquitecturas software.
€I Bertoa et 01., (2005). Adaptan la nom1a ISO 9126 a los componentes COTS.
€I Losavio et 01. (2003) refinan el modelo de cali dad de la ISO 9126 para
arquitecturas software, llegando a proponer divers as medidas para los atIibutos
de calidad.
€I Franch y Carvallo (2003), y Botella et. al (2003), desanollan una metodologia
que conduce a la constmccion de modelos de cali dad especificos de dominio
en tenninos del estandar ISO 9126, y que han aplicado a paquetes software
COTS (commercial off-the-shelj). Esta metodologia consta de siete pasos
(figura 5.8):

O. Definir el dominio
1. Detenninar subcaracteristicas de calidad
2. Definir unajerarquia de subcaracteristicas
3. Descomponer subcaracteristicas en atIibutos
4. Descomponer atIibutos derivados (aquellos que no sean medibles
directamente) en atIibutos basicos
5. Establecer relaciones entI'e entidades de calidad (por ejemplo, aumentar
la subcaracteristica de seguridad lleva consigo que aumente la madurez
de un producto)
6. Detenninar metIicas para los atIibutos.

€I Simlo y Belchior (2003). Amplian las subcaracteristicas y atIibutos propuestos

por la nonna ISO 9126 llegando a identificar 124 atIibutos de calidad para los
componentes software.
€I Moraga et 01., (2005) proponen un modelo de calidad para portlets basada en
la adaptacion de ISO 9126 asi como en algunos de los trabajos anterionnente
citados.
92 CAUDAD DE SISTEMAS Il\1fOR,'vrA.TICOS ©RA-l\IA

Paso 1

Paso 3

Paso 4

Establecer Relaciones
Paso 5
entre entidades de calidad

Paso 6 Datarminar ivletricas

para los atributos

Figura 5.8. Metodologia para la construccion de modelos de calidad especificos de

dominio (Franch y Carvallo, 2003)

4. LECTURAS RECOMENDADAS
• Cechich, A., Piattini, M. y Vallecillo, A. (eds.) (2003). Component-Based
Sofnvare Quality: jvfethods and Techniques. Splinger Verlag LNCS 2693. En
esta recopilacion se abordan diversos aspectos de la calidad relativa a los
sistemas sofuvare basados en componentes.

5. SITIOS WEB RECOMENDADOS

• http://v{v{w.sei.cmu.edulsemaipresentations/zubrow/esepg/ Presentacion del
Sofnvare Engineering Institllte sobre IS.O 25000 Y el modelo CMMI.

6. EJERCICIOS
1. Compare las caracteIisticas y subcaracteIisticas de calidad del modelo de McCall
y de1l110delo propuesto en la nonna ISO 9126, (,cmille parece m1s completo?, (,a
que elementos de la calidad Ie concede 111<1S importancia McCall? y (,a cmiles la
non11a ISO 9126?, (,encuentra gran sil11ilitud entre ambos?

2. Como sefiala Kan (2003), los panimetros de satisfaccion del c1iente que
monitol1za IBM son: capacidad, funcionalidad, usabilidad, desel11pei'io, fiabilidad,
instalabilidad, l11antenibilidad, documentacion!infOlmacion, y servicio), mientras
GRA-?vLA,. CAPiTULO 5: CAUDAD DE PRODUCTO SOmVARE 93

que Hewlett-Packard utiliza: funcionalidad, usabilidad, fiabilidad, desempeiio y

servicio; compare estos panimetros con las caracteristicas de la nonna ISO 9126.

3. Tomando como base el proceso de selecci6n propuesto por la nonna ISO 14598,
defina un proceso de selecci6n para henamientas de amllisis y diseiio Olientado a
objetos, adaptando si fuera necesario el modelo de calidad de la ISO 9126.
Compare elmodelo definido con la nonna ISO 14102 (ISO, 1995).

4. Compare las diferentes propuestas existentes sobre modelos de calidad para

componentes (p.ej. Simao y Belchior (2003) 0 Bertoa et al. (2005)) analizando
que caracteristicas y subcaracteristicas de la nonna ISO 9126 se han adoptado tal
cual, l11odificado 0 descartado para este tipo de software.

5. Desanolle un proceso de analisis y selecci6n para sistemas de infonnaci6n

geognifica (SIG) teniendo en cuenta las caracteristicas distintivas de este tipo de
sistemas. Proponga a continuaci6n diferentes fonnas de medir las caracteristicas
propuestas.

6. Accediendo al portal de ISO (wlvw.iso.ch) investigue cual es la situaci6n actual

de las nOlmas de la familia ISO 25000, Y su trazabilidad respecto a las nonnas
ISO 9126 e ISO 14598.

7. Analice. utilizando una matriz, las diferentes interacciones que pueden darse entre
las subcaracteristicas del modelo de calidad de la ISO 9126. Por ejemplo, una
mayor funcionalidad podria influir en una men or facilidad de prueba.