Metricas de Bang

Métricas para el presupuesto Modelos y componentes primitivas Métricas de atributos internos Métricas de atributos externos


Métricas del software Calidad en el Desarrollo Desarrollo de Software Métricas del software You can’t control what you can’t measure can’t measure

Pablo R. Fillottrani

Tom DeMarco

Depto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur

Segundo Cuatrimestre 2007


Calidad en el Desarrollo de Software


Métricas del software - resumen

1

Métricas para el presupuesto

2

Modelos y componentes primitivas

3

Métricas de atributos internos

4

Métricas de atributos externos




Métricas para el presupuesto

objetivo: maximizar la cantidad de funciones entregables por objetivo: unidad de costo, considerando el costo total (todo el tiempo de vida) del sistema costo total del sistema: sistema: costo de desarrollo + costo de producción + costo de mantenimiento



Pasos a seguir

Modelización del problema

pasos a seguir: 1

2

3

4

5

formular un sólo indicador de medida de éxito vs el objetivo. objetivo. BPB: Bang per Buck (impacto por peso) coleccionar datos en una muestra de proyectos para establecer establecer estándares de performance de BPB buscar y evaluar predictores para aquellas partes de medida del BPB que influyen a futuro motivar al personal para mejorar el BPB. El personal debe estar informado de cómo se calcula el BPB publicar el BPB proyectado durante el proyecto, y el real luego de 6 meses de la implementación


un modelo consiste de una partición, junto con un registro de las interfaces entre las piezas de la partición se necesitan tres perspectivas para especificar la mayoría de los sistemas: modelo funcional: funcional: visión particionada de lo que hace el sistema modelo de datos retenidos: retenidos : visión particionada de lo que el sistema recuerda modelo de comportamiento: comportamiento : visión de los diferentes estados de comportamiento que caracterizan al sistema



Métricas de especificación la confección de un modelo formal provee tres beneficios: el modelo de especificación es público. Puede ser corregido y refinado por miembros del proyecto o usuario el modelo de especificación tiene características medibles que pueden ser relacionadas con performance observada el modelo de especificación es terminado en forma temprana durante el proyecto, provee oportunidad para corregir las estimaciones

el modelo de especificación describe los requerimientos en sí mismo, no la forma de satisfacerlos. un análisis cuantitativo del modelo provee una medida de las funciones




Métricas provenientes de primitivas Corrección de indicadores Cálculo del bang

Componentes primitivas de un modelo componente primitiva: primitiva: no se descompone en componentes subordinadas dependiendo de lo que se particione, se obtienen seis clases de primitivas: Elemento DFD DD diag. objetos diag. objetos diag diag.. esta estado doss diag diag.. esta estado doss

Par ticiona requer requerimi imient entos os del sistem sistemaa datos del sistema datos retenidos datos retenidos cara caract cter erís ístitica cass de cont contro roll cara caract cter erís ístitica cass de cont contro roll

Produce primitivas primit primitiva ivass funcio funcional nales es datos elementales objetos relaciones esta estado doss tran transi sici cion ones es



Métricas a partir de las primitivas

analizar las primitivas provee métricas básicas para medir el Bang: PF : número de primitivas funcionales automáticas PFM : número de primitivas funcionales manuales modificables DE : número de datos elementales dentro del sistema automático DEI : número de datos elementales de input DEO : número de datos elementales de output DER : número de datos elementales retenidos




Métricas a partir de las primitivas

métricas básicas para medir el Bang (cont.): OB : número de objetos retenidos RE : número de relaciones en el modelo de datos retenido ST : número de estados en el modelo de comportamiento TR : número de transiciones en el modelo de comportamiento TC i : número de data tokens en la primitiva i RE i : número de relaciones que involucran al objeto i



Formulación de una teoría de costos bang tentativo bang = PF ∗ (FactorDePesoParaPF )+ DE ∗ (FactorDePesoParaDE )+ . . . para caracterizar el bang se elige uno de los indicadores como el principal y se usan los otros para modificarlo en la mayoría de los sistemas administrativos PF es el principal indicador hay sistemas altamente orientados a funciones y otros a datos, dependiendo de esto es el indicador que se deberá considerar como principal






Indicador principal

se pueden analizar dos razones en función de PF (primitivas funcionales) y RE (relaciones entre objetos): RE /PF < 0,7 sistema orientado a funciones RE /PF > 1,5 sistema orientado a datos

la razón DEO /PF es una medida de cuánto el sistema está dedicado a cálculos o a administración de datos



Clasificación de proyectos



Particiones uniformes

para determinar el criterio de hasta donde se debe particionar se puede usar TC avg = ∑ TC i /PF i

regla de partición uniforme: dejar una componente como primitiva sólo si no es posible una partición o si la nueva partición no reduce el TC avg





Corrección de indicadores I

las primitivas se pueden clasificar de acuerdo a su función en: separación: dividen los datos de input merge: combinan los datos de input dirección de datos: dirigen datos de acuerdo a una variable de control actualización simple: actualiza uno o mas datos en almacenamientos administración de almacenamientos: analiza datos almacenados y actúa basado en el estado de los datos





Corrección de indicadores II

clasificación de primitivas (cont.) edición: evalúa nuevos datos en frontera hombre-máquina verificación: chequea e informa inconsistencias manipulación de textos: administra textos sincronización: decide cuándo actuar o decide por otras generación de output: formatea nuevos flujos de datos (no tabulares) display: construye outputs tabulares (2 dimensiones) aritméticas: realiza cálculos inicialización: setea valores para datos almacenados



Corrección de indicadores III

computación: cálculos matemáticos complejos administración de dispositivos: controla dispositivos

los factores dependen del contexto: tipos de sistemas herramientas, lenguajes de programación

en los sistemas orientados a datos el peso depende de los RE i de los objetos existen factores de corrección en función de los RE i



Cálculo del bang

clasificación de primitivas (cont.)





Cálculo del bang funcional

el bang es un indicador cuantitativo de las funciones útiles netas desde el punto de vista del usuario. Independiente de la implementacion en sistemas híbridos se aconseja manejar dos bangs , el funcional y el de datos. No se puede generalizar una fórmula que los relacione objetivos de calcular el bang : se usa como un predictor fuerte y anticipado del esfuerzo se usa para calcular eficiencia productiva: BPB

se deben usar otras métricas para otras actividades, como por ejemplo conversión de la base de datos, etc Pablo R. Fillottrani




Cálculo del bang orientado a datos

bang ::= 0 para cada primitiva funcional f[i] del modelo TC[i] ::= sumatoria de data token de f[i]

bang ::= 0 para cada objeto del modelo de datos

PFC[i] ::= corrección(TC[i]

calcular RE[i]

clasificar f[i] buscar PesoCorr[i] en tabla de corrección y de acuerdo al tipo de primitiva bang ::= bang + PFC[i] * PesoCorr[i]

OBC[i] ::= corrección(RE[i]) bang ::= bang + OBC[i]


Longitud Funcionalidad Complejidad Estructuras Métricas orientadas a objetos

Tamaño del software



Medición del tamaño

el tamaño del software puede ser descripto con tres atributos: en software, el tamaño no es lo que importa ya que en general no considera

longitud: mide tamaño físico del producto funcionalidad: mide las funciones provistas por el producto complejidad: puede ser interpretada de distintas maneras

esfuerzo: no tiene en cuenta redundancia y complejidad productividad: no consideran funcionalidad costo: no contabiliza reuso



del problema a resolver del algoritmo utilizado, eficiencia del software estructural: mide la estructura del SW implementada cognitiva: esfuerzo requerido para entender el SW




Consideraciones

hay consenso en medir longitud de programas, pero no de especificaciones existen trabajos para medir funcionalidad de especificaciones existen pocos avances en medición de complejidad




Productos

los tres productos mas importantes cuyo tamaño sería importante medir son: especificaciones diseño código

la medida mas comúnmente usada son las líneas de código: LOC se debe tener en cuenta: líneas en blanco, líneas de comentarios, declaración de datos y líneas que contienen varias instrucciones



Líneas de código



Líneas de código

Conte, Dunsmore & Shen: cualquier línea de texto de programa que no es comentario o línea en blanco, independientemente del número de sentencias o fragmentos de sentencias en la línea Hewlett-Packard : una sentencia de código fuente no comentada; cualquier sentencia excepto comentarios o líneas en blanco NCLOC - CLOC: non commented line of code - commented line of code ELOC: effective line of code longitud total LOC = NCLOC + CLOC





Líneas de código

en programación visual, entornos de ventanas, orientación a objetos lenguajes de cuarta generación, cambian las nociones de tamaño surgen dos nuevos objetivos de medición: ¿cómo se tienen en cuenta objetos no textuales? ¿cómo medimos componentes construidas externamente?

Pfleeger: contar objetos y métodos conduce a estimaciones mas precisas

es posible distinguir entre la cantidad de código entregado (DSI Delivered Source instructions) y la cantidad de código desarrollado formula de Halstead: volumen = longitud ∗ log 2 (vocabulario ) otro enfoque es medir longitud de acuerdo a: número de bytes de almacenamiento requerido para el texto del programa número de caracteres (CHAR ) en el texto del programa





Longitud de especificaciones las especificaciones y diseños consisten de textos y diagramas se deben medir diferentes objetos atómicos los objetos atómicos para DFD: procesos, entidades externas, flujos de datos, almacenamientos. las entidades atómicas para especificaciones algebraicas son clases, funciones, operaciones y axiomas intuitivamente: se predice la longitud para tratar de relacionar la longitud de productos de etapas posteriores con la longitud de productos ya construidos



Longitud de especificaciones



Reuso

razón de expansión α : tamaño de diseño / tamaño de código LOC = a ∗ ∑i = 1n S i , donde S i es el tamaño del módulo i Walston & Felix:

el reuso mejora la productividad y la calidad. Es difícil de definir formalmente grados de reuso publicado por NASA/Goddard’s Software Engineering Lab reuso verbatim: reusado sin cambio ligeramente modificado: se reusó modificando menos del 25%

D documentación medida en páginas L longitud del programa D = 49L1,01

LOC

extensamente modificado: se reusó modificando más del 25%

para estimaciones precisas, se deben recolectar datos para entornos específicos

LOC

nuevo: ninguna línea proviene de un componente previo

razón de reuso r = LineasReusadas /LOC






Funcionalidad

existen tres enfoques para medir funcionalidad: puntos de función de Albrecht COCOMO II peso de especificación de De Marco

idea intuitiva: si un programa P es la implementación de la especificación S , entonces P y S deberían tener la misma funcionalidad




Puntos de función de Albrecht

los puntos de función (PFA) intentan medir la cantidad de funcionalidad de un sistema, descripta en la especificación pasos: 1

identificar inputs externos outputs externos consultas archivos externos archivos internos



Puntos de función de Albrecht

2

determinar complejidad subjetiva a cada ítem: simple, media, compleja y asignarle un peso según la tabla calcular PFNA: 15

PFNA =

calcular el factor de complejidad técnico (FCT ): 14

FCT = 0,65 + 0,01 ∗ ∑ F i i =1

4

donde F i es la valoración de 14 posibles factores de complejidad en el rango de 0 a 5. El resultado es tal que 0 , 65 ≤ FCT ≤ 1,35 calcular PFA PFA = PFNA ∗ FCT Pablo R. Fillottrani


Item

∑ #|tipo i | ∗ Peso i

i =1 3


Puntos de función de Albrecht - peso de cada categoría de items

pasos (cont.) 1




Componentes del Factor de Complejidad Técnico F 1 confiabilidad de backup

F 8 actualización online

y recuperación F 2 comunicacion de datos F 3 funciones distribuidas F 4 performance F 5 dependencia de la configuración F 6 entrada de datos online F 7 facilidad de operación

F 9 interface compleja F 10 procesamiento

complejo F 11 reusabilidad F 12 facilidad de instalación F 13 sitios múltiples F 14 facilidad de cambio

inputs externos outputs externos consultas archivos externos archivos internos

Factor de Peso simple medio complejo 3 4 6 4 5 7 3 4 6 7 10 15 5 7 10





Evaluación de los puntos de función de Albrecht los puntos de función forman una base para la estimación del esfuerzo Albrecht los propone como medida de tamaño independiente de la tecnología presentan varios problemas: subjetividad en FCT, variación del 35 % contar las cosas 2 veces → FCT = 1 pero valores no intuitivos: F i = 3  F i = 3 → FCT = 1,07 problemas con exactitud: el FCT no mejora significativamente la estimación de recursos



Evaluación de los puntos de función de Albrecht

problems con PFA (cont) no se puede usar anticipadamente: requiere la especificación completa problemas con cambios de requerimientos: variaciones de 400 % a 2000 % luego de implementación problemas con dominios de aplicación: funciona bien para sistemas de información administrativos, no en sistemas de tiempo real o en aplicaciones científicas problemas de dependencia de tecnología: no es independiente de los métodos de análisis y diseño usados




COCOMO II el modelo original de COCOMO desarrollado por Boehm resultó muy exitoso, sin embargo su aplicación no es práctica para entornos modernos de desarrollo de este modo, surge COCOMO II, cuyos objetivos son: desarrollar modelos de costos y de estimación acordes a las prácticas actuales desarrollar bases de datos de costos y herramientas que soporten una mejora continua del modelo proveer un framework analítico cuantitativo, y un conjunto de herramientas y técnicas para evaluar los efectos de las mejoras en los costos de ciclos de vida y en las planificaciones



Modelos del COCOMO II

COCOMO II está compuesto por tres modelos: modelo de la aplicación: basado en puntos objeto modelo de diseño temprano: usado para obtener estimaciones de costo y duración antes de finalizar el diseño de la arquitectura modelo post-arquitectura: el modelo más detallado, con nuevos conductores de costos, y nuevas ecuaciones






Métricas básicas de COCOMO II

COCOMO II provee un modelo para estimar costos en base a: KLOC

puntos objeto (PO ) puntos función (PF )




Cálculo de puntos objeto


pasos para el cálculo de PO (cont.)

pasos para el cálculo de PO 1 2 Vistas de pantalla

estimar el número de pantallas, reportes y componentes 3GL clasificar la complejidad de los mismos en simple, medio o difícil total < 4 (<2 servidor, < 2 cl ie nt e) simple simple medio

<3 3-7 >7

fuentes de datos total < 8 (2-3 servidor, 3- 5 cl ie nt e) simple medio difícil

total > 7 ( >3 servidor, > 5 cl ie nte ) medio difícil difícil




Secciones de reporte 0-1 2-3 >3

total < 4 (<2 servidor, < 2 cl ien te ) simple simple medio

fuentes de datos total < 8 (2-3 servidor, 3 -5 cl ie nt e) simple medio difícil

total > 7 ( >3 servidor, > 5 cl ie nt e) medio difícil difícil

3

4

pesar los objetos de acuerdo a su complejidad Objeto simple medio difícil pantalla 1 2 3 reporte 2 5 8 componente 3GL 10 determinar PO mediante la sumatoria de los pesos de todos los objetos encontrados








Cálculo de puntos función

pasos para el cálculo de PO (cont.) 5

estimar el porcentaje de reuso que se espera y calcular los nuevos puntos objeto (NPO )

pasos para el cálculo de PF : 1

NPO ::= PO (100 − %reuso )/100

NPO se utiliza a continuación en COCOMO II para estimar el

esfuerzo necesario para el desarrollo del proyecto, teniendo en cuenta la productividad del personal y de las herramientas CASE a utilizar

contar inputs externos ( IE ) outputs externos ( OE ) consultas externas ( CE ) archivos internos ( AI ) archivos de interface externos ( AE )





Cálculo de puntos función pasos para el cálculo de PF (cont.):

pasos para el cálculo de PF (cont.): 2

clasificar los objetos de acuerdo a su complejidad en simple, medio, o complejo

para AI y AE registros 1 2-5 >5

1-19 simple simple medio

datos 20-50 simple medio d ifícil para IE archivos 0-1 2-3 >3

>50 medio d ifícil difícil 1-4 simple simple medio



para OE y CE archivos 1-5 0-1 simple 2-3 simple >3 medio datos 5-15 >15 simple medio medi o difícil difícil difícil

datos 5-20 simple medio d ifícil

4

71 91 128 128 29 91 105






Complejidad

convertir PFNA en líneas de código estimadas (SLOC ) de acuerdo a la siguiente tabla: SLOC por PFNA

aplicar pesos de complejidad según la tabla puntos función complejidad simple medio complejo inputs externos 3 4 6 outputs externos 4 5 7 consultas externas 3 4 6 archivos internos 7 10 15 archivos externos 5 7 10 calcular los puntos de función no ajustados (PFNA), sumando los puntos de función por su peso de complejidad


pasos para el cálculo de PF (cont.):

Lenguaje Ada Basic (comp.) Basic (int.) C C++ Cobol 85 Fortran 77

3

> 20 medio d ifícil difícil


5


Lenguaje Java Lisp Modula 2 Pascal Prolog Generador reportes Planilla de cálculo

SLOC por PFNA

53 64 80 91 64 80 6

los puntos de función de Albrecht miden el problema. Un problema puede tener varias soluciones de distinta complejidad complejidad de la solución ≥ complejidad del problema complejidad del problema: cantidad de recursos requeridos para una solución óptima del problema complejidad de la solución: cantidad de recursos necesarios para implementar una solución particular la complejidad de la solución generalmente se mide en dos aspectos: tiempo y espacio



Complejidad en tiempo y en espacio

el tiempo mide el tiempo de la computadora necesario para el problema o para la solución particular el espacio mide la memoria de la computadora extra (aparte de los datos de entrada) necesario para el problema o para la solución particular para medir la complejidad de un problema, siempre se tiene en cuenta un algoritmo optimal que lo soluciona





Eficiencia



Ejemplo problema: encontrar la posición de un elemento en un arreglo ordenado solución 1: búsqueda secuencial, con complejidad en tiempo de n comparaciones y de espacio 1 solución 2: búsqueda binaria, con complejidad en tiempo de log2 (n ) comparaciones y de espacion de 1 se puede demostrar que el problema tiene complejidad en tiempo de log2 (n ) y en espacio de 1. Por lo que búsqueda binaria es optimal en tiempo y espacio, pero búsqueda secuencial es optimal sólo en espacio. siempre se mide el peor caso para todas las instancias de tamaño n , dada la imposibilidad práctica de medir en cada instancia en particular Pablo R. Fillottrani




Características de medir eficiencia

el medir tiempo de ejecución es una medida de eficiencia externa. Depende de factores externos. idea intuitiva: identificar un pequeño número de operaciones aritméticas primitivas relevantes del algoritmo. Ejemplo: en búsquedas / ordenamiento: comparaciones usando esa información medir en términos del número de operaciones requeridas para un input dado

se mide el producto y no el proceso no es dependiente de la máquina o de la implementación es específica de un input con respecto al algoritmo en la mayoría de los problemas los inputs pueden caracterizarse por un solo parámetro de tamaño n ejemplo: algoritmo de búsqueda. Input: lista de elementos e ítem a buscar. La eficiencia del algoritmo depende de la longitud de la lista



Notación asintótica



Objetivos

mide el número de operaciones primitivas requeridas para cualquier algoritmo es f (n ). Ejemplo: log 2 (n ) , n 2 , n ,... idea: definir una relación empírica: más eficiente no es claro que pares están en la relación. Ejemplo: n 2 >??100 ∗ n para precisarlo se usa un formalismo matemático notación O (), el orden de una función



no interesa conocer los valores absolutos de las funciones. permitir una caracterización simple de la eficiencia de un algoritmo y comparar las performances relativas de distintos algoritmos. independizar el análisis de los algoritmos de condiciones específicas de implementación: lenguaje de programación, compilador, equipo, etc.







Notación O (·)

se aplica a funciones de tiempo de ejecución o de espacio de memoria de algoritmos en base a la longitud de la entrada: f (n ) : N −→ R + . se denomina asintótica porque analiza el comportamiento de las funciones en el límite , es decir su tasa de crecimiento.

O (g (n ))

= {f (n ) : ∃c ∈ R + , ∃n 0 ∈ N , tal que f (n ) ≤ cg (n ) para todo n ≥ n 0}

determina una cota superior en la tasa de crecimiento de una función, dentro de un factor constante. ejemplos: 6n 3 ∈ O (n 3 ) ya que se cumple la definición con c = 6, n 0 = 1. 3log n ∈ O (n ) ya que se cumple la definición con c = 1, n 0 = 4.





Notación Ω(·) Ejemplos: 300n 2 ∈ O (n 2 ) 5n 4 − 4n 3 + 10n 2 + 39 ∈ O (n 4 ) logb n ∈ O (loga n ), ∀a , b 2n ∈ O (n !) 500000n ∈ O (0,00001n 2 ) ∈ O (500000n ) 0,000001n 2  ∈ O (2n ) n ! 



Ω(g (n )) = {f (n ) : ∃c ∈ R + , ∃n 0 ∈ N , tal que f (n ) ≥ cg (n ) para todo n ≥ n 0 }

determina una cota inferior en la tasa de crecimiento de una función, dentro de un factor constante. ejemplos: 6n 3 ∈ Ω(n 3 ) ya que se cumple la definición con c = 1, n 0 = 1 1/3n ∈ Ω(log n ) ya que se cumple la definición con c = 1/3, n 0 = 1.







Clasificación de problemas según su complejidad Ejemplos: 3n 5 + 4n 3 − 8n 2 + 10n ∈ Ω(n 4 ) logb n ∈ Ω(loga n ), ∀a , b n ! ∈ Ω(2n ) 0,00001n 2 ∈ Ω(50000n ) 50000n  ∈ Ω(0,00001n 2) ∈ Ω(n !) 2n 

de acuerdo al estado de conocimiento de sus algoritmos cerrado abierto

de acuerdo a los recursos indispensables para su solución tratables intratables



un problema se dice cerrado si se han encontrado algoritmos que lo resuelven y se ha demostrado que esos algoritmos son óptimos en cuanto al O () del tiempo de ejecución BÚSQUEDA en un arreglo ordenado y ORDENAMIENTO de un arreglo son problemas cerrados ÁRBOL DE CUBRIMIENTO MINIMAL para un grafo es un problema abierto, dado que su cota inferior demostrada es de Θ(a ), mientras que el mejor algoritmo conocido no es lineal (pero mejor que Θ(a log n ))





Complejidad de un problema

Supongamos que para solucionar todas las instancias de un problema particular un algoritmo requiere f (n ) cálculos Decimos que f(n) asintóticamente óptima si para todo algoritmo con complejidad g que soluciona el problema, f es O (g ) complejidad de un problema: es el orden del algoritmo asintóticamente óptimo para la solución del problema un problema que tiene una solución acotada polinómicamente se dice tratable o factible



para cerrar un problema se puede hacer: encontrar un algoritmo asintóticamente mejor que los que se conocen. demostar una cota asintóticamente superior de las que se conocen.





en general, los distintos grados de tratabilidad son muy subjetivos (varían mucho de acuerdo al modelo computacional, los recursos disponibles, las variantes de las estructuras de datos, etc.) por lo tanto un objetivo primario del estudio de la complejidad es definir cuáles problemas son tratables, y cuáles no. Recién después de esto se pueden considerar distintos grados de tratabilidad o intratabilidad por ejemplo, se puede afirmar que la mayoría de los problemas vistos en la materia son tratables: o sea tienen solución para instancias grandes, y una mejora algorítmica o una mejora en el HW produce una gran ampliación en el conjunto de instancias que se pueden resolver en cambio, hay problemas que no son tratables: el problema de las torres de Hanoi, o el problema del viajante, en la práctica sólo se resuelven para instancias pequeñas.



Estructuras



Estructura del flujo de control

la estructura del producto es importante no solo para el desarrollo sino también para el mantenimiento podemos dividir la estructura en: estructura del flujo de control: apunta a la secuencia en las cuales se ejecutan las instrucciones estructura del flujo de datos: sigue el rastro de los items de datos, cómo son creados o manejados por el programa estructura de datos: la organización de los datos en sí misma, independiente del programa





Ejemplo grafo de control de flujo

las mediciones de flujo de control son usualmente modeladas a partir de grafos dirigidos, llamados grafos de control de flujo (flowgraphs) el grafo está compuesto por: nodos: corresponden a las sentencias del programa arcos: muestran el flujo de control de una sentencia a otra

dado un programa A, llamamos interpretación razonable F (A) al grafo de control de flujo de A no siempre es obvio cómo mapear A en F (A)





Medidas de un grafo de control de flujo si m es una medida estructural definida en términos del modelo F (A), y si el programa A es estructuralmente mas complejo que B , entonces m (A) >> m (B se trata de introducir un enfoque independiente de cualquier visión de programación estructurada la técnica permite mostrar que cualquier programa tiene una única descomposición estructural definida por componentes primitivas se utilizan conceptos de grafos



Métricas orientadas a objetos



Métricas CK de objetos y relaciones entre objetos

métricas propuestas por Shyam R. Chidamber y Chris F. Kemerer definición de objetos y relaciones entre objetos atributos y propiedades de objetos comunicación entre objetos

métricas propuestas por Mark Lorenz y Jeff Kidd de tamaño: número de atributos y métodos de herencia: reuso de los métodos en la jerarquía internas: relacionadas con la cohesión de la clase externas: relacionadas con el acoplamiento entre clases





Métodos ponderados por clase (WMC )

WMC = ∑ c i i

, donde ci es una medida de complejidad del método i el número de métodos y su complejidad es un predictor de cuánto tiempo y esfuerzo es necesario para desarrollar y mantener la clase cuanto más métodos mayor impacto en los hijos (herencia) clases con más métodos son mas específicas, limitando el reuso

métodos ponderados por clase (WMC weighted methods per class) profundidad del árbol de herencia (DIN depth of inheritance) número de descendientes (NOC number of children)





Profundidad del árbol de herencia (DIN ) esa longitud máxima desde el nodo hasta la raíz del árbol de herencia cuanto más profunda está una clase en una jerarquía, mayor número de métodos hereda, haciendo más complejo predecir su comportamiento una jerarquía de clases profunda lleva también a una mayor complejidad de diseño ya que involucra más clases por otro lado, los valores grandes de esta medida implican que se pueden reutilizar muchos métodos



Número de subclases (NOC )



Métricas CK de atributos y propiedades de objetos

definida como el número de subclases inmedidatas a medida que crece el número de descendientes se incrementa la reutilización puede darse una mayor posibilidad de una incorrecta abstracción y mayor complejidad de la clase padre un gran número de hijos puede requerir mayor testing de los métodos de la clase un gran número de hijos también es un indicador de la influencia potencial de una clase en el diseño





Respuesta para una clase (RFC)

es el número de métodos que pueden ser invocados en respuesta a un mensaje enviado a un objeto de la clase un valor muy alto indica que la clase es compleja y probablemente altamente acoplada aumenta el esfuerzo de testeo y mantenimiento puede surgir el interrogante de si la clase está modelada correctamente

respuesta para una clase (RFC response for a class) falta de cohesión en los métodos (LCO lack of cohesion)





Falta de cohesión en los métodos (LCO)

es el número de pares de métodos cuya similitud es cero menos el número de pares de métodos cuya similitud es distinta de cero. Si el valor es negativo, se asume cero similitud: si dos pares de métodos acceden a uno o más de los mismos atributos la cohesión de los métodos dentro de una clase es deseable ya que promueve el encapsulamiento la falta de cohesión implica que una clase debiera dividirse en dos o más clases



Métricas CK de comunicación entre objetos

respuesta para una clase (RFC ) acoplamiento entre objetos (CBO coupling between objects)





Algunas métricas LK

tamaño de clase (CS ) número de operaciones redefinidas en una clase (NOO ) número de operaciones agregadas en una clase (NOA) índice de especialización (SI )



Acoplamiento entre objetos de clase(CBO) es la cantidad de clases con las cuales está acoplada una clase está acoplada con otra si usa métodos o variables de instancia de la otra un valor alto disminuye el diseño modular y dificulta el reuso el acoplamiento debe mantenerse mínimo para mejorar modularidad y encapsulamiento una medida de acoplamiento es útil para determinar cuanto de complejo será el diseño de testing cuanto más acoplamiento presenta el diseño más riguroso debe ser el testing





Tamaño de una clase (CS )

es el número total de métodos (heredados + propios) más el número total de atributos (heredados + propios) se puede dar mayor peso a atributos y métodos públicos y heredados un valor bajo indica mayor potencial de reuso



Número de operaciones redefinidas en una clase (NOO )

un NOO elevado es índice de no respeto a la abstracción implícita en la superclase es decir, de una jerarquía frágil involucra mayor dificultad en el testing y mantenimiento





Índice de especialización (SI )

la especialización se da agregando, redefiniendo o eliminando métodos de la superclase se define SI = (NOO ∗ nivel )/M donde nivel es el nivel de la clase en la jerarquía y M es el número total de métodos en la clase valores elevados de SI indican baja conformidad con la abstracción de la superclase



Número de operaciones agregadas en una clase (NOA)

al crecer el NOA la clase se aleja de la abstracción representada por la superclase también es índice de una jerarquía frágil, que conlleva dificultades en testing y mantenimiento en general, al crecer el DIN el NOA debería disminuir




Medidas de atributos internos vs externos la medición de atributos externos no es tan difundida como la de los internos la principal razón es que los atributos internos se consideran predictores razonables de aquellos externos y además los internos estan disponibles antes para su medición también, no es fácil la medición de atributos externos la medición cuidadosa de atributos externos requiere recursos extra que no todos los administradores de proyectos desean comprometer



Medidas basadas en defectos

Medidas de usabilidad

la densidad de defectos del software se define como la razón entre el número de defectos conocidos y el tamaño del producto pero no existe consenso sobre lo que es un defecto algunos reemplazan el tamaño del código por el tiempo de ejecución, resultando en tasa de defectos otra medida es la de desperdicios del sistema, definida como la razón entre el tiempo (o costo) de reparar defectos post-entrega sobre el tiempo (o costo) total del sistema




Medidas de mantenibilidad

para cualquier producto, el tiempo medio para una reparación (MTTR ) se mide como el promedio que toma a un equipo de mantenimiento reparar el sistema este tiempo puede involucrar factores externos al producto, como tiempos administrativos m se ha estudiado que ciertas combinaciones de factores internos tienen más probabilidad de generar errores

usabilidad es la medida en que el software es conveniente y práctico para usar (user-friendliness ) una posible medida es la probabilidad de que el operador no experimente un problema en la interface del usuario el problema de esta medida es que requiere una recolección de datos intensiva y cuidadosa también se puede medir indirectamente contando manuales, buen uso de menues y gráficos, mensajes de errores informados, invocaciones a funciones de ayuda e interfaces consistentes



Metricas de Bang

Recommend Documents