Nous nous sommes demandé, dans le post précédent, pourquoi les développeurs ne connaissaient généralement pas les Points de Fonction, et si cette métrique pouvait leur être utile.

Notre réponse est plutôt négative, surtout si l’on considère qu’une telle estimation est réalisée manuellement, par des consultants qui s’appuient sur une démarche assez complexe. Il existe d’ailleurs nombre de certifications dont l’objet est de valider qu’un consultant maîtrise ces concepts et sache les mettre en œuvre de manière opérationnelle.

Pas vraiment de quoi attirer des développeurs qui, selon moi, vont plutôt préférer s’investir dans une nouvelle technologie, un nouveau langage, le dernier framework à la mode, un développement Open Source, etc.

Imaginons maintenant que le calcul des Points de Fonction puisse être automatisé : cela suffirait-il pour que les développeurs utilisent cette mesure ?

Automated Function Points (AFP)

L’OMG a réalisé une norme de spécifications décrivant les conditions à remplir par un logiciel afin d’automatiser la mesure des Points de Fonction.

Limitations

Ce document énonce certaines différences avec une estimation manuelle des Points de Fonction. Par exemple, le paragraphe « 1.3 Limitations » explique que cette norme ne s’applique pas à « la mesure des évolutions d’une application ou de la maintenance de fonctionnalités [existantes], encore appelés Enhancement Function Points ».

Si c’est bien le cas, ce serait alors une divergence assez importante puisque les Points de Fonctions automatisés ne concerneraient dés lors que des développements nouveaux, et non pas des versions successives d’une application. Or nous savons bien que 80% ou 90% des projets portent sur de la maintenance applicative et que les projets nouveaux sont assez largement minoritaires.

D’ailleurs, ces spécifications ne prétendent pas (paragraphe « 2.1 Conformance ») à une stricte conformité avec la mesure manuelle des Points de Fonction, ne serait-ce que par les difficultés soulevées pour complètement automatiser … un processus manuel. Le paragraphe « 2.3 Consistency with IFPUG CPM » explique ainsi que « cette norme effectue des choix explicites » lorsque, dans certaines situations, les règles édictés par l’FPUG (1) peuvent se révéler assez vagues.

Ce même paragraphe explique qu’un consultant IFPUG sera amené à effectuer certaines interprétations en matière de conception et de développement d’éléments fonctionnels, ce qui est évidemment impossible pour un outil logiciel, qui ne peut décider de lui même si telle structure de données ou telle transaction est importante ou non pour l’application : « il [le logiciel] ne peut capturer aucune des intentions du concepteur qui ne laisse une empreinte dans le code source ».

Donc la norme elle-même explique clairement que « le comptage des Automated Function Points … peut différer des comptages manuels produits par un consultant IFPUG certifié ».

Mise en œuvre de la norme

Le reste du document liste les différentes étapes de calcul des AFP. Je ne vais pas détailler ces opérations mais simplement lister ce qui, sur la base de mon expérience en matière d’outils d’analyse de code, risque de provoquer des écarts avec un comptage manuel ou d’avoir des conséquences pour la mise en œuvre de cette norme dans le cadre d’un cycle de vie de projet.

Frontières

La première étape consiste à définir les frontières (‘boundaries’) fonctionnelles de l’application, du point de vue de l’utilisateur, afin de déterminer ce qui est dans l’application, et donc le code correspondant à analyser, et ce qui est externe à l’application et donc hors de l’analyse automatisée des Points de Fonction.

Prenons comme exemple une application toute simple de Gestion des feuilles d’activités (Timesheets) pour une SSII, dans laquelle un prestataire va saisir les tâches et temps passés pour un client, à fin de facturation. Cette application ne va pas gérer elle-même les employés de la société de services, mais récupérer ces informations depuis le système de gestion des Ressources Humaines. De même, les différents types d’activité, facturables ou non, et leur code, sont habituellement gérés par le système comptable. Et les informations concernant le client et la prestation à réaliser devraient se retrouver dans le système commercial.

Si notre application de Gestion des Timesheets effectue elle-même les traitements d’accès aux données de ces autres systèmes, alors ceux-ci sont internes à l’application et donc doivent être pris en compte dans notre évaluation de Points de Fonction automatisés. Si au contraire, il est fait appel à des composants de ces autres systèmes afin d’obtenir les données nécessaires, alors ces traitements sont externes et ne sont pas dans le périmètre d’analyse.

Parfois, pour ne pas dire souvent, le choix sera difficile voire impossible. Si vous avez des web-services entre vos applications, où les rattacher ? A quelle application ? Doivent-ils être pris en compte ? Vous avez des Copybooks, équivalents à des ‘includes’ pour une application Mainframe-Cobol, qui décrivent les tables DB2, et sont réutilisables par toutes les applications accédant à ces tables. Si 15 applications utilisent une même table, elles travailleront toutes avec un même Copybook. A quelle application rattacher celui-ci ? Comment faire lorsque nous sommes en face d’un ERP ou autre progiciel composé de différents modules fortement intégrés et imbriqués ?

Découpage du code applicatif

Evidemment, vous devez vous poser ces mêmes questions chaque fois que vous configurez une nouvelle analyse de code, que ce soit pour compter des Points de Fonction ou non. Mais si vous vous intéressez uniquement à la qualité du code, savoir si tel composant appartient ou non à telle application n’est pas critique : vous souhaitez seulement contrôler si ce composant présente ou non des violations aux bonnes pratiques de programmation. C’est ce qui se passe généralement, par exemple pour des applications Mainframe Cobol, même si l’on va souvent tenter de découper celles-ci selon certains critères utiles pour notre évaluation de la qualité, par exemple selon leur nature Batch ou Transactionnelle, parce qu’un défaut en matière de performance sera plus grave pour une application TP avec un utilisateur devant son écran que pour une application Batch sans utilisateur et qui s’exécute durant la nuit.

Lorsque les frontières applicatives ne sont pas précises, le second critère le plus utilisé en matière de découpage du code et de configuration des analyses sera organisationnel : rassembler tous les composants gérés par une même équipe, et localisé généralement dans un espace (répertoire réseau, bibliothèque mainframe, outil de gestion de configuration, etc.) administré par cette équipe. Ce découpage s’avère critique dans certains Use Cases, par exemple pour une Quality Gate ou un benchmarking sur la qualité de code entre vos outsourceurs ou vos équipes internes. Dans ces cas là, vous vous intéressez aux défauts ajoutés ou corrigés dans les versions successives de l’application, afin de décider de l’acceptation ou du rejet d’une nouvelle version ou si votre outsourceur travaille correctement ou non, s’il fait ou non les efforts nécessaires pour s’améliorer et comment il se compare avec vos autres fournisseurs.

C’est également ce critère organisationnel – qui gère quel composant – que nous devons privilégier si l’on souhaite mesurer la productivité des développeurs. Mais je vois poindre quelques difficultés supplémentaires. D’abord, la nécessité de précision et de rigueur est bien plus importante. Si vous dites à un développeur que vous avez trouvé la même violation aux bonnes pratiques de programmation dans 10 composants qu’il a modifiés, et qu’en fait l’un d’entre eux ne relève pas de sa responsabilité, il n’en reste pas moins qu’il a répété cette malpractice dans 9 composants sur 10, et donc qu’il doit s’améliorer. En fait, dans le cas d’une Quality Gate, une seule occurrence suffit, si elle est bloquante. Mais si vous dites à un développeur ou un outsourcer qu’il ne travaille pas assez, et que vous omettez un seul composant dans votre analyse automatisée des Points de Fonction, votre conclusion sera forcément contestée. Un développeur peut passer plusieurs heures ou plusieurs jours sur une simple méthode ou une unique fonction. Omettre un seul objet parmi plusieurs milliers peut fausser les résultats, et donc une rigueur extrême est nécessaire dans le cadre de ce Use Case particulier des Points de Fonction automatisés.

Autre problème : vous ne vous intéressez qu’au code modifié par l’équipe de projet, car de même que vous ne pouvez pas tenir un outsourceur responsable des défauts déjà présents dans le code qu’il a reçu pour maintenance, de même vous n’allez pas mesurer sa productivité sur du code qu’il n’a pas réalisé. Or vous ne pouvez pas mesurer les Points de Fonction uniquement sur du code modifié : vous devez identifier des structures fonctionnelles et les transactions rattachées à celles-ci, depuis la couche de présentation jusqu’à la couche de données. Ce n’est possible qu’en ré-analysant toute l’application et en calculant la différence en nombre de Points de Fonction avec une version précédente, en admettant que cette norme s’applique à des versions nouvelles (cf. la limitation évoquée ci-dessus).

C’est donc plus compliqué mais également plus délicat à interpréter. Imaginons deux équipes qui ont produit toutes deux 100 Points de Fonction, la première dans une application qui mesure 1 000 FP, la seconde dans une application qui en compte 10 000. J’imagine que l’effort n’est pas le même, de la même manière qu’on ne peut comparer le travail d’ajout de 1 000 lignes de code (LOC) dans une application selon qu’elle en compte 10 000 ou 100 000. D’ailleurs, certains experts considèrent que le comptage des Points de Fonction doit être effectué différemment pour des tailles d’application très petites ou très élevées.

Dernière chose : vous devez exclure de votre analyse les librairies, frameworks, composants réutilisables et autres dépendances externes à votre application, mais également toutes les tables ou fichiers qui ne relèvent pas de l’application. Cependant, il faudra analyser ces objets afin de trouver les transactions entre les différentes couches de l’application, et donc prendre en compte ceux-ci dans l’analyse mais « les identifier clairement comme externe » à celle-ci, comme indiqué dans les spécifications de la norme OMG.

Ce document souligne l’importance de cette étape de définition du périmètre d’analyse, et requiert pour ce faire la présence d’un Subject Matter Expert (SME), voire d’un « application owner ».

Analyse

Le reste du document recense et précise les différentes étapes du processus de comptage. Retenons la nécessité :

• d’identifier toutes les fonctions dans le code et de les classer en Data functions et Transactional functions,
• tout en prenant en compte le caractère externe ou interne des structures de données de l’application,
• avant de procéder à l’estimation des Points de Fonctions pour chacune d’entre elles.

Ces requirements nécessitent que le logiciel d’analyse de code soit en mesure de prendre en compte les bases de données relationnelles ou non – certaines applications Cobol utilisent des bases de données hiérarchiques – mais aussi toutes sortes de fichiers, ce qui n’est pas le plus naturel pour un tel outil qui s’intéresse avant tout au code.

Il faut également pouvoir identifier chaque structure logique de données afin de pouvoir ‘mapper’ celles-ci avec les transactions. Or ces structures peuvent être réparties sur plusieurs tables, et le document précise les contraintes à respecter pour identifier les structures de type ‘master-detail’. Dans notre exemple de Gestion des Timesheets, un même prestataire remplit plusieurs timesheets, éventuellement pour différents clients. Chaque timesheet sera composé de plusieurs activités, ce qui signifie que la table ‘Timesheet’ sera de nature ‘detail’ pour les entités ‘Prestataire’ ou ‘Client’, et ‘master’ pour les ‘Activités’.

La norme OMG recommande de s’appuyer sur les conventions de nommage afin de reconnaître les tables, vues, index, clés, etc. qui permettent d’identifier ces structures de données et leurs relations.
Cela suppose que :

• ces conventions de nommage existent,
• qu’elles soient appliquées par l’équipe de projet,
• que le logiciel d’analyse soit configuré afin de reconnaître ces règles.

Il faut également pouvoir analyser tout type de fichier et leur structure interne – tabulaire (flat-files, fichiers CSV, etc.) ou arborescente (xml, html, etc.). Sauf que dans ce cas, nous ne disposons pas de clés ou indexs pour identifier les structures de données logiques, et que le software de calcul des AFP devra effectuer un choix – le plus souvent considérer ce fichier comme une entité logique unique – qui ne sera pas forcément celui effectué par un consultant IFPUG.

Il faut aussi pouvoir définir si un fichier est temporaire ou non, et si les données qu’il contient sont ou non gérées par l’utilisateur. Par exemple, un fichier log ou d’erreurs, utilisable uniquement par le programmeur, doit être exclu du périmètre d’analyse.

Une fois les structures de données identifiées, il faut pouvoir faire de même avec les transactions qui gèrent ces données à travers les couches de l’application, et identifier celles en entrée (inputs) de celles en sortie (outputs), à travers les opérations réalisées selon qu’il s’agit de lire ou d’écrire ou de modifier/supprimer ces données. Ceci suppose, selon la norme, de :

• « capturer les transactions depuis l’interface utilisateur »,
• « d’identifier les événements utilisateur qui interagissent avec la couche de données » et
• « les outputs utilisateur créés depuis ces fonctions de [manipulation de] données.

Toujours selon le document, identifier ces transactions nécessite de :

• pouvoir trouver tous les liens entre les différents objets, qui constituent un chemin depuis le début et jusqu’á la fin de la transaction ;
• pouvoir prendre en compte les multiples chemins existants, afin d’y rattacher toutes les opérations sur les structures de données, en une unique transaction ;
• pouvoir déclarer dans l’outil des éléments de code externe et non analysés, afin de pouvoir reconstituer ces transactions, ou tout au moins, lister les éléments manquants. Afin de pouvoir reconstituer une transaction complète, il faut parfois analyser des éléments externes à l’application, donc inclure ceux-ci dans le périmètre d’analyse tout en les excluant du comptage.

Automated Function Points : quelle mesure ?

Comme nous pouvons le voir, le document de la norme OMG précise les conditions nécessaires à l’utilisation des Points de Fonction Automatisés, ainsi que ses limites. Les points qui me paraissent plus importants à retenir sont les suivants.

Périmètre

La norme ne s’applique pas à « la mesure des évolutions d’une application ou de la maintenance de fonctionnalités », et donc ne concernerait que les nouveaux développements. Si c’est bien le cas, cela limite fortement son usage et son intérêt.

Mesures AFP et IFPUG

La norme ne prétend pas à une stricte conformité avec un comptage manuel des Points de Fonction, puisque « le comptage des Automated Function Points … peut différer des comptages manuels produits par un consultant IFPUG certifié ».

Ceci me paraît un premier point important à souligner : les Points de Fonction Automatisés ne sont pas les Points de Fonction IFPUG. Il s’agit d’une autre mesure, qui présente l’avantage d’être calculable de manière automatique par un outil, et donc avec moins d’efforts qu’un comptage manuel, mais pour un résultat différent également.

Paramétrage

Le comptage de Points de Fonction automatisés nécessite d’identifier et d’assembler en composants fonctionnels toutes les structures de données et les transactions, et de décider lesquelles sont internes ou externes, et à prendre ou non en compte lors du paramétrage de l’outil et de l’analyse. Ceci suppose de maîtriser :

• La connaissance de l’application par un SME ou expert du projet.
• La connaissance du comptage automatisé des Points de Fonction, afin de déterminer le périmètre d’analyse et les éléments à prendre en compte.
• La connaissance de l’outil et de son paramétrage afin de configurer l’analyse, en accord avec les deux points précédents.

Cette phase de paramétrage est évidemment critique si l’on souhaite parvenir à un résultat le plus objectif et donc le plus crédible possible lorsqu’il s’agit de mesurer la productivité d’une équipe.

Analyse et validation

Le comptage de Points de Fonction automatisés par un outil suppose que celui-ci soit capable :

• D’analyser tout type de composant.
• D’identifier tous les liens entre ces composants.
• D’assembler tous ces liens en transactions avec le moins de false-positives possible.

Or il est bien rare qu’un outil d’analyse de code soit capable de reconnaître et d’analyser tout type de fichier. Une fonctionnalité importante d’une application de Gestion des Timesheets comme celle de notre exemple sera la production de rapports – les feuilles d’activité – pour validation avant facturation, généralement sous différents formats : Excel, PDF, etc. Je ne connais aucun outil d’analyse de code qui gère ce type de fichiers.

Trouver tous les liens entre composants peut s’avérer difficile, voire impossible pour certaines technologies. L’utilisation de frameworks (Spring, Hibernate, etc.) rend complexe ce type d’analyse et suppose un travail important de validation des résultats afin d’éviter le plus possible les false-positives, puis de vérifier les transactions identifiées et le comptage des Points de Fonction pour celles-ci.

Conclusion

En conclusion, je pense que les Automated Function Points sont une mesure différente, qui produira des résultats différents d’une estimation manuelle conduite par un consultant IFPUG. Dans une situation idéale, il faudrait la présence d’un tel consultant afin de participer à la définition du périmètre d’analyse, le paramétrage de l’outil, la validation des résultats, ceci en supposant que l’outil soit capable d’identifier tous les composants, les liens entre ceux-ci, les structures de données, les transactions, etc.

Même dans un tel cas idéal, je pense que la différence entre une estimation manuelle et une mesure des AFP sera au minimum de 10% à 20%, et plus souvent entre 40% et 50%. Cela me paraît un minimum sur certaines applications ou technologies, et l’écart pourrait s’avérer plus important, par exemple pour une application Cobol Batch (beaucoup de fichiers), un logiciel intégré avec différents modules (type ERP), en cas d’utilisation de frameworks, etc.

Automated Function Points : pour qui ?

La mise en oeuvre des AFP suppose un effort important, qui doit être répété chaque fois que l’application subira des évolutions importantes dans ses fonctionnalités (en admettant que cette norme s’applique également aux nouvelles versions).

Ceci écarte d’emblée l’utilisation des AFP dans un cycle d’intégration continue, lorsque l’analyse de code vise à identifier des violations critiques ou bloquantes aux bonnes pratiques de programmation, afin par exemple de corriger celles-ci avant une Quality Gate ou pour éviter l’inflation de la Dette Technique. Je ne vois donc pas comment les développeurs pourraient s’intéresser aux AFP et les intégrer dans un cycle de développement logiciel.

Cela ne signifie pas que les AFP ne présentent pas d’intérêt. Deux consultants IFPUG procédant à une estimation manuelle de Points de Fonction parviendront assez souvent à des résultats différents, alors qu’une mesure automatisée produira un même résultat, de manière répétable. L’effort de mise en œuvre, même s’il est important, sera néanmoins inférieur à l’investissement requis pour une estimation manuelle, notamment pour des applications volumineuses.

Simplement, il s’agit d’une autre mesure qui nécessite une validation importante des éléments d’analyse – inputs/outputs, internes/externes, structures de données et transactions, false positives, etc – pour être utilisée en tant que mesure de la taille fonctionnelle d’une application.
Je pense qu’elle est réservée à des experts en matière d’analyse de code, mais aussi avec une bonne connaissance des Points de Fonction, si l’on souhaite l’utiliser pour effectuer des benchmarkings entre différentes applications ou technologies.

Elle me paraît dangereuse à utiliser telle quelle pour des mesures de la productivité d’équipes ou d’outsourceurs : il sera très facile de contester les résultats produits dans un tel cadre.

Je pense qu’elle peut être utile dans le cadre d’une rétro-documentation, avant une reprise de l’application, un refactoring ou un re-engineering (portage de l’application dans une autre technologie). Dans ces cas, tout ce qui peut faciliter la compréhension fonctionnelle de l’application, l’estimation de la couverture de tests et le chiffrage de la charge de travail sera le bienvenu, même si la mesure manque de précision.

Voyez-vous d’autres cas d’utilisation pour une telle mesure ?

 

(1) IFPUG : International Function Points User Group, qui produit le Function Point Counting Practices Manual (FP CPM).

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.