Software Effort Estimation: Techniques, Models & Real-World Applications

Core Concepts: What is Software Effort Estimation?

Software effort estimation is the process of predicting the amount of work (in person-hours, person-months) required to develop a software project. It is a critical input for project planning, budgeting, and scheduling. Poor estimates lead to:

• Under-budgeting → missed deadlines, stressed teams
• Over-budgeting → wasted resources, lost bids
• Unrealistic timelines → client dissatisfaction

Why Estimate Effort?

1. Classification of Estimation Techniques

Estimation techniques can be grouped into three broad categories, each with trade-offs in accuracy, effort, and adaptability.

A. Expert Judgment (Non-Algorithmic)

Definition: Estimates are made by experienced professionals (e.g., senior developers, project managers) based on intuition, past projects, and domain knowledge.

How It Works

1. Individual Estimation: A single expert provides an estimate.
2. Group Estimation (Wideband Delphi): Multiple experts discuss and refine estimates iteratively.
3. Analogy-Based: Compare the new project to similar past projects.

Worked Example: Estimating a Mobile App for Pathao

Scenario: A startup wants to build a ride-hailing app like Pathao but for electric rickshaws in Kathmandu. Expert Judgment Steps:

1. Breakdown: The app has modules:
   • User registration/login (3 person-weeks)
   • Ride booking system (5 person-weeks)
   • Payment gateway (4 person-weeks, due to PCI compliance)
   • Driver tracking (6 person-weeks, using Google Maps API)
   • Admin dashboard (3 person-weeks)
2. Adjustments:
   • Risk Factor: Payment gateway is high-risk (add 20% buffer → 4.8 person-weeks).
   • Team Size: 2 developers, 1 QA tester → Total effort = 21 person-weeks ÷ 3 = 7 weeks.
3. Final Estimate: 7 weeks (with 10% contingency → 7.7 weeks).

Advantages

• Fast and low-cost.
• Works well for unique or innovative projects where historical data is scarce.
• Captures intuitive insights (e.g., "This API will be tricky").

Disadvantages

• Subjective: Biases (optimism, overconfidence) affect accuracy.
• Inconsistent: Different experts may give wildly different estimates.
• No repeatability: Hard to justify to clients or stakeholders.

B. Algorithmic (Parametric) Models

These use mathematical formulas based on project attributes (e.g., size, complexity, team experience). The most famous are:

1. COCOMO (Constructive Cost Model)
2. SLIM (Software Life-cycle Management)
3. Function Point Analysis (FPA)

classDiagram
    class COCOMO {
      +Basic: Effort = a × (KLOC)^b
      +Intermediate: Effort = a × (KLOC)^b × EM
      +Advanced: Phase-specific models
    }
    class SLIM {
      +Effort = a × Size^b
      +Schedule = c × (Effort)^d
      +Cost = Effort × Salary
    }
    class FPA {
      +EI + EO + EQ + ILF + EIF → Function Points
      +Adjustment factors (complexity, etc.)
    }
    COCOMO <|-- SLIM : "Uses historical data"
    SLIM <|-- FPA : "Size metric flexibility"

1. COCOMO (Boehm, 1981)

Definition: A three-level model that estimates effort based on lines of code (LOC) and 15 cost drivers (e.g., team experience, product complexity).

COCOMO Levels

COCOMO II (Updated Version)

• Uses object points (not just LOC) for OO projects.
• Includes early design model (for high-level estimates) and post-architecture model (for detailed estimates).

Worked Example: Estimating a Bank Loan Management System (Nepal Bank)

Scenario: A bank wants to develop a loan approval system with:

• 50,000 LOC (estimated)
• Cost drivers (from COCOMO II):
  • RELY (Reliability) = 1.05 (high, as loans involve money)
  • CPLX (Complexity) = 1.10 (moderate, due to regulatory rules)
  • TIME (Execution time constraints) = 1.00 (no strict deadline)
  • STOR (Database size) = 1.00 (moderate)

Formula (Intermediate COCOMO):

Effort (person-months) = 2.94 × (KLOC)^1.05 × EM
where EM = Product of Effort Multipliers (EM = RELY × CPLX × TIME × STOR × ...)

Calculation:

1. KLOC = 50
2. EM = 1.05 × 1.10 × 1.00 × 1.00 × ... (assume others = 1.0 for simplicity) = 1.155
3. Effort = 2.94 × (50)^1.05 × 1.155 ≈ 2.94 × 52.5 × 1.155 ≈ 175 person-months

Adjustments:

• Team size: 5 developers → 35 months (≈ 2.9 years).
• Contingency: Add 20% → 3.5 years.

Real-World Tie-In: Nepal’s Nepal Rastra Bank (NRB) uses similar models to estimate core banking system upgrades, which cost millions of rupees and take 18–24 months.

2. SLIM (Software Life-cycle Management)

Definition: A parametric model that estimates effort, schedule, and cost using historical data and Bayesian statistics.

Key Features:

• Uses three equations:
  1. Effort = a × Size^b
  2. Schedule = c × (Effort)^d
  3. Cost = Effort × Salary Rate
• Size can be in function points, LOC, or object points.

Worked Example: Estimating a Daraz Order Processing System Scenario: Daraz wants to upgrade its order processing module to handle 10,000 transactions/hour. Inputs:

• Size: 80 function points (estimated via FPA).
• Historical data: Past projects of similar size took 120 person-days per function point.
• Team: 4 developers, 1 QA tester.

SLIM Estimate:

1. Effort = 80 FP × 120 person-days/FP = 9,600 person-days.
2. Convert to person-months: 9,600 ÷ 20 = 480 person-months.
3. With 4 people: 480 ÷ 4 = 12 months.

Real-World Tie-In: Daraz uses SLIM-like models to estimate seasonal traffic spikes (e.g., Dashain/Tihar sales) and scales teams accordingly.

3. Function Point Analysis (FPA)

Definition: Estimates effort based on software functionality (inputs, outputs, queries, files) rather than code size.

Steps:

1. Identify 5 function types:
   • External Inputs (EI)
   • External Outputs (EO)
   • External Inquiries (EQ)
   • Internal Logical Files (ILF)
   • External Interface Files (EIF)
2. Assign weights (from IFPUG standard).
3. Calculate Unadjusted Function Points (UFP).
4. Adjust for complexity (using 14 General System Characteristics like performance, security).

Worked Example: Estimating a Kathmandu Traffic Management App Scenario: A smart city project wants to build an app to optimize traffic signals in Kathmandu. Function Breakdown:

Adjustment Factor (VAF):

• Complexity Factors (e.g., distributed processing = 1.05, performance = 1.10).
• Assume VAF = 1.20 (moderate complexity).
• Adjusted FP = 101 × 1.20 = 121.2.

Effort Estimate:

• Historical data: 10 person-hours per FP.
• Total effort = 121.2 FP × 10 = 1,212 person-hours.
• With 2 developers: 1,212 ÷ 160 (8-hour workweek) ÷ 2 = ~3.8 weeks.

Real-World Tie-In: Kathmandu Metropolitan City (KMC) uses FPA to estimate smart city projects, which often involve third-party integrations (e.g., traffic cameras, IoT sensors).

Comparison Table: Expert Judgment vs. Algorithmic Models

2. Bottom-Up vs. Top-Down Estimation Approaches

Estimation can be done bottom-up (detailed) or top-down (high-level). Each has pros and cons.

A. Bottom-Up Estimation

Definition: Break the project into small tasks, estimate each, and sum them up.

How It Works

1. Work Breakdown Structure (WBS): Decompose the project into tasks (e.g., "Develop login screen," "Test payment gateway").
2. Estimate each task: Use expert judgment or historical data.
3. Sum efforts: Add up all tasks + contingency (10–20%).

Worked Example: Estimating a WhatsApp Clone for Nepal

WBS Breakdown:

Advantages

• Accurate: Captures all details.
• Flexible: Easy to adjust if scope changes.

Disadvantages

• Time-consuming: Requires detailed planning.
• Risk of overestimation: Developers may pad estimates.

B. Top-Down Estimation

Definition: Start with a high-level estimate (e.g., "This project will take 6 months") and break it down later.

How It Works

1. Initial guess: Based on past projects or analogy.
2. Allocate effort: Divide total effort into phases (e.g., 30% design, 40% development).
3. Refine later: Adjust as details emerge.

Worked Example: Estimating a Government e-Service Portal (eSewa-like)

Top-Down Steps:

1. Initial Estimate: "Similar to eSewa, this will take 8 months."
2. Phase Breakdown:
   • Requirements: 1 month (10%)
   • Design: 2 months (20%)
   • Development: 4 months (50%)
   • Testing: 1 month (10%)
   • Deployment: 0.5 months (5%)
3. Team Size: 6 people → Total effort = 8 × 6 = 48 person-months.

Advantages

• Fast: Useful for early bids/proposals.
• Big-picture focus: Aligns with business goals.

Disadvantages

• Less accurate: Misses low-level details.
• Risk of misalignment: May not match actual work needed.

Comparison Table: Bottom-Up vs. Top-Down

3. Hybrid Approaches: Combining Methods

In practice, most projects use a mix of top-down and bottom-up, or combine expert judgment with algorithmic models.

Example: COCOMO + Bottom-Up

1. Top-Down: Use COCOMO for a high-level estimate (e.g., "Project will take 18 months").
2. Bottom-Up: Break into WBS tasks, estimate each, and adjust COCOMO parameters.
3. Reconcile: If bottom-up says 20 months, revisit COCOMO assumptions.

sequenceDiagram
    participant Expert
    participant COCOMO
    participant BottomUp
    
    Expert->>COCOMO: Input: 50KLOC, RELY=1.05, CPLX=1.10
    COCOMO-->>Expert: Effort ≈ 175 person-months
    
    Expert->>BottomUp: Breakdown:
    Expert->>BottomUp: - Loan approval (40KLOC)
    Expert->>BottomUp: - Reporting (10KLOC)
    BottomUp-->>Expert: Total: 50KLOC (matches COCOMO)
    
    Expert->>Expert: Adjust for team size (5 devs) + 20% contingency
    Expert-->>Expert: Final: 3.5 years

4. Common Pitfalls in Effort Estimation

Even experienced teams make mistakes. Here are five critical errors:

stateDiagram-v2
    [*] --> Estimate
    Estimate --> Overoptimism: "Underestimates risk (e.g., Pathao’s payment gateway)"
    Estimate --> IgnoreRisk: "Forgets API downtime (e.g., Daraz’s Dashain traffic)"
    IgnoreRisk --> Contingency: "Adds 10–20% buffer"
    Overoptimism --> Stakeholder: "Client demands 30% reduction"
    Stakeholder --> [*]: "Project fails"
    Contingency --> [*]: "Project succeeds"

A. Over-Optimism (Unrealistic Estimates)

• Cause: Developers underestimate complexity (e.g., "This API will be easy!").
• Example: A team estimated a payment gateway for a fintech app in 2 weeks but took 6 weeks due to PCI compliance issues.
• Fix: Use padding (e.g., add 20–30% buffer) and historical data.

B. Ignoring Risk Factors

• Cause: Not accounting for unknowns (e.g., third-party delays, regulatory changes).
• Example: Ncell’s mobile money system faced delays due to Nepal Rastra Bank’s new KYC rules.
• Fix: Use risk-adjusted estimates (e.g., add 30% for high-risk tasks).

C. Inconsistent Units

• Cause: Mixing person-hours, person-days, and person-months without conversion.
• Example: Estimating in person-months but tracking in hours leads to confusion.
• Fix: Stick to one unit (e.g., person-months) and document conversions.

D. Not Validating with Stakeholders

• Cause: Estimates are made in isolation without client/team input.
• Example: A Daraz vendor portal was estimated at 3 months but took 6 months because stakeholders didn’t review requirements early.
• Fix: Walkthroughs and peer reviews of estimates.

E. Using Outdated Data

• Cause: Relying on old project metrics (e.g., COCOMO data from 2010 for a 2024 project).
• Example: Estimating a cloud-based app using COCOMO data from monolithic systems.
• Fix: Update models with current team velocity and technology trends.

In the Real World

Software effort estimation is everywhere in Nepal’s tech industry. Here’s how companies apply these techniques:

1. eSewa: Function Point Analysis for Government Portals

• What they do: eSewa uses FPA to estimate government service portals (e.g., citizenship certificate, tax payments).
• Why it matters: The Nepal Government’s Digital Nepal vision requires accurate costing for 100+ online services.
• Real Example: The citizenship certificate portal was estimated at 120 function points and took 4 months (vs. initial 2-month guess).

2. Daraz: COCOMO for Seasonal Traffic Spikes

• What they do: Daraz uses COCOMO II to estimate Black Friday/Dashain sales traffic.
• Why it matters: During peak seasons, their system must handle 10× normal traffic.
• Real Example: For Dashain 2023, Daraz estimated:
  • Size: 800 function points (due to new features like "lightning deals").
  • Effort: 1,200 person-days (≈ 50 developers for 3 months).
  • Outcome: Successfully handled 2 million orders/day without crashes.

3. Ncell: SLIM for Network Upgrades

• What they do: Ncell uses SLIM to estimate 5G rollout efforts in Nepal.
• Why it matters: 5G requires new infrastructure (small cells, fiber backhaul).
• Real Example: For Pokhara 5G pilot, Ncell estimated:
  • Effort: 500 person-months (≈ 25 engineers for 2 years).
  • Cost: ~Rs. 2 billion (including hardware and training).
  • Result: On-time launch with 99.9% uptime.

4. Pathao: Bottom-Up for Driver App Updates

• What they do: Pathao uses bottom-up estimation for driver app updates (e.g., new payment methods, safety features).
• Why it matters: Drivers are highly price-sensitive—delays mean lost earnings.
• Real Example: Adding UPI payments was broken into:
  • Backend integration (3 weeks)
  • Driver app update (2 weeks)
  • Testing (1 week)
  • Total: 6 weeks (vs. initial 3-week guess).

5. Nepal Rastra Bank (NRB): Risk-Adjusted COCOMO for Core Banking

• What they do: NRB uses COCOMO with risk buffers for core banking system upgrades.
• Why it matters: Banking systems cannot fail—downtime means millions in losses.
• Real Example: For a loan processing upgrade, NRB added:
  • 20% buffer for regulatory changes.
  • 15% buffer for third-party API delays.
  • Final estimate: 36 months (vs. 30 months without buffers).

Exam Tip: How to Score Full Marks

This unit is highly theoretical but expects practical application. Here’s how to maximize marks:

1. Understand the Syllabus Expectations

• Define clearly: Always start with precise definitions (e.g., "COCOMO is a parametric model...").
• Compare methods: Exams often ask to contrast two techniques (e.g., "Compare COCOMO and SLIM").
• Apply to real scenarios: Use Nepalese examples (e.g., eSewa, Daraz, Ncell) in your answers.

2. Common Exam Patterns

3. Model Answer Structure

Question: "Explain COCOMO with a worked example for a Nepalese software project." Answer Structure:

1. Definition: "COCOMO is a parametric effort estimation model developed by Boehm in 1981..."
2. Levels: Briefly describe basic, intermediate, advanced.
3. Worked Example:
   • Scenario: "Estimate effort for a bank loan management system with 50 KLOC..."
   • Steps: Show formula, cost drivers, calculation.
   • Real-World Tie-In: "Nepal Rastra Bank uses similar models for core banking upgrades..."
4. Limitations: "COCOMO assumes linear growth in effort, which may not hold for Agile projects."

4. Avoid These Mistakes

• ❌ No calculations: If a question asks for an estimate, show the math.
• ❌ Vague examples: Don’t say "a website"—say "eSewa’s payment gateway".
• ❌ Ignoring units: Always specify person-hours, person-months, etc.
• ❌ Copy-pasting definitions: Paraphrase and add your own insights.

5. Quick Revision Checklist

Before the exam, ensure you can: ✅ List 3 algorithmic models (COCOMO, SLIM, FPA) and their differences. ✅ Explain bottom-up vs. top-down with a Nepalese example. ✅ Calculate COCOMO effort for a given KLOC. ✅ Identify 5 common estimation pitfalls and fixes. ✅ Relate estimation to real-world Nepalese projects (e.g., Daraz, Ncell).

Summary Table: Key Techniques at a Glance

Final Thought: Why This Matters in Nepal

Software effort estimation is not just academic—it directly impacts:

• Your job: Will you deliver on time? Will you get promoted?
• Nepal’s economy: Will eSewa/Khalti succeed? Will Ncell’s 5G launch on schedule?
• Your projects: Will your startup’s MVP launch on time?

Remember: The best estimators combine data with experience—just like how Nepal’s best trekking guides use maps (data) + local knowledge (experience) to plan routes.