Lecture notes on Object-Oriented Software Engineering
Object-oriented software engineering an agile unified methodology and object oriented software engineering analysis and design advantages pdf free download
Dr.DavidWllker,United States,Professional
Published Date:11-07-2017
Your Website URL(Optional)
Comment
Software Engineering
A PRACTITIONER’S APPROACHCHAPTER
THE PRODUCT
1
KEY
he warnings began more than a decade before the event, but no one paid
CONCEPTS
much attention. With less than two years to the deadline, the media
application
Tpicked up the story. Then government officials voiced their concern, busi-
categories . . . . . . . 9
ness and industry leaders committed vast sums of money, and finally, dire warn-
component-based
ings of pending catastrophe penetrated the public’s consciousness. Software,
assembly. . . . . . . . . 8
in the guise of the now-infamous Y2K bug, would fail and, as a result, stop the
failure curves . . . . . 8
world as we then knew it.
history . . . . . . . . . . 5
As we watched and wondered during the waning months of 1999, I couldn’t
myths . . . . . . . . . . 12
help thinking of an unintentionally prophetic paragraph contained on the first
reuse . . . . . . . . . . . . 9
page of the fourth edition of this book. It stated:
software
characteristics . . . . 6
Computer software has become a driving force. It is the engine that drives business
software
decision making. It serves as the basis for modern scientific investigation and engi-
engineering . . . . . . 4
neering problem solving. It is a key factor that differentiates modern products and
wear . . . . . . . . . . . . 7
services. It is embedded in systems of all kinds: transportation, medical, telecom-
munications, military, industrial processes, entertainment, office products, . . . the
list is almost endless. Software is virtually inescapable in a modern world. And as
we move into the twenty-first century, it will become the driver for new advances in
everything from elementary education to genetic engineering.
What is it? Computer software is What are the steps? You build computer software
QUICK
the product that software engi- like you build any successful product, by apply-
LOOK
neers design and build. It encom- ing a process that leads to a high-quality result
passes programs that execute within a computer that meets the needs of the people who will use
of any size and architecture, documents that the product. You apply a software engineering
encompass hard-copy and virtual forms, and approach.
data that combine numbers and text but also What is the work product? From the point of view of
includes representations of pictorial, video, and a software engineer, the work product is the pro-
audio information. grams, documents, and data that are computer
Who does it? Software engineers build it, and virtu- software. But from the user’s viewpoint, the work
ally everyone in the industrialized world uses it product is the resultant information that somehow
either directly or indirectly. makes the user’s world better.
Why is it important? Because it affects nearly every How do I ensure that I’ve done it right? Read the
aspect of our lives and has become pervasive in remainder of this book, select those ideas appli-
our commerce, our culture, and our everyday cable to the software that you build, and apply
activities. them to your work.
34 PART ONE THE PRODUCT AND THE PROCESS
In the five years since the fourth edition of this book was written, the role of soft-
ware as the “driving force” has become even more obvious. A software-driven Inter-
net has spawned its own 500 billion economy. In the euphoria created by the promise
of a new economic paradigm, Wall Street investors gave tiny “dot-com” companies
billion dollar valuations before these start-ups produced a dollar in sales. New
software-driven industries have arisen and old ones that have not adapted to the new
driving force are now threatened with extinction. The United States government has
litigated against the software’s industry’s largest company, just as it did in earlier eras
when it moved to stop monopolistic practices in the oil and steel industries.
Software’s impact on our society and culture continues to be profound. As its
importance grows, the software community continually attempts to develop tech-
“Ideas and
nologies that will make it easier, faster, and less expensive to build high-quality com-
technological
puter programs. Some of these technologies are targeted at a specific application
discoveries are the
domain (e.g., Web-site design and implementation); others focus on a technology
driving engines of
economic growth.”
domain (e.g., object-oriented systems); and still others are broad-based (e.g., oper-
The Wall Street
ating systems such as LINUX). However, we have yet to develop a software technol-
Journal
ogy that does it all, and the likelihood of one arising in the future is small. And yet,
people bet their jobs, their comfort, their safety, their entertainment, their decisions,
and their very lives on computer software. It better be right.
This book presents a framework that can be used by those who build computer
software—people who must get it right. The technology encompasses a process, a
set of methods, and an array of tools that we call software engineering.
1.1 THE EVOLVING ROLE OF SOFTWARE
Today, software takes on a dual role. It is a product and, at the same time, the vehi-
cle for delivering a product. As a product, it delivers the computing potential embod-
ied by computer hardware or, more broadly, a network of computers that are accessible
by local hardware. Whether it resides within a cellular phone or operates inside a
mainframe computer, software is an information transformer—producing, manag-
Software is both a
ing, acquiring, modifying, displaying, or transmitting information that can be as sim-
product and a vehicle
ple as a single bit or as complex as a multimedia presentation. As the vehicle used
for delivering a
to deliver the product, software acts as the basis for the control of the computer (oper-
product.
ating systems), the communication of information (networks), and the creation and
control of other programs (software tools and environments).
Software delivers the most important product of our time—information. Software
transforms personal data (e.g., an individual’s financial transactions) so that the data
can be more useful in a local context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information networks (e.g., Inter-
net) and provides the means for acquiring information in all of its forms.
The role of computer software has undergone significant change over a time span
of little more than 50 years. Dramatic improvements in hardware performance, pro-CHAPTER 1 THE PRODUCT 5
found changes in computing architectures, vast increases in memory and storage
capacity, and a wide variety of exotic input and output options have all precipitated
more sophisticated and complex computer-based systems. Sophistication and com-
plexity can produce dazzling results when a system succeeds, but they can also pose
huge problems for those who must build complex systems.
Popular books published during the 1970s and 1980s provide useful historical
insight into the changing perception of computers and software and their impact on
our culture. Osborne OSB79 characterized a "new industrial revolution." Toffler
“For I dipped into the
future, far as the
TOF80 called the advent of microelectronics part of "the third wave of change" in
human eye could
human history, and Naisbitt NAI82 predicted a transformation from an industrial
see, Saw the vision
society to an "information society." Feigenbaum and McCorduck FEI83 suggested
of the world, and all
that information and knowledge (controlled by computers) would be the focal point
the wonder that
would be.” for power in the twenty-first century, and Stoll STO89 argued that the "electronic
Tennyson
community" created by networks and software was the key to knowledge interchange
throughout the world.
As the 1990s began, Toffler TOF90 described a "power shift" in which old power
structures (governmental, educational, industrial, economic, and military) disinte-
grate as computers and software lead to a "democratization of knowledge." Yourdon
“Computers make it
YOU92 worried that U.S. companies might loose their competitive edge in software-
easy to do a lot of
related businesses and predicted “the decline and fall of the American programmer.”
things, but most of
Hammer and Champy HAM93 argued that information technologies were to play a
the things that they
pivotal role in the “reengineering of the corporation.” During the mid-1990s, the per-
make it easier to do
don't need to be
vasiveness of computers and software spawned a rash of books by “neo-Luddites”
done.”
(e.g., Resisting the Virtual Life, edited by James Brook and Iain Boal and The Future
Andy Rooney
Does Not Compute by Stephen Talbot). These authors demonized the computer, empha-
sizing legitimate concerns but ignoring the profound benefits that have already been
realized. LEV95
During the later 1990s, Yourdon YOU96 re-evaluated the prospects for the
software professional and suggested the “the rise and resurrection” of the Ameri-
can programmer. As the Internet grew in importance, his change of heart proved
to be correct. As the twentieth century closed, the focus shifted once more, this
time to the impact of the Y2K “time bomb” (e.g., YOU98b, DEJ98, KAR99).
Although the predictions of the Y2K doomsayers were incorrect, their popular
writings drove home the pervasiveness of software in our lives. Today, “ubiquitous
computing” NOR98 has spawned a generation of information appliances that
have broadband connectivity to the Web to provide “a blanket of connectedness
over our homes, offices and motorways” LEV99. Software’s role continues to
expand.
The lone programmer of an earlier era has been replaced by a team of software
specialists, each focusing on one part of the technology required to deliver a com-
plex application. And yet, the same questions asked of the lone programmer are being
asked when modern computer-based systems are built:6 PART ONE THE PRODUCT AND THE PROCESS
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can't we find all the errors before we give the software to customers?
• Why do we continue to have difficulty in measuring progress as software is
being developed?
1
These, and many other questions, are a manifestation of the concern about soft-
ware and the manner in which it is developed—a concern that has lead to the adop-
tion of software engineering practice.
1.2 SOFTWARE
In 1970, less than 1 percent of the public could have intelligently described what
"computer software" meant. Today, most professionals and many members of the
public at large feel that they understand software. But do they?
A textbook description of software might take the following form: Software is (1)
instructions (computer programs) that when executed provide desired function and per-
How should
formance, (2) data structures that enable the programs to adequately manipulate infor-
?
we define
mation, and (3) documents that describe the operation and use of the programs. There
software?
is no question that other, more complete definitions could be offered. But we need
more than a formal definition.
1.2.1 Software Characteristics
To gain an understanding of software (and ultimately an understanding of software
engineering), it is important to examine the characteristics of software that make it
different from other things that human beings build. When hardware is built, the
human creative process (analysis, design, construction, testing) is ultimately trans-
lated into a physical form. If we build a new computer, our initial sketches, formal
design drawings, and breadboarded prototype evolve into a physical product (chips,
circuit boards, power supplies, etc.).
Software is a logical rather than a physical system element. Therefore, software
has characteristics that are considerably different than those of hardware:
1. Software is developed or engineered, it is not manufactured in the classical
sense.
Software is
Although some similarities exist between software development and hardware man-
engineered, not
manufactured.
ufacture, the two activities are fundamentally different. In both activities, high qual-
1 In an excellent book of essays on the software business, Tom DeMarco DEM95 argues the coun-
terpoint. He states: “Instead of asking ‘why does software cost so much?’ we need to begin ask-
ing ‘What have we done to make it possible for today’s software to cost so little?’ The answer to
that question will help us continue the extraordinary level of achievement that has always distin-
guished the software industry.”CHAPTER 1 THE PRODUCT 7
FIGURE 1.1
Failure curve
for hardware
“Infant “Wear out”
mortality”
Time
ity is achieved through good design, but the manufacturing phase for hardware can
introduce quality problems that are nonexistent (or easily corrected) for software.
Both activities are dependent on people, but the relationship between people applied
and work accomplished is entirely different (see Chapter 7). Both activities require
the construction of a "product" but the approaches are different.
Software costs are concentrated in engineering. This means that software proj-
ects cannot be managed as if they were manufacturing projects.
2. Software doesn't "wear out."
Software doesn’t wear
out, but it does
Figure 1.1 depicts failure rate as a function of time for hardware. The relationship,
deteriorate.
often called the "bathtub curve," indicates that hardware exhibits relatively high fail-
ure rates early in its life (these failures are often attributable to design or manufac-
turing defects); defects are corrected and the failure rate drops to a steady-state level
(ideally, quite low) for some period of time. As time passes, however, the failure rate
rises again as hardware components suffer from the cumulative affects of dust, vibra-
tion, abuse, temperature extremes, and many other environmental maladies. Stated
simply, the hardware begins to wear out.
Software is not susceptible to the environmental maladies that cause hardware to
wear out. In theory, therefore, the failure rate curve for software should take the form of
the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure
rates early in the life of a program. However, these are corrected (ideally, without intro-
ducing other errors) and the curve flattens as shown.The idealized curve is a gross over-
simplification of actual failure models (see Chapter 8 for more information) for software.
However, the implication is clear—software doesn't wear out. But it does deteriorate
This seeming contradiction can best be explained by considering the “actual curve”
shown in Figure 1.2. During its life, software will undergo change (maintenance). As
Failure rate8 PART ONE THE PRODUCT AND THE PROCESS
FIGURE 1.2
Increased failure
Idealized and
rate due to side
actual failure
effects
curves for
software
Change
Actual curve
Idealized curve
Software engineering
Time
methods strive to
reduce the magnitude
of the spikes and the
changes are made, it is likely that some new defects will be introduced, causing the
slope of the actual
failure rate curve to spike as shown in Figure 1.2. Before the curve can return to the
curve in Figure 1.2.
original steady-state failure rate, another change is requested, causing the curve to
spike again. Slowly, the minimum failure rate level begins to rise—the software is
deteriorating due to change.
Another aspect of wear illustrates the difference between hardware and software.
When a hardware component wears out, it is replaced by a spare part. There are no
software spare parts. Every software failure indicates an error in design or in the
process through which design was translated into machine executable code. There-
fore, software maintenance involves considerably more complexity than hardware
maintenance.
3. Although the industry is moving toward component-based assembly, most
Most software
software continues to be custom built.
continues to be
Consider the manner in which the control hardware for a computer-based product
custom built.
is designed and built. The design engineer draws a simple schematic of the digital
circuitry, does some fundamental analysis to assure that proper function will be
achieved, and then goes to the shelf where catalogs of digital components exist. Each
integrated circuit (called an IC or a chip) has a part number, a defined and validated
function, a well-defined interface, and a standard set of integration guidelines. After
each component is selected, it can be ordered off the shelf.
As an engineering discipline evolves, a collection of standard design components
is created. Standard screws and off-the-shelf integrated circuits are only two of thou-
sands of standard components that are used by mechanical and electrical engineers
as they design new systems. The reusable components have been created so that the
engineer can concentrate on the truly innovative elements of a design, that is, the
Failure rateCHAPTER 1 THE PRODUCT 9
parts of the design that represent something new. In the hardware world, component
reuse is a natural part of the engineering process. In the software world, it is some-
thing that has only begun to be achieved on a broad scale.
A software component should be designed and implemented so that it can be
reused in many different programs. In the 1960s, we built scientific subroutine libraries
XRef
that were reusable in a broad array of engineering and scientific applications. These
Software reuse is
subroutine libraries reused well-defined algorithms in an effective manner but had a
discussed in Chapter
limited domain of application. Today, we have extended our view of reuse to encom-
13. Component-based
software engineering is pass not only algorithms but also data structure. Modern reusable components encap-
presented in Chapter
sulate both data and the processing applied to the data, enabling the software engineer
27.
to create new applications from reusable parts. For example, today's graphical user
interfaces are built using reusable components that enable the creation of graphics
windows, pull-down menus, and a wide variety of interaction mechanisms. The data
structure and processing detail required to build the interface are contained with a
library of reusable components for interface construction.
1.2.2 Software Applications
Software may be applied in any situation for which a prespecified set of procedural
steps (i.e., an algorithm) has been defined (notable exceptions to this rule are expert
system software and neural network software). Information content and determinacy
are important factors in determining the nature of a software application. Content
refers to the meaning and form of incoming and outgoing information. For example,
many business applications use highly structured input data (a database) and pro-
duce formatted “reports.” Software that controls an automated machine (e.g., a
numerical control) accepts discrete data items with limited structure and produces
individual machine commands in rapid succession.
Information determinacy refers to the predictability of the order and timing of infor-
mation. An engineering analysis program accepts data that have a predefined order,
executes the analysis algorithm(s) without interruption, and produces resultant data
in report or graphical format. Such applications are determinate. A multiuser oper-
ating system, on the other hand, accepts inputs that have varied content and arbi-
trary timing, executes algorithms that can be interrupted by external conditions, and
produces output that varies as a function of environment and time. Applications with
these characteristics are indeterminate.
It is somewhat difficult to develop meaningful generic categories for software appli-
cations. As software complexity grows, neat compartmentalization disappears. The
following software areas indicate the breadth of potential applications:
System software. System software is a collection of programs written to service
other programs. Some system software (e.g., compilers, editors, and file manage-
ment utilities) process complex, but determinate, information structures. Other sys-
tems applications (e.g., operating system components, drivers, telecommunications10 PART ONE THE PRODUCT AND THE PROCESS
processors) process largely indeterminate data. In either case, the system software
area is characterized by heavy interaction with computer hardware; heavy usage by
multiple users; concurrent operation that requires scheduling, resource sharing, and
sophisticated process management; complex data structures; and multiple external
interfaces.
Real-time software. Software that monitors/analyzes/controls real-world events
as they occur is called real time. Elements of real-time software include a data gath-
ering component that collects and formats information from an external environ-
ment, an analysis component that transforms information as required by the
application, a control/output component that responds to the external environment,
and a monitoring component that coordinates all other components so that real-time
response (typically ranging from 1 millisecond to 1 second) can be maintained.
Business software. Business information processing is the largest single software
application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inven-
tory) have evolved into management information system (MIS) software that accesses
one or more large databases containing business information. Applications in this
area restructure existing data in a way that facilitates business operations or man-
One of the most
comprehensive libraries of agement decision making. In addition to conventional data processing application,
shareware/freeware can
business software applications also encompass interactive computing (e.g., point-
be found at
of-sale transaction processing).
www.shareware.com
Engineering and scientific software. Engineering and scientific software have
been characterized by "number crunching" algorithms. Applications range from astron-
omy to volcanology, from automotive stress analysis to space shuttle orbital dynam-
ics, and from molecular biology to automated manufacturing. However, modern
applications within the engineering/scientific area are moving away from conven-
tional numerical algorithms. Computer-aided design, system simulation, and other
interactive applications have begun to take on real-time and even system software
characteristics.
Embedded software. Intelligent products have become commonplace in nearly
every consumer and industrial market. Embedded software resides in read-only mem-
ory and is used to control products and systems for the consumer and industrial mar-
kets. Embedded software can perform very limited and esoteric functions (e.g., keypad
control for a microwave oven) or provide significant function and control capability
(e.g., digital functions in an automobile such as fuel control, dashboard displays, and
braking systems).
Personal computer software. The personal computer software market has bur-
geoned over the past two decades. Word processing, spreadsheets, computer graph-
ics, multimedia, entertainment, database management, personal and business financial
applications, external network, and database access are only a few of hundreds of
applications.
Web-based software. The Web pages retrieved by a browser are software that
incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g.,CHAPTER 1 THE PRODUCT 11
hypertext and a variety of visual and audio formats). In essence, the network becomes
a massive computer providing an almost unlimited software resource that can be
accessed by anyone with a modem.
Artificial intelligence software. Artificial intelligence (AI) software makes use
of nonnumerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis. Expert systems, also called knowledge-
based systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing are representative of applications within this
category.
1.3 SOFTWARE: A CRISIS ON THE HORIZON?
Many industry observers (including this author) have characterized the problems
associated with software development as a "crisis." More than a few books (e.g.,
GLA97, FLO97, YOU98a) have recounted the impact of some of the more spec-
tacular software failures that have occurred over the past decade. Yet, the great suc-
“The most likely way
cesses achieved by the software industry have led many to question whether the term
for the world to be
software crisis is still appropriate. Robert Glass, the author of a number of books on
destroyed, most
software failures, is representative of those who have had a change of heart. He states
experts agree, is by
GLA98: “I look at my failure stories and see exception reporting, spectacular fail-
accident. That's
where we come in; ures in the midst of many successes, a cup that is now nearly full.”
we're computer
It is true that software people succeed more often than they fail. It also true that
professionals. We
the software crisis predicted 30 years ago never seemed to materialize. What we
cause accidents.”
really have may be something rather different.
Nathaniel
The word crisis is defined in Webster's Dictionary as “a turning point in the course of
Borenstein
anything; decisive or crucial time, stage or event.” Yet, in terms of overall software qual-
ity and the speed with which computer-based systems and products are developed,
there has been no "turning point," no "decisive time," only slow, evolutionary change,
punctuated by explosive technological changes in disciplines associated with software.
The word crisis has another definition: "the turning point in the course of a disease,
when it becomes clear whether the patient will live or die." This definition may give us
a clue about the real nature of the problems that have plagued software development.
2
What we really have might be better characterized as a chronic affliction. The
word affliction is defined as "anything causing pain or distress." But the definition of
the adjective chronic is the key to our argument: "lasting a long time or recurring
often; continuing indefinitely." It is far more accurate to describe the problems we
have endured in the software business as a chronic affliction than a crisis.
Regardless of what we call it, the set of problems that are encountered in the devel-
opment of computer software is not limited to software that "doesn't function
2 This terminology was suggested by Professor Daniel Tiechrow of the University of Michigan in a
talk presented in Geneva, Switzerland, April 1989.12 PART ONE THE PRODUCT AND THE PROCESS
properly." Rather, the affliction encompasses problems associated with how we
develop software, how we support a growing volume of existing software, and how
we can expect to keep pace with a growing demand for more software.
We live with this affliction to this day—in fact, the industry prospers in spite of it.
And yet, things would be much better if we could find and broadly apply a cure.
1.4 SOFTWARE MYTHS
Many causes of a software affliction can be traced to a mythology that arose during
the early history of software development. Unlike ancient myths that often provide
human lessons well worth heeding, software myths propagated misinformation and
“In the absence of
confusion. Software myths had a number of attributes that made them insidious; for
meaningful standards,
instance, they appeared to be reasonable statements of fact (sometimes containing
a new industry like
software comes to
elements of truth), they had an intuitive feel, and they were often promulgated by
depend instead on
experienced practitioners who "knew the score."
folklore.”
Today, most knowledgeable professionals recognize myths for what they are—
Tom DeMarco
misleading attitudes that have caused serious problems for managers and technical
people alike. However, old attitudes and habits are difficult to modify, and remnants
of software myths are still believed.
Management myths. Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep schedules from slip-
ping, and improve quality. Like a drowning person who grasps at a straw, a software
manager often grasps at belief in a software myth, if that belief will lessen the pres-
sure (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 software
practitioners aware of its existence? Does it reflect modern software engineering prac-
tice? Is it complete? Is it streamlined to improve time to delivery while still main-
taining a focus on quality? In many cases, the answer to all of these questions is "no."
Myth: My people have state-of-the-art software development tools, after all, we
buy them the newest computers.
Reality: It takes much more than the latest model mainframe, workstation, or PC
to do high-quality software development. Computer-aided software engineering
(CASE) tools are more important than hardware for achieving good quality and pro-
ductivity, yet the majority of software developers still do not use them effectively.
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 manufacturing.
In the words of Brooks BRO75: "adding people to a late software project makes itCHAPTER 1 THE PRODUCT 13
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. Peo-
ple can be added but only in a planned and well-coordinated manner.
The Software Project
Managers Network at
3
Myth: If I decide to outsource the software project to a third party, I can just relax
www.spmn.com can
and let that firm build it.
help you dispel these and
other myths.
Reality: If an organization does not understand how to manage and control software
projects internally, it will invariably struggle when it outsources 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
customer) and ultimately, dissatisfaction with the developer.
Myth: A general statement of objectives is sufficient to begin writing programs—
we can fill in the details later.
Work very hard to
Reality: A poor up-front definition is the major cause of failed software efforts. A
understand what you
formal and detailed description of the information domain, function, behavior, per-
have to do before you
start. You may not be formance, interfaces, design constraints, and validation criteria is essential. These
able to develop every
characteristics can be determined only after thorough communication between cus-
detail, but the more
tomer and developer.
you know, the less risk
you take. Myth: Project requirements continually change, but change can be easily accom-
modated 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. Figure 1.3 illustrates the impact of
change. If serious attention is given to up-front definition, early requests for change
can be accommodated easily. The customer can review requirements and recom-
mend modifications with relatively little impact on cost. When changes are requested
XRef
The management and during software design, the cost impact grows rapidly. Resources have been com-
control of change is
mitted and a design framework has been established. Change can cause upheaval
considered in detail in
that requires additional resources and major design modification, that is, additional
Chapter 9.
cost. Changes in function, performance, interface, or other characteristics during
implementation (code and test) have a severe impact on cost. Change, when requested
after software is in production, can be over an order of magnitude more expensive
than the same change requested earlier.
3 The term “outsourcing” refers to the widespread practice of contracting software development
work to a third party—usually a consulting firm that specializes in building custom software for
its clients.14 PART ONE THE PRODUCT AND THE PROCESS
FIGURE 1.3
60–100×
The impact of
change
1.5–6×
1×
Definition Development After release
Practitioner's myths. Myths that are still believed by software practitioners have
been fostered by 50 years of programming culture. During the early days of software,
programming was viewed as an art form. Old ways and attitudes die hard.
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that "the sooner you begin 'writing code', the longer
it'll take you to get done." Industry data (LIE80, JON91, PUT97) indicate that
between 60 and 80 percent of all effort expended on software will be expended 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
Whenever you think,
applied from the inception of a project—the formal technical review. Software reviews
we don’t have time for
(described in Chapter 8) are a "quality filter" that have been found to be more effec-
software engineering
discipline, ask yourself: tive than testing for finding certain classes of software defects.
“Will we have time to
Myth: The only deliverable work product for a successful project is the working
do it over again?”
program.
Reality: A working program is only one part of a software configuration that includes
many elements. Documentation provides a foundation for successful engineering
and, more important, guidance for software support.
Myth: Software engineering will make us create voluminous and unnecessary doc-
umentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creat-
ing quality. Better quality leads to reduced rework. And reduced rework results in
faster delivery times.
Many software professionals recognize the fallacy of the myths just described. Regret-
tably, 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.
Cost to changeCHAPTER 1 THE PRODUCT 15
1.5 SUMMARY
Software has become the key element in the evolution of computer-based systems
and products. Over the past 50 years, software has evolved from a specialized prob-
lem solving and information analysis tool to an industry in itself. But early “pro-
gramming” culture and history have created a set of problems that persist today.
Software has become the limiting factor in the continuing evolution of computer-
based systems. Software is composed of programs, data, and documents. Each of
these items comprises a configuration that is created as part of the software engi-
neering process. The intent of software engineering is to provide a framework for
building software with higher quality.
REFERENCES
BRO75 Brooks, F., The Mythical Man-Month, Addison-Wesley, 1975.
DEJ98 De Jager, P. et al., Countdown Y2K: Business Survival Planning for the Year
2000, Wiley, 1998.
DEM95 DeMarco, T., Why Does Software Cost So Much? Dorset House, 1995, p. 9.
FEI83 Feigenbaum, E.A. and P. McCorduck, The Fifth Generation, Addison-
Wesley, 1983.
FLO97 Flowers, S., Software Failure, Management Failure—Amazing Stories and
Cautionary Tales, Wiley, 1997.
GLA97 Glass, R.L., Software Runaways, Prentice-Hall, 1997.
GLA98 Glass, R.L., “Is There Really a Software Crisis?” IEEE Software, vol. 15,
no. 1, January 1998, pp. 104–105.
HAM93 Hammer, M., and J. Champy, Reengineering the Corporation, HarperCollins
Publishers, 1993.
JON91 Jones, C., Applied Software Measurement, McGraw-Hill, 1991.
KAR99 Karlson, E. and J. Kolber, A Basic Introduction to Y2K: How the Year 2000
Computer Crisis Affects YOU, Next Era Publications, 1999.
LEV95 Levy, S., “The Luddites Are Back,” Newsweek, July 12, 1995, p. 55.
LEV99 Levy, S., “The New Digital Galaxy,” Newsweek, May 31, 1999, p. 57.
LIE80 Lientz, B. and E. Swanson, Software Maintenance Management, Addison-
Wesley, 1980.
NAI82 Naisbitt, J., Megatrends, Warner Books, 1982.
NOR98 Norman, D., The Invisible Computer, MIT Press, 1998.
OSB79 Osborne, A., Running Wild—The Next Industrial Revolution,
Osborne/McGraw-Hill, 1979.
PUT97 Putnam, L. and W. Myers, Industrial Strength Software, IEEE Computer
Society Press, 1997.
STO89 Stoll, C., The Cuckoo's Egg, Doubleday, 1989.
TOF80 Toffler, A., The Third Wave, Morrow, 1980.16 PART ONE THE PRODUCT AND THE PROCESS
TOF90 Toffler, A., Powershift, Bantam Publishers, 1990.
YOU92 Yourdon, E., The Decline and Fall of the American Programmer, Yourdon
Press, 1992.
YOU96 Yourdon, E., The Rise and Resurrection of the American Programmer, Your-
don Press, 1996.
YOU98a Yourdon, E., Death March Projects, Prentice-Hall, 1998.
YOU98b Yourdon, E. and J. Yourdon, Time Bomb 2000, Prentice-Hall, 1998.
PROBLEMS AND POINTS TO PONDER
1.1. Software is the differentiating characteristic in many computer-based products
and systems. Provide examples of two or three products and at least one system in
which software, not hardware, is the differentiating element.
1.2. In the 1950s and 1960s, computer programming was an art form learned in an
apprenticelike environment. How have the early days affected software development
practices today?
1.3. Many authors have discussed the impact of the "information era." Provide a
number of examples (both positive and negative) that indicate the impact of software
on our society. Review one of the pre-1990 references in Section 1.1 and indicate
where the author’s predictions were right and where they were wrong.
1.4. Choose a specific application and indicate: (a) the software application category
(Section 1.2.2) into which it fits; (b) the data content associated with the application;
and (c) the information determinacy of the application.
1.5. As software becomes more pervasive, risks to the public (due to faulty pro-
grams) become an increasingly significant concern. Develop a realistic doomsday
scenario (other than Y2K) where the failure of a computer program could do great
harm (either economic or human).
1.6. Peruse the Internet newsgroup comp.risks and prepare a summary of risks to
the public that have recently been discussed. An alternate source is Software Engi-
neering Notes published by the ACM.
1.7. Write a paper summarizing recent advances in one of the leading edge soft-
ware application areas. Potential choices include: advanced Web-based applications,
virtual reality, artificial neural networks, advanced human interfaces, intelligent agents.
1.8. The “myths” noted in Section 1.4 are slowly fading as the years pass, but oth-
ers are taking their place. Attempt to add one or two “new” myths to each category. CHAPTER 1 THE PRODUCT 17
FURTHER READINGS AND INFORMATION SOURCES
Literally thousands of books are written about computer software. The vast major-
ity discuss programming languages or software applications, but a few discuss soft-
ware itself. Pressman and Herron (Software Shock, Dorset House, 1991) presented an
early discussion (directed at the layperson) of software and the way professionals
build it.
Negroponte's (Being Digital, Alfred A. Knopf, 1995) best-selling book provides a
view of computing and its overall impact in the twenty-first century. Books by Nor-
man NOR98 and Bergman (Information Appliances and Beyond, Academic Press/Mor-
gan Kaufmann, 2000) suggest that the widespread impact of the PC will decline as
information appliances and pervasive computing connect everyone in the indus-
trialized world and almost every “appliance” that they own to a new Internet
infrastructure.
Minasi (The Software Conspiracy: Why Software Companies Put out Faulty Products,
How They Can Hurt You, and What You Can Do, McGraw-Hill, 2000) argues that the
“modern scourge” of software bugs can be eliminated and suggests ways to accom-
plish this. DeMarco (Why Does Software Cost So Much? Dorset House, 1995) has pro-
duced a collection of amusing and insightful essays on software and the process
through which it is developed.
A wide variety of information sources on software-related topics and manage-
ment is available on the Internet. An up-to-date list of World Wide Web references
that are relevant to software can be found at the SEPA Web site:
http://www.mhhe.com/engcs/compsci/pressman/resources/product.mhtmlCHAPTER
THE PROCESS
2
KEY
n a fascinating book that provides an economist’s view of software and soft-
CONCEPTS
ware engineering, Howard Baetjer, Jr. BAE98, comments on the software
common process
Iprocess:
framework . . . . . . 23
component-based
Because software, like all capital, is embodied knowledge, and because that knowl-
development. . . . . 42
edge is initially dispersed, tacit, latent, and incomplete in large measure, software
concurrent
development is a social learning process. The process is a dialogue in which the
development. . . . . 40
knowledge that must become the software is brought together and embodied in the
evolutionary process
software. The process provides interaction between users and designers, between
models. . . . . . . . . . 34
users and evolving tools, and between designers and evolving tools technology. It
formal methods . . 43
is an iterative process in which the evolving tool itself serves as the medium for com-
4GT . . . . . . . . . . . . 44
munication, with each new round of the dialogue eliciting more useful knowledge
maintenance
from the people involved.
activities . . . . . . . 21
process maturity
Indeed, building computer software is an iterative learning process, and the
levels. . . . . . . . . . . 24
outcome, something that Baetjer would call “software capital,” is an embodi-
prototyping . . . . . 30
ment of knowledge collected, distilled, and organized as the process is con-
RAD. . . . . . . . . . . . 32
ducted.
software
engineering. . . . . . 20
What is it? When you build a building. One process might be appropriate for
QUICK
product or system, it’s important creating software for an aircraft avionics system,
LOOK
to go through a series of pre- while an entirely different process would be indi-
dictable steps—a road map that helps you create cated for the creation of a Web site.
a timely, high-quality result. The road map that What is the work product? From the point of view
you follow is called a ‘software process.’ of a software engineer, the work products are the
Who does it? Software engineers and their man- programs, documents, and data produced as a
agers adapt the process to their needs and then consequence of the software engineering activi-
follow it. In addition, the people who have ties defined by the process.
requested the software play a role in the software How do I ensure that I’ve done it right? A number of
process. software process assessment mechanisms enable
Why is it important? Because it provides stability, organizations to determine the “maturity” of a
control, and organization to an activity that can, software process. However, the quality, timeliness,
if left uncontrolled, become quite chaotic. and long-term viability of the product you build
What are the steps? At a detailed level, the process are the best indicators of the efficacy of the process
that you adopt depends on the software you’re that you use.
1920 PART ONE THE PRODUCT AND THE PROCESS
But what exactly is a software process from a technical point of view? Within the
context of this book, we define a software process as a framework for the tasks that
are required to build high-quality software. Is process synonymous with software engi-
neering? The answer is “yes” and “no.” A software process defines the approach that
is taken as software is engineered. But software engineering also encompasses tech-
nologies that populate the process—technical methods and automated tools.
More important, software engineering is performed by creative, knowledgeable
people who should work within a defined and mature software process that is appro-
priate for the products they build and the demands of their marketplace. The intent
of this chapter is to provide a survey of the current state of the software process and
pointers to more detailed discussion of management and technical topics presented
later in this book.
2.1 SOFTWARE ENGINEERING: A LAYERED TECHNOLOGY
Although hundreds of authors have developed personal definitions of software engi-
neering, a definition proposed by Fritz Bauer NAU69 at the seminal conference on
“More than a
the subject still serves as a basis for discussion:
discipline or a body
Software engineering is the establishment and use of sound engineering principles in
of knowledge,
engineering is a
order to obtain economically software that is reliable and works efficiently on real machines.
verb, an action
Almost every reader will be tempted to add to this definition. It says little about the
word, a way of
approaching a
technical aspects of software quality; it does not directly address the need for cus-
problem.”
tomer satisfaction or timely product delivery; it omits mention of the importance of
Scott Whitmire
measurement and metrics; it does not state the importance of a mature process. And
yet, Bauer’s definition provides us with a baseline. What “sound engineering princi-
ples” can be applied to computer software development? How do we “economically”
build software so that it is “reliable”? What is required to create computer programs
that work “efficiently” on not one but many different “real machines”? These are the
questions that continue to challenge software engineers.
The IEEE IEE93 has developed a more comprehensive definition when it states:
How do we
Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach
?
define
to the development, operation, and maintenance of software; that is, the application of
software
engineering to software. (2) The study of approaches as in (1).
engineering?
2.1.1 Process, Methods, and Tools
Software engineering is a layered technology. Referring to Figure 2.1, any engineer-
ing approach (including software engineering) must rest on an organizational com-
mitment to quality. Total quality management and similar philosophies foster a
continuous process improvement culture, and this culture ultimately leads to theCHAPTER 2 THE PROCESS 21
FIGURE 2.1
Software Tools
engineering
layers
Methods
Process
A quality focus
development of increasingly more mature approaches to software engineering. The
bedrock that supports software engineering is a quality focus.
The foundation for software engineering is the process layer. Software engineer-
ing process is the glue that holds the technology layers together and enables rational
and timely development of computer software. Process defines a framework for a set
of key process areas (KPAs) PAU93 that must be established for effective delivery of
software engineering technology. The key process areas form the basis for manage-
ment control of software projects and establish the context in which technical meth-
ods are applied, work products (models, documents, data, reports, forms, etc.) are
produced, milestones are established, quality is ensured, and change is properly man-
aged.
Software engineering methods provide the technical how-to's for building soft-
ware. Methods encompass a broad array of tasks that include requirements analy-
sis, design, program construction, testing, and support. Software engineering methods
Software engineering
rely on a set of basic principles that govern each area of the technology and include
encompasses a
modeling activities and other descriptive techniques.
process, management
Software engineering tools provide automated or semi-automated support for the
and technical methods,
and tools.
process and the methods. When tools are integrated so that information created by
one tool can be used by another, a system for the support of software development,
called computer-aided software engineering, is established. CASE combines software,
hardware, and a software engineering database (a repository containing important
information about analysis, design, program construction, and testing) to create a
software engineering environment analogous to CAD/CAE (computer-aided
design/engineering) for hardware.
2.1.2 A Generic View of Software Engineering
Engineering is the analysis, design, construction, verification, and management of
technical (or social) entities. Regardless of the entity to be engineered, the following
questions must be asked and answered:
• What is the problem to be solved?
• What characteristics of the entity are used to solve the problem?
Advise:Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.