METRICAS

1. 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.
REFERENCIA
http://es.slideshare.net/pervys/estimacin-software-por-puntos-de-funcin
http://calidadysoftware.blogspot.com/2011/09/metricas-loc.html
https://msdn.microsoft.com/es-pe/library/bb385914.aspx