Points de fonction – comparaison

Nous examinons les différentes façons de mesurer la taille d'un logiciel

Le dimensionnement d’un logiciel n’est pas chose aisée, car il existe des centaines de langages, d’architectures et de techniques pour l’écrire. L’industrie a essayé de nombreuses approches différentes au fil des ans, mais la plus efficace est celle appelée dimensionnement fonctionnel. Connaître la taille est généralement le plus utile avant que le code ne soit écrit. La taille peut également être un indicateur de la quantité de fonctionnalités métier impliquées. Des techniques telles que le comptage des user stories, le comptage des story points et les principales méthodes d'analyse des points de fonction : les points de fonction COSMIC et les points de fonction traditionnels (IFPUG) sont tous abordés ici. Il est également possible d'évaluer la taille après l'écriture du code, ce qui est généralement moins utile.

Allez droit au but : nous vous recommandons d’utiliser les points de fonction COSMIC dans la plupart des cas. Pourquoi? parce qu'ils sont valides, fiables, cohérents, impossibles à jouer, rapides à mesurer et adaptés au travail Agile où les exigences complètes peuvent ne pas être connues à l'avance.

Pourquoi le dimensionnement des logiciels est-il important ?

Le développement de logiciels est un travail de connaissances à forte intensité de main-d'œuvre. Le facteur de coût le plus important pour le développement d’un logiciel est généralement l’effort humain nécessaire pour le créer, le concevoir et le tester. Ce que nous voulons généralement savoir, c'est combien d'efforts et combien de temps il faudra pour livrer. De nombreux facteurs affectent le temps et les efforts. Le facteur le plus important est taille du logiciel.  Examinons donc les différentes approches de dimensionnement des logiciels. On confond souvent dimensionnement et estimation de l’effort. Par exemple, les story points et la taille des t-shirts ne sont en réalité qu'une estimation de l'effort, pas une taille.

Lignes de code

Les lignes de code sont créées facilement et automatiquement par la plupart des outils de codage. Il existe deux valeurs principales, le nombre brut de lignes utilisées (LOC) et le nombre net de lignes de code fonctionnel (SLOC).

Compter les lignes de code a un intérêt limité dans la gestion de projets logiciels. Prenons par exemple deux développeurs qui écrivent tous deux 50 lignes de code par jour. Il se peut que l’un des développeurs écrive un code concis et efficace qui fasse bon usage des capacités du langage sous-jacent. Ses 50 lignes offrent des fonctionnalités importantes, peut-être même une (petite) application entière, alors que l'autre pourrait simplement effectuer une validation très basique. En apparence, ils sont aussi productifs les uns que les autres, écrivant tous deux 50 lignes par jour. C'est la principale raison pour laquelle nous limitons l'utilisation de SLOC pour le dimensionnement des logiciels. RAPIDE, INCONSISTANT, TROMPEUR

Compter les histoires

Beaucoup de gens pensent que le simple fait de compter le nombre d’histoires équivaut à n’importe quoi. Il s'agit d'une approche peu fiable, car certaines user stories sont des projets de développement importants, nous pourrions vraiment les appeler des épopées, alors que d'autres user stories sont si triviales qu'elles n'impliquent aucune fonctionnalité reconnaissable par l'utilisateur. La plage que nous voyons généralement est de 0 à 120 CFP. Comme vous pouvez le constater, nous utilisons la méthodologie de dimensionnement COSMIC pour valider si d'autres approches ont du mérite. RAPIDE, INCONSISTANT, TROMPEUR

Compter les points d'histoire

Les story points sont un proxy arbitraire pour la mesure de la taille qui ne doit être utilisé qu'au sein d'une équipe. Ils ne constituent pas une mesure ni un indicateur valable pour déterminer les progrès réalisés par rapport à l’équipe. N'oubliez pas que les story points peuvent changer avec le temps et constituent une opinion incohérente sur la durée probable d'une activité. Ils sont hautement jouables par ceux qui fournissent le décompte. La popularité des story points est un comportement quelque peu bizarre de la majorité de l’industrie du logiciel – leur popularité n’est pas méritée. D'autre part, COSMIC Sizing et IFPUG Sizing sont tous deux des normes ISO formelles et cohérentes pour mesurer la taille.

La taille d’une user story peut varier considérablement. Une histoire peut être livrée en quelques minutes, une autre peut nécessiter le travail d’une équipe entière pendant un mois. Compter des histoires de différentes tailles est une indication de progrès mais ne constitue pas une mesure valable du progrès.  LENT, INCOhérent, TROMPEUR

Analyse des points de fonction

Dimensionnement fonctionnel norme ISO

La seule façon cohérente de mesurer la taille des logiciels (à partir de 2023) est le dimensionnement fonctionnel. Il existe deux principales normes en matière de dimensionnement fonctionnel :   Points de fonction IFPUG (1ère génération) et  Points de fonction cosmique Points (2e génération).

Les deux normes Function Point sont matures, valides et éprouvées (IFPUG : 1974, COSMIC : 1998). Elles constituent une description et une mesure cohérentes et centrées sur l’utilisateur de la fonctionnalité en termes d’entrées et de sorties et de données stockées. Ils sont comptés en examinant les exigences et en appliquant certaines règles/principes pour déterminer les types de données qui sont déplacés et stockés. Les deux normes sont matures, entretenues de manière indépendante et leur apprentissage est gratuit ou peu coûteux. Nous recommandons la méthodologie de dimensionnement COSMIC de 2e génération. Les unités de la méthodologie de dimensionnement COSMIC sont le COSMIC Function Point (CFP). Le travail pour effectuer le dimensionnement des points de fonction est appelé analyse des points de fonction (FPA).

Points de fonction cosmique. RECOMMANDÉ

Certains des principaux avantages de la norme COSMIC FP sont :

1. COSMIC Sizing est basé sur les principes de conception logicielle. En standard, aucun réglage n'est nécessaire lorsqu'il est appliqué à différents types de logiciels (codage personnalisé, middleware, applications Web, logiciels multicouches, logiciels système, systèmes embarqués ou projets d'entrepôt de données).
2. COSMIC nous donne une définition d'un point de fonction unique, chaque mouvement d'un groupe de données Entrée, Sortie, Lecture, Ecriture compte pour 1 CFP.
3. Le CFP peut être mesuré avec précision à partir d'exigences incomplètes, ce qui les rend adaptés à Agile et à diverses formes de travail Agile à grande échelle.
4. Les CFP sont plus rapides et plus faciles à apprendre que IFPUG FP. (1/3 des pages numériques pour l'ensemble du programme de méthodologie)
5. COSMIC FP peut être déterminé automatiquement avec un degré de précision plus élevé que IFPUG via une analyse automatisée des exigences.

Pour en savoir plus sur le dimensionnement COSMIC, nous vous recommandons Le guide du dimensionnement des logiciels par Charles Symons

Points de fonction IFPUG

Cela dit, les COSMIC FP sont préférables aux IFPUG FP traditionnels, ces derniers bénéficient de volumes plus importants de données de référence publiées et disponibles. La méthodologie de dimensionnement IFPUG a été conçue dans les années 1970, lorsque la conception de logiciels était moins stratifiée et séparée qu'elle ne l'est aujourd'hui. Les normes restent largement inchangées par rapport à leur concept initial. Nous aimons IFPUG FP, mais nous préférons COSMIC FP. Simple Function Points est une approximation de l'IFPUG FP adoptée par l'organisation en 2019. ScopeMaster estime à la fois IFPUG et PF simple.

Compter manuellement les points de fonction

Jusqu'à présent, le comptage des points de fonction était un processus manuel laborieux. Vous devez lire les exigences, puis enregistrer le nombre de points de fonction sur papier ou dans une feuille de calcul. Des comptages précis et cohérents ne sont obtenus que s’ils sont effectués par un spécialiste des points de fonction certifié et expérimenté. En moyenne, un mesureur certifié peut mesurer jusqu'à 2 000 FP/semaine, ce qui équivaut à environ $2m de logiciel.  LENT, PRÉCIS

Estimation de la taille des points de la fonction

En utilisant quelques règles empiriques, il est possible d’estimer le nombre de PF en examinant un certain nombre de facteurs contributifs. Si votre application est principalement une application de type base de données, vous pouvez compter le nombre de tables de base de données contenant des données gérées par l'application. Vous multipliez ensuite le nombre de tables par 27 à 30 pour une estimation IFPUG. Il ne s’agit là que d’une des nombreuses règles empiriques utiles sur laquelle on ne devrait pas s’appuyer pour autre chose qu’une taille de haut niveau. Vitesse de comptage : 5 000 – 50 000 FP / personne semaine  RAPIDE, INEXACTE

Points de fonction retour de flamme à partir de lignes de code

La plupart des langages logiciels ont publié des moyennes de lignes de code par point de fonction. Par exemple, 50 lignes de Java équivalent en moyenne à un point de fonction. Compter les lignes de code et diviser par ce nombre est appelé « retour de flamme ». C'est utile après le code a été écrit. Vous devez être prudent avec cette approche, en particulier lorsque vous utilisez de grands volumes de frameworks pré-écrits qui peuvent devoir être exclus d'un décompte de code personnalisé. Vitesse de comptage : jusqu’à 5 000 FP/personne semaine.  RAPIDE, INEXACT, TROMPEUR

Nombre de points de fonction automatisés à partir du code

Il est désormais possible d'automatiser le comptage de points de fonction à partir du code. La société Cast Software a développé un logiciel qui effectuera un décompte automatisé fiable des points de fonction basé sur le code d'application existant. Il faut un certain effort pour préparer le code afin qu'il puisse être interprété, après quoi un décompte fiable peut être obtenu. C’est de loin supérieur à l’approche retour de flamme. Il présente l’avantage supplémentaire de fournir un aperçu approfondi du code de l’application.   RAPIDE, COHÉRENT, PRÉCIS

Dimensionnement automatisé des points de fonction COSMIC

En utilisant ScopeMaster®, vous pouvez bénéficier d'un décompte automatisé des points de la fonction COSMIC en quelques minutes. En analysant le texte des besoins des utilisateurs, nous pouvons détecter la taille fonctionnelle (mouvements de données). ScopeMaster® fournira un résultat cohérent avec une précision supérieure à 85% par rapport à un comptage manuel effectué par un mesureur expert.

Les résultats sont cohérent et transparent. En combinaison avec un contrôle manuel par un spécialiste des points de fonction, nous constatons des taux de comptage de 10 000 à 20 000 FP/par semaine-homme. (environ $10- $20m de logiciel) RAPIDE, COHÉRENT, ASSEZ PRÉCIS

Certaines des analyses de dimensionnement qui ScopeMaster® génère automatiquement à partir de vos user stories écrites.

Conclusion

Si vous souhaitez déterminer la taille d'une application des exigences écrites vous avez deux choix principaux : compter les points de fonction manuellement ou utiliser ScopeMaster® pour les compter pour vous. Si vous disposez déjà d'un code d'application que vous souhaitez mesurer, il existe des choix supplémentaires : retour de flamme à partir des lignes de code, estimation à partir de composants techniques (par exemple sur la base d'un nombre de tables de base de données), ou regardez l'automatisation du dimensionnement fonctionnel à partir du logiciel CAST. .