Punto de función

El punto de función es una "unidad de medida" que expresa la cantidad de funcionalidad empresarial que un sistema de información (como producto) proporciona a un usuario. Los puntos de función se utilizan para calcular una medida de tamaño funcional (FSM) del software. El costo (en dólares u horas) de una sola unidad se calcula a partir de proyectos anteriores.

Existen varios estándares reconocidos y/o especificaciones públicas para dimensionar el software en función de los puntos de función.

1. Normas ISO

• FiSMA: ISO/IEC 29881:2010 Tecnología de la información – Ingeniería de sistemas y software – Método de medición de tamaño funcional FiSMA 1.1.
• IFPUG: ISO/IEC 20926:2009 Ingeniería de software y sistemas – Medición de software – Método de medición de tamaño funcional IFPUG.
• Mark-II: ISO/IEC 20968:2002 Ingeniería de software – Análisis de puntos de función Ml II – Manual de prácticas de contabilidad
• Nesma: ISO/IEC 24570:2018 Ingeniería de software – Nesma versión del método de medición de tamaño funcional 2.3 – Definiciones y directrices de contabilidad para la aplicación del análisis de puntos de función
• COSMIC: ISO/IEC 19761:2011 Ingeniería de software. Un método de medición de tamaño funcional.
• OMG: ISO/IEC 19515:2019 Tecnología de la información — Puntos de funcionamiento automatizados del Grupo de Gestión de Objetos (AFP), 1.0

Las primeras cinco normas son implementaciones de la norma general para la medición del tamaño funcional ISO/IEC 14143. La especificación OMG Automated Function Point (AFP), liderada por el Consortium for IT Software Quality, proporciona una norma para automatizar el recuento de puntos de función según las directrices del International Function Point User Group (IFPUG). Sin embargo, las implementaciones actuales de esta norma tienen una limitación al poder distinguir la salida externa (EO) de las consultas externas (EQ) de manera inmediata, sin una configuración previa.

Los puntos de función fueron definidos en 1979 en Measuring Application Development Productivity (Medición de la productividad del desarrollo de aplicaciones) por Allan J. Albrecht de IBM. Se identifican los requisitos funcionales del usuario del software y cada uno de ellos se clasifica en uno de cinco tipos: salidas, consultas, entradas, archivos internos e interfaces externas. Una vez que se identifica la función y se clasifica en un tipo, se evalúa su complejidad y se le asigna una cantidad de puntos de función. Cada uno de estos requisitos funcionales del usuario se asigna a una función empresarial del usuario final, como una entrada de datos para una entrada o una consulta del usuario para una consulta. Esta distinción es importante porque tiende a hacer que las funciones medidas en puntos de función se asignen fácilmente a requisitos orientados al usuario, pero también tiende a ocultar funciones internas (por ejemplo, algoritmos), que también requieren recursos para su implementación.

Actualmente no existe ningún método FSM reconocido por la ISO que incluya complejidad algorítmica en el resultado del dimensionamiento. Recientemente se han propuesto diferentes enfoques para abordar esta debilidad percibida, implementados en varios productos de software comerciales. Las variaciones del método IFPUG basado en Albrecht diseñadas para compensar esta (y otras debilidades) incluyen:

• Puntos de funcionamiento tempranos y fáciles – Ajustes por problemas y complejidad de datos con dos preguntas que producen una medición de complejidad algo subjetiva; simplifica la medición eliminando la necesidad de contar elementos de datos.
• Puntos de funcionamiento de ingeniería – Se cuenta con elementos (nombres variables) y operadores (por ejemplo, aritmética, igualdad/igualdad, booleano). Esta variación resalta la función computacional. La intención es similar a la de las medidas de complejidad Halstead basadas en el operador/operand.
• Medida Bang – Define una métrica de función basada en doce cuenta primitivas (simple) que afectan o muestran Bang, definida como "la medida de la verdadera función que debe ser entregada como percibida por el usuario". La medida Bang puede ser útil para evaluar el valor de una unidad de software en términos de la función útil que proporciona, aunque hay poca evidencia en la literatura de dicha aplicación. El uso de la medida Bang podría aplicarse cuando se está considerando la reingeniería (ya sea total o parcial), como se discutió en Mantenimiento de Sistemas Operacionales—Una visión general.
• Puntos de alimentación – Añade cambios para mejorar la aplicabilidad a los sistemas con un procesamiento interno significativo (por ejemplo, sistemas operativos, sistemas de comunicaciones). Esto permite la contabilidad de funciones no fácilmente perceptibles por el usuario, pero esenciales para el funcionamiento adecuado.
• Puntos de función de micro ponderados – Uno de los modelos más nuevos (2009) que ajusta los puntos de función utilizando pesos derivados de la complejidad del flujo del programa, el vocabulario operativo y el operador, el uso de objetos y el algoritmo.
• Puntos de Función Fuzzy - Propone una transición borrosa y gradativa entre complejidades bajas x medianas y altas

El uso de puntos de función en lugar de líneas de código busca abordar varios problemas adicionales:

• El riesgo de "inflación" de las líneas creadas de código, y reduciendo así el valor del sistema de medición, si los desarrolladores son incentivizados para ser más productivos. Los defensores de FP se refieren a esto como medir el tamaño de la solución en lugar del tamaño del problema.
• Líneas de Código (LOC) medidas recompensan idiomas de bajo nivel porque se necesitan más líneas de código para ofrecer una cantidad similar de funcionalidad a un lenguaje de nivel superior. C. Jones ofrece un método para corregir esto en su trabajo.
• Las medidas de LOC no son útiles durante las primeras fases del proyecto, donde es difícil calcular el número de líneas de código que se entregarán. Sin embargo, los puntos de función pueden derivarse de los requisitos y por lo tanto son útiles en métodos como la estimación por proxy.

Albrecht observó en su investigación que los puntos de función estaban altamente correlacionados con las líneas de código, lo que ha dado lugar a un cuestionamiento del valor de dicha medida si se dispone de una medida más objetiva, es decir, el recuento de líneas de código. Además, ha habido múltiples intentos de abordar las deficiencias percibidas en la medida mediante la ampliación del régimen de recuento. Otros han ofrecido soluciones para sortear los desafíos mediante el desarrollo de métodos alternativos que crean un indicador de la cantidad de funcionalidad entregada.

• COCOMO (Modelo de Costo Constructivo)
• Comparación del software de estimación del desarrollo
• Método Mark II
• Punto de objeto
• Estimación del esfuerzo de desarrollo de software
• Software Sizing
• Líneas de código fuente
• Use puntos de caso
• El método de punto de función simple

• The International Function Point Users Group (IFPUG)