1

Software Size Estimations

Based on

Software Requirements

By
Khaqan Zaheer
Agenda 2

- Background
- Effort Estimation Process
- Estimation Issues and solutions
- Types of estimation methods
- COCOMO Model
- IFPUG Method
- Summary
Background 3
Software Size
 No of requirements
 Source Lines of Code
 Function Points
 Object Points
 Software development Effort
 Product Characteristics
 Production Resources
 Organizational Characteristics
 Development Time
 Software Development Cost
 Background
4

Characterize Predict

Processes,
Products &
Resources

Evaluate Improve
 5
Background

Classical View Of Software Estimation Process [Vidger/Kark]

Effort Estimation Process 6

 Determine Objectives
 Who needs what data for what purpose(s)
 Gather Data
 Well-Defined Requirements
 Focus Should Be Given To ‘Hard’ Data
 Analyze Data Using A Variety Of Methods
 Re-estimate Costs Throughout The Project
 Refine and Make Changes As Necessary
 Effective Monitoring i.e., Planned Vs Actual
 Compare End Costs With Estimated Costs
 Project Postmortem Analysis
Issues and Problems 7

 Inaccurate Estimation Models, Methods, and Tools

 Duration, Size, and Number of People Involved
 New/Mixed Technology
 Inexperienced Project Managers and Estimators
 IneffectiveManagement of Requirements
 Software Process Maturity
 Lack of Historical Data
 8
Solution for better Estimates

 A Combination Of Models, Methods, and Tools

 Gathering/Improving of Historical Data
 Well-defined and Well-controlled Software Development
Processes
 Better Managing of Requirements
 Experienced Project Managers, Estimators, and Team
Members
 9

Types of Estimation Methods

 Expert Judgment Method 10

Expert judgment techniques involve consulting with

software cost estimation experts to use their experience and
understanding of the proposed project to arrive at an
estimate of its cost.
Technique: Delphi technique, a group consensus technique.

 Advantages: Empirical
 Disadvantages: Subjective
Estimating by Analogy 11

Estimating by analogy means comparing the proposed

project to previously completed similar project where
the project development information is known.

 Advantages: Based on actual experience of projects

 Disadvantages: Difficult to ensure the degree of
representative between previous projects and new
one
Top-Down Estimating Method 12

 It is also called Macro Model

 System level architecture
 Work break down structure
 Modularization

 Size estimation is derived from the global properties of the software project,
and then the project is partitioned into various low-level components.

 Advantages: Efficient and system level view

 Disadvantages: Coarse Grained
Bottom-up Estimating Method 13

Bottom-up estimating method, the cost of each

software components is estimated and then
combines the results to arrive at an estimated
cost of overall project.

 Advantages: Detailed and stable

 Disadvantages: overlook many of the
system-level costs, inaccurate, more time-
consuming
Parkinson's Law 14

The project costs whatever resources are

available
Advantages: No overspend
Disadvantages: System is usually unfinished
Pricing to win 15

The project costs whatever the customer has to

spend on it
Advantages: You get the contract
Disadvantages: The probability that the
customer gets the system he or she wants is
small. Costs do not accurately reflect the work
required
Algorithmic Method 16

The algorithmic method is designed to provide some

mathematical equations to perform software estimation.
Models: COCOMO & COCOMO II, Putnam,
ESTIMACS and SPQR/20.
Disadvantages:
1.Unable to deal with exceptional conditions
2.Poor sizing inputs and inaccurate cost driver rating will
result in inaccurate estimation
Algorithmic Method (Cont’d) 17

Advantages:
1. Objective, repeatable
2. Has modifiable and analyzable formulas
3. Efficient and able to support sensitivity
analysis
The Selection and Use of Estimation
18
Methods
No one method is necessarily better or worse than the other, in
fact, their strengths and weaknesses are often complementary to
each other.
1.Do not depend on a single cost or schedule estimate, use several
techniques or cost models, compare the results
2.Document the assumptions made when making the estimates
3.Monitor the project to detect when assumptions that turn out to
be wrong jeopardize the accuracy of the estimate.
4.Improve software process
5.Maintaining a historical database
Commercial Tools of Cost Estimation
19
(Cont’d)
Some Promising Tools:

 ACEIT • Cost Xpert

 COCOMO II * • ESTIMATE Pro *
 Construx Estimate * • PRICE-S
 COSMOS * • SEER-SEM
 COSTAR * • SLIM-Estimate

*Most parametric models are likely to have the

COCOMO II equations at the core...
 20
The COCOMO Model

 Constructive Cost Model

 Modelto estimate the development cost and
schedule of a software project.
 Introduced by Barry Boehm.
 Primarilybased on the software development
practices prior to 1980s, i.e. based on the
Waterfall model.
The COCOMO Model 21

 Effort equation is the basis of the COCOMO model.

The nominal effort equation of a project of a given size is given

by the equation – PM(nominal) = A * (Size)B
PM(nominal) is the
nominal effort in person months
A is the multiplicative effect of cost drivers
B is the constant
representing the affect of scale factors
Types of Softwares 22

 Organic Mode - "small" teams with "good"

experience working with "less than rigid"
requirements
 Embedded Mode - need to operate within tight
constraints.
 Semidetached Mode - intermediate between the
organic and embedded modes.
COCOMO Model 23

 Effort=MM = a * KLOC b

 Duration=Time development = c * MM d

 People required (P) = Effort Applied / Development Time 

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

A Person-Month is one month of effort by one person. In the olden days,

a Person-Month would have been called a Man-Month or a Staff-Month.
In standard COCOMO, there are exactly 152 hours per Person-Month.
The COCOMO II Model 24

Has
three series of models:
The Early prototyping level
The Early Design Model
The Post-Architecture Model
Early prototyping level 25

 Supports prototyping projects and projects where there is

extensive reuse
 Based on standard estimates of developer productivity in
object points/month
 Takes CASE tool use into account
 Formula is
 PM = ( NOP  (1 - %reuse/100 ) ) / PROD

 PM is the effort in person-months, NOP is the number

of object points and PROD is the productivity
Object points 26

 Object points are an alternative function-related measure to

function points when 4Gls or similar languages are used for
development
 Object points are NOT the same as object classes
 The number of object points in a program is a weighted estimate
of
 The number of separate screens that are displayed
 The number of reports that are produced by the system
 The number of 3GL modules that must be developed to
supplement the 4GL code
Object point estimation 27

 Object points are easier to estimate from a

specification than function points as they
are simply concerned with screens, reports
and 3GL modules
 They can therefore be estimated at an early
point in the development process. At this
stage, it is very difficult to estimate the
number of lines of code in a system
Object point productivity 28
Early design level – 29

COCOMO-II
Estimates can be made after the requirements have been agreed
Basedon standard formula for algorithmic models
PM = A  SizeB  M + PM where
m

M = PERS  RCPX  RUSE  PDIF  PREX  FCIL  SCED

PM = (ASLOC  (AT/100)) / ATPROD
m

A = 2.5 in initial calibration, Size in KLOC, B varies from 1.1 to 1.24

depending on novelty of the project, development flexibility, risk management
approaches and the process maturity
PM reflects the amount of automatically generated code
m
ASLOC :Size of adapted components
AT is the percentage of code automatically generated.
ATPROD is Productivity of the engineer integrating the adapted code (app.
2400 source statements per month)
Multipliers 30

 Multipliers reflect the capability of the developers, the non-functional

requirements, the familiarity with the development platform, etc.
 RCPX - product reliability and complexity
 RUSE - the reuse required
 PDIF - platform difficulty
 PREX - personnel experience
 PERS - personnel capability
 SCED - required schedule
 FCIL - the team support facilities
Post-Architectural Model 31

 Effort = 2.94 * EAF * (KSLOC)E

Where
 EAF   Is the Effort Adjustment Factor derived from the Cost
Drivers
 EIs an exponent derived from the five Scale Drivers
 E= (sum of scale factors/100) + 1.01
Post Architectural model 32

 Cost Drivers are used in the model to adjust the

nominal effort in the software project
 Cost Drivers are multiplicative factors required to
determine the effort required to complete the software
project. Ratings range from VL, L, N, H, VH, EH
 Model has 17 cost drivers divided into 4 categories:
 Product
 Computer
 Personnel
 Project
The COCOMO II Model 33

 Cost drivers in the Product category:

 Required Software Reliability
 Database Size
 Software Product Complexity
control operations, computational operations,
device-dependent operations, data management
operations, and user interface management
operations.
 Required Reusability
 Documentation match to life-cycle needs
The COCOMO II Model 34

 Cost drivers in the Computer Category:

 Execution Time Constraint
 Main Storage Constraint
 Platform Volatility
The COCOMO II Model 35

 Cost drivers in Personnel Category:

 Analyst Capability
 Programmer Capability
 Applications Experience
 Platform Experience
 Language and Tool Experience
 Personnel Continuity
The COCOMO II Model 36

 Cost drivers in Project category:

 Use of Software Tools
 Multisite Development
 Required Development Schedule
Exponent scale factors 37

Scale factor Explanation

Precedentedness Reflects the previous experience of the organisation
with this type of project. Very low means no previous
experience, Extra high means that the organisation is
completely familiar with this application domain.
Development Reflects the degree of flexibility in the development
flexibility process. Very low means a prescribed process is used;
Extra high means that the client only sets general goals.
Architecture/risk Reflects the extent of risk analysis carried out. Very low
resolution means little analysis, Extra high means a complete a
thorough risk analysis.
Team cohesion Reflects how well the development team know each
other and work together. Very low means very difficult
interactions, Extra high means an integrated and
effective team with no communication problems.
Process maturity Reflects the process maturity of the organisation. The
computation of this value depends on the CMM
Maturity Questionnaire but an estimate can be achieved
by subtracting the CMM process maturity level from 5.
Scaling Factors 38

 cause an exponential cost increase

Cost Drivers Very Low Nom High Very Extra
Low High High
Precedentedness 5 4 3 2 1 0
(PREC)
Development flexibility 5 4 3 2 1 0
(FLEX)
Archictecture/risk 5 4 3 2 1 0
resolution (RESL)
Team cohesion 5 4 3 2 1 0
(TEAM)
Process Maturity 5 4 3 2 1 0
(PMAT)
 39
Effort Multipliers (Post-
Architecture)
 Product factors
Cost Drivers Very Low Nom High Very Extra
Low High High
Reliability (RELY) 0.75 0.88 1.00 1.15 1.39

Database size (DATA) 0.93 1.00 1.09 1.19

Complexity (CPLX) 0.75 0.88 1.00 1.15 1.30 1.66

Reusability (RUSE) 0.91 1.00 1.14 1.29 1.49

Documentation (DOCU) 0.89 0.95 1.00 1.06 1.13

Effort Multipliers (Post- 40

Architecture)
 Platform factors
Cost Drivers Very Low Nom High Very Extra
Low High High
Execution time 1.00 1.11 1.31 1.67
constraints (TIME)
Main storage 1.00 1.06 1.21 1.57
constraints (STOR)
Platform volatility 0.87 1.00 1.15 1.30
(PVOL)
Effort Multipliers (Post- 41

Architecture)
 Personnel factors

Cost Drivers Very Low Nom High Very Extra

Low High High
Analyst capability 1.50 1.22 1.00 0.83 0.67
(ACAP)
Programmer .. (PCAP) 1.37 1.16 1.00 0.87 0.74

Application experience 1.22 1.10 1.00 0.89 0.81

(APEX)
Platform .. (PLEX) 1.24 1.10 1.00 0.92 0.84

Language/tool ..(LTEX) 1.25 1.12 1.00 0.88 0.81

Personnel continuity 1.24 1.10 1.00 0.92 0.84

(PCON)
Effort Multipliers (Post- 42

Architecture)
 Project factors

Cost Drivers Very Low Nom High Very Extra

Low High High
Use of software tools 1.24 1.12 1.00 0.86 0.72
(TOOL)
Multi-site development 1.25 1.10 1.00 0.92 0.84 0.78
(SITE)
Required development 1.29 1.10 1.00 1.00 1.00
schedule (SCED)
Post-Architectural Model 43

 Effort = 2.94 * EAF * (KSLOC)E

Where
 EAF   Is the Effort Adjustment Factor derived from the Cost
Drivers
 EIs an exponent derived from the five Scale Drivers
 E= (sum of scale factors/100) + 1.01
 44
Functional Size Measurement
(FSM)

 International Function Point Users Group

(IFPUG) FP
 Common Software Measurement International
Consortium (COSMIC) FP
Applicability of FSM 45

Inputs for FSM :

Requirements definition artifacts
Data analysis / modeling artifacts
Artifacts from functional decomposition of requirements
Key Concept for FSM 46

Elementary Process: the smallest unit of activity that is

meaningful to the user(s)
E.g., FUR: “The user will be able to add a new employee to the
application.” is an Elementary Process.

The elementary process must be self-contained and leave the

business of the application being counted in a consistent state.

E.g.,If all the employee information is not added, an employee

has not yet been created. Adding some of the information alone
leaves the business of adding employee in an inconsistent state.
ISO 14143-1 Terminology for 47

FSM (I)
Functional User Requirements (FUR): A sub-set of the user
requirements. The FURs represent the user practices and procedures
that the software must perform to fulfill the users’ needs.

Function Points: It is a unit of measurement to express the amount of

business functionality, an information system (as a product) provides to a
user. FPs measure software size. They are widely accepted as an industry
standard for functional sizing.

Functional Size: A size of the software derived by quantifying the FUR.

 48

ISOBase

of FUR defined Terminology
14143-1 by and used by an for
Functional Component (BFC): An elementary unit
FSM Method for
measurement purposes.
FSM (II)
 BFC Type: A BFC is classified as one and only one BFC
Type.
Transaction Functions
 External Input
 External Output
 External Inquiry
Data Functions
 Internal Logical File
 External Interface File
ISO Approved FSM Methods 49

 IFPUG Function Point Analysis (ISO/IEC 20926)

 Mark II Function Point Analysis (ISO/IEC 20968)
 NESMA Functional Size Measurement Method
 (ISO/IEC 24570)
 COSMIC Function Points (ISO/IEC 19761)
IFPUG FPA Measurement 50

Procedure
1. Identify Elementary processes from the
Functional User Requirements
2. Identify the BFCs and their types.
3. Rate the complexity of each BFC Type.
4. Assign Function Points to each BFC Type
according to the complexity rates.
5. Calculate the functional size by summing the FPs
assigned to each distinct BFC Type.
IFPUG FPA – BFC Types 51

 Transaction Functions
 External Input
 External Output
 External Inquiry
 Data Functions
 Internal Logical File
 External Interface File
 52
Identify Transaction
Functions (I)
 External Input (EI): an Elementary Process that processes data or
control information that comes from outside the application’s
boundary.  
 The primary intent of an EI is to maintain one or more ILFs and/or to
alter the behavior of the system.
 E.g. “The user will be able to add a new employee to the application.”
Identify Transaction Functions 53

(II)
 External Output (EO): an elementary process that
sends data or control information outside the
application’s boundary.
 The primary intent of an external output is to present
information to a user through processing logic other than or in
addition to the retrieval of data or control information.
 The processing logic must contain at least one mathematical
formula or calculation, or create derived data. An external
output may also maintain one or more ILFs and/or alter the
behavior of the system.
 E.g. “The user will be able to calculate and report the monthly
salaries of all employees.”
 54
Identify Transaction
Functions (III)
 External Inquiry (EQ): an elementary process that sends data or control
information outside the application boundary.
 The primary intent of an external inquiry is to present information
to a user through the retrieval of data or control information. The
processing logic contains no mathematical formula or calculation,
and creates no derived data.
 No ILF is maintained during the processing, nor is the behavior of
the system altered.
 E.g. “The user will be able to retrieve the contact details of an
employee.”
Identify Data Functions (I) 55

 Internal Logical File (ILF): The groups of data or data entities

maintained (create, update, delete) by the Elementary processes
within the boundary of the application.
 E.g. Employee
Identify Data Functions (II) 56

 External Interface File (EIF): The groups of data or data

entities maintained (create, update, delete) by another
application and referenced by the Elementary processes
within the boundary of the application.
 E.g. Salary (Employee type, Gross Amount, Tax)
 57
Rate the Complexities of BFC Types
 Assign each identified EI, EO and EQ a functional
complexity based on the number of file types referenced
(FTRs) and data element types (DETs).
 A file types reference (FTR) is;
 An ILF read or maintained by a transactional function or
 An EIF read by a transactional function
 A DET is a unique user recognizable, non-repeated field
that enters or exits the application boundary and is required
to complete the transaction.
 E.g. Employee ID, Employee name, Employee
telephone number, etc.
 58
Rate the Complexity of Data
Functions
 Assign each identified ILF and EIF a functional
complexity based on the number of DETs and
record element types (RETs) associated with the
ILF or EIF.
 A DET is a unique user recognizable, non-
repeated field.
 E.g. Employee (ID, name, surname, address, type,
department)
 A RET is a user recognizable subgroup of data
elements within an ILF or EIF.
 E.g. Salaried employee, Hourly employee
 59
Complexity Weights for
Transaction
 External Input:
Functions

 External Output and External Inquiry:

 60
Function Points assignments for
BFC Types
 Function Points - Complexity weights for EI & EQ

  

  
 Function Points - Complexity weights for EO
 61
Function Points assignments for
Data Functions
 Complexity weights for ILF & EIF

 Function Points - Complexity weights for ILF

Function Points assignments for 62

Data Functions
 Function Points - Complexity weights for EIF
Calculate Functional Size

Prepare a FPUG Functional Size measurement 63

sheet which involves all the details of the
measurement.
IFPUG FPA – example 64

 A simple information system is required for a bank.

 It will enable new customers to be added and
deleted from a customer file.
 The system shall support paying in and withdrawal
transactions and display a warning message if the
borrower has an excessive overdraft
 Customers should be able to query their account
balance via a terminal.
 A report of overdrawn customers can be requested.
BFC Types 65

External input:
 add new customers
 delete customer
 Deposit transaction
 withdrawal transaction
Internal logical file
 customer file
External Inquiry:
 query account balance
External interface file:
 none

External outputs:
 display warning message of an excessive overdraft
 request a report of overdrawn customers
 66

Function-point assignments
References 67

Fenton, Norman, and James Bieman. Software metrics: a

rigorous and practical approach . CRC press, 2014.
Karl Wiegers, Joy Beatty 2013, Software Requirements: Best
practices, 3rd edn. Microsoft Press.
Longstreet, David. "Fundamentals of function point
analysis." Longstreet Consulting, Inc (2002).
Summary 68