Why can’t engineering good
software be like building a
house?
Steve Cross
cross@gatech.edu
November 17, 2004
What I’d like to share with you
• Background
– History, state of practice
• Analogy
– SWE should be more like designing and building a house
• 3 key ideas
– Process – do the work right the first time
– Architecture – design and engineering analysis before coding
– Reuse – leverage investment  engineered assets + experience
• Summary
A Brief History of Software
Engineering
1968, the term
“software engineering”
first used
1990’s
1980’s
1970’s
1960’s
1950’s
High Order
Languages
Tools
Emphasis on
cycle time
Emphasis on
quality
Emphasis on
productivity
2000’s?
State of practice
Requirements
needs
Right Product
Built Badly
Right Product
Built Well
(e.g., buffer overflows
are the most common vulnerability
exploited in internet attacks)
(and on cost, on schedule, etc.)
Wrong Product
Built Badly
Wrong Product
Built Well
(i.e., most projects so classified)
(e.g., the ‘require-delay-surprise’
phenomena)
Code
Implementation
Design
analysis
A serious implication of shoddy
designs and coding practices
•
•
•
•
Viruses
Worms
Identity theft
etc, etc, etc
Leading Culprit - Buffer Overflows
http://www.cert.org/homeusers/buffer_overflow.html
Critical Need for Better Software
Vulnerabilities Reported to CERT/CC
Data from 1,500 Software Projects
Projects canceled
before completion
Projects late
and over budget
23%
53%
Projects
completed
on time and
on budget
49%
28%
31%
• Average cost growth exceeds 89%
• The average final product contains 61% of the originally
specified features
Ref: Standish Group, CHAOS Study, Summer 2001.
Lots of bad products built badly
The public is beginning
to understand that poor
quality software is the
cause of many problems.
Reference:
Cover of 12/6/1999 business week,
www.businessweek.com
Reasons Why Projects Fail
•
•
•
•
•
•
Project objectives not understood
Bad planning and estimating
Technology new to the organization
Inadequate/no project management
Methodology
Insufficient senior staff on the team
Ref: Robert Glass, Software Runaways, Prentice Hall, Inc., ISBN 0-13-673443, 1998.
Would you design and build a house
the way you do software?
Before
what is
needed
What we hope we will get
… and what we get
Analogies between houses and
software engineering
Feature
House
Software
Architecture
Blueprints
Architecture Description
Languages (e.g., UML)
Standards
Building Codes
“Technical View”
(e.g., J2EE)
Construction Method
Assembly of
prefabricated
components
Assembly of objects and
other reusable software
modules
Process
Skilled craftspeople
following a
production plan
Experienced team (e.g.,
architect, designer, coders,
testers) following defined
ways of work
First Principles
Leveraged investment
Physics
N/A (e.g., use of iterative
(e.g., structural analysis)
approaches to gain experience)
A housing subdivision
A product line
(e.g., cell phones, printers)
Key Idea #1: Process
(compiled individual and team experience)
A software process is a set of activities, methods,
and practices that people employ to develop and
maintain software and associated products (e.g.,
project plans, design documents, test cases,
documentation)
A process model (e.g., the Capability Maturity
Model ® or CMMI ® ) is a collection of process
descriptions and an embedded approach for
assessment and continuous improvement
® Capability
Maturity Model, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University
Many process modeling approaches
•
•
•
•
CMM®, CMMISM
PSP, TSP
Agile approaches
Other process models
Key point
capture, use, and improve experience
®
CMM is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
SMCMMI
SMPSP
is a service mark of Carnegie Mellon University.
and TSP are service marks of Carnegie Mellon University
Capability Maturity Models
(models of engineering organizations)
5
Productivity
4
3
2
1
Risk
Process models came form manufacturing –
e.g., Crosby’s Quality Management Maturity
Grid
Management Stage 1:
Categories Uncertainty
Stage 2:
Awakening
Stage 3:
Enlightenment
Stage 4:
Wisdom
Stage 5:
Certainty
Cost of
Reported:
Reported:
quality as % unknown
5%
of sales
Actual: 20% Actual: 18%
Reported: 8%
Actual: 12%
Reported: Reported:
6.5%
2.5%
Actual: 8% Actual: 2.5%
Summation
of company
quality
posture
“We are
identifying and
resolving our
quality
problems.”
“We
routinely
prevent
defects
from
occurring.”
“We don’t
know why
we have
quality
problems.”
“Must we
always have
quality
problems?”
“We know
why we don’t
have quality
problems.”
Ref: Crosby, P. Quality is Free: The Art of Making Quality Certain. New York: McGraw-Hill, 1979.
Improvement Focus at Each Maturity
Level
Project management
Repeatable system in place;
performance is repeatable
Plans bas ed on past
is informal and
performance are Process
more
Initial
realistic in Level 2ad hoc; performance is
organiz ations
unpredictable
Ta rget N-z
Ta rget N-y
Time/$/...
Ta rget N+a
With well-defined processes ,
performance improves in
Level 3 organiz ations
Time/$/...
Ta rget N
Defined
Software engineering and
management processes
defined and integrated
Time/$/...
Ta rget N-x
Based on quantitative
understanding of proces s
and product, performance
continues to improve in
Level 4 organiz ations
Probability
Managed Product and process are
quantitatively controlled
Time/$/...
Probability
Performanc e continuously
improves in Level 5
organiz ations
Probability
Process improvement is
Optimizing institutionalized
Predicted Performance
Probability
Process Characteristics
Probability
Level
Time/$/...
Average Number of Defects/Kloc
Post-Release Defects
15
10
5
0
Level 1
Level 2
level 3
Time
(Based on 120 projects in
Ref: Griffin, Scott (Boeing CIO). “Software Process Improvement Journey: Boeing Information Systems)
From Level 1 to Level 5.” SEPG Conference, Seattle WA (USA), March 2000.
Cycle Time
Average Number of Hours
100
80
60
36% Faster
40
20
0
Level 1
Level 2
level 3
Time
(Based on 120 projects in
Ref: Griffin, Scott (Boeing CIO). “Software Process Improvement Journey:
Boeing Information Systems)
From Level 1 to Level 5.” SEPG Conference, Seattle WA (USA), March 2000.
Percent of Staff Support per System
Productivity
100
- 12%
75
Increased
Productivity
- 26%
- 38%
50
- 62%
25
Reduced Staff Support
per System = Increased Productivity
0
1992
Level 1
1993
1994
Level 2
1995
1996
Level 3
Ref: Griffin, Scott (Boeing CIO). “Software Process Improvement Journey:
From Level 1 to Level 5.” SEPG Conference, Seattle WA (USA), March 2000.
In contrast, how fast can one
(design and) build a good house?
Start at t0
Building
t0 + 2hrs 45 min
Industry Association, San Diego, CA, 1997.
Key Idea #2: Architecture
Definition:
A software architecture is the structure or structures of
the system, which comprise software elements, the
externally visible properties of those elements, the
relationships among them, and the documentation to
describe it all.
Explicit modeling of the architecture permits analysis of a
design before coding and test
Ref: Bass, Clements, Kazman. Software Architecture in Practice (2nd edition), Addison-Wesley, 2003.
Systems, models, and views
• Model
– Abstraction describing a system or subsystem
• View
– Selected aspects of a model
• Notation
– Set of rules for representing views
Systems, models, and views
Blueprint
s
Electronic
Drawings
(plumbing)
Blueprint
s
(room layout)
View 2
System
View 1
Model 1
Model 2
View 3
Blueprint
s
(wiring)
Scale
Model
House
Move towards notation that allows exploration
of static and dynamic behaviors
System
Model
described by
View
depicted by
House: system
Model 1: electronic drawings
Model 2: scale model
View 1: room layout
View 2: wiring diagram
View 3: plumbing
Constrains
Operational View
identifies what needs to be accomplished
and who does it
Technical View
Some key points
about architecture (1)
centered design
Note: others use different
terminology to describe “views” –
see Krutchen’s “4+1 views” paper (2)
prescribes standards and
conventions
Attribute
Analysis
Generated from
OV and TV
Systems View
relates systems and
characteristics to
operational needs
Repository
(components, modules)
• From component library
• Newly prototyped components
build/integrate, test
Actual
System
References:
(1) “DoD Architecture Framework Working Group, DoD Architecture Framework, Version 1.0, Volume I: Definitions and Guidelines,” February 2004
(2) Krutchen, P. “Architectural Blueprints – the “4+1” Model of Software Architecture,
IEEE Software, Nov. 1995, p. 42-50, also at www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf
Structured English
to XML mappings
Narrative Form
Use Cases
Constrains
What ifs by
end-users
Operational View
identifies what needs to be accomplished
and who does it
Qualitative
assessments
Technical View
Quantitative
measurements
prescribes standards and
conventions
Attribute
Analysis
Generated from
OA and TA
Systems View
relates systems and
characteristics to
operational needs
Simulation
Environment
Executable
Architecture
Rapid
Composability
Repository
(components, modules)
build/integrate, test
Actual
System
•Role played by humans or agents
• From component library
• Newly prototyped components
Analogies between houses and
software engineering
Feature
House
Software
Architecture
Blueprints
Architecture Description
Languages (e.g., UML)
Standards
Building Codes
“Technical View”
(e.g., J2EE)
Construction Method
Assembly of
prefabricated
components
Assembly of objects and
other reusable software
modules
Process
Skilled craftspeople
following a
production plan
Experienced team (e.g.,
architect, designer, coders,
testers) following defined
ways of work
First Principles
Leveraged investment
Physics
N/A (e.g., use of iterative
(e.g., structural analysis)
approaches to gain experience)
A housing subdivision
A product line
(e.g., cell phones, printers)
Myth: it is easy to build a
system from components - just
assemble it
Components
everywhere
but
no help in how
to assemble them
into a system
OK, now what do I do?
“How To”
Book
Duct Tape
Goof
Off
Idea #3: Reuse Everything
Use of a
common
asset base
Architecture
in production
Production Plan
of a related
set of products
Scope Definition
Business Case
Putting it all together
•
Domain Understanding
Understanding Relevant Domains
feeds
Requirements
drive
Architecture Definition
Architecture Evaluation
Architecture
specifies components
Make/Buy/Mine/Commission Analysis
Make
Buy
Mine
Commission
Component
Development
COTS
Utilization
Mining
Existing
Assets
[Developing an
Acquisition
Strategy]
organizational
policy
existing
talent
market availability
Software System Integration
legacy base
Components
Testing
In summary - Design in Quality!
Software state of practice (“test in” quality)
60 - 80 % of effort and cost*
Development
Integration and System Test
World-class developers “design in” quality
Predictable and improved
cost, schedule, and quality
Ref: Standish Group, CHAOS Report, 2001.
Parting thought
• Software engineering is hard work
• The expectation of outputs from our
profession should be at least as high as
the building trades
Some other references
•
Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., and Stafford, J. (2002).
Documenting Software Architectures: Views and Beyond, Reading (MA): Addison-Wesley.
•
Clements, P., Kazman, R., and Klein, M. (2001). Evaluating Software Architectures: Methods and Case
Studies. Reading (MA): Addison-Wesley.
•
Clements, P. and Northrop, L. (2001). Software Product Lines: Practices and Patterns, Reading (MA):
Addison-Wesley.
•
Cross, S. (2002). “Reflections on the Process Revolution,” IEEE Tutorial on Software Management, 6th
Edition, Reifer, D (Ed).
•
Haeckel, S. (1999). Adaptive Enterprise: Creating and Leading Sense-and-Respond Organizations, Boston:
Harvard Business School Press
•
Kotter, J. and Cohen, D. (2002). The Heart of Change, Boston: Harvard Business School Press.
•
MacMillan, P. (2001). The Performance Factor: Unlocking the Secrets of Teamwork, Nashville: Broadman &
Holman Publishers.
•
Royce, W. (1998). Software Project Management: A Unified Framework, Reading (MA): Addison-Wesley.
•
Smith, H. and Fingar, P. (2003). Business Process Management: The Third Wave. Tampa: Meghan-Kiffer
Press.
•
Web sites
•
•
•
•
•
IEEE Software Magazine
Object Management Group
Software Engineering Institute
UML, papers on
Workflow Management Coalition
www.computer.org/software
www.omg.org
www.sei.cmu.edu
www.rspa.com/reflib/UMLRelatedMaterials.html
www.wfmc.org