Software development effort estimation: Difference between revisions

Content deleted Content added
External links: Removed low value commercial links
Citation bot (talk | contribs)
Alter: template type. Add: isbn, s2cid. | You can use this bot yourself. Report bugs here. | Suggested by SemperIocundus | via #UCB_webform
Line 22:
| isbn = 978-0-7695-2002-5
| chapter = A review of software surveys on software effort estimation
| 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 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.
Line 33 ⟶ 34:
| pages=79–93}}</ref>
 
Currently the term “effort 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 | url = | 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 46 ⟶ 47:
}}</ref> and Nelson.<ref>Nelson, E. A. (1966). Management Handbook for the Estimation of Computer Programming Costs. AD-A648750, Systems Development Corp.</ref>
 
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]], [[SEER-SEM]] and SLIM. They 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|use case points]]<ref>{{cite bookjournal
| author = Anda, B. Angelvik, E. Ribu, K.
| title = Improving Estimation Practices by Applying Use Case Models
Line 54 ⟶ 55:
| volume = 2559
| pages=383–397
| citeseerxisbn = 10.1.1.546.112978-3-540-00234-5
| citeseerx = 10.1.1.546.112
}} {{isbn|9783540002345|9783540362098}}.</ref> or [[object point]]s in the 1990s.
 
Line 167 ⟶ 169:
| year=2000
| journal=Empirical Software Engineering
| pages=175–182}}| s2cid = 1293988
}}
</ref>
<ref>{{cite web
Line 229 ⟶ 232:
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]]:
{{quotation |<!-- 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}}</ref> |Tom Cargill|[[Bell Labs]]}}
* [[Hofstadter's law]]:
{{quotation|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>