1. Software EngineeringA P R A C T I T I O N E R S A P P R O A C H

2. McGraw-Hill Series in Computer ScienceSenior Consulting EditorC. L. Liu, National Tsing HuaUniversityConsulting EditorAllen B. Tucker, BowdoinCollegeFundamentals of Computingand ProgrammingComputer Organization andArchitectureSystems and LanguagesTheoretical FoundationsSoftware Engineering andDatabasesArtificial IntelligenceNetworks, Parallel andDistributed ComputingGraphics and VisualizationThe MIT Electrical andComputer Science SeriesSoftware Engineering andDatabasesAtzeni, Ceri, Paraborschi,and Torlone,Database Systems, 1/eMitchell, MachineLearning, 1/eMusa, Iannino,and Okumoto,Software Reliability, 1/ePressman, SoftwareEngineering: A BeginnersGuide, 1/ePressman, SoftwareEngineering: A PractionersGuide, 5/eRamakrishnan/Gehrke,Database ManagementSystems, 2/eSchach, Classical and Object-Oriented SoftwareEngineering with UMLand C++, 4/eSchach, Classical and Object-Oriented SoftwareEngineering with UML andJava, 1/e 3. Software EngineeringA P R A C T I T I O N E R S A P P R O A C HFIFTH EDITIONRoger S. Pressman, Ph.D.Boston Burr Ridge, IL Dubuque, IA Madison, WINew York San Francisco St. LouisBangkok Bogot Caracas Lisbon London Madrid Mexico CityMilan New Delhi Seoul Singapore Sydney Taipei Toronto 4. McGraw-Hill Higher EducationA 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-31. Software engineering. I. Title. II. Series.QA76.758.P75 2001005.1dc2100-036133http://www.mhhe.com 5. To my parents 6. viABOUT THE AUTHORRoger S. Pressman is an internationally recognized authority in software processimprovement and software engineering technologies. For over three decades, he hasworked as a software engineer, a manager, a professor, an author, and a consultant, focus-ingon software engineering issues.As an industry practitioner and manager, Dr. Pressman worked on the development ofCAD/CAM systems for advanced engineering and manufacturing applications. He has alsoheld positions with responsibility for scientific and systems programming.After receiving a Ph.D. in engineering from the University of Connecticut, Dr. Pressmanmoved to academia where he became Bullard Associate Professor of Computer Engineeringat the University of Bridgeport and director of the university's Computer-Aided Design andManufacturing Center.Dr. Pressman is currently president of R.S. Pressman & Associates, Inc., a consultingfirm specializing in software engineering methods and training. He serves as principle con-sultant,helping companies establish effective software engineering practices. He alsodesigned and developed the companys software engineering training and process improve-mentproductsEssential Software Engineering, a complete video curriculum that is amongthe industry's most comprehensive treatments of the subject, and Process Advisor, a self-directedsystem for software engineering process improvement. Both products are usedby hundreds of companies worldwide.Dr. Pressman has written many technical papers, is a regular contributor to industryperiodicals, and is author of six books. In addition to Software Engineering: A Practitioner'sApproach, he has written A Manager's Guide to Software Engineering (McGraw-Hill), anaward-winning book that uses a unique Q&A format to present management guidelinesfor instituting and understanding software engineering technology; Making Software Engi-neeringHappen (Prentice-Hall), the first book to address the critical management problemsassociated with software process improvement; and Software Shock (Dorset House), a treat-mentthat focuses on software and its impact on business and society. Dr. Pressman is onthe Editorial Boards of IEEE Software and the Cutter IT Journal, and for many years, waseditor 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-ingand at many other industry meetings. He is a member of the ACM, IEEE, and Tau BetaPi, Phi Kappa Phi, Eta Kappa Nu, and Pi Tau Sigma. 7. viiPreface xxvCONTENTS AT A GLANCEPART ONE The Product and the Process 1CHAPTER 1 The Product 3CHAPTER 2 The Process 19PART TWO Managing Software Projects 53CHAPTER 3 Project Management Concepts 55CHAPTER 4 Software Process and Project Metrics 79CHAPTER 5 Software Project Planning 113CHAPTER 6 Risk Analysis and Management 145CHAPTER 7 Project Scheduling and Tracking 165CHAPTER 8 Software Quality Assurance 193CHAPTER 9 Software Configuration Management 225PART THREE Conventional Methods for Software Engineering 243CHAPTER 10 System Engineering 245CHAPTER 11 Analysis Concepts and Principles 271CHAPTER 12 Analysis Modeling 299CHAPTER 13 Design Concepts and Principles 335CHAPTER 14 Architectural Design 365CHAPTER 15 User Interface Design 401CHAPTER 16 Component-Level Design 423CHAPTER 17 Software Testing Techniques 437CHAPTER 18 Software Testing Strategies 477CHAPTER 19 Technical Metrics for Software 507PART FOUR Object-Oriented Software Engineering 539CHAPTER 20 Object-Oriented Concepts and Principles 541CHAPTER 21 Object-Oriented Analysis 571CHAPTER 22 Object-Oriented Design 603 8. viii CONTENTS AT A GLANCECHAPTER 23 Object-Oriented Testing 631CHAPTER 24 Technical Metrics for Object-Oriented Systems 653PART FIVE Advanced Topics in Software Engineering 671CHAPTER 25 Formal Methods 673CHAPTER 26 Cleanroom Software Engineering 699CHAPTER 27 Component-Based Software Engineering 721CHAPTER 28 Client/Server Software Engineering 747CHAPTER 29 Web Engineering 769CHAPTER 30 Reengineering 799CHAPTER 31 Computer-Aided Software Engineering 825CHAPTER 32 The Road Ahead 845 9. ixTABLE OF CONTENTSPART ONETHE PRODUCT AND THE PROCESS 1CHAPTER 1 THE PRODUCT 31.1 The Evolving Role of Software 41.2 Software 61.2.1 Software Characteristics 61.2.2 Software Applications 91.3 Software: A Crisis on the Horizon? 111.4 Software Myths 121.5 Summary 15REFERENCES 15PROBLEMS AND POINTS TO PONDER 16FURTHER READINGS AND INFORMATION SOURCES 17CHAPTER 2 THE PROCESS 192.1 Software Engineering: A Layered Technology 202.1.1 Process, Methods, and Tools 202.1.2 A Generic View of Software Engineering 212.2 The Software Process 232.3 Software Process Models 262.4 The Linear Sequential Model 282.5 The Prototyping Model 302.6 The RAD Model 322.7 Evolutionary Software Process Models 342.7.1 The Incremental Model 352.7.2 The Spiral Model 362.7.3 The WINWIN Spiral Model 382.7.4 The Concurrent Development Model 402.8 Component-Based Development 422.9 The 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 50 10. x CONTENTSPART TWOMANAGING SOFTWARE PROJECTS 53CHAPTER 3 PROJECT MANAGEMENT CONCEPTS 553.1 The Management Spectrum 563.1.1 The People 563.1.2 The Product 573.1.2 The Process 573.1.3 The Project 573.2 People 583.2.1 The Players 583.2.2 Team Leaders 593.2.3 The Software Team 603.2.4 Coordination and Communication Issues 653.3 The Product 673.3.1 Software Scope 673.3.2 Problem Decomposition 673.4 The Process 683.4.1 Melding the Product and the Process 693.4.2 Process Decomposition 703.5 The Project 713.6 The W5HH Principle 733.7 Critical Practices 743.8 Summary 74REFERENCES 75PROBLEMS AND POINTS TO PONDER 76FURTHER READINGS AND INFORMATION SOURCES 77CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 794.1 Measures, Metrics, and Indicators 804.2 Metrics in the Process and Project Domains 814.2.1 Process Metrics and Software Process Improvement 824.2.2 Project Metrics 864.3 Software Measurement 874.3.1 Size-Oriented Metrics 884.3.2 Function-Oriented Metrics 894.3.3 Extended Function Point Metrics 914.4 Reconciling Different Metrics Approaches 944.5 Metrics for Software Quality 954.5.1 An Overview of Factors That Affect Quality 954.5.2 Measuring Quality 964.5.3 Defect Removal Efficiency 984.6 Integrating Metrics Within the Software Engineering Process 984.6.1 Arguments for Software Metrics 994.6.2 Establishing a Baseline 1004.6.3 Metrics Collection, Computation, and Evaluation 1004.7 Managing Variation: Statistical Quality Control 1004.8 Metrics for Small Organizations 1044.9 Establishing a Software Metrics Program 1054.10 Summary 107REFERENCES 107 11. CONTENTS xiPROBLEMS AND POINTS TO PONDER 109FURTHER READINGS AND INFORMATION SOURCES 110CHAPTER 5 SOFTWARE PROJECT PLANNING 1135.1 Observations on Estimating 1145.2 Project Planning Objectives 1155.3 Software Scope 1155.3.1 Obtaining Information Necessary for Scope 1165.3.2 Feasibility 1175.3.3 A Scoping Example 1185.4 Resources 1205.4.1 Human Resources 1215.4.2 Reusable Software Resources 1215.4.3 Environmental Resources 1225.5 Software Project Estimation 1235.6 Decomposition Techniques 1245.6.1 Software Sizing 1245.6.2 Problem-Based Estimation 1265.6.3 An Example of LOC-Based Estimation 1285.6.4 An Example of FP-Based Estimation 1295.6.4 Process-Based Estimation 1305.6.5 An Example of Process-Based Estimation 1315.7 Empirical Estimation Models 1325.7.1 The Structure of Estimation Models 1325.7.2 The COCOMO Model 1335.7.3 The Software Equation 1355.8 The Make/Buy Decision 1365.8.1 Creating a Decision Tree 1375.8.2 Outsourcing 1385.9 Automated Estimation Tools 1395.10 Summary 140REFERENCES 140PROBLEMS AND POINTS TO PONDER 141FURTHER READINGS AND INFORMATION SOURCES 142CHAPTER 6 RISK ANALYSIS AND MANAGEMENT 1456.1 Reactive versus Proactive Risk Strategies 1466.2 Software Risks 1466.3 Risk Identification 1486.3.1 Assessing Overall Project Risk 1496.3.2 Risk Components and Drivers 1496.4 Risk Projection 1516.4.1 Developing a Risk Table 1516.4.2 Assessing Risk Impact 1536.4.3 Risk Assessment 1546.5 Risk Refinement 1566.6 Risk Mitigation, Monitoring, and Management 1566.7 Safety Risks and Hazards 1586.8 The RMMM Plan 1596.9 Summary 159REFERENCES 160 12. xii CONTENTSPROBLEMS AND POINTS TO PONDER 161FURTHER READINGS AND INFORMATION SOURCES 162CHAPTER 7 PROJECT SCHEDULING AND TRACKING 1657.1 Basic Concepts 1667.1.1 Comments on Lateness 1677.2.1 Basic Principles 1687.2 The Relationship Between People and Effort 1707.2.1 An Example 1707.2.2 An Empirical Relationship 1717.2.3 Effort Distribution 1727.3 Defining a Task Set for the Software Project 1727.3.1 Degree of Rigor 1737.3.2 Defining Adaptation Criteria 1747.3.3 Computing a Task Set Selector Value 1757.3.4 Interpreting the TSS Value and Selecting the Task Set 1767.4 Selecting Software Engineering Tasks 1777.5 Refinement of Major Tasks 1787.6 Defining a Task Network 1807.7 Scheduling 1817.7.1 Timeline Charts 1827.7.2 Tracking the Schedule 1857.8 Earned Value Analysis 1867.9 Error Tracking 1877.10 The Project Plan 1897.11 Summary 189REFERENCES 189PROBLEMS AND POINTS TO PONDER 190FURTHER READINGS AND INFORMATION SOURCES 192CHAPTER 8 SOFTWARE QUALITY ASSURANCE 1938.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 Amplification 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. CONTENTS xiii8.9 Mistake-Proofing for Software 2148.10 The ISO 9000 Quality Standards 2168.10.1 The ISO Approach to Quality Assurance Systems 2178.10.2 The ISO 9001 Standard 2178.11 The SQA Plan 2188.12 Summary 219REFERENCES 220PROBLEMS AND POINTS TO PONDER 221FURTHER READINGS AND INFORMATION SOURCES 222CHAPTER 9 SOFTWARE CONFIGURATION MANAGEMENT 2259.1 Software Configuration Management 2269.1.1 Baselines 2279.1.2 Software Configuration Items 2289.2 The SCM Process 2309.3 Identification of Objects in the Software Configuration 2309.4 Version Control 2329.5 Change Control 2349.6 Configuration Audit 2379.7 Status Reporting 2379.8 SCM Standards 2389.9 Summary 238REFERENCES 239PROBLEMS AND POINTS TO PONDER 239FURTHER READINGS AND INFORMATION SOURCES 240PART THREECONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 243CHAPTER 10 SYSTEM ENGINEERING 24510.1 Computer-Based Systems 24610.2 The System Engineering Hierarchy 24810.2.1 System Modeling 24910.2.2 System Simulation 25110.3 Business Process Engineering: An Overview 25110.4 Product Engineering: An Overview 25410.5 Requirements Engineering 25610.5.1 Requirements Elicitation 25610.5.2 Requirements Analysis and Negotiation 25810.5.3 Requirements Specification 25910.5.4 System Modeling 25910.5.5 Requirements Validation 26010.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 ANALYSIS CONCEPTS AND PRINCIPLES 27111.1 Requirements Analysis 27211.2 Requirements Elicitation for Software 27411.2.1 Initiating the Process 27411.2.2 Facilitated Application Specification Techniques 27511.2.3 Quality Function Deployment 27911.2.4 Use-Cases 28011.3 Analysis Principles 28211.3.1 The Information Domain 28311.3.2 Modeling 28511.3.3 Partitioning 28611.3.4 Essential and Implementation Views 28811.4 Software Prototyping 28911.4.1 Selecting the Prototyping Approach 28911.4.2 Prototyping Methods and Tools 29011.5 Specification 29111.5.1 Specification Principles 29111.5.2 Representation 29211.5.3 The Software Requirements Specification 29311.6 Specification Review 29411.7 Summary 294REFERENCES 295PROBLEMS AND POINTS TO PONDER 296FURTHER READINGS AND INFORMATION SOURCES 297CHAPTER 12 ANALYSIS MODELING 29912.1 A Brief History 30012.2 The Elements of the Analysis Model 30112.3 Data Modeling 30212.3.1 Data Objects, Attributes, and Relationships 30212.3.2 Cardinality and Modality 30512.3.3 Entity/Relationship Diagrams 30712.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 31512.5 Behavioral Modeling 31712.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 Specification 32512.6.5 The Process Specification 32712.7 The Data Dictionary 32812.8 Other Classical Analysis Methods 33012.9 Summary 331REFERENCES 331PROBLEMS AND POINTS TO PONDER 332FURTHER READINGS AND INFORMATION SOURCES 334 15. CONTENTS xvCHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 33513.1 Software Design and Software Engineering 33613.2 The Design Process 33813.2.1 Design and Software Quality 33813.2.2 The Evolution of Software Design 33913.3 Design Principles 34013.4 Design Concepts 34113.4.1 Abstraction 34213.4.2 Refinement 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 35113.5 Effective Modular Design 35213.5.1 Functional Independence 35213.5.2 Cohesion 35313.5.3 Coupling 35413.6 Design Heuristics for Effective Modularity 35513.7 The Design Model 35713.8 Design Documentation 35813.9 Summary 359REFERENCES 359PROBLEMS AND POINTS TO PONDER 361FURTHER READINGS AND INFORMATION SOURCES 362CHAPTER 14 ARCHITECTURAL DESIGN 36514.1 Software Architecture 36614.1.1 What Is Architecture? 36614.1.2 Why Is Architecture Important? 36714.2 Data Design 36814.2.1 Data Modeling, Data Structures, Databases, and the DataWarehouse 36814.2.2 Data Design at the Component Level 36914.3 Architectural Styles 37114.3.1 A Brief Taxonomy of Styles and Patterns 37114.3.2 Organization and Refinement 37414.4 Analyzing Alternative Architectural Designs 37514.4.1 An Architecture Trade-off Analysis Method 37514.4.2 Quantitative Guidance for Architectural Design 37614.4.3 Architectural Complexity 37814.5 Mapping Requirements into a Software Architecture 37814.5.1 Transform Flow 37914.5.2 Transaction Flow 38014.6 Transform Mapping 38014.6.1 An Example 38014.6.2 Design Steps 38114.7 Transaction Mapping 38914.7.1 An Example 39014.7.2 Design Steps 390 16. xvi CONTENTS14.8 Refining the Architectural Design 39414.9 Summary 395REFERENCES 396PROBLEMS AND POINTS TO PONDER 397FURTHER READINGS AND INFORMATION SOURCES 399CHAPTER 15 USER INTERFACE DESIGN 40115.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 40415.2 User Interface Design 40515.2.1 Interface Design Models 40515.2.2 The User Interface Design Process 40715.3 Task Analysis and Modeling 40815.4 Interface Design Activities 41015.4.1 Defining Interface Objects and Actions 41015.4.2 Design Issues 41315.5 Implementation Tools 41515.6 Design Evaluation 41615.7 Summary 418REFERENCES 418PROBLEMS AND POINTS TO PONDER 419FURTHER READINGS AND INFORMATION SOURCES 420CHAPTER 16 COMPONENT-LEVEL DESIGN 42316.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 43016.2 Comparison of Design Notation 43216.3 Summary 433REFERENCES 433PROBLEMS AND POINTS TO PONDER 434FURTHER READINGS AND INFORMATION SOURCES 435CHAPTER 17 SOFTWARE TESTING TECHNIQUES 43717.1 Software Testing Fundamentals 43817.1.1 Testing Objectives 43917.1.2 Testing Principles 43917.1.3 Testability 44017.2 Test Case Design 44317.3 White-Box Testing 44417.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 45217.5 Control Structure Testing 45417.5.1 Condition Testing 454 17. CONTENTS xvii17.5.2 Data Flow Testing 45617.5.3 Loop Testing 45817.6 Black-Box Testing 45917.6.1 Graph-Based Testing Methods 46017.6.2 Equivalence Partitioning 46317.6.3 Boundary Value Analysis 46517.6.4 Comparison Testing 46517.6.5 Orthogonal Array Testing 46617.7 Testing for Specialized Environments, Architectures, and Applications 46817.7.1 Testing GUIs 46917.7.2 Testing of Client/Server Architectures 46917.7.3 Testing Documentation and Help Facilities 46917.7.4 Testing for Real-Time Systems 47017.8 Summary 472REFERENCES 473PROBLEMS AND POINTS TO PONDER 474FURTHER READINGS AND INFORMATION SOURCES 475CHAPTER 18 SOFTWARE TESTING STRATEGIES 47718.1 A Strategic Approach to Software Testing 47818.1.1 Verification and Validation 47918.1.2 Organizing for Software Testing 47918.1.3 A Software Testing Strategy 48018.1.4 Criteria for Completion of Testing 48218.2 Strategic Issues 48418.3 Unit Testing 48518.3.1 Unit Test Considerations 48518.3.2 Unit Test Procedures 48718.4 Integration Testing 48818.4.1 Top-down Integration 48818.4.2 Bottom-up Integration 49018.4.3 Regression Testing 49118.4.4 Smoke Testing 49218.4.5 Comments on Integration Testing 49318.4.6 Integration Test Documentation 49418.5 Validation Testing 49518.5.1 Validation Test Criteria 49518.5.2 Configuration Review 49618.5.3 Alpha and Beta Testing 49618.6 System Testing 49618.6.1 Recovery Testing 49718.6.2 Security Testing 49718.6.3 Stress Testing 49818.6.4 Performance Testing 49818.7 The Art of Debugging 49918.7.1 The Debugging Process 49918.7.2 Psychological Considerations 50018.7.3 Debugging Approaches 50118.8 Summary 502REFERENCES 503PROBLEMS AND POINTS TO PONDER 504FURTHER READINGS AND INFORMATION SOURCES 505 18. xviii CONTENTSCHAPTER 19 TECHNICAL METRICS FOR SOFTWARE 50719.1 Software Quality 50819.1.1 McCalls Quality Factors 50919.1.2 FURPS 51119.1.3 ISO 9126 Quality Factors 51319.1.4 The Transition to a Quantitative View 51319.2 A Framework for Technical Software Metrics 51419.2.1 The Challenge of Technical Metrics 51419.2.2 Measurement Principles 51519.2.3 The Attributes of Effective Software Metrics 51619.3 Metrics for the Analysis Model 51719.3.1 Function-Based Metrics 51819.3.2 The Bang Metric 52019.3.3 Metrics for Specification Quality 52219.4 Metrics for the Design Model 52319.4.1 Architectural Design Metrics 52319.4.2 Component-Level Design Metrics 52619.4.3 Interface Design Metrics 53019.5 Metrics for Source Code 53119.6 Metrics for Testing 53219.7 Metrics for Maintenance 53319.8 Summary 534REFERENCES 534PROBLEMS AND POINTS TO PONDER 536FURTHER READING AND OTHER INFORMATION SOURCES 537PART FOUROBJECT-ORIENTED SOFTWARE ENGINEERING 539CHAPTER 20 OBJECT-ORIENTED CONCEPTS AND PRINCIPLES 54120.1 The Object-Oriented Paradigm 54220.2 Object-Oriented Concepts 54420.2.1 Classes and Objects 54620.2.2 Attributes 54720.2.3 Operations, Methods, and Services 54820.2.4 Messages 54820.2.5 Encapsulation, Inheritance, and Polymorphism 55020.3 Identifying the Elements of an Object Model 55320.3.1 Identifying Classes and Objects 55320.3.2 Specifying Attributes 55720.3.3 Defining Operations 55820.3.4 Finalizing the Object Definition 55920.4 Management of Object-Oriented Software Projects 56020.4.1 The Common Process Framework for OO 56020.4.2 OO Project Metrics and Estimation 56220.4.3 An OO Estimating and Scheduling Approach 56420.4.4 Tracking Progress for an OO Project 56520.5 Summary 566REFERENCES 566PROBLEMS AND POINTS TO PONDER 567FURTHER READINGS AND INFORMATION SOURCES 568 19. CONTENTS xixCHAPTER 21 OBJECT-ORIENTED ANALYSIS 57121.1 Object-Oriented Analysis 57221.1.1 Conventional vs. OO Approaches 57221.1.2 The OOA Landscape 57321.1.3 A Unified Approach to OOA 57521.2 Domain Analysis 57621.2.1 Reuse and Domain Analysis 57721.2.2 The Domain Analysis Process 57721.3 Generic Components of the OO Analysis Model 57921.4 The OOA Process 58121.4.1 Use-Cases 58121.4.2 Class-Responsibility-Collaborator Modeling 58221.4.3 Defining Structures and Hierarchies 58821.4.4 Defining Subjects and Subsystems 59021.5 The Object-Relationship Model 59121.6 The Object-Behavior Model 59421.6.1 Event Identification with Use-Cases 59421.6.2 State Representations 59521.7 Summary 598REFERENCES 599PROBLEMS AND POINTS TO PONDER 600FURTHER READINGS AND INFORMATION SOURCES 601CHAPTER 22 OBJECT-ORIENTED DESIGN 60322.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 Unified Approach to OOD 61022.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 61622.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 62122.4 Design Patterns 62422.4.1 Describing a Design Pattern 62422.4.2 Using Patterns in Design 62522.5 Object-Oriented Programming 62522.6 Summary 626REFERENCES 627PROBLEMS AND POINTS TO PONDER 628FURTHER READINGS AND INFORMATION SOURCES 629 20. xx CONTENTSCHAPTER 23 OBJECT-ORIENTED TESTING 63123.1 Broadening the View of Testing 63223.2 Testing OOA and OOD Models 63323.2.1 Correctness of OOA and OOD Models 63323.2.2 Consistency of OOA and OOD Models 63423.3 Object-Oriented Testing Strategies 63623.3.1 Unit Testing in the OO Context 63623.3.2 Integration Testing in the OO Context 63723.3.3 Validation Testing in an OO Context 63723.4 Test Case Design for OO Software 63723.4.1 The Test Case Design Implications of OO Concepts 63823.4.2 Applicability of Conventional Test Case DesignMethods 63823.4.3 Fault-Based Testing 63923.4.4 The Impact of OO Programming on Testing 64023.4.5 Test Cases and the Class Hierarchy 64123.4.6 Scenario-Based Test Design 64123.4.7 Testing Surface Structure and Deep Structure 64323.5 Testing Methods Applicable at the Class Level 64423.5.1 Random Testing for OO Classes 64423.5.2 Partition Testing at the Class Level 64423.6 Interclass Test Case Design 64523.6.1 Multiple Class Testing 64523.6.2 Tests Derived from Behavior Models 64723.7 Summary 648REFERENCES 649PROBLEMS AND POINTS TO PONDER 649FURTHER READINGS AND INFORMATION SOURCES 650CHAPTER 24 TECHNICAL METRICS FOR OBJECT-ORIENTEDSYSTEMS 65324.1 The Intent of Object-Oriented Metrics 65424.2 The Distinguishing Characteristics of Object-Oriented Metrics 65424.2.1 Localization 65524.2.2 Encapsulation 65524.2.3 Information Hiding 65524.2.4 Inheritance 65624.2.5 Abstraction 65624.3 Metrics for the OO Design Model 65624.4 Class-Oriented Metrics 65824.4.1 The CK Metrics Suite 65824.4.2 Metrics Proposed by Lorenz and Kidd 66124.4.3 The 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. CONTENTS xxiPART FIVEADVANCED TOPICS IN SOFTWARE ENGINEERING 671CHAPTER 25 FORMAL METHODS 67325.1 Basic Concepts 67425.1.1 Deficiencies of Less Formal Approaches 67525.1.2 Mathematics in Software Development 67625.1.3 Formal Methods Concepts 67725.2 Mathematical Preliminaries 68225.2.1 Sets and Constructive Specification 68325.2.2 Set Operators 68425.2.3 Logic Operators 68625.2.4 Sequences 68625.3 Applying Mathematical Notation for Formal Specification 68725.4 Formal Specification 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 697CHAPTER 26 CLEANROOM SOFTWARE ENGINEERING 69926.1 The Cleanroom Approach 70026.1.1 The Cleanroom Strategy 70126.1.2 What Makes Cleanroom Different? 70326.2 Functional Specification 70326.2.1 Black-Box Specification 70526.2.2 State-Box Specification 70526.2.3 Clear-Box Specification 70626.3 Cleanroom Design 70626.3.1 Design Refinement and Verification 70726.3.2 Advantages of Design Verification 71026.4 Cleanroom Testing 71226.4.1 Statistical Use Testing 71226.4.2 Certification 71426.5 Summary 714REFERENCES 715PROBLEMS AND POINTS TO PONDER 716FURTHER READINGS AND INFORMATION SOURCES 717CHAPTER 27 COMPONENT-BASED SOFTWARE ENGINEERING 72127.1 Engineering of Component-Based Systems 72227.2 The CBSE Process 72427.3 Domain Engineering 72527.3.1 The Domain Analysis Process 72627.3.2 Characterization Functions 72727.3.3 Structural Modeling and Structure Points 72827.4 Component-Based Development 73027.4.1 Component Qualification, Adaptation, andComposition 730 22. xxii CONTENTS27.4 2 Component Engineering 73427.4.3 Analysis and Design for Reuse 73427.5 Classifying and Retrieving Components 73527.5.1 Describing Reusable Components 73627.5.2 The Reuse Environment 73827.6 Economics of CBSE 73927.6.1 Impact on Quality, Productivity, and Cost 73927.6.2 Cost Analysis Using Structure Points 74127.6.3 Reuse Metrics 74127.7 Summary 742REFERENCES 743PROBLEMS AND POINTS TO PONDER 744FURTHER READINGS AND INFORMATION SOURCES 745CHAPTER 28 CLIENT/SERVER SOFTWARE ENGINEERING 74728.1 The Structure of Client/Server Systems 74828.1.1 Software Components for c/s Systems 75028.1.2 The Distribution of Software Components 75028.1.3 Guidelines for Distributing Application Subsystems 75228.1.4 Linking c/s Software Subsystems 75328.1.5 Middleware 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 75528.4.1 Architectural Design for Client/Server Systems 75628.4.2 Conventional Design Approaches for ApplicationSoftware 75728.4.3 Database Design 75828.4.4 An Overview of a Design Approach 75928.4.5 Process Design Iteration 76128.5 Testing Issues 76128.5.1 Overall c/s Testing Strategy 76228.5.2 c/s Testing Tactics 76328.6 Summary 764REFERENCES 764PROBLEMS AND POINTS TO PONDER 765FURTHER READINGS AND INFORMATION SOURCES 766CHAPTER 29 WEB ENGINEERING 76929.1 The Attributes of Web-Based Applications 77129.1.1 Quality Attributes 77329.1.2 The Technologies 77329.2 The WebE Process 77429.3 A Framework for WebE 77529.4 Formulating/Analyzing Web-Based Systems 77629.4.1 Formulation 77629.4.2 Analysis 77829.5 Design for Web-Based Applications 77929.5.1 Architectural Design 78029.5.2 Navigation Design 78329.5.3 Interface Design 785 23. CONTENTS xxiii29.6 Testing Web-Based Applications 78629.7 Management Issues 78729.7.1 The WebE Team 78829.7.2 Project Management 78929.7.3 SCM Issues for WebE 79229.8 Summary 794REFERENCES 795PROBLEMS AND POINTS TO PONDER 796FURTHER READINGS AND INFORMATION SOURCES 797CHAPTER 30 REENGINEERING 79930.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 80430.2 Software Reengineering 80430.2.1 Software Maintenance 80430.2.2 A Software Reengineering Process Model 80530.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 81230.4 Restructuring 81330.4.1 Code Restructuring 81430.4.2 Data Restructuring 81430.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 81830.6 The Economics of Reengineering 81930.7 Summary 820REFERENCES 820PROBLEMS AND POINTS TO PONDER 822FURTHER READINGS AND INFORMATION SOURCES 823CHAPTER 31 COMPUTER-AIDED SOFTWARE ENGINEERING 82531.1 What is CASE? 82631.2 Building Blocks for CASE 82631.3 A Taxonomy of CASE Tools 82831.4 Integrated CASE Environments 83331.5 The Integration Architecture 83431.6 The CASE Repository 83631.6.1 The Role of the Repository in I-CASE 83631.6.2 Features and Content 83731.7 Summary 841REFERENCES 842PROBLEMS AND POINTS TO PONDER 842FURTHER READINGS AND INFORMATION SOURCES 843 24. xxiv CONTENTSCHAPTER 32 THE ROAD AHEAD 84532.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. PREFACEWhen a computer software succeedswhen it meets the needs of the peoplewho use it, when it performs flawlessly 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 dissatisfied, when it is error prone, whenit is difficult 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 first edition of this book was written, software engineer-inghas 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-plinedapproach 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-tudeshave changed, progress has been made, but much remains to be done beforexxvthe discipline reaches full maturity.The fifth edition of Software Engineering: A Practitioner's Approach is intended toserve as a guide to a maturing engineering discipline. The fifth 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 first year graduate level. The formatand style of the fifth edition have undergone significant change, making the presen-tationmore reader-friendly and the content more easily accessible.The fifth edition is considerably more than a simple update. The book has beenrevised to accommodate the dramatic growth in the field 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 26. xxvi PREFACESepaWeb, can be found at http://www.mhhe.com/pressman. Designed to be usedin conjunction with the fifth edition of Software Engineering: A Practitioner's Approach,SepaWeb provides a broad array of software engineering resources that will benefitinstructors, students, and industry professionals.Like all Web sites, SepaWeb will evolve over time, but the following major con-tentareas will always be present: (1) a broad array of instructor resources includinga 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-lectionof tiny tools, a case study, and additional supplementary content; and (3) adetailed collection of professional resources including outlines (and samples of) soft-wareengineering documents and other work products, a useful set of software engi-neeringchecklists, a catalog of software engineering (CASE) tools, a comprehensivecollection of Web-based resources, and an adaptable process model that providesa 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 fifth edition have been organized into five parts. This hasbeen done to compartmentalize topics and assist instructors who may not have thetime 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-ducethe subject matter, and more important, to present concepts that will be nec-essaryfor later chapters. Part Two, Managing Software Projects, presents topics thatare relevant to those who plan, manage, and control a software development proj-ect.Part Three, Conventional Methods for Software Engineering, presents the clas-sicalanalysis, design, and testing methods that some view as the conventionalschool 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 EngineeringTopics, presents dedicated chapters that address formal methods, cleanroom soft-wareengineering, component-based software engineering, client/server softwareengineering, Web engineering, reengineering, and CASE.The five-part organization of the fifth edition enables an instructor to "cluster" top-icsbased on available time and student need. An entire one-term course can be builtaround one or more of the five parts. For example, a "design course" might empha-sizeonly Part Three or Part Four; a "methods course" might present selected chap-tersin Parts Three, Four, and Five. A "management course" would stress Parts Oneand Two. By organizing the fifth edition in this way, I attempted to provide an instruc-torwith a number of teaching options. SepaWeb can and should be used to supple-mentthe content that is chosen from the book.An Instructor's Guide for Software Engineering: A Practitioner's Approach is avail-ablefrom SepaWeb. The Instructor's Guide presents suggestions for conducting var- 27. PREFACE xxviiious types of software engineering courses, recommendations for a variety of soft-wareprojects 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-ingand 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 five 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-clesas 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-ingfield. 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-gogicalcontent.The content of the fifth edition of Software Engineering: A Practitioner's 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 filled me with more pride. And finally,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. xxviiiUSING THIS BOOKThe fifth edition of Software Engineering: A Practitioners Approach (SEPA) has beenredesigned to enhance your reading experience and to provide integrated links to theSEPA Web site, http://www.mhhe.com/pressman/. SepaWeb contains a wealth of usefulsupplementary 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 haveadopted SEPA for classroom use.A comprehensive video curriculum, Essential Software Engineering, is available to com-plementthis book. The video curriculum has been designed for industry training and hasbeen modularized to enable individual software engineering topics to be presented on anas-needed, when-needed basis. Further information on the video can be obtained by mail-ingthe request card at the back of this book.1Throughout the book, you will encounter marginal icons that should be interpreted inthe following manner:Used to emphasize animportant point in thebody of the text.Practical advice fromthe real world ofsoftware engineering.Where can Ifind the?answer?XRefProvides an importantcross reference withinthe book.The keypoint icon will help youto find important points quickly.The advice icon provides prag-maticguidance that can helpyou make the right decision oravoid common problems whilebuilding software.The question mark icon askscommon questions that areanswered in the body of thetext.The xref icon will point you toanother part of the book whereinformation relevant to the cur-rentdiscussion can be found.The quote icon presents inter-estingquotes that have rele-vanceto the topic at hand.The WebRef icon providesdirect pointers to importantsoftware engineering relatedWeb sites.The SepaWeb pointer indicatesthat further information aboutthe noted topic is available atthe SEPA Web site.The SepaWeb.checklists iconpoints you to detailed checkliststhat will help you to assess thesoftware engineering workyoure doing and the workproducts you produce.The SepaWeb.documentsicon points you to detailed doc-umentoutlines, descriptionsand examples contained withinthe SEPA Web site.Important wordsWebRefFor pointers that will takeyou directly to WebresourcesA selected topic1 If the card is missing, please visit the R.S. Pressman & Associates, Inc. Web site athttp://www.rspa.com/ese, or e-mail to info@rspa.com. 29. 1P A R TTHE PRODUCT ANDTHE PROCESSIn this part of Software Engineering: A Practitioners Approach, youlllearn about the product that is to be engineered and the processthat provides a framework for the engineering technology. Thefollowing questions are addressed in the chapters that follow: What is computer software . . . really? Why do we struggle to build high-quality computer-basedsystems? How can we categorize application domains for computersoftware? 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-wareengineering work?Once these questions are answered, youll be better prepared tounderstand the management and technical aspects of the engi-neeringdiscipline to which the remainder of this book is dedicated.One 30. 3CHAPTER1 THE PRODUCTKEYCONCEPTSapplicationcategories . . . . . . . 9component-basedassembly. . . . . . . . . 8failure curves . . . . . 8history . . . . . . . . . . 5myths . . . . . . . . . . 12reuse . . . . . . . . . . . . 9softwarecharacteristics . . . . 6softwareengineering . . . . . . 4wear . . . . . . . . . . . . 7The warnings began more than a decade before the event, but no one paidmuch attention. With less than two years to the deadline, the mediapicked up the story. Then government officials voiced their concern, busi-nessand industry leaders committed vast sums of money, and finally, dire warn-ingsof pending catastrophe penetrated the publics consciousness. Software,in the guise of the now-infamous Y2K bug, would fail and, as a result, stop theworld as we then knew it.As we watched and wondered during the waning months of 1999, I couldnthelp thinking of an unintentionally prophetic paragraph contained on the firstpage of the fourth edition of this book. It stated:Computer software has become a driving force. It is the engine that drives businessdecision making. It serves as the basis for modern scientific investigation and engi-neeringproblem solving. It is a key factor that differentiates modern products andservices. It is embedded in systems of all kinds: transportation, medical, telecom-munications,military, industrial processes, entertainment, office products, . . . thelist is almost endless. Software is virtually inescapable in a modern world. And aswe move into the twenty-first century, it will become the driver for new advances ineverything from elementary education to genetic engineering.What is it? Computer software isthe product that software engi-neersdesign and build. It encom-passesprograms that execute within a computerof any size and architecture, documents thatencompass hard-copy and virtual forms, anddata that combine numbers and text but alsoincludes representations of pictorial, video, andaudio information.Who does it? Software engineers build it, and virtu-allyeveryone in the industrialized world uses iteither directly or indirectly.Why is it important? Because it affects nearly everyaspect of our lives and has become pervasive inour commerce, our culture, and our everydayactivities.What are the steps? You build computer softwarelike you build any successful product, by apply-inga process that leads to a high-quality resultthat meets the needs of the people who will usethe product. You apply a software engineeringapproach.What is the work product? From the point of view ofa software engineer, the work product is the pro-grams,documents, and data that are computersoftware. But from the users viewpoint, the workproduct is the resultant information that somehowmakes the users world better.How do I ensure that Ive done it right? Read theremainder of this book, select those ideas appli-cableto the software that you build, and applythem to your work.QUICKLOOK 31. 4 PART ONE THE PRODUCT AND THE PROCESSIn the five years since the fourth edition of this book was written, the role of soft-wareas the driving force has become even more obvious. A software-driven Inter-nethas 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-nologiesthat will make it easier, faster, and less expensive to build high-quality com-puterprograms. Some of these technologies are targeted at a specific applicationdomain (e.g., Web-site design and implementation); others focus on a technologydomain (e.g., object-oriented systems); and still others are broad-based (e.g., oper-atingsystems such as LINUX). However, we have yet to develop a software technol-ogythat 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.1 THE EVOLVING ROLE OF SOFTWAREToday, software takes on a dual role. It is a product and, at the same time, the vehi-clefor delivering a product. As a product, it delivers the computing potential embod-iedby 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-ing,acquiring, modifying, displaying, or transmitting information that can be as sim-pleas a single bit or as complex as a multimedia presentation. As the vehicle usedto deliver the product, software acts as the basis for the control of the computer (oper-atingsystems), 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 financial 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 significant change over a time spanof little more than 50 years. Dramatic improvements in hardware performance, pro-Ideas andtechnologicaldiscoveries are thedriving engines ofeconomic growth.The Wall StreetJournalSoftware is both aproduct and a vehiclefor delivering aproduct. 32. CHAPTER 1 THE PRODUCTfound changes in computing architectures, vast increases in memory and storagecapacity, and a wide variety of exotic input and output options have all precipitatedmore sophisticated and complex computer-based systems. Sophistication and com-plexitycan produce dazzling results when a system succeeds, but they can also posehuge problems for those who must build complex systems.Popular books published during the 1970s and 1980s provide useful historicalinsight into the changing perception of computers and software and their impact onour culture. Osborne [OSB79] characterized a "new industrial revolution." Toffler[TOF80] called the advent of microelectronics part of "the third wave of change" inhuman history, and Naisbitt [NAI82] predicted a transformation from an industrialsociety to an "information society." Feigenbaum and McCorduck [FEI83] suggestedthat information and knowledge (controlled by computers) would be the focal pointfor power in the twenty-first century, and Stoll [STO89] argued that the "electroniccommunity" created by networks and software was the key to knowledge interchangethroughout the world.As the 1990s began, Toffler [TOF90] described a "power shift" in which old powerstructures (governmental, educational, industrial, economic, and military) disinte-grateas computers and software lead to a "democratization of knowledge." Yourdon[YOU92] worried that U.S. companies might loose their competitive edge in software-relatedbusinesses and predicted the decline and fall of the American programmer.Hammer and Champy [HAM93] argued that information technologies were to play apivotal role in the reengineering of the corporation. During the mid-1990s, the per-vasivenessof computers and software spawned a rash of books by neo-Luddites(e.g., Resisting the Virtual Life, edited by James Brook and Iain Boal and The FutureDoes Not Compute by Stephen Talbot). These authors demonized the computer, empha-sizinglegitimate concerns but ignoring the profound benefits that have already beenrealized. [LEV95]During the later 1990s, Yourdon [YOU96] re-evaluated the prospects for thesoftware professional and suggested the the rise and resurrection of the Ameri-canprogrammer. As the Internet grew in importance, his change of heart provedto be correct. As the twentieth century closed, the focus shifted once more, thistime to the impact of the Y2K time bomb (e.g., [YOU98b], [DEJ98], [KAR99]).Although the predictions of the Y2K doomsayers were incorrect, their popularwritings drove home the pervasiveness of software in our lives. Today, ubiquitouscomputing [NOR98] has spawned a generation of information appliances thathave broadband connectivity to the Web to provide a blanket of connectednessover our homes, offices and motorways [LEV99]. Softwares role continues toexpand.The lone programmer of an earlier era has been replaced by a team of softwarespecialists, each focusing on one part of the technology required to deliver a com-plexapplication. And yet, the same questions asked of the lone programmer are beingasked when modern computer-based systems are built:5For I dipped into thefuture, far as thehuman eye couldsee, Saw the visionof the world, and allthe wonder thatwould be.TennysonComputers make iteasy to do a lot ofthings, but most ofthe things that theymake it easier to dodon't need to bedone.Andy Rooney 33. 6 PART ONE THE PRODUCT AND THE PROCESS Why does it take so long to get software finished? Why are development costs so high? Why can't we find all the errors before we give the software to customers? Why do we continue to have difficulty in measuring progress as software isbeing developed?These, and many other questions,1 are a manifestation of the concern about soft-wareand the manner in which it is developeda concern that has lead to the adop-tionof software engineering practice.1.2 SOFTWAREIn 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-formance,(2) data structures that enable the programs to adequately manipulate infor-mation,and (3) documents that describe the operation and use of the programs. Thereis no question that other, more complete definitions could be offered. But we needmore than a formal definition.1.2.1 Software 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-latedinto 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.Although some similarities exist between software development and hardware man-ufacture,the two activities are fundamentally different. In both activities, high qual-How shouldwe define?software?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-ingWhat 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-guishedthe software industry.Software isengineered, notmanufactured. 34. CHAPTER 1 THE PRODUCT7Infant Wear outmortalityTimeFailure rateity 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-ectscannot be managed as if they were manufacturing projects.2. Software doesn't "wear out."Figure 1.1 depicts failure rate as a function of time for hardware. The relationship,often called the "bathtub curve," indicates that hardware exhibits relatively high fail-urerates early in its life (these failures are often attributable to design or manufac-turingdefects); 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-ducingother errors) and the curve flattens as shown.The idealized curve is a gross over-simplificationof actual failure models (see Chapter 8 for more information) for software.However, the implication is clearsoftware doesn't 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). AsFIGURE 1.1Failure curvefor hardwareSoftware doesnt wearout, but it doesdeteriorate. 35. 8 PART ONE THE PRODUCT AND THE PROCESSchanges are made, it is likely that some new defects will be introduced, causing thefailure rate curve to spike as shown in Figure 1.2. Before the curve can return to theoriginal 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, mostsoftware continues to be custom 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 defined and validatedfunction, a well-defined 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-sandsof 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, theFIGURE 1.2Idealized andactual failurecurves forsoftwareIncreased failurerate due to sideeffectsTimeFailure rateChangeActual curveIdealized curveSoftware engineeringmethods strive toreduce the magnitudeof the spikes and theslope of the actualcurve in Figure 1.2.Most softwarecontinues to becustom built. 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-thingthat 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 scientific subroutine librariesthat were reusable in a broad array of engineering and scientific applications. Thesesubroutine libraries reused well-defined algorithms in an effective manner but had alimited domain of application. Today, we have extended our view of reuse to encom-passnot only algorithms but also data structure. Modern reusable components encap-sulateboth data and the processing applied to the data, enabling the software engineerto create new applications from reusable parts. For example, today's 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.2 Software ApplicationsSoftware may be applied in any situation for which a prespecified set of proceduralsteps (i.e., an algorithm) has been defined (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-duceformatted 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 predefined order,executes the analysis algorithm(s) without interruption, and produces resultant datain report or graphical format. Such applications are determinate. A multiuser oper-atingsystem, on the other hand, accepts inputs that have varied content and arbi-trarytiming, 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 difficult 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 file manage-mentutilities) process complex, but determinate, information structures. Other sys-temsapplications (e.g., operating system components, drivers, telecommunicationsXRefSoftware reuse isdiscussed in Chapter13. Component-basedsoftware engineering ispresented in Chapter27. 37. 10 PART ONE THE PRODUCT AND THE PROCESSprocessors) process largely indeterminate data. In either case, the system softwarearea is characterized by heavy interaction with computer hardware; heavy usage bymultiple users; concurrent operation that requires scheduling, resource sharing, andsophisticated process management; complex data structures; and multiple externalinterfaces.Real-time software. Software that monitors/analyzes/controls real-world eventsas they occur is called real time. Elements of real-time software include a data gath-eringcomponent that collects and formats information from an external environ-ment,an analysis component that transforms information as required by theapplication, a control/output component that responds to the external environment,and a monitoring component that coordinates all other components so that real-timeresponse (typically ranging from 1 millisecond to 1 second) can be maintained.Business software. Business information processing is the largest single softwareapplication area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inven-tory)have evolved into management information system (MIS) software that accessesone or more large databases containing business information. Applications in thisarea restructure existing data in a way that facilitates business operations or man-agementdecision making. In addition to conventional data processing application,business software applications also encompass interactive computing (e.g., point-of-sale transaction processing).Engineering and scientific software. Engineering and scientific software havebeen characterized by "number crunching" algorithms. Applications range from astron-omyto volcanology, from automotive stress analysis to space shuttle orbital dynam-ics,and from molecular biology to automated manufacturing. However, modernapplications within the engineering/scientific area are moving away from conven-tionalnumerical algorithms. Computer-aided design, system simulation, and otherinteractive applications have begun to take on real-time and even system softwarecharacteristics.Embedded software. Intelligent products have become commonplace in nearlyevery consumer and industrial market. Embedded software resides in read-only mem-oryand 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., keypadcontrol for a microwave oven) or provide significant function and control capability(e.g., digital functions in an automobile such as fuel control, dashboard displays, andbraking systems).Personal computer software. The personal computer software market has bur-geonedover the past two decades. Word processing, spreadsheets, computer graph-ics,multimedia, entertainment, database management, personal and business financialapplications, external network, and database access are only a few of hundreds ofapplications.Web-based software. The Web pages retrieved by a browser are software thatincorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g.,One of the mostcomprehensive libraries ofshareware/freeware canbe found atwww.shareware.com 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-basedsystems, pattern recognition (image and voice), artificial neural networks,theorem proving, and game playing are representative of applications within thiscategory.1.3 SOFTWARE: A CRISIS ON THE HORIZON?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-tacularsoftware failures that have occurred over the past decade. Yet, the great suc-cessesachieved by the software industry have led many to question whether the termsoftware crisis is still appropriate. Robert Glass, the author of a number of books onsoftware failures, is representative of those who have had a change of heart. He states[GLA98]: I look at my failure stories and see exception reporting, spectacular fail-uresin the midst of many successes, a cup that is [now] nearly full.It is true that software people succeed more often than they fail. It also true thatthe software crisis predicted 30 years ago never seemed to materialize. What wereally have may be something rather different.The word crisis is defined in Webster's Dictionary as a turning point in the course ofanything; decisive or crucial time, stage or event. Yet, in terms of overall software qual-ityand 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 definition: "the turning point in the course of a disease,when it becomes clear whether the patient will live or die." This definition 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 affliction is defined as "anything causing pain or distress." But the definition ofthe adjective chronic is the key to our argument: "lasting a long time or recurringoften; continuing indefinitely." It is far more accurate to describe the problems wehave endured in the software business as a chronic affliction than a crisis.Regardless of what we call it, the set of problems that are encountered in the devel-opmentof computer software is not limited to software that "doesn't function2 This terminology was suggested by Professor Daniel Tiechrow of the University of Michigan in atalk presented in Geneva, Switzerland, April 1989.The most likely wayfor the world to bedestroyed, mostexperts agree, is byaccident. That'swhere we come in;we're computerprofessionals. Wecause accidents.NathanielBorenstein 39. 12 PART ONE THE 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 affliction to this dayin fact, the industry prospers in spite of it.And yet, things would be much better if we could find and broadly apply a cure.1.4 SOFTWARE MYTHSMany causes of a software affliction 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 andconfusion. Software myths had a number of attributes that made them insidious; forinstance, they appeared to be reasonable statements of fact (sometimes containingelements of truth), they had an intuitive feel, and they were often promulgated byexperienced practitioners who "knew the score."Today, most knowledgeable professionals recognize myths for what they aremisleading attitudes that have caused serious problems for managers and technicalpeople alike. However, old attitudes and habits are difficult 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 that's full of standards and procedures for buildingsoftware, won't 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 reflect modern software engineering prac-tice?Is it complete? Is it streamlined to improve time to delivery while still main-taininga 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 itIn the absence ofmeaningful standards,a new industry likesoftware comes todepend instead onfolklore.Tom DeMarco 40. CHAPTER 1 THE PRODUCT13later." At first, 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-plecan be added but only in a planned and well-coordinated manner.Myth: If I decide to outsource3 the software project to a third party, I can just relaxand let that firm build it.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-titionersdo little to correct misinformation. Myths lead to false expectations (by thecustomer) and ultimately, dissatisfaction with the developer.Myth: A general statement of objectives is sufficient to begin writing programswe can fill in the details later.Reality: A poor up-front definition is the major cause of failed software efforts. Aformal and detailed description of the information domain, function, behavior, per-formance,interfaces, design constraints, and validation criteria is essential. Thesecharacteristics can be determined only after thorough communication between cus-tomerand developer.Myth: Project requirements continually change, but change can be easily accom-modatedbecause software is flexible.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 definition, early requests for changecan be accommodated easily. The customer can review requirements and recom-mendmodifications with relatively little impact on cost. When changes are requestedduring software design, the cost impact grows rapidly. Resources have been com-mittedand a design framework has been established. Change can cause upheavalthat requires additional resources and major design modification, 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.The Software ProjectManagers Network atwww.spmn.com canhelp you dispel these andother myths.XRefThe management andcontrol of change isconsidered in detail inChapter 9.3 The term outsourcing refers to the widespread practice of contracting software developmentwork to a third partyusually a consulting firm that specializes in building custom software forits clients.Work very hard tounderstand what youhave to do before youstart. You may not beable to develop everydetail, but the moreyou know, the less riskyou take. 41. 14 PART ONE THE PRODUCT AND THE PROCESS1Definition1.56Development60100After releaseCost to changePractitioner's 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 longerit'll 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 first 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 beapplied from the inception of a projectthe formal technical review. Software reviews(described in Chapter 8) are a "quality filter" that have been found to be more effec-tivethan testing for finding certain classes of software defects.Myth: The only deliverable work product for a successful project is the workingprogram.Reality: A working program is only one part of a software configuration 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-umentationand will invariably slow us down.Reality: Software engineering is not about creating documents. It is about creat-ingquality. 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 thefirst step toward formulation of practical solutions for software engineering.FIGURE 1.3The impact ofchangeWhenever you think,we dont have time forsoftware engineeringdiscipline, ask yourself:Will we have time todo it over again? 42. CHAPTER 1 THE PRODUCT1.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-lemsolving and information analysis tool to an industry in itself. But early pro-grammingculture and history have created a set of problems that persist today.Software has become the limiting factor in the continuing evolution of computer-basedsystems. Software is composed of programs, data, and documents. Each ofthese items comprises a configuration that is created as part of the software engi-neeringprocess. 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 Cuckoo's Egg, Doubleday, 1989.[TOF80] Toffler, A., The Third Wave, Morrow, 1980.15 43. 16 PART ONE THE PRODUCT AND THE PROCESS[TOF90] Toffler, A., Powershift, Bantam Publishers, 1990.[YOU92] Yourdon, E., The Decline and Fall of the American Programmer, YourdonPress, 1992.[YOU96] Yourdon, E., The Rise and Resurrection of the American Programmer, Your-donPress, 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 PONDER1.1. Software is the differentiating characteristic in many computer-based productsand systems. Provide examples of two or three products and at least one system inwhich software, not hardware, is the differentiating element.1.2. In the 1950s and 1960s, computer programming was an art form learned in anapprenticelike environment. How have the early days affected software developmentpractices today?1.3. Many authors have discussed the impact of the "information era." Provide anumber of examples (both positive and negative) that indicate the impact of softwareon our society. Review one of the pre-1990 references in Section 1.1 and indicatewhere the authors predictions were right and where they were wrong.1.4. Choose a specific application and indicate: (a) the software application category(Section 1.2.2) into which it fits; (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 doomsdayscenario (other than Y2K) where the failure of a computer program could do greatharm (either economic or human).1.6. Peruse the Internet newsgroup comp.risks and prepare a summary of risks tothe public that have recently been discussed. An alternate source is Software Engi-neeringNotes published by the ACM.1.7. Write a paper summarizing recent advances in one of the leading edge soft-wareapplication areas. Potential choices include: advanced Web-based applications,virtual reality, artificial 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-ersare taking their place. Attempt to add one or two new myths to each category. 44. CHAPTER 1 THE PRODUCT17FURTHER READINGS AND INFORMATION SOURCESLiterally thousands of books are written about computer software. The vast major-itydiscuss programming languages or software applications, but a few discuss soft-wareitself. Pressman and Herron (Software Shock, Dorset House, 1991) presented anearly discussion (directed at the layperson) of software and the way professionalsbuild it.Negroponte's (Being Digital, Alfred A. Knopf, 1995) best-selling book provides aview of computing and its overall impact in the twenty-first century. Books by Nor-man[NOR98] and Bergman (Information Appliances and Beyond, Academic Press/Mor-ganKaufmann, 2000) suggest that the widespread impact of the PC will decline asinformation appliances and pervasive computing connect everyone in the indus-trializedworld 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-plishthis. DeMarco (Why Does Software Cost So Much? Dorset House, 1995) has pro-duceda 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-mentis 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. 19CHAPTER2 THE PROCESSKEYCONCEPTScommon processframework . . . . . . 23component-baseddevelopment. . . . . 42concurrentdevelopment. . . . . 40evolutionary processmodels. . . . . . . . . . 34formal methods . . 434GT . . . . . . . . . . . . 44maintenanceactivities . . . . . . . 21process maturitylevels. . . . . . . . . . . 24prototyping . . . . . 30RAD. . . . . . . . . . . . 32softwareengineering. . . . . . 20In a fascinating book that provides an economists view of software and soft-wareengineering, Howard Baetjer, Jr. [BAE98], comments on the softwareprocess:Because software, like all capital, is embodied knowledge, and because that knowl-edgeis initially dispersed, tacit, latent, and incomplete in large measure, softwaredevelopment is a social learning process. The process is a dialogue in which theknowledge that must become the software is brought together and embodied in thesoftware. The process provides interaction between users and designers, betweenusers 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-munication,with each new round of the dialogue eliciting more useful knowledgefrom the people involved.Indeed, building computer software is an iterative learning process, and theoutcome, something that Baetjer would call software capital, is an embodi-mentof knowledge collected, distilled, and organized as the process is con-ducted.What is it? When you build aproduct or system, its importantto go through a series of pre-dictablestepsa road map that helps you createa timely, high-quality result. The road map thatyou follow is called a software process.Who does it? Software engineers and their man-agersadapt the process to their needs and thenfollow it. In addition, the people who haverequested the software play a role in the softwareprocess.Why is it important? Because it provides stability,control, and organization to an activity that can,if left uncontrolled, become quite chaotic.What are the steps? At a detailed level, the processthat you adopt depends on the software yourebuilding. One process might be appropriate forcreating software for an aircraft avionics system,while an entirely different process would be indi-catedfor the creation of a Web site.What is the work product? From the point of viewof a software engineer, the work products are theprograms, documents, and data produced as aconsequence of the software engineering activi-tiesdefined by the process.How do I ensure that Ive done it right? A number ofsoftware process assessment mechanisms enableorganizations to determine the maturity of asoftware process. However, the quality, timeliness,and long-term viability of the product you buildare the best indicators of the efficacy of the processthat you use.QUICKLOOK 46. 20 PART ONE THE PRODUCT AND THE PROCESSBut what exactly is a software process from a technical point of view? Within thecontext of this book, we define 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 defines the approach thatis taken as software is engineered. But software engineering also encompasses tech-nologiesthat populate the processtechnical methods and automated tools.More important, software engineering is performed by creative, knowledgeablepeople who should work within a defined and mature software process that is appro-priatefor 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 SOFTWARE ENGINEERING: A LAYERED TECHNOLOGYAlthough hundreds of authors have developed personal definitions of software engi-neering,a definition proposed by Fritz Bauer [NAU69] at the seminal conference onthe subject still serves as a basis for discussion:[Software engineering is] the establishment and use of sound engineering principles inorder to obtain economically software that is reliable and works efficiently on real machines.Almost every reader will be tempted to add to this definition. It says little about thetechnical aspects of software quality; it does not directly address the need for cus-tomersatisfaction or timely product delivery; it omits mention of the importance ofmeasurement and metrics; it does not state the importance of a mature process. Andyet, Bauers definition provides us with a baseline. What sound engineering princi-plescan be applied to computer software development? How do we economicallybuild software so that it is reliable? What is required to create computer programsthat work efficiently on not one but many different real machines? These are thequestions that continue to challenge software engineers.The IEEE [IEE93] has developed a more comprehensive definition w