Section 2 · Project Estimation Techniques
On this page 12 headings
Why estimation matters
Project estimation helps establish cost, establish a schedule and bid for projects. More detailed information about the project leads to more accurate estimates.
Software size and person-months
Lines of Code (LOC) measure software size. A KLOC is 1,000 lines of code; 4,000 LOC = 4 KLOC.
A person-month is the amount of work done by one person in one month. 12 PM = 12 × 1 = 4 × 3 = 2 × 6: 12 people for 1 month, 4 people for 3 months, or 2 people for 6 months.
Work is expressed in person-months because it is easier to get a feel for how many people are needed to finish the work in a fixed time.
Empirical estimation versus heuristic estimation
Empirical estimation uses experience and educated judgement. Heuristic estimation uses mathematical relationships between parameters such as size and effort.
Expert judgement
An expert makes an educated guess about the problem size after analysing the problem thoroughly, estimates the cost of the different components, and combines them into an overall estimate.
Drawbacks of expert judgement
| Drawback | Example |
|---|---|
| Human errors and individual bias | Bias towards a technology/framework |
| Optimistic estimates | Even more so to win a contract |
| Overlooking factors / lack of adequate knowledge | Strong in database and UI, weak on additional modules or plugins |
Solved by a group of experts? To an extent — but the group can still be biased, and decisions may be dominated by overly assertive or senior members.
Delphi estimation: anonymous repeated rounds
A coordinator gives each expert the SRS and an estimation form. Each expert estimates independently and submits their result to the coordinator. The coordinator summarizes the responses without identifying their authors and distributes the summary back to the experts.
Experts review the anonymous feedback and revise their estimates independently. Rounds repeat; the coordinator compiles the final estimate.
No discussion between experts is allowed during the entire process, because some may be influenced by an experienced or senior estimator; comments in the summary stay anonymous.
COCOMO: the effort model
COCOMO (Constructive Cost Model), introduced by Boehm in 1981: Effort = a × (SIZE in KLOC)^b person-months. The constants a and b depend on the type of project.
COCOMO project types
| Type | Description | a | b |
|---|---|---|---|
| Organic | A well-understood application program; small team, mostly experienced | 2.4 | 1.05 |
| Semi-detached | A mix of experienced and inexperienced people with limited experience building related systems | 3.0 | 1.12 |
| Embedded | Strongly coupled with hardware; team may be large with many inexperienced people | 3.6 | 1.20 |
Effort depends not only on size but also on the type of project and the composition of the team; constants are lowest for organic (2.4, 1.05) and highest for embedded.
Seller Portal: estimate the size of seven modules
Not a straightforward system — modules interface with the main Amazon system and with banks for payments — so classified semi-detached (in some cases it could be embedded). LOC per module estimated from data of previous projects.
| Seller Portal module | Estimated LOC |
|---|---|
| Catalogue add/edit/delete | 300 |
| Inventory add/edit/delete | 300 |
| Order tracking | 1,000 |
| Payment tracking | 800 |
| Inventory tracking | 800 |
| Sales tracking | 500 |
| Customer feedback | 300 |
| TOTAL | 4,000 = 4 KLOC |
Cost drivers and effort adjustment factor
Required software reliability = very high (orders and money involved) → 1.40; database size = high → 1.08; application experience of the team = low → 1.13; programming language experience = high → 0.95. The 15 cost drivers are grouped into product, computer, personnel (and project) attributes; multiplying all of them gives the effort adjustment factor. Here only four are used for simplicity.
Other factors beyond size: people working on the project (experience with the framework/domain — e.g. e-commerce), technical attributes of the product (database size, complexity, reliability), tools and practices used by the team.
COCOMO worked example: slide values and corrected calculation
| Step | Slide value | Correct calculation |
|---|---|---|
| Initial effort = 3.0 × 4^1.12 | 15.83 PM | ≈ 14.17 PM |
| Effort adjustment factor = 1.40 × 1.08 × 1.13 × 0.95 | 1.62 | 1.62 |
| Final estimate = initial × EAF | 25.65 PM | ≈ 23.0 PM |
| Cost before adjustment (rounded initial effort), at ₹75,000 per person per month | 16 × 75,000 = ₹12 lakh | 14 × 75,000 ≈ ₹10.5 lakh |
Using the adjusted effort of approximately 23.0 person-months, the adjusted cost is 23.0 × ₹75,000 ≈ ₹17.25 lakh. The initial cost before adjustment is approximately ₹10.63 lakh without rounding effort to 14 PM.
The slide's 15.83 PM does not follow from 3.0 × 4^1.12 (which evaluates to ≈14.17). The method is unchanged; only the arithmetic differs. If asked to compute, use the correct value; if asked what the lecture states, it is 15.83 PM.
COCOMO summary
Determine the type of product → estimate LOC for each module → initial estimate → effort adjustment factor from the 15 cost drivers → overall estimate. The overall estimate depends on the LOC estimates, so get as much detail as possible and be aware of your biases.
A British Computer Society survey of more than 1000 projects found 92% of project managers made estimates using experience instead of formulas (A. Taylor, BCS Review, Jan 2000).