COCOMO methods for software size estimation

OBJECT-ORIENTED
SOFTWAREENGINEERING
UNIT 02: PROJECTMANAGEMENT,PLANNINGANDRISK
ANALYSIS
© 2019, PRAMOD PARAJULI

Disclaimer
These slides are part of teaching materials for Object Oriented
Software Engineering (OOSE). These slides do not cover all
aspect of learning OOSE, nor are these be taken as primary
source of information. As the core textbooks and reference
books for learning the subject has already been specified and
provided to the students, students are encouraged to learn
from the original sources.
Contents in these slides are copyrighted to the instructor and
authors of original texts where applicable.
OOSE UNIT 02 - Project Management, Planning & Risk Analysis

COCOMO
UNIT 02: PROJECT MANAGEMENT

SOFTWARECOSTESTIMATIONMETHODS
 Cost estimation: prediction of both the person-effort and elapsed time of a project
 Methods:
– Algorithmic
– Expert judgment
– Estimation by analogy
– Parkinsonian
 Best approach is a combination of methods
– compare and iterate estimates, reconcile differences
 COCOMO - the “COnstructive COst MOdel”
– COCOMO II is the update to Dr. Barry Boehm’s COCOMO 1981
 COCOMO is the most widely used, thoroughly documented and calibrated cost
model
– Price-to-win
– Top-down
– Bottom-up

INTRODUCTION
 proposed by Barrey W. Boehm in 1981.
 Empirical software estimation model in the world.
 Predicts the effort and duration of a project based on
:
• inputs relating to the size of the resulting systems and
• number of "cost drives" that affect productivity.

THEDEVELOPMENTMODE
1. Organic mode :
• Relatively simple ,
• small projects with a small team are handled .
• good application experience to less rigid requirements.
2. Semidetached mode:
• For intermediate software projects(little complex compared to organic mode projects in terms
of size).
• have a mix of rigid and less than rigid requirements.
3.Embedded mode:
• Project to be developed within a tight set of hardware and software operational constraints.
• Example of complex project: Air traffic control system

 The coefficients of Aa, bb, cc, dd for the three
modes are:
Aa bb cc dd
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

COCOMO:SOMEASSUMPTIONS
 Primary cost driver is the number of Delivered Source
Instructions (DSI) / Delivered Line Of Code developed by
the project
 COCOMO estimates assume that the project will enjoy
good management by both the developer and the customer
 Assumes the requirements specification is not
substantially changed after the plans and requirements
phase.

FORMSOFCOCOMOMODELS
 COCOMO is defined in terms of three different models:
1. Basic model,
2. Intermediate model, and
3. Detailed model.
1. Basic Model:
– a function of program size expressed in terms of lines of Code (LOC).
– good for quick, early, rough order of magnitude estimates of
software costs .

1.BASICCOCOMO
 a function of program size expressed in terms of lines of Code
(LOC).
 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

1.BASICCOCOMO
 The basic COCOMO model takes the following form:
E=ab (KLOC)bb
persons-months
D=cb (E)db
months
where,
E - Stands for the effort applied in terms of person months
D - Development time in chronological months
KLOC - Kilo lines of code of the project.
From E & D we can compute the no. of people required to accomplish the project as
N=E/D

1.BASICCOCOMO
 Merits
• good for quick, early, rough order of magnitude estimates of
software project.
 Limitations
• Limited Accuracy: does not consider certain factors (hardware
constraints, personal quality and experiences, modern
techniques and tools ) for cost estimation of software.
• The estimates within a factor of 1.3 only 29% of the time and
within the factor of 2 only 60% of time.

1.BASICCOCOMO
Example: Consider your team is
developing a software project using semi-
detached mode with 30,000 lines of
code . We will obtain estimation for this
project as follows:
(1)Effort estimation
(2) Duration estimation
(3)Person estimation

1.BASICCOCOMO
Example: Consider your team is
developing a software project using semi-
detached mode with 30,000 lines of
code . We will obtain estimation for this
project as follows:
(1)Effort estimation
E= a (KLOC)b
person-months
E=3.0(30)1.12
= 135.36 (136)
(2) Duration estimation
D=c (E)d
months
D=2.5 (136) 0.35
= 13.95 (14)
(3)Person estimation
N=E/D persons
N =136/14 = 9.7 (10)

2.INTERMEDIATECOCOMO
 Computes effort as a function of program size
and a lot of cost drivers that includes subjective
assessment of
• product attributes,
• hardware attributes,
• personal attributes and
• project attributes

Cost Driver
COCOMO_II
Post
Architecture
COCOMO_II
Early Design REVIC COCOMO_87
COCOMO_81 &
COCOMO_85
Personnel Factors
ACAP Analyst Capability Yes Yes Yes Yes
APEX AEXP Applications Experience Yes Yes Yes Yes
PCAP Programmer Capability Yes Yes Yes Yes
LEXP Programming Language Experience Yes Yes Yes
VEXP Virtual Machine Experience Yes Yes Yes
PERS Personnel Capability Yes
PREX Personnel Experience Yes
PCON Personnel Continuity Yes
PLEX PEXP Platform Experience Yes
LTEX Language and Tool Experience Yes
Product Factors
RELY Required Software Reliability Yes Yes Yes Yes
DATA Database Size Yes Yes Yes Yes
CPLX Software Product Complexity Yes Yes Yes Yes
RUSE Required Reusability Yes Yes Yes Yes
DOCU Documentation Match to Life-Cycle Needs Yes
RCPX Product Reliability and Complexity Yes

Cost Driver
COCOMO_II
Post
Architecture
COCOMO_II
Early Design REVIC COCOMO_87
COCOMO_81 &
COCOMO_85
Platform Factors
TIME Execution Time Constraint Yes Yes Yes Yes
STOR Main Storage Constraint Yes Yes Yes Yes
TURN Computer Turnaround Time Yes Yes Yes
VIRT Virtual Machine Volatility Yes Yes
VMVH Virtual Machine Volatility: Host Yes
VMVT Virtual Machine Volatility: Target Yes
PVOL Platform Volatility Yes
PDIF Platform Difficulty Yes
PLAT Platform Yes
Project Factors
TOOL Use of Software Tools Yes Yes Yes Yes
MODP Modern Programming Practices Yes Yes Yes
SCED Required Development Schedule Yes Yes Yes Yes Yes
SECU Classified Security Application Yes Yes
SITE Multisite Development Yes
FCIL Facilities Yes
RVOL Requirements Volatility Yes

 Based on the rating effort multipliers is determined. The product of all
effort Multipliers result in “effort adjustment factor” (EAF). The
intermediate COCOMO takes the form.
 E = ai (KLOC)bi
× EAF where
E - Effort applied in terms of person-months
KLOC - Kilo lines of code for the project
EAF - It is the effort adjustment factor
 The duration and person estimate is same as in basic COCOMO model i.e;
D = cb (E)db
months i.e; use values of cb and db coefficients.
 N=E/D persons

THE VALUES OF AI AND BI FOR VARIOUS CLASS OF
SOFTWARE PROJECTS ARE:
Software Projects Ai Bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20

 Merits:
• This model can be applied to almost entire software product for
easy and rough cost estimation during early stage.
• It can also be applied at the software product component level for
obtaining more accurate cost estimation.
 Limitations:
• The effort multipliers are not dependent on phases.
• A product with many components is difficult to estimate.

Example: Consider your team is developing a project
having 30,000 lines of code which in an embedded
software with critical area hence reliability is high .
The estimation can be
E = a (KLOC)bi
× EAF
As reliability is high
EAF=1.15 (product attribute)
ai =
bi =
E =
D = cb (E)db
=
N = E/D

Example: Consider your team is developing a project
having 30,000 lines of code which in an embedded
software with critical area hence reliability is high .
The estimation can be
E = a (KLOC)bi
× EAF
As reliability is high
EAF=1.15 (product attribute)
ai =2.8
bi =1.20 for embedded software
E = 2.8 (30)1.20
× 1.15
= 191 person month
D = cb (E)db
= 2.5(191) 0.32
= 13 months approximately
N = E/D
= 191/13
N = 15 persons approx.

3.DETAILEDCOCOMOMODEL
 Detailed COCOMO incorporates all
characteristics of the intermediate version with
an assessment of the cost driver’s impact on
each phase of the development process.
 This helps in determining the man power
allocation for each phase of the project.

 Phase-Sensitive Effort Multipliers:
• Some phases( Design, programming, integration/test)are more affected
than others by factors defined by the cost drivers.
 Three –Level Product Hierarchy:
• Modules,
• Sub-System, and
• System Levels
 The rating of the cost drivers are done at appropriate level. i.e.
the level at which it is most suspicious to variation.

 Phases
• Plans and requirements
• System Design
• Detailed Design
• Module code and test
• Integrate and test
 Cost of each subsystem is estimated separately. This reduces
the margin of error.

 Multiply all 15 Cost Drivers to get Effort Adjustment
Factor(EAF)
 E(Effort) = ab(KLOC)bb
× EAF(in Person-Month)
 D(Development Time) = cb(E)db
(in month)
 Ep (Total Effort) = µp × E (in Person-Month)
 Dp (Total Development Time) = τp × D (in month)

Consider you are developing a full screen editor as a project. The major components identified and
their sizes are
(i) Screen Edit – 4K
(ii) Command Lang Interpreter – 2K
(iii)File Input and Output – 1K
(iv) Cursor movement – 2K
(v) Screen Movement – 3K.
Assume the Required software reliability is high, product complexity is high, analyst capability is
high & programming language experience is low. Use COCOMO model to estimate cost and
time for different phases.

Size of modules : 4 + 2 + 1 + 2 + 3 = 13 KLOC [Organic]
EAF = 1.15 * 1.15 * 0.86 * 1.07 = 1.2169
Cost Drivers Very Low Low Nominal High Very High Extra High
RELY 0.75 0.88 1.00 1.15 1.40 --
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
ACAP 1.46 1.19 1.00 0.86 0.71
LEXP 1.14 1.07 1.00 0.95 -- --

Initial Effort (E) = ab(KLOC)bb
× EAF = 3.2 (12)1.05
× 1.2169
= 52.9 person-months
Initial Development Time (D) = cb(E)d
b =2.5*(52.9)0.38
= 11.29 months
Phase value of µp and τp
Plan & Req System
Design
Detail
Design
Module code &
test
Integration & Test
Organic Small µp 0.06 0.16 0.26 0.42 0.16
Organic Small τp 0.10 0.19 0.24 0.39 0.18

Phase wise effort & development time distribution
E D Ep (in person-months) Dp (in months)
Plan & Requirement 52.9 11.29 0.06*52.9 = 3.17 0.10*11.29=1.12
System Design
Detail Design
Module code & test
Integration & test
Reference: COCOMO-I, Classroom Presentation, Jagat Man Mulguthi, NCIT, Spring 2018

COCOMO-II
UNIT 02: PROJECT MANAGEMENT
Reference: Cost Estimation with COCOMO II, Barry Boehm, University of Southern California

COCOMOBLACKBOXMODEL
©USC-CSSE
COCOMO II
product size estimate
product, process,
platform, and personnel
attributes
reuse, maintenance,
and increment parameters
organizational
project data
development, maintenance
cost and schedule estimates
cost, schedule distribution by
phase, activity, increment
recalibration to
organizational data

COCOMOEFFORTFORMULATION
# of cost drivers
Effort (person-months) = A (Size)E
Π Σmi
i=1
 Where:
– A is a constant derived from historical project data
(currently A = 2.94 in COCOMOII.2000)
– Size is in KSLOC (thousand source lines of code),
or converted from function points or object points
– Σ is an exponent for the diseconomy of scale dependent on five additive scale drivers according to
b = .91 + .01×ΣSFi,
where SFi is a weighting factor for ith
scale driver
– ΣMi is the effort multiplier for the ith cost driver. The geometric product results in an overall effort adjustment factor to the nominal effort.
 Automated translation effects are not included
©USC-CSSE

DISECONOMYOFSCALE
 Nonlinear relationship when exponent > 1
©USC-CSSE
0
2 0 0 0
4 0 0 0
6 0 0 0
8 0 0 0
1 0 0 0 0
1 2 0 0 0
1 4 0 0 0
1 6 0 0 0
0 5 0 0 1 0 0 0
K S L O C
P
e
r
s
o
n
M
o
n
t
h
s
B = 1 .2 2 6
B = 1 .0 0
B = 0 .9 1

COCOMOSCHEDULEFORMULATION
 Where:
– Schedule is the calendar time in months from the requirements baseline to acceptance
– C is a constant derived from historical project data
(currently C = 3.67 in COCOMOII.2000)
– Effort is the estimated person-months excluding the SCED effort multiplier
– E is the exponent in the effort equation
– SCED% is the compression / expansion percentage in the SCED cost driver
 This is the COCOMOII.2000 calibration
 Formula can vary to reflect process models for reusable and COTS
software, and the effects of application composition capabilities.
©USC-CSSE
Schedule (months) = C (Effort)(.33+0.2(E-1.01))
x SCED% / 100

RUP/ICSMPHASEDISTRIBUTIONS
©USC-CSSE
125
118
Project Total
100
100
COCOMO Total
12.5
12
Transition
62.5
76
Construction
37.5
24
Elaboration
12.5
6
Inception
Schedule %
Effort %
Phase

COCOMOII OUTPUTRANGES
 COCOMO II provides one standard deviation optimistic and
pessimistic estimates.
 Reflect sources of input uncertainties per funnel chart.
 Apply to effort or schedule for all of the stage models.
 Represent 80% confidence limits: below optimistic or
pessimistic estimates 10% of the time.
©USC-CSSE
Stage Optimistic
Estimate
Pessimistic
Estimate
1 0.50 E 2.0 E
2 0.67 E 1.5 E
3 0.80 E 1.25 E

REUSEDANDMODIFIEDSOFTWARE
 Effort for adapted software (reused or
modified) is not the same as for new software.
 Approach: convert adapted software into
equivalent size of new software.
©USC-CSSE

NONLINEARREUSEEFFECTS
 The reuse cost function does not go through the origin
due to a cost of about 5% for assessing, selecting, and
assimilating the reusable component.
 Small modifications generate disproportionately large
costs primarily due the cost of understanding the
software to be modified, and the relative cost of
interface checking.
©USC-CSSE

NONLINEARREUSEEFFECTS
©USC-CSSE
Relative
cost
Amount Modified
1.0
0.75
0.5
0.25
0.25 0.5 0.75 1.0
0.55
0.70
1.0
0.046
Usual Linear
Assumption
Data on 2954
NASA modules
[Selby,1988]

COCOMOREUSEMODEL
 A nonlinear estimation model to convert
adapted (reused or modified) software into
equivalent size of new software:
©USC-CSSE
AAF DM CM IM
  
0 4 0 3 0 3
. ( ) . ( ) . ( )
ESLOC
ASLOC AA AAF SU UNFM
AAF

 

[ ( . ( )( ))]
, .
1 0 02
100
0 5
ESLOC
ASLOC AA AAF SU UNFM
AAF

 

[ ( )( )]
, .
100
0 5

COCOMOREUSEMODELCONT’D
 ASLOC - Adapted Source Lines of Code
 ESLOC - Equivalent Source Lines of Code
 AAF - Adaptation Adjustment Factor
 DM - Percent Design Modified. The percentage of the adapted software's design which is modified in
order to adapt it to the new objectives and environment.
 CM - Percent Code Modified. The percentage of the adapted software's code which is modified in order
to adapt it to the new objectives and environment.
 IM - Percent of Integration Required for Modified Software. The percentage of effort required to
integrate the adapted software into an overall product and to test the resulting product as compared to
the normal amount of integration and test effort for software of comparable size.
 AA - Assessment and Assimilation effort needed to determine whether a fully-reused software module is
appropriate to the application, and to integrate its description into the overall product description. See
table.
 SU - Software Understanding. Effort increment as a percentage. Only used when code is modified
(zero when DM=0 and CM=0). See table.
 UNFM - Unfamiliarity. The programmer's relative unfamiliarity with the software which is applied
multiplicatively to the software understanding effort increment (0-1).
©USC-CSSE

ASSESSMENTANDASSIMILATION
INCREMENT(AA)
©USC-CSSE
AA Increment Level of AA Effort
0 None
2 Basic module search and documentation
4 Some module Test and Evaluation (T&E), documentation
6 Considerable module T&E, documentation
8 Extensive module T&E, documentation

SOFTWAREUNDERSTANDING
INCREMENT(SU)
 Take the subjective average of the three categories.
 Do not use SU if the component is being used unmodified
(DM=0 and CM =0).
©USC-CSSE
Very Low Low Nominal High Very High
Structure Very low
cohesion, high
coupling,
spaghetti code.
Moderately low
cohesion, high
coupling.
Reasonably well-
structured; some
weak areas.
High cohesion, low
coupling.
Strong modularity,
information hiding in
data / control
structures.
Application
Clarity
No match
between program
and application
world views.
Some correlation
between program
and application.
Moderate
correlation
between program
and application.
Good correlation
between program
and application.
Clear match between
program and
application world-
views.
Self-
Descriptivenes
s
Obscure code;
documentation
missing, obscure
or obsolete
Some code
commentary and
headers; some
useful
documentation.
Moderate level of
code
commentary,
headers,
documentations.
Good code
commentary and
headers; useful
documentation;
some weak areas.
Self-descriptive code;
documentation up-to-
date, well-organized,
with design rationale.
SU Increment
to ESLOC
50 40 30 20 10

PROGRAMMERUNFAMILIARITY(UNFM)
 Only applies to modified software
©USC-CSSE
UNFM Increment Level of Unfamiliarity
0.0 Completely familiar
0.2 Mostly familiar
0.4 Somewhat familiar
0.6 Considerably familiar
0.8 Mostly unfamiliar
1.0 Completely unfamiliar

COSTFACTORS
 Significant factors of development cost:
– scale drivers are sources of exponential effort variation
– cost drivers are sources of linear effort variation
• product, platform, personnel and project attributes
• effort multipliers associated with cost driver ratings
– Defined to be as objective as possible
 Each factor is rated between very low and very high
per rating guidelines
– relevant effort multipliers adjust the cost up or down
©USC-CSSE

SCALEFACTORS
 Precedentedness (PREC)
– Degree to which system is new and past experience applies
 Development Flexibility (FLEX)
– Need to conform with specified requirements
 Architecture/Risk Resolution (RESL)
– Degree of design thoroughness and risk elimination
 Team Cohesion (TEAM)
– Need to synchronize stakeholders and minimize conflict
 Process Maturity (PMAT)
– SEI CMM process maturity rating
©USC-CSSE

SCALEFACTORRATING
©USC-CSSE
Scale Factors (Wi) Very Low Low Nominal High Very High Extra High
Precedentedness
(PREC)
thoroughly
unprecedented
largely
unprecedented
somewhat
unprecedented
generally
familiar
largely
familiar
throughly
familiar
Development
Flexibility (FLEX)
rigorous occasional
relaxation
some
relaxation
general
conformity
some
conformity
general
goals
Architecture/Risk
Resolution (RESL)*
little (20%) some (40%) often (60%) generally
(75%)
mostly
(90%)
full (100%)
Team Cohesion
(TEAM)
very difficult
interactions
some difficult
interactions
basically
cooperative
interactions
largely
cooperative
highly
cooperative
seamless
interactions
Process Maturity
(PMAT)
Weighted average of “Yes” answers to CMM Maturity Questionnaire
* % significant module interfaces specified, % significant risks eliminated

COSTDRIVERS
 Product Factors
– Reliability (RELY)
– Data (DATA)
– Complexity (CPLX)
– Reusability (RUSE)
– Documentation (DOCU)
 Platform Factors
– Time constraint (TIME)
– Storage constraint (STOR)
– Platform volatility (PVOL)
©USC-CSSE
 Personnel factors
– Analyst capability (ACAP)
– Program capability (PCAP)
– Applications experience (APEX)
– Platform experience (PLEX)
– Language and tool experience (LTEX)
– Personnel continuity (PCON)
 Project Factors
– Software tools (TOOL)
– Multisite development (SITE)
– Required schedule (SCED)

PRODUCTFACTORS
 Required Software Reliability (RELY)
– Measures the extent to which the software must
perform its intended function over a period of
time.
– Ask: what is the effect of a software failure
©USC-CSSE
50
Very Low Low Nominal High Very High Extra High
RELY slight
inconvenience
low, easily
recoverable losses
moderate, easily
recoverable losses
high financial loss risk to human life

EXAMPLEEFFORTMULTIPLIERVALUESFORRELY
©USC-CSSE
Very Low Low High Very High
Slight
Inconvenience
Low, Easily
Recoverable
Losses
High Financial
Loss
Risk to Human
Life
1.15
0.75
0.88
1.39
1.0
Moderate, Easily
Recoverable
Losses
Nominal

EXAMPLEEFFORTMULTIPLIERVALUESFORRELY
E.g. a highly reliable system costs 39% more than a nominally reliable system
1.39/1.0=1.39)
or a highly reliable system costs 85% more than a very low reliability system
(1.39/.75=1.85)
©USC-CSSE

EXAMPLETABLE-BASEDESTIMATION
Effort (person-months) = 2.94 (Size)E
Π Σmi
E is an exponent for the diseconomy of scale dependent on five additive scale drivers according to b = .91 + .01 × Σ SFi,
where SFi is a weighting factor for ith
scale driver
Example estimate: Size=30 KSLOC; RELY, CPLX = High; TOOL= High; All other scale factors and cost drivers = Nominal
E = 0.91 + .01 (3.72+3.04+4.24+3.29+4.68) = 0.91 + .1897 = 1.0997 ~ 1.1
P Σmi = (1.10) × (1.17) × (0.90) = 1.1583
Size = 30 KSLOC
Effort = 2.94 × 30 1.1 ×
1.1583 = 143.55 person-months
©USC-CSSE

End of Unit 02 : Project Management, Planning and
Risk Analysis

COCOMO methods for software size estimation

More Related Content

What's hot (20)

Similar to COCOMO methods for software size estimation (20)

Recently uploaded (20)

COCOMO methods for software size estimation