Software Engineering - Webs€¦ · CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 79 4.1 Measures,...

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

McGraw-Hill Series in Computer Science

Senior Consulting EditorC. L. Liu, National Tsing Hua

University

Consulting EditorAllen B. Tucker, Bowdoin

College

Fundamentals of Computingand Programming

Computer Organization andArchitecture

Systems and LanguagesTheoretical FoundationsSoftware Engineering and

DatabasesArtificial Intelligence

Networks, Parallel andDistributed Computing

Graphics and VisualizationThe MIT Electrical and

Computer Science Series

Software Engineering andDatabases

Atzeni, Ceri, Paraborschi, and Torlone, Database Systems, 1/e

Mitchell, Machine Learning, 1/e

Musa, Iannino, and Okumoto, Software Reliability, 1/e

Pressman, SoftwareEngineering: A Beginner’sGuide, 1/e

Pressman, SoftwareEngineering: A Practioner’sGuide, 5/e

Ramakrishnan/Gehrke,Database ManagementSystems, 2/e

Schach, Classical and Object-Oriented SoftwareEngineering with UML and C++, 4/e

Schach, Classical and Object-Oriented SoftwareEngineering with UML andJava, 1/e

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

FIFTH 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 CityMilan New Delhi Seoul Singapore Sydney Taipei Toronto

SOFTWARE 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 0

ISBN 0073655783

Publisher: 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 Company

Library of Congress Cataloging-in-Publication DataPressman, Roger S.

Software engineering: a practitioner’s 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.1—dc21

00-036133

http://www.mhhe.com

McGraw-Hill Higher EducationA Division of The McGraw-Hill Companies

To my parents

vi

R oger 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-

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 scientific 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 university's Computer-Aided Design and

Manufacturing Center.

Dr. Pressman is currently president of R.S. Pressman & Associates, Inc., a consulting

firm 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 company’s software engineering training and process improve-

ment products—Essential Software Engineering, a complete video curriculum that is among

the industry's 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 Practitioner's

Approach, he has written A Manager's 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 first 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.

ABOUT THE AUTHOR

vii

Preface xxv

PART ONE The Product and the Process 1

CHAPTER 1 The Product 3

CHAPTER 2 The Process 19

PART TWO Managing Software Projects 53

CHAPTER 3 Project Management Concepts 55

CHAPTER 4 Software Process and Project Metrics 79

CHAPTER 5 Software Project Planning 113

CHAPTER 6 Risk Analysis and Management 145

CHAPTER 7 Project Scheduling and Tracking 165

CHAPTER 8 Software Quality Assurance 193

CHAPTER 9 Software Configuration Management 225

PART THREE Conventional Methods for Software Engineering 243

CHAPTER 10 System Engineering 245

CHAPTER 11 Analysis Concepts and Principles 271

CHAPTER 12 Analysis Modeling 299

CHAPTER 13 Design Concepts and Principles 335

CHAPTER 14 Architectural Design 365

CHAPTER 15 User Interface Design 401

CHAPTER 16 Component-Level Design 423

CHAPTER 17 Software Testing Techniques 437

CHAPTER 18 Software Testing Strategies 477

CHAPTER 19 Technical Metrics for Software 507

PART FOUR Object-Oriented Software Engineering 539

CHAPTER 20 Object-Oriented Concepts and Principles 541

CHAPTER 21 Object-Oriented Analysis 571

CHAPTER 22 Object-Oriented Design 603

CONTENTS AT A GLANCE

CONTENTS AT A GLANCEviii

CHAPTER 23 Object-Oriented Testing 631

CHAPTER 24 Technical Metrics for Object-Oriented Systems 653

PART FIVE Advanced Topics in Software Engineering 671

CHAPTER 25 Formal Methods 673

CHAPTER 26 Cleanroom Software Engineering 699

CHAPTER 27 Component-Based Software Engineering 721

CHAPTER 28 Client/Server Software Engineering 747

CHAPTER 29 Web Engineering 769

CHAPTER 30 Reengineering 799

CHAPTER 31 Computer-Aided Software Engineering 825

CHAPTER 32 The Road Ahead 845

ix

PART ONE—THE PRODUCT AND THE PROCESS 1

CHAPTER 1 THE PRODUCT 3

1.1 The Evolving Role of Software 41.2 Software 6

1.2.1 Software Characteristics 61.2.2 Software Applications 9

1.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 17

CHAPTER 2 THE PROCESS 19

2.1 Software Engineering: A Layered Technology 202.1.1 Process, Methods, and Tools 202.1.2 A Generic View of Software Engineering 21

2.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 34

2.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 40

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

TABLE OF CONTENTS

CONTENTSx

PART TWO—MANAGING SOFTWARE PROJECTS 53

CHAPTER 3 PROJECT MANAGEMENT CONCEPTS 55

3.1 The Management Spectrum 563.1.1 The People 563.1.2 The Product 573.1.2 The Process 573.1.3 The Project 57

3.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 65

3.3 The Product 673.3.1 Software Scope 673.3.2 Problem Decomposition 67

3.4 The Process 683.4.1 Melding the Product and the Process 693.4.2 Process Decomposition 70

3.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 77

CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 79

4.1 Measures, Metrics, and Indicators 804.2 Metrics in the Process and Project Domains 81

4.2.1 Process Metrics and Software Process Improvement 824.2.2 Project Metrics 86

4.3 Software Measurement 874.3.1 Size-Oriented Metrics 884.3.2 Function-Oriented Metrics 894.3.3 Extended Function Point Metrics 91

4.4 Reconciling Different Metrics Approaches 944.5 Metrics for Software Quality 95

4.5.1 An Overview of Factors That Affect Quality 954.5.2 Measuring Quality 964.5.3 Defect Removal Efficiency 98

4.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 100

4.7 Managing Variation: Statistical Quality Control 1004.8 Metrics for Small Organizations 1044.9 Establishing a Software Metrics Program 1054.10 Summary 107REFERENCES 107

CONTENTS xi

PROBLEMS AND POINTS TO PONDER 109FURTHER READINGS AND INFORMATION SOURCES 110

CHAPTER 5 SOFTWARE PROJECT PLANNING 113

5.1 Observations on Estimating 1145.2 Project Planning Objectives 1155.3 Software Scope 115

5.3.1 Obtaining Information Necessary for Scope 1165.3.2 Feasibility 1175.3.3 A Scoping Example 118

5.4 Resources 1205.4.1 Human Resources 1215.4.2 Reusable Software Resources 1215.4.3 Environmental Resources 122

5.5 Software Project Estimation 1235.6 Decomposition Techniques 124

5.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 131

5.7 Empirical Estimation Models 1325.7.1 The Structure of Estimation Models 1325.7.2 The COCOMO Model 1335.7.3 The Software Equation 135

5.8 The Make/Buy Decision 1365.8.1 Creating a Decision Tree 1375.8.2 Outsourcing 138

5.9 Automated Estimation Tools 1395.10 Summary 140REFERENCES 140PROBLEMS AND POINTS TO PONDER 141FURTHER READINGS AND INFORMATION SOURCES 142

CHAPTER 6 RISK ANALYSIS AND MANAGEMENT 145

6.1 Reactive versus Proactive Risk Strategies 1466.2 Software Risks 1466.3 Risk Identification 148

6.3.1 Assessing Overall Project Risk 1496.3.2 Risk Components and Drivers 149

6.4 Risk Projection 1516.4.1 Developing a Risk Table 1516.4.2 Assessing Risk Impact 1536.4.3 Risk Assessment 154

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

CONTENTSxii

PROBLEMS AND POINTS TO PONDER 161FURTHER READINGS AND INFORMATION SOURCES 162

CHAPTER 7 PROJECT SCHEDULING AND TRACKING 165

7.1 Basic Concepts 1667.1.1 Comments on “Lateness” 1677.2.1 Basic Principles 168

7.2 The Relationship Between People and Effort 1707.2.1 An Example 1707.2.2 An Empirical Relationship 1717.2.3 Effort Distribution 172

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

7.4 Selecting Software Engineering Tasks 1777.5 Refinement of Major Tasks 1787.6 Defining a Task Network 1807.7 Scheduling 181

7.7.1 Timeline Charts 1827.7.2 Tracking the Schedule 185

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

CHAPTER 8 SOFTWARE QUALITY ASSURANCE 193

8.1 Quality Concepts 1948.1.1 Quality 1958.1.2 Quality Control 1968.1.3 Quality Assurance 1968.1.4 Cost of Quality 196

8.2 The Quality Movement 1988.3 Software Quality Assurance 199

8.3.1 Background Issues 2008.3.2 SQA Activities 201

8.4 Software Reviews 2028.4.1 Cost Impact of Software Defects 2038.4.2 Defect Amplification and Removal 204

8.5 Formal Technical Reviews 2058.5.1 The Review Meeting 2068.5.2 Review Reporting and Record Keeping 2078.5.3 Review Guidelines 207

8.6 Formal Approaches to SQA 2098.7 Statistical Software Quality Assurance 2098.8 Software Reliability 212

8.8.1 Measures of Reliability and Availability 2128.8.2 Software Safety 213

CONTENTS xiii

8.9 Mistake-Proofing for Software 2148.10 The ISO 9000 Quality Standards 216

8.10.1 The ISO Approach to Quality Assurance Systems 2178.10.2 The ISO 9001 Standard 217

8.11 The SQA Plan 2188.12 Summary 219REFERENCES 220PROBLEMS AND POINTS TO PONDER 221FURTHER READINGS AND INFORMATION SOURCES 222

CHAPTER 9 SOFTWARE CONFIGURATION MANAGEMENT 225

9.1 Software Configuration Management 2269.1.1 Baselines 2279.1.2 Software Configuration Items 228

9.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 240

PART THREE—CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 243

CHAPTER 10 SYSTEM ENGINEERING 245

10.1 Computer-Based Systems 24610.2 The System Engineering Hierarchy 248

10.2.1 System Modeling 24910.2.2 System Simulation 251

10.3 Business Process Engineering: An Overview 25110.4 Product Engineering: An Overview 25410.5 Requirements Engineering 256

10.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 261

10.6 System Modeling 26210.7 Summary 265REFERENCES 267PROBLEMS AND POINTS TO PONDER 267FURTHER READINGS AND INFORMATION SOURCES 269

CONTENTSxiv

CHAPTER 11 ANALYSIS CONCEPTS AND PRINCIPLES 271

11.1 Requirements Analysis 27211.2 Requirements Elicitation for Software 274

11.2.1 Initiating the Process 27411.2.2 Facilitated Application Specification 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 Specification 29111.5.1 Specification Principles 29111.5.2 Representation 29211.5.3 The Software Requirements Specification 293

11.6 Specification Review 29411.7 Summary 294REFERENCES 295PROBLEMS AND POINTS TO PONDER 296FURTHER READINGS AND INFORMATION SOURCES 297

CHAPTER 12 ANALYSIS MODELING 299

12.1 A Brief History 30012.2 The Elements of the Analysis Model 30112.3 Data Modeling 302

12.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 31712.6 The Mechanics of Structured Analysis 319

12.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 327

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

CONTENTS xv

CHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 335

13.1 Software Design and Software Engineering 33613.2 The Design Process 338

13.2.1 Design and Software Quality 33813.2.2 The Evolution of Software Design 339

13.3 Design Principles 34013.4 Design Concepts 341

13.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 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 35513.7 The Design Model 35713.8 Design Documentation 35813.9 Summary 359REFERENCES 359PROBLEMS AND POINTS TO PONDER 361FURTHER READINGS AND INFORMATION SOURCES 362

CHAPTER 14 ARCHITECTURAL DESIGN 365

14.1 Software Architecture 36614.1.1 What Is Architecture? 36614.1.2 Why Is Architecture Important? 367

14.2 Data Design 36814.2.1 Data Modeling, Data Structures, Databases, and the Data

Warehouse 36814.2.2 Data Design at the Component Level 369

14.3 Architectural Styles 37114.3.1 A Brief Taxonomy of Styles and Patterns 37114.3.2 Organization and Refinement 374

14.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 378

14.5 Mapping Requirements into a Software Architecture 37814.5.1 Transform Flow 37914.5.2 Transaction Flow 380

14.6 Transform Mapping 38014.6.1 An Example 38014.6.2 Design Steps 381

14.7 Transaction Mapping 38914.7.1 An Example 39014.7.2 Design Steps 390

CONTENTSxvi

14.8 Refining the Architectural Design 39414.9 Summary 395REFERENCES 396PROBLEMS AND POINTS TO PONDER 397FURTHER READINGS AND INFORMATION SOURCES 399

CHAPTER 15 USER INTERFACE DESIGN 401

15.1 The Golden Rules 40215.1.1 Place the User in Control 40215.1.2 Reduce the User’s 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 40815.4 Interface Design Activities 410

15.4.1 Defining Interface Objects and Actions 41015.4.2 Design Issues 413

15.5 Implementation Tools 41515.6 Design Evaluation 41615.7 Summary 418REFERENCES 418PROBLEMS AND POINTS TO PONDER 419FURTHER READINGS AND INFORMATION SOURCES 420

CHAPTER 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 43216.3 Summary 433REFERENCES 433PROBLEMS AND POINTS TO PONDER 434FURTHER READINGS AND INFORMATION SOURCES 435

CHAPTER 17 SOFTWARE TESTING TECHNIQUES 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 44317.3 White-Box Testing 44417.4 Basis Path Testing 445

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

CONTENTS xvii

17.5.2 Data Flow Testing 45617.5.3 Loop Testing 458

17.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 466

17.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 470

17.8 Summary 472REFERENCES 473PROBLEMS AND POINTS TO PONDER 474FURTHER READINGS AND INFORMATION SOURCES 475

CHAPTER 18 SOFTWARE TESTING STRATEGIES 477

18.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 482

18.2 Strategic Issues 48418.3 Unit Testing 485

18.3.1 Unit Test Considerations 48518.3.2 Unit Test Procedures 487

18.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 494

18.5 Validation Testing 49518.5.1 Validation Test Criteria 49518.5.2 Configuration Review 49618.5.3 Alpha and Beta Testing 496

18.6 System Testing 49618.6.1 Recovery Testing 49718.6.2 Security Testing 49718.6.3 Stress Testing 49818.6.4 Performance Testing 498

18.7 The Art of Debugging 49918.7.1 The Debugging Process 49918.7.2 Psychological Considerations 50018.7.3 Debugging Approaches 501


CONTENTSxviii

CHAPTER 19 TECHNICAL METRICS FOR SOFTWARE 507

19.1 Software Quality 50819.1.1 McCall’s Quality Factors 50919.1.2 FURPS 51119.1.3 ISO 9126 Quality Factors 51319.1.4 The Transition to a Quantitative View 513

19.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 516

19.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 522

19.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 530

19.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 537

PART FOUR—OBJECT-ORIENTED SOFTWARE ENGINEERING 539

CHAPTER 20 OBJECT-ORIENTED CONCEPTS AND PRINCIPLES 541

20.1 The Object-Oriented Paradigm 54220.2 Object-Oriented Concepts 544

20.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 550

20.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 559

20.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 565


CONTENTS xix

CHAPTER 21 OBJECT-ORIENTED ANALYSIS 571

21.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 575

21.2 Domain Analysis 57621.2.1 Reuse and Domain Analysis 57721.2.2 The Domain Analysis Process 577

21.3 Generic Components of the OO Analysis Model 57921.4 The OOA Process 581

21.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 590

21.5 The Object-Relationship Model 59121.6 The Object-Behavior Model 594

21.6.1 Event Identification with Use-Cases 59421.6.2 State Representations 595


CHAPTER 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 Unified 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 62522.6 Summary 626REFERENCES 627PROBLEMS AND POINTS TO PONDER 628FURTHER READINGS AND INFORMATION SOURCES 629

CONTENTSxx

CHAPTER 23 OBJECT-ORIENTED TESTING 631

23.1 Broadening the View of Testing 63223.2 Testing OOA and OOD Models 633

23.2.1 Correctness of OOA and OOD Models 63323.2.2 Consistency of OOA and OOD Models 634

23.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 637

23.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 Design

Methods 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 643

23.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 644

23.6 Interclass Test Case Design 64523.6.1 Multiple Class Testing 64523.6.2 Tests Derived from Behavior Models 647


CHAPTER 24 TECHNICAL METRICS FOR OBJECT-ORIENTED SYSTEMS 653

24.1 The Intent of Object-Oriented Metrics 65424.2 The Distinguishing Characteristics of Object-Oriented Metrics 654

24.2.1 Localization 65524.2.2 Encapsulation 65524.2.3 Information Hiding 65524.2.4 Inheritance 65624.2.5 Abstraction 656

24.3 Metrics for the OO Design Model 65624.4 Class-Oriented Metrics 658

24.4.1 The CK Metrics Suite 65824.4.2 Metrics Proposed by Lorenz and Kidd 66124.4.3 The MOOD Metrics Suite 662

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

CONTENTS xxi

PART FIVE—ADVANCED TOPICS IN SOFTWARE ENGINEERING 671

CHAPTER 25 FORMAL METHODS 673

25.1 Basic Concepts 67425.1.1 Deficiencies of Less Formal Approaches 67525.1.2 Mathematics in Software Development 67625.1.3 Formal Methods Concepts 677

25.2 Mathematical Preliminaries 68225.2.1 Sets and Constructive Specification 68325.2.2 Set Operators 68425.2.3 Logic Operators 68625.2.4 Sequences 686

25.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 Methods—The Road Ahead 69425.8 Summary 695REFERENCES 695PROBLEMS AND POINTS TO PONDER 696FURTHER READINGS AND INFORMATION SOURCES 697

CHAPTER 26 CLEANROOM SOFTWARE ENGINEERING 699

26.1 The Cleanroom Approach 70026.1.1 The Cleanroom Strategy 70126.1.2 What Makes Cleanroom Different? 703

26.2 Functional Specification 70326.2.1 Black-Box Specification 70526.2.2 State-Box Specification 70526.2.3 Clear-Box Specification 706

26.3 Cleanroom Design 70626.3.1 Design Refinement and Verification 70726.3.2 Advantages of Design Verification 710

26.4 Cleanroom Testing 71226.4.1 Statistical Use Testing 71226.4.2 Certification 714


CHAPTER 27 COMPONENT-BASED SOFTWARE ENGINEERING 721

27.1 Engineering of Component-Based Systems 72227.2 The CBSE Process 72427.3 Domain Engineering 725

27.3.1 The Domain Analysis Process 72627.3.2 Characterization Functions 72727.3.3 Structural Modeling and Structure Points 728

27.4 Component-Based Development 73027.4.1 Component Qualification, Adaptation, and

Composition 730

CONTENTSxxii

27.4 2 Component Engineering 73427.4.3 Analysis and Design for Reuse 734

27.5 Classifying and Retrieving Components 73527.5.1 Describing Reusable Components 73627.5.2 The Reuse Environment 738

27.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 741


CHAPTER 28 CLIENT/SERVER SOFTWARE ENGINEERING 747

28.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 753

28.2 Software Engineering for c/s Systems 75528.3 Analysis Modeling Issues 75528.4 Design for c/s Systems 755

28.4.1 Architectural Design for Client/Server Systems 75628.4.2 Conventional Design Approaches for Application

Software 75728.4.3 Database Design 75828.4.4 An Overview of a Design Approach 75928.4.5 Process Design Iteration 761

28.5 Testing Issues 76128.5.1 Overall c/s Testing Strategy 76228.5.2 c/s Testing Tactics 763


CHAPTER 29 WEB ENGINEERING 769

29.1 The Attributes of Web-Based Applications 77129.1.1 Quality Attributes 77329.1.2 The Technologies 773

29.2 The WebE Process 77429.3 A Framework for WebE 77529.4 Formulating/Analyzing Web-Based Systems 776

29.4.1 Formulation 77629.4.2 Analysis 778

29.5 Design for Web-Based Applications 77929.5.1 Architectural Design 78029.5.2 Navigation Design 78329.5.3 Interface Design 785

CONTENTS xxiii

29.6 Testing Web-Based Applications 78629.7 Management Issues 787

29.7.1 The WebE Team 78829.7.2 Project Management 78929.7.3 SCM Issues for WebE 792


CHAPTER 30 REENGINEERING 799

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 81930.7 Summary 820REFERENCES 820PROBLEMS AND POINTS TO PONDER 822FURTHER READINGS AND INFORMATION SOURCES 823

CHAPTER 31 COMPUTER-AIDED SOFTWARE ENGINEERING 825

31.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 836

31.6.1 The Role of the Repository in I-CASE 83631.6.2 Features and Content 837


CONTENTSxxiv

CHAPTER 32 THE ROAD AHEAD 845

32.1 The Importance of Software—Revisited 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

PREFACE

xxv

When a computer software succeeds—when 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 use—it can and does change things for the better.

But when software fails—when its users are dissatisfied, when it is error prone, when

it is difficult to change and even harder to use—bad things can and do happen. We

all want to build software that makes things better, avoiding the bad things that lurk

in the shadow of failed efforts. To succeed, we need discipline when software is

designed and built. We need an engineering approach.

In the 20 years since the first edition of this book was written, software engineer-

ing has evolved from an obscure idea practiced by a relatively small number of zealots

to a legitimate engineering discipline. Today, it is recognized as a subject worthy of

serious research, conscientious study, and tumultuous debate. Throughout the indus-

try, software engineer has replaced programmer as the job title of preference. Software

process models, software engineering methods, and software tools have been adopted

successfully 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 discipline

is 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 engineering

approach 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 before

the discipline reaches full maturity.

The fifth edition of Software Engineering: A Practitioner's Approach is intended to

serve as a guide to a maturing engineering discipline. The fifth edition, like the four

editions that preceded it, is intended for both students and practitioners, retaining its

appeal as a guide to the industry professional and a comprehensive introduction to

the student at the upper level undergraduate or first year graduate level. The format

and style of the fifth edition have undergone significant change, making the presen-

tation more reader-friendly and the content more easily accessible.

The fifth edition is considerably more than a simple update. The book has been

revised to accommodate the dramatic growth in the field and to emphasize new and

important software engineering practices. In addition, a comprehensive Web site has

been developed to complement the content of the book. The Web site, which I call

PREFACExxvi

SepaWeb, can be found at http://www.mhhe.com/pressman. Designed to be used

in conjunction with the fifth edition of Software Engineering: A Practitioner's Approach,

SepaWeb provides a broad array of software engineering resources that will benefit

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 Instructor’s 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 fifth edition have been organized into five 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 five-part organization of the fifth 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 five 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 fifth 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 Instructor's Guide for Software Engineering: A Practitioner's Approach is avail-

able from SepaWeb. The Instructor's Guide presents suggestions for conducting var-

PREFACE xxvii

ious types of software engineering courses, recommendations for a variety of soft-

ware projects to be conducted in conjunction with a course, solutions to selected

problems, and a number of teaching aids.

A comprehensive video curriculum, Essential Software Engineering, is available to

complement this book. The video curriculum has been designed for industry train-

ing 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 mailing the request card at the back of this book.1

My work on the five editions of Software Engineering: A Practitioner’s Approach has

been the longest continuing technical project of my life. Even when the writing stops,

information extracted from the technical literature continues to be assimilated and

organized. 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 within

the 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 Michigan—Dear-

born; and, James Purtilo, University of Maryland. Their comments and criticism have

been invaluable. Special thanks and acknowledgement also go to Bruce Maxim of

the University of Michigan—Dearborn, who assisted me in developing the Web site

that accompanies this book. Bruce is responsible for much of its design and peda-

gogical content.

The content of the fifth edition of Software Engineering: A Practitioner's Approach

has been shaped by industry professionals, university professors, and students who

have used earlier editions of the book and have taken the time to communicate their

suggestions, criticisms, and ideas. My thanks to each of you. In addition, my personal

thanks go to our many industry clients worldwide, who certainly teach me as much

or more than I can teach them.

As the editions of this book have evolved, my sons, Mathew and Michael, have

grown from boys to men. Their maturity, character, and success in the real world

have 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. Pressman

1 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 [email protected].

xxviii

USING THIS BOOK

The fifth edition of Software Engineering: A Practitioner’s 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 useful

supplementary information for readers of the book and a broad array of resources (e.g.,

an Instructor’s 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:

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-matic guidance 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-rent discussion can be found.

The quote icon presents inter-esting quotes that have rele-vance to 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 workyou’re doing and the workproducts you produce.

The SepaWeb.documentsicon points you to detailed doc-ument outlines, descriptionsand examples contained withinthe SEPA Web site.

“Important words”

WebRefFor pointers that will takeyou directly to Webresources

A selected topic

1 If the card is missing, please visit the R.S. Pressman & Associates, Inc. Web site athttp://www.rspa.com/ese, or e-mail to [email protected].

1

P A R T

In this part of Software Engineering: A Practitioner’s Approach, you’lllearn 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-ware engineering work?

Once these questions are answered, you’ll be better prepared tounderstand the management and technical aspects of the engi-neering discipline to which the remainder of this book is dedicated.

THE PRODUCT ANDTHE PROCESS

One

3

C H A P T E R

K E YC O N C E P T S

applicationcategories . . . . . . . 9

component-basedassembly. . . . . . . . . 8

failure curves . . . . . 8

history . . . . . . . . . . 5

myths . . . . . . . . . . 12

reuse . . . . . . . . . . . . 9

softwarecharacteristics . . . . 6

softwareengineering . . . . . . 4

wear . . . . . . . . . . . . 7

The 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-ness and industry leaders committed vast sums of money, and finally, dire warn-

ings of pending catastrophe penetrated the public’s consciousness. Software,

in the guise of the now-infamous Y2K bug, would fail and, as a result, stop the

world as we then knew it.

As we watched and wondered during the waning months of 1999, I couldn’t

help thinking of an unintentionally prophetic paragraph contained on the first

page of the fourth edition of this book. It stated:

Computer software has become a driving force. It is the engine that drives business

decision making. It serves as the basis for modern scientific investigation and engi-

neering problem solving. It is a key factor that differentiates modern products and

services. It is embedded in systems of all kinds: transportation, medical, telecom-

munications, military, industrial processes, entertainment, office products, . . . the

list is almost endless. Software is virtually inescapable in a modern world. And as

we move into the twenty-first century, it will become the driver for new advances in

everything from elementary education to genetic engineering.

1 THE PRODUCT

What is it? Computer software isthe product that software engi-

neers design and build. It encom-

passes programs that execute within a computer

of any size and architecture, documents that

encompass hard-copy and virtual forms, and

data that combine numbers and text but also

includes representations of pictorial, video, and

audio information.

Who does it? Software engineers build it, and virtu-ally everyone in the industrialized world uses it

either directly or indirectly.

Why is it important? Because it affects nearly everyaspect of our lives and has become pervasive in

our commerce, our culture, and our everyday

activities.

What are the steps? You build computer softwarelike you build any successful product, by apply-

ing a process that leads to a high-quality result

that meets the needs of the people who will use

the product. You apply a software engineering

approach.

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 computer

software. But from the user’s viewpoint, the work

product is the resultant information that somehow

makes the user’s world better.

How do I ensure that I’ve done it right? Read theremainder of this book, select those ideas appli-

cable to the software that you build, and apply

them to your work.

Q U I C KL O O K

PART ONE THE PRODUCT AND THE PROCESS4

In the five 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 promise

of a new economic paradigm, Wall Street investors gave tiny “dot-com” companies

billion dollar valuations before these start-ups produced a dollar in sales. New

software-driven industries have arisen and old ones that have not adapted to the new

driving force are now threatened with extinction. The United States government has

litigated against the software’s industry’s largest company, just as it did in earlier eras

when it moved to stop monopolistic practices in the oil and steel industries.

Software’s impact on our society and culture continues to be profound. As its

importance grows, the software community continually attempts to develop tech-

nologies that will make it easier, faster, and less expensive to build high-quality com-

puter programs. Some of these technologies are targeted at a specific application

domain (e.g., Web-site design and implementation); others focus on a technology

domain (e.g., object-oriented systems); and still others are broad-based (e.g., oper-

ating systems such as LINUX). However, we have yet to develop a software technol-

ogy 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 computer

software—people who must get it right. The technology encompasses a process, a

set of methods, and an array of tools that we call software engineering.

1.1 THE EVOLVING ROLE OF SOFTWARE

Today, 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 accessible

by local hardware. Whether it resides within a cellular phone or operates inside a

mainframe computer, software is an information transformer—producing, manag-

ing, acquiring, modifying, displaying, or transmitting information that can be as sim-

ple as a single bit or as complex as a multimedia presentation. As the vehicle used

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 and

control of other programs (software tools and environments).

Software delivers the most important product of our time—information. Software

transforms personal data (e.g., an individual’s financial transactions) so that the data

can be more useful in a local context; it manages business information to enhance

competitiveness; 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 span

of little more than 50 years. Dramatic improvements in hardware performance, pro-

“Ideas andtechnologicaldiscoveries are thedriving engines ofeconomic growth.”The Wall StreetJournal

Software is both aproduct and a vehiclefor delivering aproduct.

CHAPTER 1 THE PRODUCT

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 on

our culture. Osborne [OSB79] characterized a "new industrial revolution." Toffler

[TOF80] called the advent of microelectronics part of "the third wave of change" in

human history, and Naisbitt [NAI82] predicted a transformation from an industrial

society to an "information society." Feigenbaum and McCorduck [FEI83] suggested

that information and knowledge (controlled by computers) would be the focal point

for power in the twenty-first century, and Stoll [STO89] argued that the "electronic

community" created by networks and software was the key to knowledge interchange

throughout the world.

As the 1990s began, Toffler [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." Yourdon

[YOU92] worried that U.S. companies might loose their competitive edge in software-

related businesses and predicted “the decline and fall of the American programmer.”

Hammer and Champy [HAM93] argued that information technologies were to play a

pivotal role in the “reengineering of the corporation.” During the mid-1990s, the per-

vasiveness of 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 Future

Does Not Compute by Stephen Talbot). These authors demonized the computer, empha-

sizing legitimate concerns but ignoring the profound benefits 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]. Software’s 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:

5

“For I dipped into thefuture, far as thehuman eye couldsee, Saw the visionof the world, and allthe wonder thatwould be.” Tennyson

“Computers make iteasy to do a lot ofthings, but most ofthe things that theymake it easier to dodon't need to bedone.”Andy Rooney


• 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 is

being developed?

These, and many other questions,1 are a manifestation of the concern about soft-

ware and the manner in which it is developed—a concern that has lead to the adop-

tion of software engineering practice.

1.2 SOFTWARE

In 1970, less than 1 percent of the public could have intelligently described what

"computer software" meant. Today, most professionals and many members of the

public 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. There

is no question that other, more complete definitions could be offered. But we need

more than a formal definition.

1.2.1 Software Characteristics

To gain an understanding of software (and ultimately an understanding of software

engineering), it is important to examine the characteristics of software that make it

different from other things that human beings build. When hardware is built, the

human creative process (analysis, design, construction, testing) is ultimately trans-

lated into a physical form. If we build a new computer, our initial sketches, formal

design 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, software

has characteristics that are considerably different than those of hardware:

1. Software is developed or engineered, it is not manufactured in the classical

sense.

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-ing ‘What have we done to make it possible for today’s 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.”

Software isengineered, notmanufactured.


ity is achieved through good design, but the manufacturing phase for hardware can

introduce quality problems that are nonexistent (or easily corrected) for software.

Both activities are dependent on people, but the relationship between people applied

and work accomplished is entirely different (see Chapter 7). Both activities require

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

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-

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 rate

rises again as hardware components suffer from the cumulative affects of dust, vibra-

tion, abuse, temperature extremes, and many other environmental maladies. Stated

simply, the hardware begins to wear out.

Software is not susceptible to the environmental maladies that cause hardware to

wear out. In theory, therefore, the failure rate curve for software should take the form of

the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure

rates early in the life of a program. However, these are corrected (ideally, without intro-

ducing other errors) and the curve flattens as shown.The idealized curve is a gross over-

simplification of actual failure models (see Chapter 8 for more information) for software.

However, the implication is clear—software doesn't wear out. But it does deteriorate!

This seeming contradiction can best be explained by considering the “actual curve”

shown in Figure 1.2. During its life, software will undergo change (maintenance). As

7

“Wear out”“Infantmortality”

Time

Failu

re ra

te

FIGURE 1.1Failure curvefor hardware

Software doesn’t wearout, but it doesdeteriorate.


changes are made, it is likely that some new defects will be introduced, causing the

failure rate curve to spike as shown in Figure 1.2. Before the curve can return to the

original steady-state failure rate, another change is requested, causing the curve to

spike again. Slowly, the minimum failure rate level begins to rise—the software is

deteriorating 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 no

software spare parts. Every software failure indicates an error in design or in the

process through which design was translated into machine executable code. There-

fore, software maintenance involves considerably more complexity than hardware

maintenance.

3. Although the industry is moving toward component-based assembly, most

software continues to be custom built.

Consider the manner in which the control hardware for a computer-based product

is designed and built. The design engineer draws a simple schematic of the digital

circuitry, does some fundamental analysis to assure that proper function will be

achieved, and then goes to the shelf where catalogs of digital components exist. Each

integrated circuit (called an IC or a chip) has a part number, a defined and validated

function, a well-defined interface, and a standard set of integration guidelines. After

each component is selected, it can be ordered off the shelf.

As an engineering discipline evolves, a collection of standard design components

is 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 engineers

as they design new systems. The reusable components have been created so that the

engineer can concentrate on the truly innovative elements of a design, that is, the

FIGURE 1.2Idealized andactual failurecurves forsoftware

Increased failurerate due to side

effects

Time

Failu

re ra

te

Change

Actual curve

Idealized curve

Most softwarecontinues to be custom built.

Software engineeringmethods strive toreduce the magnitudeof the spikes and theslope of the actualcurve in Figure 1.2.


parts of the design that represent something new. In the hardware world, component

reuse 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 be

reused in many different programs. In the 1960s, we built scientific subroutine libraries

that were reusable in a broad array of engineering and scientific applications. These

subroutine libraries reused well-defined algorithms in an effective manner but had a

limited domain of application. Today, we have extended our view of reuse to encom-

pass not only algorithms but also data structure. Modern reusable components encap-

sulate both data and the processing applied to the data, enabling the software engineer

to create new applications from reusable parts. For example, today's graphical user

interfaces are built using reusable components that enable the creation of graphics

windows, pull-down menus, and a wide variety of interaction mechanisms. The data

structure and processing detail required to build the interface are contained with a

library of reusable components for interface construction.

1.2.2 Software Applications

Software may be applied in any situation for which a prespecified set of procedural

steps (i.e., an algorithm) has been defined (notable exceptions to this rule are expert

system software and neural network software). Information content and determinacy

are important factors in determining the nature of a software application. Content

refers 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., a

numerical control) accepts discrete data items with limited structure and produces

individual 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 data

in 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, and

produces output that varies as a function of environment and time. Applications with

these characteristics are indeterminate.

It is somewhat difficult to develop meaningful generic categories for software appli-

cations. As software complexity grows, neat compartmentalization disappears. The

following software areas indicate the breadth of potential applications:

System software. System software is a collection of programs written to service

other programs. Some system software (e.g., compilers, editors, and file manage-

ment utilities) process complex, but determinate, information structures. Other sys-

tems applications (e.g., operating system components, drivers, telecommunications

9

XRefSoftware reuse isdiscussed in Chapter13. Component-basedsoftware engineering ispresented in Chapter27.


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 this

area restructure existing data in a way that facilitates business operations or man-

agement decision 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 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/scientific 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 significant 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 financial

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

One of the mostcomprehensive libraries ofshareware/freeware canbe found at www.shareware.com


hypertext and a variety of visual and audio formats). In essence, the network becomes

a massive computer providing an almost unlimited software resource that can be

accessed by anyone with a modem.

Artificial intelligence software. Artificial intelligence (AI) software makes use

of nonnumerical algorithms to solve complex problems that are not amenable to

computation 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 this

category.

1.3 SOFTWARE: A CRISIS ON THE HORIZON?

Many industry observers (including this author) have characterized the problems

associated 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-

cesses achieved by the software industry have led many to question whether the term

software crisis is still appropriate. Robert Glass, the author of a number of books on

software 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-

ures in 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 that

the software crisis predicted 30 years ago never seemed to materialize. What we

really have may be something rather different.

The word crisis is defined in Webster's Dictionary as “a turning point in the course of

anything; 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 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 us

a 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 The

word affliction is defined as "anything causing pain or distress." But the definition of

the adjective chronic is the key to our argument: "lasting a long time or recurring

often; continuing indefinitely." It is far more accurate to describe the problems we

have 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-

opment of computer software is not limited to software that "doesn't function

11

2 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


properly." Rather, the affliction encompasses problems associated with how we

develop software, how we support a growing volume of existing software, and how

we can expect to keep pace with a growing demand for more software.

We live with this affliction to this day—in 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 MYTHS

Many causes of a software affliction can be traced to a mythology that arose during

the early history of software development. Unlike ancient myths that often provide

human lessons well worth heeding, software myths propagated misinformation and

confusion. Software myths had a number of attributes that made them insidious; for

instance, they appeared to be reasonable statements of fact (sometimes containing

elements of truth), they had an intuitive feel, and they were often promulgated by

experienced practitioners who "knew the score."

Today, most knowledgeable professionals recognize myths for what they are—

misleading attitudes that have caused serious problems for managers and technical

people alike. However, old attitudes and habits are difficult to modify, and remnants

of software myths are still believed.

Management myths. Managers with software responsibility, like managers in most

disciplines, 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 software

manager 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-

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

“In the absence ofmeaningful standards, a new industry likesoftware comes todepend instead onfolklore.”

Tom DeMarco


later." At first, this statement may seem counterintuitive. However, as new people

are added, people who were working must spend time educating the newcomers,

thereby reducing the amount of time spent on productive development effort. Peo-

ple can 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 person

at 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 the

customer) and ultimately, dissatisfaction with the developer.

Myth: A general statement of objectives is sufficient to begin writing programs—we 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. These

characteristics can be determined only after thorough communication between cus-

tomer and developer.

Myth: Project requirements continually change, but change can be easily accom-modated because 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 of

change. If serious attention is given to up-front definition, early requests for change

can be accommodated easily. The customer can review requirements and recom-

mend modifications with relatively little impact on cost. When changes are requested

during software design, the cost impact grows rapidly. Resources have been com-

mitted and a design framework has been established. Change can cause upheaval

that requires additional resources and major design modification, that is, additional

cost. Changes in function, performance, interface, or other characteristics during

implementation (code and test) have a severe impact on cost. Change, when requested

after software is in production, can be over an order of magnitude more expensive

than the same change requested earlier.

13

The Software ProjectManagers Network at www.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 party—usually 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.


Practitioner's myths. Myths that are still believed by software practitioners have

been 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 that

between 60 and 80 percent of all effort expended on software will be expended after

it 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 project—the formal technical review. Software reviews

(described in Chapter 8) are a "quality filter" that have been found to be more effec-

tive than 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 engineering

and, 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 in

faster 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 the

first step toward formulation of practical solutions for software engineering.

1×

Definition

1.5–6×

Development

60–100×

After release

Cos

t to

chan

ge

FIGURE 1.3The impact ofchange

Whenever you think,we don’t have time forsoftware engineeringdiscipline, ask yourself:“Will we have time todo it over again?”


1.5 SUMMARY

Software has become the key element in the evolution of computer-based systems

and 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 of

these items comprises a configuration that is created as part of the software engi-

neering process. The intent of software engineering is to provide a framework for

building 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 Year

2000, 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 Failure—Amazing Stories and

Cautionary 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. 104–105.

[HAM93] Hammer, M., and J. Champy, Reengineering the Corporation, HarperCollins

Publishers, 1993.

[JON91] Jones, C., Applied Software Measurement, McGraw-Hill, 1991.

[KAR99] Karlson, E. and J. Kolber, A Basic Introduction to Y2K: How the Year 2000

Computer 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 Wild—The Next Industrial Revolution,

Osborne/McGraw-Hill, 1979.

[PUT97] Putnam, L. and W. Myers, Industrial Strength Software, IEEE Computer

Society Press, 1997.

[STO89] Stoll, C., The Cuckoo's Egg, Doubleday, 1989.

[TOF80] Toffler, A., The Third Wave, Morrow, 1980.

15


[TOF90] Toffler, 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

Software Engineering - Webs€¦ · CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 79 4.1 Measures,...

Documents

Transcript of Software Engineering - Webs€¦ · CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 79 4.1 Measures,...