|
|
|
|
|
La moyenne pour chaque module i est donnée par :
Mi =
((Vmini + Vmaxi + 4 * Vpi) Jean
+
(Vmini + Vmaxi + 4 * Vpi) Pierre) / 12
Nous avons vu comment exploiter les estimations données par Pierre et Jean pour les différents modules, afin d'en déterminer une durée estimée globale et une précision.
Ce résultat est néanmoins assez peu utile, car si il s'avère correct, aussi bien que s'il se révèle en fin de compte totalement faux, il n'a été obtenu que sur la base des évaluations " à vue " de Pierre et Jean, et rien ne garantit que ces évaluation seront aussi bonnes ou meilleures la prochaine fois.
Rien ne permet non plus de savoir, le cas échéant, pourquoi elles sont fausses et comment les améliorer. Nous allons maintenant étudier deux méthodes, qui, combinées nous permettrons, sinon d'obtenir de meilleures résultats, du moins de les justifier, et, donc, de pouvoir éventuellement les améliorer au fil du temps.
Les Points de Fonction ont été inventés par A.J. Albrecht, d'IBM, au milieu des années 70.
Albrecht était chargé de mesurer la productivité des équipes de développement. La productivité étant définie comme " la quantité de travail par unité de temps ou de coût ", il s'agissait de trouver une mesure du travail des programmeurs.
Ceux-ci utilisaient des langages variés, et Albrecht a constaté - comme d'autres avant lui - que la taille du code produit (mesuré en nombre d'instructions ou de lignes) ne pouvait constituer une métrique appropriée2. Son originalité est d'avoir su dépasser ce problème et d'avoir proposé la métrique des Points de Fonction.
Un Point de Fonction est une unité abstraite qui mesure la complexité ou la richesse d'une application en terme de fonctionnalités.
L'intérêt de la méthode d'Albrecht tient en ce que le nombre de Points de Fonction d'un programme ne dépend pas de la manière dont il a été réalisé mais des services qu'il peut rendre.
Les Points de Fonction constituent donc une métrique très utile pour comparer des applications, mesurer la productivité d'une équipe (nombre de Points de Fonction produits par unités de temps), la qualité d'un programme (nombre d'erreurs par Point de Fonction), comparer des coûts de réalisation lorsque les outils employés diffèrent.
Un Point de Fonction ne signifie rien en lui-même, mais c'est une unité de mesure extrêmement utile aux producteurs de logiciel, au même titre que le mètre carré corrigé en immobilier.
Le principe du calcul des Points de Fonction repose sur le recensement d'éléments fonctionnels que sont les possibilités d'interaction entre l'utilisateur et
|
|
|
|
|
|
|
|
|
|
|
l'application ou entre différentes applications, auxquels sont ensuite appliqués des poids respectifs.
Le total de ces poids donnant un nombre de Points de Fonction dits Bruts (PFB), qui est ensuite corrigé en fonction de la difficulté de programmation de certaines de ces interactions pour obtenir un nombre de Points de Fonction Ajustés (PFA).
La première publication de la méthode des Points de Fonction date de 1979, mais elle a inspiré de très nombreux travaux et a connu plusieurs évolutions et variations.
Parmi les principales on peut citer les travaux de De Marco (" Bang " Functional Metrics) en 1982, qui proposent une version plus élaborée de la méthode d'Albrecht, appliquée aux logiciels scientifiques.
IBM a, pour sa part, publié en 1984 une révision de la méthode des Points de Fonction qui précisait les règles de comptage des Points de fonction et détaillait l'ajustement de ceux-ci en fonction de la complexité et des contraintes de programmation (l'impact potentiel de la complexité sur la taille du programme est alors passé de 25 à 250 %).
Un grand pas vers la normalisation a ensuite été franchi en 1986 avec la création du Groupe International des Utilisateurs des Points de Fonction (IFPUG) qui standardise depuis la terminologie et les règles utilisées dans le comptage des Points de Fonction.
On doit notamment à l'IFPUG la variante des Points de Fonction appelée "Points de Fonctionnalité" ("Feature Points" chez leurs auteurs, anglo-saxons) qui introduit un paramètre fonctionnel supplémentaire, les algorithmes mis en oeuvre, de façon à pouvoir être appliquée aux logiciels systèmes ou scientifiques qui ne produisent que peu de résultats mais plutôt des services (de calcul, d'accès au matériel ...).
La dernière publication par l'IFPUG des méthodes des points de fonctions et des points de fonctionnalités porte la référence 4.0.
C'est cette révision que j'ai retenue, car elle est tout à fait adaptée à la variété des applications que l'on développe avec Delphi et car, de par son utilisation à grande échelle, une large documentation est accessible sur les pratiques de la méthode.
Nous en étudierons les détails pratiques dans le prochain numéro.
______________________________
1 A l'exception notable du secteur du bâtiment et des travaux publics.
2 Albrecht avait déjà montré, en 1978, qu'une métrique basée sur les lignes de code pénalise les langages évolués. Ainsi pour un même projet réalisé avec deux langages :
Assembleur Ada
Analyse 2 mois 2 mois
Codage 3 mois 1 mois
Nb Lignes 10 000 3 000
Productivité 2 000 lig/mois 1 000 lignes /mois
|
|
|
|
|
|
|