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.

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

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 lenguajes de 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.

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.

REFERENCIAhttp://es.slideshare.net/pervys/estimacin-software-por-puntos-de-funcin

http://calidadysoftware.blogspot.com/2011/09/metricas-loc.htmlhttps://msdn.microsoft.com/es-pe/library/bb385914.aspx