Software development effort estimation

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Software development effort estimation is the process of predicting the most realistic use of effort required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.

State-of-practice[edit]

Published surveys on estimation practice suggest that expert estimation is the dominant strategy when estimating software development effort.[1]

Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. For a review of effort estimation error surveys, see.[2] However, the measurement of estimation error is not unproblematic, see Assessing and interpreting the accuracy of effort estimates. The strong over-confidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or “almost sure” to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.[3]

Currently the term “effort estimate” is used to denote as different concepts as most likely use of effort (modal value), the effort that corresponds to a probability of 50% of not exceeding (median), the planned effort, the budgeted effort or the effort used to propose a bid or price to the client. This is believed to be unfortunate, because communication problems may occur and because the concepts serve different goals.[4][5]

History[edit]

Software researchers and practitioners have been addressing the problems of effort estimation for software development projects since at least the 1960s; see, e.g., work by Farr [6] and Nelson.[7]

Most of the research has focused on the construction of formal software effort estimation models. The early models were typically based on regression analysis or mathematically derived from theories from other domains. Since then a high number of model building approaches have been evaluated, such as approaches founded on case-based reasoning, classification and regression trees, simulation, neural networks, Bayesian statistics, lexical analysis of requirement specifications, genetic programming, linear programming, economic production models, soft computing, fuzzy logic modeling, statistical bootstrapping, and combinations of two or more of these models. The perhaps most common estimation methods today are the parametric estimation models COCOMO and SLIM. They both have their basis in estimation research conducted in the 1970s and 1980s and are since then updated with new calibration data, with the last major release being COCOMO II in the year 2000. The estimation approaches based on functionality-based size measures, e.g., function points, is also based on research conducted in the 1970s and 1980s, but are re-calibrated with modified size measures and different counting approaches, such as the “use case points” [8] in the 1990s and COSMIC in the 2000s.

Estimation approaches[edit]

There are many ways of categorizing estimation approaches, see for example.[9][10] The top level categories are the following:

  • Expert estimation: The quantification step, i.e., the step where the estimate is produced based on judgmental processes.
  • Formal estimation model: The quantification step is based on mechanical processes, e.g., the use of a formula derived from historical data.
  • Combination-based estimation: The quantification step is based on a judgmental and mechanical combination of estimates from different sources.

Below are examples of estimation approaches within each category.

Estimation approach Category Examples of support of implementation of estimation approach
Analogy-based estimation Formal estimation model ANGEL, Weighted Micro Function Points
WBS-based (bottom up) estimation Expert estimation Project management software, company specific activity templates
Parametric models Formal estimation model COCOMO, SLIM, SEER-SEM, TruePlanning for Software
Size-based estimation models[11] Formal estimation model Function Point Analysis,[12] Use Case Analysis, SSU (Software Size Unit), Story points-based estimation in Agile software development
Group estimation Expert estimation Planning poker, Wideband Delphi
Mechanical combination Combination-based estimation Average of an analogy-based and a Work breakdown structure-based effort estimate
Judgmental combination Combination-based estimation Expert judgment based on estimates from a parametric model and group estimation

Selection of estimation approach[edit]

The evidence on differences in estimation accuracy of different estimation approaches and models suggest that there is no “best approach” and that the relative accuracy of one approach or model in comparison to another depends strongly on the context .[13] This implies that different organizations benefit from different estimation approaches. Findings, summarized in,[14] that may support the selection of estimation approach based on the expected accuracy of an approach include:

  • Expert estimation is on average at least as accurate as model-based effort estimation. In particular, situations with unstable relationships and information of high importance not included in the model may suggest use of expert estimation. This assumes, of course, that experts with relevant experience are available.
  • Formal estimation models not tailored to a particular organization’s own context, may be very inaccurate. Use of own historical data is consequently crucial if one cannot be sure that the estimation model’s core relationships (e.g., formula parameters) are based on similar project contexts.
  • Formal estimation models may be particularly useful in situations where the model is tailored to the organization’s context (either through use of own historical data or that the model is derived from similar projects and contexts), and it is likely that the experts’ estimates will be subject to a strong degree of wishful thinking.

The most robust finding, in many forecasting domains, is that combination of estimates from independent sources, preferable applying different approaches, will on average improve the estimation accuracy.[15][16][17]

In addition, other factors such as ease of understanding and communicating the results of an approach, ease of use of an approach, cost of introduction of an approach should be considered in a selection process.

Assessing the accuracy of estimates[edit]

The most common measure of the average estimation accuracy is the MMRE (Mean Magnitude of Relative Error), where the MRE of each estimate is defined as:

MRE = \frac{|\text{actual effort} - \text{estimated effort}|}\text{actual effort}

This measure has been criticized [18] [19] [20] and there are several alternative measures, such as more symmetric measures [21] , Weighted Mean of Quartiles of relative errors (WMQ) [22] and Mean Variation from Estimate (MVFE).[23]

A high estimation error cannot automatically be interpreted as an indicator of low estimation ability. Alternative, competing or complementing, reasons include low cost control of project, high complexity of development work, and more delivered functionality than originally estimated. A framework for improved use and interpretation of estimation error measurement is included in.[24]

Psychological issues[edit]

There are many psychological factors potentially explaining the strong tendency towards over-optimistic effort estimates that need to be dealt with to increase accuracy of effort estimates. These factors are essential even when using formal estimation models, because much of the input to these models is judgment-based. Factors that have been demonstrated to be important are: Wishful thinking, anchoring, planning fallacy and cognitive dissonance. A discussion on these and other factors can be found in work by Jørgensen and Grimstad.[25]

  • It's easy to estimate what you know.
  • It's hard to estimate what you know you don't know.
  • It's very hard to estimate things that you don't know you don't know.

See also[edit]

References[edit]

  1. ^ Jørgensen, M. "A Review of Studies on Expert Estimation of Software Development Effort". 
  2. ^ Molokken, K. Jorgensen, M. "A review of software surveys on software effort estimation". 
  3. ^ Jørgensen, M. Teigen, K.H. Ribu, K. "Better sure than safe? Over-confidence in judgement based software development effort prediction intervals". 
  4. ^ Edwards, J.S. Moores, T.T. (1994), "A conflict between the use of estimating and planning tools in the management of information systems.". European Journal of Information Systems 3(2): 139-147.
  5. ^ 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
  6. ^ Farr, L. Nanus, B. "Factors that affect the cost of computer programming". 
  7. ^ Nelson, E. A. (1966). Management Handbook for the Estimation of Computer Programming Costs. AD-A648750, Systems Development Corp.
  8. ^ Anda, B. Angelvik, E. Ribu, K. "Improving Estimation Practices by Applying Use Case Models". 
  9. ^ Briand, L. C. and I. Wieczorek (2002). Resource estimation in software engineering. Encyclopedia of software engineering. J. J. Marcinak. New York, John Wiley & Sons: 1160-1196.
  10. ^ Jørgensen, M. Shepperd, M. "A Systematic Review of Software Development Cost Estimation Studies". 
  11. ^ Hill Peter (ISBSG) - Estimation Workbook 2 - published by International Software Benchmarking Standards Group ISBSG - Estimation and Benchmarking Resource Centre
  12. ^ Morris Pam — Overview of Function Point Analysis Total Metrics - Function Point Resource Centre
  13. ^ Shepperd, M. Kadoda, G. "Comparing software prediction techniques using simulation". 
  14. ^ Jørgensen, M. "Estimation of Software Development Work Effort:Evidence on Expert Judgment and Formal Models". 
  15. ^ Winkler, R.L. "Combining forecasts: A philosophical basis and some current issues Manager". 
  16. ^ Blattberg, R.C. Hoch, S.J. Database Models and Managerial Intuition: 50% Model + 50% Manager. JSTOR 2632364. 
  17. ^ Jørgensen, M. "Estimation of Software Development Work Effort:Evidence on Expert Judgment and Formal Models". 
  18. ^ Shepperd, M. Cartwright, M. Kadoda, G. "On Building Prediction Systems for Software Engineers". 
  19. ^ Kitchenham, B. Pickard, L.M. MacDonell, S.G. Shepperd,. "What accuracy statistics really measure". 
  20. ^ Foss, T. Stensrud, E. Kitchenham, B. Myrtveit, I. "A Simulation Study of the Model Evaluation Criterion MMRE". IEEE. 
  21. ^ Miyazaki, Y. Terakado, M. Ozaki, K. Nozaki, H. "Robust regression for developing software estimation models". 
  22. ^ Lo, B. Gao, X. "Assessing Software Cost Estimation Models: criteria for accuracy, consistency and regression". 
  23. ^ Hughes, R.T. Cunliffe, A. Young-Martos, F. "Evaluating software development effort model-building techniquesfor application in a real-time telecommunications environment". 
  24. ^ Grimstad, S. Jørgensen, M. "A Framework for the Analysis of Software Cost Estimation Accuracy". 
  25. ^ Jørgensen, M. Grimstad, S. "How to Avoid Impact from Irrelevant and Misleading Information When Estimating Software Development Effort". 

External links[edit]