1.Software EngineeringA PRACTITIONERS APPROACH

2. McGraw-Hill Series in Computer ScienceSenior Consulting EditorNetworks, Parallel andPressman, SoftwareC. L. Liu, National Tsing Hua Distributed Computing Engineering: A BeginnersUniversityGraphics and VisualizationGuide, 1/eThe MIT Electrical andPressman, SoftwareConsulting Editor Computer Science Series Engineering: A PractionersAllen B. Tucker, BowdoinGuide, 5/eCollege Software Engineering andRamakrishnan/Gehrke,Databases Database ManagementFundamentals of Computing Atzeni, Ceri, Paraborschi,Systems, 2/eand Programming and Torlone,Schach, Classical and Object-Computer Organization and Database Systems, 1/e Oriented SoftwareArchitectureMitchell, Machine Engineering with UMLSystems and Languages Learning, 1/e and C++, 4/eTheoretical Foundations Musa, Iannino,Schach, Classical and Object-Software Engineering andand Okumoto,Oriented SoftwareDatabases Software Reliability, 1/e Engineering with UML andArticial IntelligenceJava, 1/e 3. Software EngineeringA PRACTITIONERS APPROACHFIFTH EDITION Roger S. Pressman, Ph.D.Boston Burr Ridge, IL Dubuque, IA Madison, WINew York San Francisco St. Louis Bangkok Bogot Caracas Lisbon London Madrid Mexico City Milan New Delhi Seoul Singapore Sydney Taipei Toronto 4. McGraw-Hill Higher Education A Division of The McGraw-Hill CompaniesSOFTWARE ENGINEERINGPublished by McGraw-Hill, an imprint of The McGraw-Hill Companies, Inc. 1221 Avenue of theAmericas, New York, NY, 10020. Copyright/2001, 1997, 1992, 1987, 1982, by The McGraw-Hill Com-panies, Inc. All rights reserved. No part of this publication may be reproduced or distributed in anyform or by any means, or stored in a database or retrieval system, without the prior written consentof The McGraw-Hill Companies, Inc., including, but not limited to, in any network or other electronicstorage or transmission, or broadcast for distance learning.This book is printed on acid-free paper.1 2 3 4 5 6 7 8 9 0 DOC/DOC 0 9 8 7 6 5 4 3 2 1 0ISBN 0073655783Publisher: Thomas CassonExecutive editor: Betsy JonesDevelopmental editor: Emily GrayMarketing manager: John WannemacherProject manager: Karen J. NelsonProduction supervisor: Heather BurbridgeCoordinator freelance design: Keith McPhersonSupplement coordinator: Rose RangeNew media: Christopher StylesCover design: Rhiannon ErwinCover illustrator: Joseph GiliansCompositor: Carlisle Communications, Ltd.Typeface: 8.5/13.5 LeawoodPrinter: R. R. Donnelley & Sons CompanyLibrary of Congress Cataloging-in-Publication DataPressman, Roger S. Software engineering: a practitioners approach / Roger S. Pressman.5th ed. p. cm. (McGraw-Hill series in computer science) Includes index. ISBN 0-07-365578-3 1. Software engineering. I. Title. II. Series.QA76.758.P75 2001005.1dc2100-036133http://www.mhhe.com 5. To my parents 6. ABOUT THE AUTHOR Roger S. Pressman is an internationally recognized authority in software processimprovement and software engineering technologies. For over three decades, he has worked as a software engineer, a manager, a professor, an author, and a consultant, focus- ing on software engineering issues.As an industry practitioner and manager, Dr. Pressman worked on the development of CAD/CAM systems for advanced engineering and manufacturing applications. He has also held positions with responsibility for scientic and systems programming.After receiving a Ph.D. in engineering from the University of Connecticut, Dr. Pressman moved to academia where he became Bullard Associate Professor of Computer Engineering at the University of Bridgeport and director of the universitys Computer-Aided Design and Manufacturing Center.Dr. Pressman is currently president of R.S. Pressman & Associates, Inc., a consulting rm specializing in software engineering methods and training. He serves as principle con- sultant, helping companies establish effective software engineering practices. He also designed and developed the companys software engineering training and process improve- ment productsEssential Software Engineering, a complete video curriculum that is among the industrys most comprehensive treatments of the subject, and Process Advisor, a self- directed system for software engineering process improvement. Both products are used by hundreds of companies worldwide.Dr. Pressman has written many technical papers, is a regular contributor to industry periodicals, and is author of six books. In addition to Software Engineering: A Practitioners Approach, he has written A Managers Guide to Software Engineering (McGraw-Hill), an award-winning book that uses a unique Q&A format to present management guidelines for instituting and understanding software engineering technology; Making Software Engi- neering Happen (Prentice-Hall), the rst book to address the critical management problems associated with software process improvement; and Software Shock (Dorset House), a treat- ment that focuses on software and its impact on business and society. Dr. Pressman is on the Editorial Boards of IEEE Software and the Cutter IT Journal, and for many years, was editor of the Manager column in IEEE Software.Dr. Pressman is a well-known speaker, keynoting a number of major industry confer- ences. He has presented tutorials at the International Conference on Software Engineer- ing and at many other industry meetings. He is a member of the ACM, IEEE, and Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu, and Pi Tau Sigma.vi 7. C O N T E N T S AT A G L A N C E Preface xxvPA R T O N E The Product and the Process1 CHAPTER 1 The Product 3 CHAPTER 2 The Process 19PA R T T W O Managing Software Projects 53 CHAPTER 3 Project Management Concepts 55 CHAPTER 4 Software Process and Project Metrics79 CHAPTER 5 Software Project Planning113 CHAPTER 6 Risk Analysis and Management145 CHAPTER 7 Project Scheduling and Tracking 165 CHAPTER 8 Software Quality Assurance193 CHAPTER 9 Software Conguration Management225PA R T T H R E E Conventional Methods for Software Engineering243 CHAPTER 10System Engineering245 CHAPTER 11Analysis Concepts and Principles271 CHAPTER 12Analysis Modeling299 CHAPTER 13Design Concepts and Principles335 CHAPTER 14Architectural Design365 CHAPTER 15User Interface Design401 CHAPTER 16Component-Level Design 423 CHAPTER 17Software Testing Techniques 437 CHAPTER 18Software Testing Strategies 477 CHAPTER 19Technical Metrics for Software 507PA R T F O U R Object-Oriented Software Engineering 539 CHAPTER 20Object-Oriented Concepts and Principles541 CHAPTER 21Object-Oriented Analysis 571 CHAPTER 22Object-Oriented Design603vii 8. viii C O N T E N T S AT A G L A N C E CHAPTER 23 Object-Oriented Testing 631 CHAPTER 24 Technical Metrics for Object-Oriented Systems 653PA R T F I V E Advanced Topics in Software Engineering671 CHAPTER 25 Formal Methods673 CHAPTER 26 Cleanroom Software Engineering 699 CHAPTER 27 Component-Based Software Engineering721 CHAPTER 28 Client/Server Software Engineering747 CHAPTER 29 Web Engineering769 CHAPTER 30 Reengineering799 CHAPTER 31 Computer-Aided Software Engineering825 CHAPTER 32 The Road Ahead 845 9. TA B L E O F C O N T E N T SPA R T O N E T H E P R O D U C T A N D T H E P R O C E S S1CHAPTER 1 THE PRODUCT31.1The Evolving Role of Software 41.2Software 6 1.2.1 Software Characteristics 6 1.2.2 Software Applications 91.3Software: A Crisis on the Horizon? 111.4Software Myths 121.5Summary 15REFERENCES 15PROBLEMS AND POINTS TO PONDER 16FURTHER READINGS AND INFORMATION SOURCES 17CHAPTER 2 THE PROCESS192.1Software Engineering: A Layered Technology 20 2.1.1Process, Methods, and Tools 20 2.1.2A Generic View of Software Engineering 212.2The Software Process 232.3Software Process Models 262.4The Linear Sequential Model 282.5The Prototyping Model 302.6The RAD Model 322.7Evolutionary Software Process Models 34 2.7.1The Incremental Model 35 2.7.2The Spiral Model 36 2.7.3The WINWIN Spiral Model 38 2.7.4The Concurrent Development Model 402.8Component-Based Development 422.9The Formal Methods Model 432.10 Fourth Generation Techniques 442.11 Process Technology 462.12 Product and Process 462.13 Summary 47REFERENCES 47PROBLEMS AND POINTS TO PONDER 49FURTHER READINGS AND INFORMATION SOURCES 50ix 10. x CONTENTSPA R T T W O M A N A G I N G S O F T WA R E P R O J E C T S53CHAPTER 3 PROJECT MANAGEMENT CONCEPTS553.1The Management Spectrum 56 3.1.1 The People 56 3.1.2 The Product 57 3.1.2 The Process 57 3.1.3 The Project 573.2People 58 3.2.1 The Players 58 3.2.2 Team Leaders 59 3.2.3 The Software Team 60 3.2.4 Coordination and Communication Issues 653.3The Product 67 3.3.1 Software Scope 67 3.3.2 Problem Decomposition 673.4The Process 68 3.4.1 Melding the Product and the Process 69 3.4.2 Process Decomposition 703.5The Project 713.6The W5HH Principle 733.7Critical Practices 743.8Summary 74REFERENCES 75PROBLEMS AND POINTS TO PONDER 76FURTHER READINGS AND INFORMATION SOURCES 77CHAPTER 4 S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S 794.1Measures, Metrics, and Indicators 804.2Metrics in the Process and Project Domains 81 4.2.1Process Metrics and Software Process Improvement 82 4.2.2Project Metrics 864.3Software Measurement 87 4.3.1Size-Oriented Metrics 88 4.3.2Function-Oriented Metrics 89 4.3.3Extended Function Point Metrics 914.4Reconciling Different Metrics Approaches 944.5Metrics for Software Quality 95 4.5.1An Overview of Factors That Affect Quality 95 4.5.2Measuring Quality 96 4.5.3Defect Removal Efciency 984.6Integrating Metrics Within the Software Engineering Process 98 4.6.1Arguments for Software Metrics 99 4.6.2Establishing a Baseline 100 4.6.3Metrics Collection, Computation, and Evaluation 1004.7Managing Variation: Statistical Quality Control 1004.8Metrics for Small Organizations 1044.9Establishing a Software Metrics Program 1054.10 Summary 107REFERENCES 107 11. CONTENTSxiPROBLEMS AND POINTS TO PONDER 109FURTHER READINGS AND INFORMATION SOURCES 110CHAPTER 5 S O F T WA R E P R O J E C T P L A N N I N G 1135.1Observations on Estimating 1145.2Project Planning Objectives 1155.3Software Scope 115 5.3.1Obtaining Information Necessary for Scope 116 5.3.2Feasibility 117 5.3.3A Scoping Example 1185.4Resources 120 5.4.1Human Resources 121 5.4.2Reusable Software Resources 121 5.4.3Environmental Resources 1225.5Software Project Estimation 1235.6Decomposition Techniques 124 5.6.1Software Sizing 124 5.6.2Problem-Based Estimation 126 5.6.3An Example of LOC-Based Estimation 128 5.6.4An Example of FP-Based Estimation 129 5.6.4Process-Based Estimation 130 5.6.5An Example of Process-Based Estimation 1315.7Empirical Estimation Models 132 5.7.1The Structure of Estimation Models 132 5.7.2The COCOMO Model 133 5.7.3The Software Equation 1355.8The Make/Buy Decision 136 5.8.1Creating a Decision Tree 137 5.8.2Outsourcing 1385.9Automated Estimation Tools 1395.10 Summary 140REFERENCES 140PROBLEMS AND POINTS TO PONDER 141FURTHER READINGS AND INFORMATION SOURCES 142CHAPTER 6 R I S K A N A LY S I S A N D M A N A G E M E N T 1456.1Reactive versus Proactive Risk Strategies 1466.2Software Risks 1466.3Risk Identication 148 6.3.1 Assessing Overall Project Risk 149 6.3.2 Risk Components and Drivers 1496.4Risk Projection 151 6.4.1 Developing a Risk Table 151 6.4.2 Assessing Risk Impact 153 6.4.3 Risk Assessment 1546.5Risk Renement 1566.6Risk Mitigation, Monitoring, and Management 1566.7Safety Risks and Hazards 1586.8The RMMM Plan 1596.9Summary 159REFERENCES 160 12. xii CONTENTSPROBLEMS AND POINTS TO PONDER 161FURTHER READINGS AND INFORMATION SOURCES 162CHAPTER 7 PROJECT SCHEDULING AND TRACKING 1657.1Basic Concepts 166 7.1.1Comments on Lateness 167 7.2.1Basic Principles 1687.2The Relationship Between People and Effort 170 7.2.1An Example 170 7.2.2An Empirical Relationship 171 7.2.3Effort Distribution 1727.3Dening a Task Set for the Software Project 172 7.3.1Degree of Rigor 173 7.3.2Dening Adaptation Criteria 174 7.3.3Computing a Task Set Selector Value 175 7.3.4Interpreting the TSS Value and Selecting the Task Set 1767.4Selecting Software Engineering Tasks 1777.5Renement of Major Tasks 1787.6Dening a Task Network 1807.7Scheduling 181 7.7.1Timeline Charts 182 7.7.2Tracking the Schedule 1857.8Earned Value Analysis 1867.9Error Tracking 1877.10 The Project Plan 1897.11 Summary 189REFERENCES 189PROBLEMS AND POINTS TO PONDER 190FURTHER READINGS AND INFORMATION SOURCES 192CHAPTER 8 S O F T WA R E Q U A L I T Y A S S U R A N C E1938.1 Quality Concepts 1948.1.1 Quality 1958.1.2 Quality Control 1968.1.3 Quality Assurance 1968.1.4 Cost of Quality 1968.2 The Quality Movement 1988.3 Software Quality Assurance 1998.3.1 Background Issues 2008.3.2 SQA Activities 2018.4 Software Reviews 2028.4.1 Cost Impact of Software Defects 2038.4.2 Defect Amplication and Removal 2048.5 Formal Technical Reviews 2058.5.1 The Review Meeting 2068.5.2 Review Reporting and Record Keeping 2078.5.3 Review Guidelines 2078.6 Formal Approaches to SQA 2098.7 Statistical Software Quality Assurance 2098.8 Software Reliability 2128.8.1 Measures of Reliability and Availability 2128.8.2 Software Safety 213 13. CONTENTSxiii8.9Mistake-Proong for Software 2148.10 The ISO 9000 Quality Standards 216 8.10.1The ISO Approach to Quality Assurance Systems 217 8.10.2The ISO 9001 Standard 2178.11 The SQA Plan 2188.12 Summary 219REFERENCES 220PROBLEMS AND POINTS TO PONDER 221FURTHER READINGS AND INFORMATION SOURCES 222 CHAPTER 9S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T2259.1Software Conguration Management 226 9.1.1Baselines 227 9.1.2Software Conguration Items 2289.2The SCM Process 2309.3Identication of Objects in the Software Conguration 2309.4Version Control 2329.5Change Control 2349.6Conguration Audit 2379.7Status Reporting 2379.8SCM Standards 2389.9Summary 238REFERENCES 239PROBLEMS AND POINTS TO PONDER 239FURTHER READINGS AND INFORMATION SOURCES 240PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G 243 CHAPTER 10 SYSTEM ENGINEERING24510.1 Computer-Based Systems 24610.2 The System Engineering Hierarchy 248 10.2.1 System Modeling 249 10.2.2 System Simulation 25110.3 Business Process Engineering: An Overview 25110.4 Product Engineering: An Overview 25410.5 Requirements Engineering 256 10.5.1 Requirements Elicitation 256 10.5.2 Requirements Analysis and Negotiation 258 10.5.3 Requirements Specication 259 10.5.4 System Modeling 259 10.5.5 Requirements Validation 260 10.5.6 Requirements Management 26110.6 System Modeling 26210.7 Summary 265REFERENCES 267PROBLEMS AND POINTS TO PONDER 267FURTHER READINGS AND INFORMATION SOURCES 269 14. xiv CONTENTSCHAPTER 11 A N A LY S I S C O N C E P T S A N D P R I N C I P L E S 271 11.1 Requirements Analysis 272 11.2 Requirements Elicitation for Software 27411.2.1 Initiating the Process 27411.2.2 Facilitated Application Specication Techniques 27511.2.3 Quality Function Deployment 27911.2.4 Use-Cases 280 11.3 Analysis Principles 28211.3.1 The Information Domain 28311.3.2 Modeling 28511.3.3 Partitioning 28611.3.4 Essential and Implementation Views 288 11.4 Software Prototyping 28911.4.1 Selecting the Prototyping Approach 28911.4.2 Prototyping Methods and Tools 290 11.5 Specication 29111.5.1 Specication Principles 29111.5.2 Representation 29211.5.3 The Software Requirements Specication 293 11.6 Specication Review 294 11.7 Summary 294 REFERENCES 295 PROBLEMS AND POINTS TO PONDER 296 FURTHER READINGS AND INFORMATION SOURCES 297CHAPTER 12 A N A LY S I S M O D E L I N G299 12.1 A Brief History 300 12.2 The Elements of the Analysis Model 301 12.3 Data Modeling 30212.3.1 Data Objects, Attributes, and Relationships 30212.3.2 Cardinality and Modality 30512.3.3 Entity/Relationship Diagrams 307 12.4 Functional Modeling and Information Flow 30912.4.1 Data Flow Diagrams 31112.4.2 Extensions for Real-Time Systems 31212.4.3 Ward and Mellor Extensions 31212.4.4 Hatley and Pirbhai Extensions 315 12.5 Behavioral Modeling 317 12.6 The Mechanics of Structured Analysis 31912.6.1 Creating an Entity/Relationship Diagram 31912.6.2 Creating a Data Flow Model 32112.6.3 Creating a Control Flow Model 32412.6.4 The Control Specication 32512.6.5 The Process Specication 327 12.7 The Data Dictionary 328 12.8 Other Classical Analysis Methods 330 12.9 Summary 331 REFERENCES 331 PROBLEMS AND POINTS TO PONDER 332 FURTHER READINGS AND INFORMATION SOURCES 334 15. CONTENTS xvCHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 335 13.1 Software Design and Software Engineering 336 13.2 The Design Process 33813.2.1 Design and Software Quality 33813.2.2 The Evolution of Software Design 339 13.3 Design Principles 340 13.4 Design Concepts 34113.4.1 Abstraction 34213.4.2 Renement 34313.4.3 Modularity 34313.4.4 Software Architecture 34613.4.5 Control Hierarchy 34713.4.6 Structural Partitioning 34813.4.7 Data Structure 34913.4.8 Software Procedure 35113.4.9 Information Hiding 351 13.5 Effective Modular Design 35213.5.1 Functional Independence 35213.5.2 Cohesion 35313.5.3 Coupling 354 13.6 Design Heuristics for Effective Modularity 355 13.7 The Design Model 357 13.8 Design Documentation 358 13.9 Summary 359 REFERENCES 359 PROBLEMS AND POINTS TO PONDER 361 FURTHER READINGS AND INFORMATION SOURCES 362CHAPTER 14 ARCHITECTURAL DESIGN365 14.1Software Architecture 366 14.1.1What Is Architecture? 366 14.1.2Why Is Architecture Important? 367 14.2Data Design 368 14.2.1Data Modeling, Data Structures, Databases, and the Data Warehouse 368 14.2.2Data Design at the Component Level 369 14.3Architectural Styles 371 14.3.1A Brief Taxonomy of Styles and Patterns 371 14.3.2Organization and Renement 374 14.4Analyzing Alternative Architectural Designs 375 14.4.1An Architecture Trade-off Analysis Method 375 14.4.2Quantitative Guidance for Architectural Design 376 14.4.3Architectural Complexity 378 14.5Mapping Requirements into a Software Architecture 378 14.5.1Transform Flow 379 14.5.2Transaction Flow 380 14.6Transform Mapping 380 14.6.1An Example 380 14.6.2Design Steps 381 14.7 Transaction Mapping 389 14.7.1An Example 390 14.7.2Design Steps 390 16. xvi CONTENTS 14.8 Rening the Architectural Design 394 14.9 Summary 395 REFERENCES 396 PROBLEMS AND POINTS TO PONDER 397 FURTHER READINGS AND INFORMATION SOURCES 399CHAPTER 15 U S E R I N T E R FA C E D E S I G N 401 15.1 The Golden Rules 40215.1.1 Place the User in Control 40215.1.2 Reduce the Users Memory Load 40415.1.3 Make the Interface Consistent 404 15.2 User Interface Design 40515.2.1 Interface Design Models 40515.2.2 The User Interface Design Process 407 15.3 Task Analysis and Modeling 408 15.4 Interface Design Activities 41015.4.1 Dening Interface Objects and Actions 41015.4.2 Design Issues 413 15.5 Implementation Tools 415 15.6 Design Evaluation 416 15.7 Summary 418 REFERENCES 418 PROBLEMS AND POINTS TO PONDER 419 FURTHER READINGS AND INFORMATION SOURCES 420CHAPTER 16 COMPONENT-LEVEL DESIGN 423 16.1 Structured Programming 42416.1.1 Graphical Design Notation 42516.1.2 Tabular Design Notation 42716.1.3 Program Design Language 42916.1.4 A PDL Example 430 16.2 Comparison of Design Notation 432 16.3 Summary 433 REFERENCES 433 PROBLEMS AND POINTS TO PONDER 434 FURTHER READINGS AND INFORMATION SOURCES 435CHAPTER 17 S O F T WA R E T E S T I N G T E C H N I Q U E S 437 17.1 Software Testing Fundamentals 43817.1.1 Testing Objectives 43917.1.2 Testing Principles 43917.1.3 Testability 440 17.2 Test Case Design 443 17.3 White-Box Testing 444 17.4 Basis Path Testing 44517.4.1 Flow Graph Notation 44517.4.2 Cyclomatic Complexity 44617.4.3 Deriving Test Cases 44917.4.4 Graph Matrices 452 17.5 Control Structure Testing 45417.5.1 Condition Testing 454 17. CONTENTSxvii17.5.2Data Flow Testing 45617.5.3Loop Testing 458 17.6 Black-Box Testing 45917.6.1Graph-Based Testing Methods 46017.6.2Equivalence Partitioning 46317.6.3Boundary Value Analysis 46517.6.4Comparison Testing 46517.6.5Orthogonal Array Testing 466 17.7 Testing for Specialized Environments, Architectures, and Applications 46817.7.1Testing GUIs 46917.7.2Testing of Client/Server Architectures 46917.7.3Testing Documentation and Help Facilities 46917.7.4Testing for Real-Time Systems 470 17.8 Summary 472 REFERENCES 473 PROBLEMS AND POINTS TO PONDER 474 FURTHER READINGS AND INFORMATION SOURCES 475CHAPTER 18 S O F T WA R E T E S T I N G S T R AT E G I E S 477 18.1 A Strategic Approach to Software Testing 47818.1.1Verication and Validation 47918.1.2Organizing for Software Testing 47918.1.3A Software Testing Strategy 48018.1.4Criteria for Completion of Testing 482 18.2 Strategic Issues 484 18.3 Unit Testing 48518.3.1Unit Test Considerations 48518.3.2Unit Test Procedures 487 18.4 Integration Testing 48818.4.1Top-down Integration 48818.4.2Bottom-up Integration 49018.4.3Regression Testing 49118.4.4Smoke Testing 49218.4.5Comments on Integration Testing 49318.4.6Integration Test Documentation 494 18.5 Validation Testing 49518.5.1Validation Test Criteria 49518.5.2Conguration Review 49618.5.3Alpha and Beta Testing 496 18.6 System Testing 49618.6.1Recovery Testing 49718.6.2Security Testing 49718.6.3Stress Testing 49818.6.4Performance Testing 498 18.7 The Art of Debugging 49918.7.1The Debugging Process 49918.7.2Psychological Considerations 50018.7.3Debugging Approaches 501 18.8 Summary 502 REFERENCES 503 PROBLEMS AND POINTS TO PONDER 504 FURTHER READINGS AND INFORMATION SOURCES 505 18. xviiiCONTENTS CHAPTER 19T E C H N I C A L M E T R I C S F O R S O F T WA R E 507 19.1 Software Quality 50819.1.1McCalls Quality Factors 50919.1.2FURPS 51119.1.3ISO 9126 Quality Factors 51319.1.4The Transition to a Quantitative View 513 19.2 A Framework for Technical Software Metrics 51419.2.1The Challenge of Technical Metrics 51419.2.2Measurement Principles 51519.2.3The Attributes of Effective Software Metrics 516 19.3 Metrics for the Analysis Model 51719.3.1Function-Based Metrics 51819.3.2The Bang Metric 52019.3.3Metrics for Specication Quality 522 19.4 Metrics for the Design Model 52319.4.1Architectural Design Metrics 52319.4.2Component-Level Design Metrics 52619.4.3Interface Design Metrics 530 19.5 Metrics for Source Code 531 19.6 Metrics for Testing 532 19.7 Metrics for Maintenance 533 19.8 Summary 534 REFERENCES 534 PROBLEMS AND POINTS TO PONDER 536 FURTHER READING AND OTHER INFORMATION SOURCES 537PA R T F O U R O B J E C T - O R I E N T E D S O F T WA R E E N G I N E E R I N G 539 CHAPTER 20OBJECT-ORIENTED CONCEPTS AND PRINCIPLES 541 20.1 The Object-Oriented Paradigm 542 20.2 Object-Oriented Concepts 54420.2.1Classes and Objects 54620.2.2Attributes 54720.2.3Operations, Methods, and Services 54820.2.4Messages 54820.2.5Encapsulation, Inheritance, and Polymorphism 550 20.3 Identifying the Elements of an Object Model 55320.3.1Identifying Classes and Objects 55320.3.2Specifying Attributes 55720.3.3Dening Operations 55820.3.4Finalizing the Object Denition 559 20.4 Management of Object-Oriented Software Projects 56020.4.1The Common Process Framework for OO 56020.4.2OO Project Metrics and Estimation 56220.4.3An OO Estimating and Scheduling Approach 56420.4.4Tracking Progress for an OO Project 565 20.5 Summary 566 REFERENCES 566 PROBLEMS AND POINTS TO PONDER 567 FURTHER READINGS AND INFORMATION SOURCES 568 19. CONTENTS xixCHAPTER 21 O B J E C T - O R I E N T E D A N A LY S I S 571 21.1 Object-Oriented Analysis 57221.1.1Conventional vs. OO Approaches 57221.1.2The OOA Landscape 57321.1.3A Unied Approach to OOA 575 21.2 Domain Analysis 57621.2.1Reuse and Domain Analysis 57721.2.2The Domain Analysis Process 577 21.3 Generic Components of the OO Analysis Model 579 21.4 The OOA Process 58121.4.1Use-Cases 58121.4.2Class-Responsibility-Collaborator Modeling 58221.4.3Dening Structures and Hierarchies 58821.4.4Dening Subjects and Subsystems 590 21.5 The Object-Relationship Model 591 21.6 The Object-Behavior Model 59421.6.1Event Identication with Use-Cases 59421.6.2State Representations 595 21.7 Summary 598 REFERENCES 599 PROBLEMS AND POINTS TO PONDER 600 FURTHER READINGS AND INFORMATION SOURCES 601CHAPTER 22 OBJECT-ORIENTED DESIGN 603 22.1 Design for Object-Oriented Systems 60422.1.1 Conventional vs. OO Approaches 60522.1.2 Design Issues 60722.1.3 The OOD Landscape 60822.1.4 A Unied Approach to OOD 610 22.2 The System Design Process 61122.2.1 Partitioning the Analysis Model 61222.2.2 Concurrency and Subsystem Allocation 61322.2.3 The Task Management Component 61422.2.4 The User Interface Component 61522.2.5 The Data Management Component 61522.2.6 The Resource Management Component 61622.2.7 Intersubsystem Communication 616 22.3 The Object Design Process 61822.3.1 Object Descriptions 61822.3.2 Designing Algorithms and Data Structures 61922.3.3 Program Components and Interfaces 621 22.4 Design Patterns 62422.4.1 Describing a Design Pattern 62422.4.2 Using Patterns in Design 625 22.5 Object-Oriented Programming 625 22.6 Summary 626 REFERENCES 627 PROBLEMS AND POINTS TO PONDER 628 FURTHER READINGS AND INFORMATION SOURCES 629 20. xx CONTENTS CHAPTER 23 OBJECT-ORIENTED TESTING 63123.1 Broadening the View of Testing 63223.2 Testing OOA and OOD Models 633 23.2.1Correctness of OOA and OOD Models 633 23.2.2Consistency of OOA and OOD Models 63423.3 Object-Oriented Testing Strategies 636 23.3.1Unit Testing in the OO Context 636 23.3.2Integration Testing in the OO Context 637 23.3.3Validation Testing in an OO Context 63723.4 Test Case Design for OO Software 637 23.4.1The Test Case Design Implications of OO Concepts638 23.4.2Applicability of Conventional Test Case Design Methods 638 23.4.3Fault-Based Testing 639 23.4.4The Impact of OO Programming on Testing 640 23.4.5Test Cases and the Class Hierarchy 641 23.4.6Scenario-Based Test Design 641 23.4.7Testing Surface Structure and Deep Structure 64323.5 Testing Methods Applicable at the Class Level 644 23.5.1Random Testing for OO Classes 644 23.5.2Partition Testing at the Class Level 64423.6 Interclass Test Case Design 645 23.6.1Multiple Class Testing 645 23.6.2Tests Derived from Behavior Models 64723.7 Summary 648REFERENCES 649PROBLEMS AND POINTS TO PONDER 649FURTHER READINGS AND INFORMATION SOURCES 650 CHAPTER 24 TECHNICAL METRICS FOR OBJECT-ORIENTEDSYSTEMS65324.1 The Intent of Object-Oriented Metrics 65424.2 The Distinguishing Characteristics of Object-Oriented Metrics 654 24.2.1Localization 655 24.2.2Encapsulation 655 24.2.3Information Hiding 655 24.2.4Inheritance 656 24.2.5Abstraction 65624.3 Metrics for the OO Design Model 65624.4 Class-Oriented Metrics 658 24.4.1The CK Metrics Suite 658 24.4.2Metrics Proposed by Lorenz and Kidd 661 24.4.3The MOOD Metrics Suite 66224.5 Operation-Oriented Metrics 66424.6 Metrics for Object-Oriented Testing 66424.7 Metrics for Object-Oriented Projects 66524.8 Summary 666REFERENCES 667PROBLEMS AND POINTS TO PONDER 668FURTHER READINGS AND INFORMATION SOURCES 669 21. CONTENTSxxiPA R T F I V E A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G671 CHAPTER 25 FORMAL METHODS67325.1 Basic Concepts 674 25.1.1Deciencies of Less Formal Approaches 675 25.1.2Mathematics in Software Development 676 25.1.3Formal Methods Concepts 67725.2 Mathematical Preliminaries 682 25.2.1Sets and Constructive Specication 683 25.2.2Set Operators 684 25.2.3Logic Operators 686 25.2.4Sequences 68625.3 Applying Mathematical Notation for Formal Specication 68725.4 Formal Specication Languages 68925.5 Using Z to Represent an Example Software Component 69025.6 The Ten Commandments of Formal Methods 69325.7 Formal MethodsThe Road Ahead 69425.8 Summary 695REFERENCES 695PROBLEMS AND POINTS TO PONDER 696FURTHER READINGS AND INFORMATION SOURCES 697 CHAPTER 26 C L E A N R O O M S O F T WA R E E N G I N E E R I N G 69926.1 The Cleanroom Approach 700 26.1.1The Cleanroom Strategy 701 26.1.2What Makes Cleanroom Different? 70326.2 Functional Specication 703 26.2.1Black-Box Specication 705 26.2.2State-Box Specication 705 26.2.3Clear-Box Specication 70626.3 Cleanroom Design 706 26.3.1Design Renement and Verication 707 26.3.2Advantages of Design Verication 71026.4 Cleanroom Testing 712 26.4.1Statistical Use Testing 712 26.4.2Certication 71426.5 Summary 714REFERENCES 715PROBLEMS AND POINTS TO PONDER 716FURTHER READINGS AND INFORMATION SOURCES 717 CHAPTER 27 C O M P O N E N T - B A S E D S O F T WA R E E N G I N E E R I N G 72127.1 Engineering of Component-Based Systems 72227.2 The CBSE Process 72427.3 Domain Engineering 725 27.3.1The Domain Analysis Process 726 27.3.2Characterization Functions 727 27.3.3Structural Modeling and Structure Points 72827.4 Component-Based Development 730 27.4.1Component Qualication, Adaptation, and Composition 730 22. xxii CONTENTS 27.4 2 Component Engineering 734 27.4.3 Analysis and Design for Reuse 73427.5 Classifying and Retrieving Components 735 27.5.1 Describing Reusable Components 736 27.5.2 The Reuse Environment 73827.6 Economics of CBSE 739 27.6.1 Impact on Quality, Productivity, and Cost 739 27.6.2 Cost Analysis Using Structure Points 741 27.6.3 Reuse Metrics 74127.7 Summary 742REFERENCES 743PROBLEMS AND POINTS TO PONDER 744FURTHER READINGS AND INFORMATION SOURCES 745 CHAPTER 28 C L I E N T / S E R V E R S O F T WA R E E N G I N E E R I N G 74728.1 The Structure of Client/Server Systems 748 28.1.1Software Components for c/s Systems 750 28.1.2The Distribution of Software Components 750 28.1.3Guidelines for Distributing Application Subsystems 752 28.1.4Linking c/s Software Subsystems 753 28.1.5Middleware and Object Request Broker Architectures 75328.2 Software Engineering for c/s Systems 75528.3 Analysis Modeling Issues 75528.4 Design for c/s Systems 755 28.4.1Architectural Design for Client/Server Systems 756 28.4.2Conventional Design Approaches for Application Software 757 28.4.3Database Design 758 28.4.4An Overview of a Design Approach 759 28.4.5Process Design Iteration 76128.5 Testing Issues 761 28.5.1Overall c/s Testing Strategy 762 28.5.2c/s Testing Tactics 76328.6 Summary 764REFERENCES 764PROBLEMS AND POINTS TO PONDER 765FURTHER READINGS AND INFORMATION SOURCES 766 CHAPTER 29 WEB ENGINEERING76929.1 The Attributes of Web-Based Applications 771 29.1.1 Quality Attributes 773 29.1.2 The Technologies 77329.2 The WebE Process 77429.3 A Framework for WebE 77529.4 Formulating/Analyzing Web-Based Systems 776 29.4.1 Formulation 776 29.4.2 Analysis 77829.5 Design for Web-Based Applications 779 29.5.1 Architectural Design 780 29.5.2 Navigation Design 783 29.5.3 Interface Design 785 23. CONTENTSxxiii 29.6 Testing Web-Based Applications 786 29.7 Management Issues 78729.7.1 The WebE Team 78829.7.2 Project Management 78929.7.3 SCM Issues for WebE 792 29.8 Summary 794 REFERENCES 795 PROBLEMS AND POINTS TO PONDER 796 FURTHER READINGS AND INFORMATION SOURCES 797CHAPTER 30 REENGINEERING799 30.1 Business Process Reengineering 80030.1.1 Business Processes 80030.1.2 Principles of Business Process Reengineering 80130.1.3 A BPR Model 80230.1.4 Words of Warning 804 30.2 Software Reengineering 80430.2.1 Software Maintenance 80430.2.2 A Software Reengineering Process Model 805 30.3 Reverse Engineering 80930.3.1 Reverse Engineering to Understand Processing 81030.3.2 Reverse Engineering to Understand Data 81130.3.3 Reverse Engineering User Interfaces 812 30.4 Restructuring 81330.4.1 Code Restructuring 81430.4.2 Data Restructuring 814 30.5 Forward Engineering 81430.5.1 Forward Engineering for Client/Server Architectures 81630.5.2 Forward Engineering for Object-Oriented Architectures 81730.5.3 Forward Engineering User Interfaces 818 30.6 The Economics of Reengineering 819 30.7 Summary 820 REFERENCES 820 PROBLEMS AND POINTS TO PONDER 822 FURTHER READINGS AND INFORMATION SOURCES 823CHAPTER 31 C O M P U T E R - A I D E D S O F T WA R E E N G I N E E R I N G 825 31.1 What is CASE? 826 31.2 Building Blocks for CASE 826 31.3 A Taxonomy of CASE Tools 828 31.4 Integrated CASE Environments 833 31.5 The Integration Architecture 834 31.6 The CASE Repository 83631.6.1 The Role of the Repository in I-CASE 83631.6.2 Features and Content 837 31.7 Summary 841 REFERENCES 842 PROBLEMS AND POINTS TO PONDER 842 FURTHER READINGS AND INFORMATION SOURCES 843 24. xxiv CONTENTS CHAPTER 32 THE ROAD AHEAD84532.1 The Importance of SoftwareRevisited 84632.2 The Scope of Change 84732.3 People and the Way They Build Systems 84732.4 The "New" Software Engineering Process 84832.5 New Modes for Representing Information 84932.6 Technology as a Driver 85132.7 A Concluding Comment 852REFERENCES 853PROBLEMS AND POINTS TO PONDER 853FURTHER READINGS AND INFORMATION SOURCES 853 25. P R E FA C E hen a computer software succeedswhen it meets the needs of the peopleWwho use it, when it performs awlessly over a long period of time, when it iseasy to modify and even easier to useit can and does change things for the better.But when software failswhen its users are dissatised, when it is error prone, whenit is difcult to change and even harder to usebad things can and do happen. Weall want to build software that makes things better, avoiding the bad things that lurkin the shadow of failed efforts. To succeed, we need discipline when software isdesigned and built. We need an engineering approach. In the 20 years since the rst edition of this book was written, software engineer-ing has evolved from an obscure idea practiced by a relatively small number of zealotsto a legitimate engineering discipline. Today, it is recognized as a subject worthy ofserious research, conscientious study, and tumultuous debate. Throughout the indus-try, software engineer has replaced programmer as the job title of preference. Softwareprocess models, software engineering methods, and software tools have been adoptedsuccessfully across a broad spectrum of industry applications. Although managers and practitioners alike recognize the need for a more disci-plined approach to software, they continue to debate the manner in which disciplineis to be applied. Many individuals and companies still develop software haphazardly,even as they build systems to service the most advanced technologies of the day.Many professionals and students are unaware of modern methods. And as a result,the quality of the software that we produce suffers and bad things happen. In addi-tion, debate and controversy about the true nature of the software engineeringapproach continue. The status of software engineering is a study in contrasts. Atti-tudes have changed, progress has been made, but much remains to be done beforethe discipline reaches full maturity. The fth edition of Software Engineering: A Practitioners Approach is intended toserve as a guide to a maturing engineering discipline. The fth edition, like the foureditions that preceded it, is intended for both students and practitioners, retaining itsappeal as a guide to the industry professional and a comprehensive introduction tothe student at the upper level undergraduate or rst year graduate level. The formatand style of the fth edition have undergone signicant change, making the presen-tation more reader-friendly and the content more easily accessible. The fth edition is considerably more than a simple update. The book has beenrevised to accommodate the dramatic growth in the eld and to emphasize new andimportant software engineering practices. In addition, a comprehensive Web site hasbeen developed to complement the content of the book. The Web site, which I call xxv 26. xxvi P R E FA C E SepaWeb, can be found at http://www.mhhe.com/pressman. Designed to be used in conjunction with the fth edition of Software Engineering: A Practitioners Approach, SepaWeb provides a broad array of software engineering resources that will benet instructors, students, and industry professionals. Like all Web sites, SepaWeb will evolve over time, but the following major con- tent areas will always be present: (1) a broad array of instructor resources including a comprehensive on-line Instructors Guide and supplementary teaching materials (e.g., slide presentations to supplement lectures, video-based instructional aids); (2) a wide variety of student resources including an extensive on-line learning center (encompassing study guides, Web-based resources, and self-tests), an evolving col- lection of tiny tools, a case study, and additional supplementary content; and (3) a detailed collection of professional resources including outlines (and samples of) soft- ware engineering documents and other work products, a useful set of software engi- neering checklists, a catalog of software engineering (CASE) tools, a comprehensive collection of Web-based resources, and an adaptable process model that provides a detailed task breakdown of the software engineering process. In addition, Sepa- Web will contain other goodies that are currently in development. The 32 chapters of the fth edition have been organized into ve parts. This has been done to compartmentalize topics and assist instructors who may not have the time to complete the entire book in one term. Part One, The Product and the Process, presents an introduction to the software engineering milieu. It is intended to intro- duce the subject matter, and more important, to present concepts that will be nec- essary for later chapters. Part Two, Managing Software Projects, presents topics that are relevant to those who plan, manage, and control a software development proj- ect. Part Three, Conventional Methods for Software Engineering, presents the clas- sical analysis, design, and testing methods that some view as the conventional school of software engineering. Part Four, Object-Oriented Software Engineering, presents object-oriented methods across the entire software engineering process, including analysis, design, and testing. Part Five, Advanced Software Engineering Topics, presents dedicated chapters that address formal methods, cleanroom soft- ware engineering, component-based software engineering, client/server software engineering, Web engineering, reengineering, and CASE. The ve-part organization of the fth edition enables an instructor to "cluster" top- ics based on available time and student need. An entire one-term course can be built around one or more of the ve parts. For example, a "design course" might empha- size only Part Three or Part Four; a "methods course" might present selected chap- ters in Parts Three, Four, and Five. A "management course" would stress Parts One and Two. By organizing the fth edition in this way, I attempted to provide an instruc- tor with a number of teaching options. SepaWeb can and should be used to supple- ment the content that is chosen from the book. An Instructors Guide for Software Engineering: A Practitioners Approach is avail- able from SepaWeb. The Instructors Guide presents suggestions for conducting var- 27. P R E FA C E xxviiious types of software engineering courses, recommendations for a variety of soft-ware projects to be conducted in conjunction with a course, solutions to selectedproblems, and a number of teaching aids.A comprehensive video curriculum, Essential Software Engineering, is available tocomplement this book. The video curriculum has been designed for industry train-ing and has been modularized to enable individual software engineering topics to bepresented on an as-needed, when-needed basis. Further information on the videocan be obtained by mailing the request card at the back of this book.1My work on the ve editions of Software Engineering: A Practitioners Approach hasbeen the longest continuing technical project of my life. Even when the writing stops,information extracted from the technical literature continues to be assimilated andorganized. For this reason, my thanks to the many authors of books, papers, and arti-cles as well as a new generation of contributors to electronic media (newsgroups, e-newsletters, and the World Wide Web) who have provided me with additional insight,ideas, and commentary over the past 20 years. Many have been referenced withinthe pages of each chapter. All deserve credit for their contribution to this rapidly evolv-ing field. I also wish to thank the reviewers of the fifth edition: Donald H. Kraft,Louisiana State University; Panos E. Livadas, University of Florida; Joseph Lambert,Pennsylvania State University; Kenneth L. Modesitt, University of MichiganDear-born; and, James Purtilo, University of Maryland. Their comments and criticism havebeen invaluable. Special thanks and acknowledgement also go to Bruce Maxim ofthe University of MichiganDearborn, who assisted me in developing the Web sitethat accompanies this book. Bruce is responsible for much of its design and peda-gogical content.The content of the fth edition of Software Engineering: A Practitioners Approachhas been shaped by industry professionals, university professors, and students whohave used earlier editions of the book and have taken the time to communicate theirsuggestions, criticisms, and ideas. My thanks to each of you. In addition, my personalthanks go to our many industry clients worldwide, who certainly teach me as muchor more than I can teach them.As the editions of this book have evolved, my sons, Mathew and Michael, havegrown from boys to men. Their maturity, character, and success in the real worldhave been an inspiration to me. Nothing has lled me with more pride. And nally,to Barbara, my love and thanks for encouraging still another edition of "the book."Roger S. Pressman1 If the request card is missing, please visit the R. S. Pressman & Associates, Inc. Web site athttp://www.rspa.com/ese or e-mail a request for information to info@rspa.com. 28. USING THIS BOOK The fifth edition of Software Engineering: A Practitioners Approach (SEPA) has beenredesigned to enhance your reading experience and to provide integrated links to the SEPA Web site, http://www.mhhe.com/pressman/. SepaWeb contains a wealth of useful supplementary information for readers of the book and a broad array of resources (e.g., an Instructors Guide, classroom slides, and video supplements) for instructors who have adopted SEPA for classroom use. A comprehensive video curriculum, Essential Software Engineering, is available to com- plement this book. The video curriculum has been designed for industry training and has been modularized to enable individual software engineering topics to be presented on an as-needed, when-needed basis. Further information on the video can be obtained by mail- ing the request card at the back of this book.1 Throughout the book, you will encounter marginal icons that should be interpreted in the following manner: The keypoint icon will help you The WebRef icon provides Used to emphasize anWebRef to nd important points quickly.direct pointers to important important point in the For pointers that will take software engineering related body of the text. you directly to Web Web sites. resources The advice icon provides prag- matic guidance that can help The SepaWeb pointer indicates Practical advice from you make the right decision or that further information about the real world of avoid common problems while the noted topic is available at software engineering. building software. the SEPA Web site. A selected topic The question mark icon asks? Where can Ind thecommon questions that are The SepaWeb.checklists icon answer? answered in the body of the points you to detailed checklists text. that will help you to assess the The xref icon will point you to software engineering work XRef another part of the book whereyoure doing and the workProvides an importantcross reference within information relevant to the cur-products you produce.the book.rent discussion can be found. The SepaWeb.documents The quote icon presents inter- icon points you to detailed doc- esting quotes that have rele- Important words ument outlines, descriptions vance to the topic at hand. and examples contained within the SEPA Web site. 1 If the card is missing, please visit the R.S. Pressman & Associates, Inc. Web site atxxviii http://www.rspa.com/ese, or e-mail to info@rspa.com. 29. PA R TOneTHE PRODUCT ANDTHE PROCESS n this part of Software Engineering: A Practitioners Approach, youll I learn about the product that is to be engineered and the process that provides a framework for the engineering technology. The following questions are addressed in the chapters that follow: What is computer software . . . really? Why do we struggle to build high-quality computer-based systems? How can we categorize application domains for computer software? What myths about software still exist? What is a software process? Is there a generic way to assess the quality of a process? What process models can be applied to software develop- ment? How do linear and iterative process models differ? What are their strengths and weaknesses? What advanced process models have been proposed for soft- ware engineering work? Once these questions are answered, youll be better prepared to understand the management and technical aspects of the engi- neering discipline to which the remainder of this book is dedicated. 1 30. CHAPTER1THE PRODUCTKEY The warnings began more than a decade before the event, but no one paidCONCEPTSmuch attention. With less than two years to the deadline, the mediaapplicationpicked up the story. Then government ofcials voiced their concern, busi-categories . . . . . . . 9 ness and industry leaders committed vast sums of money, and nally, dire warn-component-basedassembly. . . . . . . . . 8ings of pending catastrophe penetrated the publics consciousness. Software,failure curves . . . . . 8 in the guise of the now-infamous Y2K bug, would fail and, as a result, stop thehistory . . . . . . . . . . 5world as we then knew it.As we watched and wondered during the waning months of 1999, I couldntmyths . . . . . . . . . . 12 help thinking of an unintentionally prophetic paragraph contained on the rstreuse . . . . . . . . . . . . 9 page of the fourth edition of this book. It stated:softwarecharacteristics . . . . 6Computer software has become a driving force. It is the engine that drives businesssoftware decision making. It serves as the basis for modern scientic investigation and engi-engineering . . . . . . 4 neering problem solving. It is a key factor that differentiates modern products andwear . . . . . . . . . . . . 7 services. It is embedded in systems of all kinds: transportation, medical, telecom- munications, military, industrial processes, entertainment, ofce products, . . . the list is almost endless. Software is virtually inescapable in a modern world. And as we move into the twenty-rst century, it will become the driver for new advances in everything from elementary education to genetic engineering. QUICKWhat is it? Computer software isWhat are the steps? You build computer software LOOK the product that software engi-like you build any successful product, by apply-neers design and build. It encom-ing a process that leads to a high-quality resultpasses programs that execute within a computer that meets the needs of the people who will useof any size and architecture, documents that the product. You apply a software engineeringencompass hard-copy and virtual forms, and approach.data that combine numbers and text but also What is the work product? From the point of view ofincludes representations of pictorial, video, anda software engineer, the work product is the pro-audio information. grams, documents, and data that are computerWho does it? Software engineers build it, and virtu- software. But from the users viewpoint, the workally everyone in the industrialized world uses itproduct is the resultant information that somehoweither directly or indirectly. makes the users world better.Why is it important? Because it affects nearly everyHow do I ensure that Ive done it right? Read theaspect of our lives and has become pervasive inremainder of this book, select those ideas appli-our commerce, our culture, and our everydaycable to the software that you build, and applyactivities.them to your work. 3 31. 4 PA R T O N E THE PRODUCT AND THE PROCESSIn the ve years since the fourth edition of this book was written, the role of soft-ware as the driving force has become even more obvious. A software-driven Inter-net has spawned its own $500 billion economy. In the euphoria created by the promiseof a new economic paradigm, Wall Street investors gave tiny dot-com companiesbillion dollar valuations before these start-ups produced a dollar in sales. Newsoftware-driven industries have arisen and old ones that have not adapted to the newdriving force are now threatened with extinction. The United States government haslitigated against the softwares industrys largest company, just as it did in earlier eraswhen it moved to stop monopolistic practices in the oil and steel industries.Softwares impact on our society and culture continues to be profound. As itsimportance grows, the software community continually attempts to develop tech-Ideas andnologies that will make it easier, faster, and less expensive to build high-quality com- technological discoveries are theputer programs. Some of these technologies are targeted at a specific application driving engines of domain (e.g., Web-site design and implementation); others focus on a technology economic growth.domain (e.g., object-oriented systems); and still others are broad-based (e.g., oper- The Wall Streetating systems such as LINUX). However, we have yet to develop a software technol- Journalogy that does it all, and the likelihood of one arising in the future is small. And yet,people bet their jobs, their comfort, their safety, their entertainment, their decisions,and their very lives on computer software. It better be right.This book presents a framework that can be used by those who build computersoftwarepeople who must get it right. The technology encompasses a process, aset of methods, and an array of tools that we call software engineering. 1.1T H E E V O LV I N G R O L E O F S O F T WA R EToday, software takes on a dual role. It is a product and, at the same time, the vehi-cle for delivering a product. As a product, it delivers the computing potential embod-ied by computer hardware or, more broadly, a network of computers that are accessibleby local hardware. Whether it resides within a cellular phone or operates inside amainframe computer, software is an information transformerproducing, manag-Software is both aing, acquiring, modifying, displaying, or transmitting information that can be as sim-product and a vehicleple as a single bit or as complex as a multimedia presentation. As the vehicle usedfor delivering aproduct.to deliver the product, software acts as the basis for the control of the computer (oper-ating systems), the communication of information (networks), and the creation andcontrol of other programs (software tools and environments).Software delivers the most important product of our timeinformation. Softwaretransforms personal data (e.g., an individuals nancial transactions) so that the datacan be more useful in a local context; it manages business information to enhancecompetitiveness; it provides a gateway to worldwide information networks (e.g., Inter-net) and provides the means for acquiring information in all of its forms.The role of computer software has undergone signicant change over a time spanof little more than 50 years. Dramatic improvements in hardware performance, pro- 32. CHAPTER 1 THE PRODUCT 5 found changes in computing architectures, vast increases in memory and storage capacity, and a wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. Sophistication and com- plexity can produce dazzling results when a system succeeds, but they can also pose huge problems for those who must build complex systems. Popular books published during the 1970s and 1980s provide useful historical insight into the changing perception of computers and software and their impact onFor I dipped into the our culture. Osborne [OSB79] characterized a "new industrial revolution." Toffler future, far as the[TOF80] called the advent of microelectronics part of "the third wave of change" in human eye could human history, and Naisbitt [NAI82] predicted a transformation from an industrial see, Saw the vision society to an "information society." Feigenbaum and McCorduck [FEI83] suggested of the world, and all the wonder that that information and knowledge (controlled by computers) would be the focal point would be.for power in the twenty-rst century, and Stoll [STO89] argued that the "electronic Tennysoncommunity" created by networks and software was the key to knowledge interchange throughout the world. As the 1990s began, Tofer [TOF90] described a "power shift" in which old power structures (governmental, educational, industrial, economic, and military) disinte- grate as computers and software lead to a "democratization of knowledge." YourdonComputers make it [YOU92] worried that U.S. companies might loose their competitive edge in software- easy to do a lot of related businesses and predicted the decline and fall of the American programmer. things, but most of the things that theyHammer and Champy [HAM93] argued that information technologies were to play a make it easier to dopivotal role in the reengineering of the corporation. During the mid-1990s, the per- dont need to bevasiveness of computers and software spawned a rash of books by neo-Luddites done.(e.g., Resisting the Virtual Life, edited by James Brook and Iain Boal and The Future Andy Rooney Does Not Compute by Stephen Talbot). These authors demonized the computer, empha- sizing legitimate concerns but ignoring the profound benets that have already been realized. [LEV95] During the later 1990s, Yourdon [YOU96] re-evaluated the prospects for the software professional and suggested the the rise and resurrection of the Ameri- can programmer. As the Internet grew in importance, his change of heart proved to be correct. As the twentieth century closed, the focus shifted once more, this time to the impact of the Y2K time bomb (e.g., [YOU98b], [DEJ98], [KAR99]). Although the predictions of the Y2K doomsayers were incorrect, their popular writings drove home the pervasiveness of software in our lives. Today, ubiquitous computing [NOR98] has spawned a generation of information appliances that have broadband connectivity to the Web to provide a blanket of connectedness over our homes, offices and motorways [LEV99]. Softwares role continues to expand. The lone programmer of an earlier era has been replaced by a team of software specialists, each focusing on one part of the technology required to deliver a com- plex application. And yet, the same questions asked of the lone programmer are being asked when modern computer-based systems are built: 33. 6 PA R T O N ETHE PRODUCT AND THE PROCESS Why does it take so long to get software nished? Why are development costs so high? Why cant we nd all the errors before we give the software to customers? Why do we continue to have difculty in measuring progress as software isbeing developed?These, and many other questions,1 are a manifestation of the concern about soft-ware and the manner in which it is developeda concern that has lead to the adop-tion of software engineering practice.1.2 S O F T WA R EIn 1970, less than 1 percent of the public could have intelligently described what"computer software" meant. Today, most professionals and many members of thepublic at large feel that they understand software. But do they?A textbook description of software might take the following form: Software is (1)instructions (computer programs) that when executed provide desired function and per-? Howdeneweshouldformance, (2) data structures that enable the programs to adequately manipulate infor-mation, and (3) documents that describe the operation and use of the programs. Theresoftware?is no question that other, more complete denitions could be offered. But we needmore than a formal denition.1.2.1Software CharacteristicsTo gain an understanding of software (and ultimately an understanding of softwareengineering), it is important to examine the characteristics of software that make itdifferent from other things that human beings build. When hardware is built, thehuman creative process (analysis, design, construction, testing) is ultimately trans-lated into a physical form. If we build a new computer, our initial sketches, formaldesign drawings, and breadboarded prototype evolve into a physical product (chips,circuit boards, power supplies, etc.).Software is a logical rather than a physical system element. Therefore, softwarehas characteristics that are considerably different than those of hardware:1. Software is developed or engineered, it is not manufactured in the classicalsense.Software isengineered, not Although some similarities exist between software development and hardware man-manufactured. ufacture, the two activities are fundamentally different. In both activities, high qual-1 In an excellent book of essays on the software business, Tom DeMarco [DEM95] argues the coun-terpoint. He states: Instead of asking why does software cost so much? we need to begin ask-ing What have we done to make it possible for todays software to cost so little? The answer tothat question will help us continue the extraordinary level of achievement that has always distin-guished the software industry. 34. CHAPTER 1THE PRODUCT 7F I G U R E 1.1Failure curvefor hardwareInfant Wear outmortalityFailure rate Timeity is achieved through good design, but the manufacturing phase for hardware canintroduce quality problems that are nonexistent (or easily corrected) for software.Both activities are dependent on people, but the relationship between people appliedand work accomplished is entirely different (see Chapter 7). Both activities requirethe construction of a "product" but the approaches are different. Software costs are concentrated in engineering. This means that software proj-ects cannot be managed as if they were manufacturing projects.Software doesnt wear 2. Software doesnt "wear out."out, but it doesFigure 1.1 depicts failure rate as a function of time for hardware. The relationship,deteriorate.often called the "bathtub curve," indicates that hardware exhibits relatively high fail-ure rates early in its life (these failures are often attributable to design or manufac-turing defects); defects are corrected and the failure rate drops to a steady-state level(ideally, quite low) for some period of time. As time passes, however, the failure raterises again as hardware components suffer from the cumulative affects of dust, vibra-tion, abuse, temperature extremes, and many other environmental maladies. Statedsimply, the hardware begins to wear out. Software is not susceptible to the environmental maladies that cause hardware towear out. In theory, therefore, the failure rate curve for software should take the form ofthe idealized curve shown in Figure 1.2. Undiscovered defects will cause high failurerates early in the life of a program. However, these are corrected (ideally, without intro-ducing other errors) and the curve attens as shown.The idealized curve is a gross over-simplication of actual failure models (see Chapter 8 for more information) for software.However, the implication is clearsoftware doesnt wear out. But it does deteriorate! This seeming contradiction can best be explained by considering the actual curveshown in Figure 1.2. During its life, software will undergo change (maintenance). As 35. 8 PA R T O N ETHE PRODUCT AND THE PROCESSF I G U R E 1.2Increased failureIdealized andactual failure rate due to sidecurves foreffectssoftware Failure rate Change Actual curve Idealized curveSoftware engineering Timemethods strive toreduce the magnitudeof the spikes and the changes are made, it is likely that some new defects will be introduced, causing theslope of the actual failure rate curve to spike as shown in Figure 1.2. Before the curve can return to thecurve in Figure 1.2.original steady-state failure rate, another change is requested, causing the curve tospike again. Slowly, the minimum failure rate level begins to risethe software isdeteriorating due to change.Another aspect of wear illustrates the difference between hardware and software.When a hardware component wears out, it is replaced by a spare part. There are nosoftware spare parts. Every software failure indicates an error in design or in theprocess through which design was translated into machine executable code. There-fore, software maintenance involves considerably more complexity than hardwaremaintenance. 3. Although the industry is moving toward component-based assembly, mostMost software software continues to be custom built.continues to becustom built. Consider the manner in which the control hardware for a computer-based productis designed and built. The design engineer draws a simple schematic of the digitalcircuitry, does some fundamental analysis to assure that proper function will beachieved, and then goes to the shelf where catalogs of digital components exist. Eachintegrated circuit (called an IC or a chip) has a part number, a dened and validatedfunction, a well-dened interface, and a standard set of integration guidelines. Aftereach component is selected, it can be ordered off the shelf.As an engineering discipline evolves, a collection of standard design componentsis created. Standard screws and off-the-shelf integrated circuits are only two of thou-sands of standard components that are used by mechanical and electrical engineersas they design new systems. The reusable components have been created so that theengineer can concentrate on the truly innovative elements of a design, that is, the 36. CHAPTER 1 THE PRODUCT9parts of the design that represent something new. In the hardware world, componentreuse is a natural part of the engineering process. In the software world, it is some-thing that has only begun to be achieved on a broad scale. A software component should be designed and implemented so that it can bereused in many different programs. In the 1960s, we built scientic subroutine libraries XRef that were reusable in a broad array of engineering and scientic applications. TheseSoftware reuse is subroutine libraries reused well-dened algorithms in an effective manner but had adiscussed in Chapter13. Component-based limited domain of application. Today, we have extended our view of reuse to encom-software engineering is pass not only algorithms but also data structure. Modern reusable components encap-presented in Chaptersulate both data and the processing applied to the data, enabling the software engineer27.to create new applications from reusable parts. For example, todays graphical userinterfaces are built using reusable components that enable the creation of graphicswindows, pull-down menus, and a wide variety of interaction mechanisms. The datastructure and processing detail required to build the interface are contained with alibrary of reusable components for interface construction.1.2.2Software ApplicationsSoftware may be applied in any situation for which a prespecied set of proceduralsteps (i.e., an algorithm) has been dened (notable exceptions to this rule are expertsystem software and neural network software). Information content and determinacyare important factors in determining the nature of a software application. Contentrefers to the meaning and form of incoming and outgoing information. For example,many business applications use highly structured input data (a database) and pro-duce formatted reports. Software that controls an automated machine (e.g., anumerical control) accepts discrete data items with limited structure and producesindividual machine commands in rapid succession. Information determinacy refers to the predictability of the order and timing of infor-mation. An engineering analysis program accepts data that have a predened order,executes the analysis algorithm(s) without interruption, and produces resultant datain report or graphical format. Such applications are determinate. A multiuser oper-ating system, on the other hand, accepts inputs that have varied content and arbi-trary timing, executes algorithms that can be interrupted by external conditions, andproduces output that varies as a function of environment and time. Applications withthese characteristics are indeterminate. It is somewhat difcult to develop meaningful generic categories for software appli-cations. As software complexity grows, neat compartmentalization disappears. Thefollowing software areas indicate the breadth of potential applications:System software. System software is a collection of programs written to serviceother programs. Some system software (e.g., compilers, editors, and le manage-ment utilities) process complex, but determinate, information structures. Other sys-tems applications (e.g., operating system components, drivers, telecommunications 37. 10 PA R T O N E THE PRODUCT AND THE PROCESS processors) process largely indeterminate data. In either case, the system software area is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and sophisticated process management; complex data structures; and multiple external interfaces. Real-time software. Software that monitors/analyzes/controls real-world events as they occur is called real time. Elements of real-time software include a data gath- ering component that collects and formats information from an external environ- ment, an analysis component that transforms information as required by the application, a control/output component that responds to the external environment, and a monitoring component that coordinates all other components so that real-time response (typically ranging from 1 millisecond to 1 second) can be maintained. Business software. Business information processing is the largest single software application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inven- tory) have evolved into management information system (MIS) software that accesses one or more large databases containing business information. Applications in thisOne of the mostarea restructure existing data in a way that facilitates business operations or man-comprehensive libraries of agement decision making. In addition to conventional data processing application,shareware/freeware can business software applications also encompass interactive computing (e.g., point-be found atwww.shareware.comof-sale transaction processing). Engineering and scientic software. Engineering and scientic software have been characterized by "number crunching" algorithms. Applications range from astron- omy to volcanology, from automotive stress analysis to space shuttle orbital dynam- ics, and from molecular biology to automated manufacturing. However, modern applications within the engineering/scientic area are moving away from conven- tional numerical algorithms. Computer-aided design, system simulation, and other interactive applications have begun to take on real-time and even system software characteristics. Embedded software. Intelligent products have become commonplace in nearly every consumer and industrial market. Embedded software resides in read-only mem- ory and is used to control products and systems for the consumer and industrial mar- kets. Embedded software can perform very limited and esoteric functions (e.g., keypad control for a microwave oven) or provide signicant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems). Personal computer software. The personal computer software market has bur- geoned over the past two decades. Word processing, spreadsheets, computer graph- ics, multimedia, entertainment, database management, personal and business nancial applications, external network, and database access are only a few of hundreds of applications. Web-based software. The Web pages retrieved by a browser are software that incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., 38. CHAPTER 1 THE PRODUCT11hypertext and a variety of visual and audio formats). In essence, the network becomesa massive computer providing an almost unlimited software resource that can beaccessed by anyone with a modem.Artificial intelligence software. Artificial intelligence (AI) software makes useof nonnumerical algorithms to solve complex problems that are not amenable tocomputation or straightforward analysis. Expert systems, also called knowledge-based systems, pattern recognition (image and voice), artificial neural networks,theorem proving, and game playing are representative of applications within thiscategory. 1.3S O F T WA R E : A C R I S I S O N T H E H O R I Z O N ?Many industry observers (including this author) have characterized the problemsassociated with software development as a "crisis." More than a few books (e.g.,[GLA97], [FLO97], [YOU98a]) have recounted the impact of some of the more spec-tacular software failures that have occurred over the past decade. Yet, the great suc-The most likely waycesses achieved by the software industry have led many to question whether the term for the world to besoftware crisis is still appropriate. Robert Glass, the author of a number of books on destroyed, mostsoftware failures, is representative of those who have had a change of heart. He states experts agree, is by accident. Thats [GLA98]: I look at my failure stories and see exception reporting, spectacular fail- where we come in;ures in the midst of many successes, a cup that is [now] nearly full. were computer It is true that software people succeed more often than they fail. It also true that professionals. Wethe software crisis predicted 30 years ago never seemed to materialize. What we cause accidents.really have may be something rather different. Nathaniel Borenstein The word crisis is dened in Websters Dictionary as a turning point in the course ofanything; decisive or crucial time, stage or event. Yet, in terms of overall software qual-ity and the speed with which computer-based systems and products are developed,there has been no "turning point," no "decisive time," only slow, evolutionary change,punctuated by explosive technological changes in disciplines associated with software.The word crisis has another denition: "the turning point in the course of a disease,when it becomes clear whether the patient will live or die." This denition may give usa clue about the real nature of the problems that have plagued software development.What we really have might be better characterized as a chronic affliction.2 Theword afiction is dened as "anything causing pain or distress." But the denition ofthe adjective chronic is the key to our argument: "lasting a long time or recurringoften; continuing indenitely." It is far more accurate to describe the problems wehave endured in the software business as a chronic afiction than a crisis.Regardless of what we call it, the set of problems that are encountered in the devel-opment of computer software is not limited to software that "doesnt function2 This terminology was suggested by Professor Daniel Tiechrow of the University of Michigan in atalk presented in Geneva, Switzerland, April 1989. 39. 12PA R T O N ETHE PRODUCT AND THE PROCESSproperly." Rather, the affliction encompasses problems associated with how wedevelop software, how we support a growing volume of existing software, and howwe can expect to keep pace with a growing demand for more software.We live with this afiction to this dayin fact, the industry prospers in spite of it.And yet, things would be much better if we could nd and broadly apply a cure. 1.4S O F T WA R E M Y T H SMany causes of a software afiction can be traced to a mythology that arose duringthe early history of software development. Unlike ancient myths that often providehuman lessons well worth heeding, software myths propagated misinformation andIn the absence ofconfusion. Software myths had a number of attributes that made them insidious; formeaningful standards,a new industry like instance, they appeared to be reasonable statements of fact (sometimes containingsoftware comes to elements of truth), they had an intuitive feel, and they were often promulgated bydepend instead onexperienced practitioners who "knew the score."folklore.Today, most knowledgeable professionals recognize myths for what they areTom DeMarcomisleading attitudes that have caused serious problems for managers and technicalpeople alike. However, old attitudes and habits are difcult to modify, and remnantsof software myths are still believed.Management myths. Managers with software responsibility, like managers in mostdisciplines, are often under pressure to maintain budgets, keep schedules from slip-ping, and improve quality. Like a drowning person who grasps at a straw, a softwaremanager often grasps at belief in a software myth, if that belief will lessen the pres-sure (even temporarily).Myth:We already have a book thats full of standards and procedures for buildingsoftware, wont that provide my people with everything they need to know?Reality:The book of standards may very well exist, but is it used? Are softwarepractitioners aware of its existence? Does it reect modern software engineering prac-tice? Is it complete? Is it streamlined to improve time to delivery while still main-taining a focus on quality? In many cases, the answer to all of these questions is "no."Myth:My people have state-of-the-art software development tools, after all, webuy them the newest computers.Reality:It takes much more than the latest model mainframe, workstation, or PCto do high-quality software development. Computer-aided software engineering(CASE) tools are more important than hardware for achieving good quality and pro-ductivity, yet the majority of software developers still do not use them effectively.Myth:If we get behind schedule, we can add more programmers and catch up(sometimes called the Mongolian horde concept).Reality:Software development is not a mechanistic process like manufacturing.In the words of Brooks [BRO75]: "adding people to a late software project makes it 40. CHAPTER 1 THE PRODUCT 13later." At rst, this statement may seem counterintuitive. However, as new peopleare added, people who were working must spend time educating the newcomers,thereby reducing the amount of time spent on productive development effort. Peo-The Software Projectple can be added but only in a planned and well-coordinated manner.Managers Network atMyth:If I decide to outsource3 the software project to a third party, I can just relaxwww.spmn.com canhelp you dispel these and and let that rm build it.other myths.Reality: If an organization does not understand how to manage and control softwareprojects internally, it will invariably struggle when it outsources software projects.Customer myths. A customer who requests computer software may be a personat the next desk, a technical group down the hall, the marketing/sales department,or an outside company that has requested software under contract. In many cases,the customer believes myths about software because software managers and prac-titioners do little to correct misinformation. Myths lead to false expectations (by thecustomer) and ultimately, dissatisfaction with the developer.Myth:A general statement of objectives is sufcient to begin writing programswe can ll in the details later.Work very hard toReality: A poor up-front denition is the major cause of failed software efforts. Aunderstand what youhave to do before you formal and detailed description of the information domain, function, behavior, per-start. You may not be formance, interfaces, design constraints, and validation criteria is essential. Theseable to develop every characteristics can be determined only after thorough communication between cus-detail, but the moretomer and developer.you know, the less riskyou take. Myth:Project requirements continually change, but change can be easily accom-modated because software is exible.Reality: It is true that software requirements change, but the impact of changevaries with the time at which it is introduced. Figure 1.3 illustrates the impact ofchange. If serious attention is given to up-front denition, early requests for changecan be accommodated easily. The customer can review requirements and recom- XRef mend modications with relatively little impact on cost. When changes are requested The management and during software design, the cost impact grows rapidly. Resources have been com- control of change is mitted and a design framework has been established. Change can cause upheaval considered in detail in Chapter 9. that requires additional resources and major design modication, that is, additionalcost. Changes in function, performance, interface, or other characteristics duringimplementation (code and test) have a severe impact on cost. Change, when requestedafter software is in production, can be over an order of magnitude more expensivethan the same change requested earlier.3 The term outsourcing refers to the widespread practice of contracting software developmentwork to a third partyusually a consulting rm that specializes in building custom software forits clients. 41. 14PA R T O N E THE PRODUCT AND THE PROCESSF I G U R E 1.3 60100The impact ofchangeCost to change1.56 1DefinitionDevelopment After releasePractitioners myths. Myths that are still believed by software practitioners havebeen fostered by 50 years of programming culture. During the early days of software,programming was viewed as an art form. Old ways and attitudes die hard.Myth:Once we write the program and get it to work, our job is done.Reality: Someone once said that "the sooner you begin writing code, the longeritll take you to get done." Industry data ([LIE80], [JON91], [PUT97]) indicate thatbetween 60 and 80 percent of all effort expended on software will be expended afterit is delivered to the customer for the rst time.Myth:Until I get the program "running" I have no way of assessing its quality.Reality: One of the most effective software quality assurance mechanisms can beWhenever you think,applied from the inception of a projectthe formal technical review. Software reviewswe dont have time forsoftware engineering(described in Chapter 8) are a "quality lter" that have been found to be more effec-discipline, ask yourself: tive than testing for nding certain classes of software defects.Will we have time toMyth:The only deliverable work product for a successful project is the workingdo it over again?program.Reality: A working program is only one part of a software conguration that includesmany elements. Documentation provides a foundation for successful engineeringand, more important, guidance for software support.Myth:Software engineering will make us create voluminous and unnecessary doc-umentation and will invariably slow us down.Reality: Software engineering is not about creating documents. It is about creat-ing quality. Better quality leads to reduced rework. And reduced rework results infaster delivery times. Many software professionals recognize the fallacy of the myths just described. Regret-tably, habitual attitudes and methods foster poor management and technical practices,even when reality dictates a better approach. Recognition of software realities is therst step toward formulation of practical solutions for software engineering. 42. CHAPTER 1 THE PRODUCT 151.5 SUMMARYSoftware has become the key element in the evolution of computer-based systemsand products. Over the past 50 years, software has evolved from a specialized prob-lem solving and information analysis tool to an industry in itself. But early pro-gramming culture and history have created a set of problems that persist today.Software has become the limiting factor in the continuing evolution of computer-based systems. Software is composed of programs, data, and documents. Each ofthese items comprises a conguration that is created as part of the software engi-neering process. The intent of software engineering is to provide a framework forbuilding software with higher quality.REFERENCES[BRO75] Brooks, F., The Mythical Man-Month, Addison-Wesley, 1975.[DEJ98] De Jager, P. et al., Countdown Y2K: Business Survival Planning for the Year2000, Wiley, 1998.[DEM95] DeMarco, T., Why Does Software Cost So Much? Dorset House, 1995, p. 9.[FEI83] Feigenbaum, E.A. and P. McCorduck, The Fifth Generation, Addison-Wesley, 1983.[FLO97] Flowers, S., Software Failure, Management FailureAmazing Stories andCautionary Tales, Wiley, 1997.[GLA97] Glass, R.L., Software Runaways, Prentice-Hall, 1997.[GLA98] Glass, R.L., Is There Really a Software Crisis? IEEE Software, vol. 15,no. 1, January 1998, pp. 104105.[HAM93] Hammer, M., and J. Champy, Reengineering the Corporation, HarperCollinsPublishers, 1993.[JON91] Jones, C., Applied Software Measurement, McGraw-Hill, 1991.[KAR99] Karlson, E. and J. Kolber, A Basic Introduction to Y2K: How the Year 2000Computer Crisis Affects YOU, Next Era Publications, 1999.[LEV95] Levy, S., The Luddites Are Back, Newsweek, July 12, 1995, p. 55.[LEV99] Levy, S., The New Digital Galaxy, Newsweek, May 31, 1999, p. 57.[LIE80] Lientz, B. and E. Swanson, Software Maintenance Management, Addison-Wesley, 1980.[NAI82] Naisbitt, J., Megatrends, Warner Books, 1982.[NOR98] Norman, D., The Invisible Computer, MIT Press, 1998.[OSB79] Osborne, A., Running WildThe Next Industrial Revolution,Osborne/McGraw-Hill, 1979.[PUT97] Putnam, L. and W. Myers, Industrial Strength Software, IEEE ComputerSociety Press, 1997.[STO89] Stoll, C., The Cuckoos Egg, Doubleday, 1989.[TOF80] Tofer, A., The Third Wave, Morrow, 1980. 43. 16 PA R T O N E THE PRODUCT AND THE PROCESS [TOF90] Tofer, A., Powershift, Bantam Publishers, 1990. [YOU92] Yourdon, E., The Decline and Fall of the American Programmer, Yourdon Press, 1992. [YOU96] Yourdon, E., The Rise and Resurrection of the American Programmer, Your- don Press, 1996. [YOU98a] Yourdon, E., Death March Projects, Prentice-Hall, 1998. [YOU98b] Yourdon, E. and J. Yourdon, Time Bomb 2000, Prentice-Hall, 1998. PROBLEMS AND POINTS TO PONDER 1.1. Software is the differentiating characteristic in many computer-based products and systems. Provide examples of two or three products and at least one system in which software, not hardware, is the differentiating element. 1.2. In the 1950s and 1960s, computer programming was an art form learned in an apprenticelike environment. How have the early days affected software development practices today? 1.3. Many authors have discussed the impact of the "information era." Provide a number of examples (both positive and negative) that indicate the impact of software on our society. Review one of the pre-1990 references in Section 1.1 and indicate where the authors predictions were right and where they were wrong. 1.4. Choose a specic application and indicate: (a) the software application category (Section 1.2.2) into which it ts; (b) the data content associated with the application; and (c) the information determinacy of the application. 1.5. As software becomes more pervasive, risks to the public (due to faulty pro- grams) become an increasingly significant concern. Develop a realistic doomsday scenario (other than Y2K) where the failure of a computer program could do great harm (either economic or human). 1.6. Peruse the Internet newsgroup comp.risks and prepare a summary of risks to the public that have recently been discussed. An alternate source is Software Engi- neering Notes published by the ACM. 1.7. Write a paper summarizing recent advances in one of the leading edge soft- ware application areas. Potential choices include: advanced Web-based applications, virtual reality, articial neural networks, advanced human interfaces, intelligent agents. 1.8. The myths noted in Section 1.4 are slowly fading as the years pass, but oth- ers are taking their place. Attempt to add one or two new myths to each category. 44. CHAPTER 1 THE PRODUCT 17F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E SLiterally thousands of books are written about computer software. The vast major-ity discuss programming languages or software applications, but a few discuss soft-ware itself. Pressman and Herron (Software Shock, Dorset House, 1991) presented anearly discussion (directed at the layperson) of software and the way professionalsbuild it. Negropontes (Being Digital, Alfred A. Knopf, 1995) best-selling book provides aview of computing and its overall impact in the twenty-rst century. Books by Nor-man [NOR98] and Bergman (Information Appliances and Beyond, Academic Press/Mor-gan Kaufmann, 2000) suggest that the widespread impact of the PC will decline asinformation appliances and pervasive computing connect everyone in the indus-trialized world and almost every appliance that they own to a new Internetinfrastructure. Minasi (The Software Conspiracy: Why Software Companies Put out Faulty Products,How They Can Hurt You, and What You Can Do, McGraw-Hill, 2000) argues that themodern scourge of software bugs can be eliminated and suggests ways to accom-plish this. DeMarco (Why Does Software Cost So Much? Dorset House, 1995) has pro-duced a collection of amusing and insightful essays on software and the processthrough which it is developed. A wide variety of information sources on software-related topics and manage-ment is available on the Internet. An up-to-date list of World Wide Web referencesthat are relevant to software can be found at the SEPA Web site:http://www.mhhe.com/engcs/compsci/pressman/resources/product.mhtml 45. CHAPTER 2THE PROCESSKEYIn a fascinating book that provides an economists view of software and soft-CONCEPTSware engineering, Howard Baetjer, Jr. [BAE98], comments on the softwarecommon processprocess:framework . . . . . . 23component-basedBecause software, like all capital, is embodied knowledge, and because that knowl-development. . . . . 42edge is initially dispersed, tacit, latent, and incomplete in large measure, softwareconcurrentdevelopment. . . . . 40 development is a social learning process. The process is a dialogue in which theknowledge that must become the software is brought together and embodied in theevolutionary processmodels. . . . . . . . . . 34software. The process provides interaction between users and designers, betweenformal methods . . 43 users and evolving tools, and between designers and evolving tools [technology]. Itis an iterative process in which the evolving tool itself serves as the medium for com-4GT . . . . . . . . . . . . 44munication, with each new round of the dialogue eliciting more useful knowledgemaintenancefrom the people involved.activities . . . . . . . 21process maturitylevels. . . . . . . . . . . 24 Indeed, building computer software is an iterative learning process, and theprototyping . . . . . 30outcome, something that Baetjer would call software capital, is an embodi-ment of knowledge collected, distilled, and organized as the process is con-RAD. . . . . . . . . . . . 32ducted.softwareengineering. . . . . . 20QUICKWhat is it? When you build abuilding. One process might be appropriate forLOOK product or system, its important creating software for an aircraft avionics system, to go through a series of pre-while an entirely different process would be indi- dictable stepsa road map that helps you create cated for the creation of a Web site. a timely, high-quality result. The road map that What is the work product? From the point of view you follow is called a software process.of a software engineer, the work products are the Who does it? Software engineers and their man-programs, documents, and data produced as a agers adapt the process to their needs and then consequence of the software engineering activi- follow it. In addition, the people who have ties dened by the process. requested the software play a role in the software How do I ensure that Ive done it right? A number of process.software process assessment mechanisms enable Why is it important? Because it provides stability, organizations to determine the maturity of a control, and organization to an activity that can,software process. However, the quality, timeliness, if left uncontrolled, become quite chaotic. and long-term viability of the product you build What are the steps? At a detailed level, the processare the best indicators of the efcacy of the process that you adopt depends on the software youre that you use. 19 46. 20PA R T O N E THE PRODUCT AND THE PROCESSBut what exactly is a software process from a technical point of view? Within thecontext of this book, we dene a software process as a framework for the tasks thatare required to build high-quality software. Is process synonymous with software engi-neering? The answer is yes and no. A software process denes the approach thatis taken as software is engineered. But software engineering also encompasses tech-nologies that populate the processtechnical methods and automated tools.More important, software engineering is performed by creative, knowledgeablepeople who should work within a dened and mature software process that is appro-priate for the products they build and the demands of their marketplace. The intentof this chapter is to provide a survey of the current state of the software process andpointers to more detailed discussion of management and technical topics presentedlater in this book.2.1 S O F T WA R E E N G I N E E R I N G : A L AY E R E D T E C H N O L O G YAlthough hundreds of authors have developed personal denitions of software engi-neering, a denition proposed by Fritz Bauer [NAU69] at the seminal conference onMore than athe subject still serves as a basis for discussion: discipline or a body of knowledge,[Software engineering is] the establishment and use of sound