Project Size Estimation Techniques

• Estimation of the size of software is an essential part of Software

Project Management.
• It helps the project manager to further predict the effort and
time which will be needed to build the project.

Various measures are used in project size estimation, Some of these are:
• Lines of Code
• Number of entities in ER diagram
• Total number of processes in detailed data flow diagram
• Function points
Lines of Code (LOC)

• Lines of Code (LOC) is a direct approach method and requires a higher

level of detail by means of decomposition and partitioning.

• From statement of software scope software is decomposed into problem

functions that can each be estimated individually.

• LOC count the total number of lines of source code in a project.

An Expected Value is then computed using the following formula.

Expected Value = [Sopt + 4* Sm + Spess]/6
where,
• EV stand for the estimation variable.
• Sopt stand for the optimistic estimate.
• Sm stands for the most likely estimate.
• Spess stand for the pessimistic estimate.
Lines of Code (LOC)

It is assumed that there is a very small probability that the actual size
results will fall outside the optimistic or pessimistic value.

Once the expected value for estimation variable has been determined,
historical LOC data are applied and person months, costs etc are calculated using
the following formula.
Size = KLOC
Effort = Person / Month
Productivity = KLOC / Person-month
Quality = Defects / KLOC
Cost = $ / LOC
Documentation = pages of documentation / KLOC

Where,
• KLOC stand for no. of lines of code (in thousands).
• Person-month stand for is the time(in months) taken by developers to finish
the product.
• Defects stand for Total Number of errors discovered
Advantages:
• Universally accepted and is used in many models like COCOMO.
• Estimation is closer to developer’s perspective.
• Simple to use.

Disadvantages:
• Different programming languages contains different number of lines.
• No proper industry standard exist for this technique.
• It is difficult to estimate the size using this technique in early stages of
project.
Example:

Problem Statement:
Take the Library management system case. Software developed for
library will accept data from operator for issuing and returning books.
Issuing and returning will require some validity checks. For issue it is
required to check if the member has already issued the maximum books allowed.
In case for return, if the member is returning the book after the due
date then fine has to be calculated.
All the interactions will be through user interface. Other operations
include maintaining database and generating reports at regular intervals.

Major software functions identified.

• User interface
• Database management
• Report generation
For user interface Expected Value = [Sopt + 4* Sm + Spess]/6
Sopt : 1800
Sm : 2000
Spess : 4000
EV for user interface
EV = (1800 + 4*2000 + 4000) / 6
EV = 2300
For database management
Sopt : 4600
Sm : 6900
Spess : 8600
EV for database management
EV = (4600 + 4*6900 + 8600) / 6
EV = 6800
For report generation
Sopt : 1200
Sm : 1600
Spess : 3200
EV for report generation
EV = (1200 + 4*1600 + 3200) / 6
EV = 1800
Example 1: LOC Approach
• A system is composed of 7 subsystems as below.
• Given for each subsystem the size in LOC and the
2 metrics: productivity=LOC/pm (pm: person-month) ,Cost=$/LOC
• Calculate the system total cost in $ and effort in months .

Software Engineering SW Cost Estimation Slide 7

Example 1: LOC Approach
Functions estimated LOC LOC/pm $/LOC Cost Effort (months)

UICF 2340 315 14 32,000 7.4

2DGA 5380 220 20 107,000 24.4

3DGA 6800 220 20 136,000 30.9

DSM 3350 240 18 60,000 13.9

CGDF 4950 200 22 109,000 24.7

PCF 2140 140 28 60,000 15.2

DAM 8400 300 18 151,000 28.0

Totals 33,360 655,000 145.0

Efforts (Months) = Estimated LOC / (LOC/pm)

Cost = (LOC/pm) * ($/LOC) * Efforts (Months)
Burdened Labour Rate = $/p-m

Software Engineering SW Cost Estimation Slide 8

Example 2: LOC Approach

Software Engineering SW Cost Estimation Slide 9

Example 2: LOC Approach
Assuming
 Estimated project LOC = 33200
 Organisational productivity (similar project type) = 620
LOC/p-m
 Burdened labour rate = 8000 $/p-m

Then
 Effort = 33200/620 = (53.6) = 54 p-m
 Cost per LOC = 8000/620 = (12.9) = 13 $/LOC
 Project total Cost = 8000 * 54 = 432000 $

Software Engineering SW Cost Estimation Slide 10

Function Points: FP
Function Points is used in 2 contexts:

 Past: To develop metrics from historical data

 Future: Use of available metrics to size the s/w of

a new project

Software Engineering SW Cost Estimation Slide 11

Function Points
 Based on a combination of program characteristics
 The number of :
External (user) inputs: input transactions that update internal files
External (user) outputs: reports, error messages
User interactions: inquiries
Logical internal files used by the system:
Example a purchase order logical file composed of 2 physical
files/tables Purchase_Order and Purchase_Order_Item
External interfaces: files shared with other systems

 A weight (ranging from 3 for simple to 15 for complex

features) is associated with each of these above
 The function point count is computed by multiplying each
raw count by the weight and summing all values
Software Engineering SW Cost Estimation Slide 12
Function Points - Calculation
weighting factor
measurement parameter count simple avg. complex
number of user inputs X 3 4 6 =
number of user outputs X 4 5 7 =
number of user inquiries X 3 4 6 =
number of files X 7 10 15 =
number of ext.interfaces X 5 7 10 =
count-total
complexity multiplier
function points

Software Engineering SW Cost Estimation Slide 13

Function Points – Taking Complexity
into Account -14 Factors Fi
Each factor is rated on a scale of:
Zero: not important or not applicable
Five: absolutely essential

1. Backup and recovery

2. Data communication
3. Distributed processing functions
4. Is performance critical?
5. Existing operating environment
6. On-line data entry
7. Input transaction built over multiple screens
Software Engineering SW Cost Estimation Slide 14
Function Points – Taking Complexity
into Account -14 Factors Fi (cont.)
8. Master files updated on-line
9. Complexity of inputs, outputs, files, inquiries
10. Complexity of processing
11. Code design for re-use
12. Are conversion/installation included in design?
13. Multiple installations
14. Application designed to facilitate change by the
user

Software Engineering SW Cost Estimation Slide 15

 Function Points – Taking Complexity
into Account -14 Factors Fi (cont.)

i=14
FP = UFC * [ 0.65 + 0.01 * F ]
i
i=1

UFC: Unadjusted function point count

0 <= Fi <= 5

Software Engineering SW Cost Estimation Slide 16

FP: Advantages & Disadvantages
 Advantages
Available early .. We need only a detailed specification
Not restricted to code
Language independent
More accurate than LOC

 Disadvantages
Ignores quality issues of output
Subjective counting .. depend on the estimator
Hard to automate.. Automatic function-point counting is
impossible

Software Engineering SW Cost Estimation Slide 17

Function points and LOC
 FPs can be used to estimate LOC depending on
the average number of LOC per FP for a given
language
LOC = AVC * number of function points
AVC is a language-dependent factor varying from
approximately 300 for assemble language to 12-40 for a 4GL

Software Engineering SW Cost Estimation Slide 18

Relation Between FP & LOC
Programming Language LOC/FP (average)
Assembly language 320
C 128
COBOL 106
FORTRAN 106
Pascal 90
C++ 64
Ada 53
Visual Basic 32
Smalltalk 22
Power Builder (code generator) 16
SQL 12

Software Engineering SW Cost Estimation Slide 19

Function Points & Normalisation
 Function points are used to normalise measures (same as
for LOC) for:
S/w productivity
Quality

 Error (bugs) per FP (discovered at programming)

 Defects per FP (discovered after programming)
 $ per FP
 Pages of documentation per FP
 FP per person-month

Software Engineering SW Cost Estimation Slide 20

Example 1: FP Approach
Example 1: FP Approach (cont.) Complexity Factor
Example 1: FP Approach (cont.)
Assuming F = 52
i
i
FP = UFC * [ 0.65 + 0.01 * Fi ]
i

FP = 342 * 1.17 = 400

Complexity adjustment factor = 1.17
Example 4: FP Approach (cont.)
Assuming
• Estimated FP = 401
• Organisation average productivity (similar project type) = 6.5 FP/p-m
(person-month)
• Burdened labour rate = 8000 $/p-m

Then
• Estimated effort = 401/6.5 = (61.65) = 62 p-m
• Cost per FP = 8000/6.5 = 1231 $/FP
• Project cost = 8000 * 62 = 496000 $
Example 2:
Consider a project with the following functional units :
Number of user inputs = 50
Number of user outputs = 40
Number of user enquiries = 35
Number of user files = 06
Number of external interfaces = 04
Function Points

Advantages:
• It can be easily used in the early stages of project planning.
• It is independing on the programming language.
• It can be used to compare different projects even if they use different
technologies(database, langauge etc).

Disadvantages:
• It is not good for real time systems and embedded systems.
• Many cost estimation models like COCOMO uses LOC and hence FPC
must be converted to LOC.
Process Based Estimation
 Process Based Estimation
Activity Risk Construction
CC Planning Analysis Engineering Release CE Totals
Task analysis design code test

Function

UICF 0.50 2.50 0.40 5.00 n/a 8.40

2DGA 0.75 4.00 0.60 2.00 n/a 7.35
3DGA 0.50 4.00 1.00 3.00 n/a 8.50
CGDF 0.50 3.00 1.00 1.50 n/a 6.00
DSM 0.50 3.00 0.75 1.50 n/a 5.75
PCF 0.25 2.00 0.50 1.50 n/a 4.25
DAM 0.50 2.00 0.50 2.00 n/a 5.00

Totals 0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

% effort 1% 1% 1% 8% 45% 10% 36%

CC = customer communication CE = customer evaluation

Assuming
• Total Effort = 46
• For Instance we get the total for Task Design as 20.50,
20.50*100/46 = 44.5
• Burdened labour rate = 8000 $/p-m

Then
• Total Estimated Project = 46 p-m
• Total Project cost = 8000 * 46 = 368000 $
COCOMO Model
Person Estimation (Organic Mode) = E/D = 1295.31 P-M / 38.07 M
= 34 Persons