Software development effort estimation: Difference between revisions

Revision as of 18:58, 27 July 2023

Latest revision as of 10:52, 27 August 2025

(19 intermediate revisions by 11 users not shown)

Line 1:

{{Short description|Process in software development}}

In [[software development]], '''effort estimation''' is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain [[software]] based on incomplete, uncertain and noisy input. Effort [[estimation|estimates]] may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.<ref>{{cite web | url=http://www.infoq.com/articles/software-development-effort-estimation | title=What We do and Don't Know about Software Development Effort Estimation}}</ref><ref>{{cite web|title=Cost Estimating And Assessment Guide GAO-09-3SP Best Practices for developing and managing Capital Program Costs|date=2009|publisher=US Government Accountability Office|url=https://www.gao.gov/new.items/d093sp.pdf }}</ref>

Line 53 ⟶ 54:

}}</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 journalbook

| author = Anda, B. Angelvik, E. Ribu, K.

| title = ImprovingProduct EstimationFocused PracticesSoftware byProcess Applying Use Case ModelsImprovement

| chapter = Improving Estimation Practices by Applying Use Case Models

| doi=10.1007/3-540-36209-6_32

| journalseries = Lecture Notes in Computer Science

| doi=10.1007/3-540-36209-6_32

| year=2002

| journal=Lecture Notes in Computer Science

| volume = 2559

| pages=383–397

| isbn = 978-3-540-00234-5

| citeseerx = 10.1.1.546.112

}} {{isbn|9783540002345|9783540362098}}.</ref> or [[object point]]s and [[COSMIC_functional_size_measurement|COSMIC Function Points]] in the 1990s.

==Estimation approaches==

Line 122 ⟶ 124:

| doi = 10.1109/32.965341

| year = 2001

| bibcode = 2001ITSEn..27.1014S
| url = http://bura.brunel.ac.uk/handle/2438/1102

}}

</ref> This implies that different organizations benefit from different estimation approaches. Findings<ref name="Jørgensen, M">{{cite web

Line 179 ⟶ 182:

</ref>

<ref>{{cite web

| author = [[Barbara Kitchenham|Kitchenham, B.]], Pickard, L.M., MacDonell, S.G. Shepperd

| title = What accuracy statistics really measure

| url = http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=IPSEFU000148000003000081000001&idtype=cvips&gifs=yes }}

</ref>

<ref>{{cite journal

| author = Foss, T., Stensrud, E., [[Barbara Kitchenham|Kitchenham, B.]], Myrtveit, I.

| title = A Simulation Study of the Model Evaluation Criterion MMRE

| journal = IEEE Transactions on Software Engineering

Line 192 ⟶ 195:

| url = http://portal.acm.org/citation.cfm?id=951936 | doi = 10.1109/TSE.2003.1245300

| year = 2003

| citeseerxbibcode = 102003ITSEn.1.129.101.5792985F

| citeseerx = 10.1.1.101.5792

}}

</ref> and there are several alternative measures, such as more symmetric measures,<ref>{{cite journal

Line 210 ⟶ 214:

| 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

| url = https://ieeexplore.ieee.org/document/689296 | archive-url = https://web.archive.org/web/20170920055746/http://ieeexplore.ieee.org/document/689296/ | url-status = dead | archive-date = September 20, 2017 | doi = 10.1049/ip-sen:19983370

| year = 1998

| doi-broken-date = 12 July 2025

}}</ref>

MRE is not reliable if the individual items are skewed. PRED(25) is preferred as a measure of estimation accuracy. PRED(25) measures the percentage of predicted values that are within 25 percent of the actual value.

Line 226 ⟶ 231:

==Psychological issues==

There are many psychological factors potentially explaining the strong tendency towards over-optimistic effort estimates. These factors are essential to consider 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 (cognitive bias)|anchoring]], [[planning fallacy]] and [[cognitive dissonance]].<ref>{{cite webjournal

| author = Jørgensen, M. Grimstad, S.

| title = How to Avoid Impact from Irrelevant and Misleading Information When Estimating Software Development Effort

| journal = IEEE Software

| url = https://www.simula.no/publications/avoiding-irrelevant-and-misleading-information-when-estimating-development-effort }}

| date = 2008

| pages = 78–83

| url = https://www.simula.no/publications/avoiding-irrelevant-and-misleading-information-when-estimating-development-effort }}

</ref>

* It's easy to estimate what is known.

Line 245 ⟶ 253:

}}

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

{{blockquote|What one programmer can do in one month, two programmers can do in two months.|[[Fred Brooks]]|{{Citation needed|date=November 2024|reason=Where did this exact quote come from?}}

}}