Software

Project
Economics
 Software Project Economics:
Objectives
• To provide a framework that enables the manager to
make reasonable estimates of resources, cost and
schedule.
 Various steps of Planning Activity

Size Estimation

Cost Estimation Development Time

Resources
Requirements

Project
scheduling
 What is Estimation Method
• An estimation method is a set of processes, supported by
appropriate empirical formulae and backed with historical
reference data, that help derive predictable results within a
decent level of accuracy.
• There are a number of software project estimation methods
available to project managers that help arrive at estimated size,
effort, schedule, resource loading, and other similar parameters.
• For an estimation method to become easily acceptable by
software developers as well as business and IT groups, What
shall be the key ingredients of the method ?
 What is Estimation Method
The key ingredients of the method shall:
– Be a method that can be easily understood and deployable
– Allow modularization of the software application components
– Provide predictable results with an accuracy within reasonable
limits
– Be comparable across a variety of software projects
– Be backed by extensive regression analysis data
– Facilitate conversion/transformation of the output to other project
execution parameters such as schedule, cost, progress, etc.
– Include well-documented instruction manuals, continually
updated by recognized bodies

Function Point Analysis method truly provide answers

to the maximum needs of a software project estimator
 Function Point Analysis
• Alan Albercht (IBM 1970) developed a technique called
Function Point Analysis.
• It measures functionality from users point of view.
• It deals with functionality being delivered
 Pre-requisite to Function Point Count

• To commence the function point counting procedure,

documentation that describes the functionality delivered by
the software or the functionality that is impacted by the
software project being measured must be gathered.
• To properly determine all of the Functional User
Requirements, sufficient documentation must be obtained as
well as access to subject matter experts who are able to
provide additional information to address any gaps in the
documentation

Can you list some documents that may be required for

calculating Function Point?
 The following list of documentation is not exhaustive but is useful
when conducting any Functional Size Measurement
• Project proposals • Use/feature cases
• Requirement documents • System specifications
• Procedural descriptions • Detailed design specifications
• High-level system diagrams • Physical design models
(showing relationships to other • Operational models
interacting applications) • Program and module specifications
• Logical data models • File layouts
• Data flow diagrams • Screens and screen prints
• Entity relationship diagrams • Copies of reports or report layouts
• Data/object models • Test cases (features)
• Database layouts • User manuals and technical
• Class diagrams documentation
• Process models • Training materials
• Prototypes • Other software development
• Functional specifications artifacts
 FPA Model
• The FPA model facilitates the measurement of software application
size.
• The output of this method is a count (number) called function points.
• A function point is defined as a unit of business functionality delivered
through the software being measured.
– If application X has a measured count of 500 function points (FP),
the count signifies that the functionality delivered by the
application to the end users is equivalent to 500 business
functions.
• The FPA model is based on the premise that any software application
can be sized based on five key parameters: input, output, inquiries,
internal files, and external interfaces
• The most significant part of the software, from the developer's
perspective, is the code, which is not visible to the end user and is like
a black box. The FPA method does not touch the code part of the
software at all.
 FPA Model

Application B

Application Boundary

Fig. Components of an Application

 FPA Process
• In order to obtain the best results from the FPA model, it is
essential that you follow certain well-defined sizing processes
and workflows as prescribed in the user manual CPM
(Counting Practices Manual), version 4.2 by IFPUG .
• The steps to be followed include
– Identify a good estimator
– Obtain all the relevant artifacts of the application being counted
– Understand the user view
– Identify the type of function point (FP) count
– Determine the scope and boundary of the application
– Count the (unadjusted) data functions
– Count the (unadjusted) transaction functions
– Using the 14 GSC, calculate the value adjustment factor
– Arrive at the adjusted function point (FP) count
 FPA Process
Sequence of the steps to be followed during the counting process
 Function Point Analysis
• The principle of Function Point Analysis is that a
system is decomposed into functional units
• The five function units are divided in two categories:
– Data function types
• Internal Logical files
• External Interface files
– Transactional Function Types
• External Inputs
• External Outputs
• External Inquiry
 Special Features

• FPA is independent of the language, tools or methodologies used

for implementation
• Function points can be estimated from requirement
specification/design specifications, thus making it possible to
estimate development effort in early phases of development.
• Function Points are directly linked to the statement of
requirements; any change of requirements can easily be followed
by a re-estimate
• They are based on the system user’s external view of the system
• The five functional units are ranked according to their complexity
i.e. Low, Average or High.
• Organization that use FP methods develop criteria for determining
whether a particular entry is Low, Average or High
 Counting Function Points

Functional Units Weighing Factors

Low Average High

External Inputs 3 4 6

External Output 4 5 7

External Inquiries 3 4 6

Internal Logical files 7 10 15

External Interface files 5 7 10

 Unadjusted Function Point

Functional Unit
Functional Units Count complexity Complexity totals
Totals

Low x 3 =
External Inputs Average x 4 =
High x 6 =

Low x 4 =

External Outputs Average x 5 =

High x 7 =

Low x 3 =

External Inquiries Average x 4 =

High x 6 =

Low x 7 =
Internal Logical Average x 10 =
files High x 15 =

Low x 5 =
External Interface Average x 7 =
Files High x 10 =
 Procedure for Calculating UFP

5 3
UFP =  Z ij wij
I =1 J =1

Where i indicates the row and j indicates the column of Table “Functional Units with
weighing factors

wij : It is the entry of the ith row and jth column of Table “Functional Units with weighing
factors

Z ij : It is the count of the number of functional units of Type i that have been classified as
having the complexity corresponding to column j
 Complexity adjustment Factor

• The final number of function points is arrived at by

multiplying the UFP by an adjustment factor that is determined
by considering 14 aspects of processing complexity.
• This adjustment factor allows the UFP count to be modified by
at most 35%.
• The final adjusted FP count is obtained by using the following
relationship
FP= UFP * CAF
Where CAF = 0.65 + 0.01 x Fi
 Complexity adjustment Factor

Rate each factor on a scale of 0 to 5

0 1 2 3 4 5
No Influence Incidental Moderate Average Significant Essential

1. Does the system require reliable backup and recovery?

2. Is data communication 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 online data entry
7. Does the online data entry require the input to be built over
multiple screens or operations
 Complexity adjustment Factor

Rate each factor on a scale of 0 to 5

0 1 2 3 4 5
No Influence Incidental Moderate Average Significant Essential

8. Are the master files updated online?

9. Is the inputs, outputs, files or inquiries complex?
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?
 Problem
• Consider a project with the following functional
units:
• No. of user inputs = 50
• No. of outputs = 40
• No. of user enquiries = 35
• No of user files = =06
• No of external interfaces = 04
• Assume all CAF and weighting factors are average.
Compute the FP for the project
 Answer
5 3
UFP =  Z ij wij
I =1 J =1

UFP = 50*4+40*5+35*4+6*10+4*7
=200+200+140+60+28=628

CAF = (0.65 + 0.01  Fi )

=(0.65+0.01(14*3)) = 0.65 + 0.42 = 1.07

FP = UFP * CAF
=628 * 1.07 = 672
 Exercise
• An application has the following:
• 10 low external inputs, 12 high external outputs, 20
low internal logical files, 15 high external interface
files, 12 average external inquiries and a value of
CAF of 1.10.
• What are the unadjusted and adjusted FP counts?
 Answer
5 3
UFP =  Z
I =1 J =1
ij wij

= 10*3 + 12*7 + 20*7 + 15*10 + 12*4

= 30 + 84 + 140 + 150 + 48 = 452
FP = UFP * CAF
= 452 * 1.10 = 497.2
Example
Consider a project with the following parameters.
i) External Inputs
a) 10 with low complexity
b) 15 with average complexity
c) 17 with high complexity
ii) External outputs:
a) 6 with low complexity
b) 13 with high complexity
iii) External inquiries:
a) 3 with low complexity
b) 4 with average complexity
c) 2 with high complexity
Example
iv) Internal logical files:
a) 2 with average complexity
b) 1 with high complexity
v) External Interface files
a) 9 with low complexity

In addition to above, system required

• Significant data communication
• Performance is very critical
• Designed code may be moderately reusable
• System is not designed for multiple installations in different
organizations.
Other complexity adjustment factors are treated as average. Compute
the function points for the project
The factor given in table may be calculated as
14

Fi = 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41
i=1

CAF = (0.65 + 0.01 Fi)

= (0.65 + 0.01  41)
= 1.06
FP = UFP  CAF
= 424  1.06
= 449.44
Constructive Cost Model
 Constructive Cost Model (COCOMO)
• Proposed by B.W. Bohem in his famous book “Software
Engineering Economics” in 1981
• COCOMO is a hierarchy of software cost estimation models,
which include Basic, Intermediate and Detailed sub models
 Basic Model

• Aims at estimating in a quick and rough fashion.

• Used in small to medium size software projects.
• Three modes of software development are considered in this
model: Organic, Semi Detached and Embedded
 Basic Model
organic mode
– a small team of experienced developers develops software
in a very familiar environment.
– The size of the software development in this mode ranges
from small (a few KLOC) to medium (a few tens of
KLOC)
Embedded Mode
– The project has tight constraints, which might be related to
the target processor and its interface with the associated
hardware
– The problem to be solved is unique and so it is often hard
to find experienced persons, as the same does not usually
available
Semi detached mode
is an intermediate mode between the organic mode and
embedded mode.
Name some attributes that can be used to further qualify three Modes of Projects
 Comparison of three COCOMO Modes
Development
Mode Project size Nature of Project Innovation Deadline
Environment

Small size project,

Typically
experienced Familiar and
Organic 2-50 Little Not tight
developers in the Inhouse
KLOC
familiar environment

Medium size
Typically projects, medium size
Semi
50-300 team, Average Medium Medium Medium
detached KLOC previous experience
on similar projects
Large Project, real Complex
Over 300 time systems, complex Hardware/
Embedded Significant Tight
KLOC interfaces, very little interfaces
previous experience required
 Basic Model
• The basic COCOMO equations take the form
E = ab (KLOC ) b
b

D = cb (E ) b
d

E is the Effort applied in Person month

D is the Development Time in months
The coefficients ab,bb,cb,db are given in table below

Project ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi 3.0 1.12 2.5 0.35
detached

Embedded 3.6 1.20 2.5 0.32

Basic COCOMO Coefficient

• When effort and development
Basic Modeltime are known, the
average staff size to complete the project may be
calculated as:
– Average staff size = E/D persons

• When project size is known, the productivity level

may be calculated as:
– Productivity P = KLOC/E KLOC/PM
• Example : Suppose that a project was estimated to be
400 KLOC. Calculate the effort and development
time for each of the three modes i.e. organic,
semidetached and embedded.
Organic Mode
– E=2.4(400)1.05=1295.31 PM (Person-Month)
– D=2.5(1295.31)0.38=38.07 M
Semidetached Mode
– E=3.0(400)1.12 =2462.79 PM (Person-Month)
– D=2.5(2462.79)0.35 =38.45 M
Embedded Mode
– E=3.6(400)1.20=4772.81 PM (Person-Month)
– D=2.5(4772.81)0.32=38 M
 Discussions on Example

• Effort calculated for embedded mode is approximately

4 times, the effort for organic mode
• Effort calculated for semidetached mode is 2 times the
effort of organic mode.
• Surprisingly, the development time is approximately
the same for all three modes.
• Selection of Mode is very Important
– The selection of a mode is not only dependent on project
size, but also on other parameters as Nature of Project,
Innovation, Deadline of the project, Development
environment
• A project size of 200 KLOC is to be developed. Software
Example
development team has average experience on similar type of
projects. The project schedule is not very tight. Calculate the
effort, development time, average staff size and productivity
of the project.
 Solution

• The semi detached model is the most appropriate

mode. Keeping in view the size, schedule and
experience of the development team

E=3.0(200)1.12 =1133.12 PM (Person-Month)

D=2.5(1133.12)0.35 =29.3 M

E
Average Staff Size (SS) = Persons
D
= 1133.12 = 38.67 persons
29.3

KLOC 200
Productivity = = = 0.1765 KLOC / PM
E 1133.12
= 176 LOC/PM
• The basic modelIntermediate
allowed for Model
a quick and rough
estimate, but it resulted in a lack of accuracy.
• Boehm introduced an additional set of 15 predictors
called cost drivers in the intermediate model to take
account of the software development.
• Cost drivers are used to adjust the nominal cost of a
project to the actual project environment, increasing
the accuracy of the estimate.
• The cost driversIntermediate
are groupedModel
into four categories
• Product attributes
– Requires software reliability (RELY)
– Database size (DATA)
– Product complexity (CPLX)
• Computer attributes
– Execution time constraint (TIME)
– Main storage constraint (STOR)
– Virtual machine volatility (VIRT)
– Computer turn around time (TURN)
• The cost drivers Intermediate
are grouped into four categories
Model
• Personnel attributes
– Analyst capability (ACAP)
– Application experience (AEXP)
– Programmer capability (PCAP)
– Virtual machine experience (VEXP)
– Programming Language Experience (LEXP)
• Project attributes
– Modern programming practices (MODP)
– Use of software tool (TOOL)
– Required development schedule (SCED)
• Each cost drive is Intermediate
rated for a given project environment.
Model
• The rating uses a scale very low, low, nominal, high, very
high, extra high
 Ratings
Cost drivers
Very low Low Nominal High Very High Extra High
Product Attributes
RELY 0.75 0.88 1.00 1.15 1.40
DATA 0.94 1.00 1.08 1.16
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
Computer Attributes
TIME 1.00 1.11 1.30 1.66
STOR 1.00 1.06 1.21 1.56
VIRT 0.87 1.00 1.15 1.30
TURN 0.87 1.00 1.07 1.15
Personnel Attributes
ACAP 1.46 1.19 1.00 0.86 0.71
AEXP 1.29 1.13 1.00 0.91 0.82
PCAP 1.42 1.17 1.00 0.86 0.70
VEXP 1.21 1.10 1.00 0.90
LEXP 1.14 1.07 1.00 0.95
Project attributes
MODP .124 1.10 1.00 0.91 0.82
TOOL 1.24 1.10 1.00 0.91 0.83
SCED 1.23 1.08 1.00 1.04 1.10
 Intermediate Model

• The multiplying factors for all cost drivers are multiplied to

get the Effort Adjustment Factor (EAF). Typically EAF range
from 0.9 to 1.4
• The intermediate COCOMO equations take the form:

E = ai (KLOC )  EAF
bi

D = ci (E )
di
 Intermediate Model

Project ai bi ci di
Organic 3.2 1.05 2.5 0.38

Semi 3.0 1.12 2.5 0.35

detached
Embedde 2.8 1.20 2.5 0.32
d
 Detailed COCOMO Model
• It offers a means for processing all the project
characteristics to construct a software estimate.
The detailed model introduces two more capabilities:
• Phase-sensitive effort multipliers: some phases (like
design, programming, integration) are more affected
than others factors defined by cost driers. The
detailed model provides a set of phase sensitive effort
multipliers for each cost drivers.
• Three–level product hierarchy: Three product
levels -module, subsystem and system are defined.
The ratings of the cost drivers are done at appropriate
level; that is the level at which it is most susceptible
to variation.
 Development Phases
Software development is accomplished 4 successive phases
• Plans/Requirements: In this phase full product specification is
generated and this consumes 6% to 8% of the effort and 10%
to 40% of the development time
• Product design: requires 16% to 18% of the nominal effort and
can last up to 19% to 38% of the development time
• Programming requires 48% to 68 % of the effort and lasts
from 24% to 64% of the development time
• Integration / Test: requires 16% to 34% of the nominal effort
and can last from 18% to 34% of the development time.
 Principle of effort estimate
• Size Equivalent:
– the software might be partly developed from software
already existing, a full development is not always required.
In such cases, the parts of Design Document (DD%), Code
(C%) and Integration (I%) to be modified are estimated.
– Then an adjustment factor (A) is calculated by means of the
following equation.
A = 0.4 DD + 0.3 C +0.3 I 3.1
The size equivalent is obtained by
S (equivalent) = (S X A) /100
Where S represents the thousands of lines of code (KLOC) of
the module
 Principle of effort estimate

• Multipliers have been developed that can be applied to the

total project effort, E, and the total project development time,
D in order to allocate effort and schedule components to each
phase in the life cycle phases, and the effort and schedule for
each phase are assumed to be given in terms of the overall
effort and schedule by
• Ep = pE
• Dp = pD
Mode & code size Plan and System Detail Module Integration
Requirement Design Design code & & test
test

Life Cycle Phase Value p

Organic Small S = 2 0.06 0.16 0.26 0.42 0.16

Organic Medium S= 32 0.06 0.16 0.24 0.38 0.22
Semi det medium S= 32 0.07 0.17 0.25 0.33 0.25
Semi Det large S= 128 0.07 0.17 0.24 0.31 0.28
Embedded large S= 128 0.08 0.18 0.25 0.26 0.31
Embedded Extra. large 0.08 0.18 0.24 0.24 0.34
S= 320
Mode & code size Plan and System Detail Module Integration
Requirement Design Design code & & test
test

Lifecycle Phase Value of p

Organic Small S = 2 0.10 0.19 0.24 0.39 0.18

Organic Medium S =32 0.12 0.19 0.21 0.34 0.26

Semi det medium S= 32 0.20 0.26 0.21 0.27 0.26

Semi Det large S= 128 0.22 0.27 0.19 0.25 0.29

Embedded large S= 128 0.36 0.36 0.18 0.18 0.28

Embedded Extra large 0.40 0.38 0.16 0.16 0.30

S= 320
 Principle of effort estimate

• COCOMO is highly calibrated model.

• It is easy to use and documented properly.
• It does not give proper importance to software requirements
and specification phase.
 Example
• A new project with estimated 400 KLOC embedded system
has to be developed. Project manager has a choice of hiring
from two pools of developers: very highly capable with very
little experience in the programming language being used or
developers of low quality but a lot of experience with the
programming language. What is the impact of hiring
developers from one or the other pool.
 Solution

• This is the case of embedded mode and model is intermediate

COCOMO.
E = ai (KLOC ) D = ci (E )
bi di

E= 2.8 (400)1.20 =3712 PM

• Case 1 Developers are very highly capable with very little
experience in the programming being used
EAF = 0.70 * 1.14
(Programmer Capability (PCAP) 0.70)
(Programming Language Exp (LEXP) 1.14
• E1= EAF *3712
• D = 2.5 (E1) 0.32
• Consider a project toExample
develop a full screen editor. The
major components identified are (1) Screen edit (2)
Command Language Interpreter (3) file input and
output (4) cursor movement (5) Screen Movement.
The size of these are estimated to be 4K, 2K, 1K, 2K
and 3K delivered source code lines. Use COCOMO
model to determine:
• (a) Overall cost and schedule estimates
• (b) Cost and schedule estimates for different phases
• Size of five modules are: Solution
• Screen edit = 4 KLOC
• Command Language Interpreter = 2 KLOC
• File input and output = 1 KLOC
• Cursor Movement = 2 KLOC
• Screen Movement = 3 KLOC
• Total =12 KLOC
 Solution

Let us assume that the significant cost drivers are

– Required software reliability is high 1.15
– Product complexity is high 1.15
– Analyst capability is high 0.86
– Programming language experience is low 1.07
– All other drivers are nominal E = ai (KLOC ) i  EAF
b

EAF = 1.15 * 1.15 * 0.86 * 1.07 = 1.2169

D = ci (E )
di

E = 3.2(1.2 )  1.2169 = 52.91 PM

1.05

D = 2.5(52.91) = 11.29 M
0.38
Using the following equations and referring phase wise cost and schedule estimates can
be calculated
E p = p  E
Dp =  p D

Since size is only 12 KLOC, it is an organic small model. Phase wise effort distribution is
given below:

Effort Distribution
System Design 0.16 * 52.91 = 8.465 PM
Detailed Design 0.26 * 52.91 = 13.756 PM
Module Code and Test 0.42 * 52.91 = 22.222 PM
Integration and Test 0.16 * 52.91 = 8.465 PM
Time Distribution
System Design 0.19 * 11.29 = 2.145 M
Detailed Design 0.24 * 11.29 = 2.709 M
Module Code and Test 0.39 * 11.29 = 4.403 M
Integration and Test 0.18 * 11.29 = 2.032 M