Métricas de productividad y calidad La medición es fundamental para cualquier disciplina de ingeniería. En el contexto de la planificación de proyecto, nos preocupamos principalmente por las métricas de productividad y de calidad: Medir el rendimiento de desarrollo como función del esfuerzo aplicado. Evaluar la calidad del desarrollo realizado. Crear una base histórica para poder planificar próximos proyectos. Nos interesa saber ¿Cual fue la productividad del desarrollo de software en anteriores proyectos? ¿Como era la calidad del software producido? ¿Cómo se pueden extrapolar al presente los datos de productividad anteriores? ¿Que técnicas son las más adecuadas según que proyectos? Encontramos dificultades en ponernos de acuerdo sobre que medir y como evaluar las medidas en el software.

Clasificación de las métricas Las mediciones se pueden englobar en dos categorías: Medidas directas El coste y el esfuerzo aplicado. El número de líneas de código (LDC), velocidad de ejecución, memoria, defectos. Medidas indirectas Funcionalidad, calidad, complejidad, eficiencia, fiabilidad, mantenimiento. Dependiendo de lo que se quiera medir, las métricas se clasifican en: Métricas orientadas al tamaño Son medidas directas sobre el resultado y la calidad del software Métricas orientadas a la función Son medidas indirectas Métricas orientadas a la persona Proporcionan información sobre la forma en que la gente desarrolla software y sobre el puntos de vista humano de la efectividad de las herramientas y métodos.

Clasificación de la métricas Podemos clasificar el campo de las métricas del software en Métricas de productividad. Miden el rendimiento del proceso Métricas de calidad. Miden como se ajusta el software a los requisitos implícitos y explícitos del cliente. Métricas técnicas. Se centra en las características del software (complejidad lógica, grado de modularidad).

Métricas orientadas al tamaño Las métricas del software orientadas al tamaño son medidas directas del software y del proceso por el cual se desarrolla. A continuación se muestran una serie de valores: Esfuerzo: 24 Ptas: 12 KLDC: 20,4 Páginas de documentos: 123 Errores: 18 Peronal: 4 Con los datos de la tabla se puede desarrollar, para cada proyecto, un conjunto de métricas sencillas de productividad y de calidad orientadas al tamaño. También se pueden calcular valores medios con todos los proyectos. Productividad = KLDC / persona-mes Calidad = errores / KLDC Costes = pesetas / KLDC Documentación = páginas /KLDC Falta la tabla de valores

Polémica de las métricas orientadas al tamaño Las métricas orientadas al tamaño son bastante polémicas. La mayor parte de la discusión gira en torno al uso de las líneas de código (LDC) como medida clave. Defensores LDC es un artificio que se puede calcular fácilmente para todos lo proyectos. Muchos modelos de estimación del software existentes utilizan LDC como clave de entrada Existe un amplio conjunto de datos y de literatura basados en LDC. Detractores LDC es altamente dependiente del lenguaje de programación. Perjudica a los programas cortos pero bien diseñado. No se puede adaptar fácilmente a lenguajes no procedimentales.

Métricas orientadas a la función Las métricas del software orientadas a la función son medidas indirectas del software y del proceso por el cual se desarrolla. Se centran en la “funcionalidad” o “utilidad” del programa. Albrecht, sugirió el método del punto de función. Los puntos de función (PFs) se obtienen utilizando una relación empírica basada en medidas cuantitativas del dominio de información del software y valoraciones subjetivas de la complejidad del software. Se basa en la evaluación de cinco características del ámbito de la información. La evaluación de cada una de estas características se pondera por un determinado peso dependiendo de si se considera simple, media o compleja. Falta la imagén

P.F.: Características del ámbito de la información Número de entradas de usuario. (simple * 3, medio * 4 y complejo * 6) Entrada de usuario que proporciona al software diferentes datos orientados a la aplicación. Número de salidas de usuario. (simple *4, medio *5 y complejo *7) Salidas que proporcionan al usuario información orientada a la aplicación (informes, pantallas, mensajes de error, etc.) Número de peticiones de usuario. (simple * 3, medio *4 y complejo *6) Una petición está definida como una entrada interactiva que resulta de la generación de algún tipo de respuesta en forma de salida interactiva (entrada-salida). Número de archivos (simple *7, medio *10 y complejo *15) Se cuenta cada archivo lógico. Número de interfaces externas. (simple * 5, medio * 7 y complejo *10) Se cuentan todas las interfaces legibles por la máquina (por ejemplo, archivos de datos en cinta o disco) que son utilizados para transmitir información a otro sistema.

P. F.: Cálculo de los P. F. A cada uno de estos valores se le asocia una complejidad. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada determinada es simple, media o compleja. No obstante, la determinación de la complejidad es algo subjetivo. Para calcular los puntos de función, se utiliza la siguiente relación: PF = cuanta_total x (0,65 + 0,01 x suma(Fi)) donde cuenta_total es la suma de las características ponderadas del ámbito. Fi (i = 1 hasta 14) son los valores de ajuste de complejidad basados en las respuestas a las cuestiones señaladas en la siguiente transparencia. Los valores constantes de la ecuación anterior y los factores de peso aplicados a las cuentas de los ámbitos de información han sido determinados empíricamente. Una vez calculados los puntos de función, se usan de forma análoga a las LDC como medida de la productividad, calidad y otros atributos del software: Productividad = PF / personas_mes Calidad = errores / PF Costes = pesetas / PF Documentación = páginas / PF

P. F.: Valores de ajuste de complejidad Cada una de las siguientes cuestiones se evalúa en una escala de 0 a 5: 0 = Sin influencia 1 = Incidental 2 = Moderado 3 = Medio 4 = Significativo 5 = Esencial 1. ¿Requiere el sistema copias de seguridad y recuperación fiables? 2. ¿Se requieren comunicaciones de datos? 3. ¿Existen funciones de procesamiento distribuido? 4. ¿Es crítico el rendimiento? 5. ¿Será ejecutado el sistema en un entorno operativo existente y fuertemente utilizado? 6. ¿Requiere el sistema entrada de datos interactiva? 7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas o variadas operaciones? 8. ¿Se actualizan los archivos maestros de forma interactiva? 9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 10. ¿ Es complejo el procesamiento interno? 11. ¿Se ha diseñado el código para ser reutilizable? 12. ¿Están incluidas en el diseño la conversión y la instalación? 13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? 14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?

P. F.: Puntos de características Se denomina puntos de características, a la métrica que incorpora a los puntos de función la complejidad de los programas. La medida del punto de característica da cabida a aplicaciones cuya complejidad algorítmica es alta. Las aplicaciones de software de tiempo real, de control de procesos y de sistemas empotrados tienden a tener una complejidad algorítmica alta y son por lo tanto fácilmente tratables por puntos de características. Además de los valores del ámbito de información, la métrica del punto de característica tiene en cuenta otra característica del software, los algoritmos. Un algoritmo se define como “un problema de complejidad computacional limitada que se incluye dentro de un determinado programa de computadora”. La inversión de una matriz, la decodificación de una cadena de bits o el manejo de una interrupción, son todos ellos ejemplos de algoritmos. Para calcular los puntos de característica, se suman las siguientes cantidades. Número de entradas de usuario * 4 Número de salidas de usuario * 5 Número de peticiones al usuario * 4 Número de archivos * 7 Número de interfaces externos * 7 Algoritmos * 3

P. F.: Punto de características Se usa un único valor de peso para cada uno de los parámetros de medida y se calcula el valor del punto de características global mediante la ecuación anterior. Los PF y los PC representan lo mismo: “funcionalidad” o “utilidad” en forma de software. Ambas medidas dan los mismos resultados para aplicaciones convencionales de sistemas de información, pero para sistemas más complejos de tiempo real, la cuenta de puntos de característica es frecuentemente entre un 20 y 35 por 100 mayor que la cuenta determinada sólo mediante puntos de función. Comentarios a la métrica del punto de función y de característica: Defensores PF y PC son independientes del lenguaje de programación. Detractores Requiere cierta habilidad, experiencia y subjetividad.

Cinco factores importantes que inciden en la productividad del software Factores humanos. El tamaño y la experiencia de la organización de desarrollo. Factores del problema. La Complejidad del problema a resolver y el número de cambios en las restricciones o los requisitos del diseño. Factores del proceso. Técnicas del análisis y diseño utilizadas, disponibilidad de lenguajes y herramientas CASE y técnicas de revisión. Factores del producto. Fiabilidad y rendimiento del sistema basado en computadora. Factores de los recursos. Disponibilidad de herramientas CASE, recursos de hardware y software. Tanto PF como LDC han resultado ser predicciones relativamente precisas del esfuerzo y del coste de desarrollo de software. Sin embargo para usar LDC y PF en las técnicas de estimación, se tiene que establecer una línea base de información histórica. ¿Se debe compara la relación LDC/persona_mes de un grupo con los datos similares de otro grupo? ¿Deben los gestores evaluar el rendimiento de las personas usando estas medidas? Hay muchos factores que influyen en la productividad, haciendo que la comparación sea mal interpretada.

Métricas para la calidad del software Las métricas de calidad contemplan la complejidad del programa, la modularidad efectiva y el tamaño total del programa. Factores de calidad McCall y Cavano propusieron un conjunto de factores de calidad hacia el desarrollo de métricas de calidad de software. Estos factores evaluaban el software desde tres puntos de vista distintos: Operación del producto (su uso) Revisión del producto (su modificación) Transición del producto (“transportarlo”)

Medidas de calidad Aunque existen muchas formas de medir la calidad del software, las métricas a posteriori son las más ampliamente utilizadas. Estas incluyen: Corrección Es el número de defectos por KLDC, donde defecto se define como la falta comprobada de conformidad con los requisitos. Los defectos los comunica un usuario del programa después de que el programa ha sido distribuido para su uso general y se cuentan durante un período de tiempo estándar, típicamente un año. Facilidad de mantenimiento El mantenimiento del software representa más esfuerzo que cualquier otra actividad de la Ingeniería del software. Es la facilidad con la cual se puede corregir un programa si se encuentra un error, adaptarlo si su entorno cambia, o mejorarlo si el cliente desea un cambio en los requisitos. No hay forma de medir directamente la facilidad de mantenimiento; por lo tanto, debemos utilizar medidas indirectas. Una métrica sencilla es el tiempo medio entre cambios (TMEC), el tiempo que lleva analizar el cambio requerido, diseñar una modificación apropiada, implementar el cambio, probarlo y distribuir el cambio a todos los usuarios.

Medidas de calidad Integridad Este atributo mide la habilidad de un sistema para resistir ataques contra su integridad (tanto accidentales como intencionados). Ataque puede producirse sobre cualquiera de los tres componentes del software: programas, datos y documentos. Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad. Amenaza es la probabilidad de que un ataque de un tipo determinado ocurra en un tiempo determinado. La seguridad es el probabilidad de que se pueda repeler el ataque de un determinado tipo. La integridad del sistema se puede definir como: Integridad = suma ( 1 - amenaza * (1 - seguridad)) Facilidad de uso La facilidad de uso intenta cuantificar la interfaz con el usuario y se puede medir en función de cuatro características: Habilidad intelectual y/o física requerida para aprender el sistema. Tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema. Aumento neto en productividad. Valoración subjetiva de la disposición de los usuarios hacia el sistema.

Integración de la métricas en la Ingeniería del Software La mayoría de los que desarrollan software no miden y, desgraciadamente, la mayoría tiene pocas ganas de comenzar a hacerlo. El intentar reunir medidas donde nadie las ha reunido anteriormente se encuentra frecuentemente con una cierta resistencia. Argumentos a favor de las métricas del software. Si no medimos, no hay forma de determinar si estamos mejorando. La medición proporciona beneficios a nivel estratégico, a nivel de proyecto y a nivel técnico. Mediante la obtención y la evaluación de medidas de calidad y de productividad, los directivos de gestión pueden establecer objetivos significativos para mejorar el proceso de ingeniería del software. El software es un objetivo comercial estratégico para muchas empresas. Los rigores del trabajo diario de un proyecto del software dejan poco tiempo para planteamientos estratégicos.

Integración de la métricas en la Ingeniería del Software Las siguientes preguntas se responderían si tuviésemos métricas de proyectos anteriores: ¿Qué requisitos del usuario son más susceptibles al cambio? ¿Qué módulos del sistemas son más propensos a error? ¿Cómo se debe planificar la prueba para cada módulo? ¿Cuántos errores puedo esperar cuando comience la prueba?

Establecimiento de una línea base Mediante el establecimiento de una línea base para las métricas, se pueden obtener beneficios a nivel estratégico , de proyecto y técnico. La línea base es el conjunto de datos recogidos de anteriores proyectos de software. Para que sea una ayuda efectiva en la planificación estratégica y/o en las estimaciones de coste y esfuerzo, los datos de la línea base tienen que poseer los siguientes atributos: Los datos deben ser razonablemente precisos. Los datos deben obtenerse de muchos proyectos. Las medidas tienen que ser consistentes (por ejemplo, las LDC tienen que ser interpretadas de igual forma para todos los proyectos de los que se hayan obtenido datos). Las aplicaciones deben ser similares a la que vaya a ser estimada.