 |
Contents at a Glance |
| Introduction and Definitions of Software Best Practices:Paths for Software Deployment >> |
Software
Engineering Best
Practices
A
BOUT
THE AUTHOR
CAPERS JONES is
currently the president and
CEO of Capers Jones &
Associates
LLC. He is also the founder
and former chairman
of
Software
Productivity Research LLC (SPR). He
holds the title of
Chief
Scientist Emeritus at SPR.
Capers Jones founded SPR
in
1984.
Before founding SPR, Capers
was assistant director of
pro-
gramming
technology for the ITT
Corporation at the
Programming
Technology
Center in Stratford, Connecticut. He
was also a man-
ager
and researcher at IBM in
California.
Capers
is a well-known author and
international public
speaker.
Some
of his books have been
translated into six
languages. All of
his
books are translated into
Japanese, and his newest
books are
available
in Chinese editions as well.
Among his book titles
are
Patterns
of Software Systems Failure
and Success (International
Thomson
Computer Press, 1995);
Applied
Software Measurement,
Third
Edition (McGraw-Hill, 2008);
Software
Quality: Analysis
and
Guidelines
for Success (International
Thomson, 1997); Estimating
Software
Costs, Second
Edition (McGraw-Hill, 2007);
and Software
Assessments,
Benchmarks, and Best
Practices (Addison
Wesley
Longman,
2000). The third edition of
his book Applied
Software
Measurement
was
published by McGraw-Hill in
2008.
Capers
and his colleagues from
SPR have collected
historical data
from
more than 600 corporations
and more than 30
government
organizations.
This historical data is a
key resource for
judging
the
effectiveness of software process
improvement methods.
More
than
13,000 projects have been
reviewed. This data is also
widely
cited
in software litigation in cases
where quality, productivity,
and
schedules
are part of the proceedings.
In addition to his
technical
books,
Mr. Jones has also received
recognition as an historian
after
the
publication of The
History and Future of
Narragansett Bay in
2006
by Universal Publishers. Mr. Jones
was the keynote
speaker
at
the annual Japanese
Symposium on Software Testing in
Tokyo
in
2008. He was also keynote
speaker at the World
Congress of
Quality,
and the keynote speaker at
the 2008 conference of
the
International
Function Point Users Group
(IFPUG). His research
studies
include quality estimating,
quality measurement,
software
cost
and schedule estimation, and
software metrics. He has
been
awarded
a life-time membership in IFPUG. He
was also named
as
a Distinguished Advisor to the
Consortium for
Information
Technology
Software Quality
(CISQ).
S
oftware
Engineering
Best
Practices
Lessons
from Successful
Projects
in
the Top Companies
Capers
Jones
New
York Chicago San Francisco
Lisbon London
Madrid
Mexico
City Milan New Delhi
San Juan
Seoul
Singapore
Sydney Toronto
Copyright
© 2010 by The McGraw-Hill Companies.
All rights reserved. Except as permitted
under
the
United States Copyright Act
of 1976, no part of this publication may
be reproduced or distributed
in
any form or by any means, or
stored in a database or retrieval system,
without the prior written
per-
mission
of the publisher.
ISBN:
978-0-07-162162-5
MHID:
0-07-162162-8
The
material in this eBook also
appears in the print version
of this title: ISBN:
978-0-07-162161-8,
MHID:
0-07-162161-X.
All
trademarks are trademarks of their
respective owners. Rather than
put a trademark symbol
after
every
occurrence of a trademarked name, we use
names in an editorial fashion only,
and to the
benefit
of the trademark owner, with no
intention of infringement of the
trademark. Where such
designations
appear in this book, they
have been printed with
initial caps.
McGraw-Hill
eBooks are available at special quantity
discounts to use as premiums
and sales
promotions,
or for use in corporate training
programs. To contact a representative
please e-mail us at
bulksales@mcgraw-hill.com.
Information
has been obtained by McGraw-Hill
from sources believed to be reliable.
However,
because
of the possibility of human or mechanical
error by our sources, McGraw-Hill, or
others,
McGraw-Hill
does not guarantee the
accuracy, adequacy, or completeness of
any information and
is
not
responsible for any errors or omissions
or the results obtained from
the use of such
information.
TERMS
OF USE
This
is a copyrighted work and The
McGraw-Hill Companies, Inc.
("McGraw-Hill") and its
licensors
reserve
all rights in and to the
work. Use of this work is
subject to these terms. Except as
permitted
under
the Copyright Act of 1976
and the right to store
and retrieve one copy of
the work, you may
not
decompile,
disassemble, reverse engineer, reproduce,
modify, create derivative works
based upon,
transmit,
distribute, disseminate, sell, publish or
sublicense the work or any
part of it without
McGraw-Hill's
prior consent. You may
use the work for your own
noncommercial and personal
use;
any
other use of the work is
strictly prohibited. Your right to
use the work may be
terminated if you
fail
to comply with these
terms.
THE
WORK IS PROVIDED "AS IS."
McGRAW-HILL AND ITS
LICENSORS MAKE NO GUAR-
ANTEES
OR WARRANTIES AS TO THE ACCURACY,
ADEQUACY OR COMPLETENESS OF
OR
RESULTS TO BE OBTAINED FROM
USING THE WORK, INCLUDING
ANY
INFORMATION
THAT CAN BE ACCESSED THROUGH
THE WORK VIA HYPERLINK
OR
OTHERWISE,
AND EXPRESSLY DISCLAIM ANY
WARRANTY, EXPRESS OR
IMPLIED,
INCLUDING
BUT NOT LIMITED TO IMPLIED
WARRANTIES OF MERCHANTABILITY OR
FITNESS
FOR A PARTICULAR PURPOSE.
McGraw-Hill and its
licensors do not warrant or
guar-
antee
that the functions contained in the work
will meet your requirements or that its
operation will be
uninterrupted
or error free. Neither McGraw-Hill nor
its licensors shall be
liable to you or anyone
else
for
any inaccuracy, error or omission,
regardless of cause, in the
work or for any damages
resulting
therefrom.
McGraw-Hill has no responsibility for
the content of any
information accessed through
the
work.
Under no circumstances shall
McGraw-Hill and/or its licensors be
liable for any indirect,
inci-
dental,
special, punitive, consequential or similar
damages that result from the
use of or inability to
use
the work, even if any of
them has been advised of
the possibility of such
damages. This
limitation
of liability shall apply to any
claim or cause whatsoever
whether such claim or
cause
arises
in contract, tort or
otherwise.
T
his
book is dedicated to many colleagues who
have studied and
advanced
the field of software
engineering. Some of these
include
Allan
Albrecht, Barry Boehm, Fred
Brooks, Tom DeMarco,
the
late
Jim Frame, Peter Hill, Watts
Humphrey, Steve Kan,
Steve
McConnell,
Roger Pressman, Tony
Salvaggio, Paul
Strassmann,
Jerry
Weinberg, and Ed Yourdon.
This
page intentionally left
blank
Contents
at a Glance
Chapter
1. Introduction and Definitions of
Software Best
Practices
1
Chapter
2. Overview of 50 Software Best
Practices
39
Chapter
3. A Preview of Software Development
and
Maintenance
in 2049
177
Chapter
4. How Software Personnel
Learn New Skills
227
Chapter
5. Software Team Organization
and Specialization
275
Chapter
6. Project Management and
Software Engineering
351
Chapter
7. Requirements, Business
Analysis,
Architecture,
Enterprise Architecture, and
Design
437
Chapter
8. Programming and Code
Development
489
Chapter
9. Software Quality: The Key
to Successful
Software
Engineering
555
Index
645
vii
This
page intentionally left
blank
Contents
ix
x
Contents
Contents
xi
C
xii
Contents
Contents
xiii
This
page intentionally left
blank
Foreword
Software
Engineering is about people--the
people who have a need
for
and
use software, the people
who build software, the
people who test
software,
the people who manage
software projects, and the
people who
support
and maintain software. So why is it
that the emphasis of
soft-
ware
engineering still concentrates on
the technology?
How
old is the business of
software development? Let's
settle on
55
years. That means a full
generation has moved through
the industry.
These
people were trained, spent
their lives working on
software, and
are
now retired or close to
retirement. In their time,
they have seen
innumerable
promises of "a better way"--silver
bullets by the score.
There
have been thousands of new
programming languages, all
manner
of
methodologies, and a plethora of
new tools. It sometimes
seems as
if
the software industry is as
strongly driven by fads and
fashion as
the
garment industry. Many
practitioners become apostolic in
their
worship
of a particular approach, practice, or
tool--for a while at
least.
But when the metrics are
collected and analyzed, the
sad truth
is
revealed--as an industry we have
not made a great deal of
progress.
There
have been no major
breakthroughs that have led
to the painless
production
of quality software delivered on
time and within a
predicted
cost.
And the skeptics ask,
"Is software engineering an
oxymoron?"
Our
fixation on technology blinds
us. We don't want to, or
can't, see
the
need to embrace basic, sound
engineering practices. In this
book,
Capers
Jones contends that if the
software industry wants to be
rec-
ognized
as an engineering discipline, rather
than a craft, then it
must
employ
solid engineering practices to
deliver an acceptable result,
eco-
nomically.
Technology is fascinating, but it is
not the most
important
factor
when it comes to doing good
work and delivering a good
result.
The
way people work, the
choices they make, and
the disciplines they
choose
to apply, will have more
impact on the success of a
software
project
than the choice of
technology.
There
must be times when Capers
feels like a prophet alone
in a desert.
He
has been tirelessly providing
the software industry with
guidance
xv
a
xvi
Foreword
nd
instruction on how to become a profession
and an engineering
dis-
cipline.
His efforts span 16 books
over 28 years. There are
times when I
wonder
if he ever sleeps. Draft chapters of
this book would arrive in
my
inbox
at all times of the night
and day. When you
read something and
think
to yourself: Well,
that makes sense; it's
obvious, really, you
realize
the
author has done a good
job. Capers is such a
writer. What he
writes
is
engaging, understandable, and
practical. My copies of his
books are
well
thumbed, and festooned with
Post-it notes. A sure sign
of the books'
practical
usefulness.
Capers
has an ability to stand back
and observe the essence of
the
problems
that still plague our
industry. He is fearless in attacking
prac-
tices
that he sees as dangerous--in
this book his targets
are the use of
the
measurements Cost
per Defect and
Lines
of Code. His
views will, no
doubt,
be controversial, despite his
well-reasoned dismantling of
these
dangerous
economic measures. Debate
and discussion will
rage--these
are
long overdue. It takes a
professional of Capers' standing to
light the
touch
paper to ignite these
debates.
Software
quality also comes under
the microscope in this book.
He
describes
software quality as the key
factor to successful software
engi-
neering--the
driving factor that has
more influence on software
costs,
schedules,
and success than any other.
There will be controversy
here
too
as Capers challenges some
common definitions of software
quality.
Throughout
the book, there is an
emphasis on the need for
measure-
ment
and metrics. Capers is
critical of the lack of
measurement, and the
use
of metrics that he describes as
hazardous.
The
software industry
deserves
to be critically questioned while it
makes little use of
measure-
ment
and metrics. As Capers
asserts, terms like "best
practices" are an
embarrassment
when we cannot present
statistical evidence.
Software
engineering is 55 years old;
the time has come
for it to
mature.
In this book, Capers Jones's
emphasis on the people and
man-
agement
issues of software engineering
point the way toward
achieving
that
maturity, and with it the
prospect of the software
industry being
recognized
as an engineering discipline.
Peter
R. Hill
CEO
International
Software Benchmarking Standards
Group
(ISBSG)
Limited
Acknowledgments
Thanks
as always to my wife, Eileen,
who has put up with the
writing
of
16 books over 28
years.
Thanks
also to the many colleagues
who provided insights and
help-
ful
information for this book,
and also for past
books: Michael Bragen
and
Doug Brindley, the CTO
and president of my former
company,
Software
Productivity Research (SPR);
Tom Cagley, the president of
the
International
Function Point Users Group
(IFPUG); Bob Charrette,
the
president
of ITABHI; Ben Chelf, of Coverity
Systems; Steven
Cohen,
from
Microsoft; Dr. Taz Doughtry,
from James Madison
University; Chas
Douglis,
a former president of Software
Productivity Research; Dr.
Larry
Driben,
the president of Pearl
Street software; Gary Gack,
president
of
Process Fusion; Jonathan
Glazer, the president of
PowerBees; Scott
Goldfarb,
the president of the Quality
and Productivity
Management
Group;
Steve Heffner, CEO of
Pennington Systems; Peter
Hill, the CEO of
International
Software Benchmarking Standards
Group (ISBSG); Watts
Humphrey,
from the Software
Engineering Institute (SEI);
Ken Hamer-
Hodges,
the president of Sipantic;
Dr. Steve Kan, from IBM
Rochester; Dr.
Leon
Kappleman, from the
University of North Texas;
Ravindra Karanam,
the
CTO of Unisys software
operations; Dov Levy, the
president of Dovél
Systems;
Dr. Tom Love, the
president of Shoulders Corporation;
Steve
McConnell,
the president of Construx;
Michael Milutis, the
director of
the
Information Technology Metrics
and Productivity Institute
(ITMPI);
Peter
Mollins, the chief of
marketing of Relativity Technology;
Prasanna
Moses,
from Unisys; Dr Walker Royce,
the head of IBM's Rational
group;
Dr.
Akira Sakakibara, a distinguished
scientist from IBM Tokyo;
Tony
Salvaggio,
the president of Computer
Aid Inc. (CAI); Paul
Strassmann,
president
of the Information Economics
Press (and the former CIO of
the
DoD);
and Cem Tanyel, a vice
president and general
manager of Unisys
Application
Development Services.
A
special tribute should be
given to two executives who
did a great deal
to
professionalize software. The
late James H. Frame was
director of IBM's
Santa
Teresa lab and then VP of
the ITT Programming
Development
xvii
C
xviii
Acknowledgments
enter
at Stratford, Connecticut. The
late Ted Climis was an IBM
vice
president
who recognized the critical
role of software at IBM. Both
men
clearly
understood that software was
vital to corporate business
opera-
tions
and that it needed to be designed
and built to the highest
standards
of
excellence.
Introduction
Between
the time this book
was started and the
time it was
completed,
the
global recession began. As a
result, this book moved in a
somewhat
different
direction than older books
dealing with software
engineering.
Due
to the recession, the book
now includes material on
dealing with
layoffs
and downsizing; on the
changing economic balance
between the
United
States and other countries;
and on the economics of
software
during
a recessionary period.
Software
engineering was not
immediately affected by the
financial
crisis
and the recession when it
started in 2008, but as time
passed,
venture
funds began to run out.
Other forms of financing for
software
companies
became difficult, so by the
middle of 2009, software
engineer-
ing
positions were starting to be
affected by layoffs. Specialty
positions
such
as quality assurance and
technical writing have been
affected
even
more severely, since such
positions are often the
first to go during
economic
downturns.
One
unexpected byproduct of the
recession is that the
availability of
software
engineers combined with a reduction in
compensation has made
the
United States a candidate
for becoming an outsource
country.
As
of 2009, the cost
differentials between the
United States, India,
and
China are being lowered,
and the convenience of
domestic contracts
versus
international contracts may
prove to be beneficial for
the soft-
ware
engineering community of the
United States.
As
the recession continues, the
high costs of software are
being exam-
ined
more seriously than in the
past. The recession also
highlights the
fact
that software has always
been insecure. Due to the
recession, cyber-
crime
such as the theft of
valuable information, identity
theft, and even
embezzlement
are increasing rapidly.
There are also sharp
increases in
"phishing"
or attempting to use false
messages to gain access to
personal
bank
accounts.
xix
F
xx
Introduction
rom
the author's viewpoint, the
recession is highlighting four
critical
areas
where software engineering
needs to improve to become a
solid
engineering
discipline rather than a
craft:
1.
Software security needs to be
improved organically by raising
the
immunity
levels of applications and
including better security
fea-
tures
in programming languages themselves.
Access control and
permissions
are weak links in software
engineering.
2.
Software quality needs to be improved in
terms of both defect
preven-
tion
methods and defect removal
methods. Poor quality has
damaged
the
economics of software for 50
years, and this situation
cannot con-
tinue.
Every major application
needs to use effective
combinations of
inspections,
static analysis, and
testing. Testing alone is
inadequate
to
achieve high quality
levels.
3.
Software measurements need to be
improved in order to gain
better
understanding
of the true economic picture
of software development
and
software maintenance. This
implies moving to
activity-based
costs.
Better measurement also
implies analyzing the flaws
of tra-
ditional
metrics such as "cost per
defect" and "lines of code,"
which
violate
the rules of standard
economics.
4.
Due to the recession, new
development is slowing down, so
the eco-
nomics
of software maintenance and
renovation need to be
better
understood.
Methods of preserving and
renovating legacy
applica-
tions
are increasingly important, as
are methods of mining
legacy
applications
for "lost" requirements and
business rules.
As
of 2009, the great majority
of companies and the great
majority of
software
engineers have no effective
measurements of either
productiv-
ity
or quality. This is not a
suitable situation for a
true engineering dis-
cipline.
Lack of measurements combined with
hazardous metrics
mean
that
evaluating the effectiveness of
methods such as Agile,
Rational
Unified
Process (RUP), and the
Team Software Process (TSP)
is harder
than
it should be.
While
the lack of measurements and
the ability to judge the
effective-
ness
of software engineering methods
and practices was
inconvenient
when
the economy was growing, it
is a serious problem during a
reces-
sion.
Poor measurements have made
phrases such as "best
practices"
embarrassing
for software, because a majority of
the best-practice
claims
have
not been based on solid
measurements using valid
metrics.
This
book attempts to show a
combination of metrics and
measure-
ments
that can demonstrate
effectiveness and hopefully
place software
engineering
on a sound economic basis.
The "best practices"
described
h
Introduction
xxi
erein
are those where quantitative
data provides at least a
provisional
ability
to judge effectiveness.
The
book is divided into nine
chapters, each of which
deals with a set
of
technical and social
issues.
Chapter
1: Introduction and Definitions of
Software Best Practices
Because
many
software applications may
last for 25 years or more
after they are
first
delivered, software engineering is
not just concerned with
develop-
ment.
Software engineering needs to
consider the many years of
main-
tenance
and enhancement after
delivery. Software engineering
also
needs
to include effective methods
for extracting or "mining"
legacy
applications
to recover lost business
rules and
requirements.
There
are more software engineers
working on maintenance
than
on
new development. Many of the
maintenance software engineers
are
tasked
with maintaining applications they
did not develop, which
may
be
coded in "dead" languages, and
where there are neither
specifications
nor
effective comments in the
code itself.
Software
engineering "best practices"
are not a "one size fits
all" tech-
nology.
Evaluating best practices
requires that the practices
be under-
stood
for small applications of
100 function points or
below, medium
applications
of 1000 function points, and
large systems that may
top
100,000
function points in
size.
Further,
the best practices that
are effective for web
applications
and
information technology are
not necessarily the same as
those with
good
results on embedded applications,
systems software, and
weapons
systems.
As
a result of these two wide
sets of variations, this
book evaluates
best
practices in terms of both
application size and
application type.
This
chapter discusses
Chapter
2: Overview of 50 Software Best
Practices
50
software engineering best
practices. Not all of the
practices are
purely
technical. For example,
during recessionary periods,
companies
have
layoffs that if done poorly
will damage operational
effectiveness
for
many years.
This
chapter deals with development
best practices,
maintenance
best
practices, management best
practices, and sociological
best prac-
tices
such as those dealing with
layoffs, which are often
handled poorly
and
eliminate too few managers
and executives and too
many software
engineers
and specialists.
Methods
other than layoffs such as
reducing the work periods
and
compensation
of all employees are usually
preferable to actual
staff
reductions.
O
xxii
Introduction
ther
best-practice areas include
security control, quality
control,
risk
analysis, governance, development,
maintenance, and
renovation
of
legacy applications.
Portions
of this chapter have served
in software litigation where
fail-
ure
to conform to software engineering
best practices were part of
the
plaintiff's
claims.
Chapter
3: A Preview of Software Development
and Maintenance in
2049
When
software engineering is viewed up close
as it is practiced in 2009,
it
is difficult to envision changes
and improvements. Chapter 3
skips
ahead
to 2049 and explores what
software engineering might be
like in a
world
where all of us are
connected via social
networks, where the
work
of
software engineering can be
divided easily among
software engineers
who
may live in many different
countries.
The
chapter also looks ahead to
specific technical topics
such as the
role
of data mining in gathering
requirements and the
possible avail-
ability
of substantial libraries of certified
reusable material. Also
pos-
sible
are intelligent agents and
search-bots that will accumulate
and
even
analyze information on critical
topics.
Given
the rapid rate of
technological progress, it can be
anticipated
that
computing devices, networks,
and communication channels will
be
extremely
sophisticated by 2049. But software
engineering tends to
lag
hardware.
Significant improvements are
needed in security, quality,
and
reusability
to keep pace with hardware and
network evolution.
Chapter
4: How Software Personnel
Learn New Skills
Due
in part to the
recession,
publishers of paper books
and also software journals
are expe-
riencing
severe economic problems and
many are reducing staffs.
Online
publishing
and electronic books such as
the Amazon Kindle and
the
Sony
PR-505 are rapidly
expanding. Web publication,
blogs, and Twitter
are
also expanding in terms of
both providers and
users.
Chapter
4 evaluates 17 channels that
are available for
transmitting
and
learning new software
engineering information. Each
channel is
ranked
in terms of learning effectiveness
and cost-effectiveness.
Long-
range
predictions are made as to
the future of each
channel.
Some
of the learning channels
evaluated include conventional
paper
books,
electronic books, software
journals, electronic journals
and blogs,
wiki
sites, commercial education,
in-house education, academic
educa-
tion,
live conferences, and
webinars, or online conferences.
Electronic
media
have surpassed print media
in terms of cost-effectiveness and
are
challenging
older media in terms of
learning effectiveness.
Chapter
4 also suggests curricula
for software engineers,
software
quality
assurance personnel, software
test personnel, software
project
office
personnel, and software
managers. While today's
academic curricula
a
Introduction
xxiii
re
sufficient for mainstream
software engineering, there is a
shortage
of
solid education on topics
such as sizing, estimating,
planning, secu-
rity,
quality control, maintenance,
renovation, and software
engineering
economic
analysis.
Software
metrics are poorly served by
the academic community,
with
very
little critical analysis of
the flaws of common metrics
such as cost
per
defect and lines of
code.
While
functional metrics are
taught in a number of universities,
there
is
little in the way of
critical economic analysis of
older metrics that
behave
erratically or that violate
the canons of manufacturing
econom-
ics.
In particular, the impact of
fixed costs on productivity is
not dealt
with,
and this is the main
reason why both lines of
code and cost
per
defect
are invalid for economic
analysis.
Software
engi-
Chapter
5: Software Team Organization
and Specialization
neering
organizations range from one
person independent
companies
that
produce small applications up
through massive organizations
with
more
than 1000 personnel who
are part of companies that
may employ
more
than 50,000 software
personnel.
Large
software engineering organizations
employ more than 90
kinds
of
specialists in addition to software
engineers themselves:
quality
assurance,
technical writers, database
administration, security
special-
ists,
webmasters, and metrics
specialists are a few
examples.
Chapter
5 shows the results of many
different kinds of
organization
structures,
including pair programming,
small Agile teams,
hierarchical
organizations,
matrix organizations, and
virtual organizations that
are
geographically
dispersed. It also shows the
most effective ways of
orga-
nizing
specialists such as software
quality assurance, testing,
technical
documentation,
and project offices.
For
example, for large projects
in large companies, separate
mainte-
nance
teams and separate test
groups tend to be more
effective than
having
maintenance and testing
performed by the development
team
itself.
Specialists and generalists
must work together, and
organization
structures
have a strong impact on
overall results.
It
is common
Chapter
6: Project Management and
Software Engineering
knowledge
that many software projects
are sized incorrectly,
estimated
incorrectly,
and have schedules committed
that are too short
for the
capabilities
of the development team.
These lapses in project
manage-
ment
can cause the affected
software projects to either
fail completely
or
to have serious cost and
schedule overruns.
Chapter
6 deals with the critical
management functions that
can
cause
software engineering failures if
they are not done
well: sizing,
p
xxiv
Introduction
lanning,
estimating, progress tracking,
resource tracking,
benchmarks,
and
change management.
Chapter
6 suggests that every
software project larger than
trivial
should
collect both quality and
productivity data that can
be used for
baselines
and benchmarks. Collecting
data on productivity and
quality
should
be universal and not rare
exceptions.
Careful
measurement of methods utilized
and results achieved
is
a
sign of professionalism. Failure to
measure is a sign that
"software
engineering"
is not yet a true
engineering discipline.
Chapter
7: Requirements, Business Analysis,
Architecture, Enterprise
Architecture,
and Design Long
before any code can be
written, it is nec-
essary
to understand user requirements.
These requirements need
to
be
mapped onto effective
software architectures and
then translated
into
detailed designs. In addition,
new applications need to be
placed
in
the context of the overall
enterprise portfolio of applications.
With
more
than 20 forms of requirements
methods and 40 kinds of
design
methods,
software engineers have a
great many choices.
This
chapter discusses the most
widely used methods of
dealing with
requirements
and design issues and
shows the classes and
types of
applications
for which they are
best suited. Agile methods,
the unified
modeling
language (UML), and many
other techniques are
discussed.
The
full portfolio for a large
corporation circa 2009 can
include more
than
5000 applications totaling
more than 10 million
function points.
The
portfolio can include
in-house applications, outsourced
applications,
commercial
applications, and open-source
applications.
The
portfolio can include web
applications, information
technology
applications,
embedded software, and
systems software. Due to
the
recession,
it is increasingly important for
corporate executives to
know
the
size, contents, value,
security levels, and quality
levels of corporate
portfolios.
Portfolio
analysis has been hampered
in the past by the
difficulty of
quantifying
the sizes of various
applications. New high-speed
sizing
methods
that operate on commercial
applications and on
open-source
applications
as well as on in-house applications
are beginning to
elimi-
nate
these historical problems. It is
now possible to size
thousands of
applications
in a matter of a few days to a
few weeks.
This
chapter deals with
Chapter
8: Programming and Code
Development
programming
and code development from an
unusual viewpoint. As of
2009,
there are about 2500
programming languages and
dialects. This
chapter
asks questions about why
software engineering has so
many
languages.
C
Introduction
xxv
hapter
8 also asks whether the
plethora of languages is helpful
or
harmful
to the software engineering
profession. In addition, it
discusses
the
reasons many applications
use between 2 and 15
different program-
ming
languages. The general
conclusion is that while
some program-
ming
languages do benefit software
development, the existence of
2500
languages
is a maintenance nightmare.
The
chapter suggests the need
for a National
Programming
Translation
Center that would record
the syntax of all known
lan-
guages
and assist in converting
applications written in dead
languages
into
modern languages.
The
chapter also includes
information on the kinds of
bugs found in
source
code, and the most
effective "personal" methods of
defect preven-
tion
and defect removal that
are carried out by software
engineers prior
to
public activities such as
function and regression
testing.
Personal
software methods such as
desk checking and unit
testing
are
normally not measured.
However, volunteers do record
information
on
defects found via "private"
defect removal activities, so
some data is
available.
This
chapter also discusses
methods of measuring programming
pro-
ductivity
and quality levels. The
chapter is controversial due to
challeng-
ing
the traditional "lines of code"
(LOC) metric as being
economically
invalid.
The LOC metric penalizes
high-level languages and
distorts
economic
analysis.
Already
in 2009, the lines of code
metric cannot deal with
require-
ments,
design, screens, or documentations.
Collectively, the costs of
these
noncode
activities constitute more
than 60 percent of total
development
expenses.
The
alternative is functional metrics,
which can handle all
known soft-
ware
engineering activities. However,
software functional metrics
have
been
slow and expensive. New
high-speed functional metrics
are starting
to
appear circa 2009 that
promise to expand the usage
of such metrics.
Chapter
9: Software Quality: The Key
to Successful Software
Engineering
Quality
has long been one of the
weakest links in the chain
of technologies
associated
with software engineering. This
chapter attempts to cover
all
major
factors that influence software
quality, including both
defect preven-
tion
methods and defect removal
methods.
The
chapter discusses the
strengths and weaknesses of
formal inspec-
tions,
static analysis, and 17
different kinds of testing. In
addition, the
chapter
deals with various troublesome
metrics that degrade
under-
standing
software quality. For
example, the popular "cost
per defect"
metric
actually penalizes quality
and achieves the lowest
cost for the
buggiest
applications! In addition, quality
has economic value far
in
e
xxvi
Introduction
xcess
of the mere cost of removing
defects, and this value
cannot be
shown
using cost per defect
metrics.
The
main theme of the chapter is
that quality is the driving
factor
that
has more influence on
software costs, schedules,
and success than
any
other. But poor measurement
practices have made it
difficult to
carry
out valid software
engineering economic
studies.
This
chapter is controversial because it
challenges two common
defi-
nitions
of quality. The definition
that quality means
"conformance to
requirements"
is challenged on the grounds
that many requirements
are
harmful
or "toxic" and should not be
implemented. The definition
that
quality
means conformance to a list of
words ending in "ility,"
such as
"portability,"
is also challenged on the
grounds that some of these
terms
can
be neither predicted nor
measured. Quality needs a
definition that
can
be predicted before applications
begin and measured when
they
are
complete.
Quality
is the key to successful
software engineering. But before
the
key
can unlock a door to real
professionalism, it is necessary to
know
how
to measure software quality
and also software economics.
The chap-
ter
concludes that an activity
that cannot measure its
own results is
not
a true engineering discipline. It is
time for software
engineering
to
study critical topics such
as defect potentials and
defect removal
efficiency
levels.
As
of 2009, most projects have
far too many bugs or
defects, and remove
less
than 85 percent of these
prior to delivery. Every
software engineer
and
every software project
manager should know what
combination of
inspections,
static analysis, and test
stages is needed to achieve
defect
removal
efficiency levels that
approach 99 percent. Without
such knowl-
edge
based on measurements, software
engineering is a misnomer,
and
software
development is only a craft
and not a true
profession.
One
of the inspira-
Overall
Goals of Software
Engineering Best
Practices
tions
for this book was an
older book from 1982.
The older book was
Paul
Starr's
Pulitzer Prize winner,
The
Social Transformation of
American
Medicine.
Until
I read Paul Starr's book, I
did not realize that
150 years ago,
medical
degrees were granted after
two years of study, without
any
internships
or residency requirements. In fact,
most physicians-in-
training
never entered a hospital
while in medical school.
Even more
surprising,
medical schools did not
require either a college
degree or a
high-school
diploma for admission. More
than 50 percent of U.S.
physi-
cians
never went to
college.
Paul
Starr's book detailed the
attempts of the American
Medical
Association
to improve academic training of
physicians, establish a
canon
of professional malpractice to weed
out quacks, and to
improve
t
Introduction
xxvii
he
professional status of physicians.
There are many lessons in
Paul
Starr's
book that would be valuable
for software
engineering.
The
primary goal of this book on
software engineering best
practices is
to
provide incentive for
putting software engineering on a
solid basis of
facts
derived from accurate
measurement of quality and
productivity.
As
the recession continues,
there is an increasing need to
minimize
software
failures, speed up software delivery,
and reduce software
main-
tenance
expenses. These needs cannot
be accomplished without
careful
measurements
of the effectiveness of tools,
methods, languages,
and
software
organization structures.
Accurate
measurement is the key that
will unlock better
software
quality
and security. Better
software quality and
security are the
keys
that
will allow software engineering to
become a true profession
that is
equal
to older engineering fields in achieving
successful results.
Measurement
of software engineering results will
also lead to more
and
better benchmarks, which in
turn will provide solid
proofs of soft-
ware
engineering methods that
have proven to be effective.
The over-
all
themes of the book are
the need for better
measurements, better
benchmarks,
better quality control, and
better security as
precursors
to
successful software
engineering.
This
page intentionally left
blank
Table of Contents:
- Introduction and Definitions of Software Best Practices:Paths for Software Deployment
- Overview of 50 Software Best Practices:Best Practices for Outsourcing Software Applications
- A Preview of Software Development and Maintenance in 2049:Requirements Analysis Circa 2049
- How Software Personnel Learn New Skills:The Evolution of Software Learning Channels
- Software Team Organization and Specialization:Quantifying Organizational Results
- Project Management and Software Engineering:Software Progress and Problem Tracking
- Requirements, Business Analysis, Architecture, Enterprise Architecture, and Design:Software Requirements
- Programming and Code Development:How Many Programming Languages Are Really Needed?
- Software Quality: The Key to Successful Software Engineering, Measuring Software Quality, Software Defect Removal
- Index