Libro La Calidad Del SW y Su Medida PDF

Jess M.
" Miriguet Melian

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

JESS M" M ~ G U E T MELIN
Profesor Titular de Lenguajes y Sistemas Informticos (UNED)
JUAN FRANCISCO HERNNDEZ BALLESTEROS

Director del Servicio de Informtica 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
ningn procedimiento electrnico o mecnico, incluyendo fotocopia, grabacin
magntica o cualquier almacenamiento de informacin y sistema de recupera-
cin, sin permiso escrito de Editorial Centro de Estudios Ramn Areces, S. A.
O EDITORIAL CENTRO DE ESTUDIOS RAMON ARECES, S.A.

Tomas Bretn, 21 - 28045 Madrid
ISBN: 84-8004-611-2
Deposito legal: M. 44.635-2003
Impresin por:
LAVEL, S.A.
Humanes (Madrid)
Impreso en Espaa 1 Printed in Spain

CAPTULO 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. Definicin 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 caractersticas de la calidad del software ......................................... 32
2.6. El Declogo de la calidad ....................................................................... 33
3. Estados de desarrollo de la calidad ................................................................ 37
3.1. Inspeccin ................................................................................................ 37
3.2. Control de la calidad ............................................................................... 38
3.3. Aseguramiento de la calidad ................................................................... 39
3.4. Gestin de la Calidad Total .................................................................... 40
3.5. Evolucin del concepto de calidad .........................................................41
4. Aproximacin histrica................................................................................... 41
4.1. Artesanos y obreros ................................................................................. 42
4.2. Los orgenes ............................................................................................ 42
4.3. La Revolucin Insustrial: la inspeccin ................................................. 43
4.4. De 1900 a 1950: la era del control estadstico ....................................... 44
4.5. El aseguramiento de la calidad: aparecen las normas ............................ 46
4.6. El presente: la gestin de la Calidad Total .............................................. 47
4.7. La industria del software y la industria tradicional ................................. 48
4.8. Orgenes del aseguramiento de la calidad del software .......................... 49
4.9. Las normas de calidad del software ......................................................... 52
4.10. Anlisis de los atributos ......................................................................... 53
4.1 1. Los modelos ........................................................................................... 53
4.12. El futuro .................................................................................................. 55
5. Concepciones errneas y paradigrnas de la calidad ...................................... 56
6. Costes de la calidad ........................................................................................ 57
6.1. Costes de prevencin ............................................................................... 58
6.2. Costes de evaluacin ................................................................................ 59
6.3. Costes de la no calidad ............................................................................. 59
6.4. Relacin costeheneficio .......................................................................... 59
6.5. La Regla Federal Express ........................................................................61
CAPTULO 2: LA MEDIDA DE LA CALIDAD DEL SOFTWARE ...............63

1. Introduccin.................................................................................................... -63
2. Necesidad de la medida del software.............................................................. 65
2.1. La medida como elemento de mejora metodolgica .............................. 65
2.2. La medida y el conocimiento................................................................... 66
2.3. Importancia de la medida ......................................................................... 66
3. Estimacin .......................................................................................................
68
. .
3.1. Definicion y problemtica........................................................................
68
3.2. Los mtodos de estimacin ...................................................................... 69
LA CALIDAD DEL SOFTWARE Y SU MEDIDA 11
3.3. Las reglas de estimacin de De Marco.................................................... 70

3.4. Evaluacin de las estimaciones ............................................................... 71
4. Estimacin 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. Teora general de la medida ..................................................................... 79
5.3. Escalas ..................................................................................................... 82
6. Aproximacin histrica .................................................................................. 83
6.1. Los orgenes ............................................................................................ 83
6.2. Maurice Halstead...................................................................................... 83
6.3. El control de flujo de programa ............................................................... 85
6.4. Sistemas de diseo .................................................................................. 86
6.5. Costes y esfuerzos ................................................................................... -87
7. La medida del software .................................................................................. 89
7.1. Marco terico ........................................................................................... 89
8. La norma ISOIIEC 9126 ................................................................................ 93
CAPTULO 3: NORMALIZACI~NY CERTIFICACI~N:

NORMA ISO 9001 :2000 ....................................................................................... 95
1.
. . . .
Normalizacion y certificacion........................................................................ 96
2. Terminologa 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. Planificacin 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 certificacin ............................................................................... 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 gestin de la calidad ............................................................. 113
9.3. Responsabilidad de la direccin ............................................................. 114
9.4. Gestin de los recursos ............................................................................ 114
9.5. Realizacin del producto o servicio ........................................................ 114
9.6. Medicin, anlisis y mejora .....................................................................115
10. La norma ISO 9004:2000............................................................................. 115
10.1. Introduccin a la norma ......................................................................... 115
10.2. Responsabilidad de la direccin ............................................................ 116
. .
10.3. Gestion de los recursos .......................................................................... 116
10.4. Realizacin del producto o servicio ...................................................... 116

10.5. Medicin, anlisis y mejora .................................................................. 117
11. La calidad. su aseguramiento y medida segn la norma
ISO 9001:2000 e ISO 9000-3:1997 ..................................................................... 117
CAPTULO 4: MODELOS. METODOLOGAS Y ESTNDARES:

ESTRATEGIAS PARA ALCANZAR LA CALIDAD ..................................... 121
1. Modelos. metodologas y estndares ........................................................... 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 caractersticas comunes .................................................... 128
2.3. La calidad. su aseguramiento y medida segn el modelo....................... 131
3. Modelo BOOTSTRAP................................................................................. 134
3.1. El concepto Bootstrap. del diagnstico a la solucin ............................. 134
3.2. Prctica 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. Metodologa MTRICA V. 3 ...................................................................... 147
5.1. MTRICA. una metodologa basada en proceso ................................... 149
CAPITULO 5: MTRICAS PARA MODELOS CONCEPTUALES ............ 153

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

2.3. Mtricas de Piattini ................................................................................. 159
3. Mtricas para modelos conceptuales orientados a objetos ........................... 159
3.1. Mtricas de Brito e Abreu y Carapuca.................................................... 159
3.2. Mtricas de Chindamber y Kemerer ...................................................... 161
3.3. Mtricas de Lorenz y Kidd ...................................................................... 162
3.4. Mtricas de gnero y al ............................................................................ 163
CAP~TULO6: EL ANLISIS DEL PUNTO FUNCIN ............................... 165

1. Introduccin al Anlisis del Punto Funcin ................................................ 165
1.1. La propuesta de Albrecht: ventajas e inconvenientes ............................. 165
2. El Anlisis del Punto Funcin paso a paso .................................................. 168
2.1. Determinar el tipo de conteo a realizar .................................................. 168
2.2. Identificar los lmites en los que se aplicar el conteo de
los Puntos Funcin ................................................................................... 168
2.3. Identificacin de los Ficheros Lgicos Internos (FLI) .......................... 169
2.4. Identificacin de los Ficheros de Interfaz Externo (FIE) ....................... 170
2.5. Clasificar la complejidad de los ficheros lgicos y determinar
su contribucin ....................................................................................... 171
2.6. Conteo de los tipos de funcin asociado a transacciones .......................... 174
2.6.1. Identificacin de Entradas Externas ........................................................174
2.6.2. Identificacin de Salidas Externas................................................ 176
2.6.3. Identificacin de Cuestiones Externas ........................................ 177
2.6.4 Clasificar la complejidad de las transacciones identificadas y su
contribucin .................................................................................. 179
2.6.5. Clculo del valor de los Puntos Funcin sin ajustar .................... 185
2.6.6. Clculo del valor del factor de ajuste ........................................... 187
2.6.7. Clculo de los Puntos Funcin ajustados .................................... 188
3. Ms all del Anlisis del Punto Funcin tradicional ..............................................192
CAPITULO 7: LA NORMA ISOIIEC 9126 Y LA MEDIDA

DE LA CALIDAD .............................................................................................. 193
1. Descomponer un problema para buscar la solucin ................................ 193
1.1. La descomposicin jerrquica 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 aplicacin informtica.
Ejemplo prctico ........................................................................................... 211
4.1. Definicin de requisitos de calidad ........................................................ 211
4.2. Preparar la evaluacin .............................................................................. 213
.
4.2.1. Seleccion de mtricas .................................................................... 214
r
4.2.2. Tasar .............................................................................................. 216

4.2.3. Valoracin del criterio .................................................................. 217
4.2.4. Obtencin de medidas ................................................................... 219
CAPITULO 8: MTRICAS DEL SOFTWARE ........................................ 221

1. Mtricas e indicadores de la productividad................................................. 221
1.1. Medida del tamao ................................................................................... 222
1.2. Medida de la productividad .................................................................... 227
2. Indicadores y mtricas 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 mtrica de Henry y Kafura ................................................................ 237
5. Mtricas para modelos de datos ................................................................... 240
5.1. Mtricas a nivel de tabla ......................................................................... 240
5.2. Mtricas a nivel de estrella ..................................................................... 240
5.3. Mtricas 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. Clasificacin de los mtodos .................................................................. 243
6.2. Algunos mtodos de evaluacin ............................................................. 244
7. Medida de seguridad .................................................................................... 245
7.1. Un poco de historia ................................................................................. 246
7.2. SSE-CMM ............................................................................................... 247
7.3. Mtricas de eficacia de los algoritmos criptogrficos ............................ 248
7.4. Mtricas de seguridad de red .................................................................. 250
LISTA DE SIGLAS
AENOR Asociacin Espaola de Normalizacin y

Certificacin.
APF Anlisis del Punto Funcin.
ASA American Standards Association.
AS1 Anlisis del Sistema de Informacin.
ATT American Telephone & Telegraph.
AWS American War Standards.
CE Cuestiones Externas.
CEN Comit Europeo de Normalizacin.
CIS Construccin del Sistema de Informacin.
CMM Capability Maturity Model.
COCOMO COnstructive COst Model.
DFP Punto Funcin del desarrollo del proyecto.
DSI Diseo del Sistema de Informacin.
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 Lgico Interno.
GQM Goal Question Metrics.
GSC Caractersticas Generales del Sistema.
IAS Implantacin y Aceptacin del Sistema.
IBM International Business Machines.
IEC International Electrotechnical Commission.
IECISA Informtica El Corte Ingls.
IEEE Institute of Electrical and Electronic Engineers.
IFPUG International Function Point Users Group.
IMT Inspeccin Media Total.
ISO International Organization for Standards.
JAN Joint Army-Navy Standard.
JTC Joint Technical Committee.
LCMS Lmite de Calidad Media de Salida.
LOC Lines Of Code.
1X LISTA DE SIGLAS
MAP Ministerio de Administraciones Pblicas.

METKIT Metrics Educational ToolKIT.
MIT Massachusetts Institute of Technology
MSI Mantenimiento de Sistemas de Informacin.
MTTF Mean Time to Faillure.
NASA National Aeronautics and Space Administration.
OTAN Organizacin del Tratado del Atlntico Norte.
PSI Planificadn de Sistemas de Informacin.
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 Funcin sin Ajustar.
VAF Valor del Factor de Ajuste.
WG Working Group.
La sociedad actual reclama productos y servicios informticos que den
respuesta a sus necesidades, requisitos cada vez ms exigentes en un mercado
globalizado de altsima competitividad. La respuesta de las empresas debe
sustentarse en el disciplinado ejercicio de metodologas que tengan en la calidad un
instrumento eficaz para responder a este desafo.
Los programas informticos, el software, es el valor aadido de mayor

trascendencia en las industrias de principios del siglo XXI. Sin este componente el
instrumental ms sofisticado o el ordenador ms complejo carece de valor,
relegado a un amasijo de cables y circuitos electrnicos sin utilidad.
La ingeniera del software como disciplina nacida hace casi cuarenta aos como
respuesta a la llamada "crisis de la programacin" asume las estrategias de las
ingenieras tradicionales y trata de utilizarlas adaptndolas a la fabricacin de
programas para ordenador. Esta misma ingeniera que busca en modelos de calidad
tradicional su ms fiel aliado debe proseguir en la mejora continua de sus procesos.
Dentro de esta mejora se encuentra, sin duda, la obtencin de medidas adecuadas a
las entidades y atributos que le son propios. Medir implica conocer y conocer
permite manipular aquellos factores de inters en la bsqueda de la excelencia.
Medir la calidad es, por tanto, un requisito imprescindible en las nuevas
metodologas del software y un factor estratgico en el sector de la nueva
economa.
Nos encontramos ante un reto, uno ms en esta civilizacin en constante

cambio, en constante evolucin. Un reto que, sin duda, exige un decidido apoyo a
la investigacin y a las tecnologas de la informacin y las comunicaciones. La
divulgacin cientfica es un camino seguro en la consecucin de un conocimiento
global. Nos permite el intercambio de informacin, 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 superacin que no son ms 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 fsico, electrodomstico, aeroplano, automvil etc. Este
concepto desaparece en la ingeniera del software cuyo principal producto es un
ente inmaterial, del cual slo apreciamos sus resultados al ser ejecutado sobre un
soporte fsico, el ordenador. Este es un hecho de capital importancia que
condiciona la concepcin de la ingeniera del software. Bajo esta consideracin 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 creacin del
programa informtica.
La medida de un proceso productivo o de los atributos de un producto
elaborado, es en la actualidad una actividad estratgica en las empresas de
cualquier sector productivo. La ingeniera del software requiere y exige de estas
medidas no limitndose a la implantacin de metodologas aunque stas abarquen
todo el proceso productivo de una aplicacin informtica e incluso su posterior
mantenimiento. Medir es necesario, mas all, es imprescindible para la ingeniera
del software igual que lo es para cualquier otra ingeniera. Medir, y en concreto
medir la calidad, permite obtener informacin sobre atributos cuyo conocimiento
aportan ventajas estructurales a aquella empresa o profesional que los poseen
permitiendo la ejecucin de acciones correctoras sobre datos objetivos y
disfunciones perfectamente identificadas. La medida del software nos proporciona
valiosa informacin sobre el proceso de desarrollo, los productos resultantes o los
recursos utilizados. Hacer uso adecuado de esa informacin nos brinda la mejora
intrnseca del propio proceso creativo modificndolo si fuera preciso.
El software, la ingeniera del software, modelos de desarrollo, metodologas y la
medida de entidades se encuentran ntimamente unidos y deben colaborar en la
obtencin de productos y servicios de calidad.
En el captulo 1 se introducirn los conceptos bsicos de calidad en la industria
tradicional y su traslado a la industria del software. Se revisar la evolucin del
concepto de calidad a lo largo de la historia y se comprobar el atraso histrico
que, en trminos de calidad, tiene la fabricacin del software con respecto al resto
' Miguel de Cervantes Saavedra. Don Quijote de la Mancha

de las industrias. Finaliza el captulo con los costes que suponen la implantacin de
un sistema de gestin de la calidad en los procesos de produccin o servicios.
El captulo 2 se centra en el problema de la medida. Tras discutir la necesidad
de medir el software, se definen los conceptos bsicos y se introduce la teora de la
medida. Se repasa histricamente la evolucin de la medida de atributos propios
del software. Finalmente se presenta un marco terico vlido 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 normalizacin y certificacin
asociados a la calidad del software. Como norma internacional de gran
implantacin se presentar en detalle la familia de normas ISO 9000.
El captulo 4 trata de las estrategias para alcanzar la calidad mediante diversos
modelos, metodologas y estndares. Se profundiza en el estudio de los modelos
CMM y Bootstrap, el estndar ISO 15504 y la metodologa MTRICA Versin 3.
Estos modelos y metodologas se han escogido por su impacto histrico y su
elevado nivel de implantacin en numerosos pases, son una referencia bsica en el
estudio de la calidad del software y su normalizacin.
En el captulo 5 se estudian las mtricas asociadas a modelos conceptuales,
estos modelos permiten enlazar los requisitos de los usuarios y la solucin
software. Se estudiarn las mtricas correspondientes a modelos tradicionales y
orientados a objeto.
El captulo 6 profundiza en una tcnica para medir la funcionalidad de las
aplicaciones informticas, entendida sta como el conjunto de funciones aportadas
al usuario por el producto informtico. Esta tcnica es el Anlisis del Punto
Funcin. Su inclusin como un captulo aparte se justifica por la importancia
creciente de esta medida y representar un avance conceptual y prctico en la
cuantificacin del software.
En el captulo 7 se presenta un estudio exhaustivo de la norma ISO 9126, ya
introducida en el apartado 2. En este mismo captulo se explica el procedimiento
propuesto para medir cualquier atributo propio del software.
En el captulo 8 se hace un repaso las medidas ms 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 Ingeniera Informtica de la UNED, los autores han
pretendido que tambin pueda servir a los profesionales de la informtica como una
base para la implantacin de la calidad en sus productos.
Quizs 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
intencin de ampliarlo en futuras ediciones. En este momento iniciamos esta labor.
Julio 2003
Los autores
Captulo 1
LA CALIDAD DEL SOFTWARE

La calidad tiene la estructura de un guila bicfala (...)
porque al mismo tiempo que un paradigma, que un ejemplo,
la calidad se ha convertido en un gran tpico.'
La industria del software, como tal industria, tiene muchas de las caractersticas
de la industria tradicional, entre ellas la necesidad de que sus productos sean de
calidad. En este captulo se tratar del concepto de calidad, de sus caractersticas y
de sus diferentes estados a travs de los tiempos, para terminar con un breve
estudio sobre los costes y beneficios que conlleva la implantacin 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 comunicacin escritos y audiovisuales como en las

revistas tcnicas el tema de la calidad tiene una presencia continuada; incluso los
polticos y gobernantes incluyen el trmino 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 tena que conformarse con lo que le ofrecan. Hoy en da, los oferentes de
productos y10 servicios deben adaptarse a las necesidades, gustos y exigencias de
' Lpez Cachero, M. 11 Jornadas de Calidad del Software, organizadas por la Asociacin de Tcnicos de
Informtica. 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 evaluacin y certificacin de los productos
europeos, la calidad europea, como medio para evitar su discriminacin 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 evolucin. Tal
como Edward yourdon2 expone "... la posibilidad de que los usuarios finales sean
demasiado exigentes puede explicarse por la presin empresarial a la que estn
sometido^"^.
Existen varias razones que justifican el por qu la calidad es crtica 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 prdidas 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 slo para los productos materiales, tambin 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 adelantarn". Hewlett-Packard.
"El crecimiento no es nuestro objetivo principal. Nuestro objetivo ha de ser

una organizacin de calidad, lo cual significa que nos sentiremos orgullosos de
nuestro trabajo y de nuestros productos en los aos venideros. A medida que
alcancemos la calidad, el crecimiento vendr por aadidura". Digital.
'Yourdon, Edward. Investigador ampliamente conocido por idear el mtodo estructurado de anlisis y diseo, as
como ser coautor del mtodo denominado CoadIYourdon para programacin orientada a objeto en los aos
noventa. Autor de ms de quinientos artculos y veinticinco libros es licenciado en matemticas por el MIT y el
Instituto Politcnico de Nueva York. Consultar el sitio http://www.vourdon.com.
'Yourdon Edward, "Lo bueno..es lo mejor?", Byte, no 22, octubre 1996. pg. 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 obtencin de certificaciones emitidas por organismos de carcter 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 captacin 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 gestin de la calidad se enfrenta a severos obstculos de difcil
superacin. Si bien es patente la existencia de un consenso generalizado que nos
indica un grado de concienciacin sobre este tema, no es menos cierto que esta
sensibilidad muchas veces se acerca ms a una actitud esttica que a un verdadero
compromiso con los principios bsicos que rigen esta disciplina. Lpez Cachero
sentencia "... Pero cuando se trata de ponernos de acuerdo en discutir qu es la
calidad, cmo 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 gestin de la calidad sin la debida preparacin 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 creacin de una entidad inmaterial, el programa informtico, de
caractersticas sui gneris 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 aparicin de numerosos modelos
propios del aseguramiento de la calidad del software. Se pueden citar ms de una
decena de estos modelos generados por universidades, asociaciones de carcter
trasnacional y organismos pblicos. CMM, ISO 9000, BOOTSTRAP, SQAM,
proyecto ALVEY, MTRICA, ISO/IEC 9126, proyecto SPICE, son slo algunos
ejemplos de los numerosos esfuerzos realizados en esta direccin.
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
equiparacin en objetivos y resultados.
Lpez Cachero, M. 11 Jornadas de Calidad del Software, organizadas por la Asociacin de Tcnicos de
Informtica. Madrid 2 y 3 de julio de 1998. Registro en audio realizado por nosotros.
Lpez Cachero, M. 11 Jornadas de Calidad del Software, organizadas por la Asociacin de Tcnicos de
informtica. Madrid 2 y 3 de julio de 1998. Registro en audio realizado por nosotros. Lpez Cachero, Manuel.
Rector de la Universidad Alfonso X el Sabio y presidente de la Asociacin Espaola de Normalizacin y
Certificacin, AENOR.
La medida del software se considera, igualmente, una necesaria consecuencia de

la adopcin de una estrategia propia de las ingenieras tradicionales en el desarrollo
de los programas informticos, 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 tericos 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 implantacin de procedimientos de mejoras sin la obtencin de medidas
rigurosas era una prctica habitual en las empresas del sector. Este hecho es
considerado por algunos autores como Fenton, Gibbs o Tom deMarco una de las
causas ms importante de la situacin actual en el desarrollo de programas para
ordenador.
La medida del software se limita, en numerosos casos, a la obtencin de datos
estadsticos sobre la satisfaccin del cliente sin entrar en conceptos ms propios del
software y sus atributos tales como la fiabilidad, madurez, estabilidad, etc. La
medida del software se encuentra lejos de ser una verdadera cuantificacin de los
atributos de procesos o productos, limitndose a la acumulacin de cantidades
resultado de medidas realizadas sobre atributos poco definidos con el fin de obtener
una base de datos histrica sobre la que aplicar diferentes herramientas
matemticas de naturaleza estadstica. Un claro ejemplo de este hecho es el uso del
anlisis del punto funcin con el fin de estimar esfuerzos en la realizacin de
aplicaciones informticas. Sin embargo, esta situacin est cambiando.
La obtencin de medidas estrictas que representen y cuantifiquen atributos
claramente identificados de entidades propias del software y su proceso de creacin
es una necesidad que estudiosos y profesionales ya no ponen en duda.
La medida del software y los modelos de aseguramiento y administracin de la
calidad del software son la base de una pirmide cuya cspide es el control del
proceso de creacin de aplicaciones informticas.
Como colofn 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
disean, organizan y controlan. Si siempre se ha dicho que "el principal capital de
una empresa u organizacin lo constituyen sus recursos humanos", hoy da es ms
cierto que nunca, como reconoce la Comisin Europea:
"En ltima instancia, las expectativas de Europa descansan sobre el potencial

intelectual tcnico de su poblacin y especialmente de las generaciones ms
jvenes. Por ello, la inversin en capital humano en general y en educacin y
capacitacin en particular deben ocupar un lugar destacado en la agenda de todos
los estados miembros."
2. CONCEPTO DE CALIDAD
2.1. Definicin de Calidad
Con objeto de estudiar la medida de la calidad del software se hace

imprescindible definir este atributo. No es difcil encontrar ms de una decena de
definiciones aportadas por instituciones, estudiosos y organizaciones propias del
mbito tradicional de la prestacin de servicios o del suministro de bienes
manufacturados.
La Real Academia Espaola 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. Carcter, genio, ndole. 4. Condicin o
requisito que se pone en un contrato. 5. Estado de una persona, naturaleza, edad y
dems 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.
Segn Mara ~ o l i n e rcalidad,

~, en sentido amplio, equivale a "cualidad"
Como se puede observar las acepciones del trmino son muy variopintas,
aunque aadiremos 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 caractersticas 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 Satisfaccin del cliente y conformidad con sus requisitos y necesidades'' .
o El grado de satisfaccin que produce al cliente" .
'Real Academia Espaola. Diccionario de la lengua espaola. 22" Edicin. Madrid, 2001. Pg. 401.
' Mara Moliner. Diccionario de uso del Espaol. Editorial Gredos S.A. Madrid, 2000. Pg. 224.
UNE-EN ISO 9000. Sistemas de gestin de la calidad. Fundamentos y vocabulario. AENOR. Madrid, 2000. Pg.
16.
Sebastin Prez, Miguel ngel; Bargueo Farias, Vicente; Novo Sanjurjo, Vicente. Gestin y Control de
calidad. Cuadernos de la V E D . Madrid. UNED. 1994. Pg. 15.
' O Sebastin Prez, Miguel Angel; Bargueo Farias, Vicente; Novo Sanjurjo, Vicente. Op. Cit. Pg. 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. Pg. 3. La
traduccin 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 creacin, consideraremos como

definicin de calidad la propuesta por la norma ISO 9000:2000. El proceso de
creacin de programas o el producto informtico 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 definicin 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 difcil concrecin. 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
aplicacin informtica y el grado en que sta las satisface. Estos requisitos sern
estudiados ms adelante.
2.2. Tipos de Calidad
En los mbitos industriales en general, y en los informticos en particular,

circulan numerosas historias jocosas de cmo lo que se proporciona al cliente no
tiene nada que ver ni con lo que ste ha solicitado ni con el diseo 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 gustara 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 Espaa. Cinco Das. Madrid, 1995. Pg. 28.
/
n CALIDAD
REALIZADA \
\ CALIDAD
PROGRAMADA
y CALIDAD /
Figura 1.1. Los tres tipos de calidad.
Podemos representar estas calidades como tres crculos que se cortan. Lo que la
gestin de la calidad pretende conseguir es que el rea comn 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 caractersticas, por
ejemplo la esttica, y es debido a que los usuarios no disponen de la informacin
completa. En estos casos los productos o servicios se evalan ms por su nombre
de marca o la publicidad que por sus caractersticas 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 gestin poco puede hacer para que la calidad
percibida sea igual a la realizada, salvo incrementar la comunicacin a fin de
conseguir la convergencia.
2.3. Rasgos inherentes a la calidad
Algunos de los rasgos ms 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 comn.
Involucra a todos los niveles de la empresa.
Las consecuencias de la implantacin de un sistema de calidad son:
o Mejora de la imagen de la empresa.

o Apoyo al marketing.
o Favorece el espritu de equipo.
o Genera valor aadido.
o Genera crecimiento sostenido basado en la excelencia.
o Es una inversin sin riesgo.
2.4. Dimensiones de la calidad
El modelo que representa la calidad se configura mediante un conjunto de

dimensiones, tambin llamados factores o caractersticas, que son independientes
entre s. Un producto puede tener un valor alto en una dimensin y bajo en otra.
Estas dimensiones varan segn los diversos autores.
A continuacin presentaremos la de Sebastin, Bargueo y ~ o v o ' ligeramente
~,
modificada.
Las dimensiones identificadas son: Prestaciones, Diferenciacin, Fiabilidad,
Conformidad, Duracin, Asistencia Tcnica y Esttica.
Prestaciones
Son las caractersticas operativas principales de un producto, que son

fundamentalmente medibles, como la velocidad mxima de un vehculo, el tiempo
de frenado, el nmero de canales de un televisor, los watios de potencia de un
equipo de sonido, etc. La conexin entre calidad y prestaciones, a pesar de poderse
dar una medida de estas ltimas, se encuentra afectada por las preferencias
individuales y la semntica. As, un cliente puede preferir el tiempo de frenado a la
velocidad o no asociar con calidad el trmino potencia de un equipo de sonido o de
una bombilla (por ejemplo no considera que una lmpara de 100 watios sea de ms
calidad que una de 40 watios). As como las prestaciones se corresponden con las
caractersticas objetivas del producto, su relacin con la calidad depende de la
interpretacin individual y particular del cliente.
" Sebastin, Miguel Angel; Bargueo, Vicente; Novo, Vicente. Gestin y Control de calidad. Madrid. UNED.
1994.
Diferenciacin
La diferenciacin se refiere a las caractersticas secundarias del producto, las

que coexisten con el funcionamiento bsico del producto. La distincin con las
prestaciones es muchas veces difcil, pues muchos clientes pueden pensar que para
ellos una caracterstica secundaria o caracterstica diferencial, por ejemplo, la
inclusin de una calculadora en una aplicacin software de contabilidad, es una
prestacin del producto software considerado.
Fiabilidad
Se denomina fiabilidad a la probabilidad de que un producto no falle en un

perodo 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 slo vlidas
para productos que estn funcionando durante un cierto tiempo, por lo tanto slo
sirve para productos duraderos y no para productos perecederos o servicios de
consumo instantneo.
Conformidad
La conformidad es el grado en que el diseo y las prestaciones del producto

cumple los estndares establecidos. Su medida vara de un sector a otro. En la
industria de fabricacin se mide mediante la tasa de defectos (proporcin de la
produccin que no cumplen las normas). En otros sectores, como en los servicios,
se mide por el nmero de reclamaciones o la frecuencia de reparaciones durante el
perodo de garanta. 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 diferenciacin.
Como los usuarios no quieren ni defectos ni fallos, apartando del mercado los
productos que los presentan, la inversin en fiabilidad y conformidad se consideran
como ganancias directas de la calidad.
Duracin
Es la medida de la vida del producto. En esta medida de carcter tcnico

subyace un aspecto econmico. La duracin tcnica es la cantidad de uso que se
obtiene del producto antes de su deterioro fsico, sin posibilidad de reparacin. Si
la reparacin es posible, la duracin es ms difcil de calcular, ya que la vida del
producto depender de las condiciones econmicas; as, si la economa va bien los

coches usados tienen menor duracin. En general, el cliente tiene que elegir entre
el coste de la reparacin para incrementar la duracin y la inversin de un nuevo
modelo ms fiable. Como se puede deducir la fiabilidad tiene mucho que ver con la
duracin. Aunque no siempre una mayor duracin implica una mejora 'del
producto, ya que puede ocultar una situacin econmica particular, por ejemplo,
obsrvese el parque automovilstico cubano, cuya vida media sobrepasa de largo
los 14 aos considerados como media, siendo casi joyas de museo.
Asistencia tcnica
Esta caracterstica est relacionada con el servicio de reparaciones y la atencin

al cliente en general, y comprende la prontitud en la atencin o reparacin, la
competencia de los empleados y el trato al consumidor. Algunos aspectos pueden
medirse objetivamente, como el tiempo de reparacin o el del actualizacin de un
antivirus, otros como el trato al cliente slo puede hacerse de forma subjetiva. Es
uno de los aspectos que ms influyen en la percepcin actual de la calidad.
Esttica
Es muy subjetiva y est muy ligada a la personalidad del usuario, que no tiene
por qu aceptar los cnones establecidos. La forma de un producto, su color, sabor,
tacto o sonido o grficos afectan de forma diferente a los diferentes usuarios. En un
programa de videojuegos la calidad que percibe el usuario est muy ligada a la
esttica (parte grfica, msica de fondo, diseo de los personajes, etc.).
2.5. Las caractersticas 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
fmstracin y de prdida 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 caractersticas compuestas: Funcionalidad,
Fiabilidad, Facilidad de uso, Eficiencia, Mantenimiento y Movilidad. Cada una de
ellas se descomponen en subcaractersticas que sern estudiadas en detalle en el
correspondiente captulo.
As, cuando se adquiere un software se quiere que ste funcione siempre y bajo
diferentes condiciones incluso difciles 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 fcil (facilidad de uso), que lo
hagas lo ms rpido posible y con el mnimo consumo de recursos (eficiencia), que
cuando las circunstancias lo pidan pueda modificarse fcilmente (mantenimiento)
y, por ltimo, que pueda transferirse de un entorno a otro (movilidad o
portabilidad).
Quizs, de las dimensiones manejadas, la del nivel ms bajo asumido es la
fiabilidad, ya que el software debe funcionar siempre que se requiera. Qu mayor
fmstracin que cuando se est de viaje con un porttil, no pueda utilizarse por un
incidente del sistema operativo.
El siguiente nivel exigido, el intermedio, es la funcionalidad. No slo el
software debe de tener las funcionalidades que dice tener, sino que debe
comunicarlas. Es decir, el usuario debe disponer de la informacin suficiente para
poner usar de forma eficaz todas las tareas. El manual de usuario de la aplicacin
es un componente ms del software.
En un nivel superior se encuentra la facilidad de uso (usabilidad). Adems de
hacer lo que debe hacer el software, debe de hacerlo de una forma fcil, natural y
amigable, de ah la importancia del diseo de las interfaces.
El resto de las caractersticas 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 fcil. La economa de recursos, la facilidad de
modificacin y el transporte del software aaden la miel a la hojuela de las tres
caractersticas fundamentales.
2.6. El Declogo de la calidad
Este declogo de la calidad es propuesto por Arthur ~ n d e r s e n 'como

~ preceptos
fundamentales para la gestin exitosa del factor estratgico Calidad. Segn los
autores, el declogo es consecuencia de su experiencia en consultora.
Los preceptos del declogo 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 Espaa. Madrid. Cinco Das. 1995.
establecer una posicin de liderazgo en algn segmento, identificando aquellos

factores o dimensiones de calidad en los que tiene ventajas competitivas y
diseando estrategias de segmentacin para explotar los nichos del mercado
correspondientes.
2" El proceso de calidad se inicia con el liderazgo activo de la Alta Direccin
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 organizacin y la estrategia de calidad han de
impulsar su desarrollo y crecimiento. Como la visin y la estrategia de calidad han
de ser compartidas por toda la organizacin, el estilo de gestin ha de ser
participativo y se ha de practicar diariamente lo que se predica.
3" La calidad es un factor estratgico de competitividad y diferenciacin
No se puede hablar de niveles de calidad absolutos, ya que lo que importa es la

comparacin 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 vara a lo largo del ciclo de vida del producto
desde la innovacin en su inicio, pasando a la competencia en precio y calidad
como factor diferenciador segn se avanza en el ciclo. La calidad y el servicio al
cliente son ventajas competitivas duraderas.
4" La calidad efectiva es garanta de rentabilidad sostenida
Si el criterio primordial empresarial es la excelencia del servicio al cliente, la

eficacia de las operaciones se evala en trminos de calidad ms que en trminos
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 reduccin de
costes, aunque al principio haya que invertir en formacin, aprendizaje y
modificacin de los hbitos. La rentabilidad se debe a diversos factores como:
o Los clientes satisfechos son los mejores vendedores.

o Los clientes satisfechos son ms fieles a la hora de una nueva compra.
o Los productos y servicios de mayor calidad proporcionan mejores precios y
mrgenes comerciales.
o Menores costes de comercializacin, ya que no hay que captar nuevos
clientes.
o Mayor productividad al dirigir los recursos hacia un objetivo comn y

conocido.
5" La calidad involucra a todo los miembros de la organizacin
De poco sirve que exista una poltica 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 seleccin de personal, ya que la imagen que de la empresa se'
forman los clientes viene condicionada por el entusiasmo, motivacin y conviccin
que transmiten los empleados; por lo tanto, los candidatos seleccionados deben
tener unas actitudes y caractersticas acordes con la orientacin de la empresa. Las
empresas que consiguen implantar con xito este tipo de estrategia son las que han
dado prioridad a la inversin en formacin de sus empleados, convirtiendo esta
formacin en un mecanismo fundamental en el proceso de motivacin, ayudando a
establecer el espritu de equipo y cooperacin necesarios para que la gestin diaria
de la calidad alcance el xito.
6" La calidad involucra tambin 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 implantacin de sistema de aseguramiento de calidad
segn normas ISO o sus equivalentes espaolas UNE.
7" La calidad debe ser el criterio que configure todos los sistemas y procesos de
la empresa
Si una organizacin no evala todas sus actividades desde la orientacin al

cliente puede que implante sistemas incompatibles con la calidad. Los sistemas que
ms influyen en la gestin eficaz de la calidad son:
- Sistemas de captacin de informacin externa. Esta informacin 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 medicin de la calidad, Estos sistemas permiten evaluar los

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

ligarse al cumplimiento de los objetivos de calidad, y es la herramienta ms
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 frustracin y suponen la prdida del cliente. Las estrategias
comunicacionales tienen como objetivo:
- Crear una imagen institucional que se asocie con el concepto de calidad.

- La promocin de los aspectos de calidad difeenciadores.
9" Calidad implica sensibilidad y preocupacin 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 conservacin del medio ambiente. La responsabilidad social
forma parte de la imagen de la empresa.
1 O" La calidad es dinmica
La calidad no es esttica, est constantemente en transformacin 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 grfico siguiente:
Gestin estratgica de la calidad
Aseguramiento de la calidad
Figura 1.2. Etapas de la calidad.
3.1. Inspeccin
Como consecuencia de la organizacin "taylorista" de la produccin nace el

control de calidad como supervisin de los productos terminados segn el concepto
"aceptado o no aceptado". Los inspectores de calidad comprobaban si los
productos cumplan determinados requisitos, rechazando aquellos que no
superaban la correspondiente inspeccin. Sus caractersticas son:
o El objetivo principal es la deteccin de errores.

o Su visin de la calidad es un problema a resolver.
o Pone el nfasis en la uniformidad del servicio.
o Emplea mtodos de fijacin de estndares y medicin.
o El papel de los profesionales de la calidad es de inspeccin, clasificacin,
conteo y medicin.
o La responsabilidad de la consecucin de la calidad es del departamento de
inspeccin.
o Su orientacin y enfoque es que la calidad se comprueba.
3.2. Control de la calidad
Hacia 1924 se establecen las bases del Control Estadstico de la Calidad, que
recibe su confirmacin durante la Segunda Guerra Mundial, contribuyendo a la
produccin de guerra que facilitara el triunfo a los Aliados. Las caractersticas son:
El objetivo principal es el control para detectar errores en los productos

terminados.
Su visin de la calidad sigue siendo un problema a resolver.
El nfasis sigue estando en la uniformidad del servicio, pero reduciendo la
inspeccin.
Sus mtodos son herramientas y tcnicas estadsticas.
El papel de los profesionales de la calidad es de resolucin de problemas y
aplicacin de mtodos estadsticos.
La responsabilidad de la consecucin de la calidad es de los departamentos
de calidad y de los inspectores.
La orientacin y enfoque se basa en que la calidad se controla.
Su filosofa es clasificar los productos en funcin de su calidad intrnseca.
Su alcance se relaciona exclusivamente con el producto final.
Las referencias escritas son las especificaciones del producto.
La formacin del personal queda limitada a los inspectores.
El coste de la calidad se debe al rechazo de productos ya terminados, no
recuperndose su coste de produccin.
A los proveedores prcticamente no se les presta ninguna atencin.
Las nicas normas existentes son las especificaciones del producto.
La calidad se obtiene por comparacin de las especificaciones con el
resultado del control del producto terminado.
3.3. Aseguramiento de la calidad
Del control estadstico de la calidad se pasa a la gestin de la misma,

caracterizndose por:
Su objetivo principal es la coordinacin de los diferentes procesos que

llevan al producto.
Su visin 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 mtodos son los programas y sistemas de calidad.
El papel de los profesionales de la calidad est en planificar la calidad,
medirla y disear programas para la calidad.
La responsabilidad de la consecucin de la calidad es de todos los
departamentos; la direccin se limita a fijar la poltica, planificar, coordinar
y controlar.
Su orientacin y enfoque es que la calidad se produce.
Su filosofa es incorporar la calidad al producto desde la fase de desarrollo
al final de una forma planificada.
Su alcance se limita al proceso de produccin, junto a los proceso de apoyo,
en cuanto tengan relacin directa con el producto final.
Sus referencias escritas son normas ISO u otras especficas 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 documentacin de toda la lnea jerrquica que ejerce la responsabilidad
del aseguramiento.
La formacin es especfica. Se dirige a que cada persona aprenda
exclusivamente las tareas que tenga que desarrollar.
La reduccin 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 segn las normas y se mide por
el nmero 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 especficas del
sector.
3.4. Gestin de la Calidad Total
Un grupo de empresas europeas pens, a mediados de los aos ochenta en

obtener una ventaja competitiva por medio de la Gestin de la Calidad Total
(TQM) y crearon la Fundacin Europea para la Gestin de la Calidad (EFQM).
Esta gestin no se basa en normas sino en modelos como el Premio Malcom
Baldrige, el Premio Deming o el Modelo Europeo (modelo EFQM). Sus
principales caractersticas son:
Su objetivo principal es el impacto estratgico.

Su visin 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 mtodos son la planificacin estratgica, la fijacin de objetivos y la
movilizacin de la organizacin.
El papel de los profesionales de la calidad se centra en la fijacin de
objetivos, formacin, coordinacin entre los departamentos y diseo de
programas.
La responsabilidad de la consecucin de la calidad es de todos los
miembros de la empresa bajo el liderazgo activo de la direccin.
La orientacin y el enfoque se basa en que la calidad se gestiona.
Su filosofa se basa en dirigir la organizacin, con colaboracin de los
empleados, hacia la mejora de los productos.
Su alcance es la Gestin por Procesos de todo lo que se hace en la
organizacin.
Las referencias escritas, adems de todas las anteriores, incluyen las
expectativas de los clientes, las polticas de calidad, los objetivos
estratgicos, la participacin de los empleados, la relacin con la
comunidad, etc.
La responsabilidad de la gestin es de todo el equipo directivo y de los
mandos intermedios.
El control de costes se dirige a reducir el coste mediante la eliminacin de
todos aquellos elementos y procesos que no aaden valor, desde el punto de
vista del cliente interno y externo.
El proveedor constituye un eslabn ms en la cadena de valor, por lo que
hay que establecer con l una relacin de confianza para conseguir una
Calidad Concertada.
3.5. Evolucin del concepto de calidad
Inicialmente la calidad se consideraba un problema. Actualmente esta visin ha

variado al considerarse como un factor estratgico, un elemento competitivo.
Tambin ha pasado de ser incumbencia exclusiva del departamento de produccin
a afectar al resto de los departamentos, hasta llegar actualmente al mercado y a los
clientes, centrndose todo el nfasis de la calidad en estos ltimos. Los mtodos,
que consistan nicamente en herramientas de medicin han evolucionado hasta
herramientas de gestin y planificacin.
La calidad ha ido acrecentando su papel en la empresa, involucrando cada vez a
mayor nmero de personas y saliendo de la organizacin para centrarse en el
mercado y el consumidor.
El cambio puede observarse en el siguiente cuadro:
Tabla l. l. Evolucin de la calidad en la empresa.
Las actividades necesarias para la obtencin de cierto producto, de forma que

ste cumpla con requisitos concretos pueden ser entendidas como control de la
calidad. La historia y evolucin de esta disciplina se encuentra, por tanto,
estrechamente unida a los avances tecnolgicos aportados por la humanidad desde
sus orgenes.
El trmino calidad no aparece hasta muy avanzada la historia de la economa y
la tecnologa, aunque s se emplean calibre, galga, sistema de medicin que indican
un cierto papel de la metrologa, es decir, una tendencia a cuantificar las
caractersticas de los productos.
4.1. Artesanos y Obreros
Un momento importante para la aparicin de lo que podramos llamar "la

calidad moderna" se produce cuando el artesano se convierte en obrero con el
advenimiento de la Revolucin Industrial.
Anteriormente era el artesano el que produca los artculos que necesitaban los
dems, pero los haca uno a uno, solamente condicionado por el cliente. Los
productos tienen ciertas connotaciones artsticas y el artesano tiene prcticamente
una total libertad de accin. 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 satisfaccin del cliente, que es lo que hoy en
da se conoce como calidad.
La Revolucin Industrial introduce la produccin masiva y la cadena de
montaje. El operario no tiene ni iniciativa ni libertad de accin, 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 situacin socio-econmica 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 satisfaccin del cliente o sea la calidad de su trabajo.
Es necesario, por consiguiente, la organizacin de un sistema de medicin,
supervisin y control que intente asegurar la calidad de la produccin, con la
intervencin de nuevos operarios especializados en calidad.
4.2. Los orgenes
En los principios de la humanidad, la sociedad era exclusivamente nmada,

recolectora y cazadora. Cada grupo elaboraba sus propios productos segn sus
necesidades, por lo que no haca ningn 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 dems. Es el momento en el que empieza a tener lugar
una "funcin de calidad" por parte del artesano por un lado y del consumidor por
otro. Tambin se inicia el comercio, incluso a grandes distancias: el intermediario,
el comerciante, hace tambin 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 fcil conocer cundo y dnde se produjo la
evolucin 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 construccin
de las pirmides de Egipto, por lo que podemos considerar esta poca como
referencia temporal bsica para esta disciplina. La Grecia clsica o el antiguo
imperio romano han dejado muestras evidentes del nivel de calidad alcanzado en
sus obras de ingeniera o arquitectura. Aun, hoy en da, podemos disfrutar de la
simbiosis de tcnica y belleza que sus construcciones nos ofrecen.
En la Edad Media y hasta finales del siglo XIX el suministro de servicios y la
produccin de bienes se encontraban esencialmente limitados a individuos aislados,
como mximo a un grupo formado por algunas pocas personas. Este colectivo era
quien controlaba la calidad del artculo haciendo las funciones de productor e
inspector. El resultado de esta actitud es que los estndares 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 proteccin y provecho econmico y social de
sus miembros. Regulaban las economas locales urbanas estableciendo monopolios
sobre el comercio, manteniendo servicios estables sobre condiciones estables y
especificando estndares de calidad sobre las cosas.
"Esta regulacin 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 Revolucin Industrial: la inspeccin
El advenimiento de la industrializacin, a finales del siglo XVIII, supuso

profundos cambios sociales y econmicos generados por 'un proceso tcnico.
Prcticamente desaparecen los pequeos talleres artesanales y se forman grupos de
trabajadores ms numerosos con atribuciones especficas o similares. La
l5 Banks, Jeny. Profesor de la Escuela Industrial y de Sistemas Ingenieriles perteneciente al Instituto Tecnolgico
de Georgia. Experto en sistemas de simulacin informtica. Consultar la Encyclopedia of Software Engineering,

John Wiley & Sons, 1994.
Jerry Banks. Principies of quality control. John Wiley & Sons, 1989. Pg. 4. La traduccin es nuestra.
" Banks, Jeny., op. cit. pg. 6. La traduccin 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
tena la misin de controlar el trabajo de los empleados. Por otro lado el dueo de
la fbrica, an presente fsicamente en la misma, elige estndares 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 tcnica 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 estadstico
En 19 11 Taylor en su obra Principios de la direccin cientzjica propone la

separacin entre la direccin de la empresa y los trabajadores mediante la frmula:
"La direccin debe definir la tarea de cada uno de los operarios especificando el
mtodo que deben de usar y cuantificando el tiempo que deben emplear en
realizarla."
La organizacin "taylorista" de la produccin se extiende rpidamente. El

proceso de produccin se descompone en una serie de sencillas tareas y cada
operario slo realiza una de ellas y, por lo tanto, de una forma fcil. La duracin de
la formacin del personal es relativamente corta y se puede atender rpidamente los
aumentos de produccin mediante la contratacin 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 diseo 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 solucin que
comprar lo que hay en el mercado.
Como la organizacin de la empresa es funcional, slo los directivos de mayor
nivel de cada funcin tienen una visin 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 tcnicas de control de
calidad, mejorando y estandarizando los procesos. Las materias primas se
distribuan 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 supervisin de inspectores, a
pesar del avance prctico y conceptual que supusieron, era una tcnica insuficiente
que no satisfaca a ciertas empresas. La empresa Be11 Telephone se enfrentaba a un
grave problema: las solicitudes de instalacin de telfonos sobrepasaban las ms
optimistas expectativas, pero al mismo tiempo se incrementaban de forma
alarmante las reclamaciones de los clientes, lo que supona 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 tcnicas e instrumentos ms certeros que
provocara una mayor confianza en los productos ofrecidos. En 1924 se form el
Departamento de Inspeccin de Laboratorio de las compaas Be11 Telephone y
Western Electric [Banks, 19891, que recibi el nombre de "Quality Assurance
Department", es decir, Departamento de Garanta 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 deban realizar cada uno de los miembros del equipo.
Esa descripcin, se considera actualmente como la primera documentacin de un
sistema de calidad.
El Dr. Walter A. Shewhart el da 16 de mayo de 1924, propone un grfico de
control para el anlisis 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 estadstico de la calidad.
Las aportaciones de este equipo fueron muy importantes. Por primera vez,
adems de utilizar grficas de control, se definieron conceptos y nociones hasta
entonces no bien entendidos, tales como riesgo del proveedor, riesgo del cliente,
probabilidad de aceptacin o inspeccin media total (IMT).
En 1925, Dodge present los principios bsicos del muestreo por atributos en
el procedimiento de inspeccin. En febrero de 1926 la revista "Manufacturing
Industries" publica el artculo de Shewhart "Finding causes of Quality variation" y
en octubre otro artculo, "Quality control charts" en el "Be11 System Tcnica1
Journal". En 1927, las tablas de muestreo sobre el concepto de lmite de calidad
media de salida (LCMS) fueron desarrollados por el equipo de la Western Electric.
Se haba alcanzado la fase que Marciniak denomin "cuantificacin 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 dcada de los treinta la aceptacin de las
tcnicas de muestre0 en la industria se afianz, e incluso super las fronteras de los

Estados Unidos de Amrica, teniendo especial impacto en la comunidad
universitaria del Reino Unido. Egon S. Pearson pronunca 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 ms tarde la British
Standard Association publica otro artculo 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 motivacin y compromiso
de los empleados, a esta iniciativa se la denomin Plan Scanlon.
En 1940 la Asociacin Americana de Estndares, ms conocido por sus siglas
provenientes de su nombre en ingls ASA (American Standards Association), a
requerimiento del Departamento de Defensa de los Estados Unidos de Amrica,
impuls la utilizacin de controles estadsticos en los productos manufacturados.
De este esfuerzo surgieron los estndares AWS Zl.1 "Gua del Control de
Calidad", y AWS 21.2 "Mtodo Grfico de Control y Anlisis de Datos". El
nombre de estos estndares proviene de las siglas en ingls 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 ejrcito se involucra activamente en el control de la calidad. La
participacin de las fuerzas armadas, sobre todo de los Estados Unidos, en esta
materia se revelar como fundamental. Su influencia no slo incide en la dcada de
los cuarenta, si no en toda la historia del control de la calidad hasta nuestros das.
En 1946 se crea formalmente la American Society for Quality Control (ASQC).
En 1949 se desarrolla el denominado JAN-105, acrnimo de su nombre en ingls,
Joint Army-Navy Standard, documento que significaba un importante avance en
el campo de variables, atributos y el anlisis secuencial.
La medida de atributos relacionados con la calidad se revel una actividad
sumamente importante ya en la dcada de los aos 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 estadstico continu en la dcada de los aos
cincuenta, este decenio estuvo marcado por el desarrollo y modificacin de
estndares de control de calidad.
En 1950 un comit formado por militares norteamericanos desarroll la norma
MIL-STD-105A, considerada un compromiso entre los estndares de control
militar JAN-105 y las tablas del ejrcito norteamericano denominadas ASF. A este
estndar le siguieron la MIL-STD-105B, MIL-STD-105C, MIL-STD-1O5D y la
MIL-STD-414 emitida en 1957. Estos manuales no tenan en cuenta estndares

relacionados con los requisitos de programas de calidad o tcnicas de inspeccin a
aplicar a los suministradores. El estndar 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 Aeronutica norteamericana,
mundialmente conocida por sus siglas en ingls NASA, tambin fueron muy
activos, emitiendo sus propios manuales.
Fuera de los Estados Unidos tambin surgen investigadores y estudiosos del
control de la calidad. En 1947 se crea en Japn la Unin Japonesa de Cientficos e
Ingenieros (JUSE) que se convertir desde su nacimiento en el impulsor de la
evolucin de la calidad, siendo aceptadas sus pautas por todo el mundo. Dentro de
la SUSE se organiza el Comit de investigacin en control de Calidad. Ese mismo
ao se promulga la Ley de Normalizacin Industrial de Japn, 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 hara que la
marca "Made in Japan" sera un smbolo 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
tcnicas de grficas de control en el Japn y crea el Diagrama causa-efecto,
conocido comnmente el diagrama de la espina de pez, "fish-bone". A Ishikawa le
fue concedido el Premio Dening.
En Europa tambin se percibe un continuo inters por el control de la calidad,
siendo Gran Bretaa es el pas europeo lder en este campo. Se fundan diversas
asociaciones para la promocin de las tcnicas de Calidad. As, en 1956 nace la
Organizacin Europea para el Control de la Calidad (EOQC, European
Organization for Quality Control) que es hoy da la European Organization for
Quality. En Francia se funda en 1957 la Association Francaise pour le Contrle
Indstriele et la Qualit (AFCIQ). En 1961, nace en Espaa la Asociacin Espaola
para el Control de la Calidad (AECC) que ha cambiado su nombre por el de
Asociacin Espaola para la Calidad.
4.6. El presente: la gestin de la Calidad Total
La dcada 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 fabricacin. Las estructuras de toma de decisin en el negocio no
utilizaban adecuadamente los resultados y recomendaciones emanadas de las
tcnicas estadsticas aplicadas. El concepto de calidad total presentaba la idea de
que todos los departamentos, no slo el de control de la calidad, tuviera

responsabilidades en este trabajo.
Simultneamente la industria japonesa sinti la necesidad de una educacin ms
profunda de los supervisores, que eran la unin entre administradores y operarios.
Como respuesta a este hecho la Unin de Cientficos e Ingenieros (JUSE) public
la revista Gemba-To-QC en abril de 1960. Al amparo de esta idea surgen los
denominados crculos de calidad, foros de debate y discusin en las empresas. En
ellos supervisores y trabajadores opinan sobre los controles de calidad existentes
provocando un autoadiestramiento en la calidad y su tcnica.
Philip B. Crosby, promotor de un programa de 14 puntos para la gestin de la
calidad y de las cuatro calidades absolutas (definicin de calidad, sistema de
prevencin de la calidad, cero defectos, y medicin de la calidad), era el director de
produccin de la empresa Martn, fabricante de los misiles Pershing. Alcanz la
fama cuando puso en marcha, mediante un plan de incentivos para los trabajadores
si reducan los defectos, el primer proyecto "cero defectos". El 12 de diciembre de
1961 consigue entregar en Cabo Caaveral (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 britnica 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 Fundacin Europea para la Gestin
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 rpidamente aplicando en pocos aos prcticas propias del control de
calidad que otras disciplinas han madurado durante dcadas. 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
aos un estado de madurez para el que otras industrias han necesitado alrededor de
200 aos."
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 relacin con el proceso de creacin de programas informticos,
han supuesto una referencia importante para el mismo. La tabla 1.2, propuesta
tambin por Marciniak, pone de manifiesto esta relacin, comparando las

diferentes fases superadas por el control de calidad y su aplicacin por parte de la
industria en general, y la industria del software.
Etapa Descripcin Industria del Industria en

--- .- Software general
Artesanos Se fan de la creatividad y del buen Aos sesenta Antes del
trabajo artesanal siglo XIX
Inspeccin Supervisores inspeccionan la calidad Aos setenta Siglo XIX

antes de la liberacin de producto
Control Cuantificacin de la calidad del Pocas Aos treinta

estadstico producto; tcnicas de muestre0 evidencias
del proceso de uso
Aseguramiento Uso de estndares en los sistemas Aos ochenta Aos

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

con la calidad y minimizan costes
Calidad dirigida Calidad total dirigida hacia el cuidado Pocas Aos 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. Orgenes del aseguramiento de la calidad del software
A finales de la dcada de los sesenta varios documentos de IBM utilizaron de

forma ocasional el trmino aseguramiento de la calidad del software [Dunn, 19941.
Generalmente esta expresin se encontraba asociada a la realizacin de pruebas del
producto ya desarrollado. Por otro lado los requisitos para ofertas exigan incluir un
prrafo bajo el ttulo "Aseguramiento de la Calidad del Software". Este apartado
requera 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 especificacin 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 administracin. Los
puntos ms importantes eran:
- Mtodos a utilizar por el contratista para evaluar diseo y documentacin.

- Aprobacin interna del trabajo.
- Documentacin de los estndares del gobierno norteamericano para un
trabajo desarrollado bajo contrato con el mismo.
- Biblioteca sobre los procedimientos de control para cdigo 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, anlisis de las especificaciones externas que
aseguran la verificacin, criterios de esas pruebas, control de las pruebas,
certificacin de los resultados, revisin de la documentacin de las pruebas.
La norma norteamericana perfil el mbito de la prctica del aseguramiento de

la calidad del software, con excepcin de los procesos de mejoramiento de la
calidad. Por otro lado no identificaba mtodos, tcnicas, prcticas o herramientas
que los contratistas deban seguir. Slo indicaba que este asunto deba 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 Ejrcito 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", tambin
similar a la norma MIL-S-52779, aunque hizo un mayor hincapi en la
documentacin y uso de revisiones formales reflejando el desarrollo del software
segn el modelo militar "en cascada". Omiti de forma deliberada procedimientos
de prueba.
Estos primeros documentos no tenan como propsito recetar herramientas y
tcnicas para prevenir defectos, mtodos para dirigir revisiones de cdigo,
filosofas y tcnicas de las pruebas o uso de datos para mejorar la calidad de
futuros desarrollos. La interseccin con otros aspectos de la ingeniera del software
tuvo que ver nicamente con el control del proceso del desarrollo del software y
liberacin 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 tcitamente

definido como el de un polica o un rbitro, observado como algo nuevo, incluso
para los equipos de control de calidad tradicionales.
"Algunos departamentos de control de calidad saban cmo interpretar las
nuevas especificaciones. El ritmo pareca familiar, pero los entornos de control de
calidad nunca haban bailado con una msica tan extraa.19"
A mediados de los setenta, la fiabilidad, ciertamente uno de los atributos
primeros de la calidad del software, atrajo la atencin de forma importante sobre
conceptos como productividad del programador o control del proyecto. La
fiabilidad era vista como la materializacin diligente de los preceptos
prevalecientes en la ingeniera del software que enfatizaba en la planificacin del
desarrollo de proyectos, modelado de requisitos, administracin de la
configuracin o las tcnicas de diseo. El aseguramiento de la calidad del software
no jugaba ningn papel en este hecho. Los textos de la poca, por ejemplo, no
hacan referencia a este concepto (aseguramiento de la calidad del software).
En los primeros aos ochenta las actividades relacionadas con el aseguramiento
de la calidad en el software se centraban en establecer estndares para la deteccin
de errores, control de cambios, documentacin y control de proyectos.
Dunn y Ullman publicaron un libro en 1982 que supuso la extensin de los
conceptos relacionados con el aseguramiento de la calidad del software ms 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
administracin, aunque algunos estudiosos del mismo consideran que no distingui
claramente la herramienta de la administracin en s.
En los aos ochenta exista una clara confusin que no permita definir el
aseguramiento de la calidad del software como un conjunto de actividades o como
una organizacin funcional. De cualquier manera la calidad en el software estaba
atrayendo a gran cantidad de investigadores, estudiosos, administradores y gerentes
relacionados con la programacin.
Por otro lado la informtica era utilizada como una herramienta, por otras
disciplinas, en sus propios procesos de aseguramiento de la calidad. El nmero de
paquetes informticos desarrollados para este objetivo se multiplic por dos, y a
veces por tres, segn el rea considerada, desde mediados de los aos ochenta hasta
1988.
l9 Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineenng, John Wiley & Sons, 1994. Pg.
942. La traduccin 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 estndares de gran influencia, no slo en el mbito militar, sino en
numerosos aspectos de la vida civil. En 1979 el Ejrcito de Tierra norteamericano
auspici unas jornadas en la Escuela de Postgrado de la Marina en Monterrey,
California. El resultado de estas reuniones fue enormemente fructfero pues se
establecieron las bases de la que ms tarde sera 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
configuracin y administracin 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 organizacin de aseguramiento de calidad del
software. El proceso de creacin de este estndar se alarg hasta 1988.
Aunque en los setenta y en los ochenta el aseguramiento de la calidad del
software se haban establecido en compaas de software empotrado, esta
disciplina haba empezado a encontrar un hueco en sistemas de programacin y
sistemas de administracin de la informacin, que inclua la programacin de
aplicaciones de uso comercial.
La pobre calidad con la que muchos programas llegaban a la fase de ejecucin
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 poda 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.
Verificacin y validacin 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. Pg.
4.10. Anlisis de los atributos
A mediados de los ochenta, el concepto asociado al aseguramiento de la calidad

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

programacin y control del proyecto software.
- Pruebas.
- Verificacin y validacin.
En los ochenta el primero de estos tres conceptos increment el nfasis del

anlisis de los atributos de la estructura del software as como en la acumulacin y
anlisis de los datos asociados a los errores. Es aceptado que la permanencia de los
errores en el proyecto software incrementa dramticamente su presencia a medida
que el error permanece ms tiempo en dicho proceso. La prctica de la coleccin y
anlisis de datos se desarroll en el mbito del aseguramiento de la calidad. La
dependencia de los datos es intrnseca al concepto de control de la calidad total y es
la sustancia de una de las siete categoras de criterios del Premio Nacional de
Calidad Malcolm.
Una variacin de este primer punto asociado al aseguramiento de la calidad del
software, influenciado por el concepto de calidad total, supera la confusin entre
organizacin-administracin.
"El aseguramiento de la calidad del software no asegura la calidad del software;

asegura la planificacin y ejecucin de un programa de calidad que envuelve tres
elementos tecnologa, persona y administracin, tres partes que finalmente actan
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 implantacin de la calidad en el
desarrollo de programas informticos. Ms adelante haremos un estudio detallado
de alguno de ellos.
El Instituto de Ingeniera del Software, ms conocido por su acrnimo ingls
SE1 (Software Engineering Institute) ide un marco de referencia para el proceso
de creacin del software como respuesta al requerimiento de gobierno
''Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineering, John Wiley & Sons, 1994. Pg.
norteamericano para la obtencin de un mtodo que permitiera valorar la capacidad

de los contratistas de aplicaciones informticas que accedan a sus licitaciones.
Tras cuatro aos de trabajo el SEI, en colaboracin con la empresa Mitre
Corporation, desarroll un modelo apoyado en el concepto de madurez al que
denomin CMM acrnimo del ingls 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 mritos que el Modelo de Madurez posee, su aplicacin
en el mbito europeo fue discutida por algunos estudiosos. Tal y como apunta el
profesor Gnter R. Koch , el modelo de valoracin de la madurez propuesto por el
SE1 mostraba ciertas debilidades que lo hacan dificil de aceptar desde el punto de
vista de la mentalidad europea.
La metodologa Bootstrap se encuentra alineada con la norma ISO 9000. Esta
norma, a su vez, propuso la norma ISO 9000-3, gua de aplicacin de la norma ISO
9001 para compaas 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
definicin de procesos y procedimientos para la certificacin 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 creacin 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 dcada de los aos noventa, el sentimiento
generalizado de la necesidad de promover un estndar internacional que
armonizara los modelos de referencia existentes.
El proyecto SPICE, promovido por ISO (International Organization for
Standards) surgi como un esfuerzo de colaboracin internacional que deba
materializarse en un nuevo estndar para la valoracin del proceso del software. El
grupo de trabajo que llevara a cabo esta labor (WG10) contara con un equipo
central de profesionales con dedicacin exclusiva, adems de aportaciones de
investigadores, estudiosos y profesionales de ms de veinte pases.
SPICE deba proporcionar el soporte necesario para la elaboracin de un nuevo
estndar. La realizacin de pruebas de campo sera una labor fundamental de la que
se deberan extraer los datos oportunos y derivar los anlisis que posibilitaran la
mejora del modelo en sus diferentes borradores. La promocin del nuevo modelo y
el seguimiento del mismo con objetivo de propiciar su evolucin seran 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 ao se celebr un encuentro en Mjico 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 Secretara del
SC7 las nueve partes de documento comenzando el perodo de votaciones. En la
actualidad el proyecto ha alcanzado el llamado Informe Tcnico. La norma
ISOIIEC 15504 ha rebasado, por tanto, el estado del borrador DTR (Draft
Technical Report) y tambin la votacin de los miembros del JTC1. El objeto de
este perodo es reexaminar la situacin del informe tcnico publicado y, si es
posible, alcanzar el acuerdo internacional necesario para la publicacin de un
estndar internacional que reemplace al mismo.
4.12. El futuro
Podemos predecir algo del futuro en la prctica del aseguramiento de la calidad

del software gracias a las actividades que esta disciplina est desarrollando hoy en
da. As mismo podemos inferir su desarrollo debido a la influencia que otras reas
de la ingeniera 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
unin con los estndares 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 auditora. Por ejemplo, ms
que examinar el contenido de un determinado fichero para evaluar el nivel de
cumplimiento de cierto modelo de documentacin se ha de comprobar la
documentacin 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 satisfaccin del cliente. Mientras
que en los primeros aos 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 resolucin de
problemas enlnea, bajada de actualizaciones o control enlnea son varias de las
posibilidades de esta nueva actividad que son ya una realidad.
El inters por la programacin orientada a objeto sigue creciendo, las prcticas
del aseguramiento del software debern adaptarse a este tipo de programacin.
La metodologa de desarrollo propiciada por la Administracin estatal espaola
MTRICA Versin 3. recoge de forma expresa el uso de tcnicas de desarrollo
orientadas a objeto.
El uso de lenguajes de cuarta generacin permiti un cambio del aseguramiento

del software hacia recursos de verificacin de diseo y cdigo para asegurar la
correcta aplicacin de los modelos de requisitos. Esta tendencia se acentuar y se
consolidar.
Ningn cambio en la tecnologa 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 intrnseca
entre la metodologa aplicada a los entornos orientados a objeto y los aplicados al
desarrollo de aplicaciones con lenguajes de cuarta generacin.
La filosofia de la administracin 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
compaa deben influir en el aseguramiento de la calidad del software y, por
supuesto, de las actividades de medida, anlisis, eliminacin de defectos y dems
aspectos que deben ser mejorados en este mbito. Se espera una influencia de
modelos y estndares (CMM, ISO-9000, ISO-15504 y modelos similares). No
parece, por lo tanto, discutible el auge que deber alcanzar una aplicacin de las
medidas ms estructurada. Estudios sobre la medida y su verdadera significacin
continan [Fenton, 921, [Curran y Sanders, 19941, [Fenton y Pfleeger, 19971.
5. CONCEPCIONES ERRNEAS Y PARADIGMAS DE LA CALIDAD
A pesar de la mayor sensibilizacin hacia la calidad, todava existen ideas

errneas que van en detrimento de la obtencin 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 administracin.
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 funcin de la deteccin y correccin de

errores es sustituida por la ms activa de prevenir los errores.
o Cumplir los estandares. El cumplimiento a rajatabla de los estndares de la
organizacin 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 aadir valor al producto.
o Invertir en calidad. La visin clsica de que la calidad se consigue
incrementando inspecciones y controles, los cules aumentan su costo, se
cambia por el enfoque hacia la calidad, disminuyendo los controles y
aumentando la prevencin, ya que por este camino se ahorra dinero.
o La calidad requiere tiempo. Si se logra reducir errores, se reducen los
tiempos de produccin, lo cual es una nueva reduccin 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 organizacin 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 implantacin de un sistema de calidad conlleva unos costes que, a medio y

largo plazo, revierten en ahorros y beneficios, tanto tangibles (econmicos) 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 prevencin y los costes
de la inspeccin o costes de evaluacin.
Como puede deducirse de la figura para aumentar el beneficio es necesario
reducir principalmente los costes de la no calidad.
6.1. Costes de prevencin
Son los costes en que se incurren para evitar la comisin de errores en

cualquier funcin de la empresa, desde el diseo a la venta, pasando por
administracin, personal, produccin, etc.
Algunos de estos costes son: revisin del diseo, programas de formacin,
evaluacin de proveedores, revisin de especificaciones, mantenimiento
preventivo, etc.
En contra de lo que generalmente se cree, la mayora 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 formacin
\ / Trabajo \ /
Operario: 20%
Figura 1.4. Origen de los fallos en una organizacin.

6.2. Costes de evaluacin
Incluye todos los gastos relacionados con la inspeccin de la produccin ya

terminada y de las auditoras sobre la conformidad de las funciones con los
criterios y procedimientos establecidos. Por ejemplo: las inspecciones, las pruebas,
el control de recepcin de los productos de los proveedores, la aceptacin 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 produccin. Antes o
despus de su entrega al cliente, incluyendo las acciones correctiva, la garanta o la
prdida de confianza del cliente.
Segn estudios de Arthur Andersen, la falta de calidad provoca las siguientes
consecuencias negativas para la empresa:
o Cuesta cinco veces ms obtener un cliente nuevo que retener a uno antiguo.
o Slo el diez por ciento de los clientes que han tenido una mala experiencia
vuelve a repetir la compra.
o Slo el cuatro por cientos de los clientes defraudados se lo comunica al
proveedor.
o Un cliente insatisfecho comenta su caso con, al mnimo, diez personas.
6.4. Relacin coste/beneficio
Segn 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 grfico de la figura 1.5 muestra como el coste total
mnimo 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 acta 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. Relacin costeheneficio de la calidad.

6.5. La Regla Federal Express
La empresa de mensajera urgente lder en Norteamrica, Federal Express,

considera que sus gastos anuales por acciones no previstas (errores en los destinos,
retrasos areos, reclamaciones de facturas, etc.) superan los 800 millones de
dlares, teniendo en cuenta los errores cometidos y la prdida 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 dlar por hora. Si
es detectado ms tarde, cuesta 10 dlares. Por ltimo, si es detectado por el cliente,
estos costes se elevan a unos 100 dlares.
Por consiguiente, es necesario hacer las cosas bien a la primera mediante la
estructuracin 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.
Captulo 2
LA MEDIDA DE LA CALIDAD DEL SOFTWARE

Una diferencia principal entre una "bien desarrollada"
ciencia como la fsica y algunas de las menos "bien
desarrolladas" ciencias tales como la sicologa o
sociologa es el grado en el cual las cosas son medidas.'
El objetivo actual de las industrias, incluida la industria de la produccin del

software, es la calidad. Pero para alcanzarla es necesario saber en qu situacin se
est, y por tanto es necesario estimar o medir la calidad. Se inicia este captulo con
las definiciones de estimacin y medida con sus respectivas caractersticas y
propiedades. Se presenta la teora de la medida y una aproximacin histrica a su
aplicacin a la industria del software. Se estudiarn, igualmente, las medidas ms
importantes propuestas en la historia breve, pero intensa, de la ingeniera del
software.
A mediados de la dcada 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 repetan 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 Matemticas Discretas y Teora de la Ciencia Computacional, consorcio
formado por las universidades de Rutgers y Princenton junto a diversas empresas tecnolgicas (AT&T, Lucent
Technologies, NEC, entre otras). Consultar la direccin de intemet http:// dimacs.mtgers.edu/index.html.
64 LA MEDIDA DE LA CALIDAD DEL SOFTWARE
[Marciniak, 19941. La situacin era de tal gravedad que la Organizacin del

Tratado del Atlntico Norte (OTAN) patrocin en otoo de 1968 una conferencia
internacional en Garmisch-Partenkirchen, Alemania, en la que se dieron cita medio
centenar de los ms afamados estudiosos de la disciplina informtica. Esta
convencin supuso uno de los ms importantes hitos en la moderna historia del
software. En ella no slo se reconoci el estado de crisis en el que se encontraba el
desarrollo de programas para ordenador, sino que tambin se aport la solucin. En
1968 se acu el concepto de "ingeniera del software" como una nueva disciplina
al servicio del desarrollo estructurado y metodolgico de los programas
informticos. La unin de estas dos palabras "ingeniera" y "software'', no fue un
hecho espontneo, tal y como reconocieron los propios organizadores. En las actas
se recogen diferentes apreciaciones en este sentido, siendo una de las ms explcita
la cita siguiente:
"La frase "ingeniera del software" fue deliberadamente escogida por

provocadora, dando a entender la necesidad de que la manufactura del
software se base sobre tipos de fundamentos tericos y disciplinas
prcticas, que son tradicionales en ramas establecidas en la ingeniera."2
Ms de veinte aos despus Norma E. Fenton se cuestiona ''Algo ha ido mal o

esperamos demasiado, demasiado pronto?"3. Esta pregunta se justifica, cuatro
lustros despus de la conferencia de Garmish, en la situacin 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 programacin de gran tamao que
entran en servicio, otros dos quedan cancelados. Los proyectos de

desarrollo de programas de tamao medio suelen consumir vez y media el
tiempo previsto, situacin que empeora en los grandes. Y alrededor de tres
cuartas partes de todos los sistemas de gran tamao son "fracasos
operativos", lo que significa que o no funcionan como se quera 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 traduccin es nuestra.
Fenton, Norman E. Sojiware Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. Pg 5 . La
Gibbs, W. Wayt. Licenciado en Fsica e Ingls por la universidad de Comell, afamado articulista de Scientijc
American, ha publidado numerosos artculos sobre el software y ciencias afines. Ha desarrollado labores de
investigacin en nanotecnologia y biotecnologia en el MIT. Consultar http:l/web.mit.edu/knight-sciencel
Gibbs, W. Wayt. "La crisis crnica de la programacin", Investigacin y Ciencia, Tendencias en Informtica.
Pg. 73.
2. NECESIDAD DE LA MEDIDA DEL SOFTWARE
2.1. La medida como elemento de mejora metodolgica
La respuesta a las reflexiones de Fenton nos la proporciona l mismo al

considerar que, a pesar de una clara aproximacin a un proceso metodolgico en el
desarrollo de programas informticos, ste no ha considerado la medida del
software con la profundidad y rigor que se requiere, "mejoras metodolgicas en
solitario no hacen una disciplina ingenierilW6.Parece evidente que el proceso
estructurado del desarrollo del software ha proporcionado una clara evolucin en la
programacin informtica, muy alejada de filosofa general de programacin
manejada en los orgenes de los ordenadores de propsito general, en la que el
tcnico desarrollaba el programa, lo probaba, correga e incluso utilizaba, tras un
proceso de creacin artesanal y sin apenas hacer uso de herramientas o
metodologa alguna. Pero este hecho no ha erradicado severos problemas tal y
como nos demuestra la estadstica mencionada en la ltima cita.
Bajo esta realidad podemos indicar que en estos momentos existe una clara
tendencia hacia la obtencin de medidas rigurosas, tambin en el software. No es
extrao encontrar referencias enrgicas en esta direccin aportadas por estudiosos
que nos hacen recordar otras declaraciones, no menos tajantes, enunciadas por
cientficos 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 ms all y
sentencia, "la produccin de software est fuera de control porque no se puede
medirm9.
La medida del software no es una aspiracin nueva, tal y como comprobaremos
en el siguiente apartado, pero quizs ha sido la dcada de los aos noventa aquella
en la que se ha reconocido toda la importancia que esta actividad posee. En la
conferencia celebrada en Pars Eurometrics 1991, H. D. ~ o m b a c h " perteneciente
Fenton, Norman E., op. cit. pg. 5. La traduccin es nuestra.

' DeMarco, Tom. Graduado por las universidades de Columbia, Cornell y La Sorbona de Pars, comenz su
carrera profesional en los laboratorios Bell. Ha trabajado en numerosos proyectos entre los que cabe destacar la
implantacin de sistemas informticos bancarios en Holanda, Suecia, Finlandia y Francia. En 1999 se le concedi
el premio Stevens por su contribucin a la ingeniera 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 traduccin es nuestra.
'O ~ o m b a c hH.
, Deiter. Profesor de Ciencia de la Computacin en la universidad de Kaiserlautern en Alemania. Ha
centrado su investigacin en la calidad del software y su medida. Consultar Encyclopedia of Software
al Software Engineering Laboratory (SEL), afirm "no deberamos preguntarnos

por ms tiempo si debemos medir, la cuestin hoy en da es cmo.""
2.2. La medida y el conocimiento
Las ciencias empricas, junto con las diferentes ingenieras, poseen en el

proceso de medida una larga tradicin y fundamentado conocimiento, alcanzado
gracias a siglos de investigacin y aportaciones de eminentes cientfico^'^. La
trascendencia que a esta actividad se le ha conferido queda patente en actitudes
reflejadas en citas como aquella que ilustra este captulo, u otras de no menos
compromiso o rotundidad. Lord Kelvin, el famoso matemtico y fsico britnico, a
finales del siglo pasado sentenciaba:
"Cuando puedes medir aquello de lo que hablas, y expresarlo en nmeros,

t conoces algo acerca de ello; pero cuando no puedes medirlo, cuando no
puedes expresarlo en nmeros, tu conocimiento es insatisfactorio y escaso:
podra ser el comienzo del saber, pero apenas has avanzado en tus ideas
hacia un estado ~ientfico"'~.
Medir es conocer, y este conocimiento nos permite avanzar sobre bases slidas.
Pero medir nos proporciona algo ms, nos posibilita aplicar las poderosas
herramientas que las matemticas nos ofrecen, facilitando la manipulacin de datos
con objeto de alcanzar una visin 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 atencin de este captulo, va ms all

de lo expuesto. La consecucin de nuevas, y cada vez ms exactas medidas, ha
impulsado la aparicin de novedosas tcnicas y sofisticado instrumental, pero
" Software Engineering Laboratory. Collected Software Engineering Papers. Vol.: X, SEL-92-003, November,
1992. Pg. 164. La traduccin es nuestra.
" Existen numerosos ejemplos que ratifican esta afirmacin. Muchos de ellos representaron el comienzo de una
nueva era para la investigacin o un avance sustancial en campos cientficos de muy diversa orientacin. Galileo
Galilei (1546-1642) invent el termmetro, paso fundamental para el desarrollo de la termodinmica. Evangelista
Torricelli (1608-1647) en 1643, realiz el experimento que permiti la invencin del barmetro. Henry Cavendish
(173 1 -181O), inventor de la balanza que lleva su nombre, permite el clculo de la masa de un cuerpo basndose en
la fuerza de atraccin ejercidas por ambas debido a la interaccin gravitacional. Willian Crookes (1832-1919)
invent el radimetro en 1875. Aparato diseado para la medida de la energa de una radiacin. O los modernos
sistemas del clculo de distancias basados en el haz lser, son ejemplos que nos permiten afirmar la importancia
que los cientficos de todas las pocas han dado a la obtencin de medidas fiables. Consultar enciclopedia Salvat
Universal. Barcelona. 1996.
l 3 Kelvin, Willian Thomson, referencia en: Alan L. Mackay. Diccionario de citas cientficas. Ediciones de la
Torre. 1992.
tambin ha provocado el progreso de disciplinas concretas, estimulando la

aparicin de innovadoras hiptesis de notable importancia. Medir, como tarea
cientfica en s misma, es un verdadero generador de nuevas teoras que han
permitido abrir nuevas perspectivas a muy diferentes campos de investigacin. Un
claro ejemplo de este hecho lo tenemos en el desarrollo terico del concepto de
"temperatura emprica" aportado por la termodinmica. Partiendo, en sus ms
remotos orgenes, de la concepcin fisiolgica de caliente y fro, la diferenciacin
entre calor y temperatura no fue correctamente interpretada hasta la intervencin en
1760 de Joseph ~ l a c k 'quien
~ aport la definicin de calor especfico. Casi un
siglo ms tarde, en 1843 James P. ~ o u l e determin
'~ el equivalente mecnico del
calor, asimilando esta entidad a la energa interna de un cuerpo tericamente
distinta de la concepcin de temperatura, definida como una funcin de estado, es
decir, dependiente de variables que permite especificar su estado de equilibrio
trmico. Una actividad tan habitual y aparentemente simple como es conocer la
temperatura a la que se encuentra una habitacin se apoya en un profundo y
cientfico conocimiento del atributo que est siendo medido.
Las ingenieras, como disciplinas que aplican el conocimiento cientfico sobre
construcciones o artefactos que nos son tiles, no son ajenas a la trascendencia del
proceso de medida. Modelos matemticos y teoras deben apoyarse en medidas
fiables. Si deseamos conocer la resistencia que cierto circuito elctrico 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 informacin errnea la ley de Ohm sera de muy difcil aplicacin.
Esta concepcin del desarrollo cientfico, apoyado en la obtencin de medidas
fiables, se encuentra avalada por el mtodo cientfico, verdadera columna vertebral
del conocimiento cientfico y tecnolgico, por lo que no nos ha de extraar el
trascendental papel que esta actividad ha jugado en el devenir cientfico desde hace
siglos.
l 4 Black, Joseph. Qumico y fisico escocs 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. Fsico britnico del siglo XIX. Estableci la teora mecnica del calor. Consultar
enciclopedia Salvat Universal. Barcelona. 1996.
3.1. Definicin y problemtica
La estimacin es el proceso de prediccin de la duracin, 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 estimacin
como la complejidad del proyecto, su estructuracin, el tamao, los recursos
involucrados y los riesgos asociados.
La estimacin es siempre difcil de realizar por diversas razones, entre las que
se encuentran:
No existe un modelo ni una frmula de estimacin universal.

Son muchas las personas implicadas en el proyecto, desde la alta direccin
de la empresa a los ejecutivos del proyecto, que precisan de las
estimaciones.
La utilidad de una estimacin varia con la etapa de desarrollo en que se
encuentra el proyecto.
Las estimaciones precisas son difciles de formular, sobre todo al inicio del
proyecto.
La estimacin suele hacerse superficialmente, sin tener en cuenta el
esfuerzo necesario para hacer el trabajo.
La rapidez del cambio de las metodologas y las tecnologas no permiten la
estabilizacin del proceso de estimacin.
Los estimadores pueden no tener experiencias.
El estimador suele hacer la estimacin en funcin del tiempo que a l le
llevara en realizar el trabajo, sin tener en cuenta la experiencia y formacin
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 duracin del trabajo se
ajustar como mnimo al tiempo disponible. Aadir 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 mtodos de estimacin
Adems de los mtodos algortmicos se suelen utilizar por su sencillez los

siguientes:
El juicio del experto
La realidad indica que el mtodo 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 histricas.
El mtodo de Wideband Delphi es una aproximacin que se puede definir como
un protocolo multipaso cuyo fin es hacer coincidir la opinin de un grupo de
expertos evitando as estimaciones parciales de individuos aislados. Los pasos a
ejecutar seran:
1. El coordinador del equipo tcnico de expertos presenta a cada uno de ellos

una especificacin de estimacin.
2. El coordinador convoca una reunin 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 estimacin.
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 reunin entre expertos.
6. Los expertos vuelven a emitir sus estimaciones de forma independiente.
7. Se repiten los pasos 2 al 6 hasta la obtencin de un valor en el que todos los
expertos estn de acuerdo.
Este mtodo tiene como desventaja evidente el alto coste en tiempo y recursos
humanos necesarios para su implantacin, as como la subordinacin al nivel de
experiencia y conocimientos en el entorno que puedan aportar los tcnicos.
Como ventajas se podran indicar que las estimaciones parciales son
neutralizadas y se presenta una estimacin global. Por otro lado las estimaciones
suministradas por este grupo de expertos difcilmente pueden ser obviadas gracias
a la trascendencia que la organizacin otorga a este proceso al proporcionar
costosos recursos a esta tarea.
La analoga
Se hace la estimacin de un proyecto nuevo por analoga con las estimaciones

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

aplicar a la ingeniera 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
estimacin del esfuerzo se hace en base a los recursos disponibles y no al producto.
La mejor oferta
Se procura conocer hasta cunto el cliente est dispuesto a pagar y cules son
las ofertas de la competencia. El valor que permite lograr el proyecto se toma como
estimacin del esfuerzo.
Las estimaciones global y detallada
La estimacin global, tambin denominada descendente, se hace teniendo en

cuenta las funcionalidades del producto, pasndose posteriormente al detalle.
La estimacin detallada o ascendente empieza por la estimacin 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 estimacin de De Marco
De Marco formul las siguientes nueve reglas, relativas a la estimacin:
1. Estimar no es repetir.
2. Estimar no es negociar.
3. Las estimaciones no admiten regateo.
4. Estimar no es dividir en partes una duracin 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 estimacin significativa, no sugiera la
respuesta.
7. Una estimacin til es una proyeccin en la que la probabilidad no es
optimista ni pesimista.
8 . El ratio entre la estimacin ms optimista y la til es medianamente

uniforme para cualquier persona.
9. Las estimaciones deben formularlas un comit.
3.4. Evaluacin de las estimaciones
Una primera evaluacin de una estimacin sera 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 frmula:
(Estimado - Real) 1 Real
Hay que tener en cuenta que los errores pueden ser de infravaloracin o de
sobrestimacin, 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 aos de la era de la programacin, la dcada de los cuarenta, el

hardware fue el principal objeto de estudio y atencin por parte de investigadores
y cientficos. Los emergentes sistemas de informacin automatizada giraban en
torno a los equipos y su optimizacin. Hoy en da, por el contrario, es el software el
componente que aporta un mayor valor aadido a estos sistemas. Si, adems,
consideramos que el soporte informtico es una actividad estratgica de primer
orden en la sociedad actual, no es extrao que el cumplimiento de plazos y costes
sea una exigencia inevitable en el proceso de creacin del software.
El conocimiento de costes y esfuerzos futuros permite prever la asignacin de
recursos adecundolos a las necesidades venideras.
Se presenta como evidente que estimar, es decir, conocer cul ser el valor de
cierta magnitud, no es una tarea simple, ms an en una disciplina joven como es el
caso del desarrollo de programas informticos, y en el que factores de muy diversa
naturaleza estn presentes. Sin embargo, esta decisin por vaticinar el futuro
basndose en datos del presente y en estudios anteriores, ha permitido un cierto
desarrollo de mtodos y modelos matemticos.
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 sern necesarios datos
de diferente naturaleza tal y como observaremos en los modelos que se explicarn.
Como paso previo a su estimacin definamos estos atributos.
El esfuerzo se entiende como el tiempo necesario para la realizacin 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 trminos econmicos.
4.2. Los principales modelos
Los modelos matemticos ms importante en la estimacin del coste y esfuerzo

son COCOMO, SLIM y Puntos de Funcionalidad, al que se dedicar un captulo.
Es posible que alguno de estos mtodos 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 tamao o en la medida de la calidad. Sin embargo, en este capitulo es
donde se har una explicacin ms extensa y detallada de los dos primeros.
El modelo COCOMO (COnstructive COst MOdel) fue ideado por Boehm, el
modelo Punto Funcin lo desarroll Albretch y el SLIM (Software, LIfe Cycle
Management) fue creado por Putman.
El modelo COCOMO y el de Punto Funcin pueden encuadrarse en aquellos
modelos empricos dependientes de una variable principal a los que se aaden
factores de ajuste relacionados con la productividad. Son dos claros ejemplos de
modelos estticos.
El modelo SLIM es un modelo dinmico que realiza una reparticin del
esfuerzo en funcin del tiempo.
4.3. COCOMO
El modelo COCOMO permite la estimacin del esfuerzo como una medida

indirecta del el tamao del cdigo fuente. Boehm present este mtodo en su libro
Software Engineering Economics, publicado en 1981.
El modelo de Boehm basa su estimacin del esfuerzo en la posibilidad de
conocer el tamao del programa, es, por tanto, una traslacin del proceso
predictivo desde un atributo (esfuerzo) a otro (tamao). Este modelo fue ideado
tras el estudio de 63 proyectos software realizados por el autor, y ha sido de
indudable impacto en la ingeniera del software.
El modelo COCOMO se basa en la existencia de tres niveles que han de

aplicarse segn el estado en que se encuentre el desarrollo del proyecto.
Modelo bsico. Se utiliza al principio del proyecto. La informacin que facilita

es una estimacin en cuanto al orden de magnitud del esfuerzo.
Las ecuaciones que rigen este modelo son:
E = a (KLOC)~ Ecuacin 2.1
T = C E ~ Ecuacin 2.2
Donde E es el esfuerzo expresado en personas-mes, el nmero de lneas de

cdigo 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 nmero de
meses estimados para el desarrollo.
Tabla 2.1. COCOMO bsico.
Los posibles modos son:
Orgnico. Equipos pequeos de trabajo. Existe un buen conocimiento de la

aplicacin y del sistema utilizado. Poca influencia de las comunicaciones.
Semiacoplado. Se sitan en una posicin media en cuanto a complejidad y

tamao, entre el modo Orgnico 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 validacin muy elevados. Requisitos estrictos e
inamovibles. Un ejemplo claro lo tendramos 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, mtodos y personal). Lo valores de las
constantes tambin se ven afectadas.
En este caso la ecuacin es:
E = a ( K L D C )m(x)
~ Ecuacin 2.3
Donde E, KLOC, a y b tienen el mismo significado que en el caso del

COCOMO bsico. Aunque el valor de los parmetros a y b son diferentes (tabla
2.2).
El valor m(x) es el peso del factor de coste xj, y cuya expresin matemtica es:
15
m(x)=n Ecuacin 2.4
El valor m(x) en el caso del modelo bsico tiene como valor fijo la unidad.
Boehm consider quince factores de coste diferentes, agrupados segn el
siguiente esquema.
1 . Atributos del producto.

1 . 1 . Fiabilidad requerida.
1.2. Tamao 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 ejecucin.
2.1.2. Restricciones de memoria.
2.1.3. Inestabilidad de la mquina virtual.
2.1.4. Tiempo de espera requerido.
2.2. El personal.
2.2.1. Capacidad de anlisis.
2.2.2. Capacidad del ingeniero de software.
2.2.3. Experiencia en aplicaciones.
2.2.4. Experiencia con mquina virtual.
2.2.5. Experiencia con lenguaje de programacin.
2.3. Mtodos y herramientas.
2.3.1. Prctica de los mtodos modernos de programacin.
2.3.2. Utilizacin de herramientas de software.
2.4. Tiempo.
2.4.1. Planificacin 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 pblicas
por Boehm se asigna un valor numrico a cada factor y se aplica la ecuacin 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 gua 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 tamao del proyecto en KLOC y derivar una prediccin del
esfuerzo.
3. Determinar el valor de los 15 valores de ajuste.
4. Hacer uso de la ecuacin de estimacin del esfuerzo.
5. Hacer uso de la ecuacin que estima el tiempo de desarrollo.
El modelo COCOMO posee un claro inconveniente al involucrar la evaluacin

del nmero lneas de cdigo en el propio sistema de prediccin. Por otro lado la
seleccin del modo de desarrollo es extremadamente importante. El modelo
COCOMO es un modelo muy dependiente de datos histricos de la organizacin
que no siempre estn 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 tcnico
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 distribucin del esfuerzo en un

proyecto software viene especificado por la denominada curva de
RayleighINorden. Esta curva se obtuvo basndose en datos recopilados por Norden
y las descripciones analticas de las curvas realizadas por Lord Rayleigh.
Putnam propuso la siguiente "ecuacin del software".
L = CkK113 td413 Ecuacin 2.5
Donde L es el nmero de lneas de cdigo esperadas en magnitudes de

sentencias fuente, Ck es una constante dependiente del nivel tecnolgico en el que
se desarrolla la aplicacin, suele obtenerse gracias a datos histricos recopilados de
desarrollos anteriores. El factor K es el esfuerzo de desarrollo expresado en
personas-aos y finalmente tdes el tiempo de desarrollo expresado en aos.
De la ecuacin 2.5 podemos obtener fcilmente la ecuacin:
',
K = / td4) Ecuacin 2.6
L ~(ck3
De esta segunda ecuacin podemos deducir interesantes conclusiones. El factor

td al estar afectado por una potencia tal alta indica que pequeas variaciones en el
tiempo de entrega pueden modificar enormemente el esfuerzo a realizar. Por otro
lado tambin observamos la dependencia de este modelo del valor asociado a Ck ,
hecho que gran cantidad de especialistas consideran una desventaja, ya que
pequeas 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 aceleracin de la potencia de trabajo como
D , = K I ~ ~ ~ Ecuacin 2.7
LA CALIDAD DEL SOFTWARE Y S U MEDIDA 77
Esta ecuacin es sumamente til a la hora de comparar los modelos de Boehm y

de Putnam. El tiempo de desarrollo es proporcional a la raz cbica 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 tambin
similar al exponente del modelo COMOCO que oscilaba entre 1,05 y 1,20. El
valor Do toma valores especficos 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
reutilizacin de cdigo el valor es de 27.
El modelo de Putnam ha recibido algunas crticas como es el hecho de que las
curvas de Rayleigh y Nordem no consideran la fase de especificacin de requisitos,
por lo que no se tiene en cuenta esta fase del desarrollo en la correspondiente
ecuacin propuesta por Putnam. Por otro lado algunos tcnicos consideran difcil
utilizar este modelo en entomos de desarrollo pequeos. Esta limitacin tiene su
origen que los datos recopilados para su creacin han sido tomados en entornos de
desarrollo grandes.
Q 1 2 3 4 5
Figura 2.1. Aproximacin 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 ms adecuada es la propuesta por Norman E. ent ton'^ que
define la accip de medir de la siguiente forma:
o Medir. Proceso a travs del cual nmeros o smbolos 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 asignacin objetiva y emprica de un nmero

(o smbolo) 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 medicin de otros atributos (uno o varios) 19.
En numerosos casos la obtencin de medidas indirectas es enormemente til.

Atributos, de muy diversa naturaleza, pueden ser estudiados ms 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 mtrica. Para evitar confusiones y sentar una definicin objetiva definimos
mtrica 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, mtodos formales y aspectos
tericos de la ingeniera del software. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
l7 Fenton, Norman E. Sojiware Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. Pg. 3. La
'' Fenton, Norman E., op. cit. pg. 17. La traduccin es nuestra.
l9Fenton, Norman E., op. cit. pg. 19. La traduccin es nuestra.
o Mtrica. La caracterizacin numrica de un atributo "simple" en

contraposicin al concepto de medida, entendido como funcin cuyos
parmetros sern las mtricas obtenidas y que nos permitirn estudios de
atributos ms complejos20.
Evidentemente en el entorno de la medida del software el concepto "mtrica" no

tiene relacin con el concepto asociado al espacio mtrico propio de la topologa en
las matemticas.
Las definiciones anteriores unidas a la teora representacional de la medida que
a continuacin introduciremos nos permiten definir un marco terico apropiado del
que luego haremos uso para ajustarlo definitivamente al medio informtico.
5.2. Teora general de la medida
La teora de la medida se sustenta en el teorema de representacin, teorema de

unicidad y la definicin del sistema de relacin. Expliquemos cada uno de ellos.
El "sistema de relacin emprico" tiene como funcin determinar las
propiedades (o axiomas) acerca de los atributos, las cuales capturan cualquier
comprensin intuitiva u observacin emprica sobre los mismos. La medida es
precedida del concepto (recordemos el desarrollo de la nocin de temperatura
emprica reseada en el apartado anterior), de forma que un atributo ha de ser
caracterizado a partir de las relaciones empricas que podamos establecer, primer
paso hacia la consecucin de su medida.
De manera formal, los atributos se encuentran caracterizados por un conjunto de
relaciones empricas " R , que unido al de entidades "C", constituyen el
denominado sistema de relaciones empricas.
En lenguaje propio de las matemticas podemos escribir:
c (C, R)
siendo:
C: Sistema de relacin emprico.

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

de la siguiente manera:
20
donde las relaciones involucraran elementos del conjunto C.
Habramos establecido el sistema de relaciones emprico, primer paso hacia la

medida de los atributos propios de las entidades estudiadas. Se nos presenta como
evidente que un aumento en el nmero de relaciones que pueden establecerse
implica un mayor conocimiento de la entidad estudiada.
Una vez establecido el sistema de relacin emprico, y tomando ste como base,
se ha de establecer el denominado "sistema de relacin numrico", consistente en
un conjunto de nmeros y una o ms relaciones definidas sobre los mismos. Cada
relacin propia del sistema emprico ha de tener su correspondiente relacin en el
sistema numrico.
Matemticamente:
N CN, P)
siendo:
N: Sistema de relacin numrico.

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

numricas en funcin al sistema emprico.
donde las relaciones involucraran elementos del conjunto N.

Una vez definido el sistema emprico y su correspondiente sistema numrico

estamos en disposicin de definir la medida de un atributo.
La medida de un atributo es una correspondencia desde un sistema de relacin
emprica (C,R), para el atributo, sobre un sistema de relacin numrica (N,P). La
relacin, M, har corresponder entidades del conjunto C en "nmeros", esto es,
entidades del conjunto N, adems de hacer corresponder cada relacin R en una
relacin en P. Como requisito adicional se ha de cumplir la "condicin de
representacin" que implica el que toda relacin emprica ha de ser mantenida en el
sistema de relacin numrico. Si la relacin M cumple esta condicin se denomina
homeomorfismo o representacin.
En simbologa matemtica podemos escribir:
En diagramas de Venn y considerando los ejemplos indicados arriba, la

correspondencia podra expresarse:
Figura 2.2. Diagrama de Venn para la relacin M.
La condicin de representacin requiere que medir sea el establecimiento entre

entidades en C y nmeros, de tal forma que las relaciones en C inducidas por el
atributo impliquen y sean implicadas por las relaciones entre sus imgenes en el
conjunto de nmeros elegidos. La condicin de representacin puede ser vista
como la definicin formal de aquello que nosotros queremos hacer significar a
travs de la medida, describiendo o caracterizando un atributo.
5.3. Escalas
Bajo este soporte terico definimos el concepto de "escala" como la tripleta

(C,N,M). En muchos casos, cuando los sistemas de relacin numrico y emprico
se nos presentan como evidentes la notacin se simplifica y asociamos la definicin
de escala con el smbolo que indica la correspondencia, es decir M.
Pueden existir diferentes escalas al poder definir varias representaciones para un
mismo sistema emprico en estudio. Para un sistema de relacin dado, cualquier
correspondencia que transforme una representacin M en otra representacin M'
vlida, se denomina representacin admisible. El tipo de transformacin admisible
para un determinado sistema de relacin emprica define cun 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 ms habituales,
hecho que definir el tipo de escala que estemos utilizando en un momento dado.
"F" asignacin uno a uno

M' = F(M)
"F" montona 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 ms habituales.
Basndonos en los conceptos estudiados de escala describamos la nocin de

"significacin" en el entorno de la medida de atributos. Esta definicin ser til a la
hora de establecer las limitaciones sobre el tipo de manipulaciones matemticas 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 numricas es significativo si su
verdad (o falsedad) permanece inalterable si cada escala M implicada es
reemplazada por una escala aceptable M'. La relacin M' es una escala aceptable si
puede derivarse de la relacin M por una transformacin admisible.
6.1. Los orgenes
El deseo de obtener valores numricos que representan atributos propios del

desarrollo y ejecucin de programas para ordenador ha sido una aspiracin para
investigadores y estudioso desde hace ms de treinta aos.
Uno de los primeros y principales trabajos que de forma ms importante han
influenciado en la teora aplicada a la medida del software, fue publicado en 1964
por arquitecto britnico Chistopher Alexander, lo titul Notes on the Synthesis of
Form. En su escrito Alexander describi la naturaleza del proceso de diseo segn
su ptica. Para este investigador un ingenio ha sido bien diseado si los
componentes que forman parte de l son relativamente independientes entre s.
Alexander finalizaba su escrito presentando un programa informtica cuya
aplicacin sera ayudar a tcnicos y profesionales en la tarea del diseo. Este
programa aceptaba como datos de entrada las relaciones existentes entre los
diferentes componentes del artefacto. Haciendo uso de un anlisis en racimo
proporcionaba como resultado un diseo en el que se pretenda minimizar en
nmero de componentes del mismo. Como podemos apreciar la relacin del trabajo
de este arquitecto con la prctica informtica se produce exclusivamente en el
desarrollo del programa que ide para ayudar a extender su visin en el diseo
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 concepcin adecuada para el proceso de creacin de productos software. Ms
adelante, en este mismo captulo, podremos apreciar hasta que punto las ideas de
Christopher Alexander han condicionado la investigacin 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
tericas, que van desde la sicologa del conocimiento, teora de la informacin o la
termodinmica, hasta concretar un proceso de medida determinado. La filosofa
bsica en la que asent su teora fue que la comprensin del software era similar al
proceso mental de manipulacin de seales. Halstead defini un conjunto de
medidas que pueden ser extradas del cdigo fuente del programa. Su influencia en
'' Halstead, Maurice H. Graduado en meteorologa 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 mtricas del software a las que inicialmente las denomin "Termodinmica
del Software". Consultar el sitio www.itee.uq.eduau.
la teora informtica ha sido muy importante y su trabajo fue utilizado en la

industria adems de ser impulsor de la concepcin de la medida del software como
actividad de principal inters para el desarrollo informtico. La influencia de este
investigador se extendi de forma definitiva durante la dcada de los setenta y
primeros aos 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 teora propuesta por
Halstead para evaluar el grado de modularizacin de un sistema [Baker, 19791.
curtisZ4y SUS colegas intentaron demostrar que cierto parmetro definido por
Halstead [Halstead, 19771 era un buen sistema de prediccin del tiempo de
correccin de errores [Curtis et al, 19791. stos son algunos de los muchos
ejemplos que podramos aportar.
La teora de Halstead perdi numerosos adeptos a mediados de la dcada de los
ochenta. Este hecho se basa en ciertos contenciosos conceptuales que esta teora no
lleg a superar [Fenton, 19921:
o Muchas de las asunciones sobre la sicologa cognoscitiva en la que se bas

Halstead se consideran ahora errneas.
o Muchos de los experimentos realizados se encuentran pobremente
diseados y los resultados obtenidos posean errores estadsticos. La teoria
propuesta se basaba en medidas de carcter general, de forma opuesta a la
actual consideracin de medidas especficas que respondan a preguntas
concretas.
o Las medidas propuestas se basaban en el cdigo del programa, de forma
preponderante. Este hecho supone un grado de limitacin muy elevado para
el programador, que tiene poca libertad de accin a la hora de alterar el
curso del proyecto ya que muchos recursos han sido ya utilizados pues la
aplicacin ha pasado por varias fases que, quizs, deberan 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 prcticamente eliminadas del contexto industrial, a excepcin de algunos
experimentos aislados. A pesar de esta afirmacin hemos encontrado investigadores
22 Baker, A.L. Matemtico britnico condecorado con la Medalla Fields en 1970 por su trabajo en el campo de la
teora de los nmeros. 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
Informacin y la Computacin. Estudioso de la ingeniera 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, diseo de
interfaces o factores humanos y de organizacin que afectan al proceso software. Doctor por la universidad
Cristiana de Tejas, entre otros ttulos, ha publicado casi un centenar de artculos 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 crticas que ahora recaen sobre su teora.
6.3. El control de flujo de programas
A mediados de la dcada de los setenta surgi un gran inters por la medida del
software basado en el control de flujo de un programa o mdulo. Este hecho
coincidi con el auge de la programacin estructurada como aproximacin sensible
al desarrollo detallado del diseo de mdulos. En este contexto terico un sistema
un programa fcil de leer, desarrollar, mantener y corregir es aquel que se
encuentra diseado bajo un limitado nmero de estructuras de control.
La medida clsica del control de flujo es la denominada "complejidad
ciclomtica". Esta medida fue desarrollada por el cientfico 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
teora grfica, relacionada directamente con el nmero de "caminos" asociados a
un programa o mdulo. McCabe postul que un valor elevado de la complejidad
ciclomtica de un grafo que representa un mdulo o programa de forma directa,
implicara un grado elevado de dificultad en las propiedades de comprensibilidad y
facilidad de prueba. La razn de este discernimiento es que un valor elevado en la
complejidad ciclomtica implicara 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 implicaran un
mayor nmero de caminos a explorar al realizar pruebas de datos.
El trabajo de McCabe de 1976, es de obligada referencia en cualquier texto de
ingeniera del software al ser uno de los modelos ms originales y copiados de la
historia de la medida del software.
A pesar de este hecho han aparecido estudios crticos sobre la medida propuesta
por McCabe. Se demostr que muchos de los experimentos eran estadsticamente
sospechosos y que la complejidad ciclomtica no proporciona mejores predicciones
que aquellas que nos ofrece el modelo de las lneas de cdigo. Esta afirmacin se
soporta sobre numerosas experiencias empricas [Fenton, 19921.
Existen, adems, otras crticas realizadas hacia esta teora grfica. Por un lado la
falta de trascendencia dada por este modelo a las condiciones de un mdulo o
programa. As, por ejemplo, dos mdulos con igual complejidad ciclomtica son
enormemente distintos debido al uso de mltiples operadores booleanos,
expresiones aritmticas complejas o abuso de los "flags" en el programa. Otros de
25
MacCabe Thomas, J. Licenciado en matemticas por las universidades de Privilence y Connecticut. Prestigioso
consultor y autoridad en las reas de la calidad del software, tcnicas de validacin 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 ciclomtica, pero uno de ellos puede ser mucho ms difcil
de entender que el otro debido al nmero y extensin 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 crticas.
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 aplicacin de
las medidas del software de enorme potencial. Si un programador utiliza un
detallado diseo, de forma que sea isomrfico con el cdigo final generado,
medidas tales como la complejidad ciclomtica pueden ser utilizadas durante la
fase de diseo detallado del programa.
Una de las mayores crticas vertidas sobre el modelo de McCabe es que haya
sido utilizado para medir ms factores de calidad que aquellos para los que fue
ideado. Muchos trabajadores, escondidos tras el paraguas del trmino complejidad,
han errneamente extendido ste hacia reas donde McCabe nunca intent ir.
6.4. Sistemas de diseo
Si la dcada de los setenta puede definirse como el decenio de la programacin

estructurada los ochenta se pueden caracterizar como la dcada de los "sistemas de
diseo". La caracterstica ms significativa de esta concepcin del desarrollo de
programa para ordenador se centra en restar trascendencia a la fase de
programacin, recayendo el peso del desarrollo sobre tareas anteriores a sta, tales
como la captura de las especificaciones del sistema o la fase de diseo. Esta
concepcin se inspir en la industria tradicional y es dnde las tesis propuestas por
Christopher Alexander alcanzan su mayor influencia tras casi veinte aos desde su
publicacin.
Tal como propuso Alexander la idea principal de los modernos sistemas de
medida estn basados en la idea de que el sistema software es aquel en el cual los
componentes del mismo (subrutinas, mdulos, rutinas) son relativamente
independientes y se encuentran aislados entre s. Estos sistemas tienen la propiedad
de que sus mdulos son fciles de entender, corregir y probar. El diseo
estructurado de Yourdon tiene como elemento sustancial de su mtodo de
programacin las ideas originales de Alexander, y los trabajos sobre la abstraccin
de datos propuestos por David ~ a r n a s o~ los
~ , iniciales intentos de caracterizar la
26
Pamas, David Lorge. Profesor de Ingeniera Computacional y Electricidad de la universidad de McMaster,
Ontario. Miembro de Laboratorio de Investigacin de Comunicaciones del Instituto de Telecomunicaciones de
Ontario. Autor de ms de 150 publicaciones orientadas al estudio de la estructura del software, diseo de
complejidad del sistema, fueron catalizadores de esta visin y su aplicacin a los

modernos modelos de medida. El modelo de ~ a f u r a ~y' ~ e n r pes,
probablemente, el diseo ms utilizado desarrollado hasta ahora. La idea principal
de este sistema es que la complejidad es medida en trminos de flujos de
informacin y que aquellos mdulos ms complejos del sistema son aquellos a los
que fluyen ms datos.
6.5. Costes y esfuerzos
En paralelo con el trabajo sobre la medida de los sistemas de diseo, los ltimos
aos de la dcada de los setenta y los primeros aos de la dcada de los ochenta
vieron algunos trabajos derivados de las medidas de las especificaciones. Las
medidas extradas 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 tamao 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 ms populares.
Un problema achacado al punto de funcionalidad es que asume un limitado
nmero de aplicaciones tipo, principalmente sistemas basados en ficheros de gran
volumen, muy propios de entidades financieras, pero no puede considerarse en
sistemas hbridos tales como aquellos de control de stocks con un gran componente
de comunicaciones. En los primeros aos de los ochenta DeMarco present una
medida llamada " BANG que intentaba superar este hecho apoyado en factores de
ajuste que dependan 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 matemticas por la universidad de San Francisco y doctor por la universidad
de Purdue, actualmente es responsable del Departamento de Ciencia de la Computacin del Instituto Politcnico
de la universidad de Virginia. Su labor investigadora ha alcanzado la programacin orientada a objeto,
computacin paralela, seguridad informtica, mtricas, entre otros campos. Consultar Encyclopedia of Software
28
Henry, Sallie. Doctora en Ciencia de la Computacin por la universidad del Estado de Iowa, ha trabajado en los
campos de la medida del software, metodologias de diseo y programacin orientada a objeto. Consultar el sitio
http://www.cs.vt.edu/
29
Albrech, Allan J. Internacionalmente conocido como inventor de la medida denominada anlisis del punto
funcin. Graduado por la universidad de Bucknell en 1949 como ingeniero elctrico y electrnico, 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. Cientfico con ms de cuarenta aos de experiencia, fue pionero en la medida del software
desarrollando la tcnica denominada puntos funcin MKII. Comenz su carrera en el uso de ordenadores aplicados
a la energa atmica. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
La medida de una aplicacin a travs de los puntos de funcionalidad posee hoy

en da una extensin mundial, aunque se ha implantado de forma ms amplia en los
Estados Unidos de Amrica, Australia, Japn y algunos pases europeos. En estas
localizaciones han aparecido asociaciones de usuarios de gran influencia y que a
travs de foros de debate y cursos extienden este modelo por todo el mundo3'.
En los ltimos aos de la dcada de los setenta se increment el inters por la
medida de las pruebas estructurales. Un nmero 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 dcada de los setenta y en la dcada de los ochenta los
programadores encontraron sus mayores problemas en el coste y estimacin del
proyecto software. El deseo era encontrar un modelo que tuviera un nmero de
entradas y que produjera alguna forma de estimacin de recursos para el proyecto.
Los problemas de la estimacin del coste.
El mtodo ms conocido es el modelo COCOMO desarrollado por el cientfico
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 travs de
cuarenta y siete preguntas y de las correspondientes respuestas se deduce el valor
de sesenta y ocho parmetros. La filosofa del proyecto es desarrollar un programa
de esfuerzos, niveles de equipos, documentacin 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 atencin de numerosos investigadores.
Sin embargo an hoy en da existen algunos problemas que todava no han sido
resueltos:
o Falta de madurez en la medida del software.

o Inexistencia de estandarizacin en las medidas.
o Medidas del software an no ampliamente aceptadas [Zuse, 19981.
"un ejemplo de este tipo de organizaciones es la denominada en ingls Intemational Function Point Users Group
(IFPUG). Entidad orientada al desarrollo y mejora de la tcnica de medida del punto funcin y de su extensin
alrededor del mundo.
32 Boehm, Bany. Profesor de Ingeniera del Software y Director del Departamento de Ciencia Computacional en el
Centro de Ingeniera del Software. Doctor ingeniero por la universidad de UCLA en 1961, ha realizado numerosas
aportaciones a la ingeniera del software, tales como el modelo COCOMO, el Modelo Espiral o aproximaciones
tericas a la administracin del software, entre otras. Consultar Encyclopedia of Software Engineering, John Wiley
& Sons, 1994.
7. LA MEDIDA DEL SOFTWARE
7.1. Marco terico
Tras definir concepto bsicos, propios de la teora de la medida, este apartado

propone un marco terico 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 bibliografa bsica en este apartado aunque
introduciremos aportaciones de otros autores que refuercen este acercamiento
terico al proceso de medida de programas informticos, aportaciones que
indicaremos puntualmente.
La realizacin de medidas aplicadas en un entorno propio del desarrollo de
programas informticos necesita definiciones concisas que identifiquen claramente
las entidades a estudiar as como aquellos atributos que sern objeto de dichas
medidas.
Procesos, productos y recursos sern los entes objeto de estudio en este entorno.
A continuacin los definimos y acompaamos estas definiciones con ejemplos que
pretendemos aclaren definitivamente estas exposiciones.
Procesos. Sern 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 podran ser desde la construccin de especificaciones

hasta el propio desarrollo del sistema software, desde la captura de los requisitos
hasta la liberacin 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 podramos indicar la documentacin propia de

las especificaciones o del diseo, representacin del cdigo fuente u objeto, entre
otros.
33
Fenton, Norman E. Sofmare Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. La traduccin es
nuestra.
34
Fenton, Norman E. Sofhoare Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. Pg. 42. La
Recursos. Se deJinen como un conjunto de entidades considerados como

entradas para la produccin del software35.
Ejemplo de recursos sera el personal implicado, herramientas utilizadas o

mtodo manejado.
Una vez definidos las entidades que sern objeto de nuestra atencin hemos de
considerar los atributos a medir. Como primera aproximacin indiquemos una muy
fundamental divisin de los mismos en dos tipos bien definidos. "Atributos
directos" como aquellos que pueden ser medidos en trminos de las entidades a
estudiar y "atributos indirectos", definidos como aquellos que slo pueden ser
medidos por medio de cmo productos, procesos y recursos se relacionan con su
entorno.
Basndonos en las entidades consideradas anteriormente, podemos encontrar un
nmero determinado de atributos de inters.
Asociados al estudio de los procesos, como atributo interno, Fenton aporta un
nmero limitado de stos. Tiempo, entendido como duracin del proceso, esfuerzo
asociado al proceso y nmero de incidentes de cierto tipo que pueden acaecer
durante el proceso estudiado. Evidentemente podemos encontrar numerosas
combinaciones de medidas directas cuyo resultado sera la pertinente medida
indirecta que, recordemos, pueden ser de igual e incluso de mayor inters que las
medidas directas. Ejemplos de atributos externos podramos citar la estabilidad,
coste, calidad, entre otros.
Atributos internos propios de los productos seran, longitud, funcionalidad,
redundancia, grado de acoplamiento etc. Como atributos externos podramos citar
la comprensibilidad, facilidad de mantenimiento, fiabilidad.
En el caso de los recursos, podramos citar como atributo interno la edad o
sueldo (del programador), nivel de comunicacin 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 ergonoma 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 slo pueden ser medidos de forma
indirecta, segn 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 relacin 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
combinacin de stos nos puede proporcionar una informacin muy interesante y
35
ser tan abundante como la combinacin de atributos internos sea posible. La tabla
2.6 muestra algunos atributos y su entidad asociada. segn la visin "METKIT".
Tabla 2.5. Ejemplos de atributos internos y externos.
Dos ltimas definiciones nos permitirn finalizar este repaso terico a la medida
del software.
El fin ltimo del proceso de medida es el clculo de alguna magnitud conocida
o predecir un atributo an inexistente. Este hecho nos lleva a dos definiciones
importantes.
Modelo. Entendido como una representacin abstracta de un objeto36.
Podemos dividir los modelos existentes en representaciones abstractas de varios

productos, procesos o recursos. Tales modelos capturan atributos que estn siendo
medidos sin ambigedad posible. Por otro lado existen modelos que indican
abstractas representaciones entre atributos de entidades. Estos modelos relacionan,
por lo general, ms de dos medidas a travs de una frmula matemtica.
Pero la consecucin de un modelo no es suficiente para desarrollar un proceso
de prediccin. Necesitamos determinar parmetros para el modelo e interpretar los
36
Fenton, Norman E. SofhYare Metrics. A Rigorous Approach. London, Chaprnan & Hall, 1992. Pg. 48. La
resultados de forma correcta. Basndonos en esto podemos definir:
Sistema. Sistema de prediccin como un modelo matemtico junto a un

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

seran actividades que se realizan
en cualquier proyecto.
Productos Es cualquier herramienta, servicio Para Mantenimiento,

o, en general, resultado, derivado documentacin: Movilidad,
de los procesos ejecutados. Salida longitud, Reutilizacin etc.
de los mismos. modularidad,
redundancia etc.
Para cdigo o
diseo formal:
estructuracin,
acoplamiento etc.
Recursos Cualquier tipo de entidad Edad del Productividad,
considerada como entrada para la personal, salario, experiencia,
produccin del software. Pueden velocidad del fiabilidad,
ser de muy diversa naturaleza. equipo hardware capacidad de
Herramientas, mtodos, (entre otros) reutilizacin (entre
materiales, son ejemplos de otros)
recursos.
Tabla 2.6. Entidades objeto de medida segn el marco terico propuesto.
Las definiciones expuestas nos permitirn abordar el proceso de medida del

software bajo una base cientfica.
37
Fenton, Norman E. Op. Cit. pg. 48. La traduccin es nuestra.
8. LA NORMA ISOlIEC9126
No podemos acabar este captulo 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 travs de una metodologa de
amplia utilizacin en las ciencias empricas como es la descomposicin jerrquica
en rbol. Considera la medida de la calidad a travs 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 tambin propone
un procedimiento de medida con objeto de ser una referencia de carcter
internacional.
Estudiaremos en detalle esta norma en el captulo VII.
Uso de recursos
fallos aprendizaje para cambios instalacin
Capacidad de Adherencia
Interoperatividad Operatividad Estabilidad Coexistencia
recuperacin 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.

Captulo 3
NORMALIZACI~NY CERTIFICACI~N:
NORMA ISO 9001:2000
El aseguramiento de la calidad es un modelo
planificado y sistemtico para proporcionar una adecuada
confianza en que un producto es conforme con los
requerimientos tcnicos establecidos'
Unido a los conceptos metodologa y modelo aparece habitualmente el de

norma. En el mbito de las comunicaciones y la informtica existen organizaciones
nacionales y, ms habitualmente, trasnacionales que adoptan estos modelos y
metodologas promoviendo su conocimiento y utilizacin. Cuando un modelo o
metodologa es adoptado por una organizacin de estas caractersticas adquiere el
rango de norma.
Un concepto muy unido al de normalizacin (o norma) es el de certificacin. Es
habitual el que un organismo que recomienda una determinada norma, establezca la
posibilidad de certificar a una empresa, profesional, institucin, colectivo etc. en
dicha norma. Con esta accin lo que se pretende es asegurar, dar fe, sobre el grado
de implantacin de la norma en la empresa certificada.
Se tratar en este captulo de la normalizacin y de la certificacin, as como de
las normas y entidades de certificacin, prestando especial atencin 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. Pg. 60. La traduccin es nuestra.
Las normas son reglas metodolgicas y modelos adoptados por organizaciones
nacionales o internacionales que se dedican al establecimiento de estndares. Estas
organizaciones se apoyan en foros de expertos que se suelen constituir en comits
muy cualificados.
La Organizacin Internacional para la Estandarizacin, ms conocida por sus
siglas en ingls, ISO, propone gran cantidad de normativa en numerosos campos
tecnolgicos, y es un claro ejemplo de este tipo de instituciones. Su homlogo
nacional es AENOR, Asociacin Espaola de Normalizacin. Las normas
propuestas por la ISO, o por cualquier otra organizacin de caractersticas
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 Elctrica y de Electrnica
Norteamericano (IEEE), la Agencia 9Espacial Norteamericana (NASA) son
instituciones, entre otras muchas, especialmente activas en la publicacin de
normativas de gran impacto mundial.
Las empresas que siguen una determinada norma suelen querer demostrarlo
mediante el correspondiente certificado de la organizacin generadora del estndar,
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 certificacin, inicialmente, slo se haca sobre el grado de cumplimiento de
un determinado producto industrial sobre una determinada norma tcnica, y que,
por consiguiente, no era necesario comprobarlo a cada momento. La certificacin
alcanz tal difusin y prestigio que las empresas de servicio tambin 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 fabricacin del software; un programa es
diferente a otro y una aplicacin no tiene nada que ver con otra aplicacin. 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 metodologa
que, con una alta probabilidad, dar lugar a un servicio (software) de calidad. Se
certifica, en definitiva, el mtodo con el que la empresa desarrolla el producto final,
en este caso la aplicacin informtica.
La certificacin ms 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 Espaa, la certificacin ms 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:
Gestin de la calidad del software2 (Software Quality Management)
"Aspecto de la funcin general de la gestin que determina y aplica la poltica

de calidad (objetivos y directrices generales de calidad de una empresa)." Esta
gestin puede hacerse a nivel de proyecto o a nivel de empresa, es decir, a nivel
estratgico.
Aseguramiento de la calidad del software3 (Software Quality Assurance)
"Conjunto de actividades y sistemticas 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 garanta de calidad.
Control de la calidad del software5 (Software QualiS Control)
"Tcnicas y actividades de carcter 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 organizacin I E E E ~la define como "el proceso de
verificar el propio trabajo o el de un compaero".
Verificacin y validacin del Software ( V y V ) .
Es un concepto especfico de la industria del software La verificacin

comprueba que el software funciona, es decir, que tcnicamente se ha construido
AENOR. Normas para la gestin 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 validacin 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 organizacin, las actividades se orientan hacia la
consecucin de una estructura organizativa centrada en la calidad, en la que todas
las unidades (administrativas, de produccin, 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 translacin de lo
dispuesto en el sistema de calidad a las actividades del proyecto, siendo necesaria
la adaptacin de las disposiciones generales a cada proyecto. En la industria del
software, se aplicarn las tcnicas de evaluacin y control de la calidad del
software a todas las fases del ciclo de vida.
4. LOS SISTEMAS DE CALIDAD
4.1. Definicin
La norma ISO 9000lUNE 66900 define un sistema de calidad como: "La

estructura de organizacin, de responsabilidades, de actividades, de recursos y de
procedimientos que se establecen para llevar a cabo la gestin de calidad".
Como consecuencia de esta definicin, el sistema de calidad debe ser
concordante con los objetivos de calidad de la empresa, definidos en la poltica de
calidad de la misma, que es una parte de la poltica general de la empresa. Por ello,
la alta direccin debe expresar dicha poltica, planificarla estratgicamente, asignar
recursos y elegir los planes y evaluaciones sistemticos; en definitiva, la alta
direccin debe iniciar, desarrollar, implementar y actualizar peridicamente el
sistema de calidad.
Tambin debe crear la estructura del sistema de gestin de calidad, tanto en su
aspecto jerrquico 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 ms 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 prcticos.
Los elementos escritos son los documentos en los que se describe el sistema, los
procedimientos, etc., ajustndose 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 prctica incluye aspectos fsicos (locales, computadores, herramientas
software, etc.) y aspectos humanos (coordinacin de equipos de trabajo, formacin
en calidad, tcnicas de software, tcnicas de comunicacin 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 polticas y procedimientos, todos los
elementos, requisitos y medios que adopte la empresa en orden a la calidad.
Segn el tamao 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 especficos (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 certificacin, y facilita las relaciones con los clientes
y los proveedores.
Las diferentes normas indican la estructura del manual de calidad. Un ejemplo
podra ser el siguiente. ,
O. ndice.
l . Presentacin de la empresa.
1.1 Objeto y campo de aplicacin.
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. Gestin 2000.
Barcelona, 1994.
4. Poltica de calidad.
4.1 Responsabilidades delegadas.
4.1.1 Director de calidad.
4.1.2 Responsable de calidad de diseo.
4.1.3 Responsable de calidad de produccin.
4.1.4. Responsable de calidad de servicios.
4.2 Canales de comunicacin.
4.3 Amplitud de aplicacin.
4.4 Documentacin del sistema de calidad.
4.4.1 Registros de la calidad.
4.4.2 Explicacin de los registros.
4.5 Procedimientos operativos.
4.6 Planes de calidad.
4.6.1 Planes de formacin.
4.6.2 Plan de evaluacin de proveedores.
4.6.3 Plan de evaluacin del personal.
4.6.4 Plan de adquisicin 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 Revisin y evaluacin del sistema.
4.9 Mejora de la calidad.
5. El desarrollo del producto.
5.1 Fase de recepcin y estudio del pedido.
5.2 Fase de diseo.
5.3 Fase de produccin.
5.4 Fase de pruebas.
5.5 Fase de instalacin.
5.6 Garantas.
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 ms manejable.
De todas formas, en el manual se debe explicitar claramente la existencia de estos
procedimientos separados.
Los procedimientos son instrucciones especficas y detalladas de los procesos o

actividades, e incluyen tanto la experiencia y prctica del trabajo cotidiano como
los cdigos, normas y especificaciones a los que hay que ajustarse.
En el desarrollo del software, se incluyen en los procedimientos las
metodologas y tcnicas que hay que aplicar, coino el formato de documentos, la
forma de documentar, procedimiento de pruebas, reglas de codificacin, etc.
4.5. Registros de datos sobre calidad
Son archivos o bases de datos que contienen toda la informacin relacionada

con el proceso de la calidad (datos de pruebas, datos de auditoria, inspecciones,
datos de costes, etc.).
Su papel, adems de facilitar el funcionamiento del sistema de calidad y
determinar el nivel alcanzado de calidad, se prolonga despus de finalizado el
proyecto como base para el estudio de las tendencias y la correccin 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 especfico para adaptarlas a cada proyecto, que se conoce como
plan de aseguramiento de la calidad. Lo ms normal es que este plan siga
fielmente lo dispuesto en el plan general. Pero muchas veces es necesario
adaptarlo. Esta adaptacin del sistema a nivel de proyecto puede deberse a
diferentes causas: Proyectos muy crticos, como los espaciales, que suponen un
gran coste econmico e, incluso, prdida de vidas humanas, que exigirn unas
pruebas y unas validaciones ms numerosas y rigurosas que las exigidas por el
sistema de calidad general; necesidades especficas del cliente, como los contratos
con la OTAN, que exigen la aplicacin de otras normas de calidad (PECAL, etc.);
proyectos para clientes especiales con necesidades especiales.
5. CALIDAD A NIVEL DE PROYECTO
5.1. Planificacin del aseguramiento de la calidad en un proyecto
Siguiendo el estndar 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 financiacin y viabilidad del
proyecto.
- Definir las metodologas, tcnicas y herramientas s utilizar.
- Planificar la gestin del proyecto software.
El Plan de Gestin del Proyecto Software debe incluir y describir:
- El da a da del proyecto, con los correspondientes controles de auditorias y

revisiones.
- La planificacin del aseguramiento de la calidad del software (SQA).
- La planificacin de la documentacin del proyecto.
A partir del plan de gestin, 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 especfico para cada proyecto, siguiendo las directrices del Manual
de Calidad y de sus Procedimientos y las normas requeridas por los clientes.
Siguiendo el estndar 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.

Documentacin referenciada en el plan (manuales, procedimientos, etc.).
Gestin del aseguramiento de la calidad (organizacin, actividades y
responsabilidades).
Documentacin mnima exigida a los desarrolladores tanto del desarrollo
del software (especificaciones, diseo, manuales de usuario, etc.) como de
control (planes de Validacin y Verificacin).
Estndares que se deben aplicar obligatoriamente.
Actividades de revisin y auditoria.
Gestin de la configuracin del software (mediante un plan de gestin
especfico 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 cdigo, 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 cdigo (almacenamiento y versiones), control de acceso a

equipos y prevenciones de seguridad y control de las caractersticas 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
Segn el estndar IEEE 10741, las tcnicas para el aseguramiento de la calidad

son, principalmente, tres:
- Mtricas del software para controlar el proyecto.

- Verificacin y Validacin del software (incluyendo pruebas y revisiones) en
todas las fases del ciclo de vida.
- Gestin de la configuracin del software.
Las mtricas se estudiarn en otros captulos 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 extensin a
la industria general dio lugar a la norma ISO/DIS 9000:1985.
Posteriormente se desarrollaron otras normas, tanto en Amrica (normas ISO)
como en Europa (normas EN) y en Espaa (normas UNE). Tanto las normas
europeas como espaolas suelen ser, en la mayora de los casos, una traduccin de
la correspondiente norma ISO.
Un sistema de calidad no debe disearse usando como gua las normas de
aseguramiento contractuales, aunque debe cumplirlas. La metodologa de diseo
debe basarse en las caractersticas 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.
- Acomodacin de la norma a las necesidades de las partes contratantes.
- Revisin del contrato para valorar la capacidad de satisfacer los requisitos
de calidad exigidos y sus implicaciones econmicas.
- Requisitos tcnicos claramente definidos en las especificaciones del
contrato.
Adems, para seleccionar el modelo hay que considerar:
- La complejidad del proceso de diseo.

- La madurez del mismo.
- La complejidad del proceso de produccin.
- Las caractersticas particulares del producto.
- La seguridad del producto y las consecuencias de su fallo.
- Las consideraciones econmicas 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. Slo tendran sentido esta
inversin de recursos humanos, temporales y econmicos, 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 prcticas 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 tramitacin de la Certificacin del Registro de Empresa corresponde a la
Divisin de Certificacin de AENOR, mediante el siguiente proceso:
1". Solicitud del peticionario, incluyendo el cuestionario de evaluacin

preliminar, dirigido a AENOR.
2". Anlisis por parte de AENOR de la solicitud y cuestionario, informando a
la empresa en caso de dudas sobre su solicitud, y pidiendo a continuacin
el Manual de la Calidad y los Procedimientos Operativos de la Calidad (si
procede).
3". Envo 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 podran estudiar en las oficinas de la

Empresa inmediatamente antes de la visita previa.
4". Anlisis por parte de los tcnicos de AENOR de la documentacin enviada
por el peticionario, informndole sobre aquellos requisitos que no se
cumplen o que no existen con respecto al modelo de Aseguramiento de la
Calidad aplicable dentro de la documentacin bsica de su sistema, o sobre
la aceptacin terica de la misma.
5". Visita previa por parte del equipo auditor designado por AENOR y un
auditor de una Entidad de Evaluacin subcontratada por AENOR.
6". Auditoria del Sistema de Aseguramiento de la Calidad a los lugares objeto
de Certificacin por el mismo equipo auditor.
7". Envo a AENOR, si procede, del Plan de Acciones Correctoras a las no
conformidades detectadas en la auditoria.
8". Evaluacin y decisin por parte de AENOR y comunicacin a la empresa.
9". Auditorias de seguimiento (una visita al menos por ao, en los dos aos
siguientes a la concesin del Certificado).
10". Auditoria de renovacin al tercer ao de la concesin del Certificado, a no
ser que exista expresa renuncia por parte del Titular de la Certificacin.
Todo el proceso se representa en el siguiente grfico.

Informacin preliminar
Cuestionario de evaluacin preliminar
I
exigencias de la certificacin
No
A
1 Informacin
al solicitante
Manual de la calidad
procedimientos, otros
documentos aplicables
procedimientos, otros
documentos aplicables Informacin 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 estndares. El Reino Unido de la Gran
Bretaa fue un pas pionero en este campo. En 1974 se public una normativa para
Aseguramiento de la Calidad, Guas, 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
direccin de la Organizacin Internacional para la Normalizacin. ISO 9000 se
adopta para facilitar en el comercio global proporcionando valor aadido a las
empresas certificadas y una ventaja estratgica a las mismas.
La familia de normas denominada ISO 9000 en un conjunto de documentos
sobre las buenas prcticas de los sistemas de gestin de la calidad. Al igual que
estndares ya comentado hace hincapi en qu requisitos ha de cumplir el sistema
de calidad de una empresa sin establecer el cmo deben cumplirse. En este caso la
norma considerada e; especfica para la gestin de la calidad aunque su mbito de
actuacin no se encuentra restringida al desarrollo de programas para ordenador si
no que es de carcter genrico. Este hecho se super en 1991 al publicarse la norma
UNE-EN 29000-3. Normas de gestin y aseguramiento de la calidad. Parte 3: Gua
para la aplicacin de la norma ISO 9001 al desarrollo, suministro y mantenimiento
de soporte lgico. ISO 9000-3:1991, ms tarde modificada en 1997 publicndose la
traduccin al espaol en noviembre de 1998 UNE-EN ISO 9000-3.
La correspondencia entre las normas americanas, europeas y espaolas 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 aplicacin es todo tipo de empresa, independientemente de su
tamao y su actividad.
La norma ISO 9001 se orienta a las empresas que de deben hacerse cargo del
diseo, produccin, instalacin y servicio post-venta del producto.
La norma ISO 9002 es aplicable cuando la empresa suministradora se hace
cargo de la produccin e instalacin del producto.
La norma ISO 9003 es para cuando la empresa suministradora puede demostrar
la calidad del producto mediante inspeccin final.
8.2. La ISO 9000:2000. Razones para un cambio
Adems de que el protocolo inicial obliga a realizar una revisin de las normas
cada cinco aos, existen diversas razones provenientes del enfoque del Sistema de
Gestin de la Calidad definido por las normas ISO para realizar un cambio en las
normas.
A raz de un conjunto de encuestas a distintas organizaciones se determinaron
las siguientes razones:
Estructura comn 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
crculo de mejora continua. Dicha estructura debe servir de base para revisar los
captulos de la norma.
Compatibilidad con las normas SGM ISO 14000.
Muchas empresas, debido a la presin actual de los ecologistas, quieren

certificar sus sistemas de gestin medioambientales con la citada norma. Muchas
de ellas ya estaban certificadas para sus sistemas de calidad. Sin embargo, no
exista una equivalencia clara entre los requisitos de ambas normas, por lo que se
produca prdidas de sinergias.
Alcance reducido de los requisitos de la norma ISO 9001
Las organizaciones deberan 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 Gestin es necesario basarse en la mejora

continua, luego es necesario definir nuevos requerimientos en este sentidos para los
sistemas de Gestin de la Calidad.
Adecuacin para empresas de cualquier tamao.
La certificacin basada en la ISO 9001 ha tenido una moderada difusin entre

las PYMES, por el enfoque de algunos requerimientos que aparentemente slo se
ajustaban a organizaciones grandes.
Relacin amigable.
Una de las principales crticas a esta familia de normas era la dificultad de su

comprensin y aplicacin, unido a una aparente falta de consistencia entre las
numerosas normas existentes.
Facil transicin a la nueva norma.
Debido al gran nmero de certificaciones existentes, el cambio no debera

significar un empezar completamente de cero. Tambin se exiga un perodo
transitorio, con coexistencia de ambas normas, lo suficientemente largo para
permitir a las organizaciones la adaptacin de sus sistemas de calidad, y pudiendo
elegir el momento del cambio a la nueva certificacin.
8.3. Principios del cambio
Uno de los principios bsicos del cambio ha sido la adaptacin a la evolucin de

la gestin 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 Gestin de la Calidad Total, que se refleja en las directrices de la nueva
norma ISO 9004:2000.
Los principios bsicos en que se ha basado la revisin de la norma son:
Organizacin enfocada al cliente.
Las organizaciones tienden a orientarse hacia los clientes, para obtener su

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

directivos de cualquier nivel.
Participacin de las personas.
Los conocimientos de todo el personal de la organizacin tienen que ponerse a

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

interrelacionadas se comprenden y gestionan de forma sistemtica a partir de
informacin fiable.
Enfoque del sistema hacia la gestin.
Por medio de la gestin de los procesos se consigue la mejora y el logro

eficiente de los objetivos.
Mejora continua.
Definida como "el procedimiento segn 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 informacin 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 versin ISO 9000:2000 que, a fecha de

finalizacin del presente libro actualiza la versin precedente tal como muestra el
siguiente cuadro:
o ISO 9001 :2000 Sistemas de Gestin de la Calidad
- Sustituye a ISO 9001:1994, ISO 9002:1994 e ISO 9003:1994

ISO 9004:2000 Sistemas de Gestin de la Calidad
ctrices para la mejora continua del desempeo. 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 gestin de la calidad y
aseguramiento de la calidad. Parte 3: Directrices para la aplicacin
Tabla 3.1. Familia de normas ISO 9000.
En este punto es significativo apuntar que la norma que sustituir a ISO 9000-
3:1997 an no se ha liberado por lo que la aplicacin a entornos propios del
desarrollo software se encuentra pendiente de adaptacin, por lo que se centrar la
atencin 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
introducirn, igualmente, conceptos propios de la norma publicada en el ao 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 introduccin a la
misma.
9.1. Introduccin 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 aplicacin de la norma. Son: demostrar la capacidad

para cumplir los requisitos reglamentarios y los del cliente y satisfacerle mediante
la mejora continua y la prevencin de no conformidades.
Se pueden excluir ciertos requerimientos de la norma en funcin 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 Gestin de la Calidad. Principios y vocabulario."
Se producen algunos cambios en las definiciones de la anterior versin,
desapareciendo el trmino subcontratista y el principal protagonista, el
suministrador, pasa a denominarse Organizacin.
9.2. Sistema de Gestin de la Calidad
En la parte 4 se definen los requisitos generales y los requisitos generales de la

documentacin.
Los requisitos generales son:
Planificar
- Identificacin de todos los procesos que, de alguna forma, afectan a la

calidad del producto.
- Determinacin de la secuencia y la relacin que estos procesos tienen entre
ellos.
Ejecutar
- Determinar mtodos 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 parmetros relevantes.
- Hay que establecer los responsables de los procesos.
Medir
- Asegurar la disponibilidad de la informacin suficiente que permita el

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

mejora continua.
La documentacin 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 direccin
En la parte 5 se describen los requisitos relacionados con la responsabilidad de

la direccin en la gestin de un sistema de calidad, entre las que se destacan:
- El compromiso de la direccin.
- El enfoque al cliente.
- La poltica de calidad.
- La planificacin.
- La administracin.
- La revisin por la direccin.
9.4. Gestin de los recursos
La parte 6 describe los requisitos relacionados con la gestin de los recursos

necesarios para la obtencin del producto o servicio, que se detallan en cuatro
subpartes:
- Suministro de recursos.
- Recursos humanos.
- Instalaciones.
- Entorno de trabajo.
9.5. Realizacin del producto o servicio
Los requisitos relativos a la realizacin del producto o servicio se describen en

la parte 7, que se subdivide en 6 subpartes:
- Planificacin de los procesos de realizacin.

- Procesos relacionados con los clientes.
- Diseo y10 desarrollo.
- Compras.
- Operaciones de produccin y de prestacin de servicios.
- Control de equipos de medicin y de seguimiento.
9.6. Medicin, anlisis y mejora
La parte 8 describe los requisitos relacionados con la deteccin, el seguimiento

y el anlisis de las mejoras. Se divide en 5 subpartes:
- Planificacin.
- Medicin y seguimiento.
- Control de las no conformidades.
- Anlisis de datos.
- Mejora.
Dentro de la medicin y seguimiento se incluyen las siguientes reas:
- Satisfaccin del cliente.

- Auditoria interna.
- Medicin y seguimiento de los procesos.
- Medicin y seguimiento del producto.
10. LA NORMA ISO 9004:2000
Esta norma expone las recomendaciones para llevar a cabo la mejora del
sistema de gestin de la calidad y explicaciones adicionales con relacin a los
requisitos de la norma ISO 9001:2000. No es una directriz para cumplir con la
9001, sino recomendaciones a la direccin de la organizacin para obtener mejoras.
Consta tambin de 8 partes.
10.1. Introduccin a la norma
En las cuatro primeras partes se exponen el objeto y campo de aplicacin

(recomendaciones genricas par la mejora de la gestin de los sistemas de calidad),
normas de consulta (la ya citada norma ISO 9000:2000), terminologa y
definiciones (ISO 9000:2000) y recomendaciones del Sistema de Gestin 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 documentacin y el uso de los principios
de gestin de la calidad (los 8 principios bsicos del cambio ya citados).
10.2. Responsabilidad de la direccin
En la parte cinco de la norma se describen las responsabilidades de la direccin

articuladas en:
- Responsabilidades generales.
- Necesidades y expectativas.
- Poltica de calidad.
- Planificacin de la calidad.
- Administracin.
- Comunicacin.
- Documentacin y registro.
- Revisin.
10.3. Gestin de los recursos
La parte 6 de la norma se relaciona con el papel de la direccin en identificar y

proporcionar, en tiempo y formas los recursos necesarios para la consecucin de
los objetivos planificados de gestin de la calidad. Estos recursos son:
- Recursos de personal.
- Entornos de trabajo, tanto squicos como fsicos, adecuados.
- Recursos de informacin.
- Recursos financieros.
- Infraestructuras y recursos naturales.
- Suministradores.
10.4. Realizacin del producto o servicio
La parte 7 se refiere a la realizacin 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 diseo y10 el desarrollo.
- Procesos relacionados con las compras.
- Procesos relacionados con operaciones de produccin y de servicio.
- Control de equipos de medicin y seguimiento.
10.5. Medicin, anlisis y mejora
La parte 8 basa la mejora continua en la medicin y el anlisis de sus resultados.

Estas mediciones y anlisis deben hacerse regularmente, a intervalos apropiados,
sobre los datos relevantes de los productos, procesos y clientes, como entradas al
proceso de revisin por la direccin.
La organizacin debera bsicamente medir la eficiencia de:
- El sistema de gestin de la calidad (satisfaccin 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 metodologa para implantar, de una

forma sencilla, un procedimiento interno de auto evaluacin.
La norma tambin presenta ejemplos de informacin a incluir en los procesos de
medida, anlisis y mejora en los siguientes campos:
- Relativa al cliente.
- Satisfaccin del cliente.
- Auditoria interna.
- Financiera.
- Auto evaluacin.
- Procesos.
- Productos.
- Partes interesadas.
- Propietarios.
- Suministradores.
- Sociedad.
- Medio ambiente.
Otros apartados se refieren al control de las no conformidades, al anlisis de

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

NORMA ISO 9001:2000 E ISO 9000-3:1997
En el caso de los programas para ordenador (soporte lgico segn 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 ao 2000 acerca la misma a la gestin de la calidad total aportando
directrices para la mejora continuada.
La norma ISO 9001 :2000 posee la siguiente estructura:
- Introduccin.
- Objeto y campo de actuacin.
- Normas para la consulta.
- Trminos y definiciones.
- Sistemas de gestin de la calidad.
- Responsabilidad de la direccin.
- Gestin de los recursos.
- Realizacin del producto.
- Medicin, mejora y anlisis.
Considerando directamente el apartado "Medicin, mejora y anlisis", la norma

diferencia claramente procesos y producto estableciendo la necesidad de medir y
hacer un seguimiento de las caractersticas del producto as como el seguimiento y
medicin de los procesos. Medir es, en este estndar una herramienta fundamental
de la misma. Esta necesidad impuesta por la norma es equiparable a la indicacin
expresada por el modelo de madurez (CMM) en su nivel 4. Tal y como es habitual
en este tipo de estndares no se profundiza en medidas determinadas. El
seguimiento y medicin del producto es equivalente al control de calidad clsico,
basado en la inspeccin del producto para comprobar su cumplimiento con unas
especificaciones definidas [Soluziona, 20011. Como la realizacin de un producto
es el resultado de diversos procesos encadenados, deben considerarse en ia
definicin 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 inforrnticos, con la norma
ISO 9000-3: 1991 revisada en 1997 y emitindose 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 obtencin de medidas, por ejemplo en el apartado 4.47
Verificacin del diseo, 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 accin recomendada. Las siguientes citas exponen este hecho:
"Se deben realizar verificaciones del diseo durante las fases apropiadas
del mismo (...). Se deben registrar las medidas de verificacin del
diseo""
"El suministrador debe: determinar qu medidas deben realizarse, la

exactitud requerida y seleccionar los equipos de inspeccin, medida y
ensayo adecuados y que sean aptos para la exactitud y precisin
necesarios"'*
La Norma s aporta, de forma expresa, la necesidad de utilizar tcnicas

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

- Nmero y tipos de defectos en la salida de los procesos.
- Eficiencia en la eliminacin de defectos.
- Deslizamiento de hitos.
Para productos:
- Capacidad de ser probado.

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

caracterstica medible y aporta aquellos principios que deben cumplir. Las
mtricas tienen la necesidad de estar definidas claramente, deben aadir valor al
proceso o producto estudiado, debe estar identificada la forma en que puede ser
influida (por ejemplo por cambios en el diseo o tcnicas de desarrollo) y se
comprende su significado con relacin al proceso o producto.
" UNE-EN ISO 9000-3. Gestin de la Calidad y Aseguramiento de la Calidad. Parte 3: Directrices para la
aplicacin de la Norma ISO 9001: 1994 al desarrollo, suministro, instalacin y mantenimiento de soporte lgico.
AENOR. Madrid, 1998. Pg. 20
''Op cit pg. 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 tcnicas
estadsticas.
El modelo propugna la medida de la calidad explicando este concepto desde el
punto de vista de la satisfaccin del cliente.
Captulo 4
MODELOS, METODOLOGIAS Y ESTNDARES:

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 trminos modelo, norma o metodologa de forma

subjetiva y ambivalente por parte de profesionales de la informtica y en
publicaciones especializadas. En este captulo, en su primer apartado, se definirn
estos conceptos con el fin de evitar errores y permitirnos clasificar la enorme
cantidad de normas, estndares y metodologas existentes en el mercado con una
base conceptual coherente. Explicaremos en detalle los modelos CMM y Bootstrap
la norma internacional ISO 15504 y la metodologa MTRICA Versin 3, como
ejemplos prcticos de estrategias asociadas al aseguramiento de la calidad en el
desarrollo de aplicaciones informticas.
1.1. Definiciones
Una metodologa de desarrollo de aplicaciones informticas es un conjunto de

mtodos que permiten sistematizar actividades. Nos dicen cmo hacer las cosas a
travs de procedimientos bien descritos.
'Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineering, John Wiley & Sons, 1994. Pg.
122 MODELOS, METODOLOGIAS Y ESTNDARES
Esta idea proviene de la industria clsica2 donde el control, basado en la medida

de atributos propios del proceso, permiten su optimizacin y mejora continua. Las
metodologas de desarrollo, por tanto, nos prestan una ayuda singular frente a la
ineficacia de la creacin artesanal singular, limitada e irrepetible, basada en el
conocimiento de un nico elemento: el maestro. El proceso industrial es el
resultado de dcadas de investigacin y aportaciones de decenas o cientos de
estudiosos y tcnicos. Una adecuada metodologa es, por tanto, el mejor aliado
frente a la improvisacin y a la ineficacia.
Unida al concepto de metodologa aparece habitualmente el de "modelo de
desarrollo".
Un modelo, en sentido amplio, es un arquetipo, una referencia a imitar o
reproducir.
En la ingeniera del software un modelo nos proporcionar el objetivo a
alcanzar, dnde debemos llegar, pero no nos indicar cmo. Cuando el Modelo de
la Madurez del Software (CMM) presenta una abstraccin del proceso de creacin
de aplicaciones informticas, aporta un conjunto de estadios, de capas, que
permitirn determinar el nivel de madurez, el cmo alcanzar esos niveles, esos
objetivos, es responsabilidad del informtico.
Tambin es importante destacar la definicin de modelo desde una perspectiva
matemtica, entendido como una representacin abstracta de un concepto o una
entidad. Un modelo matemtico puede venir representado por una ecuacin. Sin
embargo este concepto de modelo es mucho ms determinista y presenta menos
ambigedades que el primero donde en muchas ocasiones se mezcla con el de
metodologa o se equipara al de estndar.
Figura 4.1. Funcin de transferencia en circuito cerrado. Un modelo matemtico

que representa un sistema de control tradicional.
Aportamos el concepto de industria clsica frente al de industria del software de igual manera que existen
evidentes diferencias y, al mismo tiempo, claros intentos de aproximacin entre la ingenieria del software y las
ingenieras ms tradicionales como la ingeniera del motor, aeronutica, de componentes mecnicos, electrnicos
etc.
2. EL MODELO DE MADUREZ DE LA CAPACIDAD DEL SOFTWARE
El Instituto de Ingeniera del Software, ms conocido por su acrnimo ingls

SE1 (Software Engineering Institute) ide un marco de referencia para el proceso
de creacin del software como respuesta al requerimiento del gobierno
norteamericano para la obtencin de un mtodo que permitiera valorar la capacidad
de los contratistas de aplicaciones informticas que accedan a sus licitaciones.
Tras cuatro aos de trabajo el SEI, en colaboracin con la empresa Mitre
Corporation, desarroll un modelo apoyado en el concepto de madurez al que
denomin CMM acrnimo del/ ingls 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 Versin 1.1, tras las revisiones
efectuadas sobre la Versin 1 durante los aos 1991 y 1992.
Un entorno comercial cada vez ms competitivo requiere de tiempos de
desarrollo de nuevas aplicaciones menores a la par que exige productos de calidad,
la estandarizacin del proceso y la deteccin 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 realizacin de aplicaciones
inforrnticas 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 gua a las organizaciones indicando cmo mejorar los
procesos asociados al desarrollo y mantenimiento del software. La filosofa general
que rige este modelo se fundamenta en diferentes niveles de madurez, entendidos
como sucesivas etapas cuyo objetivo es la obtencin 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 organizacin.
Es importante indicar que el Modelo de Madurez se fundamenta en la secuencia
de los niveles propuestos. No es aconsejable ni tcnicamente adecuado el pretender
un nivel superior sin haber alcanzado el intermedio. Los niveles de madurez
pueden asemejarse a los estratos telricos, uno sucede a otro, lo apoya y sustenta.
Es fcil entender que no es posible el proceder a una mejora continuada con la
aplicacin de nuevas tecnologas, como sera el caso del Nivel 5, sin haber
establecido un control cuantitativo de los procesos software, o haber establecido
estndares adecuados para, por ejemplo, la recopilacin o manipulacin de datos en
la que asentar la cuantificacin 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 tecnolgicas de inesperadas consecuencias. La
exigencia de la calidad no es slo para los productos materiales, tambin 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

-Estndares y procedimientos no mantenimiento de software bajo control.
seguidos por los trabajadores. -Planes establecidos guan el trabajo a
-El trabajo viene impuesto por crisis realizar.
puntuales a superar. -Existe una comunicacin fluida entre
-Acciones de "apagafuegos". equipos de trabajo, existe la transmisin
-Estimaciones de costes, esfuerzos y de experiencia entre los tcnicos.
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 organizacin. 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 organizacin. Los niveles de madurez
son:
Inicial
El proceso software se caracteriza porque es ad hoc, incluso ocasionalmente

catico. Algunos procesos son definidos aunque no se siguen con rigurosidad y el
xito depende de esfuerzos individuales.
Una organizacin adjetivada como de Nivel 1 no proporcionara 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
solucin 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
direccin enrgica, de tal forma que la prdida de ese equipo o del administrador
implica una merma casi inmediata de la efectividad del servicio de muy difcil
recuperacin.
El xito de organizaciones del Nivel 1 depende exclusivamente de la
competencia de los trabajadores, su inters y predisposicin. La seleccin del
mismo, su entrenamiento o el fichaje de profesionales de vala es el motor de este
tipo de organizaciones.
Las organizaciones establecidas en el Nivel 1, son muy dependientes de ciertos
recursos humanos, centralizando la ejecucin de proyectos en la direccin
fomentada por stos. La prdida de estos recursos implica la inmediata cada de la
eficiencia de los proyectos y resulta traumtica para la organizacin.
Repetible
Han sido establecidos procesos bsicos de gestin del proyecto que permiten el
seguimiento de costes, planificacin y funcionalidad. La necesaria disciplina del
proceso consiste en la experiencia acumulada en xitos anteriores de proyectos con
similares caractersticas. Estas experiencias se convierten en la verdadera gua 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 polticas para la administracin del proyecto
software y se implementan procedimientos que permitan aplicar dichas polticas.
De nuevo la planificacin y administracin 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 organizacin.
El proceso software de Nivel 2 puede resumirse en un entorno disciplinado y
se encuentra bajo el control efectivo de un sistema de administracin guiado por
planes realistas basados en el rendimiento de proyectos anteriores. En este segundo
Nivel la direccin enrgica para el cumplimiento de las pautas de desarrollo
establecidas sigue siendo un factor fundamental de xito.
El proceso software para las actividades de direccin e ingeniera est
documentado, estandarizado e integrado en el proceso global de creacin,
mantenimiento y administracin del software de la organizacin. Se hacen uso de
prcticas propias de la ingeniera del software, los proyectos se adaptan a los
estndares establecidos y permiten un conocimiento de la situacin y progreso del
mismo, las versiones de programas y aplicaciones son controladas y su puesta en
explotacin es verificada y aprobada adecuadamente.
La existencia de mecanismos de verificacin, estndares, as como entradas y
salidas, permite establecer un proceso definido, apoyo bsico de administradores y
gua 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 constatacin
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 estndar 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 lneas de producto establecidas, coste, funcionalidad y agendas
estn bajo control y la calidad del software es seguida.
Gestionado
Esta etapa se caracteriza por la capacidad de la organizacin 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 direccin se
constituye en un firme aliado del programa de medidas dirigindolo y posibilitando
los recursos necesarios para su realizacin. Este apoyo de la direccin 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 organizacin 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 captulo como el objetivo principal de
la medida del software, por la que este modelo asume dicho papel, potencindolo e
incluso definiendo un nivel basado en su recoleccin y uso. La medida del software

es reconocida como una base fundamental en el desarrollo de aplicaciones
informticas.
Este nivel de madurez se puede resumir en predecible, ya que el proceso es
medido y opera dentro de los lmites establecidos. Este conocimiento cuantitativo
permite predecir tendencias en los procesos y la calidad de los productos. Si las
medidas recogidas implican una desviacin de los objetivos marcados se procede a
la realizacin de acciones correctoras.
Optimizado
En este Nivel la organizacin incorpora nuevas tecnologas e ideas innovadoras,

en un deseo de mejora continua facilidad por un proceso de retroalimentacin
basado en la medida de los atributos propios del proceso software. El impacto de la
incorporacin de estas nuevas tecnologas se valora de forma cuantitativa en cuanto
a costes y efectos sobre la organizacin. Se proponen mejoras en el proceso
software fundamentada en medidas numricas y previsiones del resultado de su
incorporacin a los proyectos. La organizacin est envuelta en un conocimiento
de sus puntos fuertes y dbiles que permitir la prevencin 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 organizacin
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 tecnologas.
Se aprecia en la estructura del Modelo de la Madurez del Software una evidente
preocupacin en la obtencin de datos cuantitativos como elemento de juicio
necesario para la mejora del proceso productivo. La medicin del software es una
actividad bsica en este modelo, tal como lo demuestra ser un rea clave comn del
proceso.
Accedemos a un nivel superior cuando hemos alcanzado uno objetivos, la
organizacin ha alcanzado ese nivel como consecuencia de estos objetivos.
128 MODELOS, METODOLOG~ASY ESTNDARES
1 Nivel 5 1
Procesos de mejora
continua
I Organizacin
madura
estandarizados
Organizacin
Figura 4.3. Niveles de madurez en el modelo CMM.
2.2. reas clave y caractersticas 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 consecucin de objetivos importantes para la mejora de la capacidad
del proceso productivo. Existen dieciocho reas clave de proceso, cada una de ellas
contiene una descripcin breve de la misma, los objetivos a alcanzar y las prcticas
clave. Las prcticas clave determinan las actividades, procedimientos, directrices y
polticas 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: Gestin de requisitos (RM).
Objetivo: Documentar los planes.
rea Clave: Gestin 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: Gestin de configuracin (SCM).
rea Clave: Gestin de subcontratacin (SSM).
Nivel 3
Objetivo: Identificar el proceso.
Arrea Clave: Establecimiento del proceso de la organizacin
(OPF).
rea Clave: Definicin del proceso de la organizacin (OPD).
rea Clave: Gestin integrada del software (ISM).
rea Clave: Ingeniera del producto software (SPE).
Objetivo: Fomentar el trabajo en equipo.
rea Clave: Coordinacin entre grupos (IC).
rea Clave: Programa de formacin (TP).
Objetivo: Reducir defectos.
rea Clave: Revisin entre iguales (PR).
Nivel 4
Objetivo: Definir metas.
rea Clave: Gestin de la calidad del software (SQM).
Objetivo: Gestionar el progreso.
rea Clave: Gestin cuantitativa del proceso (QPM).
Nivel 5
Objetivo: Optimizar el rendimiento.
rea Clave: Prevencin de defectos (DP).
rea Clave: Gestin del cambio de procesos (PCM).
Objetivo: Adoptar nuevas tecnologas.
rea Clave: Gestin del cambio tecnologa aplicada (TCM).
Figura 4.4. reas clave por niveles.
Cada rea clave est organizada en cinco secciones denominadas caractersticas

comunes. Cada rea clave, adems, est descrita tomando como base las prcticas
clave que contribuyen a satisfacer los objetivos de dicha rea. Al abordar dichas
prcticas clave se alcanzan los objetivos del rea clave del proceso. Las
caractersticas comunes nos informan si los objetivos se han cubierto. A
continuacin indicamos las caractersticas comunes:
Actividades
Describen procedimientos necesarios para implementar un rea clave de

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

organizacin para implementar de forma competente el proceso software. Suele
afectar a los recursos y estructuras de la organizacin y a la formacin.
Medidas y anlisis
Medicin y anlisis 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 ms crticas informaciones de las que depende el
administrador de los sistemas de informacin o el ingeniero de software. Muchos
de los profesionales basan este conocimiento en su experiencia personal obtenida
tras participar en diferentes proyectos. Una visin real de la situacin en la que se
encuentra el proyecto software slo es posible con revisiones peridicas
establecidas. Es interesante hacer notar cmo los niveles de madurez del software
propuestos por el SE1 estn 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 acercara a una
entidad amorfa en la que difcilmente 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 administracin 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 informacin 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
tecnologas o mejoras administrativas.
2.3. La calidad, su aseguramiento y medida segn 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 "garanta de calidad del software" y en especial las reas clave
del Nivel 4, "gestin de calidad y medidas" y "anlisis del proceso" son las reas
en las que centraremos nuestro estudio.
En las "caractersticas comunes", antes comentadas, son destacables las
denominadas "medicin y anlisis". En stas, de forma expresa, se indica la
necesidad de medir el proceso software y utilizar dichos datos cuantitativos en los
correspondientes anlisis.
El propsito del "aseguramiento de la calidad del software", propio del Nivel 2,
es proporcionar a la direccin la adecuada visibilidad del proceso utilizado en el
proyecto software y de los productos que se estn construyendo. Los objetivos se
centran en planificacin de las actividades propias del aseguramiento del software,
la verificacin de la adhesin de los productos y actividades a estndares,
procedimientos y requisitos aplicables y la informacin al equipo de trabajo. De
forma expresa no se define la calidad del software y en cuanto a la prctica propia
de la medida y anlisis, sta se centra en la medicin de costes y calendario de
ejecucin del proyecto. Las medidas que se proponen en este modelo son las
siguientes:
132 MODELOS. METODOLOGIAS Y ESTNDARES
- 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 prcticas clave se destaca la formalizacin de medidas de la entidad

"proceso". Se basan en medidas directas del proceso de aseguramiento de software
(nmero de hitos, esfuerzo y tiempo utilizado). Adems aporta la necesidad de
medida del producto software, en concreto identificando el nmero de inspecciones
del producto en comparacin con el plan de aseguramiento de la calidad
establecido.
El Nivel 4 implica el conocimiento cuantitativo del proceso y producto
software. El rea clave "gestin 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 tcnica de
carcter cuantitativo o basado en datos de carcter estadistico apropiado para
analizar el proceso de software3.
Es interesante destacar la Actividad 4 dentro de la caracterstica comn:
actividades realizadas. En ella se destaca la necesidad de una definicin clara de las
medidas a recopilar, su utilizacin posterior y el momento en que se van obtener.
De nuevo el modelo aporta ejemplos de medidas de forma genrica, mezclando
medidas propias de procesos y productos (errores detectados en el producto final,
eficacia del proceso de entrenamiento, tamao y coste del software) segn las
definiciones establecidas en el captulo 2 del presente estudio.
En cuanto al propsito del rea clave gestin 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 propsito de la gestin de la calidad es desarrollar un conocimiento
cuantitativo de la calidad de los productos del proceso software y alcanzar los
especficos objetivos de la al ida d.^
En cuanto al propsito del rea clave gestin 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, Versin 1.l, TR. Software Engineering. Institute-Camegie Mellon
Universitiy. 1993. Pg. 5. La traduccin es nuestra.
SEI. Op. Cit. Pg. 36. La traduccin es nuestra.
"El propsito de la gestin de la calidad es desarrollar un conocimiento

cuantitativo de la calidad de los productos del proceso software y alcanzar los
especficos 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 caractersticas del producto software.
Como ejemplo de estas caractersticas, en la actividad 3 dentro de la caracterstica
comn, actividades realizadas, se aportan, entre otras, las siguientes:
o Funcionalidad.
o Fiabilidad.
o Facilidad de uso.
o Facilidad de mantenimiento.
Existe una relacin evidente entre el concepto caracterstica del software

aplicado por esta metodologa con el concepto atributo del software explicado en el
captulo 2 del presente estudio. La entidad poseedora del atributo no se identifica
de forma expresa aportndose el concepto producto software de forma genrica sin
diferenciar si se trata de un proceso, producto o recurso. El modelo CMM indica la
necesidad de cuantificar las caractersticas de la calidad del producto software.
Siguiendo con la filosofa general del modelo no se profundiza. El modelo CMM
explica qu ha de hacerse, no el cmo, 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 indicacin
de atributo medido.
El modelo CMM otorga una elevada importancia a la calidad del software y su
medida. La calidad es propia de la definicin de cada proyecto, por lo que de forma
implcita aporta el concepto de calidad como una percepcin del resultado final
frente a los requerimientos presentados.
En este modelo no hace una clara definicin de las medidas a coleccionar, ni
identifica procesos, productos o recursos a medir. Aporta ejemplos de medidas
como apoyo a la metodologa, sin incluir un anlisis detallado de los mismos.
5
SEI. Op. Cit. Pg. 36. La traduccin es nuestra.
3. MODELO BOOTSTRAP
El CMM ha sido, sin lugar a dudas, un punto de referencia bsico en la

ingeniera 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
mritos que el Modelo de Madurez posee, su aplicacin en el mbito europeo
manifest una serie de disfunciones. Tal y como apunta el profesor Guenter R.
Koch "...el modelo de Valoracin de la Madurez propuesto por el SE1 mostraba
ciertas debilidades que lo hacan difcil 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 tecnologa del software, entendida sta, no como un
instrumento de presin sobre las organizaciones, tal como supuso el CMM, sino
como un apoyo a las mismas, estimulando el mercado de las tecnologas de la
informacin. En este clima el proyecto BOOTSTRAP supuso una nueva
orientacin, en la cual la transferencia de tecnologa deba ser comprendida como
un catalizador de la pujanza del mercado, de forma que motivara a productores y
usuarios a introducir mtodos y herramientas para el desarrollo y mantenimiento
del software.
"El proyecto BOOTSTRAP deba fertilizar los campos para introducir moderna
tecnologa del software en las empresas. sta se hara a travs de un anlisis del
estado actual de la industria de la ingeniera del software identificando los cambios
potenciales y motivaciones que permitieran aceptar nuevos contextos para la
ingeniera del software"
3.1. El concepto Bootstrap, del diagnstico a la solucin
El modelo BOOTSTRAP propone un mtodo y los instrumentos necesarios que

permiten identificar los puntos dbiles de la organizacin, adems de presentar los
cambios necesarios para obtener una mejora de la situacin.
El modelo del proceso bsico elegido por Bootstrap se centra en entidades
extendidas por lazos de retroalimentacin, estos lazos se entienden como procesos
de comparacin entre las caractersticas 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 resumira el concepto Bootstrap es la mejora cclica propia de la
filosofa Kaizen que propone una continua secuencia del tipo PlaniJicar-Hacer-
Comprobar-Accin.
Por otro lado BOOTSTRAP se asienta en que antes de cualquier inversin en
tecnologa tales como herramientas de ltima generacin o complicados soportes
infomiticos debe implementarse a travs de una adecuada metodologa la solucin

a los problemas que pudieran afectar a la organizacin. La frmula propuesta es:
Como mxima fundamental de este modelo se puede indicar que la forma de

superara la crisis del software es mejorando el proceso de organizacin por el cual
el software es creado, manejado y mantenido.
Los mbitos cubiertos por BOOTSTRAP seran:
a) reas objeto de inters.

b) La estructura y comportamiento del rea estudiada, esto es, su organizacin.
c) La escala de la organizacin utilizando un modelo de referencia.
d) Las mtricas que permitan "medir" la organizacin.
e) El proceso de cambio hacia un estado mejor.
La comunidad del software slo recientemente ha asimilado al software como

un producto en el que el proceso de creacin y mantenimiento son de igual
importancia e interdependientes. Bajo esta declaracin de principios para
BOOTSTRAP existen dos aspectos bsicos en el modelo del proceso:
o Una estructura en capas jerrquicas. Bootstrap eligi un modelo clsico

admitido y estandarizado por la Agencia Espacial Europea. En este modelo
la asuncin bsica 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 comparacin con una escala ordinal La
escala de medida propuesta por el SE1 a travs de su modelo CMM fue
aceptada como adecuada.
La razn fundamental de la eleccin de un modelo de organizacin orientado al

proceso es permitirnos una slida base sobre la cual "medir" las organizaciones, o
de forma ms 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 compaas, 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 ESTNDARES
Los objetivos de la valoracin BOOTSTRAP seran:
o Medir y desarrollar un perfil de la calidad para el SPU (Unidades de

Produccin de Software) de forma analtica, 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 accin en una serie de mini-proyectos que
implementen los pasos recomendados para la mejora.
3.2. Prctica del modelo
En la prctica la metodologa Bootstrap se basa en un conjunto de cuestionarios

que actan de sensores, permitindonos conocer el estado en que se encuentra la
organizacin as como su estructura interna. Estos sensores pueden ser
considerados como mtricas de atributos determinados del software, si nos ceimos
a la teora de la medida expuesta en este texto (ver captulo 2), de hecho todo el
proceso de obtencin de datos de la organizacin puede ser comparado con la
aproximacin GQM (Goal Question Metrics) pero con diferente profundidad y
jerarqua.
El cuestionario es altamente interactivo permitiendo una clara intervencin de
asesores y asesorados. Los datos son adquiridos desde el mismo momento en el que
comienza este cuestionario. Esta batera de preguntas puede dividirse en tres
grandes grupos:
1. Un cuestionario complejo sobre datos generales de la organizacin. Su

estructura, rea de actividad, aplicaciones dominantes, sistemas de calidad
asociada a la administracin de recursos.
2. Un cuestionario sobre la metodologa e ingeniera utilizada. Procesos en
general, proceso independiente propios del ciclo de vida tales como proyectos y
administracin de la calidad.
3. Cuestionario sobre la tecnologa y su transferencia. Datos sobre la
introduccin tecnolgica, soporte de procesos y funciones a travs de la
tecnologa. Soporte tecnolgico 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
Tecnologa
Innovacin tecnolgica
Sistema de Calidad Funciones para el ciclo de vida
Administracin de los Funciones independientes del
recursos ciclo de vida
Metodologa
--
Funciones de Procesos
Descripcin de procesos Funciones de Desarrollo
Funciones de Administracin Medida de los procesos Modelo de desarrollo
Administracin de configuracin Control de los procesos Requisitos, anlisis y definicin
y cambio Diseo de la arquitectura
Administracin de riesgos Implementacin y diseo
Administracin de proyectos detallado
Administracin de la calidad Prueba
Administracin de subcontratistas Operatoria y mantenimiento
Sistemas de propsitos especiales
Figura 4.5. Proceso de valoracin Bootstrap.
El paso segundo es una conclusin directa del anlisis realizado en el paso

primero.
El tercer paso ha de ser organizado como un proceso interactivo de decisiones
que envolvera a todos los miembros de la organizacin.
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 Organizacin y la Metodologa
A (bajo) a B (alto) para la Tecnologa

Organizacin Ingeniera Ingeniera Ingeniera Tecnologa

del Soporte del del Producto
Atributos del Proceso
Figura 4.6. Grfico de barras tpico de la valoracin Bootstrap.
El segundo resultado es la cuantificacin 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 obtencin 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 bsicos 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
prcticas de la organizacin en comparativa con sus competidores.
La valoracin es presentada a travs de una serie de grficos de barras, de forma que es
fcil identificar en qu reas son aquellas ms necesitadas de una actuacin correctora.
4. LA NORMA ISO 15504
El incremento en el nmero de modelos y estndares destinados a la valoracin

y mejora del software y su proceso de desarrollo (CMM, Trillium, Bootstrap,
Technology Diagnostic, entre otros) propiciaron, al inicio de la dcada de los aos
noventa, el sentimiento generalizado de la necesidad de promover un estndar
internacional que armonizara los modelos de referencia existentes.
El proyecto SPICE, acrnimo de las palabras inglesas Software Process
Improvement and Capability Determination, promovido por ISO surgi como un
esfuerzo de colaboracin internacional que deba materializarse en un nuevo
estndar para la valoracin del proceso del software. El grupo de trabajo que
llevara a cabo esta labor, denominado WG10, contara con un equipo central de
profesionales con dedicacin exclusiva, adems de aportaciones de investigadores,
estudiosos y profesionales de ms de veinte pases.
El proyecto SPICE deba proporcionar el soporte necesario para la elaboracin
del nuevo estndar. La realizacin de pruebas de campo sera una labor
fundamental de la que se deberan extraer los datos oportunos y derivar los anlisis
que posibilitaran la mejora del modelo en sus diferentes borradores. La promocin
del nuevo modelo y el seguimiento del mismo con objetivo de propiciar su
evolucin seran 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 Tecnologas de la Informacin
SC7 Software Engineering
WGlO Working Group on Software Process Assessment
Tabla 4.1. La organizacin ISO y el proyecto SPICE. Acrnimos en ingls.
El estndar resultante del proyecto deba cumplir ciertos objetivos:
O Ser lo suficientemente genrico para tener un amplio horizonte de

aplicacin, a la par de lo suficientemente especfico como para ser til
y manejable.
O Establecer los mecanismos que permitieran migrar desde estndares ya
establecidos, as como evitar la aparicin de otros estndares de facto.
O Proporcionar un programa de transferencia tecnolgica que permitiera
la adopcin del nuevo estndar.
Desde el nacimiento del proyecto SPICE hasta nuestros das una serie de hitos
se han sucedido en el proceso de creacin de la nueva norma. El largo camino
recorrido por sta nos da cuenta del cuidadoso estudio que requiere la creacin de
un modelo de estas caractersticas.
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 ao se celebr un encuentro en Mjico del grupo de
trabajo nmero 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 secretara del comit SC7 las nueve partes de documento comenzando
el perodo de votaciones. En la actualidad el proyecto ha alcanzado el llamado
estado 90.92, es decir se encuentra en fase de revisin. La norma ISO/IEC 15504
ha rebasado, por tanto, el estado del borrador DTR (Draft Technical Report) y
tambin la votacin de los miembros del comit JTC1. En los aos sucesivos a la
publicacin de informe tcnico ste se encuentra sujeto a estas revisiones por parte
del ya nombrado comit JTC1. El objeto de este perodo es reexaminar la situacin
del informe tcnico publicado y, si es posible, alcanzar el acuerdo internacional
necesario para la publicacin de un estndar internacional que reemplace al
mismo.
Software Engineering Institute, EE.UU AFNOR, Francia

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

colaboracin de numerosos organismos.
4.1. ISO 15504, un modelo bidimensional
El modelo, a travs de una aproximacin estructurada, nos permite valorar los

procesos software, fomentando la auto evaluacin y ofreciendo un mecanismo por
el cual los adquisidores pueden ganar confianza en los resultados de la valoracin,
de esta forma los datos obtenidos pueden ser utilizados para fines de calificacin de
los suministradores, permitiendo determinar la capacidad de los procesos, as como
su adecuacin 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 segn esta organizacin.
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 tambin 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 gua indicadora
Figura 4.7. ISOIIEC 15504, componentes y sus relaciones.
Evaluacin de los procesos, mejora de los procesos y determinacin 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 dimensin 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 segn en grado de
cumplimiento de los mismos indicado en tantos por ciento.
La primera dimensin denominada dimensin del proceso define un conjunto
estndar de procesos para el ciclo de vida completo del software. La dimensin del
proceso parte de tres clases bsicas de procesos (Primaria, Soporte y
Organizativas), stas se dividen en cinco categoras de proceso (Cliente/
Suministrador, Ingeniera, Soporte, Administracin, Organizacin), veinticuatro
procesos de alto nivel, y otros diecisis componentes. Cada proceso se define desde
el punto de vista de su finalidad y como un conjunto identificado de resultados.
Soporte
SUP. 1 Documentacin
MAN. 2 Admir SUP.2 Administracin de la
configuracin
SUP. 3 Aseguramiento de la
calidad
SUP. 4 Verificacin
SUP. 5 Validacin
SUP. 6 Revisin
SUP. 7 auditoria
RG. i Orien SUP. 8 Resolucin de
-..,.""'- problemas
1 delprocesc
el proceso
nrnrern
Figura 4.8. Arquitectura de los procesos segn ISOAEC 15504.
La dimensin de la capacidad del proceso se sustenta en un conjunto de

atributos que determinan el nivel. El objetivo de esta dimensin 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
estndar representa la medida del software de igual manera que en el caso CMM.
Los niveles considerados por el estndar son:
Incompleto
Hay un fallo generalizado al alcanzar los propsitos del proceso.
Realizado
El propsito 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 especficos y es

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

la ingeniera del software.
Predecible
El proceso definido es ejecutado en consistencia con controles de lmites

establecidos, para alcanzar los objetivos definidos. Medidas detalladas del
rendimiento son coleccionadas y analizadas.
Optimizado
La realizacin 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 Administracin del Trabajo del
Inoenieria Producto
Deiarrollo,Mantenimiento Nivel 3. Proceso establecido
Sum~nistrador Definicin 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 estndar ISO/IEC 15504.

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

ambigedades en la cuantificacin 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 valoracin. Cada uno de ellos est definido desde el
punto de vista de las caractersticas que el proceso debera exhibir. Para cada
atributo hay una descripcin general y un conjunto de caractersticas especficas, de
forma que cada uno es evaluado para cada proceso valorado, desde el punto de
vista del grado de realizacin 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 evaluacin se basa
en el principio de que la capacidad del proceso se puede evaluar si se demuestra la
consecucin 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.: Administracin del Rendimiento (51%- 100%)
Atri. Proc.: Administracin del Trabajo del Producto (51% - 100%)
Nivel 3
Atri. Proc.: Administracin del Rendimiento (86%-100%)
Atri. Proc.: Definicin 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 aproximacin no slo permite conocer el nivel en qu se encuentra
nuestros procesos, es una gua que nos permite su mejora al conocer el valor qu
deben tener los atributos para conseguir un nivel superior de excelencia, segn la
escala propuesta. La dimensin de la capacidad no slo sirve para cuantificar la
capacidad de la organizacin, tambin es una gua para su optimizacin.
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 organizacin
denominado administracin de la calidad, incluida en la dimensin del proceso, y
en el Nivel 4 en el atributo medida propio de la dimensin de la capacidad. A
continuacin 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 administracin 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 satisfaccin del cliente y la de exponer la necesidad de su
observacin (el modelo la define como monitorizacin).
De forma clara y concisa se asocia la calidad como cumplimiento de los
requisitos, tanto explcitos como implcitos, expuestos por el cliente.
Dentro de proceso de soporte en el apartado denominado aseguramiento de la
calidad tambin 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 propsito 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. Pg. 19.
' ISO/IEC TR 15504-2. Information technology -Software process assessment - Part:2 A reference model for
de la organizacin, para ejecutar una efectiva administracin del proceso y

demostrar objetivamente la calidad del mismom8.
Es sumamente interesante la expresa referencia a la necesidad de medir como
factor estratgico de la organizacin 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 fcilmente identificable cmo 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 organizacin. Este desarrollo lgico coincide con el
aportado en el captulo 2 del presente estudio. La organizacin se describe en
funcin a un modelo basado en procesos cuyos atributos, su medida, determina el
grado de madurez de la misma.
La relacin de la calidad y su medida, de nuevo se considera un factor
estratgico. El modelo exige su control y medida pero no aporta cmo obtener
estos objetivos aunque hace referencia expresa al almacenamiento de datos
histricos.
En conclusin el modelo de referencia no considera tcnica o desarrollo terico
expreso en cuanto a la medida del software aunque afirma su necesario control. La
calidad y su medida son factores estratgicos en la organizacin, de tal importancia
que el Nivel 4 slo se alcanza cuando se han logrado satisfacer objetivos
relacionados directamente con la medida de atributos propios de los procesos
definidos. Sin embargo la definicin precisa de atributos no se define de forma
expresa.
Incluido en el Plan de Accin de la Subdireccin General de Coordinacin de

Informtica del Ministerio de Administraciones Pblicas (MAP) se elabor una
metodologa de desarrollo de sistemas de informacin denominada MTRICA.
La primera versin se remonta a 1989, MTRICA V. 1: Guas metodolgicas,
pero fue en 1993 cuando se public la versin 2: Gua tcnica, de referencia y de
usuario. En 1995 se liber la versin 2.1 y en julio de 2001 se ha liberado la
versin 3, mejora resultante de la publicacin 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 consideracin de las aportaciones recopiladas en esos siete
meses.
Para la elaboracin de MTRICA V.3 se han considerado mtodos
(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 tecnologas propias de la
informtica y las comunicaciones (clientelservidor, orientado a objeto, reutilizacin
y bases de datos, entre otras).
La elaboracin de MTRICA se basa en la participacin de diferentes actores
relevantes en la ejecucin de proyectos informticos. En concreto los intervinientes
en la ltima versin han sido:
O MAP y el Comit de Seguimiento.

O Administracin General del Estado (Defensa, Interior, Justicia, Trabajo,
entre otros).
O Comunidades Autnomas (Andaluca, Castilla-La Mancha, Madrid, Pas
Vasco).
O Ayuntamientos.
O Informtica El Corte Ingls (IECISA).
O Universidad Carlos 111de Madrid.
O Fondos PEINATYCA.
Los usuarios a los que va dirigida MTRICA V. 3. pueden resumirse en:
O Administracin del Estado.

O Comunidades Autnomas.
O Ayuntamientos.
O Centros de enseanza de ingeniera del software.
La metodologa MTRICA es utilizada habitualmente como referencia en

licitaciones cuyo objeto es el desarrollo de programas para ordenador publicadas
por organismos de carcter institucional espaoles. Las empresas aportan el
cumplimiento de esta metodologa como instrumento que permite la ejecucin en
plazo y coste del proyecto adjudicado. Esta consecuencia proviene de los objetivos
principales que esta metodologa expresa de forma determinante en su primer
captulo:
"La metodologa MTRICA Versin 3 ofrece a las Organizaciones un

instrumento til para la sistematizacin de las actividades que dan soporte al ciclo
de vida del software. La nueva versin de MTRICA contempla el desarrollo de
Sistemas de Informacin para las distintas tecnologas que actualmente estn
conviviendo y los aspectos de gestin que aseguran que un proyecto cumple sus
objetivos en trminos de calidad y coste."
5.1. MTRICA, una metodologa basada en procesos
MTRICA propone una descomposicin de los procesos en actividades,

dividiendo a su vez stas en tareas. Para cada tarea se definen sus productos
resultantes, entradas, contenido, tcnicas, prcticas y participantes definiendo de
forma expresa cada uno de estos elementos.
Los procesos principales de MTRICA Versin 3. son:
O Planificacin de sistemas de informacin.

O Desarrollo de sistemas de informacin.
O Mantenimiento de sistemas de informacin
A su vez el proceso principal desarrollo de sistemas de informacin se ha

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

O Anlisis del sistema de informacin (ASI).
O Diseo del sistema de informacin (DSI).
O Construccin del sistema de informacin (CSI).
O Implantacin y aceptacin del sistema (IAS).
MTRICA Versin 3 aporta un conjunto de procesos (definidos en la

metodologa como interfaces) orientados a la organizacin y como apoyo al propio
proceso de desarrollo. Estas interfaces definen un conjunto de actividades que,
segn la propia'met~dolo~a:
"En el caso de existir en la organizacin se debern aplicar para enriquecer o

influir en la ejecucin de las actividades de los procesos principales de la
metodologa y que si no existen habr que realizar para complementar y garantizar
el xito del proyecto desarrollado con MTRICA Versin 3."
Las interfaces que define MTRICA Versin 3 son:
O Gestin de Proyectos (GP).

O Seguridad (SEG).
O Aseguramiento de la Calidad (CAL).
O Gestin de la Configuracin (GC).
La metodologa MTRICA Versin 3 tambin aporta tcnicas con la intencin

de ayudar en la obtencin 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 Versin 3. propone el uso del
Anlisis del Punto Funcin para la estimacin de esfuerzos en el proyecto software,
entre otras muchas tcnicas propuestas.
METRICA es una metodologa extensa que debe adaptarse al sistema de
informacin que estemos desarrollando. No es adecuado aplicar MTRICA en toda
sus extensin 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 inclusin
en la metodologa de un apartado destinado a los Planes de Sistemas de
Informacin. Es evidente que el desarrollo de una aplicacin informtica limitada
en cuanto a recursos y funcionalidades no debe comenzar con la elaboracin de un
completo plan de sistemas, aunque s deber considerar la existencia del mismo en
la organizacin y adecuarse a las lneas estratgicas establecidas por ste.
A modo de ejemplo se indican a continuacin actividades y tareas consecuencia
de aplicar MTRICA Versin 3. en uno de sus apartados, en concreto en el
definido como EVS (Estudio de Viabilidad del Sistema). Cualquier otro apartado
de la metodologa se deber aplicar de forma similar a lo que veremos a
continuacin.
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 precisin
entradas y salidas del proceso, resultado y tareas que lo componen. Es interesante
observar como la existencia de un Plan de Sistemas de Informacin es recogida de
forma expresa como entrada de las tareas que componen este proceso. La
elaboracin de una posible solucin a un requerimiento debe estar encuadrada en la
estrategia corporativa especificada en el plan de sistemas de la institucin.
EVS 1,
EVS 2, Situacin actual
EVS 3, Catlogo de Anlisis del
EVS 4, Requisitos Sistema de
EVS 5, y Objetivos Informacin
EVS 6. Alternativas
de Solucin
Solucinn Pronuesta
Figura 4.10. Actividades consideradas en el proceso de Evaluacin del Sistema de

Informacin.
De las actividades que constituyen este apartado consideremos la denominada

EVSl (Establecimiento del alcance del sistema). Las tareas, productos,
participantes, tcnicas y prcticas 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, prctica y participantes, EVS.
La aplicacin de MTRICA Versin 3 proporciona sistemas con calidad y

seguridad, no obstante puede ser necesario en funcin de las caractersticas del
sistema un refuerzo especial en estos aspectos, refuerzo que se obtendra aplicando
la interfaz correspondiente.
Segn la propia metodologa:
"efinen una serie de actividades de interfaz con otros procesos organizativos o

de soporte que, en el caso de existir en la organizacin, enriquecern o influirn en
la ejecucin de las actividades de los procesos principales."
MTRICA Versin 3, aporta un apartado especfico de tcnicas a utilizar en los

procesos antes indicados. Estas tcnicas 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, gestin y soporte. Diagramas de distinta naturaleza y
objetivo, herramientas de estimacin y planificacin, anlisis de impacto,
prototipado de aplicacin etc. son algunas de las muchas propuestas por MTRICA
Versin 3 como apoyo al ingeniero de software.
Captulo 5
No ser nada intil ni ocioso...

haceros recordar la primera fuente y origen1
La rpida evolucin de la tecnologa informtica, con sus impresionantes

mejoras en prestaciones y rendimiento, no ha sido acompaada por una anloga
evolucin 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 investigacin y desarrollo de nuevas
formas de desarrollo de software, dando lugar a modelos y metodologas. Estos
modelos y metodologas, a pesar de mejorar la situacin, 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 solucin software correspondiente y
permiten modelar, adems de los aspectos estticos de los Sistemas Informticos,
algunos aspectos de su comportamiento.
1. MODELOS CONCEPTUALES
1.1. Definiciones
Oliv define el modelo conceptual como "la bsqueda y definicin formal del
conocimiento general sobre un dominio que un sistema de informacin (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 slo sea

una fase inicial, es mucho mayor que la de otras fases del ciclo de vida, ya que la
deteccin y correccin 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 atencin 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-Relacin (ER),
desarrollado en 1976 por Chen, y modificado posteriormente por otros autores,
todava pueden describir fcilmente los requisitos de datos de un Sistema de
Informacin con independencia del criterio de la gestin y organizacin de los
datos.
Los modelos conceptuales orientados a objetos representan, adems de los
datos, el comportamiento y funcionalidad del Sistema de Informacin, mediante
diagramas de clases, de actividad, de transicin 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 caractersticas del modelo conceptual y la
calidad del proceso con la manera en que se desarrollan los modelos conceptuales.
Algunos autores, como Batni 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,
solapndose entre s, presentan objetivos no realistas, presuponen la existencia de
diseo/implementacin y otros defectos.
I Batini et al. (1992) expresividad, autoexplicacin,

extensibilidad y normalidad
Correccin conceptual, complecin
conceptual, correccin sintctica,
Reingruber M. y Gregory W. (1994)
complecin sintctica, conocimiento de
la empresa.
1 Boman et a1 (1997)
Facilidad de compresin, correccin
semntica, estabilidad, complecin
conceptual.
Tabla 5.1. Calidad y sus propiedades segn 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 caractersticas en el modelado conceptual de los datos. En general, estos
marcos, al definir slo propiedades deseables y carecer de medidas cuantitativas,
no permiten medir eficazmente la calidad del producto obtenido.
Para evitar los sesgos en el proceso de evaluacin 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
mtricas de calidad de los modelos conceptuales han aparecido en los ltimos aos.
2.1. Mtricas de Kesh
El profesor S. Kesh public, en 1995~,el mtodo que haba desarrollado para el

aseguramiento de la calidad del modelo Entidad-Relacin. Este mtodo se basa en
que la calidad en estos modelos de datos se determina por dos tipos de
componentes: los ontolgicos y los de comportamiento.
El mtodo se compone de tres pasos:
1" Clculo del valor de cada uno de los componentes ontolgicos. Se calcula
individualmente el valor de los componentes estructurales (las relaciones entre los
elementos que forman el modelo: adecuacin al problema: 01, validez, 02,
consistencia, 03, y concisin, 04) y de los componentes de contenido (los atributos
de las entidades: completitud, os, cohesin, 06, y validez, 07).
2" Clculo de los valores de los componentes de comportamiento. Este clculo
se hace a partir de los valores de los componentes ontolgicos 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 diseador, s2, facilidad de mantenimiento, s3,
precisin, s4 y rendimiento, SS.
3" Clculo de la calidad del modelo Esta clculo se hace a partir de los valores
de los componentes de comportamiento de acuerdo con la frmula:
' 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 MTRICAS 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 organizacin en funcin de la importancia
que tengan para la misma.
Las frmulas para el clculo de las si son las siguientes:
Los valores de los factores ontolgicos son, en algunos casos, estimados por
los usuarios y, en otros, calculados mediante frmulas ad hoc. Los procedimientos
son los siguientes:
Adecuacin 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 tcnico que no est involucrado en el proyecto.
Consistencia del modelo (oj). Se calcula mediante la frmula
estando DI basado en el ratio nmero de inconsistencias/4n, siendo n el nmero de

relaciones en el modelo (4n representa el nmero de implicaciones).
Concisin del modelo (o4) Si un modelo ER tiene n entidades, el nmero
mnimo 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 estn
relacionadas entre s. En los dems casos, el valor (entre O y 5) se obtiene mediante
una frmula especfica.
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.
Cohesin del contenido (06). La cohesin para cada entidad es el tamao del
identificador primario. Si este est formado por un solo atributo, la cohesin es
mxima y, por lo tanto, o6 es 5. Al contrario, si el identificador primario est
formado por todos los atributos de la entidad. La cohesin es mnima y o6 vale O.

Para los dems casos se utilizan frmulas especficas.
Validez del contenido (0,) Si todos los atributos para todas las entidades son
vlidos 07 vale 5. Si todos los atributos se consideran invlidos. Se le atribuye a 07
el valor O. En los dems casos se aplica la frmula
siendo ni el nmero de entidades invlidas y n, el nmero de atributos de la

entidad.
Como el modelo est poco experimentado, es necesario mucha interaccin
entre los diseadores y los usuarios para su retroalimentacin. El propio Kesh
considera que el valor de Q no es una estimacin precisa, sino un indicador de la
calidad del modelo ER y que, por consiguiente, habra que seguir trabajando sobre
el modelo.
En resumen, el modelo de Kesh se aplica a modelos ER, tiene un enfoque
ontolgico y de componentes, comprende mtricas tanto objetivas como subjetivas,
no ha sido validado ni tericamente ni empricamente y no existen herramientas
matemticas.
2.2. Mtricas de Moody
En 1998, ~ o o d ~ \ r e s e n t un conjunto de mtricas, algunas objetivas y otras

subjetivas, para evaluar algunos factores de calidad de los modelos de datos. Estas
mtricas son, para los diferentes factores de calidad:
Complecin
- Nmero de elementos del modelo de datos que no corresponden con los

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

corresponden a polticas de negocio.
- Nmero 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 estratgica de los cambios.
- Nmero de elementos del modelo que en el fututo estarn sometidos a
cambios.
Correccin
- Nmero de violaciones a las formas normales.

- Nmero de violaciones a las convenciones de modelos de datos.
- Nmero de instancias de redundancias en el modelo.
Simplicidad
- Nmero de entidades.
- Nmero de entidades y relaciones.
- Nmero de constructores.
Integracin
- Nmero de conflictos con los sistemas existentes.

- Nmero de conflictos con el modelo de datos corporativo.
- Valoracin de los representantes de todas las reas del negocio.
Implementabilidad
- Valoracin de riesgo tcnico.

- Valoracin de riesgo de planificacin.
- Estimacin del coste del desarrollo.
- Nmero de elementos fsicos del modelo de datos.
Comprensibilidad
- Valoracin de los usuarios sobre la comprensibilidad del modelo.

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

para demostrar la validez de estas mtricas.
El mtodo de Moody no ha sido validado de terica ni prcticamente, no aporta
herramientas, tiene medidas objetivas y estimaciones subjetivas, y slo tiene en
cuenta algunos factores de calidad para los modelos ER
2.3. Mtricas 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 slo
puede hacerse cuando el producto est terminado o prximo 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:
Nmero total de entidades en el modelo ER.

Nmero total de atributos (simples, compuestos y multivaluados)
en el modelo, tanto en las relaciones como en las entidades.
NDA Nmero total de atributos derivados en el modelo.
NCA Nmero total de atributos compuestos en el modelo.
NMVA Nmero total de atributos multivaluados en el modelo.
NNR Nmero total de relaciones comunes en el modelo.
NM:NR Nmero total de relaciones N:M en el modelo.
NI: NR Nmero total de relaciones I:N e 1:I en el modelo.
NbinaryR Nmero total de relaciones binarias en el modelo.
NN AryR.
De ellas, son mtricas de tamao las NE, NA, NCA, NDA y NMVA, y de
complejidad el resto.
Estas mtricas del modelo ER son objetivas y han sido validadas tericamente
por Genero, siguiendo la teora de Zuse, y empricamente mediante un caso de
estudio y dos experimentos controlados.
3 . MTRICAS PARA MODELOS CONCEPTUALES ORIENTADOS A

OBJETOS
3.1. Mtricas de Brito e Abreu y Carapuqa
Brito y Carapuqa presentaron las mtricas 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 mtricas MOOD se definieron para aplicarlas a nivel de diagramas de
clases y se pueden utilizar en la fase de diseo. Las definiciones de las diferentes
mtricas son:
MHF El Method Hiding Factor (factor de ocultamiento de los mtodos)

se define como el cociente entre la suma de las invisibilidades de
todos los mtodos definidos en todas las clases y el nmero total de
mtodos definidos en el sistema. La invisibilidad de un mtodo es
el porcentaje del total de clases desde las cuales el mtodo es
invisible. El MHF es el ratio entre el nmero de mtodos privados
y el nmero total de mtodos, y sirve para medir la encapsulacin.
AHF El Attribute Hiding Factor (factor de ocultamiento de los atributos)
se define como el cociente entre el nmero de invisibilidades de
todos los atributos definidos en todas las clases y el nmero total
de atributos definidos en el sistema. Se propone tambin como
medida de encapsulacin.
MIF El Method Inheritance Factor (factor de herencia de los mtodos)
es el cociente entre el nmero de mtodos heredados en todas las
clases del sistema y el nmero total de mtodos (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 nmero de atributos
heredados en todas las clases del sistema y el nmero total de
atributos existentes (heredados y definidos localmente) en todas las
clases. Lo mismo que la anterior mtrica expresa la capacidad de
reutilizacin del sistema.
El Polymorphim Factor (factor de polimorfismo) se define como el
ratio entre el nmero actual de situaciones diferentes posibles de
polimorfismo y el nmero mximo de posibles situaciones distintas
de polimorfismos para cada clase. El factor PF es una medida
indirecta de la asociacin dinmica del sistema.
7
Las conclusiones de un estudio emprico 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 mtrica AHF es el 100%.

El incremento de la reusabilidad por medio de la herencia dificulta la
comprensin y el mantenimiento de los sistemas.
La redefinicin de modelos pueden reducir la complejidad y hacer el sistema
ms comprensible y fcil de mantener.
En resumen, las mtricas de Brito e Abreu y Carapuga se enfoca hacia las

caractersticas de los diagramas de clase, son medidas objetivas y han sido
validadas de forma terica y parcialmente de forma emprica.
3.2. Mtricas de Chindamber y Kemerer
En 1994, Chimdamber y ~ e m e r e r ' propusieron seis mtricas para la

complejidad del diseo Orientado a Objeto, aunque no todas pueden aplicarse a
nivel conceptual, y adems han sido muy criticadas por su ambigedad e
imprecisin.
Las mtricas que se considerarn son:
DIT La mtrica Depth of Inheritance. Tree se define como la

profundidad del rbol de una clase (en los casos de herencia
mltiple es la mxima longitud desde el nodo hasta la raz del
rbol). Se basa en que cuando ms profunda est la clase en la
jerarqua, mayor nmero de operaciones puede heredar. Se propuso
como una medida de la complejidad de una clase, complejidad de
diseo y reusabilidad potencial.
NOC La mtrica Number Of Children se define como el nmero de
subclases inmediatas subordinadas a una clase. Esta medida indica
cuntas subclases van a heredar las operaciones de la clase padre.
Esta mtrica presenta medidas objetivas para la complejidad de las clases y han
sido validadas tericamente por los autores al corroborar que satisfacen los
axiomas de weyuker9. La validacin emprica 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, nm. 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, nm. 10, 1996.

3.3. Mtricas de Lorenz y Kidd
Lorenz y ~ i d d " propusieron las mtricas de diseo par medir las

caractersticas estticas de un producto software. Se dividen en tres grupos:
mtricas de tamao, mtricas de herencia y mtricas de las caractersticas internas
de las clases.
De todas las propuestas, la que se pueden aplicar a un diseo de alto nivel son
las siguientes:
Mtricas de tamao
PIM La mtrica Nmero de Mtodos de Instancia Pblicos es el nmero

total de mtodos pblicos de instancias (los que estn disponibles
como servicios para otras clases). Se considera que mide la
cantidad de responsabilidad que tiene una clase.
NIM Se define el Nmero de Mtodos de Instancia como la suma de
todos los mtodos (pblicos, protegidos y privados) de una clase.
Segn los autores es una medida de la cantidad de colaboracin
utilizada.
NIV El Nmero de Variables de Instancia se determina por el nmero
total de variables (privadas y protegidas) a nivel de instancia que
tiene una clase.
NCM El Nmero de Mtodos de Clase es el nmero total de mtodos a
nivel de clase.
NW El Nmero de Variables de Clase es el total de variables a nivel de
clase que tiene una clase.
Mtricas de herencia
NMO El Nmero de Mtodos Sobrecargados es el nmero total de

mtodos sobrecargados en una subclase. Se propuso para medir la
calidad del uso de la herencia.
NMI El Nmero de Mtodos Heredados se define como el nmero de
mtodos que hereda una clase. Tambin mide la calidad del uso de
la herencia.
NMA El Nmero de Mtodos Aadidos es el nmero total de mtodos
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

nmero de mtodos sobrescritos multiplicado por el nivel de
anidamiento en la jerarqua y dividido entre el nmero total de
mtodos. Mide el grado en que una subclase redefine el
comportamiento de una superclase.
Mtricas de caractersticas internas de una clase
APPM El Promedio de Parmetros por Mtodo se define como el

cociente entre el nmero total de parmetros por mtodo y el
nmero total de mtodos.
Se enfocan estas mtricas a las caractersticas internas del diseo orientado a

objetos con medidas objetivas y una herramienta, la OOMetric, que slo puede
aplicarse a cdigo escrito en C++ y Smalltalk. No se ha validado tericamente y
slo empricamente de forma parcial.
3.4. Mtricas de Genero y al
enero'^ y otros
propusieron en el ao 2000 un conjunto de mtricas para la
medida de la complejidad estructural de los modelos de clase debido al uso de
relaciones UML. Se clasifican en: mtricas a nivel de modelo de clases y mtricas
a nivel de clase.
Mtricas a nivel de modelo de clases
Nassoc La mtrica Nmero de Asociaciones se define como el nmero

total de asociaciones dentro de un modelo de clases.
Nagg La mtrica Nmero de Agrupaciones se define como el nmero de
relaciones de agregacin dentro de un modelo de clases.
Ndep El Nmero de Dependencias es el nmero total de relaciones de
dependencia en un modelo de clases.
Ngen El Nmero de Generalizaciones se define como el nmero total de
relaciones de generalizacin dentro de un modelo de clases.
NgenH La mtrica Nmero de Jerarquas de Generalizacin es el total de
jerarquas de generalizacin 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 mtrica Nmero de Jerarquas de Agregacin es el nmero total
de jerarquas de agregacin dentro de un modelo de clases.
MmDIT La mtrica Mximo DZT se define como el mximo de los valores
DIT obtenidos de cada clase del modelo de clases. El valor DIT es
la longitud de la ruta ms larga desde la clase a la clase raz de la
jerarqua de generalizacin.
MaxHAgg La mtrica Mximo HAgg es el mximo de los valores Hagg de
cada clase del modelo de clases. El valor HAgg, dentro de la
jerarqua de agregacin, es la longitud de la ruta ms larga desde la
clase hasta las hojas.
Mtricas a nivel de clases
NassosC El Nmero de Asociaciones por Clase es el nmero 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 ms larga desde la
clase a las hojas, dentro de una jerarqua de agregacin.
NODP El Numero de Partes Directas de una clase es el nmero de Partes
Directas que contiene una clase que pertenece a una jerarqua de
agregacin.
NP El Nmero de Partes es el nmero de clases "partes" (directas o
indirectas) de una clase "todo".
NW La mtrica Nmero de Todos se define como el nmero de clases
"todos" (directas e indirectas) en una clase "parte".
Masg La mtrica Agregacin Mltiple es el nmero de clases "todo"
directas que tiene una clase en una jerarqua de agregacin.
Ndepln El Nmero de Dependencias In se define como el nmero de clases
que depende de una clase dada.
NdepOut El Nmero de Dependencias Out es el nmero de clases de las que
depende la clase dada.
Esta mtrica se enfoca hacia la complejidad estructural debida al uso de

relaciones y es objetiva. Se ha validado tericamente usando los marcos de Briand,
Zuse y Poels y Dedene. Tambin se han realizado diversos experimentos
controlados para validar empricamente las mtricas a nivel de modelos de clases.
Captulo 6
EL ANLISIS DEL PUNTO FUNCIN

En 1968 sabamos 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 informticos es uno de los objetivos principales de este texto.
El anlisis del Punto Funcin (APF) es una tcnica destinada a medir la
funcionalidad de una aplicacin informtica, entendida sta como el conjunto de
funciones aportadas al usuario por el producto informtico. Tal como veremos a lo
largo del captulo esta tcnica presenta severos problemas incompatibles con la
teora 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 obtencin de valiosas estadsticas. La medida del software es una disciplina que
se sustenta, como cualquier otra rama cientfica, sobre mejoras sucesivas. Hacer
uso de una herramienta que no es perfecta o matemticamente correcta no es un
error en s, siempre que conozcamos este hecho y sepamos las limitaciones que lo
acompaan.
1.1. La propuesta de Albrecht: ventajas e inconvenientes
La tcnica del anlisis del Punto Funcin fue ideada por Allan Albrecht,
especialista de la firma IBM, a finales de los aos 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 traduccin es nuestra.
Cliff Jones es profesor de la universidad de Manchester experto en metodologias y procesos de desarrollo del
software.
166 EL ANLISIS DEL PUNTO FUNCIN
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 das se han
generado diversas versiones del APF promovidas por el International Function
Point Users Group (IFPUG) w e . La organizacin IFPUG, tal como se
le conoce habitualmente, es una sociedad sin nimo de lucro cuyo fin es la
extensin y mejora del anlisis del Punto Funcin. Su sede se encuentra en los
Estados Unidos de Amrica. En este momento la ltima versin liberada del texto
Function Point Counting Practica1 Manual es la 4.1.1.
Otra fuente bibliogrfica 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 edicin. Existen numerosas versiones
posteriores de esta iniciativa. Uno de los proyectos acogido al programa ESPRIT
fue denominado METKIT (Metrics Educational ToolKIT). La filosofa que
auspici dicho programa fue proporcionar una educacin efectiva y rigurosa en el
campo de la medida del software. El resultado fue, entre otros, la elaboracin de
diferente material de auto-estudio destinado a promover el conocimiento y
utilizacin de la medida en el software. La tcnica del anlisis del Punto Funcin
fue uno de los objetivos del proyecto por lo que se elabor un mdulo en el que se
explicaba en detalle este mtodo. El programa ESPRIT y las aportaciones del
IFPUG son dos fuentes muy interesantes de conocimiento y especializacin
relacionadas con el APF (ver bibliografa).
El anlisis del Punto Funcin es utilizado habitualmente como alternativa a la
medida del tamao de una aplicacin informtica a las lneas de cdigo. El APF es
independiente de la tecnologa empleada en el desarrollo de los programas y
permite estimar el tamao de la aplicacin informtica (en nmero de Puntos
Funcin) 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
realizacin. Ya indicamos en el captulo 4 como el APF es propuesto como
herramienta dentro de la metodologa MTRICA Versin 3, por lo que podemos
afirmar que el anlisis del Punto Funcin se encuentra en plena expansin y es
utilizado en numerosas empresas de software obteniendo datos, en muchos casos
considerados estratgicos y secretos, por su relevancia dentro de la organizacin.
Sin embargo, tal como ya indicamos, existen problemas en la ejecucin de esta
herramienta, e incluso en su concepcin. Fenton y Pflegeer [Fenton y
Ptleeger,1997] hace un exhaustivo repaso a estos inconvenientes, alguno de los
ms significativos son:
- Existe un grado de subjetividad en la medida alcanzada, en concreto en el

denominado factor tecnolgico.
- Es necesario una muy detallada definicin del proyecto si pretendemos

medir el mismo en las primeras etapas del desarrollo.
- Aparecen problemas e ineficacia de la medida al depender de la tecnologa
utilizada. El APF no es totalmente independiente del sistema de anlisis o
del mtodo de diseo utilizado aunque supone una mejora frente al uso de
lneas de cdigo, por ejemplo.
- Aparecen problemas cuando se utiliza el APF en aplicaciones de carcter
cientfico o aplicaciones en tiempo real.
- Existen problemas con la teora 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 mtodo depende de forma dramtica de la experiencia del tcnico que
evala la aplicacin, ms an, la medida de una aplicacin, realizada por un mismo
tcnico vara sustancialmente si sta es ejecutada cuando la aplicacin posee un
nivel de detalle distinto en su documentacin. Una aplicacin correctamente
documentada implica una mejor y ms fcil medida que otra aplicacin con
deficiencias en su documentacin. El anlisis del Punto Funcin requiere un nivel
de disciplina elevado e incluso procesos de retroalimentacin que disminuyen
considerablemente la dispersin 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 obtencin
de'datos ms objetivos. Generalmente la informacin acumulada por una empresa
u organizacin en la medida de Puntos Funcin alimenta bases de datos de carcter
corporativo que son utilizadas como repositorios de informacin 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 ejecucin de un nuevo proyecto. Los datos tienen difcil utilidad en otras
empresas pero son sumamente tiles si la organizacin que acomete este trabajo
insiste en el uso de esta medida y acumula datos histricos.
El anlisis del Punto Funcin es muy utilizado en ecuaciones, como la densidad
de defectos, al sustituir las lneas de cdigo por el nmero de Puntos Funcin en la
cuantificacin del tamao de la aplicacin informtica.
Nmero de defectos descubiertos en el programa

Ecuacin 6.1
Tamao del programa
168 EL ANLISIS DE L PLINTO F L I N C I ~ N
Segn la ecuacin 6.1 las unidades propias de la densidad de defectos son el

nmero de defectos por nmero de Puntos Funcin del programa.
2. EL ANLISIS DEL PUNTO FUNCIN PASO A PASO
El Anlisis del Punto Funcin es un procedimiento secuencia1 que se compone

de un conjunto de pasos que hemos de ejecutar. A continuacin explicamos en
detalle el procedimiento a realizar hasta la obtencin del nmero de Puntos
Funcin de la aplicacin 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
aplicacin a medir y determinar las ecuaciones que se han de utilizar. El IFPUG
considera tres tipos de conteo de Puntos Funcin, segn el estado de implantacin
y desarrollo en que se encuentre la aplicacin informtica.
Provectos de desarrollo. El conteo de los Puntos Funcin de proyectos de

desarrollo mide las funciones proporcionadas al usuario final con la
primera instalacin del software entregado, una vez el proyecto ha sido
completado.
Provectos de mejora. El conteo de los Puntos Funcin de proyectos de
mejora mide las modificaciones sobre las aplicaciones existentes que
aaden, cambian o eliminan funciones de usuario entregadas cuando el
proyecto fue completado.
Aplicacin. El conteo de los Puntos Funcin de aplicaciones est asociado
con sistemas ya instalados. Esta contabilidad ofrece la medida de las
funciones que la aplicacin 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 lmites en los que se aplicar el conteo de los Puntos
Funcin
Identificar los lmites en los que se aplicar el conteo de los Puntos Funcin
significa determinar el borde entre el proyecto o aplicacin que est siendo medido
y aplicaciones externas o el dominio del usuario.
El IFPUG fija una serie de reglas para su identificacin.
El lmite de la aplicacin se determina en funcin del punto de vista del

usuario. Nos hemos de centrar en aquello que el usuario puede entender y
describir.
El lmite entre aplicaciones afines se basa en las distintas funciones
apreciadas desde el punto de vista del usuario, no en consideraciones
tecnolgicas.
Para proyectos de mejora, el lmite inicial debe ajustarse a lmites ya
establecidos para la aplicacin o las aplicaciones que estn siendo
modificadas.
Este paso requiere la colaboracin del usuario final. Consideramos muy til
para la ejecucin de este segundo punto la realizacin de reuniones con el
responsable funcional o usuario responsable de la aplicacin a medir. El punto de
vista por l aportado, unido a la informacin recabada del equipo de desarrollo,
sistemas e incluso gestor de la base de datos nos permite obtener el conocimiento
necesario para determinar adecuadamente los lmites de la aplicacin.
El anlisis del Punto Funcin propone una serie de conceptos asociados a los
datos y a las transacciones. Los Tipos de Funcin 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
Funcin de Datos son los Ficheros Lgicos Internos y los Ficheros de Interfaz
Externos. Cuantifiquemos cada uno de ellos.
2.3. Identificacin de los Ficheros Lgicos Internos (FLI)
Un Fichero Lgico Interno (FLI) es un grupo de datos relacionados

lgicamente, o informacin de control, identificables para el usuario y mantenidos
dentro de los lmites de la aplicacin.
Para identificar los Ficheros Lgicos Internos presentes en el sistema, se han de
buscar datos o informacin de control que cumplan con la definicin propuesta.
Los ficheros aspirantes son sometidos a un cuestionario. Slo cuando todas las
preguntas propuestas tienen respuesta afirmativa podemos resolver que los datos
considerados son FLI.
Desde un punto de vista prctico el proceso de identificacin 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 lgicos, o identificables
por el usuario, de forma que cumple con especficos
requisitos de ste?
Pregunta 2 El grupo de datos es modificado, o Afirmativo/Negativo.

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

mantenido, a travs de un proceso elemental de la
Afirmativo/Negativo.
o Fichero de Interfaz Externo
Tabla 6.2. Identificacin de los Ficheros Lgicos Internos.
2.4. Identificacin de los Ficheros de Interfaz Externo (FIE)
Un Fichero de Interfaz Externo (FIE) es un grupo de datos relacionados

lgicamente, o informacin de control, identificables para el usuario, referidos por
la aplicacin, pero mantenidos dentro de los lmites de otra aplicacin. Esto
significa que un Fichero de Interfaz Externo de una aplicacin debe ser un Fichero
Lgico Interno para otro sistema.
Para identificar los Ficheros de Interfaz Externos se han de buscar datos o
informacin de control que cumplan con la definicin propuesta. Los ficheros
aspirantes son sometidos a un cuestionario. Slo cuando todas las preguntas
formuladas tienen respuesta afirmativa podemos resolver que los datos
considerados son FIE.
Desde un punto de vista meramente prctico el proceso de identificacin 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 Igicamente 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 aplicacin que est siendo
considerada y, adems, es externo a la misma?
Pregunta 3 El gmpo de datos no es mantenido AfimativoMegativo.

por la aplicacin que est siendo medida?
Pregunta 4 El gmpo de datos es considerado Afimativo/Negativo.

como un FLI, al menos por otra aplicacin?
Pregunta 5 El grupo de datos considerado no ha AfimativoMegativo.
Tabla 6.3. Identificacin de los ficheros interfaz externos.
2.5. Clasificar la complejidad de los ficheros lgicos y determinar su

contribucin
El nmero de ficheros lgicos y su complejidad relativa funcional determina la

contribucin de los tipos de funcin de datos al conteo de los Puntos Funcin sin
ajustar.
La asignacin de complejidades a FLI y FIE se basa en el nmero de Tipos de
Elementos de Datos (TED) y nmero 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 lgicos 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 relacin con otro FLI. Es lo que se denomina como
clave externa.
Regla 3.
Considerar las siguientes tcnicas de implementacin como un simple TED,
para el grupo de campos considerado.
- Campos que aparecen ms de una vez en un FLI o FIE por razones
tecnolgicas o tcnicas de implementacin.
- Campos repetidos que son idnticos en su formato y existen para permitir
mltiples ocurrencias de un dato.
Desde un punto de vista meramente prctico el proceso de identificacin 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 fsicas como
usuario en un FLI o FIE de ellas simples TED
Fichero " Pmeba A"
Campo "AA" SiMo SiMo SiMo
Campo " A B SiMo SiMo SINo
Campo "AC" SiMo SiMo SMo
...
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 opcin de utilizar uno o

ninguno de los subgrupos durante un proceso elemental que aade 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 prctico el proceso de identificacin 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 ejecucin de este punto es sumamente beneficioso concretar reuniones

con el coordinador de informtica correspondiente o responsable funcional ya que
nos permite identificar los subgrupos de datos en cada fichero lgico reconocido.
Insistimos en que el punto de vista del usuario es fundamental en esta herramienta
por lo que su colaboracin es imprescindible.
Una vez conocidos los tipos de elementos de datos y los tipos de elementos de
registros propios de cada fichero lgico podemos establecer el nivel de
complejidad apoyndonos en la tabla 6.6.
Tabla 6.6. Asignacin de complejidad segn TER y TED.
Este proceso permite medir la complejidad segn una escala ordinal de tres
puntos.
174 EL ANALISIS DEL PUNTO FUNCIN
2.6. Conteo de los tipos de funcin asociado a transacciones
Los tipos de funcin asociados a transacciones representan la funcionalidad

proporcionada al usuario para el procesamiento de datos por una aplicacin. Estos
tipos de funcin se dividen en: Salidas Externas (SE), Entradas Externas (EE) y
Cuestiones Externas (CE).
2.6. l . Identificacin de Entradas Externas
Una Entrada Externa (EE) procesa datos o informacin de control que

provienen de fuera de los lmites de la aplicacin. La Entrada Externa es en s
misma un proceso elemental.
Para identificar las Entradas Externas se han de buscar datos o informacin de
control que se encuentren dentro de la definicin propuesta. Las transacciones
aspirantes se someten, entonces, a un cuestionario. Slo cuando todas las preguntas
tienen respuesta afirmativa podemos resolver que las transacciones estudiadas son
EE.
Desde un punto de vista prctico la identificacin 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 (identificacin de Entradas
Externas) se ha de discriminar entre tratamiento de datos y de informacin de
control.
LA CALIDAD DEL SOFTWARE Y SU MEDiDA 175
Regla 2. Los datos en un FLI son Afirmativo/Negativo

mantenidos a travs de un proceso
elemental de la aplicacin.
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 aplicacin 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 lgico es nico
en relacin a otras
Entradas Externas.
- Para el sistema los
elementos de datos
identificados son
diferentes en relacin a
otras Entradas Externas.
Tabla 6.7. Identificacin de Entradas Externas para datos.
* El concepto autocontenido proviene del entorno en el que se ide el mtodo APF y es equivalente al de
transaccin, entendida sta como interaccin con el sistema que permite asegurar la coherencia del sistema
despus de la finalizacin correcta o no de dicha transaccin.
Afirmativo/Negativo
recibida desde fuera de la aplicacin.
Regla 2. La informacin es especificada Afirmativo/Negativo

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

una de las dos siguientes reglas debe ser
- Para el sistema, el
procesamiento lgico es
nico en relacin con otras
Entradas Externas.
- Para el sistema, los
elementos de datos
identificados son diferentes
en relacin con otras
Tabla 6.8. Identificacin de Entradas Externas para informacin de control.
2.6.2. Identificacin de Salidas Externas
Una salida externa (SE) se define como un proceso elemental que genera datos
o informacin de control y son enviados fuera de los lmites de la aplicacin.
Para identificar las Salidas Externas se han de buscar procesos elementales que
se encuentren dentro de la definicin propuesta. Las transacciones aspirantes se
someten, entonces, a un cuestionario. Slo cuando todas las preguntas tienen
respuesta afirmativa podemos resolver que las transacciones estudiadas son SE.
Desde un punto de vista prctico la identificacin 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
lmites del sistema.
Regla 2 Un resultado sale de los lmites de AfirmativoMegativo

la aplicacin.
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 aplicacin 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 lgico 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 aplicacin.
Tabla 6.10. Identificacin de Cuestiones Externas (CE).

2.6.4. Clasificar la complejidad de las transacciones identificadas y su

contribucin
Una vez identificadas las transacciones se ha de estudiar su complejidad. Esta

caracterstica, unida al nmero transacciones contabilizadas, determinarn la
contribucin al conteo de los Puntos Funcin sin ajuste.
En el caso de Entradas Externas la complejidad se sustenta en el nmero de
Tipos de Ficheros Referidos (TFR) y los Tipos de Elementos de Datos (TED). Un
TFR se define como un FLI ledo o mantenido por un tipo de funcin o un FIE
ledo por un tipo de funcin. Un Tipo de Elementos de Datos es un campo no
recurrente reconocible para el usuario, mantenido en FLI por una EE.
Para contabilizar el nmero 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 ledo y mantenido por una EE.
Desde un punto de vista prctico la identificacin 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 travs de una EE sobre un FLX.
Regla 3. Considerar las siguientes tcnicas de implementacin para un grupo de

campos como un nico TED:
- Campo lgico almacenado fsicamente en muchos campos pero requerido por
el usuario como una pieza simple de informacin.
- Campos que aparecen ms de una vez en un FLI por causas tcnicas o de
implementacin.
- 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 accin a ser
realizada por la EE.
Desde un punto de vista prctico la identificacin 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 nmero de Tipos de

Ficheros Referidos (TFR) y del nmero de Tipos de Elementos de Datos (TED).
Un TFR se define como un fichero ledo 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 ledo durante el procesamiento de
una salida externa.
Desde un punto de vista meramente prctico 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, ttulos.. .).
Regla 3. No considerar variables de paginacin o marcas generadas por el
sistema.
Regla 4. Considerar las siguientes tcnicas de implementacin fsica como un
nico TED.
Regla 4.1. Un campo lgico almacenado fsicamente en mltiples campos
cuando es requerido por el usuario como una pieza nica de informacin.
Regla 4.2. Cada impresin de etiqueta o cada impresin de equivalente
numrico en una salida grfica.
Regla 4.3. Informacin de texto que puede ser una simple palabra, frase o
sentencia.
Desde un punto de vista prctico 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 nmero 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 Funcin.
Un TFR se define como un fichero ledo al procesar una Cuestin Externas. Un
TED se define como un campo no recurrente y reconocible para el usuario que
aparece en una Cuestin 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 ledo durante el procesamiento
de la Cuestin Externa.
Para la Salida.
Reala 1. Contar un TFR por FLI o FIE ledo durante el procesamiento de

Cuestiones Externas.
fiesde un punto de vista prctico 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 Cuestin Externas.
Regla 2. Contar un TED por cada campo que especifica el criterio de seleccin
de los datos.
Regla 3. Considerar las siguientes tcnicas de implementacin para un grupo de
campos como un nico TED.
y no vr
P; fsica?
I como m Considerair un TED
N ado
Tabla 6.17. Complejidad asociada a CE, contabilidad de TED
Una vez identificados para cada transaccin 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. Asignacin de complejidad para Entradas Externas
Tabla 6.19. Asignacin de complejidad para Salidas Externas
Conocidos los niveles de complejidad (alto, medio o alto) de cada transaccin

se asigna, segn la tabla 6.20, un peso diferente a cada uno de stos.
Complejidad baja
Complejidad media
Tabla 6.20. Contribucin al conteo segn complejidad.
2.6.5. Clculo del valor de los Puntos Funcin sin ajustar
Con la informacin obtenida en los pasos anteriores la mecnica a seguir en el

clculo de los Puntos Funcin sin ajustar es:
1. Contar el nmero de ficheros y transacciones identificados agrupando

stos segn su complejidad.
2. Multiplicar el nmero de ficheros y transacciones ya agrupados segn su
complejidad por el factor correspondiente.
3. Sumar los 15 valores obtenidos.
La ecuacin para determinar los Puntos Funcin sin ajustar es:
15
UFC = (Nmero de items de var iedad i) x ( p e s q) Ecuacin 6.7
i=I
Desde un punto de vista prctico el clculo de los Puntos Funcin sin ajustar se
determina obteniendo tablas tales como 6.21 y 6.22. Los datos incluidos en las
tablas son a ttulo de ejemplo.
186 EL ANALISIS DEL PUNTO FWCIN
po de
ncin incin
Tabla 6.21. Clculo de los Puntos Funcin sin ajustar para Ficheros Lgicos.
. --- .
Funcin 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 clculo de los Puntos Funcin sin ajustar para
transacciones.
En este caso los Puntos Funcin sin ajustar se determinaran sumando los
factores indicados en la ltima columna de las tablas asociadas a transacciones y
ficheros:
UFC = 15 + 46 + 36 + 42 +31 =170 Ecuacin 6.8
2.6.6. Clculo del valor del factor de ajuste
El clculo del Valor del Factor de Ajuste (VAF) se basa en la cuantificacin de

catorce Caractersticas Generales del Sistema (GSC), permitiendo establecer la
funcionalidad general de la aplicacin medida. La cuantificacin es posible al
establecerse el grado de influencia de cada factor y hacerla coincidir con una escala
que vara 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 Caractersticas Generales del Sistema sobre una escala de valor
mnimo "0" y valor mximo "5". Esta estimacin se ha de basar en la
influencia de cada una de las 14 caractersticas sobre el sisterra medido.
b. Determinar el grado de influencia total (TID), sumando el grado de influencia
de cada una de las caractersticas evaluadas.
c. Aplicar la ecuacin :
VAF = ( TDI * 0.01 ) + 0.65 Ecuacin 6.9
Las caractersticas del sistema a considerar son:
1. Comunicaciones.
2. Procesamiento distribuido de datos.
3. Rendimiento.
4. Uso elevado de la configuracin.
5. ndice de transacciones.
6. Entrada de datos en-lnea.
7. Eficiencia y usuario final.
8. Actualizacin en-lnea.
9. Procesamiento complejo.
10. Reutilizacin.
1 1. Fcil instalacin.
12. Fcil operacin.
13. Mltiples 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 clculo del factor de ajuste es criticado por ser uno de los componentes ms
subjetivos del Anlisis del Punto Funcin.
2.6.7. Clculo de los Puntos Funcin ajustados
Como indicamos en su momento podemos considerar tres tipos de clculo

segn el estado de implantacin y desarrollo en que se encuentre la aplicacin a
medir. Veamos cada uno de ellos y las ecuaciones asociadas a los mismos.
Clculo del Punto Funcin Ajustado en el caso de Desarrollo de Proyectos.
Los componentes que intervienen en el clculo de la funcionalidad son tres:
- La funcionalidad de la aplicacin incluida en los requisitos del usuario para el

proyecto.
- La conversin 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 Ecuacin 6.10
Donde:
DFP es el valor de los Puntos Funcin del desarrollo del proyecto.

UFP es el valor de los Puntos Funcin sin ajustar.
CFP es el valor de los Puntos Funcin aadidos por la conversin de Punto

Funcin sin ajustar.
VAF es el valor del factor de ajuste.
Clculo de los Puntos Funcin en el caso de meiora de proyectos.
Los componentes que intervienen en este caso son tres:
- Funcionalidad de la aplicacin incluida en los requisitos del usuario para el

proyecto.
- Conversin de funcionalidad.
- Valor del factor de ajuste.
En este caso la frmula utilizada es:
EFP = [(ADD + CHGA + CFP) * VAFA] + ( DEL * VAFB) Ecuacin 6.11
donde:
EFP son los Puntos Funcin contabilizados en la mejora del proyecto.

ADD son los Puntos Funcin sin ajustar de aquellas funciones que fueron
aadidas por la mejora del proyecto.
CHGA son los Puntos Funcin de aquellas funciones que fueron modificadas
por la mejora del proyecto. Este nmero refleja las funciones tras las
modificaciones.
CFP son los Puntos Funcin aadidos por la conversin.
VAFA: es el valor del factor de ajuste para la aplicacin despus de la mejora.
DEL es el Punto Funcin sin ajustar de aquellas funciones que fueron borradas
por la mejora del proyecto.
VAFB es el valor del factor de ajuste de la aplicacin antes del proyecto de
mejora.
Clculo de los Punto Funcin para el caso de aplicaciones.
En este punto se establecen las frmulas para el clculo de los Puntos Funcin
para aplicaciones. Existen dos variantes a esta frmula.
Frmula para establecer los Puntos Funcin iniciales de la aplicacin.
Frmula para restablecer los Puntos Funcin para una aplicacin tras una
mejora que implica un cambio en la funcionalidad de sta.
La frmula que establece el valor inicial de los Puntos Funcin para una
aplicacin es:
AFP = ADD * VAF Ecuacin 6.12
donde:
APF son los Puntos Funcin para el estado inicial de la aplicacin.

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

la funcionalidad de la aplicacin. La frmula utilizada en este caso es:
APF = [ (UFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA Ecuacin 6.13
Donde:
AFP son los Puntos de Funcin ajustados.

UFPB son los Puntos de Funcin no ajustados antes de la mejora del proyecto.
ADD son los Puntos Funcin de aquellas funciones aadidas por la mejora del
proyecto.
CHGA son los Puntos Funcin sin ajustar de aquellas funciones modificadas
por la mejora del proyecto antes de que los cambios ser produjeran.
CHGB son los Puntos Funcin sin ajustar de aquellas funciones modificadas
por la mejora del proyecto despus de que los cambios ser produjeran.
DEL son los Puntos Funcin 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 bibliografa con

numerosos ejemplos prcticos que colaboran en gran medida en el conocimiento de
este tipo de medidas.
A modo de resumen y como gua prctica aportamos el siguiente cuadro:
Determinar tipo de Identificar lmites Identificar FLI
Identificar FIE
Leyenda
Se aconseja participacin del responsable
funcional.
Requiere cumplimentar formulario
Figura 6.1. Esquema aplicacin Anlisis Puntos Funcin.

3. MS ALL DEL ANLISIS DEL PUNTO FUNCIN TRADICIONAL
El Anlisis del Punto Funcin posee ventajas e inconvenientes que ya hemos

indicado al principio de este captulo, sin embargo, es incuestionable la extensin
de su uso en numerosos pases de todo el mundo, especialmente en Estados
Unidos, Canad y Reino Unido, y su utilizacin habitual en empresas de desarrollo
como medida del tamao de las aplicaciones informticas.
Del conocimiento y utilizacin del APF han surgido diferentes modificaciones o
variaciones de esta medida con objeto de mejorar su exactitud y permitir su
utilizacin en entornos distintos al origen histrico de la misma, recordemos:
grandes bases de datos que reciban gran cantidad de accesos bajo una tecnologa
transaccional pura, entorno tecnolgico propio de organizaciones como bancos u
organismos oficiales.
La aportacin de Symons [Symons, 19881 se basa en la utilizacin de
"transacciones lgicas", consideradas stas como procesos de entrada-salida a los
que, adems, aplica ciertos pesos. El nombre de esta modificacin del APF se
denomina Mark 2. Capers Jones [Jones, 20001 ha realizado diferentes estudios
sobre el Anlisis del Punto Funcin, stos han sido utilizado por otros autores para
promover mejoras y cambios en la medida, entre los que cabe destacar los Punto
Funcin 3D y los denominados Full Function Point.
Entre las novedades ms interesantes cabe destacar la aportacin del profesor
Francisco Sanchs de la Universidad de Oviedo. Su trabajo, presentado en el foro
sobre calidad e informtica celebrado en Santiago de Cuba en el primer trimestre
del 2003, se basa en el estudio de la sensibilidad del Anlisis del Punto Funcin
aportando interesantes modificaciones al mtodo que lo mejoran.
El Anlisis del Punto Funcin se encuentra en continua mejora y posee un
evidente dinamismo fruto de su utilizacin en las organizaciones.
Captulo 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 captulo 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 captulo con un ejemplo prctico en el que aplicaremos los
conocimientos explicados en apartados anteriores.
La calidad de un programa informtico es un atributo complejo, compuesto de

otros muchos atributos, incluso diferentes segn el observador. El responsable de
sistemas de una organizacin considerar un programa de gran calidad si consume
poco recursos tcnicos tales como servidores o lneas de comunicacin y los utiliza
eficientemente, el usuario har hincapi en las funciones del programa y en la
inexistencia de errores en tiempo de ejecucin, el responsable de la cuenta de
resultados de la empresa que desarrolla la aplicacin 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 segn 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 Espaa". Computenvorld, 7-13 septiembre de
2001.
194 LA NORMA ISOIIEC 9126
software proponen la descomposicin de este atributo en otros ms simples y

medibles, al tiempo que establecen los requisitos de calidad. Con este
procedimiento no slo podemos enfrentarnos a la medida de la calidad de forma
ms simple y coherente, tambin nos ayudar a conocer el programa informtico,
sus caractersticas 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 descomposicin jerrquica es una estrategia muy utilizada en diferentes
disciplinas cientficas. La ingeniera del software la explota en beneficio del
conocimiento real de los atributos de calidad.
1.1. La descomposicin jerrquica en rbol
Los modelos de calidad asumen en su mayora 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 tambin se han considerados atributos internos como la
eficiencia), stos se descomponen en otros de ms bajo nivel denominados criterios
de calidad y que suelen ser atributos internos. Una vez alcanzado este nivel se
procede a una segunda descomposicin, realizada de forma que los criterios de
calidad sean asociados a atributos que pueden ser medidos a travs de las
denominadas mtricas 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 captulo. Todos estos modelos siguen la filosofa de
simplificacin jerrquica en rbol.
La conexin entre atributos, mtricas y factores de calidad no es un axioma de
aceptacin 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 ejecucin de medidas y su relacin ltima con la calidad del
software a travs 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 mtrica y
medida. La medida de un atributo ha sido explicada en el captulo 2 por lo que es
un trmino definido y claro. Sin embargo el uso de mtrica se ha utilizado para
especificar muy diversas entidades. Medidas directas, indirectas, procedimientos de
medid?, atributos del programa informtico, entre otros. Para evitar problemas y
ambigedades optamos por considerar una mtrica como una medida directa de un
atributo simple [Fenton y Pleeger, 19971. Como veremos ms adelante las mtricas
del software se combinarn 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 travs de la descomposicin

jerrquica.
Se pueden considerar dos aproximaciones diferentes a la hora de implantar un

modelo de calidad [Kan, 20031. Por un lado podramos realizar una aplicacin
rgida de un modelo prefijado en el que los factores de calidad son aportados por el
modelo seleccionado. Por otro lado podemos considerar una aproximacin 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 descomposicin en factores y las correspondientes mtricas de calidad. La
relacin entre factores y criterios de calidad es establecida tambin por usuarios e
ingenieros de software aunque generalmente se escoge algn 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 relacin 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 clsicos de la utilizacin de

la descomposicin jerrquica para la medida de la calidad. El modelo de McCall es
uno de los ms 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 (operacin del

producto, revisin del producto y transicin del producto), incluye 41 mtricas
(entendida como medidas directas de los atributos, ver captulo 2), 21 criterios de
calidad y 11 factores de calidad. Se ha incluido en este modelo un nivel ms de
descomposicin al considerar la calidad de uso o puntos de vista de la calidad. La
figura 7.2 nos muestra de forma grfica la propuesta de McCall. La
descomposicin, por tanto, se basa en tres ejes bsicos sobre los que luego se
aplican descomposiciones sucesivas.
Punto de vista Factores

- Facilidad de uso.
- Integridad.
Operacin del Producto - Correccin.
- Fiabilidad.
- Eficiencia.
- Facilidad de
mantenimiento.
Revisin del Producto
- Facilidad de prueba.
- Flexibilidad.
- Facilidad de reutilizacin.
Transicin 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 mquina?
Flexibilidad Reutilizacin
Puedo modificarlo? Puedo volver a utilizar parte del
Correccin
Hace el programa lo que quiero?
Fiabilidad
Lo hace de forma exacta todo el tiempo?
Eficiencia
Se ejecutar sobre el soporte fsico de forma
ptima?
Facilidad de uso
i,Puedo utilizarlo?
Figura 7.2. Modelo clsico de calidad del software propuesto por McCall.
La operatoria para la obtencin de un resultado numrico relacionado con uno

de los puntos de vista propuesto por McCall es descomponerlo hasta la obtencin
de medidas cuya combinacin preemitira la cuantificacin de la calidad. Debemos
determinar los factores asociados a la Operacin, Transicin o Revisin 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 comprobacin con objeto de conocer si se
aplica a los requisitos (R) al diseo (D) o a la implementacin (1). La figura 7.3 nos
muestra alguna de las preguntas tipo de la lista de revisin utilizada para el criterio
de calidad "nivel de cumplimiento" dentro del factor de calidad "correccin".
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 comprobacin para criterios de calidad.
Las letras R, D, 1, indican si la lista de comprobacin es aplicable a los

requisitos (R), al diseo (D) y10 la implementacin (1). Se ha de responder SNo a
cada pregunta de la lista para cada uno de los criterios.
McCall propone para cada criterio una frmula de regresin del tipo:
Medida criterio = r, m , + r,m, + ... + rnmn Ecuacin 7.1
Donde r, identifica los coeficientes de regresin y mj representa las distintas

mtricas 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 - ( nmero de erroreslnmero de lneas de cdigo)
o Facilidad de mantenimiento = 1 - 0,1 (nmero medio de das-hombre por

correccin)
o Movilidad = 1 - (esfuerzo para trasladarlesfuerzo para implementar)
U Flexibilidad = 1 - 0,05 (nmero medio de das-hombre por cambio)
Las medidas propuestas pueden ser modificadas segn el criterio del tcnico. Es
muy habitual el uso de la medida de la fiabilidad considerando el nmero de
errores por el tamao de la aplicacin contabilizados segn el nmero de puntos
funcin. El nivel de subjetividad de la medida es uno de los problemas a resolver

por parte de la ingeniera del software. Todos deben medir lo mismo y de la misma
forma.
Modelo de Boehm
Independencia
Figura 7.4. Modelo de Boehm para la descomposicin 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 tcnico o el usuario de la aplicacin. 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 travs de la
descomposicin jerrquica en rbol.
2. LA NORMA ISOIIEC 9126
La norma ISOIIEC 9126, en su apndice "C", llamado historia del trabajo,

reconoce la dificultad existente para comparar y entender la calidad del software
por parte de los usuarios/clientes, an 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 situacin impuls la
propuesta de creacin de un modelo de calidad que deba 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 organizacin (ISO) acepta el fracaso de este primer intento de
normalizar la calidad del software argumentando la falta de una base comn de
acuerdo y existiendo, por tanto, un amplio campo de arbitrariedades y subjetividad.
Con el objetivo de superar esta situacin ISO propone basar el estudio y
normalizacin de la calidad en la definicin de este concepto, calidad, propuesto en
la norma ISO 8420. Conseguir una estandarizacin y asenso internacional debe
sustentarse en una definicin aceptada y nica, la propuesta de una definicin de la
calidad pareca una iniciativa fundamental para proseguir en la creacin del
estndar. En 1991 se publica la primera edicin de la norma ISOIIEC 9126 con
objeto de "promover un entorno que permita la evaluacin de la calidad del
softwarev3. Sin embargo en 1994 se entendi necesaria la modificacin y
Como nota es interesante destacar la dificultad de traduccin de algunos trminos ingleses al espaol. En
muchos casos asistimos a traducciones casi literales de los trminos anglosajones. En nuestro caso entendemos
ms adecuado el realizar traducciones ms libres pero con un significado que entendemos ms til y descriptivo
del vocablo ingls.
IS0.9126 Information technology - Software product evaluation - Quality characteristics and guidelines for
their use. Suiza, 1991. Pg. iv. La traduccin es nuestra.
LA CALIDAD DEL SOFTWARE Y SU MEDIDA 20 1
adaptacin de la norma. En esta versin se introdujeron los conceptos de calidad

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

- Parte 2: Mtricas internas.
- Parte 3: Mtricas externas.
- Parte 4: Calidad en las mtricas de uso.
Sin embargo slo la parte primera, modelo de calidad, es un estndar 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 caractersticas del

producto software desde un punto de vista interno", y la calidad externa definida
como "la totalidad de las caractersticas 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 estn
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 segn ISOIIEC 9126.
La calidad de uso es definida por la norma como "la capacidad del software que
posibilita la obtencin de objetivos especficos con efectividad, productividad,
satisfaccin y seguridad".
Es interesante observar como la norma ISOIIEC 9126 aborda el conocimiento
de la calidad dividindolo en calidad interna o externa de forma similar a como se
propone por Fenton y que ya explicamos en el captulo 2. En este caso los
conceptos de atributos internos y externos son menos definidos en la norma que en
la aproximacin de Fenton y no coinciden en su totalidad con esta teora, sin
embargo se observa una aproximacin similar al problema considerando diferentes
"niveles" en la calidad que se influyen entre s.
Figura 7.6. Modelo de calidad segn ISOIIEC 9126.
La definicin de cada uno de las caractersticas y subcaractersticas es:
Funcionalidad. Se define como un conjunto de atributos que ataen a la

existencia de un conjunto de funciones y sus propiedades especficas. Estas
funciones son las que satisfacen las necesidades implcitas y establecidas. Esta
caracterstica del software puede ser desglosada en varias subcaractersticas:
o Idoneidad. Capacidad del software de proporcionar un conjunto apropiado

de funciones para tareas especficas y objetivos del usuario.
o Exactitud. Capacidad del software para proporcionar resultados correctos o
que necesitan un determinado grado de precisin.
o Interoperatividad. Capacidad del software de interaccionar con uno o ms
sistemas especificados.
o Seguridad. Capacidad del software de proteger la informacin y los datos.
o Adherencia a normas. Capacidad del software relacionada con el grado de
conformidad con estndares, convenciones o regulaciones existentes en
leyes o prescripciones similares.
Fiabilidad. Conjunto de atributos que ataen a la capacidad del software para

mantener su nivel de prestacin bajo condiciones establecidas durante un tiempo
establecido. Se descompone en las siguientes subcaractersticas:
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 recuperacin. Capacidad para restablecer el nivel de
rendimiento y de recuperacin 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 Fcil comprensin. La capacidad del software que permite al usuario

comprender si el producto es aceptable y cmo puede ser usado para tareas
particulares y determinadas condiciones de uso.
o Fcil aprendizaje. Capacidad del producto software que permite al usuario
aprender la aplicacin software.
o Operatividad. Capacidad del producto software que permite al usuario
controlar y usar la aplicacin 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 nmero de recursos y tiempo de ejecucin cuando el software
desarrolla sus funciones bajo condiciones establecidas.
Mantenimiento. Capacidad del producto software para ser modificado. Se

descompone en:
o Facilidad de anlisis. 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
ejecucin de una modificacin especfica 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 organizacin.
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 instalacin. Capacidad del producto software para ser
instalado en un entorno especfico.
o Coexistencia. Capacidad del producto software de coexistir con otros
programas independientes en un entorno comn y compartiendo recursos
tambin comunes.
o Facilidad de reemplazo. Capacidad del producto software de ser utilizado
en lugar de otro producto software especfico para el mismo propsito que
ste y en un entorno similar.
206 LA NORMA ISOlIEC 9126
La calidad de uso, de forma grfica:
Calidad
de uso
1 Eficacia 1 Productividad 1 Seguridad 1' Satisfaccin 1

Figura 7.7. Calidad de uso en la norma ISOIIEC 9126.
Eficacia. Capacidad del software para permitir a los usuarios alcanzar objetivos
especficos con precisin y completamente en un contexto especfico de uso.
Productividad. Capacidad del producto software para permitir a los usuarios
emplear recursos apropiados con relacin a la eficacia alcanzada en un contexto
especfico 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 especfico de uso.
Satisfaccin. La capacidad del producto software para satisfacer al usuario en
un contexto especfico de uso.
2.2. Medidas internas y externas
Las caractersticas en las que ISOIIEC 9126 descompone la calidad son

influidas por atributos internos y externos propios de dichas caractersticas. Los
atributos internos son indicadores de los atributos externos. Un atributo interno
puede influir a una o ms caractersticas y una caracterstica puede verse influida
por uno o ms atributos (ver figura 7.8).
Las caractersticas y subcaractersticas son medidas, por tanto, a travs de sus
correspondientes atributos. De nuevo observamos un paralelismo con la propuesta
de Fenton en la que se propona la medida de entidades propias del software a
travs de la cuantificacin de sus atributos, tambin identificados como internos y
externos (ver captulo 2).
La norma ISOIIEC define las mtricas internas como aquellas medidas que se
realizan sobre un producto software no ejecutable, tal como la norma indica "un
producto software intermedio debera ser evaluado usando mtricas internas".
Las mtricas externas son medidas del producto software obtenidas del
comportamiento del sistema en la fase de ejecucin del mismo. Finalmente las
mtricas de la calidad de uso, como tercer gran concepto propuesto por la norma,
mide la extensin en la que un producto alcanza las necesidades expuestas por el
usuario de forma especfica en relacin a los objetivos de efectividad, seguridad,
productividad y satisfaccin.
Subcaracterstica
Caracterstica
Figura 7.8. Atributos y caractersticas segn la norma ISOIIEC 9126.
3. PROCEDIMIENTO DE MEDIDA PROPUESTO
Como colofn de este captulo explicamos el procedimento de medida basado

en la realizacin de un conjuto de pasos o fases destinados a la cuatificacin de un
atributo seleccionado. Este apartado es consecuencia de la recopilacin y estudio
de diferentes fuentes; la norma ISOIIEC 9126, la metodologa MTRICA Versin
208 LA NORMA ISOIIEC 9 126
3. (se estudia en detalle en el captulo 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 informtico en
explotacin. Para obtener datos cuantitativos se proceder a descomponer el
atributo a estudiar en criterios de calidad de ms bajo nivel tal y como hemos
presentado en la descomposicin jerrquica explicada. Con el objetivo de ser lo
ms didctico posible se tomar el atributo "madurez" como ejemplo de propiedad
del software que se desea medir y se explicarn los pasos diseados tanto desde un
punto de vista genrico 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 identificacin del atributo a medir.
Cuantificar el atributo ser el resultado final del proceso. El uso de una
metodologa de desarrollo, en este caso MTRICA Versin 3, ser bsica para el
cumplimiento de este primer paso. La tarea denominada "EVS 3.2: identificacin
de requisitos" y "EVS 3.3: catalogacin de requisitos" se propone sean utilizadas
para el cumplimiento de este punto del procedimiento (ver figura 7.9). La necesaria
identificacin de requisitos exigida por MTRICA Versin 3 se integra, por tanto,
en el proceso de medida diseado. Esta integracin permite al tcnico identificar
fcilmente los atributos de calidad que se deseen cuantificar en la aplicacin por
estar expresamente indicados en los requisitos del sistema y claramente
documentados.
En un segundo paso se ha de disear el proceso de evaluacin. Se divide en tres
apartados:
Seleccin de mtricas de calidad.
Evidentemente estas mtricas estn directamente relacionadas con los requisitos

identificados en el primer paso. Haciendo uso de la descomposicin jerrquica
segn el modelo Goal Question Metrics y basndonos en la norma ISO 9126 es
posible la seleccin de mtricas adecuadas al atributo estudiado. Siguiendo con el
ejemplo propuesto, partiendo del concepto de "calidad de uso" segn la norma
ISOIIEC 9126, nuestra atencin se centra en el atributo de calidad denominado
"seguridad". Con objeto de concretar este atributo de alto nivel utilizamos la
descomposicin jerrquica escogiendo la "fiabilidad como atributo de ms bajo
nivel. Finalmente es el criterio "madurez" el objetivo de nuestro estudio. La
medida del atributo madurez se obtendr segn la ecuacin 6.6 tomando como
medida del tamao del software el nmero de puntos funcin como alternativa al
habitualmente utilizado nmero de lneas de cdigo.
Tasar el nivel de dejhicin.
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 satisfaccin de los
requisitos. Se suele elegir una escala 1-10 con objeto de adecuar la evaluacin a la
medida utilizada en la prctica comn de mtodos de evaluacin habituales.
Valorar la definicin de los criterios.
Se basa en preparar procedimientos que permitan resumir los resultados de la

evaluacin de las diferentes caractersticas. En este punto tambin se han de tener
en cuenta factores propios de la administracin de recursos tales como coste y
esfuerzo requerido. Es necesario estimar el esfuerzo por parte de la organizacin.
El procedimiento de medida, el almacenamiento de los datos o el clculo del
esfuerzo necesario para la realizacin de la medida puede ser ejecutada con los
mecanismos o herramientas que el tcnico considere.
En el segundo punto el procedimiento propuesto hace uso, de nuevo de la

metodologa MTRICA Versin 3, en concreto en su apartado EVS-CAL 1.3.
"Identificacin de las propiedades de la calidad". La informacin aportada es
valiosa al establecer los atributos (propiedades segn la nomenclatura de
MTRICA Versin 3) que, bien complejos, bien simples, permitirn establecer las
correspondientes medidas.
Como tercer paso se establece la evaluacin del atributo. Este proceso se basa
en los anteriores. En l se realizan medidas de los atributos seleccionados segn las
escalas acordadas. El procedimiento propuesto es original al integrar estndares
internacionales como ISO 9126, metodologas de desarrollo como es el caso de
MTRICA Versin 3 y el procedimiento de descomposicin jerrquica
denominado Goal Question Metrics con el objetivo de la medida de la calidad del
software.
La incorporacin de ejemplos en este libro tiene por objeto, no slo la expresin
prctica de la teora presentada en los apartados anteriores, sino la de ser una forma
alternativa de incluir nuevos conocimientos. Enfrentarse a la ejecucin en un
entorno real de conceptos y teoras implica plantearse nuevas incgnitas que deben
resolverse. Muchas dudas surgen en la aplicacin prctica de la teora, aunque sta
haya sido extensamente explicada. Al final de este captulo se ha propuesto un
ejemplo extrado de la realidad.
METRICA Versin .3
Se apoya en
Definicin de requisitos
Seleccin de mtricas
ISO 9126
Selecciona Valoracin del criterio
Mtricas
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

INFORMTICA. EJEMPLO PRCTICO
Como ejercicio prctico del procedimiento de medida propuesto en el apartado

3, a continuacin explicamos en detalle la medida del atributo fiabilidad de cierta
aplicacin informtica que se encuentra en explotacin.
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 prctica en la ejecucin de
distintas herramientas propuestas a lo largo de diferentes captulos de este texto. El
Anlisis del Punto Funcin, el modelo de descomposicin jerrquica en rbol (Goal
Question Metrics), la metodologa MTRICA Versin 3.0, sern tcnicas a
emplear. Este apartado no slo ser una aplicacin inmediata de los
procedimientos, teoras y herramientas propuestas, ser una forma de profundizar
en la teora y conocimientos expuestos a lo largo de otros captulos.
Este primer ejercicio tiene por objetivo la medida de la calidad de una
aplicacin informtica que se encuentra en explotacin, en concreto del atributo
fiabilidad. Consideremos los pasos definidos en la figura 7.9 de forma que los
epgrafes siguientes coincidirn con los pasos a ejecutar para la medida de la
calidad.
4.1. Definicin de requisitos de calidad
La metodologa MTRICA Versin 3.0 considera en su interfaz de calidad o

interfaz CAL un marco comn de referencia para la definicin de planes de
aseguramiento de la calidad. Parece lgico, por tanto, apoyarnos en la propia
metodologa para obtener los requisitos de calidad del producto software a
desarrollar (figura 7.10).
METRICA V 3.0
Se apoyaen ,vscAL, E"I CAL ,

Definicin de requisitos
Figura 7.10 Definicin de requisitos de calidad.

La actividad EVS-CAL~:IDENTIFICACINDE LAS PROPIEDADES DE

CALIDAD DEL SISTEMA, sera la tarea a considerar en este primer punto. La
identificacin de las propiedades de la calidad estaran asociadas al proceso EVS
(Estudio de Viabilidad del Sistema) y, por tanto se realizara en los primeras fases
del desarrollo software. Si consideramos en detalle la tarea EVS-CAL1, MTRICA
Versin 3.0 la descompone en las siguientes actividades:
Determinacin de los Sistemas
EVS-CAL 1.3
1 de Calidad
Tabla 7.2. Tareas asociadas a la actividad EVS-CAL1.
Es fcil 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
identificarn 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 cuantificacin, su
medida. Es muy importante que los resultados de los equipos de trabajo sean
recogidos por escrito en un acta de reunin 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
informtico, este hecho es sumamente importante ya que implica la modificacin
de todo el proceso de creacin del software y afecta a todo el proyecto. La
concrecin de criterios de calidad debe ser una exigencia para el equipo de
desarrollo y deben ser capturados con mximo rigor al inicio del proyecto evitando
posibles modificaciones futuras que se convierten en una seria amenaza a la
planificacin 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 colaboracin y

autoexigencia de quien va a utilizarlo.
4.2 Preparar la evaluacin
El segundo punto a realizar es la preparacin del proceso de evaluacin. Esta

fase se divide a su vez en tres apartados:
o Seleccin de mtricas.
O Tasar.
o Valoracin del criterio.
METRICA V 3.0
Se apoya en
0:. Preparacin evaluacin

Utiliza -
1 Seleccin de mtricas e \
\
Se basa
Tasar en
Selecciona
m Mtricas
Figura 7.11 Procedimiento de medida propuesto, paso segundo.

4.2.1. Seleccin de mtricas
Una vez identificado el factor de calidad se hace necesario la descomposicin

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
composicin del factor considerado. Debemos asociar medidas (mtricas) a cada
uno de estos factores. En este caso consideraremos a modo de ejemplo el criterio
madurez que entendemos medido a travs de la densidad de defectos. La
asociacin de factores y medidas es uno de los grandes retos de la ingeniera del
software y es donde la experiencia sustituye a una slida propuesta terica.
Figura 7.11. El criterio madurez en el modelo de calidad ISOIIEC 9126.
La densidad de defectos se obtiene a travs de la ecuacin:
Nmero de fallos detectados en el programa

Ecuacin 7.1
Tamaodel pro grama
El numerador es una cantidad fcil 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
solicitndole que indicara los fallos detectados en el programa en tiempo de

ejecucin.
La recopilacin de incidencias de la aplicacin estudiada se realiz por parte del
coordinador informtico (usuario avanzado interlocutor del jefe de proyecto). Toda
incidencia detectada se pona en conocimiento del responsable del proyecto quien,
en colaboracin con el coordinador clasificaba la incidencia segn el siguiente
protocolo:
o Incidencia provocada por la necesidad de cambios en el programa inforrntico

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 paralizacin total del sistema.
o Fallo grave. Implica la paralizacin total de uno o varios

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

programas sin necesidad de suspender su ejecucin.
El resultado final de la contabilidad de incidencias se recoge en la tabla 7.3.
Con relacin al denominador es habitual considerar el tamao de una aplicacin

informtica obteniendo el nmero de lneas de cdigo. Ya hemos comentado los
severos problemas que esta medida posee por lo que consideramos el tamao de la
aplicacin en nmeros de puntos funcin.
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 satisfaccin. Con objeto de capturar esta
informacin es necesario dividir en diferentes grados de satisfaccin los resultados
obtenidos [ISO/IEC 91261. En el caso que nos ocupa lo ms trascendente es la
exigencia del coordinador informtico de no aceptar la aplicacin si se detectaba un
error definido como muy grave. Esta consideracin exiga una escala todohada de
forma que cualquier error de estas caractersticas (muy grave) tena como
consecuencia la no aceptacin del producto informtico. Con objeto de realizar un
estudio ms detallado de las medidas obtenidas se fij adems otra posible escala
considerando los niveles de satisfaccin como muy satisfactorio, satisfactorio e

insatisfactorio, segn la siguiente figura:
.. . . . . . . . . . . . . . . . . . .. .. .. .
. . . . . . . . . . . . .
4 . .. . .. . .. . .. . ... ... ....................
. . . . . . . . . . . . . . . . . . . .. .. .. .
. . . .. .. .. .. .. .. .. .. .. . . . .
....... . . . . . . . .....
. . ..~atiSfactorio.. . .
. ... ... ... ... ... ... ... ... ... ... ... ... ..
. . . . . . . . . . . . . . . . . . .. .. .. ..
Muy . . . . . . . . . . . . .
Insatisfactorio . ... ... ... ... ... ... .. . .. . .. . .. . .. . .. . ..
. . . . . .. .. .. .. .. .. .. .. .. .. . Insatisfactorio
. .. .. .. .. .. .. .. .. .. .. .. .. .
. . . . . . . . . . . . . . . . . . . .. .. .. .
. . . . .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . .. .. .. .. .. .. .
. . . . . . . . . .
b
0,5 1,o
Densidad de defectos
Figura 7.12. Nivel de satisfaccin y densidad de defectos
El resultado de la cuantificacin del atributo fiabilidad es la clasificacin de la

entidad programa informtico en una escala de tipo nominal. Estamos etiquetando,
adjetivando el programa en funcin a los errores detectados por unidad de tamao
del cdigo. El programa ser aceptado o no en funcin del nivel de satisfaccin 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 cuantificacin de un atributo en sucesivos proyectos. Por
otro lado uno de los evidentes problemas de esta subjetividad en la cuantificacin
de atributos es la inexistencia de datos universales que permitan cotejar
aplicaciones de distinta naturaleza tcnica.
4.2.3. Valoracin del criterio
La necesaria infraestructura tcnica y los recursos humanos imprescindibles

para la ejecucin de un programa de medida es un factor que muchas veces se
considera de menor importancia y que, sin embargo, supone el aspecto ms crtico
del trabajo a realizar. El apoyo de la direccin es bsico y se manifiesta en la
designacin de recursos humanos a las diferentes tareas a realizar. La
concienciacin del personal, su formacin y la dedicacin a la medida del software
debe estar apoyada por la direccin de forma indiscutible.
Este apartado est dirigido a la estimacin de los recursos humanos y tcnicos

necesarios para la realizacin de la medida. En el caso que nos ocupa el nmero de
tcnicos informticos, de usuarios finales y su dedicacin se expresan en la tabla
7.4.
Tabla 7.4. Estimacin del personal y dedicacin.
De nuevo nos encontramos con la necesaria experiencia del responsable del

proyecto para el clculo de los recursos necesarios. Como podemos observar en la
tabla 7.4, se incluye de forma expresa la participacin del coordinador informtico
con dedicacin parcial y una estimacin de 16 horas en total.
Una vez identificados los integrantes del equipo de trabajo es imprescindible
establecer un protocolo de actuacin para la recopilacin 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 bsicas:
1. El coordinador informtico aporta informacin detallada sobre las incidencias

recopiladas durante un perodo de tiempo determinado hacindoselas llegar al
responsable del proyecto. Esta informacin debe ser trasmitida por escrito y
haciendo uso de una plantilla estndar en la que se recoja la informacin necesaria.
2. El programador informtico (sistemas-desarrollo) realiza la contabilidad de
los puntos funcin de los programas. Esta tarea es independiente del punto (1).
3. El operador traslada la informacin a tablas y estadillos para el futuro anlisis
de los datos. La informacin enviada por el coordinador informtico y por parte de
los programadores se utiliza para el clculo de la densidad de defectos. Es un
proceso de clculo simple.
4. Semanalmente el responsable del proyecto realiza una reunin de control con
los agentes implicados y dirige esfuerzos segn los trabajos desarrollados y la
posible existencia de desviaciones de los tiempos estimados.
La obtencin de datos cuantitativos culminar con el anlisis de los mismos y la

propuesta de actuaciones segn 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 decisin es tan crtica como la aceptacin o no de
una aplicacin informtica ya desarrollada y en fase de explotacin.
4.2.4. Obtencin de medidas
El resultado final del proceso establecido es la obtencin de los datos

cuantitativos. Segn establecimos en el punto 4.2.1, la ecuacin 7.1 y la tabla 7.3
nos proporcionaran parte de la informacin necesaria para la cuantificacin de la
fiabilidad. El denominador de la ecuacin se obtendra ejecutando el Anlisis del
Punto Funcin.
El resultado de la medida del tamao de la aplicacin informtica es:
Tamao aplicacin = 90,984 puntos funcin ajustados
Por lo que la densidad de defectos de la aplicacin es:
1190,984 = 0,011
10190,984 = 0,110
Con las siguientes unidades:
0,011 incidencias graves por puntos funcin

0,110 incidencias leves por puntos funcin
En ambos casos, considerando los dos tipos de incidencias, la aplicacin se

considera aceptable para el usuario. La aplicacin, por tanto, cumple los requisitos
exigidos.
Captulo 8
MTRICAS DEL SOFTWARE

En cualquier sector econmico, el disponer de
informacin cuantificada resulta vital para mejorar en el mundo
competitivo de los negocios. En la industria del software, la
utilizacin de las mtricas comienza a valorarse debido a los
excelentes resultados obtenidos con su implantacin'
La bsqueda de la calidad como elemento competitivo en la industria del

software implica saber en qu situacin se est y planificar cmo 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 caractersticas de la calidad del
software, no siempre de acuerdo con la norma ISO 9126. Actualmente, el
desarrollo de las mtricas se encuentra en un momento de cierta confusin,
necesitando muchas de ellas de validacin tanto terica como emprica. En muchos
casos la medida obtenida no se sabe a qu caracterstica de calidad afecta ni de qu
forma. En este captulo se presentan, aunque no de forma exhaustiva, las mtricas
ms utilizadas.
1. MTRICAS E INDICADORES DE LA PRODUCTIVIDAD
A pesar de que el software no posee entidad material, la cuantifcacin de su

tamao 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 mtrica? Boletn Interno Tecnolgico de Indra. Madrid.
222 MTRICAS DEL SOFTWARE
coste o productividad. Es debido a su relacin 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 nmero de lneas de cdigo generado por
persona y mes, se presentan medidas alternativas y sus ventajas.
1.1. Medida del tamao
La medida tradicional de este atributo (tamao de una aplicacin) se ha

fundamentado en el nmero de lneas de cdigo. An es habitual utilizar como
medida de la productividad generada por un tcnico el nmero de lneas de cdigo
por nmero de unidades temporales consideradas (das, horas, meses).
Las ecuaciones ms habituales en la medida de la productividad2 [Kan, 20031
son:
Tamao
Productividad = Ecuacin 8.1
Esfuerzo
Lneas de cdigo
Productividad = Ecuacin 8.2
Personas - mes
Por otro lado, las medidas ms habituales utilizadas para cuantificar el tamao
de una aplicacin informtica son:
Lneas de cdigo
El nmero de lneas de texto que componen el cdigo fuente de un programa ha

sido la medida ms utilizada en la cuantificacin del tamao del software,
entendido ste como un atributo interno de un producto. Es una medida fcil de
obtener y manipular, adems, ha sido considerada como factor clave de otros
atributos como ocurre en el caso de la productividad. Las lneas de cdigo,
expresadas como LOC (del ingls 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 lneas en blanco en la

contabilidad de las lneas de cdigo de un programa?
- Es equivalente el nmero de lneas de cdigo contabilizado en un lenguaje
de programacin u otro?
- Se han de considerar todas las instrucciones, o pueden obviarse
definiciones de constantes y variables?
- Al igual que se hace con el cdigo fuente Puede utilizarse esta medida
para otros documentos propios del desarrollo software tales como
requisitos o diseo del programa?
- Influye la tecnologa a utilizar en la contabilidad de las lneas de cdigo?
- Hay instrucciones que pueden necesitar ms de una lnea de cdigo fuente,
o por el contrario pueden existir diferentes instrucciones en una lnea, no
sera necesario considerar el impacto de este hecho?
Hacer uso de esta medida requiere la definicin de lo que entendemos por lnea
de cdigo. De esta forma superaremos algunas ambigedades respondiendo a
varias preguntas anteriores. Una Inea de cdigo se define como: Cualquier lnea
de texto del programa excluyendo comentarios y lneas en blanco.
En muchos casos es interesante considerar tambin el nmero de lneas de
comentarios que posee un programa ya que, aunque no son comandos necesarios
para la ejecucin del mismo, s son una fuente de informacin muy til que pueden
influir en las posteriores modificaciones o en el mantenimiento de dicho programa.
As las lneas de cdigo sin considerar los comentarios se especificarn como
NLOC, y aquellas que consideren los comentarios se definen como CLOC. El
nmero de lneas totales sera:
LOC = CLOC + NLOC Ecuacin 8.3
Una medida de la densidad de comentarios sera:
d=-CLOC Ecuacin 8.4

LOC
Algunos investigadores han propuesto el carcter como medida alternativa a las

lneas de cdigo [Fenton, 19921. Sera una medida simple de coleccionar y la
conversin del nmero de caracteres en lneas de cdigo sera extremadamente
fcil.
node cavcteres
LOC = Ecuacin 8.5
a
Donde a es un nmero promedio de caracteres por lnea de texto.
En muchas ocasiones podemos encontrar el acrnimo KLOC, indicando miles

de lneas de cdigo. Es una magnitud muy utilizada en grandes aplicaciones, siendo
un mltiplo de LOC.
Medir el tamao del cdigo fuente haciendo uso de las lneas de cdigo presenta
algunos inconvenientes y dudas a las que nos hemos referido anteriormente. Estos
problemas se ven agravados cuando deseamos medir el tamao de otros
documentos propios de la fase de diseo o captura de los requisitos. Es fcil
comprender el grave obstculo que encierra cuantificar esta documentacin si se
considera que en numerosas ocasiones se componen, no slo de lneas de texto, si
no tambin de grficos, diagramas de flujo, ecuaciones, smbolos y dems
anotaciones propias de estas fases del desarrollo software. En muchas ocasiones se
utiliza el nmero de pginas de documentacin pero no es una medida aceptable.
En resumen, las lneas de cdigo 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 lneas de cdigo es la contabilidad de las

muestras, token, existentes en el cdigo 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 obtendra un valor ms adecuado al
lenguaje de programacin utilizado proporcionndonos una idea ms precisa de la
informacin contenida en el cdigo fuente. La Ciencia del Software de Halstead
hace uso de estas seales o tokens, que permiten conocer el tamao de un
programa, el vocabulario del mismo o su volumen. Esta ltima medida nos indica
el espacio de memoria mnimo requerido para almacenar el programa. La medida
propuesta por Halstead ha sido considerada como una mezcla de tamao y esfuerzo
Funcionalidad
En algunos casos, propios de grandes aplicaciones en las que existen miles de

programas con cientos de lneas de cdigo cada uno de ellos, se ha propuesto como
unidad de medida del tamao el mdulo. Sin embargo, esta medida es de difcil
aplicacin en un marco de medida estricto pues no existe una clara definicin de
esta magnitud, es ms, su uso implicara cierta confusin entre la entidad medida,
programa o conjunto de programas que constituyen una aplicacin, y la medida en
s misma, mdulo, entendido como programa, rutina o subrutina que forma parte de
la aplicacin. Como alternativa ms 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 coleccin de instrucciones que
realizan una tarea determinada. El programador considera el cdigo a travs de las
funciones que ha de realizar ms que como un conjunto de lneas de texto o
comentarios, por lo que su cuantificacin sera enormemente til al hacer coincidir
un valor numrico con la apreciacin subjetiva del profesional.
Albrecht a finales de la dcada de los setenta realiz un muy serio acercamiento
a la medida de la funcionalidad gracias a su concepto de Punto Funcin. Es
especialmente destacable que la medida propuesta por Albretch puede ser aplicada
tanto al cdigo, como a las especificaciones o al diseo, superando uno de los
graves problemas suscitado por el uso de las lneas de cdigo. Es habitual obtener
el nmero de Puntos Funcin propios de cierto programa, transformarlos en lnea
de cdigo segn el lenguaje de programacin utilizado y posteriormente hacer uso
de ecuaciones en las que interviene como factor el valor LOC.
Capers Jones, uno de los ms influyentes investigadores en el mbito de la
ingeniera del software, ha propuesto el concepto de nivel de lenguaje
relacionndolo con el concepto de Punto Funcin. Un lenguaje de programacin
poseer un nivel u otro basndose en el menor nmero de estamentos requeridos
para codificar un Punto Funcin. Cobol, por ejemplo, es un lenguaje de nivel 3 y
requiere alrededor de 105 estamentos por Punto Funcin. Capers Jones relaciona el
concepto de nivel del lenguaje con el de productividad y, por tanto, con el tamao
del cdigo.
226 MT~UCASDEL SOFTWARE
1 1 1 por Punto Funcin 1

Basic 3.00 107
Clipper 17.00 19
Fortran 90 4.00 80
Natural 6.00 53
Lenguaje Mquina 0.50 640
Tabla 8.1. Niveles de lenguajes segn Caper Jones.
Reusabilidad
Es muy habitual que los programadores hagan uso ms de una vez de programas
o parte de stos, modificndolos o simplemente reutilizndolos sin llegar a
modificarlos. Esta prctica ha de influir en la medida del tamao del cdigo, es
considerado por algunos modelos.
La reusabilidad posee dos acepciones que convienen diferenciar. Por un lado
encontramos el cdigo desarrollado de forma externa al programa que se est
implementando y que Fenton defini como reuso pblico. Es evidente que para la
medida del programa en su conjunto se podra 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 definira el reuso privado entendido como mdulos reutilizados dentro del
mismo producto. Es en este ltimo caso donde se puede aplicar ciertas tcnicas y
ecuaciones que permitan una mejor aproximacin al tamao real de nuestro
programa ya que no puede medirse de forma similar un cdigo desarrollado desde
cero que otro adaptado o simplemente utilizado ms de una vez.
El modelo de Boehm, COCOMO tiene en cuenta el hecho de la reusabilidad,
segn la ecuacin:
a
S , = S , +-S, Ecuacin 8.6
1 O0
donde S, es el cdigo reutilizado, S, el cdigo nuevo y a es un factor de ajuste que

se obtiene en funcin del grado de modificacin sufrido por el diseo (DM) y el
cdigo (CM) y del correspondiente esfuerzo de integracin (IM) segn la ecuacin:
a = 0.4(DM) + 0.3(CM) + 0.3 ( IM) Ecuacin 8.7
el mximo valor de a es de 100, en este caso se asumira que adaptar el cdigo es

similar en cuanto al esherzo a reescribirlo.
Thebaut presenta una modificacin a esta ecuacin aplicando un exponencial a
uno de los factores segn la ecuacin:
S, = S, + S ,k Ecuacin 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

valoracin 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 nmero 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 aadimos un control de
la calidad del producto realizado, obtenemos una medida fiable, sencilla y
enormemente til de la productividad industrial. Esta nocin de la productividad y
su mediada se ha intentado trasladar al desarrollo de programas informticos. Si
conocemos el monto total del producto obtenido, en este caso el tamao del
programa, y el esfuerzo necesario para su desarrollo, generalmente expresados en
personas-mes, sera simple medir la productividad del equipo de desarrollo segn
la frmula:
Tamao de salida
Ecuacin 8.9
Personas - mes
Haciendo la sustitucin del numerador por cualquiera de las medidas del
tamao del software propuestas en el apartado anterior se obtendra 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. Segn 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 slo cuando una tarea puede
repartirse entre varios empleados sin que sea necesaria una comunicacin entre
ellos. El coste vara, de hecho, como el producto del nmero de personas y el
nmero de meses. El avance, no".
En las tareas que pueden repartirse y que adems requieren una comunicacin
entre subreas, debe aadirse al total del trabajo a realizar el esfuerzo de
comunicacin.
La frontera de comunicacin que se ha aadido, se compone de dos partes: la
formacin y la intercomunicacin.
La formacin de los trabajadores incluye la tecnologa, los objetivos del trabajo,
la estrategia general y el plan de trabajo. Este esfuerzo varia linealmente con el
nmero de trabajadores.
El esfuerzo de intercomunicacin incluye la coordinacin de tareas, las
reuniones de resolucin de problemas, etc..
Puntos Funcin
La medida ms utilizada en el caso del tamao del software ha sido el nmero

de lneas de cdigo, por lo que la productividad ha venido indicada en la mayora
de los casos en trminos de lneas de cdigo por persona y mes. Las ventajas e
inconveniente que presentaba la media del tamao en trminos 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 segn el lenguaje de programacin utilizado o
la falta de representacin de la productividad del equipo de desarrollo al ser
fcilmente alterable aadiendo lneas de cdigo innecesarias o de poca utilidad. La
alternativa es el uso de los Punto Funcin, segn la ecuacin:
Nmero de Puntos Funcin

Ecuacin 8.10
personas - mes
El uso de esta ecuacin 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 tamao del software ms cercana a
la visin 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 estadsticos que
determinen de forma muy aproximada el nmero de unidades defectuosas resultado
de cierto proceso y realizado por cierto equipo. El control estadstico se basa en la
obtencin de un producto estandarizado, con idnticas caractersticas. Este hecho
no puede darse en el software por lo que el control de la calidad debe basarse en
medidas propias de esta actividad.
nmero de errores
Calidad = Ecuacin 8.1 1
IUOC
Documentacin
Es habitual recoger datos sobre la documentacin aportada por el equipo de

trabajo. Se ha de considerar la informacin suministrada con el programa un factor
ms para evaluar la productividad. Suele expresarse segn la ecuacin:
nmero de paginas
Ecuacin 8.12
KLOC
Es muy difcil cuantificar la documentacin, generalmente compuesta por texto,

grficos o esquemas, por lo que la ecuacin 8.12 es muy criticada.
Tambin es interesante considerar el cdigo reutilizado y obtener medidas que
lo consideren como las estudiadas en el punto anterior.
Nivel de lenguaje
Una aproximacin algo ms 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
numricos a esta relacin.
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 expresin que envuelva el tamao de la
salida y el nmero de personas involucrada en dicha tarea. Debe considerarse la
calidad del producto resultante. Se han de realizar una batera de medidas en las
que se han de incluir datos relacionados con el tamao del programa resultante,
personal implicado en el proceso, coste del mismo y la calidad resultante.
A continuacin 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 relacin 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 produccin de software libre de defectos, de tal forma que su utilizacin diaria
est exenta de errores. Esta concepcin tiene una clara incidencia con la calidad y
ms 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 realizacin de pruebas ms o menos complejas y
en la establecimiento de revisiones tcnicas. La realizacin 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 comprobacin han sido tradicionalmente aquellas en las que
intervienen el nmero de errores detectados durante el proceso de prueba, aunque
tambin se han considerado el nmero de cambios realizados en el diseo de un
programa o en el cdigo del mismo. El proceso habitual es realizar una batera de
pruebas y contabilizar ciertas medidas, las ms utilizadas son las expuestas a
continuacin.
Densidad de defectos
nmero de defectos descubiertos en el programa

Ecuacin 8.13
tamao del programa
La medida 8.13 es la ms habitual y se denomina densidad de defectos. Como

se observa es una medida indirecta en la que interviene el tamao del programa,
generalmente indicado en miles de lneas de cdigo, KLOC, aunque tambin se
utilizan los puntos funcin. 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 nmero de defectos
descubiertos durante cierta fase de pruebas u operacin del software, y por otro de
un atributo interno de un producto como es el caso del tamao del programa.
Esta medida es muy utilizada incluso en grandes empresas, y an en nuestros
das se considera un dato estratgico y de acceso restringido.
Tasas
Muy relacionadas con la definicin 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 ms utilizadas son:
Tasa de propagacin de defectos
nmero de defectos ocasionados al corregir defecto

Ecuacin 8.14
nmero de defectos corregidos
Eficiencia en la eliminacin de defectos
nmero de defectos corregidos durante una fase de desarrollo

* 100
numero de defectos detectados durante una fase de desarrollo
Ecuacin 8.15
Tasa de efectividad de las pruebas
nmero de objetos probados almenos una vez

* 100 Ecuacin 8.16
nmero de objetos totales
Con las ecuaciones 8.14J.15, 8.16 se pueden realizar una poltica de pruebas y
captura de medidas muy valiosas para el desarrollo de aplicaciones y su control de
calidad.
Las revisiones tcnicas basan su eficacia en la realizacin de verificaciones
manuales del diseo o cdigo. La principal preocupacin 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 tcnicos 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 matemticamente.
R(t)= 1 - F ( t ) Ecuacin 8.17
Si consideramos un valor del tiempo discreto la ecuacin seria
d,
R(n)= 1 - - Ecuacin 8.18
n
donde d,, es el nmero de fallos encontrados en n ejecuciones.
Si f(t) es la funcin densidad de probabilidad, es decir:
f (t) = dF(t) l dt Ecuacin 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 Ecuacin 8.20

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

O
R(t) = e,
Ih(x)h
Ecuacin 8.23
Se define el tiempo medido entre fallos MTTF, acrnimo del ingls Mean Time
to Faillure como:
1
MTTF = - Cfl ti
i=1
Ecuacin 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 travs de la ecuacin.
MTTF = ) ~ ( tdt) Ecuacin 8.25

O
4. COMPLEJIDAD DEL SOFTWARE
Unida intrnsecamente a la medida del tamao del software se encuentra la

medida de la complejidad. Como se ha podido apreciar en las ecuaciones
anteriores, conocer el tamao 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 cuantificacin de este
atributo ha supuesto numerosos esfuerzos, dos de los ms representativos son
introducidos a continuacin.
4.1. La Ciencia del Software de Halstead
La Ciencia del Software de Halstead es una de las ms estudiadas, populares y

controvertidas teoras sobre el software y su cuantificacin. Halstead defini un
conjunto de mtricas basadas en los elementos sintcticos existentes en el
programa, en el lxico del cdigo fuente. Su base terica parte de la psicologa,
concretamente de la psicologa cognitiva.
La ciencia de Halstead de basa en un conjunto de medidas definidas as:
nl = nmero de operadores distintos que aparecen en un programa.

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

programa segn la ecuacin:
N=N,+N2 Ecuacin 8.26
Adems define el "vocabulario" del programa como:
n = n l +n2 Ecuacin 8.2 7
Permite estimar el valor de N segn la ecuacin:
N= nllog2nl+n210g2n2 Ecuacin 8.28
El valor de N puede convertirse en nmero de lneas de cdigo haciendo uso de

tablas obtenidas por mtodos estadsticos.
Segn esta teora el esfuerzo requerido para generar el programa se definira

como el nmero de- operaciones mentales necesarias pare escribir un programa de
longitud N. Este valor vendra dado por la ecuacin:
E= (nl N N2 logzn)/(2 n2) Ecuacin 8.29
Define el concepto Volumen del Programa como el nmero mnimo de bits

necesario para codificarlo:
V = N log2(nl+ N2) Ecuacin 8.30
Este valor cambia segn el lenguaje utilizado. Para cada algoritmo particular ha
de existir un volumen mnimo. Halstead define la razn de volumen "L" como la
razn entre el volumen de la forma ms compacta de un programa y el volumen
del programa real. L debe ser siempre menor que uno.
L = (2 n2 )f(n~N2) Ecuacin 8.31
Halstead teorizo que cada lenguaje poda ser clasificado por un nivel de
lenguaje, "1". Este valor parece estar relacionado con el nivel de abstraccin en
especificacin de procedimientos. A mayor nivel de lenguaje mayor nivel de
abstraccin.
Las crticas al modelo de Halstead se fundamentan en considerar errneas las
hiptesis de la psicologa cognitiva, base terica del mismo. Por otro lado se han
determinado errores estadsticos cometidos en la validacin de pruebas de medidas
obtenidas haciendo uso de las ecuaciones de Halstead [Fenton 19911. Otro hecho
fundamental es que las medidas propuestas en esta teora obvian el diseo
centrando su informacin en el cdigo.
4.2. La medida de la complejidad de McCabe
Esta medida se basa en la representacin grfica de un programa segn el flujo

de control del mismo y nos informa de la complejidad lgica del diseo propuesto
debido a la estructura de decisiones del mdulo considerado. Se denomina
complejidad ciclomtica. Y la ecuacin que nos proporciona su valor es:
V(G)=e-n+2 Ecuacin 8.32
Donde e es el nmero de flechas de conexin que implica una transferencia de

control de un nodo a otro y n el nmero de nodos, entendidos stos como tareas de
proceso.
236 METRICAS DEL SOFTWARE
Para conocer esta medida es necesario, por tanto, obtener la representacin del
programa haciendo uso del grafo de flujo. Los elementos bsico que conforman
dicho diagrama se consideran a continuacin:
Nodo. Representan sentencias de cdigo.
Nodo Predicado. En sentencias en las que aparecen

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

XORY.
Uno de los usos ms habituales del nmero ciclomtico est asociado con la
ejecucin de pruebas. El nmero ciclomtico nos informa del nmero de caminos
independientes del programa. Conocido este valor podemos saber el nmero de

pruebas mximo que asegure el que todas las sentencias se ejecutan al menos una
vez.
La complejidad del producto software fue limitado por McCabe, asocindolo a
un valor V(G) =lo, de forma que mdulos con una complejidad ciclomatica
superior a este valor eran inadecuados, propensos a errores y de difcil
mantenimiento.
4.3. La mtrica de Henry y Kafura
Henry y ~ a f u r midieron
a~ la complejidad basndose en el flujo de informacin
entre mdulos.
Se define un mdulo como "una secuencia identificable de instrucciones
contiguas", que no tienen que ser necesariamente de cdigo fuente (texto de
especificacin, de diseo, etc.). Se distinguen los atributos intra-mdzdos (atributos
de un mdulo vistos como independiente de los otros mdulos) y los atributos
inter-mdulos (atributos del sistema visto como un conjunto de mdulos ms o
menos dependientes unos de otros.
El anlisis del diseo puede hacerse como si se tratar de grafos, tales como
grafo de llamadas entre mdulos, grafos de control, grafos de dependencia de
datos, etc. En los grafos se pueden hacer diversas medidas:
Medidas de la morfologa del grafo: nmero de arcos, de nodos, profundidad,

anchura, etc.
Medidas de nodos: nmero de arco entrantes, de arcos salientes, grado de

acoplamiento (se mide por los atributos del flujo de informacin entre mdulos).
Cohesin de un mdulo se define como "atributo de mdulos individuales, que

describe su fuerza funcional, es decir, la importancia segn la cual los
componentes del mdulo son necesarios para ejecutar la misma tarea".
en ton^ propone, para la medida de la cohesin intra-mdulo el cociente entre

el nmero de mdulos con cohesin funcional y el nmero total de mdulos. Como
la cohesin no est habitualmente modelada por un grafo, hay que definir una
medida ordinal, distinguindose 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.
Cohesin abstracta: el mdulo es un tipo abstracto de datos.

Cohesin funcional: el mdulo slo ejecuta una funcin bien definida.
Cohesin secuencial: el mdulo ejecuta varias funciones que se realizan en
el orden descrito en la especificacin.
Cohesin comunicacional: el mdulo ejecuta varias funciones que tratan el
mismo conjunto de datos. El cul no est organizado como una estructura o
un tipo nico.
Cohesin procedural: el mdulo ejecuta varias funciones que slo estn
relacionados con un procedimiento general.
Cohesin temporal: el mdulo ejecuta varia funciones que slo estn
relacionadas por el hecho de que deben tener lugar en la misma zona
temporal.
Cohesin lgica: el mdulo ejecuta varias funciones que slo tienen una
relacin lgica.
Cohesin de coincidencia: el mdulo ejecuta varias funciones que no estn
relacionadas.
~ o o c defini
h~ la cohesin como una "medida del grado de conectividad entre
los elementos de un mdulo 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
diseo orientado a objetos".
La presentacin hecha por Henry y Kafura de su mtrica es la siguiente:
Flujo global de informacin
Hay un flujo global de informacin de un mdulo A hacia un mdulo B a

travs de una estructura global de datos D, si A deposita informacin en D y B
busca informacin en B.
Flujo local de informacin
Hay flujo local de informacin de un mdulo A hacia un mdulo B, si se

tienen una o ms 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 oriente et applications. Addison- Wesley, 1991

F1 X O R Y. Flujo local directo de informacin
Hay un flujo local directo de informacin de un mdulo A hacia un mdulo B,

si A llama a B.
Flujo local indirecto de informacin
Hay un flujo local indirecto de informacin de un mdulo A hacia un mdulo

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 nmero de flujos locales hacia el

procedimiento A, ms el nmero de estructuras de datos en las que el
procedimiento A busca informacin.
El fan-out de un procedimiento A es el nmero de flujos locales que vienen del

procedimiento A, ms el nmero de estructuras de datos que son actualizadas por el
procedimiento A.
La frmula que define el valor de la complejidad de un procedimiento es:
comp.- proc. = (fan-in x fan-out12 Ecuacin 8.33
El hecho de elevar al cuadrado viene dado por la suposicin de Henry y

Kafura de que la complejidad es una funcin ms que lineal de las conexiones del
procedimiento con su entorno.
El flujo total de informacin ser el sumatorio de las complejidades de todos
los procedimientos, es decir:
Flujo = C (fan-in x fan-out12 Ecuacin 8.34

Los procesos de negocios se abordan generalmente mediante diseo

multidimensionales que capturan las mediciones (hechos o medidas) del negocio y
los parmetros (dimensiones) que identifican las mediciones. Los modelos de datos
multidimensionales suelen representarse mediante esquemas en estrella, con una
tabla central (contiene las medidas de inters, los hechos) y varias tablas de
dimensin (una por cada dimensin conteniendo la informacin acerca de dichas
dimensiones).
El objetivo de las mtricas para modelos de datos es medir la complejidad del
esquema de estrella como un ndice de la calidad del sistema. Estas mtricas se
distribuyen en tres niveles: mtricas a nivel de tabla, mtricas a nivel de estrella, y
mtricas a nivel de esquema. Estas mtricas han sido definidas por calero 6 y otros,
que tambin han realizado su validacin formal, aunque es necesario proceder a su
validacin emprica a fin de refinarlas y depurarlas.
5.1. Mtricas a nivel de tabla
Son principalmente dos:
NA(T) Nmero de atributos de una tabla.

NFK(T) Nmero de claves ajenas de una tabla.
5.2. Mtricas a nivel de estrella
Las mtricas propuestas son:
NDT(S) Nmero de tablas dimensionales de una estrella.

NT(S) Nmero de tablas de la estrella.
NADT(S) Nmero de atributos de las tablas dimensionales de una estrella.
NAFT(S) Nmero 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) Nmero de atributos de la estrella.
NFK(S) Nmero 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. Mtricas a nivel de esquema
En el ltimo nivel se encuentran las siguientes mtricas:
NFT(Sc) Nmero de tablas de hechos del esquema.

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

NFK(Sc) Nmero 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
diseadores del sistema, por lo que deben elegirse aquellas dimensiones de calidad,
que proporciona la ISO 9126, que resulten ms significativas.
Una metodologa para medicin de la calidad de los datos, basada en las ideas
de 0man7 et al., es la siguiente:
Fase 1: Identificacin de los objetivos y de las medidas. Fase de anlisis que a

partir de los requisitos de calidad de los usuarios se obtienen datos para las
siguientes fases
Determinar el objetivo de la medicin.
1.2 Determinar los parmetros 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 valoracin de los datos.
1.3.4 Identificar las fuentes de los datos.
1.4 Definicin de criterios de calidad.
Fase 2: Creacin de una estructura de calidad. En esta fase de diseo se dota al

almacn de datos de una estructura para almacenar los valores de las medidas.
Fase 3: Medicin de los atributos de calidad. Se procede a la medicin 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: Anlisis y Evaluacin 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,
desechndose los invlidos.
Actualmente existe un proyecto denominado CALDEA, financiado por la
Subdireccin General de Proyectos de Investigacin del Ministerio de Ciencia y
Tecnologa, 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 caracterstica de la calidad de un interfaz de usuario es la

facilidad de uso del mismo, por lo cual se han desarrollado diversos mtodos y
medidas de esta caracterstica o atributo.
6.1. Clasificacin de los mtodos
Siguiendo a wixon8 y Wilson distinguimos cinco criterios de clasificacin:
Mtodos formativos vs. Mtodos sumativos. Los primeros se orientan a la

deteccin de problemas y generacin de ideas de facilidad de uso (usabilidad), al
principio de las fases de anlisis, diseo y desarrollo. Los segundos sirven para
evaluar sistemas terminados.
Mtodos de descubrimiento vs. Mtodos de decisin. Los primeros son
cualitativos y se dirigen al usuario para determinar cmo piensa, cmo trabaja y
con qu problemas encuentra. Los segundos, cuantitativos, sirven para elegir entre
diversos diseos alternativas.
Mtodos formales vs. Mtodos informales. Muchos de los mtodos descritos
formalmente son, en la prctica, adaptados por los evaluadores, de manera
informal, segn sus objetivos.
Mtodos que involucran al usuario vs. Mtodos que no involucran al usuario.
Dependen del que el usuario participe o no en el anlisis, diseo y evaluacin del
proyecto informtica.
Mtodos completos vs. Mtodos componentes. Los primeros se extienden por
todos los pasos para completar un diseo centrado en la facilidad de uso. Los
componente, slo cubren parte de un proceso completo de usabilidad y son la
mayora de los mtodos.
- - - --
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 mtodos de evaluacin
Se distinguir entre mtodos en los que los usuarios participan en un papel

principal (user testing), usando las tcnicas 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 orgenes

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 mnimo de 10 cuestionarios.
MUMMS (Measuring the Usability of Multy-Media Systems). De los mismos

autores y con los mismos objetivos, sirve para medir la satisfaccin de los usuarios
de aplicaciones multimedias.
WAMMI (Website Anlisis and Measurement Multimedia Inventory). De los

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

forma cruzada, diferentes productos.
Usabilitv Inspection
Estas mtricas, cuantitativas, obtienen informacin sobre la usabilidad que

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

- Nmero de tareas que pueden completarse en un tiempo dado.
- Relacin entre las interacciones con xito y los errores.
- Tiempo usado para reparar los errores.
- Nmero de errores de usuario.
HFRG. The humanfactors research group.Universiy 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.

Nmeros de acciones errneas inmediatamente posteriores.
Nmero de comandos y otras caractersticas utilizados por el usuario.
Nmero de comandos y otras caractersticas no utilizados nunca.
Nmero de caractersticas que el usuario recuerda despus 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.
Nmero de ocasiones en que el usuario presenta fmstracin.
Proporcin de usuarios que prefieren el sistema a otro de la competencia.
Proporcin de usuarios que emplean estrategias eficiente.
Tiempo muerto en el que el usuario no interacta con el sistema.
Nmero de veces en que el usuario se desva de la tarea.
Mtodo de Constantine y ~ o c k w o o d ' ~
Estas mtricas pretenden medir la complejidad (complexityl y la adecuaciQn

(appropriateness) del diseo. Sin entrar en detalles, se presenta una relacin de las
mtricas y de las caractersticas 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 caracterstica

demandada al software. Desgraciadamente existen pocas medidas y la evaluacin
de la seguridad de los sistemas informticos se hace mediante auditorias de
seguridad, basadas en cuestionarios, en general, cualitativos.
Como principio general se emplea el mtodo de descomposicin en rbol de la
caracterstica Seguridad en sus subcaractersticas. Un ejemplo poda 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. Descomposicin en rbol de las caractersticas 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 informticos 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 Amrica.
Orientado inicialmente a la determinacin de los niveles de confidencialidad de la
informacin, di como fruto el TSEC (Trusted Computer System Evaluation
7
Criteria) o "Libro Naranja ', cuya evolucin, incluyendo tambin la evaluacin de
la seguridad de las redes informticas, fue el TNI (Trusted Network Interpretation)
o "Libro Rojo".
Como alternativa a los criterios americanos, algunos pases europeos, en 1990,

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

presenta las caractersticas bsicas de la ingeniera de seguridad de un sistema
informtico. No describe proceso concreto. Solamente propone las mejores
prcticas para obtener una buena seguridad del sistema. La arquitectura bsica
consta de tres categoras:
- Organizacin.
- Proyecto.
- Ingeniera 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 mtricas en dos grandes

grupos:
Mtricas de proceso. Medidas que pueden ofrecer evidencias de la madurez

de los procesos propuestos en el modelo.
Mtricas de seguridad. Mtricas para evaluar los atributos de seguridad
(confidencialidad, integridad, etc.) en un momento dado.
248 METRICAS DEL SOFTWARE
7.3. Mtricas de eficacia de los algoritmos criptogrficos
Para determinar estas mtricas es necesario, en primer lugar, identificar los

atributos comunes a los algoritmos criptogrficos. Los criterios comunes
propuestos son:
- Tipo de algoritmo (simtrico o asimtrico).

- Tipo de funcin (autentificacin, 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, anlisis
diferencial, etc.).
Algunas de las mtricas son:
Longitud de la clave
Cuanto mayor es, ms resistente es el algoritmo frente a un ataque de fuerza

bruta. Se expresa en nmero de bits de longitud de la clave. Cada bit que se aade a
la clave se duplica el nmero de intentos necesarios para descubrir la clave.
Nmero de pasos para realizar el cifrado
El nmero de pasos es la base de clculo para las mtricas relacionadas con el

tiempo de resolucin en un procesador determinado. Tambin permite hacer
estimaciones tericas 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 codificacin en un

determinado procesador. Normalmente se expresa en Mtops (millones de
operaciones tericas por segundo).
Fuerza del algoritmo
Es una medida subjetiva. Esta mtrica propone una serie de niveles asociados a
las caractersticas 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 ms cercana o barata. Los niveles
propuestos son:
Un algoritmo tiene nivel US (Unconditionally Secure) si, independientemente

del mtodo 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 anlisis criptogrfico sistemtico en un perodo de tiempo
suficientemente corto como para que la informacin 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 ms

conocido.
Tabla 8.3. Algoritmos de cifrado y su evaluacin.
7.4. Mtricas de seguridad de red
La coleccin de medidas propuestas se dividen en bsicas y de procesos:
Mtricas bsicas
Nmero de intentos de intrusin con xito en un perodo de tiempo.

Nmero de intentos de intrusin sin xito en un perodo de tiempo.
Nmero de virus detectados en la red en un perodo de tiempo.
Nmero de intrusiones detectadas en la red en un perodo de tiempo.
Nmero de violaciones de las reglas de seguridad detectadas en un perodo
de tiempo.
Nmero de intentos de saltarse las reglas de seguridad detectados en un
perodo de tiempo.
Porcentajes de palabras de claves de acceso caducadas.
Nmero de modificaciones sobre las claves de entrada modificadas por los
usuarios en un perodo de tiempo.
Evaluacin de la inversin en monitorizacin de la seguridad de la red en
un perodo de tiempo.
Nmero de reglas de seguridad utilizadas.
Frecuencia de las revisiones de acceso.
Frecuencia de las actualizaciones contra virus.
Nmero de componentes de la red infectados en un perodo de tiempo.
Mtricas de proceso
- Nmero de usuarios externos al sistema.

- Nmero de usuarios internos que salen a la red pblica.
- Nmero deJirewalls por sistema que existen en la red.
- Porcentaje de claves de entrada adecuadas a la poltica propuesta por la
organizacin.
- Porcentaje de claves de entrada modificadas segn la poltica de la
organizacin.
- Porcentaje de sistemas con informacin 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. Gestin de la Calidad y
Aseguramiento de la Calidad. Parte 3: Directrices para la
aplicacin de la Norma ISO 9001:1994 al desarrollo,
suministro, instalacion y mantenimiento de soporte lgico.
AENOR. Madrid, 1998.
[AENOR, 20001 e UNE-EN ISO 9000. Sistemas de gestin de la calidad.
Fundamentos y vocabulario. AENOR. Madrid, 2000.
[AENOR, 2000al UNE-EN ISO 9004. Sistemas de gestin de la calidad.
Directrices para la mejora del desempeo. AENOR. Madrid,
2000.
[Alcatel, 19951 e AAVV, "Modelo de madurez software. CMM: Capability
Maturity Model" Alcatel Standard Elctrica, 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 Hernndez y Vctor La Torre. Fondo Educativo
Interamericano, S.A. Mjico.1970.
[Amescua, 20011 Antonio de Amescua. SPICE. Ponencia presentada en el
XII Cursos de Verano de la UNED, Modelos y mtodos para
la mejora de los procesos de desarrollo de sofware vila, Julio
2001. Documentacin oficial de las Jornadas.
[Amescua, e Antonio de Amescua, Juan Llorns y ngel Garca.
Llorns y Garca, "SPICE: un marco para la evaluacin de procesos
19971 software",Calidad del Software 11, NOVATICA, Julio/Agosto
1997, no 128, pg. 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. Princples 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. "Tcnicas de aseguramiento de la calidad
del software", Monografa, Calidad del Software 1,
NOVATICA enerolfebrero 1997, no 125, pp. 62-66.
[Castell y e Nria Castell y ngels Hernndez. "Filtrado de
Hernndez, 19971 Especificaciones de Software escritas en lenguaje Natural",
Monografa, Calidad del Software 1, NOVATICA,
enerolfebrero 1997, no 125, pp. 31-46.
[Cerrada, 200 11 e Jos Antonio Cerrada Somolinos. Introduccin.
Conceptos de Mejora de los Procesos. Ponencia presentada
en el XII Cursos de Verano de la UNED, Modelos y mtodos
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 Asociacin de Tcnicos de Informtica
(ATI), noviembre 1997. Documentacin oficial de las
Jornadas.
[Cuevas y Gonzalo Cuevas y Vicente Martnez. "Infraestructura y

Martnez, 19971 funciones necesarias en una organizacin para la
implantacin de un proyecto de mejora continua del proceso
del software", monografa, 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. Cmo se hace un tesis? Tcnicas y
procedimientos de investigacin, 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 edicin. 2002.
[Freixanet, Caas Josep R. Freixanet, Eduard Caas y Enric Roca. "Plan
y Roca, 19971 de Mtricas del Software: aproximacin a su diseo",
Monografa, NOVATICA, Julio/agosto, 1997, no 128, pp.8-
14.
[Gibbs, 19941 W. Wayt Gibbs. "La crisis crnica de la programacin",
Investigacin y Ciencia, Tendencias en Informtica, pp. 72-
81, noviembre, 1994.
[Gmez, Bernaras A. Gmez, A. Bernaras, M. Emaldi y F.J. Ruiz. "La
y otros, 19971 mejora del proceso de Software en I+D", Monografa, Calidad
del Software 1, NOVATICA, enerolfebrero 1997, no 125, pp.
22-30.
[Gonzlez, 19971 Julio Gonzlez Sanz. "La Calidad del Software", Fsica y
Sociedad. Oviedo, Madrid, Grficas SUMMA, Nmero 8,
Otoo 1997, pp. 32-36.
[Gonzlez, 1997b3 Julio Gonzlez Sanz. "La nueva versin de la norma ISO
9000-3, gua para la aplicacin de ISO 9001: 1994",
enerolfebrero , 1997, no 125, pp. 5-9.
[Gonzalo, 20011 Agustn Gonzalo Cuevas. Estructura del Modelo de
Madurez de la Capacidad. Ponencia presentada en el XII
Cursos de Verano de la UNED, Modelos y mtodos para la
mejora de los procesos de desarrollo de sofware vila, Julio
2001. Documentacin oficial de las Jornadas.
[Granja, 19971 Juan Carlos Granja lvarez. "Calidad del Software 1",
Monografa, NOVATICA, enero /febrero, 1997, no 125, p. 3.
[Hernndez, Juan Francisco Hdez. Ballesteros. El papel de las
20021 mtricas en el aseguramiento de la calidad del software.Tesis
Doctoral. E.T.S.I.1, UNED, noviembre, 2002.
[Hernndez, Juan Francisco Hdez. Ballesteros. "La ingeniera del
19981 software como solucin a la crisis de la programacin". El
Da, abril de 1998.
[Huecas, Maas y Gabriel Huecas, Jos. A. Maas y Toms Robles.
Robles, 19971 "Mtricas de Cobertura tcnicas de descripciones formales",
Monografa, 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.
[Inn, 19971 M" Luisa Inn. "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. espaola de
Jos Mara Vallhorant Bou. Editorial Revert, S.A., 1990).
[Kan, 20031 Stephen H. Kan. Metrics and Model in Software
Engineering. Segunda edicin. Pearson Education, Inc.
Boston . 2003.
[Kugler, 19971 e Hans-Jrgen Kugler. "Mejora de los procesos de
Software: el modo de mantenerse por delante en calidad",
Monografa, NOVATICA, enerolfebrero, 1997, no 125, pag.
4.
[Longstreet e David H. Longstreet y Raffaela Ibba. " Fundamentos del
Ibba, 19961 anlisis 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 Pblicas. Plan
general de garanta de calidad aplicable al desarrollo de
equipos lgicos, Coleccin INFORMES Y DOCUMENTOS,
Secretara General Tcnica, Instituto Nacional de
Administracin Pblica, 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 Melin. Garantas de Calidad del
Software. Ponencia presentada en Cursos de Verano, vila,
Julio 1995. Documentacin 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 Innovacin y Calidad del
Software. Asociacin de Tcnicos de Informtica. Palma de
Mallorca, Julio 2002. Documentacin 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, versin l .1 Modelos y mtodos para la
mejora de los procesos de desarrollo de software
(Documentacin de referencia CMM V 1.1: CMUSEI-93-
TR-24 y CMCr/SEI-95-TR-25, nivel 2), Software
Engineering Institute. 1993.Traducido por SOMEPRO.
Documentacin aportada en los, XII Cursos de Verano,
Universidad Nacional de Educacin 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" Edicin. McGraw-Hill, Inc. 1993.
(Trad. por Carlos Cervigon Ruckaer).
[Quesada, 19871 Quesada Herrera, Jos. Redaccin y presentacin 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 dinmicos para la gestin de
proyectos software: un nuevo enfoque", Monografa, Calidad
del Software 1, NOVATICA, enerolfebrero 1997, no 125, p.
53.
[Real, 20011 Real Academia Espaola de la Lengua. Diccionario de la
lengua espaola. Edicin 22. Madrid, 2001.
[Rementeria, Santiago Rementeria. " Eficacia de la gestin del
19971 software en un contexto organizativo amplio", Monografa,
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.
[Rodrguez, Garv M.L. Rodrguez, 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.
[Snchez, Pickin C. Snchez, S. Pickin y otros. "La calidad del producto
y otros, 19971 en los sistemas distribuidos", Monografa, Calidad del
Software 1, NOVATICA, enerotfebrero 1997, no 125, pg.47.
[Sanchis, 19981 Francisco Sanchs Marco.Evaluacin y gestin de
proyectos informticos. 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.
[Sebastin y col., Miguel ngel Sebastin Prez, Vicente Bargueo Farias
19941 y Vicente Novo Sanjurjo. Gestin 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,
pg 164.
[Sobrino, 19971 Carlos Sobrino Snchez. Gestin de calidad. Aplicacin a
la industria del software. I Jornada sobre Calidad del
Software, organizada por el grupo de Trabajo sobre Calidad
del Software de la Asociacin de Tcnicos de Informtica
(ATI), noviembre 1997. Documentacin 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 vdeo, e Video La Calidad del Software, Programacin TV.
19961 Educativa 95/96, Programa 081, emisin 27 de mayo de
1996, UNED, Centro de Diseo y Produccin de medios
audiovisuales.
[Villena, 19971 e Villena, Leonardo."La metrologa, la Calidad y las
PYMES", Fsica y Sociedad. Oviedo, Madrid, Grficas
SUMMA, Nmero 8, Otoo 1997, pp. 10-15.
[Visconti, Marcello Visconti et al. "Experiencia con un modelo de
Antimn y Rojas, madurez para el mejoramiento del Proceso de Aseguramiento
19971 de Calidad del Software", Monografa, 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 estndares al aseguramiento del
producto software", Monografa, 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 mtrica para la
Palomar, 19971 capacidad de prueba del Software", Monografa, 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. pg. 154.
[Zuse, 1991 Horst Zuse. Software Complexity and Methods.
DeGruyter Publisher. Berlin-New York, 1991.

Libro La Calidad Del SW y Su Medida PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro La Calidad Del SW y Su Medida PDF

Cargado por

Copyright:

Formatos disponibles

Jess M.

" Miriguet Melian

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

JUAN FRANCISCO HERNNDEZ BALLESTEROS

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

Impreso en Espaa 1 Printed in Spain

CAPTULO 2: LA MEDIDA DE LA CALIDAD DEL SOFTWARE ...............63

3.3. Las reglas de estimacin de De Marco.................................................... 70

CAPTULO 3: NORMALIZACI~NY CERTIFICACI~N:

10.4. Realizacin del producto o servicio ...................................................... 116

CAPTULO 4: MODELOS. METODOLOGAS Y ESTNDARES:

CAPITULO 5: MTRICAS PARA MODELOS CONCEPTUALES ............ 153

2.2. Mtricas de Moody ................................................................................. 157

CAP~TULO6: EL ANLISIS DEL PUNTO FUNCIN ............................... 165

3. Ms all del Anlisis del Punto Funcin tradicional ..............................................192

CAPITULO 7: LA NORMA ISOIIEC 9126 Y LA MEDIDA

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

CAPITULO 8: MTRICAS DEL SOFTWARE ........................................ 221

AENOR Asociacin Espaola de Normalizacin y

MAP Ministerio de Administraciones Pblicas.

Los programas informticos, el software, es el valor aadido de mayor

Nos encontramos ante un reto, uno ms en esta civilizacin 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 comunicacin 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 slo para los productos materiales, tambin 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. Definicin de Calidad

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

Segn Mara ~ o l i n e rcalidad,

o Grado en el que un conjunto de caractersticas inherentes cumple con los

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

En el caso del software y su proceso de creacin, consideraremos como

2.2. Tipos de Calidad

En los mbitos industriales en general, y en los informticos en particular,

Calidad necesaria. Es la calidad que pide el cliente y la que le gustara 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 ms sobresalientes de la calidad son:

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

Las consecuencias de la implantacin 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 caractersticas operativas principales de un producto, que son

La diferenciacin se refiere a las caractersticas 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 diseo y las prestaciones del producto

Es la medida de la vida del producto. En esta medida de carcter tcnico

producto depender de las condiciones econmicas; as, si la economa va bien los