Vice President and Editorial Director, ECS: Marcia J. Horton Executive Editor:1tacy Dunkelberger Assistant Editor: Melinda Hasgerty Director of Team-Based Project Management: Vince O'Brien Senior Managing Editor: Scott Disanno Production Liaison: Jane Bonnell Production Editor: Pavithra Jayapaul, TexTech Senior Operations Specialist: Alan Fischer Operations Specialist: Lisa McDowell Marketing Manager: Erin Davis Marketing Assistant: Mack Patterson Art Director: Kenny Beck Cover Designer: Kristine Carney Cover Image: [credit to come] Art Editor: Greg Dulles Media Editor: Dani.el Sandin Media Project Manager: John M. Cassar Composition/Full-Service Project Management:Tex'Tuch International Pvt. Ltd.
Copyright © 2010, 2006, 2001, 1998 by Peiu son Higher Education. Upper SaddJe Rh•er, New Jersey 07458. All rights reserved. Manufactured in the United States of America. lbis publication is protected by Copy- 1ight and permission should be obtained from the publisher prior to any prohibited reproduction,storage in a retrieval system, or transmission in any form or by any means, electronic, mechanicaJ,photocopying, record- ing, or likewise. To obtain permission(s) to use materials from this work, please submit a w!'.itten request to Pearson Higher Education, Permissions Department, 1 Lake Street, Upper Saddle R iver, NJ 07458.
The author and publisher of this book have used their best efforts in preparing this book. These efforts include the development, research, and testing of the theories and programs to dete!'.mine their etrectiveness. The author and publisher make no warranty of any kind, expressed or implied, with regard to these programs or the documentation contained in this book. The author and publisher shall not be liable in any event for incidental or consequential damages in connection \vi th, or arising out o:f, the furnishing, performance, or use of these programs.
Library of Congress Cataloging-In-Publication Data Pfteeger. Shari Law:rence.
Software engineering: theory and practice I Shari Lawrence Pfleeger, Joanne M. Atlee. -4th ed. p.cm.
Includes bibliographical references an.d index. ISBN-13: 978-0-13-606169-4 (alk. paper) ISBN-10: 0.13-606169-9 (a.lk. paper)
1. Software engineering. I. Atlee, Joanne M. II. Title. QA76.758.P492010 005.l-<lc22 2008051400
Prentice Hall is an imprint of
PEARSON www.pear:sonhighered .com
10 9 8 7 6 5 4 3 2 1
"From so much loving and journeying, books emerge." Pablo Neruda
To Florence Rogart for providing the spark; to Norma Mertz for helping to keep the flame bu ming.
To John Gannon, posthumously, for his integrity, inspiration, encouragement, friendship, and the legacy he has left to all of
us in software engineering. J.M.A.
BRIDGING THE GAP BETWEEN RESEARCH AND PRACTK E
Software engineering has come a long way since ]968, when the term was first used at a NATO conference. And software itself has entered our lives in ways that few had anti- cipated, even a decade ago. So a firm grounding in software engineering theory and practice is essential for understanding how to build good software and for evaluating the risks and opportunities that software presents in our everyday lives. This text repre- sents the blending o f the two current software engineering worlds: that of the practi- tioner, whose main focus is to build high-qlllality products that perform useful functions, and that of the researcher, who strives to find ways to improve the quality of productts and the productivity of those who build them. Edsgar Dykstra continually reminded us that rigor in research and practice tests our understanding of software engineering and helps us to improve our thinking, our approaches, and ultimately our productts.
It is in this spirit that we have enhanced our book, buildin g an underlying frame- work for this questioning and improvement. In particular, this fourth edition contains extensive material about bow to abstract and model a problem, and how to use models, design principles, design pauerns, and design strategies to create appropriate solutions. Software engineers are more than programmers fo llowing instructions, much as chefs are more than cooks following recipes. There is an art to building good software, and the art is embodied in understanding how to abstract and model the essential elements of a problem and then use those abstractions to design a solution. We often hear good devel- opers talk about "elegant" solutions, meaning that the solution addresses the heart of the problem, such that not only does the software solve the problem in its current form but it can also be modified as the problem evolves over time. In this way, students learn to blend research with practice and art with science, to build solid software.
The science is always grounded in reality. Designed for an undergraduate soft- ware engineering curriculum, this book paints a pragmatic picture of software engi- neering research and practices so that students can apply what they learn directly to the real-world problems they are trying to solve. Examples speak to a student's limited experience but illustrate clearly how large software developme nt projects progress from need to idea to reality. The examples represent the many situations that readers are likely to experience: large projects and small, "agile" methods and highly structured ones, object-oriented and procedural approaches. real-time and transaction processing, development and maintenance situations.
The book is also suitable for a graduate course offering an introduction to soft- ware engineering concepts and practices, or for practitioners wishing to expand their
knowledge of the subject. Io particular, Chapters 12, 13, and 14 present thought- provoking material designed to interest graduate students in current research topics.
This text has many key features that distinguish it from other books.
• Unlike other software engineering books that consider measurement and model- ing as separate issues, this book blends measurement and modeLing with the more general discussion of software engineering. That is, measurement and modeling are considered as an integral part of software engineering strategies, rather than as separate discipLines. Thus, students learn how to abstract and model, and how to involve quantita tive assessment and improvement in their daily activities. They can use their models to understand the important elements of the problems they are solving as well as the solution alternatives; they can use measurement to eval- uate their progress on an individual, team, and project basis.
• Similarly, concepts such as reuse, risk management, and quaLity engineering are embedded in the software engineering activities that are affected by them, instead of being tre ated as separate issues.
• The current edition addresses the use of agile methods, including extreme program- ming. It describes the benefits and risks of giving developers more autonomy and contrasts this agility with more traditional approaches to software development.
• Each chapter applies its concepts to two common examples: one that represents a typical information system, and another that represents a real-time system. Both examples are based on actual projects. The information system example describes the software needed to determine the price of advertising time for a large British te levision company. The real-time system is the control software for the Ariane-5 rocket; we look at the problems reported, and explore bow software engineering techniques could have helped to locate and avoid some of them. Students can foUow the progress of two typical projects, seeing how the various pract.ices described in the book are merged into the technologies used to build systems.
• At the end of every chapter, the results are expressed in three ways: what the con- te nt of the chapter means for development teams, what it means for individual developers, and what it means for researchers. The student can easily review the highlights of each chapter, and can see the chapter's relevance to both research and practice.
• The Companion Web site can be found at www.prenhalJ.com/pfteeger. It contains current examples from the lite rature and examples of real artifacts from reaJ projects. It also includes Links to Web pages for relevant tool and method vendors. It is here that students can find real requirements documents, designs, code, test plans, and more. Students seeking additional, in-depth information are pointed to re putable, accessible publications and Web s.ites. Tue Web pages are updated regu- larly to keep the material in the textbook current, and include a facility for feed- back to the author and the pubLisher.
• A Student Study G uide is available from your local Pearson Sales Representative.
• PowerPoint slides and a full solutions manual are available on the lnstructor Resource Center. Please contact your local Pearson Sales Representative for access information.
• The book is reple te with case studies and examples from the literature. Many of tbe one-page case studies sbowo as sidebars in tbe book are expanded on tbe Web page. The student can see bow tbe book's theoretical concepts are applied to real- life situations.
• Each chapter ends with thought-provoking questions about policy, legal, and e th- ical issues in software engineering. Students see software engineering in its social and political contexts. As with other sciences, software engineering decisions must be viewed in terms of the people their consequences will affect.
• Every chapter addresses both procedural and object-orienrted development. In addition, Chapter 6 on design explains the steps of an object-oriented develop- ment process. We discuss several design principles and use object-oriented examples to show bow designs can be improved to incorporate these principles.
• The book has an annotated bibliography that points to many of the seminal papers in software engineering. Io addition, the Web page points to annotated bibliographies and discussion groups for specialized areas, such as software relia- biJity, fault tolerance, computer security, and more.
• Each chapter includes a description of a term project, involving development of software for a mortgage processing system. The instructor may use this term project, or a variation of it, in class assignme nts.
• Each chapter ends with a list of key references for the concepts in the chapter, enabling students to find in-depth information about particular tools and methods discussed in the chapter.
• This edition includes examples highlighting computer security. In particular, we emphasize designing security in, instead of adding it during coding or testing.
CONTENTS AND ORGANIZATION
This text is organized in three parts. The first part motivates the reader, explaining why knowledge of software engineering is important to practitioners and researchers alike. Part I a lso discusses the need for understanding process issues, for making decisions about the degree of "agility" developers will have, and for doing careful project plan- ning. Part II walks through the major steps of development and maintenance, regard- less of the process mode l used to build the software: e liciting, modeling, and checking the requirements; designing a solution to the problem; writing and testing the code; and turning it over to the customer. Part III focuses on evaluation and improvement. It looks at bow we can assess the quality of our processes and products, and how to take steps to improve them.
Chapter 1: Why Software Engineering?
In this cbapter we address our track record, motivating the reader and highlighting where in later chapters certain key issues are examined. Io particular, we look a t
Wasserman's key factors that help define software engineering: abstraction, analysis and design methods and notations, modularity and architecture, software life cycle and process, reuse, measurement, tools and integra ted environments, and user interface and prototyping. We discuss the difference be tween computer science and software engi- neering, explaining some of the major types of problems that can be encountered, and laying the groundwork for the rest of the book. We also explore the need to take a sys- tems approach to buiJding software, and we introduce the two common examples that wiU be used in every chapter. It is here that we introduce the context for the te rm project.
Chapter 2: Modeling the Process and Life Cycle
Io this chapter, we present an overview of different types of process and life-cycle mod- els, including the waterfalJ model, the V-model, the spiral model, and various protort:yp- ing models. We address the need for agile methods, where developers are given a great deal of autonomy, and contrast them with more traditional software development pro- cesses. We also describe several modeling techniques and tools, including systems dynamics and other corrunonJy-used approaches. Each of the two common examples is modeled in part with some of the techniques introduced here.
Chapter 3: Planning and Man.aging the Project
Here, we look at project planning and scheduJing. We introduce notions such as activi- ties and milestones, work breakdown structure, activity graphs, risk management, and costs and cost estimation. Estimation models are used to estimate the cost and schedule of the two common exam ples. We focus on actua l case studies, including management o f software development for the F-16 airplane and for Digital's alpha AXP programs.
Chapter 4: Capturing the Requirem ents
This chapter emphasizes the critical roles of abstraction and modeling in good software engineering. In particuJar, we use models to tease out misunderstandings and missing details in provided requirements, as well as to communicate require ments to others. We explore a number of different modeling paradigms, study example notations for each paradigm, discuss when to use each paradigm, and provide advice about how to make particular modeling and abstraction decisions. We discuss diffe rent sources and differ- ent types of requirements (functional requireme10ts vs. quality requirements vs. design constraints), explain how to write testable requirements, and describe bow to resolve conflicts. O ther topics discussed include requirements e licitation, requirements docu- mentation, requirements reviews, requirements q uality and how to measure it, and an example of bow to select a specification method. The chapter ends with application of some of the methods to the two common examples.
Chapter 5: Designing the Architecture
This chapter on software architecture bas been completely revised for the fourth edition. It begins by describing the role of architecture in the software design process and in the
larger development process. We examine the steps involved in producing the a rchitec- ture, including modeling, analysis, documentation, a nd review, resulting in the creatio n of a Software Architecture Document that can be used by program designers in describing modules and interfaces. We discuss bow to decompose a problem into parts, and bow to use diffe renl views to examine the several aspeccs of the problem so as to find a suitable solution. Next, we focus on modeling the solution ·using one or more architectural styles, including pipe-and-filter, peer-to-peer, client-server, publish-subscribe, repositories, and layering. We look at combining styles and using them to achieve quality goals, such as modifia bilil y, performance, securil y, re liabilil y, robustness, and usability.
Once we have an initial architecture, we evaluate and refine it. In this chapter , we show ho w to measure design quality and to use evaluation techniques in safe ty analysis, security analysis, trade-off analysis, and cost-bene fit analysis to selecl the best archi lec- ture for the customer's needs. We stress the importance of documenting the design rationale, validating and verifying that the design matches the requirements, and er.eat- ing an architecture that suits the customer's product needs. Towards the end of the chapter, we examine ho w to build a product-line architecture that aUows a software provide r to reuse the design across a family of similar products. The chapter ends with an arcltitectural analysis of our information system and real-time e xamples.
Chapter 6: Designing the Modules
Chapter 6, substantially revised in this edition, investigates how to move from a descrip- tion o f the system architeclure to descriptions of the design's individual modules. We begin with a discussion of the design process and then introduce six key design prin- ciples to guide us in fashioning modules from the architecture: modularity, inte rfaces, information hiding, incremental development, abs traction, and gene rality. Next, we take an in-depth look at object-oriented design and how it supports our s ix principles. Using a variety of notations from the Unified Modeling Language, we show how to represent multiple aspects of module functionality and inte raction, so that we can build a robust and maintainable design. We also describe a collection of design patte rns, each with a particul!a r purpose, and demonstrate how they can be used to re inforce the design prin- ciples. Next, we discuss global issues such as data management, exception handling, user interfaces, and frameworks; we see how consistency and clarity of approach can lead to more effective designs.
Taking a careful look at object-oriented measurement, we apply some of the com- mon object-oriented metrics to a service sta tion example. We note how changes in met- rics values, due to changes in the design, can help us decide bow Ito aUocate resources and search for faults. Fina lly, we apply object-orie nted concepts to our information sys- tems and real-time examples.
Chapter 7: Writing the Programs
In this chapte r, we address code-level design decisions and the issues involved in imple- menting a design to produce high-quali ty code. We discuss standa rds and procedures, and suggest some simple programming guidelines. Examples are provided in a varie ty of languages, including both object-oriented and procedural. We discuss the need. for
xvi ii Preface
program documentatiom and an error-handling strategy. The chapter ends by applying some of the concepts to the two common examples.
Chapter 8: Testing the Programs
lo th.is chapte r, we explo re several aspects of test:ing programs. We distinguish conven- tional testing approaches from the cleanroom method, and we look at how to test a variety of systems. We present definitions and categories of software problems, and we discuss how orthogonal defect classification cam make data collection and analysis more effective. We then explain the diffe rence between unit testing and integration testing. After introducing several automated test tools and techniques, we explain the need for a testing life cycle and how the tools can be integrated into it. F111ally, the chap- te r applies these concepts to the two common examples.
Chapter 9: Testing the System
We begin with principles of system testing, including reuse of test suites and data, and the need for careful configuration management. Concepts introduced include function test- ing, performance testing, acceptance testing and installa tion testing. We look at the spe- cial needs of testing object-oriented systems. Several test tools are described, and the roles of test team members are discussed. Next, we introduce the reader to software re lia- bility modeling, and we explore issues of reliability, maintainability, and availability. The reader learns how to use the results of testing to estimate the likely characteristics of the delivered product. The several types of test documentation are introduced, too, and the chapter ends by describing test strategies for the two common examples.
Chapter 10: Delivering the System
This chapter discusses tbe need for training and documentation, and presents several examples of training and documents that could accompany the information system and real-time examples.
Chapter 11: Main taining the System
ln this chapter, we address the results of system change. We explain how changes can occur during the system's life cycle, and how system design, code, test process, and documenta- tion must accommodate them. Typical maintenance problems are discussed, as well as the need for careful configuration management. There is a thorough discus.sion of the use of measurement to predict likely changes, and to evaluate the effects of change. We look at reengineering and restructuring in the overall context of rejuvenating legacy systems. Finally, the two common examples are evaluated ill! terms of the like Li hood of change.
Chapter 12: Evaluating Products, Processes, and Resources
Since many software engineering decisions involve the incorporatjon and integration of existing components, this chapter addresses ways to evaluate processes and products. It discusses the need for empirical evaluation and gives several examples to show how measure ment can be used to establish a baseline for quality and productivity We look at
several quality models, !bow to evaluate systems for reusability, how to perform post- mortems, and how to understand return on investment in information technology. These concepts are applied to the two common examples.
Chapter 13: Improving Predictions, Products, Processes, and J<esources
This ch.apter builds on Chapter 11 by showing bow prediction, product, process, and resource improvement can be accomplished. It contains several in-depth case studies to show how prediction models, inspection techniques, and other aspects of software engi- neering can be understood and improved using a variety of investigative techniques. This chapter ends with a set of guidelines for evaluating current situations and identify- ing opportunHies for imiProvement.
Chapter 14: The Fwure of Software Engineering
In this final chapter, we look at several open issues in software engineering. We revisit Wasserman's concepts to see bow well we are doing as a discipline. We examine sev,eral issues in technology transfer and decision-making, to determine if we do a good job at moving important ideas from research to practice. Finally, we examine controversial issues, such as licensing of software engineers as professional engineers and the trend towards more domain-specific solutions and methods.
Books are written as fri,ends and fa mily provide technical and emotional support. It is impossible to list here all those who helped to sustain us during the writing and revising, and we apologize in advance for any omissions. Many thanks to the readers of earlier editions, whose careful scrutiny of the text generated excellent suggestions for correc- tion and clarification. As far as we know, all such suggestions have been incorporated into this edition. We continue to appreciate feedback from readers, positive or negative.
Carolyn Seaman (University of Maryland-Baltimore Campus) was a terrific reviewer of the first edition, suggesting ways to clarify and simplify, leading to a tighter, more understandable text. She also prepared most of the solutions to the exercises, and helped to set up an early version of the book's Web site. I am grate:ful for her friendship and assistance. Yiqing Liang and Carla Valle updated the We b site and added sub- stantial new material for the second edition; Patsy Ann Zimmer (University of Water- loo) revised the Web site for the third edition, particularly with respect to modeling notations and agile methods.
We owe a huge thank-you to Forrest Shull (Fraunhofer Center-Maryland) and Roseanne Tesoriero (Washington College), who developed the initial study guide for this book; to Maria Vieira Nelson (Catholic University of Minas Gerais, Brazil), who revised the study guide and the solutions manual for the third edition; and to Eduardo S. Barrenechea (University of Waterloo) for updating the materials for the fourth edition. Thanks., too, to Hossein Saiedian (University of Kansas) for preparing the PowerPoint presentation for the fourth edition. We are also particularly indebted to Guilherme Travassos (Federal University of Rio de Janeiro) for the use of material that he developed
with Pfleeger at the University of Maryland-College Park, and that he enriched and expanded considerably for use in subsequent classes.
Helpful and thoughtful reviewers for all four editions included Barbara Kitcben- ham (Keele University, UK), Bernard Woolfolk (Lucent Technologies), Ana Regina Cavakanti da Rocha (Federal University of Rio de Janeiro), Frances Uku (University of California at Berkeley), Lee Scou Ehrhart (MITRE), Laurie Werth (University of Texas), Vickie Almstrum (University ofTexas), Lionel Briand (Simula Research, Nor- way), Steve Thibaut (University of Florida), Lee Wittenberg (Kean College of New Jer- sey), Philip Johnson (University of Hawaii), Daniel Berry (University of Waterloo, Canada), Nancy Day (University of Waterloo), Jianwei Niu (University of Waterloo), Chris Gorringe (University of East Anglia, UK), Ivan Aaen (Aalborg University), Damla Turget (University of Central Florida), Lamie Williams (North Carolina State University), Ernest Sibert (Syracuse University),Allen HoUiday (California State Uni- versity, Fullerton) David Rine (George Mason University),Anthony Sullivan (Univer- sity of 1exas, Dallas), D avid Chesney (University of Michigan, Ann Arbor), Ye Duan (Missouri University), Rammohan K. Ragade (Kentucky University), and several anonymous reviewers provided by Prentice Hall. Discussions with Greg Hislop (Drexel University), John Favaro ( lntecs Sisterni, Italy), Filippo Lanubile (Universita di Bari, Italy), John d' Ambra (University of New South Wales, Australia), Chuck H ow- ell (MITRE), Tim Yieregge (U.S. Army Computer Emergency Response Team) and James and Suzanne Robertson (Atlantic Systems Guild, UK) led to many improve- ments and enhancements.
Thanks to Toni Holm and Alan Apt, who made the third edition of the book's production interesting and relatively painless. Thanks, too, to James and Suzanne Robertson for tbe use of tbe Piccadilly example, and to Norman Fenton for the use of material from our software metrics book. We are grateful to Tracy Dunkelberger for encouraging us in producing this fourth edition; we appreciate both her patience and her professionalism. Thanks, too, to Jane Bonne ll! and Pavithra Jayapaul for seamless production.
Many thanks to the publishers of several of the figures and examples for granting permission to reproduce them here. The material from Complete Systems Analysis (Robertson and Robertson 1994) and Mastering the Requirements Process (Robertson and Robertson 1999) is drawn from and used with permission from Dorset House Pub- Lishing, at www.dorsethouse.com; au rights reserved. The article in Exercise 1.1 is repro- duced from the Washington Post with permission from the Associated Press. Figures 2.15 and 2.16 are reproduced from Barghouti et a l. (1995) by permission of John Wiley and Soos Limited. Figures 12.14 and 12.15 are reproduced from Rout (1995) by permis- sion of John Wiley and Sons Limited.
Figures and tables in Chapters 2, 3, 4, 5, 9, 11, 12, and 14 that are noted with an IEEE copyright are reprinted with permission of the Institute of Electrical and Elec- tronics Engineers. Similarly, the three tables in Chapter 14 that are noted with an ACM copyright are reprinted with permission of the Association of Computing Machinery. Table 2.1 and Figure 2.11 from Lai (1991) are reproduced with perrnis.sion from the Software Productivity Consortium. Figures 8.16 and 8.17 from Graham (1996a) are reprinte d with permission from Dorothy R. Graham. Figure 12.11 and Table 12.2 are adapted from Liebman (1994) with permis.sion from the Cente r for Science in the
Public Interest, 1875 Connecticut Avenue NW, Washington DC. Tables 8.2, 8.3, 8.5, and 8.6 are reproduced with permission of The McGraw-Hill Companies. Figures and examples from Shaw aod Garlan (1996), Card aod Glass (1990), Grady (1997), aod Lee and Tepfenhart (1997) are reproduced with permission from Prentice Hall.
Tables 9.3, 9.4, 9.6, 9.7, 13.1, 13.2, 13.3, and 13.4, as well as Figures 1.15, 9. 7. 9.8, 9.9, 9.14, 13.1, 13.2, 13.3, 13.4, 13.5, 13.6, and 13.7 are reproduced or adapted from Fenton and Ptleeger (1997) in whole or in part with permjssion from Norman Fenton. Figures 3.16, 5.19, and 5.20 are reproduced or adapted from Norman Fenton's course notes, with rus kind perntission.
We especially appreciate our employers, the RAND Corporation and the Univer- sity of Waterloo, respectively, for their encouragement.1 And we thank our friends and family, who offered their kfadness, support, and patience as the book-writing stole time orrunarily spent with them. In particular, Shari Lawrence Plleeger is grateful to Manny Lawrence, the manager of the real Royal Service Station , and to his …