40 Años de Puntos de Función: Pasado, Presente, Futuro

Por Louis Bouillon

Sólo 40 Hace años, en octubre 1979, Dr. Allan Albrecht propuso por primera vez una técnica para el dimensionamiento de la funcionalidad de un sistema de software. Se adoptó su técnica, se convirtió en una norma internacional, y inspirado a varias otras técnicas y más. En este trabajo se muestra el pasado, presente y (posible) future contributions of Function Point Analysis.

El pasado: orígenes, La motivación y justificación

En los 1970s, Líneas de código (LOC) se usa incorrectamente para el dimensionamiento de los sistemas de software (y siguen siendo hoy en día en algunos dominios funcionales, tales como los sistemas de automoción y militar en tiempo real y, Sólo para nombrar unos pocos) y condujo a lo Capers Jones calificó la “paradoja de la productividad” ^[1]: escribiendo más LOC no significa necesariamente que ser más productivo ... el estilo de programación, la expresividad de un determinado lenguaje de programación, la regla para el recuento de las LOC (físico o lógico, con / sin líneas de comentarios ...) creado una enorme variabilidad en proyecto (sí, proyecto!) Estimacion. Porque en ese momento, que sólo tenía mainframes, no PC o mini-ordenadores. Así, la (software) esfuerzo de producto para desplegar era la mayor parte de las funcionalidades generales del proyecto y el esfuerzo de software fueron pensados ​​como el principal resultado de un proyecto de software. Como consecuencia, durante muchos años (y todavía en muchos contratos), Puntos de función (PM) fueron (y son) erróneamente concebido como el “tamaño del proyecto”, mientras que sólo expresan el tamaño funcional del producto. De todas formas, El objetivo de Albrecht fue superar la “paradoja de la productividad” y encontrar una manera de normalizar los cálculos de productividad desde una perspectiva de negocio ^[2]. La gran idea era basar su técnica en algo independiente de la tecnología: procesos y datos. Así, un cálculo de FP (y el tamaño funcional producto relacionado) derivado del análisis de un conjunto de requisitos de usuario funcionales (pieles) que es lo mismo a pesar de la tecnología y el estilo organizativo adoptado, mientras que el esfuerzo, la duración y el costo / precio son, por supuesto, variable de acuerdo con tales elementos. El ejemplo típico propuesto en los últimos años era mirar FP metros cuadrados como para medir el “tamaño” de un piso: el número de metros cuadrados puede ser el mismo para dos pisos en dos lugares diferentes, pero el tiempo para la construcción de ellos puede diferir (por ejemplo. un piso puede ser construido con ladrillos o prefabricar), así como sus costos de producción y valor comercial (un piso en Manhattan, Nueva York, deberá costar más por metro cuadrado que otra en otro lugar); cost is not value.

El primer documento, anticuado 1979, fundamentos planteados para este objetivo, como se indica en su título (“La medición de la productividad del desarrollo de aplicaciones”). Representaba una gran explosión para las estimaciones, Extracto tratando de entradas / salidas / consultas y datos de un análisis funcional, en particular, debido a que un nuevo número de este tipo podría haber sido derivado antes de la programación y, a más, al igual que con un recuento de LOC. Como no se puede prever con un cierto nivel de precisión el número de LOC su equipo producirá mañana ... demasiada variabilidad!

Hay muchas ventajas pero también algunas cuestiones abiertas: la correlación entre el esfuerzo del proyecto (personas / día) y el tamaño funcional producto (en FP) No era tan alto, y un Factor de Ajuste de Valores (VAF) se introdujo con el fin de mejorar una relación tal y el valor de R2 en un análisis de regresión lineal. VAF se calculó inicialmente en 10 Características generales del sistema (GSCS) con una variabilidad de ± 25% en el primer 1979 papel, ampliada a 14 GSCs en la segunda y última de papel, anticuado 1983 ^[3], con una variabilidad ± 35% en el valor de FP inicial “no ajustado”. VAF era, por lo tanto, La primera manera de forma indirecta “tamaño” de la contribución de los requisitos no funcionales (NFR), tanto en el producto, así como el nivel de proyecto. Este segundo y último papel de Allan Albrecht declaró la estructura final FPA, dividir el MAESTRO tipo de función datos iniciales en ILF y EIF, y declaró el sistema de ponderación definitiva (como siendo válida en la versión actual de CPM v4.3.1 IFPUG, anticuado 2010 ^[4]) a partir de ese momento. Así, es posible comparar -desde un punto de vista funcional dimensionamiento- a software product realized today with another one released years ago for benchmarking purposes.

En 1987, IFPUG nació y se mantiene en sus manos la gestión y evolución de la técnica de Albrecht. En los próximos años, varias técnicas se alejaron de las ideas de Albrecht, y sólo algunos se convirtieron en las normas ISO, como se muestra en la figura. 1:

Higo. 1: Normas ISO FSM (con líneas azules punteadas)

Son (En orden de aparicion): Mark-II (1988), NESMA FPA (1990), FISMA (199X) y cósmico (1998), con una gran cantidad de variantes menores (aquí ^[5] una lista de algunos de ellos).

Primeros usos de la FPA fueron determinar el tamaño funcional de los productos de software con fines de estimación y evaluación comparativa y -para simplificar- as a contractual unit for payment in an ICT contract.

En 1998, ISO comenzó la creación de una familia de estándares bajo la etiqueta “14143” con los principios comunes para la llamada Medición Dimensionamiento funcional (FSM) métodos, indicando de manera clara que tales métodos dimensionadas un producto (no un proyecto) y sólo cuando se mueve de pieles de productos, que excluía versiones ISO relacionados que inicialmente incluía factores de ajuste tales como VAF ^[6]. Lo racional? Tales factores “ajuste / calibración” vinieron de NFR, así, están fuera de alcance para un método de FSM. Como evidencia: YO ASI 20926:2003 era el estándar ISO para v4.1 IFPUG CPM “no ajustados.” Versiones 4.x -desde 1999 en- definiciones versión refinada y conceptos básicos, en particular, “usuario” y “límite”. Versión v4.3 (2010) definitivamente caído VAF del texto normativo (también en la norma ISO / IEC 20926:2009) and maintained it for historical purposes in Appendix C.

Mientras tanto, ya que las pieles y NFR necesitan ser tratados de manera paralela, Proceso de evaluación de software que no funciona (CHASQUIDO) proyecto se inició en 2007, liberando v1.0 en 2011 ^[7], para un nuevo, Dimensionamiento primera medición que no funciona (NFSM) método, que ha pasado de la norma ISO sobre la calidad del producto de software (9126 antes de ^[8], y se convirtió en la corriente 25010:2011 estándar ^[9]) mientras trata de complementar el dimensionamiento funcional tanto como sea posible. Higo. 2 ayuda a determinar el alcance del proyecto derecha, con tres tipos de requisitos:

Higo. 2: Existen tres tipos de requisitos (del esquema de la ‘ABC’)

La información fue escrito de manera diferente a la versión 4.1 de CPM. Yo claramente expresada en una 2012 papel que escribí para MetricViews ^[10], El esquema ‘ABC’; tales taxonomía también se usó en una 2015 papel co-escrita por IFPUG / COSMIC para expresar mejor una taxonomía para NFR ^[11]. Esta clasificación es crítico desde el principio de cualquier proyecto para analizar y comparar con un buen análisis comparativo adecuadamente. Higo. 3 resume cómo el requerimiento de usuario podría ser desplegado y dividir, en el caso más amplio, en tres trozos: pieles de productos (UNA), NFR de productos (segundo) y las limitaciones del proyecto / requisitos (do).

Higo. 3: El esquema ABC [10]

A partir de las necesidades del usuario al esfuerzo general del proyecto final y los costes – El esquema de “ABC” ^[10] en 1997 ISBSG (isbsg.org) nació y todas las asociaciones de la medición del software más activos (SMA) adherido a esta iniciativa de referencia. los 2019 lanzamiento ^[12] incluye más de 9,000 proyectos, en su mayoría de tamaño utilizando los métodos IFPUG y cósmico FPA. Otra norma complementaria fue la ISO / IEC 14143-5:2004 ^[13], que propone criterios para la definición de “dominios funcionales” y permite una comparación razonable entre los sistemas de software con características similares y la distribución del esfuerzo por tipos de requisitos (A B C). No tiene sentido comparar manzanas con naranjas ...

El presente: Que esta pasando?

FSM métodos se utilizan de forma difusa en la Información & Tecnología de la comunicación (TIC) contratos, con una mayor concentración en algunos países (por ejemplo. Italia, Brasil, Polonia, India), y representan una base cuantitativa para dimensionar el tamaño funcional del producto y puede ayudar en el análisis de la evaluación comparativa para determinar lo que podría ser (aproximadamente) el esfuerzo no es funcional en un proyecto, como se muestra en la figura 4:

Higo. 4: distribución de esfuerzo por tipo de requisito (A B C) por dominio funcional: un ejemplo

Un ejemplo de la distribución de esfuerzo por tipo de requisito (A B C) por dominio funcional está dividiendo lo que no es funcional según el esquema ABC. Un requisito de tipo B se puede realizar y se despliega por un especialista en TI (por ejemplo. un administrador de la base, usabilidad experto ...) que por lo general cuesta menos que otro profesional (por ejemplo. un jefe de proyecto / servicio, un especialista en la medición, una persona de garantía de calidad ...) la ejecución de un requerimiento de tipo C, pero más de un profesional (por ejemplo. un analista / programador) la ejecución de un requisito de tipo A. Higo. 5 muestra las dos pirámides opuestas para una distribución típica del esfuerzo del proyecto por tipo de requerimiento y el costo por persona / día para cada tipo de profesional ^[14].

Higo. 5: distribución de esfuerzo por tipo de requerimiento y el costo / día-hombre (de acuerdo con el esquema ABC)

distribución de esfuerzo por tipo de requerimiento y el costo / día-hombre (de acuerdo con el esquema ABC). Otra vez, lecciones aprendidas de 40 años de experiencia ayudaron a definir mejor (y refinar) principios y reglas sobre el ámbito de aplicación de FPA. El ‘123’ esquema es otra clasificación ^[15] por declarar qué tipo de requisitos puede estar presente en una determinada fase de un proyecto (1: dev, 2: ops, 3: SVC, Mantenimiento).

Higo. 6: El ‘123’ esquema de conjunto con el esquema de ‘ABC’

Así, en la fase OPS se utiliza un software, no producido / cambiado, y genera un recuento “cero FP”, así como cuando una solicitud de cambio incluirá únicos requisitos de tipo B (por ejemplo. para un mantenimiento correctivo / perfectivo, como se indica en la norma ISO / IEC 14764:2006 estándar ^[16], también citada en v4.3.1 CPM – parte 3, capítulo 4, páginas 20-21). Incluso si las definiciones y criterios acerca de lo que ha sido creado FUR o NFR, explicado y difundido a través del tiempo, todavía hay una deuda cultural en las prácticas contractuales y las empresas para utilizar al menos una unidad de medida (Unidad de medida de) para el dimensionamiento de los requisitos de tipo A (PM, cualquier clase) conjuntamente con la unidad de medida para el dimensionamiento de los requisitos de tipo B (por ejemplo. con puntos IFPUG SNAP o medidas de la norma ISO / IEC 25023 ^[17], así como las actividades de tipo C que completan las posibilidades de la estimación de todo el esfuerzo necesario para la determinación del alcance de un proyecto. Sólo al dimensionar todos los requisitos para los tres (A B C) tipos, es posible reducir la “corrupción del alcance,”Mientras que todavía hay una idea errónea histórica acerca de lo que un tamaño de FP y lo que no lo hace. Pero sería suficiente conocer en un método de FSM, que son sus componentes funcionales Base (BFC) para la inclusión (o no) such an activity or activities.

Por último, si bien no menos importante, FP y automatización. Dr. Albrecht creó una “medida de diseño” para permitir una estimación en las primeras fases de un ciclo de vida. Algunas herramientas de hoy en día, después 40 años, derivaría PM (cualquier clase) análisis de código de software o trabajando en algunas formas de anotaciones FUR. Algunos (sentido común) observaciones y pensamientos: la automatización es útil si es respetuoso de cuatro criterios: Más rápido, más preciso, más oportuna y más bajo en costo. Si necesitamos un nuevo tamaño PIEL, un código de la herramienta de análisis (como se establece en la nueva norma ISO 19515 Automatizado de serie en FP ^[18]) sería inútil y costoso. O, utilizando una herramienta asumiendo algunas notaciones UML como entradas implicarían más horas-hombre (y costos relacionados) para la traducción de un requerimiento por escrito basada en humanos en un formato de meta-lenguaje. también, una organización necesita analizar cuidadosamente el retorno de la inversión para dicha elección(s) de acuerdo con los cuatro criterios mencionados anteriormente. la creación rápida de un proyecto de línea de base en el que el tiempo y el esfuerzo son activos críticos podrían estar bien bajo las condiciones previas que se verifica por un CFPA humana y que la Unidad de medida de bajo alcance son los mismos. De otra manera, automation could become risky or difficult to manage.

El futuro: ¿Qué podemos esperar?

Como mucha gente diría, el futuro es ahora ... pero lo que podemos esperar de FPA en un futuro próximo? FPA tiene bases sólidas y es independiente de la tecnología; lo que hemos aprendido del pasado es que los próximos pasos deben ser:

• Una mejor y más asequibles Requisitos del usuario (UR) administración, determinación del alcance y de medición durante las primeras fases de un proyecto: this is the main and primary goal that should be achieved.
• Adopción de FPA a las nuevas tecnologías, a través de la correcta interpretación de las reglas básicas de la APF 1979/84. Todavía no podemos medir y tamaño a través de FPA nuevas tecnologías como la computación en nube ^[19], Internet de las Cosas (IO) ^[20], artificial intelligence and any new tech the upcoming years will bring us.

Nuestra mejor apuesta no es inventar algo nuevo, sino analizar profundamente nuestros procesos y datos actuales para determinar las formas nuevas y diferentes para diseñar un sistema de software y fijas El tamaño de una piel con FPA!

“Tenemos la intención de seguir utilizando y mejorando la función valor medición.” (Allan Albrecht, octubre 1979)

referencias

1. Jones, DO., ¿Cuáles son los puntos de función? página web SPR, URL: http://tiny.cc/tgur7y
2. Un Albrecht. J., “La medición de la productividad de desarrollo de aplicaciones” en Proc. participación conjunta, GUÍA, y desarrollo de aplicaciones de IBM , 1979, páginas. 83-92. http://tiny.cc/2ywacz
3. Un Albrecht. J. & Gaffney J. MI., “función de software, líneas de código fuente, y la predicción esfuerzo de desarrollo: Una validación de la ciencia del software,” IEEE Trans. Software Eng., vol. 9, no. 6, noviembre 1983, páginas. 639-647. http://tiny.cc/1zwacz
4. IFPUG, Manual de prácticas de conteo de puntos función (CPM), lanzamiento 4.3.1, enero 2010, URL: ifpug.org
5. Lotras M., Dumke R., Puntos-Metrics: Comparaciones y análisis”, en: Las tendencias actuales en la medición del software, editorial Shaker, 2001, pp.228-267
6. ISO / IEC, Estándar internacional 14143-1 – Tecnologías de la información – Medición de software – Funcional de la medida del – Parte 1: definición de conceptos, February 2007
7. IFPUG, Proceso de evaluación de software no funcionales (CHASQUIDO) Manual de prácticas de evaluación (APM), versión 1.0, septiembre 2011, URL: ifpug.org
8. ISO / IEC, ES 9126-1:2001 – Ingeniería de software – Calidad del producto – Parte 1: Modelo de calidad, Organización Internacional para la Estandarización, 2001
9. ISO / IEC, ES 25010:2011 -Sistemas y software de ingeniería-Systems y la calidad del software Requisitos y Evaluación (Cuadrado)-modelos de calidad del sistema y del software, Organización Internacional para la Estandarización, March 2011
10. Caldo L., La próxima frontera: Medición y evaluación de la productividad no funcionales, MetricViews, agosto 2012, URL:https://www.ifpug.org/Metric%20Views/MVBuglione.pdf
11. COSMIC / IFPUG, Glosario de términos de requisitos no funcionales y requisitos de los proyectos de software utilizado en la medición del desempeño del proyecto, la evaluación comparativa y la estimación, v1.0, September 2015
12. ISBSG, re&mi (Desarrollo & Mejora) repositorio, R2019, URL:isbsg.org
13. ISO / IEC, Reporte técnico 14143-5 – Tecnologías de la información – Medición de software – Funcional de la medida del – Parte 5: determinación de dominios funcionales para su uso con la medida del tamaño funcional, 2004 (R2019)
14. Caldo L., Cómo manejar proyectos uniformes y medibles: centrarse en los tipos y requisitos, ZeroUnoWeb, Mayo 3 2019, URL: http://tiny.cc/y1tr7y
15. Caldo L., Interpretar DevOps para medir bien (y lo mejor) proyectos, PMExpo2017, Presentación, octubre 2017, URL:https://www.pmexpo.it/2017/programma/009tk
16. ISO / IEC, Estándar internacional 14764:2006 - Procesos del ciclo de vida del software - Ingeniería de Software – Mantenimiento, 2006
17. ISO / IEC, Estándar internacional 25023:2016 – Sistemas e ingeniería de software – Sistemas y requisitos de calidad de software y Evaluación (Cuadrado) – La medición de la calidad del sistema y producto de software, June 2016
18. ISO / IEC, Estándar internacional 19515:2019 – Tecnologías de la información – Objeto de administración de grupos automatizados Puntos de Función (AFP), 1.0, May 2019
19. Woodward S., Análisis de Puntos de Función aclara en un mundo nublado, Metricas 2012, Sao Paulo (Brasil), nov 28-29 2012, URL:http://www.bfpug.com.br/metricas2012/woodward.pdf
20. Cagley T., Puntos de función y IOT, o ¿Cómo Mi cocina es espiándome!, IFPUG ISMA17, Bangalore (India), marzo 8, 2019

Sobre el Autor

Luigi Buglione es el Director IFPUG para conferencias / Educación y Presidente de la Función Gruppo Utenti Point Italia – Asociación Italiana métricas de software (GUFPI-ISMA) (www.gufpi-isma.org). Se desempeña como Especialista de Mejoras Medición y Proceso en Ingeniería Ing. inf. SpA en Roma, Italia y Profesor Asociado de la Escuela de Tecnología Superior (ETS) - Universidad de Quebec, Canadá. Él alcanzó varias certificaciones, incluyendo CFPS IFPUG, CSP, CSMS, y el CCFL COSMIC acerca de la medición del software. Es ponente habitual en conferencias internacionales en SW / Servicio de Medición, Mejora de procesos y calidad y es parte activa de la Internacional y Asociaciones Técnicas Nacionales sobre estas cuestiones. Recibió un doctorado. en MIS y un cum laude en Economía. Luigi puede ser alcanzado en luigi.buglione@eng.it.