Quelle granularité pour les exigences logicielles ?
Lorsque l’on fait le chiffrage d’un projet logiciel, il faut faire très attention à ne pas tomber dans le piège de la fractalisation en définissant le niveau de précision des exigences logicielles. Cela pourrait aboutir à une explosion de la charge et donc des coûts.
Pour bien comprendre ce syndrome, on peut l’illustrer avec la question suivante.
Quelle est la longueur des côtes française ?
Cela dépend du niveau de décomposition. À l’échelle 1/1 000 000, la longueur des côtes française est de 18 000 km. Mais les cartes ne présentent pas le même niveau de détail aux échelles 1 cm = 100 m et 1 cm = 10 km. Et s’il fallait mesurer la longueur de la côte en contournant chaque grain de sable, on trouverait une distance énorme !
À titre d’exemple, la longueur du trait de côte des îles Kerguelen, qui sont particulièrement découpées, varie du simple au double si l’on utilise l’échelle 1/1 000 000 ou l’échelle 1/90 000. (source)
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 :
- qui est significatif pour l’utilisateur ;
- qui constitue une transaction complète ;
- qui est autonome (auto porteur) ;
- 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.
Découvrez les offres de produits et de services Estimancy permettant de mesurer ou d’estimer des projets logiciels à partir des exigences logicielles utilisateurs rédigées en langage naturel.
![[Replay webinaire] Les bases de l’estimation des projets logiciels](https://www.estimancy.com/wp-content/uploads/0122-1-576x360.jpg)
![[Replay webinaire] Spécification des projets logiciels : estimer les projets agiles](https://www.estimancy.com/wp-content/uploads/Copie-de-Copie-de-Webinaire-21-octobre-2021-576x360.jpg)
![[Replay] Webinaire : Comment réaliser un contre-chiffrage sur un projet logiciel](https://www.estimancy.com/wp-content/uploads/Copie-de-Webinaire-11-576x360.png)
![[Replay] Webinaire – Comment formuler les exigences pour estimer les projets de développement logiciel ?](https://www.estimancy.com/wp-content/uploads/Webinaire-_-comment-formuler-les-exigences-576x360.png)
