Point de fonction

Le point de fonction est une « unité de mesure » qui exprime la quantité de fonctionnalités métier qu'un système d'information (en tant que produit) fournit à un utilisateur. Les points de fonction sont utilisés pour calculer une mesure de taille fonctionnelle (MSF) d'un logiciel. Le coût (en dollars ou en heures) d'une seule unité est calculé à partir de projets antérieurs.

Il existe plusieurs normes reconnues et/ou spécifications publiques pour le dimensionnement des logiciels basés sur Function Point.

1. Normes ISO

• FiSMA : ISO/IEC 29881:2010 Technologies de l’information – Ingénierie des systèmes et du logiciel – Méthode de mesure de la taille fonctionnelle FiSMA 1.1.
• IFPUG : ISO/IEC 20926:2009 Ingénierie du logiciel et des systèmes – Mesure du logiciel – Méthode de mesure de la taille fonctionnelle IFPUG.
• Mark-II : ISO/IEC 20968:2002 Ingénierie logicielle – Analyse des points de fonction Ml II – Manuel des pratiques de comptage
• Nesma : ISO/IEC 24570:2018 Ingénierie logicielle – Méthode de mesure de la taille fonctionnelle Nesma version 2.3 – Définitions et lignes directrices de comptage pour l'application de l'analyse des points de fonction
• COSMIC : ISO/IEC 19761:2011 Ingénierie du logiciel. Méthode de mesure de la taille fonctionnelle.
• OMG : ISO/IEC 19515:2019 Technologies de l'information — Points de fonction automatisés du groupe de gestion des objets (AFP), 1.0

Les cinq premières normes sont des implémentations de la norme globale pour la mesure de la taille fonctionnelle ISO/IEC 14143. La spécification OMG Automated Function Point (AFP), dirigée par le Consortium for IT Software Quality , fournit une norme pour automatiser le comptage des points de fonction selon les directives de l'International Function Point User Group ( IFPUG ). Cependant, les implémentations actuelles de cette norme ont une limitation dans la capacité à distinguer la sortie externe (EO) des demandes externes (EQ) prêtes à l'emploi, sans configuration préalable.

Les points de fonction ont été définis en 1979 dans Measuring Application Development Productivity par Allan J. Albrecht chez IBM . Les exigences fonctionnelles des utilisateurs du logiciel sont identifiées et chacune est classée dans l'un des cinq types suivants : sorties, demandes de renseignements, entrées, fichiers internes et interfaces externes. Une fois la fonction identifiée et classée dans un type, elle est ensuite évaluée en termes de complexité et un certain nombre de points de fonction lui est attribué. Chacune de ces exigences fonctionnelles des utilisateurs correspond à une fonction métier de l'utilisateur final, telle qu'une saisie de données pour une entrée ou une requête utilisateur pour une demande de renseignements. Cette distinction est importante car elle tend à faire en sorte que les fonctions mesurées dans les points de fonction correspondent facilement aux exigences orientées utilisateur, mais elle tend également à masquer les fonctions internes (par exemple les algorithmes), qui nécessitent également des ressources pour être mises en œuvre.

Il n'existe actuellement aucune méthode FSM reconnue par l'ISO qui intègre la complexité algorithmique dans le résultat du dimensionnement. Récemment, différentes approches ont été proposées pour traiter cette faiblesse perçue, mises en œuvre dans plusieurs produits logiciels commerciaux. Les variantes de la méthode IFPUG basée sur Albrecht conçues pour compenser cette faiblesse (et d'autres) comprennent :

• Points de fonction précoces et faciles – S'adapte à la complexité du problème et des données avec deux questions qui produisent une mesure de complexité quelque peu subjective ; simplifie la mesure en éliminant le besoin de compter les éléments de données.
• Points de fonction d'ingénierie – Les éléments (noms de variables) et les opérateurs (par exemple, arithmétique, égalité/inégalité, booléen) sont comptés. Cette variante met en évidence la fonction de calcul. mesures de complexité Halstead basées sur les opérateurs/opérandes .
• Mesure de Bang – Définit une métrique de fonction basée sur douze comptages primitifs (simples) qui affectent ou montrent le Bang, défini comme « la mesure de la fonction réelle à fournir telle que perçue par l'utilisateur ». La mesure de Bang peut être utile pour évaluer la valeur d'une unité logicielle en termes de fonction utile qu'elle fournit, bien qu'il existe peu de preuves dans la littérature d'une telle application. L'utilisation de la mesure de Bang pourrait s'appliquer lorsqu'une réingénierie (complète ou par morceaux) est envisagée, comme indiqué dans Maintenance des systèmes opérationnels - Présentation.
• Points de fonctionnalité – Ajoute des modifications pour améliorer l'applicabilité aux systèmes avec un traitement interne important (par exemple, les systèmes d'exploitation, les systèmes de communication). Cela permet de prendre en compte les fonctions qui ne sont pas facilement perceptibles par l'utilisateur, mais qui sont essentielles au bon fonctionnement.
• Points de fonction micro pondérés – L’un des modèles les plus récents (2009) qui ajuste les points de fonction à l’aide de pondérations dérivées de la complexité du flux du programme, du vocabulaire des opérandes et des opérateurs, de l’utilisation des objets et de l’algorithme.
• Points de fonction flous - Propose une transition floue et graduelle entre les complexités faible x moyenne et moyenne x élevée

L'utilisation de points de fonction au profit de lignes de code cherche à résoudre plusieurs problèmes supplémentaires :

• Le risque d'une « inflation » des lignes de code créées, et donc d'une réduction de la valeur du système de mesure, si les développeurs sont incités à être plus productifs. Les partisans de la PF parlent de mesure de la taille de la solution plutôt que de la taille du problème.
• Les mesures de lignes de code ( LOC ) récompensent les langages de bas niveau car davantage de lignes de code sont nécessaires pour fournir une quantité similaire de fonctionnalités à un langage de niveau supérieur. C. Jones propose une méthode pour corriger cela dans son travail.
• Les mesures LOC ne sont pas utiles pendant les premières phases du projet, où il est difficile d'estimer le nombre de lignes de code à livrer. Cependant, les points de fonction peuvent être dérivés des exigences et sont donc utiles dans des méthodes telles que l'estimation par proxy.

Albrecht a observé dans ses recherches que les points de fonction étaient fortement corrélés aux lignes de code, ce qui a conduit à remettre en question la valeur d'une telle mesure si une mesure plus objective, à savoir le comptage des lignes de code, était disponible. En outre, de nombreuses tentatives ont été faites pour remédier aux lacunes perçues de la mesure en augmentant le régime de comptage. D'autres ont proposé des solutions pour contourner les défis en développant des méthodes alternatives qui créent un proxy pour la quantité de fonctionnalités fournies.