SOFTWARE EFFORT ESTIMATION

Chapter 1: Introduction to Software Estimation

1.1 What Makes a Successful Project?

A successful software project is one that delivers on all of the following dimensions:
• Agreed Functionality
• On Time
• At The Agreed Cost
• With The Required Quality

Project success follows two key stages:

• Set targets
• Attempt to achieve targets

1.2 Problems with Estimating

Estimation is inherently challenging due to several factors:
• Subjective nature of much of estimating — it may be difficult to produce evidence to
support your precise target
• Political pressures — managers may wish to reduce estimated costs in order to win
support for acceptance of a project proposal
• Changing technologies — these bring uncertainties, especially in the early days when
there is a 'learning curve'
• Projects differ — experience on one project may not be applicable to another

1.3 Basis for Successful Estimating

• Information about past projects — need to collect performance details about past
projects: how big were they? How much effort/time did they need?
• Need to be able to measure the amount of work involved
• Traditional size measurement for software is 'lines of code' — but this can have
problems

1.4 Estimation Issues

Estimation is critical for project planning, budgeting, and scheduling.
• Overestimation: predicting more effort, time, or cost than actually required
• Underestimation: predicting less effort, time, or cost than needed
• Both lead to inefficiencies, risks, and loss of stakeholder trust

Page 1
Problems with Overestimation
• Leads to resource underutilization (people, time, and budget sit idle)
• Increases project costs and timelines, reducing competitiveness
• Creates a false sense of security → teams may work at a slower pace
• May discourage stakeholders due to perceived high cost/time demands

Problems with Underestimation

• Causes project delays due to unrealistic timelines
• Leads to budget overruns as actual costs exceed estimates
• Increases stress on the development team, reducing quality and morale
• Risk of scope creep and failure to meet client expectations
• May damage the organization's reputation due to missed deadlines

1.5 A Taxonomy of Estimation Methods

• Bottom-up — activity based, analytical
• Parametric or algorithmic models e.g. function points
• Expert opinion — just guessing?
• Analogy — case-based, comparative
• Parkinson and 'price to win' (non-algorithmic approach where the cost of a project is
determined by available resources)

1.6 Parameters to be Estimated

Size is a fundamental measure of work. Based on the estimated size, two parameters are
estimated:
• Effort
• Duration

1.7 Measure of Work

The project size is a measure of the problem complexity in terms of the effort and time required
to develop the product. Two metrics are used to measure project size:
• Source Lines of Code (SLOC)
• Function Point (FP)

FP is nowadays favoured over SLOC because of the many shortcomings of SLOC (Source Lines
Of Code).

Source Lines of Code (SLOC)

SLOC is the most traditionally used metric for project sizing, and also the most controversial. Key
debates include:
• Count comments?
• Declaring variables?
• Efficient code vs. code bloat
• Language differences

Page 2
 • Easier to count afterwards than to estimate

Major Shortcomings of SLOC

• Difficult to estimate at start of a project
• Only a code measure
• Programmer-dependent
• Does not consider code complexity

1.8 Bottom-up versus Top-down

Bottom-up
• Use when no past project data is available
• Identify all tasks that have to be done — so quite time-consuming
• Use when you have no data about similar past projects
Steps:
• Break project into smaller and smaller components
• Stop when you get to what one person can do in one/two weeks
• Estimate costs for the lowest level activities
• At each higher level calculate estimate by adding estimates for lower levels

Top-down
• Produce overall estimate based on project cost drivers
• Based on past project data
• Divide overall estimate between jobs to be done

Page 3
Chapter 2: Estimation by Analogy
The use of analogy is also called case-based reasoning. The estimator seeks out projects that
have been completed (source cases) and that have similar characteristics to the new project (the
target case).

Where a similar, completed, project is identified and its actual effort is used as a basis for the new
project. The effort that has been recorded for the matching source case can then be used as a
base estimate for the target.

The estimator should then try to identify any differences between the target and the source and
make adjustments to the base estimate for the new project.

2.1 The ANGEL Tool

One software application that has been developed to support analogy-based estimation is
ANGEL. This tool:
• Identifies the source case that is nearest the target by measuring the Euclidean distance
between cases
• The source case that is at the shortest Euclidean distance from the target is deemed to
be the closest match

2.2 Euclidean Distance Formula

distance = sqrt((target_param1 - source_param1)^2 + ... +
(target_paramN - source_paramN)^2)

2.3 Example — Estimation by Analogy

Project B has 5 inputs and 10 outputs. Calculate the Euclidean distance between this project and
a target new project (with 7 inputs and 15 outputs):
ED = sqrt((7 - 5)^2 + (15 - 10)^2) = sqrt(4 + 25) =
sqrt(29) ≈ 5.39
If Project A had a closer Euclidean Distance, then Project A is therefore the closer analogy.

Page 4
Chapter 3: Albrecht / IFPUG Function Points
Function Point Analysis (FPA) was initially developed by Allan J. Albrecht in 1979 at IBM. It has
been further modified by the International Function Point User's Group (IFPUG) in 1984, to clarify
rules, establish standards, and encourage their use and evolution.

FPA gives a dimensionless number defined in function points which is an effective relative
measure of function value delivered to the customer. Function point metrics evaluate functionality
from the perspective of the user, based on the requests and responses they receive.

3.1 Five Function Types

1. External Inputs (EI)
Data entering the system (e.g., user forms, input screens).
• User login form (username/password)
• New customer registration form
• Online payment submission
• Uploading a file into the system

2. External Outputs (EO)

Data leaving the system with processing (e.g., reports, messages).
• Monthly sales report generation
• Invoice or receipt printing
• Email confirmation after order
• Alert/notification messages

3. External Inquiries (EQ)

User requests with input + output but no significant processing (e.g., search query).
• Checking account balance in online banking
• Product availability search in an e-commerce app
• Flight status lookup
• Employee directory search

4. Internal Logical Files (ILF)

Logical data maintained within the system (e.g., customer database).
• Customer records database
• Employee payroll file
• Inventory stock database
• Student academic records

5. External Interface Files (EIF)

Data used by the system but maintained by another system (e.g., shared reference files).
• Currency exchange rates from a central bank API
• Product catalog from a supplier system
• Weather information from a government service
• Hospital accessing lab test results from an external lab system

Page 5
3.2 Albrecht Complexity Multipliers

Low Medium High

Function Type
Complexity Complexity Complexity
External Inputs (EI) 3 4 6
External Outputs (EO) 4 5 7
External Inquiries (EQ) 3 4 6
Internal Logical Files (ILF) 7 10 15
External Interface Files (EIF) 5 7 10

3.3 Unadjusted Function Points (UFP) Formula

UFP = Σ (Number of Functions of Each Type × Weight)
Count each EI, EO, EQ, ILF, EIF, classify it (low/average/high), multiply by its weight, and sum
them all up.

3.4 Worked Example — Calculating UFP

Estimate the size of a software system using Albrecht's Function Point Analysis. The system has:
• 3 low, 2 medium, and 5 high External Inputs
• 5 low, 3 medium, and 1 high External Outputs
• 0 low, 3 medium, and 2 high External Queries
• 4 low, 0 medium, and 1 high Internal Logical Files
• 3 low, 1 medium, and 0 high External Interface Files

Function Type Low Medium High Total

External Inputs (EI) 3×3=9 2×4=8 5 × 6 = 30 47
External Outputs (EO) 5 × 4 = 20 3 × 5 = 15 1×7=7 42
External Queries (EQ) 0×3=0 3 × 4 = 12 2 × 6 = 12 24
Internal Logical Files (ILF) 4 × 7 = 28 0 × 10 = 0 1 × 15 = 15 43
External Interface Files (EIF) 3 × 5 = 15 1×7=7 0 × 10 = 0 22

UFP = 47 + 42 + 24 + 43 + 22 = 178

3.5 General System Characteristics (GSC)

There are 14 General System Characteristics, each rated on a Degree of Influence (DI) scale from
0 (No influence) to 5 (Essential):

# GSC Name DI Value Meaning

1 Data Communications 3 Average
2 Distributed Data Processing 2 Moderate

Page 6
 # GSC Name DI Value Meaning
3 Performance 4 Significant
4 Heavily Used Configuration 3 Average
5 Transaction Rate 3 Average
6 Online Data Entry 4 Significant
7 End User Efficiency 4 Significant
8 Online Update 3 Average
9 Complex Processing 3 Average
10 Reusability 2 Moderate
11 Installation Ease 3 Average
12 Operational Ease 3 Average
13 Multiple Sites 1 Incidental
14 Facilitate Change 2 Moderate

3.6 Total Adjusted Function Points (AFP)

TDI = Σ (DI of all 14 GSCs) = 40
VAF = (0.01 × TDI) + 0.65 = (0.01 × 40) + 0.65 = 1.05
AFP = UFP × VAF = 178 × 1.05 ≈ 187

3.7 Converting AFP to Effort

Effort (Person-Hours) = AFP × Productivity Rate

Project Type Productivity (Hours/FP)

Simple system 8 – 10
Medium system 10 – 15
Complex system 15 – 20

Example (Medium complexity): AFP = 187, Productivity = 10 hours/FP

Effort = 187 × 10 = 1870 person-hours
Converting to person-months (1 person-month = 160 hours):
Effort = 1870 / 160 = 11.7 person-months

3.8 Converting Effort to Development Time and Cost

Development Time (months) = Person-Months / Team Size
Example: Effort = 11.7 PM, Team size = 3 developers
Time = 11.7 / 3 = 3.9 ≈ 4 months

Page 7
 Cost = Person-Months × Cost per Person-Month
Example: Cost per developer = ₹60,000/month, Effort = 11.7 PM
Cost = 11.7 × 60,000 = ₹7,02,000 ≈ ₹7 lakhs

Page 8
Chapter 4: Function Point Mark II
Function Point Mark II is a software size estimation technique developed mainly for business
application systems. It measures software size based on functional user requirements,
independent of programming language or technology. It is an enhancement of the original
Function Point Analysis (FPA) and focuses more on data processing and transactions.

4.1 Mark II Components

Mark II measures size using three components only (simpler than IFPUG):

1. Input Data (ID)

Data entering the system — includes user inputs, data updates, or files received.

2. Output Data (OD)

Data leaving the system — reports, confirmations, displayed results.

3. Entity References (ER)

Logical data entities accessed (read or written) — tables, files, or data stores used by the
transaction.

4.2 Mark II Formula

Mark II FP = (0.58 × ID) + (1.66 × OD) + (0.26 × ER)
These weights reflect the relative processing effort.

4.3 Worked Example — Customer Registration

A 'Customer Registration' transaction:
• Input fields: Customer Name, Address, Phone Number → ID = 3
• Output fields: Customer ID, Confirmation Message → OD = 2
• Entity references: Customer Table → ER = 1

Mark II FP = (0.58 × 3) + (1.66 × 2) + (0.26 × 1)

= 1.74 + 3.32 + 0.26 = 5.32 Function Points

Converting to effort (Productivity = 10 FP/Person-Month):

Effort = 5.32 / 10 = 0.532 Person-Months

Cost estimation (Cost per PM = ₹50,000):

Cost = 0.532 × 50,000 = ₹26,600

Page 9
4.4 Why Mark II is Used
• Better suited for MIS & data-driven systems
• Simpler than traditional FPA
• Good for early project estimation
• Technology independent

4.5 IFPUG vs Mark II Comparison

Feature IFPUG FP Mark II FP

Components 5 types (EI, EO, EQ, ILF, EIF) 3 types (ID, OD, ER)
Focus Data + functionality Transactional processing

Page 10
Chapter 5: COCOMO I — Constructive Cost Model
The COCOMO model was developed by Barry W. Boehm in 1981 to estimate software
development effort, cost, and schedule based on project size. It mainly estimates:
• Effort (Person-Months)
• Development Time (Months)
• Cost

5.1 COCOMO Formulas

Effort (PM) = a × (KLOC)^b
Time (Months) = c × (Effort)^d
Where: KLOC = Thousands of Lines of Code; a, b, c, d = Constants depending on project type.

5.2 Project Categories

Mode Description Example

Organic Small, simple projects College project, payroll
system
Semi-detached Medium complexity Inventory system
Embedded Complex, real-time systems ATM, Air traffic system

5.3 Types of COCOMO

1. Basic COCOMO
Uses only Lines of Code; does NOT consider project factors. Simple and quick, used in early
estimation. Suitable for small academic projects and rough estimates.

Mode a b c d
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

2. Intermediate COCOMO
Adds Effort Adjustment Factor (EAF) to Basic COCOMO formula based on cost drivers.
Effort = a × (KLOC)^b × EAF
EAF depends on: product reliability, database size, programmer capability, hardware constraints,
project complexity, development environment. More accurate than Basic; considers 15 cost
drivers. Suitable for medium-scale commercial projects when team and project details are known.

3. Detailed (Complete) COCOMO

Extends Intermediate COCOMO by applying cost drivers to each development phase separately.
Phases considered: Requirements analysis, System design, Detailed design, Coding, Testing,
Maintenance.

Page 11
Very detailed with phase-wise effort distribution and highest accuracy. Complex calculations.
Suitable for large systems such as defense, banking, and embedded systems.

5.4 Basic COCOMO — Worked Example

Suppose: Project size = 32 KLOC, Mode = Organic

Step 1: Effort Calculation

Effort = 2.4 × (32)^1.05 = 2.4 × 38.05 ≈ 91.33 Person-
Months

Step 2: Development Time

Time = 2.5 × (91.33)^0.38 ≈ 2.5 × 5.56 ≈ 13.89 Months

Step 3: Team Size

Team Size = Effort / Time = 91.33 / 13.89 ≈ 6.6 → 6–7
people

Step 4: Cost Estimation

If cost per person per month = ₹50,000:
Total Cost = 91.33 × 50,000 = ₹45,66,500

5.5 Intermediate COCOMO — Worked Example

Semi-detached Project: KLOC = 50, Mode = Semi-detached, EAF = 1.2
(50)^1.12 ≈ 80
Effort = 3.0 × 80 × 1.2 = 287.84 PM
This shows how project factors increase effort significantly.

5.6 COCOMO Summary

Model Accuracy Complexity Usage

Basic Low Simple Early estimation
Intermediate Medium Moderate Practical projects
Detailed High Complex Large/critical systems

Page 12
Chapter 6: COCOMO II
COCOMO II (Constructive Cost Model II) is the updated version of COCOMO developed by Barry
W. Boehm to suit modern software development (OO, reuse, RAD, GUI, etc.). It provides better
estimation for:
• Object-oriented projects
• Component-based systems
• Agile / iterative development

6.1 COCOMO II Sub-Models

• Application Composition Model → Uses Object Points
• Early Design Model
• Post-Architecture Model
This chapter focuses on the Application Composition Model (Object Points).

6.2 What are Object Points?

Object Points measure software size based on:
• Screens (Forms / UI pages)
• Reports
• 3GL Components (Reusable modules)
Used mainly for GUI-based systems, RAD tools, and web applications.

6.3 Object Point Weights

Category Complexity Weight

Screens Simple 1
Screens Medium 2
Screens Difficult 3
Reports Simple 2
Reports Medium 5
Reports Difficult 8
3GL Components All 10 per component

6.4 Productivity Rates

Team Experience Productivity (OP per PM)

Low 4
Nominal 7
High 13

6.5 Step-by-Step Estimation Using Object Points

Page 13
 Step 1: OP = Σ (Number × Weight)
Step 2: NOP = OP × (1 - %Reuse/100)
Step 3: Effort (PM) = NOP / Productivity
Where NOP = New Object Points.

6.6 Worked Example

A software project has: 4 Simple Screens, 3 Medium Screens, 2 Difficult Screens, 2 Simple
Reports, 1 Difficult Report, 3 Reusable 3GL Components. Reuse = 20%, Team Productivity = 7
OP/PM (Nominal).

Step 1: Calculate Object Points

Screens: (4 × 1) + (3 × 2) + (2 × 3) = 4 + 6 + 6 = 16
Reports: (2 × 2) + (1 × 8) = 4 + 8 = 12
3GL Components: 3 × 10 = 30
Total OP = 16 + 12 + 30 = 58

Step 2: Adjust for Reuse

NOP = 58 × (1 - 0.20) = 58 × 0.8 = 46.4

Step 3: Effort Estimation

Effort = 46.4 / 7 = 6.63 Person-Months

Step 4: Cost
Cost per PM = ₹60,000
Total Cost = 6.63 × 60,000 = ₹3,97,800

6.7 Why Object Points are Important

• Suitable for GUI-based systems
• Works well when LOC is unknown
• Supports reuse
• Better for early prototyping

6.8 COCOMO I vs COCOMO II Comparison

Feature COCOMO I COCOMO II

Size Measure KLOC Object Points / FP /
KSLOC
Suitable For Traditional systems Modern OO systems

Page 14
Chapter 7: COSMIC Full Function Points
While approaches like that of IFPUG are suitable for information systems, they are not helpful
when it comes to sizing real-time or software embedded applications. This has resulted in the
development of another version of function points — the COSMIC FFP method.

The Full Function Point (FFP) method has its origins in the work of two interlinked research groups
in Québec, Canada. At the start, the developers were at pains to stress that this method should
be seen as simply an extension to the IFPUG method for real-time systems.

The original work of FFPs has been taken by the formation of the Common Software Measurement
Consortium (COSMIC).

Page 15
Chapter 8: Summary — Parametric Models
Comparison

Model Developed By Size Measure Best For

IFPUG FP Allan Albrecht / IFPUG Function Points (5 types) Information systems
Mark II FP Symons Function Points (3 types) MIS & data-driven
systems
COCOMO I Barry W. Boehm (1981) KLOC Traditional software
COCOMO II Barry W. Boehm Object Points / KSLOC Modern OO / GUI
systems
COSMIC FFP COSMIC Consortium Full Function Points Real-time & embedded
systems

Page 16