Module 3
Effort Estimation
Effort estimation is the process of predicting the amount of effort (person-
hours, cost, duration) required to develop a software system.
It forms the basis for scheduling, budgeting, staffing, and resource
allocation.
Estimation accuracy is critical because poor estimates are a leading cause of
project failure.
Problems with Estimation
Over-Estimation
Predicting more effort than required.
Effects:
Project may appear too costly and fail to win approval.
If approved, resources are under-utilized.
Wastage of allocated budget.
Parkinson’s Law: “Work expands to fill the time available.”→ Teams work
slower if given more time.
Brooks’ Law: “Adding manpower to a late project makes it later.”→ More
people = more communication overhead = less productivity.
Reduced competitiveness when bidding for contracts.
Under-Estimation
Predicting less effort than required.
Effects:
Project may be accepted but is actually unfeasible.
Module 3 1
Leads to rushed work, rework during testing, and delayed completion.
Leads to cost overruns, schedule slippage, and poor quality.
Creates stress on the development team. Pressure on staff → reduced
quality
In extreme cases → project failure and damage to supplier’s reputation.
How Agile Tries to Fix It
Agile methods (like Extreme Programming) handle uncertainty by using short
iterations and continuous re-estimation, preventing both over- and under-
estimates.
Measures of Work Size
Source Lines of Code (SLOC or KLOC): Basic measure, but limited since it
ignores code complexity.
Function Points (FP): Measure based on user-visible functionality,
independent of language or tools.
Software Effort Estimation Techniques
1. Expert Judgment
In this method, estimates are made by professionals who have expertise and
experience in similar types of projects.
Procedure:
1. The expert studies the project requirements.
2. Based on past experience and understanding, the expert provides an
effort, time, and cost estimate.
3. It can be done individually or by group consensus.
Advantages:
Fast and simple when detailed data is unavailable.
Incorporates human experience, especially valuable for unique projects.
Module 3 2
Disadvantages:
Subjective and prone to bias.
Accuracy depends entirely on the expert’s knowledge.
2. Estimation by Analogy (Analogous Estimation)
Uses similar completed projects (source cases) to estimate effort or cost for
a new project (target case).
Steps:
1. Identify previous projects with similar characteristics.
2. Select the most comparable one.
3. Adjust for differences in size, complexity, or technology.
The project with the smallest distance is considered the best analogy.
Advantages:
Simple and effective when historical data exists.
Incorporates real-world performance data.
Disadvantages:
Requires a good database of previous projects.
Difficult when no comparable projects exist.
3. Delphi Technique
The Delphi Technique is a structured group consensus method that refines
expert judgment by collecting independent, anonymous estimates from
multiple experts and reaching consensus through iteration.
Procedure:
1. A coordinator distributes project details to experts.
2. Experts provide their estimates independently.
Module 3 3
3. The coordinator summarizes all estimates (with reasoning) and
redistributes them anonymously.
4. Experts revise their estimates after reviewing others’ reasoning.
5. Steps 3–4 repeat until consensus is reached.
Advantages:
Reduces dominance or group pressure effects.
Combines diverse expertise.
Produces more objective and consistent estimates.
Disadvantages:
Time-consuming, requires coordination.
4. Lines of Code (LOC)–based Estimation
Estimate the number of LOC that will be produced, then use productivity rates
(e.g., staff-months per 1,000 LOC).
Models like COCOMO use LOC as a key input.
Pros: Simple and tied to implementation size.
Cons: Cannot be measured until design is stable; does not account for code
complexity or language type.
5. Function Point Analysis (FPA)
A language-independent, user-focused method measuring software
functionality delivered to the user rather than lines of code.
Measures software size by counting user-visible features (inputs, outputs,
files, inquiries, interfaces).
Each function is given a weight (simple/average/complex).
Five Function Types (External User Types):
1. External Inputs (EI): Data entering the system.
Module 3 4
2. External Outputs (EO): Reports, results produced.
3. External Inquiries (EQ): Input requests that do not update data.
4. Internal Logical Files (ILF): Internal data storage.
5. External Interface Files (EIF): Shared data with other systems.
Steps:
1. Count each function type with complexity level (Low, Average, High).
2. Multiply by weights.
3. Sum all to get Unadjusted Function Points (UFP).
4. Calculate Complexity Adjustment Factor (CAF) using 14 general system
characteristics (each 0–5).
1. Compute Adjusted Function Points (AFP):
Pros: Independent of programming language; can be applied early.
Cons: Requires trained estimators; time-consuming; some subjectivity
remains.
6. Use Case Points (UCP)
Estimates based on number and complexity of use cases in UML models.
Steps:
1. Assign weights to actors and use cases.
2. Adjust for technical and environmental factors.
3. Convert total into effort using standard productivity rates.
Module 3 5
Pros: Well-suited for object-oriented projects; can be derived early using
UML diagrams.
Cons: Needs detailed use case models early.
Module 3 6