Calidad en el Desarrollo de Software - Métricas del …prf/teaching/SQ07/clase3.pdf · pueden ser...

Métricas para el presupuestoModelos y componentes primitivas

Métricas de atributos internosMétricas de atributos externos

Calidad en el Desarrollo de SoftwareMétricas del software

Pablo R. Fillottrani

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

Segundo Cuatrimestre 2007

Pablo R. Fillottrani Calidad en el Desarrollo de Software



Métricas del software

You can’t control what you can’t measure

Tom DeMarco




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 porunidad de costo, considerando el costo total (todo el tiempo devida) del sistema

costo total del sistema: costo de desarrollo + costo de producción+ costo de mantenimiento




Pasos a seguir

pasos a seguir:1 formular un sólo indicador de medida de éxito vs el objetivo. BPB:

Bang per Buck (impacto por peso)2 coleccionar datos en una muestra de proyectos para establecer

estándares de performance de BPB3 buscar y evaluar predictores para aquellas partes de medida del

BPB que influyen a futuro4 motivar al personal para mejorar el BPB. El personal debe estar

informado de cómo se calcula el BPB5 publicar el BPB proyectado durante el proyecto, y el real luego de

6 meses de la implementación




Modelización del problema

un modelo consiste de una partición, junto con un registro de lasinterfaces entre las piezas de la particiónse necesitan tres perspectivas para especificar la mayoría de lossistemas:

modelo funcional: visión particionada de lo que hace el sistemamodelo de datos retenidos: visión particionada de lo que elsistema recuerdamodelo de comportamiento: visión de los diferentes estados decomportamiento 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 yrefinado por miembros del proyecto o usuarioel modelo de especificación tiene características medibles quepueden ser relacionadas con performance observadael modelo de especificación es terminado en forma tempranadurante el proyecto, provee oportunidad para corregir lasestimaciones

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 lasfunciones




Métricas provenientes de primitivasCorrección de indicadoresCálculo del bang

Componentes primitivas de un modelo

componente primitiva: no se descompone en componentessubordinadas

dependiendo de lo que se particione, se obtienen seis clases deprimitivas:

Elemento Particiona Produce primitivasDFD requerimientos del sistema primitivas funcionalesDD datos del sistema datos elementales

diag. objetos datos retenidos objetosdiag. objetos datos retenidos relacionesdiag. estados características de control estadosdiag. estados características de control transiciones





Métricas a partir de las primitivas

analizar las primitivas provee métricas básicas para medir elBang:

PF : número de primitivas funcionales automáticasPFM: número de primitivas funcionales manuales modificablesDE : número de datos elementales dentro del sistema automáticoDEI: número de datos elementales de inputDEO: número de datos elementales de outputDER: 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 retenidosRE : número de relaciones en el modelo de datos retenidoST : número de estados en el modelo de comportamientoTR: número de transiciones en el modelo de comportamientoTCi : número de data tokens en la primitiva iREi : 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 elprincipal y se usan los otros para modificarlo

en la mayoría de los sistemas administrativos PF es el principalindicador

hay sistemas altamente orientados a funciones y otros a datos,dependiendo de esto es el indicador que se deberá considerarcomo principal





Indicador principal

se pueden analizar dos razones en función de PF (primitivasfuncionales) y RE (relaciones entre objetos):

RE/PF < 0,7 sistema orientado a funcionesRE/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 sepuede usar

TCavg = ∑i

TCi/PF

regla de partición uniforme: dejar una componente comoprimitiva sólo si no es posible una partición o si la nueva particiónno reduce el TCavg





Corrección de indicadores I

las primitivas se pueden clasificar de acuerdo a su función en:separación: dividen los datos de inputmerge: combinan los datos de inputdirección de datos: dirigen datos de acuerdo a una variable decontrolactualización simple: actualiza uno o mas datos enalmacenamientosadministración de almacenamientos: analiza datos almacenadosy 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áquinaverificación: chequea e informa inconsistenciasmanipulación de textos: administra textossincronización: decide cuándo actuar o decide por otrasgeneración de output: formatea nuevos flujos de datos (notabulares)display: construye outputs tabulares (2 dimensiones)aritméticas: realiza cálculosinicialización: setea valores para datos almacenados





Corrección de indicadores III

clasificación de primitivas (cont.)computación: cálculos matemáticos complejosadministración de dispositivos: controla dispositivos

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

en los sistemas orientados a datos el peso depende de los REi

de los objetos

existen factores de corrección en función de los REi





Cálculo del bang

el bang es un indicador cuantitativo de las funciones útiles netasdesde el punto de vista del usuario. Independiente de laimplementacion

en sistemas híbridos se aconseja manejar dos bangs, elfuncional y el de datos. No se puede generalizar una fórmula quelos relacioneobjetivos de calcular el bang:

se usa como un predictor fuerte y anticipado del esfuerzose usa para calcular eficiencia productiva: BPB

se deben usar otras métricas para otras actividades, como porejemplo conversión de la base de datos, etc





Cálculo del bang funcional

bang ::= 0para cada primitiva funcional f[i] del modelo

TC[i] ::= sumatoria de data token de f[i]PFC[i] ::= corrección(TC[i]clasificar f[i]buscar PesoCorr[i] en tabla de corrección

y de acuerdo al tipo de primitivabang ::= bang + PFC[i] * PesoCorr[i]





Cálculo del bang orientado a datos

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

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




LongitudFuncionalidadComplejidadEstructurasMétricas orientadas a objetos

Tamaño del software

en software, el tamaño no es lo que importaya que en general no considera

esfuerzo: no tiene en cuenta redundancia y complejidadproductividad: no consideran funcionalidadcosto: no contabiliza reuso





Medición del tamaño

el tamaño del software puede ser descripto con tres atributos:longitud: mide tamaño físico del productofuncionalidad: mide las funciones provistas por el productocomplejidad: puede ser interpretada de distintas maneras

del problema a resolverdel algoritmo utilizado, eficiencia del softwareestructural: mide la estructura del SW implementadacognitiva: esfuerzo requerido para entender el SW





Consideraciones

hay consenso en medir longitud de programas, pero no deespecificaciones

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íaimportante medir son:

especificacionesdiseñocó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

Conte, Dunsmore & Shen: cualquier línea de texto de programaque no es comentario o línea en blanco, independientemente delnú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 lineof code

ELOC: effective line of code

longitud total LOC = NCLOC +CLOC





Líneas de código

es posible distinguir entre la cantidad de código entregado (DSIDelivered Source instructions) y la cantidad de códigodesarrollado

formula de Halstead: volumen = longitud ∗ log2(vocabulario)

otro enfoque es medir longitud de acuerdo a:número de bytes de almacenamiento requerido para el texto delprogramanúmero de caracteres (CHAR) en el texto del programa





Líneas de código

en programación visual, entornos de ventanas, orientación aobjetos lenguajes de cuarta generación, cambian las nociones detamañosurgen 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 masprecisas





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 sonclases, funciones, operaciones y axiomas

intuitivamente: se predice la longitud para tratar de relacionar lalongitud de productos de etapas posteriores con la longitud deproductos ya construidos





Longitud de especificaciones

razón de expansión α : tamaño de diseño / tamaño de código

LOC = a∗∑i = 1nSi , donde Si es el tamaño del módulo iWalston & Felix:

D documentación medida en páginasL longitud del programaD = 49L1,01

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





Reuso

el reuso mejora la productividad y la calidad. Es difícil de definirformalmentegrados de reuso publicado por NASA/Goddard’s SoftwareEngineering Lab

reuso verbatim: reusado sin cambioligeramente modificado: se reusó modificando menos del 25 %LOCextensamente modificado: se reusó modificando más del 25 %LOCnuevo: 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 AlbrechtCOCOMO IIpeso de especificación de De Marco

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





Puntos de función de Albrecht

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

1 identificarinputs externosoutputs externosconsultasarchivos externosarchivos internos





Puntos de función de Albrecht

pasos (cont.)1 determinar complejidad subjetiva a cada ítem: simple, media,

compleja y asignarle un peso según la tabla2 calcular PFNA:

PFNA =15

∑i=1

#|tipoi | ∗Pesoi

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

FCT = 0,65+0,01∗14

∑i=1

Fi

donde Fi es la valoración de 14 posibles factores de complejidaden el rango de 0 a 5. El resultado es tal que 0,65 ≤ FCT ≤ 1,35

4 calcular PFAPFA = PFNA∗FCT





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

Item Factor de Pesosimple medio complejo

inputs externos 3 4 6outputs externos 4 5 7consultas 3 4 6archivos externos 7 10 15archivos internos 5 7 10





Componentes del Factor de Complejidad Técnico

F1 confiabilidad de backupy recuperación

F2 comunicacion de datos

F3 funciones distribuidas

F4 performance

F5 dependencia de laconfiguración

F6 entrada de datos online

F7 facilidad de operación

F8 actualización online

F9 interface compleja

F10 procesamientocomplejo

F11 reusabilidad

F12 facilidad de instalación

F13 sitios múltiples

F14 facilidad de cambio





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

los puntos de función forman una base para la estimación delesfuerzo

Albrecht los propone como medida de tamaño independiente dela tecnologíapresentan varios problemas:

subjetividad en FCT, variación del 35 %contar las cosas 2 vecesvalores no intuitivos: Fi = 3 6→ FCT = 1 peroFi = 3 → FCT = 1,07problemas con exactitud: el FCT no mejora significativamente laestimació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óncompletaproblemas con cambios de requerimientos: variaciones de 400 %a 2000 % luego de implementaciónproblemas con dominios de aplicación: funciona bien parasistemas de información administrativos, no en sistemas detiempo real o en aplicaciones científicasproblemas de dependencia de tecnología: no es independiente delos 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 paraentornos modernos de desarrollode este modo, surge COCOMO II, cuyos objetivos son:

desarrollar modelos de costos y de estimación acordes a lasprácticas actualesdesarrollar bases de datos de costos y herramientas que soportenuna mejora continua del modeloproveer un framework analítico cuantitativo, y un conjunto deherramientas y técnicas para evaluar los efectos de las mejorasen 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 objetomodelo de diseño temprano: usado para obtener estimaciones decosto y duración antes de finalizar el diseño de la arquitecturamodelo post-arquitectura: el modelo más detallado, con nuevosconductores de costos, y nuevas ecuaciones





Métricas básicas de COCOMO II

COCOMO II provee un modelo para estimar costos en base a:KLOCpuntos objeto (PO)puntos función (PF )





Cálculo de puntos objeto

pasos para el cálculo de PO1 estimar el número de pantallas, reportes y componentes 3GL2 clasificar la complejidad de los mismos en simple, medio o difícil

Vistas fuentes de datos Secciones fuentes de datosde total < 4 total < 8 total > 7 de total < 4 total < 8 total > 7pantalla (<2 servidor, (2-3 servidor, ( >3 servidor, reporte (<2 servidor, (2-3 servidor, ( >3 servidor,

<2 cliente) 3-5 cliente) >5 cliente) <2 cliente) 3-5 cliente) >5 cliente)<3 simple simple medio 0-1 simple simple medio3-7 simple medio difícil 2-3 simple medio difícil>7 medio difícil difícil >3 medio difícil difícil






pasos para el cálculo de PO (cont.)3 pesar los objetos de acuerdo a su complejidad

Objeto simple medio difícilpantalla 1 2 3reporte 2 5 8componente 3GL - - 10

4 determinar PO mediante la sumatoria de los pesos de todos losobjetos encontrados






pasos para el cálculo de PO (cont.)5 estimar el porcentaje de reuso que se espera y calcular los

nuevos puntos objeto (NPO)

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

NPO se utiliza a continuación en COCOMO II para estimar elesfuerzo necesario para el desarrollo del proyecto, teniendo encuenta la productividad del personal y de las herramientas CASEa utilizar





Cálculo de puntos función

pasos para el cálculo de PF :1 contar

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






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 datos para OE y CE datosregistros 1-19 20-50 >50 archivos 1-5 5-20 > 201 simple simple medio 0-1 simple simple medio2-5 simple medio difícil 2-3 simple medio difícil>5 medio difícil difícil >3 medio difícil difícil

para IE datosarchivos 1-4 5-15 >150-1 simple simple medio2-3 simple medio difícil>3 medio difícil difícil






pasos para el cálculo de PF (cont.):3 aplicar pesos de complejidad según la tabla

puntos función complejidadsimple medio complejo

inputs externos 3 4 6outputs externos 4 5 7consultas externas 3 4 6archivos internos 7 10 15archivos externos 5 7 10

4 calcular los puntos de función no ajustados (PFNA), sumando lospuntos de función por su peso de complejidad






pasos para el cálculo de PF (cont.):5 convertir PFNA en líneas de código estimadas (SLOC) de

acuerdo a la siguiente tabla:

Lenguaje SLOC por PFNA Lenguaje SLOC por PFNAAda 71 Java 53Basic (comp.) 91 Lisp 64Basic (int.) 128 Modula 2 80C 128 Pascal 91C++ 29 Prolog 64Cobol 85 91 Generador reportes 80Fortran 77 105 Planilla de cálculo 6





Complejidad

los puntos de función de Albrecht miden el problema. Unproblema puede tener varias soluciones de distinta complejidad

complejidad de la solución ≥ complejidad del problema

complejidad del problema: cantidad de recursos requeridos parauna solución óptima del problema

complejidad de la solución: cantidad de recursos necesarios paraimplementar una solución particular

la complejidad de la solución generalmente se mide en dosaspectos: tiempo y espacio





Complejidad en tiempo y en espacio

el tiempo mide el tiempo de la computadora necesario para elproblema o para la solución particular

el espacio mide la memoria de la computadora extra (aparte delos datos de entrada) necesario para el problema o para lasolución particular

para medir la complejidad de un problema, siempre se tiene encuenta un algoritmo optimal que lo soluciona





Ejemplo

problema: encontrar la posición de un elemento en un arregloordenado

solución 1: búsqueda secuencial, con complejidad en tiempo den comparaciones y de espacio 1

solución 2: búsqueda binaria, con complejidad en tiempo delog2(n) comparaciones y de espacion de 1

se puede demostrar que el problema tiene complejidad en tiempode log2(n) y en espacio de 1. Por lo que búsqueda binaria esoptimal en tiempo y espacio, pero búsqueda secuencial esoptimal sólo en espacio.

siempre se mide el peor caso para todas las instancias detamaño n, dada la imposibilidad práctica de medir en cadainstancia en particular





Eficiencia

el medir tiempo de ejecución es una medida de eficienciaexterna. Depende de factores externos.idea intuitiva:

identificar un pequeño número de operaciones aritméticasprimitivas relevantes del algoritmo. Ejemplo: en búsquedas /ordenamiento: comparacionesusando esa información medir en términos del número deoperaciones requeridas para un input dado





Características de medir eficiencia

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 caracterizarsepor un solo parámetro de tamaño n

ejemplo: algoritmo de búsqueda. Input: lista de elementos e ítema buscar. La eficiencia del algoritmo depende de la longitud de lalista





Notación asintótica

mide el número de operaciones primitivas requeridas paracualquier algoritmo es f (n). Ejemplo: log2(n) , n2, n,...

idea: definir una relación empírica: más eficiente

no es claro que pares están en la relación. Ejemplo:n2 >??100∗n

para precisarlo se usa un formalismo matemático notación O(),el orden de una función





Objetivos

no interesa conocer los valores absolutos de las funciones.

permitir una caracterización simple de la eficiencia de unalgoritmo y comparar las performances relativas de distintosalgoritmos.

independizar el análisis de los algoritmos de condicionesespecíficas de implementación: lenguaje de programación,compilador, equipo, etc.





se aplica a funciones de tiempo de ejecución o de espacio dememoria de algoritmos en base a la longitud de la entrada:f (n) : N −→ R+.

se denomina asintótica porque analiza el comportamiento de lasfunciones en el límite, es decir su tasa de crecimiento.





Notación O(·)

O(g(n)) = f (n) : ∃c ∈ R+,∃n0 ∈ N, tal que

f (n)≤ cg(n) para todo n ≥ n0

determina una cota superior en la tasa de crecimiento de unafunción, dentro de un factor constante.ejemplos:

6n3 ∈ O(n3) ya que se cumple la definición con c = 6,n0 = 1.3 logn ∈ O(n) ya que se cumple la definición con c = 1,n0 = 4.





Ejemplos:

300n2 ∈ O(n2)

5n4−4n3 +10n2 +39 ∈ O(n4)

logb n ∈ O(loga n),∀a,b

2n ∈ O(n!)

500000n ∈ O(0,00001n2)

0,000001n2 6∈ O(500000n)

n! 6∈ O(2n)





Notación Ω(·)

Ω(g(n)) = f (n) : ∃c ∈ R+,∃n0 ∈ N, tal que

f (n)≥ cg(n) para todo n ≥ n0

determina una cota inferior en la tasa de crecimiento de unafunción, dentro de un factor constante.ejemplos:

6n3 ∈ Ω(n3) ya que se cumple la definición con c = 1,n0 = 11/3n ∈ Ω(logn) ya que se cumple la definición conc = 1/3,n0 = 1.





Ejemplos:

3n5 +4n3−8n2 +10n ∈ Ω(n4)

logb n ∈ Ω(loga n),∀a,b

n! ∈ Ω(2n)

0,00001n2 ∈ Ω(50000n)

50000n 6∈ Ω(0,00001n2)

2n 6∈ Ω(n!)





Clasificación de problemas según su complejidad

de acuerdo al estado de conocimiento de sus algoritmoscerradoabierto

de acuerdo a los recursos indispensables para su solucióntratablesintratables





un problema se dice cerrado si se han encontrado algoritmos quelo 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 unarreglo son problemas cerrados

ÁRBOL DE CUBRIMIENTO MINIMAL para un grafo es unproblema abierto, dado que su cota inferior demostrada es deΘ(a), mientras que el mejor algoritmo conocido no es lineal(pero mejor que Θ(a logn))





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





Complejidad de un problema

Supongamos que para solucionar todas las instancias de unproblema particular un algoritmo requiere f (n) cálculos

Decimos que f(n) asintóticamente óptima si para todo algoritmocon complejidad g que soluciona el problema, f es O(g)

complejidad de un problema: es el orden del algoritmoasintóticamente óptimo para la solución del problema

un problema que tiene una solución acotada polinómicamente sedice tratable o factible





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





Estructuras

la estructura del producto es importante no solo para eldesarrollo sino también para el mantenimientopodemos dividir la estructura en:

estructura del flujo de control: apunta a la secuencia en las cualesse ejecutan las instruccionesestructura del flujo de datos: sigue el rastro de los items de datos,cómo son creados o manejados por el programaestructura de datos: la organización de los datos en sí misma,independiente del programa





Estructura del flujo de control

las mediciones de flujo de control son usualmente modeladas apartir de grafos dirigidos, llamados grafos de control de flujo(flowgraphs)

el grafo está compuesto por:

nodos: corresponden a las sentencias del programaarcos: muestran el flujo de control de una sentencia a otra

dado un programa A, llamamos interpretación razonable F(A) algrafo de control de flujo de A

no siempre es obvio cómo mapear A en F(A)





Ejemplo grafo de control de flujo





Medidas de un grafo de control de flujo

si m es una medida estructural definida en términos del modeloF(A), y si el programa A es estructuralmente mas complejo queB, entonces m(A) >> m(B

se trata de introducir un enfoque independiente de cualquiervisión de programación estructurada

la técnica permite mostrar que cualquier programa tiene unaúnica descomposición estructural definida por componentesprimitivas

se utilizan conceptos de grafos





Métricas orientadas a objetos

métricas propuestas por Shyam R. Chidamber y Chris F. Kemerer

definición de objetos y relaciones entre objetosatributos y propiedades de objetoscomunicación entre objetos

métricas propuestas por Mark Lorenz y Jeff Kiddde tamaño: número de atributos y métodosde herencia: reuso de los métodos en la jerarquíainternas: relacionadas con la cohesión de la claseexternas: relacionadas con el acoplamiento entre clases





Métricas CK de objetos y relaciones entre objetos

métodos ponderados por clase (WMC weighted methods perclass)

profundidad del árbol de herencia (DIN depth of inheritance)

número de descendientes (NOC number of children)





Métodos ponderados por clase (WMC)

WMC = ∑i

ci

, donde ci es una medida de complejidad del método i

el número de métodos y su complejidad es un predictor decuánto tiempo y esfuerzo es necesario para desarrollar ymantener 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





Profundidad del árbol de herencia (DIN)

esa longitud máxima desde el nodo hasta la raíz del árbol deherencia

cuanto más profunda está una clase en una jerarquía, mayornúmero de métodos hereda, haciendo más complejo predecir sucomportamiento

una jerarquía de clases profunda lleva también a una mayorcomplejidad de diseño ya que involucra más clases

por otro lado, los valores grandes de esta medida implican quese pueden reutilizar muchos métodos





Número de subclases (NOC)

definida como el número de subclases inmedidatas

a medida que crece el número de descendientes se incrementala reutilización

puede darse una mayor posibilidad de una incorrecta abstraccióny mayor complejidad de la clase padre

un gran número de hijos puede requerir mayor testing de losmétodos de la clase

un gran número de hijos también es un indicador de la influenciapotencial de una clase en el diseño





Métricas CK de atributos y propiedades de objetos

respuesta para una clase (RFC response for a class)

falta de cohesión en los métodos (LCO lack of cohesion)





Respuesta para una clase (RFC)

es el número de métodos que pueden ser invocados enrespuesta a un mensaje enviado a un objeto de la clase

un valor muy alto indica que la clase es compleja yprobablemente altamente acoplada

aumenta el esfuerzo de testeo y mantenimiento

puede surgir el interrogante de si la clase está modeladacorrectamente





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

es el número de pares de métodos cuya similitud es cero menosel 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 losmismos atributos

la cohesión de los métodos dentro de una clase es deseable yaque promueve el encapsulamiento

la falta de cohesión implica que una clase debiera dividirse endos o más clases





Métricas CK de comunicación entre objetos

respuesta para una clase (RFC)

acoplamiento entre objetos (CBO coupling between objects)





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 deinstancia de la otra

un valor alto disminuye el diseño modular y dificulta el reuso

el acoplamiento debe mantenerse mínimo para mejorarmodularidad y encapsulamiento

una medida de acoplamiento es útil para determinar cuanto decomplejo será el diseño de testing

cuanto más acoplamiento presenta el diseño más riguroso debeser el testing





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)





Tamaño de una clase (CS)

es el número total de métodos (heredados + propios) más elnúmero total de atributos (heredados + propios)

se puede dar mayor peso a atributos y métodos públicos yheredados

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ónimplícita en la superclase

es decir, de una jerarquía frágil

involucra mayor dificultad en el testing y mantenimiento





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

al crecer el NOA la clase se aleja de la abstracción representadapor la superclase

también es índice de una jerarquía frágil, que conllevadificultades en testing y mantenimiento

en general, al crecer el DIN el NOA debería disminuir





Índice de especialización (SI)

la especialización se da agregando, redefiniendo o eliminandométodos de la superclase

se defineSI = (NOO ∗nivel)/M

donde nivel es el nivel de la clase en la jerarquía y M es elnúmero total de métodos en la clase

valores elevados de SI indican baja conformidad con laabstracción de la superclase




Medidas de atributos internos vs externos

la medición de atributos externos no es tan difundida como la delos internos

la principal razón es que los atributos internos se consideranpredictores 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 recursosextra que no todos los administradores de proyectos deseancomprometer




Medidas basadas en defectos

la densidad de defectos del software se define como la razónentre 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 deejecución, resultando en tasa de defectos

otra medida es la de desperdicios del sistema, definida como larazón entre el tiempo (o costo) de reparar defectos post-entregasobre el tiempo (o costo) total del sistema




Medidas de usabilidad

usabilidad es la medida en que el software es conveniente ypráctico para usar (user-friendliness)

una posible medida es la probabilidad de que el operador noexperimente un problema en la interface del usuario

el problema de esta medida es que requiere una recolección dedatos 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




Medidas de mantenibilidad

para cualquier producto, el tiempo medio para una reparación(MTTR) se mide como el promedio que toma a un equipo demantenimiento reparar el sistema

este tiempo puede involucrar factores externos al producto, comotiempos administrativos

m se ha estudiado que ciertas combinaciones de factoresinternos tienen más probabilidad de generar errores


Calidad en el Desarrollo de Software - Métricas del …prf/teaching/SQ07/clase3.pdf · pueden ser...

Documents

Transcript of Calidad en el Desarrollo de Software - Métricas del …prf/teaching/SQ07/clase3.pdf · pueden ser...