Wikipédia

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

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.
Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

La mise en forme de cet article est à améliorer ().

La mise en forme du texte ne suit pas les recommandations de Wikipédia : il faut le « wikifier ».

État des pratiques modifier

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

Histoire modifier

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[8],[9]. Vous pouvez consulter, par exemple, les travaux de Farr et Nelson pour plus d'informations à ce sujet[10].

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[11].

Approches d’estimation modifier

Il existe de nombreuses façons de catégoriser les approches d'estimation[12],[13]. 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[14].
  • 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[15], 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 [16]
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 modifier

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[17]. Cela signifie que différentes organisations peuvent tirer avantage de différentes approches d'estimation[18]. 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[18],[19],[20].

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

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 modifier

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[22].

  • 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)

Notes et références modifier

  1. ↑ « What We do and Don't Know about Software Development Effort Estimation »
  2. ↑ « Cost Estimating And Assessment Guide GAO-09-3SP Best Practices for developing and managing Capital Program Costs », US Government Accountability Office,
  3. ↑ Jørgensen, M., « A Review of Studies on Expert Estimation of Software Development Effort », Journal of Systems and Software, vol. 70, nos 1–2,‎ , p. 37–60 (DOI 10.1016/S0164-1212(02)00156-5, lire en ligne)
  4. ↑ Molokken, K. Jorgensen, M., 2003 International Symposium on Empirical Software Engineering, 2003. ISESE 2003. Proceedings, , 223–230 p. (ISBN 978-0-7695-2002-5, PMCID 15471986, DOI 10.1109/ISESE.2003.1237981), « A review of software surveys on software effort estimation »
  5. ↑ Jørgensen, M. Teigen, K.H. Ribu, K., « Better sure than safe? Over-confidence in judgement based software development effort prediction intervals », Journal of Systems and Software, vol. 70, nos 1–2,‎ , p. 79–93 (DOI 10.1016/S0164-1212(02)00160-7)
  6. ↑ Edwards, « A conflict between the use of estimating and planning tools in the management of information systems », European Journal of Information Systems, vol. 3, no 2,‎ , p. 139–147 (DOI 10.1057/ejis.1994.14, S2CID 62582672)
  7. ↑ Goodwin, P. (1998). Enhancing judgmental sales forecasting: The role of laboratory research. Forecasting with judgment. G. Wright and P. Goodwin. New York, John Wiley & Sons: 91-112. Hi
  8. ↑ Farr, L. Nanus, B., « Factors that affect the cost of computer programming, volume I » [archive du ]
  9. ↑ Farr, L. Nanus, B., « Factors that affect the cost of computer programming, volume II » [archive du ]
  10. ↑ Nelson, E. A. (1966). Management Handbook for the Estimation of Computer Programming Costs. AD-A648750, Systems Development Corp.
  11. ↑ Anda, B. Angelvik, E. Ribu, K., Product Focused Software Process Improvement, vol. 2559, coll. « Lecture Notes in Computer Science », , 383–397 p. (ISBN 978-3-540-00234-5, DOI 10.1007/3-540-36209-6_32, CiteSeerx 10.1.1.546.112, lire en ligne), « Improving Estimation Practices by Applying Use Case Models » (ISBN 9783540002345 et 9783540362098).
  12. ↑ Briand, L. C. and Wieczorek, I. (2002). "Resource estimation in software engineering". Encyclopedia of software engineering. J. J. Marcinak. New York, John Wiley & Sons: 1160–1196.
  13. ↑ Jørgensen, M. Shepperd, M., « A Systematic Review of Software Development Cost Estimation Studies »
  14. ↑ « Custom Software Development Services – Custom App Development – Oxagile »
  15. ↑ Morris Pam — Overview of Function Point Analysis Total Metrics - Function Point Resource Centre
  16. ↑ Srinivasa Gopal and Meenakshi D'Souza. 2012. Improving estimation accuracy by using case based reasoning and a combined estimation approach. In Proceedings of the 5th India Software Engineering Conference (ISEC '12). ACM, New York, USA, 75-78. DOI 10.1145/2134254.2134267
  17. ↑ Shepperd, M. Kadoda, G., « Comparing software prediction techniques using simulation », IEEE Transactions on Software Engineering, vol. 27, no 11,‎ , p. 1014–1022 (DOI 10.1109/32.965341, lire en ligne)
  18. ↑ a et b Jørgensen, M., « Estimation of Software Development Work Effort:Evidence on Expert Judgment and Formal Models »
  19. ↑ Winkler, R.L., « Combining forecasts: A philosophical basis and some current issues Manager », International Journal of Forecasting, vol. 5, no 4,‎ , p. 605–609 (DOI 10.1016/0169-2070(89)90018-6)
  20. ↑ Blattberg, R.C. Hoch, S.J., « Database Models and Managerial Intuition: 50% Model + 50% Manager », Management Science, vol. 36, no 8,‎ , p. 887–899 (DOI 10.1287/mnsc.36.8.887, JSTOR 2632364)
  21. ↑ BlueOptima, « outsource app development »,
  22. ↑ Jørgensen, M. Grimstad, S., « How to Avoid Impact from Irrelevant and Misleading Information When Estimating Software Development Effort », IEEE Software,‎ , p. 78–83 (lire en ligne)
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Estimation_d%27effort_de_développement_de_logiciel&oldid=209625687 ».