Software engineering for real time systems jim cooling pdf

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-

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

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

The transcendental view is much like Plato's description of the ideal or Aristotle's con-

cept o f form. In other words, just as every actual table is an approximation of an ideal table,

we can think of software quality as an ideal toward which we strive; however, we may never

be able to implement it comple tely. The transcendental view is ethereal, in contrast to the more concrete view of the user.

We take a user view when we measure product characteristics, such as defect density or relia-

bility, in order to understand the overall product quality.

The ma nufacturing view looks at quality during production and after delivery. In partic-

ular, it examines whether the product was built right the first time, avoiding costly rework to

fix delivered faults. Thus, the manufacturing view is a process view, advocating conformance to good process. However, there is little evidence that conformance to process actually results

in products with fewer faults and failures; process may indeed lead to h igh-quality products,

but it may possibly institutionalize the production of mediocre products. We examine some of

these issues in Chapter 12.

The user and manufacturing views look at the product from the o utside, b ut the product

view peers inside and evaluates a product's inherent characte ristics. This view is the one oft.en

advocated by software metrics experts; they assume that good internal quality indicators will

lead to good external ones, such as reliability and maintainability. However, more research is

10 Chapter 1 Why Software Engineering?

needed to verify these assumptions and to determine which aspects of quality affect the prod-

uct's actual use. We may have to develop models that link the product view to the user view. Customers or marketers often take a user view of quality. Researchers sometimes hold a

product view, and the development team has a manufacturing view. if the differences in view-

points are not made explicit, then confusion and misunderstanding can lead to bad decisions and poor products. The value-based view can link these disparate pictures of quality. By

equating quality to what the customer is willing to pay, we can look at trade-offs between cost

and quality, and we can manage conflicts when they arise. Similarly, purchasers compare product costs with potential benefits, thinking of quality as value for money.

Kitchen.ham and Pfteeger (1996) investigated the answer to this question in their introduction to a special issue of IEEE Software on quaJity. They note that the context helps to de te rmine the answer. FauJts tolerated in word processing software may not be acceptable in safety-critical or mission-critical systems. Thus, we must consider quality in a t least three ways: the quality of the product, lhe quality of the process that resuJ t.s in the product, and the quality of the product in the context of the business environment in which the product wiU be used.

The Quality of the Product

We can ask people to name the characteristics of software that contribute to its overalJ quality, but we are likely to get different answers from each person we ask. Thjs differ- ence occurs because the importance of the characteristics depends on who is analyzing the software. Users judge software to be of high quality if it does what they want in a way that is easy to learn and easy to use. However , sometimes quality and functionality are inte rtwined; if some thing is hard to learn or use but its functionality is worth the trouble, then it is stiU considered to have high quality.

We try to measure software quality so that we can compare one product with another. To do so, we identify those aspects of the system that contribute to its overall quality. Thus, when measuring software quality, users assess such external characte ristics as the number of failures and type of failures. For example, they may define faiJures as minor, major, and catastrophic, and hope that any failures that occur are onJy minor ones.

The software must also be judged by those who are designing and writing the code and by those who must maintain the programs after they are written. These practi- tioners tend to look at internal characte ristics of the products, sometimes even before the product is delive red to the user. In particular , practitioners often look at numbers and types o f faults for evide nce of a product's quality (or lack of it) . For example, devel- opers track the number of faults found in requirements, design, and code inspections and use them as indicators of the like ly quaJity of the final product.

For this reason, we often build models to relate the user's exte rnal view to the developer's inte rnal view of the software. Figure 1.5 is an example of an early quality model built by McCaU and bis colleagues to show how external quality factors (on the left-hand side) re la te to product quality criteria (on the right-hand side). McCaU associ- ated each right-band criterion with a measurement to indicate the degree to which an

Section 1.3 What Is Good Software? 11

Correctneu

Rel iabilily

lnte rit

Usability

Mainhinabilily

Testabilitf

I nteropmbil itr

FIGURE 1.5 McCall's quality model.

e lement of quality was addressed (McCall, Richards, and Walte rs 1977). We will exam- ine several product quality models in Chapter 12.

The Quality of the Process

There are maoy activities that affect the ultimate product quality; if aoy of the activities go awry, tbe product quality may suffer. For this reason, many software engineers feel that the quality of the development and maintenance process is as important as prod- uct quality. One of the advantages of modeling the process is that we can examine it and look for ways to improve it. For example, we can ask questions such as:

• Where and when are we likely to find a particular kiod of fault? • How cao we fiod faults earlier in the development process?

• How can we build io fault tole rance so that we minimize the likeLihood that a fault wiU become a failure?

• How cao we design secure, high-quality systems? • Are there alternative activities that can make our process more effective or effi-

cient at ensuriog quality?

These questioos can be applied to the whole development process or to a subprocess, such as configuration management, reuse, or testing; we will investigate these processes in late r chapters.

In the 1990s, there was a well-publicized focus on process modeling and process improvement in software engineering. Inspired by the work of Deming and Juran, and implemented by companies such as IBM, process guidelines such as tbe Capability

12 Chapter 1 Why Software Engineering?

Maturity Mode l (CMM), ISO 9000, and Software Process Improvement and Capability dEte rmination (SPICE) suggested that by improving the software development process, we can improve the quality of the resulting products. In Chapter 2, we will see how to iden- tify relevant process activities and model their effects on intermediate and final products. Chapte rs 12 and 13 will examine process models an.d improvement frameworks in depth.

Quality in the Context of the Business Environment

When the focus of quality assessment is on products and processes, we usually measure quality with mathematical expressions involving faults, failures, and timing. Rarely is the scope broadened to include a business perspective, where qualjty is viewed in terms of the products and services being provided by the business in which the software is embedded. That is, we Look at the technical value of our products, rather than more broadly at their business value, and we make decisions based only on the resulting products' technical quality. In other words, we assume that improving technical quality will automaticaJly translate into business value.

SeveraJ researchers have taken a close look at the relationships between business value and technical value . For example, Simmons inte rviewed many Australian busi- nesses to de termine how they make their information technology-related business decisions. She proposes a framework for understanding what companies mean by "business vaJue" (Simmons 1996). In a report by Favaro and Pfteeger (1997), Steve Andrioie, chief information officer for Cigna Corporation, a large U.S. insurance com- pany, described how his company distinguishes technical value from business value:

We measure the quality [of our software] by the obvious metrics: up versus down time, maintenance costs, costs connected with modifications, and the like. In other words, we manage development based on operational performance within cost parameters. HOW the vendor provides cost-effective performance is less of a concern than the results of the effort. ... The issue of business versus technical value is near and dear to our heart ... and one [on] which we focus a great deal of attention. I guess I am surprised to learn that com- panies would contract with companies for their technical value, at the relative expense of business value. If anything, we err on the other side! If there is not clear (expected) busi- ness value (expressed quantitatively: number of claims processed, etc.) then we can't launch a systems project. We take very seriously the "purposeful" requirement phase of the project, when we ask: "why do we want this system?" and "why do we care?"

There have been several attempts to re late technical value and business value in a quantitative and meaningful way. For example, Humphrey, Snyder, and Willis (1991) note that by improving its development process according to the CMM "maturity" scale (to be discussed in Chapter 12), Hughes Aircraft improved its productivity by 4 to 1 and saved millions of dollars. Similarly, Dion (1993) reported that Raytheon's twofold increase in productivity was accompanied by a $7.70 re turn on every dollar invested in process improvement. And pe rsonne l at Tmker Air Force Base in Oklahoma noted a productivity improvement of 6.35 to 1 (Lipke and Butler 1992).

H owever, Brodman and Johnson (1995) took a closer look at the business value of process improvement. They surveyed 33 companies that performed some kind of process improvement activities, and examined several key issues. Among othe r things, Brodman

Section 1.3 What Is Good Software? 13

and Johnson asked companies how they defined return on investment (ROI), a concept that is clearly defined in the business community. They note that the textbook definition of return on investment, derived from the financial community, describes the investment in terms of what is given up for other purposes. That is, tbe "investment must not only return the original capital but enough more to at least equal what the funds would have earned elsewhere, plus an allowance for risk" (Putnam and Myers 1992). Usually, the business community uses one of three models to assess ROI: a payback model, an accounting rate-of-return model, and a discounted cash flow model.

However, Brodman and Johnson (1995) found that the U.S. government and U.S. industry interpret ROI in very different ways, each different from the other, and both dif- ferent from the standard business school approaches. The government views ROI in terms of dollars, looking at reducing operating costs, predicting do llJar savings, and calculating the cost of employing new technologies. Government investments are also expressed in dol- lars, such as the cost of introducing new technologies or process improvement initiatives.

On the other band, industry viewed investment in terms of effort, rather than cost or dollars. That is, companies were interested in saving time or using fewer people, and their definition of re turn on investment reflected this focus on decreasing effort. Among the companies surveyed , return on investment included such items as

• training • schedule

• risk • quality • productivity • process • customer • costs • business

"The cost issues included in the definition involve meeting cost predictions, improving cost performance, and staying within budget, rather than reducing operating costs or streamlining the project or organization. Figure 1.6 summarizes the frequency with which many organizations included an investment item in their definition of RO I. For example, about 5 percent of those interviewed included a quality group's effort in the ROI effort calculation, and approximately 35 percent included soflware costs when considering numbe r of dollars invested.

The difference in views is disturbing, because it means that calculations of ROI cannot be compared across organizations. But there are good reasons for these differ- ing views. Dollar savings from reduced schedule, higher quality, and increased produc- tivity are re turned to the government rather than the contractor. On the other hand, contractors are usuaUy looking for a competitive edge and increased work capacity as weU as greater profit; thus, the contractor's ROI is more effort- than cost-based. In par- ticular, more accurate cost and schedule estimation can mean customer satilsfaction and repeat business. And decreased time to market as well as improved product quality are perceived as offering business value, too.

14 Chapter 1

:! ...

Why Software Engineering?

Facilities E===~----------------1

Soltwue costs:

Har~ware costs J:=====:::I Materia ls

General _,_ _________ _

Assessments i----.. SCE costs

Internal R&D Process .,. _______ _.

Doeumantation1 Quality group'

Software process groupJ:=====::J

Genera I ~;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;~J

0% 10% 20% 30% 40% SO% 60% 70%

Percent of lnterwlewees

FIGURE 1.6 Terms included in industry definition of return on investment.

Even though the different ROI calculations can be justi fied for each organization, it is worrying that softwa re technology return on investment is not the same as financial ROI. At some point, program success must be reported to higher levels of manage- ment, many of which are related not to software but to the main company business, such as telecommunications or banking. Much confusion will result from the use of the same terminology to mean vastly different things.. Thus, our success criteria must make sense no t only for software projects and processes, but also for the more general busi- ness practices they support. We will examine this issue in more detail in Chapter 12 and look at using several common measures of business value to choose among technology options,.

1.4 WHO DOES SOFTWARE ENGINEERING?

A key component of software development is communication be tween customer and developer; if that fa ils, so too wiU the system. We must understand what the customer wants and needs before we can build a system to help solve the cus tomer 's problem. To do this, let us turn our attention to the people invo lved in soft ware development.

The number of people working on software development depends on the project's size and degree of difficulty. However, no matter how many people are involved , the roles played throughout the Life of the project can be distjnguished. Thus, for a large project, one person or a group may be assigned to each of the roles identi- fied; on a smaU project, o ne person or group may take on several ro les at once.

Usually, the participants in a project fall into one of three categories: customer, user, or developer. The customer is the company, organization, or person who is paying for the so fl ware system to be developed. The developer is the company, organizalioo, or person who is building tlhe software system for the customer. This category includes any

USER

Section 1.4 Who Does Software Engineering? 15

CUSTOMER Sponsors system development

Needs

Software system

FIGURE 1.7 Participants in software development.

managers needed to coordinate and guide the programme rs and testers. The user is the person or people who wiU actuaUy use the system: the ones who sit at the te rminal or submit the data or read the output. Although for some projects the customer, user, and developer are the same person or group, often these are different sets of people. Figure 1. 7 shows the basic relationships among the three types of participants.

The customer, being in control of the funds, usually negotiates the contract and signs the acceptance papers. However, sometimes the customer is not a user. For example, suppose Wittenberg Water Works signs a contract with Gentle Systems, Inc., to build a computerized accounting system for the company. The president of Witten- berg may describe to the representatives of Gentle Systems exactly what is needed, and she will sign the contract. However, the president wiU not use the accounting system directly; the users will be the bookkeepers and accounting c lerks. Thus, it is important that the developers understand exact! y what both the customer and users want and need.

On the otber band, suppose Wittenberg Water Works is so large that it bas its own computer systems development division. The division may decide that it ne:eds an auto- mated tool to keep track of its own project costs and schedules. By building the tool itself, the division is at the same time the user, customer, and developer.

In recent years, the simple distinctions among customer, user, and developer have become more complex. Customers and users have been involved in the development process in a variety of ways. The customer may decide to purchase Commercial Off-The- Sbelf (COTS) software to be incorporated in the final product that the developer will supply and support. When this happens, the customer is involved in system architecture decisions, and there are many more constraints on development. Similarly, tbe developer may choose to use additional developers, caUed subcontractors, who build a subsystem and deliver it to the developers to be included in the final product. The subcontractors may work side by side with the primary developers, or they may work al a di[ferent site,

16 Chapter 1 Why Software Engineering?

coordinating their work with the primary developers and delivering the subsystem late in the development process. The subsystem may be a t urnkey system, where the code is incorporated whole (without additional code for integration), or it may require a sepa- rate integration process for building the links from tbe major system to the subsystem(s).

Thus, the notion of ·•system" is important in software engineering, not onJy for understanding the problem analysis and solution synthesis, but also for organizing the development process and for assigning appropria tte roles to the participants. In the next section, we look at the role of a systems approach :in good software engineering practice.

1.5 A SYSTEMS APPROACH

The projects we develop do not exist in a vacuum .. Often, the hardware and software we put together must interact with users, with o ther software tasks, with other pieces of hardware, with existing databases (i.e., with carefully defined sets of data and data re la- tionships), o r even with o the r computer systems. Therefore, it is important to provide a context for any project by knowing the boundaries of the project: what is included in the project and what is not. For example, suppose you a re asked by your supervisor to write a program to print paychecks for the people in your office. You must know whether your program simply reads hours worked from another system and prints the results or whe the r you must also calculate the pay information. SimiJarly, you must know whe ther the program is to ca lcuJate taxes, pensions, and be nefits or whether a report of these items is to be provided with each paycheck. What you are really asking is: Where does the project begin and end? The same question applies to any system. A system is a collection of objects and activities, plus a description of the relationships that tie the objects and activities together. Typically, our system de finition includes, for each activity, a list of inputs required, actions taken, and outputs produced. Thus, to begin, we must know whether any object or activity is included in the system or not.

The Elements of a System

We describe a system by naming its parts and then identifying how the component parts are related to one anothe r. This identification is the first step in analyzing the problem presented to us.

Activities and O bjects. First, we distinguis h between activities and objects. An activity is something tha t happens in a system. Usually described as an event initiated by a trigger, the activity transforms one thing to anothe r by chang i-ng a characteristic. This transformation can mean that a data e lement is moved from one location to another , is changed from one value to another, or is combined with o ther data to supply input for yet another activity. For example, an item of data can be moved from one file to another. In this case, tbe characteristic changed is the location. Or the value of the data ite m can be incremented. Finally, the address of the data item can be included in a list of parameters with the addresses of several o ther data items so that another routine can be caUed to handle a ll the data at once.

The e lements involved in the activities a re caUed objects or entities. Usually, these objects are re lated to each o the r in some way. For instance, the objects can be

Section 1.5 A Systems Approach 17

arranged in a table or matrix. Often, objects are grouped as records, wbere each record is arranged in a prescribed format. An employee history record, for example, may con- tain objects (called fields) for each employee, such as the following:

First name Middle name Last name Street address City State

Postal code SaJary per hour Benefits per hour Vacation hours accrued Sick leave accmed

Not only is each fie ld in the record defined, but the size and rela tionsltip o f each fie ld to the others are named. Thus, the record description states the data type of each fie ld, the starting location in the record, and the length of the field. In turn, since there is a record for each employee, the records a re combined into a file, and file characteris tics (such as maximum number o f records) may be specified.

Sometimes, the objects are defined slightly differently. Instead of considering each item as a fie ld in a larger record, the object is viewed as being independent. The object description contains a Listing of the characteristics of each object, as well as a list of au the actions that can take place using the object or affecting the object. For example, consider the object "polygon." An o bject description may say that this object bas characteristics such as number of sides and length of each side. The actions may include calcula tion of the area or of the perimeter. There may even be a characteristic called "polygon. type,'' so that each instantiation of ·'polygon" is identified! when it is a "rhombus" or "rectangle," for instance. A type may itself have an object description; "rectangle" may be composed of types "square" and "not square," for example. We will explore these concepts in Chapter 4 when we investigate requirements ana lysis, and in depth in Chapte r 6 when we discuss object-oriented development.

Relationships and the System Boundary. Once entities and activities are defined, we match the entities with their activities. The relationships among entities and activi- ties are clearly and carefully defined. An entity definition includes a description of where the entity originates. Some items reside in files that already exist; others are cre- a ted during some activity. The entity's destination is important, too. Some items are used by only one activity, but ot!hers are destined to be input to other systems. That is, some items from one system are used by activities outside the scope of the system being examined. Thus, we can think of the system at which we are looking as having a border or boundary. Some items cross the boundary to enter our system, and others are prod- ucts of our syste m and travel out for another system's use.

Using these concepts, we can define a system as a collection of things: a set of entities, a set of activities, a description of il:he relationships among entities and activities, and a def- inition of the boundary of the system. This definition of a system applies not only to com- puter systems but to anything in which objects interact in some way with other objects.

Examples of Systems. To see how system definition works, consider the parts of you that a llow you to take in oxygen and excrete carbon dioxide and water: yoru respi- ratory system. You can define its boundary easily: If you name a particular organ of

18 Chapter 1 Why Software Engineering?

FIGURE 1.8 Respiratory system.

ENTITIES: Particulate matter Oxygen Carbon dioxide Water Nitrogen Nose Mouth Trachea Bronchial tubes Lungs Alveoli

ACTIVITIES: Inhale ,ans Filter gases T ransler molecules

to/from bl ocd Exhale ,ans

your body, you can say whether or not it is part of your respiratory system. Molecules of oxygen and carbon dioxide are entities or objects moving through the system in ways that are clearly defined. We can also describe the activities in the system in terms of the inte ractions of the entities. If necessary, we can imustrate the syste m by showing what enters and leaves it; we can also supply tables to describe all entities and the activities in which they are involved. Figure 1.8 illustrates the respiratory system. Note that each activity involves the entities and can be defined by describing whjch entities ac t as input, how they are processed, and what is produced (output).

We must describe our computer systems clearly, too. We work with prospective users to define the boundary of the system: Where does our work start and stop? In addition, we need to know what is on the boundary of the system and thus determine the origins of the input and destinations of the output. For example, in a system that prints paychecks, pay information may come from the company's payroll system. The system output may be a set of paychecks sent to the mail room to be delivered to the appropriate recipients. In the system shown in Figure 1.9, we can see the boundary and can understand the entities, the activities, and their relationships.

Interrelated Systems

The concept of boundary is important, because very few systems are independent of other systems. For example, the respiratory system must interact with the digestive sys- tem, the circulatory syste m, the nervous system, and others. The respiratory system could not function witbout the nervous system; neither could the circulatory system function without the respiratory system. The interdependencies may be complex. (Indeed, many of our environmental problems arise and are intensified because we do not appreciate the complexity of our ecosystem.) However, once the boundary of a system is described, it is easier for us to see what is within and without and what crosses the boundary.

In turn, it is possible for one system to exist inside anothe r system. When we describe a computer system, we often concentrate on a small piece of what is really a

l[I I ~ Computer i~ ~

D1te ulidation

~ System bound1ry

Section 1.5

M•H•u•ijJ

~ Printin9

A Systems Approach 19

FIGURE 1.9 System definition of paycheck production.

much larger system. Such a focus allows us to define and build a much less complex sys- tem than the enveloping one. If we a re careful in documenting the interactions among and be tween systems affecting ours, we lose nothing by concentrating on this sma ller piece of a larger system.

Let us look at an example of bow this can be done. Suppose we are developing a water-monito ring system where data are gathe red at many points through.out a river val- ley. At the collection sites, several calculations are done, and the results are communicated to a central location for comprehensive reporting. Such a system may be implemented with a computer at the central site communicating with several dozen smalle r computers at the remote locations. Many system activities must be considered, including the way the water data a re gathered, the calculations perfo rmed at the remote locations,. the commu- nication of information to the central site, the storage of the communicated data in a data- base or shared data file, and the creation of reports from the data. We can view this system as a coUection of systems, each with a special purpose. In particula r, we can conside r only the communications aspect of the larger system and develop a communications system to transmit data from a set of remote sites to a central one. If we care fully define the bound- ary between the communications and the larger system, the design and development of the communications system can be done independently of the larger system.

The complexity of the entire water-monitoring system is much greate r than the com- plexity of the communications system, so our treatment of separate, smalle r pieces makes our job much simple r. If the boundary definitions are detailed and correct, building the larger system from the smaller ones is relatively easy. We can describe the building pro- cess by considering the larger system in layers, as illustrated in Figure 1.10 fo r our water- monito ring example. A layer is a system by itself, but each layer and those it contains also form a system. The circles of the figure represent the boundaries of the respective systems, and the entire set of circles incorporates the entire water-monito ring system.

20 Chapter 1 Why Software Engineering?

FIG URE 1.1 O Layers of a water-monitoring system.

Recognizing that one system contains another is important, because it reflects the fact that an object or activity in one system is part of every system represented by the oute r layers. Since more complexity is introduced witb each layer, understanding any one object or activity becomes more difficult with each more encompassing system. Thus, we maximize simplicity and our consequent understanding of the system by focusing on tbe smallest system possible at first.