Libro La Calidad Del SW y Su Medida

Jesús M.
" Miriguet Melian

11
!.
3wn Francisco HernBndez B a i l e t e ~ s

JESÚS M" M ~ G U E T MELIÁN
Profesor Titular de Lenguajes y Sistemas Informáticos (UNED)
JUAN FRANCISCO HERNÁNDEZ BALLESTEROS

Director del Servicio de Informática del Cabildo de Tenerife
LA CALIDAD
DEL SOFTWARE
Y SU MEDIDA
Reservados todos los derechos
Ni la totalidad ni parte de ese libro puede reproducirse o transmitirse por
ningún procedimiento electrónico o mecánico, incluyendo fotocopia, grabación
magnética o cualquier almacenamiento de información y sistema de recupera-
ción, sin permiso escrito de Editorial Centro de Estudios Ramón Areces, S. A.
O EDITORIAL CENTRO DE ESTUDIOS RAMON ARECES, S.A.

Tomas Bretón, 21 - 28045 Madrid
ISBN: 84-8004-611-2
Deposito legal: M. 44.635-2003
Impresión por:
LAVEL, S.A.
Humanes (Madrid)
Impreso en España 1 Printed in Spain

CAPÍTULO 1: LA CALIDAD DEL SOFTWARE ............................................ 23
1. El papel de la calidad en el desarrollo del software ...................................... 23
1.1. ¿Por qué calidad? .................................................................................... 23
1.2. La calidad en la industria del software ................................................... 24
2. Concepto de calidad ....................................................................................... 27
2.1. Definición de calidad .............................................................................. 27
2.2. Tipos de calidad ...................................................................................... 28
2.3. Rasgos inherentes a la calidad ................................................................ 29
2.4. Dimensiones de la calidad ...................................................................... 30
2.5. Las características de la calidad del software ......................................... 32
2.6. El Decálogo de la calidad ....................................................................... 33
3. Estados de desarrollo de la calidad ................................................................ 37
3.1. Inspección ................................................................................................ 37
3.2. Control de la calidad ............................................................................... 38
3.3. Aseguramiento de la calidad ................................................................... 39
3.4. Gestión de la Calidad Total .................................................................... 40
3.5. Evolución del concepto de calidad .........................................................41
4. Aproximación histórica................................................................................... 41
4.1. Artesanos y obreros ................................................................................. 42
4.2. Los orígenes ............................................................................................ 42
4.3. La Revolución Insustrial: la inspección ................................................. 43
4.4. De 1900 a 1950: la era del control estadístico ....................................... 44
4.5. El aseguramiento de la calidad: aparecen las normas ............................ 46
4.6. El presente: la gestión de la Calidad Total .............................................. 47
4.7. La industria del software y la industria tradicional ................................. 48
4.8. Orígenes del aseguramiento de la calidad del software .......................... 49
4.9. Las normas de calidad del software ......................................................... 52
4.10. Análisis de los atributos ......................................................................... 53
4.1 1. Los modelos ........................................................................................... 53
4.12. El futuro .................................................................................................. 55
5. Concepciones erróneas y paradigrnas de la calidad ...................................... 56
6. Costes de la calidad ........................................................................................ 57
6.1. Costes de prevención ............................................................................... 58
6.2. Costes de evaluación ................................................................................ 59
6.3. Costes de la no calidad ............................................................................. 59
6.4. Relación costeheneficio .......................................................................... 59
6.5. La Regla Federal Express ........................................................................61
CAPÍTULO 2: LA MEDIDA DE LA CALIDAD DEL SOFTWARE ...............63

1. Introducción.................................................................................................... -63
2. Necesidad de la medida del software.............................................................. 65
2.1. La medida como elemento de mejora metodológica .............................. 65
2.2. La medida y el conocimiento................................................................... 66
2.3. Importancia de la medida ......................................................................... 66
3. Estimación .......................................................................................................
68
. .
3.1. Definicion y problemática........................................................................
68
3.2. Los métodos de estimación ...................................................................... 69
LA CALIDAD DEL SOFTWARE Y SU MEDIDA 11
3.3. Las reglas de estimación de De Marco.................................................... 70

3.4. Evaluación de las estimaciones ............................................................... 71
4. Estimación de costes y esfuerzo .................................................................................
71
4.1. Definiciones de coste y esfuerzo ............................................................. 72
4.2. Los principales modelos ......................................................................... -72
4.3. COCOMO................................................................................................. 72
4.4. SLIM ......................................................................................................... 76
5. Medida ............................................................................................................ 78
5.1. Definiciones ............................................................................................. 78
5.2. Teoría general de la medida ..................................................................... 79
5.3. Escalas ..................................................................................................... 82
6. Aproximación histórica .................................................................................. 83
6.1. Los orígenes ............................................................................................ 83
6.2. Maurice Halstead...................................................................................... 83
6.3. El control de flujo de programa ............................................................... 85
6.4. Sistemas de diseño .................................................................................. 86
6.5. Costes y esfuerzos ................................................................................... -87
7. La medida del software .................................................................................. 89
7.1. Marco teórico ........................................................................................... 89
8. La norma ISOIIEC 9126 ................................................................................ 93
CAPÍTULO 3: NORMALIZACI~NY CERTIFICACI~N:

NORMA ISO 9001 :2000 ....................................................................................... 95
1.
. . . .
Normalizacion y certificacion........................................................................ 96
2. Terminología sobre calidad del software........................................................ 97
3. Los niveles de la calidad ................................................................................ 98
4. Los sistemas de calidad .................................................................................. 98
. .
4.1. Definicion.................................................................................................... 98
4.2. Partes del sistema ........................................................................................ 99
4.3. Manual de calidad ....................................................................................... 99
4.4. Los procedimientos................................................................................. 100
4.5. Registros de datos sobre calidad ............................................................. 101
4.6. El enlace con la calidad del proyecto ...................................................... 101
5. Calidad a nivel de proyecto.......................................................................... 101
5.1. Planificación del aseguramiento de la calidad en un proyecto ............... 101
5.2. El plan de aseguramiento de la calidad del software .............................. 102
5.3. Actividades de aseguramiento de la calidad ........................................ 103
6. Modelos contractuales de aseguramiento de la calidad ............................. 103
7. Proceso de certificación ............................................................................... 104
8. La familia de normas ISO:9000 ................................................................... 108
8.1. Antecedentes ............................................................................................ 108
8.2. La ISO 9000.2000. Razones para un cambio .......................................... 109
8.3. Principios del cambio............................................................................... 110
8.4. Las normas ISO 9000:2000 ..................................................................... 111
9. La norma ISO 9001 :2000 ............................................................................. 112
..
9.1. Introduccion a la norma ........................................................................... 112
9.2. Sistema de gestión de la calidad ............................................................. 113
9.3. Responsabilidad de la dirección ............................................................. 114
9.4. Gestión de los recursos ............................................................................ 114
9.5. Realización del producto o servicio ........................................................ 114
9.6. Medición, análisis y mejora .....................................................................115
10. La norma ISO 9004:2000............................................................................. 115
10.1. Introducción a la norma ......................................................................... 115
10.2. Responsabilidad de la dirección ............................................................ 116
. .
10.3. Gestion de los recursos .......................................................................... 116
10.4. Realización del producto o servicio ...................................................... 116

10.5. Medición, análisis y mejora .................................................................. 117
11. La calidad. su aseguramiento y medida según la norma
ISO 9001:2000 e ISO 9000-3:1997 ..................................................................... 117
CAPÍTULO 4: MODELOS. METODOLOGÍAS Y ESTÁNDARES:

ESTRATEGIAS PARA ALCANZAR LA CALIDAD ..................................... 121
1. Modelos. metodologías y estándares ........................................................... 121
1.1. Definiciones ............................................................................................. 121
2. El Modelo de Madurez de la Capacidad del Software ................................ 123
2.1. Los cinco niveles definidos en el modelo CMM ................................... 124
2.2. Áreas clave y características comunes .................................................... 128
2.3. La calidad. su aseguramiento y medida según el modelo....................... 131
3. Modelo BOOTSTRAP................................................................................. 134
3.1. El concepto Bootstrap. del diagnóstico a la solución ............................. 134
3.2. Práctica del modelo.................................................................................. 136
4. La norma ISO 15504 .................................................................................... 139
4.1. ISO 15504. un modelo.bidimensional..................................................... 141
4.2. La calidad. su aseguramiento y medida en la norma ............................. 146
5. Metodología MÉTRICA V. 3 ...................................................................... 147
5.1. MÉTRICA. una metodología basada en proceso ................................... 149
CAPITULO 5: MÉTRICAS PARA MODELOS CONCEPTUALES ............ 153

1. Modelos conceptuales .................................................................................. 153
1.1. Definciones .............................................................................................. 153
1.2. Calidad de los modelos conceptuales ...................................................... 154
2. Métricas para modelos conceptuales tradicionales ........................................155
2.1. Métricas de Kesh ..................................................................................... 155
14 INDICE
2.2. Métricas de Moody ................................................................................. 157

2.3. Métricas de Piattini ................................................................................. 159
3. Métricas para modelos conceptuales orientados a objetos ........................... 159
3.1. Métricas de Brito e Abreu y Carapuca.................................................... 159
3.2. Métricas de Chindamber y Kemerer ...................................................... 161
3.3. Métricas de Lorenz y Kidd ...................................................................... 162
3.4. Métricas de género y al ............................................................................ 163
CAP~TULO6: EL ANÁLISIS DEL PUNTO FUNCIÓN ............................... 165

1. Introducción al Análisis del Punto Función ................................................ 165
1.1. La propuesta de Albrecht: ventajas e inconvenientes ............................. 165
2. El Análisis del Punto Función paso a paso .................................................. 168
2.1. Determinar el tipo de conteo a realizar .................................................. 168
2.2. Identificar los límites en los que se aplicará el conteo de
los Puntos Función ................................................................................... 168
2.3. Identificación de los Ficheros Lógicos Internos (FLI) .......................... 169
2.4. Identificación de los Ficheros de Interfaz Externo (FIE) ....................... 170
2.5. Clasificar la complejidad de los ficheros lógicos y determinar
su contribución ....................................................................................... 171
2.6. Conteo de los tipos de función asociado a transacciones .......................... 174
2.6.1. Identificación de Entradas Externas ........................................................174
2.6.2. Identificación de Salidas Externas................................................ 176
2.6.3. Identificación de Cuestiones Externas ........................................ 177
2.6.4 Clasificar la complejidad de las transacciones identificadas y su
contribución .................................................................................. 179
2.6.5. Cálculo del valor de los Puntos Función sin ajustar .................... 185
2.6.6. Cálculo del valor del factor de ajuste ........................................... 187
2.6.7. Cálculo de los Puntos Función ajustados .................................... 188
3. Más allá del Análisis del Punto Función tradicional ..............................................192
CAPITULO 7: LA NORMA ISOIIEC 9126 Y LA MEDIDA

DE LA CALIDAD .............................................................................................. 193
1. Descomponer un problema para buscar la solución ................................ 193
1.1. La descomposición jerárquica en árbol ................................................... 194
1.2. Modelos de McCall y Boehrn ................................................................. 196
2. La norma ISO/IEC 9126 .............................................................................. 200
2.1. Calidad de uso, interna y externa ........................................................... 201
2.2. Medidas internas y externas .................................................................... 206
3. Procedimiento de medida propuesto ............................................................ 207
4. La medida de la fiabilidad de una aplicación informática.
Ejemplo práctico ........................................................................................... 211
4.1. Definición de requisitos de calidad ........................................................ 211
4.2. Preparar la evaluación .............................................................................. 213
.
4.2.1. Seleccion de métricas .................................................................... 214
r
4.2.2. Tasar .............................................................................................. 216

4.2.3. Valoración del criterio .................................................................. 217
4.2.4. Obtención de medidas ................................................................... 219
CAPITULO 8: MÉTRICAS DEL SOFTWARE ........................................ 221

1. Métricas e indicadores de la productividad................................................. 221
1.1. Medida del tamaño ................................................................................... 222
1.2. Medida de la productividad .................................................................... 227
2. Indicadores y métricas relacionadas con la calidad ................................... 230
2.1. Densidad de defectos e indicadores de calidad del proceso ................... 230
3. Fiabilidad ...................................................................................................... 232
4. Complejidad del software ........................................................................... 234
4.1. La Ciencia del Software de Halstead ...................................................... 234
4.2. La medida de la complejidad de McCabe ............................................... 235
4.3. La métrica de Henry y Kafura ................................................................ 237
5. Métricas para modelos de datos ................................................................... 240
5.1. Métricas a nivel de tabla ......................................................................... 240
5.2. Métricas a nivel de estrella ..................................................................... 240
5.3. Métricas a nivel de esquema .................................................................... 241
5.4. Calidad de los propios datos .................................................................... 242
6. Medidas del facilidad de uso de las interfaces de usuario .......................... 243
6.1. Clasificación de los métodos .................................................................. 243
6.2. Algunos métodos de evaluación ............................................................. 244
7. Medida de seguridad .................................................................................... 245
7.1. Un poco de historia ................................................................................. 246
7.2. SSE-CMM ............................................................................................... 247
7.3. Métricas de eficacia de los algoritmos criptográficos ............................ 248
7.4. Métricas de seguridad de red .................................................................. 250
LISTA DE SIGLAS
AENOR Asociación Española de Normalización y

Certificación.
APF Análisis del Punto Función.
ASA American Standards Association.
AS1 Análisis del Sistema de Información.
ATT American Telephone & Telegraph.
AWS American War Standards.
CE Cuestiones Externas.
CEN Comité Europeo de Normalización.
CIS Construcción del Sistema de Información.
CMM Capability Maturity Model.
COCOMO COnstructive COst Model.
DFP Punto Función del desarrollo del proyecto.
DSI Diseño del Sistema de Información.
DTR Draft Technical Report.
EE Entradas Externas.
ESPRIT European Strategic Program for Research and
Development
EVS Estudio de Viabilidad del Sistema.
FIE Fichero de Interfaz Externo.
FLI Fichero Lógico Interno.
GQM Goal Question Metrics.
GSC Características Generales del Sistema.
IAS Implantación y Aceptación del Sistema.
IBM International Business Machines.
IEC International Electrotechnical Commission.
IECISA Informática El Corte Inglés.
IEEE Institute of Electrical and Electronic Engineers.
IFPUG International Function Point Users Group.
IMT Inspección Media Total.
ISO International Organization for Standards.
JAN Joint Army-Navy Standard.
JTC Joint Technical Committee.
LCMS Límite de Calidad Media de Salida.
LOC Lines Of Code.
1X LISTA DE SIGLAS
MAP Ministerio de Administraciones Públicas.

METKIT Metrics Educational ToolKIT.
MIT Massachusetts Institute of Technology
MSI Mantenimiento de Sistemas de Información.
MTTF Mean Time to Faillure.
NASA National Aeronautics and Space Administration.
OTAN Organización del Tratado del Atlántico Norte.
PSI Planificadn de Sistemas de Información.
SAG Software A.G.
SE Salidas Externas.
SE1 Software Engineering Institute.
SPICE Software Process Improvement and Capability
dEtermination.
TED Tipos de Elementos de Datos.
TER Tipos de Elementos de Registros.
UFC Puntos Función sin Ajustar.
VAF Valor del Factor de Ajuste.
WG Working Group.
La sociedad actual reclama productos y servicios informáticos que den
respuesta a sus necesidades, requisitos cada vez más exigentes en un mercado
globalizado de altísima competitividad. La respuesta de las empresas debe
sustentarse en el disciplinado ejercicio de metodologías que tengan en la calidad un
instrumento eficaz para responder a este desafío.
Los programas informáticos, el software, es el valor añadido de mayor

trascendencia en las industrias de principios del siglo XXI. Sin este componente el
instrumental más sofisticado o el ordenador más complejo carece de valor,
relegado a un amasijo de cables y circuitos electrónicos sin utilidad.
La ingeniería del software como disciplina nacida hace casi cuarenta años como
respuesta a la llamada "crisis de la programación" asume las estrategias de las
ingenierías tradicionales y trata de utilizarlas adaptándolas a la fabricación de
programas para ordenador. Esta misma ingeniería que busca en modelos de calidad
tradicional su más fiel aliado debe proseguir en la mejora continua de sus procesos.
Dentro de esta mejora se encuentra, sin duda, la obtención de medidas adecuadas a
las entidades y atributos que le son propios. Medir implica conocer y conocer
permite manipular aquellos factores de interés en la búsqueda de la excelencia.
Medir la calidad es, por tanto, un requisito imprescindible en las nuevas
metodologías del software y un factor estratégico en el sector de la nueva
economía.
Nos encontramos ante un reto, uno más en esta civilización en constante

cambio, en constante evolución. Un reto que, sin duda, exige un decidido apoyo a
la investigación y a las tecnologías de la información y las comunicaciones. La
divulgación científica es un camino seguro en la consecución de un conocimiento
global. Nos permite el intercambio de información, comprender y ser comprendido,
explicar y entender. Por todo esto es seguro que el reto al que nos enfrentamos
estará culminado con el esfuerzo y la superación que no son más que una etapa
intermedia hacia el éxito.
Ricardo Melchior Navarro

Presidente del Excmo. Cabildo Insular de Tenerife
Nada puede torcer el camino de la verdad y la calidad, porque éstas adelgazan y no
quiebran y siempre andan sobre la mentira y la falta de industria, como el aceite sobre el
agua 1
El resultado final del proceso creativo humano en la industria tradicional se

materializa en un objeto físico, electrodoméstico, aeroplano, automóvil etc. Este
concepto desaparece en la ingeniería del software cuyo principal producto es un
ente inmaterial, del cual sólo apreciamos sus resultados al ser ejecutado sobre un
soporte físico, el ordenador. Este es un hecho de capital importancia que
condiciona la concepción de la ingeniería del software. Bajo esta consideración el
software no se fabrica, se desarrolla, tal como apunta Pressman, haciendo uso de un
proceso secuencia1 compuesto de diferentes etapas que culmina con la creación del
programa informática.
La medida de un proceso productivo o de los atributos de un producto
elaborado, es en la actualidad una actividad estratégica en las empresas de
cualquier sector productivo. La ingeniería del software requiere y exige de estas
medidas no limitándose a la implantación de metodologías aunque éstas abarquen
todo el proceso productivo de una aplicación informática e incluso su posterior
mantenimiento. Medir es necesario, mas allá, es imprescindible para la ingeniería
del software igual que lo es para cualquier otra ingeniería. Medir, y en concreto
medir la calidad, permite obtener información sobre atributos cuyo conocimiento
aportan ventajas estructurales a aquella empresa o profesional que los poseen
permitiendo la ejecución de acciones correctoras sobre datos objetivos y
disfunciones perfectamente identificadas. La medida del software nos proporciona
valiosa información sobre el proceso de desarrollo, los productos resultantes o los
recursos utilizados. Hacer uso adecuado de esa información nos brinda la mejora
intrínseca del propio proceso creativo modificándolo si fuera preciso.
El software, la ingeniería del software, modelos de desarrollo, metodologías y la
medida de entidades se encuentran íntimamente unidos y deben colaborar en la
obtención de productos y servicios de calidad.
En el capítulo 1 se introducirán los conceptos básicos de calidad en la industria
tradicional y su traslado a la industria del software. Se revisará la evolución del
concepto de calidad a lo largo de la historia y se comprobará el atraso histórico
que, en términos de calidad, tiene la fabricación del software con respecto al resto
' Miguel de Cervantes Saavedra. Don Quijote de la Mancha

de las industrias. Finaliza el capítulo con los costes que suponen la implantación de
un sistema de gestión de la calidad en los procesos de producción o servicios.
El capítulo 2 se centra en el problema de la medida. Tras discutir la necesidad
de medir el software, se definen los conceptos básicos y se introduce la teoría de la
medida. Se repasa históricamente la evolución de la medida de atributos propios
del software. Finalmente se presenta un marco teórico válido para la medida del
software y de la calidad como atributo. Se introduce el modelo ISOIIEC 9126.
En el capitulo 3 estudiaremos los conceptos de normalización y certificación
asociados a la calidad del software. Como norma internacional de gran
implantación se presentará en detalle la familia de normas ISO 9000.
El capítulo 4 trata de las estrategias para alcanzar la calidad mediante diversos
modelos, metodologías y estándares. Se profundiza en el estudio de los modelos
CMM y Bootstrap, el estándar ISO 15504 y la metodología MÉTRICA Versión 3.
Estos modelos y metodologías se han escogido por su impacto histórico y su
elevado nivel de implantación en numerosos países, son una referencia básica en el
estudio de la calidad del software y su normalización.
En el capítulo 5 se estudian las métricas asociadas a modelos conceptuales,
estos modelos permiten enlazar los requisitos de los usuarios y la solución
software. Se estudiarán las métricas correspondientes a modelos tradicionales y
orientados a objeto.
El capítulo 6 profundiza en una técnica para medir la funcionalidad de las
aplicaciones informáticas, entendida ésta como el conjunto de funciones aportadas
al usuario por el producto informático. Esta técnica es el Análisis del Punto
Función. Su inclusión como un capítulo aparte se justifica por la importancia
creciente de esta medida y representar un avance conceptual y práctico en la
cuantificación del software.
En el capítulo 7 se presenta un estudio exhaustivo de la norma ISO 9126, ya
introducida en el apartado 2. En este mismo capítulo se explica el procedimiento
propuesto para medir cualquier atributo propio del software.
En el capítulo 8 se hace un repaso las medidas más interesantes actualmente
utilizadas en la industria del software. Este repaso es limitado y aborda aquellas
medidas que supusieron un avance en la historia del software o son habitualmente
utilizadas por empresas del sector.
Aunque el origen de este libro era servir de texto para la asignatura "Calidad del
Software" de 5" curso de Ingeniería Informática de la UNED, los autores han
pretendido que también pueda servir a los profesionales de la informática como una
base para la implantación de la calidad en sus productos.
Quizás se le encuentren fallos u omisiones, debidos en gran parte a la necesidad
de que estuviera editado para el inicio del curso, pero los autores tienen la
intención de ampliarlo en futuras ediciones. En este momento iniciamos esta labor.
Julio 2003
Los autores
Capítulo 1
LA CALIDAD DEL SOFTWARE

La calidad tiene la estructura de un águila bicéfala (...)
porque al mismo tiempo que un paradigma, que un ejemplo,
la calidad se ha convertido en un gran tópico.'
La industria del software, como tal industria, tiene muchas de las características
de la industria tradicional, entre ellas la necesidad de que sus productos sean de
calidad. En este capítulo se tratará del concepto de calidad, de sus características y
de sus diferentes estados a través de los tiempos, para terminar con un breve
estudio sobre los costes y beneficios que conlleva la implantación de un sistema de
calidad.
1. EL PAPEL DE LA CALIDAD EN EL DESARROLLO DEL SOFTWARE
1.1. ¿Por qué calidad?
Tanto en los medios de comunicación escritos y audiovisuales como en las

revistas técnicas el tema de la calidad tiene una presencia continuada; incluso los
políticos y gobernantes incluyen el término en sus discursos y proyectos. Todo ello
es debido al papel fundamental que la calidad juega en la competitividad de las
empresas y a que se ha acabado el tiempo en que la demanda superaba a la oferta y
el cliente tenía que conformarse con lo que le ofrecían. Hoy en día, los oferentes de
productos y10 servicios deben adaptarse a las necesidades, gustos y exigencias de
' López Cachero, M. 11 Jornadas de Calidad del Software, organizadas por la Asociación de Técnicos de
Informática. Madnd 2 y 3 de julio de 1998.
24 LA CALIDAD DEL SOFTWARE
los potenciales clientes para mantenerse en el mercado. Incluso la Comunidad

Europea propone la necesidad de la evaluación y certificación de los productos
europeos, la calidad europea, como medio para evitar su discriminación en los
mercados internacionales.
La necesidad de producir productos de calidad es una realidad evidente exigida
por un mercado abierto, enormemente competitivo y en constante evolución. Tal
como Edward yourdon2 expone "... la posibilidad de que los usuarios finales sean
demasiado exigentes puede explicarse por la presión empresarial a la que están
sometido^"^.
Existen varias razones que justifican el por qué la calidad es crítica para la
supervivencia de las empresas:
o La calidad es un factor competitivo.

o La calidad es esencial para el comercio internacional.
o La calidad reduce las pérdidas pr~ducidaspor la no calidad.
o La calidad mantiene a los clientes e incrementa los beneficios.
o La calidad es el sello distintivo de los negocios de nivel mundial.
1.2. La calidad en la industria del software
La exigencia de la calidad no es sólo para los productos materiales, también lo

es para los productos inmateriales, los llamados servicios. Dentro de estas
empresas de servicio se encuentran las empresas desarrolladoras de software; y las
principales de ellas han apostado por la calidad como demuestran las siguientes
consignas o tesis:
"Si no mantenemos nuestro ímpetu en el aspecto de la calidad, los

japoneses nos adelantarán". Hewlett-Packard.
"El crecimiento no es nuestro objetivo principal. Nuestro objetivo ha de ser

una organización de calidad, lo cual significa que nos sentiremos orgullosos de
nuestro trabajo y de nuestros productos en los años venideros. A medida que
alcancemos la calidad, el crecimiento vendrá por añadidura". Digital.
'Yourdon, Edward. Investigador ampliamente conocido por idear el método estructurado de análisis y diseño, así
como ser coautor del método denominado CoadIYourdon para programación orientada a objeto en los años
noventa. Autor de más de quinientos artículos y veinticinco libros es licenciado en matemáticas por el MIT y el
Instituto Politécnico de Nueva York. Consultar el sitio http://www.vourdon.com.
'Yourdon Edward, "Lo bueno..¿es lo mejor?", Byte, no 22, octubre 1996. pág. 154.
Las empresas de software se ven obligadas a implantar modelos y metodologias

propias del aseguramiento de la calidad del software generalmente culminados con
la obtención de certificaciones emitidas por organismos de carácter internacional.
Estas certificaciones son exhibidas como muestra de la excelencia de sus procesos
productivos y se entienden como un mecanismo necesario, aunque no suficiente,
para la captación de nuevos clientes o el mantenimiento de los ya existentes. La
4
calidad es un "principio que no es ni social ni culturalmente bueno discutirm .
Sin embargo la gestión de la calidad se enfrenta a severos obstáculos de difícil
superación. Si bien es patente la existencia de un consenso generalizado que nos
indica un grado de concienciación sobre este tema, no es menos cierto que esta
sensibilidad muchas veces se acerca más a una actitud estética que a un verdadero
compromiso con los principios básicos que rigen esta disciplina. López Cachero
sentencia "... Pero cuando se trata de ponernos de acuerdo en discutir qué es la
calidad, cómo se lleva a cabo hasta sus últimas consecuencias, empiezan los
problemas"5.
Este hecho, unido a la dificultad de objetivar atributos asociados a la calidad o a
su control, han provocado numerosas frustraciones en aquellas empresas que
emprendieron procesos de gestión de la calidad sin la debida preparación y
conocimiento. En numerosos casos el propio concepto de calidad es mal entendido
o no adecuadamente utilizado. Este hecho se ve agudizado en una disciplina cuyo
resultado es la creación de una entidad inmaterial, el programa informático, de
características sui géneris muy distintas al resultado de los procesos productivos
tradicionales.
La necesidad de implantar procedimientos y modelos que permitan el control y
aseguramiento de la calidad, así como la falta de un consenso generalizado sobre
esta disciplina, ha tenido como resultado la aparición de numerosos modelos
propios del aseguramiento de la calidad del software. Se pueden citar más de una
decena de estos modelos generados por universidades, asociaciones de carácter
trasnacional y organismos públicos. CMM, ISO 9000, BOOTSTRAP, SQAM,
proyecto ALVEY, MÉTRICA, ISO/IEC 9126, proyecto SPICE, son sólo algunos
ejemplos de los numerosos esfuerzos realizados en esta dirección.
La calidad del software adolece de la inexistencia de un punto de vista unificado
que simplifique y dé coherencia a los modelos existentes permitiendo su
equiparación en objetivos y resultados.
López Cachero, M. 11 Jornadas de Calidad del Software, organizadas por la Asociación de Técnicos de
Informática. Madrid 2 y 3 de julio de 1998. Registro en audio realizado por nosotros.
López Cachero, M. 11 Jornadas de Calidad del Software, organizadas por la Asociación de Técnicos de
informática. Madrid 2 y 3 de julio de 1998. Registro en audio realizado por nosotros. López Cachero, Manuel.
Rector de la Universidad Alfonso X el Sabio y presidente de la Asociación Española de Normalización y
Certificación, AENOR.
La medida del software se considera, igualmente, una necesaria consecuencia de

la adopción de una estrategia propia de las ingenierías tradicionales en el desarrollo
de los programas informáticos, ya puesto de manifiesto en la conferencia de
Garmisch en 1968. Medir atributos propios del software y su proceso creativo, es
una necesidad aceptada por teóricos y profesionales que consideran esta actividad
normal en el control del proceso y del producto software. Sin embargo este
compromiso se encuentra con serias disfunciones consecuencia, igualmente, de la
fragilidad del mismo.
La implantación de procedimientos de mejoras sin la obtención de medidas
rigurosas era una práctica habitual en las empresas del sector. Este hecho es
considerado por algunos autores como Fenton, Gibbs o Tom deMarco una de las
causas más importante de la situación actual en el desarrollo de programas para
ordenador.
La medida del software se limita, en numerosos casos, a la obtención de datos
estadísticos sobre la satisfacción del cliente sin entrar en conceptos más propios del
software y sus atributos tales como la fiabilidad, madurez, estabilidad, etc. La
medida del software se encuentra lejos de ser una verdadera cuantificación de los
atributos de procesos o productos, limitándose a la acumulación de cantidades
resultado de medidas realizadas sobre atributos poco definidos con el fin de obtener
una base de datos histórica sobre la que aplicar diferentes herramientas
matemáticas de naturaleza estadística. Un claro ejemplo de este hecho es el uso del
análisis del punto función con el fin de estimar esfuerzos en la realización de
aplicaciones informáticas. Sin embargo, esta situación está cambiando.
La obtención de medidas estrictas que representen y cuantifiquen atributos
claramente identificados de entidades propias del software y su proceso de creación
es una necesidad que estudiosos y profesionales ya no ponen en duda.
La medida del software y los modelos de aseguramiento y administración de la
calidad del software son la base de una pirámide cuya cúspide es el control del
proceso de creación de aplicaciones informáticas.
Como colofón de lo expuesto no debe olvidarse que la calidad de los productos
y servicios depende en gran manera de la calidad de los profesionales que los
diseñan, organizan y controlan. Si siempre se ha dicho que "el principal capital de
una empresa u organización lo constituyen sus recursos humanos", hoy día es más
cierto que nunca, como reconoce la Comisión Europea:
"En última instancia, las expectativas de Europa descansan sobre el potencial

intelectual técnico de su población y especialmente de las generaciones más
jóvenes. Por ello, la inversión en capital humano en general y en educación y
capacitación en particular deben ocupar un lugar destacado en la agenda de todos
los estados miembros."
2. CONCEPTO DE CALIDAD
2.1. Definición de Calidad
Con objeto de estudiar la medida de la calidad del software se hace

imprescindible definir este atributo. No es difícil encontrar más de una decena de
definiciones aportadas por instituciones, estudiosos y organizaciones propias del
ámbito tradicional de la prestación de servicios o del suministro de bienes
manufacturados.
La Real Academia Española de la Lengua define el concepto "calidad" como6 :
Calidad (del lat. Qualitas, -atis y este calco del griego poiothz) .f. Propiedad o
conjunto de propiedades inherentes a algo, que permiten juzgar su valor. 2. Buena
calidad, superioridad o excelencia. 3. Carácter, genio, índole. 4. Condición o
requisito que se pone en un contrato. 5. Estado de una persona, naturaleza, edad y
demás circunstancias y condiciones que se requieren para un cargo o dignidad. 6.
Nobleza del linaje. 7. Importancia o gravedad de algo. 8. pl. Prendas personales 9.
Condiciones que se ponen en algunos juegos de naipes.
Según María ~ o l i n e rcalidad,

~, en sentido amplio, equivale a "cualidad"
Como se puede observar las acepciones del término son muy variopintas,
aunque añadiremos aquellas que se encuentran en los textos que tratan de la
calidad, tal como se entiende en los ámbitos empresariales, tales como:
o Grado en el que un conjunto de características inherentes cumple con los

requisitos8.
o El conjunto de actividades encaminadas a descubrir y satisfacer las
necesidades de un colectivo o de una sociedad en general9.
o Satisfacción del cliente y conformidad con sus requisitos y necesidades'' .
o El grado de satisfacción que produce al cliente" .
'Real Academia Española. Diccionario de la lengua española. 22" Edición. Madrid, 2001. Pág. 401.
' María Moliner. Diccionario de uso del Español. Editorial Gredos S.A. Madrid, 2000. Pág. 224.
UNE-EN ISO 9000. Sistemas de gestión de la calidad. Fundamentos y vocabulario. AENOR. Madrid, 2000. Pág.
16.
Sebastián Pérez, Miguel Ángel; Bargueño Fariñas, Vicente; Novo Sanjurjo, Vicente. Gestión y Control de
calidad. Cuadernos de la V E D . Madrid. UNED. 1994. Pág. 15.
' O Sebastián Pérez, Miguel Angel; Bargueño Fariñas, Vicente; Novo Sanjurjo, Vicente. Op. Cit. Pág. 15.
"JOC Sanders y Eugene Curran. Software Quality. A Framework for Success in Software Development and
Support, Centre for Software Engineering, Dublin, Addison-Wesley Publishing Company, 1994. Pág. 3. La
traducción es nuestra.
o El proceso de identificar, aceptar, satisfacer y superar constantemente las

expectativas y necesidades de todos los colectivos humanos relacionados
con la empresa (clientes, empleados, directivos, propietarios, proveedores y
la comunidad) con respecto a los productos y servicios que proporciona'2.
En el caso del software y su proceso de creación, consideraremos como

definición de calidad la propuesta por la norma ISO 9000:2000. El proceso de
creación de programas o el producto informático en sí, no se diferencian, en cuanto
a objetivos a alcanzar, de aquel que debe cumplir cualquier otro servicio o producto
ofrecido por la industria tradicional.
La definición propuesta es de ámbito general pero nos permite afirmar que la
calidad debe ser impuesta por los requisitos que ha de cumplir el producto o
servicio, hecho que en el caso de los programas para computador pueden ser
subjetivos y de difícil concreción. El problema de la medida de la calidad del
software se ha trasladado, por tanto, a la medida de los requisitos a cumplir por la
aplicación informática y el grado en que ésta las satisface. Estos requisitos serán
estudiados más adelante.
2.2. Tipos de Calidad
En los ámbitos industriales en general, y en los informáticos en particular,

circulan numerosas historias jocosas de cómo lo que se proporciona al cliente no
tiene nada que ver ni con lo que éste ha solicitado ni con el diseño inicial.
Por ello podemos distinguir tres tipos de calidad relacionados entre sí: calidad
necesaria, calidad programada y calidad realizada.
Calidad necesaria. Es la calidad que pide el cliente y la que le gustaría recibir.
Calidad programada. Es el nivel de calidad que se propone obtener el

fabricante.
Calidad realizada. Es la calidad que se puede obtener debido a las personas

que realizan el trabajo o a los medios utilizados.
''Arthur Andersen. La Calidad en España. Cinco Días. Madrid, 1995. Pág. 28.
/
n CALIDAD
REALIZADA \
\ CALIDAD
PROGRAMADA
y CALIDAD /
Figura 1.1. Los tres tipos de calidad.
Podemos representar estas calidades como tres círculos que se cortan. Lo que la
gestión de la calidad pretende conseguir es que el área común sea la mayor posible,
incluso que lleguen a coincidir para evitar insatisfacciones y gastos superfluos.
A veces se habla de calidad percibida, que no tiene que coincidir con la
realizada, ya que depende de la subjetividad de algunas de las características, por
ejemplo la estética, y es debido a que los usuarios no disponen de la información
completa. En estos casos los productos o servicios se evalúan más por su nombre
de marca o la publicidad que por sus características objetivas. La calidad percibida
es el grado de calidad que el cliente cree que tiene el producto o servicio. Al ser
subjetiva del cliente, el sistema de gestión poco puede hacer para que la calidad
percibida sea igual a la realizada, salvo incrementar la comunicación a fin de
conseguir la convergencia.
2.3. Rasgos inherentes a la calidad
Algunos de los rasgos más sobresalientes de la calidad son:
0 Implica la mejora continua de la productividad y de la competitividad.

O Significa hacer las cosas bien a la primera.
O Consiste en dar al cliente lo que éste desea.
0 Se basa en el sentido común.
Involucra a todos los niveles de la empresa.
Las consecuencias de la implantación de un sistema de calidad son:
o Mejora de la imagen de la empresa.

o Apoyo al marketing.
o Favorece el espíritu de equipo.
o Genera valor añadido.
o Genera crecimiento sostenido basado en la excelencia.
o Es una inversión sin riesgo.
2.4. Dimensiones de la calidad
El modelo que representa la calidad se configura mediante un conjunto de

dimensiones, también llamados factores o características, que son independientes
entre sí. Un producto puede tener un valor alto en una dimensión y bajo en otra.
Estas dimensiones varían según los diversos autores.
A continuación presentaremos la de Sebastián, Bargueño y ~ o v o ' ligeramente
~,
modificada.
Las dimensiones identificadas son: Prestaciones, Diferenciación, Fiabilidad,
Conformidad, Duración, Asistencia Técnica y Estética.
Prestaciones
Son las características operativas principales de un producto, que son

fundamentalmente medibles, como la velocidad máxima de un vehículo, el tiempo
de frenado, el número de canales de un televisor, los watios de potencia de un
equipo de sonido, etc. La conexión entre calidad y prestaciones, a pesar de poderse
dar una medida de estas últimas, se encuentra afectada por las preferencias
individuales y la semántica. Así, un cliente puede preferir el tiempo de frenado a la
velocidad o no asociar con calidad el término potencia de un equipo de sonido o de
una bombilla (por ejemplo no considera que una lámpara de 100 watios sea de más
calidad que una de 40 watios). Así como las prestaciones se corresponden con las
características objetivas del producto, su relación con la calidad depende de la
interpretación individual y particular del cliente.
" Sebastián, Miguel Angel; Bargueño, Vicente; Novo, Vicente. Gestión y Control de calidad. Madrid. UNED.
1994.
Diferenciación
La diferenciación se refiere a las características secundarias del producto, las

que coexisten con el funcionamiento básico del producto. La distinción con las
prestaciones es muchas veces difícil, pues muchos clientes pueden pensar que para
ellos una característica secundaria o característica diferencial, por ejemplo, la
inclusión de una calculadora en una aplicación software de contabilidad, es una
prestación del producto software considerado.
Fiabilidad
Se denomina fiabilidad a la probabilidad de que un producto no falle en un

período de tiempo determinado. Su medida puede hacerse de diversas formas tales
como el tiempo medio hasta el primer fallo, el tiempo medio entre dos fallos y la
tasa de fallos por unidad de tiempo. Evidentemente estas medidas son sólo válidas
para productos que están funcionando durante un cierto tiempo, por lo tanto sólo
sirve para productos duraderos y no para productos perecederos o servicios de
consumo instantáneo.
Conformidad
La conformidad es el grado en que el diseño y las prestaciones del producto

cumple los estándares establecidos. Su medida varía de un sector a otro. En la
industria de fabricación se mide mediante la tasa de defectos (proporción de la
producción que no cumplen las normas). En otros sectores, como en los servicios,
se mide por el número de reclamaciones o la frecuencia de reparaciones durante el
período de garantía. Tanto la conformidad como la fiabilidad son medidas muy
objetivas de la calidad y, por consiguiente, no afectan tanto a las preferencias
individuales de los clientes como lo hacen las prestaciones y la diferenciación.
Como los usuarios no quieren ni defectos ni fallos, apartando del mercado los
productos que los presentan, la inversión en fiabilidad y conformidad se consideran
como ganancias directas de la calidad.
Duración
Es la medida de la vida del producto. En esta medida de carácter técnico

subyace un aspecto económico. La duración técnica es la cantidad de uso que se
obtiene del producto antes de su deterioro físico, sin posibilidad de reparación. Si
la reparación es posible, la duración es más difícil de calcular, ya que la vida del
producto dependerá de las condiciones económicas; así, si la economía va bien los

coches usados tienen menor duración. En general, el cliente tiene que elegir entre
el coste de la reparación para incrementar la duración y la inversión de un nuevo
modelo más fiable. Como se puede deducir la fiabilidad tiene mucho que ver con la
duración. Aunque no siempre una mayor duración implica una mejora 'del
producto, ya que puede ocultar una situación económica particular, por ejemplo,
obsérvese el parque automovilístico cubano, cuya vida media sobrepasa de largo
los 14 años considerados como media, siendo casi joyas de museo.
Asistencia técnica
Esta característica está relacionada con el servicio de reparaciones y la atención

al cliente en general, y comprende la prontitud en la atención o reparación, la
competencia de los empleados y el trato al consumidor. Algunos aspectos pueden
medirse objetivamente, como el tiempo de reparación o el del actualización de un
antivirus, otros como el trato al cliente sólo puede hacerse de forma subjetiva. Es
uno de los aspectos que más influyen en la percepción actual de la calidad.
Estética
Es muy subjetiva y está muy ligada a la personalidad del usuario, que no tiene
por qué aceptar los cánones establecidos. La forma de un producto, su color, sabor,
tacto o sonido o gráficos afectan de forma diferente a los diferentes usuarios. En un
programa de videojuegos la calidad que percibe el usuario está muy ligada a la
estética (parte gráfica, música de fondo, diseño de los personajes, etc.).
2.5. Las características de la calidad del software
Debido a que el software es intangible, no material, muchas personas tienen

dificultades para asociarle el concepto de calidad. Sin embargo las posibilidades de
fmstración y de pérdida de confianza en él son muy elevadas.
Para adaptar las dimensiones estudiadas a la calidad del software se seguirá la
norma ISO 9126, que describe seis características compuestas: Funcionalidad,
Fiabilidad, Facilidad de uso, Eficiencia, Mantenimiento y Movilidad. Cada una de
ellas se descomponen en subcaracterísticas que serán estudiadas en detalle en el
correspondiente capítulo.
Así, cuando se adquiere un software se quiere que éste funcione siempre y bajo
diferentes condiciones incluso difíciles de cumplir (fiabilidad), que realice las
funcionalidades que dice tener y que por ello se ha adquirido (funcionalidad), que
se puedan ejecutar las funcionalidades de una forma fácil (facilidad de uso), que lo
hagas lo más rápido posible y con el mínimo consumo de recursos (eficiencia), que
cuando las circunstancias lo pidan pueda modificarse fácilmente (mantenimiento)
y, por último, que pueda transferirse de un entorno a otro (movilidad o
portabilidad).
Quizás, de las dimensiones manejadas, la del nivel más bajo asumido es la
fiabilidad, ya que el software debe funcionar siempre que se requiera. Qué mayor
fmstración que cuando se está de viaje con un portátil, no pueda utilizarse por un
incidente del sistema operativo.
El siguiente nivel exigido, el intermedio, es la funcionalidad. No sólo el
software debe de tener las funcionalidades que dice tener, sino que debe
comunicarlas. Es decir, el usuario debe disponer de la información suficiente para
poner usar de forma eficaz todas las tareas. El manual de usuario de la aplicación
es un componente más del software.
En un nivel superior se encuentra la facilidad de uso (usabilidad). Además de
hacer lo que debe hacer el software, debe de hacerlo de una forma fácil, natural y
amigable, de ahí la importancia del diseño de las interfaces.
El resto de las características son complementarias de las anteriores, ya que lo
fundamental es que el software, en primer lugar, debe de funcionar, hacer lo que
dice que hace y de una manera fácil. La economía de recursos, la facilidad de
modificación y el transporte del software añaden la miel a la hojuela de las tres
características fundamentales.
2.6. El Decálogo de la calidad
Este decálogo de la calidad es propuesto por Arthur ~ n d e r s e n 'como

~ preceptos
fundamentales para la gestión exitosa del factor estratégico Calidad. Según los
autores, el decálogo es consecuencia de su experiencia en consultoría.
Los preceptos del decálogo son:
1" La calidad la deJinen los clientes
En los actuales mercados competitivos son los clientes los que determinan sus
necesidades y si los productos y servicios que se le ofrecen les satisfacen. De ahí
que las empresas deban entender y conocer las necesidades, preferencias,
percepciones y valores de los potenciales clientes y, en base a ellos, y con el fin de
14
Arthur Andersen. La calidad en España. Madrid. Cinco Días. 1995.
establecer una posición de liderazgo en algún segmento, identificando aquellos

factores o dimensiones de calidad en los que tiene ventajas competitivas y
diseñando estrategias de segmentación para explotar los nichos del mercado
correspondientes.
2" El proceso de calidad se inicia con el liderazgo activo de la Alta Dirección
La calidad no se delega, se practica. Por consiguiente deben ser los directivos

los que lideren activamente el proceso de la calidad. Una vez que los directivos han
previsto el futuro de la empresa u organización y la estrategia de calidad han de
impulsar su desarrollo y crecimiento. Como la visión y la estrategia de calidad han
de ser compartidas por toda la organización, el estilo de gestión ha de ser
participativo y se ha de practicar diariamente lo que se predica.
3" La calidad es un factor estratégico de competitividad y diferenciación
No se puede hablar de niveles de calidad absolutos, ya que lo que importa es la

comparación que los clientes hacen de las calidades percibidas entre los diferentes
productos o servicios en competencia en el mercado. El factor de calidad a tener en
cuenta como ventaja competitiva varía a lo largo del ciclo de vida del producto
desde la innovación en su inicio, pasando a la competencia en precio y calidad
como factor diferenciador según se avanza en el ciclo. La calidad y el servicio al
cliente son ventajas competitivas duraderas.
4" La calidad efectiva es garantía de rentabilidad sostenida
Si el criterio primordial empresarial es la excelencia del servicio al cliente, la

eficacia de las operaciones se evalúa en términos de calidad más que en términos
de costes, ya que, si el nivel de calidad obtenido cumple con las expectativas de los
clientes, la rentabilidad está garantizada. A la larga la calidad implica reducción de
costes, aunque al principio haya que invertir en formación, aprendizaje y
modificación de los hábitos. La rentabilidad se debe a diversos factores como:
o Los clientes satisfechos son los mejores vendedores.

o Los clientes satisfechos son más fieles a la hora de una nueva compra.
o Los productos y servicios de mayor calidad proporcionan mejores precios y
márgenes comerciales.
o Menores costes de comercialización, ya que no hay que captar nuevos
clientes.
o Mayor productividad al dirigir los recursos hacia un objetivo común y

conocido.
5" La calidad involucra a todo los miembros de la organización
De poco sirve que exista una política de calidad y que los directivos la lideren si
el resto del personal no se encuentra involucrado. Un factor fundamental para ello
se encuentra en la selección de personal, ya que la imagen que de la empresa se'
forman los clientes viene condicionada por el entusiasmo, motivación y convicción
que transmiten los empleados; por lo tanto, los candidatos seleccionados deben
tener unas actitudes y características acordes con la orientación de la empresa. Las
empresas que consiguen implantar con éxito este tipo de estrategia son las que han
dado prioridad a la inversión en formación de sus empleados, convirtiendo esta
formación en un mecanismo fundamental en el proceso de motivación, ayudando a
establecer el espíritu de equipo y cooperación necesarios para que la gestión diaria
de la calidad alcance el éxito.
6" La calidad involucra también a los proveedores
Es evidente que la calidad de un producto depende en un gran grado de la

calidad de sus materias primas y de las herramientas utilizadas durante su proceso.
Por ello es fundamental la calidad de los productos y servicios suministrados por
los proveedores. De ahí nace el concepto de calidad concertada, que implica el
trabajo conjunto con los proveedores con el fin de que estos asuman su parte de
responsabilidad en obtener el objetivo final de calidad. De hecho muchas empresas
exigen a sus proveedores la implantación de sistema de aseguramiento de calidad
según normas ISO o sus equivalentes españolas UNE.
7" La calidad debe ser el criterio que configure todos los sistemas y procesos de
la empresa
Si una organización no evalúa todas sus actividades desde la orientación al

cliente puede que implante sistemas incompatibles con la calidad. Los sistemas que
más influyen en la gestión eficaz de la calidad son:
- Sistemas de captación de información externa. Esta información se

convierte en la base para el conocimiento del mercado, de la competencia y
de los gustos y necesidades de los clientes y permite que se traduzcan en
innovaciones en los productos y servicios para responder ágilmente a los

cambios del entorno.
- Sistemas de medición de la calidad, Estos sistemas permiten evaluar los

factores de calidad que soportan la estrategia de la empresa. Con esta
información y la obtenida en el apartado anterior se puede evaluar el grado
de cumplimiento de los objetivos de calidad establecidos y la posición
competitiva de la empresa y de proceder a efectuar las correcciones
necesarias.
- Sistemas de retribución e incentivos al personal. Estos incentivos deben

ligarse al cumplimiento de los objetivos de calidad, y es la herramienta más
eficaz para motivar al personal y modificar su comportamiento.
8" La calidad debe comunicarse
Para que la'calidad sea percibida hay que dar a conocer las ventajas
diferenciadoras que pueden ser cumplidos por la empresa para generar expectativas
en los clientes. Nunca deben anunciarse aspectos que sean falsos, ya que
defraudan, causan frustración y suponen la pérdida del cliente. Las estrategias
comunicacionales tienen como objetivo:
- Crear una imagen institucional que se asocie con el concepto de calidad.

- La promoción de los aspectos de calidad difeenciadores.
9" Calidad implica sensibilidad y preocupación de la empresa por su entorno

social y medioambiental
Si una empresa se orienta hacia la calidad tiene que distinguirse por su

sensibilidad y responsabilidad hacia la comunidad y el medio ambiente en el que se
desenvuelve. No puede separarse del concepto global de calidad la responsabilidad
social, la ética y la conservación del medio ambiente. La responsabilidad social
forma parte de la imagen de la empresa.
1 O" La calidad es dinámica
La calidad no es estática, está constantemente en transformación debido

fundamentalmente a tres factores: los gustos y motivaciones de los consumidores
cambian con el tiempo, la competencia presiona mediante el lanzamiento de
nuevos productos y servicios y el proceso evolutivo interno de la propia empresa

hace que se fije continuamente nuevas metas.
3. ESTADOS DE DESARROLLO DE LA CALIDAD
La calidad ha pasado por diferentes etapas de desarrollo hasta el momento

actual como se representa en el gráfico siguiente:
Gestión estratégica de la calidad
Aseguramiento de la calidad
Figura 1.2. Etapas de la calidad.
3.1. Inspección
Como consecuencia de la organización "taylorista" de la producción nace el

control de calidad como supervisión de los productos terminados según el concepto
"aceptado o no aceptado". Los inspectores de calidad comprobaban si los
productos cumplían determinados requisitos, rechazando aquellos que no
superaban la correspondiente inspección. Sus características son:
o El objetivo principal es la detección de errores.

o Su visión de la calidad es un problema a resolver.
o Pone el énfasis en la uniformidad del servicio.
o Emplea métodos de fijación de estándares y medición.
o El papel de los profesionales de la calidad es de inspección, clasificación,
conteo y medición.
o La responsabilidad de la consecución de la calidad es del departamento de
inspección.
o Su orientación y enfoque es que la calidad se comprueba.
3.2. Control de la calidad
Hacia 1924 se establecen las bases del Control Estadístico de la Calidad, que
recibe su confirmación durante la Segunda Guerra Mundial, contribuyendo a la
producción de guerra que facilitaría el triunfo a los Aliados. Las características son:
El objetivo principal es el control para detectar errores en los productos

terminados.
Su visión de la calidad sigue siendo un problema a resolver.
El énfasis sigue estando en la uniformidad del servicio, pero reduciendo la
inspección.
Sus métodos son herramientas y técnicas estadísticas.
El papel de los profesionales de la calidad es de resolución de problemas y
aplicación de métodos estadísticos.
La responsabilidad de la consecución de la calidad es de los departamentos
de calidad y de los inspectores.
La orientación y enfoque se basa en que la calidad se controla.
Su filosofía es clasificar los productos en función de su calidad intrínseca.
Su alcance se relaciona exclusivamente con el producto final.
Las referencias escritas son las especificaciones del producto.
La formación del personal queda limitada a los inspectores.
El coste de la calidad se debe al rechazo de productos ya terminados, no
recuperándose su coste de producción.
A los proveedores prácticamente no se les presta ninguna atención.
Las únicas normas existentes son las especificaciones del producto.
La calidad se obtiene por comparación de las especificaciones con el
resultado del control del producto terminado.
3.3. Aseguramiento de la calidad
Del control estadístico de la calidad se pasa a la gestión de la misma,

caracterizándose por:
Su objetivo principal es la coordinación de los diferentes procesos que

llevan al producto.
Su visión de la calidad sigue siendo un problema a resolver, aunque ahora
de una forma activa.
Su énfasis consiste en actuar en la totalidad de la cadena, incluidas las
funciones de I+D y las áreas de apoyo.
Sus métodos son los programas y sistemas de calidad.
El papel de los profesionales de la calidad está en planificar la calidad,
medirla y diseñar programas para la calidad.
La responsabilidad de la consecución de la calidad es de todos los
departamentos; la dirección se limita a fijar la política, planificar, coordinar
y controlar.
Su orientación y enfoque es que la calidad se produce.
Su filosofía es incorporar la calidad al producto desde la fase de desarrollo
al final de una forma planificada.
Su alcance se limita al proceso de producción, junto a los proceso de apoyo,
en cuanto tengan relación directa con el producto final.
Sus referencias escritas son normas ISO u otras específicas de
aseguramiento de la calidad, el manual de calidad y los procedimientos
escritos.
La responsabilidad está en asegurar el cumplimiento de las instrucciones de
la documentación de toda la línea jerárquica que ejerce la responsabilidad
del aseguramiento.
La formación es específica. Se dirige a que cada persona aprenda
exclusivamente las tareas que tenga que desarrollar.
La reducción de costes no es un objetivo directo. Los ahorros se producen
indirectamente al actuar mediante medidas correctoras siguiendo los
procedimientos escritos en el sistema de calidad.
La calidad se obtiene realizando las tareas según las normas y se mide por
el número de desviaciones.
Al suministrador se le debe exigir su conformidad con sistemas de
aseguramiento de la calidad.
Las normas son la ISO 9001-2000, 9002-94, 9003-94 o las específicas del
sector.
3.4. Gestión de la Calidad Total
Un grupo de empresas europeas pensó, a mediados de los años ochenta en

obtener una ventaja competitiva por medio de la Gestión de la Calidad Total
(TQM) y crearon la Fundación Europea para la Gestión de la Calidad (EFQM).
Esta gestión no se basa en normas sino en modelos como el Premio Malcom
Baldrige, el Premio Deming o el Modelo Europeo (modelo EFQM). Sus
principales características son:
Su objetivo principal es el impacto estratégico.

Su visión de la calidad cambia del problema a una oportunidad de ventaja
competitiva.
Su énfasis se pone en el mercado y las necesidades de los clientes.
Sus métodos son la planificación estratégica, la fijación de objetivos y la
movilización de la organización.
El papel de los profesionales de la calidad se centra en la fijación de
objetivos, formación, coordinación entre los departamentos y diseño de
programas.
La responsabilidad de la consecución de la calidad es de todos los
miembros de la empresa bajo el liderazgo activo de la dirección.
La orientación y el enfoque se basa en que la calidad se gestiona.
Su filosofía se basa en dirigir la organización, con colaboración de los
empleados, hacia la mejora de los productos.
Su alcance es la Gestión por Procesos de todo lo que se hace en la
organización.
Las referencias escritas, además de todas las anteriores, incluyen las
expectativas de los clientes, las políticas de calidad, los objetivos
estratégicos, la participación de los empleados, la relación con la
comunidad, etc.
La responsabilidad de la gestión es de todo el equipo directivo y de los
mandos intermedios.
El control de costes se dirige a reducir el coste mediante la eliminación de
todos aquellos elementos y procesos que no añaden valor, desde el punto de
vista del cliente interno y externo.
El proveedor constituye un eslabón más en la cadena de valor, por lo que
hay que establecer con él una relación de confianza para conseguir una
Calidad Concertada.
3.5. Evolución del concepto de calidad
Inicialmente la calidad se consideraba un problema. Actualmente esta visión ha

variado al considerarse como un factor estratégico, un elemento competitivo.
También ha pasado de ser incumbencia exclusiva del departamento de producción
a afectar al resto de los departamentos, hasta llegar actualmente al mercado y a los
clientes, centrándose todo el énfasis de la calidad en estos últimos. Los métodos,
que consistían únicamente en herramientas de medición han evolucionado hasta
herramientas de gestión y planificación.
La calidad ha ido acrecentando su papel en la empresa, involucrando cada vez a
mayor número de personas y saliendo de la organización para centrarse en el
mercado y el consumidor.
El cambio puede observarse en el siguiente cuadro:
Tabla l. l. Evolución de la calidad en la empresa.
Las actividades necesarias para la obtención de cierto producto, de forma que

éste cumpla con requisitos concretos pueden ser entendidas como control de la
calidad. La historia y evolución de esta disciplina se encuentra, por tanto,
estrechamente unida a los avances tecnológicos aportados por la humanidad desde
sus orígenes.
El término calidad no aparece hasta muy avanzada la historia de la economía y
la tecnología, aunque sí se emplean calibre, galga, sistema de medición que indican
un cierto papel de la metrología, es decir, una tendencia a cuantificar las
características de los productos.
4.1. Artesanos y Obreros
Un momento importante para la aparición de lo que podríamos llamar "la

calidad moderna" se produce cuando el artesano se convierte en obrero con el
advenimiento de la Revolución Industrial.
Anteriormente era el artesano el que producía los artículos que necesitaban los
demás, pero los hacía uno a uno, solamente condicionado por el cliente. Los
productos tienen ciertas connotaciones artísticas y el artesano tiene prácticamente
una total libertad de acción. Aunque el artesano no ha desaparecido en la actualidad
(alfareros, bordadoras, sastres, zapateros, etc.) sigue teniendo un contacto directo o
casi directo con el cliente, conociendo, por lo tanto, sus necesidades y
requerimientos y elaborando el producto a la medida. Al entregar el producto, el
artesano puede conocer el grado de satisfacción del cliente, que es lo que hoy en
día se conoce como calidad.
La Revolución Industrial introduce la producción masiva y la cadena de
montaje. El operario no tiene ni iniciativa ni libertad de acción, su trabajo viene
impuesto por su puesto en el conjunto del proceso productivo. El comportamiento
de obrero está condicionado por muchos aspectos, tales como el tipo y estructura
de su empresa, la situación socio-económica de su entorno, etc., siendo para él
poco significativas las necesidades del usuario final, al que no conoce, y del que no
aprecia sus requerimientos. Por lo tanto, el operario no conocerá casi nunca el
grado de satisfacción del cliente o sea la calidad de su trabajo.
Es necesario, por consiguiente, la organización de un sistema de medición,
supervisión y control que intente asegurar la calidad de la producción, con la
intervención de nuevos operarios especializados en calidad.
4.2. Los orígenes
En los principios de la humanidad, la sociedad era exclusivamente nómada,

recolectora y cazadora. Cada grupo elaboraba sus propios productos según sus
necesidades, por lo que no hacía ningún control del tipo calidad sobre su proceso
productivo, ya que no es lo mismo trabajar para uno mismo que producir para otra
persona que tiene algo que decir sobre el resultado del trabajo.
Cuando los hombres aprenden a domesticar los animales y sobre todo cultivar
los vegetales, se ven obligados a asentarse, y al mejorar los cultivos se produce un
excedente de alimentos que permite que algunos puedan convertirse en artesanos y
producir objetos para los demás. Es el momento en el que empieza a tener lugar
una "función de calidad" por parte del artesano por un lado y del consumidor por
otro. También se inicia el comercio, incluso a grandes distancias: el intermediario,
el comerciante, hace también un papel de "inspector de calidad" al elegir los
productos con los que va a negociar.
Existe una notable diferencia entre un control de calidad realizado de forma

inconsciente, desorganizada y por individuos aislados, y aquel otro, colectivo,
organizado y consciente. No es fácil conocer cuándo y dónde se produjo la
evolución desde una actitud hacia la otra. Jerry ~ a n k s ' ' apunta "la existencia de
conscientes esfuerzos en el control de la calidad"I6 en tiempos de la construcción
de las pirámides de Egipto, por lo que podemos considerar esta época como
referencia temporal básica para esta disciplina. La Grecia clásica o el antiguo
imperio romano han dejado muestras evidentes del nivel de calidad alcanzado en
sus obras de ingeniería o arquitectura. Aun, hoy en día, podemos disfrutar de la
simbiosis de técnica y belleza que sus construcciones nos ofrecen.
En la Edad Media y hasta finales del siglo XIX el suministro de servicios y la
producción de bienes se encontraban esencialmente limitados a individuos aislados,
como máximo a un grupo formado por algunas pocas personas. Este colectivo era
quien controlaba la calidad del artículo haciendo las funciones de productor e
inspector. El resultado de esta actitud es que los estándares de calidad eran auto-
establecidos. Por otro lado la existencia o no de conformidad entre el producto
elaborado o el servicio ofrecido, y los requisitos del cliente eran determinados de
forma individual.
En esta era, sin embargo, la actividad manufacturera no era totalmente ajena a
un control de calidad organizado. Los gremios, entendidos como agrupaciones de
maestros artesanos, surgieron para la protección y provecho económico y social de
sus miembros. Regulaban las economías locales urbanas estableciendo monopolios
sobre el comercio, manteniendo servicios estables sobre condiciones estables y
especificando estándares de calidad sobre las cosas.
"Esta regulación de las actividades manufactureras (por parte de los gremios)
puede haber sido uno de los primeros esfuerzos en el control de la calidad.17"
"Los consumidores se vieron beneficiados por una parte, porque la existencia de
los gremios garantizaba una alta calidad de los productos.ls "
4.3. La Revolución Industrial: la inspección
El advenimiento de la industrialización, a finales del siglo XVIII, supuso

profundos cambios sociales y económicos generados por 'un proceso técnico.
Prácticamente desaparecen los pequeños talleres artesanales y se forman grupos de
trabajadores más numerosos con atribuciones específicas o similares. La
l5 Banks, Jeny. Profesor de la Escuela Industrial y de Sistemas Ingenieriles perteneciente al Instituto Tecnológico
de Georgia. Experto en sistemas de simulación informática. Consultar la Encyclopedia of Software Engineering,

John Wiley & Sons, 1994.
Jerry Banks. Principies of quality control. John Wiley & Sons, 1989. Pág. 4. La traducción es nuestra.
" Banks, Jeny., op. cit. pág. 6. La traducción es nuestra.
'* Consultar "gremio" en la enciclopedia Salvat Universal. Barcelona. 1996.
complejidad de las manufacturas se incrementa y se incluye en el proceso

productivo maquinaria sofisticada que proporciona un aumento espectacular de la
productividad. Bajo estas circunstancias comienza la era del supervisor. Esta figura
tenía la misión de controlar el trabajo de los empleados. Por otro lado el dueño de
la fábrica, aún presente físicamente en la misma, elige estándares y claves
relacionadas con el control de la calidad.
A medida que transcurre el siglo XIX, avanza la complejidad de las
manufacturas, las industrias crecen y la técnica progresa. Las organizaciones
consideran la necesidad de incluir en sus plantillas individuos que, aunque no
envueltos de forma directa en el proceso productivo, inspeccionen la calidad del
producto.
4.4. De 1900 a 1950: la era del control estadístico
En 19 11 Taylor en su obra Principios de la dirección cientzjica propone la

separación entre la dirección de la empresa y los trabajadores mediante la fórmula:
"La dirección debe definir la tarea de cada uno de los operarios especificando el
método que deben de usar y cuantificando el tiempo que deben emplear en
realizarla."
La organización "taylorista" de la producción se extiende rápidamente. El

proceso de producción se descompone en una serie de sencillas tareas y cada
operario sólo realiza una de ellas y, por lo tanto, de una forma fácil. La duración de
la formación del personal es relativamente corta y se puede atender rápidamente los
aumentos de producción mediante la contratación de nuevo personal.
Los precios de los productos bajan y se hacen asequibles a una gran masa de
usuarios, aunque éstos no son tenidos en cuenta en el diseño de los productos. La
empresa ofrece el producto que considera satisface las necesidades de los usuarios
y a éstos, como la oferta es inferior a la demanda, no les queda otra solución que
comprar lo que hay en el mercado.
Como la organización de la empresa es funcional, sólo los directivos de mayor
nivel de cada función tienen una visión global del proceso. Lo que obliga a
comprobar que el producto obtenido al final de una fase satisfaga las condiciones
de entrada de la fase siguiente. De ahí que las tareas deban de ser supervisadas y
los productos resultantes controlados. Nace así el departamento de control de
calidad y sus operarios, los inspectores como supervisores de si el producto "pasa o
no-pasa", con el fin de eliminar los no aptos. La calidad se centra en el producto.
En 1918, Henry Ford fue de los primeros en aplicar técnicas de control de
calidad, mejorando y estandarizando los procesos. Las materias primas se
distribuían regularmente en la planta de "River Rouge" el lunes y los viernes los

productos estaban terminados y listos para ser despachados.
Las rutinas de control de la calidad basada en la supervisión de inspectores, a
pesar del avance práctico y conceptual que supusieron, era una técnica insuficiente
que no satisfacía a ciertas empresas. La empresa Be11 Telephone se enfrentaba a un
grave problema: las solicitudes de instalación de teléfonos sobrepasaban las más
optimistas expectativas, pero al mismo tiempo se incrementaban de forma
alarmante las reclamaciones de los clientes, lo que suponía el tener que dedicar
gran parte de sus recursos a resolver este problema. La empresa Western Electric,
bajo contrato de la empresa American Be11 Telephone Company, estudió el
problema con el objetivo de proporcionar técnicas e instrumentos más certeros que
provocara una mayor confianza en los productos ofrecidos. En 1924 se formó el
Departamento de Inspección de Laboratorio de las compañías Be11 Telephone y
Western Electric [Banks, 19891, que recibió el nombre de "Quality Assurance
Department", es decir, Departamento de Garantía de Calidad.
Se nombró responsable a R. L. Jones que formó un equipo de especialistas,
entre los que se encontraban muchos de los hoy considerados precursores de la
calidad actual (Dodge, Romig, Edwars y Shewhart). El propio Jones redactó
personalmente las tareas que debían realizar cada uno de los miembros del equipo.
Esa descripción, se considera actualmente como la primera documentación de un
sistema de calidad.
El Dr. Walter A. Shewhart el día 16 de mayo de 1924, propone un gráfico de
control para el análisis de los datos obtenidos por los inspectores con el fin de sacar
conclusiones sobre el proceso productivo. Shewhart está considerado como el
padre del control estadístico de la calidad.
Las aportaciones de este equipo fueron muy importantes. Por primera vez,
además de utilizar gráficas de control, se definieron conceptos y nociones hasta
entonces no bien entendidos, tales como riesgo del proveedor, riesgo del cliente,
probabilidad de aceptación o inspección media total (IMT).
En 1925, Dodge presentó los principios básicos del muestreo por atributos en
el procedimiento de inspección. En febrero de 1926 la revista "Manufacturing
Industries" publica el artículo de Shewhart "Finding causes of Quality variation" y
en octubre otro artículo, "Quality control charts" en el "Be11 System Técnica1
Journal". En 1927, las tablas de muestreo sobre el concepto de límite de calidad
media de salida (LCMS) fueron desarrollados por el equipo de la Western Electric.
Se había alcanzado la fase que Marciniak denominó "cuantificación de la calidad
del producto".
En 1931 aparece el libro "Economic control of quality for manufactured
products" del propio Shewhart, que se convierte en la "biblia" de la calidad en
Estados Unidos. Las empresas lo utilizan como herramienta para conseguir sus
objetivos de calidad. A lo largo de la década de los treinta la aceptación de las
técnicas de muestre0 en la industria se afianzó, e incluso superó las fronteras de los

Estados Unidos de América, teniendo especial impacto en la comunidad
universitaria del Reino Unido. Egon S. Pearson pronuncía la conferencia "A
survey of de the uses of stastistical metod in the control and standardization of
manufactured products" en la Roya1 Statistical Society y más tarde la British
Standard Association publica otro artículo de Pearson "The application of stastiscal
methods to industrial standardization and quality control". Por otro lado se
promovió el concepto de control de calidad basado en la motivación y compromiso
de los empleados, a esta iniciativa se la denominó Plan Scanlon.
En 1940 la Asociación Americana de Estándares, más conocido por sus siglas
provenientes de su nombre en inglés ASA (American Standards Association), a
requerimiento del Departamento de Defensa de los Estados Unidos de América,
impulsó la utilización de controles estadísticos en los productos manufacturados.
De este esfuerzo surgieron los estándares AWS Zl.1 "Guía del Control de
Calidad", y AWS 21.2 "Método Gráfico de Control y Análisis de Datos". El
nombre de estos estándares proviene de las siglas en inglés de este documento;
American War Standards.
4.5. El aseguramiento de la calidad: aparecen las normas
Durante la Segunda Guerra Mundial, debido a la falta de mano de obra

cualificada, el ejército se involucra activamente en el control de la calidad. La
participación de las fuerzas armadas, sobre todo de los Estados Unidos, en esta
materia se revelará como fundamental. Su influencia no sólo incide en la década de
los cuarenta, si no en toda la historia del control de la calidad hasta nuestros días.
En 1946 se crea formalmente la American Society for Quality Control (ASQC).
En 1949 se desarrolla el denominado JAN-105, acrónimo de su nombre en inglés,
Joint Army-Navy Standard, documento que significaba un importante avance en
el campo de variables, atributos y el análisis secuencial.
La medida de atributos relacionados con la calidad se reveló una actividad
sumamente importante ya en la década de los años cuarenta. Debido a la
trascendencia de las certificaciones emitidas por los laboratorios sobre la industria
y el comercio, era imprescindible que éstos realizaran unas evaluaciones "honestas,
precisas, exactas."
Aunque el control de calidad estadístico continuó en la década de los años
cincuenta, este decenio estuvo marcado por el desarrollo y modificación de
estándares de control de calidad.
En 1950 un comité formado por militares norteamericanos desarrolló la norma
MIL-STD-105A, considerada un compromiso entre los estándares de control
militar JAN-105 y las tablas del ejército norteamericano denominadas ASF. A este
estándar le siguieron la MIL-STD-105B, MIL-STD-105C, MIL-STD-1O5D y la
MIL-STD-414 emitida en 1957. Estos manuales no tenían en cuenta estándares

relacionados con los requisitos de programas de calidad o técnicas de inspección a
aplicar a los suministradores. El estándar MIL-0-9858A y el MIL-1-45208A
solucionaron este defecto con amplitud, pues resultaron ser verdaderos programas
de aseguramiento y control de calidad. Por otro lado el Departamento de Defensa
norteamericano y la Agencia Nacional Espacial y Aeronáutica norteamericana,
mundialmente conocida por sus siglas en inglés NASA, también fueron muy
activos, emitiendo sus propios manuales.
Fuera de los Estados Unidos también surgen investigadores y estudiosos del
control de la calidad. En 1947 se crea en Japón la Unión Japonesa de Científicos e
Ingenieros (JUSE) que se convertirá desde su nacimiento en el impulsor de la
evolución de la calidad, siendo aceptadas sus pautas por todo el mundo. Dentro de
la SUSE se organiza el Comité de investigación en control de Calidad. Ese mismo
año se promulga la Ley de Normalización Industrial de Japón, bajo cuya sombra se
editan las normas JIS. En julio de 1950 se organiza un seminario en el que
interviene el Dr. Deming, el cual afirmó que el avance en la calidad haría que la
marca "Made in Japan" sería un símbolo mundial.
Fue en 1950 cuando el renombrado experto en el control de calidad K. Ishikawa
comenzó sus estudios sobre estos conceptos. En 1955 Ishikawa introdujo las
técnicas de gráficas de control en el Japón y crea el Diagrama causa-efecto,
conocido comúnmente el diagrama de la espina de pez, "fish-bone". A Ishikawa le
fue concedido el Premio Dening.
En Europa también se percibe un continuo interés por el control de la calidad,
siendo Gran Bretaña es el país europeo líder en este campo. Se fundan diversas
asociaciones para la promoción de las técnicas de Calidad. Así, en 1956 nace la
Organización Europea para el Control de la Calidad (EOQC, European
Organization for Quality Control) que es hoy día la European Organization for
Quality. En Francia se funda en 1957 la Association Francaise pour le Contróle
Indústriele et la Qualité (AFCIQ). En 1961, nace en España la Asociación Española
para el Control de la Calidad (AECC) que ha cambiado su nombre por el de
Asociación Española para la Calidad.
4.6. El presente: la gestión de la Calidad Total
La década de los sesenta está caracterizada por una nueva fase en la disciplina
del control de calidad. Era el principio de la denominada por Feigenbaum, en 1956,
Calidad Total. Antes de 1960 el control de calidad estaba esencialmente asociado a
la planta de fabricación. Las estructuras de toma de decisión en el negocio no
utilizaban adecuadamente los resultados y recomendaciones emanadas de las
técnicas estadísticas aplicadas. El concepto de calidad total presentaba la idea de
que todos los departamentos, no sólo el de control de la calidad, tuviera

responsabilidades en este trabajo.
Simultáneamente la industria japonesa sintió la necesidad de una educación más
profunda de los supervisores, que eran la unión entre administradores y operarios.
Como respuesta a este hecho la Unión de Científicos e Ingenieros (JUSE) publicó
la revista Gemba-To-QC en abril de 1960. Al amparo de esta idea surgen los
denominados círculos de calidad, foros de debate y discusión en las empresas. En
ellos supervisores y trabajadores opinan sobre los controles de calidad existentes
provocando un autoadiestramiento en la calidad y su técnica.
Philip B. Crosby, promotor de un programa de 14 puntos para la gestión de la
calidad y de las cuatro calidades absolutas (definición de calidad, sistema de
prevención de la calidad, cero defectos, y medición de la calidad), era el director de
producción de la empresa Martín, fabricante de los misiles Pershing. Alcanzó la
fama cuando puso en marcha, mediante un plan de incentivos para los trabajadores
si reducían los defectos, el primer proyecto "cero defectos". El 12 de diciembre de
1961 consigue entregar en Cabo Cañaveral (actual Cabo Kennedy) un cohete sin
defectos, el primero de una serie de cero defectos.
A mediados de los ochenta aparecen las primeras normas internacionales, las
ISO 9000, derivadas de la norma militar británica BS 5750.
En 1987, el presidente de los EEUU, Ronald Reagan institucionaliza el
Malcolm Baldridge Quality Award, que motivó a la mejora continuada de la
calidad a empresas como Motorola, Digital Equipment y Rank Xerox. En 1992 se
establece el Premio Europeo a la calidad de la Fundación Europea para la Gestión
de Calidad (EFQM).
4.7. La Industria del Software y la industria tradicional
El desarrollo de programas para ordenador es una industria joven que ha

evolucionado rápidamente aplicando en pocos años prácticas propias del control de
calidad que otras disciplinas han madurado durante décadas. Tal como Marciniak
nos indica:
"Una diferencia principal entre la industria del software y otras industrias, es

que la industria del software es relativamente muy joven. Intenta alcanzar en 30
años un estado de madurez para el que otras industrias han necesitado alrededor de
200 años."
Por otro lado es evidente la influencia de la industria tradicional sobre la

industria del software. Por ello no podemos obviar acontecimientos, que si bien
parecen no tener relación con el proceso de creación de programas informáticos,
han supuesto una referencia importante para el mismo. La tabla 1.2, propuesta
también por Marciniak, pone de manifiesto esta relación, comparando las

diferentes fases superadas por el control de calidad y su aplicación por parte de la
industria en general, y la industria del software.
Etapa Descripción Industria del Industria en

--- .- Software general
Artesanos Se fían de la creatividad y del buen Años sesenta Antes del
trabajo artesanal siglo XIX
Inspección Supervisores inspeccionan la calidad Años setenta Siglo XIX

antes de la liberación de producto
Control Cuantificación de la calidad del Pocas Años treinta

estadístico producto; técnicas de muestre0 evidencias
del proceso de uso
Aseguramiento Uso de estándares en los sistemas Años ochenta Años

de la calidad de calidad para los procesos cincuenta
Conformidad Calidad total: se eliminan derroches Años noventa Años ochenta

con la calidad y minimizan costes
Calidad dirigida Calidad total dirigida hacia el cuidado Pocas Años noventa
al cliente del cliente y del servicio evidencia
de uso
Calidad dirigida Calidad total dirigida hacia el cliente Pocas Algunas
al mercado existente así como a clientes en evidencias evidencias
Tabla 1.2. Las etapas de la calidad.
4.8. Orígenes del aseguramiento de la calidad del software
A finales de la década de los sesenta varios documentos de IBM utilizaron de

forma ocasional el término aseguramiento de la calidad del software [Dunn, 19941.
Generalmente esta expresión se encontraba asociada a la realización de pruebas del
producto ya desarrollado. Por otro lado los requisitos para ofertas exigían incluir un
párrafo bajo el título "Aseguramiento de la Calidad del Software". Este apartado
requería al contratista dirigir un cuidadoso programa de pruebas para cualquier
software embebido en el producto ofertado. Pero es en 1974 cuando aparece por
primera vez el concepto de aseguramiento de la calidad del software en un sentido
amplio, fue en una especificación militar norteamericana identificada como MIL-S-
52779 (AD) denominado "Programa de Requerimientos para el Aseguramiento de

la Calidad del Software".
La MIL-S-52779 (AD) solicitaba de los contratistas diferentes exigencias
relacionadas con el desarrollo del software así como de su administración. Los
puntos más importantes eran:
- Métodos a utilizar por el contratista para evaluar diseño y documentación.

- Aprobación interna del trabajo.
- Documentación de los estándares del gobierno norteamericano para un
trabajo desarrollado bajo contrato con el mismo.
- Biblioteca sobre los procedimientos de control para código y datos
relacionados.
- Revisiones y auditorias, especialmente para asegurar que el software ha
seguido sucesivos estados en su desarrollo.
- Control de los subcontratistas del software.
- Pruebas, incluyendo planes, análisis de las especificaciones externas que
aseguran la verificación, criterios de esas pruebas, control de las pruebas,
certificación de los resultados, revisión de la documentación de las pruebas.
La norma norteamericana perfiló el ámbito de la práctica del aseguramiento de

la calidad del software, con excepción de los procesos de mejoramiento de la
calidad. Por otro lado no identificaba métodos, técnicas, prácticas o herramientas
que los contratistas debían seguir. Sólo indicaba que este asunto debía ser tenido en
cuenta por adelantado y controlado para asegurar su uso durante el desarrollo.
Otras normas surgieron teniendo como modelo la MIL-S-52779 y sus versiones
posteriores. La norma FAA-STD-018 promovida por el Ejército del Aire
norteamericano o las AQAP-13 propias de la OTAN. En 1979 IEEE emitió la
norma P730 "Planes de Aseguramiento de la Calidad del Software", también
similar a la norma MIL-S-52779, aunque hizo un mayor hincapié en la
documentación y uso de revisiones formales reflejando el desarrollo del software
según el modelo militar "en cascada". Omitió de forma deliberada procedimientos
de prueba.
Estos primeros documentos no tenían como propósito recetar herramientas y
técnicas para prevenir defectos, métodos para dirigir revisiones de código,
filosofías y técnicas de las pruebas o uso de datos para mejorar la calidad de
futuros desarrollos. La intersección con otros aspectos de la ingeniería del software
tuvo que ver únicamente con el control del proceso del desarrollo del software y
liberación de nuevas versiones. Los modelos propuestos por los militares
norteamericanos o el IEEE se acercaban al concepto tradicional del control de
calidad en orden a vigilar el trabajo de los programadores y analistas.
El papel asignado al aseguramiento de la calidad del software fue tácitamente

definido como el de un policía o un árbitro, observado como algo nuevo, incluso
para los equipos de control de calidad tradicionales.
"Algunos departamentos de control de calidad sabían cómo interpretar las
nuevas especificaciones. El ritmo parecía familiar, pero los entornos de control de
calidad nunca habían bailado con una música tan extraña.19"
A mediados de los setenta, la fiabilidad, ciertamente uno de los atributos
primeros de la calidad del software, atrajo la atención de forma importante sobre
conceptos como productividad del programador o control del proyecto. La
fiabilidad era vista como la materialización diligente de los preceptos
prevalecientes en la ingeniería del software que enfatizaba en la planificación del
desarrollo de proyectos, modelado de requisitos, administración de la
configuración o las técnicas de diseño. El aseguramiento de la calidad del software
no jugaba ningún papel en este hecho. Los textos de la época, por ejemplo, no
hacían referencia a este concepto (aseguramiento de la calidad del software).
En los primeros años ochenta las actividades relacionadas con el aseguramiento
de la calidad en el software se centraban en establecer estándares para la detección
de errores, control de cambios, documentación y control de proyectos.
Dunn y Ullman publicaron un libro en 1982 que supuso la extensión de los
conceptos relacionados con el aseguramiento de la calidad del software más allá
del control del proyecto, hacia la medida del software, mejora de la calidad y
calidad inherente. El libro concibió esta disciplina como una herramienta de
administración, aunque algunos estudiosos del mismo consideran que no distinguió
claramente la herramienta de la administración en sí.
En los años ochenta existía una clara confusión que no permitía definir el
aseguramiento de la calidad del software como un conjunto de actividades o como
una organización funcional. De cualquier manera la calidad en el software estaba
atrayendo a gran cantidad de investigadores, estudiosos, administradores y gerentes
relacionados con la programación.
Por otro lado la informática era utilizada como una herramienta, por otras
disciplinas, en sus propios procesos de aseguramiento de la calidad. El número de
paquetes informáticos desarrollados para este objetivo se multiplicó por dos, y a
veces por tres, según el área considerada, desde mediados de los años ochenta hasta
1988.
l9 Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineenng, John Wiley & Sons, 1994. Pág.
942. La traducción es nuestra.

4.9. Las normas de calidad del software
En el ámbito militar se siguió trabajando profusamente en la calidad del

software y su aseguramiento. El resultado de este esfuerzo se materializó en un
conjunto de estándares de gran influencia, no sólo en el ámbito militar, sino en
numerosos aspectos de la vida civil. En 1979 el Ejército de Tierra norteamericano
auspició unas jornadas en la Escuela de Postgrado de la Marina en Monterrey,
California. El resultado de estas reuniones fue enormemente fructífero pues se
establecieron las bases de la que más tarde sería la normativa denominada DOD-
STD-2168 sustituta oficial de la MIL-STD-52779 A.
La esencia de la DOD-STD-2168 es que el contratista debe establecer un
programa para asegurar que el proyecto software está bajo un control de
configuración y administración y que los componentes del desarrollo son evaluados
con respecto a la calidad y que el producto final está apropiadamente cualificado
para su uso. Es interesante apuntar que a los primeros borradores de este proyecto
se le llamó "Medida y Aseguramiento de la Calidad del Software", y enfatizaba en
evaluar si el proceso de desarrollo del contratista era adecuado para producir un
software de calidad. Por otro lado, esta norma en ninguna parte requiriere de forma
expresa que el contratista posea una organización de aseguramiento de calidad del
software. El proceso de creación de este estándar se alargó hasta 1988.
Aunque en los setenta y en los ochenta el aseguramiento de la calidad del
software se habían establecido en compañías de software empotrado, esta
disciplina había empezado a encontrar un hueco en sistemas de programación y
sistemas de administración de la información, que incluía la programación de
aplicaciones de uso comercial.
La pobre calidad con la que muchos programas llegaban a la fase de ejecución
era debido a la falta de un adecuado programa de prueba.
"Era frecuente para algunos desarrolladores considerar el software listo para su

uso si el programa podía ser compilado y cargado.20"
No sorprende, por tanto, que el aseguramiento de la calidad en el software se
dirigiera hacia un incremento en las pruebas.
Verificación y validación fue otro significado a menudo adscrito al
aseguramiento de la calidad en el software.
20
Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineering, John Wiley & Sons, 1994. Pág.
4.10. Análisis de los atributos
A mediados de los ochenta, el concepto asociado al aseguramiento de la calidad

se asoció a tres significados diferentes:
- Una aproximación comprensiva a la mejora del software, proceso de

programación y control del proyecto software.
- Pruebas.
- Verificación y validación.
En los ochenta el primero de estos tres conceptos incrementó el énfasis del

análisis de los atributos de la estructura del software así como en la acumulación y
análisis de los datos asociados a los errores. Es aceptado que la permanencia de los
errores en el proyecto software incrementa dramáticamente su presencia a medida
que el error permanece más tiempo en dicho proceso. La práctica de la colección y
análisis de datos se desarrolló en el ámbito del aseguramiento de la calidad. La
dependencia de los datos es intrínseca al concepto de control de la calidad total y es
la sustancia de una de las siete categorías de criterios del Premio Nacional de
Calidad Malcolm.
Una variación de este primer punto asociado al aseguramiento de la calidad del
software, influenciado por el concepto de calidad total, supera la confusión entre
organización-administración.
"El aseguramiento de la calidad del software no asegura la calidad del software;

asegura la planificación y ejecución de un programa de calidad que envuelve tres
elementos tecnología, persona y administración, tres partes que finalmente actúan
rec~rsivamente.~'"
4.11. Los modelos
En la actualidad existen modelos de uso habitual en las empresas de software

que han influido enormemente en el proceso de implantación de la calidad en el
desarrollo de programas informáticos. Más adelante haremos un estudio detallado
de alguno de ellos.
El Instituto de Ingeniería del Software, más conocido por su acrónimo inglés
SE1 (Software Engineering Institute) ideó un marco de referencia para el proceso
de creación del software como respuesta al requerimiento de gobierno
''Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineering, John Wiley & Sons, 1994. Pág.
norteamericano para la obtención de un método que permitiera valorar la capacidad

de los contratistas de aplicaciones informáticas que accedían a sus licitaciones.
Tras cuatro años de trabajo el SEI, en colaboración con la empresa Mitre
Corporation, desarrolló un modelo apoyado en el concepto de madurez al que
denominó CMM acrónimo del inglés Capability Maturity Model, traducido
habitualmente por Modelo de la Madurez del Desarrollo Software.
La respuesta europea se materializó en el denominado modelo Bootstrap. Sin
obviar los incuestionables méritos que el Modelo de Madurez posee, su aplicación
en el ámbito europeo fue discutida por algunos estudiosos. Tal y como apunta el
profesor Günter R. Koch , el modelo de valoración de la madurez propuesto por el
SE1 mostraba ciertas debilidades que lo hacían dificil de aceptar desde el punto de
vista de la mentalidad europea.
La metodología Bootstrap se encuentra alineada con la norma ISO 9000. Esta
norma, a su vez, propuso la norma ISO 9000-3, guía de aplicación de la norma ISO
9001 para compañías de software.
Otra de las iniciativas encuadradas en modelos cuya finalidad es ayudar a las
organizaciones a mejorar la calidad del software es TickIT. Promociona la
definición de procesos y procedimientos para la certificación de la calidad de los
sistemas en el contexto de la calidad total. Trillium es, a su vez, un modelo
desarrollado por la empresa Be11 Canadá para valorar el proceso de creación del
software de suministradores potenciales en orden a minimizar riesgos propios y
asegurar tiempos de entrega de productos.
Este conjunto de iniciativas (CMM, Trillium, Bootstrap, Technology
Diagnostic ...) propició, al inicio de la década de los años noventa, el sentimiento
generalizado de la necesidad de promover un estándar internacional que
armonizara los modelos de referencia existentes.
El proyecto SPICE, promovido por ISO (International Organization for
Standards) surgió como un esfuerzo de colaboración internacional que debía
materializarse en un nuevo estándar para la valoración del proceso del software. El
grupo de trabajo que llevaría a cabo esta labor (WG10) contaría con un equipo
central de profesionales con dedicación exclusiva, además de aportaciones de
investigadores, estudiosos y profesionales de más de veinte países.
SPICE debía proporcionar el soporte necesario para la elaboración de un nuevo
estándar. La realización de pruebas de campo sería una labor fundamental de la que
se deberían extraer los datos oportunos y derivar los análisis que posibilitarían la
mejora del modelo en sus diferentes borradores. La promoción del nuevo modelo y
el seguimiento del mismo con objetivo de propiciar su evolución serían otras de las
labores encomendadas al grupo de trabajo 10.
En el bienio 1993-1995 el borrador del producto fue desarrollado y se realizaron
las primeras pruebas de campo. En el verano de 1996 se reflejaron diferentes
cambios en la norma para ajustarla a los datos recogidos en las pruebas efectuadas.
En octubre de ese mismo año se celebró un encuentro en Méjico del WGlO en el

que la comunidad internacional, por primera vez, pudo conocer las partes que
definen el modelo. A mitad de noviembre de 1996 se entregó a la Secretaría del
SC7 las nueve partes de documento comenzando el período de votaciones. En la
actualidad el proyecto ha alcanzado el llamado Informe Técnico. La norma
ISOIIEC 15504 ha rebasado, por tanto, el estado del borrador DTR (Draft
Technical Report) y también la votación de los miembros del JTC1. El objeto de
este período es reexaminar la situación del informe técnico publicado y, si es
posible, alcanzar el acuerdo internacional necesario para la publicación de un
estándar internacional que reemplace al mismo.
4.12. El futuro
Podemos predecir algo del futuro en la práctica del aseguramiento de la calidad

del software gracias a las actividades que esta disciplina está desarrollando hoy en
día. Así mismo podemos inferir su desarrollo debido a la influencia que otras áreas
de la ingeniería del software han producido sobre el concepto de calidad del
software y su aseguramiento.
El aseguramiento de la calidad del software estará determinado por la segura
unión con los estándares para el desarrollo y mantenimiento del software.
Gracias al incremento de herramientas para el control y seguimiento de
proyectos, se ha de esperar un cambio en materia de auditoría. Por ejemplo, más
que examinar el contenido de un determinado fichero para evaluar el nivel de
cumplimiento de cierto modelo de documentación se ha de comprobar la
documentación suministrada por las herramientas utilizadas.
Existe una clara tendencia a incrementar el énfasis sobre la calidad del soporte
al cliente. Esto es el resultado de aplicar conceptos propios de la calidad total, ya
que en este concepto de la calidad se premia la satisfacción del cliente. Mientras
que en los primeros años de aseguramiento de la calidad del software se centró en
los procesos de desarrollo y mantenimiento el futuro demandará un incremento en
el aseguramiento de la calidad del servicio.
El uso de las telecomunicaciones para el soporte al cliente, con la resolución de
problemas enlínea, bajada de actualizaciones o control enlínea son varias de las
posibilidades de esta nueva actividad que son ya una realidad.
El interés por la programación orientada a objeto sigue creciendo, las prácticas
del aseguramiento del software deberán adaptarse a este tipo de programación.
La metodología de desarrollo propiciada por la Administración estatal española
MÉTRICA Versión 3. recoge de forma expresa el uso de técnicas de desarrollo
orientadas a objeto.
El uso de lenguajes de cuarta generación permitió un cambio del aseguramiento

del software hacia recursos de verificación de diseño y código para asegurar la
correcta aplicación de los modelos de requisitos. Esta tendencia se acentuará y se
consolidará.
Ningún cambio en la tecnología del desarrollo del software cambiará los
fundamentos del papel del concepto de aseguramiento de la calidad del software,
en el sentido de la captura de problemas lo antes posible y mantener un control
sobre el software como producto final. De hecho no existe una diferencia intrínseca
entre la metodología aplicada a los entornos orientados a objeto y los aplicados al
desarrollo de aplicaciones con lenguajes de cuarta generación.
La filosofia de la administración en el proceso de la calidad puede tener un gran
efecto en el aseguramiento de la calidad del software. El modelo de calidad total
que distribuye la responsabilidad de la calidad sobre los trabajadores de toda la
compañía deben influir en el aseguramiento de la calidad del software y, por
supuesto, de las actividades de medida, análisis, eliminación de defectos y demás
aspectos que deben ser mejorados en este ámbito. Se espera una influencia de
modelos y estándares (CMM, ISO-9000, ISO-15504 y modelos similares). No
parece, por lo tanto, discutible el auge que deberá alcanzar una aplicación de las
medidas más estructurada. Estudios sobre la medida y su verdadera significación
continúan [Fenton, 921, [Curran y Sanders, 19941, [Fenton y Pfleeger, 19971.
5. CONCEPCIONES ERRÓNEAS Y PARADIGMAS DE LA CALIDAD
A pesar de la mayor sensibilización hacia la calidad, todavía existen ideas

erróneas que van en detrimento de la obtención de productos de calidad. Entre ellas
destacaremos:
o La calidad es intangible y, por consiguiente, no puede medirse.

La calidad es cara.
0 La calidad significa lujo, peso y brillo.
o La calidad no es un problema de la gerencia y la administración.
o La calidad es responsabilidad únicamente del Departamento de Calidad.
En general, estas concepciones configuran un paradigma del enfoque antiguo

que es necesario cambiar hacia las nuevas ideas que consideran la calidad como
una estrategia global de negocio e instrumento de la gerencia. Los cambios de estos
paradigmas son los siguientes:
o Detectar errores. La antigua función de la detección y corrección de

errores es sustituida por la más activa de prevenir los errores.
o Cumplir los estandares. El cumplimiento a rajatabla de los estándares de la
organización debe de evolucionar hacia satisfacer las expectativas de los
clientes.
o Cumplir el presupuesto. El antiguo enfoque de relacionar el coste de las
funciones con el presupuesto de gastos hay que cambiarlo por el apoyo
financiero y operativo para añadir valor al producto.
o Invertir en calidad. La visión clásica de que la calidad se consigue
incrementando inspecciones y controles, los cuáles aumentan su costo, se
cambia por el enfoque hacia la calidad, disminuyendo los controles y
aumentando la prevención, ya que por este camino se ahorra dinero.
o La calidad requiere tiempo. Si se logra reducir errores, se reducen los
tiempos de producción, lo cual es una nueva reducción de costes. Por lo
tanto, la calidad aprovecha el tiempo.
o La responsabilidad de la calidad es de unas pocas personas. Esta vieja
idea hace que el resto de la organización no esté concienciada ni
preocupada por la calidad. El nuevo enfoque es que la calidad necesita de
una mejora continua y que es responsabilidad de todos.
6. COSTES DE LA CALIDAD
La implantación de un sistema de calidad conlleva unos costes que, a medio y

largo plazo, revierten en ahorros y beneficios, tanto tangibles (económicos) como
intangibles.
La figura 1.3 representa como se descompone el precio del producto entre los
diversos costos y el beneficio.
Figura 1.3. El coste de un producto.

Los costes de la calidad son suma de otros tres costes: Los costes de las
acciones no previstas (costes de no-calidad), los costes de prevención y los costes
de la inspección o costes de evaluación.
Como puede deducirse de la figura para aumentar el beneficio es necesario
reducir principalmente los costes de la no calidad.
6.1. Costes de prevención
Son los costes en que se incurren para evitar la comisión de errores en

cualquier función de la empresa, desde el diseño a la venta, pasando por
administración, personal, producción, etc.
Algunos de estos costes son: revisión del diseño, programas de formación,
evaluación de proveedores, revisión de especificaciones, mantenimiento
preventivo, etc.
En contra de lo que generalmente se cree, la mayoría de los fallos tienen su
origen en el equipo directivo, hasta un SO%, como se indica en la figura 1.4.
Equipo directivo: 80%
Mantenimiento
Planes de formación
\ / Trabajo \ /
Operario: 20%
Figura 1.4. Origen de los fallos en una organización.

6.2. Costes de evaluación
Incluye todos los gastos relacionados con la inspección de la producción ya

terminada y de las auditorías sobre la conformidad de las funciones con los
criterios y procedimientos establecidos. Por ejemplo: las inspecciones, las pruebas,
el control de recepción de los productos de los proveedores, la aceptación del
producto, el estudio del cumplimiento con las especificaciones, etc.
6.3. Costes de la no calidad
Son todos los costes relacionados con los errores de producción. Antes o
después de su entrega al cliente, incluyendo las acciones correctiva, la garantía o la
pérdida de confianza del cliente.
Según estudios de Arthur Andersen, la falta de calidad provoca las siguientes
consecuencias negativas para la empresa:
o Cuesta cinco veces más obtener un cliente nuevo que retener a uno antiguo.
o Sólo el diez por ciento de los clientes que han tenido una mala experiencia
vuelve a repetir la compra.
o Sólo el cuatro por cientos de los clientes defraudados se lo comunica al
proveedor.
o Un cliente insatisfecho comenta su caso con, al mínimo, diez personas.
6.4. Relación coste/beneficio
Según se aumenta la calidad del producto los costes de la no calidad

disminuyen, pero al mismo tiempo el coste del sistema de calidad aumenta. El
perfeccionismo resulta caro. El gráfico de la figura 1.5 muestra como el coste total
mínimo de la calidad se alcanza en un punto lejos del 100% de la calidad. Muchas
veces será necesario aumentar los costes para obtener una calidad aceptable por el
cliente.
Costes
1 Costes no calidad
Calidad (%)
Figura 1.5. Costes de la no calidad.
Si se actúa de forma que se reduzcan las acciones no previstas es posible

conseguir un ahorro potencial de los costes totales de la calidad y por consiguiente,
un mayor beneficio, como puede observarse en el diagrama de barras de la figura
1.6.
COSTE f BENEFllrSIO
Figura 1.6. Relación costeheneficio de la calidad.

6.5. La Regla Federal Express
La empresa de mensajería urgente líder en Norteamérica, Federal Express,

considera que sus gastos anuales por acciones no previstas (errores en los destinos,
retrasos aéreos, reclamaciones de facturas, etc.) superan los 800 millones de
dólares, teniendo en cuenta los errores cometidos y la pérdida de clientes. Estos
costes se expresan mediante la regla "1-10-100". Esta regla indica que si un
problema se detecta en el momento que ocurre, su coste es de un dólar por hora. Si
es detectado más tarde, cuesta 10 dólares. Por último, si es detectado por el cliente,
estos costes se elevan a unos 100 dólares.
Por consiguiente, es necesario hacer las cosas bien a la primera mediante la
estructuración de los procesos. Como consecuencia, se podrá ahorrar tiempo y
dinero, proporcionando al cliente un mejor servicio que ayudará a ganar su
fidelidad. Esta es la regla de oro de la calidad total.
Capítulo 2
LA MEDIDA DE LA CALIDAD DEL SOFTWARE

Una diferencia principal entre una "bien desarrollada"
ciencia como la física y algunas de las menos "bien
desarrolladas" ciencias tales como la sicología o
sociología es el grado en el cual las cosas son medidas.'
El objetivo actual de las industrias, incluida la industria de la producción del

software, es la calidad. Pero para alcanzarla es necesario saber en qué situación se
está, y por tanto es necesario estimar o medir la calidad. Se inicia este capítulo con
las definiciones de estimación y medida con sus respectivas características y
propiedades. Se presenta la teoría de la medida y una aproximación histórica a su
aplicación a la industria del software. Se estudiarán, igualmente, las medidas más
importantes propuestas en la historia breve, pero intensa, de la ingeniería del
software.
A mediados de la década de los sesenta el desarrollo de programas para

ordenador presentaba serias disfunciones. Pobre calidad en los sistemas,
aplicaciones entregadas fuera de plazo y con numerosos errores y elevados costes
de mantenimiento eran hechos que se repetían con demasiada asiduidad
' Roberts, Fred S. Measurement Theory with Applications to Decisionmaking, Utility, and the Social Sciences.
Encyclopedia of Mathematics and its Applications. Addison Wesley Publishing Cornpany, 1979.
Roberts, Fred S. Director del Centro de Matemáticas Discretas y Teoría de la Ciencia Computacional, consorcio
formado por las universidades de Rutgers y Princenton junto a diversas empresas tecnológicas (AT&T, Lucent
Technologies, NEC, entre otras). Consultar la dirección de intemet http:// dimacs.mtgers.edu/index.html.
64 LA MEDIDA DE LA CALIDAD DEL SOFTWARE
[Marciniak, 19941. La situación era de tal gravedad que la Organización del

Tratado del Atlántico Norte (OTAN) patrocinó en otoño de 1968 una conferencia
internacional en Garmisch-Partenkirchen, Alemania, en la que se dieron cita medio
centenar de los más afamados estudiosos de la disciplina informática. Esta
convención supuso uno de los más importantes hitos en la moderna historia del
software. En ella no sólo se reconoció el estado de crisis en el que se encontraba el
desarrollo de programas para ordenador, sino que también se aportó la solución. En
1968 se acuñó el concepto de "ingeniería del software" como una nueva disciplina
al servicio del desarrollo estructurado y metodológico de los programas
informáticos. La unión de estas dos palabras "ingeniería" y "software'', no fue un
hecho espontáneo, tal y como reconocieron los propios organizadores. En las actas
se recogen diferentes apreciaciones en este sentido, siendo una de las más explícita
la cita siguiente:
"La frase "ingeniería del software" fue deliberadamente escogida por

provocadora, dando a entender la necesidad de que la manufactura del
software se base sobre tipos de fundamentos teóricos y disciplinas
prácticas, que son tradicionales en ramas establecidas en la ingeniería."2
Más de veinte años después Norma E. Fenton se cuestiona ''¿Algo ha ido mal o
esperamos demasiado, demasiado pronto?"3. Esta pregunta se justifica, cuatro
lustros después de la conferencia de Garmish, en la situación en la que el desarrollo
de programas para ordenador se encuentra sumido y que ~ i b b ilustras ~ de forma
contundente:
"... por cada seis nuevos sistemas de programación de gran tamaño que
entran en servicio, otros dos quedan cancelados. Los proyectos de

desarrollo de programas de tamaño medio suelen consumir vez y media el
tiempo previsto, situación que empeora en los grandes. Y alrededor de tres
cuartas partes de todos los sistemas de gran tamaño son "fracasos
operativos", lo que significa que o no funcionan como se quería o no se
utilizan para nada."5
James E. Tomayco. "Milestones in Software Engineering", Encyclopedia of Software Engineering, John Wiley
& Sons, 1994. pp. 687-697. La traducción es nuestra.
Fenton, Norman E. Sojiware Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. Pág 5 . La
Gibbs, W. Wayt. Licenciado en Física e Inglés por la universidad de Comell, afamado articulista de Scientijc
American, ha publidado numerosos artículos sobre el software y ciencias afines. Ha desarrollado labores de
investigación en nanotecnologia y biotecnologia en el MIT. Consultar http:l/web.mit.edu/knight-sciencel
Gibbs, W. Wayt. "La crisis crónica de la programación", Investigación y Ciencia, Tendencias en Informática.
Pág. 73.
2. NECESIDAD DE LA MEDIDA DEL SOFTWARE
2.1. La medida como elemento de mejora metodológica
La respuesta a las reflexiones de Fenton nos la proporciona él mismo al

considerar que, a pesar de una clara aproximación a un proceso metodológico en el
desarrollo de programas informáticos, éste no ha considerado la medida del
software con la profundidad y rigor que se requiere, "mejoras metodológicas en
solitario no hacen una disciplina ingenierilW6.Parece evidente que el proceso
estructurado del desarrollo del software ha proporcionado una clara evolución en la
programación informática, muy alejada de filosofía general de programación
manejada en los orígenes de los ordenadores de propósito general, en la que el
técnico desarrollaba el programa, lo probaba, corregía e incluso utilizaba, tras un
proceso de creación artesanal y sin apenas hacer uso de herramientas o
metodología alguna. Pero este hecho no ha erradicado severos problemas tal y
como nos demuestra la estadística mencionada en la última cita.
Bajo esta realidad podemos indicar que en estos momentos existe una clara
tendencia hacia la obtención de medidas rigurosas, también en el software. No es
extraño encontrar referencias enérgicas en esta dirección aportadas por estudiosos
que nos hacen recordar otras declaraciones, no menos tajantes, enunciadas por
científicos de otras disciplinas, ramas del saber que vieron en el proceso de medida
una base hndamental en su trabajo. Así, por ejemplo, Tom ~ e ~ a r apunta c o ~ que
8
"no podemos controlar aquello que no se puede medirw , Fenton va más allá y
sentencia, "la producción de software está fuera de control porque no se puede
medirm9.
La medida del software no es una aspiración nueva, tal y como comprobaremos
en el siguiente apartado, pero quizás ha sido la década de los años noventa aquella
en la que se ha reconocido toda la importancia que esta actividad posee. En la
conferencia celebrada en París Eurometrics 1991, H. D. ~ o m b a c h " perteneciente
Fenton, Norman E., op. cit. pág. 5. La traducción es nuestra.

' DeMarco, Tom. Graduado por las universidades de Columbia, Cornell y La Sorbona de París, comenzó su
carrera profesional en los laboratorios Bell. Ha trabajado en numerosos proyectos entre los que cabe destacar la
implantación de sistemas informáticos bancarios en Holanda, Suecia, Finlandia y Francia. En 1999 se le concedió
el premio Stevens por su contribución a la ingeniería del software. Consultar Encyclopedia of Software
Engineering, John Wiley & Sons, 1994.
Tom DeMarco. Controlling Software Proyects: Management, Measurement and Estimation. Englewood Cliffs,
New York. Prentice Hall, 1982. La traducción es nuestra.
'O ~ o m b a c hH.
, Deiter. Profesor de Ciencia de la Computación en la universidad de Kaiserlautern en Alemania. Ha
centrado su investigación en la calidad del software y su medida. Consultar Encyclopedia of Software
al Software Engineering Laboratory (SEL), afirmó "no deberíamos preguntarnos

por más tiempo si debemos medir, la cuestión hoy en día es cómo.""
2.2. La medida y el conocimiento
Las ciencias empíricas, junto con las diferentes ingenierías, poseen en el

proceso de medida una larga tradición y fundamentado conocimiento, alcanzado
gracias a siglos de investigación y aportaciones de eminentes científico^'^. La
trascendencia que a esta actividad se le ha conferido queda patente en actitudes
reflejadas en citas como aquella que ilustra este capítulo, u otras de no menos
compromiso o rotundidad. Lord Kelvin, el famoso matemático y físico británico, a
finales del siglo pasado sentenciaba:
"Cuando puedes medir aquello de lo que hablas, y expresarlo en números,

tú conoces algo acerca de ello; pero cuando no puedes medirlo, cuando no
puedes expresarlo en números, tu conocimiento es insatisfactorio y escaso:
podría ser el comienzo del saber, pero apenas has avanzado en tus ideas
hacia un estado ~ientífico"'~.
Medir es conocer, y este conocimiento nos permite avanzar sobre bases sólidas.
Pero medir nos proporciona algo más, nos posibilita aplicar las poderosas
herramientas que las matemáticas nos ofrecen, facilitando la manipulación de datos
con objeto de alcanzar una visión de la entidad estudiada que de otra forma hubiera
sido imposible obtener.
2.3. Importancia de la medida
La trascendencia de la actividad, centro de atención de este capítulo, va más allá

de lo expuesto. La consecución de nuevas, y cada vez más exactas medidas, ha
impulsado la aparición de novedosas técnicas y sofisticado instrumental, pero
" Software Engineering Laboratory. Collected Software Engineering Papers. Vol.: X, SEL-92-003, November,
1992. Pág. 164. La traducción es nuestra.
" Existen numerosos ejemplos que ratifican esta afirmación. Muchos de ellos representaron el comienzo de una
nueva era para la investigación o un avance sustancial en campos científicos de muy diversa orientación. Galileo
Galilei (1546-1642) inventó el termómetro, paso fundamental para el desarrollo de la termodinámica. Evangelista
Torricelli (1608-1647) en 1643, realizó el experimento que permitió la invención del barómetro. Henry Cavendish
(173 1 -181O), inventor de la balanza que lleva su nombre, permite el cálculo de la masa de un cuerpo basándose en
la fuerza de atracción ejercidas por ambas debido a la interacción gravitacional. Willian Crookes (1832-1919)
inventó el radiómetro en 1875. Aparato diseñado para la medida de la energía de una radiación. O los modernos
sistemas del cálculo de distancias basados en el haz láser, son ejemplos que nos permiten afirmar la importancia
que los científicos de todas las épocas han dado a la obtención de medidas fiables. Consultar enciclopedia Salvat
Universal. Barcelona. 1996.
l 3 Kelvin, Willian Thomson, referencia en: Alan L. Mackay. Diccionario de citas científicas. Ediciones de la
Torre. 1992.
también ha provocado el progreso de disciplinas concretas, estimulando la

aparición de innovadoras hipótesis de notable importancia. Medir, como tarea
científica en sí misma, es un verdadero generador de nuevas teorías que han
permitido abrir nuevas perspectivas a muy diferentes campos de investigación. Un
claro ejemplo de este hecho lo tenemos en el desarrollo teórico del concepto de
"temperatura empírica" aportado por la termodinámica. Partiendo, en sus más
remotos orígenes, de la concepción fisiológica de caliente y frío, la diferenciación
entre calor y temperatura no fue correctamente interpretada hasta la intervención en
1760 de Joseph ~ l a c k 'quien
~ aportó la definición de calor específico. Casi un
siglo más tarde, en 1843 James P. ~ o u l e determinó
'~ el equivalente mecánico del
calor, asimilando esta entidad a la energía interna de un cuerpo teóricamente
distinta de la concepción de temperatura, definida como una función de estado, es
decir, dependiente de variables que permite especificar su estado de equilibrio
térmico. Una actividad tan habitual y aparentemente simple como es conocer la
temperatura a la que se encuentra una habitación se apoya en un profundo y
científico conocimiento del atributo que está siendo medido.
Las ingenierías, como disciplinas que aplican el conocimiento científico sobre
construcciones o artefactos que nos son útiles, no son ajenas a la trascendencia del
proceso de medida. Modelos matemáticos y teorías deben apoyarse en medidas
fiables. Si deseamos conocer la resistencia que cierto circuito eléctrico opondrá al
paso de la corriente, es de obligado conocimiento el voltaje soportado por el
mismo, así como la intensidad de corriente que fluirá por el conductor. Sin estos
datos o con información errónea la ley de Ohm sería de muy difícil aplicación.
Esta concepción del desarrollo científico, apoyado en la obtención de medidas
fiables, se encuentra avalada por el método científico, verdadera columna vertebral
del conocimiento científico y tecnológico, por lo que no nos ha de extrañar el
trascendental papel que esta actividad ha jugado en el devenir científico desde hace
siglos.
l 4 Black, Joseph. Químico y fisico escocés del siglo XVIII. Entre otras aportaciones descubrió el calor latente y el
calor especifico. Consultar enciclopedia Salvat Universal. Barcelona. 1996.
l 5 Joule, James Prescott. Físico británico del siglo XIX. Estableció la teoría mecánica del calor. Consultar
enciclopedia Salvat Universal. Barcelona. 1996.
3.1. Definición y problemática
La estimación es el proceso de predicción de la duración, esfuerzos y costes

necesarios para realizar todas las actividades y obtener todos los productos
asociados a un proyecto.
Es necesario tener en cuenta numerosos aspectos que afectan a la estimación
como la complejidad del proyecto, su estructuración, el tamaño, los recursos
involucrados y los riesgos asociados.
La estimación es siempre difícil de realizar por diversas razones, entre las que
se encuentran:
No existe un modelo ni una fórmula de estimación universal.

Son muchas las personas implicadas en el proyecto, desde la alta dirección
de la empresa a los ejecutivos del proyecto, que precisan de las
estimaciones.
La utilidad de una estimación varia con la etapa de desarrollo en que se
encuentra el proyecto.
Las estimaciones precisas son difíciles de formular, sobre todo al inicio del
proyecto.
La estimación suele hacerse superficialmente, sin tener en cuenta el
esfuerzo necesario para hacer el trabajo.
La rapidez del cambio de las metodologías y las tecnologías no permiten la
estabilización del proceso de estimación.
Los estimadores pueden no tener experiencias.
El estimador suele hacer la estimación en función del tiempo que a él le
llevaría en realizar el trabajo, sin tener en cuenta la experiencia y formación
de la persona que realmente lo realiza.
Existen malas interpretaciones en las relaciones lineales entre la capacidad
requerida por unidad de tiempo y el tiempo disponible. Como consecuencia
se cumple una de las leyes de Murphy, que dice "la duración del trabajo se
ajustará como mínimo al tiempo disponible. Añadir recursos un proyecto
retrasado, no tiene por qué disminuir el retraso."
El estimador tiende a reducir en alguna medida sus estimaciones para hacer
mas aceptable su oferta.
3.2. Los métodos de estimación
Además de los métodos algorítmicos se suelen utilizar por su sencillez los

siguientes:
El juicio del experto
La realidad indica que el método utilizado en gran parte de los proyectos

software, y en numerosas empresas en el momento de estimar el coste de los
desarrollos se basan principalmente en juicios emitidos por uno o varios expertos
avalados por su experiencia en entornos similares y apoyados, aunque no en todos
los casos, en datos objetivos obtenidos de proyectos anteriores y almacenados en
bases de datos históricas.
El método de Wideband Delphi es una aproximación que se puede definir como
un protocolo multipaso cuyo fin es hacer coincidir la opinión de un grupo de
expertos evitando así estimaciones parciales de individuos aislados. Los pasos a
ejecutar serían:
1. El coordinador del equipo técnico de expertos presenta a cada uno de ellos

una especificación de estimación.
2. El coordinador convoca una reunión con el grupo de expertos para que se
produzca un intercambio de opiniones entre ellos sobre el producto y sus
estimaciones.
3. Cada experto aporta su estimación.
4. El coordinador remite a cada experto un informe con el valor medio de las
estimaciones obtenidas así como el valor propuesto por cada individuo.
5. Se convoca una segunda reunión entre expertos.
6. Los expertos vuelven a emitir sus estimaciones de forma independiente.
7. Se repiten los pasos 2 al 6 hasta la obtención de un valor en el que todos los
expertos estén de acuerdo.
Este método tiene como desventaja evidente el alto coste en tiempo y recursos
humanos necesarios para su implantación, así como la subordinación al nivel de
experiencia y conocimientos en el entorno que puedan aportar los técnicos.
Como ventajas se podrían indicar que las estimaciones parciales son
neutralizadas y se presenta una estimación global. Por otro lado las estimaciones
suministradas por este grupo de expertos difícilmente pueden ser obviadas gracias
a la trascendencia que la organización otorga a este proceso al proporcionar
costosos recursos a esta tarea.
La analogía
Se hace la estimación de un proyecto nuevo por analogía con las estimaciones

de proyectos anteriores comparables y que estén terminados.
La ley de Parkinson
En 1987, C. N. Parkinson formuló unas leyes que, reformuladas, se pueden

aplicar a la ingeniería del software. Una de ellas dice "los programas son como los
gases perfectos, ocupan todo el espacio que se les da". Esto significa que la
estimación del esfuerzo se hace en base a los recursos disponibles y no al producto.
La mejor oferta
Se procura conocer hasta cuánto el cliente está dispuesto a pagar y cuáles son
las ofertas de la competencia. El valor que permite lograr el proyecto se toma como
estimación del esfuerzo.
Las estimaciones global y detallada
La estimación global, también denominada descendente, se hace teniendo en

cuenta las funcionalidades del producto, pasándose posteriormente al detalle.
La estimación detallada o ascendente empieza por la estimación de los
esfuerzos individuales, los cuales se suman para obtener el esfuerzo del proyecto.
Tiene el peligro de olvidarse de las tareas generales.
3.3. Las reglas de estimación de De Marco
De Marco formuló las siguientes nueve reglas, relativas a la estimación:
1. Estimar no es repetir.
2. Estimar no es negociar.
3. Las estimaciones no admiten regateo.
4. Estimar no es dividir en partes una duración fija.
5 . Un retraso en una fase de un proyecto implica un retraso proporcional en
todas las fases siguiente.
6. Si desea que se le proporcione una estimación significativa, no sugiera la
respuesta.
7. Una estimación útil es una proyección en la que la probabilidad no es
optimista ni pesimista.
8 . El ratio entre la estimación más optimista y la útil es medianamente

uniforme para cualquier persona.
9. Las estimaciones deben formularlas un comité.
3.4. Evaluación de las estimaciones
Una primera evaluación de una estimación sería la diferencia entre el esfuerzo

estimado y el real. Pero un error de, por ejemplo, 5 horas-hombre en un proyecto
de 1000, no es el mismo que en un proyecto de 20.000 horas-hombre. Por
consiguiente se suele utilizar el test de porcentaje de error dado por la fórmula:
(Estimado - Real) 1 Real
Hay que tener en cuenta que los errores pueden ser de infravaloración o de
sobrestimación, cuya importancia sigue la ley de Brooke, en el primer caso, y la de
Parkinson, en el segundo. Los dos tipos de errores no se anulan uno al otro cuando
se hace la media de numerosos errores.
En los primeros años de la era de la programación, la década de los cuarenta, el

hardware fue el principal objeto de estudio y atención por parte de investigadores
y científicos. Los emergentes sistemas de información automatizada giraban en
torno a los equipos y su optimización. Hoy en día, por el contrario, es el software el
componente que aporta un mayor valor añadido a estos sistemas. Si, además,
consideramos que el soporte informático es una actividad estratégica de primer
orden en la sociedad actual, no es extraño que el cumplimiento de plazos y costes
sea una exigencia inevitable en el proceso de creación del software.
El conocimiento de costes y esfuerzos futuros permite prever la asignación de
recursos adecuándolos a las necesidades venideras.
Se presenta como evidente que estimar, es decir, conocer cuál será el valor de
cierta magnitud, no es una tarea simple, más aún en una disciplina joven como es el
caso del desarrollo de programas informáticos, y en el que factores de muy diversa
naturaleza están presentes. Sin embargo, esta decisión por vaticinar el futuro
basándose en datos del presente y en estudios anteriores, ha permitido un cierto
desarrollo de métodos y modelos matemáticos.
4.1. Definiciones de coste y esfuerzo
El coste y el esfuerzo son atributos propios del proceso de desarrollo del

software. Dependiendo del modelo utilizado para su medida serán necesarios datos
de diferente naturaleza tal y como observaremos en los modelos que se explicarán.
Como paso previo a su estimación definamos estos atributos.
El esfuerzo se entiende como el tiempo necesario para la realización de una
cierta tarea por parte del equipo de desarrollo. Suele venir expresados en hombre-
mes.
El coste se encuentra relacionado directamente con el esfuerzo de cada tarea
aunque en este caso se exprese en términos económicos.
4.2. Los principales modelos
Los modelos matemáticos más importante en la estimación del coste y esfuerzo

son COCOMO, SLIM y Puntos de Funcionalidad, al que se dedicará un capítulo.
Es posible que alguno de estos métodos sea citado en otros apartados del libro ya
que han sido utilizados para la medida de otros atributos del software, como en el
caso del tamaño o en la medida de la calidad. Sin embargo, en este capitulo es
donde se hará una explicación más extensa y detallada de los dos primeros.
El modelo COCOMO (COnstructive COst MOdel) fue ideado por Boehm, el
modelo Punto Función lo desarrolló Albretch y el SLIM (Software, LIfe Cycle
Management) fue creado por Putman.
El modelo COCOMO y el de Punto Función pueden encuadrarse en aquellos
modelos empíricos dependientes de una variable principal a los que se añaden
factores de ajuste relacionados con la productividad. Son dos claros ejemplos de
modelos estáticos.
El modelo SLIM es un modelo dinámico que realiza una repartición del
esfuerzo en función del tiempo.
4.3. COCOMO
El modelo COCOMO permite la estimación del esfuerzo como una medida

indirecta del el tamaño del código fuente. Boehm presentó este método en su libro
Software Engineering Economics, publicado en 1981.
El modelo de Boehm basa su estimación del esfuerzo en la posibilidad de
conocer el tamaño del programa, es, por tanto, una traslación del proceso
predictivo desde un atributo (esfuerzo) a otro (tamaño). Este modelo fue ideado
tras el estudio de 63 proyectos software realizados por el autor, y ha sido de
indudable impacto en la ingeniería del software.
El modelo COCOMO se basa en la existencia de tres niveles que han de

aplicarse según el estado en que se encuentre el desarrollo del proyecto.
Modelo básico. Se utiliza al principio del proyecto. La información que facilita

es una estimación en cuanto al orden de magnitud del esfuerzo.
Las ecuaciones que rigen este modelo son:
E = a (KLOC)~ Ecuación 2.1
T = C E ~ Ecuación 2.2
Donde E es el esfuerzo expresado en personas-mes, el número de líneas de

código estimadas excluyendo comentarios (en miles) viene indicado por KLOC.
Los valores a, b, c, d son valores constantes (tabla 2.1) que dependen de la clase de
proyecto o "modo" que estemos evaluando. El valor T representa el número de
meses estimados para el desarrollo.
Tabla 2.1. COCOMO básico.
Los posibles modos son:
Orgánico. Equipos pequeños de trabajo. Existe un buen conocimiento de la

aplicación y del sistema utilizado. Poca influencia de las comunicaciones.
Semiacoplado. Se sitúan en una posición media en cuanto a complejidad y

tamaño, entre el modo Orgánico y el Integrado. Equipo formado por expertos y
principiantes. Se han de satisfacer requisitos no excesivamente estrictos. Por
ejemplo aplicaciones bancarias o que impliquen transacciones con bases de datos.
Integrado. Sistema hardwarelsoftware complejo con influencia clara de la

seguridad o tiempo real. Costes de validación muy elevados. Requisitos estrictos e
inamovibles. Un ejemplo claro lo tendríamos en el software de control de un
sistema de defensa o de una central nuclear.
Modelo intermedio. Se aplica cuando el proyecto ha sido dividido en

subsistemas. En este modelo se han de considerar factores relativos a atributos del
producto software y de recursos (materiales, métodos y personal). Lo valores de las
constantes también se ven afectadas.
En este caso la ecuación es:
E = a ( K L D C )m(x)
~ Ecuación 2.3
Donde E, KLOC, a y b tienen el mismo significado que en el caso del

COCOMO básico. Aunque el valor de los parámetros a y b son diferentes (tabla
2.2).
El valor m(x) es el peso del factor de coste xj, y cuya expresión matemática es:
15
m(x)=n Ecuación 2.4
El valor m(x) en el caso del modelo básico tiene como valor fijo la unidad.
Boehm consideró quince factores de coste diferentes, agrupados según el
siguiente esquema.
1 . Atributos del producto.

1 . 1 . Fiabilidad requerida.
1.2. Tamaño de la base de datos.
1.3. Complejidad del producto.
2. Atributos de los recursos.
2.1. El material.
2.1.1. Restricciones del rendimiento en tiempo de ejecución.
2.1.2. Restricciones de memoria.
2.1.3. Inestabilidad de la máquina virtual.
2.1.4. Tiempo de espera requerido.
2.2. El personal.
2.2.1. Capacidad de análisis.
2.2.2. Capacidad del ingeniero de software.
2.2.3. Experiencia en aplicaciones.
2.2.4. Experiencia con máquina virtual.
2.2.5. Experiencia con lenguaje de programación.
2.3. Métodos y herramientas.
2.3.1. Práctica de los métodos modernos de programación.
2.3.2. Utilización de herramientas de software.
2.4. Tiempo.
2.4.1. Planificación temporal del desarrollo requerida.
Cada factor es valorado por separado en una escala ordinal de seis puntos (muy
bajo/bajo/nominal/alta/rnuy altalextra alta). A partir de las tablas hechas públicas
por Boehm se asigna un valor numérico a cada factor y se aplica la ecuación 2.4, el
resultado es el factor de ajuste del esfuerzo.
Tabla 2.2. COCOMO intermedio.
COCOMO detallado. El modelo de COCOMO detallado se basa en dividir el

esfuerzo en fases, de forma que para cada una de ellas se obtenga el factor de coste
correspondiente. Finalmente se ha de sumar cada uno de ellos para obtener el
global.
Como guía para el uso del modelo COCOMO, en cualquiera de sus variedades,
podemos indicar los siguientes pasos a seguir:
1. Identificar el "modo" de desarrollo para el nuevo proyecto.

2 . Estimar el tamaño del proyecto en KLOC y derivar una predicción del
esfuerzo.
3. Determinar el valor de los 15 valores de ajuste.
4. Hacer uso de la ecuación de estimación del esfuerzo.
5. Hacer uso de la ecuación que estima el tiempo de desarrollo.
El modelo COCOMO posee un claro inconveniente al involucrar la evaluación

del número líneas de código en el propio sistema de predicción. Por otro lado la
selección del modo de desarrollo es extremadamente importante. El modelo
COCOMO es un modelo muy dependiente de datos históricos de la organización
que no siempre están disponibles.
En el aspecto positivo indicar la transparencia del modelo así como el acierto de
los factores definidos para obtener el factor de ajuste al ser de gran ayuda al técnico
a la hora de entender el impacto de cada factor en el proyecto software.
4.4. SLIM
El modelo de Putnam, Slim, se apoya en que la distribución del esfuerzo en un

proyecto software viene especificado por la denominada curva de
RayleighINorden. Esta curva se obtuvo basándose en datos recopilados por Norden
y las descripciones analíticas de las curvas realizadas por Lord Rayleigh.
Putnam propuso la siguiente "ecuación del software".
L = CkK113 td413 Ecuación 2.5
Donde L es el número de líneas de código esperadas en magnitudes de

sentencias fuente, Ck es una constante dependiente del nivel tecnológico en el que
se desarrolla la aplicación, suele obtenerse gracias a datos históricos recopilados de
desarrollos anteriores. El factor K es el esfuerzo de desarrollo expresado en
personas-años y finalmente tdes el tiempo de desarrollo expresado en años.
De la ecuación 2.5 podemos obtener fácilmente la ecuación:
',
K = / td4) Ecuación 2.6
L ~(ck3
De esta segunda ecuación podemos deducir interesantes conclusiones. El factor

td al estar afectado por una potencia tal alta indica que pequeñas variaciones en el
tiempo de entrega pueden modificar enormemente el esfuerzo a realizar. Por otro
lado también observamos la dependencia de este modelo del valor asociado a Ck ,
hecho que gran cantidad de especialistas consideran una desventaja, ya que
pequeñas modificaciones en este valor implican grandes modificaciones en el valor
del esfuerzo.
Tabla 2.3. Algunos valores de Ckpropuestos por Pressman.
Putnam definió la denominada aceleración de la potencia de trabajo como
D , = K I ~ ~ ~ Ecuación 2.7
LA CALIDAD DEL SOFTWARE Y S U MEDIDA 77
Esta ecuación es sumamente útil a la hora de comparar los modelos de Boehm y

de Putnam. El tiempo de desarrollo es proporcional a la raíz cúbica de K, valor
similar al propuesto por Boehm que recordemos oscilaba entre (0,32 y 0,38). Por
otro lado el esfuerzo es proporcional a la potencia 917, es decir, 1,28 también
similar al exponente del modelo COMOCO que oscilaba entre 1,05 y 1,20. El
valor Do toma valores específicos para diferentes modalidades de desarrollos, así
en el caso de nuevo software con interacciones con otros sistemas el valor Do e s
7,3, si es un sistema aislado es 15 y para sistemas con gran cantidad de
reutilización de código el valor es de 27.
El modelo de Putnam ha recibido algunas críticas como es el hecho de que las
curvas de Rayleigh y Nordem no consideran la fase de especificación de requisitos,
por lo que no se tiene en cuenta esta fase del desarrollo en la correspondiente
ecuación propuesta por Putnam. Por otro lado algunos técnicos consideran difícil
utilizar este modelo en entomos de desarrollo pequeños. Esta limitación tiene su
origen que los datos recopilados para su creación han sido tomados en entornos de
desarrollo grandes.
Q 1 2 3 4 5
Figura 2.1. Aproximación a las Curvas de Rayleigmorden.

5. MEDIDA
5.1. Definiciones
Se encuentran diferentes definiciones que identifican la actividad de medir. De

entre todas ellas la más adecuada es la propuesta por Norman E. ent ton'^ que
define la accióp de medir de la siguiente forma:
o Medir. Proceso a través del cual números o símbolos son asignados a

atributos de entidades en el mundo real de tal manera que los describe de
acuerdo a reglas claramente dejinidas17
De igual manera se define el resultado de este proceso, es decir, la medida

como:
o Medida. Una medida es una asignación objetiva y empírica de un número

(o símbolo) a una entidad para caracterizar un atributo especifico".
Se puede clasificar las medidas realizadas en dos tipos bien definidos, medidas
directas y medidas indirectas. Se definen de la siguiente manera:
o Medida directa. La medida directa de un atributo es una medida que no

depende de medidas de otros atributos.
o Medida indirecta. Medida indirecta de un atributo es aquella que

involucra la medición de otros atributos (uno o varios) 19.
En numerosos casos la obtención de medidas indirectas es enormemente útil.

Atributos, de muy diversa naturaleza, pueden ser estudiados más adecuadamente
haciendo uso de este tipo de medidas.
Algunos conceptos utilizados en la medida de atributos propios del software se
han utilizado de forma poco concisa e incluso contradictoria. Este es el caso de la
palabra métrica. Para evitar confusiones y sentar una definición objetiva definimos
métrica de la siguiente forma:
l 6 Fenton, Norman. Profesor de la Universidad de Queen Mary (Universidad de Londres). Ha sido investigador
principal de en numerosos proyectos relacionados con la medida del software, métodos formales y aspectos
teóricos de la ingeniería del software. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
l7 Fenton, Norman E. Sojiware Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. Pág. 3. La
'' Fenton, Norman E., op. cit. pág. 17. La traducción es nuestra.
l9Fenton, Norman E., op. cit. pág. 19. La traducción es nuestra.
o Métrica. La caracterización numérica de un atributo "simple" en

contraposición al concepto de medida, entendido como función cuyos
parámetros serán las métricas obtenidas y que nos permitirán estudios de
atributos más complejos20.
Evidentemente en el entorno de la medida del software el concepto "métrica" no

tiene relación con el concepto asociado al espacio métrico propio de la topología en
las matemáticas.
Las definiciones anteriores unidas a la teoría representacional de la medida que
a continuación introduciremos nos permiten definir un marco teórico apropiado del
que luego haremos uso para ajustarlo definitivamente al medio informático.
5.2. Teoría general de la medida
La teoría de la medida se sustenta en el teorema de representación, teorema de

unicidad y la definición del sistema de relación. Expliquemos cada uno de ellos.
El "sistema de relación empírico" tiene como función determinar las
propiedades (o axiomas) acerca de los atributos, las cuales capturan cualquier
comprensión intuitiva u observación empírica sobre los mismos. La medida es
precedida del concepto (recordemos el desarrollo de la noción de temperatura
empírica reseñada en el apartado anterior), de forma que un atributo ha de ser
caracterizado a partir de las relaciones empíricas que podamos establecer, primer
paso hacia la consecución de su medida.
De manera formal, los atributos se encuentran caracterizados por un conjunto de
relaciones empíricas " R , que unido al de entidades "C", constituyen el
denominado sistema de relaciones empíricas.
En lenguaje propio de las matemáticas podemos escribir:
c (C, R)
siendo:
C: Sistema de relación empírico.

C: Conjunto de las entidades consideradas.
R: Conjunto de relaciones observadas sobre las entidades.
Así, por ejemplo, podríamos considerar un conjunto de entidades y relaciones

de la siguiente manera:
20
donde las relaciones involucrarían elementos del conjunto C.
Habríamos establecido el sistema de relaciones empírico, primer paso hacia la

medida de los atributos propios de las entidades estudiadas. Se nos presenta como
evidente que un aumento en el número de relaciones que pueden establecerse
implica un mayor conocimiento de la entidad estudiada.
Una vez establecido el sistema de relación empírico, y tomando éste como base,
se ha de establecer el denominado "sistema de relación numérico", consistente en
un conjunto de números y una o más relaciones definidas sobre los mismos. Cada
relación propia del sistema empírico ha de tener su correspondiente relación en el
sistema numérico.
Matemáticamente:
N CN, P)
siendo:
N: Sistema de relación numérico.

N: Conjunto de números considerados.
P: Conjunto de relaciones observadas sobre el conjunto N.
Siguiendo con el ejemplo anterior, debemos definir el sistema de relaciones

numéricas en función al sistema empírico.
donde las relaciones involucrarían elementos del conjunto N.

Una vez definido el sistema empírico y su correspondiente sistema numérico

estamos en disposición de definir la medida de un atributo.
La medida de un atributo es una correspondencia desde un sistema de relación
empírica (C,R), para el atributo, sobre un sistema de relación numérica (N,P). La
relación, M, hará corresponder entidades del conjunto C en "números", esto es,
entidades del conjunto N, además de hacer corresponder cada relación R en una
relación en P. Como requisito adicional se ha de cumplir la "condición de
representación" que implica el que toda relación empírica ha de ser mantenida en el
sistema de relación numérico. Si la relación M cumple esta condición se denomina
homeomorfismo o representación.
En simbología matemática podemos escribir:
En diagramas de Venn y considerando los ejemplos indicados arriba, la

correspondencia podría expresarse:
Figura 2.2. Diagrama de Venn para la relación M.
La condición de representación requiere que medir sea el establecimiento entre

entidades en C y números, de tal forma que las relaciones en C inducidas por el
atributo impliquen y sean implicadas por las relaciones entre sus imágenes en el
conjunto de números elegidos. La condición de representación puede ser vista
como la definición formal de aquello que nosotros queremos hacer significar a
través de la medida, describiendo o caracterizando un atributo.
5.3. Escalas
Bajo este soporte teórico definimos el concepto de "escala" como la tripleta

(C,N,M). En muchos casos, cuando los sistemas de relación numérico y empírico
se nos presentan como evidentes la notación se simplifica y asociamos la definición
de escala con el símbolo que indica la correspondencia, es decir M.
Pueden existir diferentes escalas al poder definir varias representaciones para un
mismo sistema empírico en estudio. Para un sistema de relación dado, cualquier
correspondencia que transforme una representación M en otra representación M'
válida, se denomina representación admisible. El tipo de transformación admisible
para un determinado sistema de relación empírica define cuán única es la escala y
si puede ser utilizada como escala tipo. Esto implica que la escala tipo depende de
las reescalas permitidas. La tabla 2.4 expone las transformaciones más habituales,
hecho que definirá el tipo de escala que estemos utilizando en un momento dado.
"F" asignación uno a uno

M' = F(M)
"F" monótona creciente.
Ordinal
M(x) 2 M(y) 3 M'(x) 2 M'(y)
M ' = a M + b (a>0) Intervalo

M'=aM (a > O) Ratio
M'=M Absoluta
Tabla 2.4. Tipos de escalas más habituales.
Basándonos en los conceptos estudiados de escala describamos la noción de

"significación" en el entorno de la medida de atributos. Esta definición será útil a la
hora de establecer las limitaciones sobre el tipo de manipulaciones matemáticas a
las que podemos someter los valores resultado de una medida realizada en el
entorno de una determinada escala.
Se dice que un enunciado que envuelve escalas numéricas es significativo si su
verdad (o falsedad) permanece inalterable si cada escala M implicada es
reemplazada por una escala aceptable M'. La relación M' es una escala aceptable si
puede derivarse de la relación M por una transformación admisible.
6.1. Los orígenes
El deseo de obtener valores numéricos que representan atributos propios del

desarrollo y ejecución de programas para ordenador ha sido una aspiración para
investigadores y estudioso desde hace más de treinta años.
Uno de los primeros y principales trabajos que de forma más importante han
influenciado en la teoría aplicada a la medida del software, fue publicado en 1964
por arquitecto británico Chistopher Alexander, lo tituló Notes on the Synthesis of
Form. En su escrito Alexander describió la naturaleza del proceso de diseño según
su óptica. Para este investigador un ingenio ha sido bien diseñado si los
componentes que forman parte de él son relativamente independientes entre sí.
Alexander finalizaba su escrito presentando un programa informática cuya
aplicación sería ayudar a técnicos y profesionales en la tarea del diseño. Este
programa aceptaba como datos de entrada las relaciones existentes entre los
diferentes componentes del artefacto. Haciendo uso de un análisis en racimo
proporcionaba como resultado un diseño en el que se pretendía minimizar en
número de componentes del mismo. Como podemos apreciar la relación del trabajo
de este arquitecto con la práctica informática se produce exclusivamente en el
desarrollo del programa que ideó para ayudar a extender su visión en el diseño
industrial. A pesar de este hecho, las propuestas de Alexander han sido uno de los
pilares sobre los que se han apoyado investigadores que han apreciado en sus tesis
una concepción adecuada para el proceso de creación de productos software. Más
adelante, en este mismo capítulo, podremos apreciar hasta que punto las ideas de
Christopher Alexander han condicionado la investigación de la medida del
software.
6.2. Maurice Halstead
Maurice ~ a l s t e a d fue
~ ' el primer investigador que de forma consistente propuso
un proceso de medida para el software. Para ello se apoyó en diferentes fuentes
teóricas, que van desde la sicología del conocimiento, teoría de la información o la
termodinámica, hasta concretar un proceso de medida determinado. La filosofía
básica en la que asentó su teoría fue que la comprensión del software era similar al
proceso mental de manipulación de señales. Halstead definió un conjunto de
medidas que pueden ser extraídas del código fuente del programa. Su influencia en
'' Halstead, Maurice H. Graduado en meteorología por la universidad de Berkeley en 1940, doctor por la
universidad de Jonhs Hopkins de Baltimore, es considerado uno de los pioneros en el software para computadoras.
Realizó importantes aportaciones en la métricas del software a las que inicialmente las denominó "Termodinámica
del Software". Consultar el sitio www.itee.uq.eduíau.
la teoría informática ha sido muy importante y su trabajo fue utilizado en la

industria además de ser impulsor de la concepción de la medida del software como
actividad de principal interés para el desarrollo informático. La influencia de este
investigador se extendió de forma definitiva durante la década de los setenta y
primeros años de los ochenta y podemos hablar de centenares de estudios e
investigaciones basadas en los principios propuestos por este investigador.
~ a k e r y~ zwebenZ3
* hicieron uso de medidas basadas en la teoría propuesta por
Halstead para evaluar el grado de modularización de un sistema [Baker, 19791.
curtisZ4y SUS colegas intentaron demostrar que cierto parámetro definido por
Halstead [Halstead, 19771 era un buen sistema de predicción del tiempo de
corrección de errores [Curtis et al, 19791. Éstos son algunos de los muchos
ejemplos que podríamos aportar.
La teoría de Halstead perdió numerosos adeptos a mediados de la década de los
ochenta. Este hecho se basa en ciertos contenciosos conceptuales que esta teoría no
llegó a superar [Fenton, 19921:
o Muchas de las asunciones sobre la sicología cognoscitiva en la que se basó

Halstead se consideran ahora erróneas.
o Muchos de los experimentos realizados se encuentran pobremente
diseñados y los resultados obtenidos poseían errores estadísticos. La teoria
propuesta se basaba en medidas de carácter general, de forma opuesta a la
actual consideración de medidas específicas que respondan a preguntas
concretas.
o Las medidas propuestas se basaban en el código del programa, de forma
preponderante. Este hecho supone un grado de limitación muy elevado para
el programador, que tiene poca libertad de acción a la hora de alterar el
curso del proyecto ya que muchos recursos han sido ya utilizados pues la
aplicación ha pasado por varias fases que, quizás, deberían reconsiderarse.
o Las reglas de conteo de las que hace uso, no se encuentran totalmente
definidas.
Estas deficiencias han llevado a que las medidas propuestas por Halstead hayan
sido prácticamente eliminadas del contexto industrial, a excepción de algunos
experimentos aislados. A pesar de esta afirmación hemos encontrado investigadores
22 Baker, A.L. Matemático británico condecorado con la Medalla Fields en 1970 por su trabajo en el campo de la
teoría de los números. Consultar el sitio hnp:l/www.britannica.com.
23
Zweben, Stuart. Profesor de la universidad del Estado de Ohio y responsable del Departamento de Ciencia de la
Información y la Computación. Estudioso de la ingeniería del software, ha centrado sus estudios en la medida de la
calidad del software. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
24
Curtis, Bill. Conocido internacionalmente por sus investigaciones sobre la medida del software, diseño de
interfaces o factores humanos y de organización que afectan al proceso software. Doctor por la universidad
Cristiana de Tejas, entre otros títulos, ha publicado casi un centenar de artículos y desarrollado su carrera en
prestigiosos centros de estudio. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
que no han perdido toda la esperanza en los procesos propuestos por Halstead.
Alguno de ellos incluso lamenta la muerte de este investigador pues consideran que
su talento hubiera podido superar las críticas que ahora recaen sobre su teoría.
6.3. El control de flujo de programas
A mediados de la década de los setenta surgió un gran interés por la medida del
software basado en el control de flujo de un programa o módulo. Este hecho
coincidió con el auge de la programación estructurada como aproximación sensible
al desarrollo detallado del diseño de módulos. En este contexto teórico un sistema
un programa fácil de leer, desarrollar, mantener y corregir es aquel que se
encuentra diseñado bajo un limitado número de estructuras de control.
La medida clásica del control de flujo es la denominada "complejidad
ciclomática". Esta medida fue desarrollada por el científico norteamericano
internacionalmente conocido en el ámbito de la medida del software por sus
aportaciones en este campo, Thomas ~ c ~ a bEsta e . es~ una
~ medida basada en una
teoría gráfica, relacionada directamente con el número de "caminos" asociados a
un programa o módulo. McCabe postuló que un valor elevado de la complejidad
ciclomática de un grafo que representa un módulo o programa de forma directa,
implicaría un grado elevado de dificultad en las propiedades de comprensibilidad y
facilidad de prueba. La razón de este discernimiento es que un valor elevado en la
complejidad ciclomática implicaría una densidad elevada de instrucciones tipo "IF,
WHILE" o "REPEAT". La incidencia de estas construcciones es un mayor grado
de dificultad a la hora de leer esos programas o probarlos, ya que implicarían un
mayor número de caminos a explorar al realizar pruebas de datos.
El trabajo de McCabe de 1976, es de obligada referencia en cualquier texto de
ingeniería del software al ser uno de los modelos más originales y copiados de la
historia de la medida del software.
A pesar de este hecho han aparecido estudios críticos sobre la medida propuesta
por McCabe. Se demostró que muchos de los experimentos eran estadísticamente
sospechosos y que la complejidad ciclomática no proporciona mejores predicciones
que aquellas que nos ofrece el modelo de las líneas de código. Esta afirmación se
soporta sobre numerosas experiencias empíricas [Fenton, 19921.
Existen, además, otras críticas realizadas hacia esta teoría gráfica. Por un lado la
falta de trascendencia dada por este modelo a las condiciones de un módulo o
programa. Así, por ejemplo, dos módulos con igual complejidad ciclomática son
enormemente distintos debido al uso de múltiples operadores booleanos,
expresiones aritméticas complejas o abuso de los "flags" en el programa. Otros de
25
MacCabe Thomas, J. Licenciado en matemáticas por las universidades de Privilence y Connecticut. Prestigioso
consultor y autoridad en las áreas de la calidad del software, técnicas de validación y pruebas del software.
Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
los problemas se encuentra -en el tratamiento de los datos. Dos programas pueden
tener igual complejidad ciclomática, pero uno de ellos puede ser mucho más difícil
de entender que el otro debido al número y extensión de las variables utilizadas por
cada uno de éstos. A finales de los setenta y principio de los ochenta han aparecido
algunas variantes del modelo de McCabe que intentaban superar estas críticas.
Aparecen modelos que consideran el nivel de anidamiento o complejidad booleana
o tienen en cuenta factores asociados a los datos tratados y de qué forma, por parte
del programa.
Las medidas basadas en el control de flujo impulsaron un área de aplicación de
las medidas del software de enorme potencial. Si un programador utiliza un
detallado diseño, de forma que sea isomórfico con el código final generado,
medidas tales como la complejidad ciclomática pueden ser utilizadas durante la
fase de diseño detallado del programa.
Una de las mayores críticas vertidas sobre el modelo de McCabe es que haya
sido utilizado para medir más factores de calidad que aquellos para los que fue
ideado. Muchos trabajadores, escondidos tras el paraguas del término complejidad,
han erróneamente extendido éste hacia áreas donde McCabe nunca intentó ir.
6.4. Sistemas de diseño
Si la década de los setenta puede definirse como el decenio de la programación

estructurada los ochenta se pueden caracterizar como la década de los "sistemas de
diseño". La característica más significativa de esta concepción del desarrollo de
programa para ordenador se centra en restar trascendencia a la fase de
programación, recayendo el peso del desarrollo sobre tareas anteriores a ésta, tales
como la captura de las especificaciones del sistema o la fase de diseño. Esta
concepción se inspiró en la industria tradicional y es dónde las tesis propuestas por
Christopher Alexander alcanzan su mayor influencia tras casi veinte años desde su
publicación.
Tal como propuso Alexander la idea principal de los modernos sistemas de
medida están basados en la idea de que el sistema software es aquel en el cual los
componentes del mismo (subrutinas, módulos, rutinas) son relativamente
independientes y se encuentran aislados entre sí. Estos sistemas tienen la propiedad
de que sus módulos son fáciles de entender, corregir y probar. El diseño
estructurado de Yourdon tiene como elemento sustancial de su método de
programación las ideas originales de Alexander, y los trabajos sobre la abstracción
de datos propuestos por David ~ a r n a s o~ los
~ , iniciales intentos de caracterizar la
26
Pamas, David Lorge. Profesor de Ingeniería Computacional y Electricidad de la universidad de McMaster,
Ontario. Miembro de Laboratorio de Investigación de Comunicaciones del Instituto de Telecomunicaciones de
Ontario. Autor de más de 150 publicaciones orientadas al estudio de la estructura del software, diseño de
complejidad del sistema, fueron catalizadores de esta visión y su aplicación a los

modernos modelos de medida. El modelo de ~ a f u r a ~y' ~ e n r pes,
probablemente, el diseño más utilizado desarrollado hasta ahora. La idea principal
de este sistema es que la complejidad es medida en términos de flujos de
información y que aquellos módulos más complejos del sistema son aquellos a los
que fluyen más datos.
6.5. Costes y esfuerzos
En paralelo con el trabajo sobre la medida de los sistemas de diseño, los últimos
años de la década de los setenta y los primeros años de la década de los ochenta
vieron algunos trabajos derivados de las medidas de las especificaciones. Las
medidas extraídas de las especificaciones funcionales del sistema se idearon pare
estimar el coste y esfuerzo o para asegurar la productividad. Allan ~ l b r e t c es
h ~el~
investigador por excelencia en esta área de estudio.
La medida propuesta por Albretch, "punto de funcionalidad, tiene en su ánimo
medir el tamaño funcional del software. Originalmente se intentó en el
procesamiento comercial de datos.
~ ~ m o n desarrolló
s~' un producto industrial basado en la idea original de
Albretch. Este modelo es utilizado, sobre todo, para administradores de grandes
bases de datos, en cuyos sistemas esta medida es de las más populares.
Un problema achacado al punto de funcionalidad es que asume un limitado
número de aplicaciones tipo, principalmente sistemas basados en ficheros de gran
volumen, muy propios de entidades financieras, pero no puede considerarse en
sistemas híbridos tales como aquellos de control de stocks con un gran componente
de comunicaciones. En los primeros años de los ochenta DeMarco presentó una
medida llamada " BANG que intentaba superar este hecho apoyado en factores de
ajuste que dependían del grado de fortaleza de datos y de funciones.
lenguajes, software de seguridad, entre otros campos de estudio. Consultar . Encyclopedia of Software
27
Kafura, Dennis G . Licenciado en matemáticas por la universidad de San Francisco y doctor por la universidad
de Purdue, actualmente es responsable del Departamento de Ciencia de la Computación del Instituto Politécnico
de la universidad de Virginia. Su labor investigadora ha alcanzado la programación orientada a objeto,
computación paralela, seguridad informática, métricas, entre otros campos. Consultar Encyclopedia of Software
28
Henry, Sallie. Doctora en Ciencia de la Computación por la universidad del Estado de Iowa, ha trabajado en los
campos de la medida del software, metodologias de diseño y programación orientada a objeto. Consultar el sitio
http://www.cs.vt.edu/
29
Albrech, Allan J. Internacionalmente conocido como inventor de la medida denominada análisis del punto
función. Graduado por la universidad de Bucknell en 1949 como ingeniero eléctrico y electrónico, trabajó en IBM
donde desarrolló gran parte de su carrera. Se retiró en 1998 desarrollando ahora una labor de consultor
independiente. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
30
Symons, Charles. Científico con más de cuarenta años de experiencia, fue pionero en la medida del software
desarrollando la técnica denominada puntos función MKII. Comenzó su carrera en el uso de ordenadores aplicados
a la energía atómica. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
La medida de una aplicación a través de los puntos de funcionalidad posee hoy

en día una extensión mundial, aunque se ha implantado de forma más amplia en los
Estados Unidos de América, Australia, Japón y algunos países europeos. En estas
localizaciones han aparecido asociaciones de usuarios de gran influencia y que a
través de foros de debate y cursos extienden este modelo por todo el mundo3'.
En los últimos años de la década de los setenta se incrementó el interés por la
medida de las pruebas estructurales. Un número de medidas fueron desarrolladas
con el deseo de cuantificar el grado de profundidad que deben poseer el proceso de
pruebas. Estos modelos se han basado en medidas estructurales, pocos trabajos se
han llevado acabo sobre pruebas de tipo funcional.
A finales de la década de los setenta y en la década de los ochenta los
programadores encontraron sus mayores problemas en el coste y estimación del
proyecto software. El deseo era encontrar un modelo que tuviera un número de
entradas y que produjera alguna forma de estimación de recursos para el proyecto.
Los problemas de la estimación del coste.
El método más conocido es el modelo COCOMO desarrollado por el científico
Bany ~ o e h m Como~ ~ . elemento primordial indica la necesidad de una base de
datos del proyecto previa. Otros modelos como el SOFTCOST desarrollado en
Pasadena por investigadores de la "Jet Propulsion Laboratory". A través de
cuarenta y siete preguntas y de las correspondientes respuestas se deduce el valor
de sesenta y ocho parámetros. La filosofía del proyecto es desarrollar un programa
de esfuerzos, niveles de equipos, documentación y requisitos de capacidad de
procesamiento.
Como se puede apreciar en este breve recorrido por la historia de la medida del
software, esta actividad ha sido centro de atención de numerosos investigadores.
Sin embargo aún hoy en día existen algunos problemas que todavía no han sido
resueltos:
o Falta de madurez en la medida del software.

o Inexistencia de estandarización en las medidas.
o Medidas del software aún no ampliamente aceptadas [Zuse, 19981.
"un ejemplo de este tipo de organizaciones es la denominada en inglés Intemational Function Point Users Group
(IFPUG). Entidad orientada al desarrollo y mejora de la técnica de medida del punto función y de su extensión
alrededor del mundo.
32 Boehm, Bany. Profesor de Ingeniería del Software y Director del Departamento de Ciencia Computacional en el
Centro de Ingeniería del Software. Doctor ingeniero por la universidad de UCLA en 1961, ha realizado numerosas
aportaciones a la ingeniería del software, tales como el modelo COCOMO, el Modelo Espiral o aproximaciones
teóricas a la administración del software, entre otras. Consultar Encyclopedia of Software Engineering, John Wiley
& Sons, 1994.
7. LA MEDIDA DEL SOFTWARE
7.1. Marco teórico
Tras definir concepto básicos, propios de la teoría de la medida, este apartado

propone un marco teórico y conceptual sobre el que asentaremos las diferentes
actividades asociadas con la medida del software. De nuevo haremos referencia al
texto de Norman E. Fenton como bibliografía básica en este apartado aunque
introduciremos aportaciones de otros autores que refuercen este acercamiento
teórico al proceso de medida de programas informáticos, aportaciones que
indicaremos puntualmente.
La realización de medidas aplicadas en un entorno propio del desarrollo de
programas informáticos necesita definiciones concisas que identifiquen claramente
las entidades a estudiar así como aquellos atributos que serán objeto de dichas
medidas.
Procesos, productos y recursos serán los entes objeto de estudio en este entorno.
A continuación los definimos y acompañamos estas definiciones con ejemplos que
pretendemos aclaren definitivamente estas exposiciones.
Procesos. Serán aquellas actividades relacionadas con el software que

normalmente poseen el parametro "tiempo" como factor. Por tanto son
actividades que se realizan durante una parte del tiempo total que dura el
3
proyecto software ".
Ejemplos de esta entidad podrían ser desde la construcción de especificaciones

hasta el propio desarrollo del sistema software, desde la captura de los requisitos
hasta la liberación al usuario del producto.
Productos. Se entienden como aquellos servicios, herramientas o

documentos derivados de los procesos, entendidos como resultados de
éstos34.
Como ejemplos de esta entidad podríamos indicar la documentación propia de

las especificaciones o del diseño, representación del código fuente u objeto, entre
otros.
33
Fenton, Norman E. Sofmare Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. La traducción es
nuestra.
34
Fenton, Norman E. Sofhoare Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. Pág. 42. La
Recursos. Se deJinen como un conjunto de entidades considerados como

entradas para la producción del software35.
Ejemplo de recursos sería el personal implicado, herramientas utilizadas o

método manejado.
Una vez definidos las entidades que serán objeto de nuestra atención hemos de
considerar los atributos a medir. Como primera aproximación indiquemos una muy
fundamental división de los mismos en dos tipos bien definidos. "Atributos
directos" como aquellos que pueden ser medidos en términos de las entidades a
estudiar y "atributos indirectos", definidos como aquellos que sólo pueden ser
medidos por medio de cómo productos, procesos y recursos se relacionan con su
entorno.
Basándonos en las entidades consideradas anteriormente, podemos encontrar un
número determinado de atributos de interés.
Asociados al estudio de los procesos, como atributo interno, Fenton aporta un
número limitado de éstos. Tiempo, entendido como duración del proceso, esfuerzo
asociado al proceso y número de incidentes de cierto tipo que pueden acaecer
durante el proceso estudiado. Evidentemente podemos encontrar numerosas
combinaciones de medidas directas cuyo resultado sería la pertinente medida
indirecta que, recordemos, pueden ser de igual e incluso de mayor interés que las
medidas directas. Ejemplos de atributos externos podríamos citar la estabilidad,
coste, calidad, entre otros.
Atributos internos propios de los productos serían, longitud, funcionalidad,
redundancia, grado de acoplamiento etc. Como atributos externos podríamos citar
la comprensibilidad, facilidad de mantenimiento, fiabilidad.
En el caso de los recursos, podríamos citar como atributo interno la edad o
sueldo (del programador), nivel de comunicación en los equipos de trabajo o la
rapidez o precio de los equipos hardware. Como atributos externos podemos
indicar la facilidad de uso, grado de ergonomía o experiencia.
La tabla 2.5 muestra un resumen de atributos, recursos, procesos y entidades
relacionadas con la medida del software.
Los atributos externos son aquellos que sólo pueden ser medidos de forma
indirecta, según se encuentren conectados con su entorno, mientras que los
atributos internos son los que su medida puede realizarse de forma directa como
atributo del recurso, producto o proceso estudiado. La relación entre atributos
internos y medidas directas, así como entre atributos externos y medidas indirectas
es clara. Pueden existir pocos atributos internos de cierta entidad, sin embargo la
combinación de éstos nos puede proporcionar una información muy interesante y
35
ser tan abundante como la combinación de atributos internos sea posible. La tabla
2.6 muestra algunos atributos y su entidad asociada. según la visión "METKIT".
Tabla 2.5. Ejemplos de atributos internos y externos.
Dos últimas definiciones nos permitirán finalizar este repaso teórico a la medida
del software.
El fin último del proceso de medida es el cálculo de alguna magnitud conocida
o predecir un atributo aún inexistente. Este hecho nos lleva a dos definiciones
importantes.
Modelo. Entendido como una representación abstracta de un objeto36.
Podemos dividir los modelos existentes en representaciones abstractas de varios

productos, procesos o recursos. Tales modelos capturan atributos que están siendo
medidos sin ambigüedad posible. Por otro lado existen modelos que indican
abstractas representaciones entre atributos de entidades. Estos modelos relacionan,
por lo general, más de dos medidas a través de una fórmula matemática.
Pero la consecución de un modelo no es suficiente para desarrollar un proceso
de predicción. Necesitamos determinar parámetros para el modelo e interpretar los
36
Fenton, Norman E. SofhYare Metrics. A Rigorous Approach. London, Chaprnan & Hall, 1992. Pág. 48. La
resultados de forma correcta. Basándonos en esto podemos definir:
Sistema. Sistema de predicción como un modelo matemático junto a un

conjunto de procedimientos predictivos que permiten determinar parámetros
desconocidos e interpretar resultado^^^.
"tiempo" como factor. Por ello

serían actividades que se realizan
en cualquier proyecto.
Productos Es cualquier herramienta, servicio Para Mantenimiento,

o, en general, resultado, derivado documentación: Movilidad,
de los procesos ejecutados. Salida longitud, Reutilización etc.
de los mismos. modularidad,
redundancia etc.
Para código o
diseño formal:
estructuración,
acoplamiento etc.
Recursos Cualquier tipo de entidad Edad del Productividad,
considerada como entrada para la personal, salario, experiencia,
producción del software. Pueden velocidad del fiabilidad,
ser de muy diversa naturaleza. equipo hardware capacidad de
Herramientas, métodos, (entre otros) reutilización (entre
materiales, son ejemplos de otros)
recursos.
Tabla 2.6. Entidades objeto de medida según el marco teórico propuesto.
Las definiciones expuestas nos permitirán abordar el proceso de medida del

software bajo una base científica.
37
Fenton, Norman E. Op. Cit. pág. 48. La traducción es nuestra.
8. LA NORMA ISOlIEC9126
No podemos acabar este capítulo sin hacer referencia a la norma ISOIIEC 9126.
Esta norma es trascendente por diversos motivos. Es un intento por normalizar la
medida de la calidad del software por parte de un organismo tan importante como
es el caso de ISO. Asume la medida del software a través de una metodología de
amplia utilización en las ciencias empíricas como es la descomposición jerárquica
en árbol. Considera la medida de la calidad a través de la medida de atributos
directos, indirectos y medida de la calidad de uso, siguiendo la propuesta de Fenton
en su texto sobre la medida del software. La norma ISOIIEC 9126 también propone
un procedimiento de medida con objeto de ser una referencia de carácter
internacional.
Estudiaremos en detalle esta norma en el capítulo VII.
Uso de recursos
fallos aprendizaje para cambios instalación
Capacidad de Adherencia
Interoperatividad Operatividad Estabilidad Coexistencia
recuperación a normas
Adherencia Software Facilidad Facilidad de
Seguridad
a normas atractivo para pmebas reemplazo
Adherencia Adherencia Adherencia Adherencia
a normas a normas a normas a normas
Tabla 2.6. La norma ISOIIEC 9126.

Capítulo 3
NORMALIZACI~NY CERTIFICACI~N:
NORMA ISO 9001:2000
El aseguramiento de la calidad es un modelo
planificado y sistemático para proporcionar una adecuada
confianza en que un producto es conforme con los
requerimientos técnicos establecidos'
Unido a los conceptos metodología y modelo aparece habitualmente el de

norma. En el ámbito de las comunicaciones y la informática existen organizaciones
nacionales y, más habitualmente, trasnacionales que adoptan estos modelos y
metodologías promoviendo su conocimiento y utilización. Cuando un modelo o
metodología es adoptado por una organización de estas características adquiere el
rango de norma.
Un concepto muy unido al de normalización (o norma) es el de certificación. Es
habitual el que un organismo que recomienda una determinada norma, establezca la
posibilidad de certificar a una empresa, profesional, institución, colectivo etc. en
dicha norma. Con esta acción lo que se pretende es asegurar, dar fe, sobre el grado
de implantación de la norma en la empresa certificada.
Se tratará en este capítulo de la normalización y de la certificación, así como de
las normas y entidades de certificación, prestando especial atención a la norma ISO
900 1:2000.
1
Standards Coordinating Comminee of the IEEE Computer Society. Standars Glossary of Software Engineering
Tenninologv. IEEE. Nueva York, 1991. Pág. 60. La traducción es nuestra.
Las normas son reglas metodológicas y modelos adoptados por organizaciones
nacionales o internacionales que se dedican al establecimiento de estándares. Estas
organizaciones se apoyan en foros de expertos que se suelen constituir en comités
muy cualificados.
La Organización Internacional para la Estandarización, más conocida por sus
siglas en inglés, ISO, propone gran cantidad de normativa en numerosos campos
tecnológicos, y es un claro ejemplo de este tipo de instituciones. Su homólogo
nacional es AENOR, Asociación Española de Normalización. Las normas
propuestas por la ISO, o por cualquier otra organización de características
similares, son recomendaciones, no disposiciones legales, es decir no poseen el
rango de Ley.
El Departamento de Defensa norteamericano (DoD), la Agencia Espacial
Europea (ESA), el Instituto de Ingenieros de Eléctrica y de Electrónica
Norteamericano (IEEE), la Agencia 9Espacial Norteamericana (NASA) son
instituciones, entre otras muchas, especialmente activas en la publicación de
normativas de gran impacto mundial.
Las empresas que siguen una determinada norma suelen querer demostrarlo
mediante el correspondiente certificado de la organización generadora del estándar,
y así evitarse gastos en demostrar que cumple las normativas en cada concurso al
que se presente o en cada propuesta a un posible nuevo cliente.
La certificación, inicialmente, sólo se hacía sobre el grado de cumplimiento de
un determinado producto industrial sobre una determinada norma técnica, y que,
por consiguiente, no era necesario comprobarlo a cada momento. La certificación
alcanzó tal difusión y prestigio que las empresas de servicio también quisieron
tener sus certificados, sobre todo el de calidad, ya que la sociedad actual demanda
fundamentalmente calidad. Pero en los servicios el producto es único e irrepetible,
ello es particularmente aplicable a la fabricación del software; un programa es
diferente a otro y una aplicación no tiene nada que ver con otra aplicación. Por lo
tanto lo que se certifica en estos casos no es el cumplimiento de la normativa por
parte del producto, sino que la empresa está organizada y sigue una metodología
que, con una alta probabilidad, dará lugar a un servicio (software) de calidad. Se
certifica, en definitiva, el método con el que la empresa desarrolla el producto final,
en este caso la aplicación informática.
La certificación más conocida es la asociada a la norma de calidad ISO 9001,
aunque existen otras certificaciones como la militar PECAL, para empresas que
desarrollan software para la OTAN, o la asociada al modelo CMM, que expide
Carnegie Mellon.
En España, la certificación más extendida es la asociada a la norma de calidad
ISO 9001 :2000.
Aunque ya se definieron los conceptos generales de calidad, conviene

adaptarlos a la industria del software. Numerosas definiciones son, por otro lado,
comunes en la industria del software y en la industria en general. Estos conceptos
son:
Gestión de la calidad del software2 (Software Quality Management)
"Aspecto de la función general de la gestión que determina y aplica la política

de calidad (objetivos y directrices generales de calidad de una empresa)." Esta
gestión puede hacerse a nivel de proyecto o a nivel de empresa, es decir, a nivel
estratégico.
Aseguramiento de la calidad del software3 (Software Quality Assurance)
"Conjunto de actividades y sistemáticas necesarias para aportar la confianza en

que el software satisfará los requisitos dados de calidad". La I E E E ~la define como
"conjunto de actividades para evaluar el proceso mediante el cual se desarrolla el
software". El aseguramiento tiene como objetivo dar confianza al cliente de que el
software tiene calidad, pero no la garantiza. El aseguramiento de la calidad no tiene
nada que ver con la garantía de calidad.
Control de la calidad del software5 (Software QualiS Control)
"Técnicas y actividades de carácter operativo, utilizadas para satisfacer los

requisitos relativos a la calidad, centradas en dos objetivos fundamentales:
mantener bajo control un proceso y eliminar las causas de defectos en las diferentes
fases del ciclo de vida". La organización I E E E ~la define como "el proceso de
verificar el propio trabajo o el de un compañero".
Verificación y validación del Software ( V y V ) .
Es un concepto específico de la industria del software La verificación

comprueba que el software funciona, es decir, que técnicamente se ha construido
AENOR. Normas para la gestión y el aseguramiento de la calidad. AENOR. Madrid, 1992

AENOR. o p . Cit.
IEEE. Computer Dictionary. IEEE. New Yrok, 1990.
5
AENOR. Op. Cit.
6
IEEE: Op. Cit.
de acuerdo con los requisitos del usuario. La actividad se realiza para cada fase del
ciclo de vida, para confirmar que lo realizado hasta el momento es correcto,
completo y consistente. La validación se realiza sobre el producto terminado y ya
verificado y comprueba que funciona como quiere el cliente y realiza todas las
funciones requeridas.
3. LOS NIVELES DE LA CALIDAD
Las actividades para la mejora de la calidad en cualquier industria, incluida la

del software, se realizan en dos niveles: a nivel de empresa y a nivel de proyecto.
A nivel de empresa u organización, las actividades se orientan hacia la
consecución de una estructura organizativa centrada en la calidad, en la que todas
las unidades (administrativas, de producción, comerciales, etc.) y todo el personal
trabajen mentalizados hacia la calidad. Para conseguirlo hay que implantar lo que
se conoce como Sistema de calidad.
En muchas empresas, y en particular en las empresas del software, el'trabajo se
articula mediante los proyectos. La calidad se obtiene por la translación de lo
dispuesto en el sistema de calidad a las actividades del proyecto, siendo necesaria
la adaptación de las disposiciones generales a cada proyecto. En la industria del
software, se aplicarán las técnicas de evaluación y control de la calidad del
software a todas las fases del ciclo de vida.
4. LOS SISTEMAS DE CALIDAD
4.1. Definición
La norma ISO 9000lUNE 66900 define un sistema de calidad como: "La

estructura de organización, de responsabilidades, de actividades, de recursos y de
procedimientos que se establecen para llevar a cabo la gestión de calidad".
Como consecuencia de esta definición, el sistema de calidad debe ser
concordante con los objetivos de calidad de la empresa, definidos en la política de
calidad de la misma, que es una parte de la política general de la empresa. Por ello,
la alta dirección debe expresar dicha política, planificarla estratégicamente, asignar
recursos y elegir los planes y evaluaciones sistemáticos; en definitiva, la alta
dirección debe iniciar, desarrollar, implementar y actualizar periódicamente el
sistema de calidad.
También debe crear la estructura del sistema de gestión de calidad, tanto en su
aspecto jerárquico como comunicativo, con el fin del que el sistema sea
comprendido por todo el personal, ofrezca confianza a los clientes, sea eficaz y se
centre más en prevenir que en detectar y corregir errores.
4.2. Partes del sistema
Siguiendo a Senllé y stol17, un sistema de calidad está constituido por elementos

escritos y elementos prácticos.
Los elementos escritos son los documentos en los que se describe el sistema, los
procedimientos, etc., ajustándose a una norma determinada, generalmente la ISO
9000. Los principales documentos son el Manual de Calidad, los Procedimientos
y los Registros de datos sobre calidad.
La parte práctica incluye aspectos físicos (locales, computadores, herramientas
software, etc.) y aspectos humanos (coordinación de equipos de trabajo, formación
en calidad, técnicas de software, técnicas de comunicación y de reuniones, etc.).
4.3. Manual de calidad
Es el elemento principal del establecimiento de un sistema de calidad, en el que

se encuentran, por escrito, en forma de políticas y procedimientos, todos los
elementos, requisitos y medios que adopte la empresa en orden a la calidad.
Según el tamaño de la empresa habrá manuales de calidad para la totalidad de la
empresa, manuales de calidad a nivel de producto, manuales de calidad a nivel de
departamento, manuales de calidad específicos (desarrollo, proyectos, compras,
relaciones con clientes, etc.).
El manual de calidad es para uso interno de la empresa, aunque es necesario y
fundamental en el proceso de certificación, y facilita las relaciones con los clientes
y los proveedores.
Las diferentes normas indican la estructura del manual de calidad. Un ejemplo
podría ser el siguiente. ,
O. Índice.
l . Presentación de la empresa.
1.1 Objeto y campo de aplicación.
1.2 Necesidades del cliente.
1.3 Desarrollo del producto.
1.4 Objetivos de la calidad.
2. Normas para consulta.
3. Definiciones.
7
A. Senllé y G. A. Stoll. Calidad total. ISO 9000. Las normaspara la calidad en lapractica. Ed. Gestión 2000.
Barcelona, 1994.
4. Política de calidad.
4.1 Responsabilidades delegadas.
4.1.1 Director de calidad.
4.1.2 Responsable de calidad de diseño.
4.1.3 Responsable de calidad de producción.
4.1.4. Responsable de calidad de servicios.
4.2 Canales de comunicación.
4.3 Amplitud de aplicación.
4.4 Documentación del sistema de calidad.
4.4.1 Registros de la calidad.
4.4.2 Explicación de los registros.
4.5 Procedimientos operativos.
4.6 Planes de calidad.
4.6.1 Planes de formación.
4.6.2 Plan de evaluación de proveedores.
4.6.3 Plan de evaluación del personal.
4.6.4 Plan de adquisición de recursos.
4.7 Auditorias del sistema de calidad.
4.7.1 Programa de auditorias.
4.7.2 Contenido e informe de las auditorias.
4.8 Revisión y evaluación del sistema.
4.9 Mejora de la calidad.
5. El desarrollo del producto.
5.1 Fase de recepción y estudio del pedido.
5.2 Fase de diseño.
5.3 Fase de producción.
5.4 Fase de pruebas.
5.5 Fase de instalación.
5.6 Garantías.
6. Consideraciones financieras.
6.1 Recursos humanos.
6.2 Recursos materiales.
6.3 Otros recursos.
4.4. Los procedimientos
Aunque en principio los procedimientos forman parte del manual de calidad,

muchas veces se presentan de forma separada con el fin de hacerlo más manejable.
De todas formas, en el manual se debe explicitar claramente la existencia de estos
procedimientos separados.
Los procedimientos son instrucciones específicas y detalladas de los procesos o

actividades, e incluyen tanto la experiencia y práctica del trabajo cotidiano como
los códigos, normas y especificaciones a los que hay que ajustarse.
En el desarrollo del software, se incluyen en los procedimientos las
metodologías y técnicas que hay que aplicar, coino el formato de documentos, la
forma de documentar, procedimiento de pruebas, reglas de codificación, etc.
4.5. Registros de datos sobre calidad
Son archivos o bases de datos que contienen toda la información relacionada

con el proceso de la calidad (datos de pruebas, datos de auditoria, inspecciones,
datos de costes, etc.).
Su papel, además de facilitar el funcionamiento del sistema de calidad y
determinar el nivel alcanzado de calidad, se prolonga después de finalizado el
proyecto como base para el estudio de las tendencias y la corrección de errores.
4.6. El enlace con la calidad del proyecto
Ya que el sistema de calidad marca las directrices generales, es necesario

desarrollar un plan específico para adaptarlas a cada proyecto, que se conoce como
plan de aseguramiento de la calidad. Lo más normal es que este plan siga
fielmente lo dispuesto en el plan general. Pero muchas veces es necesario
adaptarlo. Esta adaptación del sistema a nivel de proyecto puede deberse a
diferentes causas: Proyectos muy críticos, como los espaciales, que suponen un
gran coste económico e, incluso, pérdida de vidas humanas, que exigirán unas
pruebas y unas validaciones más numerosas y rigurosas que las exigidas por el
sistema de calidad general; necesidades específicas del cliente, como los contratos
con la OTAN, que exigen la aplicación de otras normas de calidad (PECAL, etc.);
proyectos para clientes especiales con necesidades especiales.
5. CALIDAD A NIVEL DE PROYECTO
5.1. Planificación del aseguramiento de la calidad en un proyecto
Siguiendo el estándar IEEE', al iniciar un proyecto software hay que:
- Seleccionar uno o varios modelos del ciclo de vida, y concretarlo luego en

uno determinado para dicho proyecto.
8
IEEE. Estandarfor developing soffware lyfe cycleproceses. Std 1074. IEEE computer society. New York, 1991.
- Definir los aspectos relacionados con la financiación y viabilidad del
proyecto.
- Definir las metodologías, técnicas y herramientas s utilizar.
- Planificar la gestión del proyecto software.
El Plan de Gestión del Proyecto Software debe incluir y describir:
- El día a día del proyecto, con los correspondientes controles de auditorias y

revisiones.
- La planificación del aseguramiento de la calidad del software (SQA).
- La planificación de la documentación del proyecto.
A partir del plan de gestión, se genera el Plan de Aseguramiento de la Calidad

del Sofmare.
5.2. El Plan de Aseguramiento de la Calidad del Software
Este plan es específico para cada proyecto, siguiendo las directrices del Manual
de Calidad y de sus Procedimientos y las normas requeridas por los clientes.
Siguiendo el estándar 7309 de la IEEE sobre planes de aseguramiento de la calidad
del software, el plan debe incluir:
Objetivos de calidad del proyecto y enfoque adoptado para alcanzarlos.

Documentación referenciada en el plan (manuales, procedimientos, etc.).
Gestión del aseguramiento de la calidad (organización, actividades y
responsabilidades).
Documentación mínima exigida a los desarrolladores tanto del desarrollo
del software (especificaciones, diseño, manuales de usuario, etc.) como de
control (planes de Validación y Verificación).
Estándares que se deben aplicar obligatoriamente.
Actividades de revisión y auditoria.
Gestión de la configuración del software (mediante un plan de gestión
específico o describiendo sus actividades).
Informes de problemas, especificando la forma de tratar y corregir los
problemas y los responsables que han de hacerlo.
Herramientas para apoyar el aseguramiento de la calidad (revisiones,
inspecciones, analizadores de código, generadores de entornos de prueba,
etc.), especificando sus objetivos y la manera de utilizarlas.
9
IEEE. Std 730/1984. Standardfor software quality assuranceplans. IEEE. New York, 1984.
LA CALIDAD DEL SOFTWARE Y SU MEDlDA 103
- Control del código (almacenamiento y versiones), control de acceso a

equipos y prevenciones de seguridad y control de las características del
software de los suministradores.
- Recogida, almacenamiento y mantenimiento de datos sobre el
aseguramiento de la calidad.
5.3. Actividades de aseguramiento de la calidad
Según el estándar IEEE 10741°, las técnicas para el aseguramiento de la calidad

son, principalmente, tres:
- Métricas del software para controlar el proyecto.

- Verificación y Validación del software (incluyendo pruebas y revisiones) en
todas las fases del ciclo de vida.
- Gestión de la configuración del software.
Las métricas se estudiarán en otros capítulos de este libro.
6. MODELOS CONTRACTUALES DE ASEGURAMIENTO DE LA

CALIDAD
Los primeros modelos contractuales de aseguramiento de la calidad nacieron en

los ámbitos de las industrias americanas de defensa, naval y nuclear. Su extensión a
la industria general dio lugar a la norma ISO/DIS 9000:1985.
Posteriormente se desarrollaron otras normas, tanto en América (normas ISO)
como en Europa (normas EN) y en España (normas UNE). Tanto las normas
europeas como españolas suelen ser, en la mayoría de los casos, una traducción de
la correspondiente norma ISO.
Un sistema de calidad no debe diseñarse usando como guía las normas de
aseguramiento contractuales, aunque debe cumplirlas. La metodología de diseño
debe basarse en las características de la empresa, los elementos de un sistema de
calidad (normas ISO 9004 o UNE 66904) y los principales problemas de calidad
identificados.
A la hora de preparar un contrato de aseguramiento de la calidad es necesario
tener en cuenta:
p p p p p
lo IEEE. Std. 1074/1991. Standardfov developing sofhvare l f e cycleprocesses. IEEE Computer Society. New
York, 1991.
- Acomodación de la norma a las necesidades de las partes contratantes.
- Revisión del contrato para valorar la capacidad de satisfacer los requisitos
de calidad exigidos y sus implicaciones económicas.
- Requisitos técnicos claramente definidos en las especificaciones del
contrato.
Además, para seleccionar el modelo hay que considerar:
- La complejidad del proceso de diseño.

- La madurez del mismo.
- La complejidad del proceso de producción.
- Las características particulares del producto.
- La seguridad del producto y las consecuencias de su fallo.
- Las consideraciones económicas de los aspectos anteriores.
Como ya se ha indicado, los productos software no suelen certificarse, debido al

largo proceso que implica y sus elevados costos. Sólo tendrían sentido esta
inversión de recursos humanos, temporales y económicos, para productos como
sistemas operativos, bases de datos, etc. Lo habitual es certificar la empresa, para
demostrar a los clientes que tienen implantado un sistema de aseguramiento de la
calidad que de alguna forma, garantiza que el producto será de calidad, debido al
uso de buenas prácticas orientadas hacia la calidad.
El "Registro de Empresa" certifica la conformidad del Sistema de
Aseguramiento de la Calidad de una empresa respecto a los requisitos contenidos
en una de las normas UNE-EN-ISO que definen tres modelos de ~ s e ~ u r a m i e nde
to
la Calidad, y a los requisitos particulares de dicho Sistema.
La tramitación de la Certificación del Registro de Empresa corresponde a la
División de Certificación de AENOR, mediante el siguiente proceso:
1". Solicitud del peticionario, incluyendo el cuestionario de evaluación

preliminar, dirigido a AENOR.
2". Análisis por parte de AENOR de la solicitud y cuestionario, informando a
la empresa en caso de dudas sobre su solicitud, y pidiendo a continuación
el Manual de la Calidad y los Procedimientos Operativos de la Calidad (si
procede).
3". Envío a AENOR del Manual de la Calidad y Procedimientos Operativos de
la calidad, si la empresa decide que su estudio se realice en las oficinas de
AENOR. Alternativamente se podrían estudiar en las oficinas de la

Empresa inmediatamente antes de la visita previa.
4". Análisis por parte de los técnicos de AENOR de la documentación enviada
por el peticionario, informándole sobre aquellos requisitos que no se
cumplen o que no existen con respecto al modelo de Aseguramiento de la
Calidad aplicable dentro de la documentación básica de su sistema, o sobre
la aceptación teórica de la misma.
5". Visita previa por parte del equipo auditor designado por AENOR y un
auditor de una Entidad de Evaluación subcontratada por AENOR.
6". Auditoria del Sistema de Aseguramiento de la Calidad a los lugares objeto
de Certificación por el mismo equipo auditor.
7". Envío a AENOR, si procede, del Plan de Acciones Correctoras a las no
conformidades detectadas en la auditoria.
8". Evaluación y decisión por parte de AENOR y comunicación a la empresa.
9". Auditorias de seguimiento (una visita al menos por año, en los dos años
siguientes a la concesión del Certificado).
10". Auditoria de renovación al tercer año de la concesión del Certificado, a no
ser que exista expresa renuncia por parte del Titular de la Certificación.
Todo el proceso se representa en el siguiente gráfico.

Información preliminar
Cuestionario de evaluación preliminar
I
exigencias de la certificación
No
A
1 Información
al solicitante
Manual de la calidad
procedimientos, otros
documentos aplicables
procedimientos, otros
documentos aplicables Información al solicitante
r m Visita previa Informe visita previa
de la calidad
E3 Informe auditoria
8. LA FAMILIA DE NORMAS I S 0 9000
8.1. Antecedentes
El control y posteriormente el aseguramiento de la calidad en la industria

tradicional trajo como consecuencia numerosas iniciativas que, en no pocas
ocasiones, culminaban con modelos y estándares. El Reino Unido de la Gran
Bretaña fue un país pionero en este campo. En 1974 se publicó una normativa para
Aseguramiento de la Calidad, Guías, BS 5179. No fue hasta 1979 que hubo un
acuerdo y se publica por primera vez, en el Reino Unido, la BS 5750 precursora de
la familia de normas ISO 9000. En 1987 BS 5750 se convierte en ISO 9000 bajo la
dirección de la Organización Internacional para la Normalización. ISO 9000 se
adopta para facilitar en el comercio global proporcionando valor añadido a las
empresas certificadas y una ventaja estratégica a las mismas.
La familia de normas denominada ISO 9000 en un conjunto de documentos
sobre las buenas prácticas de los sistemas de gestión de la calidad. Al igual que
estándares ya comentado hace hincapié en qué requisitos ha de cumplir el sistema
de calidad de una empresa sin establecer el cómo deben cumplirse. En este caso la
norma considerada e; específica para la gestión de la calidad aunque su ámbito de
actuación no se encuentra restringida al desarrollo de programas para ordenador si
no que es de carácter genérico. Este hecho se superó en 1991 al publicarse la norma
UNE-EN 29000-3. Normas de gestión y aseguramiento de la calidad. Parte 3: Guía
para la aplicación de la norma ISO 9001 al desarrollo, suministro y mantenimiento
de soporte lógico. ISO 9000-3:1991, más tarde modificada en 1997 publicándose la
traducción al español en noviembre de 1998 UNE-EN ISO 9000-3.
La correspondencia entre las normas americanas, europeas y españolas es: serie
ISO 9000, serie EN-29001 y serie UNE 66900.
El objeto de estas normas es "establecer los requisitos que de be cumplir un
sistema de calidad cuando contractualmente debe ponerse de manifiesto la
capacidad de un proveedor para suministrar un producto que satisfaga las
necesidades del cliente".
Su campo de aplicación es todo tipo de empresa, independientemente de su
tamaño y su actividad.
La norma ISO 9001 se orienta a las empresas que de deben hacerse cargo del
diseño, producción, instalación y servicio post-venta del producto.
La norma ISO 9002 es aplicable cuando la empresa suministradora se hace
cargo de la producción e instalación del producto.
La norma ISO 9003 es para cuando la empresa suministradora puede demostrar
la calidad del producto mediante inspección final.
8.2. La ISO 9000:2000. Razones para un cambio
Además de que el protocolo inicial obliga a realizar una revisión de las normas
cada cinco años, existen diversas razones provenientes del enfoque del Sistema de
Gestión de la Calidad definido por las normas ISO para realizar un cambio en las
normas.
A raíz de un conjunto de encuestas a distintas organizaciones se determinaron
las siguientes razones:
Estructura común con el modelo de procesos.
Ya en el primer borrador se desarrollaron las actividades de soporte del Sistema

de Calidad mediante una estructura de procesos realimentados, para cerrar un
círculo de mejora continua. Dicha estructura debe servir de base para revisar los
capítulos de la norma.
Compatibilidad con las normas SGM ISO 14000.
Muchas empresas, debido a la presión actual de los ecologistas, quieren

certificar sus sistemas de gestión medioambientales con la citada norma. Muchas
de ellas ya estaban certificadas para sus sistemas de calidad. Sin embargo, no
existía una equivalencia clara entre los requisitos de ambas normas, por lo que se
producía pérdidas de sinergias.
Alcance reducido de los requisitos de la norma ISO 9001
Las organizaciones deberían poder reducir el alcance y decidir, en casos

justificados, la no-aplicabilidad en algunos requerimientos.
Incluir requisitos para la mejora continua.
Para alcanzar la Excelencia en la Gestión es necesario basarse en la mejora

continua, luego es necesario definir nuevos requerimientos en este sentidos para los
sistemas de Gestión de la Calidad.
Adecuación para empresas de cualquier tamaño.
La certificación basada en la ISO 9001 ha tenido una moderada difusión entre

las PYMES, por el enfoque de algunos requerimientos que aparentemente sólo se
ajustaban a organizaciones grandes.
Relación amigable.
Una de las principales críticas a esta familia de normas era la dificultad de su

comprensión y aplicación, unido a una aparente falta de consistencia entre las
numerosas normas existentes.
Facil transición a la nueva norma.
Debido al gran número de certificaciones existentes, el cambio no debería

significar un empezar completamente de cero. También se exigía un período
transitorio, con coexistencia de ambas normas, lo suficientemente largo para
permitir a las organizaciones la adaptación de sus sistemas de calidad, y pudiendo
elegir el momento del cambio a la nueva certificación.
8.3. Principios del cambio
Uno de los principios básicos del cambio ha sido la adaptación a la evolución de

la gestión de la calidad. Así, del primitivo control de calidad, se paso al
aseguramiento de la calidad, reflejado en las normas ISO de 1994. El siguiente
paso es la Gestión de la Calidad Total, que se refleja en las directrices de la nueva
norma ISO 9004:2000.
Los principios básicos en que se ha basado la revisión de la norma son:
Organización enfocada al cliente.
Las organizaciones tienden a orientarse hacia los clientes, para obtener su

satisfacción e incluso superar sus expectativas.
Liderazgo.
Es fundamental para avanzar hacia la excelencia el liderazgo de los equipos

directivos de cualquier nivel.
Participación de las personas.
Los conocimientos de todo el personal de la organización tienen que ponerse a

disposición del proceso de mejora continua.
Enfoque a procesos.
Se consigue una mayor efectividad cuando todas las actividades

interrelacionadas se comprenden y gestionan de forma sistemática a partir de
información fiable.
Enfoque del sistema hacia la gestión.
Por medio de la gestión de los procesos se consigue la mejora y el logro

eficiente de los objetivos.
Mejora continua.
Definida como "el procedimiento según el cual se planifican acciones

encaminadas a la mejora de las actividades, se ejecutan esas acciones, midiendo sus
resultados y actuando en consecuencia." La mejora continua debe ser el objetivo
permanente de las empresas, para evitar el retroceso.
Enfoque hacia la toma de decisiones.
La toma de decisiones se basa en observar y estudiar las medidas de los

procesos y en toda la información relevante y fiable que se pueda obtener.
Relaciones mutuamente beneficiosas suministradores-proveedores.
Al final de la cadena proveedor-suministrador se encuentra el cliente final, por

lo que es necesario establecer relaciones de mutua confianza entre los proveedores
y los suministradores.
8.4. Las normas ISO 9000:2000
En enero de 2000 se publica la versión ISO 9000:2000 que, a fecha de

finalización del presente libro actualiza la versión precedente tal como muestra el
siguiente cuadro:
o ISO 9001 :2000 Sistemas de Gestión de la Calidad
- Sustituye a ISO 9001:1994, ISO 9002:1994 e ISO 9003:1994

ISO 9004:2000 Sistemas de Gestión de la Calidad
ctrices para la mejora continua del desempeño. Sustituye a ISO 9004 -1
o ISO 19011 (a editar en 2002)
- Sustituirá a ISO 1001 l(auditoria), e ISO 14010, ISO 14011 e
ISO 14012 (medio ambiente)
o ISO 9000-3: 1997 Normas para la gestión de la calidad y
aseguramiento de la calidad. Parte 3: Directrices para la aplicación
Tabla 3.1. Familia de normas ISO 9000.
En este punto es significativo apuntar que la norma que sustituirá a ISO 9000-
3:1997 aún no se ha liberado por lo que la aplicación a entornos propios del
desarrollo software se encuentra pendiente de adaptación, por lo que se centrará la
atención en la norma ISO 9000-3 al considerarse en esta norma y de forma expresa
aquellos conceptos estudiados en otras normas propias del desarrollo software. Se
introducirán, igualmente, conceptos propios de la norma publicada en el año 2000
con objeto de apreciar el concepto general de la misma.
9. LA NORMA ISO 9001:2000
Los requisitos establecidos por la norma ISO 9001:2000 se estructuran en las

partes 5 a 8 de la norma, siendo las cuatro primeras partes una introducción a la
misma.
9.1. Introducción a la norma
Comprende las partes 1, 2 y 3 de la norma, en las que destacar los siguientes

conceptos.
Los objetivos y campo de aplicación de la norma. Son: demostrar la capacidad

para cumplir los requisitos reglamentarios y los del cliente y satisfacerle mediante
la mejora continua y la prevención de no conformidades.
Se pueden excluir ciertos requerimientos de la norma en función de la
naturaleza de los productos o servicios, los requerimientos del cliente o los
requisitos reglamentarios.
En la parte 2 se indica que la norma de consulta es la ISO 9000:2000 relativa a
"Sistemas de Gestión de la Calidad. Principios y vocabulario."
Se producen algunos cambios en las definiciones de la anterior versión,
desapareciendo el término subcontratista y el principal protagonista, el
suministrador, pasa a denominarse Organización.
9.2. Sistema de Gestión de la Calidad
En la parte 4 se definen los requisitos generales y los requisitos generales de la

documentación.
Los requisitos generales son:
Planificar
- Identificación de todos los procesos que, de alguna forma, afectan a la

calidad del producto.
- Determinación de la secuencia y la relación que estos procesos tienen entre
ellos.
Ejecutar
- Determinar métodos y criterios para asegurar el correcto funcionamiento y

control de los procesos.
- Los procesos han de estar documentados.
- Los procesos han de estar medidos mediante parámetros relevantes.
- Hay que establecer los responsables de los procesos.
Medir
- Asegurar la disponibilidad de la información suficiente que permita el

seguimiento del proceso.
Actuar
- Medir y realizar el seguimiento del proceso, para analizar y conseguir una

mejora continua.
La documentación del sistema debe estar constituida, al menos, por los
procedimientos exigidos en las partes 5 a 8 de la norma y los documentos
necesarios para asegurar el control y correcto funcionamiento de los procesos.
9.3. Responsabilidad de la dirección
En la parte 5 se describen los requisitos relacionados con la responsabilidad de

la dirección en la gestión de un sistema de calidad, entre las que se destacan:
- El compromiso de la dirección.
- El enfoque al cliente.
- La política de calidad.
- La planificación.
- La administración.
- La revisión por la dirección.
9.4. Gestión de los recursos
La parte 6 describe los requisitos relacionados con la gestión de los recursos

necesarios para la obtención del producto o servicio, que se detallan en cuatro
subpartes:
- Suministro de recursos.
- Recursos humanos.
- Instalaciones.
- Entorno de trabajo.
9.5. Realización del producto o servicio
Los requisitos relativos a la realización del producto o servicio se describen en

la parte 7, que se subdivide en 6 subpartes:
- Planificación de los procesos de realización.

- Procesos relacionados con los clientes.
- Diseño y10 desarrollo.
- Compras.
- Operaciones de producción y de prestación de servicios.
- Control de equipos de medición y de seguimiento.
9.6. Medición, análisis y mejora
La parte 8 describe los requisitos relacionados con la detección, el seguimiento

y el análisis de las mejoras. Se divide en 5 subpartes:
- Planificación.
- Medición y seguimiento.
- Control de las no conformidades.
- Análisis de datos.
- Mejora.
Dentro de la medición y seguimiento se incluyen las siguientes áreas:
- Satisfacción del cliente.

- Auditoria interna.
- Medición y seguimiento de los procesos.
- Medición y seguimiento del producto.
10. LA NORMA ISO 9004:2000
Esta norma expone las recomendaciones para llevar a cabo la mejora del
sistema de gestión de la calidad y explicaciones adicionales con relación a los
requisitos de la norma ISO 9001:2000. No es una directriz para cumplir con la
9001, sino recomendaciones a la dirección de la organización para obtener mejoras.
Consta también de 8 partes.
10.1. Introducción a la norma
En las cuatro primeras partes se exponen el objeto y campo de aplicación

(recomendaciones genéricas par la mejora de la gestión de los sistemas de calidad),
normas de consulta (la ya citada norma ISO 9000:2000), terminología y
definiciones (ISO 9000:2000) y recomendaciones del Sistema de Gestión de
Calidad (parte 4).
La parte cuatro de la ISO 9001:2000 define como gestionar los sistemas y los
procesos, los requisitos generales de la documentación y el uso de los principios
de gestión de la calidad (los 8 principios básicos del cambio ya citados).
10.2. Responsabilidad de la dirección
En la parte cinco de la norma se describen las responsabilidades de la dirección

articuladas en:
- Responsabilidades generales.
- Necesidades y expectativas.
- Política de calidad.
- Planificación de la calidad.
- Administración.
- Comunicación.
- Documentación y registro.
- Revisión.
10.3. Gestión de los recursos
La parte 6 de la norma se relaciona con el papel de la dirección en identificar y

proporcionar, en tiempo y formas los recursos necesarios para la consecución de
los objetivos planificados de gestión de la calidad. Estos recursos son:
- Recursos de personal.
- Entornos de trabajo, tanto síquicos como físicos, adecuados.
- Recursos de información.
- Recursos financieros.
- Infraestructuras y recursos naturales.
- Suministradores.
10.4. Realización del producto o servicio
La parte 7 se refiere a la realización del producto o servicio y consta de los

siguientes apartados:
- Revisiones del proceso.

- Validaciones del proceso/producto resultante.
- Mejora de procesos.
- Procesos relacionados con las partes interesadas.
- Procesos relacionados con el diseño y10 el desarrollo.
- Procesos relacionados con las compras.
- Procesos relacionados con operaciones de producción y de servicio.
- Control de equipos de medición y seguimiento.
10.5. Medición, análisis y mejora
La parte 8 basa la mejora continua en la medición y el análisis de sus resultados.

Estas mediciones y análisis deben hacerse regularmente, a intervalos apropiados,
sobre los datos relevantes de los productos, procesos y clientes, como entradas al
proceso de revisión por la dirección.
La organización debería básicamente medir la eficiencia de:
- El sistema de gestión de la calidad (satisfacción del cliente, auditorias

internas, resultados financieros y auto evaluaciones).
- Los procesos.
- El producto.
- Las otras partes, terceros, interesadas.
En un anexo, el D, la norma describe una metodología para implantar, de una

forma sencilla, un procedimiento interno de auto evaluación.
La norma también presenta ejemplos de información a incluir en los procesos de
medida, análisis y mejora en los siguientes campos:
- Relativa al cliente.
- Satisfacción del cliente.
- Auditoria interna.
- Financiera.
- Auto evaluación.
- Procesos.
- Productos.
- Partes interesadas.
- Propietarios.
- Suministradores.
- Sociedad.
- Medio ambiente.
Otros apartados se refieren al control de las no conformidades, al análisis de

datos para la mejora y al proceso de mejora.
11. LA CALIDAD, SU ASEGURAMIENTO Y MEDIDA SEGÚN LA

NORMA ISO 9001:2000 E ISO 9000-3:1997
En el caso de los programas para ordenador (soporte lógico según la

nomenclatura de la norma), la familia ISO 9000 se complementa con otras normas
propias del desarrollo software, ISO 15504 e ISO 12207. La norma ISO 9000
publicada en el año 2000 acerca la misma a la gestión de la calidad total aportando
directrices para la mejora continuada.
La norma ISO 9001 :2000 posee la siguiente estructura:
- Introducción.
- Objeto y campo de actuación.
- Normas para la consulta.
- Términos y definiciones.
- Sistemas de gestión de la calidad.
- Responsabilidad de la dirección.
- Gestión de los recursos.
- Realización del producto.
- Medición, mejora y análisis.
Considerando directamente el apartado "Medición, mejora y análisis", la norma

diferencia claramente procesos y producto estableciendo la necesidad de medir y
hacer un seguimiento de las características del producto así como el seguimiento y
medición de los procesos. Medir es, en este estándar una herramienta fundamental
de la misma. Esta necesidad impuesta por la norma es equiparable a la indicación
expresada por el modelo de madurez (CMM) en su nivel 4. Tal y como es habitual
en este tipo de estándares no se profundiza en medidas determinadas. El
seguimiento y medición del producto es equivalente al control de calidad clásico,
basado en la inspección del producto para comprobar su cumplimiento con unas
especificaciones definidas [Soluziona, 20011. Como la realización de un producto
es el resultado de diversos procesos encadenados, deben considerarse en ia
definición de las inspecciones a realizar todos los procesos implicados y productos
intermedios.
Como ya se ha indicado anteriormente, la norma ISO 9000:1994 se
complementó, en el ámbito del desarrollo de programas inforrnáticos, con la norma
ISO 9000-3: 1991 revisada en 1997 y emitiéndose la norma ISO 9000-3 1997,
finalmente incorporada como norma UNE en 1998: UNE-EN ISO 9000-3.
La norma UNE-EN ISO 9000-3 considera, en varios de sus apartados, la
necesidad de medir y la obtención de medidas, por ejemplo en el apartado 4.47
Verificación del diseño, en el punto 4.1 1.2 Procedimiento de control, en el punto
4.15.16 Entrega, entre otros. En todos estos casos la norma presenta la necesidad
de medir de forma generalista sin especificar qué atributos pueden estar
relacionados con la acción recomendada. Las siguientes citas exponen este hecho:
"Se deben realizar verificaciones del diseño durante las fases apropiadas
del mismo (...). Se deben registrar las medidas de verificación del
diseño""
"El suministrador debe: determinar qué medidas deben realizarse, la

exactitud requerida y seleccionar los equipos de inspección, medida y
ensayo adecuados y que sean aptos para la exactitud y precisión
necesarios"'*
La Norma sí aporta, de forma expresa, la necesidad de utilizar técnicas

estadísticas para analizar medidas de la capacidad del proceso y las características
del producto [Soluziona, 20011. Se aportan ejemplos de "características" de
productos y procesos.
Para procesos:
- Madurez del proceso.

- Número y tipos de defectos en la salida de los procesos.
- Eficiencia en la eliminación de defectos.
- Deslizamiento de hitos.
Para productos:
- Capacidad de ser probado.

- Utilidad.
- Fiabilidad.
- ~antenibilidad'~.
- Disponibilidad.
La norma igualmente define de forma expresa el concepto "métrica" como

característica medible y aporta aquellos principios que deben cumplir. Las
métricas tienen la necesidad de estar definidas claramente, deben añadir valor al
proceso o producto estudiado, debe estar identificada la forma en que puede ser
influida (por ejemplo por cambios en el diseño o técnicas de desarrollo) y se
comprende su significado con relación al proceso o producto.
" UNE-EN ISO 9000-3. Gestión de la Calidad y Aseguramiento de la Calidad. Parte 3: Directrices para la
aplicación de la Norma ISO 9001: 1994 al desarrollo, suministro, instalación y mantenimiento de soporte lógico.
AENOR. Madrid, 1998. Pág. 20
''Op cit pág. 34
l 3 UNE-EN ISO 9000-3 indica de forma expresa el concepto mantenibilidad. En traducciones realizadas por
nosotros se ha preferido hacer uso del texto "facilidad de mantenimiento".
Como en el estudio de otras normas, UNE-EN ISO 9000-3 aporta ejemplos sin
detallar el procedimiento de medida a utilizar apuntando al uso de técnicas
estadísticas.
El modelo propugna la medida de la calidad explicando este concepto desde el
punto de vista de la satisfacción del cliente.
Capítulo 4
MODELOS, METODOLOGIAS Y ESTÁNDARES:

ESTRATEGIAS PARA ALCANZAR LA CALIDAD
Era frecuente para algunos desarrolladores
considerar el software listo para su uso si el
1
programa podia ser compilado y cargado.
Es habitual el uso de los términos modelo, norma o metodología de forma

subjetiva y ambivalente por parte de profesionales de la informática y en
publicaciones especializadas. En este capítulo, en su primer apartado, se definirán
estos conceptos con el fin de evitar errores y permitirnos clasificar la enorme
cantidad de normas, estándares y metodologías existentes en el mercado con una
base conceptual coherente. Explicaremos en detalle los modelos CMM y Bootstrap
la norma internacional ISO 15504 y la metodología MÉTRICA Versión 3, como
ejemplos prácticos de estrategias asociadas al aseguramiento de la calidad en el
desarrollo de aplicaciones informáticas.
1.1. Definiciones
Una metodología de desarrollo de aplicaciones informáticas es un conjunto de

métodos que permiten sistematizar actividades. Nos dicen cómo hacer las cosas a
través de procedimientos bien descritos.
'Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineering, John Wiley & Sons, 1994. Pág.
122 MODELOS, METODOLOGIAS Y ESTÁNDARES
Esta idea proviene de la industria clásica2 donde el control, basado en la medida

de atributos propios del proceso, permiten su optimización y mejora continua. Las
metodologías de desarrollo, por tanto, nos prestan una ayuda singular frente a la
ineficacia de la creación artesanal singular, limitada e irrepetible, basada en el
conocimiento de un único elemento: el maestro. El proceso industrial es el
resultado de décadas de investigación y aportaciones de decenas o cientos de
estudiosos y técnicos. Una adecuada metodología es, por tanto, el mejor aliado
frente a la improvisación y a la ineficacia.
Unida al concepto de metodología aparece habitualmente el de "modelo de
desarrollo".
Un modelo, en sentido amplio, es un arquetipo, una referencia a imitar o
reproducir.
En la ingeniería del software un modelo nos proporcionará el objetivo a
alcanzar, dónde debemos llegar, pero no nos indicará cómo. Cuando el Modelo de
la Madurez del Software (CMM) presenta una abstracción del proceso de creación
de aplicaciones informáticas, aporta un conjunto de estadios, de capas, que
permitirán determinar el nivel de madurez, el cómo alcanzar esos niveles, esos
objetivos, es responsabilidad del informático.
También es importante destacar la definición de modelo desde una perspectiva
matemática, entendido como una representación abstracta de un concepto o una
entidad. Un modelo matemático puede venir representado por una ecuación. Sin
embargo este concepto de modelo es mucho más determinista y presenta menos
ambigüedades que el primero donde en muchas ocasiones se mezcla con el de
metodología o se equipara al de estándar.
Figura 4.1. Función de transferencia en circuito cerrado. Un modelo matemático

que representa un sistema de control tradicional.
Aportamos el concepto de industria clásica frente al de industria del software de igual manera que existen
evidentes diferencias y, al mismo tiempo, claros intentos de aproximación entre la ingenieria del software y las
ingenierías más tradicionales como la ingeniería del motor, aeronáutica, de componentes mecánicos, electrónicos
etc.
2. EL MODELO DE MADUREZ DE LA CAPACIDAD DEL SOFTWARE
El Instituto de Ingeniería del Software, más conocido por su acrónimo inglés

SE1 (Software Engineering Institute) ideó un marco de referencia para el proceso
de creación del software como respuesta al requerimiento del gobierno
norteamericano para la obtención de un método que permitiera valorar la capacidad
de los contratistas de aplicaciones informáticas que accedían a sus licitaciones.
Tras cuatro años de trabajo el SEI, en colaboración con la empresa Mitre
Corporation, desarrolló un modelo apoyado en el concepto de madurez al que
denominó CMM acrónimo del/ inglés Capability Maturuty Model, traducido
habitualmente por Modelo de la Madurez del Desarrollo Software o Modelo de
Madurez de la Capacidad. En 1993 se publicó la Versión 1.1, tras las revisiones
efectuadas sobre la Versión 1 durante los años 1991 y 1992.
Un entorno comercial cada vez más competitivo requiere de tiempos de
desarrollo de nuevas aplicaciones menores a la par que exige productos de calidad,
la estandarización del proceso y la detección de disfunciones en los primeros
estadios del desarrollo software son importantes recursos que han de ser utilizados
de forma obligatoria por las casas de software. Obtener organizaciones de software
maduras preparadas para el reto que supone la realización de aplicaciones
inforrnáticas con la debida calidad es el objetivo de este modelo (ver figura 4.2). El
modelo CMM fue ideado para empresas de software cuyos clientes requieren
productos de calidad en el tiempo fijado.
El Modelo de Madurez guía a las organizaciones indicando cómo mejorar los
procesos asociados al desarrollo y mantenimiento del software. La filosofía general
que rige este modelo se fundamenta en diferentes niveles de madurez, entendidos
como sucesivas etapas cuyo objetivo es la obtención de un proceso software
optimizado. Cada una de estas etapas comprende un conjunto de objetivos a
alcanzar de forma que, una vez satisfechos, implique un mayor nivel de capacidad
en los procesos de la organización.
Es importante indicar que el Modelo de Madurez se fundamenta en la secuencia
de los niveles propuestos. No es aconsejable ni técnicamente adecuado el pretender
un nivel superior sin haber alcanzado el intermedio. Los niveles de madurez
pueden asemejarse a los estratos telúricos, uno sucede a otro, lo apoya y sustenta.
Es fácil entender que no es posible el proceder a una mejora continuada con la
aplicación de nuevas tecnologías, como sería el caso del Nivel 5, sin haber
establecido un control cuantitativo de los procesos software, o haber establecido
estándares adecuados para, por ejemplo, la recopilación o manipulación de datos en
la que asentar la cuantificación de los procesos productivos. El modelo de madurez
propuesto por el SE1 se basa en mejoras continuas y progresivas, no en saltos
cualitativos ni en revoluciones tecnológicas de inesperadas consecuencias. La
exigencia de la calidad no es sólo para los productos materiales, también lo es para
124 MODELOS, METODOLOG~ASY ESTANDARES
los productos inmateriales, los llamados servicios. Dentro de estas empresas de

servicio se encuentran las empresas desarrolladoras de software; y las principales
de ellas han apostado por la calidad.
-Procesos improvisados. -Procesos de desarrollo y

-Estándares y procedimientos no mantenimiento de software bajo control.
seguidos por los trabajadores. -Planes establecidos guían el trabajo a
-El trabajo viene impuesto por crisis realizar.
puntuales a superar. -Existe una comunicación fluida entre
-Acciones de "apagafuegos". equipos de trabajo, existe la transmisión
-Estimaciones de costes, esfuerzos y de experiencia entre los técnicos.
plazos superados al no poseer datos -Estimaciones de costes, esfuerzos y
fiables sobre objetivos a alcanzar. plazos son generalmente respetados.
-Falta de un conocimiento riguroso de -Responsabilidades y cometidos
procesos y de la propia organización. definidos claramente.
-Acciones individuales y "heroicas", a -Funcionalidad y calidad del producto.
veces contraproducentes
Figura 4.2. Objetivos del modelo CMM.
2.1. Los cinco niveles definidos en el modelo CMM
Los cinco niveles de madurez del proceso software definen una escala ordinal
permitiendo la medida de la madurez de una organización. Los niveles de madurez
son:
Inicial
El proceso software se caracteriza porque es ad hoc, incluso ocasionalmente

caótico. Algunos procesos son definidos aunque no se siguen con rigurosidad y el
éxito depende de esfuerzos individuales.
Una organización adjetivada como de Nivel 1 no proporcionaría un entorno

estable para desarrollar y mantener el software. Las necesidades y compromisos de
cada momento son los verdaderos planificadores del trabajo que se encuentra
condicionado por crisis puntuales. El uso de los recursos está comprometido por la
solución de esas crisis por lo que el profesional es un "apaga fuegos", sin
posibilidad de organizar su labor debido a lo perentorio de las situaciones que ha de
resolver. La experiencia del equipo juega un papel primordial junto con una
dirección enérgica, de tal forma que la pérdida de ese equipo o del administrador
implica una merma casi inmediata de la efectividad del servicio de muy difícil
recuperación.
El éxito de organizaciones del Nivel 1 depende exclusivamente de la
competencia de los trabajadores, su interés y predisposición. La selección del
mismo, su entrenamiento o el fichaje de profesionales de valía es el motor de este
tipo de organizaciones.
Las organizaciones establecidas en el Nivel 1, son muy dependientes de ciertos
recursos humanos, centralizando la ejecución de proyectos en la dirección
fomentada por éstos. La pérdida de estos recursos implica la inmediata caída de la
eficiencia de los proyectos y resulta traumática para la organización.
Repetible
Han sido establecidos procesos básicos de gestión del proyecto que permiten el
seguimiento de costes, planificación y funcionalidad. La necesaria disciplina del
proceso consiste en la experiencia acumulada en éxitos anteriores de proyectos con
similares características. Estas experiencias se convierten en la verdadera guía del
proyecto software. Desarrollos anteriores han podido ser documentados, medidos e
incluso mejorados, y el equipo de desarrollo ha sido entrenado en las mismas.
En este nivel se establecen políticas para la administración del proyecto
software y se implementan procedimientos que permitan aplicar dichas políticas.
De nuevo la planificación y administración de los nuevos desarrollos se basan en la
experiencia de proyectos anteriores.
Debido a que el éxito del desarrollo de aplicaciones se basa en gran medida en
experiencias anteriores, nuevos proyectos con requisitos muy diferentes de los ya
abordados implican un evidente riesgo para la organización.
El proceso software de Nivel 2 puede resumirse en un entorno disciplinado y
se encuentra bajo el control efectivo de un sistema de administración guiado por
planes realistas basados en el rendimiento de proyectos anteriores. En este segundo
Nivel la dirección enérgica para el cumplimiento de las pautas de desarrollo
establecidas sigue siendo un factor fundamental de éxito.
El proceso software para las actividades de dirección e ingeniería está
documentado, estandarizado e integrado en el proceso global de creación,
mantenimiento y administración del software de la organización. Se hacen uso de
prácticas propias de la ingeniería del software, los proyectos se adaptan a los
estándares establecidos y permiten un conocimiento de la situación y progreso del
mismo, las versiones de programas y aplicaciones son controladas y su puesta en
explotación es verificada y aprobada adecuadamente.
La existencia de mecanismos de verificación, estándares, así como entradas y
salidas, permite establecer un proceso definido, apoyo básico de administradores y
guía del personal a su cargo. Debido a la existencia de procesos bien delimitados es
posible controlar el progreso de los proyectos y actuar en consecuencia
permitiendo variaciones en los mismos si fuera necesario frente a la constatación
de desviaciones que pudieran dar origen a retrasos en la entrega del producto o
falta de calidad en los mismos.
El proceso software de Nivel 3 puede ser resumido como estándar y consistente.
El trabajo de administradores, ingenieros de software se rigen por procedimiento
establecidos y modelos determinados que permiten que éstos sean repetibles y
estables. Dentro de líneas de producto establecidas, coste, funcionalidad y agendas
están bajo control y la calidad del software es seguida.
Gestionado
Esta etapa se caracteriza por la capacidad de la organización por medir atributos

del software, tanto del producto y su calidad como del proceso creativo asociado al
mismo. Este hecho le permite establecer objetivos cuantitativos y conocer su grado
de cumplimiento.
Atributos relevantes como la productividad y calidad son medidas en aquellos
procesos importantes a lo largo de todo el proyecto software. La dirección se
constituye en un firme aliado del programa de medidas dirigiéndolo y posibilitando
los recursos necesarios para su realización. Este apoyo de la dirección supone un
elemento fundamental en este Nivel.
El proceso de medida no se toma como una tarea puntual, es una actividad
organizada en la que se sustenta la organización y la toma de decisiones de los
administradores, al ofrecer fundamentos cuantitativos que permiten evaluar y
predecir atributos del software y su desarrollo. Recordemos que estas actividades
son las que presentamos al principio de este capítulo como el objetivo principal de
la medida del software, por la que este modelo asume dicho papel, potenciándolo e
incluso definiendo un nivel basado en su recolección y uso. La medida del software

es reconocida como una base fundamental en el desarrollo de aplicaciones
informáticas.
Este nivel de madurez se puede resumir en predecible, ya que el proceso es
medido y opera dentro de los límites establecidos. Este conocimiento cuantitativo
permite predecir tendencias en los procesos y la calidad de los productos. Si las
medidas recogidas implican una desviación de los objetivos marcados se procede a
la realización de acciones correctoras.
Optimizado
En este Nivel la organización incorpora nuevas tecnologías e ideas innovadoras,

en un deseo de mejora continua facilidad por un proceso de retroalimentación
basado en la medida de los atributos propios del proceso software. El impacto de la
incorporación de estas nuevas tecnologías se valora de forma cuantitativa en cuanto
a costes y efectos sobre la organización. Se proponen mejoras en el proceso
software fundamentada en medidas numéricas y previsiones del resultado de su
incorporación a los proyectos. La organización está envuelta en un conocimiento
de sus puntos fuertes y débiles que permitirá la prevención de defectos. Las
organizaciones del Nivel 5 analizan los defectos y determina sus causas.
Este Nivel se puede resumir en una mejora continuada ya que la organización
está envuelta en un continuo esfuerzo de mejora y estudio del rendimiento de sus
procesos. La mejora del proceso se basa tanto en un incremento de los ya existentes
como en el uso de innovaciones y nuevas tecnologías.
Se aprecia en la estructura del Modelo de la Madurez del Software una evidente
preocupación en la obtención de datos cuantitativos como elemento de juicio
necesario para la mejora del proceso productivo. La medición del software es una
actividad básica en este modelo, tal como lo demuestra ser un área clave común del
proceso.
Accedemos a un nivel superior cuando hemos alcanzado uno objetivos, la
organización ha alcanzado ese nivel como consecuencia de estos objetivos.
128 MODELOS, METODOLOG~ASY ESTÁNDARES
1 Nivel 5 1
Procesos de mejora
continua
I Organización
madura
estandarizados
Organización
Figura 4.3. Niveles de madurez en el modelo CMM.
2.2. Áreas clave y características comunes
En el modelo CMM cada nivel de madurez está compuesto de varias áreas

claves de proceso. Estas áreas claves identifican actividades que, al ejecutarse,
implican la consecución de objetivos importantes para la mejora de la capacidad
del proceso productivo. Existen dieciocho áreas clave de proceso, cada una de ellas
contiene una descripción breve de la misma, los objetivos a alcanzar y las prácticas
clave. Las prácticas clave determinan las actividades, procedimientos, directrices y
políticas para cada área clave.
En la figura 4.4 observamos las áreas claves de los procesos para cada uno de
los cinco niveles definidos en el modelo CMM.
Nivel 2
Objetivo: Clarificar requisitos.
Área Clave: Gestión de requisitos (RM).
Objetivo: Documentar los planes.
Área Clave: Gestión de proyectos (SPP).
Objetivo: Recoger medidas de progreso.
Área Clave: Seguimiento y control de proyectos (PTO).
Área Clave: Aseguramiento de la calidad (SQA).
Objetivo: Control de productos.
Área Clave: Gestión de configuración (SCM).
Área Clave: Gestión de subcontratación (SSM).
Nivel 3
Objetivo: Identificar el proceso.
Arrea Clave: Establecimiento del proceso de la organización
(OPF).
Área Clave: Definición del proceso de la organización (OPD).
Área Clave: Gestión integrada del software (ISM).
Área Clave: Ingeniería del producto software (SPE).
Objetivo: Fomentar el trabajo en equipo.
Área Clave: Coordinación entre grupos (IC).
Área Clave: Programa de formación (TP).
Objetivo: Reducir defectos.
Área Clave: Revisión entre iguales (PR).
Nivel 4
Objetivo: Definir metas.
Área Clave: Gestión de la calidad del software (SQM).
Objetivo: Gestionar el progreso.
Área Clave: Gestión cuantitativa del proceso (QPM).
Nivel 5
Objetivo: Optimizar el rendimiento.
Área Clave: Prevención de defectos (DP).
Área Clave: Gestión del cambio de procesos (PCM).
Objetivo: Adoptar nuevas tecnologías.
Área Clave: Gestión del cambio tecnología aplicada (TCM).
Figura 4.4. Áreas clave por niveles.
Cada área clave está organizada en cinco secciones denominadas características

comunes. Cada área clave, además, está descrita tomando como base las prácticas
clave que contribuyen a satisfacer los objetivos de dicha área. Al abordar dichas
prácticas clave se alcanzan los objetivos del área clave del proceso. Las
características comunes nos informan si los objetivos se han cubierto. A
continuación indicamos las características comunes:
Actividades
Describen procedimientos necesarios para implementar un área clave de

proceso. Se relacionan con el establecimiento de planes y procedimientos, a la
realización del trabajo y al seguimiento del mismo.
Compromiso
Describe las acciones que la organización debe lleva a cabo para asegurar que
se ha consolidado un proceso y es duradero. Suele afectar a las políticas de la
organización y al patrocinio de la alta dirección.
Capacidad
La capacidad describe las condiciones que deben existir en el proyecto u

organización para implementar de forma competente el proceso software. Suele
afectar a los recursos y estructuras de la organización y a la formación.
Medidas y análisis
Medición y análisis describen la necesidad de medir el proceso y analizar los

datos obtenidos.
Describe los pasos a seguir para asegurar que las actividades se llevan a cabo de
acuerdo con el proceso establecido. Implica al grupo de aseguramiento de la
calidad.
La posibilidad de conocer los procesos y tareas que conforman el proyecto

software es una de las más críticas informaciones de las que depende el
administrador de los sistemas de información o el ingeniero de software. Muchos
de los profesionales basan este conocimiento en su experiencia personal obtenida
tras participar en diferentes proyectos. Una visión real de la situación en la que se
encuentra el proyecto software sólo es posible con revisiones periódicas
establecidas. Es interesante hacer notar cómo los niveles de madurez del software
propuestos por el SE1 están relacionados con la visibilidad que el proceso del
software posee. El modelo CMM asocia el conocimiento de los procesos a la

capacidad de medir sus atributos. Así en el Nivel 1 el proceso se acercaría a una
entidad amorfa en la que difícilmente se pueden establecer el estado en el que se
encuentra el proyecto o las actividades que lo conforman. En el Nivel 2 los
controles sobre la administración que se establecen permiten una visibilidad del
proyecto en ocasiones definidas. El proyecto puede ser asimilado a un conjunto de
cajas negras en la que es posible establecer ciertos controles en hitos determinados
del proyecto software, conocemos la información entrante y saliente, pero no el
proceso interno. En el Nivel 3 las tareas que conforman esas cajas negras propias
del Nivel 2 son accesibles. Los ingenieros y administradores conocen sus tareas y
responsabilidades. En el Nivel 4 el proceso software definido es controlado
cuantitativamente, por tanto, conocido de forma efectiva. Los administradores
pueden medir el progreso del proyecto. La medida es una base fundamental para la
toma de decisiones. En el Nivel 5 nuevos caminos son incorporados permitiendo,
de manera controlada, la mejora de la calidad y de la productividad. Los
administradores pueden establecer cuantitativamente el impacto de nuevas
tecnologías o mejoras administrativas.
2.3. La calidad, su aseguramiento y medida según el modelo
Observando las áreas clave de cada nivel es evidente que existen algunas
directamente relacionadas con el objeto de este libro. En concreto las áreas claves
identificadas como "garantía de calidad del software" y en especial las áreas clave
del Nivel 4, "gestión de calidad y medidas" y "análisis del proceso" son las áreas
en las que centraremos nuestro estudio.
En las "características comunes", antes comentadas, son destacables las
denominadas "medición y análisis". En éstas, de forma expresa, se indica la
necesidad de medir el proceso software y utilizar dichos datos cuantitativos en los
correspondientes análisis.
El propósito del "aseguramiento de la calidad del software", propio del Nivel 2,
es proporcionar a la dirección la adecuada visibilidad del proceso utilizado en el
proyecto software y de los productos que se están construyendo. Los objetivos se
centran en planificación de las actividades propias del aseguramiento del software,
la verificación de la adhesión de los productos y actividades a estándares,
procedimientos y requisitos aplicables y la información al equipo de trabajo. De
forma expresa no se define la calidad del software y en cuanto a la práctica propia
de la medida y análisis, ésta se centra en la medición de costes y calendario de
ejecución del proyecto. Las medidas que se proponen en este modelo son las
siguientes:
132 MODELOS. METODOLOGIAS Y ESTÁNDARES
- Cumplimiento de hitos para las actividades propias del aseguramiento del

software.
- Trabajo realizado, esfuerzo utilizado e inversiones en actividades propias del
aseguramiento del software
- Cantidad de inspecciones del producto y revisiones de las actividades.
En estas prácticas clave se destaca la formalización de medidas de la entidad

"proceso". Se basan en medidas directas del proceso de aseguramiento de software
(número de hitos, esfuerzo y tiempo utilizado). Además aporta la necesidad de
medida del producto software, en concreto identificando el número de inspecciones
del producto en comparación con el plan de aseguramiento de la calidad
establecido.
El Nivel 4 implica el conocimiento cuantitativo del proceso y producto
software. El área clave "gestión cuantitativa del proceso" tiene por objetivo el
controlar el rendimiento del proceso software de forma cuantitativa. El modelo
CMM considera el concepto "control cuantitativo" como cualquier técnica de
carácter cuantitativo o basado en datos de carácter estadistico apropiado para
analizar el proceso de software3.
Es interesante destacar la Actividad 4 dentro de la característica común:
actividades realizadas. En ella se destaca la necesidad de una definición clara de las
medidas a recopilar, su utilización posterior y el momento en que se van obtener.
De nuevo el modelo aporta ejemplos de medidas de forma genérica, mezclando
medidas propias de procesos y productos (errores detectados en el producto final,
eficacia del proceso de entrenamiento, tamaño y coste del software) según las
definiciones establecidas en el capítulo 2 del presente estudio.
En cuanto al propósito del área clave gestión de la calidad del software es el de
obtener un conocimiento cuantitativo de la calidad de los productos software del
proceso productivo. Este objetivo coincide literalmente con el estudio que venimos
realizando. De forma textual el modelo enuncia:
El propósito de la gestión de la calidad es desarrollar un conocimiento
cuantitativo de la calidad de los productos del proceso software y alcanzar los
específicos objetivos de la al ida d.^
En cuanto al propósito del área clave gestión de la calidad del software es el de
obtener un conocimiento cuantitativo de la calidad de los productos software del
proceso productivo. Este objetivo coincide literalmente con el estudio que venimos
realizando. De forma textual el modelo enuncia:
3
SEI. Capability Maturity Model for Software, Versión 1.l, TR. Software Engineering. Institute-Camegie Mellon
Universitiy. 1993. Pág. 5. La traducción es nuestra.
SEI. Op. Cit. Pág. 36. La traducción es nuestra.
"El propósito de la gestión de la calidad es desarrollar un conocimiento

cuantitativo de la calidad de los productos del proceso software y alcanzar los
específicos objetivos de la calidad".'
No se aporta un concepto de calidad de forma expresa. La calidad a controlar y

medir es identificada en el propio proyecto como parte del mismo.
Se expresa la necesidad de identificar características del producto software.
Como ejemplo de estas características, en la actividad 3 dentro de la característica
común, actividades realizadas, se aportan, entre otras, las siguientes:
o Funcionalidad.
o Fiabilidad.
o Facilidad de uso.
o Facilidad de mantenimiento.
Existe una relación evidente entre el concepto característica del software

aplicado por esta metodología con el concepto atributo del software explicado en el
capítulo 2 del presente estudio. La entidad poseedora del atributo no se identifica
de forma expresa aportándose el concepto producto software de forma genérica sin
diferenciar si se trata de un proceso, producto o recurso. El modelo CMM indica la
necesidad de cuantificar las características de la calidad del producto software.
Siguiendo con la filosofía general del modelo no se profundiza. El modelo CMM
explica qué ha de hacerse, no el cómo, aportando ejemplos significativos
relacionados directamente con las tareas a realizar. De nuevo no se indican de
forma expresa atributos medibles o entidades poseedoras de las mismas. Así, por
ejemplo, se presenta la medida valor medio entre errores sin una clara indicación
de atributo medido.
El modelo CMM otorga una elevada importancia a la calidad del software y su
medida. La calidad es propia de la definición de cada proyecto, por lo que de forma
implícita aporta el concepto de calidad como una percepción del resultado final
frente a los requerimientos presentados.
En este modelo no hace una clara definición de las medidas a coleccionar, ni
identifica procesos, productos o recursos a medir. Aporta ejemplos de medidas
como apoyo a la metodología, sin incluir un análisis detallado de los mismos.
5
SEI. Op. Cit. Pág. 36. La traducción es nuestra.
3. MODELO BOOTSTRAP
El CMM ha sido, sin lugar a dudas, un punto de referencia básico en la

ingeniería del software. Cualquier otro modelo posterior al desarrollado por el SE1
hace referencia a éste, e incluso lo asume y utiliza. Sin obviar los incuestionables
méritos que el Modelo de Madurez posee, su aplicación en el ámbito europeo
manifestó una serie de disfunciones. Tal y como apunta el profesor Guenter R.
Koch "...el modelo de Valoración de la Madurez propuesto por el SE1 mostraba
ciertas debilidades que lo hacían difícil de aceptar desde el punto de vista de la
mentalidad europea.. .".
A la vista de este hecho la Comunidad Europea apoyó un proyecto cuyo
objetivo era la transferencia de tecnología del software, entendida ésta, no como un
instrumento de presión sobre las organizaciones, tal como supuso el CMM, sino
como un apoyo a las mismas, estimulando el mercado de las tecnologías de la
información. En este clima el proyecto BOOTSTRAP supuso una nueva
orientación, en la cual la transferencia de tecnología debía ser comprendida como
un catalizador de la pujanza del mercado, de forma que motivara a productores y
usuarios a introducir métodos y herramientas para el desarrollo y mantenimiento
del software.
"El proyecto BOOTSTRAP debía fertilizar los campos para introducir moderna
tecnología del software en las empresas. Ésta se haría a través de un análisis del
estado actual de la industria de la ingeniería del software identificando los cambios
potenciales y motivaciones que permitieran aceptar nuevos contextos para la
ingeniería del software"
3.1. El concepto Bootstrap, del diagnóstico a la solución
El modelo BOOTSTRAP propone un método y los instrumentos necesarios que

permiten identificar los puntos débiles de la organización, además de presentar los
cambios necesarios para obtener una mejora de la situación.
El modelo del proceso básico elegido por Bootstrap se centra en entidades
extendidas por lazos de retroalimentación, estos lazos se entienden como procesos
de comparación entre las características medidas y las deseadas, es decir, aquellas a
las que se tiende. De nuevo el proceso de medida surge como una necesidad del
modelo propuesto, y base fundamental del mismo.
La idea que resumiría el concepto Bootstrap es la mejora cíclica propia de la
filosofía Kaizen que propone una continua secuencia del tipo PlaniJicar-Hacer-
Comprobar-Acción.
Por otro lado BOOTSTRAP se asienta en que antes de cualquier inversión en
tecnología tales como herramientas de última generación o complicados soportes
infomiáticos debe implementarse a través de una adecuada metodología la solución

a los problemas que pudieran afectar a la organización. La fórmula propuesta es:
Como máxima fundamental de este modelo se puede indicar que la forma de

superara la crisis del software es mejorando el proceso de organización por el cual
el software es creado, manejado y mantenido.
Los ámbitos cubiertos por BOOTSTRAP serían:
a) Áreas objeto de interés.

b) La estructura y comportamiento del área estudiada, esto es, su organización.
c) La escala de la organización utilizando un modelo de referencia.
d) Las métricas que permitan "medir" la organización.
e) El proceso de cambio hacia un estado mejor.
La comunidad del software sólo recientemente ha asimilado al software como

un producto en el que el proceso de creación y mantenimiento son de igual
importancia e interdependientes. Bajo esta declaración de principios para
BOOTSTRAP existen dos aspectos básicos en el modelo del proceso:
o Una estructura en capas jerárquicas. Bootstrap eligió un modelo clásico

admitido y estandarizado por la Agencia Espacial Europea. En este modelo
la asunción básica es que el desarrollo software puede ser presentado como
un flujo lineal de actividades bien definidas que conforman el ciclo de vida.
o Una medida del proceso basada en un modelo de referencia y su escala. La
medida se entiende aquí como una comparación con una escala ordinal La
escala de medida propuesta por el SE1 a través de su modelo CMM fue
aceptada como adecuada.
La razón fundamental de la elección de un modelo de organización orientado al

proceso es permitirnos una sólida base sobre la cual "medir" las organizaciones, o
de forma más precisa, la madurez de dichas organizaciones (su calidad). El haber
elegido el modelo de referencia del ciclo de vida propuesto por la ESA, es una base
fundamental sobre la que comparar modelos de procesos de otras compañías, es
una referencia. Evidentemente elegir el modelo propuesto por la ESA es debido a
que se ha considerado altamente maduro y de gran calidad.
136 MODELOS, METODOLOG~ASY ESTÁNDARES
Los objetivos de la valoración BOOTSTRAP serían:
o Medir y desarrollar un perfil de la calidad para el SPU (Unidades de

Producción de Software) de forma analítica, descubriendo debilidades
y fortalezas del SPU.
o De las fortalezas y debilidades descubiertas derivar los pasos para
obtener una mejora desde el punto de vista de un plan de acciones
recomendadas para ser ejecutadas de forma inmediata.
o Transformar el plan de acción en una serie de mini-proyectos que
implementen los pasos recomendados para la mejora.
3.2. Práctica del modelo
En la práctica la metodología Bootstrap se basa en un conjunto de cuestionarios

que actúan de sensores, permitiéndonos conocer el estado en que se encuentra la
organización así como su estructura interna. Estos sensores pueden ser
considerados como métricas de atributos determinados del software, si nos ceñimos
a la teoría de la medida expuesta en este texto (ver capítulo 2), de hecho todo el
proceso de obtención de datos de la organización puede ser comparado con la
aproximación GQM (Goal Question Metrics) pero con diferente profundidad y
jerarquía.
El cuestionario es altamente interactivo permitiendo una clara intervención de
asesores y asesorados. Los datos son adquiridos desde el mismo momento en el que
comienza este cuestionario. Esta batería de preguntas puede dividirse en tres
grandes grupos:
1. Un cuestionario complejo sobre datos generales de la organización. Su

estructura, área de actividad, aplicaciones dominantes, sistemas de calidad
asociada a la administración de recursos.
2. Un cuestionario sobre la metodología e ingeniería utilizada. Procesos en
general, proceso independiente propios del ciclo de vida tales como proyectos y
administración de la calidad.
3. Cuestionario sobre la tecnología y su transferencia. Datos sobre la
introducción tecnológica, soporte de procesos y funciones a través de la
tecnología. Soporte tecnológico dependiente e independiente del ciclo de vida.
En el caso de dependencia del ciclo de vida se refiere a herramientas CASE,
computadoras, redes...
Madurez BOOTSTRAP
Tecnología
Innovación tecnológica
Sistema de Calidad Funciones para el ciclo de vida
Administración de los Funciones independientes del
recursos ciclo de vida
Metodología
--
Funciones de Procesos
Descripción de procesos Funciones de Desarrollo
Funciones de Administración Medida de los procesos Modelo de desarrollo
Administración de configuración Control de los procesos Requisitos, análisis y definición
y cambio Diseño de la arquitectura
Administración de riesgos Implementación y diseño
Administración de proyectos detallado
Administración de la calidad Prueba
Administración de subcontratistas Operatoria y mantenimiento
Sistemas de propósitos especiales
Figura 4.5. Proceso de valoración Bootstrap.
El paso segundo es una conclusión directa del análisis realizado en el paso

primero.
El tercer paso ha de ser organizado como un proceso interactivo de decisiones
que envolvería a todos los miembros de la organización.
El primer resultado de los datos obtenidos es conocer el nivel de madurez del
SPU (o proyecto) en una escala similar a la propuesta por el modelo CMM:
1 ( bajo) a 5 (alto) para la Organización y la Metodología
A (bajo) a B (alto) para la Tecnología

Organización Ingeniería Ingeniería Ingeniería Tecnología

del Soporte del del Producto
Atributos del Proceso
Figura 4.6. Gráfico de barras típico de la valoración Bootstrap.
El segundo resultado es la cuantificación desde el punto de vista de porcentaje

de los atributos clave propuestos por el Bootstrap. Cada uno de los niveles
inferiores es valorado individualmente, contribuyendo a la obtención del valor
inmediatamente superior y finalmente del sistema en su conjunto. De esta forma se
obtiene un perfil sobre las fortalezas y debilidades del SPU. Estos perfiles se
presentan en histogramas absolutos, en un primer momento, y en uno relativo con
posterioridad. Los valores de este segundo histograma se obtienen comparando los
resultados del perfil individual de cada uno de los criterio básicos con la media de
cada uno de éstos a lo largo del tiempo. Gracias a los datos acumulados se pueden
obtener interesantes resultados en los que se pueden comparara buenas y malas
prácticas de la organización en comparativa con sus competidores.
La valoración es presentada a través de una serie de gráficos de barras, de forma que es
fácil identificar en qué áreas son aquellas más necesitadas de una actuación correctora.
4. LA NORMA ISO 15504
El incremento en el número de modelos y estándares destinados a la valoración

y mejora del software y su proceso de desarrollo (CMM, Trillium, Bootstrap,
Technology Diagnostic, entre otros) propiciaron, al inicio de la década de los años
noventa, el sentimiento generalizado de la necesidad de promover un estándar
internacional que armonizara los modelos de referencia existentes.
El proyecto SPICE, acrónimo de las palabras inglesas Software Process
Improvement and Capability Determination, promovido por ISO surgió como un
esfuerzo de colaboración internacional que debía materializarse en un nuevo
estándar para la valoración del proceso del software. El grupo de trabajo que
llevaría a cabo esta labor, denominado WG10, contaría con un equipo central de
profesionales con dedicación exclusiva, además de aportaciones de investigadores,
estudiosos y profesionales de más de veinte países.
El proyecto SPICE debía proporcionar el soporte necesario para la elaboración
del nuevo estándar. La realización de pruebas de campo sería una labor
fundamental de la que se deberían extraer los datos oportunos y derivar los análisis
que posibilitarían la mejora del modelo en sus diferentes borradores. La promoción
del nuevo modelo y el seguimiento del mismo con objetivo de propiciar su
evolución serían otras de las labores encomendadas al grupo de trabajo 10.
ISO International Organization for Standards
IEC International Electrotechnical Commission

Joint Technical Committee 1
JTC1
Responsables de las Tecnologías de la Información
SC7 Software Engineering
WGlO Working Group on Software Process Assessment
Tabla 4.1. La organización ISO y el proyecto SPICE. Acrónimos en inglés.
El estándar resultante del proyecto debía cumplir ciertos objetivos:
O Ser lo suficientemente genérico para tener un amplio horizonte de

aplicación, a la par de lo suficientemente específico como para ser útil
y manejable.
O Establecer los mecanismos que permitieran migrar desde estándares ya
establecidos, así como evitar la aparición de otros estándares de facto.
O Proporcionar un programa de transferencia tecnológica que permitiera
la adopción del nuevo estándar.
Desde el nacimiento del proyecto SPICE hasta nuestros días una serie de hitos
se han sucedido en el proceso de creación de la nueva norma. El largo camino
recorrido por ésta nos da cuenta del cuidadoso estudio que requiere la creación de
un modelo de estas características.
En el bienio 1993-1995 el borrador del producto fue desarrollado y se realizaron
las primeras pruebas de campo. En el verano de 1996 se reflejaron diferentes
cambios en la norma para ajustarla a los datos recogidos en las pruebas efectuadas.
En octubre de ese mismo año se celebró un encuentro en Méjico del grupo de
trabajo número 10 (WG10) en el que la comunidad internacional, por primera vez,
pudo conocer las partes que definen el modelo. A mitad de noviembre de 1996 se
entregó a la secretaría del comité SC7 las nueve partes de documento comenzando
el período de votaciones. En la actualidad el proyecto ha alcanzado el llamado
estado 90.92, es decir se encuentra en fase de revisión. La norma ISO/IEC 15504
ha rebasado, por tanto, el estado del borrador DTR (Draft Technical Report) y
también la votación de los miembros del comité JTC1. En los años sucesivos a la
publicación de informe técnico éste se encuentra sujeto a estas revisiones por parte
del ya nombrado comité JTC1. El objeto de este período es reexaminar la situación
del informe técnico publicado y, si es posible, alcanzar el acuerdo internacional
necesario para la publicación de un estándar internacional que reemplace al
mismo.
Software Engineering Institute, EE.UU AFNOR, Francia

AT&T Be11 Labs, EE.UU IBM, Australia
Be11 Canada Fujitsu, Japón
Northen Telecom, Canadá NTT, Japón
British Telecom, Gran Bretaña CSELT, Italia
ITDC, Finlandia Brameur, Gran Bretaña
Defense Research Agency, Gran
Etnoteam, Italia
Bretaña
Tabla 4.2. El deseo por internacionalizar del proyecto SPICE implica la

colaboración de numerosos organismos.
4.1. ISO 15504, un modelo bidimensional
El modelo, a través de una aproximación estructurada, nos permite valorar los

procesos software, fomentando la auto evaluación y ofreciendo un mecanismo por
el cual los adquisidores pueden ganar confianza en los resultados de la valoración,
de esta forma los datos obtenidos pueden ser utilizados para fines de calificación de
los suministradores, permitiendo determinar la capacidad de los procesos, así como
su adecuación para cumplir un requisito determinado o una clase de requisitos. La
norma ISO 15504 se basa en otra norma de ISO, la 12207 que describe el ciclo de
vida según esta organización.
Las partes de la norma ISO 15504 liberadas son:
ISOIIEC 15504 - 1. Information technology - Software proccess assessment.

Part 1: Concepts and introductory guide. Technical Report, publicado el 15 de
agosto de 1998.
Part 2: A reference modelo for processes and process capability. Technical Report,
publicado el 15 de agosto de 1998.
Part 3: Performing an assessment. Technical Report, publicado el 15 de agosto de
1998.
Part 4: Guide to performing assessment. Technical Report, publicado el 15 de
agosto de 1998.
ISOIIEC 15504 - 5. Information technology - Software proccess assessment. An
assessment model and indicator guidance, 1999.
Part 6: Guide to competency of assessors. Technical Report, publicado el 15 de
agosto de 1998.
Part 7: Guide for users in process improvement. Technical Report, publicado el 15
de agosto de 1998.
Part 8: Guide for use in determining supplier process capability. Technical Report,
publicado el 15 de agosto de 1998.
Part 9: Vocabulary. Technical Report, publicado el 15 de agosto de 1998.
El modelo ISO/IEC 15504 también está ideado para determinar la idoneidad de

los procesos de otras organizaciones para un contrato determinado o clase de
contrato.
onceptos y gula introductoria Vocabulario
y guía indicadora
Figura 4.7. ISOIIEC 15504, componentes y sus relaciones.
Evaluación de los procesos, mejora de los procesos y determinación de la

capacidad son los objetivos a alto nivel propuesto por el proyecto SPICE.El
modelo de referencia se fundamenta en dos dimensiones bien determinadas y
complementarias. Una de ellas determina los procesos a ser valorados, definiendo
el proceso de vida del software. La otra dimensión presenta una escala para evaluar
la capacidad. La escala elegida posee cinco niveles caracterizados por un conjunto
de nueve atributos de procesos, que a su vez, son tasados según en grado de
cumplimiento de los mismos indicado en tantos por ciento.
La primera dimensión denominada dimensión del proceso define un conjunto
estándar de procesos para el ciclo de vida completo del software. La dimensión del
proceso parte de tres clases básicas de procesos (Primaria, Soporte y
Organizativas), éstas se dividen en cinco categorías de proceso (Cliente/
Suministrador, Ingeniería, Soporte, Administración, Organización), veinticuatro
procesos de alto nivel, y otros dieciséis componentes. Cada proceso se define desde
el punto de vista de su finalidad y como un conjunto identificado de resultados.
Soporte
SUP. 1 Documentación
MAN. 2 Admir SUP.2 Administración de la
configuración
SUP. 3 Aseguramiento de la
calidad
SUP. 4 Verificación
SUP. 5 Validación
SUP. 6 Revisión
SUP. 7 auditoria
RG. i Orien SUP. 8 Resolución de
-..,.""'- problemas
1 delprocesc
el proceso
nrnrern
Figura 4.8. Arquitectura de los procesos según ISOAEC 15504.
La dimensión de la capacidad del proceso se sustenta en un conjunto de

atributos que determinan el nivel. El objetivo de esta dimensión es definir la escala
de medida para la capacidad del proceso, para ello se considera una escala de tipo
ordinal de seis puntos. Hagamos hincapié en la base fundamental que para este
estándar representa la medida del software de igual manera que en el caso CMM.
Los niveles considerados por el estándar son:
Incompleto
Hay un fallo generalizado al alcanzar los propósitos del proceso.
Realizado
El propósito del proceso es generalmente alcanzado. Este éxito no tiene por qué
haber sido rigurosamente planificado ni seguido.
Gestionado
El proceso libera productos de acuerdo a procedimientos específicos y es

planificado y seguido.
Establecido
El proceso es llevado a cabo usando procesos definidos basados en principios de

la ingeniería del software.
Predecible
El proceso definido es ejecutado en consistencia con controles de límites

establecidos, para alcanzar los objetivos definidos. Medidas detalladas del
rendimiento son coleccionadas y analizadas.
Optimizado
La realización de los procesos se encuentra optimizadas de forma que coincidan

con las necesidades actuales y futuras de negocio. Los resultados de los procesos
son alcanzados de forma repetida de acuerdo con los objetivos definidos.
Niveles y atributos
Nivel O Proceso Incompleto
Nivel 1 Proceso Realizado
Procesos propios del Ciclo de Vida Rendimiento del uroceso
Cliente K I \ F I2 P r o c e s c ~ . ~ \ d r n ~ n ~ ~ ~ r ' d d ~ ~
Adquisicion. Suministro, Operdcion Admini\iraiii>n del Kcndimitnto
Requisitos Administración del Trabajo del
Inoenieria Producto
Deiarrollo,Mantenimiento Nivel 3. Proceso establecido
Sum~nistrador Definición del Proceso
Documentacion, Adminstracion de Recursos del Proceso
~ o n f i g u r d ~ i oaseguramiento
n, de la calidad, Nivel 4 Proceso Predecible
vrrificdcion, validacion, revision, auditoria, Medida del Proceso
resoluc~onde problemas Control del Proceso
Administracion Nivel S Proceso Optimizado
Administracion, proyecto, cali+d y riesgos Cambio del Proceso
Organizac~m Mejora Continua
Oricntac~on,mejora, recursos humanos.
infraestmctura, medida y reuso
,
Figura 4.9. Las dos dimensiones del estándar ISO/IEC 15504.

Los niveles de capacidad, aisladamente, no son suficientes para evitar

ambigüedades en la cuantificación de la capacidad de los procesos, por lo que son
necesarios una serie de atributos comunes a todos los procesos. Estos atributos son
utilizados como base para la valoración. Cada uno de ellos está definido desde el
punto de vista de las características que el proceso debería exhibir. Para cada
atributo hay una descripción general y un conjunto de características específicas, de
forma que cada uno es evaluado para cada proceso valorado, desde el punto de
vista del grado de realización del mismo. Los valores son asignados en una escala
de cuatro puntos no alcanzado, parcialmente alcanzado, altamente alcanzado y
totalmente alcanzado. Considerando el valor de cada atributo podremos determinar
el nivel en qué se encuentra el proceso estudiado. El modelo de evaluación se basa
en el principio de que la capacidad del proceso se puede evaluar si se demuestra la
consecución de los atributos del proceso.
1 Nivel 1
Atri. Proc.: Rendimiento del Proceso (51%-100%)
Nivel 2
I Atri. Proc.: Rendimiento del Proceso (86%-100%)

Atri. Proc.: Administración del Rendimiento (51%- 100%)
Atri. Proc.: Administración del Trabajo del Producto (51% - 100%)
Nivel 3
Atri. Proc.: Administración del Rendimiento (86%-100%)
Atri. Proc.: Definición del Proceso (51%-100%)
Atri. Proc.: Recursos del Proceso (51%-100%)
Nivel 4
Atri. Proc.: Recursos del Proceso (86%- 100%)
Atri. Proc.: Medida del Proceso (51%-100%)
Atri. Proc.: Control del Proceso (51%-100%)
Nivel 5
Atri. Proc.: Recursos del Proceso (86%-100%)
Atri. Proc.: Medida del Proceso (86%-100%)
Atri. Proc.: Control del Proceso (86%-100%)
Atri. Proc.: Cambio del Proceso (5 1%-100%)
Atri. Proc.: Mejora Continua (51%-100%)
Tabla 4.3. Niveles, atributos de los procesos asociados y grado de cumplimento.
Esta aproximación no sólo permite conocer el nivel en qué se encuentra
nuestros procesos, es una guía que nos permite su mejora al conocer el valor qué
deben tener los atributos para conseguir un nivel superior de excelencia, según la
escala propuesta. La dimensión de la capacidad no sólo sirve para cuantificar la
capacidad de la organización, también es una guía para su optimización.
4.2. La calidad, su aseguramiento y medida en la norma
Debido a que el modelo de referencia ISO 15504 es un modelo bidimiensional,

los conceptos a estudiar en detalle en este apartado (calidad y medida), así como
sus posibles relaciones, aparecen en el proceso propio de la organización
denominado administración de la calidad, incluida en la dimensión del proceso, y
en el Nivel 4 en el atributo medida propio de la dimensión de la capacidad. A
continuación exponemos los resultados del estudio de estos conceptos es el modelo
de referencia.
En la parte 2 del modelo de referencia "Modelo de referencia para procesos y
capacidad" aparecen indicaciones directas a la calidad y su aseguramiento, así
como a su medida. Tal como demuestra la siguiente cita:
"El objetivo del proceso de la administración de la calidad es monitorizar la

calidad de los servicios y productos del proyecto y asegurar que ésta satisface al
6
clientew .
Se observan coincidencias con el resto de modelos estudiados focalizando el

concepto calidad con la satisfacción del cliente y la de exponer la necesidad de su
observación (el modelo la define como monitorización).
De forma clara y concisa se asocia la calidad como cumplimiento de los
requisitos, tanto explícitos como implícitos, expuestos por el cliente.
Dentro de proceso de soporte en el apartado denominado aseguramiento de la
calidad también se hace referencia expresa a proporcionar el aseguramiento que
productos y procesos de un proyecto cumplen con sus requerimientos especzjkos y
7
se adhieren a los planes establecidos . De forma expresa se cita a la normativa ISO
9001 como complemento a utilizar en este punto de la norma ISO 15504.
El modelo estudiado considera la medida como un proceso propio de la parte
organizativa del ciclo de vida.
"El propósito del proceso de medida es coleccionar y analizar datos

relacionados con los productos desarrollados y los procesos implementados dentro
'ISO/IEC TR 15504-2. Information technology -Software process assessment - Parti2 A reference modelfor
processes andprocess capability. ISOIIEC. Suiza, 1998. Pág. 19.
' ISO/IEC TR 15504-2. Information technology -Software process assessment - Part:2 A reference model for
de la organización, para ejecutar una efectiva administración del proceso y

demostrar objetivamente la calidad del mismom8.
Es sumamente interesante la expresa referencia a la necesidad de medir como
factor estratégico de la organización para asegurar la calidad del proceso
productivo.
El dimensionamiento de la capacidad se fundamenta en medir una serie de
atributos definidos en el proceso de desarrollo software. Es especialmente
destacable que el Nivel 4 del modelo se denomine proceso predecible. En dicho
estado los atributos definidos son atributos de medida y atributo de control de
proceso.
Es fácilmente identificable cómo se hace uso de propiedades (atributos) de
aquellas entidades (procesos en este caso) para llegar a obtener una escala ordinal
del nivel de capacidad de una organización. Este desarrollo lógico coincide con el
aportado en el capítulo 2 del presente estudio. La organización se describe en
función a un modelo basado en procesos cuyos atributos, su medida, determina el
grado de madurez de la misma.
La relación de la calidad y su medida, de nuevo se considera un factor
estratégico. El modelo exige su control y medida pero no aporta cómo obtener
estos objetivos aunque hace referencia expresa al almacenamiento de datos
históricos.
En conclusión el modelo de referencia no considera técnica o desarrollo teórico
expreso en cuanto a la medida del software aunque afirma su necesario control. La
calidad y su medida son factores estratégicos en la organización, de tal importancia
que el Nivel 4 sólo se alcanza cuando se han logrado satisfacer objetivos
relacionados directamente con la medida de atributos propios de los procesos
definidos. Sin embargo la definición precisa de atributos no se define de forma
expresa.
Incluido en el Plan de Acción de la Subdirección General de Coordinación de

Informática del Ministerio de Administraciones Públicas (MAP) se elaboró una
metodología de desarrollo de sistemas de información denominada MÉTRICA.
La primera versión se remonta a 1989, MÉTRICA V. 1: Guías metodológicas,
pero fue en 1993 cuando se publicó la versión 2: Guía técnica, de referencia y de
usuario. En 1995 se liberó la versión 2.1 y en julio de 2001 se ha liberado la
versión 3, mejora resultante de la publicación del correspondiente borrador en
ISO/IEC TR 15504-2. Information technology -Sofhoare process assessment - Part:2 A reference model for
enero de 2001 y la consideración de las aportaciones recopiladas en esos siete
meses.
Para la elaboración de MÉTRICA V.3 se han considerado métodos
(EUROMETODO, SSADM V4, MAGERIT, Information Engineering), normativa
intet-nacional (ISO 12.207, ISOIIEC TR 15504/SPICE, UNE-EN ISO 9001 :2000,
IEEE 610.12- 1.990) y se han tenido en cuenta diferentes tecnologías propias de la
informática y las comunicaciones (clientelservidor, orientado a objeto, reutilización
y bases de datos, entre otras).
La elaboración de MÉTRICA se basa en la participación de diferentes actores
relevantes en la ejecución de proyectos informáticos. En concreto los intervinientes
en la última versión han sido:
O MAP y el Comité de Seguimiento.

O Administración General del Estado (Defensa, Interior, Justicia, Trabajo,
entre otros).
O Comunidades Autónomas (Andalucía, Castilla-La Mancha, Madrid, País
Vasco).
O Ayuntamientos.
O Informática El Corte Inglés (IECISA).
O Universidad Carlos 111de Madrid.
O Fondos PEINATYCA.
Los usuarios a los que va dirigida MÉTRICA V. 3. pueden resumirse en:
O Administración del Estado.

O Comunidades Autónomas.
O Ayuntamientos.
O Centros de enseñanza de ingeniería del software.
La metodología MÉTRICA es utilizada habitualmente como referencia en

licitaciones cuyo objeto es el desarrollo de programas para ordenador publicadas
por organismos de carácter institucional españoles. Las empresas aportan el
cumplimiento de esta metodología como instrumento que permite la ejecución en
plazo y coste del proyecto adjudicado. Esta consecuencia proviene de los objetivos
principales que esta metodología expresa de forma determinante en su primer
capítulo:
"La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un

instrumento útil para la sistematización de las actividades que dan soporte al ciclo
de vida del software. La nueva versión de MÉTRICA contempla el desarrollo de
Sistemas de Información para las distintas tecnologías que actualmente están
conviviendo y los aspectos de gestión que aseguran que un proyecto cumple sus
objetivos en términos de calidad y coste."
5.1. MÉTRICA, una metodología basada en procesos
MÉTRICA propone una descomposición de los procesos en actividades,

dividiendo a su vez éstas en tareas. Para cada tarea se definen sus productos
resultantes, entradas, contenido, técnicas, prácticas y participantes definiendo de
forma expresa cada uno de estos elementos.
Los procesos principales de MÉTRICA Versión 3. son:
O Planificación de sistemas de información.

O Desarrollo de sistemas de información.
O Mantenimiento de sistemas de información
A su vez el proceso principal desarrollo de sistemas de información se ha

dividido en cinco procesos:
O Estudio de viabilidad del sistema (EVS).

O Análisis del sistema de información (ASI).
O Diseño del sistema de información (DSI).
O Construcción del sistema de información (CSI).
O Implantación y aceptación del sistema (IAS).
MÉTRICA Versión 3 aporta un conjunto de procesos (definidos en la

metodología como interfaces) orientados a la organización y como apoyo al propio
proceso de desarrollo. Estas interfaces definen un conjunto de actividades que,
según la propia'met~dolo~ía:
"En el caso de existir en la organización se deberán aplicar para enriquecer o

influir en la ejecución de las actividades de los procesos principales de la
metodología y que si no existen habrá que realizar para complementar y garantizar
el éxito del proyecto desarrollado con MÉTRICA Versión 3."
Las interfaces que define MÉTRICA Versión 3 son:
O Gestión de Proyectos (GP).

O Seguridad (SEG).
O Aseguramiento de la Calidad (CAL).
O Gestión de la Configuración (GC).
La metodología MÉTRICA Versión 3 también aporta técnicas con la intención

de ayudar en la obtención de los productos resultantes de las tareas definidas.
Igualmente propone herramientas que permitan automatizar el desarrollo y facilitar

el trabajo de los profesionales TIC.
A modo de ejemplo indicamos como METRJCA Versión 3. propone el uso del
Análisis del Punto Función para la estimación de esfuerzos en el proyecto software,
entre otras muchas técnicas propuestas.
METRICA es una metodología extensa que debe adaptarse al sistema de
información que estemos desarrollando. No es adecuado aplicar MÉTRICA en toda
sus extensión a proyectos que no lo requieran, adecuando las tareas a ejecutar a las
dimensiones del proyecto software. Un claro ejemplo de este hecho es la inclusión
en la metodología de un apartado destinado a los Planes de Sistemas de
Información. Es evidente que el desarrollo de una aplicación informática limitada
en cuanto a recursos y funcionalidades no debe comenzar con la elaboración de un
completo plan de sistemas, aunque sí deberá considerar la existencia del mismo en
la organización y adecuarse a las líneas estratégicas establecidas por éste.
A modo de ejemplo se indican a continuación actividades y tareas consecuencia
de aplicar MÉTRICA Versión 3. en uno de sus apartados, en concreto en el
definido como EVS (Estudio de Viabilidad del Sistema). Cualquier otro apartado
de la metodología se deberá aplicar de forma similar a lo que veremos a
continuación.
La figura 4.10 es una imagen muy significativa de las actividades que forman
parte del proceso Estudio de Viabilidad del Sistema. Se determinan con precisión
entradas y salidas del proceso, resultado y tareas que lo componen. Es interesante
observar como la existencia de un Plan de Sistemas de Información es recogida de
forma expresa como entrada de las tareas que componen este proceso. La
elaboración de una posible solución a un requerimiento debe estar encuadrada en la
estrategia corporativa especificada en el plan de sistemas de la institución.
EVS 1,
EVS 2, Situación actual
EVS 3, Catálogo de Análisis del
EVS 4, Requisitos Sistema de
EVS 5, y Objetivos Información
EVS 6. Alternativas
de Solución
Solucinn Pronuesta
Figura 4.10. Actividades consideradas en el proceso de Evaluación del Sistema de

Información.
De las actividades que constituyen este apartado consideremos la denominada

EVSl (Establecimiento del alcance del sistema). Las tareas, productos,
participantes, técnicas y prácticas asociadas a la misma se resumen en la tabla 4.4.
Catalogo de Usuarios. trabajo. Jefe de Proyecto

Plan de Trabajo. Analista.
Tabla 4.4. Tareas, productos, práctica y participantes, EVS.
La aplicación de MÉTRICA Versión 3 proporciona sistemas con calidad y

seguridad, no obstante puede ser necesario en función de las características del
sistema un refuerzo especial en estos aspectos, refuerzo que se obtendría aplicando
la interfaz correspondiente.
Según la propia metodología:
"efinen una serie de actividades de interfaz con otros procesos organizativos o

de soporte que, en el caso de existir en la organización, enriquecerán o influirán en
la ejecución de las actividades de los procesos principales."
MÉTRICA Versión 3, aporta un apartado específico de técnicas a utilizar en los

procesos antes indicados. Estas técnicas proporcionan al ingeniero de software
herramientas con las que obtener diferentes productos propios del ciclo de vida del
software. Las herramientas propuestas son de muy diversa naturaleza afectando a
las fases de desarrollo, gestión y soporte. Diagramas de distinta naturaleza y
objetivo, herramientas de estimación y planificación, análisis de impacto,
prototipado de aplicación etc. son algunas de las muchas propuestas por MÉTRICA
Versión 3 como apoyo al ingeniero de software.
Capítulo 5
No será nada inútil ni ocioso...

haceros recordar la primera fuente y origen1
La rápida evolución de la tecnología informática, con sus impresionantes

mejoras en prestaciones y rendimiento, no ha sido acompañada por una análoga
evolución en el desarrollo de la industria del software, es la llamada "crisis del
software". Por ello los equipos de 1 + D de las empresas y numerosos profesores
universitarios han dedicado sus esfuerzos a la investigación y desarrollo de nuevas
formas de desarrollo de software, dando lugar a modelos y metodologías. Estos
modelos y metodologías, a pesar de mejorar la situación, no llegan a obtener
resultados espectaculares, por lo que se abren camino nuevas ideas y modelos. De
entre ellos empiezan a destacar los llamados modelos conceptuales, que permiten el
enlace entre los requisitos de los usuarios y la solución software correspondiente y
permiten modelar, además de los aspectos estáticos de los Sistemas Informáticos,
algunos aspectos de su comportamiento.
1. MODELOS CONCEPTUALES
1.1. Definiciones
Olivé define el modelo conceptual como "la búsqueda y definición formal del
conocimiento general sobre un dominio que un sistema de información (SI)
necesita conocer para llevar a cabo las funciones requeridas."2
' Francois Rabelais. Pantagruel, cap. 1 (1532).

A. Olivé. An introducfion lo concepfual modeling of ifIformation Systern. Cap. 2. Advanced Database
Technology and Desing. Artech House, 2000.
154 METRICAS PARA MODELOS CONCEPTUALES
La influencia del modelo conceptual en el producto resultante, aunque sólo sea

una fase inicial, es mucho mayor que la de otras fases del ciclo de vida, ya que la
detección y corrección de errores en las primeras etapas de cualquier proceso, y en
particular en el desarrollo del software, permite una mejora de la calidad y unos
menores costes de no conformidad. La atención al modelado es clave para el éxito
del proyecto.
Los modelos conceptuales pueden clasificarse en dos grandes grupos, los
tradicionales y los orientados a objetos:
Los modelos conceptuales tradicionales, como el Entidad-Relación (ER),
desarrollado en 1976 por Chen, y modificado posteriormente por otros autores,
todavía pueden describir fácilmente los requisitos de datos de un Sistema de
Información con independencia del criterio de la gestión y organización de los
datos.
Los modelos conceptuales orientados a objetos representan, además de los
datos, el comportamiento y funcionalidad del Sistema de Información, mediante
diagramas de clases, de actividad, de transición de estados, etc.
1.2. Calidad de los modelos conceptuales
Como siempre que se habla de calidad, hay que distinguir entre la calidad del
producto y la calidad del proceso realizado para conseguirlo. En este caso, la
calidad del producto se relaciona con las características del modelo conceptual y la
calidad del proceso con la manera en que se desarrollan los modelos conceptuales.
Algunos autores, como Batíni y Gregori entre otros, identifican la calidad de
los modelos con una lista de las propiedades ideales que deben tener los modelos
de datos (tabla 5.1). Estas listas pueden servir para mejorar la calidad de los
modelos, pero, en general, no son estructuradas, las definiciones no son precisas,
solapándose entre sí, presentan objetivos no realistas, presuponen la existencia de
diseño/implementación y otros defectos.
I Batini et al. (1992) expresividad, autoexplicación,

extensibilidad y normalidad
Corrección conceptual, compleción
conceptual, corrección sintáctica,
Reingruber M. y Gregory W. (1994)
compleción sintáctica, conocimiento de
la empresa.
1 Boman et a1 (1997)
Facilidad de compresión, corrección
semántica, estabilidad, compleción
conceptual.
Tabla 5.1. Calidad y sus propiedades según autores.

Por ello, otros autores, como Moody, Kesh, Piattini, etc., estudian la calidad
definiendo marcos de referencia para estructurar y organizar los conceptos claves y
las características en el modelado conceptual de los datos. En general, estos
marcos, al definir sólo propiedades deseables y carecer de medidas cuantitativas,
no permiten medir eficazmente la calidad del producto obtenido.
Para evitar los sesgos en el proceso de evaluación de la calidad, ~ o o d ~ ~
propuso en 1998 que era necesario contar con medidas objetivas y cuantitativas
para evaluar la calidad de los modelos conceptuales.
En los siguientes apartados se presentan algunas de las propuestas que sobre
métricas de calidad de los modelos conceptuales han aparecido en los últimos años.
2.1. Métricas de Kesh
El profesor S. Kesh publicó, en 1995~,el método que había desarrollado para el

aseguramiento de la calidad del modelo Entidad-Relación. Este método se basa en
que la calidad en estos modelos de datos se determina por dos tipos de
componentes: los ontológicos y los de comportamiento.
El método se compone de tres pasos:
1" Cálculo del valor de cada uno de los componentes ontológicos. Se calcula
individualmente el valor de los componentes estructurales (las relaciones entre los
elementos que forman el modelo: adecuación al problema: 01, validez, 02,
consistencia, 03, y concisión, 04) y de los componentes de contenido (los atributos
de las entidades: completitud, os, cohesión, 06, y validez, 07).
2" Cálculo de los valores de los componentes de comportamiento. Este cálculo
se hace a partir de los valores de los componentes ontológicos relevantes para cada
uno de los componentes de comportamiento. Los componentes de comportamiento
a tener en cuenta son: facilidad de uso desde el punto de vista del usuario, S I ,
usabilidad desde el punto de vista del diseñador, s2, facilidad de mantenimiento, s3,
precisión, s4 y rendimiento, SS.
3" Cálculo de la calidad del modelo Esta cálculo se hace a partir de los valores
de los componentes de comportamiento de acuerdo con la fórmula:
' D. Moody, G. Shanks y P. Darke. Improving the Quality ofEntiQ Relatioship Models-Experience in Research
and Practice. Proceeding of 17'~.Intemational Conference on Conceptual Modelling. Singapur, 1998.
S. Kesh. Evaluating the quality ofentity relationship models. Information and Software Technology,vol. 37 no
12. 1995.
156 MÉTRICAS PARA MODELOS CONCEPTUALES
siendo wi los pesos de los factores de comportamiento y si los valores de dichos

factores. Los pesos se determinan por la organización en función de la importancia
que tengan para la misma.
Las fórmulas para el cálculo de las si son las siguientes:
Los valores de los factores ontológicos son, en algunos casos, estimados por
los usuarios y, en otros, calculados mediante fórmulas ad hoc. Los procedimientos
son los siguientes:
Adecuación del modelo al problema (o,). Valor entre 1 y 5, determinado

mediante entrevista con los usuarios.
Validez del modelo (oZ).Valor entre 1 y 5, obtenido mediante entrevistas a un
equipo técnico que no está involucrado en el proyecto.
Consistencia del modelo (oj). Se calcula mediante la fórmula
estando DI basado en el ratio número de inconsistencias/4n, siendo n el número de

relaciones en el modelo (4n representa el número de implicaciones).
Concisión del modelo (o4) Si un modelo ER tiene n entidades, el número
mínimo de relaciones es (n-1). Un modelo ER con (n-1) entidades se le atribuye un
04 de 5. El valor O se atribuye al peor de los casos, cuando todas las entidades están
relacionadas entre sí. En los demás casos, el valor (entre O y 5) se obtiene mediante
una fórmula específica.
Completitud de2 contenido (o5). Se compara el modelo ER con la lista de
consultas e informes que se desean obtener de la base de datos y por cada fallo que
se observe se resta de 5 una cantidad proporcionada a la importancia de la falta.
Cohesión del contenido (06). La cohesión para cada entidad es el tamaño del
identificador primario. Si este está formado por un solo atributo, la cohesión es
máxima y, por lo tanto, o6 es 5. Al contrario, si el identificador primario está
formado por todos los atributos de la entidad. La cohesión es mínima y o6 vale O.

Para los demás casos se utilizan fórmulas específicas.
Validez del contenido (0,) Si todos los atributos para todas las entidades son
válidos 07 vale 5. Si todos los atributos se consideran inválidos. Se le atribuye a 07
el valor O. En los demás casos se aplica la fórmula
siendo ni el número de entidades inválidas y n, el número de atributos de la

entidad.
Como el modelo está poco experimentado, es necesario mucha interacción
entre los diseñadores y los usuarios para su retroalimentación. El propio Kesh
considera que el valor de Q no es una estimación precisa, sino un indicador de la
calidad del modelo ER y que, por consiguiente, habría que seguir trabajando sobre
el modelo.
En resumen, el modelo de Kesh se aplica a modelos ER, tiene un enfoque
ontológico y de componentes, comprende métricas tanto objetivas como subjetivas,
no ha sido validado ni teóricamente ni empíricamente y no existen herramientas
matemáticas.
2.2. Métricas de Moody
En 1998, ~ o o d ~ \ r e s e n t óun conjunto de métricas, algunas objetivas y otras

subjetivas, para evaluar algunos factores de calidad de los modelos de datos. Estas
métricas son, para los diferentes factores de calidad:
Compleción
- Número de elementos del modelo de datos que no corresponden con los

requisitos del usuario.
- Número de elementos del modelo de datos que corresponden con los
requisitos del usuario, pero definidos incorrectamente.
- Número de requisitos del usuario no representados en el modelo.
- Número de inconsistencias con el modelo de procesos.
Integridad
- Número de restricciones de integridad incluidas en el modelo que no

corresponden a políticas de negocio.
- Número de reglas del negocio que no se cumplen por el modelo de datos.
5
D. Moody. Metrics for evaluating the quality of entity relationship models. Proceedings of
the 1 7 ' ~International Conference on Conceptual Modelling. Singapur, 1998.
Flexibilidad
- Costes estimados de los cambios.

- Importancia estratégica de los cambios.
- Número de elementos del modelo que en el fututo estarán sometidos a
cambios.
Corrección
- Número de violaciones a las formas normales.

- Número de violaciones a las convenciones de modelos de datos.
- Número de instancias de redundancias en el modelo.
Simplicidad
- Número de entidades.
- Número de entidades y relaciones.
- Número de constructores.
Integración
- Número de conflictos con los sistemas existentes.

- Número de conflictos con el modelo de datos corporativo.
- Valoración de los representantes de todas las áreas del negocio.
Implementabilidad
- Valoración de riesgo técnico.

- Valoración de riesgo de planificación.
- Estimación del coste del desarrollo.
- Número de elementos físicos del modelo de datos.
Comprensibilidad
- Valoración de los usuarios sobre la comprensibilidad del modelo.

- Capacidad de los usuarios de interpretar el modelo correctamente.
- Valoración de los desarrolladores sobre la comprensibilidad del modelo.
Moody propuso que investigadores y profesionales trabajen conjuntamente

para demostrar la validez de estas métricas.
El método de Moody no ha sido validado de teórica ni prácticamente, no aporta
herramientas, tiene medidas objetivas y estimaciones subjetivas, y sólo tiene en
cuenta algunos factores de calidad para los modelos ER
2.3. Métricas de Piattini
Un grupo de investigadores coordinados por piattini6 trabajó en la medida de la

facilidad de mantenimiento de los modelos ER. Es evidente que esta medida sólo
puede hacerse cuando el producto está terminado o próximo a finalizar, ya que la
facilidad de mantenimiento es un atributo externo de la calidad. Para evitar este
inconveniente se predice la facilidad de mantenimiento mediante la medida de un
atributo interno (la complejidad estructural del modelo ER), que influye
fuertemente en el mantenimiento de la base de datos que se implementa. A su vez,
la complejidad estructural depende de sus elementos como entidades, relaciones,
atributos, etc. El conjunto de medidas propuesto es el siguiente:
Número total de entidades en el modelo ER.

Número total de atributos (simples, compuestos y multivaluados)
en el modelo, tanto en las relaciones como en las entidades.
NDA Número total de atributos derivados en el modelo.
NCA Número total de atributos compuestos en el modelo.
NMVA Número total de atributos multivaluados en el modelo.
NNR Número total de relaciones comunes en el modelo.
NM:NR Número total de relaciones N:M en el modelo.
NI: NR Número total de relaciones I:N e 1:I en el modelo.
NbinaryR Número total de relaciones binarias en el modelo.
NN AryR.
De ellas, son métricas de tamaño las NE, NA, NCA, NDA y NMVA, y de
complejidad el resto.
Estas métricas del modelo ER son objetivas y han sido validadas teóricamente
por Genero, siguiendo la teoría de Zuse, y empíricamente mediante un caso de
estudio y dos experimentos controlados.
3 . MÉTRICAS PARA MODELOS CONCEPTUALES ORIENTADOS A

OBJETOS
3.1. Métricas de Brito e Abreu y Carapuqa
Brito y Carapuqa presentaron las métricas MOOD para medir algunos de los
principales mecanismos de los modelos orientados a objetos (encapsulamiento,
M. Paitiini, M. Genero y L. Jimenez. A metric-based aproach forpredicting conceptual data modes

maintainability. International Journal of Software Engineering and knowledge engineering. World Scientific
Publishing Company, 2001.
polimorfismo, herencia y paso de mensajes, etc.) para poder evaluar la
productividad del desarrollo y la calidad del producto.
Las métricas MOOD se definieron para aplicarlas a nivel de diagramas de
clases y se pueden utilizar en la fase de diseño. Las definiciones de las diferentes
métricas son:
MHF El Method Hiding Factor (factor de ocultamiento de los métodos)

se define como el cociente entre la suma de las invisibilidades de
todos los métodos definidos en todas las clases y el número total de
métodos definidos en el sistema. La invisibilidad de un método es
el porcentaje del total de clases desde las cuales el método es
invisible. El MHF es el ratio entre el número de métodos privados
y el número total de métodos, y sirve para medir la encapsulación.
AHF El Attribute Hiding Factor (factor de ocultamiento de los atributos)
se define como el cociente entre el número de invisibilidades de
todos los atributos definidos en todas las clases y el número total
de atributos definidos en el sistema. Se propone también como
medida de encapsulación.
MIF El Method Inheritance Factor (factor de herencia de los métodos)
es el cociente entre el número de métodos heredados en todas las
clases del sistema y el número total de métodos (heredados y
locales) en todas las clases. El MIF se utiliza como una medida de
la herencia y, por tanto, sirve de medida de la reusabilidad.
AIF El Attribute Inheritance Factor (factor de herencia de los atributos)
está definido como el cociente entre el número de atributos
heredados en todas las clases del sistema y el número total de
atributos existentes (heredados y definidos localmente) en todas las
clases. Lo mismo que la anterior métrica expresa la capacidad de
reutilización del sistema.
El Polymorphim Factor (factor de polimorfismo) se define como el
ratio entre el número actual de situaciones diferentes posibles de
polimorfismo y el número máximo de posibles situaciones distintas
de polimorfismos para cada clase. El factor PF es una medida
indirecta de la asociación dinámica del sistema.
7
Las conclusiones de un estudio empírico fueron:
Al aumentar el valor de MHF o el del MIF, disminuye la densidad de defectos

y el esfuerzo para corregirlos.
F. Brito e Abreu y W. Melo. Evaluating the impact ofobject-oriented design on Sofrware Quality. Proceedings of
3rdlntemational Metric Symposium, 1996.
El valor ideal de la métrica AHF es el 100%.

El incremento de la reusabilidad por medio de la herencia dificulta la
comprensión y el mantenimiento de los sistemas.
La redefinición de modelos pueden reducir la complejidad y hacer el sistema
más comprensible y fácil de mantener.
En resumen, las métricas de Brito e Abreu y Carapuga se enfoca hacia las

características de los diagramas de clase, son medidas objetivas y han sido
validadas de forma teórica y parcialmente de forma empírica.
3.2. Métricas de Chindamber y Kemerer
En 1994, Chimdamber y ~ e m e r e r ' propusieron seis métricas para la

complejidad del diseño Orientado a Objeto, aunque no todas pueden aplicarse a
nivel conceptual, y además han sido muy criticadas por su ambigüedad e
imprecisión.
Las métricas que se considerarán son:
DIT La métrica Depth of Inheritance. Tree se define como la

profundidad del árbol de una clase (en los casos de herencia
múltiple es la máxima longitud desde el nodo hasta la raíz del
árbol). Se basa en que cuando más profunda está la clase en la
jerarquía, mayor número de operaciones puede heredar. Se propuso
como una medida de la complejidad de una clase, complejidad de
diseño y reusabilidad potencial.
NOC La métrica Number Of Children se define como el número de
subclases inmediatas subordinadas a una clase. Esta medida indica
cuántas subclases van a heredar las operaciones de la clase padre.
Esta métrica presenta medidas objetivas para la complejidad de las clases y han
sido validadas teóricamente por los autores al corroborar que satisfacen los
axiomas de weyuker9. La validación empírica fue realizada por Basil y sus
colaborado re^'^, que encontraron que la posibilidad de encontrar un fallo es
directamente proporcional al valor de DIT e inversamente al del NOC.
9.
Chindamber y C. Kemerer A metric suite for object oriented Desing. IEEE Transactions on Software
Engineering ,20 (6), 1994.
E. Weyuker. Evaluating software c o m p l e x i ~measures. IEEE Transaction Software Engineering, vol. 14, núm. 9,
1988.
l o V. Basili, L. Briand y W. Melo. A validation of Object-Oriented Desing Metrics as Quality Indicators. IEEE
Transactions on Software Engineering. Vol. 22, núm. 10, 1996.

3.3. Métricas de Lorenz y Kidd
Lorenz y ~ i d d " propusieron las métricas de diseño par medir las

características estáticas de un producto software. Se dividen en tres grupos:
métricas de tamaño, métricas de herencia y métricas de las características internas
de las clases.
De todas las propuestas, la que se pueden aplicar a un diseño de alto nivel son
las siguientes:
Métricas de tamaño
PIM La métrica Número de Métodos de Instancia Públicos es el número

total de métodos públicos de instancias (los que están disponibles
como servicios para otras clases). Se considera que mide la
cantidad de responsabilidad que tiene una clase.
NIM Se define el Número de Métodos de Instancia como la suma de
todos los métodos (públicos, protegidos y privados) de una clase.
Según los autores es una medida de la cantidad de colaboración
utilizada.
NIV El Número de Variables de Instancia se determina por el número
total de variables (privadas y protegidas) a nivel de instancia que
tiene una clase.
NCM El Número de Métodos de Clase es el número total de métodos a
nivel de clase.
NW El Número de Variables de Clase es el total de variables a nivel de
clase que tiene una clase.
Métricas de herencia
NMO El Número de Métodos Sobrecargados es el número total de

métodos sobrecargados en una subclase. Se propuso para medir la
calidad del uso de la herencia.
NMI El Número de Métodos Heredados se define como el número de
métodos que hereda una clase. También mide la calidad del uso de
la herencia.
NMA El Número de Métodos Añadidos es el número total de métodos
que se definen en una subclase. Igual que las anteriores mide la
calidad de uso de la herencia.
" M. Lorenz y J. Kidd. Object-oriented Sofh~are

metrics: apracticalguide. Ed. Prentice Hall. Englewood Cliffs,
New Jersey, 1994.
SIX El índice de EspeciJicacion para una clase se define como el

número de métodos sobrescritos multiplicado por el nivel de
anidamiento en la jerarquía y dividido entre el número total de
métodos. Mide el grado en que una subclase redefine el
comportamiento de una superclase.
Métricas de características internas de una clase
APPM El Promedio de Parámetros por Método se define como el

cociente entre el número total de parámetros por método y el
número total de métodos.
Se enfocan estas métricas a las características internas del diseño orientado a

objetos con medidas objetivas y una herramienta, la OOMetric, que sólo puede
aplicarse a código escrito en C++ y Smalltalk. No se ha validado teóricamente y
sólo empíricamente de forma parcial.
3.4. Métricas de Genero y al
enero'^ y otros
propusieron en el año 2000 un conjunto de métricas para la
medida de la complejidad estructural de los modelos de clase debido al uso de
relaciones UML. Se clasifican en: métricas a nivel de modelo de clases y métricas
a nivel de clase.
Métricas a nivel de modelo de clases
Nassoc La métrica Número de Asociaciones se define como el número

total de asociaciones dentro de un modelo de clases.
Nagg La métrica Número de Agrupaciones se define como el número de
relaciones de agregación dentro de un modelo de clases.
Ndep El Número de Dependencias es el número total de relaciones de
dependencia en un modelo de clases.
Ngen El Número de Generalizaciones se define como el número total de
relaciones de generalización dentro de un modelo de clases.
NgenH La métrica Número de Jerarquías de Generalización es el total de
jerarquías de generalización en un modelo de clases.
l 2 M- Genero, M. Piattini y C. Calero. An approach to evaluate the complexifv ofconceprual database models. 2"d
European Software Measurement Conference. Madrid. 2000.
M. Genero. Defining and validating metrics for conceptual models. Tesis doctoral. Universidad de Castilla-La
Mancha, 2002.
NaggH La métrica Número de Jerarquías de Agregación es el número total
de jerarquías de agregación dentro de un modelo de clases.
MmDIT La métrica Máximo DZT se define como el máximo de los valores
DIT obtenidos de cada clase del modelo de clases. El valor DIT es
la longitud de la ruta más larga desde la clase a la clase raíz de la
jerarquía de generalización.
MaxHAgg La métrica Máximo HAgg es el máximo de los valores Hagg de
cada clase del modelo de clases. El valor HAgg, dentro de la
jerarquía de agregación, es la longitud de la ruta más larga desde la
clase hasta las hojas.
Métricas a nivel de clases
NassosC El Número de Asociaciones por Clase es el número total de

asociaciones de una clase (con otras clases o con ella misma).
Hagg La Altura de una clase es la longitud de la ruta más larga desde la
clase a las hojas, dentro de una jerarquía de agregación.
NODP El Numero de Partes Directas de una clase es el número de Partes
Directas que contiene una clase que pertenece a una jerarquía de
agregación.
NP El Número de Partes es el número de clases "partes" (directas o
indirectas) de una clase "todo".
NW La métrica Número de Todos se define como el número de clases
"todos" (directas e indirectas) en una clase "parte".
Masg La métrica Agregación Múltiple es el número de clases "todo"
directas que tiene una clase en una jerarquía de agregación.
Ndepln El Número de Dependencias In se define como el número de clases
que depende de una clase dada.
NdepOut El Número de Dependencias Out es el número de clases de las que
depende la clase dada.
Esta métrica se enfoca hacia la complejidad estructural debida al uso de

relaciones y es objetiva. Se ha validado teóricamente usando los marcos de Briand,
Zuse y Poels y Dedene. También se han realizado diversos experimentos
controlados para validar empíricamente las métricas a nivel de modelos de clases.
Capítulo 6
EL ANÁLISIS DEL PUNTO FUNCIÓN

En 1968 sabíamos qué queriamos construir, pero no lo
hicimos. Ahora intentamos construir sobre arenas movedizas'.
El conocimiento, propuesta y estudio de medidas de atributos asociados a la

calidad de programas informáticos es uno de los objetivos principales de este texto.
El análisis del Punto Función (APF) es una técnica destinada a medir la
funcionalidad de una aplicación informática, entendida ésta como el conjunto de
funciones aportadas al usuario por el producto informático. Tal como veremos a lo
largo del capítulo esta técnica presenta severos problemas incompatibles con la
teoría de la medida [Fenton y Pfleeger, 19971 pero, al mismo tiempo es utilizada
por numerosas empresas y organizaciones para la contabilidad de sus programas y
la obtención de valiosas estadísticas. La medida del software es una disciplina que
se sustenta, como cualquier otra rama científica, sobre mejoras sucesivas. Hacer
uso de una herramienta que no es perfecta o matemáticamente correcta no es un
error en sí, siempre que conozcamos este hecho y sepamos las limitaciones que lo
acompañan.
1.1. La propuesta de Albrecht: ventajas e inconvenientes
La técnica del análisis del Punto Función fue ideada por Allan Albrecht,
especialista de la firma IBM, a finales de los años setenta. Diseñó este proceso de
I
Cliff Jones. Actas de las conferencias auspiciadas por la OTAN, Conference-London to analyze the Furure
Direcrion ofSofhyare. Abril 1993. Disponible en http:l/www.comlab.ox.ac.uWarchive. La traducción es nuestra.
Cliff Jones es profesor de la universidad de Manchester experto en metodologias y procesos de desarrollo del
software.
166 EL ANÁLISIS DEL PUNTO FUNCIÓN
medida para entornos bancarios sustentados en grandes bases de datos alojadas en

ordenadores tipo host bajo arquitectura SNA (IBM serie 390). En 1984 se publicó
el texto IBM CIS & A Guideline 313, AD/M Productivity Measurement and
Estimate Validation por la empresa IBM. Desde entonces hasta nuestro días se han
generado diversas versiones del APF promovidas por el International Function
Point Users Group (IFPUG) w e . La organización IFPUG, tal como se
le conoce habitualmente, es una sociedad sin ánimo de lucro cuyo fin es la
extensión y mejora del análisis del Punto Función. Su sede se encuentra en los
Estados Unidos de América. En este momento la última versión liberada del texto
Function Point Counting Practica1 Manual es la 4.1.1.
Otra fuente bibliográfica muy importante para el conocimiento y estudio del
APF es la propuesta que la Comunidad Europea concibió en el programa ESPRIT
(European Strategic Program for Research and Development). En 1988 este
programa ya se encontraba en su segunda edición. Existen numerosas versiones
posteriores de esta iniciativa. Uno de los proyectos acogido al programa ESPRIT
fue denominado METKIT (Metrics Educational ToolKIT). La filosofía que
auspició dicho programa fue proporcionar una educación efectiva y rigurosa en el
campo de la medida del software. El resultado fue, entre otros, la elaboración de
diferente material de auto-estudio destinado a promover el conocimiento y
utilización de la medida en el software. La técnica del análisis del Punto Función
fue uno de los objetivos del proyecto por lo que se elaboró un módulo en el que se
explicaba en detalle este método. El programa ESPRIT y las aportaciones del
IFPUG son dos fuentes muy interesantes de conocimiento y especialización
relacionadas con el APF (ver bibliografía).
El análisis del Punto Función es utilizado habitualmente como alternativa a la
medida del tamaño de una aplicación informática a las líneas de código. El APF es
independiente de la tecnología empleada en el desarrollo de los programas y
permite estimar el tamaño de la aplicación informática (en número de Puntos
Función) desde las primeras fases del proyecto. Este hecho nos posibilita el
conocer la magnitud de un programa y por tanto estimar el esfuerzo para su
realización. Ya indicamos en el capítulo 4 como el APF es propuesto como
herramienta dentro de la metodología MÉTRICA Versión 3, por lo que podemos
afirmar que el análisis del Punto Función se encuentra en plena expansión y es
utilizado en numerosas empresas de software obteniendo datos, en muchos casos
considerados estratégicos y secretos, por su relevancia dentro de la organización.
Sin embargo, tal como ya indicamos, existen problemas en la ejecución de esta
herramienta, e incluso en su concepción. Fenton y Pflegeer [Fenton y
Ptleeger,1997] hace un exhaustivo repaso a estos inconvenientes, alguno de los
más significativos son:
- Existe un grado de subjetividad en la medida alcanzada, en concreto en el

denominado factor tecnológico.
- Es necesario una muy detallada definición del proyecto si pretendemos

medir el mismo en las primeras etapas del desarrollo.
- Aparecen problemas e ineficacia de la medida al depender de la tecnología
utilizada. El APF no es totalmente independiente del sistema de análisis o
del método de diseño utilizado aunque supone una mejora frente al uso de
líneas de código, por ejemplo.
- Aparecen problemas cuando se utiliza el APF en aplicaciones de carácter
científico o aplicaciones en tiempo real.
- Existen problemas con la teoría de la medida al mezclar en una misma
medida diferentes escalas de forma inconsistente.
Nuestra experiencia con el uso del APF nos indica que la medida alcanzada al
utilizar este método depende de forma dramática de la experiencia del técnico que
evalúa la aplicación, más aún, la medida de una aplicación, realizada por un mismo
técnico varía sustancialmente si ésta es ejecutada cuando la aplicación posee un
nivel de detalle distinto en su documentación. Una aplicación correctamente
documentada implica una mejor y más fácil medida que otra aplicación con
deficiencias en su documentación. El análisis del Punto Función requiere un nivel
de disciplina elevado e incluso procesos de retroalimentación que disminuyen
considerablemente la dispersión de los datos obtenidos. Conocer los problemas
asociados a esta herramienta de medida nos permite minimizar los errores.
Proponemos el uso del APF combinadas con estrategias de revisiones peer to peer.
Uno de los resultados inmediatos de adoptar este tipo de revisiones es la obtención
de'datos más objetivos. Generalmente la información acumulada por una empresa
u organización en la medida de Puntos Función alimenta bases de datos de carácter
corporativo que son utilizadas como repositorios de información que permiten
mejorar los niveles de exactitud en las previsiones de nuevos proyectos. Es muy
habitual el uso de este tipo de estrategias para cuantificar el esfuerzo a realizar para
la ejecución de un nuevo proyecto. Los datos tienen difícil utilidad en otras
empresas pero son sumamente útiles si la organización que acomete este trabajo
insiste en el uso de esta medida y acumula datos históricos.
El análisis del Punto Función es muy utilizado en ecuaciones, como la densidad
de defectos, al sustituir las líneas de código por el número de Puntos Función en la
cuantificación del tamaño de la aplicación informática.
Número de defectos descubiertos en el programa

Ecuación 6.1
Tamaño del programa
168 EL ANÁLISIS DE L PLINTO F L I N C I ~ N
Según la ecuación 6.1 las unidades propias de la densidad de defectos son el

número de defectos por número de Puntos Función del programa.
2. EL ANÁLISIS DEL PUNTO FUNCIÓN PASO A PASO
El Análisis del Punto Función es un procedimiento secuencia1 que se compone

de un conjunto de pasos que hemos de ejecutar. A continuación explicamos en
detalle el procedimiento a realizar hasta la obtención del número de Puntos
Función de la aplicación considerada.
2.1. Determinar el tipo de conteo a realizar
El primer paso a ejecutar al utilizarse el APF es determinar qué tipo de

contabilidad se va a realizar. Ésta depende del estado en que se encuentre la
aplicación a medir y determinará las ecuaciones que se han de utilizar. El IFPUG
considera tres tipos de conteo de Puntos Función, según el estado de implantación
y desarrollo en que se encuentre la aplicación informática.
Provectos de desarrollo. El conteo de los Puntos Función de proyectos de

desarrollo mide las funciones proporcionadas al usuario final con la
primera instalación del software entregado, una vez el proyecto ha sido
completado.
Provectos de mejora. El conteo de los Puntos Función de proyectos de
mejora mide las modificaciones sobre las aplicaciones existentes que
añaden, cambian o eliminan funciones de usuario entregadas cuando el
proyecto fue completado.
Aplicación. El conteo de los Puntos Función de aplicaciones está asociado
con sistemas ya instalados. Esta contabilidad ofrece la medida de las
funciones que la aplicación proporciona al usuario final, en un momento
dado. Es actualizado cada vez que se completa un proyecto de mejora que
altera las funciones del sistema.
2.2. Identificar los límites en los que se aplicará el conteo de los Puntos
Función
Identificar los límites en los que se aplicará el conteo de los Puntos Función
significa determinar el borde entre el proyecto o aplicación que está siendo medido
y aplicaciones externas o el dominio del usuario.
El IFPUG fija una serie de reglas para su identificación.
El límite de la aplicación se determina en función del punto de vista del

usuario. Nos hemos de centrar en aquello que el usuario puede entender y
describir.
El límite entre aplicaciones afines se basa en las distintas funciones
apreciadas desde el punto de vista del usuario, no en consideraciones
tecnológicas.
Para proyectos de mejora, el límite inicial debe ajustarse a límites ya
establecidos para la aplicación o las aplicaciones que están siendo
modificadas.
Este paso requiere la colaboración del usuario final. Consideramos muy útil
para la ejecución de este segundo punto la realización de reuniones con el
responsable funcional o usuario responsable de la aplicación a medir. El punto de
vista por él aportado, unido a la información recabada del equipo de desarrollo,
sistemas e incluso gestor de la base de datos nos permite obtener el conocimiento
necesario para determinar adecuadamente los límites de la aplicación.
El análisis del Punto Función propone una serie de conceptos asociados a los
datos y a las transacciones. Los Tipos de Función de Datos representan la
funcionalidad proporcionada al usuario final que permite dar respuesta a los
requisitos asociados a los datos tanto internos como externos. Los Tipos de
Función de Datos son los Ficheros Lógicos Internos y los Ficheros de Interfaz
Externos. Cuantifiquemos cada uno de ellos.
2.3. Identificación de los Ficheros Lógicos Internos (FLI)
Un Fichero Lógico Interno (FLI) es un grupo de datos relacionados

lógicamente, o información de control, identificables para el usuario y mantenidos
dentro de los límites de la aplicación.
Para identificar los Ficheros Lógicos Internos presentes en el sistema, se han de
buscar datos o información de control que cumplan con la definición propuesta.
Los ficheros aspirantes son sometidos a un cuestionario. Sólo cuando todas las
preguntas propuestas tienen respuesta afirmativa podemos resolver que los datos
considerados son FLI.
Desde un punto de vista práctico el proceso de identificación de FLI se ha
resumido en una tabla dividida en tres columnas: ficheros aspirantes a ser
considerados FLI, preguntas tipo, respuestas y un breve comentario (ver tabla 6.2).
"Propuesta A" control es un gmpo de datos lógicos, o identificables
por el usuario, de forma que cumple con específicos
requisitos de éste?
Pregunta 2 ¿El grupo de datos es modificado, o Afirmativo/Negativo.

mantenido, dentro de los limites de la aplicación?
Pregunta 3 ¿El grupo de datos es modificado, o Afirmativo/Negativo.

mantenido, a través de un proceso elemental de la
Afirmativo/Negativo.
o Fichero de Interfaz Externo
Tabla 6.2. Identificación de los Ficheros Lógicos Internos.
2.4. Identificación de los Ficheros de Interfaz Externo (FIE)
Un Fichero de Interfaz Externo (FIE) es un grupo de datos relacionados

lógicamente, o información de control, identificables para el usuario, referidos por
la aplicación, pero mantenidos dentro de los límites de otra aplicación. Esto
significa que un Fichero de Interfaz Externo de una aplicación debe ser un Fichero
Lógico Interno para otro sistema.
Para identificar los Ficheros de Interfaz Externos se han de buscar datos o
información de control que cumplan con la definición propuesta. Los ficheros
aspirantes son sometidos a un cuestionario. Sólo cuando todas las preguntas
formuladas tienen respuesta afirmativa podemos resolver que los datos
considerados son FIE.
Desde un punto de vista meramente práctico el proceso de identificación de FIE
se ha resumido en una tabla dividida en tres columnas: ficheros propuestos a ser
considerados FIE, preguntas tipo, respuestas y un breve comentario (ver tabla 6.3).
"Propuesta A" control cs un grupo Iúgicamente relacionado o Explicació~i

identificable por el usuario de forma que cumpla
con requisitos especificamente establecidos por
Pregunta 2 ¿El gmpo de datos es utilizado como AfirmativoMegativo.

referencia por la aplicación que está siendo
considerada y, además, es externo a la misma?
Pregunta 3 ¿El gmpo de datos no es mantenido AfimativoMegativo.

por la aplicación que está siendo medida?
Pregunta 4 ¿El gmpo de datos es considerado Afimativo/Negativo.

como un FLI, al menos por otra aplicación?
Pregunta 5 ¿El grupo de datos considerado no ha AfimativoMegativo.
Tabla 6.3. Identificación de los ficheros interfaz externos.
2.5. Clasificar la complejidad de los ficheros lógicos y determinar su

contribución
El número de ficheros lógicos y su complejidad relativa funcional determina la

contribución de los tipos de función de datos al conteo de los Puntos Función sin
ajustar.
La asignación de complejidades a FLI y FIE se basa en el número de Tipos de
Elementos de Datos (TED) y número de Tipos de Elementos de Registros (TER)
propios de los FLI y FIE contabilizados.
Un tipo de elemento de dato se define como un campo único, no recurrente y
reconocible para el usuario en un FLI o FIE.
Para determinar los TED existentes en los ficheros lógicos se aplican tres reglas:
Regla 1.
Contabilizar un TED por cada campo no recurrente, único y reconocible para el
usuario en un FLI o FIE.
Regla 2.
Contar un TED por cada campo en un FLI o FIE que existe porque el usuario
requiere que se mantenga una relación con otro FLI. Es lo que se denomina como
clave externa.
Regla 3.
Considerar las siguientes técnicas de implementación como un simple TED,
para el grupo de campos considerado.
- Campos que aparecen más de una vez en un FLI o FIE por razones
tecnológicas o técnicas de implementación.
- Campos repetidos que son idénticos en su formato y existen para permitir
múltiples ocurrencias de un dato.
Desde un punto de vista meramente práctico el proceso de identificación de

tipos de elementos de datos se ha resumido en una tabla (ver tabla 6.4) dividida en
cuatro columnas: campo de un FLI o FIE propuesto y reglas de conteo (tres
columnas).
Contabilizar un TED por ;Clave externa? Contabilizar

cada campo no recurrente, Contabilizar un implementaciones
n I O FIE
ln&o y reconocible para el TED por cada una físicas como
usuario en un FLI o FIE de ellas simples TED
Fichero " Pmeba A"
Campo "AA" SiMo SiMo SiMo
Campo " A B SiMo SiMo SíINo
Campo "AC" SiMo SiMo SíMo
...
Tabla 6.4. Complejidad de FLI y FIE, contabilidad de tipos de elementos de

datos.
Un Tipo de Elemento de Registro (TER) se define como un subgrupo de

elementos de datos reconocibles para el usuario dentro de un FLI o FIE.
Existen dos tipos de subgrupos:
- Opcional. Son aquellos que el usuario tiene la opción de utilizar uno o

ninguno de los subgrupos durante un proceso elemental que añade o crea
una instancia de datos.
- Obligatorio. Son aquellos que el usuario debe usar al menos uno de estos
subgrupos.
Las reglas a utilizar para identificar TER son dos:
Regla 1. Contar un TER por cada subgrupo opcional u obligatorio existente en

un FLI o FIE.
Regla 2. Si no existen subgrupos, contabilizar el FLI o FIE como un único
TER.
Desde un punto de vista práctico el proceso de identificación de tipos de

elementos de registros se ha resumido en una tabla dividida en dos columnas: FLI o
FIE propuesto, subgrupos bien obligatorio, bien opcional reconocido (ver tabla
6.5).
Tabla 6.5. Complejidad de FLI y FIE, contabilidad de tipos de elementos de

registros.
Para la ejecución de este punto es sumamente beneficioso concretar reuniones

con el coordinador de informática correspondiente o responsable funcional ya que
nos permite identificar los subgrupos de datos en cada fichero lógico reconocido.
Insistimos en que el punto de vista del usuario es fundamental en esta herramienta
por lo que su colaboración es imprescindible.
Una vez conocidos los tipos de elementos de datos y los tipos de elementos de
registros propios de cada fichero lógico podemos establecer el nivel de
complejidad apoyándonos en la tabla 6.6.
Tabla 6.6. Asignación de complejidad según TER y TED.
Este proceso permite medir la complejidad según una escala ordinal de tres
puntos.
174 EL ANALISIS DEL PUNTO FUNCIÓN
2.6. Conteo de los tipos de función asociado a transacciones
Los tipos de función asociados a transacciones representan la funcionalidad

proporcionada al usuario para el procesamiento de datos por una aplicación. Estos
tipos de función se dividen en: Salidas Externas (SE), Entradas Externas (EE) y
Cuestiones Externas (CE).
2.6. l . Identificación de Entradas Externas
Una Entrada Externa (EE) procesa datos o información de control que

provienen de fuera de los límites de la aplicación. La Entrada Externa es en sí
misma un proceso elemental.
Para identificar las Entradas Externas se han de buscar datos o información de
control que se encuentren dentro de la definición propuesta. Las transacciones
aspirantes se someten, entonces, a un cuestionario. Sólo cuando todas las preguntas
tienen respuesta afirmativa podemos resolver que las transacciones estudiadas son
EE.
Desde un punto de vista práctico la identificación de EE se ha resumido en una
tabla dividida en tres columnas: procesos propuestos, preguntas tipo, respuestas y
un breve comentario (ver tablas 6.7 y 6.8). En este caso (identificación de Entradas
Externas) se ha de discriminar entre tratamiento de datos y de información de
control.
LA CALIDAD DEL SOFTWARE Y SU MEDiDA 175
Regla 2. Los datos en un FLI son Afirmativo/Negativo

mantenidos a través de un proceso
elemental de la aplicación.
Regla 3. El proceso es la unidad de Afirmativo/Negativo

actividad menor que es significativa
para el usuario final.
Regla 4. El proceso es auto-contenido2 AfirmativotNegativo

y deja la aplicación que está siendo
medida en un estado consistente.
Regla 5. Para el proceso identificado Afirmativo/Negativo

una de las dos siguientes reglas debe ser
- Para el sistema el
proceso lógico es único
en relación a otras
Entradas Externas.
- Para el sistema los
elementos de datos
identificados son
diferentes en relación a
otras Entradas Externas.
Tabla 6.7. Identificación de Entradas Externas para datos.
* El concepto autocontenido proviene del entorno en el que se ideó el método APF y es equivalente al de
transacción, entendida ésta como interacción con el sistema que permite asegurar la coherencia del sistema
después de la finalización correcta o no de dicha transacción.
Afirmativo/Negativo
recibida desde fuera de la aplicación.
Regla 2. La información es especificada Afirmativo/Negativo

por el usuario para asegurar el
cumplimiento con los requisitos de
función del sistema.
Regla 3. Para identificar los procesos, Afirmativo/Negativo

una de las dos siguientes reglas debe ser
- Para el sistema, el
procesamiento lógico es
único en relación con otras
Entradas Externas.
- Para el sistema, los
elementos de datos
identificados son diferentes
en relación con otras
Tabla 6.8. Identificación de Entradas Externas para información de control.
2.6.2. Identificación de Salidas Externas
Una salida externa (SE) se define como un proceso elemental que genera datos
o información de control y son enviados fuera de los límites de la aplicación.
Para identificar las Salidas Externas se han de buscar procesos elementales que
se encuentren dentro de la definición propuesta. Las transacciones aspirantes se
someten, entonces, a un cuestionario. Sólo cuando todas las preguntas tienen
respuesta afirmativa podemos resolver que las transacciones estudiadas son SE.
Desde un punto de vista práctico la identificación de SE ha resumido en una
tabla dividida en tres columnas: procesos propuestos, preguntas tipo, respuestas y
un breve comentario (ver tabla 6.9).
178 EL ANALISIS DEL PUNTO FUNCION
límites del sistema.
Regla 2 Un resultado sale de los límites de AfirmativoMegativo

la aplicación.
Regla 3 Datos son recuperados. AfirmativoMegativo
Regla 4 Los datos obtenidos no poseen AfirmativoiNegativo

datos derivados
I
Regla 5 La EIS unida forma un proceso AfirmativoMegativo
que es la menor unidad de actividad que es
significativa para el usuario final
Regla 6 El proceso elemental es AfirmativoNegativo

autocontenido y deja a la aplicación en un
estado consistente.
Regla 7 El proceso no actualiza FLI

ArmativoMegativo
AfirmativoMegativo
l
Regla 8 Para identificar el proceso una de
estas dos reglas debe ser aplicada:
- Para el sistema el
procesamiento lógico en la
entrada o salida es Único
desde el punto de vista de
otras Cuestiones Externas.
- Para el sistema los
elementos de datos en la
entrada o salida son
diferentes a otras Cuestiones
?
Externas en la aplicación.
Tabla 6.10. Identificación de Cuestiones Externas (CE).

2.6.4. Clasificar la complejidad de las transacciones identificadas y su

contribución
Una vez identificadas las transacciones se ha de estudiar su complejidad. Esta

característica, unida al número transacciones contabilizadas, determinarán la
contribución al conteo de los Puntos Función sin ajuste.
En el caso de Entradas Externas la complejidad se sustenta en el número de
Tipos de Ficheros Referidos (TFR) y los Tipos de Elementos de Datos (TED). Un
TFR se define como un FLI leído o mantenido por un tipo de función o un FIE
leído por un tipo de función. Un Tipo de Elementos de Datos es un campo no
recurrente reconocible para el usuario, mantenido en FLI por una EE.
Para contabilizar el número de TFR se han de aplicar las siguientes reglas:
Regla 1. Contar un TFR por cada FLI mantenido.

Repla 2. Contar un TFR por cada FLI ó FIE leido durante el procesamiento de
una EE.
Regla 3. Contar una sola vez cada FLI leído y mantenido por una EE.
Desde un punto de vista práctico la identificación de TFR se ha resumido en la

tabla 6.1 1.
Externa imente mantenido
Tabla 6.11. Complejidad de EE. Contabilidad de TFR.
Las reglas para contabilizar un TED son:
Repla 1. Contar un TED por cada campo no recurrente y reconocible para el

usuario mantenido sobre un FLI por una EE.
Regla 2. Contar un TED por cada campo, no aportado por el usuario, pero que
es mantenido a través de una EE sobre un FLX.
Regla 3. Considerar las siguientes técnicas de implementación para un grupo de

campos como un único TED:
- Campo lógico almacenado físicamente en muchos campos pero requerido por
el usuario como una pieza simple de información.
- Campos que aparecen más de una vez en un FLI por causas técnicas o de
implementación.
- Campos que indican un error ocurrido durante el proceso, o confirman que el
proceso ha concluido exitosamente.
- Contar un simple TED para la capacidad de especificar la acción a ser
realizada por la EE.
Desde un punto de vista práctico la identificación de TFR se ha resumido en la
tabla 6.12.
'LI.
ei usuaric
recurren1
Tabla 6.12. Complejidad de EE. Contabilidad de TED.
En el caso de Salidas Externas la complejidad se basa en el número de Tipos de

Ficheros Referidos (TFR) y del número de Tipos de Elementos de Datos (TED).
Un TFR se define como un fichero leído cuando una entrada externa es procesada.
Un TED se define como un campo no recurrente reconocible por el usuario que
aparece en una SE.
La regla para contabilizar TFR es:
Regla 1. Contar un TFR por cada FLI o FIE leído durante el procesamiento de
una salida externa.
Desde un punto de vista meramente práctico el conocimiento de la complejidad

asociada a los TFR para las Salidas Externas se ha resumido en una tabla (ver tabla
6.13).
coi
S
pro
Fichero "A"
Fichero "B"
Tabla 6.13. Complejidad asociada a SE., contabilidad de TFR.
Las reglas para contabilizar TED son:
Regla 1. Contar un TED por cada campo no recurrente y reconocible para el

usuario que aparece en una SE.
Regla 2. No contar literales como TED (cabeceras de listados, títulos.. .).
Regla 3. No considerar variables de paginación o marcas generadas por el
sistema.
Regla 4. Considerar las siguientes técnicas de implementación física como un
único TED.
Regla 4.1. Un campo lógico almacenado físicamente en múltiples campos
cuando es requerido por el usuario como una pieza única de información.
Regla 4.2. Cada impresión de etiqueta o cada impresión de equivalente
numérico en una salida gráfica.
Regla 4.3. Información de texto que puede ser una simple palabra, frase o
sentencia.
Desde un punto de vista práctico el conocimiento de la complejidad asociada a

los TED para las Salidas Externas se ha resumido en una tabla (ver tabla 6.14).
iReco
el usu
gas Externia
recuri
Tabla 6.14. Complejidad asociada a SE, contabilidad de TED.

La complejidad de las Cuestiones Externas se basa en el número de Tipo de
Ficheros Referidos (TFR) y Tipos de Elementos de Datos (TED) para cada
componente (entrada y salida) de la CE. Se ha de considerar la complejidad mayor
de los dos componentes (entrada y salida) y trasladar este valor al conteo de los
Puntos Función.
Un TFR se define como un fichero leído al procesar una Cuestión Externas. Un
TED se define como un campo no recurrente y reconocible para el usuario que
aparece en una Cuestión Externas.
Las reglas para el conteo de TFR en el caso de Cuestiones Externas son:
Para la Entrada.
Regla 1. Considerar un TFR por cada FLI o FIE leído durante el procesamiento
de la Cuestión Externa.
Para la Salida.
Reala 1. Contar un TFR por FLI o FIE leído durante el procesamiento de

Cuestiones Externas.
fiesde un punto de vista práctico el conocimiento de la complejidad asociada a
los TFR para las Cuestiones Externas se ha resumido en una tabla (ver tabla 6.15).
rternas
Tabla 6.15. Complejidad asociada a CE, contabilidad de TFR.
Las reglas para contabilizar los Tipos de Elemento de Datos son:
Para la entrada
Regla 1. Contar un TED por cada campo no recurrente y reconocible para el

usuario que aparece en la entrada de la Cuestión Externas.
Regla 2. Contar un TED por cada campo que especifica el criterio de selección
de los datos.
Regla 3. Considerar las siguientes técnicas de implementación para un grupo de
campos como un único TED.
y no vr
P; física?
I como m Considerair un TED
N ado
Tabla 6.17. Complejidad asociada a CE, contabilidad de TED
Una vez identificados para cada transacción los tipos de ficheros referidos y
tipos de elementos de datos podemos establecer el nivel de complejidad. Para ello
se hace uso de las siguientes tablas.
Tabla 6.18. Asignación de complejidad para Entradas Externas
Tabla 6.19. Asignación de complejidad para Salidas Externas
Conocidos los niveles de complejidad (alto, medio o alto) de cada transacción

se asigna, según la tabla 6.20, un peso diferente a cada uno de éstos.
Complejidad baja
Complejidad media
Tabla 6.20. Contribución al conteo según complejidad.
2.6.5. Cálculo del valor de los Puntos Función sin ajustar
Con la información obtenida en los pasos anteriores la mecánica a seguir en el

cálculo de los Puntos Función sin ajustar es:
1. Contar el número de ficheros y transacciones identificados agrupando

éstos según su complejidad.
2. Multiplicar el número de ficheros y transacciones ya agrupados según su
complejidad por el factor correspondiente.
3. Sumar los 15 valores obtenidos.
La ecuación para determinar los Puntos Función sin ajustar es:
15
UFC = (Número de items de var iedad i) x ( p e s q) Ecuación 6.7
i=I
Desde un punto de vista práctico el cálculo de los Puntos Función sin ajustar se
determina obteniendo tablas tales como 6.21 y 6.22. Los datos incluidos en las
tablas son a título de ejemplo.
186 EL ANALISIS DEL PUNTO FWCIÓN
po de
nción inción
Tabla 6.21. Cálculo de los Puntos Función sin ajustar para Ficheros Lógicos.
. --- .
Función idos
X3 = o
Medio X4= O
X6= 36
Medio X5= O
X7= 42
X3= 27
1 Medio X4= 4
X6= O
Tabla 6.22.Ejemplo del cálculo de los Puntos Función sin ajustar para
transacciones.
En este caso los Puntos Función sin ajustar se determinarían sumando los
factores indicados en la última columna de las tablas asociadas a transacciones y
ficheros:
UFC = 15 + 46 + 36 + 42 +31 =170 Ecuación 6.8
2.6.6. Cálculo del valor del factor de ajuste
El cálculo del Valor del Factor de Ajuste (VAF) se basa en la cuantificación de

catorce Características Generales del Sistema (GSC), permitiendo establecer la
funcionalidad general de la aplicación medida. La cuantificación es posible al
establecerse el grado de influencia de cada factor y hacerla coincidir con una escala
que varía desde el valor "5" para una gran influencia, hasta el valor "0" que implica
nula influencia.
El procedimiento seguido para calcular el valor del factor de ajuste es:
a. Evaluar las 14 Características Generales del Sistema sobre una escala de valor
mínimo "0" y valor máximo "5". Esta estimación se ha de basar en la
influencia de cada una de las 14 características sobre el sisterría medido.
b. Determinar el grado de influencia total (TID), sumando el grado de influencia
de cada una de las características evaluadas.
c. Aplicar la ecuación :
VAF = ( TDI * 0.01 ) + 0.65 Ecuación 6.9
Las características del sistema a considerar son:
1. Comunicaciones.
2. Procesamiento distribuido de datos.
3. Rendimiento.
4. Uso elevado de la configuración.
5. Índice de transacciones.
6. Entrada de datos en-línea.
7. Eficiencia y usuario final.
8. Actualización en-línea.
9. Procesamiento complejo.
10. Reutilización.
1 1. Fácil instalación.
12. Fácil operación.
13. Múltiples sitios.
14. Facilidad de cambio.
Los grados de influencia son:
a. No presente o sin influencia.

b. Influencia circunstancial.
c. Influencia moderada.
d. Influencia media.
e. Influencia significativa.
f. Influencia fiierte.
El cálculo del factor de ajuste es criticado por ser uno de los componentes más
subjetivos del Análisis del Punto Función.
2.6.7. Cálculo de los Puntos Función ajustados
Como indicamos en su momento podemos considerar tres tipos de cálculo

según el estado de implantación y desarrollo en que se encuentre la aplicación a
medir. Veamos cada uno de ellos y las ecuaciones asociadas a los mismos.
Cálculo del Punto Función Ajustado en el caso de Desarrollo de Proyectos.
Los componentes que intervienen en el cálculo de la funcionalidad son tres:
- La funcionalidad de la aplicación incluida en los requisitos del usuario para el

proyecto.
- La conversión de la funcionalidad incluida en los requisitos del usuario para el
proyecto.
- El valor del factor de ajuste.
Considerando los factores antes definidos podemos establecer:
DFP = ( UFP + CFP ) * VAF Ecuación 6.10
Donde:
DFP es el valor de los Puntos Función del desarrollo del proyecto.

UFP es el valor de los Puntos Función sin ajustar.
CFP es el valor de los Puntos Función añadidos por la conversión de Punto

Función sin ajustar.
VAF es el valor del factor de ajuste.
Cálculo de los Puntos Función en el caso de meiora de proyectos.
Los componentes que intervienen en este caso son tres:
- Funcionalidad de la aplicación incluida en los requisitos del usuario para el

proyecto.
- Conversión de funcionalidad.
- Valor del factor de ajuste.
En este caso la fórmula utilizada es:
EFP = [(ADD + CHGA + CFP) * VAFA] + ( DEL * VAFB) Ecuación 6.11
donde:
EFP son los Puntos Función contabilizados en la mejora del proyecto.

ADD son los Puntos Función sin ajustar de aquellas funciones que fueron
añadidas por la mejora del proyecto.
CHGA son los Puntos Función de aquellas funciones que fueron modificadas
por la mejora del proyecto. Este número refleja las funciones tras las
modificaciones.
CFP son los Puntos Función añadidos por la conversión.
VAFA: es el valor del factor de ajuste para la aplicación después de la mejora.
DEL es el Punto Función sin ajustar de aquellas funciones que fueron borradas
por la mejora del proyecto.
VAFB es el valor del factor de ajuste de la aplicación antes del proyecto de
mejora.
Cálculo de los Punto Función para el caso de aplicaciones.
En este punto se establecen las fórmulas para el cálculo de los Puntos Función
para aplicaciones. Existen dos variantes a esta fórmula.
Fórmula para establecer los Puntos Función iniciales de la aplicación.
Fórmula para restablecer los Puntos Función para una aplicación tras una
mejora que implica un cambio en la funcionalidad de ésta.
La fórmula que establece el valor inicial de los Puntos Función para una
aplicación es:
AFP = ADD * VAF Ecuación 6.12
donde:
APF son los Puntos Función para el estado inicial de la aplicación.

ADD son los Puntos Función sin ajustar de aquellas funciones que fueron
instaladas por el desarrollo del proyecto.
VFA es el valor del factor de ajuste.
La fórmula se vuelve a calcular una vez un proyecto de mejora haya modificado

la funcionalidad de la aplicación. La fórmula utilizada en este caso es:
APF = [ (UFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA Ecuación 6.13
Donde:
AFP son los Puntos de Función ajustados.

UFPB son los Puntos de Función no ajustados antes de la mejora del proyecto.
ADD son los Puntos Función de aquellas funciones añadidas por la mejora del
proyecto.
CHGA son los Puntos Función sin ajustar de aquellas funciones modificadas
por la mejora del proyecto antes de que los cambios ser produjeran.
CHGB son los Puntos Función sin ajustar de aquellas funciones modificadas
por la mejora del proyecto después de que los cambios ser produjeran.
DEL son los Puntos Función de aquellas funciones que han sido borradas
durante la mejora del proyecto.
VAFA valor del factor de ajuste tras la mejora del proyecto.
El International Function Point Users Group posee amplia bibliografía con

numerosos ejemplos prácticos que colaboran en gran medida en el conocimiento de
este tipo de medidas.
A modo de resumen y como guía práctica aportamos el siguiente cuadro:
Determinar tipo de Identificar límites Identificar FLI
Identificar FIE
Leyenda
Se aconseja participación del responsable
funcional.
Requiere cumplimentar formulario
Figura 6.1. Esquema aplicación Análisis Puntos Función.

3. MÁS ALLÁ DEL ANÁLISIS DEL PUNTO FUNCIÓN TRADICIONAL
El Análisis del Punto Función posee ventajas e inconvenientes que ya hemos

indicado al principio de este capítulo, sin embargo, es incuestionable la extensión
de su uso en numerosos países de todo el mundo, especialmente en Estados
Unidos, Canadá y Reino Unido, y su utilización habitual en empresas de desarrollo
como medida del tamaño de las aplicaciones informáticas.
Del conocimiento y utilización del APF han surgido diferentes modificaciones o
variaciones de esta medida con objeto de mejorar su exactitud y permitir su
utilización en entornos distintos al origen histórico de la misma, recordemos:
grandes bases de datos que recibían gran cantidad de accesos bajo una tecnología
transaccional pura, entorno tecnológico propio de organizaciones como bancos u
organismos oficiales.
La aportación de Symons [Symons, 19881 se basa en la utilización de
"transacciones lógicas", consideradas éstas como procesos de entrada-salida a los
que, además, aplica ciertos pesos. El nombre de esta modificación del APF se
denomina Mark 2. Capers Jones [Jones, 20001 ha realizado diferentes estudios
sobre el Análisis del Punto Función, éstos han sido utilizado por otros autores para
promover mejoras y cambios en la medida, entre los que cabe destacar los Punto
Función 3D y los denominados Full Function Point.
Entre las novedades más interesantes cabe destacar la aportación del profesor
Francisco Sanchís de la Universidad de Oviedo. Su trabajo, presentado en el foro
sobre calidad e informática celebrado en Santiago de Cuba en el primer trimestre
del 2003, se basa en el estudio de la sensibilidad del Análisis del Punto Función
aportando interesantes modificaciones al método que lo mejoran.
El Análisis del Punto Función se encuentra en continua mejora y posee un
evidente dinamismo fruto de su utilización en las organizaciones.
Capítulo 7
LA NORMA ISODEC 9126
Y LA MEDIDA DE LA CALIDAD
La calidad permite dar confianza a los clientes y a los
proveedores, dar confianza interna y aprovechar la
experiencia intelectual.'
En este capítulo estudiaremos con detenimiento la norma ISOIIEC 9126, a la

vez que propondremos un procedimiento de medida de la calidad del software
basado en este modelo. La norma ISOIIEC 9126 tiene en los modelos de McCall y
Boehm dos antecesores que supusieron un gran impacto en la medida del software.
Finalizaremos el capítulo con un ejemplo práctico en el que aplicaremos los
conocimientos explicados en apartados anteriores.
La calidad de un programa informático es un atributo complejo, compuesto de

otros muchos atributos, incluso diferentes según el observador. El responsable de
sistemas de una organización considerará un programa de gran calidad si consume
poco recursos técnicos tales como servidores o líneas de comunicación y los utiliza
eficientemente, el usuario hará hincapié en las funciones del programa y en la
inexistencia de errores en tiempo de ejecución, el responsable de la cuenta de
resultados de la empresa que desarrolla la aplicación considerará que el programa
es bueno si se han obtenido unos ingresos adecuados al esfuerzo realizado. Como
vemos cada actor considera la calidad del software según su punto de vista, sus
expectativas y necesidades. Los modelos utilizados para la medida de la calidad del
'Juan Izquierdo. "La calidad del software asignatura pendiente en España". Computenvorld, 7-13 septiembre de
2001.
194 LA NORMA ISOIIEC 9126
software proponen la descomposición de este atributo en otros más simples y

medibles, al tiempo que establecen los requisitos de calidad. Con este
procedimiento no sólo podemos enfrentarnos a la medida de la calidad de forma
más simple y coherente, también nos ayudará a conocer el programa informático,
sus características de calidad. Cuando medimos un proceso o un producto
comenzamos a conocerlos. Conocer la calidad, los atributos que la integran, es un
factor vital para las empresas y organizaciones.
La descomposición jerárquica es una estrategia muy utilizada en diferentes
disciplinas científicas. La ingeniería del software la explota en beneficio del
conocimiento real de los atributos de calidad.
1.1. La descomposición jerárquica en árbol
Los modelos de calidad asumen en su mayoría el punto de vista del usuario,

considerando el software como un producto a evaluar. Partiendo de los
denominados factores de calidad entendidos como atributos de calidad (por lo
general se trata de atributos externos tales como la facilidad de uso o de
mantenimiento, aunque también se han considerados atributos internos como la
eficiencia), éstos se descomponen en otros de más bajo nivel denominados criterios
de calidad y que suelen ser atributos internos. Una vez alcanzado este nivel se
procede a una segunda descomposición, realizada de forma que los criterios de
calidad sean asociados a atributos que pueden ser medidos a través de las
denominadas métricas de calidad. Factores y criterios han de estar relacionados de
forma que la influencia entre ambos se establezca de forma clara. Modelos de este
tipo son los ideados por Boehm y McCall, el modelo MQ, LOQUM o la norma
IS09126, objeto de este capítulo. Todos estos modelos siguen la filosofía de
simplificación jerárquica en árbol.
La conexión entre atributos, métricas y factores de calidad no es un axioma de
aceptación general ni existe un asenso universal en esta materia por lo que el
modelo de calidad posee numerosas versiones. La experiencia es un factor
determinante en la ejecución de medidas y su relación última con la calidad del
software a través de los criterios y factores de calidad.
Llegados a este punto, y antes de continuar con el procedimiento de medida, es
importante destacar el uso que se hace habitualmente de los vocablos métrica y
medida. La medida de un atributo ha sido explicada en el capítulo 2 por lo que es
un término definido y claro. Sin embargo el uso de métrica se ha utilizado para
especificar muy diversas entidades. Medidas directas, indirectas, procedimientos de
medid?, atributos del programa informático, entre otros. Para evitar problemas y
ambigüedades optamos por considerar una métrica como una medida directa de un
atributo simple [Fenton y Pleeger, 19971. Como veremos más adelante las métricas
del software se combinarán para obtener la medida de la calidad.
Calidad del software
Factores de calidad
Criterios de calidad
Medidas del software
Figura 7.1. La medida de la calidad del software a través de la descomposición

jerárquica.
Se pueden considerar dos aproximaciones diferentes a la hora de implantar un

modelo de calidad [Kan, 20031. Por un lado podríamos realizar una aplicación
rígida de un modelo prefijado en el que los factores de calidad son aportados por el
modelo seleccionado. Por otro lado podemos considerar una aproximación en el
que el modelo de calidad se establece por acuerdo entre usuario e ingeniero de
software y, por tanto, los atributos de calidad son seleccionados por éstos, así como
la descomposición en factores y las correspondientes métricas de calidad. La
relación entre factores y criterios de calidad es establecida también por usuarios e
ingenieros de software aunque generalmente se escoge algún modelo existente en el
mercado al que se le suele incluir variaciones puntuales. Insistimos en la importancia de
la experiencia del responsable de la calidad del software y la relación que debe establecer
entre medidas a realizar y criterios de calidad.
1.2. Modelos de McCall y Boehm
Los modelos de McCall y Boehm son dos ejemplos clásicos de la utilización de

la descomposición jerárquica para la medida de la calidad. El modelo de McCall es
uno de los más antiguos y extendidos [McCall, 19771 y ha sido tomado como
ejemplo y referencia para otros modelos e iniciativas de medida de la calidad del
software.
Modelo de McCall
McCall presenta en su modelo tres puntos de vista de calidad (operación del

producto, revisión del producto y transición del producto), incluye 41 métricas
(entendida como medidas directas de los atributos, ver capítulo 2), 21 criterios de
calidad y 11 factores de calidad. Se ha incluido en este modelo un nivel más de
descomposición al considerar la calidad de uso o puntos de vista de la calidad. La
figura 7.2 nos muestra de forma gráfica la propuesta de McCall. La
descomposición, por tanto, se basa en tres ejes básicos sobre los que luego se
aplican descomposiciones sucesivas.
Punto de vista Factores

- Facilidad de uso.
- Integridad.
Operación del Producto - Corrección.
- Fiabilidad.
- Eficiencia.
- Facilidad de
mantenimiento.
Revisión del Producto
- Facilidad de prueba.
- Flexibilidad.
- Facilidad de reutilización.
Transición del Producto - Interoperabilidad.
- Movilidad.
Tabla 7.1. Factores del modelo de McCall.

Facilidad de mantenimiento Interoperabilidad

¿Puedo arreglarlo? ¿Puedo relacionarlo con otros sistemas?
Facilidad de prueba Movilidad
¿Puedo probarlo? ¿Puedo utilizarlo en otra máquina?
Flexibilidad Reutilización
¿Puedo modificarlo? ¿Puedo volver a utilizar parte del
Corrección
¿Hace el programa lo que quiero?
Fiabilidad
¿Lo hace de forma exacta todo el tiempo?
Eficiencia
¿Se ejecutará sobre el soporte físico de forma
óptima?
Facilidad de uso
i,Puedo utilizarlo?
Figura 7.2. Modelo clásico de calidad del software propuesto por McCall.
La operatoria para la obtención de un resultado numérico relacionado con uno

de los puntos de vista propuesto por McCall es descomponerlo hasta la obtención
de medidas cuya combinación preemitiría la cuantificación de la calidad. Debemos
determinar los factores asociados a la Operación, Transición o Revisión que
influyen en la calidad, éstos se encuentran identificados por el modelo, una vez
seleccionados los factores se han de obtener las medidas asociadas a cada criterio.
Para ello se hace uso de una lista de comprobación con objeto de conocer si se
aplica a los requisitos (R) al diseño (D) o a la implementación (1). La figura 7.3 nos
muestra alguna de las preguntas tipo de la lista de revisión utilizada para el criterio
de calidad "nivel de cumplimiento" dentro del factor de calidad "corrección".
Respuesta: S í N o
Preguntas
R D I
1 ¿Hay referencias ambiguas?
2 ¿Todas las funciones definidas son utilizadas?
(-1
Figura 7.3. Pregunta tipo de una lista de comprobación para criterios de calidad.
Las letras R, D, 1, indican si la lista de comprobación es aplicable a los

requisitos (R), al diseño (D) y10 la implementación (1). Se ha de responder SíNo a
cada pregunta de la lista para cada uno de los criterios.
McCall propone para cada criterio una fórmula de regresión del tipo:
Medida criterio = r, m , + r,m, + ... + rnmn Ecuación 7.1
Donde r, identifica los coeficientes de regresión y mj representa las distintas

métricas asociadas al criterio.
Es habitual normalizar el resultado de las medidas a valores entre O y 1
buscando la coherencia de los resultados.
Algunas medidas propuestas en el modelo son:
U Fiabilidad = 1 - ( número de erroreslnúmero de líneas de código)
o Facilidad de mantenimiento = 1 - 0,1 (número medio de días-hombre por

corrección)
o Movilidad = 1 - (esfuerzo para trasladarlesfuerzo para implementar)
U Flexibilidad = 1 - 0,05 (número medio de días-hombre por cambio)
Las medidas propuestas pueden ser modificadas según el criterio del técnico. Es
muy habitual el uso de la medida de la fiabilidad considerando el número de
errores por el tamaño de la aplicación contabilizados según el número de puntos
función. El nivel de subjetividad de la medida es uno de los problemas a resolver

por parte de la ingeniería del software. Todos deben medir lo mismo y de la misma
forma.
Modelo de Boehm
Independencia
Figura 7.4. Modelo de Boehm para la descomposición de la calidad del

software.
La figura2 7.4 representa el modelo de Boehm [Boehm et al., 19781

considerando los componentes de la calidad y sus relaciones. Este modelo, al igual
que el propuesto por McCall, es un modelo fijo sin posibilidad de ser modificado o
adaptado por el técnico o el usuario de la aplicación. Los criterios y factores son
determinados y fijos de forma que la medida de la calidad debe ajustarse a estas
definiciones y a las relaciones entre criterios y factores de calidad que el modelo
propone.
El modelo de Boehm junto con el de McCall representaron los primeros
intentos por cuantificar la calidad del software como producto a través de la
descomposición jerárquica en árbol.
2. LA NORMA ISOIIEC 9126
La norma ISOIIEC 9126, en su apéndice "C", llamado historia del trabajo,

reconoce la dificultad existente para comparar y entender la calidad del software
por parte de los usuarios/clientes, aún a pesar de los significativos intentos por
definir este concepto y conseguir valorarlo. McCall, Boehm son importantes
estudiosos de la materia que propusieron soluciones al problema y que ya hemos
citado en este texto en diferentes oportunidades. Esta situación impulsó la
propuesta de creación de un modelo de calidad que debía ser amparado por un
amplio consenso internacional.
El equipo de trabajo de ISO denominado JTCl (Joint Technical Committee l),
realizó sus primeros estudios en 1978 y en 1985 la norma ISO 9126 comenzó su
andadura. La propia organización (ISO) acepta el fracaso de este primer intento de
normalizar la calidad del software argumentando la falta de una base común de
acuerdo y existiendo, por tanto, un amplio campo de arbitrariedades y subjetividad.
Con el objetivo de superar esta situación ISO propone basar el estudio y
normalización de la calidad en la definición de este concepto, calidad, propuesto en
la norma ISO 8420. Conseguir una estandarización y asenso internacional debe
sustentarse en una definición aceptada y única, la propuesta de una definición de la
calidad parecía una iniciativa fundamental para proseguir en la creación del
estándar. En 1991 se publica la primera edición de la norma ISOIIEC 9126 con
objeto de "promover un entorno que permita la evaluación de la calidad del
softwarev3. Sin embargo en 1994 se entendió necesaria la modificación y
Como nota es interesante destacar la dificultad de traducción de algunos términos ingleses al español. En
muchos casos asistimos a traducciones casi literales de los términos anglosajones. En nuestro caso entendemos
más adecuado el realizar traducciones más libres pero con un significado que entendemos más útil y descriptivo
del vocablo inglés.
IS0.9126 Information technology - Software product evaluation - Quality characteristics and guidelines for
their use. Suiza, 1991. Pág. iv. La traducción es nuestra.
LA CALIDAD DEL SOFTWARE Y SU MEDIDA 20 1
adaptación de la norma. En esta versión se introdujeron los conceptos de calidad

interna y calidad externa. Igualmente se creó una nueva norma, ISOIIEC 14598,
que asumía el modelo del proceso de evaluación antes incluido en la propia norma
ISOIIEC 9126.
La norma ISOIIEC 9126 posee cuatro partes:
- Parte 1: Modelo de la calidad.

- Parte 2: Métricas internas.
- Parte 3: Métricas externas.
- Parte 4: Calidad en las métricas de uso.
Sin embargo sólo la parte primera, modelo de calidad, es un estándar aprobado

y publicado siendo el resto de partes de la norma informes que se encuentran en la
denominada fase de Technical Report (TR). Por tanto estudiaremos en profundidad
la primera parte como base de nuestra propuesta de medida de la calidad.
2.1. Calidad de uso, interna y externa
La norma define un modelo de calidad basado en dos partes bien identificadas:
- La calidad interna y externa.

- La calidad de uso.
La calidad interna, entendida como "la totalidad de las características del

producto software desde un punto de vista interno", y la calidad externa definida
como "la totalidad de las características de producto software desde un punto de
vista externo" influyen en la calidad del proceso, al mismo tiempo que la calidad
de uso influye sobre las anteriores. Calidad interna, externa y de uso están
relacionadas, una se sustenta en la otra como capas sucesivas. La calidad del
proceso influye en la calidad del producto que a su vez es relevante en la calidad de
uso.
I Calidad del proceso 1 ---F Medida del roces so
Calidad interna ---+ Medida interna
Calidad externa --+ Medida externa
Medida de la
Calidad de uso -b calidad de uso
Figura 7.5. Modelo de calidad según ISOIIEC 9126.
La calidad de uso es definida por la norma como "la capacidad del software que
posibilita la obtención de objetivos específicos con efectividad, productividad,
satisfacción y seguridad".
Es interesante observar como la norma ISOIIEC 9126 aborda el conocimiento
de la calidad dividiéndolo en calidad interna o externa de forma similar a como se
propone por Fenton y que ya explicamos en el capítulo 2. En este caso los
conceptos de atributos internos y externos son menos definidos en la norma que en
la aproximación de Fenton y no coinciden en su totalidad con esta teoría, sin
embargo se observa una aproximación similar al problema considerando diferentes
"niveles" en la calidad que se influyen entre sí.
Figura 7.6. Modelo de calidad según ISOIIEC 9126.
La definición de cada uno de las características y subcaracterísticas es:
Funcionalidad. Se define como un conjunto de atributos que atañen a la

existencia de un conjunto de funciones y sus propiedades específicas. Estas
funciones son las que satisfacen las necesidades implícitas y establecidas. Esta
característica del software puede ser desglosada en varias subcaracterísticas:
o Idoneidad. Capacidad del software de proporcionar un conjunto apropiado

de funciones para tareas específicas y objetivos del usuario.
o Exactitud. Capacidad del software para proporcionar resultados correctos o
que necesitan un determinado grado de precisión.
o Interoperatividad. Capacidad del software de interaccionar con uno o más
sistemas especificados.
o Seguridad. Capacidad del software de proteger la información y los datos.
o Adherencia a normas. Capacidad del software relacionada con el grado de
conformidad con estándares, convenciones o regulaciones existentes en
leyes o prescripciones similares.
Fiabilidad. Conjunto de atributos que atañen a la capacidad del software para

mantener su nivel de prestación bajo condiciones establecidas durante un tiempo
establecido. Se descompone en las siguientes subcaracterísticas:
o Madurez. Capacidad del software para evitar fallos como resultados de

defectos en el software.
o Tolerancia a fallos. Capacidad del software para mantener un nivel
especificado de rendimiento en casos de fallos del software.
o Capacidad de recuperación. Capacidad para restablecer el nivel de
rendimiento y de recuperación de datos afectados directamente en el caso
de un fallo.
Facilidad de uso. Capacidad del producto software de ser entendido, aprendido,

usado y atractivo al usuario, cuando es utilizado bajo ciertas condiciones
especificadas.
o Fácil comprensión. La capacidad del software que permite al usuario

comprender si el producto es aceptable y cómo puede ser usado para tareas
particulares y determinadas condiciones de uso.
o Fácil aprendizaje. Capacidad del producto software que permite al usuario
aprender la aplicación software.
o Operatividad. Capacidad del producto software que permite al usuario
controlar y usar la aplicación software.
o Software atractivo. Capacidad del producto software de ser atractivo al
usuario.
Eficiencia. Capacidad del producto software para proporcionar un rendimiento

apropiado relacionado con el total de recursos utilizados bajo condiciones
establecidas.
o Comportamiento frente al tiempo. Capacidad del producto software para

proporcionar una respuesta y un tiempo de procesamiento apropiados al
..
desarrollar sus funciones bajo condiciones establecidas.
o Uso de recursos. Capacidad del producto software para utilizar un
apropiado número de recursos y tiempo de ejecución cuando el software
desarrolla sus funciones bajo condiciones establecidas.
Mantenimiento. Capacidad del producto software para ser modificado. Se

descompone en:
o Facilidad de análisis. Capacidad del producto software para diagnosticar

deficiencias o causas de fallos en el software.
o Capacidad para cambios. Capacidad del producto software que permite la
ejecución de una modificación específica en el mismo.
o Estabilidad. Capacidad del producto software para evitar efectos no
esperados debidos a modificaciones en el mismo.
o Facilidades para pruebas. Capacidad del producto software que permite al
software que ha sido modificado ser evaluado.
Movilidad. Capacidad del producto software para ser transferido de un entorno

a otro. El entorno se interpreta tanto a nivel software y hardware, como aquel
entorno relacionado con la organización.
o Adaptabilidad. Capacidad del producto software para ser adaptado a

diferentes entornos especificados sin aplicar acciones alejadas de aquellas
que el propio software proporcione.
o Facilidad de instalación. Capacidad del producto software para ser
instalado en un entorno específico.
o Coexistencia. Capacidad del producto software de coexistir con otros
programas independientes en un entorno común y compartiendo recursos
también comunes.
o Facilidad de reemplazo. Capacidad del producto software de ser utilizado
en lugar de otro producto software específico para el mismo propósito que
éste y en un entorno similar.
206 LA NORMA ISOlIEC 9126
La calidad de uso, de forma gráfica:
Calidad
de uso
1 Eficacia 1 Productividad 1 Seguridad 1' Satisfacción 1

Figura 7.7. Calidad de uso en la norma ISOIIEC 9126.
Eficacia. Capacidad del software para permitir a los usuarios alcanzar objetivos
específicos con precisión y completamente en un contexto específico de uso.
Productividad. Capacidad del producto software para permitir a los usuarios
emplear recursos apropiados con relación a la eficacia alcanzada en un contexto
específico de uso.
Seguridad. La capacidad del producto software para alcanzar niveles aceptables
de riesgo hacia la gente, negocio, software, propiedad o medio ambiente, en un
contexto específico de uso.
Satisfacción. La capacidad del producto software para satisfacer al usuario en
un contexto específico de uso.
2.2. Medidas internas y externas
Las características en las que ISOIIEC 9126 descompone la calidad son

influidas por atributos internos y externos propios de dichas características. Los
atributos internos son indicadores de los atributos externos. Un atributo interno
puede influir a una o más características y una característica puede verse influida
por uno o más atributos (ver figura 7.8).
Las características y subcaracterísticas son medidas, por tanto, a través de sus
correspondientes atributos. De nuevo observamos un paralelismo con la propuesta
de Fenton en la que se proponía la medida de entidades propias del software a
través de la cuantificación de sus atributos, también identificados como internos y
externos (ver capítulo 2).
La norma ISOIIEC define las métricas internas como aquellas medidas que se
realizan sobre un producto software no ejecutable, tal como la norma indica "un
producto software intermedio debería ser evaluado usando métricas internas".
Las métricas externas son medidas del producto software obtenidas del
comportamiento del sistema en la fase de ejecución del mismo. Finalmente las
métricas de la calidad de uso, como tercer gran concepto propuesto por la norma,
mide la extensión en la que un producto alcanza las necesidades expuestas por el
usuario de forma específica en relación a los objetivos de efectividad, seguridad,
productividad y satisfacción.
Subcaracterística
Característica
Figura 7.8. Atributos y características según la norma ISOIIEC 9126.
3. PROCEDIMIENTO DE MEDIDA PROPUESTO
Como colofón de este capítulo explicamos el procedimento de medida basado

en la realización de un conjuto de pasos o fases destinados a la cuatificación de un
atributo seleccionado. Este apartado es consecuencia de la recopilación y estudio
de diferentes fuentes; la norma ISOIIEC 9126, la metodología MÉTRICA Versión
208 LA NORMA ISOIIEC 9 126
3. (se estudia en detalle en el capítulo 4) y las aportaciones recogidas de diferentes

autores entre los que destaca la propuesta por el profesor Norman E. Fenton.
En concreto se pretende medir la calidad de un programa informático en
explotación. Para obtener datos cuantitativos se procederá a descomponer el
atributo a estudiar en criterios de calidad de más bajo nivel tal y como hemos
presentado en la descomposición jerárquica explicada. Con el objetivo de ser lo
más didáctico posible se tomará el atributo "madurez" como ejemplo de propiedad
del software que se desea medir y se explicarán los pasos diseñados tanto desde un
punto de vista genérico como considerando la medida de este atributo en concreto.
El procedimiento, evidentemente, puede ser utilizado para cualquier atributo que se
pretenda cuantificar.
Un primer paso del proceso de medida es la identificación del atributo a medir.
Cuantificar el atributo será el resultado final del proceso. El uso de una
metodología de desarrollo, en este caso MÉTRICA Versión 3, será básica para el
cumplimiento de este primer paso. La tarea denominada "EVS 3.2: identificación
de requisitos" y "EVS 3.3: catalogación de requisitos" se propone sean utilizadas
para el cumplimiento de este punto del procedimiento (ver figura 7.9). La necesaria
identificación de requisitos exigida por MÉTRICA Versión 3 se integra, por tanto,
en el proceso de medida diseñado. Esta integración permite al técnico identificar
fácilmente los atributos de calidad que se deseen cuantificar en la aplicación por
estar expresamente indicados en los requisitos del sistema y claramente
documentados.
En un segundo paso se ha de diseñar el proceso de evaluación. Se divide en tres
apartados:
Selección de métricas de calidad.
Evidentemente estas métricas están directamente relacionadas con los requisitos

identificados en el primer paso. Haciendo uso de la descomposición jerárquica
según el modelo Goal Question Metrics y basándonos en la norma ISO 9126 es
posible la selección de métricas adecuadas al atributo estudiado. Siguiendo con el
ejemplo propuesto, partiendo del concepto de "calidad de uso" según la norma
ISOIIEC 9126, nuestra atención se centra en el atributo de calidad denominado
"seguridad". Con objeto de concretar este atributo de alto nivel utilizamos la
descomposición jerárquica escogiendo la "fiabilidad como atributo de más bajo
nivel. Finalmente es el criterio "madurez" el objetivo de nuestro estudio. La
medida del atributo madurez se obtendrá según la ecuación 6.6 tomando como
medida del tamaño del software el número de puntos función como alternativa al
habitualmente utilizado número de líneas de código.
Tasar el nivel de dejhición.
Se han de definir en esta fase las escalas propias de las medidas a realizar. Las
escalas han de ser divididas en rangos de acuerdo a niveles de satisfacción de los
requisitos. Se suele elegir una escala 1-10 con objeto de adecuar la evaluación a la
medida utilizada en la práctica común de métodos de evaluación habituales.
Valorar la definición de los criterios.
Se basa en preparar procedimientos que permitan resumir los resultados de la

evaluación de las diferentes características. En este punto también se han de tener
en cuenta factores propios de la administración de recursos tales como coste y
esfuerzo requerido. Es necesario estimar el esfuerzo por parte de la organización.
El procedimiento de medida, el almacenamiento de los datos o el cálculo del
esfuerzo necesario para la realización de la medida puede ser ejecutada con los
mecanismos o herramientas que el técnico considere.
En el segundo punto el procedimiento propuesto hace uso, de nuevo de la

metodología MÉTRICA Versión 3, en concreto en su apartado EVS-CAL 1.3.
"Identificación de las propiedades de la calidad". La información aportada es
valiosa al establecer los atributos (propiedades según la nomenclatura de
MÉTRICA Versión 3) que, bien complejos, bien simples, permitirán establecer las
correspondientes medidas.
Como tercer paso se establece la evaluación del atributo. Este proceso se basa
en los anteriores. En él se realizan medidas de los atributos seleccionados según las
escalas acordadas. El procedimiento propuesto es original al integrar estándares
internacionales como ISO 9126, metodologías de desarrollo como es el caso de
MÉTRICA Versión 3 y el procedimiento de descomposición jerárquica
denominado Goal Question Metrics con el objetivo de la medida de la calidad del
software.
La incorporación de ejemplos en este libro tiene por objeto, no sólo la expresión
práctica de la teoría presentada en los apartados anteriores, sino la de ser una forma
alternativa de incluir nuevos conocimientos. Enfrentarse a la ejecución en un
entorno real de conceptos y teorías implica plantearse nuevas incógnitas que deben
resolverse. Muchas dudas surgen en la aplicación práctica de la teoría, aunque ésta
haya sido extensamente explicada. Al final de este capítulo se ha propuesto un
ejemplo extraído de la realidad.
METRICA Versión .3
Se apoya en
Definición de requisitos
Selección de métricas
ISO 9126
Selecciona Valoración del criterio
Métricas
J Obtiene
m Medida
Figura 7.9. El procedimiento de medida propuesto.

4. LA MEDIDA DE LA FIABILIDAD DE UNA A P L I C A C I ~ N

INFORMÁTICA. EJEMPLO PRÁCTICO
Como ejercicio práctico del procedimiento de medida propuesto en el apartado

3, a continuación explicamos en detalle la medida del atributo fiabilidad de cierta
aplicación informática que se encuentra en explotación.
El objeto de este ejercicio es doble. Por un lado nos entrenaremos en la medida
de este atributo propio del software presentando un proceso de medida que puede
ser utilizado en empresas de desarrollo o por que deseen evaluar la calidad del
producto ya entregado. Por otro lado nos servirá de práctica en la ejecución de
distintas herramientas propuestas a lo largo de diferentes capítulos de este texto. El
Análisis del Punto Función, el modelo de descomposición jerárquica en árbol (Goal
Question Metrics), la metodología MÉTRICA Versión 3.0, serán técnicas a
emplear. Este apartado no sólo será una aplicación inmediata de los
procedimientos, teorías y herramientas propuestas, será una forma de profundizar
en la teoría y conocimientos expuestos a lo largo de otros capítulos.
Este primer ejercicio tiene por objetivo la medida de la calidad de una
aplicación informática que se encuentra en explotación, en concreto del atributo
fiabilidad. Consideremos los pasos definidos en la figura 7.9 de forma que los
epígrafes siguientes coincidirán con los pasos a ejecutar para la medida de la
calidad.
4.1. Definición de requisitos de calidad
La metodología MÉTRICA Versión 3.0 considera en su interfaz de calidad o

interfaz CAL un marco común de referencia para la definición de planes de
aseguramiento de la calidad. Parece lógico, por tanto, apoyarnos en la propia
metodología para obtener los requisitos de calidad del producto software a
desarrollar (figura 7.10).
METRICA V 3.0
Se apoyaen ,vscAL, E"I CAL ,

Definición de requisitos
Figura 7.10 Definición de requisitos de calidad.

La actividad EVS-CAL~:IDENTIFICACIÓNDE LAS PROPIEDADES DE

CALIDAD DEL SISTEMA, sería la tarea a considerar en este primer punto. La
identificación de las propiedades de la calidad estarían asociadas al proceso EVS
(Estudio de Viabilidad del Sistema) y, por tanto se realizaría en los primeras fases
del desarrollo software. Si consideramos en detalle la tarea EVS-CAL1, MÉTRICA
Versión 3.0 la descompone en las siguientes actividades:
Determinación de los Sistemas
EVS-CAL 1.3
1 de Calidad
Tabla 7.2. Tareas asociadas a la actividad EVS-CAL1.
Es fácil identificar la tarea EVS-CAL 1.3 como aquella que nos permitirá
completar el primer punto del procedimiento de medida. La tarea EVS-CAL 1.3
será el resultado de las reuniones de trabajo realizadas por el jefe del proyecto y el
equipo de aseguramiento de la calidad, y como producto de esta tarea se
identificarán las propiedades de calidad del software. En este caso se ha
considerado la fiabilidad como la propiedad a evaluar. Es evidente que pueden
identificarse cuantas propiedades se consideren y que el equipo de trabajo detecte.
Cada una de las propiedades deberá sufrir un proceso similar al que seguiremos
con el propuesto para el de fiabilidad con objeto de obtener su cuantificación, su
medida. Es muy importante que los resultados de los equipos de trabajo sean
recogidos por escrito en un acta de reunión o cualquier otro medio que permita
identificar claramente el asenso conseguido y la responsabilidad asumida en la
misma por todos los componentes del equipo. Es demasiado habitual las
modificaciones de requisitos de todo tipo a lo largo del desarrollo de un programa
informático, este hecho es sumamente importante ya que implica la modificación
de todo el proceso de creación del software y afecta a todo el proyecto. La
concreción de criterios de calidad debe ser una exigencia para el equipo de
desarrollo y deben ser capturados con máximo rigor al inicio del proyecto evitando
posibles modificaciones futuras que se convierten en una seria amenaza a la
planificación establecida. Es imprescindible involucrar al usuario y considerar su
"punto de vista" ya que no debemos olvidar que el producto software, como
cualquier otro producto comercial, debe tener como fin dar respuesta a los
requerimientos del usuario. No podemos plantear un proyecto sin la colaboración y

autoexigencia de quien va a utilizarlo.
4.2 Preparar la evaluación
El segundo punto a realizar es la preparación del proceso de evaluación. Esta

fase se divide a su vez en tres apartados:
o Selección de métricas.
O Tasar.
o Valoración del criterio.
METRICA V 3.0
Se apoya en
0:. Preparación evaluación

Utiliza -
1 Selección de métricas e \
\
Se basa
Tasar en
Selecciona
m Métricas
Figura 7.11 Procedimiento de medida propuesto, paso segundo.

4.2.1. Selección de métricas
Una vez identificado el factor de calidad se hace necesario la descomposición

del mismo en criterios de calidad que nos acerquen a la medida deseada. Haremos
uso de la norma ISOIIEC 9126, gracias a la cual (ver figura 7.11) determinamos la
composición del factor considerado. Debemos asociar medidas (métricas) a cada
uno de estos factores. En este caso consideraremos a modo de ejemplo el criterio
madurez que entendemos medido a través de la densidad de defectos. La
asociación de factores y medidas es uno de los grandes retos de la ingeniería del
software y es donde la experiencia sustituye a una sólida propuesta teórica.
Figura 7.11. El criterio madurez en el modelo de calidad ISOIIEC 9126.
La densidad de defectos se obtiene a través de la ecuación:
Número de fallos detectados en el programa

Ecuación 7.1
Tamañodel pro grama
El numerador es una cantidad fácil de cuantificar aunque es necesario establecer

cierta disciplina con el fin de recoger datos objetivos. En el ejemplo propuesto,
obtenido de una experiencia real, se involucró al usuario de forma directa
solicitándole que indicara los fallos detectados en el programa en tiempo de

ejecución.
La recopilación de incidencias de la aplicación estudiada se realizó por parte del
coordinador informático (usuario avanzado interlocutor del jefe de proyecto). Toda
incidencia detectada se ponía en conocimiento del responsable del proyecto quien,
en colaboración con el coordinador clasificaba la incidencia según el siguiente
protocolo:
o Incidencia provocada por la necesidad de cambios en el programa inforrnático

para mejorarlo o adaptarlo a nuevas necesidades del usuario.
o Incidencia provocada por un fallo en el programa debido a un defecto en el

software. En este segundo caso se estableció la siguiente escala:
o Fallo muy grave. Implica la paralización total del sistema.
o Fallo grave. Implica la paralización total de uno o varios

programas.
o Fallo leve. Implica un mal funcionamiento de uno o varios

programas sin necesidad de suspender su ejecución.
El resultado final de la contabilidad de incidencias se recoge en la tabla 7.3.
Con relación al denominador es habitual considerar el tamaño de una aplicación

informática obteniendo el número de líneas de código. Ya hemos comentado los
severos problemas que esta medida posee por lo que consideramos el tamaño de la
aplicación en números de puntos función.
Tabla 7.3. Resumen incidencias detectadas en el proyecto de medida.
4.2.2. Tasar
Los valores cuantitativos obtenidos representan la medida de un atributo, de una

cualidad del software. Estos datos deben ser trasladados a una escala pero esta
escala no nos indica el nivel de satisfacción. Con objeto de capturar esta
información es necesario dividir en diferentes grados de satisfacción los resultados
obtenidos [ISO/IEC 91261. En el caso que nos ocupa lo más trascendente es la
exigencia del coordinador informático de no aceptar la aplicación si se detectaba un
error definido como muy grave. Esta consideración exigía una escala todohada de
forma que cualquier error de estas características (muy grave) tenía como
consecuencia la no aceptación del producto informático. Con objeto de realizar un
estudio más detallado de las medidas obtenidas se fijó además otra posible escala
considerando los niveles de satisfacción como muy satisfactorio, satisfactorio e

insatisfactorio, según la siguiente figura:
.. . . . . . . . . . . . . . . . . . .. .. .. .
. . . . . . . . . . . . .
4 . .. . .. . .. . .. . ... ... ....................
. . . . . . . . . . . . . . . . . . . .. .. .. .
. . . .. .. .. .. .. .. .. .. .. . . . .
....... . . . . . . . .....
. . ..~atiSfactorio.. . .
. ... ... ... ... ... ... ... ... ... ... ... ... ..
. . . . . . . . . . . . . . . . . . .. .. .. ..
Muy . . . . . . . . . . . . .
Insatisfactorio . ... ... ... ... ... ... .. . .. . .. . .. . .. . .. . ..
. . . . . .. .. .. .. .. .. .. .. .. .. . Insatisfactorio
. .. .. .. .. .. .. .. .. .. .. .. .. .
. . . . . . . . . . . . . . . . . . . .. .. .. .
. . . . .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . .. .. .. .. .. .. .
. . . . . . . . . .
b
0,5 1,o
Densidad de defectos
Figura 7.12. Nivel de satisfacción y densidad de defectos
El resultado de la cuantificación del atributo fiabilidad es la clasificación de la

entidad programa informático en una escala de tipo nominal. Estamos etiquetando,
adjetivando el programa en función a los errores detectados por unidad de tamaño
del código. El programa será aceptado o no en función del nivel de satisfacción que
presente.
Los datos obtenidos son habitualmente almacenados en bases de datos. Estas
bases de datos se toman como referencia en otros proyectos de forma que es muy
habitual que se mejore la cuantificación de un atributo en sucesivos proyectos. Por
otro lado uno de los evidentes problemas de esta subjetividad en la cuantificación
de atributos es la inexistencia de datos universales que permitan cotejar
aplicaciones de distinta naturaleza técnica.
4.2.3. Valoración del criterio
La necesaria infraestructura técnica y los recursos humanos imprescindibles

para la ejecución de un programa de medida es un factor que muchas veces se
considera de menor importancia y que, sin embargo, supone el aspecto más crítico
del trabajo a realizar. El apoyo de la dirección es básico y se manifiesta en la
designación de recursos humanos a las diferentes tareas a realizar. La
concienciación del personal, su formación y la dedicación a la medida del software
debe estar apoyada por la dirección de forma indiscutible.
Este apartado está dirigido a la estimación de los recursos humanos y técnicos

necesarios para la realización de la medida. En el caso que nos ocupa el número de
técnicos informáticos, de usuarios finales y su dedicación se expresan en la tabla
7.4.
Tabla 7.4. Estimación del personal y dedicación.
De nuevo nos encontramos con la necesaria experiencia del responsable del

proyecto para el cálculo de los recursos necesarios. Como podemos observar en la
tabla 7.4, se incluye de forma expresa la participación del coordinador informático
con dedicación parcial y una estimación de 16 horas en total.
Una vez identificados los integrantes del equipo de trabajo es imprescindible
establecer un protocolo de actuación para la recopilación de los datos. El
procedimiento debe ser aprobado por el responsable e informado al resto del
equipo. En el caso que nos ocupa el procedimiento consta de 4 tareas básicas:
1. El coordinador informático aporta información detallada sobre las incidencias

recopiladas durante un período de tiempo determinado haciéndoselas llegar al
responsable del proyecto. Esta información debe ser trasmitida por escrito y
haciendo uso de una plantilla estándar en la que se recoja la información necesaria.
2. El programador informático (sistemas-desarrollo) realiza la contabilidad de
los puntos función de los programas. Esta tarea es independiente del punto (1).
3. El operador traslada la información a tablas y estadillos para el futuro análisis
de los datos. La información enviada por el coordinador informático y por parte de
los programadores se utiliza para el cálculo de la densidad de defectos. Es un
proceso de cálculo simple.
4. Semanalmente el responsable del proyecto realiza una reunión de control con
los agentes implicados y dirige esfuerzos según los trabajos desarrollados y la
posible existencia de desviaciones de los tiempos estimados.
La obtención de datos cuantitativos culminará con el análisis de los mismos y la

propuesta de actuaciones según los resultados obtenidos. Hemos de considerar que
los datos no son un fin en sí misino, sino un medio para la toma de decisiones sobre
bases objetivas. En este caso la decisión es tan crítica como la aceptación o no de
una aplicación informática ya desarrollada y en fase de explotación.
4.2.4. Obtención de medidas
El resultado final del proceso establecido es la obtención de los datos

cuantitativos. Según establecimos en el punto 4.2.1, la ecuación 7.1 y la tabla 7.3
nos proporcionarían parte de la información necesaria para la cuantificación de la
fiabilidad. El denominador de la ecuación se obtendría ejecutando el Análisis del
Punto Función.
El resultado de la medida del tamaño de la aplicación informática es:
Tamaño aplicación = 90,984 puntos función ajustados
Por lo que la densidad de defectos de la aplicación es:
1190,984 = 0,011
10190,984 = 0,110
Con las siguientes unidades:
0,011 incidencias graves por puntos función

0,110 incidencias leves por puntos función
En ambos casos, considerando los dos tipos de incidencias, la aplicación se

considera aceptable para el usuario. La aplicación, por tanto, cumple los requisitos
exigidos.
Capítulo 8
MÉTRICAS DEL SOFTWARE

En cualquier sector económico, el disponer de
información cuantificada resulta vital para mejorar en el mundo
competitivo de los negocios. En la industria del software, la
utilización de las métricas comienza a valorarse debido a los
excelentes resultados obtenidos con su implantación'
La búsqueda de la calidad como elemento competitivo en la industria del

software implica saber en qué situación se está y planificar cómo mejorar. Para ello
no basta conocer aspectos cualitativos si no se cuantifican adecuadamente.
Numerosos estudiosos de la calidad del software investigan en este campo y
proponen continuamente medidas de aspectos y características de la calidad del
software, no siempre de acuerdo con la norma ISO 9126. Actualmente, el
desarrollo de las métricas se encuentra en un momento de cierta confusión,
necesitando muchas de ellas de validación tanto teórica como empírica. En muchos
casos la medida obtenida no se sabe a qué característica de calidad afecta ni de qué
forma. En este capítulo se presentan, aunque no de forma exhaustiva, las métricas
más utilizadas.
1. MÉTRICAS E INDICADORES DE LA PRODUCTIVIDAD
A pesar de que el software no posee entidad material, la cuantifícación de su

tamaño fue una de las primeras medidas propuestas, y ha sido ampliamente
utilizada por los ingenieros de software, bien como un valor en sí mismo, bien
como un elemento clave para determinar otros atributos tales como complejidad,
' Marta D'Amore Benito. Ingeniero de Telecomunicaciones por la UPM, especiiista en Calidad del Software.
¿Para qué las métrica? Boletín Interno Tecnológico de Indra. Madrid.
222 MÉTRICAS DEL SOFTWARE
coste o productividad. Es debido a su relación directa con la medida de la

productividad la causa por la cual se ha incluido su estudio en este apartado.
La productividad, otro de los atributos propio de los recursos utilizados para el
desarrollo del software que será estudiado. Aunque la medida tradicional de este
atributo se ha fundamentado en el número de líneas de código generado por
persona y mes, se presentan medidas alternativas y sus ventajas.
1.1. Medida del tamaño
La medida tradicional de este atributo (tamaño de una aplicación) se ha

fundamentado en el número de líneas de código. Aún es habitual utilizar como
medida de la productividad generada por un técnico el número de líneas de código
por número de unidades temporales consideradas (días, horas, meses).
Las ecuaciones más habituales en la medida de la productividad2 [Kan, 20031
son:
Tamaño
Productividad = Ecuación 8.1
Esfuerzo
Líneas de código
Productividad = Ecuación 8.2
Personas - mes
Por otro lado, las medidas más habituales utilizadas para cuantificar el tamaño
de una aplicación informática son:
Líneas de código
El número de líneas de texto que componen el código fuente de un programa ha

sido la medida más utilizada en la cuantificación del tamaño del software,
entendido éste como un atributo interno de un producto. Es una medida fácil de
obtener y manipular, además, ha sido considerada como factor clave de otros
atributos como ocurre en el caso de la productividad. Las líneas de código,
expresadas como LOC (del inglés Lines of Code), presentan, sin embargo, ciertos
problemas que se ponen de manifiesto en las siguientes preguntas:
La productividad es un atributo externo de los recursos, en concreto del recurso personal [Fenton y
Pfleeger, 19971.
- ¿Se han de considerar los comentarios y las líneas en blanco en la

contabilidad de las líneas de código de un programa?
- ¿Es equivalente el número de líneas de código contabilizado en un lenguaje
de programación u otro?
- ¿Se han de considerar todas las instrucciones, o pueden obviarse
definiciones de constantes y variables?
- Al igual que se hace con el código fuente ¿Puede utilizarse esta medida
para otros documentos propios del desarrollo software tales como
requisitos o diseño del programa?
- ¿Influye la tecnología a utilizar en la contabilidad de las líneas de código?
- Hay instrucciones que pueden necesitar más de una línea de código fuente,
o por el contrario pueden existir diferentes instrucciones en una línea, ¿no
sería necesario considerar el impacto de este hecho?
Hacer uso de esta medida requiere la definición de lo que entendemos por línea
de código. De esta forma superaremos algunas ambigüedades respondiendo a
varias preguntas anteriores. Una Iínea de código se define como: Cualquier línea
de texto del programa excluyendo comentarios y líneas en blanco.
En muchos casos es interesante considerar también el número de líneas de
comentarios que posee un programa ya que, aunque no son comandos necesarios
para la ejecución del mismo, sí son una fuente de información muy útil que pueden
influir en las posteriores modificaciones o en el mantenimiento de dicho programa.
Así las líneas de código sin considerar los comentarios se especificarán como
NLOC, y aquellas que consideren los comentarios se definen como CLOC. El
número de líneas totales sería:
LOC = CLOC + NLOC Ecuación 8.3
Una medida de la densidad de comentarios sería:
d=-CLOC Ecuación 8.4

LOC
Algunos investigadores han propuesto el carácter como medida alternativa a las

líneas de código [Fenton, 19921. Sería una medida simple de coleccionar y la
conversión del número de caracteres en líneas de código sería extremadamente
fácil.
node cavácteres
LOC = Ecuación 8.5
a
Donde a es un número promedio de caracteres por línea de texto.
En muchas ocasiones podemos encontrar el acrónimo KLOC, indicando miles

de líneas de código. Es una magnitud muy utilizada en grandes aplicaciones, siendo
un múltiplo de LOC.
Medir el tamaño del código fuente haciendo uso de las líneas de código presenta
algunos inconvenientes y dudas a las que nos hemos referido anteriormente. Estos
problemas se ven agravados cuando deseamos medir el tamaño de otros
documentos propios de la fase de diseño o captura de los requisitos. Es fácil
comprender el grave obstáculo que encierra cuantificar esta documentación si se
considera que en numerosas ocasiones se componen, no sólo de líneas de texto, si
no también de gráficos, diagramas de flujo, ecuaciones, símbolos y demás
anotaciones propias de estas fases del desarrollo software. En muchas ocasiones se
utiliza el número de páginas de documentación pero no es una medida aceptable.
En resumen, las líneas de código son una medida sencilla de obtener y
manipular, ampliamente utilizadas aunque con serios inconvenientes, algunos de
los cuales pueden ser superados gracias a definiciones concretas y de general
consenso.
Tokens
Una alternativa a la contabilidad de las líneas de código es la contabilidad de las

muestras, token, existentes en el código fuente. Un token se define como un
elemento propio del lenguaje que posee significado por sí mismo (instrucciones,
identificadores, operadores, constantes, delimitadores de comentarios y signos
especiales). Haciendo uso de esta medida se obtendría un valor más adecuado al
lenguaje de programación utilizado proporcionándonos una idea más precisa de la
información contenida en el código fuente. La Ciencia del Software de Halstead
hace uso de estas señales o tokens, que permiten conocer el tamaño de un
programa, el vocabulario del mismo o su volumen. Esta última medida nos indica
el espacio de memoria mínimo requerido para almacenar el programa. La medida
propuesta por Halstead ha sido considerada como una mezcla de tamaño y esfuerzo
Funcionalidad
En algunos casos, propios de grandes aplicaciones en las que existen miles de

programas con cientos de líneas de código cada uno de ellos, se ha propuesto como
unidad de medida del tamaño el módulo. Sin embargo, esta medida es de difícil
aplicación en un marco de medida estricto pues no existe una clara definición de
esta magnitud, es más, su uso implicaría cierta confusión entre la entidad medida,
programa o conjunto de programas que constituyen una aplicación, y la medida en
sí misma, módulo, entendido como programa, rutina o subrutina que forma parte de
la aplicación. Como alternativa más certera existe el concepto de funcionalidad.
Este atributo, propio del programa, está asociado con el concepto de funciones
proporcionadas por el mismo, entendido como una colección de instrucciones que
realizan una tarea determinada. El programador considera el código a través de las
funciones que ha de realizar más que como un conjunto de líneas de texto o
comentarios, por lo que su cuantificación sería enormemente útil al hacer coincidir
un valor numérico con la apreciación subjetiva del profesional.
Albrecht a finales de la década de los setenta realizó un muy serio acercamiento
a la medida de la funcionalidad gracias a su concepto de Punto Función. Es
especialmente destacable que la medida propuesta por Albretch puede ser aplicada
tanto al código, como a las especificaciones o al diseño, superando uno de los
graves problemas suscitado por el uso de las líneas de código. Es habitual obtener
el número de Puntos Función propios de cierto programa, transformarlos en línea
de código según el lenguaje de programación utilizado y posteriormente hacer uso
de ecuaciones en las que interviene como factor el valor LOC.
Capers Jones, uno de los más influyentes investigadores en el ámbito de la
ingeniería del software, ha propuesto el concepto de nivel de lenguaje
relacionándolo con el concepto de Punto Función. Un lenguaje de programación
poseerá un nivel u otro basándose en el menor número de estamentos requeridos
para codificar un Punto Función. Cobol, por ejemplo, es un lenguaje de nivel 3 y
requiere alrededor de 105 estamentos por Punto Función. Capers Jones relaciona el
concepto de nivel del lenguaje con el de productividad y, por tanto, con el tamaño
del código.
226 MÉT~UCASDEL SOFTWARE
1 1 1 por Punto Función 1

Basic 3.00 107
Clipper 17.00 19
Fortran 90 4.00 80
Natural 6.00 53
Lenguaje Máquina 0.50 640
Tabla 8.1. Niveles de lenguajes según Caper Jones.
Reusabilidad
Es muy habitual que los programadores hagan uso más de una vez de programas
o parte de éstos, modificándolos o simplemente reutilizándolos sin llegar a
modificarlos. Esta práctica ha de influir en la medida del tamaño del código, es
considerado por algunos modelos.
La reusabilidad posee dos acepciones que convienen diferenciar. Por un lado
encontramos el código desarrollado de forma externa al programa que se está
implementando y que Fenton definió como reuso público. Es evidente que para la
medida del programa en su conjunto se podría elegir alguna de las opciones
comentadas en este apartado tal y como se hubiera realizado con otros programas
íntegramente desarrollados por el equipo habitual de programadores. Por otro lado
se definiría el reuso privado entendido como módulos reutilizados dentro del
mismo producto. Es en este último caso donde se puede aplicar ciertas técnicas y
ecuaciones que permitan una mejor aproximación al tamaño real de nuestro
programa ya que no puede medirse de forma similar un código desarrollado desde
cero que otro adaptado o simplemente utilizado más de una vez.
El modelo de Boehm, COCOMO tiene en cuenta el hecho de la reusabilidad,
según la ecuación:
a
S , = S , +-S, Ecuación 8.6
1 O0
donde S, es el código reutilizado, S, el código nuevo y a es un factor de ajuste que

se obtiene en función del grado de modificación sufrido por el diseño (DM) y el
código (CM) y del correspondiente esfuerzo de integración (IM) según la ecuación:
a = 0.4(DM) + 0.3(CM) + 0.3 ( IM) Ecuación 8.7
el máximo valor de a es de 100, en este caso se asumiría que adaptar el código es

similar en cuanto al esherzo a reescribirlo.
Thebaut presenta una modificación a esta ecuación aplicando un exponencial a
uno de los factores según la ecuación:
S, = S, + S ,k Ecuación 8.8
donde valor de k es mayor que cero y menor o igual a uno.
1.2. Medida de la Productividad
Uno de los primeros objetivos de la medida del software es el control y

valoración de la labor realizada por el equipo de desarrollo.
Hombre-Mes
La industria tradicional posee una herramienta simple y efectiva que le permite

valorar el trabajo de sus operarios. Conociendo el número de unidades realizadas
por un trabajador y el tiempo empleado para tal fin se puede obtener una exacta
medida de la productividad de dicho trabajador. Si a esto le añadimos un control de
la calidad del producto realizado, obtenemos una medida fiable, sencilla y
enormemente útil de la productividad industrial. Esta noción de la productividad y
su mediada se ha intentado trasladar al desarrollo de programas informáticos. Si
conocemos el monto total del producto obtenido, en este caso el tamaño del
programa, y el esfuerzo necesario para su desarrollo, generalmente expresados en
personas-mes, sería simple medir la productividad del equipo de desarrollo según
la fórmula:
Tamaño de salida
Ecuación 8.9
Personas - mes
Haciendo la sustitución del numerador por cualquiera de las medidas del
tamaño del software propuestas en el apartado anterior se obtendría la
productividad de un programador o del equipo de desarrollo. La productividad es
la medida de un atributo externo propio de un recurso. Se habla de la productividad
(atributo externo) del equipo de desarrolladores (recurso) al realizar el desarrollo
de cierto programa (producto). Se valora al equipo de profesionales no al proceso
de desarrollo.
Pero la medida hombre-mes tiene muchos problemas. Según Brooks, "El
Hombre-Mes, como unidad para medir la magnitud de un trabajo, es un mito
peligroso y equivoco. Implica que los hombres y los meses son intercambiables.
Los hombres y los meses son bienes intercambiables sólo cuando una tarea puede
repartirse entre varios empleados sin que sea necesaria una comunicación entre
ellos. El coste varía, de hecho, como el producto del número de personas y el
número de meses. El avance, no".
En las tareas que pueden repartirse y que además requieren una comunicación
entre subáreas, debe añadirse al total del trabajo a realizar el esfuerzo de
comunicación.
La frontera de comunicación que se ha añadido, se compone de dos partes: la
formación y la intercomunicación.
La formación de los trabajadores incluye la tecnología, los objetivos del trabajo,
la estrategia general y el plan de trabajo. Este esfuerzo varia linealmente con el
número de trabajadores.
El esfuerzo de intercomunicación incluye la coordinación de tareas, las
reuniones de resolución de problemas, etc..
Puntos Función
La medida más utilizada en el caso del tamaño del software ha sido el número
de líneas de código, por lo que la productividad ha venido indicada en la mayoría
de los casos en términos de líneas de código por persona y mes. Las ventajas e
inconveniente que presentaba la media del tamaño en términos de LOC se traslada,
por tanto, a la medida de la productividad. Frente a la sencillez de su contabilidad
aparecen serias dudas de su bondad según el lenguaje de programación utilizado o
la falta de representación de la productividad del equipo de desarrollo al ser
fácilmente alterable añadiendo líneas de código innecesarias o de poca utilidad. La
alternativa es el uso de los Punto Función, según la ecuación:
Número de Puntos Función

Ecuación 8.10
personas - mes
El uso de esta ecuación posee la ventaja de que puede obtenerse en cualquier

momento del desarrollo del software evaluando la productividad en fases diferentes
y con la ventaja de hacer uso de una medida del tamaño del software más cercana a
la visión del programador.
Errores
Otro factor que afecta a la productividad es la calidad del producto obtenido. En

el caso de un producto industrial es sencillo aplicar procedimientos estadísticos que
determinen de forma muy aproximada el número de unidades defectuosas resultado
de cierto proceso y realizado por cierto equipo. El control estadístico se basa en la
obtención de un producto estandarizado, con idénticas características. Este hecho
no puede darse en el software por lo que el control de la calidad debe basarse en
medidas propias de esta actividad.
número de errores
Calidad = Ecuación 8.1 1
IUOC
Documentación
Es habitual recoger datos sobre la documentación aportada por el equipo de

trabajo. Se ha de considerar la información suministrada con el programa un factor
más para evaluar la productividad. Suele expresarse según la ecuación:
número de paginas
Ecuación 8.12
KLOC
Es muy difícil cuantificar la documentación, generalmente compuesta por texto,

gráficos o esquemas, por lo que la ecuación 8.12 es muy criticada.
También es interesante considerar el código reutilizado y obtener medidas que
lo consideren como las estudiadas en el punto anterior.
Nivel de lenguaje
Una aproximación algo más sofisticada a la productividad es la propuesta por

Capers Jones apoyada en el concepto nivel del lenguaje (ya introducido en el
apartado anterior). Para este investigador la productividad se encuentra relacionada
con el nivel del lenguaje aunque no de forma lineal. La tabla 8.2 aporta datos
numéricos a esta relación.
Tabla 8.2. Productividad y nivel de lenguaje.
Como resumen de este apartado hay que indicar que la productividad no puede
determinarse exclusivamente como una expresión que envuelva el tamaño de la
salida y el número de personas involucrada en dicha tarea. Debe considerarse la
calidad del producto resultante. Se han de realizar una batería de medidas en las
que se han de incluir datos relacionados con el tamaño del programa resultante,
personal implicado en el proceso, coste del mismo y la calidad resultante.
A continuación se presentan medidas que se han establecido como valores de

singular importancia en la medida de la calidad del software. En este apartado se
han incluido medidas relacionadas con la calidad, así como otras aproximaciones
como es el caso de la medida de la complejidad propuesta por McCabe o la Ciencia
del Software ideada por Halstead. La medida de McCabe se ha incluido por la
trascendencia que la complejidad del software posee en relación a la calidad.
2.1. Densidad de defectos e indicadores de calidad del proceso
Uno de los principales objetivos de administradores e ingenieros de software es

la producción de software libre de defectos, de tal forma que su utilización diaria
esté exenta de errores. Esta concepción tiene una clara incidencia con la calidad y
más concretamente con el atributo fiabilidad, ya definido en el apartado anterior.
Los recursos utilizados para asegurar que un programa se encuentra libre de
errores se ha fundamentado en la realización de pruebas más o menos complejas y
en la establecimiento de revisiones técnicas. La realización de pruebas destinada a

descubrir disfunciones en el software ha de ser cuidadosamente establecida
considerando las funciones que el programa debe realizar así como seleccionando
adecuadamente los datos "testigo" de las pruebas planificadas. Las medidas propias
de este tipo de comprobación han sido tradicionalmente aquellas en las que
intervienen el número de errores detectados durante el proceso de prueba, aunque
también se han considerado el número de cambios realizados en el diseño de un
programa o en el código del mismo. El proceso habitual es realizar una batería de
pruebas y contabilizar ciertas medidas, las más utilizadas son las expuestas a
continuación.
Densidad de defectos
número de defectos descubiertos en el programa

Ecuación 8.13
tamaño del programa
La medida 8.13 es la más habitual y se denomina densidad de defectos. Como

se observa es una medida indirecta en la que interviene el tamaño del programa,
generalmente indicado en miles de líneas de código, KLOC, aunque también se
utilizan los puntos función. La densidad de defectos mide un atributo externo del
producto de forma indirecta, haciendo uso de dos medidas directas. Por un lado la
medida de un atributo interno de un proceso como es el número de defectos
descubiertos durante cierta fase de pruebas u operación del software, y por otro de
un atributo interno de un producto como es el caso del tamaño del programa.
Esta medida es muy utilizada incluso en grandes empresas, y aún en nuestros
días se considera un dato estratégico y de acceso restringido.
Tasas
Muy relacionadas con la definición de densidad de defectos del software se

encuentran otras medidas que se agrupan con el nombre de "tasas". Son
indicadores de la calidad del proceso ya que tienen el factor tiempo como
componente de las mismas. Algunas de las medidas más utilizadas son:
Tasa de propagación de defectos
número de defectos ocasionados al corregir defecto

Ecuación 8.14
número de defectos corregidos
Eficiencia en la eliminación de defectos
número de defectos corregidos durante una fase de desarrollo

* 100
numero de defectos detectados durante una fase de desarrollo
Ecuación 8.15
Tasa de efectividad de las pruebas
número de objetos probados almenos una vez

* 100 Ecuación 8.16
número de objetos totales
Con las ecuaciones 8.14J.15, 8.16 se pueden realizar una política de pruebas y
captura de medidas muy valiosas para el desarrollo de aplicaciones y su control de
calidad.
Las revisiones técnicas basan su eficacia en la realización de verificaciones
manuales del diseño o código. La principal preocupación en estos casos en evitar
juicios personales o subjetivos, por lo que se articulan procesos tendentes a evitar
estas actitudes. No nos extendemos en este punto pues se escapa del objetivo de
este apartado
3. Fiabilidad
La medida de la fiabilidad es expresada por numerosos técnicos como

probabilidad de que no ocurra un error en un determinado tiempo. Si consideramos
R la medida de la fiabilidad y F como la probabilidad de que aparezca un error en
un tiempo determinado t, podemos expresar matemáticamente.
R(t)= 1 - F ( t ) Ecuación 8.17
Si consideramos un valor del tiempo discreto la ecuación seria
d,
R(n)= 1 - - Ecuación 8.18
n
donde d,, es el número de fallos encontrados en n ejecuciones.
Si f(t) es la función densidad de probabilidad, es decir:
f (t) = dF(t) l dt Ecuación 8.19
donde f(t) es la probabilidad de que el software falle en el intervalo de tiempo (t,

t + dt). La tasa de riesgo h(t) es la probabilidad de que el sofware falle en (t, t + dt)
si no ha fallado antes:
h(t) = f (4 Ecuación 8.20

1- F(t)
de donde se puede obtener:
d
h(t) = f ( t ) =--(ln(l-~(t)))=- ln R(t) Ecuación 8.21
1-F(t) dt dt
ln R(t) = Ih(x)dx Ecuación 8.22

O
R(t) = e,
Ih(x)h
Ecuación 8.23
Se define el tiempo medido entre fallos MTTF, acrónimo del inglés Mean Time
to Faillure como:
1
MTTF = - Cfl ti
i=1
Ecuación 8.24
Finalmente la fiabilidad, tal como la se ha definido para estas ecuaciones se

relaciona con el valor del tiempo medio entre errores a través de la ecuación.
MTTF = ) ~ ( tdt) Ecuación 8.25

O
4. COMPLEJIDAD DEL SOFTWARE
Unida intrínsecamente a la medida del tamaño del software se encuentra la

medida de la complejidad. Como se ha podido apreciar en las ecuaciones
anteriores, conocer el tamaño del software es fundamental para establecer la
calidad del mismo, por lo que medir la complejidad es fundamental en el
conocimiento de la calidad de un sistema software. La cuantificación de este
atributo ha supuesto numerosos esfuerzos, dos de los más representativos son
introducidos a continuación.
4.1. La Ciencia del Software de Halstead
La Ciencia del Software de Halstead es una de las más estudiadas, populares y

controvertidas teorías sobre el software y su cuantificación. Halstead definió un
conjunto de métricas basadas en los elementos sintácticos existentes en el
programa, en el léxico del código fuente. Su base teórica parte de la psicología,
concretamente de la psicología cognitiva.
La ciencia de Halstead de basa en un conjunto de medidas definidas así:
nl = número de operadores distintos que aparecen en un programa.

n2= número de operandos distintos que aparecen en un programa.
NI= número total de ocurrencia de operadores.
N2= número total de ocurrencia de operandos.
Conocidas estas medidas iniciales podemos calcular "N", la longitud del

programa según la ecuación:
N=N,+N2 Ecuación 8.26
Además define el "vocabulario" del programa como:
n = n l +n2 Ecuación 8.2 7
Permite estimar el valor de N según la ecuación:
N= nllog2nl+n210g2n2 Ecuación 8.28
El valor de N puede convertirse en número de líneas de código haciendo uso de

tablas obtenidas por métodos estadísticos.
Según esta teoría el esfuerzo requerido para generar el programa se definiría

como el número de- operaciones mentales necesarias pare escribir un programa de
longitud N. Este valor vendría dado por la ecuación:
E= (nl N N2 logzn)/(2 n2) Ecuación 8.29
Define el concepto Volumen del Programa como el número mínimo de bits

necesario para codificarlo:
V = N log2(nl+ N2) Ecuación 8.30
Este valor cambia según el lenguaje utilizado. Para cada algoritmo particular ha
de existir un volumen mínimo. Halstead define la razón de volumen "L" como la
razón entre el volumen de la forma más compacta de un programa y el volumen
del programa real. L debe ser siempre menor que uno.
L = (2 n2 )f(n~N2) Ecuación 8.31
Halstead teorizo que cada lenguaje podía ser clasificado por un nivel de
lenguaje, "1". Este valor parece estar relacionado con el nivel de abstracción en
especificación de procedimientos. A mayor nivel de lenguaje mayor nivel de
abstracción.
Las críticas al modelo de Halstead se fundamentan en considerar erróneas las
hipótesis de la psicología cognitiva, base teórica del mismo. Por otro lado se han
determinado errores estadísticos cometidos en la validación de pruebas de medidas
obtenidas haciendo uso de las ecuaciones de Halstead [Fenton 19911. Otro hecho
fundamental es que las medidas propuestas en esta teoría obvian el diseño
centrando su información en el código.
4.2. La medida de la complejidad de McCabe
Esta medida se basa en la representación gráfica de un programa según el flujo

de control del mismo y nos informa de la complejidad lógica del diseño propuesto
debido a la estructura de decisiones del módulo considerado. Se denomina
complejidad ciclomática. Y la ecuación que nos proporciona su valor es:
V(G)=e-n+2 Ecuación 8.32
Donde e es el número de flechas de conexión que implica una transferencia de

control de un nodo a otro y n el número de nodos, entendidos éstos como tareas de
proceso.
236 METRICAS DEL SOFTWARE
Para conocer esta medida es necesario, por tanto, obtener la representación del
programa haciendo uso del grafo de flujo. Los elementos básico que conforman
dicho diagrama se consideran a continuación:
Nodo. Representan sentencias de código.
Nodo Predicado. En sentencias en las que aparecen

condiciones tipo NOR, OR, AND y NAND, aparece un
nodo por cada condición, a éstos nodos se les denomina
Nodo Predicado.
Flechas de conexión. Representan flujos de control.
Sentencia "until"
Sentencia "if'.
Sentencia "while".
Ejemplo de nodo predicado con sentencia

XORY.
Uno de los usos más habituales del número ciclomático está asociado con la
ejecución de pruebas. El número ciclomático nos informa del número de caminos
independientes del programa. Conocido este valor podemos saber el número de

pruebas máximo que asegure el que todas las sentencias se ejecutan al menos una
vez.
La complejidad del producto software fue limitado por McCabe, asociándolo a
un valor V(G) =lo, de forma que módulos con una complejidad ciclomatica
superior a este valor eran inadecuados, propensos a errores y de difícil
mantenimiento.
4.3. La métrica de Henry y Kafura
Henry y ~ a f u r midieron
a~ la complejidad basándose en el flujo de información
entre módulos.
Se define un módulo como "una secuencia identificable de instrucciones
contiguas", que no tienen que ser necesariamente de código fuente (texto de
especificación, de diseño, etc.). Se distinguen los atributos intra-módzdos (atributos
de un módulo vistos como independiente de los otros módulos) y los atributos
inter-módulos (atributos del sistema visto como un conjunto de módulos más o
menos dependientes unos de otros.
El análisis del diseño puede hacerse como si se tratará de grafos, tales como
grafo de llamadas entre módulos, grafos de control, grafos de dependencia de
datos, etc. En los grafos se pueden hacer diversas medidas:
Medidas de la morfología del grafo: número de arcos, de nodos, profundidad,

anchura, etc.
Medidas de nodos: número de arco entrantes, de arcos salientes, grado de

acoplamiento (se mide por los atributos del flujo de información entre módulos).
Cohesión de un módulo se define como "atributo de módulos individuales, que

describe su fuerza funcional, es decir, la importancia según la cual los
componentes del módulo son necesarios para ejecutar la misma tarea".
en ton^ propone, para la medida de la cohesión intra-módulo el cociente entre

el número de módulos con cohesión funcional y el número total de módulos. Como
la cohesión no está habitualmente modelada por un grafo, hay que definir una
medida ordinal, distinguiéndose de mejor a peor:
S. Henry y D. Kafura. Software Sfructure metric base on information flow. IEEE Transaction on software
Engineering. Vol 7, no 5, 1981.
4
N. Fenton. Software Metrics. A rigourous Approach. Chapman & Hall. 1992.
Cohesión abstracta: el módulo es un tipo abstracto de datos.

Cohesión funcional: el módulo sólo ejecuta una función bien definida.
Cohesión secuencial: el módulo ejecuta varias funciones que se realizan en
el orden descrito en la especificación.
Cohesión comunicacional: el módulo ejecuta varias funciones que tratan el
mismo conjunto de datos. El cuál no está organizado como una estructura o
un tipo único.
Cohesión procedural: el módulo ejecuta varias funciones que sólo están
relacionados con un procedimiento general.
Cohesión temporal: el módulo ejecuta varia funciones que sólo están
relacionadas por el hecho de que deben tener lugar en la misma zona
temporal.
Cohesión lógica: el módulo ejecuta varias funciones que sólo tienen una
relación lógica.
Cohesión de coincidencia: el módulo ejecuta varias funciones que no están
relacionadas.
~ o o c definió
h~ la cohesión como una "medida del grado de conectividad entre
los elementos de un módulo único, en el caso general, o como el grado de
conectividad entre los elementos de una clase o un objeto único, en el caso del
diseño orientado a objetos".
La presentación hecha por Henry y Kafura de su métrica es la siguiente:
Flujo global de información
Hay un flujo global de información de un módulo A hacia un módulo B a

través de una estructura global de datos D, si A deposita información en D y B
busca información en B.
Flujo local de información
Hay flujo local de información de un módulo A hacia un módulo B, si se

tienen una o más de las siguientes condiciones:
a) A llama a B.
b) B llama a A, y A devuelve un valor a B, y B lo utiliza inmediatamente.
c) C llama a la vez a A y a B, pasando un valor de A hacia B.
G. Booch. Conception orientée et applications. Addison- Wesley, 1991

F1 X O R Y. Flujo local directo de información
Hay un flujo local directo de información de un módulo A hacia un módulo B,

si A llama a B.
Flujo local indirecto de información
Hay un flujo local indirecto de información de un módulo A hacia un módulo

B, si B llama a A, A devuelve un valor a B, y B lo utiliza enseguida, o si C llama a
la vez a A y a B, pasando un valor de salida de A hacia B.
El fan-in de un procedimiento A es el número de flujos locales hacia el

procedimiento A, más el número de estructuras de datos en las que el
procedimiento A busca información.
El fan-out de un procedimiento A es el número de flujos locales que vienen del

procedimiento A, más el número de estructuras de datos que son actualizadas por el
procedimiento A.
La fórmula que define el valor de la complejidad de un procedimiento es:
comp.- proc. = (fan-in x fan-out12 Ecuación 8.33
El hecho de elevar al cuadrado viene dado por la suposición de Henry y

Kafura de que la complejidad es una función más que lineal de las conexiones del
procedimiento con su entorno.
El flujo total de información será el sumatorio de las complejidades de todos
los procedimientos, es decir:
Flujo = C (fan-in x fan-out12 Ecuación 8.34

Los procesos de negocios se abordan generalmente mediante diseño

multidimensionales que capturan las mediciones (hechos o medidas) del negocio y
los parámetros (dimensiones) que identifican las mediciones. Los modelos de datos
multidimensionales suelen representarse mediante esquemas en estrella, con una
tabla central (contiene las medidas de interés, los hechos) y varias tablas de
dimensión (una por cada dimensión conteniendo la información acerca de dichas
dimensiones).
El objetivo de las métricas para modelos de datos es medir la complejidad del
esquema de estrella como un índice de la calidad del sistema. Estas métricas se
distribuyen en tres niveles: métricas a nivel de tabla, métricas a nivel de estrella, y
métricas a nivel de esquema. Estas métricas han sido definidas por calero 6 y otros,
que también han realizado su validación formal, aunque es necesario proceder a su
validación empírica a fin de refinarlas y depurarlas.
5.1. Métricas a nivel de tabla
Son principalmente dos:
NA(T) Número de atributos de una tabla.

NFK(T) Número de claves ajenas de una tabla.
5.2. Métricas a nivel de estrella
Las métricas propuestas son:
NDT(S) Número de tablas dimensionales de una estrella.

NT(S) Número de tablas de la estrella.
NADT(S) Número de atributos de las tablas dimensionales de una estrella.
NAFT(S) Número de atributos de la tabla de hechos de la estrella.
FT Tabla de hechos de la estrella.
DTi Tabla dimensional i de la estrella S.
NA(S) Número de atributos de la estrella.
NFK(S) Número de claves ajenas de una estrella.
C. Calero, M. Piattini, C. Pascua1 y M:A. Serrano, Towards data warehouse quality rnetrics.Proceedinds of 31d
Workshop on desing and management of data warehouse, 2001.
NFK(S) = NFK(FT) + CNFK(DTi) (i = 1 a NDT).
RSA(S) Ratio de atributos de la estrella.
RSA(S) = NADT(S)/NAFT(FT).
RFK(S) Ratio de claves ajenas.
5.3. Métricas a nivel de esquema
En el último nivel se encuentran las siguientes métricas:
NFT(Sc) Número de tablas de hechos del esquema.

NDT(Sc) Número de tablas de dimensión del esquema.
NSDT(Sc) Número de tablas dimensionales compartidas por mas de una
estrella.
NT(Sc) Número de tablas del esquema.
NAFT(Sc) Número de atributos de las tablas de hechos del esquema.
NAFT(Sc) = CNA(FTi) (i = 1 a NFT).
NADT(Sc) Número de atributos deC las tablas de dimensión del esquema.
NADT(Sc) = CDA(DTi) (i =1 a NDT)
NASDT(Sc) Número de atributos de las tablas de dimensión compartidas.
NASDT(Sc) = CNA(DTi) (i = 1 a NSDT)
NA(Sc) Número de atributos del esquema.

NFK(Sc) Número de claves ajenas del esquema.
RSDT(Sc) Ratio de tablas dimensionales compartidas.
RT(Sc) Ratio de tablas. Cantidad de tablas dimensionales por cada tabla de hechos.
RScA(Sc) Ratio de atributos del esquema.

RFK(Sc) Ratio de claves ajenas.
RFK(Sc) = NFK(Sc)/NA(Sc)
RSDTA(Sc) Ratio de atributos de las tablas dimensionales compartidas.
5.4. Calidad de los propios datos
La calidad de datos es un concepto multidimensional que comprende diversos

aspectos que dependen de las necesidades de los usuarios de los datos y de los
diseñadores del sistema, por lo que deben elegirse aquellas dimensiones de calidad,
que proporciona la ISO 9126, que resulten más significativas.
Una metodología para medición de la calidad de los datos, basada en las ideas
de 0man7 et al., es la siguiente:
Fase 1: Identificación de los objetivos y de las medidas. Fase de análisis que a

partir de los requisitos de calidad de los usuarios se obtienen datos para las
siguientes fases
Determinar el objetivo de la medición.
1.2 Determinar los parámetros e indicadores de calidad.
1.3 Localizar los datos a valorar.
1.3.1 Determinar la cantidad de datos que deben ser valorados.
1.3.2 Localizar esos datos en la base de datos.
1.3.3 Elegir el momento en el que debe hacerse la valoración de los datos.
1.3.4 Identificar las fuentes de los datos.
1.4 Definición de criterios de calidad.
Fase 2: Creación de una estructura de calidad. En esta fase de diseño se dota al

almacén de datos de una estructura para almacenar los valores de las medidas.
Fase 3: Medición de los atributos de calidad. Se procede a la medición de aquellas

dimensiones de la calidad seleccionadas, bien mediante muestre0 o sobre la
totalidad de los datos.
7
L. Oman, V. Storey y R. Wang. Systems Approaches to Improving Data Quality.
1994.
http://web.mit.edu/tdqm/www/papers/94/94-0S.html,
Fase 4: Análisis y Evaluación de los valores de los atributos de calidad. Se valora

el grado de bondad de los datos y el grado de calidad del conjunto de ello,
desechándose los inválidos.
Actualmente existe un proyecto denominado CALDEA, financiado por la
Subdirección General de Proyectos de Investigación del Ministerio de Ciencia y
Tecnología, para crear un modelo de madurez de calidad de datos.
6. MEDIDAS DE FACILIDAD DE USO DE LAS INTEFWACES DE

USUARIO
Parece evidente que la característica de la calidad de un interfaz de usuario es la

facilidad de uso del mismo, por lo cual se han desarrollado diversos métodos y
medidas de esta característica o atributo.
6.1. Clasificación de los métodos
Siguiendo a wixon8 y Wilson distinguimos cinco criterios de clasificación:
Métodos formativos vs. Métodos sumativos. Los primeros se orientan a la

detección de problemas y generación de ideas de facilidad de uso (usabilidad), al
principio de las fases de análisis, diseño y desarrollo. Los segundos sirven para
evaluar sistemas terminados.
Métodos de descubrimiento vs. Métodos de decisión. Los primeros son
cualitativos y se dirigen al usuario para determinar cómo piensa, cómo trabaja y
con qué problemas encuentra. Los segundos, cuantitativos, sirven para elegir entre
diversos diseños alternativas.
Métodos formales vs. Métodos informales. Muchos de los métodos descritos
formalmente son, en la práctica, adaptados por los evaluadores, de manera
informal, según sus objetivos.
Métodos que involucran al usuario vs. Métodos que no involucran al usuario.
Dependen del que el usuario participe o no en el análisis, diseño y evaluación del
proyecto informática.
Métodos completos vs. Métodos componentes. Los primeros se extienden por
todos los pasos para completar un diseño centrado en la facilidad de uso. Los
componente, sólo cubren parte de un proceso completo de usabilidad y son la
mayoría de los métodos.
- - - --
8
D. Wixon y C. Wilson. The usability engineering framework for product design and evaluation. Handbook of
human-computer interaction. Elsevier Science, 1997.
6.2. Algunos métodos de evaluación
Se distinguirá entre métodos en los que los usuarios participan en un papel

principal (user testing), usando las técnicas de cuestionarios y "brainstorming" y
los que se prescinden de los usuarios (usability inspection) y en los que los
principales protagonistas son los expertos.
SUMI (Software Usability Measurement Inventory )9. Aunque en sus orígenes

era un cuestionario para evaluar la calidad del software tanto para productos
nuevos, como para comparar versiones antiguas y obtener ideas para nuevos
desarrollos. Requiere un mínimo de 10 cuestionarios.
MUMMS (Measuring the Usability of Multy-Media Systems). De los mismos

autores y con los mismos objetivos, sirve para medir la satisfacción de los usuarios
de aplicaciones multimedias.
WAMMI (Website Análisis and Measurement Multimedia Inventory). De los

mismos autores, se utiliza para la evaluación de sitios web.
SUS (System Usability ~cale)" Consiste en un sencillo test para comparar, de

forma cruzada, diferentes productos.
Usabilitv Inspection
Estas métricas, cuantitativas, obtienen información sobre la usabilidad que

presenta el producto.
Medidas de ~ielsenl'
Las medidas típicas cuantificables de usabilidad propuestas son:
- Tiempo que los usuarios emplean para completar una tarea.

- Número de tareas que pueden completarse en un tiempo dado.
- Relación entre las interacciones con éxito y los errores.
- Tiempo usado para reparar los errores.
- Número de errores de usuario.
HFRG. The humanfactors research group.Universiíy College Cork, 1990.

'OJ- Brooke. User Information Architecture A/D Group.Digita1Equipment Co. Ltd.
" J. Nielsen. Usability Engineering.Academic Press, 1993.
Porcentaje de competidores que consiguen una medida mejor.

Números de acciones erróneas inmediatamente posteriores.
Número de comandos y otras características utilizados por el usuario.
Número de comandos y otras características no utilizados nunca.
Número de características que el usuario recuerda después de un test.
Frecuencia de uso de manuales y10 ayudas del sistema y tiempo empleado
en ello.
Frecuencia con la que el uso anterior resolvieron el problema.
Ratios entre opiniones positivas y negativas del usuario durante el test.
Número de ocasiones en que el usuario presenta fmstración.
Proporción de usuarios que prefieren el sistema a otro de la competencia.
Proporción de usuarios que emplean estrategias eficiente.
Tiempo muerto en el que el usuario no interactúa con el sistema.
Número de veces en que el usuario se desvía de la tarea.
Método de Constantine y ~ o c k w o o d ' ~
Estas métricas pretenden medir la complejidad (complexityl y la adecuaciQn

(appropriateness) del diseño. Sin entrar en detalles, se presenta una relación de las
métricas y de las características que pretenden cuantificar:
- Essential Efficiency Simplicidad

- Task Concordance Eficiencia, simplicidad
- Task Visibility Visibilidad.
- Layout Uniformity Regularidad, uniformidad
- Visual Coherence Comprensibilidad.
7. MEDIDAS DE SEGURIDAD
La seguridad se ha convertido, actualmente, en la principal característica

demandada al software. Desgraciadamente existen pocas medidas y la evaluación
de la seguridad de los sistemas informáticos se hace mediante auditorias de
seguridad, basadas en cuestionarios, en general, cualitativos.
Como principio general se emplea el método de descomposición en árbol de la
característica Seguridad en sus subcaracterísticas. Un ejemplo podía ser el de la
figura 8.1.
12
L. Constantine y L. Lockwood. Software for use. A practical guide to the models and methods o j
usage.centered design. Addison-Wesley, 1999.
..
;
;;
f ALGORITMO j/ CLAVES
;!
j 1
........................................i i..................................i
i
CCESIBILIDAD
Fig. 8.1. Descomposición en árbol de las características de la seguridad.
7.1. Un poco de historia
El inicio de las investigaciones sobre herramientas para evaluar y auditar la

seguridad de los sistemas informáticos fue el trabajo conjunto del DoD
(Department of Defense) y el NIST (National Institute of Standars and
Technology), en 1970, ambas instituciones de los Estados Unidos de América.
Orientado inicialmente a la determinación de los niveles de confidencialidad de la
información, dió como fruto el TSEC (Trusted Computer System Evaluation
7
Criteria) o "Libro Naranja ', cuya evolución, incluyendo también la evaluación de
la seguridad de las redes informáticas, fue el TNI (Trusted Network Interpretation)
o "Libro Rojo".
Como alternativa a los criterios americanos, algunos países europeos, en 1990,

establecieron un conjunto de criterios para evaluar la seguridad. Estos criterios,
basados en algunos conceptos del TSEC, variaban algunos enfoques.
Partiendo también de la base del TSEC, el gobierno canadiense desarrolló el
CTCPEC (Canadian Trusted Computer Product Evaluation Criteria).
En la década de los noventa, se funden todos los anteriores criterios en lo que se
conoce como Common Criteria que, en su versión de 1999, sirvió de base al
estándar ISOIIEC 15408.
7.2. SSE-CMM
El SSE-CMM (Systems Security Engineering-Capability Maturity Model)

presenta las características básicas de la ingeniería de seguridad de un sistema
informático. No describe proceso concreto. Solamente propone las mejores
prácticas para obtener una buena seguridad del sistema. La arquitectura básica
consta de tres categorías:
- Organización.
- Proyecto.
- Ingeniería de seguridad.
Y, siguiendo los criterios del CMM, presenta cinco niveles de seguridad:
- Seguridad mantenida de manera informal.

- Seguridad planificada y gestionada.
- Seguridad definida.
- Seguridad controlada cuantitativamente.
- Seguridad mejorada de forma continua.
El grupo de desarrollo del SSE-CMM divide las métricas en dos grandes

grupos:
Métricas de proceso. Medidas que pueden ofrecer evidencias de la madurez

de los procesos propuestos en el modelo.
Métricas de seguridad. Métricas para evaluar los atributos de seguridad
(confidencialidad, integridad, etc.) en un momento dado.
248 METRICAS DEL SOFTWARE
7.3. Métricas de eficacia de los algoritmos criptográficos
Para determinar estas métricas es necesario, en primer lugar, identificar los

atributos comunes a los algoritmos criptográficos. Los criterios comunes
propuestos son:
- Tipo de algoritmo (simétrico o asimétrico).

- Tipo de función (autentificación, firma digital, mensaje secreto, etc.).
- Longitud de la clave.
- Complejidad del algoritmo, en cuanto cifrado, descifrado y tratamiento de
la clave.
- Comportamiento ante los ataques (fuerza bruta, factorial, análisis
diferencial, etc.).
Algunas de las métricas son:
Longitud de la clave
Cuanto mayor es, más resistente es el algoritmo frente a un ataque de fuerza

bruta. Se expresa en número de bits de longitud de la clave. Cada bit que se añade a
la clave se duplica el número de intentos necesarios para descubrir la clave.
Número de pasos para realizar el cifrado
El número de pasos es la base de cálculo para las métricas relacionadas con el

tiempo de resolución en un procesador determinado. También permite hacer
estimaciones teóricas sobre las operaciones a realizar para descifrar un determinado
algoritmo.
Tiempo para atacar el cifrado
Se define como el menor tiempo posible para resolver la codificación en un

determinado procesador. Normalmente se expresa en Mtops (millones de
operaciones teóricas por segundo).
Fuerza del algoritmo
Es una medida subjetiva. Esta métrica propone una serie de niveles asociados a
las características de vulnerabilidad de un determinado algoritmo, como si se
pueden decodificar mediante unos recursos computacionales no disponibles o muy

caros, o si puede hacerse de una forma más cercana o barata. Los niveles
propuestos son:
Un algoritmo tiene nivel US (Unconditionally Secure) si, independientemente

del método utilizado para interceptar el contenido de un mensaje cifrado, no es
posible decodificar el contenido a partir de dicho contenido.
Un algoritmo tiene nivel CS (Computational Secure) si no se puede

decodificar usando análisis criptográfico sistemático en un período de tiempo
suficientemente corto como para que la información sea útil.
ccs
Un algoritmo tiene nivel CCS (Conditionally Computational Secure) si se
puede decodificar utilizando claves que no son lo suficientemente largas para
lcanzar el nivel CS.
Un algoritmo tiene nivel W (Weak) si puede decodificarse mediante un ataque

de fuerza bruta en un tiempo razonable de tiempo, p. e., 24 horas, y un coste
abordable, 200.000$.
Un algoritmo tiene un nivel VW (very weak) si puede decodificarse en un

tiempo corto, 8 horas, y un bajo coste, 2000$.
En la tabla 8.3 , se exponen las evaluaciones de los algoritmos de cifrado más

conocido.
Tabla 8.3. Algoritmos de cifrado y su evaluación.
7.4. Métricas de seguridad de red
La colección de medidas propuestas se dividen en básicas y de procesos:
Métricas básicas
Número de intentos de intrusión con éxito en un período de tiempo.

Número de intentos de intrusión sin éxito en un período de tiempo.
Número de virus detectados en la red en un período de tiempo.
Número de intrusiones detectadas en la red en un período de tiempo.
Número de violaciones de las reglas de seguridad detectadas en un período
de tiempo.
Número de intentos de saltarse las reglas de seguridad detectados en un
período de tiempo.
Porcentajes de palabras de claves de acceso caducadas.
Número de modificaciones sobre las claves de entrada modificadas por los
usuarios en un período de tiempo.
Evaluación de la inversión en monitorización de la seguridad de la red en
un período de tiempo.
Número de reglas de seguridad utilizadas.
Frecuencia de las revisiones de acceso.
Frecuencia de las actualizaciones contra virus.
Número de componentes de la red infectados en un período de tiempo.
Métricas de proceso
- Número de usuarios externos al sistema.

- Número de usuarios internos que salen a la red pública.
- Número deJirewalls por sistema que existen en la red.
- Porcentaje de claves de entrada adecuadas a la política propuesta por la
organización.
- Porcentaje de claves de entrada modificadas según la política de la
organización.
- Porcentaje de sistemas con información sensible.
[AAVV, 19931 AAVV, "Function Point Analysis", Datapro Computer
Systems Hardware & Software. Delran, USA, McGraw-Hill,
1993.
[AAVV, 19951 AAVV, "Measurement: Establishing a Point of
Departure", Datapro Computer Systems Hardware &
Software. Delran, USA, McGraw-Hill, 1995.
[AENOR, 19941 e UNE-EN ISO 9000-1. Normas para la gestion de la
calidad y el aseguramiento de la calidad. Parte 1: directrices
para su seleccion y utilizacion. AENOR. Madrid, 1994.
[AENOR, 19981 e UNE-EN ISO 9000-3. Gestión de la Calidad y
Aseguramiento de la Calidad. Parte 3: Directrices para la
aplicación de la Norma ISO 9001:1994 al desarrollo,
suministro, instalacion y mantenimiento de soporte lógico.
AENOR. Madrid, 1998.
[AENOR, 20001 e UNE-EN ISO 9000. Sistemas de gestión de la calidad.
Fundamentos y vocabulario. AENOR. Madrid, 2000.
[AENOR, 2000al UNE-EN ISO 9004. Sistemas de gestión de la calidad.
Directrices para la mejora del desempeño. AENOR. Madrid,
2000.
[Alcatel, 19951 e AAVV, "Modelo de madurez software. CMM: Capability
Maturity Model" Alcatel Standard Eléctrica, 1995.
[Alonso y Finn, Marcelo Alonso y Edward J. Finn. Funtamental
19671 Universiq Physics. Volume I. Mechanics. Addison Wesley
Publishing Companing Reading Massachusetts. 1967. Trad.
por Carlos Hernández y Víctor La Torre. Fondo Educativo
Interamericano, S.A. Méjico.1970.
[Amescua, 20011 Antonio de Amescua. SPICE. Ponencia presentada en el
XII Cursos de Verano de la UNED, Modelos y métodos para
la mejora de los procesos de desarrollo de sofware Ávila, Julio
2001. Documentación oficial de las Jornadas.
[Amescua, e Antonio de Amescua, Juan Lloréns y Ángel García.
Lloréns y García, "SPICE: un marco para la evaluación de procesos
19971 software",Calidad del Software 11, NOVATICA, Julio/Agosto
1997, no 128, pág. 33.
[Ashley y Nicholas Ashley y Paul Goodman. Principles of
Goodman, 19921 Function Point Analysis. Guidelines For Assessing The
Influence of System Characteristics.METKIT, London, July
1992.
[Ashley y Nicholas Ashley y Paul Goodman. Princíples of
Goodman, 1992bl Function Point Analysis. Student Booklet. METKIT,
London, July 1992.
[Ashley y Nicholas Ashley y Paul Goodman. Principies of
Goodman, 19941 Function Point Analysis. Slides With Teachers Notes.
METKIT, London, April 1994.
[Ashley y Papp, Nicholas Ashley y Gaspar Papp. Module IWIM What is
1992 ] Measurement? Student Notes. S.1. METKIT, London,
September 1992.
[Ashley y Papp, Nicholas Ashley y Papp Gaspar. Module IWIM, What Is
1992bl Measurement? Student Notes. METKIT, London, September
1992.
[Ashley y Papp, Nicholas Ashley y Gaspar Papp. Module IWIMSlides.
1992~1 METKIT, London, September 1992.
[Ashley, 19921 Nicholas Ashley. Module IFPA. Principles Of Function
Point Analysis. Bibliography. METKIT, London, July 1992.
[Ashley, 1992bl Nicholas Ashley. Module IFPA. Principles Of Function
Point Analysis. Glossary of Terms. METKIT, London, July
1992.
[Ashley, 1992~1 Nicholas Ashley. Module IFPA. Principles Of Function
Point Analysis. Set of Questions & Answers. METKIT,
London, July, 1992.
[Ashley, 1992dl Nicholas Ashley. Module IMMT, Measurement As A
Management Tool, Glossary of Abbreviations. METKIT,
London, June 1992.
[Ashley, 1992el Nicholas Ashley. Module IWIM. What Is Measurement?
Glossary of Abbreviations. METKIT, London, September,
1992.
[Ashley, 1992fl Nicholas Ashley. Module IWIM What Is Measurement?
Teacher Guide. METKIT, London, September, 1992.
[Ashley, 1992gl Nicholas Ashley. Specifying & Measuring Software
Quality. Glossary of Abbreviations. METKIT, London,
October 1992.
[Ashley, 1992hl Nicholas Ashley. Speczfying & Measuring Software
Quality. Module Advert. METKIT, London, October 1992.
[Ashley, 1992iI e Nicholas Ashley. Speczfiing & Measuring Software

Quality. Slides With Teacher Notes. METKIT, London,
October 1992.
[Ashley, 1992j1 e Nicholas Ashley. Speczfiing & Measuring Software
Quality. Student Notes. METKIT, London, October 1992.
[Ashley, 1992kl e Nicholas Ashley. Speczfiing & Measuring Software
Quality. Teacher Guide. METKIT, London, October 1992.
[Ashley, 199211 e Nicholas Ashley. Module IMMT, Measurement As A
Management Tool, Set of Questions & Answers. METKIT,
London, June 1992.
[Ashley, 19941 e Nicholas Ashley. Module IMMT. Measurement As A
Management Tool. Student Booklet. s.1. METKIT, London,
April 1994.
[Ashley, 1994bl e Nicholas Ashley. Module IMMT. Measurement As A
Management Tool. An Ovewiew of the Materials in the
Module IMMT. s.1. METKIT, London, April 1994.
[Ashley, 1994~1 Nicholas Ashley. Measurement As A Management Tool.
An Ovewiew of The Materials In The Module IMMT,
METKIT Module. METKIT, London, April 1994.
[Ashley, 1994dl e Nicholas Ashley. Module IFPA. Principles Of Function
Point Analysis. An Ovewiew of the Materials In The Module
IFPA. METKIT, London, April 1994.
[Ashley, 1994el Nicholas Ashley. Module IFPA. Principles Of Function
Point Analysis. Solution to Workshop Example. METKIT,
London, April 1994.
[Ashley, 1994fl e Nicholas Ashley. Module IFPA. Principles Of Function
Point Analysis. Teacher Guide. METKIT, London, April
1994.
[Ashley, 199481 Nicholas Ashley. Module IFPA. Principles Of Function
Point Analysis. Teacher Guidelines for Making Module
Interactive. METKIT, London, April 1994.
[Ashley, 1994hl Nicholas Ashley. Module IFPA. Principles Of Function
Point Analysis. Workshop Example. METKIT, London,
April 1994.
[Ashley, 199413 e Nicholas Ashley. Module IMMT, Measurement As A
Management Tool, Student Booklet, METKIT, London,
April 1994.
[Ashley, 1994j1 e Nicholas Ashley. Module IMMT, Measurement As A
Management Tool, Teacher Guidelines For Making Module
Interactive. METKIT, London, April 1994
[Ashley, 1994kl e Nicholas Ashley. Module IMMT, Measurement As A
Management Tool, Teacher Guide. METKIT, London,
April 1994
[Ashley, Papp y Nicholas Ashley, Papp Gaspar y Russell Meg. Module
Russell, 19921 IWIM. What Is Measurement?Slides with Teacher Notes.
METKIT, London, September, 1992.
[Bache y Bazzana,. Richard Bache y Gualtiero Bazzana. Software Metrics for
19931 Product Assessment. McGraw-Hill. England, 1993.
[Baker, 19791 e A. L. Baker y S. H. Zweben. The Use of Software
Science in Evaluating Modularity Concepts. IEEE
Transactions of Software Engineering, 5 . 1979. pp. 1 10-
120.
[Baker et al, l A. L. Baker et al. A Philosophy for Software
19901 Measurement. The Journal of System and Software, Volume
12, no. 3,1990 pp 227-281.
[Banks, 19891 e Jeny Banks. Principies of Quality Control. John Wiley
& Sons, 1989.
[Boehm, 19811 e Bany W. Boehm. Software Engineering Economics.
Prentice Hall, 198 1 .
[Brooks, 19951 Frederik P. Brooks. The mythical man-month. Essays on
Software Engineering anniversary edition.Addison-Wesley,
1995.
[Carrasco, 19971 l José Carrasco. "Técnicas de aseguramiento de la calidad
del software", Monografía, Calidad del Software 1,
NOVATICA enerolfebrero 1997, no 125, pp. 62-66.
[Castell y e Núria Castell y Ángels Hernández. "Filtrado de
Hernández, 19971 Especificaciones de Software escritas en lenguaje Natural",
Monografía, Calidad del Software 1, NOVATICA,
enerolfebrero 1997, no 125, pp. 31-46.
[Cerrada, 200 11 e José Antonio Cerrada Somolinos. Introducción.
Conceptos de Mejora de los Procesos. Ponencia presentada
en el XII Cursos de Verano de la UNED, Modelos y métodos
para la me-jora de los procesos de desarrollo de sofware Ávila,
Julio 2001.
[Clementi, 19971 Frangois Clementi. SPICE. 1 Jornada sobre Calidad del
Software, organizada por el grupo de Trabajo sobre Calidad
del Software de la Asociación de Técnicos de Informática
(ATI), noviembre 1997. Documentación oficial de las
Jornadas.
[Cuevas y Gonzalo Cuevas y Vicente Martínez. "Infraestructura y

Martínez, 19971 funciones necesarias en una organización para la
implantación de un proyecto de mejora continua del proceso
del software", monografía, Calidad del Software 1,
NOVATICA, julio/agosto 1997, no 128, pp.3-7.
[Curran y Sanders, Eugene Curran y Joc Sanders. Software Quality. A
19941 Framework for Success in Software Development and
Support. Cornwall, Addison- Wesley Publishers, 1994.
[Curtis et al., B. Curtis et al. Measuring The Psychological
19791 Complexity of Software Maintenance Tasks With Halstead
and McCabe. IEEE Transactions of Software Engineering, 5.
1979. pp. 96-104.
[Defensa, 19941 Ministerio de Defensa. Requisitos OTAN de
aseguramiento de la caliad para el desarrollo software.
PECAL 150-94. 1994.
[DeMarco, 19821 Tom DeMarco. Controlling Software Proyects:
Management, Measurement and Estimation. Englewood
Cliffs, N. J. Prentice Hall, 1982.
[Dunn, 19941 Robert H. Dunn. "Quality Assurance", Encyclopedia of
Software Engineering, John Wiley & Sons, 1994, pp. 941-
958.
[Eco, 19971 Umberto Eco. ¿Cómo se hace un tesis? Técnicas y
procedimientos de investigación, estudio y escritura.
Barcelona, Editorial Gedisa,1997.
[Fenton, 19921 Norman E. Fenton. Software Metrics. A Rigorous
Approach. London, Chapman & Hall, 1992.
[Fenton y Norman E. Fenton y Shari Lawrence Pfleeger. Software
Pfleeger,1997] Metrics. A Rigorous & Practical Approach. Boston, PWS
Publishing Company, 1997.
[Fenton y Norman E. Fenton y Shari Lawrence Pfleeger. Software
Pfleeger,2002] Metrics. A Rigorous & Practical Approach. Boston, PWS
Publishing Company, segunda edición. 2002.
[Freixanet, Cañas Josep R. Freixanet, Eduard Cañas y Enric Roca. "Plan
y Roca, 19971 de Métricas del Software: aproximación a su diseño",
Monografía, NOVATICA, Julio/agosto, 1997, no 128, pp.8-
14.
[Gibbs, 19941 W. Wayt Gibbs. "La crisis crónica de la programación",
Investigación y Ciencia, Tendencias en Informática, pp. 72-
81, noviembre, 1994.
[Gómez, Bernaras A. Gómez, A. Bernaras, M. Emaldi y F.J. Ruiz. "La
y otros, 19971 mejora del proceso de Software en I+D", Monografía, Calidad
del Software 1, NOVATICA, enerolfebrero 1997, no 125, pp.
22-30.
[González, 19971 Julio González Sanz. "La Calidad del Software", Física y
Sociedad. Oviedo, Madrid, Gráficas SUMMA, Número 8,
Otoño 1997, pp. 32-36.
[González, 1997b3 Julio González Sanz. "La nueva versión de la norma ISO
9000-3, guía para la aplicación de ISO 9001: 1994",
enerolfebrero , 1997, no 125, pp. 5-9.
[Gonzalo, 20011 Agustín Gonzalo Cuevas. Estructura del Modelo de
Madurez de la Capacidad. Ponencia presentada en el XII
Cursos de Verano de la UNED, Modelos y métodos para la
mejora de los procesos de desarrollo de sofware Ávila, Julio
2001. Documentación oficial de las Jornadas.
[Granja, 19971 Juan Carlos Granja Álvarez. "Calidad del Software 1",
Monografía, NOVATICA, enero /febrero, 1997, no 125, p. 3.
[Hernández, Juan Francisco Hdez. Ballesteros. El papel de las
20021 métricas en el aseguramiento de la calidad del software.Tesis
Doctoral. E.T.S.I.1, UNED, noviembre, 2002.
[Hernández, Juan Francisco Hdez. Ballesteros. "La ingeniería del
19981 software como solución a la crisis de la programación". El
Día, abril de 1998.
[Huecas, Mañas y Gabriel Huecas, José. A. Mañas y Tomás Robles.
Robles, 19971 "Métricas de Cobertura técnicas de descripciones formales",
Monografía, Calidad del Software 11, NOVATICA, julio1
agosto 1997, 11'128, pp. 16-23.
[Halstead, 19771 M.H. Halstead. Elements of Software Science. Elsevier
North-Hollad. 1977.
[IFPUG, 19941 International Function Point Users Group. Function
Point Counting Practices Manual, Release 4.0, Fourth
Release, Atlanta, Georgia, January 1994.
[IFPUG, 1994 b] International Function Point Users Group. Function
Point Counting Practices: Case Studies, Case Study 1,
Release 1.0, First Release, Atlanta, Georgia, July 1994.
[Inín, 19971 M" Luisa Inín. "Modelo de madurez: formalismo o
creatividad", Calidad del Software 1, NOVATICA,
Enerolfebrero, 1997, no 125, pp.59-61.
[ISO, 19981 ISO/IEC TR 15504-1. Information technology -Sqftware

process assessment - Part:l Concepts and introductoiy
guide. ISO/IEC. Suiza, 1998.
[ISO, 1998bl ISO/IEC TR 15504-2. Information technology -Software
process assessment - Part.2 A reference model for processes
andprocess capability. ISOIIEC. Suiza, 1998.
[ISO, 1998~1 ISO/IEC TR 15504-3. Inforrnation technology -Software
process assessment - Part:3 Performing un assessment.
ISO/IEC. Suiza, 1998.
[ISO, 1998dl ISO/IEC TR 15504-4. Inforrnation technology -Software
process assessment - Part:4 Guide to performing
assessment. ISO/IEC. Suiza, 1998.
[ISO, 1998el ISO/IEC TR 15504-6. Information technology -Software
process assessment - Part:6 Guide to competency of
assessors. ISO/IEC. Suiza, 1998.
[ISO, 1998fl ISO/IEC TR 15504- 7. Information technology -Software
process assessment - Part: 7 Guide for use in process
inprovement. ISO/IEC. Suiza, 1998.
[ISO, 199881 ISO/IEC TR 15504-8. Information technology -Software
process assessment - Part:8 Guide for use in determining
suppliler process capability. ISOIIEC. Suiza, 1998.
[ISO, 1998hl ISO/IEC TR 15504-9. Information technology -Software
process assessment - Part:9 Vocabulaiy. ISO/IEC. Suiza,
1998.
[ISO, 20011 ISO/IEC 9126-1. Software engineering - Product
quality - Part: 1 Quality model. ISOIIEC. Suiza, 2001.
[Jones, 20001 Capers Jones. Software Assessments, Benchmarks, and
Best Practices. 2000.
[Jones, 19781 Capers Jones. Measuring Programming Quality and
Productivity. IBM Systems Journal, Volume 17, no 1, 1978.
[Jones, 19881 Capers Jones. A Short History of Function Points and
Features Points. Software Productivity Reseach, Inc.
Cambrige, Mass, 1988.
[Jones, 199 11 Capers Jones. Applied Software Measurement: Assuring
Productivity and Quality, McGraw Hill, New York, 1991.
[Jones, 19931 e Cliff Jones. Conference-London to analyze the Future
Direction o f Software. Abril 1993. Actas de las conferencias.
Disponible en http://www.comlab.ox.ac.uk~archive.
[Juran, 19511 e J. M. Juran. Quality Control Handbook, Third Edition.

McGraw-Hill Book Company, New York. (trad. española de
José María Vallhorant Bou. Editorial Reverté, S.A., 1990).
[Kan, 20031 Stephen H. Kan. Metrics and Model in Software
Engineering. Segunda edición. Pearson Education, Inc.
Boston . 2003.
[Kugler, 19971 e Hans-Jürgen Kugler. "Mejora de los procesos de
Software: el modo de mantenerse por delante en calidad",
Monografía, NOVATICA, enerolfebrero, 1997, no 125, pag.
4.
[Longstreet e David H. Longstreet y Raffaela Ibba. " Fundamentos del
Ibba, 19961 análisis de puntos de funcionalidad", Systems Development
Management Journal. Agosto, 1996.
[Longstreet e e David H. Longstreet y Raffaela Ibba. "Puntos de
Ibba, 1996bl Funcionalidad Paso a Paso", Systems Development
Management Journal.Agosto, 1996.
[Lundquist, 19961 Gordon Lundquist. Guidelines to Software Measurement.
Release 1.1. International Function Point Users Group,
1996.
[MAP, 19911 Ministerio para las Administraciones Públicas. Plan
general de garantía de calidad aplicable al desarrollo de
equipos lógicos, Colección INFORMES Y DOCUMENTOS,
Secretaría General Técnica, Instituto Nacional de
Administración Pública, Madrid, 1991.
[Marciniak, 19941e John J. Marciniak. "Software Engineering a Historical
Perspective", Encyclopedia of Software Engineering, John
Wiley & Sons, 1994. pp. 1176-1182.
[Marciniak, e John J. Marciniak. "Total Quality Management in
1994al Software Development", Encyclopedia of Software
Engineering, John Wiley & Sons, 1994. pp. 1364 -1376.
[McCall, 19941 James A. McCall. "Quality Factors", Encyclopedia of
Software Engineering, John Wiley & Sons, 1994, pp. 959-
969.
[Minguet, 19961 e José M" Minguet Melián. Garantías de Calidad del
Software. Ponencia presentada en Cursos de Verano, Ávila,
Julio 1995. Documentación oficial de las Jornadas.
[Morales, 20021 Morales, L. Mejora de los procesos de software en el

marco del Capability Maturity Model (CMM) . Ponencia
presentada en las VI1 Jornadas sobre Innovación y Calidad del
Software. Asociación de Técnicos de Informática. Palma de
Mallorca, Julio 2002. Documentación oficial de la Jornadas.
[Paulk et al, 19931 Mark C. Paulk et al. Capability Maturity Model for
Software, Version 1.1 , CMUiSEI-93-TR-24. Software
Engineering Institute. 1993.
[Paulk et Mark C. Paulk et al. Key Practices of Capability

al, 1993bl Maturity
Model, Version l .1 , CMU/SEI-93-TR-24. Software
Engineering Institute.1993.
[Paulk et al, Mark C. Paulk et al. Modelo de madurez de capacidad
1993~1 para el software, versión l .1 Modelos y métodos para la
mejora de los procesos de desarrollo de software
(Documentación de referencia CMM V 1.1: CMUíSEI-93-
TR-24 y CMCr/SEI-95-TR-25, nivel 2), Software
Engineering Institute. 1993.Traducido por SOMEPRO.
Documentación aportada en los, XII Cursos de Verano,
Universidad Nacional de Educación a Distancia.
[Paulk et al, M. Paulk, C. V. Weber & B. Curtis, The capability
19951 maturity
model. Guidelines for improving software process, Reading,
Addison-Wesley, 1995.
[Pressman, 19931 Roger S. Pressman. Software Engineering: A
Pactitioner's Approach. 3" Edición. McGraw-Hill, Inc. 1993.
(Trad. por Carlos Cervigon Ruckaüer).
[Quesada, 19871 Quesada Herrera, José. Redacción y presentación del
trabajo intelectual: tesinas, tesis doctorales, proyectos,
memorias, monografias. Madrid, Paraninfo S.A, 1987.
[Rakitin, 19971 Steven R. Rakitin. Software verification and validation:
a practitioners's guide. Artech House, Inc. 1997.
[Ramos, 19971 Isabel Ramos. "Modelos dinámicos para la gestión de
proyectos software: un nuevo enfoque", Monografía, Calidad
del Software 1, NOVATICA, enerolfebrero 1997, no 125, p.
53.
[Real, 20011 Real Academia Española de la Lengua. Diccionario de la
lengua española. Edición 22. Madrid, 2001.
[Rementeria, Santiago Rementeria. " Eficacia de la gestión del
19971 software en un contexto organizativo amplio", Monografía,
NOVATICA, enerolfebrero, 1997, no 125, pp.25-30.
[Roberts, 19791 Fred S. Roberts. Measurement Theory with Aplications to
Decisionmaking, Utility, and the Social Sciences.
Encyclopedia of Mathematics and its Applications. Addison
Wesley Publishing Company, 1979.
[Rodríguez, Garví M.L. Rodríguez, E. Garví y J.C Granja. " Calidad y
y Granja, 19971 reusabilidad del Software: estudio de la funcionalidad",
enerolfebrero 1997, no 125, pp. 67-68.
[Sánchez, Pickin C. Sánchez, S. Pickin y otros. "La calidad del producto
y otros, 19971 en los sistemas distribuidos", Monografía, Calidad del
Software 1, NOVATICA, enerotfebrero 1997, no 125, pág.47.
[Sanchis, 19981 Francisco Sanchís Marco.Evaluación y gestión de
proyectos informáticos. Servicio de publicaciones EUINPM,
1998.
[Salvat, 19961 AA.VV. Enciclopedia Salvat Universal, Barcelona.
Editorial Salvat, 1996.
[Sanders y Curran, Joc Sanders y Eugene Curran. Software Quality. A
1994 ] Framework for Success in Software Development and
Support, Centre for Software Engineering, Dublin, Addison
Wesley Publishing Company, 1994.
[Sebastián y col., Miguel Ángel Sebastián Pérez, Vicente Bargueño Fariñas
19941 y Vicente Novo Sanjurjo. Gestión y Control de calidad.
Cuadernos de la UNED. Madrid. UNED. 1994.
[St-Pierre et al, Denis St-Pierre et al. Full Function Point: Counting
19971 Practices Manual. T.R. 1997-04. Software Engineering
Management Research Laboratory and Software Engineering
Laboratory in Applied Metrics. Montreal, 1997
[SEI, 20021 AAVV, Capability Maturity Model Integration for
Software Engineering (CMMI), Versionl . l . CMU/SEI-2002-
TR-028. Software Engineering Institute. Agosto 2002.
[SEL, 19921 Software Engineering Laboratory. Collected Software
Engineering Papers. Vol.: X, SEL-92-003, November, 1992,
pág 164.
[Sobrino, 19971 Carlos Sobrino Sánchez. Gestión de calidad. Aplicación a
la industria del software. I Jornada sobre Calidad del
Software, organizada por el grupo de Trabajo sobre Calidad
del Software de la Asociación de Técnicos de Informática
(ATI), noviembre 1997. Documentación oficial de las
Jornadas.
[Sommerville, e Ian Sommerville. Software Engineering, McGraw Hill,

19921 1993.
[Soluziona, 200 11 AA.VV.La Norma ISO 9001 del 2000. Edicions Gestió
2000, Barcelona, 2001.
[Symons, 19881 e Symos C.R. Function point analysis: Difficulties and
improvementes, IEEE Transactions on Software
Engineering, pp.2-11, 1988.
[Tomayko, 19941 James E. Tomayko. "Milestones in Software
Engineering", Encyclopedia of Software Engineering, John
Wiley & Sons, 1994. pp. 687-697.
[UNED vídeo, e Video La Calidad del Software, Programación TV.
19961 Educativa 95/96, Programa 081, emisión 27 de mayo de
1996, UNED, Centro de Diseño y Producción de medios
audiovisuales.
[Villena, 19971 e Villena, Leonardo."La metrología, la Calidad y las
PYMES", Física y Sociedad. Oviedo, Madrid, Gráficas
SUMMA, Número 8, Otoño 1997, pp. 10-15.
[Visconti, Marcello Visconti et al. "Experiencia con un modelo de
Antimán y Rojas, madurez para el mejoramiento del Proceso de Aseguramiento
19971 de Calidad del Software", Monografía, Calidad del Software 1,
NOVATICA, enerolfebrero, 1997, no 125, pp. 18-21.
[Vollman y Thomas Vollman y Juan Garbajosa. "Soporte prestado

Garbajosa, 19971 por herramientas CASE y estándares al aseguramiento del
producto software", Monografía, Calidad del Software 1,
NOVATICA, enero/ febrero, 1997, no 125, pp. 14-17.
[Wang, Trujillo y e Y.Wang, J. Trujillo y M. Palomar. " Una métrica para la
Palomar, 19971 capacidad de prueba del Software", Monografía, Calidad del
Software 1, NOVATICA, enerolfebrero, 1997, no 125, pp.
10-13.
[Webster, 19961 e Bruce F. Webster. "The Real Software Crisis". BYTE,
january 1996.
[Yourdon, 19961 e Edward Yourdon. "Lo bueno..¿es lo mejor?", Byte, no
22, octubre 1996. pág. 154.
[Zuse, 1991 Horst Zuse. Software Complexity and Methods.
DeGruyter Publisher. Berlin-New York, 1991.

Libro La Calidad Del SW y Su Medida

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Libro La Calidad Del SW y Su Medida

Enviado por

Direitos autorais:

Formatos disponíveis

Jesús M.

" Miriguet Melian

3wn Francisco HernBndez B a i l e t e ~ s

JUAN FRANCISCO HERNÁNDEZ BALLESTEROS

O EDITORIAL CENTRO DE ESTUDIOS RAMON ARECES, S.A.

Impreso en España 1 Printed in Spain

CAPÍTULO 2: LA MEDIDA DE LA CALIDAD DEL SOFTWARE ...............63

3.3. Las reglas de estimación de De Marco.................................................... 70

CAPÍTULO 3: NORMALIZACI~NY CERTIFICACI~N:

10.4. Realización del producto o servicio ...................................................... 116

CAPÍTULO 4: MODELOS. METODOLOGÍAS Y ESTÁNDARES:

CAPITULO 5: MÉTRICAS PARA MODELOS CONCEPTUALES ............ 153

2.2. Métricas de Moody ................................................................................. 157

CAP~TULO6: EL ANÁLISIS DEL PUNTO FUNCIÓN ............................... 165

3. Más allá del Análisis del Punto Función tradicional ..............................................192

CAPITULO 7: LA NORMA ISOIIEC 9126 Y LA MEDIDA

4.2.2. Tasar .............................................................................................. 216

CAPITULO 8: MÉTRICAS DEL SOFTWARE ........................................ 221

AENOR Asociación Española de Normalización y

MAP Ministerio de Administraciones Públicas.

Los programas informáticos, el software, es el valor añadido de mayor

Nos encontramos ante un reto, uno más en esta civilización en constante

Ricardo Melchior Navarro

El resultado final del proceso creativo humano en la industria tradicional se

' Miguel de Cervantes Saavedra. Don Quijote de la Mancha

LA CALIDAD DEL SOFTWARE

1. EL PAPEL DE LA CALIDAD EN EL DESARROLLO DEL SOFTWARE

1.1. ¿Por qué calidad?

Tanto en los medios de comunicación escritos y audiovisuales como en las

los potenciales clientes para mantenerse en el mercado. Incluso la Comunidad

o La calidad es un factor competitivo.

1.2. La calidad en la industria del software

La exigencia de la calidad no es sólo para los productos materiales, también lo

"Si no mantenemos nuestro ímpetu en el aspecto de la calidad, los

"El crecimiento no es nuestro objetivo principal. Nuestro objetivo ha de ser

Las empresas de software se ven obligadas a implantar modelos y metodologias

La medida del software se considera, igualmente, una necesaria consecuencia de

"En última instancia, las expectativas de Europa descansan sobre el potencial

2.1. Definición de Calidad

Con objeto de estudiar la medida de la calidad del software se hace

Según María ~ o l i n e rcalidad,

o Grado en el que un conjunto de características inherentes cumple con los

o El proceso de identificar, aceptar, satisfacer y superar constantemente las

En el caso del software y su proceso de creación, consideraremos como

2.2. Tipos de Calidad

En los ámbitos industriales en general, y en los informáticos en particular,

Calidad necesaria. Es la calidad que pide el cliente y la que le gustaría recibir.

Calidad programada. Es el nivel de calidad que se propone obtener el

Calidad realizada. Es la calidad que se puede obtener debido a las personas

Figura 1.1. Los tres tipos de calidad.

2.3. Rasgos inherentes a la calidad

Algunos de los rasgos más sobresalientes de la calidad son:

0 Implica la mejora continua de la productividad y de la competitividad.

Las consecuencias de la implantación de un sistema de calidad son:

o Mejora de la imagen de la empresa.

2.4. Dimensiones de la calidad

El modelo que representa la calidad se configura mediante un conjunto de

Son las características operativas principales de un producto, que son

La diferenciación se refiere a las características secundarias del producto, las

Se denomina fiabilidad a la probabilidad de que un producto no falle en un

La conformidad es el grado en que el diseño y las prestaciones del producto

Es la medida de la vida del producto. En esta medida de carácter técnico