Metricas Sw-2.pdf

METRICAS DEL SOFTWARE

MSc. I.S Judith del Pilar Rodríguez Tenjo

Medida

C O N C E P T O S C L A V E S

Directa Indirecta

Permite resolver problemas     

Características de un proceso de medición Medición

Formulación Colección Análisis Interpretación Realimentación

Atributos internos Atributos externos Valorar

Calidad y fiabilidad

Estimar

Tiempo y esfuerzo

Actividades

Métrica Diseño

     

    

Estimación del costo y el esfuerzo Acumulación de datos Medición de la productividad Elaboración de modelos de seguridad Valoración de capacidades de madurez

Definiciones claras Definir el modelo Establecer criterio de conteo Decidir que es bueno Reporte de la métrica Clasificaciones adicionales   

Características  

Simple y fácil de calcular Empírica e intuitiva Consistente en el empleo de unidades y tamaño. Independiente del lenguaje de programación. Un mecanismo para realimentación de calidad.

la

MEDIDAS

Medición y Métricas Medición es el acto de determinar una medida

Una medida proporciona una indicación cuantitativa de la extensión, la cantidad, la dimensión, la capacidad o el tamaño de algún atributo del producto o proceso.

Métrica, es la medida cuantitativa del grado de en que un sistema, componente o proceso posee un atributo determinado.

Un indicador es una métrica o una combinación de métricas que proporciona conocimiento acerca del proceso de software, un proyecto de software o el propio producto

El proceso de medición- actividades Formulación

Retroalimentación

Colección

Actividades de la medición

Interpretación

Análisis

Formulación: Obtención de medidas y métricas del software apropiadas para la presentación del software en cuestión. 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.

El proceso de medición

Métricas del modelo del análisis En esta fase es deseable que las métricas técnicas proporcionen una visión interna a la calidad del modelo de análisis.

Estas métricas examinan el modelo de análisis con la intención de predecir el “tamaño” del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionadas.

Otras Métricas : Métrica Bang  Modelo de Análisis Métrica de Especificación

• La métrica de punto de función PF se usa para medir la funcionalidad que entrega un sistema , empleando datos históricos el PF se usa para estimar el costo o el esfuerzo requerido para diseñar codificar y probar el software Predecir el numero de errores que se encontraran durante la prueba Pronosticar el numero de METRICAS BASADAS componentes, de líneas de código proyectadas o ambas en el sistema implementado. EN LA FUNCION

• Se derivan al normalizar las medidas de calidad y/o productividad para considerar el tamaño que se produjo. • No se aceptan universalmente como la mejor forma de medir el proceso de Métricas orientadas software. al tamaño

• BANG: Se aplica para desarrollar una indicación del tamaño del software a implementar como consecuencia del modelo de análisis. • ESPECIFICACION: Davis y colegas proponen una lista de características que pueden METRICAS BANG Y emplearse para valorar la calidad del modelo de análisis y la correspondiente Métricas de cakidad especificación de requisitos. de ka especificación

METRICAS ?

¿Qué son las métricas? Es la medición es esencial para cualquier disciplina de ingeniería y la ingeniería de software no es una excepción.

Las métricas de software se refieren aun amplio rango de medidas para el software dentro del contexto de la planificación del proyecto de software, las métricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a la estimación. Existen métricas que podemos utilizar para evaluar lo que estamos haciendo en ingeniería de software.

Why?

Una métrica es una medida efectuada sobre algún aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparación con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias. Con esta definición, la definición y aplicación de una métrica no es un objetivo en sí mismo sino un medio para controlar el desarrollo de un sistema de software.

¿Qué son las métricas? 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 estas técnicas mejorará el proceso y sus productos" .

Figura . Concepto de 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é asegurarnos de que las métricas cumplen 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, porque no se entiendan 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.

Fuente: CHOQUE, Aspiazu. Ingeniería del software, principios y conceptos. México: Mc Graw Hill, 1994. p.123.

Who ?

Producto

• Las métricas sobre el producto están orientadas a estimar las características del mismo antes de su desarrollo. • Estas estimaciones se basan en el conocimiento que los desarrolladores adquieren a partir de datos obtenidos de proyectos anteriores. • A) Tamaño estimado del código B) Complejidad estimada C) Robustez

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.

Proyecto

• Engloba todos los recursos, actividades y artefactos, que se organizan para lograr un producto de software de calidad, 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.

Métricas del Proyecto

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).

Métricas del Proyecto El gestor 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.

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.

Métricas proceso 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 coste y los Para mejorar un proceso se deben medir los atributos del mismo, desarrollar métricas de defectos encontrados. acuerdo a estos atributos y utilizarlas para Las métricas permiten tener una visión proporcionar indicadores que conduzcan la profunda del proceso de software que mejora del proceso. ayudará a tomar decisiones más fundamentadas, ayudan a analizar el Los errores detectados antes de la entrega trabajo desarrollado, conocer si se ha del software, la productividad, recursos y mejorado o no con respecto a proyectos tiempo consumido y ajuste con la anteriores, ayudan a detectar áreas planificación son algunos de los resultados con problemas para poder remediarlos a que pueden medirse en el proceso, así como las tareas específicas de la ingeniería del tiempo y a realizar mejores estimaciones. software.

Actualmente existen muchas 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 posti- mplantación. •Medición de las pruebas (errores, cubrimiento, resultado en número de defectos y número de éxito). •Medición de la transformación o evolución del producto

¿Por qué el proceso? existen varios factores que determinan la calidad del software y la eficiencia de la organización, entre ellos están la complejidad del producto, las tecnologías y las personas, así como algunas condiciones de entorno que también tienen su impacto, estas pueden ser condiciones de gestión (Ej.: plazo de entrega, regla de empresa), entornos de desarrollo y características del cliente, 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.

Métricas del Producto 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. En los artefactos del producto se mide, entre otras cosas, el tamaño, la calidad (teniendo en cuenta los defectos, la complejidad, la primitividad, entre otros), la totalidad, rastreabilidad, volatilidad, esfuerzo.

METRICAS- SOFTWARE Proceso

Métricas del Software

Producto



Tiempo y desarrollo.

 

Reusabilidad Productividad



Tamaño.

costo



Estructura lógica  Estructura de datos  Puntos de función ............

Fuente: EJIOGU, L. Software engineering with formal mectrics. Brasilia: Pearson, 1996.

de

Otras clasificaciones de las métricas Uno puede distinguir el objetivo de las propiedades subjetivas (la métrica).

Generalmente hablando, el indicador de la métrica siempre debe producir los valores idénticos para una métrica dada.

Incluso para la métrica subjetiva, son las medidas del proceso de software, como el tiempo de desarrollo global, el tipo de metodología usado ó el nivel de experiencia del personal de la programación. Los observadores calificados pueden medir los diferentes valores dados para una métrica, desde que su juicio subjetivo este involucrado llegando al valor moderado.

Volviendo métricas del Producto Métricas orientadas al tamaño. Provienen de la normalización de las medidas de calidad y/o productividad considerando el tamaño del software que se haya producido. Varias métricas intentan cuantificar el software por el tamaño. La métrica que usa más esto ampliamente es LOC; padece la deficiencia obvia que su valor no puede medirse hasta después que el proceso codificación se haya completado. Los puntos función del sistema y el Bang tienen la ventaja de ser predecibles en la fase del plan en el proceso de desarrollo y, se puede decir que posiblemente antes. Algunas métricas definidas por Halstead también usadas miden el tamaño del software (longitud y volumen del programa) (Véase la

Figura ).

Líneas de código

Métricas del producto según el tamaño

LOC KLOC DSI NCSS NSLOC

Punto de función C. Bang

Volumen del programa

Métricas de halstead

Longitud del programa Vocabulario del programa Dificultad del programa

VENTAJAS DE LAS MÉTRICAS

 

Son fáciles de calcular  Muchos modelos de  estimación de software usan LOC o KLOC como datos de  entrada.

DESVENTAJAS DE LAS MÉTRICAS

Son dependientes del lenguaje de programación. Perjudica a los programas cortos pero bien diseñados. Su uso en estimación es difícil porque hay que estimar las LOC a producirse mucho antes de que se complete el análisis y el diseño.

Fuente: FENTON, Norman. Software mectrics. London: Chapman & Hall, 1991. p.63

Líneas de código (LOC). Las métricas de las líneas de código (LOC), posiblemente son las más altamente usadas para hallar el tamaño del programa. involucran tratamiento de líneas pálidas y líneas del comentario, declaraciones no ejecutables, las declaraciones múltiples línea, y líneas múltiples por declaración, así como la pregunta de cómo contar las líneas de código rehusadas. La definición más común de LOC parece contar cualquier línea que no sea un espacio en blanco o línea de comentario, sin tener en cuenta el número de declaraciones por línea.

Definiciones importantes LOC LOC. Líneas de código es la más habitual y antigua KLOC. Miles de líneas de código. Es la unidad de medida que adoptan la mayoría de modelos clásicos de estimación de costos, en la calificación de un proyecto informático. DSI. Instrucciones de código fuente realmente entregados, y su múltiplo KDSI, que surgieron para que se tuviera en cuenta que, en los nuevos entornos de desarrollo y construcción de software NCSS. Líneas de código fuente sin tener en cuenta los comentarios, y su múltiplo KNCSS. Por el hecho de considerar que en un buen proceso de construcción los programas incluyen líneas de comentario o que una línea de tratamiento se puede escribir en diferentes líneas de código para aumentar la legibilidad y mejorar la mantenibilidad del software. NSLOC. Nuevas líneas de código fuente, tal como se realiza en el modelo COCOMO 2 para que se tenga en cuenta que sólo deben contarse las líneas de código nuevas sin contar las que incorpore automáticamente el entorno de programación.

Punto de función. Sugiere un acercamiento a la medida de productividad. Se obtienen utilizando una relación empírica basada en medidas cuantitativas del dominio de información de software y valorizaciones subjetivas de la complejidad del software.

Esto quiere decir que la estimación se refiere a los resultados que se obtienen de un software y no cómo se producen internamente estos resultados.

Esta técnica aporta una medida estándar del tamaño de los sistemas de información, y sirve de base para la estimación del esfuerzo requerido para el desarrollo de los proyectos.

La medida de los SI mediante los puntos de función proporciona una estimación del tamaño del software independiente de la tecnología utilizada en su desarrollo y dependiente únicamente de la funcionalidad que el sistema proporciona al usuario.

Los Puntos Funcionales pueden ser entendidos y evaluados por usuarios que no son técnicos

Estas medidas aíslan el tamaño intrínseco del sistema de los factores del medio, facilitando el estudio de factores que influyen en la producción.

Las razones de Albrecht, para proponer los Puntos Funcionales como medidas de tamaño de un sistema tomadas de Pressman ’98,

Estas medidas pueden determinarse al inicio del ciclo de desarrollo, lo que permite utilizar los Puntos Funcionales en la estimación de procesos.

Estas medidas están basadas; en las observaciones de los usuarios externos del sistema, y es tecnología independiente.

Métricas de complejidad del proceso

Métrica de flujo de información Métrica ciclómatica de complejidad

Que paso con …. Métricas de estructura de datos

cantidad de datos Variables vivas

MÉTRICAS DEL PROCESO

Métricas de estructura lógica o de control

Métricas del esfuerzo de desarrollo PROCESO

M Métrica de É spans T R Número de I decisiones C A S Métrica de flujo de D información Métrica de E costo L

Métricas de complejidad del proceso Métrica ciclomática de complejidad. Esta medida se deriva del grafo de flujo de control de un programa y mide el número de caminos independientes a través de un programa. Lo que está relacionado con la facilidad para probar y mantener el código. Una aproximación al valor del número ciclomático se obtiene de la siguiente expresión:

El número de complejidad ciclomática puede asimilarse al número de líneas que constituirían el esqueleto de un diagrama cuyo flujo se ha simplificado al máximo.

diagrama más simple, que es aquel que posee un sólo camino, presenta un ,un posible límite de complejidad estaría en torno a , más allá de esta cifra, las tareas de prueba y mantenimiento resultan muy complicadas. Si t representa el número de predicados, se puede demostrar que:

Donde e es el número de líneas del diagrama de flujo, n es el número de nodos, y p el total de elementos interconectados. Otra aproximación sugiere que el número de elementos interconectados es siempre dos (inicio y final), por lo que:

V (G)  e  n  2 p |

e  n  t 1

V (G)  e  n  2  t  1

Métricas de complejidad del proceso Y de aquí: = Dado que t y DE son prácticamente la misma cosa:

V (Gprog) 

m

 DEi  m

i 1

V (G)  DE  1

Por otra parte, también se puede demostrar que la complejidad ciclomática de un programa formado por varios módulos, es igual a la suma de las distintas complejidades. Si m es el número de módulos: V (Gprog) 

m

 V (Gi)

i 1

m

 ni  2m

La entropía es otra medida relacionada con la complejidad y el análisis de diagramas de flujo. La expresión general es: n 1 Z n   Log 2( piX  Qj ); x  2 i 1

i 1

Donde Qi es la probabilidad de que el elemento de decisión iésimo (símbolo IFTHEN) esté en serie con el anterior. Por su parte pi es igual a 1 menos la cantidad anterior. Zn está relacionada con MIN, el número de regiones delimitadas por un diagrama de flujo. En una sola línea de flujo MIN vale 1, con un bucle o una decisión es 2, con varias decisiones anidadas su cálculo se complica y la entropía da una expresión más exacta que el cálculo manual.

La entropía ha querido ser la métrica de unión entre complejidad y actualmente varias herramientas de medida del software la emplean para valorar la complejidad frente a métricas más clásicas como el número de complejidad ciclomática. En la cuadro10 se pueden apreciar las dificultades de esta métrica.

DIFICULTADES DE LAS MÉTRICAS CICLOMÁTICAS La métrica ha sido asociada con la tasa de errores en módulos, sin embargo no ha sido demostrado que provee mejor información que otros métodos.

Hay dificultades prácticas cuando se trata de el grafo de algunos programas y que es a menudo el grafo de un programa equivalente se obtiene más rápido que el del original. Esto hace pensar sobre que es lo que realmente se esta calculando.

La métrica resulta muy superficial tratando ciertos tipos de problemas, por ejemplo se obtiene el mismo valor en con tres bucles en secuencia que con tres bucles anidados. Un problema fundamental con el uso de la métrica como medida de la testeabilidad del programa es que se basa exclusivamente en el flujo de control y obvia el flujo de datos. Hay muchos programas que pueden ser escritos el uso de estructuras de control, mediante tablas y arrays u otras prácticas de programación

orientada a datos, por lo tanto el valor de la métrica puede estar muy influido por el estilo del programador.

Métricas de estructura de datos.

Todo software se crea fundamentalmente para procesar datos. Datos que entran son procesados y salen. Por lo tanto es importante dar una breve descripción de las de métricas para estos datos del sistema. Cantidad de datos. Una variable es un string de caracteres alfanuméricos que es definido por un programador y que es usado para representar algún valor durante compilación o ejecución. La cantidad de variables se conoce como VARS, y puede ser obtenida mediante una lista de referencias cruzadas, excluyendo variables definidas pero nunca usadas. ¿Cómo se relaciona VARS con los operando definidos anteriormente?

N 2  VARS  cons tan tes

únicas  labels

Esta métrica sólo refleja el número de variables únicas, sin indicar su grado de uso. Las métricas siguientes cubren ese aspecto.

Métricas de estructura de datos. Variables vivas. Una variable está viva desde la primera a la última referencia dentro de un procedimiento, por lo tanto, el número promedio de variables vivas (lv promedio) es la suma de la contabilización de variables vivas dividido el número de sentencias ejecutables en el procedimiento.

Métricas de estructura lógica o de control Métricas de estructura lógica o de control. La estructura lógica de un programa es el mecanismo que le permite realizar las distintas funciones para las que fue construido. La estructura lógica del programa representa los algoritmos empleados en su diseño y procesa los datos (la expresión Algoritmos + Estructuras de Datos = Programas WIRT76 es una estupenda definición de programa).

Spans (separación o amplitudes) de variables. La métrica spans de variables (SP) captura la frecuencia con la cual una variable es usada dentro de un programa o procedimiento. Una variable referenciada “n” veces tiene “n-1” spans.

Métricas de esfuerzo de desarrollo Métricas de esfuerzo de desarrollo. El esfuerzo requerido para construir un sistema puede ser medido con muchas unidades. Desde las discriminaciones mentales de Halstead, hasta el número real de horas y minutos que invierte un programador, la variedad es enorme, sin embargo hay una medida que destaca por su universalidad: la persona- mes o meses -hombre. Por otra parte, aunque el esfuerzo es muy importante, en realidad la más importante métrica del esfuerzo es el costo. La importancia de la medida del esfuerzo y coste responde más a necesidades de tipo administrativo y de gestión que estrictamente técnicas. Pero por ello no deben menospreciarse: el aspecto económico del software, que es el que subyace a la gestión, determina la viabilidad de los proyectos. El conocimiento del esfuerzo invertido ayuda a valorar la productividad y a preparar las medidas de corrección oportunas para mejorar el trabajo del equipo y, estimar las necesidades de futuros proyectos.

Where ? Proceso de desarrollo METRICAS PARA EL MODELO DE ANALISIS

MÉTRICAS PARA EL CÓDIGO FUENTE

Funcionalidad entregada Tamaño del sistema Calidad de la especificación

Métricas de Halstead Métricas de complejidad Métricas de longitud

METRICAS PARA EL MODELO DE DISEÑO

MÉTRICAS PARA PRUEBAS

Métricas arquitectónicas Métricas a nivel de componentes Métricas del diseño de la interfaz Métricas especializadas en diseño orientado a objetos

Métricas de cobertura de instrucciones y ramas Métricas relacionadas con los defectos Efectividad de la prueba Métricas en el proceso

Métricas y Calidad Métricas de calidad. Son todas las métricas de software que definen de una u otra forma la calidad del software; en la figura, se observa tales métricas como exactitud, estructuración o modularidad, pruebas, mantenimiento, reusabilidad, cohesión del módulo, acoplamiento del módulo, etc. Estas son los puntos críticos en el diseño, codificación, pruebas y mantenimiento. Métricas de mantenibilidad. Métricas de Testeabilidad. Métrica de flexibilidad.

Métrica de corrección.

Medición de remoción de defectos de software.

Métricas de defectos.

Medición de la eficacia de la remoción de defectos.

MÉTRICAS DE CALIDAD

Métricas de facilidad de uso. Métricas integridad. Métricas de facilidad de mantenimiento.

Defectos informados por los clientes Medición de la eficacia de la eliminación de defectos. El índice de mantenibilidad (IM).