guía 08. medición de software...

1

INTRODUCCIÓN

"Lo que no se puede medir, no se puedecontrolar; lo que no se puede controlar no sepuede gestionar; lo que no se puede gestionar,no se puede mejorar" (Peter Drucker)

“No se puede predecir lo que no sepuede medir” (Norman Fenton)”

“Las métricas son un buen medio para entender, monitorizar,controlar, predecir y probar el desarrollo software y los proyectos demantenimiento” (Briand et al., 1996)

En general, la medición persigue tres objetivos fundamentales(Fenton y Pfleeger, 1997):

• entender qué ocurre durante el desarrollo y el mantenimiento• controlar qué es lo que ocurre en nuestros proyectos• mejorar nuestros procesos y nuestros productos

Guía 08. Medición de Software

2

INTRODUCCIÓN

Las métricas pueden ser utilizadas para que losprofesionales e investigadores puedan tomar lasmejores decisiones. (Pfleeger, 1997).

MÉTRICAS COMO MEDIO PARAASEGURAR LA CALIDAD EN LOS

PRODUCTOS / PROCESOS / PROYECTOS SOFTWARE


3

ONTOLOGÍA DE LA MEDICIÓN

La medición de software es una disciplina

relativamente joven, y no existe consenso general

sobre la definición exacta de los conceptos y

terminología que maneja.

Una ontología ha de comprenderse como un entendimiento común y

compartido de un dominio


4


Sub-Ontología Caracterización y Objetivos de la Medición Software: Glosario de Conceptos


5


Sub-Ontología Caracterización y Objetivos de la Medición Software: Tabla de Interrelaciones


6


• Concepto: MÉTRICA

• Definición. Una forma de medir y una escala, definidas pararealizar mediciones de uno o varios atributos

• Relaciones:

– Una métrica está definida para uno o más atributos

– Una métrica puede expresarse en una unidad (sólo paramétricas cuya escala sea de tipo intervalo o ratio)

• Ejemplos

– “líneas de código” para el “tamaño” de un “módulo en C” o deun “programa en Python”.


7


• Concepto. MEDIDA

• Definición. Resultado de una medición.

• Relaciones: Una medida es el resultado de una medición

• Ejemplos

– 35.000 líneas de código, 200 páginas, 50 clases.

– 5 meses desde el comienzo al fin del proyecto.

– 0,5 fallos por cada 1.000 líneas de código.


8


9


ESCALAS

NOMINAL. Escala más básica, que sitúa a las entidades en diferentes categoríasasignando al atributo un nombre. Cuando un producto se rotula de acuerdo alcumplimiento de las especificaciones de diseño como "conforme y no conforme".o "crítico, grave, y menor". No se obtienen valores numéricos y no se puederealizar un orden de las observaciones con sentido.

ORDINAL. Los atributos pueden ser ordenados en rangos, pero la distanciaentre los mismos no es significativa.

Suponga que a los clientes se les hace unas preguntas para valorar la calidad delproducto. Los clientes valoran la calidad de acuerdo a las siguientes respuestas:1 (excelente), 2 (bueno), 3 (regular), 3 (malo) 4 (pésimo).

Estos datos son ordinales. Note que una valoración de 1 no indica que el servicioes dos veces mejor que cuando se da una valoración de 2. Sin embargo podemosdecir que la valoración de 1 es preferiblemente mejor que 2, y así en los demáscasos.


10


ESCALAS

INTERVALO. Como la ordinal pero la distancia entre los atributos sí tienesentido.

Si se mide la temperatura en grados celsius, la distancia entre 30º y 40º es lamisma que entre 60º y 70º. Sin embargo, hay que tener en cuenta que en estaescala el cero es arbitrario; por tanto no se puede decir que 50º es el doble detemperatura que 25º (aunque el valor si es el doble).

RATIO. El mas útil en medición del software, ya que preserva el orden , eltamaño de los intervalos y también los ratios entre las entidades. Tiene un puntofijo de referencia: el cero (comienzo de la escala) y se incrementa en pasosiguales. Con estos valores de la escala se pueden hacer operaciones

matemáticas de + , - , * , /


11


• Todo proceso de medición tiene como objetivo fundamentalsatisfacer necesidades de medición detectadas en la empresa en laque se lleva a cabo.

• A partir de esta necesidad se identifican entidades y atributos aser medidos.

• Luego se definen las métricas necesarias (unidad en la que seexpresa, escala a la que pertenece, atributo o atributos para losque se define)

• Primero se definen métricas directas, luego indirectas, yfinalmente criterios de decisión para satisfacer las necesidades deinformación planteadas inicialmente.


12

ESTÁNDARES

Practical Software Measurement (PSM) (McGarry et al., 2002) se basa en la experiencia obtenida de organizaciones para saber cuál es la mejor manera de implementar un programa de medida software con garantías de éxito.

ISO/IEC 15939. Este estándar internacional (2002) establece las actividades y tareas necesarias

para identificar, definir, seleccionar, aplicar y mejorar de manera exitosa la medición de software dentro deun proyecto general o de la estructura de medición de una empresa.


13

ESTÁNDARES

MEDICIÓN EN ISO/IEC 12207. Es el estándar para los procesos de ciclo de vida del software. Este

estándar se concibió para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. Elestándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software.


14

DEFINICIÓN DE MÉTRICAS

Basili y Weiss (1984) y Rombach (1990). Autores y refinadores de GQM (Goal-Question-

Metric), un paradigma para desarrollar y mantener un programa de métricas . Proporciona

una manera útil para definir mediciones tanto del proceso como de los resultados de un

proyecto. GQM se puede aplicar a todo el ciclo de vida del producto, procesos, y recursos y se

pude alinear fácilmente con el ambiente organizacional. Tiene como principio básico que la

medición debe ser realizada, siempre, orientada a un objetivo.

Objetivo Objetivo Perseguido

Preguntas Pregunta 1 Pregunta N

Métricas M1 Mn... M1’ Mn’...


15

PROCESO DE RECOPILACIÓN DE MÉTRICAS

MÉTRICAS DE SOFTWARE


16


Clasificación de las métricas de software según criterios:


17


Según el contexto:

Proceso:

Se recopilan de todos los proyectos, y durante un largo periodo de tiempo

Caracterizadas por:

Control y ejecución del proyecto.

Medición de tiempos de las fases.

Proyecto:

Permiten evaluar el estado del proyecto.

Permiten seguir la pista de los riesgos.

Producto:

Se centran en las características del software y no en cómo se fabricó.

También son productos los artefactos, documentos, modelos y componentesque conforman el software.

Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad y elesfuerzo.


18

EJEMPLO. Supongamos una organización que lleva a cabo un proyecto dedesarrollo de un software X. En un determinado momento el responsable delproyecto necesita saber si la productividad es adecuada, es decir:

La necesidad de información es conocer el nivel de productividad de losprogramadores del proyecto en comparación con lo habitual en otros proyectosen la organización.

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íneasutilizando como instrumento una herramienta CASE.

HPD (horas-programador diarias). El método de medición es que el responsable delproyecto 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 esconsultar el plan del proyecto, donde se tuvo que indicar este valor, previa consulta a unresponsable de personal.


19

EJEMPLO

Indirectas:

HPT (horas-programador totales).

La función de cálculo es una sumatoria de las HPD de cada día: HPT = ∑HPD

[Métrica indirecta definida con base en 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 / HPD[Métrica indirecta definida con base en 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 decada hora por el total de horas empleadas: CTP = CHP * HPT[Métrica indirecta definida con base en 2 métricas, una directa y otra indirecta].

CLCF (coste por línea de código fuente).La función de cálculo establece que el CLCF es el resultado de dividir el coste totalactual del proyecto -en unidades monetarias- entre la cantidad de líneas decódigo fuente escritas: CLCF = CTP/ LCF.[Métrica indirecta definida con base en 2 métricas, una indirecta y otra directa].


20

EJEMPLO

Indicadores: PROD (productividad de los programadores).

El modelo de análisis utiliza los valores de las métricas LCF, HPT, LCFH y CTP para establecerun 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 losvalores medios de

LCF , HPT , LCFH (LCFHvm valor medio de líneas de código fuente por hora de programador) y CTP

del subconjunto de proyectos similares (aquellos que tienen LCF entre el 80% y el 120%).

Y la organización establece el siguiente criterio de decisión:

LCFH / LCFHvm < 0.70 se interpreta como PROD=’muy baja’.0.70 <= LCFH / LCFHvm < 0.90 se interpreta como PROD=’baja’.0.90 <= LCFH / LCFHvm < 1.10 se interpreta como PROD=’normal’.1.10 <= LCFH / LCFHvm < 1.30 se interpreta como PROD=’alta’.1.30 <= LCFH / LCFHvm se interpreta como PROD=’muy alta’.

De modo que cuando se calcule el valor para el indicador (a partir de las métricasmencionadas) se podrá evaluar y entregar un concepto sobre la situación que dicho indicadorpretende reflejar.


21

OTROS QUE SE PUEDEN UTILIZAR

Número de defectos generados por desarrollador por hora

Número de cambios a los requisitos

Número de versiones con correcciones (patch) realizadas después de

lanzar el producto

Horas disponibles y ejecutadas por programador por semana

Defectos descubiertos durante las pruebas

Número de defectos introducidos al realizar una modificación.


MEDIDA DE LOS FACTORES DE CALIDAD

Los factores que afectan a la calidad del software se puedencategorizar en dos amplios grupos:

(1)Factores que se pueden medir directamente (por ejemplo,defectos por punto de función).

(2)Factores que se pueden medir sólo indirectamente (porejemplo, facilidad de uso o de mantenimiento).

En todos los casos debe aparecer la medición. Debemoscomparar el software (documentos, programas, datos) con unareferencia y llegar a una conclusión sobre la calidad.

22



Ejemplo. Modelo de McCall.

23




Es difícil, y en algunos casos imposible, desarrollar medidas directas de los factores de calidad anteriores.

Por tanto, se definen y emplean un conjunto de criterios para desarrollar expresiones para todos los factores, de acuerdo con la siguiente relación:

QF = (c1 * m1) + (c2 * m2) + (c3 * m3) + … + (cn * mn)

Donde: QF es un factor de calidad del software, cn son coeficientes de regresión ( c1 + c2 + … + cn = 1.0 ) m, son los valores de los criterios que afectan al factor de calidad.

24




El problema es que muchas de los criterios definidas por

McCall pueden medirse solamente de manera subjetiva. Las

métricas pueden ir en forma de lista de comprobación que se

emplea para "puntuar" atributos específicos del software.

El esquema de puntuación propuesto por McCall es una

escala del 0 (bajo) al 10 (alto).

Se emplean las siguientes criterios en el esquema de

puntuación:

25




Facilidad de auditoría. La facilidad con la que se puede comprobar el cumplimiento de los estándares.

Exactitud. La exactitud de los cálculos y del control.

Estandarización de comunicaciones. El grado de empleo de estándares de interfaces y protocolos.

Compleción. El grado con que se ha logrado la implementación total de una función.

Complejidad. Valoración del grado de complejidad del componente / función.

Concisión. Lo compacto que es el programa en términos de líneas de código.

Consistencia. El empleo de un diseño uniforme y de técnicas de documentación a lo largo del proyecto dedesarrollo del software.

Estandarización de datos. El empleo de estructuras y tipos de datos estándares a lo largo del programa.

Tolerancia al error. El daño causado cuando un programa encuentra un error.

Eficiencia de ejecución. El rendimiento del funcionamiento de un programa.

Capacidad de expansión. El grado con que se pueden ampliar el diseño arquitectónico, de datos oprocedimental.

26




Generalidad. La amplitud de aplicación potencial de los componentes del programa.

Independencia del hardware. El grado con que se desacopla el software del hardware donde opera.

Instrumentación. El grado con que el programa vigila su propio funcionamiento e identifica los errores queocurren.

Modularidad. La independencia funcional de componentes de programa.

Operatividad. La facilidad de operación de un programa.

Seguridad. La disponibilidad de mecanismos que controlan o protegen los programas y los datos.

Autodocumentación. El grado en que el código fuente proporciona documentación significativa.

Simplicidad. El grado de facilidad con que se puede entender un programa.

Independencia del sistema software. El grado de independencia de programa respecto a lascaracterísticas del lenguaje de programación no estándar, características del sistema operativo y otrasrestricciones del entorno.

Trazabilidad. La capacidad de seguir una representación del diseño o un componente real del programahasta los requisitos.

Formación (Entrenamiento). El grado en que ayuda el software a manejar el sistema a los nuevosusuarios.

27



28




Las relaciones entre los factores de calidad y los criterios son las siguientes:

A. Corrección = (C1 * CM) + (C2 * CS) + (C3 * TZ)

B. Fiabilidad = (C1 * EX) + (C2 * CX) + (C3 * CS) + (C4 * TE) + (C5 * MD) + (C6 * SM)

C. Eficiencia = (C1 * CN) + (C2 * EE) + (C3 * OP)

D. Seguridad (Integridad) = (C1 * FA) + (C2 * IN) + (C3 * SG)

E. Usabilidad (Facilidad de uso) = (C1 * OP) + (C2 * FM)

F. Facilidad de mantenimiento = (C1 * CN) + (C2 * CS) + (C3 * IN) + (C4 * MD) + (C5 * AD) + (C6 * SM)

G. Flexibilidad = (C1 * CX) + (C2 * CN) + (C3 * CS) + (C4 * CE) + (C5 * GE) + (C6 * MD) + (C7 * AD) + (C8 * SM)

H. Facilidad de Pruebas = (C1 * FA) + (C2 * CX) + (C3 * IN) + (C4 * MD) + (C5 * AD) + (C6 * SM)

I. Portabilidad = (C1 * GE) + (C2 * IH) + (C3 * MD) + (C4 * AD) + (C5 * SM)

J. Reusabilidad = (C1 * GE) + (C2 * IH) + (C3 * MD) + (C4 * AD) + (C5 * IS)

K. Interoperatividad = (C1 * EC) + (C2 * ED) + (C3 * GE) + (C4 * MD)

29




Criterio: Generalidad (GE--Generality)Métrica 1. GE.1: UR Unit ReferencingMétrica 2. GE.2: UI Unit Implementation

Criterio: Independencia de la Aplicación (AP--Application Independence)Métrica 1. AP.3: AS Architecture Standardization

Criterio: Modularidad (MO--Modularity)Métrica 1. MO.1: MI Modular Implementation

Criterio: Auto Descriptividad (SD--Self-Descriptiveness)Métrica 1. SD.2: EC Effectiveness of Comments

Tomadas del Reporte Técnico de la Federal Aviation Administration Technical Center.(página 246 del archivo digital).

Indican cuáles son las métricas a tener en cuenta para valorar los atributos que conforman la reusabilidad.

30




A modo de guía se muestran las especificaciones de 2 métricasasociadas a 2 criterios diferentes:

Criterio: Independencia de la AplicaciónMétrica 1. AP.3: Estandarización de la Arquitectura (AS)

REGLA:

Para cada módulo de un CSCI (Computer Software Configuration Item), responda la pregunta:

"Cuántas líneas de código no-HOL (High Order Language) hay en el módulo?” (ejemplo de no-HOL es el lenguaje ensamblador).

"Divida la cantidad de líneas de código no-HOL entre la cantidad total de líneas de código." (Bowen, Wigle y Tsai 1985).

RANGO: Esta métrica genera un número real entre cero y uno.

INTERPRETACIÓN: Los valores “útiles” para este atributo son los que se acerquen más a cero.

cantidad de líneas de código no-HOL en el módulo

cantidad total de líneas de código fuente del móduloAS

31




Criterio: Independencia de la AplicaciónMétrica 1. AP.3: Estandarización de la Arquitectura (AS)

La razón de fijarse en lenguaje que no sea HOL es que esos lenguajes son

dependientes de la máquina y en la medida que haya una menor cantidad de

esas líneas, esto aumenta la valoración del atributo y por consiguiente podría

incidir en un aumento de la reusabilidad.

Aporte: para ratios como este cuyos valores “buenos” para la reusabilidad

son los que se acercan a cero, habría necesidad de efectuar un cálculo como

este: ASr = 1 – AS. De modo que cuando el valor de AS se acerque más a

cero, el valor de ASr será más cercano a 1 de modo que todas las métricas

se puedan llevar a valores con sentido positivo (o creciente) y se puedan

llevar todas a una expresión general para cuantificar la reusabilidad.

32




Criterio: Auto DescriptividadMétrica 1. SD.2: Efectividad de los Comentarios (EC)

REGLA:

Para cada módulo de un CSCI, responda la pregunta:

"¿Tiene comentario de encabezado que contenga toda la información acorde conel estándar establecido?” (Bowen, Wigle, and Tsai 1985).

Divida el total de respuestas afirmativas entre el número de módulos que se estén evaluando.

RANGO: Esta métrica genera un número real entre cero y uno.

INTERPRETACIÓN: Los valores “útiles” para este atributo son los que se acerquen más a 1.

cantidad de módulos concomentarios que cumplenestándar

ECcantidaddemódulos evaluados

33




Criterio: Auto DescriptividadMétrica 1. SD.2: Efectividad de los Comentarios (EC)

La razón de fijarse en que los comentarios cumplan con unestándar establecido es que podrían facilitar la comprensión de loque hace el módulo. Esto aumenta la valoración del atributo ya quesi se puede comprender, se puede evaluar con menos dificultad sise podría re-usar, y por consiguiente podría incidir en un aumentode la reusabilidad.

Aporte: para ratios como este cuyos valores “buenos” para lareusabilidad son los que se acercan a 1, no hay necesidad decalcular una expresión adicional como se hizo con la métricaanterior.

34




Cuantificación de la Reusabilidad. Aún teniendo en cuenta loexpresado, ahora se plantea una primera aproximación para calcularun valor (o probabilidad) para la reusabilidad, a partir de las 2métricas revisadas:

REUSABILIDAD = (C1 * ASr) + (C2 * EC).

De esta manera el rango de valores resultantes está entre 0 y 1.

Ci son coeficientes de regresión ( C1 + C2 = 1.0 ) que representan laponderación o el “peso” que se le podría asignar a cada métrica si secree que alguna de ellas podría tener una mayor incidencia en lacuantificación de la reusabilidad.

De no ser así, en este ejemplo C1 = C2 = 0.5.

35




Generalizando, se muestra una expresión que podría cuantificar unavaloración para “Reusabilidad”:

Por lo tanto, se muestran los símbolos originales, ya que no se tieneforma de saber cuáles de ellas tienen “valores buenos” cerca de cero.

REUSABILIDAD = (C1 * UR) + (C2 * UI) + (C3 * ASr) + (C4 * MI) + (C5 * EC)

Ci son coeficientes de regresión ( C1 + C2 + C3 + C4 + C5 = 1.0 )

Si la ponderación es equitativa Ci = 0.2

36

-------------------- FIN DEL DOCUMENTO


guía 08. medición de software...

Documents