Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Software EngineeringA PRACTITIONER’S APPROACH
  2. 2. McGraw-Hill Series in Computer ScienceSenior Consulting Editor Networks, Parallel and Pressman, SoftwareC. L. Liu, National Tsing Hua Distributed Computing Engineering: A Beginner’s University Graphics and Visualization Guide, 1/e The MIT Electrical and Pressman, SoftwareConsulting Editor Computer Science Series Engineering: A Practioner’sAllen B. Tucker, Bowdoin Guide, 5/e College Software Engineering and Ramakrishnan/Gehrke, Databases Database ManagementFundamentals of Computing Atzeni, Ceri, Paraborschi, Systems, 2/e and Programming and Torlone, Schach, Classical and Object-Computer Organization and Database Systems, 1/e Oriented Software Architecture Mitchell, Machine Engineering with UMLSystems and Languages Learning, 1/e and C++, 4/eTheoretical Foundations Musa, Iannino, Schach, Classical and Object-Software Engineering and and Okumoto, Oriented Software Databases Software Reliability, 1/e Engineering with UML andArtificial Intelligence Java, 1/e
  3. 3. Software EngineeringA PRACTITIONER’S APPROACH FIFTH EDITION Roger S. Pressman, Ph.D. Boston Burr Ridge, IL Dubuque, IA Madison, WI New York San Francisco St. Louis Bangkok Bogotá Caracas Lisbon London Madrid Mexico City Milan New Delhi Seoul Singapore Sydney Taipei Toronto
  4. 4. McGraw-Hill Higher Education A Division of The McGraw-Hill CompaniesSOFTWARE ENGINEERINGPublished by McGraw-Hill, an imprint of The McGraw-Hill Companies, Inc. 1221 Avenue of theAmericas, New York, NY, 10020. Copyright/2001, 1997, 1992, 1987, 1982, by The McGraw-Hill Com-panies, Inc. All rights reserved. No part of this publication may be reproduced or distributed in anyform or by any means, or stored in a database or retrieval system, without the prior written consentof The McGraw-Hill Companies, Inc., including, but not limited to, in any network or other electronicstorage or transmission, or broadcast for distance learning.This book is printed on acid-free paper.1 2 3 4 5 6 7 8 9 0 DOC/DOC 0 9 8 7 6 5 4 3 2 1 0ISBN 0073655783Publisher: Thomas CassonExecutive editor: Betsy JonesDevelopmental editor: Emily GrayMarketing manager: John WannemacherProject manager: Karen J. NelsonProduction supervisor: Heather BurbridgeCoordinator freelance design: Keith McPhersonSupplement coordinator: Rose RangeNew media: Christopher StylesCover design: Rhiannon ErwinCover illustrator: Joseph GiliansCompositor: Carlisle Communications, Ltd.Typeface: 8.5/13.5 LeawoodPrinter: R. R. Donnelley & Sons 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-3 1. Software engineering. I. Title. II. Series. QA76.758.P75 2001 005.1—dc21 00-036133http://www.mhhe.com
  5. 5. To my parents
  6. 6. ABOUT THE AUTHOR R oger S. Pressman is an internationally recognized authority in software process improvement and software engineering technologies. For over three decades, he has worked as a software engineer, a manager, a professor, an author, and a consultant, focus- ing on software engineering issues. As an industry practitioner and manager, Dr. Pressman worked on the development of CAD/CAM systems for advanced engineering and manufacturing applications. He has also held positions with responsibility for 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 universitys 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 industrys most comprehensive treatments of the subject, and Process Advisor, a self- directed system for software engineering process improvement. Both products are used by hundreds of companies worldwide. Dr. Pressman has written many technical papers, is a regular contributor to industry periodicals, and is author of six books. In addition to Software Engineering: A Practitioners Approach, he has written A Managers Guide to Software Engineering (McGraw-Hill), an award-winning book that uses a unique Q&A format to present management guidelines for instituting and understanding software engineering technology; Making Software Engi- neering Happen (Prentice-Hall), the 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.vi
  7. 7. C O N T E N T S AT A G L A N C E Preface xxvPA R T O N E The Product and the Process 1 CHAPTER 1 The Product 3 CHAPTER 2 The Process 19PA R T T W O Managing Software Projects 53 CHAPTER 3 Project Management Concepts 55 CHAPTER 4 Software Process and Project 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 225PA R T T H R E E 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 507PA R T F O U R 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 vii
  8. 8. viii C O N T E N T S AT A G L A N C E CHAPTER 23 Object-Oriented Testing 631 CHAPTER 24 Technical Metrics for Object-Oriented Systems 653PA R T F I V E Advanced Topics in Software 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
  9. 9. TA B L E O F C O N T E N T SPA R T O N E — T H E P R O D U C T A N D T H E P R O C E S S 1 CHAPTER 1 THE PRODUCT 3 1.1 The Evolving Role of Software 4 1.2 Software 6 1.2.1 Software Characteristics 6 1.2.2 Software Applications 9 1.3 Software: A Crisis on the Horizon? 11 1.4 Software Myths 12 1.5 Summary 15 REFERENCES 15 PROBLEMS AND POINTS TO PONDER 16 FURTHER READINGS AND INFORMATION SOURCES 17 CHAPTER 2 THE PROCESS 19 2.1 Software Engineering: A Layered Technology 20 2.1.1 Process, Methods, and Tools 20 2.1.2 A Generic View of Software Engineering 21 2.2 The Software Process 23 2.3 Software Process Models 26 2.4 The Linear Sequential Model 28 2.5 The Prototyping Model 30 2.6 The RAD Model 32 2.7 Evolutionary Software Process Models 34 2.7.1 The Incremental Model 35 2.7.2 The Spiral Model 36 2.7.3 The WINWIN Spiral Model 38 2.7.4 The Concurrent Development Model 40 2.8 Component-Based Development 42 2.9 The Formal Methods Model 43 2.10 Fourth Generation Techniques 44 2.11 Process Technology 46 2.12 Product and Process 46 2.13 Summary 47 REFERENCES 47 PROBLEMS AND POINTS TO PONDER 49 FURTHER READINGS AND INFORMATION SOURCES 50 ix
  10. 10. x CONTENTSPA R T T W O — M A N A G I N G S O F T WA R E P R O J E C T S 53 CHAPTER 3 PROJECT MANAGEMENT CONCEPTS 55 3.1 The Management Spectrum 56 3.1.1 The People 56 3.1.2 The Product 57 3.1.2 The Process 57 3.1.3 The Project 57 3.2 People 58 3.2.1 The Players 58 3.2.2 Team Leaders 59 3.2.3 The Software Team 60 3.2.4 Coordination and Communication Issues 65 3.3 The Product 67 3.3.1 Software Scope 67 3.3.2 Problem Decomposition 67 3.4 The Process 68 3.4.1 Melding the Product and the Process 69 3.4.2 Process Decomposition 70 3.5 The Project 71 3.6 The W5HH Principle 73 3.7 Critical Practices 74 3.8 Summary 74 REFERENCES 75 PROBLEMS AND POINTS TO PONDER 76 FURTHER READINGS AND INFORMATION SOURCES 77 CHAPTER 4 S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S 79 4.1 Measures, Metrics, and Indicators 80 4.2 Metrics in the Process and Project Domains 81 4.2.1 Process Metrics and Software Process Improvement 82 4.2.2 Project Metrics 86 4.3 Software Measurement 87 4.3.1 Size-Oriented Metrics 88 4.3.2 Function-Oriented Metrics 89 4.3.3 Extended Function Point Metrics 91 4.4 Reconciling Different Metrics Approaches 94 4.5 Metrics for Software Quality 95 4.5.1 An Overview of Factors That Affect Quality 95 4.5.2 Measuring Quality 96 4.5.3 Defect Removal Efficiency 98 4.6 Integrating Metrics Within the Software Engineering Process 98 4.6.1 Arguments for Software Metrics 99 4.6.2 Establishing a Baseline 100 4.6.3 Metrics Collection, Computation, and Evaluation 100 4.7 Managing Variation: Statistical Quality Control 100 4.8 Metrics for Small Organizations 104 4.9 Establishing a Software Metrics Program 105 4.10 Summary 107 REFERENCES 107
  11. 11. CONTENTS xi PROBLEMS AND POINTS TO PONDER 109 FURTHER READINGS AND INFORMATION SOURCES 110CHAPTER 5 S O F T WA R E P R O J E C T P L A N N I N G 113 5.1 Observations on Estimating 114 5.2 Project Planning Objectives 115 5.3 Software Scope 115 5.3.1 Obtaining Information Necessary for Scope 116 5.3.2 Feasibility 117 5.3.3 A Scoping Example 118 5.4 Resources 120 5.4.1 Human Resources 121 5.4.2 Reusable Software Resources 121 5.4.3 Environmental Resources 122 5.5 Software Project Estimation 123 5.6 Decomposition Techniques 124 5.6.1 Software Sizing 124 5.6.2 Problem-Based Estimation 126 5.6.3 An Example of LOC-Based Estimation 128 5.6.4 An Example of FP-Based Estimation 129 5.6.4 Process-Based Estimation 130 5.6.5 An Example of Process-Based Estimation 131 5.7 Empirical Estimation Models 132 5.7.1 The Structure of Estimation Models 132 5.7.2 The COCOMO Model 133 5.7.3 The Software Equation 135 5.8 The Make/Buy Decision 136 5.8.1 Creating a Decision Tree 137 5.8.2 Outsourcing 138 5.9 Automated Estimation Tools 139 5.10 Summary 140 REFERENCES 140 PROBLEMS AND POINTS TO PONDER 141 FURTHER READINGS AND INFORMATION SOURCES 142CHAPTER 6 R I S K A N A LY S I S A N D M A N A G E M E N T 145 6.1 Reactive versus Proactive Risk Strategies 146 6.2 Software Risks 146 6.3 Risk Identification 148 6.3.1 Assessing Overall Project Risk 149 6.3.2 Risk Components and Drivers 149 6.4 Risk Projection 151 6.4.1 Developing a Risk Table 151 6.4.2 Assessing Risk Impact 153 6.4.3 Risk Assessment 154 6.5 Risk Refinement 156 6.6 Risk Mitigation, Monitoring, and Management 156 6.7 Safety Risks and Hazards 158 6.8 The RMMM Plan 159 6.9 Summary 159 REFERENCES 160
  12. 12. xii CONTENTS PROBLEMS AND POINTS TO PONDER 161 FURTHER READINGS AND INFORMATION SOURCES 162 CHAPTER 7 PROJECT SCHEDULING AND TRACKING 165 7.1 Basic Concepts 166 7.1.1 Comments on “Lateness” 167 7.2.1 Basic Principles 168 7.2 The Relationship Between People and Effort 170 7.2.1 An Example 170 7.2.2 An Empirical Relationship 171 7.2.3 Effort Distribution 172 7.3 Defining a Task Set for the Software Project 172 7.3.1 Degree of Rigor 173 7.3.2 Defining Adaptation Criteria 174 7.3.3 Computing a Task Set Selector Value 175 7.3.4 Interpreting the TSS Value and Selecting the Task Set 176 7.4 Selecting Software Engineering Tasks 177 7.5 Refinement of Major Tasks 178 7.6 Defining a Task Network 180 7.7 Scheduling 181 7.7.1 Timeline Charts 182 7.7.2 Tracking the Schedule 185 7.8 Earned Value Analysis 186 7.9 Error Tracking 187 7.10 The Project Plan 189 7.11 Summary 189 REFERENCES 189 PROBLEMS AND POINTS TO PONDER 190 FURTHER READINGS AND INFORMATION SOURCES 192 CHAPTER 8 S O F T WA R E Q U A L I T Y A S S U R A N C E 193 8.1 Quality Concepts 194 8.1.1 Quality 195 8.1.2 Quality Control 196 8.1.3 Quality Assurance 196 8.1.4 Cost of Quality 196 8.2 The Quality Movement 198 8.3 Software Quality Assurance 199 8.3.1 Background Issues 200 8.3.2 SQA Activities 201 8.4 Software Reviews 202 8.4.1 Cost Impact of Software Defects 203 8.4.2 Defect Amplification and Removal 204 8.5 Formal Technical Reviews 205 8.5.1 The Review Meeting 206 8.5.2 Review Reporting and Record Keeping 207 8.5.3 Review Guidelines 207 8.6 Formal Approaches to SQA 209 8.7 Statistical Software Quality Assurance 209 8.8 Software Reliability 212 8.8.1 Measures of Reliability and Availability 212 8.8.2 Software Safety 213
  13. 13. CONTENTS xiii 8.9 Mistake-Proofing for Software 214 8.10 The ISO 9000 Quality Standards 216 8.10.1 The ISO Approach to Quality Assurance Systems 217 8.10.2 The ISO 9001 Standard 217 8.11 The SQA Plan 218 8.12 Summary 219 REFERENCES 220 PROBLEMS AND POINTS TO PONDER 221 FURTHER READINGS AND INFORMATION SOURCES 222 CHAPTER 9 S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T 225 9.1 Software Configuration Management 226 9.1.1 Baselines 227 9.1.2 Software Configuration Items 228 9.2 The SCM Process 230 9.3 Identification of Objects in the Software Configuration 230 9.4 Version Control 232 9.5 Change Control 234 9.6 Configuration Audit 237 9.7 Status Reporting 237 9.8 SCM Standards 238 9.9 Summary 238 REFERENCES 239 PROBLEMS AND POINTS TO PONDER 239 FURTHER READINGS AND INFORMATION SOURCES 240PA R T T H R E E — C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G 243 CHAPTER 10 SYSTEM ENGINEERING 245 10.1 Computer-Based Systems 246 10.2 The System Engineering Hierarchy 248 10.2.1 System Modeling 249 10.2.2 System Simulation 251 10.3 Business Process Engineering: An Overview 251 10.4 Product Engineering: An Overview 254 10.5 Requirements Engineering 256 10.5.1 Requirements Elicitation 256 10.5.2 Requirements Analysis and Negotiation 258 10.5.3 Requirements Specification 259 10.5.4 System Modeling 259 10.5.5 Requirements Validation 260 10.5.6 Requirements Management 261 10.6 System Modeling 262 10.7 Summary 265 REFERENCES 267 PROBLEMS AND POINTS TO PONDER 267 FURTHER READINGS AND INFORMATION SOURCES 269
  14. 14. xiv CONTENTS CHAPTER 11 A N A LY S I S C O N C E P T S A N D P R I N C I P L E S 271 11.1 Requirements Analysis 272 11.2 Requirements Elicitation for Software 274 11.2.1 Initiating the Process 274 11.2.2 Facilitated Application Specification Techniques 275 11.2.3 Quality Function Deployment 279 11.2.4 Use-Cases 280 11.3 Analysis Principles 282 11.3.1 The Information Domain 283 11.3.2 Modeling 285 11.3.3 Partitioning 286 11.3.4 Essential and Implementation Views 288 11.4 Software Prototyping 289 11.4.1 Selecting the Prototyping Approach 289 11.4.2 Prototyping Methods and Tools 290 11.5 Specification 291 11.5.1 Specification Principles 291 11.5.2 Representation 292 11.5.3 The Software Requirements Specification 293 11.6 Specification Review 294 11.7 Summary 294 REFERENCES 295 PROBLEMS AND POINTS TO PONDER 296 FURTHER READINGS AND INFORMATION SOURCES 297 CHAPTER 12 A N A LY S I S M O D E L I N G 299 12.1 A Brief History 300 12.2 The Elements of the Analysis Model 301 12.3 Data Modeling 302 12.3.1 Data Objects, Attributes, and Relationships 302 12.3.2 Cardinality and Modality 305 12.3.3 Entity/Relationship Diagrams 307 12.4 Functional Modeling and Information Flow 309 12.4.1 Data Flow Diagrams 311 12.4.2 Extensions for Real-Time Systems 312 12.4.3 Ward and Mellor Extensions 312 12.4.4 Hatley and Pirbhai Extensions 315 12.5 Behavioral Modeling 317 12.6 The Mechanics of Structured Analysis 319 12.6.1 Creating an Entity/Relationship Diagram 319 12.6.2 Creating a Data Flow Model 321 12.6.3 Creating a Control Flow Model 324 12.6.4 The Control Specification 325 12.6.5 The Process Specification 327 12.7 The Data Dictionary 328 12.8 Other Classical Analysis Methods 330 12.9 Summary 331 REFERENCES 331 PROBLEMS AND POINTS TO PONDER 332 FURTHER READINGS AND INFORMATION SOURCES 334
  15. 15. CONTENTS xvCHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 335 13.1 Software Design and Software Engineering 336 13.2 The Design Process 338 13.2.1 Design and Software Quality 338 13.2.2 The Evolution of Software Design 339 13.3 Design Principles 340 13.4 Design Concepts 341 13.4.1 Abstraction 342 13.4.2 Refinement 343 13.4.3 Modularity 343 13.4.4 Software Architecture 346 13.4.5 Control Hierarchy 347 13.4.6 Structural Partitioning 348 13.4.7 Data Structure 349 13.4.8 Software Procedure 351 13.4.9 Information Hiding 351 13.5 Effective Modular Design 352 13.5.1 Functional Independence 352 13.5.2 Cohesion 353 13.5.3 Coupling 354 13.6 Design Heuristics for Effective Modularity 355 13.7 The Design Model 357 13.8 Design Documentation 358 13.9 Summary 359 REFERENCES 359 PROBLEMS AND POINTS TO PONDER 361 FURTHER READINGS AND INFORMATION SOURCES 362CHAPTER 14 ARCHITECTURAL DESIGN 365 14.1 Software Architecture 366 14.1.1 What Is Architecture? 366 14.1.2 Why Is Architecture Important? 367 14.2 Data Design 368 14.2.1 Data Modeling, Data Structures, Databases, and the Data Warehouse 368 14.2.2 Data Design at the Component Level 369 14.3 Architectural Styles 371 14.3.1 A Brief Taxonomy of Styles and Patterns 371 14.3.2 Organization and Refinement 374 14.4 Analyzing Alternative Architectural Designs 375 14.4.1 An Architecture Trade-off Analysis Method 375 14.4.2 Quantitative Guidance for Architectural Design 376 14.4.3 Architectural Complexity 378 14.5 Mapping Requirements into a Software Architecture 378 14.5.1 Transform Flow 379 14.5.2 Transaction Flow 380 14.6 Transform Mapping 380 14.6.1 An Example 380 14.6.2 Design Steps 381 14.7 Transaction Mapping 389 14.7.1 An Example 390 14.7.2 Design Steps 390
  16. 16. xvi CONTENTS 14.8 Refining the Architectural Design 394 14.9 Summary 395 REFERENCES 396 PROBLEMS AND POINTS TO PONDER 397 FURTHER READINGS AND INFORMATION SOURCES 399 CHAPTER 15 U S E R I N T E R FA C E D E S I G N 401 15.1 The Golden Rules 402 15.1.1 Place the User in Control 402 15.1.2 Reduce the User’s Memory Load 404 15.1.3 Make the Interface Consistent 404 15.2 User Interface Design 405 15.2.1 Interface Design Models 405 15.2.2 The User Interface Design Process 407 15.3 Task Analysis and Modeling 408 15.4 Interface Design Activities 410 15.4.1 Defining Interface Objects and Actions 410 15.4.2 Design Issues 413 15.5 Implementation Tools 415 15.6 Design Evaluation 416 15.7 Summary 418 REFERENCES 418 PROBLEMS AND POINTS TO PONDER 419 FURTHER READINGS AND INFORMATION SOURCES 420 CHAPTER 16 COMPONENT-LEVEL DESIGN 423 16.1 Structured Programming 424 16.1.1 Graphical Design Notation 425 16.1.2 Tabular Design Notation 427 16.1.3 Program Design Language 429 16.1.4 A PDL Example 430 16.2 Comparison of Design Notation 432 16.3 Summary 433 REFERENCES 433 PROBLEMS AND POINTS TO PONDER 434 FURTHER READINGS AND INFORMATION SOURCES 435 CHAPTER 17 S O F T WA R E T E S T I N G T E C H N I Q U E S 437 17.1 Software Testing Fundamentals 438 17.1.1 Testing Objectives 439 17.1.2 Testing Principles 439 17.1.3 Testability 440 17.2 Test Case Design 443 17.3 White-Box Testing 444 17.4 Basis Path Testing 445 17.4.1 Flow Graph Notation 445 17.4.2 Cyclomatic Complexity 446 17.4.3 Deriving Test Cases 449 17.4.4 Graph Matrices 452 17.5 Control Structure Testing 454 17.5.1 Condition Testing 454
  17. 17. CONTENTS xvii 17.5.2 Data Flow Testing 456 17.5.3 Loop Testing 458 17.6 Black-Box Testing 459 17.6.1 Graph-Based Testing Methods 460 17.6.2 Equivalence Partitioning 463 17.6.3 Boundary Value Analysis 465 17.6.4 Comparison Testing 465 17.6.5 Orthogonal Array Testing 466 17.7 Testing for Specialized Environments, Architectures, and Applications 468 17.7.1 Testing GUIs 469 17.7.2 Testing of Client/Server Architectures 469 17.7.3 Testing Documentation and Help Facilities 469 17.7.4 Testing for Real-Time Systems 470 17.8 Summary 472 REFERENCES 473 PROBLEMS AND POINTS TO PONDER 474 FURTHER READINGS AND INFORMATION SOURCES 475CHAPTER 18 S O F T WA R E T E S T I N G S T R AT E G I E S 477 18.1 A Strategic Approach to Software Testing 478 18.1.1 Verification and Validation 479 18.1.2 Organizing for Software Testing 479 18.1.3 A Software Testing Strategy 480 18.1.4 Criteria for Completion of Testing 482 18.2 Strategic Issues 484 18.3 Unit Testing 485 18.3.1 Unit Test Considerations 485 18.3.2 Unit Test Procedures 487 18.4 Integration Testing 488 18.4.1 Top-down Integration 488 18.4.2 Bottom-up Integration 490 18.4.3 Regression Testing 491 18.4.4 Smoke Testing 492 18.4.5 Comments on Integration Testing 493 18.4.6 Integration Test Documentation 494 18.5 Validation Testing 495 18.5.1 Validation Test Criteria 495 18.5.2 Configuration Review 496 18.5.3 Alpha and Beta Testing 496 18.6 System Testing 496 18.6.1 Recovery Testing 497 18.6.2 Security Testing 497 18.6.3 Stress Testing 498 18.6.4 Performance Testing 498 18.7 The Art of Debugging 499 18.7.1 The Debugging Process 499 18.7.2 Psychological Considerations 500 18.7.3 Debugging Approaches 501 18.8 Summary 502 REFERENCES 503 PROBLEMS AND POINTS TO PONDER 504 FURTHER READINGS AND INFORMATION SOURCES 505
  18. 18. xviii CONTENTS CHAPTER 19 T E C H N I C A L M E T R I C S F O R S O F T WA R E 507 19.1 Software Quality 508 19.1.1 McCall’s Quality Factors 509 19.1.2 FURPS 511 19.1.3 ISO 9126 Quality Factors 513 19.1.4 The Transition to a Quantitative View 513 19.2 A Framework for Technical Software Metrics 514 19.2.1 The Challenge of Technical Metrics 514 19.2.2 Measurement Principles 515 19.2.3 The Attributes of Effective Software Metrics 516 19.3 Metrics for the Analysis Model 517 19.3.1 Function-Based Metrics 518 19.3.2 The Bang Metric 520 19.3.3 Metrics for Specification Quality 522 19.4 Metrics for the Design Model 523 19.4.1 Architectural Design Metrics 523 19.4.2 Component-Level Design Metrics 526 19.4.3 Interface Design Metrics 530 19.5 Metrics for Source Code 531 19.6 Metrics for Testing 532 19.7 Metrics for Maintenance 533 19.8 Summary 534 REFERENCES 534 PROBLEMS AND POINTS TO PONDER 536 FURTHER READING AND OTHER INFORMATION SOURCES 537PA R T F O U R — O B J E C T - O R I E N T E D S O F T WA R E E N G I N E E R I N G 539 CHAPTER 20 OBJECT-ORIENTED CONCEPTS AND PRINCIPLES 541 20.1 The Object-Oriented Paradigm 542 20.2 Object-Oriented Concepts 544 20.2.1 Classes and Objects 546 20.2.2 Attributes 547 20.2.3 Operations, Methods, and Services 548 20.2.4 Messages 548 20.2.5 Encapsulation, Inheritance, and Polymorphism 550 20.3 Identifying the Elements of an Object Model 553 20.3.1 Identifying Classes and Objects 553 20.3.2 Specifying Attributes 557 20.3.3 Defining Operations 558 20.3.4 Finalizing the Object Definition 559 20.4 Management of Object-Oriented Software Projects 560 20.4.1 The Common Process Framework for OO 560 20.4.2 OO Project Metrics and Estimation 562 20.4.3 An OO Estimating and Scheduling Approach 564 20.4.4 Tracking Progress for an OO Project 565 20.5 Summary 566 REFERENCES 566 PROBLEMS AND POINTS TO PONDER 567 FURTHER READINGS AND INFORMATION SOURCES 568
  19. 19. CONTENTS xixCHAPTER 21 O B J E C T - O R I E N T E D A N A LY S I S 571 21.1 Object-Oriented Analysis 572 21.1.1 Conventional vs. OO Approaches 572 21.1.2 The OOA Landscape 573 21.1.3 A Unified Approach to OOA 575 21.2 Domain Analysis 576 21.2.1 Reuse and Domain Analysis 577 21.2.2 The Domain Analysis Process 577 21.3 Generic Components of the OO Analysis Model 579 21.4 The OOA Process 581 21.4.1 Use-Cases 581 21.4.2 Class-Responsibility-Collaborator Modeling 582 21.4.3 Defining Structures and Hierarchies 588 21.4.4 Defining Subjects and Subsystems 590 21.5 The Object-Relationship Model 591 21.6 The Object-Behavior Model 594 21.6.1 Event Identification with Use-Cases 594 21.6.2 State Representations 595 21.7 Summary 598 REFERENCES 599 PROBLEMS AND POINTS TO PONDER 600 FURTHER READINGS AND INFORMATION SOURCES 601CHAPTER 22 OBJECT-ORIENTED DESIGN 603 22.1 Design for Object-Oriented Systems 604 22.1.1 Conventional vs. OO Approaches 605 22.1.2 Design Issues 607 22.1.3 The OOD Landscape 608 22.1.4 A Unified Approach to OOD 610 22.2 The System Design Process 611 22.2.1 Partitioning the Analysis Model 612 22.2.2 Concurrency and Subsystem Allocation 613 22.2.3 The Task Management Component 614 22.2.4 The User Interface Component 615 22.2.5 The Data Management Component 615 22.2.6 The Resource Management Component 616 22.2.7 Intersubsystem Communication 616 22.3 The Object Design Process 618 22.3.1 Object Descriptions 618 22.3.2 Designing Algorithms and Data Structures 619 22.3.3 Program Components and Interfaces 621 22.4 Design Patterns 624 22.4.1 Describing a Design Pattern 624 22.4.2 Using Patterns in Design 625 22.5 Object-Oriented Programming 625 22.6 Summary 626 REFERENCES 627 PROBLEMS AND POINTS TO PONDER 628 FURTHER READINGS AND INFORMATION SOURCES 629
  20. 20. xx CONTENTS CHAPTER 23 OBJECT-ORIENTED TESTING 631 23.1 Broadening the View of Testing 632 23.2 Testing OOA and OOD Models 633 23.2.1 Correctness of OOA and OOD Models 633 23.2.2 Consistency of OOA and OOD Models 634 23.3 Object-Oriented Testing Strategies 636 23.3.1 Unit Testing in the OO Context 636 23.3.2 Integration Testing in the OO Context 637 23.3.3 Validation Testing in an OO Context 637 23.4 Test Case Design for OO Software 637 23.4.1 The Test Case Design Implications of OO Concepts 638 23.4.2 Applicability of Conventional Test Case Design Methods 638 23.4.3 Fault-Based Testing 639 23.4.4 The Impact of OO Programming on Testing 640 23.4.5 Test Cases and the Class Hierarchy 641 23.4.6 Scenario-Based Test Design 641 23.4.7 Testing Surface Structure and Deep Structure 643 23.5 Testing Methods Applicable at the Class Level 644 23.5.1 Random Testing for OO Classes 644 23.5.2 Partition Testing at the Class Level 644 23.6 Interclass Test Case Design 645 23.6.1 Multiple Class Testing 645 23.6.2 Tests Derived from Behavior Models 647 23.7 Summary 648 REFERENCES 649 PROBLEMS AND POINTS TO PONDER 649 FURTHER READINGS AND INFORMATION SOURCES 650 CHAPTER 24 TECHNICAL METRICS FOR OBJECT-ORIENTED SYSTEMS 653 24.1 The Intent of Object-Oriented Metrics 654 24.2 The Distinguishing Characteristics of Object-Oriented Metrics 654 24.2.1 Localization 655 24.2.2 Encapsulation 655 24.2.3 Information Hiding 655 24.2.4 Inheritance 656 24.2.5 Abstraction 656 24.3 Metrics for the OO Design Model 656 24.4 Class-Oriented Metrics 658 24.4.1 The CK Metrics Suite 658 24.4.2 Metrics Proposed by Lorenz and Kidd 661 24.4.3 The MOOD Metrics Suite 662 24.5 Operation-Oriented Metrics 664 24.6 Metrics for Object-Oriented Testing 664 24.7 Metrics for Object-Oriented Projects 665 24.8 Summary 666 REFERENCES 667 PROBLEMS AND POINTS TO PONDER 668 FURTHER READINGS AND INFORMATION SOURCES 669
  21. 21. CONTENTS xxiPA R T F I V E — A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G 671 CHAPTER 25 FORMAL METHODS 673 25.1 Basic Concepts 674 25.1.1 Deficiencies of Less Formal Approaches 675 25.1.2 Mathematics in Software Development 676 25.1.3 Formal Methods Concepts 677 25.2 Mathematical Preliminaries 682 25.2.1 Sets and Constructive Specification 683 25.2.2 Set Operators 684 25.2.3 Logic Operators 686 25.2.4 Sequences 686 25.3 Applying Mathematical Notation for Formal Specification 687 25.4 Formal Specification Languages 689 25.5 Using Z to Represent an Example Software Component 690 25.6 The Ten Commandments of Formal Methods 693 25.7 Formal Methods—The Road Ahead 694 25.8 Summary 695 REFERENCES 695 PROBLEMS AND POINTS TO PONDER 696 FURTHER READINGS AND INFORMATION SOURCES 697 CHAPTER 26 C L E A N R O O M S O F T WA R E E N G I N E E R I N G 699 26.1 The Cleanroom Approach 700 26.1.1 The Cleanroom Strategy 701 26.1.2 What Makes Cleanroom Different? 703 26.2 Functional Specification 703 26.2.1 Black-Box Specification 705 26.2.2 State-Box Specification 705 26.2.3 Clear-Box Specification 706 26.3 Cleanroom Design 706 26.3.1 Design Refinement and Verification 707 26.3.2 Advantages of Design Verification 710 26.4 Cleanroom Testing 712 26.4.1 Statistical Use Testing 712 26.4.2 Certification 714 26.5 Summary 714 REFERENCES 715 PROBLEMS AND POINTS TO PONDER 716 FURTHER READINGS AND INFORMATION SOURCES 717 CHAPTER 27 C O M P O N E N T - B A S E D S O F T WA R E E N G I N E E R I N G 721 27.1 Engineering of Component-Based Systems 722 27.2 The CBSE Process 724 27.3 Domain Engineering 725 27.3.1 The Domain Analysis Process 726 27.3.2 Characterization Functions 727 27.3.3 Structural Modeling and Structure Points 728 27.4 Component-Based Development 730 27.4.1 Component Qualification, Adaptation, and Composition 730
  22. 22. xxii CONTENTS 27.4 2 Component Engineering 734 27.4.3 Analysis and Design for Reuse 734 27.5 Classifying and Retrieving Components 735 27.5.1 Describing Reusable Components 736 27.5.2 The Reuse Environment 738 27.6 Economics of CBSE 739 27.6.1 Impact on Quality, Productivity, and Cost 739 27.6.2 Cost Analysis Using Structure Points 741 27.6.3 Reuse Metrics 741 27.7 Summary 742 REFERENCES 743 PROBLEMS AND POINTS TO PONDER 744 FURTHER READINGS AND INFORMATION SOURCES 745 CHAPTER 28 C L I E N T / S E R V E R S O F T WA R E E N G I N E E R I N G 747 28.1 The Structure of Client/Server Systems 748 28.1.1 Software Components for c/s Systems 750 28.1.2 The Distribution of Software Components 750 28.1.3 Guidelines for Distributing Application Subsystems 752 28.1.4 Linking c/s Software Subsystems 753 28.1.5 Middleware and Object Request Broker Architectures 753 28.2 Software Engineering for c/s Systems 755 28.3 Analysis Modeling Issues 755 28.4 Design for c/s Systems 755 28.4.1 Architectural Design for Client/Server Systems 756 28.4.2 Conventional Design Approaches for Application Software 757 28.4.3 Database Design 758 28.4.4 An Overview of a Design Approach 759 28.4.5 Process Design Iteration 761 28.5 Testing Issues 761 28.5.1 Overall c/s Testing Strategy 762 28.5.2 c/s Testing Tactics 763 28.6 Summary 764 REFERENCES 764 PROBLEMS AND POINTS TO PONDER 765 FURTHER READINGS AND INFORMATION SOURCES 766 CHAPTER 29 WEB ENGINEERING 769 29.1 The Attributes of Web-Based Applications 771 29.1.1 Quality Attributes 773 29.1.2 The Technologies 773 29.2 The WebE Process 774 29.3 A Framework for WebE 775 29.4 Formulating/Analyzing Web-Based Systems 776 29.4.1 Formulation 776 29.4.2 Analysis 778 29.5 Design for Web-Based Applications 779 29.5.1 Architectural Design 780 29.5.2 Navigation Design 783 29.5.3 Interface Design 785
  23. 23. CONTENTS xxiii 29.6 Testing Web-Based Applications 786 29.7 Management Issues 787 29.7.1 The WebE Team 788 29.7.2 Project Management 789 29.7.3 SCM Issues for WebE 792 29.8 Summary 794 REFERENCES 795 PROBLEMS AND POINTS TO PONDER 796 FURTHER READINGS AND INFORMATION SOURCES 797CHAPTER 30 REENGINEERING 799 30.1 Business Process Reengineering 800 30.1.1 Business Processes 800 30.1.2 Principles of Business Process Reengineering 801 30.1.3 A BPR Model 802 30.1.4 Words of Warning 804 30.2 Software Reengineering 804 30.2.1 Software Maintenance 804 30.2.2 A Software Reengineering Process Model 805 30.3 Reverse Engineering 809 30.3.1 Reverse Engineering to Understand Processing 810 30.3.2 Reverse Engineering to Understand Data 811 30.3.3 Reverse Engineering User Interfaces 812 30.4 Restructuring 813 30.4.1 Code Restructuring 814 30.4.2 Data Restructuring 814 30.5 Forward Engineering 814 30.5.1 Forward Engineering for Client/Server Architectures 816 30.5.2 Forward Engineering for Object-Oriented Architectures 817 30.5.3 Forward Engineering User Interfaces 818 30.6 The Economics of Reengineering 819 30.7 Summary 820 REFERENCES 820 PROBLEMS AND POINTS TO PONDER 822 FURTHER READINGS AND INFORMATION SOURCES 823CHAPTER 31 C O M P U T E R - A I D E D S O F T WA R E E N G I N E E R I N G 825 31.1 What is CASE? 826 31.2 Building Blocks for CASE 826 31.3 A Taxonomy of CASE Tools 828 31.4 Integrated CASE Environments 833 31.5 The Integration Architecture 834 31.6 The CASE Repository 836 31.6.1 The Role of the Repository in I-CASE 836 31.6.2 Features and Content 837 31.7 Summary 841 REFERENCES 842 PROBLEMS AND POINTS TO PONDER 842 FURTHER READINGS AND INFORMATION SOURCES 843
  24. 24. xxiv CONTENTS CHAPTER 32 THE ROAD AHEAD 845 32.1 The Importance of Software—Revisited 846 32.2 The Scope of Change 847 32.3 People and the Way They Build Systems 847 32.4 The "New" Software Engineering Process 848 32.5 New Modes for Representing Information 849 32.6 Technology as a Driver 851 32.7 A Concluding Comment 852 REFERENCES 853 PROBLEMS AND POINTS TO PONDER 853 FURTHER READINGS AND INFORMATION SOURCES 853
  25. 25. P R E FA C E hen a computer software succeeds—when it meets the needs of the peopleW who 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, whenit is difficult to change and even harder to use—bad 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-ing has evolved from an obscure idea practiced by a relatively small number of zealotsto a legitimate engineering discipline. Today, it is recognized as a subject worthy ofserious research, conscientious study, and tumultuous debate. Throughout the indus-try, software engineer has replaced programmer as the job title of preference. Softwareprocess models, software engineering methods, and software tools have been adoptedsuccessfully across a broad spectrum of industry applications. Although managers and practitioners alike recognize the need for a more disci-plined approach to software, they continue to debate the manner in which disciplineis to be applied. Many individuals and companies still develop software haphazardly,even as they build systems to service the most advanced technologies of the day.Many professionals and students are unaware of modern methods. And as a result,the quality of the software that we produce suffers and bad things happen. In addi-tion, debate and controversy about the true nature of the software engineeringapproach continue. The status of software engineering is a study in contrasts. Atti-tudes have changed, progress has been made, but much remains to be done beforethe discipline reaches full maturity. The fifth edition of Software Engineering: A Practitioners 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-tation more 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 xxv
  26. 26. xxvi P R E FA C E SepaWeb, can be found at http://www.mhhe.com/pressman. Designed to be used in conjunction with the fifth edition of Software Engineering: A Practitioners 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 Instructors Guide for Software Engineering: A Practitioners Approach is avail- able from SepaWeb. The Instructors Guide presents suggestions for conducting var-
  27. 27. P R E FA C E xxviiious types of software engineering courses, recommendations for a variety of soft-ware projects to be conducted in conjunction with a course, solutions to selectedproblems, and a number of teaching aids. A comprehensive video curriculum, Essential Software Engineering, is available tocomplement this book. The video curriculum has been designed for industry train-ing and has been modularized to enable individual software engineering topics to bepresented on an as-needed, when-needed basis. Further information on the videocan be obtained by mailing the request card at the back of this book.1 My work on the five editions of Software Engineering: A Practitioner’s Approach hasbeen the longest continuing technical project of my life. Even when the writing stops,information extracted from the technical literature continues to be assimilated andorganized. For this reason, my thanks to the many authors of books, papers, and arti-cles as well as a new generation of contributors to electronic media (newsgroups, e-newsletters, and the World Wide Web) who have provided me with additional insight,ideas, and commentary over the past 20 years. Many have been referenced withinthe pages of each chapter. All deserve credit for their contribution to this rapidly evolv-ing field. I also wish to thank the reviewers of the fifth edition: Donald H. Kraft,Louisiana State University; Panos E. Livadas, University of Florida; Joseph Lambert,Pennsylvania State University; Kenneth L. Modesitt, University of Michigan—Dear-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 Michigan—Dearborn, who assisted me in developing the Web sitethat accompanies this book. Bruce is responsible for much of its design and peda-gogical content. The content of the fifth edition of Software Engineering: A Practitioners Approachhas been shaped by industry professionals, university professors, and students whohave used earlier editions of the book and have taken the time to communicate theirsuggestions, criticisms, and ideas. My thanks to each of you. In addition, my personalthanks go to our many industry clients worldwide, who certainly teach me as muchor more than I can teach them. As the editions of this book have evolved, my sons, Mathew and Michael, havegrown from boys to men. Their maturity, character, and success in the real worldhave been an inspiration to me. Nothing has 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 at http://www.rspa.com/ese or e-mail a request for information to info@rspa.com.
  28. 28. USING THIS BOOK T he fifth edition of Software Engineering: A Practitioner’s Approach (SEPA) has been redesigned to enhance your reading experience and to provide integrated links to the SEPA Web site, http://www.mhhe.com/pressman/. SepaWeb contains a wealth of useful supplementary information for readers of the book and a broad array of resources (e.g., an 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: The keypoint icon will help you The WebRef icon provides Used to emphasize an WebRef to find important points quickly. direct pointers to important important point in the For pointers that will take software engineering related body of the text. you directly to Web Web sites. resources The advice icon provides prag- matic guidance that can help The SepaWeb pointer indicates Practical advice from you make the right decision or that further information about the real world of avoid common problems while the noted topic is available at software engineering. building software. the SEPA Web site. A selected topic The question mark icon asks ? Where can I find the common questions that are The SepaWeb.checklists icon answer? answered in the body of the points you to detailed checklists text. that will help you to assess the The xref icon will point you to software engineering work XRef another part of the book where you’re doing and the work Provides an important cross reference within information relevant to the cur- products you produce. the book. rent discussion can be found. The SepaWeb.documents The quote icon presents inter- icon points you to detailed doc- esting quotes that have rele- “Important words” ument outlines, descriptions vance to the topic at hand. and examples contained within the SEPA Web site. 1 If the card is missing, please visit the R.S. Pressman & Associates, Inc. Web site atxxviii http://www.rspa.com/ese, or e-mail to info@rspa.com.
  29. 29. PA R TOne THE PRODUCT AND THE PROCESS n this part of Software Engineering: A Practitioner’s Approach, you’ll I learn about the product that is to be engineered and the process that provides a framework for the engineering technology. The following questions are addressed in the chapters that follow: • What is computer software . . . really? • Why do we struggle to build high-quality computer-based systems? • How can we categorize application domains for computer software? • What myths about software still exist? • What is a “software process”? • Is there a generic way to assess the quality of a process? • What process models can be applied to software develop- ment? • How do linear and iterative process models differ? • What are their strengths and weaknesses? • What advanced process models have been proposed for soft- ware engineering work? Once these questions are answered, you’ll be better prepared to understand the management and technical aspects of the engi- neering discipline to which the remainder of this book is dedicated. 1
  30. 30. CHAPTER 1 THE PRODUCTKEY T he warnings began more than a decade before the event, but no one paidCONCEPTS much attention. With less than two years to the deadline, the mediaapplication picked up the story. Then government officials voiced their concern, busi-categories . . . . . . . 9 ness and industry leaders committed vast sums of money, and finally, dire warn-component-basedassembly. . . . . . . . . 8 ings of pending catastrophe penetrated the public’s consciousness. Software,failure curves . . . . . 8 in the guise of the now-infamous Y2K bug, would fail and, as a result, stop thehistory . . . . . . . . . . 5 world as we then knew it. As we watched and wondered during the waning months of 1999, I couldn’tmyths . . . . . . . . . . 12 help thinking of an unintentionally prophetic paragraph contained on the firstreuse . . . . . . . . . . . . 9 page of the fourth edition of this book. It stated:softwarecharacteristics . . . . 6 Computer software has become a driving force. It is the engine that drives businesssoftware decision making. It serves as the basis for modern scientific investigation and engi-engineering . . . . . . 4 neering problem solving. It is a key factor that differentiates modern products andwear . . . . . . . . . . . . 7 services. It is embedded in systems of all kinds: transportation, medical, telecom- munications, military, industrial processes, entertainment, 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. QUICK What is it? Computer software is What are the steps? You build computer software LOOK the product that software engi- like you build any successful product, by apply- neers design and build. It encom- ing a process that leads to a high-quality result passes programs that execute within a computer that meets the needs of the people who will use of any size and architecture, documents that the product. You apply a software engineering encompass hard-copy and virtual forms, and approach. data that combine numbers and text but also What is the work product? From the point of view of includes representations of pictorial, video, and a software engineer, the work product is the pro- audio information. grams, documents, and data that are computer Who does it? Software engineers build it, and virtu- software. But from the user’s viewpoint, the work ally everyone in the industrialized world uses it product is the resultant information that somehow either directly or indirectly. makes the user’s world better. Why is it important? Because it affects nearly every How do I ensure that I’ve done it right? Read the aspect of our lives and has become pervasive in remainder of this book, select those ideas appli- our commerce, our culture, and our everyday cable to the software that you build, and apply activities. them to your work. 3
  31. 31. 4 PA R T O N E THE PRODUCT AND THE PROCESS 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-“Ideas and nologies that will make it easier, faster, and less expensive to build high-quality com- technological discoveries are the puter programs. Some of these technologies are targeted at a specific application driving engines of domain (e.g., Web-site design and implementation); others focus on a technology economic growth.” domain (e.g., object-oriented systems); and still others are broad-based (e.g., oper- The Wall Street ating systems such as LINUX). However, we have yet to develop a software technol- Journal 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 T H E E V O LV I N G R O L E O F S O F T WA R E 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-Software is both a ing, acquiring, modifying, displaying, or transmitting information that can be as sim-product and a vehicle ple as a single bit or as complex as a multimedia presentation. As the vehicle usedfor delivering aproduct. to deliver the product, software acts as the basis for the control of the computer (oper- ating systems), the communication of information (networks), and the creation 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-
  32. 32. CHAPTER 1 THE PRODUCT 5 found changes in computing architectures, vast increases in memory and storage capacity, and a wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. Sophistication and com- plexity can produce dazzling results when a system succeeds, but they can also pose huge problems for those who must build complex systems. Popular books published during the 1970s and 1980s provide useful historical insight into the changing perception of computers and software and their impact on“For I dipped into the our culture. Osborne [OSB79] characterized a "new industrial revolution." Toffler future, far as the [TOF80] called the advent of microelectronics part of "the third wave of change" in human eye could human history, and Naisbitt [NAI82] predicted a transformation from an industrial see, Saw the vision society to an "information society." Feigenbaum and McCorduck [FEI83] suggested of the world, and all the wonder that that information and knowledge (controlled by computers) would be the focal point would be.” for power in the twenty-first century, and Stoll [STO89] argued that the "electronic Tennyson 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“Computers make it [YOU92] worried that U.S. companies might loose their competitive edge in software- easy to do a lot of related businesses and predicted “the decline and fall of the American programmer.” things, but most of the things that they Hammer and Champy [HAM93] argued that information technologies were to play a make it easier to do pivotal role in the “reengineering of the corporation.” During the mid-1990s, the per- dont need to be vasiveness of computers and software spawned a rash of books by “neo-Luddites” done.” (e.g., Resisting the Virtual Life, edited by James Brook and Iain Boal and The Future Andy Rooney Does Not Compute by Stephen Talbot). These authors demonized the computer, empha- sizing legitimate concerns but ignoring the profound 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:
  33. 33. 6 PA R T O N E THE PRODUCT AND THE PROCESS • Why does it take so long to get software finished? • Why are development costs so high? • Why cant 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 S O F T WA R E 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-? Howdefine we should 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. Theresoftware? 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.Software isengineered, not Although some similarities exist between software development and hardware man-manufactured. ufacture, the two activities are fundamentally different. In both activities, high qual- 1 In an excellent book of essays on the software business, Tom DeMarco [DEM95] argues the coun- terpoint. He states: “Instead of asking ‘why does software cost so much?’ we need to begin ask- ing ‘What have we done to make it possible for today’s software to cost so little?’ The answer to that question will help us continue the extraordinary level of achievement that has always distin- guished the software industry.”
  34. 34. CHAPTER 1 THE PRODUCT 7F I G U R E 1.1Failure curvefor hardware “Infant “Wear out” mortality” Failure rate Time 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.Software doesn’t wear 2. Software doesnt "wear out."out, but it does Figure 1.1 depicts failure rate as a function of time for hardware. The relationship,deteriorate. often called the "bathtub curve," indicates that hardware exhibits relatively high fail- ure rates early in its life (these failures are often attributable to design or manufac- turing defects); defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some period of time. As time passes, however, the failure 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 doesnt 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