CST - T8 - Ingeniería Informática - PDF

INGENIERÍA INFORMÁTICA LA EVALUACIÓN TEMA: Evaluación, medición y métricas Ing. David Sánchez Rivero  Hoy en día la calidad es un término que preocupa a las empresas productoras de software y que debe tenerse en cuenta en todas las etapas del desarrollo del mismo. Independientemente d...

INGENIERÍA INFORMÁTICA LA EVALUACIÓN TEMA: Evaluación, medición y métricas Ing. David Sánchez Rivero  Hoy en día la calidad es un término que preocupa a las empresas productoras de software y que debe tenerse en cuenta en todas las etapas del desarrollo del mismo. Independientemente del tipo de producto que se esté desarrollando, la calidad es fundamental para lograr la satisfacción de las necesidades y expectativas del cliente. Las métricas de software proporcionan información objetiva que contribuye al mejoramiento de los procesos y productos de software, lo cual evidentemente favorece al logro de la calidad. En la actualidad, el uso de las métricas se está poniendo en práctica con éxito en el amplio mercado del software pues las empresas productoras están reconociendo la importancia que tienen las mediciones para cuantificar y por consiguiente gestionar de forma más efectiva la calidad de los procesos y productos de software. En empresas que se dedican exclusivamente a la informática, se tiene noción de la necesidad de formalizar los mecanismos de estimación, comprendiendo que los registros históricos de antiguos proyectos realizados pueden ayudar a estimar con mayor exactitud el esfuerzo, tiempo de desarrollo, costo, posibles errores, recursos y tamaño para los nuevos proyectos. Es válido aclarar que en ocasiones los resultados de los procesos de medición no son interpretados de la mejor manera, pues aún existen compañías que no tienen una cultura adecuada sobre la medición, desconociendo el alcance de madurez y calidad que pudiera alcanzar el producto final. Lord Kelvin dijo alguna vez: Cuando puedes medir aquello de lo que hablas y expresarlo en números, sabes algo acerca de ello; pero cuando no puedes medir, cuando no puedes expresarlo en números, tu conocimiento es exiguo e insatisfactorio: puede ser el comienzo del conocimiento; sin embargo, apenas habrás avanzado, en tus pensamientos, hacia la etapa de una ciencia. Calidad del Software & Testing 2  Para evaluar la calidad del software, primero hay que establecer los requisitos de la evaluación, para luego especificar, diseñar y ejecutar la evaluación. Para establecer requisitos y objetivos se deben completar cuatro tareas fundamentales: Establecer el propósito de la evaluación, identificar el producto a evaluar, identificar los requerimientos de calidad y elegir el marco de calidad. Establecer el Propósito de la Evaluación: Según la Norma IRAM: “El propósito de la evaluación de la calidad del software es apoyar directamente tanto el desarrollo como la adquisición de un software que satisfaga las necesidades del usuario y del cliente. El objetivo final es asegurarse de que el producto proporciona la calidad requerida, que satisface las necesidades explícitas e implícitas de los usuarios (incluyendo a los operadores, a los receptores de los resultados del software, o al personal de mantenimiento del software)”. En sentido general, el propósito de la evaluación de la calidad puede ser: Aceptar o rechazar un producto de software desarrollado o comprado. Predecir o estimar la calidad de dicho producto. Comparar un producto con los productos competidores. Seleccionar un producto entre productos alternativos. Decidir cuándo mejorar o sustituir un producto. Identificar el Producto a Evaluar: Se debe identificar claramente el producto a evaluar, o la parte del producto sujeto a evaluación. Así, tenemos cuatro posibles escenarios: 1. En Desarrollo: Para pasar a la siguiente etapa de desarrollo. Aquí tienen impacto los artefactos y los módulos existentes, tanto como sus relaciones con el Plan de Proyecto de Desarrollo del Software. Estos pueden cambiar y actualizarse en tanto se avanza en el desarrollo de la aplicación. Calidad del Software & Testing 3  2. Desarrollado: Para estimar su calidad final. Se debe identificar todos los artefactos y los módulos existentes relativos al software o al módulo bajo estudio. 3. Desarrollado: Cuando queda obsoleto o cuando se lanza una actualización. 4. Evaluación y selección de un software entre productos alternativos: los productos a evaluar son productos finales de software o componentes, ya sean construidos a medida, prefabricados o incluso prototipos. En cualquiera de los casos, si no es posible identificar en detalle, es necesario documentar inicialmente una lista de los aspectos conocidos, que luego se irá refinando. Identificar los requerimientos de calidad: En esta etapa, hay una serie de definiciones que hay que realizar: En función del Stakeholder “Factor que encarga la evaluación”, se debe identificar cuáles serán los demás Stakeholders: Evaluador, Factor normativo, Inversor en el desarrollo, Sponsor, Usuario, Empresa del usuario, Otras empresas, Ingeniero de requerimientos, Analista de sistemas, Diseñador del software, Programador, Gerente de Proyecto, Tester, Analista QA. Se debe especificar cuáles son los Requerimientos de Calidad para el Producto Software, usando para ello, algunos de los Modelos de Calidad existentes. Elegir el Marco de Calidad: Para lograr definir el marco de calidad, se cuenta con dos tareas fundamentales: 1. Definir el Modelo de Calidad a usar: En función de lo especificado en Identificar los Requerimiento de Calidad, se debe especificar el Modelo de Calidad a utilizar para la Evaluación. 2. Definir la rigurosidad del modelo: Se usará el modelo en el cual los parámetros de ponderación, las rigurosidades y las fidelidades serán todas idénticas a los pesos relativos obtenidos de los cuestionarios por la característica básica que de ella derivan. Calidad del Software & Testing 4  Todas las organizaciones de software exitosas implementan mediciones como parte de sus actividades cotidianas pues estas brindan la información objetiva necesaria para la toma de decisiones y que tendrá un impacto efectivo en el negocio y desempeño en la ingeniería. Para poder asegurar que un proceso o sus productos resultantes son de calidad o poder compararlos, es necesario asignar valores, descriptores, indicadores o algún otro mecanismo mediante el cual se pueda llevar a cabo dicha comparación. Para entender mejor el concepto de métrica es necesario aclarar que los términos, métricas, medición y medida no tienen el mismo significado. Medida: Proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto. Medición: La medición es el acto de determinar una medida. Métrica: Es una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. Se definen las métricas de software como “La aplicación continua de mediciones basadas en técnicas para el proceso de desarrollo del software y sus productos, para suministrar información relevante a tiempo, así el administrador junto con el empleo de estás técnicas mejorará el proceso y sus productos”. Para una definición más completa debe incluirse los servicios relacionados al software como la respuesta a los resultados del cliente: Ver Fig. 1. Figura 1. Concepto de Métricas. Calidad del Software & Testing 5  Características de las Métricas Para que sea útil en el contexto del mundo real, una métrica del software debe ser objetiva, simple y calculable, consistente en el empleo de unidades y tamaños, persuasiva, además debería ser independiente del lenguaje de programación y proporcionar una realimentación eficaz para el desarrollador de software. ¿Por qué se debe asegurar que las métricas cumplan estas condiciones?: Las métricas deben ser un instrumento que ayude a mejorar el proceso, producto o proyecto de software, no tiene mucho sentido aplicar métricas que lejos de ayudar a los desarrolladores constituyan un problema; bien por ser demasiado complejas, o porque no se entienden correctamente los objetivos que persiguen o porque arrojen resultados imprecisos que no puedan ser interpretados por los ingenieros de software. Es importante entonces que una métrica pueda obtenerse fácilmente, que se entienda por qué y para qué se utiliza, que los cálculos no produzcan resultados ambiguos o en los que existan extrañas combinaciones de unidades, y que la interpretación de valores obtenidos esté acorde a las nociones intuitivas del ingeniero de software. Por otra parte las métricas no deben ser específicas para ningún lenguaje de programación o metodología de desarrollo. Proceso de Medición Todo proceso de medición del software tiene como objetivo fundamental satisfacer necesidades de información a partir de las cuales se deben identificar las entidades y los atributos que deben ser medidos. El proceso de medición, se caracteriza por cinco actividades: Formulación: Obtención de medidas y métricas del software apropiadas para la presentación del software en cuestión. Calidad del Software & Testing 6  Colección: Mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. Análisis: Cálculo de las métricas y la aplicación de herramientas matemáticas. Interpretación: La evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la presentación. Retroalimentación: Recomendaciones obtenidas de la interpretación de métricas y técnicas transmitidas al equipo de desarrollo de software. Clasificación de las Métricas Existen innumerables métricas con propósitos diferentes que reflejan o describen la conducta del software, estas pueden medir entre otros aspectos la competencia, calidad, desempeño y la complejidad del software contribuyendo a establecer de una manera sistemática y objetiva una visión interna del trabajo mejorando así la calidad del producto. A continuación se detalla una clasificación de las mismas: Métricas de complejidad: Son todas las métricas de software que definen de una u otra forma la medición de la complejidad. Tales como volumen, tamaño, anidaciones, costo (estimación) y configuración. Estas son los puntos críticos de la concepción, viabilidad, análisis y diseño de software. Métricas de calidad: Son todas las métricas de software que definen de una u otra forma la calidad del software; tales como exactitud, estructuración o modularidad, pruebas, mantenimiento, reusabilidad, entre otras. Estas son los puntos críticos en el diseño, codificación, prueba y mantenimiento. Calidad del Software & Testing 7  Métricas de competencia: Son todas las métricas que intentan valorar o medir las actividades de productividad de los programadores o practicantes con respecto a su certeza, rapidez, eficiencia y competencia. Métricas de desempeño: Corresponden a las métricas que miden la conducta de módulos y sistemas de un software, bajo la supervisión del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia de ejecución, tiempo, almacenamiento, complejidad de algoritmos computacionales, etc. Métricas estilizadas: Son las métricas de experimentación y de preferencia. Por ejemplo: estilo de código, las convenciones de datos, las limitaciones, etc. Pero estas no se deben confundir con las métricas de calidad o complejidad. Variedad de métricas: Tales como portabilidad, facilidad de localización, consistencia, etc. Estas clasificaciones de métricas fortalecen la idea de que más de una métrica puede ser deseable para valorar la complejidad y la calidad del software, teniendo en cuenta que para ello es necesario medir los atributos del software. Establecimiento de una línea base Un punto de partida para realizar estimaciones es establecer una línea base de métricas que permita a una organización sintonizar su proceso de ingeniería del software para eliminar las causas de los defectos que tienen el mayor impacto en el desarrollo del software, es fundamental que una línea base contenga datos recopilados de proyectos desarrollados anteriormente lo que requiere una investigación histórica de los mismos; la línea base no es más que la recopilación de medidas, métricas e indicadores que guíen el proyecto o el proceso. Ver Fig. 2. Calidad del Software & Testing 8  Figura 2. Proceso de recopilación de métricas del Software. Por lo general la información reunida no necesariamente tiene que ser diferente. Las mismas métricas pueden obtener beneficios a nivel de proceso, proyecto y producto. Métricas del Proceso Las métricas del proceso se recopilan de todos los proyectos y durante un largo período de tiempo. Su intento es proporcionar indicadores que lleven a mejoras de los procesos de software a largo plazo. Un indicador es una métrica o una combinación de métricas que proporcionan una visión profunda del proceso del software, del proyecto de software o del producto en si. La medición del proceso implica las mediciones de las actividades relacionadas con el software siendo algunos de sus atributos típicos el esfuerzo, el costo y los defectos encontrados. Las métricas permiten tener una visión profunda del proceso de software que ayudará a tomar decisiones más fundamentadas, ayudan a analizar el trabajo desarrollado, conocer si se ha mejorado o no con respecto a proyectos anteriores, ayudan a detectar áreas con problemas para poder remediarlos a tiempo y a realizar mejores estimaciones. Calidad del Software & Testing 9  Para mejorar un proceso se deben medir los atributos del mismo, desarrollar métricas de acuerdo a estos atributos y utilizarlas para proporcionar indicadores que conduzcan a la mejora del proceso. Los errores detectados antes de la entrega del software, la productividad, recursos y tiempo consumido y ajuste con la planificación son algunos de los resultados que pueden medirse en el proceso, así como las tareas específicas de la ingeniería del software. Actualmente existen diversas métricas, y éstas deben usarse conforme se ajusten al proceso. Las métricas del proceso se caracterizan por: El control y ejecución del proyecto. Medición de tiempos del análisis, diseño, implementación, implantación y postimplantación. Medición de las pruebas (errores, cubrimiento, resultado en número de defectos y número de éxitos). Medición de la transformación o evolución del producto. ¿Por qué el proceso? Como se observa en la Fig. 3, existen varios factores que determinan la calidad del software y la eficiencia de la organización, entre ellos están la complejidad del producto, la tecnología (es decir, los métodos y herramientas de la ingeniería del software) y las personas (su habilidad y motivación), así como algunas condiciones de entorno que también tienen su impacto, estas pueden ser condiciones de gestión (Ej.: plazo de entrega, reglas empresariales), entornos de desarrollo (Ej. herramientas de software integradas) y características del cliente (Ej. facilidad de comunicación y colaboración); sin embargo en el centro de todas ellas se encuentra el proceso pues es el único factor de los controlables al mejorar la calidad del software y su rendimiento como organización. Analizando y mejorando el proceso se puede obtener mejores productos. Calidad del Software & Testing 10  Figura 3. Determinantes de la calidad del software y de la efectividad de la organización. La eficacia de un proceso de software sólo puede medirse de manera indirecta. Esto significa que es posible derivar un conjunto de métricas con base en los resultados que pueden derivarse del proceso. Los resultados incluyen medidas de los errores descubiertos antes de liberar el software, defectos entregados a y reportados por usuarios finales, productos operativos entregados (productividad), esfuerzo humano empleado, tiempo calendario consumido, conformidad con la agenda y otras medidas. También pueden derivarse métricas de proceso al medir las características de tareas de ingeniería de software específicas. Por ejemplo, puede medirse el esfuerzo y el tiempo empleados al realizar las actividades sombrilla y las actividades genéricas de ingeniería del software. Calidad del Software & Testing 11  Dado que el proyecto engloba todos los recursos, actividades y artefactos, que se organizan para lograr un producto de software es de vital importancia definir algunas mediciones que ayuden al mejoramiento del mismo. A nivel de proyecto se minimiza la planificación de desarrollo haciendo los ajustes necesarios para evitar retrasos o riesgos potenciales, minimizar los defectos, y por tanto la cantidad de trabajo que ha de rehacerse, lo que ocasiona una reducción del coste global del proyecto, además puede evaluarse la calidad de los productos en el momento actual y cuando sea necesario. La primera aplicación de métricas de proyectos, en la mayoría de los proyectos de software, ocurre durante la estimación. Las métricas recopiladas de proyectos anteriores se utilizan como una base desde la que se realizan las estimaciones del esfuerzo y del tiempo para el actual trabajo del software. A medida que avanza un proyecto, las medidas del esfuerzo y del tiempo consumido se comparan con las estimaciones originales (y la planificación de proyectos). El gestor de proyectos utiliza estos datos para supervisar y controlar el avance. A medida que comienza el trabajo técnico, otras métricas de proyectos comienzan a tener significado. Se miden los índices de producción representados mediante páginas de documentación, las horas de revisión, los puntos de función y las líneas fuentes entregadas; en el proyecto se sigue la pista de los errores detectados durante todas las tareas de ingeniería del software. Cuando va evolucionando el software desde la especificación del diseño, se recopilan las métricas técnicas para evaluar la calidad del mismo y para proporcionar indicadores que influirán en el enfoque tomado para la generación y prueba del código. Calidad del Software & Testing 12  Finalmente los indicadores de proyecto permiten: Evaluar el estado del proyecto en curso. Seguir la pista de los riesgos potenciales. Detectar las áreas de problemas antes de que se conviertan en “críticas”. Ajustar el flujo y las tareas del trabajo. Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo del software. La intención de las métricas de proyecto es doble. Primero, se usan para minimizar el calendario de desarrollo al hacer los ajustes necesarios para evitar demoras y mitigar potenciales problemas y riesgos. Segundo, se usan para valorar la calidad del producto sobre una base en marcha y, cuando es necesario, modificar el enfoque técnico para mejorar la calidad. Conforme la calidad mejora, los defectos se minimizan, y conforme el conteo de defectos baja, la cantidad de reelaboración requerida durante el proyecto también se reduce. Esto conduce a una reducción en el costo global del proyecto. Calidad del Software & Testing 13  Las métricas del producto se centran en las características del software y no en cómo fue producido. Un producto no es solo el software o sistema funcionando sino también los artefactos, documentos, modelos, módulos o componentes que lo conforman, por tanto, las métricas del producto deben hacerse sobre la base de medir cada uno de estos. Por ejemplo en los artefactos del producto se mide, entre otras cosas: el tamaño, la calidad (teniendo en cuenta los defectos, la complejidad, entre otros), la totalidad, la rastreabilidad, la volatilidad, el esfuerzo. Aunque las métricas de producto para el software de computadora son imperfectas, pueden proporcionar una forma sistemática de valorar la calidad con base en un conjunto de reglas claramente definidas. También proporcionan comprensión inmediata, en lugar de hacerlo después de los hechos. Esto permite descubrir y corregir potenciales problemas antes de que se conviertan en defectos catastróficos. Durante las cuatro décadas pasadas, muchos investigadores intentaron desarrollar una sola métrica que proporcionara una medida abarcadora de la complejidad del software. Fenton caracteriza esta investigación como una búsqueda del “imposible Santo Grial”. Aunque se han propuesto decenas de medidas de complejidad, cada una toma una visión un poco diferente de lo que es la complejidad y de qué atributos de un sistema conducen a la complejidad. Aunque existe la necesidad de medir y de controlar la complejidad del software, y si bien un solo valor de esta métrica de calidad es difícil de derivar, es posible desarrollar medidas de diferentes atributos internos de programa (por ejemplo, modularidad efectiva, independencia funcional y otros atributos, entre otros). Estas medidas y las métricas derivadas de ellas pueden usarse como indicadores independientes de la calidad de los modelos de requerimientos y de diseño. Calidad del Software & Testing 14  El principal objetivo de los ingenieros del software es producir un sistema, aplicación o producto de alta calidad, para lo cual emplean métodos y herramientas efectivas dentro del contexto de un proceso maduro de desarrollo del software y además deben desarrollar mediciones que den como resultado sistemas de alta calidad. Para obtener esta evaluación, el ingeniero debe utilizar medidas técnicas, que evalúan la calidad con objetividad, no con subjetividad. En la norma ISO 9126 se proponen un grupo de métricas que atribuyen a los factores de calidad. A pesar del avance en el desarrollo de software y las tecnologías, con el paso de los años los atributos que proporcionan una indicación de la calidad del software siguen siendo los mismos, en este sentido en inevitable mencionar el trabajo desarrollado por McCall y Cavano en cuanto a la definición de factores de calidad, pues a pesar del tiempo, sus estudios han sido una guía para otros modelos y normas de calidad. La norma ISO 9126 es un ejemplo de ello, muchas características y subcaracterísticas definidas en la misma (Ver Tabla 1) hacen referencia a la operación, transición y revisión del software y aunque no las dividen en estos tres grupos, señalan entre otras cosas la necesidad de lograr que el software opere correctamente y con el grado de exactitud requerido, que los usuarios sean capaces de entenderlo y usarlo, es decir que sea amigable con quienes interactúen con él, que sea capaz de responder correctamente ante fallos o cambios del entorno y que proporcione una ejecución o desempeño apropiado, teniendo en cuenta los recursos utilizados. PROPUESTA DE MÉTRICAS Las métricas propuestas miden el desarrollo de los proyectos y ayudan a los líderes y directivos de los mismos en la toma decisiones y acciones correctivas, así como el mejoramiento continuo de los procesos, obteniéndose mejores resultados. Calidad del Software & Testing 15  Tabla 1. Características de la Norma ISO 9126 y aspectos que atiende cada una En el área de proceso, la captura de requisitos en una correcta gestión de requisitos contribuye, en gran medida, al éxito de los proyectos de software, aportando el entendimiento y la comprensión de los problemas que se necesitan solucionar y cómo resolverlos, definiendo con claridad, sin ambigüedades, en forma consistente y compacta lo que se desea producir. Las métricas propuestas fueron: Entendimiento de los requisitos: referida a la capacidad de entender el significado de los requisitos, o sea que no exista ambigüedad, que cada requisito tenga una sola interpretación. Estabilidad de los requisitos: referida a los cambios que sufren los requisitos a lo largo de todo el ciclo de vida del software incluyendo la eliminación, inserción y modificación; estos continuos cambios en la especificación de los requisitos traen consigo un atraso en el cronograma de trabajo. Calidad del Software & Testing 16  La elaboración del plan de proyecto es otra de las áreas en las que se propusieron métricas. El plan constituye una guía para la realización y el control del proyecto y sus actividades, en él se asignan las responsabilidades, recursos y fechas de cumplimiento a las tareas. El plan incluye estimación de los elementos de trabajo y tareas, recursos necesarios, negociación de compromisos, establecimiento de un calendario, e identificación y análisis de los posibles riesgos que pueda tener el proyecto. Dentro de la planificación del proyecto se proponen las siguientes métricas relacionadas con las tareas a cumplir, los plazos destinados a las mismas, el tiempo, esfuerzo y productividad. Porcentaje de tareas completadas: con el objetivo de llevar un registro de las mediciones de las tareas que se desarrollan durante el proyecto, pues de esta manera pueden realizarse mejores asignaciones de recursos y tiempo, así como tener una medida del progreso del trabajo realizado respecto al planificado teniendo en cuenta el cumplimiento de las tareas. Porcentaje de error de estimación de Tamaño: teniendo registros de cuanto puede desviarse el tamaño real del software respecto al planificado pueden realizarse mejores estimaciones para futuros trabajos con características similares, de manera que pueda minimizarse lo más posible el porcentaje de error en la estimación del tamaño. La estimación del tamaño es un punto de partida para realizar cálculos y estimaciones de tiempo, costo y esfuerzo. Porcentaje de error de estimación de Tiempo: de manera análoga a la métrica anterior también puede analizarse el error de estimación del tiempo. Estos registros ayudarán a hacer mejores estimaciones de tiempo para trabajos futuros. Calidad del Software & Testing 17  Productividad: con el objetivo de calcular la producción de código por unidad de tiempo y el esfuerzo necesario para desarrollar un software. A medida que se avanza en los ciclos de desarrollo del proyecto, la productividad se incrementa. Otra de las áreas es la gestión de riesgos, en la que pueden identificarse tempranamente los posibles riesgos y tomar medidas correctivas para mitigarlos a tiempo, estos deben tenerse en cuenta para decidir si se continúa con el proyecto. Esta es una de las actividades que se inicia en la primera etapa de un proyecto y se desarrolla a lo largo de todo su ciclo de vida llegando finalmente hasta la aceptación del producto obtenido. Medición de la Identificación de los Riesgos: es una medida para guardar los riesgos más comunes en cada una de las etapas del desarrollo del software así como las consecuencias que traen consigo cada uno de ellos (el incremento de los costos, la cancelación del proyecto, la insatisfacción del cliente, entre otras), de manera tal que al cabo de cierto tiempo, guardando estos registros históricos, y al comenzar un nuevo proyecto se tengan identificados los posibles riesgos y prevenirlos, valorando además su repercusión en cuanto al alcance (cuánto afecta) y la duración (por cuánto tiempo se manifiesta). Probabilidad de que ocurran riesgos de un mismo tipo: calculando la probabilidad de ocurrencia de riesgos de un tipo determinado (personal, organizativos, de herramientas, de requerimientos, de estimación, de presupuesto, entre otros), se logrará organizarlos y, según la prioridad, mitigarlos para contrarrestar los efectos que puedan ocasionar al sistema. Calidad del Software & Testing 18  Efectividad de la mitigación de riesgos: con el objetivo de determinar la relación existente entre los riesgos mitigados y el total de riesgos identificados. Guardando estos datos puede conocerse cuán efectivos han sido los planes de mitigación de riesgos, o sea ya se tendrá un conocimiento de las soluciones que fueron efectivas y por lo tanto pueden ser usadas nuevamente para mitigar riesgos similares a los resueltos. Finalmente la etapa de prueba que es tan o más importante que todas las realizadas hasta el momento, en ella se refleja la calidad con que ha sido llevada a cabo la proyección del sistema. En esta etapa no se puede asegurar la ausencia de defectos solo puede demostrarse la existencia de los mismos. En todas las fases del desarrollo del proyecto hay que probar el software que se va construyendo y resulta muy importante definir un conjunto de mediciones para guardar los resultados de las mismas de manera que aporten información relevante para pruebas sucesivas. Las métricas utilizadas durante la fase de pruebas, junto con las técnicas de estimación adecuadas dan soporte para predecir y controlar los defectos esperados, la duración de las pruebas, los recursos dedicados, los defectos remanentes, etc. Rendimiento de la eliminación de defectos: con el objetivo de conocer la relación entre los defectos eliminados y todos los existentes en una etapa determinada del proyecto de software. Es importante que todos los defectos sean encontrados y eliminados en la etapa que se esté analizando y se reduzcan los defectos evadidos. Integridad de la implementación funcional: es una medida de cuán completa ha sido la implementación según la especificación de requisitos, se detectan el número de funciones perdidas, aquellas que fueron descritas en la especificación de requisitos y no fueron implementadas. Calidad del Software & Testing 19  Con esta métrica se evalúa la completitud de la implementación, si se tienen muchas funcionalidades perdidas, no si se desarrolló una buena implementación, lo cual implicará la toma de acciones correctivas para controlar este proceso de manera tal que no se vea afectada la calidad del producto final. Cobertura de las pruebas: indica cómo se van cumpliendo los casos de prueba especificados, por lo tanto mientras mayor sea la cobertura, mayor número de casos de prueba se estarán cumpliendo, de esta manera se llevará un control del cumplimiento de los casos de prueba requeridos para cubrir los requisitos lo que, por supuesto, da una medida de cuan correctamente se está desarrollando el proceso de prueba. La madurez de las pruebas: es un indicador de qué tan bien se está desarrollando el proceso de prueba; no solo se preocupa de la completitud de los casos de prueba, según los definidos para cumplir los requisitos, sino que también se interesa por cuales han obtenido resultados satisfactorios. Para ello es necesario llevar un control de los casos de prueba que arrojaron resultados satisfactorios y el total de los casos de prueba definidos para el cumplimiento de los requisitos. El porcentaje de defectos por tipo: se calcula con el objetivo de identificar los tipos de defectos más comunes que puedan presentarse en cualquiera de las etapas del proceso de desarrollo del software; es aplicable, de manera individual, para cada desarrollador o por equipo de trabajo. Este porcentaje sería de los tipos de defectos que se encontraron tanto en las revisiones, como luego en las compilaciones y en las pruebas. Calidad del Software & Testing 20  Porcentaje del tiempo total dedicado a las pruebas: es una medida del porcentaje del tiempo dedicado a las pruebas respecto al tiempo total del proyecto. El tiempo de la prueba será mayor mientras más defectos se hayan introducido en el software. Este tiempo dedicado a las pruebas dependerá en gran medida del tamaño y complejidad del software que se esté desarrollando, los proyectos similares al analizado tendrán una referencia para estimar el tiempo que se debe emplear en las pruebas. Calidad del Software & Testing 21  El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores durante el proceso para evitar que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas inspecciones es el descubrimiento de errores, principio, para que no se propaguen al paso siguiente del proceso de desarrollo del software (catarata de errores de Mizuno). Una serie de estudios (TRW, Nippon Electric y Mitre Corp., entre otros) indican que las actividades del diseño introducen entre el 50% y 65% de todos los errores (y en último lugar, todos los defectos) durante el proceso de software. Sin embargo se ha demostrado que las inspecciones de software son efectivas en un 75% a la hora de detectar errores. Los beneficios de aplicar Inspecciones son: Reducción de los defectos en el uso del software. Reducción de los recursos de desarrollo, sobre todo en las etapas de codificación y prueba. Reducción en los costos de mantenimiento correctivo. El proceso de inspección Se puede ver a las inspecciones de software como un repaso detallado y formal del trabajo en proceso. Pequeños grupos de trabajadores (4 o 5) estudian el "producto de trabajo” independientemente y luego se reúnen para examinar el trabajo en detalle. El “producto de trabajo” representa 200 a 250 líneas de código; requerimientos, diseño y otros productos de trabajo son inspeccionados en un tamaño similar. Los productos de trabajo son considerados en progreso hasta que la inspección y las correcciones necesarias estén completas. El tiempo de la inspección varía según cuan familiarizado esté el inspector con el material. Calidad del Software & Testing 22