FACTORES, CRITERIOS Y MTRICAS A CONSIDERAR EN LA EVALUACIN DE UN PRODUCTO DE SOFTWARE

Karen Niemann karen.niemann@uv.cl Escuela de Ingeniera Comercial Universidad de Valparaso Pasaje La Paz 1301, Via del Mar CHILE Marcello Visconti abcdef@utfsm.cl Departamento de Informtica U.T.F.S.M. Casilla 110-V, Valparaso CHILE

Resumen Hablar de calidad es abarcar un tema con muchas aristas que an no han logrado ser pulidas. Esto es, por carencia de una definicin clara en lo que a calidad se refiere. El presente artculo expone seis diferentes propuestas comnmente halladas en la literatura, y luego sugiere aspectos que deben ser considerados para evaluar si un producto posee o no atributos que lo hacen merecedor del calificativo de calidad. Seguidamente, se analiza un mecanismo para derivar mtricas o mediciones de calidad a partir de los objetivos establecidos. Finalmente, se presenta brevemente una herramienta automatizada que facilita el proceso de evaluacin de la calidad de un producto de software. En un prrafo resumir el trabajo, incluyendo marco conceptual, propuestas y/o aportes. Palabras claves: Mtricas, mediciones, modelos, atributos de calidad de software.

I.

Introduccin.

Es frecuente en el rea de ingeniera de software encontrar proyectos que no cumplen con los plazos ni presupuestos asignados o que los sistemas que se generan no responden a los requerimientos de los usuarios y, por ello, tempranamente se entra a la etapa de mantencin de ellos, que ms que una evolucin adaptativa, corresponde a una correctiva. En la gestin de un proyecto de software, esto es, desde que se concibe hasta que se implementa se tienen presentes caractersticas de calidad que debe tener el producto de software resultante, entre otros: facilidad de mantencin, operabilidad, ajuste a los requerimientos, portabilidad, correccin, facilidad de uso. El problema o vaco que existe es

que la literatura no menciona o explicita las mtricas para cuantificar las caractersticas de productos de software sobre la base de estos atributos. Roger Pressman en su libro Ingeniera de Software, un enfoque prctico[1] explica muy bien lo que a mediciones y mtricas se refiere. Dice: En la mayora de los desafos tcnicos, la medicin y las mtricas nos ayudan a entender tanto el proceso tcnico que se utiliza para desarrollar un producto, como el propio producto. El proceso se mide para intentar mejorarlo. El producto se mide para intentar aumentar su calidad. De este enunciado se puede inferir que la calidad resultante de un producto de software depender de las actividades realizadas durante el proceso de desarrollo. Pero la pregunta clave es: cules son las mtricas apropiadas para el proceso y cules son para el producto?. La dcada de los 90s se reconoce como la era de la calidad del software, esto se basa en las actividades y resultados logrados en las dcadas previas. As, la dcada de los 60s se enfoc hacia la funcionalidad del software. Lo dominante, en aquel entonces, en ingeniera de software fue el desarrollo e implementacin de funciones de sistemas o del negocio en productos de software. Las dcadas de los 70 y comienzos de los 80 fueron las eras de administracin de proyectos de software. Un vuelco grande dio lugar al cambiar desde la implementacin de funciones hacia el monitoreo y control del desarrollo de proyectos de software. La dcada de los 80 se reconoce como la era de desarrollo de software. Lo central en ella lleg a ser el establecimiento y determinacin de equilibrios entre requerimientos del negocio, productividad de desarrollo de software y costos del proyecto. Por tanto, se puede decir que en la dcada que estamos terminando, la industria del software est evolucionando hacia una disciplina industrial profesional. Este artculo pretende enfocarse hacia el ltimo tema. Efectuando una recopilacin y anlisis del estado del arte, primero se definirn las caractersticas que debiera tener un producto para catalogarse de calidad, asunto donde no existe consenso, y, segundo, identificar para cada una de las caractersticas anteriores, mediciones o mtricas a aplicar, en lo posible cuantificables en forma directa y objetiva. Para finalmente describir una metodologa y herramienta que apoya la especificacin, supervisin, control y evaluacin de la calidad de un producto de software. II. Antecedentes.

Al profundizar en la literatura, se puede observar que no existe unanimidad de criterios en cuanto a las caractersticas que debe satisfacer un producto de software de calidad y, por ello, existe una clara dificultad sobre qu medir o cmo cuantificar estas mediciones. Ms an, no existe consenso en lo que se refiere a calidad. En este artculo se tomar uno de los significados planteados por Fenton y Pfleeger [2] que define calidad como la aptitud o suficiencia del producto para sus propsitos (fitness for its purpose). Esta amplia definicin es adoptada pues permite utilizarla independientemente del observador

(evaluador), esto es, analista, diseador, programador, cliente o usuario. Por tanto, los atributos del producto de software sern seleccionados dependiendo de quin evale. De hecho, se pueden encontrar cinco definiciones para calidad [8]. Las siguientes estn descritas desde la perspectiva de desarrollo de software: Definicin basada en el producto: La calidad se basa en un conjunto bien definido de atributos de calidad del software, entendindose por ello, una propiedad abstracta o fsica factible de medir en una entidad. Por lo tanto, para dos productos del mismo tipo, la diferencia en la calidad de ellos va a estar dada por los atributos especficos que se hayan implementado. Definicin basada en los usuarios: Suficiencia del producto para su uso. Esta definicin establece que la calidad del software debiera determinarse por el o los usuarios del producto, en un negocio especfico. Por tanto, se establece diferentes calidades de un producto de software, por las diferencias que se produzcan en las caractersticas del negocio. La calidad puede tener muchos aspectos subjetivos y no puede determinarse sobre la base de slo mtricas cuantitativas y matemticas. Definicin basada en los fabricantes: Esta definicin apunta a la elaboracin de productos de software; procesos de especificacin, diseo e implementacin. La calidad depende del alcance de la implementacin de los requerimientos y su conformidad con aquellos planteados originalmente, y se basa en las inspecciones, registros y anlisis estadstico de los defectos y fallos de los productos intermedios o el producto final. Definicin basada en el valor: Esta definicin establece que la calidad del software siempre debiera determinarse por un proceso de decisin que balancee aspectos de tiempo, esfuerzo y costo. Esta definicin enfatiza la necesidad de lograr acuerdos entre las partes involucradas, esto es, asesores, clientes, desarrolladores y fabricantes. Definicin basada en la excelencia: Esta definicin esotrica o filosfica establece que la calidad puede en principio ser reconocida fcilmente dependiendo de las percepciones y los sentimientos afectivos de una persona o grupo hacia un tipo de producto de software. A menudo, una afirmacin de excelencia acerca de la calidad puede ser el primer paso hacia la formulacin de una definicin explcita acompaada de medidas de calidad. Independiente de lo anterior, se debe tener presente que las medidas pueden ser hechas directa o indirectamente sobre el producto[1]. Ejemplos de las primeras son: LOC producidas, velocidad de ejecucin, tamao de la memoria principal requerido para ejecutar el software, cantidad de defectos detectados durante una fase de desarrollo o perodo de tiempo en explotacin. Medidas indirectas seran entre otras: funcionalidad, complejidad, eficiencia, confiabilidad, facilidad de mantencin y uso, portabilidad.

2.1

Propuesta de McCall y colegas.

McCall y Carvano [1] ya en el ao 1978 focalizaron la calidad para un producto de software como un conjunto de factores vistos desde tres prismas diferentes donde cada uno abarca diferentes caractersticas o criterios del producto, los cuales pueden ser medidos. a) operacin del producto (su uso): correctitud: grado en que un programa satisface los requerimientos de informacin y sus especificaciones, y con ello logra los objetivos planteados por el cliente y/o usuario confiabilidad: grado en que un programa ejecuta sus funciones esperadas con la precisin requerida. Una definicin ms acertada es: probabilidad de que un programa opere libre de defectos en un entorno determinado y durante un tiempo especfico eficiencia: cantidad de recursos computacionales y de cdigo requeridos por un programa para llevar a cabo sus funciones integridad: grado en que se controla el acceso a los programas o datos, por personas no autorizadas facilidad de uso: esfuerzo requerido para aprender a operar y utilizar un programa, preparar la entrada de datos e interpretacin de su salida

b)

revisin del producto (su modificacin): facilidad de mantencin: esfuerzo requerido para modificar un programa. McCall con ello hace referencia a una mantencin correctiva, es decir, el esfuerzo requerido para localizar y arreglar un error de un programa. No obstante, hoy la literatura de Ingeniera de Software realiza una definicin ms amplia de lo que a mantencin se refiere [4], pues incluye evolucin adaptativa y perfectiva (localizar las modificaciones al cdigo y arreglarlo para adecuarlo a cambios en el entorno o efectuar mejoras en l) flexibilidad: esfuerzo requerido para modificar un programa operativo facilidad de prueba: esfuerzo requerido para probar un programa para asegurar que ejecuta la funcin deseada

c)

transicin del producto (su modificacin para trabajar en un entorno diferente): portabilidad: esfuerzo requerido al modificar un programa para que opere en un hardware y/o entorno de sistemas diferente para el que fue originalmente diseado reusabilidad: grado en que un programa o partes de l pueden utilizarse en otras aplicaciones facilidad de interoperacin: esfuerzo requerido para acoplar un sistema a otro

Para evaluar cada una de estas caractersticas del producto, McCall propone una serie de mtricas que en su mayora obedecen a medidas indirectas y/o subjetivas, pues son mas bien evaluadas por un puntaje en escala de cero (mnimo) a diez (mximo). Este artculo, como se ver en la propuesta (punto III), sugiere que lo mismo podra ser hecho cuantificando cada factor de calidad porcentualmente, de acuerdo al grado de cumplimiento. Para no olvidar alguno, se propone elaborar una lista de comprobacin (checklist) dependiendo de los aspectos que se deseen evaluar, especificando para stos un peso o ponderacin de importancia. Las mtricas propuestas por McCall son: Facilidad de auditora: referido a la facilidad con la cual se puede comprobar la conformidad con los estndares Exactitud: la precisin con que se llevan a cabo los clculos y el control Normalizacin de las comunicaciones: el grado con el cual las interfaces, protocolos y anchos de banda estndares se utilizan Completitud: el grado de cumplimiento en la implementacin completa de las funciones requeridas Concisin: lo compacto del programa en trminos de lneas de cdigo Consistencia: el empleo uniforme de tcnicas de documentacin y diseo en todo el proyecto de desarrollo de software Estandarizacin de los datos: el empleo de estructuras de datos y de tipos estndares en todo el programa Tolerancia a errores: el dao que se produce cuando se encuentra un error en el programa Eficiencia en la ejecucin: la performance de tiempo de ejecucin de un programa Facilidad de expansin: el grado al cual se puede ampliar el diseo arquitectnico, de datos o de procedimientos Generalidad: la posibilidad de aplicacin de componentes del programa Independencia del hardware: el grado en que el software se puede ejecutar en un hardware diferente al que opera Instrumentacin: el grado con el cual el programa monitorea su propia operacin e identifica errores que ocurren Modularidad: independencia funcional de los componentes del programa (concepto de cohesin) Facilidad de operacin: la facilidad de operacin del programa Seguridad: la disponibilidad de mecanismos que controlen o protegen tanto a los programas como a los datos Autodocumentacin: grado en que el cdigo fuente provee documentacin significativa Simplicidad: grado en que un programa puede comprenderse sin dificultad

Independencia del sistema de software: grado en que un programa es independiente de caractersticas no estndares del lenguaje de programacin y sistema operativo, y otras restricciones del entorno Facilidad de ruteo: facilidad de rutear una representacin de diseo o componente actual del programa de vuelta hacia sus requerimientos Entrenamiento: grado en que el software ayuda a nuevos usuarios a aplicar el sistema.

La siguiente tabla muestra la relacin entre los factores, criterios y mtricas propuestas por McCall y sus colegas: Factor Operacin del producto Criterio Correccin Confiabilidad Mtrica Completitud Consistencia Facilidad de ruteo Exactitud Complejidad Consistencia Tolerancia a errores Modularidad Simplicidad Concisin Eficiencia en la ejecucin Facilidad de operacin Facilidad de auditora Instrumentacin Seguridad Facilidad de operacin Entrenamiento Concisin Consistencia Instrumentacin Modularidad Autodocumentacin Simplicidad Complejidad Concisin Consistencia Facilidad de expansin Generalidad Modularidad Autodocumentacin Simplicidad

Eficiencia Integridad Facilidad de uso Revisin del producto Facilidad de mantencin

Flexibilidad

Facilidad de prueba

Transicin del producto

Portabilidad

Reusabilidad

Facilidad de interoperacin

Facilidad de auditora Complejidad Instrumentacin Modularidad Autodocumentacin Simplicidad Generalidad Independencia del hardware Modularidad Autodocumentacin Independencia del software Generalidad Independencia del hardware Modularidad Autodocumentacin Independencia del software Normalizacin de las comunicaciones Estandarizacin en los datos Generalidad Modularidad

2.2

Propuesta de Gilb.

Diez aos ms tarde, en 1988, Gilb [1] desarrolla una propuesta incorporando mediciones y mtricas a los siguientes atributos: a) Facilidad de correccin, grado que el software realiza una funcin determinada, medido por la cantidad de defectos por KLOC durante un perodo de tiempo determinado, Facilidad de mantencin, es decir, el grado de facilidad para la modificacin de un software al ejecutar ya sea una evolucin correctiva, adaptativa o perfectiva. Para medir lo anterior, propone una medida indirecta: tiempo medio entre cambios (TMEC), comprendindose sta como el tiempo requerido desde que se analiza un cambio, se disea la modificacin apropiada, se implementa, se prueba, y se comunica a los usuarios. Mientras ms pequeo sea el TMEC implica que existi mayor facilidad de mantencin. Integridad, esto es, grado en que un sistema es vulnerable ante hechos fortuitos o mal intencionados. El efecto resultante puede afectar la seguridad en los programas, datos y/o documentos. Este atributo es indirecto pues hay que medir dos nuevas caractersticas: amenaza y seguridad. La primera se refiere a la probabilidad, estimada o deducida por evidencia emprica, de que se viole la integridad en un perodo de tiempo especfico. Mientras que la seguridad corresponde a la

b)

c)

probabilidad, nuevamente estimada o deducida por experiencia, de que el sistema rechace un acceso que afecte su integridad. Por tanto, la integridad, Gilb la define como: Integridad = [1 amenaza (1 seguridad)] d) Facilidad de uso, es decir, posibilidad de cuantificar cun amigable es el producto de software con el usuario. He aqu nuevamente la necesidad de incluir nuevas caractersticas: - habilidad intelectual y/o fsica requerida para aprender a usar el sistema, - tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema, - cuando se ha llegado al nivel anterior, clculo del aumento neto en productividad comparado con el sistema que est siendo reemplazado, y - valoracin subjetiva (posible de obtener a travs de una encuesta o cuestionario) de la disposicin de los usuarios hacia el sistema. Propuesta de Universidad de Magdeburg.

2.3

Un estudio desarrollado por la Universidad de Magdeburg [3] clasifica el tema de calidad en dos grandes grupos: mtricas de recursos y mtricas de productos. a) Mtricas de recursos: Factor Mtricas de hardware Criterio Mtricas de performance Mtrica Performance del computador Performance de la red Benchmarks Perfil (profile) de la performance Tiempo medio de falla (MTTF Mean Time To Failure) Tiempo medio entre fallas (MTBF Mean Time Between Failure) Tiempo medio de reparacin (MTTR Mean Time To Repair) Tiempo de repeticin medio (Mean Recurrence Time) Tiempo de espera medio en estados de error (Mean Waiting Time in Error States)

Mtricas de confiabilidad

Mtricas de eficacia

Eficacia en el uso del tiempo Restricciones de seguridad Eficacia local

Mtricas del software

Mtricas de performance

Mtricas del modelo (paradigmen metrics)

Mtricas de substitucin

Mtodos de productividad Productividad en el lenguaje de programacin Desarrollo en el nivel del ambiente, entorno Tendencia en el uso de mtodos de desarrollo Tendencia en el uso de lenguajes de programacin Calidad del paradigma Grado de portabilidad del software Complejidad de desarrollo del software

b) Mtricas del producto (tema de inters de este artculo): Factor Producto Criterio Mtricas de funcionalidad Mtrica Software sea el apropiado Software sea exacto Facilidad de interoperacin Cumplimiento Software sea seguro Software sea maduro Tolerancia a fallas o defectos Facilidad de recuperacin Facilidad de comprensin Facilidad para aprender Facilidad de recuperacin Comportamiento con respecto al tiempo Comportamiento con respecto al uso de recursos Facilidad para analizar Facilidad para modificar Estable Facilidad de prueba

Mtricas de confiabilidad Mtricas de uso u operacin Mtricas de eficiencia

Mtricas de mantencin

Mtricas de portabilidad

Facilidad de adaptar Facilidad de instalar Conformidad Facilidad de reemplazar

2.4

Propuesta de Hewlett-Packard: FURPS.

FURPS (Functionality, Usability, Reliability, Performance, Supportability) es un acrnimo propuesto por Hewlett-Packard [1] para simbolizar los factores de calidad principales de un producto de software. Factor Funcionalidad Criterio Funcionalidad Mtrica Caractersticas y posibilidades que ofrece el software Generalidad de las funciones que el software entrega Seguridad de todo el sistema Desarrollo de interfaz adecuada al usuario Esttica global Consistencia Documentacin Frecuencia de fallos y su importancia Precisin de los resultados de salida Tiempo medio entre fallos Habilidad de recuperacin frente a fallos Previsibilidad del software Velocidad de proceso Tiempo de respuesta Consumo de recursos Rendimiento total de procesamiento Eficiencia (lograr objetivos en forma ptima; menor tiempo, menores recursos, menores costos)

Facilidad de uso

Facilidad de uso

Confiabilidad

Confiabilidad

Rendimiento

Rendimiento

Capacidad de soporte

Capacidad de soporte

Facilidad de ampliar el software Facilidad de adaptar el software Grado en que el software presta servicio (utilidad) Facilidad de prueba Compatibilidad Facilidad de configuracin del software1 Facilidad de instalacin Facilidad de localizar problemas

II.5

ISO-IEC 9126.

ISO (International Organization for Standarization) e IEC (International Electrotechnical Comission) constituyen un organismo especializado en estandarizaciones universales. En lo especfico, el Joint Technical Committe ISO/IEC JTC1 Information Tecnology prepar un estndar internacional ISO/IEC 9126-1 [5] que apunta a la evaluacin de la calidad de productos de software. El documento contiene: - desarrollo de caractersticas de calidad y pautas para su empleo, - definicin de seis caractersticas de calidad y - descripcin de un modelo del proceso de evaluacin de productos de software. Las caractersticas de calidad del software definidas en ISO-IEC 9126 pueden utilizarse para especificar los requerimientos del cliente y del usuario, tanto para requerimientos funcionales como no funcionales. Por otro lado, para evaluar la calidad del software se pueden efectuar mediciones a atributos internos o externos. Para los primeros, tpicamente son mediciones estticas a productos intermedios. Es decir, corresponden a mediciones efectuadas al producto en s mismo (intermedio o final), sean stas directas o indirectas. Mientras que para medir atributos externos del producto de software, hay que concentrarse en la medicin del comportamiento del producto de software cuando se ejecuta. El objetivo es que el producto posea el efecto requerido dentro de un contexto particular de uso. En definitiva, ISO-IEC 9126 efecta una clasificacin de los atributos de calidad del software en seis caractersticas, las cuales a su vez son subdivididas en subcaractersticas

Identificar y organizar un cambio, garantizar que se implemente adecuadamente, e informar del cambio a todos a quienes afecte durante todo el ciclo de vida del producto (desde su gestin hasta que se deja de utilizar)

que se pueden medir por mtricas internas (obedecen a propiedades del cdigo) o externas (evaluadas con respecto al comportamiento del software cuando se ejecuta) [8]. Factor Funcionalidad Criterio Funcionalidad Mtrica Software sea el apropiado Software sea exacto Facilidad de interoperacin Software sea seguro Cumplimiento Software sea maduro Tolerancia a fallas o defectos Facilidad de recuperacin Cumplimiento Facilidad de comprensin Facilidad para aprender Facilidad de operacin Sea atractivo Cumplimiento Comportamiento con respecto al tiempo Comportamiento con respecto al uso de recursos Cumplimiento Facilidad para analizar Facilidad para modificar Estable Facilidad de prueba Cumplimiento Facilidad de adaptacin Facilidad de instalacin Coexistencia Facilidad de reemplazo Cumplimiento

Confiabilidad

Confiabilidad

Operacin

Uso u operacin

Eficiencia

Eficiencia

Mantencin

Mantencin

Portabilidad

Portabilidad

Cabe destacar que lo propuesto por la Universidad de Magdeburg coincide bastante con este estndar universal, que adems ofrece definiciones formales para cada atributo: Criterio Funcionalidad Mtrica Software sea el apropiado Definicin: Capacidad del producto de software para... Proveer un conjunto de funciones apropiadas para tareas y objetivos del usuario especficos Proveer los resultados o efectos correctos o convenidos

Capacidad del producto de software de proveer funciones que concuerden Software sea exacto con necesidades establecidas

e implcitas cuando se opere Facilidad de interoperacin bajo condiciones especficas. Cumplimiento

Confiabilidad Capacidad del producto de software de mantener un nivel especificado de performance cuando se emplea bajo condiciones especificadas.

Operacin Capacidad del producto de software de ser comprendido, aprendido, usado y presentar atractivo para el usuario, cuando se utilice bajo condiciones especificadas.

Interactuar con uno o ms sistemas especificados Adherirse a los estndares, convenciones o regulaciones en la ley y prescripciones similares Software sea seguro Proteger informacin y datos para que personas o sistemas no autorizados no puedan leerlos o modificarlos, y que a las personas o sistemas autorizados no se les niegue el acceso a ellos. Software sea maduro Evitar fallar como resultado de defectos en el software Tolerancia a fallas o defectos Mantener un nivel especificado de performance en casos de fallos del software o por una transgresin a su interface especificada Facilidad de recuperacin Reestablecer el nivel especificado de performance y recuperar los datos directamente afectados en caso de una falla Cumplimiento Adherirse a los estndares, convenciones o regulaciones relacionadas con la confiabilidad Facilidad de comprensin Permitirle al usuario comprender si el software es o no apropiado, y como puede ser usado para tareas particulares y condiciones de uso Facilidad para aprender Permitirle al usuario aprender su aplicacin Facilidad de operacin Permitirle al usuario operarlo y controlarlo Sea atractivo Ser atractivo al usuario

Adherirse a los estndares, convenciones, guas de estilo o regulaciones relacionadas con la operacin Eficiencia Comportamiento con Proveer tiempos de respuesta respecto al tiempo y procesamiento apropiados Capacidad del producto de y velocidades de salida software de proveer una cuando ejecute sus funciones, performance apropiada, bajo condiciones establecidas relativa a la cantidad de Comportamiento con Usar cantidades y tipos de recursos empleados, bajo respecto al uso de recursos recursos apropiados cuando condiciones establecidas. el software ejecuta su funcin , bajo condiciones establecidas Cumplimiento Adherirse a los estndares o convenciones relaionadas con eficiencia Mantencin Facilidad para analizar Ser diagnosticado en bsqueda de deficiencias o Capacidad del producto de causas de fallos en el software para ser software, o sean identificadas modificado. Las las partes a ser modificadas modificaciones pueden Facilidad para modificar Permitir implementar una incluir correcciones, modificacin especificada mejoramientos o adaptacin Estable Evitar efectos inesperados al del software a cambios en el efectuar modificaciones al entorno, en los software requerimientos y en las Facilidad de prueba Permitir validar software especificaciones funcionales. modificado Cumplimiento Adherirse a los estndares o convenciones relacionadas con mantencin Portabilidad Facilidad de adaptacin Ser adaptado a diferentes ambientes especificados sin Capacidad del producto de necesidad de aplicar otras software para ser transferido acciones o medios que de un ambiente a otro. aquellos provistos para este propsito para el software considerado Facilidad de instalacin Ser instalado en un ambiente especificado Coexistencia Coexistir con otro software independiente en un ambiente comn, compartiendo recursos comunes

Cumplimiento

Facilidad de reemplazar

Cumplimiento

Ser usado en reemplazo de otro producto de software especificado con el mismo propsito y en el mismo ambiente Adherirse a los estndares o convenciones relacionados con portabilidad

ISO-IEC 9126, adems, aporta caractersticas de calidad cuando el producto est en uso. Es decir, enfoca la calidad desde el prisma del usuario final, cuando ste opera el software en un ambiente determinado. Por lo tanto, el producto de software se evala a partir de los resultados observados, y no es evaluado por las propiedades intrnsecas de l. Se considera relevante entregar la siguiente informacin, por cuanto, al evaluar la calidad cuando se usa un producto de software puede proveer retroalimentacin para mejorar un producto. Siendo que, a su vez, la evaluacin de un producto puede constituir una retroalimentacin para mejorar el proceso de gestin de un proyecto de software. Para evaluar la calidad del software cuando est en uso, por usuarios especficos que concuerden con sus requerimientos para llevar a cabo metas especficas, se puede clasificar los atributos de calidad en cuatro caractersticas: Criterio Calidad en uso Mtrica Efectividad Definicin: Capacidad del producto de software para... Permitir a los usuarios llevar a cabo metas especificadas con precisin y en forma completa dentro de un contexto especfico de uso Permitir a los usuarios emplear cantidades de recursos apropiadas en relacin con la efectividad lograda, en un contexto de uso especificado Llevar a cabo un nivel de riesgo de dao aceptable para personas, software, equipamiento o el entorno en un contexto especfico de uso Satisfacer a los usuarios en un contexto especfico de uso

Capacidad del producto de software para permitir a los usuarios determinados llevar a cabo metas especificadas Productividad con efectividad, productividad, seguridad y satisfaccin, en un contexto especfico de uso. Seguridad

Satisfaccin

II.6

Propuesta de ATAQS.

El rea de Tecnologa para Avaliao da Qualidade de Software (ATAQS) perteneciente a la Fundao Centro Tecnolgico para Informtica (CTI) de So Pablo, Brasil, est desarrollando mtodos y herramientas automatizadas para apoyar la evaluacin y el mejoramiento tanto de procesos de desarrollo de software como de los productos en s, en forma integrada [7]. Desde 1994 al ao en curso, el CTI ha llevado a cabo, por lo menos, 300 evaluaciones de productos de software con los propsitos de estimar el nivel de calidad de los productos de software brasileos, promover su mejoramiento, expandir la cultura y conceptos de calidad de software y para crear conciencia de la importancia de estos conceptos en la comunidad de software, que incluye a desarrolladores, vendedores y usuarios. El mtodo provisto para los evaluadores de la calidad de productos de software est enfocado desde el punto de vista de los usuarios y est basado en las normas internacionales ISO/IEC 9126 e ISO/IEC 12119. La primera, como se describi en el punto anterior, est referida a un modelo compuesto de seis caractersticas de calidad que debe poseer un producto de software: funcionalidad, confiabilidad, usabilidad (operacin), eficiencia, mantencin y portabilidad. ISO/IEC 12119 trata con los componentes de un producto de software disponibles para el usuario final: embalaje, descripcin del producto, documentacin, interface y software. La estructura de evaluacin propuesta por ATAQS consiste en una lista de verificacin de los siguientes criterios: Factor Embalaje Criterio Identificacin Aspectos visuales Aspectos de robustez Aspectos prcticos Identificaciones indicaciones Funcionalidad Confiabilidad Uso Opciones Completitud Mtrica

Descripcin del producto

Documentacin

Adecuado Identificaciones e indicaciones Descripciones de funcionalidad Descripciones de confiabilidad Descripciones de uso Descripciones de opciones

Funcionalidad Operacin Interface Funcionalidad Operacin Software Funcionalidad

Eficiencia

Portabilidad Confiabilidad

Adecuado Exacto Facilidad de comprensin Facilidad para aprender Facilidad de operacin Adecuado Conformidad Facilidad de comprensin Facilidad para aprender Facilidad de operacin Adecuado Exacto Interoperacin Conformidad Seguridad en los accesos Comportamiento relativo al tiempo Comportamiento relativo a los recursos Adaptabilidad Capacidad de instalacin Capacidad de desinstalacin Grado de madurez Tolerancia a las fallas Facilidad de recuperacin

II.7

Criterios comunes en las propuestas descritas y mtricas sugeridas para cada uno de ellos.

Realizado y analizado un cuadro comparativo entre las seis propuestas anteriores, se puede inferir de l la existencia de criterios comunes que se repiten en la mayora de ellas, sin perjuicio de que dos de las propuestas descritas (Universidad de Magdeburg y ATAQS) se basan en la ISO-IEC 9126. En el caso de la Universidad de Magdeburg, an cuando sta no lo menciona, cae en evidencia por la similitud con la norma. A continuacin se presentan los criterios comunes (en orden alfabtico para facilitar la bsqueda) en las propuestas descritas y las mtricas sugeridas para cada uno de ellos (entre [ ] se indica la fuente). Confiabilidad [3,4,10] MTTF [3] : Tiempo medio de falla (en horas UCP)

MTTR MRT MWTES [1,8,13] MTBF MTBF [1,4] Disponibilidad Disponibilidad [4] POFOD

: : : : = = = =

Tiempo medio de reparacin Tiempo de repeticin medio Tiempo de espera medio en estados de error Tiempo medio entre fallas MTTF + MTTR Probabilidad de que un programa funcione de acuerdo con los requerimientos en un momento dado 100% MTTF / (MTTF + MTTR) Probabilidad de falla en la demanda Ej.: POFOD = 0,001 significa que 1 de 1000 requerimientos del servicio pueden resultar en error Tasa de ocurrencia de falla (en horas UCP) Ej.: ROCOF = 2/100 significa que 2 errores probablemente ocurrirn en cada 100 unidades de tiempo operacional Cantidad de defectos conocidos / Tamao del producto (LOC o PF) Cantidad de defectos / Tamao del mdulo Tiempo requerido para arreglar defectos de post-release / Tiempo total requerido para desarrollar sistema 100 Costo en arreglar defectos post-release / Costo total del proyecto

[4,10] ROCOF

[2] Densidad de defecto [10] Densidad de defectos por mdulo [2] Sistema inutilizado

= =

Razn de sistema inutilizado [13] Densidad de falla del mdulo Correctitud Extensin de la prueba

: :

Densidad de falla del mdulo Extensin de la funcin Extensin del arco

Eficiencia [10] Eficiencia Facilidad de interoperacin [14] Razn de conformidad del formato de los datos = Cantidad de formatos de los datos en conformidad / Cantidad de formatos de datos Razn de conformidad de la representacin de los datos = Cantidad de representaciones en conformidad / Cantidad de representaciones de datos = Cantidad de defectos encontrados / KLOC

Facilidad de mantencin [1] TMEC Documentacin Trfico de cambios anual = = = Tiempo medio entre cambios Pginas de documentacin / KLOC o PF KLOC para un sistema en mantenimiento / (Cantidad de inst. de cdigo fuente que se modifican o aaden durante un ao de mantenimiento) Tiempo medio de reparacin 100 Tiempo total en implementar cambio / Cantidad total de cambios implementados

[2] MTTR Razn de mantencin Cantidad de problemas no resueltos

= =

Tiempo utilizado en problemas no resueltos Porcentaje de cambios que introdujeron nuevas fallas Cantidad de mdulos modificados para implementar un cambio

[13] Cohesin Acoplamiento

: :

Cantidad de mdulos modificados por falla Cantidad de mdulos que llaman a un mdulo (Fan-in) Cantidad de mdulos llamados por un mdulo (Fan-out) Cantidad de accesos a datos comunes Tamao del mdulo Cantidad de mdulos Complejidad ciclomtica Conformidad con estndares de documentacin Facilidad de lectura, comprensin de la documentacin Densidad de comentarios

Simplicidad

Facilidad de anlisis

Facilidad de prueba [2] Complejidad ciclomtica de McCabe: v(G) = e n + 2 donde e = cantidad de arcos n = cantidad de nodos

Facilidad de uso u operacin [2] Perodo productivo

*

100 (Tiempo de tarea* Tiempo no productivo) / Tiempo de tarea* = 100 (Eficiencia del usuario / Eficiencia del experto) : Esfuerzo para la operacin Conformidad con los estndares de documentacin del usuario

aprendizaje, comprensin

Eficiencia del usuario relativa [13] Facilidad de aprendizaje

Madurez

[1] Indice de madurez del software = [MT (Fa + Fc + Fd)] / MT donde MT = cantidad de mdulos en el release actual Fa = cantidad de mdulos en el release actual que han sido agregados Fc = cantidad de mdulos en el release actual que han sido cambiados Fd = cantidad de mdulos en el release actual que han sido eliminados [14] Tiempo promedio de fallas = Tiempo total de funcionamiento / Cantidad de fallas Cantidad de errores por producto / Volumen del producto Cantidad de errores puestos en evidencia en la fase de prueba del sistema / Cantidad total de pruebas

Densidad de errores en el producto = Razn de errores en las pruebas =

Portabilidad [13] Portabilidad modular [14] Adaptabilidad : Densidad de mdulos especficos de hardware Cantidad de accesos a datos comunes Cantidad de intervenciones sobre el software / Cantidad de modificaciones funcionales

Seguridad [1] Integridad = [1 amenaza (1 seguridad)]

En base a las mtricas recopiladas, se puede inferir que mientras algunas son recurrentes en la literatura, otras escasamente son mencionadas. En trminos generales se puede concluir que la confiabilidad de un producto de software est estrechamente relacionada con la cantidad de defectos o fallas detectadas. La facilidad de mantencin est asociada al tiempo requerido para implementar un cambio, tamao y simplicidad de un programa y, aspectos de documentacin. La facilidad de uso u operacin est ligada con el aprendizaje del software y la documentacin de l.

III.

Propuesta.

Es as como se encuentra en la literatura relevante diferentes atributos para definir la calidad de un producto de software. La propuesta por ISO-IEC 9126 parece ser la ms completa. Presentados diferentes enfoques para medir la calidad de un producto de software es que es tarea del evaluador dar prioridad o peso a los atributos de su importancia. Esto puede ser hecho con la ayuda del modelo GQM [2], es decir, formulando metas (Goals) que identifican claramente los propsitos de la evaluacin, elaborando preguntas (Questions) que apunten a satisfacer las metas planteadas, y finalmente, identificando las mtricas (Metrics) o mediciones a utilizar para responder a cada pregunta. Por tanto, lo primero a considerar es tener claro que la evaluacin de un producto de software puede ser hecho desde diferentes puntos de vista, pues depender de quin evale y de lo que desee evaluar. Por ejemplo, de presentarse la situacin en que se desea evaluar la calidad de un paquete de software para el cual no se tendr acceso al mdulo fuente, slo debiera formularse una lista de comprobacin desde el punto de vista de aquellos relacionados con adquisicin (interesados en criterios como: costo, facilidad de instalacin, facilidad de interoperacin, aspectos de eficiencia o rendimiento, embalaje, seguridad, capacidad de soporte) y usuario (aspectos de funcionalidad, confiabilidad, eficiencia, documentacin, seguridad y facilidad de operacin). Pero si la situacin es evaluar un producto de software hecho a medida por personal interno o externo, supuesto en que s se dispondr del mdulo fuente, la nmina de evaluadores sin duda incluir a personal de desarrollo, mantencin, staff de aseguramiento de calidad (o evaluadores independientes), auditora. En estas circunstancias, la lista de comprobacin incluira, adems de lo mencionado anteriormente, criterios dirigidos a la modificacin, revisin y transicin del software (facilidad de mantencin, flexibilidad, facilidad de prueba, portabilidad, reusabilidad, facilidad de auditora, estandarizacin de datos, autodocumentacin). En sntesis, los evaluadores al establecer claramente sus objetivos de lo que deseen evaluar, podrn confeccionar una lista de comprobacin de atributos del software en forma acertada, y para ello se pueden apoyar en el modelo GQM. Por ejemplo, desde el punto de vista del responsable por el proceso de mantencin del software, la aplicacin de GQM podra ser:

G: Q1: Q2: Q3: Q4: M1.1: M1.2: M1.3: M1.4: M1.5: M1.6: M1.7: M1.8: M1.9: M2.1: M2.2: M3.1: M3.2: M3.3: M3.4: M3.5: M3.6: M3.7: M4.1: M4.2:

Evaluar el proceso de mantencin de un producto de software a objeto de asegurar la facilidad en su ejecucin. Qu atributos debe poseer un producto de software para hacer el proceso de mantencin una tarea fcil? Qu esfuerzo se requiere para llevar a cabo una modificacin al software? Qu esfuerzo se requiere para efectuar una prueba al software? Cunto cuesta realizar la mantencin? Simplicidad (complejidad ciclomtica) Chequeo de existencia de autodocumentacin del software Chequeo de que la autodocumentacin est actualizada Chequeo de que la autodocumentacin est completa Chequeo de existencia de documentacin externa del software Chequeo de que la documentacin externa del software est actualizada Chequeo de que la documentacin externa del software est completa Chequeo de la estructura del software obedezca a mdulos con alto grado de cohesin y bajo grado de acoplamiento Chequeo de existencia de aplicacin de estndares Cantidad de programadores abocados a la tarea de modificacin del software/tiempo en ejecutar la tarea Clculo de TMEC -Tiempo Medio Entre Cambios- (Gilb [1]) Cantidad de programadores abocados a la tarea de probar el software/tiempo dedicado a ejecutar la tarea Eficacia en la remocin de defectos= cantidad de defectos encontrados y removidos/tamao del mdulo (LOC) o tamao del sistema(PF) Densidad de defectos por mdulo= cantidad de defectos/tamao del mdulo(LOC) Eficiencia en la remocin de defectos= cantidad de defectos encontrados y removidos/tiempo dedicado a encontrarlos y removerlos Chequeo de existencia y aplicacin de revisiones de diseo de alto nivel Chequeo de existencia y aplicacin de revisiones de diseo detallado Chequeo de existencia y aplicacin de revisiones durante la etapa de codificacin Costo de mantencin= tiempo dedicado a esta tarea [hr]/valor hora-hombre (programador) Costo de mantencin= tiempo dedicado a esta tarea [hr]/valor hora-mquina (UCP)

Ocurre que algunos ndices propuestos en el ejemplo no tienen significado al evaluar por primera vez el proceso de mantencin, pues no existe algn otro valor de referencia con el cual comparar, para poder finalmente aseverar si el producto de software tiene o no el atributo de proveer facilidad de mantencin. Frente a este hecho, se propone que el aspecto de calidad debe ser abordado como parte de la cultura organizacional, es decir, se deben llevar a cabo como prctica organizacional todas las actividades que aseguren y permitan evaluar la calidad de un producto de software. Al poseer datos histricos de otras aplicaciones, en algn repositorio, se contar con mejores argumentos para poder dilucidar y apoyar esta aseveracin.

Ahora bien, continuando con el ejemplo, si por meta de calidad se entiende que es la calidad necesaria y suficiente para reflejar los requerimientos reales del usuario [10], se propone determinar un grado o nivel de performance para todos aquellos atributos o mtricas que no son cuantificables en forma directa o indirecta. Es decir, la asignacin de un grado de performance con el cual se satisfaga la caracterstica de calidad necesaria, representado por un conjunto especfico de valores o en forma porcentual, de acuerdo al grado de cumplimiento. En lo especfico del ejemplo, las mtricas mencionadas con relacin a la autodocumentacin, documentacin, checklist de revisiones y aplicacin de estndares pueden evaluarse de esta forma. Por ltimo, a raz de que pueden existir varios evaluadores que participen en el proceso de evaluacin de un producto de software, se sugiere, de estimarse conveniente, ponderar cada puntaje asignado para, as, por ejemplo, dar mayor grado de influencia a quien tenga la responsabilidad de decidir sobre la adquisicin o no de un paquete de software, en vez de quien lo vaya a operar. IV. Aplicacin.

SQUID (Software Quality In Development) [11, 12, 13] es un mtodo y una herramienta para el aseguramiento y el control de la calidad que permite a una organizacin desarrolladora de software planificar y controlar la calidad del producto durante su desarrollo. Es decir, es un mtodo basado en mediciones para especificar, planificar, controlar y evaluar la calidad de un producto. SQUID especifica un modelo de calidad en trminos de caractersticas de calidad (propiedades abstractas que no pueden medirse en forma directa), las que son refinadas hasta que son propiedades directamente medibles y, por lo tanto, pasan a constituir lo que llama atributos de calidad. Una base de datos provista por la herramienta permite almacenar los valores objetivos definidos durante la fase de especificacin de calidad, para en forma posterior, en la etapa de control de calidad, ser comparados con los valores reales de los atributos de calidad internos. En la fase de evaluacin de calidad presentada por el mtodo SQUID, se cerciora de que el producto satisfaga los requerimientos especificados. El mecanismo de evaluacin bsico provisto por SQUID consiste en: - medir los valores reales de los atributos externos para cada porcin del producto (partes del producto de software con diferentes requerimientos de calidad) - comparar cada valor actual con su respectivo valor objetivo, e - informar de las desviaciones de calidad producidas.

Para el ejemplo descrito en la seccin anterior (facilidad de mantencin), una vista externa del modelo de calidad que identifica las subcaractersticas externas y los atributos externos aplicando SQUID sera [12]:

Caracterstica de calidad Facilidad de mantencin

Subcaracterstica externa Mantencin correctiva

Mantenibilidad adaptable

Atributo externo Tiempo de recuperacin Tamao del cambio Eficacia de contencin de falta Productividad de la modificacin

Y una vista interna del modelo de calidad que conecta caractersticas de calidad con subcaractersticas internas y atributos internos sera: Caractersticas ca-lidad Facilidad mantencin de Subcaractersticas internas de Modularidad SubSubcaracterstic Atributo interno as de calidad internas Cohesin Eficiencia de localizacin de fallas Acoplamiento Mando de acoplamiento Reuso interno Uso de datos comn Simplicidad Tamao Eficiencia de descomposicin Complejidad estructural Documento Conformidad para Analisibilidad documentos estndares Legibilidad del documento Legibilidad del Densidad del cdigo comentario

Facilidad de anlisis

V.

Anlisis y conclusiones.

Un factor clave para asegurar la calidad adecuada de un producto de software es realizar una especificacin completa de los atributos que debiera cumplir, por todos los que tengan la responsabilidad en la evaluacin de l.

Esto puede llevarse a cabo definiendo los criterios de calidad apropiados considerando el o los objetivo(s) de evaluacin que se ha(n) definido. Es importante que el producto de software sea evaluado para cada caracterstica de calidad relevante usando mtricas validadas y ampliamente aceptadas. La mayora de las mtricas propuestas por entendidos en la materia, y expresadas en este artculo, obedecen a medidas indirectas hechas sobre el producto. Para avanzar hacia la solucin de este hecho (aplicando cada vez ms mediciones directas) es que se requiere de la formulacin de una definicin ms precisa de calidad de software y, de esta manera, deducir mediciones cuantitativas de la calidad del software para obtener un anlisis ms objetivo. La aplicacin de toda la metodologa SQUID y el uso de su herramienta posibilita a quienes evalen lograr este cometido. El proceso de evaluacin de un producto de software, adems de responder a la interrogante de que si es o no calificable de calidad, puede ayudar a disminuir la tasa de defectos, el tiempo dedicado a la etapa de mantencin, mejorar la satisfaccin del cliente o usuario y disminuir el costo de desarrollo, si se analizan las causas de las deficiencias detectadas en el producto para no volver a reproducirlas. VI. Bibliografa y Referencias.

Utilizar nomenclatura en cita y en lista bibliogrfica de acuerdo a Norma ISO. Especificar lista biblografa en orden alfabtico. Ver link Formato presentacin bibliografa y citas bibliogrficas en Temas y enlaces de inters, de mi pgina web. [1] [2] [3] [4] [5] [6] Roger S. Pressman. Software Engineering. A Practitioners Approach. McGraw Hill. 4ta. Edicin, 1997. Norman E. Fenton y Shari Lawrence Pfleeger. Software Metrics. A Rigorous and Practical Approach. PWS Publishing Company. 2da. Edicin, 1997.
http://irb.cs.uni-magdeburg.de/sw-eng/us/

Ian Sommerville. Software Engineering. Addison-Wesley. 5ta. Edicin, 1996. ISO/IEC FCD 9126-1.2: Information Technology Software product quality Part 1: Quality model. 19 de junio de 1998. ISO/IEC 14598-3: Information Technology Software product evaluation Part 3: Process for developers. 3 de junio de 1998.

[7] [8] [9] [10] [11]

Mrcia Regina M. Martinez et al. The Software Product Evaluation Data Base Supporting MEDE-PRODS. Paper presentado a ISSES 99. 1999. Erick van Veenendaal, Julie McMullan. Achieving Software Product Quality. Uitgeverij Tutein Nolthenius Publishers. 1997. Watts S. Humphrey. A Discipline for Software Engineering. Addison-Wesley Publishing Company. 1995. Primer Simposio Latinoamericano de Calidad y Productividad en Desarrollo de Software. INTEC-CORFO Chile. Santiago de Chile. Noviembre de 1997. Jorgen Boegh, Stefano Depanfilis, Barbara Kitchenham, Alberto Pasquini. A Method for Software Quality Planing, Control and Evaluation. IEEE Software. Marzo/abril 1999. Jorge S. Bozo Parraguez. SQUID como Apoyo a la Gestin de Calidad en un Ambiente de Desarrollo Automatizado. Memoria para optar al ttulo de Ingeniero Civil Informtico, UTFSM. Abril de 1998. Barbara Kitchenham, Stephen Linkman, Jorgen Boegh, Alberto Pasquini. SQUID Conceptual Handbook. Work Package 3, Report D3.7/1, Esprit Project P8436, Junio de 1996. S. De Panfilis, M. Venturini, R. Stefani, R. Bottacin. MO01. La Qualit nello sviluppo di un prodotto Software Manuale operativo. Engineering Ingegneria Informatica S.p.A. Septiembre 1 de 1993.

[12]

[13]

[14]