La métrica del punto función, definida por Allan Albrecht, de IBM, en 1979 , es un método para medir el tamaño del software. 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 explotación y mantenimiento.
Existen diferentes metodologías de medición, la más popular de las cuales es la mantenida por el International Function Point Users Group (IFPUG).
Antecedentes
Tradicionalmente se ha medido el tamaño del software mediante el 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
La organización ISO/IEC ha definido un estándar de Medida del Tamaño Funcional, titulado 'ISO/IEC 14143-1:1998'. Con base en este estándar se han declarado métodos estándares de recuento los siguientes:
- ISO/IEC 20926:2003 IFPUG 4.1 Unadjusted functional size measurement method - Counting practices manual
- ISO/IEC 19761:2003 COSMIC-FFP - A Functional Size Measurement Method
- ISO/IEC 20968:2002 Mk II Function Point Analysis - Counting Practices Manual
- ISO/IEC 24570:2004 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
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, 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,35 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
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 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 inventarían 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.
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 Funtion Point Analisys)
- Desarrollada en Holanda
- Muy similar al IFPUG-FPA
Crítica
La principal crítica 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 demasiado poco fiable.
- 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
Bibliografía
IFPUG: Counting Practices Manual, Release 4.2 (Puede encontrarse una versión en español en la Asociación Española de Métricas del Software).
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.
No hay comentarios:
Publicar un comentario