Métricas básicas: el tamaño del software

Antes de empezar a revisar las diferentes tipologías de métricas es necesario saber cómo medir el tamaño de un software, ya que se trata de una métrica base que utilizaremos en otras métricas.

El tamaño de un software puede definirse según el número de líneas de código o sus puntos función.

4.4.1. Líneas de código

La métrica de líneas de código contabiliza el número de líneas que tiene un programa. Si bien este concepto puede parecer muy simple, tiene diferentes interpretaciones.

El texto del código de un programa lo podemos dividir en líneas físicas, que se pueden clasificar en:

• Líneas en blanco. • Líneas de comentarios.

• Líneas de sentencia. Declaraciones o definiciones de datos, una sentencia simple ejecutable o una sentencia compuesta. Por lo tanto, una línea de sentencia puede incluir varias sentencias.

Las diferentes interpretaciones asociadas a las líneas de código se describen de acuerdo con la combinación de las diferentes clasificaciones anteriores: • Líneas�físicas�de�código. Incluye todos los tipos de líneas.

• Líneas�efectivas�de�código�o�líneas�de�código�sin�comentarios.

Conta-biliza todas las líneas que no estén en blanco y no sean líneas exclusivas de comentario.

• Líneas�lógicas�de�código. Contabiliza cada una de las sentencias.

• Líneas�comentadas�de�código. Contabiliza las líneas de código que tienen

uno o más comentarios.

Debido a las diferentes interpretaciones posibles, siempre que usemos esta métrica para calcular otras métricas tendremos que ser muy explí-citos, indicando si consideramos líneas físicas, efectivas, lógicas o co-mentadas.

Ejemplo de los tipos de líneas

Veamos con un ejemplo de código cada uno de los tipos de líneas descritas. En la tabla se marca una "X" cuando se encuentra en el código uno de los tipos de líneas establecidos. Por ejemplo, la línea int puntos=0; int iCnt=0 incluye dos sentencias y, por lo tanto, dos líneas lógicas.

  Líneas

físicas efectivas^Líneas lógicas^{Líneas Líneas co-}mentadas

/* Cálculo de los puntos de

fidelización del VCV */ ^{X     X}

public int

calculaPuntos(double anIm-port) {

X X X  

int punts= 0; int iCnt = 0; X X XX (2)  

  X      

if (anImport>=100 &&

anIm-port<300) { //un comentario ^{X X X X}

// dar 2 puntos X     X puntos = 2; X X X   } else { X X X   puntos = 0; X X X   } X X X   retorno puntos; X X X   } X X X   TOTAL 12 9 10 3 Tasa de comentarios       3/13 = 25%

Una métrica bastante interesante derivada de las anteriores es la tasa de co-mentarios, que nos indica cómo se encuentra comentado el código:

El número de líneas suele asociarse a la complejidad del software, ya que en la práctica será más costoso desarrollar un programa de muchas líneas que uno pequeño, y será más difícil mantenerlo. Sin embargo, es importante tener en cuenta que las líneas de código no se pueden considerar en ningún caso co-mo una medida de eficiencia de los desarrolladores. Habrá programadores que pueden construir la misma funcionalidad con menos código o aplicar estruc-turas de reutilización, y, en ese caso, el código seguramente será más fácil de entender y mantener (y menos complejo).

La métrica de líneas de código está en ciertos aspectos cuestionada, ya que: • Es poco útil cuando se quiere comparar la complejidad de programas que

se han escrito en diferentes lenguajes de programación, ya que el mismo algoritmo puede ser implementado en un lenguaje con menos líneas que otro (no por la habilidad del programador, sino por lo que ofrecen los lenguajes y su nivel de detalle).

• No hay consenso sobre cómo se calculan determinados casos. Cuando usa-mos una librería en el proyecto ¿teneusa-mos que sumar las líneas de código de esta librería? ¿Tenemos que contar las líneas del sistema operativo? • Depende del estilo de programación utilizado. Por ejemplo, en nuestro

código ejemplo, las llaves de inicio de bloque se encuentran al final de la línea física, en lugar de encontrarse en una nueva línea. Si hubiésemos puesto las llaves en nuevas sentencias físicas, las métricas habrían variado. • Existen herramientas que generan código de forma automática. Este

códi-go generado automáticamente desvirtúa la métrica.

Muchas de estas problemáticas se resuelven con la utilización de la métrica puntos función.

4.4.2. Puntos función

El método de puntos función se basa en medir el tamaño del aplicativo según las funcionalidades en que se quiera desarrollar. Su ventaja es que permite calcular el tamaño de una aplicación antes de que se cree el código.

Los puntos función se pueden calcular en diferentes momentos del proyecto según el conocimiento que se vaya obteniendo de él. En las fases iniciales ob-tendremos un valor en el que ob-tendremos que incluir un pequeño margen de error, mientras que en fases más avanzadas, por ejemplo cuando se haya com-pletado el análisis, obtendremos un valor más preciso. Aunque no se disponga de requerimientos muy formales, se puede hacer una aproximación de forma sencilla. El método permite comparar el tamaño de diferentes aplicaciones sin importar el lenguaje de programación utilizado en cada una de ellas.

El proceso de cálculo de puntos función incluye los siguientes pasos:

1) De acuerdo con el documento de requisitos, identificar los siguientes tipos

de componentes:

a)�Número�de�entradas�de�usuario: número de datos de usuario o

compo-nentes de control de entrada diferentes en el sistema (datos de entrada, pro-cesos batch...).

b)�Número�de�salidas�de�usuario: número de datos de usuario o componentes

de control de salida diferentes (informes, listados...).

c)�Número�de�consultas�de�usuario: número de operaciones en las que un

usuario introduce unos datos de entrada y obtiene al momento unos datos de respuesta.

d)�Número�de�ficheros�lógicos�internos: número de entidades del modelo

de datos.

e)�Número�de�interfaces�externas: número de ficheros intercambiados entre

sistemas.

2) Analizar la complejidad de cada uno de los tipos anteriores y clasificarlos

en simples, medios o complejos.

3) Para cada nivel de complejidad y tipo de elemento (entradas, salidas,

cam-pos a procesar...) se establece un factor de ponderación, y según la tabla si-guiente se calcula el número total de puntos función sin ajustar:

La suma del número de los diferentes elementos con su factor nos da el valor de lo que se denomina puntos�función�sin

ajustar (PFSA).

4) A continuación se calcula el factor de ajuste de complejidad relativa del

proyecto, teniendo en cuenta elementos que pueden variar el esfuerzo, valo-rándolos en un grado de 0 a 5:

Factor Grado (0-5)

Requisitos de copias de confianza y recuperación   Requisitos de comunicación de datos  

Alcance de proceso distribuido  

Factor Grado (0-5)

Entorno operacional esperado  

Alcance de las entradas en línea  

Alcance de multipantallas o entradas para varias operaciones   Alcance de actualización en línea de ficheros maestros   Alcance de entradas, salidas, consultas y ficheros complejos   Alcance de procesamiento complejo de datos   Alcance de cómo el código desarrollado actual puede ser diseñado

para ser reutilizado  

Alcance de funciones de conversión e instalación incluidas en el

dise-ño  

Alcance de múltiples instalaciones en la organización   Alcance de cambio y foco en la facilidad de uso  

Total�(FC) Suma�de�los�grados

5) Finalmente, ya podemos calcular el valor de los puntos función ajustados o puntos�función, teniendo en cuenta el valor obtenido de los puntos función

sin ajustar y el valor del factor de ajuste.

Existen diferentes estudios5 que han establecido factores de conversión para conocer cuántas líneas de código equivalen a un punto función en diferentes lenguajes de programación, con lo que, una vez construido el código, podre-mos valorar si nuestras estimaciones en el modelo puntos función han estado lo suficientemente próximas a la realidad.

Sin embargo, no tenemos que olvidar que, a partir de los puntos función y en combinación con otros modelos, como, por ejemplo, COCOMO II, podemos obtener el número de horas de esfuerzo en construcción necesarios para el desarrollo del aplicativo.