Fractalisation et estimation de projet

Pour chiffrer un projet, il faut commencer par identifier les composants élémentaires, qui, une fois additionnés, donnent la taille du logiciel à développer. La difficulté est de s’arrêter au bon niveau de décomposition.

Si l’on prend une exigence telle que « l’application permet de gérer les fiches clients ».

Nous pouvons la décomposer de la manière suivante :

• créer une fiche client ;
• consulter une fiche client ;
• modifier une fiche client ;
• supprimer une fiche client.

Nous pourrions la décomposer plus finement encore :

• créer une fiche client :
• afficher une grille de saisie vide ;
• vérifier que le n° de SS est conforme ;
• vérifier que le code postal et la ville correspondent ;
• etc.

La décomposition peut se poursuivre jusqu’à l’instruction élémentaire dans le langage de programmation.

Plus le niveau de décomposition est fin, et plus l’évaluation du travail va être élevée. En effet, l’expérience montre que lorsque l’on chiffre séparément toutes les opérations à un niveau très fin, la charge de travail « explose ».

Il est donc primordial de se mettre d’accord sur un niveau de décomposition raisonnable, et suffisamment clair pour éviter qu’il y ait la moindre ambiguïté.

Quel niveau de décomposition choisir ?

C’est une question centrale, et l’approche des Points de Fonction (ISO 14143) apporte une réponse pragmatique. La granularité est définie par la notion de processus élémentaire.

Processus élémentaire :

-> la plus petite unité d’activité qui satisfait tous les points suivants :

1. qui est significatif pour l’utilisateur ;
2. qui constitue une transaction complète ;
3. qui est autonome (auto porteur) ;
4. qui laisse l’application dans un état cohérent.

Exemple 1 : une exigence fonctionnelle peut indiquer qu’une fonction doit être fournie pour gérer les informations sur l’employé. Cette exigence est décomposée en unités de travail plus petites telles que : ajouter un employé, changer l’employé, supprimer l’employé, afficher l’employé.

 Exemple 2 : les exigences individuelles peuvent indiquer la nécessité d’ajouter différents types d’informations sur les employés (par exemple, l’adresse, le salaire et les informations associées), mais la plus petite unité d’activité significative pour l’utilisateur est d’ajouter un employé.

Renforcé par la notion de « primary intent » ou « intention primaire ou principale », un processus élémentaire selon IFPUG, peut être soit :

• une entrée ;
• une sortie ;
• une requête.

Même si pour réaliser un processus élémentaire, il peut y avoir des traitements supplémentaires, c’est l’intention primaire qui va permettre de décider de son type.

Par exemple : un écran de saisie et de sauvegarde d’une fiche client, peut entraîner un affichage (donc une sortie) de tel ou tel élément ; l’intention première est d’entrer des données, donc le traitement sera uniquement du type « Entrée », malgré les affichages, qui sont des sorties.

Ainsi la granularité se définit par rapport à l’utilisateur, et aux actions qu’il mène.

Dans l’exemple ci-dessus, et relativement à la norme des Points de Fonction IFPUG, le bon niveau de granularité est :

• créer une fiche client ;
• consulter une fiche client ;
• modifier une fiche client ;
• supprimer une fiche client.

Cas des projets sous-traités

Le danger de fractalisation est plus grand si le projet est sous-traité. Le sous-traitant pourra avoir tendance à décomposer trop finement les travaux. D’abord, pour spécifier plus en détail la demande de son client et être sûr d’avoir une compréhension commune, et parce que c’est financièrement plus avantageux pour lui.

Il est donc fondamental que les règles de décomposition soient claires et précises, et si possible qu’elles s’appuient sur une norme comme les Points de Fonction (IFPUG, COSMIC,…), car cela permet alors d’avoir la possibilité de désigner un arbitre indépendant en la personne d’un expert en Points de Fonction.