Schedule Estimation and Improvement
Barry Boehm, USC-CSSE
CS 577a, Fall 2013
12-20-2012
1
Outline
• Methods for schedule estimation
– Size and effort-based: CS 577b interpretation of COCOMO II effort
– Plan-based: critical-path analysis
– Cost-schedule tradespace analysis
• CORADMO Expedited Software Development Model
– RAD: Rapid Application Development
– Expedited Schedule Drivers
– Relation to RAD Opportunity Tree
• RAD Opportunity Tree elements reorganized around productprocess-project-people-risk factors determined in SERC
Expediting SE study
• Model calibrated to 12 agile project data points
• Case Study: From Plan-Driven to Agile
12-20-2012
2
Using COCOMO II in CS 577
• Begin with COCOMO II bottom-up team estimate
– Source lines of code (SLOC)
• Based on prototype sizing, % of functionality
• 250 SLOC, 25% of module functionality => 1000 SLOC module
• Easy to underestimate %; consider off-nominal cases
– Using adjustments to CS 577 below
– Focus on 577b Construction phase
• Cross-check with estimate
– Using Application Point or Fast Function Point sizing
– Effort by activity, rough 577b milestone plan
• Adjust, try to reconcile both estimates
©USC-CSSE
3
COCOMO II Estimates for 577b
• Disregard COCOMO II (CII) schedule estimates
• Use COCOMO II effort estimates to determine how large a team
needed for 12-week fixed schedule
– Assuming 12 hours/week of dedicated effort per person
– Assuming 10 of the 12 weeks fill COCOMO II Construction phase
(72% of total effort estimate)
– Assuming 100 hours/person-month for COCOMO estimates
• For 577b Construction phase, these are equivalent:
– 1 577b team member effort = (10 weeks)(12 hours/week) = 120 hrs
– 1.67*[est'd COCOMO II person month] = (1.67)(100 hours)(0.72) = 120 hrs
• So, one 577b team member effort = 1.67 COCOMO II PM's
• And 6 577b team members’ effort = 6*1.67 = 10 COCOMO II PM's
– 5 on-campus students + 1 off-campus student or equivalent
• Or, N COCOMO II PM's / 1.67 = N CS577b team members needed
©USC-CSSE
4
Outline
• Methods for schedule estimation
– Size and effort-based: CS 577b interpretation of COCOMO II effort
– Plan-based: critical-path analysis
– Cost-schedule tradespace analysis
• CORADMO Expedited Software Development Model
– RAD: Rapid Application Development
– Expedited Schedule Drivers
– Relation to RAD Opportunity Tree
• RAD Opportunity Tree elements reorganized around productprocess-project-people-risk factors determined in SERC
Expediting SE study
• Model calibrated to 12 agile project data points
• Case Study: From Plan-Driven to Agile
12-20-2012
5
Simple Software Development PERT Chart
Design,4
Requireme
nts,3
Start
Document,
2
Finish
Code,
4
Test data,2
Product
test, 4
Test plan,2
Test
drivers, 6
6
PERT chart development step1 and step2
Document,
2
Finish
Product
test, 4
7
PERT chart development step3
Document,
2
Finish
Code,
4
Product
test, 4
8
PERT chart development step4
Design,4
Document,
2
Finish
Code,
4
Test data,2
Product
test, 4
Test
drivers, 6
9
PERT chart development steps 5, 3, 4, 5, 3, 4, 5
Design,4
Requireme
nts,3
Document,
2
Finish
Code,
4
Test data,2
Product
test, 4
Test plan,2
Test
drivers, 6
10
Critical Path Procedure
1. Label the Start node (0, 0)
2. For all unlabeled nodes N whose predecessors are
all labeled nodes, compute the earliest possible start
time as the latest finishing time of all its predecessor
S N  max [ Fi ]
nodes
iP ( N )
where P(N) is the set of predecessor nodes of N
Compute the corresponding finish time FN=SN+DN
,where DN is the duration of activity N, Label the node
N as (SN, FN)
3. Repeat Step 2 until no unlabeled nodes remain.
11
Critical path determination after two iterations
(3, 7)
(0, 3)
(0, 0)
Requireme
nts,3
Start
Design,4
Document,
2
(3, 5)
Finish
Code,
4
Test data,2
Product
test, 4
(0, 2)
Test plan,2
(2, 8)
Test
drivers, 6
12
Critical path determination after five iterations
(7, 9)
(3, 7)
(0, 3)
Design,4
(7, 11)
(0, 0)
Requireme
nts,3
(3, 7)
(3, 5)
Code,
4
(7, 11)
Start
(0, 0)
(0, 3)
(3, 5)
(13, 15)
(11, 15)
(15, 15)
Finish
(15, 15)
Test data,2
(0, 2)
Test plan,2
Document,
2
(9, 11)
(2, 8)
Product
test, 4
(11, 15)
Test
drivers, 6
(5, 11)
13
Latest-Start Procedure
1. Underlabel the Finish node F with its start and finish times as
determined from the critical-path procedure, that is
(S’F, F’F) = ( SF, FF)
2. For all non-underlabeled nodes N whose successors are all
underlabeled nodes, compute the latest possible finish time as
the earliest starting
F '  time
min of
[ Sall
' ] its successor nodes.
N
iS ( N )
i
where S(N) is the set of successor nodes of N.
Compute the corresponding latest-start time
S’N =F’N - DN where DN is the duration of activity N, Underlabel
the node as (S’N, F’N) ,Compute the slack time for the activity
as
LN =S’N - SN (or LN =F’N - FN)
3. Repeat Step 2 until no non-underlabeled nodes remain.
14
Shortening the Critical Path
(6, 8)
(3, 6)
(0, 3)
Design,3
(6, 8)
(0, 0)
Requireme
nts,3
(3, 5)
Document,
2
(12, 12)
Finish
Code,
2
(8, 12)
Start
Test data,2
Product
test, 4
(0, 2)
Test plan,2
(2, 8)
Test
drivers, 6
15
Cost-Schedule Tradespace Analysis
• Generally, reducing schedule adds cost
– Pair programming: 60% schedule * 2 people = 120% cost
• Increasing schedule may or may not add cost
– Pre-planned smaller team: less communications overhead
– Mid-course stretchout: pay longer for tech, admin overhead
• Can often decrease both cost and schedule
– Lean, agile, value-based methods; product-line reuse
• Can optimize on schedule via concurrent vs. sequential processes
– Sequential; cost-optimized: Schedule = 3 * cube root (effort)
• 27 person-months: Schedule = 3*3=9 months; 3 personnel
– Concurrent, schedule-optimized: Schedule = square root (effort)
• 27 person-months: Schedule = 5.5 months; 5.4 personnel
• Can also accelerate agile square root schedule
– SERC Expediting SysE study: product, process, people, project, risk
10-22-2013
16
Outline
• Methods for schedule estimation
– Size and effort-based: CS 577b interpretation of COCOMO II effort
– Plan-based: critical-path analysis
– Cost-schedule tradespace analysis
• CORADMO Expedited Software Development Model
– RAD: Rapid Application Development
– Expedited Schedule Drivers
– Relation to RAD Opportunity Tree
• RAD Opportunity Tree elements reorganized around productprocess-project-people-risk factors determined in SERC
Expediting SE study
• Model calibrated to 12 agile project data points
• Case Study: From Plan-Driven to Agile
12-20-2012
17
RAD Opportunity Tree
Figure 3. The RAD Opportunity Tree
Also in SERC RT-20
Systems 2020 Report, Appendix B
Eliminating Tasks
Reducing time per task
Reducing risks of
single-point failures
Business process reengineering
Reusing assets
Applications generation
Design-to-schedule
Tools and automation
Work Streamlining (80-20)
Increasing parallelism
Reducing failures
Reducing their effects
Reducing backtracking
Early error elimination
Process anchor points
Improving process maturity
Collaboration technology
Activity network
streamlining
Minimizing task dependencies
Avoiding high fan-in, fan-out
Reducing task variance
Removing tasks from critical path
Increasing effective
workweek
24x7 development
Nightly builds, testing
Weekend warriors
Better people and incentives
Transition to learning organization
18
12-20-2012
4 Potential Critical Success Factors
Areas
Final Database
Over 30 Interviews with Gov’t/ Industry Rapid Development
Organizations
Over 23,500 words from interview notes
Product, Process, People … all in a Project Context
Product Factor Elements
• Product simplicity (of interfaces, legacy migration, -ilities)
– Very Low: Extremely complex; Extra High: Extremely simple
• Ability to reuse product elements
– Very Low: None; Extra High: 90%
• Ability to defer low-impact aspects
– Very Low: Never; Extra High: Anytime
• System definition via models vs. documents
– Very low: None; Extra High: 90%
• Technology maturity of key capabilities
– Very Low: >0 Level 1-2 or >1 Level 3; Extra High: All >Level 7
12-20-2012
20
Process Factor Elements
• Concurrency of OpCon, Rqts., Architecture, V&V
– Very Low: Highly sequential; Extra High: Fully concurrent
• Process streamlining
– Very Low: Heavily Bureaucratic; Extra High: Fully streamlined
• General SE tool support (coverage, integration, maturity: CIM)
– Very Low: Simple tools, weak CIM; Extra High: Very strong CIM
12-20-2012
21
Project Factor Elements
• Collaboration support
– Very Low: Globally distributed; weak communications, data
sharing
– Extra High: Largely collocated; very strong communications, data
sharing
• Single-domain models, methods, processes, tools (MMPTs)
– Very Low: Simple MMPTs, weak CIM; Extra High: Extensive CIM
• Multi-domain models, methods, processes, tools (MMPTs)
– Very Low: Simple MMPTs, weak CIM; Extra High: Extensive CIM
12-20-2012
22
People Factor Elements
• General-SE Knowledge, Skills, and Agility (KSA)
– Very Low: Very weak KSA; Extra High: Very strong KSA
• Single-domain Knowledge, Skills, and Agility (KSA)
– Very Low: Very weak KSA; Extra High: Very strong KSA
• Multi-domain Knowledge, Skills, and Agility (KSA)
– Very Low: Very weak KSA; Extra High: Very strong KSA
• Team compatibility
– Very Low: Very difficult interactions
– Extra High: Seamless interactions
12-20-2012
23
Risk Acceptance Factor
• Risk Acceptance
– Very Low: Highly risk-averse;
– Extra High: Strongly risk-accepting
12-20-2012
24
This motivated the development of CORADMO.
Its COCOMO II post-processor used a nominal
square-root relationship between PM and D,
completing a 27-PM project in 5.2 months with an
average team size of 5.2 people. It then adjusted the
The effort and schedule multipliers for these
factors were determined such that a well-jelled,
be
would
project
RAD
domain-experienced
estimated as 9 people on a 27-PM project for 3
months, but that a misguided RAD project would
CORADMO-SE Rating Scales, Schedule Multipliers
TABLE I. SCHEDULE A CCELERATORS AND R ATING FACTORS
Accelerators/Ratings
Product Factors
Simplicity
Element Reuse
Low-Priority
Deferrals
Models vs Documents
Key Technology
Maturity
Process Factors
Concurrent
Operational Concept,
Requirements,
Architecture, V&V
Process Streamlining
General SE tool
support CIM
(Coverage,
Integration, Maturity)
Project Factors
Project size (peak # of
personnel)
Collaboration support
Single-domain
MMPTs (Models,
Methods, Processes,
Tools)
Multi-domain
MMPTs
People Factors
General SE KSAs
(Knowledge, Skills,
Agility)
Single-Domain KSAs
Low
1.05
Highly
complex
None (0%)
Minimal (15%)
Some (30%)
Never
Rarely
Sometimes
Very High
0.92
Highly simple
Considerate
(70%)
Extra High
0.87
Extremely
simple
Extensive
(90%)
Often
Usually
Anytime
Considerate
(70%)
Extensive
(90%)
1-2 TRL 6
All > TRL 7
0.92
0.87
None (0%)
Minimal (15%)
Some (30%)
>0 TRL 1,2 or
>1 TRL 3
1.09
1 TRL 3 or > 1
TRL 4
1.05
1 TRL 4 or > 2
TRL 5
1.0
Highly
sequential
Mostly
sequential
2 artifacts
mostly
concurrent
3 artifacts
mostly
concurrent
All artifacts
mostly
concurrent
Fully
concurrent
Heavily
bureaucratic
Largely
bureaucratic
Conservative
bureaucratic
Moderate
streamline
Mostly
streamlined
Fully
streamlined
Simple tools,
weak
integration
Minimal CIM
Some CIM
Moderate CIM
Considerable
CIM
Extensive CIM
1.08
1.04
1.0
0.96
0.93
0.9
Over 300
Over 100
Over 30
Over 10
Over 3
≤ 3
Nationally
distributed,
some sharing
Regionally
distributed,
moderate
sharing
Metro-area
distributed,
good sharing
Simple
campus,
strong sharing
Largely
collocated,
Very strong
sharing
Minimal CIM
Some CIM
Moderate CIM
Considerable
CIM
Extensive CIM
Globally
distributed
weak comm. ,
data sharing
Simple
MMPTs,
weak
integration
Simple; weak
integration
1.13
Minimal CIM
1.06
Weak KSAs
Some KSAs
Weak
Some
Weak
Some
Team Compatibility
Very difficult
interactions
Some difficult
interactions
1.13
Highly riskaverse
1.06
Partly riskaverse
12-20-2012
Mod. complex
High
0.96
Moderately
simple
Moderate
(50%)
Moderate
(50%)
1-2 TRL 5 or
>2 TRL 6
0.96
Multi-Domain KSAs
Risk Acceptance Factor
Nominal
1.0
Very Low
1.09
Extremely
complex
Some CIM or
not needed
1.0
Moderate
KSAs
Moderate
Moderate or
not needed
Basically
cooperative
interactions
1.0
Balanced risk
aversion,
acceptance
Moderate CIM
0.94
Considerable
CIM
0.89
Extensive CIM
0.84
Good KSAs
Strong KSAs
Very strong
KSAs
Good
Strong
Very strong
Good
Strong
Very strong
Largely
cooperative
Highly
cooperative
Seamless
interactions
0.94
Moderately
risk-accepting
0.89
Considerably
risk-accepting
0.84
Strongly riskaccepting
25
in project staff sizes is the primary reason for the
varying Project ratings. The staff was described as
research.
CORADMO-SE Calibration Data
TABLE II. COMMERCIAL
PROJECTS RATING FACTORS ANDSome
ANALYSIS
Mostly
Commercial;
DoD
Person Duration Duration
Multi- Error
Product Process Project People Risk
Months (Months) / √PM
plier
%
Application Type
Technologies
Insurance agency system
HTML/VB
34.94
3.82
0.65
VH
VH
XH
VH
N
0.68
5%
Scientific/engineering
C++
18.66
3.72
0.86
L
VH
VH
VH
N
0.80
-7%
Compliance - expert
HTML/VB
17.89
3.36
0.79
VH
VH
XH
VH
N
0.68
-15%
Barter exchange
SQL/VB/ HTML
112.58
9.54
0.90
VH
H
H
VH
N
0.75
-16%
Options exchange site
HTML/SQL
13.94
2.67
0.72
VH
VH
XH
VH
N
0.68
-5%
Commercial HMI
C++
205.27
13.81
0.96
L
N
N
VH
N
0.93
-3%
Options exchange site
HTML
42.41
4.48
0.69
VH
VH
XH
VH
N
0.68
-1%
Time and billing
C++/VB
26.87
4.80
0.93
L
VH
VH
VH
N
0.80
-14%
70.93
8.62
1.02
L
N
VH
VH
N
0.87
-15%
9.79
1.39
0.44
VH
VH
XH
VH
N
0.68
53%
Hybrid Web/client-server VB/HTML
ASP
HTML/VB/SQL
On-line billing/tracking
VB/HTML
17.20
2.70
0.65
VH
VH
XH
VH
N
0.68
4%
Palm email client
C/HTML
4.53
1.45
0.68
N
VH
VH
VH
N
0.76
12%
12-20-2012
26
Outline
• Methods for schedule estimation
– Size and effort-based: CS 577b interpretation of COCOMO II effort
– Plan-based: critical-path analysis
– Cost-schedule tradespace analysis
• CORADMO Expedited Software Development Model
– RAD: Rapid Application Development
– Expedited Schedule Drivers
– Relation to RAD Opportunity Tree
• RAD Opportunity Tree elements reorganized around productprocess-project-people-risk factors determined in SERC
Expediting SE study
• Model calibrated to 12 agile project data points
• Case Study: From Plan-Driven to Agile
12-20-2012
27
ised
s in
hes.
s a
in
ense
ally
eers
d a
e a
and
fies
apid
n to
sion
The
this
hich
s a
e of
a
,
the
the
pert
d to
ings
single-domain KSAs (H); good multiple-domain
KSAs (H); but some difficult team interactions (L).
Case Study: From Plan-Driven to Agile
TABLE III. AS-IS RATING F ACTORS
Accelerators/Ratings
Product Factors
Simplicity
Element Reuse
Low-Priority Deferrals
Models vs Documents
Key Technology
Maturity
Process Factors
Concurrent Operational
Concept, Requirements,
Architecture, V&V
Process Streamlining
General SE tool support
CIM (Coverage,
Integration, Maturity)
Project Factors
Project size (peak # of
personnel)
Collaboration support
Single-domain MMPTs
(Models, Methods,
Processes, Tools)
Multi-domain MMPTs
People Factors
General SE KSAs
(Knowledge, Skills,
Agility)
Single-Domain KSAs
Multi-Domain KSAs
Team Compatibility
Risk Acceptance Factor
12-20-2012
VL
1.09
L
1.05
N
1.0
X
H
0.96
VH
0.92
XH
0.87
X
X
X
X
1.09
1.05
1.0
0.96
0.92
0.87
0.93
0.9
0.89
0.84
0.89
0.84
X
X
X
1.08
1.04
1.0
0.96
X
X
X
1.13
X
1.06
1.0
0.94
X
X
X
1.13
1.06
1.0
X
X
0.94
28
Case Study: From Plan-Driven to Agile
Initial Project: Focus on Concurrent SE
H
organ
was
perfo
found
concu
poten
W
proje
overa
oppo
SE s
as th
proje
multi
effec
seque
proce
IV:
·
TABLE IV. INITIAL T O-BE RATING FACTORS
Accelerators/Ratings
Product Factors
Simplicity
Element Reuse
Low-Priority Deferrals
Models vs Documents
Key Technology
Maturity
Process Factors
Concurrent Operational
Concept, Requirements,
Architecture, V&V
Process Streamlining
General SE tool support
CIM (Coverage,
Integration, Maturity)
Project Factors
Project size (peak # of
personnel)
Collaboration support
Single-domain MMPTs
(Models, Methods,
Processes, Tools)
Multi-domain MMPTs
People Factors
General SE KSAs
(Knowledge, Skills,
Agility)
Single-Domain KSAs
Multi-Domain KSAs
Team Compatibilit y
Risk Acceptance Factor
VL
1.09
L
1.05
N
1.0
X
H
0.96
VH
0.92
XH
0.87
0.96
0.92
0.87
0.93
0.9
0.89
0.84
0.89
0.84
X
X
X
X
1.09
1.05
1.0
X
X
X
1.08
1.04
1.0
0.96
X
X
X
1.13
X
1.06
1.0
0.94
X
X
X
1.13
1.06
X
1.0
X
0.94
The divisions approach to risk is evenly balanced
between risk-aversion and risk acceptance, leading
to a nominal rating (N) and no effect on the
schedule.
The selected ratings result in the following factor
multiplier
values,
which
calculates
an
overall
acceleration factor of 1.01, suggesting the division’s
approach will result in a schedule duration close to
the nominal case:
Expected schedule reduction of 1.09/0.96 = 0.88 (green arrow)
Actual schedule delay of 15% due to side effects (red arrows)
Model prediction: 0.88*1.09*1.04*1.06*1.06 = 1.13
12-20-2012
29
·
·
tered
with
tiative, and
g a goal of
ative given
y preparing
tors whose
values (the
g aware of
ng positive
e an overall
*1.06=1.29.
trated with
ong
with
Concept,
activities,
m High, for
nd external
be at least
edup factor
e resulting
would
be
up of 23%
is schedule
improving
y remaining
her factors,
This is encouraging, but it is unknown to what
extent the model will accurately describe projects
outside this limited set. We are in the process of
collecting additional data points over a wider variety
Case Study: From Plan-Driven to Agile
Next Project: Fix Side Effects; Reduce Bureaucracy
TABLE V. FINAL TO -BE RATING F ACTORS
Accelerators/Ratings
Product Factors
Simplicity
Element Reuse
Low-Priority Deferrals
Models vs Documents
Key Technology
Maturity
Process Factors
Concurrent Operational
Concept, Requirements,
Architecture, V&V
Process Streamlining
General SE tool support
CIM (Coverage,
Integration, Maturity)
Project Factors
Project size (peak # of
personnel)
Collaboration support
Single-domain MMPTs
(Models, Methods,
Processes, Tools)
Multi-domain MMPTs
People Factors
General SE KSAs
(Knowledge, Skills,
Agility)
Single-Domain KSAs
Multi-Domain KSAs
Team Compatibilit y
Risk Acceptance Factor
VL
1.09
L
1.05
N
1.0
X
H
0.96
VH
0.92
XH
0.87
X
X
X
X
1.09
1.05
1.0
0.96
0.92
0.87
X
X
X
1.08
1.04
1.0
0.96
0.93
0.9
0.89
0.84
0.89
0.84
X
X
X
1.13
X
1.06
1.0
0.94
X
X
X
1.13
1.06
1.0
X
X
0.94
Model estimate: 0.88*(0.92/0.96)*(0.96/1.05) = 0.77 speedup
Project results: 0.8 speedup
Model tracks project status; identifies further speedup potential
12-20-2012
30
Outline
• Methods for schedule estimation
– Size and effort-based: CS 577b interpretation of COCOMO II effort
– Plan-based: critical-path analysis
– Cost-schedule tradespace analysis
• CORADMO Expedited Software Development Model
– RAD: Rapid Application Development
– Expedited Schedule Drivers
– Relation to RAD Opportunity Tree
• RAD Opportunity Tree elements reorganized around productprocess-project-people-risk factors determined in SERC
Expediting SE study
• Model calibrated to 12 agile project data points
• Case Study: From Plan-Driven to Agile
12-20-2012
31