Libro-La Calidad Del Sw y Su Medida

11

!.

Jesús M." Miriguet Melian 3wn Francisco HernBndez B a i l e t e ~ s

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

LA CALIDAD DEL SOFTWARE Y SU MEDIDA

Reservados todos los derechos Ni la totalidad ni parte de ese libro puede reproducirse o transmitirse por ningún procedimiento electrónico o mecánico, incluyendo fotocopia, grabación magnética o cualquier almacenamiento de información y sistema de recuperación, sin permiso escrito de Editorial Centro de Estudios Ramón Areces, S. A.

O EDITORIAL CENTRO DE ESTUDIOS RAMON ARECES, S.A. Tomas Bretón, 21 - 28045 Madrid

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

CAPÍTULO 1: LA CALIDAD DEL SOFTWARE ............................................ 23 1.

El papel de la calidad en el desarrollo del software ...................................... 23 1.1. ¿Por qué calidad? ....................................................................................

23

1.2. La calidad en la industria del software ................................................... 24 2.

Concepto de calidad ....................................................................................... 27 2.1. Definición de calidad .............................................................................. 27 2.2. Tipos de calidad ...................................................................................... 28 2.3. Rasgos inherentes a la calidad ................................................................ 29 2.4. Dimensiones de la calidad ...................................................................... 30 2.5. Las características de la calidad del software ......................................... 32 2.6. El Decálogo de la calidad ....................................................................... 33

3.

Estados de desarrollo de la calidad ................................................................ 37 3.1. Inspección ................................................................................................

37

3.2. Control de la calidad ............................................................................... 38 3.3. Aseguramiento de la calidad ................................................................... 39 3.4. Gestión de la Calidad Total .................................................................... 40 3.5. Evolución del concepto de calidad 4.

.........................................................41

Aproximación histórica...................................................................................

41

4.1. Artesanos y obreros ................................................................................. 42 4.2. Los orígenes ............................................................................................ 42

4.3. La Revolución Insustrial: la inspección ................................................. 43 4.4. De 1900 a 1950: la era del control estadístico ....................................... 44 4.5. El aseguramiento de la calidad: aparecen las normas ............................ 46 4.6. El presente: la gestión de la Calidad Total .............................................. 47 4.7. La industria del software y la industria tradicional ................................. 48 4.8. Orígenes del aseguramiento de la calidad del software .......................... 49 4.9. Las normas de calidad del software ......................................................... 52 4.10. Análisis de los atributos ......................................................................... 53 4.1 1. Los modelos ........................................................................................... 53 4.12. El futuro ..................................................................................................

55

5.

Concepciones erróneas y paradigrnas de la calidad ...................................... 56

6.

Costes de la calidad ........................................................................................ 57 6.1. Costes de prevención ............................................................................... 58 6.2. Costes de evaluación ................................................................................ 59 6.3. Costes de la no calidad ............................................................................. 59 6.4. Relación costeheneficio .......................................................................... 59 6.5. La Regla Federal Express ........................................................................61

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

Introducción.................................................................................................... -63

2.

Necesidad de la medida del software.............................................................. 65 2.1. La medida como elemento de mejora metodológica .............................. 65 2.2. La medida y el conocimiento................................................................... 66 2.3. Importancia de la medida ......................................................................... 66

3.

Estimación ....................................................................................................... 68

.

.

3.1. Definicion y problemática........................................................................ 68 3.2. Los métodos de estimación ...................................................................... 69

11


3.3. Las reglas de estimación de De Marco.................................................... 70 3.4. Evaluación de las estimaciones ............................................................... 71 4.

Estimación de costes y esfuerzo ................................................................................. 71

4.1. Definiciones de coste y esfuerzo ............................................................. 72 4.2. Los principales modelos ......................................................................... -72 4.3. COCOMO................................................................................................. 72 4.4. SLIM ......................................................................................................... 76 5.

Medida ............................................................................................................

78

5.1. Definiciones .............................................................................................

78

5.2. Teoría general de la medida ..................................................................... 79 5.3. Escalas ..................................................................................................... 82 6.

Aproximación histórica .................................................................................. 83 6.1. Los orígenes ............................................................................................ 83

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

6.4. Sistemas de diseño .................................................................................. 86 6.5. Costes y esfuerzos ................................................................................... -87 7.

La medida del software .................................................................................. 89 7.1. Marco teórico ........................................................................................... 89

8.

La norma ISOIIEC 9126 ................................................................................ 93

CAPÍTULO 3: NORMALIZACI~NY CERTIFICACI~N: NORMA ISO 9001 :2000 ....................................................................................... 95

.

.

.

.

1.

Normalizacion y certificacion........................................................................ 96

2.

Terminología sobre calidad del software........................................................ 97

3.

Los niveles de la calidad ................................................................................ 98

4.

Los sistemas de calidad .................................................................................. 98

.

.

4.1. Definicion.................................................................................................... 98 4.2. Partes del sistema ........................................................................................ 99 4.3. Manual de calidad ....................................................................................... 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. Planificación del aseguramiento de la calidad en un proyecto ............... 101 5.2. El plan de aseguramiento de la calidad del software .............................. 102 5.3. Actividades de aseguramiento de la calidad ........................................ 103 6.

Modelos contractuales de aseguramiento de la calidad ............................. 103

7.

Proceso de certificación ...............................................................................

8.

La familia de normas ISO:9000 ................................................................... 108 8.1. Antecedentes ............................................................................................

104

108

8.2. La ISO 9000.2000. Razones para un cambio .......................................... 109 8.3. Principios del cambio...............................................................................

110

8.4. Las normas ISO 9000:2000 ..................................................................... 111 9.

La norma ISO 9001 :2000 ............................................................................. 112

..

9.1. Introduccion a la norma ........................................................................... 112 9.2. Sistema de gestión de la calidad ............................................................. 113 9.3. Responsabilidad de la dirección ............................................................. 114 9.4. Gestión de los recursos ............................................................................ 114 9.5. Realización del producto o servicio ........................................................ 114 9.6. Medición, análisis y mejora .....................................................................115 10. La norma ISO 9004:2000............................................................................. 115 10.1. Introducción a la norma .........................................................................

115

10.2. Responsabilidad de la dirección ............................................................ 116 .

.

10.3. Gestion de los recursos .......................................................................... 116

13


10.4. Realización del producto o servicio ...................................................... 116 10.5. Medición, análisis y mejora .................................................................. 117 11. La calidad. su aseguramiento y medida según la norma

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

CAPÍTULO 4: MODELOS. METODOLOGÍAS Y ESTÁNDARES: ESTRATEGIAS PARA ALCANZAR LA CALIDAD ..................................... 121 1.

Modelos. metodologías y estándares ........................................................... 121 1.1. Definiciones ............................................................................................. 121

2.

El Modelo de Madurez de la Capacidad del Software ................................ 123 2.1. Los cinco niveles definidos en el modelo CMM ................................... 124 2.2. Áreas clave y características comunes .................................................... 128 2.3. La calidad. su aseguramiento y medida según el modelo....................... 131

3.

Modelo BOOTSTRAP................................................................................. 134 3.1. El concepto Bootstrap. del diagnóstico a la solución ............................. 134 3.2. Práctica del modelo.................................................................................. 136

4.

La norma ISO 15504 .................................................................................... 139 4.1. ISO 15504. un modelo.bidimensional..................................................... 141 4.2. La calidad. su aseguramiento y medida en la norma ............................. 146

5.

Metodología MÉTRICA V. 3 ...................................................................... 147 5.1. MÉTRICA. una metodología basada en proceso ................................... 149

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

1.

Modelos conceptuales .................................................................................. 153 1.1. Definciones .............................................................................................. 153 1.2. Calidad de los modelos conceptuales ...................................................... 154

2.

Métricas para modelos conceptuales tradicionales ........................................155 2.1. Métricas de Kesh .....................................................................................

155

INDICE

14

2.2. Métricas de Moody ................................................................................. 157 2.3. Métricas de Piattini ................................................................................. 159 3.

Métricas para modelos conceptuales orientados a objetos ........................... 159 3.1. Métricas de Brito e Abreu y Carapuca.................................................... 159 3.2. Métricas de Chindamber y Kemerer ...................................................... 161 3.3. Métricas de Lorenz y Kidd ...................................................................... 162 3.4. Métricas de género y al ............................................................................ 163

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

1.

Introducción al Análisis del Punto Función ................................................ 165 1.1. La propuesta de Albrecht: ventajas e inconvenientes ............................. 165

2.

El Análisis del Punto Función paso a paso .................................................. 168 2.1. Determinar el tipo de conteo a realizar .................................................. 168 2.2. Identificar los límites en los que se aplicará el conteo de los Puntos Función ...................................................................................

168

2.3. Identificación de los Ficheros Lógicos Internos (FLI) .......................... 169 2.4. Identificación de los Ficheros de Interfaz Externo (FIE) ....................... 170 2.5. Clasificar la complejidad de los ficheros lógicos y determinar su contribución ....................................................................................... 171 2.6. Conteo de los tipos de función asociado a transacciones .......................... 174 2.6.1. Identificación de Entradas Externas ........................................................174

2.6.2. Identificación de Salidas Externas................................................ 176 2.6.3. Identificación de Cuestiones Externas ........................................ 177 2.6.4 Clasificar la complejidad de las transacciones identificadas y su contribución .................................................................................. 179 2.6.5. Cálculo del valor de los Puntos Función sin ajustar .................... 185 2.6.6. Cálculo del valor del factor de ajuste ........................................... 187 2.6.7. Cálculo de los Puntos Función ajustados .................................... 188

15


3.

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

CAPITULO 7: LA NORMA ISOIIEC 9126 Y LA MEDIDA

DE LA CALIDAD .............................................................................................. 193 1.

Descomponer un problema para buscar la solución ................................ 193 1.1. La descomposición jerárquica en árbol ................................................... 194 1.2. Modelos de McCall y Boehrn ................................................................. 196

2.

La norma ISO/IEC 9126 .............................................................................. 200 2.1. Calidad de uso, interna y externa ........................................................... 201 2.2. Medidas internas y externas .................................................................... 206

3.

Procedimiento de medida propuesto ............................................................ 207

4.

La medida de la fiabilidad de una aplicación informática. Ejemplo práctico ........................................................................................... 211 4.1. Definición de requisitos de calidad ........................................................ 211 4.2. Preparar la evaluación .............................................................................. 213

.

4.2.1. Seleccion de métricas .................................................................... 214 r

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

216

4.2.3. Valoración del criterio .................................................................. 217 4.2.4. Obtención de medidas ................................................................... 219

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

Métricas e indicadores de la productividad................................................. 221 1.1. Medida del tamaño ................................................................................... 222 1.2. Medida de la productividad .................................................................... 227

2.

Indicadores y métricas relacionadas con la calidad ................................... 230 2.1. Densidad de defectos e indicadores de calidad del proceso ................... 230

3.

Fiabilidad ......................................................................................................

4.

Complejidad del software ........................................................................... 234

232

4.1. La Ciencia del Software de Halstead ...................................................... 234 4.2. La medida de la complejidad de McCabe ............................................... 235 4.3. La métrica de Henry y Kafura ................................................................ 237 5.

Métricas para modelos de datos ................................................................... 240 5.1. Métricas a nivel de tabla ......................................................................... 240 5.2. Métricas a nivel de estrella ..................................................................... 240 5.3. Métricas a nivel de esquema .................................................................... 241 5.4. Calidad de los propios datos .................................................................... 242

6.

Medidas del facilidad de uso de las interfaces de usuario .......................... 243 6.1. Clasificación de los métodos .................................................................. 243 6.2. Algunos métodos de evaluación ............................................................. 244

7.

Medida de seguridad .................................................................................... 245 7.1. Un poco de historia ................................................................................. 246 7.2. SSE-CMM ............................................................................................... 247 7.3. Métricas de eficacia de los algoritmos criptográficos ............................ 248 7.4. Métricas de seguridad de red .................................................................. 250

LISTA DE SIGLAS AENOR 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

Asociación Española de Normalización y Certificación. Análisis del Punto Función. American Standards Association. Análisis del Sistema de Información. American Telephone & Telegraph. American War Standards. Cuestiones Externas. Comité Europeo de Normalización. Construcción del Sistema de Información. Capability Maturity Model. COnstructive COst Model. Punto Función del desarrollo del proyecto. Diseño del Sistema de Información. Draft Technical Report. Entradas Externas. European Strategic Program for Research and Development Estudio de Viabilidad del Sistema. Fichero de Interfaz Externo. Fichero Lógico Interno. Goal Question Metrics. Características Generales del Sistema. Implantación y Aceptación del Sistema. International Business Machines. International Electrotechnical Commission. Informática El Corte Inglés. Institute of Electrical and Electronic Engineers. International Function Point Users Group. Inspección Media Total. International Organization for Standards. Joint Army-Navy Standard. Joint Technical Committee. Límite de Calidad Media de Salida. Lines Of Code.

1X

MAP METKIT MIT MSI MTTF NASA OTAN PSI SAG SE SE1 SPICE TED TER UFC VAF WG

LISTA DE SIGLAS

Ministerio de Administraciones Públicas. Metrics Educational ToolKIT. Massachusetts Institute of Technology Mantenimiento de Sistemas de Información. Mean Time to Faillure. National Aeronautics and Space Administration. Organización del Tratado del Atlántico Norte. Planificadn de Sistemas de Información. 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 Función sin Ajustar. Valor del Factor de Ajuste. Working Group.

La sociedad actual reclama productos y servicios informáticos que den respuesta a sus necesidades, requisitos cada vez más exigentes en un mercado globalizado de altísima competitividad. La respuesta de las empresas debe sustentarse en el disciplinado ejercicio de metodologías que tengan en la calidad un instrumento eficaz para responder a este desafío. Los programas informáticos, el software, es el valor añadido de mayor trascendencia en las industrias de principios del siglo XXI. Sin este componente el instrumental más sofisticado o el ordenador más complejo carece de valor, relegado a un amasijo de cables y circuitos electrónicos sin utilidad. La ingeniería del software como disciplina nacida hace casi cuarenta años como respuesta a la llamada "crisis de la programación" asume las estrategias de las ingenierías tradicionales y trata de utilizarlas adaptándolas a la fabricación de programas para ordenador. Esta misma ingeniería que busca en modelos de calidad tradicional su más fiel aliado debe proseguir en la mejora continua de sus procesos. Dentro de esta mejora se encuentra, sin duda, la obtención de medidas adecuadas a las entidades y atributos que le son propios. Medir implica conocer y conocer permite manipular aquellos factores de interés en la búsqueda de la excelencia. Medir la calidad es, por tanto, un requisito imprescindible en las nuevas metodologías del software y un factor estratégico en el sector de la nueva economía. Nos encontramos ante un reto, uno más en esta civilización en constante cambio, en constante evolución. Un reto que, sin duda, exige un decidido apoyo a la investigación y a las tecnologías de la información y las comunicaciones. La divulgación científica es un camino seguro en la consecución de un conocimiento global. Nos permite el intercambio de información, comprender y ser comprendido, explicar y entender. Por todo esto es seguro que el reto al que nos enfrentamos estará culminado con el esfuerzo y la superación que no son más que una etapa intermedia hacia el éxito. Ricardo Melchior Navarro Presidente del Excmo. Cabildo Insular de Tenerife

Nada puede torcer el camino de la verdad y la calidad, porque éstas adelgazan y no quiebran y siempre andan sobre la mentira y la falta de industria, como el aceite sobre el agua 1

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

' Miguel de Cervantes Saavedra. Don Quijote de la Mancha

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

Capítulo 1 LA CALIDAD DEL SOFTWARE La calidad tiene la estructura de un águila bicéfala (...) porque al mismo tiempo que un paradigma, que un ejemplo, la calidad se ha convertido en un gran tópico.'

La industria del software, como tal industria, tiene muchas de las características de la industria tradicional, entre ellas la necesidad de que sus productos sean de calidad. En este capítulo se tratará del concepto de calidad, de sus características y de sus diferentes estados a través de los tiempos, para terminar con un breve estudio sobre los costes y beneficios que conlleva la implantación de un sistema de calidad.

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

¿Por qué calidad?

Tanto en los medios de comunicación escritos y audiovisuales como en las revistas técnicas el tema de la calidad tiene una presencia continuada; incluso los políticos y gobernantes incluyen el término en sus discursos y proyectos. Todo ello es debido al papel fundamental que la calidad juega en la competitividad de las empresas y a que se ha acabado el tiempo en que la demanda superaba a la oferta y el cliente tenía que conformarse con lo que le ofrecían. Hoy en día, los oferentes de productos y10 servicios deben adaptarse a las necesidades, gustos y exigencias de

'

López Cachero, M. 11 Jornadas de Calidad del Software, organizadas por la Asociación de Técnicos de Informática. Madnd 2 y 3 de julio de 1998.

LA CALIDAD DEL SOFTWARE

24

los potenciales clientes para mantenerse en el mercado. Incluso la Comunidad Europea propone la necesidad de la evaluación y certificación de los productos europeos, la calidad europea, como medio para evitar su discriminación en los mercados internacionales. La necesidad de producir productos de calidad es una realidad evidente exigida por un mercado abierto, enormemente competitivo y en constante evolución. Tal como Edward yourdon2 expone "... la posibilidad de que los usuarios finales sean demasiado exigentes puede explicarse por la presión empresarial a la que están

sometido^"^. Existen varias razones que justifican el por qué la calidad es crítica para la supervivencia de las empresas: o o o o o

1.2.

La calidad es un factor competitivo. La calidad es esencial para el comercio internacional. La calidad reduce las pérdidas pr~ducidaspor la no calidad. 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

La exigencia de la calidad no es sólo para los productos materiales, también lo es para los productos inmateriales, los llamados servicios. Dentro de estas empresas de servicio se encuentran las empresas desarrolladoras de software; y las principales de ellas han apostado por la calidad como demuestran las siguientes consignas o tesis: "Si no mantenemos nuestro ímpetu en el aspecto de la calidad, los japoneses nos adelantarán". Hewlett-Packard. "El crecimiento no es nuestro objetivo principal. Nuestro objetivo ha de ser una organización de calidad, lo cual significa que nos sentiremos orgullosos de nuestro trabajo y de nuestros productos en los años venideros. A medida que alcancemos la calidad, el crecimiento vendrá por añadidura". Digital.

'

Yourdon, Edward. Investigador ampliamente conocido por idear el método estructurado de análisis y diseño, así como ser coautor del método denominado CoadIYourdon para programación orientada a objeto en los años noventa. Autor de más de quinientos artículos y veinticinco libros es licenciado en matemáticas por el MIT y el Instituto Politécnico de Nueva York. Consultar el sitio http://www.vourdon.com. Yourdon Edward, "Lo bueno..¿es lo mejor?", Byte, no 22, octubre 1996. pág. 154.

'


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

26


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


27

2. CONCEPTO DE CALIDAD 2.1.

Definición de Calidad

Con objeto de estudiar la medida de la calidad del software se hace imprescindible definir este atributo. No es difícil encontrar más de una decena de definiciones aportadas por instituciones, estudiosos y organizaciones propias del ámbito tradicional de la prestación de servicios o del suministro de bienes manufacturados. La Real Academia Española de la Lengua define el concepto "calidad" como6 : Calidad (del lat. Qualitas, -atis y este calco del griego poiothz) .f. Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor. 2. Buena calidad, superioridad o excelencia. 3. Carácter, genio, índole. 4. Condición o requisito que se pone en un contrato. 5. Estado de una persona, naturaleza, edad y demás circunstancias y condiciones que se requieren para un cargo o dignidad. 6. Nobleza del linaje. 7. Importancia o gravedad de algo. 8. pl. Prendas personales 9. Condiciones que se ponen en algunos juegos de naipes. ~, en sentido amplio, equivale a "cualidad" Según María ~ o l i n e rcalidad, Como se puede observar las acepciones del término son muy variopintas, aunque añadiremos aquellas que se encuentran en los textos que tratan de la calidad, tal como se entiende en los ámbitos empresariales, tales como: o

o

o o

Grado en el que un conjunto de características 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. Satisfacción del cliente y conformidad con sus requisitos y necesidades'' . El grado de satisfacción que produce al cliente" .

'Real Academia Española. Diccionario de la lengua española. 22" Edición. Madrid, 2001. Pág. 401. ' María Moliner. Diccionario de uso del Español. Editorial Gredos S.A. Madrid, 2000. Pág. 224. UNE-EN ISO 9000. Sistemas de gestión de la calidad. Fundamentos y vocabulario. AENOR. Madrid, 2000. Pág. 16. Sebastián Pérez, Miguel Ángel; Bargueño Fariñas, Vicente; Novo Sanjurjo, Vicente. Gestión y Control de calidad. Cuadernos de la V E D . Madrid. UNED. 1994. Pág. 15. ' O Sebastián Pérez, Miguel Angel; Bargueño Fariñas, Vicente; Novo Sanjurjo, Vicente. Op. Cit. Pág. 15. "JOC Sanders y Eugene Curran. Software Quality. A Framework for Success in Software Development and Support, Centre for Software Engineering, Dublin, Addison-Wesley Publishing Company, 1994. Pág. 3. La traducción es nuestra.


28

o

El proceso de identificar, aceptar, satisfacer y superar constantemente las expectativas y necesidades de todos los colectivos humanos relacionados con la empresa (clientes, empleados, directivos, propietarios, proveedores y la comunidad) con respecto a los productos y servicios que proporciona'2.

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

Tipos de Calidad

En los ámbitos industriales en general, y en los informáticos en particular, circulan numerosas historias jocosas de cómo lo que se proporciona al cliente no tiene nada que ver ni con lo que éste ha solicitado ni con el diseño inicial. Por ello podemos distinguir tres tipos de calidad relacionados entre sí: calidad necesaria, calidad programada y calidad realizada. Calidad necesaria. Es la calidad que pide el cliente y la que le gustaría recibir. Calidad programada. Es el nivel de calidad que se propone obtener el fabricante. Calidad realizada. Es la calidad que se puede obtener debido a las personas que realizan el trabajo o a los medios utilizados.

''Arthur Andersen. La Calidad en España. Cinco Días. Madrid, 1995. Pág. 28.


29

n

/

\

CALIDAD REALIZADA

\

y

CALIDAD PROGRAMADA

CALIDAD

/

Figura 1.1. Los tres tipos de calidad. Podemos representar estas calidades como tres círculos que se cortan. Lo que la gestión de la calidad pretende conseguir es que el área común sea la mayor posible, incluso que lleguen a coincidir para evitar insatisfacciones y gastos superfluos. A veces se habla de calidad percibida, que no tiene que coincidir con la realizada, ya que depende de la subjetividad de algunas de las características, por ejemplo la estética, y es debido a que los usuarios no disponen de la información completa. En estos casos los productos o servicios se evalúan más por su nombre de marca o la publicidad que por sus características objetivas. La calidad percibida es el grado de calidad que el cliente cree que tiene el producto o servicio. Al ser subjetiva del cliente, el sistema de gestión poco puede hacer para que la calidad percibida sea igual a la realizada, salvo incrementar la comunicación a fin de conseguir la convergencia. 2.3.

Rasgos inherentes a la calidad

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

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 común. Involucra a todos los niveles de la empresa.


30

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

o o o o o

Mejora de la imagen de la empresa. Apoyo al marketing. Favorece el espíritu de equipo. Genera valor añadido. Genera crecimiento sostenido basado en la excelencia. Es una inversión sin riesgo.

2.4. Dimensiones de la calidad

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

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

Sebastián, Miguel Angel; Bargueño, Vicente; Novo, Vicente. Gestión y Control de calidad. Madrid. UNED. 1994.

"


31

Diferenciación

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

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

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

Es la medida de la vida del producto. En esta medida de carácter técnico subyace un aspecto económico. La duración técnica es la cantidad de uso que se obtiene del producto antes de su deterioro físico, sin posibilidad de reparación. Si la reparación es posible, la duración es más difícil de calcular, ya que la vida del


32

producto dependerá de las condiciones económicas; así, si la economía va bien los coches usados tienen menor duración. En general, el cliente tiene que elegir entre el coste de la reparación para incrementar la duración y la inversión de un nuevo modelo más fiable. Como se puede deducir la fiabilidad tiene mucho que ver con la duración. Aunque no siempre una mayor duración implica una mejora 'del producto, ya que puede ocultar una situación económica particular, por ejemplo, obsérvese el parque automovilístico cubano, cuya vida media sobrepasa de largo los 14 años considerados como media, siendo casi joyas de museo.

Asistencia técnica Esta característica está relacionada con el servicio de reparaciones y la atención al cliente en general, y comprende la prontitud en la atención o reparación, la competencia de los empleados y el trato al consumidor. Algunos aspectos pueden medirse objetivamente, como el tiempo de reparación o el del actualización de un antivirus, otros como el trato al cliente sólo puede hacerse de forma subjetiva. Es uno de los aspectos que más influyen en la percepción actual de la calidad.

Estética Es muy subjetiva y está muy ligada a la personalidad del usuario, que no tiene por qué aceptar los cánones establecidos. La forma de un producto, su color, sabor, tacto o sonido o gráficos afectan de forma diferente a los diferentes usuarios. En un programa de videojuegos la calidad que percibe el usuario está muy ligada a la estética (parte gráfica, música de fondo, diseño de los personajes, etc.).

2.5.

Las características de la calidad del software

Debido a que el software es intangible, no material, muchas personas tienen dificultades para asociarle el concepto de calidad. Sin embargo las posibilidades de fmstración y de pérdida de confianza en él son muy elevadas. Para adaptar las dimensiones estudiadas a la calidad del software se seguirá la norma ISO 9126, que describe seis características compuestas: Funcionalidad, Fiabilidad, Facilidad de uso, Eficiencia, Mantenimiento y Movilidad. Cada una de ellas se descomponen en subcaracterísticas que serán estudiadas en detalle en el correspondiente capítulo. Así, cuando se adquiere un software se quiere que éste funcione siempre y bajo diferentes condiciones incluso difíciles de cumplir (fiabilidad), que realice las funcionalidades que dice tener y que por ello se ha adquirido (funcionalidad), que


33

se puedan ejecutar las funcionalidades de una forma fácil (facilidad de uso), que lo hagas lo más rápido posible y con el mínimo consumo de recursos (eficiencia), que cuando las circunstancias lo pidan pueda modificarse fácilmente (mantenimiento) y, por último, que pueda transferirse de un entorno a otro (movilidad o portabilidad). Quizás, de las dimensiones manejadas, la del nivel más bajo asumido es la fiabilidad, ya que el software debe funcionar siempre que se requiera. Qué mayor fmstración que cuando se está de viaje con un portátil, no pueda utilizarse por un incidente del sistema operativo. El siguiente nivel exigido, el intermedio, es la funcionalidad. No sólo el software debe de tener las funcionalidades que dice tener, sino que debe comunicarlas. Es decir, el usuario debe disponer de la información suficiente para poner usar de forma eficaz todas las tareas. El manual de usuario de la aplicación es un componente más del software. En un nivel superior se encuentra la facilidad de uso (usabilidad). Además de hacer lo que debe hacer el software, debe de hacerlo de una forma fácil, natural y amigable, de ahí la importancia del diseño de las interfaces. El resto de las características son complementarias de las anteriores, ya que lo fundamental es que el software, en primer lugar, debe de funcionar, hacer lo que dice que hace y de una manera fácil. La economía de recursos, la facilidad de modificación y el transporte del software añaden la miel a la hojuela de las tres características fundamentales. 2.6.

El Decálogo de la calidad

~ preceptos Este decálogo de la calidad es propuesto por Arthur ~ n d e r s e n 'como fundamentales para la gestión exitosa del factor estratégico Calidad. Según los autores, el decálogo es consecuencia de su experiencia en consultoría. Los preceptos del decálogo son: 1" La calidad la deJinen los clientes

En los actuales mercados competitivos son los clientes los que determinan sus necesidades y si los productos y servicios que se le ofrecen les satisfacen. De ahí que las empresas deban entender y conocer las necesidades, preferencias, percepciones y valores de los potenciales clientes y, en base a ellos, y con el fin de 14

Arthur Andersen. La calidad en España. Madrid. Cinco Días. 1995.


34

establecer una posición de liderazgo en algún segmento, identificando aquellos factores o dimensiones de calidad en los que tiene ventajas competitivas y diseñando estrategias de segmentación para explotar los nichos del mercado correspondientes. 2" El proceso de calidad se inicia con el liderazgo activo de la Alta Dirección La calidad no se delega, se practica. Por consiguiente deben ser los directivos los que lideren activamente el proceso de la calidad. Una vez que los directivos han previsto el futuro de la empresa u organización y la estrategia de calidad han de impulsar su desarrollo y crecimiento. Como la visión y la estrategia de calidad han de ser compartidas por toda la organización, el estilo de gestión ha de ser participativo y se ha de practicar diariamente lo que se predica. 3" La calidad es un factor estratégico de competitividad y diferenciación

No se puede hablar de niveles de calidad absolutos, ya que lo que importa es la comparación que los clientes hacen de las calidades percibidas entre los diferentes productos o servicios en competencia en el mercado. El factor de calidad a tener en cuenta como ventaja competitiva varía a lo largo del ciclo de vida del producto desde la innovación en su inicio, pasando a la competencia en precio y calidad como factor diferenciador según se avanza en el ciclo. La calidad y el servicio al cliente son ventajas competitivas duraderas.

4" La calidad efectiva es garantía de rentabilidad sostenida Si el criterio primordial empresarial es la excelencia del servicio al cliente, la eficacia de las operaciones se evalúa en términos de calidad más que en términos de costes, ya que, si el nivel de calidad obtenido cumple con las expectativas de los clientes, la rentabilidad está garantizada. A la larga la calidad implica reducción de costes, aunque al principio haya que invertir en formación, aprendizaje y modificación de los hábitos. La rentabilidad se debe a diversos factores como: o o o

o

Los clientes satisfechos son los mejores vendedores. Los clientes satisfechos son más fieles a la hora de una nueva compra. Los productos y servicios de mayor calidad proporcionan mejores precios y márgenes comerciales. Menores costes de comercialización, ya que no hay que captar nuevos clientes.


35

o Mayor productividad al dirigir los recursos hacia un objetivo común y conocido. 5" La calidad involucra a todo los miembros de la organización

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

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

Si una organización no evalúa todas sus actividades desde la orientación al cliente puede que implante sistemas incompatibles con la calidad. Los sistemas que más influyen en la gestión eficaz de la calidad son:

-

Sistemas de captación de información externa. Esta información se convierte en la base para el conocimiento del mercado, de la competencia y de los gustos y necesidades de los clientes y permite que se traduzcan en


36

innovaciones en los productos y servicios para responder ágilmente a los cambios del entorno.

-

Sistemas de medición de la calidad, Estos sistemas permiten evaluar los factores de calidad que soportan la estrategia de la empresa. Con esta información y la obtenida en el apartado anterior se puede evaluar el grado de cumplimiento de los objetivos de calidad establecidos y la posición competitiva de la empresa y de proceder a efectuar las correcciones necesarias.

-

Sistemas de retribución e incentivos al personal. Estos incentivos deben ligarse al cumplimiento de los objetivos de calidad, y es la herramienta más eficaz para motivar al personal y modificar su comportamiento.

8" La calidad debe comunicarse

Para que la'calidad sea percibida hay que dar a conocer las ventajas diferenciadoras que pueden ser cumplidos por la empresa para generar expectativas en los clientes. Nunca deben anunciarse aspectos que sean falsos, ya que defraudan, causan frustración y suponen la pérdida del cliente. Las estrategias comunicacionales tienen como objetivo: -

-

Crear una imagen institucional que se asocie con el concepto de calidad. La promoción de los aspectos de calidad difeenciadores.

9" Calidad implica sensibilidad y preocupación de la empresa por su entorno social y medioambiental Si una empresa se orienta hacia la calidad tiene que distinguirse por su sensibilidad y responsabilidad hacia la comunidad y el medio ambiente en el que se desenvuelve. No puede separarse del concepto global de calidad la responsabilidad social, la ética y la conservación del medio ambiente. La responsabilidad social forma parte de la imagen de la empresa. 1 O" La calidad es dinámica La calidad no es estática, está constantemente en transformación debido fundamentalmente a tres factores: los gustos y motivaciones de los consumidores cambian con el tiempo, la competencia presiona mediante el lanzamiento de


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 gráfico siguiente:

Gestión estratégica de la calidad

Aseguramiento de la calidad

Figura 1.2. Etapas de la calidad.

3.1.

Inspección

Como consecuencia de la organización "taylorista" de la producción nace el control de calidad como supervisión de los productos terminados según el concepto "aceptado o no aceptado". Los inspectores de calidad comprobaban si los productos cumplían determinados requisitos, rechazando aquellos que no superaban la correspondiente inspección. Sus características son:


38

o o o o o

o o

3.2.

El objetivo principal es la detección de errores. Su visión de la calidad es un problema a resolver. Pone el énfasis en la uniformidad del servicio. Emplea métodos de fijación de estándares y medición. El papel de los profesionales de la calidad es de inspección, clasificación, conteo y medición. La responsabilidad de la consecución de la calidad es del departamento de inspección. Su orientación y enfoque es que la calidad se comprueba. Control de la calidad

Hacia 1924 se establecen las bases del Control Estadístico de la Calidad, que recibe su confirmación durante la Segunda Guerra Mundial, contribuyendo a la producción de guerra que facilitaría el triunfo a los Aliados. Las características son: El objetivo principal es el control para detectar errores en los productos terminados. Su visión de la calidad sigue siendo un problema a resolver. El énfasis sigue estando en la uniformidad del servicio, pero reduciendo la inspección. Sus métodos son herramientas y técnicas estadísticas. El papel de los profesionales de la calidad es de resolución de problemas y aplicación de métodos estadísticos. La responsabilidad de la consecución de la calidad es de los departamentos de calidad y de los inspectores. La orientación y enfoque se basa en que la calidad se controla. Su filosofía es clasificar los productos en función de su calidad intrínseca. Su alcance se relaciona exclusivamente con el producto final. Las referencias escritas son las especificaciones del producto. La formación del personal queda limitada a los inspectores. El coste de la calidad se debe al rechazo de productos ya terminados, no recuperándose su coste de producción. A los proveedores prácticamente no se les presta ninguna atención. Las únicas normas existentes son las especificaciones del producto. La calidad se obtiene por comparación de las especificaciones con el resultado del control del producto terminado.


39

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


40

3.4. Gestión de la Calidad Total Un grupo de empresas europeas pensó, a mediados de los años ochenta en obtener una ventaja competitiva por medio de la Gestión de la Calidad Total (TQM) y crearon la Fundación Europea para la Gestión de la Calidad (EFQM). Esta gestión no se basa en normas sino en modelos como el Premio Malcom Baldrige, el Premio Deming o el Modelo Europeo (modelo EFQM). Sus principales características son: Su objetivo principal es el impacto estratégico. Su visión de la calidad cambia del problema a una oportunidad de ventaja competitiva. Su énfasis se pone en el mercado y las necesidades de los clientes. Sus métodos son la planificación estratégica, la fijación de objetivos y la movilización de la organización. El papel de los profesionales de la calidad se centra en la fijación de objetivos, formación, coordinación entre los departamentos y diseño de programas. La responsabilidad de la consecución de la calidad es de todos los miembros de la empresa bajo el liderazgo activo de la dirección. La orientación y el enfoque se basa en que la calidad se gestiona. Su filosofía se basa en dirigir la organización, con colaboración de los empleados, hacia la mejora de los productos. Su alcance es la Gestión por Procesos de todo lo que se hace en la organización. Las referencias escritas, además de todas las anteriores, incluyen las expectativas de los clientes, las políticas de calidad, los objetivos estratégicos, la participación de los empleados, la relación con la comunidad, etc. La responsabilidad de la gestión es de todo el equipo directivo y de los mandos intermedios. El control de costes se dirige a reducir el coste mediante la eliminación de todos aquellos elementos y procesos que no añaden valor, desde el punto de vista del cliente interno y externo. El proveedor constituye un eslabón más en la cadena de valor, por lo que hay que establecer con él una relación de confianza para conseguir una Calidad Concertada.


3.5.

41

Evolución del concepto de calidad

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

Tabla l. l. Evolución de la calidad en la empresa.

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


42

4.1.

Artesanos y Obreros

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

4.2.

Los orígenes

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


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 fácil conocer cuándo y dónde se produjo la evolución desde una actitud hacia la otra. Jerry ~ a n k s ' ' apunta "la existencia de conscientes esfuerzos en el control de la calidad"I6 en tiempos de la construcción de las pirámides de Egipto, por lo que podemos considerar esta época como referencia temporal básica para esta disciplina. La Grecia clásica o el antiguo imperio romano han dejado muestras evidentes del nivel de calidad alcanzado en sus obras de ingeniería o arquitectura. Aun, hoy en día, podemos disfrutar de la simbiosis de técnica y belleza que sus construcciones nos ofrecen. En la Edad Media y hasta finales del siglo XIX el suministro de servicios y la producción de bienes se encontraban esencialmente limitados a individuos aislados, como máximo a un grupo formado por algunas pocas personas. Este colectivo era quien controlaba la calidad del artículo haciendo las funciones de productor e inspector. El resultado de esta actitud es que los estándares de calidad eran 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 protección y provecho económico y social de sus miembros. Regulaban las economías locales urbanas estableciendo monopolios sobre el comercio, manteniendo servicios estables sobre condiciones estables y especificando estándares de calidad sobre las cosas. "Esta regulación de las actividades manufactureras (por parte de los gremios) puede haber sido uno de los primeros esfuerzos en el control de la calidad.17" "Los consumidores se vieron beneficiados por una parte, porque la existencia de los gremios garantizaba una alta calidad de los productos.ls " 4.3.

La Revolución Industrial: la inspección

El advenimiento de la industrialización, a finales del siglo XVIII, supuso profundos cambios sociales y económicos generados por 'un proceso técnico. Prácticamente desaparecen los pequeños talleres artesanales y se forman grupos de trabajadores más numerosos con atribuciones específicas o similares. La l5 Banks, Jeny. Profesor de la Escuela Industrial y de Sistemas Ingenieriles perteneciente al Instituto Tecnológico de Georgia. Experto en sistemas de simulación informática. Consultar la Encyclopedia of Software Engineering, John Wiley & Sons, 1994. Jerry Banks. Principies of quality control. John Wiley & Sons, 1989. Pág. 4. La traducción es nuestra. " Banks, Jeny., op. cit. pág. 6. La traducción es nuestra. '* Consultar "gremio" en la enciclopedia Salvat Universal. Barcelona. 1996.


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 tenía la misión de controlar el trabajo de los empleados. Por otro lado el dueño de la fábrica, aún presente físicamente en la misma, elige estándares y claves relacionadas con el control de la calidad. A medida que transcurre el siglo XIX, avanza la complejidad de las manufacturas, las industrias crecen y la técnica progresa. Las organizaciones consideran la necesidad de incluir en sus plantillas individuos que, aunque no envueltos de forma directa en el proceso productivo, inspeccionen la calidad del producto. 4.4.

De 1900 a 1950: la era del control estadístico

En 19 11 Taylor en su obra Principios de la dirección cientzjica propone la separación entre la dirección de la empresa y los trabajadores mediante la fórmula: "La dirección debe definir la tarea de cada uno de los operarios especificando el método que deben de usar y cuantificando el tiempo que deben emplear en realizarla." La organización "taylorista" de la producción se extiende rápidamente. El proceso de producción se descompone en una serie de sencillas tareas y cada operario sólo realiza una de ellas y, por lo tanto, de una forma fácil. La duración de la formación del personal es relativamente corta y se puede atender rápidamente los aumentos de producción mediante la contratación de nuevo personal. Los precios de los productos bajan y se hacen asequibles a una gran masa de usuarios, aunque éstos no son tenidos en cuenta en el diseño de los productos. La empresa ofrece el producto que considera satisface las necesidades de los usuarios y a éstos, como la oferta es inferior a la demanda, no les queda otra solución que comprar lo que hay en el mercado. Como la organización de la empresa es funcional, sólo los directivos de mayor nivel de cada función tienen una visión global del proceso. Lo que obliga a comprobar que el producto obtenido al final de una fase satisfaga las condiciones de entrada de la fase siguiente. De ahí que las tareas deban de ser supervisadas y los productos resultantes controlados. Nace así el departamento de control de calidad y sus operarios, los inspectores como supervisores de si el producto "pasa o no-pasa", con el fin de eliminar los no aptos. La calidad se centra en el producto. En 1918, Henry Ford fue de los primeros en aplicar técnicas de control de calidad, mejorando y estandarizando los procesos. Las materias primas se


45

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

46


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

El aseguramiento de la calidad: aparecen las normas

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


47

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

48


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

La Industria del Software y la industria tradicional

El desarrollo de programas para ordenador es una industria joven que ha evolucionado rápidamente aplicando en pocos años prácticas propias del control de calidad que otras disciplinas han madurado durante décadas. Tal como Marciniak nos indica: "Una diferencia principal entre la industria del software y otras industrias, es que la industria del software es relativamente muy joven. Intenta alcanzar en 30 años un estado de madurez para el que otras industrias han necesitado alrededor de 200 años." Por otro lado es evidente la influencia de la industria tradicional sobre la industria del software. Por ello no podemos obviar acontecimientos, que si bien parecen no tener relación con el proceso de creación de programas informáticos, han supuesto una referencia importante para el mismo. La tabla 1.2, propuesta


49

también por Marciniak, pone de manifiesto esta relación, comparando las diferentes fases superadas por el control de calidad y su aplicación por parte de la industria en general, y la industria del software.

Etapa ---

Descripción .-

Industria del Industria en Software general Años sesenta Antes del siglo XIX

Artesanos

Se fían de la creatividad y del buen trabajo artesanal

Inspección

Supervisores inspeccionan la calidad antes de la liberación de producto

Años setenta

Siglo XIX

Control estadístico del proceso

Cuantificación de la calidad del producto; técnicas de muestre0

Pocas evidencias de uso

Años treinta

Aseguramiento de la calidad

Uso de estándares en los sistemas de calidad para los procesos

Años ochenta

Años cincuenta

Conformidad con la calidad

Calidad total: se eliminan derroches y minimizan costes

Años noventa

Años ochenta

Calidad dirigida al cliente

Calidad total dirigida hacia el cuidado del cliente y del servicio

Años noventa

Calidad dirigida al mercado

Calidad total dirigida hacia el cliente existente así como a clientes en

Pocas evidencia de uso Pocas evidencias

Algunas evidencias

Tabla 1.2. Las etapas de la calidad. 4.8.

Orígenes del aseguramiento de la calidad del software

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


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 administración. Los puntos más importantes eran:

-

-

Métodos a utilizar por el contratista para evaluar diseño y documentación. Aprobación interna del trabajo. Documentación de los estándares del gobierno norteamericano para un trabajo desarrollado bajo contrato con el mismo. Biblioteca sobre los procedimientos de control para código y datos relacionados. Revisiones y auditorias, especialmente para asegurar que el software ha seguido sucesivos estados en su desarrollo. Control de los subcontratistas del software. Pruebas, incluyendo planes, análisis de las especificaciones externas que aseguran la verificación, criterios de esas pruebas, control de las pruebas, certificación de los resultados, revisión de la documentación de las pruebas.

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


51

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

l9 Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineenng, John Wiley & Sons, 1994. Pág. 942. La traducción es nuestra.

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 estándares de gran influencia, no sólo en el ámbito militar, sino en numerosos aspectos de la vida civil. En 1979 el Ejército de Tierra norteamericano auspició unas jornadas en la Escuela de Postgrado de la Marina en Monterrey, California. El resultado de estas reuniones fue enormemente fructífero pues se establecieron las bases de la que más tarde sería la normativa denominada 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 configuración y administración y que los componentes del desarrollo son evaluados con respecto a la calidad y que el producto final está apropiadamente cualificado para su uso. Es interesante apuntar que a los primeros borradores de este proyecto se le llamó "Medida y Aseguramiento de la Calidad del Software", y enfatizaba en evaluar si el proceso de desarrollo del contratista era adecuado para producir un software de calidad. Por otro lado, esta norma en ninguna parte requiriere de forma expresa que el contratista posea una organización de aseguramiento de calidad del software. El proceso de creación de este estándar se alargó hasta 1988. Aunque en los setenta y en los ochenta el aseguramiento de la calidad del software se habían establecido en compañías de software empotrado, esta disciplina había empezado a encontrar un hueco en sistemas de programación y sistemas de administración de la información, que incluía la programación de aplicaciones de uso comercial. La pobre calidad con la que muchos programas llegaban a la fase de ejecución era debido a la falta de un adecuado programa de prueba. "Era frecuente para algunos desarrolladores considerar el software listo para su uso si el programa podía ser compilado y cargado.20" No sorprende, por tanto, que el aseguramiento de la calidad en el software se dirigiera hacia un incremento en las pruebas. Verificación y validación fue otro significado a menudo adscrito al aseguramiento de la calidad en el software.

20

Robert H. Dunn. "Quality Assurance", Encyclopedia of Software Engineering, John Wiley & Sons, 1994. Pág. 945. La traducción es nuestra.


53

4.10. Análisis de los atributos

A mediados de los ochenta, el concepto asociado al aseguramiento de la calidad se asoció a tres significados diferentes:

-

Una aproximación comprensiva a la mejora del software, proceso de programación y control del proyecto software. Pruebas. Verificación y validación.

En los ochenta el primero de estos tres conceptos incrementó el énfasis del análisis de los atributos de la estructura del software así como en la acumulación y análisis de los datos asociados a los errores. Es aceptado que la permanencia de los errores en el proyecto software incrementa dramáticamente su presencia a medida que el error permanece más tiempo en dicho proceso. La práctica de la colección y análisis de datos se desarrolló en el ámbito del aseguramiento de la calidad. La dependencia de los datos es intrínseca al concepto de control de la calidad total y es la sustancia de una de las siete categorías de criterios del Premio Nacional de Calidad Malcolm. Una variación de este primer punto asociado al aseguramiento de la calidad del software, influenciado por el concepto de calidad total, supera la confusión entre organización-administración. "El aseguramiento de la calidad del software no asegura la calidad del software; asegura la planificación y ejecución de un programa de calidad que envuelve tres elementos tecnología, persona y administración, tres partes que finalmente actúan rec~rsivamente.~'" 4.11. Los modelos

En la actualidad existen modelos de uso habitual en las empresas de software que han influido enormemente en el proceso de implantación de la calidad en el desarrollo de programas informáticos. Más adelante haremos un estudio detallado de alguno de ellos. El Instituto de Ingeniería del Software, más conocido por su acrónimo inglés SE1 (Software Engineering Institute) ideó un marco de referencia para el proceso de creación del software como respuesta al requerimiento de gobierno

''


54


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


55

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

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


56

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

5. CONCEPCIONES ERRÓNEAS Y PARADIGMAS DE LA CALIDAD

A pesar de la mayor sensibilización hacia la calidad, todavía existen ideas erróneas que van en detrimento de la obtención de productos de calidad. Entre ellas destacaremos: o 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 administración. La calidad es responsabilidad únicamente del Departamento de Calidad.

En general, estas concepciones configuran un paradigma del enfoque antiguo que es necesario cambiar hacia las nuevas ideas que consideran la calidad como una estrategia global de negocio e instrumento de la gerencia. Los cambios de estos paradigmas son los siguientes:


o

o

o

o

o

o

57

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

6. COSTES DE LA CALIDAD

La implantación de un sistema de calidad conlleva unos costes que, a medio y largo plazo, revierten en ahorros y beneficios, tanto tangibles (económicos) como intangibles. La figura 1.3 representa como se descompone el precio del producto entre los diversos costos y el beneficio.

Figura 1.3. El coste de un producto.


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 prevención y los costes de la inspección o costes de evaluación. Como puede deducirse de la figura para aumentar el beneficio es necesario reducir principalmente los costes de la no calidad. 6.1. Costes de prevención

Son los costes en que se incurren para evitar la comisión de errores en cualquier función de la empresa, desde el diseño a la venta, pasando por administración, personal, producción, etc. Algunos de estos costes son: revisión del diseño, programas de formación, evaluación de proveedores, revisión de especificaciones, mantenimiento preventivo, etc. En contra de lo que generalmente se cree, la mayoría de los fallos tienen su origen en el equipo directivo, hasta un SO%, como se indica en la figura 1.4.

Equipo directivo: 80%

Mantenimiento Planes de formación

\

/

Trabajo

\ /

Operario: 20%

Figura 1.4. Origen de los fallos en una organización.


6.2.

59

Costes de evaluación

Incluye todos los gastos relacionados con la inspección de la producción ya terminada y de las auditorías sobre la conformidad de las funciones con los criterios y procedimientos establecidos. Por ejemplo: las inspecciones, las pruebas, el control de recepción de los productos de los proveedores, la aceptación del producto, el estudio del cumplimiento con las especificaciones, etc. 6.3.

Costes de la no calidad

Son todos los costes relacionados con los errores de producción. Antes o después de su entrega al cliente, incluyendo las acciones correctiva, la garantía o la pérdida de confianza del cliente. Según estudios de Arthur Andersen, la falta de calidad provoca las siguientes consecuencias negativas para la empresa:

o o o

o 6.4.

Cuesta cinco veces más obtener un cliente nuevo que retener a uno antiguo. Sólo el diez por ciento de los clientes que han tenido una mala experiencia vuelve a repetir la compra. Sólo el cuatro por cientos de los clientes defraudados se lo comunica al proveedor. Un cliente insatisfecho comenta su caso con, al mínimo, diez personas. Relación coste/beneficio

Según se aumenta la calidad del producto los costes de la no calidad disminuyen, pero al mismo tiempo el coste del sistema de calidad aumenta. El perfeccionismo resulta caro. El gráfico de la figura 1.5 muestra como el coste total mínimo de la calidad se alcanza en un punto lejos del 100% de la calidad. Muchas veces será necesario aumentar los costes para obtener una calidad aceptable por el cliente.


60

Costes

1

Costes no calidad

Calidad (%) Figura 1.5. Costes de la no calidad. Si se actúa de forma que se reduzcan las acciones no previstas es posible conseguir un ahorro potencial de los costes totales de la calidad y por consiguiente, un mayor beneficio, como puede observarse en el diagrama de barras de la figura 1.6.

COSTE f BENEFllrSIO

Figura 1.6. Relación costeheneficio de la calidad.


6.5.

61

La Regla Federal Express

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

Capítulo 2 LA MEDIDA DE LA CALIDAD DEL SOFTWARE Una diferencia principal entre una "bien desarrollada" ciencia como la física y algunas de las menos "bien desarrolladas" ciencias tales como la sicología o sociología es el grado en el cual las cosas son medidas.'

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

A mediados de la década de los sesenta el desarrollo de programas para ordenador presentaba serias disfunciones. Pobre calidad en los sistemas, aplicaciones entregadas fuera de plazo y con numerosos errores y elevados costes de mantenimiento eran hechos que se repetían con demasiada asiduidad

' Roberts, Fred S. Measurement Theory with Applications to Decisionmaking, Utility, and the Social Sciences. Encyclopedia of Mathematics and its Applications. Addison Wesley Publishing Cornpany, 1979. Roberts, Fred S. Director del Centro de Matemáticas Discretas y Teoría de la Ciencia Computacional, consorcio formado por las universidades de Rutgers y Princenton junto a diversas empresas tecnológicas (AT&T, Lucent Technologies, NEC, entre otras). Consultar la dirección de intemet http:// dimacs.mtgers.edu/index.html.

LA MEDIDA DE LA CALIDAD DEL SOFTWARE

64

[Marciniak, 19941. La situación era de tal gravedad que la Organización del Tratado del Atlántico Norte (OTAN) patrocinó en otoño de 1968 una conferencia internacional en Garmisch-Partenkirchen, Alemania, en la que se dieron cita medio centenar de los más afamados estudiosos de la disciplina informática. Esta convención supuso uno de los más importantes hitos en la moderna historia del software. En ella no sólo se reconoció el estado de crisis en el que se encontraba el desarrollo de programas para ordenador, sino que también se aportó la solución. En 1968 se acuñó el concepto de "ingeniería del software" como una nueva disciplina al servicio del desarrollo estructurado y metodológico de los programas informáticos. La unión de estas dos palabras "ingeniería" y "software'', no fue un hecho espontáneo, tal y como reconocieron los propios organizadores. En las actas se recogen diferentes apreciaciones en este sentido, siendo una de las más explícita la cita siguiente: "La frase "ingeniería del software" fue deliberadamente escogida por provocadora, dando a entender la necesidad de que la manufactura del software se base sobre tipos de fundamentos teóricos y disciplinas prácticas, que son tradicionales en ramas establecidas en la ingeniería."2 Más de veinte años después Norma E. Fenton se cuestiona ''¿Algo ha ido mal o esperamos demasiado, demasiado pronto?"3. Esta pregunta se justifica, cuatro lustros después de la conferencia de Garmish, en la situación en la que el desarrollo s ~ de forma de programas para ordenador se encuentra sumido y que ~ i b b ilustra contundente: "... por cada seis nuevos sistemas de programación de gran tamaño que entran en servicio, otros dos quedan cancelados. Los proyectos de desarrollo de programas de tamaño medio suelen consumir vez y media el tiempo previsto, situación que empeora en los grandes. Y alrededor de tres cuartas partes de todos los sistemas de gran tamaño son "fracasos operativos", lo que significa que o no funcionan como se quería o no se utilizan para nada."5

James E. Tomayco. "Milestones in Software Engineering", Encyclopedia of Software Engineering, John Wiley & Sons, 1994. pp. 687-697. La traducción es nuestra.

Fenton, Norman E. Sojiware Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. Pág 5 . La traducción es nuestra. Gibbs, W. Wayt. Licenciado en Física e Inglés por la universidad de Comell, afamado articulista de Scientijc American, ha publidado numerosos artículos sobre el software y ciencias afines. Ha desarrollado labores de investigación en nanotecnologia y biotecnologia en el MIT. Consultar http:l/web.mit.edu/knight-sciencel Gibbs, W. Wayt. "La crisis crónica de la programación", Investigación y Ciencia, Tendencias en Informática. Pág. 73.


65

2. NECESIDAD DE LA MEDIDA DEL SOFTWARE 2.1.

La medida como elemento de mejora metodológica

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

Fenton, Norman E., op. cit. pág. 5. La traducción es nuestra.

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


66

al Software Engineering Laboratory (SEL), afirmó "no deberíamos preguntarnos por más tiempo si debemos medir, la cuestión hoy en día es cómo."" 2.2.

La medida y el conocimiento

Las ciencias empíricas, junto con las diferentes ingenierías, poseen en el proceso de medida una larga tradición y fundamentado conocimiento, alcanzado gracias a siglos de investigación y aportaciones de eminentes científico^'^. La trascendencia que a esta actividad se le ha conferido queda patente en actitudes reflejadas en citas como aquella que ilustra este capítulo, u otras de no menos compromiso o rotundidad. Lord Kelvin, el famoso matemático y físico británico, a finales del siglo pasado sentenciaba: "Cuando puedes medir aquello de lo que hablas, y expresarlo en números, tú conoces algo acerca de ello; pero cuando no puedes medirlo, cuando no puedes expresarlo en números, tu conocimiento es insatisfactorio y escaso: podría ser el comienzo del saber, pero apenas has avanzado en tus ideas hacia un estado ~ientífico"'~. Medir es conocer, y este conocimiento nos permite avanzar sobre bases sólidas. Pero medir nos proporciona algo más, nos posibilita aplicar las poderosas herramientas que las matemáticas nos ofrecen, facilitando la manipulación de datos con objeto de alcanzar una visión de la entidad estudiada que de otra forma hubiera sido imposible obtener.

2.3.

Importancia de la medida

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


67

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

l 4 Black, Joseph. Químico y fisico escocés del siglo XVIII. Entre otras aportaciones descubrió el calor latente y el calor especifico. Consultar enciclopedia Salvat Universal. Barcelona. 1996. l 5 Joule, James Prescott. Físico británico del siglo XIX. Estableció la teoría mecánica del calor. Consultar enciclopedia Salvat Universal. Barcelona. 1996.


68

3.1.

Definición y problemática

La estimación es el proceso de predicción de la duración, esfuerzos y costes necesarios para realizar todas las actividades y obtener todos los productos asociados a un proyecto. Es necesario tener en cuenta numerosos aspectos que afectan a la estimación como la complejidad del proyecto, su estructuración, el tamaño, los recursos involucrados y los riesgos asociados. La estimación es siempre difícil de realizar por diversas razones, entre las que se encuentran: No existe un modelo ni una fórmula de estimación universal. Son muchas las personas implicadas en el proyecto, desde la alta dirección de la empresa a los ejecutivos del proyecto, que precisan de las estimaciones. La utilidad de una estimación varia con la etapa de desarrollo en que se encuentra el proyecto. Las estimaciones precisas son difíciles de formular, sobre todo al inicio del proyecto. La estimación suele hacerse superficialmente, sin tener en cuenta el esfuerzo necesario para hacer el trabajo. La rapidez del cambio de las metodologías y las tecnologías no permiten la estabilización del proceso de estimación. Los estimadores pueden no tener experiencias. El estimador suele hacer la estimación en función del tiempo que a él le llevaría en realizar el trabajo, sin tener en cuenta la experiencia y formación de la persona que realmente lo realiza. Existen malas interpretaciones en las relaciones lineales entre la capacidad requerida por unidad de tiempo y el tiempo disponible. Como consecuencia se cumple una de las leyes de Murphy, que dice "la duración del trabajo se ajustará como mínimo al tiempo disponible. Añadir recursos un proyecto retrasado, no tiene por qué disminuir el retraso." El estimador tiende a reducir en alguna medida sus estimaciones para hacer mas aceptable su oferta.


69

3.2. Los métodos de estimación

Además de los métodos algorítmicos se suelen utilizar por su sencillez los siguientes: El juicio del experto

La realidad indica que el método utilizado en gran parte de los proyectos software, y en numerosas empresas en el momento de estimar el coste de los desarrollos se basan principalmente en juicios emitidos por uno o varios expertos avalados por su experiencia en entornos similares y apoyados, aunque no en todos los casos, en datos objetivos obtenidos de proyectos anteriores y almacenados en bases de datos históricas. El método de Wideband Delphi es una aproximación que se puede definir como un protocolo multipaso cuyo fin es hacer coincidir la opinión de un grupo de expertos evitando así estimaciones parciales de individuos aislados. Los pasos a ejecutar serían: 1. El coordinador del equipo técnico de expertos presenta a cada uno de ellos una especificación de estimación. 2. El coordinador convoca una reunión con el grupo de expertos para que se produzca un intercambio de opiniones entre ellos sobre el producto y sus estimaciones. 3. Cada experto aporta su estimación. 4. El coordinador remite a cada experto un informe con el valor medio de las estimaciones obtenidas así como el valor propuesto por cada individuo. 5. Se convoca una segunda reunión entre expertos. 6. Los expertos vuelven a emitir sus estimaciones de forma independiente. 7. Se repiten los pasos 2 al 6 hasta la obtención de un valor en el que todos los expertos estén de acuerdo. Este método tiene como desventaja evidente el alto coste en tiempo y recursos humanos necesarios para su implantación, así como la subordinación al nivel de experiencia y conocimientos en el entorno que puedan aportar los técnicos. Como ventajas se podrían indicar que las estimaciones parciales son neutralizadas y se presenta una estimación global. Por otro lado las estimaciones suministradas por este grupo de expertos difícilmente pueden ser obviadas gracias a la trascendencia que la organización otorga a este proceso al proporcionar costosos recursos a esta tarea.


70

La analogía Se hace la estimación de un proyecto nuevo por analogía con las estimaciones de proyectos anteriores comparables y que estén terminados. La ley de Parkinson En 1987, C. N. Parkinson formuló unas leyes que, reformuladas, se pueden aplicar a la ingeniería del software. Una de ellas dice "los programas son como los gases perfectos, ocupan todo el espacio que se les da". Esto significa que la estimación del esfuerzo se hace en base a los recursos disponibles y no al producto. La mejor oferta Se procura conocer hasta cuánto el cliente está dispuesto a pagar y cuáles son las ofertas de la competencia. El valor que permite lograr el proyecto se toma como estimación del esfuerzo. Las estimaciones global y detallada La estimación global, también denominada descendente, se hace teniendo en cuenta las funcionalidades del producto, pasándose posteriormente al detalle. La estimación detallada o ascendente empieza por la estimación de los esfuerzos individuales, los cuales se suman para obtener el esfuerzo del proyecto. Tiene el peligro de olvidarse de las tareas generales. 3.3.

Las reglas de estimación de De Marco

De Marco formuló las siguientes nueve reglas, relativas a la estimación: 1. Estimar no es repetir.

2. Estimar no es negociar. 3. Las estimaciones no admiten regateo. 4. Estimar no es dividir en partes una duración fija. 5 . Un retraso en una fase de un proyecto implica un retraso proporcional en todas las fases siguiente. 6. Si desea que se le proporcione una estimación significativa, no sugiera la respuesta. 7. Una estimación útil es una proyección en la que la probabilidad no es optimista ni pesimista.


71

8 . El ratio entre la estimación más optimista y la útil es medianamente uniforme para cualquier persona. 9. Las estimaciones deben formularlas un comité. 3.4.

Evaluación de las estimaciones

Una primera evaluación de una estimación sería la diferencia entre el esfuerzo estimado y el real. Pero un error de, por ejemplo, 5 horas-hombre en un proyecto de 1000, no es el mismo que en un proyecto de 20.000 horas-hombre. Por consiguiente se suele utilizar el test de porcentaje de error dado por la fórmula: (Estimado - Real) 1 Real Hay que tener en cuenta que los errores pueden ser de infravaloración o de sobrestimación, cuya importancia sigue la ley de Brooke, en el primer caso, y la de Parkinson, en el segundo. Los dos tipos de errores no se anulan uno al otro cuando se hace la media de numerosos errores.

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


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 serán necesarios datos de diferente naturaleza tal y como observaremos en los modelos que se explicarán. Como paso previo a su estimación definamos estos atributos. El esfuerzo se entiende como el tiempo necesario para la realización de una cierta tarea por parte del equipo de desarrollo. Suele venir expresados en hombre-

mes. El coste se encuentra relacionado directamente con el esfuerzo de cada tarea aunque en este caso se exprese en términos económicos. 4.2.

Los principales modelos

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

COCOMO

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

73


El modelo COCOMO se basa en la existencia de tres niveles que han de aplicarse según el estado en que se encuentre el desarrollo del proyecto. Modelo básico. Se utiliza al principio del proyecto. La información que facilita es una estimación en cuanto al orden de magnitud del esfuerzo. Las ecuaciones que rigen este modelo son:

E = a (KLOC)~ T = C E ~

Ecuación 2.1 Ecuación 2.2

Donde E es el esfuerzo expresado en personas-mes, el número de líneas de código estimadas excluyendo comentarios (en miles) viene indicado por KLOC. Los valores a, b, c, d son valores constantes (tabla 2.1) que dependen de la clase de proyecto o "modo" que estemos evaluando. El valor T representa el número de meses estimados para el desarrollo.

Tabla 2.1. COCOMO básico.

Los posibles modos son: Orgánico. Equipos pequeños de trabajo. Existe un buen conocimiento de la aplicación y del sistema utilizado. Poca influencia de las comunicaciones. Semiacoplado. Se sitúan en una posición media en cuanto a complejidad y tamaño, entre el modo Orgánico y el Integrado. Equipo formado por expertos y principiantes. Se han de satisfacer requisitos no excesivamente estrictos. Por ejemplo aplicaciones bancarias o que impliquen transacciones con bases de datos. Integrado. Sistema hardwarelsoftware complejo con influencia clara de la seguridad o tiempo real. Costes de validación muy elevados. Requisitos estrictos e inamovibles. Un ejemplo claro lo tendríamos en el software de control de un sistema de defensa o de una central nuclear.


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, métodos y personal). Lo valores de las constantes también se ven afectadas. En este caso la ecuación es:

E = a ( K L D C )m(x) ~

Ecuación 2.3

Donde E, KLOC, a y b tienen el mismo significado que en el caso del COCOMO básico. Aunque el valor de los parámetros a y b son diferentes (tabla 2.2). El valor m(x) es el peso del factor de coste xj, y cuya expresión matemática es: 15

m(x)=n

Ecuación 2.4

El valor m(x) en el caso del modelo básico tiene como valor fijo la unidad. Boehm consideró quince factores de coste diferentes, agrupados según el siguiente esquema. 1 . Atributos del producto. 1 . 1 . Fiabilidad requerida. 1.2. Tamaño de la base de datos. 1.3. Complejidad del producto. 2. Atributos de los recursos. 2.1. El material. 2.1.1. Restricciones del rendimiento en tiempo de ejecución. 2.1.2. Restricciones de memoria. 2.1.3. Inestabilidad de la máquina virtual. 2.1.4. Tiempo de espera requerido. 2.2. El personal. 2.2.1. Capacidad de análisis. 2.2.2. Capacidad del ingeniero de software. 2.2.3. Experiencia en aplicaciones. 2.2.4. Experiencia con máquina virtual. 2.2.5. Experiencia con lenguaje de programación. 2.3. Métodos y herramientas. 2.3.1. Práctica de los métodos modernos de programación. 2.3.2. Utilización de herramientas de software.


75

2.4. Tiempo. 2.4.1. Planificación temporal del desarrollo requerida. Cada factor es valorado por separado en una escala ordinal de seis puntos (muy bajo/bajo/nominal/alta/rnuy altalextra alta). A partir de las tablas hechas públicas por Boehm se asigna un valor numérico a cada factor y se aplica la ecuación 2.4, el resultado es el factor de ajuste del esfuerzo.

Tabla 2.2. COCOMO intermedio. %

COCOMO detallado. El modelo de COCOMO detallado se basa en dividir el esfuerzo en fases, de forma que para cada una de ellas se obtenga el factor de coste correspondiente. Finalmente se ha de sumar cada uno de ellos para obtener el global. Como guía para el uso del modelo COCOMO, en cualquiera de sus variedades, podemos indicar los siguientes pasos a seguir: 1. Identificar el "modo" de desarrollo para el nuevo proyecto. 2 . Estimar el tamaño del proyecto en KLOC y derivar una predicción del esfuerzo. 3. Determinar el valor de los 15 valores de ajuste. 4. Hacer uso de la ecuación de estimación del esfuerzo. 5. Hacer uso de la ecuación que estima el tiempo de desarrollo.

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


76

4.4.

SLIM

El modelo de Putnam, Slim, se apoya en que la distribución del esfuerzo en un proyecto software viene especificado por la denominada curva de RayleighINorden. Esta curva se obtuvo basándose en datos recopilados por Norden y las descripciones analíticas de las curvas realizadas por Lord Rayleigh. Putnam propuso la siguiente "ecuación del software".

L = CkK113 td413 Ecuación 2.5 Donde L es el número de líneas de código esperadas en magnitudes de sentencias fuente, Ck es una constante dependiente del nivel tecnológico en el que se desarrolla la aplicación, suele obtenerse gracias a datos históricos recopilados de desarrollos anteriores. El factor K es el esfuerzo de desarrollo expresado en personas-años y finalmente tdes el tiempo de desarrollo expresado en años. De la ecuación 2.5 podemos obtener fácilmente la ecuación: ',

K

=

L ~(ck3 / td4) Ecuación 2.6

De esta segunda ecuación podemos deducir interesantes conclusiones. El factor td al estar afectado por una potencia tal alta indica que pequeñas variaciones en el tiempo de entrega pueden modificar enormemente el esfuerzo a realizar. Por otro lado también observamos la dependencia de este modelo del valor asociado a Ck , hecho que gran cantidad de especialistas consideran una desventaja, ya que pequeñas modificaciones en este valor implican grandes modificaciones en el valor del esfuerzo.

Tabla 2.3. Algunos valores de Ckpropuestos por Pressman.

Putnam definió la denominada aceleración de la potencia de trabajo como D , = K I ~ ~ ~

Ecuación 2.7

LA CALIDAD DEL SOFTWARE Y S U MEDIDA

77

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

Q

1

2

3

4

Figura 2.1. Aproximación a las Curvas de Rayleigmorden.

5


78

MEDIDA

5.

5.1.

Definiciones

Se encuentran diferentes definiciones que identifican la actividad de medir. De entre todas ellas la más adecuada es la propuesta por Norman E. ent ton'^ que define la accióp de medir de la siguiente forma:

o Medir. Proceso a través del cual números o símbolos son asignados a atributos de entidades en el mundo real de tal manera que los describe de acuerdo a reglas claramente dejinidas17 De igual manera se define el resultado de este proceso, es decir, la medida como: o Medida. Una medida es una asignación objetiva y empírica de un número (o símbolo) a una entidad para caracterizar un atributo especifico".

Se puede clasificar las medidas realizadas en dos tipos bien definidos, medidas directas y medidas indirectas. Se definen de la siguiente manera: o Medida directa. La medida directa de un atributo es una medida que no depende de medidas de otros atributos. o Medida indirecta. Medida indirecta de un atributo es aquella que involucra la medición de otros atributos (uno o varios) 19.

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

79


o Métrica. La caracterización numérica de un atributo "simple" en contraposición al concepto de medida, entendido como función cuyos parámetros serán las métricas obtenidas y que nos permitirán estudios de atributos más complejos20. Evidentemente en el entorno de la medida del software el concepto "métrica" no tiene relación con el concepto asociado al espacio métrico propio de la topología en las matemáticas. Las definiciones anteriores unidas a la teoría representacional de la medida que a continuación introduciremos nos permiten definir un marco teórico apropiado del que luego haremos uso para ajustarlo definitivamente al medio informático. 5.2.

Teoría general de la medida

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

c (C, R) siendo: C: Sistema de relación empírico. C: Conjunto de las entidades consideradas. R: Conjunto de relaciones observadas sobre las entidades.

Así, por ejemplo, podríamos considerar un conjunto de entidades y relaciones de la siguiente manera:

20



80

donde las relaciones involucrarían elementos del conjunto C.

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

Matemáticamente:

N CN, P) siendo:

N: Sistema de relación numérico. N: Conjunto de números considerados. P: Conjunto de relaciones observadas sobre el conjunto N. Siguiendo con el ejemplo anterior, debemos definir el sistema de relaciones numéricas en función al sistema empírico.

donde las relaciones involucrarían elementos del conjunto N.


81

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

En diagramas de Venn y considerando los ejemplos indicados arriba, la correspondencia podría expresarse:

Figura 2.2. Diagrama de Venn para la relación M.

La condición de representación requiere que medir sea el establecimiento entre entidades en C y números, de tal forma que las relaciones en C inducidas por el atributo impliquen y sean implicadas por las relaciones entre sus imágenes en el conjunto de números elegidos. La condición de representación puede ser vista como la definición formal de aquello que nosotros queremos hacer significar a través de la medida, describiendo o caracterizando un atributo.

82

5.3.


Escalas

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

"F" asignación uno a uno M' = F(M) "F" monótona creciente. 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 más habituales.

Basándonos en los conceptos estudiados de escala describamos la noción de "significación" en el entorno de la medida de atributos. Esta definición será útil a la hora de establecer las limitaciones sobre el tipo de manipulaciones matemáticas a las que podemos someter los valores resultado de una medida realizada en el entorno de una determinada escala. Se dice que un enunciado que envuelve escalas numéricas es significativo si su verdad (o falsedad) permanece inalterable si cada escala M implicada es reemplazada por una escala aceptable M'. La relación M' es una escala aceptable si puede derivarse de la relación M por una transformación admisible.


6.1.

83

Los orígenes

El deseo de obtener valores numéricos que representan atributos propios del desarrollo y ejecución de programas para ordenador ha sido una aspiración para investigadores y estudioso desde hace más de treinta años. Uno de los primeros y principales trabajos que de forma más importante han influenciado en la teoría aplicada a la medida del software, fue publicado en 1964 por arquitecto británico Chistopher Alexander, lo tituló Notes on the Synthesis of Form. En su escrito Alexander describió la naturaleza del proceso de diseño según su óptica. Para este investigador un ingenio ha sido bien diseñado si los componentes que forman parte de él son relativamente independientes entre sí. Alexander finalizaba su escrito presentando un programa informática cuya aplicación sería ayudar a técnicos y profesionales en la tarea del diseño. Este programa aceptaba como datos de entrada las relaciones existentes entre los diferentes componentes del artefacto. Haciendo uso de un análisis en racimo proporcionaba como resultado un diseño en el que se pretendía minimizar en número de componentes del mismo. Como podemos apreciar la relación del trabajo de este arquitecto con la práctica informática se produce exclusivamente en el desarrollo del programa que ideó para ayudar a extender su visión en el diseño industrial. A pesar de este hecho, las propuestas de Alexander han sido uno de los pilares sobre los que se han apoyado investigadores que han apreciado en sus tesis una concepción adecuada para el proceso de creación de productos software. Más adelante, en este mismo capítulo, podremos apreciar hasta que punto las ideas de Christopher Alexander han condicionado la investigación de la medida del software. 6.2.

Maurice Halstead

Maurice ~ a l s t e a d fue ~ ' el primer investigador que de forma consistente propuso un proceso de medida para el software. Para ello se apoyó en diferentes fuentes teóricas, que van desde la sicología del conocimiento, teoría de la información o la termodinámica, hasta concretar un proceso de medida determinado. La filosofía básica en la que asentó su teoría fue que la comprensión del software era similar al proceso mental de manipulación de señales. Halstead definió un conjunto de medidas que pueden ser extraídas del código fuente del programa. Su influencia en

'' Halstead, Maurice H. Graduado en meteorología por la universidad de Berkeley en 1940, doctor por la universidad de Jonhs Hopkins de Baltimore, es considerado uno de los pioneros en el software para computadoras. Realizó importantes aportaciones en la métricas del software a las que inicialmente las denominó "Termodinámica del Software". Consultar el sitio www.itee.uq.eduíau.


84

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

o

o

o

Muchas de las asunciones sobre la sicología cognoscitiva en la que se basó Halstead se consideran ahora erróneas. Muchos de los experimentos realizados se encuentran pobremente diseñados y los resultados obtenidos poseían errores estadísticos. La teoria propuesta se basaba en medidas de carácter general, de forma opuesta a la actual consideración de medidas específicas que respondan a preguntas concretas. Las medidas propuestas se basaban en el código del programa, de forma preponderante. Este hecho supone un grado de limitación muy elevado para el programador, que tiene poca libertad de acción a la hora de alterar el curso del proyecto ya que muchos recursos han sido ya utilizados pues la aplicación ha pasado por varias fases que, quizás, deberían reconsiderarse. Las reglas de conteo de las que hace uso, no se encuentran totalmente definidas.

Estas deficiencias han llevado a que las medidas propuestas por Halstead hayan sido prácticamente eliminadas del contexto industrial, a excepción de algunos experimentos aislados. A pesar de esta afirmación hemos encontrado investigadores Baker, A.L. Matemático británico condecorado con la Medalla Fields en 1970 por su trabajo en el campo de la teoría de los números. Consultar el sitio hnp:l/www.britannica.com. 23 Zweben, Stuart. Profesor de la universidad del Estado de Ohio y responsable del Departamento de Ciencia de la Información y la Computación. Estudioso de la ingeniería del software, ha centrado sus estudios en la medida de la calidad del software. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994. 24 Curtis, Bill. Conocido internacionalmente por sus investigaciones sobre la medida del software, diseño de interfaces o factores humanos y de organización que afectan al proceso software. Doctor por la universidad Cristiana de Tejas, entre otros títulos, ha publicado casi un centenar de artículos y desarrollado su carrera en prestigiosos centros de estudio. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.

22


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 críticas que ahora recaen sobre su teoría. 6.3.

El control de flujo de programas

A mediados de la década de los setenta surgió un gran interés por la medida del software basado en el control de flujo de un programa o módulo. Este hecho coincidió con el auge de la programación estructurada como aproximación sensible al desarrollo detallado del diseño de módulos. En este contexto teórico un sistema un programa fácil de leer, desarrollar, mantener y corregir es aquel que se encuentra diseñado bajo un limitado número de estructuras de control. La medida clásica del control de flujo es la denominada "complejidad ciclomática". Esta medida fue desarrollada por el científico norteamericano internacionalmente conocido en el ámbito de la medida del software por sus aportaciones en este campo, Thomas ~ c ~ a bEsta e . es~ una ~ medida basada en una teoría gráfica, relacionada directamente con el número de "caminos" asociados a un programa o módulo. McCabe postuló que un valor elevado de la complejidad ciclomática de un grafo que representa un módulo o programa de forma directa, implicaría un grado elevado de dificultad en las propiedades de comprensibilidad y facilidad de prueba. La razón de este discernimiento es que un valor elevado en la complejidad ciclomática implicaría una densidad elevada de instrucciones tipo "IF, WHILE" o "REPEAT". La incidencia de estas construcciones es un mayor grado de dificultad a la hora de leer esos programas o probarlos, ya que implicarían un mayor número de caminos a explorar al realizar pruebas de datos. El trabajo de McCabe de 1976, es de obligada referencia en cualquier texto de ingeniería del software al ser uno de los modelos más originales y copiados de la historia de la medida del software. A pesar de este hecho han aparecido estudios críticos sobre la medida propuesta por McCabe. Se demostró que muchos de los experimentos eran estadísticamente sospechosos y que la complejidad ciclomática no proporciona mejores predicciones que aquellas que nos ofrece el modelo de las líneas de código. Esta afirmación se soporta sobre numerosas experiencias empíricas [Fenton, 19921. Existen, además, otras críticas realizadas hacia esta teoría gráfica. Por un lado la falta de trascendencia dada por este modelo a las condiciones de un módulo o programa. Así, por ejemplo, dos módulos con igual complejidad ciclomática son enormemente distintos debido al uso de múltiples operadores booleanos, expresiones aritméticas complejas o abuso de los "flags" en el programa. Otros de 25

MacCabe Thomas, J. Licenciado en matemáticas por las universidades de Privilence y Connecticut. Prestigioso consultor y autoridad en las áreas de la calidad del software, técnicas de validación y pruebas del software. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.

86


los problemas se encuentra -en el tratamiento de los datos. Dos programas pueden tener igual complejidad ciclomática, pero uno de ellos puede ser mucho más difícil de entender que el otro debido al número y extensión de las variables utilizadas por cada uno de éstos. A finales de los setenta y principio de los ochenta han aparecido algunas variantes del modelo de McCabe que intentaban superar estas críticas. Aparecen modelos que consideran el nivel de anidamiento o complejidad booleana o tienen en cuenta factores asociados a los datos tratados y de qué forma, por parte del programa. Las medidas basadas en el control de flujo impulsaron un área de aplicación de las medidas del software de enorme potencial. Si un programador utiliza un detallado diseño, de forma que sea isomórfico con el código final generado, medidas tales como la complejidad ciclomática pueden ser utilizadas durante la fase de diseño detallado del programa. Una de las mayores críticas vertidas sobre el modelo de McCabe es que haya sido utilizado para medir más factores de calidad que aquellos para los que fue ideado. Muchos trabajadores, escondidos tras el paraguas del término complejidad, han erróneamente extendido éste hacia áreas donde McCabe nunca intentó ir.

6.4. Sistemas de diseño Si la década de los setenta puede definirse como el decenio de la programación estructurada los ochenta se pueden caracterizar como la década de los "sistemas de diseño". La característica más significativa de esta concepción del desarrollo de programa para ordenador se centra en restar trascendencia a la fase de programación, recayendo el peso del desarrollo sobre tareas anteriores a ésta, tales como la captura de las especificaciones del sistema o la fase de diseño. Esta concepción se inspiró en la industria tradicional y es dónde las tesis propuestas por Christopher Alexander alcanzan su mayor influencia tras casi veinte años desde su publicación. Tal como propuso Alexander la idea principal de los modernos sistemas de medida están basados en la idea de que el sistema software es aquel en el cual los componentes del mismo (subrutinas, módulos, rutinas) son relativamente independientes y se encuentran aislados entre sí. Estos sistemas tienen la propiedad de que sus módulos son fáciles de entender, corregir y probar. El diseño estructurado de Yourdon tiene como elemento sustancial de su método de programación las ideas originales de Alexander, y los trabajos sobre la abstracción de datos propuestos por David ~ a r n a s o~ los ~ , iniciales intentos de caracterizar la

26 Pamas, David Lorge. Profesor de Ingeniería Computacional y Electricidad de la universidad de McMaster, Ontario. Miembro de Laboratorio de Investigación de Comunicaciones del Instituto de Telecomunicaciones de Ontario. Autor de más de 150 publicaciones orientadas al estudio de la estructura del software, diseño de


87

complejidad del sistema, fueron catalizadores de esta visión y su aplicación a los modernos modelos de medida. El modelo de ~ a f u r a ~y' ~ e n r pes, probablemente, el diseño más utilizado desarrollado hasta ahora. La idea principal de este sistema es que la complejidad es medida en términos de flujos de información y que aquellos módulos más complejos del sistema son aquellos a los que fluyen más datos.

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


88

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

Falta de madurez en la medida del software. Inexistencia de estandarización en las medidas. Medidas del software aún no ampliamente aceptadas [Zuse, 19981.

"un ejemplo de este tipo de organizaciones es la denominada en inglés Intemational Function Point Users Group (IFPUG). Entidad orientada al desarrollo y mejora de la técnica de medida del punto función y de su extensión alrededor del mundo. 32 Boehm, Bany. Profesor de Ingeniería del Software y Director del Departamento de Ciencia Computacional en el Centro de Ingeniería del Software. Doctor ingeniero por la universidad de UCLA en 1961, ha realizado numerosas aportaciones a la ingeniería del software, tales como el modelo COCOMO, el Modelo Espiral o aproximaciones teóricas a la administración del software, entre otras. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.


89

7. LA MEDIDA DEL SOFTWARE

7.1.

Marco teórico

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

Ejemplos de esta entidad podrían ser desde la construcción de especificaciones hasta el propio desarrollo del sistema software, desde la captura de los requisitos hasta la liberación al usuario del producto. Productos. Se entienden como aquellos servicios, herramientas o documentos derivados de los procesos, entendidos como resultados de éstos34.

Como ejemplos de esta entidad podríamos indicar la documentación propia de las especificaciones o del diseño, representación del código fuente u objeto, entre otros. 33

Fenton, Norman E. Sofmare Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. La traducción es nuestra. 34 Fenton, Norman E. Sofhoare Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. Pág. 42. La traducción es nuestra.

90


Recursos. Se deJinen como un conjunto de entidades considerados como entradas para la producción del software35. Ejemplo de recursos sería el personal implicado, herramientas utilizadas o método manejado. Una vez definidos las entidades que serán objeto de nuestra atención hemos de considerar los atributos a medir. Como primera aproximación indiquemos una muy fundamental división de los mismos en dos tipos bien definidos. "Atributos directos" como aquellos que pueden ser medidos en términos de las entidades a estudiar y "atributos indirectos", definidos como aquellos que sólo pueden ser medidos por medio de cómo productos, procesos y recursos se relacionan con su entorno. Basándonos en las entidades consideradas anteriormente, podemos encontrar un número determinado de atributos de interés. Asociados al estudio de los procesos, como atributo interno, Fenton aporta un número limitado de éstos. Tiempo, entendido como duración del proceso, esfuerzo asociado al proceso y número de incidentes de cierto tipo que pueden acaecer durante el proceso estudiado. Evidentemente podemos encontrar numerosas combinaciones de medidas directas cuyo resultado sería la pertinente medida indirecta que, recordemos, pueden ser de igual e incluso de mayor interés que las medidas directas. Ejemplos de atributos externos podríamos citar la estabilidad, coste, calidad, entre otros. Atributos internos propios de los productos serían, longitud, funcionalidad, redundancia, grado de acoplamiento etc. Como atributos externos podríamos citar la comprensibilidad, facilidad de mantenimiento, fiabilidad. En el caso de los recursos, podríamos citar como atributo interno la edad o sueldo (del programador), nivel de comunicación en los equipos de trabajo o la rapidez o precio de los equipos hardware. Como atributos externos podemos indicar la facilidad de uso, grado de ergonomía o experiencia. La tabla 2.5 muestra un resumen de atributos, recursos, procesos y entidades relacionadas con la medida del software. Los atributos externos son aquellos que sólo pueden ser medidos de forma indirecta, según se encuentren conectados con su entorno, mientras que los atributos internos son los que su medida puede realizarse de forma directa como atributo del recurso, producto o proceso estudiado. La relación entre atributos internos y medidas directas, así como entre atributos externos y medidas indirectas es clara. Pueden existir pocos atributos internos de cierta entidad, sin embargo la combinación de éstos nos puede proporcionar una información muy interesante y 35



91

ser tan abundante como la combinación de atributos internos sea posible. La tabla 2.6 muestra algunos atributos y su entidad asociada. según la visión "METKIT".

Tabla 2.5. Ejemplos de atributos internos y externos. Dos últimas definiciones nos permitirán finalizar este repaso teórico a la medida del software. El fin último del proceso de medida es el cálculo de alguna magnitud conocida o predecir un atributo aún inexistente. Este hecho nos lleva a dos definiciones importantes. Modelo. Entendido como una representación abstracta de un objeto36. Podemos dividir los modelos existentes en representaciones abstractas de varios productos, procesos o recursos. Tales modelos capturan atributos que están siendo medidos sin ambigüedad posible. Por otro lado existen modelos que indican abstractas representaciones entre atributos de entidades. Estos modelos relacionan, por lo general, más de dos medidas a través de una fórmula matemática. Pero la consecución de un modelo no es suficiente para desarrollar un proceso de predicción. Necesitamos determinar parámetros para el modelo e interpretar los 36

Fenton, Norman E. SofhYare Metrics. A Rigorous Approach. London, Chaprnan & Hall, 1992. Pág. 48. La traducción es nuestra.

92


resultados de forma correcta. Basándonos en esto podemos definir: Sistema. Sistema de predicción como un modelo matemático junto a un conjunto de procedimientos predictivos que permiten determinar parámetros desconocidos e interpretar resultado^^^.

"tiempo" como factor. Por ello serían actividades que se realizan en cualquier proyecto. Productos

Es cualquier herramienta, servicio o, en general, resultado, derivado de los procesos ejecutados. Salida de los mismos.

Recursos

Cualquier tipo de entidad considerada como entrada para la producción del software. Pueden ser de muy diversa naturaleza. Herramientas, métodos, materiales, son ejemplos de recursos.

Para documentación: longitud, modularidad, redundancia etc. Para código o diseño formal: estructuración, acoplamiento etc. Edad del personal, salario, velocidad del equipo hardware (entre otros)

Mantenimiento, Movilidad, Reutilización etc.

Productividad, experiencia, fiabilidad, capacidad de reutilización (entre otros)

Tabla 2.6. Entidades objeto de medida según el marco teórico propuesto. Las definiciones expuestas nos permitirán abordar el proceso de medida del software bajo una base científica.

37

Fenton, Norman E. Op. Cit. pág. 48. La traducción es nuestra.

93


8. LA NORMA ISOlIEC9126

No podemos acabar este capítulo sin hacer referencia a la norma ISOIIEC 9126. Esta norma es trascendente por diversos motivos. Es un intento por normalizar la medida de la calidad del software por parte de un organismo tan importante como es el caso de ISO. Asume la medida del software a través de una metodología de amplia utilización en las ciencias empíricas como es la descomposición jerárquica en árbol. Considera la medida de la calidad a través de la medida de atributos directos, indirectos y medida de la calidad de uso, siguiendo la propuesta de Fenton en su texto sobre la medida del software. La norma ISOIIEC 9126 también propone un procedimiento de medida con objeto de ser una referencia de carácter internacional. Estudiaremos en detalle esta norma en el capítulo VII.

aprendizaje

fallos Interoperatividad

Capacidad de recuperación

Operatividad

Seguridad

Adherencia a normas

Software atractivo Adherencia a normas

Adherencia a normas

Uso de recursos Adherencia a normas

para cambios

instalación

Estabilidad

Coexistencia

Facilidad para pmebas

Facilidad de reemplazo

Adherencia a normas

Adherencia a normas

Tabla 2.6. La norma ISOIIEC 9126.

Capítulo 3

NORMALIZACI~NY CERTIFICACI~N: NORMA ISO 9001:2000 El aseguramiento de la calidad es un modelo planificado y sistemático para proporcionar una adecuada confianza en que un producto es conforme con los requerimientos técnicos establecidos'

Unido a los conceptos metodología y modelo aparece habitualmente el de norma. En el ámbito de las comunicaciones y la informática existen organizaciones nacionales y, más habitualmente, trasnacionales que adoptan estos modelos y metodologías promoviendo su conocimiento y utilización. Cuando un modelo o metodología es adoptado por una organización de estas características adquiere el rango de norma. Un concepto muy unido al de normalización (o norma) es el de certificación. Es habitual el que un organismo que recomienda una determinada norma, establezca la posibilidad de certificar a una empresa, profesional, institución, colectivo etc. en dicha norma. Con esta acción lo que se pretende es asegurar, dar fe, sobre el grado de implantación de la norma en la empresa certificada. Se tratará en este capítulo de la normalización y de la certificación, así como de las normas y entidades de certificación, prestando especial atención a la norma ISO 900 1:2000.

1

Standards Coordinating Comminee of the IEEE Computer Society. Standars Glossary of Software Engineering Tenninologv. IEEE. Nueva York, 1991. Pág. 60. La traducción es nuestra.

Las normas son reglas metodológicas y modelos adoptados por organizaciones nacionales o internacionales que se dedican al establecimiento de estándares. Estas organizaciones se apoyan en foros de expertos que se suelen constituir en comités muy cualificados. La Organización Internacional para la Estandarización, más conocida por sus siglas en inglés, ISO, propone gran cantidad de normativa en numerosos campos tecnológicos, y es un claro ejemplo de este tipo de instituciones. Su homólogo nacional es AENOR, Asociación Española de Normalización. Las normas propuestas por la ISO, o por cualquier otra organización de características similares, son recomendaciones, no disposiciones legales, es decir no poseen el rango de Ley. El Departamento de Defensa norteamericano (DoD), la Agencia Espacial Europea (ESA), el Instituto de Ingenieros de Eléctrica y de Electrónica Norteamericano (IEEE), la Agencia 9Espacial Norteamericana (NASA) son instituciones, entre otras muchas, especialmente activas en la publicación de normativas de gran impacto mundial. Las empresas que siguen una determinada norma suelen querer demostrarlo mediante el correspondiente certificado de la organización generadora del estándar, y así evitarse gastos en demostrar que cumple las normativas en cada concurso al que se presente o en cada propuesta a un posible nuevo cliente. La certificación, inicialmente, sólo se hacía sobre el grado de cumplimiento de un determinado producto industrial sobre una determinada norma técnica, y que, por consiguiente, no era necesario comprobarlo a cada momento. La certificación alcanzó tal difusión y prestigio que las empresas de servicio también quisieron tener sus certificados, sobre todo el de calidad, ya que la sociedad actual demanda fundamentalmente calidad. Pero en los servicios el producto es único e irrepetible, ello es particularmente aplicable a la fabricación del software; un programa es diferente a otro y una aplicación no tiene nada que ver con otra aplicación. Por lo tanto lo que se certifica en estos casos no es el cumplimiento de la normativa por parte del producto, sino que la empresa está organizada y sigue una metodología que, con una alta probabilidad, dará lugar a un servicio (software) de calidad. Se certifica, en definitiva, el método con el que la empresa desarrolla el producto final, en este caso la aplicación informática. La certificación más conocida es la asociada a la norma de calidad ISO 9001, aunque existen otras certificaciones como la militar PECAL, para empresas que desarrollan software para la OTAN, o la asociada al modelo CMM, que expide Carnegie Mellon. En España, la certificación más extendida es la asociada a la norma de calidad ISO 9001 :2000.


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: Gestión de la calidad del software2 (Software Quality Management)

"Aspecto de la función general de la gestión que determina y aplica la política de calidad (objetivos y directrices generales de calidad de una empresa)." Esta gestión puede hacerse a nivel de proyecto o a nivel de empresa, es decir, a nivel estratégico. Aseguramiento de la calidad del software3 (Software Quality Assurance)

"Conjunto de actividades y sistemáticas necesarias para aportar la confianza en que el software satisfará los requisitos dados de calidad". La I E E E ~la define como "conjunto de actividades para evaluar el proceso mediante el cual se desarrolla el software". El aseguramiento tiene como objetivo dar confianza al cliente de que el software tiene calidad, pero no la garantiza. El aseguramiento de la calidad no tiene nada que ver con la garantía de calidad.

Control de la calidad del software5 (Software QualiS Control) "Técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales: mantener bajo control un proceso y eliminar las causas de defectos en las diferentes fases del ciclo de vida". La organización I E E E ~la define como "el proceso de verificar el propio trabajo o el de un compañero".

Verificación y validación del Software ( V y V ) . Es un concepto específico de la industria del software La verificación comprueba que el software funciona, es decir, que técnicamente se ha construido AENOR. Normas para la gestión y el aseguramiento de la calidad. AENOR. Madrid, 1992 AENOR. o p . Cit. IEEE. Computer Dictionary. IEEE. New Yrok, 1990. 5 AENOR. Op. Cit. 6 IEEE: Op. Cit.

de acuerdo con los requisitos del usuario. La actividad se realiza para cada fase del ciclo de vida, para confirmar que lo realizado hasta el momento es correcto, completo y consistente. La validación se realiza sobre el producto terminado y ya verificado y comprueba que funciona como quiere el cliente y realiza todas las funciones requeridas.

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

Definición

La norma ISO 9000lUNE 66900 define un sistema de calidad como: "La estructura de organización, de responsabilidades, de actividades, de recursos y de procedimientos que se establecen para llevar a cabo la gestión de calidad". Como consecuencia de esta definición, el sistema de calidad debe ser concordante con los objetivos de calidad de la empresa, definidos en la política de calidad de la misma, que es una parte de la política general de la empresa. Por ello, la alta dirección debe expresar dicha política, planificarla estratégicamente, asignar recursos y elegir los planes y evaluaciones sistemáticos; en definitiva, la alta dirección debe iniciar, desarrollar, implementar y actualizar periódicamente el sistema de calidad. También debe crear la estructura del sistema de gestión de calidad, tanto en su aspecto jerárquico como comunicativo, con el fin del que el sistema sea


99

comprendido por todo el personal, ofrezca confianza a los clientes, sea eficaz y se centre más en prevenir que en detectar y corregir errores. 4.2.

Partes del sistema

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

Manual de calidad

Es el elemento principal del establecimiento de un sistema de calidad, en el que se encuentran, por escrito, en forma de políticas y procedimientos, todos los elementos, requisitos y medios que adopte la empresa en orden a la calidad. Según el tamaño de la empresa habrá manuales de calidad para la totalidad de la empresa, manuales de calidad a nivel de producto, manuales de calidad a nivel de departamento, manuales de calidad específicos (desarrollo, proyectos, compras, relaciones con clientes, etc.). El manual de calidad es para uso interno de la empresa, aunque es necesario y fundamental en el proceso de certificación, y facilita las relaciones con los clientes y los proveedores. Las diferentes normas indican la estructura del manual de calidad. Un ejemplo podría ser el siguiente. ,

O. Índice. l . Presentación de la empresa. 1.1 Objeto y campo de aplicación. 1.2 Necesidades del cliente. 1.3 Desarrollo del producto. 1.4 Objetivos de la calidad. 2. Normas para consulta. 3. Definiciones. 7

A. Senllé y G. A. Stoll. Calidad total. ISO 9000. Las normaspara la calidad en lapractica. Ed. Gestión 2000. Barcelona, 1994.

4. Política de calidad. 4.1 Responsabilidades delegadas. 4.1.1 Director de calidad. 4.1.2 Responsable de calidad de diseño. 4.1.3 Responsable de calidad de producción. 4.1.4. Responsable de calidad de servicios. 4.2 Canales de comunicación. 4.3 Amplitud de aplicación. 4.4 Documentación del sistema de calidad. 4.4.1 Registros de la calidad. 4.4.2 Explicación de los registros. 4.5 Procedimientos operativos. 4.6 Planes de calidad. 4.6.1 Planes de formación. 4.6.2 Plan de evaluación de proveedores. 4.6.3 Plan de evaluación del personal. 4.6.4 Plan de adquisición de recursos. 4.7 Auditorias del sistema de calidad. 4.7.1 Programa de auditorias. 4.7.2 Contenido e informe de las auditorias. 4.8 Revisión y evaluación del sistema. 4.9 Mejora de la calidad. 5. El desarrollo del producto. 5.1 Fase de recepción y estudio del pedido. 5.2 Fase de diseño. 5.3 Fase de producción. 5.4 Fase de pruebas. 5.5 Fase de instalación. 5.6 Garantías. 6. Consideraciones financieras. 6.1 Recursos humanos. 6.2 Recursos materiales. 6.3 Otros recursos.

4.4.

Los procedimientos

Aunque en principio los procedimientos forman parte del manual de calidad, muchas veces se presentan de forma separada con el fin de hacerlo más manejable. De todas formas, en el manual se debe explicitar claramente la existencia de estos procedimientos separados.


101

Los procedimientos son instrucciones específicas y detalladas de los procesos o actividades, e incluyen tanto la experiencia y práctica del trabajo cotidiano como los códigos, normas y especificaciones a los que hay que ajustarse. En el desarrollo del software, se incluyen en los procedimientos las metodologías y técnicas que hay que aplicar, coino el formato de documentos, la forma de documentar, procedimiento de pruebas, reglas de codificación, etc.

Registros de datos sobre calidad

4.5.

Son archivos o bases de datos que contienen toda la información relacionada con el proceso de la calidad (datos de pruebas, datos de auditoria, inspecciones, datos de costes, etc.). Su papel, además de facilitar el funcionamiento del sistema de calidad y determinar el nivel alcanzado de calidad, se prolonga después de finalizado el proyecto como base para el estudio de las tendencias y la corrección de errores.

El enlace con la calidad del proyecto

4.6.

Ya que el sistema de calidad marca las directrices generales, es necesario desarrollar un plan específico para adaptarlas a cada proyecto, que se conoce como plan de aseguramiento de la calidad. Lo más normal es que este plan siga fielmente lo dispuesto en el plan general. Pero muchas veces es necesario adaptarlo. Esta adaptación del sistema a nivel de proyecto puede deberse a diferentes causas: Proyectos muy críticos, como los espaciales, que suponen un gran coste económico e, incluso, pérdida de vidas humanas, que exigirán unas pruebas y unas validaciones más numerosas y rigurosas que las exigidas por el sistema de calidad general; necesidades específicas del cliente, como los contratos con la OTAN, que exigen la aplicación de otras normas de calidad (PECAL, etc.); proyectos para clientes especiales con necesidades especiales.

CALIDAD A NIVEL DE PROYECTO

5. 5.1.

Planificación del aseguramiento de la calidad en un proyecto

Siguiendo el estándar IEEE', al iniciar un proyecto software hay que: -

8

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 financiación y viabilidad del proyecto. Definir las metodologías, técnicas y herramientas s utilizar. Planificar la gestión del proyecto software.

El Plan de Gestión del Proyecto Software debe incluir y describir:

-

El día a día del proyecto, con los correspondientes controles de auditorias y revisiones. La planificación del aseguramiento de la calidad del software (SQA). La planificación de la documentación del proyecto.

A partir del plan de gestión, se genera el Plan de Aseguramiento de la Calidad del Sofmare. 5.2.

El Plan de Aseguramiento de la Calidad del Software

Este plan es específico para cada proyecto, siguiendo las directrices del Manual de Calidad y de sus Procedimientos y las normas requeridas por los clientes. Siguiendo el estándar 7309 de la IEEE sobre planes de aseguramiento de la calidad del software, el plan debe incluir: Objetivos de calidad del proyecto y enfoque adoptado para alcanzarlos. Documentación referenciada en el plan (manuales, procedimientos, etc.). Gestión del aseguramiento de la calidad (organización, actividades y responsabilidades). Documentación mínima exigida a los desarrolladores tanto del desarrollo del software (especificaciones, diseño, manuales de usuario, etc.) como de control (planes de Validación y Verificación). Estándares que se deben aplicar obligatoriamente. Actividades de revisión y auditoria. Gestión de la configuración del software (mediante un plan de gestión específico o describiendo sus actividades). Informes de problemas, especificando la forma de tratar y corregir los problemas y los responsables que han de hacerlo. Herramientas para apoyar el aseguramiento de la calidad (revisiones, inspecciones, analizadores de código, generadores de entornos de prueba, etc.), especificando sus objetivos y la manera de utilizarlas. 9

IEEE. Std 730/1984. Standardfor software quality assuranceplans. IEEE. New York, 1984.

LA CALIDAD DEL SOFTWARE Y SU MEDlDA

-

-

5.3.

103

Control del código (almacenamiento y versiones), control de acceso a equipos y prevenciones de seguridad y control de las características del software de los suministradores. Recogida, almacenamiento y mantenimiento de datos sobre el aseguramiento de la calidad.

Actividades de aseguramiento de la calidad

Según el estándar IEEE 10741°, las técnicas para el aseguramiento de la calidad son, principalmente, tres:

-

Métricas del software para controlar el proyecto. Verificación y Validación del software (incluyendo pruebas y revisiones) en todas las fases del ciclo de vida. Gestión de la configuración del software.

Las métricas se estudiarán en otros capítulos de este libro.

6. MODELOS CONTRACTUALES DE ASEGURAMIENTO DE LA CALIDAD Los primeros modelos contractuales de aseguramiento de la calidad nacieron en los ámbitos de las industrias americanas de defensa, naval y nuclear. Su extensión a la industria general dio lugar a la norma ISO/DIS 9000:1985. Posteriormente se desarrollaron otras normas, tanto en América (normas ISO) como en Europa (normas EN) y en España (normas UNE). Tanto las normas europeas como españolas suelen ser, en la mayoría de los casos, una traducción de la correspondiente norma ISO. Un sistema de calidad no debe diseñarse usando como guía las normas de aseguramiento contractuales, aunque debe cumplirlas. La metodología de diseño debe basarse en las características de la empresa, los elementos de un sistema de calidad (normas ISO 9004 o UNE 66904) y los principales problemas de calidad identificados. A la hora de preparar un contrato de aseguramiento de la calidad es necesario tener en cuenta: p

p

p

p

p

lo IEEE. Std. 1074/1991. Standardfov developing sofhvare l f e cycleprocesses. IEEE Computer Society. New York, 1991.

-

-

Acomodación de la norma a las necesidades de las partes contratantes. Revisión del contrato para valorar la capacidad de satisfacer los requisitos de calidad exigidos y sus implicaciones económicas. Requisitos técnicos claramente definidos en las especificaciones del contrato.

Además, para seleccionar el modelo hay que considerar:

-

La complejidad del proceso de diseño. La madurez del mismo. La complejidad del proceso de producción. Las características particulares del producto. La seguridad del producto y las consecuencias de su fallo. Las consideraciones económicas de los aspectos anteriores.

Como ya se ha indicado, los productos software no suelen certificarse, debido al largo proceso que implica y sus elevados costos. Sólo tendrían sentido esta inversión de recursos humanos, temporales y económicos, para productos como sistemas operativos, bases de datos, etc. Lo habitual es certificar la empresa, para demostrar a los clientes que tienen implantado un sistema de aseguramiento de la calidad que de alguna forma, garantiza que el producto será de calidad, debido al uso de buenas prácticas orientadas hacia la calidad. El "Registro de Empresa" certifica la conformidad del Sistema de Aseguramiento de la Calidad de una empresa respecto a los requisitos contenidos 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 tramitación de la Certificación del Registro de Empresa corresponde a la División de Certificación de AENOR, mediante el siguiente proceso: 1". Solicitud del peticionario, incluyendo el cuestionario de evaluación preliminar, dirigido a AENOR. 2". Análisis por parte de AENOR de la solicitud y cuestionario, informando a la empresa en caso de dudas sobre su solicitud, y pidiendo a continuación el Manual de la Calidad y los Procedimientos Operativos de la Calidad (si procede). 3". Envío a AENOR del Manual de la Calidad y Procedimientos Operativos de la calidad, si la empresa decide que su estudio se realice en las oficinas de


105

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

Información preliminar

Cuestionario de evaluación preliminar

I No exigencias de la certificación

A

1 Información al solicitante

Manual de la calidad procedimientos, otros documentos aplicables

procedimientos, otros documentos aplicables

Información al solicitante

r m Visita previa

de la calidad

Informe visita previa

E3 Informe auditoria

8. LA FAMILIA DE NORMAS I S 0 9000 8.1.

Antecedentes

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


8.2.

109

La ISO 9000:2000. Razones para un cambio

Además de que el protocolo inicial obliga a realizar una revisión de las normas cada cinco años, existen diversas razones provenientes del enfoque del Sistema de Gestión de la Calidad definido por las normas ISO para realizar un cambio en las normas. A raíz de un conjunto de encuestas a distintas organizaciones se determinaron las siguientes razones: Estructura común con el modelo de procesos. Ya en el primer borrador se desarrollaron las actividades de soporte del Sistema de Calidad mediante una estructura de procesos realimentados, para cerrar un círculo de mejora continua. Dicha estructura debe servir de base para revisar los capítulos de la norma. Compatibilidad con las normas SGM ISO 14000. Muchas empresas, debido a la presión actual de los ecologistas, quieren certificar sus sistemas de gestión medioambientales con la citada norma. Muchas de ellas ya estaban certificadas para sus sistemas de calidad. Sin embargo, no existía una equivalencia clara entre los requisitos de ambas normas, por lo que se producía pérdidas de sinergias. Alcance reducido de los requisitos de la norma ISO 9001 Las organizaciones deberían poder reducir el alcance y decidir, en casos justificados, la no-aplicabilidad en algunos requerimientos. Incluir requisitos para la mejora continua. Para alcanzar la Excelencia en la Gestión es necesario basarse en la mejora continua, luego es necesario definir nuevos requerimientos en este sentidos para los sistemas de Gestión de la Calidad. Adecuación para empresas de cualquier tamaño. La certificación basada en la ISO 9001 ha tenido una moderada difusión entre las PYMES, por el enfoque de algunos requerimientos que aparentemente sólo se ajustaban a organizaciones grandes.

Relación amigable. Una de las principales críticas a esta familia de normas era la dificultad de su comprensión y aplicación, unido a una aparente falta de consistencia entre las numerosas normas existentes. Facil transición a la nueva norma. Debido al gran número de certificaciones existentes, el cambio no debería significar un empezar completamente de cero. También se exigía un período transitorio, con coexistencia de ambas normas, lo suficientemente largo para permitir a las organizaciones la adaptación de sus sistemas de calidad, y pudiendo elegir el momento del cambio a la nueva certificación. 8.3.

Principios del cambio

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

Liderazgo. Es fundamental para avanzar hacia la excelencia el liderazgo de los equipos directivos de cualquier nivel. Participación de las personas. Los conocimientos de todo el personal de la organización tienen que ponerse a disposición del proceso de mejora continua.


111

Enfoque a procesos. Se consigue una mayor efectividad cuando todas las actividades interrelacionadas se comprenden y gestionan de forma sistemática a partir de información fiable. Enfoque del sistema hacia la gestión. Por medio de la gestión de los procesos se consigue la mejora y el logro eficiente de los objetivos. Mejora continua. Definida como "el procedimiento según el cual se planifican acciones encaminadas a la mejora de las actividades, se ejecutan esas acciones, midiendo sus resultados y actuando en consecuencia." La mejora continua debe ser el objetivo permanente de las empresas, para evitar el retroceso. Enfoque hacia la toma de decisiones. La toma de decisiones se basa en observar y estudiar las medidas de los procesos y en toda la información relevante y fiable que se pueda obtener. Relaciones mutuamente beneficiosas suministradores-proveedores. Al final de la cadena proveedor-suministrador se encuentra el cliente final, por lo que es necesario establecer relaciones de mutua confianza entre los proveedores y los suministradores. 8.4.

Las normas ISO 9000:2000

En enero de 2000 se publica la versión ISO 9000:2000 que, a fecha de finalización del presente libro actualiza la versión precedente tal como muestra el siguiente cuadro:

o

ISO 9001 :2000 Sistemas de Gestión de la Calidad

- Sustituye a ISO 9001:1994, ISO 9002:1994 e ISO 9003:1994 ISO 9004:2000 Sistemas de Gestión de la Calidad ctrices para la mejora continua del desempeño. Sustituye a ISO 9004 -1 o ISO 19011 (a editar en 2002) - Sustituirá a ISO 1001 l(auditoria), e ISO 14010, ISO 14011 e ISO 14012 (medio ambiente) o ISO 9000-3: 1997 Normas para la gestión de la calidad y aseguramiento de la calidad. Parte 3: Directrices para la aplicación

Tabla 3.1. Familia de normas ISO 9000. En este punto es significativo apuntar que la norma que sustituirá a ISO 90003:1997 aún no se ha liberado por lo que la aplicación a entornos propios del desarrollo software se encuentra pendiente de adaptación, por lo que se centrará la atención en la norma ISO 9000-3 al considerarse en esta norma y de forma expresa aquellos conceptos estudiados en otras normas propias del desarrollo software. Se introducirán, igualmente, conceptos propios de la norma publicada en el año 2000 con objeto de apreciar el concepto general de la misma.

9. LA NORMA ISO 9001:2000

Los requisitos establecidos por la norma ISO 9001:2000 se estructuran en las partes 5 a 8 de la norma, siendo las cuatro primeras partes una introducción a la misma. 9.1.

Introducción a la norma

Comprende las partes 1, 2 y 3 de la norma, en las que destacar los siguientes conceptos.


113

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

Sistema de Gestión de la Calidad

En la parte 4 se definen los requisitos generales y los requisitos generales de la documentación. Los requisitos generales son: Planificar

-

Identificación de todos los procesos que, de alguna forma, afectan a la calidad del producto. Determinación de la secuencia y la relación que estos procesos tienen entre ellos. Ejecutar

-

Determinar métodos y criterios para asegurar el correcto funcionamiento y control de los procesos. Los procesos han de estar documentados. Los procesos han de estar medidos mediante parámetros relevantes. Hay que establecer los responsables de los procesos. Medir

-

Asegurar la disponibilidad de la información suficiente que permita el seguimiento del proceso. Actuar

-

Medir y realizar el seguimiento del proceso, para analizar y conseguir una mejora continua.

La documentación del sistema debe estar constituida, al menos, por los procedimientos exigidos en las partes 5 a 8 de la norma y los documentos necesarios para asegurar el control y correcto funcionamiento de los procesos.

9.3.

Responsabilidad de la dirección

En la parte 5 se describen los requisitos relacionados con la responsabilidad de la dirección en la gestión de un sistema de calidad, entre las que se destacan: -

-

9.4.

El compromiso de la dirección. El enfoque al cliente. La política de calidad. La planificación. La administración. La revisión por la dirección. Gestión de los recursos

La parte 6 describe los requisitos relacionados con la gestión de los recursos necesarios para la obtención del producto o servicio, que se detallan en cuatro subpartes: -

9.5.

Suministro de recursos. Recursos humanos. Instalaciones. Entorno de trabajo. Realización del producto o servicio

Los requisitos relativos a la realización del producto o servicio se describen en la parte 7, que se subdivide en 6 subpartes:

-

-

Planificación de los procesos de realización. Procesos relacionados con los clientes. Diseño y10 desarrollo. Compras. Operaciones de producción y de prestación de servicios. Control de equipos de medición y de seguimiento.


9.6.

115

Medición, análisis y mejora

La parte 8 describe los requisitos relacionados con la detección, el seguimiento y el análisis de las mejoras. Se divide en 5 subpartes: -

-

Planificación. Medición y seguimiento. Control de las no conformidades. Análisis de datos. Mejora.

Dentro de la medición y seguimiento se incluyen las siguientes áreas:

-

-

10.

Satisfacción del cliente. Auditoria interna. Medición y seguimiento de los procesos. Medición y seguimiento del producto.

LA NORMA ISO 9004:2000

Esta norma expone las recomendaciones para llevar a cabo la mejora del sistema de gestión de la calidad y explicaciones adicionales con relación a los requisitos de la norma ISO 9001:2000. No es una directriz para cumplir con la 9001, sino recomendaciones a la dirección de la organización para obtener mejoras. Consta también de 8 partes.

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

10.2. Responsabilidad de la dirección

En la parte cinco de la norma se describen las responsabilidades de la dirección articuladas en: -

-

Responsabilidades generales. Necesidades y expectativas. Política de calidad. Planificación de la calidad. Administración. Comunicación. Documentación y registro. Revisión.

10.3. Gestión de los recursos La parte 6 de la norma se relaciona con el papel de la dirección en identificar y proporcionar, en tiempo y formas los recursos necesarios para la consecución de los objetivos planificados de gestión de la calidad. Estos recursos son:

-

Recursos de personal. Entornos de trabajo, tanto síquicos como físicos, adecuados. Recursos de información. Recursos financieros. Infraestructuras y recursos naturales. Suministradores.

10.4. Realización del producto o servicio

La parte 7 se refiere a la realización del producto o servicio y consta de los siguientes apartados:

-

Revisiones del proceso. Validaciones del proceso/producto resultante. Mejora de procesos. Procesos relacionados con las partes interesadas. Procesos relacionados con el diseño y10 el desarrollo. Procesos relacionados con las compras. Procesos relacionados con operaciones de producción y de servicio. Control de equipos de medición y seguimiento.


117

10.5. Medición, análisis y mejora La parte 8 basa la mejora continua en la medición y el análisis de sus resultados. Estas mediciones y análisis deben hacerse regularmente, a intervalos apropiados, sobre los datos relevantes de los productos, procesos y clientes, como entradas al proceso de revisión por la dirección. La organización debería básicamente medir la eficiencia de: -

-

El sistema de gestión de la calidad (satisfacción del cliente, auditorias internas, resultados financieros y auto evaluaciones). Los procesos. El producto. Las otras partes, terceros, interesadas.

En un anexo, el D, la norma describe una metodología para implantar, de una forma sencilla, un procedimiento interno de auto evaluación. La norma también presenta ejemplos de información a incluir en los procesos de medida, análisis y mejora en los siguientes campos:

-

-

-

Relativa al cliente. Satisfacción del cliente. Auditoria interna. Financiera. Auto evaluación. Procesos. Productos. Partes interesadas. Propietarios. Suministradores. Sociedad. Medio ambiente.

Otros apartados se refieren al control de las no conformidades, al análisis de datos para la mejora y al proceso de mejora.

11.

LA CALIDAD, SU ASEGURAMIENTO Y MEDIDA SEGÚN LA NORMA ISO 9001:2000 E ISO 9000-3:1997

En el caso de los programas para ordenador (soporte lógico según la nomenclatura de la norma), la familia ISO 9000 se complementa con otras normas

propias del desarrollo software, ISO 15504 e ISO 12207. La norma ISO 9000 publicada en el año 2000 acerca la misma a la gestión de la calidad total aportando directrices para la mejora continuada. La norma ISO 9001 :2000 posee la siguiente estructura: -

-

-

Introducción. Objeto y campo de actuación. Normas para la consulta. Términos y definiciones. Sistemas de gestión de la calidad. Responsabilidad de la dirección. Gestión de los recursos. Realización del producto. Medición, mejora y análisis.

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


119

"Se deben realizar verificaciones del diseño durante las fases apropiadas del mismo (...). Se deben registrar las medidas de verificación del diseño"" "El suministrador debe: determinar qué medidas deben realizarse, la exactitud requerida y seleccionar los equipos de inspección, medida y ensayo adecuados y que sean aptos para la exactitud y precisión necesarios"'* La Norma sí aporta, de forma expresa, la necesidad de utilizar técnicas estadísticas para analizar medidas de la capacidad del proceso y las características del producto [Soluziona, 20011. Se aportan ejemplos de "características" de productos y procesos. Para procesos: Madurez del proceso. Número y tipos de defectos en la salida de los procesos. Eficiencia en la eliminación de defectos. Deslizamiento de hitos.

-

-

Para productos: -

Capacidad de ser probado. Utilidad. Fiabilidad. ~antenibilidad'~. Disponibilidad.

La norma igualmente define de forma expresa el concepto "métrica" como característica medible y aporta aquellos principios que deben cumplir. Las métricas tienen la necesidad de estar definidas claramente, deben añadir valor al proceso o producto estudiado, debe estar identificada la forma en que puede ser influida (por ejemplo por cambios en el diseño o técnicas de desarrollo) y se comprende su significado con relación al proceso o producto.

" UNE-EN ISO 9000-3. Gestión de la Calidad y Aseguramiento de la Calidad. Parte 3: Directrices para la aplicación de la Norma ISO 9001: 1994 al desarrollo, suministro, instalación y mantenimiento de soporte lógico. AENOR. Madrid, 1998. Pág. 20 ''Op cit pág. 34 l 3 UNE-EN ISO 9000-3 indica de forma expresa el concepto mantenibilidad. En traducciones realizadas por nosotros se ha preferido hacer uso del texto "facilidad de mantenimiento".

Como en el estudio de otras normas, UNE-EN ISO 9000-3 aporta ejemplos sin detallar el procedimiento de medida a utilizar apuntando al uso de técnicas estadísticas. El modelo propugna la medida de la calidad explicando este concepto desde el punto de vista de la satisfacción del cliente.

Capítulo 4 MODELOS, METODOLOGIAS Y ESTÁNDARES: ESTRATEGIAS PARA ALCANZAR LA CALIDAD Era frecuente para algunos desarrolladores considerar el software listo para su uso si el 1 programa podia ser compilado y cargado.

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

1.1.

Definiciones

Una metodología de desarrollo de aplicaciones informáticas es un conjunto de métodos que permiten sistematizar actividades. Nos dicen cómo hacer las cosas a través de procedimientos bien descritos.

'


122

MODELOS, METODOLOGIAS Y ESTÁNDARES

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

Figura 4.1. Función de transferencia en circuito cerrado. Un modelo matemático que representa un sistema de control tradicional.

Aportamos el concepto de industria clásica frente al de industria del software de igual manera que existen evidentes diferencias y, al mismo tiempo, claros intentos de aproximación entre la ingenieria del software y las ingenierías más tradicionales como la ingeniería del motor, aeronáutica, de componentes mecánicos, electrónicos etc.


123

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

MODELOS, METODOLOG~ASY

124

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. -Estándares 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 organización. -Acciones individuales y "heroicas", a veces contraproducentes

-Procesos de desarrollo y mantenimiento de software bajo control. -Planes establecidos guían el trabajo a realizar. -Existe una comunicación fluida entre equipos de trabajo, existe la transmisión de experiencia entre los técnicos. -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 organización. Los niveles de madurez son: Inicial

El proceso software se caracteriza porque es ad hoc, incluso ocasionalmente caótico. Algunos procesos son definidos aunque no se siguen con rigurosidad y el éxito depende de esfuerzos individuales.


125

Una organización adjetivada como de Nivel 1 no proporcionaría un entorno estable para desarrollar y mantener el software. Las necesidades y compromisos de cada momento son los verdaderos planificadores del trabajo que se encuentra condicionado por crisis puntuales. El uso de los recursos está comprometido por la solución de esas crisis por lo que el profesional es un "apaga fuegos", sin posibilidad de organizar su labor debido a lo perentorio de las situaciones que ha de resolver. La experiencia del equipo juega un papel primordial junto con una dirección enérgica, de tal forma que la pérdida de ese equipo o del administrador implica una merma casi inmediata de la efectividad del servicio de muy difícil recuperación. El éxito de organizaciones del Nivel 1 depende exclusivamente de la competencia de los trabajadores, su interés y predisposición. La selección del mismo, su entrenamiento o el fichaje de profesionales de valía es el motor de este tipo de organizaciones. Las organizaciones establecidas en el Nivel 1, son muy dependientes de ciertos recursos humanos, centralizando la ejecución de proyectos en la dirección fomentada por éstos. La pérdida de estos recursos implica la inmediata caída de la eficiencia de los proyectos y resulta traumática para la organización. Repetible

Han sido establecidos procesos básicos de gestión del proyecto que permiten el seguimiento de costes, planificación y funcionalidad. La necesaria disciplina del proceso consiste en la experiencia acumulada en éxitos anteriores de proyectos con similares características. Estas experiencias se convierten en la verdadera guía del proyecto software. Desarrollos anteriores han podido ser documentados, medidos e incluso mejorados, y el equipo de desarrollo ha sido entrenado en las mismas. En este nivel se establecen políticas para la administración del proyecto software y se implementan procedimientos que permitan aplicar dichas políticas. De nuevo la planificación y administración de los nuevos desarrollos se basan en la experiencia de proyectos anteriores. Debido a que el éxito del desarrollo de aplicaciones se basa en gran medida en experiencias anteriores, nuevos proyectos con requisitos muy diferentes de los ya abordados implican un evidente riesgo para la organización. El proceso software de Nivel 2 puede resumirse en un entorno disciplinado y se encuentra bajo el control efectivo de un sistema de administración guiado por planes realistas basados en el rendimiento de proyectos anteriores. En este segundo Nivel la dirección enérgica para el cumplimiento de las pautas de desarrollo establecidas sigue siendo un factor fundamental de éxito.

El proceso software para las actividades de dirección e ingeniería está documentado, estandarizado e integrado en el proceso global de creación, mantenimiento y administración del software de la organización. Se hacen uso de prácticas propias de la ingeniería del software, los proyectos se adaptan a los estándares establecidos y permiten un conocimiento de la situación y progreso del mismo, las versiones de programas y aplicaciones son controladas y su puesta en explotación es verificada y aprobada adecuadamente. La existencia de mecanismos de verificación, estándares, así como entradas y salidas, permite establecer un proceso definido, apoyo básico de administradores y guía del personal a su cargo. Debido a la existencia de procesos bien delimitados es posible controlar el progreso de los proyectos y actuar en consecuencia permitiendo variaciones en los mismos si fuera necesario frente a la constatación de desviaciones que pudieran dar origen a retrasos en la entrega del producto o falta de calidad en los mismos. El proceso software de Nivel 3 puede ser resumido como estándar y consistente. El trabajo de administradores, ingenieros de software se rigen por procedimiento establecidos y modelos determinados que permiten que éstos sean repetibles y estables. Dentro de líneas de producto establecidas, coste, funcionalidad y agendas están bajo control y la calidad del software es seguida. Gestionado

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


127

incluso definiendo un nivel basado en su recolección y uso. La medida del software es reconocida como una base fundamental en el desarrollo de aplicaciones informáticas. Este nivel de madurez se puede resumir en predecible, ya que el proceso es medido y opera dentro de los límites establecidos. Este conocimiento cuantitativo permite predecir tendencias en los procesos y la calidad de los productos. Si las medidas recogidas implican una desviación de los objetivos marcados se procede a la realización de acciones correctoras. Optimizado En este Nivel la organización incorpora nuevas tecnologías e ideas innovadoras, en un deseo de mejora continua facilidad por un proceso de retroalimentación basado en la medida de los atributos propios del proceso software. El impacto de la incorporación de estas nuevas tecnologías se valora de forma cuantitativa en cuanto a costes y efectos sobre la organización. Se proponen mejoras en el proceso software fundamentada en medidas numéricas y previsiones del resultado de su incorporación a los proyectos. La organización está envuelta en un conocimiento de sus puntos fuertes y débiles que permitirá la prevención de defectos. Las organizaciones del Nivel 5 analizan los defectos y determina sus causas. Este Nivel se puede resumir en una mejora continuada ya que la organización está envuelta en un continuo esfuerzo de mejora y estudio del rendimiento de sus procesos. La mejora del proceso se basa tanto en un incremento de los ya existentes como en el uso de innovaciones y nuevas tecnologías. Se aprecia en la estructura del Modelo de la Madurez del Software una evidente preocupación en la obtención de datos cuantitativos como elemento de juicio necesario para la mejora del proceso productivo. La medición del software es una actividad básica en este modelo, tal como lo demuestra ser un área clave común del proceso. Accedemos a un nivel superior cuando hemos alcanzado uno objetivos, la organización ha alcanzado ese nivel como consecuencia de estos objetivos.

MODELOS, METODOLOG~ASY ESTÁNDARES

128

1

Nivel 5

1

Procesos de mejora continua I

Organización madura

estandarizados

Organización

Figura 4.3. Niveles de madurez en el modelo CMM.

2.2.

Áreas clave y características comunes

En el modelo CMM cada nivel de madurez está compuesto de varias áreas claves de proceso. Estas áreas claves identifican actividades que, al ejecutarse, implican la consecución de objetivos importantes para la mejora de la capacidad del proceso productivo. Existen dieciocho áreas clave de proceso, cada una de ellas contiene una descripción breve de la misma, los objetivos a alcanzar y las prácticas clave. Las prácticas clave determinan las actividades, procedimientos, directrices y políticas para cada área clave. En la figura 4.4 observamos las áreas claves de los procesos para cada uno de los cinco niveles definidos en el modelo CMM.


129

Nivel 2 Objetivo: Clarificar requisitos. Área Clave: Gestión de requisitos (RM). Objetivo: Documentar los planes. Área Clave: Gestión de proyectos (SPP). Objetivo: Recoger medidas de progreso. Área Clave: Seguimiento y control de proyectos (PTO). Área Clave: Aseguramiento de la calidad (SQA). Objetivo: Control de productos. Área Clave: Gestión de configuración (SCM). Área Clave: Gestión de subcontratación (SSM). Nivel 3 Objetivo: Identificar el proceso. Arrea Clave: Establecimiento del proceso de la organización (OPF). Área Clave: Definición del proceso de la organización (OPD). Área Clave: Gestión integrada del software (ISM). Área Clave: Ingeniería del producto software (SPE). Objetivo: Fomentar el trabajo en equipo. Área Clave: Coordinación entre grupos (IC). Área Clave: Programa de formación (TP). Objetivo: Reducir defectos. Área Clave: Revisión entre iguales (PR). Nivel 4 Objetivo: Definir metas. Área Clave: Gestión de la calidad del software (SQM). Objetivo: Gestionar el progreso. Área Clave: Gestión cuantitativa del proceso (QPM). Nivel 5 Objetivo: Optimizar el rendimiento. Área Clave: Prevención de defectos (DP). Área Clave: Gestión del cambio de procesos (PCM). Objetivo: Adoptar nuevas tecnologías. Área Clave: Gestión del cambio tecnología aplicada (TCM). Figura 4.4. Áreas clave por niveles. Cada área clave está organizada en cinco secciones denominadas características comunes. Cada área clave, además, está descrita tomando como base las prácticas clave que contribuyen a satisfacer los objetivos de dicha área. Al abordar dichas

prácticas clave se alcanzan los objetivos del área clave del proceso. Las características comunes nos informan si los objetivos se han cubierto. A continuación indicamos las características comunes: Actividades Describen procedimientos necesarios para implementar un área clave de proceso. Se relacionan con el establecimiento de planes y procedimientos, a la realización del trabajo y al seguimiento del mismo. Compromiso Describe las acciones que la organización debe lleva a cabo para asegurar que se ha consolidado un proceso y es duradero. Suele afectar a las políticas de la organización y al patrocinio de la alta dirección. Capacidad La capacidad describe las condiciones que deben existir en el proyecto u organización para implementar de forma competente el proceso software. Suele afectar a los recursos y estructuras de la organización y a la formación. Medidas y análisis Medición y análisis describen la necesidad de medir el proceso y analizar los datos obtenidos.

Describe los pasos a seguir para asegurar que las actividades se llevan a cabo de acuerdo con el proceso establecido. Implica al grupo de aseguramiento de la calidad. La posibilidad de conocer los procesos y tareas que conforman el proyecto software es una de las más críticas informaciones de las que depende el administrador de los sistemas de información o el ingeniero de software. Muchos de los profesionales basan este conocimiento en su experiencia personal obtenida tras participar en diferentes proyectos. Una visión real de la situación en la que se encuentra el proyecto software sólo es posible con revisiones periódicas establecidas. Es interesante hacer notar cómo los niveles de madurez del software propuestos por el SE1 están relacionados con la visibilidad que el proceso del


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 acercaría a una entidad amorfa en la que difícilmente se pueden establecer el estado en el que se encuentra el proyecto o las actividades que lo conforman. En el Nivel 2 los controles sobre la administración que se establecen permiten una visibilidad del proyecto en ocasiones definidas. El proyecto puede ser asimilado a un conjunto de cajas negras en la que es posible establecer ciertos controles en hitos determinados del proyecto software, conocemos la información entrante y saliente, pero no el proceso interno. En el Nivel 3 las tareas que conforman esas cajas negras propias del Nivel 2 son accesibles. Los ingenieros y administradores conocen sus tareas y responsabilidades. En el Nivel 4 el proceso software definido es controlado cuantitativamente, por tanto, conocido de forma efectiva. Los administradores pueden medir el progreso del proyecto. La medida es una base fundamental para la toma de decisiones. En el Nivel 5 nuevos caminos son incorporados permitiendo, de manera controlada, la mejora de la calidad y de la productividad. Los administradores pueden establecer cuantitativamente el impacto de nuevas tecnologías o mejoras administrativas.

2.3.

La calidad, su aseguramiento y medida según el modelo

Observando las áreas clave de cada nivel es evidente que existen algunas directamente relacionadas con el objeto de este libro. En concreto las áreas claves identificadas como "garantía de calidad del software" y en especial las áreas clave del Nivel 4, "gestión de calidad y medidas" y "análisis del proceso" son las áreas en las que centraremos nuestro estudio. En las "características comunes", antes comentadas, son destacables las denominadas "medición y análisis". En éstas, de forma expresa, se indica la necesidad de medir el proceso software y utilizar dichos datos cuantitativos en los correspondientes análisis. El propósito del "aseguramiento de la calidad del software", propio del Nivel 2, es proporcionar a la dirección la adecuada visibilidad del proceso utilizado en el proyecto software y de los productos que se están construyendo. Los objetivos se centran en planificación de las actividades propias del aseguramiento del software, la verificación de la adhesión de los productos y actividades a estándares, procedimientos y requisitos aplicables y la información al equipo de trabajo. De forma expresa no se define la calidad del software y en cuanto a la práctica propia de la medida y análisis, ésta se centra en la medición de costes y calendario de ejecución del proyecto. Las medidas que se proponen en este modelo son las siguientes:

MODELOS. METODOLOGIAS Y ESTÁNDARES

132

- Cumplimiento de hitos para las actividades propias del aseguramiento del -

software. Trabajo realizado, esfuerzo utilizado e inversiones en actividades propias del aseguramiento del software Cantidad de inspecciones del producto y revisiones de las actividades.

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

3

SEI. Capability Maturity Model for Software, Versión 1.l, TR. Software Engineering. Institute-Camegie Mellon Universitiy. 1993. Pág. 5. La traducción es nuestra. SEI. Op. Cit. Pág. 36. La traducción es nuestra.


133

"El propósito de la gestión de la calidad es desarrollar un conocimiento cuantitativo de la calidad de los productos del proceso software y alcanzar los específicos objetivos de la calidad".' No se aporta un concepto de calidad de forma expresa. La calidad a controlar y medir es identificada en el propio proyecto como parte del mismo. Se expresa la necesidad de identificar características del producto software. Como ejemplo de estas características, en la actividad 3 dentro de la característica común, actividades realizadas, se aportan, entre otras, las siguientes:

o o o o

Funcionalidad. Fiabilidad. Facilidad de uso. Facilidad de mantenimiento.

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

5

SEI. Op. Cit. Pág. 36. La traducción es nuestra.

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

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


135

infomiáticos debe implementarse a través de una adecuada metodología la solución a los problemas que pudieran afectar a la organización. La fórmula propuesta es:

Como máxima fundamental de este modelo se puede indicar que la forma de superara la crisis del software es mejorando el proceso de organización por el cual el software es creado, manejado y mantenido. Los ámbitos cubiertos por BOOTSTRAP serían:

a) b) c) d) e)

Áreas objeto de interés. La estructura y comportamiento del área estudiada, esto es, su organización. La escala de la organización utilizando un modelo de referencia. Las métricas que permitan "medir" la organización. El proceso de cambio hacia un estado mejor.

La comunidad del software sólo recientemente ha asimilado al software como un producto en el que el proceso de creación y mantenimiento son de igual importancia e interdependientes. Bajo esta declaración de principios para BOOTSTRAP existen dos aspectos básicos en el modelo del proceso: o

o

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

La razón fundamental de la elección de un modelo de organización orientado al proceso es permitirnos una sólida base sobre la cual "medir" las organizaciones, o de forma más precisa, la madurez de dichas organizaciones (su calidad). El haber elegido el modelo de referencia del ciclo de vida propuesto por la ESA, es una base fundamental sobre la que comparar modelos de procesos de otras compañías, es una referencia. Evidentemente elegir el modelo propuesto por la ESA es debido a que se ha considerado altamente maduro y de gran calidad.

MODELOS, METODOLOG~ASY ESTÁNDARES

136

Los objetivos de la valoración BOOTSTRAP serían: o

o

o

3.2.

Medir y desarrollar un perfil de la calidad para el SPU (Unidades de Producción de Software) de forma analítica, descubriendo debilidades y fortalezas del SPU. 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 acción en una serie de mini-proyectos que implementen los pasos recomendados para la mejora.

Práctica del modelo

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

1. Un cuestionario complejo sobre datos generales de la organización. Su estructura, área de actividad, aplicaciones dominantes, sistemas de calidad asociada a la administración de recursos. 2. Un cuestionario sobre la metodología e ingeniería utilizada. Procesos en general, proceso independiente propios del ciclo de vida tales como proyectos y administración de la calidad. 3. Cuestionario sobre la tecnología y su transferencia. Datos sobre la introducción tecnológica, soporte de procesos y funciones a través de la tecnología. Soporte tecnológico dependiente e independiente del ciclo de vida. En el caso de dependencia del ciclo de vida se refiere a herramientas CASE, computadoras, redes...


137

Madurez BOOTSTRAP

Tecnología Innovación tecnológica Funciones para el ciclo de vida Funciones independientes del

Sistema de Calidad Administración de los recursos

ciclo de vida

Metodología

Funciones de Administración Administración de configuración y cambio Administración de riesgos Administración de proyectos Administración de la calidad Administración de subcontratistas

Funciones de Procesos Descripción de procesos Medida de los procesos Control de los procesos

Funciones de Desarrollo Modelo de desarrollo Requisitos, análisis y definición Diseño de la arquitectura Implementación y diseño detallado Prueba Operatoria y mantenimiento Sistemas de propósitos especiales

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


138

Organización Ingeniería del Soporte

Ingeniería del

Ingeniería del Producto

Tecnología

Atributos del Proceso

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


139

4. LA NORMA ISO 15504

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

ISO

International Organization for Standards

IEC

International Electrotechnical Commission

JTC1

Joint Technical Committee 1 Responsables de las Tecnologías de la Información

SC7

Software Engineering

WGlO

Working Group on Software Process Assessment

Tabla 4.1. La organización ISO y el proyecto SPICE. Acrónimos en inglés. El estándar resultante del proyecto debía cumplir ciertos objetivos:

O Ser lo suficientemente genérico para tener un amplio horizonte de aplicación, a la par de lo suficientemente específico como para ser útil y manejable.

O

O

Establecer los mecanismos que permitieran migrar desde estándares ya establecidos, así como evitar la aparición de otros estándares de facto. Proporcionar un programa de transferencia tecnológica que permitiera la adopción del nuevo estándar.

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

Software Engineering Institute, EE.UU AT&T Be11 Labs, EE.UU Be11 Canada Northen Telecom, Canadá British Telecom, Gran Bretaña ITDC, Finlandia Etnoteam, Italia

AFNOR, Francia IBM, Australia Fujitsu, Japón NTT, Japón CSELT, Italia Brameur, Gran Bretaña Defense Research Agency, Gran Bretaña

Tabla 4.2. El deseo por internacionalizar del proyecto SPICE implica la colaboración de numerosos organismos.


4.1.

141

ISO 15504, un modelo bidimensional

El modelo, a través de una aproximación estructurada, nos permite valorar los procesos software, fomentando la auto evaluación y ofreciendo un mecanismo por el cual los adquisidores pueden ganar confianza en los resultados de la valoración, de esta forma los datos obtenidos pueden ser utilizados para fines de calificación de los suministradores, permitiendo determinar la capacidad de los procesos, así como su adecuación para cumplir un requisito determinado o una clase de requisitos. La norma ISO 15504 se basa en otra norma de ISO, la 12207 que describe el ciclo de vida según esta organización. Las partes de la norma ISO 15504 liberadas son:

ISOIIEC 15504 - 1. Information technology - Software proccess assessment. Part 1: Concepts and introductory guide. Technical Report, publicado el 15 de agosto de 1998. 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 también está ideado para determinar la idoneidad de los procesos de otras organizaciones para un contrato determinado o clase de contrato.

onceptos y gula introductoria

Vocabulario

y guía indicadora

Figura 4.7. ISOIIEC 15504, componentes y sus relaciones. Evaluación de los procesos, mejora de los procesos y determinación de la capacidad son los objetivos a alto nivel propuesto por el proyecto SPICE.El modelo de referencia se fundamenta en dos dimensiones bien determinadas y complementarias. Una de ellas determina los procesos a ser valorados, definiendo el proceso de vida del software. La otra dimensión presenta una escala para evaluar la capacidad. La escala elegida posee cinco niveles caracterizados por un conjunto de nueve atributos de procesos, que a su vez, son tasados según en grado de cumplimiento de los mismos indicado en tantos por ciento. La primera dimensión denominada dimensión del proceso define un conjunto estándar de procesos para el ciclo de vida completo del software. La dimensión del proceso parte de tres clases básicas de procesos (Primaria, Soporte y Organizativas), éstas se dividen en cinco categorías de proceso (Cliente/ Suministrador, Ingeniería, Soporte, Administración, Organización), veinticuatro procesos de alto nivel, y otros dieciséis componentes. Cada proceso se define desde el punto de vista de su finalidad y como un conjunto identificado de resultados.

143


Soporte SUP. 1 Documentación SUP.2 Administración de la configuración SUP. 3 Aseguramiento de la

MAN. 2 Admir

calidad SUP. 4 Verificación SUP. 5 Validación SUP. 6 Revisión SUP. 7 auditoria SUP. 8 Resolución de problemas

RG. i Orien

-..,.""'-

1 del

procesc el proceso nrnrern

Figura 4.8. Arquitectura de los procesos según ISOAEC 15504. La dimensión de la capacidad del proceso se sustenta en un conjunto de atributos que determinan el nivel. El objetivo de esta dimensión es definir la escala de medida para la capacidad del proceso, para ello se considera una escala de tipo ordinal de seis puntos. Hagamos hincapié en la base fundamental que para este estándar representa la medida del software de igual manera que en el caso CMM. Los niveles considerados por el estándar son: Incompleto Hay un fallo generalizado al alcanzar los propósitos del proceso. Realizado El propósito del proceso es generalmente alcanzado. Este éxito no tiene por qué haber sido rigurosamente planificado ni seguido.


144

Gestionado El proceso libera productos de acuerdo a procedimientos específicos y es planificado y seguido. Establecido El proceso es llevado a cabo usando procesos definidos basados en principios de la ingeniería del software. Predecible El proceso definido es ejecutado en consistencia con controles de límites establecidos, para alcanzar los objetivos definidos. Medidas detalladas del rendimiento son coleccionadas y analizadas. Optimizado La realización de los procesos se encuentra optimizadas de forma que coincidan con las necesidades actuales y futuras de negocio. Los resultados de los procesos son alcanzados de forma repetida de acuerdo con los objetivos definidos.

Procesos propios del Ciclo de Vida

Cliente

Adquisicion. Suministro, Operdcion Requisitos Inoenieria Deiarrollo,Mantenimiento Sum~nistrador Documentacion, Adminstracion de ~ o n f i g u r d ~ i oaseguramiento n, de la calidad, vrrificdcion, validacion, revision, auditoria, resoluc~onde problemas 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 Administración del Trabajo del Producto Nivel 3. Proceso establecido Definición 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 estándar ISO/IEC 15504.


145

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

1 Nivel 1

I

Atri. Proc.: Rendimiento del Proceso (51%-100%) Nivel 2 Atri. Proc.: Rendimiento del Proceso (86%-100%) Atri. Proc.: Administración del Rendimiento (51%- 100%) Atri. Proc.: Administración del Trabajo del Producto (51% - 100%) Nivel 3 Atri. Proc.: Rendimiento del Proceso (86%-100%) Atri. Proc.: Administración del Rendimiento (86%-100%) Atri. Proc.: Administración del Trabajo del Producto (86% - 100%) Atri. Proc.: Definición del Proceso (51%-100%) Atri. Proc.: Recursos del Proceso (51%-100%) Nivel 4 Atri. Proc.: Rendimiento del Proceso (86%-100%) Atri. Proc.: Administración del Rendimiento (86%-100%) Atri. Proc.: Administración del Trabajo del Producto (86% - 100%) Atri. Proc.: Definición 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.: Administración del Rendimiento (86%-100%) Atri. Proc.: Administración del Trabajo del Producto (86% - 100%) Atri. Proc.: Definición 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 aproximación no sólo permite conocer el nivel en qué se encuentra nuestros procesos, es una guía que nos permite su mejora al conocer el valor qué deben tener los atributos para conseguir un nivel superior de excelencia, según la escala propuesta. La dimensión de la capacidad no sólo sirve para cuantificar la capacidad de la organización, también es una guía para su optimización. 4.2.

La calidad, su aseguramiento y medida en la norma

Debido a que el modelo de referencia ISO 15504 es un modelo bidimiensional, los conceptos a estudiar en detalle en este apartado (calidad y medida), así como sus posibles relaciones, aparecen en el proceso propio de la organización denominado administración de la calidad, incluida en la dimensión del proceso, y en el Nivel 4 en el atributo medida propio de la dimensión de la capacidad. A continuación exponemos los resultados del estudio de estos conceptos es el modelo de referencia. En la parte 2 del modelo de referencia "Modelo de referencia para procesos y capacidad" aparecen indicaciones directas a la calidad y su aseguramiento, así como a su medida. Tal como demuestra la siguiente cita: "El objetivo del proceso de la administración de la calidad es monitorizar la calidad de los servicios y productos del proyecto y asegurar que ésta satisface al 6 clientew . Se observan coincidencias con el resto de modelos estudiados focalizando el concepto calidad con la satisfacción del cliente y la de exponer la necesidad de su observación (el modelo la define como monitorización). De forma clara y concisa se asocia la calidad como cumplimiento de los requisitos, tanto explícitos como implícitos, expuestos por el cliente. Dentro de proceso de soporte en el apartado denominado aseguramiento de la calidad también se hace referencia expresa a proporcionar el aseguramiento que productos y procesos de un proyecto cumplen con sus requerimientos especzjkos y 7 se adhieren a los planes establecidos . De forma expresa se cita a la normativa ISO 9001 como complemento a utilizar en este punto de la norma ISO 15504. El modelo estudiado considera la medida como un proceso propio de la parte organizativa del ciclo de vida. "El propósito del proceso de medida es coleccionar y analizar datos relacionados con los productos desarrollados y los procesos implementados dentro

'ISO/IEC TR 15504-2. Information technology -Software process assessment - Parti2 A reference modelfor processes andprocess capability. ISOIIEC. Suiza, 1998. Pág. 19.

' ISO/IEC TR 15504-2. Information technology -Software process assessment - Part:2 A reference model for processes andprocess capability. ISOIIEC. Suiza, 1998. Pág. 20.


147

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

Incluido en el Plan de Acción de la Subdirección General de Coordinación de Informática del Ministerio de Administraciones Públicas (MAP) se elaboró una metodología de desarrollo de sistemas de información denominada MÉTRICA. La primera versión se remonta a 1989, MÉTRICA V. 1: Guías metodológicas, pero fue en 1993 cuando se publicó la versión 2: Guía técnica, de referencia y de usuario. En 1995 se liberó la versión 2.1 y en julio de 2001 se ha liberado la versión 3, mejora resultante de la publicación del correspondiente borrador en

ISO/IEC TR 15504-2. Information technology -Sofhoare process assessment - Part:2 A reference model for processes andprocess capability. ISOIIEC. Suiza, 1998. Pág. 23.

enero de 2001 y la consideración de las aportaciones recopiladas en esos siete meses. Para la elaboración de MÉTRICA V.3 se han considerado métodos (EUROMETODO, SSADM V4, MAGERIT, Information Engineering), normativa intet-nacional (ISO 12.207, ISOIIEC TR 15504/SPICE, UNE-EN ISO 9001 :2000, IEEE 610.12- 1.990) y se han tenido en cuenta diferentes tecnologías propias de la informática y las comunicaciones (clientelservidor, orientado a objeto, reutilización y bases de datos, entre otras). La elaboración de MÉTRICA se basa en la participación de diferentes actores relevantes en la ejecución de proyectos informáticos. En concreto los intervinientes en la última versión han sido: O O O

O O

O O

MAP y el Comité de Seguimiento. Administración General del Estado (Defensa, Interior, Justicia, Trabajo, entre otros). Comunidades Autónomas (Andalucía, Castilla-La Mancha, Madrid, País Vasco). Ayuntamientos. Informática El Corte Inglés (IECISA). Universidad Carlos 111de Madrid. Fondos PEINATYCA.

Los usuarios a los que va dirigida MÉTRICA V. 3. pueden resumirse en: Administración del Estado. Comunidades Autónomas. Ayuntamientos. O Centros de enseñanza de ingeniería del software.

O O O

La metodología MÉTRICA es utilizada habitualmente como referencia en licitaciones cuyo objeto es el desarrollo de programas para ordenador publicadas por organismos de carácter institucional españoles. Las empresas aportan el cumplimiento de esta metodología como instrumento que permite la ejecución en plazo y coste del proyecto adjudicado. Esta consecuencia proviene de los objetivos principales que esta metodología expresa de forma determinante en su primer capítulo: "La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software. La nueva versión de MÉTRICA contempla el desarrollo de Sistemas de Información para las distintas tecnologías que actualmente están


149

conviviendo y los aspectos de gestión que aseguran que un proyecto cumple sus objetivos en términos de calidad y coste."

MÉTRICA, una metodología basada en procesos

5.1.

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

Planificación de sistemas de información. Desarrollo de sistemas de información. Mantenimiento de sistemas de información

A su vez el proceso principal desarrollo de sistemas de información se ha dividido en cinco procesos:

Estudio de viabilidad del sistema (EVS). Análisis del sistema de información (ASI). Diseño del sistema de información (DSI). O Construcción del sistema de información (CSI). O Implantación y aceptación del sistema (IAS).

O O O

MÉTRICA Versión 3 aporta un conjunto de procesos (definidos en la metodología como interfaces) orientados a la organización y como apoyo al propio proceso de desarrollo. Estas interfaces definen un conjunto de actividades que, según la propia'met~dolo~ía: "En el caso de existir en la organización se deberán aplicar para enriquecer o influir en la ejecución de las actividades de los procesos principales de la metodología y que si no existen habrá que realizar para complementar y garantizar el éxito del proyecto desarrollado con MÉTRICA Versión 3." Las interfaces que define MÉTRICA Versión 3 son: O O O O

Gestión de Proyectos (GP). Seguridad (SEG). Aseguramiento de la Calidad (CAL). Gestión de la Configuración (GC).

La metodología MÉTRICA Versión 3 también aporta técnicas con la intención de ayudar en la obtención de los productos resultantes de las tareas definidas.


150

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

EVS 1, EVS 2, EVS 3, EVS 4, EVS 5, EVS 6.

Situación actual Catálogo de Requisitos y Objetivos Alternativas de Solución Solucinn Pronuesta

Análisis del Sistema de Información

Figura 4.10. Actividades consideradas en el proceso de Evaluación del Sistema de Información.


151

De las actividades que constituyen este apartado consideremos la denominada EVSl (Establecimiento del alcance del sistema). Las tareas, productos, participantes, técnicas y prácticas asociadas a la misma se resumen en la tabla 4.4.

Catalogo de Usuarios. Plan de Trabajo.

trabajo.

Jefe de Proyecto

Analista.

Tabla 4.4. Tareas, productos, práctica y participantes, EVS. La aplicación de MÉTRICA Versión 3 proporciona sistemas con calidad y seguridad, no obstante puede ser necesario en función de las características del sistema un refuerzo especial en estos aspectos, refuerzo que se obtendría aplicando la interfaz correspondiente. Según la propia metodología: "efinen una serie de actividades de interfaz con otros procesos organizativos o de soporte que, en el caso de existir en la organización, enriquecerán o influirán en la ejecución de las actividades de los procesos principales." MÉTRICA Versión 3, aporta un apartado específico de técnicas a utilizar en los procesos antes indicados. Estas técnicas proporcionan al ingeniero de software herramientas con las que obtener diferentes productos propios del ciclo de vida del software. Las herramientas propuestas son de muy diversa naturaleza afectando a las fases de desarrollo, gestión y soporte. Diagramas de distinta naturaleza y objetivo, herramientas de estimación y planificación, análisis de impacto, prototipado de aplicación etc. son algunas de las muchas propuestas por MÉTRICA Versión 3 como apoyo al ingeniero de software.

Capítulo 5

No será nada inútil ni ocioso... haceros recordar la primera fuente y origen1

La rápida evolución de la tecnología informática, con sus impresionantes mejoras en prestaciones y rendimiento, no ha sido acompañada por una análoga evolución en el desarrollo de la industria del software, es la llamada "crisis del software". Por ello los equipos de 1 + D de las empresas y numerosos profesores universitarios han dedicado sus esfuerzos a la investigación y desarrollo de nuevas formas de desarrollo de software, dando lugar a modelos y metodologías. Estos modelos y metodologías, a pesar de mejorar la situación, no llegan a obtener resultados espectaculares, por lo que se abren camino nuevas ideas y modelos. De entre ellos empiezan a destacar los llamados modelos conceptuales, que permiten el enlace entre los requisitos de los usuarios y la solución software correspondiente y permiten modelar, además de los aspectos estáticos de los Sistemas Informáticos, algunos aspectos de su comportamiento.

1. MODELOS CONCEPTUALES 1.1.

Definiciones

Olivé define el modelo conceptual como "la búsqueda y definición formal del conocimiento general sobre un dominio que un sistema de información (SI) necesita conocer para llevar a cabo las funciones requeridas."2

' Francois Rabelais. Pantagruel, cap. 1 (1532). A. Olivé. An introducfion lo concepfual modeling of ifIformation Systern. Cap. 2. Advanced Database Technology and Desing. Artech House, 2000.

METRICAS PARA MODELOS CONCEPTUALES

154

La influencia del modelo conceptual en el producto resultante, aunque sólo sea una fase inicial, es mucho mayor que la de otras fases del ciclo de vida, ya que la detección y corrección de errores en las primeras etapas de cualquier proceso, y en particular en el desarrollo del software, permite una mejora de la calidad y unos menores costes de no conformidad. La atención al modelado es clave para el éxito del proyecto. Los modelos conceptuales pueden clasificarse en dos grandes grupos, los tradicionales y los orientados a objetos: Los modelos conceptuales tradicionales, como el Entidad-Relación (ER), desarrollado en 1976 por Chen, y modificado posteriormente por otros autores, todavía pueden describir fácilmente los requisitos de datos de un Sistema de Información con independencia del criterio de la gestión y organización de los datos. Los modelos conceptuales orientados a objetos representan, además de los datos, el comportamiento y funcionalidad del Sistema de Información, mediante diagramas de clases, de actividad, de transición de estados, etc. Calidad de los modelos conceptuales

1.2.

Como siempre que se habla de calidad, hay que distinguir entre la calidad del producto y la calidad del proceso realizado para conseguirlo. En este caso, la calidad del producto se relaciona con las características del modelo conceptual y la calidad del proceso con la manera en que se desarrollan los modelos conceptuales. Algunos autores, como Batíni y Gregori entre otros, identifican la calidad de los modelos con una lista de las propiedades ideales que deben tener los modelos de datos (tabla 5.1). Estas listas pueden servir para mejorar la calidad de los modelos, pero, en general, no son estructuradas, las definiciones no son precisas, solapándose entre sí, presentan objetivos no realistas, presuponen la existencia de diseño/implementación y otros defectos.

I

Batini et al. (1992)

Reingruber M. y Gregory W. (1994)

expresividad, autoexplicación, extensibilidad y normalidad Corrección conceptual, compleción conceptual, corrección sintáctica, compleción sintáctica, conocimiento de la empresa. Facilidad de compresión, corrección semántica, estabilidad, compleción conceptual.

1 Boman et a1 (1997)

Tabla 5.1. Calidad y sus propiedades según 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 características en el modelado conceptual de los datos. En general, estos marcos, al definir sólo propiedades deseables y carecer de medidas cuantitativas, no permiten medir eficazmente la calidad del producto obtenido. Para evitar los sesgos en el proceso de evaluación de la calidad, ~ o o d ~ ~ propuso en 1998 que era necesario contar con medidas objetivas y cuantitativas para evaluar la calidad de los modelos conceptuales. En los siguientes apartados se presentan algunas de las propuestas que sobre métricas de calidad de los modelos conceptuales han aparecido en los últimos años.

2.1.

Métricas de Kesh

El profesor S. Kesh publicó, en 1995~, el método que había desarrollado para el aseguramiento de la calidad del modelo Entidad-Relación. Este método se basa en que la calidad en estos modelos de datos se determina por dos tipos de componentes: los ontológicos y los de comportamiento. El método se compone de tres pasos: 1" Cálculo del valor de cada uno de los componentes ontológicos. Se calcula individualmente el valor de los componentes estructurales (las relaciones entre los elementos que forman el modelo: adecuación al problema: 01, validez, 02, consistencia, 03, y concisión, 04) y de los componentes de contenido (los atributos de las entidades: completitud, os, cohesión, 06, y validez, 07). 2" Cálculo de los valores de los componentes de comportamiento. Este cálculo se hace a partir de los valores de los componentes ontológicos relevantes para cada uno de los componentes de comportamiento. Los componentes de comportamiento a tener en cuenta son: facilidad de uso desde el punto de vista del usuario, S I , usabilidad desde el punto de vista del diseñador, s2, facilidad de mantenimiento, s3, precisión, s4 y rendimiento, SS. 3" Cálculo de la calidad del modelo Esta cálculo se hace a partir de los valores de los componentes de comportamiento de acuerdo con la fórmula:

' D. Moody, G. Shanks y P. Darke. Improving the Quality ofEntiQ Relatioship Models-Experience in Research and Practice. Proceeding of 17'~.Intemational Conference on Conceptual Modelling. Singapur, 1998. S. Kesh. Evaluating the quality ofentity relationship models. Information and Software Technology,vol. 37 no 12. 1995.

156

MÉTRICAS PARA MODELOS CONCEPTUALES

siendo wi los pesos de los factores de comportamiento y si los valores de dichos factores. Los pesos se determinan por la organización en función de la importancia que tengan para la misma. Las fórmulas para el cálculo de las si son las siguientes:

Los valores de los factores ontológicos son, en algunos casos, estimados por los usuarios y, en otros, calculados mediante fórmulas ad hoc. Los procedimientos son los siguientes:

Adecuación del modelo al problema (o,). Valor entre 1 y 5, determinado mediante entrevista con los usuarios. Validez del modelo (oZ).Valor entre 1 y 5, obtenido mediante entrevistas a un equipo técnico que no está involucrado en el proyecto. Consistencia del modelo (oj). Se calcula mediante la fórmula

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


157

formado por todos los atributos de la entidad. La cohesión es mínima y o6 vale O. Para los demás casos se utilizan fórmulas específicas. Validez del contenido (0,) Si todos los atributos para todas las entidades son válidos 07 vale 5. Si todos los atributos se consideran inválidos. Se le atribuye a 07 el valor O. En los demás casos se aplica la fórmula

siendo ni el número de entidades inválidas y n, el número de atributos de la entidad. Como el modelo está poco experimentado, es necesario mucha interacción entre los diseñadores y los usuarios para su retroalimentación. El propio Kesh considera que el valor de Q no es una estimación precisa, sino un indicador de la calidad del modelo ER y que, por consiguiente, habría que seguir trabajando sobre el modelo. En resumen, el modelo de Kesh se aplica a modelos ER, tiene un enfoque ontológico y de componentes, comprende métricas tanto objetivas como subjetivas, no ha sido validado ni teóricamente ni empíricamente y no existen herramientas matemáticas.

2.2.

Métricas de Moody

En 1998, ~ o o d ~ \ r e s e n t óun conjunto de métricas, algunas objetivas y otras subjetivas, para evaluar algunos factores de calidad de los modelos de datos. Estas métricas son, para los diferentes factores de calidad: Compleción -

-

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

Integridad

-

5

Número de restricciones de integridad incluidas en el modelo que no corresponden a políticas de negocio. Número de reglas del negocio que no se cumplen por el modelo de datos.

D. Moody. Metrics for evaluating the quality of entity relationship models. Proceedings of the 1 7 ' ~International Conference on Conceptual Modelling. Singapur, 1998.

158


Flexibilidad

-

Costes estimados de los cambios. Importancia estratégica de los cambios. Número de elementos del modelo que en el fututo estarán sometidos a cambios.

Corrección -

-

Número de violaciones a las formas normales. Número de violaciones a las convenciones de modelos de datos. Número de instancias de redundancias en el modelo.

Simplicidad

-

Número de entidades. Número de entidades y relaciones. Número de constructores.

Integración -

-

Número de conflictos con los sistemas existentes. Número de conflictos con el modelo de datos corporativo. Valoración de los representantes de todas las áreas del negocio.

Implementabilidad

-

Valoración de riesgo técnico. Valoración de riesgo de planificación. Estimación del coste del desarrollo. Número de elementos físicos del modelo de datos.

Comprensibilidad -

Valoración de los usuarios sobre la comprensibilidad del modelo. Capacidad de los usuarios de interpretar el modelo correctamente. Valoración de los desarrolladores sobre la comprensibilidad del modelo.

Moody propuso que investigadores y profesionales trabajen conjuntamente para demostrar la validez de estas métricas. El método de Moody no ha sido validado de teórica ni prácticamente, no aporta herramientas, tiene medidas objetivas y estimaciones subjetivas, y sólo tiene en cuenta algunos factores de calidad para los modelos ER


2.3.

159

Métricas de Piattini

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

NDA NCA NMVA NNR NM:NR NI: NR NbinaryR NN

Número total de entidades en el modelo ER. Número total de atributos (simples, compuestos y multivaluados) en el modelo, tanto en las relaciones como en las entidades. Número total de atributos derivados en el modelo. Número total de atributos compuestos en el modelo. Número total de atributos multivaluados en el modelo. Número total de relaciones comunes en el modelo. Número total de relaciones N:M en el modelo. Número total de relaciones I:N e 1:I en el modelo. Número total de relaciones binarias en el modelo. AryR.

De ellas, son métricas de tamaño las NE, NA, NCA, NDA y NMVA, y de complejidad el resto. Estas métricas del modelo ER son objetivas y han sido validadas teóricamente por Genero, siguiendo la teoría de Zuse, y empíricamente mediante un caso de estudio y dos experimentos controlados.

3 . MÉTRICAS PARA MODELOS CONCEPTUALES ORIENTADOS A OBJETOS

3.1.

Métricas de Brito e Abreu y Carapuqa

Brito y Carapuqa presentaron las métricas MOOD para medir algunos de los principales mecanismos de los modelos orientados a objetos (encapsulamiento, M. Paitiini, M. Genero y L. Jimenez. A metric-based aproach forpredicting conceptual data modes maintainability. International Journal of Software Engineering and knowledge engineering. World Scientific Publishing Company, 2001.

polimorfismo, herencia y paso de mensajes, etc.) para poder evaluar la productividad del desarrollo y la calidad del producto. Las métricas MOOD se definieron para aplicarlas a nivel de diagramas de clases y se pueden utilizar en la fase de diseño. Las definiciones de las diferentes métricas son: MHF

AHF

MIF

AIF

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

Las conclusiones de un estudio empírico fueron: Al aumentar el valor de MHF o el del MIF, disminuye la densidad de defectos y el esfuerzo para corregirlos. F. Brito e Abreu y W. Melo. Evaluating the impact ofobject-oriented design on Sofrware Quality. Proceedings of 3rdlntemational Metric Symposium, 1996.


161

El valor ideal de la métrica AHF es el 100%. El incremento de la reusabilidad por medio de la herencia dificulta la comprensión y el mantenimiento de los sistemas. La redefinición de modelos pueden reducir la complejidad y hacer el sistema más comprensible y fácil de mantener. En resumen, las métricas de Brito e Abreu y Carapuga se enfoca hacia las características de los diagramas de clase, son medidas objetivas y han sido validadas de forma teórica y parcialmente de forma empírica. 3.2.

Métricas de Chindamber y Kemerer

En 1994, Chimdamber y ~ e m e r e r ' propusieron seis métricas para la complejidad del diseño Orientado a Objeto, aunque no todas pueden aplicarse a nivel conceptual, y además han sido muy criticadas por su ambigüedad e imprecisión. Las métricas que se considerarán son: DIT

NOC

La métrica Depth of Inheritance. Tree se define como la profundidad del árbol de una clase (en los casos de herencia múltiple es la máxima longitud desde el nodo hasta la raíz del árbol). Se basa en que cuando más profunda está la clase en la jerarquía, mayor número de operaciones puede heredar. Se propuso como una medida de la complejidad de una clase, complejidad de diseño y reusabilidad potencial. La métrica Number Of Children se define como el número de subclases inmediatas subordinadas a una clase. Esta medida indica cuántas subclases van a heredar las operaciones de la clase padre.

Esta métrica presenta medidas objetivas para la complejidad de las clases y han sido validadas teóricamente por los autores al corroborar que satisfacen los axiomas de weyuker9. La validación empírica fue realizada por Basil y sus colaborado re^'^, que encontraron que la posibilidad de encontrar un fallo es directamente proporcional al valor de DIT e inversamente al del NOC.

9. Chindamber

y C. Kemerer A metric suite for object oriented Desing. IEEE Transactions on Software Engineering ,20 (6), 1994. E. Weyuker. Evaluating software c o m p l e x i ~measures. IEEE Transaction Software Engineering, vol. 14, núm. 9, 1988. l o V. Basili, L. Briand y W. Melo. A validation of Object-Oriented Desing Metrics as Quality Indicators. IEEE Transactions on Software Engineering. Vol. 22, núm. 10, 1996.


162

3.3.

Métricas de Lorenz y Kidd

Lorenz y ~ i d d " propusieron las métricas de diseño par medir las características estáticas de un producto software. Se dividen en tres grupos: métricas de tamaño, métricas de herencia y métricas de las características internas de las clases. De todas las propuestas, la que se pueden aplicar a un diseño de alto nivel son las siguientes: Métricas de tamaño PIM

NIM

NIV

NCM NW

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

Métricas de herencia NMO

NMI

NMA

El Número de Métodos Sobrecargados es el número total de métodos sobrecargados en una subclase. Se propuso para medir la calidad del uso de la herencia. El Número de Métodos Heredados se define como el número de métodos que hereda una clase. También mide la calidad del uso de la herencia. El Número de Métodos Añadidos es el número total de métodos que se definen en una subclase. Igual que las anteriores mide la calidad de uso de la herencia.

" M. Lorenz y J. Kidd. Object-oriented Sofh~are metrics: apracticalguide. Ed. Prentice Hall. Englewood Cliffs, New Jersey, 1994.


SIX

163

El índice de EspeciJicacion para una clase se define como el número de métodos sobrescritos multiplicado por el nivel de anidamiento en la jerarquía y dividido entre el número total de métodos. Mide el grado en que una subclase redefine el comportamiento de una superclase.

Métricas de características internas de una clase APPM

El Promedio de Parámetros por Método se define como el cociente entre el número total de parámetros por método y el número total de métodos.

Se enfocan estas métricas a las características internas del diseño orientado a objetos con medidas objetivas y una herramienta, la OOMetric, que sólo puede aplicarse a código escrito en C++ y Smalltalk. No se ha validado teóricamente y sólo empíricamente de forma parcial. 3.4.

Métricas de Genero y al

enero'^ y otros

propusieron en el año 2000 un conjunto de métricas para la medida de la complejidad estructural de los modelos de clase debido al uso de relaciones UML. Se clasifican en: métricas a nivel de modelo de clases y métricas a nivel de clase. Métricas a nivel de modelo de clases Nassoc Nagg Ndep Ngen NgenH

La métrica Número de Asociaciones se define como el número total de asociaciones dentro de un modelo de clases. La métrica Número de Agrupaciones se define como el número de relaciones de agregación dentro de un modelo de clases. El Número de Dependencias es el número total de relaciones de dependencia en un modelo de clases. El Número de Generalizaciones se define como el número total de relaciones de generalización dentro de un modelo de clases. La métrica Número de Jerarquías de Generalización es el total de jerarquías de generalización en un modelo de clases.

l 2 M- Genero, M. Piattini y C. Calero. An approach to evaluate the complexifv ofconceprual database models. 2"d European Software Measurement Conference. Madrid. 2000. M. Genero. Defining and validating metrics for conceptual models. Tesis doctoral. Universidad de Castilla-La Mancha, 2002.

NaggH MmDIT

MaxHAgg

La métrica Número de Jerarquías de Agregación es el número total de jerarquías de agregación dentro de un modelo de clases. La métrica Máximo DZT se define como el máximo de los valores DIT obtenidos de cada clase del modelo de clases. El valor DIT es la longitud de la ruta más larga desde la clase a la clase raíz de la jerarquía de generalización. La métrica Máximo HAgg es el máximo de los valores Hagg de cada clase del modelo de clases. El valor HAgg, dentro de la jerarquía de agregación, es la longitud de la ruta más larga desde la clase hasta las hojas.

Métricas a nivel de clases NassosC Hagg NODP

NP NW

Masg Ndepln NdepOut

El Número de Asociaciones por Clase es el número total de asociaciones de una clase (con otras clases o con ella misma). La Altura de una clase es la longitud de la ruta más larga desde la clase a las hojas, dentro de una jerarquía de agregación. El Numero de Partes Directas de una clase es el número de Partes Directas que contiene una clase que pertenece a una jerarquía de agregación. El Número de Partes es el número de clases "partes" (directas o indirectas) de una clase "todo". La métrica Número de Todos se define como el número de clases "todos" (directas e indirectas) en una clase "parte". La métrica Agregación Múltiple es el número de clases "todo" directas que tiene una clase en una jerarquía de agregación. El Número de Dependencias In se define como el número de clases que depende de una clase dada. El Número de Dependencias Out es el número de clases de las que depende la clase dada.

Esta métrica se enfoca hacia la complejidad estructural debida al uso de relaciones y es objetiva. Se ha validado teóricamente usando los marcos de Briand, Zuse y Poels y Dedene. También se han realizado diversos experimentos controlados para validar empíricamente las métricas a nivel de modelos de clases.

Capítulo 6

EL ANÁLISIS DEL PUNTO FUNCIÓN En 1968 sabíamos qué queriamos construir, pero no lo hicimos. Ahora intentamos construir sobre arenas movedizas'.

El conocimiento, propuesta y estudio de medidas de atributos asociados a la calidad de programas informáticos es uno de los objetivos principales de este texto. El análisis del Punto Función (APF) es una técnica destinada a medir la funcionalidad de una aplicación informática, entendida ésta como el conjunto de funciones aportadas al usuario por el producto informático. Tal como veremos a lo largo del capítulo esta técnica presenta severos problemas incompatibles con la teoría de la medida [Fenton y Pfleeger, 19971 pero, al mismo tiempo es utilizada por numerosas empresas y organizaciones para la contabilidad de sus programas y la obtención de valiosas estadísticas. La medida del software es una disciplina que se sustenta, como cualquier otra rama científica, sobre mejoras sucesivas. Hacer uso de una herramienta que no es perfecta o matemáticamente correcta no es un error en sí, siempre que conozcamos este hecho y sepamos las limitaciones que lo acompañan.

1.1.

La propuesta de Albrecht: ventajas e inconvenientes

La técnica del análisis del Punto Función fue ideada por Allan Albrecht, especialista de la firma IBM, a finales de los años setenta. Diseñó este proceso de I

Cliff Jones. Actas de las conferencias auspiciadas por la OTAN, Conference-London to analyze the Furure Direcrion ofSofhyare. Abril 1993. Disponible en http:l/www.comlab.ox.ac.uWarchive. La traducción es nuestra. Cliff Jones es profesor de la universidad de Manchester experto en metodologias y procesos de desarrollo del software.

EL ANÁLISIS DEL PUNTO FUNCIÓN

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

Existe un grado de subjetividad en la medida alcanzada, en concreto en el denominado factor tecnológico.


-

-

167

Es necesario una muy detallada definición del proyecto si pretendemos medir el mismo en las primeras etapas del desarrollo. Aparecen problemas e ineficacia de la medida al depender de la tecnología utilizada. El APF no es totalmente independiente del sistema de análisis o del método de diseño utilizado aunque supone una mejora frente al uso de líneas de código, por ejemplo. Aparecen problemas cuando se utiliza el APF en aplicaciones de carácter científico o aplicaciones en tiempo real. Existen problemas con la teoría de la medida al mezclar en una misma medida diferentes escalas de forma inconsistente.

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

Número de defectos descubiertos en el programa Tamaño del programa

Ecuación 6.1

EL ANÁLISIS DE L PLINTO F L I N C I ~ N

168

Según la ecuación 6.1 las unidades propias de la densidad de defectos son el número de defectos por número de Puntos Función del programa.

2. EL ANÁLISIS DEL PUNTO FUNCIÓN PASO A PASO El Análisis del Punto Función es un procedimiento secuencia1 que se compone de un conjunto de pasos que hemos de ejecutar. A continuación explicamos en detalle el procedimiento a realizar hasta la obtención del número de Puntos Función de la aplicación considerada. 2.1. Determinar el tipo de conteo a realizar El primer paso a ejecutar al utilizarse el APF es determinar qué tipo de contabilidad se va a realizar. Ésta depende del estado en que se encuentre la aplicación a medir y determinará las ecuaciones que se han de utilizar. El IFPUG considera tres tipos de conteo de Puntos Función, según el estado de implantación y desarrollo en que se encuentre la aplicación informática. Provectos de desarrollo. El conteo de los Puntos Función de proyectos de desarrollo mide las funciones proporcionadas al usuario final con la primera instalación del software entregado, una vez el proyecto ha sido completado. Provectos de mejora. El conteo de los Puntos Función de proyectos de mejora mide las modificaciones sobre las aplicaciones existentes que añaden, cambian o eliminan funciones de usuario entregadas cuando el proyecto fue completado. Aplicación. El conteo de los Puntos Función de aplicaciones está asociado con sistemas ya instalados. Esta contabilidad ofrece la medida de las funciones que la aplicación proporciona al usuario final, en un momento dado. Es actualizado cada vez que se completa un proyecto de mejora que altera las funciones del sistema. 2.2. Identificar los límites en los que se aplicará el conteo de los Puntos Función Identificar los límites en los que se aplicará el conteo de los Puntos Función significa determinar el borde entre el proyecto o aplicación que está siendo medido y aplicaciones externas o el dominio del usuario.


169

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

Un Fichero Lógico Interno (FLI) es un grupo de datos relacionados lógicamente, o información de control, identificables para el usuario y mantenidos dentro de los límites de la aplicación. Para identificar los Ficheros Lógicos Internos presentes en el sistema, se han de buscar datos o información de control que cumplan con la definición propuesta. Los ficheros aspirantes son sometidos a un cuestionario. Sólo cuando todas las preguntas propuestas tienen respuesta afirmativa podemos resolver que los datos considerados son FLI. Desde un punto de vista práctico el proceso de identificación de FLI se ha resumido en una tabla dividida en tres columnas: ficheros aspirantes a ser considerados FLI, preguntas tipo, respuestas y un breve comentario (ver tabla 6.2).

"Propuesta A"

control es un gmpo de datos lógicos, o identificables por el usuario, de forma que cumple con específicos requisitos de éste?

Pregunta 2 ¿El grupo de datos es modificado, o mantenido, dentro de los limites de la aplicación?

Afirmativo/Negativo.

Pregunta 3 ¿El grupo de datos es modificado, o mantenido, a través de un proceso elemental de la

Afirmativo/Negativo.

Afirmativo/Negativo. o Fichero de Interfaz Externo

Tabla 6.2. Identificación de los Ficheros Lógicos Internos. 2.4. Identificación de los Ficheros de Interfaz Externo (FIE)

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


"Propuesta A"

171

control cs un grupo Iúgicamente relacionado o identificable por el usuario de forma que cumpla con requisitos especificamente establecidos por

Explicació~i

Pregunta 2 ¿El gmpo de datos es utilizado como referencia por la aplicación que está siendo considerada y, además, es externo a la misma?

AfirmativoMegativo.

Pregunta 3 ¿El gmpo de datos no es mantenido por la aplicación que está siendo medida?

AfimativoMegativo.

Pregunta 4 ¿El gmpo de datos es considerado como un FLI, al menos por otra aplicación?

Afimativo/Negativo.

Pregunta 5 ¿El grupo de datos considerado no ha

AfimativoMegativo.

Tabla 6.3. Identificación de los ficheros interfaz externos. 2.5.

Clasificar la complejidad de los ficheros lógicos y determinar su contribución

El número de ficheros lógicos y su complejidad relativa funcional determina la contribución de los tipos de función de datos al conteo de los Puntos Función sin ajustar. La asignación de complejidades a FLI y FIE se basa en el número de Tipos de Elementos de Datos (TED) y número de Tipos de Elementos de Registros (TER) propios de los FLI y FIE contabilizados. Un tipo de elemento de dato se define como un campo único, no recurrente y reconocible para el usuario en un FLI o FIE. Para determinar los TED existentes en los ficheros lógicos se aplican tres reglas: Regla 1. Contabilizar un TED por cada campo no recurrente, único y reconocible para el usuario en un FLI o FIE. Regla 2. Contar un TED por cada campo en un FLI o FIE que existe porque el usuario requiere que se mantenga una relación con otro FLI. Es lo que se denomina como clave externa. Regla 3. Considerar las siguientes técnicas de implementación como un simple TED, para el grupo de campos considerado.

-

-

Campos que aparecen más de una vez en un FLI o FIE por razones tecnológicas o técnicas de implementación. Campos repetidos que son idénticos en su formato y existen para permitir múltiples ocurrencias de un dato.

Desde un punto de vista meramente práctico el proceso de identificación de tipos de elementos de datos se ha resumido en una tabla (ver tabla 6.4) dividida en cuatro columnas: campo de un FLI o FIE propuesto y reglas de conteo (tres columnas). Contabilizar un TED por 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 físicas como simples TED

Campo "AA"

SiMo

SiMo

SiMo

Campo " A B

SiMo

SiMo

SíINo

Campo "AC"

SiMo

SiMo

SíMo

n I O FIE Fichero " Pmeba A"

... Tabla 6.4. Complejidad de FLI y FIE, contabilidad de tipos de elementos de datos. Un Tipo de Elemento de Registro (TER) se define como un subgrupo de elementos de datos reconocibles para el usuario dentro de un FLI o FIE. Existen dos tipos de subgrupos:

-

Opcional. Son aquellos que el usuario tiene la opción de utilizar uno o ninguno de los subgrupos durante un proceso elemental que añade o crea una instancia de datos. Obligatorio. Son aquellos que el usuario debe usar al menos uno de estos subgrupos.

Las reglas a utilizar para identificar TER son dos: Regla 1. Contar un TER por cada subgrupo opcional u obligatorio existente en un FLI o FIE. Regla 2. Si no existen subgrupos, contabilizar el FLI o FIE como un único TER.


173

Desde un punto de vista práctico el proceso de identificación de tipos de elementos de registros se ha resumido en una tabla dividida en dos columnas: FLI o FIE propuesto, subgrupos bien obligatorio, bien opcional reconocido (ver tabla 6.5).

Tabla 6.5. Complejidad de FLI y FIE, contabilidad de tipos de elementos de registros. Para la ejecución de este punto es sumamente beneficioso concretar reuniones con el coordinador de informática correspondiente o responsable funcional ya que nos permite identificar los subgrupos de datos en cada fichero lógico reconocido. Insistimos en que el punto de vista del usuario es fundamental en esta herramienta por lo que su colaboración es imprescindible. Una vez conocidos los tipos de elementos de datos y los tipos de elementos de registros propios de cada fichero lógico podemos establecer el nivel de complejidad apoyándonos en la tabla 6.6.

Tabla 6.6. Asignación de complejidad según TER y TED. Este proceso permite medir la complejidad según una escala ordinal de tres puntos.

EL ANALISIS DEL PUNTO FUNCIÓN

174

2.6.

Conteo de los tipos de función asociado a transacciones

Los tipos de función asociados a transacciones representan la funcionalidad proporcionada al usuario para el procesamiento de datos por una aplicación. Estos tipos de función se dividen en: Salidas Externas (SE), Entradas Externas (EE) y Cuestiones Externas (CE). 2.6. l . Identificación de Entradas Externas

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

175

LA CALIDAD DEL SOFTWARE Y SU MEDiDA

Regla 2. Los datos en un FLI son mantenidos a través de un proceso elemental de la aplicación.

Afirmativo/Negativo

Regla 3. El proceso es la unidad de actividad menor que es significativa para el usuario final.

Afirmativo/Negativo

Regla 4. El proceso es auto-contenido2 y deja la aplicación que está siendo medida en un estado consistente.

AfirmativotNegativo

Regla 5. Para el proceso identificado una de las dos siguientes reglas debe ser

Afirmativo/Negativo

-

Para el sistema el proceso lógico es único en relación a otras Entradas Externas. Para el sistema los elementos de datos identificados son diferentes en relación a otras Entradas Externas.

Tabla 6.7. Identificación de Entradas Externas para datos.

* El concepto autocontenido proviene del entorno en el que se ideó el método APF y es equivalente al de transacción, entendida ésta como interacción con el sistema que permite asegurar la coherencia del sistema después de la finalización correcta o no de dicha transacción.

Afirmativo/Negativo recibida desde fuera de la aplicación.

Regla 2. La información es especificada por el usuario para asegurar el cumplimiento con los requisitos de función del sistema.

Afirmativo/Negativo

Regla 3. Para identificar los procesos, una de las dos siguientes reglas debe ser

Afirmativo/Negativo

Para el sistema, el procesamiento lógico es único en relación con otras Entradas Externas. - Para el sistema, los elementos de datos identificados son diferentes en relación con otras

-

Tabla 6.8. Identificación de Entradas Externas para información de control. 2.6.2.

Identificación de Salidas Externas

Una salida externa (SE) se define como un proceso elemental que genera datos o información de control y son enviados fuera de los límites de la aplicación. Para identificar las Salidas Externas se han de buscar procesos elementales que se encuentren dentro de la definición propuesta. Las transacciones aspirantes se someten, entonces, a un cuestionario. Sólo cuando todas las preguntas tienen respuesta afirmativa podemos resolver que las transacciones estudiadas son SE. Desde un punto de vista práctico la identificación de SE ha resumido en una tabla dividida en tres columnas: procesos propuestos, preguntas tipo, respuestas y un breve comentario (ver tabla 6.9).

EL ANALISIS DEL PUNTO FUNCION

178

límites del sistema.

Regla 2 Un resultado sale de los límites de AfirmativoMegativo la aplicación. Regla 3 Datos son recuperados.

AfirmativoMegativo

Regla 4 Los datos obtenidos no poseen AfirmativoiNegativo datos derivados

I

Regla 5 La EIS unida forma un proceso AfirmativoMegativo que es la menor unidad de actividad que es significativa para el usuario final Regla 6 El proceso elemental es AfirmativoNegativo autocontenido y deja a la aplicación en un estado consistente. 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 lógico en la entrada o salida es Único desde el punto de vista de otras Cuestiones Externas. - Para el sistema los elementos de datos en la entrada o salida son diferentes a otras Cuestiones Externas en la aplicación. ?

Tabla 6.10. Identificación de Cuestiones Externas (CE).

l


2.6.4.

179

Clasificar la complejidad de las transacciones identificadas y su contribución

Una vez identificadas las transacciones se ha de estudiar su complejidad. Esta característica, unida al número transacciones contabilizadas, determinarán la contribución al conteo de los Puntos Función sin ajuste. En el caso de Entradas Externas la complejidad se sustenta en el número de Tipos de Ficheros Referidos (TFR) y los Tipos de Elementos de Datos (TED). Un TFR se define como un FLI leído o mantenido por un tipo de función o un FIE leído por un tipo de función. Un Tipo de Elementos de Datos es un campo no recurrente reconocible para el usuario, mantenido en FLI por una EE. Para contabilizar el número de TFR se han de aplicar las siguientes reglas: Regla 1. Contar un TFR por cada FLI mantenido. Repla 2. Contar un TFR por cada FLI ó FIE leido durante el procesamiento de una EE. Regla 3. Contar una sola vez cada FLI leído y mantenido por una EE. Desde un punto de vista práctico la identificación de TFR se ha resumido en la tabla 6.1 1. Externa

imente mantenido

Tabla 6.11. Complejidad de EE. Contabilidad de TFR. Las reglas para contabilizar un TED son: Repla 1. Contar un TED por cada campo no recurrente y reconocible para el usuario mantenido sobre un FLI por una EE. Regla 2. Contar un TED por cada campo, no aportado por el usuario, pero que es mantenido a través de una EE sobre un FLX.


180

Regla 3. Considerar las siguientes técnicas de implementación para un grupo de campos como un único TED: - Campo lógico almacenado físicamente en muchos campos pero requerido por el usuario como una pieza simple de información. - Campos que aparecen más de una vez en un FLI por causas técnicas o de implementación. - Campos que indican un error ocurrido durante el proceso, o confirman que el proceso ha concluido exitosamente. - Contar un simple TED para la capacidad de especificar la acción a ser realizada por la EE. Desde un punto de vista práctico la identificación de TFR se ha resumido en la tabla 6.12. 'LI.

ei usuaric recurren1

Tabla 6.12. Complejidad de EE. Contabilidad de TED. En el caso de Salidas Externas la complejidad se basa en el número de Tipos de Ficheros Referidos (TFR) y del número de Tipos de Elementos de Datos (TED). Un TFR se define como un fichero leído cuando una entrada externa es procesada. Un TED se define como un campo no recurrente reconocible por el usuario que aparece en una SE. La regla para contabilizar TFR es: Regla 1. Contar un TFR por cada FLI o FIE leído durante el procesamiento de una salida externa. Desde un punto de vista meramente práctico el conocimiento de la complejidad asociada a los TFR para las Salidas Externas se ha resumido en una tabla (ver tabla 6.13).

181


S

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, títulos.. .). Regla 3. No considerar variables de paginación o marcas generadas por el sistema. Regla 4. Considerar las siguientes técnicas de implementación física como un único TED. Regla 4.1. Un campo lógico almacenado físicamente en múltiples campos cuando es requerido por el usuario como una pieza única de información. Regla 4.2. Cada impresión de etiqueta o cada impresión de equivalente numérico en una salida gráfica. Regla 4.3. Información de texto que puede ser una simple palabra, frase o sentencia. Desde un punto de vista práctico el conocimiento de la complejidad asociada a los TED para las Salidas Externas se ha resumido en una tabla (ver tabla 6.14).

gas Externia

iReco el usu recuri

Tabla 6.14. Complejidad asociada a SE, contabilidad de TED.

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

Regla 1. Considerar un TFR por cada FLI o FIE leído durante el procesamiento de la Cuestión Externa. Para la Salida.

Reala 1. Contar un TFR por FLI o FIE leído durante el procesamiento de Cuestiones Externas. fiesde un punto de vista práctico el conocimiento de la complejidad asociada a los TFR para las Cuestiones Externas se ha resumido en una tabla (ver tabla 6.15).

rternas

Tabla 6.15. Complejidad asociada a CE, contabilidad de TFR. Las reglas para contabilizar los Tipos de Elemento de Datos son: Para la entrada

Regla 1. Contar un TED por cada campo no recurrente y reconocible para el usuario que aparece en la entrada de la Cuestión Externas. Regla 2. Contar un TED por cada campo que especifica el criterio de selección de los datos. Regla 3. Considerar las siguientes técnicas de implementación para un grupo de campos como un único TED.

y no

vr física? Considerair un TED

P; I

como m N

ado

Tabla 6.17. Complejidad asociada a CE, contabilidad de TED Una vez identificados para cada transacción los tipos de ficheros referidos y tipos de elementos de datos podemos establecer el nivel de complejidad. Para ello se hace uso de las siguientes tablas.

Tabla 6.18. Asignación de complejidad para Entradas Externas

Tabla 6.19. Asignación de complejidad para Salidas Externas Conocidos los niveles de complejidad (alto, medio o alto) de cada transacción se asigna, según la tabla 6.20, un peso diferente a cada uno de éstos.


185

Complejidad baja

Complejidad media

Tabla 6.20. Contribución al conteo según complejidad. 2.6.5.

Cálculo del valor de los Puntos Función sin ajustar

Con la información obtenida en los pasos anteriores la mecánica a seguir en el cálculo de los Puntos Función sin ajustar es: 1.

2. 3.

Contar el número de ficheros y transacciones identificados agrupando éstos según su complejidad. Multiplicar el número de ficheros y transacciones ya agrupados según su complejidad por el factor correspondiente. Sumar los 15 valores obtenidos.

La ecuación para determinar los Puntos Función sin ajustar es: 15

(Número de items de var iedad i) x ( p e s q) Ecuación 6.7

UFC = i=I

Desde un punto de vista práctico el cálculo de los Puntos Función sin ajustar se determina obteniendo tablas tales como 6.21 y 6.22. Los datos incluidos en las tablas son a título de ejemplo.

186

EL ANALISIS DEL PUNTO FWCIÓN

po de nción

inción

Tabla 6.21. Cálculo de los Puntos Función sin ajustar para Ficheros Lógicos. . ---

Función

.

idos

Medio

Medio

1

Medio

o

X3 = X4= X6=

O 36

X5= X7=

O 42

X3= X4= X6=

27 4 O

Tabla 6.22.Ejemplo del cálculo de los Puntos Función sin ajustar para transacciones.

187


En este caso los Puntos Función sin ajustar se determinarían sumando los factores indicados en la última columna de las tablas asociadas a transacciones y ficheros: UFC = 15

2.6.6.

+ 46 + 36 + 42 +31 =170

Ecuación 6.8

Cálculo del valor del factor de ajuste

El cálculo del Valor del Factor de Ajuste (VAF) se basa en la cuantificación de catorce Características Generales del Sistema (GSC), permitiendo establecer la funcionalidad general de la aplicación medida. La cuantificación es posible al establecerse el grado de influencia de cada factor y hacerla coincidir con una escala que varía desde el valor "5" para una gran influencia, hasta el valor "0" que implica nula influencia. El procedimiento seguido para calcular el valor del factor de ajuste es: a. Evaluar las 14 Características Generales del Sistema sobre una escala de valor mínimo "0" y valor máximo "5". Esta estimación se ha de basar en la influencia de cada una de las 14 características sobre el sisterría medido. b. Determinar el grado de influencia total (TID), sumando el grado de influencia de cada una de las características evaluadas. c. Aplicar la ecuación : VAF = ( TDI

*

0.01 ) + 0.65

Las características del sistema a considerar son: Comunicaciones. Procesamiento distribuido de datos. Rendimiento. Uso elevado de la configuración. Índice de transacciones. Entrada de datos en-línea. Eficiencia y usuario final. Actualización en-línea. 9. Procesamiento complejo. 10. Reutilización. 1 1. Fácil instalación. 12. Fácil operación.

1. 2. 3. 4. 5. 6. 7. 8.

Ecuación 6.9

13. Múltiples 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 cálculo del factor de ajuste es criticado por ser uno de los componentes más subjetivos del Análisis del Punto Función.

2.6.7.

Cálculo de los Puntos Función ajustados

Como indicamos en su momento podemos considerar tres tipos de cálculo según el estado de implantación y desarrollo en que se encuentre la aplicación a medir. Veamos cada uno de ellos y las ecuaciones asociadas a los mismos. Cálculo del Punto Función Ajustado en el caso de Desarrollo de Proyectos. Los componentes que intervienen en el cálculo de la funcionalidad son tres: -

-

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

Ecuación 6.10

Donde: DFP es el valor de los Puntos Función del desarrollo del proyecto. UFP es el valor de los Puntos Función sin ajustar.


189

CFP es el valor de los Puntos Función añadidos por la conversión de Punto Función sin ajustar. VAF es el valor del factor de ajuste. Cálculo de los Puntos Función en el caso de meiora de proyectos. Los componentes que intervienen en este caso son tres:

-

Funcionalidad de la aplicación incluida en los requisitos del usuario para el proyecto. Conversión de funcionalidad. Valor del factor de ajuste.

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

La fórmula que establece el valor inicial de los Puntos Función para una aplicación es: AFP = ADD * VAF

Ecuación 6.12

donde: APF son los Puntos Función para el estado inicial de la aplicación. ADD son los Puntos Función sin ajustar de aquellas funciones que fueron instaladas por el desarrollo del proyecto. VFA es el valor del factor de ajuste. La fórmula se vuelve a calcular una vez un proyecto de mejora haya modificado la funcionalidad de la aplicación. La fórmula utilizada en este caso es: APF = [ (UFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA

Ecuación 6.13

Donde: AFP son los Puntos de Función ajustados. UFPB son los Puntos de Función no ajustados antes de la mejora del proyecto. ADD son los Puntos Función de aquellas funciones añadidas por la mejora del proyecto. CHGA son los Puntos Función sin ajustar de aquellas funciones modificadas por la mejora del proyecto antes de que los cambios ser produjeran. CHGB son los Puntos Función sin ajustar de aquellas funciones modificadas por la mejora del proyecto después de que los cambios ser produjeran. DEL son los Puntos Función de aquellas funciones que han sido borradas durante la mejora del proyecto. VAFA valor del factor de ajuste tras la mejora del proyecto. El International Function Point Users Group posee amplia bibliografía con numerosos ejemplos prácticos que colaboran en gran medida en el conocimiento de este tipo de medidas. A modo de resumen y como guía práctica aportamos el siguiente cuadro:

191


Determinar tipo de

Identificar límites

Identificar FLI

Identificar FIE

Leyenda Se aconseja participación del responsable funcional. Requiere cumplimentar formulario Figura 6.1. Esquema aplicación Análisis Puntos Función.

192


3. MÁS ALLÁ DEL ANÁLISIS DEL PUNTO FUNCIÓN TRADICIONAL

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

Capítulo 7 LA NORMA ISODEC 9126 Y LA MEDIDA DE LA CALIDAD La calidad permite dar confianza a los clientes y a los proveedores, dar confianza interna y aprovechar la experiencia intelectual.'

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

La calidad de un programa informático es un atributo complejo, compuesto de otros muchos atributos, incluso diferentes según el observador. El responsable de sistemas de una organización considerará un programa de gran calidad si consume poco recursos técnicos tales como servidores o líneas de comunicación y los utiliza eficientemente, el usuario hará hincapié en las funciones del programa y en la inexistencia de errores en tiempo de ejecución, el responsable de la cuenta de resultados de la empresa que desarrolla la aplicación considerará que el programa es bueno si se han obtenido unos ingresos adecuados al esfuerzo realizado. Como vemos cada actor considera la calidad del software según su punto de vista, sus expectativas y necesidades. Los modelos utilizados para la medida de la calidad del

'

Juan Izquierdo. "La calidad del software asignatura pendiente en España". Computenvorld, 7-13 septiembre de 2001.

LA NORMA ISOIIEC 9126

194

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

La descomposición jerárquica en árbol

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


195

Calidad del software

Factores de calidad

Criterios de calidad

Medidas del software

Figura 7.1. La medida de la calidad del software a través de la descomposición jerárquica. Se pueden considerar dos aproximaciones diferentes a la hora de implantar un modelo de calidad [Kan, 20031. Por un lado podríamos realizar una aplicación rígida de un modelo prefijado en el que los factores de calidad son aportados por el modelo seleccionado. Por otro lado podemos considerar una aproximación en el que el modelo de calidad se establece por acuerdo entre usuario e ingeniero de software y, por tanto, los atributos de calidad son seleccionados por éstos, así como la descomposición en factores y las correspondientes métricas de calidad. La relación entre factores y criterios de calidad es establecida también por usuarios e ingenieros de software aunque generalmente se escoge algún modelo existente en el mercado al que se le suele incluir variaciones puntuales. Insistimos en la importancia de


196

la experiencia del responsable de la calidad del software y la relación que debe establecer entre medidas a realizar y criterios de calidad. 1.2.

Modelos de McCall y Boehm

Los modelos de McCall y Boehm son dos ejemplos clásicos de la utilización de la descomposición jerárquica para la medida de la calidad. El modelo de McCall es uno de los más antiguos y extendidos [McCall, 19771 y ha sido tomado como ejemplo y referencia para otros modelos e iniciativas de medida de la calidad del software. Modelo de McCall

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

Operación del Producto

Revisión del Producto

Transición del Producto

-

Factores Facilidad de uso. Integridad. Corrección. Fiabilidad. Eficiencia. Facilidad de mantenimiento. Facilidad de prueba. Flexibilidad. Facilidad de reutilización. Interoperabilidad. Movilidad.

Tabla 7.1. Factores del modelo de McCall.


Facilidad de mantenimiento ¿Puedo arreglarlo? Facilidad de prueba ¿Puedo probarlo? Flexibilidad ¿Puedo modificarlo?

197

Interoperabilidad ¿Puedo relacionarlo con otros sistemas? Movilidad ¿Puedo utilizarlo en otra máquina? Reutilización ¿Puedo volver a utilizar parte del

Corrección ¿Hace el programa lo que quiero? Fiabilidad ¿Lo hace de forma exacta todo el tiempo? Eficiencia ¿Se ejecutará sobre el soporte físico de forma óptima? Facilidad de uso i,Puedo utilizarlo?

Figura 7.2. Modelo clásico de calidad del software propuesto por McCall. La operatoria para la obtención de un resultado numérico relacionado con uno de los puntos de vista propuesto por McCall es descomponerlo hasta la obtención de medidas cuya combinación preemitiría la cuantificación de la calidad. Debemos determinar los factores asociados a la Operación, Transición o Revisión que influyen en la calidad, éstos se encuentran identificados por el modelo, una vez seleccionados los factores se han de obtener las medidas asociadas a cada criterio. Para ello se hace uso de una lista de comprobación con objeto de conocer si se aplica a los requisitos (R) al diseño (D) o a la implementación (1). La figura 7.3 nos muestra alguna de las preguntas tipo de la lista de revisión utilizada para el criterio de calidad "nivel de cumplimiento" dentro del factor de calidad "corrección".


198

Respuesta: S í N o

Preguntas

R 1

¿Hay referencias ambiguas?

2

¿Todas las funciones definidas son utilizadas?

D

I

(-1 Figura 7.3. Pregunta tipo de una lista de comprobación para criterios de calidad. Las letras R, D, 1, indican si la lista de comprobación es aplicable a los requisitos (R), al diseño (D) y10 la implementación (1). Se ha de responder SíNo a cada pregunta de la lista para cada uno de los criterios. McCall propone para cada criterio una fórmula de regresión del tipo:

Medida criterio = r, m , + r,m,

+ ... + rnmn

Ecuación 7.1

Donde r, identifica los coeficientes de regresión y mj representa las distintas métricas asociadas al criterio. Es habitual normalizar el resultado de las medidas a valores entre O y 1 buscando la coherencia de los resultados. Algunas medidas propuestas en el modelo son: U

Fiabilidad = 1 - ( número de erroreslnúmero de líneas de código)

o

Facilidad de mantenimiento = 1 corrección)

o

Movilidad = 1 - (esfuerzo para trasladarlesfuerzo para implementar)

U

Flexibilidad = 1 - 0,05 (número medio de días-hombre por cambio)

-

0,1 (número medio de días-hombre por

Las medidas propuestas pueden ser modificadas según el criterio del técnico. Es muy habitual el uso de la medida de la fiabilidad considerando el número de errores por el tamaño de la aplicación contabilizados según el número de puntos


199

función. El nivel de subjetividad de la medida es uno de los problemas a resolver por parte de la ingeniería del software. Todos deben medir lo mismo y de la misma forma. Modelo de Boehm

Independencia

Figura 7.4. Modelo de Boehm para la descomposición de la calidad del software.

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 técnico o el usuario de la aplicación. Los criterios y factores son determinados y fijos de forma que la medida de la calidad debe ajustarse a estas definiciones y a las relaciones entre criterios y factores de calidad que el modelo propone. El modelo de Boehm junto con el de McCall representaron los primeros intentos por cuantificar la calidad del software como producto a través de la descomposición jerárquica en árbol.

2. LA NORMA ISOIIEC 9126

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


20 1

adaptación de la norma. En esta versión se introdujeron los conceptos de calidad interna y calidad externa. Igualmente se creó una nueva norma, ISOIIEC 14598, que asumía el modelo del proceso de evaluación antes incluido en la propia norma ISOIIEC 9126. La norma ISOIIEC 9126 posee cuatro partes:

-

-

Parte 1: Modelo de la calidad. Parte 2: Métricas internas. Parte 3: Métricas externas. Parte 4: Calidad en las métricas de uso.

Sin embargo sólo la parte primera, modelo de calidad, es un estándar aprobado y publicado siendo el resto de partes de la norma informes que se encuentran en la denominada fase de Technical Report (TR). Por tanto estudiaremos en profundidad la primera parte como base de nuestra propuesta de medida de la calidad. Calidad de uso, interna y externa

2.1.

La norma define un modelo de calidad basado en dos partes bien identificadas:

-

-

La calidad interna y externa. La calidad de uso.

La calidad interna, entendida como "la totalidad de las características del producto software desde un punto de vista interno", y la calidad externa definida como "la totalidad de las características de producto software desde un punto de vista externo" influyen en la calidad del proceso, al mismo tiempo que la calidad de uso influye sobre las anteriores. Calidad interna, externa y de uso están relacionadas, una se sustenta en la otra como capas sucesivas. La calidad del proceso influye en la calidad del producto que a su vez es relevante en la calidad de uso.


202

I

Calidad del proceso

1

---F

Medida del

---+

Calidad interna

Calidad externa

Calidad de uso

--+

roces so

Medida interna

Medida externa

-b

Medida de la calidad de uso

Figura 7.5. Modelo de calidad según ISOIIEC 9126.

La calidad de uso es definida por la norma como "la capacidad del software que posibilita la obtención de objetivos específicos con efectividad, productividad, satisfacción y seguridad". Es interesante observar como la norma ISOIIEC 9126 aborda el conocimiento de la calidad dividiéndolo en calidad interna o externa de forma similar a como se propone por Fenton y que ya explicamos en el capítulo 2. En este caso los conceptos de atributos internos y externos son menos definidos en la norma que en la aproximación de Fenton y no coinciden en su totalidad con esta teoría, sin embargo se observa una aproximación similar al problema considerando diferentes "niveles" en la calidad que se influyen entre sí.


203

Figura 7.6. Modelo de calidad según ISOIIEC 9126. La definición de cada uno de las características y subcaracterísticas es:

Funcionalidad. Se define como un conjunto de atributos que atañen a la existencia de un conjunto de funciones y sus propiedades específicas. Estas funciones son las que satisfacen las necesidades implícitas y establecidas. Esta característica del software puede ser desglosada en varias subcaracterísticas: o

o o o o

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

Fiabilidad. Conjunto de atributos que atañen a la capacidad del software para mantener su nivel de prestación bajo condiciones establecidas durante un tiempo establecido. Se descompone en las siguientes subcaracterísticas:


204

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 recuperación. Capacidad para restablecer el nivel de rendimiento y de recuperación de datos afectados directamente en el caso de un fallo. Adherencia a normas. Capacidad del software relacionada con el grado de conformidad con estándares, convenciones o regulaciones existentes en leyes o prescripciones similares.

o o o

o

Facilidad de uso. Capacidad del producto software de ser entendido, aprendido, usado y atractivo al usuario, cuando es utilizado bajo ciertas condiciones especificadas. o

Fácil comprensión. La capacidad del software que permite al usuario comprender si el producto es aceptable y cómo puede ser usado para tareas particulares y determinadas condiciones de uso. Fácil aprendizaje. Capacidad del producto software que permite al usuario aprender la aplicación software. Operatividad. Capacidad del producto software que permite al usuario controlar y usar la aplicación 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 estándares, convenciones o regulaciones existentes en leyes o prescripciones similares.

o o o o

Eficiencia. Capacidad del producto software para proporcionar un rendimiento apropiado relacionado con el total de recursos utilizados bajo condiciones establecidas. o ..

o

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 número de recursos y tiempo de ejecución cuando el software desarrolla sus funciones bajo condiciones establecidas. Adherencia a normas. Capacidad del software relacionada con el grado de conformidad con estándares, 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 análisis. Capacidad del producto software para diagnosticar deficiencias o causas de fallos en el software. Capacidad para cambios. Capacidad del producto software que permite la ejecución de una modificación específica 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 estándares, 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 organización.

o

o 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 instalación. Capacidad del producto software para ser instalado en un entorno específico. Coexistencia. Capacidad del producto software de coexistir con otros programas independientes en un entorno común y compartiendo recursos también comunes. Facilidad de reemplazo. Capacidad del producto software de ser utilizado en lugar de otro producto software específico para el mismo propósito que éste y en un entorno similar. Adherencia a normas. Capacidad del software relacionada con el grado de conformidad con estándares, convenciones o regulaciones existentes en leyes o prescripciones similares.

206

LA NORMA ISOlIEC 9126

La calidad de uso, de forma gráfica:

Calidad de uso

1

Eficacia

1

Productividad

1

Seguridad

1'

Satisfacción

1

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

Las características en las que ISOIIEC 9126 descompone la calidad son influidas por atributos internos y externos propios de dichas características. Los atributos internos son indicadores de los atributos externos. Un atributo interno puede influir a una o más características y una característica puede verse influida por uno o más atributos (ver figura 7.8). Las características y subcaracterísticas son medidas, por tanto, a través de sus correspondientes atributos. De nuevo observamos un paralelismo con la propuesta de Fenton en la que se proponía la medida de entidades propias del software a través de la cuantificación de sus atributos, también identificados como internos y externos (ver capítulo 2).


207

La norma ISOIIEC define las métricas internas como aquellas medidas que se realizan sobre un producto software no ejecutable, tal como la norma indica "un producto software intermedio debería ser evaluado usando métricas internas". Las métricas externas son medidas del producto software obtenidas del comportamiento del sistema en la fase de ejecución del mismo. Finalmente las métricas de la calidad de uso, como tercer gran concepto propuesto por la norma, mide la extensión en la que un producto alcanza las necesidades expuestas por el usuario de forma específica en relación a los objetivos de efectividad, seguridad, productividad y satisfacción.

Subcaracterística

Característica

Figura 7.8. Atributos y características según la norma ISOIIEC 9126.

3. PROCEDIMIENTO DE MEDIDA PROPUESTO

Como colofón de este capítulo explicamos el procedimento de medida basado en la realización de un conjuto de pasos o fases destinados a la cuatificación de un atributo seleccionado. Este apartado es consecuencia de la recopilación y estudio de diferentes fuentes; la norma ISOIIEC 9126, la metodología MÉTRICA Versión

LA NORMA ISOIIEC 9 126

208

3. (se estudia en detalle en el capítulo 4) y las aportaciones recogidas de diferentes autores entre los que destaca la propuesta por el profesor Norman E. Fenton. En concreto se pretende medir la calidad de un programa informático en explotación. Para obtener datos cuantitativos se procederá a descomponer el atributo a estudiar en criterios de calidad de más bajo nivel tal y como hemos presentado en la descomposición jerárquica explicada. Con el objetivo de ser lo más didáctico posible se tomará el atributo "madurez" como ejemplo de propiedad del software que se desea medir y se explicarán los pasos diseñados tanto desde un punto de vista genérico como considerando la medida de este atributo en concreto. El procedimiento, evidentemente, puede ser utilizado para cualquier atributo que se pretenda cuantificar. Un primer paso del proceso de medida es la identificación del atributo a medir. Cuantificar el atributo será el resultado final del proceso. El uso de una metodología de desarrollo, en este caso MÉTRICA Versión 3, será básica para el cumplimiento de este primer paso. La tarea denominada "EVS 3.2: identificación de requisitos" y "EVS 3.3: catalogación de requisitos" se propone sean utilizadas para el cumplimiento de este punto del procedimiento (ver figura 7.9). La necesaria identificación de requisitos exigida por MÉTRICA Versión 3 se integra, por tanto, en el proceso de medida diseñado. Esta integración permite al técnico identificar fácilmente los atributos de calidad que se deseen cuantificar en la aplicación por estar expresamente indicados en los requisitos del sistema y claramente documentados. En un segundo paso se ha de diseñar el proceso de evaluación. Se divide en tres apartados: Selección de métricas de calidad. Evidentemente estas métricas están directamente relacionadas con los requisitos identificados en el primer paso. Haciendo uso de la descomposición jerárquica según el modelo Goal Question Metrics y basándonos en la norma ISO 9126 es posible la selección de métricas adecuadas al atributo estudiado. Siguiendo con el ejemplo propuesto, partiendo del concepto de "calidad de uso" según la norma ISOIIEC 9126, nuestra atención se centra en el atributo de calidad denominado "seguridad". Con objeto de concretar este atributo de alto nivel utilizamos la descomposición jerárquica escogiendo la "fiabilidad como atributo de más bajo nivel. Finalmente es el criterio "madurez" el objetivo de nuestro estudio. La medida del atributo madurez se obtendrá según la ecuación 6.6 tomando como medida del tamaño del software el número de puntos función como alternativa al habitualmente utilizado número de líneas de código.


209

Tasar el nivel de dejhición. Se han de definir en esta fase las escalas propias de las medidas a realizar. Las escalas han de ser divididas en rangos de acuerdo a niveles de satisfacción de los requisitos. Se suele elegir una escala 1-10 con objeto de adecuar la evaluación a la medida utilizada en la práctica común de métodos de evaluación habituales. Valorar la definición de los criterios. Se basa en preparar procedimientos que permitan resumir los resultados de la evaluación de las diferentes características. En este punto también se han de tener en cuenta factores propios de la administración de recursos tales como coste y esfuerzo requerido. Es necesario estimar el esfuerzo por parte de la organización. El procedimiento de medida, el almacenamiento de los datos o el cálculo del esfuerzo necesario para la realización de la medida puede ser ejecutada con los mecanismos o herramientas que el técnico considere. En el segundo punto el procedimiento propuesto hace uso, de nuevo de la metodología MÉTRICA Versión 3, en concreto en su apartado EVS-CAL 1.3. "Identificación de las propiedades de la calidad". La información aportada es valiosa al establecer los atributos (propiedades según la nomenclatura de MÉTRICA Versión 3) que, bien complejos, bien simples, permitirán establecer las correspondientes medidas. Como tercer paso se establece la evaluación del atributo. Este proceso se basa en los anteriores. En él se realizan medidas de los atributos seleccionados según las escalas acordadas. El procedimiento propuesto es original al integrar estándares internacionales como ISO 9126, metodologías de desarrollo como es el caso de MÉTRICA Versión 3 y el procedimiento de descomposición jerárquica denominado Goal Question Metrics con el objetivo de la medida de la calidad del software. La incorporación de ejemplos en este libro tiene por objeto, no sólo la expresión práctica de la teoría presentada en los apartados anteriores, sino la de ser una forma alternativa de incluir nuevos conocimientos. Enfrentarse a la ejecución en un entorno real de conceptos y teorías implica plantearse nuevas incógnitas que deben resolverse. Muchas dudas surgen en la aplicación práctica de la teoría, aunque ésta haya sido extensamente explicada. Al final de este capítulo se ha propuesto un ejemplo extraído de la realidad.

210


METRICA Versión .3

Se apoya en Definición de requisitos

f

Selección de métricas

ISO 9126

Selecciona

Valoración del criterio

Métricas

J

Obtiene

m Medida

Figura 7.9. El procedimiento de medida propuesto.


211

4. LA MEDIDA DE LA FIABILIDAD DE UNA A P L I C A C I ~ N INFORMÁTICA. EJEMPLO PRÁCTICO

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

Definición de requisitos de calidad

La metodología MÉTRICA Versión 3.0 considera en su interfaz de calidad o interfaz CAL un marco común de referencia para la definición de planes de aseguramiento de la calidad. Parece lógico, por tanto, apoyarnos en la propia metodología para obtener los requisitos de calidad del producto software a desarrollar (figura 7.10). METRICA V 3.0

Se apoyaen

,vscAL,

Definición de requisitos

Figura 7.10 Definición de requisitos de calidad.

E"I

CAL

,

212


La actividad EVS-CAL~:IDENTIFICACIÓNDE LAS PROPIEDADES DE CALIDAD DEL SISTEMA, sería la tarea a considerar en este primer punto. La identificación de las propiedades de la calidad estarían asociadas al proceso EVS (Estudio de Viabilidad del Sistema) y, por tanto se realizaría en los primeras fases del desarrollo software. Si consideramos en detalle la tarea EVS-CAL1, MÉTRICA Versión 3.0 la descompone en las siguientes actividades:

Determinación de los Sistemas

EVS-CAL 1.3

1 de Calidad

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

213


requerimientos del usuario. No podemos plantear un proyecto sin la colaboración y autoexigencia de quien va a utilizarlo. 4.2

Preparar la evaluación

El segundo punto a realizar es la preparación del proceso de evaluación. Esta fase se divide a su vez en tres apartados:

o O

o

Selección de métricas. Tasar. Valoración del criterio. METRICA V

3.0

Se apoya en

Preparación evaluación

0:.

1


Utiliza

e

-

\

\ Se basa

Tasar

en

Selecciona

m Métricas

Figura 7.11 Procedimiento de medida propuesto, paso segundo.

214


4.2.1.


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

Figura 7.11. El criterio madurez en el modelo de calidad ISOIIEC 9126.

La densidad de defectos se obtiene a través de la ecuación:

Número de fallos detectados en el Tamañodel pro grama

programa

Ecuación 7.1

El numerador es una cantidad fácil de cuantificar aunque es necesario establecer cierta disciplina con el fin de recoger datos objetivos. En el ejemplo propuesto, obtenido de una experiencia real, se involucró al usuario de forma directa


215

solicitándole que indicara los fallos detectados en el programa en tiempo de ejecución. La recopilación de incidencias de la aplicación estudiada se realizó por parte del coordinador informático (usuario avanzado interlocutor del jefe de proyecto). Toda incidencia detectada se ponía en conocimiento del responsable del proyecto quien, en colaboración con el coordinador clasificaba la incidencia según el siguiente protocolo: o

Incidencia provocada por la necesidad de cambios en el programa inforrnático para mejorarlo o adaptarlo a nuevas necesidades del usuario.

o

Incidencia provocada por un fallo en el programa debido a un defecto en el software. En este segundo caso se estableció la siguiente escala:

o

Fallo muy grave. Implica la paralización total del sistema.

o

Fallo grave. Implica la paralización total de uno o varios programas.

o

Fallo leve. Implica un mal funcionamiento de uno o varios programas sin necesidad de suspender su ejecución.

El resultado final de la contabilidad de incidencias se recoge en la tabla 7.3. Con relación al denominador es habitual considerar el tamaño de una aplicación informática obteniendo el número de líneas de código. Ya hemos comentado los severos problemas que esta medida posee por lo que consideramos el tamaño de la aplicación en números de puntos función.


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 satisfacción. Con objeto de capturar esta información es necesario dividir en diferentes grados de satisfacción los resultados obtenidos [ISO/IEC 91261. En el caso que nos ocupa lo más trascendente es la exigencia del coordinador informático de no aceptar la aplicación si se detectaba un error definido como muy grave. Esta consideración exigía una escala todohada de forma que cualquier error de estas características (muy grave) tenía como consecuencia la no aceptación del producto informático. Con objeto de realizar un estudio más detallado de las medidas obtenidas se fijó además otra posible escala

217


considerando los niveles de satisfacción como muy satisfactorio, satisfactorio e insatisfactorio, según la siguiente figura:

.. . . . . . . . . . . . . . . . . . .. .. .. .

4

Muy Insatisfactorio

. . . . . . . . . . . . . . .. . .. . .. . .. . ... ... .................... . . . . . . . . . . . . . . . . . . . .. .. .. . . . . .. .. .. .. .. .. .. .. .. . . . . ....... . . ..~atiSfactorio.. . . . . . . . ..... . . . ... ... ... ... ... ... ... ... ... ... ... ... .. . . . . . . . . . . . . . . . . . . .. .. .. .. . . . . . . . . . . . . .

. ... ... ... ... ... ... .. . .. . .. . .. . .. . .. . .. . . . . . .. .. .. .. .. .. .. .. .. .. . Insatisfactorio . .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . .. .. .. . . . . . .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . .. .. .. .. .. .. . . . . . . . . . . .

0,5

1,o

b

Densidad de defectos

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

4.2.3.

Valoración del criterio

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

218


Este apartado está dirigido a la estimación de los recursos humanos y técnicos necesarios para la realización de la medida. En el caso que nos ocupa el número de técnicos informáticos, de usuarios finales y su dedicación se expresan en la tabla 7.4.

Tabla 7.4. Estimación del personal y dedicación. De nuevo nos encontramos con la necesaria experiencia del responsable del proyecto para el cálculo de los recursos necesarios. Como podemos observar en la tabla 7.4, se incluye de forma expresa la participación del coordinador informático con dedicación parcial y una estimación de 16 horas en total. Una vez identificados los integrantes del equipo de trabajo es imprescindible establecer un protocolo de actuación para la recopilación de los datos. El procedimiento debe ser aprobado por el responsable e informado al resto del equipo. En el caso que nos ocupa el procedimiento consta de 4 tareas básicas: 1. El coordinador informático aporta información detallada sobre las incidencias recopiladas durante un período de tiempo determinado haciéndoselas llegar al responsable del proyecto. Esta información debe ser trasmitida por escrito y haciendo uso de una plantilla estándar en la que se recoja la información necesaria. 2. El programador informático (sistemas-desarrollo) realiza la contabilidad de los puntos función de los programas. Esta tarea es independiente del punto (1). 3. El operador traslada la información a tablas y estadillos para el futuro análisis de los datos. La información enviada por el coordinador informático y por parte de los programadores se utiliza para el cálculo de la densidad de defectos. Es un proceso de cálculo simple. 4. Semanalmente el responsable del proyecto realiza una reunión de control con los agentes implicados y dirige esfuerzos según los trabajos desarrollados y la posible existencia de desviaciones de los tiempos estimados.


219

La obtención de datos cuantitativos culminará con el análisis de los mismos y la propuesta de actuaciones según los resultados obtenidos. Hemos de considerar que los datos no son un fin en sí misino, sino un medio para la toma de decisiones sobre bases objetivas. En este caso la decisión es tan crítica como la aceptación o no de una aplicación informática ya desarrollada y en fase de explotación. 4.2.4.

Obtención de medidas

El resultado final del proceso establecido es la obtención de los datos cuantitativos. Según establecimos en el punto 4.2.1, la ecuación 7.1 y la tabla 7.3 nos proporcionarían parte de la información necesaria para la cuantificación de la fiabilidad. El denominador de la ecuación se obtendría ejecutando el Análisis del Punto Función. El resultado de la medida del tamaño de la aplicación informática es: Tamaño aplicación = 90,984 puntos función ajustados Por lo que la densidad de defectos de la aplicación es: 1190,984 = 0,011 10190,984 = 0,110 Con las siguientes unidades: 0,011 incidencias graves por puntos función 0,110 incidencias leves por puntos función En ambos casos, considerando los dos tipos de incidencias, la aplicación se considera aceptable para el usuario. La aplicación, por tanto, cumple los requisitos exigidos.

Capítulo 8 MÉTRICAS DEL SOFTWARE En cualquier sector económico, el disponer de información cuantificada resulta vital para mejorar en el mundo competitivo de los negocios. En la industria del software, la utilización de las métricas comienza a valorarse debido a los excelentes resultados obtenidos con su implantación'

La búsqueda de la calidad como elemento competitivo en la industria del software implica saber en qué situación se está y planificar cómo mejorar. Para ello no basta conocer aspectos cualitativos si no se cuantifican adecuadamente. Numerosos estudiosos de la calidad del software investigan en este campo y proponen continuamente medidas de aspectos y características de la calidad del software, no siempre de acuerdo con la norma ISO 9126. Actualmente, el desarrollo de las métricas se encuentra en un momento de cierta confusión, necesitando muchas de ellas de validación tanto teórica como empírica. En muchos casos la medida obtenida no se sabe a qué característica de calidad afecta ni de qué forma. En este capítulo se presentan, aunque no de forma exhaustiva, las métricas más utilizadas.

1. MÉTRICAS E INDICADORES DE LA PRODUCTIVIDAD A pesar de que el software no posee entidad material, la cuantifícación de su tamaño fue una de las primeras medidas propuestas, y ha sido ampliamente utilizada por los ingenieros de software, bien como un valor en sí mismo, bien como un elemento clave para determinar otros atributos tales como complejidad,

' Marta D'Amore Benito. Ingeniero de Telecomunicaciones por la UPM, especiiista en Calidad del Software. ¿Para qué las métrica? Boletín Interno Tecnológico de Indra. Madrid.

MÉTRICAS DEL SOFTWARE

222

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

Medida del tamaño

La medida tradicional de este atributo (tamaño de una aplicación) se ha fundamentado en el número de líneas de código. Aún es habitual utilizar como medida de la productividad generada por un técnico el número de líneas de código por número de unidades temporales consideradas (días, horas, meses). Las ecuaciones más habituales en la medida de la productividad2 [Kan, 20031 son: Productividad =

Productividad =

Tamaño Esfuerzo

Ecuación 8.1

Líneas de código Personas - mes

Ecuación 8.2

Por otro lado, las medidas más habituales utilizadas para cuantificar el tamaño de una aplicación informática son: Líneas de código El número de líneas de texto que componen el código fuente de un programa ha sido la medida más utilizada en la cuantificación del tamaño del software, entendido éste como un atributo interno de un producto. Es una medida fácil de obtener y manipular, además, ha sido considerada como factor clave de otros atributos como ocurre en el caso de la productividad. Las líneas de código, expresadas como LOC (del inglés Lines of Code), presentan, sin embargo, ciertos problemas que se ponen de manifiesto en las siguientes preguntas:

La productividad es un atributo externo de los recursos, en concreto del recurso personal [Fenton y Pfleeger, 19971.

223


-

-

¿Se han de considerar los comentarios y las líneas en blanco en la contabilidad de las líneas de código de un programa? ¿Es equivalente el número de líneas de código contabilizado en un lenguaje de programación u otro? ¿Se han de considerar todas las instrucciones, o pueden obviarse definiciones de constantes y variables? Al igual que se hace con el código fuente ¿Puede utilizarse esta medida para otros documentos propios del desarrollo software tales como requisitos o diseño del programa? ¿Influye la tecnología a utilizar en la contabilidad de las líneas de código? Hay instrucciones que pueden necesitar más de una línea de código fuente, o por el contrario pueden existir diferentes instrucciones en una línea, ¿no sería necesario considerar el impacto de este hecho?

Hacer uso de esta medida requiere la definición de lo que entendemos por línea de código. De esta forma superaremos algunas ambigüedades respondiendo a varias preguntas anteriores. Una Iínea de código se define como: Cualquier línea de texto del programa excluyendo comentarios y líneas en blanco. En muchos casos es interesante considerar también el número de líneas de comentarios que posee un programa ya que, aunque no son comandos necesarios para la ejecución del mismo, sí son una fuente de información muy útil que pueden influir en las posteriores modificaciones o en el mantenimiento de dicho programa. Así las líneas de código sin considerar los comentarios se especificarán como NLOC, y aquellas que consideren los comentarios se definen como CLOC. El número de líneas totales sería: LOC = CLOC + NLOC

Ecuación 8.3

Una medida de la densidad de comentarios sería:

d=-CLOC LOC

Ecuación 8.4

Algunos investigadores han propuesto el carácter como medida alternativa a las líneas de código [Fenton, 19921. Sería una medida simple de coleccionar y la

conversión del número de caracteres en líneas de código sería extremadamente fácil.

LOC =

node cavácteres a

Ecuación 8.5

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

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


225

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

MÉT~UCASDEL SOFTWARE

226

1

1 por Punto Función 1

1 Basic Clipper Fortran 90 Natural Lenguaje Máquina

3.00 17.00 4.00 6.00 0.50

107 19 80 53 640

Tabla 8.1. Niveles de lenguajes según Caper Jones.

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

Ecuación 8.6

donde S, es el código reutilizado, S, el código nuevo y a es un factor de ajuste que se obtiene en función del grado de modificación sufrido por el diseño (DM) y el código (CM) y del correspondiente esfuerzo de integración (IM) según la ecuación:


227

a = 0.4(DM) + 0.3(CM) + 0.3 ( IM)

Ecuación 8.7

el máximo valor de a es de 100, en este caso se asumiría que adaptar el código es similar en cuanto al esherzo a reescribirlo. Thebaut presenta una modificación a esta ecuación aplicando un exponencial a uno de los factores según la ecuación:

S, = S,

+ S ,k

Ecuación 8.8

donde valor de k es mayor que cero y menor o igual a uno.

1.2.

Medida de la Productividad

Uno de los primeros objetivos de la medida del software es el control y valoración de la labor realizada por el equipo de desarrollo.

Hombre-Mes La industria tradicional posee una herramienta simple y efectiva que le permite valorar el trabajo de sus operarios. Conociendo el número de unidades realizadas por un trabajador y el tiempo empleado para tal fin se puede obtener una exacta medida de la productividad de dicho trabajador. Si a esto le añadimos un control de la calidad del producto realizado, obtenemos una medida fiable, sencilla y enormemente útil de la productividad industrial. Esta noción de la productividad y su mediada se ha intentado trasladar al desarrollo de programas informáticos. Si conocemos el monto total del producto obtenido, en este caso el tamaño del programa, y el esfuerzo necesario para su desarrollo, generalmente expresados en personas-mes, sería simple medir la productividad del equipo de desarrollo según la fórmula:

Tamaño de salida Personas - mes

Ecuación 8.9

Haciendo la sustitución del numerador por cualquiera de las medidas del tamaño del software propuestas en el apartado anterior se obtendría la productividad de un programador o del equipo de desarrollo. La productividad es la medida de un atributo externo propio de un recurso. Se habla de la productividad (atributo externo) del equipo de desarrolladores (recurso) al realizar el desarrollo de cierto programa (producto). Se valora al equipo de profesionales no al proceso de desarrollo. Pero la medida hombre-mes tiene muchos problemas. Según Brooks, "El Hombre-Mes, como unidad para medir la magnitud de un trabajo, es un mito peligroso y equivoco. Implica que los hombres y los meses son intercambiables. Los hombres y los meses son bienes intercambiables sólo cuando una tarea puede repartirse entre varios empleados sin que sea necesaria una comunicación entre ellos. El coste varía, de hecho, como el producto del número de personas y el número de meses. El avance, no". En las tareas que pueden repartirse y que además requieren una comunicación entre subáreas, debe añadirse al total del trabajo a realizar el esfuerzo de comunicación. La frontera de comunicación que se ha añadido, se compone de dos partes: la formación y la intercomunicación. La formación de los trabajadores incluye la tecnología, los objetivos del trabajo, la estrategia general y el plan de trabajo. Este esfuerzo varia linealmente con el número de trabajadores. El esfuerzo de intercomunicación incluye la coordinación de tareas, las reuniones de resolución de problemas, etc..

Puntos Función La medida más utilizada en el caso del tamaño del software ha sido el número de líneas de código, por lo que la productividad ha venido indicada en la mayoría de los casos en términos de líneas de código por persona y mes. Las ventajas e inconveniente que presentaba la media del tamaño en términos de LOC se traslada, por tanto, a la medida de la productividad. Frente a la sencillez de su contabilidad aparecen serias dudas de su bondad según el lenguaje de programación utilizado o la falta de representación de la productividad del equipo de desarrollo al ser fácilmente alterable añadiendo líneas de código innecesarias o de poca utilidad. La alternativa es el uso de los Punto Función, según la ecuación:

Número de Puntos Función personas - mes

Ecuación 8.10

229


El uso de esta ecuación posee la ventaja de que puede obtenerse en cualquier momento del desarrollo del software evaluando la productividad en fases diferentes y con la ventaja de hacer uso de una medida del tamaño del software más cercana a la visión del programador. Errores Otro factor que afecta a la productividad es la calidad del producto obtenido. En el caso de un producto industrial es sencillo aplicar procedimientos estadísticos que determinen de forma muy aproximada el número de unidades defectuosas resultado de cierto proceso y realizado por cierto equipo. El control estadístico se basa en la obtención de un producto estandarizado, con idénticas características. Este hecho no puede darse en el software por lo que el control de la calidad debe basarse en medidas propias de esta actividad.

Calidad =

número de errores IUOC

Ecuación 8.1 1

Documentación Es habitual recoger datos sobre la documentación aportada por el equipo de trabajo. Se ha de considerar la información suministrada con el programa un factor más para evaluar la productividad. Suele expresarse según la ecuación:

número de paginas KLOC

Ecuación 8.12

Es muy difícil cuantificar la documentación, generalmente compuesta por texto, gráficos o esquemas, por lo que la ecuación 8.12 es muy criticada. También es interesante considerar el código reutilizado y obtener medidas que lo consideren como las estudiadas en el punto anterior. Nivel de lenguaje Una aproximación algo más sofisticada a la productividad es la propuesta por Capers Jones apoyada en el concepto nivel del lenguaje (ya introducido en el

apartado anterior). Para este investigador la productividad se encuentra relacionada con el nivel del lenguaje aunque no de forma lineal. La tabla 8.2 aporta datos numéricos a esta relación.

Tabla 8.2. Productividad y nivel de lenguaje. Como resumen de este apartado hay que indicar que la productividad no puede determinarse exclusivamente como una expresión que envuelva el tamaño de la salida y el número de personas involucrada en dicha tarea. Debe considerarse la calidad del producto resultante. Se han de realizar una batería de medidas en las que se han de incluir datos relacionados con el tamaño del programa resultante, personal implicado en el proceso, coste del mismo y la calidad resultante.

A continuación se presentan medidas que se han establecido como valores de singular importancia en la medida de la calidad del software. En este apartado se han incluido medidas relacionadas con la calidad, así como otras aproximaciones como es el caso de la medida de la complejidad propuesta por McCabe o la Ciencia del Software ideada por Halstead. La medida de McCabe se ha incluido por la trascendencia que la complejidad del software posee en relación a la calidad. 2.1.

Densidad de defectos e indicadores de calidad del proceso

Uno de los principales objetivos de administradores e ingenieros de software es la producción de software libre de defectos, de tal forma que su utilización diaria esté exenta de errores. Esta concepción tiene una clara incidencia con la calidad y más concretamente con el atributo fiabilidad, ya definido en el apartado anterior. Los recursos utilizados para asegurar que un programa se encuentra libre de errores se ha fundamentado en la realización de pruebas más o menos complejas y


23 1

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

Densidad de defectos número de defectos descubiertos en el programa tamaño del programa

Ecuación 8.13

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

Tasas Muy relacionadas con la definición de densidad de defectos del software se encuentran otras medidas que se agrupan con el nombre de "tasas". Son indicadores de la calidad del proceso ya que tienen el factor tiempo como componente de las mismas. Algunas de las medidas más utilizadas son:

Tasa de propagación de defectos

número de defectos ocasionados al corregir defecto número de defectos corregidos

Ecuación 8.14

Eficiencia en la eliminación de defectos

número de defectos corregidos durante una fase de desarrollo * 100 numero de defectos detectados durante una fase de desarrollo Ecuación

8.15

Tasa de efectividad de las pruebas

número de objetos probados almenos una vez * 100 número de objetos totales

Ecuación 8.16

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

3.

Fiabilidad

La medida de la fiabilidad es expresada por numerosos técnicos como probabilidad de que no ocurra un error en un determinado tiempo. Si consideramos R la medida de la fiabilidad y F como la probabilidad de que aparezca un error en un tiempo determinado t, podemos expresar matemáticamente.

R(t)= 1 - F ( t )

Ecuación 8.17

Si consideramos un valor del tiempo discreto la ecuación seria

d, R(n)= 1 - n

Ecuación 8.18

233


donde d,, es el número de fallos encontrados en n ejecuciones. Si f(t) es la función densidad de probabilidad, es decir:

f (t) = dF(t) l dt

Ecuación

8.19

donde f(t) es la probabilidad de que el software falle en el intervalo de tiempo (t, t + dt). La tasa de riesgo h(t) es la probabilidad de que el sofware falle en (t, t + dt) si no ha fallado antes: h(t) =

f (4 1- F(t)

Ecuación 8.20

de donde se puede obtener:

h(t) =

d f ( t ) =--(ln(l-~(t)))=1-F(t) dt

ln R(t) = Ih(x)dx

ln R(t) dt

Ecuación 8.21

Ecuación 8.22

O

1

R(t) = e,

Ih(x)h

Ecuación 8.23

Se define el tiempo medido entre fallos MTTF, acrónimo del inglés Mean Time to Faillure como:

1 MTTF = -

Cfl ti i=1

Ecuación 8.24

Finalmente la fiabilidad, tal como la se ha definido para estas ecuaciones se relaciona con el valor del tiempo medio entre errores a través de la ecuación.

MTTF = ) ~ ( tdt) O

Ecuación 8.25

4. COMPLEJIDAD DEL SOFTWARE Unida intrínsecamente a la medida del tamaño del software se encuentra la medida de la complejidad. Como se ha podido apreciar en las ecuaciones anteriores, conocer el tamaño del software es fundamental para establecer la calidad del mismo, por lo que medir la complejidad es fundamental en el conocimiento de la calidad de un sistema software. La cuantificación de este atributo ha supuesto numerosos esfuerzos, dos de los más representativos son introducidos a continuación. 4.1.

La Ciencia del Software de Halstead

La Ciencia del Software de Halstead es una de las más estudiadas, populares y controvertidas teorías sobre el software y su cuantificación. Halstead definió un conjunto de métricas basadas en los elementos sintácticos existentes en el programa, en el léxico del código fuente. Su base teórica parte de la psicología, concretamente de la psicología cognitiva. La ciencia de Halstead de basa en un conjunto de medidas definidas así: nl = número de operadores distintos que aparecen en un programa. n2= número de operandos distintos que aparecen en un programa. NI= número total de ocurrencia de operadores. N2= número total de ocurrencia de operandos. Conocidas estas medidas iniciales podemos calcular "N", la longitud del programa según la ecuación: N=N,+N2

Ecuación 8.26

Además define el "vocabulario" del programa como: n = n l +n2

Ecuación 8.2 7

Permite estimar el valor de N según la ecuación: N= nllog2nl+n210g2n2

Ecuación 8.28

El valor de N puede convertirse en número de líneas de código haciendo uso de tablas obtenidas por métodos estadísticos.


235

Según esta teoría el esfuerzo requerido para generar el programa se definiría como el número de- operaciones mentales necesarias pare escribir un programa de longitud N. Este valor vendría dado por la ecuación: E= (nl N N2 logzn)/(2 n2)

Ecuación 8.29

Define el concepto Volumen del Programa como el número mínimo de bits necesario para codificarlo: V = N log2(nl+ N2)

Ecuación 8.30

Este valor cambia según el lenguaje utilizado. Para cada algoritmo particular ha de existir un volumen mínimo. Halstead define la razón de volumen "L" como la razón entre el volumen de la forma más compacta de un programa y el volumen del programa real. L debe ser siempre menor que uno. L = (2 n2 )f(n~N2)

Ecuación 8.31

Halstead teorizo que cada lenguaje podía ser clasificado por un nivel de lenguaje, "1". Este valor parece estar relacionado con el nivel de abstracción en especificación de procedimientos. A mayor nivel de lenguaje mayor nivel de abstracción. Las críticas al modelo de Halstead se fundamentan en considerar erróneas las hipótesis de la psicología cognitiva, base teórica del mismo. Por otro lado se han determinado errores estadísticos cometidos en la validación de pruebas de medidas obtenidas haciendo uso de las ecuaciones de Halstead [Fenton 19911. Otro hecho fundamental es que las medidas propuestas en esta teoría obvian el diseño centrando su información en el código. 4.2.

La medida de la complejidad de McCabe

Esta medida se basa en la representación gráfica de un programa según el flujo de control del mismo y nos informa de la complejidad lógica del diseño propuesto debido a la estructura de decisiones del módulo considerado. Se denomina complejidad ciclomática. Y la ecuación que nos proporciona su valor es: V(G)=e-n+2

Ecuación 8.32

Donde e es el número de flechas de conexión que implica una transferencia de control de un nodo a otro y n el número de nodos, entendidos éstos como tareas de proceso.

METRICAS DEL SOFTWARE

236

Para conocer esta medida es necesario, por tanto, obtener la representación del programa haciendo uso del grafo de flujo. Los elementos básico que conforman dicho diagrama se consideran a continuación:

Nodo. Representan sentencias de código.

Nodo Predicado. En sentencias en las que aparecen condiciones tipo NOR, OR, AND y NAND, aparece un nodo por cada condición, a éstos nodos se les denomina Nodo Predicado. Flechas de conexión. Representan flujos de control.

Sentencia "until"

Sentencia "if'.

Sentencia "while".

Ejemplo de nodo predicado con sentencia XORY.

Uno de los usos más habituales del número ciclomático está asociado con la ejecución de pruebas. El número ciclomático nos informa del número de caminos


237

independientes del programa. Conocido este valor podemos saber el número de pruebas máximo que asegure el que todas las sentencias se ejecutan al menos una vez. La complejidad del producto software fue limitado por McCabe, asociándolo a un valor V(G) =lo, de forma que módulos con una complejidad ciclomatica superior a este valor eran inadecuados, propensos a errores y de difícil mantenimiento.

4.3.

La métrica de Henry y Kafura

Henry y ~ a f u r midieron a~ la complejidad basándose en el flujo de información entre módulos. Se define un módulo como "una secuencia identificable de instrucciones contiguas", que no tienen que ser necesariamente de código fuente (texto de especificación, de diseño, etc.). Se distinguen los atributos intra-módzdos (atributos de un módulo vistos como independiente de los otros módulos) y los atributos inter-módulos (atributos del sistema visto como un conjunto de módulos más o menos dependientes unos de otros. El análisis del diseño puede hacerse como si se tratará de grafos, tales como grafo de llamadas entre módulos, grafos de control, grafos de dependencia de datos, etc. En los grafos se pueden hacer diversas medidas: Medidas de la morfología del grafo: número de arcos, de nodos, profundidad, anchura, etc. Medidas de nodos: número de arco entrantes, de arcos salientes, grado de acoplamiento (se mide por los atributos del flujo de información entre módulos). Cohesión de un módulo se define como "atributo de módulos individuales, que describe su fuerza funcional, es decir, la importancia según la cual los componentes del módulo son necesarios para ejecutar la misma tarea".

en ton^ propone, para la medida de la cohesión intra-módulo el cociente entre el número de módulos con cohesión funcional y el número total de módulos. Como la cohesión no está habitualmente modelada por un grafo, hay que definir una medida ordinal, distinguiéndose de mejor a peor:

S. Henry y D. Kafura. Software Sfructure metric base on information flow. IEEE Transaction on software Engineering. Vol 7, no 5, 1981. 4 N. Fenton. Software Metrics. A rigourous Approach. Chapman & Hall. 1992.


238

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

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

Flujo local de información Hay flujo local de información de un módulo A hacia un módulo B, si se tienen una o más de las siguientes condiciones: a) A llama a B. b) B llama a A, y A devuelve un valor a B, y B lo utiliza inmediatamente. c) C llama a la vez a A y a B, pasando un valor de A hacia B.

G. Booch. Conception orientée et applications. Addison- Wesley, 1991


239

F1 X O R Y. Flujo local directo de información

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

Hay un flujo local indirecto de información de un módulo A hacia un módulo B, si B llama a A, A devuelve un valor a B, y B lo utiliza enseguida, o si C llama a la vez a A y a B, pasando un valor de salida de A hacia B.

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

El fan-out de un procedimiento A es el número de flujos locales que vienen del procedimiento A, más el número de estructuras de datos que son actualizadas por el procedimiento A. La fórmula que define el valor de la complejidad de un procedimiento es: comp.- proc. = (fan-in x fan-out12 Ecuación 8.33 El hecho de elevar al cuadrado viene dado por la suposición de Henry y Kafura de que la complejidad es una función más que lineal de las conexiones del procedimiento con su entorno. El flujo total de información será el sumatorio de las complejidades de todos los procedimientos, es decir:

Flujo = C (fan-in x fan-out12 Ecuación 8.34


240

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

Métricas a nivel de tabla

Son principalmente dos: NA(T) NFK(T) 5.2.

Número de atributos de una tabla. Número de claves ajenas de una tabla.

Métricas a nivel de estrella

Las métricas propuestas son: NDT(S) NT(S) NADT(S) NAFT(S) FT DTi NA(S)

Número de tablas dimensionales de una estrella. Número de tablas de la estrella. Número de atributos de las tablas dimensionales de una estrella. Número de atributos de la tabla de hechos de la estrella. Tabla de hechos de la estrella. Tabla dimensional i de la estrella S. Número de atributos de la estrella.

NFK(S)

Número de claves ajenas de una estrella.

C. Calero, M. Piattini, C. Pascua1 y M:A. Serrano, Towards data warehouse quality rnetrics.Proceedinds of 31d Workshop on desing and management of data warehouse, 2001.


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. Métricas a nivel de esquema

En el último nivel se encuentran las siguientes métricas: NFT(Sc) NDT(Sc) NSDT(Sc) NT(Sc) NAFT(Sc)

Número de tablas de hechos del esquema. Número de tablas de dimensión del esquema. Número de tablas dimensionales compartidas por mas de una estrella. Número de tablas del esquema. Número de atributos de las tablas de hechos del esquema. NAFT(Sc) = CNA(FTi) (i = 1 a NFT).

NADT(Sc)

Número de atributos deC las tablas de dimensión del esquema. NADT(Sc) = CDA(DTi) (i =1 a NDT)

NASDT(Sc)

Número de atributos de las tablas de dimensión compartidas. NASDT(Sc) = CNA(DTi) (i = 1 a NSDT)

NA(Sc) NFK(Sc) RSDT(Sc)

Número de atributos del esquema. Número 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)

RSDTA(Sc)

Ratio de atributos de las tablas dimensionales compartidas.

5.4.

Calidad de los propios datos

La calidad de datos es un concepto multidimensional que comprende diversos aspectos que dependen de las necesidades de los usuarios de los datos y de los diseñadores del sistema, por lo que deben elegirse aquellas dimensiones de calidad, que proporciona la ISO 9126, que resulten más significativas. Una metodología para medición de la calidad de los datos, basada en las ideas de 0man7 et al., es la siguiente: Fase 1: Identificación de los objetivos y de las medidas. Fase de análisis que a partir de los requisitos de calidad de los usuarios se obtienen datos para las siguientes fases Determinar el objetivo de la medición. 1.2 Determinar los parámetros e indicadores de calidad. 1.3 Localizar los datos a valorar. 1.3.1 Determinar la cantidad de datos que deben ser valorados. 1.3.2 Localizar esos datos en la base de datos. 1.3.3 Elegir el momento en el que debe hacerse la valoración de los datos. 1.3.4 Identificar las fuentes de los datos. 1.4 Definición de criterios de calidad. Fase 2: Creación de una estructura de calidad. En esta fase de diseño se dota al almacén de datos de una estructura para almacenar los valores de las medidas. Fase 3: Medición de los atributos de calidad. Se procede a la medición de aquellas dimensiones de la calidad seleccionadas, bien mediante muestre0 o sobre la totalidad de los datos.

7

L. Oman, V. Storey y R. Wang. Systems Approaches http://web.mit.edu/tdqm/www/papers/94/94-0S.html, 1994.

to

Improving

Data

Quality.


243

Fase 4: Análisis y Evaluación de los valores de los atributos de calidad. Se valora el grado de bondad de los datos y el grado de calidad del conjunto de ello, desechándose los inválidos. Actualmente existe un proyecto denominado CALDEA, financiado por la Subdirección General de Proyectos de Investigación del Ministerio de Ciencia y Tecnología, para crear un modelo de madurez de calidad de datos.

6. MEDIDAS DE FACILIDAD DE USO DE LAS INTEFWACES DE USUARIO Parece evidente que la característica de la calidad de un interfaz de usuario es la facilidad de uso del mismo, por lo cual se han desarrollado diversos métodos y medidas de esta característica o atributo. 6.1. Clasificación de los métodos

Siguiendo a wixon8 y Wilson distinguimos cinco criterios de clasificación: Métodos formativos vs. Métodos sumativos. Los primeros se orientan a la detección de problemas y generación de ideas de facilidad de uso (usabilidad), al principio de las fases de análisis, diseño y desarrollo. Los segundos sirven para evaluar sistemas terminados. Métodos de descubrimiento vs. Métodos de decisión. Los primeros son cualitativos y se dirigen al usuario para determinar cómo piensa, cómo trabaja y con qué problemas encuentra. Los segundos, cuantitativos, sirven para elegir entre diversos diseños alternativas. Métodos formales vs. Métodos informales. Muchos de los métodos descritos formalmente son, en la práctica, adaptados por los evaluadores, de manera informal, según sus objetivos. Métodos que involucran al usuario vs. Métodos que no involucran al usuario. Dependen del que el usuario participe o no en el análisis, diseño y evaluación del proyecto informática. Métodos completos vs. Métodos componentes. Los primeros se extienden por todos los pasos para completar un diseño centrado en la facilidad de uso. Los componente, sólo cubren parte de un proceso completo de usabilidad y son la mayoría de los métodos.

-

8

-

-

--

D. Wixon y C. Wilson. The usability engineering framework for product design and evaluation. Handbook of human-computer interaction. Elsevier Science, 1997.

Algunos métodos de evaluación

6.2.

Se distinguirá entre métodos en los que los usuarios participan en un papel principal (user testing), usando las técnicas de cuestionarios y "brainstorming" y los que se prescinden de los usuarios (usability inspection) y en los que los principales protagonistas son los expertos.

SUMI (Software Usability Measurement Inventory )9. Aunque en sus orígenes era un cuestionario para evaluar la calidad del software tanto para productos nuevos, como para comparar versiones antiguas y obtener ideas para nuevos desarrollos. Requiere un mínimo de 10 cuestionarios. MUMMS (Measuring the Usability of Multy-Media Systems). De los mismos autores y con los mismos objetivos, sirve para medir la satisfacción de los usuarios de aplicaciones multimedias. WAMMI (Website Análisis and Measurement Multimedia Inventory). De los mismos autores, se utiliza para la evaluación de sitios web. SUS (System Usability ~cale)" Consiste en un sencillo test para comparar, de forma cruzada, diferentes productos. Usabilitv Inspection Estas métricas, cuantitativas, obtienen información sobre la usabilidad que presenta el producto. Medidas de ~ielsenl' Las medidas típicas cuantificables de usabilidad propuestas son:

-

-

Tiempo que los usuarios emplean para completar una tarea. Número de tareas que pueden completarse en un tiempo dado. Relación entre las interacciones con éxito y los errores. Tiempo usado para reparar los errores. Número de errores de usuario.

HFRG. The humanfactors research group.Universiíy College Cork, 1990. J- Brooke. User Information Architecture A/D Group.Digita1Equipment Co. Ltd. " J. Nielsen. Usability Engineering.Academic Press, 1993.

'O


245

Porcentaje de competidores que consiguen una medida mejor. Números de acciones erróneas inmediatamente posteriores. Número de comandos y otras características utilizados por el usuario. Número de comandos y otras características no utilizados nunca. Número de características que el usuario recuerda después de un test. Frecuencia de uso de manuales y10 ayudas del sistema y tiempo empleado en ello. Frecuencia con la que el uso anterior resolvieron el problema. Ratios entre opiniones positivas y negativas del usuario durante el test. Número de ocasiones en que el usuario presenta fmstración. Proporción de usuarios que prefieren el sistema a otro de la competencia. Proporción de usuarios que emplean estrategias eficiente. Tiempo muerto en el que el usuario no interactúa con el sistema. Número de veces en que el usuario se desvía de la tarea.

Método de Constantine y ~ o c k w o o d ' ~ Estas métricas pretenden medir la complejidad (complexityl y la adecuaciQn (appropriateness) del diseño. Sin entrar en detalles, se presenta una relación de las métricas y de las características que pretenden cuantificar:

-

Essential Efficiency 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 característica demandada al software. Desgraciadamente existen pocas medidas y la evaluación de la seguridad de los sistemas informáticos se hace mediante auditorias de seguridad, basadas en cuestionarios, en general, cualitativos. Como principio general se emplea el método de descomposición en árbol de la característica Seguridad en sus subcaracterísticas. Un ejemplo podía ser el de la figura 8.1. 12

L. Constantine y L. Lockwood. Software for use. A practical guide to the models and methods o j usage.centered design. Addison-Wesley, 1999.

..

;

;; f

ALGORITMO

j/

;! j

CLAVES

1

........................................i i..................................i

i

CCESIBILIDAD

Fig. 8.1. Descomposición en árbol de las características de la seguridad.

7.1.

Un poco de historia

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


247

Como alternativa a los criterios americanos, algunos países europeos, en 1990, establecieron un conjunto de criterios para evaluar la seguridad. Estos criterios, basados en algunos conceptos del TSEC, variaban algunos enfoques. Partiendo también de la base del TSEC, el gobierno canadiense desarrolló el CTCPEC (Canadian Trusted Computer Product Evaluation Criteria). En la década de los noventa, se funden todos los anteriores criterios en lo que se conoce como Common Criteria que, en su versión de 1999, sirvió de base al estándar ISOIIEC 15408.

SSE-CMM

7.2.

El SSE-CMM (Systems Security Engineering-Capability Maturity Model) presenta las características básicas de la ingeniería de seguridad de un sistema informático. No describe proceso concreto. Solamente propone las mejores prácticas para obtener una buena seguridad del sistema. La arquitectura básica consta de tres categorías:

-

Organización. Proyecto. Ingeniería de seguridad.

Y, siguiendo los criterios del CMM, presenta cinco niveles de seguridad:

-

Seguridad mantenida de manera informal. Seguridad planificada y gestionada. Seguridad definida. Seguridad controlada cuantitativamente. Seguridad mejorada de forma continua.

El grupo de desarrollo del SSE-CMM divide las métricas en dos grandes grupos:

Métricas de proceso. Medidas que pueden ofrecer evidencias de la madurez de los procesos propuestos en el modelo. Métricas de seguridad. Métricas para evaluar los atributos de seguridad (confidencialidad, integridad, etc.) en un momento dado.

METRICAS DEL SOFTWARE

248

7.3.

Métricas de eficacia de los algoritmos criptográficos

Para determinar estas métricas es necesario, en primer lugar, identificar los atributos comunes a los algoritmos criptográficos. Los criterios comunes propuestos son:

-

Tipo de algoritmo (simétrico o asimétrico). Tipo de función (autentificación, firma digital, mensaje secreto, etc.). Longitud de la clave. Complejidad del algoritmo, en cuanto cifrado, descifrado y tratamiento de la clave. Comportamiento ante los ataques (fuerza bruta, factorial, análisis diferencial, etc.). Algunas de las métricas son: Longitud de la clave

Cuanto mayor es, más resistente es el algoritmo frente a un ataque de fuerza bruta. Se expresa en número de bits de longitud de la clave. Cada bit que se añade a la clave se duplica el número de intentos necesarios para descubrir la clave. Número de pasos para realizar el cifrado

El número de pasos es la base de cálculo para las métricas relacionadas con el tiempo de resolución en un procesador determinado. También permite hacer estimaciones teóricas sobre las operaciones a realizar para descifrar un determinado algoritmo. Tiempo para atacar el cifrado

Se define como el menor tiempo posible para resolver la codificación en un determinado procesador. Normalmente se expresa en Mtops (millones de operaciones teóricas por segundo). Fuerza del algoritmo

Es una medida subjetiva. Esta métrica propone una serie de niveles asociados a las características de vulnerabilidad de un determinado algoritmo, como si se


249

pueden decodificar mediante unos recursos computacionales no disponibles o muy caros, o si puede hacerse de una forma más cercana o barata. Los niveles propuestos son:

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

Un algoritmo tiene nivel CS (Computational Secure) si no se puede decodificar usando análisis criptográfico sistemático en un período de tiempo suficientemente corto como para que la información sea útil.

ccs Un algoritmo tiene nivel CCS (Conditionally Computational Secure) si se puede decodificar utilizando claves que no son lo suficientemente largas para lcanzar el nivel CS.

Un algoritmo tiene nivel W (Weak) si puede decodificarse mediante un ataque de fuerza bruta en un tiempo razonable de tiempo, p. e., 24 horas, y un coste abordable, 200.000$.

Un algoritmo tiene un nivel VW (very weak) si puede decodificarse en un tiempo corto, 8 horas, y un bajo coste, 2000$. En la tabla 8.3 , se exponen las evaluaciones de los algoritmos de cifrado más conocido.

Tabla 8.3. Algoritmos de cifrado y su evaluación. 7.4.

Métricas de seguridad de red

La colección de medidas propuestas se dividen en básicas y de procesos: Métricas básicas Número de intentos de intrusión con éxito en un período de tiempo. Número de intentos de intrusión sin éxito en un período de tiempo. Número de virus detectados en la red en un período de tiempo. Número de intrusiones detectadas en la red en un período de tiempo. Número de violaciones de las reglas de seguridad detectadas en un período de tiempo. Número de intentos de saltarse las reglas de seguridad detectados en un período de tiempo. Porcentajes de palabras de claves de acceso caducadas. Número de modificaciones sobre las claves de entrada modificadas por los usuarios en un período de tiempo. Evaluación de la inversión en monitorización de la seguridad de la red en un período de tiempo. Número de reglas de seguridad utilizadas. Frecuencia de las revisiones de acceso. Frecuencia de las actualizaciones contra virus. Número de componentes de la red infectados en un período de tiempo.


25 1

Métricas de proceso

-

-

Número de usuarios externos al sistema. Número de usuarios internos que salen a la red pública. Número deJirewalls por sistema que existen en la red. Porcentaje de claves de entrada adecuadas a la política propuesta por la organización. Porcentaje de claves de entrada modificadas según la política de la organización. Porcentaje de sistemas con información sensible.

[AAVV, 19931

AAVV, "Function Point Analysis", Datapro Computer Systems Hardware & Software. Delran, USA, McGraw-Hill, 1993. AAVV, "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. Gestión de la Calidad y Aseguramiento de la Calidad. Parte 3: Directrices para la aplicación de la Norma ISO 9001:1994 al desarrollo, suministro, instalacion y mantenimiento de soporte lógico. AENOR. Madrid, 1998. [AENOR, 20001 e UNE-EN ISO 9000. Sistemas de gestión de la calidad. Fundamentos y vocabulario. AENOR. Madrid, 2000. [AENOR, 2000al [Alcatel, 19951 [Alonso y Finn, 19671

UNE-EN ISO 9004. Sistemas de gestión de la calidad. Directrices para la mejora del desempeño. AENOR. Madrid, 2000. e AAVV, "Modelo de madurez software. CMM: Capability Maturity Model" Alcatel Standard Eléctrica, 1995.

Marcelo Alonso y Edward J. Finn. Funtamental Universiq Physics. Volume I. Mechanics. Addison Wesley Publishing Companing Reading Massachusetts. 1967. Trad. por Carlos Hernández y Víctor La Torre. Fondo Educativo Interamericano, S.A. Méjico.1970. [Amescua, 20011 Antonio de Amescua. SPICE. Ponencia presentada en el XII Cursos de Verano de la UNED, Modelos y métodos para la mejora de los procesos de desarrollo de sofware Ávila, Julio 2001. Documentación oficial de las Jornadas. e Antonio de Amescua, Juan Lloréns y Ángel García. [Amescua, Lloréns y García, "SPICE: un marco para la evaluación de procesos software",Calidad del Software 11, NOVATICA, Julio/Agosto 19971 1997, no 128, pág. 33.

[Ashley y Nicholas Ashley y Paul Goodman. Principles of Goodman, 19921 Function Point Analysis. Guidelines For Assessing The Influence of System Characteristics.METKIT, London, July 1992. Nicholas Ashley y Paul Goodman. Princíples of [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 Of Function Point Analysis. Bibliography. METKIT, London, July 1992. [Ashley, 1992bl [Ashley, [Ashley, [Ashley, [Ashley,

Nicholas Ashley. Module IFPA. Principles Of Function Point Analysis. Glossary of Terms. METKIT, London, July 1992. 1992~1 Nicholas Ashley. Module IFPA. Principles Of Function Point Analysis. Set of Questions & Answers. METKIT, London, July, 1992. 1992dl Nicholas Ashley. Module IMMT, Measurement As A Management Tool, Glossary of Abbreviations. METKIT, London, June 1992. 1992el Nicholas Ashley. Module IWIM. What Is Measurement? Glossary of Abbreviations. METKIT, London, September, 1992. 1992fl Nicholas Ashley. Module IWIM What Is Measurement? Teacher Guide. METKIT, London, September, 1992.

Nicholas Ashley. Specifying & Measuring Software Quality. Glossary of Abbreviations. METKIT, London, October 1992. [Ashley, 1992hl Nicholas Ashley. Speczfying & Measuring Software Quality. Module Advert. METKIT, London, October 1992.

[Ashley, 1992gl


255

[Ashley, 1992iI

e Nicholas Ashley. Speczfiing & Measuring Software Quality. Slides With Teacher Notes. METKIT, London, October 1992. [Ashley, 1992j1 e Nicholas Ashley. Speczfiing & Measuring Software Quality. Student Notes. METKIT, London, October 1992.

[Ashley, 1992kl

Nicholas Ashley. Speczfiing & Measuring Software Quality. Teacher Guide. METKIT, London, October 1992.

[Ashley, 199211

e

[Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley, [Ashley,

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

e

Nicholas Ashley. Module IMMT, Measurement As A Management Tool, Teacher Guide. METKIT, London, April 1994 [Ashley, Papp y Nicholas Ashley, Papp Gaspar y Russell Meg. Module Russell, 19921 IWIM. What Is Measurement?Slides with Teacher Notes. METKIT, London, September, 1992. [Bache y Bazzana,. Richard Bache y Gualtiero Bazzana. Software Metrics for 19931 Product Assessment. McGraw-Hill. England, 1993. [Baker, 19791

e A. L. Baker y S. H. Zweben. The Use of Software Science in Evaluating Modularity Concepts. IEEE Transactions of Software Engineering, 5 . 1979. pp. 1 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 .

[Baker et al, 19901 [Banks, 19891 [Boehm, 19811

Frederik P. Brooks. The mythical man-month. Essays on Software Engineering anniversary edition.Addison-Wesley, 1995. [Carrasco, 19971 l José Carrasco. "Técnicas de aseguramiento de la calidad del software", Monografía, Calidad del Software 1, NOVATICA enerolfebrero 1997, no 125, pp. 62-66. [Castell y e Núria Castell y Ángels Hernández. "Filtrado de Hernández, 19971 Especificaciones de Software escritas en lenguaje Natural", Monografía, Calidad del Software 1, NOVATICA, enerolfebrero 1997, no 125, pp. 31-46. [Cerrada, 200 11 e José Antonio Cerrada Somolinos. Introducción. Conceptos de Mejora de los Procesos. Ponencia presentada en el XII Cursos de Verano de la UNED, Modelos y métodos para la me-jora de los procesos de desarrollo de sofware Ávila, Julio 2001. Frangois Clementi. SPICE. 1 Jornada sobre Calidad del [Clementi, 19971 Software, organizada por el grupo de Trabajo sobre Calidad del Software de la Asociación de Técnicos de Informática (ATI), noviembre 1997. Documentación oficial de las Jornadas.

[Brooks, 19951


257

[Cuevas y Gonzalo Cuevas y Vicente Martínez. "Infraestructura y Martínez, 19971 funciones necesarias en una organización para la implantación de un proyecto de mejora continua del proceso del software", monografía, Calidad del Software 1, NOVATICA, julio/agosto 1997, no 128, pp.3-7. 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. ¿Cómo se hace un tesis? Técnicas y [Eco, 19971 procedimientos de investigación, estudio y escritura. Barcelona, Editorial Gedisa,1997. [Fenton, 19921 Norman E. Fenton. Software Metrics. A Rigorous Approach. London, Chapman & Hall, 1992. [Fenton y 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 edición. 2002. Josep R. Freixanet, Eduard Cañas y Enric Roca. "Plan [Freixanet, Cañas de Métricas del Software: aproximación a su diseño", y Roca, 19971 Monografía, NOVATICA, Julio/agosto, 1997, no 128, pp.814. [Gibbs, 19941 W. Wayt Gibbs. "La crisis crónica de la programación", Investigación y Ciencia, Tendencias en Informática, pp. 7281, noviembre, 1994.

[Gómez, Bernaras A. Gómez, A. Bernaras, M. Emaldi y F.J. Ruiz. "La y otros, 19971 mejora del proceso de Software en I+D", Monografía, Calidad del Software 1, NOVATICA, enerolfebrero 1997, no 125, pp. 22-30. [González, 19971 Julio González Sanz. "La Calidad del Software", Física y Sociedad. Oviedo, Madrid, Gráficas SUMMA, Número 8, Otoño 1997, pp. 32-36. [González, 1997b3 Julio González Sanz. "La nueva versión de la norma ISO 9000-3, guía para la aplicación de ISO 9001: 1994", Monografía, Calidad del Software 1, NOVATICA, enerolfebrero , 1997, no 125, pp. 5-9. Agustín 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 métodos para la mejora de los procesos de desarrollo de sofware Ávila, Julio 2001. Documentación oficial de las Jornadas. [Granja, 19971 Juan Carlos Granja Álvarez. "Calidad del Software 1", Monografía, NOVATICA, enero /febrero, 1997, no 125, p. 3. [Hernández, 20021

Juan Francisco Hdez. Ballesteros. El papel de las métricas en el aseguramiento de la calidad del software.Tesis Doctoral. E.T.S.I.1, UNED, noviembre, 2002.

[Hernández, 19981

Juan Francisco Hdez. Ballesteros. "La ingeniería del software como solución a la crisis de la programación". El Día, abril de 1998.

[Huecas, Mañas y Gabriel Huecas, José. A. Mañas y Tomás Robles. Robles, 19971 "Métricas de Cobertura técnicas de descripciones formales", Monografía, Calidad del Software 11, NOVATICA, julio1 agosto 1997, 11'128, pp. 16-23. 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. [Inín, 19971 M" Luisa Inín. "Modelo de madurez: formalismo o creatividad", Calidad del Software 1, NOVATICA, Enerolfebrero, 1997, no 125, pp.59-61.


[ISO, 19981 [ISO, 1998bl

[ISO, 1998~1 [ISO, 1998dl [ISO, 1998el [ISO, 1998fl [ISO, 199881

[ISO, 1998hl [ISO, 20011

259

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.

[Jones, 20001

Capers Jones. Software Assessments, Benchmarks, and Best Practices. 2000.

[Jones, 19781

Capers Jones. Measuring Programming Quality and Productivity. IBM Systems Journal, Volume 17, no 1, 1978.

[Jones, 19881

Capers Jones. A Short History of Function Points and Features Points. Software Productivity Reseach, Inc. Cambrige, Mass, 1988. Capers Jones. Applied Software Measurement: Assuring Productivity and Quality, McGraw Hill, New York, 1991.

[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.

[Juran, 19511

e J. M. Juran. Quality Control Handbook, Third Edition. McGraw-Hill Book Company, New York. (trad. española de José María Vallhorant Bou. Editorial Reverté, S.A., 1990).

[Kan, 20031

Stephen H. Kan. Metrics and Model in Software Engineering. Segunda edición. Pearson Education, Inc. Boston . 2003. [Kugler, 19971 e Hans-Jürgen Kugler. "Mejora de los procesos de Software: el modo de mantenerse por delante en calidad", Monografía, NOVATICA, enerolfebrero, 1997, no 125, pag. 4. [Longstreet e David H. Longstreet y Raffaela Ibba. " Fundamentos del Ibba, 19961 análisis de puntos de funcionalidad", Systems Development Management Journal. Agosto, 1996. 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 Públicas. Plan [MAP, 19911 general de garantía de calidad aplicable al desarrollo de equipos lógicos, Colección INFORMES Y DOCUMENTOS, Secretaría General Técnica, Instituto Nacional de Administración Pública, Madrid, 1991. [Marciniak, 19941e John J. Marciniak. "Software Engineering a Historical Perspective", Encyclopedia of Software Engineering, John Wiley & Sons, 1994. pp. 1176-1182. 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 Melián. Garantías de Calidad del Software. Ponencia presentada en Cursos de Verano, Ávila, Julio 1995. Documentación 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 Innovación y Calidad del Software. Asociación de Técnicos de Informática. Palma de Mallorca, Julio 2002. Documentación oficial de la Jornadas. [Paulk et al, 19931 Mark C. Paulk et al. Capability Maturity Model for Software, Version 1.1 , CMUiSEI-93-TR-24. Software Engineering Institute. 1993. [Paulk et 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, versión l .1 Modelos y métodos para la mejora de los procesos de desarrollo de software (Documentación de referencia CMM V 1.1: CMUíSEI-93TR-24 y CMCr/SEI-95-TR-25, nivel 2), Software Engineering Institute. 1993.Traducido por SOMEPRO. Documentación aportada en los, XII Cursos de Verano, Universidad Nacional de Educación a Distancia. [Paulk et al, M. Paulk, C. V. Weber & B. Curtis, The capability 19951 maturity model. Guidelines for improving software process, Reading, Addison-Wesley, 1995. [Pressman, 19931 Roger S. Pressman. Software Engineering: A Pactitioner's Approach. 3" Edición. McGraw-Hill, Inc. 1993. (Trad. por Carlos Cervigon Ruckaüer). [Quesada, 19871 Quesada Herrera, José. Redacción y presentación del trabajo intelectual: tesinas, tesis doctorales, proyectos, memorias, monografias. Madrid, Paraninfo S.A, 1987. Steven R. Rakitin. Software verification and validation: [Rakitin, 19971 a practitioners's guide. Artech House, Inc. 1997. [Ramos, 19971

[Real, 20011

Isabel Ramos. "Modelos dinámicos para la gestión de proyectos software: un nuevo enfoque", Monografía, Calidad del Software 1, NOVATICA, enerolfebrero 1997, no 125, p. 53. Real Academia Española de la Lengua. Diccionario de la lengua española. Edición 22. Madrid, 2001.

[Rementeria, 19971 [Roberts, 19791

[Rodríguez, Garví y Granja, 19971 [Sánchez, Pickin y otros, 19971 [Sanchis, 19981 [Salvat, 19961

Santiago Rementeria. " Eficacia de la gestión del software en un contexto organizativo amplio", Monografía, 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. Rodríguez, E. Garví y J.C Granja. " Calidad y reusabilidad del Software: estudio de la funcionalidad", Monografía, Calidad del Software 1, NOVATICA, enerolfebrero 1997, no 125, pp. 67-68. C. Sánchez, S. Pickin y otros. "La calidad del producto en los sistemas distribuidos", Monografía, Calidad del Software 1, NOVATICA, enerotfebrero 1997, no 125, pág.47. Francisco Sanchís Marco.Evaluación y gestión de proyectos informáticos. 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. [Sebastián y col., Miguel Ángel Sebastián Pérez, Vicente Bargueño Fariñas 19941 y Vicente Novo Sanjurjo. Gestión y Control de calidad. Cuadernos de la UNED. Madrid. UNED. 1994. [St-Pierre et al, Denis St-Pierre et al. Full Function Point: Counting 19971 Practices Manual. T.R. 1997-04. Software Engineering Management Research Laboratory and Software Engineering Laboratory in Applied Metrics. Montreal, 1997 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, pág 164. [Sobrino, 19971 Carlos Sobrino Sánchez. Gestión de calidad. Aplicación a la industria del software. I Jornada sobre Calidad del Software, organizada por el grupo de Trabajo sobre Calidad del Software de la Asociación de Técnicos de Informática (ATI), noviembre 1997. Documentación oficial de las Jornadas.


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 vídeo, e Video La Calidad del Software, Programación TV. 19961 Educativa 95/96, Programa 081, emisión 27 de mayo de 1996, UNED, Centro de Diseño y Producción de medios audiovisuales. [Villena, 19971 e Villena, Leonardo."La metrología, la Calidad y las PYMES", Física y Sociedad. Oviedo, Madrid, Gráficas SUMMA, Número 8, Otoño 1997, pp. 10-15. [Visconti, Marcello Visconti et al. "Experiencia con un modelo de Antimán y Rojas, madurez para el mejoramiento del Proceso de Aseguramiento 19971 de Calidad del Software", Monografía, Calidad del Software 1, NOVATICA, enerolfebrero, 1997, no 125, pp. 18-21. [Vollman y Thomas Vollman y Juan Garbajosa. "Soporte prestado Garbajosa, 19971 por herramientas CASE y estándares al aseguramiento del producto software", Monografía, Calidad del Software 1, NOVATICA, enero/ febrero, 1997, no 125, pp. 14-17. [Wang, Trujillo y e Y.Wang, J. Trujillo y M. Palomar. " Una métrica para la Palomar, 19971 capacidad de prueba del Software", Monografía, Calidad del Software 1, NOVATICA, enerolfebrero, 1997, no 125, pp. 10-13. [Webster, 19961 e Bruce F. Webster. "The Real Software Crisis". BYTE, january 1996. [Yourdon, 19961 e Edward Yourdon. "Lo bueno..¿es lo mejor?", Byte, no 22, octubre 1996. pág. 154. Horst Zuse. Software Complexity and Methods. [Zuse, 1991 DeGruyter Publisher. Berlin-New York, 1991.

Libro-La Calidad Del Sw y Su Medida

Recommend Documents