Punto de función

Unidad de medida

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. ^[1]

Normas

Existen varios estándares reconocidos y/o especificaciones públicas para dimensionar el software basado en Function Point.

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 conteo
• Nesma: ISO/IEC 24570:2018 Ingeniería de software – Método de medición de tamaño funcional de Nesma versión 2.3 – Definiciones y pautas de conteo 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 — Grupo de gestión de objetos Puntos de función automatizados (AFP), 1.0

Los primeros cinco estándares son implementaciones del estándar general para la medición del tamaño funcional ISO/IEC 14143. ^[2] La especificación OMG Automated Function Point (AFP), liderada por el Consortium for IT Software Quality , proporciona un estándar para automatizar el recuento de puntos de función de acuerdo con las pautas del International Function Point User Group ( IFPUG ). Sin embargo, las implementaciones actuales de este estándar tienen una limitación al poder distinguir la salida externa (EO) de las consultas externas (EQ) de manera inmediata, sin alguna configuración inicial. ^[3]

Introducción

Los puntos de función se definieron en 1979 en Medición de la productividad del desarrollo de aplicaciones por Allan J. Albrecht en IBM . ^[4] Se identifican los requisitos funcionales del usuario del software y cada uno se clasifica en uno de cinco tipos: salidas, consultas, entradas, archivos internos e interfaces externas. Una vez que la función se identifica 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 implementarse.

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 función tempranos y fáciles: se ajusta al problema y a la complejidad de los datos con dos preguntas que producen una medición de complejidad algo subjetiva; simplifica la medición al eliminar la necesidad de contar elementos de datos.
• Puntos de función de ingeniería: se cuentan los elementos (nombres de variables) y los operadores (por ejemplo, aritméticos, de igualdad/desigualdad, booleanos). Esta variación resalta la función computacional. ^{[5] La intención es similar a la de las} medidas de complejidad de Halstead basadas en operadores/operandos .
• Medida de Bang: define una métrica de función basada en doce conteos primitivos (simples) que afectan o muestran Bang, definido como "la medida de la verdadera función que se entregará tal como la percibe el usuario". La medida de Bang puede ser útil para evaluar el valor de una unidad de software en términos de cuánta función útil proporciona, aunque hay poca evidencia en la literatura de tal aplicación. El uso de la medida de Bang podría aplicarse cuando se esté considerando la reingeniería (ya sea completa o por partes), como se analiza en Mantenimiento de sistemas operativos: descripción general.
• Puntos de características: agrega cambios para mejorar la aplicabilidad a sistemas con un procesamiento interno significativo (por ejemplo, sistemas operativos, sistemas de comunicaciones). Esto permite tener en cuenta funciones que el usuario no percibe fácilmente, pero que son esenciales para el funcionamiento correcto.
• Puntos de microfunción 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 de operandos y operadores, el uso de objetos y el algoritmo.
• Puntos de Función Difusos - Propone una transición difusa y gradual entre complejidades bajas x medias y medias x altas ^[6]

Contraste

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

• El riesgo de "inflación" de las líneas de código creadas y, por lo tanto, de reducción del valor del sistema de medición, si se incentiva a los desarrolladores a ser más productivos. Los defensores de la planificación funcional se refieren a esto como medir el tamaño de la solución en lugar del tamaño del problema.
• Las medidas de líneas de código ( LOC ) recompensan a los lenguajes de bajo nivel porque se necesitan más líneas de código para ofrecer una cantidad similar de funcionalidad que un lenguaje de nivel superior. ^[7] C. Jones ofrece un método para corregir esto en su trabajo. ^[8]
• Las medidas LOC no son útiles durante las primeras fases del proyecto, cuando resulta complicado estimar la cantidad de líneas de código que se entregarán. Sin embargo, los puntos de función se pueden derivar de los requisitos y, por lo tanto, son útiles en métodos como la estimación por proxy.

Crítica

Albrecht observó en su investigación que los puntos de función estaban altamente correlacionados con las líneas de código, ^[9] 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 conteo de líneas de código. Además, ha habido múltiples intentos de abordar las deficiencias percibidas con la medida mediante la ampliación del régimen de conteo. ^{[10] [11] [12] [13] [14] [15]} 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. ^[16]

Véase también

• COCOMO (Modelo de Costos Constructivos)
• Comparación de software de estimación de desarrollo
• Método Mark II
• Punto de objeto
• Estimación del esfuerzo de desarrollo de software
• Dimensionamiento del software
• Líneas fuente de código
• Puntos de casos de uso
• El método del punto de función simple

Referencias

1. Thomas Cutting, Estimación de lecciones aprendidas en la gestión de proyectos: tradicional, consultado el 28 de mayo de 2010
2. ISO/IEC JTC 1/SC 7 Ingeniería de software y sistemas (2007-02-01). «ISO/IEC 14143». Organización Internacional de Normalización . Consultado el 26 de febrero de 2019 .{{cite web}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
3. Especificación OMG/CISQ "Puntos de función automatizados", febrero de 2013, número de documento OMG ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0
4. AJ Albrecht, "Medición de la productividad del desarrollo de aplicaciones", Actas del Simposio conjunto de desarrollo de aplicaciones de SHARE, GUIDE e IBM, Monterey, California, 14-17 de octubre, IBM Corporation (1979), págs. 83-92.
5. Puntos de función de ingeniería y sistema de seguimiento, Centro de soporte de tecnología de software Archivado el 11 de noviembre de 2010 en Wayback Machine , consultado el 14 de mayo de 2008
6. Lima, Osías de Souza; Farías, Pedro Porfirio Muñiz; Belchior, Arnaldo Días (1 de junio de 2003). "Modelado difuso para análisis de puntos funcionales". Revista de calidad del software . 11 (2): 149–166. doi :10.1023/A:1023716628585. ISSN  1573-1367. S2CID  19655881.
7. Jones, C. y Bonsignour O. La economía de la calidad del software, Addison-Wesley, 2012. págs. 105-109.
8. Jones, C. Medición de software aplicada: aseguramiento de la productividad y la calidad. McGraw-Hill. Junio ​​de 1996.
9. Albrecht, A. Función del software, líneas fuente de código y estimación del esfuerzo de desarrollo: una validación de la ciencia del software. 1983.
10. Symons, CR "Análisis de puntos de función: dificultades y mejoras". IEEE Transactions on Software Engineering. Enero de 1988. pp. 2-111.
11. Hemmstra, F. y Kusters R. "Análisis de puntos de función: evaluación de un modelo de estimación de costos de software". Revista Europea de Sistemas de Información. 1991. Vol 1, No 4. pp 229-237.
12. Jeffery, R y Stathis, J. "Dimensionamiento de software basado en especificaciones: una investigación empírica de métricas de funciones". Actas del decimoctavo taller anual de ingeniería de software. 1993. págs. 97-115.
13. Symons, C. Dimensionamiento y estimación de software: Mk II FPA (análisis de puntos de función). John Wiley & Sons, Inc. Nueva York, 1991
14. Demarco, T. "Un algoritmo para dimensionar productos de software". ACM Sigmetrics Performance Evaluation Review. 1984. Volumen 12, Número 2. Págs. 13-22.
15. Jeffrey, DR, Low, GC y Barnes, M. "Una comparación de técnicas de conteo de puntos de función". IEEE Transactions on Software Engineering. 1993. Volumen 19, Número 5. Págs. 529-532.
16. Schwartz, Adam. "Uso de casos de prueba para dimensionar sistemas: un estudio de caso". Novena Conferencia Internacional sobre Tecnología de la Información - Nuevas Generaciones, 2012. Abril de 2012. Págs. 242-246.

Enlaces externos

• El Grupo Internacional de Usuarios de Puntos de Función (IFPUG)