Cost Estimation

Problems in Software Estimation

Software estimation is the process of predicting effort, cost, time, resources, and size
required for a software project. Because software projects involve uncertainty and changing
requirements, estimation often faces many problems.

Major Problems in Software Estimation

1. Unclear or Incomplete Requirements

 Requirements may not be fully defined at the start.

 Clients may not clearly express their needs.
 Missing requirements lead to incorrect estimates.

Problem:
If scope is unclear, effort and cost estimates become unreliable.

2. Frequent Requirement Changes (Scope Creep)

 Requirements often change during development.

 New features may be added after estimation.

Effect:

 Cost overruns
 Schedule delays
 Re-estimation becomes necessary

3. Difficulty in Measuring Software Size

Estimating software size is difficult using:

 LOC (Lines of Code)

 Function Points
 Use Case Points

Problems:

 Early stages may not provide enough detail.

 Size estimates may be inaccurate.

Since effort depends heavily on size, errors propagate.

4. Lack of Historical Data

Good estimates often need past project data.

Problem:

 New organizations may have no historical metrics.

 Past data may be inconsistent or unavailable.

Result:

 Estimates rely on guesswork.

5. Human Judgment Errors

Expert-based estimates may suffer from:

 Optimism bias
 Overconfidence
 Underestimation
 Subjective judgment

This often causes unrealistic commitments.

6. Inaccurate Productivity Assumptions

Estimations often assume a certain productivity level.

Problem:
  Actual developer productivity varies.
 Team skill differences affect effort.

This can distort estimates.

7. Technical Uncertainty

New technology, tools, or unfamiliar domains create uncertainty.

Examples:

 New programming language

 New framework
 Research-oriented projects

Problem:
Difficult to predict effort accurately.

8. Risk and Uncertainty

Unexpected risks affect estimates:

 Technical risks
 Resource risks
 Schedule risks

Failure to consider risk causes estimation errors.

9. Ignoring Non-Development Activities

Estimates sometimes omit:

 Testing
 Reviews
 Documentation
 Maintenance
 Meetings
 Rework

Result:
Underestimation.
10. Poor Cost Driver Assessment

Models like COCOMO depend on cost drivers.

Incorrect rating of factors like:

 Complexity
 Reliability
 Personnel capability

leads to wrong estimates.

11. People-Related Factors

Human factors are hard to estimate:

 Skill levels
 Experience
 Team turnover
 Communication issues

These strongly affect effort.

12. Novelty of Project

If project is unprecedented:

 No reference data
 Unknown complexity
 Harder prediction

Estimation becomes risky.

13. Pressure for Unrealistic Estimates

Sometimes management or clients force:

 Lower budgets
 Shorter deadlines

This causes politically driven estimates instead of realistic ones.

14. Changing Productivity During Project

Productivity may vary because of:

 Learning curves
 Fatigue
 Team changes
 Tool issues

Static estimates may become invalid.

15. Complexity of Software

Large systems have:

 Many modules
 Interdependencies
 Integration challenges

Complexity is difficult to estimate precisely.

Common Estimation Errors

a) Underestimation

Estimated values are too low.

Causes:

 Optimism
 Ignored risks
 Missing tasks

Effect:

 Budget overrun
 Delays

b) Overestimation

Estimate too high.

Effects:
  Resource waste
 Higher costs
 Reduced competitiveness

Fundamental Problems in Software Estimation

Three classic problems:

1. Size Estimation Problem

How large is the software?
2. Effort Estimation Problem
How much work is required?
3. Schedule Estimation Problem
How long will it take?

Errors in one affect the others.

Why Software Estimation is Difficult

Software is:

 Intangible
 Complex
 Dynamic
 People-intensive
 Uncertain

Unlike physical engineering, software often changes during construction.

Ways to Reduce Estimation Problems

 Better requirement analysis
 Use historical data
 Apply models (COCOMO, FPA)
 Include risk buffers
 Use expert judgment + models together
 Re-estimate periodically
 Use decomposition (WBS)
 Review assumptions regularly
Algorithmic Cost Estimation
Function Points
Function Point Estimation Analysis
Notes(For Exam Points)
Function Point Analysis (FPA) Model
Function Point Analysis (FPA) is a software size estimation technique used to measure
the functionality delivered by a software system from the user’s point of view. It estimates
the size, effort, cost, and productivity of software independent of programming language.

It was developed by Allan Albrecht (IBM).

Definition
Function Point Analysis is a technique for measuring software size by quantifying the
functions the system performs for users based on:

 Inputs
 Outputs
 Inquiries
 Files
 Interfaces

Unlike LOC (Lines of Code), FPA measures what software does, not how it is coded.

Objectives of FPA
It is used for:

 Software size estimation

 Cost estimation
 Effort estimation
 Productivity measurement
 Project planning
 Comparing projects

Basic Idea
Software is viewed as a collection of functions provided to users.

Size is measured in Function Points (FP).

Two major steps:

1. Calculate Unadjusted Function Points (UFP)

2. Adjust them using complexity factors to get Adjusted Function Points (AFP)

Step 1: Unadjusted Function Points (UFP)

Five components are counted.

1. External Inputs (EI)

User inputs entering the system.

Examples:

 Login forms
 Data entry screens
 Registration forms

2. External Outputs (EO)

Reports or outputs produced.

Examples:

 Salary slips
 Reports
 Invoices

3. External Inquiries (EQ)

Interactive queries involving input and output.

Examples:

 Search operations
 Account balance inquiry

4. Internal Logical Files (ILF)

Logical data maintained inside the system.

Examples:

 Employee database
 Customer records

5. External Interface Files (EIF)

Files used but maintained by other systems.
Examples:

 Third-party databases
 External inventory files

Standard Weights
Each component has weights based on complexity.

Component Simple Average Complex

EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10

Formula for UFP

UFP = ∑ (Count × Weight)

Compute weighted sum of all components.

Example of UFP Calculation

Suppose:
 10 Inputs (Average) → 10×4 = 40
 8 Outputs (Complex) → 8×7 = 56
 5 Queries (Simple) → 5×3 =15
 4 ILFs (Average) → 4×10=40
 2 EIFs (Simple) → 2×5=10
UFP:
40 + 56 + 15 + 40 + 10 = 161
Step 2: Value Adjustment Factor (VAF)
There are 14 General System Characteristics (GSCs).

Each rated 0–5.

GSC Factors
1. Data communications
2. Distributed processing
3. Performance
4. Heavily used configuration
5. Transaction rate
6. Online data entry
7. End-user efficiency
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitate change

Total Degree of Influence

TDI=∑GSC
Range:

Minimum = 0
Maximum = 70

Value Adjustment Factor

VAF= 0.65 + 0.01(TDI)

Adjusted Function Points (AFP) or Function Points (FP)

FP = UFP × VAF
Example

Suppose:
UFP = 161
DI = 35
Then:
VAF=0.65+0.01(35)=1.00
Adjusted FP:
FP = 161 × 1 = 161

Effort Estimation using FP

Once FP is known:
Effort = FP × Productivity Factor

Example:
If 1 FP = 5 person-hours

Effort:
161 × 5 = 805 person-hours

Conversion to LOC

Function points can be converted to lines of code:

LOC= FP × Language Factor

Example:
For Java
1 FP ≈ 50 LOC

161 × 50 = 8050 LOC

COCOMO Models (Basic, Intermediate
and Complete COCOMO)
Note: COCOMO Model is not mentioned in your Syllabus. Study it for
understanding of COCOMO II

COCOMO (Constructive Cost Model) was developed by Barry Boehm (1981) for
estimating software effort, development time, staffing, and cost.

COCOMO has three major models:

1. Basic COCOMO
2. Intermediate COCOMO
3. Complete (Detailed) COCOMO

1. Basic COCOMO Model

Definition
Basic COCOMO estimates software effort and development time based only on:

 Size of software (KLOC)

 Nature of project

It is a simple, preliminary estimation model.

Project Categories in Basic COCOMO

(a) Organic Mode

Small, simple projects with experienced teams.

Examples:

 Payroll system
 Inventory management

Characteristics:
  Familiar problem
 Flexible requirements
 Small team

(b) Semi-Detached Mode

Medium-size projects with mixed complexity.

Examples:

 Database systems
 Compilers

Characteristics:

 Moderate complexity
 Mixed experience team

(c) Embedded Mode

Large and complex projects with strict constraints.

Examples:

 Air traffic control

 Real-time operating systems

Characteristics:

 Tight hardware/software constraints

 High complexity
Effort Estimation Formula
Effort = a (KLOC) b
Effort in Person-Months.

Mode a b
Organic 2.4 1.05
Semi-Detached 3.0 1.12
Embedded 3.6 1.20

Development Time Formula

TDEV = c (Effort) d
Mode c d
Organic 2.5 0.38
Semi-Detached 2.5 0.35
Embedded 2.5 0.32

Personnel Required
People = TDEV / Effort

Example (Basic COCOMO)

Suppose: 50 KLOC and Organic project

Effort=2.4(50)1.05
Estimated effort ≈ 145 Person-Months

Limitations
Basic COCOMO only considers size and ignores many real factors.
2. Intermediate COCOMO
Definition
Intermediate COCOMO improves Basic COCOMO by considering:

 Software size
 Project type
 Cost drivers (Effort Adjustment Factor)

Effort Formula
b
Effort= a (KLOC) × EAF

Where:

 EAF = Effort Adjustment Factor

Mode a b
Organic 3.2 1.05
Semi-Detached 3.0 1.12
Embedded 2.8 1.20

Cost Drivers (15 Drivers)

Product Attributes

 Required reliability
 Database size
 Product complexity

Hardware Attributes

 Runtime constraints
 Memory constraints
 Platform volatility
Personnel Attributes

 Analyst capability
 Programmer capability
 Experience

Project Attributes

 Software tools
 Schedule constraints

Effort Adjustment Factor (EAF)

EAF = ∏ EMi
Product of all effort multipliers.

Development Time
Same schedule formula:

TDEV = c (Effort) d
Features
 More realistic than Basic model
 Includes environmental factors
 Better estimation accuracy

3. Complete (Detailed) COCOMO Model

Definition
Complete COCOMO is the most advanced version.

It extends Intermediate COCOMO by:

 Using all cost drivers

 Considering each development phase separately
  Phase-wise effort distribution

Phases Considered
Effort estimated separately for:

1. Requirements analysis
2. System design
3. Detailed design
4. Coding
5. Testing
6. Integration

Formula
Overall effort:

Effort= a (KLOC) b × EAF

But effort is distributed phase-wise.

Phase-wise Allocation Example

Effort may be distributed as:

 Requirements → 10%
 Design → 20%
 Coding → 35%
 Testing → 25%
 Integration →10%

Features
 Most detailed
 Highest accuracy
 Phase-sensitive estimation
 Suitable for large critical projects
COCOMO II
Sub Models of COCOMO II
Note: You can skip Reuse Model
COCMO II Concise Notes (for Exam
Points)
COCOMO II (Constructive Cost Model II) is a software cost estimation model used to
estimate the effort (person-months), development time, staffing, and cost required to
develop software systems. It was developed by Barry Boehm as an improved version of
COCOMO (1981) to suit modern software development practices like reuse, prototyping,
object-oriented development, and iterative models.

Definition
COCOMO II is an algorithmic model that estimates software development effort and
schedule based on:

 Size of software (usually in KLOC or Function Points)

 Cost drivers (product, platform, personnel, project factors)
 Scale factors (factors affecting economies/diseconomies of scale)

Objectives of COCOMO II
It helps in:

 Estimating development effort

 Predicting schedule (time)
 Estimating project cost
 Resource planning
 Risk analysis
 Project management and control

Basic Effort Estimation Formula

COCOMO II estimates effort using:

PM = A × (Size) E × ∏ EMi
Where

 PM = Effort in Person-Months
 A = Constant (usually 2.94)
 Size = Software size in KLOC (Thousands of Lines of Code)
 E = Exponent reflecting scale factors
 EMᵢ = Effort Multipliers (cost drivers)
 Exponent Formula

E = B + 0.01 ∑ SFi
Where:

 B = 0.91
 SFᵢ = Five Scale Factors

Scale Factors (SF)

These determine whether a project has economies or diseconomies of scale.

1. PREC (Precedentedness)
o Similarity with past projects.
2. FLEX (Development Flexibility)
o Degree of process flexibility.
3. RESL (Architecture / Risk Resolution)
o Risk analysis and architecture maturity.
4. TEAM (Team Cohesion)
o Communication and cooperation among team.
5. PMAT (Process Maturity)
o Organizational process maturity.

Higher scale factors generally increase effort.

Effort Multipliers (Cost Drivers)

These adjust effort based on project conditions.

1. Product Factors
 Required reliability (RELY)
 Database size (DATA)
 Product complexity (CPLX)
 Required reusability (RUSE)
 Documentation needs (DOCU)

2. Platform Factors
  Execution time constraints (TIME)
 Storage constraints (STOR)
 Platform volatility (PVOL)

3. Personnel Factors
 Analyst capability (ACAP)
 Programmer capability (PCAP)
 Experience (AEXP, PEXP)
 Language/tool experience (LTEX)
 Personnel continuity (PCON)

4. Project Factors
 Use of tools (TOOL)
 Multisite development (SITE)
 Schedule compression (SCED)

Schedule Estimation Formula

Development time:

TDEV = C × (PM) F
Where:

 TDEV = Development time in months

 C = 3.67
 PM = Person-months
 F = 0.28 + 0.2(E-0.91)

Cost Estimation
Project Cost:

Cost = Effort × Cost per Person-Month

Example:
If effort = 100 PM
Cost per PM = ₹50,000

Cost = 100 × 50,000 = ₹50,00,000

Three Sub-Models of COCOMO II
1. Application Composition Model
Used for:

 Prototyping
 GUI-based applications
 Rapid application development

Uses Object Points instead of LOC

Formula:

Productivity
Effort =
Object Points

Object points include:

 Screens
 Reports
 3GL components

2. Early Design Model

Used in early stages when requirements are rough.

Uses:

 Unadjusted Function Points or KLOC

 7 aggregated cost drivers

Effort formula same as general COCOMO II:

PM = A × (Size) E × ∏ EMi
Suitable for:

 Feasibility studies
 Initial planning
 Architecture selection
3. Post-Architecture Model
Used after architecture is defined.

Most detailed model.

Uses:

 Full 17 effort multipliers

 5 scale factors
 Detailed schedule estimation

Suitable for:

 Detailed project planning

 Accurate cost estimation

Steps in Using COCOMO II

1. Estimate software size
2. Select scale factors
3. Determine effort multipliers
4. Compute effort
5. Estimate schedule
6. Estimate staffing and cost

Advantages of COCOMO II
 Realistic and systematic
 Suitable for modern software development
 Supports reuse and prototyping
 Helps budgeting and scheduling
 Useful for risk management
 Widely accepted in software engineering

Limitations
 Accuracy depends on size estimation
 Difficult for very small agile projects
 Requires proper cost driver assessment
 Can be complex to apply
Example (Simple)
Suppose:

 Size = 50 KLOC
 A = 2.94
 E = 1.1
 Product of EM = 1.2

Effort:

PM=2.94 (50)1.1 (1.2)

Estimated effort ≈ 218 Person-Months.

SLIM (Software Life Cycle Management)

Model for Cost Estimation
SLIM (Software Life Cycle Management) is a software cost estimation model developed
by Larry Putnam. It is also known as the Putnam Model.

It is used to estimate:

 Software development effort

 Development time
 Staffing levels
 Cost of software projects

SLIM is based on mathematical modeling and the Rayleigh manpower distribution curve.

Definition
SLIM is an algorithmic software estimation model that predicts effort, schedule, and cost
based on the relationship among:

 Software size
 Productivity
 Effort
 Development time

It models how manpower changes over the software life cycle.

Basic Idea of SLIM
SLIM assumes staffing follows a Rayleigh curve:

 Few people at project start

 Team grows during development
 Peaks in middle
 Decreases during testing and completion

This reflects real project behavior.

Rayleigh Curve Concept

Manpower usage:

 Requirements → low staffing

 Design/Coding → peak staffing
 Testing/Deployment → declining staffing

This manpower pattern forms the Rayleigh curve.

3. Cost Estimation
Project Cost:

Cost = Effort × Cost per Person-Year

Technology Constant (Ck)

Ck reflects development capability.

Depends on:

 Tools used
 Team skills
  Methods
 Environment
 Process maturity

Higher Ck → Higher productivity.

Typical ranges:

 Poor environment → low Ck

 Good environment → high Ck

Inputs to SLIM
SLIM uses:

 Estimated software size

 Productivity index
 Development time constraints
 Staffing patterns

Outputs of SLIM
It estimates:

 Total effort
 Development schedule
 Staffing profile
 Total cost
 Productivity

Important Principle of SLIM

Trade-off Between Time and Effort
Reducing schedule often increases effort sharply.

SLIM shows:

Small reduction in schedule

→ Large increase in effort

This is a key management insight.

Steps in Using SLIM
1. Estimate software size
2. Determine technology constant
3. Apply software equation
4. Estimate effort
5. Estimate schedule
6. Compute cost

Features of SLIM Model

 Macro-level estimation model
 Based on empirical data
 Uses Rayleigh staffing curve
 Captures effort-schedule tradeoff
 Suitable for large projects
Advantages
1. Realistic Staffing Pattern
Models actual manpower behavior.

2. Good for Large Projects

Works well for large systems.

3. Considers Productivity
Includes technology constant.

4. Supports Cost and Schedule Trade-offs

Useful for management decisions.

5. Scientific Model
Uses mathematical relationships.

Limitations
1. Difficult for Small Projects
Less suitable for small projects.

2. Requires Accurate Size Estimate

Errors in LOC affect results.

3. Complex to Apply
More difficult than COCOMO.

4. Needs Historical Data

Technology constant may be hard to determine.
Applications of SLIM
Used for:

 Large software project estimation

 Defense projects
 System software
 Project planning
 Resource allocation
 Estimating of Web Application
Development
Web application estimation is the process of predicting the size, effort, time, resources,
and cost required to develop a web application.

Because web applications often involve rapidly changing requirements, user interfaces,
databases, integrations, and performance concerns, estimation is an important but challenging
activity.

Factors Affecting Web Application Estimation

Web application effort depends on many factors:

1. Scope and Requirements

Estimate based on:

 Number of features
 Functional requirements
 Non-functional requirements
 Complexity of business logic

Examples:

 Simple informational website → Low effort

 E-commerce platform → High effort

2. Application Size
Size may be estimated using:

 Function Points (FP)

 Use Case Points (UCP)
 Lines of Code (LOC)
 Story Points (Agile)

Larger size generally means higher effort.

3. Front-End Complexity
Depends on:

 Number of pages/screens
 UI/UX complexity
 Responsive design
 Dynamic interfaces
 JavaScript frameworks (React, Angular, etc.)

More complex interfaces increase effort.

4. Back-End Complexity
Includes:

 Business logic
 APIs
 Authentication
 Database operations
 Server-side processing

Complex back-end means more development time.

5. Database Complexity
Estimation depends on:

 Number of tables
 Relationships
 Data volume
 Transactions
 Query complexity

6. Integration Requirements
Effort increases with integration of:

 Payment gateways
 Third-party APIs
 Cloud services
 Social login
  External systems

7. Non-Functional Requirements
Includes:

 Security
 Performance
 Scalability
 Reliability
 Availability

These often add significant effort.

Methods for Estimating Web Applications

1. Expert Judgment
Estimation based on experienced developers.

Uses:

 Experience
 Similar projects
 Historical data

Simple but subjective.

2. Function Point Analysis

Estimate system functionality through:

 Inputs
 Outputs
 Files
 Interfaces

Can be used for web projects.

3. Use Case Point Method
Based on:

 Number of use cases

 Actors
 Technical complexity

Popular for web systems.

Effort Components in Web Development
Estimation
Estimate effort for each activity:

Development Effort
 Front-end coding
 Back-end coding
 Database development

Testing Effort
 Unit testing
 Integration testing
 Security testing
 Performance testing

Design Effort
 UI/UX design
 Wireframes
 Prototyping

Deployment Effort
 Hosting setup
 Configuration
 DevOps activities

Maintenance Effort
 Bug fixing
 Updates
 Enhancements
Web Application Cost Estimation Formula
Effort
Effort = Size × Productivity

Cost
Cost:

Cost = Effort × Cost per Person-Month

Example Estimation Approach

Suppose web project includes:

 20 web pages
 User authentication
 Product catalog
 Payment gateway
 Admin dashboard

Estimated efforts: Given as Follows

Task Person-Months
UI Design 2
Frontend 4
Backend 5
Database 2
Testing 3
Total Effort:
2 + 4 + 5 + 2 + 3 = 16 PM
If cost per PM = ₹60,000
Cost:
16 × 60,000 = ₹9,60,000
Common Parameters Used in Web
Estimation
Consider:

 Number of pages
 Number of forms
 APIs required
 Database entities
 Security requirements
 Performance requirements
 User roles
 Integrations
 Reusable component

Challenges in Web Application Estimation

1. Changing Requirements
Web projects often evolve rapidly.

2. Technology Changes
Frameworks and tools change.

3. UI Uncertainty
Front-end effort often underestimated.

4. Integration Complexity
Third-party dependencies add uncertainty.

5. Scope Creep
Common in web projects.

Techniques to Improve Accuracy

 Break project into modules (WBS)
 Use historical data
  Use prototype-based estimation
 Include risk buffers
 Re-estimate iteratively
 Combine expert judgment with models

Special Models for Web Estimation

Some web-specific approaches include:

 WebMo model
 OO estimation models
 Use Case Point models
 Agile velocity estimation