Líneas de código fuente

Las líneas de código fuente ( SLOC ), también conocidas como líneas de código ( LOC ), es una métrica de software
utilizada para medir el tamaño de un programa de computadora contando el número de líneas en el texto del código
fuente del programa . El SLOC se usa generalmente para predecir la cantidad de esfuerzo que se requerirá para
desarrollar un programa, así como para estimar la productividad o la capacidad de mantenimiento de la programación
una vez que se produce el software.

Métodos de medición
Muchas comparaciones útiles involucran solo el orden de magnitud de las líneas de código en un proyecto. Usar líneas
de código para comparar un proyecto de 10,000 líneas con un proyecto de 100,000 líneas es mucho más útil que cuando
se compara un proyecto de 20,000 líneas con un proyecto de 21,000 líneas. Si bien es discutible exactamente cómo
medir líneas de código, las discrepancias de un orden de magnitud pueden ser indicadores claros de la complejidad del
software o de las horas hombre .
Hay dos tipos principales de medidas de SLOC: SLOC físico (LOC) y SLOC lógico (LLOC). Las definiciones específicas
de estas dos medidas varían, pero la definición más común de SLOC físico es un recuento de líneas en el texto del
código fuente del programa, excluyendo las líneas de comentarios. [1]
El SLOC lógico intenta medir el número de "declaraciones" ejecutables, pero sus definiciones específicas están
vinculadas a lenguajes de computadora específicos (una medida SLOC lógica simple para lenguajes
de programación tipo C es el número de puntos y comas que terminan en enunciados). Es mucho más fácil crear
herramientas que midan el SLOC físico, y las definiciones de SLOC físico son más fáciles de explicar. Sin embargo, las
medidas físicas de SLOC son sensibles a las convenciones de estilo y formato lógicamente irrelevantes, mientras que las
SLOC lógicas son menos sensibles a las convenciones de estilo y formato. Sin embargo, las medidas SLOC a menudo
se establecen sin dar su definición, y el SLOC lógico a menudo puede ser significativamente diferente del SLOC físico.
Considere este fragmento de código C como un ejemplo de la ambigüedad encontrada al determinar SLOC:

para ( i = 0 ; i < 100 ; i ++ ) printf ( "hola" ); / * ¿Cuántas líneas de

código es esto? * /

En este ejemplo tenemos:

 1 línea física de código (LOC),

 2 líneas lógicas de código (LLOC) ( para la declaración y la declaración printf ),
 1 línea de comentarios
Dependiendo del programador y los estándares de codificación, la "línea de código" anterior podría escribirse en muchas
líneas separadas:

/ * Ahora, ¿cuántas líneas de código es esto? * /

for ( i = 0 ; i < 100 ; i ++ )
{
printf ( "hola" );
}

En este ejemplo tenemos:

 4 líneas físicas de código (LOC): ¿se estima que colocar llaves se estima?
 2 líneas lógicas de código (LLOC): ¿qué pasa con todo el trabajo escribiendo líneas sin enunciados?
 1 línea de comentario: las herramientas deben tener en cuenta todo el código y los comentarios,
independientemente de la ubicación de los comentarios.
Incluso los valores SLOC "lógicos" y "físicos" pueden tener una gran cantidad de definiciones variables. Robert E.
Park (mientras estaba en el Instituto de Ingeniería de Software ) y otros desarrollaron un marco para definir los
valores de SLOC, para permitir que las personas expliquen y definan cuidadosamente la medida de SLOC utilizada
en un proyecto. Por ejemplo, la mayoría de los sistemas de software reutilizan el código, y determinar qué código
reutilizado (si corresponde) incluir es importante al informar una medida.

Orígenes
En el momento en que las personas comenzaron a usar SLOC como una métrica, los lenguajes más utilizados,
como FORTRAN y lenguaje ensamblador , eran lenguajes orientados a líneas. Estos lenguajes se desarrollaron en
el momento en que las tarjetas perforadas eran la forma principal de entrada de datos para la programación. Una
tarjeta perforada generalmente representaba una línea de código. Era un objeto discreto que se contaba
fácilmente. Era la salida visible del programador, por lo que tenía sentido para los gerentes contar líneas de código
como una medida de la productividad de un programador, incluso refiriéndose a " imágenes de tarjeta " .". Hoy en
día, los lenguajes de computadora más utilizados permiten mucho margen de maniobra para el formateo. Las
líneas de texto ya no están limitadas a 80 o 96 columnas, y una línea de texto ya no corresponde necesariamente a
una línea de código.

Ventajas [ editar ]
1. Alcance para la automatización del conteo: dado que la línea de código es una entidad física, el esfuerzo de
conteo manual se puede eliminar fácilmente al automatizar el proceso de conteo. Se pueden desarrollar
pequeñas utilidades para contar el LOC en un programa. Sin embargo, una utilidad de conteo de código
lógico desarrollada para un idioma específico no se puede usar para otros idiomas debido a las diferencias
sintácticas y estructurales entre los idiomas. Sin embargo, se han producido contadores físicos de LOC que
cuentan con docenas de idiomas.
2. Una métrica intuitiva: la línea de código sirve como una métrica intuitiva para medir el tamaño del software
porque se puede ver y se puede visualizar su efecto. Se dice que los puntos de función son más una
métrica objetiva que no se puede imaginar como una entidad física, solo existe en el espacio lógico. De
esta manera, LOC es útil para expresar el tamaño del software entre los programadores con bajos niveles
de experiencia.
3. Medida ubicua: las medidas LOC han existido desde los primeros días del software [15] . Como tal, es
discutible que haya más datos LOC disponibles que cualquier otra medida de tamaño.
Desventajas [ editar ]
1. Falta de responsabilidad: la medida de líneas de código sufre algunos problemas
fundamentales. Algunos [ quien? ] piensan que no es útil medir la productividad de un proyecto utilizando solo
los resultados de la fase de codificación, que generalmente representa solo del 30% al 35% del esfuerzo
general. [ cita requerida ]
2. Falta de cohesión con la funcionalidad: aunque los experimentos [¿ por quién? ] han confirmado repetidamente
que si bien el esfuerzo está altamente correlacionado con LOC, la funcionalidad está menos correlacionada
con LOC. Es decir, los desarrolladores expertos pueden desarrollar la misma funcionalidad con mucho
menos código, por lo que un programa con menos LOC puede exhibir más funcionalidad que otro
programa similar. En particular, LOC es una medida de productividad pobre de las personas, porque un
desarrollador que desarrolla solo unas pocas líneas puede ser aún más productivo que un desarrollador
que crea más líneas de código, incluso más: algunas buenas refactorizaciones como "método de
extracción" código redundante y mantenerlo limpio reducirá principalmente las líneas de código.
3. Impacto adverso en la estimación: debido al hecho presentado en el punto n. ° 1, las estimaciones basadas
en líneas de código pueden salir negativamente, posiblemente.
4. Experiencia del desarrollador: la implementación de una lógica específica difiere según el nivel de
experiencia del desarrollador. Por lo tanto, el número de líneas de código difiere de persona a persona. Un
desarrollador experimentado puede implementar cierta funcionalidad en menos líneas de código que otro
desarrollador con relativamente menos experiencia, aunque use el mismo lenguaje.
5. Diferencia en idiomas: considere dos aplicaciones que proporcionan la misma funcionalidad (pantallas,
informes, bases de datos). Una de las aplicaciones está escrita en C ++ y la otra aplicación está escrita en
un lenguaje como COBOL. El número de puntos de función sería exactamente el mismo, pero los aspectos
de la aplicación serían diferentes. Las líneas de código necesarias para desarrollar la aplicación
ciertamente no serían las mismas. Como consecuencia, la cantidad de esfuerzo requerida para desarrollar
 la aplicación sería diferente (horas por punto de función). A diferencia de las líneas de código, el número de
puntos de función permanecerá constante.
6. Advenimiento de las herramientas GUI : con el advenimiento de los lenguajes de programación basados en
GUI y herramientas como Visual Basic , los programadores pueden escribir relativamente poco código y
lograr altos niveles de funcionalidad. Por ejemplo, en lugar de escribir un programa para crear una ventana
y dibujar un botón, un usuario con una herramienta GUI puede usar arrastrar y soltar y otras operaciones
del mouse para colocar componentes en un espacio de trabajo. El código generado automáticamente por
una herramienta GUI no suele tenerse en cuenta cuando se utilizan métodos de medición LOC. Esto da
como resultado una variación entre idiomas; La misma tarea que se puede hacer en una sola línea de
código (o ningún código) en un idioma puede requerir varias líneas de código en otro.
7. Problemas con varios idiomas: en el escenario de software actual, el software a menudo se desarrolla en
más de un idioma. Muy a menudo, se emplean varios idiomas dependiendo de la complejidad y los
requisitos. El seguimiento y la notificación de la productividad y las tasas de defectos plantean un problema
grave en este caso, ya que los defectos no pueden atribuirse a un lenguaje particular posterior a la
integración del sistema. El punto de función se destaca como la mejor medida de tamaño en este caso.
8. Falta de estándares de conteo: no existe una definición estándar de qué es una línea de código. ¿Cuentan
los comentarios? ¿Se incluyen las declaraciones de datos? ¿Qué sucede si una declaración se extiende
sobre varias líneas? - Estas son las preguntas que a menudo surgen. Aunque organizaciones como SEI e
IEEE han publicado algunas pautas en un intento de estandarizar el conteo, es difícil ponerlas en práctica
especialmente ante la introducción de nuevos y más nuevos idiomas cada año.
9. Psicología: un programador cuya productividad se mide en líneas de código tendrá un incentivo para
escribir código innecesariamente detallado. Cuanto más se centre la administración en las líneas de
código, más incentivo tendrá el programador para expandir su código con una complejidad
innecesaria. Esto no es deseable, ya que una mayor complejidad puede conducir a un mayor costo de
mantenimiento y un mayor esfuerzo requerido para la corrección de errores.
En el documental de PBS Triumph of the Nerds , el ejecutivo de Microsoft Steve Ballmer criticó el uso de líneas de
código de conteo:
En IBM hay una religión en el software que dice que tienes que contar K-LOC, y un K-LOC es mil líneas de
código. ¿Qué tan grande es un proyecto? Oh, es una especie de proyecto 10K-LOC. Este es un 20K-LOCer. Y esto
es 50K-LOCs. E IBM quería que fuera una religión sobre cómo nos pagaban. Cuánto dinero ganamos con OS / 2 ,
cuánto hicieron. ¿Cuántos K-LOC hiciste? Y seguimos tratando de convencerlos, oye, si es así, un desarrollador
tiene una buena idea y puede hacer algo en 4K-LOC en lugar de 20K-LOC, ¿deberíamos ganar menos
dinero? Porque ha hecho algo más pequeño y más rápido, menos K-LOC. K-LOC, K-LOC, esa es la
metodología. Ugh! De todos modos, eso siempre me arruga la espalda al pensar en todo el asunto.

https://en.wikipedia.org/wiki/Source_lines_of_code

https://www.geeksforgeeks.org/software-engineering-project-size-estimation-techniques/

http://eclases.tripod.com/id14.html
MÉTRICA DE PUNTO DE FUNCIÓN

La métrica de función es un método utilizado en Ingeniería de Software para medir el tamaño del software. Fue definida
por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la
tecnología utilizada para la construcción y explotación del software. Métodos para la métrica de Puntos de Función:
Método de Recuento: Consiste en asignar una cantidad de "puntos" a una aplicación informática según la complejidad
de los datos que maneja y de los procesos que realiza sobre ellos. Determinar el tipo de recuento Puede tratase de un
proyecto, una mejora a una aplicación o recontar una aplicación ya instalada. Según el tipo se incluirán funciones de
conversión, modificación y baja de funcionalidad. Identificar el alcance del recuento y los límites de la aplicación Se
delimita el alcance de lo que se va a medir. Contar las funciones de datos Se realiza un inventario de los ficheros lógicos
utilizados (vistos como un usuario) tanto internos de la aplicación como mantenidos por otra aplicación. Para cada uno
de ellos se recuenta el número de datos y de registros lógicos. En función de este número se calcula para cada fichero un
índice de complejidad y posteriormente una contribución en puntos función. Contar las funciones transaccionales De
modo similar se realiza un inventario de los procesos elementales del sistema, distinguiendo los procesos de entrada,
salida y consulta. Según el número de ficheros lógicos y datos que maneja cada proceso y de su naturaleza, se calcula su
índice de complejidad y su contribución en puntos función. Calcular el recuento bruto de puntos función A partir de los
recuentos anteriores se calcula un recuento total bruto (unadjusted). Determinar el factor de ajuste En función de 14
"características generales del sistema" que se valoran de 0 a 5 en función de su grado de influencia, se calcula un factor
de ajuste al recuento.

2. Estas características tienen que ver con la arquitectura de la aplicación, sus requisitos de carga y rendimiento,
complejidad de cálculos, etc.. Calcular el recuento ajustado Aplicando el factor de ajuste al recuento bruto se obtiene el
recuento final. MKII (Mark II) Desarrollada por KPMG en 1986 Definida y publicada por Charles Symons en 1991
Adoptada por la UKSMA (United Kingdom Software Metrics Association) Intenta ser un método de medición continua
a lo largo del ciclo de vida de una aplicación, frente a unas mediciones más estáticas del IFPUG-FPA. FFP (Full Function
Point) Desarrollada por COSMIC (Common Software Measurement International Consortium) Es una adaptación del
FPA con vistas al software real-time (equipos de telecomunicaciones, sistemas operativos y similares). NESMA FPA
(Netherlands Software Metrics Users Association Function Point Analysis) Desarrollada en Holanda Muy similar al
IFPUG-FPA

3. MÉTRICA DE LINEAS DE CÓDIGO LOC es un acrónimo de "Lines of Code". Se utiliza como métrica en diversas
situaciones, en las que se mide el número de líneas de código. Usualmente, se utiliza la variante "KLOC", que son miles
de líneas de código. Es fácil de medir. Pues sí, eso es cierto. Prácticamente cualquier entorno lo ofrece, y todos los
plugins de métricas lo ofrecen. Es fácil de combinar: muchas otras métricas pueden venir referidas a ella (Ejemplo: "nº
de defectos por cada mil líneas de código"). Ofrece una medida aproximada del tamaño de un software, y de su
complejidad. Pues vaya, esto también es cierto. Un programa de 1000 líneas no sé si será el doble de grande que otro de
500, pero más grande, sí. Sin embargo, en este mundillo se encuentran muchos argumentos en su contra: No es una
medida fiable de productividad personal. La respuesta obvia sería: "pues claro". En este mundillo de las métricas, uno
aprende que lo primero que hace un programador es ver en qué medida la métrica puede valorar su trabajo. Es el caso
típico de: "pensar mal". El problema es que las métricas están siempre para conocer el proyecto, y no siempre para ver
el rendimiento de las personas. Sin embargo, sí puede obtenerse (y se debe, de hecho) métricas del estilo: LOC totales
por persona, LOC modificadas por persona en un período, LOC nuevas por persona en un período, etc. Penaliza a
lenguajesde alto nivel. Toma, pues claro. Los lenguajes de alto nivel están para eso. Para que con menos líneas, se hagan
más cosas. Lo mismo que los frameworks y las librerías: para ahorrar líneas de código. Pero de nuevo volvemos a lo
mismo: esta métrica permite comparar sólo en el caso de que se pueda comparar. No podemos comparar solamente
lenguajes similares, sino proyectos en que la arquitectura sea equivalente. La complejidad de un software no depende
de su tamaño. Hay programas muy pequeños, endiabladamente retorcidos, mientras que hay otros muy grandes, pero
muy simples en concepción y ejecución. De nuevo, la respuesta es "pues claro". El problema es que una métrica no es
más que un número. Para obtener conclusiones, normalmente hay que usar varias métricas e indicadores de los
proyectos. El valor de una medida de codigo Las métricas de código son un conjunto de medidas de software que
proporcionan a los programadores una mejor visión del código que están desarrollando. Al aprovechar las métricas de
código, los programadores pueden entender qué tipos y métodos se deben rehacer o probar más a fondo. Los equipos
de desarrollo pueden identificar los riesgos potenciales, entender el estado actual de un proyecto y seguir el progreso
durante el desarrollo del software.

4. Medidas del software En la lista siguiente se muestran los resultados de las métricas de código que calcula Visual
Studio: Índice de mantenimiento: calcula un valor de índice entre 0 y 100 que representa la facilidad relativa de
mantenimiento del código. Un valor alto significa mayor facilidad de mantenimiento. Las calificaciones codificadas por
colores se pueden utilizar para identificar rápidamente puntos problemáticos del código. Una clasificación verde se
encuentra entre 20 y 100 e indica que el mantenimiento del código es bueno. Una clasificación amarilla se encuentra
entre 10 y 19 e indica que el mantenimiento del código es moderado. Una clasificación roja se encuentra entre 0 y 9 e
indica un mantenimiento pobre. Complejidad ciclomática: mide la complejidad estructural del código. Se crea
calculando el número de rutas de acceso del código diferente del flujo del programa. Un programa que tenga un flujo de
control complejo requerirá más pruebas para lograr una buena cobertura de código y será más difícil de mantener.
Profundidad de herencia: indica el número de definiciones de clase que se extienden a la raíz de la jerarquía de clases.
Cuanto más profunda es la jerarquía, más difícil puede ser entender dónde se definen y se vuelven a definir
determinados métodos y campos. Acoplamiento de clases: mide el acoplamiento a las clases únicas a través de
parámetros, variables locales, tipos de valores devueltos, llamadas a métodos, instancias genéricas o de plantillas, clases
base, implementaciones de interfaces, campos definidos en tipos externos y decoración de atributos. El buen diseño de
software sugiere que los tipos y métodos deben tener cohesión alta y acoplamiento bajo. Un acoplamiento alto indica
un diseño difícil de reutilizar y mantener debido a sus interdependencias en otros tipos. Líneas de código: indica el
número aproximado de líneas del código. El recuento se basa en el código IL y, por consiguiente, no representa el
número exacto de líneas en el archivo de código fuente. Un recuento muy alto podría indicar que un tipo o método
intenta hacer demasiado trabajo y debe dividirse. También puede indicar que el tipo o método podría ser difícil de
mantener. Métodos anónimos Un método anónimo es simplemente un método que no tiene ningún nombre. Los
métodos anónimos se utilizan con más frecuencia para pasar un bloque de código como parámetro delegado. Los
resultados de las métricas para un método anónimo declarado en un miembro, ya sea como método o como descriptor
de acceso, se asocian al miembro que declara el método. Código generado Algunas herramientas de software y
compiladores generan código que se agrega a un proyecto y que el programador del proyecto no ve o no debe cambiar.
Principalmente, las métricas de código omiten el código generado cuando calculan los valores de métricas. Esto permite
que los valores de métricas reflejen lo que el programador puede ver y cambiar. No se omite el código generado para
formularios Windows Forms, porque es código que el programador puede ver y cambiar.

CARACTERISTICAS
Los Puntos de Función miden el software cualificando la funcionalidad que proporciona externamente basándose en el
diseño lógico del sistema. Por lo tanto, en el caso de subsistemas diseñados independientemente los Puntos de Función
se calcularán para cada una de ellas, y luego se sumarán.
La técnica de medición del tamaño en punto-función consiste en asignar una cantidad de "puntos" a una aplicación
informática según la complejidad de los datos que maneja y de los procesos que realiza sobre ellos. Siempre tratando de
considerarlo desde el punto de vista del usuario.

PUNTOS DE REFERENCIA
Los objetivos de los Puntos de Función son:
• Medir lo que el usuario pide y lo que el usuario recibe.
• Medir independientemente de la tecnología utilizada en la implantación del sistema.
• Proporcionar una métrica de tamaño que dé soporte al análisis de la calidad y la productividad.
• Proporcionar un medio para la estimación del software.
• Proporcionar un factor de normalización para la comparación de distintos software.

http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/unidad4.pdf

Principales métodos para calcular Puntos Función

– FP Lite: Este método deriva del método de análisis de punto función (FPA) definido por El Grupo
Internacional de Usuarios de Puntos Función (IFPUG), y fue creado por la empresa “David Consulting
Group”, ya que el FPA, por su tamaño y complejidad, es raramente aplicable como tal.
– Puntos Casos de Uso (Use Case Points): Es un método para la estimación del tamaño del
software basada en los casos de uso. Mí método preferido, por su aplicabilidad real. Fueron introducidos
por (Karner, 1993). Esté modo es similar al del cálculo de los FPA de IFPUG, pero comienza con casos de
usos y actores. Aquí tenéis una explicación mayor del método.
– Early and Quick Function Points (E&QFP): Otra técnica, que fue originalmente propuesta por Roberto
Meli para, de nuevo, facilitar el cálculo de los FPA de IFPUG. Es quizá el método más utilizado en la
administración pública italiana.
Una estimación con Puntos Función, permite que la empresa tenga un método repetible de estimar, y por
ello se usan sobre todo en organizaciones que externalizan mucho y quieren fijar unas reglas, un método
estándar, de estimación con sus proveedores. Además los Puntos Función obtener otros diferentes
indicadores, que pueden usarse para mejorar el proceso incluyendo: Número de horas de desarrolladores
por Puntos Función, Número total de horas por Puntos Función, Coste por Puntos Función, etc.

Métricas LOC y PF
La relación entre líneas de código y puntos de función depende del lenguaje de programación que se use para
implementar el software y la calidad del diseño. Algunos estudios intentan relacionar las medidas PF y LOC. La
tabla4 [QSM02], que se presenta en la página siguiente, ofrece estimaciones burdas del número promedio de líneas
de código requeridas para construir un punto de función en varios lenguajes de programación. Una revisión de estos
datos indica que un LOC de C++ proporciona aproximadamente 2.4 veces la “funcionalidad” (como promedio) que
un LOC de C. Más aún, un LOC de Smalltalk proporciona al menos cuatro veces la funcionalidad de un LOC para un
lenguaje de programación convencional, como Ada, COBOL o C. Al usar la información contenida en la tabla, es
posible “retroactivar” [Jon98] el software existente para estimar el número de puntos de función, una vez conocido
el número total de enunciados del lenguaje de programación.

Las medidas LOC y PF se usan frecuentemente para calcular métricas de productividad. Esto invariablemente
conduce a un debate acerca del uso de tales datos. ¿El LOC/persona-mes (o PF/persona-mes) de un grupo debe
compararse con datos similares de otro? ¿Los gerentes deben valorar el desempeño individual usando dichas
métricas? La respuesta a estas preguntas es un enfático ¡NO! La razón para esta respuesta es que muchos factores
influyen en la productividad, lo que hace que las comparaciones entre “manzanas y naranjas” se malinterpreten con
facilidad. Es cierto que los puntos de función y las métricas basadas en LOC son predictores relativamente precisos
del esfuerzo y del costo en el desarrollo del software. Sin embargo, si se van a usar LOC y PF para estimación
(capítulo 26), debe establecerse una línea de referencia de información. Dentro del contexto de las métricas de
proceso y proyecto, la preocupación debe estar centrada principalmente en la productividad y la calidad, medidas de
“salida” del desarrollo del software como función del esfuerzo y el tiempo aplicados y medidas de “aptitud para el
uso” de los productos operativos que se producen. Con propósitos de mejorar el proceso y la planificación del
proyecto, su interés es histórico.

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 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.}

Puntos-Función

Otra de las métricas basadas en el diseño es la debida a Albretch [Albretch, 1979] y conocida como el Método de
Puntos-Función. Albretch sugiere que podría estimarse el tamaño de un Sistema Software teniendo en cuenta las
diferentes funciones que el software deberá de realizar, y posteriormente asignando un valor, en puntos, a cada una de
esas funciones. En general, el método consiste en contar las funciones que debe realizar el software, ajustarlas según su
complejidad y hacer una estimación basada en la suma de los pesos de los Puntos-Función resultantes. Así, propone
Albretch contar, a partir del diseño, las siguientes funciones:

• Número de entradas externas

• Número de salidas externas

• Número de ficheros lógicos internos

• Número de ficheros de interfase

• Número de consultas externas

El número total de funciones de cada clase se ajusta posteriormente según su complejidad, multiplicándolo por un valor
determinado, que varía entre 3 y 15 dependiendo de si la función es simple, tiene una complejidad promedio o es una
función compleja. A continuación se sumarían los resultados y se obtendría el total de Puntos-Función iniciales, PF. En la
tabla siguiente se muestran los coeficientes multiplicadores de Albretch según la complejidad de las funciones.
Seguidamente, es necesario calcular la complejidad del proyecto, con respecto a 14

características que pueden o no estar presentes en el mismo, y que se valoran de 0 a

6, dependiendo de su influencia en el proyecto. Un valor cero indica que la

característica no está presente o no tiene influencia y un valor 6 indica una fuerte

influencia.

Estas características son las siguientes:

• Comunicación de datos

• Funciones distribuidas

• Rendimiento

• Configuración

• Ratio de transacciones

• Entrada de datos “on-line”

• Eficiencia del usuario final

• Actualización “on-line”

• Complejidad de procesamiento

• Reutilización del software

• Facilidad de instalación

Facilidad de operación

• Lugares múltiples

• Facilidad de cambios

Sumando los resultados parciales, se obtiene la complejidad total del proyecto Cp,

que se ajusta según la siguiente fórmula, obteniéndose así la complejidad ajustada

del proyecto, Cpa.

Cpa = 0,65 + (0,01Cp)

Finalmente, se calculan los Puntos-Función ajustados, PFa, como:

PFa = PF x Cpa

Estos Puntos-Función ajustados los utiliza Albretch para estimar el tamaño del

proyecto, proporcionando una estimación de las líneas de código a partir de los

puntos función, y dependiendo del lenguaje de desarrollo empleado. Presenta

además un Modelo General Simplificado, para cualquier lenguaje:

Nº de Instrucciones (NINST) = 66PFa

Algunos de los inconvenientes del método vienen dados por la arbitrariedad de los

coeficientes de ajuste utilizados por Albretch, así como a la dificultad para

identificar las funciones del software a partir de las especificaciones, ya que éste es

un proceso bastante subjetivo.

Este método se estudia con todo detalle más adelante en este mismo tema.