Software Cost Estimation

and COCOMO II

❚ Park, Jung-Won ❚ Univ. of Southern Cal.

(USC)
❚ Center for Software
Engineering (CSE)

❚ Systems Engineering
Research Institute
(SERI), Taejon, Korea
❚ December 29, 1997
What is COCOMO?

❚ COnstructive COst MOdel

❚ estimating software development effort and cost
❚ function of the size of the software product in
source instructions
❚ function of the most significant software cost
drivers
Importance of Software
Cost Estimation - problems

❚ Software project personnel have no firm basis

for telling a manager, customer, or salesperson
that their proposed budget and schedule are
unrealistic.
❚ Software analysts have no firm basis for making
realistic hardware-software tradeoff analysis
during the system design phase.
❚ Project managers have no firm basis for
determining how much time and effort each
software phase and activity should take.
USC-CSE Affiliates

❚ Commercial Industry (9)

AT&T, Bellcore, EDS, HP, IDE, Motorola, Rational, TI,
Xerox
❚ Aerospace Industry (9)
E-Systems, Hughes, Litton, Lockheed, Loral, Northrop
Grumman, Rockwell, SAIC, TRW
❚ Government (3)
DISA, USAF Rome Lab, US Army Research Labs
❚ FFRDC’s and Consortia (5)
Aerospace, IDA, JPL, SEI, SPC
Partial List of COCOMO
Packages

❚ CB COCOMO ❚ GHL COCOMO

❚ COCOMOID ❚ REVIC
❚ COCOMO1 ❚ SECOMO
❚ CoCoPro ❚ SWAN
❚ COSTAR
❚ COSTMODL
❚ GECOMO Plus
Steps in Software
Estimation

❚ 1. Establish Objectives
* Rough Sizing
* Make-or-Buy
* Detailed Planning
❚ 2. Allocate enough time, dollars, talent
❚ 3. Pin down software requirements
* Document definitions, assumptions
❚ 4. Work out as much as detail as objectives permit
Steps in Software
Estimation

❚ 5. Use several independent techniques and sources

* Top-Down vs. Bottom-Up
* Algorithms vs. Expert Judgment
❚ 6. Compare and iterate estimates
* Pin down and resolve inconsistencies
* Be constructive
❚ 7. Follow up
COCOMO FEATURES

❚ Development cost and schedule estimates

❚ 3 levels of fidelity
❚ Macro and micro estimation
❚ Sensitivity analysis
❚ Software adaptation, conversion costs
❚ Software maintenance costs
❚ Calibration to user environment
Three COCOMO modes of
Software Development

❚ Organic Mode - small software teams develop

software in a highly familiar, in-house
environment.
❚ Semidetached Mode - intermediate between the
organic and embedded modes.
❚ Embedded Mode - need to operate within tight
constraints. (electronic funds transfer system or
an air traffic control system)
 Basic COCOMO Effort and
Schedule Equations

Mode Effort Schedule

Organic MM = 2.4(KDSI)1.05 TDEV = 2.5(MM)0.38
Semidetached MM = 3.0(KDSI)1.12 TDEV = 2.5(MM)0.35
Embedded MM = 3.6(KDSI)1.20 TDEV = 2.5(MM)0.32

KDSI = thousands of delivered source instructions

A COCOMO man-month consists of 152 hours of
working time.
 Intermediate COCOMO Effort
and Schedule Equations

Mode Nominal Effort Schedule

Organic (MM)NOM = 3.2(KEDSI)1.05 TDEV = 2.5(MM)0.38
Semidetached (MM)NOM = 3.0(KEDSI)1.12 TDEV = 2.5(MM)0.35
Embedded (MM)NOM = 2.8(KEDSI)1.20 TDEV = 2.5(MM)0.32

MM = MMNOM x Π(EM)
KEDSI = thousands of equivalent delivered source
instructions
Software Productivity
Range
1.20 Language experience

1.23 Schedule constraint

1.23 Data base size

Software cost driver attribute

1.32 Turnaround time

1.34 Virtual machine experience
1.49 Virtual machine volatility
1.49 Software tools
1.51 Modern programming practices
1.56 Storage constraint
1.57 Applications experience
1.66 Timing constraint
1.87 Required reliability
2.36 Product complexity
4.18 Personnel/team capability
1.00
Software productivity range
Software Costing and
Sizing Accuracy vs. Phase
4x

Completed Size (DSI)

Programs + Cost ($)
2x USAF/ESD
Proposals
+
1.5x +
+ +

Relative 1.25x
+
Size +
x +
Range + +
+
+
+

+
0.5x

Product Detail
Concept of Rqts. Design Design Accepted
0.25x Spec. Spec.
Operation Spec. Software

Feasability Plans Product Detail Devel.

and Design Design and
Rqts. Test
Phases and Milestones
Software Cost Estimation
Methods

❚ Algorithmic Model
❚ Expert Judgment
❚ Analogy
❚ Parkinson
❚ Price-To-Win
❚ Top-Down
❚ Bottom-Up
Software Cost Estimation
Method -Algorithmic Model

❚ COCOMO II
Strengths Weaknesses
❚ Objective, repeatable, ❚ Subjective inputs
analyzable formula ❚ Assessment of
❚ Efficient, good for exceptional
sensitivity analysis circumstances
❚ Objectively calibrated ❚ Calibrated to past,
to experience not future
Software Cost Estimation
Method - Expert Judgment

Strengths Weaknesses
❚ Assessment of ❚ No better than
representativeness, participants
interactions, ❚ Biases, incomplete
exceptional recall
circumstances
Software Cost Estimation
Method - Analogy

Strengths Weaknesses
❚ Based on ❚ Representativeness of
representative experience
experience
Software Cost Estimation
Method - Parkinson

Strengths Weakness
❚ Correlates with some ❚ Reinforces poor
experience practice
Software Cost Estimation
Method - Price-To-Win

Strengths Weakness
❚ Often wins ❚ Generally produces
large overruns
Software Cost Estimation
Method - Top-Down

Strengths Weakness
❚ System level focus ❚ Less detailed basis
efficient ❚ Less stable
Software Cost Estimation
Method - Bottom-Up

Strengths Weakness
❚ More detailed basis ❚ May overlook system
❚ More stable level costs
❚ Fosters individual ❚ Requires more effort
commitment
 COCOMO Black Box Model

Software product size

estimate Software development,
maintenance cost and
Software product, process, computer, schedule estimates
and personnel attributes

Software reuse, maintenance, COCOMO II

and increment parameters Cost, schedule distribution by
Software organization’s phase, activity, increment
project data

COCOMO recalibrated
to organization’s data
COCOMO II Objectives

❚ Develop a 1990’s-2000’s software cost

model - Addressing new processes and
practices
❚ Retain COCOMO internal, external
openness
❚ Develop database, tool support for
continuous model improvement
❚ Support closed-loop quantitative project
management and process improvement
Future Software
Marketplace Sector

User programming
(55M performers in US in year 2005)
Application Application System
generators composition integration
(0.6M) (0.7M) (0.7M)

Infrastructure
(0.75M)
COCOMO 2.0 Coverage of
Future SW Practices Sectors

❚ User Programming: No need for cost model

❚ Applications Composition: Use object counts or object
points
- Count (weight) screens, reports, 3GL routines
❚ System Integration; development of applications
generators and infrastructure software
- Prototyping: Applications composition model
- Early design: Function Points and 7 cost drivers
- Post-architecture: Source Statements or Function
Points and 17 cost drivers
- Stronger reuse/reengineering model
Post-Architecture Model
Formulation

Effort (person-months) = A x (Size)B x ΠEMi

❚ where A is a constant derived from
calibration
❚ B = 1.01 + .01 x Σ SFi , where SFi is a
weighting factor for ith scale driver (5)
❚ EMi is the effort multiplier for the ith cost
driver (17)
Post-Architecture Model
Formulation

❚ Effort:
 

= A×(Size)(SF) × ∏EM
 
PM  

estimated 

 i i 



❚ Size
- KSLOC (Thousands of Source Lines of Code)
- UFP (Unadjusted Function Points)
- EKSLOC (Equivalent KSLOC) used for adaptation
❚ SF: Scale Factors (5)
❚ EM: Effort Multipliers (7 for ED, 17 for PA)
Scale Factors

B = 1.01 + 0.01 x ΣSFi

❚ Precedentedness (PREC)
❚ Development flexibility (FLEX)
❚ Architecture/risk resolution (RESL)
❚ Team cohesion (TEAM)
❚ Process maturity(PMAT)
Scale Factors
Scale Very Low Low Nominal High Very High Extra High
Factors (W i )
PREC thoroughly largely somewhat generally largely thoroughly
unprecedented unprecedented unprecedented familiar familiar familiar
FLEX rigorous occasional some general some general goals
relaxation relaxation conformity conformity
RESL little (20%) some (40%) often (60%) generally mostly full (100%)
(75%) (90%)
TEAM very difficultsome difficult basically largely highly seamless
interactions interactions cooperative cooperative cooperative interactions
interaction
PMAT weighted sum of KPA competition levels

• Precedentedness (PREC)
• Development flexibility (FLEX)
• Architecture/risk resolution (RESL)
• Team cohesion (TEAM)
• Process maturity(PMAT)
Post-Architecture EMs

❚ Product: RELY, DATA, DOCU, CPLX, RUSE

❚ Platform: TIME, STOR, PVOL
❚ Personnel: ACAP, AEXP, PCAP, PEXP,
LTEX, PCON
❚ Project: TOOL, SITE, SCED
Effort Multipliers - Product

Very Low Low Nominal High Very High Extra High

Required slight incon - low, easily moderate, high financial risk to human
Reliability venience recoverable easily loss life
(RELY) losses recoverable
losses
Database DB bytes/ 10ŠD/P< 100 100ŠD/P< D/P 1000
Size Pgm SLOC< 1000
(DATA) 10
Complexity see Complexity Table
(CPLX)
Required none across across across across
Reuse (RUSE) project program product line multiple
product lines
Documentation Many life - Some life - Right-sized Excessive for Very
Match to cycle needs cycle needs to life-cycle life-cycle excessive for
Lifecycle uncovered uncovered needs needs life-cycle
(DOCU) needs
Effort Multipliers - Platform

Very Low Low Nominal High Very High Extra High

Execution Š50% use of 70% 85% 95%
Time available
Constraint execution
(TIME) time
Main Š50% use of 70% 85% 95%
Storage available
Constraint storage
(STOR)
Platform major change major: 6 mo.; major: 2 mo.; major: 2 wk.;
Volatility every 12 mo.; minor: 2 wk. minor: 1 wk. minor: 2 days
(PVOL) minor change
every 1 mo.
Effort Multipliers -
Personnel

Very Low Low Nominal High Very High Extra High

Analyst 15th 35th 55th 75th 90th
Capability percentile percentile percentile percentile percentile
(ACAP)
Programmer 15th 35th 55th 75th 90th
Capability percentile percentile percentile percentile percentile
(PCAP)
Personnel 48%/year 24%/year 12%/year 6%/year 3%/year
Continuity
(PCON)
Application Š 2 months 6 months 1 year 3 years 6 years
Experience
(AEXP)
Platform Š 2 months 6 months 1 year 3 years 6 years
Experience
(PEXP)
Language Š 2 months 6 months 1 year 3 years 6 years
and Tool
Experience
(LTEX)
 Effort Multipliers - Project

Very Low Low Nominal High Very High Extra High

Use of edit, code, simple, basic strong, strong, mature,
Software debug frontend, lifecycle mature proactive
Tools (TOOL) backend tools, lifecycle lifecycle tools,
CASE, little moderately tools, well integrated
integration integrated moderately with processes,
integrated methods, reuse
Multisite International Multi-city Multi-city or Same city or Same building Fully
Development: and Multi - Multi - metro. area or complex collocated
Collocation company company
(SITE)
Multisite Some phone, Individual Narrowband Wideband Wideband elect. Interactive
Development: mail phone, FAX email electronic comm, multimedia
Communicati communica - occasional
ons (SITE) tion video conf.
Required 75% of 85% 100% 130% 160%
Development nominal
Schedule
(SCED)
Scale Factors

W(i) Very Low Low Nominal High Very High Extra High
Precedentedness 4.05 3.24 2.43 1.62 0.81 0.00
Development Flexibility 6.07 4.86 3.64 2.43 1.21 0.00
Architecture / Risk 4.22 3.38 2.53 1.69 0.84 0.00
Resolution
Team Cohesion 4.94 3.95 2.97 1.98 0.99 0.00
Process Maturity 4.54 3.64 2.73 1.82 0.91 0.00
Cost Drivers
Cost Rating
Very Low Low Nominal High Very High Extra High
RELY 0.75 0.88 1.00 1.15 1.39
DATA 0.93 1.00 1.09 1.19
CPLX 0.75 0.88 1.00 1.15 1.30 1.66
RUSE 0.91 1.00 1.14 1.29 1.49
DOCU 0.89 0.95 1.00 1.06 1.13
TIME 1.00 1.11 1.31 1.67
STOR 1.00 1.06 1.21 1.57
PVOL 0.87 1.00 1.15 1.30
ACAP 1.50 1.22 1.00 0.83 0.67
PCAP 1.37 1.16 1.00 0.87 0.74
PCON 1.24 1.10 1.00 0.92 0.84
AEXP 1.22 1.10 1.00 0.89 0.81
PEXP 1.25 1.12 1.00 0.88 0.81
LTEX 1.22 1.10 1.00 0.91 0.84
TOOL 1.24 1.12 1.00 0.86 0.72
SITE 1.25 1.10 1.00 0.92 0.84 0.78
SCED 1.29 1.10 1.00 1.00 1.00
Example - RELY

Required Software Reliability (RELY)

❚ Very Low : slight inconvenience
❚ Low : low, easily recoverable loses
❚ Nominal : moderate, easily recoverable
loses
❚ High : high financial loss
❚ Very High : risk to human life
Effect of Required
Reliability on Productivity
1.40

1.30

1.20

Low, easily 1.10

Slight recovered
inconvenience losses High Very High

Very Low Low High financial Risk to

.90 loss human life

.80

.70
Size

❚ 1. SLOC
❚ 2. Function points
- when little is known for SLOC estimation
- function point quantify the amount of
functionality in a software project
❚ 3. Adaptation
- reuse model
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)
AAF : Adaptation Adjustment Factor
DM : Percentage of Design Modified
CM : Percentage of Code Modified
IM : Percent of Integration Required for Modified
Software
COCOMO Reuse Model

❚ ESLOC = ASLOC[AA+AAF(1+0.02(SU)(UNFM))] / 100,

AAF <= 0.5
❚ ESLOC = ASLOC[AA + AAF(SU)(UNFM)]/100, AAF>0.5
AAF : Adaptation Adjustment Factor
ASLOC : Adapted Source Lines of Code
ESLOC : Equivalent Source Lines of Code
AA : Assessment and Assimilation effort
SU : Software Understanding
UNFM : Unfamiliarity
USC COCOMO Software
Status

❚ There is a initial version available for MS Windows,

SunOS, and Java
- Has new calibrated values
- Confidence ranges (optimistic, most likely, pessimistic)
- User definable Cost Drivers: USR1, USR2
- Schedule input is now project wide
- New reference manual
- New values can be manually input for all cost drivers
- Version changed to COCOMO II.199Y.X( Where Y is
the year and X is the version within that year)
Long Term Vision

❚ Produce model covering trade-offs among software cost,

schedule, functionality, performance, quality
❚ Enable the use of the model to scope projects and
monitor project progress
❚ Use the data from COCOMO-assisted management to
calibrate improved versions of COCOMO
❚ Use the data and improved COCOMO cost drivers to
enable affiliates to formulate and manage software
improvement investments.
Data collection

❚ Defined the data needed (to completely

describe the Post Architecture Model)
❚ Collected data with a paper form or a computer
software tool
❚ Affiliate Organizations provided majority of data
- Historical - whole project
❚ Site visits or phone interviews to record data
❚ Entered the data into the repository
❚ Did data consistency checking and conditioning
Information Sources

❚ E-mail: [email protected],
[email protected]
❚ URL:
http://sunset.usc.edu/COCOMOII/Cocomo.html
❚ Textbook: Barry Boehm, Software
Engineering Economics, Prentice-Hall,
1981
COCOMO Glossary

❚ EAF : Effort Adjustment Factor

❚ NOM PM : Nominal Person-Month
❚ EST PM : Estimated Person-Month
❚ PROD : Productivity
❚ INST COST : Instruction cost (cost/SLOC)
❚ FSWP : Full-time SoftWare Personnel