Cmpe 131

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

ISBN-13: 978-0-13-606169-4

lSBN-10: 0.13-606169-9

"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.

S.L.P.

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.

Pref ace

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

xiii

xiv Preface

knowledge of the subject. Io particular, Chapters 12, 13, and 14 present thought- provoking material designed to interest graduate students in current research topics.

KEY FEATURES.

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.

Preface xv

• 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

xvi Preface

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

Preface xvii

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

Preface xix

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.

ACKNOWLEDGMENTS

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

xx Preface

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

Preface xxi

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 bookkeepe r, Bea Lawrence, not only for working with her and her students on the specification of the Royal system, but a lso for their affection and guidance in their other job: as her parents. Jo Atlee gives special thanks to her parents, Nancy and Gary Atlee, who have sup- ported and encouraged her in everytlting she bas done (and attempted); and to her col- leagues and students, who graciously took on more than their share of work during the major writing periods. And, most especially, we thank Charles Pfteeger andl Ken Salem, who were constant and much-appreciated sources of suppo rt, encouragement, and good humor.

Shari Lawre nce Ptleeger Joartne M. AtJee

1Please note tbat tbis book is not a product of the RAND Corporation and bas not undergone RAND's quality assurance process. The work represents us as authors, not as employees of our respective institutions.

About the Authors

Shari Lawrence POeeger (Ph.D., Information Technology and Engineering, George Mason University; M.S., Planning, Pennsylvania State University; M.A., Mathematics, Pennsylvania State University; B.A., Mathematics, Harpur College) is a seniior info rma- tion scientist at the RAND Corporation. Her current research focuses on policy and decision-making issues that help organizations and government agencies understand whether and how information technology supports their missions and goals. Her work at RAND has involved assisting cLients in creating software measurement programs, supporting gove rnment agencies in defining information assurance po Licies, and sup- porting decisions about cyber security and homeland security.

Prior to joining RAND, she was the president of Systems/Software, Ille., a consul- tancy specializing in software engineering and technology. She bas been a visiting pro- fessor at City University (London) and the University of Maryland a nd was the founder and director of Howard University's Center for Research in Evaluating Soft- ware Technology. The author of many textbooks on software engineering and computer security, Pfleeger is we lJ known for her work in empirical studies of softwa re engineer- ing and for her muJtjdiscipLinary approach to solving information technology problems. She has been associate editor-in-chief of IEEE Software, associa te editor of IEEE Transactions on Soflware Engineering, associate editor of IEEE Security and Privacy, and a member of the IEEE Computer Society Technical Council on Software Engi- neering. A frequent speaker at conferences and workshops, Pfleeger has been named repeatedly by the Journal of Systems and Software as one of the world's top software engineering researchers.

Joanne M. Atlee (Ph.D. and M.S., Computer Science, University of Maryland; B.S., Computer Science and Physics, ColJege of WilJiam and Mary; P.Eng.) is an Associate Professor in the School of Computer Science at the University of Wa terloo. Her research focuses on software modeling, documentation, and analysis. She is best known for her work on model checking software requirements specifications. Other research interests include model-based software engineering, modular software development, feature interactions, and cost-benefit analysis of formal software development tech- niques. Atlee serves on the editorial boards for IEEE Transactions on Software Engi- neering, Software and Systems Modeling, and the Requi.rements Engineering Journal and is Vice Chair of the International Federation for Information Processing (IFIP) Working G roup 2.9, an inte rnational group of researchers. working on advances in soft- ware requirements engineering. She is Program Co-Chair for the 31st International Conference on Software Engineering (ICSE'09).

Atlee also has strong inte rests in software engineering education. She was the founding Director o f Water loo's Bachelor's program in Software Engineering. She

xx iii

xxiv About the Authors

served as a member of the Steering Committee for the ACMJIBEE-CS Computing Curricula-Software Engineering (CCSE) volwne, wh.ich provides curricular guide- lines for undergraduate programs in software engineering. She also served on a Cana- dian Engineering Q ualifications Board committee whose mandate is to set a software engineering syllabus, to offer guidance to provincial engineering associations on what constitutes acceptable academic quaLifications for Licensed Professional Engineers who practice software engineering.

SOFTWARE ENGINEERING

1

In this chapter, we look at • what we mean by software

engineering • software engineering's track record • what we mean by good software • why a systems approach is important • how software engineering has

changed since the 1970s

Software pervades our world, and we sometimes take for granted its role in making our Lives more comfortable, efficient, and effective. For example, consider the simple tasks involved in preparing toast for breakfast. The code in the toaste r controls how brown the bread wiU get and when the finished product pops up. Programs control and regu- late the delivery of electricity to the house, and software biUs us for our energy usage. In fact, we may use automated programs to pay the electricity bill, to orde r more gro- ceries, and even to buy a new toaste r! Today, softwar e is working both explicitly and behind the scenes in virtua lly all aspects of our Jives, including the critical systems that affect our health and well-being. For this reason, software engineering is more impor- tant than ever. Good software engineering practices must ensure that software makes a positive contribution to bow we lead our Lives.

This book highlights the key issues in software engineering, describing what we know about techniques and tools, and how they affect the resulting products we build and use. We will look at both theory and practice: what we know and how it is applied in a typical software development or maintenance project. We will also examine what we do not yet know, but what would be helpful in making our products more re liable, safe, useful, and accessible.

We begin by looking at bow we analyze problems and develop solutio ns. Then we investigate the differences between computer science problems and engineering ones. Our ultimate goal is to produce solutions incorporating high-quality software, and we consider characteristics that contribute to the quality.

2 Chapter 1 Why Software Engineering?

We also look at how successful we have been as developers of software systems. By examining several examples of software fa ilure, we see how far we have come and how much farther we must go in mastering the art of quality software development.

Next, we look at the people involved in software development. After describing tbe roles and responsibilities of customers, users, and developers, we turn to a study of the system itself. We see that a system can be viewed as a group of objects related to a set of activities and enclosed by a boundary. Alternatively, we look at a system with an engineer's eye; a system can be developed much as a house is built. Having defined the steps in building a system, we discuss the roles of the development team at each step.

Finally, we discuss some of the changes that have affected the way we practice software engineering. We present Wasserman's eight ideas to tie together our practices into a coherent whole.

1.1 WHATIS SOFTWARE ENGINEERING?

As software engineers, we use our knowledge of computers and computing to belp solve problems. Often the problem with which we are dealing is re lated to a computer or an existing computer system, but sometimes tbe difficulties underlying the problem have no thing to do with computers. Therefore, it is essential that we first understand the nature of the problem. [n particular, we must be very careful not to impose computing machinery or techniques on every problem that comes our way. We must solve the problem first. Then, if need be, we can use techno logy as a tool to implement our solu- tion. For the remainder o f this book, we assume that our analysis has shown that some kind of computer system is necessary or desirable Ito solve a particular problem at hand.

Solving Problems

Most problems are large and sometimes tricky to handle, especiaUy if they represent something new that bas never been solved before. So we must begin investigating a problem by analyzing it, that is, by breaking it into pieces that we can understand and try to deal with. We can thus describe the larger problem as a coUection of small prob- lems and their interrelationships. Figure 1.1 iUustrates how analysis works. It is impor- tant to remember that the relationships (the arrows in the figure, and the relative positions of the subproblems) are as essentia l as the subproblems themselves. Some- times, it is the relationships that hold the clue to how to solve the larger problem, rather than simply the nature of the subproblems.

Once we have anal yzed the problem, we mu.st construct our solution from compo- nents that address the problem's various aspects. Figure 1.2 illustra tes th.is reverse pro- cess: Synthesis is the putting together of a large structure from small building blocks. As with analysis, the compositio n of the individual solutions may be as challenging as the process. of finding the solutions. To see why, consider the process of writing a novel. The dictionary contains all the words that you might want to use in your writing. But the most di.fficult part of writing is deciding how to organize and compose the words into sentences, and likewise the sentences into paragraphs and chapters to form the complete book. Thus, any problem-solving technique must have two parts: analyzing the problem to dete rmine its nature, and then synthesizing a solution based on o ur analysis.

Section 1.1 What Is Software Engineering? 3

PROBLEM

Q

.__________.I D I

~--~II I Q

Subproblem 4 Subproblem 1 Subproblem 2 I~~.-~

~--~~----~11~~-~-~-~~31~~~~ FIGURE 1.1 The process of analysis.

11

Solution 4

~S-olu-tion_i_~~S-olu-tio-n2---~~-~~~~~~ _ . _ II Solution 31_

Q .-----------.I D

I II I

Q SOLUTION

FIGURE 1.2 The process of synthesis.

4 Chapter 1 Why Software Engineering?

To help us solve a problem, we employ a variety of methods, tools, procedures, and paradigms. A method or technique is a formal procedure for producing some result. For example, a chef may prepare a sauce using a sequence of ingredients com- bined in a carefully timed and ordered way so that the sauce thicke ns but does not cur- dle or separate. The procedure for preparing the sauce involves timing and ingredients but may not depend on the type of cooking equipment used.

A tool is an instrument or automated system for accomplishing something in a bette r way. This "better way" can mean that the tool makes us more accurate, more e ffi- cient, o r more productive or that it enhances the quality of the resulting product. For example, we use a typewriter or a keyboard and printer to write letters because the resulting documents are easier to read than our handwriting. Or we use a pair of scis- sors as a tool because we can cut faster and stra£gbter than if we were tearing a page. However, a tool is not always necessary for making something well. For example, a cooking technique can make a sauce better, not tbe pot or spoon used by the chef.

A procedure is IJke a recipe: a combination of tools and techniques tbat, in con- cert, produce a particular product. Fo r instance, as we wiU see in later chapters, our test plans describe our test procedures; they tell us which tools will be used on which data sets under which circumstances so we can determine whether our software meets its requirements.

FinaUy, a paradigm is like a cooking style; it represents a particular approach or philosophy for building software. Just as we can distinguish French cooking from Chi- nese cooking, so too do we distinguish paradigms IJke object-oriented development from procedural ones. One is not better than ano ther; each has its advantages and dis- advantages, and there may be situations when one is more appropriate than another.

Software engineers use tools, techniques, procedures, and paradigms to enhance the qua lJty of their software products. Their aim is to use efficient and productive approaches to generate effective solutions to problems. In the chapters that follow, we wiU highlight particular approaches that support the development and mainte nance activities we describe. An up-to-date set of pointe rs to tools and techniques is listed in this book's associated home page on the World Wide Web.

Where Does the Software Engineer Fit In?

To understand how a software engineer fits into tlile computer science wo rld, let us look to another discipline for an example. Consider the study of chemistry and its use to solve problems. The chemist investigates chemicals: their structure, their interactions, and the theory behind their behavior. Chemical engineers apply the results of the chemist 's studies to a var iety of problems. Chemistry as viewed by chemists is the object o f study. On the other h and, for a chemical engineer, chemistry is a tool to be used to address a general problem (which may not even be "chemical" in nature).

We can view computing in a similar light. We can concentrate on the computers and programming languages, or we can view them as tools to be used in designing and implementing a solution to a problem. So ftware engineering takes the latter view, as shown in Figure 1.3. Instead of investigating hardware design or proving theorems about how algoritluns wo rk, a software engineer focuses on the computer as a pro blem- solving tool. We will see la ter in this chapter that a software engineer works with the

COMPUTER SCIENCE

ENGINEERING

Tools and Tec~niques to Sol~e Problem

Section 1.2

CUSTOMER

Problem

How Successful Have We Been? 5

FIGURE 1.3 The relationship be tween computer science and software engineering.

functions of a computer as part of a general solution, rather than with the structure or theory o f the computer ~tse lf.

1.2 HOW SUCCESSFUL HAVE WE BEEN?

Writing software is an art as well as a science, and it is important for you as a student of computer science to understand why. Computer scientists and software engineering researchers study computer mechanisms and theorize about how to make them more product ive or efficient. However, they also design computer systems and write pro- grams lo perform tasks on those systems, a practice that involves a great deal of art, ingenuity, and skill. There may be many ways to perform a particular task on a particu- lar system, but some are better than others. One way may be more efficient, more pre- cise, easier to modify, easier to use, o r easier to understand. Any hacker can write code to make something work, but it takes the skill and understanding o f a professional soft- ware engineer to prodll!ce code that is robust, easy to understand and maintain, and does its job in the most efficient and effective way possible. Consequently, software engineering is about des.igning and developing high-quality software.

Be fore we examine what is needed to produce quality software systems, let us look back to see how success:ful we have been. Are users happy with their existing software systems? Yes and no. Software has enabled us to perform tasks more quickly and effec- tively !Jl.an ever before. Consider life before word processing, spreadsheets, electronic mail, or sophisticated telephony, for example. And software has supported life-sustaining or Life-saving advances in medicine, agriculture, transportation, and most other indus- tries. In addition, software has enabled us to do things that were never imagined in the past: microsurgery, multimedia education, robotics, and more.

6 Chapter 1 Why Software Engineering?

However, software is not without its problems. Often systems function , but not exactly as expected. We all have heard stories of systems that just barely work. And we aU have written faulty programs: code that contains mistakes, but is good enough for a passing grade or for demonstrating tbe feasibility of an approach. Clearly, sucb behav- ior is not acceptable when developing a system for delivery to a customer.

There is an enormous difference between an error in a class project and one in a large software system. In fact, software faults and the difficulty in producing fault-free software are frequently discussed in tbe literature and in the hallways. Some faults are merely annoying; others cost a great deal of time and money. Still others are ltife- tbreatening. Sidebar 1.1 explains the re lationships among faults, e rrors, and failures. Let us look at a few examples of fai lures to see wbat is going wrong and why.

SIDEBAR 1.1 TERMINOLOGY FOR DESCRIBING BUGS

Often, we talk about "bugs" in software, meaning many things that depend on the context. A "bug" can be a mistake in interpreting a requirement, a syntax error in a piece of code, o r the (as-yet-Wlknown) cause of a system crash. The Institute of Electrical and Electronics

Engineers (IEEE) has suggested a standard terminology (in IEEE Standard 729) for describ- ing "bugs" in our software products (IEEE 1983).

A fault occurs when a human makes a mistake, called an error, in performing some soft-

ware activity. For example, a designer may misWlderstand a requirement and create a design that does not match the actual intent of the requirements analyst and the user. This de.~ign fa1Ult

is an encoding of the error, and it can lead to other fallllts, such as incorrect code and an incor-

rect description in a user manual. Thus, a single error can generate many faults, and a fault can reside in any development or maintenance product.

A failure is a departure from the system's required behavior. It can be discovered before or after system delivery, during testing, or during operation and maintenance. As we will see

in Chapter 4, the requirements documents can contain faults. So a failure may indicate that

the system is not performing as required, even though it may be performing as specified

Thus, a fault is an inside view of the system, as seen by the eyes of the developers, whereas a failure is an outside view: a problem that the user sees. Not ev,ery fault corresponds

to a failure; for example, if faulty code is never executed or a particular state is never ente red, then the fault will never cause the code to fail. Figure 1.4 shows the genesis of a failure.

..... 15' ..... ?I ean lead to ean lead lo • • human error fault failure

FIGURE 1.4 How human error causes a failure.

Section 1.2 How Successful Have We Been? 7

Io the early 1980s, the United States Internal Revenue Service (IRS) hired Sperry Corporation to build an automated federal income tax form processing system. Accord- ing to the Wash ington Post, the "system . . . proved inadequate to the workload, cost nearly twice what was expected and must be replaced soon" (Sawyer 1985). lo 1985, an extra $90 million was needed to enhance the original $103 million worth of Sperry equip- ment. In addition , because tbe problem prevented the IRS from re turning refunds to tax- payers by tbe deadline, the IRS was forced to pay $40.2 million in inte rest and $22.3 million in overtime wages for its employees who were trying to catch up. In 1996, the situ- a tion had not improved. The Los Angeles Times reported on March 29 that there was stiU no master plan for the modernization of IRS computers,onJy a 6000-page technical docu- ment. Congressman Jim Lightfoot called tbe project "a $4-billion fiasco that is flounder- ing because of inadequate planning" (Yartabedian 1996).

Situations such as these still occur. In the United States, the Federal Bureau of Investigation's (FBI's) Trilogy project attempted to upgrade the FBI's computer systems. The results were devastating: "Afte r more than four years o f hard work and half a billion dollars spent, however, Trilogy has had little impact on the FBI's antiquated case-man- agement system, which today remains a morass of mainframe green screens and vast stores of paper records" (Knorr 2005). Similarly, in the United Kingdom, the cost of over- hauling the National Health Service's information systems was double tbe o riginal esti- mate (Ballard 2006). We will see in Chapter 2 why project planning is essential to the production of quality software.

For many years, the public accepted tbe infusion of software in their daily lives with little question. But President Reagan's proposed Strategic Defense Initiative (SDI) heightene d the public's awareness of the di[flculty of producing a fau lt-rree soft- ware system. Popular newspape r and magazine reports (such as Jacky 1985; Parnas 1985, Rensburger 1985) expressed skepticism in the computer science community. And now, years la te r, when the U.S. Congress is asked to allocate funds to build a simila r sys- tem, many computer scientists and software engineers continue to believe there is no way to write and test the software to guarantee adequate reliability.

For example, many software engineers think that an anliballis lic-rnis.sile system would require at least 10 milLion Lines of code; some estimates range as high as one hun- dred million. By comparison, the software supporting the American space shuttle consists of 3 million lines of code, including computers on the ground controlling the launch and the flight; there we re 100,000 lines of code in the shuttle itself in 1985 (Rensburger 1985). Thus, an antimissile software system would require the testing of an enormol!lS amount of code. Moreover , the reliability constraints would be impossible to test. To s.ee why, con- sider the notion of safety-critical software. Typically, we say that something that is safety- critical (i.e., something whose failure poses a threat to life or health) should have a reliabi(jty of at least 10-9. As we shall see in Chapter 9, this terminology means that the system can fail no more often than once in 109 hours of operation. To observe this degree of reLiability, we would have to run the system for at least 109 hours to verify that it does not fail. But 109 hours is over 114,000 years-far too long as a testing interval!

We will also see in Chapter 9 that helpful technology can become deadly when software is improperly designed or programmed. For example, the medical community was aghast when the Therac-25, a radiation therapy and X-ray machine, malfunctioned and killed several patients. The software designers bad not anticipated the use of several

8 Chapter 1 Why Software Engineering?

arrow keys in nonstandard ways; as a consequence, the software retained its high set- tings and issued a highly concentrated dose of radiation when low levels were intended (Leveson and Turner 1993).

Similar examples of unanticipated use and its dangerous consequences are easy to find. Fo r example, recent efforts to use off-the-she lf components (as a cost savings mea- sure instead of custom-crafting of software) result in designs that use components in ways not intended by the original developers. Many licensing agreements explicitly point to the risks of unanticipated use: "Because each end-user syste m is customized and differs from utilized testing platforms and because a user or application designer may use the software in combination with other products in a manner not evaluated or con- templated by [the vendor] or its suppliers, the user or application designer is ultimately responsible for verifying and validating the [software]" (Lookout Direct n.d.).

Unanticipated use of the system should be considered throughout software design activities. These uses can be handled in at least two ways: by stretching your imagination to think of how the system can be abused (as well as used properly), and by assuming that the system will be abused and d!esigning the software to handle the abuses. We discuss these approaches in Chapter 8.

Although many vendors strive for zero-defect software, in fact most software products are not fault-free. Market forces encoruage software developers to detiver products quickly, with lilttle time to test thoroughly. Typically, the test team will be able to test only those functions most likely to be used, or those tha t are most like ly to endanger or irritate users. For this reason, many users are wary of installing the first version of code, knowing that the bugs will not be worked out until the second version. Furthermore, the modifications needed to fix known faults are sometimes so difficuat. to make that it is easier to rewrite a whole system than to change existing code. We will investigate the issues involved in software maintenance in Chapter 11.

In spite of some spectacular successes and the overall acceptance of software as a fact of life, there is still much room for improvement in the quality of the software we produce. For example, lack of quality can be costly; the longer a fault goes undetected, the more expensive it is to correct. In particular, the cost of correcting an error made during the initial analysis of a project is estimated to be only one-tenth the cost of cor- recting a similar error after the system has been turned over to the customer. Unfo rtu- nately, we do not catch most of tbe errors early on. Half of the cost of correcting faults found during testing and maintenance comes l:rom errors made much earlier in the life of a system. In Chapters 12 and 13, we will look at ways to evaluate the effectiveness of our development activities and improve the processes to catch mistakes as early as possible.

One of tbe simple but powerfuJ techniques we will propose is the use of review and inspection. Many students are accustomed to developing and testing software on their own. But their testing may be less effective than tbey think. For example, Fagan studied the way faults were detected. He discovered that testing a program by running it with test data revealed only a bout a fifth of the faults located during systems develop- ment. However, peer review, the process whereby coUeagues examine and comment on each other's designs and code, uncovered the remaining four out of five faults found (Fagan 1986). Thus, the ,quality of your software can be increased dramatically just by having your coUeagues review your work. We will learn more in later chapters about how the review and insp ection processes can be· used after each major development

Section 1.3 What Is Good Software? 9

step to find and fix faults as early as possible. And we wiU see in Chapter 13 how to improve the inspection process itself.

1.3 WHAT IS GOOD SOFTWARE?

Just as manufacturers look for ways to ensure the quality of the products they produce, so too must software engineers find methods to ensure that their products are of acceptable quality and utility. Thus, good software engineering must always include a strategy for pro- ducing quality software. But before we can devise a strategy, we must understand what we mean by quality software. Sidebar 1.2 shows us how perspective inftuences what we mean by "quality." In this section, we examine what distinguishes good software from bad.

SIDEBAR 1.2 PERSPECTIVES ON QUALITY

G all'Vin (1984) discusses about how different people perceive quality. He describes quality from five different perspectives: • the transcendental view, whe re quality is something we can recognize but not d efine

• the user view, whe re quality is fitness for purpose

• the manufacturing view, whe re quality is conformance to specification

• the product view, where q uality is tied to inhe rent product characteristics

• the value-based view, where quality depends o n the amount the customer is willing to pay for it