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 %.