Mesurer un logiciel en lignes de code revient à mesurer un bâtiment au nombre de briques employées : le chiffre dépend davantage de la technique de construction que du bâtiment lui-même. C’est précisément le problème que la mesure de taille fonctionnelle (Functional Size Measurement, FSM) résout, en déplaçant le point d’observation depuis l’implémentation vers les exigences fonctionnelles de l’utilisateur.
Deux méthodes dominent la pratique industrielle : l’IFPUG Function Point Analysis et COSMIC. Toutes deux sont des normes ISO à part entière. Elles ne mesurent pourtant pas tout à fait la même chose, et le choix entre les deux n’est pas neutre. Cet article détaille leurs mécaniques de comptage, leur ancrage normatif, et applique les deux méthodes à un même périmètre bancaire pour en montrer concrètement l’écart.
1. Le cadre fédérateur : la famille ISO/IEC 14143
Avant de comparer les méthodes, il faut comprendre la norme qui définit ce qu’est une méthode de FSM. La série ISO/IEC 14143 ne mesure rien elle-même : elle établit le méta-cadre auquel toute méthode candidate doit se conformer.
| Partie | Objet |
|---|---|
| ISO/IEC 14143-1:2007 | Définition des concepts fondamentaux de la FSM |
| ISO/IEC 14143-2 | Évaluation de la conformité des méthodes de mesure |
| ISO/IEC 14143-3 | Vérification des méthodes de FSM |
| ISO/IEC 14143-4 | Modèle de référence |
| ISO/IEC 14143-5 | Détermination des domaines fonctionnels |
| ISO/IEC 14143-6:2012 | Guide d’utilisation de la série et des normes associées |
La partie 1 introduit deux notions structurantes. Les FUR (Functional User Requirements) sont les exigences décrivant ce que le logiciel doit faire pour l’utilisateur, indépendamment de comment il le fait — les exigences de qualité, de performance ou de technologie en sont explicitement exclues. Le BFC (Base Functional Component) est l’unité élémentaire de FUR qu’une méthode donnée identifie et compte. C’est ici que les méthodes divergent : chacune définit ses propres BFC.
Point souvent mal compris : ISO/IEC 14143-1 ne prescrit aucune règle de comptage et ne recommande aucune méthode. Elle sert de test de conformité. C’est ce qui explique la coexistence de plusieurs normes ISO concurrentes pour un même objet.
Les cinq méthodes de FSM normalisées ISO
| Norme | Méthode | Statut |
|---|---|---|
| ISO/IEC 20926:2009 | IFPUG FSM Method | Très largement diffusée |
| ISO/IEC 19761:2011 | COSMIC | Croissance soutenue, forte adoption en embarqué et temps réel |
| ISO/IEC 20968:2002 | Mk II Function Point Analysis | Usage résiduel, principalement au Royaume-Uni |
| ISO/IEC 24570 | NESMA FPA v2.1 | Variante compatible IFPUG, ancrage néerlandais |
| ISO/IEC 29881 | FiSMA 1.1 | Origine finlandaise, diffusion limitée |
À ces cinq méthodes s’ajoute ISO/IEC 19515 (Automated Function Points de l’OMG), qui définit un comptage automatisable à partir du code, aligné sur les règles IFPUG. Ce n’est pas une méthode de FSM au sens de 14143 mais une spécification d’automatisation.
2. IFPUG Function Point Analysis — ISO/IEC 20926
La méthode remonte aux travaux d’Allan Albrecht chez IBM à la fin des années 1970. L’International Function Point Users Group, créé en 1986, en assure depuis la maintenance. La normalisation ISO s’est faite en deux temps : ISO/IEC 20926:2003 couvrait la version 4.1 de la méthode ; la seconde édition, ISO/IEC 20926:2009, l’annule et la remplace.
Point d’attention pratique : la norme ISO ne couvre que le comptage non ajusté. Le Counting Practices Manual (CPM), actuellement en release 4.3.1, reprend le contenu normatif et l’enrichit de règles détaillées et d’exemples. C’est le CPM que les praticiens utilisent au quotidien, et qui sert de base à la certification CFPS.
Cinq types de composants
Fonctions de données — ce que le système mémorise :
- ILF (Internal Logical File) : groupe de données logiquement lié, maintenu à l’intérieur de la frontière applicative.
- EIF (External Interface File) : groupe de données référencé par l’application mais maintenu par une autre application.
Fonctions de transaction — ce que le système fait :
- EI (External Input) : traitement de données entrantes qui maintient un ILF ou modifie le comportement du système.
- EO (External Output) : envoi de données vers l’extérieur comportant une logique de traitement additionnelle — calcul, dérivation, création de données.
- EQ (External Inquiry) : restitution de données vers l’extérieur sans logique de traitement ni modification d’ILF.
La distinction EO/EQ est la source d’erreur la plus fréquente chez les praticiens débutants. Le critère discriminant est l’existence d’une donnée dérivée ou d’une modification d’état.
La pondération par complexité
Chaque composant est classé en complexité faible / moyenne / élevée selon le croisement des DET (champs uniques reconnaissables par l’utilisateur), des RET (sous-groupes au sein d’un fichier logique) et des FTR (fichiers logiques référencés par une transaction). La grille est fixe :
| Type de fonction | Faible | Moyenne | Élevée |
|---|---|---|---|
| ILF | 7 | 10 | 15 |
| EIF | 5 | 7 | 10 |
| EI | 3 | 4 | 6 |
| EO | 4 | 5 | 7 |
| EQ | 3 | 4 | 6 |
La somme des poids donne l’UFP (Unadjusted Function Points) — la seule grandeur couverte par ISO/IEC 20926.
Le VAF : un héritage à écarter
Le modèle historique appliquait un Value Adjustment Factor, dérivé de 14 caractéristiques générales du système, faisant varier le total dans une plage de ±35 %. Ce facteur mêle taille fonctionnelle et caractéristiques non fonctionnelles, ce qui contrevient à la définition même de la FSM. Il est exclu de la norme ISO et considéré comme obsolète.
Pour couvrir le non-fonctionnel, IFPUG a développé un dispositif distinct : SNAP (Software Non-functional Assessment Process), dont l’Assessment Practices Manual est en version 2.4. SNAP produit des points SNAP, comptés séparément des points de fonction — les deux grandeurs ne doivent jamais être additionnées.
Limites structurelles
L’échelle de pondération est plafonnée. Un ILF de 200 DET et un ILF de 20 DET pèsent tous deux 15 points s’ils dépassent le seuil de complexité élevée. Cette compression pénalise les logiciels à forte densité algorithmique. Par ailleurs, le modèle a été conçu pour les systèmes de gestion, où l’essentiel de la valeur réside dans la manipulation de fichiers logiques — un présupposé qui s’applique mal au temps réel et à l’embarqué.
3. COSMIC — ISO/IEC 19761
COSMIC — Common Software Measurement International Consortium — est né à la fin des années 1990 d’un effort international explicitement conçu pour dépasser les limites des méthodes dites de « première génération ». La méthode a été normalisée sous ISO/IEC 19761:2003 (alors appelée COSMIC-FFP), puis révisée en ISO/IEC 19761:2011. Le Measurement Manual en est à la version 5.0, publiée en plusieurs parties. Différence de modèle économique notable : ce manuel est librement téléchargeable, là où le CPM d’IFPUG est un produit payant.
Un BFC unique : le mouvement de données
Là où IFPUG compte cinq types de composants pondérés, COSMIC n’en reconnaît qu’un seul : le mouvement de données. Le principe sous-jacent est qu’un processus fonctionnel se ramène à un ensemble de déplacements d’un groupe de données unique.
| Mouvement | Description |
|---|---|
| Entry (E) | Un groupe de données franchit la frontière depuis un utilisateur fonctionnel vers le processus |
| Exit (X) | Un groupe de données franchit la frontière depuis le processus vers un utilisateur fonctionnel |
| Read (R) | Un groupe de données est lu depuis un stockage persistant |
| Write (W) | Un groupe de données est écrit vers un stockage persistant |
Chaque mouvement vaut 1 CFP (COSMIC Function Point). Pas de pondération, pas de grille de complexité, pas de plafond.
Concepts clés
- Utilisateur fonctionnel : tout émetteur ou récepteur de données vis-à-vis du logiciel mesuré. Il peut s’agir d’un humain, mais aussi d’un autre logiciel, d’un capteur ou d’un actionneur. C’est cette généralisation qui rend la méthode applicable au temps réel et à l’embarqué.
- Processus fonctionnel : ensemble de mouvements déclenché par un événement déclencheur unique. Il comporte toujours au minimum un Entry et un Exit ou un Write — soit un plancher de 2 CFP.
- Frontière : sépare le logiciel mesuré de ses utilisateurs fonctionnels.
- Couche : partition d’architecture ; chaque couche se mesure séparément puis les tailles s’additionnent.
- Stratégie de mesure : phase préalable fixant le périmètre, la finalité, la portée, les utilisateurs fonctionnels et le niveau de granularité. La partie 3a du manuel documente des stratégies standard garantissant des comparaisons à périmètre équivalent.
La propriété d’additivité
Conséquence directe de l’absence de pondération : les tailles COSMIC sont strictement additives. La taille d’un ensemble est la somme des tailles de ses parties, et la taille d’une évolution est la somme des mouvements ajoutés, modifiés et supprimés. Cette propriété facilite considérablement la mesure incrémentale et le suivi de projets agiles.
4. Comparaison structurée
| Critère | IFPUG (ISO/IEC 20926) | COSMIC (ISO/IEC 19761) |
|---|---|---|
| Génération | Première | Deuxième |
| Unité | UFP | CFP |
| Types de BFC | 5 (ILF, EIF, EI, EO, EQ) | 1 (mouvement de données, 4 sous-types) |
| Pondération | Grille fixe faible / moyenne / élevée | Aucune — 1 mouvement = 1 CFP |
| Plafond d’échelle | Oui (15 max pour un ILF) | Non |
| Additivité | Imparfaite | Stricte |
| Utilisateur | Principalement humain | Humain, logiciel, capteur, actionneur |
| Domaines de prédilection | Systèmes de gestion, SI d’entreprise | Temps réel, embarqué, middleware, mobile, SI |
| Manuel de référence | CPM 4.3.1 (payant) | Measurement Manual v5.0 (gratuit) |
| Certification | CFPS / CFPP | Certification COSMIC (parties 1 et 2) |
| Non-fonctionnel | SNAP APM 2.4, comptage séparé | Hors périmètre par conception |
| Base historique | Très volumineuse (ISBSG) | Plus récente mais en croissance |
5. Cas d’usage bancaire : un module d’octroi de crédit à la consommation
Rien ne vaut un périmètre réel mesuré deux fois. Prenons un module d’octroi de crédit à la consommation, composé de la saisie des demandes, d’un moteur de scoring, de l’édition de l’offre et du déblocage des fonds. Nous le mesurons d’abord en IFPUG, puis en COSMIC.
Périmètre et frontière. Le module dialogue avec le référentiel client (CRM), maintenu par une autre application, avec le fichier des incidents de paiement, et avec le système de paiement qui exécute les virements. Ces trois systèmes sont extérieurs à la frontière.
5.1 Comptage IFPUG
Fonctions de données
| Composant | Type | Complexité | Poids |
|---|---|---|---|
| Dossier de demande de crédit | ILF | Élevée | 15 |
| Décision et historique de scoring | ILF | Moyenne | 10 |
| Barème de taux | ILF | Faible | 7 |
| Référentiel client (CRM) | EIF | Moyenne | 7 |
| Fichier des incidents de paiement | EIF | Faible | 5 |
| Sous-total données | 44 | ||
Fonctions de transaction
| Composant | Type | Complexité | Poids |
|---|---|---|---|
| Créer ou modifier une demande de crédit | EI | Élevée | 6 |
| Téléverser une pièce justificative | EI | Faible | 3 |
| Saisir une décision dérogatoire | EI | Moyenne | 4 |
| Ordonner le déblocage des fonds | EI | Moyenne | 4 |
| Éditer l’offre de prêt (TAEG, échéancier) | EO | Élevée | 7 |
| Restituer le score et les motifs de refus | EO | Moyenne | 5 |
| Reporting mensuel de production | EO | Moyenne | 5 |
| Consulter le statut d’un dossier | EQ | Faible | 3 |
| Rechercher un dossier par client | EQ | Moyenne | 4 |
| Consulter le barème en vigueur | EQ | Faible | 3 |
| Sous-total transactions | 44 | ||
Taille fonctionnelle : 44 + 44 = 88 UFP.
Noter le classement des trois sorties. L’édition de l’offre de prêt est un EO et non un EQ, parce qu’elle calcule le TAEG et génère l’échéancier : il y a création de données dérivées. La consultation du barème, en revanche, est un simple EQ — elle restitue sans rien calculer. C’est exactement la frontière évoquée plus haut.
5.2 Comptage COSMIC du même périmètre
Les utilisateurs fonctionnels sont ici le chargé de clientèle, le CRM, le fichier des incidents et le système de paiement. Chaque processus fonctionnel se décompose en mouvements.
| Processus fonctionnel | E | X | R | W | CFP |
|---|---|---|---|---|---|
| Créer une demande de crédit | 1 | 1 | 2 | 1 | 5 |
| Modifier une demande | 1 | 1 | 1 | 1 | 4 |
| Téléverser une pièce justificative | 1 | 1 | 0 | 1 | 3 |
| Calculer le score | 1 | 1 | 3 | 1 | 6 |
| Saisir une décision dérogatoire | 1 | 1 | 1 | 1 | 4 |
| Éditer l’offre de prêt | 1 | 1 | 3 | 1 | 6 |
| Consulter le statut d’un dossier | 1 | 1 | 1 | 0 | 3 |
| Rechercher un dossier par client | 1 | 1 | 1 | 0 | 3 |
| Consulter le barème en vigueur | 1 | 1 | 1 | 0 | 3 |
| Ordonner le déblocage des fonds | 1 | 1 | 1 | 1 | 4 |
| Restituer les motifs de refus | 1 | 1 | 1 | 0 | 3 |
| Produire le reporting mensuel | 1 | 1 | 2 | 0 | 4 |
| Total | 48 CFP | ||||
Le déblocage des fonds illustre bien l’apport de COSMIC : l’Exit vers le système de paiement est compté comme un mouvement à part entière, parce que ce système est un utilisateur fonctionnel au même titre qu’un humain. IFPUG, lui, le range dans un EI sans distinguer le destinataire.
5.3 Ce que l’écart nous apprend
Sur ce périmètre, 88 UFP correspondent à 48 CFP, soit un rapport d’environ 1,8. Ce rapport n’est pas transposable. Il dépend entièrement de la structure du logiciel mesuré : un module riche en fichiers logiques et pauvre en interactions fera monter le ratio, un module fortement transactionnel le fera baisser. Les formules de conversion qui circulent dans la littérature donnent des résultats acceptables sur les systèmes de gestion classiques et se dégradent nettement ailleurs. Une conversion n’est jamais une mesure : si le résultat doit fonder un engagement contractuel, il faut recompter.
5.4 Du comptage à l’estimation d’effort
La taille fonctionnelle n’est pas une estimation : c’est un intrant. Pour obtenir un effort, il faut la combiner à un ratio de productivité issu de l’historique de l’organisation. Si la banque observe historiquement 1,4 jour-homme par point de fonction sur ce type de développement, l’estimation initiale s’établit à 88 × 1,4 ≈ 123 jours-homme.
Trois réserves accompagnent ce chiffre. D’abord, le ratio de productivité doit provenir de projets comparables en technologie, en équipe et en domaine — un ratio emprunté à une autre organisation n’a aucune valeur prédictive. Ensuite, les exigences non fonctionnelles (disponibilité, conformité réglementaire, sécurité, performance sous charge) ne sont pas dans les 88 UFP ; en contexte bancaire, où la conformité pèse lourd, elles s’évaluent séparément — via SNAP ou un modèle interne. Enfin, ce chiffre est une base de négociation, pas un engagement : il gagne à être exprimé en fourchette et révisé à chaque incrément.
6. Critères de choix
Retenir IFPUG lorsque :
- le périmètre est un système d’information de gestion classique ;
- l’organisation dispose d’un historique de productivité déjà exprimé en points de fonction ;
- le contexte contractuel ou réglementaire l’impose — plusieurs donneurs d’ordre publics référencent explicitement IFPUG ;
- l’accès à un vivier de compteurs certifiés CFPS est déterminant ;
- l’estimation s’appuie sur des bases de référence externes matures, de type ISBSG.
Retenir COSMIC lorsque :
- le logiciel est temps réel, embarqué, ou dépourvu d’utilisateur humain direct ;
- l’architecture est fortement distribuée ou multicouche ;
- la démarche est incrémentale et l’additivité stricte est un prérequis ;
- l’objectif est la mesure de la maintenance évolutive, où l’on compte les mouvements impactés ;
- le budget de mise en place est contraint — le manuel est gratuit et la courbe d’apprentissage plus courte.
Dans les deux cas, quelques principes non négociables. Ne jamais mélanger les unités : un portefeuille mesuré partiellement en UFP et partiellement en CFP ne produit aucune donnée exploitable. Documenter la stratégie de mesure — périmètre, frontière, utilisateurs fonctionnels, granularité — sans quoi la mesure n’est ni reproductible ni auditable. Séparer le fonctionnel du non-fonctionnel. Et mesurer tôt : une mesure produite en fin de projet n’a plus aucune valeur d’aide à la décision.
Conclusion
IFPUG et COSMIC ne s’opposent pas : elles répondent à des questions voisines depuis des modèles conceptuels distincts. IFPUG offre la profondeur historique, un écosystème mature et un ancrage contractuel solide dans le monde des systèmes de gestion. COSMIC apporte un modèle plus simple, plus général et mathématiquement mieux formé, particulièrement adapté aux architectures modernes et aux logiciels sans utilisateur humain.
Le cadre ISO/IEC 14143 garantit que les deux méthodes mesurent bien une taille fonctionnelle au sens normatif. Le reste — le choix de la méthode, la rigueur de la stratégie de mesure, la constance dans le temps — relève de la discipline de l’organisation. Et c’est cette discipline, bien plus que le choix de la méthode, qui détermine la valeur réelle du dispositif de mesure.
Références normatives
- ISO/IEC 14143-1:2007 — Functional size measurement — Part 1: Definition of concepts
- ISO/IEC 14143-6:2012 — Part 6: Guide for use of the ISO/IEC 14143 series
- ISO/IEC 20926:2009 — IFPUG functional size measurement method 2009
- ISO/IEC 19761:2011 — COSMIC: a functional size measurement method
- ISO/IEC 20968:2002 — Mk II Function Point Analysis
- ISO/IEC 24570 — NESMA functional size measurement method v2.1
- ISO/IEC 29881 — FiSMA 1.1 functional size measurement method
- ISO/IEC 19515 — OMG Automated Function Points (AFP) 1.0
- IFPUG — Function Point Counting Practices Manual, release 4.3.1
- IFPUG — SNAP Assessment Practices Manual, release 2.4
- COSMIC — Measurement Manual for ISO 19761, version 5.0 (parties 1, 2 et 3a)
Laisser un commentaire