Libro-La Calidad Del SW y Su Medida

Jess M.
" Miriguet Melian 3wn Francisco HernBndez B a i l e t e ~ s
!.
11
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 recuperacin, 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 4.
.........................................................41
41
Aproximacin histrica...................................................................................
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.
6.
Concepciones errneas y paradigrnas de la calidad ...................................... 56 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 61 6.5. La Regla Federal Express ........................................................................
CAPTULO 2: LA MEDIDA DE LA CALIDAD DEL SOFTWARE ............... 63 1. 2. Introduccin.................................................................................................... -63 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
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 ............................................................................................................ 5.1. Definiciones ............................................................................................. 78 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. 8. La medida del software .................................................................................. 89 7.1. Marco terico ........................................................................................... 89 La norma ISOIIEC 9126 ................................................................................ 93
CAPTULO 3: NORMALIZACI~N CERTIFICACI~N: Y NORMA ISO 9001 :2000 ....................................................................................... 95 1. 2. 3. 4. Normalizacion y certificacion........................................................................ 96 Terminologa sobre calidad del software........................................................ 97 Los niveles de la calidad ................................................................................ 98 Los sistemas de calidad .................................................................................. 98
4.1. Definicion.................................................................................................... 98 4.2. Partes del sistema ........................................................................................ 99 4.3. Manual de calidad ....................................................................................... 4.4. Los procedimientos................................................................................. 99 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 Proceso de certificacin ............................................................................... 8.1. Antecedentes ............................................................................................ 8.3. Principios del cambio............................................................................... 9. 104 La familia de normas ISO:9000 ................................................................... 108 108 8.2. La ISO 9000.2000. Razones para un cambio .......................................... 109 110 8.4. Las normas ISO 9000:2000 ..................................................................... 111 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 .........................................................................
.
7.
8.
..
115
10.2. Responsabilidad de la direccin ............................................................ 116 10.3. Gestion de los recursos .......................................................................... 116
13
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~TULO EL ANLISIS DEL PUNTO FUNCIN ............................... 165 6:
1. 2.
Introduccin al Anlisis del Punto Funcin ................................................ 165 1.1. La propuesta de Albrecht: ventajas e inconvenientes ............................. 165 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
174 2.6.1. Identificacin de Entradas Externas ........................................................
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
15
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 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.
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. 3. 4. Indicadores y mtricas relacionadas con la calidad ................................... 230 2.1. Densidad de defectos e indicadores de calidad del proceso ................... 230 Fiabilidad ...................................................................................................... 232 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 APF ASA AS1 ATT AWS CE CEN CIS CMM COCOMO DFP DSI DTR EE ESPRIT EVS FIE FLI GQM GSC IAS IBM IEC IECISA IEEE IFPUG IMT ISO JAN JTC LCMS LOC Asociacin Espaola de Normalizacin y Certificacin. Anlisis del Punto Funcin. American Standards Association. Anlisis del Sistema de Informacin. American Telephone & Telegraph. American War Standards. Cuestiones Externas. Comit Europeo de Normalizacin. Construccin del Sistema de Informacin. Capability Maturity Model. COnstructive COst Model. Punto Funcin del desarrollo del proyecto. Diseo del Sistema de Informacin. Draft Technical Report. Entradas Externas. European Strategic Program for Research and Development Estudio de Viabilidad del Sistema. Fichero de Interfaz Externo. Fichero Lgico Interno. Goal Question Metrics. Caractersticas Generales del Sistema. Implantacin y Aceptacin del Sistema. International Business Machines. International Electrotechnical Commission. Informtica El Corte Ingls. Institute of Electrical and Electronic Engineers. International Function Point Users Group. Inspeccin Media Total. International Organization for Standards. Joint Army-Navy Standard. Joint Technical Committee. Lmite de Calidad Media de Salida. Lines Of Code.
1X
LISTA DE SIGLAS
MAP METKIT MIT MSI MTTF NASA OTAN PSI SAG SE SE1 SPICE TED TER UFC VAF WG
Ministerio de Administraciones Pblicas. Metrics Educational ToolKIT. Massachusetts Institute of Technology Mantenimiento de Sistemas de Informacin. Mean Time to Faillure. National Aeronautics and Space Administration. Organizacin del Tratado del Atlntico Norte. Planificadn de Sistemas de Informacin. Software A.G. Salidas Externas. Software Engineering Institute. Software Process Improvement and Capability dEtermination. Tipos de Elementos de Datos. Tipos de Elementos de Registros. Puntos Funcin sin Ajustar. Valor del Factor de Ajuste. 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 o o o o
La calidad es un factor competitivo. La calidad es esencial para el comercio internacional. La calidad reduce las prdidas pr~ducidas la no calidad. por La calidad mantiene a los clientes e incrementa los beneficios. La calidad es el sello distintivo de los negocios de nivel mundial. La calidad en la industria del software
1.2.
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.
'
'
25
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.
26
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."
27
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
o o
Grado en el que un conjunto de caractersticas inherentes cumple con los requisitos8. El conjunto de actividades encaminadas a descubrir y satisfacer las necesidades de un colectivo o de una sociedad en general9. Satisfaccin del cliente y conformidad con sus requisitos y necesidades'' . 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.
28
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.
29
n
CALIDAD REALIZADA
CALIDAD PROGRAMADA
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
O O
0
Implica la mejora continua de la productividad y de la competitividad. Significa hacer las cosas bien a la primera. Consiste en dar al cliente lo que ste desea. Se basa en el sentido comn. Involucra a todos los niveles de la empresa.
30
Las consecuencias de la implantacin de un sistema de calidad son: o Mejora de la imagen de la empresa. Apoyo al marketing. Favorece el espritu de equipo. Genera valor aadido. Genera crecimiento sostenido basado en la excelencia. Es una inversin sin riesgo.
o o o o
o
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.
31
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
32
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
33
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.
34
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 o o
Los clientes satisfechos son los mejores vendedores. Los clientes satisfechos son ms fieles a la hora de una nueva compra. Los productos y servicios de mayor calidad proporcionan mejores precios y mrgenes comerciales. Menores costes de comercializacin, ya que no hay que captar nuevos clientes.
35
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
36
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
37
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:
38
o o o o o
o
o
El objetivo principal es la deteccin de errores. Su visin de la calidad es un problema a resolver. Pone el nfasis en la uniformidad del servicio. Emplea mtodos de fijacin de estndares y medicin. El papel de los profesionales de la calidad es de inspeccin, clasificacin, conteo y medicin. La responsabilidad de la consecucin de la calidad es del departamento de inspeccin. Su orientacin y enfoque es que la calidad se comprueba.
Control de la calidad
3.2.
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.
39
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.
40
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.
41
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.
42
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.
43
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 autoestablecidos. 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.
44
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
45
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
46
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
47
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
48
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
49
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
Se fan de la creatividad y del buen trabajo artesanal Supervisores inspeccionan la calidad antes de la liberacin de producto Cuantificacin de la calidad del producto; tcnicas de muestre0
Artesanos
Industria del Industria en Software general Aos sesenta Antes del siglo XIX
Aos setenta Siglo XIX
Inspeccin
Control estadstico del proceso Aseguramiento de la calidad Conformidad con la calidad Calidad dirigida al cliente Calidad dirigida al mercado
Pocas evidencias de uso Aos ochenta
Aos treinta
Uso de estndares en los sistemas de calidad para los procesos Calidad total: se eliminan derroches y minimizan costes Calidad total dirigida hacia el cuidado del cliente y del servicio Calidad total dirigida hacia el cliente existente as como a clientes en
Aos cincuenta Aos ochenta
Aos noventa
Pocas evidencia de uso Pocas evidencias
Aos noventa
Algunas 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-
50
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.
51
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.
52
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 DODSTD-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. 945. La traduccin es nuestra.
53
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
''
54
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.
55
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.
56
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
0
o o
La calidad es intangible y, por consiguiente, no puede medirse. La calidad es cara. La calidad significa lujo, peso y brillo. La calidad no es un problema de la gerencia y la administracin. 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:
57
Detectar errores. La antigua funcin de la deteccin y correccin de errores es sustituida por la ms activa de prevenir los errores. Cumplir los estandares. El cumplimiento a rajatabla de los estndares de la organizacin debe de evolucionar hacia satisfacer las expectativas de los clientes. 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. 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. 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. 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.
58
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.
59
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 o
o
o 6.4.
Cuesta cinco veces ms obtener un cliente nuevo que retener a uno antiguo. Slo el diez por ciento de los clientes que han tenido una mala experiencia vuelve a repetir la compra. Slo el cuatro por cientos de los clientes defraudados se lo comunica al proveedor. Un cliente insatisfecho comenta su caso con, al mnimo, diez personas. 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.
60
Costes
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.
61
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 s~ de programas para ordenador se encuentra sumido y que ~ i b b ilustra 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 traduccin es nuestra. 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.
65
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 que c o ~ 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
' 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. Fenton, Norman E., op. cit. pg. 6. 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 Engineering, John Wiley & Sons, 1994.
Fenton, Norman E., op. cit. pg. 5. La traduccin es nuestra.
66
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.
67
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.
68
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.
69
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.
70
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.
71
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.
72
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.
73
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)~ T = C E ~
Ecuacin 2.1 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.
74
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.
75
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.
76
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".
413 L = CkK113 td 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:
' ,
L ~(ck3 td4) Ecuacin 2.6 /
De esta segunda ecuacin podemos deducir interesantes conclusiones. El factor t al estar afectado por una potencia tal alta indica que pequeas variaciones en el d tiempo de entrega pueden modificar enormemente el esfuerzo a realizar. Por otro lado tambin observamos la dependencia de este modelo del valor asociado a C , k 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.
Figura 2.1. Aproximacin a las Curvas de Rayleigmorden.
78
5.
MEDIDA
Definiciones
5.1.
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 traduccin es nuestra. '' Fenton, Norman E., op. cit. pg. 17. La traduccin es nuestra. l9Fenton, Norman E., op. cit. pg. 19. La traduccin es nuestra.
79
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
80
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.
81
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.
82
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. M(x) 2 M(y) 3 M'(x) 2 M'(y)
M ' = a M + b (a>0) M'=aM (a > O ) M'=M
Ordinal Intervalo Ratio 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.
83
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.
84
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 zwebenZ3hicieron 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. 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. 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. 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.
85
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. es una medida basada en una e ~ ~ 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.
86
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
87
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 p es, 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~el h ~ 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 un producto industrial basado en la idea original de s~' 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 Engineering, John Wiley & Sons, 1994. 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 Engineering, John Wiley & Sons, 1994. 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.
88
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 o o
Falta de madurez en la medida del software. Inexistencia de estandarizacin en las medidas. 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.
89
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.
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 traduccin es nuestra.
33
90
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
91
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
Fenton, Norman E. SofhYare Metrics. A Rigorous Approach. London, Chaprnan & Hall, 1992. Pg. 48. La traduccin es nuestra.
36
92
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 o, en general, resultado, derivado de los procesos ejecutados. Salida de los mismos. Para documentacin: longitud, modularidad, redundancia etc. Para cdigo o diseo formal: estructuracin, acoplamiento etc. Edad del personal, salario, velocidad del equipo hardware (entre otros) Mantenimiento, Movilidad, Reutilizacin etc.
Recursos
Cualquier tipo de entidad considerada como entrada para la produccin del software. Pueden ser de muy diversa naturaleza. Herramientas, mtodos, materiales, son ejemplos de recursos.
Productividad, experiencia, fiabilidad, capacidad de reutilizacin (entre otros)
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.
93
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.
fallos Interoperatividad Seguridad Adherencia a normas Capacidad de recuperacin Adherencia a normas
aprendizaje Operatividad Software atractivo Adherencia a normas
Uso de recursos Adherencia a normas
para cambios Estabilidad Facilidad para pmebas Adherencia a normas
instalacin Coexistencia Facilidad de reemplazo Adherencia a normas
Tabla 2.6. La norma ISOIIEC 9126.
Captulo 3
NORMALIZACI~N CERTIFICACI~N: Y 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.
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.
97
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 ~ define como la "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 ~ define como "el proceso de la 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
99
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.
101
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. 5.1.
CALIDAD A NIVEL DE PROYECTO 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.
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 to en una de las normas UNE-EN-ISO que definen tres modelos de ~ s e ~ u r a m i e nde 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
105
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
No exigencias de la certificacin
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.
109
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.
111
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:
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 90003: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.
113
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:
-
9.4.
El compromiso de la direccin. El enfoque al cliente. La poltica de calidad. La planificacin. La administracin. La revisin por la direccin. 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. Realizacin del producto o servicio
9.5.
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.
115
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.
117
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:
119
"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.
'
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.
123
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~AS Y
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. -Estndares y procedimientos no seguidos por los trabajadores. -El trabajo viene impuesto por crisis puntuales a superar. -Acciones de "apagafuegos". -Estimaciones de costes, esfuerzos y plazos superados al no poseer datos fiables sobre objetivos a alcanzar. -Falta de un conocimiento riguroso de procesos y de la propia organizacin. -Acciones individuales y "heroicas", a veces contraproducentes
-Procesos de desarrollo y mantenimiento de software bajo control. -Planes establecidos guan el trabajo a realizar. -Existe una comunicacin fluida entre equipos de trabajo, existe la transmisin de experiencia entre los tcnicos. -Estimaciones de costes, esfuerzos y plazos son generalmente respetados. -Responsabilidades y cometidos definidos claramente. -Funcionalidad y calidad del producto.
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.
125
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
127
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~AS ESTNDARES Y
1
Procesos de mejora continua
I
Nivel 5
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.
129
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
131
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:
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.
133
"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 o o o
Funcionalidad. Fiabilidad. Facilidad de uso. 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.
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-HacerComprobar-Accin. Por otro lado BOOTSTRAP se asienta en que antes de cualquier inversin en tecnologa tales como herramientas de ltima generacin o complicados soportes
135
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) b) c) d) e)
reas objeto de inters. La estructura y comportamiento del rea estudiada, esto es, su organizacin. La escala de la organizacin utilizando un modelo de referencia. Las mtricas que permitan "medir" la organizacin. 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. 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~AS ESTNDARES Y
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. 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. 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...
137
Madurez BOOTSTRAP
Tecnologa Sistema de Calidad Administracin de los recursos Metodologa Innovacin tecnolgica Funciones para el ciclo de vida Funciones independientes del
ciclo de vida
Funciones de Administracin Administracin de configuracin y cambio Administracin de riesgos Administracin de proyectos Administracin de la calidad Administracin de subcontratistas Funciones de Procesos Descripcin de procesos Medida de los procesos Control de los procesos Funciones de Desarrollo Modelo de desarrollo Requisitos, anlisis y definicin Diseo de la arquitectura Implementacin y diseo detallado Prueba 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
138
Organizacin Ingeniera del Soporte
Ingeniera del
Ingeniera del Producto
Tecnologa
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.
139
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 IEC
International Organization for Standards International Electrotechnical Commission Joint Technical Committee 1 Responsables de las Tecnologas de la Informacin Software Engineering Working Group on Software Process Assessment
JTC1
SC7 WGlO
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.
Establecer los mecanismos que permitieran migrar desde estndares ya establecidos, as como evitar la aparicin de otros estndares de facto. 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 AT&T Be11 Labs, EE.UU Be11 Canada Northen Telecom, Canad British Telecom, Gran Bretaa ITDC, Finlandia Etnoteam, Italia
AFNOR, Francia IBM, Australia Fujitsu, Japn NTT, Japn CSELT, Italia Brameur, Gran Bretaa Defense Research Agency, Gran Bretaa
Tabla 4.2. El deseo por internacionalizar del proyecto SPICE implica la colaboracin de numerosos organismos.
141
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. ISOIIEC 15504 - 2. Information technology - Software proccess assessment. Part 2: A reference modelo for processes and process capability. Technical Report, publicado el 15 de agosto de 1998. ISOIIEC 15504 - 3. Information technology - Software proccess assessment. Part 3: Performing an assessment. Technical Report, publicado el 15 de agosto de 1998. ISOIIEC 15504 - 4. Information technology - Software proccess assessment. 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. ISOIIEC 15504 - 6. Information technology - Software proccess assessment. Part 6: Guide to competency of assessors. Technical Report, publicado el 15 de agosto de 1998. ISOIIEC 15504 - 7. Information technology - Software proccess assessment. Part 7: Guide for users in process improvement. Technical Report, publicado el 15 de agosto de 1998. ISOIIEC 15504 - 8. Information technology - Software proccess assessment. Part 8: Guide for use in determining supplier process capability. Technical Report, publicado el 15 de agosto de 1998. ISOIIEC 15504 - 9. Information technology - Software proccess assessment. 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.
143
Soporte
MAN. 2 Admir
SUP. 1 Documentacin SUP.2 Administracin de la configuracin SUP. 3 Aseguramiento de la
calidad
SUP. 4 Verificacin SUP. 5 Validacin SUP. 6 Revisin SUP. 7 auditoria SUP. 8 Resolucin de problemas
procesc el proceso
nrnrern
RG. i Orien
-..,.""'-
1 del
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.
144
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.
Procesos propios del Ciclo de Vida
Cliente
Adquisicion. Suministro, Operdcion Requisitos Inoenieria Deiarrollo,Mantenimiento Sum~nistrador Documentacion, Adminstracion de ~onfigurd~ion, aseguramiento de la calidad, vrrificdcion, validacion, revision, auditoria, resoluc~on problemas de Administracion Administracion, proyecto, cali+d y riesgos Organizac~m Oricntac~on, mejora, recursos humanos. infraestmctura, medida y reuso
Niveles y atributos Nivel O Proceso Incompleto Nivel 1 Proceso Realizado Rendimiento del uroceso K I \ F I2 P r o c e s c ~ . ~ \ d r n ~ n ~ ~ ~ r ' d d ~ ~ Admini\iraiii>n del Kcndimitnto Administracin del Trabajo del Producto Nivel 3. Proceso establecido Definicin del Proceso Recursos del Proceso Nivel 4 Proceso Predecible Medida del Proceso Control del Proceso Nivel S Proceso Optimizado Cambio del Proceso Mejora Continua
Figura 4.9. Las dos dimensiones del estndar ISO/IEC 15504.
145
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 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.: Rendimiento del Proceso (86%-100%) Atri. Proc.: Administracin del Rendimiento (86%-100%) Atri. Proc.: Administracin del Trabajo del Producto (86% - 100%) Atri. Proc.: Definicin del Proceso (51%-100%) Atri. Proc.: Recursos del Proceso (51%-100%) Nivel 4 Atri. Proc.: Rendimiento del Proceso (86%-100%) Atri. Proc.: Administracin del Rendimiento (86%-100%) Atri. Proc.: Administracin del Trabajo del Producto (86% - 100%) Atri. Proc.: Definicin del Proceso (86%-100%) 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.: Rendimiento del Proceso (86%-100%) Atri. Proc.: Administracin del Rendimiento (86%-100%) Atri. Proc.: Administracin del Trabajo del Producto (86% - 100%) Atri. Proc.: Definicin del Proceso (86%-100%) 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
' ISO/IEC TR 15504-2. Information technology -Software process assessment - Part:2 A reference model for
processes andprocess capability. ISOIIEC. Suiza, 1998. Pg. 20.
processes andprocess capability. ISOIIEC. Suiza, 1998. Pg. 19.
147
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 processes andprocess capability. ISOIIEC. Suiza, 1998. Pg. 23.
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 O O
O O
O
O
MAP y el Comit de Seguimiento. Administracin General del Estado (Defensa, Interior, Justicia, Trabajo, entre otros). Comunidades Autnomas (Andaluca, Castilla-La Mancha, Madrid, Pas Vasco). Ayuntamientos. Informtica El Corte Ingls (IECISA). Universidad Carlos 111de Madrid. Fondos PEINATYCA.
Los usuarios a los que va dirigida MTRICA V. 3. pueden resumirse en:

O O O
Administracin del Estado. Comunidades Autnomas. 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
149
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 O O
Planificacin de sistemas de informacin. Desarrollo de sistemas de informacin. Mantenimiento de sistemas de informacin
A su vez el proceso principal desarrollo de sistemas de informacin se ha dividido en cinco procesos:

O O O
Estudio de viabilidad del sistema (EVS). Anlisis del sistema de informacin (ASI). 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 O O
O
Gestin de Proyectos (GP). Seguridad (SEG). Aseguramiento de la Calidad (CAL). 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.
150
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, EVS 3, EVS 4, EVS 5, EVS 6.
Situacin actual Catlogo de Requisitos y Objetivos Alternativas de Solucin Solucinn Pronuesta
Anlisis del Sistema de Informacin
Figura 4.10. Actividades consideradas en el proceso de Evaluacin del Sistema de Informacin.
151
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. Plan de Trabajo.
trabajo.
Jefe de Proyecto
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.
Batini et al. (1992)
Reingruber M. y Gregory W. (1994)
1
Boman et a1 (1997)
expresividad, autoexplicacin, extensibilidad y normalidad Correccin conceptual, complecin conceptual, correccin sintctica, complecin sintctica, conocimiento de la empresa. Facilidad de compresin, correccin semntica, estabilidad, complecin conceptual.
Tabla 5.1. Calidad y sus propiedades segn autores.
155
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~, mtodo que haba desarrollado para el 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
157
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
un En 1998, ~ o o d ~ \ r e s e n t 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.
D. Moody. Metrics for evaluating the quality of entity relationship models. Proceedings of International Conference on Conceptual Modelling. Singapur, 1998. the 1 7 ' ~
158
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
159
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. Nmero total de atributos derivados en el modelo. Nmero total de atributos compuestos en el modelo. Nmero total de atributos multivaluados en el modelo. Nmero total de relaciones comunes en el modelo. Nmero total de relaciones N:M en el modelo. Nmero total de relaciones I:N e 1:I en el modelo. Nmero total de relaciones binarias en el modelo. AryR.
NDA NCA NMVA NNR NM:NR NI: NR NbinaryR NN
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. 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. 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. 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
AHF
MIF
AIF
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.
161
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
NOC
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. 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.
162
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
NIM
NIV
NCM NW
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. 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. 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. El Nmero de Mtodos de Clase es el nmero total de mtodos a nivel de clase. El Nmero de Variables de Clase es el total de variables a nivel de clase que tiene una clase.
Mtricas de herencia
NMO
NMI
NMA
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. 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. 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.
163
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
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 Nagg Ndep Ngen NgenH
enero'^ y otros
La mtrica Nmero de Asociaciones se define como el nmero total de asociaciones dentro de un modelo de clases. La mtrica Nmero de Agrupaciones se define como el nmero de relaciones de agregacin dentro de un modelo de clases. El Nmero de Dependencias es el nmero total de relaciones de dependencia en un modelo de clases. El Nmero de Generalizaciones se define como el nmero total de relaciones de generalizacin dentro de un modelo de clases. 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 MmDIT
MaxHAgg
La mtrica Nmero de Jerarquas de Agregacin es el nmero total de jerarquas de agregacin dentro de un modelo de clases. 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. 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 Hagg NODP El Nmero de Asociaciones por Clase es el nmero total de asociaciones de una clase (con otras clases o con ella misma). 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. 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. El Nmero de Partes es el nmero de clases "partes" (directas o indirectas) de una clase "todo". La mtrica Nmero de Todos se define como el nmero de clases "todos" (directas e indirectas) en una clase "parte". La mtrica Agregacin Mltiple es el nmero de clases "todo" directas que tiene una clase en una jerarqua de agregacin. El Nmero de Dependencias In se define como el nmero de clases que depende de una clase dada. El Nmero de Dependencias Out es el nmero de clases de las que depende la clase dada.
NP
NW
Masg Ndepln NdepOut
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
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.
I
166
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.
167
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 Tamao del programa
Ecuacin 6.1
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.
169
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 mantenido, dentro de los limites de la aplicacin? Pregunta 3 El grupo de datos es modificado, o mantenido, a travs de un proceso elemental de la
Afirmativo/Negativo.
Afirmativo/Negativo.
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).
171
"Propuesta A"
control cs un grupo Igicamente relacionado o identificable por el usuario de forma que cumpla con requisitos especificamente establecidos por
Pregunta 2 El gmpo de datos es utilizado como referencia por la aplicacin que est siendo considerada y, adems, es externo a la misma? Pregunta 3 El gmpo de datos no es mantenido por la aplicacin que est siendo medida? Pregunta 4 El gmpo de datos es considerado como un FLI, al menos por otra aplicacin? Pregunta 5 El grupo de datos considerado no ha
Explicaci~i
AfirmativoMegativo.
AfimativoMegativo. Afimativo/Negativo. 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 cada campo no recurrente, ln&o y reconocible para el usuario en un FLI o FIE ;Clave externa? Contabilizar un TED por cada una de ellas Contabilizar implementaciones fsicas como simples TED
n I O FIE
Fichero " Pmeba A" Campo "AA" Campo " A B Campo "AC"
SiMo SiMo SiMo
SiMo SiMo SiMo
SiMo SINo 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.
173
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 mantenidos a travs de un proceso elemental de la aplicacin. Regla 3. El proceso es la unidad de actividad menor que es significativa para el usuario final. Regla 4. El proceso es auto-contenido2 y deja la aplicacin que est siendo medida en un estado consistente. Regla 5. Para el proceso identificado 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.
Afirmativo/Negativo
Afirmativo/Negativo
AfirmativotNegativo
Afirmativo/Negativo
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 por el usuario para asegurar el cumplimiento con los requisitos de funcin del sistema. Regla 3. Para identificar los procesos, una de las dos siguientes reglas debe ser
-
Afirmativo/Negativo
Afirmativo/Negativo
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 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.
ArmativoMegativo
Regla 7 El proceso no actualiza FLI

AfirmativoMegativo
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).
179
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.
180
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).
181
coi 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 recuri
gas Externia
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
I
vr
P;
como m
N
fsica? Considerair un TED 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.
185
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.
2.
3.
Contar el nmero de ficheros y transacciones identificados agrupando stos segn su complejidad. Multiplicar el nmero de ficheros y transacciones ya agrupados segn su complejidad por el factor correspondiente. Sumar los 15 valores obtenidos.
La ecuacin para determinar los Puntos Funcin sin ajustar es:

15
UFC =
i=I
(Nmero de items de var iedad i) x ( p e s q) Ecuacin 6.7
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
Medio
X3 = X4= X6=
o
O 36
Medio
X5= X7= X3= X4= X6=
O 42 27 4 O
Medio
Tabla 6.22.Ejemplo del clculo de los Puntos Funcin sin ajustar para transacciones.
187
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. 2. 3. 4. 5. 6. 7. 8.
Comunicaciones. Procesamiento distribuido de datos. Rendimiento. Uso elevado de la configuracin. ndice de transacciones. Entrada de datos en-lnea. Eficiencia y usuario final. 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. b. c. d. e. f. No presente o sin influencia. Influencia circunstancial. Influencia moderada. Influencia media. Influencia significativa. 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 Donde: DFP es el valor de los Puntos Funcin del desarrollo del proyecto. UFP es el valor de los Puntos Funcin sin ajustar.
Ecuacin 6.10
189
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 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.12
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:
191
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.
192
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.
195
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
196
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. Correccin. Fiabilidad. Eficiencia. Facilidad de mantenimiento. Facilidad de prueba. Flexibilidad. Facilidad de reutilizacin. Interoperabilidad. Movilidad.
Operacin del Producto
Revisin del Producto
Transicin del Producto
Tabla 7.1. Factores del modelo de McCall.
197
Facilidad de mantenimiento Puedo arreglarlo? Facilidad de prueba Puedo probarlo? Flexibilidad Puedo modificarlo?
Interoperabilidad Puedo relacionarlo con otros sistemas? Movilidad Puedo utilizarlo en otra mquina? Reutilizacin 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".
198
Preguntas 1
2
Respuesta: S N o R D I
Hay referencias ambiguas? 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) Facilidad de mantenimiento = 1 correccin)

-
o o
U
0,1 (nmero medio de das-hombre por
Movilidad = 1 - (esfuerzo para trasladarlesfuerzo para implementar) 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
199
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.
200
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.
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.
202
Calidad del proceso
---F
Medida del
roces so
Calidad interna
---+
--+
Medida interna
Calidad externa
Medida externa
Calidad de uso
Medida de la 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.
203
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
o
o o o
Idoneidad. Capacidad del software de proporcionar un conjunto apropiado de funciones para tareas especficas y objetivos del usuario. Exactitud. Capacidad del software para proporcionar resultados correctos o que necesitan un determinado grado de precisin. Interoperatividad. Capacidad del software de interaccionar con uno o ms sistemas especificados. Seguridad. Capacidad del software de proteger la informacin y los datos. 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:
204
o o o
Madurez. Capacidad del software para evitar fallos como resultados de defectos en el software. Tolerancia a fallos. Capacidad del software para mantener un nivel especificado de rendimiento en casos de fallos del software. Capacidad de recuperacin. Capacidad para restablecer el nivel de rendimiento y de recuperacin de datos afectados directamente en el caso de un fallo. Adherencia a normas. Capacidad del software relacionada con el grado de conformidad con estndares, convenciones o regulaciones existentes en leyes o prescripciones similares.
Facilidad de uso. Capacidad del producto software de ser entendido, aprendido, usado y atractivo al usuario, cuando es utilizado bajo ciertas condiciones especificadas.
o
o o
o 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. Fcil aprendizaje. Capacidad del producto software que permite al usuario aprender la aplicacin software. Operatividad. Capacidad del producto software que permite al usuario controlar y usar la aplicacin software. Software atractivo. Capacidad del producto software de ser atractivo al usuario. Adherencia a normas. Capacidad del software relacionada con el grado de conformidad con estndares, convenciones o regulaciones existentes en leyes o prescripciones similares.
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. 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. Adherencia a normas. Capacidad del software relacionada con el grado de conformidad con estndares, convenciones o regulaciones existentes en leyes o prescripciones similares.
205
Mantenimiento. Capacidad del producto software para ser modificado. Se descompone en:
o
o
o
o o
Facilidad de anlisis. Capacidad del producto software para diagnosticar deficiencias o causas de fallos en el software. Capacidad para cambios. Capacidad del producto software que permite la ejecucin de una modificacin especfica en el mismo. Estabilidad. Capacidad del producto software para evitar efectos no esperados debidos a modificaciones en el mismo. Facilidades para pruebas. Capacidad del producto software que permite al software que ha sido modificado ser evaluado. Adherencia a normas. Capacidad del software relacionada con el grado de conformidad con estndares, convenciones o regulaciones existentes en leyes o prescripciones similares.
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 o
o
Adaptabilidad. Capacidad del producto software para ser adaptado a diferentes entornos especificados sin aplicar acciones alejadas de aquellas que el propio software proporcione. Facilidad de instalacin. Capacidad del producto software para ser instalado en un entorno especfico. Coexistencia. Capacidad del producto software de coexistir con otros programas independientes en un entorno comn y compartiendo recursos tambin comunes. 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. Adherencia a normas. Capacidad del software relacionada con el grado de conformidad con estndares, convenciones o regulaciones existentes en leyes o prescripciones similares.
206
LA NORMA ISOlIEC 9126
La calidad de uso, de forma grfica:
Calidad de uso
Eficacia
Productividad
Seguridad
1'
Satisfaccin
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).
207
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.
209
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.
210
METRICA Versin .3
Se apoya en Definicin de requisitos
Seleccin de mtricas
ISO 9126
Selecciona
Valoracin del criterio
Mtricas
m
Medida
Obtiene
Figura 7.9. El procedimiento de medida propuesto.
211
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 Definicin de requisitos
,vscAL,
E"I
CAL
Figura 7.10 Definicin de requisitos de calidad.
212
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
213
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
O
Seleccin de mtricas. Tasar. Valoracin del criterio.

METRICA V
3.0
Se apoya en
0 : .
Preparacin evaluacin
Utiliza
Seleccin de mtricas
\
Se basa
en
Tasar
Selecciona
m
Mtricas
Figura 7.11 Procedimiento de medida propuesto, paso segundo.
214
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 Tamaodel pro grama
programa
Ecuacin 7.1
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
215
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. 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
o
Fallo muy grave. Implica la paralizacin total del sistema. Fallo grave. Implica la paralizacin total de uno o varios programas. 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.
216
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
217
considerando los niveles de satisfaccin como muy satisfactorio, satisfactorio e insatisfactorio, segn la siguiente figura:
. . . . . . .. .. . . . . . . . . . . . . . . . . . . ... .................... . . . . . . . . . . . . . . . . . . . .. .. .. . . . . .. .. .. .. . . .. .. .. . . . . . . . ....... . . . . . . . ..... .~atiSfactorio.. . . ..... . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . .. .. .. .. . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . .. .. .. .
Muy Insatisfactorio
. . . . ... ... ... . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. ... ... .. .. . Insatisfactorio . . .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . .. .. .. . . . . . .. .. .. .. .. .. .. . . . . . . . . . . .. .. .. .. .. .. .. . . . . . . . . .. .. . . . . . . . .

1,o
0,5
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.
218
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.
219
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: Productividad = Tamao Esfuerzo Ecuacin 8.1
Productividad =
Lneas de cdigo Personas - mes
Ecuacin 8.2
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.
223
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 LOC
Ecuacin 8.4
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.
LOC =
node cavcteres a
Ecuacin 8.5
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
225
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~UCAS DEL SOFTWARE
1
Basic Clipper Fortran 90 Natural Lenguaje Mquina
3.00 17.00 4.00 6.00 0.50
1 por Punto Funcin 1

107 19 80 53 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, 1 O0
Ecuacin 8.6
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:
227
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 Personas - mes
Ecuacin 8.9
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 personas - mes
Ecuacin 8.10
229
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.
Calidad =
nmero de errores IUOC
Ecuacin 8.1 1
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 KLOC
Ecuacin 8.12
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
23 1
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 tamao del programa Ecuacin 8.13
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 nmero de defectos corregidos
Ecuacin 8.14
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
Tasa de efectividad de las pruebas
8.15
nmero de objetos probados almenos una vez * 100 nmero de objetos totales
Ecuacin 8.16
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 - n
Ecuacin 8.18
233
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) = de donde se puede obtener:
f (4 1- F(t)
Ecuacin 8.20
h(t) =
d f ( t ) =--(ln(l-~(t)))=1-F(t) dt
ln R(t) dt
Ecuacin 8.21
ln R(t) = Ih(x)dx
O
Ecuacin 8.22
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 )
O
Ecuacin 8.25
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.
235
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
237
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 la complejidad basndose en el flujo de informacin a~ 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.
238
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 la cohesin como una "medida del grado de conectividad entre h~ 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
239
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
240
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) NFK(T)

5.2.
Nmero de atributos de una tabla. Nmero de claves ajenas de una tabla.
Mtricas a nivel de estrella
Las mtricas propuestas son: NDT(S) NT(S) NADT(S) NAFT(S) FT DTi NA(S) Nmero de tablas dimensionales de una estrella. Nmero de tablas de la estrella. Nmero de atributos de las tablas dimensionales de una estrella. Nmero de atributos de la tabla de hechos de la estrella. Tabla de hechos de la estrella. Tabla dimensional i de la estrella 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.
241
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) NDT(Sc) NSDT(Sc) NT(Sc) NAFT(Sc) Nmero de tablas de hechos del esquema. Nmero de tablas de dimensin del esquema. Nmero de tablas dimensionales compartidas por mas de una estrella. Nmero de tablas del esquema. 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) NFK(Sc) RSDT(Sc) Nmero de atributos del esquema. Nmero de claves ajenas del esquema. 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) Ratio de atributos de las tablas dimensionales compartidas.
RSDTA(Sc)
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.
L. Oman, V. Storey y R. Wang. Systems Approaches http://web.mit.edu/tdqm/www/papers/94/94-0S.html, 1994.
to
Improving
Data
Quality.
243
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.
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.
'O
HFRG. The humanfactors research group.Universiy College Cork, 1990. J- Brooke. User Information Architecture A/D Group.Digita1Equipment Co. Ltd. " J. Nielsen. Usability Engineering.Academic Press, 1993.
245
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 Task Concordance Task Visibility Layout Uniformity Visual Coherence
Simplicidad Eficiencia, simplicidad Visibilidad. Regularidad, uniformidad 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
i
ALGORITMO
j/
j
;!
1
CLAVES
........................................ 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 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".
7
247
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
249
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.
25 1
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, "Measurement: Establishing a Point of [AAVV, 19951 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 [Alcatel, 19951 [Alonso y Finn, 19671 UNE-EN ISO 9004. Sistemas de gestin de la calidad. Directrices para la mejora del desempeo. AENOR. Madrid, 2000. e AAVV, "Modelo de madurez software. CMM: Capability Maturity Model" Alcatel Standard Elctrica, 1995.
Marcelo Alonso y Edward J. Finn. Funtamental 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. e Antonio de Amescua, Juan Llorns y ngel Garca. [Amescua, Llorns y Garca, "SPICE: un marco para la evaluacin de procesos software",Calidad del Software 11, NOVATICA, Julio/Agosto 19971 1997, no 128, pg. 33.
[Ashley y Nicholas Ashley y Paul Goodman. Principles o f Goodman, 19921 Function Point Analysis. Guidelines For Assessing The Influence of System Characteristics.METKIT, London, July 1992. Nicholas Ashley y Paul Goodman. Princples o f [Ashley y Goodman, 1992bl Function Point Analysis. Student Booklet. METKIT, London, July 1992. Nicholas Ashley y Paul Goodman. Principies of [Ashley y 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 O Function f Point Analysis. Bibliography. METKIT, London, July 1992. [Ashley, 1992bl [Ashley, [Ashley, [Ashley, [Ashley, Nicholas Ashley. Module IFPA. Principles O Function f Point Analysis. Glossary o Terms. METKIT, London, July f 1992. 1992~1 Nicholas Ashley. Module IFPA. Principles O Function f Point Analysis. Set o Questions & Answers. METKIT, f London, July, 1992. 1992dl Nicholas Ashley. Module IMMT, Measurement As A Management Tool, Glossary o Abbreviations. METKIT, f London, June 1992. 1992el Nicholas Ashley. Module IWIM. What Is Measurement? Glossary o Abbreviations. METKIT, London, September, f 1992. 1992fl Nicholas Ashley. Module IWIM What Is Measurement? Teacher Guide. METKIT, London, September, 1992.
[Ashley, 1992gl
Nicholas Ashley. Specifying & Measuring Software Quality. Glossary o Abbreviations. METKIT, London, f October 1992. [Ashley, 1992hl Nicholas Ashley. Speczfying & Measuring Software Quality. Module Advert. METKIT, London, October 1992.
255
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, 1992iI
[Ashley, 1992kl [Ashley, 199211 [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley,
Nicholas Ashley. Speczfiing & Measuring Software Quality. Teacher Guide. METKIT, London, October 1992.
e e
Nicholas Ashley. Module IMMT, Measurement As A Management Tool, Set of Questions & Answers. METKIT, London, June 1992. 19941 e Nicholas Ashley. Module IMMT. Measurement As A Management Tool. Student Booklet. s.1. METKIT, London, April 1994. 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. 1994~1 Nicholas Ashley. Measurement As A Management Tool. An Ovewiew of The Materials In The Module IMMT, METKIT Module. METKIT, London, April 1994. 1994dl e Nicholas Ashley. Module IFPA. Principles Of Function Point Analysis. An Ovewiew of the Materials In The Module IFPA. METKIT, London, April 1994. 1994el Nicholas Ashley. Module IFPA. Principles Of Function Point Analysis. Solution to Workshop Example. METKIT, London, April 1994. 1994fl e Nicholas Ashley. Module IFPA. Principles Of Function Point Analysis. Teacher Guide. METKIT, London, April 1994. 199481 Nicholas Ashley. Module IFPA. Principles Of Function Point Analysis. Teacher Guidelines for Making Module Interactive. METKIT, London, April 1994. 1994hl Nicholas Ashley. Module IFPA. Principles Of Function Point Analysis. Workshop Example. METKIT, London, April 1994. 199413 e Nicholas Ashley. Module IMMT, Measurement As A Management Tool, Student Booklet, METKIT, London, April 1994. 1994j1 e Nicholas Ashley. Module IMMT, Measurement As A Management Tool, Teacher Guidelines For Making Module Interactive. METKIT, London, April 1994
[Ashley, 1994kl
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.
e
[Baker, 19791
[Baker et al, 19901 [Banks, 19891 [Boehm, 19811 [Brooks, 19951
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 10120. l A. L. Baker et al. A Philosophy for Software Measurement. The Journal of System and Software, Volume 12, no. 3,1990 pp 227-281. e Jeny Banks. Principies of Quality Control. John Wiley & Sons, 1989. e Bany W. Boehm. Software Engineering Economics. Prentice Hall, 198 1 .
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. Frangois Clementi. SPICE. 1 Jornada sobre Calidad del [Clementi, 19971 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.
257
[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. Eugene Curran y Joc Sanders. Software Quality. A [Curran y Sanders, Framework for Success in Software Development and 19941 Support. Cornwall, Addison- Wesley Publishers, 1994. [Curtis et al., B. Curtis et al. Measuring The Psychological Complexity of Software Maintenance Tasks With Halstead 19791 and McCabe. IEEE Transactions of Software Engineering, 5. 1979. pp. 96-104. Ministerio de Defensa. Requisitos OTAN de [Defensa, 19941 aseguramiento de la caliad para el desarrollo software. PECAL 150-94. 1994. Tom DeMarco. Controlling Software Proyects: [DeMarco, 19821 Management, Measurement and Estimation. Englewood Cliffs, N. J. Prentice Hall, 1982. Robert H. Dunn. "Quality Assurance", Encyclopedia of [Dunn, 19941 Software Engineering, John Wiley & Sons, 1994, pp. 941958. Umberto Eco. Cmo se hace un tesis? Tcnicas y [Eco, 19971 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 Pfleeger,1997] Norman E. Fenton y Shari Lawrence Pfleeger. Software Metrics. A Rigorous & Practical Approach. Boston, PWS Publishing Company, 1997. Norman E. Fenton y Shari Lawrence Pfleeger. Software [Fenton y Pfleeger,2002] Metrics. A Rigorous & Practical Approach. Boston, PWS Publishing Company, segunda edicin. 2002. Josep R. Freixanet, Eduard Caas y Enric Roca. "Plan [Freixanet, Caas de Mtricas del Software: aproximacin a su diseo", y Roca, 19971 Monografa, NOVATICA, Julio/agosto, 1997, no 128, pp.814. [Gibbs, 19941 W. Wayt Gibbs. "La crisis crnica de la programacin", Investigacin y Ciencia, Tendencias en Informtica, pp. 7281, 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", Monografa, Calidad del Software 1, NOVATICA, enerolfebrero , 1997, no 125, pp. 5-9. Agustn Gonzalo Cuevas. Estructura del Modelo de [Gonzalo, 20011 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, 20021 [Hernndez, 19981 Juan Francisco Hdez. Ballesteros. El papel de las mtricas en el aseguramiento de la calidad del software.Tesis Doctoral. E.T.S.I.1, UNED, noviembre, 2002. Juan Francisco Hdez. Ballesteros. "La ingeniera del 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. M.H. Halstead. Elements of Software Science. Elsevier [Halstead, 19771 North-Hollad. 1977. International Function Point Users Group. Function [IFPUG, 19941 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.
259
[ISO, 19981 [ISO, 1998bl
ISO/IEC TR 15504-1. Information technology -Sqftware process assessment - Part:l Concepts and introductoiy guide. ISO/IEC. Suiza, 1998. ISO/IEC TR 15504-2. Information technology -Software process assessment - Part.2 A reference model for processes andprocess capability. ISOIIEC. Suiza, 1998. ISO/IEC TR 15504-3. Inforrnation technology -Software process assessment - Part:3 Performing un assessment. ISO/IEC. Suiza, 1998. ISO/IEC TR 15504-4. Inforrnation technology -Software process assessment - Part:4 Guide to performing assessment. ISO/IEC. Suiza, 1998. ISO/IEC TR 15504-6. Information technology -Software process assessment - Part:6 Guide to competency of assessors. ISO/IEC. Suiza, 1998. ISO/IEC TR 15504- 7. Information technology -Software process assessment - Part: 7 Guide for use in process inprovement. ISO/IEC. Suiza, 1998. ISO/IEC TR 15504-8. Information technology -Software process assessment - Part:8 Guide for use in determining suppliler process capability. ISOIIEC. Suiza, 1998. ISO/IEC TR 15504-9. Information technology -Software process assessment - Part:9 Vocabulaiy. ISO/IEC. Suiza, 1998. ISO/IEC 9126-1. Software engineering - Product quality - Part: 1 Quality model. ISOIIEC. Suiza, 2001. Capers Jones. Software Assessments, Benchmarks, and Best Practices. 2000. Capers Jones. Measuring Programming Quality and Productivity. IBM Systems Journal, Volume 17, no 1, 1978. Capers Jones. A Short History of Function Points and Features Points. Software Productivity Reseach, Inc. Cambrige, Mass, 1988. Capers Jones. Applied Software Measurement: Assuring Productivity and Quality, McGraw Hill, New York, 1991.
[ISO, 1998~1 [ISO, 1998dl [ISO, 1998el [ISO, 1998fl [ISO, 199881
[ISO, 1998hl [ISO, 20011 [Jones, 20001 [Jones, 19781 [Jones, 19881 [Jones, 199 11
[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. 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).
[Juran, 19511
[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. e [Longstreet 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. Ministerio para las Administraciones Pblicas. Plan [MAP, 19911 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. e John J. Marciniak. "Total Quality Management in [Marciniak, 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. 959969. [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.
261
[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 al, 1993bl Mark C. Paulk et al. Key Practices of Capability Maturity Model, Version l .1 , CMU/SEI-93-TR-24. Software Engineering Institute.1993. Mark C. Paulk et al. Modelo de madurez de capacidad [Paulk et al, 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-93TR-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. Steven R. Rakitin. Software verification and validation: [Rakitin, 19971 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 Academia Espaola de la Lengua. Diccionario de la lengua espaola. Edicin 22. Madrid, 2001.
[Real, 20011
[Rementeria, 19971 [Roberts, 19791
[Rodrguez, Garv y Granja, 19971 [Snchez, Pickin y otros, 19971 [Sanchis, 19981 [Salvat, 19961
Santiago Rementeria. " Eficacia de la gestin del software en un contexto organizativo amplio", Monografa, NOVATICA, enerolfebrero, 1997, no 125, pp.25-30. 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. M.L. Rodrguez, E. Garv y J.C Granja. " Calidad y reusabilidad del Software: estudio de la funcionalidad", Monografa, Calidad del Software 1, NOVATICA, enerolfebrero 1997, no 125, pp. 67-68. C. Snchez, S. Pickin y otros. "La calidad del producto en los sistemas distribuidos", Monografa, Calidad del Software 1, NOVATICA, enerotfebrero 1997, no 125, pg.47. Francisco Sanchs Marco.Evaluacin y gestin de proyectos informticos. Servicio de publicaciones EUINPM, 1998. 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 AAVV, Capability Maturity Model Integration for [SEI, 20021 Software Engineering (CMMI), Versionl . l . CMU/SEI-2002TR-028. Software Engineering Institute. Agosto 2002. Software Engineering Laboratory. Collected Software [SEL, 19921 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.
263
[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. James E. Tomayko. "Milestones in Software [Tomayko, 19941 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. Horst Zuse. Software Complexity and Methods. [Zuse, 1991 DeGruyter Publisher. Berlin-New York, 1991.

Libro-La Calidad Del SW y Su Medida

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Libro-La Calidad Del SW y Su Medida

Transféré par

Droits d'auteur :

Formats disponibles

Jess M.

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

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

CAPTULO 1: LA CALIDAD DEL SOFTWARE ............................................ 23

El papel de la calidad en el desarrollo del software ...................................... 23

4.1. Artesanos y obreros ................................................................................. 42 4.2. Los orgenes ............................................................................................ 42

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

Estimacin de costes y esfuerzo ................................................................................. 71

6.2. Maurice Halstead...................................................................................... 83 6.3. El control de flujo de programa ............................................................... 85

6.4. Sistemas de diseo .................................................................................. 86

Calidad a nivel de proyecto..........................................................................

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

ISO 9001:2000 e ISO 9000-3:1997 ..................................................................... 117

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

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

CAPITULO 7: LA NORMA ISOIIEC 9126 Y LA MEDIDA

4.2.2. Tasar ..............................................................................................

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

' Miguel de Cervantes Saavedra. Don Quijote de la Mancha

Captulo 1 LA CALIDAD DEL SOFTWARE

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

LA CALIDAD DEL SOFTWARE

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

LA CALIDAD DEL SOFTWARE

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

LA CALIDAD DEL SOFTWARE

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

Rasgos inherentes a la calidad

Algunos de los rasgos ms sobresalientes de la calidad son:

LA CALIDAD DEL SOFTWARE

2.4. Dimensiones de la calidad

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

LA CALIDAD DEL SOFTWARE

Las caractersticas de la calidad del software

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

Arthur Andersen. La calidad en Espaa. Madrid. Cinco Das. 1995.

LA CALIDAD DEL SOFTWARE

4" La calidad efectiva es garanta de rentabilidad sostenida

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

o Mayor productividad al dirigir los recursos hacia un objetivo comn y

LA CALIDAD DEL SOFTWARE

8" La calidad debe comunicarse

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

Gestin estratgica de la calidad

Figura 1.2. Etapas de la calidad.

LA CALIDAD DEL SOFTWARE

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

LA CALIDAD DEL SOFTWARE

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

Evolucin del concepto de calidad

Tabla l. l. Evolucin de la calidad en la empresa.

LA CALIDAD DEL SOFTWARE

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

La Revolucin Industrial: la inspeccin

LA CALIDAD DEL SOFTWARE

De 1900 a 1950: la era del control estadstico

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

LA CALIDAD DEL SOFTWARE

El aseguramiento de la calidad: aparecen las normas

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

LA CALIDAD DEL SOFTWARE

La Industria del Software y la industria tradicional

LA CALIDAD DEL SOFTWARE Y SU MEDIDA