74
www.construx.com Seven Diagrams Every Software Developer Should Understand
www.construx.com
Seven Diagrams Every
Software Developer
Should Understand
Also Known As
“How Not to be Surprised in
Software Development”
Copyright Notice
These materials are © 1996-2014 Construx Software Builders,
Inc.
All Rights Reserved. No part of the contents of this seminar
may be reproduced or transmitted in any form or by any
means without the written permission of Construx Software
Builders, Inc.
Introduction
5 Construx®
How Not to Be Surprised in Software Development
My Background
300 books and articles?
600 books and articles!
Another 300 books
and articles!
Another ~1000 papers,
of which only 250
were publishable
<sigh>
6 Construx®
I did not work as hard on my next book,
Software Project Survival Guide …
A History of
Attempts to Explain
Software
Development
8 Construx®
A Long Line of Attempts to Explain
Software Development
9 Construx®
Why do we Need to Help People
Understand Software Engineering?
10 Construx®
Why do we Need to Help Other People
Understand Software Engineering? (cont.)
“… they had just two weeks to test the site before all
the pieces from several contractors had to work
together the day of the launch.”
“We all know we were working under a compressed
time frame to launch this on Oct. 1”
“Determining many of the problems the system would
have after the various parts were integrated was
difficult until the site actually went online, Bataille
said. It was the agency’s responsibility to make sure
all the parts worked together.”
“According to one specialist, the Web site contains
about 500 million lines of software code. By
comparison, a large bank’s computer system is
typically about one-fifth that size.”
“The technology is there to do that. It just
requires foresight.”
11 Construx®
Latest Attempt to Explain Software Development
Software
Engineering
Essentials Lecture Series
CxLearn.com
12 Construx®
The Goal
Help software professionals develop mental
models and frameworks to understand and
improve their software projects, to understand
the context for current software practices,
and to evaluate new developments in
software engineering.
Talk Roadmap
14 Construx®
Roadmap for This Talk
Introduce four core influences
Highlight seven key diagrams
Introduce many other diagrams
that are also informative
What’s the benefit of that? Candidate
Top 7 Diagram
Four Core Software
Influences
16 Construx®
Four Core Influences
SIZE (diseconomy of scale; failure rate; specializations; mix of activities)
UNCERTAINTY (intellectual phases; cone of uncertainty; feature
staircase vs. feature buildup; risk management; effort vs. certainty curve)
DEFECTS (DCI, defect detection lag, defect removal techniques in
series, relationship to process stability)
HUMAN VARIATION (effect on research; effect on selection of
methods (familiar vs. unfamiliar); effect on team composition, team
cohesion, recruiting, and retention; focus on perfect execution vs. perfect
plans; implication for favoring robust methods)
Core Influence:
Size
18 Construx®
Which “Size” Diagrams Are Most Informative?
We have many informative diagrams. Which really
explains the essence of Size in Software?
Team Size
Pro
du
ctiv
ity
1 ~7 ~50 ~250-350
Ou
tpu
t
19
Diseconomy of Scale (Fred Brooks)
Efficiency is an N2 function of the number of
people on the project due to communication
paths: N*(N-1)/2
1 person =
0 paths
2 people =
1 path
3 people =
3 paths
4 people =
6 paths
5 people =
10 paths
20
Diseconomy of Scale (Larry Putnam)
0
5
10
15
20
25
30
35
40
45
50
1.5-3 3-5 5-7 9-11 15-20
Team Size
Sc
he
du
le (
Mo
nth
s)
0
50
100
150
200
250
300
Eff
ort
(Sta
ff M
on
ths)
Schedule Effort
Adapted from Lawrence H. Putnam and Ware Myers, Five Core Metrics: The Intelligence
Behind Successful Software Management
21
Brooks’ Diseconomy of Scale Revisited
Efficiency is an N2 function of the number of
people on the project due to communication
paths: N*(N-1)/2
1 person =
0 paths
2 people =
1 path
3 people =
3 paths
4 people =
6 paths
5 people =
10 paths
50 people =
1225 paths
22
Diseconomy of Scale: McConnell’s
Step Function
Team Size
Pro
du
ctiv
ity
1 ~7 ~50 ~250-350
23
Diseconomy of Scale: McConnell’s
Step Function, Output
Team Size
Pro
du
ctiv
ity
1 ~7 ~50 ~250-350
Ou
tpu
t
24 Construx®
Failure Rates by Size
Source: Adapted from Applied Software Measurement, 3rd Edition (Jones 2008), Estimating Software Costs (Jones 1998).
Project Outcomes by Project Size
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
10 FP
500-1000 LOC
100 FP
5K-10K LOC
1,000 FP
50K-100K LOC
10,000 FP
500K-1M LOC
100,000 FP
5M-10M LOC
Pe
rce
nta
ge
Failed
Late
On Time
Early
25 Construx®
Error Rate by Size? Productivity by Size?
-
5,000
10,000
15,000
20,000
25,000
30,000
1 KLOC 10KLOC
100KLOC
1,000KLOC
10,000KLOC
LOC
/ S
taff
Ye
ar
Productivity by Size
High LOC/Staff Year
Nominal
Low LOC/Staff Year
Notice the “High” here?
This implies that a 500 MLOC
healthcare.gov would
require at least
100,000 staff-years of effort
(all since 2010!)
-
20
40
60
80
100
120
<2 KLOC 2-16KLOC
16-64KLOC
64-512KLOC
512+KLOC
De
fec
ts /
KLO
C
Error Rate by Size
Low Error Rate
High Error Rate
Average Error Rate
26 Construx®
Specializations by Organization Size
Cocomo Factors by
Size
28 Construx®
Cocomo II’s View of Software Project
Influences
-27%
-24%
0%
-19%
-22%
-18%
-19%
-19%
-22%
-13%
0%
-19%
-10%
-18%
-16%
-5%
-14%
74%
42%
34%
63%
29%
22%
26%
23%
22%
17%
30%
46%
15%
15%
20%
28%
19%
14%
12%
24%
11%
-16%
-19%
-15%
-29%
Product Complexity
Requirements Analyst Capability
Programmer Capability (general)
Time Constraint
Personnel Continuity (turnover)
Multi-Site Development
Required Software Reliability
Extent of Documentation Required
Applications (Business Area) Experience
Use of Software Tools
Platform Volatility
Storage Constraint
Precedentedness
Process Maturity
Language and Tools Experience
Database Size
Platform Experience
Architecture and Risk Resolution
Development Flexibility
Developed for Reuse
Team Cohesion
29 Construx®
Cocomo II’s View of Software Project
Influences
30 Construx®
Cocomo II’s View of Software Project
Influences
31 Construx®
Why Does This Matter?
(Implications of the Diagram)
Understanding the factors in the Cocomo model
and their relative importances goes a long way
toward explaining software project dynamics
overall
Many dynamics related to project size are implied
by Cocomo’s scaling factors
Many dynamics related to human variation are
implied in the Cocomo model
Activity Mix by Project
Size
33 Construx®
Project Activity Mix by Project Size
Construction
is approx.
2/3
Construction
is approx.
1/3
34 Construx®
Why Does This Matter?
(Implications of the Diagram)
Small project success does not prepare
organizations for large project success
Organizations must change focus as their projects
inevitably become larger
Organizations must build different/additional skill
sets as their projects become larger
There are numerous interactions between size,
uncertainty, defects, and human variation
Core Influence:
Uncertainty
36 Construx®
Again, We Have Many Wonderful
“Uncertainty” Diagrams
37
Effort vs. Knowledge Curve
Effort Expended
Knowledge /
Understanding
0%
100%
50%
25%
75%
38 Construx®
Waste
Feature Build Down
(The Feature Staircase)
Release
Plan
39
Cost
Feature Build Up
Diminishing returns when functionality is
delivered in priority order
Time
Opportunity to Add More
Value
Value /
Functionality
40
Risk Management: Relationship between
Planned and Unplanned Work
Planned Work
Planned
“Overhead”
Unplanned,
Variable Work
Cone of Uncertainty
vs. Cloud of
Uncertainty
42
Cone of Uncertainty vs. Cloud of Uncertainty
0.67x
0.8x
1.0x
0.5x
0.25x
2x
4x
1.5x
1.25x
Project
schedule
0.85x
0.9x
1.0x
0.8x
0.6x
1.25x
1.6x
1.15x
1.1x
Project scope
(effort, size, features)
Initial
product
definition Approved
product
definition
Requirements
Product
design
Detailed
design
Product
complete
43 Construx®
Why Does This Matter?
(Implications of the Diagram)
Explains why perfect estimation on Day 1 of a
project is not possible
Explains why reestimation is necessary if you want
accurate estimates
Explains why actively attacking uncertainty is
essential
Intellectual Phases
45
Intellectual Phases
Schedule
Focus
Discovery Invention Construction
This figure is adapted from Grady Booch, Object Solutions: Managing
the Object-Oriented Project, Reading, Mass: Addison Wesley 1996
46 Construx®
Schedule
Focus
Discovery Invention Construction
Intellectual Phases
Cost of Overlap
Overlap = Dependencies
Uncertainty
Risk
Rework
Higher costs
Longer
schedules
Lower quality
47 Construx®
Intellectual Phases
Degree of Overlap
Time
Focus
Discovery Invention Construction
Time
Discovery Invention Construction
Time
Discovery Invention Construction
48 Construx®
Intellectual Phases
Variations in Sources of Project Challenges
Discovery Invention Construction
Focus
49 Construx®
Why Does This Matter?
(implications of the diagram)
Many project failures are caused by treating uncertainties as
though they are certain
Additional inefficiencies are
created by treating uncertainties as if they were certain
Inefficiencies are also created by
treating certainties as if they were
uncertain
Software’s intangibility
exacerbates this phenomenon
Diagram provides a framework
for identifying uncertainty and planning appropriately
Pro
jec
t is
Tre
ate
d A
s
Project Is
Ce
rta
in
Un
ce
rta
in
Certain Uncertain
Effective
Effective
Risks Failure
Inefficient
Core Influence:
Defects
51 Construx®
Defect Cost Increase (DCI)
Requirements
Architecture
Construction
System test Requirements Architecture Construction Post-Release
Average
Cost to
Correct
Activity in which a
Defect Is
Introduced
Activity in Which a Defect Is Detected
52 Construx®
Fix More Defects Earlier!
Requirements
Architecture
Construction
System test Requirements Architecture Construction Post-Release
Average
Cost to
Correct
Activity in which a
Defect Is
Introduced
Activity in Which a Defect Is Detected
Fix Here Don’t Wait
to Fix Here
53 Construx®
Reduce Defect Cost Increase!
Requirements
Architecture
Construction
System test Requirements Architecture Construction Post-Release
Average
Cost to
Correct
Activity in which a Defect Is Introduced
Activity in Which a Defect Is Detected
54 Construx®
Effort/ Cost/
Schedule
Percentage of Defects
Removed Before Release
~95% 100%
Quality is an Accelerator
Quality improvement motivated primarily by economics
(quality is free)
Quality improvement motivated by quality, per se
(quality costs more)
Most Org’s
are Here
Gap Between Defect
Insertion and Defect
Detection
56 Construx®
Minimize Gap Between Defect
Insertion and Defect Detection
Time
Cumulative Defects
Risk of Extra Cost
Risk of Extra Cost
Time
Defect creation
Defect removal
Schedule / Cost
Savings
Typical Project Well-Run Project
57 Construx®
Why Does This Matter?
Practices that increase gaps between defect
insertion and defect detection will increase project
costs and project risk
Practices that minimize gaps between defect
insertion and defect detection will reduce project
costs and project risks
Understanding this diagram fully will lead to
basically same conclusions as understanding the
other diagrams
Core Influence:
Human
Variation
59 Construx®
Note
This is not just
general “humans
develop software.” This is specifically
about variation
across different
humans.
Human Beings Exhibit the Same
Variations in Performance That
Programmers Do!
Wednesday May 21 2009
60 Construx®
Cocomo II’s View of Software Project
Influences
-24%
-19%
-19%
-14%
42%
34%
29%
22%
20%
19%
11%
-16%
-15%
-29% Requirements Analyst Capability
Programmer Capability (general)
Personnel Continuity (turnover)
Applications (Business Area) Experience
Language and Tools Experience
Platform Experience
Team Cohesion
373% -78% Cumulative Effect of Personnel Factors
Human Variation vs.
Process-or-Practice
Variation
62 Construx®
Differences in Productivity
Productivity
Productivity of Team A A
B Productivity of Team B
63 Construx®
Differences in Methods
Productivity
Team A Used
Pair Programming A
B Team B Used
Formal Inspections
Which
method is
better?
64 Construx®
Differences in Capability
Productivity
Team A Had
Star Performers A
B Team B Had
Average Performers
Now
which
method is
better?
65 Construx®
Process Variation vs. Human Variation
Productivity
Typical Variation in
Method Productivity (~20%)
Typical Variation in
Individual Productivity (20:1) and
Team Productivity (3-10:1)
66 Construx®
Effect of Variations in Human Productivity
Productivity
Typical Variation in
Method Productivity (~20%)
Typical Variation in
Individual Productivity (20:1) and
Team Productivity (3-10:1)
Is the observed productivity difference between A and B
due to method differences or to differences
in individual capability or team capability?
A
B
67 Construx®
Example:
Chrysler C3 Extreme Programming Project
Productivity
Range that Kent Beck and
Ron Jeffries would perform using
any methods whatsoever
Kent and Ron’s performance on
Chrysler C3 project (speculation)
Range that average personnel will perform in, with or without
Extreme Programming
So, what is the effect of
Extreme Programming?
68 Construx®
Why Does This Matter?
Academic research on process effectiveness must
account for human variation to be meaningful (and
most does not)
Evaluation of pilot projects in organizations must
account for human variation to evaluate new
methods (and most does not)
The most effective approaches to software
development are capability based rather than
process based
Summary
Human
Variation Defects
Uncertainty Size
70 Construx®
Four Core Influences
Human
Variation Defects
Uncertainty Size
71 Construx®
Why Does This Matter?
Each influence is important in itself
Each influence interacts with each other influence,
and the interactions are significant
Goal: Help software professionals develop a mental
model / framework for understanding current
practices and new developments in software
engineering
72 Construx®
Latest Attempt to Explain Software Development
Software
Engineering
Essentials Lecture Series
CxLearn.com
Check it out now!
Construx Software is committed to helping
individuals and organizations improve their
software development practices. For information
about our training and consulting services, contact
+1(425)636-0100
10900 NE 8th Street, Suite 1350
Bellevue, WA 98004
+1 (866) 296-6300
www.construx.com
END
