PDF de programación - Tema 2 - Métricas y Modelos de Estimación del Software

TEMA 2

METRICAS Y MODELOS DE ESTIMACION DEL SOFTWARE



2.1



Introducción a las métricas del software

El término “Métricas del Software” comprende muchas actividades, todas ellas

relacionadas de alguna manera con la idea de mejorar la calidad del software. Cada

una de esas actividades ha evolucionado por sus propios medios dentro de un

dominio más amplio que las abarca a todas: la Ingeniería del Software [Fenton -

Pfleeger, 1996]

Entre estas actividades se pueden incluir las siguientes:



• Medidas y modelos de estimación de costes y esfuerzo
• Medidas y modelos de productividad
• Recogida de datos
• Medidas y modelos de calidad
• Modelos de fiabilidad
• Modelos y evaluación del rendimiento
• Métricas de la estructura y la complejidad
• Modelos de madurez
• Gestión a través de las métricas
• Evaluación de métodos y herramientas


Nuestro objetivo es revisar las métricas asociadas a estas actividades presentándolas,

en la medida de lo posible, en dos grandes grupos: métricas basadas en el código y

métricas basadas en el diseño y en las especificaciones. Asimismo, y por ser

especialmente relevante para los casos de estudio de esta tesis, se hace mención a

una serie de métricas específicas para programas COBOL. Y para finalizar con las

métricas más actuales, se estudian algunas de las más relevantes especialmente

diseñadas para programación orientada a objetos.

__________________________________________________________________________________________
Herramientas de Gestión de Proyectos Serafín Caridad Simón



2.1




Por último, para completar el estudio del estado actual de las métricas del software y

del control de calidad, se presentan en este capítulo los marcos más importantes de

medida, así como los principales estándares asociados.


2.1.1 Métricas basadas en el código



Los primeros intentos que se realizaron para medir la calidad del software

condujeron al desarrollo de una serie de métricas basadas casi exclusivamente en el

código de los programas. De esta primera época destacaremos las Líneas de Código,

la Ecuación de Putnam, Software Science, la Complejidad Ciclomática, las Métricas

Híbridas y los Modelos Cocomo. Estas métricas de la primera etapa se estudian a

continuación.

2.1.1.1 Líneas de Código



Aunque el tamaño de una aplicación software se puede medir utilizando unidades de

medida muy diversas (número de módulos de los programas, número de páginas de

los listados del código “fuente”, número de rutinas, etc.), el código de los programas

ha sido, originalmente, la principal fuente de medida del software y casi todas las

métricas de esta primera etapa de intentos de medir el software se basan

exclusivamente en el código. Así, entre las primeras métricas que se utilizaron para

predecir la fiabilidad y la complejidad de las aplicaciones se encuentran las líneas de

código (LOC: Lines Of Code) Está métrica, por su simplicidad y por la dificultad

que representa definir qué es una línea de código, ha sido criticada severamente por

diferentes autores [McCabe 1976, DeMarco 1982] En efecto, al intentar usar LOC

como medida, surge de inmediato la duda sobre qué es lo que se debe de considerar

como una línea de código. Es necesario decidir, por ejemplo, si una línea de código

es la línea escrita en un lenguaje de alto nivel, o por el contrario es una línea de

código máquina, ya que hay que tener en cuenta que una línea de código escrita en

un lenguaje de alto nivel se puede convertir en múltiples líneas de código máquina.

Si consideramos que el código máquina es el que ejecuta el ordenador se podría

__________________________________________________________________________________________
Herramientas de Gestión de Proyectos Serafín Caridad Simón



2.2





argüir que éstas son las LOC a considerar. Sin embargo, lo que escribe el

programador son las líneas en el lenguaje de alto nivel, y no tiene por que

enfrentarse a la dificultad del código máquina.

En 1981, Boehm propone [Boehm, 1981] el uso de líneas de código “fuente”

expresadas en miles (KLOC: Kilo-Lines Of Code) y en 1983, Basili y Hutchens

[Basili - Hutchens, 1983] sugieren que LOC debe de considerarse como una métrica

de base, contra la que se deben de comparar las demás métricas, por lo que sería de

esperar que cualquier métrica efectiva se comportase mejor que LOC, y que, en

cualquier caso, LOC ofreciese una “hipótesis nula” para evaluaciones empíricas de

las diferentes métricas del software.

No obstante, para que la aplicación de las métricas basadas en el código sea efectiva,

es necesario definir claramente el concepto de línea de código. Según Fenton y

Pfleeger, la definición más extendida es la que establece Hewlett-Packard:

“cualquier sentencia del programa, excluyendo las líneas de comentarios y las líneas

en blanco” [Fenton - Pfleeger, 1996] Esta definición permite contar las líneas de

código de una forma fácil y de una manera uniforme, independientemente del

lenguaje de programación empleado.

2.1.1.2 La Densidad de Defectos



La métrica más comúnmente utilizada para medir la calidad del software es la

densidad de defectos, que se expresa como:

Número de defectos descubiertos

Tamaño del código

Donde el tamaño normalmente se expresa en miles de líneas de código.



Aunque esta métrica correctamente utilizada puede constituir un indicador útil

de la calidad del software, no puede considerarse como una medida de la calidad

__________________________________________________________________________________________
Herramientas de Gestión de Proyectos Serafín Caridad Simón



2.3





en un sentido estricto. De hecho, existen una serie de problemas conocidos y

bien documentados sobre esta métrica, destacando en particular los siguientes:

•

Es más bien un indicador de la severidad de las pruebas que de la

calidad del software



•

No existe un consenso generalizado de lo que es un defecto. Puede

considerarse como defecto un fallo del software descubierto durante las

pruebas (que potencialmente puede convertirse en un fallo en tiempo de

operación) o un fallo descubierto durante la ejecución de la aplicación. En

algunos casos se considera un defecto el encontrado después de que la

aplicación ha superado las pruebas y está siendo utilizada por el usuario

final, en otros casos un defecto se refiere a cualquier tipo de fallo

conocido, en otros a un error descubierto en una fase en concreto del ciclo

de vida del software, etc. La terminología varía mucho dependiendo del

tipo de organización que la emplee; normalmente los términos tasa de

fallos, densidad de fallos, ratio de errores se utilizan indistintamente.

•

El tamaño se utiliza solo como una medida subrogada del tiempo.

Por ejemplo, para fallos en tiempo de operación, la ratio de errores se

debería de basar en el tiempo medio entre fallos, proporcionando una

medida precisa de la fiabilidad del software, que es la interesante desde el

punto de vista del usuario final.

•

No existe un consenso sobre cómo medir el software de un modo

consistente y comparable. Aún empleando Líneas de Código (o kilo-líneas

de código) para el mismo lenguaje de programación, las desviaciones en

las reglas empleadas para contar pueden originar variaciones en un factor

de 1 a 5.

__________________________________________________________________________________________
Herramientas de Gestión de Proyectos Serafín Caridad Simón



2.4





A pesar de estos problemas conocidos, la densidad de defectos se ha convertido

en un estándar “de facto” en las empresas a la hora de medir la calidad del

software, aunque, por razones obvias, no suelen publicarse los resultados,

aunque la densidad de defectos sea relativamente baja.

Uno de los informes más reveladores [Daskalantonakis, 1992] afirma que el objetivo

de calidad Sigma Seis de Motorola, es tener “no más de 3.4 defectos por millón de

unidades de salida en un proyecto”. Esto implica una densidad de defectos

excepcionalmente baja de 0,0034 defectos por cada mil líneas de código. El informe

parece sugerir que, en 1990, la densidad de defectos media se encontraba entre 1 y 6

defectos por cada mil líneas, con una fuerte tendencia a disminuir.

2.1.1.3 La Ecuación de Putnam



Otra de las métricas basadas en el código fue propuesta por Putnam, quien por

medio de un estudio de datos, desarrolla un modelo para la estimación del

tamaño y el esfuerzo necesario para el desarrollo de productos software [Putnam,

1978] Putnam define una ecuación para estimar el tamaño (T) del software,

expresado en líneas de código:



T= C * K1/3