Software development effort estimation: Difference between revisions

Revision as of 23:39, 13 June 2023

Revision as of 18:58, 27 July 2023

Line 24:

| s2cid = 15471986

}}</ref> However, the measurement of estimation error is problematic, see [[#Assessing the accuracy of estimates|Assessing the accuracy of estimates]].

The strong overconfidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or “almost"almost sure”sure" to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.<ref>{{cite journal

| author = Jørgensen, M. Teigen, K.H. Ribu, K.

| title = Better sure than safe? Over-confidence in judgement based software development effort prediction intervals

Line 34:

| pages=79–93}}</ref>

Currently the term “effort"effort estimate”estimate" is used to denote as different concepts such 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.<ref>{{cite journal | last1 = Edwards | first1 = J.S. Moores | year = 1994 | title = A conflict between the use of estimating and planning tools in the management of information systems | journal = [[European Journal of Information Systems]] | volume = 3 | issue = 2| pages = 139–147 | doi=10.1057/ejis.1994.14| s2cid = 62582672 }}</ref><ref>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</ref>

==History==

Line 66:

==Estimation approaches==

There are many ways of categorizing estimation approaches, see for example.<ref>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-11961160–1196.</ref><ref>{{cite web

| author = Jørgensen, M. Shepperd, M.

| title = A Systematic Review of Software Development Cost Estimation Studies

| url = http://simula.no/research/engineering/publications/Jorgensen.2007.1 }}</ref> 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.<ref>{{cite web | url=http://www.oxagile.com/services/custom-software-design-and-development/ | title=Custom Software Development Services -– Custom App Development -– Oxagile}}</ref>

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

Line 94:

| [[COCOMO]], [[Putnam model|SLIM]], [[SEER-SEM]], [[TruePlanning for Software]]

|-

| Size-based estimation models<ref>Hill Peter (ISBSG) -– Estimation Workbook 2 -– published by International Software Benchmarking Standards Group [http://www.isbsg.org/ISBSGnew.nsf/WebPages/~GBL~Practical%20Project%20Estimation%202nd%20Edition ISBSG - Estimation and Benchmarking Resource Centre] {{Webarchive|url=https://web.archive.org/web/20080829172340/https://www.isbsg.org/isbsgnew.nsf/WebPages/~GBL~Practical%20Project%20Estimation%202nd%20Edition |date=2008-08-29 }}</ref>

| Formal estimation model

| [[Function Point Analysis]],<ref>Morris Pam&nbsp;— Overview of Function Point Analysis [http://www.totalmetrics.com/function-point-resources/what-are-function-points Total Metrics - Function Point Resource Centre]</ref> [[Use Case]] Analysis, [[Use Case Points]], SSU (Software Size Unit), [[Story point]]s-based estimation in [[Agile software development]], [[Object point|Object Points]]

Line 104:

| Mechanical combination

| Combination-based estimation

| Average of an analogy-based and a [[Work breakdown structure]]-based effort estimate<ref>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, NY, USA, 75-78. {{doi|10.1145/2134254.2134267}}</ref>

|-

| Judgmental combination

Line 112:

==Selection of estimation approaches==

The evidence on differences in estimation accuracy of different estimation approaches and models suggest that there is no “best"best approach”approach" and that the relative accuracy of one approach or model in comparison to another depends strongly on the context

.<ref>{{cite journal

| author = Shepperd, M. Kadoda, G.

Line 129:

| url = http://simula.no/research/engineering/publications/Jorgensen.2007.2 }}</ref> 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’sorganization's own context, may be very inaccurate. Use of own historical data is consequently crucial if one cannot be sure that the estimation model’smodel'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’sorganization'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.<ref name="Jørgensen, M"/><ref>{{cite journal

Line 210:

| author = Hughes, R.T. Cunliffe, A. Young-Martos, F.

| title = Evaluating software development effort model-building techniquesfor application in a real-time telecommunications environment

| journal = IEE Proceedings -– Software

| volume = 145

| page = 29

Line 238:

The chronic underestimation of development effort has led to the coinage and popularity of numerous humorous adages, such as ironically referring to a task as a "[[small matter of programming]]" (when much effort is likely required), and citing laws about underestimation:

* [[Ninety–ninety rule]]:

{{quotationblockquote |<!-- PLEASE DON'T CHANGE THIS QUOTE WITHOUT CHECKING THE ORIGINAL SOURCE! THE %'S ARE NOT SUPPOSED TO TOTAL 100%! -->The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90<!-- YES THIS TOTALS 180%! THIS IS NOT AN ERROR! --> percent of the development time.<ref name="Bentley1985">{{cite journal|last= Bentley|first= Jon|year= 1985|title= Programming pearls|journal= Communications of the ACM|volume= 28|issue= 9|pages= 896–901|issn= 0001-0782|doi= 10.1145/4284.315122|s2cid= 5832776|format= fee required|doi-access= free}}</ref> |Tom Cargill|[[Bell Labs]]}}

* [[Hofstadter's law]]:

{{quotationblockquote|Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.|[[Douglas Hofstadter]]| ''[[Gödel, Escher, Bach: An Eternal Golden Braid]]''<ref>

''Gödel, Escher, Bach: An Eternal Golden Braid''. 20th anniversary ed., 1999, p. 152. {{ISBN|0-465-02656-7}}.

</ref>

}}

* [[Brooks's law|Fred Brooks' law]]:

{{quotationblockquote|What one programmer can do in one month, two programmers can do in two months.|[[Fred Brooks]]|

}}