Nos preguntemos en el post anterior, ¿por qué los desarrolladores generalmente no tienen conocimiento de los Puntos de Función? Y si esta medida podría serlos útil.

Nuestra respuesta es más bien negativa, sobre todo si tenemos en cuenta que tal estimación se realiza manualmente por consultores y con un proceso a veces bastante complejo. Hay muchas certificaciones cuyo objetivo es validar que un consultor domina estos conceptos y sepa ponerlos en práctica de manera operacional.

No es realmente lo que puede atraer desarrolladores que, en mi opinión, más bien preferirán invertir en una nueva tecnología, un nuevo lenguaje, el último framework de moda, un desarrollo de código abierto, etc.

Ahora imaginamos que el cálculo de los puntos de función se pueda automatizar: ¿sería suficiente para que los desarrolladores adopten esta medida?

Automated Function Points (AFP)

El Object Management Group (OMG) ha realizado una normativa de especificaciones que describe los requisitos para automatizar la medición de puntos de función.

Limitaciones

Este documento establece unas diferencias con una estimación manual de Puntos de Función. Por ejemplo, la sección « 1.3 Limitations » explica que esta norma no se aplica a « la medición  de los cambios de una aplicación o del mantenimiento de funcionalidades [existentes], también llamado Enhancement Function Points ».

Si este es el caso, entonces sería más bien una gran discrepancia si los Puntos de Función automatizados se pueden usar solamente en nuevos desarrollos, y no con las versiones sucesivas de una aplicación. Sabemos que el 80% o el 90% de los proyectos son de mantenimiento de aplicaciones, los nuevos proyectos son más o menos una minoría.

Por otra parte, estas especificaciones no pretenden (« 2.1 Conformance ») a un estricto cumplimiento de la medición manual de los Puntos de Función, sobre todo por las dificultades … para automatizar completamente un proceso manual. La sección « 2.3 Consistency with IFPUG CPM » explica que « esta norma toma decisiones explícitas » cuando, en algunas situaciones, las normas promulgadas por el IFPUG (1) pueden ser bastante imprecisas.

En la misma sección, explica que el consultor IFPUG tendrá que realizar algunas interpretaciones acerca del diseño y desarrollo de los elementos funcionales, lo que obviamente es imposible por una herramienta de software, que no puede decidir por sí misma si una estructura de datos o una transacción es importante o no para la aplicación: « El [software] no puede capturar cualquiera de las intenciones del diseñador que no deje una huella en el código fuente. »

Así que la propia norma establece claramente que « contar Puntos de Function automatizados … puede diferir de los recuentos manuales efectuados por un consultor IFPUG certificado ».

Implementación de la norma

El resto del documento enumera los pasos necesarios para contar AFP. No voy a detallar estas operaciones, sino simplemente listar lo que, en base a mi experiencia en herramientas de análisis de código, puede causar discrepancias con el calculo manual de FP o tener consecuencias para la aplicación de esta norma en el ciclo de vida de un proyecto.

Fronteras

El primer paso consiste en definir las fronteras (‘outbounds’) de la aplicación a nivel funcional, desde el punto de vista del usuario, para determinar lo que está en la aplicación, y entonces el código que analizar, y qué es externo a la aplicación y por lo tanto fuera del análisis automatizado de Puntos de Función.

Consideramos como ejemplo una sencilla gestión de hojas de actividades (timesheets) para una empresa de TI en la que un empleado ingresa las tareas y el tiempo dedicado para un cliente y al final emitir factura. Esta aplicación no gestiona ella misma los empleados de la empresa, pero va a recuperar esta información del sistema de gestión de Recursos Humanos. Del mismo modo, los diferentes tipos de actividades, facturables o no, suelen ser gestionados por el sistema contable. Y la información sobre el cliente y el servicio a prestar deberían reflejarse en el sistema comercial.

Si nuestra aplicación maneja su propio acceso a los datos de estos otros sistemas, entonces estos son internos y deben tenerse en cuenta en nuestra evaluación de Puntos de Función Automatizados. Sin embargo, si se utiliza a componentes de estos otros sistemas para conseguir los datos necesarios, entonces estos tratamientos son externos y no están en el ámbito de análisis de la aplicación.

A veces, para no decir a menudo, la elección será difícil, si no imposible. Si tenemos unos servicios Web entre diferentes aplicaciones, ¿donde conectarlos? ¿A cual aplicación? ¿Deben ser considerados? Tenemos unos CopyBooks, equivalente a ‘include’ en aplicaciones Mainframe-Cobol, que describen las tablas DB2 y son reutilizables por todas las aplicaciones que acceden a estas tablas. Si 15 aplicaciones utilizan una misma tabla, todas trabajan con el mismo CopyBook (bueno, esto es lo que se supone que deberían hacer). ¿A que aplicación vincular este CopyBook? ¿Y qué hay de un ERP u otro paquete de softwares que consta con varios módulos altamente integrados y imbricados?

Desglose del código de la aplicación

Obviamente, tenemos ya que hacernos estas mismas preguntas cada vez que se configura un nuevo análisis de código, ya sea para el recuento de puntos de función o no. Pero si estás interesado sólo en la calidad del código, que un tal componente pertenece o no a dicha aplicación no es crítico: lo que deseas es comprobar si el componente tiene o no violaciones de buenas prácticas de programación. Esto es lo que suele ocurrir, por ejemplo, para aplicaciones en Cobol Mainframe, donde las aplicaciones no tienen realmente fronteras. Más a menudo, tratamos de configurar los análisis de acuerdo con algunos criterios útiles para nuestra evaluación de la calidad, por ejemplo, en función de su tipo transaccional o batch, porque un defecto en el rendimiento va a ser peor para una aplicación TP con un usuario frente a la pantalla que para una aplicación Batch sin usuario y que se ejecuta durante la noche.

Cuando los límites de aplicación no son claras, el segundo criterio más utilizado para el desglose del código y la configuración de los análisis es de tipo organizacional: reunir todos los componentes administrados por el mismo equipo, y que normalmente se encuentran en un espacio (directorio de red, biblioteca mainframe, repositorio de una herramienta de gestión de configuración, etc.), administrado por el equipo. Esta configuración basada en ‘quien hace qué’ resulta crítica en algunos casos de uso, por ejemplo para un Quality Gate o un benchmarking de la calidad de código entre distintos proveedores o equipos internos. En estos casos, estamos interesado en los defectos añadidos o corregidos en versiones posteriores de la aplicación, con el fin de decidir sobre aceptar (OK) o rechazar (KO) una nueva versión o si tu proveedor externo está trabajando correctamente o no, si hace o no los esfuerzos para mejorar y cómo se compara con otros proveedores.

Este es también el criterio organizativo – quien gestiona cual componente – que debemos utilizar si queremos medir la productividad de los desarrolladores. Pero veo aparecer algunas dificultades adicionales. En primer lugar, la necesidad de precisión y de rigor es más importante. Si le dices a un desarrollador que has encontrado el mismo incumplimiento de las buenas prácticas de programación en 10 componentes que él ha cambiado, y, de hecho, uno de ellos no está dentro de su responsabilidad, sin embargo, él repitió esta mala práctica en 9 de cada 10 componentes, y por lo tanto debe mejorar. De hecho, en el caso de Quality Gate, una sola ocurrencia es suficiente si está de tipo Blocker. Pero si le dices a un desarrollador o un proveedor que él no trabaja lo suficiente, y olvides un componente en tu análisis automatizado de los puntos de función, tu conclusión será muy probablemente discutida y de manera bien vehemente. Un desarrollador puede pasar varias horas o varios días en un solo método o una sola función. La omisión de un único objeto entre muchos miles puede falsear los resultados, así que mucho cuidado.

Otro problema: te interesa solamente el código modificado por el equipo del proyecto, porque del mismo modo que no puedes responsabilizar un outsourcer de los defectos ya presentes en el código que recibió por mantenimiento, tampoco puedes medir la productividad del código ya existente, sino del código que él ha modificado o escrito. Pero no se puede medir los puntos de función del código modificado solo: es necesario identificar las estructuras de datos y las transacciones correspondientes, desde la capa de presentación hasta la capa de datos. Esto sólo es posible si vuelves a analizar toda la aplicación, calculando la diferencia del número de puntos de función con una versión anterior. Y eso solamente si consideramos que esta norma se aplica a las nuevas versiones (véase la limitación mencionada anteriormente).

Por lo que es más complicado, pero también más difícil de interpretar. Imaginamos dos equipos que produjeron 100 puntos de función, el primero en una aplicación que mide 1 000 FP, el segundo en una aplicación que tiene 10 000 FP. Supongo que el esfuerzo no es lo mismo, del mismo modo que no podemos comparar el trabajo de añadir 1 000 líneas de código (LOC) en una aplicación que tiene ya 10 000 o en 100 000 LOC. De hecho, algunos expertos creen que el recuento de puntos función debe realizarse de manera diferente para aplicaciones de tamaño muy pequeño o muy alto.

Última cosa: hay que excluir del análisis las librarías, los frameworks, los componentes reutilizables y otras dependencias externas a la aplicación, sino también todas las tablas o los archivos que no entran dentro de la aplicación. Sin embargo, se analizará estos objetos con el fin de encontrar las transacciones entre las diferentes capas de la aplicación y por lo tanto les consideremos en el análisis, pero « claramente identificados como externos », como dictan las especificaciones de la norma OMG. Este documento pone de relieve la importancia de esta etapa de definir el alcance del análisis, y para ello se requiere la presencia de un experto en aplicación (SME), o incluso el ‘aplication owner’.

Análisis

El resto del documento describe los pasos del proceso de recuento AFP:

• Identificar todas las funciones en el código y clasificarlas en funciones de datos y funciones transaccionales,
• teniendo en cuenta la naturaleza interna o externa de las estructuras de datos,
• antes de realizar la estimación de puntos de funciones para cada una de ellos

Estos requisitos exigen que el software de análisis de código sea capaz de tener en cuenta las bases de datos, relacionales o no – algunas aplicaciones Cobol utilizan bases de datos jerárquicas – pero también todo tipo de archivos, lo que no es muy natural para una herramienta de este tipo.

También es necesario identificar cada estructura lógica de datos con el fin de vincularlas con las transacciones. Sin embargo, estas estructuras pueden estar dispersas en varias tablas, y el documento especifica las restricciones que deben respetarse para identificar estructuras de tipo ‘master-detail’. En nuestro ejemplo de gestión de Timesheets, una persona rellena varias hojas de actividad, posiblemente para diferentes clientes. Cada timesheet constará de varias actividades, lo que significa que la tabla ‘Timesheet’ es de tipo ‘detail’ para las entidades ‘Proveedor’ o ‘Cliente’, y ‘master’ para ‘Actividades’.

El estándar OMG recomienda utilizar las reglas de nomenclatura para reconocer tablas, vistas, índices, claves, etc. que identifican estas estructuras de datos y sus relaciones. Esto implica que:

• Existen estas reglas.
• Están aplicadas por el equipo del proyecto.
• El software de análisis está configurado para reconocer estas reglas, y los objetos correspondientes.

También debe ser capaz de analizar cualquier tipo de archivo y su estructura interna – tabular (flat-files, archivos CSV, etc.) o arborescente (xml, html, etc.). Sólo que en este caso no tenemos claves o índices para saber como agrupar los datos en estructuras lógicas, y el software de cálculo de AFP debe elegir – por lo general, considerando un archivo como una única entidad lógica – opción que no escogería necesariamente un consultor IFPUG.

Hay que comprobar también si un archivo es temporal o no, y si los datos que contiene son gestionados o no por un usuario. Por ejemplo, un archivo log de errores, utilizable sólo por el programador, se debe excluir del ámbito de análisis.

Una vez identificadas las estructuras de datos, tenemos que hacer lo mismo con las transacciones que gestionan los datos a través de las capas de la aplicación, e identificar a los ‘inputs’ de los ‘outputs’ a través de las operaciones realizadas: leer (‘read’) o escribir (‘write’) o editar/borrar datos. Esto implica, según la norma de:

• « capturar las transacciones desde la interfaz de usuario »,
• « para identificar los eventos que interactúan con la capa de datos » y
• « los outputs creados por estas transacciones de [gestión de] datos.

También de acuerdo con el documento, identificar tales operaciones requiere:

• Poder encontrar vínculos entre los diferentes objetos, que constituyen un ‘camino’ (path) desde el principio y hasta el final de la transacción;
• Poder tener en cuenta los numerosos caminos existentes, con el fin de agrupar todas las operaciones en las estructuras de datos en una única transacción;
• Poder declarar en la herramienta los elementos de código externos (analizados o no) con el fin de reconstruir las transacciones, o al menos una lista de los elementos que faltan. Para reconstruir una transacción completa, a veces se necesitará analizar los componentes externos a la aplicación, pues incluirlos en el análisis pero excluyéndolos del recuento.

Automated Function Points: ¿qué medida?

Como podemos ver, el documento de la norma OMG especifica los requisitos para el uso de los Puntos de Función automatizados, así como sus limitaciones. Los puntos que considero más importante a recordar son los siguientes.

Perímetro

La norma no se aplica a « la medición de los cambios de una aplicación o del mantenimiento de sus funcionalidades », y por lo tanto sólo se aplicaría a los nuevos desarrollos. Si este es el caso, limita muchísimo su uso e su interés.

Medidas AFP e IFPUG

La norma no pretende a una estricta conformación con la medición manual de Puntos de Función, ya que « contar Automated Function Points … puede diferir de los recuentos manuales realizados por un consultor IFPUG certificado ».

Esto me parece un primer punto importante: los Puntos de Función automatizados no son Puntos de Función IFPUG. Es otra medida, que tiene la ventaja de ser computable automáticamente por una herramienta, y por lo tanto con menos esfuerzo que un recuento manual, pero también con un resultado diferente.

Configuración

Contar Puntos de Función automatizados requiere identificar y ensamblar en componentes funcionales todas las estructuras de datos y las transacciones, y decidir cuáles son internas o externas, temporales o no, para el usuario o no, y configurar todo eso. Esto supone:

• El conocimiento de la aplicación por el SME o experto del proyecto.
• El conocimiento de los Puntos de Función automatizados para determinar el alcance del análisis y los elementos que se deben tomar en cuenta.
• El conocimiento de la herramienta y sus parámetros para configurar el análisis, de acuerdo con los dos puntos anteriores.

Esta fase de configuración es obviamente crucial si queremos lograr un resultado más objetivo y por lo tanto lo más creíble posible cuando se trata de medir la productividad de un equipo.

Análisis y validación

Un recuento de Puntos de Función automatizado por una herramienta supone que esta sea capaz de:

• Analizar cualquier tipo de componente.
• Identificar todos los vínculos entre estos componentes.
• Ensamblar todos estos enlaces en caminos (‘path’) para constituir transacciones, con el mínimo posible de falsos positivos.

Pero es raro que una herramienta de análisis de código sea capaz de reconocer y analizar cualquier tipo de objeto y de archivo. Por ejemplo, una característica importante de nuestra aplicación de gestión de Timesheets será de producir hojas de actividades para su validación antes de facturación, usualmente en diferentes formatos: Excel, PDF, etc. No conozco ninguna herramienta de análisis de código que reconozca este tipo de archivo.

Buscar todos los vínculos entre los componentes puede ser difícil o imposible para algunas tecnologías. El uso de frameworks (Spring, Hibernate, etc.) complica este tipo de análisis, y supone un trabajo importante para validar los resultados con el fin de evitar falsos positivos, luego para comprobar las transacciones y el recuento de los puntos de función.

Conclusión

En conclusión, creo que los Puntos de Función automatizados son una medida diferente, que produce resultados distintos de un cálculo manual que lleva a cabo un consultor IFPUG. En una situación ideal, se requeriría la presencia de un tal consultor para participar en la definición del alcance del análisis, la configuración de la herramienta, la validación de los resultados. Esto suponiendo que la herramienta sea capaz de identificar todos los componentes, los vínculos entre ellos, todas las estructuras de datos y las transacciones, etc.

Incluso en tal caso ideal, creo que la diferencia entre una estimación manual y una medición de AFP es de al menos 10% a 20%, con mayor frecuencia entre el 40% y el 50%. Eso me parece un mínimo para unas aplicaciones o tecnologías específicas, y la diferencia podría ser más importante, por ejemplo, para una aplicación Cobol Batch (muchos archivos), un ERP con diferentes módulos integrados, en caso de frameworks, etc.

Automated Function Points: ¿para quién?

La puesta en marcha de Automated Function Points requiere un esfuerzo significativo, que debe repetirse cada vez que la aplicación será sometida a grandes cambios en sus funcionalidades (suponiendo que esta norma también se aplica a las nuevas versiones).

Esto excluye inmediatamente su uso en un ciclo de integración continúa, cuando el propósito de un análisis de código es identificar violaciones críticas o bloqueantes de buenas prácticas de programación para, por ejemplo, corregirlos antes de un Quality Gate o para evitar la inflación de la Deuda Técnica. Así que no veo cómo los desarrolladores pueden estar interesados ​​en AFP e integrarlos en un ciclo de desarrollo de software.

Esto no significa que los AFP no demuestran beneficios. Dos consultores IFPUG calculando manualmente puntos de función conseguirán muy a menudo resultados diferentes, mientras que una medición automatizada producirá siempre el mismo resultado, de manera repetible. El esfuerzo de implementación, incluso si es importante, sin embargo, será inferior a la inversión requerida para una estimación manual, especialmente para grandes aplicaciones.

Simplemente, se trata de otra medida que requiere una validación importante de los elementos de análisis  – inputs/outputs, internos/externos, temporal o no, para el usuario o no, estructuras de datos y transacciones, falsos positivos, etc. – para que se pueda utilizar como una medida de tamaño funcional de una aplicación.
Creo que está reservado para los expertos en análisis de código, pero también con un buen conocimiento de los puntos de función, si se quiere utilizar para hacer benchmarkings entre diferentes aplicaciones y tecnologías.

Me parece peligroso utilizarla para medir la productividad de los equipos o los proveedores: será demasiado fácil de impugnar los resultados producidos en dicho contexto.

Creo que puede ser útil como parte de una retro-documentación antes de transferir una aplicación a un otro equipo, una refactorización o una reingeniería (portar la aplicación a otra tecnología). En estos casos, todo lo que puede facilitar la comprensión funcional de la aplicación, la estimación de la cobertura de pruebas y la estimación de la carga de trabajo será útil, incluso si la medida carece de precisión.

Y tú, ves otros casos de uso de esta medida?

 

(1) IFPUG : International Function Points User Group, que produce el Function Point Counting Practices Manual (FP CPM).

Esta entrada está disponible también en Lire cet article en français y Read that post in english.