Estimation de l'effort de développement logiciel

Dans le développement de logiciels , l'estimation de l'effort est le processus de prédiction de la quantité d'effort la plus réaliste (exprimée en termes d'heures-personnes ou d'argent) nécessaire pour développer ou maintenir un logiciel sur la base d'entrées incomplètes, incertaines et bruyantes. Les estimations d'effort peuvent être utilisées comme données d'entrée pour les plans de projet, les plans d'itération, les budgets, les analyses d'investissement, les processus de tarification et les cycles d'appel d'offres.

Les enquêtes publiées sur la pratique d’estimation suggèrent que l’estimation par des experts est la stratégie dominante lors de l’estimation de l’effort de développement de logiciels.

En règle générale, les estimations d'effort sont trop optimistes et il existe une forte surconfiance dans leur exactitude. Le dépassement moyen de l'effort semble être d'environ 30 % et ne pas diminuer au fil du temps. Pour une revue des enquêtes sur les erreurs d'estimation de l'effort, voir. Cependant, la mesure de l'erreur d'estimation est problématique, voir Évaluation de l'exactitude des estimations. La forte surconfiance dans l'exactitude des estimations d'effort est illustrée par la constatation selon laquelle, en moyenne, si un professionnel du logiciel est sûr à 90 % ou « 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 n'est que de 60 à 70 %.

Actuellement, le terme « estimation de l'effort » est utilisé pour désigner différents concepts tels que l'utilisation la plus probable de l'effort (valeur modale), l'effort qui correspond à une probabilité de 50 % de ne pas dépasser (médiane), l'effort planifié, l'effort budgétisé ou l'effort utilisé pour proposer une offre ou un prix au client. Cela est considéré comme regrettable, car des problèmes de communication peuvent survenir et parce que les concepts servent des objectifs différents.

Les chercheurs et les praticiens du logiciel s'intéressent aux problèmes d'estimation de l'effort pour les projets de développement de logiciels depuis au moins les années 1960 ; voir, par exemple, les travaux de Farr et Nelson.

La plupart des recherches se sont concentrées sur la construction de modèles formels d'estimation de l'effort logiciel. Les premiers modèles étaient généralement basés sur une analyse de régression ou dérivaient mathématiquement de théories d'autres domaines. Depuis lors, un grand nombre d'approches de construction de modèles ont été évaluées, telles que les approches fondées sur le raisonnement par cas , les arbres de classification et de régression , la simulation , les réseaux neuronaux , les statistiques bayésiennes , l'analyse lexicale des spécifications d'exigences, la programmation génétique , la programmation linéaire , les modèles de production économique, le soft computing , la modélisation logique floue , le bootstrapping statistique et les combinaisons de deux ou plusieurs de ces modèles. Les méthodes d'estimation les plus courantes aujourd'hui sont peut-être les modèles d'estimation paramétrique COCOMO , SEER-SEM et SLIM. Elles sont basées sur des recherches d'estimation menées dans les années 1970 et 1980 et sont depuis lors mises à jour avec de nouvelles données d'étalonnage, la dernière version majeure étant COCOMO II en 2000. Les approches d'estimation basées sur des mesures de taille basées sur la fonctionnalité, par exemple les points de fonction , sont également basées sur des recherches menées dans les années 1970 et 1980, mais sont recalibrées avec des mesures de taille modifiées et des approches de comptage différentes, telles que les points de cas d'utilisation ou les points d'objet et les points de fonction COSMIC dans les années 1990.

Il existe de nombreuses façons de catégoriser les approches d'estimation, voir par exemple. Les catégories de niveau supérieur sont les suivantes :

• Estimation experte : L'étape de quantification, c'est-à-dire l'étape où l'estimation est produite sur la base de processus de jugement.
• Modèle d’estimation formelle : 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 la 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 dans chaque catégorie.

Les données sur les différences de précision des estimations entre les différentes approches et modèles d'estimation suggèrent qu'il n'existe pas de « meilleure approche » et que la précision relative d'une approche ou d'un modèle par rapport à un autre dépend fortement du contexte. Cela implique que différentes organisations bénéficient de différentes approches d'estimation. Les résultats qui peuvent étayer le choix d'une approche d'estimation en fonction de la précision attendue d'une approche comprennent :

• L'estimation par des experts est en moyenne au moins aussi précise que l'estimation de l'effort basée sur un modèle. En particulier, les situations avec des relations instables et des informations de grande importance non incluses dans le modèle peuvent suggérer le recours à l'estimation par des experts. Cela suppose, bien sûr, que des experts ayant une expérience pertinente soient disponibles.
• Les modèles d'estimation formels qui ne sont pas adaptés au contexte propre à une organisation particulière peuvent être très imprécis. L'utilisation de données historiques propres 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 par l'utilisation de ses propres données historiques, 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 soumises à un fort degré de vœu pieux.

La conclusion la plus solide, dans de nombreux domaines de prévision, est que la combinaison d’estimations provenant de sources indépendantes, de préférence en appliquant des approches différentes, améliorera en moyenne la précision de l’estimation.

Il est important d’être conscient des limites de chaque approche traditionnelle pour mesurer la productivité du développement logiciel.

En outre, d’autres facteurs tels que la facilité de compréhension et de communication des résultats d’une approche, la facilité d’utilisation d’une approche et le coût de mise en œuvre d’une approche doivent être pris en compte dans le processus de sélection.

La mesure la plus courante de la précision moyenne de l'estimation est la MMRE (Mean Magnitude of Relative Error), où la MRE de chaque estimation est définie comme :

MRE = ⁠| (effort réel) - (effort estimé) |/(effort réel)⁠

Cette mesure a été critiquée et il existe plusieurs mesures alternatives, telles que des mesures plus symétriques, la moyenne pondérée des quartiles d'erreurs relatives (WMQ) et la variation moyenne par rapport à l'estimation (MVFE).

L'estimation de la valeur moyenne n'est pas fiable si les éléments individuels sont biaisés. PRED(25) est préféré comme mesure de la précision de l'estimation. PRED(25) mesure le pourcentage de valeurs prédites qui se situent à 25 % de la valeur réelle.

Une erreur d'estimation élevée ne peut pas être automatiquement interprétée comme un indicateur d'une faible capacité d'estimation. Les raisons alternatives, concurrentes ou complémentaires comprennent le faible contrôle des coûts du projet, la grande complexité du travail de développement et un nombre de fonctionnalités plus important que prévu à l'origine. Un cadre pour une meilleure utilisation et interprétation de la mesure des erreurs d'estimation est inclus dans

De nombreux facteurs psychologiques peuvent expliquer la forte tendance à des estimations d'effort trop optimistes. Ces facteurs sont essentiels à prendre en compte même lors de l'utilisation de modèles d'estimation formels, car une grande partie des données d'entrée de ces modèles repose sur le jugement. Les facteurs qui se sont avérés importants sont le vœu pieux , l'ancrage , l'erreur de planification et la dissonance cognitive .

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

La sous-estimation chronique de l'effort de développement a conduit à la création et à la popularité de nombreux adages humoristiques, comme celui qui fait référence ironiquement à une tâche comme étant une « petite affaire de programmation » (alors qu'un effort important est probablement nécessaire), et qui cite des lois sur la sous-estimation :

• Règle des quatre-vingt-dix-quatre-vingt-dix :

Les 90 premiers pour cent du code représentent les 90 premiers pour cent du temps de développement. Les 10 pour cent restants du code représentent les 90 pour cent restants du temps de développement.

—  Tom Cargill, Bell Labs

• Loi de Hofstadter :

Loi de Hofstadter : Cela prend toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter.

—  Douglas Hofstadter , Gödel, Escher, Bach : Une tresse dorée éternelle

• Loi de Fred Brooks :

Ce qu’un programmeur peut faire en un mois, deux programmeurs peuvent le faire en deux mois.

—Fred  Brooks