Software Estimation Models

By: Vijay Kumar

 Introduction
• In the previous Session, we studied how an
estimate of the size of software can be made
either in terms of LOC or Function Points.
• This estimate would have to be converted into
an estimate of effort in terms of manpower
requirement and time required.
• Knowing the size of the software to be
developed and an understanding of the
complexity involved in developing the same, the
planner needs to produce an estimate of the
effort that would be involved.
 Cost Estimation Methods
• Algorithmic methods
– These models provide one or more
mathematical algorithms, which produce
software cost estimate as a function of the
number of cost drivers.
– COCOMO that we will be learning later is an
example.
 Expert Judgment
• Expert judgment techniques involve consulting
one or more experts, who use their experience
and understanding of the proposed project to
arrive at an estimate of its cost.
• The strengths and weaknesses of these
methods are highly complementary to the
algorithmic models.
• The expert is able to factor in differences
between the past projects and the existing one,
and the new techniques involved in the new.
• The expertise and objectivity of the estimator is
a major weakness, with the estimate being
affected by the bias, pessimism, optimism, lack
of knowledge and other personal interests of the
planner.
 Analogy
• The actual costs of one or more completed projects are
compared against the new project to arrive at an
estimate.
• The new requirement may be compared to an
old/completed project to understand the similarities and
differences.
• Estimation by analogy can be done either at the total
project level or at subsystem level.
• The main strength of estimation by analogy is that the
estimate is based on actual experience of the project.
• This experience can be studied to determine specific
differences from the new project and estimate its cost
impact.
 Cost Model
• Cost models offer direct estimates of
effort.
• These models have a primary cost factor
such as size and number of secondary
adjustment factors or cost drivers.
• Cost drivers are characteristics of the
project, process, products or resources
that influence effort.
 COCOMO
• COCOMO (Constructive Cost Model) was introduced by
Barry Boehm and is one of the most frequently used cost
models.
• It consists of three different models of increasing
complexity and level of detail.
• Model 1:
– The basic COCOMO model determines software
development effort (and cost) as a function of program
size expressed in estimated lines of code.
 COCOMO
• Model 2:
– The Intermediate COCOMO model calculates
software development effort as a function of
program size and a set of cost drivers that
include subjective assessments of product,
hardware, personnel and project attributes.
 COCOMO
• Model 3:
– The Advanced COCOMO model includes all
characteristics of the intermediate version
along with an evaluation of the impact of the
cost driver on each stage of the system
development life cycle.
 COCOMO
• COCOMO categorizes software projects
being developed into three modes:
– Organic,
– Semi-detached and
– Embedded.
 Organic Mode
• Considerably small, simple software projects
developed by small teams with good application
experience with not-so-rigid requirements, fall
into the organic mode.
• Most people connected with this sort of projects
have experience in working with related systems
within the organization and have a thorough
understanding of how the system under
development will contribute to the projects goals.
• There are few organic mode projects, which
were developed with more than 50 KDSI (*KDSI
stands for one thousand delivered source
instructions).
 Semi-Detached Mode
• An intermediate software project, where teams
with mixed experience levels must meet a mix of
rigid and less than rigid requirements, is
categorized as semi-detached mode.
• The semi-detached mode of software
development represents an intermediate stage
between organic and embedded modes.
• Intermediate may mean:
– Intermediate level of project characteristics.
– A mixture of organic and embedded characteristics
– The size of a semi-detached mode project may
extend up to 300 KDSI.
 Embedded Mode
• A software project that must be developed
within a set of tight hardware, software
and operational constraints is categorized
under embedded mode.
• The product must operate within a strongly
fixed model of hardware, software and
procedures.
• Embedded mode projects may deal with
all sizes of KDSI.
 The Basic COCOMO Model
• The basic COCOMO model provides quick, early and
rough order of magnitude estimates of software costs.
• Its accuracy is necessarily limited because of its lack of
factors to 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.
• The most fundamental calculation in the COCOMO
model is the use of the Effort Estimation to estimate the
number of staff months required to develop a project.
• Most of the other COCOMO results, including the
estimates for Requirements and Maintenance, are
derived from this quantity.
 The Basic COCOMO Model
• The Basic model was developed in what Boehm defined
as the Organic Mode.
• In such a software project, Boehm estimates:
– The number of thousands of delivered source instructions (KDSI)
in Man Months as:
MM = 2.4 (KDSI) 1.05
– The estimate of development schedule in months as:
TDEV = 2.5 (MM) 0.38
• The primary cost driver is the number of delivered
source instructions (DSI) developed by the project.
• The term, delivered software implies all program
instructions created by project personnel and processed
into machine code but excludes support software such
as test drivers, comment cards and unmodified utility
software. Job control languages format statements and
data declarations are included. Comments are not
included as instructions.
 Example
• The In House systems department has
received a request from the raw material
stores to develop a program to keep track
of raw materials. This would be similar to
the program already developed
successfully and running at the finished
goods store. An initial study has
determined that the size of the program
will be 45,000 DSI. Calculate an estimate
of the effort and schedule.
 The Basic COCOMO Model
• The project can be considered as an
organic mode software project, where
– Effort = 2.4 (KDSI) 1.05x = 2.4 (45)1.05 =
130.64= 131 man months
• Schedule = Time required
– TR= 2.5 (Effort MM) 0.38 = 2.5 (130.64)0.38 =
15.9 months
– No of persons= E/D=131/15.9=8.23=9
persons
Limitations of Basic COCOMO
• The major limitation of this model is that it
does not incorporate the effect of any of
the cost drivers involved in Software
development other than the lines of code.
• The figures generated out of a basic
COCOMO model may have to be adjusted
to take care of additional cost drivers like
personnel factors, hardware constraints
and environmental attributes.
The Intermediate COCOMO Model
• The basic COCOMO model helps in
explaining the variation that one observes
in the software project costs.
• The Intermediate COCOMO model
incorporates an additional 15 variables,
which explains the variation in the costs
not explained by the Basic COCOMO.
Different variables in Intermediate COCOMO
Model
Product attributes Computer attributes Personnel attributes Project attributes

Required Software Execution Time Analyst capability Modern

Reliability Constraint (ACAP) Programming
(RELY) (TIME) Practices
(MODP)
Data Base Size Main storage Applications Use of Software Tools
(DATA) Constraint Experience (TOOL)
(STOR) (AEXP)
Product Complexity Virtual Machine Programmer Required
(CPLX) Complexity Capability Development
(VIRT) (PCAP) Schedule (SCED)

Computer Virtual Machine

Turnaround Experience
Time (TURN) (VEXP)

Programming
Language
experience
(LEXP)
The Intermediate COCOMO Model
• The nominal COCOMO effort is multiplied by
factors based on the above attributes to obtain a
refined estimate of the software effort.
• In case of all these factors, a rating ranging from
0.70 to 1.4 is applied based on the type of
software being developed.
• This gives the final software development effort
in person months and the development
schedule.
• These parameters are assigned values as
tabled in next slide.
 Values Assigned to various Parameters
Cost Driver Very Low Low Nominal High Very High Extra High

ACAP Analyst 1.46 1.19 1.00 0.86 0.71 -

Capability
AEXP Applications 1.29 1.13 1.00 0.91 0.82 -
Experience
CPLX Product 0.70 0.85 1.00 1.15 1.30 1.65
Complexity
DATA Database Size - 0.94 1.00 1.08 1.16 -
LEXP Language 1.14 1.07 1.00 0.95 - -
Experience
MODP Modern 1.24 1.10 1.00 0.91 0.82 -
Programming
Practices
PCAP Programmer 1.42 1.17 1.00 0.86 0.70 -
Capability
RELY Required 0.75 0.88 1.00 1.15 1.40 -
Software Reliability
SCED Required 1.23 1.08 1.00 1.04 1.10
Development
Schedule
 Values Assigned to various Parameters
Cost Driver Very Low Low Nominal High Very High Extra
Hi
gh

STOR Main Storage - - 1.00 1.06 1.21 1.56

Constraint

TIME Execution Time - - 1.00 1.11 1.30 1.66

Constraint

TOOL Use of Software 1.24 1.10 1.00 0.91 0.83 -

Tools

TURN Computer - 0.87 1.00 1.07 1.15 -

Turnaround Time

VEXP Virtual 1.21 1.10 1.00 0.90 - -

Machine
Experience

VIRT Virtual Machine - 0.87 1.00 1.15 1.30 -

Volatility
 For example
• If our project will develop software that
controls an airplane's flight, we would set
the Required Software Reliability (RELY)
cost driver to Very High.
• Such a rating corresponds to an effort
multiplier of 1.40, meaning that our project
will require 40% more effort than a typical
software project.