Estimation d'effort de développement de logiciel

L'estimation d'effort de développement de logiciel désigne le processus visant à anticiper la quantité d'effort la plus réaliste nécessaire (exprimée en termes d'heures-personnes ou d'argent) pour développer ou entretenir un logiciel en se basant sur des données d'entrée qui sont souvent incomplètes, incertaines et sujettes à des variations. Les estimations d'effort peuvent être utilisées pour contribuer à l'élaboration de plans de projet, de plans d'itération, de budgets, d'analyses d'investissement, de procédures de tarification, et dans le cadre d'appels d'offres^[1],[2].

État des pratiques

Les enquêtes publiées sur les pratiques d'estimation indiquent que l'estimation par des experts est la stratégie prédominante lors de l'évaluation de l'effort requis pour le développement de logiciels^[3].

En général, les estimations d'effort tendent à être excessivement optimistes, avec une surconfiance marquée en leur précision. En moyenne, le dépassement de l'effort semble avoisiner les 30 % et ne montre aucune tendance à diminuer avec le temps. Pour une revue des enquêtes portant sur les erreurs d'estimation de l'effort, veuillez vous référer à. Cependant, mesurer l'erreur d'estimation se révèle problématique, comme indiqué dans l'article intitulé "Évaluation de l'exactitude des estimations"^[4]. La forte surestimation de la précision des estimations d'effort est illustrée par la conclusion selon laquelle, en moyenne, si un professionnel du logiciel est sûr à 90 % ou même "presque sûr" d'inclure l'effort réel dans un intervalle minimum-maximum, la fréquence observée d'inclusion de l'effort réel ne s'élève qu'à 60 à 70 %^[5].

À l'heure actuelle, le terme "estimation de l'effort" englobe diverses notions, notamment l'utilisation la plus probable de l'effort (valeur modale), l'effort correspondant à une probabilité de 50 % de ne pas être dépassé (médiane), l'effort prévu, l'effort budgétisé, ou encore l'effort engagé pour établir une offre ou un prix client. Cette situation est regrettable, car elle peut entraîner des problèmes de communication et de compréhension, étant donné que ces concepts poursuivent des objectifs différents^[6],[7]. Une analyse récente de 107 projets logiciels d’entreprise a révélé que la portée vague ou floue était le facteur le plus constant d’inexactitudes dans les estimations, entraînant une déviation des coûts 4,4 fois plus importante que pour les projets bien définis^[8].

Histoire

Les chercheurs et les professionnels du domaine logiciel ont abordé les problèmes liés à l'estimation de l'effort dans les projets de développement de logiciels depuis au moins les années 1960^[9],[10]. Vous pouvez consulter, par exemple, les travaux de Farr et Nelson pour plus d'informations à ce sujet^[11].

La majeure partie des recherches a été axée sur la création de modèles formels pour estimer l'effort dans le développement logiciel. Les premiers modèles étaient généralement établis à partir analyses de régression ou dérivés mathématiquement de théories empruntées à d'autres domaines. Depuis lors, un large éventail d'approches de modélisation a été évalué. Cela inclut des méthodes fondées sur le raisonnement basé sur des cas, les arbres de classification et de régression, la simulation, les réseaux de neurones, les statistiques bayésiennes,analyse lexicale des spécifications d'exigences, la programmation génétique, la programmation linéaire, les modèles d'économie de la production, informatique logicielle, la modélisation de la logique floue, le démarrage statistique, ainsi que des combinaisons de deux ou plusieurs de ces modèles.

Les méthodes d'estimation les plus couramment utilisées aujourd'hui sont peut-être les modèles d'estimation paramétrique, tels que COCOMO, SEER-SEM et SLIM. Ils sont basés sur des recherches effectuées dans les années 1970 et 1980, et ils ont été régulièrement mis à jour avec de nouvelles données d'étalonnage. La dernière version majeure de COCOMO a été publiée en 2000 sous le nom de COCOMO II. D'autre part, les approches d'estimation basées sur des mesures de taille fonctionnelle, comme les points de fonction, s'appuient également sur des recherches menées dans les années 1970 et 1980. Elles ont ensuite été adaptées avec de nouvelles mesures de taille et différentes méthodes de comptage, telles que les points de cas d'utilisation, dans les années 1990^[12].

Approches d’estimation

Il existe de nombreuses façons de catégoriser les approches d'estimation^[13],[14]. Pour des exemples détaillés, vous pouvez vous référer à des sources spécifiques. Cependant, les catégories de niveau supérieur couramment utilisées pour classer ces approches sont les suivantes :

• Estimation d'expert : L'étape de quantification, c'est-à-dire l'étape où l'estimation est produite sur la base de processus de jugement^[15].
• Modèle d'estimation formel : L'étape de quantification est basée sur des processus mécaniques, par exemple l'utilisation d'une formule dérivée de données historiques.
• Estimation basée sur une combinaison : l'étape de quantification est basée sur une combinaison discrétionnaire et mécanique d'estimations provenant de différentes sources.

Vous trouverez ci-dessous des exemples d’approches d’estimation au sein de chaque catégorie.

Approche d’estimation	Catégorie	Exemples d’accompagnement à la mise en œuvre de l’approche d’estimation
Estimation basée sur l'analogie	Modèle d'estimation formel	ANGEL, points de micro-fonction pondérés
Estimation basée sur WBS (de bas en haut)	Estimation d'expert	Logiciel de gestion de projet, modèles d'activités spécifiques à l'entreprise
Modèles paramétriques	Modèle d'estimation formel	COCOMO, SLIM, SEER-SEM, TruePlanning pour logiciels
Modèles d'estimation basés sur la taille	Modèle d'estimation formel	Analyse des points de fonction[16], Analyse des cas d'utilisation, points de cas d'utilisation, SSU (Software Size Unit), estimation basée sur les points d'histoire dans le développement de logiciels Agile, points d'objet
Estimation de groupe	Estimation d'expert	Planification du poker, Delphi à large bande
Combinaison mécanique	Estimation basée sur une combinaison	Moyenne d'une estimation de l'effort basée sur une analogie et d'une estimation de l'effort basée sur une structure de répartition du travail [17]
Combinaison de jugement	Estimation basée sur une combinaison	Jugement d'expert basé sur les estimations d'un modèle paramétrique et l'estimation de groupe

Sélection d'approches d'estimation

Les données probantes sur les différences d'exactitude des estimations entre différentes approches et modèles suggèrent qu'il n'y a pas de "meilleure approche" universelle, et que l'exactitude relative d'une approche ou d'un modèle par rapport à un autre dépend fortement du contexte^[18]. Cela signifie que différentes organisations peuvent tirer avantage de différentes approches d'estimation^[19]. Les résultats qui peuvent orienter la sélection d'une approche d'estimation en fonction de la précision attendue comprennent :

• L’estimation d’expert est en moyenne au moins aussi précise que l’estimation d’effort basée sur un modèle. En particulier, les situations comportant des relations instables et des informations de grande importance non incluses dans le modèle peuvent suggérer le recours à une estimation d'expert. Cela suppose bien entendu que des experts possédant une expérience pertinente soient disponibles.
• Les modèles d'estimation formels, non adaptés au contexte propre à une organisation particulière, peuvent s'avérer très inexacts. L'utilisation de ses propres données historiques est donc cruciale si l'on ne peut pas être sûr que les relations fondamentales du modèle d'estimation (par exemple, les paramètres de formule) sont basées sur des contextes de projet similaires.
• Les modèles d'estimation formels peuvent être particulièrement utiles dans les situations où le modèle est adapté au contexte de l'organisation (soit grâce à l'utilisation de données historiques propres, soit parce que le modèle est dérivé de projets et de contextes similaires), et il est probable que les estimations des experts seront soumis à un fort degré de vœux pieux.

La conclusion la plus robuste, qui s'applique à de nombreux domaines de prévision, est que la combinaison d'estimations provenant de sources indépendantes, de préférence en utilisant différentes approches, a tendance à améliorer en moyenne la précision des estimations^{[19],[20],[21]}.

Il est essentiel de prendre conscience des limites de chaque approche traditionnelle pour mesurer la productivité du développement logiciel^[22].

De plus, d'autres facteurs tels que la facilité de compréhension et de communication des résultats d'une approche, la convivialité de l'approche, et les coûts associés à l'adoption de cette approche doivent également être pris en considération dans le processus de sélection.

Problèmes psychologiques

De nombreux facteurs psychologiques peuvent expliquer la forte tendance à des estimations d'effort trop optimistes. Il est essentiel de prendre en compte ces facteurs, même lors de l'utilisation de modèles d'estimation formels, car une grande partie des données entrant dans ces modèles sont basées sur le jugement. Les facteurs qui se sont révélés importants incluent les vœux pieux, l'ancrage, les erreurs de planification et la dissonance cognitive^[23].

• Il est facile d'estimer ce que l'on sait.
• Il est difficile d’évaluer ce qui est inconnu. (inconnues connues)
• Il est très difficile d'estimer ce qui n'est pas connu comme étant inconnu. (inconnus inconnus)