MODULO III Ingeniería de Software INF - 163 42 METRICAS DE PROCESO Y PROYECTO 03/12/2012 Resumen preparado por Miguel Cotaña 1
La medición permite obtener una visión del proceso y el proyecto pues proporciona un mecanismo para lograr una evaluación objetiva La medición se aplica al proceso de software con la finalidad de mejorarlo de manera continua La medición se utiliza a lo largo de un proyecto de software como apoyo en la estimación, el control de calidad, la valoración de la productividad y el control del proyecto 2
Medición es una operación de asignar un valor a algo que es una medida Métrica es una interpretación de la medida Grado en que un sistema, componente posee un atributo dado Indicador provee una visión en cuanto al logro de objetivos 3
Cuando se puede medir y cuantificar aquello sobre lo que uno habla y expresarlo en números, se sabe algo acerca de eso; cuando no puede ser expresado en números el conocimiento es escaso e insatisfactorio Lord Kelvin 4
Clasificación Clasificación 1: Métricas de producto Métricas de proceso Clasificación 2: Métricas basadas en atributos internos del producto: Medidas de estructuración de un programa Métricas de complejidad Métricas de cobertura de pruebas Métricas de calidad del diseño Métricas basadas en atributos externos del producto: Métricas de portabilidad Métricas de defectos Métricas de usabilidad Métricas de mantenibilidad Métricas de fiabilidad 5
Métricas basadas en código fuente: Nº de líneas de código Nº de líneas de comentario Nº de instrucciones Densidad de documentación Métricas basadas en estructura de diseño: Relacionadas con el control intramodular Relacionadas con el acoplamiento entre clases Métricas para sistemas orientados a objetos: Acoplamiento Herencia Cohesión 6
Se aplica las métricas para valorar la calidad de los productos Proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de reglas Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales 7
Medición de los requisitos Los requisitos del Software son la base de las medidas de calidad La falta de concordancia con los requisitos es una falta de calidad Los productos de los requerimientos, pueden ser evaluados por el número de requerimientos De manera similar, se puede medir la cantidad de cambios introducidos a los requerimientos 8
Medidas para diagramas de clases Se debe asegurar la calidad de los diagramas de clases en las etapas iniciales del ciclo de vida para lograr sistema de mejor calidad Podemos Centrarnos en una de las características de la calidad más críticas, la mantenibilidad (ISO 9126)(atributo externo) Para evaluar la complejidad estructural (atributo interno) utilizamos métricas 9
la mantenibilidad se ve influenciada por tres subcaracterísticas: Comprensibilidad: Facilidad con la que el diagrama de clases puede ser entendido Analizabilidad: Facilidad que ofrece el diagrama de clases para descubrir sus deficiencias o errores Modificabilidad o Cambiabilidad: Facilidad que ofrece el diagrama de clases para realizar una modificación especificada, ya sea por un error, por un concepto no tenido en cuenta o por un cambio en los requisitos 10
Medidas de GENERO ET AL (2000) METRICA NC NA NM NAssoc NAgg NDep NGen NAggH NGenH MaxDIT MaxHAgg DEFINICION Número total de clases Número total de atributos Número total de métodos Número total de relaciones de asociación Número total de relaciones de agregación (cada par parte-todo en una relación de agregación) El número total de relaciones de dependencia Número total de relaciones de generalización (cada par padre-hijo en una relación de generalización) Número total de jerarquías de agregación Número total de jerarquías de generalización Es el camino más largo desde la clase hasta la raíz de la jerarquía Es el camino más largo desde la clase hasta las hojas 11
Medidas para diagramas de casos de uso En los diagramas de CU, sólo se muestran el nombre de los casos de uso, los actores y algunas relaciones Marchesi (1998), Saeki (2003) proponen: NCU (número de CU) NA (número de actores) NI, NE (número de relaciones de inclusión y extensión) 12
Factores de calidad de McCall Los factores que afectan la calidad se pueden categorizar en: Factores que se pueden medir directamente, como por ejemplo los defectos por punto de función Factores que se pueden medir sólo indirectamente, como por ejemplo la facilidad de uso o mantenimiento En todos los casos debe aparecer la medición Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad 13
Facilidad de mantenimiento Flexibilidad Facilidad de prueba Revisión del Producto Transición del producto Portabilidad Reusabilidad Interoperatividad Operación del producto Corrección Fiabilidad Usabilidad Integridad Eficiencia 14
15
Ejemplo: el factor de calidad Corrección tiene asociadas las métricas: Compleción (Completitud); Trazabilidad; Consistencia Para evaluar la compleción es necesario dar respuesta a la siguiente lista de comprobación: 16
1 No hay referencias ambiguas [R,D,I] 2 Todas las referencias a datos definidas son calculadas u obtenidas de una fuente externa [R,D,I] 3 Todas las funciones definidas son utilizadas [R,D,I] 4 Todas las referencias a funciones están definidas [R,D,I] 5 Se han definido todas las condiciones y procesamientos para cada punto de decisión [R,D,I] 6 Concuerdan todos los parámetros de llamada a funciones definidos y referenciados [D,I] 7 Todos los informes de problemas se han resuelto [R,D,I] 8 El diseño concuerda con los requisitos [D] 9 El código concuerda con el diseño [I] 17
Se contesta con un SI o NO, y luego se aplica la que da como resultado el grado o nivel de calidad: C= (# SI para R/6)+(# SI para D/8)+(# SI para I/8) 3 De esta forma, la medida para la compleción es un número entre 0 y 1 La medida para la corrección, por ejemplo, se calculará (x+y+z)/3 Donde: x es la medida para la compleción, y para la trazabilidad y z para la consistencia 18
Algunas métricas Facilidad de mantenimiento = 1-01 (número medio de días-hombre por corrección) Portabilidad = 1 - (esfuerzo para portar / esfuerzo para implementar) Flexibilidad = 1-005 (número medio de días-hombre por cambio) Fiabilidad = 1 - (número de errores/ número de líneas de código) 19
La fiabilidad emplea varias medidas, la primera de ellas es la probabilidad F de que aparezca un error en un tiempo determinado t, donde t > 0 La fiabilidad R es la probabilidad de que no ocurra un error en ese intervalo de tiempo: R(t) = 1 - F(t) esto supone que se estudia la fiabilidad a lo largo de un espacio continuo de tiempo 20
Pero, es más realista ajustarse al número de veces n que se ejecuta el programa: R(n) = 1 - dn /n donde dn es el número de fallo hallados en n ejecuciones Si f(t) es la función de densidad de probabilidad: f(t) = df(t) / dt y f(tt) es la probabilidad de que el software falle en el intervalo (t, t + d t) 21
La tasa de riesgo h(t) es la probabilidad de que el software falle en (t, t + d t) si no ha fallado antes: h(t) = f(t) / ( 1 - F(t) ) de donde podemos obtener una nueva expresión para la fiabilidad del software: h(t) = f(t) / ( 1 - F(t) )= - d( ln (1 - F(t) ) ) / dt = - d ln R(t) / dt 22
La fiabilidad R(t) de un componente en un determinado medio durante un periodo t se define como la probabilidad de que su tiempo para fallar excede a t: R(t) = - λ*t donde: R(t)=funcionalidad de un componente; λ = tasa constante de fallo t = intervalo de tiempo R T (t)=1-[1-r1(t)][1-r2(t)][1-rn(t)] 23
Es difícil desarrollar medidas directas de los factores de calidad señalados anteriormente, se definen un conjunto de métricas para desarrollar expresiones que utilicen los factores: Fq = c1 x m1 + c2 x m2 + +cn x mn Fq es factor de calidad cn son coeficientes de regresión mn son las métricas que afectan al factor calidad 24
Lamentablemente muchas de las métricas definidas por McCall solamente pueden medirse de manera subjetiva Las métricas se acomodan en una lista de comprobación que se emplea para puntuar atributos específicos del software El esquema de puntuación que se propone es una escala del 0 (bajo) al 10 (alto) 25
Factores de calidad de Boehm 26
Métricas en los dominios del proceso y el proyecto Las métricas del proceso se recopilan en el curso de todos los proyectos y durante largos periodos Su objetivo es proporcionar un conjunto de indicadores de proceso que conduzcan a la mejora de los procesos de software a largo plazo 27
Las métricas del proyecto permiten que un gestor de proyecto de software: 1) Valore el estado de un proyecto en curso; 2) Rastree los riesgos potenciales; 3) Descubra las áreas problema antes de que se vuelvan críticas ; 4) Ajuste el flujo de trabajo o las tareas; 5) Evalué la habilidad del equipo 28
Medición del software Se clasifican en 2 categorías: 1 Medidas indirectas del producto que influyen funcionalidad, calidad, complejidad, eficiencia, confiabilidad, facilidad de mantenimiento, etc 2 Medidas directas del proceso de software (costo, esfuerzo aplicados) y del producto (líneas de código, rapidez de ejecución y defectos reportados); 29
Ejemplo Supongamos una empresa de software que lleva a cabo un proyecto de desarrollo de un sistema X En un determinado momento el líder del proyecto necesita conocer el nivel de productividad de los programadores del proyecto en comparación con lo habitual en otros proyectos: 30
Las métricas a utilizar podrían ser: Directas: LCF (líneas de código fuente escritas) El método de medición es contar las líneas utilizando una herramienta CASE HPD (horas-programador diarias) El método de medición es que el líder del proyecto anota cada día las horas dedicadas por los programadores al proyecto CHP (coste por hora-programador, en unidades monetarias) El método de medición es consultar el plan del proyecto, donde se tuvo que indicar este valor, previa consulta a un responsable de personal 31
Indirectas: HPT (horas-programador totales) La función de cálculo es un sumatorio de las HPD de cada día: [métrica indirecta definida en base a sólo 1 métrica directa] LCFH (líneas de código fuente por hora de programador) La función de cálculo es una simple división: LCFH = LCF / HPT [métrica indirecta definida en base a 2 métricas directas] CTP (coste total actual del proyecto, en unidades monetarias) La función de cálculo establece que el CTP es el producto del coste unitario de cada hora por el total de horas empleadas: CTP = CHP * HPT [métrica indirecta definida en base a 2 métricas, una directa y otra indirecta] CLCF (coste por línea de código fuente) CLCF = LCF/CTP 32
Indicadores: PROD (productividad de los programadores) El modelo de análisis utiliza los valores de las métricas LCF, HPT, LCFH y CTP para establecer un valor cualitativo de la productividad de los programadores en este proyecto El modelo se basa en extraer de una base histórica de proyectos de la organización los valores medios de LCF, HPT, LCFH (LCFHvm) y CTP del subconjunto de proyectos similares (aquellos que tienen LCF entre el 80% y el 120% ) Los criterios de decisión establecidos son: LCFH/LCFHvm < 70% => PROD= muy baja 70% LCFH/LCFHvm < 90% => PROD= baja 90% LCFH/LCFHvm < 110% => PROD= normal 110% LCFH/LCFHvm < 130% => PROD= alta 130% LCFH/LCFHvm => PROD= muy alta 33
Métricas orientadas al tamaño Las métricas del software orientadas al tamaño preceden de la normalización de las medidas de calidad o productividad considerando el tamaño de software que se ha producido Si una organización de software mantiene registros simples es factible crear una tabla de medidas orientadas al tamaño 34
Proyecto LDC esfuerzo $ Pagdoc errores defectos personal Beta Alfa Gamma 12100 27200 20200 14 52 33 150 240 314 500 1480 1000 139 350 200 El desarrollo de métricas que se asimilen con métricas similares procedentes de otros proyectos requiere elegir líneas de código con valor de normalización 19 76 54 3 5 6 35
A partir de los datos rudimentarios de la tabla se desarrolla un conjunto de métricas simples orientadas al tamaño para cada proyecto La métricas orientadas al tamaño no se aceptan universalmente como la forma de medir el proceso del software 36
Métricas orientadas a la función Las métricas del software orientadas a la función emplean como un valor de normalización una medida de la funcionalidad que entrega la aplicación La métrica orientada a la función utilizada con mayor amplitud es el punto de función (PF) El cálculo del PF se basa en características del dominio de información y la complejidad del software 37
La métrica del punto de función (PF) se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evalua para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto de función: 38
Número de entradas del usuario; Número de salidas del usuario; Número de consultas del usuario; Número de archivos; Número de interfaces externas 39
Entradas: Pantallas o formularios a través de los cuales usuarios humanos de una aplicación u otros programas agregan nuevos datos o actualizan datos existentes Si una pantalla de entrada es muy grande para ser desplegada de una vez (asumiendo 80 columnas y 25 líneas) y requiere de una segunda pantalla, el conjunto cuenta como una (1) sola entrada Se deben considerar entradas que requieren procesamiento único 40
Salidas: Pantallas o informes que la aplicación produce para uso humano o para otros programas Las salidas que requieren procesamiento separado deben ser contabilizadas: en una aplicación de remuneraciones una función de salida que genere 100 cheques contaría como una sola salida Ej: pantallas, informes impresos, archivos en disco, sets de cheques, facturas impresas 41
Las consultas se dividen en dos partes: la porción de entrada y la porción de salida Ejemplos de consultas: consulta de un usuario sin actualizar un archivo, mensajes de ayuda, mensajes de selección Una consulta típica sería una relacionada con una reservación aérea Pantallas que le permiten a los usuarios interrogar una aplicación y solicitar asistencia o información, tal como pantallas de ayuda (HELP) 42
Archivos internos lógicos: Colección lógica de registro que la aplicación modifica o actualiza una tabla de una base de datos Archivos externos de interfaz: bases de datos compartidas, archivos lógicos direccionables desde o hacia otra aplicación Es un conjunto de datos definidos por el usuario, que están relacionados lógicamente y que sólo son usados para propósitos de referencia 43
CGS Factores de influencia FI1 comunicación de datos FI2 funciones distribuidas FI3 objetivos de performance FI4 configuración usada fuertemente FI5 tasa de transacciones FI6 entrada de datos en línea FI7 eficiencia del usuario final FI8 actualización en línea FI9 procesamiento complejo FI10 reusabilidad FI11 facilidad de instalación FI12 facilidad operacional FI13 sitios múltiples FI14 facilitamiento del cambio 44
Escala de evaluación 0 factor no presente o sin influencia 1 influencia insignificante 2 influencia moderada 3 influencia promedio 4 influencia significativa 5 influencia fuerte 45
Comunicación de datos: implica que datos y/o información de control son enviadas o recibidas La evaluación es un 0 para aplicaciones batch, y un 5 para aplicaciones en que predomina el teleproceso; Funciones distribuidas: analiza si una aplicación es monolítica y opera en un solo procesador o si es distribuida 0 para aplicaciones monolíticas y un 5 para aplicaciones que se ejecutan dinámicamente en varios procesadores; 46
Objetivos de performance: la evaluación sería un 0 si no hay establecido ningún criterio especial de performance, y un 5 si los usuarios insisten en objetivos de performance muy rigurosos que requieren un esfuerzo; Configuración usada fuertemente: la evaluación sería un 0 si la aplicación no tiene restricciones especiales de uso, y un 5 si el uso anticipado requiere especial esfuerzo para ser logrado; 47
Tasa de transacciones: la evaluación sería un 0 si el volumen de transacciones no es significativo, y un 5 si el volumen es lo suficientemente significativo como para producir stress en la aplicación y requerir un esfuerzo especial para alcanzar throughputs deseados; Entrada de datos en línea: la evaluación sería un 0 si menos del 15% de las transacciones son interactivas, y un 5 si más del 50% de las transacciones son interactivas 48
Eficiencia del usuario final: la evaluación sería un 0 si no hay usuarios finales o no hay requerimientos especiales para los usuarios finales, y un 5 si los requerimientos de eficiencia de usuarios finales son lo suficientemente rígidos como para requerir un esfuerzo; Actualización en línea: la evaluación sería 0 si no hay, y un 5 si las actualizaciones son obligatorias y especialmente difíciles; 49
Procesamiento complejo: la evaluación sería 0 si no hay, y un 5 en casos que requieren decisiones lógicas extensas, matemática compleja, procesamiento de excepciones; Reusabilidad: la evaluación sería un 0 si la funcionalidad se planifica, y un 5 si mucha de la funcionalidad y los artefactos del proyecto se pretende que sean usados ampliamente por otras aplicaciones; 50
Facilidad de instalación: la evaluación sería un 0 si este factor es insignificante, y un 5 si la instalación es importante y tan restrictiva que requiere un esfuerzo especial para cumplirla satisfactoriamente; Facilidad operacional: la evaluación sería un 0 si este factor es insignificante, y un 5 si la facilidad operacional es tan restrictiva que requiere un esfuerzo especial para alcanzarla; 51
Sitios múltiples: la evaluación sería un 0 si hay solo un sitio planificado de uso, y un 5 si el proyecto y sus artefactos se pretenden sean usados en muchos lugares; Facilitamiento del cambio: la evaluación sería un 0 si el cambio no ocurre, y un 5 si la aplicación se desarrolla específicamente para permitir a los usuarios finales el hacer cambios rápidos para controlar datos o tablas que ellos mantienen con la ayuda de la aplicación 52
La cuenta total debe ajustarse utilizando la siguiente ecuación: PF = c-total x (0,65 + 0,01 x Fi) Donde c-total es la suma de todas las entradas PF obtenidas y Fi (i=1 a 14) son los "valores de ajuste de complejidad" 53
Se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 56 Factor de ponderación Parámetro de medición Cuenta Simple Media Compl Número de entradas del usuario 3 X 3 4 6 = 9 Número de salidas del usuario 2 X 4 5 7 = 8 Número de consultas del usuario 2 X 3 4 6 = 6 Número de archivos 1 X 7 10 15 = 7 Número de interfaces externas 4 X 5 7 10 = 20 Cuenta total 50 Cálculo de puntos de función 54