« On ne peut pas gérer ce que l’on ne sait pas mesurer », cette phrase attribuée au statisticien W. Edwards Deming est l’un des principes les plus importants en gestion d’entreprise et cela parait évident. Par exemple, un amateur de course à pied ne pourra pas savoir s’il progresse s’il ne se chronomètre jamais.  Ce principe s’applique également dans le domaine de l’ingénierie logicielle, et pour cela, il y a la mesure logicielle.

Mesurer la taille de vos projets logiciels avant leur lancement, c’est capital. C’est comme repérer son itinéraire sur une carte avant de partir en voyage ou étudier les plans d’une maison avant de démarrer les travaux.

La capacité d’un éditeur de logiciels à pouvoir mesurer la taille d’un projet tôt dans son cycle de vie (avant même la phase de développement) est la clé de la bonne gestion et du contrôle des ressources.

Sommaire

1. 1. 1. La taille logicielle fonctionnelle
      2. Qu’est-ce qu’un Point de Fonction ?
      3. La méthode IFPUG
      4. La méthode COSMIC

La taille logicielle fonctionnelle

La principale mesure est la taille logicielle, et plus précisément, la taille fonctionnelle. L’unité de mesure de la taille logicielle la plus répandue est le Point de Fonction. Cette taille logicielle peut également être mesurée en lignes de code, c’est-à-dire, le nombre de lignes de code fonctionnel sans les commentaires.

Bien qu’il soit intéressant de connaître le nombre de lignes de code, cette mesure est un indicateur de l’effort fourni, mais elle ne représente pas les fonctionnalités offertes par l’application. Si deux développeurs développent une même fonction à l’aide de deux techniques différentes, il est fort à parier que l’un n’aura

besoin que de quelques lignes de code, alors que l’autre devra en rédiger bien plus pour obtenir le même résultat. La méthode de mesure de la taille la plus fiable est indépendante de la technologie de développement. Elle représente le point de vue de l’utilisateur, son unité de mesure est le Point de Fonction.

Qu’est-ce qu’un Point de Fonction ?

Le concept des Points de Fonction a été présenté pour la première fois en 1979 par Alan Albrecht, alors ingénieur pour IBM. Un Point de Fonction est une unité de mesure qui exprime la quantité de fonctionnalités d’un système d’information (en tant que produit) fournies à un utilisateur. Les Points de Fonction sont utilisés pour mesurer la taille fonctionnelle (FSM) d’un logiciel. Le coût (€/h) d’une unité représente indirectement la productivité. Elle est calculée à partir de projets précédents.

Les méthodes de mesure les plus utilisées sont les Points de Fonction IFPUG (International Function Point Users’ Group) et COSMIC (Common Software Measurement International Consortium). Ce sont des normes ISO.

La méthode IFPUG

La méthode de mesure IFPUG comprend 5 étapes :

• La première étape, c’est l’identification du périmètre de comptage. C’est la raison d’être du comptage qui va déterminer son périmètre. C’est au cours de cette phase qu’il convient de déterminer le type de projet et donc le type de comptage – développement, amélioration ou application.

• La deuxième étape, c’est la définition de la frontière de l’application. Il s’agit tout simplement la limite entre le projet ou l’application à mesurer et les applications externes ou les utilisateurs. Il est essentiel que la frontière de l’application soit définie du point de vue de l’utilisateur, et non d’un point de vue L’illustration ci-dessous présente la fonctionnalité du point de vue de l’utilisateur et selon IFPUG.

• La troisième étape, c’est l’identification et le recueil des fonctions de données. Les fonctions de données comprennent les ILF (Internal Logical File) et les EIF (External Interface File). Elles prennent en charge les exigences utilisateur de stockage ou de référencement des données.
  • ILF : Groupe logique de données maintenues par l’application étudiée (ex. : fichier employés).
  • EIF : Groupe logique de données référencé mais non maintenu par l’application étudiée (ex. : tableau d’état global).

• La quatrième étape, c’est l’identification et le recueil des fonctions de transaction. Les fonctions de transaction comprennent les EI (External input), les EQ (External inquiry) et les EO (External output). Les fonctions de transaction prennent en charge les exigences utilisateur de traitement de données.
  • EI : Maintient un ILF ou transfère les données de contrôle vers l’application étudiée.
  • EO : Données formatées envoyées à l’extérieur de l’application avec une valeur ajoutée (ex. : calcul de totaux).
  • EQ : Données formatées envoyées à l’extérieur de l’application sans calcul.

• La cinquième et dernière étape est le calcul de la taille fonctionnelle. Après l’identification et le recueil des fonctions de données et des fonctions de transaction, l’objet et le périmètre de comptage doivent être pris en compte pour sélectionner et appliquer la formule appropriée de calcul de la taille fonctionnelle. La taille d’un projet logiciel est différente de la taille du produit fini. La mesure qui en résulte est exprimée en Points de Fonction non ajustés (UFP). Ce comptage représente la taille de l’application ou du projet à partir des fonctionnalités et toujours du point de vue de l’utilisateur.

La méthode COSMIC

La méthode COSMIC peut être utilisée pour mesurer la taille d’applications métier, temps réel, d’infrastructures logicielles de systèmes d’exploitation ou de versions hybrides. La caractéristique commune de tous ces logiciels, c’est qu’ils sont principalement composés de fonctions qui ajoutent, stockent, retrouvent ou extraient des données.

À l’instar d’IFPUG, les limites entre l’application à mesurer et les utilisateurs fonctionnels doivent être définies.

Il existe quatre types de sous-processus de « Transfert de données » (illustration ci-dessous) pouvant être identifiés à partir des exigences :

• Une « Entrée » transfert un groupe de données d’un utilisateur fonctionnel vers le logiciel,
• Une « Sortie » transfert un groupe de données vers l’extérieur de l’application,
• Une « Lecture » transfert un groupe de données à partir d’un espace de stockage permanent,
• Une « éCriture » transfert un groupe de données vers un espace de stockage permanent,

La taille d’une partie du logiciel est alors définie comme étant le total des mouvements de données (
Entrées, Sorties, Lectures et éCritures) de tous les processus fonctionnels de cette partie de logiciel. Chaque mouvement de données vaut un Point de Fonction COSMIC (CFP).

L’illustration ci-dessous présente les quatre types de mouvements de données.

Conclusion

IFPUG (ifpug.org) et COSMIC (cosmic-sizing.org) sont toutes deux des unités standards permettant de mesurer la taille d’une application logicielle. On peut alors se demander quelle méthode sera la mieux adaptée à son projet.

Bien que les avantages et les inconvénients de ces deux méthodes aient été étudiés et argumentés dans diverses études, il n’est pas évident de faire un choix. Certaines études comparatives concluent qu’IFPUG est davantage compatible avec les applications MIS (management information system) alors que COSMIC est plus adaptée aux applications temps réel. Les deux méthodes se disputent la première place du podium de la meilleure mesure logicielle.

La convertibilité entre les Points de Fonction IFPUG et COSMIC pose également question. Par exemple, lorsqu’une partie d’une application a été mesurée avec les Points de Fonction IFPUG et une autre partie avec les Points de Fonction COSMIC, quelle est la taille réelle de l’intégralité de l’application ?

Certains chercheurs, comme M. Desharnais, proposent un facteur de conversion entre COSMIC et IFPUG. Cependant, diverses études concluent qu’il existe une corrélation entre les deux méthodes, mais elle dépendrait du contexte d’utilisation (temps réel, gestion, etc.).