Las métricas del Software se refieren a un amplio elenco de medidas para el Software de

computadora. La medición se puede aplicar al proceso de Software con el intento de mejorarlo

sobre una base continua.

Podemos definir las Métricas de Software o Medidas de Software como:

La aplicación continúa de técnicas basadas en las medidas de los procesos de desarrollo de

Software y sus productos, para producir una información de gestión significativa y a tiempo. Esta
información se utilizará para mejorar esos procesos y los productos que se obtienen de ellos.

Las Métricas de Software implican medir: medir involucra números; el uso de números para hacer
cosas mejor. Las Métricas de Software pretenden mejorar los procesos de desarrollo de Software y
mejorar, por tanto, todos los aspectos de la gestión de aquellos procesos.

Estas medidas son aplicables a todo el ciclo de vida del desarrollo, desde la iniciación, cuando
debemos estimar los costos, al seguimiento y control de la fiabilidad de los productos finales, y a la
forma en que los productos cambian a través del tiempo debido a la aplicación de mejoras.

Las medidas del Software y los modelos de medida son entonces útiles para estimar y predecir
costos y para medir la productividad y la calidad del producto. Un ingeniero del Software recopila
medidas y desarrolla métricas para obtener indicadores.

Áreas de Aplicación

Algunas de las áreas donde se aplican las métricas de Software son:

El control de proyectos de desarrollo de Software a través de medidas en un área que esta

generando un gran interés. Este es un tema que ha alcanzado un interés relevante con el
incremento de contratos a precio fijo para desarrollar un producto Software y la utilización de
cláusulas de penalización en los mismos en caso de retrasos, sobrecostos, etc.

La predicción de los niveles de calidad del Software, a menudo en términos de fiabilidad, es otra
área en que las Métricas de Software tienen un importante papel que jugar.

El uso de las Métricas de Software es proporcionar una verificación cuantitativa del diseño de
software es otra área bien definida. Estas Métricas no se van a estudiar en esta Unidad si no en la
Unidad de Diseño.

Recientemente se ha estudiado el efecto de los factores del entorno en la eficacia de los procesos
de desarrollo. Esta opción no está abierta para todas las organizaciones, pero existe una gran
preocupación sobre como incrementar la productividad de los procesos de desarrollo
introduciendo cambios en el entorno en el cual aquellos tienen lugar. Las medidas pueden ser
utilizadas para identificar donde deberían concentrarse los cambios.

La utilización de las Métricas para comprar unas organizaciones con otras es un área de aplicación
muy importante. CSC- Index en Europa y el Software Engineering Institute en E.E.U.U. ofrecen este
tipo de servicios a la industria y muchas organizaciones los utilizan. Un resultado de esta aplicación
es que se puede identificar que se está haciendo mal y quién lo está haciendo bien y aprender de
esas empresas.
Finalmente, el uso más común de las medidas de Software es la provisión de información de
gestión, que incluye datos acerca de la productividad, calidad y eficacia de los procesos.

El valor de esta información está en analizar los datos de las tendencias, día a día. ¿Está mejorando
o empeorando la calidad de un equipo de desarrollo?. Si es así, ¿por qué ocurre? ¿Qué puede
hacer la dirección para mejorar la situación?

Características de las Métricas de Software

La calidad de las medidas debería facilitar el desarrollo de modelos que sean capaces de predecir
el comportamiento de determinados parámetros que afectan al desarrollo de productos o
procesos.

Una medida ideal debería ser:

Objetiva

Sencilla, definible con precisión para que puede ser evaluada

Fácilmente obtenible (a costo razonable)

Valida, la métrica debería medir exactamente lo que se quiere medir y no otra cosa.

Robusta. Debería de ser relativamente insensible a cambios poco insignificativos en el proceso o

en el producto.

Además, para una mejor utilización de estas medidas, a la hora de realizar estudios analíticos o
análisis estadísticos deberían de tener unos valores que se ajusten a una cierta escala de medida.

Clasificación de las Métricas de Software

Las Métricas de Software se pueden clasificar, de una manera general. En Métricas de producto y
Métricas de proceso.

Las Métricas de Producto son medidas de producto Software durante cualquier fase de su
desarrollo desde los requisitos hasta la instalación. Las Métricas de Producto pueden medir la
complejidad del diseño, el tamaño del producto final (fuente u objeto) o el número de páginas de
documentación producida.

Las Métricas de Proceso son medidas del proceso de desarrollo del Software tales como tiempo
de desarrollo total, esfuerzo en días/ hombre o mes / hombre de desarrollo del producto, tipo de
metodología utilizada o nivel medio de experiencia de los programadores.

Métricas de Productos

Muchos de los trabajos iniciales realizados sobre las métricas de producto están relacionados con
las características del código fuente. Conforme se ha ido ganando experiencias con las métricas y
los modelos se ha puesto de manifiesto que la información disponible durante los primeros
momentos del ciclo de desarrollo puede ser de gran valor para controlar el proceso y los
resultados.
Vamos a analizar, de todos los tipos de medidas utilizadas en la medición del producto Software,
únicamente aquellas que nos interesen para realizar el proceso de estimación del Software, que
serán las métricas del tamaño, y en cierto grado las de calidad.

Métricas del tamaño

Las Métricas del Software orientadas al tamaño provienen de la normalización de las medidas de
`calidad y/o productividad considerando -el tamaño - del Software que se haya producido.

Existen un cierto número de Métricas que intentan cuantificar el tamaño del Software. La Métrica
más utilizada, líneas de código, tiene el inconveniente obvio de que sus valores no pueden ser
medidos hasta que el proceso de codificación ha finalizado. Los puntos de función, y los Bang de
De Marco tienen las ventajas de ser medibles durante los primeros pasos de desarrollo.

El estado actual en el estudio de las medidas del tamaño es:

Existe un cierto consenso en cuanto a las medidas de longitud, pero no en cuanto a las medidas de
las especificaciones o diseño.

Existen algunos trabajos de medición de las funcionalidades de las especificaciones (que se aplican
igualmente al diseño y a los programas)

Existen muy pocos trabajos en cuanto a la medida de la complejidad del problema a resolver.
Nótese que este concepto es distinto que el de complejidad computacional, por tanto el trabajo
hecho en esa área no sirve.

A continuación, vamos a analizar las medidas más utilizadas en la determinación del tamaño del
Software.

• Líneas de Código: La medida más utilizada de la longitud del código fuente de un programa es el
Número de Líneas de Código (Lines of Code en Inglés, abreviado LOC).

Sin embargo esta métrica puede calcularse de muchas maneras. Estas diferencias afectan ala
tratamiento de las líneas en blanco y las líneas de comentarios, las sentencias no ejecutables, las
instrucciones múltiples por línea y las múltiples líneas por instrucción. Además, deberían contarse
las líneas reusables del código

Cuando se intenta utilizar esta medida (líneas de código) en términos de productividad surgen dos
problemas.

◦ No se tiene en cuenta el concepto de reutilización.

◦ No se tiene en cuenta el concepto de costos fijos ni tareas que se desarrolla que no produce
instrucciones

• Especificación del Diseño La definición de medidas análogas a la longitud para las

especificaciones y los documentos de diseño no es fácil. Al comienzo del ciclo de vida, tales
documentos consisten en una infinidad de texto, grafos, diagramas matemáticos, y símbolos. La
naturaleza de aquellos dependerá en particular del estilo el método o la notación utilizada. Unas
especificaciones o un diseño, están compuestos por textos o diagramas, los cuales parecen
inmedibles con relación a la longitud.
Una medida que se ha utilizado para permitir las comparaciones es la del Número de Paginas. Sin
embargo, la unidad página no puede ser formalmente definida si se desea incluir textos y
diagramas.

• Predicción de la longitud: Existen una serie de modelos que veremos más adelante para la
predicción del costo que dependen de la habilidad para predecir la longitud ( NLOC) con exactitud
con la fase de definición de especificaciones del sistema a implantar.

Un modo intuitivo de predecir la longitud es obteniendo una relación entre la longitud de

diferentes productos obtenidos durante el ciclo de vida. En particular, una predicción de longitud,
se puede obtener considerando la relación ratio de expansión entre la longitud de las
especificaciones o del diseño y la longitud del Código en proyectos similares en los que se
mantienen datos.

Ha habido algunos intentos para establecer relaciones empíricas entre la longitud del código de
programas y la longitud de la documentación.

• Funcionalidad: El concepto de funcionalidad de un producto se origina a partir de una noción

intuitiva de cantidad de funciones que proporciona.

•Ha habido dos intentos serios para medir la funcionalidad de un producto de Software. Uno de
ellos se debe a Albrecht y corresponde a los Puntos de Función (FPA, del inglés Function Point
Análisis) y otro debido a de De Marco, los Bang, que no ha tenido una gran difusión.

El objetivo más importante es identificar una medida del tamaño de Software que pueda ser la
variable predominante en los sistemas de predicción de costos y esfuerzo, así como en la
evaluación de la productividad. Este es un objetivo encomiable, ya que una medida de la
funcionalidad sería claramente preferible a la medida del tamaño exclusivamente de la longitud.
En ambos casos, los productos cuya funcionalidad está siendo medida con documentos de
especificación, pero que podrían aplicarse posteriormente a otros productos del ciclo de vida. La
funcionalidad, a pesar de los problemas existentes, es un atributo muy importante del producto y
es la mejor aproximación existente hasta la fecha.

Métricas de Calidad

El objeto primordial de la ingeniería del Software es producir un sistema, aplicación o producto de

alta calidad. Para lograr este objetivo, los ingenieros del software deben aplicar métodos efectivos
con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del
Software. Se puede generar una larga lista de características de la calidad de Software: corrección,
eficacia, portabilidad, mantenibilidad, fiabilidad, etc. Desafortunadamente, las características a
veces se solapan y entran en conflicto unas con otras. Por ejemplo, incrementar la portabilidad,
que es muy deseable, puede dar lugar a una eficacia menor.

Aunque se han realizado una gran cantidad de trabajos en está área, presenta una gran variedad
en los caminos seguidos frente a otras áreas de investigación de las métricas, tales como el
tamaño del Software o la complejidad, cuyo estudio ha sido más uniforme.
Han tenido considerable atención tres áreas:

Corrección de los programas, medida como el número de efectos. Un programa debe operar
correctamente o proporcionará poco valor a sus usuarios. La corrección es el grado en el que el
Software lleva a cabo su función requerida.

Fiabilidad del Software, calculada partir del dato anterior. En está época de intrusos informáticos y
de virus, la integridad del software ha llegado ha tener mucha importancia. Este atributo mide la
habilidad de un sistema para resistir ataques ( tanto accidentales como intencionales ) contra su
seguridad. El ataque se puede realizar en cualquiera de los tres componentes del Software,
programas, datos, y documentos.

Mantenibilidad del Software, que se mide a partir de otro conjunto de métricas, incluidas las de
complejidad: La facilidad de mantenimiento es la facilidad con la que se puede corregir un
programa si se encuentra un error, se puede adaptar si su entorno cambia, o mejorar si su cliente
desea un cambio de requisitos.

La calidad del software es una característica que, teóricamente al menos, puede ser medida en
cada fase del ciclo de desarrollo del Software.

Métricas de Procesos

Estas métricas evalúan el proceso en sí de fabricación del producto correspondiente. Ejemplos de

este tipo de métricas son el tiempo de desarrollo del producto, el esfuerzo que conlleva dicho
desarrollo, el número y tipo de recursos empleados (personas, máquinas, etc) el costo del proceso.
La obtención de este tipo de métricas esta asociada generalmente a alguna técnica de estimación.
En el siguiente tema describiremos las técnicas básicas de estimación, y los métodos que se
pueden aplicar.

Integración de las Métricas dentro del Proceso de Software

La mayoría de los desarrolladores de Software todavía no miden, y por desgracia, la mayoría no

desean ni comenzar.

¿Por qué es tan importante medir el proceso de ingeniería de Software y el producto (Software)
que produce?. La respuesta es relativamente obvia. Si no se mide, no hay una forma real de
determinar sí se está mejorando. Y si no se está mejorando, se está perdido.

Mediante el uso de la medición para establecer una línea base del proyecto, cada uno de estos
asuntos se hace más fácil de manejar. Ya hemos apuntado que la línea base sirve como base de la
estimación. Además, la recopilación de métricas de calidad permite a una organización -sintonizar-
su proceso de ingeniería del Software para eliminar las causas - poco vitales- de los defectos que
tienen el mayor impacto en el desarrollo del Software.

MÉTRICAS PARA EL MODELO DE REQUERIMIENTOS

El trabajo técnico en la ingeniería del software comienza con la creación del modelo de
requerimientos. En esta etapa se derivan los requerimientos y se establece un cimiento para el
diseño. Por tanto, son deseables métricas de producto que proporcionen comprensión acerca de
la calidad del modelo de análisis.

Métrica basada en funciones

La métrica de punto de función (PF) puede usarse de manera efectiva como medio para medir la
funcionalidad que entra a un sistema. Al usar datos históricos, la métrica PF puede entonces
usarse para:

1) Estimar el costo o esfuerzo requerido para diseñar, codificar y probar el software; 2) predecir el
número de errores que se encontrarán durante las pruebas, y 3) prever el número de
componentes y/o de líneas fuente proyectadas en el sistema implementado.

MÉTRICAS PARA EL MODELO DE DISEÑO.

Las métricas de diseño para software de computadora, al igual que todas las demás métricas de
software, no son perfectas. El debate continúa acerca de su eficacia y sobre la forma en la que
deben aplicarse. Muchos expertos argumentan que se requiere más experimentación antes de
poder usar las medidas de diseño, aunque el diseño sin medición es una alternativa inaceptable.

Métricas del diseño arquitectónico.

Las métricas del diseño arquitectónico se enfocan en características de la arquitectura del

programa con énfasis en la estructura arquitectónica y en la efectividad de los módulos o
componentes dentro de la arquitectura. Dichas métricas son “caja negra” en tanto no requieren
conocimiento alguno del funcionamiento interior de un componente de software particular.

Card y Glass definen tres medidas de complejidad del diseño de software: complejidad estructural,
complejidad de datos y complejidad del sistema.

Métricas para diseño orientado a objetos.

En un tratamiento detallado de las métricas de software para sistemas OO, describe nueve
características distintas y mensurables de un diseño OO:

Tamaño. El tamaño se define en función de cuatro visiones: población, volumen, longitud y

funcionalidad. La población se mide al realizar un conteo estático de entidades OO, tales como
clases u operaciones

Complejidad. Como el tamaño, existen muchas visiones diferentes de la complejidad del software.
Whitmire ve la complejidad en términos de características estructurales al examinar cómo se
relacionan mutuamente las clases de un diseño OO.

Suficiencia. “el grado en el que una abstracción posee las características requeridas de él o en el
que un componente de diseño posee características en su abstracción, desde el punto de vista de
la aplicación actual”.

Completitud. La única diferencia entre completitud y suficiencia es “el conjunto de características

contra las cuales se compara la abstracción o el componente de diseño”.
Cohesión. Como su contraparte en software convencional, un componente OO debe diseñarse de
manera que tenga todas las operaciones funcionando en conjunto para lograr un solo propósito
bien definido.

Primitivismo. Una característica que es similar a la simplicidad, el primitivismo (aplicado tanto a

operaciones como a clases), es el grado en el que una operación es atómica, es decir, la operación
no puede construirse a partir de una secuencia de otras operaciones contenidas dentro de una
clase.

Similitud. El grado en el que dos o más clases son similares en términos de su estructura, función,
comportamiento o propósito se indica mediante esta medida.

Volatilidad. Como se menciona muchas veces en este libro, los cambios en el diseño pueden
ocurrir cuando se modifican los requerimientos o cuando ocurren modificaciones en otras partes
de una aplicación, lo que da como resultado la adaptación obligatoria del componente de diseño
en cuestión.

Métricas de diseño en el nivel de componente

Las métricas de diseño en el nivel de componente para componentes de software convencional se

enfocan en las características internas de un componente de software e incluyen medidas de
cohesión de módulo, acoplamiento y complejidad. Dichas medidas pueden ayudarlo a juzgar la
calidad de un diseño en el nivel de componente.

Las métricas de diseño en el nivel de componente pueden aplicarse una vez desarrollado el diseño
procedural y son “cajas de cristal” en tanto requieren conocimiento del funcionamiento interior
del módulo en el que se está trabajando. Alternativamente, pueden demorarse hasta que el
código fuente esté disponible.

Métricas de acoplamiento. El acoplamiento de módulo proporciona un indicio de cuán

“conectado” está un módulo con otros módulos, con datos globales y con el entorno exterior.