MEDICIÓN DEL SOFTWARE 1
MEDICIÓN DEL SOFTWARE 1. Introducción 2. Conceptos básicos 3. Alcance de las métricas 4. Clasificación de las métricas Procesos Productos Recursos 5. Clasificación de los atributos 6. Medición de atributos internos del producto Longitud Funcionalidad Puntos de caso de uso Código OO Modelos conceptuales OO 7. Medición de atributos de los recursos 8. Resumen de las métricas 9. GQM 10. Caso práctico 2
1. Introducción: El informe CHAOS (1) 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 16% 27% 26% 28% 35% 53% 33% 46% 49% 46% 40% 31% 28% 23% 19% Éxito Problemas Cancelados Éxito: Proyectos terminados dentro del plazo y presupuesto. Problemas: Proyectos terminados pero sin cumplir plazos o presupuesto. Cancelados: Proyectos suspendidos durante el desarrollo. 3
1. Introducción: El informe CHAOS (2) 60% 50% 40% 30% 20% Cancelados Problemas Éxito 10% 0% CHAOS'94 CHAOS'96 CHAOS'98 CHAOS'00 CHAOS'06 Hay un porcentaje de proyectos de desarrollo muy alto que fracasan no por falta de presupuesto o tecnología sino por falta de gestión. 4
1. Introducción: El informe CHAOS (3) http://www.standishgroup.com/sample_research/pdfpages/extreme_chaos.pdf 5
2. Conceptos básicos Métrica Evaluación del grado en el cual un producto o proceso posee un atributo determinado (extensión, cantidad, dimensiones, capacidad o tamaño) (IEEE, 1993). Medición Proceso objetivo y empírico por el que se asignan números o símbolos a atributos de entidades del mundo real con objeto de describirlas (Fenton y Kitchenham, 1991) Métrica directa e indirecta Una métrica es directa si se puede medir directamente del atributo y su valor no depende de la medida de otros atributos (longitud del código fuente, duración del proceso de prueba, número de defectos...). Una métrica es indirecta si comprende la medición de varios atributos, es decir, si deriva de otros atributos (productividad, estabilidad de requisitos, densidad de defectos en un módulo, etc.) (Wohlin et al. 2000). Métrica objetiva y subjetiva Una métrica es objetiva si su valor no depende del observador y es subjetiva en caso contrario. 6
1. Conceptos básicos La medición contribuye a superar algunos problemas habituales en el desarrollo del software: Problema Requisitos incorrectos Toma de decisiones Falta de control Exceso de gasto Costes de mantenimiento Evaluación de nuevos métodos Medir ayuda a Desarrollar requisitos verificables expresados en términos medibles. Proporciona evidencia cuantificable para apoyar las decisiones. Hacer más visible el desarrollo e identificar problemas anticipadamente. Realizar predicciones de coste y plazo justificables. Recomendar determinadas estrategias de prueba e identificar los módulos problemáticos. Valorar los efectos en la productividad y la calidad. 7
2. Conceptos básicos La posibilidad de medir es el fundamento de las disciplinas científicas y de ingeniería. Sin poder medir es muy difícil evaluar y experimentar las técnicas y los métodos de ingeniería del software. No se puede controlar lo que no se puede medir y no se puede predecir lo que no se puede medir. Objetivos del proceso de medición: Gestión durante el proceso de Ingeniería del Software, más concretamente: Predicción: estimación de los atributos que tendrá una entidad que no existe aún (coste de un proyecto, esfuerzo necesario). Evaluación: comprobación del cumplimiento de ciertas características por una entidad que ya existe (calidad del diseño, fiabilidad del software, etc.). Experimentación en Ingeniería del Software. 8
2. Conceptos básicos FORMULACIÓN Definición de medidas y métricas COLECCIÓN Obtención de datos ANÁLISIS Cálculo de métricas INTERPRETACIÓN Evaluación de los resultados REALIMENTACIÓN Recomendaciones obtenidas Proceso de medición de Roche 9
3. Alcance de las métricas Las métricas del software abarcan muchas actividades y son múltiples las razones que justifican su uso : Estimación de coste y esfuerzo (o al menos reducción de estos) Modelos y medidas de productividad Recolección de datos Modelos y evaluación de la calidad (AENOR, ISO, etc.) Modelos de fiabilidad Están incluidos en la mayoría de los modelos de calidad. La especialización de los modelos de fiabilidad permite aumentar el entendimiento y control de los productos. Evaluación del rendimiento (Puede ser cualitativo) Aunque es otro aspecto de la calidad, la valoración del rendimiento incluye características observables como tiempos de respuesta y características internas como eficiencia de los algoritmos. Métricas estructurales y de complejidad Para realizar predicciones sobre atributos de calidad (fiabilidad, facilidad de mantenimiento,...) se pueden medir atributos estructurales sobre representaciones del software que están disponibles antes que el código. Gestión mediante métricas La realización de gráficos basados en diferentes medidas a lo largo del proyecto permite conocer el estado del mismo. Evaluación y comparación de métodos y herramientas Las investigaciones cuidadosas, con análisis y mediciones controladas sobre una herramienta o método permiten hacerlos más productivos para situaciones particulares. 10
3. Alcance de las métricas 1. En cuánto podría ser mejorada la productividad si no tuviese que gastar tiempo en mantenimiento? 2. Cuánto tiempo le costó el último año adaptar su presupuesto en trabajar con nuevas versiones de compiladores, bases de datos o sistemas operativos? 3. Cuáles de las aplicaciones que desarrolla su empresa demanda el mayor tiempo de soporte al usuario? 4. Cuánto tiempo se gasta realmente en testing? 5. Crée que sus desarrolladores dedican suficiente tiempo a actividades de diseño? 6. Su proceso de desarrollo ha madurado en los últimos años? 7. El esfuerzo dedicado a mejorar la calidad del software está reduciendo el tiempo que se dedica a corregir errores? 8. Con qué precisión es usted capaz de estimar proyectos futuros? 9. En cuántos proyectos han trabajado cada uno de sus desarrolladores en el último año? 10. Cuál es el número medio de horas por semana que sus desarrolladores dedican a un proyecto? Fuente: Karl E. Wiegers, Process Impact, www.processimpact.com 11
4. Clasificación de las métricas El primer paso de la medición es identificar los atributos o entidades a medir. Estos pueden ser de tres tipos: Productos: componentes, entregas o documentos resultantes de una actividad de proceso. Procesos: atributos de actividades relacionadas con el software. Recursos: entidades requeridas por una actividad de proceso Dentro de cada clase anterior se puede distinguir: Atributos internos: Son aquellos que pueden ser medidos examinando el proceso, producto o recurso mismo. Atributos externos: se miden con respecto a como el proceso, producto o recurso se relaciona con su entorno. 12
5. Clasificación de atributos Atributos internos del producto: Medidas de tamaño (longitud del código, funcionalidad...) Medidas de diseño Acoplamiento: grado de interdependencia entre módulos Cohesión: grado en el los componentes locales de un módulo colaboran para realizar una tarea concreta Modularidad... Medidas de complejidad (estructuras de datos, estructura lógica...)... Atributos externos, que dependen del comportamiento del producto en un entorno determinado: Portabilidad Fiabilidad Usabilidad Facilidad de mantenimiento Escalabilidad 13
5. Clasificación de atributos Generalmente, el interés de conocer el valor de un atributo interno es que pueda dar información sobre algún atributo externo de interés para el observador. influyen en Atributos internos del producto Atributos externos Ejemplo: el número de requisitos de una especificación de requisitos de sistema puede ayudarnos a predecir el esfuerzo asociado al proyecto. 14
6. Medición de atributos internos del producto Los atributos internos describen los productos de software de forma que dependen únicamente del producto mismo. El producto puede ser descrito en función de su tamaño. Se pueden definir un conjunto de atributos para medir el tamaño del software: Longitud: tamaño físico del producto. Funcionalidad: funciones que proporciona el producto al usuario. Complejidad (de tiempo o espacio): recursos necesarios (de tiempo o memoria de ordenador) para implementar una solución particular. Las propiedades estructurales del software son atributos internos relacionados con la calidad del producto. Los tipos de medidas estructurales son: Flujo de control: secuencia en que se ejecutan las instrucciones. Flujo de datos: seguimiento de cómo los datos se crean y se manejan por un programa. Estructura de los datos: organización de los datos independiente del programa. Los principales productos que resulta útil medir son la especificación, el diseño y el código. 15
6. Medición de atributos internos del producto: Longitud Código El numero de líneas de código (LOC) es la medida más usada para medir la longitud del código fuente. Se han realizado muchas propuestas para contarlas. La más extendida es la de HP que no contabiliza las líneas comentadas ni en blanco. La abreviatura que se usa para estas líneas es NCLOC o ELOC (effective lines of code). Es útil medir por separado las líneas comentadas (CLOC) para calcular esfuerzo, productividad, etc. La longitud total será: LOC = NCLOC + CLOC También puede se útil calcular la densidad de comentarios: CLOC/LOC Para propósitos tales como la prueba es importante conocer cuanto código ejecutable se produce, para ello se mide el número de sentencias ejecutables (ES), ignorando los comentarios, declaraciones de datos y cabeceras. Otra propuesta consiste en contabilizar únicamente el código entregado al cliente. Se cuenta el número de DSI (delivered source instruction) que incluye las declaraciones de datos, las cabeceras y las instrucciones fuente. 16
6. Medición de atributos internos del producto: funcionalidad Puntos de función (PF) Medida de la funcionalidad propuesta por Albrecht. Es una medida del producto y del proceso que se sigue para desarrollarlo. Está centrado en la funcionalidad o utilidad del producto. Los PF se obtienen utilizando una relación empírica basada en items del producto y valoraciones subjetivas de la complejidad del mismo. El paso previo al cálculo de los PF, es el cálculo de PFS (unadjusted function point count), puntos de función sin ajustar: Se determinan los siguientes elementos de alguna representación del software: Entradas externas: entradas de usuario que proporcionan datos a la aplicación. Salidas externas: Salidas que proporcionan información al usuario. Consultas externas: peticiones interactivas que requieren una respuesta. Ficheros externos: interfaces con otros sistemas legibles por la máquina. Ficheros internos: ficheros maestros lógicos del sistema. A cada elemento se le asigna un índice de complejidad entre tres: simple, media o complejo. A cada índice le corresponde un factor de ponderación. 17
6. Medición de atributos internos del producto: funcionalidad Factor de peso Item Simple Medio Complejo Entradas externas 3 4 6 Salidas externas 4 5 7 Consultas externas 3 4 6 Ficheros externos 7 10 15 Ficheros internos 5 7 10 Items y factores de peso para calcular los PFS PFS = 15 ((número de items de la clase i) peso i ) i=1 Para completar el cálculo de los PF es necesario conocer el factor de complejidad técnica (FCT) que engloba los 14 factores. F 1 Copias de seguridad y recuperación fiables Componentes del factor de complejidad técnica F 6 Entrada interactiva de datos F 11 Reusabilidad F 2 Comunicación de datos F 7 Facilidad operativa F 12 Facilidad de instalación F 3 Funciones distribuidas F 8 Actualización interactiva F 13 Múltiples sitios F 4 Rendimiento F 9 Interfaces complejas F 14 Facilidad de cambios F 5 Configuración muy cargada F 10 Procesamiento complejo 18
6. Medición de atributos internos del producto: funcionalidad Cada componente de la tabla anterior se sitúa en una escala entre 0 y 5 según su influencia: Ninguna influencia 0 Incidental 1 Moderado 2 Medio 3 Significativo 4 Esencial 5 La siguiente fórmula combina los 14 factores: FCT = 0.65 + 0.01 14 F i i=1 Los valores constantes de la ecuación y los factores de ponderación se obtienen empíricamente. Cálculo final de los puntos de función: PF= PFS* FCT La técnica de puntos de función presenta problemas debido a la subjetividad de la aplicación de los factores y a la inexactitud de las medidas. Puntos de función o líneas de código? Existen factores de conversión (Albrecht/Jones) que permiten relacionar el número medio de LOC requerido para construir un PF en diferentes lenguajes. 19
6. Medición de atributos internos del producto: funcionalidad Fuente: Pressman, 5ª edición, pág. 62 Lenguaje de Programación Ensamblador C COBOL FORTRAN Pascal C++ Ada95 Visual Basic SmallTalk SQL Java LOC/PF 320 128 106 106 90 64 53 32 22 12 58 http://irb.cs.uni-magdeburg.de/sw-eng/us/java/fp/ 20
6. Medición de atributos internos del producto: funcionalidad Ejemplo de puntos de función Una representación de un sencillo programa de revisión ortográfica. El sistema tiene una entrada (el nombre del archivo que ha de revisarse), tres salidas (el número total de palabras revisadas, el número total de errores y una lista de las palabras erróneamente escritas), una consulta (el usuario puede obtener interactivamente el número de palabras procesadas hasta el momento), un archivo externo (el documento a inspeccionar y un archivo interno (el diccionario). Para este sencillo programa, el número de elementos es 1+3+1+1+1=7. Entrada: 1. Nombre del documento a revisar Archivo externo: 1. Documento que se va a revisar Usuario Corrector ortográfico Consulta: 1. cuántas palabras llevamos procesadas? Archivo interno: Diccionario Salida: 1. Numero de palabras revisadas 2. Número total de faltas de ortografía 3. Lista de palabras con errores ortográficos 21
6. Medición de atributos internos del producto: funcionalidad Puntos objeto Utiliza una medida del tamaño que puede ser aplicada al comienzo del desarrollo. Para realizar el cálculo de los puntos objeto se realiza una medida inicial contando el número de pantallas, informes y componentes de 3GL de la aplicación. A cada objeto se le asigna un factor de peso según su grado de dificultad. Los pesos reflejan el esfuerzo relativo requerido para implementar un objeto de un determinado nivel. Tipo de objeto Simple Medio Difícil Pantalla 1 2 3 Informe 2 5 8 Componente 3GL - - 10 Tipos de objeto y factores de peso Puntos de característica Sistemas en tiempo real, control de procesos, empotrados, sistemas 22
6. Medición de atributos internos del producto: Puntos de casos de uso Puntos de caso de uso Los casos de uso son la base para estimar el esfuerzo (en técnicos hora) de un proyecto software tomando de partida la especificación de requisitos del proyecto en cuestión. La métrica punto de caso de uso, que se denota UCP, es: UCP= UUCP * TCF * EF UUCP representa los puntos de casos de uso no ajustados, que es una suma ponderada del número de actores y del número de casos de uso de la especificación. Peso de los actores: Tipo de actor Peso de los casos de uso: Peso Interfaz de programa 1 Interfaz interactiva 2 Interfaz gráfica 3 Número de pasos/número de clases de análisis Peso Menos de 4 pasos ó 5 clases de análisis 5 Entre 4 y 7 pasos ó entre 6 y 10 clases de 10 análisis Otro caso 15 23
6. Medición de atributos internos del producto: Puntos de casos de uso Puntos de caso de uso (continuación) TCF representa algunos aspectos no funcionales del sistema y se conoce como factor de complejidad técnica. Para calcular el valor de TCF se toma de la siguiente tabla y cada factor se multiplica por un valor entre 0 y 5 según la incidencia de dicho factor en el proyecto. 13 TCF= 0.6 + 0.01 W i * FI i i=1 : Descripción del factor técnico Peso de los casos de uso: Peso Sistema distribuido 2 Rendimiento 1 Eficiencia 1 Procesamiento interno complejo 1 Reusabilidad 1 Facilidad de instalación 0.5 Facilidad de uso 0.5 Portabilidad 2 Facilidad de cambio 1 Concurrencia 1 Seguridad (condiciones especiales) 1 Otorgue acceso directo a terceras personas 1 Facilidad de enseñarlo a los usuarios finales 1 24
6. Medición de atributos internos del producto: Puntos de casos de uso Puntos de caso de uso (continuación) EF representa el nivel de experiencia del personal técnico del proyecto y la estabilidad de los requisitos. Para calcular el valor de EF se aplica la siguiente ecuación: EF= 1.4 + (-0.03) 8 i=1 W i * FI i Descripción del factor de entorno (W i ) Peso Familiarizados con las metodologías a usar 1.5 Trabajadores a tiempo parcial -1 Capacidad de análisis 0.5 Experiencia en el dominio de la aplicación 0.5 Experiencia en OO 1 Motivación 1 Dificultades para programar -1 Requisitos estables 2 Varios estudios empíricos basados en proyectos reales han dado como resultado que el esfuerzo para desarrollar un Punto de caso de uso es aproximadamente de 18 técnico hora. Esto permite calcular el esfuerzo de desarrollo 25
6. Medición de atributos internos del producto: Código OO La mayoría de las métricas orientadas a objetos se basan en las características distintivas del software orientado a objetos respecto al software convencional: Localización: forma en que se concentra la información dentro de un programa Encapsulamiento: empaquetamiento de una colección de elementos. Ocultamiento de la información: supresión de los detalles operativos de un componente. Herencia: mecanismo que permite la propagación de responsabilidades de un objeto a otro. Abstracción: mecanismo que permite concentrarse en los detalles esenciales de un componente sin considerar los de nivel inferior. 26
6. Medición de atributos internos del producto: Código OO Código orientado a objeto: Número de métodos estáticos. Afferent Coupling: Número de clases fuera del paquete que dependen de clases dentro del paquete. Efferent Coupling: Número de clases dentro del paquete que dependen de clases fuera del paquete. Nested Block Depth: profundidad en bloques anidados. Lack of Cohesion in Methods (LCOM), Falta de cohesión en métodos: Si es cerca de 1 quiere decir que se nos aconseja que dividamos la clase en varias subclases. 27
6. Medición de atributos internos del producto: Modelos conceptuales OO Métricas orientadas a clases CK (Chidamber/Kemerer) Métodos ponderados por clase (MPC): recoge la noción de complejidad. Para una clase C con M 1, M 2,...,M n métodos con un peso de complejidad c 1, c 2,..., c n respectivamente, MPC = Profundidad del árbol de herencia (PAH): longitud del camino máximo entre un nodo y la raíz del árbol. Número de hijos (NH): es el número de descendientes inmediatos de una clase (nodo). Acoplamiento entre clases (AC): número de clases que se acoplan con una clase dada. Respuesta para una clase (RPC): es el número de métodos locales de una clase más el número de métodos llamados por dichos métodos locales. Métrica de falta de cohesión (MFC): número de métodos locales que no acceden a atributos comunes. c i 28
6. Medición de atributos internos del producto: Modelos conceptuales OO Métricas orientadas a clases CK (Chidamber/Kemerer) Ejemplo: Profundidad del árbol de herencia (PAH): longitud del camino máximo entre un nodo y la raíz del árbol. Animal Invertebrados Vertebrados PAH(dg)=3 Sin esqueleto Con esqueleto externo Sangre fría Sangre caliente 29
7. Medición de atributos de los recursos Los recursos incluyen cualquier entrada en la producción de software. Las medidas de recursos ayudan a controlar el proceso indicando cómo el proceso está usando y transformando las entradas en salidas. Los recursos internos que se pueden medir directamente son: Personal Materiales Herramientas Métodos... Los recursos externos pueden obtenerse a partir de los anteriores: Coste Productividad productividad = cantidad de salida / cantidad de entrada 31
8. Resumen de métricas ENTIDADES Productos Especificaciones, diseño, código... Procesos Realización de la especificación, del diseño, del código... Recursos Personal, equipos, hardware, software... Internos Tamaño, reusabilidad, modularidad, funcionalidad, acoplamiento, complejidad... Tiempo, esfuerzo, cambios en requisitos, fallos en la especificación Edad, precio, tamaño del equipo, velocidad, tamaño de memoria ATRIBUTOS Externos Comprensión, mantenibilidad, calidad, fiabilidad... Calidad, coste, estabilidad Productividad, experiencia, calidad, usabilidad, fiabilidad 33
9. GQM (Goal Question Metric) El enfoque GQM puede utilizarse para seleccionar e implementar métricas de una manera efectiva (http:www.gqm.nl). Se aplican varios pasos: Lista de los objetivos y agentes. Áreas de medición. Definición de términos. Para cada objetivo obtener las preguntas que deben contestarse para saber si se están cumpliendo los objetivos. Decidir qué medir para poder contestar las preguntas de forma adecuada. OBJETIVO: Evaluar la efectividad del estándar de codificación PREGUNTAS: Quien está usando el estándar? MEDIDAS INTERMEDIAS: MÉTRICAS Técnicos usando el estándar Total técnicos Cual es la productividad del codificador? Esfuerzo en codificación con y sin estándar Ejemplo de métricas derivadas con el método GQM Cual es la calidad del código? Cantidad de código Errores?...?...?... 34
9. GQM (Goal Question Metric) OBJETIVOS Mejorar la planificación del proyecto. Incrementar la contención de defectos. Incrementar la Fiabilidad. AREAS DE MEDICIÓN Defectos entregados y defectos entregados por tamaño.... DEFINICIÓN DE TÉRMINOS PROBLEMA SOFTWARE. ERROR, DEFECTO, FALLO, AVERÍA.. MÉTODOS GQM: Objetivo: mejorar la planificación del proyecto. Pregunta: Cuál es la precisión en la estimación del valor real del plazo del proyecto? Métrica: Precisión en la estimación del plazo (PEP) PEP=Duración real /Duración estimada 35
Referencias Binder, R., Testing Object-Oriented Systems, American Programmer, 7(4), 22-29, 1994. Clemons RK, Project Estimation with Use Case Points Disponible en http://www.stsc.hill.af.mil/crosstalk/2006/02/0602clemmons.pdf Chidamber, S.R. y Kemerer, C.F., A metrics suite for object-oriented design,ieee Trans. Software Engineering, 20(6), 476-493, 1994. Churcher, N.I. and Shepperd, M.J., Towards Conceptual Framework for Object-Oriented Metrics, ACM Software Engineering Notes, 20 (2), 67-76, 1995. Dolado, J.J. y Fernández, L. (coordinadores). Medición para la Gestión en la Ingeniería del Software. Ra-ma, 2000. Fenton, N.E. y Pfleeger, S.L., Software metrics. A rigorous & practical approach, 1997. Fenton, N.E. Y Kitchenham B., Validating Software Meaures, Journal of Software Testing, Verification and Reliability 1(2): 27-42, 1991 Genero M., Piattini M., Calero C. (coordinadores), Metrics for Software Conceptual Models, Imperial College Press, 2005. IEEE Software Engineering Standards,. Standard 610.12-1990, 1993. Lorenz, M. and Kidd, J., Object_oriented Software Metrics, Prentice Hall 1994. McConnell, S., Desarrollo y gestión de proyectos informáticos, Mc Graw Hill 1997. Putnam, Lawrence H and Myers W., Five Core Metrics, DH Publishing, 2003 Pressman, R.S., Ingeniería del Software. Un enfoque práctico, Mc Graw Hill, 2005. Wohlin C. Et al. Experimentation in Software Engineering: An Introduction. Kluwer Academic Publisher, 2000 36