Il est assez fréquent qu’on nous demande quelle est la fiabilité des estimations des projets logiciels. Si la question peut sembler simple, la réponse ne l’est pas tant que cela. Afin d’y répondre, nous devons donc introduire deux notions essentielles sur l’estimation de projets : l’exactitude et l’incertitude.
Exactitude de l’estimation
Un instrument de mesure est d’autant plus exact que les résultats de mesure qu’il indique coïncident avec la « valeur vraie » que l’on cherche à mesurer. Il est à remarquer que l’exactitude ne s’exprime pas par une valeur chiffrée. C’est une appréciation qualitative des résultats.
L’exactitude est plus aisée à définir par l’erreur de mesure. Elle s’exprime en unité de grandeur (erreur absolue) ou en pourcentage (erreur relative).
Afin de bien comprendre cette notion dans l’estimation de projet, étudions un exemple :
imaginons que vous devez estimer la durée du trajet pour aller de Paris à Alençon. Dans un premier temps, vous allez évaluer la distance à parcourir. Puis, dans un second temps, vous allez évaluer une vitesse moyenne. Des outils comme Via Michelin ou votre GPS, font cela automatiquement :
- distance à parcourir : 192 km par la N12 ;
- vitesse moyenne : 66 km/h, de laquelle on calcule la durée (2h55) ;
- le coût est déduit de la consommation moyenne et du prix de l’essence.
Évaluons l’exactitude de l’estimation dans les cas suivants :
cas n° 1 :
à la fin du voyage, la durée et la distance réalisées sont de respectivement 3 h, et 193 km. L’exactitude de l’estimation est de :
- 97 % sur la durée ;
- 99 % sur la distance.
Nous avons donc une estimation exacte à quelques pourcents près.
Cas n° 2 :
Vous avez rencontré des problèmes de circulation, et mis 4h au lieu de 3h, par le même chemin. L’exactitude de l’estimation est alors de :
- 63 % sur la durée ;
- 99 % sur la distance.
Cas n° 3 :
Vous avez décidé de passer par Rambouillet, puis Dreux, rajoutant 24 km à la distance à parcourir, pour une durée de 3 h 41. L’exactitude de l’estimation est alors de :
- 74 % sur la durée ;
- 88 % sur la distance.
L’exactitude de l’estimation est-elle bonne ? Non.
Le modèle d’estimation est-il mauvais ? Non, car si nous avions fait l’estimation avec les bonnes hypothèses sur la distance, nous aurions obtenu 0 % d’erreur.
Nous aurions également pu imaginer le cas où le voyage durera 5 heures car le trajet est fait en scooter, non pas en voiture.
Conclusions :
Ainsi, l’exactitude dépend :
- d’évènements extérieurs (trafic, météo) que vous n’aviez pas anticipés (mauvaises hypothèses de départ) ;
- d’une décision : vous avez décidé de faire un détour (changement d’hypothèse) ;
- d’une mauvaise évaluation de la vitesse : vous roulez en scooter et non en voiture.
- Remarque : si le modèle d’estimation ne prévoit pas que vous puissiez rouler en scooter, le modèle est défaillant. Sinon, c’est un problème d’hypothèse.
L’exactitude d’un modèle d’estimation de projet de développement :
l’exactitude dans les projets de développements de logiciel est évaluée de la même manière que dans l’exemple. En effet, pour évaluer l’exactitude d’un modèle d’estimation, il faut comparer l’estimation initiale avec la valeur réelle finale, mais surtout vérifier que les hypothèses prises au départ ont bien été respectées.
- Le périmètre du projet a-t-il changé (la taille est-elle plus importante que prévue) ?
- Les hypothèses de productivité ont-elles été respectées (compétences des équipes, outillage, technologie, etc.)
- Quels problèmes ont eu une incidence sur le projet (grève de transport, épidémies de grippe, etc.). Ces problèmes doivent être identifiés dans les risques possibles car ils échappent au contrôle de l’entreprise.
L’exactitude de l’estimation dépend donc de l’exactitude des éléments suivants :
- les hypothèses de l’estimation ;
- la quantité estimée ;
- la productivité (vitesse) estimée : la qualité de l’abaque ou du modèle d’estimation d’effort utilisé.
Incertitude de l’estimation
L’incertitude d’une estimation d’effort de développement logiciel est synonyme de « doute » sur la validité de cette estimation. Ce doute est généralement la conséquence, entre autres, d’une connaissance incomplète, imprécise ou limitée des projets de développement logiciel à estimer et de l’instabilité de l’environnement de développement.
L’incertitude est principalement liée à la dispersion des valeurs qui pourraient raisonnablement être attribuées à une grandeur.
Il y a là une dimension statistique fondamentale, car les modèles d’estimation sont construits sur des historiques de projets. L’expérience montre que deux projets logiciels semblables peuvent avoir des coûts (ou des durées) très différents.
Cela n’est pas spécifique aux projets logiciels :
dans les transports en commun, l’actualité nous informe régulièrement de retards très importants, ce qui se traduit par une incertitude sur la durée du trajet. L’incertitude augmente avec la fréquence et la quantité de retard. Un retard exceptionnel d’une heure aura moins d’incidence sur l’incertitude qu’un retard fréquent de 15 minutes.
Les incertitudes qui existent intrinsèquement dans le processus d’estimation font que l’estimation réaliste doit être représentée de façon probabiliste ou possibiliste sous la forme de distribution de possibilités. Du point de vue pratique, la plupart des auteurs indiquent que la représentation des estimations sous la forme de distributions de probabilité ou d’intervalles de prédiction permet de mieux comprendre ces estimations.
L’incertitude d’une estimation de l’effort d’un projet logiciel peut être exprimée par un « Intervalle de confiance » (IvP).
L’intervalle de confiance représente un intervalle dont les bornes représentent un minimum et un maximum d’effort estimé correspondant à un degré de confiance souhaité. Ce degré de confiance est souvent noté (1−α) où α représente la probabilité que l’IvP ne couvre pas l’effort réel. En effet, l’effort réel devrait appartenir à l’IvP dans (1−α) % des cas. Généralement, le degré de confiance peut être différent selon la phase du projet. Le degré de confiance recommandé pour la phase de planification de projets doit être supérieur ou égal à 90 %.
Plus cet intervalle est étroit, meilleure est l’exactitude de l’estimation. La largeur de l’intervalle de confiance représente l’incertitude.
Alors, une estimation devrait toujours être énoncée ainsi : le coût du projet devrait être compris entre X et Y euros avec une probabilité de Z %.
Bases de connaissance et calibrage
Comment estimer un projet si on n’a aucune idée de la productivité (vitesse) ?
C’est toujours un exercice difficile, car nous allons devoir faire des hypothèses.
Prenons l’exemple du marathon :
l’estimation du temps que va mettre un participant pour courir un marathon sans connaissance préalable sur la vitesse moyenne de cette personne, va nous conduire à un intervalle de confiance entre 2 h 06 (le record) et 8 h (temps maximum généralement accordé) avec un degré de confiance de 100 %. Une autre estimation peut être l’intervalle entre 3 h et 5 h 30 avec un degré de confiance de 80 %. Plus l’incertitude est très élevée, plus l’intervalle s’élargi.
Dans le cas où de nouvelles informations sont fournies sur la vitesse moyenne (notamment sur une distance de 10 km), ainsi que des hypothèses concernant l’entrainement pour le marathon du participant, l’incertitude va très nettement diminuer (plus ou moins 15 minutes environ).
En matière de développement de logiciel, c’est la même chose. En l’absence d’information sur la productivité, l’incertitude sur les estimations va être très élevée. Si une mesure sur un projet passé est effectuée, cela permettra de calibrer le modèle de chiffrage au contexte étudié et de réduire l’incertitude sur l’estimation.
Dans les organisations ayant une bonne maturité de processus de développement de logiciels, la bonne gestion des risques, et une bonne planification permettent d’avoir moins de dispersion (variation de productivité) entre les projets. Autrement dit l’incertitude diminue, l’exactitude des estimations est meilleure.
Conclusion
L’estimation de projet consiste à évaluer l’effort et la durée d’un projet, en fonction d’informations connues, d’hypothèses, et d’un modèle d’estimation.
La qualité des informations connues et inconnues influe de manière très importante sur le résultat. Il est donc nécessaire de vérifier que les hypothèses de départ sont toujours respectées, et pour les hypothèses les plus structurantes, de les traiter comme des risques.
Pour améliorer les modèles d’estimation, rien ne vaut les bilans de projets et le calibrage sur des données réelles.
Enfin, lorsque l’on présente une estimation, il est important de préciser l’incertitude, à l’aide d’une estimation 3 points : Min, Probable, Max.
Découvrez les offres de produits et de services Estimancy permettant de mesurer ou d’estimer des projets logiciels à partir des exigences 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)
