pre75977_FM.
qxd 11/27/08 6:38 PM Page iii
Software Engineering
A PRACTITIONER’S APPROACH
SEVENTH EDITION
Roger S. Pressman, Ph.D.
pre75977_ch01.qxd 11/27/08 3:11 PM Page 21
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 21
The Sixth Principle: Plan Ahead for Reuse
Reuse saves time and effort.15Achieving a high level of reuse is arguably the
hardest goal to accomplish in developing a software system. The reuse of code and
designs has been proclaimed as a major benefit of using object-oriented technolo-
gies. However, the return on this investment is not automatic. To leverage the
reuse possibilities that object-oriented [or conventional] programming provides
requires forethought and planning. There are many techniques to realize reuse
at every level of the system development process. . . . Planning ahead for reuse
reduces the cost and increases the value of both the reusable components and the
systems into which they are incorporated.
The Seventh principle: Think!
This last principle is probably the most overlooked. Placing clear, complete
thought before action almost always produces better results. When you think about
something, you are more likely to do it right. You also gain knowledge about how
to do it right again. If you do think about something and still do it wrong, it be-
comes a valuable experience. A side effect of thinking is learning to recognize
when you don’t know something, at which point you can research the answer.
When clear thought has gone into a system, value comes out. Applying the first six
principles requires intense thought, for which the potential rewards are enormous.
If every software engineer and every software team simply followed Hooker’s seven
principles, many of the difficulties we experience in building complex computer-
based systems would be eliminated.
1.6 S O F T WA R E M Y T H S
Software myths—erroneous beliefs about software and the process that is used to
uote:
build it—can be traced to the earliest days of computing. Myths have a number of
“In the absence of attributes that make them insidious. For instance, they appear to be reasonable
meaningful statements of fact (sometimes containing elements of truth), they have an intuitive
standards, a new
feel, and they are often promulgated by experienced practitioners who “know the
industry like
software comes to score.”
depend instead on Today, most knowledgeable software engineering professionals recognize myths
folklore.” for what they are—misleading attitudes that have caused serious problems for
Tom DeMarco managers and practitioners alike. However, old attitudes and habits are difficult to
modify, and remnants of software myths remain.
15 Although this is true for those who reuse the software on future projects, reuse can be expensive
for those who must design and build reusable components. Studies indicate that designing and
building reusable components can cost between 25 to 200 percent more than targeted software. In
some cases, the cost differential cannot be justified.
pre75977_ch01.qxd 11/27/08 3:11 PM Page 22
22 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING
WebRef Management myths. Managers with software responsibility, like managers in
The Software Project most disciplines, are often under pressure to maintain budgets, keep schedules from
Managers Network at slipping, and improve quality. Like a drowning person who grasps at a straw, a soft-
www.spmn.com
can help you dispel
ware manager often grasps at belief in a software myth, if that belief will lessen the
these and other myths. pressure (even temporarily).
Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they
need to know?
Reality: The book of standards may very well exist, but is it used? Are soft-
ware practitioners aware of its existence? Does it reflect modern
software engineering practice? Is it complete? Is it adaptable? Is it
streamlined to improve time-to-delivery while still maintaining a
focus on quality? In many cases, the answer to all of these questions
is “no.”
Myth: If we get behind schedule, we can add more programmers and catch up
(sometimes called the “Mongolian horde” concept).
Reality: Software development is not a mechanistic process like manufactur-
ing. In the words of Brooks [Bro95]: “adding people to a late soft-
ware project makes it later.” At first, this statement may seem
counterintuitive. However, as new people are added, people who
were working must spend time educating the newcomers, thereby
reducing the amount of time spent on productive development
effort. People can be added but only in a planned and well-
coordinated manner.
Myth: If I decide to outsource the software project to a third party, I can just
relax and let that firm build it.
Reality: If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it out-
sources software projects.
Customer myths. A customer who requests computer software may be a person
at the next desk, a technical group down the hall, the marketing/sales department,
or an outside company that has requested software under contract. In many cases,
the customer believes myths about software because software managers and prac-
titioners do little to correct misinformation. Myths lead to false expectations (by the
Work very hard to customer) and, ultimately, dissatisfaction with the developer.
understand what you
have to do before you Myth: A general statement of objectives is sufficient to begin writing
start. You may not be programs—we can fill in the details later.
able to develop every
Reality: Although a comprehensive and stable statement of requirements is
detail, but the more
you know, the less risk not always possible, an ambiguous “statement of objectives” is a
you take. recipe for disaster. Unambiguous requirements (usually derived
pre75977_ch01.qxd 11/27/08 3:11 PM Page 23
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 23
iteratively) are developed only through effective and continuous
communication between customer and developer.
Myth: Software requirements continually change, but change can be easily
accommodated because software is flexible.
Reality: It is true that software requirements change, but the impact of
change varies with the time at which it is introduced. When require-
ments changes are requested early (before design or code has been
started), the cost impact is relatively small.16 However, as time
passes, the cost impact grows rapidly—resources have been commit-
ted, a design framework has been established, and change can
cause upheaval that requires additional resources and major design
modification.
Practitioner’s myths. Myths that are still believed by software practitioners have
been fostered by over 50 years of programming culture. During the early days, pro-
Whenever you think, gramming was viewed as an art form. Old ways and attitudes die hard.
we don’t have time for
software engineering, Myth: Once we write the program and get it to work, our job is done.
ask yourself, “Will we Reality: Someone once said that “the sooner you begin ‘writing code,’ the
have time to do it over longer it’ll take you to get done.” Industry data indicate that between
again?”
60 and 80 percent of all effort expended on software will be ex-
pended after it is delivered to the customer for the first time.
Myth: Until I get the program “running” I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms
can be applied from the inception of a project—the technical review.
Software reviews (described in Chapter 15) are a “quality filter” that
have been found to be more effective than testing for finding certain
classes of software defects.
Myth: The only deliverable work product for a successful project is the working
program.
Reality: A working program is only one part of a software configuration that
includes many elements. A variety of work products (e.g., models,
documents, plans) provide a foundation for successful engineering
and, more important, guidance for software support.
Myth: Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about
creating a quality product. Better quality leads to reduced rework.
And reduced rework results in faster delivery times.
16 Many software engineers have adopted an “agile” approach that accommodates change incre-
mentally, thereby controlling its impact and cost. Agile methods are discussed in Chapter 3.
pre75977_ch01.qxd 11/27/08 3:11 PM Page 24
24 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING
Many software professionals recognize the fallacy of the myths just described.
Regrettably, habitual attitudes and methods foster poor management and technical
practices, even when reality dictates a better approach. Recognition of software
realities is the first step toward formulation of practical solutions for software
engineering.
1.7 H O W I T A L L S TA R T S
Every software project is precipitated by some business need—the need to correct a
defect in an existing application; the need to adapt a “legacy system” to a changing
business environment; the need to extend the functions and features of an existing
application; or the need to create a new product, service, or system.
At the beginning of a software project, the business need is often expressed
informally as part of a simple conversation. The conversation presented in the
sidebar is typical.
S AFE H OME 17
How a Project Starts Joe: How big . . . bottom line big?
The scene: Meeting room at CPI Mal (avoiding a direct commitment): Tell him
Corporation, a (fictional) company that makes consumer about our idea, Lisa.
products for home and commercial use. Lisa: It’s a whole new generation of what we call “home
The players: Mal Golden, senior manager, product management products.” We call ’em SafeHome. They use
development; Lisa Perez, marketing manager; Lee the new wireless interface, provide homeowners or small-
Warren, engineering manager; Joe Camalleri, executive business people with a system that’s controlled by their
VP, business development PC—home security, home surveillance, appliance and
device control—you know, turn down the home air
The conversation:
conditioner while you’re driving home, that sort of thing.
Joe: Okay, Lee, what’s this I hear about your folks
Lee (jumping in): Engineering’s done a technical
developing a what? A generic universal wireless box?
feasibility study of this idea, Joe. It’s doable at low
Lee: It’s pretty cool . . . about the size of a small manufacturing cost. Most hardware is off-the-shelf.
matchbook . . . we can attach it to sensors of all kinds, a Software is an issue, but it’s nothing that we can’t do.
digital camera, just about anything. Using the 802.11g
Joe: Interesting. Now, I asked about the bottom line.
wireless protocol. It allows us to access the device’s output
without wires. We think it’ll lead to a whole new Mal: PCs have penetrated over 70 percent of all
generation of products. households in the USA. If we could price this thing right,
it could be a killer-App. Nobody else has our wireless
Joe: You agree, Mal?
box . . . it’s proprietary. We’ll have a 2-year jump on
Mal: I do. In fact, with sales as flat as they’ve been this the competition. Revenue? Maybe as much as 30 to
year, we need something new. Lisa and I have been 40 million dollars in the second year.
doing a little market research, and we think we’ve got a
Joe (smiling): Let’s take this to the next level. I’m
line of products that could be big.
interested.
17 The SafeHome project will be used throughout this book to illustrate the inner workings of a project
team as it builds a software product. The company, the project, and the people are purely fictitious,
but the situations and problems are real.
