Métrica de punto función

La métrica del punto función es un método utilizado en ingeniería del software para medir el tamaño del software. Fue definida por Allan Albrecht, de IBM, en 1979 ("Measuring Application Development Productivity") y pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la implementación y mantenimiento.

Existen diferentes metodologías de medición, de las cuales la más popular es la mantenida por el International Function Point Users Group (IFPUG).

Antecedentes[editar]

Tradicionalmente se ha medido el tamaño del software mediante distintas métricas: recuento de las líneas de código, número de programas fuente, o técnicas similares, que no resultan aceptables como una buena práctica profesional, porque:

Su resultado depende fuertemente del entorno técnico y el lenguaje de programación utilizado
Varía en función de la pericia de cada programador y del uso de normas y metodologías
No resultan significativas al usuario ni a la dirección

Cuando se trata de establecer métricas de productividad y calidad en la construcción de software, o realizar estimaciones de coste y duración, es imprescindible disponer de una medida fiable y comprensible del tamaño de lo que se construye.

Normalización[editar]

La organización ISO/IEC ha definido un estándar de Medida del Tamaño Funcional, titulado 'ISO/IEC 14143-1:1998', revisado en 'ISO/IEC 14143-1:2007'. Con base en este estándar se han declarado, como métodos estándares de recuento, los siguientes:

ISO/IEC 20926:2009 IFPUG 4.3.1 Unadjusted functional size measurement method - Counting practices manual
ISO/IEC 19761:2011 COSMIC-FFP - A Functional Size Measurement Method
ISO/IEC 20968:2002 Mk II Function Point Analysis - Counting Practices Manual
ISO/IEC 24570:2005 NESMA Guide to Using Function Point Analysis

La norma española equivalente a la ISO 14143 es la UNE 71045-1:2000. "Tecnología de la información. Medida del Software. Medida del tamaño funcional. Parte 1: Definición de conceptos."

Benchmarking[editar]

Una de las utilidades de disponer de una medida del tamaño funcional del software es la de poder comparar el coste del desarrollo de aplicaciones (y otros parámetros de gestión) entre diferentes proyectos y organizaciones (Benchmarking). Para ello el "International Software Benchmarking Standards Group" mantiene una base de datos de métricas y provee diferentes productos de tipo estadístico.

Estos datos y herramientas son de una ayuda importante para una de las tareas más difíciles en la ingeniería del software,la cual es la estimación de costes.

El coste de desarrollo de software por cada punto función varía dependiendo de la tecnología utilizada, el tamaño del proyecto, los requisitos de calidad exigidos y otros parámetros. La media general de todos los proyectos está en 11,50 horas-hombre por punto-función.

El ISBSG incluye en su base de datos mediciones realizadas con cualquiera de las cuatro metodologías ya citadas, aunque la mayoría utiliza la IFPUG-FPA.

Método de recuento[editar]

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.

Por ejemplo, el método IFPUG-FPA (Function Point Analisys) establece los siguientes pasos:

Determinar el tipo de recuento

Puede tratarse 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 (No ajustado).

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.

Otras metodologías de medición son:

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

Crítica[editar]

La crítica principal que recibe esta métrica es la de requerir una dedicación adicional en los proyectos de desarrollo de software, que suelen desenvolverse con presupuestos ajustados.

Su implantación en una organización no acostumbrada a su uso suele resultar penosa y requerir un fuerte compromiso de la dirección. Suele ser vista por los desarrolladores como un mecanismo de control de su trabajo.

Otros aspectos negativos serían:

Resulta arduo formar al personal en su utilización y más todavía mantener unos criterios homogéneos de recuento.
Carece de precisión cuando se trata de proyectos pequeños. Por debajo de unos 100 pf resulta poco confiable.
Para resultar realmente útil, una organización de desarrollo y mantenimiento de software debe tener recontada la mayor parte de su base instalada, pero hacerlo resulta muy costoso especialmente si mantiene software adquirido a terceros.
El factor de ajuste calculado a partir de las características generales del sistema resulta de dudosa utilidad.

Referencias[editar]

IFPUG: Counting Practices Manual, Release 4.3.1.

Garmus, David and Herron, David: “Function Point Analysis: Measurement Practices for Successful Software Projects”; Ed. Addison-Wesley; diciembre de 2000.

Jones, Capers: "Software Assessments Benchamarks, and Best Practices"; Ed. Addison-Wesley; 2000.

DeMarco, Tom; "Controlling Software Projects"; Ed. Prentice Hall; 1982.

Página de bibliografía del IFPUG