OBJECT-ORIENTED

SOFTWARE ENGINEERING
UNIT 02 : PROJECT MANAGEMENT, PLANNING AND RISK
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
 UNIT 02: PROJECT MANAGEMENT

COCOMO

OOSE UNIT 02 - Project Management, Planning & Risk Analysis

SOFTWARE COST ESTIMATION METHODS
 Cost estimation: prediction of both the person-effort and elapsed time of a project
 Methods:
– Algorithmic
– Expert judgment
– Price-to-win
– Estimation by analogy – Top-down
– Parkinsonian – Bottom-up
 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
 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.
 THE DEVELOPMENT MODE
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: SOME ASSUMPTIONS
 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.
 FORMS OF COCOMO MODELS
 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.BASIC COCOMO
 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

OOSE UNIT 02 - Project Management, Planning & Risk Analysis

 1.BASIC COCOMO
 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.BASIC COCOMO
 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.BASIC COCOMO
Example: Consider your team is
developing a software project using semi- (2) Duration estimation
detached mode with 30,000 lines of
code . We will obtain estimation for this
project as follows:

(3)Person estimation
(1)Effort estimation
 1.BASIC COCOMO
Example: Consider your team is
developing a software project using semi- (2) Duration estimation
detached mode with 30,000 lines of D=c (E)d months
code . We will obtain estimation for this D=2.5 (136) 0.35 = 13.95 (14)
project as follows:

(3)Person estimation
(1)Effort estimation
N=E/D persons
E= a (KLOC)b person-months
N =136/14 = 9.7 (10)
E=3.0(30)1.12 = 135.36 (136)
 2. INTERMEDIATE COCOMO
 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
 COCOMO_II
Post COCOMO_II COCOMO_81 &
Cost Driver Architecture Early Design REVIC COCOMO_87 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      

OOSE UNIT 02 - Project Management, Planning & Risk Analysis

 COCOMO_II
Post COCOMO_II COCOMO_81 &
Cost Driver Architecture Early Design REVIC COCOMO_87 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    

OOSE UNIT 02 - Project Management, Planning & Risk Analysis

 2. INTERMEDIATE COCOMO
 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
2. INTERMEDIATE COCOMO
SOFTWARE PROJECTS ARE:

Software Projects Ai Bi

Organic 3.2 1.05

Semi-detached 3.0 1.12
Embedded 2.8 1.20
 2. INTERMEDIATE COCOMO
 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.
 2. INTERMEDIATE COCOMO
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 . D = cb (E)db
The estimation can be
=
E = a (KLOC)bi × EAF

As reliability is high
EAF=1.15 (product attribute) N = E/D
ai =
bi =

E=
 2. INTERMEDIATE COCOMO
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 . D = cb (E)db
The estimation can be = 2.5(191) 0.32
E = a (KLOC)bi × EAF = 13 months approximately
As reliability is high
EAF=1.15 (product attribute)
ai =2.8
N = E/D
bi =1.20 for embedded software = 191/13
E = 2.8 (30)1.20 × 1.15
= 191 person month N = 15 persons approx.
 3. DETAILED COCOMO MODEL
 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.
 3. DETAILED COCOMO MODEL
 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.
 3. DETAILED COCOMO MODEL
 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.
 3. DETAILED COCOMO MODEL
 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)
 3. DETAILED COCOMO MODEL
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.
 3. DETAILED COCOMO MODEL
Size of modules : 4 + 2 + 1 + 2 + 3 = 13 KLOC [Organic]
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 -- --

EAF = 1.15 * 1.15 * 0.86 * 1.07 = 1.2169

 3. DETAILED COCOMO MODEL
Initial Effort (E) = ab(KLOC)bb × EAF = 3.2 (12)1.05 × 1.2169
= 52.9 person-months

Initial Development Time (D) = cb(E)db =2.5*(52.9)0.38 = 11.29 months

Phase value of µp and τp

Plan & Req System Detail Module code & Integration & Test
Design Design 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
 3. DETAILED COCOMO MODEL
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
 UNIT 02: PROJECT MANAGEMENT

COCOMO-II
Reference: Cost Estimation with COCOMO II, Barry Boehm, University of Southern California
OOSE UNIT 02 - Project Management, Planning & Risk Analysis
 COCOMO BLACK BOX MODEL
product size estimate
development, maintenance
product, process,
cost and schedule estimates
platform, and personnel
attributes

reuse, maintenance,
and increment parameters
COCOMO II cost, schedule distribution by
phase, activity, increment

organizational
project data
recalibration to
organizational data

©USC-CSSE
 COCOMO EFFORT FORMULATION
# of cost drivers

Effort (person-months) = A (Size)E

i=1
Π Σm i

 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 i th cost driver. The geometric product results in an overall effort adjustment factor to the nominal
effort.

 Automated translation effects are not included

©USC-CSSE
 DISECONOMY OF SCALE
 Nonlinear relationship when exponent > 1
16000
B = 1 .2 2 6
P e rs o n M o n th s
14000
12000
10000
8000
6000
4000 B = 1 .0 0
2000
0 B = 0 .9 1
0 500 1000
KSLO C
©USC-CSSE
 COCOMO SCHEDULE FORMULATION
Schedule (months) = C (Effort)(.33+0.2(E-1.01)) x SCED% / 100
 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
RUP/ICSM PHASE DISTRIBUTIONS
Phase Effort % Schedule %
Inception 6 12.5
Elaboration 24 37.5
Construction 76 62.5
Transition 12 12.5
COCOMO Total 100 100
Project Total 118 125

©USC-CSSE
 COCOMO II OUTPUT RANGES
 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.
Stage Optimistic Pessimistic
Estimate Estimate

1 0.50 E 2.0 E

2 0.67 E 1.5 E

3 0.80 E 1.25 E

©USC-CSSE
REUSED AND MODIFIED SOFTWARE
 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
 NONLINEAR REUSE EFFECTS
 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
NONLINEAR REUSE EFFECTS
Data on 2954
NASA modules 1.0
[Selby,1988]
1.0

0.70
0.75
0.55
Relative
cost
0.5

Usual Linear
Assumption
0.25

0.046

0.25 0.5 0.75 1.0

Amount Modified

©USC-CSSE
 COCOMO REUSE MODEL
 A nonlinear estimation model to convert
adapted (reused or modified) software into
equivalent size of new software:
AAF  0.4( DM )  0.3( CM )  0.3( IM )

ASLOC[ AA  AAF (1  0.02( SU )(UNFM ))]

ESLOC  , AAF  0.5
100

ASLOC[ AA  AAF  ( SU )(UNFM )]

ESLOC  , AAF  0.5
100
©USC-CSSE
 COCOMO REUSE MODEL CONT’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
 ASSESSMENT AND ASSIMILATION
INCREMENT (AA)

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

©USC-CSSE
 SOFTWARE UNDERSTANDING
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).
Very Low Low Nominal High Very High
Structure Very low Moderately low Reasonably well- High cohesion, low Strong modularity,
cohesion, high cohesion, high structured; some coupling. information hiding in
coupling, coupling. weak areas. data / control
spaghetti code. structures.
Application No match Some correlation Moderate Good correlation Clear match between
Clarity between program between program correlation between program program and
and application and application. between program and application. application world-
world views. and application. views.
Self- Obscure code; Some code Moderate level of Good code Self-descriptive code;
Descriptivenes documentation commentary and code commentary and documentation up-to-
s missing, obscure headers; some commentary, headers; useful date, well-organized,
or obsolete useful headers, documentation; with design rationale.
documentation. documentations. some weak areas.
SU Increment 50 40 30 20 10
to ESLOC

©USC-CSSE
 PROGRAMMER UNFAMILIARITY (UNFM)

 Only applies to modified software

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

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

©USC-CSSE
 COST DRIVERS
 Personnel factors
 Product Factors – Analyst capability (ACAP)
– Reliability (RELY)
– Program capability (PCAP)
– Data (DATA)
– Applications experience (APEX)
– Complexity (CPLX)
– Platform experience (PLEX)
– Reusability (RUSE)
– – Language and tool experience (LTEX)
Documentation (DOCU)
– Personnel continuity (PCON)
 Platform Factors
– Time constraint (TIME)  Project Factors
– Storage constraint (STOR) – Software tools (TOOL)
– Platform volatility (PVOL) – Multisite development (SITE)
– Required schedule (SCED)
©USC-CSSE
 PRODUCT FACTORS
 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
Very Low Low Nominal High Very High Extra High
RELY slight low, easily moderate, easily high financial loss risk to human life
inconvenience recoverable losses recoverable losses

©USC-CSSE
50
EXAMPLE EFFORT MULTIPLIER VALUES FOR RELY

1.39

Low, Easily
Recoverable
Losses 1.15

Very Low Low Nominal High Very High

1.0
Slight Moderate, Easily High Financial Risk to Human
Inconvenience Recoverable Loss Life
0.88 Losses

0.75
©USC-CSSE
 EXAMPLE EFFORT MULTIPLIER VALUES FOR RELY

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
TABLE 2.50 COCOMO II SCALE FACTORS & MULTIPLIERS

©USC-CSSE
 EXAMPLE TABLE-BASED ESTIMATION
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

OOSE UNIT 02 - Project Management, Planning & Risk Analysis