Transcript SW Economics & COCOMO II November 25, 2005 Jongmoon Baik, Ph.D. School of Engineering Information and Communications University.

SW Economics & COCOMO II
November 25, 2005
Jongmoon Baik, Ph.D.
School of Engineering
Information and Communications University
What is Software Economics?
“Software Economics is the study of how scarce
project resources are allocated for software projects”
Psychology
Organizational Behavior
Social Psychology
Software
Economics
Statistics
Economics
Software Development
http://www.softwaremetrics.com/se.htm
Information and Communications University
2
Macro vs. Micro Economics

Macro economics
 SE supports a commercial S/W sector that
earns $200B to $240B in US
 SE drove $1T of economic growth in US

Micro economics
 About ¼ of software projects are delivered
successfully
 Commercial developers typically write 12K
lines of code per year
 Government developers typically write 1.5K
lines of code per year
Information and Communications University
3
Software Economics Roadmap

Goal
 Develop fundamental knowledge to enable
significant measurable increases in the
value created over time

Better decision making:
 Key enabler of greater value added
 In richer design spaces
Information and Communications University
4
Current Issues in SEE

Global Software Economics

Free (Open) Software Economics

etc.
Information and Communications University
5
Why is it important to Software Cost??

Software cost is big and growing

Many useful software products are not
getting developed

Get us better software not just more
software
Boehm et. Al, “Understanding and Controlling Software Cost”, IEEE
TSE, SE4, 10, pp1462-77
Information and Communications University
6
WHAT IS COCOMO?
Beach Boys – KoKoMo (1988)
Information and Communications University
7
WHAT IS COCOMO?
“COCOMO (COnstructive COst
MOdel)” is a model designed by
Barry Boehm to give an estimate
of the number of programmermonths it will take to develop a
software product.”
- Wikipedia, the free encyclopedia -
Information and Communications University
8
Software Estimation Techniques
Software Estimation Techniques
Information and Communications University
9
Software Cost Estimation Steps
1.
Establish Objectives



2.
3.
Allocate Enough Time, Dollars, Talent
Pin down Software Requirements

4.
5.
Top-Down vs. Bottom-Up
Algorithm Vs. Expert-Judgement
Compare and iterate estimates


7.
Documents Definition, Assumption
Work out as much detail as Objectives permit
Use several independent Techniques + Sources


6.
Rough Sizing
Make-or-Buy
Detailed Planning
Pin down and resolve inconsistencies
Be Conservative
Follow up
Information and Communications University
10
COCOMO II Overview - I





COCOMO II Baseline Overview
Application Composition Model
Sizing Methods (SLOC & UFP)
Early Design & Post Architecture Models
Software Reuse Model
Information and Communications University
11
COCOMO II Overview - II
Software development,
maintenance cost and
schedule estimates
Software product size estimate
Software product, process,
computer, and personnel attributes
COCOMO II
Cost, schedule distribution
by phase, activity,
increment
Software reuse, maintenance,
and increment parameters
Software organization’s
project data
COCOMO recalibrated
to organization’s
data
Information and Communications University
12
COCOMO II Overview - III

Open interfaces and internals
 Published in Software Cost Estimation with
COCOMO II, Boehm et. al., 2000
• COCOMO – Software Engineering Economics ,
Boehm, 1981

Numerous Implementation, Calibrations,
Extensions
 Incremental Development, Ada, new
environment technology
 Arguably the most frequently-used software
cost model worldwide
Information and Communications University
13
COCOMO II User Objectives

Making investment or other financial decisions involving a software
development

Setting project budgets and schedules as a basis for planning and control

Deciding on or negotiating tradeoffs among software cost, schedule,
functionality, performance or quality factors

Making software cost and schedule risk management decisions

Deciding which parts of a software system to develop, reuse, lease or
purchase

Making legacy software inventory decisions: what parts to modify, phase
out, outsource, etc.

Setting mixed investment strategies to improve your organization’s
software capability, via reuse, tools, process maturity, outsourcing, etc.

Deciding how to implement a process improvement strategy
Information and Communications University
14
COCOMO II Objectives

Provide accurate cost and schedule estimates for both current and
likely future software projects.

Enabling organizations to easily recalibrate, tailor or extend
COCOMO II to better fit their unique situations.

Provide careful, easy-to-understand definition of the model’s inputs,
outputs and assumptions.

Provide constructive model.

Provide a normative model.

Provide evolving model.
Information and Communications University
15
S/W Estimation Accuracy vs. Phase
4x
Completed
Programs
2x
+
Size (DSI)
Cost ($)
USAF/ESD
Proposals
+
1.5x
Relative
Size
Range
+
+
+
1.25x
+
+
+
+
x
+
+
+
+
+
0.5x
Concept of
Operation
0.25x
Feasibility
Plans
and
Rqts.
Product
Design
Spec.
Rqts.
Spec.
Product
Design
Detail
Design
Spec.
Detail
Design
Phases and Milestones
Accepted
Software
Devel.
and
Test
“Corn of Software Cost Estimation”
Information and Communications University
16
MBASE/Rational Anchor Point Milestones
App.
Compos.
Inception
LCO,
LCA
SRR
Sys
Devel
Transition
Elaboration, Construction
Waterfall
Rqts.
Inception
Phase
LCO
IOC
SAT
PDR
Prod. Des.
Development
Elaboration
Construction
LCA
Information and Communications University
Trans.
IOC
17
Application Composition Model

Challenge:
 Modeling rapid application composition with
graphical user interface (GUI) builders,
client-server support, object-libraries, etc.

Responses:
 Application-Point Sizing and Costing Model
 Reporting estimate ranges rather than point
estimate
Information and Communications University
18
Application Point Estimation Procedure
Step 1: Assess Element-Counts: estimate the number of screens, reports, and 3GL components that will comprise this
application. Assume the standard definitions of these elements in your ICASE environment.
Step 2: Classify each element instance into simple, medium and difficult complexity levels depending on values of
characteristic dimensions. Use the following scheme:
For Screens
For Reports
# and source of data tables
Number of
Views
Contained
Total < 4
(<2 srvr, <3
clnt)
Total <8
(<3 srvr, 3
5 clnt)
# and source of data tables
-
Total 8+
(>3 srvr, >5
clnt)
Number
of Sections
Contained
Total < 4
(<2 srvr, <3
clnt)
Total <8
(<3 srvr, 3
5 clnt)
-
Total 8+
(>3 srvr, >5
clnt)
<3
simple
simple
medium
0 or 1
simple
simple
medium
3-7
simple
medium
difficult
2 or 3
simple
medium
difficult
medium
difficult
difficult
4+
medium
difficult
difficult
>8
Step 3: Weigh the number in each cell using the following scheme. The weights reflect the relative effort required to
implement an instance of that complexity level.
Element Type
Screen
Report
3GL Component
Simple
1
2
Complexity-Weight
Medium
Difficult
2
3
5
8
10
Step 4: Determine Application-Points: add all the weighted element instances to get one number, the Application-Point count.
Step 5: Estimate percentage of reuse you expect to be achieved in this project. Compute the New Application Points to be
developed NAP =(Application-Points) (100-%reuse) / 100.
Step 6: Determine a productivity rate, PROD=NAP/person-month, from the following scheme:
Developer's experience and capability
ICASE maturity and capability
Very Low
Low
Nominal
High
Very High
Very Low
Low
Nominal
High
Very High
7
13
25
PROD
4
Step 7: Compute the estimated person-months: PM=NAP/PROD.
Information and Communications University
50
19
Sizing Methods

Counting Source Lines of Code (SLOC)
 SEI Definition Check List

Counting Unadjusted Function Points
(UFP)
 IFPUG
Information and Communications University
20
Source Lines of Code





Best Source : Historical data form previous projects
Expert-Judged Lines of Code
Expressed in thousands of source lines of code
(KSLOC)
Difficult Definition – Different Languages
COCOMO II uses Logical Source Statement
 SEI Source Lines of Code Check List
 Excludes COTS, GFS, other products, language
support libraries and operating systems, or other
commercial libraries
Information and Communications University
21
SEI Source Lines of Code Checklist
Information and Communications University
22
Unadjusted Function Points - I



Based on the amount of functionality in a
software project and a set of individual
project factors.
Useful since they are based on
information that is available early in the
project life-cycle.
Measure a software project by quantifying
the information processing functionality
associated with major external data or
control input, output, or file types.
Information and Communications University
23
Unadjusted Function Points - II
Step 1. Determine function counts by type. The unadjusted function point counts should be counted by a lead technical person based on
information in the software requirements and design documents. The number of each the five user function types should be counted
(Internal Logical File (ILF), External Interface File (EIF), External Input (EI), External Output (EO), and External Inquiry (EQ)).
Step 2. Determine complexity-level function counts. Classify each function count into Low, Average, and High complexity levels
depending on the number of data element types contained and the number of file types reference. Use the following scheme.
For EO and EQ
F o r IL F a n d E IF
Rec o rd
Elem en ts
Data Elem en ts
File Ty p es
1 -1 9
2 0 -5 0
51+
1
Low
Low
Avg
2 -5
Low
Avg
6+
Avg
H ig h
For EI
Data Elem en ts
File Ty p es
1 -5
6 -1 9
20+
0 or 1
Low
Low
Avg
H ig h
2 -3
Low
Avg
H ig h
4+
Avg
H ig h
Data Elem en ts
1 -4
5 -1 5
16+
0 or 1
Low
Low
Avg
H ig h
2 -3
Low
Avg
H ig h
H ig h
4+
Avg
H ig h
H ig h
Step 3. Apply complexity weights. Weight the number in each cell using the following scheme. The weight reflect the relative value of
the function to the user.
Fu n c tio n Ty p e
C o m p le x ity W e ig h t
Low
A v e ra g e
H ig h
In te rn a l L o g ic a l F ile (IL F )
7
10
15
E x te rn a l In te rfa c e F ile s (E IF )
5
7
10
E x te rn a l In p u ts (E I)
3
4
6
E x te rn a l O u tp u ts
4
5
7
E x te rn a l In q u irie s
3
4
6
Step 4. Compute Unadjusted Function Points. Add all the weight functions counts to get one number, the Unadjusted Function Points.
Information and Communications University
24
Relating UFPs to SLOC

USC-COCOMO II
 Use conversion table (Backfiring) to convert UFPS into
equivalent SLOC
 Support 41 implementation languages and USR1-5 for
accommodation of user’s additional implementation
languages
 Additional Ratios and Updates :
http://www.spr.com/library/0Langtbl.htm
Language
S LO C /U FP
A ccess
A da 83
A da 95
38
71
49
.
.
.
.
Language
S LO C /U FP
Jovial
Lisp
M achine C o de
107
64
640
.
.
U S R _1
U S R _2
1
1
.
.
.
.
.
.
Information and Communications University
25
Early Design & Post-Architecture Models
A = 2.94
B = 0.91
C = 3.67
D = 0.28
• Early Design Model [6 EMs]:
• Post Architecture Model [16 EMs]:
*Exclude SCED driver
EMs: Effort multipliers to reflect characteristics of particular
software under development
A : Multiplicative calibration variable
E : Captures relative (Economies/Diseconomies of scale)
SF: Scale Factors
Information and Communications University
26
Scale Factors & Cost Drivers

Project Level – 5 Scale Factors
 Used for both ED & PA models

Early Design – 7 Cost Drivers

Post Architecture – 17 Cost Drivers
 Product, Platform, Personnel, Project
Information and Communications University
27
Project Scale Factors - I

Relative economies or diseconomies of scale
 E < 1.0 : economies of scale
• Productivity increase as the project size increase
• Achieved via project specific tools (e.g., simulation, testbed)
 E = 1.0 : balance
• Linear model : often used for cost estimation of small projects
 E > 1.0 : diseconomies of scale
• Main factors : growth of interpersonal communication overhead
and growth of large-system overhead
Information and Communications University
28
Project Scale Factors - II
S c ale F ac to r s
(S F i )
V er y L o w
Low
N o m in al
H ig h
V er y H ig h
E x tr a H ig h
PREC
th o ro u g h ly
u n p reced en te
d
6 .2 0
larg ely
u n p reced en te
d
4 .9 6
so m ew h at
u n p reced en te
d
3 .7 2
g en erally
fam iliar
larg ely
fam iliar
th ro u g h ly
fam iliar
2 .4 8
1 .2 4
0 .0 0
rig o ro u s
o ccasio n al
relax atio n
so m e
relax atio n
g en eral
co n fo rm ity
so m e
co n fo rm ity
g en eral g o als
5 .0 7
4 .0 5
3 .0 4
2 .0 3
1 .0 1
0 .0 0
little (2 0 % )
so m e (4 0 % )
o ften (6 0 % )
m o stly (9 0 % )
fu ll (1 0 0 % )
7 .0 7
5 .6 5
4 .2 4
g en erally (7 5
%)
2 .8 3
1 .4 1
0 .0 0
v ery d ifficu lt
in teractio n s
so m e d ifficu lt
in teractio n s
b asically
co o p erativ e
in teractio n s
larg ely
co o p erativ e
h ig h ly
co o p erativ e
seam less
in teractio n s
5 .4 8
4 .2 8
3 .2 9
2 .1 9
1 .1 0
0 .0 0
S W -C M M
L ev el 1
L o w er
S W -C M M
L ev el 1
U p p er
S W -C M M
L ev el 2
S W -C M M
L ev el 3
S W -C M M
L ev el 3
S W -C M M
L ev el 5
FLEX
RESL
TEAM
PMAT
O r th e E stim ated P ro cess M atu rity L ev el (E P M L )
7 .8 0
6 .2 4
4 .6 8
3 .1 2
Information and Communications University
1 .5 6
0 .0 0
29
COCOMO II Effort Multipliers
Product:
Platform:
RELY, DATA, RUSE,
DOCU, CPLX
TIME, STOR, PVOL
Personnel:
Project:
PCAP, ACAP, PCON,
APEX, LTEX, PLEX
TOOL, SITE, SCED
Information and Communications University
30
ED EMs vs. PA EMs
Early Design Cost
Driver
Counterpart Combined
Post-Architecture Cost Drivers
RCPX
RELY, DATA, CPLX, DOCU
RUSE
RUSE (Same as P-A RUSE)
PDIF
TIME, STOR, PVOL
PERS
ACAP, PCAP, PCON
PREX
APEX, PLEX, LTEX
FCIL
TOOL, SITE
SCED
SCED (Same as P-A SCED)
Information and Communications University
31
Life Cycle Phases
C O C O M O II E s tim a tio n E n d p o in ts
I
R
R
M B A S E /R U P
L
C
O
In ce p tio n
L
C
R
M o st like ly
m o d e l to u se :
C o n stru ctio n
P re lim in a ry
(P ro d u ct) D e sig n
D e ta ile d
D e sig n
P
D
R
S
R
R
E a rly D e s ig n M o d e l
P
R
R
I
O
C
E la b o ra tio n
P la n s a n d
R e q u ire m e n ts
W a te rfa ll
L
C
A
T ra n sitio n
C o d e a n d In te g ra tio n
U n it T e st
a n d T e st
C
D
R
U
T
C
S
A
R
P o s t-A rc h ite c tu re M o d e l
Information and Communications University
32
Waterfall Phase Distribution
Information and Communications University
33
Software Reuse
Information and Communications University
34
Reuse & Product Line Mgmt.

Challenges
- Estimate costs of both reusing software and
developing software for future reuse
- Estimate extra effects on schedule (if any)

Responses
- New nonlinear reuse model for effective size
- Cost of developing reusable software estimated
by RUSE effort multiplier
- Gathering schedule data
Information and Communications University
35
Non-Linear Reuse Effect
A A M W o rs t C a s e :
A A F = 0 .5
AA = 8
SU = 50
UNFM = 1
1 .5
AAM
A A M B est C ase:
A A F = 0 .5
AA = 0
SU = 10
UNFM = 0
1 .0
R elative C o st
S e lb y d a ta
s u m m a ry
0 .5
[S e lb y 1 9 8 8 ]
0 .0 4 5
0 .0
50
100
R e la tiv e M o d ific a tio n o f S iz e (A A F )
Information and Communications University
36
COCOMO II Reuse Model

Add Assessment & Assimilation increment (AA)
 - Similar to conversion planning increment

Add software understanding increment (SU)
 - To cover nonlinear software understanding effects
 - Coupled with software unfamiliarity level (UNFM)
 - Apply only if reused software is modified
Information and Communications University
37
Software Understanding
SU
V ery L o w
Low
N o m i n al
Hig h
V er y H i g h
M o d erately lo w
co h esio n , h igh
co u p lin g.
R easo n ab ly w ellstru ctu red ; so m e
w eak areas.
H igh co h esio n , lo w
co u p lin g.
S tru c tu re
V ery lo w co h esio n ,
h igh co u p lin g,
sp agh etti co d e.
S tro n g m o d u larity,
in fo rm atio n h id in g
in d ata / co n tro l
stru ctu res.
N o m atch b etw een
p ro gram an d
ap p licatio n w o rld v iew s.
S o m e co rrelatio n
b etw een p ro gram
an d ap p licatio n .
M o d erate
co rrelatio n b etw een
p ro gram an d
ap p licatio n .
G o o d co rrelatio n
b etw een p ro gram
an d ap p licatio n .
C lear m atch
b etw een p ro gram
an d ap p licatio n
w o rld -v iew s.
S e lf-D e s c rip tiv e ness
O b scu re co d e;
d o cu m en tatio n
m issin g, o b scu re o r
o b so lete
S o m e co d e
co m m en tary an d
h ead ers; so m e
u sefu l
d o cu m en tatio n .
M o d erate lev el o f
co d e co m m en tary,
h ead ers,
d o cu m en tatio n .
G o o d co d e
co m m en tary an d
h ead ers; u sefu l
d o cu m en tatio n ;
so m e w eak areas.
S elf-d escrip tiv e
co d e;
d o cu m en tatio n u p to -d ate, w ello rgan iz ed , w ith
d esign ratio n ale.
S U In c re m e n t to
ESLO C
50
40
30
20
10
A p p lic a tio n
C la rity
Information and Communications University
38
Assessment and Assimilation (AA)
Level of A A Effort
A A Increm ent
0
N one
2
B asic m odule search and docum entation
4
S om e m odule T est and E valuation (T & E ), docum entation
6
C onsiderable m odule T & E , docum entation
8
E xtensive m odule T & E , docum entation
Information and Communications University
39
Unfamiliarity (UNFM)
U N FM Increm ent
Level of U nfam iliarity
0.0
C om pletely fam iliar
0.2
M ostly fam iliar
0.4
S om ew hat fam iliar
0.6
C onsiderably fam iliar
0.8
M ostly unfam iliar
1.0
C om pletely unfam iliar
Information and Communications University
40
Guidelines for Quantifying Adapted Software
Code
C ateg o r y
DM
CM
N ew
- all original
softw are
A dapted
- changes to
preexisting
softw are
R eused
- unchanged
existing
softw are
COTS
- off-the-shelf
softw are (often
requires new
glue code as a
w rapper around
the C O T S )
IM
AA
SU
UNFM
0% – 8%
0% - 50%
0-1
not applicable
+
0% - 100%
norm ally > 0%
0 % - 100%
usually > D M
and m ust be >
0%
0%
0%
0%
0%
0% - 100+ %
IM usually
m oderate and
can be > 100%
0% - 100%
rarely 0% , but
could be very
sm all
0% - 100%
0% – 8%
not applicable
0% – 8%
not applicable
Information and Communications University
41
Requirement Evolution & Volatility (REVL)

Adjust the effective size of the product
 Causal factors: user interface evolution,
technology upgrades, or COTS volatility

Percentage of code discarded due to
requirement evolution
 E.g., SLOC = 100K and REVL = 20
• Project effective size = 120K
Information and Communications University
42
USC-COCOMO II.2000 Demo.
Information and Communications University
43
Further Information

Book
 Software Cost Estimation with COCOMO II

USC-CSE
 http://sunset.usc.edu

Jongmoon Baik
 E-mail: [email protected]
 Phone: 042-866-6170
Information and Communications University
44