Post on 22-Oct-2018
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