Software Engineering (phần 1) ppt

toxTzxTs
Preface xv
R A R Y ;
Introduction to Software
Engineering 1
f h l p :e r 1
The Scope of Software
Engineering 3
l .1 Historical A spects 4
l .2 Econom ic Aspects 7
l .3 M aintenance Aspects 8
l .4 Specihcation and Design Aspects
l .5 Team Programm ing A spects 15
l .6 The Object-oriented Paradigm l 7
l .7 Terminology 21
Chapter Review 23
For Further Reading 24
Problems 25
References 26
f h l p :e r 2
The Softw are Process 30
lmplementation Phase 40
2.5.1 lmplementation Phase
Testing 40
lmplementation Phase
Documentation 40
lntegration Phase 41
2.6.1 lntegration Phase Testing
2.6.2 lntegration Phase
Documentation 42
M aintenance Phase 42

M aintenance Phase Testing
M aintenance Phase
Documentation 43
Retirement 43
Problems with Softw are Production:
Essence and Accidents 214.
2.9.1 Complexity 45
2.9.2 Conformity 47
2.9.3 Changeability 48
2.9.4 lnvisibility 49
2.9.5 No Silver Bullet? 50
2. 10 lmproving the Softw are Process 51
2. l l Capability M at-urity M odels 51
2. 12 Other Software Process
lmprovement lnitiatives 54
2.13 Costs and Benehts of Software
Process lm provement 55
Chapter Review 57
For Further Reading 58
Problem s 59
References 60
f h l p :e r a
Software Life-cycle M odels 64
Build-and-Fix M odel 64
W aterfall M odel 65
3.2.1 Analysis of the
W aterfall M odel 68
vii
Client, Developer, and User
Requirem ents Phase 33

2.2.1 Requirements Phase Testing 34
2.2.2 Requirements Phase
Documentation 35
Specihcation Phase 35
2.3.1 Specilication Phase Testing
2.3.2 Specilication Phase
Documentation 38
Design Phase 38
2.4.1 Design Phase Testing
2.4.2 Design Phase
Documentation 40
Please purchase Image To PDF Converter on to remove this message, thank you.
vIII
Rapid Prototyping M odel 70
3.3.1 lntegrating the W aterfall and
Rapid Prototyping M odels 71
lncremental M odel 72
3.4.1 Analysis of the
lncremental M odel 73
3.5 Extreme Programming 75
3.6 Synchronize-and-stabilize M odel
3.7 Spiral M odel 78
3.7.1 Analysis of the Spiral M odel 82
Object-oriented
Life-cycle M odels 82
3.9 Comparison of Life-cycle M odels
Chapter Review 86
For Further Reading 86
Problems 87
References 87

f h l p :e r 4
Team s 90
Team Organization 90
Democratic Team Approach 92
4.2.1 Analysis of the Democratic
Team Approach 93
Classical Chief Programmer
Team Approach 93
4.3.1 The New Ftpr/c Iimes Project 95
4.3.2 lmpracticality of the
Classical Chief
Programmer Team Approach 96
Beyond Chief Programmer
and Democratic Teams 97
4.5 Synchronize-and-stabilize Teams l0l
4.6 Extreme Programming Team s l02
Chapter Review l03
For Further Reading 104
Problems 104
References 105
CONTENTS
5.4 CASE l 15
5.5 Taxonomy of CASE 1 16
5.6 Scope of CASE l 18
5.7 Software Versions l22
5.7.1 Revisions l22
5.7.2 Variations l23
Conhguration Control l24
5.8.1 Conliguration Control during
Product M aintenance l26

Baselines l27
Conliguration Control during
Product Development l27
Build Tools l28
Productivity Gains with
CASE Technology l29
Chapter Review l 31
For Further Reading 13l
Problems l 32
References l 33
f h l p :e r l
Testing 136
f h l p :e r S
The Tools of the Trade 106
Stepwise Rehnement 106
5.1.1 Stepwise Relinement Example
Cost-Benefit Analysis 1 l 3
Software M etrics 1 14
Quality lssues 137
6.l .1 Software Quality Assurance l37
6.l .2 M anagerial lndependence 138
Nonexecution-Based Testing 139
6.2.1 W alkthroughs l39
6.2.2 M anaging W alkthroughs
6.2.3 lnspections 141
6.2.4 Comparison of lnspections
and W alkthroughs l43
Strengths and W eaknesses
of Reviews l44
6.2.6 M etrics for lnspections l44

Execution-Based Testing 145
W 'hat Should Be Tested? 145
6.4.1 Utility l46
6.4.2 Reliability l47
6.4.3 Robustness 147
6.4.4 Performance l48
6.4.5 Correctness l49
Testing versus Correctness Proofs
6.5.1 Exam ple of a Correctness
Proof l5l
Correctness Proof
Case Smdy l54
Please purchase Image To PDF Converter on to remove this message, thank you.
CONTENTS I;t
Correctness Proof and
Software Engineering
W ho Should Perform
Execution-Based Testing? l58
6.7 W hen Testing Stops l60
Chapter Review l 60
For Further Reading l 6 l
Problems l62
References l 64
f h l p :e r V
From M odules to Objects 167
W hat ls a M odule?
Cohesion 17 l
7.2.1 Coincidental Cohesion l7l
7.2.2 Logical Cohesion l72
7.2.3 Tem poral Cohesion l73

7.2.4 Procedural Cohesion l74
7.2.5 Communicational Cohesion
7.2.6 Functional Cohesion l75
7.2.7 lnform ational Cohesion l75
7.2.8 Cohesion Example l76
Coupling 177
7.3.1 Content Coupling l78
7.3.2 Common Coupling l78
7.3.3 Control Coupling 180
7.3.4 Stamp Coupling l80
7.3.5 Data Coupling l82
7.3.6 Coupling Example l82
7.3.7 The lmportance of Coupling
Data Encapsulation 184
7.4.1 Data Encapsulation and
Product Development 186
Data Encapsulation and
Product M aintenance l88
7.5 Abstract Data Types 194
7.6 lnfrom ation Hiding 195
7.7 Objects 198
7.8 lnheritance, Polymorphism,
and Dynamic Binding 20 1
7.9 Cohesion and Coupling of Objects 203
7.10 The Object-oriented Paradigm 204
Chapter Review 207
For Further Reading 207
Problems 208
References 209
f h l p :e r a

Reusability, Portpbility,
and Interoperabllity 212
8. l Reuse Concepts 2l2
8.2 lm pediments to Reuse 214
8.3 Reuse Case St-udies 2 l 6
8.3.1 Raytheon M issile
Systems Division 2l6
8.3.2 Toshiba Software Factory
8.3.3 NASA Software 2l8
8.3.4 GTE Data Services 2l9
8.3.5 Hewlett-packard 220
8.3.6 European 'Space Agency 221
Objects and Reuse 222
Reuse during the Design and
lmplementation Phases 222
8.5.1 Design Reuse 222
8.5.2 Application Frameworks
8.5.3 Design Patterns 225
8.5.4 Software Architecmre 229
Reuse and M aintenance 230
Portability 23 l
8.7.1 Hardware lncompatibilities
8.7.2 Operating Systems
lncompatibilities 233
8.7.3 Numerical Software
lncompatibilities 233
8.7.4 Compiler lncompatibilities
W'hy Portability? 239
Techniques for
Achieving Portability 240

8.9.1 Portable System Software 240
8.9.2 Portable Application
Software 24l
8.9.3 Portable Data 242
lnteroperability 243
8.10.1 COM .243
8.10.2 CORBA 244
8.10.3 Comparing COM
and CORBA 245
Fut-ure Trends in
lnteroperability 245
Chapter Review 246
For Further Reading 247
Problem s 248
References 250
Please purchase Image To PDF Converter on to remove this message, thank you.
x
f h l p :e r @
Planning and Estim ating 257
Planning and the Software Process 257
Estimating Duration and Cost 259
9.2.1 M etrics for the Size
of a Product 260
Techniques of Cost
Estim ation 264
9.2.3 lntermediate COCOM O
9.2.4 COCOM O 11 270
9.2.5 Tracking Duration and
Cost Estimates 272
Components of a Software Project

M anagement Plan 272
Software Project
M anagement Plan Framework
IEEE Software Project
M anagement Plan 274
Planning Testing 278
Planning Object-oriented
Projects 279
9.8 Training Requirem ents 280
9.9 D ocumentation Standards 28 l
9.10 CASE Tools for Planning
and Estimating 282
Testing the Software Project
M anagem ent Plan 282
Chapter Review 283
For Further Reading 283
Problems 284
References 285
CONTENTS
Other Requirements Elicitation
Techniques 293
10.2 Requirem ents Analysis 294
10.3 Rapid Prototyping 294
10.4 Human Factors 296
10.5 Rapid Prototyping as a
Specihcation Technique 298
10.6 Reusing the Rapid Prototype 300
10.7 M anagem ent lm plications of the
Rapid Prototyping M odel 302
Experiences w ith Rapid

Prototyping 304
Techniques for Requirements
Elicitation and Analysis 305
Testing during the
Requirem ents Phase 305
CASE Tools for the
Requirem ents Phase 306
M etrics for the
Requirem ents Phase 307
l0. l 3 Object-oriented Requirements? 308
10.14 Air Gourm et Case St-udy:
Requirem ents Phase 308
Air Gourmet Case St-udy:
Rapid Prototype 31 l
Challenges of the
Requirements Phase
Chapter Review 3 15
For Further Reading 3 15
Problems 3l6
References 3 17
f h l p :e r 11
Specification Phase 319
1 1. l The Specihcation Docum ent
1 1.2 lnform al Specihcations 32 l
l l .2.1 Case Smdy:
Text Processing 322
Struct-ured Systems Analysis 323
l l .3.1 Sally's Software Shop 323
1 1.4 Other Semiformal Techniques 33 l
1 1.5 Entity-Relationship M odeling 332

1 1.6 Finite State M achines 335
l l .6.1 Elevator Problem : Finite
State M achines 336
R A R q' V
The Phases of the Software
Life Cycle 289
f h l p :e r 1@
Requirem ents Phase 290
Requirements Elicitation 29 l
10.1 .1 lnterviews 29 l
10.1 .2 Scenarios 292
Please purchase Image To PDF Converter on to remove this message, thank you.
CONTENTS xI
Petri Nets 34l
l l .7.1 Elevator Problem :
Petri Nets 343
Z 346
l l .8.1 Elevator Problem : Z 347
l l .8.2 Analysis of Z 349
l l .9 Other Fonnal Techniques 35l
l l .l0 Com parison of
Specihcation Techniques
Testing during the
Specihcation Phase 353
CA SE Tools for the
Specihcation Phase 354
M etrics for the
Specihcation Phase 355
Air Gourm et Case Study:
Structured Systems Analysis 355

Air Gourm et Case Study:
Software Project M anagement
Plan 357
Challenges of the
Specihcation Phase
Chapter Review 358
For Further Reading 359
Problem s 360
References 362
12.9 Challenges of the
Object-oriented Analysis Phase 390
Chapter Review 39l
For Further Reading 39 l
Problem s 392
References 393
f h l p :e r la
Design Phase 395
l3. l Design and Abstraction 395
13.2 Action-oriented Design 396
13.3 Data Flow Analysis 397
13.3.1 Data Flow Analysis
Example 398
13.3.2 Extensions 402
13.4 Transaction Analysis 403
13.5 Data-oriented Design 406
13.6 Object-oriented Design 406
13.7 Elevator Problem :
Object-oriented Design 407
13.8 Form al Techniques for
Detailed Design 4l5

13.9 Real l-ime Design Techniques 41 6
l3. 10 Testing during the Design Phase 41 8
13.1 l CASE Tools for the
Design Phase 41 8
l3. 12 M etrics for the Design Phase
l3. 13 AP Gourm et Case St-udy:
Object-oriented Design 420
l3. 14 Challenges of the Design Phase 429
Chapter Review 429
For Further Reading 430
Problem s 43 l
References 43 l
f h l p :e r 12
Object-oriented
A nalysis Phase 366
Object-oriented Analysis 366
Elevator Problem :
Object-oriented Analysis
12.3 Use-case M odeling 369
12.4 Class M odeling 37l
12.4.1 Noun Extraction 372
12.4.2 CRC Cards 374
Dynamic M odeling 375
Testing during the
Object-oriented Analysis Phase 378
CA SE Tools for the
Object-oriented Analysis Phase 383
Air Gounnet Case Study:
Object-oriented Analysis 383
f h l p :e r 14

Im plem entation Phase 434
l4. l Choice of Programming Language 434
14.2 Fourth-Generation Languages 437
14.3 Good Programming Practice 440
14.4 Coding Standards 445
14.5 M odule Reuse 446
Please purchase Image To PDF Converter on to remove this message, thank you.
xII
M odule Test Case Selection 447
14.6.1 Testing to Specilications
versus Testing to Code 447
Feasibility of Testing
to Specilications 447
Feasibility of Testing
to Code 448
Black-Box M odule lksting
Techniques 45 1
14.7.1 Equivalence Testing and
Boundary Value Analysis 45l
14.7.2 Functional Testing 452
Glass-Box M odule lksting
Techniques 454
14.8.1 Strucmral Testing: Statement,
Branch, and Path Coverage 454
14.8.2 Complexity M etrics 456
Code W alkthroughs and
lnspections 458
14.10 Com parison of
M odule lksting Techniques 458
14.1 l Cleanroom 459

14.12 Potential Problem s W hen
Testing Objects 460
14.13 M anagement Aspects of
M odule Testing 463
14.14 W hen to Rewrite Rather than
Debug a M odule 463
14.15 CASE Tools for the
lmplementation Phase 465
14.16 AP Gourmet Case Study:
Black-Box Test Cases 465
Challenges of the
lmplementation Phase 467
Chapter Review 467
For Further Reading 468
Problems 469
References 470
f h l p :e r 1S
Implemrntation and
Integratlon Phase 474
CONTENTS
Bottom-up lmplementation
and lntegration 477
Sandwich lmplementation
and lntegration 478
lmplementation and lntegration
of Object-oriented Products 480
M anagement lssues during the
lmplementation and
lntegration Phase 480
Testing during the lm plem entation

and lntegration Phase 48 l
lntegration Testing of Graphical
User lnterfaces 48 l
15.4 Product Testing 482
15.5 Acceptance Testing 483
15.6 CASE Tools for the lm plem entation
and lntegration Phase 484
CASE Tools for the Complete
Software Process 484
lntegrated Environm ents 485
Environm ents for
Business Applications 486
l5. 10 Public Tool lnfrastructures 487
l5. l l Potential Problems
with Environm ents 487
M etrics for the lm plem entation
and lntegration Phase 488
Air Gourmet Case St-udy: lm plementation
and lntegration Phase 488
Challenges of the lmplementation
and lntegration Phase 489
Chapter Review 489
For Further Reading 490
Problems 490
References 492
f h l p :e r 1*
M aintenance Phase 493
W hy M aintenance ls Necessary 493
W hat ls Required
of M aintenance Programmers 494

16.3 M aintenance Case Study 497
16.4 M anagement of M aintenance 498
16.4.1 Fault Reports 498
16.4.2 Authorizing Changes
to the Product 499
lntroduction to lm plem entation
and lntegration 474
15.1 .1 Top-down lmplementation
and lntegration 475
Please purchase Image To PDF Converter on to remove this message, thank you.
CONTENTS ;tIII
16.4.3 Ensuring M aintainability 500
16.4.4 Problem of Repeated
M aintenance 500
M aintenance of
Object-oriented Software 50 l
M aintenance Skills versus
Development Skills 504
l 6.7 Reverse Engineering 505
l 6.8 Testing during the
M aintenance Phase 506
CA SE Tools for the
M aintenance Phase 507
M etrics for the
M aintenance Phase 507
Air Gourm et Case Study:
M aintenance Phase 508
Challenges of the
M aintenance Phase
Chapter Review 509

For Further Reading 509
Problem s 5l0
References 51 l
A p p e n d lx A
Broadlands A rea Children's
H ospital 513
A p p e n d lx B
Softw are Engineering
Resources 518
A p p e n d lx f
Air Gqurmet Case Study:
C Rapld Prototype 520
A p p e n d lx p
Air Gourpet Case Study:
Java Rapld Prototype 521
A p p e n d lx E
A ir Gourm et Case Study:
Structured System s A nalysis 522
A p p e n d lx F
A ir Gourm et Case Study:
Software Project M anagement
Plan 529
A p p e n d lx *
A ir Gourm et Case Study:
Object-oriented Analysis 534
A p p e n d lx H
A ir Gourm et Case Study:
Designforc++ Im plem entation 535
A p p e n d lx I
A ir Gourm et Case Study:

Designforlavalmplem entation 560
A p p e n d lx J
A ir Gourm et Case Study:
Black-Box Test Cases 582
A p p e n d lx K
A ir Gourm et Case Study:
C++ Source C ode 588
A p p e n d lx k
A ir Gourm et Case Study:
Java Source Code 589
Bibliography 590
Author Index 617
Subjectlndex 623
Please purchase Image To PDF Converter on to remove this message, thank you.
P REFM :
The fourth edition of this book was published in two versions, one with code examples presented in C++
and the other in Java. H owever, software engineering essentially is language independent, and in any event,
there are relatively few code examples in this book. Accordingly, in this edition, l m ade every effort to :11100th
over language-dependent details and ensure that the code exam ples are equally clear to C++ and Java users.
For example, instead of using cout for C++ output and System.out.println for Java output, l utilized the
pseudocode instruction print. (The one exception is the new case st-udy, where complete implementation
details are given in 170th C++ and Java.) Therefore, the fifth edition can be considered a unihcation of the
two versions of the fourth edition.
Pedagogics is the theme of the fifth edition. All through this book, l added m aterial to highlight key
aspects of each chapter. For exam ple, there are How to Perform boxes that summarize important techniques
such as object-oriented analysis and object-oriented design. ln addition, new synopses and outlines assist 170th
the st-udent and the instructor. Also, to provide additional material on how to perform the various techniques
of software engineering, the case st-udy in this edition is presented in greater detail than in the fourth edition.
The fourth edition included a chapter entitled tt-l-eams and the Tools of Their Trade.'' As part of the stress
on pedagogics in this new edition, the m aterial has been updated and split into two, to focus m ore clearly on

each of the separate underlying topics. ln this edition, Chapter 4 is devoted to teams, whereas the tools used
by software engineers are described in Chapter 5.
As before, l include 170th classical and object-oriented material, notwithstanding the virt-ually unanimous
agreement that the object-oriented paradigm is superior to the classical (structured) paradigm. My decision
m ight surprise som e readers', surely an up-to-date software engineering textbook should describe only the
object-oriented paradigm and treat the classical paradigm, at best, as a historical footnote.
This is not the case. Despite the widespread enthusiasm for the object-oriented paradigm and the rapidly
accumulating evidence of its superiority over the classical paradigm, it nevertheless is essential to include
m aterial on the classical paradigm . There are three reasons for this. First, it is im possible to appreciate
why object-oriented technology is superior to classical technology without fully understanding the classical
approach and how it differs from the object-oriented approach.
The second reason why 170th the classical and object-oriented paradigms are included is that technology
transfer is a slow process. The vast majority of software organizations have not yet adopted the object-oriented
paradigm. lt therefore is likely that m any of the st-udents who use this book will be em ployed by organizations
that still use classical software engineering techniques. Furtherm ore, even if an organization is using the
object-oriented approach for developing new software, existing software still has to be maintained, and this
legacy software is not object oriented. Therefore, excluding classical material would not be fair to many of
the st-udents who use this text.
A third reason for including 170th paradigm s is that a student who is employed at an organization con-
sidering the transition to object-oriented technology will be able to advise that organization regarding 170th
the strengths and the weaknesses of the new paradigm . So, as in the previous edition, the classical and
object-oriented approaches are compared, contrasted, and analyzed.
The fourth edition was the first software engineering textbook to utilize the Unified M odeling Language
(UML), which was introduced shortly before that edition was published. ln the intervening three years, UML
has been formally standardized and becom e so widely used that any textbook that does not use UM L to
Please purchase Image To PDF Converter on to remove this message, thank you.
xvI PREFACE
describe object-oriented analysis and design immediately would be obsolete. There-
fore, l continue to use UML for object-oriented analysis and object-oriented design,
as well as wherever diagrams depict objects and their inten-elationships.

Another then-new topic introduced into the fourth edition was design patterns.
As with UM L, design patterns now are part of m ainstream software engineering. The
m aterial on design patterns therefore has been retained and strengthened.
A new topic in this edition is extreme programming (XP). XP still is controversial,
but l feel that st-udents need an overview of the topic so they can decide for them selves
whether XP is merely a fad or a genuine major breakthrough in software engineering.
ln the previous edition, l stressed the im portance of documentation, m aintenance,
reuse, portability, testing, and CASE tools. ln this edition, all these concepts are
stressed equally firm ly. lt is no use teaching students the latest techniques unless they
appreciate the im portance of the basics of software engineering.
As in the fourth edition, particular attention is paid to object-oriented life-cycle
models, object-oriented analysis, object-oriented design, management implications
of the object-oriented paradigm, and the testing and maintenance of object-oriented
software. Metrics forthe object-oriented paradigm also are included. ln addition, there
are many briefer references to objects, a paragraph or even only a sentence in length.
The reason is that the object-oriented paradigm is not just concerned with how the
various phases are performed but rather perm eates the w ay we think about software
engineering. Object technology pervades this book.
The softw are process still is the concept that underlies the book as a whole. To
control the process, we have to be able to measure what is happening to the project.
Accordingly, the em phasis on m etrics is retained. W ith regard to process improvement,
the material on the capability mat-urity model (CMM ) and ISO/IEC 15504 (SPICE)
has been updated, and material on ISO/IEC 12207 has been added.
As in the fourth edition, this book contains over 600 references. l selected current
research papers as well as classic articles and books whose message rem ains fresh
and relevant. There is no question that software engineering is a rapidly m oving field
and that st-udents therefore need to know the latest results and where in the literature
to find them . At the sam e time, today's cutting-edge research is based on yesterday's
truths, and l see no reason to exclude an older reference if its ideas are as applicable
today as they originally were.

W ith regard to prerequisites, it is assum ed that the reader is familiar with one
high-level programming language such as Pascal, C, C++, Ada, BASIC, COBOL,
FORTRAN, or Java. ln addition, the reader is expected to have taken a course in data
struct-ures.
How THz FIFTH EpITIoN Is @ ROANIIZP
Like the fourth edition of this book, the fifth edition is written for 170th the traditional
one-semester and the newer two-semester software engineering curriculum . ln the
traditional one-semester (or one-quarter) course, the instructor has to rush through
the theoretical m aterial to provide the students the knowledge and skills needed for
Please purchase Image To PDF Converter on to remove this message, thank you.
PREFACE xvll
the term project as soon as possible. The need for haste is so that the students can
commence the term project early enough to complete it by the end of the semester.
To cater to a one-semester, project-based software engineering course, Part 2 of this
book covers the life cycle, phase by phase, and Part l contains the theoretical m aterial
needed to understand Part 2. For exam ple, Part l introduces the reader to CASE,
metrics, and testing', each chapter of Part 2 contains a section on CASE tools for
that phase, a section on m etrics for that phase, and a section on testing during that
phase. Part l is kept short to enable the instructor to start Part 2 relatively early in
the semester. Furthermore, the last two chapters of Part l (Chapters 8 and 9) may be
postponed and taught in parallel w ith Part 2. The class then can begin developing the
term project as soon as possible.
W e t-urn now to the two-semester software engineering cuniculum. M ore and
m ore com puter science and com puter engineering departm ents are realizing that the
overwhelming preponderance of their graduates find em ployment as softw are en-
gineers. As a result, many colleges and universities introduced a two-semester (or
two-quarter) software engineering sequence. The first course is largely theoretical
(but almost always there is a small project of some sort). The second course consists
of a major team-based term project, usually a capstone project. W'hen the tenn project
is in the second course, there is no need for the instructor to rush to start Part 2.

Therefore, an instructor teaching a one-semester (or one-quarter) sequence using
the fifth edition covers most of Chapters l through 7, then starts Part 2 (Chapters 10
through 16). Chapters 8 and 9 can then be taught in parallel with Part 2 or at the end
of the course, while the st-udents are implementing the term project. W'hen teaching
the two-semester sequence, the chapters of the book are taught in order', the class now
is fully prepared for the team-based term project they will develop in the following
sem ester.
To ensure that the key software engineering techniques of Part 2 truly are un-
derstood, each is presented twice. First, whenever a technique is introduced, it is
illustrated by means of the elevator problem . The elevator problem is the correct size
for the reader to be able to see the technique applied to a complete problem, and it
has enough subtleties to highlight 170th the strengths and weaknesses of the technique
being taught. Then, the relevant portion of the new case study is presented toward the
end of each chapter. This detailed solution provides the second illustration of each
technique.
Tuz pRoekzM SzTs
As in the previous edition, there are four types of problem s. First, the end of each
chapter contains a number of exercises intended to highlight key points. These exer-
cises are self-contained', the technical inform ation for all the exercises can be found
in this book.
Second, there is a software term project. lt is designed to be solved by students
working in team s of three, the smallest number of team mem bers that cannot confer
over a standard telephone. The term project comprises l 6 separate components, each
Please purchase Image To PDF Converter on to remove this message, thank you.
;t5eIII PREFACE
tied to the relevant chapter. For exam ple, design is the topic of Chapter l 3, so in that
chapter the component of the term project is concerned with software design. By
breaking a large project into smaller, well-dehned pieces, the instructor can monitor
the progress of the class more closely. The structure of the term project is such that
an instructor may freely apply the l 6 components to any other project that he or she

chooses.
Because this book is written for use by graduate st-udents as w ell as upper-class
undergraduates, the third type of problem is based on research papers in the software
engineering literat-ure. ln each chapter, an im portant paper has been chosen', wherever
possible, a paper related to object-oriented software engineering has been selected.
The student is asked to read the paper and answer a question relating its contents.
Of cotlrse, the instructor is free to assign any other research paper', the For Further
Reading section at the end of each chapter includes a wide variety of relevant papers.
The fourth type of problem relates to the case study. This type of problem was first
introduced in the third edition in response to instructors who feel that their st-udents
learn more by m odifying an existing product than by developing a product from
scratch. M any senior softw are engineers in the industry agree with that viewpoint.
Accordingly, each chapter in which the case study is presented has at least three
problems that require the st-udent to modify the case st-udy in some way. For exam ple,
in one chapter the st-udent is asked to redesign the case st-udy using a different design
technique from the one used for the case study. ln another chapter, the st-udent is asked
what the effect would have been of performing the steps of the object-oriented analysis
in a different order. To make it easy to m odify the source code of the case study, it is
available on the World Wide Web at - .mhhe.com/engcs/compsci/schach. The
w eb site also has transparency m asters for all the figures in this book, as well as a
complete set of Powerpoint lecture notes.
The Instructor's Solution M anual contains detailed solutions to all the exercises,
as well as to the term project. The Instructor's Solution Manual is available from
M cGraw-l-lill.
A txxow kzpoMzxTs
l am indebted to those w ho review ed this edition, including'.
An'in Agah (University of Kansas)
Thaddeus R. Crews, Jr. (Western Kentucky University)
Eduardo B. Fernandez (Florida Atlantic University)
Michael Godfrey (Cornell University)

Scott Hawker (University of Alabama)
Thomas B. Horton (Florida Atlantic University)
Gail Kaiser (Columbia University)
Laxmikant V. Kale (University of lllinois)
Helene Kershner (University of Buffalo)
Chung Lee (California State Polytechnic University at Pomona)
Please purchase Image To PDF Converter on to remove this message, thank you.
PREFACE xIx
Richard A. Lejk (University of North Carolina, Charlotte)
Susan A. Mengel (Texas Technological University)
David S. Rosenblum (University of California at lrvine)
Shmuel Rotenstreich (George Washington University)
Wendel Scarbrough (Azusa Pacific University)
Gerald B. Sheble (lowa State)
Jie We (City University of New York)
David Workman (University of Central Florida)
l thank two individuals who m ade contributions to earlier books. First, Jeff Gray
once again made num erous insightful suggestions. ln particular, l am grateful for his
many ideas regarding Chapter 8. Also, he once again is a coauthor of the Instructor's
Solution M anual. Second, my son David has m ade a num ber of helpful contributions
to the book and again is a coauthor of the Instructor's Solution M anual.
Since l 999, l have been involved in joint research with Dr. Amir Tomer of
RAFAEL and the Technion, lsrael lnstitute of Technology. The papers we wrote
together are nominally on m aintenance. However, the issue underlying our research
is the nature of software engineering. A direct consequence of working with Amir
is that l gained new insight into software engineering. l have incorporated m any of
these ideas into this edition.
Turning now to my publisher, M cGraw-l-lill, l am truly grateful to executive
editor Betsy Jones and developmental editor Emily Gray for their assistance from
start to finish. l particularly appreciate their suggestions regarding giving equal stress

to 170th C++ and Java in an integrated volume. Rick Hecker was the ideal project
manager in every way. l was most fortunate to have Gnomi Schrift Gouldin as the
copy editor for this book. She greatly improved the readability of my manuscript, and
l am grateful for her m any suggestions.
l would like to thank the m any instructors from all over the world who sent m e
e-m ail concerning the fourth edition. l am exceedingly appreciative of their sugges-
tions, comm ents, and criticism s. l look forward with anticipation to receiving instruc-
tors' feedback on this edition also. My e-mail address is
Students, too, have been most helpful. First, l thank my students at Vanderbilt
for their many questions and com m ents, 170th inside and outside the classroom . l also
an m ost grateful for the provocative questions and constructive suggestions e-m ailed
m e by st-udents from all over the world. l look forward keenly to st-udent feedback on
this edition, too.
Finally, as alw ays, l thank m y family for their continual support. W hen l started
writing books, my limited free tim e had to be shared between m y young children and
my current book project. Now that my children are adults and work with me on my
books, writing has becom e a fam ily activity. For the tenth tim e, it is m y privilege to
dedicate this book to my wife, Sharon, and my children, David and Lauren, with love.
Stephen R . Schach
Please purchase Image To PDF Converter on to remove this message, thank you.
R A R +
I T TI T F :
I EE I
Yhe first nine chapters of this book play a dual role. They introduce the reader to the software process, and
they also provide an overview of the book. The software process is the way we produce software. lt starts with
concept exploration and ends when the product is finally decommissioned. During this period, the product
goes through a series of phases such as requirements, specification, design, implementation, integration,
maintenance, and ultimately, retirement. The software process also includes the tools and techniques we use
to develop and m aintain software as well as the software professionals involved.
ln Chapter 1. Tçrlnhe Scope of Software Engineering,'' it is pointed out that techniques for software pro-

duction must be cost effective and promote constructive interaction between the members of the softw are
production team. The importance of objects is stressed throughout the book, starting with this chapter.
çt-f'he Software Process'' is the title of Chapter 2. Each phase of the process is discussed in detail. M any
problem s of software engineering are described, but no solutions are put forward in this chapter. Instead, the
reader is informed where in the book each problem is tackled. ln this way, the chapter serves as a guide to the
rest of the book. The chapter concludes with material on software process improvement.
A variety of different software life-cycle m odels are discussed in detail in Chapter 3, ':software Life-cycle
M odels.'' These include t
c
h.t Fat-erfalt-model. th id rotot ing mod l t e ' remental model, ey
-tr q.!p
s
Izr-tylaurp-n-uing, the synchronize-and-stabilize model. and the spiral model. To enable the reader to decide on an
appropriate life-cycle model for a specihc project, the various life-cycle models are compared and contrasted.
Chapter 4 is entitled çTeams.'' Today's projects are too large to be completed by a single individual within
the given time constraints. Instead, a team of software professionals collaborate on the project. The major
topic of this chapter is how teams should be organized so that team members work togethcr productively.
Various different ways of organizing team s are discussed, including democratic teams, chief programmer
teams, synchronize-and-stabilize team s, and extrem e program ming teams.
Chapter 5 discusses ''The Tools of the Trade.'' A software engineer needs to be able to use a number of
different tools, both theoretical and practical. In this chapter, the reader is introduced to a variety of software
engineering tools. One such tool is stepwise refinement. a technique for decom posing a large problem
into smaller, more tractable problems. Another tool is cost-benetit analysis, a technique for determining
whethera softwareproject is fnancially feasible. Then, computer-aided software engineering (CASE) tools are
1
Please purchase Image To PDF Converter on to remove this message, thank you.
x p A * T , . Infrodutgion 'o soe are Engineering
r
is a software product that assists software engineers to de- ldescribed. A CASE tool
lvelop and maintain software

.
Finally, to manage the software process. it is necessary t
to measure valious quantities to determine whether the project is on track. These t
measures (metrics) are critical to the success of a project. tt
The last two topics of Chapter 5, CASE tools and metrics, are treated in detail b
in Chapters 10 through 16, which describe the specific phases of the software life j
cycle. There is a discussion of the CASE tools that support each phase, as well as a '
description of the metrics needed to manage that phase adequately. @
An important theme of this book is that testing is not a separate phase to be carried
out just before delivering the product to the client or even at the end of each phase
of the software life cycle. Instead, testing is performed in parallel with all software
production activities. ln Chapter 6, ç4rlksting,'' the concepts underlying testing are
discussed. The consideration of testing techniques specihc to individual phases of the
software life cycle is defen'ed until Chapters 10 through 1 6.
Chapter 7 is entitled çtFrom Modules to Objects.'' A detailed explanation is given
of classes and objects, and why the object-oriented paradigm is proving to be more
successful than the structured paradigm. The concepts of this chapter then are utilized
in the rest of the book, particularly Chapter l2, 'çobject-oriented Analysis Phase,''
and in Chapter 13, ''Design Phase,'' in which object-oriented design is presented.
The ideas of Chapter 7 are extended in Chapter 8, t'Reusability, Portability, and
lnteroperability.'' It is important to be able to write reusa'ble software that can be
ported to a variety of different hardware and run on distributed architectures such
as client-server.The lirst part of the chapter is devoted to reuse', the topics include
a variety of reuse case studies as well as reuse strategies such as object-oriented
patterns and frameworks. Portability is the second major topic; portability strategies
are presented in some depth. The chapter concludes with interoperability topics such
as CORBA and COM. A recuning theme of this chapter is the role of objects in
achieving reusability, portability, and interoperability.
The last chapter in PM 1 is Chapter 9, 4iplanning and Estim ating.'' Before starting
a software project, it is essential to plan the entire operation in detail. Once the

project begins, management must closely monitor progress. noting deviations from
the plan and taking corrective action where necessary. Also, it is vital that the client
be provided accurate estimates of how long the project will take and how much it will
cost. Different estimation techniques are presented, including function points and
COCOMO II. A detailed description of a software project management plan is given.
The material of this chapter is utilized in Chapters 1 1 and 12. W hen the classical
paradigm is used, major planning and estimating activities take place at the end of the
specification phase, as explained in Chapter 1 l . W hen software is developed using the
object-oriented paradigm, this planning takes place at the end of the object-oriented
analysis phase (Chapter 12).
Please purchase Image To PDF Converter on to remove this message, thank you.
e n - > * - <
E t E F F E I EE I
A well-known story tells of an executive who received a computer-generated bill for $0.00. After having a
good laugh with friends about 'Eidiot computerss'' the executive tossed the bill away. A month later a similar bill
anived, this tim e marked 30 days. Then came the third bill. The foul'th bill arrived a month later, accompanied
by a message hinting at p
.
pljible
-
le
-
gal action if the bill for $0.00 was not paid at once.
The fifth bill, marked 120 days, did not hint at anything- the message was rude and forthright, threatening
all m anner of legal actions if the bill was not imm ediately paid. Fearful of his organization's credit rating in
the hands of this mania
-
ca
-
l machine, the executive called an acquaintance who was a software engineer and

related the w hole son'y story. Trying not to laugh, the software engineer told the executive to mail a check
for $0.00. This had the desired effect, and a receipt for $0.00 was received a few days later. The executive
carefully hled it away in case at some future date the eomputer might allege that $0.00 was still owing.
This well-known story has a less well-known sequel. A few days later the executive was summoned by
his bank manager. The banker held up a check and asked, ''ls this your check?''
The executive agreed that it was.
ç'Would you mind telling me why you wrote a check for $0.00?5' asked the banker.
So the whole story was retold. W hen the executive had finished, the banker turned to him and she quietly
asked, E<l-lave you any idea what your check for $0.00 did to our computer system?''
A computer professional can laugh at this story, albe-tt somewhat nervously. After all, every one of us has
designed or implemented a product that, in its original form, would have resulted in the equivalent of sending
dunning letters for $0.00. Up to now, we have always caught this sort of fault duling testing. But our laughter
has a hollow ring to it, because at the back of our m inds is the fear that someday w e will not detect the fault
before the product is delivered to the customer.
A decidedly less hum orous softw are fa was detected on Novem berg. 1979. The Strategic Aircommand
had an alel't scramble when the worldwide military command and control system (W W MCCS) computer
network reported that the Soviet Union had launched missiles aimed toward the United States LNeumann,
19801. What actually happened was that a simulated attack was interpreted as the real thing, just as in the
movie WarGames some 5 years later. Although the U.S. Department of Defense understandably has not given
details about the precise mechanism by w hich test data were taken for actual data, it seems reasonable to
ascribe the problem to a software fault. Either the system as a whole was not designed to differentiate between
simulations and reality, or the user interface did not include the necessary checks for ensuring that end users
3
Please purchase Image To PDF Converter on to remove this message, thank you.
l
* t u A p : : R 1 * The stope of so6wore Engineering k
!
k
'
i

W ANTEP To KNow 'JusT IN ZAS: You
In the case of the W W MCCS network, disaster was a time, after which the clock was reset. As a result, the ;
averted at the last minute. However, the consequences fault never had a significant effect and therefore was t
riot mis- lof other software faults sometimes have been tragic
. For not detected. In the Gulf W ar, however. the Pat )
example, between 1 985 and 1 987, at least two patients sile battery at Dhahran ran continuously for over l 00 l
died as a consequence of severe overdoses of radiation hours. This caused the accumulated time discrepancy to y
delivered by the Therac-25 medical linear accelerator become large enough to render the system inaccurate. (
(Leveson and Turner, 1 9931. The cause was a fault in During the Gulf War, the United States shipped Pa- 7
the control software. triot missiles to lsrael for protection against the Scuds.
During the 1 99 1 Gulf W ar, a Scud missile pen- lsraeli forces detected the timing problem after only 8
etrated the Patriot antimissl e shield and struck a hours and immediately reported it to the manufpcturer
barracks near Dhahran, Saudi Arabia. In all, 28 Ameri- in the United States. The manufacturer corrected the
cans were killed and 98 wounded. The software for the fault as quickly as it could but, tragically, the new soft-
Patriot missile contained a cumulative timing fault. The ware arrived the day after the direct hit by the Scud
Patriot was designed to operate for only a few hours at lMellor, 19941.
of the system would be able to distinguish fact from fiction. ln other words, a software
fault, if indeed the problem was caused by software, could have brought civilization
as we know it to an unpleasant and abrupt end. (See the Just in Case You Wanted to
Know box above for information on disasters caused by other software faults.)
W hether we are dealing with billing or air defense, m uch of our software is
delivered late, overbudget, and with residual faults. Software engineering is an attempt
to solve these problem s. In other words, software engineering is a discipline whose
aim is the production of fault-free software, delivered on time and within budget, that
satishes the user's needs. Furthermore, the software must be easy to m odify when
the user's needs change. To achieve these goals, a software engineer has to acquire a
broad range of skills, both technical and managerial. These skills have to be applied
notjust to programming but to every phase of software production, from requirements
to maintenance.
The scope of software engineering is extrem ely broad. Som e aspects of software

engineering can be categorized as mathematics or computer science', other aspects
fall into the areas of economics, management, or psychology. To display the wide-
reaching realm of software engineering, five different as ects now will be examined.
la H ISTORItA: A spEtTs
It is a fact that electric power generators fail, but far less frequently than payroll
products. Bridges sometimes collapse, but considerably less often than operating
system s. In the beliefthat software design, im plementation, and maintenance could be
j
Please purchase Image To PDF Converter on to remove this message, thank you.
Aa HISTORICAL A SPKTS 5
put on the same footing as traditional engineering disciplines, a NATO study group in
1967 coined the term software engineering. The claim that buildlng software is similar
to other engineering tasks was endorsed by the l 968 NATO Software Engineering
Conference held in Garmisch, Germany (Naur. Randell, and Buxton, 19761. This
endorsement is not too surprising', the very name of the conference reflected the belief
that software production should be an engineeringlike activity. A conclusion of the
conferees was that software engineering should use the philosophies and paradigms
of established engineering disciplines to solve what they termed the software crisis;
namely, that the quality of software generally was unacceptably low and that deadlines
and cost limits were not being met.
Despite many software success stories, a considerable am ount of software still
is being delivered late, over budget, and with residual faults. That the software crisis
still is with us, over 30 years later, tells us two things. First, the software production
process, while resembling traditional engineering in many respects, has its own unique
properties and problem s. Second, the software crisis perhaps should be renamed the
sof-are depression, in view of its long duration and poor prognos-is.
Certainly, bridges collapse less frequently than operating systems. W hy then
cannot bridge-building techniques be used to build operating system s? W hat the
NATO conferees overlooked is that bridges are as different from operating systems
as chalk is from cheese.

A major difference between bridges and operating systems lies in the attitudes of
the civil engineering comm unity and the software engineering comm unity to the act
of collapsing. W hen a bridge collapses. as the Tacom a Narrows bridge did in 1940,
the bridge almost always has to be redesigned and rebuilt from scratch. The original
design was faulty and posed a threat to hum an safety', certainly, the design requires
drastic changes. ln addition, the effects of the collapse in almost every instance will
have caused so much dam age to the bridge fabric that the only reasonable thing is
to demolish what is left of the faulty bridge, then com pletely redesign and rebuild
it. Furtherm ore, other bridges built to the same design have to be carefully inspected
and. in the worst case, redesigned and rebuilt.
ln contrast, an operating system crash is notconsidered unusual and rarely triggers
an immediate investigation into its design. W hen a cN sh occurs, it may be possible
èW h t caused thesimply to reboot the system in the hope that the set of cumstances t a
crash will not recur. This may be the only remedy if, as often is the case, there is no
evidence as to the cause of the crash. The damage caused by the crash usually will
be minor: a database partially corrupted, a few files lost. Even when dam age to the
file system is considerable, backup data often can restore the tile system to a state not
too far removed from its precrash condition. Perhaps, if software engineers treated
an operating system crash as seriously as civil engineers treat a bridge collapse, the
overall level of professionalism within software engineering would rise.
Now consider a real-time system , that is, a system able to respond to inputs from
the real world as fast as they occur. An example is a computer-controlled intensive care
unit. Irrespective of how m any medical emergencies occur virtually simultaneously,
the system m ust continue to alert the medical staff to every new em ergency without
ceasing to monitor those patients whose condition is critical but stable. In general,
the failure of a real-time system, whether it controls an intensive care unit, a nuclear
Please purchase Image To PDF Converter on to remove this message, thank you.
l t u A p T : R l * The stope ol soe ox Engineering
I
)

reactor, or the climatic conditions aboard a space station, has significant effects. Most l
1.
real-time system s, therefore, include some elem ent of fault tolerance to minim ize the l
l
effects of a failure. That is, the system is designed to attempt an automatic recovery à
from any failure. j
The very concept of fault tolerance highlights a major difference between bridges
and operating system s. Bridges are engineered to withstand every reasonably antici-
pated condition: high winds, flash ioods, and so on. An implicit assumption of all too
many software builders is that we cannot hope to anticipate al1 possible conditions
that the software must withstand, so we must design our software to try to mini- jmize the damage that an unanticipated condition might cause
. In other words, bridges !
are assumed to be perfectly engineered. ln contrast, most operating systems are as- I
sumed to be imperfectly engineered; many are designed in such a way that rebooting i
is a simple operation that the user may perform whenever needed. This difference !
is a fundamental reason why so much software today cannot be considered to be )
engineered. r
lt might be suggested that this difference is only tempormy After all, we have 1lb
een building bridges for thousands of years, and we therefore have considerable
iexperience and expertise in the types of conditions a bridge must withstand
. W e have .
ly 50 years of experience with operating systems. Surely with more experience, ion
the argument goes. we will understand operating system s as well as we understand ?
bridges and so eventually will be able to construct operating systems that will not fail. i
The flaw in this argum ent is that hardware, and hence the associated operating I
is growing in complexity faster than we can master it. ln the 1960s, we isystem
, j
had multiprogramming operating systems', in the l970s, we had to deal with virtual 1i
memory', and now, we are attempting to come to terms with multiprocessor and !
distributed (network) operating systems. Until we can handle the complexity caused ' '

by the interconnections of the various components of a software product such as an :
.
operating system , we cannot hope to understand it fully) and if we do not understand
it, we cannot hope to engineer it. (
Part of the reason for the complexity of software is that, as it executes, software j7
oes through discrete states. Changing even one bit causes the software to change jg
state. The total number of such states can be vast, and many of them have not been ô
considered by the development team . If the software enters such an unanticipated It
he result often is software failure. ln contrast, bridges are continuous (ana- jState, t
log) systems. They are described using continuous mathematics, essentially calculus.
However, discrete system s such as operating systems have to be described using dis-
l
crete mathematics gparnas, 19901. Software engineers therefore have to be skilled in I
ldiscrete m athem atics
,
a prim ary tool in trying to cope with this complexity. l
A second major difference between bridges and operating systems is mainte- l
nance. M aintaining a bridge generally is restricted to painting it, repailing minor
cracks, resurfacing the road, and so on. A civil engineer, if asked to rotate a bridge
through 90O or to move it hundreds of miles, would consider the request outrageous.
However, we think nothing of asking a software engineer to convert l
-h.ttyh operatin
system into a tim e-sharin one or to port it from one machine to another with totally
different architectural characteristics. It is not unusual for 50 percent of the source
Please purchase Image To PDF Converter on to remove this message, thank you.
4.2 EcoNoMIC A:PK TS y
code of an operating system to be rewritten over a s-year period, especially if it is
ported to new hardware. But no engineer would consent to replacing half a bridge',
safety requirements would dictate that a new bridge be built. The area of maintenance,
therefore, is a second fundam ental aspect in w hich software engineering differs from

traditional engineering. Further maintenance aspects of software engineering are de-
scribed in Section l .3. But first, economic-oriented aspects are presented.
1.Q KtoNoM lt A spetTs
An insight into the relationship between software engineering and computer science
can be obtained by comparing and contrasting the relationship between chemical
engineering and chemistry. After all, eomputer science and chemistry are both sci-
ences, and both have a theoretical component and a practical com ponent. In the case
of chemistry, the practical component is laboratory work; in the case of computer
science, the practical component is programming.
Consider the process of extracting gasoline from coal. During W orld W ar lI, the
Germ ans used this process to m ake fuel for their war machine because they largely
were cut off from oil supplies. W hile the antiapartheid oil embargo was in effect, the
governm ent of the Republic of South Africa poured billions of dollars into SASOL
(an Afrikaans acronym standing for t'South African coal into oi1''). About half of
South Africa's liquid fuel needs were m et in this way.
From the viewpoint of a chemist, there are many possible ways to convert coal
into gasoline and all are equally important. After all, no one chemical reaction is m ore
important than any other. But from the chem ical engineer's viewpoint, at any one time
there is exactly one important mechanism for synthesizing gasoline from coal- the
reaction that is economically the most attractive. In other words, the chem ical engineer
evaluates a1l possible reactions, then rejects all but that one reaction for which the
cost per liter is the lowest.
A similar relationship holds between computer science and software engineering.
The computer scientist investigates a variety of ways to produce software, som e good
and some bad. But the software engineer is interested in only those techniques that
make sound economic sense.
For instance, a software organization currently using coding technique C'L ld
discovers that new coding technique, C'L ew, would result in code being produced in
only nine-tenths of the time needed by C'rold and, hence, at nine-tenths of the cost.
Common sense seems to dictate that C'Lew is the appropriate technique to use. In fact,

although common sense certainly dictates that the faster technique is the technique
of choice, the economics of software engineering may imply the opposite.
One reason is the cost of introducing new technology into an organization. The
fact that coding is 10 percent faster when technique C'Lew is used may be less im-
portant than the costs incurred in introducing C'Lew into the organization. It may be
necessary to complete two or three projects before recouping the cost of training.
Please purchase Image To PDF Converter on to remove this message, thank you.
a t u A p T : R 4 . The stope of soe are Engineering
Also, while attending courses on C'Lew, software personnel are unable to do produc-
tive work. Even when they return, a steep learning curve may be involved', it may take
months of practice with C'L ew before software professionals become as proficient
with C'Lew as they currently are with C'Lld. Therefore, initial projects using C'Lew
may take far longer to complete than if the organization had continued to use C'Lld.
All these costs need to be taken into account when deciding whether to change to
C'Lew.
A second reason why the economics of softw are engineering may dictate that
C'rou be retained is the maintenance consequence. Coding technique C'L ew indeed
may be 10 percent faster than C'L ld. and the resulting code may be of comparable
quality from the viewpoint of satisfying the client's current needs. But the use of
technique C'Lew may result in code that is difficult to maintain, making the cost of
C'Lew higher over the life of the product. Of course, if the software developer is
not responsible for any maintenance, then, from the viewpoint of just that developer,
C'Lew is a most attractive proposition. After all, use of C'Lew would cost 10 percent
less. The client should insist that technique Crrold be used and pay the higher initial
costs with the expectation that the total lifetime cost of the software will be lower.
Unfortunately, often the sole aim of both the client and the software provider is
to produce code as quickly as possible. The long-term effects of using a particular
technique generally are ignored in the interests of short-term gain. Applying economic
principles to software engineering requires the client to choose techniques that reduce
long-term costs.

W e now consider the importance of maintenance.
l.a M AINTENANtE A spetTs
The series of steps that software undergoes, from concept exploration through final ;
irement, is termed its Iqfe cycle. During this time, the product goes through a lret I
series of phases: requirements, specilication. design, implementation, integration, I
maintenance, and retirement. Life-cycle models are discussed in greater detail in
Chapter 3', the topic is introduced at this point so that the concept of maintenance can
be dehned.
Until the end of the 1970s, most organizations were producing software using
as their life-cycle model what now is termed the waterfall model. There are many
variations of this model, butby and large, the product goes through seven broad phases.
These phases probably do not correspond exactly to the phases of any one particular
organization, but they are sufhciently close to most practices for the purposes of
this book. Similarly, the precise name of each phase varies from organization to
organization. The nam es used here for the various phases have been chosen to be as
general as possible in the hope that the reader will feel comfortable with them. For
easy reference, the phases are summarized in Figure 1 . 1, which also indicates the
chapters in this book in which they are presented.
Please purchase Image To PDF Converter on to remove this message, thank you.
1.a MAINTENANCE ASPECTS @
1 . Requiremenfs phase (Chapter 1 0)
2. Specification (analysis) phase (Chapters 1 1 cnd 1 2)
3. Design phase (Chapter 1 3)
:. lmplementatîon phase (Chcpers 1 zt and 1 5)
5. Integration phase (Chapter 1 5)
6. Maintencnce phase (Chapter 18)
7. zetirement
Flgure Aa The phases of the sohware Iife cycle and
the chapters in this book in which they are presented.
1. Requirem ents phase. The concept is explored and refined, and the client's re-

quirements are elicited.
2. Spec/cation (analysis) phase. The client's requirements are analyzed and pre-
sented in the form of the specncation document, ''what the product is supposed
to do.'' This phase sometimes is called the analysis phase. At the end of this
phase, a plan is drawn up, the software project managementplan, describing the
proposed software development in full detail.
3. Designphase. The specihcations undergo two consecutive design processes. First
comes architectural design, in which the product as a whole is broken down into
components, called modules. Then, each module is designed; this process is
termed detailed design. The two resulting design documents describe E%how the
roduct does it.''P
4. lmplementation phase. The various components are coded and tested.
5. Integration phase. The eom ponents of the product are com bined and tested as
a whole. W hen the developers are satisfied that the product functions correctly,
it is tested by the client (acceptance testing). This phase ends when the product
is accepted by the client and installed on the client's computer. (W e will see in
Chapter l 5 that the integration phase should be performed in parallel with the
implementation phase.)
6. Maintenance phase. The product is used to perform the tasks for which it was de-
veloped. During this time, it is m aintained. M aintenance includes all changes to
the product once the client has agreed that it satishes the specihcation document
(but see the Just in Case You Wanted to Know box on page 10). Maintenance
includes corrective maintenance (or software repair), which consists of the re-
moval of residual faults while leaving the specifications unchanged, as well as
enhancement (or software update), which consists of changes to the specihca-
tions and the implementation of those changes. There are, in turn, two types of
enhancement. The first is perfective maintenance, changes that the client thinks
will improve the effectiveness of the product, such as additional functionality or
decreased response time. The second is adaptive m aintenance, changes m ade in
response to changes in the environment in which the product operates, such as

Please purchase Image To PDF Converter on to remove this message, thank you.
1* t H A p ' : k l * The scope of Soe ore Engineering
new governm ent regulations. Studies have indicated that, on average, m aintain-
ers spend approximately 17.5 percent of their tim e on corrective maintenance,
60.5 percent on perfective maintenance, and 18 percent on adaptive maintenanee
kLientz, Swanson, and Tompkins, 19781.
7. Retirement. The product is removed from service. This occurs when the function-
ality provided by the product no longer is of any use to the client organization.
JusT IN tAsz You W ANTEP To Kxow
In the l970s, software production was viewed as con- changes to the specitications necessitate corresponding
sisting of two distinctactivities performed sequentially: changes to those portions of the design already com-
development followed by maintenance. Starting from pleted. Only when these changes have been made can
scratch, the software product was developed then in- development proceed. ln other words, developers have
stalled on the client's computer. Any change to the soft- to pedbrm t'maintenance'' long before the product is
ware after installation, whether to tix a residual fault or installed.
extend the functionality, constituted classical mainte- A second problem with the classical development-
nance (IEEE 6 l0. l2, 19901. Hence. the way that soft- then-maintenance model arose as a result of the way
ware was developed classically can be described as the in which we now construct software. ln classical soft-
development-then-maintenance model. ware engineering, a characteristic of development was
This is a temporal definition; that is, an activity is that the development team built the target product from
classified as development or maintenance depending scratch. In contrast, as a consequence of the high costof
on when it is performed. Suppose that a fault in the software production today, developers try to reuse parts
software is detected and eorrected a day after the soft- of existing software wherever possible in the software
ware has been installed. This clearly constitutes mainte- to be constructed (reuse is discussed in detail in Chap-
nance. But if the identical fault is detected and corrected ter 8). Therefore, the development-then-maintenance
the day before the software is installed, in terms of the model is inappropriate whenever there is reuse.
classical definition, this constitutes development. A more realistic way of Iooking at maintenance is ë
is unrealistic to view maintenance as the process that occurs when $There are two reasons why this model
l
today. First, nowadays it is certainly not unusual for ç'software undergoes modifications to code and associ-

construction of a product to take a year or more. ated documentation due to a problem or the need for
During this time, the client's requirements may well improvement or adaptation'' (ISO/IEC l 2207, 1995J. j
change. For example, the client might insist that the By this definition, maintenance occurs whenever a fault j
product now be implemented on a faster micropro- is fixed or the requirements change, irrespective of 1'
cessor that has become available. Alternatively, the whether this takes place before or after installation of ')
client organization may have expanded into Canada the product. '
while development was under ways and the product However, until such time as the majority of soft-
now has to be modihed so it also can handle sales in ware engineers realize that the development-then- .
.
Canada. To see how this sort of change in requirements maintenance model is outdated, there is little point in )
affects the software life cycle, suppose that the client's trying to change the tlsage of the word maintenance. l
irements change while the design is being devel- ln this book, I accordingly still refer to maintenance as lrequ
(oped
. The software engineering team has to suspend the activity carried out after development is complete
development and modify the speciûcation document to and the product installed. Nevertheless, I hope that the q
rellect the changed requirements. Furthermore, it then true nature of maintenance soon will be more widely ,
may be necessary to modify the design as well, if the recognized.
2
)
Please purchase Image To PDF Converter on to remove this message, thank you.
1.a M AINTENANCE A5PKT5 11
Returning to the topic of maintenance, it som etimes is said that only bad software
products undergo m aintenance. ln fact, the opposite is true', bad products are thrown
away, whereas good products are repaired and enhanced, for 10, 15, or even 20 years.
Furtherm ore, a software product is a model of the real world, and the real world is
pepetually changing. As a consequence, software has to be maintained constantly
for it to remain an accuratc reflection of the real world.
For instance, if the sales tax rate changes from 6 percent to 7 percent, almost
every software produet that deals with buying or selling has to be ehanged. Suppose
the product contains the C+ + statement

consi floot saleslbx = 8.0,'
or the equivalent Java statement
publit siciit finol floci saleslbx = (floo') 8.0,.
declaring that salesTax is a floating-point constant initialized to the value 8.0. ln this
case, maintenanee is relatively simple. W ith the aid of a text editor the value 6.0 is
replaced by Z.O and the code is recompiled and relinked. However, if instead of using
the name salesTox, the actual value 8.0 has been used in the product wherever the
value of the sales tax is invoked, then sueh a product will be extremely diflicult to
maintain. For example, there may be occurrences of the value 6.0 in the source code
that should be changed to Z.O but are overlooked or instances of 6.O that do not refer
to sales tax but incorrectly are changed to Z.O. Finding these faults almost always is
difhcult and time consuming. ln fact, with some software, it might be less expensive
in the long run to throw away the product and recode it rather than try to determine
which of the many constants need to be changed and how to make the modihcations.
The real-time real world also is constantly changing. The missiles with which ajet
tighter is armed may be replaced by a new model, requiring a change to the weapons
control component of the associated avionics system. A six-cylinder engine is to be
offered as an option in a popular four-cylinder automobile', this implies changing the
on-board computer that controls the fuel injection system, timing. and so on.
Healthy organizations change; only dying organizations are static. This means
that maintenance in the form of enhancement is a positive part of an organization's
activities, rellecting that the organization is on the move.
But just how much time is devoted to maintenance? rfhe pie chart in Figure
1 .2 was obtained by averaging data from various sources, including gElshoff, 1976,.
Daly, 1977*, Zelkowitz. Shaw, and Gannon, 1979., and Boehm. 19811. Figure 1.2
shows the approximate percentage of time (= money) spent on each phase of the
software life cycle. About l 5 years later, the proportion of time spent on the various
developm ent phases had hardly changed. This is shown in Figure 1 .3, which compares
the data in Figure l .2 with more recent data on l 32 Hewlett-packard projects kGrady,
19941. The data from Figure l .2 have been grouped to make them comparable to the

lnewer data
.
1 Figure 1
.
3 reilects only the development phases. The proportion of developmenf time devoted to the require-1 ments and specificotion phases in Figure 1
.
2 is (2 + 53/33, or 2 1 %, as shown in Figure 1 .3.
Please purchase Image To PDF Converter on to remove this message, thank you.
.2 e u A p T : w 4 . The stope of so&wore Engineering
Module Integration
N testing aos
Modully yv
o
codingxN
5% NDesign
h
o N6 /0 N
Specification h
h(analvsis) <
J ' N5 4
N
Requirements
2%
Maintenance
67%
Fl@ue. 1.2 Approximate relctive costs of the phases of the
sohware Iife cycle.
Vorious Proiet's 13Q More Retenl
be- een 197* and Hewle/-potkard
1981 Proiees

Requirements ond specification
(analysis) phases 2 1 % 1 8%
Design phase 1 8 1 9
Implementction phase 36 34
Intesration phuse 2:. 29
Flgure 1.a Comparison of approximate average percentases of time spenf
on the development phcses for various proiects befween 1 976 and 1 98 1 cnd for
1 32 more recenf Hewlett-Fackard proiects.
As can be seen in Figure l .2, about two-thirds of total software costs were devoted
to m aintenance. Newer data conhrm the continuing emphasis on maintenance. For
example, in 1992 between 60 and 80 percent of research and development personnel at
Hewlett-packard were involved in maintenance, and maintenance constituted betw een
40 and 60 percent of the total cost of software (Coleman, Ash, Lowther. and Oman,
19941. However, many organizations devote as much as 80 percent of their time and
effort to maintenance (Yourdon. 19961. Therefore, maintenance is an extremely time
consuming, expensive phase of the software life cycle.
Consider again the software organization currently using coding technique Crfold
that learns that C'Lew will reduce coding time by 10 percent. Even if C'Lew has no
Please purchase Image To PDF Converter on to remove this message, thank you.
1.* SPK IFICATION AND DESIGN ASPKIS la
adverse effect on maintenance, an astute software manager will think twice before
changing coding practices. The entire staff will have to be retrained, new software
development tools purchased, and perhaps additional staff members hired who are
experienced in the new technique. All this expense and disruption has to be endured
for a possible 0.5 percent decrease in software costs because, as shown in Figure 1 .2,
module coding constitutes on average only 5 percent of total software costs.
Now suppose a new technique that reduces maintenance by 10 percent is devel-
oped. This probably should be introduced at once because, on average, it will reduce
overall costs by 6.7 percent. The overhead involved in changing to this technique is
a small price to pay for such large overall savings.

Because maintenance is so important, a major aspect of software engineering
consists of those techniques, tools, and practices that lead to a reduction in m ainte-
nance costs.
l.* SPKtIFIIATI/N ANp IE:IGN A SPEW :
Software professionals are human and therefore sometimes make errors while devel-
oping a product. As a result, there w ill be a fault in the software. If the error is made
during the requirements phase, then the resulting fault probably also will appear in the
specifications, the design, and the code. Clearly, the earlierwe correct a fault, the better.
The relative eosts of hxing a fault at various phases in the software life cycle are
shown in Figure l .4 gBoehm, 198 l 1. The figure reoects data from IBM gFagan. 19741,
GTE kDaly, 19771, the Safeguard project îstephenson, 19761, and some smaller TRW
projects (Boehm, 19801. The solid line in Figure l .4 is the best lit for the data relating
to the larger projects, and the dashed line is the best tit for the smaller projects. For
each of the phases of the software life cycle, the corresponding relative cost to detect
and correct a fault is depicted in Figure 1 .5. Each step on the solid line in Figure 1 .5
is constructed by taking the corresponding point on the solid straight line of Figure
1.4 and plotting the data on a linear scale.
Suppose it costs $40 to detect and correct a specific fault during the design
phase. From the solid line in Figure 1 .5 (projects between l 974 and 1980), that same
fault would cost only about $30 to lix during the specification phase. But, during the
maintenance phase, that fault would cost around $2000 to detect and correct. Newer
data show that now it is even m ore important to detect faults early. The dashed line in
Figure 1.5 shows the cost of detecting and correcting a fault during the development
of system software for the IBM AS/400 glkan et al 19941. On average, the same fault
wotlld have cost $3680 to fix during the maintenance phase of the AS/400 software.
The reason that the cost of correcting a fault increases so steeply is related to
what has to be done to correct a fault. Early in the developm ent Iife cycle, the product
essentially exists only on paper, and correcting a fault may simply m ean using an
eraser and pencil. The other extreme is a product already delivered to a client. At
the very least, correcting a fault means editing the code, recompiling and relinking

it, and then carefully testing that the problem is solved. Next, it is critical to check
that making the change has not created a new problem elsewhere in the product. AlI
Please purchase Image To PDF Converter on to remove this message, thank you.