ISB1 103

Estimation Techniques
Organizations need to make software effort and cost
estimates.
There are two types of technique that can be used to do
this:
 Experience-based techniques
The estimate of future effort requirements is based on the
manager’s experience of past projects and the application domain.
Essentially, the manager makes an informed judgment of what the
effort requirements are likely to be.

 Algorithmic cost modeling

In this approach, a formula approach is used to compute the
project effort based on estimates of product attributes, such as size,
and process characteristics, such as experience of staff involved.
 Estimation Techniques:
Experience-based Approaches
 Experience-based techniques rely on judgments based on
experience of past projects and the effort expended in
these projects on software development activities.

 Typically, you identify the deliverables to be produced in a

project and the different software components or systems
that are to be developed.

 You document these in a spreadsheet, estimate them

individually and compute the total effort required.

 It usually helps to get a group of people involved in the

effort estimation and to ask each member of the group to
explain their estimate.
Categories of Software Projects
Estimation applies to three categories of software
projects:
 Organic projects
 Semi-detached projects
 Embedded projects
 Software Project Categories
 Organic
 In the organic mode, relatively small software teams
develop software in a highly familiar, in-house
environment. Most people connected with the project
have extensive experience in working with related
systems within the organization, and have a thorough
understanding of how the system under development
will contribute to the organizations objectives.
Software Project Categories (Cont’)
 Semidetached
 Medium teams with mixed experience working with a
mixture of the organic and embedded mode characteristics.

 Embedded
 The major distinguishing factor of an embedded-mode
software project is a need to operate within tight
constraints. The product must operate within (is embedded
in) a strongly coupled complex of hardware, software,
regulations, and operational procedures such as an electronic
funds transfer system or an air traffic control system.
 Estimation Techniques:
Algorithmic Cost Modeling

 COCOMO
 COCOMO II
 OBJECT POINT ORIENTED
 FUNCTION POINT ORIENTED
 ESTIMATION COST MODELLING
Why Cost Estimation?
 Cost Estimation is needed early for software pricing

Software price (S/W) =

Cost + Profit
Fundamental estimation question
 Effort
 How much effort is required to complete an activity?
 Units: man-day(person-day), man-week, man-month…
 Duration
 How much calendar time is needed to complete an
activity?
 Units: hour, day, week, month, year
 Cost of an activity?
 What is the total cost of an activity?
 Project estimation and scheduling are interleaved
management activities
Software Cost Components
 Effort costs(dominant factor in most projects)
 Salaries
 Social insurance &benefits
 Tool costs: Hardware and software for development
 Depreciation on relatively small #of years
 Travel and Training costs (for particular client)
 Overheads(OH): Costs must take overheads into account
 Costs of building, air-conditioning, heating, lighting
 Costs of networking and communications
 Costs of shared facilities (eg library, staff, restaurant, etc)
 Depreciation costs of assets
Lines of Code(LOC)
Program length (LOC) can be used
to predict program characteristics
eg: person-month effort and ease of
maintenance
 The COCOMO Model
 An empirical model based on project experience.

 Well-documented, ‘independent’ model which is not tied

to a specific software vendor.

 Long history from initial version published in 1981

(COCOMO-81) through various instantiations to
COCOMO II.

 COCOMO II takes into account different approaches to

software development, reuse, etc.
 Basic COCOMO
Basic COCOMO is good for quick, early, rough order
of magnitude estimates of software costs
It does not account for differences in hardware
constraints, personnel quality and experience, use
of modern tools and techniques, and other project
attributes known to have a significant influence on
software costs, which limits its accuracy
Basic COCOMO Model: Formula
E = a b (KLOC or KDSI) b b
D = c b (E) d
b
P = E/D
where :
 E is the effort applied in person-months,
 D is the development time in chronological months,
 KLOC / KDSI is the estimated number of delivered lines of code for the
project (expressed in thousands),
 P is the number of people required.
The coefficients ab, bb, cb and db are given in next
slide.
COCOMO – to calculate development time

 Software Project

Category ab bb cb db
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
Basic COCOMOModel: Equation
Basic COCOMOModel: Example
 COCOMOII
COCOMO 81 was developed with the assumption that a
waterfall process would be used and that all software
would be developed from scratch.

Since its formulation, there have been many changes in

software engineering practice and COCOMO II is
designed to accommodate different approaches to
software development.
 COCOMO IIModels
 COCOMO II incorporates a range of sub-models that
produce increasingly detailed software estimates.

 The sub-models in COCOMO II are:

 Application composition model. Used when software is composed

from existing parts.
 Early design model. Used when requirements are available but
design has not yet started.
 Reuse model. Used to compute the effort of integrating reusable
components.
 Post-architecture model. Used once the system architecture has
been designed and more information about the system is available.
Use of COCOMO IIModels
COCOMOII
COCOMO II is a 3-levelmodel that allows increasingly
detailed estimates to be prepared as development
progresses
 Early prototyping level
 Estimates based on object-points and a simple formula is
used for effort estimation
 Early design level
 Estimates based on function-points that are then translated
to LOC
 Includes 7 cost drivers
 Post-architecture level
 Estimates based on lines of source code or function point
 Includes 17cost drivers
COCOMO II Early prototyping level:
Object-Points

 Suitable for projects built using modern GUI-builder tools

 Based on Object-Points
 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 (for 4GLs)
 Object-points are an alternative function-related measure
to function points when 4Glsor similar languages are used
for development
 Object-points are NOT the same as object classes
 The number of object-points in a program is considered as
a weighted estimate of 3 elements:
 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-Points –Weighting
Object Simple Medium Difficult
Type
Screen 1 2 3
Report 2 5 8
Each 3GL 10 10 10
module
Object-Points: Complexity Levels
 srvr: number of server data tables used with screen/report
 clnt: number of client data tables used with screen/report
Object-Point Estimation
 Object-points are easy to estimate
 simply concerned with screens, reports and 3GL
modules
 At an early point in the development process:
 Object-points can be early estimated
 It is very difficult to estimate the number of lines of code
in a system
Productivity Estimates
 LOC productivity
 Real-time embedded systems: 40-160 LOC/P-month
 Systems programs: 150-400 LOC/P-month
 Commercial applications: 200-800 LOC/P-month
 Object-points productivity: PROD
 measured 4 -50 object points/person-month
 depends on tool support and developer capability
Object Point Effort Estimation
 Effort in p/month = NOP / PROD
 NOP = number of OP of the system
 Example:
 An application contains 840 Object-points (NOP=840)
& Productivity is very high (= 50 object points/person-
month )
 Then, Effort = 840/50 = (16.8) = 17p-m
Adjustment for %of Reuse
% reuse: the % of screens, reports, & 3GLmodules
reused from previous applications, pro-rated by
degree of reuse
 Adjusted NOP= NOP * (1 -% reuse/ 100)
 Adjusted NOP: New NOP
 Example:
 Anapplication contains 840 OP, of which 20%can be
supplied by existing components.
Adjusted NOP= 840 * (1 –20/100) = 672 OP “New OP”
Adjusted effort= 672/50 = (13.4) = 14p-m
Object-Point Estimation Procedure
1. Assess object-counts in the system: number of screens,
reports, & 3GL.
2. Assess complexity level for each object (use table):
simple, medium and difficult.
3. Calculate “NOP” the object-point count of the system:
add all weights for all object instances
4. Estimate the % of reuse and compute the adjusted NOP
“New Object Points “to be developed
5. Determine the productivity rate PROD (use metrics
table)
6. Compute the adjusted effort PM = adjusted NOP / PROD
Object-Point Estimation Example
Assessment of a software system shows that:
The system includes
6 screens: 2 simple + 3 medium +1difficult
3 reports: 2 medium + 1difficult
2 3GL components
30 % of the objects could be supplied from previously
developed components
Productivity is high
Compute the estimated effort P-M ‘Person-months’
needed to develop the system
OPEstimation Example:Solution
Object counts:
2 simple screens x 1= 2
3 medium screens x2=6
1difficult screen x3= 3
2 medium reports x 5 = 10
1difficult report x8 =8
2 3GL components x 10 =20
NOP 49
OPEstimation Example:Solution
 Adjusted NOP ‘New NOP’ = NOP * (1 -% reuse/ 100)
= 49 * ( 1-(30/100))
= (34.3)
= 35
 For high productivity (metric table): PROD = 25 OP/P-M
 Estimated effort Person-Month = Adjusted NOP/ PROD
= 35/ 25
= 1.4P-M
Function Points (5 characteristics )
 Based on a combination of program 5 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
Function Points ( FP)Oriented
A weight is associated with each of the above 5
characteristics
Weight range:
from 3 for simple feature
to 15for complex feature
The function point count is computed by
multiplying each raw count by the weight and
summing all values
Function Points -Calculation
 14 Complexity Adjustment Factors
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational
environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be
built over multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?

39
14 Complexity Adjustment Factors (Cont’)
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the
design?
13. Is the system designed for multiple installations in
different organizations?
14. Is the application designed to facilitate change and
ease of use by the user?

40
Function Points (FP) 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
Relation Between FP& LOC
Software Information Domain Values

 Number of user inputs:

External i/o
 Number of user outputs:

 Number of user inquiries: User interaction

 Number of files:

 Number of external interfaces:

43
 Steps In Calculating FP
1.Count the information domain values.
2. Assess the complexity of the values.
3. Calculate the raw FP (see table 1-2).
4. Rate the complexity factors to produce the complexity
adjustment value (CAV)
5. Calculate the adjusted FP as follows:

44
 Function Point Metrics
Weighting Factor

Parameter Count Simple Average Complex

Inputs x3 4 6 =
Outputs x4 5 7 =
Inquiries x3 4 6 =
Files x7 10 15 =
Interfaces x5 7 10 =

Count-total (raw FP) =

Function Point Metrics Weighting Factor

45
Rate Complexity Factors
For each complexity adjustment factor, give a
rating on a scale of 0 to 5
0 - No influence
1- Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

46
 Complexity Adjustment Value

The rating for all the factors, F1 to F14, are summed to

produce the complexity adjustment value (CAV).

CAV is then used in the calculation of the function

point (FP) of the software

47
Example: Function Point -Oriented Metrics
If you were given, the information as below and
using table 1-3, assume that the weighting factor is
average, calculate what is the function point.

Number of user inputs : 5

Number of user outputs : 5
Number of user inquiries : 10 Refer Slide 18

Number of files : 3
Number of external interfaces : 3

48
Example: Function Point -Oriented Metrics
Weighting Factor

Parameter Count Simple Average Complex

Inputs 5 x 3 4 6 = 20
Outputs x 4 5 7 = 25
5
Inquiries x 3 4 6 = 40
10
Files x 7 10 15 = 30
3
Interfaces x 5 7 10 = 21
3
Count-total (raw FP) 136

Table 1-4 : Function Point Metrics Weighting Factor

49
Example: Function Point-Oriented Metrics
Assume that you were given that the complexity adjustment factor as
below:
Factor Value
1. Backup and recovery 0
2. Data communications 0
3. Distributed processing 0
4. Performance critical 3
5. Existing operating environment 0
6. On-line data entry 4
7. Input transaction over multiple screens 2
8. Master files updated on-line 0
9. Information domain values complex 2
10. Internal processing complex 2
11. Code designed for reuse 2
12. Conversion / installation in design 0
13. Multiple installations 0
14. Application designed for change 2
Sum of Complexity Factors: 17
Table 1-3
Example: Function Point -Oriented Metrics

Result :

= 136 * [0.65 + 0.01 *17]

= 111.52 Function points

= 112adjusted Function points

51
Example: Function Point -Oriented Metrics
If the project involves 5 workers per month, calculate
the productivity.

Thus,
productivity = 111.52/5
= 22.30

52
Example: Function Point -Oriented Metrics

Productivity = Functionality / Effort

= FP / person-month

Quality = Errors / Functionality

= Errors / FP

Cost = $ / FP

Documentation = pages / FP

53
Function Point Analysis
Because function point analysis is independent of
language used, development platform, etc. it can be
used to identify the productivity benefits of . . .
 One programming language over another
 One development platform over another
 One development methodology over another
 One programming department over another
 Before-and-after gains in investing in programmer
training
 And so forth …….
Function Point Characteristics
 Advantages:
 language independent, based on data known early in
project, good for estimation
 Disadvantages:
 calculation complexity, subjective assessments

55
Expected Software Size
Based on three-point factor
Compute Expected Software Size (S) as weighted
average of:
 Optimistic estimate: S(opt)
 Most likely estimate: S(ml)
 Pessimistic estimate: S(pess)
S = {S(opt) +4S(ml) +S(pess) }/ 6
 Beta probability distribution
Example 1: LOCApproach
 A system is composed of 7 subsystems as below:
 Given for each subsystem:
 size in LOC
 productivity metric: LOC/pm (pm: person month),
 Cost metric: $/LOC
 Calculate the system total cost in $ and effort in months
Example 1 – LOCApproach
Example 2: LOCApproach
Assuming
 Estimated project LOC =33200
 Organizational productivity (similar project type) =
620 LOC/p-m
Burdened labor 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$
Example 3: FPApproach
Example 3: FPApproach
Complexity Factor(cont…)
Example 3: FPApproach (cont…)
Example 4: FPApproach (cont.)
Assuming
 Estimated FP = 400
 Organization average productivity (similar project
type) = 6.5 FP/p-m (person-month)
Burdened labor rate = 8000 $/p-m
Then
 Estimated effort = 400/6.5 = (61.53) = 62 p-m
 Cost per FP = 8000/6.5 = 1231$/FP
 Project cost = 8000 * 62 = 496000 $
Empirical Estimation Models -
Estimation Cost Modelling
Function Point Table
Example of FPA
Object Point Analysis - Screen
Object Point Analysis :
Complexity Weighting
Object Point Analysis –
Productivity Rate
Estimation Cost Modelling

A is an organization-dependent constant
B reflects the nonlinearity(disproportionate) effort for large projects
M is a multiplier reflecting product, process and people attributes

Most commonly used product attribute for cost

estimation is code size (LOC)
Most models are basically similar but with different
values for A, B and M
System to be built
Object Point Analysis
Rating of system
Rating Results
Function Point Estimation
(FP ->KLOC)
FP-> LOC
Total Function Points =16
Published figures for C show that :
=> 1FP = 128 LOC in C
Estimated Size:
=> 16 * 128 = 20148 = 2 KLOC
Scale Factor Estimation
Effort Adjustment Factors(EAF)