Estimation Approaches

An estimation approach is the procedure that turns what is known about a piece of software — its requirements, its size, past projects — into a number for its size, effort, duration or cost. What separates the families is “the quantification step—that is, the final step that transforms the input into the effort estimate” [1]: a person, or a formula.

1. What is estimated

Estimates come in a chain: first size (lines of code, function points, story points), then effort from size and history, then schedule from effort, each wrapped in a range that is refined as the project moves [2]. Cost is effort priced at a rate. Size is the weakest link [3].

2. Six families

Miranda groups the approaches into six families [4]:

Family	How the number is produced	Needs
Judgment	an expert’s reasoning, unaided or structured — see expert judgment, Planning Poker, paired comparison	people who know similar work
Engineering	a cost function built from what drives the effort, such as functions × process activities [5]	knowledge of the process, not history
Counting	a weighted count of external characteristics — function points	a requirements specification
Industry norms	a published ratio, such as Jones’s schedule in months ≈ FP^0.4 [6]	a size; no local data
Analogy	the nearest completed projects in a case base, by Euclidean distance over known features, averaged [7]	“a minimum of 10-12 projects”
Parametric	a cost estimating relationship fitted by regression — COCOMO	a size and a calibrated model

A norm checks an estimate rather than making one: “Simple rules of thumb should not be used for contracts, bids, or other serious business purposes”, Jones writes of his own rules [6]. Phase splits are norms too, and they move with size: in COCOMO II, integration and test takes 19% of effort on a small project and 31% on a large one — figures the manual calls “provisional” [8].

3. The cost estimating relationship

A parametric model has the general form E = A + B × (ev)^C: effort in person-months from a size ev in lines of code or function points, with A, B and C “derived using regression analysis on data collected from past software projects” [5]. The simplest real one is Albrecht’s W = 54F − 13,390 work-hours from function points [9]. The constants are someone else’s history, so “Estimation models must be calibrated for local needs!”

4. Bottom-up and top-down

Top-down estimates the project as a whole against completed projects; bottom-up sums estimates of the activities in a WBS. The field evidence gives a simple rule: “software companies should apply the bottom-up strategy unless the estimators have experience from, or access to, very similar projects” [10]. The numbers are on expert judgment.

5. Combining methods when requirements are vague and history is missing

“Practice and the literature often recommend that several estimation methods be used in concert (when possible) to mitigate the bias, shortcomings, or risks of using a single method” [3]. The gain depends on independence: “A key assumption for accuracy improvement is that the estimates are independent” [11]. With a vague specification and no history, analogy and calibration are out, and five moves remain:

1. Three to five estimators from different roles, each alone first [12], then a group session to surface forgotten work.
2. Top-down and bottom-up, run independently: top-down from a published norm, bottom-up over a WBS with a checklist, which stands in for the missing history.
3. One cross-check that needs no local data, such as an uncalibrated model or a rule of thumb.
4. Read the spread instead of averaging it away. Wide divergence usually means misunderstood scope or wrong productivity data [5].
5. Report a range, re-estimate as requirements firm up, and start recording actuals.

For example, twenty professionals estimated a real web publication system alone: 220 to 2,286 hours, mean 1,088. In five mixed-role groups the mean rose to 1,548, against an actual 2,365 [13]. “The groups sometimes even identified necessary activities that none of the individuals had reported.”

6. Estimate, target, commitment

The estimate is the most likely effort, the target what the business wants, the commitment what the project promises. DeMarco and Lister separate “the goal (that which the project aims for), the estimate (the most likely outcome) and the schedule (what the project commits to)”, and the first guideline follows: “Do not mix estimation of most likely effort with planning, budgeting or pricing.” [14]

How solid is this?

• Combining is practice, not a measured effect. Only 5 of 304 estimation papers study it [15]; RAND and Pressman are syntheses.
• The group result is one company, one project, and groups who did not build the system.
• Analogy’s evidence is mixed, and its first author concedes the founding study “is not now reproducible” [16].

---

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [17] on software project management.

References

1. M. Jørgensen, B. Boehm, and S. Rifkin,
   “Software Development Effort Estimation: Formal Models or Expert Judgment?,” IEEE Software, vol. 26, no. 2, pp. 14–19, Mar. 2009, doi: 10.1109/MS.2009.47.
2. S. McConnell,
   Rapid development: taming wild software schedules. Pearson Education, 1996.
3. S. L. Pfleeger, F. Wu, and R. Lewis,
   “Software Cost Estimation and Sizing Methods: Issues and Guidelines,” RAND Corporation, Monograph MG-269, 2005.
4. E. Miranda,
   “Managing Software Development.” 2014.
5. R. S. Pressman,
   Software Engineering: A Practitioner’s Approach, 7th ed. McGraw-Hill, 2010.
6. C. Jones,
   “By Popular Demand: Software Estimating Rules of Thumb,” Computer, vol. 29, no. 3, pp. 116–118, Mar. 1996, doi: 10.1109/MC.1996.485905.
7. M. Shepperd and C. Schofield,
   “Estimating Software Project Effort Using Analogies,” IEEE Transactions on Software Engineering, vol. 23, no. 11, pp. 736–743, Nov. 1997, doi: 10.1109/32.637387.
8. Center for Software Engineering, USC,
   COCOMO II Model Definition Manual. Center for Software Engineering, University of Southern California, 2000.
9. A. J. Albrecht and J. E. Gaffney Jr.,
   “Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation,” IEEE Transactions on Software Engineering, vol. SE-9, no. 6, pp. 639–648, Nov. 1983, doi: 10.1109/TSE.1983.235271.
10. M. Jørgensen,
    “Top-down and Bottom-up Expert Estimation of Software Development Effort,” Information and Software Technology, vol. 46, no. 1, pp. 3–16, Jan. 2004, doi: 10.1016/S0950-5849(03)00093-4.
11. M. Jørgensen,
    “What We Do and Don’t Know about Software Development Effort Estimation,” IEEE Software, vol. 31, no. 2, pp. 37–40, 2014, doi: 10.1109/MS.2014.49.
12. M. Jørgensen,
    “A Review of Studies on Expert Estimation of Software Development Effort,” Journal of Systems and Software, vol. 70, no. 1–2, pp. 37–60, Feb. 2004, doi: 10.1016/S0164-1212(02)00156-5.
13. K. Moløkken-Østvold and M. Jørgensen,
    “Group Processes in Software Effort Estimation,” Empirical Software Engineering, vol. 9, no. 4, pp. 315–334, Dec. 2004, doi: 10.1023/B:EMSE.0000039882.39206.5a.
14. S. Grimstad, M. Jørgensen, and K. Moløkken-Østvold,
    “Software Effort Estimation Terminology: The Tower of Babel,” Information and Software Technology, vol. 48, no. 4, pp. 302–310, Apr. 2006, doi: 10.1016/j.infsof.2005.04.004.
15. M. Jørgensen and M. Shepperd,
    “A Systematic Review of Software Development Cost Estimation Studies,” IEEE Transactions on Software Engineering, vol. 33, no. 1, pp. 33–53, Jan. 2007, doi: 10.1109/TSE.2007.256943.
16. M. Shepperd,
    “‘Estimating Software Project Effort Using Analogies’: Reflections After 28 Years,” IEEE Transactions on Software Engineering, vol. 51, no. 3, pp. 778–782, Mar. 2025, doi: 10.1109/TSE.2025.3534032.
17. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

---

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.