4.2 METRICAS DE PROCESO Y PROYECTO

MODULO III

Ingeniería de Software INF - 163

Resumen preparado por Miguel Cotaña 1

03/12/2012

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

3

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.

4

“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

5

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.

Clasificación

6

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.

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

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

Medición de los requisitos

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

Medidas para diagramas de clases

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

11

Medidas de GENERO ET AL. (2000)

METRICA DEFINICION

NC Número total de clases.

NA Número total de atributos.

NM Número total de métodos.

NAssoc Número total de relaciones de asociación.

NAgg Número total de relaciones de agregación (cada par parte-todo en una relación de agregación)

NDep El número total de relaciones de dependencia.

NGen Número total de relaciones de generalización (cada par padre-hijo en una relación de generalización)

NAggH Número total de jerarquías de agregación

NGenH Número total de jerarquías de generalización.

MaxDIT Es el camino más largo desde la clase hasta la raíz de la jerarquía.

MaxHAgg Es el camino más largo desde la clase hasta las hojas.

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

Medidas para diagramas de casos de uso

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

Factores de calidad de McCall

14

Revisión del

Producto

Transición del

producto

Operación

del producto

Corrección Fiabilidad Usabilidad Integridad Eficiencia

Facilidad de mantenimiento

Flexibilidad

Facilidad de prueba

Portabilidad

Reusabilidad

Interoperatividad

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

Facilidad de mantenimiento = 1 - 0.1 (número medio de días-hombre por corrección)

Portabilidad = 1 - (esfuerzo para portar / esfuerzo para implementar)

Flexibilidad = 1 - 0.05 (número medio de días-hombre por cambio)

Fiabilidad = 1 - (número de errores/ número de líneas de código)

19

Algunas métricas

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

RT(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

26

Factores de calidad de Boehm

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

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

Ejemplo

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

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.

Métricas orientadas al tamaño

34

Proyecto LDC esfuerzo $ Pag.doc errores defectos

personal

Beta Alfa

Gamma . . . . .

12100 27200 20200

.

.

.

.

.

.

14 52 33 . . . . . .

150 240 314

.

.

.

.

.

500 1480 1000

.

.

.

.

.

.

139 350 200

.

.

.

.

.

.

19 76 54 . . . . . .

3 5 6 . . . . . .

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

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

Métricas orientadas a la función

37

38

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:

39

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.

40

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.

41

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.

42

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

43

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.

FI.1 comunicación de datos

FI.2 funciones distribuidas

FI.3 objetivos de performance

FI.4 configuración usada fuertemente

FI.5 tasa de transacciones

FI.6 entrada de datos en línea

FI.7 eficiencia del usuario final

FI.8 actualización en línea

FI.9 procesamiento complejo

FI.10 reusabilidad

FI.11 facilidad de instalación

FI.12 facilidad operacional

FI.13 sitios múltiples

FI.14 facilitamiento del cambio

CGS… Factores de influencia

44

0 factor no presente o sin influencia

1 influencia insignificante

2 influencia moderada

3 influencia promedio

4 influencia significativa

5 influencia fuerte

Escala de evaluación

45

46

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;

47

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;

48

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

49

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;

50

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;

51

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;

52

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.

53

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

54

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

Se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 56