1. Software Engineering A P R A C T I T I O N E R S A P P R O A
C H
2. McGraw-Hill Series in Computer Science Senior Consulting
Editor C. L. Liu, National Tsing Hua University Consulting Editor
Allen B. Tucker, Bowdoin College Fundamentals of Computing and
Programming Computer Organization and Architecture Systems and
Languages Theoretical Foundations Software Engineering and
Databases Articial Intelligence Networks, Parallel and Distributed
Computing Graphics and Visualization The MIT Electrical and
Computer Science Series Software Engineering and Databases Atzeni,
Ceri, Paraborschi, and Torlone, Database Systems, 1/e Mitchell,
Machine Learning, 1/e Musa, Iannino, and Okumoto, Software
Reliability, 1/e Pressman, Software Engineering: A Beginners Guide,
1/e Pressman, Software Engineering: A Practioners Guide, 5/e
Ramakrishnan/Gehrke, Database Management Systems, 2/e Schach,
Classical and Object- Oriented Software Engineering with UML and
C++, 4/e Schach, Classical and Object- Oriented Software
Engineering with UML and Java, 1/e
3. Software Engineering A 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, WI New York San Francisco St. Louis Bangkok
Bogot Caracas Lisbon London Madrid Mexico City Milan New Delhi
Seoul Singapore Sydney Taipei Toronto
4. SOFTWARE ENGINEERING Published by McGraw-Hill, an imprint of
The McGraw-Hill Companies, Inc. 1221 Avenue of the Americas, 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 any form or by any
means, or stored in a database or retrieval system, without the
prior written consent of The McGraw-Hill Companies, Inc.,
including, but not limited to, in any network or other electronic
storage 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 Casson
Executive editor: Betsy Jones Developmental editor: Emily Gray
Marketing manager: John Wannemacher Project manager: Karen J.
Nelson Production supervisor: Heather Burbridge Coordinator
freelance design: Keith McPherson Supplement coordinator: Rose
Range New media: Christopher Styles Cover design: Rhiannon Erwin
Cover illustrator: Joseph Gilians Compositor: Carlisle
Communications, Ltd. Typeface: 8.5/13.5 Leawood Printer: R. R.
Donnelley & Sons Company Library of Congress
Cataloging-in-Publication Data Pressman, Roger S. Software
engineering: a practitioners approach / Roger S. Pressman.5th ed.
p. cm. (McGraw-Hill series in computer science) Includes index.
ISBN 0-07-365578-3 1. Software engineering. I. Title. II. Series.
QA76.758.P75 2001 005.1dc21 00-036133 http://www.mhhe.com
McGraw-Hill Higher Education A Division of The McGraw-Hill
Companies
5. To my parents
6. vi Roger 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
scientic and systems programming. After receiving a Ph.D. in
engineering from the University of Connecticut, Dr. Pressman moved
to academia where he became Bullard Associate Professor of Computer
Engineering at the University of Bridgeport and director of the
university's Computer-Aided Design and Manufacturing Center. Dr.
Pressman is currently president of R.S. Pressman & Associates,
Inc., a consulting rm specializing in software engineering methods
and training. He serves as principle con- sultant, helping
companies establish effective software engineering practices. He
also designed and developed the companys software engineering
training and process improve- ment productsEssential Software
Engineering, a complete video curriculum that is among the
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 rst book
to address the critical management problems associated with
software process improvement; and Software Shock (Dorset House), a
treat- ment that focuses on software and its impact on business and
society. Dr. Pressman is on the Editorial Boards of IEEE Software
and the Cutter IT Journal, and for many years, was editor of the
Manager column in IEEE Software. Dr. Pressman is a well-known
speaker, keynoting a number of major industry confer- ences. He has
presented tutorials at the International Conference on Software
Engineer- ing and at many other industry meetings. He is a member
of the ACM, IEEE, and Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu, and
Pi Tau Sigma. ABOUT THE AUTHOR
7. 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
Conguration 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
8. 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
9. ix PART ONETHE PRODUCT AND THE PROCESS 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
TABLE OF CONTENTS
10. CONTENTSx PART TWOMANAGING SOFTWARE PROJECTS 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 SOFTWARE PROCESS AND PROJECT
METRICS 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 Efciency
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. CONTENTS xi PROBLEMS AND POINTS TO PONDER 109 FURTHER
READINGS AND INFORMATION SOURCES 110 CHAPTER 5 SOFTWARE PROJECT
PLANNING 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 142 CHAPTER 6 RISK
ANALYSIS AND MANAGEMENT 145 6.1 Reactive versus Proactive Risk
Strategies 146 6.2 Software Risks 146 6.3 Risk Identication 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 Renement 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. CONTENTSxii 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 Dening a Task Set for the
Software Project 172 7.3.1 Degree of Rigor 173 7.3.2 Dening
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 Renement of Major
Tasks 178 7.6 Dening 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 SOFTWARE
QUALITY ASSURANCE 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 Amplication 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. CONTENTS xiii 8.9 Mistake-Proong 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
SOFTWARE CONFIGURATION MANAGEMENT 225 9.1 Software Conguration
Management 226 9.1.1 Baselines 227 9.1.2 Software Conguration Items
228 9.2 The SCM Process 230 9.3 Identication of Objects in the
Software Conguration 230 9.4 Version Control 232 9.5 Change Control
234 9.6 Conguration 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 240 PART
THREECONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 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 Specication 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. CONTENTSxiv CHAPTER 11 ANALYSIS CONCEPTS AND PRINCIPLES 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 Specication 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 Specication 291
11.5.1 Specication Principles 291 11.5.2 Representation 292 11.5.3
The Software Requirements Specication 293 11.6 Specication Review
294 11.7 Summary 294 REFERENCES 295 PROBLEMS AND POINTS TO PONDER
296 FURTHER READINGS AND INFORMATION SOURCES 297 CHAPTER 12
ANALYSIS MODELING 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 Specication 325 12.6.5 The Process
Specication 327 12.7 The Data Dictionary 328 12.8 Other Classical
Analysis Methods 330 12.9 Summary 331 REFERENCES 331 PROBLEMS AND
POINTS TO PONDER 332 FURTHER READINGS AND INFORMATION SOURCES
334
15. CONTENTS xv CHAPTER 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 Renement 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 362 CHAPTER 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 Renement 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. CONTENTSxvi 14.8 Rening the Architectural Design 394 14.9
Summary 395 REFERENCES 396 PROBLEMS AND POINTS TO PONDER 397
FURTHER READINGS AND INFORMATION SOURCES 399 CHAPTER 15 USER
INTERFACE DESIGN 401 15.1 The Golden Rules 402 15.1.1 Place the
User in Control 402 15.1.2 Reduce the Users 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 Dening 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 SOFTWARE TESTING TECHNIQUES
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. 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 475 CHAPTER 18
SOFTWARE TESTING STRATEGIES 477 18.1 A Strategic Approach to
Software Testing 478 18.1.1 Verication 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 Conguration 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. CONTENTSxviii CHAPTER 19 TECHNICAL METRICS FOR SOFTWARE 507
19.1 Software Quality 508 19.1.1 McCalls 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 Specication 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 537 PART FOUROBJECT-ORIENTED SOFTWARE
ENGINEERING 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
Dening Operations 558 20.3.4 Finalizing the Object Denition 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. CONTENTS xix CHAPTER 21 OBJECT-ORIENTED ANALYSIS 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 Unied 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
Dening Structures and Hierarchies 588 21.4.4 Dening Subjects and
Subsystems 590 21.5 The Object-Relationship Model 591 21.6 The
Object-Behavior Model 594 21.6.1 Event Identication 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 601 CHAPTER 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 Unied 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. CONTENTSxx 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. CONTENTS xxi PART FIVEADVANCED TOPICS IN SOFTWARE
ENGINEERING 671 CHAPTER 25 FORMAL METHODS 673 25.1 Basic Concepts
674 25.1.1 Deciencies 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 Specication 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 Specication 687 25.4 Formal Specication
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 MethodsThe Road Ahead 694 25.8 Summary 695 REFERENCES 695
PROBLEMS AND POINTS TO PONDER 696 FURTHER READINGS AND INFORMATION
SOURCES 697 CHAPTER 26 CLEANROOM SOFTWARE ENGINEERING 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 Specication 703
26.2.1 Black-Box Specication 705 26.2.2 State-Box Specication 705
26.2.3 Clear-Box Specication 706 26.3 Cleanroom Design 706 26.3.1
Design Renement and Verication 707 26.3.2 Advantages of Design
Verication 710 26.4 Cleanroom Testing 712 26.4.1 Statistical Use
Testing 712 26.4.2 Certication 714 26.5 Summary 714 REFERENCES 715
PROBLEMS AND POINTS TO PONDER 716 FURTHER READINGS AND INFORMATION
SOURCES 717 CHAPTER 27 COMPONENT-BASED SOFTWARE ENGINEERING 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 Qualication, Adaptation, and Composition
730
22. CONTENTSxxii 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 CLIENT/SERVER SOFTWARE
ENGINEERING 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. 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 797 CHAPTER 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 823
CHAPTER 31 COMPUTER-AIDED SOFTWARE ENGINEERING 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. CONTENTSxxiv CHAPTER 32 THE ROAD AHEAD 845 32.1 The
Importance of SoftwareRevisited 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. PREFACE xxv When a computer software succeedswhen it meets
the needs of the people who use it, when it performs awlessly over
a long period of time, when it is easy to modify and even easier to
useit can and does change things for the better. But when software
failswhen its users are dissatised, when it is error prone, when it
is difcult to change and even harder to usebad 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 rst
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 fth edition of Software Engineering: A
Practitioner's Approach is intended to serve as a guide to a
maturing engineering discipline. The fth 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 rst year graduate level. The format
and style of the fth edition have undergone signicant change,
making the presen- tation more reader-friendly and the content more
easily accessible. The fth edition is considerably more than a
simple update. The book has been revised to accommodate the
dramatic growth in the eld 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
26. PREFACExxvi SepaWeb, can be found at
http://www.mhhe.com/pressman. Designed to be used in conjunction
with the fth edition of Software Engineering: A Practitioner's
Approach, SepaWeb provides a broad array of software engineering
resources that will benet instructors, students, and industry
professionals. Like all Web sites, SepaWeb will evolve over time,
but the following major con- tent areas will always be present: (1)
a broad array of instructor resources including a comprehensive
on-line Instructors Guide and supplementary teaching materials
(e.g., slide presentations to supplement lectures, video-based
instructional aids); (2) a wide variety of student resources
including an extensive on-line learning center (encompassing study
guides, Web-based resources, and self-tests), an evolving col-
lection of tiny tools, a case study, and additional supplementary
content; and (3) a detailed collection of professional resources
including outlines (and samples of) soft- ware engineering
documents and other work products, a useful set of software engi-
neering checklists, a catalog of software engineering (CASE) tools,
a comprehensive collection of Web-based resources, and an adaptable
process model that provides a detailed task breakdown of the
software engineering process. In addition, Sepa- Web will contain
other goodies that are currently in development. The 32 chapters of
the fth edition have been organized into ve parts. This has been
done to compartmentalize topics and assist instructors who may not
have the time to complete the entire book in one term. Part One,
The Product and the Process, presents an introduction to the
software engineering milieu. It is intended to intro- duce the
subject matter, and more important, to present concepts that will
be nec- essary for later chapters. Part Two, Managing Software
Projects, presents topics that are relevant to those who plan,
manage, and control a software development proj- ect. Part Three,
Conventional Methods for Software Engineering, presents the clas-
sical analysis, design, and testing methods that some view as the
conventional school of software engineering. Part Four,
Object-Oriented Software Engineering, presents object-oriented
methods across the entire software engineering process, including
analysis, design, and testing. Part Five, Advanced Software
Engineering Topics, presents dedicated chapters that address formal
methods, cleanroom soft- ware engineering, component-based software
engineering, client/server software engineering, Web engineering,
reengineering, and CASE. The ve-part organization of the fth
edition enables an instructor to "cluster" top- ics based on
available time and student need. An entire one-term course can be
built around one or more of the ve parts. For example, a "design
course" might empha- size only Part Three or Part Four; a "methods
course" might present selected chap- ters in Parts Three, Four, and
Five. A "management course" would stress Parts One and Two. By
organizing the fth edition in this way, I attempted to provide an
instruc- tor with a number of teaching options. SepaWeb can and
should be used to supple- ment the content that is chosen from the
book. An Instructor's Guide for Software Engineering: A
Practitioner's Approach is avail- able from SepaWeb. The
Instructor's Guide presents suggestions for conducting var-
27. 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 ve editions of Software Engineering: A Practitioners 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 MichiganDear- 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 MichiganDearborn, 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 fth 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 lled me with more pride. And nally, 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 at
http://www.rspa.com/ese or e-mail a request for information to
[email protected].
28. xxviii USING THIS BOOK The fifth edition of Software
Engineering: A Practitioners 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 Instructors Guide,
classroom slides, and video supplements) for instructors who have
adopted SEPA for classroom use. A comprehensive video curriculum,
Essential Software Engineering, is available to com- plement this
book. The video curriculum has been designed for industry training
and has been modularized to enable individual software engineering
topics to be presented on an as-needed, when-needed basis. Further
information on the video can be obtained by mail- ing the request
card at the back of this book.1 Throughout the book, you will
encounter marginal icons that should be interpreted in the
following manner: Used to emphasize an important point in the body
of the text. Practical advice from the real world of software
engineering. Where can I nd the answer? ? XRef Provides an
important cross reference within the book. The keypoint icon will
help you to nd important points quickly. The advice icon provides
prag- matic guidance that can help you make the right decision or
avoid common problems while building software. The question mark
icon asks common questions that are answered in the body of the
text. The xref icon will point you to another part of the book
where information 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 provides direct
pointers to important software engineering related Web sites. The
SepaWeb pointer indicates that further information about the noted
topic is available at the SEPA Web site. The SepaWeb.checklists
icon points you to detailed checklists that will help you to assess
the software engineering work youre doing and the work products you
produce. The SepaWeb.documents icon points you to detailed doc-
ument outlines, descriptions and examples contained within the SEPA
Web site. Important words WebRef For pointers that will take you
directly to Web resources A selected topic 1 If the card is
missing, please visit the R.S. Pressman & Associates, Inc. Web
site at http://www.rspa.com/ese, or e-mail to [email protected].
29. 1 P A R T I n this part of Software Engineering: A
Practitioners Approach, youll learn about the product that is to be
engineered and the process that provides a framework for the
engineering technology. The following questions are addressed in
the chapters that follow: What is computer software . . . really?
Why do we struggle to build high-quality computer-based systems?
How can we categorize application domains for computer software?
What myths about software still exist? What is a software process?
Is there a generic way to assess the quality of a process? What
process models can be applied to software develop- ment? How do
linear and iterative process models differ? What are their
strengths and weaknesses? What advanced process models have been
proposed for soft- ware engineering work? Once these questions are
answered, youll be better prepared to understand the management and
technical aspects of the engi- neering discipline to which the
remainder of this book is dedicated. THE PRODUCT AND THE PROCESS
One
30. 3 C H A P T E R K E Y C O N C E P T S application
categories . . . . . . . 9 component-based assembly. . . . . . . .
. 8 failure curves. . . . . 8 history . . . . . . . . . . 5 myths .
. . . . . . . . . 12 reuse . . . . . . . . . . . . 9 software
characteristics . . . . 6 software engineering . . . . . . 4 wear .
. . . . . . . . . . . 7 T he warnings began more than a decade
before the event, but no one paid much attention. With less than
two years to the deadline, the media picked up the story. Then
government ofcials voiced their concern, busi- ness and industry
leaders committed vast sums of money, and nally, dire warn- ings of
pending catastrophe penetrated the publics 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 couldnt help thinking
of an unintentionally prophetic paragraph contained on the rst 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 scientic
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, ofce
products, . . . the list is almost endless. Software is virtually
inescapable in a modern world. And as we move into the twenty-rst
century, it will become the driver for new advances in everything
from elementary education to genetic engineering. 1 THE PRODUCT
What is it? Computer software is the 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 every aspect of our lives and has become pervasive
in our commerce, our culture, and our everyday activities. What are
the steps? You build computer software like 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 of a software engineer, the
work product is the pro- grams, documents, and data that are
computer software. But from the users viewpoint, the work product
is the resultant information that somehow makes the users world
better. How do I ensure that Ive done it right? Read the remainder
of this book, select those ideas appli- cable to the software that
you build, and apply them to your work. Q U I C K L O O K
31. PART ONE THE PRODUCT AND THE PROCESS4 In the ve years since
the fourth edition of this book was written, the role of soft- ware
as the driving force has become even more obvious. A
software-driven Inter- net has spawned its own $500 billion
economy. In the euphoria created by the 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
softwares industrys largest company, just as it did in earlier eras
when it moved to stop monopolistic practices in the oil and steel
industries. Softwares 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
softwarepeople 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
transformerproducing, 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 timeinformation. Software transforms
personal data (e.g., an individuals nancial 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 signicant change over a time span
of little more than 50 years. Dramatic improvements in hardware
performance, pro- Ideas and technological discoveries are the
driving engines of economic growth. The Wall Street Journal
Software is both a product and a vehicle for delivering a
product.
32. 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-rst 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, Tofer [TOF90] described a "power shift"
in which old power structures (governmental, educational,
industrial, economic, and military) disinte- grate as computers and
software lead to a "democratization of knowledge." 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 benets that have
already been realized. [LEV95] During the later 1990s, Yourdon
[YOU96] re-evaluated the prospects for the software professional
and suggested the the rise and resurrection of the Ameri- can
programmer. As the Internet grew in importance, his change of heart
proved to be correct. As the twentieth century closed, the focus
shifted once more, this time to the impact of the Y2K time bomb
(e.g., [YOU98b], [DEJ98], [KAR99]). Although the predictions of the
Y2K doomsayers were incorrect, their popular writings drove home
the pervasiveness of software in our lives. Today, ubiquitous
computing [NOR98] has spawned a generation of information
appliances that have broadband connectivity to the Web to provide a
blanket of connectedness over our homes, offices and motorways
[LEV99]. Softwares role continues to expand. The lone programmer of
an earlier era has been replaced by a team of software specialists,
each focusing on one part of the technology required to deliver a
com- plex application. And yet, the same questions asked of the
lone programmer are being asked when modern computer-based systems
are built: 5 For I dipped into the future, far as the human eye
could see, Saw the vision of the world, and all the wonder that
would be. Tennyson Computers make it easy to do a lot of things,
but most of the things that they make it easier to do don't need to
be done. Andy Rooney
33. PART ONE THE PRODUCT AND THE PROCESS6 Why does it take so
long to get software nished? Why are development costs so high? Why
can't we nd all the errors before we give the software to
customers? Why do we continue to have difculty 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 developeda 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 denitions could be offered. But
we need more than a formal denition. 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 should we dene 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 todays 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.
Software is engineered, not manufactured.
34. CHAPTER 1 THE PRODUCT 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 attens as shown.The
idealized curve is a gross over- simplication of actual failure
models (see Chapter 8 for more information) for software. However,
the implication is clearsoftware 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 outInfant
mortality Time Failurerate FIGURE 1.1 Failure curve for hardware
Software doesnt wear out, but it does deteriorate.
35. PART ONE THE PRODUCT AND THE PROCESS8 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 risethe 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 dened and validated
function, a well-dened 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.2 Idealized
and actual failure curves for software Increased failure rate due
to side effects Time Failurerate Change Actual curve Idealized
curve Most software continues to be custom built. Software
engineering methods strive to reduce the magnitude of the spikes
and the slope of the actual curve in Figure 1.2.
36. CHAPTER 1 THE PRODUCT 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
scientic subroutine libraries that were reusable in a broad array
of engineering and scientic applications. These subroutine
libraries reused well-dened 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 prespecied set of procedural steps
(i.e., an algorithm) has been dened (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
predened 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 difcult 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 le manage- ment utilities) process
complex, but determinate, information structures. Other sys- tems
applications (e.g., operating system components, drivers,
telecommunications 9 XRef Software reuse is discussed in Chapter
13. Component-based software engineering is presented in Chapter
27.
37. PART ONE THE PRODUCT AND THE PROCESS10 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 scientic software.
Engineering and scientic software have been characterized by
"number crunching" algorithms. Applications range from astron- omy
to volcanology, from automotive stress analysis to space shuttle
orbital dynam- ics, and from molecular biology to automated
manufacturing. However, modern applications within the
engineering/scientic area are moving away from conven- tional
numerical algorithms. Computer-aided design, system simulation, and
other interactive applications have begun to take on real-time and
even system software characteristics. Embedded software.
Intelligent products have become commonplace in nearly every
consumer and industrial market. Embedded software resides in
read-only mem- ory and is used to control products and systems for
the consumer and industrial mar- kets. Embedded software can
perform very limited and esoteric functions (e.g., keypad control
for a microwave oven) or provide signicant function and control
capability (e.g., digital functions in an automobile such as fuel
control, dashboard displays, and braking systems). Personal
computer software. The personal computer software market has bur-
geoned over the past two decades. Word processing, spreadsheets,
computer graph- ics, multimedia, entertainment, database
management, personal and business nancial applications, external
network, and database access are only a few of hundreds of
applications. Web-based software. The Web pages retrieved by a
browser are software that incorporates executable instructions
(e.g., CGI, HTML, Perl, or Java), and data (e.g., One of the most
comprehensive libraries of shareware/freeware can be found at
www.shareware.com
38. CHAPTER 1 THE PRODUCT 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 dened 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 denition: "the turning point in the course of a disease,
when it becomes clear whether the patient will live or die." This
denition may give 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 afiction
is dened as "anything causing pain or distress." But the denition
of the adjective chronic is the key to our argument: "lasting a
long time or recurring often; continuing indenitely." It is far
more accurate to describe the problems we have endured in the
software business as a chronic afiction than a crisis. Regardless
of what we call it, the set of problems that are encountered in the
devel- opment of computer software is not limited to software that
"doesn't function 11 2 This terminology was suggested by Professor
Daniel Tiechrow of the University of Michigan in a talk presented
in Geneva, Switzerland, April 1989. The most likely way for the
world to be destroyed, most experts agree, is by accident. That's
where we come in; we're computer professionals. We cause accidents.
Nathaniel Borenstein
39. PART ONE THE PRODUCT AND THE PROCESS12 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 afiction to this dayin fact, the
industry prospers in spite of it. And yet, things would be much
better if we could nd and broadly apply a cure. 1.4 SOFTWARE MYTHS
Many causes of a software afiction 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 difcult 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 building software, 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 software
practitioners aware of its existence? Does it reect modern software
engineering prac- tice? Is it complete? Is it streamlined to
improve time to delivery while still main- taining a focus on
quality? In many cases, the answer to all of these questions is
"no." Myth: My people have state-of-the-art software development
tools, after all, we buy them the newest computers. Reality: It
takes much more than the latest model mainframe, workstation, or PC
to 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 of meaningful standards, a new industry
like software comes to depend instead on folklore. Tom DeMarco
40. CHAPTER 1 THE PRODUCT later." At rst, 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 relax and let that rm build it. Reality: If
an organization does not understand how to manage and control
software projects 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 sufcient to begin writing programs we
can ll in the details later. Reality: A poor up-front denition is
the major cause of failed software efforts. A formal 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 exible. Reality: It is true that
software requirements change, but the impact of change varies with
the time at which it is introduced. Figure 1.3 illustrates the
impact of change. If serious attention is given to up-front
denition, early requests for change can be accommodated easily. The
customer can review requirements and recom- mend modications 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
modication, 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 Project Managers Network at www.spmn.com
can help you dispel these and other myths. XRef The management and
control of change is considered in detail in Chapter 9. 3 The term
outsourcing refers to the widespread practice of contracting
software development work to a third partyusually a consulting rm
that specializes in building custom software for its clients. Work
very hard to understand what you have to do before you start. You
may not be able to develop every detail, but the more you know, the
less risk you take.
41. PART ONE THE PRODUCT AND THE PROCESS14 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 longer it'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 rst time.
Myth: Until I get the program "running" I have no way of assessing
its quality. Reality: One of the most effective software quality
assurance mechanisms can be applied from the inception of a
projectthe formal technical review. Software reviews (described in
Chapter 8) are a "quality lter" that have been found to be more
effec- tive than testing for nding certain classes of software
defects. Myth: The only deliverable work product for a successful
project is the working program. Reality: A working program is only
one part of a software conguration that includes many 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 rst step toward
formulation of practical solutions for software engineering. 1
Definition 1.56 Development 60100 After release Costtochange FIGURE
1.3 The impact of change Whenever you think, we dont have time for
software engineering discipline, ask yourself: Will we have time to
do it over again?
42. CHAPTER 1 THE PRODUCT 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 conguration 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 FailureAmazing 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.
104105. [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 WildThe
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] Tofer, A., The Third Wave, Morrow, 1980.
15
43. PART ONE THE PRODUCT AND THE PROCESS16 [TOF90] Tofer, A.,
Powershift, Bantam Publishers, 1990. [YOU92] Yourdon, E., The
Decline and Fall of the American Programmer, Yourdon Press, 1992.
[YOU96] Yourdon, E., The Rise and Resurrection of the American
Programmer, Your- don Press, 1996. [YOU98a] Yourdon, E., Death
March Projects, Prentice-Hall, 1998. [YOU98b] Yourdon, E. and J.
Yourdon, Time Bomb 2000, Prentice-Hall, 1998. PROBLEMS AND POINTS
TO PONDER 1.1. Software is the differentiating characteristic in
many computer-based products and systems. Provide examples of two
or three products and at least one system in which software, not
hardware, is the differentiating element. 1.2. In the 1950s and
1960s, computer programming was an art form learned in an
apprenticelike environment. How have the early days affected
software development practices today? 1.3. Many authors have
discussed the impact of the "information era." Provide a number of
examples (both positive and negative) that indicate the impact of
software on our society. Review one of the pre-1990 references in
Section 1.1 and indicate where the authors predictions were right
and where they were wrong. 1.4. Choose a specic application and
indicate: (a) the software application category (Section 1.2.2)
into which it ts; (b) the data content associated with the
application; and (c) the information determinacy of the
application. 1.5. As software becomes more pervasive, risks to the
public (due to faulty pro- grams) become an increasingly
significant concern. Develop a realistic doomsday scenario (other
than Y2K) where the failure of a computer program could do great
harm (either economic or human). 1.6. Peruse the Internet newsgroup
comp.risks and prepare a summary of risks to the public that have
recently been discussed. An alternate source is Software Engi-
neering Notes published by the ACM. 1.7. Write a paper summarizing
recent advances in one of the leading edge soft- ware application
areas. Potential choices include: advanced Web-based applications,
virtual reality, articial neural networks, advanced human
interfaces, intelligent agents. 1.8. The myths noted in Section 1.4
are slowly fading as the years pass, but oth- ers are taking their
place. Attempt to add one or two new myths to each category.
44. CHAPTER 1 THE PRODUCT FURTHER READINGS AND INFORMATION
SOURCES Literally thousands of books are written about computer
software. The vast major- ity discuss programming languages or
software applications, but a few discuss soft- ware itself.
Pressman and Herron (Software Shock, Dorset House, 1991) presented
an early discussion (directed at the layperson) of software and the
way professionals build it. Negroponte's (Being Digital, Alfred A.
Knopf, 1995) best-selling book provides a view of computing and its
overall impact in the twenty-rst century. Books by Nor- man [NOR98]
and Bergman (Information Appliances and Beyond, Academic Press/Mor-
gan Kaufmann, 2000) suggest that the widespread impact of the PC
will decline as information appliances and pervasive computing
connect everyone in the indus- trialized world and almost every
appliance that they own to a new Internet infrastructure. Minasi
(The Software Conspiracy: Why Software Companies Put out Faulty
Products, How They Can Hurt You, and What You Can Do, McGraw-Hill,
2000) argues that the modern scourge of software bugs can be
eliminated and suggests ways to accom- plish this. DeMarco (Why
Does Software Cost So Much? Dorset House, 1995) has pro- duced a
collection of amusing and insightful essays on software and the
process through which it is developed. A wide variety of
information sources on software-related topics and manage- ment is
available on the Internet. An up-to-date list of World Wide Web
references that are relevant to software can be found at the SEPA
Web site:
http://www.mhhe.com/engcs/compsci/pressman/resources/product.mhtml
17
45. 19 C H A P T E R K E Y C O N C E P T S common process
framework . . . . . . 23 component-based development. . . . . 42
concurrent development. . . . . 40 evolutionary process models. . .
. . . . . . . 34 formal methods . . 43 4GT . . . . . . . . . . . .
44 maintenance activities . . . . . . . 21 process maturity levels.
. . . . . . . . . . 24 prototyping . . . . . 30 RAD. . . . . . . .
. . . . 32 software engineering. . . . . . 20 I n a fascinating
book that provides an economists view of software and soft- ware
engineering, Howard Baetjer, Jr. [BAE98], comments on the software
process: Because software, like all capital, is embodied knowledge,
and because that knowl- edge is initially dispersed, tacit, latent,
and incomplete in large measure, software development is a social
learning process. The process is a dialogue in which the knowledge
that must become the software is brought together and embodied in
the software. The process provides interaction between users and
designers, between users and evolving tools, and between designers
and evolving tools [technology]. It is an iterative process in
which the evolving tool itself serves as the medium for com-
munication, with each new round of the dialogue eliciting more
useful knowledge from the people involved. Indeed, building
computer software is an iterative learning process, and the
outcome, something that Baetjer would call software capital, is an
embodi- ment of knowledge collected, distilled, and organized as
the process is con- ducted. 2 THE PROCESS What is it? When you
build a product or system, its important to go through a series of
pre- dictable stepsa road map that helps you create a timely,
high-quality result. The road map that you follow is called a
software process. Who does it? Software engineers and their man-
agers adapt the process to their needs and then follow it. In
addition, the people who have requested the software play a role in
the software process. Why is it important? Because it provides
stability, control, and organization to an activity that can, if
left uncontrolled, become quite chaotic. What are the steps? At a
detailed level, the process that you adopt depends on the software
youre building. One process might be appropriate for creating
software for an aircraft avionics system, while an entirely
different process would be indi- cated for the creation of a Web
site. What is the work product? From the point of view of a
software engineer, the work products are the programs, documents,
and data produced as a consequence of the software engineering
activi- ties dened by the process. How do I ensure that Ive done it
right? A number of software process assessment mechanisms enable
organizations to determine the maturity of a software process.
However, the quality, timeliness, and long-term viability of the
product you build are the best indicators of the efcacy of the
process that you use. Q U I C K L