作者在本书的第5版讨论了该领域最新的话题并针对教学进行了修改。新增加的“如何实现”这部分总结了重要的技巧、新大纲、新要点以及更加具体的案例研究，突出了教学上的改进，增强了实用性。
为便于学生阅读，作者将本书分成两个部分：第1部分论述了软件工程的理论基础，第2部分阐述了生命周期的各个阶段。第2部分的主要特性是通过案例研究描述了所用的技巧。在第5版中，作者对连续的案例研究进行了更加详细的说明，以使学生更好地理解如何在实际中应用所学的技巧。给出的研究课题需要学生对案例研究进行修改，使学生能在干中学。
The fourth edition of this book was published in two versions, one with code examples presented in C++ and the other in Java. However, software engineering essentially is language independent, and in any event, there are relatively few code examples in this book.. Accordingly, in this edition, I made every effort to smooth over language-dependent details and ensure that the code examples are equally clear to C++ and Java users. For example, instead of using cout for C++ output and System out. println for Java output, I utilized the pseudocode instruction print. (The one exception is the new case study, where complete implementation details are given in both C++ and Java.) Therefore, the fifth edition can be considered a unification of the two versions of the fourth edition.
Pedagogics is the theme of the fifth edition. All through this book, I added material to highlight key aspects of each chapter. For example, there are How to Perform boxes that summarize important techniques such as object-oriented analysis and object--oriented design. In addition, new synopses and outlines assist both the student and the instructor. Also, to provide additional material on how to Perform the various techniques of software engineering, the case study in this edition is presented in greater detail than in the fourth edition.
The fourth edition included a chapter entitled ''Teams and the Tools of Their Trade." As part of the stress on pedagogics in this new edition, the material has been updated and split into two, to focus more clearly on each of the separate underlying topics. In this edition, Chapter 4 is devoted to teams, whereas the tools used by software engineers are described in Chapter 5.
As before, I include both classical and object-oriented material, notwithstanding the virtually unanimous agreement that the object-oriented paradigm is superior to the classical (structured) paradigm. My decision might surprise some 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 material on the classical paradigm. There are three reasons for this. First, it is impossible to appreciate why object-oriented technology is superior to classical technology who fully understanding the classical approach and how it differs from the object--oriented approach.
The second reason why both 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. It therefore is likely that many of the students who use this book will be employed by organizations that still use classical software engineering techniques. Furthermore, 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 students who use this text.
A third reason for including both paradigms is that a student who is employed at an organization considering the transition to object-oriented technology will be able to advise that organization regarding both 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 Modeling Language (UML), which was introduced shortly before that edition was published. In the intervening three years, UML has been formally standardized and become so widely used that any textbook that does not use UML to describe object-oriented analysis and design immediately would be obsolete. Therefore, I continue to use UML for object-oriented analysis and object-oriented design, as well as wherever diagrams depict Objects and their interrelationships.
Another then-new topic introduced into the fourth edition was design patterns. As with UML, design patterns now are part of mainstream software engineering. The material on design patterns therefore has been retained and strengthened.
A new topic in this edition is extreme programming (XP). XP still is controversial, but I feel that students need an overview of the topic so they can decide for themselves whether XP is merely a fad or a genuine major breakthrough in software engineering.
In the previous edition, I stressed the importance of documentation, maintenance, reuse, portability, testing, and CASE tools. In this edition, all these concepts are stressed equally firmly. It is no use teaching students the latest techniques unless they appreciate the importance 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 for the object-oriented paradigm also are included. In 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 permeates the way we think about software engineering. Object technology pervades this book.
The software 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 emphasis on metrics is retained. With regard to process improvement, the material on the capability maturity model (CMM) and ISO/IEC l5504 (SPICE) has been updated, and material on ISO/IEC l2207 has been added.
As in the fourth edition, this book contains over 600 references. I selected current research papers as well as classic articles and books whose message remains fresh and relevant. There is no question that software engineering is a rapidly moving field and that students therefore need to know the latest results and where in the literature to find them. At the same time, today's cutting-edge research is based on yesterday's truths, and I see no reason to exclude an older reference if its ideas are as applicable today as they originally were.
With regard to prerequisites, it is assumed that the reader is familiar with one high-level Programming language such as Pascal, C, C++, Ada, BASIC, COBOL, FORTRAN, or Java. In addition, the reader is expected to have taken a course in data structures.
HOW THE FIFTH EDITION IS ORGANIZED
Like the fourth edition of this book, the fifth edition is written for both the traditional one-semester and the newer two-semester software engineering curriculum. In the traditional one-semester (or one-quarter) course, the instructor has to rush through the theoretical material to provide the students the knowledge and skills needed for 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, Pat 2 of this book covers the life cycle, phase by phase, and Part l contains the theoretical material needed to understand Part 2. For example, 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 metrics for that phase, and a section on testing during that phase. Part l is kept short to enable the instructor to stat 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 with Part 2. The class then can begin developing the term project as soon as possible.
We turn now to the two-semester software engineering curriculum. More and more computer science and computer engineering departments are realizing that the overwhelming preponderance of their graduates find employment as software engineers. 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. When the term 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 Pall 2 (Chapters l0 through l6). Chapters 8 and 9 can then be taught in parallel with Part 2 or at the end of the course, while the students are implementing the term project. When 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 semester.
To ensure that the key software engineering techniques of Part 2 truly are understood, 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 both 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.
THE PROBLEM SETS
As in the previous edition, there are four types of problems. First, the end of each chapter contains a number of exercises intended to highlight key points. These exercises are self-contained; the technical information for all the exercises can be found in this book.
Second, there is a software term project. It is designed to be solved by students working in teams of three, the smallest number of team members that cannot confer over a standard telephone. The term project comprises l6 separate components, each tied to the relevant chapter. For example, design is the topic of Chapter l3, so in that chapter the component of the term project is concerned with software design. By breaking a large project into smaller, well-defined 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 l6 components to any other project that he or she chooses.
Because this book is written for use by graduate students as well as upper-class undergraduates, the third type of problem is based on research papers in the software engineering literature. In each chapter, an important 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 course, 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 students learn more by modifying an existing product than by developing a product from scratch. Many senior software 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 student to modify the case study in some way. For example, in one chapter the student is asked to redesign the case study using a different design technique from the one used for the case study. In another chapter, the student 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 modify the source code of the case study, it is available on the Word Wide Web at www.mhhe.com/engcs/compsci/schach. The web site also has transparency masters for all the figures in this book, as well as a complete set of PowerPoint lecture notes.
The Instructor's Solution Manual contains detailed solutions to all the exercises, as well as to the term project. The Instructor's Solution Manual is available from McGraw-Hill.
ACKNOWLEDGMENTS
I am indebted to those who reviewed this edition, including:
Arvin 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 Illinois)
Helene Kershner (University of Buffalo)
Chung Lee (California State Polytechnic University at Pomona)
Richard A. Lejk (University of North Carolina, Charlotte)
Susan A. Mengel (Texas Technological University)
David S. Rosenblum (University of California at Irvine)
Shmuel Rotenstreich (George Washington University)
Wendel Scarbrough (Azusa Pacific University)
Gerald B. Sheble (Iowa State)
Jie We (City University of New York)
David Workman (University of Central Florida)
I thank two individuals who made contributions to earlier books. First, Jeff Gray once again mad numerous insightful suggestions. In particular, I am grateful for his many ideas regarding Chapter 8. Also, he once again is a coauthor of the Instructor's Solution Manual. Second, my son David has made a number of helpful contributions to the book and again is a coauthor of the Instructor's Solution Manual.
Since 1999, I have been involved in joint research with Dr. Amir Tome of RAFAEL and the Technion, Israel Institute of Technology The papers we wrote together are nominally on maintenance. However, the issue underlying our research is the nature of software engineering. A direct consequence of working with Amir is that I gained new insight into software engineering. I have incorporated many of these ideas into these edition.
Turning now to my publisher, McGraw-Hill, I am truly grateful to executive editor Betsy Jones and developmental editor Emily Gray for their assistance from start to finish. I particularly appreciate their suggestions regarding giving equal stress to both C++ and Java in an integrated volume. Rick Hecker was the ideal Project manager in every way. I was most fortunate to have Gnomi Schrift Gouldin as the copy editor for this book. She greatly improved the readability of my manuscript, and I am grateful for her many suggestions.
I would like to thank the many instructors from all over the world who sent me e-mail concerning the fourth edition. I am exceedingly appreciative of their suggestions, comments, and criticisms. I look forward with anticipation to receiving instructors' feedback on this edition also. My e-mail address is srs@vuse.vanderbilt.edu.
Students, too, have been most helpful. First, I thank my students at Vanderbilt for their many questions and comments, both inside and outside the classroom. I also an most grateful for the provocative questions and constructive suggestions e-mailed me by students from all over the world. I look forward keenly to student feedback on this edition, too.
Finally, as always, I thank my Family for their continual support. When I started writing books, my limited free time had to be shared between my young children and my current book project. Now that my children are adults and work with me on my books, writing has become a body activity. For the tenth time, it is my privilege to dedicate this book to my wife, Sharon, and my children, David and Lauren, With love.
stephen R. Schach
Preface xv
PART 1 Introduction to Software Engineering 1
Chapter 1 The Scope of Software Engineering 3
l.l Historical Aspects 4
l.2 Economic Aspects 7
l.3 Maintenance Aspects 8
l.4 Specification and Design Aspects l3
l.5 Team Programming Aspects 15
1.6 The Object-Oriented Paradigm l7
l.7 Terminology 2l
Chapter Review 23
For Further Reading 24
Problems 25
References 26
Chapter 2 The Software Process 30
2.1 Client, Developer, and User 32
2.2 Requirements Phase 33
2.2.l Requirements Phase Testing 34
2.2.2 Requirements Phase Documentation 35
2.3 Specification Phase 35
2.3.l Specification Phase Testing 37
2.3.2 Specification Phase Documentation 38
2.4 Design Phase 38
2.4.l Design Phase Testing 39
2.4.2 Design Phase Documentation 40
2.5 Implementation Phase 40
2.5.l Implementation Phase Testing 40
2.5.2 Implementation Phase Documentation 40
2.6 Integration Phase 41
2.6.l Integration Phase Testing 4l
2.6.2 Integration Phase Documentation 42
2.7 Maintenance Phase 42
2.7.l Maintenance Phase Testing 43
2.7.2 Maintenance Phase Documentation 43
2.8 Retirement 43
2.9 Problems with Software Production: Essence and Accidents44
2.9.l Complexity 45
2.9.2 Conformity 47
2.9.3 Changeability 48
2.9.4 Invisibility 49
2.9.5 No Si1verBullet 50
2.l0 Improving the Software Process 5l
2.l1 Capability Maturity Models 5l
2.l2 Other Software Process Improvement Initiatives 54
2.l3 Costs and Benefits of Software Process Improvement 55
Chanter Review 57
For Further Reading 58
Problems 59
References 60
Chapter 3 Software Life-Cycle Models 64
3.l Build-and-Fix Model 64
3.2 Waterfall Model 65
3.2.l Analysis of the Waterfall Model 68
3.3 Rapid Prototyping Model 70
3.3.l Integrating the Waterfall and Rapid Prototyping Models7l
3.4 Incremental Model 72
3.4.l Analysis of the Incremental Model 73
3.5 Extreme Programming 75
3.6 Synchronize-and-Stabilize Model 77
3.7 Spiral Model 78
3.7.l Analysis of the Spiral Model 82
3.8 Object-Oriented Life-Cycle Models 82
3.9 Comparison of Life-Cycle Models 84
Chapter Review 86
For Further Reading 86
Problems 87
References 87
Chapter 4 Teams 90
4.l Team Organization 90
4.2 Democratic Team Approach 92
4.2.l Analysis of the Democratic Team Approach 93
4.3 Classical Chief Programmer Team Approach 93
4.3.l The New York Times Project 95
4.3.2 Impracticality of the Classical Chief
Programmer Team Approach 96
4.4 Beyond Chief Programmer and Democratic Teams 97
4.5 Synchronize-and-Stabilize Teams l0l
4.6 Extreme Programming Teams l02
Chapter Review l03
For Further Reading 104
Problems l04
References l05
Chapter 5 The Tools Of the Trade 106
5.l Stepwise Refinement 106
5.l.l Stepwise Refinement Example l07
5.2 Cost-Benefit Analysis ll3
5.3 Software Metrics ll4
5.4 CASE ll5
5.5 Taxonomy of CASE ll6
5.6 Scope of CASE ll8
5.7 Software Versions l22
5.7.l Revisions l22
5.7.2 Variations l23
5.8 Configuration Control l24
5.8.l Configuration Control during Product Maintenance l26
5.8.2 Baselines l27
5.8.3 Configuration Control during Product Development l27
5.9 Build Tools 128
5.l0 Productivity Gains with CASE Technology l29
Chapter Review l3l
For Further Reading l3l
Problems l32
References l33
Chapter 6 Testing 136
6.l Quality Issues l37
6.l.l Software Quality Assurance l37
6.l.2 Managerial Independence l38
6.2 Nonexecution-Based Testing l39
6.2.l Walkthroughs l39
6.2.2 Managing Walkthroughs l40
6.2.3 Inspections l4l
6.2.4 Comparison of Inspections and Walkthroughs l43
6.2.5 Strengths and Weaknesses of Reviews l44
6.2.6 Metrics for Inspections l44
6.3 Execution-Based Testing l45
6.4 What Should Be Tested l45
6.4.l Utility l46
6.4.2 Reliability l47
6.4.3 Robustness l47
6.4.4 Performance l48
6.4.5 Correctness l49
6.5 Testing versus Correctness Proofs l5l
6.5.l Example of a Correctness Proofs l5l
6.5.2 Correctness Proof Case Study l54
6.5.3 Correctness Proof and Software Engineering l55
6.6 Who Should Perform Execution-Based Testing l58
6.7 When Testing Stops 160
Chapter Review l60
For Further Reading l6l
Problems l62
References 164
Chapter 7 From Modules to Objects 167
7.l What Is a Module l67
7.2 Cohesion l7l
7.2.l Coincidental Cohesion l7l
7.2.2 Logical Cohesion l72
7.2.3 Temporal Cohesion l73
7.2.4 Procedural Cohesion l74
7.2.5 Communicational Cohesion l74
7.2.6 Functional Cohesion l75
7.2.7 Informational Cohesion l75
7.2.8 Cohesion Example l76
7.3 Coupling 177
7.3.l Content Coupling l78
7.3.2 Common Coupling l78
7.3.3 Control Coupling l80
7.3.4 Stamp Coupling l80
7.3.5 Data Coupling l82
7.3.6 Coupling Example l82
7.3.7 The Importance of Coupling l82
7.4 Data Encapsulation l84
7.4.l Data Encapsulation and Product Development l86
7.4.2 Data Encapsulation and Product Maintenance l88
7.5 Abstract Data Types l94
7.6 Infromation Hiding l95
7.7 Objects l98
7.8 Inheritance, Polymorphism, and Dynamic Binding 20l
7.9 Cohesion and Coupling of Objects 203
7.l0 The Object-Oriented Paradigm 204
Chapter Review 207
For Further Reading 207
Problems 208
References 209
Chapter 8 Reusability Portability, and Interoperability 212
8.l Reuse Concepts 2l2
8.2 Impediments to Reuse 2l4
8.3 Reuse Case Studies 216
8.3.l Raytheon Missi1e Systems Division 2l6
8.3.2 Toshiba software Factory 2l7
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 22l
8.4 Objects and Reuse 222
8.5 Reuse during the Design and Implementation Phases 222
8.5.l Design Reuse 222
8.5.2 Application Frameworks 224
8.5.3 Design Patterns 225
8.5.4 Software Architecture 229
8.6 Reuse and Maintenance 230
8.7 Portability 23l
8.7.l Ware Incompatibilities 232
8.7.2 Operating Systems Incompatibilities 233
8.7.3 Numerical Software Incompatibilities 233
8.7.4 Compiler Incompatibilities 235
8.8 Why Portability 239
8.9 Techniques for Achieving Portability 240
8.9.l Portable System Software 240
8.9.2 Portable Application Software 24l
8.9.3 Portable Data 242
8.l0 Interoperability 243
8.l0.l COM 243
8.l0.2 CORBA 244
8.l0.3 Comparing COM and CORBA 245
8.ll Future Trends in Interoperability 245
Chapter Review For Further Reading 247
Problems 248
References 250
Chapter 9 Planning and Estimating 257
9.l Planning and the Software Process 257
9.2 Estimating Duration and Cost 259
9.2.l Metrics for the Size of a Product 260
9.2.2 Techniques of Cost Estimation 264
9.2.3 Intermediate COCOMO 267
9.2.4 COCOMO II 270
9.2.5 Tracking Duration and Cost Estimates 272
9.3 Components of a Software Project Management Plan 272
9.4 software Project Management Plan Framework 274
9.5 IEEE Software Project Management Plan 274
9.6 Planning Testing 278
9.7 Planning Object-Oriented Projects 279
9.8 Training Requirements 280
9.9 Documentation Standards 281
9.l0 CASE Tools for Planning and Estimating 282
9.ll Testing the Software Project Management Plan 282
Chapter Review 283
For Further Reading 283
Problems 284
References 285
PART 2 The Phases of the Software Life Cycle 289
Chapter 1O Requirements Phase 290
l0.l Requirements Elicitation 29l
l0.l.l Interviews 29l
l0.l.2 Scenarios 292
l0.l.3 Other Requirements Elicitation Techniques 293
l0.2 Requirements Analysis 294
l0.3 Rapid Prototyping 294
l0.4 Human Factors 296
l0.5 Rapid Prototyping as a Specification Technique 298
l0.6 Reusing the Rapid Prototype 300
l0.7 Management Implications of the Rapid Prototyping Model302
l0.8 Experiences with Rapid Prototyping 304
l0.9 Techniques for Requirements Elicitation and Analysis 305
l0.l0 Testing during the Requirements Phase 305
10.ll CASE Tools for the Requirements Phase 306
l0.l2 Metrics for the Requirements Phase 307
10.l3 Object-Oriented Requirements 308
10.l4 Air Gourmet Case Study: Requirements Phase 308
10.l5 Air Gourmet Case Study: Rapid Prototype 3ll
l0.l6 Challenges of the Requirements Phase 3l3
Chapter Review 3l5
For Further Reading 3l5
Problems 316
References 3l7
Chapter 11 Specification Phase 319
ll.l The Specification Document 3l9
ll.2 Informal Specifications 32l
ll.2.l Case Study: Text Processing 322
ll.3 Structured Systems Analysis 323
1l.3.l Sally's Software Shop 323
l1.4 Other Semiformal Techniques 33l
ll.5 Entity-Relationship Modeling 332
1l.6 Finite State Machines 335
ll.6.l Elevator Problem: Finite State Machines 336
ll.7 Petri Nets 34l
ll.7.l Elevator Problem: Petri Nets 343
ll.8 Z 346
ll.8.l Elevator Problem: Z 347
ll.8.2 Analysis of Z 349
ll.9 Other Formal Techniques 35l
ll.l0 Comparison of Specification Techniques 352
ll.ll Testing during the Specification Phase 353
ll.l2 CASE Tools for the Specification Phase 354
ll.l3 Metrics for the Specification Phase 355
ll.l4 Air Gourmet Case Study: Structured Systems Analysis 355
ll.l5 Air Gourmet Case Study: Software Project Management Plan 357
ll.l6 Challenges of the Specification Phase 358
Chapter Review 358
For Further Reading 359
Problems 360
References 362
Chapter 12 Object-Oriented Analysis Phase 366
l2.l Object-Oriented Analysis 366
l2.2 Elevator Problem: Object-Oriented Analysis 369
l2.3 Use-Case Modeling 369
l2.4 Class Modeling 37l
l2.4.l Noun Extraction 372
l2.4.2 CRC Cards 374
l2.5 Dynamic Modeling 375
l2.6 Testing during the Object-Oriented Analysis Phase 378
l2.7 CASE Tools for the Object-Oriented Analysis Phase 383
l2.8 Air Gourmet Case Study: Object-Oriented Analysis 383
l2.9 Challenges of the Object-Oriented Analysis Phase 390
Chapter Review 39l
For Further Reading 39l
Problems 392
References 393
Chapter 13 Design Phase 395
l3.l Design and Abstraction 395
l3.2 Action-Oriented Design 396
l3.3 Data Flow Analysis 397
l3.3.l Data Flow Analysis Example 398
l3.3.2 Extensions 402
13.4 Transaction Analysis 403
13.5 Data-Oriented Design 406
l3.6 Object-Oriented Design 406
l3.7 Elevator Problem: Object-Oriented Design 407
13.8 Formal Techniques for Detailed Design 415
l3.9 Real-Time Design Techniques 4l6
l3.10 Testing during the Design Phase 4l8
13.l1 CASE Tools for the Design Phase 4l8
l3.l2 Metrics for the Design Phase 4l9
l3.13 Air Gourmet Case Study: Object-Oriented Design 420
l3.l4 Challenges of the Design Phase 429
Chapter Review 429
For Further Reading 430
Problems 43l
References 43l
Chapter 14 Implementation Phase 434
14.l Choice of Programming Language 434
l4.2 Fourth-Generation Languages 437
l4.3 Good Programming Practice 440
l4.4 Coding Standards 445
l4.5 Module Reuse 446
l4.6 Module Test Case Selection 447
l4.6.l Testing to Specifications versus Testing to Code 447
l4.6.2 Feasibility of Testing to Specifications 447
l4.6.3 Feasibility of Testing to Code 448
l4.7 Black-Box Module-Testing Techniques 451
l4.7.l Equivalence Testing and Boundary Value Analysis 45l
l4.7.2 Functional Testing 452
l4.8 Glass-Box Module-Testing Techniques 454
l4.8.l Structural Testing: Statement, Branch, and Path Coverage 454
l4.8.2 Complexity Metrics 456
l4.9 Code Walkthroughs and Inspections 458
l4.l0 Comparison of Module-Testing Techniques 458
l4.ll Cleanroom 459
l4.12 Potential Problems When Testing Objects 460
l4.l3 Management Aspects of Module Testing 463
l4.l4 When to Rewrite Rather than Debug a Module 463
l4.l5 CASE Tools for the Implementation Phase 465
l4.l6 Air Gourmet Case Study: Black-Box Test Cases 465
l4.l7 Challenges of the Implementation Phase 467
Chapter Review 467
For Further Reading 468
Problems 469
References 470
Chapter 15 Implementation and Integration Phase 474
l5.l Introduction to Implementation and Integration 474
l5.l.l Top-down Implementation and Integration 475
l5.l.2 Bottom-up Implementation and Integration 477
l5.l.3 Sandwich Implementation and Integration 478
l5.l.4 Implementation and Integration of Object-Oriented Products 480
l5.l.5 Management Issues during the Implementation and Integration Phase 480
l5.2 Testing during the Implementation and Integration
Phase 48l
l5.3 Integration Testing of Graphical User Interfaces 48l
l5.4 Product Testing 482
l5.5 Acceptance Testing 483
l5.6 CASE Tools for the Implementation and Integration
Phase 484
l5.6 CASE Tools for the Complete Software Process 484
l5.8 Integrated Environments 485
l5.9 Environments for Business Applications 486
l5.l0 Public Tool Infrastructures 487
l5.ll Potential Problems with Environments 487
l5.l2 Metrics for the Implementation and Integration Phase 488
l5.l3 Air Gourmet Case Study: Implementation and Integration Phase 488
l5.l4 Challenges of the Implementation and Integration
Phase 489
Chapter Review 489
For Further Reading 490
Problems 490
References 492
Chapter 16 Maintenance Phase 493
16.1 Why Maintenance Is Necessary 493
16.2 What Is Required of Maintenance Programmers 494
l6.3 Maintenance Case Study 497
l6.4 Management of Maintenance 498
l6.4.l Fault Reports 498
l6.4.2 Authorizing Changes to the Product 499
l6.4.3 Ensuring Maintainability 500
l6.4.4 Problem of Repeated Maintenance 500
l6.5 Maintenance of Object-Oriented Software 501
l6.6 Maintenance Skills versus Development Skills 504
l6.7 Reverse Engineering 505
16.8 Testing during the Maintenance Phase 506
l6.9 CASE Tools for the Maintenance Phase 507
l6.l0 Metrics for the Maintenance Phase 507
l6.l1 Air Gourmet Case Study: Maintenance Phase 508
16.l2 Challenges of the Maintenance Phase 508
Chapter Review 509
For Further Reading 509
Problems 510
References 51l
Appendix A Broadlands Area Children's Hospital 513
Appendix B Software Engineering Resources 518
Appendix C Air Gourmet Case Study: C Rapid Prototype 520
Appendix D Air Gourmet Case Study: Java Rapid Prototype 521
Appendix E Air Gourmet Case Study: Structured Systems Analysis 522
Appendix F Air Gourmet Case Study: Software Project Management Plan 529
Appendix G Air Gourmet Case Study: Object-Object-Oriented Analysis 534
Appendix H Air Gourmet Case Study: Design for C++ Implementation 535
Appendix I Air Gourmet Case Study: Design for Java Implementation 560
Appendix J Air Gourmet Case Study: Black-Box Test Cases 582
Appendix K Air Gourmet Case Study: C++ Source Code 588
Appendix L Air Gourmet Case Study: Java Source Code 589
Bibliography 590
Author Index 617
Subject Index 623
