To my parents
SOFTWARE ENGINEERING:
A PRACTITIONER’S APPROACH
Copyright by The McGraw-Hill Companies, Inc. All
R
rights reserved. Printed in the United States of America. Except as permitted oger S. Pressman is an internationally recognized consultant and author
under the United States Copyright Act of 1976, no part of this publication may in software eneineerine. He received a B.S.E. (cum laude) from the
be reproduced or distributed in any form or by any means, or stored in a data University of from the University of Bridgeport and a
base or retrieval system, without the prior written permission of the publisher.
Ph.D. in engineering from the University of Connecticut, and has over 25 years
This book is printed on acid-free paper. of industry experience, holding both technical and management positions with
responsibility for the development of software for engineered products and
3 4 5 6 7 8 9 0 FGR FGR 9 0 9 8 7 terns.
As an industry practitioner and manager, Dr. Pressman worked on the de-
velopment of CAD/CAM systems engineering and manufacturing
I S B N in aerospace applications. He has also held positions with responsibility for sci-
This book was set in New Century Schoolbook by York Graphic Sen rices, Inc entific and systems programming.
The editor Eric M. Munson; In addition to his industry experience, Dr. Pressman was Bullard Associate
The production supervisor was Annette Mayeski. Professor of Computer Engineering at the University of Bridgeport and Director
Cover illustration and design by Joseph of the University’s Computer-Aided Design and Manufacturing Center.
New drawings were done by York Production Services. Dr. Pressman is President of R.S. Pressman & Associates, Inc., a consult-
Project supervision was done by York Production Services. ing firm specializing in software engineering methods and training. He serves
Printing/Fairfield was printer and binder. as principal consultant, specializing in helping companies establish effective
Library of Congress Cataloging-in-Publication Data is available.
software engineering practices. He developed the software engineering
LC Card
assessment method, a unique blend of quantitative and qualitative analysis
that helps clients assess their current state of software engineering practice.
International Edition
Copyright 1997. Exclusive rights by The McGraw-Hill Companies, Inc. for In addition to consulting services rendered to many Fortune 500 clients,
manufacture and export. This book cannot be re-exported from the country to R.S. Pressman Associates, Inc. markets a wide variety of software engineer-
which it is consigned by McGraw-Hill. The International Edition is not avail- ing training products and process improvement services. The company has de-
able in North America. veloped a state-of-the-art video curriculum, Essential Software Engineering,
When ordering this title, use ISBN o-07-114603-2. which is among the industry’s most comprehensive treatments of the subject.
ABOUT THE AUTHOR
Another product, Process Advisor, is a self-directed system for software process
improvement.
Dr. Pressman is author of 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 Making Software
Engineering Happen (Prentice Hall), the first book to address the critical man-
agement problems associated with software engineering process improvement,
Software Shock House), a treatment of software and its impact on busi-
ness and society, and A Manager’s Guide to Software Engineering (McGraw- \’
Hill), a book that uses a unique Q&A format to management guidelines
for instituting and understanding the technology. Dr. Pressman is on the edi-
torial boards of American Programmer and IEEE Software, and is editor of the
“Manager” column in IEEE Software. He is a member of the ACM, IEEE, and
Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu, nnd Pi Tau Sigma.
PREFACE
PART ONE THE PRODUCT AND THE PROCESS 1
CHAPTER 1 THE PRODUCT
CHAPTER 2 THE PROCESS
PART TWO MANAGING SOFTWARE PROJECTS 55
CHAPTER 3 PROJECT MANAGEMENT CONCEPTS 57
CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 76
CHAPTER 5 SOFTWARE PROJECT PLANNING 102
CHAPTER 6 RISK MANAGEMENT 132
CHAPTER 7 PROJECT SCHEDULING AND TRACKING 153
CHAPTER 8 SOFTWARE QUALITY ASSURANCE 179
CHAPTER 9 SOFTWARE CONFIGURATION MANAGEMENT 209
PART THREE CONVENTIONAL METHODS FOR ENGINEERING 229
CHAPTER 10 SYSTEM ENGINEERING 231
CHAPTER 1 ANALYSIS CONCEPTS AND PRINCIPLES 270
CHAPTER 12 ANALYSIS MODELING 298
CHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 341
viii CONTENTS AT A GLANCE
CHAPTER 14 DESIGN METHODS 371
CHAPTER 15 DESIGN FOR REAL-TIME SYSTEMS 423
CHAPTER 16 SOFTWARE TESTING TECHNIQUES 448
CHAPTER 17 SOFTWARE TESTING STRATEGIES 487
CHAPTER 18 TECHNICAL METRICS FOR SOFTWARE 517
PART FOUR SOFTWARE ENGINEERING 549
CHAPTER 19 CONCEPTS AND PRINCIPLES 551
CHAPTER 20 OBJECTORIENTED ANALYSIS 581
CHAPTER 21 OBJECT-ORIENTED DESIGN 614
CHAPTER 22 OBJECTORIENTED TESTING 644
CHAPTER 23 TECHNICAL METRICS FOR OBJECT-ORIENTED SYSTEMS 664
PARTFIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING 679
CHAPTER 24 FORMAL METHODS 681
CHAPTER 25 707
CHAPTER 26 I
CHAPTER 27 756
CHAPTER 28 SOFTWARE ENGINEERING 784
CHAPTER 29 COMPUTER-AIDED SOFTWARE ENGINEERING 805 PREFACE xxv
CHAPTER 30 THE ROAD AHEAD 826
PART ONE THE PRODUCT AND THE PROCESS 1
INDEX 840
CHAPTER 1 THE PRODUCT 3
1.1 THE EVOLVING ROLE OF SOFTWARE 4
1.1 An Industry Perspective 7
1.1.2 An Aging Software Plant
11 ‘Software Competitiveness
SOFTWARE
1 Software Characteristics
1.2.2 Components 13
1 Software Applications 14
1.3 A CRISIS ON THE HORIZON 16
1.4 SOFTWARE MYTHS
1.5 SUMMARY
REFERENCES 19
PROBLEMS AND POINTS TO PONDER 20
FURTHER READINGS AND INFORMATION SOURCES 21
CHAPTER 2 THE PROCESS 22
2.1 SOFTWARE LAYERED TECHNOLOGY 22
2.1 1 Process, Methods, and Tools 23
2.1.2 A Generic View of Software Engineering 24
ix
X TABLE OF CONTENTS Xi
2.2 THE SOFTWARE PROCESS 26 4.2. Process Metrics and Software Process Improvement 78
2.3 SOFTWARE PROCESS MODELS 4.2.2 Project Metrics
2.4 THE LINEAR SEQUENTIAL MODEL 4.3 SOFTWARE MEASUREMENT
2.5 THE MODEL 32 4.3.1 Metrics
2.6 THE RAD MODEL 34 4.3.2 Function-Oriented Metrics
2.7 EVOLUTIONARY SOFTWARE PROCESS MODELS 4.3.3 Extended Function Point Metrics 87
2.7. The incremental Model 4.4 RECONCILING DIFFERENT METRICS APPROACHES 90
2.7.2 The 4.5 METRICS FOR SOFTWARE QUALITY
2.7.3 The Assembly Model 42 4.5.1 An Overview of Factors That Affect Quality
2.7.4 The Model 43 4.5.2 Measuring Quality 93
2.8 THE METHODS 45 4.5.3 Defect Removal Efficiency
2.9 FOURTH GENERATION TECHNIQUES 46 4.6 INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
2.10 PROCESS TECHNOLOGY 47 4.7 SUMMARY 97
2.11 PRODUCT AND PROCESS 48 REFERENCES 98
2.12 ‘SUMMARY 49 PROBLEMS AND POINTS TO PONDER 99
REFERENCES 49 FURTHER READINGS AND OTHER INFORMATION SOURCES 100
PROBLEMS AND POINTS TO PONDER 50
FURTHER READINGS AND OTHER INFORMATION SOURCES 51
CHAPTER 5 SOFTWARE PROJECT 102
PART TWO MANAGING SOFTWARE PROJECTS 55 5.1 OBSERVATIONS ON ESTIMATING 102
5.2 PROJECT PLANNING OBJECTIVES 104
57 5.3 SOFTWARE SCOPE 104
CHAPTER 3 PROJECT MANAGEMENT CONCEPTS
Obtaining Information Necessary for Scope 104
3. THE MANAGEMENT SPECTRUM 58 5.3.2 A Scoping Example
3.1.1 People 58 5.4 RESOURCES , 108
3.1.2 T h e P r o b l e m 58 5.4.1 H u m a n R e s o u r c e s 109
3. The Process 59 5.4.2 Reusable Software Resources 109
3.2 PEOPLE 59 5.4.3 Environmental Resources 110
3 2.1 The Players 60 5.5 SOFTWARE PROJECT ESTIMATION
3.2.2 T e a m L e a d e r s 60 5.6 DECOMPOSITION TECHNIQUES 112
3.2.3 The Team 5.6. Software Sizing 112
3.2.4 Coordination and Communication Issues 65 5.6.2 Problem-Based Estimation 113
3.3 THE PROBLEM 5.6.3 An Example of LOC-Bosed Estimation 115
3.3.1 Software Scope 5.6.4 An Example of FP-Based Estimation 116
3.3.2 Problem Decomposition 67 5.6.5 Process-Based Estimation 118
3 4 THE PROCESS 68 5.6.6 An Exomple of Process-Based Estimation 118
3.4.1 Melding the Problem and the Process 69 5.7 EMPIRICAL ESTIMATION MODELS 120
2 Process Decomposition 70 5.7.1 The Structure of Estimation Models 120
3.5 THE PROJECT 71 5.7.2 The COCOMO Model 121
3.6 SUMMARY 72 5.7.3 The Software Equation 124
REFERENCES 72 5.8 THE MAKE-BUY 125
PROBLEMS AND POINTS TO PONDER 73 Creating a Decision Tree 126
FURTHER READINGS AND OTHER 74 5.8.2 Outsourcing 127
5.9 AUTOMATED ESTIMATION TOOLS 128
CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 76 5.10 SUMMARY 129
REFERENCES 129
4.1 MEASURES, METRICS, AND INDICATORS 77 PROBLEMS AND POINTS TO PONDER 129
4.2 METRICS IN THE PROCESS PROJECT DOMAINS 77 FURTHER READINGS AND OTHER SOURCES 130
...
xii TABLE OF CONTENTS TABLE OF CONTENTS
CHAPTER RISK MANAGEMENT 132 8 ASSURANCE
6.1 REACTIVE VS. PROACTIVE RISK STRATEGIES 133 8.1 QUALITY CONCEPTS 180
6.2 SOFTWARE RISKS 133 8.1.1 181
6.3 RISK 134 8.1 Quality Control 181
6.3.1 Product Size Risks 135 8.1 Quality Assurance 182
6.3.2 Business Impact Risks 136 8.1.4 Cost of Quality 182
6.3.3 Customer-Related Risks 136 8.2 THE QUALITY MOVEMENT 184
6.3.4 Process Risks 137 8.3 SOFTWARE ASSURANCE 185
6.3.5 Technology Risk 139 Background Issues 185
6.3.6 Development Environment Risks 8.3.2 SQA Activities 186
6.3.7 Risks Associated with Staff Size and Experience 140 8.4 SOFTWARE REVIEWS’ 187
6.3.8 Risk Components and Drivers 141 8.4.1 Cost lmpoct of Software Defects 188
6.4 RISK PROJECTION 141 8.4.2 Defect Amplification and Removal 189
6.4.1 Developing a Risk Table 141 8.5 TECHNICAL REVIEWS 190
6.4.2 Assessing Risk impact 144 8.5 1 T h e R e v i e w M e e t i n g 191
6.4.3 Risk Assessment 145 8.5.2 Review Reporting ond Record Keeping 192
6.5 RISK MITIGATION, MONITORING, AND MANAGEMENT 146 8.5.3 Review Guidelines 193
6.6 SAFETY RISKS AND HAZARDS 148 8.6 FORMAL APPROACHES TO SQA 194
6.7 THE 149 8.7 STATISTICAL QUALITY ASSURANCE 195
SUMMARY 149 8 8 SOFTWARE 197
REFERENCES 150 8 1 Measures of and 198
PROBLEMS AND POINTS PONDER 8.8.2 and 198
READINGS AND OTHER INFORMATION SOURCES 151 8.9 THE SQA
8.10 THE 9000 QUALITY STANDARDS
8.10 1 The Approach to Quality Assurance Systems 202
CHAPTER 7 PROJECT SCHEDULING AND TRACKING 153 8.10.2 The 9001 Standard 202
7.1 8.11 SUMMARY 203
BASIC CONCEPTS 154
REFERENCES 204
7.1 1 Comments on “lateness” 154
PROBLEMS AND POINTS TO PONDER 205
7.1 Basic Principles 156
FURTHER READINGS AND OTHER INFORMATION SOURCES 206
7.2 THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT 157
7.2.1 An Examole 1.58
7.2.2 An Relationship 158
7.2.3 Effort Distribution 159 CHAPTER 9 SOFTWARE CONFIGURATION MANAGEMENT 209
7.3 DEFINING A TASK SET FOR THE SOFTWARE PROJECT 160
7.3.1 De ree of Rigor 161 9.1 SOFTWARE MANAGEMENT 210
7.3.2 De3ining Adaptation Criteria 161 9.1.1 Baselines 210
7.3.3 Computing a Task Set Selector Value 162 9.1 Software Configuration Items 212
7.3.4 Interpreting the TSS Value and Selecting the Task Set 163 9.2 THE SCM PROCESS 214
7.4 SELECTING SOFTWARE ENGINEERING TASKS 164 9.3 IDENTIFICATION OF OBJECTS IN THE SOFTWARE
7.5 REFINEMENT OF MAJOR TASKS 165 CONFIGURATION 215
7.6 DEFINING A TASK NETWORK 168 9.4 VERSION CONTROL 218
7.7 SCHEDULING 170 9.5 CHANGE CONTROL 220
7.7.1 Charts 170 9.6 CONFIGURATION AUDIT 223
7.7.2 Tracking the Schedule 172 9.7 STATUS REPORTING 224
7.8 THE PROJECT 174 Y.8 SCM STANDARDS 224
7.8 SUMMARY 175 9.9 224
REFERENCES 176 225
PROBLEMS AND POINTS TO PONDER 176 PROBLEMS AND POINTS TO PONDER 226
FURTHER READINGS AND OTHER INFORMATION SOURCES 177 FURTHER READINGS AND OTHER INFORMATION SOURCES 226
TABLE OF CONTENTS TABLE OF CONTENTS xv
PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 229 11.7 SUMMARY 293
REFERENCES 294
CHAPTER ENGINEERING PROBLEMS AND POINTS TO PONDER 295
231
READINGS AND OTHER INFORMATION SOURCES 296
10.1 COMPUTER-BASED SYSTEMS 232
10.2 THE SYSTEM ENGINEERING HIERARCHY 234 CHAPTER 12 ANAlYSlS MODELING 298
10.2.1 System Modeling 235
10 2.2 Information An 237 12.1 A BRIEF HISTORY 299
10.2.3 Product Overview 239 12.2 THE ELEMENTS OF THE ANAlYSlS MODEL ,
10.3 INFORMATION ENGINEERING 241 12.3 DATA MODELING 301
10.4 INFORMATION STRATEGY PLANNING 241 Data Objects, and Relationships 301
10.4.1 Enterprise Modeling 242 12.3.2 and Modality 304
4.2 Business-Level Data Modeling 244 12.3.3 Diagrams 305
10.5 BUSINESS AREA ANALYSIS 245 12.4 FUNCTIONAL AND INFORMATION FLOW 309
10.5.1 Process Modeling 247 12.4.1 Data Diagrams 309
10.5.2 Information Flow Modeling 247 12.4.2 Extensions for Real-Time Systems 312
10.6 PRODUCT ENGINEERING 250 12.4.3 Ward and Extensions 312
System 253 12.4.4 and Pirbhai Extensions 315
10.6.2 Identification of Need 253 12.5 BEHAVIORAL MODELING 316
10.6.3 Feasibility Study 253 12.6 THE MECHANICS OF STRUCTURED 320
10.6.4 Economic Analysis 255 12.6 1 Creating an Entity-Relationship Diagram 321
Technical Analysis 256 2 Creating a Data Flow Model 323
10.7 MODELING THE SYSTEM ARCHITECTURE 259 12.6.3 Creating a Control Flow Model 325
10.8 SYSTEM MODELING AND 262 1 2.6.4 The Control Specification 328
10.9 SYSTEM SPECIFICATION 264 12.6.5 The Process Specification 330
10.10 SUMMARY 264 12.7 THE DATA DICTIONARY 330
REFERENCES 266 12.8 AN OVERVIEW OF OTHER CLASSICAL ANALYSIS
PROBLEMS AND POINTS TO PONDER 266 METHODS 334
FURTHER READINGS AND OTHER INFORMATION SOURCES 268 12.8.1 Data Structured Systems Development 334
12.8.2 Jackson System Development 335
CHAPTER 1 1 ANALYSIS CONCEPTS AND PRINCIPLES 12.8.3 SADT 335
270
12.9 SUMMARY 336
11.1 REQUIREMENTS ANALYSIS 270 REFERENCES 336
11.2 COMMUNICATION TECHNIQUES 272 PROBLEMS AND POINTS TO PONDER 337
1 1 1 Initiating the Process 273 FURTHER READINGS AND OTHER INFORMATION SOURCES 339
1 Facilitated Techniques 274
11 Function Deployment 277 CHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 341
11 ANALYSIS PRINCIPLES 278
1.3.1 The Information Domain 279 13 1 SOFTWARE DESIGN AND SOFTWARE ENGINEERING 341
1.3 2 Modeling 281 13.2 THE DESIGN PROCESS 343
1 1.3.3 Partitioning 282 Design and Quality 343
1 1 Essential and Views 284 The Evolution of Software Design 344
11.4 SOFTWARE 285 13 3 DESIGN PRINCIPLES 345
1 1.4.1 Selecting the 285 13.4 DESIGN CONCEPTS 346
1 Methods and Tools 287 13.4.1 Abstraction 347
11.5 SPECIFICATION 288 13.4.2 Refinement 348
11 1 Specification 288 13 4.3 Modularity 348
1 5.2 Representation 289 13.4.4 Software Architecture 351
1 1 The Software Requirements 290 13.4.5 Control Hierarchy 352
11.6 SPECIFICATION REVIEW 292 13.4.6 Structural Partitioning 353
TABLE OF CONTENTS TABLE OF xvii
1347 Structure 354 14. 5 A Example 412
Software Procedure 355 14.12 SUMMARY 415
13.4.9 Information Hiding 356 REFERENCES 416
13.5 EFFECTIVE MODULAR DESIGN 357 PROBLEMS AND POINTS TO PONDER 417
Functional Independence 357 FURTHER READINGS AND OTHER INFORMATION SOURCES 421
135.2 Cohesion 358
13.5.3 Coupling 359 CHAPTER 15 DESIGN FOR REAL-TIME SYSTEMS 423
13.6 DESIGN HEURISTICS FOR EFFECTIVE MODULARITY 361
13.7 THE DESIGN MODEL 363 15.1 SYSTEM CONSIDERATIONS 424
13.8 DESIGN DOCUMENTATION 363 15.2 REAL-TIME SYSTEMS 425
13.9 SUMMARY 365 15.2.1 Integration and Performance Issues 425
REFERENCES 366 15.2.2 Interrupt Handling 426
PROBLEMS AND POINTS TO PONDER 367 15.2.3 Real-Time Data Bases 426
FURTHER READINGS AND OTHER INFORMATION SOURCES 368 15.2.4 Real-Time Operating Systems 428
15.2.5 Real-Time Languages 429
CHAPTER 14 DESIGN METHODS 371 15.2 6 Synchronization and Communication 430
15.3 ANALYSIS AND SIMULATION OF REAL-TIME SYSTEMS 430
14.1 DATA DESIGN 371 Mathematical Tools for Real-Time System 431
14.2 ARCHITECTURAL DESIGN 373 Simulation and Modeling 435
14.2. Contributors 374 15.4 REAL-TIME DESIGN 442
14.2.2 Areas of Application 374 15.5 SUMMARY 443
14.3 THE ARCHITECTURAL DESIGN PROCESS 375 REFERENCES 444
14 3 1 Transform Flaw 375 AND POINTS TO 445
14.3.2 Transaction Flow 375 READINGS AND SOURCES 445
14.4 TRANSFORM MAPPING 377
14.4.1 An Example 377 CHAPTER 16 SOFTWARE TESTING METHODS 448
14.4.2 Design Steps 378
145 TRANSACTION MAPPING 387 16.1 SOFTWARE TESTING FUNDAMENTALS 449
14.51 An Example 387 16.1 1 Testing Objectives 449
14.5.2 Design Steps 387 16.1 Testina 450
14.6 DESIGN POSTPROCESSING 390 451
14.7 ARCHITECTURAL DESIGN OPTIMIZATION 391 16.2 TEST CASE DESIGN 453
14.8 INTERFACE DESIGN 393 16.3 WHITE BOX TESTING 455
14.8.1 Internal and External Interface Design 394 16.4 BASIS PATH TESTING 455
14.8.2 User Interface Design 394 16.4.1 Flow Graph Notation 456
14.9 HUMANCOMPUTER INTERFACE DESIGN 395 16.4.2 Complexity 458
14.9.1 Interface Design Models 395 16.4.3 Deriving Test Cases 460
14.9.2 Task Analysis and Modeling 396 16.4.4 Graph Matrices 463
14.9.3 Design Issues 398 16.5 CONTROL STRUCTURE TESTING 464
14.9.4 Implementation Tools 400 16.5.1 Condition Testing 465
14.95 Design Evaluation 401 16.5.2 Data Flow Testing 467
14.10 INTERFACE DESIGN GUIDELINES 403 16.5.3 loop Testing 469
14. General Interaction 403 16.6 BLACK-BOX TESTING 470
14.10.2 Information Display 404 Graph-Based Testing Methods 471
14.10.3 Data Input 405 Equivalence Portitioning 474
1 4 . 1 1 PROCEDURAL DESIGN 406 Boundary Value Analysis 475
14.1 1 1 Structured Programming 406 16.6.4 Comparison Testing 476
14.1 1.2 Graphical Design Notation 407 16.7 TESTING FOR SPECIALIZED ENVIRONMENTS 477
14.1 1 Tabular Design Notation 409 Testing 477
14.1 1 4 Program Design language 411 16.7.2 Testing of Client/Server Architectures 479
...
XVIII TABLE OF CONTENTS TABLE OF CONTENTS
16.7.3 Testing Documentation and Help Facilities 479 18.2.2 Measurement Principles 524
16 7.4 for Real-Time Svstems 480 18.2.3 The Attributes of Effective Software Metrics 525
SUMMARY 481 18.3 METRICS FOR THE ANALYSIS MODEL 526
REFERENCES 482 18.3.1 Function-Based Metrics 527
PROBLEMS AND POINTS TO PONDER 483 18.3.2 The Bang Metric 529
FURTHER READINGS AND OTHER INFORMATION 484 18.3.3 Metrics for 531
18.4 THE MODEL 532
CHAPTER 17 SOFTWARE TESTING STRATEGIES 487 Desian Metrics 533
18.4.2 Design Metrics 536
17.1 A STRATEGIC APPROACH TO SOFTWARE TESTING 488 18.4.3 Interface Design Metrics 539
17.1.1 Verification and Validation 488 18.5 SOURCE CODE 540
17.1 Organizing for Software Testing 489 18.6 METRICS FOR TESTING 542
17. A Software Testing y 490 18.7 METRICS FOR MAINTENANCE 543
17.1 Criteria for Completion 492 18.8 SUMMARY 544
17.2 STRATEGIC ISSUES 493 REFERENCES 544
17.3 UNIT TESTING 494 PROBLEMS AND POINTS TO PONDER 546
17.3.1 Unit Test Considerations 495 FURTHER READINGS AND OTHER SOURCES 547
17.3.2 Unit Test Procedures 497
17.4 INTEGRATION TESTING 498
17.4.1 Integration 499 PART FOUR OBJECT-ORIENTED ENGINEERING 549
17.4.2 Bottom-Up Integration 501
17.4.3 Regression Testing 501
17.4.4 Comments on Integration Testing 503 CHAPTER 19 OBJECT-ORIENTED CONCEPTS AND PRINCIPLES 551
17.4.5 Integration Test Documentation 503 19.1
THE OBJECTORIENTED PARADIGM 552
17.5 VALIDATION TESTING 505
OBJECT-ORIENTED
19.2 CONCEPTS 553
17.5.1 Validation Test Criteria 506
19 2 1 Classes and Objects 556
Configuration Review 506
19.2.2 Attributes 557
Alpha and Beta Testing 506
19.2.3 Operotions, Methods, and Services 558
17.6 SYSTEM TESTING 507
19.2 4 Messages 558
17.6. Recovery Testing 507
19.2.5 Encapsulation, Inheritance, and Polymorphism 560
17.6.2 Testing 508
19.3 IDENTIFYING THE ELEMENTS OF AN OBJECT MODEL 564
17.6.3 Stress Testing 508
19.3.1 Classes and 565
17.6.4 Performance Testing 509
19.3.2 Attributes 568
17.7 THE ART OF DEBUGGING 509
19.3.3 Definina 569
17.7.1 The Debugging Process 510
19.3.4 Object Definition 571
17.7.2 Psychological 511
19.4 MANAGEMENT OF OBJECTORIENTED SOFTWARE
17 7.3 Debugging Approaches 511
PROJECTS 571
17.8 513
19.4.1 The Common Process Framework for 00 572
REFERENCES 514
19.4.2 Project Metrics and Estimation 573
PROBLEMS AND POINTS TO PONDER 514
19.4.3 An CO Estimating and Scheduling Approach 575
FURTHER READINGS AND OTHER INFORMATION SOURCES 515
19.4.4 Progress for an Project 576
19.5 SUMMARY 577
CHAPTER 18 TECHNICAL METRICS FOR SOFTWARE 517 REFERENCES 578
PROBLEMS AND POINTS TO PONDER 578
18.1, SOFTWARE QUALITY 518
FURTHER READINGS AND OTHER INFORMATION SOURCES 579
18. 1 McCall’s Quality F a c t o r s 519
18.1.2 FURPS 521
522 CHAPTER 20 OBJECTORIENTED ANALYSIS
18.1 The Transition to a Quantitative View
18.2 A FRAMEWORK FOR TECHNICAL SOFTWARE METRICS 523 20.1 OBJECTORIENTED ANALYSIS 582
18.2.1 The Challenge of Technical Metrics 523 20.1.1 Conventional vs. 00 Approaches 582
xx TABLE OF CONTENTS TABLE OF CONTENTS xxi
20.1.2 The OOA landscape 583 CHAPTER 22 OBJECT-ORIENTED TESTING 644
20.2 DOMAIN 586
20 3 1 Reuse and 22.1 BROADENING THE VIEW OF TESTING
2.2 3
20.3 GENERIC COMPONENTS OF THE 00 22.2.1 Correctness OOA and OOD Models 646
‘MODEL 590 22.2.2 of OOA and OOD Models 646
2 0 . 4 THE OOA PROCESS 591 22.3 STRATEGIES 648
20.4.1 Use Cases 592 22.3.1 Unit Testing in the 00 Context 648
20.4.2 594 22.3.2 Integration Testing in the 00 Context 649
20.4.3 Defining and Hierarchies 599 22.3.3 Validation Testing in an 00 Context 650
20.4.4 Defining and 600 2 2 . 4 TEST CASE DESIGN FOR 00 SOFTWARE 650
2 0 . 5 THE MODEL 601 22.4.1 The Test Case Design Implications of 00
2 0 . 6 THE MODEL 60.5 Concepts 650
20.6.1 Event Identification with Use Cases 605 22.4.2 of Conventional Test Case
20.6.2 State Representations 606 Methods 6.51
2 0 . 7 SUMMARY 609 22 4 3 Fault-Based Testina 651
REFERENCES 610 2 2 . 4 . 4 The Impact of on 652
PROBLEMS AND POINTS TO PONDER 61 1 22.4 5 Test Cases and the Class 653
FURTHER READINGS AND OTHER INFORMATION SOURCES 612 22.4 6 Test 654
22.4.7 Surface Structure ond Deep Structure 65.5
2 2 . 5 TESTING METHODS APPLICABLE AT THE CLASS LEVEL 456
22.5 1 Testing for 00 Classes 656
22.5 2 Partition Testing at the Class level 657
CHAPTER 2 1 OBJECT-ORIENTED DESIGN 614 22.6 TEST CASE DESIGN 658
21.1 DESIGN FOR OBJECT-ORIENTED SYSTEMS 615 22.6.1 Multiple Class Testing 658
31 616 32.6 Tests from Behavior Models 659
2 1.1.2 Design Issues 617 2 2 . 7 SUMMARY 661
2 The OOD 618 REFERENCES 662
21.2 THE GENERIC OF THE 00 DESIGN PROBLEMS AND POINTS TO PONDER 662
MODEL 623 FURTHER READINGS AND OTHER INFORMATION SOURCES 663
21.3 THE SYSTEM DESIGN PROCESS 624 CHAPTER 23 TECHNICAL METRICS FOR OBJECT-ORIENTED SYSTEMS 664
2 1 the Analysis Model 625
2 Concurrency and Subsystem Allocation 626 23.1 THE INTENT OF OBJECT-ORIENTED METRICS 664
2 1.3.3 T h e T a s k M a n a g e m e n t C o m p o n e n t . 626 23.2 THE 665
2 1.3.4 T h e D a t a M a n a g e m e n t C o m p o n e n t 627 23.2.1 Localization 665
2 1 3.5 The Resource 628 23 2.2 Encapsulation 666
2 1 The Interface 628 23.2 3 Information 666
2 1 7 Inter-Subsvstem 629 23.2 4 Inheritance 666
2 1 . 4 THE OBJECT DESIGN PROCESS 631 23.2.5 Abstraction 667
2 1.4.1 Descriptions 631 23.3 METRICS FOR THE 00 DESIGN MODEL 667
21 Desianina Alaorithms and Data Structures 632 2 3 . 4 CLASS-ORIENTED METRICS 667
21 3 and lnterfoces 634 23.4.1 The CK Metrics Suite 667
2 1 . 5 DESIGN PATTERNS 636 23 4.2 Metrics Proposed by and Kidd 670
21 1 a Pattern 637 23 5 OPERATION-ORIENTED METRICS 672
21 638 2 3 6 METRICS FOR OBJECTORIENTED TESTING 672
21.6 PROGRAMMING 638 2 3 7 METRICS FOR PROJECTS 673
2 1 . 7 SUMMARY 638 2 3 8 SUMMARY 674
REFERENCES 639 REFERENCES 675
AND POINTS TO AND POINTS TO PONDER 675
AND INFORMATION 64 AND INFORMATION SOURCES 676
xxii TABLE OF CONTENTS TABLE OF CONTENTS xxiii
PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING 679 26.2 THE REUSE PROCESS 732
26.2.1 Reusable Artifacts 732
26.2.2 A Process Model 734
CHAPTER 24 METHODS 681
26.3 DOMAIN ENGINEERING 735
24.1 BASIC CONCEPTS 681 26.3.1 The Domain Process 736
24.1 1 D e f i c i e n c i e s o f L e s s F o r m a l A p p r o a c h e s 682 26 3.2 737
24.1 Mathematics in Software Development 684 26.3.3 Structural Modeling and Structure 738
24.1.3 Formal Methods Concepts 685 26.4 REUSABLE COMPONENTS 740
24.2 M A T H E M A T I C A L PRELIMINARIES 690 26.4.1 Analysis and Design for Reuse 740
24.2.1 Sets and Constructive 690 26.4.2 Construction Methods 741
24.2.2 Set Operators 691 26.4.3 Component-Based Development 742
24.2.3 Logic 694 26.5 AND RETRIEVING COMPONENTS 743
24 3 APPLYING MATHEMATICAL NOTATION FOR FORMAL 26.5.1 Describing Reusable Components 744
SPECIFICATION 696 26.5.2 The Reuse Environment 746
24.4 FORMAL SPECIFICATION LANGUAGES 698 26.6 ECONOMICS OF SOFTWARE REUSE 747
24.5 USING Z TO REPRESENT AN EXAMPLE SOFTWARE 26.6.1 Impact on Quality, Productivity, and Cost 747
COMPONENT 699 26.6.2 Cost Analysis Using Structure Points 748
24.6 THE TEN COMMANDMENTS OF FORMAL METHODS 701 26.6.3 Reuse Metrics 749
24.7 FORMAL METHODS-THE ROAD AHEAD 702 26.7 SUMMARY 750
24.8 SUMMARY 703 REFERENCES 751
REFERENCES 703 PROBLEMS AND POINTS TO PONDER 752
PROBLEMS AND POINTS TO PONDER 704 FURTHER READINGS AND OTHER INFORMATION SOURCES 753
FURTHER READINGS AND OTHER INFORMATION SOURCES 705
CHAPTER 27 REENGINEERING 756
CHAPTER 2.5 CLEANROOM SOFTWARE ENGINEERING 707
27.1 BUSINESS PROCESS REENGINEERING 757
2.5 1 THE CLEANROOM APPROACH 708 Business Processes 757
2.5 1 1 The Cleanroom Strategy 708 27 1 Principles of Business Process Reengineering 759
25.1 What Makes Different? 711 27.1.3 A BPR Model
25.2 FUNCTIONAL SPECIFICATION 711 27.1.4 Words 761
25 2 1 Black-Box 712 27.2 SOFTWARE 762
25.2.2 State-Box 713 27.2.1 Software Maintenance 762
25.2.3 Clear-Box 714 27.2 2 A Software Reengineering Process Model 763
25.3 DESIGN REFINEMENT AND VERIFICATION 714 27.3 REVERSE ENGINEERING 767
25.3.1 Design Refinement and 715 27.3.1 Reverse Engineering to Understand Processing 768
25.3.2 Advantages of Design 719 27.3.2 Reverse Engineering to Understand Data 770
25.4 CLEANROOM TESTING 720 27.3.3 Reverse Engineering User Interfaces 771
25.4.1 Statistical Use Testing 721 27.4 RESTRUCTURING 773
25.4.2 Certification 722 27.4.1 Code Restructuring 773
25.5 SUMMARY 723 27.4.2 Data Restructuring’ 774
REFERENCES 724 27.5 FORWARD ENGINEERING 774
PROBLEMS AND POINTS TO PONDER 724 27.5.1 Forward Engineering for Client/Server
READINGS AND OTHER INFORMATION 725 Architectures 775
27.5.2 Forward Engineering for
728 Architectures 777
CHAPTER 26 SOFTWARE REUSE
27.5.3 Engineering User Interfaces 778
26.1 MANAGEMENT ISSUES 729 27.6 THE ECONOMICS OF REENGINEERING 778
Roadblocks to Reuse 729 27.7 S U M M A R Y 779
26.1.2 A Hardware 730 REFERENCES 780
26.1.3 Some Suggestions Establishing an Approach to PROBLEMS AND POINTS TO PONDER 781
Reuse 731 FURTHER READINGS AND OTHER INFORMATION SOURCES 782
TABLE OF CONTENTS
CHAPTER 28 SOFTWARE ENGINEERING 784
28. THE STRUCTURE 785
28 1 C/S 786
28.1 The of Software Components 787
28 1 Guidelines for Distributing
Components 788
licking C/S Software Components 789
28.1 Middleware and Broker
A r c h i t e c t u r e s 789
28.2 SOFTWARE ENGINEERING FOR C/S SYSTEMS 791
28 3 MODELING ISSUES 791
28.4 DESIGN FOR C/S SYSTEMS 792
28 4 1 793
28.4.2 Design 793
2 8 . 4 . 3 An of Design Approach 796
28.4 4 Process lterotion 797
28.5 TESTING ISSUES 798
28.51 Overall C/S Testing Strategy 798
28.5.2 C/S Testing 801
28.6 SUMMARY 801
REFERENCES 802
A
PROBLEMS AND POINTS TO PONDER 803
FURTHER READINGS AND OTHFR INFORMATION 803 engineering moves into its fourth decade of it
from many of the strengths and some of the frailties that are
CHAPTER 29 COMPUTER-AIDED SOFTWARE 805
by of the same innocence nnd enthusiasm of its
29.1 IS 806 have been replaced by more reasonable expectations (and even a healthy cyni-
29 2 BLOCKS FOR CASE 806 cism) fostered by years of experience. Software engineering approaches its mid-
29.3 A TAXONOMY OF CASE TOOLS 808 life with many accomplishments, but with significant work yet to do. Today, it is
29 4 INTEGRATED CASE ENVIRONMENTS 813
814 recognized as a legitimate discipline, one worthy of serious research, conscien-
29.5 THE INTEGRATION ARCHITECTURE
816 tious study, and tumultuous debate. Throughout the industry, “software engi-
29.6 THE CASE REPOSITORY
29.6.1 The Role of the Repository I-CASE 816 neer” has replaced “programmer” as the job title of preference. Software process
29.6.2 Features and Content 817 models, software engineering methods, and software tools have adopted suc-
29.7 SUMMARY 821 cessfully across a broad spectrum of industry applications. Managers and prac-
REFERENCES 822 titioners alike recognize the need for a more disciplined approach software.
PROBLEMS AND POINTS TO PONDER 822 But many of the problems discussed in earlier editions of this hook remain
FURTHER READINGS AND OTHER INFORMATION SOURCES 823 us. Many individuals and companies still develop software haphazardly.
826 Many professionals and students are unaware of modern methods. And as a re-
CHAPTER 30 THE ROAD AHEAD
sult, the quality of the software that we produce suffers. In addition, debate
30.1 THE IMPORTANCE OF SOFTWARE-REVISITED 827 and controversy about the true nature of the software engineering approach
30 2 THE SCOPE OF CHANGE 827
829 continue. The status of software engineering is a study in contrasts. Attitudes
30.3 PEOPLE AND THE WAY THEY SYSTEMS
30.4 THE “NEW” SOFTWARE PROCESS 832 have changed, progress has been made, but much remains to be done before the
30.5 FOR REPRESENTING INFORMATION 833 discipline reaches full maturity.
30.6 TECHNOLOGY AS A DRIVER 83.5 The fourth edition of Software A Practitioner’s Approach is in-
7A COMMENT 837 tended to serve as a guide to maturing diaciplinc. The fourth edi-
837 tion, like the three editions that have it, is intonded for both
PROBLEMS AND TO PONDER 838 and practitioners, and maintains the format and style of its predecessors.
FURTHER READINGS AND OTHER INFORMATION SOURCES 838 The book retains its appeal as a guide to the industry professional and a
INDEX 840
xx”
xxvi PREFACE PREFACE xxvii
prehensive introduction to the student at the upper level undergraduate or Like the first three editions, an Instructor’s Guide for Software
first year graduate level. A Practitioner’s Approach is available from McGraw-Hill. The Instructor’s
The fourth edition is considerably more than a simple update. The book has presents suggestions for conducting various types of software engineering
been completely restructured to accommodate the dramatic growth in the field courses, recommendations for a variety of software projects to be conducted in
and to emphasize new and important software engineering methods. Chapters conjunction with a course, solutions to selected problems, and transparency
that have been retained from earlier editions have been revised and updated. masters to aid in teaching selected topics. In addition, a comprehensive video
Twelve new chapters have been added to provide more complete treatment of curriculum, Essential Software Engineering, is available to complement this
contemporary trends and techniques. Many new examples, problems and points book. The video curriculum has been designed for industry training and has
to ponder have been included. The Further Readings and Other Information been modularized to enable individual software engineering topics to be pre-
Sources sections (one of the more popular tidbits in earlier editions) have been sented on an as-needed, when-needed basis. Further information on the video
expanded for every chapter. Hundreds of new published sources and over 160 can be obtained by mailing the request card at the back of this
sources from the World Wide have been included. My work on the four editions of Software Engineering: A Practitioner’s
The 30 chapters of the fourth edition have been organized into live parts. Approach has been the longest continuing technical project of my life. Even
This has been done to compartmentalize topics and assist instructors who may when the writing stops, information extracted from the technical literature con-
not have the time to complete the entire book in one term. Part One, The tinues to be assimilated and organized. For this reason, my thanks to the many
Product and presents an introduction to the software engineering authors of books, papers, and articles as well as a new generation of contribu-
milieu. It is intended to introduce the subject matter and, more importantly, to tors to electronic media (newsgroups and the World Wide who have pro-
present concepts that will be necessary for later chapters. Part Two, Managing vided me with additional insight, ideas, and commentary over the past 15
Software Projects, presents topics that are relevant to those who plan, manage, years. Many have been referenced within the pages of each chapter. All deserve
and control a software development project. Part Three, Conventional Methods credit for their contribution to this rapidly evolving field. I also wish to thank
for Software Engineering, presents the analysis, design, and testing methods the reviewers of the fourth edition: Frank H. Westervelt, Wayne State
that some view as the “conventional” school of software engineering. Part Four, University; Steven A. Demurjian, The University of Connecticut; Chung Lee,
Object-Oriented Software Engineering, presents object-oriented methods across California State Polytechnic University; Alan Davis, University of Colorado;
the entire software engineering process, including analysis, design, and testing. Michael C. Mah, QSM Associates; Richard N. Taylor, University of
Part Five, dedicated Auburn
that address formal methods, cleanroom engineering, reuse, Warren Harrison, Portland University; M. Kokar,
neering, client/server software engineering, and CASE. Northeastern University. Their comments and criticism have been invaluable.
It is important to note that the fourth edition has a much greater empha- The content of the fourth edition of Software Engineering: A Practitioner’s
sis on metrics and measurement than earlier editions. Three separate chapters Approach has been shaped by industry professionals, university professors, and
on software metrics address measurement of the software process, technical students who have used earlier editions of the book and have taken the time
metrics for analysis, design, and testing using conventional methods, and tech- to communicate their suggestions, criticisms, and ideas. My thanks to each of
nical metrics for object-oriented software engineering. you. In addition, my personal thanks go to our many industry clients through-
The five-part organization of the fourth edition enables an instructor to out North America and Europe, who certainly teach me as much as or more
cluster topics based on available time and student need. An entire one-term than I can teach them.
course can be built around one or more of the five parts. For example, a “design As the editions of this book have evolved, my sons, and Michael,
course” might emphasize only Part III or Part IV, a “methods course” might pre- have grown from boys to men. Their maturity and character have been an in-
sent selected chapters in Parts III, IV, and A “management course” would spiration to me. Nothing has filled me with more pride. And finally, to Barbara,
stress Parts I and II. By organizing the fourth edition in this way, I have at- my love and thanks for tolerating my travel schedule, understanding the
tempted to provide an instructor with a number of teaching options. evenings at the office, and encouraging still another edition of “the book.”
Roger S. Pressman
‘Because World Wide Web addresses change frequently, only those that likely to persist ,
have been noted in Further Readings and Other Sources. However, even these at accredited universities should see their Instructor’s Guide for special options
may become invalid as time passes. An up-to-date ‘hot list” the presented in this book associated with the video curriculum. If the reply card is missing, please e-mail request for
can found at information to or fax request to Pressman Associates, Inc. at
THE PRODUCT AND
THE PROCESS
In this part of Software Engineering; A Practitioner’s Approach we consider the product that is to be
engineered and the process that provides a framework for the engineering technology. In the chap-
ters that follow, we address the following questions:
!" 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 development?
!"How do linear and iterative process models differ?
!" What are their strengths and weaknesses?
!" bren work?
Once these questions are answered, you’ll be prepared to understand the management and
technical aspects of the engineering discipline to which the remainder of this book is dedicated.
THE
J ust after the first edition of this book was published in the early
front page story in Business Week magazine trumpeted the following head-
line: “Software: The New Driving
a
editors had absolutely no idea how
right they would be. At that time, software was still an unknown to most of the
general companies like Microsoft didn’t exist; computer
superstores with 15,000 square feet dedicated to shrink-wrapped software
products were unknown; the idea of TV commercials advertising
computer operating systems would have been laughable; and the Internet was
known to only a few researchers and academics. But in less than two decades,
changes that have led to all of this (and much more) have come to pass.
Computer software has become a driving force. It is the engine that drives
business decision making. It serves as the basis for modem scientific investi-
gation and engineering problem solving. It is a key factor that differentiates
modem products and services. It is embedded in systems of all kinds: trans-
portation, medical, telecommunications, military, industrial processes, enter-
tainment, products,. the list is almost endless. Software is virtually in-
escapable 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 edu-
cation to genetic engineering.
All of this has changed the public perception of software. Computer pro-
grams are ubiquitous, and the public views them as a technological fact of life.
In many instances, people bet their jobs, their comforts, their safety, their en-
tertainment, their decisions, and their very lives on computer software. It bet-
ter be right.
This book presents the technology that should 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.
3
PART THE AND T PROCESS
HE CHAPTER 1: THE PRODUCT
1.1 THE EVOLVING ROLE OF SOFTWARE During the early years of the computer era, software was viewed by many
an afterthought. Computer programming was a “seat-of-the-pants” art for which
Today, software takes on a dual role. It is a product, and at the same time, the few systematic methods existed. Software development was virtually unman-
vehicle for delivering a product. As a product, it delivers the computing poten- aged-until schedules slipped or costs began to escalate. Then programmers
tial embodied by computer hardware. Whether it resides within a cellular scrambled to make things right, and with heroic effort, they often succeeded.
phone or operates inside a mainframe computer, software is an information During the early years general-purpose hardware became commonplace.
transformer-producing, managing, acquiring, modifying, displaying, or trans- on the other hand, was custom-designed for application and had
mitting information that can be as simple as a single bit or as complex as a a relatively limited distribution. Product software (i.e., programs developed to
multimedia simulation. As the vehicle used to deliver the product, software acts be sold to one or more customers) was in its infancy. Most software was devel-
as the basis for the control of the computer (operating systems), the communi- oped and ultimately used by the same person or organization. You wrote it, you
cation of information (networks), and the creation and control of other pro- got it running, and if it failed, you fixed it. Because job mobility was low, man-
grams (software tools and environments). agers could rest assured that you’d be there when bugs were encountered.
Software delivers what many believe will be the most important product of Because of this personalized software environment, design was an implicit
the twenty-first century-information. Software transforms personal data (e.g., process performed in one’s head, and documentation was often nonexistent.
an individual’s financial transactions) so that the data can be more useful in a During the early years we learned much about the implementation of
local context; it manages business information to enhance competitiveness; it systems, but relatively little about computer system engineering.
provides a gateway to worldwide information networks (e.g., the Internet); and In fairness, however, we must acknowledge the many outstanding
it provides the means for acquiring information in all of its forms. based systems that were developed during this era. Some of these remain in
The role of computer software has undergone significant change through use today and provide landmark achievements that continue to justify admi-
the second half of the twentieth century. Dramatic improvements in hardware ration.
performance, profound changes in computing architectures, vast increases in The second era of computer system evolution spanned the decade the
memory and storage capacity, and a wide variety of exotic input and output op- mid-1960s to the late 1970s (Figure 1.1). Multiprogramming, multiuser sys-
tions have all precipitated more sophisticated and complex computer-based sys- tems introduced new concepts of human-machine interaction. Interactive tech-
tems. Sophistication and complexity can produce dazzling results when a sys- niques opened a new world of applications and new levels of hardware and
tem succeeds, but they can also pose huge for those who must build ware sophistication. Real-time systems could collect, analyze, and transform
complex data from multiple thereby controlling and producing output
books published during provide useful in milliseconds than in to the
insight into the changing perception of computers and software and generation of database management
their impact on our culture. Osborne characterized a “new industrial The second era was also characterized by the use of product software and
revolution.” the advent of microelectronics part of “the the advent of “software houses.” Software was developed for widespread
third wave of change” in human history, and Naisbitt predicted
the transformation from an industrial society to an “information society.”
Feigenbaum and suggested that information and knowl- The third era The fourth era
The early years The second era
edge (controlled by computers) would be the focal point for power in the
!" Batch orientation !" Multiuser . Distributed systems . Powerful desk-top
century, and Stoll argued that the “electronic community” created
by networks and software was the key to knowledge interchange throughout !" Limited distribution !" Real-time . Embedded “intelligence” systems
!"Custom software Database . Low cost hardware !" Object-oriented
the world. !"
As the 1990s began, described a “power shift” in which old !"Product software !" Consumer impact technologies
power structures (governmental, educational, industrial, economic, and mili- !"Expert systems
tary) disintegrate as computers and software lead to a “democratization of !" Artificial neural
knowledge.” worried that U.S. companies might lose their networks
competitive edge in businesses and predicted “the decline and !" Parallel computing
fall of the American programmer.” Hammer and Champy [HAM931 argued that !" Network computers
information technologies were to play a pivotal role in the “reengineering of the
corporation.” During the the pervasiveness of computers and soft-
ware 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 These authors demonize the computer, emphasizing legitimate
1950 1960 1970 1980 1990 2000
concerns but ignoring profound that have already been realized
FIGURE 1 Evolution of software.
AND I 7
in a multidisciplinary market. Programs for mainframes and minicom- are changing the manner in which the software community builds computer
puters were distributed to hundreds and sometimes thousands of users. programs. Expert systems and artificial intelligence software have
Entrepreneurs from industry, government, and academia broke away to de- moved from the laboratory into practical application for wide-ranging problems
velop the ultimate software package and earn a bundle of money. in the real world. Artificial neural network software coupled with the applica-
As the number of computer-based systems grew, libraries of soft- tion of fuzzy logic has opened exciting possibilities for pattern recognition and
ware began to expand. In-house developed projects produced tens of thousands human-like information processing abilities. Virtual reality programming and
of program source statements. Software products purchased from the outside multimedia systems offer radically different ways of communicating informa-
added hundreds of thousands of new statements. A dark cloud appeared on the tion to end-users. “Genetic algorithms” offer the potential for software
horizon. All of these programs-all of these source statements-had to be cor- that resides within massively parallel biological computers.
rected when faults were detected, modified as user requirements changed, or Yet, a set of software-related problems has persisted throughout the evo-
adapted to new hardware that was purchased. These activities were collectively lution of computer-based systems, and these problems continue to intensify.
called software maintenance. Effort spent on software maintenance began to
absorb resources at an alarming rate. 1. Hardware advances continue to our ability to build to tap
Worse yet, the personalized nature of many programs made them virtually hardware’s potential.
unmaintainuble. A “software crisis” loomed on the horizon. 2. Our ability to build new programs cannot keep pace with the demand for
The third era of computer system evolution began in the mid-1970s and new programs, nor can we build programs rapidly enough to meet business
spanned more than a full decade. The distributed system-multiple computers, and market needs.
each performing functions concurrently and communicating with one
greatly increased the complexity of computer-based systems. Global and local 3. The widespread use of computers has made society increasingly dependent
area networks, high-bandwidth digital communications and increasing de- on reliable operation of software. Enormous economic damage and poten-
mands for “instantaneous” data access put heavy demands on software devel- tial human suffering can occur when software fails.
opers. Yet, software and the systems that it enabled continued to reside within 4. We struggle to build computer software that has high reliability and quality.
industry and academia. Personal use was rare. 5. Our ability to support and enhance existing programs is threatened by poor
The conclusion of the third era was characterized by the advent and wide- design and inadequate resources.
spread use of microprocessors. The microprocessor has spawned a wide array
of intelligent products-from automobiles to microwave ovens, from industrial In response to these problems, software engineering practices are being adopted
robots to blood serum diagnostic equipment-but none has been more impor- throughout the industry.
tant than the persona1 computer. In less than a decade, computers became
readily accessible to the public at large.’
The fourth era of computer system evolution moves us away from individ-
ual computers and computer programs and toward the collective impact of com- 1.1.1 An Industry Perspective
puters and software. Powerful desk-top machines controlled by sophisticated
operating systems, networked locally and globally, and coupled with advanced In the early days of computing, computer-based systems were developed using
software applications have become the norm. Computing architectures are hardware-oriented management. Project managers focused on hardware be-
rapidly changing from centralized mainframe environments to decentralized cause it was the single largest budget item for system development. To control
client/server environments. Worldwide information networks provide an infra- hardware costs, managers instituted formal controls and technical standards.
structure that causes pundits and politicians alike to muse about an “informa- They demanded thorough analysis and design before something was built. They
tion superhighway” and “cyberspace connectivity.” In fact, the Internet can be measured the process to determine where improvement could be made. They
on “software” that can ho accessed by individual users. insisted on quality control and quality They instituted
The software industry is no longer a niche in the world economy. The deci- to manage Stated simply, they applied the controls, methods, and toole
sions made by industry giants such as Microsoft put billions of dollars at risk. that we recognize as hardware engineering. Sadly, software was often little
As the fourth era progresses, new technologies have begun to emerge. more than an afterthought.
oriented technologies (Part Four of this book) are rapidly displacing more con- In the early days, programming was viewed as an “art form.” Few formal
ventional software development approaches in many application areas. methods existed and fewer people used them. The programmer learned
Although predictions of “fifth generation” computers and his or her craft by trial and error. The jargon and challenges of building com-
continue to elude us, “fourth generation techniques” for software development puter software created a mystique that few cared to penetrate. The
software world was virtually undisciplined-and many practitioners of the day
loved it!
is currently es mated that 40 percent of all households in the United States have personal Today, the distribution of costs for the development of computer-based sys-
computers. tems has changed dramatically. Software, rather than hardware, is the largest
8 PART ONE: THE PRODUCT AND THE PROCESS CHAPTER : THE PRODUCT 9
single cost item. For almost two decades managers and many technical practi- It will not be enough to “patch” what is broken and give these applications
tioners have asked the following questions: \ a modern look. Many components of the software plant require significant
reengineering, or they will no longer be competitive. Unfortunately, many busi-
!" Why does it take so long to get programs finished? ness managers are unwilling to commit the resources to undertake this
neering effort. “The applications still work,” they say, “and it is ‘uneconomic’ to
!" Why are costs so high?
commit the resources to make them better.”
!" Why can’t we all errors before we give the software to our customers?
!" Why do we have difficulty in measuring progress as software is being developed.
Competitiveness
These, and many other questions, are a manifestation of the concern about soft-
ware and the manner in which it is developed-a concern that has lead to the For many years, software developers employed by large and small companies
adoption of software engineering practice. were the only show in town. And they often acted like it. Because every com-
puter program was custom-built, these in-house software people dictated costs,
schedule, and quality Today, all of this has changed.
1 An Aging Sofhvore Software is now an extremely competitive business. Software that was once
built internally can now be purchased off-the-shelf. Many companies that once
In the 1950s and 1960s many commentators criticized the steel industry in the paid legions of programmers to create specialized applications have now
United States for lack of investment in its physical plant. Factories had begun much of their software work to a third party
to deteriorate, modern methods were rarely applied, the quality and cost of the Cost, timeliness, and quality are primary drivers that will lead to intense
end product suffered, and competition began to win substantial market share. competition for software work over the next few decades. The United States
Management in these industries decided against making the capital investment and Western Europe have well-established software industries. But countries
to in their time, the in the Far East (e.g., Korea, Singapore), in Asia India, China), and in
steel industry losing significant market share to Europe all large pool highly motivated, competently educated
that had newer plants, more modern technology, and was pro- and relatively low-coat professionals This work force is moving rapidly
vided with government subsidies to make them extremely cost competitive. to adopt modem software engineering practices and has become a force to be
During that period, many of us in the fledgling computer industry looked reckoned with as a worldwide pool of software professionals chase a finite num-
at the steel industry with contempt. “If they’re unwilling to invest in their own ber of development dollars.
business,” we said, “they deserve to lose market share.” Those words may come In their book on the impact of information services on the United States
back to haunt us. and the world, Feigenbaum and state the following:
At the risk of sounding melodramatic, the software industry today is in a
position that is quite similar to that of the steel industry of the 1950s and Knowledge is power, and the is an amplifier of that power.
1960s. Across companies large and small, we an aging “software plant”- American computer industry has been innovative, vital. successful. It is, in
there are thousands of critical software-based applications that are in dramatic way, the ideal industry. It creates value by transforming the brainpower of
need of refurbishing: knowledge workers, with little consumption of energy and raw materials. Today,
we dominate the world’s ideas and markets in this most important of all mod-
!"Information system applications written twenty years ago that have under- ern technologies. But what about tomorrow?
gone 40 generations of changes and are now virtually unmaintainable. Even
the smallest modification can cause the entire system to fail. Indeed, what about tomorrow? Computer hardware has become a commodity,
!" Engineering applications that are used to produce critical design data, and available from many sources. But software remains an industry where the United
yet, because of their age and state of repair, no one really understands their States has been “innovative, vital, land1 successful.” But will we maintain our
internal structure. place at the top? At least part of the answer lies in the approach we take to the
construction of software for the next generation of computer-based systems.
!" Embedded systems (used to control power plants, air traffic, and factories,
among thousand of applications) that exhibit strange and sometimes unex-
plained behavior, but that cannot be taken out of service because there’s
1.2 SOFTWARE
nothing available to replace them.
1970, less than 1 percent of the public could have intelligently described
“This section been adapted from the introductory chapter of the book by what “computer software” meant. Today, most professionals and many members
Pressman and I. of the public at large feel that they understand software. But do they?
10 PART ONE: THE PRODUCT AND THE PROCESS CHAPTER : 11
A textbook description of software might take the following form: Software
is instructions (computer programs) that when executed provide desired
function and performance, data structures that enable the programs to ade-
quately manipulate information, and documents that describe the operation
and use of the programs. There is no question that other, more complete def-
initions 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 soft-
ware engineering), it is important to examine the characteristics of software
that make it different from other things that human beings build. When hard-
ware is built, the human creative process (analysis, design, construction, test- FIGURE 1.2.
ing) is ultimately translated into a physical form. If we build a new computer, Failure curve for
our initial sketches, formal design drawings, and breadboarded prototypes hardware. Time
evolve into a physical product (VLSI chips, circuit boards, power supplies, etc.).
Software is a logical rather than a physical system element. Therefore, soft-
ware has characteristics that differ considerably from those of
Software is not susceptible the environmental maladies that cause hard-
1. Software is developed or engineered, it is not manufactured in the classical ware wear out. In theory, therefore, the failure rate curve for software should
sense. take the form shown in Figure 1.3. Undiscovered defects will cause high fail-
ure rates early in the life of a program. However, these are corrected (hopefully
Although some similarities exist software development and hardware without introducing other errors) and the curve flattens as shown. Figure 1.3
manufacture, the two activities are fundamentally different. In both activities, is a gross oversimplification of actual failure models (see Chapter for more
high quality is achieved through good design, but the manufacturing phase for information) for software. However, the implication is clear-software doesn’t
hardware can introduce quality problems that are nonexistent (or easily cor- wear out. But it does deteriorate!
rected) for software. Both activities depend on people, but the relationship be- This seeming contradiction can best be explained by considering Figure
tween people applied and work accomplished is entirely different (see Chapter 1.4. During its life, software will undergo change (maintenance). As changes are
3). Both activities require the construction of a “product,” but the approaches made, it is likely that some new defects will be introduced, causing the failure
are different.
Software costs are concentrated in engineering. This means that software
projects cannot be managed as if they were manufacturing projects.
In the the concept of the “software factory” was introduced in
the literature (e.g., It is important to note that this term
does not imply that hardware manufacturing and software development are
equivalent. Rather, the software factory concept recommends the use of auto-
mated tools Part Five) for software development.
2. Software doesn’t “wear out.”
Figure 1.2 depicts failure rate as a function of time for hardware. The relation- continues at same
ship, often called the “bathtub curve,” indicates that hardware exhibits relatively rate until obsolescence
high failure rates early in its life (these failures are often attributable to design
or manufacturing defects); defects are corrected, and the failure rate drops a
steady-state level (hopefully, quite low) for some period of time. As time passes,
however, the failure rate rises again as hardware components suffer from the cu-, FIGURE 1.3.
mulative affects of dust, vibration, abuse, temperature extremes, and many other Failure for
environmental maladies. Stated simply, the hardware begins to wear out. (idealized) Time
PART ONF THE PRODUCT AND PROCESS CHAPTER : PRODUCT 13
increased failure about “software reusability” (e.g., we are only beginning to
see successful implementations of the concept.
rate due to side
effects
l-A.2 Software Components
As an engineering discipline evolves, a collection of standard design compo-
nents is created. Standard screws and off-the-shelf integrated circuits are only
two of thousands 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 ele-
ments of a design (i.e., the 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 something that has yet to be achieved on a
FIGURE 1.4. idealized curve broad scale.
Actual failure curve Reusability is an important of a high-quality software com-
for software. Time ponent (see Chapter 26 for additional information). A software component
should be designed and implemented so that it can be reused in many differ-
ent programs. In the we built scientific subroutine libraries that were
rate curve to spike as shown in Figure 1.4. Before the curve can return to the reusable in a broad array of engineering and scientific applications. These sub-
original steady-state failure rate, another change is requested, causing the routine libraries reused well-defined algorithms in an effective manner, but
curve to spike again. Slowly, the minimum failure rate level begins to had a limited domain of application. Today, we have extended our view of reuse
the software is deteriorating due to change. to encompass not only algorithms, but also data structures. Modem reusable
Another aspect of wear illustrates the difference between hardware and components encapsulate both data and the processing that is applied to the
software. When a hardware component wears out, it is replaced by a spare part. data, enabling the software engineer to create new applications from reusable
There are no software spare parts. Every software failure indicates an error in For example, today’s interactive interfaces are built using reusable com-
design or in the process through which design was translated into machine ex- ponents that enable the creation of graphics windows, pull-down menus and a
ecutable code. Therefore, software maintenance involves considerably more wide variety of interaction mechanisms. The data structures and processing de-
complexity than hardware maintenance. tail required to build the interface are contained within a library of reusable
components for interface construction.
3. Most software is custom-built, rather than being assembled from existing Software components are built using a programming language that has a
components. limited vocabulary, an explicitly defined grammar, and well formed rules of syn-
tax and semantics. At the lowest level, the language mirrors the instruction set
Consider the manner in which the control hardware for a microprocessor-based of the hardware. At mid-level, programming languages such as Ada 95, C, or
product is designed and built. The design engineer draws a simple schematic Smalltalk are used to create a procedural description of the program. At the
of the digital circuitry, does some fundamental analysis to ensure that proper highest level, the language uses graphical icons or other symbology to repre-
function will be achieved, and then refers to a catalog of digital components. sent the requirements for a solution. Executable instructions are automatically
Each integrated circuit (often called an “IC” or a “chip”) has a part number, a generated.
defined and validated function, a well-defined interface, and a standard set of Machine-level language is a symbolic representation of the CPU
il. produces a
the-shelf. program, machine-level language can make extremely efficient use of
Sadly, software designers are not afforded the luxury described above. With memory and “optimize” program execution speed. When a program is poorly de-
few exceptions, there are no catalogs of software components. It is possible to signed and has little documentation, machine language is a nightmare.
order off-the-shelf software, but only as a complete unit, not as components that Mid-level languages allow the software developer and the program to be
can be reassembled into new programs.” Although much has been written machine-independent. When a more sophisticated translator is used, the
situation is changing rapidly The widespread use of object-oriented technology has Part Four of this book we examine the use of object-orientedtechnologies and their im-
in the creation of software components. discussed in Chapters 19 and 26. pact component reuse.
14 PART ONE. THE PRODUCT AND THE PROCESS CHAPTER I. THE PRODUCT 15
cabulary, grammar, syntax, and semantics of a mid-level language can be much System System software is a collection of programs written to ser-
more sophisticated than machine-level languages. In fact, mid-level language vice other programs. Some system software (e.g., compilers, editors, and file
compilers and interpreters produce machine-level language as output. management utilities) processes complex, but determinate, information struc-
Although hundreds of programming languages are in use today, fewer than tures. Other systems applications (e.g., operating system components, drivers,
ten mid-level programming languages are widely used in the industry. telecommunications processors1 process largely indeterminate data. In either
Languages such as COBOL and FORTRAN remain in widespread use more case, the systems software area is characterized by heavy interaction with com-
than 30 years after their introduction. More modem programming languages puter hardware; heavy usage by multiple users; concurrent operation that re-
such as Ada95, C, C++ Eiffel, Java, and Smalltalk have each gained an en- quires scheduling, resource sharing, and sophisticated process management;
thusiastic following. complex data structures; and multiple external interfaces.
Machine code, assembly (machine-level) languages, and mid-level pro-
gramming languages are often referred to as the first three generations of com- Real-Time Software Programs that monitor/analyze/control real world events
puter languages. With any of these languages, the programmer must be con- as they occur are called real-time software. Elements of real-time software in-
cerned both with the specification of the information structure and the control clude a data gathering component that collects and formats information from
of the program itself. Hence, languages in the first three generations are termed an external environment, an analysis component that transforms information
procedural languages. as required by the application, a control/output component that responds to the
Fourth generation languages, also called nonprocedural languages, move external environment, and a monitoring component that coordinates all other
the software developer even further from the computer hardware. Rather than components so that real-time response (typically ranging from 1 millisecond to
requiring the developer to specify procedural detail, the nonprocedural lan- 1 minute) can be maintained. It should be noted that the term “real-time” dif-
guage implies a program by “specifying the desired result, rather than specify- fers from “interactive” or “timesharing.” A real-time system must respond
ing action required to achieve that result” Support software trans- within strict time constraints. The response time of an interactive (or time-
lates the specification of result into a machine executable program. sharing) system can normally be exceeded without disastrous results.
Business Business information processing is the largest single soft-
1.2.3 Applications ware application area. Discrete “systems” (e.g., payroll, accounts receivable/
payable, inventory, etc.) have evolved into management information system
software that accesses one or more large databases containing business
Software may be applied in any situation for which a prespecitied set of proce-
dural steps an algorithm) has been defined (notable exceptions to this rule information. Applications in this area restructure existing data in a way that
facilitates business operations or management decision making. In addition to
are expert systems and artificial neural network software). Information content
conventional data processing applications, business software applications also
and determinacy are important factors in determining the nature of a software
encompass interactive and client/server computing (e.g., point-of-sale transac-
application. Content refers to the meaning and form of incoming and outgoing
tion processing).
information. For example, many business applications make use of highly struc-
tured input data database) and produce formatted “reports.” Software that
controls an automated machine (e.g., a numerical control) accepts discrete data Engineering and Scientific Software Engineering and scientific software has
items with limited structure and produces individual machine commands in been characterized by “number crunching” algorithms. Applications range from
rapid succession. astronomy to volcanology, from automotive stress analysis to space shuttle or-
Information refers to the predictability of the order and tim- bital dynamics, and from molecular biology to automated manufacturing.
ing of information, An engineering analysis program accepts data that have a However, new applications within the engineering/scientific area are moving
order, executes the analysis algorithm(s) without interruption, and away from conventional numerical algorithms. Computer-aided design, system
produces resultant data in report or graphical format. Such applications are de- simulation, and other interactive applications have begun to take on real-time
terminate. A multiuser operating system, on the other hand, accepts inputs and even system software characteristics.
that have varied content and arbitrary timing, executes algorithms that can be
interrupted by external conditions, and produces output that varies as a func- Embedded Sofhvare Intelligent products have become commonplace in nearly
tion of environment and time. Applications with these characteristics are in- every consumer and industrial market. Embedded software resides in
determinate. only memory and is used to control products and systems for the consumer and
It is somewhat difficult to develop meaningful generic categories for soft- industrial markets. software can perform very limited and esoteric
ware applications. As software complexity grows, neat compartmentalization , functions (e.g., key pad control for a microwave oven) or provide significant
disappears. The following software areas indicate the breadth of potential ap- function and control capability (e.g., digital functions in an automobile such as
plications: fuel control, dashboard displays, braking systems, etc.).
16 PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 1: THE PRODUCT 17
Personal The personal computer software market has Although reference to a crisis or even an affliction can be criticized for being
geoned over the past decade. Word processing, spreadsheets, computer graph- melodramatic, the phrases do serve purpose by denoting real problems
ics, multimedia, entertainment, database management, personal and business that are encountered in all areas of software development.
financial applications, and external network or database access are only a few
of hundreds of applications.
1.4 SOFTWARE MYTHS
Artificial Artificial intelligence software makes use of
nonnumerical algorithms to solve complex problems that are not amenable to Many causes of a software can be traced to a mythology that arose dur-
computation or straightforward analysis. An active AI area is expert systems, ing the early history of software development. Unlike ancient myths, which
also called knowledge-based systems. However, other application areas for AI provided human lessons that are well worth heeding, software myths propagated
software are pattern recognition (image and voice), theorem proving, and game misinformation and confusion. Software myths had a number of attributes that
playing. In recent years, a new branch of AI software, called artificial neural net- made them insidious: For instance, they appeared to be reasonable statements of
works, has evolved. A neural network simulates the structure of brain processes fact (sometimes containing elements of truth), they had an intuitive feel, and they
(the functions of the biological neuron) and may ultimately lead to a new class were often promulgated by experienced practitioners who “knew the score.”
of software that can recognize complex patterns and learn from past experience. Today, most knowledgeable professionals recognize myths for what they
are-misleading attitudes that have caused serious problems for managers and
technical people alike. However, old attitudes and habits are difficult to mod-
SOFTWARE: A CRISIS ON THE HORIZON ify, and remnants of software myths are still believed.
Many industry observers (including this author in earlier editions of this book) Management Myths Managers with software responsibility, like managers in
have characterized the problems associated with software development as a most disciplines, are often under pressure to maintain budgets, keep schedules
“crisis.” Yet, what we really have may be something rather different. from slipping, and improve quality. Like a drowning person who grasps at a
The word “crisis” is defined in Webster’s Dictionary as “a turning point in straw, a software manager often grasps at belief in a software myth, if that be-
the course of anything; decisive or crucial time, stage or event.” Yet, for soft- lief will lessen the pressure (even temporarily).
ware there has been no “turning point,” no “decisive time,” only slow, evolu-
tionary change. In the software industry, we have had a “crisis” that has been We already have a book that’s full of standards and procedures for
with us for close to 30 years, and that is a contradiction in terms. building software. Won’t that provide my people with everything they need
Anyone who looks up the word “crisis” in the dictionary will another to know?
definition: “the turning point in course of a disease, whon it becomes clear Reality: The book of standards may very well exist, but is it used? Are
whether the patient will live or This definition may give a clue about software practitioners aware of its existence? Does it reflect modem soft-
the real nature of the problems that have plagued software development. ware development practice? Is it complete? In many cases, the answer to
We have yet to reach the stage of crisis in computer software. What we re- all of these questions is “no.”
ally have is a chronic The word is defined as “anything
Myth: My people do have state-of-the-art software development tools.
causing pain or distress.” But it is the definition of the adjective “chronic” that After all, we buy them the newest computers.
is the key to our argument: “lasting a long or recurring often; continuing
indefinitely.” It is far more accurate to describe what. endured for the Reality: It much moro that the model mainframe, worksta-
past three decades as a chronic rather than a crisis. There are no mir- tion or PC to do high-quality software development. Computer-aided soft-
acle cures, but there are many ways that we can reduce the pain as we strive ware ongincering (CASE) more important than hardware for
to discover a cure. achieving good quality and productivity, yet the majority of devel-
Whether we call it a software crisis or a software the term al- opers still do not use them.
ludes to a set of problems that are encountered in the development of computer Myth: If we get behind schedule, we can add more programmers and
software. The problems are not limited to software that “doesn’t function prop- catch up (sometimes called the “Mongolian horde concept”).
erly.” Rather, the encompasses problems associated with how we de- Reality: Software development is not a mechanistic process like manu-
velop software, how we maintain a growing volume of existing software, and facturing. In the words of Brooks “adding people to a late
how we can expect to keep pace with a growing demand for more software. project makes it later.” At first, this statement may seem counterintuitive.
However, as new people are added, people who were working must spend
time educating the newcomers, thereby reducing the amount of time spent
terminology suggested by Professor Daniel Tiechrow of the of Michigan on productive development effort. People can be added, but only in a planned
in talk presented in Geneva, Switzerland. April, and well-coordinated manner.
18 PART ONE THE PRODUCT AND PROCESS CHAPTER THE 19
Customer A customer who requests computer software may be a person
at the next desk, a technical group down the hall, the marketing/sales depart-
ment, or an outside company that has requested software under contract. In many
cases, the customer believes myths about software because software responsible
managers and practitioners do little to correct misinformation Myths lead to false
expectations (by the customer) and ultimately, dissatisfaction with developer.
A general statement of objectives is sufficient to begin writing pro-
- grams-we can fill in the details later.
R e a l i t y : Poor up-front definition is the major cause of failed software ef-
forts. A formal and detailed description of information domain, function,
performance, interfaces, design constraints, and validation criteria is es-
sential. These characteristics can be determined only after thorough com-
F I G U R E 1.
munication between customer and developer.
impact of Definition Development After release
M y t h : Project but cun be
accommodated because software is flexible.
R e a l i t y : It is true that software requirements do change, but the impact R e u l i t y : A working program is only one part of a configuration
of change varies with the time at which it is introduced. Figure 1.5 illus- that includes programs, documents, and data. Documentation forms the
trates the impact of change. If serious attention is given to up-front defin- foundation for successful development and, more important, provides guid-
ition, early requests for change can be accommodated easily. The customer ance for the software maintenance task.
can review requirements and recommend modifications with relatively lit- Many software professionals recognize the fallacy of the myths described
tle impact on cost. When changes are requested during software design,
above. Regrettably, habitual attitudes and methods foster poor management
cost impact grows rapidly. Resources have been committed and a design
and technical practices even when reality dictates a better approach.
framework has been established. Change can cause upheaval that requires
Recognition of software realities is the first step toward formulation of practi-
additional resources and major design modification, i.e., additional cost.
cal solutions for software development.
Changes in function, performance, interfaces or other characteristics dur-
ing implementation (code and test) have a severe impact on cost. Change,
when requested after software is in production use, can be more than an 1.5 SUMMARY
order of magnitude more expensive than the same change requested
earlier.
Software has become the key element in the evolution of computer-based sys-
Practitioner’s Myths Myths that are still believed by software practitioners tems and products. Over the past four decades, software has evolved from a
have been fostered by decades of programming culture. As we noted earlier in specialized problem-solving and information analysis tool to an industry in it-
this chapter, during the early days of software, programming was viewed as an self. But early “programming” culture and history have created a set of prob-
art form. Old ways and attitudes die hard. lems that persist today. Software has become a limiting factor in the evolution
of computer-based systems. Software is composed of programs, data, and docu-
Myth: write program and it. work. our job is done. ments. Each of items comprises a configuration that is created as pert af
software The of is to pro-
R e a l i t y : Someone once said that “the sooner you begin ‘writing code’, the
vide a framework for building software with higher quality.
longer it’ll take you to get done.” Industry data indicate that be-
tween 50 and 70 percent of all effort expended on a program will be ex-
pended after it is delivered to the customer for the time. REFERENCES
M y t h : Until I get the program “running,” I really have no way of assess-
ing its quality
Apprentices of Wonder, Bantam, 1989.
Reality: One of the most effective software quality assurance mecha- Begley, S., “Software au Newsweek, May 8, 1995,
nisms can be applied from the inception of a project-the formal technical Brooks, F., Man-Month, Addison-Wesley, 1975.
Software reviews (described in Chapter are a “quality filter” that Cobb, R.H., “In Praise of July 15, 1985, 92.
has been found to be more effective than testing for finding certain classes “How Much is that Ant in the Window,” Economist, vol. 331, no. 7923,
of software errors. July 1994, p. 63.
Myth: The only deliverable for a successful is the working program.
PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 1: THE PRODUCT 21
Feigenbaum, E.A., and The Generation, 1.7. Write a paper summarizing recent advances in one of the leading-edge
Wesley, 1983. application areas. Potential choices include artificial intelligence, virtual reality,
Hammer, M., and J. the Corporation, artificial neural networks, advanced human interfaces, and intelligent agents.
1993. 1.8. The “myths” noted in Section 1.4 are slowly fading as the years pass, but others
Levy, S., “The Luddites Are Back,” Newsweek, July 12, 1995, 55. are taking their place. Attempt to add one or two “new” myths each category.
Lientz, B., and E. Swanson, Software Maintenance Management,
Addison-Wesley, 1980.
Manley, J.H., “CASE: Foundation for Software Factories,” FURTHER READINGS AND INFORMATION SOURCES 6
Proceedings, IEEE, September pp.
Software: The Base Object-Oriented Component
Libraries, Prentice-Hall, 1995. There are literally thousands of books written about computer software. The
Minoli, D, Analyzing Outsourcing, McGraw-Hill, 1995. vast majority discuss programming languages or software applications, but a
Naisbitt, J. Warner Books, 1982. few discuss software itself. An informal treatment of the subject can be found
Osborne, A., Running Wild-The Next Industrial Revolution, in Negroponte’s (Being Digital, Alfred A. Knopf, Inc., 1995) bestselling
Osborne/McGraw-Hill, 1979. book provides a view of computing and its overall impact in the twenty-first
Pressman, R.S., and S.R. Software Shock, Dorset House, 1991. century. (Why Does Software Cost So Much? Dorset House, has
Stoll, C., The Cuckoo’s Egg, Doubleday, 1989. produced a collection of amusing and insightful essays on software and the
Tajima, D., and Matsubara, “Inside the Japanese Software Factory,” process through which it is developed.
Computer, vol. 17, no. 3, March 1984, pp. The basis for a solid understanding of computer software and software en-
A., The Third Morrow, 1980. gineering lies in computer science, a broad collection of topics that are far be-
A., Powershift, Bantam, 1990. yond the scope of this book. The Computer Science Bibliography Collection is a
Software Reuse: Emerging Technology, IEEE Computer Society collection of close to 600 bibliographies in the field of computer science. Nearly
Press, 1988. every topic that is relevant to software engineering is considered in its 300,000
E., T h e D e c l i n e a n d F a l l o f t h e A m e r i c a n P r o g r a m m e r , references:
Press, 1992.
The World Guide to Computer Science contains pointers to many university re-
PROBLEMS AND POINTS TO PONDER search organizations with programs in computing:
1.1. Software is the characteristic in many computer-based products
Provide of two or one
in which software, not hardware, is the differentiating element, A voluminous glossary of software terms, including many common acronyms
1.2. In the 1950s and 1960s computer programming was an art form learned in an can be found at:
apprentice-like environment. How have the early days affected software de-
velopment practices today?
1.3. Many authors have discussed the impact of the “information era.” Provide a
number of examples (both positive and negative1 that indicate the impact of
on our society. Review one of the pre-1990 references in Section 1.1 and Internet Connections Engineering provides a searchable index for engineer-
indicate where the author’s predictions were right and where he was wrong. ing programs throughout the world:
1.4. Choose a specific application and indicate the software application category
(Section into which it fits; the data content with the ap-
plication; the information of the application.
1.6. As software become more pervasive, risks to the public (due to faulty pro-
grams) become an increasingly significant concern. Develop a realistic dooms-
day scenario where the failure of a computer program could do great harm (ei- “Further Reading and Information Sources” section presented at the conclusion of each
ther economic or chapter presents print and electronic information sources that can help to expand your
1.6. Peruse the Internet newsgroup and prepare a summary of risks to derstanding of the major topics presented in the chapter. World Wide Web addresses change
frequently Therefore, some of the uniform resource locators noted in this book may
the public that have recently been discussed. [Alternate source: Software have changed by the time you need them. For an up-to-date set of engineering re-
Engineering Notes, published by the Association of Computing Machinery (ACM).) sources, visit the R.S. Pressman Associates, Inc., Web site at
THE 23
for customer or product it omits mention of
the importance of measurement and metrics; it does not state the importance
of a mature process. And yet, Bauer’s definition provides us with a baseline.
What are the “sound engineering principles” that can be applied to computer
software development? How do we “economically” build software so that it is
THE PROCESS
“reliable”? What is to create computer programs that
on not one but many different “real machines”? These are the questions that
continue to challenge software engineers.
The has a more comprehensive when it
Software Engineering: application of a systematic, disciplined,
to and maintenance of software;
that is, the application of engineering to software. The study of approaches
as in
Process, Methods, and Tools
is 2.1). Any
(including rest an commit-
he software process has been the focus of considerable attention over the ment to quality. Total quality management and similar philosophies foster a con-
last decade. But what exactly is a software process? Within the of tinuous process improvement culture, and this culture that ultimately leads
this book, we define a software process as a framework for the tasks that are to the development of more mature approaches to software engi-
required to build high-quality software. Is “process” synonymous with software neering. The bedrock that supports software engineering is a focus on quality.
engineering? The answer is “yes and no.” A software process defines the ap- The foundation for software engineering is the process layer. Software en-
proach that-is taken as software is engineered, but software engineering also gineering process is the glue that holds the technology layers together and en-
encompasses technologies that populate the process-technical methods and ables rational and timely development of computer software. Process defines a
automated tools. framework for a set of key process areas that must be estab-
More important, software engineering is performed by creative, knowl- lished for effective delivery of software engineering technology The key process
edgeable people who should work within a defined and mature software process. areas form the basis for management control of software projects and establish
The intent of this chapter is to provide a survey of the current state of the soft- the context in which technical methods are applied, work products (models, doc-
ware process and to provide pointers to more detailed discussion of manage- uments, data, reports, forms, etc.) are produced, milestones are established,
ment and technical topics presented later in this book. quality is ensured, and change is properly managed.
* Software engineering methods provide the technical “how to’s” for building
software. Methods encompass a broad array of tasks that include requirements
2.1 SOFTWARE ENGINEERING-A LAYERED analysis, design, program construction, testing, and maintenance. Software
Although hundreds of authors have developed personal definitions of software
engineering, a definition proposed by Fritz Bauer at the seminal
ference on the subject still serves as a basis for discussion: a
[Software engineering is] the establishment and use of sound engineering prin-
ciples in order to obtain economically software that is reliable and works ,
ciently on real machines.
FIGURE 2.1.
Almost every reader will be tempted to add to this definition. It says little Software engineer-
about the technical aspects of software quality; it does not directly address the ing layers.
22
PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 2: PROCESS 25
methods rely on a set of basic principles that govern each area of the to be implemented as a software architecture, how procedural details are to be
technology and include modeling activities and other descriptive techniques. implemented, how interfaces are to be characterized, how the design will be trans-
Software engineering tools provide automated or semi-automated support lated into a programming language (or nonprocedural language), and how testing
for the process and the methods. When tools are integrated so that information will performed. The methods applied during the development phase will vary,
created by one tool can be used by another, a system for the support of three specific technical tasks should always occur: software design (Chapters
development, called software engineering (CASE), is established. 14, 15, and code generation, and software testing (Chapters 16, 17, and 22).
CASE combines software, hardware, and a software engineering database (a The maintenance phase focuses on change that is associated with error
repository containing important information about analysis, design, program correction, adaptations required as the software’s environment evolves, and
construction, and testing) to create a software engineering environment that is changes due to enhancements brought about by changing customer require-
analogous to CAD/CAR (computer-aided design/engineering) for hardware. ments The maintenance phase reapplies the steps of the definition and devel-
opment phases, but does so in the context of existing software. Four types of
change are encountered during the maintenance phase:
2.1.2 A Generic View of Software Engineering Correction Even with the best quality assurance activities, it is likely that the
customer will uncover defects in the software. Corrective maintenance changes
Engineering is the analysis, design, construction, verification, and management the software to correct defects.
of technical (or social) entities. Regardless of the entity that is to be engineered,
the following questions must be asked and answered: Adaptation Over time, the original environment (e.g., CPU, operating system,
rules, external product characteristics) for which the software was de-
!" What is the problem to be solved? veloped is likely to change. Adaptive maintenance results in modification to the
!" What are the characteristics of the entity that is used to solve the problem? software to accommodate changes to its external environment,
!" How will the entity (and the solution) be realized?
Enhancement As software is used, the customer/user will recognize additional
!" How will the entity be constructed?
functions that will provide benefit. maintenance extends the software
!" What approach will be used to uncover errors that were made in the design beyond its original functional requirements.
and construction of the entity?
!" How will the entity be supported over the long term, when corrections, adag prevention Computer software deteriorates due to change, and because of this,
and enhancements are requested by users of the entity? maintenance, often called software reengineering, must be conducted
to enable the software to serve the needs of its end users. In essence, preven-
Throughout this book we focus on a single entity-computer software. To engi- tive maintenance makes changes to computer programs so that they can be
neer software adequately, a software development process must be defined. In more easily corrected, adapted. and enhanced.
this section the generic characteristics of process are considered. Today, “aging software plant” 1.1.2) is forcing companies
Later in this chapter, specific process models are addressed. to pursue software reengineering strategies (Chapter 27). In a global sense,
The work that is associated with software engineering can be categorized software reengineering is often considered as part of business process
into three generic phases, regardless of application area, project size. or com-
plexity. Each phase addresses one or more of the questions noted above. The phases and related steps described in our generic view of software en-
The definition phase focuses on That is, during definition, the soft- gineering are complemented by a number of umbrella activities. Typical activ-
ware developer attempts to identify what information is to be processed, what ities in this category include:
function and performance are desired, what system behavior can be expected,
what interfaces are to be established, what design constraints exist, and what !" Software project tracking and control
validation criteria are required to define a successful system. The key require- !" Formal technical reviews
ments of the system and the software are identified. Although the methods ap-
. Software quality
plied during the definition phase will vary depending upon the software engi-
neering paradigm (or combination of paradigms) that is applied, three major !" Software configuration management
tasks will occur in some form: system or information engineering (Chapter !" Document preparation and production
project planning (Chapters 3 through and requirements analysis !" Reusability management
(Chapters 11, 12, and
The development focuses on That is, during development a soft- !" Measurement
ware engineer attempts to define how data are to be structured, how function is !" Risk management
PART ONE THE PRODUCT AND THE PROCESS CHAPTER 2 THE PROCESS 27
throughout Lho nnd a measure of a
cussed in Parts Two and of this book. company’s software engineering practices and five maturity
which are in following manner:
L e v e l 1 : Initial-The software process is characterized as ad hoc, and oc-
2.2 THE SOFTWARE PROCESS
casionally even chaotic. Few processes are defined, and
depends on individual effort.
A software process can be characterized as shown in Figure 2.2.
Level 2: project management processes are estab-
process framework is established by defining a small number of framework ac-
lished to track cost, schedule, and functionality. The necessary
tivities that are applicable to all software projects, regardless of their size or
process discipline is in place to repeat earlier successes on proj-
complexity. A number of task sets-each a collection of software engineering
ects with similar applications.
work tasks, project milestones, software work products and deliverables, and
quality assurance points-enable the framework activities to be adapted to the Level Defined-The software process for both and
characteristics of the software project and the requirements of the project team. activities is documented, standardized, and integrated
Finally, umbrella activities-such as software quality assurance, software into an organization-wide software process. All projects use a
configuration management, and measurement’-overlay the process model. documented and approved version of the organization’s process
T h i s
throughout the process. characteristics defined for level
In recent years, there has been a significant emphasis on “process matu- L e v e l 4 : Managed-Detailed measures of the software process and prod-
rity” The Software Engineering Institute has developed a com- uct quality are collected. Both the software process and products
prehensive that is predicated on a set of software engineering capabili- are quantitatively understood and controlled using detailed mea-
ties that should be present as organizations reach different levels of process sures. This level includes all characteristics defined for level 3.
maturity. To determine an organization’s current state of process maturity, the L e v e l 5 : Optimizing-Continuousprocess improvement is enabled by
uses an assessment questionnaire and a five-point grading scheme. The quantitative feedback from the process and from testing inno-
grading scheme determines compliance with a capability maturity model vative ideas and technologies. This level includes all character-
that defines key activities required at different levels of process istics defined for level 4.
The five levels defined by the are derived as a consequence of evaluating
‘These topics are discussed in detail in later chapters. responses to the assessment questionnaire that is based on the CMM. The
results of the questionnaire are distilled to a single numerical grade that pro-
vides an indication of an organization’s process maturity.
The has key process areas with each of the maturity levels.
The describe software functions software project
planning, requirements management) that must be present to satisfy good
Framework Activities practice at a particular level. Each KPA is described by identifying the follow-
ing characteristics:
Tasks !" goals-the overall objectives that the KPA must achieve
!" commitments-requirements (imposed on the organization) that must be met
Milestones. deliverables to achieve the goals, and that provide proof of intent to comply with the goals
!" abilities-those things that mustbe in place (organizationally and techni-
SQA points cally) that will enable the organization to meet the commitments
!" activities-the specific tasks that are required to achieve the KPA function
!" methods for monitoring implementation-the manner in which the activities
are monitored as they are put into place
!" methods for verifying implementation-themanner in which proper practice
for the KPA can be verified. Eighteen (each described using the struc-
ture noted above) are defined across the maturity model and are mapped into
2 8 PART THE PRODUCT AND THE PROCESS CHAPTER THE PROCESS 29
different levels of process maturity. The following should be achieved engineering paradigm. A process model for software engineering is cho-
at each process maturity level:” sen based on the nature of the project and application, the methods and tools
be used, and the controls and deliverables that are required. In an intriguing pa-
Process Maturity Level 2 per on the nature of the software process, L.B.S. Raccoon uses fractals
Software configuration management as the basis for a discussion of the true nature of the software process.
Software quality assurance All software development can be characterized as a problem solving loop
(Figure in which four distinct stages are encountered: status quo, problem
Software subcontract management
definition, technical development, and solution integration. Status quo
Software project tracking and oversight the current state of affairs” problem definition identifies the
Software project planning \ problem to be solved; technical development solves the problem through the
Requirements management application of some technology, and solution integration delivers the results
(e.g., documents, programs, data, new business function, new product) to those
Process Maturity Level 3 who requested the solution in the first place. The generic software engineering
Peer reviews phases and steps defined in Section 2.1.2 easily map into these stages.
Intergroup coordination The problem solving loop described above applies to software engineering
Software product engineering work at many different levels of resolution. It can be used at the macro level
when the entire application is considered; at a middle level when program com-
Integrated software management ponents are being engineered, and even at the line of code level. Therefore, a
Training program representation can be used to provide an idealized view of process. In
Organization process definition Figure each stage in the problem solving loop contains an identical prob-
lem solving loop, which contains still another problem solving loop (this con-
Organization process
tinues to some rational boundary; for software, a line of code).
Realistically, it is difficult to compartmentalize activities as neatly as
Software quality management Figure implies because cross-talk occurs within and across stages, yet this
Quantitative process management simplified view leads to a very important idea: Regardless of the process model
that is chosen for a software project, all of the stages-status quo, problem
Process Maturity 5
definition, technical development, and solution integration-coexist
Process change management at some level of detail. Given the recursive nature Figure the four
Technology change management stages discussed above apply equally to the analysis of a complete application
Defect prevention and to the generation of a small segment of code.
Raccoon suggests a “Chaos model” that describes develop-
Each of the is defined by a set of key practices that contribute to satis- ment a continuum from the user to the developer to the technology.” As work
fying its goals. The key practices are policies, procedures, and activities that progresses toward a complete system, the stages described above are applied re-
must occur before a key process area has been fully instituted. The defines cursively to user needs and the developer’s technical specification of the software.
key indicators as “those key practices or components of key practices that offer In the sections that follow, a variety of different process models for software
the greatest insight into whether the goals of a key process area have been engineering are discussed. Each represents an attempt to bring order to an in-
achieved.” Assessment questions are designed to probe for the existence (or lack herently chaotic activity, It is important to remember that each of the models
thereof of a key indicator. has been characterized in a way that (hopefully) assists in the control and co-
ordination of a real software project. yet, at their core, all of the models ex-
hibit characteristics of the Chaos model.
2.3 SOFTWARE PROCESS MODELS
To solve actual problems in an industry setting, a software engineer or a team of 2.4‘ THE LINEAR SEQUENTIAL MODEL
engineers must incorporate a development strategy that encompasses the process,
methods, and tools layers described in Section 2.1.1 and the generic phases dis- Figure 2.4 illustrates the linear sequential model for software engineering.
cussed in Section 2.1.2. This strategy is often referred to as a process or a Sometimes called the “classic life cycle” or the “waterfall model,” the linear se-
that the additive. For example. process maturity level 3 contains level 2 were originally proposed for geometric representations. A pattern is defined and
plus those noted for level 2. then applied recursively at successively smaller scales; patterns fall inside patterns.
30 PART ONE. THE PRODUCT AND THE PROCESS CHAPTER THE PROCESS 31
analysis design code test
technical
development
FIGURE 2.4. The
linear
model.
solution
integration
FIGURE sign, coding, testing, and maintenance. Modeled after the conventional
The phases of a the following activities:
problem solving
loop engineering and modeling. Because is
always part of a larger system (or business), work begins by establishing
requirements for all system elements and then allocating some subset of
these requirements to software. This system view is essential when
ware must interface with other elements such as hardware, people, and
databases. System engineering and analysis encompasses requirements
gathering at the system level with a small amount of top-level analysis and
design. Information engineering encompasses requirements gathering at
the strategic business level and at the business area level.
Software requirements analysis. The requirements gathering process
is intensified and focused specifically on software. To understand the na-
ture of the program(s) to be built, the software engineer (“analyst”) must
understand the information domain (described in Chapter for the soft-
ware, as well as required function, behavior, performance, and interfacing.
Requirements for both the system and the software are documented and
reviewed with the customer.
Design. Software design is actually a multistep process that focuses on
four distinct attributes of a program: data structure, software architecture,
FIGURE and procedural (algorithmic) detail. The design
The phases within process translates requirements into a representation of the software that
phases of the can be assessed for quality before code generation begins. Like require-
problem solving ments, the design is documented and becomes part of the software
loop uration.
Code generation: The design must be translated into a machine read-
quential model suggests a systematic, sequential approach4 to software devel- able form. The code generation step performs this task. If design is per-
opment that begins at the system level and progresses through analysis, formed in a detailed manner, code generation can be accomplished mecha-
nistically.
Testing. Once code has been generated, program testing begins. The test-
the original waterfall model proposed by Winston Royce made provision ing process focuses on the logical internals of the software, assuring that
for feedback loops, the vast majority of organizations that apply this process model treat it
if it strictly linear. all statements have been tested, and on the functional externals-that is,
32 PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 2: THE PROCESS 3 3
conducting tests to uncover errors and ensure that defined input will pro- In these and many other situations, a prototyping paradigm may offer the best
duce actual results that agree with required results. approach.
M a i n t e n a n c e . Software will undoubtedly undergo change it is de- The prototyping paradigm (Figure 2.5) begins with requirements gather-
livered to the customer (a possible exception is embedded software). Change ing. Developer and customer meet and define the overall objectives for the soft-
will occur because errors been encountered, because the software ware, identify whatever requirements are known, and outline areas where fur-
must be adapted to accommodate changes in its external environment (e.g., ther definition is mandatory. A “quick design” then occurs. The quick design
focuses on a representation of those aspects of the software that will be visible
a change required because of a new operating system or peripheral device),
or because the customer requires functional or performance enhancements. to the customer/user (e.g., input approaches and output formats). The quick de-
Software maintenance reapplies each of the preceding phases to an exist- sign leads to the construction of a prototype. The prototype is evaluated by the
customer/user and is used to refine requirements for the software to be devel-
ing program rather than a new one.
oped. Iteration occurs as the prototype is tuned to satisfy the needs of the cus-
tomer, at the same time enabling the developer to better understand what
The linear sequential model is the oldest and the most widely used paradigm
needs to be done.
for software engineering. However, criticism of the paradigm has caused even ac- Ideally, the prototype serves as a mechanism for identifying software re-
tive supporters to question its efficacy Among the problems that are quirements. If a working prototype is built, the developer attempts to make use
sometimes encountered when the linear sequential model is applied are: of existing program fragments or applies tools (e.g., report generators, window
managers, etc.) that enable working programs to be generated quickly.
1. Real projects rarely follow the sequential flow that the model proposes. But what do we do with the prototype when it has served the purpose de-
Although the linear model can accommodate iteration, it does so indirectly. scribed above? Brooks provides an answer:
As a result, changes can cause confusion as the project team proceeds.
2 . It is often difficult for the customer to state all requirements explicitly. The In most projects, the first system built is barely usable. It may be too slow, too
linear sequential model requires this and has difficulty accommodating the big, awkward in use or all three. There is no alternative but to start again,
natural uncertainty that exists at the beginning of many projects. smarting but smarter, and build a redesigned version in which these problems
3 . The customer must have patience. A working version of the program(s) will are solved. When a new system concept or new technology is used, one has
not be’ available until late in the project time-span. A major blunder, if un- to build a system to throw away, for even the best planning is not so omniscient
detected until the working program is reviewed, can be disastrous. as to get it right the first time. The management question, therefore, is not
4. Developers are often unnecessarily. In an interesting analysis of
actual projects, Bradac [BRA941 found that the linear nature of the classic
life cycle leads to “blocking states” in which some project team members
must wait for other members of the to complete dependent tasks. In
fact, the time spent waiting can exceed the time spent on productive work!
The blocking states tend to be more prevalent at the beginning and end of
a linear sequential process. customer
Each of these problems is real. However, the classic life cycle paradigm has
a definite and important place in software engineering work. It provides a tem-
plate into which methods for analysis, design, coding, testing, and maintenance
can be placed. The classic life cycle remains the most widely used process model
for software engineering. While it does weaknesses, it is significantly bet-
,
ter than a haphazard approach to software development.
2.5 THE MODEL
Often, a customer defines a set of general objectives for software but does not
identify detailed input, processing, or output requirements. In other cases, the FIGURE 2.5. The
developer may be unsure of the efficiency of an algorithm, the adaptability of prototyping para-
an operating system, or the form that human-machine interaction should take. digm.
PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 2: THE PROCESS 35
whether to build a pilot system and throw it away. You will do that. The only tern” within short time periods (e.g., 60 to 90 days) Used pri-
question is whether to plan in advance to build a throwaway, or to promise to marily for information systems applications, the RAD approach encompasses
deliver the throwaway to customers. the following phases
The prototype can serve as “the first system.” The one that Brooks recom- B u s i n e s s m o d e l i n g . The information flow among business functions is
mends we throw away. this may be an idealized view. It is true that both modeled in a way that answers the following questions: What information
customers and developers like the prototyping Users get a feel for drives the business process? What information is generated? Who gener-
the actual system and developers get to build something immediately. Yet, ates it? Where does the information go? Who processes it? Business mod-
can also be problematic for the following reasons: eling is described in more detail in Chapter 10.
Data modeling. The information flow defined as part of the business
1. The customer sees what appears to be a working version of the software, modeling phase is refined into a set of data objects that are needed to sup-
unaware that the prototype is held together “with chewing gum and baling port the business. The characteristics (called attributes) of each object are
wire,” unaware that in the rush to get it working we haven’t considered identified and the relationships between these objects are defined. Data
quality or long-term maintainability. When informed that modeling is considered in Chapter 12.
must be rebuilt so that high levels of quality can be main-
P r o c e s s m o d e l i n g . The data objects defined in the data modeling phase
tained, the customer cries foul and demands that “a few fixes” be applied
to make the prototype a working product. Too often, software development are transformed to achieve the information flow necessary to implement a
management relents. business function. Processing descriptions are created for adding, modify-
ing, deleting, or retrieving a data object.
2. The developer often makes implementation compromises in order to get a
prototype working quickly. An inappropriate operating system or program- Application generation.RAD assumes the use of fourth generation
ming be simply because it is available and known; an techniques (Section 2.9). Rather than creating software using conventional
lo third the process works reuse
ity. After a time, the developer may become familiar with these choices and existing program components (when possible) or create reusable compo-
forget all the why they were inappropriate. The less-than-ideal nents (when necessary). In all cases, automated tools are used to facilitate
choice has now become an integral part of the system. construction of the software.
T e s t i n g a n d t u r n o v e r . Since the process emphasizes reuse, many
Although problems can occur, prototyping can be an effective paradigm for of the program components have already been testing. This reduces over-
software engineering. The key is to define the rules of the game at the begin- all testing time. However, new components must be tested and all inter-
ning; that is, the customer and developer must both agree that the prototype faces must be fully exercised.
is built to serve as a mechanism for defining requirements. It is then discarded
(at least in part), and the actual software is engineered with an eye toward The RAD process model is illustrated in Figure 2.6. the time
quality and maintainability. constraints imposed on a RAD project demand “scalable scope” If a
business application can be modularized in a way that enables each major func-
tion to be completed in less than three months (using the approach described
above), it is a candidate for RAD. Each major function can be addressed by a
2.6 THE RAD MODEL separate RAD team and then integrated to form a whole.
Like all process models, the RAD approach has drawbacks
Rapid Application Development is a linear sequential software develop-
ment process model that emphasizes an extremely short development cycle. !"For large, but scalable projects, RAD requires sufficient human resources to
The RAD model is a “high-speed” adaptation of the linear sequential model in create the right number of RAD teams.
which by component-hawed construction !" and who to rapid-fire
arc to complete a system in a much time frame.
the process enables a development team to create a “fully functional If commitment is lacking from either constituency, RAD projects wjll fail.
Not all types of applications are for If a system cannot he
properly modularized, building the components necessary for RAD be
conditionsare by guaranteed.In fact, software projects have poorly
requirementsat the start.In such cases (Section 2.5) or evolutionary lematic. If high performance is an issue, and performance is be achieved through
much better process options. See tuning the interfaces system components, the approach may not work.
36 PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 2: THE PROCESS 37
2.7 EVOLUTIONARY SOFTWARE PROCESS MODELS
There is growing recognition that like all complex systems, evolves
over a period of time Business and product requirements often change
as development proceeds, making a straight line path to an end product unre-
alistic; tight market deadlines make completion of a comprehensive software
product impossible, but a limited version must be introduced to meet competi-
tive or business pressure; a set of core product or system requirements is well
understood, but the details of product or system extensions have yet to be de-
fined. and need a process model
that has been explicitly designed to accommodate a product that evolves over
time.
The linear sequential model (Section 2.4) is designed for straight line de-
velopment. In essence, this waterfall approach assumes that a complete system
will be delivered after the linear sequence is completed. The prototyping model
(Section 2.5) is designed to assist the customer (or developer) in understanding
requirements. In general, it is not designed to deliver a production system. The
evolutionary nature of software is not considered in either of these classic
ware engineering paradigms.
process Evolutionary models are iterative. They are characterized in a manner that
enables software engineers to develop increasingly more complete versions of
the software.
2.7.1 The Incremental Model
application
generation
The incremental model combines elements of the linear sequential model (ap-
plied repetitively) with the iterative philosophy of prototyping. As Figure 2.7
shows, the incremental model applies linear sequences in a staggered fashion
as calendar time progresses. Each linear sequence produces a deliverable “in-
testing crement” of the software For example, de-
veloped using the incremental paradigm might deliver basic file management,
turn&over editing, and document production functions in the first increment; more so-
phisticated editing and document production capabilities in the second incre-
ment; spelling and grammar checking in the third increment; and advanced
page layout in the fourth increment. It should be noted that the
FIGURE 2.6. The process flow for any increment can incorporate the prototyping paradigm.
RAD model. days .
When an incremental model is used, the first increment is often a core
product. That is, basic requirements are addressed, but many supplementary
features (some known, others unknown) remain undelivered. The core product
is used by the customer (or undergoes detailed review). As a result of use and/or
RAD is not appropriate when technical risks are high. This occurs when a new evaluation, a plan is developed for the next increment. The plan addresses the
application makes heavy use of new technology or when the new software re- modification of the core product to better meat the needs of the customer and
quires a high degree of interoperability with existing computer programs. the delivery of additional features and functionality. This process is repeated
RAD emphasizes the development of reusable program components. following the delivery of each increment, until the complete product is pro-
Reusability (see Chapter is the cornerstone of object technologies (Part Four duced.
of this book), and is encountered in the component assembly process model dis- The incremental process model, like prototyping (Section 2.5) and other
cussed in Section 2.7.3. evolutionary approaches, is iterative in nature. But unlike prototyping, the
CHAPTER 2: THE PROCESS 39
cremental model focuses on the delivery of a operational product with each in-
crement. Early increments are “stripped down” versions of the final product,
but they do provide capability that serves the user and also provide a platform
for evaluation by the user.
development is particularly useful when is unavail-
able for a complete implementation by the business deadline that has been es-
tablished for the project. Early increments can be implemented with fewer
ple. If the core product is well received, then additional staff (if required) can
be added to implement the next increment. In addition, increments can be
planned to manage technical risks. example, a major system might require
the availability of new hardware that is under development and whose deliv-
ery date is uncertain. It might be possible to plan early increments in a way
that avoids the use of this hardware, thereby enabling partial functionality to
be delivered to end users without inordinate delay.
2.7.2 The Model
The spiral model, originally proposed by Boehm is an evolutionary
eoftware process model that couples the iterative nature of prototyping with
the controlled and systematic aspects of the linear sequential model. It pro-
vides the potential for rapid development of incremental versions of the soft-
ware. In the spiral model, software is developed in a series of incremental re-
leases. During early iterations, the incremental release might be a paper model
or prototype. During later iterations, increasingly more complete versions of
the engineered system are produced.
The spiral model is divided into a number of framework also
called task regions.” Typically, there are between three and six task regions.
Figure 2.8 depicts a spiral model that contains six task regions:
!" customer communication-tasksrequired to establish effective communi-
cation between developer and customer
!" planning-tasks required to define resources, timelines, and other
related information
!" risk analysis-tasks required to assess both technical and management risks
!" engineering-tasks required to build one or more representations of the ap-
plication
!" construction release-tasks required to construct, test, install and
vide user support (e.g., documentation and training)
!" customer evaluation-tasks required to obtain customer feedback based
on evaluation of the software representations created during the engineering
stage and implemented during the installation stage.
spiral discussed in this section is variation on the model proposed by Boehm.
For further information the original model,
38
PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 2: THE PROCESS 41
whenever a change is initiated, the process starts at the appropriate entry
point (e.g., product enhancement).
The spiral model is a realistic approach to the development of large scale
systems and software. Because software evolves as the process progresses, the
developer and customer better understand and react to risks at each evolu-
tionary level. The spiral model uses prototyping as a risk reduction mechanism,
but more important, enables the developer to apply the prototyping approach
at any stage in the evolution of the product. It maintains the systematic
wise approach suggested by the classic life cycle, but incorporates it into an it-
erative framework that more realistically reflects the real word. The spiral
model demands a direct consideration of technical risks at all stages of the
project, and if properly applied, should reduce risks before they become prob-
lematic.
But like other paradigms, the spiral model is not a panacea. It may be dif-
FIGURE 2.8. A ficult to convince customers (particularly in contract situations) that the evo-
typical spiral lutionary approach is controllable. It demands considerable risk assessment ex-
model. pertise, and relies on this expertise for success. If a major risk is not uncovered
and managed, problems will undoubtedly occur. Finally, the model itself is rel-
atively new and has not been used as widely as the linear sequential or
Each of the regions is populated by a series of work tasks that are adapted to typing paradigms. It will take a number of years before the efficacy of this im-
the characteristics of the project to be undertaken. For small projects, the num- portant new paradigm can be determined with absolute certainty.
ber of work tasks and their formality is low. For larger, more critical projects,
each task region contains more work that are defined to a higher
level of formality In all cases, the umbrella activities (e.g., software configura-
tion management and software quality assurance) noted in Section 2.2 are ap-
plied.
As this evolutionary process begins, the software engineering team moves
around the spiral in a clockwise direction, beginning at the core. The first cir-
cuit around the spiral might result in the development of a product specifica-
tion; subsequent passes around the spiral might be used to develop a prototype
and then progressively more sophisticated versions of the software. Each pass
through the planning region results in adjustments to the project plan. Cost
and schedule are adjusted based on feedback derived from customer evalua- axis
tion. In addition, the project manager adjusts the planned number of iterations
required to complete the software.
Unlike classical process models that end when software is delivered, the
spiral model can be adapted to apply throughout the life of the computer soft-
ware. entry point axis is defined in Figure 2.9. Each cube placed along
the axis represents the starting point for a different type of project. A concept
development project starts at the core of the spiral and will continue (mul- \
tiple iterations occur along the spiral path that bounds the central shaded Evaluation Construction Release
until concept development is complete. If the concept is to be developed
into an actual product, the process proceeds through the next cube (new prod-
uct development project entry point) and a new development project is ini- Product Maintenance Projects
tiated. The new product will evolve through a number of iterations around the Product Enhancement Projects
spiral following the path that bounds the region that has somewhat lighter FIGURE 2.9.
shading than the core. A similar process flow occurs for other types of projects. Spiral model New Product Development Projects
In essence, the spiral, when characterized in this way, remains operative adapted for the
entire life cycle. Concept Development Projects
until the software is retired. There are times when the process is dormant, but
PART THE PRODUCT AND THE PROCESS CHAPTER 2. THE PROCESS 43
2.7.3 The Component Assembly Model Classes (called components in Figure 2.10) created in past software engi-
neering projects are stored in a class library or repository (Chapter 29). Once
Object technologies (Chapter 19) provide the technical framework for a compo- candidate classes are identified, the class library is searched to determine if
nent-based process model for engineering. The object-oriented para- these classes already exist. If they do, they are extracted from the library and
digm emphasizes the creation of classes that encapsulate both data and the reused. If a candidate class does not reside in the library, it is engineered us-
algorithms that are used to manipulate the data. If properly designed and im- ing object-oriented methods (Chapters 20-22). The first iteration of the appli-
plemented, object-oriented classes are reusable across different applications cation to be built is then composed, using classes extracted from the library and
and computer-based system architectures. any new classes built to meet the unique needs of the application. Process flow
The component assembly model (Figure 2.10) incorporates many of the then returns to the spiral and will ultimately reenter the component assembly
characteristics of the spiral model. It is evolutionary in nature de- iteration during subsequent passes through the engineering activity.
manding an iterative approach to the creation of software. However, the com- The component assembly model leads to software reuse, and reusability
ponent assembly model composes applications from prepackaged software com- provides software engineers with a number of measurable benefits. Based on
ponents (sometimes called “classes”). studies of reusability, QSM Associates, Inc. reports component assembly leads
The engineering activity begins with the identification of candidate classes. to a 70% reduction in development cycle time, an 84% reduction in project cost,
This is accomplished by examining the data that are to be manipulated by the and a productivity index of 26.2, compared to an industry norm of 16.9
application and the algorithms that will be applied to accomplish the Although these results are a function of the robustness of the component li-
Corresponding data and algorithms are packaged into a class. brary, there is little question that the component assembly model provides sig-
nificant advantages for software engineers.
‘This is a simplified description of class definition. For a more detailed discussion, see Chapter
19.
2.7.4 The Concurrent Development Model
The concurrent development model, sometimes called concurrent engineering,
has been described in the following manner by Davis and
Project managers who track project status in terms of the major phases [of the
classic life cycle1 have no idea of the status of their projects. These are exam-
ples of trying to track extremely complex sets of activities using overly simple
models. Note that although la project is in the coding phase, there are
personnel on the project involved in activities typically associated with many
phases of development simultaneously, For example, personnel are writing
Customer requirements, designing, coding, testing, and integration testing [all at the
Software by Humphrey and
have shown the concurrency that exists for activities occur-
ring during any one phase. Kellner’s more recent work uses
charts notation that represents the states of a process, see Chapter to
represent the concurrent relationship existent among activities associated with
a specific event a requirements change during late development), but fails
to capture the richness of concurrency that exists across all software develop-
ment and management activities in a project. . . Most software development
I II I I process models are driven by time; the later it is, the later in the development
process you are. concurrent process model] is driven by user needs, man-
agement decisions, and review results.
I
I , The concurrent process model can be represented schematically as a series
of major technical activities, tasks, and their associated states. For example, the
FIGURE 2.10. The component assembly model. engineering activity defined for the spiral model (Section is accomplished
44 PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 2: THE PROCESS 45
sis activity (which existed in the none state while initial customer communi-
none cation was completed) now makes a transition into the under development
state. If, however, the customer indicates that changes in requirements must
Analysis activity be made, the analysis activity moves from the under development state into
the a w a i t i n g c h a n g e s state.
The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the software engineering activities. For
example, during early stages of design, an inconsistency in the analysis model
is uncovered. This generates the event analysis model correction, which will trig-
ger the analysis activity from the done state into the awaiting changes state.
The concurrent process model is often used as the paradigm for the devel-
opment of applications (Chapter 28). A client/server system is
composed of a set of functional components. When applied to client/server, the
concurrent process model defines activities in two dimensions a sys-
tem dimension and a component dimension. System level issues are addressed
using three activities: design, and use. The component dimension is
addressed with two activities: design and realization. Concurrency is achieved
in two ways: system and component activities occur simultaneously and can
be modeling using the state-oriented approach described above; a typical
client/server application is implemented with many components, each of which
can be designed and realized concurrently.
In reality, the concurrent process model is applicable to all types of soft-
ware development and provides an accurate picture of the current state of a
project. Rather than confining software engineering activities to a sequence of
events, it defines a network of activities. Each activity on the network exists si-
multaneously with other activities. Events generated within a given activity or
at some other place in the activity network trigger transitions among the states
of an activity.
0
FIGURE 2.11.
One element of represents a state of a 2.8 THE FORMAL METHODS MODEL
the concurrent software engineered activity
process model. The formal methods model encompasses a set of activities that lead to mathe-
matical specification of computer software. Formal methods enable a software
engineer to specify, develop, and verify a computer-based system by applying a
by invoking the following tasks: prototyping and/or analysis modeling, require- rigorous, mathematical notation. A variation on this approach, called
ments specification, and designs engineering is currently applied by some software
Figure 2.11 provides a schematic representation of one activity within the development organizations.
concurrent process model. The activity-analysis-may be in any one of the When formal methods (Chapters 24 and are used during development,
noted at any given time. Similarly, other activities (e.g., design or cus- they provide a mechanism for eliminating many of the problems that are diffi-
tomer communication) can be represented in an analogous manner. All activi- cult to overcome using other software engineering paradigms. Ambiguity, in-
ties exist concurrently but reside in different states. For example, early in a completeness, and inconsistency can be discovered and corrected more
project the customer communication activity (not shown in the figure) has com- not through ad hoc review, but through the application of mathematical analysis.
pleted its first iteration and exists in the awaiting changes state. The When formal methods are used during design, they serve as a basis for
*It should noted that analysis and design complex tasks that require substantial dis- client/server applications. software functionality is divided between clients (normally
cussion. Parts Three and Four of this book consider these topics in detail. and a powerful computer) that typically maintains a centralized data-
state is some externally observable mode of behavior. base.
\ 47
gram verification and therefore enable the software engineer to discover and velop a design strategy for the system, even if a 4GL is to be used. The use of
correct errors that might otherwise go undetected. 4GT without design (for large projects) will cause the same difficulties (poor
Although not yet a mainstream approach, the formal methods model offers quality, poor maintainability, poor customer acceptance) that we have encoun-
the promise of defect-free software. Yet, concern about its applicability in a tered when developing software using ad hoc approaches.
business environment has been voiced: Implementation using a 4GL enables the software developer to represent
desired output in a manner that results in automatic generation of code to gen-
1. The development of formal models is currently quite time-consuming and erate the output. Obviously, a data structure with relevant information must
expensive. exist and be readily accessible by the 4GL.
2 . Because few developers have the necessary background to apply To transform a 4GT implementation into a product, the developer must
formal methods, extensive training is required. conduct thorough testing, develop meaningful documentation, and perform all
other solution integration activities that are required in other software engi-
3 . It is difficult to use the models as a communication mechanism for techni-
neering paradigms. In addition, the software must be built in a
cally unsophisticated customers.
manner that enables maintenance to be performed expeditiously,
Like all software engineering paradigms, the 4GT model has advantages
These concerns notwithstanding, it is likely that the formal methods ap- and disadvantages. Proponents claim dramatic reduction in software develop-
proach will gain adherents among software developers that must build ment time and greatly improved productivity for people who build software.
critical software (e.g., developers of aircraft avionics and medical devices) and Opponents claim that current 4GT tools are not all that much easier to use
among developers that would suffer severe economic hardship should software than programming languages, that the resultant source code produced by such
errors occur. tools is “inefficient,” and that the maintainability of large software systems de-
veloped using 4GT is open to question.
There is some merit in the claims of both sides and it is possible to sum-
marize the current state of 4GT approaches:
2.9 FOURTH GENERATION TECHNIQUES
1. The use of 4GT has broadened considerably over the past decade and is
The term “fourth generation techniques” encompasses a broad array of now a viable approach for many different application areas. Coupled
software tools that have one thing in common: Each enables the software en- with software engineering (CASE) tools and code gener-
gineer to specify some characteristic of software at a high level. The tool then ators, 4GT offers a credible solution to many software problems.
automatically generates source code based on the developer’s specification.
There is little debate that the higher the level at which software can be 2. Data collected from companies who are using 4GT indicates that the time
lied to a machine, the faster a program can be built. The 4GT paradigm for soft- required to produce software is greatly reduced for small and intermediate
ware engineering focuses on the ability to specify software using specialized applications and that the amount of design and analysis for small applica-
language forms or a graphic notation that describes the problem to be solved tions is also reduced.
in terms that the customer can understand. 3. However, the use of 4GT for large software development efforts demands
Currently, a software development environment that supports the 4GT par- as much or more analysis, design, and testing (software engineering activ-
adigm includes some or all of the following tools: nonprocedural languages for ities) to obtain the substantial time saving that can be achieved through
database query, report generation, data manipulation, screen interaction and the elimination of coding.
definition, and code generation; high-level graphics capability; and spreadsheet
capability. Initially, many of the tools noted above were available only for very To summarize, fourth generation techniques have already become an im-
specific application domains, but today 4GT environments have been extended portant part of software development. When coupled with component assembly
to address most software application categories. approaches (Section the 4GT paradigm may become the dominant ap-
Like other paradigms, 4GT begins with a requirements gathering step. proach to software development.
Ideally, the customer would describe requirements and these would be directly
translated into an operational prototype. But this is unworkable. The customer
may be unsure of what is required, may be ambiguous in specifying that
are known, and may be unable or unwilling to specify information in a manner 2.10 PROCESS TECHNOLOGY
that a 4GT tool can consume. For this reason, the customer-developer dialog de-
scribed for other process models remains an essential part of the 4GT approach. The process models discussed in the preceding sections must be adapted for use
For small applications, it may be possible to move directly from the re- by a software project team. To accomplish technology tools have been
quirements gathering step to implementation using a nonprocedural fourth developed to help organizations analyze their current process, organize
generation language However, for larger efforts, it is necessary to de- work tasks, control and monitor progress, and manage technical
PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 2: THE PROCESS 49
Process technology tools allow a software organization to build an auto- while the rapid assimilation of reuse goals’ into develop-
mated model of the common process framework, task sets, and umbrella activ- ment potentially increases the satisfaction software practitioners derive from
ities discussed in Section 2.3. The model, normally represented as a network, their work, it also increases the urgency for acceptance of the duality of prod-
can then be analyzed to determine and examine alternative uct and process. Thinking of a reusable artifact as only product or only
process structures that might lead to reduced development time or cost. either obscures the context and ways to use it or obscures fact that each
Once an acceptable process has been created, other process technology tools use results in product that will, in turn, be used as input to some other soft-
can be used to allocate, monitor, and even control all engineering tasks ware development activity Taking one view over the other dramatically reduces
defined as part of the process model. Each member of a software project team the opportunities for reuse and, hence, loses the opportunity for increasing job
can use such tools to develop a checklist of work tasks to be performed, work satisfaction.
products to be produced, and quality assurance activities to be conducted. The
process technology tool can also be used to coordinate the use of other com- People derive as much (or more) satisfaction from the creative process as
puter-aided software engineering tools (Chapter that are appropriate for a they do from the end product. An artist enjoys the brush strokes as much as
particular work task she enjoys the framed result. A writer enjoys the search for the proper metaphor
as much as the finished book. A creative software professional should also de-
rive as much satisfaction from the process as the end product.
2.11 PRODUCT AND PROCESS The work of software people will change in the years ahead. The duality of
product and process is one important element in keeping creative people en-
gaged as the transition from programming to software engineering is finalized.
If the process is weak, the end product will undoubtedly suffer. But an
sive over-reliance on process is also dangerous. In a brief essay, Margaret Davis
comments on the duality of product and process: 2.12 SUMMARY
About every ten years give or take five, the software community redefines “the Software engineering is a discipline that integrates process, methods, and tools
problem” by shifting its focus from product issues to process issues. Thus, we for the development of computer software. A number of different process mod-
have embraced structured programming languages (product) followed by struc- els for software engineering have been proposed, each exhibiting strengths and
tured analysis methods (process) followed by data encapsulation (product) fol- weaknesses, but all having a series of generic phases in common. The princi-
lowed by the current emphasis on the Software Engineering Institute’s Software ples, concepts, and methods that enable us to perform the process that we call
Development Capability Maturity Model (process). software engineering are considered throughout the remainder of this book.
While the natural tendency of a pendulum is to come to rest at a point mid-
way between two extremes, the community’s focus constantly shifts
because new force is applied when the last swing fails. These swings are harm-
ful in and of themselves because they confuse the average software practitioner REFERENCES
by radically changing what it means to perform the job, let alone perform it
well. The swings also do not solve “the problem,” for they are doomed to fail as Bandinelli, S. et al., “Modeling and Improving an Industrial
long as product and process are treated as forming a dichotomy instead of a du- Process,” IEEE Software Engineering, vol. 21, no. 5, May 1995,
ality. pp. 440-454.
There is precedence in the community to advance notions of du- Boehm, B., “A Spiral Model for Software Development and En-
ality when contradictions in observations cannot be fully explained by one com- hancement,” Computer, vol. 21, no. May 1988, pp. 61-72.
peting theory or another. The dual nature of light, which seems to be simulta- Bradac, M., D. Perry, and L. Votta, ‘Prototyping a Process Monitoring
neously particle and wave, has been accepted since the 1920s when Louis de IEEE Trans. Engineering, vol. 20, no. 10, October
Broglie proposed it. I believe that the observations we can make on the arti- 1994, pp. 774-784.
facts of software and its development demonstrate a fundamental duality be- Brooks, F., Mythical Man-Month, Addison-Wesley, 1975.
tween product and process. You can never derive or understand the full arti- [BUT941 Butler, J., “Rapid Application Development in Action,” System
fact, its context, use, meaning, and worth if you view it as only a process or only Applied Computer Research, vol. 14, no. 5, May 1994, pp.
a product. 6-8.
All of human activity may be a process, but each of us derives a sense of Davis, A., and I? “A Concurrent Process Model for Software
self-worth from those activities that result in a representation or instance that Development, Engineering Notes, ACM Press, vol. 19, no. 2,
can be used or appreciated either by more than one person, used over and over, April 1994, pp. 38-51.
or used in some other context not considered. That is, we derive feelings of sat- Davis, M.J., “Process and Product: Dichotomy or Duality,” Software
isfaction from reuse of our products by ourselves or others. Engineering Notes, ACM Press, vol. 20. no. 2, April 1995, pp. 17-18.
PART ONE: THE PRODUCT AND THE PROCESS CHAPTER THE PROCESS 51
Dyer, M., The Cleanroom Approach to Quality Software Development, Management. Do a bit of research and develop an outline of the key tenets of
Wiley, 1992. a Totnl Quality Management program.
Gilb, Principles of Software Engineering Management, 2.2. Is there ever a case when the generic phases of the software engineering
Wesley, 1988. process don’t apply? If so, describe it.
Hanna, M., “Farewell Waterfalls,” Software Magazine, May 1995, pp. 2 . 3 . The Capability Maturity Model is an evolving document. Do some re-
38-46. search and determine if any new have been added since the publication
Humphrey, and M. Kellner, Process Modeling: Principles of this book.
of Entity Process 11th on Software Engineering, 2.4. The Chaos model suggests that a problem solving loop can be applied at any
IEEE Computer Society Press, pp. 331-342. degree of resolution. Discuss the way in which you would apply the loop to
Standards Collection: Software Engineering, IEEE Standard understand requirements for a new word-processing product; develop a ad-
610.12-1990, IEEE, 1993. vanced spelling/grammar checking component for the word processor; gen-
Kellner, M., Software Process Modeling: Value and Experience, erate code for a program module that determines the subject, predicate, and
Technical Review-1989 SEI, Pittsburgh, PA, 1989. object in an English language sentence.
Kellner, M., “Software Process Modeling Support for Management 2.5. Which of the software engineering paradigms presented in this chapter do
Planning and Control,” 1st Zntl. on the Software Process, you think would be most effective? Why?
IEEE Computer Society Press, 1991, pp. 8-28. 2.6. Provide five examples of software development projects that would be
Kerr, J., and R. Hunter, Inside McGraw-Hill, 1994. amenable to prototyping. Name two or three applications that would be more
Martin, J., Rapid Application Development, Prentice-Hall, 1991. difficult to prototype.
J., and Rook, “Software Development Process Models,” in 2.7. The RAD model is often tied to CASE tools. Research the literature and pro-
Software Engineer’s Reference Book, CRC Press, 1993, pp. vide a summary of a typical CASE tool that supports RAD.
Mills, H.D., M. Dyer, and R. Linger, “Cleanroom Software Engineering,” 2.8. Propose a specific software project that would be amenable to the incremen-
Software, September 1987, pp. 19-25. tal model. Present a scenario for applying the model to the software.
and B. Randall Software Engineering: A Report on a 2.9. As you move outward along the process flow path of the spiral model, what
Conference Sponsored by the NATO Science Committee, N A T O , 1 9 6 9 . can you nay about software that is being developed mnintninsd?
“Component-Oriented Software Development, CACM, vol. 2.10. Many people believe that the only way in which order of magnitude im-
35, no., 1992, pp. provements in software quality and productivity will be achieved is through
M. et al., Capability Maturity Model for Software, Software component assembly. Find three or four recent papers on the subject and
Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, them for the class.
1993. 2.11. Describe the concurrent development model in your own words.
Raccoon, L.B.S., “The Chaos Model and the Chaos Life Cycle,” ACM 2.12. Provide three examples of fourth generation techniques.
Engineering Notes, vol. no. 1, January, 1995, pp. 2.13. Which is more important-the product or the process?
IRE1951 Reilly, Live Up to the Software, September,
1995, pp. 24-26.
Royce, W.W., “Managing the Development of Large Software Systems:
Concepts and Techniques,” WESCON, August 1970. FURTHER READINGS AND OTHER INFORMATION SOURCES
W., “Concurrent Engineering: A New Paradigm for C/S
Development vol. 1, no. 6, June 1994, The current state of the art in software engineering can best be determined
pp. 28-33. from monthly publications such as Software, Computer, and the
“The Roots of Business Process American Transactions on Software Engineering. Industry periodicals such as Application
Programmer. vol. 8, no. 6, June 1995, pp. 3-7. Development and Software Development often contain articles on soft-
E., ‘Software Development Strategies, vol. ware engineering topics. The discipline is “summarized” every year in the
VI, no. 12, December 1994, p. l-16. Proceedings of the Conference on Software Engineering (spon-
sored by the IEEE and ACM) and is discussed in depth in journals such as
ACM Transactions Engineering and Methodology, ACM Software
Engineering Notes, and Annals Software Engineering.
PROBLEMS AND POINTS TO PONDER Many engineering books been published in recent years.
Some present an overview of the entire process while others delve into a few
2.1. Figure 2.1 places the three software engineering layers on top of a layer en- important topics to the exclusion of others. Three anthologies that cover a wide
titled “a quality focus.” This implies a quality program such as Total Quality range of software engineering topics are:
PART ONE: THE PRODUCT AND THE PROCESS CHAPTER 2: THE PROCESS 53
Keyes, J. Software Engineering Productivity A useful source of software engineering information, including a quarterly
Hill, 1993. newsletter, can be found at:
Marchiniak, J.J. Encyclopedia of Software Engineering, Wiley, 1994.
J. Software Engineer’s Reference Book, CRC Press, 1993.
The Software Engineering Research Center has an ongoing technical
Gautier (Distributed Engineering of Software, Prentice-Hall, 1996) provides report series describing research results. These can be found at:
suggestions and guidelines for organizations that must develop software across
geographically dispersed locations.
On the lighter side, a book by Robert Glass Conflict,
19911 presents amusing controversial on and
A of that to
software engineering process. Pressman and Shock, Dorset the Internet are available at:
House, 1991) consider software and its impact on individuals, businesses, and
government.
The Software Engineering Institute is located at Carnegie-Mellon
University) has been chartered with the responsibility of sponsoring a software
engineering monograph series. Practitioners from industry, government, and aca- An up-to-date list of World Wide Web references that are relevant to the soft-
demia are contributing important new work. Additional software engineering ware process can be found at:
publications are produced regularly by the Software Productivity Consortium.
A wide variety of software engineering standards and procedures have
been published over the past decade. The IEEE Software Engineering
Standards contains many different standards that cover almost every impor-
tant aspect of the technology. IS0 9000-3 guidelines provides guidance for soft-
ware organizations that require registration to the IS0 9001 quality standard.
Other software engineering standards can be obtained from the Department
of Defense, the FAA, and other government and not-for-profit agencies.
Fairclough (Software Engineering Guides, Prentice-Hall, 1996) provides a de-
tailed reference to software engineering standards produced by the European
Space Agency
A wide variety of information sources on software engineering and the soft-
ware process are available on the Internet. Further information on software en-
gineering can be obtained from technical societies and organizations:
ACM
European SPI Initiative
IEEE
NASA Software Engineering Lab
Research Access Clearing House
Software Engineering Institute
Software Engineering Lab,
Software Engineering Web Sites
Software Productivity Center, Canada
Software Productivity Consortium
MANAGING
SOFTWARE
-- PROJECTS
In this part of Software Engineering: A Practitioner’s Approach we consider the management tech-
niques required to plan, organize, monitor, and control software projects. In the chapters that follow,
we address the following questions:
!" must people, process, and problem be managed during a software project?
!" What are software metrics and how can they be used to manage the software process and the pro-
ject conducted as part of the process?
!" What metrics assist a manager is assessing the quality of the products that are produced and the
effectiveness of the process that is applied? __
!" How does a software team generate reliable estimates of effort, cost, and project duration?
!" When should an organization build computer software; when should it acquire software, and when
should it outsource?
!" What techniques can be used to formally assess the risks that can have an impact on project suc-
cess?
!" How does a software project manager select the set of software engineering work tasks that are
appropriate for a particular project?
!"How is a project schedule created?
!"How is quality defined in a manner that allows a software project team to control it?
!" What is software quality assurance and how is it used as a project control mechanism?
!" Why are formal technical reviews so important?
!" How is change managed during the development of computer software and after it is delivered to
the customer?
Once these questions are answered, you’ll be better prepared to manage software projects in a way that
will lead to timely delivery of a high quality product.
PROJECT MANAGEMENT
CONCEPTS
n the preface to his book on project management, Meiler
I Jones makes a statement that can be echoed by many software en-
gineering consultants:
I’ve visited dozens of commercial shops, both good and bad, and I’ve observed
scores of data processing managers, again, both good and bad. Too often, I’ve
watched in horror as these managers futilely struggled through nightmarish
projects, squirmed under impossible deadlines, or delivered systems that out-
raged their users and went on devour huge chunks of maintenance time.
What Page-Jones describes are symptoms that result from an array of man-
agement and technical problems. However, if a postmortem were to be con-
ducted for every project, it is very likely that a consistent theme would be en-
countered: project management was weak.
In this chapter and the six that follow we will consider the key concepts
that lead to effective software project management. This chapter considers
basic software project management concepts and principles. Chapter 4 pre-
sents process and project metrics, the basis for effective management decision
making. The techniques that are used to estimate cost and resource require-
ments and establish an effective project plan are discussed in Chapter 5. The
management activities that lead to effective risk monitoring, mitigation, and
management are presented in Chapter 6. Chapter 7 discusses the activities
that are required to define project tasks and establish a workable project
schedule. Finally, Chapters 8 and 9 consider techniques for ensuring quality
as a project is conducted and controlling changes throughout the life of an
application.
IWO MANAGING SOFTWARE PROJECTS J 59
3.1 THE MANAGEMENT SPECTRUM data, functions, and behaviors characterize the problem, and more impor-
tant, attempts to bound these characteristics in a quantitative manner.
Once the project objectives and scope are understood, alternative solutions
Effective software project management focuses on the three P’s: people, prob- are Although very little detail is discussed, the alternatives enable
lem, and process. The order is not arbitrary. The manager who forgets that soft- managers and practitioners to select a ‘best” approach, given the constraints
ware engineering work is an intensely human endeavor will never have imposed by delivery deadlines, budgetary restrictions, personnel availability,
in project management. A manager who fails to encourage comprehensive technical interfaces, and myriad other factors.
customer communication early in the evolution of a project risks building an
elegant solution the wrong problem. Finally, the manager who pays little at-
tention to the process runs the risk of inserting competent technical methods ..
and tools into a vacuum. 3.1.3 The Process
A software (Chapter provides the framework from which a compre-
hensive plan software development can be established. A small number of
3.1.1 People
framework activitiesare applicable to all software projects, regardless of their
size or complexity. A number of different task sets-tasks, milestones,
The cultivation of highly people been discussed and quality assurance points-enable the framework activities to
since In fact, the “people factor” is lo of snd the of
important that the Software Engineering lnstitute has developed a people the project team. Finally, umbrella activities-such software quality
management maturity (PM-CMM) “to enhance the readiness software configuration management, and measurement-overlay the
of software organizations to undertake increasingly complex applications by process model. Umbrella activities are independent of any one framework ac-
helping to attract, grow, motivate, deploy, and retain the talent needed to im- tivity and occur throughout the process.
prove their software development capability”
The people management maturity model defines the following key practice
areas for software people: recruiting, selection, performance management,
training, compensation, career development, organization and work design, and 3.2 PEOPLE
team/culture development. Organizations that achieve high levels of maturity
in the people management area have a higher likelihood of implementing ef- In a study published by the IEEE [CUR881 the engineering vice presidents of
fective software engineering practices. three major technology companies were asked the most important contributor
The PM-CMM ix companion to capability maturity project. answered in the following way:
(Chapter which guides organizations in the creation of a mature software
process. Issues associated with people management and structure for software VP 1: guess if you had to pick one thing out that is most important in
projects are considered later in this chapter. our environment, I’d say it’s not the tools that we use, it’s the peo-
ple.
VP 2: The most important ingredient that was successful on this proj-
3.1.2 The Problem ect was having smart people . . very little else matters in my
opinion.. The most important thing you do for a project is se-
lecting the staff... The success of the software development
its and should established, in ability
and good people.
should idcntificd. Without this information, it is impossible to de-
fine reasonable (and accurate) estimates of the cost; an effective assessment of VP 3: The only rule I have in management is to ensure have good peo-
risk; a realistic breakdown of project tasks; or A manageable project schedule ple-real good people-and that grow good people-and that I
provide an environment in which good people can
that provides a meaningful indication of progress.
The software developer and customer must meet to define project objectives
and scope, In many cases, this activity begins as part of the system engineering Indeed, this is a compelling testimonial on the importance of people in the soft-
process (Chapter and continues as the first step in software requirements ware engineering process. And yet, all of us, from senior engineering vice pres-
analysis (Chapter 11). Objectives identify the overall goals of the project with- idents to the lowliest practitioner, often take people for granted. Managers ar-
out considering how these goals will be achieved. Scope identifies the primary gue (as the group above had done) that people are primary, but their actions
PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 3: PROJECT MANAGEMENT CONCEPTS 61
sometimes belie their words. In this section we examine the players who par- derstanding the problem to be solved, managing the flow of ideas, and at the
ticipate in the software process and the manner in which they are organized to same time, letting everyone on the team know (by words, and far more impor-
perform effective software engineering. tant, by actions) that quality counts and that it will not be compromised.
Another view IEDG951 of the characteristics that an effective proj-
ect manager emphasizes four key traits:
3.2.1 The Players
Problem solving. An effective software project manager can diagnose
the technical and organizational issues that are most relevant, systemati-
The software process (and every software project) is populated by players who cally structure a solution or properly motivate other practitioners to de-
can be categorized into one of five constituencies: velop the solution, apply lessons learned from past projects to new situa-
tions, and remain flexible enough to change direction if initial attempts at
1. Senior managers, who define the business issues that often have significant problem solution are fruitless.
influence on the project. M a n a g e r i a l i d e n t i t y . A good project manager must take charge of the
2. Project managers, who must plan, motivate, organize, and con- project. She must have the confidence to assume control when necessary
trol the practitioners who do software work. and the assurance to allow good technical people to follow their instincts.
3. who the that necessary to A c h i e v e m e n t . To productivity of a project a manager
product or must initiative and accomplishment, and through
4. Customers, who specify the requirements for the software to be engineered. own actions that controlled risk taking will not be punished.
5. End users, who interact with the software once it is released for production An
Influence and team building. effective project manager must be
use. able to “read” people; she must be able to understand verbal and nonverbal
signals and react to the needs of the people sending these signals. The man-
Every software project is populated by the players noted above. To be ef- ager must remain under control in high-stress situations.
fective, the project team must be organized in a way that maximizes each per-
son’s skills and abilities. That’s the job of the team leader.
3.2.3 The Software Team
3.2.2 Team leaders There are almost as many human organizational structures for software de-
velopment as there are organizations that develop For better or
Project management is a people-intensive activity, and for this reason, compe- worse, organizational structure cannot be easily modified. Concern with the
tent practitioners often tram leaders. simply don’t have practical and political consequences of organizational change is not within the
right mix of people skills. And yet, as Edgemon states: “Unfortunately and all project manager’s scope of responsibilities. However, organization
too frequently it seems, individuals just fall into a project manager role and be- of the people directly involved in a new software project is within the project
come accidental project managers” manager’s purview.
What do we look for when we select someone to lead a software project? In The following options are available for applying human resources to a proj-
an excellent book of technical attempts to ect that will require people working for k years:
answer this question by suggesting the of leadership:
1. individuals are assigned to different functional tasks, relatively little
M o t i v a t i o n . The ability to encourage (by “push or pull”) technical people combined work occurs; coordination is the responsibility of a man-
to produce to their best ability. ager who may have six other projects to be concerned with;
O r g a n i z a t i o n . The ability to mold existing processes (or invent new ones) 2. individuals are assigned to different functional tasks so that
that will enable the initial concept to be translated into a final product. informal “teams” are established; an ad hoc team leader may be
I d e a s o r i n n o v a t i o n . The ability to encourage people to create and feel appointed; coordination among teams is the responsibility of a software
creative even when they must work within bounds established for a par- manager;
ticular software product or application. 3. individuals are organized into teams; each team is assigned one or more
functional tasks; each team has a specific structure that is defined for all
Weinberg that successful project apply a problem solving man- teams working on a project; coordination is controlled by both the team and
agement style. That is, a software project manager should concentrate on a software project manager.
PART TWO. MANAGING SOFTWARE PROJECTS MANAGEMENT 63
Although it is possible to voice pro and con arguments for each of the above ap-
proaches, there is a growing body of evidence that indicates that a formal
organization (option is most productive. I CT ON
The “best” depends on an organi-
zation, the number of people who will populate the team and their skill levels,
and the overall problem difficulty. Mantei suggests three generic
team organizations: type: DD CD cc
Democratic decentralized This software engineering team has Difficulty
high
no permanent leader. Rather, “task coordinators are appointed for short du-
rations and then replaced by others who may coordinate different tasks.” low
Decisions on problems and approach are made by group consensus. Size
large
Communication among team members is horizontal.
C o n t r o l l e d d e c e n t r a l i z e d ( C D ) . This software engineering team has lifetime
a defined leader who coordinates specific tasks and secondary leaders short
that have responsibility for subtasks. Problem solving remains a group long
activity, but implementation of solutions is partitioned among subgroups
by the team leader. Communication among subgroups and individuals high
is horizontal. Vertical communication along the control hierarchy also low
occurs. Reliability
Controlled Centralized(CC). Top-level problem solving and internal high
team coordination are managed by a team between
the leader and team members is vertical. Delivery date
strict
Mantei also describes seven project factors that should be considered when lox
planning the structure of software engineering teams: Sociability
high
!" the of the problem to be solved
!" the size of the resultant program(s) in lines of code or function points
!" the time the team will stay together (team lifetime)
!" the degree to which the problem can be modularized
The length of time the team will “live together” affects team morale. It has
!"the required quality and reliability of the system to be built been found that DD team structures result in high morale and iob satisfaction
!" the rigidity delivery date and are therefore good for long lifetime teams.
The DD team structure is best applied to problems with relatively low mod-
!" the degree of sociability (communication) required for the project
ularity because of the higher volume of communication that is needed. When
high modularity is possible (and people can do their own thing), the CC or CD
Table 3.1 [MAN811 summarizes the impact of project characteristics on structure will work well.
team organization. Because a centralized structure completes tasks faster, it is CC and CD teams have been found to produce fewer defects than DD
the most adept at handling simple problems. Decentralized teams generate teams, but these data have much to do with the specific quality assurance ac-
more and better solutions than individuals. Therefore such teams have a greater tivities that are applied by the team. Decentralized teams generally require
probability of success when working on difficult problems. Since the CD team more time to complete a project than a centralized structure and at the same
is centralized for problem solving, either the CD or the CC team structure can time are best when high sociability is required.
be successfully applied to simple problems. A DD structure is best for Constantine [CON931 suggests four “organizational paradigms” for soft-
problems. ware engineering teams:
Because the performance of a team is inversely to the amount
of communication that must be conducted, very large projects are best ad-
1. A closed paradigm structures a team along a traditional hierarchy of au-
dressed by teams with a CC or CD structure when subgrouping can be easily
thority (similar to a CC team). Such teams can work well when producing
accommodated.
64 PART MANAGING SOFTWARE PROJECTS CHAPTER 3: PROJECT MANAGEMENT CONCEPTS 65
software that is quite similar to past efforts, but they will be less to aged in the traditional way, and they certainly don’t need to be motivated.
be innovative when working within the closed paradigm. They’ve got momentum.
2. The random paradigm structures a team loosely and depends on individ-
ual initiative of the team members. When innovation or technological break- and Lister contend that members of jelled teams are significantly
through is required, teams following the random paradigm will excel. But more productive and more motivated than average. They share a common goal,
such teams may struggle when “orderly performance” is required. a common culture, and in many cases, a “sense of eliteness” that makes them
3. The open paradigm attempts to structure a team in a manner that achieves unique.
some of the controls associated with the closed paradigm but also much of
the innovation that occurs when using the rnndom paradigm. Work is per-
formed collaboratively with heavy communication and consensus-based de-
cision making. Open paradigm team structures are well suited to the solu- Coordination and Communication Issues
tion of complex problems, but may not perform as efficiently as other teams.
4. The synchronous paradigm relies on the natural compartmentalization of There are many reasons that software projects get into trouble. The scale of
a problem and organizes team members to work on pieces of the problem many development efforts is large, leading to complexity, confusion, and signif-
with little active communication among themselves. icant difficulties in coordinating team members. Uncertainty is common, re-
sulting in a continuing stream of changes that ratchets the project team.
has become a key characteristic of many systems. New soft-
As an historical footnote, earliest software team organization was a
ware must with existing software and conform to con-
controlled centralized (CD) structure originally called the chief programmer straints imposed by the system or product.
team. This structure was first proposed by Harlan Mills and described by Baker These characteristics of modern software-scale, uncertainty, and
The nucleus of the team is composed of a senior engineer (“the chief
erability-are facts of life. To deal with them effectively, a software engineer-
programmer”) who plans, coordinates, and reviews all technical activities of the \\ ing team must establish effective methods for coordinating the people who do
team; technical two to five people) who conduct analysis and de-
the work. To accomplish this, mechanisms for formal and informal communi-
velopment activities, and a backup engineer supports the senior engineer cation among team members and between multiple teams must be established.
in his or her activities and can replace the senior engineer with minimum loss Formal communication is accomplished through “writing, structured meetings,
in project continuity. and other relatively non-interactive and impersonal communication channels”
The chief programmer may be served by one or more specialists (e.g., Informal communication is more personal. Members of a software en-
telecommunications expert, database designer), support staff (e.g., technical
gineering team share ideas on an ad hoc basis, ask for help as problems arise,
writers, clerical personnel) and a librarian. The librarian serves many
and interact with one another daily.
teams and performs the following functions: maintains and controls all ele- and Streeter examine a collection of project coordination
ments of the software configuration (i.e., documentation, listings. data, thnt in following manner:
magnetic media); helps collect and format software productivity data; catalogs
and indexes reusable software modules; and assists the teams in research, eval-
uation, and document preparation. The importance of a librarian cannot be F o r m a l , i m p e r s o n a l a p p r o a c h e s . Include software engineering docu-
overemphasized. The librarian a controller, coordinator, and potentially, ments and deliverables (e.g. source code), technical memos, project mile-
an evaluator of the software configuration. stones, schedules and project control tools (Chapter changes requests
Regardless of team organization, the objective for every project manager is and related documentation (Chapter error tracking reports, and repos-
to help create a team that exhibits cohesiveness. In their book, Peopleware, itory data (see Chapter 29).
and Lister discuss this issue: F o r m a l , i n t e r p e r s o n a l p r o c e d u r e s . Focus on quality assurance activi-
ties (Chapter applied to software engineering work products. These in-
-‘-&de review meetings and design and code inspections.
We tend to use the word team fairly loosely in the business world, calling any
group of people assigned to work together a “team.” But many of these groups Informal, interpersonal procedures. Include group meetings for in-
just don’t seem like teams. They don’t have a common definition of success or formation dissemination and problem solving and “collocation of require-
any identifiable team spirit. What is missing is a phenomenon that we call ments and development staff.”
Electronic c o m m u n i c a t i o n . Encompasses electronic mail, electronic
A jelled team is a group of people so strongly knit that the whole is greater bulletin hoards, Web sites, and by extension, video-based conferencing
than the sum of the parts. systems.
Once a team begins to jell, the probability of success goes way up. The team Interpersonal network.Informal discussions with those outside the
can become unstoppable, a juggernaut for success.. They don’t need to be project who may have experience or insight that can assist team members.
PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 3. PROJECT MANAGEMENT CONCEPTS 67
To assess the efficacy of these techniques for project coordination, Kraul and
Streeter studied 65 software projects involving hundreds of technical staff. 6
Figure 3.1 (adapted from expresses the value and use of the coor-
discussion with peers A
dination techniques noted above. In the figure the perceived value (rated on t
a seven-point scale) of various coordination and communication techniques is
plotted against their frequency of use on a project. Techniques that fall above . documents
the regression were “judged to be relatively valuable, given the amount #" project milestones
that they were used” Techniques that fall below the line were per- error tracking reports
5 design reviews !
ceived to have less value. It is interesting to note that interpersonal net-
working (discussion with peers) was rated the technique with highest coordi-
nation and communication value. It is also important to note that early electronic mail
software quality assurance mechanisms (requirements and design reviews)
were perceived to have more value than later evaluations of code (code
inspections).
3.3 THE PROBLEM
#" source code
A software project manager is confronted with a dilemma at the very begin- repository data
ning of a software engineering project. Quantitative estimates and an orga- #" formal, impersonal approaches
nized plan are required, but solid information is unavailable. A detailed analy- !"formal interpersonal procedures
sis of software requirements would provide necessary information for
#" project control tools $" informal interpersonal procedures
estimates, but analysis often takes weeks or months to complete. Worse, re-
quirements may be fluid, changing regularly as the project proceeds. Yet, a electronic communication
FIGURE 3.1.
plan is needed “now!” A interpersonal network I
Value and use of
Therefore, we must examine the problem at the very beginning of the proj- coordination and
ect. At a minimum, the scope of the problem must be established and bounded. communication 2 I I I
techniques 2 3 4 5 6
Use of coordination technique
3.3.1 software scope
list, maximum allowable response time) are stated explicitly; constraints and/or
The first software project management activity is the determination of software limitations (e.g., product cost restricts memory size) are noted, and mitigating
scope. Scope is defined by answering the following questions: factors (e.g., desired algorithms are well understood and available in C+ + are
described.
C o n t e x t . How does the software to be built into a larger system, prod-
uct, or business context, and what constraints are imposed as a result of
the context?
3.3.2 Problem Decomposition
Information objectives.What customer-visible data objects (Chapter
11) are produced as output from the software? What data objects are re-
quired for input? Problem decomposition, sometimes called partitioning, is an activity that sits
at the core of software requirements analysis (Chapter During the scoping
F u n c t i o n a n d p e r f o r m a n c e . What function does the software perform
activity there is no attempt to fully decompose the problem. Rather, decompo-
to transform input data into output? Are any special performance charac- sition is applied in two major areas: the functionality that must be deliv-
teristics to be addressed?
ered and the process that will be used to deliver it.
Human beings tend to apply a divide and conquer strategy when they are
Software project scope must be unambiguous and understandable at manage- confronted with a complex problem. Stated simply, a complex problem is parti-
ment and technical levels. A statement of software scope must be bounded. tioned into smaller problems that are more manageable. This is the strategy
That is, quantitative data (e.g., number of simultaneous users, size of mailing that is applied as project planning begins. Software functions, described in the
PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 3: PROJECT MANAGEMENT CONCEPTS 69
statement of scope, are evaluated and to provide more detail prior to The project manager must decide which process model is most appropriate for
the beginning of estimation (Chapter Because both cost and schedule esti- the project, then define a preliminary plan based on the set of common process
mates are functionally oriented, some degree of decomposition framework activities. Once the preliminary plan is established, process de-
As an example, consider a project build a new word processing composition begins. That is, a complete plan reflecting the work tasks required
product. Among the unique features of the product are continuous voice as well to populate the framework activities must be created. We explore these activ-
as keyboard input; extremely sophisticated “automatic copy edit” features; page ities briefly in the sections that follow and present a more detailed view in
layout capability; automatic indexing and table of contents; and others. The Chapter 7.
project manager must establish a statement of scope that bounds these
features (as well as other more mundane functions such as editing, file man-
agement, document production, and the like). For example, will continuous
voice input require that the product be “trained” by the user? Specifically what 3.4.1 Melding the Problem and the Process
capabilities will the copy edit feature provide? Just how sophisticated will the
page layout capability be? Project planning begins with the melding of the problem and the process. Each
As the statement of scope evolves, a first level of partitioning naturally oc- function to be engineered by the software team must pass through the set of
curs. The project team learns that-the marketing department has talked with framework activities that have been defined for a software organization. Assume
potential customers and found that the following functions should be part of that the has adopted the following set of framework activities
automatic copy editing: (Chapter
!"spell checking !" customer communication--tasks required to establish effective communica-
!"sentence grammar checking tion between developer and customer
!" reference checking for large documents (e.g., is a reference to a bibliography !" required to define resources, timelines, and other project re-
entry found in the list of entries in the bibliography?) lated information
!" section and chapter reference validation for large documents !" risk analysis-tasks required to assess both technical and management risks
!" engineering-tasks required to build one or more representations of the ap-
Each of these features represents a subfunction be implemented in software. plication
Each in turn can be further refined if the decomposition will make planning
!" construction and release-tasks required to construct, test, install, and pro-
easier.
vide user support (e.g., documentation and training)
!" required to obtain customer feedback based on
3.4 evaluation of the software representations created during the engineering
THE PROCESS
stage and implemented during the installation stage
The generic phases that characterize the software process-definition, devel- The team members who work on each function will apply each of the frame-
opment, and maintenance--are applicable to all software. The problem is to se- work activities to it. In essence, a matrix similar to the one shown in Figure
lect the process model that is appropriate for the software to be engineered by 3.2 is created. Each major problem function (the figure notes functions for the
a project team. In Chapter 2, a wide array of software engineering paradigms word-processing software discussed earlier) is listed in the left hand column.
were discussed: are in the top row. Software engineering work tasks
(for each framework activity) would be entered in the following The job
!" the linear sequential model of the project manager (and other team members) is to estimate resource re-
!" the prototyping model quirements for each matrix cell, start and end dates for the tasks associated
!" the RAD model with each cell, and work products to be produced as a consequence of each cell.
These issues are considered in Chapters 5 and 7.
!" the incremental
!" the spiral model
!" the component assembly model
‘It should he noted that work tasks must he adapted to the specific needs of a project.
!"the concurrent development model
activities always the hut work tasks will be selected based on
!" the formal methods model number of adaptationcriteria. For a detailed discussion, see Chapter 7.
!" the fourth generation techniques model
70 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 3: PROJECT MANAGEMENT CONCEPTS 71
Once the process model has been chosen, the common process framework
is adapted to it. In every case, the CPF discussed earlier in this chap-
ter-customer communication, planning, risk analysis, engineering, construc-
COMMON PROCESS tion and release, customer evaluation-can be fitted to the paradigm. It will
ACTMTIES work for linear models, for iterative and incremental models, for evolution mod-
els, and even for concurrent or component assembly models. The CPF is in-
\ variant and serves as the basis for all software work performed by a software
organization.
But actual work tasks do vary. Process decomposition commences when the
project manager asks: “How do we accomplish this CPF activity?” For example,
a small, relatively simple project might require the following work for the
customer communication activity:
1. Develop list of clarification issues.
2. Meet with customer to address clarification issues.
3. Jointly develop a statement of scope.
4. Review the state of scope with all concerned.
5. Modify the statement of scope as required.
These events might occur over a period of less than 48 hours. They represent a
process decomposition that is appropriate for the small, relatively simple project.
Now, we consider a more complex project that has a broader scope and
more significant business impact. Such a project might require the following
work tasks for the customer communication activity:
1. Review the customer request.
2. Plan and schedule a formal, facilitated meeting with the customer.
FIGURE 3.2. Melding the problem and the process.
3. Conduct research to define proposed solutions and existing approaches.
4. Prepare a “working document” and an agenda for the formal meeting.
5. Conduct the meeting.
3.4.2 Process Decomposition
6. Jointly develop mini-specs that reflect data, function, and behavioral fea-
tures of the software.
A software team should have a significant degree of flexibility in choosing the 7 . Review each mini-spec for correctness, consistency, and lack of ambiguity,
software engineering paradigm that is best for the project and the software en-
gineering tasks that populate the process model once it is chosen. A relatively 8 . Assemble the mini-specs into a scoping document.
small project that is similar to past efforts might be best accomplished using 9 . Review the scoping document with all concerned.
the linear sequential approach. If very tight time constraints are imposed and 10. Modify the scoping document as required.
the problem can be heavily compartmentalized, the RAD model is probably the
right option. If the deadline is so tight that full functionality cannot reasonably Both projects perform the framework activity that we call customer communi-
be delivered, an incremental strategy might be best. Similarly, projects with cation, but the first project team performs half as many engineering
other characteristics (e.g., uncertain requirements, breakthrough technology, work tasks as the second.
difficult customers, significant reuse potential) will lead to the selection of
other process
3.5 THE PROJECT
that project characteristics also have strong bearing on the structure of the team Jaded industry professionals refer to the rule when discussing par-
that is to do the work. See Section 3.2.3. ticularly software projects: The percent of a system absorbs 90
72 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 3: PROJECT MANAGEMENT CONCEPTS 73
percent of allotted effort and time. The last 10 percent takes the other 90 per- Constantine, L., “Work Organization: Paradigms for Project Management
cent allotted and time This statement tells us much about and Organization, vol. 36, no. 10, October 1993, pp. 34-43.
the state of a project that gets into trouble: Cougar, J., and R. Zawacki, Managing and Motivating Computer
Personnel, Wiley, 1980.
!" The manner in which progress is assessed is flawed. (Obviously, if the 90-90 Curtis, B. et al., “A Field Study of the Design Process for Large
rule is true, 90 percent complete is not an accurate indicator!) Systems,” Software Engineering, vol. 31, no. 11, November
1988, pp. 1268-1287.
!" There is no way to calibrate progress because quantitative metrics are un-
[CUR941 Curtis, B., et al., People Management Capability Maturity Model,
available.
Software Engineering Institute, Pittsburgh, PA, 1994.
!" The project plan has not been designed to accommodate resources required T., and ‘I! Peopleware, Dorset House, 1987.
at the end of a project. Edgemon, J., “Right Stuff How to Recognize It When Selecting a Project
!" Risks have not been considered explicitly, and a plan for mitigating, moni- Manager,” Application Development Trends, vol. 2, no. 5, May 1995, pp.
toring, and managing them has not been created.
Kraul, R., and L. Streeter, “Coordination in Software Development,
!" The schedule is unrealistic or flawed.
CACM, vol. 38, no. 3, pp. 69-81.
Mantei, M., “The Effect of Programming Team Structures on
To overcome these problems, time must be spent at the beginning of a project
Programming Tasks,” CACM, vol. 24. no. 3, March 1981, pp.
to establish a realistic plan, during the project to monitor the plan, and through-
Page-Jones, M., Practical Project Management, Dorset House, 1986, vii.
out the project to control quality and change. The activities that absorb this
Weinberg, G., On Becoming a Technical Leader, Dorset House, 1986.
time are discussed in detail in the chapters that follow. Whitaker, K., Managing Software Maniacs, Wiley, 1994.
R., “Timeboxing for Top Team Performance,” Software
Development, March 1994, pp. 35-38.
3.6 SUMMARY
Software project management is an umbrella activity within software engi- PROBLEMS AND POINTS TO PONDER
neering. It begins before any technical activity is initiated and continues through-
out the definition, development, and maintenance of computer software
Three P’s have a substantial influence on software project 3.i. Based on information contained in this chapter and your own experience, de-
people, problem, and process. People must be organized into effective teams, mo- velop a ‘ten commandments” for empowering software engineers. That is,
make a list of 10 guidelines that will lead to people who work to their
tivated to do high-quality software work, and coordinated to achieve effective
communication. The problem must be communicated from customer to developer, full potential.
partitioned (decomposed) into its constituent parts, and positioned for work by 3.2. Software Engineering Institute’s People Management Capability Maturity
the software team. The process must be adapted to the people and the problem. Model takes an organized look at “key practice areas” that culti-
A common process framework is selected, an appropriate software engineering vate good software people. Your instructor will assign you one KPA for analy-
paradigm is applied, and a set of work tasks is chosen to get the job done. sis and summary.
The pivotal element in all software projects is people. Software engineers 3.3. Describe three real-life situations in which the customer and the end user are
can be organized in a number of different team structures that range from tra- one and the same. Describe three situations in which they different people.
ditional control hierarchies to “open paradigm” teams. A variety of coordination 3.4. The decisions made by senior management can have a significant impact on
and communication techniques can be applied to support the work of the team. the effectiveness of a software engineering team. Provide examples to il-
In general, formal reviews and informal communication have lustrate that this is true.
the most value for practitioners. 3.6. Review a copy of Weinberg’s book and write a two- or three-page
The project management activity encompasses measurement and metrics, summary of the issues that should be considered in applying the model.
estimation, risk analysis, schedules, tracking, and control. Each of these topics
3.6. You have been appointed a project manager within an information systems
is considered in the chapters that follow.
organization. Your job is to build an application that is quite similar to oth-
ers that your team has built, although this one is larger and more complex.
Requirements have been thoroughly documented by the customer. What team
REFERENCES structure would you choose and why? What software process would
you choose and why?
Baker, “Chief Programmer Team Management of Production 3.7. You have been appointed a project manager for a small software products
Programming,” Systems Journal. vol. 11, no. 1, 1972, pp. 5673. company. Your job is to build a breakthrough product that combines virtual
PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 3: PROJECT MANAGEMENT CONCEPTS
reality hardware with state-of-the art software. Because competition for the and and Weinberg the Professional
home entertainment market is intense, there is significant pressure to get the Programmer, Dorset House, provide useful insight into software people
job done. What team structure would you choose and why? What software. and the way in which they should be managed.
process would you choose and why? Pragmatic guidance on project management is presented by Wysocki et al.
3.6. You have been appointed a project manager for a major software products Project Management, Wiley, 19961, and Boddie (Managing a
company Your job is to manage the development of the next generation ver- Programming Project: Processes and People, 3rd edition, Prentice-Hall,
sion of its widely used word-processing software. Because competition is in- and O’Connell (How To Run Successful Projects, Prentice-Hall, 1994). Still an-
tense, tight deadlines have been established and announced. What team other take on project management in the software world is provided by
structure would you choose and why? What software process model(s) would Constantine (Constantine on Peopleware, Prentice-Hall, 1995). McCarthy
you choose and why? (Dynamics of Software Development, Microsoft Press, 1995) has written an
amusing and insightful book of rules for shipping “great software” on schedule.
3.9. You have been appointed a software project manager for a company that ser-
vices the genetic engineering world. Your job is to manage the development An excellent project management resource, containing useful information
and copious references to books, tools, and training can be found at:
of a new software product that will accelerate the pace of gene typing. The
work is R&D orionted, but the goal is to produce a product within the next
year. What team structure would you choose and why? What software process
would you choose and why?
3.10. on the of the study referred to in 3.1, documents are per-
ceived to have more use than value. Why do you think this occurred and what Project is a European research and development program in
can be done to move the “documents” data point above the regression line in the project management. A wide variety of useful information and pointers can be
graph? That is, what can be done to improve the perceived value of documents? obtained at:
3.11. You have been asked to develop a small application that analyzes each course
offered by a university and reports the average grade obtained in the course
(for a given term). Write a statement of scope that bounds this problem.
3.12. Do a first-level functional decomposition of the page layout function discussed The Project Management Institute’ Web site contains useful information on
briefly in Section 3.3.2. project management education programs, publications, special interest groups,
and tools:
FURTHER READINGS AND OTHER INFORMATION SOURCES
An up-to-date list of World Wide Web references for software project manage-
An excellent three volume series written by Weinberg (Quality Software ment can be found at
Management, Dorset House, 1992, 1993, 1994) introduces basic of systems
thinking and management concepts, explains how to use measurements effec-
tively, and addresses “congruent action,” the ability to establish “fit” between
the manager’s needs, the needs of technical staff, and the needs of the business.
It will new and experienced managers with useful information.
Brooks Mythical Man-Month, Anniversary Edition, Addison-Wesley, 1996)
has updated his classic book to provide new insight into project and
management issues. Purba and Shah (How to Manage a Successful Software
Project, Wiley, present a number of case studies that indicate why some
projects succeed and others fail. Bennatan (Software Project Management in a
Client/Server Environment, Wiley, 1995) discusses special management issues
associated with the development of client/server systems.
Another excellent book by Weinberg is must reading for every
project manager and every team leader. It will give you insight and guidance
in ways to do your job more effectively. House (The Human Side of Project
Management, Addison-Wesley, 1988) and Crosby Things: The Art of
Making Things Happen, McGraw-Hill, 1989) provide practical advice for man-
agers who must deal with human as well as technical problems. Books by
CHAPTER 4: SOFTWARE PROCESS AND PROJECT METRICS 77
In this chapter we consider software metrics that are used at the
and project level. In later chapters, we present metrics that are applied by soft-
ware engineers in a technical setting.
SOFTWARE PROCESS AND 4.1 MEASURES, METRICS, AND INDICATORS
Although the terms “measure, ““measurement,” and “metrics” are often used in-
PROJECT METRICS
terchangeably, it is important to note the subtle differences between them.
Because “measure” and “measurement” can be used either as a noun or a verb,
definitions of the terms can become confusing. Within the software engineering
context, a measure provides a quantitative indication of the extent, amount, di-
mensions, capacity, or size of some attribute of a product or process.
is the act of determining a measure. The IEEE Standard Glossary of Software
Engineering defines metric as “a quantitative measure of the de-
gree to which a system, component, or process possesses a given attribute.”
When a single data point has been collected (e.g., the number of errors un-
covered in the review of a single module), a measure has been established.
Measurement occurs as the result of the collection of one or more data points (e.g.,
a number of module reviews are investigated to collect measures of the number
of errors found during each review). A software metric relates the individual mea-
sures in some way (e.g., the average number of errors found per review or the av-
erage number of errors found per person-hour expended on
easurement is fundamental to any engineering discipline, and software A software engineer collects measures and develops metrics so that indi-
engineering is no exception. Lord Kelvin once said: cators will be obtained. An indicator is a metric or combination of metrics that
provide insight into the software process, a software project, or the product it-
When you can measure what you are speaking about and express it in num- self An indicator provides insight that enables the project manager
bers, you know something about it; but when you cannot measure, when you or software engineers to adjust the process, the project, or the product to make
cannot express it in numbers, your knowledge is of a meager and unsatisfac- things better.
tory kind: it may be the beginning of knowledge, but you have scarcely, in your For example, four software teams are working on a large software project.
Each reviews, hat is allowed to select the type of re-
view that it will use. Upon examination of the metric, errors per
Over the past decade, the community has hour project manager notices that the two teams using more for-
to take Lord Kelvin’s words to heart. But not without frustration and more mal review methods exhibit an errors found per person-hour expended that is
than a little controversy! 40 percent higher than the other teams. Assuming all other parameters equal,
metrics refers to a broad range of measurements computer this provides the project manager with an indicator that formal review meth-
software. Measurement can be applied to software process with the intent ods may provide a higher return on time investment that other review ap-
of improving it on a continuous basis. Measurement can be used throughout a proaches, She may decide to suggest that all teams use the more formal ap-
software project to assist in estimation, quality control, productivity assess- proach. The metric provides the manager with insight. And insight leads to
ment, and project control. Finally, measurement can be used by software engi- informed decision making.
neers to help assess the quality of technical work products and to assist in tac-
tical decision making as a project proceeds.
Within the context of software project management, we are concerned pri- 4.2 METRICS IN THE PROCESS AND PROJECT DOMAINS
marily with productivity and quality metrics-measures of software develop-
ment “output” as a function of effort and time applied and measures of the “fit- Measurement is commonplace in the engineering world. We measure power
ness for use” of the work products that are produced. For planning and
consumption, weight, physical dimensions, temperature, voltage,
estimating purposes, our interest is historical. What was software development
productivity on past projects? What was the quality of the software that was
produced? How can past productivity and quality data be extrapolated to the
present? How can the past help us plan and estimate more accurately? ‘This assumes that another measure, person-hours expended, is collected for each review
76
78 PART TWO. MANAGING SOFTWARE PROJECTS CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 79
noise ratio . the list is almost endless. Unfortunately, measurement is far less Product
common in the software engineering world. We have trouble agreeing on what
to measure and trouble evaluating metrics that are collected.
Metrics should be collected so that process and product indicators can be
ascertained. Process indicators enable a software engineering organization to
gain insight into the efficacy of an existing process (i.e., the paradigm, software
Customer
engineering tasks, work products, and milestones). They enable managers and
practitioners to assess what works and what doesn’t. Process metrics are col- Characteristics
lected across all and over long periods of time. Their intent is to pro-
vide indicators that lead to long-term software process improvement.
Project indicators enable a software project manager to (1) assess the sta-
tus of an ongoing project; track potential risks; (3) uncover problem areas
before they “go critical”; adjust work flow or tasks; and (5) evaluate the proj- FIGURE 4.1.
ect team’s ability to control quality of software engineering work products. Determinants for
In some cases, the same software metrics can be used to determine both proj- software quality
ect and then process indicators. In fact, measures that are collected by a project and organizational
team and converted metrics for use during a project can also be transmit effectiveness
ted to those with responsibility for software process improvement. For this rea- (adapted from
son, many of the same metrics are used in both the process and project domain.
..
Grady argues that there are “private and uses for differ-
4.2.1 Metrics and Process Improvement ent types of process data. Because it is natural that individual
might be sensitive to the use of metrics collected on an individual basis,
these data should be private to the individual and serve as an indicator for the
The only rational way to improve any process is to measure specific attributes
individual only. Examples of metrics that are private to the individual include:
of the process, develop a set of meaningful metrics based on these attributes,
and then use metrics to provide indicators that will lead to a strategy for
improvement. But before we discuss software metrics and their impact on soft- !"defect rates (by individual)
ware process improvement, it is important to note that process is only one of a !"defect rates (by module)
number of “controllable factors in improving software quality and organiza- !" errors found during development
tional performance”
Figure 4.1, process sits at the center of a triangle connecting three fac-
The “private process data” philosophy conforms well with the personal software
tors that have a profound influence on software quality and organizational per- process approach proposed by Humphrey Humphrey describes the
formance. The skill and motivation of people has been shown to be the
approach in the following manner:
single most influential factor in quality and performance. The complexity of the
product can have a substantial impact on quality and team performance. The
technology (i.e., the software engineering methods) that populates the process The personal software process is a structured set of process descriptions,
also has an impact. In addition, the process triangle exists within a circle of en- measurements, and methods that can help engineers to improve their personal
vironmental conditions that include the development environment (e.g., CASE performance. It provides the forms, scripts, and standards that help them esti-
tools), business conditions (e.g., deadlines, business rules), and customer char- mate and plan their work. It shows them how to define processes and how to
acteristics (e.g., ease of communication). measure their quality and productivity. A fundamental PSP principle is that
We measure the efficacy of a process indirectly. That is, we derive everyone is different and that a method that is effective for one engineer may
a set of metrics based on the outcomes that can be derived from the process. not be suitable for another. Tbe PSP thus helps engineers to measure and track
Outcomes include measures of errors uncovered before release of the software, their own work so they can find the methods that are best for them.
defects delivered to and reported by end users, work products delivered, human
effort expended, calendar time expended, schedule conformance, and other Humphrey recognizes that software process improvement can and should be-
measures. We also derive process metrics by measuring the characteristics of gin at the individual level. Private process data can serve as an important dri-
specific software engineering tasks. For example, we might measure the effort ver as the individual software engineer works to improve.
an&time spent performing the umbrella activities and the generic software en- Some process metrics are private to the software project team but public
gineering activities described in Chapter 2. to all team members, Examples include defects reported for major software
81
PART MANAGING SOFTWARE PROJECTS CHAPTER 4: SOFTWARE PROCESS AND PROJECT METRICS
functions (that have been developed by a number of practitioners), errors found 4. The overall cost of errors and defects in each category is computed.
during formal technical reviews, and lines of code or function points per mod- 5. Resultant data are analyzed to uncover the categories that result in high-
ule and These data are reviewed by the team to uncover indicators est cost to the organization.
that can improve team performance.
6. Plans are developed to modify the process with the intent of eliminating (or
Public metrics generally assimilate information that originally was private
reducing the frequency of occurrence of) the class of errors and defects that
to individuals and teams. Project-level defect rates (absolutely not attributed to
is most costly.
an individual), effort, calendar times, and related data are collected and eval-
uated in an attempt to uncover indicators that can improve organizational
process performance. Following steps 1 and 2 above, a simple defect distribution can be devel-
Software process metrics can provide significant benefit as an organization oped (Figure 4.2) For the pie chart noted in the figure, eight causes
works to improve its overall level of process maturity. However, like all metrics, of defects and their origin (indicated by shading) are shown. Grady suggests
these can be misused, creating more problems than they solve. Grady the development of a diagram to help in diagnosing the data
suggests a “software metrics etiquette” that is appropriate for managers as represented in the frequency diagram. In Figure 4.3 the spine of the diagram
they institute a process metrics program: (the central line) represents the quality factor that is under consideration (in
this case specification defects that account for 25 percent of the total). Each of
the ribs (diagonal lines) connected to the spine indicates a potential cause for
!"Use common sense and organizational sensitivity when interpreting metrics
the quality problem (e.g., missing requirements, ambiguous specification, in-
data.
correct requirements, changed requirements). The spine and ribs notation is
!" Provide regular feedback to the individuals and teams who have worked to then added to each of the major ribs of the diagram to expand upon the cause
collect measures and metrics. noted. Expansion is shown only for the “incorrect” cause in Figure 4.3.
!" Don’t use metrics to appraise individuals.
. Work with practitioners and teams to set clear goals and metrics that will be
used to achieve them.
!" Never use metrics to threaten or teams. 20%
!" Metrics thnt indicate a should not
tive.” These data are merely an indicator for process improvement. Data handling
!" Don’t obsess on a single metric to the exclusion of other important met-
rics.
As an organization becomes more comfortable with the collection and use Standards
of process metrics, the derivation of simple indicators gives way to a more rig- 6.9%
orous approach called statistical software In
essence, SSPI uses software failure analysis to collect information about all er-
3
rors and defects encountered as an application, system, or product is devel-
oped and used. Failure analysis works in manner:
1. All errors and defects are by origin (e.g., flaw in specification,
flaw in logic, nonconformance to standards).
Specifications
2. The cost to correct each error and defect is recorded.
25.6%
3. The number of errors and defects in each category are counted and ordered
in descending order.
Origin of errors/defects
FIGURE 4.2.
Causes of defects
%" specification/requirements
“See Sections 4.3.1 and for detailed discussions of LOC and function point metrics.
and their origin design
we discuss in Chapter 8, an error is some flaw in software engineering work product or
deliverable that is uncovered by software before the end for four software code
A is flaw that is uncovered delivery the end user. projects
PART IWO. MANAGING SOFTWARE PROJECTS CHAPTER 4. SOFTWARE PROCESS AND PROJECT METRICS 83
Missing Ambiguous collected to assess design quality and to provide indicators that will influence
the approach taken to code generation and module and integration testing.
The intent of project metrics is twofold. First, these metrics are used to
minimize the development schedule by guiding the adjustments necessary to
avoid delays and mitigate potential problems and risks. Second, project metrics
are used to assess product quality on an ongoing basis and when necessary,
modify the technical approach to improve quality.
As quality improves, errors are minimized, as errors count
down, the amount of rework required during the project is also reduced. This
leads to a reduction in overall project cost.
Specification Another model of software project metrics suggests that every
project should measure:
wrong customer
!" inputs-measures of the resources (e.g., people, environment) required to do
the work,
!" outputs-measures of the deliverables or work products created during the
software engineering process,
4.3. A inadequate inquiries !" results-measures that indicate the effectiveness of the deliverables
diagram
showing the outdated In actuality, this model can be applied to both process and project. In the proj-
causes of one class
of defects [adapted ect context, the model can be applied recursively as each framework activity
from occurs. Therefore the outputs from one activity become inputs to the next.
Changes
Results metrics can be used to provide an indication of the usefulness of work
products as they flow from one framework activity (or task) to the next.
The collection of process metrics is the driver for the creation of the
bone diagram. A completed diagram can be analyzed to derive indica-
tors that will enable a software organization to modify its process to reduce the 4.3 SOFTWARE MEASUREMENT
frequency of errors and defects.
Measurements in the physical world can be categorized in two ways: direct
(e.g., the length of a bolt) and indirect measures (e.g., the “quality” of
bolts produced, measured by counting rejects). Software metrics can be catego-
4.2.2 Project Metrics
rized similarly.
Direct measures of the software engineering process include cost and effort
Software process metrics are used for strategic purposes. Software project mea- applied. Direct measures of the product include lines of code produced,
sures are tactical. That is, project metrics and the indicators derived from them execution speed, memory size, and defects reported over some set period of
are used by a project manager and a team to adapt project work flow time. Indirect measures of the product include functionality, quality, complex-
and technical activities. ity, efficiency, reliability, maintainability, and many other “abilities” that are
The first application of project metrics on most software projects occurs discussed in Chapter 18.
during estimation (Chapter Metrics collected from past projects are used as We have already partitioned the software metrics domain into process, proj-
a basis from which effort and time duration estimates are made for current ect, and product metrics. We have also noted that product metrics that are pri-
software work. As a project proceeds, measures of effort and calendar time ex- vate to an individual are often combined to develop project metrics that are
pended are compared to original estimates (and the project schedule). The proj- public to a software team. Project metrics are then consolidated to create
ect manager uses these data to monitor and control progress. process metrics that are public to the software organization as a whole. But
As technical work commences, other project metrics begin to have signifi- how does an organization combine metrics that come from different individu-
cance. Production rates represented in terms of pages of documentation, review als or projects?
hours, function points, and delivered source lines are measured. In addition, er- To illustrate, we consider a simple example. Individuals on two different
rors uncovered during each software engineering task are tracked. As the soft- project teams record and categorize all errors that they find during the soft-
ware evolves from specification into design, technical metrics (Chapter 18) are ware engineering process. Individual measures are then combined develop
PART TWO: MANAGING SOFTWARE PROJECTS 8 5
CHAPTER SOFTWARE PROCESS AND PROJECT METRICS
team measures. Team A found 342 errors during the software engineering the rudimentary data contained in the table, a set of simple size-oriented met-
process prior to release. Team B found 184 errors. All other things being equal, rics can be developed for each project:
which team is more effective in uncovering errors throughout the process?
Because we do not know the size or complexity of the projects, we cannot an- !" errors per KLOC (thousand lines of code)
swer this question. However, if the measures are normalized, it is possible
defects per KLOC
to create software metrics that enable comparison to broader organizational !"
averages. !" $ per LOC
!" page8 of documentation per KLOC
4.3.1 Size-Oriented Metrics In addition, other interesting metrics can be computed:
Size-oriented software metrics are derived by normalizing quality and/or produc- !"errors/person-month
tivity measures by considering the “size” of the software that has been produced. !"LOC per person-month
If a software organization maintains simple records, a table of size-oriented !" $Ypage of documentation
measures, such as the one shown in Figure 4.4, can be created. The table lists
each software development project that has been completed few not the best way to
and to entry the process of software development Most of the controversy
(Figure 4.4) for project 12,100 of were developed with 24 swirls around the use of lines of code as a key measure. Proponents of
person-months of effort at a cost of $168,000. It should be noted that the effort the LOC measure claim that LOC is an “artifact” of all software development
and cost recorded in the table represent all software engineering activities (analy- projects and can be easily counted; that many existing software estimation
sis, design, coding, and testing), not just coding. Further information for project models use LOC or KLOC as a key input, and that a large body of literature
alpha indicates that 365 pages of documentation were developed, 134 errors were and data predicated on LOC already exists. On the other hand, opponents claim
recorded before the software was released, and 29 defect.8 were encountered alter that LOC measures are programming language dependent; that they penalize
release to the customer within the first year of operation. Three people worked on well-designed but shorter programs; that they cannot easily accommodate non-
the development of for project alpha. procedural languages, and that their use in estimation requires a level of de-
In order to develop metrics that can be assimilated with similar metrics tail that may be difficult to achieve (i.e., the planner must estimate the LOC
from other projects, we choose lines of code as our normalization value. From to be produced long before analysis and design have been completed).
Effort 4.3.2 Function-Oriented Metrics
12,100 24 I.68 365 134 29 Function-oriented software metrics use a measure of the functionality deliv-
27,200 62 440 321 86 ered by the application as a normalization value. Since “functionality” cannot
20,200 43 314 1050 256 be measured directly, it must be derived indirectly using other direct measures.
64
Function-oriented metrics were first proposed by Albrecht who sug-
! . . . gested a measure called the function point. Function points are derived using
an empirical on of
& . . .
domain of
& . . .
Function points are computed by completing the table shown in Figure 4.6.
Five information domain characteristics are determined, and counts are pro-
vided in the appropriate table location. Information domain values are defined
in the following
FIGURE 4.4.
Size-oriented ‘In actuality, the definition of information domain values and the manner in which they
metrics. counted bit more complex. The interested reader for details.
PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 4: SOFTWARE PROCESS AND PROJECT METRICS 87
Weighting Factor
measurement parameter count simple average complex
COMPUTING FUNCTION POINTS
of user inputs x 3 4 6
Rate each factor on a scale of 0 to 5:
number of user outputs X 4 5
0 1 2 3 A 5
number of user inquiries X 3 4 6
No
influence Incidental Average Significant Essential
number of files
X 10 15 =
1. Does the system require reliable backup and recovery?
of external interfaces I X 5 10 = 2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
count = total
I 5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
4.5. Computing function point metrics. 7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. the internal processing complex?
Number of user inputs. Each user input that provides distinct 11. Is the code designed to be reusable?
oriented data to the software is counted. Inputs should be distinguished 12. Are conversion and installation included in the design?
from inquiries, which are counted separately. 1 3 . Is the system designed for multiple installations in different organizations?
Number of outputs. Each user output that provides application-ori- 14. the application designed to facilitate change and ease of use by the user?
ented information to the user is counted. In this context output refers to
reports, screens, error messages, and so on. Individual data items within a
report are not counted separately.
and the weighting factors that are applied to information domain counts are
Number of user inquiries. An inquiry is defined as an on-line input that
determined empirically.
results in the generation of some immediate software response in the form Once function points have been calculated, they are used in a manner anal-
of an on-line output. Each distinct inquiry is counted.
ogous to LOC to normalize measures of software productivity, quality, and other
Number of files. Each logical master (i.e., a logical grouping of data attributes:
that may be one part of a large database or a separate file), is counted.
Number of external interfaces. All machine readable interfaces (e.g., data !" errors per FP
files on tape or disk) that are used to transmit information to another sys- !" defects per FP
tem are counted.
!" $ per FP
!" page of documentation per FP
Once the have been collected, a complexity value is associated
with each count. Organizations that use function point methods develop crite- !" FP per person-month
ria for determining whether a particular entry is simple, average, or complex.
Nonetheless, the determination of complexity is somewhat subjective.
To compute function points the following relationship is used:
4.3.3 Extended Function Point Metrics
FP = count-total X 10.65 + 0.01 X
where count-total is the sum of all entries obtained from Figure 4.5. The function point metric was originally designed to be applied to business in-
The = 1 to are “complexity adjustment values” based on responses formation systems applications. To accommodate these applications, the data di-
to questions [ART861 noted in Table 4.1. The constant values in the equation mension (the information domain values discussed above) was emphasized to the
PART TWO: MANAGING CHAPTER 4: SOFTWARE AND PROJECT METRICS a9
exclusion of the functional and behavioral (control) dimensions. For this reason,
the function point measure was inadequate for many engineering and embedded
systems (which emphasize function and control). A number of extensions to the
basic function point measure have been proposed to remedy this situation.
A function point extension called feature points is a of
the function point measure that can be applied to systems and engineering
software applications. The feature point measure accommodates applications in
which algorithmic complexity is high. Real-time, process control, and embedded
software application8 tend to have algorithmic complexity and are l-10 low low average
fore amenable to the point.
To compute the point, information domain values are again counted
and weighted as described in Section 4.3.2. In addition, the feature point met- 11-20 low average high
FIGURE 4.6.
ric counts a new software characteristic, algorithms. An algorithm is defined as Determining the
“a bounded computational problem that is included within a specific computer
complexity of a
program” Inverting a matrix, decoding a bit string, or handling an transformation for average high high
terrupt are all examples of algorithms.
3D function points
Another function point extension for real-time systems and engineered
products has been developed by Boeing. The Boeing approach integrates the
data dimension of software with the functional and control dimensions to pro-
vide a function oriented measure, called the Function Point that
lular phone contains software that supports auto dial functions. To enter the
is amenable to applications that emphasize function and control capabilities.
Characteristics of all three software dimensions are “counted, quantified, and auto-dial state from a resting state, the user presses an Auto key on the key
pad. This event causes an LCD display to prompt for a code that will indicate
transformed” into a measure that provides an indication of the functionality de-
the party to be called. Upon entry of the code and touching the Dial key (another
livered by the software.
The dimension is evaluated in much the same way as described in event), the cellular phone software makes a transition the dialing state. When
Section 4.3.2. Counts of retained data (the internal program data structure, computing 3D function points, not assigned a complexity value.
To compute 3D function points, the following relationship is used:
e.g., files) and external data (inputs, outputs, inquiries, and external references)
are used along with measures of complexity to derive a data dimension count. index=I+O+Q+F+E+T+R
The dimension is measured by considering “the number of in-
ternal operations to input to output datn” For the where 0, and R represent complexity weighted values for the
purposes of function point a “transformation” is viewed as a discussed inputs, outputs, internal data
of processing steps that are constrained a set of semantic statrmcnts. transformations, nnd transitions,
As a general rule, a transformation is accomplished with an algorithm that re- weighted value is computed using the following relationship:
sults in a fundamental change to input data as it is processed to become out- complexity weighted value
put data. Processing steps that acquire data from a file and simply place that
data into program memory would not be considered a transformation. The data where and represent the number of occurrences of element (e.g.,
itself has not been changed in any fundamental way outputs) for each level of complexity (low, average, high), and and
The level of complexity assigned to each transformation is a function of the are the weights. The overall computation for 3D function points
number of processing steps and the number of semantic statements that con- is shown in Figure 4.7.
trol the processing steps. Figure 4.6 provides guidelines for assigning complex- It should be noted that function points, feature points, and 3D function
ity in the functional dimension. points the same thing-“functionality” or “utility” delivered by soft-
The control dimension is measured by counting the number of transitions ware. In fact, each of these measures results in the same value if only the data
between states.” A state represents some externally observable mode of dimension of an application is considered. For more complex real-time systems,
and a transition occurs as a result of some event that causes the software or the feature point count is often between 20 and 35 percent higher than the
system to change its mode of behavior to change state). For example, a count determined using function points alone.
The function point (and its extensions), like the LOC measure, is contro-
versial. Proponents claim that FP is programming language independent, mak-
ing it ideal for applications using conventional and nonprocedural languages,
“A detailed discussion of the behavioral dimension, including and is and that it is based on data that are more likely to be known early in the evo-
presented in Chapter 12. lution of a project, making FP moie attractive as an estimation approach.
90 PART TWO. MANAGING SOFTWARE PROJECTS CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 91
Complexity Weighting tion should be correlated to of
both the amount LOC to be developed and the
development effort needed.
measurement element low average high
The following table JON911 provides rough estimates of the aver-
internal data structures X
7 x 10 + x 15 = age number of lines of code required to build one function point in various pro-
gramming languages: ,
data X
5 + X .
7 + x 10 =
number of user inputs X Programming language (average)
3 X X 6 = assembly language 320
C 128
number of user outputs 4 + X 5 + X 7 =
105
105
number of user inquiries X 3 X 4 + X 6 = Pascal 90
70
transformations X x 10 + languages 30
fourth generation languages 20
code generators 15
transitions x x x = spreadsheets 6
graphical languages (icons) 4
3D function point index
4.7. Computing the 3D function point index. A review of the above data indicates that one LOC of Ada provides approxi-
mately 1.4 times as much “functionality” (on average) as one LOC of
Furthermore, one LOC of a 4GL provides between three and five times the
Opponents claim that the method requires some “sleight of hand” in that com- of a for a conventional programming language. More de-
putation is based on subjective, rather than objective, data; that counts of the tailed data on the relationship between FP and LOC are presented in
information domain (and other dimensions) can be to collect and can be used to “backfire” (i.e., to compute the number of function points
fact; and that FP has no direct physical meaning-it’s just a number. when the number of delivered LOC are known) existing programs to determine
the FP measure for each.
LOC and FP measures are often used to derive productivity metrics. This
4.4 RECONCILING DIFFERENT METRICS APPROACHES invariably leads to a debate about the use of such data. Should the
person-month (or FP/person-month) of one group be compared to similar data
The relationship between lines of code and function points depends upon the from another? Should managers appraise the performance of individuals by
programming language that is used to implement the software and the quality using these metrics? The answers to these questions is an emphatic NO! The
of the design. A number of studies have-attempted to relate FP and LOC mea- reason for this response is that many factors influence productivity, making for
sures. To quote Albrecht and Gaffney “apples and qranges” comparisons that can be easily misinterpreted.
and Zelkowitz define five important factors that influence
The thesis of this work is that the amount of function provided by the software productivity:
(program) can be estimated from the itemization thb major compo-
nent@ of data to be used or provided by it. Furthermore, this estimate of People factors. The size and expertise of the development organization.
Problem factors. The complexity of the problem to be solved and the num-
ber of changes in design constraints or requirements.
is important to note that ‘the itemization of major components” can interpreted in a Process factors. Analysis and design techniques that are used, languages
riety of ways. Some software engineers who work in an object-oriented development and CASE tools available, and review techniques.
ment the number of classes objects the dominant size metric Chapter 23 for ad- Product Reliability and performance of the computer-based system.
ditional discussion). A maintenance organization might view project size in terms of the
number of engineering change orders (Chapter An information systems organization might Resource factors. Availability of CASE tools and hardware and software
view the number of business processes impacted by an application. resources.
92 PART MANAGING SOFTWARE PROJECTS 93
CHAPTER 4: SOFTWARE PROCESS AND PROJECT METRICS
If one of the productivity factors is above average (highly favorable) for a addition to its functional correctness and performance, which have life cycle im-
given project, software development productivity will be significantly higher plications. Such factors as maintainability and portability have been shown in
than if the same factor is below average (unfavorable). recent years to have significant life cycle cost impact .
Secondly, the framework provides a means for quantitatively assessing
how well the development is progressing relative to the quality goals estab-
4.5 METRICS FOR QUALITY lished.
The overriding goal of software engineering is to produce a high-quality sys- ‘Thirdly, the framework provides for more interaction of personnel through-
tem, application, or product. To achieve this goal, software engineers must ap- out the development effort.
ply effective methods coupled with modern tools within the context of a mature Lastly, quality assurance personnel can use indications of poor quality to
software process. In addition, a good software engineer (and good software help identify [better] standards to be enforced in the future.
managers) must measure if high quality is to be realized.
The quality of a system, application, or product is only as good as the re-
quirements that describe the problem, the design that models the solution, the A detailed discussion of McCall and Cavano’s framework, as well as other qual-
code that leads to an executable program, and the tests that exercise the soft- ity factors, is presented in Chapter 18. It is interesting to note that nearly every
ware to uncover errors. A good software engineer uses measurement to assess aspect of computing has undergone radical change as the years have passed
the quality of the analysis and design models, the source code, and the test cases since McCall and Cavano did their seminal work in 1978. But the attributes
that provide an indication of software quality remain the same.
that have been created as the software is engineered. To accomplish this real-
What does this mean? If a software organization adopts a set of quality fac-
time quality assessment, the engineer must use technical measures (Chapters
tors as a “checklist” for assessing software quality, it is likely that software
18 and to evaluate quality in objective, rather than subjective, ways.
built today will still exhibit quality well into the first few decades of the
The project manager must alsoevaluate quality as the project progresses.
Private metrics collected by individual software engineers are assimilated to first century. Even as computing architectures undergo radical change (as they
surely will), software that exhibits high quality in operation, transition, and re-
provide project-level results. Although many quality measures can be collected,
the primary thrust at the project level is to measure errors and defects. Metrics vision will continue to serve its users well.
derived from these measures provide an indication of the effectiveness of indi-
vidual and group software quality assurance and control activities.
Errors uncovered per review hour and errors uncovered per testing hour
provide insight into the efficacy of each of the activities implied by the metric. Measuring Quality
Error data can also be used to compute the defect removal efficiency for
each process framework activity. DRE is discussed in Section 45.3. Although there are many measures of software quality, correctness, maintain-
ability, integrity, and usability provide useful indicators for the project team.
Gilb suggests definitions and measures for each.
4.5.1 An Overview of Factors that Affect Quality
C o r r e c t n e s s . A program must operate correctly or it provides little value
to its users. Correctness is the degree to which the performs its
Over two decades ago, McCall and Cavano defined a set of quality fac- required function, The most common measure for correctness is defects per
tors that were a first step toward the development of metrics for software qual- where a defect is verified lack of conformance to re-
ity. These factors assess software from three distinct points of view: product quirements.
operation (using it), product revision (changing it), and product transi-
M a i n t a i n a b i l i t y . Software maintenance accounts for more effort than
tion (modifying it to work in a different environment, i.e., “porting” it]. In their
any other software engineering activity. Maintainability is the ease with
work, the authors describe the relationship between these quality factors (what which a can be corrected if an error is encountered, adapted if its
they call a “framework”) and other aspects of the software engineering process:
environment changes, or enhanced if the customer desires a change in re-
quirements There is no way to measure maintainability directly; therefore,
First, the framework provides a mechanism for the project manager to identify we must use indirect measures. A simple time-oriented metric is mean-
what qualities are important. These qualities are attributes of the software, in time-to-change the time it takes to analyze the change request,
design an appropriate modification, implement the change, test it, and dis-
tribute the change to all users. On average, programs that are maintain-
“Defect removal can be used to the impact of quality able will have a lower (for equivalent types of changes) than pro-
the topic is in grams that are not maintainable.
PART MANAGING SOFTWARE PROJECTS CHAPTER 4: SOFTWARE PROCESS AND PROJECT METRICS 9 5
Hitachi has used a cost-oriented metric for maintainability DRE = + (4.4)
called “spoilage”-the cost to correct defects encountered after the soft-
ware has been released to its end users. When the ratio of spoilage to where E = number of errors found before delivery of the software to
overall project cost (for many projects) is plotted as a function of time, a the end user
manager can determine whether the overall maintainability of software
produced by a software development organization is improving. Actions D = number of defects found after delivery
can then be taken in response to the insight gained from this
information. The ideal value for DRE is 1. That is, no defects are found in the software.
Integrity. Software integrity has become increasingly important in the Realistically, D will be greater than but the value of DRE can still ap-
age of hackers and viruses. This attribute measures a system’s ability to proach 1 as E increases. In fact, as E increases, it is likely that the final value
withstand attacks (both accidental and intentional) on its security. Attacks of D will decrease (errors are filtered out before they become defects). If used
can on all three components of software: programs, data, and doc- as a metric that provides an indicator of the filtering ability of quality control
uments. and assurance activities, DRE encourages a software project team to institute
techniques for finding as many errors as possible before delivery,
To measure integrity, two additional attributes must be defined: threat
and security. Threat is the probability (which can be estimated or derived DRE can also be used within the project to assess a team’s ability to find
from empirical evidence) that an attack of a specific type will occur within errors before they are passed to the next framework activity or software engi-
a given time. Security is the probability (which can be estimated or derived neering task. For example, the requirements analysis task produces an analy-
from empirical evidence) that the attack of a specific type will be repelled. sis model that can be reviewed to find and correct errors. Those errors that are
The integrity of a system can then be defined as: not found during the review of the analysis model are passed on to the design
task (where they may or may not be found). When used in this context, we re-
integrity = throat X (1 security)] define DRE as:
where threat and security are summed type of attack. + +
Usability. The catch-phrase “user friendliness” has become ubiquitous
in discussions of software products. If a program is not “user friendly,” it . where E, = number of errors found during software engineering activ-
is often doomed to failure, even if the functions that it performs are valu- ity
able. Usability is an attempt to quantify “user friendliness” and can be = number of errors found during software engineering activity
measured in terms of four characteristics: the physical and/or intel- 1 that are traceable to errors that were not discovered in software
lectual skill required to learn the system; the time required to become engineering activity
moderately in the use of the system; the net increase in pro-
ductivity (over the approach that the system replaces) measured when
the system is used by someone who is moderately and a sub- A quality objective for a software team (or an individual software engineer) is
jective assessment (sometimes obtained through a questionnaire) of users to achieve DRE, that approaches 1. That is, errors should be filtered out before
they are passed on to the next activity.
attitudes toward the system. Further discussion of this topic is contained
in Chapter 14.
The four factors described above are only a sampling of those that have 4.6 INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
been proposed as measures for software quality. Chapter 18 considers this topic
in additional detail. The majority of software developers still do not measure, and sadly, most have
little desire to begin. we noted earlier in this chapter, the problem is cul-
tural. Attempting to collect where none had been in the past
often precipitates resistance. “Why do we need to do this?” asks a harried proj-
4.5.3 Defect Removal Efficiency ect manager. “I don’t see the point,” complains an overworked practitioner.
Why is it so important to measure the process of software engineering and
A quality metric that provides benefit at both the project and process level is the product (software) that it produces? The answer is relatively obvious. If we
defect removal efficiency In essence, DRE is a measure of the filtering do not measure, there is no real way of determining whether we are improv-
ability of quality assurance and control activities as they are applied through- ing. And if we are not improving, we are lost.
out all process framework activities. Measurement is one of a number of “medications” that may help cure the
When considered for a project as a whole, DRE is defined in the following described in Chapter 1. It provides benefits at the strate-
manner: gic level, at the project level, and at the technical level.
96 PART MANAGING SOFTWARE PROJECTS 97
CHAPTER 4: SOFTWARE PROJECT METRICS
\
By requesting and evaluating productivity and quality measures, senior
management can establish meaningful goals for improvement of the software
engineering process. In Chapter 1 we that software is a strategic busi-
ness issue for many companies. If the process through which it is developed can
be improved, a direct impact on the bottom line can result. But to establish
goals for improvement, the current status of software development must be un-
derstood. Hence, measurement is used to establish a process baseline from
which improvements can be assessed.
The day-to-day rigors of software project work leave little time for strate-
gic thinking. Software project managers are concerned with more mundane
(but equally important) issues: developing meaningful project estimates; pro-
ducing higher-quality systems; getting product out the door on time. By using
measurement to establish a project baseline, each of these issues becomes more
manageable. We have already noted that the baseline serves as a basis for es-
timation. Additionally, the collection of quality metrics enables an organization
to “tune” its software engineering process to remove the “vital few” causes of
defects that have the greatest impact on software development.*
At the project and technical level (in the trenches), software metrics pro-
vide immediate benefit. As the software design is completed, most developers
would be anxious to obtain answers to the questions such as:
FIGURE 4.8.
!" Which user requirements are most likely to change?
Software metrics
!" Which modules in this system are most error prone? collection process
!" How much testing should be planned for each module?
!" How many errors (of specific types) can I expect when testing commences?
4.7 SUMMARY
Answers to these questions can be determined if metrics have been collected
and used as a technical guide. In later chapters we will examine how this is Measurement enables managers and practitioners to improve the software
done. process; assist in the planning, tracking, and control of a software project; and
The process for establishing a is illustrated in Figure 4.8. Ideally, assess the quality of the product (software) that is produced. Measures of spe-
data needed to establish a baseline has been collected in an ongoing manner. cific attributes of the process, project, and product are used to compute so&-
Sadly, this is rarely the case. Therefore, data collection requires an historical ware metrics. These metrics can be analyzed to provide indicators that guide
investigation of past projects to reconstruct required data. Once measures have management and technical actions.
been collected (unquestionably the most difficult step), metrics computation is Process metrics enable an organization to take a strategic view by provid-
possible. Depending on the breadth of measures collected, metrics can span a ing insight into the effectiveness of a software process. Project metrics are tac-
broad range of LOC or FP metrics as well as other quality and project-oriented tical. They enable a project manager to adapt project work flow and technical
metrics. Finally, metrics must be evaluated and applied during estimation, approach in a real-time manner.
technical work, project control, and process improvement. Metrics evaluation fo- Both size- and function-oriented metrics are used throughout the industry.
cuses on the underlyipg reasons for the results obtained and produces a set of Size-oriented metrics make use of the line of code as a normalizing factor for
indicators that guide the project or process. other measures person-months or defects. The function point is derived
from measures of the information domain and a subjective assessment of prob-
lem complexity.
Software quality metrics, like productivity metrics, focus on the process, the
have been formalized into approach called quality uroiect. and the product. By developing and analyzing a metrics baseline for
and discussed in detail in Chapter 8. an organization can act to correct those areas of the software process
metrics baseline consists of data collected from past software development projects and that are the cause of software defects. In this chapter, four quality
be simple the table presented in Figure 4.4 or complex comprehensive correctness, maintainability, integrity, and usability-are discussed. Additional
containing dozens of project nnd from them. quality metrics are described later in this book.
98 9 9
PART MANAGING SOFTWARE PROJECTS CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS
Measurement results in cultural change. Data collection, metrics computa- Whitmire, S.A., “An Introduction to 3D Function Points, Software
tion, and metrics evaluation are the three steps that must be implemented to April 1995, pp. 43-53.
begin a metrics program. By creating a metrics baseline-a database
process and product measurements-software engineers and their man-
agers can gain better insight into the work that they do and the product that
PROBLEMS AND POINTS TO PONDER
they produce.
4.1. Suggest three measures, three metrics, and corresponding indicators that
might be used to assess an automobile.
REFERENCES 4.2. Suggest three measures, three metrics, and corresponding indicators that
might be used assess the service department of an automobile dealership.
Albrecht, A.J., “Measuring Application Development Productivity,” 4.3. Describe the difference between process and project metrics in your own
Development Symposium, Monterey, CA, October 1979, words.
pp. 83-92. 4.4. Why should some software metrics be kept “private? Provide examples of
Albrecht, A.J., and J.E. Gaffney, “Software Source Lines of three metrics that should be private. Provide examples of three metrics that
Code and Development Effort Prediction: A Sohware Science Validation,” should be public.
IEEE Trans. Software Engineering, November 1983, pp. 639-648.
4.6. Obtain a copy of and write a one- or two-page summary that out-
Arthur, L.J., Measuring Programmer Productivity and Software Quality, lines the PSP approach.
Wiley-Interscience, 1985.
V., and M. Zelkowitz, “Analyzing Medium Scale Software 4.6. Grady suggests an etiquette for software metrics. Can you add three more
rules to those noted in Section
Development,” 3rd Software Engineering, IEEE, 1978,
pp. 4.7. Attempt to complete the diagram shown in Figure 4.3. That is, fol-
Boehm, B., Software Engineering Prentice-Hall, 1981. lowing the approach used for ‘Incorrect” specifications, provide analogous in-
Gilb, Principles of Software Project Management, Addison-Wesley, formation for “Missing,” “Ambiguous,” and ‘Changes.”
1988. 4.8. What is an indirect measure and why are such measures common in software
and Metrics: Establishing a metrics work?
Company-Wide Program, Prentice-Hall, 1987. 4 . 9 . Team A found 342 errors during the engineering process prior re-
Grady, Practical Software Metrics lease. Team B found 164 errors. What additional would have to be
Process Prentice-Hall, 1992. made for projects A and B to determine which of the teams eliminated errors
Grady, R.B., “Successfully Applying Software Metrics,” Computer, vol. more efficiently? What metrics would you propose to help make the determi-
27, no. 9, September 1994, pp. 18-25. nation? What historical data might be useful?
Hetzel, Making Software Measurement Work, QED Publishing Group,
4.10. Present an argument against lines of code as a measure for software produc-
1993. tivity. Will your case hold up when dozens or hundreds of projects are con-
Humphrey, W., A Discipline for Software Engineering. Addison-Wesley, sidered?
1995.
4.11. Compute the function point value for a project with the following information
ZEEE Software Engineering Standards, Std. pp. 4748.
domain characteristics:
Function Point Counting Practices Manual, Release 4.0, International
Function Point Users Group 1994.
Number of user inputs: 32
Jones, C., Programming 1986.
Jones, C., Applied Measurement, McGraw-Hill, 1991. Number of user outputs: 60
McCall, J.A., and Cavano, “A Framework for the Measurement of Number of user inquiries: 24
Software Quality,” ACM Software Quality Assurance Workshop. Novem- Number of files: 8
ber 1978.
Paulish, D., and A. Carleton, “Case Studies of Software Process Number of external interfaces: 2
Improvement Measurement,” Computer, vol. 27, no. 9, September 1994,
pp. Assume that all complexity adjustment values average. Assume that al-
B., “Measure, Metric or Indicator: What’s the Difference?” gorithms have counted. Compute the feature point value under the same con-
Crosstalk, vol. 8, no. 3, March 1995, pp. 2930. ditions.
Tajima, D., and Matsubara, “The Computer Software Industry in 4.12. Compute the 3D function point value for an embedded system the fol-
Japan,” Computer, May 1981, p. 96. lowing characteristics:
PART MANAGING SOFTWARE CHAPTER 4: SOFTWARE PROCESS AND PROJECT METRICS 101
Internal data structures: 6 projects, ascertaining the meaning of the observation, and determining its
External data structures: 3 significance for tactical and strategic decisions. Garmus and (Measuring
Number of user inputs: 12 the Software Process, Prentice-Hall, discuss process metrics with an em-
phasis on function point analysis. The Software Productivity Consortium,
Number of user outputs: 60 Software Measurement Guidebook, Thomson Computer Press, 1995) provides
Number of user inquiries: 9 useful suggestions for instituting an effective metrics approach.
Number of external interfaces: 3 Many industry reports and metrics guidebooks, published by the
Department of Defense and research centers, have
Transformations: 36
emerged over the past decade. A sampling includes:
Transitions: 24
Andres, Software Management Using Effective Process Metrics:
that the complexity of the counts is evenly divided among The Experience, TRW Systems Engineering
age, and high. Development Division, November 1989.
Carleton, A.D. et al., Software Measurement for Systems: Recom-
4.13. The used to control an advanced photocopier requires 32,000 lines
mendations for Initial Core Measures, Carnegie-Mellon
of C and 4200 lines of a specialized language. Estimate the number
University, Software Engineering Institute, September 1992.
of function points for the software inside the photocopier.
4.14. McCall and (Section define a “framework” for software quality, W.A., Software Quality Measurement: A Framework for Counting
Using information contained in this and other books, expand each of the three Problems and Defects, Carnegie-Mellon University,
major “points of view” into a set of quality factors and metrics. Software Engineering Institute, September 1992.
4.16. Develop your own metrics (do not use those presented in this chapter) for cor- Metrics Reporting Guidebook, Version 1.1, Defense Information Systems
rectness, maintsinebility, integrity, usability, Be sure that they can be Agency, prepared by Mitre Corp., May 1994.
translated into quantitative values. Metrics Starter Kit and Guidelines, Software Technology Support Center,
4.16. Is it possible for spoilage to increase while decreases? Explain. Hill AFB, UT, 1994.
4.17. Does the LOC measure make any sense when fourth generation languages
used? Explain. On the Internet, research reports and pointers to information on
4.18. Write a paper outlining the results of software productivity studies (see metrics are available at the Software Engineering Laboratory:
Further Readings). Is there commonality among the results?
4.19. Collect software metrics for 2 to 6 projects on which you have worked. Basic
information should include cost (if applicable), LOC or function points, effort
(person-months), a complexity indicator (scale 1 to and chronological time The U.S. Army software Metric System Web site contains a variety of useful in-
to completion. Combine your data with information from other formation on process metrics:
leagues and check a class metrics baseline.
4.20. Put together a presentation that could be used to convince management that
measurement would be a worthwhile activity, Be sure to use a quantitative
argument. Present it to your class. A comprehensive listing of textbooks and papers on process metrics can be ob-
tained at:
FURTHER READINGS AND OTHER INFORMATION SOURCES
Software process improvement has received a significant amount of attention A Listserv mailing list that addresses function point metrics has been estab-
in years. Books by Humphrey Yeh (Software Process Control, lished. To subscribe, send mail to: cim
McGraw-Hill, 19931, Hetzel and Grady discuss how software
metrics can be used to provide the indicators necessary to improve the software SUBJECT: “none” (this field must be empty)
process. Putnam and Myers (Executive Briefing: Controlling Software CONTENT: SUB “Your name”
ment, IEEE Computer Society, and Pulford and his colleagues (A
Q u a n t i t a t i v e A p p r o a c h t o S o f t w a r e M a n a g e m e n t , Addison-Wesley, An up-to-date list of World Wide Web references for software process metrics
process metrics and their use from a management point of view. can be found at:
Weinberg (Quality Software Management, Volume 2: First Order Mea-
surement, Dorset House, 1993) presents a useful model for observing software
CHAPTER 5: SOFTWARE PROJECT PLANNING 103
to commit to quantitative measures when qualitative data are all that exist.
Estimation carries inherent risk’ and it is this risk that leads to uncertainty.
has a strong effect on uncertainty that is inherent in
planning. Complexity, however, is a relative measure that is affected by famil-
iarity with past effort. A real-time application might be perceived as “exceed-
SOFTWARE PROJECT
ingly complex” to a software group that has previously developed only batch ap-
plications. The same real-time application might be perceived as
the-mill” for a software group that has been heavily involved in high speed
PLANNING
process control. A number of quantitative software complexity measures have
been proposed (Chapters 18 and Such measures are applied at the design
or code level and are therefore difficult to use during software planning (before
a design and code exist). However, other, more subjective assessments of com-
plexity (e.g., the function point complexity adjustment factors described in
Chapter cnn be established early in the planning process.
Project size is another important factor that can affect the accuracy of es-
timates. As size increases, the interdependency among various elements of the
software grows rapidly.” Problem decomposition, an important approach to es-
timating, becomes more because decomposed elements may still be for-
midable. To paraphrase Murphy’s law: “what can go wrong will go wrong”-and
if there are more things that can fail, more things will fail.
The degree of structural uncertainty also has an effect on estimation risk.
In this context, structure refers to the degree to which requirements have been
solidified, the ease with which functions can be compartmentalized, and the hi-
he software project management process begins with a set of activities that erarchical nature of information that must be processed.
are collectively called project planning. The first of these activities is esti- The availability of historical information also determines estimation risk.
mation. Whenever estimates are made, we look into the future and accept some Santayana once said, “Those who cannot remember the past are condemned to
degree of uncertainty as a matter of course. To quote Frederick Brooks repeat it.” By looking back, we can emulate things that worked and avoid areas
where problems arose. When comprehensive software metrics are
techniques of estimating are poorly developed. More seriously, they re- available for past projects, estimates can be made with greater assurance; sched-
flect an unvoiced assumption that is quite untrue, i.e., that all will go ules can be established to avoid past difficulties, and overall risk is reduced.
well we are uncertain of our estimates, software managers often Risk is measured by the degree of uncertainty in the quantitative
lack the courteous stubbornness to make people wait for a good product. mates established for resources, cost, and schedule. If project scope is poorly
understood or project requirements are subject to change, uncertainty and risk
become dangerously high. The software planner should demand completeness
Although estimating is as much art as it is science, this important activity
of function, performance, and interface definitions (contained in a system
need not be conducted in a haphazard manner. Useful techniques for time and
The planner, and more important the customer, should recognize that
effort estimation do exist. And because estimation lays a foundation for all
variability in software requirements means instability in cost and schedule.
other project planning activities, and project planning provides the road map
As a final observation on estimating, we consider the words of Aristotle
for successful software engineering, be ill-advised to embark with-
B.C.):
out it.
is the mark of an instructed mind to rest satisfied with the degree of pre-
cision which the nature of a subject admits, and not to seek exactness when
5.1 OBSERVATIONS ON ESTIMATING only an approximation of the truth is possible. .
A leading executive was once asked what single characteristic was most im-
portant when selecting a project manager. His response: “a person with the
ability to will go wrong before it actually does.” We might add: “and ‘Systematic techniques for risk analysis are presented in Chapter 6.
the courage to estimate when the future is cloudy.” “Sizeoften increases due to the “scope creep” that occurs when the changes re-
Estimation of resources, cost, and schedule for a software development ef- quirements. Increases in project size can have a geometric impact on project cost and
fort requires experience, access to good historical information, and the courage
102
104 PART MANAGING SOFTWARE PROJECTS 105
CHAPTER 5: SOFTWARE PROJECT PLANNING
A project manager should not become obsessive about estimation. Modern soft- is to conduct a preliminary meeting or interview. The first meeting between a
ware engineering approaches (e.g., evolutionary process models) take an itera- software engineer (the analyst) and the customer can be likened to the awk-
tive view of such approaches, it is possible” to revisit the esti- wardness of a first date between two adolescents. Neither person knows what
mate (as more information is known) and revise it when the customer makes to say or ask; both are worried that what they do say will be misinterpreted;
changes to requirements. both are thinking about where it might lead (both likely have radically differ-
ent expectations here); both want to get the thing over with; but at the
time, both want it to be a success.
5.2 PROJECT PLANNING OBJECTIVE5 Yet, communication must be initiated. Gause and Weinberg sug-
gest that the analyst start by asking context free questions. That is, a set of
questions that will lead to a basic understanding of the problem, the people
The objective of project planning is to provide a framework that en-
ables the manager to make reasonable estimates of resources, cost, and sched- who want a solution, the nature of the solution that is desired, and the effec-
tiveness of the first encounter itself.
ule. These estimates are made within a limited time frame at the beginning of
a software project and should be updated regularly as the project progresses. The first set of context free questions focus on the customer, the overall
goals, and the benefits. For example, the analyst might ask:
In addition, estimates should attempt to define “best case” and “worst case” sce-
narios so that project outcomes can be bounded.
The planning objective is achieved through a process of information dis- !"Who is behind the request for this work?
covery that leads to reasonable estimates. In the following sections, each of the !"Who will use the solution?
activities associated with software project planning is discussed. !" What will be the economic benefit of a successful solution?
!" Is there another source for the solution?
5.3 SCOPE
The next set of questions enable the analyst to gain a better understanding
of the problem and the customer voice his or her perceptions about a solution:
The first activity in software project planning is the determination of software
scope. Function and performance allocated to software during system engi- !" How would you [the customer] characterize “good” output that would be gen-
neering (Chapter should be assessed to establish a project scope that is un- erated by a successful solution?
ambiguous and understandable at management and technical ‘levels.
!" What problem(s) will this solution address?
Sofhvare scope describes function, performance, constraints, interfaces, and
reliability. Functions described in the statement of scope are evaluated and in !" Can you show me (or describe) the environment which the solution will be
some cases refined provide more detail prior the beginning of used?
Because both and schedule estimates are functionally oriented, !" Are there special performance issues or constraints that will affect the way
of decomposition is useful. Performance considerations encompass process- the solution is approached?
ing and response time requirements. Constraints identify limits placed on the
software by external hardware, available memory or other existing systems. The final set of questions focus on the effectiveness of the meeting. Cause
and Weinberg call these “meta-questions and propose the following (abbrevi-
ated) list:
5.3.1 Obtaining Information Necessary for Scope .
!" Are you the right person answer these questions? Are your answers ‘official?”
!" Are my questions relevant to the problem that you have?
Things are always somewhat hazy at the beginning of a software project. A
need has been defined and basic goals and objectives have been enunciated, but !" Am I asking too many questions?
the information necessary to define scope (a prerequisite for estimation) has !" Is there anyone else who can provide additional information?
not yet been defined.
!" Is there anything else that I should be asking you?
The most commonly used technique’to bridge the communication gap be-
tween the customer and developer and to get the communication process started
These questions (and others) will help to “break the ice” and initiate the com-
munication that is essential to establish the scope of the project. But a ques-
tion and answer meeting format is not an approach that has been
not meant to imply is always politically acceptable to modify initial estimates.
A mature software organization and its managers recognize that change is not free. yet, ingly successful. In fact, the Q&A session should be used for the first encounter
many customers demand (incorrectly) that an estimate once made must be maintained oply and then be replaced by a meeting format that combines elements of
of changing circumstances. lkm solving, negotiation, and specification.
106 PART TWO MANAGING SOFTWARE PROJECTS CHAPTER 5: SOFTWARE PROJECT PLANNING
A number of independent investigators have developed a team-oriented BINS
approach to requirements gathering that can be applied to help establish the
scope of a Called facilitated application specification techniques
this approach encourages the creation of a joint team of customers and devel-
opers who work together to identify the problem, propose elements of the so-
lution, negotiate different approaches, and specify a preliminary set of re- conveyor line
quirements. motion
ID No.
5.3.2 A
Communication with the customer leads to a definition of the data, functions,
and behavior that must be implemented, the performance and constraints that
bound the system, and related information. As an example, consider software
0 0 0
that must be developed to drive a conveyor line sorting system The
statement of scope for the CLSS follows:
, bar code SORTING
The conveyor line sorting system boxes moving along a con- STATION
veyor line. Each box is identified by a bar code that contains a part number and
is sorted into one of six bins at the end of the line. The boxes pass by a sorting
station that contains a bar code reader and a PC. The sorting station PC is con-
nected to a shunting mechanism that sorts the boxes into the bins. Boxes pass
in random order and are evenly spaced. The line is moving at live feet per
minute. A CLSS is depicted schematically in Figure 5.1.
CLSS software receives input information from a bar code reader at time
intervals that conform to the conveyor line speed. Bar code data will be decoded
FIGURE 5.1. A conveyor line sorting system
into box identification format. The software will do a look-up in a part number
data base containing a maximum of 1000 entries to determine proper bin loca-
tion for the box currently at the reader (sorting station). The proper bin loca-
tion is passed to a sorting shunt that will position boxes in the appropriate bin. !" read bar code input
A record of the bin destination for each box will be maintained for later recov- !" read pulse tachometer
ery and reporting. CLSS software will also receive input from a pulse tachome- !" decode part code data
ter that will be used to synchronize the control signal to the shunting mecha-
!" do database look-up
nism. Based on the number of pulses that will be generated between the sorting
station and the shunt, the software will produce a control signal to the shunt !"determine bin location
to properly position the box. !"produce control for shunt
. maintain record of box dcstinationx
The project planner the statement of scope and extracts all impor-
tant software functions. This process, called is waa discussed in
In this case, performance is dictated by conveyor line speed. Processing for
Chapter 3 and results in the following
each box must be completed before the next box arrives at the bar code reader.
The CLSS software is constrained by the hardware it must access (the bar code
reader, the shunt, the PC), the available memory, and the overall conveyor line
configuration (evenly spaced boxes).
should be noted that these techniques are often viewed a first step in requirements Function, performance, and constraints must be evaluated together. The
analysis and are discussed in more detail in Chapter 11. same function can precipitate an order of magnitude difference in development
reality, the functional decomposition is performed during engineering (Chapter effort when considered in the context of different performance bounds. The ef-
The planner information derived from the system specification to define fort and cost required to develop CLSS software would dramatically differ-
ent if function remains the same (i.e., put boxes into bins) but performance
109
108 PART MANAGING SOFTWARE PROJECTS CHAPTER 5: SOFTWARE PROJECT PLANNING
varies. For instance, if conveyor line average speed increases by a factor of 10
(performance) and boxes are no longer spaced evenly (a constraint),
would become considerably more complex and thereby require more effort.
Function, performance, and constraint are intimately connected.
interacts with other elements of a computer-based system. The
planner considers the nature and complexity of each interface to determine any
affect on development resources, cost, and schedule. The concept of an interface
is interpreted to mean hardware (e.g., processor, peripherals) that executes
the and devices (e.g., machines, displays) that are indirectly controlled
by the software; software that already exists (e.g., database access routines,
reusable software components, operating system) and must be linked to the Hardware/Software Tools
new software; people who make use of the software via keyboard or other ‘FIGURE 5.2.
I/O devices; and procedures that precede or succeed the a se- Resources.
quential series of operations. In each case the information transfer across the
interface must be clearly understood.
The least precise aspect of software scope is a discussion of reliability. 5.4.1 Human Resources
Software reliability measures do exist (Chapter but they are rarely used at
this stage of a project. Classic hardware reliability characteristics like mean- The planner begins by evaluating scope and selecting the skills required to
time-between-failure (MTBF) can be difficult to translate to software do- complete development. Both organizational position (e.g., manager, senior soft-
main. However, the general nature of the software may dictate special consid- ware engineer, etc.) and specialty (e.g., telecommunications, database,
erations to ensure “reliability.” For example, software for an air control client/server) are specified. For relatively small projects (six person-months or
system or the Space Shuttle (both human-rated systems) must not fail or hu- less) single individual may perform al] software engineering steps, consult-
man life may be lost. An inventory control system or word-processing software ing with specialists as required.
should not fail, but the impact of failure is considerably less dramatic. Although The number of people required for a software can be determined
it may not be possible to quantify software reliability as precisely as we would only after an estimate of development effort (e.g., person-months or
like in the statement of scope, we can the nature of the project to aid in years) is made. Techniques for estimating effort are discussed later in the
formulating estimates of effort and cost to assure reliability. chapter.
If a system specification (see Chapter 10) has properly developed,
nearly all information required for a description of software scope is available
and documented before planning begins. In cases where a spec-
ification has not been developed, the planner must take on the role of system 5.4.2 Reusable Software Resources
analyst to determine attributes and bounds that will influence estimation tasks.
Any discussion of the software resource would be incomplete without
of reusability-that is, the creation and reuse of software building blocks
5.4 RESOURCES Such building blocks must be for easy reference, stan-
dardized for easy application, and validated for easy integration.
Bennatan suggests four software resource categories that should
The second task of software planning is estimation of resources required to ac- be considered as planning proceeds:
complish the software development effort. Figure 5.2 illustrates development
resources as a pyramid. The development and software
O f f - t h e - s h e l f c o m p o n e n t s . Existing software that can be acquired from
tools-sits at the foundation of the resources pyramid and provides the a third party or that has been developed internally for a past project. These
structure to support the development effort. At a higher level we encounter
components are ready for use on the current project and have been fully
cnn drnmntically
reduce development costs and accelerate delivery. At the top of the pyramid is
the is with four Full-experience c o m p o n e n t s . Existing specifications, designs, code, or
tics: description of the resource, a statement of availability, chronological time for past projects that are similar to the software to be
that the resource will be duration of time that the resource will built for the current project. Members of the current software team have
be applied. The last two characteristics can be viewed as a time window. had full experience in the application area represented by these compo-
Availability of the resource for a specified window must be established at the nents. Therefore, modifications required for full-experience components
earliest practical time. will be relatively low-risk.
110 PART TWO MANAGING SOFTWARE PROJECTS CHAPTER 5: SOFT ARE
W PROJECT PLANNING 111
P a r t i a l - e x p e r i e n c e c o m p o n e n t s . Existing specifications, designs, code, When a computer-based system (incorporating specialized hardware and
or test data developed for past projects that are related to the software to software) is to be engineered, the software team may require access to hard-
be built for the current project, but will require substantial modification. ware elements being developed by other engineering teams. For example, soft-
Members of the current software team have only limited experience in the ware for a numerical control used on a class of machine tools may require
application area represented by these components. Therefore, modifications a specific machine tool (e.g., a NC lathe) as part of the validation test step; a
required for partial-experience components have a fair degree of risk. software project for automated typesetting may need a photo-typesetter at
N e w c o m p o n e n t s . Software components that must be built by the soft- some point during -development. Each hardware element must be specified by
ware team specifically for the needs of the current project. the software project planner.
The following guidelines should be considered by softwurc planner
when reusable components are specified as a resource: 5.5 PROJECT ESTIMATION
If off-the-shelf components meet project requirements, acquire them. The In the early days of computing, software costs comprised a small percentage of
cost for acquisition and integration of off-the-shelf components will almost overall computer-based system cost. An order of magnitude error in estimates
always be less than the cost to develop equivalent In addition, of software cost had relatively little impact. Today, software is the most expen-
risk is relatively low. sive element in most computer-based systems. A large cost estimation error can
If full-experience components are available, the risks associated with mod- make the between profit and loss. Cost overrun can be disastrous for
ification and integration are generally acceptable. The project plan should the developer.
reflect the use of these components. Software cost and effort estimation will never be an exact science. Too
If partial-experience components are available, their use for the current many variables--human, technical, environmental, political--can affect the ul-
project must be analyzed in detail. If extensive modification is required be- timate cost of software and effort applied to develop it. However, proj-
fore the components can be properly integrated with other elements of the ect estimation can be transformed from a mysterious art to a series of system-
proceed carefully. The cost to modify partial-experience compo- atic steps that provide estimates with acceptable risk.
nents be than the to develop new To achieve reliahle und effort estimates, a number of options arise:
Ironically, the use of reusable software components is often neglected during 1. Delay estimation until late in the project (obviously, we can achieve 100%
planning, only to become a paramount concern during the development phase accurate after the project is complete!).
of the software process. It is far better to specify software resource require- 2. Base estimates on similar projects that have already been completed.
ments early. In this way technical evaluation of alternatives can be conducted 3. Use relatively simple “decomposition techniques” to generate project cost
and timely acquisition can occur. and effort estimates.
4. Use one or more empirical models for software cost and effort estimation.
5.4.3 Environmental Resources Unfortunately, the first option, however attractive, is not practical. Cost esti-
mates must be provided “up-front.” However, we should recognize that the
The environment that supports the software project, called a en- longer we wait, the more we know, and the more we know, the less likely we
gineering environment (SEE), incorporates hardware and software. Hardware are to make serious errors in our estimates.
provides a platform that supports the tools (software) required to produce the The second option can work reasonably well if the current project is quite
work products that are an outcome of good software engineering similar to past efforts and other project influences (e.g., the customer, business
Because most software organizations have multiple constituencies that require conditions, the SEE, deadlines) are equivalent. Unfortunately, past experience
access to the SEE, a project planner must prescribe the time window required has not always been a good indicator of future results.
for hardware and software and verify that these resources will be available. The remaining options are viable approaches to software project estima-
tion. Ideally, the techniques noted for each option should be applied in tandem,
each used as a cross-check for the other. Decomposition techniques take a ‘di-
vide and conquer” approach to software project estimation. By decomposing a
existing components are used during a project, the overall cost reduction can project into major functions and related software engineering activities, cost
be dramatic. In fact, industry data indicate that cost, time to market, and the number of de- and effort estimation can be performed in a fashion. Empirical esti-
fects delivered to the field all reduced mation models can be used to complement decomposition techniques and offer
hardware-the target the computer on which the software will exe- a potentially valuable estimation approach in their own right. A model is based
cute when it has been released the end on experience (historical data) and takes the form:
112 PART TWO: MANAGING SOFTWARE PROJECTS 113
CHAPTER 5: SOFTWARE PROJECT PLANNING
d “Fuzzy-logic” sizing. This approach uses the approximate reasoning
where d is one of a number of estimated values (e.g., effort, cost, project dura- techniques that are the cornerstone of fuzzy logic. To apply this approach,
the planner must identify the type of application, establish its magnitude
tion) and are selected independent parameters (e.g., or
on a qualitative scale, and then refine the magnitude within the original
Automated estimation tools implement one or more decomposition tech-
range. Although personal experience can be used, the planner should also
niques or empirical models. When combined with an interactive
have access to an historical database of so that estimates can be
machine interface, automated tools provide an attractive option for estimating.
compared to actual experience.
In such systems, the characteristics of the development organization (e.g.,
experience, environment) and the software to be developed are described. Cost F u n c t i o n p o i n t s i z i n g . The planner develops estimates of the informa-
and effort estimates are derived from these data. tion domain characteristics discussed in Chapter 4,
Each of the viable software cost estimation options is only as good as the S t a n d a r d c o m p o n e n t s i z i n g . Software is composed of a number of
historical data used to seed the estimate. If no data exist, costing “standard that are generic to a particular application
rests on a very shaky foundation. In Chapter 4, we examined the characteris- area. For example, the standard components for an information system are
tics of some of the software metrics that provide the basis for historical esti- subsystems, modules, screens, reports, interactive programs, batch pro-
mation data. grams, tiles, LOC, and object-level instructions. The project planner esti-
mates the number of occurrences of each standard component and then
uses historical project data to determine the delivered size per standard
component. To illustrate, consider an information systems application. The
5.6 DECOMPOSITION TECHNIQUES planner estimates that 18 reports will be generated. Historical data indi-
cates that 967 lines of are required per report. This enables
Software project estimation is a form of problem solving, and in most cases, the the planner to estimate that 17,000 LOC will be required for the reports
problem to be solved (i.e., developing a cost and effort estimate for a software component. Similar estimates and calculations are made for other standard
project) is too complex to be considered in one piece. For this reason, we de- components, and a combined size value (adjusted statistically) results.
compose the problem, recharacterizing it as a set of smaller (and hopefully C h a n g e s i z i n g . This approach is used when a project encompasses the
more manageable) problems. use of existing software that must be modified in some way as part of a
In Chapter 3, the decomposition approach was discussed from two differ- project. The planner estimates the number and type (e.g., reuse, adding
ent points of view: decomposition of the problem and decomposition of the code, changing code, deleting code) of modifications that must be accom-
process. Estimation makes use of one or both of these forms of partitioning. But plished. Using an “effort ratio” for each type of change, the size of
before an estimate can be made, the project planner must understand the scope the change may be estimated.
of the software to be built and generate an estimate of its “size.”
Putnam and Myers suggest that the results of each of the sizing approaches
noted above be combined statistically to create a three-point or expected
estimate. This is accomplished by developing optimistic most likely, and
5.6.1 Software Sizing
pessimistic (high) values for size and combining them using equations (5.1) de-
scribed in the next section.
The accuracy of a project estimate is predicated on a number of things:
the degree to which the planner has properly estimated the size of the prod-
uct to be built; the ability to translate the size estimate into human effort,
calendar time, and dollars function of the availability of reliable software Problem-Bard Estimation
metrics from past projects); the degree to which the project plan reflects the
abilities of the software team; and (4) the stability of product requirements and In Chapter 4, lines of code and function points were described as
the environment that supports the software engineering effort. basic measures from which productivity metrics can be computed. LOC and FP
In this section, we consider the software sizing problem. Because a project data are used in two ways during software project estimation: (1) as an esti-
estimate is only as good as the estimate of the size of the work to be accom- mation variable that is used to “size” each element of the software, and as
plished, sizing represents the project planner’s major challenge. In con- baseline metrics collected from past projects and used in conjunction with esti-
text of project planning, size refers to a quantifiable outcome of the software mation variables to develop cost and effort projections.
project. if a direct approach is taken, size can be measured in LOC. If an indi-
rect approach is chosen, size is represented as FP.
Putnam and Myers suggest four different approaches to the siz- “See Section 5.9 for a brief discussion of support fuzzy-logic sizing and the other
ing problem: in this section.
114 TWO MANAGING SOFTWARE PROJECTS 5 SOFTWARE PROJECT PLANNING 115
LOC and FP estimation are distinct estimation techniques, yet both have We that there is a very small probability that the actual size re-
a number of characteristics in common. The project planner begins with a sult will fall outside the optimistic or pessimistic values. Using standard sta-
statement of software scope and from this statement attempts to de- tistical techniques, we can compute the deviation of the estimates. However, it
compose software into problem functions that can each be estimated individu- should be noted that a deviation based on uncertain (estimated) data must be
ally. LOC or FP (the estimation variable) is then estimated for each function. used judiciously.
Alternatively, the planner may choose another component for sizing such as Once the expected value for the estimation variable has been determined,
classes or objects, changes, or business processes impacted. historical LOC or FP productivity data are applied. Are the estimates correct?
Baseline productivity metrics (e.g., or are then applied to The only reasonable answer to this question is: “We can’t be sure.” Any esti-
the appropriate estimation variable and cost or effort for the function is de- mation technique, no matter how sophisticated, must be cross-checked with an-
rived. Function estimates are combined to produce an overall estimate for the other approach. Even then, common sense and experience must prevail.
entire project.
It is important to note, however, that there is often substantial scatter in
productivity metrics for an organization, making the use of a single baseline
5.6.3 An Example of Estimation
productivity metric suspect. In general, or averages should be
computed by project domain. That is, projects should be grouped by team size,
application area, complexity, and other relevant parameters. Local domain av- AH an example of and FP estimation techniques, let us consider a software
erages should then be computed. When a new project is estimated, it should package to be developed for a computer-aided design (CAD) application for me-
first be allocated to a domain, and then the appropriate domain average for chanical components. A review of the system specification indicates that the
productivity should be used in generating the estimate. software is to execute on an engineering workstation and must interface with
The LOC and FP estimation techniques differ in the level of detail required various computer graphics peripherals including a mouse, digitizer, high-reso-
for decomposition and the target of the partitioning. When LOC is used as the lution color display, and laser printer.
estimation variable, absolutely essential and is often taken Using a system specification as a guide, a preliminary statement of soft-
to considerable levels of detail. The greater the degree of partitioning, the more ware scope can be developed:
likely that reasonably accurate estimates of LOC can be developed.
For FP estimates, decomposition works differently. Rather than focusing on The CAD software will accept two- and three-dimensional geometric data
function, each of the information domain characteristics-inputs, outputs, data from an engineer. The engineer will interact and control the CAD system
tiles, inquiries, and external interfaces-and the fourteen complexity adjust- through a user interface that will exhibit characteristics of good
ment values discussed in Chapter 4 are estimated. The resultant estimates are machine interface design. All geometric data and other supporting information
used to derive a FP value that can be tied to past data and used to generate will be maintained in a CAD database. Design analysis modules will be devel-
an estimate. oped to output which will be displayed on a variety of graph-
Regardless of the estimation variable that is used, the project planner be- ics devices. The software will be designed to control and interact with periph-
gins by estimating a range of values for each function or information domain eral devices that include a mouse, digitizer, and laser printer.
value. Using historical data or (when all else fails) intuition, the planner esti-
mates an optimistic, most likely, and pessimistic size value for each function or The above statement of scope is preliminary-it is bounded. Every sentence
count for each information domain value. An implicit indication of the degree would have to be expanded to provide concrete detail and quantitative bound-
of uncertainty is provided when a range of values is specified. ing. For example, before estimation can begin the planner must determine what
A or expected value is then computed. The expected value for “characteristics of good interface design” means or what the
the estimation variable can be computed as a weighted average of size and sophistication of the “CAD database” is to be.
the optimistic most likely and pessimistic estimates. For For our purposes, we assume that further refinement has occurred and that
example, the following major software functions are identified:
EV = + (5.1)
!" user interface and control facilities
gives heaviest credence to the “most likely” estimate and follows a beta proba- !" two-dimensional geometric analysis
bility distribution.
!"three-dimensional geometric analysis
!" database management
computer graphics display facilities
acronym pm stands for person-month.
!" peripheral control
general, decomposed. However, a list of standard components
5.6.1) be used instead. !" design analysis modules (DAM)
116 117
PART MANAGING SOFTWARE PROJECTS CHAPTER SOFTWARE PROJECT
Function est.
Estimated LOC
opt. likely pess. weight FP-count
Information Domain Value
user interface and control facilities 2,300 number of inputs 20 24 30 24 4 96
two-dimensional geometric analysis 5,300 number of outputs 12 15 22 16 5 80
three-dimensional geometric analysis 6,800 22 28 22 4 88
number of inquiries 16
database management 3,350 number of 4 4 5 4 10 40
computer graphics display facilities 4,950‘ number of external interfaces 2 2 3 2 7 14
peripheral control 2,100
design analysis modules (DAM) 8,400
FIGURE 5.3.
Estimation table estimated lines of code 3 3 ,2 0 0
for LOC method. 1 FIGURE 5.4. Estimating information domain values.
Following the three-point estimation technique for LOC, the table shown in Each of the complexity weighting factors is estimated and the complexity
Figure developed. For example, the range of LOC estimates for the 3D adjustment factor is computed as described in Chapter 4:
geometric analysis function is:
Factor Value
optimistic: 4600
4
Backup and recovery
most likely: 6900
Data communications 2
pessimistic: 8600
processing 0
Performance critical 4
Applying equation the expected value for the 3D geometric analysis func-
tion is 6800 LOC. This number is entered in the table. Other estimates are de- Existing operating environment 3
rived in a similar fashion. By summing vertically in the estimated column, On-line data entry 4
an estimate of 33,200 lines of code is established for the CAD system. Input over multiple screens 5
A review of historical data indicates that the organizational average pro- 3
Master files updated on-line
ductivity for systems of this type is 620 Based on a burdened labor
Information domain values 5
rate of $8000 per month, the cost per of code is $13.00.
internal processing complex 5
Based on the LOC estimate and the historical productivity data, the total esti-
mated project cost is $431,000 and the estimated effort is 54 person-months.” Code designed for reuse 4
Conversion/installation in design 3
Multiple installations 5
Application designed for change 5
5.6.4 An Example of FP-Based Estimation
Complexity adjustment factor 1.17
Decomposition for W-based estimation focuses on information domain values,
rather than software functions. Recalling the function point calculation table Finally, the estimated number of FP is derived:
presented in Figure 4.5, the project planner estimates inputs, outputs, in-
quiries, files, and external interfaces for the CAD software. For the purposes of = count-total X IO.65 + 0.01
this estimate, the complexity weighting factor is assumed to be average. Figure
5.4 presents the results of this estimate.
Historical data normalized using function points indicate that the organiza-
tional average productivity for systems of this type is 6.6 Based on a
to the $1000 person-month. Arithmetic precision to burdened labor rate of $8000 per month, the cost per FP is approximately
trnth $1230. Based on the LOC estimate and the historical productivity data, the
118 PART MANAGING SOFTWARE PROJECTS
tal estimated project cost is $457,000 and the estimated effort is 58
months.
5.6.5 Process-Based Estimation
The most common technique for estimating a project is to base the estimate on
the process that will be used. That is, the process is decomposed into a rela-
tively small set of activities tasks and the effort required to accomplish each
task is estimated.
Like the problem-based techniques, process-based estimation begins with
a delineation of software functions obtained from the project scope. A series of
software process activities must be performed for each function. Functions and
related software process activities may be represented as part of a table simi-
lar to the one presented in Figure 3.2.
Once problem functions and process activities are melded, the planner es-
timates the effort (e.g., person-months) that will be required to accomplish. each
software process activity for each software function. These data comprise the
central matrix of the table in Figure 3.2. Average labor rates (i.e., cost/unit ef-
fort) are then to the effort estimated for each process activity. It is very
likely the labor rate will vary for each task. Senior staff are heavily
in early activities and are generally more expensive than junior staff, who are
involved in later design tasks, coding, and early testing.
Costs and effort for each function and software process activity are com-
puted as the last step. If process-based estimation is performed independently
of LOC or FP estimation, we now have two or three estimates for cost and ef-
fort that may be compared and reconciled. If both sets of estimates show rea-
sonable agreement, there is good reason to believe that the estimates are reli-
able. If, on the other hand, the results of these decomposition techniques show
little agreement, further investigation and analysis must be conducted.
An Example of Process-Based Estimation
To illustrate the use of process-based estimation, we again consider the CAD
software introduced in Section 5.6.3. The system configuration and all software
functions remain unchanged and are indicated by project scope.
The completed process-based table in Figure 5.5 shows estimates of effort
(in person-months) for each software engineering activity provided for each
CAD software function (abbreviated for brevity). The and con-
struction /release activities are subdivided into the major software engineering
tasks shown. Gross estimates of effort are provided for customer communica-
tion, planning, and risk analysis. These are noted in the “Total” row at the bot-
tom of the table. Horizontal and vertical totals provide an indication of esti-
mated effort required for analysis, design, coding, and testing. It should be
noted that 53 percent of all effort is expended on “front-end” engineering tasks
(requirements analysis and design) indicating the relative importance of this
work.
120 121
PART TWO: MANAGING SOFTWARE CHAPTER 5: SOFTWARE PROJECT PLANNING
Based on an average burdened labor rate of $8000 per month, the total esti- where A, B, and C are empirically derived constants, E is effort in person
mated project cost is $368,000 and the estimated effort is 46 person-months. If months, and is the estimation variable (either LOC or In addition to the
desired, different labor rates could associated with each software process activity relationship noted in equation (5.21, the majority of estimation models have
Total estimated effort for the CAD software ranges from a low of 46 per- some form of project adjustment component that enables E to be adjusted by
son-months (derived using a process-based estimation approach) to a high of on other project characteristics (e.g., problem complexity, staff experience,
58 person-months (derived using a FP estimation approach). The average esti- development environment).
mate (using all three approaches) is 53 person-months. The maximum varia- Among the many LOC-oriented estimation models proposed in the litera-
tion from the average estimate is approximately 13 percent. ture are:
What happens when agreement between estimates is poor? The answer to
= 5.2 X Walston-Felix Model
this question requires a re-evaluation of information used to make the esti-
mates. Widely divergent estimates can be traced to one of two causes: E = 5.5 + 0.73 X Bailey-Basili Model
E = 3.2 X Boehm simple model
1. The scope of the project is not adequately understood or has been misin-
terpreted by the planner. Doty Model for KLOC 9
E = 5.288 x
2. Productivity data used for problem-based estimation techniques is inap-
propriate for the application, is obsolete (in that it no longer accurately re- FP-oriented models have also been proposed. These include:
flects the software engineering organization), or has been misapplied. E = -13.39 + 0.0545 FP Albrecht and Gaffney Model
The planner must determine the cause of divergence and reconcile the esti- E = 60.62 x 7.728 X 10-s Kemerer Model
mates. Matson, Barnett, and Mellichamp Model
E = 585.7 15.12 FP
A quick examination of the models listed above indicates that each will yield a
5.7 EMPIRICAL ESTIMATION MODELS different result’s for the same value of LOC or The implication is clear.
Estimation models must be calibrated for local needs!
An estimation model for computer software uses empirically derived formulas
to predict effort as a function of LOC or FP. Values for LOC or FP are estimated
using the approach described in Sections 5.6.2 and 5.6.3. But instead of using 5.7.2 The COCOMO Model
tables in sections, the resultant values for or FP are
plugged into the estimation model. In his classic book on “software engineering economics,” Barry Boehm
The empirical data that support most estimation models is derived from a introduces a hierarchy of software estimation models bearing the name CO-
limited sample of projects. For this no estimation model is appropriate for Boehm’s hierarchy of models takes the
for all classes of software and in all development environments. Therefore, the following form:
results obtained from such models must be used judiciously.
Model 1. The Basic COCOMO model computes software development ef-
fort (and cost) as a function of program size expressed in esti-
mated lines of code.
5.7.1 The Structure of Estimation Models Model 2. The Intermediate COCOMO model computes software develop-
ment effort as a function of program size and a set of “cost dri-
A typical estimation model is derived using regression analysis on data col- vers” that include subjective assessments of product, hardware,
lected from past software projects. The overall structure of such models takes personnel, and project attributes.
the form Model 3. The Advanced COCOMO model incorporates all characteristics
of the intermediate version with an assessment of the cost dri-
E=A+ x (5.2) ver’s impact on each step (analysis, design, etc.) of the software
engineering process.
“In general, an estimation model should be calibrated for local conditions. The model should
be using the results of completed projects. Data predicted by the should be compared
to actual results, and the of the model (for local conditions) should assessed. If agree- of the reason is that these models are derived from relatively small populations
ment is not good, model and exponents must be recomputed local data. of projects in only few application domains.
122 PART TWO. MANAGING SOFTWARE PROJECTS CHAPTER 5. SOFTWARE PROJECT 123
BASIC COCOMO MODEL INTERMEDIATE COCOMO MODEL
Project Software Project
organic 1.05 2.5 0.38 organic 1
semidetached 3.0 1.12 2.5 0.35 semidetached 3.0 1.12
embedded 3.4 1.20 2.5 0.32 embedded 2.8 1.20
To illustrate the COCOMO model, we present an overview of the Basic and
Intermediate versions, For a more detailed discussion, the reader is urged to where is the effort applied in person-months and KLOC is the estimated
study number of delivered lines of code for the project. The a, and the ex-
The COCOMO models are defined for three classes of software projects. ponent are given in Table 5.2.
Using Boehm’s terminology these are organic mode-relatively small, sim- COCOMO represents a comprehensive empirical model for software esti-
ple software projects in which small teams with good application experience mation. However, Boehm’s own comments about COCOMO (and by
work to a set of less than rigid requirements (e.g., a thermal analysis program extension models) should hooded:
developed for a heat transfer group); semi-detached mode-an intermediate
size and complexity) software project in which teams with mixed experience Today, a software cost estimation model is doing well if it can estimate
levels must meet a mix of rigid and less than rigid requirements (e.g., a trans- costs within 20% of costs, 70% of time, and on
action processing system with fixed requirements for terminal hardware and its turf (that is, within the class of projects to which it has been cali-
database software); (3) embedded mode-a software project that must be de- brated). This is not as precise as we might like, but it is accurate enough
veloped within a set of tight hardware, software and operational constraints to provide a good deal of help in software engineering economic analysis and
(e.g., flight control software for aircraft). decision making.
The Basic COCOMO equations take the form:
To illustrate the of the COCOMO model, we apply the basic model to
E=
the CAB software example described earlier in this Using the LOC es-
timate developed in Figure 5.3 and the coefficients noted in Table 5.1, we use
the basic model to get:
where is the effort applied in person-months, D is the development time in
chronological months, and KLOC is the estimated number of delivered lines of E =
code for the project (express in thousands). The coefficients and and the =
exponents and are given in Table 5.1.
The basic model is extended to consider a set of “cost driver attributes” = 95 person-months
that can be grouped into four major categories: product attributes,
hardware attributes, personnel attributes, and project attributes. Each of the This value is considerably higher than the estimates derived in Section 5.6.
15 attributes in these categories is rated on a six-point scale that ranges from Because the COCOMO model assumes considerably lower levels than
“very low” to “extra high” (in importance or value). Based on the rating, an ef- those noted in Section 5.6, the results are not surprising. To be useful in the
fort multiplier is determined from tables published by Boehm and the context of the example problem, the COCOMO model would have to be recali-
product of effort multipliers results is an effort adjustment factor brated to the local environment.
Typical EAF range from 0.9 to 1.4. To compute project duration, use the above:
The intermediate COCOMO model takes the form:
E= x EAF
=
= 12.3 months
COCOMO model is undergoing revision at the time of this writing. The model will likely
be extended accommodate FP and will be refined based on a larger of The value for project duration enables the planner to determine a recom-
projects. mended number of people, for the project:
PART TWO: MANAGING SOFTWARE PROJECTS 125
CHAPTER 5: SOFTWARE PROJECT PLANNING
estimation model, Putnam and Myers [PUT921 suggest a set of equations de-
rived from the software equation. Minimum development time is defined as:
=
= in months for 6 months
8 people
= in person-months for E 20 person-months
In reality, the planner may decide to only four people and extend the proj-
ect duration Note that in equation is represented in years.
Using equations (5.4) with = 12,000 (recommended value for scientific
software) for the CAD software discussed earlier in this chapter,
5.7.3 The = 8.14
= 12.6 calendar months
The software equation is a multivariabie model that assumes a spe-
cific distribution of effort over the life of a software development project. The = 180 X 0.28 X
model has been derived from productivity data collected for over 4000 con-
temporary software projects. Based on these data, an estimation model of the E = 58 person-months
.
form: The results of the software equation correspond favorably with the estimates
= x x developed in Section 5.6.
where E = effort in person-months or parson-years
= project duration in months or years
= “special skills factor” that increases slowly as “the need for inte-
gration, testing, quality assurance, documentation, and manage- 5.8 THE MAKE-BUY DECISION
ment skills For small programs = 5 to
B = 0.16. For programs greater than 70 B = 0.39. In many software application areas, it is often more cost effective to acquire,
= ‘productivity parameter” that reflects: rather than develop, computer software. Software engineering managers are
faced with a make-buy decision that can be further complicated by a number
. overall maturity and management practices of acquisition options: software may be purchased (or licensed)
!" the extent which good software engineering practices are used “full-experience” or “partial-experience” software components (see Section
!"the level of programming languages used
5.4.2) may be acquired and then modified and integrated to meet specific needs,
or software be by an outside contractor to meet the pur-
!" the state of the software environment
chaser’s specifications.
!" the skills and experience of the software team The involved in the acquisition of software are defined by the
!"the complexity of the application of the-software to be purchased and the end cost. In some cases (e.g.,
cost PC software), it is less expensive to purchase and experiment than con-
Typical values might be = 2000 for development of real-time embedded soft- duct a lengthy evaluation of potential software packages. For more expensive
ware; = 10,000 for telecommunication and systems software; and = 28,000 products, the following guidelines can be applied:
for business systems applications. The productivity parameter can be derived
for local conditions using historical data collected from past development 1. Develop a specification for function and performance of the desired soft-
efforts. ware. Define measurable characteristics whenever possible.
It is important to note that the software equation has two independent pa- 2. Estimate the internal cost to develop and the delivery date.
rameters: an estimate of size (in and an indication of project du- 3a. Select three or four candidate applications that best meet your
ration in calendar months or years. tion.
To simplify the estimation process and use a more common form for their
3b. Select reusable software components that will assist in constructing the
required application.
is important note that the relationship between effort and time is not linear. Therefore, 4. Develop a comparison matrix that presents a head-to-head comparison of
reducing the number of people four would necessarily cause the project to require twice key functions. Alternatively, conduct benchmark tests to compare candi-
much calendar time. See for additional discussion. date software.
126 PART CHAPTER SOFTWARE PROJECT PLANNING 127
5. Evaluate each software package or component based on past product qual- simple (0.301 $380,000
ity, vendor support, product direction, reputation, and so on.
Contact other users of software and ask opinions.
difficult
In the analysis, the make-buy decision is made based on the following
‘conditions: Will the delivery date of the software product be sooner than minor changes
that for internally developed software? (2) Will the cost of acquisition the (0.40)
cost of customization bc less than the cost of developing the software inter-
nally’? Will the cost of outside support (e.g., contract.) be
than the cost of internal support? These conditions apply for each of the
quisition options noted above.
5.8.1 Creating a Decision Tree
The steps described above can be augmented using statistical techniques such
as decision tree analysis For example, Figure 5.6 depicts a decision
tree for a software-based system, In this case, the software engineering or-
ganization can build system X from scratch; reuse existing “partial ex-
perience” components to construct the system; buy an available software
product and modify it to meet local needs; or contract the software devel- FIGURE 5.6. A without changes
opment to an outside vendor. decision tree to
If the system is to be built from scratch, there is a 70 percent probability support the
that the job will be difficult. Using the estimation techniques discussed earlier make-buy
in this chapter, the project planner projects that a difficult development effort decision. with changes
will cost $450,000. A “simple” development effort is estimated to cost $380,000.
The expected value for cost, computed along any branch of the decision tree, is:
expected cost = (path probability), x (estimated path cost), 5.8.2 Outsourcing
where is the decision tree path. For the build path,
Sooner or later, every company that develops computer software asks a funda-
expected 0.30 + 0.70 $42913 mental question: “Is there a way that we can get the software and systems that
we need at a lower price?” The answer to this question is not a simple one, and
Following other paths of the decision tree, the projected costs for reuse,
the emotional discussions that occur in response to the question always lead to
chose, and contract, under a variety of circumstances, are also shown. The ex- a single word: “outsourcing.”
pected costs for these paths are:
In concept, outsourcing is extremely simple. Software engineering activities
expected cost,,,,, = 0.40 + 0.60 10.20 + 0.80 = are contracted to a third party who does the work at lower cost, and hopefully,
higher quality. Software work conducted within a company is reduced to a con-
expected = 0.70 + 0.30 = tract management activity.
Edward discusses the broader implications of the grow-
expected = 0.60 + 0.40 =
ing trend toward outsourcing when he states:
Based on the probability and projected costs that have been noted in Figure
5.6, the lowest expected cost is the buy option. If you have been brought up in a culture that glorifies the American software
It is important to note, however, that many criteria-not just cost-must industry as a world leader, I ask simply that you remember that it was only a
be considered during the decision making process. Availability, experience of few years ago we had the same opinion of our automobile industry. . .
the developer/vendor/contractor, conformance to requirements, local “politics,” development may well move out of the U.S. into software factories
and the likelihood of change are but a few of the criteria that may affect the in a dozen countries whose people are well educated, less expensive, and more
ultimate decision to build, reuse, buy or contract. passionately devoted to quality and productivity.
128 PART TWO: MANAGING SOFTWARE PROJECTS 129
CHAPTER 5: SOFTWARE PROJECT PLANNING
A strong statement! But one that is already becoming a reality, 5.10 SUMMARY
The decision to outsource can be either strategic or tactical. At the strate-
gic level, business managers consider whether a significant portion of all soft- The software project planner must estimate three things before a project be-
ware work can be contracted to others. At the tactical level, a project manager
gins: how long it will take, how much effort will be required, and how many
determines whether part or all of a project can be best accomplished by sub-
people will be involved. In addition, the planner must predict the resources
contracting some portion of the software work. (hardware and software) that will be required and the risk involved.
Regardless of the breadth of focus, the outsourcing decision is often a The statement of scope helps the planner to develop estimates using one or
nancial one. A detailed discussion of the financial analysis of outsourcing is be-
more techniques that fall into two broad categories: decomposition and empiri-
yond the scope of this book and is best to others However,
cal modeling. Decomposition techniques require a delineation of major software
a brief review of the pros and cons of the decision is worthwhile. functions, followed by estimates of either the size or the number of
On the positive cost savings can usually be achieved by reducing the
months required to implement each function. Empirical techniques use empiri-
number of software people and the facilities (e.g., computers, infrastructure)
cally derived expressions for effort and time to predict these project quantities.
that support them. On the negative side, a company loses some control over the
Automated tools can be used to implement a specific empirical model.
software that it needs. Since software is a technology that differentiates its sys- Accurate project estimates generally make use of at least two of the three
tems, services, and products, a company runs the risk of putting the fate of its
techniques noted above. By comparing and reconciling estimates derived using
competitiveness into the hands of a third party.
different techniques, the planner is more likely to derive an accurate estimate.
The trend toward outsourcing will undoubtedly continue. The only way to project estimation can never be an exact science, but a combination of
blunt the trend is to recognize that software work in the twenty-first century
good historical data and systematic techniques can improve estimation accuracy.
will be extremely competitive at all levels. The only way to survive is to become
as competitive as the outsourcing vendors themselves.
REFERENCES
5.9 AUTOMATED ESTIMATION TOOLS Bennatan, E.M., Management: A Practitioner’s Ap-
proach, McGraw-Hill, 1992.
The decomposition techniques and empirical estimation models described in Boehm, B., Software Engineering Economics, Prentice-Hall, 1981.
the preceding sections are available as part of a wide variety of software tools, Boehm, B., Risk Management, IEEE Computer Society Press, 1989.
These automated estimation tools allow the planner to estimate cost and effort Brooks, F., The Mythical Man-Month, Addison-Wesley, 1975.
and to perform “what if” analyses for important project variables such as de- Gause, D.C., and G.M. Weinberg, Exploring Requirements: Quality Before
livery date or staffing. Although many automated estimation tools exist, all ex- Design, Dorset House, 1989.
hibit the same general characteristics and all require one or more of the fol- Hooper, J.W.E., and R.O. Chester, Software Reuse: Guidelines and
lowing data categories: Methods, Plenum Press, 1991.
Mah, M., Quantitative Software Management, Inc., private communica-
tion.
1. A quantitative estimate of project size (e.g., LOC) or functionality (function
Martin, R., “Evaluation of Current Costing Tools,” ACM
point data)
Notes, vol. 13, no. 3, July 1988, pp.
2. Qualitative project characteristics such as complexity, required reliability, Matson, J., B. Barrett, and J. Mellichamp, “Software Development Cost
or business criticality Estimation Using Function Points, IEEE Trans. Software Engineering,
3. Some description of the development staff and/or development environment vol. 20, no. 4, April 1994, pp. 275-287.
Minoli, D., Analyzing McGraw-Hill, 1995.
From these data, the model implemented by the automated estimation tool pro- -Putnam, L., and Myers, Measures for Excellence, Press, 1992.
vides estimates of effort required to complete the project, costs, staff loading, E., Decline and of the American
time duration, and in some cases, development schedule and associated risk. Press, 1992.
An interesting comparison of automated estimation tools has done by
Martin A number of different tools were applied to the same project.
It was not surprising that a relatively large variation in estimated results was PROBLEMS AND POINTS TO PONDER
encountered. More important, the predicted values sometimes were
different than actual values. This reinforces the notion that the output 6.1. Assume that you are the project manager for a company that builds
of estimation tools should be used as one “data point” from which estimates are for consumer products. You have been contracted to build the for a
derived-not as the only for an security Write A of that describes the software.
130 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 5 PROJECT PLANNING 131
Be sure your statement of scope is bounded. If you’re unfamiliar with home contain useful information on software project planning and estimation. Lederer
security systems, do a bit of research before you begin writing. Alternate: and Prasad (“Nine Management Guidelines for Better Cost Estimating,”
Replace the home security system with another problem that is of interest Communications of the ACM, February 1992) provide a collection of useful sta-
to you. tistics that can serve as a guide for better cost estimating.
5.2. Software project complexity is discussed briefly in Section 5.1. Develop a list Putnam and Myer’s detailed treatment of software cost estimating [PUT921
of software (e.g., concurrent operation, output, etc.) and Boehm’s book on software engineering economics describe empir-
that affect the complexity of a project, Prioritize list. ical software estimation models. Both books detailed analysis of data
5.3. Performance is an important consideration during planning. Discuss how per- derived form hundreds of software projects. An excellent book by
formance can be interpreted differently depending upon the software appli- (Controlling Projects, Press, 1982) provides valuable insight
cation area. into the management, measurement, and estimation of software projects. Sneed
6.4.. Do a functional decomposition of the home security system software you de- (Software Engineering Management, Wiley, 1989) and Macro (Software
Engineering: Concepts and Prentice-Hall, 1990) consider soft-
scribed in problem 5.1. Estimate the size of each function in LOC. Assuming
ware project estimation in considerable detail.
that your organization produces 450 with a burdened labor rate of Lines-of-code cost estimation is the most commonly used approach in the
$7000 per person-month, estimate the effort and cost required to build the
industry. However, the impact of the object-oriented paradigm (see Part Four)
software using the LOC-based estimation technique described in Section 5.6.3.
may invalidate some estimation models. and Kidd (Object-Oriented
5.5. Using the 3D function point measure described in Chapter 4, compute the Software Metrics, Prentice-Hall, 1994) consider estimation for object-oriented
of FP for the home security system and derive effort and cost systems.
estimates using the FP-based estimation technique described in Section A new version of the COCOMO model, updated for the can be ob-
6.6. Use the COCOMO model to estimate the home security system software. tained at:
Assume that the basic model is applicable.
5.7. Use the “software equation” to estimate the home security system
Assume that equations are applicable and that = 8000.
5.8. Compare the effort estimates derived in problems 5.4 through 5.7. Develop a sin- Frequently asked questions and a glossary of project management terms
gle estimate% the project using a three-point estimate. What is the standard are addressed at the following sites:
deviation, and how doss it affect your degree of certainty about the estimate?
6.9. Using the results obtained in problem 5.8, determine whether it’s reasonable
to expect that the software can be built within the next 6 months and how
many people would have to be used to get the job done.
6.10. Develop a spreadsheet model that implements one or more of the estimation
techniques described in this A review of software project tools can be obtained at:
6.11. For a project team: Develop a software tool that implements each of the esti-
mation techniques developed in this chapter.
6.12. It seems odd that cost and schedule estimates are developed during software
project planning-before detailed software requirements analysis or design A listing of project management resources can be obtained at:
has been conducted. Why do you think this is done? Are there circumstances
when it should not be done?
6.13. Recompute the expected values noted for the decision tree in Figure 5.6 as-
suming that every branch has a probability. Would this change your A detailed paper and many references for project cost analysis can be acquired
nal decision? from:
6.14. Research the trade literature (e.g., Magazine) for
recent articles on outsourcing. Write a two- or three-page paper describing
you’ve learned.
An up-to-date list of World Wide Web references for software project estimation
FURTHER READINGS AND OTHER INFORMATION SOURCES can be found at:
Books by Bennatan (Software Costing, Prentice-Hall,
and (Cost Estimation for Software Development, Addison-Wesley, 1987)
CHAPTER 6: RISK MANAGEMENT 133
6.1 REACTIVE VS. PROACTIVE RISK STRATEGIES
Reactive risk strategies have been laughingly called the “Indiana Jones school
of risk management” In the movies that carried his name, Indiana
RISK MANAGEMENT
Jones, when faced with overwhelming difficulty, would invariably say, “Don’t
worry, I’ll think of something!” Never worrying about problems until they hap-
pened, Indy would react in some heroic way.
Sadly, the average software project manager is not Indiana Jones and the
members of the software project team are not his trusty sidekicks. Yet, the ma-
jority of software teams rely solely on reactive risk strategies. At best, a reac-
tive strategy monitors the project for likely risks. Resources are set aside to
deal with them, should they become actual problems. More commonly, the soft-
ware team does nothing about risks until something goes wrong. Then, the
into in to problem rapidly. This is of-
ten called “fire fighting mode.” When this fails, “crisis management”
takes over and the project is in real jeopardy.
A considerably more intelligent strategy for risk management is to be
proactive, A proactive strategy begins long before technical work is initiated.
Potential risks are identified, their probability and impact are assessed, and
they are prioritized by importance. Then, the software team establishes a plan
for managing risk. The primary objective is to avoid risk, but because not all
risks can be avoided, the team works to develop a contingency plan that will
enable it to respond in a controlled and effective manner. Throughout the re-
n his hook on risk analysis and management, Robert Charette pro- mainder of this chapter, we discuss a proactive strategy for risk management.
the following conceptual definition of risk:
First, risk concerns future happenings. Today and yesterday are beyond active 6.2 SOFTWARE RISKS
concern, as we are already reaping what was previously by our past ac-
tions. The question is, can we, therefore, by changing actions today, create Although there has been considerable debate about the proper definition for
an opportunity for a different and hopefully better situation for ourselves to- risk, is risk always involves two char-
morrow. This means, second, that risk involves change, such in changes of acteristics
mind, opinion, actions, or places. . risk involves choice, and the un-
certainty that choice itself entails. Thus paradoxically, risk, like death and
!" uncertainty-The event that characterizes the risk may or may not happen;
taxes, is one of the few certainties of life.
i.e., there are no 100% probable risks.’
When risk is considered in the context engineering, three !" risk a reality, unwanted consequences or losses will
conceptual underpinnings are always in evidence. The future is our occur.
what risks might cause the software project to go awry? Change is our
cem-how will changes in customer requirements, development technologies, When risks are analyzed, it is important to quantify the level of uncertainty
target computers, and all other entities connected to the project affect timeli- and the degree of loss associated with each risk. To accomplish this, different
ness and overall success? Last, we must grapple with choices-what methods categories of risks are considered.
and tools should we use, how many people should be involved, how much em- Project risks threaten the project plan. That is, if project risks become real,
phasis on quality is ‘enough?” it, is likely that the project schedule will slip and that costs will increase. Project
Peter once it is futile to try to eliminate risk, risks identify potential budgetary, schedule, personnel (staffing and organiza-
and questionable to try to minimize it, it is essential that the risks taken be tion), resource, customer, and requirements problems and their impact on a soft-
the right risks.” Before we can identify risks” to be taken during a
software project, it is important to identify all risks that are obvious to both
managers and practitioners. ‘A risk that is 100% probable is constraint on the software project
132
134 , PART TWO MANAGING SOFTWARE PROJECTS CHAPTER 6: RISK MANAGEMENT 135
ware project. In Chapter 5, project complexity, size, and the degree of structural One method for identifying risks is to create a risk item checklist. The
uncertainty were also defined as project (and estimation) risk factors. checklist can be used for risk identification and focuses on some subset of
Technical risks threaten the quality and timeliness of the software to be known and predictable risks in the following generic subcategories:
produced. If a technical risk becomes a reality, implementation become dif-
ficult or impossible. Technical risks identify potential design, implementation, !" Product size-risks associated with the overall size of the software to be built
interfacing, verification, and maintenance problems. In addition, specification or modified
ambiguity, technical uncertainty, technical obsolescence, and “leading-edge”
!" Business impact-risks associated with constraints imposed by management
technology are also risk factors. Technical risks occur because the problem is
harder to solve than we thought it would be. or the marketplace
Business risks threaten the viability of the software to be built. Business !" Customer characteristics-risks associated with the sophistication of the
risks often jeopardize the project or the product. Candidates for the top tomer and the developer’s ability to communicate with the customer in a
business risks are building an excellent product or system that no one really timely manner
wants (market building a product that no longer into the overall !" Process definition-risks associated with the degree to which the software
business strategy for the company (strategic risk); building a product that process has been-defined and is followed by the development organization
the sales force doesn’t understand how to sell; losing the support of senior
!" Development enuironment-risks associated with the availability and quality
management due to a change in focus or a change in people (management risk);
of the tools to be used to build the product
and losing budgetary or personnel commitment (budget risks). It is ex-
tremely important to note that simple categorization won’t always work. Some !" Technology to be built-risks associated with the complexity of the system to
risks are simply unpredictable in advance. be built and the “newness” of the technology that is packaged by the system
Another general categorization of risks has been proposed by Charette !" and experience-risks associated with the overall technical and proj-
Known risks are those that can be uncovered after careful evaluation ect experience of the software engineers who will do the work.
of the project plan, the business and technical environment in which the proj-
ect is being developed, and other reliable information sources (e.g., unrealistic The risk item checklist can be organized in different ways. Questions relevant
delivery date, lack of documented requirements or software scope, poor devel- to each of the topics noted above can be answered for each project. The
opment environment). Predictable risks are extrapolated from past project ex- answers to these questions allow the planner to estimate the impact of risk. A
perience (e.g., staff turnover, poor communication with the customer, dilution different risk item checklist format simply lists characteristics that are relevant
of staff effort as ongoing maintenance requests serviced). Unpredictable to each generic subcategory. Finally, a set of “risk components and drivers”
risks are the joker in the deck. They can and do but they are extremely WC881 are listed along with their probability of occurrence. Drivers for per-
difficult to identify in advance. formance, support, cost, and schedule are discussed in answer to later questions.
6.3 RISK IDENTIFICATION Product Size Risks
Risk identification is a systematic attempt to specify threats to the project plan Few managers would debate the following statement: risk
resource etc. By identifying known to product The following risk item checklint iden-
dictable risks, the project manager takes a step toward avoiding them tifies generic risks associated with product (software) size:
when possible and controlling them when necessary.
There are two distinct types of risks for each of the categories that have !" Estimated size of the product in LOC or
been presented in Section 6.2: generic risks and product-specific risks. Generic
risks are a potential threat to every software project. Product-specific can !" Degree of confidence in estimated size estimate?
only be identified by those with a clear understanding of the technology, the !" Estimated size of product in number of programs, files, transactions?
people, and the environment that is specific to the project at hand. To identify !" Percentage deviation in size of product from average for previous
product-specific risks, the project plan and the software statement of scope are !" Size of database created or used by the product?
examined and an answer to the following question is developed: “What special
!" Number of users of the product?
characteristics of this product may threaten our project plan?”
Both generic and product-specific risks should be identified systematically. !" Number of projected changes to the requirements for the product? before de-
Tom Gilb drives this point home when he states: “If you don’t actively livery? after delivery?
attack the risks, they will actively attack you.” !" Amount of reused software?
136 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 6: RISK MANAGEMEM 137
In each case, the information for the product to be developed must be compared would prefer not to be customers at all. Some will happily accept almost any-
to past experience. If a large percentage deviation occurs or if numbers are sim- thing that is delivered and make the very of a poor product. Others will
ilar, but past results were considerably less than satisfactory, risk is high. complain bitterly when quality is lacking; some will show their appreciation
when quality is good; a few will complain no matter what.
Customers also have varied associations with their suppliers. Some know
6.3.2 Business Impact Risks the product and producer well; others may be faceless, communicating with
the producer only by written correspondence and a few hurried telephone
calls.
An engineering at a major software company placed following
framed plaque on his wall: “God grant me brains to be a good project manager Customers often contradictory. want everything yesterday for free.
and the common sense to run like hell whenever marketing sets project dead- Often, the producer is caught among the customers’ own contradictions.
lines!” The marketing department is driven by business considerations, and
business considerations sometimes come into direct conflict with technical re- A “bad” customer can have a profound impact on a software team’s ability to
alities. The following risk item checklist identifies generic risks associated with complete a project on time and within budget. A bad customer represents a sig-
business impact: nificant threat to the project plan and a substantial risk for the project man-
ager. The following risk item checklist identifies generic risks associated with
!" Effect of this product on company revenue? different customers:
!" Visibility of this product to senior management?
!" Reasonableness of delivery deadline? !"Have you worked with the customer in the past?
!" Number of customers who will use this product and the consistency of their !" Does the customer have a solid idea of what is required? Has the customer
needs relative to the product? spent the time to write it down?
!" Number of other products/systems with which this product must be !" Will the customer agree to spend time in formal requirements gathering
erable? meetings (Chapter 11) to identify project scope?
!" Sophistication of end users? !" Is the customer willing to establish rapid communication links with the de-
veloper?
!" Amount and quality of product documentation that must be produced and de-
livered to the customer? !" Is the customer willing to participate in reviews?
!" Governmental constraints on the construction of the product? the customer technically sophisticated in the product area?
!" Costs associated with late delivery? !" Is the customer willing to let your people do their job-that is, will the
customer resist looking over your shoulder during technically detailed
!" Costs associated with a defective product?
work?
!" Does the customer understand the software process?
Each response for the product to be developed must be compared to past expe-
rience. If a large percentage deviation occurs or if numbers are similar, but past
results were considerably less than satisfactory, risk is high. If the answer to any of these questions is ‘no,” further investigation should
undertaken to assess risk potential.
6.3.3 Customer Related Risks
6.3.4 Process Risks
All customers are not created Pressman and discuss
this issue when they state: If the software process (Chapter 2) is ill-defined; if analysis, design, and test-
ing are conducted in an ad hoc fashion; if quality is a concept that everyone
Customers different needs. Some know what they want; others know agrees is important, but no one acts to achieve in any tangible way, the
what they don’t want. Some customers are willing to sweat the details, while project is at risk. The following questions are extracted from a workshop on the
others are satisfied with a vague promises. assessment of software engineering practice developed by R.S. Pressman
Inc. The questions themselves have been adapted the
Customers personalities. Some enjoy being customers-the Engineering Institute software process assessment question-
tension, the negotiation, the psychological rewards of a good product. Others naire.
138 PART TWO. MANAGING SOFTWARE PROJECTS CHAPTER RISK MANAGEMENT 139
!" Are tools used to create software prototypes?
!" Are software tools used to support the testing process?
!" Does your senior management support a written policy statement that em- !" Are software tools used to support the production and management of docu-
phasizes the importance of a standard process for software development? mentation?
!" Has your organization developed a written description of the software process
!" Are quality metrics collected for all software projects?
to be used on this project?
!" Are productivity metrics collected for all software projects?
!" Are staff members “signed up” to the software process as it is documented
and willing to use it?
If a majority of the above questions are answered “no,” software process is weak
!"Is the software process used for other projects? and risk is high.
your organization developed or acquired a series of software engineering
training courses for managers and technical stag?
!" Are published software engineering standards provided for every software 6.3.5 Technology Risk
developer and software manager?
!" Have document outlines and examples been developed for all deliverables de- Pushing the limits of the technology is and exciting. It’s the dream
fined as part of the process? of almost every technical person, because it forces a practitioner to use his or
her skills to the fullest. But it’s also very risky. Murphy’s law seems to hold
!" Are formal technical reviews of the requirements specification, design, and
sway in this part of the development universe, making it extremely difficult to
code conducted regularly?
foresee risks, much less plan for them. The following risk item checklist iden-
!" Are formal technical reviews of test procedures and test cases conducted reg- tifies generic risks associated with the technology to be built:
ularly?
!" Are the results of each formal technical review documented, including errors !" Is the technology to be built new to your organization?
found and resources used? !" Do the customer’s requirements demand the creation of new algorithms or
!" Is there some mechanism for ensuring that work conducted on a project con- input or output technology?
forms with software engineering standards? !"Does the software interface with new or unproven hardware?
!" Is configuration management used to maintain consistency among sys-
!" Does the software to be built interface with vendor supplied software prod-
tem/software requirements, design, code, and test cases? ucts that are unproven?
!" Is a mechanism used for controlling changes to customer requirements that
!"Does the software to be built interface with a database system whose func-
impact the software? tion and performance have not been proven in this application area?
!" Is there a documented statement of work, a software requirements specifica-
!" Is a specialized user interface demanded by product requirements?
tion, and a software development plan for each subcontract?
!" Do requirements for the product demand the creation of program components
!" Is a procedure followed for tracking and reviewing the performance of sub-
that are unlike any previously developed by your organization?
contractors?
!" Do requirements demand the use of new analysis, design, or testing methods?
!" Do requirements demand the use of unconventional software development
methods, such as formal methods, AI-based approaches, and artificial neural
!" Are facilitated application specification techniques used to aid in communi- networks?
cation between the customer and developer? !"Do requirements put excessive performance constraints on the product?
!" Are specific methods used for software analysis? !" Is the customer uncertain that the functionality requested is “doable”?
!"Do you use a specific method for data and architectural design?
!" Is more that SO percent of your code written in a high-order language? If the answer to any of these questions is “yes,” further investigation should be
undertaken to assess risk potential.
!" Are specific conventions for code documentation defined and used?
!"Do you use specific methods for test case design?
!" Are software tools used to support planning and tracking activities? 6.3.6 Development Risks
!" Are configuration management software tools used to control and track
change activity thmughout the software process? If a carpenter were asked to create a piece of furniture with a bent, dull
!" Are tools used to support the software analysis and design process? handsaw, the quality of the end product would be suspect. Inappropriate or
PART TWO. MANAGING SOFTWARE PROJECTS CHAPTER 6: RISK MANAGEMENT 141
effective tools can blunt the efforts of even a skilled practitioner. The software 6.3.8 Risk Components and Drivers
engineering environment supports the project team, the process, and the prod-
uct. But if the environment is flawed, it can be the source of significant risk. The U.S. Air Force has written a pamphlet that contains excellent guide-
The following risk item checklist identifies generic risks associated with the de- lines for software risk identification and abatement. The Air Force approach
velopment environment? requires that the project manager identify the risk drivers that affect
risk components-performance, cost, support, and In the context of this
!" Is a software project management tool available? discussion, the risk components are defined in the following manner:
!" Is a software process management available?
!" Are tools for analysis and design available? !" performance risk-the degree of uncertainty that the product will meet its re-
quirements and be fit for its intended use
!" Do analysis and design tools deliver methods that are appropriate for the
product to be built? . cost risk-the degree of uncertainty that the project budget will be main-
!" Are compilers or code generators available and appropriate for the product
tained
to be built? !" support risk-the degree of uncertainty that the software will be easy to
!" Are testing tools available and appropriate for the product to be built?
adapt, and enhance
!" schedule risk-the degree of uncertainty that the project schedule will be
!" Are software configuration management tools available?
maintained and that the product will be delivered on time
!" Does the environment make use of a database or repository?
!"Are all software tools integrated with one another? The impact of each risk driver on the risk component is divided into one of four
!" Have members of the project team received training in each of the tools? impact categories-negligible, marginal, critical, and catastrophic. Figure 6.1
!" Are local experts available to answer questions about the tools?
indicates the potential consequences of errors (rows labeled 1) or a
failure to achieve a desired outcome (rows labeled The impact category is
!" Is on-line help and documentation for the tools adequate?
chosen based on the characterization that best fits the description in the table.
If a majority of the above questions are answered “no,” the software develop-
ment environment is weak and risk is high.
6.4 RISK PROJECTION
Risk also called risk estimation,attempts to rate each risk in two
6.3.7 Risks Associated with Staff Size and Experience
ways-the likelihood or probability that the risk is real and the consequencea
of the problems associated with the risk, should it occur. The project planner,
Boehm suggests the following questions to assess risks associated along with other managers and technical staff, performs four risk projection ac-
with staff size and experience: tivities: establish a scale that reflects the perceived likelihood of a risk;
the consequences of the risk; estimate the impact of the risk on
!" Are the best people available? the project and the product; and (4) note the overall accuracy of the risk pro-
!" Do the people have the right combination of skills? jection so that there will be no misunderstandings.
!" Are enough people available?
!" Are staff committed for entire duration of the project?
!" Will some project staff be working only part time on this project?
6.4.1 Developing a Risk Table
!" Do staff have the right expectations about the job at hand?
!" Have staff received necessary training? A risk table provides a project manager with a simple technique for risk
!" Will turnover among staff be low enough to allow continuity? The sample risk table is illustrated in Figure 6.2.
A project team begins by listing&risks (no matter how remote) in the first
column of the table. This can be accomplished with the help of the risk item
If the answer to any of these questions is “no,” further investigation should be
undertaken to assess risk potential.
risk table should be implemented a spreadsheet model. enables easy
tion of the entries.
142 PART TWO MANAGING SOFTWARE PROJECTS CHAPTER 6. RISK 143
Risks 1 Probability 1
SUPPORT COST SCHEDULE
Size estimate may be significantly low 60% 2
Larger number of users than planned 30% 3
Failure meet the requirement would Failure in increased costs and schedule Less reuse than planned 70% 2
delays with expected values in excess of
result in mission failure End users resist system BU 40% 3
Delivery deadline will be tightened BU 50% 2
Funding will be lost c u 40% 1
Customer will change requirements 80% 2
performance Technology will not meet expectations TE 30% 1
I I
Lack of training on tools DE 80% 3
Failure to meet the requirement would Failure results in operational delays
degrade system performance to point increased costs with expected value of Staff inexperienced ST 30% 2
where mission is to Staff turnover will be high ST 60% 2
.
Some reduction in Minor delays Some shortage of Possible slippage in
2 technical software financial delivery date .
possible overruns
, Failure to would impacts.
result in degradation of with of $1
Impact values:
to small Responsive Sufficient Realistic, achievable
MARGINAL 1
reduction in schedule
technical 2 critical
performance
I I 3 marginal
Failure to meet the requirement would Error results in minor schedule 4 negligible
1 create inconvenience or nonoperational impact with expected value of less than
impact FIGURE 6.2. Sample risk table prior to sorting.
No reduction in Possible budget Early achievable
2 technical underrun delivery date
Once the first four columns of the risk table have been completed, the table
is sorted by probability and by impact. High-probability, high-impact risks per-
Note: The potential consequence of undetected software or faults. colate to the top of the table, and low-probability risks drop to the bottom. This
The potential consequence if the desired outcome is not achieved. accomplishes first-order risk prioritization.
The project manager studies the resultant sorted table and defines a cut-off
FIGURE 6.1. Impact assessment line. The cut-off line (drawn horizontally at some point in the table) implies that
only risks which lie above the line will be given further attention. Risks that fall
below the line are re-evaluated to accomplish second-order prioritization.
checklists presented in Section 6.3. Each risk is categorized in the second col- Risk impact and probability have a distinct influence on management con-
umn (e.g., PS implies a project size risk, BU implies a business risk). The prob- cern (Figure 6.3). A risk factor that has a high impact but a very low
ability of occurrence of each risk is entered in the of the table. The bility of occurrence should not absorb a significant amount of management
probability value for each risk can be estimated by team members individually. time. However, high-impact risks with moderate to high probability and
Individual values are averaged develop a single consensus probability. Next impact risks with high probability should be carried forward into the manage-
the impact of each risk is assessed. Each risk component is assessed using the ment steps that follow.
characterization presented in Figure 6.1, and an impact category is determined. All risks that lie above the cut-off line must be managed. The column la-
The categories for each of the four risk components-performance, support, cost, beled RMMM contains a pointer into a Risk Mitigation, Monitoring and
and schedule-are averaged* to determine an overall impact value. Management Plan d&eloped for all risks that lie above cut-off. The RMMM
Plan is discussed in Section 6.6.
Risk probability can be determined by making individual estimates and
weighted average can be if one component has more significance for the project. then developing a eingle consensus value. Although that approach workable,
144 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 6: RISK MANAGEMENT 145
1. Determine the average probability of occurrence value for each risk com-
very high ponent.
2. Using Figure 6.1, determine the impact for each component based on the
criteria shown.
3. Complete the risk table and analyze the results as described in the pre-
ceding sections.
impact The risk projection and analysis techniques described in Sections 6.4.1 and
6.4.2 are applied iteratively as the software project proceeds. The project team
should revisit the risk table at regular intervals, re-evaluating each risk to de-
termine when new circumstances cause its probability and impact to change.
high
As a consequence of this activity, it may be necessary to add new risks to the
table, remove some risks that are no longer relevant, and change the relative
management
positioning of still others.
concern
6.4.3 Risk Assessment
At this point in the risk management process, we have established a set of
of occurrence triplets of the form
FIGURE 6.3.
Risk and manage-
ment concern. where is risk, is the likelihood (probability) of the risk, and is the impact
of the risk. During risk assessment, we further examine the accuracy of the es-
timates that were made during attempt to prioritize the risks
more sophisticated techniques for determining risk probability have been de- that have been uncovered, and begin thinking about ways to control and/or
veloped Risk drivers can be assessed on a qualitative probability scale avert risks that are likely to occur.
that has the, following values: impossible, improbable, probable, and frequent. For assessment to be useful, a risk referent must be
Mathematical probability can then be associated with each qualitative value lined. For most software projects, the risk components discussed
(e.g., a probability of 0.7 to 1.0 implies a highly probable risk). performance, cost, support, and schedule-also represent risk referent levels;
That is, there is a level for performance degradation, cost overrun, support
difficulty, or schedule slippage (or any combination of the four) that will
cause project to be terminated. If a combination of risks create problems
6.4.2 Assessing Risk Impact that cause one or more of these referent levels to be exceeded, work will stop.
In the context of software risk analysis, a risk referent level has a single
Three factors affect the consequences that are likely if a risk does occur: its na- point, called the referent point or break point, at which the decision to pro-
ture, its scope, and its timing. The of the risk indicates the problems ceed with the project or terminate it (problems are just too great) are equally
that are likely if it occurs. For example, a poorly defined external interface to acceptable.
customer hardware technical risk) will preclude early design and testing and Figure represents this situation graphically. If a combination of risks
will likely lead to system integration problems late in a project. The scope of a leads to problems that cause cost and schedule overruns, there will be a level,
risk combines the severity (just how serious is it?) with its overall distribution represented by the curve in the figure, that (when exceeded) will cause project
(how much of the project will be affected or how many customers are harmed?). termination (the shaded region). At a referent point, the decisions to proceed
Finally, the of a risk considers when and for how long the impact will or to terminate are equally weighted.
be felt. In most cases, a project manager might want the “bad news” to occur In reality, the referent level can rarely be represented as a smooth line on
as soon as possible, but in some cases, the longer the delay, the better. a graph. In most cases it is a region in which there are areas of uncertainty
Returning once more to the risk analysis approach proposed by the U.S. Air to predict a management decision based on the combination of
Force the following steps are recommended to determine the overall referent values is often impossible).
consequences of a risk: Therefore, during risk assessment, we perform the following steps:
PART MANAGING PROJECTS CHAPTER RISK MANAGEMENT 147
To mitigate this risk, project management must develop a strategy for re-
ducing turnover. Among the possible steps to be taken are these:
!" meet with current staff to determine causes for turnover (e.g., poor working
referent point (cost value, time value) conditions, low pay, competitive job market)
!" act to mitigate those causes that are under management control before the
project termination will occur project starts
!"once project commences, assume will and develop techniques
to ensure continuity when people leave
!" about activity
is widely dispersed
!"define documentation standards and establish mechanisms to be sure that
documents are developed in a timely manner
!" conduct peer reviews of all work so that more than one person is familiar
FIGURE 6.4. with the work
Risk referent I I
!" define a backup member for every critical technologist
level. projected cost overrun
As the project proceeds, risk monitoring activities commence. The project
1. define the risk referent levels for the project manager monitors factors that may provide an indication of whether the risk
2. attempt to develop a relationship between each and each of the is becoming more or less likely. In the case of high staff turnover, the following
factors can be monitored:
referent levels
3. predict the set of referent points that define a region of termination, !" general attitude of team members based on project pressures
bounded by a curve or areas of uncertainty
!" the degree to which the team has jelled
4 . try to predict how compound combinations of risks will affect a referent
!" interpersonal relationships among team members
level
!"potentialgroblems with compensation and benefits
A detailed discussion is best left to books that are dedicated to risk analysis !" the availability of jobs within the company and outside it
(e.g.,
In addition to monitoring the factors noted above, the project manager
should also monitor the effectiveness of risk mitigation steps. For example, a
6.5 RISK MONITORING, AND MANAGEMENT risk step ubove culled for the definition
standards and mechanisms to be sure that documents are developed in a
All of the risk analysis activities presented to this point have a single timely manner.” This is one mechanism for ensuring continuity, should a crit-
assist the project team in developing a strategy for dealing with risk. An ef- ical individual leave the project. The project manager should monitor docu-
fective strategy must consider three issues: ments carefully to ensure that each can stand on its own and that each im-
parts information that would be necessary if a newcomer were forced to join
!" risk avoidance, the project.
Risk management and contingency planning assumes that mitigation ef-
monitoring, and
forts have failed and that the risk has become a reality. Continuing the exam-
!" risk management and contingency planning. ple, suppose that the project is well underway and a number of people an-
nounce that they will be leaving. If the mitigation strategy has been followed,
If a software team adopts a proactive approach to risk, avoidance is always the backup is available, information is documented, and knowledge has been dis-
best strategy. This is achieved by developing a plan for risk mitigation. For ex- persed across the team. In addition, the project manager may temporarily re-
ample, assume that high staff turnover is noted as a project risk, Based on focus resources (and readjust the project schedule) to those functions that are
past history and management intuition, the likelihood, of high turnover is fully staffed, enabling newcomers who must be added to the team to “get up to
estimated to be 0.70 percent, rather high) and the impact, is projected speed.” Those individuals who are leaving are asked to stop all work and spend
to have a critical impact on project cost and schedule. their last weeks in “knowledge transfer mode.” This might include video-based
148 PART MANAGING SOFTWARE PROJECTS 149
CHAPTER 6: RISK MANAGEMENT
knowledge capture, the development of “commentary documents” and/or meet- 6.7 THE
ing with other team members who will remain on the project.
It is important to note that RMMM steps incur additional project cost. A risk management strategy can be included in the project plan or the
For example, spending the time to “back up” every critical technologist costs risk management steps can be organized into a separate Risk Mitigation,
money. Part of risk management, therefore is to evaluate when the benefits Monitoring, and Management Plan). The RMMM Plan documents
accrued by the RMMM steps are outweighed by the costs associated with im- all work performed as part of risk analysis and is used by the project manager
plementing them. In essence, the project planner performs a classic as part of the overall Project Plan. An outline for the RMMM Plan follows.
benefit analysis. If risk aversion steps for high turnover will increase project
costs and duration by an estimated 15 percent, but the predominant cost fac-
I. Introduction
tor is “backup,” management may decide not to implement this step. On the
1. Scope and Purpose of Document=’
other hand if the risk aversion steps are projected to increase costs by 5 per-
2. Overview of major risks
cent and duration by only 3 percent, management will likely put all into
3. Responsibilities
place.
a. Management
For a large project, 30 or 40 risks may be identified. If between three and b. Technical staff
seven risk management steps are identified for each, risk management may be-
II. Project Risk Table
come a project in itself! For this reason, we adapt the Pareto 80-20 rule to soft-
1. Description of all risks above cut-off
ware risk. Experience indicates that 80 percent of the overall project risk (i.e.,
2. Factors influencing probability and impact
80 percent of the potential for project failure) can be accounted for by only 20
III. Risk Mitigation, Monitoring, Management
percent of the identified risks. The work performed during earlier risk analy-
n. Risk
sis steps will help the planner to determine which of the risks reside in that
a. Mitigation
20 percent. For this reason, some of the risks identified, assessed, and projected
i. General strategy
may not make it into the RMMM plan-they don’t comprise the critical 20 per-
ii. Specific steps to mitigate the risk
cent (the risks project priority).
b. Monitoring
i. Factors to be monitored
ii. Monitoring approach
6.6 SAFETY RISKS AND HAZARDS c. Management
i. Contingency plan
ii. Special considerations
Risk is not limited to the software project itself. Risks can occur after the soft-
ware has been successfully developed and delivered to the customer. These IV. RMMM Plan Iteration Schedule
V. Summary
risks are typically associated with the consequences of software failure in the
Although the probability of failure of a well-engineered system is small, an Once the RMMM Plan has been developed and the project has begun, risk
undetected fault in a computer-based control or monitoring system could result mitigation and monitoring steps commence. As we have already discussed, risk
in enormous economic damage, or worse, significant human injury or loss of mitigation is a problem avoidance activity. Risk monitoring is a project track-
life. But the cost and functional benefits of computer-based control and moni- ing activity with three primary objectives: (1) to assess whether a predicted
toring often outweigh the risk. Today, computer hardware and software are risk does, in fact, occur; (2) to ensure that risk aversion steps defined for the
used regularly to control safety-critical systems. risk are being properly applied; and (3) to collect information that can be used
When software is used as part of the control system, complexity can in- for future risk analysis. In many cases, the problems that occur during a proj-
crease by an order of magnitude or more. Subtle design flaws induced by hu- ect can be traced to more than one risk. Another job of risk monitoring is
man error--something that can be and in attempt to determine the “origin” (what risk or risks caused which problems)
based conventional controls-become much more difficult to uncover when throughout the project.
software is used.
Software safety and hazard analysis are software quality assurance activ-
ities (Chapter that focus on the identification and assessment of potential 6.8 SUMMARY
hazards that may impact software negatively and cause an entire system to
fail. If hazards can be identified early in the software engineering process, soft- Whenever a lot is riding on a software project, common sense dictates risk
ware design features can be specified that will either eliminate or control po- analysis. And yet, most software project managers do it informally and super-
tential ficially, if they do it at all. The time spent identifying, analyzing, and
150 PART TWO SOFTWARE PROJECTS CHAPTER 6: RISK MANAGEMENT 151
ing risk pays itself back in many ways: less upheaval during the project; a then allows the user to do a wide range of edits to the digitized video. The re-
greater ability to track and control a project; and the confidence that comes sult can then be output to tape. Do a small amount of research on systems of
with planning for problems before they occur. this type, and then make a list of technology risks that you would face as you
Risk analysis can absorb a significant amount of project planning effort. begin a project to build the video-editing system.
Identification, projection, assessment, management, and monitoring all take 6.6. You’re the project manager for a major software company. You’ve been asked
time. But the effort is worth it. To quote Sun Tzu, a Chinese general who lived to lead a team that’s developing “next generation” word-processing software
2500 years ago, “If you know the enemy and know yourself, you need not fear (see Section 3.3.2 for a brief description). Create a risk table for the project.
the result of a hundred battles.” For the software project manager, the enemy 6.6. Describe the difference between risk components and risk drivers.
is risk. 6.7. Develop a weighting scheme for project risk drivers.
6.8. Develop a risk mitigation strategy and specific risk mitigation activities for
three of the risks noted in Figure 6.2.
REFERENCES 6.9. Develop a risk monitoring strategy and specific risk monitoring activities for
three of the risks noted in Figure 6.2. Be sure to identify the factors that
Software Abatement, Pamphlet U.S. Air Force, be monitoring to determine whether the risk is becoming more or less likely.
September 30, 1988. 6.10. Develop a risk management strategy and specific risk management activities
Boehm, Risk IEEE Computer Society Press, for three of the risks noted in 6.2.
1989. 6.11. Can you think of a situation in which a high-probability, high-impact risk
Charette, R.N., Software Engineering Risk Analysis and Management, would not be considered as part of your RMMM Plan?
1989. 6.12. Referring to the risk referent shown on Figure 6.4, would the curve always
Charette, R.N., “Building Bridges over Intelligent Rivers,” American
have the symmetric arc shown, or would there be situations in which the
Programmer, vol. 5, no. 7, September 1992, pp. 2-9. curve would be more distorted? If so, suggest a scenario in which this might
I?, Management, W. Heinemann, Ltd., 1975.
happen.
T., Principles of Software Engineering Management,
Wesley, 1988. 6.13. Do some research of software safety issues and write a brief paper on the sub-
Higuera, “Team Risk Management,” U.S. Dept. of ject. See as a starting point.
Defense, January 1995, pp. 6.14. Describe five software application areas in which software safety and hazard
Leveson, N.G., System and Computers, Addison-Wesley, analysis would be a major concern.
1995.
D.L., A.J. van Schouwen, and S.P. Kwan, “Evaluation of Safety
Critical Software,” vol. 33, no. 6, June 1990, pp. 636-648. FURTHER READINGS AND OTHER INFORMATION SOURCES
Pressman, R.S., and S.R. Software Shock, Dorset House, 1991.
Software Process Assessment Workshop, R.S. Pressman Associates, Capers Jones (Assessment and Control of Software Risks, Prentice-Hall, 1994)
Inc., Orange, CT, 1995. presents a detailed discussion of software risks that includes data collected
Rowe, W.D., An Anatomy of Risk, Robert E. Publishing Co., from hundreds of software projects. Jones defines 60 risk factors that can af-
Malabar, FL, 1988. fect the outcome of software projects. Boehm suggests excellent ques-
R.,“The Indiana Jones School of Risk tionnaire and checklist formats that can prove invaluable in identifying risk.
Programmer, vol. 5, no. 7, 1992, pp. Charette presents a detailed treatment of the mechanics of risk analy-
sis, calling on probability theory and statistical techniques to analyze risks. In
a companion volume, Charette (Application Strategies for Risk Analysis,
PROBLEMS AND POINTS TO PONDER McGraw-Hill, discusses risk in the context of both system and software
engineering and defines pragmatic strategies for risk management.,
A useful snapshot of risk assessment has written by (Practical
6.1. Provide five examples from other fields that illustrate the problems associ- Risk Assessment for Project Management, Wiley, 1995). His abbreviated treat-
ated with a reactive risk strategy. ment provides a good introduction to the subject. Karolak (Software Engineering
6.2. Describe the difference between “known risks” and “predictable risks.” Risk Management, IEEE Computer Society Press, 1996) presents a guidebook
6.3. Add three additional questions or topics to each of the risk item checklists that introduces an easy-to-use risk analysis model. An entire issue
presented in this chapter. Programmer magazine (March 1995) was dedicated to risk management.
6.4. You’ve been asked to build software to support a low-cost video-editing sys- Air Force Systems Command Pamphlet AFSCP 800-45 describes
tem. The system accepts video tape as input, stores the video on disk, and risk identification and reduction techniques. Gilb presents a set of
PART TWO: MANAGING SOFTWARE PROJECTS
“principles” (often amusing and frequently profound) that can serve as a worth-
while guide for risk management. Every issue of the ACM Engineering
Notes publishes a section entitled “Risks to the Public” (editor, PG. Neumann).
If you want the latest and best software horror stories, this is the place to go.
A risk factors chart (implemented as a spreadsheet model) is available
PROJECT SCHEDULING
from Teraquest Metrics (for information via Internet: The
is a source of discussion and commentary
The on Risks to the Public Web site discusses computer and soft-
AND TRACKING
ware risks and/or methods for managing them:
An extensive set of pointers for decision/risk analysis can be obtained at:
Riskworld is an on-line publication “providing news and information on the iden-
tification, critical analysis, and management of risks” and can be obtained at:
A good paper on risk and analysis and pointers to a number of excellent risk
bibliographies can be obtained at: n the late a bright-eyed young engineer1 was chosen to “write” a com-
puter program for an automated manufacturing application. The reason for
his selection was simple. He was the only person in his technical group who
had attended a computer programming seminar. He knew the in’s and out’s of
The DOE Risk Management Quarterly (an on-line publication), although not assembler language and hut nothing about software engineering and
dedicated to software related risks, contains useful articles and pointers: even less about project scheduling and tracking.
His boss gave him the appropriate manuals and a verbal description of
what hnd to be done. He was informed that the project must be completed in
two months.
He read the manuals, considered his approach, and began writing code.
An up-to-date list of World Wide Web references that are relevant to software two weeks. the boss called him into his office and asked how things were going.
risks can be found at: “Really great,” said the young engineer with youthful enthusiasm, “This
was much simpler than I thought. I’m probably close to 75 percent finished.”
The boss smiled. “That’s really terrific,” he said. He then told the young en-
gineer to keep up the good work and plan to meet again in a week’s time.
A week later the boss called the engineer into his office and asked, ‘Where
are we?”
“Everything’s going well,” said the youngster, “but I’ve run into a few small
snags. I’ll get them ironed out and be back on track soon.”
“How does the deadline look?” the boss asked.
“No problem,” said the engineer, “I’m close to 90 percent complete.”
If you’ve been working in the software world for more than a few years, you
can finish the story. It’ll come as no surprise that the young engineer stayed 90
‘If you’re wondering whether this story is autobiographical, it is!
154 PART MANAGING SOFTWARE PROJECTS CHAPTER 7. PROJECT SCHEDULING AND TRACKING 155
percent complete for the entire project duration and only finished requested, will require 14 calendar months to create with available staff. How
help of others) one month late. does the project manager proceed?
This story has been repeated tens of thousands of times by software de- is unrealistic to march into the customer’s this case the likely
velopers during the past three decades. The big question is customer is marketing/sales) and demand that the delivery date be changed.
External market pressures have dictated the date, and the product must be re-
leased. It is equally foolhardy to refuse to undertake the work (from a career
7.1 BASIC CONCEPTS standpoint). So, what to do?
The following steps are recommended in this situation:
Although there are many reasons why software is delivered late, most can be
1. Perform a detailed estimate using data from past projects. Determine the
traced to one or more of the following root causes:
estimated effort and duration for the project.
!"an unrealistic deadline established by someone outside the software engi- 2. Using an incremental process model (Chapter develop a development
neering group and forced on managers and practitioners within the group strategy that will deliver critical functionality by the imposed deadline, but
delay other functionality until later. Document the plan.
!" changing customer requirements that are not reflected in schedule changes
3. Meet with the customer and (using the detailed estimate), explain why the
!" an honest underestimate of the amount of effort and/or the number of re-
imposed deadline is unrealistic. Be certain to note that all estimates are
sources that will be required to do the job based on performance on past projects. Also be certain to indicate the per-
!" predictable and/or unpredictable risks that were not considered when the centage improvement that would be required to achieve the deadline as it
project commenced currently The following comment is appropriate:
!" technical difficulties that could not have been foreseen in advance
!" human difficulties that could not have been foreseen in advance
“I think we may have a probbm with the delivery date for the XYZ con-
troller software. I’ve given each of you an abbreviated breakdown of pro-
!" miscommunication among project staff that results in delays duction rates for past projects and an estimate thnt we’ve done a number
!" a failure by project management to recognize that the project is falling be- of different ways. You’ll note that I’ve assumed a 20 percent improvement
hind schedule and a lack of action to correct the problem in past production rates, but we still get a delivery date that’s 14 calendar
months rather than 9 months away.”
Aggressive (read “unrealistic”) deadlines are a fact of life in the software 4. Offer the incremental development strategy as an alternative.
business. Sometimes such deadlines are demanded for reasons that are le-
gitimate from the point of view of the person who sets the deadline, but com- “We have a few options, and I’d like you to make a decision based on
mon sense says that legitimacy must also be perceived by the people doing them. First, we can increase the budget and bring on additional resources
the work. so that we’ll have a shot at getting this job done in nine months, But un-
derstand that this will increase risk of poor quality due to the tight
Second, we can remove a number of the software functions and ca-
7.1.1 on “lateness” pabilities that you’re requesting. This will make the preliminary version of
the product somewhat less functional, but we can announce all functional-
Napoleon once said: commander in chief who undertakes to carry out a ity and then deliver over the 14 month period. Third, we can dispense with
plan which he considers defective is at fault; he must put forth his reasons, in- reality and wish the project complete in 9 months. We’ll wind up with noth-
sist on the plan being changed, and finally tender his resignation rather than ing that can be delivered to a customer. The third option, I hope you’ll
be the instrument of his army’s downfall.” Strong words that many software agree, is unacceptable. Past history and our best estimates say that it is
project managers should ponder. unrealistic and a recipe for disaster.”
The estimation and risk analysis activities discussed in Chapters 5 and 6,
and the scheduling techniques described in this chapter, are often implemented There will be some grumbling, but if solid estimates based on good histor-
under the constraint of a defined deadline. If best estimates indicate that the ical data are presented, it’s likely that negotiated versions of either option 1 or
in a project manager should “protect his or her will
from lend] roflcct tha pressure back its
inators”
To illustrate, assume that a software development group has asked to the percentage improvement is 10 to 25 percent, it may actually possible get the job
build a real-time controller for a medical diagnostic instrument that is to be done. But likely. the percentage improvement in performance will be greater than
introduced to the market in 9 months. After careful estimation and risk analy- 50 percent. Thin unrealistic expectation.
sis, the software project manager comes to the conclusion that the software, as might also add that adding people will not reduce calendar time proportionally.
156 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 7: PROJECT SCHEDULING AND TRACKING 157
7.1.2 Basic Pririciples Time allocation. Each task to be scheduled must be allocated some
number of work units (e.g., person-days of effort). In addition, each task
must be assigned a start date and a completion date that are functions of
Fred Brooks, the well-known author of Mythical Man-Month was
the interdependencies and whether work will be conducted on a full-time
once asked how software projects fall behind schedule. His response was as
or part-time basis.
simple as it was profound: “One day at a time.”
The reality of a technical project (whether it involves building a hydro- Effort Validation. Every project has a defined number of staff members.
electric plant or developing an operating system) is that hundreds of small As time allocation occurs, the project manager must ensure that no more
tasks must occur to accomplish a larger goal. Some of these tasks lie outside than the allocated number of people have been allocated at any given time.
the mainstream and may be completed without worry about impact on proj- For example, consider a project that has three assigned staff members (e.g.,
ect completion date. Other tasks lie on the “critical If these “critical” three person-days are available per day of assigned effort”). On a given day,
tasks fall behind schedule, the completion date of the entire project is put into seven concurrent tasks must be accomplished. Each task requires 0.50 per-
jeopardy. son of effort. More effort been allocated than there are people to
The project manager’s objective is to define all project tasks, identify the do the-work.
ones that are critical, and then track their progress to ensure that delay is Defined responsibilities. Every task that is scheduled should be as-
“one day at a time.” To accomplish this, the manager must have a signed to a specific team member.
schedule that has been defined at a degree of resolution that enables the man- D e f i n e d o u t c o m e s . Every task that is scheduled should have a defined
ager to monitor progress and control the project. outcome. For software projects, the outcome is normally a work product
project scheduling an activity that estimated effort (e.g., the design of a module) or a part of a work product. Work products
across the planned project duration by allocating the effort to specific software are often combined in
engineering tasks. It is important to note, however, that the schedule evolves
D e f i n e d m i l e s t o n e s . Every task or group of tasks should be associated
over time. During early stages of project planning, a macroscopic schedule is
with a project milestone. A milestone is accomplished when one or more
developed. This type of schedule identifies all major software engineering ac-
work products have been reviewed for quality (Chapter 8) and have been
tivities and the product functions to which they are applied. As the project gets
approved.
under way, each entry on the macroscopic schedule is refined into a’detailed
schedule. Here, specific software tasks (required to accomplish an activity) are
identified and scheduled. Each of the above principles is applied as the project schedule evolves.
Scheduling for software development projects can be viewed’ from two
rather different perspectives. In the first, an end date for release of a
based system has already (and irrevocably) been established. The software or- 7.2 THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT
ganization is constrained to distribute effort within the prescribed time frame.
The second view of that rough chronological In a software development project a single can analyze require-
bounds have discussed but that end date is set by engi- ments, perform design, generate code, and conduct tests. As the size of a project
neering organization. Effort is distributed to make best use of resources, and increases, more people must become involved. (We can rarely afford the luxury
an end date is defined after careful analysis of the software. Unfortunately, the of approaching a ten person-year effort with one person working for ten years!)
first situation is encountered far more frequently than the second. There is a common myth (discussed in Chapter that is still believed by
Like all other areas of software engineering, a number of basic principles many managers who are responsible for software development effort: “If we fall
guide software project scheduling: schedule, we can always add more programmers and catch up later in
the project.” Unfortunately, adding people late in a project often has a disrup-
C o m p a r t m e n t a l i z a t i o n . The project must be compartmentalized into a tive effect, causing schedules to slip even further. People who are added must
of activities To accomplish the system, and people who teach them are the same people who were
ization, both the product the process are decomposed (Chapter doing the work. While they are teaching, no work is done and the project falls
Interdependency. The interdependencies of each behind.
activity or task must be Some must occur in In addition to the time it to learn system, involving more people
others can occur in parallel. Some cannot commence until the the number of communication paths and the complexity of
work product produced by another is available. Other activities occur
independently.
The critical path will discussed later in this
158 PART SOFTWARE PROJECTS CHAPTER 7. PROJECT SCHEDULING AND TRACKING 159
nication throughout a project. Although communication is absolutely essential where is development effort in person-months; P is a productivity parameter
to successful software development, every new communication path requires that reflects a variety of factors that lead to high-quality software engineering
additional effort and therefore additional time. work (typical values for P range between 2,000 and 28,000); is a special skills
factor that ranges between 0.16 and 0.39 and is a function of the size of the
be produced; and t is the project duration in calendar months.
Rearranging the software equation (above), we arrive at an expression for
7.2.1 An development effort E:
=
Consider four software engineers, each capable of producing 5000
when working on an individual project. When these four engineers are placed where is the expended (in person-years) over the entire life cycle for
on a team project, six potential paths possible. Each com- development and maintenance, and is the development time in years.
munication path requires time that could be developing soft- The equation for development effort can be related to development cost by the
ware. We shall assume that team productivity (when measured in will be inclusion of a burdened labor rate factor ($/person-year).
reduced by 250 for each communication path, due to the overhead This leads to some interesting results. Consider a complex, real-time soft-
associated with communication. Therefore, team productivity is 20,000 X ware project estimated at 33,000 LOC, 12 person-years of effort. If eight peo-
6) = 18,500 percent less than what we might expect.” ple are assigned to the project team, the project can be completed in approxi-
The one-year project on which the above team is working falls behind mately 1.3 years. If, however, we extend the end date to 1.75 years, the highly
schedule and with two months remaining, two additional people are added to nonlinear nature of the model described in equation (7.1) yields:
the team. The number of communication paths escalates to 14. The productiv-
= 3.8 person-years.
ity input of the new staff is the equivalent of 840 x 2 1680 LOC for the two
months remaining before delivery. Team productivity now is 20,000 + 1680 This implies that by extending the end date six months, we can reduce the
(250 X 14) = 18,180 number of people from eight to four! The validity of such results is open to de-
Although the above example is a gross oversimplification of real world cir- bate, but the is clear: Benefit can be gained by using fewer people
cumstances, it does serve to illustrate another key point: The relationship be- over a somewhat longer time span to accomplish the same objective.
tween the number of people working on a software project and overall produc-
tivity is not linear.
Based on the people-work relationship, are teams counterproductive? The 7.2.3 Effort Distribution
answer is an emphatic “no,” if communication serves to improve software qual-
ity. formal reviews (see Chapter conducted by software en-
can to hotter analysis design, and more important, Each of the softwareproject estimation in Chapter 5 leads
can reduce the number of errors that go undetected until testing (thereby re- to of (or person-years) required to complete software
ducing testing effort). Hence, productivity and quality, when measured by time development. A recommended distribution of effort across the definition and
to project completion and customer satisfaction, can actually improve. development phases is often referred to as the 40-20-40 Forty percent
or more of all effort is allocated to front-end analysis and design tasks. A sim-
ilar percentage is applied to back-end testing. You can correctlyinfer that cod-
ing (20 percent of effort) is de-emphasized.
7.2.2 An Empirical Relationship This effort distribution should be used as a guideline only. The character-
istics of each project dictate the distribution of effort. Effort expended on proj-
Recalling the “software equation” [PUT921 that was introduced in Chapter 5, ect planning rarely accounts for more than 2 or 3 percent of effort, unless the
we can demonstrate the highly nonlinear relationship between chronological plan commits an organization to large expenditures with high risk. Re-
quirements analysis may comprise 10 to 25 percent of project effort. Effort ex-
time to complete a project and human effort applied to the project. The num-
ber of delivered lines of code (source statements), are related to effort and pended on analysis or prototyping should increase in direct proportion with
development time by the equation: project size and complexity. A range of 20 to 25 percent of effort is normally ap-
plied to software design. Time expended for design review and subsequent it-
=Px eration must also be considered.
is possible pose a Communication, if it is effective, can enhance the ‘Today, than 40 percent of all project effort often recommended for analysis and de-
quality of the work being performed, thereby reducing the amount of rework and increasing sign tasks for large development projects. Hence, the name ‘40-20-40” no longer
the individual productivity of team members. jury is still out! plies in strict sense.
160 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 7: PROJECT SCHEDULING AND TRACKING 161
Because of the effort applied to software design, code should follow with 7.3.1 Degree of Rigor
relatively little A range of 15 to 20 percent of overall effort can be
achieved. Testing and subsequent debugging can account for 30 to 40 percent Even for a project of a particular type, the degree of rigor with which the soft-
of software development effort. The criticality of the software often dictates the ware process is applied may vary significantly. The degree of rigor is a function
amount of testing that is required. If software is human-rated (i.e., software
of many project characteristics. As an example, small, non-business-critical
failure can result in loss of life), even higher percentages may be considered. projects can generally be addressed with somewhat less rigor than large, com-
plex, business-critical applications. It should be noted, however, that proj-
ects must be conducted in a manner that results in timely, high-quality deliv-
7.3 DEFINING A TASK SET FOR THE PROJECT erables. Four different degrees of rigor can be defined:
A number of different process models were described in Chapter 2. These mod- Casual. All process framework activities (Chapter are applied, but
els offer different paradigms for software development. Regardless of whether only a minimum task set is required. In general, umbrella tasks will be
a software team chooses a linear sequential paradigm, an iterative paradigm, minimized and documentation requirements will be reduced. All basic prin-
an evolutionary paradigm, a concurrent paradigm, or some permutation, the ciples of software engineering are still applicable.
process model is populated by a set of tasks that enable the software team to Structured. The process framework will be applied for this project.
define, develop, and ultimately maintain computer software. Framework activities and related tasks appropriate to the project type will
There is no single set of tasks that is appropriate for all projects. The set be applied and umbrella activities necessary to ensure high quality will be
of tasks that would be appropriate for a large, complex system would likely be applied. SQA, SCM, documentation, and measurement tasks will be con-
perceived as overkill for a small, relatively simple project. Therefore, an effec- ducted in a streamlined manner.
tive software process should define a collection of task sets, each designed to
meet the needs of different types of projects. S t r i c t . The full process will be applied for this-project with a degree of
discipline that will ensure high quality. All umbrella activities will be ap-
A task set is a collection of engineering work tasks, milestones,
and deliverables that must be accomplished to complete a particular project. plied, and robust documentation will be produced.
The task set to be chosen must provide enough discipline to achieve high soft- Q u i c k R e a c t i o n . The process framework will be applied for this project,
ware quality. But at the same time, it must not burden the project team with but because of an emergency only those tasks essential to main-
unnecessary work. taining good quality will be applied. “Back-filling” (i.e., developing a com-
Task sets are designed to accommodate different types of projects and dif- plete set of documentation, conducting additional reviews) will be accom-
ferent degrees of rigor. Although it is difficult to develop a comprehensive tax- plished after the application/product is delivered to the customer.
onomy, most software organizations encounter of the following
The project manager must develop a systematic approach for selecting the
I. Concept Development Projects that are initiated to explore some new degree of rigor that is appropriate for a particular project. To accomplish this,
business concept or application of some new technology, project adaptation criteria are defined and a task set selector value is computed.
II. New Application Development Projects that are undertaken as a
consequence of a specific customer request.
III. Application Enhancement Projects that occur when existing software 7.3.2 Defining Adaptation Criteria9
undergoes major modifications to function, performance, or interfaces that
are observable by the end user, Adaptation criteria are used to determine the recommended degree of rigor
IV. Application Maintenance Projects that correct, adapt, or extend ex- with which the software process should be applied on a project. Eleven adap-
isting software in ways that may not be immediately obvious to the end tation criteria are defined for software projects:
user.
Reengineering Projectsthat are undertaken with the intent of re-
building an existing (legacy) system in whole or in part, situations should be rare (they should not occur on more that 10 20 percent of
all work conducted within the engineering context). An emergency is not the
project with tight time constraints.
Even within a single project type, there are many factors that influence the
adaptation criteria presented in this section and the TSS computation presented in the,
task set to be chosen. When taken in combination, these factors provide an following sections have been adapted from Model. They are
indication of the degree of rigor with which the software process should be with permission of Pressman Associates, Inc. E-mail to for
applied. information.
162 PART MANAGING SOFTWARE PROJECTS CHAPTER PROJECT SCHEDULING AND TRACKING 163
!"size of the project
!" number of potential users
COMPUTING THE TASK SET SELECTOR
!"mission criticality
!" application longevity
Adaptation Criteria Grade __Weight Entry Product
!" stability of requirements
!"ease of customer/developer communication
Size project 1.20 - 0 1 1
!"maturity of applicable technology Number of users _ _ 1
1.10 0 1
_ _ _ 1.10 0 1 1 1
!" performance constraints Business criticality
longevity 0.90 0 1 1 0
!" characteristics Stability of requirements 1.20 0 1 1 1
!"project staffing Ease of communication 0.90 1 1 1
!"reengineering factors Maturity of technology 0.90 1 0 0
Performance 0.80 0 1 1 0
1.20 1 1 0
Each of the adaptation criteria is assigned a grade that ranges between 1 and
Project staffing 1 1 1 1
5, where 1 represents a project in which a small subset of process tasks are re-
Interoperability _ _ 1.10 0 1 1 1 1
quired and overall methodological and documentation requirements are
and 5 represents a project in which a complete set of process tasks should Reengineering factors 1.20 0 0 0 0
be applied and overall methodological and documentation requirements are Task ret selector (TSS)
substantial.
Interpreting the TSS Value and Selecting the Task Set
7.3.3 Computing a Task Set Selector Value
Once the task set selector is computed, the following guidelines can be used to
To select the appropriate task set for a project, the following steps should be select the appropriate task set for a project:
conducted:
Set Selector Value of Rigor
Review each of the adaptation criteria in Section 7.3.2 and assign the ap- 1.2
propriate grades to based on the characteristics of the project. These 1 3.0 structured
grades should be entered into Table 7.1. TSS 2.4 strict
Review the weighting factors assigned to each of the criteria. The of
a weighting factor ranges from 0.8 to 1.2 and provides an indication of the The overlap in TSS values from one recommended task set to another is pur-
relative importance of a particular adaptation criterion to the types of soft- poseful and is intended to illustrate that sharp boundaries are impossible to
ware developed within the local environment. If modifications are required define when making task set selections. In the final analysis, the task set se-
better reflect local circumstances, they should be made. lector value, past experience, and common sense must all be factored into the
Multiply the grade entered in Table 7.1 by the weighting factorand by choice of the task set for a project.
the entry point multiplier the type of project to be undertaken. The
for Table 7.2 illustrates how TSS might be computed for a hypothetical proj-
entry point multiplier takes on a value of 0 or 1 and indicates the rele- ect. The project manager selects the grades shown in the “Grade” column. The
vance of the adaptation criterion to the project type. The result of the project type is new application development. Therefore, entry point multi-
product: pliers are selected from the column. The entry in the “Product” column
ix computed using
grade x weighting factor entry
x multiplier
Grade x Weight Entry Point Multiplier
is placed in the “Product” column of Table 7.1 for each adaptation criterion
individually. The value of TSS (computed as the average of all entries in the product col-
Compute the average of all entries in the “Product” column and place the umn) is 2.8. Using the criteria discussed above, the manager has the’ option of
result in the space marked task set selector This value will be used using either the structured or the strict task set. The final decision is made
to help you select the task set that is most appropriate for the project. once all project factors have been considered.
164 PART MANAGING SOFTWARE PROJECTS 165
CHAPTER 7: PROJECT AND TRACKING
P r o o f o f c o n c e p t demonstrates the viability of a new-technology in the soft-
ware context.
COMPUTING THE TASK SET SELECTOR-AN EXAMPLE
C o n c e p t i m p l e m e n t a t i o n implements the concept represeritation in a man-
ner that can be reviewed by a customer and is used for “marketing” purposes
Criteria when a concept must be sold to other customers or management.
Grade Point Multiplier Product
C u s t o m e r r e a c t i o n t o c o n c e p t solicits feedback on a new technology con-
Size of project 2 1.2 cept and targets specific customer applications.
- - - 2.4
Number of users 3 1.1 1
Business criticality A 1.1 1 A.4 A quick scan of these major tasks should yield few surprises. In fact, the flow
- - -
longevity 3 0.9 1 engineering tasks for concept development projects (and for all
2.7
Stability of requirements 2
2 1.2 1
1 - - - 2.4 other types of projects as well) is little more than common sense.
Ease communication 0.9 __ The software team must understand what must be done (scoping); the team
1.8
Maturity of technology 2 0.9 1 (or manager) must determine whether there’s anyone available do it (plan-
1.8
Performonce constraints 3 0.0 1 2.4 ning); consider the risks associated with the work (risk assessment); prove the
3 1.2 _ _ 1 3.6 technology in some way (proof of concept); and implement it in a prototypical
- - -
Project staffing 2 1.0 1 - - - 2.0 manner so that the customer can evaluate it (concept implementation and cus-
Interoperability A 1.1 1 - - - A.4 tomer evaluation). Finally, if the concept is viable, a production version (trans-
Reengineering factors 0 1.2 0 2.8 lation) must be produced.
It is important to note that concept development tasks are iterative in na-
set selector 2.8 ture. That is, an actual concept development project might approach the above
tasks in a number of planned increments, each designed to produce a deliver-
able that can be evaluated by the customer.
If a linear process model flow is chosen, each of these increments is de-
7.4 SELECTING TASKS fined in a repeating sequence as illustrated in Figure 7.1. During each se-
quence, umbrella activities (described in Chapter are applied, quality is
In order to develop a project schedule, a task set must be distributed on the monitored, and at, the end of each sequence, a deliverable is produced. With
project time line. As we noted in Section 7.3, the task set will vary depending each iteration, the deliverable should converge toward the defined end prod-
upon the project type and the degree of rigor. Each of the project types de- uct for the concept development stage. If an evolutionary model is chosen, the
scribed in Section 7.3 may be approached using a process model that is linear layout of tasks 1.1 through 1.6 would ippear as shown in Figure 7.2. Major
sequential, iterative model), or evolutionary (e.g., the spi- software engineering tasks for other project types can be defined and applied
ral model). In some cases, one project type flows smoothly into the next. For in a similar manner.
example, concept development projects that succeed often evolve into new
application development projects. As a new application development project 7.5 OF MAJOR TASKS
ends, an application enhancement project sometimes begins. This progression
is both natural and predictable, and will occur of the process model The major tasks described in Section 7.4 may be used define a macroscopic
that is adopted by an organization. As an example, we consider the major soft- schedule for a project. For example, the tasks described for concept development
ware engineering tasks for concept development projects. projects would be used to define a task network (Section 7.6) for the project.
Concept development projects are initiated when the potential for some As we noted earlier in this chapter, the macroscopic schedule must be re-
new technology must be explored. There is no certainty that the technology will fined to create a detailed project schedule. Refinement begins by taking each
be applicable, but a customer (e.g., marketing) believes that potential benefit major task and decomposing it into of (with related work
exists. Concept development projects are approached by applying the following and milestones).
major tasks: As an example of task decomposition, consider the Concept Scoping task,
discussed in Section 7.4. Task refinement can be using an outline
C o n c e p t s c o p i n g determines the overall scope of the project. format, but in this book, a process design language’” approach is used to
P r e l i m i n a r y c o n c e p t p l a n n i n g establishes the organization’s ability to un- the flow of the concept scoping activity:
dertake the work implied by the project scope.
risk assessmentevaluates the risk associated with the tech- process design language is similar in syntax program design languages discussed in
nology to be implemented as part of project scope. Chapter 14.
PART TWO MANAGING SOFTWARE PROJECTS CHAPTER 7 PROJECT SCHEDULING AND TRACKING 167
1.1 Concept scoping 1.4 Proof of concept
1.2 Preliminary concept planning
New Application
Development Projects
I I
Application
Maintenance
Release
Customer
Evaluation
FIGURE 7.2. Concept development tasks using an evolutionary model.
FIGURE 7.1. Concept development tasks in a linear, sequential model.
I.1 Concept Scoping develop class hierarchy and class connections:
1.1.1 Identify need, benefits and potential customers; define attributes for classes;
1.1.2 Define desired output/control and input events
that drive the application; 1.1.2.3 FTR: R e v i e w with
Begin Task 1.1.2 visa required;
1.1.2.1 R&view written description of need Task 1.1.2
1.1.2.2 Derive list of customer visible outputs/inputs
case of-:--mechanics 1.1.3 the functionality/behavior for each major
function deployment function;
meet with customer to isolate major concept requirements; Begin Task 1.1.3
interview end users; 1.1.3.1 output and input data
observe current approach to problem, current process; in
a of
mechanics analysis case of: mechanics
make list of major data objects; function deployment
define relationships between objects; meet with customer to review major concept require-
define object attributes; ments;
view interview end users;
make list of problem classes; observe current approach to problem, current process;
develop a hierarchical outline of functions/behaviors;
mechanics analysis
indicates that formal technical review (Chapter is be conducted. derive a context level data flow diagram;
168 PART TWO: MANAGING SOFTWARE PROJECTS
refine the data flow diagram to provide more detail;
write narratives functions at lowest
level of refinement;
mechanics view
define operations/methods that are relevant for each
class;
1.1.3.3 Review with and re-
vise as required;
Task
I. 1.4 Isolate those elements of the technology to be im-
plemented in software:
1.1.5 Research availability of software;
1.1.6 Define technical
1.1.7 Make quick estimate of sizer
Create a scope definition;
Task I.1
The tasks and noted in the process design language refinement form
the basis for a detailed schedule for the concept scoping activity.
7.6 DEFINING A TASK NETWORK
Individual tasks and have interdependencies based on their sequence.
In addition, when more than one person is involved in a software engineering
project, it is that development and tasks will in
parallel. When this occurs, concurrent tasks must coordinated so that they
will be complete when later tasks require their work product(s).
A task is a graphic representation of the task flow for project. It
is sometimes used as the mechanism through which task sequence and depen-
dencies are input to an automated project scheduling tool. In its simplest form
(used when creating a macroscopic schedule), the task network depicts major
software engineering tasks. Figure 7.3 shows a schematic task network for a
concept development project.
The concurrent nature of software engineering activities leads to a num-
ber of important scheduling requirements. Because parallel tasks occur asyn-
chronously, the planner must determine intertask dependencies to ensure
continuous progress toward completion. In addition, the project manager
should be aware of those tasks that lie on the critical path. That is, tasks
that must be completed on schedule if the project as a whole is to be com-
pleted on schedule. These issues are discussed in more detail later in this
chapter.
It is important to the task network shown in 7.3 is
Lo
each activity shown in Figure 7.3 would bc expanded. For example, Task I.1
would be expanded to show all tasks detailed in the refinement shown in
Section 7.5.
169
170 PART TWO MANAGING SOFTWARE PROJECTS
7.7 SCHEDULING
Scheduling of a software project does not differ greatly from scheduling of any
multitask engineering effort, Therefore, generalized project scheduling tools
and techniques can be npplied to with little modification.
Program and technique and critical path method
are two project scheduling methods that can be applied to soft-
ware development. Both techniques are driven by information already devel-
oped in earlier project planning activities:
!" estimates of
!"a decomposition of product function
!" the selection of the appropriate process model
!"the selection of project type and task set
Interdependencies among tasks may be defined using a task network. Tasks,
sometimes called the project work breakdown structure are defined for
the product as a whole or for individual functions.
Both PERT and CPM provide quantitative tools that allow the software
planner to determine the critical path-the chain of tasks that determines
the duration of the project; establish most likely time estimates for individ-
ual tasks by applying statistical models; and calculate boundary times that
define a time “window” for a particular task.
Boundary time calculations can be very useful in software project schedul-
ing. Slippage in the design of one function, for example, can retard further de-
velopment of other functions. Riggs describes important boundary
times that may be discerned from a PERT or CPM network: the earliest
time that a task can begin when all preceding tasks are completed in the short-
est possible time; the latest time for task initiation before the minimum proj-
ect completion time is delayed; the earliest finish-the sum of the earliest
start and the task duration; the latest finish-the latest start time added
to task duration; and the total float-the amount of surplus time or leeway
allowed in scheduling tasks so that the network critical path is maintained on
schedule. Boundary time calculations lead to a determination of critical path
and provide the manager with a quantitative method for evaluating progress
as tasks are completed.
Both PERT and CPM have been implemented in a wide variety of auto-
mated tools that are available for virtually every personal computer
Such tools are easy to use and make the scheduling methods described above , ,
available to every software project manager.
7.7.1 Charts
When creating a software project schedule, the planner begins with a set of
tasks (the work breakdown structure). If automated tools are used, the work
breakdown is input as a task network or task outline. Effort, duration, and
172 PART SOFTWARE PROJECTS
start date are then input for each task. In addition, tasks may be assigned to
specific individuals.
As a consequence of this input, a chart, also called a chart,
is generated. A chart can be developed for the entire project.
Alternatively, separate charts can be developed for each project function or for
each individual working on the project.
Figure 7.4 illustrates the format of a chart. It depicts a part of a
software project schedule that emphasizes the concept scoping task (Section
7.5) for a new word-processing software product. All project tasks (for concept
scoping) are listed in the hand column. The horizontal bars indicate the du-
ration of each task. When multiple bars occur at the same time on the calen-
dar, task concurrency is implied. The diamonds indicate milestones.
Once the information necessary for the generation of a chart has
been input; the majority of project scheduling tools produce project
tabular listing of all project tasks, their planned and actual start and end
dates, and a variety of related information (Figure 7.5). Used in conjunction with
the chart, project tables enable the project manager to track progress.
7.7.2 the Schedule
The project for If it
has been properly developed, the project schedule defines the tasks and mile-
stones that must be tracked and controlled as the project proceeds. Tracking
can be accomplished in a number of ways:
!" conducting periodic project status meetings in which each team member re-
ports progress and problems
!" evaluating the results of all reviews conducted throughout the software en-
gineering process
!" determining whether formal project milestones (the diamonds shown in
Figure 7.4) have been accomplished by the scheduled date
!" comparing actual start date to planned start date for each project task listed
in the project table (Figure 7.5)
!" meeting informally with practitioners to obtain their subjective assessment
of progress to date and problems on the horizon
In reality, all of these tracking techniques are by project
173
PART SOFTWARE CHAPTER 7 PROJECT SCHEDULING AND TRACKING 175
resources may be focused on the problem area: Staff may be redeployed, or the I. Introduction
project schedule can be redefined. A. of Plan
When faced with severe deadline pressure, experienced project managers B. Project Scope and Objectives
sometimes use a project scheduling and control technique called time-boxing 1. Statement of Scope
The time-boxing strategy recognizes that the complete product may 2. Major Functions
not be deliverable by the deadline. Therefore, an incremental soft- 3. Performance Issues
ware paradigm (Chapter is chosen, and a schedule is derived for each incre- 4. Management and Technical Constraints
mental delivery. II. Project Estimates
The tasks associated with each increment are then time-boxed. This means
A. Historical Data Used for Estimates
that the schedule for each task is adjusted by working backward from the de-
livery date for the increment. A “box” is put around each task. When a task hits B. Estimation Techniques
the boundary of its time-box (plus or minus 10 percent), work stops and the C. Estimates of Effort, Cost, Duration
next task begins. III. Risks Management Strategy
The initial reaction to the time-boxing approach is often negative: “If the A. Risk Table
work isn’t finished, how can we proceed?” The answer lies in the way work is B. Discussion of Risks to be Managed
accomplished. By the time the time-box boundary it is likely C. RMMM Plan for each risk:
that 90 percent of the task has been The remaining 10 percent, 1. Risk Mitigation
although important, can be delayed until the next increment, or be com- 2. Risk Monitoring
pleted later if required. Rather than becoming “stuck” on a task, the project pro- 3. Risk Management (contingency plans)
ceeds toward the delivery date.
IV. Schedule
A. Project Work Breakdown Structure
7.8 THE PROJECT B. Task Network
C. Chart Chart)
D. Resource Table
Each step in the software engineering process should produce a work product
V. Project Resources
that can be reviewed and that can act as a foundation for the steps that follow.
The software project plan is produced at the culmination of the planning tasks. A. People
It provides baseline cost and scheduling information that will be used through- B. Hardware and Software
out the software engineering process. C. Special Resources
The software project plan is a relatively brief document that is addressed VI. Staff Organization
to a diverse audience. It must (1) communicate scope and resources to software A. Team Structure (if applicable)
management, technical staff, and the customer; define risks and suggest B. Management Reporting
risk management techniques; define cost and schedule for management re- VII. Tracking and Control Mechanisms
view; an approach to development as-
7.6. A. Quality Control
sociated with the project; and outline how quality will he
Software project B. Change Management and Control
change will be managed. An outline of the software project plan is presented in
plan. VIII. Appendices
Figure 7.6.
A presentation of cost and schedule will vary with the audience to whom
it is addressed. If the plan is used only as an internal document, the results of
each costing technique can be presented. When the plan is disseminated out-
side the organization, a reconciled cost breakdown (combining the results of all how much and how long. Subsequent steps in the software engineering process
costing techniques) is provided. Similarly, the degree of detail contained within will concentrate on definition, development, and maintenance.
the schedule section may vary with the audience and formality of the plan.
The software project plan need not be a lengthy, complex document. Its pur-
pose is to help establish the viability of the software development effort. The 7.8 SUMMARY
of
plan concentrates on a general statement what and a specific statement of
Scheduling is the culmination of a planning activity that is a primary compo-
nent of project management. When combined with estimation methods
cynic might the saying: The first 90 percent ofsystem takes 90 percent of the
time. The last 10 percent of the system takes 90 percent of the time.” and risk analysis, scheduling establishes a road map for the project manager.
176 PART TWO: MANAGING SOFTWARE PROJECTS 7: PROJECT SCHEDULING AND TRACKING
Scheduling begins with process decomposition. The characteristics of the LOC and 15 person-years of effort (the productivity parameter is and
project are used to adapt an appropriate task set for the work to be done. A = 0.37). Assume that the software must be delivered in 24 months plus or
task network depicts each engineering task, its dependency on other tasks, and minus 12 months.
its projected duration. The task network is used to compute the critical project 7.7. Assume that you have been contracted by a university to develop an on-line
path, a chart, and a variety of project information. Using the schedule course registration system (OLCRS). First, act as the customer (if you’re a
as a guide, the project manager can track and control each step in the software student, that should be easy!) and specify the characteristics of a good sys-
engineering process. tem. Alternatively, your instructor will provide you with a set of preliminary
requirements for the system.
Using the COCOMO model described in Chapter 6, develop an effort and
REFERENCES duration estimate for OLCRS. Suggest how you would
a. define parallel work activities during the OLCRS project
Brooks, M., Mythical Man-Month, Anniversary Edition, b. distribute effort throughout the project
Wesley, 1995. establish milestones for the project
J.J., CR. Ph’ll’ and E.W. Davis, Project Management with 7.8. Using Section 7.3 as a guide, compute the TSS for OLCRS. Be sure to show
CPM, PERT and Precedence Diagramming, 3rd edition, Van Nostrand all of your work. Select a project type and derive an appropriate task set for
Reinhold, 1983. the project.
Page-Jones, M., Practical Project Management, Dorset House, 7.9. Define a task network for OLCRS, or alternatively, for another software proj-
90-91. ect that interests you. Be sure to show tasks and milestones and attach ef-
Putnam, L., and Myers, Measures for Excellence, Press, 1992. fort and duration estimates to each task. If possible, use an automated sched-
Riggs, J., Production Systems Analysis and Control, 3rd edi- uling tool to perform this work.
tion, Wiley, 1981. 7.10. If an automated scheduling tool is available, determine the critical path for
The, L., “Project Management Software That’s IS Friendly,” the network defined in problem 7.8.
October 1, 1993, pp. 55-58. 7.11. Using a scheduling tool (if available) or paper and pencil (if necessary), de-
Zahniser, R., “Time-Boxing for Top Team Performance,” Software velop a chart for the OLCRS project.
March 1995, pp. 34-38.
7.12. Refine a task called Plan the software project in much the same way as
concept scoping was refined in Section 7.5.
7.13. Suggest practical methods that would enable a manager to monitor
PROBLEMS AND POINTS TO PONDER with costs and schedules defined in the software project plan.
7.1. “Unreasonable” deadlines are a fact of life in the software business. How
should you proceed if you’re faced with one?
FURTHER READINGS AND OTHER INFORMATION SOURCES
7.2. is the difference between a macroscopic schedule and a detailed sched-
ule. Is it possible to manage a project if only a macroscopicschedule is de-
veloped? Why? Project scheduling issues are covered in most books on software project man-
agement. Wysoki and his colleagues (Effective Project Management, Wiley, 1995)
7.3. Is there ever a case where a software project milestone is not tied to a review?
and (Managing Software Development Projects, 2nd edition, Wiley,
If so, provide one or more examples.
1995) consider the topic in detail, Boddie (Crunch Mode, Prentice-Hall, 19871
7.4. In Section 7.2.1, we present an example of the “communication overhead” thnt has written a book for all managers who “have 90 days to do a six month proj-
can occur when multiple people work on a software project. Develop a ect.” Gilb (Principles of Software Engineering Management, Addison-Wesley,
terexample that illustrates how engineers who are well-versed in good soft- 1988) writes a thought-provoking discussion of software engineering and its
ware engineering practices and who make use of formal technical reviews can management. Kerr and Hunter (Inside RAD: How to Build Fully Function&
increase the production rate of a team (when compared to the sum of indi- Computer Systems in 90 Days Less, McGraw-Hill, 1994) discuss project
vidual production rates). [Hint: You can assume that reviews reduce rework scheduling issues for “accelerated” projects.
and that rework can account for 20 to 40 percent of a person’s time.1 Thayer (Software Engineering Project Management, IEEE Computer
7.6. Although adding people to a late software project can make it later, there are Society Press, 1987) has edited a thorough anthology that contains a number
circumstances in which this is not true. Describe them. of important papers on project scheduling. Bennatan (Software Project
7.6. The relationship between people and time is highly nonlinear. Using Putnam’s Management: A Practitioner’s Approach, McGraw-Hill, Ould (Strategies
Software Equation (described in Section develop a table that relates for Software Engineering, Wiley, (Managing Software
number of people to project duration for a software project requiring 50,099 Projects, Wiley, and Page-Jones, (Practical Project Management,
PART WO: MANAGING SOFTWARE PROJECTS
Dorset House Publishing, New York, have written good introductions to
project management, presenting the basic elements of estimation, planning and
scheduling, project tracking, team organization, and other management topics.
(Making Software Development Visible, Wiley, 1990) has written one of the
few books that emphasizes project tracking.
SOFTWARE QUALITY
A software management and metrics system, called Web-Integrated
Software Metrics Environment provides a framework for managing
development projects across the Internet. Programmers and managers
ASSURANCE
can log issue reports, track the status of issues, and view project metrics using
standard Web browsers at:
An up-to-date list of World Wide Web references for project scheduling and
control can be found at:
he software engineering approach described in this book works toward a
single goal: to produce high-quality software. Yet many readers will be chal-
lenged by the question: “What is software quality?”
Philip Crosby in his landmark book on quality, provides a wry an-
swer to this question:
The problem of quality management not what people don’t know it.
The problem what they think they do know. .
In this regard, quality has much in common with sex. Everybody is for it.
(Under certain conditions, of course.) Everyone feels they understand it. (Even
though they wouldn’t want to explain it.) Everyone thinks is only a
matter of following natural inclinations. all, we do get along somehow.)
And, of course, most people feel that problems in these areas are caused by
other people. (If only they would take the time to do things right.)
Some software to that software quality is some-
thing you begin lo worry has Nothing could
be further from the truth! Software quality assurance is an umbrella ac-
tivity (Chapter that is applied throughout the software process. SQA en-
compasses a quality management approach, effective software engineer-
ing technology (methods and tools), formal technical reviews that are applied
throughout the software process, a multitiered testing strategy, (5) control
of software documentation and the changes made to it, a procedure to as-
sure compliance with software development standards (when applicable), and
measurement and reporting mechanisms.
In this chapter, we focus on the management issues and the
specific activities that enable a software organization to ensure that it does “the
179
180 PART MANAGING SOFTWARE PROJECTS CHAPTER 8: SOFTWARE QUALITY ASSURANCE
right things at the right time in way.” A quantitative discussion of “simple” process such as duplication may encounter problems due to variation
quality is presented in Chapter 18. between samples.
How might a software development organization need to control variation?
From one project to another, we want to minimize the difference between the
8.1 QUALITY CONCEPTS’ predicted resources needed to complete a project and the actual resource8 used,
including staffing, equipment, and calendar time. In general, we would like to
make sure our testing program covers a known percentage of the software from
It has been said that no two snowflake8 are alike. Certainly when we watch one release to another. Not only do we want to minimize the number of defects
snow falling it is hard to imagine that snowflakes differ at all, let alone that that are released to the field, but we’d like to ensure that the variance in the
each flake possesses a unique structure. In order to observe, differences be- number of hugs is also minimized from one release to another. customers
tween snowflakes, we must examine closely, perhaps using a will likely be upset if the third release of a product has ten times many de-
magnifying glass. In fact, the closer we look, the more differences we are able fects as the previous release.) We would like to minimize the differences in
to observe. speed and accuracy of our hotline support response8 to customer problems. The
This phenomenon, variation between samples, applies to all products of hu- list goes on and on.
man as well as natural creation. For example, if two “identical” circuit hoards
are examined closely enough, we may observe that the copper pathways on the
hoards differ slightly in geometry, placement, and thickness. In addition, the lo-
8.1.1 Quality
cation and diameter of the holes drilled in the board8 varies as well.
All engineered and manufactured parts exhibit variation. The variation be-
tween samples may not be obvious without the aid of precise equipment to The American Heritage Dictionary defines quality as “a characteristic or at-
measure the geometry, electrical characteristics, or other attributes of the tribute of something.” As an attribute of an item, quality refers to measurable
parts. However, with sufficientlysensitive instruments, we will likely come to characteristics-things we are able to compare to known standards such as
the conclusion that no two samples of any item are exactly alike. length, color, electrical properties, malleability, and so on. However, software,
Does this principle apply to software as well as physical items? Imagine a largely an intellectual entity, is more challenging to characterize than physical
program that, at some point during its execution, needs to sort record8 in as- objects.
cending order based on some key field. The nature of the records is not impor- Nevertheless, measures of a program’s characteristics do exist. These prop-
tant. They may be employee records, a customer database, map coordinates for erties include cyclomatic complexity, cohesion, number of function points,
a real-time flight control system, or whatever. and many others discussed in Chapters 18 and 23. When we examine
The programmer creating the sort routine (or selecting it from a library of an item based on its measurable characteristics, two kinds of quality may be
reusable components) elects to use quicksort to solve the immediate problem. encountered: quality of design and quality of conformance.
Can an observer of the product distinguish the software from an Quality of design refers to the characteristics that designers specify for an
a bubble sort? but item, grade of materials, and performance specifications ail con-
probably need more information and possibly sensitive instrumentation to dis- tribute to the quality of design. As higher-graded materials are used and tighter
tinguish between the two systems. tolerances and greater levels of performance are specified, the design quality
Variation control is the heart of quality control. A manufacturer wants to of a product increases, if the product is manufactured according to
minimize the variation among the products that are produced, even when do- tions.
ing something relatively simple like duplicating diskettes. We want to minimize Quality of conformance is the degree to which the design specifications are
the variation between any pair of allegedly identical diskettes. Surely, this can- followed during manufacturing. Again, the greater the degree of conformance,
not he a problem-duplicating disks is a trivial manufacturing operation, and the higher the level of quality of
we can guarantee that exact duplicates of the software are always created. In software development, quality of design encompasses requirements,
Or can we? We need to ensure the tracks are placed on the diskettes within specifications, and the design of the system. Quality of conformance is an issue
a specified tolerance so that the overwhelming majority of floppy drives can focused primarily on implementation. If the implementation follows the design
read the diskettes. In addition, we need to ensure that the magnetic flux for and the resulting system meets its requirements and performance goals, con-
distinguishing a zero from a one is sufficient for read/write heads to detect. The formance quality is high.
disk duplication machines can, and do, wear and go out of tolerance. So even a
8.1.2 Quality Control
section, written by Michael has been adapted from “Fundamentals of
9000,” workbook developed for Essential a video curriculum developed Variation control may be equated to quality control. But how do we achieve
by Pressman Associates, Inc. Reprinted with permission. quality control? Quality control is the series of inspections, reviews, and tests
PART TWO. MANAGING SOFTWARE PROJECTS CHAPTER SOFTWARE ASSURANCE
182 183
throughout the development cycle ensure that each work product meets Failure costs are costs that would disappear if no defects appeared before ship-
the requirements placed upon it. Quality control includes a feedback loop to the ping a product to customers. Failure costs may be subdivided into internal fail-
process that created the work product. The combination of measurement and ure costs and external failure costs. Internal failure costs are the costs incurred
feedback allows us to tune the process when the work products created fail to when we detect in product prior to shipment. Internal failure costs
meet their specifications. This approach views quality control as part of the include:
manufacturing process.
Quality control activities may be fully automated, entirely manual, or a !" rework
combination of automated tools and human interaction. A key concept of qual- !" repair
ity control is that all work products have defined and measurable specifications
!" failure mode analysis
to which we may compare the outputs of each process. The feedback loop is es-
sential to minimize the defects produced.
External failure costs are the costs associated with defects found after the prod-
uct has been shipped to the customer. Examples of external failure are:
Quality Assurance
!" resolution
Quality consists of the auditing and reporting functions of manage- !" product return and replacement
ment. The goal of quality assurance is provide management with the data !" help line support
essnry to informed about product quality, thereby insight and confi- !" warranty work
dence that product quality is meeting its goals. Of course, if the data provided
through quality assurance identify problems, it is management’s responsibility As expected, the relative costs to find and repair a defect increase dramatically
address the problems and apply the necessary resources resolve quality issues. as we go from prevention to detection and from internal failure to external fail-
ure. Figure 8.1, based on data collected by Boehm illustrates this phe-
nomenon.
8.1.4 Cost of Quality More recent anecdotal data is reported by Kaplan and his colleagues
and is based on work at IBM’s Rochester development facility:
of quality includes all costs incurred in the pursuit of quality or in per-
forming quality related activities. Cost of quality studies are conducted to pro-
vide a baseline for the current cost of quality, to identify opportunities for re- 40-1000
ducing the cost of quality, and to provide normalized basis of comparison. The
times
basis of normalization is almost always dollars. Once we have normalized qual-
ity costs on a dollar basis, we have the necessary data to evaluate where the
opportunities lie to improve our processes. Furthermore, we can evaluate the
affect of changes in dollar-based terms.
Quality costs may be divided into costs associated with prevention, ap- 15-40
praisal, and failure. Prevention costs include: times
10
!" quality planning times
3-6
!" formal technical reviews
times
!" test equipment
!" training
Appraisal costs include activities to gain insight into product condition the
“first time through” each process. Examples of appraisal costs include:
!" in-process and interprocess inspection FIGURE 8 . 1 .
!" equipment calibration and maintenance Relative of Code System Field
testing correcting an error.
!" Test Test Operation
184 PART MANAGING PROJECTS 8: SOFTWARE QUALITY ASSURANCE 185
A total of 7053 hours was spent inspecting 200,000 lines of code with the re- While the two steps focus on the process, the next step, called kansei
sult that 3112 potential defects were prevented. Assuming a programmer cost (translated as “the senses”) concentrates on the user of the product (in this
of $40.00 per hour, the total cost of preventing 3112 defects was $282,120, or case, software). In essence, by examining the way the user applies the product,
roughly $91.00 per defect. kansei leads to improvement in the product itself, and potentially, to the process
Compare these numbers to the cost of defect removal once the product has that created it.
been shipped to the customer. Suppose that there had been no-inspections, but Finally, a step called hinshitsu broadens management concern
that programmers had been extra careful and only one defect per 1000 lines of beyond the immediate product. This is a business-oriented step that looks for
code [significantly better than industry average1 escaped into the shipped prod- opportunity in related areas that can be identified by observing the use of the
uct. That would mean that 200 defects would still have to be fixed in the field. product in the marketplace. In the software world, miryokuteki hinshitsu might
At an estimated cost of $25,000 per the cost would be $6 million, or be viewed as an attempt to uncover new and profitable products or applications
approximately 18 times more expensive than the total cost of the defect pre- that are an outgrowth from an existing computer-based system.
vention effort. For most companies should be of immediate concern. Until a mature
software process (Chapter 2) has been achieved, there is little point in moving
It is true that IBM produces software that is used by tens of thousands of cus- to the next steps.
tomers and that their costs for may be higher than average. This in
no way negates the results noted above. Even if the average software organi-
zation has field costs that are 25 percent of IBM’s (most have no idea what SOFTWARE QUALITY ASSURANCE
8.3
their costs are!), the cost savings associated with quality control and assurance
activities are compelling.
Even the most jaded software developers will agree that high-quality software is
important goal. But how do we define quality? A wag once said, “Every pro-
gram does something right, it just may not be the thing that we want it to do.”
There have been many definitions of software quality proposed in the lit-
8.2 THE QUALITY MOVEMENT erature. For our purposes, software quality is defined as:
Today, senior managers at companies throughout the industrialized world rec-
ognize that high product quality translates to cost savings and an improved Conformance to explicitly stated functional and performance requirements, ex-
bottom line. However, this was not always the case. The quality movement be- plicitly documented development standards, and implicit characteristics that
gan in the 1940s with the seminal work of W. Edwards and are expected of all professionally developed software.
had its true test in Japan. Using Deming’s ideas as a cornerstone, the
Japanese have developed a systematic approach to the elimination of the root There is little question that the above definition could be modified or extended.
causes of product defects. Throughout the 1970s and their work mi- If fact, a definitive definition of software quality could be debated endlessly. For
grated to the Western world and is sometimes called “total quality management the purposes of this book, the above definition serves to emphasize three im-
Although terminology differs across different companies and authors, portant points:
a basic four-step progression is normally encountered and forms the foundation
of any good TQM program. 1. Software requirements are the foundation from which quality is measured.
The first step is called and refers to a system of continuous process Lack of conformance to requirements is lack of quality.
improvement. The goal of is to develop a process (in this case, the soft- 2 . Specified standards define a set of development criteria that guide the
ware process) that is visible, repeatable, and measurable. manner in which software is engineered. If the criteria are not followed,
The second step, invoked only after has been achieved, is called __ lack of quality will almost surely result.
hinshitsu. This step examines intangibles that affect the process and
3 . There is a set of implicit requirements that goes unmentioned (e.g., the
works to optimize their impact on the process. For example, the software process
desire for good maintainability). If software conforms to its explicit require-
may be affected by high staff turnover, which itself is caused by constant reor-
ments but fails to meet implicit requirements, software quality is suspect.
ganizations within a company. It may be that a stable organizational structure
could do much to improve the quality of software. hinshitsu would
lead management to suggest changes in the way reorganization occurs.
8.3.1 Background Issues
‘See for discussion of in context and Quality assurance is an essential activity for any business that produces prod-
for a discussion of the use of the Baldridge Award the software world. ucts to be used by others. Prior to the twentieth century, quality assurance was
MANAGING SOFTWARE PROJECTS CHAPTER SOFTWARE
186 QUALITY ASSURANCE
187
the sole responsibility of the craftsperson who built a product. The first formal !" procedures for error reporting and tracking
quality assurance and control function was introduced at Bell Labs in 1916 and !" documents to be produced by the SQA group
spread rapidly throughout the manufacturing world.
!" amount of feedback provided to software project team
During the early days of computing (the 1950s and quality was the
sole resnonsibilitv of the programmer. Standards for quality assurance for soft-
ware introduced in military contract software development during the Participates in the development of the project’s software process descrip-
1970s and have spread rapidly into software development in the commercial t i o n . The software engineering team selects a process for the work to be
world Extending the definition presented earlier, software quality as- performed. The SQA group reviews the process description for compliance
surance is a “planned and systematic pattern of actions” that are with organizational policy, internal software standards, externally imposed
auired to ensure quality in software. Today, the implication is that many standards (e.g., and other parts of the software project plan.
constituencies in an organization have software quality assurance to compliance with the de-
resnonsibilitv-software engineers, project managers, customers, salespeople, fined software process. The SQA group identifies, documents, and tracks
and the who within an SQA group. and that have been made.
The SQA group serves as the customer’s in-house representative. That is, Audits software work products to verify compliance with those
the people who perform SQA must look at the software from the customer’s defined as part of the software process. The SQA group reviews selected
point of view. Does the software adequately meet the quality factors noted in work products; identifies, documents, and tracks deviations; verities that
Chapter Has software development been conducted according to corrections and periodically reports the results of its work
lished standards? Have technical disciplines properly performed their roles as Lo the project manager.
part of the SQA activity? The SQA group attempts to answer these and other
Ensures that deviations in software work and work products are docu-
questions to ensure that software quality is maintained.
mented and handled according to a documented procedure. Deviations
may be encountered in the project plan, process description, applicable
standards, or technical work products.
Records any noncompliance and reports to senior management. Noncom-
8.3.2 Activities pliance items are tracked until they are resolved.
Software quality assurance is comprised of a variety of tasks associated with In addition to these activities, the SQA group coordinates the control and man-
two different constituencies-the software engineers who do technical work agement of change (Chapter and helps to collect and analyze software
and a SQA group that has responsibility for quality assurance planning, over- metrics.
sight, record keeping, analysis, and reporting.
Software engineers address quality (and perform quality assurance) by
-plying solid technical methods and measures, conducting formal technical re- 8.4 SOFTWARE REVIEWS
views, and performing well-planned software testing. Only reviews are dis-
cussed in this chapter. Technology topics are discussed in Parts Three through Software reviews are a “filter” for the software engineering process. That is, re-
Five of this book. views are applied at various points during software development and serve to
The charter of the SQA group is to assist the software engineering team in uncover errors that can then be removed. Software reviews serve to “purify” the
achieving a high quality end product. The Software Engineering Institute software work products that occur as a result of analysis, design, and coding.
recommends a set of SQA activities that address quality assurance Freedman and Weinberg discuss the need for reviews this way:
planning, oversight, record keeping, analysis, and reporting. It is these activi-
ties that are performed (or by an independent SQA group:
work needs reviewing for the same reason that pencils need erasers:
err is human. The second reason we need technical reviews is that although
Prepare a Plan for a project. The plan is developed during project people are good at catching some of their own errors, large classes of errors es-
planning and is reviewed by all interested parties. Quality assurance ac- originator more than escape anyone else. The review
tivities performed by the software engineering team and the group process is, therefore, the answer to the prayer of Robert Burns:
are governed by the plan. The plan (Figure 8.5) identifies:
0 wad some power the giftie give us
!" evaluations to be performed to see ourselves as other see us
!" audits and reviews to be performed
!" standards that are applicable to the project A review-any review-is a way of using the diversity of a group of people
188 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 8: SOFTWARE ASSURANCE 189
1. point out needed improvements in the product of a single person or team; projects Assume that an error uncovered during design will cost 1.0
2. confirm those parts of a product in which improvement is either not monetary unit to correct. Relative to this cost, the same error uncovered just
desired or not needed; and before testing commences will cost 6.5 units; during testing 15 units; and after
release. between 60 and 100 units.
3. achieve technical work of more uniform, or at least more predictable,
quality than can be achieved without reviews, in order to make tech-
nical work more manageable.
8.4.2 Defect Amplification and Removal
There are many different types of reviews that can be conducted as part of
software engineering. Each has its place. An informal meeting around the cof- A defect amplification can be used to illustrate the generation
fee machine is a form of review, if technical problems are discussed. A formal and detection of errors during preliminary design, detail design, and coding
presentation of software design to an audience of customers, management, and steps of the software engineering process. The model is illustrated schemati-
technical staff is a form of review. In this book, however, we focus on the for- cally in Figure 8.2. A box represents a software development step. During the
mal technical review-sometimes called a A formal technical re- step, errors may be inadvertently generated. Review may fail to uncover newly
view is the most effective filter from a quality assurance standpoint. Conducted generated errors and errors from previous steps, resulting in some number of
by software engineers (and others) for software engineers, the FTR is an effec- errors that are passed through. In some cases, passed through from pre-
tive means for improving software quality. vious steps are amplified (amplification factor, by current work. The box sub-
divisions represent each of these characteristics and the percent efficiency for
detecting errors, a function of the thoroughness of review.
Figure 8.3 illustrates a hypothetical example of defect amplification for a
8.4.1 Cost Impact of Software Defects software development process in which no reviews are conducted. As shown in
the figure, each test step is assumed to uncover and correct 50 percent of all
The ZEEE Standard Dictionary of Electrical and Electronics Terms (IEEE incoming errors without introducing any new errors (an optimistic assump-
Standard defines a defect as “a product anomaly.” The definition for tion). Ten preliminary design errors are amplified to 94 errors before testing
“fault” in the hardware context can be found in IEEE Standard 610.12-1990: commences. Twelve latent defects are released to the field. Figure 8.4 consid-
ers the same conditions except that design and code reviews are conducted as
(a) A defect in a hardware device or component; for example, a short circuit or part of each development step. In this case, 10 initial preliminary design errors
broken wire. An incorrect step, process, or data definition in a computer pro- are amplified to 24 errors before testing commences. Only three latent defects
gram. This definition is used primarily by the fault tolerance discipline. exist. By recalling the relative costs associated with the discovery and
In common usage, the terms “error” and “bug” are used to express this mean- tion of errors, overall cost (with and without review for our hypothetical ex-
ing. See also: data-sensitive fault; program-sensitive fault; equivalent faults; ample) can be established. In Table 8.1 it can be seen that total cost for devel-
fault masking; intermittent fault. opment and maintenance when reviews are conducted is 783 cost units. When
no reviews are conducted, total cost is 2177 units-nearly three times more
Within the context of the software process, the terms “defect” and “fault” are costly.
synonymous. Both imply a quality problem that is discovered after the software To conduct reviews, a developer must expend time and effort and the de-
has been released to end users. In earlier chapters, we used the term “error” to velopment organization must spend money. However, the results of the preced-
depict a quality problem that is discovered by software engineers (or others) ing example leave little doubt that we have encountered a “pay now or pay much
before the software is released to the end user. more later” syndrome. Formal technical reviews (for design and other technical
The primary objective of formal technical reviews is to errors during activities) provide a demonstrable cost benefit. They should be conducted.
the process so that they do become defects after release of the software. The ob-
vious benefit of formal technical reviews is the early discovery of errors so that
they do not propagate to the next step in the software process.
A number of industry studies (TRW, Nippon Electric, and Mitre Corp., Development step
among others) indicate that design activities introduce between 50 and 65 per- Defects Detection
cent of all errors (and ultimately, all defects) during the software process.
However, formal techniques have been shown to be up to 75 percent ef- Errors from
fective in uncovering design flaws. By detecting and removing a large previous step
percentage of these errors, the review process substantially reduces the cost of Errors
to next step
subsequent steps in the development maintenance phases.
To illustrate the cost impact of early error detection, we consider a series FIGURE 8.2. Defect Newly generated
of relative costs that are based on actual cost data collected for large software amplification model
190
PART TWO MANAGING SOFTWARE PROJECTS CHAPTER QUALITY ASSURANCE 191
Preliminary
Detail design COST COMPARISON
test
Errors Found Number Unit
Reviews Conducted
During design 22 1.5 33
Before test 36 6.5 234
During test 15 315
After release 3 67
No Reviews Conducted
FIGURE 8.3. Defect Before test 22 6.5 143
amplification-no During test 82 15 1230
views After release 12 67
2177
Preliminary design
cover errors in function, logic, or implementation for any representation of the
software; to verify that the software under review meets its requirements;
Code/unit test to ensure that the software has been represented according to
standards; to achieve software that is developed in a uniform manner; and
to make projects more manageable. In addition, the serves as a train-
ing ground, enabling junior engineers to observe different approaches to soft-
ware analysis, design, and implementation. The FTR also serves to promote
backup and continuity because a number of people become familiar with parts
of the software that they may not have otherwise seen.
The FTR is actually a class of reviews that include inspec-
tions, round-robin and other small group technical assessments of soft-
ware. Each FTR is conducted as a meeting and will be successful only if it is
properly planned, controlled, and attended. In the paragraphs that follow,
guidelines similar to those for a
a representative formal technical review.
FIGURE 8.4. Defect
views conducted
8.5.1 The Review Meeting
8.5 FORMAL TECHNICAL REVIEWS Regardless of the FTR format that is chosen, every review meeting should
abide by the following constraints:
formal technical review is a software quality assurance activity that
performed by software engineers.:’ The objectives of the FTR are to !" between three and five people (typically) should be involved in the review;
!" advance preparation should occur but should require no more than two hours
of work for each person; and
cases, other constituencies (e.g., customers, marketing, support staff) may also par-
ticipate in technical reviews. !" the duration of the review meeting should be less than two hours.
192 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 8: SOFTWARE QUALITY ASSURANCE 193
Given the above constraints, it should be obvious that an focuses on a spe- producer a8 correction8 are made. An issues list is normally attached to the
cific (and small) part of the overall software. For example, rather than at- summary report.
tempting to review an entire design, walkthroughs are conducted for each mod- It is important to establish a follow-up procedure to ensure that items on
ule or small group of modules. With a narrower focus, the FTR has a higher the issues list have been properly corrected. Unless this is done, it is possible
likelihood of uncovering errors. that issues raised can “fall between the cracks.” One approach is to assign the
The focus of the is on a work product-a component of the software responsibility for follow-up to the review leader. A more formal approach as-
(e.g., a portion of a requirements specification, a detailed module design, a signs responsibility to an independent SQA group.
source code listing for a module). The individual who has developed the work
product-the producer-informs the project leader that the work product is
complete and that a review is required. The project leader contacts a
leader, who evaluates the work product for readiness, generates copies, and dis- 8.5.3 Review Guidelines
tributes them to two or three reviewers for advance preparation. Each reviewer
is expected to spend between one and two hours reviewing the work product, Guideline8 for the conduct of formal technical reviews must be established in
making notes, and otherwise becoming familiar with the work. Concurrently, advance, distributed to all reviewers, agreed upon, and then followed. A review
the review leader also reviews the work product and establishes an agenda for that is uncontrolled can often be worse than no review at all.
the review meeting, which is typically scheduled for the next day. The following represents a minimum set of guidelines for formal technical
The review meeting is attended by the review leader, all reviewers, and the reviews:
producer. One of the reviewers takes on the role of the recorder, that is, the indi-
vidual who records (in writing) all important issue8 raised during the review. The
1. Review the product, not the producer. An FTR involves people and egos.
begins with an introduction of the agenda and a brief introduction by the
Conducted properly, the FTR should leave all participants with a warm
producer. The producer then proceed8 to “walk through” the work product, ex-
plaining the material, while reviewers raise issues based on their advance prepa- feeling of accomplishment. Conducted improperly, the FTR can take on the
aura of an inquisition. Errors should be pointed out gently; the tone of the
ration. When valid problems or errors are discovered, the recorder notes each.
meeting should be loose and constructive; and the intent should not be to
At the end of the review, all attendees of the FTR must decide whether to
accept the work product without further modification, reject the work embarrass or belittle. The review leader should conduct the review meet-
ing to ensure that the proper tone and attitude are maintained and should
product due to errors (once corrected, another review must be per-
immediately halt a review that has gotten out of control.
formed) or accept the work product provisionally (minor errors have been
encountered and must be corrected, but no additional review will be required). 2. Set an agenda and maintain it. One of the key maladies of meetings of all
The decision made, all FTR attendees complete a indicating their par- types is drift. An FTR must be kept on track and on schedule. The review
ticipation in the review and their concurrence with the review team’s findings. leader is chartered with the responsibility for maintaining the meeting
schedule and should not be afraid to nudge people when drift sets in.
3. Limit debate and rebuttal. When an issue is raised by a reviewer, there
may not be universal agreement on its impact. Rather than spending time
8.5.2 Review Reporting and Record Keeping debating the question, the issue should be recorded for further discussion
off-line.
During the FIR, reviewer (the recorder) actively records all issues that have 4. Enunciate problem areas, but don’t attempt to solve problem noted.
been raised. These are summarized at the end of the review meeting and a re- A review is not a problem solving session. The solution of a problem can
view issues is produced. In addition, a simple summary is corn-‘ often be accomplished by the producer alone or with the help of only one
pleted. A review summary report answers three questions: other individual. Problem solving should be postponed until after the re-
view meeting.
1. What was reviewed? 5. Take written notes. It is sometimes a good idea for the recorder to make
2. Who reviewed it? note8 on a wall board, so that wording and prioritization can be assessed
3 . What were the findings and conclusions? by other reviewers as information is recorded.
6. Limit the number of participants and insist upon advance preparation.
The review summary report is typically a single page form (with possible at- Two heads are better than one, but 14 are not necessarily better than 4.
tachments). It become8 part of the project historical record and may be dis- Keep the number of people involved to the necessary minimum. However,
tributed to the project and other interested parties. all review team members must prepare in advance. Written comments
The review issues list serves two purposes: to identify problem areas should be solicited by the review leader (providing an indication that the
within the product and to an checklist that guides the reviewer has reviewed the material).
194 PART TWO MANAGING SOFTWARE PROJECTS CHAPTER 8: SOFTWARE ASSURANCE 195
7. Develop a checklist* for each work product that is likely to be A Attempts to prove programs correct are not new. Dijkstra and
checklist helps the review leader to structure the FTR meeting and helps Linger et al. among others, advocated proofs of program correctness
each reviewer to focus on important issues. Checklists should be devel- and tied these to the use of structured programming concepts (Chapter 14).
oped for analysis, design, coding, and even test documents. Today, a number of different approaches to formal proof of correctness have
been proposed and are discussed in detail in Chapters 24 and 25.
8 . Allocate resources and time schedule for For reviews to be effective,
they should be scheduled as a task during the software engineering
process. In addition, time should be scheduled for the inevitable modifi-
cations that will occur as the result of an
a.7 STATISTICAL QUALITY ASSURANCE
9 . Conduct meaningful training for all reviewers. To be effective all review
participants should receive some formal training. The training should
stress both process related issues and the human psychological side of re- Statistical quality assurance reflects a growing trend throughout industry to
views. Freedman and Weinberg estimate a one month learning become more quantitative about quality For software, statistical quality as-
curve for every 20 people who are to participate effectively in reviews. surance implies the following steps:
10. Review your early reviews. Debriefing can be beneficial in uncovering
problems with the review process itself. The very first work product to be 1. Information about software is collected and categorized.
reviewed might be the review guidelines themselves. 2. An is to to its cause (e.g., non-
conformance to specification, design error, violation of standards, poor com-
Because there are many variables (e.g., number of participants, type of munication with customer).
work products, timing and length, specific review approach) that have an im- 3. Using the Pareto principle percent of the defects can be traced to 20
pact on a successful review, a software organization should experiment to de- percent of all possible causes), isolate the 20 percent (the “vital few”).
termine what approach works best in a local context. Porter and his 4. Once the vital few causes have been identified, to correct the prob-
colleagues excellent guidance for this type of experimentation. lems that have caused the defects.
This relatively simple concept represents an important step toward the cre-
FORMAL APPROACHES TO ation of an adaptive software engineering process in which changes are made
to improve those elements of the process that introduce error.
In preceding sections, we have argued that software quality is everyone’s job To illustrate the process, assume that a software development organization
and that it can be achieved through competent analysis, design, coding, and collects information on defects for a period of one year. Some errors are uncov-
testing, as well as through the application of formal technical reviews, a ered as software is being developed. Other defects are encountered after the
titiered testing strategy, better control of software documentation and the software has been released to its end user. Although hundreds of different er-
changes made to it, and the application of accepted software development rors are uncovered,all can be tracked to one (or more) of the following causes:
standards. In addition, quality can be defined in terms of a broad array
of quality factors and measured (indirectly) using variety of indices and !" incomplete or erroneous specification
metrics. !" misinterpretation of customer communication
Over the past two decades, a small, but vocal, segment of the software engi-
!"intentional deviation from specification (IDS)
neering community has argued that a more formal approach to quality
assurance is required. It can be argued that a computer program is a mathemat- !"violation of programming standards
ical object. A rigorous syntax and semantics can be defined for every program- !" error in data representation
ming language, and a similarly rigorous approach to the specification of software
!"inconsistent module interface
requirements (Chapter is also available. Once the requirements model
has been represented in a rigorous manner, mathematic proofs of cor- !" error in design logic
rectness can be applied to demonstrate that a program conforms oxuetly to its !" or erroneous
specification. !"inaccurate or incomplete documentation
!" error in programming language translation of design
!" ambiguous or inconsistent human-computer interface
‘Extensive information on review checklists can be found at the FTR Archive on the World
Wide Web. See “Further Readings and Other Information Sources” for additional information. !" miscellaneous (MIS)
196 PART MANAGING SOFTWARE PROJECTS SOFTWAR E ASSURANCE
To apply statistical SQA, Table 8.2 is built. The table indicates that IES, MCC, = weighting factors for serious, moderate and trivial errors, where
recommended values are = 10, = 3, = 1. The weighting factors for
and EDR are the vital few causes that account for 53 percent of all errors. It
should be noted, however, that IES, EDR, PLT, and EDL would be selected as each phase should become larger as development progresses. This rewards an
organization that finds errors early
the vital few causes if only serious errors are considered. Once the vital few
causes are determined, the software development organization can begin cor-
rective action. For example, to correct MCC, the software developer might im- At each step in the software process, a phase index, is com-
plement facilitated application specification techniques (Chapter 11) to im- puted:
prove the quality of customer communication and specification. To improve + +
EDR, the developer might acquire CASE tools for data modeling and perform
more stringent data design reviews. As the vital few causes are corrected, new The error index is computed by calculating the cumulative effect or each
candidates pop to the top of the stack. weighting errors encountered later in the software engineering process
In conjunction with the collection of defect information, software develop- more heavily than those encountered earlier.
ers can calculate an error index for each major step in the software engi- EI X
neering process After analysis, design, coding, testing, and release, the
following data are gathered: = + + +
= the total number of errors uncovered during the ith step in the soft- The error index can be used in conjunction with information collected in Table
ware engineering process 8.2 to develop an overall indication of improvement in software quality.
The application of statistical SQA and the Pareto principle can be summa-
= the number of serious errors rized in a single sentence: Spend your time focusing on things that really mat-
= the number of moderate errors ter, but first be sure that you understand what really matters! Experienced in-
dustry practitioners agree that most really difficult defects can be traced to a
the number of minor errors relatively limited number of root causes. In fact, most practitioners have an in-
tuitive feeling for the “real” causes of software defects, but few have spent time
P S = size of the product design statements, pages of documentation) collecting data to support their feelings. By performing the basic steps of sta-
at the ith step tistical SQA, the vital few causes for defects can be isolated and appropriate
corrections can be made.
A comprehensive discussion of statistical SQA is beyond the scope of this
book. Interested readers should see or
DATA COLLECTION FOR STATISTICAL SQA
8.8 SOFTWARE
Total Moderato Minor There is no doubt that the reliability of a computer program is an important
element of its overall quality. If a program repeatedly and frequently fails to
Error No. No. No. % No.
perform, it matters little whether other software quality factors are acceptable.
205 22% 34 27% 68 18% 103 24% Software reliability, unlike many other quality factors, can be measured, di-
MCC 156 17% 12 9% 18% 76 17% rected, and estimated using historical and developmental data. Software relia-
IDS 5% 24 6% 23 5% bility is defined in statistical terms as “the probability of failure free operation
25 3% 0 15 A% 10 2% of a computer program in a specified environment for a specified time”
EDR 130 14% 26 20% 18% 36 . 8% To program X is estimated to have a reliability of 0.96 over eight
6% 9 7% 18 5% 31 7% elapsed processing hours. In other words, if program X were to be executed 100
A5 5% 11% 12 3% 19 4% times and require eight hours of elapsed processing time (execution time), it is
IET 95 10% 12 9% 35 9% 11% likely to operate correctly (without failure) 96 times out of 100.
36 4% 2 2% 20 5% 14 3% Whenever software reliability is discussed, a pivotal question arises: What
PLT 60 6% 15 12% 19 5% 6% is meant by the term “failure”? In the context of any discussion of software
.
HCI quality and reliability, failure is nonconformance to software requirements. Yet,
even within this definition there gradations. Failures can be only annoying
or catastrophic. One failure can be corrected within seconds while another re-
Totals 942 128 379 100% 435 100% quires weeks or even months to correct. Complicating the issue even further,
198 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER SOFTWARE QUALITY ASSURANCE
the correction of one failure may in fact result in the introduction of other Before software was used in safety critical systems, they were often controlled
errors that ultimately result in other failures. by conventional mechanical and electronic devices. System
safety techniques are designed to cope with random failures in these
systems. Human design errors are not considered since it is
assumed that all faults caused by human errors can be avoided completely or
8.8.1 Measures of Reliability and Availability removed prior to delivery and operation.
Early work in software reliability attempted to extrapolate the mathematics of When software is used as part of the control system, complexity can increase by
hardware reliability theory (e.g., to the prediction of software relia- an order of magnitude or more. Subtle design faults induced by human
bility. Most hardware related reliability models are predicated on failure due something that can be uncovered and eliminated in hardware-based conven-
to wear rather than failure due to design defects, In hardware, failures due to tional control-become much more difficult to uncover when software is used.
physical wear (e.g., the effects of temperature, corrosion, shock) are more likely Software safety and hazard analysis are software quality assurance activ-
than a design related failure. Unfortunately, the opposite is true for software. ities that focus on the identification and assessment of potential hazards that
In fact, all software failures can be traced to design or implementation prob- may impact software negatively and cause an entire system to fail. If hazards
lems; wear (see Chapter does not enter into the picture. can be identified early in the software engineering process, software design fea-
There is still debate over the relationship between key concepts in hard- tures can be specified that will either eliminate or control potential hazards.
ware reliability and their applicability to software (e.g., A modeling and analysis process is conducted as part of software safety,
Although an irrefutable link has yet to be established, it is worthwhile to con- Initially, hazards are identified and categorized by criticality and risk. For ex-
sider a few simple concepts that apply to both system elements. ample, some of the hazards associated with a computer-based cruise control for
If we consider a computer-based system, a simple measure of reliability is an automobile might be:
mean time between failure where
MTBF = + !" causes uncontrolled acceleration that cannot be stopped
does not disengage when the brake pedal is depressed
(The acronyms and are mean time to and neon time to !" does not engage when switch is activated
pair, respectively.1
Many researchers argue that MTBF is a far more useful measure than de- slowly loses or gains speed
Stated simply, an end user is concerned with failures, not with the
total defect count. Because each defect contained within a program does not Once these system-level hazards arc identified, analysis techniques are used to
the failure rate, the defect count provides little indication of assign severity and probability of To be software must be
the reliability of a system. For example, consider a program that has been in analyzed in the context of the entire system. For example, a subtle user input
operation for 14 months. Many defects in this program may remain undetected error (people are system components) may be magnified by a software fault to
for decades before they are discovered. The MTBF of such obscure defects produce control data that improperly positions a mechanical device. If a set of
might be 50 or even 100 years, Other defects, as yet undiscovered, might have external environmental conditions are met (and only if they are met), the im-
a failure rate of 18 or 24 months. Even if every one of the first category of de- proper position of the mechanical device will cause a disastrous failure. Analysis
fects (those with long MTBF) is removed, the impact on software reliability is techniques such as fault tree analysis real-time logic or Petri
negligible. net models can be used to predict the chain of events that can cause
In addition to a reliability measure, we must develop a measure of hazards and the probability that each of the events will occur to create the
ability. Software availability is the probability that a program is operating ac- chain.
cording to requirements at a given point in time and is defined as: tree analysis builds a graphical model of the sequential and concur-
rent combinations of events that can lead to a hazardous event or system state
Availability = + X 100% Using a well-developed fault tree, it is possible to observe the consequences of
a sequence of interrelated failures that occur in different system components.
The MTBF reliability measure is equally sensitive to and The
availability measure is somewhat more sensitive to an indirect measure Real-time logic builds a system model by specifying events and corre-
sponding actions. The event-action model can be analyzed using logic opera-
of the maintainability of software.
tions to test safety assertions about system components and their timing. Petri
net models can be used to determine the faults that are most hazardous.
8.8.2 Safety and Hazard Analysis
rink for project man-
Leveson discusses the impact of software in safety critical-systems agement in Chapter 6. The primary is the emphasis on technology issues opposed
when she writes: to related topics.
200 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 8: SOFTWARE QUALITY ASSURANCE 201
Once hazards are identified and analyzed, safety related requirement3 can I. Purpose of Plan
be specified for the software. That is, the specification can contain a list of un- II. References
desirable events and the desired system responses to these events. The role of III‘ Management
software in managing undesirable events is then indicated. 1. Organization
Although software reliability software safety are closely related to one
2. Tasks
another, it is important to understand the subtle difference between them.
3. Responsibilities
Software reliability uses statistical analysis to determine the likelihood that a
Iv. Documentation
software failure will occur However, the occurrence of a failure does not nec-
essarily result in a hazard or mishap. Software safety examines the ways in 1. Purpose
which failures result in conditions that can lead to a mishap. That is, failures 2. Required software engineering documents
are not considered in a vacuum, but are evaluated in the context of an entire 3. Other documents
computer-based system. Standards, Practices, and Conventions
A comprehensive discussion of software safety and hazard analysis is be- 1. Purpose
yond the scope of this book. Those reader3 with further interest should refer to 2. Conventions
Leveson’s book on the subject. Reviews and Audits
1. Purpose
2. Review Requirements
8.9 THE PLAN a. software requirements review
b. design reviews
The SQA plan provides a road map for instituting software quality assurance. c. software verification and validation reviews
Developed by the SQA group and the project team, the plan serves as a tem- d. functional audit
plate for SQA activities that are instituted for each software project. e. physical audit
Figure 8.5 presents an outline for SQA plans recommended by the IEEE f. in-process audits
Initial sections describe the purpose and scope of the document and g. management review3
indicate those software process activities that are covered by quality assurance. VII. Test
All documents noted in the SQA plan are listed and all applicable standards VIII. Problem Reporting and Corrective Action
are noted. The section of the plan describe3 place in the or- Ix. Tools, Techniques, and Methodologies
ganizational structure; SQA tasks and activities and their placement through-
X. Code Control
out the software process; and the organizational roles and responsibilities rel-
ative to product quality. Fig. 8.5. X I . Media Control
The section reference) of thr work prod- ANSI/IEEE Std. XII. Supplier Control
ucts produced as part of the software process. include: 1984 and 983-l 986 Records Collection, Maintenance, and Retention
software XIV. Training
!"project document3 project plan) plans xv. Risk Management
!"models (e.g., class hierarchies)
!" technical documents (e.g., specifications, test plans)
!"user documents (e.g., help
The section references the software test plan and procedure (Chapter
In addition, this section the minimum set of work products that are ac- 17). It also defines test record-keeping requirements. Problem Reporting and
ceptable to achieve high quality. Corrective defines procedures for reporting, tracking, and resolving
Standards, Practices, and Conventions lists all applicable standards/prac- and defects, and identifies the organizational responsibilities for these ac-
tices that are applied during the process (e.g., document standards, tivities.
coding standards, and review addition, all project, process, and The remainder of the SQA plan identifies the tools and methods that
(in some instances) product metrics that are to be collected as part of port SQA activities and tasks; references software configuration management
engineering work are listed. procedures for controlling change; defines a contract management approach; es-
The Reviews and Audits section of the plan identifies the reviews and au- tablishes methods for assembling, safeguarding, and maintaining all records;
dits to be conducted by the software engineering team, the SQA group, and the identifies training required to meet the needs of the plan, and defines methods
customer. It provides an overview of the approach for each review and audit. for identifying, assessing, monitoring, and controlling risks.
202 PART MANAGING SOFTWARE PROJECTS CHAPTER SOFTWARE QUALITY ASSURANCE 203
8.10 THE 9000 QUALITY STANDARDS” The 20 requirements delineated by 9001 address the following topics:
A quality system may be defined as the organizational structure, re- Management responsibility
sponsibilities, procedures, processes, and resources for implementing quality 2. Quality system
management IS0 9000 describes quality assurance elements in 3. Contract review
generic terms that can be applied to any business regardless of the products or
services offered. 4. Design control
To become registered to one of the quality assurance system models con- 5. Document and data control
tained in IS0 9000, a company’s quality system and operations are scrutinized 6. Purchasing
by third party auditors for compliance to the standard and for effective opera-
7. Control of customer supplied product
tion. Upon successful registration, a company is issued a certificate from a reg-
istration body represented by the auditors. Semiannual surveillance audits en- 8. Product identification and traceability
sure continued compliance to the standard. 9. Process control
10. Inspection and testing
11. Control of inspection, measuring, and test equipment
12. Inspection and test status
The Assurance Systems
13. Control of nonconforming product
14. Corrective and preventive action
The 9000 quality assurance models treat an enterprise as a network of in-
terconnected processes. For a quality system to be these processes 15. Handling, storage, packaging, preservation, and delivery
must address the areas identified in the standard and must be documented and 16. Control of quality records
practiced as described. Documenting a process helps an organization under- 17. Internal quality audits
stand, control, and improve it. It is the opportunity to understand, control, and
improve the process network that offers, perhaps, the greatest benefit to orga- 18. Training
nizations that design and implement quality systems. 19. Servicing
9000 describes the elements of a quality assurance system in general 20. Statistical techniques
terms. These elements include the organizational structure, procedures,
processes, and resources needed to implement quality planning, quality control, In order for a software organization to become registered to 9001, it must
quality assurance, and quality improvement. However, 9000 does not de- establish policies and procedures to address each of the requirements noted
scribe how an organization should implement these quality system elements. above and then be able to demonstrate that these policies and procedures are
Consequently, the challenge lies in designing and implementing a quality as- being followed. For further information on 9001, the interested reader
surance system that meets the standard and the company’s products, ser- should and
vices, and culture.
8.11 SUMMARY
8.10.2 The 9001 Standard Software quality assurance is an “umbrella activity” that is applied at each step
\ in the software process. SQA encompasses procedures for the effective applica-
9001 is the quality assurance standard that applies to software engineer- tion of methods and tools, formal technical reviews, testing strategies and tech-
ing. The standard contains 20 requirements that must be present for an effec- niques, procedures for change control, procedures for assuring compliance to
tive quality assurance system. Because the 9001 standard is applicable to standards, and measurement and mechanisms.
all engineering disciplines, a special set of guidelines have SQA is complicated by the complex nature of software quality-an at-
been developed to help interpret the standard for use in the software process. tribute of computer programs that is defined as “conformance to and
implicitly defined requirements.” But when considered more generally, software
quality encompasses many different product and process factors and related
section, written by Michael has been adapted from ‘Fundamentals of 9000” metrics.
and 9001 Standard,” workbooksdeveloped for Essential Software Engineering, a video Software reviews are one of the most important SQA activities. Reviews
curriculum developed by R.S. Pressman Associates, Inc. Reprinted with permission. serve as a filter for the software process, removing errors while they are
PART MANAGING SOFTWARE PROJECTS CHAPTER 8: SOFTWARE QUALITY ASSURANCE 205
tively inexpensive to find and correct. The formal technical review or Linger, R., H. Mills, and B. Witt, Structured Programming, Addison-
through is a stylized review meeting that has been shown to be extremely ef- Wesley, 1979.
fective in uncovering errors. Littlewood, B., “Forecasting Software Reliability,” in Reliability:
To properly conduct software quality assurance, data about the software Modeling and Identification Bittanti, Springer-Verlag, 1989, pp.
engineering process should be collected, evaluated, and
helps to improve the quality of the product and the software process itself, Musa, J.D., A. Iannino, and K. Okumoto, Engineering and Managing
Software reliability models extend measurements, enabling collected defect data with Reliability Measures, McGraw-Hill, 1987.
to be extrapolated into projected failure rates and reliability predictions. Paulk, M. et al. Capability Maturity Model for Software, Software
In summary, we recall the words of Dunn and Ullman “Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1993.
quality assurance is the mapping of the managerial precepts and design disci- Porter, A., H. Siy, CA. and L.G. Votta, “An Experiment to Assess
plines of quality assurance onto the applicable managerial and technological the Cost-Benefits of Code Inspections in Large Scale Software Develop-
space of software engineering.” The ability to ensure quality is the measure of ment,” 3rd ACM SZGSOFT Symposium on the Foundations of
a mature engineering discipline. When the mapping alluded to above is suc- Software Engineering, Washington, DC, October ACM Press, pp.
cessfully accomplished, mature software engineering is the result.
Rook, J., Software Reliability Handbook, 1990.
Schulmeyer, G.C., and J.I. Handbook Quality
REFERENCES Assurance, Van Nostrand Reinhold, 1987.
Schmauch, C.H., 9000 for Software Developers, Quality Press,
Milwaukee, WI, 1994.
von Alvin, W.H. Engineering, Prentice-Hall, 1964. Veseley, W.E. et al., Fault Tree Handbook, U.S. Nuclear Regulatory
Quality Systems Terminology, 1987. Commission, NUREG-0492, January 1981.
Boehm, B., Economics, Prentice-Hall, 1981.
Crosby, P., Quality is Free, McGraw-Hill, 1979.
Deming, W.W., Out Crisis, MIT Press, 1986. PROBLEMS AND POINTS TO PONDER
Dijkstra, E., A Discipline of Programming, Prentice-Hall, 1976.
Dunn, R., and R. Ullman, Quality Assurance for Computer Software.
Early in this chapter we noted that “variation control is the heart of quality
McGraw-Hill, 1982. control.” Since every program that is created is different from every other pro-
“IS0 9000 Software Development,” in Software Engineering,
gram, what are the variations that we look for and how do we control them?
R.S. Pressman Associates, Inc., 1995.
Freedman, and Weinberg, Handbook of it to quality of if the keeps changing
Inspections and Technical Reviews, 3rd edition, Dorset House. 1990. his mind about what it is supposed to do?
T., and D. Graham, Software Addison-Wesley, 1993. 8.3. Quality and reliability are related concepts, but are fundamentally different
“Implementing Software Inspections,” course notes, IBM Systems in a number of ways. Discuss them.
Sciences Institute, IBM Corporation, 1981. 8.4. Can a program be correct and still not be reliable? Explain.
Software Engineering Standards, 1994 edition, IEEE Computer Society, 8.6. Can a program be correct and still not exhibit good quality? Explain.
1994.
8.6. Why is there often tension between a software engineering group and an in-
Jahanian, F., and A.K. Mok, “Safety Analysis of Timing Properties of dependent software quality assurance group? Is this healthy?
Real-Time Systems,” Trans. Software Engineering, vol. SE-12, no.
9, September 1986, 8.7. You have been given the responsibility for improving the quality of
across your organization. What is the first thing that you should do? What’s next?
Jones, T.C., Programming Productivity, McGraw-Hill, 1986.
Kan, S.H., Metrics and Models in Quality Engineering, Addison- 8.6. Besides counting errors, are there other countable characteristics of software
Wesley, 1995. that imply quality? What are they and can they be measured directly?
Kaplan, C., R. Clark, and V. Tang, Secrets of Software Quality: 40 8.9. A formal technical review is effective only if everyone has prepared in ad-
from McGraw-Hill, 1995 vance. How do you recognize a review participant who has not prepared?
Leveson, “Software Why, Computing What do you do, if you’re the review leader?
vol. 18,no. 2, June 1986, pp. 125-163. 8.10. Some people argue that an FTR should assess programming style as well as
N.G., and J.L. Stolzy, “Safety Analysis using Petri Nets,” correctness. Is this a good idea? Why?
Engineering, vol. SE-13, no. 3, March 1987, 386-397. 8.11. Review Table 8.2 and select the four “vital few” causes of serious and
N.G., Safeware: System Safety and Computers, Addison-Wesley, ate errors. Suggest corrective actions using information presented in other
1995. chapters.
206 PART TWO MANAGING SOFTWARE PROJECTS CHAPTER 8: SOFTWARE QUALITY ASSURANCE 207
8.12. An organization uses a five-step software engineering process in which errors D., 9001 and Software Quality Assurance, McGraw-Hill, 1994.
are found according to the following percentage distribution: D., An to Software Quality Assurance and its Implementa-
tion, McGraw-Hill, 1994.
of Error Found Sanders, J., Software Framework for Success in Software Develop-
ment, Addison-Wesley, 1994.
20% Schulmeyer, G.G., and J.I. Total Quality Management for
2 15% Software, Van Nostrand Reinhold, 1992.
3 15% Sumner, F.H., Software Quality Assurance, Macmillan, 1993.
4 40%
5 10% Wallmuller, E., Software Quality Practical Approach,
Hall, 1995.
Weinberg, G.M., Quality Software three volumes, Dorset
Using Table 8.2 information and the percentage distribution above, compute House, 1992, 1993, 1994.
the overall defect index for the organization. Assume PS 100,000. J.W., J.M. Hiatt, and D.C. Trimble, Winning with
8.13. Research the literature on software reliability and write a paper that de- Quality Principles in Product Development, Addison-Wesley, 1995.
scribes one software reliability model. Be sure to provide an example.
8.14. The MTBF concept for software is open to criticism. Can you think of a few An anthology edited by Wheeler, Brykczynski, and Meeson (Software
reasons why? Inspection: Industry Practice, IEEE Computer Society Press, 1996) pre-
8.16. Consider two safety-critical systems that are controlled by computer. List at sents useful information on this important SQA activity. Friedman and Voas
least three hazards for each that can be directly linked to software failures. (Software Assessment, Wiley, 1995) discuss both theoretical underpinnings and
8.16. Acquire a copy of IS0 9001 and Prepare a presentation that dis- practical methods for ensuring the reliability and safety of computer programs.
cusses three IS0 9001 requirements and how they apply in a software context. The majority of published work in software reliability and software safety
can be found in recent technical papers. Lyu (Handbook of Software Reliability
Engineering, McGraw-Hill, 1996) has edited comprehensive handbook on soft-
ware reliability that is accompanied by a diskette with valuable data on soft-
FURTHER READINGS AND OTHER INFORMATION SOURCES ware failure and three reliability tools. Research in reliability modeling is dis-
cussed by Pham (Software and Testing, IEEE Computer Society
Press, 1995). The Proceedings of the Symposium on Software Reliability
Books by and Deming are excellent (Software Engineering Notes, special issue, August 1995) is an excellent com-
level presentations on the benefits of formal quality assurance programs. pendium of recent work.
Although they do not focus on software, both books are must reading for senior A reasonably wide variety of Internet sources are available for
managers with software development responsibility. Gluckman and Roome SQA and related subjects. The newsgroups comp.software-eng and
of the Quality Dorset House, 1993) humanizes often address SQA issues.
quality issues by telling the story of the players in the quality process. Kan General information on SQA can be obtained at the American Society for
(Metrics and Models in Software Quality Engineering, Addison-Wesley, 1995) Quality Control Web site:
presents a quantitative view of software quality.
There have been dozens of books written about software quality issues in
recent years. The following is a small sampling of useful sources:
Quality is of quality informa-
el al., Quality Control, Error Analysis and
tion and groups accessible over the World Wide Web:
Data Corp., Park Ridge, NJ, 1995.
Dobbins, J.H., Software Quality Assurance and Evaluation, ASQC Quality
Press, Milwaukee, WI, 1990.
Dunn, R.H., and R.S., for Computer Software, McGraw-Hill, Brief discussions andbibliographies on SQA topics can be found at:
1994.
Fenton, N., R. Whitty, and Iizuka, Software Quality Assurance and
Measurement: Worldwide Industrial Applications, Chapman Hall, 1994.
Ferdinand, A.E., Systems, Software, and Quality Engineering, Van Nostrand Software Testing Laboratories, Inc. presents a wide array of papers and dis-
Reinhold, 1993. cussion of software quality assurance:
PART MANAGING SOFTWARE PROJECTS
The WWW archive for formal technical reviews is the most extensive on-line
repository available for information on formal technical reviews, and includes
SOFTWARE
an extensive bibliography. checklists and other information can be
found at:
The NASA Formal Inspections Page contains a Formal Inspection Guidebook
CONFIGURATION
MANAGEMENT
and standard for the inspection process.
An extensive repository of information on safety-critical systems, software
safety, and hazard analysis can be found at:
An extensive guide to 9000 can be obtained at:
Additional information on IS0 9000 and related quality issues can be obtained
C in
of
project. Confusion
when computer
when not
built. And change increases
who
analyzed before they
working on
made,
from: . . recorded before they are implemented, reported to those with a need to know,
in a manner that will improve quality and reduce error. Babich
discusses this when he states:
IS0 Web Site
The art of coordinating software development to minimize confusion is
FAQ on IS0 standards called configuration management. Configuration management is the art of
identifying, organizing, and controlling modifications to the software being
built by a programming team. goal is to maximize productivity by mini-
mizing mistakes.
An IS0 9000 Bibliography
!
configuration is an umbrella activity that is
applied throughout the software process. Because change can occur at any time,
An up-to-date list of World Wide Web references for software quality assurance SCM activities are developed to identify change, (2) control change, en-
can be found at: sure that change is being properly implemented, and (4) report change
ers who may have an interest.
It is important to make a clear distinction between software maintenance
and software configuration management. Maintenance is a set of software en-
gineering activities that occur after software has been delivered to the
pul is a set of
tracking and control activities that begin when a software project begins and
terminate only when the software is taken out of operation.
209
210 PART TWO: MANAGING SOFTWARE PROJECTS CHAPTER 9 SOFTWARE CONFIGURATION MANAGEMENT 211
A primary goal of software engineering is to improve the ease with which modify project Why all this modification? The answer is really quite
changes can he accommodated and reduce the amount of effort expended when As passes all constituencies know more (about what they need,
changes must be made. in this chapter, discuss the specific activities that which approach would be best, and how to get it done and still make money).
enable us to manage change. This additional knowledge is the driving force behind most changes and leads
to a statement of fact that is difficult for many software engineering practi-
tioners to accept: Most changes are justified!
9.1 SOFTWARE CONFIGURATION MANAGEMENT A baseline is a software configuration management concept that helps us
to control change without seriously impeding justifiable change. The IEEE
(IEEE a baseline as:
The output of the software process is information that may be divided into
three broad categories: (1) computer programs (both source-level and exe- A specification or product that has been formally reviewed and agreed upon,
cutable forms), documents that describe the computer programs (targeted that the basis for further development, and that can be
at both technical practitioners and users), and datu (contained within the changed only through formal change control procedures.
program or external to it). The items that comprise all information produced as
part of the software process are collectively called a software configuration.
One way to baseline is through analogy:
As the software process progresses, the number of configuration
items grows rapidly. A system spawns a software project
plan and software requirements specification well as hardware related doc- Consider doors to the of a large restaurant. To eliminate collisions,
umental. These in turn spawn documents to a hicrurchy of infor- door is marked IN. doors have stops that
mation. If each simply spawned other little confusion would result. allow LO be opened only in the appropriate direction.
Unfortunately, another variable enters the process-change. Change may occur
If a waiter picks up an order in the kitchen. places it on a tray, and then real-
at any for any reason. In fact, the First Law of Engineering has dish, he may to the correct dish quickly
No in cycle, the will and informally before he leaves the kitchen,
change, to throughout the life cycle.
What is the origin of these changes? The answer to this question is as varied If, however, he leaves the kitchen, gives the customer the dish and then is in-
as the changes themselves. However, there are four fundamental sources of change: formed of his error, he must follow a set procedure: look at the check to
if an error has occurred; apologize profusely; return to the
!" new business or market conditions that dictate changes in product require- kitchen through the IN door; explain the problem, and so forth.
ments or business rules
!" new customer needs that demand modification of data produced by informa- A baseline is analogous to a dish as it passes through the kitchen door in
tion systems, functionality delivered by products, or services delivered by a the restaurant. Before a software configuration item becomes a baseline, change
computer-based system may be made quickly and informally. However, once a baseline is established,
we pass through a swinging one-way door. Changes can be made,
!" reorganization and/or business downsizing that causes changes in project pri-
but a specific, formal procedure must be applied to evaluate and verify each
orities or software engineering team structure
change
!" budgetary or scheduling constraints that cause a redefinition of the system In the context of software engineering, a baseline is a milestone in the de-
or product velopment of software that is marked by the delivery of one or more software
configuration items and the approval of these that is obtained through a
Software configuration management is a set of activities that have been formal technical review (Chapter For example, the elements of a design spec-
to manage change throughout the life cycle of computer software. SCM ification have been documented and reviewed. Errors are found and corrected.
can be viewed as a software quality assurance activity that is applied through- Once all parts of the specification have been reviewed, corrected and then ap-
out the software process, In the sections that follow, we examine major SCM proved, the design specification becomes a baseline. Further changes to the pro-
tasks and important concepts that help us to manage change. gram architecture (contained in the design specification) can be made only af-
ter has evaluated and approved. Although baselinus can defined
at any level of detail, the most common software baselines are shown in Figure
9.1.
9.1.1 Baselines The progression of events that lead to a baseline is illustrated in Figure
9.2. engineering tasks produce one or more After are re-
Change is a fact of life in software development. Customers want to modify re- viewed and approved, they are placed in a project database (also called a proj-
quirements. Developers want to modify technical approach. Managers want to ect library or software repository).When a member of a software engineering
212 PART WO: MANAGING SOFTWARE PROJECTS CHAPTER SOFTWARE 213
modified
System Specification
approved
Formal
technical
Software Requirements
reviews
Specification
Design Specification
extracted
SCM
controls
Test Plans/Procedures/Data
FIGURE 9.1. Operational System
Baselines FIGURE 9.2. Baselined and the project database
team wants to make a modification to a baselined SCI, it is copied from the
project database into the engineer’s private work space. However, this extracted
can be modified only if SCM controls (discussed later in chapter) are b. Process specifications
followed.’ The dashed arrows noted in Figure 9.2 illustrate the modification c. Prototype(s)
path for a baselined SCI. d. Mathematical specification
4. Preliminary User Manual
Design Specification
a. Data design description
9.1.2 Configuration
b. Architectural design description
c. Module design descriptions
We have already defined a software configuration item as information that is d. Interface design descriptions
created as part of the software engineering process. In the extreme, an could Object descriptions (if object-oriented techniques are used)
be considered to be a single section of a large specification or one test case in a 6. Source Code Listing
large suite of tests. More realistically, an is a document, an entire suite of 7. Test Specification
test cases, or a named program component (e.g., a C++ function or an a. Test plan and procedure
package). b. Test cases and recorded results
The following become the target for configuration management tech- 8. Operation and Installation Manuals
niques and form a set of baselines: 9. Executable Program
a. Module executable code
1. System Specification b. Linked modules
2. Software Project Plan 10. Database Description
3. Software Requirements Specification a. Schema and file structure
a. Graphical analysis models b. Initial content
214 PART TWO MANAGING SOFTWARE PROJECTS CHAPTER 9: SOFTWARE CONFIGURATION 215
11. As-built User Manual !" Who has responsibility for approving and prioritizing changes?
12. Maintenance Documents !" How can we assure that changes have been made properly?
a. Software problem reports
!" What mechanism is used to apprise others of changes that are made?
b. Maintenance requests
c. Engineering change orders
13. Standards and Procedures for Engineering These questions lead us to the definition of five SCM tasks:
sion control, change control, auditing, and reporting.
In addition to the noted above, many software engineering organizations
also place software tools under configuration control. That is, specific versions
of editors, compilers, and other CASE tools are “frozen” as part of the software
configuration. Because these tools were used to produce documentation, source 9.3 OF OBJECTS IN THE SOFTWARE CONFIGURATION
code, and data, they must be available when changes to the software configu-
ration are to Although are rare, it is that a now
sion of a tool a compiler) might produce different results than the origi- To control and manage software configuration items, each must he separately
nal version. For this reason, tools, like the software that they help to produce, named and then organized using an object-oriented approach. Two types of ob-
can be baselined as part of a comprehensive configuration management process. jects can be identified basic objects and aggregate A basic ob-
In reality, are organized to form objects that may be ject is a “unit of text” that has been created by a software engineer during
alogued in the project database with a single name. A configuration object has analysis, design, coding, or testing. For example, a basic object might be a sec-
a name, attributes, and is “connected” to other objects by relationships. In tion of a requirements specification, a source listing for a module, or a suite of
Figure 9.3, the configuration objects design specification, data model, mod- test cases that are used to exercise the code. An aggregate object is a collection
ule N, source code, and test specification are each defined separately. of basic objects and other aggregate objects. In Figure 9.3, design specification
However, each of the objects is related to the others as shown by the arrows. A is an aggregate object. Conceptually, it can be viewed as a named (identified)
curved arrow indicates a compositional relation. That is, data model and of pointers that specify basic objects such as data model and module N.
module N are part of the object design specification.A Each object has a set of distinct features that identify it uniquely: a name,
straight arrow indicates an interrelationship. If a change were made to the a description, a list of resources, and a “realization.” The object name is a char-
source code object, interrelationships enable a software engineer to determine acter string that identifies the object unambiguously. The object description is
what other objects (and might be affected.’ a list of data items that identify:
the type document, program, data) that is represented by the object;
9.2 THE SCM PROCESS !"a project identifier; and change and/or version information.
Software configuration management is an important element of software qual- Resources are “entities that are provided, processed, referenced or otherwise
ity assurance. Its primary responsibility is the control of change. However, SCM
quired by the object” For example, data types, specific functions, or
is also responsible for the identification of individual and various versions
even variable names may be considered to object resources. The realization is
of the software, the auditing of the software configuration to ensure that it has a pointer to the “unit of text” for a basic object and for an aggregate
been properly developed, and the reporting of changes applied to the con- Configuration object identification must also consider the relationships
figuration.
that exist between named objects. An object can be identified as an
Any discussion of SCM introduces a set of complex questions:
aggregate object. The relationship defines a hierarchy of For
example, using the simple notation,
!" How does an organization identify and manage the many existing versions
of a program (and its documentation) in a manner that will enable change to
E-R diagram 1.4 data model;
be accommodated efficiently?
data model Design Specification;
!" How does an organization control changes before and after software is re-
we create a hierarchy of
leased to a customer?
‘These relationships are discussed in Section 9.2.1, and the structure of the project database concept of an aggregate object has been proposed a mechanism for repre-
will be discussed in greater detail in Chapter 29. senting a complete version of a software configuration.
216 PART MANAGING SOFTWAREPROJECTS CHAPTER 9: SOFTWARE CONFIGURATION MANAGEMENT 217
In the first case, the interrelationship is between a composite object, while the
Data model second relationship is between an aggregate object (data model)and a basic
object (test case class
The interrelationships between configuration objects can be represented
with a module interconnection language A MIL describes the
interdependencies among configuration objects and enables any version of a
system to be constructed automatically.
Design specification The identification scheme for software objects must recognize that objects
evolve throughout the software process. Before an object is baselined, it may
data design ----- change many times, and even after a baseline has been established, changes
may be quite frequent. It is possible to create an evolution graph [GUS891 for
architectural design
any object. The evolution graph describes the change history of the object and
module design is illustrated in Figure 9.4. Configuration object 1.0 undergoes revision and be-
comes object 1.1. Minor corrections and changes result in versions 1.1.1 and
which is followed by major is object 1.2. The evolution of
object 1.0 continues through 1.3 and 1.4, but at the same time, a major modi-
fication to the object results in a path, version 2.0. Both ver-
Module N sions are currently supported.
It is possible that changes may be made to any version, but not necessar-
ily to all versions. How does the developer reference all modules, documents,
interface description
and test cases for version How does the marketing department know what
algorithm description
customers currently have version How can we be sure that changes’
PDL to version 2.1 source code are properly reflected in corresponding design
documentation? A key element in the answer to all of the above questions is
Test specification identification.
A variety of automated SCM tools CCC, RCS, Aide-dc-Camp)
test plan have been developed to aid in identification (and other SCM) tasks. In some
cases, a tool is designed to maintain full copies of only the most recent version.
test procedure
To achieve earlier versions (of documents or programs) changes by
test cases the tool) are “subtracted” from the most recent version This scheme
makes the current configuration immediately available and other versions
easily available.
Source code
9.3.
objects
It is unrealistic to assume that the only relationships among objects in an
object hierarchy are along direct paths of the hierarchical tree. In many cases,
objects are interrelated across branches of the object hierarchy. For example,
data modelis interrelated to data flow diagrams (assuming the use of struc-
tured analysis) and also interrelated to a set of test cases for a specific
nlence class. cross-structural can in
lowing
FIGURE 9.4.
graph
CHAPTER 9: SOFTWARE CONFIGURATION MANAGEMENT
218 PART TWO: MANAGING SOFTWARE PROJECTS 219
variants
obj
1.0
components
Evolution graph showing
revisions of the software
variants FIGURE 9.6.
pool versions
senbtion of
variants, and
FIGURE 9.5. versions
Versions and
posed of different To illustrate this concept, consider a version of a
simple program that is composed of components 1, 2, 3, 4, and 5 (Figure
9.4 VERSION CONTROL
Component 4 is used only when the software is implemented using color dis-
plays Component 5 is implemented when monochrome displays are available.
Version control combines procedures and tools to manage different versions of Therefore, two variants of the version can be defined: components 1, 2, 3,
configuration objects that are created during the software engineering process. and 4; components 1, 2, 3, and 5.
Clemm describes version control in the context of SCM: To construct the appropriate variant of a given version of a program, each
component can be assigned an list of features that will de-
Configuration management allows a user to specify alternative fine whether the component should be used when a particular variant of a soft-
tions of the software system through the selection of appropriate versions. This ware version is to be constructed. One or more attributes is assigned for each
is supported by associating attributes with each software version, and then al- variant. For example, a color attribute could be used to define which compo-
lowing a configuration to be specified [and constructed] by describing the set of nent should be included when color displays are to be supported.
desired attributes. Another way to conceptualize the relationship between components, vari-
ants and versions (revisions) is to represent them as an object As
The “attributes” mentioned above can be as simple as a specific version num- Figure 9.6 shows, the relationship between configuration objects and compo-
ber that is attached each object or as complex as a string of boolean vari- nents, variants, and versions can be represented as a three-dimensional space.
ables (switches) that indicate specific types of functional changes that have
been applied to the system
One representation of the different versions of a system is the evolution
graph presented in Figure 9.4. Each node on the graph is an aggregate object, “In this context, the term “component” refers to all composite objects and basic objects that
that is, a complete version of the software. Each version of the software is a col- for a For example, an “input” component might be constructed with six differ-
lection of (source code, documents, data), and each version may be ent software modules, each responsible for input subfunction.
CHAPTER SOFTWARE CONFIGURATION MANAGEMENT 221
220 PART TWO: MANAGING SOFTWARE PROJECTS
A component is composed of a collection of objects at the same revision level, Need for change is recognized
A variant is a different collection of objects at the same revision level and t
therefore coexists in parallel with other variants. A new version is defined Change user
when major changes are made to one or more objects.
A number of different automated approaches to version control have been t
proposed over the past decade. The primary difference in approaches is the so- Developer evaluates
phistication of the attributes that are used to construct specific versions and t
variants of a system and the mechanics of the process for construction. In early Change report is generated
systems, such as SCCS attributes took on numeric values. In later
systems, such as RCS symbolic revision keys were used. Modern t
terns, such as NSE or DSEE create version specifications that can be Change control authority decides
used to construct variants or new versions. These systems also support the
baselining concept, thereby precluding uncontrolled modification (or deletion)
of a particular version. Request is queued for action, generated request is denied
t
Assign individuals to configuration objects User is informed
9.5 CHANGE CONTROL
t
“Check out” configuration objects (items)
For a large software development project, uncontrolled change rapidly leads
to chaos. Change control combines human procedures and automated tools to
provide a mechanism for the control of change. The change control process is Make the change
illustrated schematically in Figure 9.7. A change is submitted and
evaluated to assess technical merit, potential side effects, overall impact on t
Review (audit) the change
other configuration objects and system functions, and the projected cost of
the change. The results of the evaluation are presented as a change report t
that is used by a change control authority person or group who “Check in” the configuration items that have been changed
makes a final decision on the status and priority of the change. An engi-
neering change order is generated for each approved change. The
describes the change to be made; the constraints that must be respected, and Establish a baseline for tasting
the criteria for review and audit. The object to be changed is “checked out”
of the project database, the change is made, and SQA activities
Perform quality assurance and testing activities
are applied. The object is then “checked in” to the database and appropriate
version control mechanisms (Section 9.4) are used to create the next version
of the software. “Promote” changes for inclusion in next release (revision)
The “check-in” and “check-out” processes implement two
ments of change control-access control and synchronization control. Access
control governs which software engineers have the authority to access and Rebuild appropriate version of software
modify a particular configuration object. control helps to t
sure that parallelehanges, performed by two different people, don’t overwrite Review (audit) the change to all configuration items
one another I
Access and synchronization control flow is illustrated schematically in t
Figure 9.8. Based on an approved change request and ECO, a software Include changes in new version
neer checks out a configuration object. An access control function ensures that
the software engineer has authority to check out the object,-and
Distribute the new version
FIGURE 9.7. The change control process
many change requests are submitted during the maintenance phase, we
take broader view in this discussion. A request for change occur at any time during the
software process.
PART TWO. MANAGING SOFTWARE PROJECTS CHAPTER 9: SOFTWARE CONFIGURATION MANAGEMENT 223
222
the product is released to customers, change control
is instituted. The formal change control procedure has been outlined in Figure
9.7.
The change control authority plays an active role in the second and
third layer of control. Depending on the size and character of a software proj-
ect, the CCA may be comprised of one person-the project manager-or a num-
ber of people (e.g., representatives from software, hardware, database engi-
neering, support, marketing, etc.). The role of the CCA is to take a global view,
that is, to assess the impact of change beyond the in question. How will
the change impact hardware? How will the change impact performance? How
will the change modify the customer’s perception of the product? How will the
change affect product quality and reliability? These and many other questions
are addressed by the CCA.
configuration object 9.6 CONFIGURATION AUDIT
Identification, control, and change control help the software developer
to maintain order what would otherwise be a chaotic and fluid situation.
However, even the most successful control mechanisms track a change only un-
FIGURE 9.8. til an is generated. How can we ensure that the change has been prop-
Access a n d erly implemented? The answer is twofold: formal technical reviews and (2)
control the software configuration audit.
The formal technical review (presented in detail in Chapter focuses on
the technical correctness of the configuration object that has been modified.
tion control locks the object in the project database so that no updates can be The reviewers assess the to determine consistency with other omis-
made to it until the version currently checked out has replaced. Note that sions, and potential side effects. A formal technical review should conducted
other copies can be checked out, but other updates cannot be made. A copy of for all but the most trivial changes.
the baselined object, called the “extracted version,” is modified by the software A software audit complements the forma1 technical review by
engineer. After appropriate SQA and testing, the modified version of the object assessing a configuration object for characteristics that are generally not con-
is checked in and the new baseline object is unlocked. sidered during review. The audit asks and answers the following questions:
Some readers may begin to feel uncomfortable with the level of bureau-
implied by the change control process This feeling is not un- 1. Has the change specified in the been made? Have any additional mod-
common. Without proper safeguards, change control can retard progress and ifications been incorporated?
create unnecessary red tape. Most software developers who have change con- 2. Has a formal technical review been conducted to technical correct-
trol mechanisms (unfortunately, many have none) have created a number of ness?
layers of control to help avoid the problems alluded to above.
Prior to an becoming a baseline, only informal change control need be 3. Have software engineering standards been properly followed?
applied. developer of the object in question may make 4. Has the been “highlighted” in the SCI? Have the change date and
whatever changes are justified by project and technical requirements (as long change author been specified? Do attributes of the configuration object
as changes do not impact broader system requirements that lie outside the de- reflect the change?
_ veloper’s scope of work). Once the object has undergone formal technical review 5. Have SCM procedures for noting the change, recording it, and reporting it
and has been approved, a baseline is created. Once an becomes a baseline, been followed?
project level change control is implemented. Now, to make a change, the devel-
6. Have all related been properly updated?
oper must gain approval from the project manager (if the change is “local”) or
from the CCA if the change impacts other In some cases, formal genera-
tion of change requests, change reports, and is dispensed with. However, In some cases, the audit questions are asked as part of a formal technical re-
assessment of each change is conducted and all changes are tracked and re- view. However, when SCM is a formal activity, the SCM audit is conducted sep-
viewed. arately by the quality assurance group.
224 PART MANAGING SOFTWARE PROJECTS CHAPTER 9: SOFTWARE CONFIGURATION MANAGEMENT 225
9.7 STATUS Once a object has been developed and reviewed, it becomes a
baseline. Changes a baselined object result in the creation of a new version
Configuration status reporting (sometimes called status accounting) is an SCM‘ of that object. The evolution of a program can be tracked by examining the re-
task that answers the following questions: What happened? Who did it? vision history of all configuration objects. Basic and aggregate objects form an
When did it h appen? What else will be affected? object pool from which variants and versions are created. Version control is the
The flow of information for configuration status reporting is illus- set of procedures and tools for managing the use of these objects.
trated in Figure 9.7. Each time a is assigned new or updated identifica- Change control is a procedural activity that ensures quality and consis-
tion, a CSR entry is made. Each time a change is approved by the CCA (i.e., an tency as changes are made to a configuration object. The change control process
is issued), a CSR entry is made. Each time a configuration audit is con- begins with a change request, leads to a decision to make or reject the request
ducted, results reported as part of the CSR task. Output from CSR may for change, and culminates with a controlled update of the that is to be
be placed in an on-line database so that software developers or main- changed.
tainers can access change information by keyword category. In addition, a SCR The configuration audit is an activity that helps to ensure that qual-
report is generated on a regular basis and is intended to keep management and ity is maintained as changes are made. Status reporting provides information
practitioners appraised of important changes. about each change to those with a need to know.
Configuration status reporting plays a vital role in the success of a large
software development project. When many people are involved, it is likely that
“the left hand not knowing what the right hand is doing” syndrome will occur.
REFERENCES
Two attempt to modify the with con-
flicting intent. A software engineering team may spend months of effort build-
ing software to an obsolete hardware specification. The person who would rec- [ADA891 Adams, E., M. Honda, and T. Miller, “Object Management in a CASE
ognize serious side effects for a proposed change is not aware that the change Environment,” 11th Software Engineering, IEEE,
is being made. CSR helps to eliminate these problems by improving communi- Pittsburgh, PA, May 1989, pp. 154-163.
cation among all people involved. Babich, W.A., Software Configuration Management, Addison-Wesley,
1986.
Bersoff, E.H., V.D. Henderson, and S.G. Siegel, Software Configuration
9.8 SCM STANDARDS Management, Prentice-Hall, 1980.
Choi, S.C., and Scacchi, “Assuring the Correctness of a Configured
Software Description,” 2nd Workshop on Software Configura-
Over the past two decades a number of software management
tion Management, ACM, Princeton, NJ, October 1989, pp. 66-75.
standards have been proposed. Many early SCM standards, such as
Clemm, G.M., “Replacing Version Control with Job Control,” 2nd
483, and focused on software developed for
Workshop on Software Configuration Management, ACM, Princeton,
military applications. However, more recent ANSI/IEEE standards, such as
NJ, October 1989, pp. 162-169.
ANSI/IEEE Std. No. 828-1983, Std. No. and Std. No. 1028-1988
[GUS891 Gustavsson, A., “Maintaining the Evaluation of Software Objects in an
are applicable for commercial software and are recommended for both
Integrated Environment,” 2nd Zntl. Workshop on Software
large and small software engineering organizations. ration Management, ACM, Princeton, NJ, 1989, pp. 114-117.
R., “Configuration Management,” HP Professional, vol. 3, no. 6,
June 1989.
9.9 SUMMARY
Software Engineering Standards, 1994 edition, IEEE Computer Society,
1994.
Software configuration management is an umbrella activity that is applied [LIE891 Lie, A., et al., “Change Oriented Versioning in a Software Engineering
throughout the process. SCM identifies, and reports Database,” 2nd Workshop on Software Configuration Manage-
modifications that invariably occur while software is being developed and after ment, ACM, Princeton, NJ, October 1989, pp. 56-65.
it has been released to a customer. All information produced as part of the soft- Narayanaswamy, K., and Scacchi, “Maintaining Configurations of
ware process becomes part of a software configuration. The configuration is or- , Evolving Software Trans. Software Engineering, vol.
ganized in a manner that enables orderly control of change. 13, no. 3, March 1987, pp. 324-334.
The configuration is composed of a set of interrelated also IRE1891 Reichenberger, C., “Orthogonal Version Management,” 2nd
called software items, that are produced as a result of some soft- Workshop on Software Configuration Management, ACM, Princeton, NJ,
ware engineering activity. In addition to documents, programs, and data, the October 1989, pp.
development environment that is used to create software can also be placed un- Rochkind, M., “The Source Code Control System,” Software
der configuration control. Engineering, vol. SE-l, no. 4, December 1975, pp.
226 PART MANAGING SOFTWARE PROJECTS CHAPTER 9: SOFT ARE
W CONFIGURATION MANAGEMENT 227
Taylor, B., “A Database Approach Configuration Management for Management, McGraw-Hill, 1992) present a good overview for those who have
Large Projects,” Software Maintenance-1985, IEEE, not yet been introduced to the subject. Another hook by these authors
November pp. a comprehensive
W.F., “Design, Implementation and Evaluation of a Revision guide to the development and management of the documentation. Berlack
Control System,” 6th Software Engineering, IEEE, Tokyo, , Configuration Management, Wiley, 1992) presents a survey of SCM
September 1982, pp. 58-67. concepts, emphasizing the importance of the repository and tools in the man-
agement of change. Babich is an abbreviated, yet effective, treatment
of pragmatic issues in software configuration management.
PROBLEMS AND POINTS TO PONDER Buckley Configuration Management, IEEE Computer Soci-
ety Press, considers configuration management approaches for all system
elements-hardware, software, and firmware with detailed discussions of ma-
9.1. Why is the First Law of System Engineering true? How does it affect our per-
jor CM activities. Rawlings (SCM for Network Development Environments,
ception of software engineering paradigms. McGraw-Hill, is the first SCM book to address the subject with a specific
9.2. Discuss the reasons for baselines in your own words. emphasis on software development in a networked environment.
9.3. Assume that you’re the manager of a small project. What baselines would you and Tools for Software Configuration Management, Wiley, 1991) con-
define for the project and how would you control them? tains reasonable coverage of all important SCM topics, but is distinguished by
9.4. Design a project database system that would enable a software engineer to discussion of repository and CASE environment issues. Arnold and Bohner
store, cross-reference, trace, update, change, etc. all important con- (Software Change Impact Analysis, IEEE Computer Society Press, 1996) have
figuration items. How would the database handle different versions of the edited an anthology that discusses how to analyze the impact of change within
same program? Would source code be handled differently than documenta- complex software-based systems.
tion? How will two developers be precluded from making different changes to A number of Internet sources are available for SCM information. The
the same at the same time? is
group comp.software.config-mgmt dedicated to configuration manage-
ment issues, including discussion of SCM tools. The Configuration Management
9.6. Do some research on object-oriented databases and write a paper that de- Yellow Pages contains many pointers to SCM information and tools on the in-
scribes how they can be used in the context of SCM. ternee and can be found at:
9.6. Use an E-R model (Chapter 12) to describe the interrelationships among the
(objects) listed in section 9.1.2.
9.7. Research an existing SCM tool and describe how it implements control for
versions, variants, and configuration objects in general.
9.8. The relations and represent simple relationships be- Pointers to the configuration management FAQ as well as other use-
tween configuration objects. Describe five additional relationships that might ful information about SCM can be obtained from:
be useful in the context of a project database.
Research an existing SCM tool and describe how it implements the mechan-
ics of version control. Alternatively, read two or three of the papers referenced
in this chapter and describe the different data structures and referencing
mechanisms that are used for version control. Information on software configuration management in the context of the
9.10. Using Figure 9.7 as a guide, develop an even more detailed work breakdown capability maturity model (Chapter can be obtained at:
for change control. Describe the role of the CCA and suggest formats for the
change request, the change report, and the ECO.
9.11. Develop a checklist for use during configuration audits.
An up-to-date list of World Wide Web references for software configuration
9.12. What is the difference between an SCM audit and a formal technical review?
Can their function be folded into one review? are the pros and cons? management can be found at:
FURTHER READINGS AND OTHER INFORMATION SOURCES
The literature on software configuration management has expanded signifi-
cantly over the past few years. and (Software Configuration
CONVENTIONAL
METHODS FOR
SOFTWARE
ENGINEERING
we
In this part of Software Engineering: A Practitioner’s Approach consider the technical concepts,
methods, and measurements that are applicable for the analysis, design, and testing of computer soft-
ware. In the chapters that follow, we address the following questions:
!" How is defined within the context of a larger system and where do product engineering
and information engineering play a role?
!" What are the basic concepts and principles that are applicable to the analysis of software re-
quirements?
!" What is structured analysis and how do its various models enable a software engineer to under-
stand data, function, and behavior?
!" What are the basic concepts and principles that are applied to software design activity?
!" How are design models for data, architecture, procedure, and interfaces created?
!" What are the unique characteristics of real-time systems and how do these characteristics affect
the manner in which such systems are analyzed and designed?
!" What are the basic concepts and principles that are applicable to the software testing?
!" How are black-box and white-box testing methods used to design effective test cases?
!"What is the strategy for software testing?
!" What technical metrics are available for assessing the quality of analysis and design models, source
code, and test cases?
Once these questions are answered, you’ll understand how to build using a disciplined en-
gineering approach.
SYSTEM ENGINEERING
F our hundred and eighty years ago, Machiavelli said “there is nothing more
to take in hand, more perilous to conduct or more uncertain in its
success, than to take the lead in the introduction of a new order of things. .
During the last quarter of the twentieth century, computer-based systems have
introduced a new order. Although technology has made great strides since
Machiavelli spoke, his words continue to ring true.
Software engineering occurs a consequence of a process, called system
Instead of concentrating solely on software, system engineering fo-
cuses on a variety of elements, analyzing, designing, and organizing those ele-
ments into a system that can be a product, a service, or a technology for the
transformation of information or control.
The system engineering process is called information engineering when the
context of the engineering work focuses on a business enterprise. When a prod-
uct is to be built,’ the process is called product engineering.’
Both information engineering and product engineering attempt to bring or-
der to the development of computer-based systems. Although each is applied in
a different application domain, both strive to put software into context. That is,
both information engineering and product engineering work to allocate a role
for computer software and to establish the links that tie software to other ele-
ments of a computer-based system.
this context, the term “product” includes everything from cellular telephones to a
kind high-technology system (e.g., air traffic control system).
reality, the term “system engineering” is often used in this context. However, this book,
the term “system engineering” is generic and is used encompass both engi-
neering and product
231
232 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 233
10.1 COMPUTER-BASED SYSTEMS Figure 10.1. At the lowest level of the hierarchy we have a numerical control
machine, robots, and data entry devices. Each is a computer-based system in
The word “system” is possibly the most overused and abused term in the tech- its own right. The elements of the numerical control machine include electronic
nical lexicon. We speak of political systems and educational systems, of avionics and electromechanical hardware (e.g., processor and memory, motors, sensors);
software (for communications, machine control, and interpolation); people (the
systems and manufacturing systems, of banking systems and subway systems.
machine operator); a database (the stored NC program); and documentation
The word tells us little. We use adjective describing “system” to understand
and procedures. A similar decomposition could be applied to the robot and data
the context in which tho word is used. Webster’s Dictionary defines “system” as
entry device. Each is a computer-based system.
“a set or arrangement of things so related as to form a unity or organic whole. a
At the next level in the hierarchy (Figure a manufacturing cell is de-
set of facts, principles, rules, etc., classified and arranged in an orderly form so
fined. The manufacturing cell is a computer-based system that may have ele-
as to show a logical plan linking the various parts . . . a method or plan of clas-
ments of its own (e.g., computers, mechanical fixtures) and also integrates the
sification or arrangement . an established way of doing something; method;
macro elements that we have called numerical control machine, robot, and data
procedure. Five additional definitions are provided in the dictionary, yet no
entry device.
precise synonym is suggested. “System” is a special word.
To summarize, the manufacturing cell and its macro elements each are
Borrowing from Webster’s definition, we a computer-based system as:
comprised of system elements with the generic labels: software, hardware, peo-
ple, database, procedures, and documentation. In some cases, macro elements
A set or arrangement of elements that are organized to accomplish some may share a generic element. For example, the robot and the NC machine
defined goal by processing information. might both be managed by a single operator (the people element). In other
cases, generic elements are exclusive to one system.
The goal may be to support some business function or to develop a product that The role of the system engineer is to define the elements for a specific com-
can be sold to generate business revenue. To accomplish the goal, a puter-based system in the context of the overall hierarchy of systems (macro
based system makes use of a variety of system elements: elements). In the sections that examine the tasks that constitute
computer system engineering.
Software. Computer programs, data structures, and related documenta-
tion serve to effect the logical method, procedure, or control that is
required. Factory Automation System
Hardware. Electronic devices that provide computing capability, and
electromechanical devices (e.g., sensors, motors, pumps) that provide ex-
ternal world function.
People. Users and operators of hardware and software.
Database. A large, organized collection of information that is accessed via
Manufacturing Inventory Information
software.
System System System
Documentation. Manuals, forms, and other descriptive information that
portrays of system.
Procedures. The steps that define the specific use of each system element
or the procedural context in which the system resides.
The elements combine in a variety of ways to transform information. For exam-
ple, a marketing department transforms raw sales data into a profile of the typ-
ical purchaser of a product, and a robot transforms a command file containing
specific instructions into a set of control signals that cause some specific physi-
cal action. Creating an information system to assist the marketing department
and control software to support the robot both require system engineering.
One complicating characteristic of computer-based systems is that the
elements comprising one system may also represent one macro element of a
still larger system. The macro element is a computer-based system that is one
part of a larger computer-based system. As an example, we consider a “factory FIGURE 10.1.
automation system” that is essentially a hierarchy of systems shown in A system of systems
234 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 235
10.2 THE SYSTEM ENGINEERING HIERARCHY proper business or technology context can be established. The world view is
fined to focus more fully on specific domain of interest. Within a specific domain,
the need for targeted system elements (e.g., data, software, hardware, people) is
Regardless of its domain of focus, system engineering encompasses a collection
analyzed1 Finally, the analysis, design, and construction of a targeted system el-
of top-down and bottom-up methods navigate the hierarchy illustrated in
, ement is initiated. At the top of the hierarchy a very broad context is established,
Figure 10.2. The system engineering process usually begins with a “world view.”
and at the bottom, detailed technical activities, performed by the relevant engi-
That is, the entire business or product domain to ensure that the
neering discipline (e.g., hardware or software engineering), are conducted.”
Stated in a slightly more formal manner, the world view is composed
of a set of domains which can each be a system or system of systems in
its own right.
W V =
Business or I
Product Domain Each domain, is composed of specific elements each of which serves some
I World view role in accomplishing the objective and goals of the domain:
..
Finally, each element is implemented by specifying the technical components
domain of interest that achieve the necessary function for an element.
= . .
In the software context, a component could be a computer program, a reusable
program an or or even a programming lan-
guage statement.
It is important to note that the system engineer narrows the focus of work
as he or she moves downward in the hierarchy described above. However, the
world view portrays a clear definition of overall functionality that will enable
Domain view the engineer to understand the domain, and ultimately the system or product,
in the proper context.
10.2.1 System Modeling
System engineering is a modeling process. Whether the focus is on the world
view or the detailed view, the engineer creates models that
!"define the processes that serve the needs of the view under consideration
!" represent the behavior of the processes and the assumptions on which the
behavior is based
!" explicitly define both exogenous and to the model
!" represent all linkages (including output) that will enable the engineer to bet-
ter understand the view
situations, however, system engineers must first consider individual system elements
detailed requirements. Using this approach, subsystems described bottom-up by
F I G U R E 10.2. first considering constituent detailed components of the subsystem.
The system
ing Detailed view
236 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 237
To construct a system model, the engineer should consider a number of re- 10.2.2 Information Engineering: An Overview
straining factors:
The goal of information engineering is to define architectures that will en-
able a business to use information effectively. In addition, information engi-
1. Assumptions that reduce the number of nossible and neering works to create an overall plan for implementing those architectures
tions, thus enabling a model to reflect a reasonable manner. Three different architectures must be analyzed and designed within
As an example, consider a three-dimensional rendering product used by the the context of business objectives and goals:
entertainment industry to create realistic animation. One domain of the
product enables the representation of 3D human forms. Input to this do-
main encompasses the ability to input movement from a live human !" data architecture
from video, or by the creation of graphical models. The system engi- !" applications architecture
neer makes certain assumptions about the range of allowable human !" technology infrastructure
movement (e.g., legs cannot be wrapped around the torso) so that the range
of inputs and processing can be limited.
The data architecture provides a framework for the information needs of a busi-
2. Simplifications that enable the model to be created in a timely manner. ness or business function. The individual building blocks of the architecture are
To illustrate, consider an office company that sells and services the data objects (to be discussed in Chapter that are used by the business.
a broad range of copiers, fax machines, and related equipment. The sys- The data objects flow between business functions, are organized within a data-
tem engineer is modeling the needs of the service organization and is base, and are transformed to provide information that serves the needs of the
working to understand the flow of information that spawns a service business.
order. Although a service can be derived from many origins, the en- The application architecture encompasses those elements of a system that
gineer categorizes only two sources: internal demand or external request, transform within the data architecture for some business purpose. In
This enables a simplified partitioning of input that is required to gener- the context this book, we normally consider the application architecture to
ate the work order. be the system of programs (software) that performs this transformation.
However, in a broader context, the application architecture might incorporate
3. Limitations that help to bound the system. For example, an aircraft avion- the role of people (who are information transformers and users) and business
ics system is being modeled for a next generation aircraft. Since the air- procedures that have not been automated.
craft will be a two-engine design, all monitoring domains for propulsion will The technology infrastructure provides the foundation for the data and ap-
be modeled to accommodate a maximum of two engines and associated re- plication architectures. The infrastructure encompasses the hardware and soft-
dundant systems. ware that are used to support applications and data. This includes computers
and computer networks, telecommunication links, storage technologies, and the
4. Constraints that will guide the manner in which the model is created and
(e.g., client/server) that has been designed to implement these
the approach taken when the model is implemented. For example, the tech-
nology infrastructure for the three-dimensional rendering system described technologies.
To model the system architectures described earlier, a hierarchy of infor-
above is a single processor. The computational complexity
mation engineering activities is defined. As shown in Figure 10.3, the world
of problems must be constrained to within the processing bounds im-
view is achieved through information strategy planning ISP views the
posed by the processor.
entire business as an entity and isolates the domains of the business (e.g.,
5. Preferences that indicate the preferred architecture for all data, functions, marketine. finance. sales) that are to the
and technology Tbe preferred solution sometimes comes into conflict with overall enterprise. ISP defines the data objects that are visible-at the
other restraining factors. Yet, customer satisfaction is often predicated on level. their relationshios. and how they flow between the business do-
_
the degree to which the preferred approach is realized. mains
The domain view is addressed an IE activity called business urea
analysis (BAA). Hares describes BAA in the following manner:
The resultant system model (at any view) may call for a completed auto-
mated solution, a semi-automated solution, or a manual approach. In fact, it is
often possible to characterize models of each type that serve as alternative so-
lutions to the problem at hand. In essence, the system engineer simply modi- should be noted that the terminology used in Figure 10.3 is not used in the
fies the relative influence of system elements (people, hardware, soft- literature. However, the of focus implied by each IE activity is by all who con-
ware) to derive models of each type. sider the subject.
238 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 239
ness functions and procedures that enable the business area to meet its objec-
tives and goals. BAA, like ISP, defines data objects, their relationships, and how
Information data flow. But at this level, these characteristics are all bounded by the busi-
Strategy Planning ness area being analyzed. The outcome of BAA is to isolate areas of opportu-
(World view) nity in which information systems may support the business area.
Once an information system has been isolated for further development, IE
makes a transition into software engineering. By invoking a business system
design step, the basic requirements of a specific information system are
modeled and these are translated into data architecture, appli-
cations architecture, and technology infrastructure.
The final IE step-construction and integration focuses on imple-
mentation detail. The architecture and infrastructure are implemented by con-
Business structing an appropriate database and internal data structures, by building ap-
A business area
Area Analysis plications using program components, and by selecting appropriate elements of
(Domain view) a technology infrastructure to support the design created during BSD. Each of
these system components must then be integrated to form a complete infor-
mation system or application. The integration activity also places the new in-
formation system into the business area context, performing all user training
and logistics support to achieve a smooth transition.
Product Engineering: An Overview
Business System
Design The goal of product engineering is to translate the customer’s desire for a set
(Element view) of defined capabilities into a working To achieve this en-
gineering-like information engineering-must derive architecture and infra-
structure. The architecture encompasses four distinct system components: soft-
ware, hardware, data (and databases), and people. A support is
Software established and includes the technology required to tie the components to-
gether and the information (e.g., documents, CD-ROM, video) that is used to
Engineer
support the components.
As shown in Figure 10.4, the world view is achieved through system analysis.
The overall requirements of the product are elicited from the customer. These re-
quirements encompass information and control needs, product function and be-
havior, overall product performance, design, and interfacing constraints, and other
FIGURE 10.3. , , , , , , , , , , , , , , , , , , , , , , (Detailed view) special needs. Once these requirements are known, the job of system analysis is
The information engi- to function and behavior to each of the four components noted above.
neering hierarchy Once allocation has occurred, component engineering commences. Compo-
nent engineering is actually a set of concurrent activities that address each of
the components engineer-
ing, human engineering, and database engineering. Each of these engineering
BAA is with in detail form of entity [data
disciplines takes a domain-specific view, but it is important to note that the en-
jectl types) and function requirements the form of processes1 of selected gineering disciplines must establish and maintain active communication with
business areas [domains] identified during ISP and ascertaining their interac- one another. Part of the role of system analysis is to establish the interfacing
tions (in the form of matrices). It is only concerned with specifying what is re- mechanisms that will enable this to happen.
quired in a business area.
As information engineer begins BAA, the focus narrows to a specific busi- engineering is also applied to the development of one-of-a-kind high-technology sys-
ness domain. BAA views the business area as an entity and isolates the busi- tems an air traffic control system).
CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER IO: SYSTEM ENGINEERING 241
1 0 . 3 ENGINEERING
The complete
product System analysis When business automation was first introduced in the early companies
I (World view) looked for areas of opportunity and simply automated business functions that
were previously performed in a manual fashion. As time passed, individual
computer programs were combined to encompass business applications. The ap-
plications were grouped into major information systems that served specific
business areas. Although this approach was workable, it resulted in problems.
Systems were difficult to “connect” to one another; redundant data was every-
where; the impact of changes to applications that served one area of the busi-
ness was to project and even more to implement; and old pro-
grams outlived their usefulness, but lack of resources caused them to be used
Component long past their prime.
engineering In their book on “reengineering the corporation,” Hammer and Champy
(Domain view) [HAM931 state:
Information technology plays a crucial role in business reengineering, but one
that is easily miscast. Modern, state-of-the-art information technology is part
. . of any reengineering effort, an essential enabler [that] permits companies to
reengineer business processes. But to paraphrase what is often said about
money and governments, merely throwing computers [and software] at an ex-
isting business problem does not cause it to be reengineered.
Analysis Design
The global objective of information engineering is to apply “information technol-
(Element view) ogy” in a way that best serves the overall needs of the business. To accomplish
this, IE must begin by analyzing business objectives and goals, understanding
the many business areas that must work together achieve these objectives and
goals, and then must define the information needs of each business area and the
business as a whole. Only after this is done does IE make a transition into the
more technical domain of software process where information
systems, applications, and programs are analyzed, designed, and built.
10.4 INFORMATION STRATEGY PLANNING
10.4.
The product engi- The first information engineering step is information strategy
neering hierarchy The overall objectives of ISP are to define strategic business objectives and
goals, (2) to isolate the critical success factors that will enable the business to
achieve these goals and objectives, to analyze the impact of technology and
automation on the goals and objectives, and to analyze existing information
to determine its role in achieving goals and objectives. ISP also creates a
The element for product engineering is the engineering discipline data model that defines key data objects and their relationship to one
applied to For engineering, this means and lo areas.
analysis and design modeling activities (covered in detail in later chapters) and’ The terms “objectives” and “goals” take on a specific meaning in An ob-
construction and integration activities that encompass code generation, testing, jective is a genera1 statement of direction. For example, a business objective for
and support eteps. Analysis modeling allocates requirements into representa- a maker of cellular telephones might be to reduce the manufactured cost of the
tions of data, function, and behavior. Design maps the analysis model into data, product. Goals define a quantitative course of action. To achieve the objective
architectural, interface, and procedural designs for the software. noted above, the manufacturer might state the following goals:
242 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 243
decrease reject rate by 20 percent within 9 months refine the boxes within the org chart until small working groups or even in-
dividuals are noted. However, for ISP purposes, business areas are all that is
!"gain 10 percent price concessions from suppliers
required.
!" reengineer keypad to reduce assembly cost by 30 percent
Business functions are identified and the processes that are required to
!" of the business functions are defined. Each of business functions is
!" implement a real-time production control system to business area that responsibility for it (Figure 10.51. In
general a business function is some ongoing activity that must be accomplished
to support the overall business. It can usually be described as a noun phrase.
Objectives tend to be strategic. Goals are tactical.
A business process is a transform that accepts specific inputs and produces spe-
Critical factors can be tied to an objective or to individual
cific outputs. It can generally be described as a verb phrase.
goals. A CSF must be present if the objective or goal is to be achieved. Therefore
To illustrate how a business function is refined into a set of supporting
management planning must accommodate it. For example, for the man-
processes, consider the market analysis function shown in Figure 10.5. A process
ufacturing objective noted above might be:
refinement follows:
!" total quality management strategy for the manufacturing organization
!" worker training and motivation
!" higher-reliability machines
I Business Functions
!" higher-quality parts
Company Product development and
!" a “sales plan” to convince suppliers to reduce prices
!" availability of engineering staff
Technology impact analysis examines objectives and goals and provides an
indication of those technologies that will have a direct or indirect impact on Market analysis
Engineering Manufacturing
achieving them successfully. The information engineer addresses the following II I Forecasting
questions: How critical is the technology to the achievement of a business ob-
jective? Is the technology available today? How will the technology change the Product
way business is conducted? What are the direct and indirect costs? How should Product
the business adapt or extend objectives and goals to accommodate the technology? Technology research
Because every business area makes some use of information technologies, New product development
ISP must also identify what currently exists and how it is currently used to System analysis
achieve objectives and goals. Business process reengineering is an ac- Component engineering
tivity that examines existing systems with the intent of reengineering them to Hardware engineering
better meet business needs. BPR is discussed in Chapter 27.
----Software engineering
Human engineering
Product V V
10.4.1 Enterprise Modeling Quality assurance
Enterprise modeling creates a three-dimensional view of a business. The
dimension addresses the organizational structure and the functions that are
performed within the business areas defined by the organizational structure.
The second dimension decomposes business function to isolate the processes
that make function happen. Finally, the third dimension relates objectives,
goals, and to the organization and its functions. In addition, enterprise
modeling creates a business-level data model that defines data objects and
their relationships to other elements of the enterprise model.
The business organization (Figure 10.5) is defined in a classical business FIGURE 10.5.
unit hierarchy an “ory chart”). Each box in the ory chart represents a Deriving on organizational chart and coupling areas to function
business area of the company, Like all hierarchies3 is generally possible to
PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING\ CHAPTER SYSTEM ENGINEERING 245
Market
describes
!" Collect data on all sales inquiries Salesperson
Product A
!" Collect data on all sales
sells
!" Analyze data on inquires and sales
Develop buyer profile
!"Compare profile to demographic research
Study industry buying trends
Establish focus groups to determine best sales message
!" Design rough sales materials
!" Test sales materials and refine
FIGURE 10.6.
Depicting relation-
!" Finalize sales approach
ship among
Each of the process steps could be further refined to provide a detailed
road map for accomplishing the business function.
During ISP, the information engineer does not become concerned with
eas of automation opportunity. is simply to understand and model
the business. Once a set of data objects is defined, their relationships are identified. A rela-
tionship indicates how objects are connected to one another. As an example,
consider the objects customer, product A, and salesperson. An information
engineer creates a (Figure 10.6) to depict these relationships.
10.4.2 Business-Level Data Modeling
Referring to the figure, relationships imply a connection between data objects.
In general, relationships can be read in either direction; hence, a customer
data modeling is an enterprise modeling activity that purchases product A and product A is purchased by a customer. In reality
focuses on the data objects (also called entities) that are required to achieve the additional information is provided as part of the data model, but we postpone
business functions noted in Section At the business level, typical data discussion of this until Chapter 12.
objects include producers and consumers of information (e.g., a customer), The culmination of the ISP activity is the creation a series of cross-ref-
things a report.), occurrences of events (e.g., a sales conference), organiza- erence matrices that establish the overall relationships between the organiza-
tional roles (e.g., a Vice President organizational units (e.g., tion (and its business areas), business objectives and goals, business functions,
Sales and Marketing), places (e.g., manufacturing cell), or information struc- and data objects. Examples of such matrices are shown in Figure 10.7.
tures (e.g., an employee file). A data object contains a set of attributes that de-
fine some aspect, quality, characteristic, or descriptor of the data that is being
described. For example, during enterprise modeling an information engineer
might define the data object customer. To more fully describe customer, the BUSINESS AREA ANALYSIS
10.5
following attributes are defined:
Object: Customer In his book on information engineering, Martin describes business
area analysis in the following manner:
name
Business areas analysis establishes a detailed framework for building
company name an information-based enterprise. It takes one business area at a time and an-
classification and authority alyzes it in detail. It uses diagrams and matrices to model and record the data
business address and information and activities in the enterprise and to give a clear understanding of the elabo-
rate and subtle ways in which the information aspects of the enterprise inter-
product interest(s) relate.
past purchase(s)
dote of last contact
status of contact diagram, called is described in detail in Chapter 12
244 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 247
Objectives and Goals Data Objects date of last contact !" record of contacts
status of contact status of last contact
next contact date
recommended nature of contact
The attribute company name has been modified to point to another object called
Company. This object contains not. only the company name but additional in-
formation about the size of the company, its purchasing requirements, the
name of other contacts, and so on. This information will be useful in the sales
domain. Other attributes have been modified and added as noted above.
10.5.1 Process Modeling
FIGURE 10.7.
Typical cross-reference matrices used during The work performed within a business area encompasses of business func-
tions that are further refined into business processes. To illustrate, consider a
simplified version of the sales function discussed in Section processes
During BAA, our focus shifts from the world view to the domain view. To model that occur to accomplish sales are:
“the elaborate and subtle ways in which the information aspects of the enter-
_ interrelate,” the information engineer must depict how data objects (de- function:
scribed during ISP and refined during BAA) are used and transformed within
each business area and how the business functions and processes within each !" Establish customer contact
business area transform these data objects. In essence, both exogenous and en- !"Provide product literature and related information
dogenous data are analyzed and modeled for each business area.
!" Address questions and concerns
To accomplish this work, BAA makes of a number of different
!" Provide evaluation product
!" data models (now refined to the business area level) !" Accept sales order
. process flow models !" Check availability of configuration ordered
!" process decomposition diagrams !"Prepare delivery order
!" a variety of cross-reference matrices !" Confirm configuration, pricing, ship date with customer
!"Transmit delivery order to fulfillment department
The data objects defined during ISP are refined for use within each business !" Follow up with customer
area. For example, the data object customer described in the
tion is used by the sales department. After evaluation of the needs of the sales
A process flow diagram (Figure 10.8) can be developed for this sequence of pro-
department (an analysis of the sales domain), the original definition of
cessing. It should be noted that each business function relevant to the business
is further refined meet the needs of sales:
area can be refined in a similar manner.
O b j e c t : Customer
Attributes:
10.5.2 Information Flow Modeling
company name Object: Company
The process flow model is integrated with the data model to provide an indi-
job classification and purchase authority cation of how information flows through a business area. Input and output data
business address and contact information objects are shown for each process, providing an indication of how the process
information (Figure to function.
product interest(s)
flow infor-
past purchase(s) mation engineer (along with others) examines how the existing process can be
FIGURE 10.8.
Process flow model for the soles function
customer
contact
delivery
order info
order info
order info
FIGURE 10.9.
Adding information flow to the process Row model for the soles function
250 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 251
reengineered (e.g., and where existing information systems 1. How many different identification numbers must be processed and what
OF applications might be modified or replaced by more efficient information is their form?
technologies. The revised process model is used as a basis for the specification 2. What is the speed of the conveyor line in feet per second and what is the
of new or revised software to support the business function. distance between boxes in feet?
The domain view established during BAA serves as the basis for business sys-
3. How far is the sorting station from the bins?
design and construction and integration-IE steps that are actually part of
the software engineering process. The steps will be considered in later chapters. 4. How far apart are the bins?
5. What should happen if a box doesn’t have an identification number or an
incorrect number is present?
10.6 PRODUCT ENGINEERING 6. What happens when a bin fills to capacity?
7. Is information about box destination and bin contents to be passed else-
Product engineering (also called system engineering) is a problem solving ac- where in the factory automation system? Is real-time data acquisition
tivity Desired product data, function, and behavior are uncovered, analyzed, required?
and allocated to individual engineering components. The system engineer be- 8. What error/failure rate is acceptable?
gins with customer-defined objectives and goals for the product and proceeds
to model these requirements in a manner that allocates them to a set of engi- 9. What pieces of the conveyor line system currently exist and are operational?
neering components-software, hardware, data (and databases), and people. What schedule and budgetary constraints are imposed?
The components are tied together with a support technol-
ogy required to integrate the components and the information (e.g., documents, Note that the above questions focus on function, performance, and information
CD-ROM, video) that is used to support the components. flow and content. The system engineer does not ask the customer how the task
The genesis of most new products and systems begins with a rather nebu- is to be done; rather, the engineer asks what is required.
lous concept of desired function. Therefore, the system engineer must bound the Assuming reasonable answers, the system engineer develops a number of
product requirements by identifying the scope of function and performance de- alternative allocations. Note that function and performance are assigned to dif-
sired. For example, it is not enough to say that the control software for the ro- ferent generic system elements in each allocation.
bot in a manufacturing automation system will “respond rapidly if a parts tray
is empty.” The system engineer must define what indicates an empty tray to Allocation 1. A sorting operator is training and placed at the sorting sta-
the robot, the precise time‘bounds (in seconds) within which re- tion location. He/she reads the box and places it into an appropriate bin.
sponse is expected, and (3) what form the response must take. That is, the sys-
Allocation 1 represents a purely manual (but nevertheless, effective) solu-
tem engineer must describe the events that drive the behavior of the robot, the
nature of the behavior, and the quantitative bounds placed on the behavior. tion to the CLSS problem. The primary engineering component is people (the
sorting operator). The person performs all sorting functions. Some documenta-
Once function, performance, constraints, and interfaces are bounded, the sys-
tion (in the form of a table relating identification number to bin location and
tem engineer moves on to a task that is called allocation. During allocation, func-
procedural description for operator training) may be required. Therefore, this
tion is assigned to one or more engineering components. alternative alloca-
tions are proposed and evaluated. To illustrate the process of allocation, we consider allocation uses only the people and documentation elements.
a macro element of the factory automation system-the conveyor line sorting sys-
Allocation 2. A bar code reader and controller are placed at the sorting
tem that was introduced in Chapter 5. The system engineer is presented station. Bar code output is passed to a programmable controller that con-
with the following (somewhat nebulous) statement of objectives for CLSS:
trols a mechanical shunting mechanism. The shunt slides the box to the
appropriate bin.
CLSS developed such that boxes moving along a conveyor line will be
identified and sorted into one of six bins at the end of the line. The boxes will For allocation 2, hardware (bar code reader, programmable control, shunt
pass by a sorting station where they will be identified. Based on an identifica- hardware, etc.), software (for the bar code reader and programmable controller)
tion number printed on the side of the box (an equivalent bar code is provided), and database look-up table that relates box ID with bin location) components
the boxes will be shunted into the appropriate bins. Boxes pass in random or- are used to provide a fully automated solution. It is likely that each of these
der and are evenly spaced. The line is moving slowly. components may have corresponding manuals and other documentation, adding
another component.
CLSS is depicted schematically in Figure 5.1. Before continuing, make a
list of questions that you would ask if you were the system engineer. Allocation 3. A bar code reader and controller are placed at the sorting
Among the many questions that should be asked and answered are the fol- station. Bar code output is passed to a robot arm that grasps a box and
lowing: moves it to the appropriate bin location.
252 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 253
Allocation 3 makes use of one macro element-the robot. Like allocation 2, 10.6.1 System Analysis
this allocation uses hardware, software, a database, and documentation as en-
gineering components. The robot is a macro element of CLSS and itself con- System analysis is conducted with the following objectives in mind: identify
tains a set of engineering components. the customer’s need; evaluate the system concept for feasibility; perform
By examining thr three allocations for it should be ob-
economic and technical analysis; allocate functions to hardware, software,
vious that the same function can be allocated to different components. In order
people, database, and other system elements; (5) establish cost and schedule
to choose the most effective allocation, a set of trade-off criteria should be ap- constraints; and create a system definition that forms the foundation for all
plied to each alternative. subsequent engineering work. Both hardware and software expertise (as well
The following trade-off criteria govern the selection of a product as human and database engineering) are required to successfully attain the ob-
ration based on a specific allocation of function and performance to generic sys- jectives listed above.
tem elements:
Project considerations. Can the configuration be built within pre- ld.6.2 of Need
established cost and schedule bounds? What is the risk associated with cost
and schedule estimates?
The first step of the system analysis process involves the identification of need.
Business considerations.Does the configuration represent the most The analyst (system engineer) meets with the customer and the end user (if dif-
profitable solution? Can it be marketed successfully? Will ultimate payoff ferent from the customer). The customer may be a representative of an outside
justify development risk? company, the marketing department of the analyst’s company (when a product
T e c h n i c a l a n a l y s i s . Does the technology exist to develop all elements of is being defined), or another technical department (when an internal system is
the system? Are function and performance assured? Can the configuration to be developed). Like information engineering, the intent is to understand the
be adequately maintained? Do technical resources exist? What is the risk product’s objective(s) and to define the goals required to meet the objective(s).
associated with the technology? Once overall goals are identified, the analyst moves on to an evaluation of
Manufacturing evaluation. Are manufacturing facilities and equip- supplementary information: Does the technology exist to build the system?
ment available? Is there a shortage of necessary components? Can quality What special development and manufacturing resources will be required? What
assurance be adequately performed? bounds have been placed on costs and schedule? If the new system is actually
product. he for to mnng customers, following
and are also asked: What is the potential market for the product? How does this
Does the customer understand product compare with competitive products? What position does this product
what the system is to accomplish? take in the overall product line of the company?
Environmental interfaces. Does the proposed configuration properly Information gathered during the needs identification step is specified in a
interface with the system’s external environment? Are machine to machine system concept document. The original concept document is sometimes prepared
and human to machine communication handled in an intelligent manner? by the-customer before meetings with the analyst. Invariably, customer-analyst
L e g a l c o n s i d e r a t i o n s . Does this configuration introduce undue liability communication results in modifications to the document.
risk? Can proprietary aspects be adequately protected? Is there potential
infringement?
10.6.3 Feasibility Study
We examine some of issues in detail later in this chapter.
is importanl to that the system engineer should also consider All projects are feasible-given unlimited resources and infinite time!
off-the-shelf solutions to the customer’s problem. Does an equivalent sys- Unfortunately, the development of a computer-based system or product is
tem already exist? Can major parts of a solution be purchased from a third more likely plagued by a scarcity of resources and difficult (if not downright
party? unrealistic) delivery dates. It is both necessary and prudent to evaluate the
The application of trade-off criteria results in the selection of a specific sys- feasibility of a project at the earliest possible time. Months or years of effort,
tem configuration and the specification of function and performance allocated thousands or millions of dollars, and untold professional embarrassment can
to hardware, software firmware), people, databases, documentation, and be averted if an ill-conceived system is recognized early in the definition
procedures. Essentially, the scope of function and performance is allocated to phase.
each engineering component of the product. The role of hardware engineering, Feasibility and risk analysis are related in many ways. If project risk is
software engineering, human engineering, and database engineering is to great (for any of the reasons discussed in Chapter the feasibility of produc-
scope produce an operational product that properly ing is During product however, we con-
integrated with other components. centrate our attention on four primary areas of interest:
254 PART THREE: CONVENTIONAL FOR ENGINEERING CHAPTER SYSTEM ENGINEERING 255
Economic feasibility. An evaluation of development cost weighed against the Legal feasibility encompasses a broad range of concerns that include con-
ultimate income or benefit derived from the developed system or product, tracts, liability, infringement, and myriad other traps frequently unknown to
Technical feasibility. A study of function, performance, and constraints technical staff. A discussion of legal issues and software is beyond the scope of
that may affect the ability to achieve an acceptable system. this book. The interested reader should see
The degree to which alternatives are considered is often limited by cost and
Legal feasibility. A determination of any infringement, violation, or lia-
time constraints; however, a legitimate but “unsponsored” variation should not
bility that could result from development of the system.
be buried.
An evaluation of alternative approaches to the development The feasibility study may be documented as a separate report to upper
of the system or product. management and included as an appendix to the system specification. Although
the format of a feasibility study may vary, the outline provided in Figure 10.10
A feasibility study is not warranted for systems in which economic justification covers most important topics.
is obvious, technical risk is low, few legal problems are expected, and no rea- The feasibility study is reviewed first by project management (to assess
sonable exists. However, if any of conditions fail, a content reliability) and by upper manngement (to assess project status). The
study of that area should be conducted. study should result in a “go/no-go” decision. It should be noted that other
Economic justification is generally the “bottom-line” consideration for most go decisions will be made during the planning, specification, and development
systems (notable exceptions sometimes include national defense systems, steps of both hardware and software engineering.
gram).” Economic
analysis, income impact on
profit centers or products, cost of resources needed for development, and po- Economic Analysis
tential market growth.
Technical feasibility is frequently the most difficult area to assess at this Among the most important information contained in a feasibility study is
stage of the product engineering process. Because objectives, functions, and per- cost-benefit analysis-an assessment of the economic justification for a com-
formance are somewhat hazy, anything seems possible if the “right” assump- puter-based system project. Cost-benefit analysis delineates costs for project
tions are made. It is essential that the process of analysis and definition be con-
ducted in parallel with an assessment of technical feasibility. In this way
concrete specifications may be judged as they are determined.
The considerations that are normally associated with technical feasibility
include:
I. Introduction ---
Development risk. Can the system element be designed so that necessary A. Statement of the problem
function and performance are achieved within the constraints uncovered B. Implementation environment
during analysis? C. Constraints
Resource availability. Are skilled staff available to develop the system el- II. Management Summary and Recommendations
ement in question? Are other necessary resources (hardware and software) A. Important findings
available to build the system? B. Comments
Technology. Has the relevant technology progressed to a state that will C. Recommendations
support the system? D. Impact
III. Alternatives
Developers of computer-based systems are optimists by nature. else would A. Alternative system configurations
be brave enough to attempt what we frequently undertake?) However, during , B. Criteria used in selecting the final approach
an evaluation of technical feasibility, a cynical, if not pessimistic, attitude IV. System Description
should prevail. at this stage can be A. Abbreviated statement of scope
B. Feasibility of allocated elements
V. Cost-Benefit Analysis
FIGURE10.10. VI. Evaluation of Technical Risk
is beginning to change attempts to ‘downsize” government become more widespread. Feasibility study VII. Legal Ramifications
Today, all systems should be economically justified. outline VIII. Other Project-Specific Topics
256 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 257
development and weighs them against tangible (i.e., measurable directly in dol-
lars) and intangible benefits of a system.
Cost-benefit analysis is complicated by criteria that vary with the charac- POSSIBLE INFORMATION SYSTEM BENEFITS*
teristics of the system to be developed, the relative size of the project, and the
expected return on investment desired as part of a company’s strategic plan.
In addition many benefits derived from computer-based systems are intangible Benefits from contributions of calculating and printing tasks
(e.g., better design quality through iterative optimization, increased customer Reduction in per unit costs of calculating and printing (CR)
satisfaction through programmable control, and better business decisions Improved accuracy in calculating tasks (ER)
through reformatted and preanalyzed sales data). Direct quantitative compar- Ability to quickly change variables and values in calculation programs (IF)
isons may be difficult to achieve. Greatly increased speed in calculating and printing (IS)
As we noted above, analysis of benefits will differ depending on system
characteristics. To illustrate, consider the benefits for management information
Benefits from contributions to record-keeping tasks
systems shown in Table 10.1. Most data-processing systems are de-
Ability to “automatically” collect and store data from records (CR, IS, ER)
veloped with “better information quantity, quality, timeliness, or organization”
More complete and systematic keeping of records (CR, ER)
as a primary objective. Therefore, the benefits noted in Table 10.1 concentrate
Increased capacity for record keeping in terms of space and cost (CR)
on information access and its impact on the user environment. The benefits
that might be associated with an engineering-scientific analysis program or a for record keeping (CR, IS)
Increase in amount of data that can be stored per record (CR, IS)
computer-based product could differ substantially.
Costs associated with the development of a computer-based system Improved security in records storage (ER, CR, MC)
Improved portability of records (IF, CR, IS)
are listed in Table 10.2. The analyst can estimate each cost and then use de-
velopment and ongoing costs to determine a return on investment, a
even point, and a payback period. tasks
from contributions to record-searching
The following excerpt may best characterize cost-benefit analysis: Faster retrieval of records (IS)
Improved ability to access records from large data bases
Like political rhetoric after the election, the cost-benefit analysis may be for- Improved ability to change records in data bases (IF, CR)
gotten after the project implementation begins. However, it is extremely im- Ability to link sites that need search capability through telecommunications (IF, IS)
portant because it has been the vehicle by which management approval has improved ability to create records of records accessed and by whom (ER, MC)
Ability to audit and analyze record-searching activity (MC, ER)
been obtained.
Only by spending the time to evaluate feasibility do we reduce the chances for Benefits from contributions restructuring capability
extreme embarrassment worse) at later stages of a system project. Effort Ability to simultaneously change entire classes of records (IS, IF, CR)
spent on a feasibility analysis that results in cancellation of a proposed project Ability to move large files of about (IS, IF)
is not wasted effort. Ability to’ create new files by merging aspects of other files (IS, IF)
Benefits from contributions of analysis and simulation capability
Ability to perform complex, simultaneous calculations quickly (IS, IF, ER)
10.6.5 Technical Analysis Ability to create simulations of complex phenomena to answer “what if?” ques-
tions (MC, IF)
Ability to aggregate large amounts of data useful for planning and decision mak-
During technical analysis,-the analyst evaluates the technical merits of the sys- ing [MC, IF)
tem concept, at the same time collecting additional information about perfor-
mance, reliability, maintainability, and producibility. In some cases, this system
Benefits from to process and resourcecontrol
analysis step also includes a limited amount of research and design,
Technical analysis begins with an assessment of the technical viability of Reduction of need for work force in process andresource control (CR)
the proposed system. What technologies are required to accomplish system Improved ability to “fine tune” process such as assembly lines [CR, MC, IS, ER)
function and performance? What new material, methods, algorithms, or Improved ability to maintain continuous monitoring of resources (MC, ER, IF)
processes are required, and their development risk? How will these
technology issues affect cost? *Abbreviations: CR = cost reduction or avoidance; ER reduction; IF increased flex-
ability; IS increased speed of activity; MC = improvement in management planning
The tools available for technical analysis are derived from mathematical control.
modeling and optimization techniques, probability and statistics, queuing the- Source: King and p. 23. with
258 PART THREE- CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 259
1. The model should represent the dynamics of the system configuration be-
ing evaluated in a way that is simple enough to understand and manipu-
POSSIBLE SYSTEM COSTS late, and yet close enough to the operating reality to yield results.
2. The model should highlight those factors that are most relevant to the
problem at hand and suppress discretion) those that are not as im-
Procurement costs portant.
Consulting costs
3 . The model should be made comprehensive by including relevant factors
Actual equipment purchase or costs and should be reliable in terms of repeatability of results.
Equipment costs
4. design should be simple enough to allow for timely implementation
Costs for modifying the equipment site conditioning, security, etc.
Cost of capitol in problem solving. Unless the model can be utilized in a timely and
manner by the analyst or the manager, it is of little value. If the model
Cost of management ond staff dealing with procurement
is large and highly complex, it may appropriate to develop a series of
smaller models in which the output of one can be tied to the input of an-
costs
other, Also, it may be desirable to evaluate a specific element of the system
Cost of operating system
independently from other elements.
Cost of equipment installation (telephone lines, data lines, etc.)
of personnel Model design should incorporate provisions for ease of modification and/or
Cost of personnel and hiring activities expansion to permit the evaluation of additional factors as required.
Cost of disruption to the rest of the organization Successful model development often includes a series of trials before the
Cost of required to direct start-up activity overall objective is met. Initial attempts may suggest information gaps
which are not immediately apparent and consequently may suggest bene-
ficial changes.
Project costs
Cost of opplicotions software purchased
Cost of software modifications to fit systems The results obtained from technical analysis form the basis for another “go/no-
Cost of personnel, overheod, etc., from in-house opplicotion development go” decision on the system. If technical risk is severe, if models indicate that
Cost for training user personnel in opplicotion use desired function or performance cannot be achieved, if the pieces just won’t lit
Cost of collection and installing collection procedures together smoothly-it’s back to the drawing board!
Cost of preparing
Cost of development management
10.7 MODELING THE SYSTEM ARCHITECTURE
Ongoing
System maintenance costs (hardwore, and facilities) Every computer-based system can be modeling as an information transform us-
Rental costs [electricity, telephones, etc.] ing an input-processing-output architecture. Hatley and Pirbhai have
Depreciation costs on hordwore extended this view to include two additional system features-user interface
Cost of staff involved in informotion systems monogement, operotion, and plan- processing and maintenance and self-test processing. Although these additional
ning activities features are not present for every computer-based system, they are very com-
mon, and their specification makes any system model more robust. Using a rep-
Source: King and [KIN 781, 24. Reprinted with permission. resentation of input, processing, output, user interface processing, and self-test
processing, a system engineer can create a model of system components that
ory, and control theory-to name a It is important to note, however, that sets a foundation for later requirements analysis and design steps in each of
analytical evaluation is not always possible. Modeling (either mathematical or the engineering disciplines.
physical) is an effective mechanism for technical analysis of computer-based To develop the system model, an architecture template [HATS71 is used.
systems. The system engineer allocates system elements to each of live processing re-
Blanchard and Fabrycky define a set of criteria for the use of mod- gions within the template: user interface, input, system function and
els during technical analysis of systems: control, output, and maintenance and self-test. The format of the archi-
tecture template is shown in Figure 10.11.
Like nearly all modeling techniques used in system and software engineer-
class of CASE tools, and simulation can assist greatly in ing, the architecture template enables the analyst to create a hierarchy of detail.
analysis. These tools discussed in Chapter 29. An architecture context diagram resides at the top level of the hierarchy.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 261
user interface processing
input process and control output
processing functions processing
sorting
maintenance and self-test FIGURE10.12. station
FIGURE 10.11. Architecture context operator
Architecture diagram for CLSS
[extended)
input information that is labeled bar code. In essence, the ACD places any sys-
The context diagram “establishes the information boundary between the
tem into the context of its external environment.
being in which the is to op-
The system engineer refines the architecture context diagram by consid-
erate” That is, the ACD defines all external producers of information ering the shaded rectangle in Figure 10.12 in more detail. The major subsys-
used by the system, all external consumers of information created by the sys-
tems that enable the conveyor line sorting system to function within the con-
tem, and all entities that communicate through the interface or perform main-
text defined by the ACD are identified. In Figure 10.13, the major
tenance and self-test.
are defined in an architecture flow diagram that is derived from the
To illustrate the use of the ACD, consider an version of the con-
ACD. Information flow across the regions of the ACD is used to guide the sys-
veyor line sorting system discussed in this The ex-
tem engineer in developing the AFD-a more detailed “schematic” for
tended version makes use of personal computer at the sorting station site. The
The architecture flow diagram shows major subsystems and important lines
PC executes all CLSS software; interfaces with the bar code reader to read part
of information (data and control) flow. In addition, the architecture template
numbers on each box; interfaces with the conveyor line monitoring equipment
partitions the subsystem processing into each of the five processing regions
to acquire conveyor line speed; stores all part numbers sorted; interacts with a discussed earlier. At this stage, each of the subsystems can contain one or more
sorting station operator to produce a variety of reports and diagnostics; sends
system elements (e.g., hardware, software, people) as allocated by the system
control signals to the shunting hardware to sort the boxes; and communicates
engineer.
with a central factory automation mainframe. The ACD for CLSS (extended) is
initial architecture flow diagram becomes the top node of a hi-
shown in Figure 10.12.
erarchy of Each rounded rectangle in the can be expanded
Each box shown in Figure 10.12 represents an external entity-that is, a
into another architecture dedicated solely to it. This process illus-
producer or consumer of information from the system. For example, the bar
trated schematically in Figure 10.14. Each of the for the system can be
code reader produces information that is input to the CLSS system. The sym- used as a starting point for subsequent engineering steps for the subsystem
bol for the entire system (or at lower levels, major subsystems) is a rectangle that has been described.
with rounded corners. Hence, CLSS is represented in the processing and con-
trol region at the center of the ACD. The labeled arrows shown in the ACD rep-
resent information (data and control) as it moves from environ-
ment into the bar reader and call modules.
262 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER IO. SYSTEM ENGINEERING 263
operator Top-Level Architecture Flow Diagram
operator requests CLSS queries, reports, displays
interface operator
interface
subsystem
bar code acquisition request
shunt control status
sorting reports
I
CLSS processing report timing location data
control
for C I
FIGURE 10.14.
Building on hi-
erarchy
crash, and start over again.” In fact, for at least one class of system-the
FIGURE 10.13. Architecture flow diogrom for CLSS (extended] continue to do this todny.
Many interact with the world in a reactive
fashion. That is, real world events are monitored by the hardware and software
Subsystems and the information that flows between them can be specified that comprise the computer-based system, and based on these events, the sys-
(bounded) for subsequent engineering work. A narrative description of each tem imposes control on the machines, processes, and even people who cause the
subsystem and a definition of all data that flow between subsystems become events to occur. Real-time and embedded systems often fall-into the reactive
important elements of the system specification. systems category.
Unfortunately, the developers of reactive systems sometimes struggle to
make them perform properly. Until recently, it has been difficult to predict the
performance, efficiency, and behavior of such systems prior to building them.
10.8 SYSTEM MODELING AND In a very real sense, the construction of many real-time systems was an ad-
venture in “flying.” Surprises (most of them unpleasant) were not discovered
Almost three decades ago, R.M. Graham made a distressing comment until the system was built and “pushed off a cliff.” If the system crashed due to
about the way we built computer-based systems: “We build systems like the incorrect function, inappropriate behavior, or poor performance, we picked up
Wright brothers built airplanes-build the whole thing, push it off a cliff, let it the pieces and started over again.
264 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 265
Many systems in the reactive category control machines and/or processes I. Introduction
(e.g., commercial airliners or petroleum refineries) that must operate with an A. Scope and Purpose of Document
extremely high degree of reliability If the system fails, significant economic or B. Overview
human loss could occur. For this reason, the approach described by Graham is 1. Objectives
both painful and dangerous. 2. Constraints
Today, CASE tools for system modeling and simulation are being used to
Functional and Data Description
help to eliminate surprises when reactive, computer-based systems are built. ,
A. System Architecture
These tools are applied during the system engineering process, while the roles
of hardware and software, are Modeling 1. Architecture Context Diagram
and simulation tool8 enable a system to “test drive” a specification of 2. ACD Description
the system. The technical details and specialized modeling techniques that are III. Subsystem Descriptions
used to enable a test drive are discussed briefly in Chapter 29. A. Architecture Diagram Specification for Subsystem
1. Architecture Flow Diagram
2. System Module Narrative
SYSTEM SPECIFICATION 3. Performance Issues
4. Design Constraints
The system specification is a document that serves as the foundation for hard- 5. Allocation of System Components
ware engineering, software engineering, data base engineering and human en- B. Architecture Dictionary
gineering. It describes the function and performance of a computer-based sys- C. Architecture Interconnect Diagrams and Description
tem and the constraints that will govern its development. The specification IV. System Modeling and Simulation Results
bounds each allocated system element. For example, it provides the software A. System Model Used for Simulation
engineer with an indication of the role of software within the context of the sys- B. Simulation Results
tem as a whole and the various subsystems described in the architecture flow C. Special Performance Issues
diagrams. The system specification also describes the information (data and
V. Project Issues
control) that is input to and output from the system.
A. Projected Development Costs
A recommended outline for the system specification is presented in Figure FIGURE 10.15.
10.15. It should be noted, however, that this is but one of many outlines that System specification B. Projected Schedule
can be used to define a system description document. The actual format and outline VI. Appendices
content may be dictated by software or system engineering standards or local
custom and preference. business area. Information engineering encompasses information strategy plan-
ning business area analysis (BAA), and application-specific analysis that
is actually part of software engineering.
10.10 SUMMARY Product engineering is a system engineering approach that begins with
system analysis. The system engineer identifies the customer’s needs, deter-
A high-technology system encompasses a number of components: software, mines economic and technical feasibility, and allocates function and perfor-
hardware, people, database, documentation, and procedures. System engineer- mance to software, hardware, people databases-the key engineering com-
ing helps to translate a customer’s needs into a model of a system that makes ponents. An architectural model of the system or product is produced and
use of one or more of these components. representations of each major subsystem can be developed. Finally, the system
System engineering begins by taking a “world view.” A business domain or engineer can create a reactive system model that can be used as the basis for
product is analyzed to establish all basic requirements. Focus is then narrowed a simulation of performance and behavior. The system engineering task culmi-
to a “domain view,” where each of the system elements is analyzed individually. nates with the creation of a system specification-a document that forms the
Each element is allocated to one or more engineering components which are foundation for all engineering work that follows.
then addressed by the relevant engineering discipline. System engineering demands intense communication between the
Information engineering is a system engineering approach that is used to tomer and the information or system engineer. The customer must understand
define architectures that enable a business to use information effectively. The system objectives and be able to state them clearly. The engineer must know
intent of information engineering is to comprehensive data architec- what questions to ask, what advice to give, and what research to do. If com-
tures, an application architecture, and a technology infrastructure that will munication succeeds and a complete model of the system is created, a solid
meet the needs of the business strategy and the objectives and goals of each foundation is established for the construction of the system.
266 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SYSTEM ENGINEERING 267
REFERENCES 1 0 . 5 . Information engineering strives to define data and application architecture
as as technology infrastructure. Describe what each of these terms
means and provide an example.
Blanchard, B.S., and W.J. Systems Engineering and Analysis,
Prentice-Hall, 1981, p. 270. 10.6. Information strategy planning begins with the definitions of objectives and
goals. Provide examples of each from the business domain.
Fried, L. “Performing Cost Benefit Analysis,” System Development
Management, Auerbach Publishers, Pennsauken, NJ, 1977. 10.7. Y o u ’ v e d e c i d e d t o s t a r t a m a i l - o r d e r b u s i n e s s f o r c o m p u t e r s o f t w a r e . B e c a u s e
you want to run the business you decide to do some information
Graham, R.M., in Proceedings 1969 NATO Conference on Software
engineering. You’ll start with ISP. Build a simple enterprise model that in-
Engineering, 1969.
cludes an org chart, business function and business process outlines, and a
Hammer, M., and J. Champy, Reengineer&g the Corporation, Harper business-level data model.
Collins, 1993, p. 83.
10.8. Let’s assume that one of the business areas that you’ve identified for the
H a r e s , J . S . , I n f o r m a t i o n E n g i n e e r i n g f o r t h e A d v a n c e d P r a c t i t i o n e r , Wiley, software mail-order business (problem 10.7) is telephone order processing.
1993, pp. 12-13. Do BAA to develop a more detailed data model and process flow diagram for
Hatley, D.J., and Pirbhai, Strategies for Real-Time System this business area.
cation. House, 1987. 10.8. A from of system developer,
or Discuss the and cons that
apply to each source. Describe an “ideal” system engineer.
KIN781 King, J., and E. Schrems, “Cost Benefit Analysis in Information Systems 10.10. Add at least five additional questions to the list developed for CLSS in
ACM vol. 10, no. 1, with
March 1978, pp. 19-34. 10.11. Your instructor will distribute a high-level description of a computer-based
Martin, J., Information Engineering: Book II-Planning and Analysis, system or product.
Prentice-Hall, 1990. a. Develop a set of questions that you should ask as a system engineer.
b. Propose at least two different allocations for the system based on answers
Rishe, Database Design, McGraw-Hill, 1992.
to your questions provided by your instructor.
[MOT921 Motamarri, “Systems Modeling and Description,” Software c. In class, compare your allocation to those of fellow students.
Notes, vol. 17, no. April 1992, pp. 57-63.
10.12. Develop a checklist for attributes to be considered when a sys-
A., and A. “Extending Data Modeling to Cover the Whole tem or product is to be evaluated. Discuss the interplay among attributes
Enterprise,” Communication of the ACM, vol. 35, no. 4, September 1992, and attempt to provide a method for grading each so that a
pp. 166-172. “feasibility number” may be developed.
ISCO891 Scott, M.D., Computer Law, Wiley, 1989. 10.13. Research the accounting techniques tbat are used for a detailed cost-benefit
S., Enterprise Architecture Planning, QED Publishing, 1993. analysis of a computer-based system that will require some hardware man-
ufacturing and assembly. Attempt to write a “cookbook” set of guidelines that,
a technical manager could apply.
PROBLEMS AND POINTS TO PONDER 10.14. Develop an architecture context and architecture flow dia-
grams for the computer-based system of your choice (or one assigned
10.1. Find as many single word synonyms for the word “system” as you can. Good by your instructor).
luck! 10.16. Write a system module narrative that would be contained in an architecture
10.2. Build a “system of systems” similar to Figure 10.1 for a large system (other diagram specification for one or more of the subsystems defined in the
than the one shown). Your hierarchy should extend down to simple system developed for problem 10.14.
elements (hardware, software, along at least one branch of the “tree.” 10.16. Research the on CASE tools and write a brief paper describing
10.3. S e l e c t a n y l a r g e s y s t e m o r p r o d u c t w i t h w h i c h y o u a r e f a m i l i a r . D e f i n e t h e how modeling and simulation tools work. Collect literature from
set of domains that describe the world view of the system or product. Describe two or more CASE vendors that sell and simulation tools and as-
the set of elements that make up one or two domains. For one element; iden- sess the similarities and differences.]
tify the technical components that must be engineered. 10.17. Based on documents provided by your instructor, develop an abbreviated
10.4. Select system or product with which you are familiar. State the system specification for one of the following computer-based systems:
simplifications, limitations, constraints, and preferences that a. a nonlinear, digital video-editing system
would have to be made to build an effective (and realizable) system model. b. a digital scanner for a personal computer
268 PART THREE: CONVENTIONAL METHODS FOR ENGINEERING CHAPTER SYSTEM ENGINEERING 269
an electronic system approach to system analysis and design. More recent books by Weinberg
d. a university registration system (General Principles of Systems Design, Dorset House, 1988, and Rethinking
e. an Internet access provider Systems Analysis and Design, Dorset House, continue in the tradition of
f. an interactive hotel system his earlier work.
g. a system of local interest A comprehensive list of pointers to other servers that have information on
Be sure to create the architecture models described in Section 10.8. “system science” can be obtained at:
10.18. Are there characteristics of a system that cannot be established during
tom engineering activities? Describe the characteristics, if any, and explain
why a consideration of them must be delayed until later engineering steps.
T&following Web sites discuss research and practical applications of system
10.19. Are there situations in which formal system specification can be abbreviated and information engineering:
or eliminated entirely? Explain.
Systems Theory and Information Engineering
FURTHER READINGS AND OTHER INFORMATION SOURCES
Martin (Information Engineering, 3 volumes, Prentice-Hall, 1989, 1990, 1991)
presents a comprehensive discussion of information engineering topics. Books Information Engineering Initiative
by Hares Spewak and Flynn and Fragoso-Diaz (Information
International Perspective, Prentice-Hall, 1996) also treat the sub-
ject in detail.
Because it is an interdisciplinary topic, product engineering is a difficult Systems Engineering Welcome Page
subject. Books by Armstrong and Sage (Introduction to Systems Engineering,
Wiley, Martin (Systems Engineering Guidebook, CRC Press, 19961,
Wymore (Model-Based Systems Engineering, CRC Press, Lacy (System
Engineering Management, McGraw-Hill, Aslaksen and (Systems An up-to-date list of World Wide Web references for information engineering
Engineering, Prentice-Hall, (Systematic Systems Approach,
and product engineering can be found at:
Prentice-Hall, and Blanchard and Fabrycky present the system
engineering process (with a distinct engineering emphasis) and provide worth-
while guidance.
An excellent IEEE tutorial by Thayer and Dorfman (System and Software
Requirements Engineering, IEEE Computer Society Press, 1990) discusses the
interrelationship between system and software level requirements analysis is-
sues. A companion volume by the same authors (Standards, Guidelines and
Examples: System and Software Engineering, IEEE Computer
Society Press, presents a comprehensive discussion of standards and
guidelines for analysis work.
Books by Robertson and Robertson (Complete Systems Analysis, Dorset
House, 19941, Silver and Silver (Systems Analysis and Design, Addison-Wesley,
19891, Model1 Professional’s Guide to Systems Analysis, McGraw-Hill,
and and Palmer (Essential Systems Analysis, Press, 1984)
provide useful discussions of the system analysis task as it is applied in the in-
formation systems world. Each contains case study supplements that illustrate
the problems, approaches, and solutions that may be applied during system
analysis.
For those readers actively involved in systems work or interested in a more
sophisticated treatment of the topic, Gerald Weinberg’s books (An Introduction
to General System Thinking, Wiley-lnterscience, 1976, and On the Design of
Stable Systems, Wiley-Interscience, 1979) have become classics and provide an
excellent discussion of “general systems thinking” that implicitly leads to a
CHAPTER I ANALYSIS CONCEPTS AND PRINCIPLES 271
ANALYSIS CONCEPTS
AND PRINCIPLES
FIGURE11.1.
Analysis and
bridge between sys-
tem engineering
complete understanding of software requirements is essential to the suc- software design
cess of a software development effort. No matter how designed or
well coded, a poorly analyzed and specified program will disappoint the user
and bring to the developer. the system engineer to software func-
The analysis is a of discovery, mod- tion and performance, indicate interface with other system elements,
eling, and specification. The software scope, initially established by the system and establish that software must meet. Requirements analysis al-
engineer and refined during software project planning, is refined in detail. lows the software engineer (often called analyst in this role) to refine the soft-
Models of the required data, information and control flow, and operational be- ware allocation and build models of the data, functional, and behavioral do-
havior are created. Alternative solutions are analyzed and allocated to various mains that will be treated by software. Requirements analysis provides the
software elements. software designer with models that can be translated in to data, architectural,
Both the developer and customer take an active role in requirements analy- interface, and procedural design. Finally, the requirements specification pro-
sis and specification. The customer attempts to reformulate a sometimes neb- vides the developer and the customer with the means to assess quality once
ulous concept of software function and performance into concrete detail. The software is built.
developer acts as interrogator, consultant, and problem solver. Software requirements analysis may be divided into five areas of effort: (1)
Requirements analysis and specification may appear to be a relatively sim- problem recognition; (2) evaluation and synthesis; modeling; (4) specifica-
ple task, but appearances are deceiving. Communication content is very high. tion; and review.
Chances for misinterpretation or misinformation abound. Ambiguity is proba- Initially, the analyst studies the system specification (if one exists) and the
ble. The dilemma that confronts a software engineer may best be understood software project plan. It is important to understand software in a system con-
by repeating the statement of an anonymous (infamous?) customer: “I know you text and to review the software scope that was used to generate planning esti-
believe you understood what you think I said, but I am not sure you realize mates. Next, communication for analysis must be established so that problem
that what you heard is not what I meant.” recognition is ensured. The goal of the analyst is recognition of the basic prob-
lem elements as perceived by the user/customer.
Problem evaluation and solution synthesis is the next major area of effort
11.1 REQUIREMENTS ANALYSIS for analysis. The analyst must define all externally observable data objects,
evaluate the flow and content of information; define and elaborate all software
a task that bridges the gap be- functions; behavior in the of that tho
allocation and software (Figure 11.1). system; system interface characteristics; additional de-
\ ’
272 CHAPTER 11: ANALYSIS CONCEPTS AND PRINCIPLES 273
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
sign constraints. Each of these tasks serves to describe the problem so that an puter-based solution. A developer responds to the customer’s request for help.
overall approach or solution may be synthesized. Communication has begun. But as we have already noted, the road from com-
For example, an inventory control system is required for a major supplier munication to understanding is full of potholes.
of auto parts. The analyst finds that problems with the current manual system
include inability to obtain the status of a component rapidly; two or three
day turnaround to update a card tile; multiple reorders to the same vendor
because there is no way to associate vendors with components, and so on. Once 11.2.1 Initiating the Process
problems have been identified, the analyst determines what information is to
be produced by the new system and what data will be provided to the system.’ The most commonly used analysis technique to bridge the communication gap
For instance, the customer desires a daily report that indicates what parts have between the customer and developer and to get the communication process
been taken from inventory and how many similar parts remain. The customer started is to conduct a preliminary meeting or interview. The first meeting be-
indicates that inventory clerks will log the identification number of each part tween a software engineer (the analyst) and the customer can be likened to the
as it leaves the inventory area. awkwardness of a date between two adolescents. Neither person knows
Upon evaluating current problems and desired information (input and out- what to say or ask, both are worried that what they do say will be misinter-
put), the analyst begins to synthesize one or more solutions. To begin, the data, preted; both are thinking about where it might lead (both are likely to have
processing functions, and behavior of the system are defined in detail. Once this radically different expectations here); both want to get the thing over with; but
information has been established, basic architectures for implementation are at the same time, both want it to be a success.
considered. A client/server approach would seem to be appropriate, but does it Yet, communication must be initiated. Gause and Weinberg sug-
fall within the scope outlined in the software plan? A database management gest that the analyst start by asking context free questions. That is, a set of ques-
system would seem to be required, but is the user/customer’s need for tions that will lead to a basic understanding of the problem, the people who
tivity justified? The process of evaluation and synthesis continues until both want a solution, the nature of the solution that is desired, and the effectiveness
analyst and customer feel confident that software can be adequately specified of the first encounter itself. The set of context free questions focus on the
for subsequent development steps. customer, overall goals, and benefits. For example, the analyst might ask:
Throughout evaluation and solution synthesis, the analyst’s primary focus
is on “what,” not “how.” What data does the system produce and consume, what !"Who is behind the request for this work?
functions must the system perform, interfaces are defined, and what con-
straints !"Who will use the solution?
During the evaluation and solution synthesis activity, the analyst creates !" What will be the economic benefit of a successful solution?
models of the system in an effort to better understand data and control flow, !" Is there another source for the solution that you need?
functional processing and behavioral operation, and information content. The
model serves as a foundation for software design and as the basis for the cre- The next set of questions enables the analyst to gain a better understand-
ation of a for the software. ing of the problem and the customer to voice his or her perceptions about a
It is important to note that detailed specification may not be possible at solution:
this stage. The customer may be unsure of precisely what is required. The
developer may be unsure that a specific approach will properly accomplish
!" How would you characterize “good” output that would be generated by a
function and performance. For these and many en alternative
to conducted
(Chapter We discuss prototyping later in this chapter !"What will this solution address?
!" Can you show me (or describe) the environment in which the solution will be
used?
11.2 COMMUNICATION TECHNIQUES !" Are special performance issues or that will affect the way
solution is approached?
Software requirements analysis always begins with communication between
two or more parties. A customer has a problem that may be amenable to a com- The set of questions focus on the effectiveness of the meeting. Gause
and Weinberg call these and propose the following
(abbreviated) list:
‘In reality, much of this information would be acquired as part of an information engineering
activity (Chapter 10) if one were conducted. !" Are you the right person to answer these questions? Are your answers
argues that the terms and “how” are vague. For interesting
of this the reader should refer to his book.
274 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER I ANALYSIS CONCEPTS AND PRINCIPLES 275
!"Are my questions relevant to the problem that you have? !"A “facilitator” (who can be a customer, a developer, or an outsider) controls
!"Am asking too many questions? the meeting.
!" A “definition mechanism” (which can be work sheets, flip charts, wall stick-
!"Is there anyone else who can provide additional information?
ers, or a board) is used.
!"Is there anything else that I should be asking you?
!" The goal is to identify the problem, propose elements of the solution, negoti-
These questions (and others) will help to “break the ice” and initiate the com- ate different approaches, and specify a preliminary set of solution require-
munication that is essential to successful analysis. But a question and answer ments in an atmosphere that is conducive to the accomplishment of the goal.
meeting format is not an approach that has been overwhelmingly successful.
In fact, the Q&A session should be used for the first encounter only and then To better understand the flow of events as they occur in a typical FAST meet-
be replaced by a meeting format that combines elements of problem solving, ing, we present a brief scenario that outlines the sequence of events that lead
negotiation, and specification. An approach to meetings of this type is pre- up to the meeting, occur during the meeting, and follow the meeting.
sented in the next section, Initial meetings between the developer and customer (Section occur
and basic questions and answers help to establish the scope of the problem and
perception of a solution. Out of these initial meetings, the developer
and write a one- or two-page “product meeting place, time,
11.2.2 Facilitated Application Specification Techniques and date for FAST are selected, and a is chosen. Representatives
from both the development and customer organizations are invited to attend.
Customers and software engineers often have an unconscious “us and them” The product request is distributed to all attendees before the meeting date.
mind set. Rather than working as a team to identify and refine requirements, While reviewing the request in the days before the meeting, each FAST at-
each constituency defines its own “territory” and communicates through a se- tendee is asked to make a list of objects that are part of the environment that
ries of memos, formal position papers, documents, and question and answer surrounds the system, other objects that are to be produced by the system, and
sessions. History has shown that this approach doesn’t work very well. objects that are used by the system to perform its functions. In addition, each
Misunderstandings abound, important information is omitted, and a successful attendee is asked to make another list of (processes or functions) that
working relationship is never established. manipulate or interact with the objects. Finally, lists of constraints (e.g., cost,
It is with these problems in mind that a number of independent investi- size, weight1 and performance criteria (e.g., speed, accuracy) are also developed.
gators have developed a team-oriented approach to requirements gathering The attendees are informed that the lists are not expected to be exhaustive, but
that is applied during early stages of analysis and specification. Called arc expected to of the system.
this approach encourages the
application specification techniques (FAST), As an assume that a FAST team working for a consumer prod-
creation of a joint team of customers and developers who work together to iden- ucts company has been provided with the following product description:
tify the problem, propose elements of the solution, negotiate different ap-
proaches, and specify a preliminary set of solution requirements Our research indicates that the market for home security systems is growing at
Today, FAST is used predominantly by the information systems community, but a rate of 40 percent per year. We would like to enter this market by building a
the technique potential for improved communication in applications of microprocessor-based home security system that would protect against
all kinds. a variety of undesirable “situations” such as illegal entry, fire, flood-
Many different approaches to FAST have been proposed.” Each makes use ing and product, tentatively called will appropriate
of a slightly different scenario, but all apply some variation on the following each situation, can he programmed by the homeowner, and will
basic guidelines: automatically telephone a monitoring agency when a situation is detected,
!" A meeting is conducted at a neutral site and attended by both developers and In reality, considerably information would be provided at this stage.
customers. But even with additional information, ambiguity would be present, omissions
!" Rules for preparation and participation are established.
would likely exist, and errors might occur. For now, the above “product de-
scription” will suffice.
!" An agenda is suggested that is formal enough to cover all important points
The FAST team is comprised of representatives from marketing, software and
but informal enough to encourage the free flow of ideas. hardware engineering, and manufacturing. An outside facilitator is to be used.
of the more popular approaches to FAST Joint Application Development de- ‘This example (with extensions and variations) will be used to illustrate important software
veloped by IBM, and The METHOD, developed by Performance Resources, Inc., Falls Church, engineering methods in many of the chapters that follow. an exercise, it would be worth-
VA. while to conduct your FAST meeting and develop a set of lists for it.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 1: ANALYSIS CONCEPTS AND PRINCIPLES 277
Each person on the FAST team (Figure 11.2) develops the lists described !" mounted on wall
above. Objects described for might include smoke detectors, window !" size approximately 9x5 inches
and door sensors, motion detectors, an alarm, an event sensor has been ac-
!" contains standard 12 key pad and special keys
tivated), a control panel, a display, telephone numbers, a telephone call, and so
on. The list of services might include setting the alarm, monitoring the sensors, !"contains LCD display of the form shown in sketch [not presented here]
dialing the phone, programming the control panel, and reading the display !"all customer interaction occurs through keys used to enable and disable the
(note that services act on objects). In a similar fashion, each FAST attendee will system
develop lists of constraints (e.g., the system must have a manufactured cost of !" software to provide interaction guidance, echoes, etc. connected to all sensors
less than $200, must be user friendly, and must interface directly to a standard
phone line) and performance criteria (e.g., a sensor event should be recognized Each then presents each of its mini-specs to all FAST attendees for dis-
within one second; an event priority scheme should be implemented).
cussion. Additions, deletions, and further elaboration are made. In some cases,
As the meeting begins, the first topic of discussion is the need and the development of mini-specs will uncover new objects, services, constraints, or
cation for the new product-everyone should agree that the product develop- performance requirements that will be added to the original lists, During all dis-
ment (or acquisition) is justified. Once agreement has been established, each
cussions, the team may raise an issue that cannot be resolved during the meet-
participant presents his or her lists for discussion. The lists can be pinned to
ing. An issues list is maintained so that these ideas will be acted on later.
the walls of the room using large sheets of paper, stuck to the walls using ad-
Alter the mini-specs are completed, each FAST attendee makes a list of val-
hesive-backed sheets, or written on a wall board. Ideally, each list entry should
idation criteria for the product/system and presents his or her list to the team.
be capable of being manipulated separately so that lists can be combined,
A consensus list of validation criteria is then created. Finally, one or more par-
entries can be deleted, and additions can be made. At this stage, critique and
ticipants (or outsiders) is assigned the task of writing the complete draft spec-
debate are strictly prohibited.
ification using all inputs from the FAST meeting.
After individual lists are presented in one topic area, a combined list is
FAST is not a panacea for the problems encountered in early requirements
created by the group. The combined list eliminates redundant entries and
gathering, but the team approach provides the benefits of many points of view,
adds any new ideas that come up during the presentation, but does not delete instantaneous discussion and refinement, and a concrete step toward the de-
anything. After combined lists for all topic areas have been created, discus- velopment of a specification.
sion-coordinated by the facilitator-ensues. The combined list is shortened,
lengthened, or reworded to properly reflect the product/system to be devel-
oped. The objective is to develop a consensus list in each topic area (objects,
services, constraints, and performance). The lists are then set aside for later 11.23 Quality Function Deployment
action.
Once the consensus lists have been completed, the team is divided into function deployment is quality management technique that
for
smaller subteams; each works to develop a mini-specification one or more translates the needs of the customer into technical requirements for software.
entries on each of the lists. The mini-specification is an elaboration of the word Originally developed in Japan and first used at the Kobe Shipyard of Mitsubishi
or phrase contained on a list. For example, the mini-specification for the Heavy Industries, Ltd. in the early QFD “concentrates on maximizing
object control panel might be: customer satisfaction” To accomplish this, QFD emphasizes under-
standing of what is valuable to the customer and then deploying these values
throughout the engineering process.
QFD identifies three types of requirements
N o r m a l r e q u i r e m e n t s . Objectives and goals are stated for a product or
system during meetings with the customer. If these requirements are pre-
sent, the customer is satisfied. Examples of normal requirements might
be requested types of graphical displays, specific system functions, and
defined levels of performance.
E x p e c t e d r e q u i r e m e n t s . These requirements are implicit to the prod-
uct or system and may be so fundamental that the customer does not ex-
plicitly state them. Their absence will be a cause for significant dissatis-
faction Examples of expected requirements are ease of human-machine
FIGURE 11.2. interaction, overall operational correctness and reliability, and ease of soft-
The FAST meeting ware installation.
278 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING ANALYSIS CONCEPTS AND PRINCIPLES 279
Exciting requirements. These features go beyond the customer’s ex- to accommodate the logical constraints imposed by processing requirements
pectations and prove to be very satisfying when present. For example, and the physical constraints imposed by other system elements.
word-processing software is requested with standard features. The deliv- In addition to the operational analysis principles noted above, Davis
ered product contains a number of page layout capabilities Lhat are quite suggests a set” of guiding principles for “requirements engineering”:
pleasing and unexpected.
!" Understand the to create the analysis model. There
In actuality, QFD spans the entire engineering process However, is a tendency to rush to a solution, even before the problem is understood.
many QFD concepts are applicable to the communication problem This often leads to elegant software that solves the wrong problem!
that faces a software engineer during early stages of requirements analysis. We !" a to understand how human-machine
present an overview of only these concepts (adapted for computer software) in Since the perception of the quality of software is often
the paragraphs that follow. on of the the interface, prototyping (and
In meetings with the customer, function is used to determine the iteration that results) is highly recommended.
the value of each function that is required for the system. Information deploy- !" Record the origin of and the reason for every requirement. This is the first step
ment identifies both the data objects and events that the system must consume
in establishing traceability back to the customer.
and produce. These are tied to the functions. Finally, task deployment examines
!" Use multiple of requirements. Building data, functional, and behavioral
the behavior of the system or product within the context of its environment.
Value analysis is conducted to determine the relative priority of requirements models provides the software engineer with three different views. This re-
determined during each of the three deployments noted above. duces the likelihood that something will be missed and increases the likeli-
QFD uses customer interviews and observation, surveys, and examination hood that will be
of historical data (e.g., problem reports) as raw data for the requirements gath- !" requirements. Tight deadlines may preclude implementation of
ering activity. These data are then translated into a table of software requirement. an incremental process model (Chapter 2) is
called the customer voice table-that is reviewed with the customer. A variety applied, those requirements to be delivered in the first increment must be
of diagrams, matrices, and evaluation methods are then used to extract ex- identified.
pected requirements and to attempt to derive exciting requirements !" Work to eliminate ambiguity. Because most requirements are described in a
natural language, the opportunity for ambiguity abounds. The use of formal
technical reviews is one way to uncover and eliminate ambiguity.
11.3 ANALYSIS PRINCIPLES
A software engineer who takes principles to heart is more likely to
that will for de-
their causes, and have developed a variety of modeling notations and corre- sign.
sponding sets of heuristics to overcome them. Each analysis method has a
unique point of all analysis by a set of
principles:
113.1 The Information Domain
1. The information domain of a problem must be represented and understood.
2 . The functions that the software is to must be defined. All software applications can be collectively called data processing. It is inter-
esting that this term contains a key to our understanding of software require-
3 . The behavior of the software (as a of external events) must be
ments. Software is built to data, to transform data from one form to
another, is, to it in way, and produce out-
4. The models that depict information, function, and behavior must parti- put. This fundamental of objective is true whether we build batch
tioned in a manner that uncovers detail in a layered (or hierarchical1 fashion. software for a payroll system or real-lime embedded software to control fuel
5 . The analysis process should move from essential information toward im- flow to an automobile engine.
plementation detail. It is important to note, however, that software also processes euents. An event
represents some aspect of system control and is really nothing more than boolean
By applying these principles, the analyst approaches a problem systematically. data-it is either on or off, true or false, there or not there. For example, a
The information domain is examined so that function may be understood more
completely. Models are used so that the characteristics of function and behav-
ior can be communicated in a compact fashion. Partitioning is applied to reduce a small subset requirements engineering principles noted here.For
complexity. Essential and implementation views of the software are necessary information, see
280 PART THREE, CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS CONCEPTS AND PRINCIPLES 281
sure sensor detects that pressure exceeds a safe value and sends an alarm sional table or as a hierarchical tree structure? Within the context of the struc-
to monitoring alarm signal is an that tho ture, what information is related to information? Is all information
within II or
and control both within of a problem. information in one information relate to information in another struc-
The first operational analysis principle requires an examination of the in- ture? These questions and others are answered by an assessment of informa-
formation domain. The information domain contains three different views of tion structure. It should be noted that structure, a related concept dis-
the data and control as each is processed by a computer program: informa- cussed later in this book, refers to the design and implementation of information
tion content and relationships, information flow, and information struc- structure.
ture. To fully understand the information domain, each of these views should
be considered.
Information content represents the individual data and control objects that 113.2 Modeling
comprise some larger collection of information that is transformed by the soft-
ware. For example, the data object paycheck is a composite of a number of im- We create models to gain a better understanding of the actual entity to be built.
portant pieces of data: the payee’s name, the net amount to be paid, the gross When the entity is a physical thing building, a plane, a machine), we can
pay, deductions, and so forth. Therefore, the content of paycheck is defined by build a model that is identical in form and shape, but smaller in scale. However,
the attributes that are needed to create it. Similarly, the content of a control when the entity is to be built is software, our model must take a different form.
system status might hy string of hits. Each bit rep- IL of that
of or partic- (and subfunctions) that Lhc transformation Lo occur, and
ular device is on- or off-line. behavior of the system as the transformation is taking place.
Data and control objects can be related to other data and control objects. During software requirements analysis, we create models of the system to
For example, the data object paycheck has one or more relationships with the be built. The models focus on what the system must do, not on how it does it.
objects timecard, employee, hank,and others. During the analysis of the in- In many cases, the models that we create make use of a graphical notation that
formation domain, these relationships should be defined. depicts information, processing, system behavior, and other characteristics as
in which and control change distinct and recognizable symbols. Other of the may be
i l l
can ho providrd using natural or a
Lo information (data and/or control), which is further specialized language for describing requirements.
transformed to output. Along this transformation path paths), additional in- The second and third operational analysis principles require that we build
formation may be introduced from an existing data store (e.g., a disk file or models of function and behavior.
memory buffer). The transformations that are applied to the data are functions
or subfunctions that a program must perform. Data and control that move be-
Functional models. Software transforms information, and in order to
tween two transformations (functions) define the interface for each function.
accomplish this, it must perform at least three generic functions: input,
Information structure represents the internal organization of various data
processing, and output. When functional models of an application are cre-
and control items. Are data or control items to be organized as an
ated, the software engineer focuses on problem-specific functions. The func-
tional model begins with a single context level model (i.e., the name of the
Lo bo built). a series of more and more functional
detail is provided, until a thorough delineation of all system functionality
is represented.
B e h a v i o r a l m o d e l s . Most software responds to events from the outside
world. This stimulus-response characteristic forms the basis of the behav-
ioral model. A computer always exists in some state-an exter-
nally observable mode of behavior (e.g., waiting, computing, printing,
polling) that is changed only when some event occurs. For example soft-
ware will remain in the wait until an internal clock indicates that
some time interval has passed, an external event (e.g., a mouse move-
ment) causes an interrupt, or an external system signals the
to act in some manner. A behavioral model creates a representation of the
FIGURE 11.3. states of the software and the events that cause software change state.
lnformotion flow and
transformation Models created during requirements analysis serve a number of important roles:
282 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS CONCEPTS AND PRINCIPLES 283
!" The model aids the analyst in understanding the information, function, and
behavior of a system, thereby making the requirements analysis task easier
and more systematic.
!" The model becomes the focal point for review and therefore the key to a de-
termination of completeness, consistency, and accuracy of the specification.
!" The model becomes the foundation for design, providing the designer with an
essential representation of software that can be translated into an imple- instant code chime
mentation context.
FIGURE11.4.
The analysis methods that are discussed in Chapters 12 and 20 are actu- control
ally modeling methods. Although the modeling method that is used is often a panel (o detailed de
matter of personal (or organizational) preference, the modeling activity is fun- scription of the con-
damental to good analysis work. trol functions
will be presented in
later chapters)
Partitioning
All interaction with is managed by a user-interaction subsystem
Problems are often too large and complex to be understood as a whole. For this that reads input provided through the keypad and function keys, displays
reason, we tend to partition (divide) such problems into parts that can be eas- prompting messages and system status on the LCD display. Keyboard interac-
ily understood and establish interfaces between the parts so that overall tion takes the following form.
lion can be accomplished. Tho fourth analysis principle suggests
functional, of software, can by
purtitioncd. information, functional, and domains of product. To illustrate,
In essence, partitioning decomposes a problem into its constituent parts. the functional domain of the problem will be partitioned. Figure 11.5 illustrates
Conceptually, establish a hierarchical representation of information or func- a horizontal decomposition of software. The problem is partitioned
tion and then partition the uppermost element by exposing increasing by representing constituent software functions, moving horizontally
detail by moving vertically in the hierarchy or decomposing the problem by in the functional hierarchy. Three major functions are noted on the level
moving horizontally in the hierarchy. To illustrate these partitioning ap- of the hierarchy
proaches, let us reconsider the security system described in Section The subfunctions associated with a major function may be ex-
11.2.2. The software allocation for (derived as a consequence of sys- amined by exposing detail vertically in the hierarchy, as illustrated in Figure
tem engineering and FAST activities) can be stated in the following para- Moving downward along a path below the function monitor
graphs: partitioning occurs vertically to show increasing levels of functional
software enables the homeowner to configure the security system The partitioning approach that we have applied to functions can
when it is installed, monitors all sensors connected to the security system, and also be applied to the information domain and behavioral domain as well. In
interacts with the homeowner through a function keys contained fact, partitioning of information flow and system behavior (discussed in Chapter
in the control panel shown in Figure 11.4. 12) will provide additional insight into system requirements. As the problem is
partitioned, interfaces between functions are derived. Data and control items
During installation, the control panel is used to “program” and that move across an interface should be restricted to inputs required to
configure the system. Each sensor is assigned a number and type, a master
password is programmed for arming and disarming the system, and telephone
are input for dialing when a sensor event occurs. Software
When a sensor event is recognized, the software invokes an audible alarm
attached to the system. After delay time that is specified by the homeowner
during system configuration activities, the software dials a telephone number FIGURE 11.5.
configure system monitor sensors interact with user
of a monitoring service and provides information about the location, reporting
the nature of the event that has been detected. The number will redialed partitioning of
every 20 seconds until telephone connection is obtained. function Horizontal Partitioning .
284 PART CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS CONCEPTS AND PRINCIPLES 285
Software by predefmed system elements (the sensor) and consider the implementation
view of function and information when such a view is appropriate.
We have already noted that software requirements analysis should focus
on what the software is to accomplish, rather than on processing will be
configure system monitor sensors interact with user. implemented. However, the implementation view should not necessarily be
terpreted as a representation of how. Rather, an implementation model repre-
I sents the current mode of operation, that is, the existing or proposed allocation
for all system elements. essential model (of function is generic in
activate
the sense that realization of function is not explicitly indicated.
sensor event alarm functions
FIGURE 11.6. 11.4 SOFTWARE PROTONPING
SafeHome-vertical read identify activate dial
partitioning of sensor event deactivate audible phone Analysis should be conducted regardless of the software engineering paradigm
tion status sensor number that is applied. However, the form that analysis takes will vary. In some cases
it is possible to apply operational analysis principles and derive a model of
from which can In other situations, requirementa
form the stated and outputs that are required by other functions or gathering (via FAST, QFD, or other “brainstorming” techniques is
system elements. ductcd, the analysis principles are applied, and a model of the software to be
built, called a prototype, is constructed for customer and developer assessment.
Finally, there are circumstances that require the construction of a prototype at
beginning of analysis, since the model is the only means through which
11.3.4 Essential and Implementation Views*
quirements can be effectively derived. The model then evolves into production
software.
An essential view of software requirements presents the functions to be ac- Boar [BOA841 justifies the prototyping technique in this way:
complished and information to be processed without regard to implementation
details. For example, the essential view of the function read sensor Most currently recommended methods for defining business system require-
status does not concern itself with the physical form of the data or the type of ments are designed to establish a final, complete, consistent, and correct set of
sensor that is used. In fact, it could be argued that read status would be a requirements before the system is designed, constructed, seen or experienced
more appropriate name for this function, since it disregards details about the by the user. Common and recurring industry experience indicates that despite
input mechanism altogether. Similarly, an essential data model of the data item the use of rigorous techniques, in many cases users still reject applications as
phone number(implied by the function dial phone number)can be repre- neither correct nor complete upon completion. Consequently, expensive,
sented at this stage without regard to the underlying structure (if consuming, and divisive rework is required to harmonize the original
used to implement the data item. By focusing attention on the essence of the cation with the definitive test of actual operational needs. In the worst case,
problem at early stages of requirements analysis, we leave our options open to rather than retrofit the delivered system, it is abandoned. Developers may
specify implementation details during later stages of requirements specifica- build and test against specifications but users accept or reject against current
tion and software design. and actual operational realities.
The implementation view of software requirements presents the real world
manifestation of processing functions and information structures. In some
Although the above quote represents an extreme view, its fundamental argu-
cases, a physical representation is developed as the step in software de-
ment is sound. In many (but not all) cases, the construction of a prototype, pos-
sign. However, most computer-based systems are specified in a manner that
sibly coupled with systematic analysis methods, is an effective approach soft-
dictates of certain implementation details. A input
device is a perimeter sensor (not a watch dog, a human guard, or a booby trap). ware engineering.
The sensor detects illegal entry by sensing a break in an electronic circuit. The
general characteristics of the sensor be noted as part of a software re-
quirements specification. The analyst must recognize the constraints imposed 11.4.1 Selecting the Approach
The prototyping paradigm can be either closed-ended or open-ended. The
closed-ended approach is often called throwaway prototyping. Using this
286 PART THREE, CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 11: ANALYSIS CONCEPTS AND PRINCIPLES 287
---
a prototype serves solely as a rough demonstration of requirements. It
is then discarded, and the software is engineered using a different paradigm. Additional
An open-ended approach, called evolutionary uses the prototype Throwaway E v o l u t i o n a r y Preliminary
as the first part of an analysis activity that will be continued into design and Question Prototype Prototype Work
construction. The prototype of the software is the evolution of the finished
system. Is the application domain understood? Yes Yes No
Before a closed-ended or open-ended approach can be chosen, it is neces- Can the problem be modeling? Yes Yes No
sary to determine whether the system to be built is amenable to prototyping. Is the customer certain of basic system Yes/No Yes/No No
A number of prototyping candidacy factors can be defined: application
requirements?
area, application complexity, customer characteristics, and project
Are requirements established/stable? No Yes Yes
In general, any application that creates dynamic visual displays, interacts Are any requirements ambiguous? Yes No Yes
heavily with a human user, or demands algorithms or combinatorial process-
ing that must be developed in an evolutionary fashion is a candidate for Are there contradictions in the requirements? Yes No Yes
totyping. However, these application areas must be weighed against application
complexity If a candidate application (one that has the characteristics noted
will require development of tens of thousands of lines of code before FIGURE 1 1.7. Selecting the appropriate prototyping approach
any demonstrable function can be performed, it is likely to be too complex for
prototyping.” If the complexity can be partitioned, however, it may still be pos-
sible to prototype portions of the software. 11.4.2 Prototyping Methods and Tools
Because the customer must interact with the prototype in later steps, it is
essential that customer resources be committed to the evaluation and re- For software prototyping to be effective, a prototype must be developed rapidly
finement of the prototype, and the customer be capable of making require- so that the customer may assess results and recommend changes. To conduct
ments decisions in a timely fashion. Finally, the nature of the development
three generic classes of methods and tools (e.g.,
project will have a strong bearing on the efficacy of prototyping. Is project are available: fourth generation techniques, reusable software com-
management willing and able to work with the prototyping method? Are pro- ponents, formal specification and prototyping environments.
tools available? Do developers have experience with prototyping
methods?
Andriole [AND921 suggests a set of six questions that will assist in the se- Fourth Generation Techniques Fourth generation techniques en-
of the prototyping approach: compass a broad array of data base query and reporting languages, program
application generators high level nonprocedural
Because 4GT enable the software engineer to generate executable code quickly,
Is the application domain for which software is to be built understood by the they are ideal for rapid prototyping.
!"
customer and the developer?
!"Does the problem to be solved lend itself to modeling?
Reusable Software Components Another approach to rapid prototyping is to
!" Is the customer fairly certain of basic system requirements? assemble, rather than build, the prototype by using a set of existing software com-
. Are requirements fairly well established and likely to be reasonably stable? ponents. A software may be a data structure (or database) or a soft-
!"Are any requirements ambiguous?
ware architectural component (i.e., a program) or a procedural component (i.e., a
module). In each case the software component must be designed in a manner that
Are there contradictions in the requirements? enables it to be reused without detailed knowledge of its internal workings.
Melding prototyping and program component reuse will work only if a li-
Figure 11.7 indicates typical sets of answers to these questions and the corre- brary system is developed so that components that do exist can be catalogued
sponding suggested prototyping approach. and then retrieved. Although a number of tools have been developed to meet
this need (e.g., much work remains to be done in this area.
It should be noted that an existing software product can be used as a pro-
totype for a “new, improved” competitive product. In a way, this is a form of
reusability for software prototyping.
useful discussion of other candidacy factors-“when to he found in
some cases, extremely complex prototypes can constructed rapidly by using fourth gen- Formal Specification and Prototyping Environments the past two
eration techniques reusable software components. decades, a number of formal specification languages and tools have been
288 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER : ANALYSIS NCEPTS AND PRINCIPLES 289
oped as a replacement for natural language specification techniques. Today, de- 11 Representation
*_
velopers of these formal languages are in the process of developing interactive
environments that (1) enable an analyst to interactively create a Figure 11.8 is a classic example of a good specification. The drawing, taken
based specification of a system or software, invoke automated tools that from Galileo’s work (circa is used to supplement text that describes his
translate the language-based specification into executable code, and (3) enable method for the analysis of the strength of a beam. Even without the accompa-
the customer to use the prototype executable code to formal requirements, , nying text, the diagram helps us to understand what must be done.
We have already seen that software requirements may be specified in a va-
riety of ways. However, if requirements are committed to paper or an electronic
11.5 presentation medium (and they almost always should be!) a simple set of guide-
lines is well worth following:
There is no doubt that the mode of specification has much to do with the qual-
ity of solution. who to work with A
or experienced the frus- of
tration and confusion that invariably results. The quality, timeliness, and can be developed. However, the representation forms contained within the
completeness of the software suffers as a consequence. specification are likely to vary with the application area. For example, a
specification of a manufacturing automation system would use different
symbology, diagrams, and language than the specification for a program-
Specification Principles ming language compiler.
Information contained within the specification should be nested. Repre-
Specification, regardless of the mode through which we accomplish it, may be sentations should reveal layers of information so that a reader can move
viewed as a representation process. Requirements are represented in a manner
that ultimately leads to successful software implementation. A number of spec-
ification principles, adapted from the work of and Goldman
can be proposed:
1. Separate functionality from implementation.
2. Develop a model of the desired behavior of a system that encompasses data
and the functional responses of a system to various stimuli from the envi-
ronment.
3. Establish the context in which software operates by specifying the manner
in which other system components interact with software.
4. the environment in which the system operates and how “a
highly intertwined collection of agents react to stimuli in the environment
(changes to objects) produced by those agents”
5. Create a cognitive model rather than a design or implementation model.
The cognitive model describes a system as perceived by its user community. FIGURE11.8.
Representation of
6. Recognize that “the specification must be tolerant of incompleteness and
specification
augmentable.” A specification is always a model-an abstraction--of some (Source: Galileo’s
real (or envisioned) situation that is normally quite complex. Hence, it will Discorsi
be incomplete and will exist at many levels of detail.
Establish the content and structure of a specification in a way that will en-
able it to be amenable Lo change. a due
science,
The list of basic specification principles noted. provides a basis for
. . 1638; from J. D.
representing requirements. However, must be translated Science in
into realization. In the next section we examine a set of guidelines for creating History, London,
a specification of requirements. Wans, 1969)
290 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER I ANALYSIS CONCEPTS AND PRINCIPLES 291
to the level of detail that is required. Paragraph and diagram numbering Introduction
schemes should indicate the level of detail that is being presented. It is A. System reference
sometimes worthwhile to present the same information at different levels Overall description
of abstraction to aid in understanding.
C. Software project constraints
Diagrams and other notational forms should be in number and II. Information Description
consistent in use. Confusing or inconsistent notation, whether graphical A. Information content representation
or symbolic, degrades understanding and fosters errors.
B. Information flow representation
Representations should be The content of a specification will 1. Data flow
change. Ideally, CASE tools should be available to update all 2. Control flow
tions that are affected by each change.
III. Functional Description
A. Functional partitioning
Investigators have conducted numerous studies (e.g.,
B. Functional description
human factors associated with specification. There appears to be little doubt
1. Processing narrative
that symbology and arrangement affect understanding. However, software en-
gineers appear to have individual preferences for specific symbolic and dia- 2. Restrictions/limitations
grammatic forms. Familiarity often lies at the root of a person’s preference, but 3. Performance requirements
other more tangible factors such as spatial arrangement, easily recognizable 4. Design constraints
patterns, and degree of formality often dictate an individual’s choice. 5. Supporting diagrams
C. Control Description
1. Control specification
2. Design constraints
11 The Software Requirements Specification IV. Behavioral Description
A. System states
The software requirements specification is produced at the culmination of the B. Events and actions
analysis task. The function and performance allocated to software as part of V. Validation and Criteria
system engineering are refined by establishing a complete information de- A. Performance bounds
scription, a detailed functional and behavioral description, an indication-of per-
B. Classes of tests
formance requirements and design constraints, appropriate validation criteria,
and other data pertinent to requirements. The National Bureau of Standards, FIGURE 11.9. C. Expected software response
IEEE (Standard No. and the U.S. Department of Defense have all Software require- D. Special considerations
proposed candidate formats for software requirements specifications (as well as ments specification VI. Bibliography
other software engineering documentation). For our purposes, however, the outline VII. Appendix
simplified outline presented in Figure 11.9 may be used as a framework for the
specification.
The introduction states the goals and objectives of the software, describing Probably the most important, and ironically, the most often neglected sec-
it in context of computer-based system. Actually, the introduction may tion of a software specification is How do we
more software of the planning document. successful What con-
provides a detailed description of the problem ducted to and constraints? neglect this sec-
that the software must solve. Information content and relationships, flow and tion because completing it demands a thorough understanding of software re-
structure are documented. Hardware, software, and human interfaces are de- quirements-something that we often do not have at this stage. Yet, specification
scribed for external system elements and internal software functions. of validation criteria acts as an implicit review of all other requirements. It is
A description of each function required to solve the problem is presented essential that time and attention be given to this section.
in the functional description. A processing narrative is provided for each func- Finally, the software requirements specification includes a bibliography
tion; design constraints are stated and justified; performance characteristics and appendix. The bibliography contains references to all documents that
are stated; and or more are included to represent the to the software other software engineering documentation,
overall structure of software and interplay among functions and vendor and standards. contains
other system elements. The description section of the specification information that supplements Tabular data, detailed descrip-
examines the operation of the software as a consequence of external events and tion of algorithms, charts, graphs, and other material are presented as appen-
internally generated control characteristics. dices.
292 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE CHAPTER 1: ANALYSIS CONCEPTS AND PRINCIPLES 293
In many case8 a software requirement8 specification may be accompanied !" Watch out for vague terms (e.g., some, sometimes, usually, ordinarily,
by an executable prototype (that in some cases may replace the specification), most, mostly); ask for clarification.
a paper prototype, or a preliminary manual. The preliminary user’s man-
!" When lists are given, but not completed, be sure all items are understood.
ual present8 the software as a black box. That is, heavy emphasis is placed on Keys to look for: “etc., and so forth, and 80 on, such as.”
user input and resultant output. The manual can serve as a valuable tool for
uncovering problems at the human-machine interface. !" Be sure stated ranges don’t contain unstated assumptions (e.g., Valid codes
range from 10 to 100. Integer? Real? Hex?).
!" Beware of vague verbs such as “handled, rejected, processed, skipped, elimi-
nated.” They can be interpreted in many ways.
11.6 SPECIFICATION REVIEW
!" Beware ambiguous pronouns (e.g., The module communicates with the
data validation module and its control is set. Whose control flag?)
Review of a software requirements specification (and/or prototype) is conducted
!" Look for statements that imply certainty (e.g., always, every, all, none, never),
by both software developer and customer. Because the specification forms the
foundation for and subsequent software engineering activities, extreme then ask for proof.
should be taken in conducting !" When a term is explicitly defined in one place, try substituting the definition
The review is conducted at a level. At this level, the occurrences of the term.
viewers attempt to ensure that the specification is complete, consistent, and ac- !" When a structure is described in words, draw a picture to aid in under-
curate. The following questions are addressed: standing.
!" When a calculation is specified, work at least two examples.
!" Do stated goals and objectives for software remain consistent with system
goals and objectives?
Once the review is complete, a software requirements specification is
!" Have important interfaces to all system elements been described? “signed off by both customer and developer. The specification becomes a “con-
!" Is information flow and structure adequately defined for the problem do- tract” for development. Changes in requirements requested after the
main? specification is finalized will not be eliminated, but the customer should note
!"Are diagrams clear? Can each stand alone without supplementary text? that each after-the-fact change is an extension of software scope and therefore
can increase cost and/or protract the
!"Do major functions remain within scope, and has each been adequately de-
Even with the best review procedures in place, a number of common spec-
scribed? ification problems persist. The specification is to in any mean-
!" Is the behavior of the software consistent with the information it must process ingful way, so inconsistency or omissions may pass unnoticed. During the re-
and the functions it must perform? view, changes to the specification may be recommended. It can be extremely
!"Are design constraints realistic? difficult to assess the global impact of a change; that is, how does a change in
one function affect requirements for other functions? Modem engi-
!" Have the technological risks of development been considered?
neering environment8 (Chapter incorporate CASE tools that have been de-
!" Have alternative software requirements been considered?
veloped to help solve these problems.
!" Have validation criteria been stated in detail? Are they adequate to describe
a 11.7 SUMMARY
!" Do inconsistencies, omissions, or redundancy exist?
!"Is the customer contact complete? Requirements analysis is the first technical step in the software engineering
!" Has the user reviewed the preliminary user’s manual or prototype? process. It is at this point that a general statement of software scope is refined
into a concrete specification that becomes the foundation for all software engi-
!" How are planing estimates affected?
neering activities that follow.
Analysis must focus on the information, functional, and behavioral do-
In order to develop answers to many of the above questions, the review may mains of a problem. To better understand what is required, models are created,
focus at a detailed level. Here, our concern is on the wording of the specification. the problem is partitioned, and representations that depict the essence of re-
We attempt to uncover problems that may be hidden within the specification con- quirements and later, implementation detail, are developed.
tent. The following guidelines for a detailed specification are suggested: In many cases, it is not possible to completely specify a problem at an early
stage. Prototyping offers an alternative approach that results in an executable
!" Be on the lookout for persuasive connectors (e.g., certainly, therefore, clearly, model of the software from which requisements can be refined. To properly con-
obviously, it follows that), and ask “why?” duct prototyping special tools and techniques are required.
294 PART CONVENTIONAL METHODS FOR ENGINEERING CHAPTER ANALYSIS CONCEPTS AND PRINCIPLES 295
A software requirements specification is developed as a consequence of PROBLEMS AND POINTS TO PONDER
analysis. Review is essential to ensure that developer and customer have the
same perception of the system. Unfortunately, even with the best of methods, 11.1. Software requirements analysis is unquestionably the most communication
the problem is that the problem keeps changing. intensive step in the software engineering process. Why does the communi-
cation path frequently break down?
11.2. There frequently severe political repercussions when software require-
REFERENCES ments (and/or system analysis) begins. For example, workers may
feel that job security is threatened by a now automated system. What causes
Akao, Function Deployment: Integrating Customer such problems? Can the analysis task be conducted so that politics is mini-
Requirements in Product Design (translated by G. Productivity mized?
Press, Cambridge MA, 1990. 1 1 . 3 . Discuss your perceptions of the ideal training and background for a systems
[AND921 Andriole, Rapid Application Prototyping, QED, 1992. analyst.
Arnold, S.P., and Stepoway, “The Reuse System: Cataloging and 1 1 . 4 . Throughout this chapter we refer to the “customer.” Describe the “customer”
Retrieval of Reusable Software,” COMPCON, 1987, pp. for information systems developers, for builders of computer-based products,
R., and N. Goodman, “Principles of Good Specification and their for systems builders. Be careful here, there may be more to this problem that
Implications for Specification Languages,” in Software Specification you first imagine!
Gehani and A.D. Addison-Wesley, 1986, Develop a facilitated application specification techniques (FAST) “kit.” The
pp. 25-39. kit should include a set of guidelines for conducting a FAST meeting, mate-
Boar, B., Application Prototyping, Wiley-Interscience, 1984. rials that can be used to facilitate the creation of lists, and any other items
that might help in defining requirements.
Bossert, J.L., Quality Function Deployment: A Approach,
ASQC Press, 1991. 1 1 . 6 . Your instructor will divide the class into groups of four or six students. Half
of the group will play the role of the marketing department, and half will
Curtis, B., Human Factors in Software Development, IEEE Computer
take on the role of software engineering. Your job is to define requirements
Society Press, 1986.
for the security system described in this chapter. Conduct a FAST
Davis, A., Software Requirements: Objects, Functions and States, meeting using the guidelines presented in this chapter.
Prentice-Hall, 1993.
1 1 . 7 . Is it fair to say that a preliminary user’s manual is a form of prototype?
Davis, A., 201 Principles of Software McGraw-Hill, 1996. Explain your answer.
Davis, A., “Software Prototyping,” in Advances in Computers, 40, 11.8. Analyze the information domain for Represent (using any nota-
Academic Press, 1995. tion that seems appropriate) information flow in the system, information
Gause, D.C., and G.M. Weinberg, Exploring Requirements: Quality Before content, and any information structure that is relevant.
Dorset House, 1989. 1 1 . 0 . Partition the functional domain for First perform horizontal par-
Holtzblatt, K., and E. teds.), Requirements Gathering: The titioning; then perform vertical partitioning.
Human Factor, a special issue of Communications of ACM, vol. 38, 11.10. Create essential and implementation representations of the sys-
no. 5, May 1995. tem.
Jordan, P.W. et al., “Software Storming: Combining Rapid Prototyping 11.11. Build a paper prototype (or a real prototype) of Be sure to depict
and Knowledge Computer, vol. 22, no. 5, May 1989, owner interaction and overall system function.
pp. 39-50.
11.12. TN to software comwnents of that mieht be ‘reusable”
Tanik, M.M., and R.T. Yeh teds.), “Rapid Prototyping in Software in other products or systems. Attempt to categorize these components
a special issue of IEEE Computer, vol. 22, no. May
Develop a for using the outline in
1989.
Figure 11.9. [Note: Your instructor will suggest which suctions to complete
Zahniser, R.A., “Building Software in Groups,” American Programmer, at this time.] Be sure to apply the questions that are described for the
vol. 3, no. July/August 1990. ification review.
Zultner, R., “Quality Function Deployment for Software: Satisfying How did your requirements differ from others who attempted a solution for
Customers,” American Programmer, February 1992, pp. 28-41. Who built a “Chevy”? Who built a “Cadillac?”
296 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS CONCEPTS AND 297
FURTHER READINGS AND OTHER INFORMATION SOURCES Additional information of requirements engineering, enterprise modeling, and
related topics can be found at:
Requirements analysis is a communication intensive activity. If communication
fails, even the best technical approach will fall short. Books by Gause and
Weinberg (Are Your On?, Dorset House, Davis and Kilov
and Ross (Information Modeling: An Object-Oriented Approach, Prentice-Hall, An up-to-date list of World Wide Web references that are relevant to
1994) contain excellent discussion of requirements analysis principles and con- ware analysis activities can be found at:
cepts. A book of short essays by Jackson (Software Requirements and Specifi-
cations, Addison-Wesley, 1995) presents opinion and guidance from one of the
exports in the
A comprehensive discussion of one requirements gathering method, Joint
Application Design, is presented by Wood and Silver (Joint Application Design,
2nd edition, Wiley, 1995). Worthwhile guidelines for conducting FAST meetings
are also Presented by Cohen (Quality Function Deployment, Addison-Wesley,
Gause and Weinberg and Zahniser The authors dis-
cuss the mechanics of effective meetings, methods for brainstorming, approaches
that can be used to clarify results, and a variety of other useful issues. A hook
by Martin (User Centered Requirements Analysis, Prentice-Hall, 1988) also dis-
cusses the need for effective customer-developer communication.
Information domain analysis is a fundamental principle of requirements
analysis. Books by Mattison Object-Oriented Enterprise, McGraw-Hill,
Practical Guide to Logical Data McGraw-Hill,
and (Data Analysis, Data Modeling and Classification, McGraw-
Hill, 1992) cover various aspects of this important subject. Gehani and
(Software Specification Techniques, Addison-Wesley, 1986) have
edited an important anthology of papers on software analysis topics, ranging
from basic principles of specification to specification and design en-
vironments. The results of more recent research can obtained from the
Proceedings of International Symposium on Engineering
sponsored by the IEEE.
Boar’s book on application prototyping [BOA841 and a book by and
Shafer (Structured Rapid Prentice-Hall, 1989) present this impor-
tant analysis technique with a definite information systems flavor. However,
many topics discussed by the authors are applicable across all application do-
mains. The Proceedings of the International Conference on Rapid Prototyping
sponsored by the IEEE presents an excellent overview of developments in rapid
prototyping.
Requirements Engineering Newsletter (an on-line publication) can be
acquired from:
An extensive bibliography on requirements engineering can be obtained at:
CHAPTER 12 ANALYSIS MODELING
!" The products of analysis must be highly maintainable. This applies particu-
larly to the Target Document [software ‘requirements specification].
!" Problems of size must be dealt with using an effective method of partition-
ing. The Victorian novel specification is out.
MODELING
!" Graphics have to be used whenever possible.
!" We have to differentiate between logical and physical
considerations
At the very least, we need . . .
!" Something to help us partition our requirements and document that parti-
tioning before specification
!" Some means of keeping track of and evaluating interfaces . .
!" New tools to describe logic and policy, something better than narrative text . .
With these words, DeMarco establishes the primary goals of an analysis method
that has become the most widely used in the world. In this chapter, we exam-
ine this method and its extensions.
12.1 A BRIEF HISTORY
A t a technical level, software engineering begins with a series of modeling
tasks that lead to a complete specification of requirements and a compre-
hensive design representation for the software to be built. The analysis model,
Like many important contributions to software engineering, structured analy-
sis was not introduced with a single landmark paper or book that was a defin-
actually a set of models, is the first technical representation of a system. itive treatment of the subject. Early work in analysis modeling was begun in
the years many methods have been proposed for analysis modeling. However, the late 1960s and early but the first appearance of the structured
two now dominate the analysis modeling landscape. The first, structured analysis approach was as an adjunct to another important topic-structured
is a classical modeling method and is described in this chapter. The other design. Researchers (e.g., needed a graphical notation for
approach, object-oriented analysis, is considered in detail in Chapter 20. A brief representing data and the processes that transformed it. These processes would
overview of other commonly used analysis methods is presented in Section 12.8. ultimately be mapped into a design architecture.
Structured analysis is a model building activity. Using a notation that sat- The term “structured analysis,” originally coined by Douglas Ross, was pop-
isfies the operational analysis principles discussed in Chapter 11, we create ularized by DeMarco In his book on the subject, DeMarco introduced
models that depict information (data and control) content and flow, we parti- and named the key graphical symbols that enabled an analyst to create infor-
tion the system functionally and behaviorally, and we depict the essence of mation flow models, suggested heuristics for the use of these symbols, sug-
what must be built. Structured analysis is not a single method applied consis- gested that a data dictionary and processing narratives could be used as a sup-
tently by all who use it. Rather, it is an amalgam that has evolved over almost plement to the information flow models, and presented numerous examples
20 years. that illustrated the use of this new method. In the years that followed, varia-
There is probably no other software engineering method that has gener- tions of the structured analysis approach were suggested by Page-Jones
ated as much interest, been tried (and often rejected and then tried again) by Gane and Sarson and many others. In every instance, the
as many people, provoked as much criticism, and sparked as much controversy, method focused on information systems applications and did not provide an ad-
but the method has prospered and has gained a substantial following in the equate notation to address the control and behavioral aspects of real-time en-
engineering community. gineering problems.
In his seminal book on the subject, Tom DeMarco describes struc- By the the deficiencies of structured analysis (when attempts
tured analysis in this way: were made to apply the method to control-oriented applications) became
painfully apparent. Real-time “extensions” were introduced by Ward and Mellor
Looking back over the recognized problems and failings of the analysis phase, and later by and Pirbhai These extensions resulted
I suggest that we need to make the following additions to our set of analysis in a more robust analysis method that could be applied effectively to engi-
phase goals: neering problems. Attempts to develop one consistent notation have been
300 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 12: ANALYSIS MODELING 301
gested and modernized treatments have been published to accommo- The data flow diagram purposes: (1) to provide an indi-
date the use of CASE tools cation of how data are transformed as they move through the system, and
to depict the functions (and subfunctions) that transform the data flow. The
DFD provides additional information that is used during the analysis of the in-
12.2 THE ELEMENTS OF THE ANALYSIS MODEL formation domain and serves as a basis for the modeling of function. A de-
scription of each function presented in the DFD is contained in a process spec-
The analysis model must achieve three primary objectives: (1) to describe what ification
The state-transition diagram indicates how the system behaves as a
the customer requires, to establish a basis for the creation of a software de-
consequence of external events. To accomplish this, the STD represents the var-
sign, and to define a set of requirements that can be validated once the soft-
ious modes of behavior (called states) of the system and the manner in which
ware is built. To accomplish these objectives, the analysis model derived dur-
transitions are made from state to state. The STD serves as the basis for be-
ing structured analysis takes the form illustrated in Figure 12.1.
havioral modeling. Additional information about control aspects of the software
At the core of the model lies the data dictionary-a repository that contains
is contained in the control specification
descriptions of all data objects consumed or produced by the software. Three
The analysis model encompasses each of the diagrams, specifications, and
different diagrams’ surround the core. The entity-relationship diagram
descriptions, and the dictionary noted in Figure 12.1. A more detailed discussion
depicts relationships between data objects. The ERD is the notation that is
of these elements of the analysis model is presented in the sections that follow.
used to conduct the data modeling activity. The attributes of each data object
noted in the ERD can be described using a data description.
12.3 DATA MODELING
Data modeling answers a set of specific questions that are relevant to any data
processing application. What are the primary data objects to be processed by
the system? What is the composition of each data object and what attributes
describe the object? Where do the objects currently reside? What are the rela-
tionships between each object and other objects? What is the relationship be-
tween the objects and the processes that transform them?
To answer these questions, data modeling methods make use of the
relationship diagram The ERD, described in detail later in this section,
enables a software engineer to identify data objects and their relationships us-
ing a graphical notation. In the context of structured analysis, the ERD defines
all data that are input, stored, transformed, and produced within an application.
The entity-relationship diagram focuses solely on data (and therefore sat-
isfies the first operational analysis principle), representing a “data network
that exists for a given system. The ERD is especially useful for applications in
Data Dictionary
I which data and the relationships that govern data are complex. Unlike the data
flow diagram (discussed in Section 12.4 and used to represent how data are
transformed), data modeling considers data independently of the processing
that transforms the data.
12.3.1 Data Objects, Attributes, and Relationships
The data model consists of three interrelated pieces of information: the data
object, the attributes that describe the data object, and the relationships that
connect data objects to one another.
FIGURE 12.1.
The structure of the A data object is a representation of almost composite informa-
analysis model tion that must be understood by software. By composite information, we mean
CHAPTER ANALYSIS MODELING 303
302 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
Relationships: one data to
attributes in this case, owner,
Name Descriptive
identifier attributes attributes
license
Make ID& Body
Number
Lexus Sedan White RSP
FIGURE12.3. Chevy Corvette X466... Spans R e d
Tabular BMW White LJL
tian of data objects . Ford Taurus Sedan BLF
Make find an instance of the data object. In some cases, values for the identifier(s)
FIGURE 12.2.
are unique, this is not a requirement. Referring to the data abject car,
Data attrib
a reasonable identifier might be the
and
The set of attributes that is appropriate far a given data object is deter-
ships
mined through understanding of the problem context. The attributes for car
described might well for an application that would be used by a
Department of Motor Vehicles, but these attributes would be useless for an au-
something that has a number of different properties or attributes. Therefore, tomobile company that needs manufacturing control software. In the latter
“width” single value) would not be a valid data object, but dimensions (in- case, the attributes far car might also include body type, and color, but
corporating height, width, and depth) could be defined as an object. many additional attributes (e.g., interior code, drive train trim package
A data object can be an external entity (e.g., anything that produces or designator, transmission type) would have to be added to make car a mean-
information), a thing (e.g., a report or a display), an occurrence (e.g., a ingful abject in the manufacturing control context.
phone call) or event (e.g., an alarm), a role (e.g., salesperson), an organizational
unit (e.g., accounting a place (e.g., a warehouse), or a structure (e.g., Relationships Data objects are connected to one another in a variety of differ-
a file). For example, a person or a car (Figure 12.2) can be viewed as a data ab- ent ways. Consider two data objects, book and bookstore. These objects can
ject in the sense that either be defined in terms of a set of attributes. The be represented using the simple notation illustrated in Figure A con-
object description incorporates the data abject and all of attributes. nection is established between book and bookstore because the two objects
Data objects are related to one another. For example, person can own car, are related. But what are the relationships? To determine the answer, we must
where the relationship connotes a specific connection between and
car. The relationships are always defined by the context of the problem that is
being analyzed,
A data object encapsulates data only-there is no reference within a data
abject to operations that act on the data.’ Therefore, the data object can be rep- Bookstore
resented as a table as shown in Figure 12.3. The headings in the table reflect
attributes of the abject. In this case, a car is defined in terms of make, model,
body type, color, and owner. The body of the table represents specific in- A basic connection between objects
stances of the data abject. For example, a Chevy Corvette is an instance of the
data object car.
orders
Attributes define the properties of a data abject and take on one of
three different characteristics. They can be used to name an instance of the
data object, (2) describe the instance, or make reference to another instance
in another table. In addition, one or more of the attributes must be defined as
an is, the identifier attribute becomes a “key” when we want to
I returns
12.4.
‘This distinction separates the data object from the class or object defined as part of the
object oriented paradigm discussed Part Four of Relationships Relationships between objects
304 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS MODELING 305
understand the role of books and bookstores within the context of the software !" One-to-many occurrence of [object] ‘A’ can relate to one or
to be built. We can define a set of object-relationship pairs that define the rel- many occurrences of [object] ‘B,’ but an occurrence of can relate to only
evant relationships. For example, one occurrence of ‘A.’ For example, a mother can have many children, but
a child can have only one mother.
!" a bookstore orders books
!" Many-to-many occurrence of ‘A’ can relate one or
!" a bookstore displays books more occurrences of ‘B,’ while an occurrence of ‘B’ can relate to one or
!" a bookstore stocks books more occurrences of ‘A.’ For example, an uncle can have many nephews,
while a nephew can have many uncles.
!" a bookstore sells books
!" a bookstore returns books Cardinality defines “the maximum number of object relationships that can par-
ticipate in a relationship” It does not, however, provide an indication
The relationships orders, displays, stocks, sells, and returns define the relevant of whether or not a particular data object must participate in the relationship.
connections between book and bookstore. Figure illustrates these To specify this information, the data model adds modality to the
object-relationship pairs graphically. relationship pair.
It is important to note that object-relationship pairs are bidirectional; that
is, they can be read in either direction. A bookstore orders books or books are Modality The modality of a relationship is zero if there is no explicit need for
ordered by a the relationship to occur or the relationship is optional. The modality is 1 if an
occurrence of the relationship is mandatory. To illustrate, consider software
that is used by a local telephone company to process requests for field service.
A customer indicates that there is a problem. If the problem is diagnosed as
12.3.2 Cardinality and Modality
relatively simple, a single repair action occurs. However, if the problem is com-
plex, multiple repair actions may be required. Figure 12.5 illustrates the rela-
The basic elements of data modeling-data objects, attributes, and relation- tionship, cardinality, and modality between the data objects customer and
ships-provide the basis for understanding the information domain of a prob- pair action.
lem. However, additional information related to these basic elements must also In the figure, a 1 to many cardinality relationship is established. That is, a
be understood. single customer can be provided with zero or many repair The
We have defined a set of and represented the pairs on the relationship connection closest to the data object rectangles indi-
that bind them. But a simple pair that states: object X relates to object Y does cate cardinality. The vertical bar indicates 1, and the three-pronged fork indi-
not provide enough information for software engineering purposes. We must un- cates many. Modality is indicated by the symbols that are further away from
derstand how many occurrences of object X are related how many occurrences the data object rectangles. The second vertical bar on the indicates that
of object Y. This leads to a data modeling concept called cardinality. there must be a customer for a repair action to occur. The circle on the right
indicates that there may be no repair action required for the type of problem
Cardinality The data model must be of representing the number of oc- reported by the customer.
currences of objects in a given relationship. defines the
dinality of an object-relationship pair in the following manner:
is the of the number of occurrences of one [object] that 123.3 Entity-Relationship Diagrams
can be related to the number of occurrences of another [object]. Cardinality is
usually expressed simply ‘one’ or ‘many.’ For example, a husband can have only The object-relationship pair (discussed in Section 12.3.1) is the cornerstone of
one wife (in most cultures), a parent can have many children. Taking into the ‘data model. These pairs can be represented graphically using the entity
consideration combinations of ‘one’ and ‘many,’ two be related relationship diagram The ERD was originally proposed by Peter Chen
for the design of relational database systems and has been extended
!" One-to-one occurrence of ‘A’ can relate to one and only by others. A set of primary components are identified for the ERD: data objects,
one occurrence of ‘B,’ and an occurrence of ‘B’ can relate to only
one occurrence of ‘A.’ For example, a husband can have only one wife, and
a wife only one husband (at least here in New Jersey).
may be a situation in which a repair action is not required.
is important note that many different have been proposed for representing
avoid ambiguity, manner in which a relationship is labeled be considered. For cardinality, and modality. Alternative notations are presented in Section 12.3.4.
example, if context not for bidirectional relation, Figure could be misin- the “data entity” or “entity” has been replaced by ‘data object.” However, the term
terpreted mean that books order In such is “entity” remains a part of the name of the graphical notation for object-relationship
306 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 12. ANALYSIS MODELING 307
Cardinality:
Cardinality: Implies that there may be
Implies that a single many repair action(s)
customer awaits repair action(s)
\
is provided with
Customer
Modality: Mandatory Modality: Optional
FIGURE 12.5. Implies that in order to Implies that there may
and have a repair action(s), be a situation in which a
modality we must have a customer repair action is not necessary
attributes, relationships, and various type indicators. The primary purpose of
the ERD is to represent data objects and their relationships.
Rudimentary ERD notation has already been introduced in Section 12.3.
Data objects are represented by a labeled rectangle. Relationships are indicated
with a labeled line connecting objects. In some variations of the ERD, the con-
necting line contains a diamond that is labeled with the relationship.
Connections between data objects and relationships are established using a va-
riety of special symbols that indicate cardinality and modality (Section FIGURE 12.7.
The relationship between data objects car and manufacturerwould be An expanded ERD
represented as shown in Figure 12.6. One manufacturer builds one or many
cars. Given the context implied by the ERD, the specification of the data object
car (see the data object table in Figure 12.61 would be radically different from
the earlier specification (Figure 12.3). By examining the symbols at the end of
the connection line between objects, it can be seen that the modality of oc-
currences is mandatory (the vertical lines).
Expanding the model, we represent a grossly oversimplified ERD (Figure
12.7) of the distribution element of the automobile business. New date objects,
shipper and dealership, are introduced. In addition, new
transports, contracts, and stocks-indicate how the data objects shown
in the associate with one another. Tables for each of data objects
in would have to according to the rules introduced
earlier in this chapter.
12.6. In addition to the basic ERD notation introduced in Figures 12.6 and 12.7,
A simple ERD and the analyst can represent object type hierarchies. In many instances, a
data table data object may actually represent a class or category of information. For ex-
(Note: In this ERD ample, the data object oar can be categorized as domestic, European, or Asian.
the relationship The ERD notation shown in Figure 12.8 represents this in the
builds is indicated model body type engine transmission!" !" ! form of a hierarchy.
by o diamond on ERD notation also provides a mechanism that represents the associativity
the connecting line between objects. An associative object is represented as shown in Figure
between data ob 12.9. In the figure, the data objects that model individual subsystems are each
associated with the data object car.
308 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS MODELING 309
Data modeling and the entity-relationship diagram provide the analyst
with a concise notation for examining data within the context of a data pro-
car cessing application. In most cases, the data modeling approach is used to cre-
ate one piece of the analysis model, but it can also be used for database design
and to support any other requirements analysis method.
12.4 FUNCTIONAL MODELING AND INFORMATION PLOW
Information is transformed as it flows through a computer-based system. The
system accepts input in a variety of forms; applies hardware, software, and hu-
E u r o p e a n domestic Asian man elements to transform input into output; and produces output in a vari-
ety of forms. Input may be a control signal transmitted by a transducer, a se-
t ries of numbers typed by a human operator, a packet of information transmitted
on a network link, or a voluminous data file retrieved from a CD-ROM. The
transform(s) may comprise a single logical comparison, a complex numerical al-
gorithm or rule-inference approach of an expert system. Output may light a
single LED or produce a report. In effect, we can create a flow model
for any computer-based system, regardless of size and complexity.
analysis an flow A
French/ computer-based is represented as an information transform shown
German Italian
English in Figure 12.10. Overall function of the system is represented as a single in-
formation transform, noted as a bubble in the figure. One or more inputs,
shown as labeled arrows, originate from external entities, represented as a box.
FIGURE 12.8. Data object type The input drives the transform to produce output information (also represented
as labeled arrows) that is passed to the external entities. It should be noted
that the model may be applied to the entire system or to the software element
only. The key is to represent the information fed into and produced by the
transform.
electronics
12.4.1 Data Flow Diagrams
As information moves through software, it is modified by a series of transfor-
mations. A data flow diagram is a graphical technique that depicts in-
engine interior drive train formation flow and the transforms that are applied as data move from input to
output. The basic form of a data flow diagram is illustrated in Figure 12.10.
The is also known as a data flow graphor a bubble chart.
The data flow diagram may be used to represent a system or software at
any level of abstraction. In fact, may be partitioned into levels that rep-
resent increasing information flow and functional detail. Therefore, the
provides a mechanism for functional modeling as well as information flow mod-
eling. In so doing, it satisfies the second operational analysis principle (i.e., cre-
ating a functional model) discussed in Chapter
A level 0 DFD, also called a fundamental system model or a context model,
FIGURE 12.9. car represents the entire software element as a single bubble with input and out-
Associating data ob put data indicated by incoming and outgoing arrows, respectively. Additional
processes (bubbles) and information flow paths are represented as the level 0
310 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 12: ANALYSIS MODELING 311
DFD is partitioned to reveal more detail. For example, a level 1 DFD might con-
tain or six bubbles with interconnecting arrows. Each of the processes rep-
resented at level 1 are subfunctions of the overall system depicted in the con-
text model.
The basic used to create a DFD is illustrated in Figure 12.11. A
rectangle is used to represent an external entity, that is, a system element (e.g.,
hardware, a person, another program) or another system that produces
to notation discussed in Section 12.4.2.
external
entity
FIGURE 12.12.
Information flow
refinement
external external
FIGURE 12.10. information information
entity entity
Information flow
model
for transformation by the software or receives information produced by
the software. A circle represents a process or transform that is applied to data
(or control) and changes it in some way An arrow represents one or more data
A producer or consumer of information that items or data objects. All arrows on a data flow diagram should be labeled. The
external
resides outside the bounds of the system to double line represents a store-stored information that is used by the soft-
entity be modeled ware. The simplicity of DFD notation is one reason why structured analysis
techniques are the most widely uaed.
It is important to note that no explicit indieation of the sequence of pro-
cessing is supplied by the diagram. Procedure or sequence may be implicit in
A transformer of information function1 the diagram, but explicit procedural representation is generally delayed until
that resides within the bounds of the software design.
system to be modeled As we noted earlier, each of the bubbles may be refined or layered to depict
more detail. Figure 12.12 illustrates this concept. A fundamental model for sys-
tem F indicates the primary input is A and ultimate output is We refine the
F model into transforms to Note that information flow continuity must be
A data object; the arrowhead the maintained, that is, input and output to each must remain the same.
direction of data flow This concept, sometimes called balancing, is essential for the development of
consistent models. Further refinement of detail in the form of
forms to Again, the input and output remain unchanged.
The data flow diagram is a graphical tool that can be very valuable during
A repository of data that is to be stored for software requirements analysis. However, the diagram can he misinterpreted if
uae by one or more processes; may be its function is with the flowchart. A data flow diagram depicts infor-
FIGURE 12.11. d a t a simple as a buffer or queue or as mation flow without explicit representation of procedural logic (e.g., conditions
Basic DFD notation sophisticated a relational database or loops). It is not a flowchart with rounded
312 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 12: ANALYSIS MODELING 313
The basic notation used to develop a DFD is not in itself to de-
scribe requirements for software. For example, an arrow shown in a DFD rep- A data object that is input or output from a
resents a data object that is input to from a process. A data store rep-
process on a “continuous” basis
resents some organized collection of data. But what is the content of the data
implied by the arrow or depicted by the store? If the arrow (or the store) rep- data flow
resents a collection of objects, what are they? These questions are answered by
applying another component the basic notation for structured analysis-the
The format and use of the data dictionary are presented later A transformer of control or “events”;
in this chapter. control
accepts control and input and produces
Finally, the graphical notation represented in Figure 12.11 must be aug- , process control as output
mented with descriptive text. A processing specification be used \
to specify the processing details implied by a bubble within The pro- 3
specification describes the input function, the algorithm that is ap-
plied to the input and the output that is produced. In addition, the PSPEC A control item or event; takes on a boolean
indicates restrictions and limitations imposed on the process (function),
or discrete value; the arrowhead indicates
performance characteristics that are relevant to the process, and design con- item the direction of data flow
straints that may influence the way in which the process will be implemented.
A repository of control items that are to be
12.4.2 Extensions for Real-lime control store URC by more
Many applications are time-dependent and process as much or more
control-oriented information as A real-time system must interact with the 12.13.
real world in a time frame dictated by the real world. Aircraft avionics, manu- Extended structured Multiple equivalent instances of the same
facturing process control, consumer products, and industrial instrumentation analysis notation for
process; used when multiple processes are
are but a few of hundreds of real-time software applications. real-time systems
created in multitasking system
To accommodate the analysis of real-time software, a number of extensions veloped by Ward
to the basic notation for structured analysis have been proposed. These exten- and Mellor
sions, developed by Ward and Mellor [WAR851 and Hatley and Pirbhai [HAT871
and shown in Figures 12.13 and 12.14, enable the analyst to represent control
flow and control processing flow and proccnning. In a significant percentage of real-time applications, the system must mon-
itor information generated by some real world process. For ex-
ample, a real-time test monitoring system for gas turbine engines might be re-
quired to monitor turbine speed, combustor temperature, and a variety of
12.4.3 Ward and Mellor Extensions pressure probes on a continuous basis. Conventional data flow notation does
Ward and Mellor extend basic structured analysis notation to accom-
modate the following demands imposed by a real-time system: A control item or event; takes on a boolean
or discrete arrowhead indicates
!" Information flow that is gathered or produced on a time-continuous basis item the direction of data flow.
!" Control information throughout control
processing
!" Multiple instances of which are sometimes FIGURE12.14. The vertical bar is a reference to a control
in multitasking situations Extended structured
specification that describes the
!" System states and the mechanism that causes transition between states analysis notationfor
real-time systems de- behavior of a system and defines how
by processes are activated as a consequence
term dictionary” in and Pirbhai of events.
314 PAR T HREE.
T M ETHODS FOR ENGINEERING CHAPTER 12: ANALYSIS MODEUNG 315
monitored input movement
temperature alarm
of each
fixture
corrected
FIGURE 12.15.
data temperature
set-point
not make a distinction between discrete data and time-continuous data. An ex-
tension to basic structured analysis notation, shown in Figure 12.15, provides
a mechanism for representing time-continuous data flow. The double headed
arrow is used to represent time-continuous flow, and a single headed arrow is
used to indicate discrete data flow. In the figure, monitored temperature is
measured continuously while a single value for temperature set-point is also FIGURE 12.16.
provided. The process shown in the figure produces a time-continuous output, Data and control
corrected value. flows using Ward
The distinction between discrete and time-continuous data flow has im- and Mellor robot command file
portant implications for both the system engineer and the software designer. notation
During the creation of the system model, a system engineer will be better able
to isolate those processes that may be performance critical (it is likely that the
input and output of time-continuous data will be performance sensitive). As the assembled by a robot are placed on fixtures, a status bit is set within a parts
or model is created, the designer must establish a status buffer control store) that indicates the presence or absence of each
mechanism for collection of time-continuous data. Obviously, the digital system component. Event informution contained within the parts status buffer is
collects data in a quasi-continuous fashion using techniques such as high-speed passed as a bit string to a process, monitor and operator The
polling. The notation indicates where analog to digital hardware will be re- process will read operator commands only when the control information, bit
quired and which transforms are likely to demand high-performance software. string, indicates that all fixtures contain components. An event flag, start/stop
In conventional data flow diagrams, control or event flows are not repre- a
flag, is sent to robot initiation control, control process that enables further
explicitly. In fact, the analyst is cautioned to specifically exclude the rep: command processing. Other data flows occur as a consequence of the process
resentation of control flow from the data diagram. This exclusion is overly activate event that is sent to process robot commands.
restrictive when real-time applications are considered and for this reason, a In some situations multiple instances of the same control or data trans-
specialized notation for representing event flows and control processing has formation process may occur in a real-time system. This can occur in a multi-
been developed. Continuing the convention established for data flow diagrams, tasking environment when tasks are spawned as a result of internal process-
data flow is represented using a solid arrow. Control flow, however, is repre- ing or external events. For example, a number of part status buffers may be
sented using a dashed or shaded arrow. A process that handles only control monitored 80 that different robots can be signaled at the appropriate time. In
flows, called a control process, is similarly represented using a dashed bubble. addition, each robot may have it8 own robot control system. The Ward and
Control flow can be input directly to a conventional process or into a con- Mellor notation used to represent multiple instances of the same
trol process. Figure 12.16 illustrates control flow and processing as it would be process is shown in Figure 12.13.
represented using Ward and Mellor notation. The figure illustrates a top-level
view of a data and control flow for a manufacturing As components to be
12.4.4 and Pirbhai Extensions
manufacturing cell is in factory automation applications. It contains computers and
automated machines (e.g., robots, NC machines, specialized fixtures) and performs one The Hatley and Pirbhai extensions to basic structured analysis no-
manufacturing operation under computer control. tation focus loss on the creation of additional graphical symbols and mere on
316 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS MODELING 317
the representation and specification of the control-oriented aspects of the soft-
ware. In Figure 12.14 the dashed arrow is once again used to Process Model
data
or event flow. Unlike Ward and Mellor, Hatley and Pirbhai suggest that dashed output
and solid notation be represented separately. Therefore, a control flow diagram .
is defined. The CFD contains the same processes as the DFD, but shows
control flow rather than data flow. Instead of representing control processes di-
rectly within the flow model, a notational reference solid bar) to a control
specification is used. In essence, the solid bar can be viewed as a “win-
dow” into an “executive” (the CSPEC) that controls the processes (functions) rep- - -
resented in the DFD based on the event that is passed through the window. The prokess
CSPEC, described in detail in Section 12.6.4, is used to indicate how the soft-
activators
ware behaves when an event or control signal is sensed and which processes
are invoked as an consequence of the occurrence of the event. A process specifi-
cation is used to describe the inner workings of a process represented in a flow
diagram. Control Model data
Using the notation described in Figures 12.11 and 12.14, along with addi- conditions
tional information contained in and Hatley and Pirbhai cre-
ate a model of a real-time system. Data flow diagrams are used to represent
data and the processes that manipulate it. Control flow diagrams show how
events flow among processes and illustrate those external events that cause
various processes to be activated. The interrelationship between the process
and control models is shown schematically in Figure 12.17, The process model
is to control through conditions. The control FIGURE 12.17. ---------
The relationship control output
is process information con- input
tained in the CSPEC. data and con-
A data condition occurs whenever data input to a process results in a con- models
trol output. This situation is illustrated in Figure 12.18, part of a flow model
for an automated monitoring and control system for pressure vessels in an oil
refinery. The process check pressure implements the algorithm de- provide a notation for this type of modeling. The state-transition rep-
scribed in the PSPEC pseudocode shown. When the absolute tank pressure is resents the behavior of a system by depicting its states and the events that
greater than an allowable maximum, an above pressure event is generated. cause the system to change state. In the STD indicates what actions
Note that when Hatley and Pirbhai notation is used, the data flow shown as (e.g., process activation) are taken as a consequence of a particular event.
part of a DFD, while the control flow is noted separately as part of a control A state is any observable mode of behavior. For example, states for a mon-
flow diagram. To determine what happens when this event occurs, we must itoring and control system for pressure vessel described in Section 12.4.4 might
check the CSPEC. be monitoring state, alarm state, pressure release state, and so on. Each of these
The control specification (CSPEC) contains a number of important modeling states represents a mode of behavior of the system. A state transition diagram
tools. A process table (described in Section is used to indicate indicates how the system moves from state to state.
which processes are activated by a given event that flows through the vertical To illustrate the use of the Hatley and Pirbhai control and behavioral exten-
bar. For example, a process activation table (PAT) for Figure 12.18 might indi- sions, consider embedded within an office photocopying machine. The
cate that the above pressure event would cause a process reduce tank pressure photocopier performs a number of functions that are implied by the level 1 DFD
(not shown) to be invoked. In addition to the PAT, the CSPEC may contain a shown in Figure 12.19. It should be noted that additional refinement of the data
state-transition diagram The STD is a behavioral model that relies on the flow and definition of each data item (using a data would be required.
definition of a set of slates and is described in the following section. The control flow for the photocopier software is shown in Figure 12.20.
Control are shown and exiting individual processen and the
“window.” For example, the paper feed status and events
flow into the CSPEC bar. This implies that each of these events will cause
12.5 BEHAVIORAL MODELING
Behavioral modeling is an operational principle for all requirements analysis of diagram, tabular representation for state transition can also be used. For ad-
methods. Yet, only extended versions of structured analysis ditional information,
318 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS MODELING 319
data flow diagram control diagram
operator
commands
if absolute tank pressure max pressure
then FIGURE 12.19.
set above pressure to “true”; level DFD for
else
set above pressure “false”;
begin conversion algorithm x-Ola;
compute converted pressure; paper feed status
end (jammed, empty)
alarm
FIGURE 12.18.
Data conditions
process represented in the CFD to be activated. If we were to examine the
CSPEC internals, the event would be shown to activate/deactivate
the manage copying process. Similarly, the jammed event (part of paper feed
status) would activate perform problem diagnosis. It should be noted that all
vertical bars within the CFD refer to the same CSPEC.
An event flow can be input directly into a process as shown with repro
fault. However, this flow does not activate the process, but rather
trol information for the process algorithm. Data arrows have been lightly
shaded for illustrative purposes, but in reality they are not shown as part of a
control flow diagram.
A simplified state transition diagram for the photocopier software de-
scribed above is shown in Figure 12.21. The rectangles represent system states
and the arrows represent transitions between states. Each arrow is labeled
with a ruled expression. The top value indicates the that cause the
transition to occur. The bottom value indicates the action that as a con- FIGURE 12.20.
sequence of the event. Therefore, when the paper tray is and the start but- Level 1 CFD for
ton is pressed, the system moves from the reading commands state to the
320 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS MODELING 321
Creating an Entity-Relationship Diagram
The entity-relationship diagram enables a software engineer fully specify the
data objects that are input and output from a system, the attributes that de-
fine the properties of these objects, and the relationships between objects. Like
most elements of the analysis model, the ERD is constructed in an iterative
manner. The following approach is taken:
copies done
- - -
read-op-tnput read-op-mnput 1. During requirements gathering, customers are asked to list the “things”
that the application or business process addresses. These “things” evolve
I into a list of input and output data as well as external entities that
produce or consume information.
2. Taking the objects one at a time, the analyst and customer define whether
or not a connection (unnamed at this stage) exists between the data object
3. Wherever connection exists, customer one or more
object-relationship pairs.
jammed
invoke perform problem-diagnosis 4. For each object-relationship pair, and modality are explored.
5. Steps 2 through 4 are continued iteratively until all object-relationship
pairs have been defined. It is common to discover omissions as this process
FIGURE 12.21. continues. New objects and relationships will invariably be added as the
Simplified state tran- number of iterations grows.
sition diagram for
6. The attributes of each entity are defined.
photocopier software
7. An entity-relationship diagram is formalized and reviewed.
8. Steps 1 through 7 are repeated until data modeling is complete.
To illustrate the use of these basic guidelines, the security sys-
tem example, discussed in Chapter 11, will be used. A processing narrative for
copies state. Note that states do not necessarily correspond to processes on is reproduced below:
a one-to-one basis. For example, the state would encompass both
the manage copying and produce user displays processes shown in Figure 12.20.
enables the homeowner to configure the security system
when it is installed, monitors all sensors connected the security system, and
interacts with the homeowner through a keypad and function keys contained
12.6 THE MECHANICS OF STRUCTURED ANALYSIS in the control shown in 11.4.
During installation, the control pane1 is used to “program” and
In the previous section, we discussed basic and extended notation for struc- configure the system. Each sensor is assigned a number and type, a master
tured analysis. To be used effectively in software requirements analysis, this password is programmed for arming and disarming the system, and telephone
notation must be combined with a set of heuristics that enable a software en- number(s) are input for dialing when a sensor event occurs.
gineer to derive a good analysis model. To illustrate the use of these heuristics, When a sensor event is recognized, the software invokes an audible alarm
an adapted version of the Hatley and Pirbhai [HAT871 extensions to the basic attached to the system. After a delay time that is specified by the homeowner
structured analysis notation will be used throughout the remainder of this during system configuration activities, the software dials a telephone number
chapter. of a monitoring service, provides information about the location, reporting the
In the sections that follow, we examine each of the steps that should be ap- nature of the event that has been detected. The number will be redialed every
plied to develop complete and accurate models using structured analysis. 20 seconds until telephone connection is obtained.
Through this discussion, the notation introduced in Section 12.4 be used, All interaction with is managed by a user-interaction subsystem
and other notational forms, alluded to earlier, will be presented in some detail. that reads input provided through the keypad und function keys, displays
CHAPTER ANALYSIS MODELING 323
322 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
prompting messages and system status on the LCD display. Keyboard interac- security system monitors
tion takes the following form . security system enablesldisables
security system tests
Discussions between the analyst and the customer indicate the following (par- security system programs
tial) list of that are relevant to the problem:
Each of the above object-relationship pairs is analyzed to determine
!" homeowner ity and modality. For example, in the object-relationship pair security
!" control panel monitors sensor, the cardinality between security system and is one
!" #$%#&'# to many. The modality is one occurrence of security system (mandatory) and
at least one occurrence of (mandatory). Using the ERD notation intro-
!" security system duced in Section 19.3, the connecting line between security and
!" monitoring service would be modified as shown in Figure analysis would be ap-
plied all other data objects.
Taking these “things” one at a time, connections are explored. To accomplish Each object is studied to determine its attributes. Since we are considering
this, each object is drawn and lines connecting the objects are noted. For ex- the software that must support the attributes should focus on data
ample, shows that a direct connection exists between the home- that must be stored to enable the system to operate. For example, the sensor
owner and control panel, security system, and service. A sin- object might have the following attributes: sensor type, internal identification
gle connection exists between and security system,and so forth. number, zone location, and alarm level.
Once all connections have been defined, one or more object-relationship
Pairs are for each connection. For example, the connection between
and is determined to have the following object-
relationship pairs: 12.6.2 Creating Data Flow Model
The data flow diagram enables the software engineer to develop models
of the information domain and functional domain at the same time. As the DFD
is refined into greater levels of detail, the analyst performs an implicit func-
tional decomposition of the system, thereby accomplishing the fourth opera-
tional analysis principle. At the same time, the DFD refinement results in a
I corresponding refinement of data as it moves through the processes that em-
body the application.
A few simple guidelines can aid immeasurably during derivation of a data
flow diagram: The level 0 data flow diagram should depict the software/
system as a single bubble; primary input and output should be carefully
noted; refinement should begin by isolating candidate processes, data ob-
control panel sensor jects, and stores to be represented at the next level; all arrows and bubbles
should be labeled with meaningful names; information continuity must
monitors
system tests
FIGURE12.23.
Developing
FIGURE 1222. ships and
tions
324 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 12: ANALYSIS MODELING 325
be maintained from level to level; and one bubble at a time should be All interaction with is managed by a user-interaction subsystem
There is a natural tendency to overcomplicate the data flow diagram. that through the keypad and function keys, displays
This occurs when the analyst attempts to show too much detail too early or rep- prompting messages and system status on the LCD display. Keyboard interac-
resents procedural aspects of the software in lieu of information flow. tion takes the following form . . .
Again considering the product, a level 0 DFD for the system is
shown in Figure 12.24. The primary external entities (boxes) produce informa- In examining the grammatical parse, we see a pattern begin to emerge. All
tion for use by system and consume information generated by the system. verbs are processes-; that is, they may ultimately be represented as
The labeled arrows represent data objects or data object type hierarchies. For bubbles in a subsequent DFD. All nouns are either external entities (boxes),
end commands, data or control objects (arrows), or data stores (double lines). Note further that
all activation/deactivation commands, all miscellaneous interactions, and all nouns and verbs can be attached to one another (e.g., sensor is assigned num-
data that are input to qualify or expand a command. ber and Therefore, by performing a grammatical parse on the
The level 0 DFD is now expanded into a level 1 model. But how do we pro- for a bubble at any DFD level, we can generate much useful infor-
ceed? A simple, yet effective approach is to perform a “grammatical parse” on mation about how to proceed with the refinement to the next level. Using this
the processing narrative that describes the context level bubble. That is, we iso- information, a level 1 DFD is shown in Figure 12.25. The context-level process
late all nouns (and noun phrases) and verbs (and verb phrases) in the narra- shown in Figure 12.24 has been expanded into seven processes derived from an
tive. To illustrate, we again reproduce the processing narrative underlining the examination of the grammatical parse. Similarly, the information flow between
first occurrence of all nouns and italicizing the occurrence of all verbs. (It processes at level 1 has derived from the parse.
should be noted that nouns and verbs that are synonyms or have no direct It should be noted that information continuity is maintained between
bearing on the modeling process are omitted.) levels 0 and 1. Elaboration of the content of inputs and output at DFD levels
0 and 1 is postponed until Section 12.7.
software homeowner to configure the security system The processes represented at DFD level 1 can be further refined into lower
when it i s i n s t a l l e d , all sensors to the security system, and levels. For example, the process monitor sensors can be refined into a level 2
interacts with homeowner through and function keys DFD as shown in Figure 12.26. Note once again that information flow conti-
in the control panel shown in Figure 11.4. nuity has been maintained between levels.
During installation, the control panel is used to “program” and The refinement of continues until each bubble performs a simple
the system. Each sensor is assigned a number and a master that is, until the process represented by the bubble performs a function that
password in programmed for arming and disarming the system, and telephone would be easily implemented as a program component. In Chapter 13 we discuss
number(s) are input for dialing when a sensor event occurs. a concept, called cohesion, that can used to assess the of a given
When a sensor event is recognized, the software an audible alarm function. For now, we strive to refine until each bubble is “single minded.”
attached to the system. After a delay time that is specified by the homeowner
during
of a monitoring service, information about the location, and
the nature of the event that has been detected. The telephone number will be 12.6.3 Creating Control Flow Model
every 20 seconds until connection is
For many types of data processing applications, the data model and the data
flow diagram are all that is necessary to obtain meaningful insight into soft-
control ware requirements. As we have already noted, however, there exists a large
control class of applications that are driven by events rather than data, that produce
panel control information rather than reports or displays, and that process informa-
tion with heavy concern for time and performance. Such applications require
the use of control flow modeling in addition to data flow modeling.
The graphical notation required to create a control flow diagram was
presented in Section 12.4.4. To review the approach for creating a CFD, a data
flow model is “stripped” of all data flow Events and control items
(dashed arrows) are then added to the diagram and a “window” vertical
into the control specification is shown. But how are events selected?
FIGURE 12.24. sensors
Context-level DFD for instructional clarity, the data flow have been shaded lightly and remain in the
picture. In practice, they are eliminated altogether.
CHAPTER ANALYSIS MODELING 327
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
user commands
alarm
configuration information/
read
sensors
FIGURE12.26.
Level 2 DFD that
the monitor sen- status
sors process
. Recalling the noun-verb parse that was applied to the processing narrative,
review all “control items” as possible CSPEC inputs/outputs.
FIGURE 12.25. Level 1 DFD for Describe the behavior of system by identifying its states; identify how each
is roached and define transitions between states.
Focus on possible omissions-a very common error in specifying control (e.g.,
ask: “Is there any other way I can get to this state or exit from it?“)
We have already noted that an event or control item is implemented as a
boolean value or false, on or 1 or or a discrete list of conditions A level 1 CFD for software is illustrated in Figure 12.27. Among
(empty, jammed, To select potential candidate events, the following guide- the events and control items noted are sensor event(i.e., a sensor has been
lines are suggested: tripped), blink flag signal to blink the LCD display), and switch
signal to turn the system on or off An event flowing into the CSPEC win-
!" List all sensors that are “read” by the software. dow from the outside world implies that the CSPEC will activate one or more
!" List all interrupt conditions. of the processes shown in the CFD. When a control item emanates from a
process and flows into the CSPEC window, control and activation of some other
!" List all “switches” that are actuated by an operator.
process or an outside entity is implied.
!" List all data conditions.
328 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 12: ANALYSIS MODELING 329
important, can ascertain whether there’ are “holes” in the specified behavior.
control For example, the STD (Figure 12.28) indicates that the only transition from the
panel reading input state when the is encountered
and a transition to the monitoring system state occurs. Yet, there appears
configure to be no way, other than the occurrence of sensor event, that will allow the
system to return to reading user input. This is an error in specification and
would hopefully be uncovered during review and corrected. Examine the STD
to determine whether there are any other anomalies.
A somewhat different mode of behavioral representation is the process
table (PAT). The PAT represents information contained in the STD in
the context of processes, not states. That is, the table indicates which processes
(bubbles) in the flow model will be invoked when an event occurs. The PAT can
be used as a guide for a designer who must build an executive that controls the
processes represented at this level. A PAT for the level 1 flow model of
software is shown in Figure 12.29.
deactivate The CSPEC describes the behavior of the system, but it does not give us
any information about the inner working of the processes that are activated as
system ,
a result of this behavior. The modeling notation that provides this information
is discussed in the next section.
start/stop switch
invoke monitor &
control system
status I
time out
invoke
interact with user
. , control system , ,
FIGURE 12.27. Level 1 CFD for monitoring acting on a
system
12.6.4 The Control Specification status sensor event sensor event
invoke display
The control specification (CSPEC) represents the behavior of the system (at the
level from which it has been referenced) in two different ways.The CSPEC con-
tains a state transition diagram that is a sequential specification of be-
havior. It can also contain a process activation table
specification of behavior. The underlying attributes of the CSPEC were intro-
duced in Section 12.4.4. It is now time to consider an example of this impor-
tant modeling notation for structured analysis.
Figure 12.28 depicts a slate-transition diagram for the level 1 flow model display actions status
for The labeled transition arrows indicate how the system responds FIGURE12.28.
to events as it traverses the four states defined at this level. By studying the State-transition invoke display
STD, a software engineer can determine the behavior of the system and, more gram for messages and status
330 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 12: ANALYSIS MODELING 331
input events side
sensor event 0 0 0 0 1 0
blink flag 0 0 1 1 0 0
start stop switch 0 1 0 0 0 0
display action status
complete 0 0 0 1 0 0
in-progress 0 0 1 0 0 0
time out 0 0 0 0 0 1
output
PSPEC: Processing Narrative for Analyze Triangle
alarm signal 0 0 0 0 1 0
The analyze-trinngle process accepts A, B, and C that
process activation represent the side dimensions of a triangle. The process
monitor and control system 0 1 0 0 1 1 tests the dimension values to determine whether all values
activate/deactivate system 0 1 0 0 0 0
are positive. If a negative value is encountered, an error
display messages and status 1 0 1 1 1 1
FIGURE12.29. message is produced. The process evaluates valid input data
interact with user 1 0 0 1 0 1
Process 12.30. to determine whether the dimensions define a valid triangle
table for Process specification and if so, what type of triangle-equilateral, or
for DFD process scalene-is implied by the dimensions. The type is output.
12.6.5 The Process Specification
The process specification (PSPEC) is used to describe all flow model processes Therefore, it is necessary to provide an organized approach for representing the
that appear at the final level of refinement. The content of the process characteristics of each data object and control item. This is accomplished with
cation can include narrative text, a program design language descrip- the data dictionary.
tion” of the process algorithm, mathematical equations, tables, diagrams, or The data dictionary has been proposed as a quasi-formal grammar for de-
charts. By providing a PSPEC to accompany each bubble in the flow model, the scribing the content of objects defined during structured analysis. This impor-
software engineer creates a “mini-spec” that can serve as a first step in the cre- tant modeling notation has been defined in the following manner
ation of the software requirements specification and as a guide for design of
the program component that will implement the process.
The data dictionary is an organized listing of all data elements that are perti-
To illustrate the use of the PSPEC, consider a software application in which
nent to the system, with precise, rigorous definitions so that user and sys-
the dimensions of various geometric objects are analyzed to identify the shape
tem analyst will have a common understanding of inputs, outputs, components
of the object. Refinement of a context level data flow diagram continues until
of stores and intermediate calculations.
level 2 processes are derived. One of these, named analyze triangle, is depicted
in Figure 12.30. The PSPEC for analyze triangle is first written as an
language narrative as shown in the figure. If additional algorithmic detail is Today, the data dictionary is almost always implemented as part of a CASE
desired at this stage, a program design language representation (Figure 12.31) “structured analysis and design tool.” Although the format of dictionaries varies
may also be included as part of the PSPEC. However, many believe that the from to tool, most contain the following information:
PDL version should be postponed until design commences.
!" name-the primary name of the data or control item, the data store, or an ex-
ternal entity
12.7 THE DATA DICTIONARY . alms-other names used for the first entry
!" where-used/how-used-a listing of the processes that use the data or control
The analysis model encompasses representations of data objects, function, and item and how it is used (e.g., input to the process, output from the process,
control. In each representation data objects and/or control items play a role. as a store, as an external entity)
!" content description-a notation for representing content
“Program is used as procedural design is described in !" supplementary information-otherinformation about data types, preset val-
detail in Chapter 14. ues (if known), restrictions or limitations, etc.
332 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 12: ANALYSIS MODELING 333
side dimensi error message The notation used to develop a content description, illustrated in Figure
12.32, enables the analyst to represent composite a data object) in one
of the three fundamental ways that it can be constructed:
1. as a sequence of data items,
triangle type
2. as a selection from among a set of data items, or
3. as a repeated grouping of data items.
Each data item entry that is represented as part of a sequence, selection, or
repetition may itself be another data object that needs further refinement
PSPEC: Structured English for Analyze Triangle within the dictionary
To illustrate the use of the data dictionary and the content description no-
procedure analyze-triangle; tation shown in Figure 12.32, we return to the level 2 DFD for the monitor sys-
read side dimensions; tem process for shown in Figure 12.26. In the figure, the data item
if any dimension is negative then produce error message; telephone number is specified as input. But what exactly is a telephone num-
if the largest dimension is less than the sum of the others ber? It could be a 7 digit local number, a 4 digit extension, or a 25 digit long
distance carrier sequence. The data dictionary provides us with a precise defi-
then begin
nition of telephone number for the DFD in question. In addition it indicates
determine number of equal sides; where and how this data item is used and any supplementary information that
if three sides are equal then type is equilateral; is relevant to it. The data dictionary entry begins as follows:
if two sides are equal then type is
if no sides are equal then type is scalene; name: telephone number
output triangle type;
aliases: none
FIGURE12.31. end;
else output type = 0, indication that no triangle exists; where used: assess against setup (output)
Process specification
using PDL for o DFD d i a l p h o n e (input)
endproc
telephone number = [local extension outside number]
Once a data object or control item name and its aliases are entered into The above content description may be read: telephone numberis composed
the data dictionary, consistency in naming can be enforced. That is, if an analy- of either a local extension(for use in a large company) or an outside num-
sis team member decides to name a newly derived data item but is ber. Local extensionand outside number represent composite data and
already in the dictionary, the CASE tool supporting the dictionary posts a must be refined further in other content description statements. Continuing the
warning to indicate duplicate names. This improves the consistency of the content description:
analysis model and helps to reduce errors.
“Where-used/how-used” information is recorded automatically from the
flow models. When a dictionary entry is created, the CASE tool scans and
to determine which processes use the data or control information and Data construct
how it is used. Although this may appear unimportant, it is actually one of the
most important benefits of the dictionary. During analysis there is an almost bt
continuous stream of changes. For large projects, it is often quite to de-
termine the impact of a change. Many a software engineer has asked, “Where
is this data object used? What else will have to change if we modify it? What
will the overall impact of the change b e Because the data dictionary can be
treated as a the analyst can ask “where-used/how-used” questions,
and get answers to queries noted above.
FIGURE12.32.
Content description
notation for o data
!" (
reality the data dictionary be one element of CASE repository. This " "
in dictionary
334 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER ANALYSIS MODELING 335
telephone number = [local extension outside number] conducted by J.D. Warnier Warnier developed a notation for
local extension = . . . representing information hierarchy using the three constructs for sequence,
outside number 9 + [local number long distance number1 and and that the software structure could be
derived directly from the data structure.
local number prefix access number Ken Orr extended Warnier’s work to encompass a some-
long distance number = + area code local number what broader view of the information domain that has evolved into Data
prefix = Structured Systems Development. DSSD considers information flow and func-
access number = a n y f o u r n u m b e r s t r i n g * tional characteristics as well as data hierarchy.
The content description is expanded until all composite data items (data ob-
jects) have been represented as elementary items (items that require no fur- 12.8.2 Jackson System Development
ther expansion) or until all data objects are represented in terms that would be
well known and unambiguous to all readers (e.g., area code is generally un-
derstood to mean a 3 digit number that never starts with 0 or 1). It is also im- Jackson System Development evolved out of work conducted by M.A.
Jackson on information domain analysis and its relationship
portant to note that a specification of elementary data often restricts a system.
to program and system design. Similar in some ways to Wamier’s approach and
For example, the definition of prefix indicates that only four branch exchanges
DSSD, JSD focuses on models of the “real world” information domain. In
can be accessed locally
Jackson’s words developer begins by creating a model of the
The data dictionary defines information items unambiguously. Although we
with which the system is concerned, the which its [the
might assume that the telephone represented by tho DFD in Figure
system’s] subject
12.26 could accommodate a 25 digit long distance carrier access number, the
To conduct JSD, the analyst applies the following steps:
data dictionary content description tells us that such numbers are not part of
the data that may be used.
For large computer-based systems, the data dictionary grows rapidly in size Entity Action Step. Using an approach that is quite similar to the object-ori-
and complexity In fact, it is extremely to maintain a dictionary man- ented analysis techniques described in Chapter 20, entities (people, objects or
ually. For this reason, CASE tools should be used. organizations that a system needs to produce or use information) and actions
(the events that occur in the real world that affect entities) are identified.
Entity Structure Step. Actions that affect each entity are ordered by time and
represented with Jackson Diagrams tree-like notation).
12.8 AN OVERVIEW OF OTHER CLASSICAL ANALYSIS METHODS Modeling Step. Entities and actions are represented as a process model;
connections between the model and the real world are defined.
Over the years, many other worthwhile software requirements analysis meth- Function Step. Functions that correspond to defined actions are specified.
ods have been used throughout the industry. While all follow the operational
System Timing Step. Process scheduling characteristics are assessed and spec-
analysis principles discussed in Chapter 11, each introduces a different nota- ified.
tion and heuristics for constructing the analysis model. In this section, we pre-
sent a very brief overview of three of the more common methods. For further Implementation Step. Hardware and software are specified as a design.
information, the interested reader should refer to the references
The last three steps in JSD are closely aligned with system or software design.
Data Structured Systems Development
12.8.3
Data Structured Systems Development also called the
methodology, evolved from pioneering work on information domain analysis Structured analysis and design technique is a technique that has
been widely used as a notation for system definition, process representations,
software requirements analysis and system/software design
formal methods approach for the specification of requirements is considered in
detail in Chapter 24. a trademark of Inc.
336 PART THREE: CONVENTIONAL METHODS FOR ENGINEERING CHAPTER ANALYSIS MODELING 337
SADT consists of procedures that allow the analyst to decompose software (or Orr, Structured Requirements Definition, Ken Orr Associates,
system) functions; a graphical notation, the SADT and Inc., Topeka, KS, 1981.
that communicates the relationships of information (data and control) and Page-Jones, M., The Practical Guide to Structured Systems Design,
function within software, and project control guidelines for applying the method- Press, 1980.
ology.
Ross, D., and K. Schoman, “Structured Analysis for Requirements
The SADT methodology encompasses automated to support analysis Definition,” IEEE Trans. Software Engineering, vol. 3, no. 1, January
procedures and a well-defined organizational harness through which the tools
1977, pp.
are applied. Reviews and milestones are specified, allowing validation of de-
veloper-customer communication+ Ross, D. “Applications and Extensions of SADT,” IEEE Computer. vol. 18,
no. 4. April 1984, pp. 25-35.
und
12.9 SUMMARY IBM Systems Journal, vol. 13, no. 2, 1974, pp. 115-139.
Tillmann, G., A Practical Guide to Logical Data Modeling, McGraw-Hill,
Structured analysis, the most widely used of requirements modeling methods, 1993.
relies on data modeling and flow modeling to create the basis for a Warnier, J.D., Logical Construction Van Nostrand Reinhold,
hensive analysis model. Using entity-relationship diagrams, the software engi- 1974.
neer creates a representation of all data objects that are important for the sys- J.D., Logical Construction of Systems, Nostrand Reinhold,
tern. Data and control flow diagrams are used as a basis for representing the 1981.
transformation of data and control. At the same time, these models are used to Ward, and S.J. Structured Development for Real-Time
create a functional model of the software and to provide a mechanism for par-
Systems, three volumes, Press, 1985.
titioning function. A behavioral model is created using the state transition di-
agram, and data content is developed with a data dictionary. Process and con- E.N., and Constantine, L.L., Structured Design, Press,
trol specifications provide additional elaboration of detail. 1978.
The original notation for structured analysis was developed for conven- E.N., Modern Structured Analysis, Prentice-Hall, 1990.
tional data processing applications, but extensions now make the method ap-
plicable to real-time systems. Structured analysis is supported by an array of
CASE tools that assist in the creation of each element of the model and also
help to ensure consistency and correctness. PROBLEMS AND POINTS TO PONDER
12.1. Acquire at least three of the references discussed in Section 12.1 and write
REFERENCES a brief paper that outlines how the perception structured analysis has
An concluding in which you think
Bruyn, et al., An Extended Modeling Language the method will change in the future.
Based on the Flow Diagram,” ACM Software Engineering Notes, li.2. You have been asked to build one of the following systems:
vol. 13, no. January 1988, pp. a. a network-based course registration system for your university
Chen, The Entity-Relationship Approach to Logical Database Design, b. an order-processing system for a direct mail advertiser of computer soft-
QED Information Systems, 1977. ware products
T., Structured Analysis and System Specification, c. a simple invoicing system for a small business
Hall, i979. d. a software product that replaces a Rolodex
an automated cookbook product
Gane, and C. Sarson, Structured Systems Analysis, McDonnell Douglas, Select the system that is of interest to you and develop an entity-relation-
1982. ship diagram that describes data objects, relationships, and attributes.
Hatley, D.J., and LA. Pirbhai, Strategies for Real-Time System What is the difference between cardinality and modality?
12.3.
Specification, Dorset House, 1987.
12.4. Draw a context-level model (level 0 for one of the systems that
Jackson, M.A., Principles of Program Design, Academic Press, 1975. are listed in problem 12.2. Write a context-level processing narrative for the
Jackson, M.A., System Prentice-Hall, 1983. system.
Orr, K.T., Structured Systems Development, Press, New York, 12.5. Using the context-level DFD developed in problem 12.4, develop level 1 and
1977. level 2 data flow diagrams. Use parse” on the context-level
338 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 2
processing narrative to get yourself started. Remember to specify all infor- 12.17. Software for a video game is to be developed. Proceed as in problem 12.14.
mation flow by labeling all arrows between bubbles. Use meaningful names 12.18. Contact four or five vendors that sell CASE tools for structured analysis.
for each transform. Review their literature and write a brief paper that summarizes generic fea-
12.6. and data dictionary for you tures seem to distinguish one tool from another.
selected in problem 12.2. Try to make your as complete as possible.
12.7. Does the information flow continuity concept mean that if one flow arrow
appears as input at level 0, then one flow arrow must appear as input at FURTHER READINGS AND OTHER INFORMATION SOURCES
subsequent levels? Discuss your answer.
12.8. Using the Ward and Mellor extensions, redraw the flow model contained in There are literally dozens of books that have been published on structured
Figures 12.19 and 12.20. How will you accommodate the CSPEC that is im- analysis. Most cover the subject adequately, but only a few do a truly excellent
plied in Figure Ward and Mellor do not use this notation. job. hook remains a good introduction to the basic notation.
12.9. Using the Hatley and Pirbhai extensions, redraw the flow model Books by et al. Systems Analysis and Design,
in Figure 12.16. How will you accommodate the control process (dashed bub- Cummings, Model1 (Systems Analysis, 2nd edition, McGraw-Hill,
ble) that is implied in Figure (Hatley and Pirbhai do not use this no- Robertson and Robertson (Complete Systems Analysis, two volumes, Dorset
tation.) House, and Page-Jones (The Practical to Structured Systems Design,
2nd edition, Prentice-Hall, 1988) are worthwhile references. Yourdon’s book on
12.10 Describe an event flow in your own words.
the subject remains the most comprehensive coverage published to
12.11 Develop a complete flow model for the photocopier software discussed in date. For an engineering emphasis and [HAT871 are the books of pref-
Section 12.5. You may use either Ward and Mellor or Hatley and Pirbhai no- erence. (“A Tool for Analysis of Real-Time Specification Methods,”
tation. Be certain to develop a detailed state-transition diagram for the sys- Software Engineering Notes, July 1993) presents an excellent bibliography of
tem. analysis methods. The Internet comp.realtime often con-
12.12. Complete the processing narratives for the analysis model for tains discussions of real-time analysis and specification methods.
software shown in Figure 12.25. Describe the interaction mechanics between Many variations on structured analysis have evolved over the last decade.
the user and the system. Will your additional information change the flow Cutts (Structured Systems Analysis and Design Methodology, Van Nostrand
models for presented in this chapter? If so, how? Reinhold, 1990) and Hares for the Practitioner, Wiley, 1990)
12.13. The department of public works for a large city has decided to develop a describe SSADM, a variation on structured analysis that is widely used in the
“computerized” pothole tracking and repair system As potholes are U.K. and Europe.
reported, they are assigned an identifying number and stored by street ad- Reingruber and Gregory (Data Modeling Handbook, Wiley, 1995) and
dress, size a scale of 1 to location (middle, curb, etc.), district (de- present detailed tutorials for creating industry quality data
termined from street address), and repair priority (determined from the size models. Kim and (“Comparing Data Modeling Formalisms,”
of the pothole). Work order data are associated with each pothole and in- Communications of the ACM, June 1995) have written an excellent comparison
clude pothole location and size, repair crew identifying number, number of of data modeling methods. An interesting book by Hay (Data Modeling Patterns,
people on crew, equipment assigned, hours applied to repair, hole status Dorset House, 1995) presents typical data model “patterns” that are encoun-
(work in progress, repaired, temporary repair, not repaired), amount of filler tered in many different businesses. A detailed treatment of behavioral model-
material used, and cost of repair (computed from hours applied, number of ing can be found in (Behavior Models: Specifying User’s Expectations,
people, material and equipment used). Finally, a damage tile is created to Prentice-Hall, 1992).
bold information about reported damage due to the pothole and includes cit- A comprehensive study of CASE tools that are available for analysis mod-
izen’s name, address, phone number, type of damage, and dollar amount of eling has been prepared by Software Technology Support Center (Requirements
damage. PHTRS is an on-line system; queries are to be made interactively. Analysis and Design Technology Report, March STSC is a government
Use structured analysis to model the PHTRS. sponsored organization located at Hill Air Force Base in Utah.
12.14. Software for a word-processing system is to be developed. Do a few hours of A short bibliography on requirements analysis methods and pointers to
research on the application area and conduct a FAST meeting (see Chapter other bibliographies on function analysis and quality function deployment can
with your fellow students to develop requirements (your instructor will be found at:
help you coordinate this). Build a requirements model of the system using
structured analysis.
lo
he Proceed as in problem 12.14. Many major CASE vendors provide Web sites that contain information
12.16. Software for a manufacturing control system for an automobile assembly about tools for structured analysis. A comprehensive set of pointers can ob-
plant is to be developed. Proceed as in problem 12.14. tained at:
340 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
A on
An up-to-date list of World Wide Web references for software analysis model-
ing can be found at:
DESIGN CONCEPTS
AND PRINCIPLES
D uct or
the in development
It may be defined “the
for any prod-
various tech-
niques and principles for the purpose of defining a device, a process or a system
in detail to permit its physical realization”
The designer’s goal is to produce a model or representation of an entity that
will later be built. The process by which the model is developed combines in-
tuition and judgment based on experience in building similar entities, a set of
principles and/or heuristics that guide the way in which the model evolves, a
set of criteria that enable quality to be judged, and a process of iteration that
ultimately leads to a final design representation.
Like engineering design approaches in other disciplines, software design
changes continually as new methods, better analysis, and broader understanding
evolve. Unlike mechanical or electronic design, software design is at a relatively
early stage in its evolution. We have given serious thought to design (as
opposed to “programming” or “writing code”) for little more than decades.
Therefore, design methodology lacks the depth, flexibility, and quantita-
tive nature that is normally associated with more classical engineering design dis-
ciplines. However, methods for design do exist; criteria for design qual-
ity are available; and design notation can be applied. In this chapter, we explore
the fundamental concepts and principles that are applicable to all software de-
sign. Chapters 14 and examine a variety of software design methods.
13.1 SOFTWARE DESIGN AND ENGINEERING
Software design sits at the technical kernel of the software engineering process
and is applied regardless of the software process model that is used. Beginning
341
342 PART FOR ENGINEERING
once software requirements have been analyzed and software design implies a flow of (e.g., data control). Therefore, the
is the of three technical code and data and control flow diagrams provide the information required for interface
that are required to build and verify the software. Each activity transforms in- design.
formation in a manner that ultimately results in validated computer software. The transforms structural elements of the program ar-
Each of the elements of analysis provides informa- chitecture into a description of software components. Information
tion that is required to create a design model. The flow of information during obtained from the CSPEC, and STD serve as the basis for procedural
software design is illustrated in Figure 13.1. Software requirements, mani- design.
fested by the data, functional, and behavioral models, feed the design step. During design we make decisions that will ultimately affect the success of
Using one of a number of design methods (discussed in later chapters), the de- software construction, and as important, the ease with which software can be
sign step produces a data design, an architectural design, an interface design, maintained. why is design important?
and a procedural design. The importance of software design can be with a single
The domain created during Design is the place where quality is fostered in software development.
analysis into the data structures that will be required to implement the soft- Design provides us with representations of software that can be assessed for
ware. The data objects and relationships defined in the entity-relationship di- quality. Design is the only way that we can accurately translate a customer’s
agram and the detailed data content depicted in the data dictionary provide requirements into a finished software product or system. Software design
the basis for the data design activity. serves as the foundation for software engineering and software maintenance
The architectural design defines the relationship among major structural steps that follow. Without design, we risk building an unstable system-one
elements of the program. This design representation-the modular framework that will fail when small changes are made; one that may be difficult to test;
of a computer program-can be derived from the analysis and the in- one whose quality cannot be assessed until late in the software engineering
teraction of subsystems defined within the analysis model. process, when time is short and many dollars have already been spent.
The interface design describes how the software communicates within it-.
to systems that with it, with humans who it.
13.2 THE DESIGN PROCESS
Software design is an iterative process through which requirements are trans-
lated into a “blueprint” for constructing the software. Initially, the blueprint de-
picts a holistic view of software. That is, the design is represented at a high
level of abstraction-a that can be directly traced to specific data, func-
tional, and behavioral requirements. As design iterations occur, subsequent
to design at much lower of abstraction.
These can still to requirements, but the connection is more
Design and Quality
Throughout the design process, the quality of the evolving design is assessed
with a series of formal technical or discussed in
Chapter 8. suggests three characteristics that serve as a
guide for the evaluation of a good design:
!" The design must implement all of the explicit requirements contained in the
analysis model, and it must accommodate all of the implicit requirements de-
sired by the customer.
!" The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently maintain the software.
The analysis model The design model !" should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspec-
FIGURE 13.1. Translating the analysis model into software design tive.
344 PART CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN CONCEPTS AND PRINCIPLES
Each of these characteristics is actually a goal of the design process. But how Regardless of the design method that is used, a software engineer should
is each of these goals achieved? apply a set of fundamental principles and basic concepts to data, architectural,
In order to evaluate the quality of a design representation, we must es- interface, and procedural design. These principles and concepts are considered
tablish technical criteria for good design. Later in this chapter, we discuss de- in the sections that follow.
sign quality criteria in some detail. For the time being, we present the follow-
ing guidelines:
DESIGN PRINCIPLES
1. A design should exhibit a hierarchical organization that makes intelligent
use of control among elements of software.’
Software design is both a process and a model. The design process is a set of
2. A design should be modular; that is, the software should be logically parti- iterative steps that enable the designer to describe all aspects of the software
tioned into elements that perform specific functions and subfunctions. to be built. It is important to note, however, that the design process is not sim-
3. A design should contain both data and procedural abstractions. ply a cookbook. Creative skill, past experience, a sense of what makes “good”
4. A design should lead to modules (e.g., subroutines or procedures) that ex- software, and an overall commitment to quality are critical success factors for
hibit independent functional characteristics. a competent design.
The design model is the equivalent of an architect’s plans for a house. It
5. A design should lead to interfaces that reduce the complexity of connections begins by representing the totality of the thing to be built (e.g., a
between modules and with the external environment. dimensional rendering of the house) and slowly relines the thing to provide
A should using is in- the
formation obtained during software requirements analysis. design model that is created for software provides a variety of different views
of lhc computer program.
These criteria are not achieved by chance. The software design process en- Basic design principles enable the software engineer to navigate the design
courages good design through the application of fundamental design principles, process. Davis suggests a of principles for software design, which
systematic methodology, and thorough review. have been adapted and extended in the following list:
!" The design process should not suffer from “tunnel vision.” A good designer
should consider alternative approaches, judging each based on the require-
13.2.2 The Evolution of Software Design ments of the problem, the resources available to do the job, and the design
concepts presented in Section 13.4.
The evolution of software design is a continuing process that has spanned the !" should be traceable to the analysis model. Because a single ele-
past three decades. Early work concentrated on criteria for the develop ment of the design model often traces to multiple requirements, it is neces-
ment of modular programs and methods for relining software architec- sary to have a means for tracking how requirements have been satisfied by
ture in a top-down manner Procedural aspects of design definition the design model.
evolved into a philosophy called structured programming MIL721. Later !" The design should not reinvent the wheel. Systems are constructed using a
work proposed methods for the translation of data flow or data struc-
of patterns, many of which have likely been encountered before.
ture WAR741 into a design definition. Newer design approaches (e.g.,
These patterns, often called reusable design should always be
propose an object-oriented approach to design derivation.
chosen as an alternative to reinvention. Time is short and resources are lim-
Many design methods, growing out of the work noted above, are being ap-
ited! Design time should be invested in representing truly new ideas and in-
plied throughout the industry. Like the methods presented in Chapter
tegrating those patterns that already exist.
12, each software design method introduces unique heuristics and notation, as
well as a somewhat parochial view of what characterizes lead to design !" The design should “minimize the distance” between the
__ ity. Yet, of these methods has a number of common characteristics: the That thr
mechanism for tho translation an analysis model into a design representa- should mimic tho structure of the
tion, (2) a notation for representing functional components and their interfaces, problem domain.
heuristics for refinement and partitioning, and guidelines for quality !" The design should exhibit uniformity and integration. A design is uniform if it
assessment. appears that one person developed the entire thing. Rules of style and format
should be noted object-oriented do not necessarily exhibit this ‘Only small subset of Davis’s design principles are noted here. For information, see
See Chapters 19 and 21 for details.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN CONCEPTS AND PRINCIPLES 347
should be defined for a design team before design work begins. A design is in- M.A. Jackson once said: “The beginning of wisdom for a [software engineer1
tegrated if care in defining interfaces between design components. is to recognize the difference between getting a program to work, and getting
it right” Fundamental software design concepts provide the necessary
!" The design should be structured to accommodate change. Many of the design
framework for “getting it right.”
concepts discussed in the next section enable a design to achieve this principle.
The design should be structured to degrade gently, even when aberrant data,
events, or operating conditions are encountered. A well-designed computer pro-
gram should never “bomb.” It should be designed to accommodate unusual cir-
cumstances, and if it must terminate processing, do so in a graceful manner. 13.4.1 Abstraction
!" Design is not coding, coding is not design. Even when detailed procedural de-
signs are created for program components, the level of abstraction of the de- When we consider a modular solution to any problem, many levels of
sign model is higher than source code. The only design decisions made at the tion can be posed. At highest level of abstraction, a solution is stated in
coding level address the small implementation details that enable the proce- broad terms using the language of the problem environment. At lower levels of
dural design to be coded. abstraction, a more procedural orientation is taken. Problem-oriented termi-
nology is coupled with implementation-oriented terminology in an effort to
!" should he for quality it is not after the a solution. Finally, of abstraction. solution is
A of concepts (Suction 13.4) and design measures (Chapters in a manner that can be directly implemented. Wasserman provides
18 and are available to assist the designer in assessing quality. a useful definition:
!" The design should be reviewed to minimize conceptual (semantic) errors.
There is sometimes a tendency to focus on minutiae when the design is re- psychological notion permits one to concentrate on a prob-
viewed, missing the forest for the trees. A designer should ensure that major lem at some level of generalization without regard to irrelevant low level de-
conceptual elements of the design (omissions, ambiguity, inconsistency) have tails; use of abstraction also permits one to work with concepts and terms that
been addressed before worrying about the syntax of the design model. , are familiar in the problem environment without having to transform them to
an unfamiliar structure
When the design principles described above are properly applied, the software
engineer creates a design that exhibits both external and internal quality fac- Each step in the software engineering process is a refinement in the level
tors quality factors are those properties of the software that of abstraction of the software solution. During system engineering, software is
can be readily observed by users (e.g., speed, reliability, correctness, allocated as an element of a computer-based system. During software require-
Internal quality factors are of importance to software engineers. They lead to a ments analysis, the software solution is stated in terms “that are familiar in
high-quality design from the technical perspective. To achieve internal quality the problem environment.” As we move through the design process, the level of
factors, the designer must understand basic design concepts. abstraction is reduced. Finally, the lowest level of abstraction is reached when
source code is generated.
As we move through different levels of abstraction, we work to create pro-
DESIGN CONCEPTS cedural and data abstractions. A procedural abstraction is a named sequence
of instructions that has a specific and limited function. An example of a proce-
A set of software design concepts has evolved over the past three dural abstraction would be the word “open” on a door. “Open” implies a long se-
decades. Although the degree of interest in each concept has varied over the quence of procedural (e.g., walk to the door; reach out and grasp knob;
turn knob and pull door; step away from moving door, etc.). A data abstraction
years, each has stood the test of time. Each provides the software designer with
a foundation from which more sophisticated design methods can be applied. is a named collection of data that describes a data object.
In the context of the procedural abstraction open noted above, we can de-
Each helps the software engineer to answer the following questions:
fine a data abstraction called door. Like any data object, the data abstraction
. What criteria can be used to partition software into individual components? for door would encompass a set of attributes that describe the door (e.g., door
type, swing direction, opening mechanism, weight, dimensions). It follows that
. How is function or data structure detail separated from a conceptual repre- the procedural abstraction open would make use of information contained in
sentation of the software?
the attributes of the data abstraction door.
. Are there uniform criteria that define the technical quality of a software de- A number of programming languages (e.g., Ada, Modula, provide
sign? mechanisms for creating abstract data types. For example, the Ada package is
a programming language mechanism that provides support for both data and
procedural abstraction. The original abstract data type is used as a template
more detailed discussion of quality factors is presented in Chapter 18. or generic data structure from which other data structures can be instantiated.
348 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 13: DESIGN CONCEPTS AND PRINCIPLES 349
Control abstraction is the third form of abstraction used in software design. ularity; that is, software is divided into separately named and addressable com-
Like procedural and data abstraction, control abstraction implies a program ponents, called modules, that are integrated to satisfy problem requirements.
control mechanism without specifying internal details. An example of a control It has been stated that “modularity is the single attribute of that
abstraction is the synchronization semaphore used to coordinate ac- allows a program to be intellectually manageable” Monolithic soft-
tivities in an operating system. ware (i.e., a large program comprised of a single module) cannot be easily
grasped by a reader. The number of control paths, span of reference, number of
variables, and overall complexity would make understanding close to impossi-
ble. To illustrate this point, consider the following argument based on observa-
13.4.2 Refinement tions of human problem solving.
Let be a function that defines the perceived complexity of a problem
refinement is a top-down design strategy originally proposed by and be a function that defines the effort (in time) required to solve a prob-
Niklaus Wirth The architecture of a program is developed by succes- lem For two problems, and if
sively relining levels of procedural detail. A hierarchy is developed by decom-
posing a macroscopic statement of function procedural abstraction) in a
wise fashion until programming language statements are reached. An overview it follows that
of the concept is provided by Wirth
In each stop (of the refinement), one or several instructions of the given pro- As a general case, this result is intuitively obvious. It does take more time to
gram are decomposed into more detailed instructions. This successive decompo- solve a difficult problem.
sition or refinement of terminates when all instructions are ex- Another interesting characteristic has been uncovered through experimen-
pressed in terms of any underlying computer or programming language. . tation in human problem solving. That is,
tasks are refined, so the data may have to be refined, decomposed, or structured,
and it is natural to refine the program and the data specifications in parallel. + + (13.2)
Every refinement step implies some design decisions. It is important Equation (13.2) implies that the perceived complexity of a problem that com-
that the programmer be aware of the underlying criteria (for design deci- bines and is greater than the perceived complexity when each problem is
sions) and of the existence of alternative solutions. . considered separately. Considering equation (13.2) and the condition implied by
equations it follows that
The process of program refinement proposed by Wirth is to the + + (13.3)
process of refinement and partitioning that is used during requirements analy-
sis. The difference is in the level of implementation detail that is considered. This leads to a “divide and conquer” conclusion-it’s easier to solve a complex
not the approach. problem when you break it into manageable pieces. The result expressed in in-
Refinement is actually a process of We begin with a statement equality (13.3) has important implications with regard to modularity and
of function description of information1 that is defined a level of ab- ware. It is, in fact, an argument for modularity.
straction. That is, the statement describes function or information conceptually, It is possible to conclude from inequality (13.3) that if we subdivide soft-
but provides no information about the internal workings of the function or the ware indefinitely, the effort required to develop it will become negligibly small!
internal structure of the information. Refinement causes the designer to elab- Unfortunately, other forces come into play, causing this conclusion to be (sadly)
orate on the original statement, providing more and more detail as each suc- invalid. As Figure 13.2 shows, the effort (cost) to develop an individual software
cessive refinement (elaboration) occurs. module does decrease as the total number of modules increases. Given the same
Abstraction and refinement are complementary concepts. Abstraction en- set of requirements, more modules means smaller individual size. However,
ables a designer to specify procedure and data and yet suppress low-level de- the number of modules grows, the effort associated with integrating the
tails. Refinement helps the designer to reveal low-level details as design pro- modules also grows. These characteristics lead to a total cost or effort curve
gresses. Both concepts aid the designer in creating a complete design model as shown in the figure. There is a number, of modules that would result in min-
the design evolves. imum development cost, but we do not have the necessary sophistication to pre-
dict M with assurance.
The shown in Figure 13.2 do provide useful guidance when modu-
larity is considered. We should modularize, but care should be taken to stay in
13.4.3 Modularity the vicinity of M. Undermodularity or overmodularity should be avoided. But
how do we know “the vicinity of How modular should we make software?
The concept of modularity in computer software has been espoused for almost The answers to these questions require an understanding of other design con-
four decades. Software architecture (described in Section embodies cepts considered later in this chapter.
350 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 13: DESIGN CONCEPTS AND PRINCIPLES 351
Although the program source code may not look modular at first glance, the
, Total software cost philosophy has been maintained, and the program will provide the benefits of
a modular system.
13.4.4 Software Architecture
Software architecture alludes to “the overall structure of the software and the
ways in which that provides conceptual integrity for a system”
In its simplest form, architecture is the hierarchical structure of pro-
FIGURE 13.2. gram components (modules), the manner in which these components interact,
I
Modularity and and the structure of the data that are used by the components. In a broader
ware cost Number of modules sense, however, “components” can be generalized to represent major system el-
ements and their
One goal of software design is to derive an architectural rendering of a sys-
Another important question arises when modularity is considered. How do tem. This rendering an a which more detailed design
we define an appropriate module of a given size’? The answer lies in the activities are conducted. A set patterns enables a software en-
method(s) used to define modules within a Meyer defines gineer to reuse design-level concepts.
five criteria that enable us to evaluate a design method with respect to its abil- Shaw and describe a set of properties that should be
ity to define an effective modular system: specified as part of an design:
M o d u l a r d e c o m p o s a b i l i t y . If a design method provides a systematic Structural properties.This aspect of the architectural design repre-
mechanism for decomposing the problem into subproblems, it will reduce sentation defines the components of a system (e.g., modules, objects, filters)
the complexity of the overall problem, thereby achieving an effective mod- and the manner in which those components are packaged and interact with
ular solution. one another: For example, objects are packaged to encapsulate both data
M o d u l a r c o m p o s a b i l i t y . If a design method enables existing (reusable) and the processing that manipulates the data, and to interact via the in-
design components to be assembled into a new it will yield a mod- \ vocation of methods (Chapter 19).
ular solution that does not reinvent the wheel. Extra-functional properties. The architectural design description
M o d u l a r u n d e r s t a n d a b i l i t y . If a module can be understood as a stand- should address how the design architecture achieves requirements for per-
alone unit (without reference to other modules) it will be easier to build formance, capacity, reliability, security, adaptability, and other system char-
and easier to change. acteristics.
M o d u l a r c o n t i n u i t y . If small changes to the system requirements result Families of related systems.The architectural design should draw
in changes to individual modules, rather than system-wide changes, the upon repeatable patterns that are commonly encountered in the design of
impact of change-induced side effects will be minimized. families of similar systems. In essence, the design should have the ability
M o d u l a r p r o t e c t i o n . If an aberrant condition occurs within a module to reuse architectural building blocks.
and its effects are constrained within that module, the impact of error-in-
- side effects will be minimized. Given the specification of these properties, the architectural design can be rep-
resented using one or more of a number of different models Structural
Finally, it is important to note that a system may be designed modularly, models represent architecture as an organized collection of program compo-
even if its implementation must be are situations (e.g., real- nents. models increase the level of design abstraction by attempt-
time software, embedded software) in which relatively minimal speed and ing to identify repeatable architectural design frameworks (patterns) that are
memory overhead introduced by subprograms (i.e., subroutines, procedures) is encountered in similar types of applications. Dynamic models address the be-
unacceptable. In such situations software can and should be designed with havioral aspects of the program architecture, indicating how the structure or
modularity as an overriding philosophy. Code may be developed “in-line.” system configuration may change as a function of external events. Process
example, the architectural components of a client/server system are represented at a dif-
14 and 21 discuss methods for design ferent level of abstraction. See Chapter 28 for details.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 13: DESIGN CONCEPTS AND PRINCIPLES 353
The control relationship among modules is expressed in the following way:
A module that controls another module is said to be superordinate to it; con-
versely, a module controlled by another is said to be subordinate to the con-
troller For example, as shown in Figure 13.3, module M is
b to modules a, and c. Module h is subordinate to module and is
ultimately subordinate to module M. Width-oriented relationships (e.g., be-
tween modules d and although possible to express in practice, need not be
defined with explicit terminology.
The control hierarchy also represents two subtly different characteristics
of the software architecture: visibility and connectivity. Visibility indicates the
set of program components that may be invoked or used as data by a given com-
ponent, even when this is accomplished indirectly. For example, a module in an
object-oriented system may have access to a wide array of data attributes that
it has inherited, but only make use of a small number of these data attributes.
All of the attributes are visible to the module. Connectivity indicates the set of
components that are directly invoked or used as data by a given component.
For a module that directly causes another module to begin execution
FIGURE 13.3. is connected to
Structureterminology
focus on the design of the business or technical process that the system 13.4.6 Structural Partitioning
must accommodate. Finally, functional models can be used to represent the
functional hierarchy of a system. The program structure should be partitioned both horizontally and vertically.
A number of different architectural description languages have As shown in Figure horizontal partitioning defines separate branches of
been developed to the models noted above Although many the modular hierarchy for each major program function. Control modules, rep-
different have been proposed, the majority provide mechanisms for de- resented in a darker shade, are used to coordinate communication between and
scribing system components and the manner in which they are connected to execution of program functions. The simplest approach to horizontal partition-
one another. ing defines three partitions-input, data transformation called process-
ing), and output. Partitioning the architecture horizontally provides a number
of distinct benefits:
Control Hierarchy
!" results in software that is easier to test
Control also called structure, represents the organization !" leads to software that is easier to maintain
of program (modules) and implies a !" propagation of fewer side effects
of control. It does not represent procedural aspects such as sequence
!" results in software that is easier to extend
of processes, occurrence/order of decisions, or repetition of operations.
Many different notations are used to represent control hierarchy. The most
Because major functions are decoupled from one another, change tends to be
common is the tree-like diagram (Figure 13.3) that represents the hierarchy.
less complex and extensions to the system common occurrence) tend to
However, other notations, such as and Jackson
diagrams may also be used with equal In to facilitate later easier to accomplish without side effects. On the negative side, horizontal par-
titioning often causes more data to be passed across module interfaces and can
discussions of structure, we define a few simple measures and terms. In Figure
13.3, depth and width provide an indication of the number of levels of control complicate the overall control of program flow (if processing requires rapid
movement from one function to another).
and overall span of control, respectively. Fun-out is a measure of the number of
modules that are directly controlled by another Fart-in indicates how
many modules directly control a given module. I ’
‘In Chapter 19, we explore the concept of inheritance for object-oriented software. A program
component can inherit control logic data another component without explicit
in the code. Components of sort would he visible. but not directly connected.
of in Figure 13.3 indicates connectivity, for modules.
DESIGN CONCEPTS AND
CONVENTIONAL FOR SOFTWARE ENGINEERING 355
354
Function final procedural design, data structure is as important as program structure to
Function the representation of software architecture.
Data structure dictates the organization, methods of access, degree of
sociativity, and processing alternatives for information. Entire texts (e.g.,
to topics, and a
discussion is beyond the of this book. it is important to
classic available for organizing information and the
concepts that underlie information hierarchies.
The organization and complexity of a structure are only by the
limited number of classic data
blocks structures.
Function 2 A simplest all data structures. As its name implies, a
(a) Horizontal partitioning scalar represents a single element of that may be addressed
by an that is, access may be achieved by specifying a single address
in storage.
When scalar items are organized as a list or contiguous group, a sequential
. is formed. Vectors are the most common of all data structures and open
the door to variable indexing of information.
When the sequential vector is extended to two, three, and ultimately, an ar-
bitrary number of dimensions, an n-dimensional space is created. The most
common n-dimensional space is the two-dimensional matrix. In most program-
ming languages, an n-dimensional space is called an array.
Items, vectors, and spaces may be organized in a variety of formats. A
is a data structure that organizes noncontiguous scalar items, vec-
tors, or spaces in a manner (called nodes) that enables them to be processed
13.4. a list. Each node contains appropriate data organization
Vertical partitioning or more
the list by redefining pointers to
accommodate the new list entry.
(Figure often called factoring, suggests that Other data structures incorporate or are constructed using the fundamen-
ion and work should be distributed top-down the tal data structures described above. For example, a hierarchical
control
Top-level modules should control functions and do is implemented using multilinked lists that contain scalar items, vectors, and
work. Modules that reside low in the architecture should possibly n-dimensional spaces. A hierarchical structure is commonly encoun-
little
performing all input, computational, and output tasks. tered in applications that require information categorization and associativity.
be the
of change in program architectures justifies the need for Categorization implies grouping of information by some generic category
A in a control module (high in the architecture) will (e.g., all subcompact automobiles or all microprocessors).
side effects to modules that are sub- Associativity implies the ability to associate information from different cat-
egories; for example, find all entries in the that cost,
ordinate to it. A change to a worker module, given
$100.00 (cost run 100 time subcategory),
is less likely to cause the propagation of side effects. In general, changes
by U.S. vendors (vendor subcategory).
around or
control structure the ba- It is important note that data structures, like program structures, can
sic behavior) is far less likely to change. For this reason be represented at different levels of abstraction. For example, a stack is a con-
ceptual model of a data structure that can be implemented as a vector or a
architectures are less likely to be susceptible to side effects when changes are
made and will therefore be more maintainable-a key quality factor. linked list. Depending on the level of design detail, the internal workings of
stack may or may not be specified.
13.4.8 Software Procedure
13.4.7 Data Structure
structure control
a representation of the logical among individual
structure of will invariably procedure focuses on the processing details
356 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 13: DESIGN CONCEPTS AND PRINCIPLES 357
Hiding implies that effective modularity can be achieved by defining a
set of independent modules that communicate with one another only that in-
formation that is necessary to achieve software function. Abstraction helps
to define the procedural informational) entities that comprise the soft-
ware. Hiding defines and enforces access constraints to both procedural
for detail within a module and any local datu structure used by the module
module
The USC of information hiding RR a for modular
provides its greatest benefits when modifications are required during test-
ing and later, during software maintenance. Because most data and proce-
dure are hidden from other parts of the software, inadvertent errors intro-
duced during modification are less likely to propagate to other locations
within the software.
Procedure for
subordinate module
13.5 EFFECTIVE MODULAR DESIGN
The fundamental design concepts described in the preceding section all serve
to precipitate modular designs. In fact, modularity has become an accepted ap-
proach in all engineering disciplines. A modular design reduces complexity (see
Section facilitates change critical aspect of software maintainability),
and results in easier implementation by encouraging parallel development of
different parts of a system.
Procedure for
subordinate module
13.5. Functional Independence
Procedure is layered
The concept of functional independence is a direct outgrowth of modularity and
the concepts of abstraction and information hiding. In landmark papers on soft-
of each module individually. Procedure must provide a precise specification of ware design Parnas [PAR721 and Wirth allude to refinement tech-
processing: including sequence of events, exact decision points, repetitive oper- niques that enhance module independence. Later work by Stevens, Myers, and
ations, and even data organization/structure. Constantine solidified the concept.
There is, of course, a relationship between structure and procedure. Functional independence is achieved by developing modules with
Processing indicated for each module must include a reference to ail modules minded” function and an “aversion” to excessive interaction with other mod-
subordinate to the module being described. That is, a procedural representa- ules. Stated another way, we want to design software so that each module ad-
tion of software is layered as illustrated in Figure 13.5. dresses a specific subfunction of requirements and has a simple interface
when viewed from other parts of the program structure. It is fair to ask why
independence is important. Software with effective modularity (i.e., indepen-
dent modules), is easier to develop because function may be compartmental-
13.4.9 Hiding ized and interfaces are simplified (consider ramifications when development
is conducted by a team). Independent modules are easier to maintain (and
The concept of modularity leads every software designer to a fundamental test) because secondary effects caused by design/code modification are limited,
3
question: “How do we decompose a software solution to obtain the best set of error propagation is reduced, and reusable modules are possible. To summa-
modules?” The principle of information hiding suggests that modules rize, functional independence is a key to good design, and design is the key to
be “characterized by design decisions that (each) hides from all others.” In other software quality.
words, modules should be specified and designed so that information (proce- Independence is measured using two qualitative criteria: cohesion and cou-
dure and data) contained within a module is inaccessible to other modules that pling. Cohesion is a measure of the relative functional strength of a module.
have no need for such information. Coupling is a measure of the relative interdependence among modules.
PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 13 DESIGN CONCEPTS AND PRINCIPLES 359
Cohesion low-up calculations requested by the user; updates a data base; and en-
ables menu selection for subsequent processing. Although the preceding tasks
are loosely related, each is an independent functional entity that might best be
Cohesion is a natural extension of the information hiding concept described in performed as a separate module. Combining the functions into a single module
Section 13.4.9. A cohesive module performs a single task within a software pro- can only serve to increase the likelihood of error propagation when a modifi-
cedure, requiring little interaction with procedures being performed in other cation is made to any one of the processing tasks noted above.
parts of a program. Stated simply, an cohesive module should (ideally) do just Moderate levels of cohesion are relatively close to one another in the de-
one thing. gree of module independence. When processing elements of a module are re-
Cohesion may be represented as a “spectrum” shown in Figure 13.6. We al- lated and must be executed in a specific cohesion exists. When
ways strive for high cohesion, although the mid-range of the spectrum is often all processing concentrate on one area of a data structure, communi-
acceptable. The scale for cohesion is nonlinear. That is, low-end cohesiveness is cational cohesionis present. High cohesion is characterized by a module that
much “worse” than the middle range, which is nearly as “good” as high-end co- performs one distinct procedural task.
hesion. In practice, a designer need not be concerned with categorizing cohe- As we have already noted, it is unnecessary to determine the precise level
sion in a specific module. Rather, the overall concept should be understood and of cohesion. Rather it is important to for high cohesion and recognize low
low levels of cohesion should be avoided when modules are designed. cohesion so that software design can be modified to achieve greater functional
To illustrate (somewhat facetiously) the low end of the spectrum, we relate independence.
the following story:
In the late 1960s most DP managers began to recognize the worth of mod-
ularity. Unfortunately many existing programs were 20,000 13.5.4 Coupling
lines of undocumented with one 2500 line subroutine! To bring a large
computer program to the state of the art, a manager asked her staff to modu- Coupling is a measure of interconnection among modules in a program struc-
larize the program. This was to be done “in your spare time.” ture. Like cohesion, coupling may be represented on a spectrum as shown in
Under the gun, one staff member asked (innocently) the proper length for Figure 13.7. Coupling depends on the interface complexity between modules,
a module. “Seventy-five lines of code,” the reply. He then obtained a red the point at which entry or reference is made to a module, and what data pass
pen and a ruler, measured the linear distance taken by 75 lines of source code, across the interface.
and drew a red line on the source listing, then another and another. Each red In software design, we strive for lowest possible coupling. Simple connec-
line indicated a module boundary. This technique is akin to developing software tivity among modules results in software that is easier to understand and less
with coincidental cohesion! prone to a “ripple effect” caused when errors occur at one location and
propagate through a system.
A module that performs a set of tasks that relate to each other loosely, if Figure 13.8 provides examples of different types of module coupling.
at all, is termed A module that performs tasks that are Modules a and d are subordinate to different modules. Each is unrelated and
related logically (e.g., a module that produces all output regardless of type) is therefore no direct coupling occurs. Module c is subordinate to module a and is
logically cohesive.When a module contains tasks that are related by the fact accessed via a conventional argument list through which data
that all be within the span of the exhibits as argument data passed; a one-
temporal cohesion. to-one correspondence of items exists), low coupling (data coupling on the
As an example of low cohesion, consider a module that performs error pro- is exhibited in this portion of structure. A variation of data coupling,
cessing for an engineering analysis package. The module is called when com- called stamp coupling, is found when a portion of a data structure (rather than
puted data exceed bounds. It performs the following tasks: com- simple arguments1 is passed via a module interface. This occurs between mod-
putes supplementary data based on original computed data; (2) produces an ules b and a.
error report (with graphical content) on the user’s workstation; performs At moderate levels coupling is characterized by passage of control between
modules. Control coupling isvery common in most software designs and is
A measure relative functional strength
A measure of the interdependence among modules
Functional
No direct coupling Stamp coupling Content coupling
Logical
Data coupling
FIGURE 13.6.
Cohesion ‘Scatter-brained ‘Single-minded”
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 13: DESIGN CONCEPTS AND PRINCIPLES 361
The coupling modes discussed above occur because of design decisions
made when the program structure was developed. Variants of external cou-
pling, however, may be introduced during coding. For example, compiler cou-
pling ties source code to specific (and often nonstandard) attributes of a
piler; operating system coupling ties design and resultant code operating
i system “hooks” that can create havoc when OS changes occur.
13.6 DESIGN HEURISTICS FOR EFFECTIVE MODULARITY
Once a program structure has been developed, effective modularity can be
achieved by applying the design concepts introduced earlier in this chapter. The
program architecture is manipulated according to a set of heuristics (guide-
lines) presented in this section.
I. Evaluate the “first iteration” of the program structure to reduce
c o u p l i n g a n d i m p r o v e c o h e s i o n . Once program structure has been de-
veloped, modules may be exploded or imploded with an eye toward im-
proving module independence. An exploded module becomes two or
modules in the final program structure. An imploded module is the result
of combining the processing implied by two or more modules.
An exploded module results when a common process component ex-
FIGURE 13.8. Types of coupling ists in two or more modules and can be redefined as a separate cohesive mod-
ule. When high coupling is expected, modules can sometimes be imploded to
reduce passage of control, reference to global data and interface complexity.
II. Attempt to minimize structures with high fan-out; strive for
shown in Figure 13.8, where a “control flag” (a variable that controls decisions i n a s d e p t h i n c r e a s e s . The structure shown inside the cloud in Figure
in a subordinate or superordinate module) is passed between modules d and e. 13.9 does not make effective use of factoring. All modules are ‘pancaked”
Relatively high levels of coupling occur when modules are tied to an envi- below a single control module. In general, a more reasonable distribution
ronment external software. For example, couples a module to specific de- of control is shown in the upper structure. The structure takes an oval
vices, formats, and communication protocols. External coupling is essential, but shape, indicating a number of layers of control and highly utilitarian mod-
should be limited to a small number of modules with a structure. High coupling ules at lower levels.
also occurs when a number of modules reference a global data area. Common III. Keep scope of effect of a module within the scope of control of
coupling, as this mode is called, is shown in Figure 13.8. Modules and k
t h a t m o d u l e . The scope of a module e is defined as all other mod-
each a data item in a global data area (e.g., a disk file, COM-
ules that are affected by a decision made in module e. The scope of control
MON, external data types in the C programming language). Module c initial-
of module is all modules that are subordinate and ultimately subordinate
izes the item. Later module g recomputes and updates the item. Let’s assume
to module e. As shown in Figure 13.9, if module e makes a decision that af-
that an error occurs and g updates the item incorrectly. Much later in process- fects module we have a violation of heuristic III, because module lies
ing, module reads the item, attempts to process it, and fails, causing the soft-
outside the scope of control of module e.
ware to abort. The apparent cause of abort is module k; the actual cause, mod-
ule g. Diagnosing problems in structures with considerable common coupling is Evaluate module interfaces to reduce complexity and redun-
time-consuming and difficult. However, this does not mean that the use of dancy and improve consistency. Module interface complexity is a
global data is necessarily “bad.” It does mean that a software designer must be prime cause of software errors. Interfaces should be designed to pass in-
aware of potential consequences of common coupling and take special care to formation simply and should be consistent with the function of a module.
guard against them. Interface inconsistency seemingly unrelated data passed via an argu-
The highest degree of coupling, content coupling, occurs when module ment list or other technique) is an indication of low cohesion. The module
makes use of data or control information maintained within the boundary of in question should be re-evaluated.
another module. Secondarily, content coupling are made V. Define function predictable, but avoid mod-
into the middle of a module. This mode of coupling can and should be avoided. ules that are overly A module is predictable when it can
PART THREE: METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN CONCEPTS AND PRINCIPLES
flow, or modes of external interface will invariably require maintenance to
remove
VI. Strive for “controlled entry” modules, avoiding “pathological
connections.” This design heuristic warns against content coupling.
Software is easier to understand and therefore easier to maintain when
modules interfaced are constrained and controlled. Pathological connection
refers to branches or references into the middle of a module.
VII. Package software based on design constraints and portability
requirements. Packaging alludes to the techniques used to assemble
software for a specific processing environment. Design constraints some-
times dictate that a program “overlay” itself in memory. When this must
occur, the design structure may have to be reorganized to group modules
by degree of repetition, frequency of access and interval between calls. In
addition, optional or “one-shot” modules may be separated in the structure
so that they may be effectively overlaid.
13.7 THE DESIGN MODEL
The design principles and concepts discussed in this chapter establish a foun-
dation for the creation of the design model that encompasses representations
of data, architecture, interfaces, and procedures. Like the analysis model before
it, in the design model each of these design representations is tied to the oth-
ers, and all can be traced back to requirements.
In Figure 13.1, the design model was represented as a pyramid. The sym-
bolism of this shape is important. A pyramid is an extremely stable object with
a wide base and a low center of gravity. Like the pyramid, we want to create a
software design that is stable. By establishing a broad foundation using data
design, a stable mid-region with architectural and interface design, and a sharp
point by applying procedural design, we create a design model that is not eas-
ily “tipped by the winds of change.
It is interesting to note that some programmers continue to design implic-
itly, conducting procedural design as they code. This is akin to taking the de-
avoid a ‘pancaked’ structure sign pyramid and standing it on its point-an extremely unstable design re-
sults. The smallest change may cause the pyramid (and the program) to topple.
The methods that lead to the creation of the design model are presented in
Chapters 14 and 21 (for object-oriented systems). Each method enables the de-
signer to create a stable design that conforms to the fundamental concepts that
FIGURE 13.9. Program structures lead to high-quality software.
13.8 DESIGN DOCUMENTATION
be treated as a black box; that is, the same external data will be produced
regardless of internal processing Modules that have internal The document outlined in Figure 13.10 can be used as a template for a
“memory” can be unpredictable unless care is taken in their use. specification. Each numbered paragraph addresses different aspects of the de-
A module that restricts processing to a single subfunction exhibits high sign model. The numbered sections of the design specification are completed as
cohesion and is viewed with favor by a designer. However, a module that the designer refines his or her representation of the software.
arbitrarily restricts size of a local data structure, options within control The overall scope of the design effort is described in section I (section num-
bers refer to specification outline). Much of the information contained in
this section is derived from the system specification and the analysis model
(software requirements specification).
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 13: DESIGN CONCEPTS AND PRINCIPLES
I. Scope Sections IV and V evolve as interface and procedural design commence.
A. System objectives External and internal program interfaces are represented and a detailed de-
B. Major software requirements sign of the human-machine interface is described. Modules-separately ad-
C. Design constraints, limitations dressable elements of software such as subroutines, functions, or
II. Data Design’ are initially described with an English-language processing narrative. The
processing narrative explains the procedural function of a module. Later, a pro-
A. Data objects and resultant data structures
cedural design tool is used to translate the narrative into a structured de-
B. File and database structures scription.
1. external file structure Section VI of the design specification contains a requirements cross-refer-
a. logical structure ence. The purpose of this cross-reference matrix is (1) to establish that all re-
b. logical record description quirements are satisfied by the software design, and (2) to indicate which mod-
c. access method ules are critical to the implementation of specific requirements.
2. global data The first stage in the development of test documentation is contained in
and data reference section of the design document. Once software structure and interfaces
111. testing of individual
and integration of the entire package. some cases, a detailed
A. Review of data and control flow
B. program structure tion of test procedure occurs in parallel’with design. In such cases, this section
may be deleted from the design specification.
Iv. Interface Design
Design constraints, such as memory limitations or the necessity
A. Human-machine interface specification for a specialized external interface, may dictate special requirements for as-
B. Human-machine interface design rules sembling or packaging of software. Special considerations caused by the neces-
C. External interface design sity for program overlay, virtual memory management, high-speed processing,
1. Interfaces to external data or other factors may cause modification in design derived from information flow
2. Interfaces to external systems or devices or structure. Requirements and considerations for software packaging are pre-
D. Internal interface design rules sented in section VII. Secondarily, this section describes the approach that will
V. Procedural Design be used to transfer software to a customer site.
For each module: Section IX of the design specification contains supplementary data.
A. Processing narrative Algorithm descriptions, alternative procedures, tabular data, excerpts from
B. Interface description other documents and other relevant information are presented as a special note
or as a separate appendix. It may be advisable to develop a preliminary
C. Design language (or other) description
ationslinstallation manual and include it as an appendix to the design
D. Modules used ment.
E. Internal data structures
F. Comments/restrictions/limitations
VI. Requirements Cross-Reference
VII. Test Provisions SUMMARY
1. Text
2. Integration strategy Design is the technical of software engineering. During design,
refinements of data structure, program architecture, interfaces, and pro-
FIGURE13.10. 3. Special considerations
VIII. Special Notes cedural detail are developed, reviewed, and documented. Design results in rep-
Design specification
resentations of software that can be assessed for quality.
outline Ix. Appendices
A number of fundamental software design principles and concepts have
been proposed over the past three decades. Design principles guide the soft-
ware engineer as the design process proceeds. Design concepts provide basic
Section II presents the data design, describing external tile structures, criteria for design quality.
internal data structures and reference that connects data objects to Modularity (in both program and data) and the concept of abstraction en-
specific tiles. Section III, the architectural design, indicates how the program able the designer to simplify and reuse software components. Refinement pro-
architecture has been derived from the analysis model. Structure charts (a vides a mechanism for representing successive layers of functional detail.
representation of program structure) are used to represent the module hier- and’data structure contribute to an overall view of software architec-
archy. ture, while procedure provides the detail necessary for algorithm
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 13: DESIGN CONCEPTS AND PRINCIPLES 367
tion. Information hiding and functional independence provide heuristics for Meyer, B., Object-Oriented Software Construction, Prentice-Hall, 1988.
achieving effective modularity. Mills, “Mathematical Foundations for Structured Programming,”
We conclude our discussion of design fundamentals with the words of Technical Report FSC 71-6012, IBM Corp., Federal Systems Division,
Myers Gaithersburg, MD, 1972.
Myers, Composite Structured Design, Van Nostrand Reinhold, 1978.
try to solve the problem by rushing through the design process so that
lORR771 Structured Systems Development, Press, New York,
enough time will be left at the end of the project to uncover errors that were
1977.
made because we rushed through the design process
“On Criteria To Be Used in Decomposing Systems into
The moral is: don’t rush through it! Design is worth the effort. Modules,” CACM, vol. 14, no. 1, April, 1972, pp. 221-227.
We have not concluded our discussion of design. In the chapter that Peters, L.J., Software Design Methods and Techniques, Press,
design methods are discussed. These methods, combined with the fundamen- New York, 1981.
tals in this chapter and other methods in Chapter 21, form the basis for a com- Ross, D., Goodenough, and C. Irvine, “Software Engineering: Process,
plete view of software design. Principles and Goals,” Computer, vol. 8, no. 5, May 1975.
Shaw, M., and D. Garlan, “Formulations and Formalisms in Software
Architecture,” Volume Notes in Computer Science,
REFERENCES Springer-Verlag, 1996.
M. et al., “Abstractions for Software Architecture and Tools to
A.V., Hopcroft, and J. Ullmann, Data Structures and Algorithms, Support Them,” Trans. Software Engineering, vol. 21, no. 4, April
Addison-Wesley, 1983. 1995, pp. 314-335.
Caine, S., and K. Gordon, “PDL-A Tool for Software Design,” in Stevens, W., G. Myers, and L. Constantine, “Structured Design,”
1975, 27 I-276. 2 ,
IEEE Taylor, ES.,
Computer Society Press, 1986. Institute of Technology, Cambridge, MA, 1959.
Dahl, 0. E. Dijkstra, and C. Structured Programming, Academic J., Logical Construction of Programs, Van Nostrand Reinhold,
Press, 1972. 1974.
Davis, A., 201 Principles of Software McGraw-Hill, 1.995. Wasserman, A., “Information System Design Methodology,” in
Dennis, J., “Modularity,* in Advanced Course on Software Engineering, Design Techniques, Freeman and A. Wasserman teds.), 4th edition,
EL. Springer-Verlag, New York, 1973, pp. 128-182. IEEE Computer Society Press, 1983, 43.
Gamma, E. et al., Design Patterns, Addison-Wesley, 1995. Wirth, N., ‘Program Development by Refinement,” CACM, vol.
14, no. 4, 1971, pp. 221-227.
G., Handbook and Data Structures, 2nd edition,
Addison-Wesley, 1989. E., and L. Constantine, Structured Design, Prentice-Hall,
1979.
Garlan, D., and M. “An Introduction to Software Architecture,” in
Advances in Software Engineering and Knowledge Engineering, vol I,
and Tortora World Scientific Publishing Company,
1995.
PROBLEMS AND POINTS TO PONDER
Jackson, M.A., Principles of Program Design, Academic Press, 1975.
Jackson, M.A., System Prentice-Hall, 1983. 13.1. Do you design software when you “write” a program? What makes software
Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley, design different from coding?
1992. 13.2. Develop three additional design principles to add to those noted in Section
Design of Systems for Small Computer 13.3.
Systems, Wiley-lnterscience, 1983, pp. 594ff. 13.3. Provide examples of three data abstractions and the procedural abstractions
R.L., Structures and Program Design, Prentice-Hall, 1984. that can be used to manipulate them.
R., “Some Notes on Program Design,” Software Engineer- 13.4. Apply a “stepwise refinement approach” to develop three different levels of
ing Notes, vol. 16, no. 4, October 1991, pp. procedural abstraction for one or more of the following programs:
PART THREE: CONVENTIONAL METHODS FOR ENGINEERING CHAPTER 13: DESIGN CONCEPTS AND PRINCIPLES 369
a. Develop a check writer that, given a numeric dollar amount, will print the 4th edition, IEEE, This tutorial reprints many of the classic
amount in words that is normally required on a check. papers that have formed the for current trends in software design. Good
b. Iteratively solve for the roots of a transcendental equation. discussions of software design fundamentals can be found in books by Myers
Develop a simple round-robin scheduling algorithm for an operating sys- Peters Macro Engineering: Concepts and
tem. Prentice-Hall, 19901, and (Software Engineering,
1 3 . 6 . Is there a case when inequality (13.2) may not be true? How might such a Wesley, 5th edition, 1996). McConnell Complete, Microsoft 1993)
case affect the argument for modularity. presents an excellent discussion of the practical aspects of designing high-qual-
ity computer
1 3 . 6 . When should a modular design be implemented as monolithic software? How
A worthwhile survey of different design notations can be found in a book
can this be accomplished? Is performance the only justification for imple- by Martin and McClure (Diagramming Techniques for Analysts and Program-
mentation of monolithic software?
mers, Prentice-Hall, 1985). Stevens (Software Design: Concepts and Methods,
1 3 . 7 . Develop at least levels of abstraction for one of the following Prentice-Hall, 1990) presents a worthwhile treatment of data, architectural
problems: and procedural design. Witt and his colleagues (Software Design, Van Nostrand
a. a consumer banking application Reinhold, 19931 also cover the topic thoroughly. The design issues involved in
b. a 3D transformation package for computer graphics applications creating effective software architectures are considered by Shaw and
c. a BASIC language interpreter (Software Architectures,Prentice-Hall, 1995) and in an anthology edited by
d. a two degree of freedom robot controller and Schmidt (Pattern Languagesof Program Design,Addison-Wesley,
e. any problem mutually agreeable to you and your instructor 1995).
As the level of abstraction decreases, your focus may narrow so that at the Mathematically rigorous treatments of computer software and design fun-
last level (source code) only a single task need be described. damentals may be found in books by Jones A Rigorurous
1 3 . 8 . Obtain the original paper and summarize the software ex- Approach, Prentice-Hall, 19801, Wulf (Fundamental Structures of Computer
ample that he uses to illustrate decomposition of a system into modules. Science, Addison-Wesley, 19811, and Brassard and Bratley (Fundamentalsof
How is information hiding used to achieve the decomposition? Prentice-Hall, 1995). Each of these texts helps to supply a neces-
1 3 . 9 . Discuss the relationship between the concept of information hiding as an at- sary theoretical foundation for our understanding of computer software.
tribute of effective modularity and the concept of module independence. (Data Structures and Program Design, Prentice-Hall, 1994) and Tucker et al.
(Fundamental of Computing II: Abstraction, Data Structures, and Large
13.10. Review some of your recent software development efforts and grade each Software Systems, McGraw-Hill, 1995) present worthwhile information on data
module (on a scale of l-low to Bring in samples of your best and structures. Measures of design quality, presented from both a technical and
worst work. management perspective, are considered by Card and Glass (Measuring
13.11. A number of high-level programming languages support the internal proce- Design Quality, Prentice-Hall, 1990).
dure as a modular construct. How does this construct affect General discussion of design issues can be found in the Internet newsgroup
hiding? and many other newsgroups.
13.12. How are the concepts of coupling and software portability related? Provide An integrated environment for software design is discussed at:
examples to support your discussion.
13.13. Discuss how structural partitioning can help to make software more main-
tainable.
13.14. What is the purpose of developing a program architecture that is factored? A variety of on-line articles on software design as well as other current infor-
13.16. Describe the concept of information hiding in your own words. mation can be obtained from the Association for Software Design at:
13.18. Why is it a good idea to keep the scope of effect of a module within its scope
of control?
Substantial research has been conducted in the area of software architectures.
An excellent technology guide to the subject can be obtained at:
FURTHER READINGS AND OTHER INFORMATION SOURCES
An excellent historical survey of important papers on software design is con-
tained in an anthology edited by Freeman and Wasserman (Software Design Pointers to current work can be found at:
370 PART THREE, CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
DESIGN METHODS
An up-to-date list of World Wide Web references for software design can be
found at:
D esign has been described as a multistep process in which representations
of data structure, program structure, interface characteristics, and proce-
dural detail are synthesized from information requirements. This description is
extended by Freeman
is an activity concerned with making major decisions, of a struc-
tural nature. It shares with programming a concern for abstracting informa-
tion representation and processing sequences, but the level of detail is quite
at the extremes. Design builds coherent, well planned representationa of
programs that concentrate on the interrelationships of parts at the higher level
and the logical operations involved at the lower levels. .
As we have noted in the preceding chapter, design is information driven.
Software design methods are derived from consideration of each of the three
domains of the analysis model. The data, functional, and behavioral domains
serve as a guide for the creation of the design.
Methods required to create each of the layers of the design model
13.1) are presented in this chapter. The objective is to provide a systematic ap-
proach for the derivation of the design-the blueprint from which software is
constructed.
14.1 DATA DESIGN
Data design is the (and some would say the most important) of four de-
sign activities that are conducted during software engineering. The impact of
371
372 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: DESIGN METHODS 373
data structure on program structure and procedural complexity causes data de- 4. Low-level data design decisions should be deferred until late in the design
sign to have a profound influence on software quality, The concepts of process. A process of refinement may be used for the design of
hiding and data abstraction provide the foundation for an approach to data. That is, overall data organization may be defined during require-
data design. ments analysis, refined during preliminary design work, and specified in
The process of data design is summarized by Wasserman detail during later design iterations. The top-down approach to data design
provides benefits that are analogous to a top-down approach to software de-
sign-major structural attributes are designed and evaluated so that
The primary activity during data design is to select logical representations of
the architecture of the data may be established.
data objects (data structures) identified during the requirements definition and
specification phase. The selection process may involve algorithmic analysis of 5 . The representation of data structures should be known only to those mod-
alternative structures in order to determine the most efficient design or may ules that must make direct use of the data contained within the structure.
simply involve the use of a set of modules “package”) that provide the de- The concept of information hiding and the related concept of coupling pro-
sired operations upon some representation of an object. vide important insight into the quality of a software design. Principle 5 al-
An important related activity during design is to identify those program ludes to the importance of these concepts as well as “the importance of sep-
modules that must operate directly upon the logical data structures, In this arating the logical view of a data object from its physical view”
way the scope of effect of individual data design decisions can be constrained. 6 . A library of useful data structures and the operations that may be applied
to them should be developed. Data structures and operations should be
viewed as resources for software design. Data structures can be designed
Regardless of the design techniques to be used, well-designed data can lead to
A library of data data
program
can reduce both specification and design effort for data.
has proposed a of may used to
specify and design data. In actuality, the design of data begins during the cre- 7. A software design and programming language should support the specifi-
ation of the analysis model (Chapter 12). Recalling that requirements analysis cation and realization of abstract data types. The implementation (and cor-
and design often overlap, we consider the following set of principles responding design) of a sophisticated data structure can be made exceed-
for data specification: ingly if no means for direct specification of the structure exists. For
example, implementation (or design) of a linked list structure or a multi-
level heterogeneous array would be difficult if the target programming lan-
1. The systematic analysis principles applied to function and behavior should guage was because the language does not support direct specifica-
also be applied to data. We spend much time and effort deriving, reviewing, tion of these data structures.
and specifying functional requirements and preliminary design. Represen-
tations of data objects, relationships, data flow, and content should also be
developed and reviewed, alternative data organizations should be consid- The principles described above form a basis for a data design approach that
ered, and the impact of data modeling on software design should be evalu- can be integrated into both the definition and development phase of the soft-
ated. For example, specification of a multiringed linked list may nicely sat- ware engineering process. As we have noted elsewhere in this book, a clear de-
finition of information is essential to successful software development.
isfy data requirements but may lead to an unwieldy software design. An
alternative data organization may lead to better results.
2. All data structures and the operations to be performed on each should be
The design of an efficient data structure must take the operations to be 14.2 ARCHITECTURAL DESIGN
performed on the data structure into account (e.g., see For exam-
ple, consider a data structure made up of a set of diverse data elements. The The primary objective of architectural design is to develop a modular program
data structure is to be manipulated in a number of major software functions. structure and represent the control relationships between modules. In addition,
Upon evaluation of the operation performed on the data structure, an abstract architectural design melds program structure and data structure, defining in-
data type is for use in subsequent software design. Specification of the terfaces that enable data to flow throughout the program.
abstract data type may simplify design considerably. To understand the importance of architecture we present a brief
3 . A data dictionary should be established and used to define both data and story from everyday life:
program design. The concept of a datadictionary was introduced in Chapter
12. A data dictionary explicitly represents the relationships among data ob- You’ve saved your money, you’ve purchased a beautiful piece of land, and you’ve
jects and the constraints on the elements of a data structure. Algorithms decided to build the house of your dreams. Having no experience in such mat-
\ that must take advantage of specific relationships can be more easily de- ters, you visit a builder and explain your desires-number and size of rooms,
fined if a dictionary-like data specification exists. contemporary styling, spa (of course!), cathedral ceilings, lots of glass, etc. The
THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN METHODS
, 375
builder listens carefully, asks few questions, and then tells you he’ll have applications; complex, numerical analysis procedures; process control; and
a design in few weeks. many other engineering and scientific software applications fall into this
As you wait anxiously for his call, you conjure up many different (and out- gory. Data flow-oriented design techniques are also applicable in data process-
rageously images of your new house. What will he come up with? ing applications and can be effectively applied even when hierarchical data
Finally, the phone rings and you rush to his office. structures do exist.
Pulling out a large manila folder, the builder spreads a diagram of the There are cases, however, in which a consideration of data flow is at best
plumbing for the second floor bathroom in front of you and proceeds to explain a side issue. In such applications (e.g., database systems, expert systems, ob-
it in great detail. ject-oriented interfaces), other design methods may be more appropriate.
“But what about the overall design?” you say.
‘Don’t worry,” says the builder, “we’ll get to that later.”
14.3 THE ARCHITECTURAL DESIGN PROCESS
Does the builder’s approach seem a bit unusual? Do you feel comfortable
with the builder’s response? Of course not! You want to see a sketch of the Data flow-oriented design is an architectural design method that allows a con-
house, a floor plan, and other information that will provide an architectural venient transition from the analysis model to a design description of program
view. Yet many software developers act like the builder in our story. They con- structure. The transition from information flow (represented as a data flow
centrate on the “plumbing” (procedural details and code) to the exclusion of the to structure is accomplished as part of a five-step process: the type
software architecture. The design method presented in this section encourages of information flow is established; flow boundaries are indicated, the
the software engineer to concentrate on architectural design before worrying DFD is mapped into program structure; control hierarchy is defined by
about the plumbing. taring; and the resultant structure is refined using design measures and
heuristics. The information flow type is the driver for the mapping approach
required in stop 3. In the following sections we examine two flow types.
14.2.1 Contributors
14.3.1 Tmnrform Flow
Architectural design (and software design generally) has its origins in earlier
design concepts that stressed modularity top-down design In the fundamental system model (level 0 data flow diagram), information
and structured programming Stevens, Myers, and Constantine must enter and exit software in an “external world” form. For example, data
were early proponents of software design based on the flow of data typed on a keyboard, tones on a telephone line, and pictures on a computer
through a system. Early work was refined and presented in books by Myers graphics all forms of external world information. Such externalized
and and Constantine data must be converted into an internal form for processing. The time history
More recent work on software architectural design has developed a much of data can be illustrated in Figure 14.1, Information enters the system along
more sophisticated focus. A book by Shaw and Garlan and articles by paths that transform external data into an internal form and will be identified
Dean IDEA951 and Moriconi are all representative of work that fo- as incoming flow. At the kernel of the software, a transition occurs. Incoming
cuses on developing formalisms for representing architectural design models data are passed through a transform center and begin to move along paths
and patterns.
now lead of the software. Data moving along these paths are called out-
going The overall flow of data occurs in a sequential manner and follows
one, or only a few, “straight line” paths. When a segment of a data flow diagram
exhibits these characteristics, transform flow is present.
14.2.2 of Application
Each software design method has strengths and weaknesses. An important
143.2 Transaction Flow
factor for a design method is the breadth of applications to which it can
be applied. Data flow-oriented design is amenable to a broad range of applica-
tion areas. In fact, because all software can be represented by a data flow dia- The fundamental system model implies transform flow; therefore, it is possible
gram, a design method that makes use of the diagram could theoretically be to characterize all data flow in this category, However, information flow is of-
applied in every software development effort. A data flow-oriented approach to ten characterized by a single data item, called a that triggers other
design is particularly useful when information is processed sequentially and no data flow along one of many paths. When a DFD takes the form shown in
formal hierarchical data structure exists. For example, microprocessor control Figure 14.2, transaction flow is present.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: METHODS 377
Incoming Outgoing
External flow flow
representation
Transform flow
Internal
representation FIGURE 14.3. sensors number
status line
Context-level DFD for I
FIGURE 14.1.
Flow of information Time
Transaction flow is characterized by data moving along an incoming path It should be noted that within a DFD for a large system, both transform
that converts external world information into a transaction. The transaction is and transaction flow may be present. For example, in a transaction-oriented
evaluated, and based on its value, flow along one of many action paths is initi- flow, information flow along an action path may have transform flow charac-
ated. The hub of information flow from which many action paths emanate is teristics.
called a transaction center.
14.4 TRANSFORM MAPPING
Transform mapping is set of design steps that allows a DFD with transform
flow characteristics to be mapped into a template for program struc-
Transaction ture. In this section transform mapping is described by applying design steps
Action to an example system-a portion of the security software presented
paths in earlier chapters.
center 14.4.1 An Example
The security system, introduced earlier in this book, is representa-
tive of many computer-based products and systems in use today. The product
monitors the real world and reacts to changes that it encounters. It also inter-
acts with a user through a series of typed inputs and alphanumeric displays.
The level 0 data flow diagram for reproduced from Chapter 12, is
shown in Figure 14.3.
During requirements analysis, more detailed flow models would be created
for In addition, control and process specifications, a data dictionary,
and various behavioral models would also be created.’
FIGURE 14.2. ‘Readers who have not read Chapters 11 and 12 are urged to do so before continuing with
Transaction this chapter.
PART THREE: CONVENTIONAL SOFTWARE ENGINEERING CHAPTER DESIGN METHODS 379
378
14.4.2 Design Steps the design step begins with an evaluation of both the system and
the requirements specification. Both documents describe information
flow and structure at software interface. Figures 14.3 and 14.4 depict level
The above example will be used to illustrate each step in transform mapping. 0 and level 1 data for the software.
The steps begin with a re-evaluation of work done during requirements analy-
Step 2. Review and data flow diagrams for the software. Informa-
sis and then move to the development of program structure.
tion obtained from analysis models contained in the software requirements
specification is refined to produce greater detail. For example, the level 2
Step 1. Review the fundamental system model.
The fundamental system for sensors (Figures 14.4 and 14.5) are examined, and a level 3 data
model encompasses the level 0 DFD and supporting information. actuality flow diagram is derived as shown in Figure 14.6. At level 3, each transform in
the data flow diagram exhibits relatively high cohesion (Chapter 13). That is,
the process implied by a transform performs a single, distinct function that can
he implemented as a module in the software Therefore, the DFD in
control Figure 14.6 sufficient for a “first cut” at the design of program
panel and we proceed without further
refinement.
configure
request
user
configuration information
control
panel
display display
\ {information-
‘ .
/information
sensors . sensor
status FIGURE 14.5.
number tones Level 2 DFD that
fines the monitor sen- status
FIGURE 14.4. Level 1 DFD for sors process number tones
CHAPTER DESIGN METHODS 381
Step 3. Determine whether the DFD has transform or transaction flow
characteristics. In general, information flow within a system can always be rep
resented as a transform. However, when an obvious transaction characteristic
(Figure 14.2) is encountered, a different design mapping is recommended. In this
step, the designer selects a global (software-wide) flow characteristic based on the
prevailing nature of the DFD. In addition, local regions of transform or
tion flow are isolated. These can be used to refine program structure de-
rived from a global characteristic described above. For now, we focus our attention
only on the monitor sensors subsystem data flow depicted in Figure 14.6.
Evaluating the DFD (Figure we see data entering the software along
one incoming path and exiting along three outgoing paths. No distinct trans-
action center is implied (although the transform acquire alarm conditions could
perceived as such). Therefore, an overall transform characteristic will as-
sumed for information flow.
Step 4. Isolate the transform center by specifying incoming and
flow In the preceding section incoming flow was described as
a path in which information is converted from external to internal form; outgoing
flow converts from internal to external form. Incoming and outgoing flow bound-
aries are open to interpretation. That is, different designers may select slightly
different points in the flow as boundary locations. In fact, alternative design
lutions can be derived by varying the placement of flow boundaries Although care
should be taken when boundaries are selected, a variance of one bubble along a
flow path will generally have little impact on the final program structure.
Flow boundaries for the example are illustrated as shaded curves running
vertically through the flow in Figure 14.6. The transforms (bubbles) that com-
prise the transform center lie within the two shaded boundaries that run from
1.0 in An be made to a houndary
(e.g.. an incoming flow boundary separating and response
on selecting
than on of divisions.
Step Perform factoring.” Program structure represents a top.
down distribution of control. Factoring results in a program structure in which
top-level modules perform decision making and low-level modules perform
most input, computational, and output work. Middle-level modules perform
some control and do moderate amounts of work.
When transform flow is encountered, a DFD is mapped to a specific struc-
ture that provides control for incoming, transform, and outgoing information
processing. This factoring for the monitor sensors subsystem is illus-
trated in Figure 14.7. A main controller (called monitor sensors executive)
resides at the top of the program structure and serves to coordinate the
lowing subordinate control functions:
an incoming information processing controller, called sensor input con-
troller, coordinates receipt of all incoming data;
a transform flow controller, called alarm conditions controller, su-
pervises all operations on data in internalized form (e.g., a module that
invokes various data transformation procedures;
an outgoing information processing controller, called alarm output
controller, coordinates production of output information.
380
PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: DESIGN METHODS 383
Step 8. “second-level factoring,” is accom-
plished by mapping individual transforms (bubbles) of a DFD into appropriate
modules within the program structure. Beginning at the transform center
boundary and moving outward along incoming and then outgoing paths, trans-
forms are mapped into subordinate levels of the software structure. The gen-
eral approach to second-level factoring for the data flow is illus-
trated in Figure 14.8.
Although Figure 14.8 illustrates a one-to-one mapping between DFD trans-
forms and software modules, different mappings frequently occur. Two or even
three bubbles can be combined and represented as one module (recalling
tential problems with cohesion), or a single bubble may be expanded to two or
more modules. Practical considerations and measures of design quality dictate
the outcome of second-level factoring. Review and refinement may lead to
changes in this structure, but it can serve as a first design iteration.
Second-level factoring for incoming flow follows in the same manner.
Factoring is again accomplished by moving outward from the transform center
boundary on the incoming flow side. The transform center of monitor sensors
subsystem software is mapped somewhat differently. Each of the data conver-
sion or calculation transforms of the transform portion of the DFD is mapped
into a module subordinate to the transform controller. A completed first itera-
tion program structure is shown in Figure 14.9.
The modules mapped in the manner described above and shown in Figure
14.9 represent an initial design of program Although modules are
named in a manner that implies function, a brief processing narrative (adapted
from the PSPEC created during analysis modeling) should be written for each.
The narrative describes:
!" information that passes into and out of the module (an interface de-
scription);
!" information that is retained by a module, e.g., data stored in a local
monitor data structure;
sensors !" a procedural narrative that indicates major decisions points and
executive and
!" a brief discussion of restrictions and special features (e.g., file I/O,-
hardware dependent characteristics, special timing requirements).
The narrative serves as a first generation design specification. However,
further refinement and additions occur regularly during this period of design.
Step 7. Refine the first iteration program structure using design
tics for improved software quality. A program structure can always be
refined by applying concepts of module independence (Chapter 13). Modules
FIGURE 14.7. First-level factoring for monitor sensors
are exploded or imploded to produce sensible factoring, good cohesion, minimal
coupling, and most important, a structure that can be implemented without dif-
ficulty, tested without confusion, and maintained without grief,
Although a three-pronged structure is implied by Figure 14.7, complex
Refinements are dictated by practical considerations and common sense.
flows in large systems may dictate two or more control modules for of There are times, for example, when controller for incoming data flow is to-
the generic control functions described above. The number of modules at
tally unnecessary, when some input processing is required in a module that is
the first level should be limited to the minimum that can accomplish con-
subordinate to the transform controller, when high coupling due to global data
trol functions and still maintain good coupling and cohesion characteris-
cannot be avoided, or when optimal structural characteristics (see Section 13.6)
tics.
384 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
F I G U R E 1 4 . 8 . First level factoring for
monitor
385
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14 DESIGN METHODS
cannot be achieved. Software coupled with human judgment is The reader should pause for a moment and consider the difference between
the final arbiter. the design approach described above and the process of “writing programs.” If
Many modifications can be made to the first iteration structure developed code is the only representation of software, the developer will have great
for the monitor subsystem: (1) The incoming controller can evaluating or refining at a global or holistic level and will, in fact, have
be removed because it is unnecessary when a single incoming flow path is to difficulty “seeing the forest for the trees.”
be managed. The substructure generated from the transform flow can be im-
ploded into the module establish alarm conditions (which will now include
the processing implied by number). Thetransform controller 14.5 TRANSACTION MAPPING
will not be needed and the small decrease in cohesion is tolerable. The mod-
ules format display and generate display can be imploded (we assume that In many software applications, a single data item triggers one or a number of
diaplay formatting is quite simple) into a new module called , information flows that effect a function implied by the triggering data item.
The refined software structure for the monitor sensors subsystem is shown in The data item, called a transaction, and its corresponding flow characteristics
Figure 14.10. were discussed in Section 14.3.2. In this section we consider design steps used
to treat transaction flow.
The objective of the preceding seven steps is develop a global represen-
tation of software. That is, once structure is defined, we can evaluate and re-
fine architecture by viewing it as a whole. Modifications made at this
time require little additional work, yet can have a profound impact on software An Example
quality and maintainability.
Transaction mapping will be illustrated by considering the interaction
subsystem of the software. Level 1 data flow for this subsystem is
shown as part of Figure 14.4. Refining the flow, 2 data flow diagram (a
corresponding data dictionary, CSPEC, and would also be created) is
developed and shown in Figure 14.11.
As shown in the figure, user commandsflows into the system and results
in additional information flow along one of three action paths. A single data
item, command type, causes the data flow to fan outward from a hub.
Therefore, the overall data flow characteristic is transaction-oriented,
It should be noted that information flow along two of the three action paths
accommodate additional incoming flow (e.g., system and data
are input on the “configure” action path. Each action path flows a single
transform, display messages and status.
14.5.2 Design Steps
Design steps for transaction mapping are similar and in some cases identical
to steps for transform mapping (Section 14.4). A major difference lies in the
mapping of the DFD to software structure.
Step 1. Review the system model.
Step 2. Review and refine data flow diagrams for the software.
generate Step 3. Determine whether the DFD has transform or transaction flow
characteristics.Steps 1, 2, and 3 are identical to corresponding steps in
pulses line
transform mapping. The DFD shown in Figure 14.11 has a classic transaction
flow characteristic. However, flow along two of the action paths emanating from
the command processing bubble appears to have transform flow char-
14.10. Refined program for monitor sensors acteristics. Therefore, flow boundaries must be established for both flow
CHAPTER 14: DESIGN METHODS 389
Identify the transaction center and the flow characteristics
along each of the action paths. location of the transaction center can
The
be immediately discerned from the DFD. The transaction center lies at the
origin of a number of actions paths that flow radially from it. For the flow
shown in Figure 14.11, the invoke command processing bubble is the trans-
action center.
The incoming path the flow path along which a transaction is re-
ceived) and all action paths must also be isolated. Boundaries that define a re-
ception path and action paths are also shown in the figure. Each action path
must be evaluated for its individual characteristic. For example, the ‘pass-
word” path (shown enclosed by a shaded area in Figure 14.11) has transform
characteristics. Incoming, outgoing flow are indicated with
boundaries.
Step Map the DFD in a structure amenable to transaction
processing. Transaction flow is mapped into a program structure that con-
tains an incoming branch and a dispatch branch. for the incoming
branch is developed in much the same way as transform mapping. Starting at
the transaction center, bubbles along the incoming path are mapped into mod-
ules. The structure of the dispatch branch contains a dispatcher module that
controls all subordinate action modules. Each action flow path of the DFD is
mapped to a structure that corresponds to its specific flow characteristics. This
process is illustrated Figure 14.12.
Considering the user interaction subsystem data flow, first-level factoring
for step 5 is shown in Figure 14.13. The bubbles read command and acti-
vate/deactivate system map directly into the program structure without the
need for intermediate control modules. center, invoke command
maps directly into of the Controllers
for system configuration and password processing are mapped as indicated in
Figure 14.12.
Step 6. Factor and refine the transaction structure and the structure
of each action path.
Each action path of the data flow diagram has its own
information flow characteristics. We have already noted that transform or
transaction flow may be encountered. The action path-related “substructure”
is developed using the design steps discussed in this and the preceding sec-
tion.
As an example, consider the password processing information flow shown
(inside shaded area) in Figure 14.11. The flow exhibits classic transform char-
acteristics. A password is input (incoming flow) and transmitted to a transform
center where it is compared against stored passwords. An alarm and warning
message (outgoing flow) are produced (if a match is not obtained). The “config-
ure” path is drawn similarly using the transform mapping. The resultant pro-
gram structure is shown in Figure 14.14.
Step 7. Refine the iteration program structure using design
tics for improved software quality. step for transaction mapping is
This
identical to the corresponding step for transform mapping. In both design ap-
proaches, criteria such as module independence, practicality (efficacy of imple-
mentation and test), and maintainability must be carefully considered as struc-
tural modifications are proposed.
388
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN METHODS 391
Transaction user
interaction
executive
FIGURE14.13.
factoring
far user interaction
subsystem
A processing narrative is (ideally) an unambiguous, bounded description of
processing that occurs within a module. The narrative describes processing
tasks, decisions, and
The interface description requires the design of internal module interfaces,
external system interfaces and the human-computer interface. These topics are
discussed in Section 14.8.
The design of data structures can have a profound impact on program
structure and the procedural details for each module. Techniques described in
Chapter 12 establish the basic data model and identify all important data
These then serve as the basis for the design of both local and global data
structures.
FIGURE 14.12. Transaction mapping Restrictions and/or limitations for each module are also documented.
Typical topics for discussion include restriction of data type or format, memory
or timing limitations, bounding values or quantities of data structures, special
cases not considered, and specific characteristics of an individual module. The
DESIGN POSTPROCESSING purpose of a restrictions/limitations section is to reduce the number of errors
introduced because of assumed functional characteristics.
Successful application of transform or transaction mapping is supplemented by Once design documentation has been developed for all modules, a design
additional documentation that is required as part of architectural design. After review is conducted (see Chapter 8 for review guidelines). The review empha-
structure has been developed and refined, the following tasks must be sizes traceability to software requirements, quality of program structure,
descriptions, descriptions, and test prac-
ticality, and maintainability.
!" A processing narrative must be developed for each module.
!"An interface description is provided for each module.
!" Local and global data structures are defined.
14.7 . ARCHITECTURAL DESIGN OPTIMIZATION
!"All design are noted.
!" A design review is conducted. Any discussion of design optimization should be prefaced with the following
!" ‘Optimization” is considered (if required and justified). comment: “Remember that an ‘optimal design’ that doesn’t work has
14: DESIGN METHODS 393
able merit.” The designer should be concerned with developing a rep-
resentation of that will meet all functional and performance require-
ments and merit acceptance based on design quality measures.
Refinement of program structure during the early stages of design is to be
encouraged. Alternative representations may be derived, refined, and evaluated
for the “best” approach This approach to optimization is one of the true bene-
fits derived from developing a representation of software architecture.
It is important to note that structural simplicity both ele-
gance and efficiency. Design optimization should strive for the smallest num-
ber of modules that is consistent with effective modularity and the least com-
plex data structure that adequately serves information requirements.
For performance-critical applications, it may be necessary to “optimize”
during later design iterations, and possibly during coding. The software engi-
neer should note, however, that a relatively small percentage (typically, 10-20
percent) of a program often accounts for a large percentage percent) of
all processing time. It is not unreasonable to propose the following approach
for performance-critical software:
1. Develop and refine program structure without concern for
critical optimization.
2. Use CASE tools that simulate run-time performance to isolate areas of in-
efficiency
3. During later design iterations, select modules that are suspect “time hogs”
and carefully develop procedures (algorithms) for time efficiency.
4. Code in an appropriate programming language.
5. Instrument the software to isolate modules that account for heavy proces-
sor utilization.
6. If necessary, redesign or recode in machine-dependent language to improve
efficiency.
This approach follows a dictum that will be further discussed in a later chap-
ter: “Get it to work, then make it fast.”
14.8 INTERFACEDESIGN
The architectural design provides a software engineer with a picture of the pro-
gram structure. Like the blueprint for a house, the overall design is not com-
plete without a representation of doors, windows, and utility connections for
water, electricity, and telephone (not to mention cable TV). The “doors, windows,
and utility connections” for computer software comprise the interface design of
a system.
Interface design focuses on three areas of concern: the design of inter-
faces between software modules; (2) the design of interfaces between the soft-
ware and other nonhuman producers and consumers of information (i.e., other
external entities); and (3) the design of the interface between a human (i.e., the
user9 and the computer.
392
CHAPTER DESIGN METHODS
PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 395
User interface design has as much to do with the study of people as it does
14.8.1 internal and External Interface Design
with technology issues. Who is the user? How does the user learn to interact
with a new system? How does the user interpret information
The design of internal program interfaces, sometimes called intermodular in- produced by the system? What will the user expect of the system? These are
design, is driven by the data that must flow between modules and the only a few of the many questions that must be asked and answered as part of
characteristics of the programming language in which the software is to be im- user interface design.
plemented.* In general, the analysis model contains much of the information
required for intermodular interface data diagram (Chapter
describes how data objects are transformed as they move through a system. 14.9 HUMAN-COMPUTER INTERFACE DESIGN
The transforms (i.e., bubbles) of the DFD are mapped into modules within the
program structure (Sections 14.4 and 14.51. Therefore, the arrows (data objects)
flowing into and out of each DFD transform must be mapped into a design for The overall process for designing a user interface begins with the creation of
the interface of the module that corresponds to that DFD transform. different models of system function (as perceived from the outside). The hu-
External interface design begins with an evaluation of each external entity man- and computer-oriented tasks that are required to achieve system function
represented in the of the analysis model. The data and control require- are then design issues that apply to all interface designs are con-
ments of the external entity are determined and appropriate external inter- sidered; tools are used to prototype and ultimately implement the design model;
faces are designed. For example, the software discussed earlier in and the result is evaluated for quality.
chapter requires interfacing with a variety of external security sensors,
The design of the interface for each sensor is predicated on the spe-
cific data and control items required for the sensor.
Both internal and external interface designs must be coupled with data 14.9.1 Interface Design Models
validation and error handling algorithms within a module. Because side effects
propagate across program interfaces, it is essential to check all data flowing Four different models come into play when a human-computer interface is
from module to module (or to the outside world) to ensure that the data con- to be designed. The software engineer creates a a human engineer
form to bounds established during requirements analysis. (or the software engineer) establishes a user the end user develops a men-
tal image that is called the user’s or the system perception, and the
implementers of the system create a Unfortunately, these
models may differ significantly The role of interface designer is to reconcile these
14.8.2 User interface Design differences and derive a consistent representation of the interface.
A design model of the entire system incorporates data, architectural, in-
In the preface to his book on user interface design, Ben Shneiderman terface, and procedural representations of the software. The requirements spec-
states: ification may establish certain constraints that help to define the user of the
system, but the interface design is
Frustration and anxiety are part of daily life for many users of The user model depicts the profile of end users of the system. To build an
information struggle to learn command language or menu se- effective user interface, “all design should begin with an understanding of the
intended users, including profiles of their age, sex, physical abilities, education,
lection systems that are supposed to help them do their job. Some people en-
counter such serious cases of computer shock, terminal terror, or network neu- cultural or ethnic background, motivation, goals and personality” In
rosis that they avoid using computerized systems. addition, users can be categorized as:
The problems to which Shneiderman alludes are real. We have all encountered !" novices-no syntactic knowledge* of the system and little semantic
“interfaces” that are difficult to learn, difficult to use, confusing, unforgiving, edges of the application or computer usage in general;
and in many cases, totally frustrating. Yet, someone spent time and energy
building each of these interfaces. and it is likely that the builder did not cre-
ate these problems purposely. this in not it should be. For interactive systems, the interface design is im-
portant as the data, architectural, or procedural design.
‘In this context syntactic knowledge refers to the mechanics of interaction that is to
the interface effectively.
refers to an underlying sense of the application--an understanding of
programming languages typically make use of an argument list transfer
data across interfaces. Object-oriented languages make use of messages accomplish data the functions that performed, the meaning of input and output, and the goals and
transfer. Design issues in these two contexts different. of the system.
396 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: DESIGN METHODS 397
!" knowledgeable, intermittent users-reasonable semantic knowledge of the ap-
plication, but relatively low recall of syntactic information necessary to use
the interface; and
!" knowledgeable, frequent users-good semantic and syntactic knowledge that
often leads the “power-user syndrome,” that is, individuals who look for
shortcuts and abbreviated modes of interaction.
The system perception (user’s model) is the image of the system that an end
user carries in his or her head. For example, if the user of a particular word
processor were asked to describe its operation, the system perception would
guide the response. The accuracy of the description will depend upon the user’s
profile (e.g., novices would provide a sketchy response at best) and overall fa-
miliarity with software in the application domain. A user who understands
word processors fully, but has only worked with the specific word processor
once, might actually be able to provide a more complete description of its func-
tion than the novice who has spent weeks trying to learn the system. FIGURE 14.15.
The system image couples the outward manifestation of the Relating interface de
based system (the look and feel of the interface), with all supporting informa- sign
tion (books, manuals, video tapes) that describe system syntax and semantics.
When the system image and the system perception are coincident, users gen-
erally feel comfortable with the software and use it effectively. To costing, and shopping. Each of these major tasks can be elaborated into
this “melding” of the models, the design model must have been developed to ac- tasks. For example, furniture layout can be refined into the following tasks:
commodate the information contained in the user model and the system image Draw floor plan based on room dimensions; place windows and doors at ap-
must accurately reflect syntactic and semantic information about the propriate locations; use furniture templates to draw scaled furniture out-
The interrelationship among the models is shown in Figure 14.15. lines on floor plan; (4) move furniture outlines to get best placement; label
The models described in this section are “abstractions of what. the user is all furniture outlines; draw dimensions to show location; and draw per-
doing or thinks he is doing or what somebody else thinks he ought to be doing spective view for customer. A similar approach could be used for each of the
when he uses an interactive system” In essence, these models enable other major tasks.
the interface designer to satisfy a key element of the most important principle 1 to 7 can each be refined further. 1 to 6 will be per-
of user interface design: “Know the user, know the tasks.” formed by manipulating informatiop and performing actions with the user in-
terface. On the other hand, 7 can be performed automatically in soft-
ware and will result in little direct user design model of the
interface should accommodate each of these tasks in a way that is consistent
with the user model (the profile of a “typical” interior designer) and system per-
14.9.2 Task Analysis and Modeling ception (what the interior designer expects from a automated system).
An alternative approach to task analysis takes an object-oriented point of
Task analysis and modeling can be applied to understand the tasks that The human engineer observes the physical objects that are used by the
currently perform (when using a manual or semiautomated approach) and interior designer and the actions that are applied to each object. For example,
then map these into a similar (but not necessarily identical) set of tasks that the furniture template would be an object in this approach to task analysis. The
are implemented in the context of the HCI. This can be accomplished by ob- interior designer would select the appropriate template, move it to a position
servation or by studying an existing specification for a computer-based solution on the floor plan, trace the furniture outline and so forth. The design model for
and deriving a set of user tasks that will accommodate the user model, the de- interface would not describe implementation details for each of these ac-
sign model, and the system perception. tions, but it would define user tasks that accomplish the end result (drawing
Regardless of the overall approach to task analysis, the furniture outlines on the floor plan).
must first define and classify tanks. One is elaboration each task or action has been defined, interface design begins. The
(Chapter 13). For example, assume that a small software company wants to first steps in the interface design process can be accomplished using
build a computer-aided design system explicitly for interior designers. By ob- the following approach:
serving a designer at work, the engineer notices that the interior design is com-
prised of a number of major activities: furniture layout, fabric and material se-
lection, wall and window covering selection, presentation (to the customer), Part Four of for further discussion of the object-oriented viewpoint.
CHAPTER DESIGN METHODS
398 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
this reduces the time required for the user to obtain help and increases the
1. Establish the goals and intentions for the task. is
“friendliness” of the interface. An add-on help facility added to the software
2. Map each goal/intention to a sequence of specific actions. after the system has been built. In many ways, it is really an on-line user’s
3. Specify the action sequence as it will be executed at the interface level. manual with limited query capability. The user may have to search through a
list of hundreds of topics to find appropriate guidance, often making many false
4. Indicate the state of the system; i.e., what does the interface look like at
starts and receiving much irrelevant information. There is little doubt that the
the time that an action in the sequence is performed?
integrated help facility is preferable to the add-on approach.
5 . Define control mechanisms, i.e., the and actions available to the A number of design issues must be addressed when a help facil-
user to alter the system state. ity is considered:
6 . Show how control mechanisms affect the state of the system.
Indicate how the user interprets the state of the system from information !" Will help be available for all system functions and at all times during sys-
provided through the interface. tem interaction? Options include help only for a subset of all functions and
actions, and help for all functions.
!" How will the user request help? Options include a help menu, a special func-
tion key, and a HELP command.
14.9.3 Design Issues
!" will be represented? Options include a separate window, a refer-
ence to a printed document (less than ideal), and a one or two line sugges-
As the design of a user interface evolves, four common design issues almost al- tion produced in a fixed screen location.
ways surface: system response time, user help facilities, error information han- !" How will the user return to normal interaction? Options include a return but-
dling, and command labeling. Unfortunately, many designers do not address ton displayed on the screen and a function key or control sequence.
these issues until relatively late in the design process (sometimes the first
!" How will help information be structured? Options include a “flat” structure
inkling of a problem doesn’t occur until an operational prototype is available).
Unnecessary iteration, project delays, and customer frustration almost always in which all information is accessed through a keyword, a hierarchy
result, It is far better to establish each as a design issue to be considered at of information that provides increasing detail as the user proceeds into the
the beginning of software design, when changes are easy and costs are low. structure, and the use of hypertext.
System response time is the primary complaint for many interactive sys-
tems. In general, system response time is measured from the point at which Error messages and warnings are “bad news” delivered to users of inter-
the user performs some control action (e.g., hits the return key or clicks a active systems when something has gone awry. At their worst, error messages
mouse) until the software responds with desired output or action. and warnings impart useless or misleading information and serve only to in-
System response time has two important characteristics: length and crease user frustration. Few computer users have not encountered an error of
If the length of time for system response is too long, user frustration the form:
and stress is the inevitable result. However, a very brief response time can also
be detrimental if the user is being paced by the interface. A rapid response may SEVERE SYSTEM
force the user to rush and therefore make mistakes.
Variability refers to the deviation from average response time, and in many
Somewhere, an explanation for error 14A must exist; otherwise, why would the
ways, it is the more important of the response time characteristics. Low
designers have added the identification? Yet the error message provides no real
ability enables the user to establish a rhythm, even if response time is rela-
indication of what is wrong or where to look get additional information. An
tively long. For example, one second response to a command is preferable to a
response that varies from 0.1 to 2.5 seconds. The user is always off balance, al- error message presented in the manner shown above does nothing to assuage
user anxiety or to help correct the problem.
ways wondering whether something “different” has occurred behind the scenes.
In general, every error message or warning produced by an interactive sys-
Almost every user of an interactive, computer-based system requires help
tem should have the following characteristics:
now and then, In some cases, a simple question addressed to a knowledgeable
colleague can do the trick. In others, detailed research in a multivolume set of
user manuals may be the only option. In many cases, however, modem software !" The message should describe the problem in jargon that the user can un-
provides on-line help facilities that enable a user to get a question answered or derstand.
resolve a problem without leaving the interface. !" The message should provide constructive advice for recovering from the error.
Two different types of help facilities are encountered: and !" The should indicate any negative consequences of the error (e.g., po-
on An help facility is designed into the software from the tentially corrupted data so that the can check to ensure that they
beginning. It is often context sensitive, enabling the user to select from those have not occurred correct them if they have).
topics that are relevant to the actions currently Obviously,
400 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: DESIGN METHODS 401
!"The message should be accompanied by an audible or visual cue. That is, a iterative design approach a broad class of interface design and prototyping
beep might be generated to accompany the display of the message, or the tools has evolved. Called user toolkits interface development
message might flash momentarily or be displayed in a color that is easily rec- systems these tools provide routines or objects that facilitate creation
ognizable as the color.” of windows, menus, device interaction, error messages, commands, and many
other elements of an interactive environment.
!" The message should be “nonjudgmental.” That is, the wording should never
Using prepackaged software that can be used directly by the designer and
place blame on the user.
implementer or a user interface, a UIDS provides built-in mechanisms
for:
Because no one really likes bad news, few users will like an error message
no matter how well it is designed. But an effective error message philosophy
can do much to improve the quality of an interactive system and will signifi- !"managing input devices (such as the mouse or keyboard);
cantly reduce user frustration when problems do occur. !" validating user input;
The typed command was once the most common mode of interaction be- !" handling errors and displaying error messages;
tween user and system software and was commonly used for applications of !" providing feedback (e.g., automatic input echo);
every type. Today, the use of window-oriented, point and pick interfaces has re-
!" providing help and prompts;
duced reliance on typed commands, but many power-users continue a
command-oriented mode of interaction. In many situations, the user can be pro- !" handling windows and fields, scrolling within windows;
vided with an option-software functions can be selected from a static or !" establishing connections between application software and the interface;
down menu or invoked through some keyboard command sequence.
!" insulating the application from interface management functions; and
A number of design issues arise when commands are provided as a mode
!"allowing the user to customize the interface.
of interaction:
!" Will every menu option have a corresponding command? The functions described above can be implemented using either a
based or a graphical approach.
!" What form will commands take? Options include a control sequence (e.g.,
function keys, and a typed word.
!" How will it to learn and remember the commands? What can be done
if a command is forgotten? (See the discussion of help earlier in this section.) 14.9.5 Design Evaluation
!" Can commands be customized or abbreviated by the user?
Once an operational user interface prototype has been created, it must be eval-
In a growing number of applications, interface designers provide a com- uated to determine whether it meets the needs of the user. Evaluation can span
mand macro that allows the user to store a sequence of commonly used a formality spectrum that ranges from an informal “test drive” in which a user
commands under a user-defined name. Instead of each command being typed impromptu feedback to a formally designed study that uses statisti-
individually (and repetitively), the command macro is typed and all commands cal methods for the evaluation of questionnaires completed by a population of
implied by it are executed in sequence. end users.
In an ideal setting, conventions for command usage should be established The user interface evaluation cycle takes the form shown in Figure 14.16.
across all applications. It is confusing and often error-prone for a user to type After the preliminary design has been completed, a first-level prototype is cre-
when a graphics object is to be duplicated in one application and when ated. The prototype is evaluated by the user, who provides the designer with
a graphics object is to be deleted in another. The potential for error is obvious. direct comments about the efficacy of the interface. In addition, if formal eval-
uation techniques are used (e.g., questionnaires, rating sheets), the designer
may extract information from this information (e.g., 80 percent of all users did
not like the mechanism for saving data files). Design modifications are made
14.9.4 Implementation Tools based on user input and the next-level prototype is created. The evaluation cy-
cle continues until no further modifications to the interface design are neces-
The process of user interface design is iterative. That is, a design model is cre- sary. But is it possible to evaluate the quality of a user interface before a pro-
ated, implemented as a examined by users (who tit the user model totype is built? If potential problems can be uncovered and corrected early, the
described earlier), and modified their comments. To accommodate this number of loops through the evaluation cycle will be reduced and development
time will shorten.
‘It should be noted that in cases (e.g., cockpit displays) the first step might to When a design model of the interface has been created, a number of eval-
simulate the interface on a display device rather than it cockpit hardware. uation criteria can be applied during early design reviews:
PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN METHODS 403
1. Were the commands easy to remember?
2. How many different commands you use?
3. How easy was it to learn basic system operations? (scale of to
4. Compared to other interfaces you’ve used, how would this rate? (top
top top bottom
build
If quantitative data are desired, a form of time study analysis can be con-
prototype .
Users are observed during interaction, and data such as number
interface
tasks correctly completed over a standard time period, frequency of
use, sequence of commands, time spent ‘looking” at the display, number of er-
rors, types of error and error recovery time, time spent using help, and num-
ber of help references per standard time period are collected and used as a
guide for interface modification.
A complete discussion of user interface evaluation methods is beyond the
scope of this book. For further information, see
user
14.10 INTERFACE DESIGN GUIDELINES
evaluates
interface
The design of user interfaces draws heavily on the experience of the designer
and on anecdotal experience presented in hundreds of technical papers and
dozens of books. Many sources in the literature (e.g., present a set
of HCI design guidelines that will result in a ‘friendly,” interface. In
14.16. this section, some of the more important HCI design guidelines are presented.
The interface Three categories of HCI design guidelines are suggested: general interac-
design evaluation tion, information display, and data entry.
14.10.1 General
The length and complexity of the written specification of the system and Guidelines for general interaction often cross the boundary into information
its interface provide an indication of the amount of learning required by display, data entry, and overall system control. They are therefore all-encom-
of the system. passing and are ignored at great risk. The following guidelines focus on gen-
2. The number of commands or actions specified and the average number of eral interaction:
arguments per command or individual operations per action provide an
indication of interaction time and the overall efficiency of the system. Be consistent. Use a consistent format for menu selection, command in-
3. The number of actions, commands, and system states indicated by the de- put, data display, and the myriad other functions that occur in a HCI.
sign model indicate the memory on users of the system. Offer meaningful feedback. Provide the user with visual and auditory
4. Interface style, help facilities, and error handling protocols provide a gen- feedback to ensure that two-way communication (between user and inter-
eral indication of the complexity of the interface and the degree to which face) is
it will be accepted by the user. Ask for verification of any nontrivial destructive action. If a requests
the deletion of a file, indicates that substantial information is to be over-
Once the first prototype is built, the can a variety of qual- written, or asks for the termination of a program, an “Are you sure. . .
itative and quantitative data that will assist in evaluating the interface. To col- message should appear.
lect qualitative data, questionnaires can be distributed to usersof the proto- Permit easy reversal of actions, UNDO or REVERSE functions have
type. Question responses can be simple yes/no, numeric, scaled saved tens of thousands of end users from millions of hours of frustration.
(subjective), or percentage (subjective). Examples are: Reversal should be available in every interactive application.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: DESIGN METHODS 405
Reduce the amount of information that must be memorized between ac- Use windows to compartmentalize different types of information. Windows
tions. The user should not be expected to remember a list of numbers or enable the user to “keep” many different types of information within easy
names so that he or she can reuse them in a subsequent function. Memory reach.
load should be minimized. Use ‘analog’ displays to represent information that is more easily assimi-
Seek efficiency in dialog, motion, and thought. Keystrokes should be min- lated with this form of representation. For example, a display of holding
imized, the distance a mouse must travel between picks should be consid- tank pressure in an oil refinery would have little impact if a numeric rep-
ered in designing screen layout, the user should rarely encounter a situa- resentation were used. However, if a thermometer-like display were used,
tion where he or she asks, “Now what does this mean?” . vertical motion and color changes could be used to indicate dangerous pres-
Forgive mistakes. The should protect itself from errors that might sure conditions. This would provide the user with both absolute and rela-
cause it to fail. tive information.
Categorize activities by function and organize screen geography accord- Consider the available geography of the display screen and use it effi-
ingly. One of the key benefits of the pull-down menu is the ability to or- ciently. When multiple windows are to be used, space should be available
ganize commands by type. In essence, the designer should strive for “cohe- to show at least some portion of each. In addition, (a system en-
sive” placement of commands and actions. gineering issue) should be selected to accommodate the type of application
that is to be implemented.
Prouide help facilities that are context sensitive. See Section 14.9.3.
Use simple action verbs or short verb phrases to name commands. A
lengthy command name is more difficult to recognize and recall. It may
also take up unnecessary space in menu lists. Data Input
Much of the user’s time is spent picking commands, typing data, and otherwise
system input. In many applications, the keyboard remains the
14.10.2 Information Display
‘mary input medium, but the mouse, digitizer, and even voice recognition sys-
tems are rapidly becoming effective alternatives. The following guidelines focus
If information presented by the HCI is incomplete, ambiguous, on data input:
ble, the application will fail to satisfy the of a user. Information is “dis-
played” in many different ways: with text, pictures, and sound, by placement, Minimize the number of input actions required of the user. Above all, re-
motion, and size; and using color, resolution, and even omission. The following duce the amount of typing that is required. This can be accomplished by
guidelines focus on information display: using the mouse to select from sets of input, using a “sliding
scale” to specify input data across a range of values, and using macros that
Display only that information that is to the current context. The enable a single keystroke to be transformed into a more complex collection
user should not to wade through data, and graph- of input data.
ics to obtain information relevant to specific system function.
Maintain consistency between information display and data input. The vi-
Don’t bury the user with data, use a presentation format that enables rapid sual characteristics of the display (e.g., text size, color, and placement)
assimilation of information. Graphs or charts should replace voluminous should be carried over to the input domain.
tables. Allow the user to customize input. An expert user might decide to create
Use consistent labels, standard abbreviations, and predictable colors. The custom commands or dispense with some types of warning messages and
meaning of a display should be obvious without reference to some outside action verification. The HCI should allow this.
source of information. Interaction should be flexible but also tuned to the user’s preferred mode of
Allow the user to maintain visual context. If graphical representations are input. The user model will assist in determining which mode of input is
scaled up and down, the original image should be displayed constantly (in --preferred. A clerical worker might be very happy with keyboard input,
reduced form at the corner of the display) so that the user understands the while a manager might be more comfortable using a point and pick device
relative location of the portion of the image that is currently being viewed. such as a mouse.
Produce meaningful error messages. See Section 14.9.3. Deactivate commands that are inappropriate in the context of current ac-
Use upper and lower case, indentation, and text grouping to aid in under- tions. This protects the user from attempting some action that could
standing. Much of the information imparted by a HCI is textual, and the sult in an error.
layout and form of the text has a significant impact on the ease with which Let the user control the interactive flow. The user should be able to jump
information is assimilated by the user. unnecessary actions, change the order of required actions (when possible
‘TER A: DESIGN METHODS 407
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
The structured constructs were proposed to limit the procedural design of
in the context of an application), and conditions without
software to a small number of predictable operations. Complexity metrics
exiting from the program.
(Chapter indicate that the use of the structured constructs reduces program
Provide help to assist with input actions. See Section 14.9.3. complexity and thereby enhances readability, testability, and maintainability
Eliminate “mickey input. Do not require the user to specify units The use of a limited number of logical constructs also contributes to a human
for engineering input (unless there may be ambiguity). Do not require the understanding process that psychologists call To understand this
user to type .OO for whole number dollar amounts, provide default values process, consider how’ you are reading this page. You do not read individual let-
whenever possible, and never require the user to enter information that ters; rather, you recognize patterns or chunks of letters that form words or
can be acquired automatically or computed within the program. phrases. The structured constructs are logical chunks that allow a reader to
recognize procedural elements of a module rather than read the design or code
by line. is enhanced when readily recognizable logical
14.11 PROCEDURAL DESIGN forms are encountered.
Any program, regardless of application area or technical complexity, can be
designed and implemented using only the three structured constructs. It should
Procedural design occurs after data, architectural, and interface designs have be noted, however, that dogmatic use of only these constructs can sometimes
been established. In an ideal world, the procedural specification required to de- cause practical difficulties. Section 14.11.2 considers this issue in further de-
line algorithmic details would be stated in a natural language such as English. tail. ,
After all, members of a software development organization all speak a natural
language (in theory, at least), people outside the software domain could more
readily understand the specification, and no new learning would be required.
Unfortunately, there is one small problem. Procedural design must specify Graphical Design Notation
procedural detail unambiguously, and a lack of ambiguity in a natural language
is not natural. Using a natural language, we can write a set of procedural steps “A picture is worth a thousand words,” but it’s rather important to know which
in too many different ways. We frequently rely on context to get a point across. picture and which 1000 words. There is no question that graphical tools, such
We often write as if a dialog with the reader were possible (it isn’t). For these as the flowchart or box diagram, provide excellent pictorial patterns that read-
and many other reasons, a more constrained mode for representing procedural ily depict procedural detail. However, if graphical tools are misused, the wrong
detail must be used. picture may lead to the wrong software.
The was once the most widely used graphical representation for
procedural design. Unfortunately, it was the most widely abused method as well.
The flowchart is quite simple pictorially A box is used to indicate a pro-
Structured Programming
cessing step. A diamond represents a logical condition, and arrows show the
flow of control. Figure 14.17 illustrates the three structured
The foundations of procedural design were formed in the early 1960s and were cussed in Section 14.11.1. Sequence is represented as two processing boxes con-
solidified with the work of Edsgar Dijkstra and his colleagues nected by a line (arrow) of control. Condition, also called if-then-else is depicted
In the late 1960s Dijkstra and others proposed the use of a set of ex- as a decision diamond which if true causes then-part processing to occur, and
isting logical constructs from which any program could be formed. The con- if false, invokes else-part processing. Repetition is represented using two slightly
structs emphasized “maintenance of functional domain.” That is, each construct different forms. The do-while tests a condition and executes a loop task repet-
had a predictable logical structure, was entered at the top, and exited at the itively as long as the condition holds true. A repeat-until executes the loop task
bottom, enabling a reader to follow procedural flow more first, then tests a condition and repeats the task until the condition fails. The
The constructs are condition, and repetition. Sequence imple- selection (or construct shown in the figure is actually an extension
ments processing steps that are essential in the specification of any algorithm, of the if-then-else. A parameter is tested by successive decisions until a true
condition provides the facility for selected processing based on some logical oc- , condition occurs and a case part processing path is executed.
and repetition provides for looping. These three constructs are fun- The structured constructs may be nested within one another as shown in
damental to structured programming-an important procedural design Figure 14.18. In the figure, a repeat-until forms the then-part of an
nique. (shown enclosed by the outer dashed boundary). Another if-then-else forms the
else-part of the larger condition. Finally, the condition itself becomes a second
block in a sequence. By nesting constructs in this manner, a complex logical
schema may be developed. It should be noted that any one of the blocks in
little used but extremely important feature of structured programming is “proof of Figure 14.18 could reference another module, thereby accomplishing proce-
designs be correct they created. An introduction dural layering implied by program structure.
verification of design is presented in Chapter 25.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: DESIGN METHODS
First
Next
task
i
Sequence -
If-then
. Loop task
Loop task
condition
condition
FIGURE14.18.
Nesting
Do while Repeat until
control is impossible; (3) the scope of local global data can be easily de-
Repetition
termined; and recursion is easy to represent.
The graphical representation of structured constructs using the box dia-
gram is illustrated in Figure 14.19. The fundamental element of the diagram
is a box. To represent sequence, two boxes are connected bottom to top. To rep-
FIGURE 14.17. Flowchart constructs resent an if-then-else, a condition box is followed by a then-part box and
part box. Repetition is depicted with a bounding pattern that encloses the
process or to be repeated. Finally, selection is
general, only represented using the graphical form shown at the bottom right of the figure.
when an escape from a loops or nested conditions Like flowcharts, a box diagram is layered on multiple pages as processing
is required. More important, additional complication of all logical tests along elements of a module are refined. A “call” to a subordinate module can be rep-
the path of escape can cloud software control flow, increase the possibility of er- resented by a box with the module name enclosed by an oval.
ror, and have a negative impact on readability and maintainability. What can
we do?
The designer is left with two options: The procedural representation is
redesigned so that the “escape branch” is not required at a nested location in 14.11.3 Tabular Design Notation
the flow of control; or the structured constructs are violated in a controlled
manner; that is, a constrained branch out of the nested flow is designed. Option In many software applications, a module may be required to evaluate a com-
1 is obviously the ideal approach, but option 2 can be accommodated without plex combination of conditions and select appropriate actions based on these
violating of the spirit of structured programming. conditions. Decision tables provide a that translates actions and con-
Another graphical design tool, the box diagram, evolved from a desire to ditions (described in a processing narrative) into a tabular form. The table is
develop a procedural design representation that would not allow violation of to misinterpret and may even be used as a machine readable input to
the structured constructs. Developed by Nassi and Shneiderman and a table driven algorithm. In a comprehensive treatment of this design tool, Ned
extended by the diagrams (also called states
charts, N-S charts, or charts) have the following characteristics: (1)
domain (that is, the scope of repetition or an if-then-else) is well de- Some old software tools and techniques mesh well with new tools and tech-
fined and clearly visible as a pictorial representation; arbitrary transfer of niques of software engineering. Decision tables are an excellent example.
PART THREE- CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN
411
DECISION TABLE
First
1 2 3 4 5 9 10
I -
task
; I =
FIGURE14.20.
Decision table
FIGURE 14.19. the customer account is billed using a fixed rate method, a minimum
Box diagram con- monthly charge is assessed for consumption of less than 100 (kilo-
watt-hours). Otherwise, computer billing applies a Schedule A rate
ture. However, if the account is billed using a variable rate method, a
Schedule A rate structure will apply to below 100 with
Decision tables preceded software engineering by nearly a decade, but fit SO additional consumption billed according to Schedule B.
well with software engineering that they might have been designed for that
purpose.
Figure 14.21 illustrates a decision table representation of the preceding
narrative. Each of the five rules indicates one of five viable conditions (e.g., a
Decision table organization is illustrated in Figure 14.20. The table is di- (true) in both rate and variable rate account makes no sense in the
vided into four sections. The upper hand quadrant contains a list of all con- context of this procedure). As a general rule, the decision table can be
ditions. The lower left hand quadrant contains a list of all actions that are to supplement other procedural --
based on combinations of conditions. The right hand quadrants form a
that indicates condition combinations and the actions
that will occur for a specific combination. Therefore, each column of the matrix Program Design language
may be interpreted as a processing rule.
The following steps are applied to develop a decision table: Program Design Language also called structured English or pseudocode, is
“a pidgin language in that it uses the vocabulary of one language (i.e., English)
1. List all actions that can be associated with a specific procedure (or mod- and the overall syntax of another structured programming language)”
ule). In this chapter PDL is used as a generic reference for a design language.
2. List all conditions (or decisions made) during execution of the procedure. At first glance PDL looks something like any modern programming lan-
Associate specific sets of conditions with specific actions, eliminating im- guage. The difference between and a modern programming language lies
3.
possible combinations of conditions; alternatively, develop every possible in the use of narrative text (e.g., English) embedded directly within PDL state-
ments. Because narrative text is embedded directly into a syntactical structure,
permutation of conditions.
PDL cannot be compiled (at least not yet). However, PDL “processors” currently
4. rules by indicating what action or actions occur for a set of exist to into a graphical representation (e.g., a flowchart) of de-
. tions. sign and produce nesting maps, a design operation index, ta-
bles, and a variety of other information.
To illustrate the use of a decision table consider the following excerpt from A program design language may be a simple transposition of a language
a processing narrative for a public utility hilling system: such as Ada or C. Alternatively, it may be a product purchased specifically for
CHAPTER DESIGN METHODS 413
412 PART THREE: CONVENTIONAL METHODS FOR
Recall that PDL is not a programming language. The designer can adapt
1 2 3 4 as required without worry of syntax errors. However, the design for the moni-
Fixed toring software would have to be reviewed you see any problems?) and fur-
T F F F
ther refined before code could be written. The following PDL defines an elabo-
rate account F F ration of the procedural design for the security monitor procedure.
Conditions
Consumption KWH T F T F
PROCEDURE
KWH F T F T
INTERFACE RETURNS
Minimum monthly X TYPE signal IS STRUCTURE DEFINED
Schedule x x’ name IS STRING LENGTH
Actions address IS HEX device location;
FIGURE 14.21. B
bound.value IS upper bound SCALAR;
Resultant decision
x STRING VAR;
table
END signal TYPE;
IS BIT
procedural design. Regardless of origin, a design language should have the fol- TYPE DEFINED
lowing characteristics: IS INSTANCE OF signal;
IS INSTANCE OF signal;
!" a fixed syntax of that provide for all structured constructs, data de- IS INSTANCE OF signal;
clarations, and modularity characteristics; temp.alarm IS INSTANCE OF signal;
!"a free syntax of natural language that describes processing features; IS INSTANCE OF signal;
!" data declaration facilities that should include both simple (scalar, array) and TYPE phone.number IS area code + 7-digit number;
complex (linked list or tree) data structures; and
!"subprogram definition and calling techniques that support various modes of
interface description. Today, a high-order programming language is often initialize all system ports and reset all
used as the basis for a PDL. For example, Ada-PDL is widely used in the Ada CASE OF
community as a design definition tool. Ada language constructs and format WHEN cps = “test” SELECT
are “mixed” with English narrative to form the design language. CALL alarm PROCEDURE WITH
“on” for test.time in seconds;
A basic PDL syntax should include constructs for subprogram definition, WHEN cps = “alarm-off SELECT
interface description, and data declaration; and techniques for block structur- CALL alarm PROCEDURE WITH
ing, condition constructs, repetition constructs, and I/O constructs. The format “off;
and semantics for some of these PDL constructs are presented in the section WHEN cps = SELECT
that follows. CALL PROCEDURE;
It should be noted that PDL can be extended to include keywords for mul- WHEN cps = SELECT
titasking and/or concurrent processing, interrupt handling, interprocess syn- deactivate signal
chronization, and many other features. The application design for which PDL
is to be used should dictate the final form for the design language.
DEFAULT none;
A PDL Example
REPEAT UNTIL is turned off
reset all and switches;
To illustrate the use of PDL, we present an example of a procedural design for DO FOR = smoke, fire, water, temp, burglar;
the security system software in earlier chapters. The READ address
system in question monitors alarms for fire, smoke, burglars, water
IF bound
(flooding), and temperature (e.g., furnace breaks while home owner is away
THEN = message
during winter); produces an alarm signal; and calls a monitoring service, gen-
set to “on” for
erating a voice synthesized message. In the PDL that follows, we illustrate
some of the important constructs noted in Section 14.11.4.
PART THREE, CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: DESIGN METHODS
414 415
CALL alarm PROCEDURE WITH “on”, alarm.time in seconds, and open to debate. However, it appears that program design language offers
CALL PROCEDURE WITH message the best combination of characteristics. PDL may be embedded directly into
source listings, improving documentation and making design maintenance less
difficult. Editing can be accomplished with any editor or word-processing
ELSE skip automatic processors exist, and the potential for “automatic
code generation” is good.
it not inferior
to The pictorial nature of flowcharts and box diagrams provides perspec-
END tive on control flow that many designers prefer; the precise tabular content of de-
cision tables is an excellent tool for table driven applications; and many other de-
Note that the designer for the procedure has used a new sign representations (e.g., see not presented in this book,
construct PARBEGIN. that specifies a parallel block. All tasks offer their own unique benefits. In the final analysis, the choice of a design
specified the block are executed in parallel. In this case, im- may be more closely related to human factors than to technical attributes.
plementation details are not considered.
Program design language-is often used in conjunction with CASE design
tools in some cases overlay a graphical component on the procedural de- 14.12 SUMMARY
sign representation. For example, the control structure diagram
can be used in conjunction with either programming language source code or
PDL. The design text is augmented with graphical symbols that depict all im- Software design encompasses four distinct but interrelated activities: data de-
portant structured programming constructs and special language forms (e.g., sign, architectural design, interface design, and procedural design. When each
the Ada task or rendezvous). CSD notation is illustrated in Figure 14.22. of these design activities has been completed, a comprehensive design model
A natural question arises in any discussion of design notation: “What no- exists for the software.
tation is really the best?” Any answer to this question is admittedly subjective Data design translates the data objects defmed in the analysis model into
data structures that ruside within the software. The attributes that describe
duta the relationships between data objects, and their use within the
program all influence the choice of data structures.
The architectural design method presented in this chapter use information
flow characteristics described in the analysis model to derive program
(key : in A data flow is mapped into program structure using one of two
A : in mapping approaches-transform mapping and/or transaction mapping.
Wherefound : out integer) is Transform mapping is applied to an information flow that exhibits distinct
between incoming and outgoing data. The mapped a
structure that allocates control to input, processing, and output along three
low, high, middle : integer;
separately factored module hierarchies. Transaction mapping is applied when
begin a single information item causes flow to branch along one of many paths. The
:= 0; DFD is mapped into a structure that allocates control to a substructure that
low := acquires and evaluates a transaction. Another substructure controls all poten-
high := A’last; tial processing actions based on a transaction.
while = Interface design encompasses internal and external program interfaces
and (low = high) and the design of the user interface. Internal and external interface design are
-.--middle (low + high) 2; guided by information obtained from the analysis model. The user interface de-
if (Key then sign process begins with task analysis and modeling, a design activity that
high := middle 1; tines user tasks and using either a elaborative or object-oriented ap
(Key then Design issues such as response time, command structure, error
handling, and help facilities are considered, and a design model for the system
low := middle + 1;
is refined. A variety of implementation tools are used to build a prototype for
evaluation by the user. A set of generic design guidelines govern general inter-
:= middle; action, information display, and data entry.
FIGURE14.22. . end Design notation, coupled with structured programming concepts, enables
Control structure end loop; the designer to represent procedural detail in a manner that facilitates trans-
gram -end lation to code. Graphical, tabular, and textual notations are available.
416 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 14: DESIGN METHODS 417
The design methods presented in this chapter lead to a design model of the Myers, G., Composite Structured Design, Van Nostrand Reinhold, 1978.
software. Data structure is developed, program architecture is established, Myers, B.A., “User Interface Tools: Introduction and Survey,” IEEE
modules are defined, and interfaces are established. This blueprint for imple- Software, January 1989, 15-23.
mentation forms the basis for all subsequent software engineering work. Nassi, I., and B. Shneiderman, “Flowchart Techniques for Structured
Programming,” Notices, ACM, August 1973.
[NOR861 Norman, User Centered Systems Design,
REFERENCES Lawrence Jersey, 1986.
Peters, L.J., Software Design: Methods and Techniques, Press,
A.V., J. and Ullmann, Data Structures and Algorithms, New York, 1981.
Addison-Wesley, 1983. User Interface Design for Computer Systems, Press
Bohm, C., and G. Jacopini, “Flow Diagrams, Turing Machines and (Wiley), 1988.
Languages with Only Two Formation Rules,” vol. 9, no. 5, May Shaw, M., and D. Garlan, “Formulations and Formalisms in Software
1966, pp. 366371. Architecture,” Volume Notes in Computer Science,
Caine, S., and K. Gordon, “PDL-A Tool for Software Design,” in Springer-Verlag, 1995.
Computer Conference, AF’IPS Press, 1975, pp. 271-276. Shneiderman, B., Designing the User Interface, Addison-Wesley, 1987.
N., “A New Format for Flowcharts.” Software-Practice and I., Software Engineering, 3rd edition, Addison-Wesley,
Experience, vol. 4, no. 4, 1974, pp. 341-357 1989.
Cross, K.H. Chang, and “Grasp/Ada 95-Visualization Stevens, G. Myers, and L. Constantine, “Structured Design,” IBM
with Control Structure Diagrams,” Journal of Defense System Journal, 13, no. 2, 1974, pp. 115-139.
January 1996, vo1.9, no. 1, pp. Wasserman, A., “Principles of Systematic Data Design and Implemen-
Dahl, O., E. Dijkstra, and C. Structured Programming, Academic tation,” in Software Design Techniques, Freeman and A. Wasserman,
Press, 1972. 3rd ed., IEEE Computer Society Press, 1980, pp. 287-293.
Dean, T.R., and J.R. “A Syntactic Theory of Software Architecture,” Wirth, N., “Program Development by Refinement,” vol.
IEEE Software Engineering, vol. 21, no. pp. 14, no. 4, 1971, pp. 221-227.
[DEN731 Dennis, J.B., “Modularity,” in Advanced Course on Software Engineering, E., and L. Constantine, Structured Design, Prentice-Hall, 1979.
EL. Bauer Springer-Verlag, New York, 1973, pp. 128-182.
Dijkstra, E., “Programming Considered as a Human Activity,” in
1965 Congress, North Holland Publishing Co., 1965.
Dijkstra, E., “Structured Software Engineering, Concepts PROBLEMS AND POINTS TO PONDER
and J. Buxton et al. Van Nostrand Reinhold, 1976.
Dumas, J.S., Designing User Interfaces for Software, Prentice-Hall, 1988. 14.1. Write a three- to five-page paper presents guidelines for selecting data
Freeman, “The Context of Design, in Software Design Techniques, structures based on the nature of problem. Begin by delineating the classi-
3rd ed., Freeman and A. Wasserman IEEE Computer Society cal data structures encountered in software work and then describe criteria
Press, pp. for selecting from these for particular types of problems.
Gomaa, H., “A Software Design Method for Real Time Systems,”
14.2. Some designers contend that all data flow may be treated as transform ori-
vol. 27, no. 9, September 1984, pp. 938-949.
ented. Discuss how this contention will affect the software structure that is
Hurley, R.B., Decision Tables in Software Engineering, Van Nostrand derived when a transaction-oriented flow is treated as a transform. Use an
Reinhold, 1983.
example flow to illustrate important points.
[LEA881 Lea, M., “Evaluating User Interface Designs,” User Interface Design for
Computer Systems, Press (Wiley), 1988. 14.3. If you haven’t done so, complete problem 12.13 in Chapter 12. Use the de-
sign methods described in this chapter to develop a program structure for
Linger, R.C, H.D. Mills, and B.I. Witt, Structured Programming,
the PHTRS.
Wesley, 1979.
Monk, A. Fundamentals of Human-Computer Aca- 14.4. Propose an approach to the design of real-time software applications that
demic Press, 1984. makes use of data techniques. To begin your discussion, list
Moran, T.P., “The Command Language Grammar: A Representation for problems with real-time systems (e.g., interrupt driven) that make direct ap-
the User Interface of Interactive Computer Systems,” of plication of data design somewhat unwieldy.
Man-Machine Studies, vol. 15, pp. 3-50. 14.5. Using a data flow diagram and a processing narrative, describe a
Moriconi, M., X. Qian, and Riemenschneider, based system that has distinct transform flow characteristics. Define flow
Refinement,” IEEE Trans. Software Engineering, vol. 21, no. 4, April boundaries and map the DFD into a software structure using the technique
1995, pp. 356-372. described in Section 14.4.
14: DESIGN METHODS
418 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
14.6. Using a data flow diagram and a processing narrative, describe a
based that has distinct transaction flow characteristics. Define flow
and map the DFD into a software structure using the technique
described in Section 14.5.
14.7. Using requirements that are derived from a classroom discussion, complete
the and architectural design for the example presented in
Sections 14.4 and 14.5. Assess the independence of all modules.
For readers with a background in design: Develop a for a sim-
ple compiler, assess its overall flow characteristic, and derive a program
structure using the techniques described in this chapter. Provide proeessihg
narratives for each module.
How does the concept of modules that invoke them-
selves) tit into the design philosophy and techniques presented in this chap-
14.10. Using the shown in Figure 14.23, apply transaction analysis to the
DFD and derive a program structure. The overall flow characteristic should
be assumed to be transaction flow (with transaction center at transform
Flow in region I is transform; flow in region II is transaction, with trans-
form as shown; flow in region III is transform. Your program
ture should have modules that correspond on a one-to-one basis with the
transforms in the figure. It will be necessary to derive a number of control
modules.
14.11. Discuss the relative merits and difficulties of applying data flow-oriented
design in the following areas:
a. embedded microprocessor applications
b. engineering/scientific analysis
c. computer graphics
d. operating system design
e. business applications
f. database management system design
g. communications software design
h. design
i. process control applications
j. artificial intelligence applications
14.12, Given a set of requirements provided by your instructor (or a set of
quirements for a problem on which you are currently working) develop a
complete design including all design documentation. Conduct a design
view (Chapter to assess the quality of your design. This problem may as-
14.23. Problem 14.10
signed to a team, rather than an individual.
14.13. Describe the worst interface that you have ever worked with and critique it
relative concepts introduced in this chapter. Describe the an registration system for a university
that you have ever worked with and critique it relative to library management system
introduced in this chapter. a next generation polling booth for elections
Consider one of the following interactive applications: g. a home banking system
a. a desk-top publishing system an interactive application assigned by your instructor
b. a computer-aided design system model, a user model, a system image, and a system
an interior design system (as described in Section for any one of the above systems.
PART, THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
CHAPTER 14: DESIGN METHODS 421
14.15. Perform a detailed task analysis for any one of the systems listed in prob- 14.31. Develop a procedural design for an encryption/decryption algorithm of your
lem 14.14. Use an elaborative or object-oriented approach. choosing.
14.16. Continuing problem 14.15, apply the seven-step interface design process de- ,
scribed in this chapter.
14.17. Describe your approach to user help facilities for the design model and task
FURTHER READINGS AND OTHER INFORMATION SOURCES
analysis you have performed as part of problems 14.15 and 14.16.
14.18. Provide a few examples that illustrate why response time variability
can be a issue. Treatments of software design are contained in most books dedicated to soft-
ware engineering. More rigorous treatments of the subject can be found in Feijs
14.19. Develop an approach that would automatically integrate error messages and
(Formalization of Design Methods, Prentice-Hall, Witt et al., (Software
a user help facility. That is, the system would automatically recognize the Architecture and Design Principles, Thomson Publishing, and Budgen
error type and provide a help window with suggestions for correcting it.
(Software Design, Addison-Wesley, 1994).
Perform a reasonably complete software design that considers appropriate
Complete presentations of data flow-oriented design may be found in
data structures and algorithms.
Myers and Constantine Buhr (System Design
14.20. Develop an interface evaluation questionnaire that contains 20 generic ques- with Ada, Prentice-Hall, and Page-Jones (The Practical Guide to
tions that would apply to most interfaces. Have ten classmates complete the Structured Systems Design, 2nd edition, Prentice-Hall, 1988). These books are
questionnaire for an interactive system that you all use. Summarize the re- dedicated to design alone and provide comprehensive tutorials in the data flow
sults and report them to your class. approach.
14.21. Attempt to add at least five additional design guidelines to each category The literature on human-computer interfaces and human factors has
discussed in Section 14.10. over the decade. Books Thimbley (The User
14.22. An enormous literature has evolved on the topic of structured programming. Interface Design Addison-Wesley, Interface:
Write a brief paper that highlights the published arguments-pro and Concepts and Design,Addison-Wesley, Nielsen (Usability
about the exclusive use of structured constructs. Academic Press, Guide to Usability,Addison-Wesley,
Problems 23 to 31 may be represented using any one more) of the pro- and Lee (Object-Oriented GUI Application Development, Prentice-Hall, 1994)
cedural design notations that have been presented in this chapter. Your in- provide worthwhile treatments of the subject. Books by Rubinstein and Hersh
structor may assign specific notation to specific problems. (The Human Factor, Digital Press, Dumas (Handbook
14.23. Develop a procedural design for modules that implement the following sorts: of Human-Computer Interaction, Elsevier Science Publishers, and Laurel
Shell-Metsner sort; BSST (tree) sort. Refer to a book on data struc- (The Art of Human-Computer Interface Design, Addison-Wesley, 1990) each
tures if you are unfamiliar with these sorts. contain worthwhile lists of interface design guidelines. Norman Psychology
14.24. Develop a procedural design for an interactive user interface that queries of Everyday Things,Basic Books, 1988) uses examples from everyday life to
highlight good and bad design. He contends that good interface designs take
for basic income tax information. Derive your own requirements and assume account of our strong perceptual abilities, while bad interfaces fight against
that all tax computations are performed by other modules.
them.
14.25. Develop a procedural design for garbage collection function for a variable The work of Linger, Mills, and Witt (Structured Programming-Theory and
partitioned memory management scheme. Define all appropriate data struc- Practice, Addison-Wesley, 1979) remains a definitive treatment of the subject.
tures in the design representation. Refer to a book on operating systems for The text contains a good PDL as well as detailed of the ramifica-
more information. tions of structured programming. Other books that focus on procedural design
14.26. Develop a procedural design for a program that accepts an arbitrarily long issues include books by Bentley (Programming Pearls,Addison-Wesley, 1986,
text as input and produces a list of words and their frequency of occurrence and More Programming Pearls, Addison-Wesley, 1988) and Dahl, Dijkstra, and
output. (Structured Programming, Academic Press, 1972).
14.27. Develop a procedural design of a program that will numerically integrate a A collection of articles and commentary of software design methods can be
function fin the bounds a to found at the Web site for the Association for Software Design:
14.28. Develop a procedural design for a generalized Turing machine that will ac-
cept a set of quadruples as program input and produce output as specified.
14.29. Develop a procedural design for a program that will solve the Towers of
Hanoi problem. Many books on artificial intelligence discuss in A bibliography, pointers and advanced discussion of software architecture tech-
some detail. nology and a “Software Architecture Technology Guide” are available at:
14.30. Develop a procedural design for all or portions of an LR parser for a
compiler. Refer to one or more books on compiler design,
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
422
An on-line edition of Geo Wiederhold’s classic book (Database Design, 3rd
tion, McGraw-Hill, 1988) can be found at:
\
DESIGN FOR REAL-TIME
SYSTEMS
A brief tutorial, “Comments on Human Computer Interface Design,” can be
found at:
Lewis and Rieman have provided an on-line textbook (as shareware) entitled
Centered User Interface Design at:
An up-to-date list of World Wide Web references for design methods
can be found at:
he design of real-time computing systems is the most challenging and com-
plex task that can be undertaken by a software engineer. By its very na-
ture, for real-time systems makes demands on analysis, design, and
testing techniques that are unknown in other application areas.
Real-time is highly coupled to the external world. That is, real-
time software must respond to the problem domain (the real world) in a time
frame dictated by the problem domain. Because real-time software must oper-
ate under rigorous performance constraints, software design is often driven by
hardware as well as software architecture, operating
----- as application requirements;.prograinming vagaries as well as
design issues.
In his book on real-time software, Robert Glass provides a useful
introduction to the subject of real-time systems:
The digital computer is becoming ever more present in the daily lives of all of
us. Computers allow our watches to play games as well as tell time, optimize
the gas mileage of our latest generation cars, and sequence our appliances. . . .
industry, computers control machines, coordinate processes, and increas-
ingly, replace manual skills and human recognition with automated systems
and “artificial intelligence.“]
All these computing interactions-whether helpful or intrusive-are
examples of real-time computing. The computer is controlling that
interacts with reality on a timely basis. In fact, timing is the essence of the
interaction. , An unresponsive real-time system may be worse than no sys-
tem at all.
423
424 , PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 15: DESIGN FOR REAL-TIME SYSTEMS 425
No more than a decade ago, real-time development was consid-
15.2 REAL-TIMESYSTEMS’
ered a black art, applied by anointed wizards who guarded their closed world
with jealousy. Today, there aren’t enough wizards to go around! Yet, there is no
question that the engineering of real-time software requires special skills. In Real-time systems generate some action in response to external events. To ac-
this chapter we examine real-time software and discuss at least some of the complish this function, they perform high-speed data acquisition and control
skills that are required to build it. under severe time and reliability constraints. Because these constraints are so
stringent, real-time systems are frequently dedicated to a single application.
Real-time systems are used widely for diverse applications that include mil-
itary command and control systems, consumer electronics, process control, in-
15.1 SYSTEM CONSIDERATIONS dustrial automation, medical and scientific research, computer graphics, local
and wide area communications, aerospace systems, computer-aided testing, and
Like any computer-based system, a real-time system must integrate hardware, a vast array of industrial instrumentation.
software, human, and database elements to properly achieve a set of functional
and performance requirements. In Chapter 10, we examined the allocation task
for computer-based systems, indicating that the system engineer must allocate 15.2.1 Integration and Performance Issuer
function and performance among the system elements. The problem for real-
time systems is proper allocation. Real-time performance is often as important
as function, yet allocation decisions that relate to performance are often Putting together a real-time system presents the system engineer with difficult
cult to make with assurance. Can a processing algorithm meet severe timing hardware and software decisions. (The allocation issues associated with hard-
constraints, or should we build special hardware to do the job? Can an ware for real-time systems are beyond the scope of this book, see for
shelf additional information.) Once the software element has been allocated, detailed
tasking, and communication, or should we build a custom executive? Can spec- software requirements are established and a fundamental software design
ified hardware coupled with proposed software meet performance criteria? must be developed. Among many real-time design concerns are coordination be-
These and many other questions must be answered by the real-time system en- tween the real-time tasks, processing of system interrupts, I/O handling to en-
gineer. sure that no data are lost, specifying the system’s internal and external timing
A comprehensive discussion of all elements of real-time systems is beyond constraints, and ensuring the accuracy of its
the scope of this book. Among a number of good sources of information are Each real-time design concern for software must be applied in the context
and is important that we understand of system performance. In most cases, the performance of a real-time system is
each of the elements of a real-time system before discussing software analysis measured as one or more time related characteristics, but other measures such
and design issues. as fault-tolerance may also be used.
Everett defines three characteristics that differentiate real-time Some real-time systems are designed for applications in which only the re-
development from engineering efforts: sponse time or the data transfer rate is critical. Other real-time applications
require optimization of both parameters under peak loading conditions. What’s
more, real-time systems must handle their peak loads while performing a num-
!" The design of a real-time system is resource constrained.The primary resource
ber of simultaneous tasks.
for a real-time system is time. It is essential to complete a defined task within
a given number of CPU cycles. In addition, other system resources, such as Since the performance of a real-time system is determined primarily by the
system response time and its data transfer rate, it is important to understand
memory size, may be traded against time to achieve system‘objectives.
these two parameters. System response time is the time within which a system
!" Real-time systems are compact, yet complex.’ Although a sophisticated real- must detect an internal or external event and respond with an action.
time system may contain well over a million lines of code, the time-critical event detection and response generation are simple. It is the processing of the
portion of the software typically represents a very small percentage of the to- information about the event to determine the appropriate response that may
tal. It is this small percentage of code that is the most complex (from an al- involve complex, time-consuming algorithms.
gorithmic point of view). Among the key parameters that affect the response time are context switch-
! " R e a l - t i m e s y s t e m s o f t e n w o r k w i t h o u t t h e p r e s e n c e o f a h u m a n u s e r .Therefore, ing and interrupt latency. Context switching involves the time and overhead to
real-time software must detect problems that lead to failure and automati- switch among tasks, and interrupt latency is the time lag before the switch is
cally recover from these problems before damage to data and the controlled
environment occurs.
In the section that follows, we examine some of the key attributes that differ- on an article, ‘Real-Time by H.J. and W.B.
entiate real-time systems from other types of computer software. Reproduced with permission of Electronic and Publishing.
426 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN FOR REAL-TIME SYSTEMS 427
actually possible. Other parameters that affect response time the speed of “Normal”
computation and the speed of access to mass storage. processing
The data transfer indicates how fast serial or parallel data, as well as flow
analog or digital data, must be moved into or out of the system. Hardware ven-
dors quote timing and capacity values for performance characteristics. Interrupt handling
However, hardware specifications for performance are usually measured
lation and are often of little value in determining overall real-time system per- . Save state of interrupted
formance. Therefore, device Bus latency, buffer size, disk per- program
formance, and a host of other factors, although important, are only part of the
story of real-time system design. !" Determine nature of the
Real-time are often required process a continuous stream of in- interrupt.
coming data. Design must ensure that data are not missed. In addition, a real-
time system must respond to events that are asynchronous. Therefore, the ar- !" Service
rival sequence and data volume cannot be easily predicted in advance. !" Restore state of interrupted
Although all software applications must be reliable, real-time systems program
make special demands on reliability, restart, and fault recovery. Because the
real world is being monitored and controlled, loss of monitoring or control (or !" Return interrupted program.
both) is intolerable in many circumstances (e.g., an air control system). FIGURE 15.1.
Consequently, real-time systems contain restart and fault-recovery mecha- Interrupts
nisms, and frequently have built-in redundancy to ensure backup.
The need for reliability, however, has spurred an ongoing debate about
whether on-line systems, such as airline reservation systems and automatic may be established. If a lower-priority process is accidentally allowed to inter-
bank tellers, also qualify as real-time. On one hand, such on-line systems must rupt, a higher-priority one, it may be to restart the processes in the
respond to external interrupts within prescribed response times on the order of right order and an endless loop may result.
one second. On the other hand, nothing catastrophic occurs if an on-line system To handle interrupts and still meet the system time constraints, many
fails to meet response requirements; instead, only system degradation results. time operating systems make dynamic calculations to determine whether the
system goals can be met. These dynamic calculations are the average
frequency of occurrence of events, the amount of time it takes to service them
15.2.2 Interrupt Handling (if they can be serviced), and the routines that can interrupt them and tem-
porarily prevent their servicing.
If the dynamic calculations show that it is impossible to handle the events
One characteristic that serves to distinguish real-time systems from any other
that can occur in the system and still meet the time constraints, the system
type is interrupt handling. A real-time system must respond to external . .
a
tiple stimuli (interrupts) are often present, priorities and priority interrupts
must be established. In other words, the most important task must always be Interrupt priority level,
serviced within time constraints regardless of other events.
Interrupt handling entails not only storing information so that the com-
puter can the interrupted task, but also avoiding deadlocks
and endless The overall approach to interrupt handling is illustrated in Normal
Figure 15.1. Normal processing flow is “interrupted” by an event that is de- Level 1 interrupt
tected by processor hardware. An is any occurrence that requires imme- service level 1
diate service and may be generated by either hardware or software. The state
of the interrupted program is saved (i.e., all register contents, control blocks,
etc. are saved) and control is passed to an interrupt service- routine that Level 3 interrupt
branches to appropriate software for handling the Upon completion
of interrupt servicing, the state of the is restored and normal pro-
cessing flow continues. 1 service level 3
FIGURE15.2.
In many situations, interrupt servicing for one event may itself be inter- A -
An example of inter-
rupted by another, higher-priority event. levels 15.2) rupt priority levels
428 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING DESIGN FOR REAL-TIME SYSTEMS
must decide on a plan of action. One possible approach involves buffering the Today, two broad classes of operating systems are used for real-time work:
data so that it can be processed quickly when the system is ready. (1) dedicated RTOS designed exclusively for real-time applications and (2) gen-
eral-purpose operating systems that have been enhanced to provide real-time
capability. The use of a real-time executive makes real-time performance feasi-
ble for a general-purpose operating system. Behaving like application software,
15.2.3 Real-Time Data Bases the executive performs a number of operating system functions-particularly
those that affect real-time performance-faster and more efficiently than the
Like many data processing systems, real-time systems often are coupled with general-purpose operating system.
a database management function. However, distributed databases would seem All operating systems must have a priority scheduling mechanism, but
to be a preferred approach in real-time systems because multitasking is com- RTOS must provide a priority mechanism that allows high-priority interrupts
monplace and data are often processed in parallel. If the database is distrib- to take precedence over less important ones. Moreover, because interrupts oc-
uted, individual tasks can access their data faster and more reliably, and with cur in response to asynchronous, nonrecurring events, they must be serviced
fewer bottlenecks than with a centralized database. The use of a distributed without first taking time to swap in a program from disk storage. Consequently,
database for real-time applications divides input/output “traffic” and short- to guarantee the required response time, a real-time operating system must
ens queues of tasks waiting for access to a database. Moreover, a failure of one have a mechanism for memory locking-that is, locking at least some programs
database will rarely cause the failure of the entire system, if redundancy is in main memory so that swapping overhead is avoided.
built in. To determine which kind of real-time operating best matches an ap-
The performance efficiencies achieved through the use of a distributed plication, measures of RTOS quality can be defined and evaluated. Context
database must be weighed against potential problems associated with data par- switching time and interrupt latency (discussed earlier) determine
titioning and replication. Although data redundancy improves response time by handling capability, the most important aspect of a real-time system. Context
providing multiple information sources, replication requirements for distrib- switching time is the time the operating system takes to store the state of the
uted files also produce logistical and overhead problems, since all the copies computer and the contents of the registers so that it can return to a process-
must be updated. In addition, of distributed databases introduces the ing task after servicing the interrupt.
problem of concurrency control. Concurrency control involves synchronizing the Interrupt latency, the maximum time lag before the system gets around to
databases so that all copies have the correct, identical information free for ac- switching a task, occurs because in an operating system there are often
cess. reentrant or critical processing paths that must be completed before an inter-
The conventional approach to concurrency control is based on what are can be processed.
known as locking and time stamps. At regular intervals, the following tasks’are The length of these paths (the number of instructions) before the system
initiated: The database is “locked” so that concurrency control is assured; no can service an interrupt indicates the worst-case time lag. The worst case
curs if a high-priority interrupt is generated immediately the system en-
is permitted; updating occurs as required; the database is unlocked;
files are validated to ensure that all updates have been correctly made; ters a critical path between an interrupt and interrupt service. If the time is
the completed update is acknowledged. All locking tasks are monitored by a too long, the system may miss data that are unrecoverable. It is important that
master clock (i.e., time stamps). The delays involved in these procedures, as the designer know the time lag so that the system can compensate for it.
well as the problems of avoiding inconsistent updates and deadlock, militate Many operating systems perform multitasking or concurrent
against the widespread use of distributed databases processing, another major requirement for real-time systems. But to be viable
for real-time operation, the system overhead must be low in terms of switching
Some techniques, however, have been developed to speed updating and to
solve the concurrency problem. One of called the proto- time and memory space used.
col maintains the consistency of replicated files by allowing only a single, ex-
clusive writing task to a It high overhead
of locking or time stamp 15.2.5 Real-Time languages
Because of the special requirements for performance and reliability demanded
15.2.4 Real-Time Operating Systems of real-time systems, the choice of a programming language is important. Many
general-purpose programming languages (e.g., C, can be
for real-time However, a of “real-
Some real-time operating systems are applicable to a broad range of
time languages” (e.g., Ada, Jovial, Chill, and others) is often used in
system configurations, while others are geared to a particular board or even.
microprocessor, regardless of the surrounding electronic environment. RTOS cialized military and communications applications.
achieve their capabilities through a combination of software features and (in- A combination of characteristics makes a real-time language different from
creasingly) a variety of micro-coded capabilities implemented in hardware. a general-purpose language. These include the multitasking capability,
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER I 5. FOR R EAL -TIME SYSTEMS 431
to directly implement real-time functions, and modern programming !"interrupt handling and context switching
features that help ensure program correctness. !" response time
A programming language that directly supports multitasking is important
!" data transfer rate and throughput
because a real-time system must respond to asynchronous events. Although
many RTOS provide multitasking capabilities, embedded real-time software of- !"resource allocation and priority handling
ten exists without an operating system. Instead, embedded applications are !" task synchronization and intertask communication
written in a language that provides sufficient run-time support for real-time
program execution. Run-time support requires less memory than an operating
Each of these performance attributes can be it is extremely dif-
system, and it can be tailored to an application, thus increasing performance. ficult to verify whothcr system elements will achieve desired response, system
resources will be sufficient to satisfy computational requirements, or process-
ing algorithms will execute with sufficient speed.
15.2.6 Task Synchronization and Communication The analysis of real-time systems requires modeling and simulation that
enables the system engineer to assess “timing and sizing” issues. Although a
number of analysis techniques have been proposed in the literature (e.g.,
A multitaskingsystem must furnish a mechanism for the tasks to pass infor- and it is fair to state that analytical approaches
mation to each other as well as to ensure their synchronization. For these func- for the analysis and design of real-time systems are still in their early stages
tions, operating systems and languages with run-time support commonly use of development.
queuing semaphores, mailboxes, or message systems. A semaphore enables con-
current tasks to be synchronized. It supplies synchronization and signaling but
contains no information. Messages are similar to semaphores except that they
carry the associated information. Mailboxes, on the other hand, do not signal
15.3.1 Mathematical Tools for Real-lime System Analysis
information but instead contain it.
Queuing semaphores are software primitives that help manage traffic. They
provide a method of directing several queues-for example, queues of tasks A set of mathematical tools that enable the system engineer to model real-time
waiting for resources, database access, and devices, as well as queues of the re- system elements and assess timing and sizing issues has been proposed by
sources and devices. The semaphores coordinate the waiting Thomas McCabe Based loosely on data flow analysis techniques
tasks with whatever they are waiting for without letting tasks or resources in- (Chapter McCabe’s approach enables the analyst to model both hardware
terfere with each other. and software elements of a real-time system; represent control in a probabilis-
In a real-time system, semaphores are commonly used to implement and tic manner; and apply network analysis, queuing and graph theory, and a
manage mailboxes. Mailboxes are temporary storage places (also called a Markovian mathematical model to derive system timing and resource
pools or for messages sent from one process to another. One process sizing. Unfortunately, the mathematics involved is beyond the scope of this
produces a piece of information, puts it in the mailbox, and then signals a con- book, making a Retailed explication of McCabe’s work difficult. However, an
suming process that there is a piece of information in the mailbox for it to use. overview of the technique will provide a worthwhile view of an analytical ap-
Some approaches to real-time operating systems or run-time support sys- proach to the engineering of real-time systems.
tems view mailboxes as the most efficient way to implement communications McCabe’s real-time analysis technique is predicated on a data flow model
between processes. Some real-time operating systems furnish a place to send of the real-time system. However, rather than using a DFD in the conventional
and receive pointers to mailbox data. This eliminates the need to transfer all manner, McCabe contends that the transforms (bubbles) of a DFD can
of the data-thus saving time and overhead. be represented as process states of a Markov chain probabilistic queuing
A third approach to communication and synchronization among processes model) and the data flows themselves represent transitions between the process
is a message system. With a message system, one process sends a message to states. The analyst can assign transitional probabilities to each data flow path.
another. The latter is then automatically activated by the run-time support sys- As shown in Figure 15.3, a value,
tem or operating system to process the message. Such a system incurs over-
head because it transfers the actual information, but it provides greater flexi-
bility and ease of use. may be specified for each flow path, where represents the probability that
flow will occur between process i and The processes correspond to in-
formation transforms (bubbles) in the DFD.
Each process in the DFD-like model can be given a “unit cost” that repre-
15.3 ANALYSIS AND SIMULATION OF REAL-TIME SYSTEMS sents the estimated (or actual) execution time required to perform its function
and an “entrance value” that depicts the number of system interrupts corre-
In the preceding section, we discussed a set of dynamic attributes that cannot sponding to the process. The model is then analyzed using a set of mathemat-
be divorced from the functional requirements of a real-time system: ical tools that compute the expected number of visits to a process, (2) the
432 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
arrival rate
unit = 4.6
FIGURE 15.3.
a queuing
network model
time spent in the system when processing begins at a specific process, and
the total time spent in the system.
To illustrate the McCabe technique on a, realistic example, we consider a
DFD for an electronic countermeasures system shown in Figure 15.4. The data
flow diagram takes the standard form, but data flow identification has been re-
placed A queue network model is derived from the DFD is shown in Figure
15.5. The values lambda correspond to the arrival rate (arrivals per second)
at each process. Depending on the type of queue encountered, the analyst must
determine statistical information such as the mean service rate (mean run-time
per process), variance of service rate, variance of arrival rate, and so forth.
The arrival rates for each process are determined using the flow path
and the arrival rate into the system, A set of flow balance equa-
tions are derived and solved simultaneously to compute the flow through each
process. For the example shown in Figure 15.5, the following flow balance equa-
tions result
= =
=
For the shown and an arrival rate, = 5 arrivals per second, the above
equations can be solved to yield:
A, = 8.3
= 5.6
= 5.4
CHAPTER FOR SYSTEMS
= 3.3
= 8.3
= 8.3
5.0
Once the arrival rates have been computed, standard queuing theory can be
used to compute system timing. Each subsystem queue, Q, and a server,
may be evaluated using formulas that correspond to the queue For
queues
utilization: =
expected queue length: =
expected number in subsystem: =
expected time in queue:
expected time in subsystem: =
where is completion rate Applying standard queuing net-
work reduction rules, illustrated in Figure 15.6, the original queuing network
(Figure 15.5) derived from the data flow diagram (Figure 15.41 can be
tied by applying the steps shown in Figure 15.7. The total time in the
system is 2.37 seconds.
Obviously, the accuracy of McCabe’s analysis approach is only as good as
estimates for probability, arrival rate, and completion rate. However,
benefit can be achieved by taking a more analytical view of real-time
systems during analysis. To quote McCabe
By changing such variables as arrival rates, interrupt rates, splitting probabil-
ities, priority structure, queue discipline, configurations, requirements, physi-
cal implementation and variances we can easily show the program manager
what affect it will have on the system at hand. These iterative methodologies
are necessary to fill a void in real-time specification modeling.
153.2 Simulation and Modeling Techniques
Mathematical analysis of a real-time system represents one approach that can
be used to understand projected performance. However, a growing number of
real-time software developers use simulation and modeling tools that not only
analyze a system’s performance, but also enable the software engineer to build
a prototype, execute it, and thereby gain an understanding of a system’s be-
havior.
The overall rationale behind simulation and modeling for real-time sys-
tems is discussed by i-Logix (a company that develops tools for systems
engineers):
436 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 15: DESIGN FOR SYSTEMS
437
(a) Series rule--The arrivals are by the subsystem in series.
= Time in system (delay)
= +
arrivals are served the subsystem in parallel. Step Further abstracted queuing network
Step 2. Equivalent queuing
all possible paths through the network
= probability of entering the server 1 system.
= probability of entering the server 2 system.
FIGURE 15.7.
Simplifying the
queuing network Step 3. Final reduction
ing the implementation model, the system engineer can see how the system as
specified would behave if implemented.
FIGURE 15.6. The i-Logix approach makes use of a notation that combines three
Queuing network different views of a system: the activity-chart, the module-chart, and the
reduction rules chart. In the paragraphs that follow, approach to real-time system
simulation and modeling is ,
The Conceptual View
The understanding of a system’s behavior in its environment over time is
most often addressed in the design, implementation and testing phases of a Functional issues are treated using activities that represent the processing
project, through iterative trial and error. The Statemate system engineering nabilities of the system. Dealing with a customer’s confirmation request in an
tool for simulation and modeling1 approach provides an alternative to this airline reservation system is an example of an activity, as is updating the air-
costly process. It allows you to build a comprehensive system model that is ac- craft’s position in an avionics system. Activities can be nested, forming a hier-
curate enough to be relied on and clear enough to be useful. The model ad- archy that constitutes a functional decomposition of the system. Items of
dresses the usual functional and flow issues, but also covers the dynamic, be-
havioral aspects of a system. This thr
analysis and retrieval tools, which provide extensive mechanisms for inspect- that adapted from which describes is
ing and debugging the and information from it. By with permission of Inc.
PART THREE: CONVENTIONAL METHODS FOR ENGINEERING CHAPTER 15. FOR REAL-TIME SYSTEMS
formation, such as the distance to a target or a customer’s name, will typically
WATCH
flow between activities and might also be kept in data stores. This functional
view of a system is captured with which are similar to conven-
tional data flow diagrams.
Dynamic behavioral issues, commonly referred to as control aspects, are
treated using a notation developed by Hare1 and his colleagues [in
Here, states (or modes) can be nested and linked in a num-
ber of ways to represent sequential or concurrent behavior. An avionics mission
computer, for example, could be in one of three states: air-to-air, air-to-ground, or
navigation. At the name time it must in the of either automatic or man-
ual flight control. Transitions between states are typically triggered by
which may be qualified by conditions. Flipping a certain switch on the throttle,
for example, is an event that will cause a transition from the navigate state
the air-to-ground state, but only on condition that the has air-to-ground
ammunition watch in
16.8. the watch is shown in Figure 15.9. I
two of a system intogratod in tho I LIGHT
with each level of an activity-chart, there will usually be a statechart, a
control activity, whose role is to control the activities and data flows of that
level [this is similar in some ways to the relationship between flow models and
CSPEC described in Chapter 12). A statechart is able to exercise control over
the activities. For example, it can instruct activities to start and and to
suspend and resume their work. It is able to change the values of variables and
thus to influence the processing carried out by the activities. It is also able to
send signals to other activities and thus cause them to change their own be-
havior. In addition to being able to generate actions, a controlling statechart is
[not in (STOPWATCH)]
able to sense being carried out by other statecharts. For example,
if one statechart starts an activity or increments the value of a variable, an- ALARM ST
other can sense that event and use it, say, to trigger a transition,
DIGITAL WATCH
FIGURE 15.9. for digital prototype (courtesy
It is important to realize that activity-charts and statecharts are strongly
linked, but they are not different representations of the same thing.
charts on their own are incomplete as a model of the system, since they do not
address behavior. Statecharts are also incomplete, since without activities they
have nothing to control. Together, a detailed activity-chart and its controlling
statecharts provide the conceptual model. The activity-chart is the backbone of
the model; its decomposition of the capabilities of the system is the dominant
hierarchy of the specification, and its controlling statecharts are the driving
force behind the system’s behavior.
FIGURE 15.8.
Digitalwatch Physical View
A specification that uses activity-charts and in the form of a
tual model is an excellent foundation, but it is not a real system. What is miss-
440 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 15: DESIGN FOR SYSTEMS 441
\
ing is a means for describing a physical (implementation) ified to reflect proper behavior; and iteration occurs until the system that
nnd means to sure that the is implemented in a way that is desired evolves.
is true to that specification. An important part of this is describing the physical The system engineer runs scenarios and views the system’s response graph-
decomposition of the system and its relationship to the conceptual model. ically. “Active” elements of the model (e.g., states that the system is in at the
The physical aspects are treated in Statemate using the language of mod- moment and activities that are active) are highlighted graphically, and the dy-
ule-charts. The terms “physical” and “module” are used generically to denote namic execution results in an animated representation of the model. The exe-
components of a system, hardware, software, or hybrid. Like activities cution of a scenario simulates the system running in real time and keeps track
in an activity-chart, modules are arranged in a hierarchy to show the decom- of time-dependent information. At any point during the execution, the engineer
position of a system into its components and subcomponents. Modules are con- can ask to see the status of any other, nongraphical, element, such as the value
nected by flow lines, which one can think of as being the carriers of informa- of a variable or a condition.
tion between modules.
Programming Simulations
Analysis and Simulation
A scenario enables the system engineer to exercise the model interactively. At
Once we have constructed a conceptual model, consisting of an activity-chart times, however, more extensive simulation may be desirable. Performance un-
and its controlling statecharts, it can be thoroughly analyzed and tested. The der random conditions in both typical and atypical situations may need to be
model might describe the entire system, down to the lowest level of detail, or For situations in which a more extensive simulation of a real-time
it might be only a partial specification. model is desired, Simulation Control Language enables the engineer to
We must first be sure that the model is syntactically correct. This gives rise retain general control over how the executions proceed, but at the same time
to many relatively straightforward tests: for example, that the various charts exploits the power of the tool to take over many of the details.
are not blatantly incomplete (e.g., missing labels or names, dangling arrows); One of the simplest things that can be done with SCL is to read lists of
that the definitions of nongraphical elements, such as events and conditions, events from a batch file. This means that lengthy scenarios or of them
employ legal operations only, and so on. Syntax checking also involves more can be prepared in advance and executed automatically. These can be observed
subtle tests, such as the correctness of inputs and outputs. A example of this is by the system engineer. Alternatively, the system engineer can program with
a test for elements that are used in the statechart but are neither input nor af- SCL to set break points and to monitor certain variables, states, or conditions.
fected internally, such as a power-on event that is meant to cause a transition For example, running a simulation of an avionics system, the engineer might
in the statechart but is not defined in the activity-chart as an input. All of these ask the SCL program to stop whenever the radar locks on target and switch to
are usually referred to as consistency and completeness tests, and most of them interactive mode. Once “lock on” is the engineer takes over inter-
are analogous to the checking carried out by a compiler prior to the actual com- actively, so that this state can be in more detail.
pilation of a programming language. The use of scenarios and simulations also enables the engineer to gather
meaningful statistics about the operation of the system that is to be built. For
Running Scenarios example, we might want to know how many times, in a typical flight of the air-
craft, the radar loses a locked-on target. Since it might be difficult for the
A syntactically correct model accurately describes system. However, it
might not be the system we had in mind. In fact, the system described might be gineer to put together a single, all-encompassing flight scenario, a programmed
simulation can be developed using accumulated results from other scenarios to
seriously flawed-syntactic correctness does not guarantee correctness of func-
tion or behavior. The real objective of analyzing the model is to find out whether obtain average-case statistics. A simulation control program generates random
it truly describes the system that we want. The analysis should enable us to events according to predefined probabilities. Thus, events that occur very rarely
(say, seat ejection in a fighter aircraft) can be assigned very low probabilities
learn more about the model that has been constructed, to examine how a sys-
while others are assigned higher probabilities, and the random selection of
tem based on it would behave, and to verify that it indeed meets expectations.
events thus becomes realistic. In order to be able to gather the desired statis-
This requires a modeling language with more than a formal syntax. It requires
tics, we insert appropriate break points in the SCL program.
that the system to create the model recognize formal semantics as well.
If the model is based on a formal semantics, the system engineer can exe- Automatic Translation Into Code
cute the model. can and run a that. him to
of ho ix ac- Once the systemmodel it can be translated in its entirety into
tually built. Lo using a function. and their control-
(ATM) the occur: a conceptual model is the en- ling statecharts can be translated into a high-level programming language,
,
Lhc such Ada or C. Today, primary of resulting code is to observe a
such as insertion of a bank card, buttons being pressed, and new balance in- system perform under circumstances that are as close to the real world as pos-
formation arriving; the reaction of the system to these events is monitored sible. For example, the prototype code can he executed in a full-fledged simu-
in is lator of or in The code
FOR 443
442 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
by such tools should be considered to be “prototypical.” It is not enabled and executed. As a result of this action, the state is modified and
production or final code. Consequently, it might not always reflect accurate a second action occurs. several actions can occur in any given
real-time performance of the intended system. Nevertheless, it is useful for state, different results (histories) can be spawned from the same initial
testing the system’s performance in close to real circumstances. state. “This nondeterminism is essential in interleaved modeling of con-
currency”
Nonterminating histories and fairness. The processing history of a re-
REAL-TIME DESIGN active system is assumed to be infinite, By this we mean that processing
continues indefinitely or “stutters” until some event causes it to continue
The design of real-time software must incorporate all of the fundamental con- processing. Fairness requirements prevent a system from stopping at some
cepts and principles (Chapter associated with high-quality software. In ad- arbitrary point.
dition, real-time software poses a set of unique problems for the designer: A
Closed system principle. design model of a real-time system should
encompass the software and the environment in which the software re-
representation of interrupts and context switching sides. “Actions can therefore be partitioned into those for which the system
concurrency as manifested by multitasking and multiprocessing itself is responsible, and to those that are assumed to be executed by the
environment”
intertask communication and synchronization
A
Structuring of state. real-time system can be modeled as a set of ob-
wide variations in data and communication rates jects,” each of which has a state of its own.
representation of timing constraints
asynchronous processing The software engineer should consider each of the concepts noted above as the
necessary and unavoidable coupling with operating systems, hardware, and design of a real-time system evolves.
other external system elements Over the past two decades, a number of real-time software design methods
have been proposed to grapple with some or all of the problems noted above.
Some approaches to real-time design extend the design methods discussed in
It is worthwhile to address a set of specialized design principles that are par-
Chapters 14 and 21 (e.g., data flow data structure
ticularly the design of real-time systems.
or object-oriented methods). Others introduce an entirely separate ap-
discusses the design model for real-time (“reactive”) software:
proach, using finite state machine models or message passing systems, Petri
nets, or a specialized language as a basis for design. A comprehensive discus-
All reasoning, whether formal or intuitive, is performed with some abstraction. sion of software design for real-time systems is beyond the scope of this book.
Therefore, it is important to understand which kinds of properties are ex- For further details, the reader should refer to and
pressible in the abstraction in question. In connection with reactive systems,
this is emphasized by the more stringent need for formal methods, and by the
fact that no general consensus has been reached about the models that should
be used. Rigorous formalisms for reactive systems range from process algebras 15.5 SUMMARY
and temporal to concrete stats-based models and Petri nets, and differ-
ent schools keep arguing about their relative merits. The design of real-time software encompasses all aspects of conventional soft-
ware design while introducing a new set of design criteria and concerns. Because
He then defines a number of “modeling principles” that should be considered real-time software must respond to real-world events in a time frame dictated
in the design of real-time software by those events, all classes of design become more complex.
It is difficult, and often impractical, to divorce software design from larger
Explicit atomicity. It is necessary to define “atomic actions” explicitly as system-oriented issues. Because real-time software is either clock or event dri-
part of the real-time design model. An atomic action or event is a well-con- ven, the designer must consider function and performance of hardware and
strained and limited function that can be executed by a single task or ex- software. Interrupt processing and data transfer rate, distributed databases
ecuted concurrently by several tasks. An atomic action is invoked only by and operating systems, specialized programming languages and synchroniza-
those tasks (“participants”) that require it, and the results of its execution tion methods are just some of the concerns of the real-time system designer.
affect only those participants; no other parts of the system are affected.
Interleaving. Although processing can be concurrent, the history of some
computation should be characterized in a way that can be obtained by a
linear sequence of actions. Starting with an initial state, a action is “See PartFour of this book.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 445
CHAPTER 15: DESIGN FOR REAL-TIME SYSTEMS
The analysis of real-time systems encompasses both mathematical mod- McCabe, T.J. et al., “Structured Real-Time Analysis and Design,”
eling and simulation. Queuing and network models enable the system engi- IEEE, October 1985, pp. 46-51.
neer to assess overall response processing rate and other timing and siz- Savitsky, S., Real-Time Microprocessor Systems, Van Nostrand Reinhold,
ing issues. Formal analysis tools provide a mechanism for real-time system 1985.
simulation. lSEL941 B., Gullekson, and P. Ward, Real-Time Object-Oriented Modeling
Software design for real-time systems can be predicated on a conventional Wiley,
design methodology that extends data flow-oriented or object-oriented design Shumate, K., and M. Keller, Software Specification and Design-A
by providing a notation and approach that addresses real-time system charac- Disciplined Approach For Real-Time Systems, Wiley 1992.
teristics. Alternatively, design methods that make use of unique notation or Ward, P.T., and S.J. Mellor, Structured Development for Real-Time
specialized languages can also be applied. volumes, Press, 1985, 1986.
Software design for real-time systems remains a challenge. Progress has Wilson, R.G., and B.H. Krogh, Petri Net Tools for the Specification and
been made; methods do exist, but a realistic assessment of the state-of-the-art Analysis of Discrete Controllers,” IEEE Trans. Software Engineering,
suggests much remains to be done. vol. 16, no. 1, January 1990, pp.
Wood, M., and T. Barrett, “A Real-Time Primer,” Embedded Systems
Programming, vol. 3, no. 2, February 1990, pp.
Zucconi, L., “Techniques and Experiences in Capturing Requirements
REFERENCES
for Real-Time Systems, ACM Software Engineering Notes, vol. 14, no. 6,
October 1989, pp. 51-55.
K.S., Developing Real-Time Embedded Software in a Market I ’
Company, Wiley, 1994.
[EVE951 Everett, W.W., “Reliability and Safety of Real-Time Systems, Computer,
PROBLEMS AND POINTS TO PONDER
May 1995, pp.
Glass, Prentice-Hall,
II., 15.1. of what “stimuli”
and or situations controls or monitors
Gross, D., and CM. Harris, of Queuing Theory, 2nd edi- 15.2. Obtain information on a commercial real-time operating system and
tion, Wiley, 1985. write a short paper that presents a discussion of RTOS internals. What spe-
Harel, D., “On Visual Formalisms,” ACM, vol. 31, cial features are present? How are interrupts handled? How does the RTOS
no. 5, May 1988, pp. effect task synchronization?
D. et al., “STATEMATE: A Working Environment for the 16.3. Write a brief comparison of the real-time constructs in the programming lan-
Development of Complex Reactive Systems,” IEEE Trans. Software guages Ada and Modula-2. Do these constructs provide distinct benefits over
Engineering, vol. 16, no. 3, April 1990, pp. other languages such as C or Pascal?
D., “Biting Toward a Brighter Future for System
16.4. Provide three examples in which semaphores would be an appropriate task
Development,” Computer, January 1992, pp. 8-24.
synchronization mechanism.
Hatley, D.J., and LA. Pirbhai, Strategies for Real-Time System
15.5. The analysis technique for real-time systems presented in Section 15.3 as-
Specification, Dorset House, 1987.
sumes a knowledge of queuing models. Do some research using the references
H.J., and ‘Real-Time Systems,” Electronic
indicated and:
Design, January 6, 1983, pp. 288-311.
a. describe how Figure 15.5 was derived from Figure 15.4.
“The Statemate Approach to Complex Systems,” Inc., Burlington,
b. show how the flow balance equations are derived from Figure 15.5.
MA, 1989.
Jackson, M., System Van Nostrand Reinhold, 1983. 15.6. Get information on one or more formal analysis tools for real-time systems
Kleinrock, L., Systems, Volume 1: Theory, Wiley, 1975. (Section 15.3.2). Write a paper that outlines each tool’s use in specification
Kurki-Suonio, R., “Stepwise Design of Real-Time Systems,” IEEE Trans. and design of a real-time system.
Software Engineering, vol. 19, no. 1, January 1993, pp. 56-69.
Levi, ST., and A.K. Real-Time System Design, McGraw-Hill,
1990. FURTHER READINGS AND OTHER INFORMATION SOURCES
Liu, L.Y., and R.K. “Static Analysis of Real-Time
Distributed Systems,” Software Engineering, vol. 16, no. 3, Hatley and Pirbhai and Ward and Mellor
April pp. arc widely used books for
446 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER DESIGN FOR SY STEMS
447
sis and design of real-time systems. Mattai Systems, Prentice- and can be obtained from:
Hall, 1996) addresses program structures, timing analysis using scheduling
theory, and specification and verification of real-time systems. Cooling
(Software Design for Real-Time Systems, Thomsen Publishing,
ers the application of formal specification methods for time-dependent
cations. (Developing Real-Time Software in a Market Company, An up-to-date list of World Wide Web references for software design for
Wiley, 1994) considers both technical aspects of real-time time systems can be found at:
development.
Heath (Real-Time Software Techniques, Van Nostrand Reinhold, 1991) fo-
cuses on implementation issues for the design and development of real-time
machine control software. Books by Shumate (Software Specification
and Design-A Disciplined Approach For Real-Time Systems, Wiley, 1992) and
Braek and Oystein (Engineering Real Time Systems, Prentice-Hall, 1993) pro-
vide a wealth of information on both analysis and design modeling for real-
time software. Klein Practitioner’s Handbook for Real-Time Analysis: Guide
to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publish-
ers, 1994) addresses the detailed mathematical analysis required to predict
the timing behavior of many real-time systems. Mahar et al. (Object-Oriented
Technology for Real-Time Systems, Prentice-Hall, 1996) and Levi and
consider real-time systems from the object technologies perspective.
Van Tilborg and Koob (Foundations Systems, Kluwer Academic
Publishers, 1992) and Krishua and Lee (Readings in Real-Time Systems, IEEE
Computer Society Press, 1993) have each edited excellent tutorials on real time
systems. Schiebe (Real-Time Systems Engineering and Applications, Kluwer
Academic Publishers, 1994) has edited an anthology that addresses the engi-
neering methods required for real-time hardware and software.
Sources for real-time system design and real-time software are distributed
across many Web sites dedicated to software and software engineering. The
Internet newsgroup comp.realtime is a source for timely discussion. The
IEEE technical committee on real-time systems an of Web point-
for real-time topics at:
Other information on real-time embedded systems, prototyping as a design
approach, and a variety of real-time resources and selected papers can be ob-
tained at the following sites:
harmony.html
Information about Real-Time Engineering magazine can be obtained at:
CHAPTER 16: SOFTWARE TESTING TECHNIQUES 449
16.1 SOFTWARE TESTING FUNDAMENTALS
Testing presents an interesting anomaly for the software engineer. Earlier in
the software process, the engineer attempts to build software from an abstract
SOFTWARE TESTING
concept to a tangible comes testing. The engineer creates
a series of test cases that are intended to “demolish” the software that has been
built. In fact, testing is the one step in the software engineering process that
could be viewed (psychologically, at least) as rather than construc-
TECHNIQUES tive.
Software developers are by their nature constructive people. Testing
quires that the developer discard preconceived notions of the “correctness” of
software just developed and overcome a conflict of interest that occurs when er-
rors are uncovered. Beizer describes this situation effectively when he
states:
There’s a myth that if we were really good at programming, there would be no
bugs to catch. If only we could really concentrate, if only everyone used struc-
tured programming, top-down design, decision tables, if programs were written
in SQUISH, if we had the right silver bullets, then there would be no bugs. So
goes the myth. There are bugs, the myth says, because we are bad at what we
do; and if we are bad at it, we should feel guilty about it. Therefore, testing and
test case design is an admission of failure, which instills a goodly dose of guilt.
And the tedium of testing is just punishment for our errors. Punishment for
he importance of software testing and its implications with respect to soft- what? For being human? Guilt for what? For failing to achieve inhuman per-
ware quality cannot be overemphasized. To quote Deutsch fection? For not distinguishing between what another programmer thinks and
what he says? For failing to be telepathic? For not solving human communica-
The development of software systems involves a series of production activities tions problems that have been kicked around. for forty centuries?
where opportunities for injection of human fallibilities are enormous. Errors
to occur of process whore the Should testing instill guilt? testing The answer to these
tives. may be erroneously or imperfectly specified, as well as later design questions is “no!” However, the objectives of testing are somewhat different
and development stages. Because of human inability to perform and com- than we might expect.
municate with perfection, development is accompanied by a quality
assurance activity.
Software testing is a critical element of software quality assurance and repre- 16.1.1 Testing Objectives
sents the ultimate review of specification, design, and coding.
The increasing visibility of software as a system element and the attendant In his classic book on software testing, Glen Myers states a number
“coats” associated with a software failure are motivating forces for well-planned, of rules that can serve well as testing objectives:
thorough testing. It is not unusual for a software development organization to
expend between 30 and 40 percent of total project effort on testing. In the ex- 1. Testing is a process of executing a program with intent of finding an
treme, testing of human-rated software (e.g.. flight control, error.
monitoring) can cost three to five times as much as all other software engi-
neering activities combined! 2. A good test case is one that has a high probability of finding an as-yet
undiscovered error.
In this chapter, we discuss software testing fundamentals and techniques
for software test case design. Software testing fundamentals define the over- 3. A successful test is one that uncovers an as-yet undiscovered error.
riding objectives for software testing. Test case design focuses set of tech-
niques for the creation of test cases that meet overall testing objectives. In The above objectives imply a dramatic change in viewpoint. They move counter
Chapter 17, testing strategies and software debugging are presented. to the commonly held view that a successful test is one in which no errors are
448
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES 451
found. Our objective is to design tests that systematically uncover different paths during testing. It is possible, however, to adequately cover program logic
classes of errors and do so with a minimum amount of time and effort. and to ensure that all conditions in the procedural design have been exercised.
If testing is conducted successfully (according to the objective stated above), !" To be most effective, testing should be conducted by an independent third
it will uncover errors in the software. As a secondary benefit, testing demon- party. By “most effective,” we mean testing that has the highest probability
strates that software functions appear to be, to specification of finding errors (the primary objective of testing). For reasons that have
and that performance requirements appear to have been met. In addition, data been introduced earlier in this chapter and are considered in more detail in
collected as testing is conducted provides a good indication of software relia- Chapter 17, the software engineer who created the system is not the best per-
bility and some indication of software as a whole. But there is one thing son to conduct all tests for the software.
that testing cannot do:
Testing cannot show the absence of defects, it can only show that software er- Testability
rors are present.
In ideal circumstances, a software engineer designs a computer program, a sys-
is important to keep this (rather gloomy) statement in mind as testing is be- tem, or a product with “testability” in mind. This enables the individuals
ing conducted. charged with testing to design effective test cases more easily. But what is
“testability?” James Bach” describes testability in the following manner:
Software testability is simply how easily a computer program can be tasted.
16.1.2 Testing Principles
Since testing is so profoundly difficult, it pays to know what can be done to
streamline it. Sometimes programmers are willing to do things that will help
Before applying methods to design effective test cases, a software engineer must the testing process, and a checklist of possible design points, features, and so
understand the basic principles that guide software testing. Davis on can be useful in negotiating with them.
a of testing principles which have been adapted for use in this book There are certainly metrics that could be used to measure testability in
most of its aspects. Sometimes, testability is used to mean how adequately a
!"All tests should be traceable to customer requirements. As have seen, the we particular set of tests will cover the product. It’s also used by the military to
objective of software testing is to uncover errors. It follows that the most se- mean how easily a tool can be checked and repaired in the field. Those two
vere defects (from the customer’s point of view) are those that cause the pro- meanings are not the same as “software testability.” The checklist that follows
gram to fail to meet its requirements. provides a set of characteristics that lead to testable software.
Tests should be planned long before testing begins. planning (Chapter Test
can begin as soon as the requirements model is complete. Detailed definition O p e r a b i l i t y . “The better it works, the more efficiently it can be tested.”
of test cases can begin as soon as the design model has been solidified.
Therefore, all tests can be planned and designed before any code has been !" The system has few bugs (bugs add reporting overhead
generated. to the test process).
!" The Pareto principle applies to software testing. Stated simply, the Pareto !" No bugs block the execution of tests.
principle implies that 80 percent of all errors uncovered during testing will !" The product evolves in functional stages (allows simultaneous devel-
likely be traceable to 20 percent of all program modules. The problem, of opment and testing).
course, is to isolate these suspect modules and to thoroughly test them.
!" T e s t i n g s h o u l d b e g i n “ i n t h e s m a l l ” a n d p r o g r e s s t o w a r d t e s t i n g “ i n t h e l a r g e . ” O b s e r v a b i l i t y . “What you see is what you test.”
The first tests planned and executed generally focus on individual program
modules. As testing progresses, testing shifts focus in an attempt to find er- !" Distinct output is generated for each input.
rors in integrated clusters of modules and ultimately in the entire system !" System states and variables are visible or queriable during execution.
(Chapter !" Past system states and variables are visible or queriable trans-
!" Exhaustive testing is not possible. The number of path permutations for even action logs).
a moderately sized program is exceptionally large (see Section 16.2 for further !"All factors affecting the output are visible.
discussion). For this reason, it is impossible to execute every combination of
paragraphs that follow 1994 by James Bach and have adapted
‘Only a small subset of Davis’s requirements engineering principles are noted here. For more an Internet posting that first appeared in the This material
information, see is used with permission.
452 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 16: SOFTWARE TESTING TECHNIQUES 453
!"Incorrect output is easily identified. !" Technical is instantly accessible.
!" Internal are automatically detected through self-testing mecha- !" Technical documentation is well organized.
nisms. !" Technical documentation is specific and detailed.
!"Internal errors are automatically reported. !" Technical documentation is accurate.
!" Source code is accessible.
The attributes suggested by James Bach can be used by a software engineer to
Controllability. “The better we can control the software, the more the develop a software configuration programs, data, and documents) that is
testing can be automated and optimized.” amenable to testing.
And what about the tests themselves? Kaner, Falk, and Nguyen
!" All possible outputs can be generated through some combination of input. suggest the following attributes of a “good” test:
!" All code is executable through some combination of input.
1. A test a high finding an achieve this goal, the
!" Software and hardware states and variables can be controlled directly
tester must understand the and attempt develop a mental of
by the test engineer. how the might fail. the of failure are probed. For exam-
!" Input and output formats are consistent and structured. ple, one class of potential in a GUI (graphical user interface) is a
!" Tests can be conveniently specified, automated, and reproduced. recognize proper position. A set of would be designed to exercise
the mouse in an attempt demons an error in mouse position recognition.
D e c o m p o s a b i l i t y . “By controlling the scope of testing, we can more 2 . A good test is not redundant. Testing time and resources are limited. There
quickly isolate problems and perform smarter retesting.” is no point in conducting a test that has the same purpose as another test.
Every test should have a different purpose (even if it is subtly different).
For example, a module of the is designed to recognize
!" The software system is built from independent modules.
a user password to activate and deactivate the system. In an effort to un-
!" Software modules can be tested independently, cover an error in password input, the tester designs a series of that
input a sequence of passwords. Valid and invalid passwords (four numeral
S i m p l i c i t y . “The less there is to test, the more quickly we it.” sequences) are input as separate tests. However, each valid/invalid pass-
word should probe a different mode of failure. For example, the invalid
!" Functional simplicity (e.g., the feature set is the minimum necessary password 1234 should not be accepted by a system programmed to recog-
to meet requirements). nize 8080 as the valid password. If 1234 is accepted, an error is present.
!" Structural simplicity (e.g., is modularized to limit the Another input, say 1235, would have the same purpose as 1234 and is
propagation of faults). therefore redundant. However, the invalid input 8081 or 8180 has a subtle
difference, attempting to demonstrate that an error exists for passwords
!" Code simplicity (e.g., a coding standard adopted for ease “close to” but not identical with the valid password.
tion and maintenance).
3 . A good test should be “best of breed” In a group of tests that have
a similar intent, time and resource limitations may militate for the execu-
Stability. “The fewer the changes, the fewer the disruptions to testing.”
tion of only a subset of these tests. In such cases, the test that has the high-
est likelihood of uncovering a whole class of errors should be used.
!" Changes to the software are infrequent.
4 . A good test should be neither too simple nor ton complex. Although it is
!"Changes to the software are sometimes possible to combine a series of tests into one test case, the pos-
!" Changes to the software do not invalidate existing tests. sible side effects associated with this approach may mask errors. In gen-
!"The software recovers well from failures. eral, each test should be executed separately.
Understandability. “The more information we have, the smarter we will 16.2 TEST CASE DESIGN
test.”
design of for and other engineered products can be as chal-
!" The design is well understood. lenging as the initial design of the product Yet for reasons that we have al-
!" Dependencies between internal, and shared components are - -
well understood. is home security system that has been used as an application in ear-
!" Changes to the design are communicated. lier chapters.
454 16 It 455
ready discussed, software engineers often treat testing as an afterthought, devel- white-box testing can be combined to provide an approach that validates the
oping test cases that may “feel right” but have little assurance of being complete. software interface and selectively assures that the internal workings of the
Recalling the objectives of testing, we must design tests that have the highest software are correct.
likelihood of finding the most errors with a minimum amount of time and effort.
Over the past two decades a rich variety of test case design methods have
evolved for software. These methods provide the developer with a systematic 16.3 WHITE-BOX TESTING
approach to testing. More important, provide a mechanism that can
help to ensure the completeness of tests provide the highest likelihood for
White-box testing, sometimes called glass-box testing, is a test case design
uncovering software.
method that uses the control structure of the procedural design to derive test
Any engineered product (and most other things) can be tested in one of two
cases. Using white-box testing methods, the software engineer can derive test
ways: knowing the specified function that a product has been designed to
cases that guarantee that all independent paths within a module have been
perform, tests can be conducted that demonstrate each function is fully opera-
exercised at least once; exercise all logical decisions on their true and false
tional, at the same time searching for errors in each function; knowing the
sides; execute all loops at their boundaries and within their operational
internal workings of a product, tests can be conducted to ensure that “all gears
bounds; and exercise internal data structures to assure their validity.
mesh,” that is, that internal operation performs according to specification and
A reasonable question might be posed at this juncture: “Why spend time
all internal components been adequately exorcised. test ap-
and energy worrying about (and testing) logical minutiae when we might bet-
proach is called black-box testing and the second, white-box testing.
ter expend effort ensuring that program requirements have been met?” Stated
When computer software is considered, black-box testing alludes to tests
that are conducted at the software interface. Although they are designed to un- another way, why don’t we spend all of our energies on black-box tests? The an-
swer lies in the nature of software defects (e.g.,
cover errors, black-box tests are used to demonstrate that software functions
are operational; that input is properly accepted and output is correctly pro-
duced; and that the integrity of external information (e.g., data files) is main- !" Logic errors and incorrect assumptions are inversely proportional to the prob-
tained. A black-box test examines some fundamental aspect of a system with ability that a program path will be executed. Errors tend to creep into our
little regard for the internal logical structure of the software. work when we design and implement function, conditions, or control that
White-box testing of software is predicated on close examination of proce- are out of the mainstream. Everyday processing tends to be well understood
dural detail. Logical paths through the software are tested by providing test (and well scrutinized), while “special case” processing tends, to fall into the
cases that exercise specific sets of conditions loops. The “status of the cracks.
program” may be examined at various points to determine if the expected or a
!" We often believe that logical path is not likely to be executed when, in fact,
asserted status corresponds to the actual status. The
it may be executed on a regular basis. logical flow of a program is some-
At first glance it would seem that very thorough white-box testing would times counterintuitive, meaning that our unconscious assumptions about
lead to “100 percent correct we need do is define all logical paths, flow of control and data may lead us to make design errors that are uncov-
develop test cases to exercise them, and evaluate results, that is, generate test ered only once path testing commences.
cases to exercise program logic exhaustively. Unfortunately, exhaustive testing !" .l)pographical errors are random. When a program is
presents certain logistical problems. For even small programs, the number of language source code, it is likely that some typing errors will oc-
possible logical paths can be very large. For example, consider the 100 line pro- cur. Many will be uncovered by syntax checking mechanisms, but others will
gram in the language C. After some basic data declaration, the program con- go undetected until testing begins. It is as likely that a typo will exist on an
tains two loops that execute from 1 to 20 times each, depending on con- obscure logical path as on a mainstream path.
ditions input. Inside the interior loop, four constructs
are required. There are approximately possible paths that may be exe-
Each of these reasons provides an argument for conducting white-box tests.
cuted in this program! Black-box testing, no matter how thorough, may miss the kinds of errors noted
To put this number in perspective, we assume that a magic test processor
above. As has stated “Bugs lurk in comers and congregate at
(“magic” because no such processor exists) has been developed for exhaustive
boundaries.” White-box testing is far more likely to uncover them.
testing. The processor can develop a test case, execute it, and evaluate the re-
sults in one millisecond. Working 24 hours a days, 365 days a year, the proces-
sor would work for 3170 years to test the program. This would undeniably
cause havoc in most development schedules. Exhaustive testing is impossible 16.4 BASIS PATH TESTING
for large software systems.
White-box tasting should not, however, be dismissed as impractical. A lim- Basis path testing is a white-box testing technique first proposed by Tom
number of important logical paths can be exercised. Important McCabe The basis path method enables the test case designer to de-
data structures can be probed for validity. The attributes of both black- and rive a logical complexity measure of a procedural design and use this
PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES
The structured constructs in flow graph form:
sequence While Until
FIGURE 16.1. where each circle represents one or more
Flow graph notation nonbranching PDL or source code statements
as a guide for defining a basis set of execution paths. Test cases derived to ex-
ercise the basis set are guaranteed to execute every statement in the program
at least one time during testing.
16.4.1 Flow Graph Notation
Before the basis path method can be introduced, a simple notation for the rep-
resentation of control flow, called a graph (or program graph) must be
The flow graph depicts control flow
trated in Figure 16.1. Each structured construct (Chapter 14) has a
corresponding flow graph symbol.
To illustrate the use of a flow graph, we consider the procedural design rep-
resentation in Figure Here, a flowchart is used to depict program con-
trol structure. Figure maps the flowchart into a corresponding flow graph
(assuming that no compound conditions are contained in the decision diamonds
of the flowchart). In Figure each circle, called a flow graph node, repre-
sents one or more procedural statements. A sequence of process boxes and a de-
cision diamond can map into a single node. The arrows on the flow graph: called
edges or represent flow of control and are analogous to arrows.
An edge must terminate at a node, even if the node does not represent any pro-
cedural statements see the symbol for the if-then-else construct). Areas
bounded by edges and nodes are called regions. When counting regions we in-
clude the area outside the graph and count it as a region.”
Any procedural design representation can be translated into a flow graph.
In Figure 16.3, a program design language segment and its correspond-
ing flow graph are shown. Note that the PDL statements have been numbered
and corresponding numbering is used for the flow graph.
When compound conditions are encountered in a procedural design, the
generation of a flow graph becomes slightly more complicated. A compound con-
dition occurs when one or more Boolean operators (logical OR, AND, NAND,
FIGURE16.2.
(a) Flow chart; (b)
“In actuality, the basis path method be conducted without the use of flow However, Flow graph
they as useful tool for understanding control and the approach.
detailed discussion of graphs and their use in testing is contained in Section
PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES 459
Flow
then procedure
procedure
FIGURE 16.4.
Compound logic
terms of a flow graph, an independent path must move along at least one edge
PDL that has not been traversed before the path is defined. For example, a set of in-
dependent paths for the flow graph illustrated in Figure is:
procedure: sort
1: do while records remain path 1: l-11
read record;
2: field 1 0 path 2: I-2-3-4-5-10-1-11
3: process record; path 3: 1-2-3-6-8-9-10-l-11
store in buffer:
increment path 4: 1-2-3-6-7-9-10-l-11
4: record field 2 0
5: then reset counter:
6: process record: Note that each new path introduces a new edge. The path
store in file;
FIGURE 16.3.
TranslatingPDL to a 7b: is not considered to be an independent path because it is simply a combination
flow graph 6: end of already specified paths and does not traverse any new edges.
Paths 1, 2, 3, and 4 defined above comprise a basis set for the flow graph
in Figure That is, if tests can be designed to force execution of these
NOR) are present in a conditional statement. In Figure 16.4, a PDL segment -paths basis set), every statement in the program Will be executed at least
translates into the flow graph shown. Note that a separate node is created for one time and every condition will have been executed on its true and false side.
each of the conditions a and in the statement IF a OR 6. Each node that con- It should be noted that the basis set is not unique. In fact, any number of dif-
tains a condition is called a predicate node and is characterized by two or more ferent basis sets can be derived for a given procedural design.
edges emanating from it. How do we know how many paths to look for? The computation of
corn lexity provides the answer. Cyclomatic complexity has a foundation
in graph t eory and provides us with an extremely useful software metric.
Complexity is computed in one of three ways:
16.4.2 Cyclomatic Complexity
1. The number of regions of the flow graph correspond to the cyclomatic
Cyclomatic complexity is a software metric that provides a quantitative mea- complexity.
sure of the logical complexity of a program. When this metric is used in the con- 2 . Cyclomatic complexity, for a flow graph is as
text of the basis path testing method, the value computed for cyclomatic com-
plexity defines the number of independent paths in the basis set of a program
and provides us with an upper bound for the number of tests that must be con- where E is the number of flow graph edges and N is the number of flow
ducted to ensure that all statements have been executed at least once. graph nodes.
An independent path is any path through the program that introduces at
least one new set of processing statements or a new condition. When stated in 3 . Cyclomatic complexity, for a flow graph G is also defined as
460 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 16: SOFTWARE TESTING TECHNIQUES 461
=P+1 ample to illustrate each step in the test case design method. that
age, although an extremely simple algorithm, contains compound conditions
where P is the number of predicate nodes contained in the flow graph G. and loops.
Refer once more to the flow graph in Figure The cyclomatic
can be computed using each of the algorithms noted above: 1. Using the design or code a foundation, a corresponding
flow graph. A flow graph is created using the symbols and construction
1. The flow graph has 4 regions rules presented in Section 16.4.1. Refer to the PDL for average in Figure
2 . V(G) = 11 edges 9 nodes + 2 = 4 16.5. A flow graph is created by numbering those PDL statements that will
3 . V(G) = 3 predicate nodes 1 = 4 be mapped into corresponding flow graph nodes. The corresponding flow
graph is shown in Figure 16.6.
Therefore, the cyclomatic complexity of the flow graph in Figure is 4. 2 . Determine the cyclomatic complexity of the resultant flow graph. The
More important, the value for V(G) provides us with an upper bound for cyclomatic complexity, V(G), is determined by applying one of the algorithms
the number of independent paths that comprise the basis set, and by implica- described above. It should be noted that V(G) can be determined without de-
tion, an upper bound on the number of tests that must be designed and executed veloping a flow graph by counting all conditional statements in the PDL (for
to guarantee coverage of all program statements. \ the procedure average, compound conditions count as 2) and adding 1.
In Figure 16.6,
V(G) = 6 regions
16.4.3 Deriving Test Cases V(G) = 18 edges 14 nodes + 2 6
V(G) = 5 predicates nodes + 1 6
The basis path testing method can be applied to a procedural design or to
source code. In this section, we present basis path testing as a series of steps.
The procedure average, depicted in PDL in Figure 16.5, will be used as an
PROCEDURE average;
This procedure computes the average of or fewer
numbers that bounding it computes the
sum end the total number valid.
INTERFACE RETURNS average,
INTERFACE ACCEPTS value, minimum, maximum;
TYPE IS SCALAR ARRAY;
TYPE average.
maximum, sum IS SCALAR;
TYPE i IS INTEGER;
-999 and 100
AND
by
sum sum + i
FIGURE 16.5. IF 0
PDL for test case de- &THEN sum FIGURE16.6.
ELSE average -999;
sign Flow groph of the
identified END average procedure overage
PART FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES 463
3. Determine a basis set of linearly independent paths. he value of T Each test case is executed and compared to expected results. Once all test cases
provides the number of linearly independent paths through the program have been completed, the tester can be sure that all statements in the program
control structure. In the case of procedure average, we expect specify six have been executed at least once.
paths: It is important note that some independent paths (e.g., Path 1 in our ex-
ample) cannot be tested in standalone fashion. That is, the combination of data
path 1: l-2-10-11-13 required to traverse the path cannot be achieved in the normal flow of the pro-
path 2: l-2-10-12-13 gram. In such cases, these paths are tested as part of another path test.
path 3: l-2-3-10-11-13
path 4: ,
path 5: . 16.4.4 Graph Matrices
path l-2-3-4-5-6-7-8-9-2- .
The procedure for deriving the flow graph and even determining a set of ba-
The ellipsis following paths 4, 5, and 6 indicates that any path sis paths is amenable to mechanization. To develop a software tool that as-
through the remainder of the control structure is acceptable. It is often sists in basis path testing, a data structure, called a graph matrix, can be quite
worthwhile to identify predicate nodes as an aid in the derivation of test useful.
cases. In this case, nodes 2, 3, 5, 6, and are nodes. A graph matrix is a square matrix whose size (i.e., number of rows and
columns) is eoual to the number of nodes on the flow graph. Each row and col-
4. Prepare test cases that will force execution of each path in the ba-
umn corresponds to an identified node, and matrix entries correspond to con-
sis set. Data should be chosen so that conditions at the predicate nodes are
appropriately set as each path is tested. Test cases that satisfy the basis nections (edges) between nodes. A simple example of a flow graph and it corre-
sponding graph is shown in Figure 16.7.
set above arc:
In the figure, each node on the flow graph is identified by numbers, while
Path 1 test case: each edge is identified by letters. A letter entry is made in the matrix to cor-
= valid input, where k i defined below respond to a between two nodes. For example, node 3 is connected
value(i) = 999, where 2 i 100 to node 4 by edge b.
expected results: correct average based on values and proper totals To this point, the graph matrix is nothing more that a tabular representa-
Note: Path 1 cannot be tested standalone but must be tested as part of path tion of a flow graph. However, by adding a link to each matrix entry, the
4, 5, and 6 tests. graph matrix can become a powerful tool for evaluating program control struc-
ture during testing. The link weight provides additional information about con-
Path 2 test case: trol flow. In its simplest form, the link weight is 1 connection exists) or 0 (a
value(l) = 999
expected results: average = 999; other totals at initial values
Path 3 test case:
attempt to process 101 or more values
first 100 values should be valid
expected results: same as test case 1
Path 4 test case:
value(i) = valid input, where 100
value(k) minimum, where k i
expected results: correct average based on k values and proper totals
Path test case:
value(i) = valid input, where 100 d
value(k) maximum, where k i
expected results: correct average based on values and proper totals
Path 6 test case:
value(i) = valid input, where i 100 FIGURE16.7.
graph Graph matrix
expected results: correct average based on values and proper totals Connection matrix
PART THREE: METHODS FOR ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES
Condition
Connections
testing is a test case design method that exercises the logical
tions contained in a program module. A simple condition is a Boolean variable
or a relational expression, possibly preceded with one NOT operator. A
expression takes the form
where and are arithmetic expressions and (relational-operator) is one of
the following: = (non-equality), or A compound
condition is composed of two or more simple conditions, Boolean operators, and
FIGURE 1 6 . 8 . parentheses. We assume that Boolean operators allowed in a compound condi-
matrix complexity tion include OR AND and NOT A condition without relational
Graph matrix
expressions is referred to as a Boolean expression.
Therefore, the possible types of components in a condition include a Boolean
operator, a Boolean variable, a pair of Boolean parentheses (surrounding a sim-
connection does not exist). But link weights can be assigned other, more inter- ple or compound condition), a relational operator, or an arithmetic expression.
esting properties: If a condition is incorrect, then at least one component of the condition is
incorrect. Thus, types of errors in a condition include the following:
!" the probability that a link (edge) will be executed;
!" Boolean operator error (existence of incorrect/missing/extra Boolean
!" the processing time expended during traversal of a link;
!" the memory required during traversal of a link; and
!"Boolean variable
!" the resources required during traversal of a link.
!" Boolean parenthesis error
!"relational operator error
To illustrate, we use the simplest weighting to indicate connections (0 or 1). The
!"arithmetic expression error
graph matrix in Figure 16.7 is redrawn as shown in Figure 16.8. Each letter
has been replaced with a 1, indicating that a connection exists (zeros have been
for clarity). in form, graph matrix is called a Tho condition method focuses on testing each condition in the program.
In row two morn in have two
predicate node. Therefore, performing the shown to the right of the of condition in
connection matrix provides us with still another method for determining Second, the test coverage of conditions a program provides guidance for the
complexity (Section 16.4.2). generation of additional tests for the-program.
Beizer provides a thorough treatment of additional mathemati- The purpose of condition testing is to detect not only errors in the condi-
cal algorithms that can be applied to graph matrices. Using these tech- tions of a program but also other errors in the program. If a test set for a pro-
niques, analysis required to design test cases can be partially or fully gram is effective for detecting errors in the conditions contained in it is
automated. likely that this test set is also effective for detecting other errors in P. In ad-
dition, if a testing strategy is effective for detecting errors in a condition, then
it is likely that this strategy will also be effective for detecting errors in a pro-
gram.
16.5 CONTROL STRUCTURE TESTING A number of condition testing strategies have been proposed. Brunch test-
ing is probably the simplest condition testing strategy. For a compound condi-
tion the true and false branches of C and every simple condition in C need
The basis path testing technique described in Section 16.4 is one of a number to be executed at least once
of techniques for structure testing. Although basis path testing is sim-
ple and highly effective, it is not sufficient in In this section, other vari-
ations on control structure testing are discussed. These broaden testing cover-
age and improve quality of white-box testing. and 16.5.2 were adapted from with permission of KC. Tai.
PART THREE: CONVENTIONAL METHODS FOR SOFT
W ARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES 467
Domain testing requires three or four tests to be derived for a ra- and is = , or Since is the same as except that the second aim-
tional expression. For a rational expression of the form ple condition in is a relational expression, we can construct a constraint set
for by modifying the constraint set defined for Cr. Note
that “t” for (Es = implies = and that “f” for = implies either
three tests are required to make the value of greater than, equal to, or less or By replacing and with and respectively and
than that of respectively If (relational-operator) is incorrect and by replacing with \ and the resulting constraint set for
and are correct, then these three tests guarantee the detection of the re- is Coverage of the above constraint set will guar-
lational operator error. To detect errors and a test that makes the antee of Boolean and relational operator errors in
value of greater or less than that of should make the difference between As a third example, we consider a condition of the form:
these two values as small as possible.
For a Boolean expression with n variables, all of 2” possible tests are re-
quired This strategy can detect Boolean operator, variable, and paren- where and are arithmetic expressions. A condition constraint for
thesis errors, but it is practical only if n is small. is of the form where each of and is = , or Since is
Error-sensitive tests for Boolean expressions can also be derived the same as except that the simple condition in is a relational ex-
TAI871. For a singular Boolean expression Boolean expression in which each pression, we can construct a constraint set for by modifying the constraint
Boolean variable occurs only once) with n Boolean variables we can set for obtaining:
easily generate a test set with less than tests such that this test set guar-
antees the detection of multiple Boolean operator errors and is also effective
for detecting other errors. Coverage of the above constraint set will guarantee detection of relational op-
Tai suggests a condition testing strategy that builds on the tech- erator errors in
niques outlined above. Called (brunch and relational operator) testing, the
technique guarantees the detection of branch and relational operator errors in
a condition provided that all Boolean variables and relational operators in the
condition occur only once and have no common variables. 16.5.2 Data Flow Testing
The BRO strategy uses condition constraints for a condition C. A condition
constraint for C with n simple conditions is defined as . , where
i is a symbol specifying a constraint on the outcome of the ith sim- The data flow testing method selects test paths of a program according to the
ple condition in condition C. A condition constraint D for condition C is said to locations of definitions and uses of variables in the program. A number of data
be covered by an execution of C if during this execution of C the outcome of flow testing strategies have been studied and compared (e.g.,
each simple condition in C satisfies the corresponding constraint in D.
For a Boolean variable, we specify a constraint on the outcome of that To data flow testing approach, that each statement
states that must be either true or false Similarly, for a relational ex- in a program is assigned a unique statement number and that each function
pression, the symbols , = , and are used to specify constraints the out- does not modify its parameters or global variables. a statement with S as
come of the expression. its statement number,
As an example, consider the condition = IX statement S contains a definition of
= statement S contains a use of
where and are Boolean variables. The condition constraint for is of If statement S is an loop statement, its DEF set is empty and its USE set
the form where each of and is or The value is a con- is based on the condition of statement S. The definition of variable X at state-
dition constraint for and is covered by the test that makes the value of ment S is said to be at statement S’ if there exists a path from statement
to be true and the value of to be false. The BRO testing strategy requires S to statement S’ that does not contain any other definition of X.
that the constraint set be covered by the executions of If A definition-use chain (or chain) of variable X is of the form S’],
is incorrect due to one or more Boolean operator errors, at least one mem- where S and S’ are statement numbers, X is in and and the
ber of the constraint set will force to fail. definition of X in statement S is live at statement S’.
As a second example, consider a condition of the form One simple data flow testing strategy is to require that every chain be
covered at least once. We refer to this strategy as the testing strategy. It
=
has been shown that testing does not guarantee the coverage of all branches
where is a Boolean expression and and are arithmetic expressions. A of a program. However, a branch is not guaranteed to be covered by DU test-
condition for is of the form where each of is “t” or ing only in rare situations such as if-then-else constructs in which the then part
PART THREE: METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES
has no definition of any variable and the else part does not exist. In this situ- 16.5.3 loop Testing
ation, the else branch of the above statement is not necessarily covered by
testing. Loops are the cornerstone for the vast majority of all algorithms implemented
Data flow testing strategies are useful for selecting test paths of a program in software. And yet, we often pay them little heed while conducting software
containing nested and loop statements. To illustrate this, consider the appli- testing.
cation of DU testing to select test paths for the PDL that follows: Loop testing is a white-box testing technique that focuses exclusively on
the validity of loop constructs. Four different classes of loops can be de-
x fined: simple loops, concatenated loops, nested loops, and unstructured loops
(Figure 16.9).
do while Cl
if C2 S i m p l e l o o p s . The following set of tests should be applied to simple
then loops, where is the maximum number of allowable passes through the
if C4
then B4;
else B5; 1. Skip the loop entirely.
2 . Only one pass through the loop.
else
if C3
then
else B3;
end
To apply DU to paths of thr control flow dia-
gram, we need to know the definitions and uses of variables in each condition
or blocks in the PDL. Assume that variable X is defined in last statement
of blocks B2, B3, B4, and B5, and is used in the statement of blocks
B2, B3, B4, B5, and B6. The DU testing strategy requires an execution of the
shortest path from each of 0 5, to each of 1 6. (Such testing
also covers any use of variable X in conditions Cl, C2, C3, and Although
there are twenty-five DU chains of variable X, we only need five paths to cover
these DU chains. The reason is that five paths are needed to cover the DU loops
Simple loops
chain of X from 0 5, to B6, and other DU chains can be covered by
making these five paths containing iterations of the loop.
Note that if we apply the branch testing strategy to select test paths of the
PDL noted above, we do not need any additional information. To select paths
of the diagram for BRO testing, we need to know the structure of each condi-
tion or block. (After the selection of a path of a program, we need to determine
whether the path is feasible for the program, i.e., whether there exists at least
one input that exercises the path.)
Since the statements in a program are related to each other according to
the definitions and uses of variables, the data flow testing approach is effective Unstructured
for error protection. However, the problems of measuring test coverage and se-
lecting test paths for data flow testing are more difficult than the correspond-
ing problems for condition testing. FIGURE 16.9. Loops
470 ENGINEERING CHAPTER 471
3. Two through the loop. . How is functional validity tested?
4. passes through the loop where !" What classes of input will make good test cases?
5. 1, + 1 passes through the loop !" Is the system particularly sensitive to certain input values?
!" How are the boundaries of a data class isolated?
N e s t e d l o o p s . If we were to extend the test approach for simple loops to !" What data rates and data volume can the system tolerate?
nested loops, the number of possible tests would grow geometrically as the
!"What effect will specific combinations of data have on system operation?
level of nesting increases. This result in an impractical number of
tests. suggests an approach that will help to reduce the
number of tests: By applying black-box techniques, we derive a set of test cases that satisfy the
following criteria test cases that reduce, by a count that is greater
than one, the number of additional test cases that must be designed to achieve
1. Start at the innermost loop. Set all other loops to minimum values.
reasonable testing, and test cases’that tell us something about the presence
2. Conduct simple loop tests for the innermost loop while holding the or absence of classes of errors, rather than errors associated with the spa-
outer loops at their minimum iteration parameter (e.g., loop counter) test at hand.
values. Add other tests for out-of-range or excluded values.
3. Work outward, conducting tests for the next loop, but keeping all other
outer loops at minimum values and other nested loops to “typical” val-
Graph-Based Testing Methods
ues.
4. Continue until all loops have been tested.
The first step in black-box testing7 is to understand the that mod-
eled in software and the relationships that connect these objects. Once this has
C o n c a t e n a t e d l o o p s . Concatenated loops can be tested using’ the ap- been accomplished, the next step is to define a series of tests that verify “all
proach defined above for simple loops if each of the loops is independent of objects have the expected relationship to one another” Stated in an-
the other. However, if two loops are concatenated and the loop counter for other way, software testing begins by creating a graph of important objects and
loop as the initial value for loop 2, then the loops are not inde- their relationships and then devising a series of tests that will cover the graph
pendent. When the loops are not independent, the approach applied to so that each object and relationship is exercised and errors are uncovered.
nested loops is recommended. To accomplish these steps, the software engineer begins by creating a
U n s t r u c t u r e d l o o p s . Whenever possible, this class of loops should be graph-a collection of nodes that represent objects; links that represent the re-
designed to reflect the use of the structured programming constructs lationships between objects; node weights that describe. the properties of a node
(Chapter 14). (e.g., a specific data value or state behavior), and link weights that describe
some characteristic of a
The symbolic representation of a graph is shown in Figure Nodes
are represented as circles connected by links that take a number of different
16.6 BLACK-BOX
forms. A directed link (represented by an arrow) indicates that a relationship
moves in only one direction. A bidirectional link, also called a symmetric link,
Black-box testing, focuses on the functional of the software. That implies that the relationship applies in both directions. Parallel links are used
is, black-box testing enables the software engineer to derive sets of input con- when a number of different relationships are established between graph nodes.
ditions that will fully exercise all functional requirements for a program. As a simple example, consider a portion of a graph for a word-processing
box testing is an alternative to white-box techniques. Rather, it is a com- application (Figure where:
plementary approach that is to uncover a different class of than
white-box methods.
Black-box testing attempts to find errors in the following categories: in-
correct or missing functions, interface errors, errors in data structures or partition testing.
or external data base access, performance errors, and initialization and this context, the “object”encompasses the data that we in Chapters
11 and 12 as well as program such modules or collections of programming language
termination errors. statements.
Unlike white-box testing, which is performed early in the testing process,
“If the above concepts vaguely familiar, recall that graphs were also used in Section
black-box testing tends to be applied during later stages of testing (see Chapter 16.4.1 create a program graph the basis path testing method. nodes of the program
Because black-box testing purposely disregards control structure, attention graph containedinstructions (program objects)characterized as either procedural design rep
is focused on the information domain. Tests are designed to answer the follow- or source code, and the directed links indicated the control flow between these
ing questions: program objects. Here, the use of graphs is extended encompass black-box testing well.
472 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE CHAPTER SOFTWARE 473
relationships shown. These test cases are designed in an attempt to find errors
in any of the relationships.
Directed link
-- describes a number of behavioral testing methods that can
make use of graphs:
T r a n s a c t i o n f l o w m o d e l i n g . The nodes represent steps in some trans-
action (e.g., the steps required to make an airline reservation using an on-
line service), and the links represent the logical connection between steps
(e.g., by validation/availability.
processing). The data flow diagram (Chapter can be used to assist in
creating graphs of this type.
Finite state modeling.The nodes represent different user observable
states of the software (e.g., each of the “screens” that appear as an order-
entry clerk takes a phone order), and the links represent the transitions
that occur to move from state to state (e.g., order-information is verified
during inventory-availability-look-up is followed by
information-input).The state-transition diagram (Chapter can be
used to assist in creating graphs of this type.
D a t a f l o w m o d e l i n g . The nodes are data objects, and the links are the
transformations that occur to translate one data object into another.
For example, the node FICA.tax.withheld is computed from
using the relationship, FTW 0.062 X GW.
T i m i n g m o d e l i n g . The nodes are program objects and the links are the
Attributes: sequential connections between those objects. Link weights are used to
start dimension: default setting or preferences specify the required execution times as the program executes.
background color: white
text color: default color or preferences A detailed discussion of each of these graph-based testing methods is beyond
the scope of this book. The interested reader should see for a compre-
hensive discussion. It is worthwhile, however, to provide a generic outline of the
graph-based testing approach.
Graph-based testing begins with the definition of all nodes and node
weights. That is, objects and attributes are identified. The data model (Chapter
FIGURE 16.10. (a) Graph notation; simple example can be used as a starting point, hut it is important to note that many nodes
may be program objects (not explicitly represented in the data model). To pro-
vide an indication of the start and stop points for the graph, it is useful to
and
object = new file menu select Once nodes have been identified, links and link weights should be estab-
lished. In general, links should be named, although links that represent con-
object = document window
trol flow between program objects need not be named.
object = document text In many cases, the graph model may have loops (i.e., a path through the
graph in which one or more nodes is encountered more than one time). Loop
As shown in the figure, a menu select on new file generates a document win- testing (Section 16.5.3) can also be applied at the behavioral (black-box) level.
dow. The node weight of document window provides a list of the window at- The graph will assist in identifying those loops that need to be tested.
tributes lhat arc to window is link weight Each relationship is separately so that test cases can be derived.
indicates that the window must be generated in less than 1.0 second. An undi- The of sequential relationships is studied to determine how the im-
rected link establishes a symmetric relationship between the new file menu pact of relationships propagates across objects defined in a graph. Transitivity
select and document text, and parallel links indicate between can be illustrated by considering three objects, X, Y, and Consider the fol-
document window and document text. In reality, a far more detailed graph lowing relationships:
would have to be generated as a precursor to test case design. The software en-
gineer then test cases by graph and each of the
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING SOFTWARE TESTING TECHNIQUES 475
Y is required to compute Z
2. If an input condition requires a specific value, one valid and two invalid
Therefore, a transitive relationship has been established between X and Z: equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid
X is required to computeZ equivalence class are defined.
4. If an input condition is Boolean, one valid and one invalid class are defined.
Baaed on this transitive relationship, find errors in the calculation of
Z must consider a variety of values for both X and Y. As an example, consider data maintained as part of an automated banking
The symmetryof a relationship (graph link) is also an important guide to application. The user can “dial” the bank using his or her personal computer,
the design of test cases. If a link is indeed bidirectional (symmetric), it is im- provide a six digit password, and follow with a series of keyword commands
portant to test this feature. The UNDO feature in many personal com- that trigger various banking functions. The software supplied for the banking
puter applications implements limited symmetry. That is, UNDO allows an ac- accepts data in the form:
tion to be negated after it has been completed. This should be thoroughly tested
and all exceptions (i.e., places where UNDO cannot be used) should be noted. area code-blank or three digit number
Finally, every node in the graph should have a relationship that leads back to
itself; in essence, a “no action” or “null action” loop. These reflexive relationships prefix-three digit number not beginning with 0 or 1
should also be tested. digit number
As test case design begins, the first objective is to achieve node coverage. password-six digit alphanumeric value
By this we mean that tests should be designed to demonstrate that no nodes
commands-“check,” “deposit,” “bill pay,” etc.
have been inadvertently omitted and that node weights (object attributes) are
correct.
Next, link coverage is addressed. Each relationship is tested based on its The input conditions associated with each data element for the banking ap-
properties. For example, a symmetric relationship is tested to demonstrate that plication can be specified as:
it is, in fact, bidirectional. A transitive relationship is tested to demonstrate
that transitivity is present. A reflexive relationship is tested to ensure that a area code: input condition, Boolean-the area code may or may not be
null loop is present. When link weights have been specified, tests are devised present
to demonstrate that these weights are valid. Finally, loop testing is invoked input condition, defined between 200 and 999,
(Section with specific exceptions
prefix: input condition, range-specified value 200 with no 0 dig-
its
16.6.2 Equivalence Partitioning suffix: input condition, digit length
inputcondition, Boolean-a password may or may not be
present
is
Equivalence partitioning a black-box testing method that divides the input
input condition, character string
domain of a program into classes of data from which test cases can be derived.
An ideal test case single-handedly uncovers a class of errors (e.g., incorrect pro- input condition, set-containing commands noted above
cessing of all character data) that might otherwise require many cases to be
executed before the general error is observed. Equivalence partitioning strives Applying the guidelines for the derivation of equivalence classes, test cases for
to define a test case that uncovers classes of errors, thereby reducing the total each input domain data item could be developed and executed. Test cases are
number of test cases that must be developed. selected so that the largest number of attributes of an equivalence class are ex-
Test case design for equivalence partitioning is based on an evaluation of ercised at once.
equivalence classes for an input condition.Using concepts introduced in the
preceding section, if a set of objects can be linked by relationships that are sym-
metric, transitive, and reflexive, an equivalence class is present An
class represents a set of valid or invalid states for input conditions. 16.6.3 Boundary Value Analysis
Typically, an input condition is either a specific numeric value, a range of val-
ues, a set of related values, or a Boolean condition. Equivalence classes may be For reasons that are not completely clear, a greater number of errors tend to
defined according to the following guidelines: occur at the boundaries of the input domain than in the “center.” It is for this
reason that boundary analysis has been developed as a testing
1. If an input condition specifies a range, one valid and two invalid equiva-
lence classes are defined.
476 PART THREE, CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES 477
technique. Boundary value analysis leads to a selection of test cases that exer- put from each version is the same, it is assumed that all implementations are
cise bounding values. correct. If the output is different, each of the applications is investigated to de-
Boundary value analysis is a test case design technique that complements termine if a defect in one or more versions is responsible for the difference. In
equivalence partitioning. Rather than selecting any element of an equivalence most cases, the comparisonof outputs can be performed by a automated tool.
class, BVA leads to the selection of test cases at the “edges” of the class. Rather Comparison testing is not foolproof. If the specification from which all ver-
than focusing solely on input conditions, BVA derives test cases from the out-, sions have been developed is in error, all versions will likely reflect the error.
put domain as well In addition, if each of the independent versions produces identical, but incor-
Guidelines for BVA are similar in many respects to those provided for rect, results, condition testing will fail to detect the error.
equivalence partitioning:
If an input condition specifies a range bounded by values a and test cases
should be designed with values a and just above and just below a and 16.7 TESTING FOR SPECIALIZED ENVIRONMENTS AND APPLICATIONS
respectively
As computer software has become more complex, the need for specialized test-
If an input condition specifies a number of values, test cases should be de-
veloped that exercise the minimum and maximum numbers. Values just ing approaches has also grown. The white-box and black-box testing methods
discussed in Sections 16.5 and 16.6 are applicable across all environments, ar-
above and below minimum and maximum are also tested.
chitectures, and applications, but unique guidelines and approaches to testing
Guidelines 1 and 2 are applied to output conditions. For example, assume are sometime warranted. In this section we consider testing guidelines for spe-
that a temperature vs. pressure table is required as output from an engi- cialized environments, architectures, and applications that are commonly en-
neering analysis program, Test cases should be designed to create an out- countered by software engineers.
put report that produces the maximum (and minimum) allowable number
of table entries.
If internal program data structures have prescribed boundaries (e.g., an ar- 16.7.1 Testing
ray has a defined limit of entries), be certain to design a test case to
exercise the data structure at its boundary.
Graphical user interfaces present interesting challenges for software
engineers. Because of reusable components provided as part of GUI develop-
Most software engineers intuitively perform BVA to some degree. By applying
ment environments, the creation of the user interface has become less
the guidelines noted above, boundary testing will be more complete, thereby consuming and more precise. At the same time, the complexity of has
having a higher likelihood for error detection.
grown, leading to more difficulty in the design and execution of test cases.
Because modern have the same look and feel, a series of standard
be dcrivcd. can as a guideline for cre-
16.6.4ComparisonTesting ating a series of generic tests for
There arc situations avionics. plant For
in which the reliability is critical. such !" Will the window open properly based on related typed or menu-based com-
redundant hardware and software are used to the possibility of mands?
error. When redundant software is developed, separate software engineering !" Can the window be moved, and scrolled?
teams develop independent versions of an application using the same
!" Is all data content contained within the window properly addressable with a
cation. In such situations, each version can be tested with the same test data
to ensure that all provide identical obtput. Then all versions are executed in mouse, function keys, directional arrows, and keyboard?
parallel with real-time comparison of results to ensure consistency. !" Does the window properly regenerate when it is overwritten and then re-
Using lessons learned from redundant systems, researchers (e.g., called?
have suggested that independent versions of software be developed for critical !" Are all functions that relate to the window available when needed?
applications, even when only a single version will be used in the delivered com-
!"Are all functions that relate to the window operational?
puter-based system. These independent versions form the basis of a black-box
!" Are all relevant pull-down menus, tool bars, scroll bars, dialog boxes, and
testing technique called testing or back-to-back testing
When multiple implementations of the same specification have been pro- icons, and other controls available and properly displayed for the window?
duced, test cases designed using other black-box techniques (e.g., !" When multiple windows are displayed, is the name of the window properly
partitioning) are provided as input to each version of the software. If the represented?
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES 479
!" Is the active window properly highlighted? 16.7.2 Testing of Client/Server Architectures
!" If multitasking is used, are all windows updated at appropriate times?
!" Do multiple or incorrect mouse picks within the window cause unexpected , , Client/server architectures (e.g., represent a signifi-
side effects? cant challenge for software testers. The distributed nature of client/server en-
!" Are audio and/or color prompts within the window or as a consequence of
vironments, the performance issues associated with transaction processing, the
window operations presented specification? potential presence of a number of different hardware platforms, the complexi-
ties of network communication, the need to service multiple clients from a cen-
!" Does the window properly close?
tralized in some cases, distributed) database, and the coordination require-
ments imposed on the server all combine to make testing of C/S architectures
For pull-down menus and mouse operations: and the software that reside within them considerably more difficult than test-
!" Is the appropriate menu bar displayed in the appropriate context? ing In fact, recent industry studies indicate a signifi-
!" Does the application menu bar display system related features (e.g., a clock cant increase testing time and cost when C/S environments are developed.
display)? For further information on client/server testing, see Chapter 28.
!" Do pull-down operations work properly?
!" Do breakaway menus, palettes, and tool bars work properly?
!" Are all menu functions and pull-down subfunctions properly listed? 16.7.3 Testing Documentation and Help Facilities
!" Are all menu functions properly addressable by the mouse?
The term “software testing” conjures images of large numbers of test cases pre-
!" Is text typeface, size, and format correct?
pared to exercise computer programs and the data that they manipulate.
!" Is it possible to invoke each menu function using its alternative text-based
Recalling the definition of software presented in the first chapter of this book,
command? it is important to note that testing must also extend to the third element of the
!" Are menu functions highlighted grayed-out) based on the context of cur- software
rent operations within a window? Errors in documentation can be as devastating to the acceptance of the pro-
!" Does each menu function perform as advertised? gram as errors in data or source code. Nothing is more frustrating than fol-
lowing the user guide exactly and getting results or behaviors that do not co-
!" Are the names of menu functions self-explanatory?
incide with those predicted by the document. For this reason, documentation
!" Is help available for each menu item, and is it context sensitive? testing should be a meaningful part of every software test plan.
!" Are mouse operations properly recognized throughout the interactive con- Documentation testing can be approached in two phases. The first phase,
text? formal technical review (Chapter examines the document for editorial clar-
!" If multiple clicks are required, are they properly recognized in context? ity. The second phase, live test, uses the documentation in conjunction with the
use of the actual program.
!" If the mouse has multiple buttons, are they properly recognized in context?
It is surprising, but live test for documentation can be approached using
!" Do the cursor, processing indicator (e.g., an hour glass or clock), and pointer techniques that are analogous to many of the black-box testing methods dis-
properly change as different operations are invoked? cussed in Section 16.6. Graph-based testing can be used to describe the use of
the program; equivalence partitioning and boundary value analysis can be used
Data entry: to define various classes of input and associated interactions. Program usage
!" Is alphanumeric data entry properly echoed and input to the system? is then tracked through the documentation:
!" Do graphical modes of data entry (e.g., a slide bar) work properly?
!" Does the documentation accurately describe how to accomplish each mode of
!" Is invalid data properly recognized?
use?
!" Are data input messages intelligible?
!" Is the description of each interaction sequence accurate?
!"Are examples accurate?
In addition to the above guidelines, finite state modeling graphs (Section
!" Are terminology, menu descriptions, and system responses consistent with
may be used to derive a series of tests that address specific data and program
objects that are relevant to the GUI. the actual program?
Because of the large number of permutations associated with GUI opera- !" Is it relatively easy to locate guidance within the documentation?
tions, testing should be using automated tools. A wide array of GUI
testing tools has appeared on the market over the past few years. For further
discussion, see Chapter 29. this context, documentation refers to printed manuals online help facilities.
480 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 16: SOFTWARE TESTING TECHNIQUES 481
!" Can troubleshooting be accomplished easily with the documentation? Behavioral testing. Using system’ models created with CASE tools
!" Are the document table of contents and index accurate and complete? 15.31, it is possible to simulate the behavior of a real-time system and exam-
ine its behavior as a consequence of external events. These analysis activities
!" Is the design of the document (layout, typefaces, indentation, graphics) con-
can serve as the basis for the design of test cases that are conducted when
ducive to understanding and quick of information? the real-time software has been built. Using a technique that is similar to
!"Are all error messages displayed for the user described in more detail in the equivalence partitioning (Section events (e.g., interrupts, control sig-
document? nals, data) are categorized for testing. For example, events for the photocopier
!" If hypertext links are used, are they accurate and complete? might be user interrupts (e.g., reset counter), mechanical interrupts (e.g., pa-
per jammed), system interrupts (e.g., toner low) and failure modes (e.g., roller
The only viable way to answer these questions is to have an independent third overheated). Each of these events is tested individually and the behavior of
party (e.g., selected users) test the documentation in the context of program us- the executable system is examined to detect errors that occur as a conse-
age. All discrepancies are noted, and areas of document ambiguity or weakness quence of processing associated with these events. The behavior of the system
are defined for potential rewrite. model (developed during the analysis activity) and the executable software
can be compared for conformance. Once each class of events has been tested,
events are presented to the system in random order and with random fre-
quency The behavior of the software is examined to detect behavior errors.
16.7.4 for Real-Time Systems testing. Once errors in individual tasks and in system behavior
have been isolated, testing shifts to time related errors. Asynchronous tasks
The time-dependent, asynchronous nature of many real-time applications that are known to communicate with one another are tested with different
(Chapter 15) adds a new and potentially difficult element to the testing data rates and processing load to determine if intertask synchronization er-
tine. Not only does the test case designer have to consider white- and rors will occur, In addition, tasks that communicate via a message queue or
box test cases, but also event handling (i.e., interrupt processing), the timing of data are tested to uncover errors in the sizing data storage areas
the data, and the parallelism of the tasks (processes) that handle the data. In System testing. Software and hardware are integrated, and a full range of
many situations, test data provided when a real-time system is in one state will system tests (Chapter 17) are conducted in an attempt to uncover errors at
result in proper processing, while the same data provided when the system is the software/hardware interface.
in a different state may lead to error.
For example, real-time that controls a new photocopier accepts Most real-time systems process interrupts. Therefore, testing the handling
interrupts the machine operator hits control keys such as “reset” of these Boolean events is essential. Using the state-transition diagram and the
or “darken”) with no error when the machine is making copies (in the “copying” control specification (Chapter the tester develops a list of all possible in-
state). These same operator interrupts, if input when the machine is in the terrupts and the processing that occurs as a consequence of the interrupt. Tests
“jammed” state, cause a diagnostic code indicating the location of the jam to be are then designed to assess the following system characteristics:
lost (an error). \
In addition, the intimate relationship that exists between real-time soft- !"Are interrupt priorities properly assigned and properly handled?
ware and its hardware environment can also cause testing problems. Software
tests must consider the impact of hardware faults on software processing. Such !"Is processing for each interrupt handled correctly?
faults can be extremely difficult to simulate realistically. !" Does the performance (e.g., processing time) of each interrupt handling pro-
Comprehensive test case design methods for real-time systems have yet to cedure conform to requirements?
evolve. However, an overall four-step strategy can be proposed: !" Does a high volume of interrupts arriving at critical times create problems
in function or performance?
Task testing. The first step in the testing of real-time software is to test
each task independently.” That is, white-box and black-box tests are de- In addition, global data areas that are used to transfer information as part of
signed and executed for each task. Each task is executed independently interrupt processing should be tested to assess the potential for the generation
during these tests. Task testing uncovers errors in logic and function, but of side effects.
will not uncover timing or behavioral errors.
16.8 SUMMARY
The primary objective for test case design is to derive a set of tests that have
highest in To accomplish this
482 PART FOR SOFTWARE ENGINEERING 483
objective two different categories of design are used: “Sensitive Data for Boolean Expressions,” ACM
white-box testing and black-box testing. Engineering Notes, vol. no. April 1984, pp.
White-box tests focus on the program control structure. Test cases are de- Frankl, P.G., and E.J. “An Applicable Family of Data Flow
rived to ensure that all statements in the program have been executed at least Testing Criteria,” IEEE Trans. Software Engineering, vol. 14, no. 10,
once during testing and that all logical conditions have been exercised. Basis October 1988, pp. 14831498.
path testing, a white-box technique, makes use of program graphs (or graph Frankl, and S. Weiss, “An Experimental Comparison of the
matrices) to derive the set of linearly independent tests that will ensure Effectiveness of Branch Testing and Data Flow,” IEEE Software
erage. Condition and data flow testing exercise program logic, and loop vol. 19, no. 8, August 1993, pp.
testing complements other white-box techniques by providing a procedure for The Complete Guide to Testing, QED Information
exercising loops of varying degrees of complexity. Sciences, Inc., MA, 1984.
Hetzel describes white-box testing as “testing in the small.” His W.E., “Weak Mutation Testing and the Completeness of Test
implication is that the white-box tests that we have considered in this chapter Cases,” IEEE Trans. Software Engineering, vol. SE-S, no. 4, July 1982,
are typically applied to small program components (e.g., modules or small pp. 371-37s.
groups of modules). Black-box testing, on the other hand, broadens our focus Jones, Programming Productivity: Issues for the IEEE Computer
and might be called “testing in the large.” Society Press, 1981.
Black-box tests are designed to uncover errors in functional requirements C., J. and H.Q. Nguyen, Testing Computer Software, 2nd edi-
without regard to the internal workings of a program. Black-box testing tech- tion, Van Nostrand Reinhold, 1993.
niques focus on the information domain of the software, deriving test cases by Knight, J., and “Testing Software Using Multiple Versions,”
partitioning the input and output domain of a program in a manner that pro- Software Productivity Consortium, Report No. VA, June
vides thorough test coverage. Graph-based testing methods explore the 1989.
between and behavior of program objects. Equivalence partitioning McCabe, T., “A Software Complexity Measure,” IEEE Trans. Software
divides the input domain into classes of data that are likely to exercise specific Engineering, vol. 2, December 1976, pp. 308420.
software function. Boundary value analysis probes the program’s ability to han- Myers, G., The Art of Software Testing, Wiley, 1979.
dle data at the limits of acceptability. Ntafos, S.C., A Comparison of Some Structural Testing Strategies,” IEEE
Specialized testing methods encompass a broad array of software capabil- Software Engineer&, vol. 14, no. 6, June 1988, pp. 866-674.
ities and application areas. Graphical user interfaces, architec- K.C., and H.K. Su, “Test Generation for Boolean Expressions,”
tures, documentation and help facilities, and real-time systems each require COMPSAC ‘87, October 1987, pp.
specialized guidelines and techniques for software testing. Tai, K.C., “What to Do Beyond Branch Testing,” ACM Software
Experienced software developers often say, ‘Testing never ends, it just gets Engineering Notes, 14, no. 2, April 1989, pp. 58-61.
transferred from you (the software engineer) to your customer. Every time your Vaskevitch, D., Strategies, IDG Books, 1993.
customer uses the program, a test is being conducted.” By applying test case de- White, L.J., and E.I. Cohen, “A Domain Strategy for Program Testing,”
sign, the engineer can achieve more complete testing and thereby uncover IEEE Trans. Software Engineering, vol. SE-6. no. 6, May pp.
and correct the highest number of errors before the “customer’s tests” begin. 247-257.
REFERENCES
PROBLEMS AND POINTS TO PONDER
Beizer, B., Software Testing Techniques, 2nd edition, Van Nostrand
Reinhold, 1990. 16.1. Myers uses the following program as a self-assessment for your
B., Black-Box Testing, Wiley, 1995. ability to specify adequate testing: A program reads three integer values.
Berson, A., Architectures, McGraw-Hill, 1992. The three values are interpreted as representing the lengths of the sides of
Brilliant, S.S., J.C. Knight, and N.G. Levenson; “The Consistent a triangle. The program prints a message that states whether the triangle
Comparison Problem in N-Version Software Engineering is scalene, or equilateral. Develop a set of test cases that you feel
Notes, vol. 12, no. 1, January 1987, pp. 29-34. will adequately test this program.
Davis, A., 201 Principles of Software McGraw-Hill, 1995. 16.2. Design and implement the program (with error handling where appropriate)
Deutsch, M., “Verification and Validation,” in Software Engineering, specified in problem 16.1. Derive a graph for the program and apply ba-
R. Jensen and C. Tonies Prentice-Hall, 1979, pp. sis path testing to develop test cases that will guarantee that all statements
Dunn, R., Software Defect Removal, McGraw-Hill, 1984. in the program have been tested. Execute the cases and show your results
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING TECHNIQUES 485
16.3. Can you think of any additional tasting objectives that discussed in of Software Testing, Prentice-Hall, 19951 and Friedman and Voaa (Software
Section Assessment: Reliability, Safety, Testability, Wiley, 1995) present good introduc-
16.4. Apply the basis path testing technique to any one of the programs that you tions to testing strategies and tactics. Mosley (The Handbook of
have implemented in problems 14.23 through 14.31. Software Prentice-Hall, 1993) discusses testing issues for large infor-
16.6. Specify, design, and implement a software tool that will compute the mation systems, and Marks (Testing Big Systems, McGraw-Hill, 1992) dis-
complexity for the programming language of your choice. Use the cusses the special issues that must be considered when testing major pro-
graph matrix as the operative data structure in your design. gramming systems. Jorgensen (Software Testing: A Craftman’s Approach, CRC
16.6. Read and determine how the program you have developed in Press, 19951 presents a detailed discussion of a wide variety of black- and
problem 16.5 can be extended to accommodate various link Extend white-box testing methods. (Handbook of Usability Testing, Wiley, 1994)
has written a useful guide for those who must exercise human interfaces.
your tool to process execution probabilities or link processing times.
(Functional Program Testing and Analysis, McGraw-Hill,
16.7. Use the condition testing approach described in Section to design a presents a mathematically rigorous discussion that attempts to unify different
set of test cases for the program you created in problem 16.2. test case design strategies. Perry (How to Test Software Packages, Wiley, 19861
16.8. Using the data flow testing approach described in Section 16.5.2, make a list provides practical guidelines and useful checklists for testing purchased soft-
of definition-use chains for the program you created in problem 16.2. ware (as well as software developed internally). Miller and (Software
16.9. Design an automated tool that will recognize loops and categorize them as and Validation Techniques, 2nd edition, IEEE Computer Society Press,
indicated in Section 16.53. 1981) have edited an excellent anthology of early papers on testing.
16.10. Extend the tool described in problem to generate test cases for each loop An excellent source of information on automated tools for software testing
category, once encountered. It will be necessary to perform this function in- is the Testing Tools Reference Guide (Software Quality Engineering, Inc.,
teractively with the tester. Jacksonville, FL, updated yearly). This directory contains descriptions of hun-
16.11. Give at least three examples in which black-box testing might give the dreds of testing tools, categorized by testing activity, hardware platform, and
that “everything’s O.K..” while white-box tests might uncover an er- support.
ror. Give at least three examples in which white-box testing might give the The Internet newsgroup contains debate,
impression that “everything’s O.K.,” while black-box tests might uncover an sion. and guidelines on all aspects of software testing. The Techniques
error. On-Line Edition, is available via the Internet and is e-mailed
monthly. It provides information of general use to the software testing com-
16.12. Will exhaustive testing (even if it is possible for very small programs) guar-
munity. For further information, contact:
antee that the program is 100 percent correct?
16.13. Using the equivalence method, derive a sot of test cases for the
system described earlier in this book. Software Testing Laboratories and the Software Testing Institute provide
useful information on testing. Information on training and publications can be
16.14. Using boundary value analysis, derive a set of test cases for the PHTRS sys-
obtained at:
tem described in problem 12.13.
16.16. Select a specific GUI for a program with which you are familiar and design
a series of tests to exercise the GUI.
..
16.16. Test a user manual help facility) for an application that you use fre-
quently. Find at least one error in the documentation,
An archive containing all articles posted to the newsgroup
can be found at:
FURTHER READINGS AND OTHER INFORMATION SOURCES
A number of excellent books are now available for those readers who desire ad- A database of software testing resources has been developed by Reliable
Software Technologies and can be found at:
ditional information on software testing. Myers remains a classic text,
covering black-box techniques in considerable detail. provides
comprehensive coverage of white-box techniques, introducing a level of mathe-
matical rigor that has often been missing in other treatments of testing. His
later book presents a concise treatment of important methods. Perry A variety of publications on software verification and testing can be acquired
Methods for Wiley-QED, 19951, (The from:
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
an online journal of “of computer bugs, glitches, incompatibilities. . .
and their can be found at:
SOFTWARE TESTING
STRATEGIES
An up-to-date list of World Wide Web references for software testing can be
found at:
strategy for software testing integrates software test case design methods
into a well-planned series of steps that result in the successful construc-
tion of software. As important, a software testing strategy provides a road map
for the software developer, the quality assurance organization, and the cus-
tomer-a road map that describes the stops to be conducted as part of testing,
when these steps are planned and then undertaken, and how much effort, time,
and resources will be required. Therefore, any testing strategy must incorpo-
rate test planning, test case design, test execution, and resultant data collec-
tion and evaluation.
A software testing strategy should be flexible enough to promote the cre-
ativity and customization that are necessary to adequately test all large soft-
ware-based systems. At the same time, the strategy must be rigid enough to
promote reasonable planning and management tracking-as the project pro-
gresses. Shooman discusses these issues:
In many ways, testing is an individualistic process, and the number of differ-
ent types of tests varies as much as the different development approaches. For
many years, our only defense against programming errors was careful design
and the native intelligence of the programmer. We are now in an era in which
modern design techniques land formal technical reviews] are helping us to re-
duce the number of initial errors that are inherent in the code. Similarly, dif-
ferent methods are beginning to cluster themselves into several distinct
approaches and philosophies.
These approaches and philosophies are what we shall call In Chapter
16, the technology of software testing was presented.’ In this chapter, we focus
our attention on the strategy for software testing.
‘Testing for systems discussed in Chapter 22.
487
PART CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING STRATEGIES 489
17.1 A STRATEGIC APPROACH TO TESTING
\ Formal
Testing is a set of activities that can be planned in advance and conducted sys- Technical
tematically For this reason a template for software testing-a set of steps into Software Reviews
which we can place specific test case design methods-should be defined for the Engineering Measurement
software engineering process. Methods
A number of software testing strategies have been proposed in the litera-
ture. All provide the software developer with a template for testing, and all
have the following generic characteristics:
!" Testing begins at the module and works “outward” toward the inte-
gration of the entire computer-based system.
!"Different testing techniques appropriate at different points in time.
!" Testing is conducted by the developer of the software and (for large projects)
an independent test group.
!" Testing and debugging are different activities, but debugging must be ac- FIGURE17.1.
commodated in any testing strategy. Achieving
quality
A strategy for software testing must accommodate low-level tests that are nec-
essary to verify that a small source code segment has been correctly imple-
mented as well as high-level tests that validate major system functions against quality by providing uniform techniques and predictable results. Formal tech-
customer requirements. A strategy must provide guidance for the practitioner nical reviews (walkthroughs) help to ensure the quality of work products pro-
and a set of milestones for the manager. Because the steps of the test strategy duced as a consequence of each software engineering step. Throughout the
occur at a time when deadline pressure begins to rise, progress must be mea- process, measurement and control are applied to every element of a software
surable and problems must surface as early as possible. configuration. Standards and procedures help to ensure uniformity, and a for-
mal SQA process enforces a “total quality philosophy.”
Testing provides the last bastion from which quality can be assessed and,
more pragmatically, errors can be uncovered. But testing should be viewed
17.1.1 Verification and Validation
as a safety net. As they say, ‘You can’t test in quality. If it’s not there before
you begin testing, it won’t be there finished testing.” Quality is
is topic is to into throughout the software process. Proper application of
and validation Verification refers to the set of activities that methods and tools, formal technical reviews, and solid management
ensure that software correctly implements a specific function. Validation refers and measurement all lead to quality that is confirmed during testing.
to a different set of activities that ensure that the software that has been built Miller relates software testing to quality assurance by stating that
is traceable to customer requirements. Boehm states this another way: “the underlying motivation of program testing is to affirm software quality
with methods that can be economically and effectively applied to both
Verification: “Are we building the product right?” scale and small-scale systems.”
Validation: “Are we building the right product?” It is important to note that verification and validation encompass a wide
array of SQA activities that include formal technical reviews, quality and con-
figuration audits, performance monitoring, simulation, feasibility study, docu-
The definition of V&V encompasses many of the activities that we have re-
mentation review, database review, algorithm analysis, development testing,
ferred to as software quality assurance
qualification testing, and installation testing Although tasting plays
Recall the discussion of software quality in Chapter 8. The activities re-
an extremely important role in V&V, many other activities are also necessary.
quired to achieve it may be viewed as a set of components depicted in Figure
17.1. Software engineering methods provide the foundation from which quality*
is built. Analysis, design, and construction (coding) methods act to enhance
17.1.2 Organizing for Software Testing
de-
object-oriented systems, testing begins at the class or object level. See Chapter 22 for For every software project, there is an inherent conflict of interest that occurs
tails. as testing begins, The people who have built the software are now asked to test
PART THREE: FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING STRATEGIES
491
the software. This seems harmless in itself: After all, who knows the program
better than its developers? Unfortunately, these same developers have a vested
interest in demonstrating that the program is error-free, that it works
to customer and that it will be completed on schedule and
budget, Each of these interests militates against thorough testing.
From a psychological point of view, software analysis and design (along
with coding) are tasks. engineer creates a computer
program, its documentation, and related data structures. Like any builder, the
software engineer is proud of the edifice that has been built and looks askance FIGURE 17.2.
at anyone who attempts to tear it down. When testing commences, there is a Testing strategy
subtle, yet definite, attempt to “break” the thing that the software engineer has
built. From the point of view of the builder, testing can be considered to be
So the builder treads lightly, designing and exe-
tests that will demonstrate that the program works, rather than uncov- performance, constraints, and validation criteria for software are es-
ering errors. Unfortunately, errors will be present. And if the engineer tablished. Moving inward along the spiral, we come to design and to cod-
doesn’t find them, the customer will! ing. To develop computer we spiral in along that decrease
There are often a number of misconceptions that can be erroneously in- the level of abstraction on each turn.
ferred from the above discussion: (1) that the developer of software should do A strategy for software testing may also be viewed in the context of the
no testing at all; that the software should be “tossed over the wall” to spiral (Figure 17.2). Unit begins at the vortex of the spiral and concen-
strangers who will test it mercilessly; and (3) that testers get involved with the trates on each unit of the software as implemented in source code. Testing pro-
only when the testing steps are about to begin. Each of these statements gresses by moving outward along the spiral to integration testing, where the fo-
is incorrect. cus is on design and the construction of the software architecture. Taking
The software developer is always responsible for testing the individual another turn outward on the spiral, we encounter testing, where re-
units (modules) of the program, ensuring that each performs the function for quirements established as part of software requirements analysis are validated
which it was designed. many cases, the developer also conducts integration against the software that has been constructed. Finally, we arrive at system
testing-a testing step that leads to the construction (and testing) of the com- testing, where the software and other system elements are tested as a whole.
plete program structure. Only after the software architecture is complete does To test computer software, we spiral out along streamlines that broaden the
an independent test group become involved. scope of testing with each turn.
The role of an independent test group is to remove the inherent prob- Considering the process from a procedural point of view, testing within the
lems associated with letting the builder test the thing that has been built. context of software engineering is actually a series of four steps that are im-
Indenendent testina removes the conflict of interest that may otherwise be pres- plemented sequentially. The steps are shown in Figure 17.3. Initially, tests fo-
ent. all, personnel in the independent group team are paid to find errors. cus on each module individually, assuring that it functions properly as a unit.
However, the-software developer doesn’t turn the program over to ITG and Hence, the name unit testing. Unit testing makes heavy use of white-box test-
walk away. The developer and the ITG work closely throughout a software proj- ing techniques, exercising specific paths in a module’s control structure to en-
ect to ensure that thorough tests will be conducted. While testing is conducted, sure complete coverage and maximum error detection. Next, modules must be
the developer must be available to correct errors that are uncovered. assembled or integrated to form the complete software package. Integration
The ITG is part of the development project team in the sense that testing addresses the issues associated with the dual problems of verification
it becomes involved during the specification process and stays involved (plan- , and program construction. Black-box test case design techniques are the most
ning and specifying test procedures) throughout a large project. However, in prevalent during integration, although a limited amount of white-box testing
many cases the ITG reports to the software quality assurance organization, may be used to ensure coverage of major control paths. the software has
thereby achieving a degree of independence that might not be possible if it were been integrated (constructed), a set of high-order tests are conducted. Validation
a part of the software development organization. criteria (established during requirements analysis) must be tested.
testing provides final assurance that software meets all functional, behavioral
and performance requirements. Black-box testing techniques are used
sively during validation.
A Software Testing The last high-order testing step falls outside the boundary of software en-
gineering and into the broader context of computer system engineering.
The software engineering process may be viewed as a spiral, illustrated in Software, once validated, must be combined with other system elements
Figure 17.2. Initially, system engineering defines the role of software and leads hardware, people, databases). System testing verifies that all elements mesh
to software requirements analysis, where the information domain, function, properly and that overall system function/performance is achieved.
CHAPTER SOFTWARE TESTING STRATEGIES 493
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
where = cumulative number of failures that are expected to occur once
the software has been tested for a certain amount of execution
high-order time, t,
requirements
tests lo = the initial failure intensity(failures per unit time) at
I the beginning of testing,
= the exponential reduction in failure intensity as errors are un-
covered and repairs are made.
The instantaneous failure intensity, can be derived by taking the de-
rivative of
= + (17.2)
Using the relationship noted in equation predict the drop-off
of errors as testing progresses. The actual error intensity can be plotted against
the predicted curve (Figure 17.4). If the actual data gathered during testing
and the logarithmic Poisson execution-time model are reasonably close to one
another over a number of data points, the model can be used to predict total
“direction”
testing time required to achieve an acceptably low failure intensity.
FIGURE 17.3. testing steps By collecting metrics during software testing and making use of existing
software reliability models, it is possible to develop meaningful guidelines for
answering the question: “When are we done testing?” There is little debate that
further work remains to be done before quantitative rules for testing can be es-
17.1.4 Criteria for Completion of Testing tablished, but the empirical approaches that currently exist are considerably
better than raw intuition.
A classic question arises every time software testing is discussed: “When are
we done testing-how do we know that we’ve tested enough?” Sadly, there is
no definitive answer to this question, but are a few pragmatic responses 17.2 STRATEGIC ISSUES
and early attempts at empirical guidance.
One response to the above question is this: “You’re never done testing, the
Later in this chapter, we explore a systematic strategy for software testing. But
burden simply shifts from you (the developer) to your customer.” Every time even the best strategy will fail if a series on overriding issues are not
the customer/user executes a computer program, the program is being tested
on a new set of data. This sobering fact underlines the importance of other soft-
ware quality assurance activities. Another response (somewhat cynical, but
nonetheless accurate) is “You’re done testing when you run out of time or you %" data collected during testing
run out of money.”
Although few practitioners argue with these responses, a software
engineer needs more rigorous criteria for determining when testing
predicted failure intensity,
has been conducted. Musa and Ackerman suggest a response that is
based on statistical criteria: “No, we cannot be absolutely certain that the soft-
ware will never fail, but relative to a theoretically sound and experimentally
validated statistical model, we have done testing to say with 95 per- .
cent confidence that the probability of 1000 CPU hours of failure-free opera-
tion in a probabilistically defined environment is at least 0.995.”
Using statistical modeling and reliability theory. models of soft-
ware failures (uncovered during testing) as a function of execution time can be FIGURE 17.4.
developed A version of the Poisson 0
execution-time model, takes the form: I I I I I
function of execution
time execution time,
= + (17.1)
494 PART METHODS FOR ENGINEERING CHAPTER I TESTING 495
dressed. Tom Gilb argues that the following issues must be addressed paths are tested to uncover errors within the boundary of the module. The
if a successful software testing strategy is to be implemented: relative complexity of tests and uncovered errors is limited by the constrained
.
scope established for unit testing. The unit test is normally white-box oriented,
product requirements in a quantifiable manner long before testing and the step can be conducted in parallel for multiple modules.
commences. Although the overriding objective of testing is to errors, a
good testing strategy also assesses other quality characteristics such as
portability, maintainability, and usability (Chapter 18). These should be
specified in a way that is so that testing results are unam- Unit Test Considemtions
biguous.
State testing objectives explicitly. The specific objectives of testing should be The tests that occur as part of unit testing are illustrated schematically in
stated in measurable terms. For example, test effectiveness, test coverage, Figure 17.5. The module interface is tested to ensure that information properly
mean time to failure, the cost to find and fix defects, remaining defect den- flows into and out of the program unit under test. The local data structure is
sity or frequency of occurrence, and test work-hours per regression test examined to ensure that data stored temporarily maintains its integrity dur-
should all be stated within the test plan ing all steps in an algorithm’s execution. Boundary conditions are tested to en-
users of the software and develop a for cat- sure that the module operates properly at boundaries established to limit or re-
egory. Use cases (Chapter 201, which describe the interaction scenario for strict processing. All independent paths (basis paths) through the control
each clans of can roduco by focusing on structure arc exercised to that all statements in a module have been
actual use of the product, at once. And finally, all error handling paths are tested.
flow across a modulo interface are required before any other
Develop a plan that emphasizes “rapid cycle test is initiated. data do not enter and exit properly, all other tests are moot.
recommends that a software engineering team “learn to test in rapid cycles In his text on software testing, Myers proposes a checklist for inter-
percent of project effort) of customer-useful, at least field ‘trialable,’ in- face tests:
crements of functionality and/or quality improvement.” The feedback gen-
erated from these rapid cycle tests can be used to control quality levels and
1. Number of input parameters equal to number of arguments?
the corresponding test strategies.
2. Parameter and argument attributes match?
Build “robust” software that is designed to test Software should be de-
signed in a manner that uses antibugging (Section techniques. That 3. Parameter and argument units systems match?
is, software should be capable of diagnosing certain classes of errors. In ad-
dition, the design should accommodate automated testing and regression
testing.
Use effective formal technical reviews as a filter prior to testing. Formal
technical reviews (Chapter can be as effective as testing in uncovering
ace
errors. For this reason, reviews can reduce the amount of testing effort that
is required to produce high-quality software. local data structures
- - -
Conduct formal technical reviews to assess the test strategy and test cases
boundary conditions
themselves. Formal technical reviews can uncover inconsistencies, omis- -
- I- - _
-
sions, and outright errors in the testing approach. This saves time and also _ _ independent paths
improves product quality.
error handling paths
Develop a continuous improvement approach for the testing process. The
test strategy should be measured. The metrics collected during testing
should be used as part of a statistical process control approach for software
testing.
17.3 UNIT TESTING
Unit testing focuses verification effort on the smallest unit of software FIGURE 17.5.
the module. Using procedural design description as a guide, important Unit test
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER SOFTWARE TESTING STRATEGIES
__
7.
6.
9.
17.3.2 Unit Procedures
498 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING \ CHAPTER I 7: T ESTING STRATEGIES
vidually acceptable imprecision may be magnified to unacceptable levels; global
data structures can present problems-sadly, the list and on.
interface Integration testing is a systematic technique for constructing the program
structure while conducting tests to uncover errors associated with interfacing.
local data structures The objective take unit tested modules and build a program structure that
has dictated by design.
boundary conditions
There is often a tendency to attempt non-incrementalintegration; that is,
independent paths to construct the program using a “big bang” approach. All modules are com-
bined in advance. The entire program is tested as a whole. And chaos usually
error handling paths results! A set of errors are encountered, Correction is difficult because isolation
of causes is complicated by the vast expanse of the entire program. Once these
errors are corrected, new ones appear and the process continues in a seemingly
endless loop.
Incremental integration is the antithesis of the big bang approach. The pro-
stub stub gram is constructed and tested in small segments, where errors are easier to
isolate and correct; interfaces are more likely to be tested completely; and a sys-
tematic test approach may be applied. In the sections that follow, a number of
different incremental integration strategies are discussed.
FIGURE 17.6.
RESUL
Unit test environment
17.4.1 Top-Down Integration
gram” that accepts test case data, passes such data to the module (to be tested),
and prints relevant results. Stubs serve to replace modules that are subordi- Top-down integration is an incremental approach to construction of program
nate to (called by) the module to be tested. A stub or “dummy subprogram” uses structure. Modules are integrated by moving downward through the control hi-
the subordinate module’s interface, may do minimal data manipulation, prints erarchy, beginning with the main control module (main program). Modules sub-
verification of entry, and returns. ordinate (and ultimately subordinate) to the main control module are incorpo-
Drivers and stubs represent overhead. That is, both are software that must rated into the structure in either a depth-first or breadth-first manner.
be developed but that is not delivered with the final product. If dri- As shown in Figure 17.7, depth-first integration would integrate all mod-
vers and stubs are kept simple, actual overhead is relatively low. Unfortunately, ules on a major control path of the structure. Selection of a major path is some-
many modules cannot be adequately unit tested with “simple” overhead soft- what arbitrary and depends on application-specific characteristics. For exam-
ware. In such cases, complete testing can be postponed until the integration ple, selecting the left hand path, modules and would be integrated
test step (where drivers or stubs are also used).
Unit testing is simplified when a module with high cohesion is designed.
When only one function is addressed by a module, the number of test cases is
reduced and errors can be more easily predicted and uncovered.
17.4 INTEGRATION
A neophyte in the software world might ask a seemingly legitimate question
once all modules have been unit tested: “If they all work individually, why do
you doubt that they’ll work when we put them together?” The problem, of
course, is “putting them together”-interfacing. Data can be lost across an in-
terface; one module can have an inadvertent, adverse affect on another; sub-
functions, when combined, may not produce the desired major function;
17.7.
“Integration strategies for object-oriented are discussed in Chapter 22. integration
PART CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 17: SOFTWARE TESTING STRATEGIES 501
first. Next, or (if necessary for proper functioning of would be in-
tegrated. Then, the central and right hand control paths are built.
first integration incorporates all modules directly subordinate at each level,
moving across horizontally. the figure, modules
and would be integrated first. The next control level, and so on,
follows.
The integration process is performed in a series of Display trace Display passed Return value Do table
message parameter table search
(or external file) parameter end
return associated
1. The main control module is used as a test driver, and stubs are substituted output parameter
for all modules directly subordinate to the main control module.
2. Depending on the integration approach selected depth- or FIGURE17.8.
Direction of data flow
first), subordinate stubs are replaced one at a time with actual modules. Stubs
3. Tests are conducted as each module is integrated.
4. On completion of each set of tests, another stub is replaced with the real 17.4.2 Integration
module.
5. Regression testing (Section 17.4.3) may be conducted to ensure that new Bottom-up integration testing, as its name implies, begins construction and
errors have not been introduced. testing with atomic modules (i.e., modules at the lowest levels in the program
structure). Because modules are integrated from the bottom up, processing re-
The process continues from step 2 until the entire program structure is built. quired for modules subordinate to a given level is always available and the
need for stubs is eliminated.
The top-down integration strategy verifies major control or decision
points early in the test process. In a well-factored program structure, deci- A bottom-up integration strategy may be implemented with the following
sion making occurs at upper levels in the hierarchy and is therefore en- steps:
countered first. If major control problems do exist, early recognition is es-
sential. If depth-first integration is selected, a complete function of the 1. Low-level modules are combined into clusters (sometimes called builds)
software may be implemented and demonstrated. For example, consider a that perform a specific software subfunction.
classic transaction structure (Chapter in which a complex series of in- 2 . A driver (a control program for testing) is written to coordinate test case
teractive inputs are requested, acquired, and validated via an incoming path. input and output.
The incoming path may be integrated in a top-down manner. All input pro- 3. The cluster is tested.
cessing (for subsequent transaction dispatching) may be demonstrated
4 . Drivers are removed and moving upward in the pro-
fore other elements of the structure have been integrated. Early demonstra-
tion of functional capability is a confidence builder for both the developer gram structure.
and the customer.
Top-down strategy sounds relatively uncomplicated, but in practice, logis- Integration follows the pattern illustrated in Figure 17.9. Modules are com-
tical problems can arise. The most common of these problems occurs when pro- bined to form clusters 1, 2, and 3. Each of the clusters is tested using a driver
cessing at low levels in the hierarchy is required to adequately test upper lev- (shown as a dashed block). Modules in clusters 1 and 2 are subordinate to M..
els. Stubs replace low-level modules at the beginning of top-down testing; Drivers and are removed, and the clusters are interfaced directly to M,.
therefore, no significant data can flow upward in the program structure. The Similarly, driver for cluster 3 is removed prior to integration with module
tester is left with three choices: delay many tests until stubs are replaced Both and will ultimately be integrated with module M,, and so forth.
with actual modules, develop stubs that perform limited functions that sim- Different categories of drivers are illustrated in Figure 17.10.
ulate the actual module, or integrate the software from the bottom of the As integration moves upward, the need for separate test drivers lessens. In
hierarchy upward. Figure 17.8 illustrates typical classes of stubs, ranging from fact, if the top two levels of program structure are integrated top-down, the
the simplest (stub to the most complex (stub number of drivers can be reduced substantially and integration of clusters is
The approach (delay tests until stubs are replaced by actual modules) greatly simplified.
causes us to lose some control over correspondence between specific tests and
incorporation of specific modules. This can lead to difficulty in determining the
cause of errors and tends to the highly constrained nature of the 17.4.3 Regression Testing
down approach. The second approach is workable, but can lead to significant
overhead, as stubs become more and more complex. The third approach, called Each time a new module is added as part of integration testing, the software
bottom-up testing is discussed in the next section, changes. New data flow paths are established, new may occur, and new
502 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 17: SOFTWARE TESTING STRATEGIES
ensure that changes (due to testing or for other reasons) do not introduce un-
intended behavior or additional errors.
Regression testing may be conducted manually, by re-executing a subset of
all test cases or using automated capture playback tools. Capture-playback
tools enable the software engineer to capture test cases and results far subse-
quent playback and comparison. The regression test suite (the subset of tests
to be executed) contains three different classes of test cases:
!" A representative sample of tests that will exercise all software functions.
!" Additional tests that focus on software functions that are likely to be affected
by the change.
!" Tests that focus on the software components that have been changed.
As integration testing proceeds, the number of regression tests can grow quite
large. Therefore, suite should be designed to include
those tests that address one or more classes of errors in each of the major pro-
gram functions. It is impractical and to re-execute every test for
every program function once a change has occurred.
17.4.4 Comments on Integration Testing
There has been much discussion (e.g., of the relative advantages and
disadvantages of top-down versus bottom-up integration testing. In the
17.9. Bottom-up integration advantages of one strategy tend to result in’disadvantages for the other strat-
egy. The disadvantage of the top-down approach is the need for stubs and
the attendant testing that can be associated with them. as-
sociated with stubs may be offset by the advantage of testing major control
trol logic These changes may cause problems with functions that pre- tions early. The major disadvantage of bottom up integration is that “the pro-
viously worked flawlessly. In the context of an integration test strategy, regres- gram as an entity does not exist until the last module is added” This
sion testing is the re-execution of some subset of tests that have already been drawback is tempered by easier test case design and a lack of stubs.
conducted to ensure that changes have not propagated unintended side effects Selection of an integration strategy depends upon software characteristics
In a broader context, successful tests (of any kind) result in the discovery and sometimes, project schedule. In general, a combined approach (sometimes
of errors, and errors must be corrected. Whenever software is corrected, some called sandwich testing) that uses a top-down strategy for upper levels of the
aspect of the software configuration (the program, its documentation, or the program structure, coupled with a bottom-up strategy for subordinate levels
data that support it) is changed. Regression testing is the activity that helps to may be the best compromise.
As integration testing is conducted, the tester should identify critical
A critical module has one or more of the following characteristics: (1) ad-
dresses several software requirements; has a high level of control (resides
relatively high in the program structure); is complex or error-prone
complexity may be used as an indicator); or has definite performance
requirements. Critical modules should be tested as early as is possible. In ad-
dition, regression tests should focus on critical module function.
invoke send parameter
subordinate from a table parameter 17.4.5 Integration lest Documentation
(or external
FIGURE17.10. An overall plan for integration of the software and a description of specific tests
Direction of
Drivers are documented in a test specification. The specification is a deliverable in the
504 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 17: SOFTWARE TESTING STRATEGIES
I. Scope of Testing a specific domain of the program structure. Therefore, program builds (groups
II. Test Plan of modules) are created to correspond to each phase.
A. Test phases and builds The following criteria and corresponding tests are applied for all test
B. Schedule phases:
C. Overhead software
D. Environment and resources Interface integrity. Internal and external interfaces are tested as each mod-
III. Test Procedure (description of test for build ule (or cluster) is incorporated into the structure.
A. Order of integration Functional Tests designed to uncover functional errors are con-
1. purpose ducted.
2. modules to be tested content. Tests designed to uncover errors associated with local
B. Unit tests for modules in build or global data structures are conducted.
1. description of test for module Performance. Tests designed to verify performance bounds established dur-
2. overhead software description ing software design are conducted.
3. expected results
C. Test environment These criteria and tests associated with them are discussed in this section of
1. special tools or techniques the test specification.
2. overhead software description A schedule for integration, overhead software, and related topics are also dis-
D. Test case data cussed as part of the “Test Plan” section. Start and end dates for each phase are
E. Expected results for build established and availability windows for unit tested modules are defined. A brief
IV. Actual Test Results description of overhead software drivers) concentrates on characteris-
FIGURE 17.11.
tics that might require special effort. Finally, test environments and resources are
Testspecification V. References
described. Unusual hardware configurations, exotic simulators, special test tools
outline VI. Appendices or techniques are a few of many topics that may be discussed in this section.
A detailed testing procedure that is required to accomplish the test plan is
described in the “Test Procedure” section. In outline item III of the test speci-
software engineering process and becomes part of the software configuration.
fication, the order of integration and corresponding tests at each integration
Figure 17.11 presents a test specification outline that may be used as a frame-
step are described. A listing of all test cases (annotated for subsequent refer-
work for this document.
ence) and expected results is also included.
“Scope of Testing” summarizes specific functional, performance and inter-
A history of actual test results, problems or peculiarities is recorded in the
nal design characteristics that are to be tested. Testing effort is bounded; cri-
‘fourth section of the test specification. Information contained in this section
teria for completion of each phusc arc described; and schedule constraints
can be vital during software maintenance. Appropriate references and appen-
are documented.
dices are presented in the final two sections.
The “Test Plan” section describes the overall strategy for integration.
Like all other elements of a software configuration, test specification for-
Testing is divided into phases and builds that address specific functional and mat may be tailored to the local needs of a software development organization.
behavioral characteristics of the software. For example, integration testing for
It is important to note, however, that an integration strategy, contained in a
a computer graphics-oriented CAD system might be divided into the following
test plan, and testing details, described in a test procedure, are essential in-
phases:
gredients and must appear.
!" user interaction (command selection; drawing creation; display representa-
tion; error processing and representation)
17.5 VALIDATION TESTING
!" data manipulation and analysis (symbol creation; dimensioning; rotation;
computation of physical properties)
At the culmination of integration testing, software is completely assembled as
!" display processing and generation (two-dimensional displays; three-dimen-
sional displays; graphs and charts) a package; interfacing errors have been uncovered and corrected, and a
of begin. Validation can be de-
!"database (access; integrity; performance) fined in many ways, but a simple (albeit harsh) definition is that validation suc-
ceeds when software functions in a manner that can be reasonably expected by
Each of these phases and subphases (denoted in parentheses) delineates a the customer. At this point a battle-hardened software developer might protest:
broad functional category within the software and can generally related to “Who or what is the arbiter of reasonable expectations?”
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 17 SOFTWARE TESTING STRATEGIES 507
Reasonable expectations are defined in the software specifi- If software is developed as a product to be used bv manv customers. it is
cation-a document (Chapter 12) that describes all user-visible attributes of impractical to perform formal acceptance tests with each one. Most software
the software. The specification contains a section titled “Validation Criteria.” product builders use a process called and beta testing to uncover errors
Information contained in that section forms the basis for a validation testing that only the end user seems able to find.
approach. The alpha test is conducted at the developer’s site by a customer. The soft-
ware is used in a natural setting with the developer “looking over the shoul-
der” of the user and recording errors and usage problems. Alpha tests are con-
ducted in a controlled environment.
17.5.1 Validation Test Criteria The beta test is conducted at one or more customer sites by the end user(s)
of the software. Unlike alpha testing, the developer is generally not present.
Therefore, the beta test is a “live” application of the software in an environment
Software validation is achieved through a series of black-box tests that demon-
that cannot be controlled by the developer. The customer records all problems
strate conformity with requirements. A test plan outlines the classes of tests to
(real or imagined) that are encountered during beta testing and reports these
be conducted, and a test procedure defines specific test cases that will be used to the developer at regular intervals. As a result of problems reported during
in an attempt to uncover errors in conformity with requirements. Both the plan beta test, the software developer makes modifications and then prepares for re-
and procedure are designed to ensure that all requirements are sat- lease of the software product to the entire customer base.
isfied; all performance requirements are achieved; documentation is correct
and human-engineered; and other requirements are met (e.g., transportability,
compatibility, error recovery, maintainability). 17.6 SYSTEM TESTING
After each validation test case has been conducted, one of two possible con-
ditions exist: (1) The function or performance characteristics conform to speci-
fication and are accepted, or a deviation from specification is uncovered and At the beginning of book, we stressed the fact that software is only one el-
a deficiency list is created. Deviation or error discovered at this stage in a proj- ement of a larger computer-based system. Ultimately, software is incorporated
ect can rarely be corrected prior to scheduled completion. It is often necessary with other system elements (e.g., new hardware, information), and a series of
to negotiate with the customer to establish a method for resolving deficiencies. system integration and validation tests are conducted. These tests fall outside
the scope of the software engineering process and are not conducted solely by
the software developer. However, steps taken during software design and test-
ing can greatly improve the probability of successful software integration in the
Configuration Review larger system.
A classic system testing problem is “finger pointing.” This occurs when an
error is uncovered, and each system element developer blames the other for the
An important element of the validation process is a configuration The problem. Rather than indulging in such nonsense, the software engineer should
tent of the review is ensure that all elements of the software configuration anticipate potential interfacing and design error-handling paths
have been properly developed, are and have the necessary detail that test all information coming from other elements of the system; conduct
support the maintenance phase of the life cycle. The configuration re- a series of tests that simulate bad data or other potential errors at the soft-
view, sometimes called an audit, has in more detail in Chapter 9. ware interface; record the results of tests to use as “evidence” if finger point-
ing does occur; and participate in planning and design of system tests to en-
sure that software is adequately tested.
System testing is a series of tests primary purpose
17.5.3 Alpha and Beta Testing in fully the computer-based Although each test has a dif-
ferent purpose, all work to verify that all system elements have been properly
It is virtually impossible for a developer to foresee how the customer integrated and perform allocated functions. In the sections that follow, we dis-
will really use a program. Instructions for use may be misinterpreted; strange cuss the types tests that are worthwhile for software-based
combinations of data may be regularly used; and output that seemed clear to systems.
the tester may be unintelligible to a user in the field.
When custom software is built. for one customer, a series of
are conducted to enable the customer to validate all requirements. Conducted by
Recovery Testing
the end user rather than the system developer, an acceptance test can range from
an informal “test drive” to a planned and systematically executed series of tests.
In fact, acceptance testing can be conducted over a period of weeks or months, Many computer-based systems must recover from faults and resume process-
thereby uncovering cumulative errors that might degrade the system over time. ing within a prespecified time. In some cases, a system must be fault tolerant;
508 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 509
CHAPTER SOFTWARE TESTING STRATEGIES
that is, processing faults must not cause overall function to cease. In termine how input functions will test cases that require maximum
other cases, a system failure must be corrected within a specified period of time memory or other resources may be executed; (4) test cases that may cause
or severe economic damage will occur. thrashing in a virtual operating system may he designed; or (5) test cases that
Recovery testing is a system test that forces the software to fail in a may cause excessive hunting for disk resident data may be created. Essentially,
ety of ways and verifies that recovery is properly performed. If recovery is au- the tester attempts to break the program.
tomatic (performed by the system itself), re-initialization, checkpointing mech- A variation of stress testing is a technique called sensitivity testing. In some
anisms, data recovery, and restart are each evaluated for correctness. If recovery situations (the most common occur in mathematical algorithms) a very small
requires human intervention, the mean time to repair is evaluated to deter- range of data contained within the bounds of valid data for a program may
mine whether it is within acceptable limits. cause extreme and even erroneous processing or profound performance degra-
dation, This situation is analogous to a singularity in a mathematical function.
Sensitivity testing attempts to combinations within valid input
17.6.2 Security Testing classes that may cause instability or improper processing.
Any computer-based system that manages sensitive information or causes ac-
tions that can improperly harm benefit) individuals is a target for improper
or illegal penetration. Penetration spans a broad range of activities: hackers 17.6.4 Performance Testing
who attempt to penetrate systems for sport; disgruntled employees who at-
tempt to penetrate for revenge; and dishonest individuals who attempt to pen- For real-time and embedded systems, software that provides required function
etrate for illicit personal gain. but does not conform to performance requirements is unacceptable. Performance
Security testing attempts to verify that protection mechanisms built into a testing is designed to test run-time performance of software within the context
system will in fact protect it from improper penetration. To quote of an integrated system. Performance testing occurs throughout all steps in the
“The system’s security must, of course, be tested for invulnerability testing process. Even at the,unit level, the performance of an individual mod-
from frontal attaak-but must also be tested for invulnerability from flank or ule may be assessed as white-box tests are conducted. However, it is not until
rear attack.” all system elements are fully integrated that the true performance of a system
During security testing, the tester plays the role(s) of the individual who can be ascertained.
desires to penetrate the system. Anything goes! The tester may attempt to ac- Performance tests are often coupled with stress testing and require
quire passwords through external clerical means, may attack the system with both hardware and software instrumentation. That is, it is often necessary to
custom software designed to break down any defenses that have been con- measure resource utilization (e.g., processor cycles) in an exacting fashion.
structed; may overwhelm the system, thereby denying service to others; may External instrumentation can monitor execution intervals, log events (e.g., in-
purposely cause system errors, hoping to penetrate during recovery; may browse terrupts) as they occur, and sample machine states on a regular basis. By in-
through insecure data, hoping to the key to system entry; and so on. strumenting a system, the tester can uncover situations that lead to degrada-
Given enough time and resources, good security testing will ultimately pen- tion and possible system failure.
etrate a system. The role of the system designer is to penetration cost
greater than the value of the information that will be obtained.
17.7 THE ART OF DEBUGGING
Stress Testing
Software testing is a process that can be systematically planned and specified.
Test case design can be conducted, strategy can be defined, and results can
During earlier software testing steps, white-box and black-box techniques re- be evaluated against prescribed expectations.
sulted in thorough evaluation of normal program functions and performance. Debugging occurs as a consequence of successful testing. That is, when a
Stress tests are designed to confront programs with abnormal situations. In test case uncovers an error, debugging is the process that results in the removal
essence, the tester who performs stress testing asks: “How high can we crank of the error, Although debugging can and should be an orderly process, it is still
this up before it fails?” very much an art. A software engineer, evaluating the results of a test, is often
Stress testing executes a system in a manner that demands resources ip confronted with a “symptomatic” indication of a software problem. That is, the
abnormal quantity, frequency, or volume. For example, special may be external manifestation of the error and the internal cause of the error may
designed that 10 interrupts per second, when one or two is the aver- have no obvious relationship to one another. The poorly understood mental
age rate; input data rates may be increased by an order of magnitude to de- process that connects a symptom to a cause is debugging.
510 PART THREE. CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 17: SOFTWARE TESTING STRATEGIES 511
5. The symptom may be a result of timing problems, rather than processing
problems.
6. It may be to accurately reproduce input conditions (e.g., a real-time
application in which input ordering is indeterminate).
7. The symptom may be intermittent. This is particularly common in embed-
ded systems that couple hardware and software inextricably.
8. The symptom may be due to causes that are distributed across a number
cases of tasks running on different processors
Suspected During debugging, we encounter errors that range from mildly annoying
. . .
(e.g., an Incorrect to (e.g. the system fails, causing
serious economic or damage). As the consequences of an error increase,
the amount of pressure to find the cause also increases. Often, pressure forces
FIGURE17.12. a software developer to fix one error and at the same time introduce two more.
Debugging
17.7.2 psychological Considerations
17.7.1 The Debugging Process
Unfortunately, there appears to be some evidence that debugging prowess is an
Debugging is testing, but it always occurs as a consequence of As innate human trait. Some people are good at it, and others aren’t. Although ex-
shown in Figure 17.12, the debugging process begins with the execution of a perimental evidence on debugging is open to many interpretations, large vari-
test case. Results are assessed and a lack of correspondence between expected ances in debugging ability have been reported for programmers with the same
and actual is encountered. In many cases, the non-corresponding data is a educational and experiential background.
symptom of an underlying cause as yet hidden. The debugging process at- Commenting on the human aspects of debugging, Shneiderman
tempts to match symptom with cause, thereby leading to error correction. states:
The debugging process will always have one of Lwo outcomes: The cause
will be found, corrected, and removed, or the cause will not be found. In the
Debugging is one of the more frustrating parts of programming. It has
latter case, the person performing debugging may suspect a cause, design a test of problem solving or brain teasers, coupled with the annoying recognition that
case to help validate his or her suspicion, and work toward error correction in you have made a mistake. Heightened anxiety, and the unwillingness to accept
an iterative fashion. the possibility of errors, increases the task difficulty, Fortunately, there is a
Why is debugging so difficult? In all likelihood, human psychology (see the
great sigh of relief and a lessening of tension when the bug is ultimately . . .
next section) has more to do with an answer than does software technology. corrected.
However, a few characteristics of bugs provide some clues:
Although it may be to “learn” debugging, a number of approaches to
1. The symptom and the cause may be geographically remote. That is, the
the problem can be proposed. We examine these in the next section.
symptom may appear in one part of a program, while the cause may actu-
ally be located at a site that is far removed. Highly coupled program struc-
tures 14) exacerbate this situation.
2. The symptom may disappear (temporarily) when another error is corrected. 17.7.3 Debugging Approaches
3. The symptom may actually be caused by nonerrors (e.g., round-off inaccu-
racies). Regardless of the approach that is taken, debugging has one overriding objec-
4. The symptom may be caused by human error that is not easily traced. tive: find and correct the cause of a software error. The objective is realized
by a combination of systematic evaluation, intuition, and luck. Bradley
describes the debugging approach in this way:
“In making this statement, we take the broadest possible view of testing.Not only does the
developer test prior to release, but the customer/user tests time it Debugging is a straightforward application of the scientific method that has
used! been developed over 2,500 years. The basis of debugging is locate the
512 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 17: TESTING STRATEGIES 513
source [the cause] by binary partitioning, through working hypotheses Once a bug has been found, it must be corrected. But as we have already
that predict new values to be examined. noted, the correction of a bug can introduce other errors and therefore do more
Take a simple non-software example: A lamp in my house does not work. harm than good. Van suggests three simple questions that every
If nothing in the house works, the cause must be in the main circuit breaker software engineer should ask before making the “correction” that removes the
or outside; I look around to see whether the neighborhood is blacked out. I plug cause of a bug:
the suspect lamp into a working socket and a working appliance into the sus-
pect circuit. So goes the alternation of hypothesis and test. Is the cause of the bug reproduced in another part of the program? In many
situations, a program error is caused by an erroneous pattern of logic that
In three for debugging nppronchcs may be proposed may be reproduced elsewhere. Explicit consideration of the logical pattern
may result in the discovery of other errors.
,
What “next bug” might introduced by the I’m about to make? Before
!"brute force the correction is made, the source code (or better, the design) should be
evaluated to assess coupling of logic and data structures. If the correction
!" backtracking is to be made in a highly coupled section of the program, special care must
!" cause elimination be taken when any change is made.
What could we have done to prevent this bug in the first place? This ques-
The brute force category of debugging is probably the most common and tion is the first step toward establishing a statistical software quality as-
least efficient method for isolating the cause of a software error. We apply brute surance approach (Chapter 8). If we correct the process as well as the prod-
force debugging methods when all else fails. Using a “let the computer find the uct, the bug will be removed from the current program and may be
error” philosophy, memory dumps are taken, run-time traces are invoked, and eliminated from all future programs.
the program is loaded with WRITE statements. We hope that somewhere in the
morass of information that is produced we will a clue that can lead us to
the cause of an error. Although the mass of information produced may ulti-
7.8 SUMMARY
mately lead to success, it more frequently leads to wasted effort and time.
Thought must be expended first!
Backtracking is a fairly common debugging approach that can be used suc- Software testing accounts for the largest percentage of technical effort in the
cessfully in small Beginning the site where a symptom hns been software process. Yet we are only beginning to understand the subtleties of
uncovered, the source code is traced backward (manually) until the site of the test planning, execution and control.
cause is found. Unfortunately, number of source lines increases, the The objective of software testing is to uncover errors. To fulfill this
number of series of test steps-unit, and system tests--are
The third approach to debugging-cause elimination-is manifested by in- planned and executed. Unit and integration tests concentrate on functional ver-
duction or deduction and introduces the concept of binary partitioning. Data re- ification of a module and incorporation of modules into a program structure.
lated to the error occurrence are organized to isolate potential causes. A “cause Validation testing demonstrates traceability to software requirements, and
hypothesis” is devised and the data are used to prove or disprove the hypothe- system testing validates software once it has been incorporated into a larger
sis. Alternatively, a list of all possible causes is developed and tests are con- system.
ducted to eliminate each. If initial tests indicate that a particular cause hy- Each test step is accomplished through a series of systematic test tech-
pothesis shows promise, the data are refined in an attempt to isolate the bug. niques that assist in the design of test cases. With each testing step, the level
Each of the above debugging approaches can be supplemented with de- of abstraction with which software is considered is broadened.
bugging tools. We can apply a wide variety of debugging compilers, dynamic de- Unlike testing (a systematic, planned activity), debugging must be viewed
bugging aids (“tracers”), automatic test case generators, memory dumps, and as an art. Beginning with a symptomatic indication of a problem, the debug-
cross-reference maps. However, tools are not a substitute for careful evaluation ging activity tracks down the cause of an error. Of the many resources avail-
based on a complete software design document and clear source code. able during debugging, the most valuable is the counsel of other software en-
Any discussion of debugging approaches and tools is incomplete without gineers.
mention of a powerful ally: other people! Each of us can recall puzzling for The requirement for higher-quality software demands a more systematic
hours or days over a persistent bug. A colleague wanders by and in desperation approach to testing. To quote Dunn and Ullman
we explain the problem and throw open the listing. Instantaneously (it seems),
the cause of the error is uncovered. Smiling smugly, our colleague wanders off. What is required is an overall strategy, spanning the strategic test space, quite
A fresh viewpoint, unclouded by hours of frustration, can do wonders. A final as deliberate in its methodology as was the systematic development on which
maxim for debugging might be: all else fails, get help!” analysis, design and code were based.
514 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 17: SOFTWARE TESTING STRATEGIES 515
In this chapter, we have examined the “strategic test space,” considering the 17.6. Add at least three additional questions to each segment of the unit test
steps that have the highest likelihood of meeting the overriding test objective: checklist presented in Section 17.3.1.
to find and remove errors in an orderly and effective manner. 17.6. The concept of “antibugging” (Section is an extremely effective way
to provide built-in debugging assistance when an error is uncovered.
a. Develop a set of guidelines for
REFERENCES b. Discuss advantages of using the technique.
Discuss disadvantages.
B.. and Quality Assurance, Van Nostrand 17.7. Develop an testing strategy for the any one of the systems im-
Reinhold, 1984. plemented in problems 14.23 through 14.31. Define test phases, note the or-
Boehm, B., Software Engineering Economics, Prentice-Hall, 1981, 37. der of integration, specify additional test software, and justify your order of
Bradley, J.H., “The Science and Art of Debugging,” integration. Assume that all modules have been unit tested and are avail-
August 19, 1985, pp. 35-38. able. it may be necessary to do a bit of design work first.]
Brown, A., and W. Debugging, American 17.8. How can project scheduling affect integration testing?
New York, 1973.
Cheung, W.H., J.P. Black, and E. Manning, “A Framework for Distributed 17.9. 1s unit testing possible or even desirable in all circumstances? Provide ex-
amples to justify your answer.
Debugging,” Software, January 1990, pp.
Dunn; R., and R. Ullman, Quality Assurance for Computer Software, 17.10. Who should perform the validation test-the software developer or the soft-
McGraw-Hill, 1982, p. 158. ware user? Justify your answer.
Gilb, T., “What We Fail To Do In Our Current Testing Culture,” 17.11. Develop a complete test strategy for the system discussed earlier
Techniques Newsletter, (on-line edition, Software Re- in this book. Document it in a test specification.
search, Inc., San Francisco, January 1995. 17.12. As a class project, develop a debugging guide for your installation, The guide
Miller, E., “The Philosophy of Testing,” in Program Testing Techniques, should provide language and system oriented hints that have been learned
IEEE Computer Society Press, 1977, pp. l-3. through the school of hard knocks! Begin with an outline of topics that will
J.D., and Ackerman, “Quantifying Software Validation: When be reviewed by the class and your instructor. Publish the guide for others in
to Stop Testing?” Software, May 1989, pp. 19-27. your local environment.
Myers, G., The Art of Software Testing, Wiley, 1979.
Shooman, M.L., Software Engineering, McGraw-Hill, 1983.
Shneiderman, B., Software Psychology, Winthrop Publishers, 1980, p. 28.
Van “Three Questions About Each Bug You Software FURTHER READINGS AND OTHER INFORMATION RESOURCES
WAN891
Engineering Notes, vol. 14, no. 5, July 1989, pp. 62-63.
Wallace, D.R., and R.U. “Software Verification and Validation: An A detailed discussion on tasting strategies can be found in books by Kit
Overview,” IEEE Software, May 1989, pp. Testing in the Real World, Addison-Wesley, Evans (Productive
E., Techniques of Program Structure and Design, Prentice-Hall, Test Management, Wiley-Interscience, Hetzel Complete Guide to
1975. Software QED Information Sciences, Beizer Ould and
in Software Cambridge University Press,
Marks (Testing Rig Systems, McGraw-Hill, and et al.
PROBLEMS AND POINTS TO PONDER Computer Software, 2nd edition, Van Nostrand Reinhold, 1993). Each delin-
eates the steps of an effective strategy, provides a set of techniques and guide-
17.1. Using your own words, describe the difference between verification and val- lines and suggests procedures for controlling and tracking the testing process.
idation Do both make use of test case design methods and testing Hutcheson (Software Testing Methods and Metrics, McGraw-Hill, 1996) pre-
--- sents testing methods and strategies but also provides a detailed discussion of
how measurement can be used to achieve efficient testing.
17.2. List some problems that might be associated with the creation of an inde-
For individuals that build product software, Gunther’s book (Management
pendent test group. Are an ITG and an SQA group made up of the same peo-
ple?
Methodology for Software Product Engineering, Wiley-Interscience, 1978)
remains a useful guide for the establishment and conduct of effective test
17.2. Is it always possible to develop a strategy for testing that uses the strategies. In addition, Perry to Test Software Packages, Wiley, 1986)
sequence of testing steps described in section What are possible com- provides useful information for both the product builder and the purchaser.
plications that might arise for embedded systems? Mosley (Real World Issues in Client-Server Software Testing, Prentice-Hall,
17.4. If you could only select three test case design methods to apply during unit 1996) addresses strategies and techniques for testing client/server based
testing, what would they be and why? applications.
516 PART THREE: CONVENTIONAL METODS
H FOR SOFTWARE ENGINEERING
Guidelines for debugging are contained in a book by Dunn (Software Defect
Removal, McGraw-Hill, 19841. presents an interesting “taxon-
omy of bugs” that can lead to effective methods for test planning. McConnell
(Code Complete, Microsoft Press, 1993) presents pragmatic advice on unit and
TECHNICAL METRICS
integration testing as well as debugging.
Internet sources for software testing are presented in the “Further Readings
and Other Information Resources” sections of Chapters 16 and 22.
FOR ‘SOFTWARE
key element of any engineering process is measurement. We use mea-
sures to better understand the attributes of the models that we create.
But most important, we use measurement assess the quality of the engi-
neered products or systems that we build.
Unlike other engineering disciplines, software engineering is not grounded
in the basic quantitative laws of physics. Absolute measures, such as voltage,
mass, velocity, or temperature, are uncommon in the software world. Instead,
we attempt to derive a set of indirect measures that lead to metrics that pro-
vide an indication of the quality of some representation of software. Because
software measures and metrics are not absolute, they are open to debate.
Fenton addresses this issue when he states:
Measurement is the process by which numbers or symbols are assigned to the
attributes of entities in the real world in such a way as to define them accord-
ing to clearly defined rules.
In the physical sciences, medicine, economics, and more recently the social
sciences, we are now able to measure attributes that we previously thought to
be unmeasurable. Of course, such measurements are not as refined as many
measurements in the physical sciences. . , but they exist land important deci-
sions are made based on them]. We feel that the obligation to attempt to -mea-
sure the unmeasurable” in order to improve our understanding of particular
entities is as powerful in software engineering as in any discipline.
But some members of the software community continue to argue that software
is unmeasurable or that attempts at measurement should be postponed until
517
518 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
CHAPTER TECHNICAL METRICS FOR SOFTWARE
519
we better understand software and the attributes that should be used to de-
scribe it. This is a mistake. 18.1.1 McCall’s Quality Factors
Although technical metrics for computer software are not absolute, they
provide us with a systematic way to assess quality based on a set of “clearly The factors that affect software quality can be categorized in two broad groups:
defined rules.” They also provide the software engineer with on-the-spot rather factors that can be directly measured (e.g., defects per function point) and
than after-the-fact insight. This enables the engineer to discover and correct factors that can be measured only indirectly (e.g., usability or maintain-
potential problems before they become catastrophic defects. ability). In each case measurement must occur. We must compare the software
In Chapter 4 we discussed as they are applied at the (documents, programs, data) to some datum and arrive at an indication of
process and project level. In this chapter, our focus shifts to measures that can quality.
be used to assess the quality of the product as it is being engineered. These McCall and his colleagues proposed a useful categorization of fac-
measures of internal product attributes provide the software engineer with a tors that affect software quality. These software quality factors, shown in Figure
real-time indication of the efficacy of the analysis, design, and code models; the 18.1, focus on three important aspects of a software product: its operational
effectiveness of test cases; and the overall quality of the software to be built. characteristics, its ability to undergo change, and its adaptability to new envi-
ronments.
Referring to the factors noted in Figure 18.1, McCall provides the follow-
ing descriptions:
18.1
Correctness. The extent to which a program satisfies its specification and
Even the most jaded software developers will agree that high-quality software is
fulfills the customer’s mission objectives.
an important goal. But how do we define quality? A wag once said, “Every pro-
gram does something right, it just may not be the thing that we want it to do.” Reliability. The extent to which a program can be expected to perform its
In Chapter 8 we proposed a number of different ways to look at software intended function with required precision. It should be noted that other,
quality and introduced a definition that stressed conformance to explicitly more complete, definitions of reliability have been proposed (see Chapter 8).
stated functional and performance requirements, explicitly documented devel- The amount of computing resources and code required by a pro-
opment standards, and implicit characteristics that are expected of all profes- gram to perform its function.
sionally developed software. Integrity. The extent to which access to software or data by unauthorized
There is little question that the above could be modified or ex- persons can be controlled.
tended and debated endlessly. For the this book, the definition
serves to emphasize three important points: Usability. The effort required to learn, operate, prepare input, and inter-
pret output of a program.
Software requirements are the foundation from which quality is measured. Maintainability. The effort required to locate and fix an error in a program.
Lack of conformance to requirements is lack of quality.’ is a very limited definition.)
Specified standards define a set of development criteria that guide the The effort required to modify an operational program.
manner in which software is engineered. If the criteria are not followed, Testability. The effort required to test a program ensure that it performs
lack of quality will almost surely result. its intended function.
There is a set of implicit that often goes unmentioned (e.g.,
the desire for good maintainability). If conforms to its explicit re-
quirements, but fails to meet implicit requirements, software quality is sus-
pect.
Software quality is a complex mix of factors that will vary across different ap-
plications and the customers who request them. In the sections that follow, soft-’
ware quality factors are identified and the human activities required to achieve
them are described.
‘It is important to that quality extends to the technical attributes of the analysis, design,
and code models. Models that exhibit high quality (in the technical sense) will lead soft-
ware that exhibits high quality from the customer’s point of view.
quality Correctness Reliability Usability Integrity Efficiency
520 PART THREE. CONVENTIONAL METHODS SOFTWARE ENGINEERING CHAPTER TECHNICAL METRICS FOR SOFTWARE 521
Portability. The effort required to transfer the program from one hardware Self-documentation. The degree to which the source code provides mean-
and/or software system environment to another. ingful documentation.
Reusability. The extent to which a program parts of a program] can be Simplicity. The degree to which a program can be understood without dif-
reused in other applications-related to the packaging and scope of the ficulty.
functions that the program performs. Software system independence. The degree to which the program is inde-
The effort required to couple one system to another. pendent of nonstandard programming language features, operating system
characteristics, and other environmental constraints.
It is and in some cases impossible, to develop direct measures of Traceability. The ability to trace a design representation or actual program
the above quality factors. Therefore, a set of metrics are defined-and used to de- component back to requirements.
velop expressions for each of the factors according to the following relationship: The degree to which the software assists in enabling new users
= + x to apply the system.
where is a software quality factor, are regression coefficients, and are The relationship between software quality factors and the metrics listed
the metrics that affect the quality factor. Unfortunately, many of the metrics above is shown in Figure 18.2. It should be noted that the weight given to each
defined by McCall can only be measured subjectively. The metrics may be in metric depends on local products and concerns.
the form of a checklist that is used to “grade” specific attributes of the software
The grading scheme proposedby McCall is a 0 (low) to 10 (high) scale.
The following metrics are used in the grading scheme:
Audibility. The ease with which conformance to standards can be checked. 18.1.2 FURPS
Accuracy. The precision ofcomputations and control.
to which standard interfaces, The quality factors described by McCall and his colleagues represent
protocols, and bandwidth are used. one of a number of suggested “checklists” for software quality. Hewlett-Packard
Completeness. The degree to which full implementation has developed a set of software quality factors that has been given the
tion has been achieved. acronym FURPS-functionality, usability, reliability, performance, and sup-
portability The FURPS quality factors draw liberally from earlier work, defin-
Conciseness. The compactness of the program in terms of lines of code.
ing the following attributes for each of the major factors:
Consistency. The use of uniform design and documentation techniques
throughout the software development project. !" Functionality is assessed by evaluating the feature set and capabilities of the
Data commonality. The use of standard data structures and types through- program, the generality of the functions that are delivered, and the security
out the program. of the overall system.
Error tolerance. The damage that occurs when the program encounters an !" Usability is assessed by considering human factors (Chapter overall aes-
error. thetics, consistency, and documentation.
Execution efficiency. The run-time performance of a program. !" Reliability is evaluated by measuring the frequency and severity of failure,
The degree to which architectural, data, or procedural de- the accuracy of output results, the mean time between failures the
sign can be extended. ability to recover from failure, and the predictability of the program.
Generality. The breadth of potential application of program components. !" Performance is measured by processing speed, response time, resource con-
sumption, throughput, and efficiency.
Hardware independence. The degree to which the software is decoupled
from the hardware on which it operates. !" Supportability combines the ability to extend the program (extensibility),
adaptability, and serviceability (these three attributes represent a more
Instrumentation. The degree to which the program monitors its own oper-
term-maintainability), as well as testability, compatibility,
ation and identifies errors that do occur.
[the ability to organize and control elements of the software configura-
Modularity. The functional independence (Chapter of program compo- tion (Chapter the ease with which a system can be installed, and the ease
nents with which problems can be localized.
Operability. The ease of operation of a program.
Security. The availability of mechanisms that control or protect programs The FURPS quality factors and attributes described above can be used to
and data. establish quality metrics for each activity in the software process.
METRICS FOR SOFTWARE 523
522 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
Subjectivity and specialization also apply to determining software quality
To help solve this problem, a more precise definition of software quality is
needed as well as a way to derive quantitative measurements of qual-
ity for objective analysis. Since there is no such thing as absolute knowl-
edge, one should not expect to measure software quality exactly, for every mea-
surement is partially imperfect. Jacob Bronkowski described this paradox of
knowledge in this way: “Year by year we devise more precise instruments with
which to observe nature with more fineness. And when we look at the obser-
vations we are discomfited to see that they are still fuzzy, and we feel that they
Auditability are as uncertain as ever.”
Accuracy
Communication In the sections that follow, we examine a set of software metrics that can
commonality be applied to the quantitative assessment of software quality. In all cases, the
Completeness metrics represent indirect measures; that is, we never really measure quality
Complexity but rather some manifestation of quality. The complicating factor is the pre-
Concision cise relationship between the variable that is measured and the quality of
Consistency software.
Data
Error tolerance
Execution efficiency 18.2‘ A FRAMEWORK FOR TECHNICAL SOFTWARE METRICS
Expandability
Generality
Hardware As we noted in the introduction to this chapter, measurement assigns numbers
lnstumentation or symbols to attributes of entities in the real world. To accomplish this, a mea-
Modularity surement model encompassing a consistent set of rules is required. Although
Operability the theory of measurement (e.g., and its application to computer soft-
Security ware (e.g., are topics that are beyond the scone of this book,
Self documentation it is worthwhile to establish a fundamental framework and a set of basic prin-
Simplicity ciples for the measurement of technical metrics for software.
System
Traceability
Training I
18.2. 18.2.1 The Challenge of Technical Metrics
factors and (Adapted from Arthur, L. A., Measuring Programmer Productivity and Software
metrics Quality, Wiley-Interscience, 1985.) Over the past two decades, many researchers have attempted to develop a sin-
gle metric that provides a comprehensive measure of software complexity.
Fenton characterizes this research as a search for “the impossible holy
The Transition to a Quantitative View grail.” Although dozens of complexity measures have been proposed
each takes a somewhat different view of what complexity is and what attri-
butes of a system lead to complexity. By analogy, consider a metric for evalu-
In the preceding sections, a set of qualitative factors for the “measurement* of ating an attractive car. Some observers might emphasize body design, others
software quality were discussed. We strive to develop precise measures for soft- might consider mechanical characteristics, still others might tout cost, or per-
ware quality and are sometimes frustrated by the subjective nature of the ac- , formance, or fuel economy, or the ability to recycle when the car is junked. Since
tivity. Cavano and McCall discuss this situation: any one of these characteristics may be at with others, it is to de-
rive a single value for “attractiveness.” The same problem occurs for computer
The determination of quality is a key factor in everyday events--wine tasting software.
contests, sporting events [e.g., talent contests, etc. In these situa- Yet there is a need to measure and control software complexity And if a
tions, quality is judged in the most fundamental and direct manner: side by single value of this “quality metric” is to derive, it should be possible
side comparison of objects under identical conditions and with predetermined to develop measures of different internal program attributes (e.g., effective
concepts. The wine may be judged according to clarity, color, bouquet, taste, etc. modularity, functional independence, and other attributes discussed in Chapter
However, this type of judgement is very subjective; to have any value at all, it 13). These measures and the metrics derived from them can be used as
must be made by an expert.
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER TECHNICAL METRICS FOR SOFTWARE 525
indicators of the quality of analysis and design models. But here again, !" analysis-the computation of metrics and the application of mathematical
problems arise. Fenton notes this when he states:
!" evaluation of metrics results in an effort to gain insight
The danger of attempting to find measures which characterize so many differ- into the quality of the representation
ent attributes is that inevitably the measures have to satisfy conflicting aims. !"feedback-recommendations derived from the interpretation of technical met-
This is counter to the representational theory of measurement. rics transmitted to the software team
Although Fenton’s statement is people argue that technical mea- The principles that can be associated with the formulation of technical metrics
surement conducted during the early stages of the software process provides
are these
engineers with a consistent and objective mechanism for assessing
quality.
It is fair to ask, however, just how valid technical metrics are. That is, how !" The objectives of measurement should be established before data collection
begins.
closely aligned are technical metrics to the long-term reliability and quality of
a computer-based system? Fenton addresses this question in the fol- !" Each technical metric should be defined in an unambiguous manner.
lowing way: !" Metrics should be derived based on a theory that is valid for the domain of
application (e.g., metrics for design should draw upon basic design concepts
In spite of the intuitive connections between the internal structure of and principles, and should attempt to provide an indication of the presence
products [technical metrics1 and its external product and process attributes, of an attribute that is deemed desirable).
there have actually been very few scientific attempts to specific rela- !" Metrics should be tailored to best accommodate specific products and
tionships. There are a number of reasons why this is so; the most commonly processes
cited is the impracticality of conducting relevant experiments.
Although formulation is a critical starting point, collection and analysis are the
Each of the challenges noted above is a cause for caution, but it is not reason activities that drive the measurement process. Roche suggests the fol-
to dismiss technical Measurement is essential if quality is to be lowing principles for these activities:
achieved.
!" Whenever possible, data collection and analysis should be automated.
!" Valid statistical techniques should be applied to establish relationships be-
tween internal product attributes and external quality characteristics (e.g.,
18.2.2 Measurement is the level of architectural complexity correlated with the number of defects
reported in production use?).
Before we introduce a series of technical metrics that assist in the evalua- !" Interpretative guidelines and recommendations should be established for
tion of the analysis and design models, provide an indication of the com- each metric.
plexity of procedural designs and source code, and facilitate the design of
more effective testing, it is important to understand basic measurement prin-
to the principles noted above, the success of a metrics activity is
ciples. Roche suggests a measurement process that can be character-
also tied to management support. Funding, training, and promotion must all be
ized by five activities:
considered if a technical measurement program is to be established and
tained.
!" formulation-the derivation of software measures and metrics that are ap-
propriate for the representation of software that is being considered
!" collection-the mechanism used to accumulate data required to derive the 18.2.3 The Attributes of Effective Software Metrics
formulated metrics
Hundreds of metrics have been proposed for computer software, but not all pro-
vide practical support to the software engineer. Some demand measurement
that is too complex, others are so that few real-world professionals
vast literature on software metrics (e.g., for extensive have any hope of understanding them, and others violate the basic intuitive
of high-quality software really is.
in this chapter) is common. However, many of the critiques focus on esoteric issues and miss
the of measurement in the real world: to help the engineer establish sys- Ejiogu defines a set of attributes that should be encompassed by
tematic and objective way to gain insight into his or her work and to improve product qual- effective software metrics. The derived metric and the measures that lead to it
ity result. should be:
METRICS FOR SOFTWARE 527
526 PART THREE CONVENTIONAL ENGINEERING
with the intent of predicting the “size” of the resultant system. It is likely that
!" simple and computable. It should be relatively easy to learn how to derive size and design complexity will be directly correlated.
the metric, and its computation should not demand inordinate effort or time.
!" empirically and intuitively persuasive. The metric should satisfy the engi-
neer’s intuitive notions about the product attribute under consideration (e.g.,
a metric that measures module cohesion should increase in value as the level Function-Based Metrics
of cohesion increases).
!" consistent and objective. The metric should always yield results that are
The function point metric (Chapter 4) can be used as a means for pre-
ambiguous. An independent third party should be able to derive the same dicting the size of a system that will be derived from the analysis model. To il-
metric value using the same information about the software. lustrate the use of the FP metric in this context, we consider a simple analy-
sis model representation illustrated in Figure 18.3. In the figure, a data flow
consistent in its use of units and dimensions. The mathematical computation
diagram (Chapter for a function within the is repre-
of the metric should use measures that do not lead to bizarre combinations sented. The function manages user interaction, accepting a user password to
of units. For example, multiplying people on the project teams by program- activate/deactivate the system and allowing inquiries on the status of security
ming language variables in the program results in a suspicious mix of units zones and various security sensors. The function displays a series of prompting
that are not intuitively persuasive. messages and sends appropriate control signals to various components of the
!" programming language independent. Metrics should be based on the analy- security system.
sis model, the design model, or the structure of the program itself. They The data flow diagram is evaluated to determine the key measures re-
should not depend on the vagaries of programming language syntax or se- quired for computation of the function point metric (Chapter 4):
mantics.
!" an effective mechanism for quality feedback. The metric should provide a soft- !"number of user inputs
ware engineer with information that can lead to a higher quality end prod- !"number of user outputs
uct.
!" number of user inquiries
!" number of files
Although most software metrics satisfy the above attributes, some commonly
used metrics may fail to satisfy one or two. An example is the function point !" number of external interfaces
(discussed in Chapter 4 and again in this chapter). It can be argued3 that the
consistent and objective attribute fails because an independent third party may
not be able to derive the same function point value as a colleague using the is home security system that has been used an example application in earlier
same about the software. Should we therefore reject the FP mea- chapters.
sure? The answer is “of course not!” FP provides useful insight and therefore
provides distinct value, even if it fails to satisfy one attribute perfectly.
18.3 METRICS FOR THE ANALYSIS MODEL
password
Technical work in software engineering begins with the creation of the analy- zone inquiry
sis It is at this stage that requirements are derived and that a foun-
dation for design is established. Therefore, technical metrics that provide in- User
sight into the quality of the analysis model are desirable.
Although relatively few analysis and specification metrics have appeared
in the literature, it is possible to adapt metrics derived for project application
(Chapter 4) for use in this context. These metrics examine the analysis model
password,
18.3.
“Please note that equally vigorous can also be made. Suchis the nature Part of the analysis
of software metrics. model for System configuration data
analysis model encompasses representations of data. function, behavior. For addi- software
tional information, see Chapters 11 and 1‘2.
528 PART THREE: CONVENTIONAL METHODS FOR ENGINEERING CHAPTER METRICS FOR SOFTWARE
Three user inputs: password, panic button, and activate/deactivate are 18.3.2 The Bang Metric
shown in the figure along with two inquires: zone inquiry and sensor in-
quiry. One file (system configuration file) is shown. Two user outputs (mes- Like the function point metric, the bang metric can be used develop an in-
sages and sensor status) and four external interfaces (test sensor, zone set- dication of the size of the software to be implemented as a consequence of the
ting, activate/deactivate, and alarm alert) are also present. These data, analysis model. Developed by Tom the bang metric is “an
along with the appropriate complexity, are shown in Figure 18.3. implementation independent indication of system size.” To compute the bang
The count-total shown in Figure 18.4 must be adjusted using equation metric, the software engineer must first evaluate a set of
(4.1): of the analysis model that are not further subdivided at the analysis level.
Primitives are determined by evaluating the analysis model and de-
FP = count-total x (0.65 0.01 x
veloping counts for the following
where count-total is the sum of FP entries obtained from Figure 18.3 and
= 1 to 14) are “complexity adjustment values.” For the purposes of this ex- Functional primitives Transformations (bubbles) that appear at
ample, we assume that is 46 moderately complex product). Therefore, the lowest level of data flow diagram (Chapter 12).
Data elements (DE).The attributes of a data object, data elements are
FP = 50 X + (0.01 x = 56 not composite data and appear within the data dictionary.
Based on the projected FP value derived from the analysis model, the project Objects Data objects as described in Chapter 11.
team can estimate the overall implemented size of the user interac- Relationships The connections between data objects as described
tion function. Assume that past data indicate that one FP translates into 60 in Chapter 12.
lines of code (an object-oriented language is to be used) and that 12 FP are pro- States (ST). The number of user observable states in the state-transition
duced for each person-month of effort. These historical data provide the project diagram (Chapter 12).
manager with important planning information that is based on the analysis
Transitions The number of state transitions in the state-transition
model rather than preliminary estimates.
diagram (Chapter 12).
In addition to the six primitives noted above, the additional counts are deter-
mined for:
Modified manual function Functions that lie out-
Weighting Factor side the system boundary and that must be modified to accommodate the
new system.
0
measurement parameter count simple average complex Input data elements Those data elements that are input to the
system.
numb& of user inputs 3 3 4 6
Output data elements Those data elements that are output from
the system.
number of user outputs 2 4 5 7 8
0
Retained data elements Those data elements that are retained
(stored) by the system.
number of user inquiries 2 3 4 6 6 Data Tokens The data tokens (data items that are not subdivided
number of files 1 x 0 7 10 15 = 7
within a functional primitive) that exist at the boundary of the
tional primitive (evaluated for each primitive).
Relationship connections
func-
The relationships that connect the
number of external interfaces 4 X 5 7 object in the data model to other objects.
count-total
“The acronym noted in parentheses following the primitive is used denote the count of the
particular primitive; e.g.. indicates the number of functional primitives present in
FIGURE 18.4. Computing user function model.
530 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
CHAPTER TECHNICAL METRICS FOR SOFTWARE
DeMarco suggests that most software can be allocated to one of two The assessed weight noted in the above algorithm is determined from 16 dif-
domains, function-strong or data-strong, depending upon the ratio
ferent classes of functional primitives defined by DeMarco. A weight ranging
Function-strong applications (commonly encountered in engineering and sci-
from 0.6 (simple data routing) to 2.5 (data management functions) is assigned
entific applications) emphasize the transformation of data and do not gener-
depending on the class of the primitive.
ally have complex data structures. Data-strong applications (commonly en- For data-strong applications, the bang metric is computed using the fol-
countered in systems applications) tend to have complex data
lowing algorithm:
models.
set initial value of 0;
0.7 implies a function-strong application do while objects to be evaluated in the data mode
0.8 1.4 implies a hybrid application compute count of relationships for object i;
compute corrected OB increment
1.5 implies a data-strong application
Because different analysis models will partition the model to greater or lessor
degrees of refinement, DeMarco suggests that an average token count per The corrected is also determined from a table published by DeMarco. An
primitive abbreviated version is shown below: ,
be used to control uniformity of partitioning across many different models 1.0
within an application domain. 3 4.0
To tho bang metric for function-strong applications, the following
algorithm is used:
computed, history can be used to associ-
ate it with and effort. DeMarco suggests that an organization build its own
set initial value of versions of the CFuPI and COB1 tables to use for calibrating information from
do while functional primitives remain to be evaluated completed software projects.
compute token-count around the boundary of primitive i;
compute increment
primitive to class;
Assess class and note assessed weight; Metrics for Specification Quality
Multiply CFuPI by the assessed weight;
bang CFuPI; and propose a list of characteristics that can be
used to assess the quality of the analysis model and the corresponding require-
ments specification: specificity (lack of ambiguity), completeness, correctness,
understandability, verifiability, internal and external consistency, achievability,
The token-count is computed by determining how many separate tokens are concision, traceability, modifiability, precision, and reusability. In addition, the
“visible” within the primitive. It is possible that the number of tokens authors note that high-quality specifications are electronically stored, exe-
and the number of data elements will differ, if data elements can be moved cutable or at least interpretable, annotated by relative importance and stability,
from input to output without any internal transformation. The corrected CFuPI versioned, organized, cross-referenced, and specified at the right level of detail.
is determined from a table published by much abbreviated version Although many of the above characteristics appear to be qualitative in na-
is shown below: ture, Davis et al. suggest that each can be represented using one or
more For example, we assume that there are requirements in a
specification, such that
2 1
5 5.8
10 16.6
15 29.3
20 43.2 of quality metrics is beyond the scope of chapter. See
532 PART THREE: CONVENTIONAL METHODS FOR ENGINEERING CHAPTER 18: TECHNICAL METRICS FOR SOFTWARE 533
where is the number of functional requirements and is the number of 18.4.1 High-Level Design Metrics
nonfunctional (e.g., performance) requirements.
To determine the specificity (lack of ambiguity) of requirements, Davis et High-level design metrics focus on characteristics of the program architecture
al. suggest a metric that is based on the consistency of the reviewers’ inter- (Chapter with an emphasis on the architectural structure and the effec-
pretation of each requirement: tiveness of modules. These metrics are black-box in the sense that they do not
require any knowledge of the inner working of a particular module with the
=
system.
where is the number of requirements for which all reviewers had identical Card and Glass define three software design complexity mea-
interpretations. The closer the value of Q is to 1, the lower the ambiguity of the sures: structural complexity, data complexity, and system complexity. Structural
specification. complexity, S(i), of a module i is in the following manner:
The completeness of functional requirements can be determined by com- = (18.11
puting the
where is the of module
Data complexity, D(i), provides an indication of the complexity in the in-
ternal interface for a module i and is defined as:
where is the number of unique function requirements, is the number of
inputs (stimuli) defined or implied by the specification, and is the number = 11 (18.2)
of states specified. The ratio measures the percentage of necessary func- where is the number of input and output variables that are passed to and
tions that have been specified for a system. However, it does not address non- from module i.
functional requirements. To incorporate these into an overall metric for svstem complexity, is defined as the sum of structural and
I
pleteness, we must consider the degree to which requirements have been data and is defined as:
validated.
= (18.3)
As each of these complexity values increases, the overall architectural com-
where is the number of requirements that have been validated as correct plexity of the system also increases. This leads to a greater likelihood that in-
and is the number of requirements that have not yet been validated. tegration and testing effort will also increase.
An earlier high-level architectural design metric proposed by Henry and
Kafura also makes use of the fan-in and fan-out. The authors define
a complexity metric of the form:
18.4 METRICS FOR THE DESIGN MODEL
HKM length(i) X + (18.4)
It is inconceivable that the design of a new aircraft, a new computer chip, where length(i) is the number of programming language statements in module
or a new office building would be conducted without defining design mea- i and is the fan-in of module i. Henry and Kafura extend the definition of
sures, determining metrics for various aspects of design quality, and using
fan-in and fan-out presented in this‘book to include not only the number of
them to guide the manner in which the design evolves. And yet, the design
module control connections (module calls) but also the number of data struc-
of complex software-based systems often proceeds with virtually no mea-
tures from which module i retrieves (fan-in) or updates (fan-out) data. To com-
surement. The irony of this is that design metrics for software are available, pute HKM during design, the procedural design may be used to estimate the
but the vast majority of software engineers continue to be unaware of their
number of programming language statements for module i. Like the Card and
existence. Glass metrics noted above, an increase in the Henry-Kafura metric leads to a
Design metrics for computer software, like all other software metrics, are greater likelihood that integration and testing effort will also increase for a
not perfect. Debate continues over their and how they should be ap- module.
plied. Many experts argue that further experimentation is required before de-
sign measures can be used. And yet, design without measurement is an unac-
ceptable alternative.
In the sections that follow we examine some of the more common design
metrics for computer Although none thorn arc all can pro- “An noted in the in indicates the number of mod-
vide the designer with improved insight and all can help the design to evolve ules immediately subordinate module that is, the number of modules that directly in-
to a higher level of quality. voked by module
CHAPTER TECHNICAL METRICS FOR SOFTWARE 535
534 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
ranges from 0 to 1. The following values must be ascertained to compute the
Fenton suggests a number of simple morphology (i.e., shape) met- DSQI
rics that enable different program architectures to be compared using a set of
straightforward dimensions. In Figure 18.5, the following metrics can be de- = the total number of modules defined in the program architecture
fined: ,
= the number of modules whose correct function depends on the
size = +a source of data input or produces data to be used elsewhere [in gen-
eral, control modules (among others) would not be counted as part
where is the number of nodes and is number of arcs (lines of of
control). For the architecture shown in Figure 18.5,
= the number of modules whose correct function depends on prior pro
size = 1’7 + 18 35
depth = the longest path from the root (top) node to a leaf node. For the ar- = the number of database items (includes data objects and all attri-
chitecture shown in Figure 18.5, depth = 4. butes that define objects)
width = maximum number of nodes at any one of the architecture. For = the total number of unique database items
the architecture shown in Figure 18.5, width 6.
= the number of database segments (different records or individual
arc-to-node ratio, = objects)
which measures the connectivity density of the architecture and may provide = the number ofmodules with a single entry and exit (exception pro-
a simple indication of the coupling of the architecture. For the architecture cessing is not considered to be a multiple exit)
shown in Figure 18.5, = 1.06.
The U.S. Air Force Systems Command [USA871 has developed a number of Once values through are determined for a computer program, the fol-
quality indicators that are based on measurable design characteris- lowing intermediate values can be computed:
tics of a computer program. Using concepts similar to those proposed in IEEE
Std. 982.1-1988 the Air Force uses information obtained from data and
Program structure: where is defined as follows: If the architectural
architectural design to derive a design structure quality index that design was developed using a distinct method (e.g., data flow-oriented de-
sign or object-oriented design, then = 1, otherwise =
Module independence: = 1
dependent on prior processing: = 1
Database size: = 1
Database compartmentalization: = 1
Module entrance/exit characteristic: = 1
With these intermediate values determined, the DSQI is computed in the fol-
lowing manner:
DSQI = (18.5)
where i = 1 to is the relative weighting of the importance of each of the
intermediate values and = 1 (if all are weighted equally, then =
0.167).
The value of DSQI for past designs can be determined and compared to a
design that is currently under development. If the DSQI is significantly lower
than average, further design work and review are indicated. Similarly, if major
width a changes are to be made to an existing design, the effect of those changes on
DSQI can be calculated.
FIGURE 18.5. Morphology metrics
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER TECHNICAL METRICS FOR SOFTWARE
18.4.2 Component-level Design Metrics A detailed discussion of the Bieman and Ott metrics is best left to the au-
thors However, to illustrate the character of these metrics, consider
the metric for strong functional cohesion:
Component-level design metrics focus on internal characteristics of software
components and include measures of module cohesion, coupling, and complex- = (18.6)
, ity. These “3-C’s” can help a software engineer to judge the quality of a compo-
nent level design. , where denotes superglue tokens-the set of data tokens that lie on
The metrics presented in this section are glass-box in the sense that they all data slices for a module the ratio of superglue tokens to the total num-
require knowledge of the inner working of the module under consideration. , ber of tokens in a module i increases toward a maximum value of 1, the func-
Component-level design metrics may be applied once a procedural design tional cohesiveness of the module also increases.
has been developed. Alternatively, they may be delayed until source code is
available. Coupling m e t r i c s Module coupling provides an indication of the
of a module to other modules, global data, and the outside environment.
In Chapter 13, coupling was discussed in qualitative terms.
Cohesion m e t r i c s Bieman and Ott define a collection of metrics that Dhama has proposed a metric for module coupling that encom-
provide an indication of the cohesiveness (Chapter 13) of a module. The met- passes data and control flow coupling, global coupling, and environmental cou-
rics are defined in terms of live concepts and measures: pling. The measures required to compute module coupling are defined in terms
of each of the three coupling types noted above.
Data slice. Stated simply, a data slice is a backward walk through a mod-
ule that looks for data values that affect the module location at which the For data and control flow coupling:
walk began. It should be noted that both program slices (which focus on = number of input data parameters
statements and conditions) and data slices can be defined. = number of input control parameters
Data tokens. The variables defined for a module can be defined as data to- d,, = number of output data parameters
kens for the module.
= number of output control parameters
tokens. The of data tokens that lie on one or more data slice.
tokens. The data that are common to data slice in For global coupling:
a module.
= number of global variables used as data
stickiness of a token is directly proportional to
= number of global variables used as control
the number of data that it binds.
For environmental coupling:
Bieman and Ott develop metrics for strong functional cohesion weak = number of modules called (fan-out)
functional cohesion and adhesiveness (the relative degree to which glue
= number of modules calling the module under consideration (fan-in)
tokens bind data slices together). These metrics can be interpreted in the fol-
lowing manner
Using these measures, a module coupling indicator, is defined in the fol-
All of these cohesion metrics range in value between 0 and 1. They have a value lowing way:
of 0 when a procedure has more than one output and exhibits none of the co- =
hesion attributes indicated by a particular metric. A procedure with no
glue tokens, no tokens that are common to all data slices, has zero strong func- where k = 1, a proportionality
tional cohesion-there are no data tokens that contribute to all outputs. A
procedure with no glue tokens, that is, no tokens common to more than one
data slice (in procedures with one data slice), exhibits zero weak where
functional cohesion and zero adhesiveness-there are no data tokens that con-
tribute to than output.
Strong functional cohesion are when the Bieman author notes that the values of and a. and (discussed in the next
and Ott metrics take on a maximum 1. may be adjusted experimental verification
538 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
CHAPTER TECHNICAL METRICS FOR SOFTWARE -- 539
The higher the value of the lower the overall module coupling. For exam-
ple. If a module has a single input and output data parameter, accesses no Zuse presents an encyclopedic discussion of no fewer than 18 dif-
global data, and is called by a single module: ferent categories of software complexity metrics. The author presents the basic
definitions for metrics in each category (e.g., there are a number of variations
= +0+ 0+0+0 1+ = = 0.33 on the cyclomatic complexity metric) and then analyzes and critiques each.
work is most comprehensive published to date.
We would expect that such a module would exhibit low coupling. Hence, a value
of = 0.33 implies low coupling. Alternatively, if a module has 5 input and 5
output data parameters, an equal number of control parameters, accesses 10
items of global data, and has a fan-in of 3 and a fan-out of 4, 18.4.3 Design Metrics
Although there is a significant literature on the design of human-computer in-
and the implied coupling is high. terfaces (see Chapter relatively little information has been published on
In order to have the coupling metric move upward as the degree of coupling metrics that would provide insight into the quality and usability of the inter-
increases, a revised coupling metric may be defined as: face.
Sears suggests appropriateness as a worthwhile
for human-computer A uses
where the degree of coupling increases nonlinearly between a minimum value graphic icons, windows, and the like-to assist the user in com-
in the range 0.66 to a maximum value that approaches 1.0. pleting To a given task using a GUI, the user must move from
one layout entity to the next. The absolute and relative position of each layout
entity, the frequency with which it is used, and the “cost” of the transition from
metrics A variety of software metrics can be computed to determine
one layout entity to the next will all contribute to the appropriateness of the
the complexity of program control flow. Many of these are based on a repre- interface.
sentation called a flow graph. As we discussed in Chapter 16, a graph is a rep-
For a specific layout (i.e., a specific GUI design), cost can be assigned to
resentation composed of nodes and links (also called edges). When the links
each sequence of actions according to the following relationship:
(edges) are directed, the flow graph is a directed graph.
McCabe identifies a number of important uses for complexity cost = [frequency of transition(k) X cost of transition(k)] (18.7)
metrics:
where k is a specific transition from one layout entity to the next as a specific
task is accomplished. The summation occurs across all transitions for a partic-
Complexity metrics can be used to predict critical information about reliability
and maintainability of software systems from automatic analysis of source code ular task or set of tasks required to accomplish some application function. Cost
[or procedural design information]. Complexity metrics also provide feedback may be characterized in terms of time, processing delay, or any other reason-
able value, such as the distance that a mouse must travel between layout en-
during the software project to help control the [design activity]. During testing,
tities.
and maintenance, they provide detailed information about software modules to
help pinpoint areas of potential instability Layout appropriateness is defined as:
LA 100 of LA-optimal of proposed layout)] (18.8)
The most widely used (and debated) complexity metric for computer soft-
where LA = 100 for an optimal layout.
ware is cyclomatic complexity, originally developed by Thomas McCabe
To compute the optimal layout for a GUI, interface real estate (the area of
and discussed in detail in Section 16.4.2.
the screen) is divided into a grid. Each square of the grid represents a possible
McCabe measure of testing difficulty
position for For a grid with N possible and K differ-
and an indication of ultimate reliability. Experimental studies indicate a strong
ent layout entities to place, the number of possible is represented in the
correlation between the McCabe metric and the number of errors existing in following manner
source code, as well as the time required to find and correct such errors.
McCabe contends that cyclomatic complexity may be used to provide number of possible layouts = X X K! (18.9)
a quantitative indication of maximum module size. Collecting data from a num-
ber of actual programming projects, he has found that a cyclomatic complex- As the number of layout positions increases, the number of possible layouts
ity of 10 appears to be a practical upper limit for module size. When the grows very To find the optimal layout, Scars pro-
complexity of modules exceeded this number, it became extremely difficult poses a searching algorithm.
to adequately test a module. See Chapter 16 for a discussion of cyclomatic com- LA is used to assess different proposed GUI layouts and the sensitivity of
plexity as a guide for the design of white-box test cases. a particular layout to changes in task descriptions (i.e., changes in the sequence
and/or frequency of transitions). The interface designer can use the change in
540 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 18: TECHNICAL METRICS FOR SOFTWARE 541
layout appropriateness, ALA, as a guide in choosing the best GUI layout for a
particular application.
It is important to note that the of GUI can be guided SORT
with metrics such as LA, but the arbiter should be user feedback based DIMENSION X(N)
on GUI prototypes. Nielsen and Levy report that “one has a reason- IF (N.LT.2)
I
ably large chance of success if one chooses between interface based
solely on user’s opinions. Users’ average task performance and their subjective IF TO 10
satisfaction with a GUI are highly correlated.” SAVE X(I)
X(J)
X(J) SAVE 7 1
CONTINUE .LT.
20 .GE. 1
18.5 METRICS FOR SOURCE CODE 10 GOT0 10 1
END
Halstead’s theory of science is “probably the best known and
most thoroughly studied . composite measures of (software) complexity”
Software science proposed the first analytical “laws” for computer
Operands the interchange sort program
Software science assigns quantitative laws to the development of computer
software. Halstead’s theory is derived from one fundamental assumption
“the human brain follows a more rigid set of rules (in developing al- 5
3 J
gorithms) than it has been aware of. . Software science uses a set of primi- 4N
tive measures that may be derived after code is generated or estimated once 5 2
design is complete. These are listed below. 6 SAVE
1 1
number of distinct operators that appear in a program
nz-the number of distinct operands that appear in a program
total number of operator occurrences FIGURE 18.6. O p e r a t o r s a n d o p e r a n d f o r
simple program
total number of operand occurrences (Source: A. Fitzsimmons and T. love,“A Review and Evaluation of Software Science,” ACM
Computing Surveys, vol. 10, no. 1, March 1978. Copyright 1978, Association of Computing
To illustrate how these primitive measures are obtained, refer to the simple Machinery, Inc. Reprinted with permission.)
SORT program [FIT781 shown in Figure 18.6.
uses the primitive measures to develop expressions for the over-
all program length; potential minimum volume for an algorithm; the actual vol- It should be noted that V will vary with programming language and represents
ume (number of bits required to specify a program); the program mea- \ the volume of information (in bits) required to specify a program. For the SORT
sure of software complexity); language (a constant for a given language); module shown in Figure 18.6, it can be shown that the volume for the
and other features such as development effort, development time, and even the version is 204. Volume for an equivalent assembler language version
projected number of faults in the software. would be 326. we would suspect, it takes more effort to specify a program
shows that length N can be estimated by: in assembler language.
Theoretically, a minimum volume must exist for a particular algorithm.
N= + (18.10) defines a volume ratio as the ratio of volume of the most compact
and program volume may be defined by: form of a program to the volume of the actual program. In actuality, must al-
ways be less than one. In terms of primitive measures, the volume ratio may
V=N + (18.11) be expressed as
(18.12)
proposed that each language may be categorized by language level,
not everyone the underlying theory correct. However, experimental verification which will vary among theorized that langungc level is
of Hal&ad’s findings have been made for a number of programming languages constant for a given language, but other work indicates that language
PART CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
CHAPTER TECHNICAL
543
level is a function of both language and The following language whose cyclomatic complexity is lower. For this reason, the tester should expend
level values have been empirically derived: above average effort to uncover errors in the module before it is integrated in
a system. Testing effort can also be estimated using metrics derived from
2.16 measures (Section 18.5). Using the definitions for program volume, V,
English prose
and program level, PL, software science effort, can be computed as:
1 1.53
ALGOL/68 2.12 PL = .
FORTRAN 1.14
Assembler 0.88
It appears that language level implies a level of abstraction in the specification The percentage of overall testing effort to be allocated to a module k can be es-
of procedure. High-level languages allow specification of code at a higher level timated using the following relationship:
of abstraction than does assembler (machine-oriented) language.
percentage of testing effort =
Halstead’s work is amenable to experimental verification, and a large body
of research has been conducted to investigate software A discussion of where is computed for module k using equations (18.13) and the summa-
this work is beyond the scope of this text, but it can be said that good agree- tion in the denominator of equation (18.14) is the sum of software science ef-
ment has been found between analytically predicted and experimental results. fort across all modules of the system.
For further information, see and As tests are conducted, three different measures provide an indication of
testing completeness. A measure of the provides an indication
how many requirements (of the total number of requirements) have been tested.
This provides an indication of the completeness of the test plan.
18.6 METRICS FOR TESTING
is a measure of the percentage of independent basis paths covered by testing ver-
sus the total number of basis paths in the program. A reasonably accurate esti-
Although much has been written on software metrics for testing (e.g., mate of the number of basis paths can be computed by adding the cyclomatic
the majority of metrics proposed focus on the process of testing, not the technical complexity of all program modules. Finally, as tests are conducted and error data
characteristics of the tests themselves. In general, testers must rely on analysis, are collected, fault profiles may be used to prioritize and categorize errors
design, and code metrics to guide them in the design and execution of test cases. covered. Priority indicates the severity of the problem. Fault categories provide,
Function-based metrics (Section 183.1) can be used as a predictor for over- a description of an error so that statistical error analysis can be conducted.
all testing effort. Various project-level characteristics (e.g., testing effort and
time, errors uncovered, number of test cases produced) for past projects can be
collected and correlated with the number of FP produced by a project team. The
team can then project “expected” values for these characteristics for the cur-
rent project. 18.7 METRICS FOR MAINTENANCE
The bang metric can provide an indication of the number of test cases re-
quired by examining the primitive measures discussed in Section 18.3.2. The All of the software metrics introduced in this chapter can be used for the de-
number of functional primitives data elements (DE), objects rela- velopment of new software and the maintenance of existing software. However,
tionships states (ST), and transitions (TR) can be used to project the num- metrics designed explicitly for maintenance activities have been proposed.
ber and types of black-box and white-box tests for the software. For example, IEEE Std. 982.1-1988 suggests a software maturity index
the number of tests associated with the human-computer interface can be es- that provides an indication of the stability of a software product (based on
timated by examining (1) the number of transitions contained in the changes that occur for each release of the product). The following information
transition representation of the HCI and evaluating the tests required to ex- is determined:
ercise each transition, the number of data objects that move across the
= the number of modules in the current release
interface, and (3) the number of data elements that are input or output.
High-level design metrics provide information on the ease or difficulty as- = the number of modules in the current release that have bean
sociated with integration testing (Chapter 17) and the need for specialized test- changed
ing software (e.g., stubs and drivers). Cyclomatic complexity (a component de-
sign metric) lies at the core of basis path testing, a test case design method = the number of modules in the current release that have been
presented in Chapter 16. In addition, cyclomatic complexity can be used to tar- added
get modules as candidates for extensive unit testing (Chapter Modules
= the number of modules from the preceding release that were
with high cyclomatic complexity are likely more error-prone than modules
deleted in the current release
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING CHAPTER 18: TECHNICAL METRICS FOR SOFTWARE 545
The maturity index is computed in the following manner: [CAR901 Card, D.N., and R.L. Glass, Measuring Software Quality.
Hall, 1990.
SMI = + (18.15) Cavano, J.P., and J.A. McCall, “A Framework for the Measurement of
As SMI approaches 1.0, the product begins to stabilize. SMI may also be used Software Quality,” ACM Software Quality Assurance Workshop,
as a metric for planning software maintenance activities. The mean time to pro- November 1978, pp. 133-139.
duce a release of a product can be correlated with SMI, and empirical Charette, R.N., Software Engineering Risk and Management,
models for maintenance effort can be developed. 1989.
Curtis, W. “Management and Experimentation in Software Engineering,”
IEEE, vol. 68, no. 9, September 1980.
Davis, A. et al., “Identifying and Measuring Quality in a Software
18.8 SUMMARY Requirements Specification, Software Metric Symposium,
IEEE, Baltimore, MD, May 1993, pp. 141-152.
R.A., and R.J. Project Software
Software metrics provide a quantitative way to assess the quality of internal Metrics, A.J. Perlis, F.G. and M. MIT Press, 1981,
product attributes, thereby enabling the software engineer to assess quality be- pp. 77-89.
fore the product is built. Metrics provide the insight necessary to create effec- Controlling Software Projects, Press, 1982.
tive analysis and design models, solid code, and thorough tests. Models of Cohesion and Coupling in Software,”
To be useful in a real world context, a software metric must be simple and of Systems and Software, vol. 29, no. 4, April 1996.
computable, persuasive, and consistent and objective. It should be programming Ejiogu, L., Software Engineering with Formal Metrics, QED Publishing,
language-independent and provide effective feedback to the engineer. 1991.
Metrics the analysis model focus on function, data, and behavior-the L., and G. Zalateu, “Validating Theory for Pascal
three components of the analysis model. The function point and the bang met- Programs,” IEEE Software Engineering, vol. 15, no. 2, December
ric each provide a quantitative means for evaluating the analysis model. Metrics 1989, pp.
for design consider high-level, component-level, and interface design issues. Fenton, N., Software Metrics, Chapman Hall, 1991.
High-level design metrics consider the architectural and structural aspects of , Fenton, N., “Software Measurement: A Necessary Scientific Basis,”
the design model. Component-level design metrics provide an indication of Software Engineering, vol. 20, no. 3, March 1994, pp.
module quality by establishing indirect measures for cohesion, coupling, and Fitzsimmons, A., and Love, “A Review and Evaluation of Software
design provide an indication of Computing vol. 10, no. 1, March 1978, pp. 3-18.
for a GUI. Establishing a
science provides an intriguing set of metrics at the source code Company-Wide Program, Prentice-Hall, 1987.
level. Using the number of operators and operands present in the code, soft- Halstead, M., of Software Science, North Holland, 1977.
ware science provides a variety of metrics that can be used’to assess program Henry, S., and D. Kafura, “Software Structure Metrics Based on
quality. Information Flow,” IEEE Trans. Software Engineering, vol. SE-7, no. 5,
Few technical metrics have been proposed for direct use in software test- September 1981, pp.
ing and maintenance. However, many other technical metrics can be used to Hetzel, B., Making Software Measurement Work, QED Publishing, 1993.
guide the testing process and as a mechanism for assessing the maintainabil- IEEE Software Engineering Standards, 1994 edition, IEEE, 1994.
ity of a computer program. Kyburg, H.E., Theory and Measurement, Cambridge University Press,
1984.
McCabe, T.J., “A Software Complexity Measure,” IEEE Trans. Software
Engineering, vol. 2, December 1976, pp.
REFERENCES McCall, J., P. Richards, and G. Walters, “Factors in Software Quality,”
three volumes, NTIS 015, 055, November 1977.
and D.M. Weiss. “A Methodology for Collecting Valid Software lMCC891 McCabe, T.J., and Butler, “Design Complexity Measurement and
Engineering Data,” Software Engineering, vol. 1984, Testing,” CACM, vol. 32, no. 12, December 1989, pp. 1415-1425.
pp. McCabe, T.J., and A.H. Watson, “Software Complexity,” Crosstalk, vol. 7,
Bieman, J.M., and L.M. Ott, “Measuring Functional Cohesion,” IEEE no. 12, December 1994, pp. 5-9.
Trans. Software Engineering, vol. 20, no. 8, August 1994, pp. Nielsen, J., and J. Levy, “Measuring Usability: Preference vs. Perfor-
Briand, L.C., S. Morasca, and V.R. “Property-Based Software mance,” vol. 37, no. 4, April 1994, pp. 65-75.
Engineering Measurement,” IEEE Trans. Software Engineering. vol. 22, J.M., “Software Metrics and Measurement Principles,”
no. 1, January 1996, pp. 68-85. Engineering Notes, ACM, vol. 19, no. 1, January 1994, pp. 76-85.
CHAPTER TECHNICAL METRICS FOR SOFTWARE
PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 547
546
18.12. Develop a software tool that will compute layout appropriateness for a GUI.
Sears, A., “Layout Appropriateness: A Metric for Evaluating User The tool should enable you to assign the transition cost between layout en-
Interface Widget Layout,” Software Engineering, vol. 19, no. tities. [Note: Recognize that the size of the potential population of layout al-
7, July 1993, pp. ternatives grows very large as the number of possible grid positions grows.]
Management Insight, AFCSP (U.S. Air Force), January
18.13. Develop a small software tool that will perform a analysis on pro-
20, 1987. gramming language source code of your choosing.
Zelkowitz, M., private communication, 1981.
18.14. Research the literature and write a paper on the relationship of Halstead’s
Zuse, H., Software Complexity: Measures and Methods, New
York, 1990. metric and McCabe’s metric on software quality (as measured by error
count). Are the data compelling? Recommend guidelines for the application
of these metrics.
18.15. Research the literature for any recent papers of metrics specifically designed
PROBLEMS AND POINTS TO PONDER to assist in test case design. Present your findings to the class.
18.16. A legacy system hos 940 modules. The latest release required that 90 of
18.1. Measurement theory is an advanced topic that has a strong bearing tin soft- these modules be changed. In addition, 40 new modules were added and 12
ware metrics. Using or some other source, write old modules were removed. Compute the software maturity index for the
a brief paper that outlines the main tenets of measurement theory. Individual system.
a presentation on the subject and present it to your class.
18.2. McCall’s quality factors were developed during the 1970s. Almost every as-
pect of computing has changed dramatically since the time that they were FURTHER READINGS AND OTHER INFORMATION SOURCES
developed, and yet, McCall’s factors continue to apply to modern software.
Can you draw any conclusions based on this fact? There are a surprisingly large number of books that are dedicated to software
18.3. Why is it that a single, all-encompassing metric cannot be developed for pro- metrics, although the majority focus on process and project metrics to the ex-
gram complexity or program quality? clusion of technical metrics. Books by Card and Glass Zuse
16.4. Review the analysis model you developed as part of problem 12.13. Using Fenton Ejiogu Moeller and Paulish (Software Metrics,
the guidelines presented in Section 18.3.1, develop an estimate for the num- Chapman Hall, and Hetzel all address technical metrics in
ber of function points associated with PHTRS. some detail. In addition, the following books are worth examining:
16.6. Review the analysis model you developed as of problem 12.13. Using
the guidelines presented in Section 18.3.2, develop primitive counts for the Conte, S.D., H.E. Dunsmore, and V.Y. Shen, Software Engineering Metrics
bang metric. Is the PHTRS system function-strong or data-strong? and Models, Benjamin Cummings, 1984
18.6. Compute the value of the bang metric using the measures you developed in Grady, R.B., Practical Software Metrics for Project Management and Process
problem 18.5. Prentice-Hall, 1992.
18.7. Create a complete design model for a system that is proposed by your in- Grady, R.B., and Caswell, Practical Software Metrics for Project
structor. Compute structural and data complexity using the metrics de- Management and Process Improvement, Prentice-Hall, 1992.
scribed in Section 18.4.1. Also compute the and morphology
A., F. and M. Shaw, Software Metrics: An Analysis and
metrics for the design model.
MIT Press, 1981.
18.8. A major information system has 1140 modules. There are 96 modules that
Sheppard, M., Software Engineering Metrics, McGraw-Hill, 1992.
perform control and coordination functions and 490 modules whose function
depends on prior processing. The system processes approximately 220 data
objects that each have an average of 3 attributes. There are 140 unique data The theory of software measurement is presented by Denvir, Herman, and
base items and 90 different database segments. 600 modules have single en- Whitty in a edited collection of papers (Proceedings of the
try and exit points. Compute the DSQI for this system. FACS Workshop: Formal Aspects of Measurement, Springer-Verlag, 1992).
Shepperd (Foundations of Software Measurement, Prentice-Hall, 1996) also ad-
1 6 . 9 . Research and Ott’s paper and develop a complete example
dresses measurement theory in some detail.
that illustrates the computation of their cohesion metric. Be sure indicate
how data slices, data tokens, and glue and superglue tokens are determined. A comprehensive summary of dozens of useful software metrics is
general, .a discussion of each metric has been distilled to
18.10. Select modules in an existing computer program. Using met- the essential “primitives” (measures) required to compute the metric and the
ric described in Section 18.4.2, compute the coupling value for each module. appropriate relationships to effect the computation. An appendix provides dis-
18.11. Develop a software tool that will compute cyclomatic complexity for a pro- cussion and many references.
gramming language module. You may choose the language.
548 PART THREE: CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING
An extensive software metrics bibliography covering process, project, and
product metrics has been assembled by the Software Measurement Laboratory
at the University of Magdeburg and can be found at:
A number of consulting companies specialize in software metrics. Their Web
sites contain useful information:
OBJECT-ORIENTED
SOFTWARE
Software Productivity Research, Inc.
Quantitative Software Management, Inc.
ENGINEERING
The United States Department of and other government agencies have
active metrics programs that are described at the following sites:
The Software Productivity Center of Canada also has an active metrics pro-
gram that provides tools and handbooks as well as other useful information at:
A set of educational materials tailored to the specific needs of industry and
academia, called is available at:
In this part of Software Engineering: A Practitioner’s Approach we consider the technical concepts,
methods, and measurements that are applicable for the analysis, design, and testing of object-ori-
ented software. In the chapters that follow, we address the following questions:
An extensive database of technical metrics with over 500 entries has been com-
piled by Professor Worst who has also written an on-line history of soft- !"What are the basic concepts and principles that are applicable to object-oriented thinking?
ware metrics with extensive bibliographic references: !" How should object-oriented software projects be planned and managed?
!"What is object-oriented analysis and how do its various models enable a software engineer to un-
derstand classes, their relationships and behaviors?
!"What is a ‘use case’ and how can it be applied to analyze the requirements of a system?
An up-to-date list of World Wide Web references for technical metrics can
be found at: !" How do conventional and object-oriented approaches differ?
!" What are the components of an object-oriented design model?
!" How are ‘patterns’ used in the creation of an
!" What are the basic concepts and principles that are applicable for testing of object-oriented soft-
ware?
How do testing strategies and test case design methods change when object-oriented software is
considered?
!" What technical metrics are available for assessing the quality of object-oriented software?
Once these questions are answered, you’ll understand how to analyze, design, implement, and test
software using the object-oriented paradigm.
OBJECT-ORIENTED
CONCEPTS AND
PRINCIPLES
W e live in a world of objects. These objects exist in nature, in man-made
entities, in business, and in the products that we use. They can be cat-
egorized, described, organized, combined, manipulated, and created. Therefore,
it is no surprise that an object-oriented view would be proposed for the creation
of computer software-an abstraction that models the world in ways that help
us to better understand and navigate it.
An object-oriented approach to the development of software was first pro-
posed in the late However, it took almost 20 years for object technolo-
gies’ to become widely used. During the half of the object-oriented
software engineering became the paradigm of choice for many software prod-
uct builders and a growing number of information systems and engineering
professionals. As time passes, object technologies are replacing classical
ware development approaches. An important question is Why?”
The answer (like many answers to questions about software engineering)
is not a simple one. Some people would argue that software professionals sim-
ply yearned for a “new” approach, but that view is overly simplistic. Object
technologies do lead to a number of inherent benefits that provide advantages
at both the management and technical level.
Object technologies lead to reuse, and reuse (of program components) leads
to faster software development and higher-quality Object-oriented
software is easier to maintain because its structure is inherently decoupled.
‘The “object technologies” is often used to encompass all aspects of an object-oriented
view and includes analysis, design, and testing methods; programming languages; data-
bases; and the applications that are created using an object-oriented approach.
*A detailed discussion of software reuse is presented in Chapter 26.
552 PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 19: CONCEPTS AND
This leads to fewer side effects when changes have to be made and less
tration for the software engineer and the customer. In addition, object-oriented identify
systems are easier to adapt and easier to scale (i.e., large systems can be cre- candidate
ated by assembling reusable subsystems).
In this chapter we introduce the basic principles and concepts that form a
foundation for the understanding of object technologies. Throughout the re-
mainder of Part Four of this book, we consider methods that form the basis for construct look-up
an engineering approach to thecreation of object-oriented products and sys- nth iteratio n classes
tems. Customer
of system I
put new
19.1 THE OBJECT-ORIENTED PARADIGM
classes
in library
For many years, the term “object-oriented” (00) was used to denote a software
development approach that used one of a number of object-oriented program-
ming languages (e.g., Ada 95, C+ Eiffel, Smalltalk). Today, the 00 paradigm engineer
encompasses a complete view of software engineering. Edward Berard notes classes I
this when he states Evaluation Construction Release
The benefits of object-oriented technology are enhanced if it is addressed
on and throughout the software engineering process. Those considering
oriented technology must assess its impact on the entire software engineering
process. Merely employing object-oriented programming will not yield
the best results. Software engineers and their managers must consider such
items as object-oriented requirements analysis object-oriented design
object-oriented domain analysis object-oriented database 19.1. The 00 process model
classes are “looked up” in a library (of existing 00 classes) before they are built.
When a class cannot be found in the library, the engineer applies ob-
A reader who is familiar with the conventional approach to software engineer- ject-oriented analysis object-oriented design object-oriented pro-
ing (presented in Part Three of this book) might react to the above statement gramming and object-oriented testing to create the class and the
with a shrug: What’s the big deal? We use analysis, design, programming, test- objects derived from the class. The new class is then put into the library so that
ing, and related technologies when we engineer software using the classical it may be reused in the future.
methods. Why should 00 be any different?” Indeed, why should 00 be any dif- The object-oriented view demands an evolutionary approach to software
ferent? In short, it shouldn’t! engineering. As we will see throughout this and the following chapters, it would
In Chapter discussed a number of different process models for soft- be exceedingly difficult to define all necessary classes for a major system or
ware engineering. Although any one of these models could be adapted for use product in a single iteration. As the 00 analysis and design models evolve, the
with 00, the best choice would recognize that 00 systems tend to evolve over need for additional classes becomes apparent. It is for this reason that the par-
time. Therefore, an evolutionary process model coupled with an approach that adigm described above works best for 00. Further discussion of the 00 process
encourages component assembly (reuse) is the best paradigm for 00 software model is presented in Section 19.4.1.
engineering. In Figure 19.1 the component assembly process model (Chapter
has been tailored for 00 software engineering.
The 00 process moves through an evolutionary spiral that starts with cus-
tomer communication. It is here that the domain is defined and that 19.2 OBJECT-ORIENTED CONCEPTS
basic problem classes (discussed later in this chapter) are identified. Planning
and risk analysis establish foundation for the plan. technical Any discussion of object-oriented software engineering must begin by
work associated with 00 software follows the path shown ing the term “object-oriented.” What is an object-oriented viewpoint? Why is a
in the shaded box. 00 software engineering emphasizes reuse. Therefore, method considered to be object-oriented? What is an object? Over the years,
PAR, FOUR. OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER OBJECT-ORIENTED CONCEPTS PRINCIPLES 555
there have been many different opinions (e.g., will modify one or more attributes of the object. For example, if the at-
about the correct answers to these questions. In the discussion that tribute location is a composite data item defined (using data dictionary
follows, we attempt to synthesize the most common of these. notation from Chapter 12) as:
To understand the object-oriented point of view, consider an example of a
real world object-the thing you are sitting in right now-a chair. Chair is a location building + floor + room
member (the term “instance” is also used) of a much larger class of objects that
we call furniture. A set of generic attributescan be associated with every ob-
then an named moue would modify one or more of the data items
ject in the class furniture. For example, all furniture has a cost, dimensions,
-weight, location, and color, among many possible attributes. These apply (building,floor or room) that comprise the attribute location. To do this, moue
must have “knowledge” of these data items. The operation move could be used
whether we are talking about a table or a chair, a sofa or an armoire. Because
for a chair or a table, as long as both are instances of the class All
chair is a member of the class furniture, chair inherits all attributes defined
for the class. This concept is illustrated schematically in Figure 19.2. valid operations (e.g., buy, sell, weigh)for the class furniture are “connected”
Once the class has been defined, the attributes can be reused when new in- to the object definition as shown in Figure 19.3 and are inherited by all in-
stances of the class.
stances of the class are created. For example, assume that we were to define a
The object chair (and all objects in general) encapsulates data (the at-
new object called chable cross between a chair and a table) that is a mem-
tribute values that define the chair), operations (the actions that are applied to
ber of the class furniture. Chahle inherits all of the attributes of furniture.
We have attempted an anecdotal definition of a class by describing its at- change the attributes of chair), other objects (composite objects can be defined
constants (set values), and other related information. Encapsulation
tributes, but something is missing. Every object in the class furniture can be
manipulated in a variety of ways. It can be bought and sold, physically
tied (e.g., you can saw off a leg or paint the object purple) or moved from one
place to another. Each of these operations (other terms are “services” or
class: furniture
dimensions the object inherits
weight all attributes and
the object inherits location
all attributes of the class
J object: chair
object: chair dimensions
object: chable
weight
cost cost location
dimensions dimensions color
weight weight
location location
color color
weigh
move
sell
FIGURE19.3.
FIGURE 19.2. Inheritance of opera- weigh
Inheritancefrom tions from class to move
class to object
557
556 , PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 19: OBJECTORIENTED AND
means that all of this information is packaged under one name and can be other elements of a system. All of these design characteristics (Chapter lead
reused as one specification or program component. to high-quality software.
Now that we have introduced a few basic concepts, a more formal defini- Stated another way, a class is a generalized description (e.g., a template,
tion of object-orientedwill prove more meaningful. Coad and pattern, or blueprint) that describes a collection of similar objects. By
define the term this way: tion, all objects that exist within a class inherit its attributes and the opera-
tions that are available to manipulate the attributes. A superclass is a collec-
object-oriented = objects + classification + inheritance + communication. tion of classes, and a subclass is an of a class.
These definitions imply the existence of a class hierarchy in which the at-
Three of these concepts have already been introduced. We will postpone a dis-
tributes and operations of the superclass are inherited by subclasses that may
cussion of communication until later.
each add additional “private” attributes and methods. A class hierarchy for the
class furniture is illustrated in Figure 19.5.
19.2.1 Classes and Objects
19.2.2 Attributes
The fundamental concepts. that lead to high-quality design (Chapter 13) apply
equally to systems developed using conventional and object-oriented methods.
We have already seen that attributes are attached to classes and and
For this reason, an 00 model of computer software must exhibit data and pro-
cedural abstractions that lead to effective modularity. A class is an 00 concept that they describe the class or object in some way. A discussion of attributes is
presented by de Champeaw and his colleagues
that encapsulates the data and procedural abstractions that are required to de-
scribe the content and behavior of some real world entity. Taylor uses
/ Real life entities are often described with words that indicate stable features.
the notation shown on the right side of Figure 19.4 to describe a class (and ob- ,
derived from a class). Most physical objects have features such as shape, weight, color, and type of
The data abstractions (attributes) that describe the class are enclosed by a material. People have features including data of birth, parents, names, and eye
“wall” of procedural abstractions (called operations, methods, or services) that color. A feature may be seen as a binary relation between a class and a certain
are capable of manipulating the data in some way. The only way to reach the domain.
attributes (and operate on them) is to go through one of the methods that com-
prise the wall. Therefore, the class encapsulates data (inside the wall) and the
furniture (superclass)
processing that manipulates the data (the methods that make up the wall).
This achieves information hiding and reduces the impact of side effects associ-
ated with change. Since the methods tend to manipulate a limited number of
attributes, they are cohesive, and because communication occurs only through
the methods that comprise the “wall,” the class tends to be decoupled from
class name
attributes:
#"#"#
operations:
FIGURE 19.4.
An alternative
sentatian of an ob FIGURE19.5.
class A class hierarchy instances of chair
558 PART FOUR: SOFTWARE CHAPTER CONCEPTS AND PRINCIPLES
The binary relation noted above implies that an attribute can take on a value cur in the receiving object. The behavior is accomplished when an operation is
defined by an enumerated domain. In most cases, a domnin is simply a set of
specific values. For example, assume that a class automobile has an attribute The interaction between objects is illustrated schematically in Figure 19.6.
color. The domain of values for color is (white, black, silver, gray, blue, red, yel- An operation within a sender object generates a message of the form:
low, green). In more complex situations, the domain can be a set of classes.
Continuing the example, the class automobile also has an attribute power
message: [destination, operation, parameters1
train that encompasses the following domain of values: value economy op-
tion, 16 valve sport option, 24 valve 32 valve luxury option). Each
of the “options” noted has a set of specific attributes of its own. where destination defines the receiver object that is stimulated by the message,
The features (values of the domain) can be augmented by assigning a de- operation refers to the method that is to receive the message, and parameters
fault value (feature) to an attribute. For example, the train attribute provides information that is required for the operation to be successful.
noted above defaults to 16 valve sport option. It may also be useful to associ- As an example of message passing within an 00 system, consider the ob-
ate a probability with a particular feature by assigned (value, probability) pairs. jects shown in Figure 19.7. Four objects, A, B, C, and communicate with one
Consider the color attribute for automobile.In some applications (e.g., man- another by passing messages. For example, if object B required processing as-
ufacturing planning) it might be necessary to assign a probability to each of sociated with operation of object D, it would send D a message that would
the colors (white and black are highly probable as automobile colors). contain:
message:
19.2.3 Operations, Methods, and Services
As part of the execution of object D may send a message to object of
An object encapsulates data (represented as a collection of attributes) and the the form:
algorithms that process the data. These algorithms are called operations, meth-
ods, or and can be viewed as modules in a conventional sense. message:
Each of the operations that is encapsulated by an object provides a repre-
sentation of one of the behaviors of the object. For example, the operation
for the object automobile will extract the color stored in the color at-
tribute. The implication of the existence of this operation is that the class au- sender object
tomobile has been designed to receive a stimulus (we call the stimu-
lus a requests the color of the particular instance of a class.
Whenever an object receives a stimulus, it initiates some behavior. This can be
as simple as retrieving the color of automobile or as complex as the initiation
of a chain of stimuli that are passed among a variety of different objects. In the
latter case, consider an example in which the initial stimulus received by ob-
receiver object
ject results in the generation of two other stimuli that are sent to object
and object Operations encapsulated by the second and third objects act on
operations: attributes:
the stimuli, returning necessary information to the first object. Object then
uses the returned information to satisfy bohavior domandcd by the initial #" UU
stimulus.
!" mm
#"#"#
19.2.4 Messages operations:
Messages are the means by which objects interact. Using the terminology in-
troduced in the preceding section, a message stimulates some behavior to
19.6.
the of this discussion the ‘operations,” but ‘methods” and “services” Message passing be-
equally popular. tween message: [receiver, operation, parameters]
560 PART FOUR: ENGINEERING CHAPTER 19: OBJECTORIENTED CONCEPTS AND PRINCIPLES 561
characteristics of object-oriented systems make them unique. As we have al-
ready noted, the 00 class and the objects spawned from the class encapsulate
B
data and the operations that work on the data in a single package. This pro-
vides a number of important benefits:
!" The internal implementation details of data and procedures are hidden from
the outside world (information hiding). This reduces the propagation of side
effects when changes occur.
!" Data structures and the operations that manipulate them are merged in a
single named entity-the class. This facilitates component reuse.
!" Interfaces among encapsulated objects are simplified. An object that sends a
message need not be concerned with the details of internal data structures
message
in the receiving object. Hence, interfacing is simplified and the system cou-
pling tends to be reduced.
Inheritance is one of the key differentiators between conventional and 00
systems. A subclass Y inherits all of the attributes and operations associated
with its superclass X. This means that all data structures and algorithms orig-
inally designed and implemented for X are immediately available for Y-no
further work need be done. Reuse has been accomplished directly.
Any change to the data or operations contained within a superclass is im-
mediately inherited by all subclasses that have inherited from the
Therefore, the class hierarchy becomes a mechanism through which changes
(at high levels) can be immediately propagated through a system.
It is important to note that at each level of the class hierarchy, new at-
FIGURE 19.7. tributes and operations may be added to those that have been inherited from
Messaging higher levels in the hierarchy. In fact, whenever a new class is to be created,
the software engineer has a number of options:
C finds performs it, and then sends an appropriate return value to D. !" The class can be designed and built from scratch. That is, inheritance is not
Operation completes its execution and sends a return value to B. used.
Cox describes the interchange between objects in the following
!" The class hierarchy can be searched to determine if an ancestor class
manner:
moat of the required operations.
!" The new class inherits from the ancestor class, and additions may then be
An object is requested to perform one of its operations by sending it a message
telling the object what to do. The receiver [object] responds to the message by added as required.
first choosing the operation that implements the message name, executing this !" The class hierarchy can be restructured so that the required attributes and
operation, and then returning control to the caller. operations can be inherited by the new class.
!" Characteristics of an existing class can be overridden and private versions of
Messaging ties an object-oriented system together. Messages provide insight attributes or operations implemented for the new
into the behavior of individual objects and the 00 system as a whole.
To illustrate how restructuring of the class hierarchy might lead to a desired
class, consider the example shown in Figure 19.8. The class hierarchy
19.2.5 Encapsulation, Inheritance, and Polymorphism
Although the structure and terminology introduced in Sections 19.2.1 through terms “descendants” and “ancestors” are sometimes used ‘subclass”
19.2.4 differentiate 00 systems from their conventional counterparts, three and “superclass,” respectively.
CHAPTER OBJECTORIENTED CONCEPTS AND PRINCIPLES 563
562 PART FOUR: SOFTWARE ENGINEERING
+ char4 + char5 + char4
+ char5 + char8
r
+
x3 x4 char1 char1
char2 char2
char1 char1 char3 char3
char2 char2 char4 char4
char3 char3 char5 char8
char4 char4
char5 char5 t char6 \ t char7
Original hier- char6 char7
archy x4
char1 char1
trated in Figure enables us to derive classes X3 and X4 with character-
char2 char2
istics and 6, and and 7, Now, suppose that
a new class with only characteristics 1, 2, 3, 4, and 8 is desired. To derive this char3 char3
class, called in the example, the hierarchy may be restructured as shown char4 char4
in Figure It is important to note that restructuring the hierarchy can be FIGURE char5 char5
difficult, and for this reason, overriding is sometimes used. Restructured class hi- char6 char7 I
In essence, overriding occurs when attributes and operations are inherited erarchy
in the normal manner, but are then modified to the specific needs of the new
. class. As Jacobson notes, when overriding is used, “inheritance is not transi-
tive.” In some cases, it is tempting to inherit some attributes and operations from
one class and others from another class. This is called multiple inheritance, and
it is controversial. In general, multiple inheritance complicates the class hier-
archy and creates potential problems in configuration control (Chapter
, Because multiple inheritance sequences are more difficult to trace, changes to
the purposes of this example, either attributes or operations.
PART FOUR: OBJECTORIENTED ENGINEERING CHAPTER AND
the definition of a class that resides high in the hierarchy may have unintended 193.1 Identifying Classes and Objects
impact(s) on classes defined lower in the architecture.
Polymorphism is a characteristic that greatly reduces the effort required If you look around a room, there is a set of physical objects that can be easily
extend an existing 00 system. To understand polymorphism, consider a con- identified, classified, and defined (in terms of attributes and operations). But
ventional application that must draw four different types of graphs: line graphs, when you “look around” the problem space of a software application, the objects
pie charts, histograms, and Kiviat diagrams. Ideally, once data are collected for may be more to comprehend.
a particular type of graph, the graph should draw itself. To accomplish this in We can begin to identify by examining the problem statement or
a conventional application (and maintain module cohesion), it would be neces- (using the terminology Chapter a “grammatical parse” on the
sary to develop drawing modules for each type of graph. Then, within the de- processing narrative for the system to be built. Objects are determined by un-
sign for each graph type, control logic similar to the following would have to derlining each noun or noun clause and entering it in a simple table. Synonyms
embedded: should be noted. If the object is required to implement a solution, then it is part
of the solution space; otherwise, if an object is necessary only to describe a so-
case of graphtype: lution, it is part of the problem space. But what should we look for once all of
if then (data); the nouns have been isolated?
if graphtype then (data); Objects manifest themselves in one of the ways represented in Figure 19.9.
if then (data); Objects can be:
if graphtype = kiviat then (data);
end case; !" $%&$'#(!" entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system;
Although this design is reasonably straightforward, adding new graph types
!" things (e.g., reports, displays, letters, signals) that are part of the information
could be tricky. A new drawing module would have to be created for each graph
domain for the problem;
type and then the control logic would have to be updated for each graph.
To solve this problem in an 00 system, each of the graphs. noted above be-
come a subclass of a general class called graph. Using a concept called
loading each subclass defines an operation called draw. An object can reality, OOA actually attempts to define classes from which objects are instantiated.
send a message to any one of the objects instantiated any one of the Therefore, when we isolate potential objects, we also identify members of potential classes.
subclasses. The object receiving the message will invoke its own draw opera-
tion to create the appropriate graph. Therefore, the design noted above is re-
duced occurrences
things organizational units
graphtype draw places
external entities structures
When a new graphtype is to be added the system, a subclass is created with
its own operation. But no changes are required within any object that
wants a graph drawn because the message graphtype draw remains un- class name
changed. To summarize, polymorphism enables a number of different opera-
tions to have the same name. This in turn decouples objects from one another, attributes:
making each more independent.
#"#"#
19.3 IDENTIFYING THE ELEMENTS OF AN OBJECT MODEL
operations:
The elements of an object model--classes and objects, attributes, operations,
and messages-were each defined and discussed in the preceding section. But
how do we go about identifying these elements for an actual problem? The sec- 19.9.
tions that follow present a series of informal guidelines that will assist in the How mani-
identification of of model. fest
PART FOUR ENGINEERING
CHAPTER OBJECT-ORIENTED CONCEPTS AND PRINCIPLES 567
!" occurrences or (e.g., a property transfer or the completion of a series ture of the event that has been detected. The number will be every 20
of robot movements) that occur within the context of system operation; seconds until telephone connection is obtained.
!" roles (e.g., manager, engineer, salesperson) played by people who interact All interaction with is managed by a user-interaction subsystem
with the system; that reads input provided through the keypad and function keys, and displays
!" organizational units (e.g., division, group, team) that are relevant to an ap-
prompting messages and system status on the LCD display. Keyboard interac-
plication; tion takes the following form.
!" places (e.g., manufacturing floor or dock) that establish the context
of the problem and the overall function of the system; or Extracting the nouns, we can propose a number of potential objects:
!" (e.g., sensors, four-wheeled vehicles or computers) that define a
class of objects or, in the extreme, related classes of objects. Potential Object/Class General Classification
The categorization noted above is but one of many that have been proposed in homeowner role or external entity
the literature. For example, Budd suggests a taxonomy of classes that sensor external entity
producers (sources) and consumers (sinks) of data, data managers, control panel external entity
occurrence
in
should never have an “imperative procedural name.” example, if system (alias security system) thing
the developers of software for a medical imaging system defined an object with number, not objects, attributes of sensor
the name image inversion,they would be making a subtle mistake. The im- master password thing
age obtained from the software could, of course, be an object (it is a thing that telephone number thing
-is part of the information domain). of the image is an operation that sensor event occurrence
is applied to the object. It is likely that inversion would be defined as an oper-
ation for the object image, but it would not be defined as a separate object to audible alarm external entity
connote “image inversion.” As states, “the intent of monitoring service organizational unit or external entity
orientation is to encapsulate, but still keep separate, data and operations on
the data.”
To illustrate how objects might be defined during the early stages of analy- The above list would be continued until all nouns in the processing narrative
sis, we return to the security system example introduced earlier in this have been considered. Note that we call each entry in the list a potential ob-
book. In Chapter 12, we performed a “grammatical parse” on a processing narra- ject. We must consider each further before a final decision is made.
tive for the system. The processing narrative is reproduced below: Coad and suggest six selection characteristics that should
be used as an analyst considers each potential object for inclusion in the analy-
sis model:
software enables the homeowner to configure the security sys-
tem when it is installed, monitors all sensors connected to the security system,
and interacts with the homeowner through a key pad and function keys con- 1. retained information-the potential object will be useful during analysis
tained in the control panel shown in Figure 11.4. only if information about it must be remembered so that the system can
function;
During installation, the control panel is used to “program” and
configure the system. Each sensor is assigned a number and type, a master 2. needed potential object must have a set of identifiable opera-
password is programmed for arming and disarming the system, and telephone tions that can change the value of its attributes in some way;
are input for dialing when a sensor event occurs. 3. attributes-during requirement analysis, the focus should be on
When sensor is recognized, the invokes an audible information (an object with a single attribute may, in fact, be use-
attached to the system. After a delay time that is specified by the homeowner ful during design, but is probably better represented as an attribute of an-
during configuration activities, the software dials a telephone number other object during the analysis activity);
of a service, provides information about the location, reporting 4. common attributes-aset of attributes can be defined for the potential ob-
ject, and these attributes apply to all occurrences of the object,
5. common operations-aset of operations can be defined for the potential ob-
ject, and these operations apply to all occurrences of the object; and
‘In this context, the term connotes any occurrence. It does not necessarily imply con- 6. essential requirements-external entities that appear in the problem space
trol as it did in Chapter 12.
and produce or consume information that is essential to the of
568 PART FOUR: SOFTWARE ENGINEERING CHAPTER 19: OBJECTORIENTED CONCEPTS AND PRINCIPLES 569
any solution for the system will almost always be defined as objects in the would be replaced (or augmented) by attributes like average salary, credit to-
requirements model. ward full vesting, pension plan options chosen, mailing address, and so on.
To develop a meaningful set of attributes for an object, the analyst can
To be considered a legitimate object for inclusion in the requirements again study the processing narrative (or statement of scope) for the problem
model, a potential object should satisfy all (or almost all) of the above charac- and select those things that reasonably “belong” to the object. In addition, the
teristics. The decision for inclusion of potential objects in the analysis model is following question should be answered for each object: “What data items (com-
somewhat subjective, and later evaluation may cause an object to be discarded posite and/or elementary) fully define this object in the context of the problem
or reinstated. However, the first step of OOA must be a definition of objects, at hand?”
and decisions (even subjective ones) must be made. With this in mind, we ap- To illustrate, we consider the system object defined for We
ply the selection characteristics to the list of potential objects: noted earlier in the book that the homeowner can configure the security sys-
tem to reflect sensor information, alarm response information, activation/deac-
tivation information, identification information, and so forth. Using the content
Potential Object/Class Characteristic Number that Applies
description notation defined for the data dictionary and presented in Chapter
homeowner rejected: 1, 2 foil even though 6 applies 12, we can represent these composite data items in the following manner:
all apply sensor information = sensor type + sensor number alarm threshold
control panel all apply
installation rejected
alarm response information = delay time + telephone number +
alarm type
system (alias security system) accepted: apply
number, type rejected: 3 foils, attributes of sensor activation/deactivation information = master password +
master password 3 foils number of allowable tries + temporary password
telephone number rejected: 3 foils identification information = system ID + verification phone number +
event accepted: apply “system
audible alarm accepted: 2, 3, 4, 5, 6
monitoring service 1, 2 fail even though 6 opplies Each of the data items on the right of the equal sign could be further defined
to an elementary level. But for our purposes, they comprise a reasonable list of
attributes for the system object (shaded portion of Figure 19.10).
It should be noted that the above list is not all-inclusive, additional objects
would have to be added to complete the model; some of the rejected poten-
tial will for that were accepted
numher and type are attributes of sensor, and master password and telephone 19.3.3 Defining Operations
number may become attributes of system); and different statements of the
problem might cause different “accept or reject” decisions to he made (e.g., if
each homeowner had his or her own password or was identified by voice print, Operations define the behavior of an object and change the object’s attributes
the homeowner object would satisfy characteristics 1 and 2 and would have in some way. More specifically, an operation changes one or more attribute val-
been accepted). ues that are contained within the object. Therefore, an operation must have
“knowledge” of the nature of the object’s attributes and must be implemented
in a manner that enables it to manipulate the data structures that have been
derived from the attributes.
19.3.2 Specifying Attributes Although many different types of operations exist, they can generally be di-
vided into three broad categories: (1) operations that manipulate data in some
Attributes describe an object that has been selected for inclusion in the analy- adding, deleting, reformatting, selecting); operations that perform
sis model. In essence, it is the attributes that define the object--that clarify a and (3) operations that monitor an object for the occurrence of
what is meant by object in the context of the problem space. For example, a controlling event.
if we were to build system that tracks for professional baseball play- As a iteration at deriving a set of operations for objects of the
ers, the attributes of the object player would from the at- analysis model, the analyst can again study the processing narrative (or state-
tributes of the same object when it is used in the context of the professional ment of scope) for the problem and select those operations that reasonably be-
baseball pension system. In the former, attributes such as name, position, bat- long to the object. To accomplish this, the grammatical parse is again studied
ting average, fielding percentage, years played, and games played might he rel- and verbs are isolated. Some of these verbs will be legitimate operations and
evant. For the latter, some of these attributes would be meaningful, but others can be easily connected to a specific object. For example, from the
CHAPTER 19: OBJECTORIENTED CONCEPTS AND PRINCIPLES 571
570 PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING
193.4 Finalizing the Object Definition
object system
The definition of operations is the last step in completing the specification of
system ID an object. In Section 19.3.3, operations were culled from a grammatical parse
verification phone number of the processing narrative for the system. Additional operations may be de-
system status termined by considering the “life history” of an object and the mes-
sensor table sages that are passed among objects defined for the system.
sensor type The generic life history of an object be defined by recognizing that the
object must be created, modified, manipulated or read in other ways, and pos-
sensor number
sibly deleted. For the system object, this can be expanded to reflect known ac-
alarm threshold tivities that occur during its life (in this case, during the time that
alarm delay time is operational). Some of the operations can be ascertained from likely commu-
telephone number(s) nication between objects. For example, sensor event will send a message to
alarm threshold system to display the event location and number; control panel will send a
master password message to update system status (an attribute); the audible alarm will
temporary password send a message; the control panel will send a modify message to change
number of tries one or more attributes without reconfiguring the entire system object; sensor
event will also send a message to call the phone number(s) contain in the ob-
program ject.. Other messages can be considered and operations derived. The resulting
display object definition is shown in Figure 19.10.
reset A similar would for each of the objects for
After attributes and operations are defined for each of the objects
FIGURE 19.10. defined to this point, the beginnings of an OOA model would be created. A more
The system modify
detailed discussion of the analysis model that is created as part of OOA is pre-
with operations call sented in Chapter 20.
19.4 Management of Object-Oriented Projects
processing narrative presented earlier in this chapter, we see that “sensor is as-
signed a number and type” or that “a master password is programmed for arm- As we discussed in Part Two of this book, modern software project management
% and disarming the system.“These two phrases indicate a number of things: can be subdivided into the following activities:
!" that an assign operation is relevant for the sensor object; 1. Establishing a common process framework for the project
!"that a program operation will be applied to the system object; 2. Using the framework and historical metrics to develop effort and time es-
!" that arm and disarm are operations that apply to system (also that system
timates
status may ultimately be defined using data dictionary notation) as 3. Specifying work products and milestones that will enable progress to be
measured
system status = [armed disarmed] 4. Defining checkpoints for quality assurance and control
5. Managing the changes that invariably occur’ as the project progresses
Upon further investigation, it is likely that operation program will be di- 6. Tracking, monitoring, and controlling progress
vided into a number of more specific suboperations required to configure the
implies configuring
The technical manager who is with an object-oriented project
creating the sensor table, inputting alarm charac-
these six activities. But because of the nature of object-oriented
teristics), and inputting password(s), but for now, we specify program as a sin-
ware, each of these management activities has a subtly different feel and must
gle operation.
In addition to the grammatical parse, we can gain additional insight into be approached using a somewhat different mind-set.
In the sections that follow, we explore software project management for ob-
other operations by considering the communication that occurs between ob-
ject-oriented projects. The fundamental principles of management stay the
jects. As we have seen, objects communicate by passing messages to one an-
same, but the technique must be adapted so that an 00 project is properly
other. The messages that pass among objects imply a set of operations that
must be present. managed.
572 PART FOUR: SOFTWARE ENGINEERING CHAPTER 19: CONCEPTS AND PRINCIPLES 573
19.4.1 The Common Process for 00 !" Conduct this reapplication of decomposition concurrently on all components
parallel) part.
A common process framework defines an organization’s approach to soft- !" Continue this process until completion criteria are attained.
ware development and It identifies the software par-
adigm that is applied to build and maintain software, and the tasks, mile- It’s important to note that the decomposition process noted above is discontin-
stones, and deliverables that will be required. It establishes the degree of rigor ued if the analyst/designer recognizes that the component or subcomponent re-
with which different kinds of projects will be approached. quired is available in a reuse library.
The CPF is always adaptable so that it can meet the individual needs of a To control the recursive/parallel process framework, the project manager
project team. This is its single most important characteristic, must recognize that progress is planned and measured incrementally. That is,
An effective CPF for 00 projects is not a linear sequential model. Linear project tasks and the project schedule are tied to each of the indepen-
sequential models, best known as life cycle or waterfall models, assume that re- dent components,” and progress is measured for each of these components in-
quirements are defined at the front end of the project and that engineering ac- dividually.
tivities progress in a linear sequential fashion. By its nature, object-oriented Each iteration of the recursive/parallel process requires planning, engi-
software engineering must apply a paradigm that encourages iterative devel- neering (analysis, design, class extraction, prototyping, and testing) and evalu-
opment. That is, 00 software evolves through a number of cycles. The common ation activities (Figure 19.11). During planning, activities associated with each
process framework that is used to manage an 00 project must be evolutionary of the independent program components are planned and scheduled. [Note:
in nature. A process model for 00 was presented in Section 19.1. With each iteration the schedule is adjusted to accommodate changes associ-
Ed Berard and Grady among others suggest the ated with the preceding iteration.] During early stages of engineering, analy-
use of a “recursive/parallel model” for object-oriented software development. In sis and design occur iteratively. The intent is to isolate all important elements
essence the recursive/parallel works in the following way: of the 00 analysis and design models. As engineering work proceeds, incre-
mental versions of the software are produced. During evaluation, reviews, cus-
!" Do enough analysis to isolate major problem classes and connections. tomer evaluation, and testing are performed for each increment, with feedback
!" Do a little design to determine whether the classes and connections can be affecting the next planning activity and subsequent increment.
implemented in a practical way.
!" Extract reusable objects from a library to build a rough prototype.
!" Conduct some tests to uncover errors in the prototype.
19.4.2 Object-Oriented Project Metrics and Estimation
. Get customer feedback on the prototype.
!" Modify the analysis model based on what you’ve learned from the prototype,
Conventional software project estimation techniques require estimates of lines
from doing design, and from customer feedback.
of code or function points as the primary driver for estimation.
!"Refine the design to accommodate your changes. Because an overriding goal for 00 projects should be reuse, LOC estimates
!" Engineer special objects (that are not available from the library). make little sense. FP estimates can be used effectively because the information
!" Assemble a new prototype using objects from the library and the new objects
domain counts that are required are readily obtainable from the problem state-
you’ve created. ment. FP analysis may provide value for estimating 00 projects, but the FP
measure does not provide enough granularity for the schedule and effort ad-
!" Conduct some tests to uncover errors in the prototype.
justments that are required as we the recursive/parallel para-
!" Get customer feedback on the prototype. digm.
Lorenz and suggest the following set of project
This approach continues until the prototype evolves into a production application.
The recursive/parallel model is quite similar to the 00 process model pre- A
Number of scenario scripts. scenario is a detailed sequence of
sented earlier in this chapter. Progress occurs iteratively. What makes the re- steps that describe the interaction between the user and the application.
cursive/parallel model different is the recognition that analysis and design Each script is organized into triplets of the form
modeling for 00 systems cannot be accomplished at an even level of abstrac-
tion, and (2) analysis and design can be applied to independent system compo-
nents concurrently. [initiator, action, participant1
Berard describes the model in the following manner:
!" Systematically decompose the problem into highly independent components. metrics for 00 in detail in Chapter 23.
!" Reapply the decomposition process to each of the independent components to scenario script defined by and Kidd is analogous the ease discussed in
decompose each further (the recursive part). Chapter 20.
CHAPTER CONCEPTS AND PRINCIPLES 5 7 5
PART FOUR. OBJECT-ORIENTED SOFTWARE ENGINEERING
The number of support classes is an indication of the amount of effort
required to develop the software and also an indication of the potential
amount of reuse to be applied during system development.
Average number of support classes per key class. general, key In
Early analysis/design classes are known early in the project. Support classes are defined through-
out. If the average number of support classes per key class were known for
a given problem domain, estimating (based on total number of classes)
would be much simplified.
Lorenz and Kidd suggest that applications with a GUI have between
two and three times the number of support classes as key classes. Non-GUI
applications have up to twice the number of support classes as key classes.
and refinement A
Number of subsystems. subsystem is an aggregation of classes that
support a function that is visible to the end user of a system. Once sub-
First systems are identified, it is easier to lay out a reasonable schedule in which
work on subsystems is partitioned among project staff.
19.4.3 An 00 Estimating and Scheduling Approach
Next
increment Software project estimation is an art, not a science. However, this in no way
precludes the use of a systematic approach. To develop reasonable estimates it
is essential to develop multiple data points. That is, estimates should be de-
rived using a of different techniques. Effort and duration estimates
used for conventional software development (Chapter 5) are applicable to the
nth 00 world, but the historical database for 00 projects is relatively small for
increment many organizations. Therefore, it is worthwhile to supplement conventional
software cost estimation with an approach that has been designed explicitly for
00 software. Lorenz and suggest the following approach:
FIGURE 19.11. Typical process sequence for on 00 project
1. Develop estimates using decomposition, FP analysis, and any other
method that is applicable for conventional applications.
where initiator is the object that requests some service (that initiates a 2. Using OOA develop scenario scripts and determine a count.
message); action is the result of the request; and is the server Recognize that the number of scenario scripts may change as the project
object that satisfies the request. progresses.
The number of scenario scripts is directly correlated to the size of the
application and to the number of test cases that must be developed to ex- 3. Using OOA, determine the number of key classes.
ercise the system once it is constructed. Categorize the type of interface for the application and develop a multiplier
Number of key classes. Key classes are the “highly independent compo- for support classes:
nents” that are defined early in OOA. Because key classes are cen-
tral to the problem domain, the number of such classes is an indication of Interface Type Multiplier
the amount of effort required to develop the software and also an indica-
tion of the potential amount of reuse to be applied during system develop- No GUI 2.0
ment. , Text-based user 2.25
Number of support classes. Support classes are required to implement GUI 2.5
the system, but are not immediately related to the problem domain. Complex GUI 3.0
Examples might be GUI classes, database access and manipulation, and
communication classes. In addition, support classes can be developed for
each of the key classes, Support classes are defined iteratively throughout Multiply the number of key classes (step by the above multiplier to
the recursive/parallel process. obtain an estimate for number of support classes.
576 PART FOUR. SOFTWARE ENGINEERING CHAPTER 19: OBJECTORIENTED CONCEPTS AND PRINCIPLES 577
5. Multiply the total number of classes (key + support) by the average num- !" Attributes and operations have been designed and reviewed.
ber of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days !" The messaging model has been created and reviewed.
per class.
6. Cross check the class based estimate by multiplying the average number Technical milestone: 00 programming completed
of work units per scenario script !" Each new class has been implemented in code from the design model.
!"Extracted classes (from a reuse library) have been integrated.
Scheduling for object-oriented projects is complicated by the iterative nature of
!" A prototype or increment has been built.
the process framework. Lorenz and Kidd suggest a set of metrics that may as-
sist during project scheduling:
milestone: 00 testing
Number of iterations.Thinking back to the 00 process model, a !"The correctness and completeness of 00 analysis and design models have
major iteration would correspond to one 360 degree traversal of the spiral. been reviewed.
The recursive/parallel process model would spawn a number of mini-spi- !" A class-responsibility-collaboration network (Chapter has been devel-
rals (localized iterations) that occur as the major iteration progresses. oped and reviewed.
and Kidd suggest that iterations of between 2.5 and 4 months in
!" Test cases are designed and class-level tests (Chapter have been con-
length are easiest to track and manage.
ducted for each class.
Number of completed contracts. A contract is “a group of related public
!" Test cases are designed and cluster testing (Chapter is completed, and
responsibilities that are provided by subsystems and classes to their clients”
A contract is an excellent milestone, and at least one contract the classes are integrated.
should be associated with each project iteration. A project manager can use !" System-level tests are completed.
completed contracts as a good indicator of progress on an 00 project.
Recalling the recursive/parallel process model discussed earlier in this chapter,
it is important to note that each of these milestones may be revisited as dif-
ferent increments are delivered to the customer.
19.4.4 Tracking Progress for an Object-Oriented Project
Although the recursive/parallel process model is the best framework for an 00 19.5
project, task parallelism makes project tracking difficult. The project manager
can have establishing meaningful milestones for an 00 project be- Object technologies reflect a natural view of the world. Objects are categorized
cause a number of different things are happening at once. In general, the fol- into classes and class hierarchies. Each class contains a set of attributes that
lowing major milestones can be considered “completed” when the criteria noted describe it and a set of operations that define its behavior. Objects model al-
have been met: most any identifiable aspect of the problem domain: External entities, things,
occurrences, roles, organizational units, places, and structures can all be rep-
Technical milestone: 00 analysis completed resented as objects. As important, objects (and the classes from which they are
derived) encapsulate both data and process. Processing operations are part of
!" All classes and the class hierarchy have been defined and reviewed. the object and are initiated by passing the object a message. A class definition,
!" Class attributes and operations associated with a class have been defined once defined, forms the basis for reusability at the modeling, design, and im-
and reviewed. plementation levels. New objects can be instantiated from a class.
!" Class relationships (Chapter have been established and reviewed. Three important concepts differentiate the 00 approach from conventional
!" A behavioral model (Chapter 20) has been created and reviewed.
software engineering. Encapsulation packages data and the operations that
manipulate the data into a single named object. Inheritance enables the at-
!" Reusable classes have been noted.
tributes and operations of a class to be inherited by all subclasses and the ob-
jects that are instantiated from them. Polymorphism enables a number of dif-
Technical milestone: 00 design completed ferent operations to have the same name, reducing the number of lines of code
!" The set of subsystems (Chapter have been defined and reviewed. required to implement a system and facilitating changes when they are made.
and using an
00
!"
with product will
!" Responsibilities and collaborations have been identified. be developed over a series of increments.
578 PART FOUR: OBJECT-ORIENTED SOFTWARE ENGINEERING
CHAPTER 19. OBJECT-ORIENTED CONCEPTS AND PRINCIPLES 579
REFERENCES 19.8. You been assigned job of engineering word-processing soft-
ware. A class named document is identified. Define the attributes and op-
Berard, E.V., Essays on Object-Oriented Software Engineering, Addison- erations that arc relevant for document.
Wesley, 1993. 19.9. Research two 00 programming languages and show how messages
G.. “Obiect-Oriented Development,” Trans. Engi- are implemented in the language syntax. Provide a few examples for each
neer&, SE-12, no. 2, pp. 211ff. language.
G., Object-Oriented Design, Benjamin Cummings, 1991. 19.10. Provide concrete example of class hierarchy restructuring as described in
[BUD961 Budd, An to Programming, 2nd edition, the discussion of Figure 19.8.
Addison-Wesley, 1996. 19.11. Provide a of multiple inheritance. Research one or more
M., “Object Oriented Domain Analysis,” ACM papers on this subject and provide the pro and con arguments for multiple
Engineering Notes, vol. 14, no. 6, October 1989, 67. inheritance.
de Champeaux, D., D. Lea, and P. Object-Oriented System
19.12. Develop a statement of scope for a system requested by your instructor. Use
Development, Addison-Wesley, 1993.
Coad, and E. Object-Oriented Analysis, 2nd edition, the grammatical parse to isolate candidate classes, attributes, and opera-
tions for the system. Apply the selection criteria discussed in Section 19.3.1
Hall, 1991.
to should uxcd in the analysis model.
Cox, B.J., Object-Oriented Programming, Addison-Wesley, 1986.
Requirements Analysis (course notebook), EVB why is
Engineering, Inc., Frederick, MD, 1989. proprinte for
Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley, 19.14. Provide three or four specific examples of the key class and support class de-
1992. scribed in Section 19.4.2.
M., and Kidd, Object-Oriented Software Metrics, Prentice-Hall,
1994.
Stroustrup, B., What is Object-Oriented Programming?”
FURTHER READINGS AND OTHER INFORMATION SOURCES
vol. 5, no. 3, May 1988, pp.
Taylor, D.A., Object-Oriented Technology: A Manager’s Guide, Addison-
Wesley, 1990. The explosion of interest in object technologies has resulted in the publication
of literally hundreds of books during the past decade. Taylor’s abbreviated
treatment remains the best basic introduction to the subject. Books
Baudoin and (Realizing the Object-Oriented Life Cycle, Prentice-Hall,
PROBLEMS AND POINTS TO PONDER 19961, and Abnous (Object-Orientation, Wiley, 19951, Meyer
Success: A Guide to Object-Orientation, Prentice-Hall, 19951, Berard
Wilkie (Object-Oriented Software Engineering, Addison-Wesley, 19931,
19.1. The object-oriented paradigm is “hot.” Articles at every level of technical and Winblad et al. (Object-Oriented Software, Addison-Wesley, 19901 provide
phistication have been written about it. Using the Reader’s Guide in your li- additional insight into basic concepts, languages, databases, and user inter-
brary, three current nontechnical (not published in engineering journals faces.
or magazines; PC magazines are O.K.) articles and write a brief paper sum- An excellent anthology of early papers on object-oriented issues has been
marizing what they have to say. compiled by Peterson (Object-Oriented Computing: Concepts, IEEE Computer
19.2. In this chapter we did not consider the case in which a new object requires Society Press, 1987). Sigfried (Understanding Object-Oriented Software
an attribute or operation that is not contained in the class from which it in- . IEEE Computer Society Press, discusses techniques for class and
herited all other attributes and operations. How do you think this is handled? object definition.
19.3. Do some research and find the real answer to problem 19.2. Proceedings, a publication that summarizes the ACM’s yearly
19.4. Using your own words and a few examples, define the terms “class,” “encap- conference on object-oriented programming systems, is dedicated to object-ori-
sulation,” “inheritance,” and “polymorphism.” ented topics and contains many useful papers. Object Magazine, Journal of
19.6. Review the objects defined for the system. Are there other objects Object-Oriented Programming, C++ Report, and The Smalltalk Report are all
that you feel should be defined as modeling begins? published by SIGS Publications, Inc. in Langhorne, Pennsylvania. In October
1995, issues of Communications of the ACM, Computer. and
19.6. Consider a typical graphical user interface (GUI). Define a set of classes Development were all dedicated to object technologies.
(and subclasses) for the interface entities that typically appear in the GUI.
The Internet newsgroup comp.object is a useful source for information,
Be sure to define appropriate attributes and operations. discussion, and debate on object technologies. The FAQ for this newsgroup is
19.7. Provide an example of a composite object. one of the most comprehensive collections of 00 information on the Internet.
580 PART FOUR: SOFTWARE ENGINEERING
The FAQ contains a discussion of most important 00 concepts, as well as de-
tailed discussion of 00 languages, databases, tools, and associated vendors, and
can be found at:
Further discussion of 00 issues may be found in
ANALYSIS
, c o m p . s p e c i f i c a t i o n , a n d c o m p . t e s t i n g . Pointers
to dozens of Web sites, archive information, and related topics on object tech-
nologies can be obtained at:
An excellent 00 tutorial that is very useful for those who are learn-
ing about the subject can be found at:
Detailed summaries of dozens of books on 00 methods can be obtained at:
A comprehensive bibliography with references to concepts, methods and lan-
guages and tools can be obtained at:
W hen a new product or system is to be built, how do we characterize it
in a way that is amenable to 00 software engineering? What are the
relevant objects? How do they relate to one another? How do objects behave in
the context of the system? How do we specify or model a problem so that we
can create an effective design?
Each of these questions is answered within the context of object-oriented
analysis first technical activity that is performed as part of 00
A collection of useful white papers, general information, references, and point- software engineering. OOA is grounded in a set of basic principles that were
ers can be acquired by visiting: introduced in Chapter 11. In order to build an analysis model, five basic prin-
ciples are applied: (1) The information domain is modeled; (2) module function
is described, (3) model behavior is represented; the models are partitioned
to expose greater detail; and early models represent the essence of the prob-
An up-to-date list of World Wide Web references for object technologies can lem while later models provide implementation details. These principles form
be found at: the foundation for the approach to OOA presented in this chapter.
The intent of OOA is to define all classes (and the relationships and be-
havior associated with them) that are relevant to the problem to solved. To
accomplish this, a number of tasks must occur:
1. Basic user requirements must be communicated between the customer and
the software engineer.
2. Classes must be identified (i.e., attributes and methods are defined).
3. A class hierarchy must be specified.
4. Object-to-object relationships (object connections) should be represented.
Object behavior must be modeled.
6. Tasks 1 through 5 are reapplied iteratively until the model is complete.
581
PART OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 20: ANALYSIS
582
Instead of examining a problem using the classic input-processing-output (in- Fichman and Kemerer suggest 11 “modeling dimensions” that may
formation flow) model or a model derived exclusively from hierarchical infor- be used to compare various conventional and object-oriented analysis methods:
mation structures, OOA introduces a number of new concepts. These new con-
cepts may seem a bit unusual, but they are really quite natural. Coad and 1. identification/classification of entities’
this when they write: a. general to specific and whole to part entity relationships
3. other entity relationships
analysis-is concepts that we first learned in
kindergarten: objects and attributes, classes and members, wholes and parts. 4. description of ‘attributes of entities
Why it has taken us so long to apply these concepts to the analysis and speci- 5. large scale model partitioning
fication of information systems is anyone’s guess-perhaps we’ve been too busy 6. states and transitions between states
“following the flow” during the heyday of structured analysis to consider the al- 7. detailed specification for functions
ternatives.
8. top-down decomposition
It is important to note that there is no universal agreement on the “concepts” 9. end-to-end processing sequences
for of kry ideas appear 10. of exclusive services
il. ix will in 11. communication (via or events)
Because many variations exist for structured analysis and dozens of OOA
20.1 OBJECT-ORIENTEDANALYSIS methods (see Section are available, it is to develop a general-
ized comparison between the two methods. It can be stated, however, that mod-
The objective of object-oriented analysis is to develop a series of models that eling dimensions 8 and 9 are always present with SA and rarely present when
describe computer software as it works to satisfy a set of customer-defined re- OOA is used.
quirements. OOA, like the conventional analysis methods described in Chapter
12, builds a multipart analysis model to satisfy this objective. The analysis
model depicts information, function, and behavior within the context of the el- 20.1.2 The OOA Landscape
ements of the object model described in Chapter 19.
The popularity of object technologies has spawned dozens of OOA
Each of these introduces a process for the analysis of a product or system, a set
20.1.1 Conventional vs. 00 approaches of models that evolves out of the process, and a notation that enables the soft-
ware engineer to create each model in a consistent manner. In the paragraphs
Is object-oriented’ analysis really different from the structured analysis ap- that follow, some of the more popular OOA are presented in outline
proach that was presented in Chapter Although debate continues, Fichman form. The intent is to provide a snapshot of the OOA process that has been pro-
and Kemerer address the question head-on: posed by the of the method.*
We conclude that the object-oriented analysis approach represents a radi- Method The method encompasses both a “micro de-
cal change over process-oriented methodologies such as structured analysis, but velopment process” and a “macro development process.” The micro level defines
only an incremental change over data oriented methodologies such as infor-
mation engineering. Process-oriented methodologies focus attention away from
the inherent properties of objects during the modeling process and lead to a
model of the problem domain that is orthogonal to the three essential princi- this context, “entity” refers to either a data object (in the structured analysis sense) or
object (in the OOA sense).
ples of object-orientation: encapsulation, classification of objects, and inheri-
tance. detailed of these methods and their differences is beyond the scope of this book.
The interested reader should refer to and Graham for detailed com-
parisons.
Stated simply, structured analysis takes a distinct input-process-output view general, OOA methods are identified using the name(s) of the developer of the method,
of requirements. Data are considered separately from the processes that trans- even if the method has been given a unique name or acronym.
form the data. System behavior, although important, tends to play a secondary meaning of many of the steps outlined in the process descriptiona that follow will be die-
role in structured analysis. The structured analysis approach makes heavy use cussed in Sections 20.3 and 20.4. It should also be noted that each of these methods
of functional decomposition (partitioning of the data flow diagram, Chapter component that will be briefly in Chapter 21.
PART FOUR: SOFTWARE ENGINEERING CHAPTER OBJECTORIENTED ANALYSIS
a set of analysis tasks that are re-applied for each stop in the macro process. by heavy emphasis on the case-a description or scenario that depicts how
Hence, an evolutionary approach is maintained. The method is sup- the user interacts with the product or system. A brief outline of Jacobson’s OOA
ported by a variety of automated tools. A brief outline of OOA micro de- process follows:
velopment process follows:
!" Identify the users of the system and their overall responsibilities.
!"Identify classes and objects. !" Build a requirements model.
Propose candidate objects. Define the actors and their responsibilities.
Conduct behavior analysis. Identify use cases for each actor.
Identify relevant scenarios. Prepare initial view of system objects and relationships.
Define attributes and operations for each class. Review model using use cases as scenarios to determine validity.
!"Identify the semantics of classes and !" Build analysis model.
Select scenarios and analyze. Identify interface objects using actor-interaction information.
Assign responsibility to achieve desired behavior. Create structural views of interface objects.
Partition responsibilities to balance behavior. Represent object behavior.
Select an object and enumerate its roles and responsibilities. Isolate subsystems and models for each.
Define operations to satisfy the responsibilities. Review the model using use cases as scenarios to determine validity.
Look for collaborations among objects.
!" Identify relationships among classes and objects. The Rambaugh and his colleagues developed the
Define dependencies that exist between objects. Object Modeling Technique for analysis, system design, and object-level
Describe the role of each participating object. design. The analysis activity creates three models: the object model repre-
sentation of objects, classes, hierarchies, and relationships), the dynamic model
Validate by walking through scenarios. (a representation of object and system behavior), and the functional model
!" Conduct a series of refinements. high-level DFD-like representation of information flow through the system). A
Produce appropriate diagrams for the work conducted above. brief outline of Rambaugh’s OOA process follows:
Define class hierarchies as appropriate.
!" Develop a statement of scope for the problem.
Perform clustering based on class commonality.
!" Build an object model.
!" Implement classes and objects (in the context of OOA, this implies comple-
tion of the analysis model). Identify classes that are relevant for the problem.
Define attributes and associations.
The Cwd and Method The Coad and method is of- Define object links.
ten viewed as one of the easiest OOA methods to learn. Modeling notation is Organize object classes using inheritance.
relatively simple and guidelines for developing the analysis model are straight-
forward. A brief outline of Coad and Yourdon’s OOA process follows: !" Develop a dynamic model.
Prepare scenarios.
!" Identify objects using “what look for” criteria. Define events and develop an event trace for each scenario,
!"Define a generalization-specification structure. Construct an event flow diagram.
!"Define a whole-part structure. Develop a state diagram.
!" Identify subjects (representations of subsystem components) Review behavior for consistency and completeness.
!" Define attributes. !" Construct a functional model for the system.
!" Define services. Identify inputs and outputs.
Use data flow diagrams to represent flow transformations.
Jacobson Also called OOSE (object-oriented software engineering), Develop (Chapter for each function.
the Jacobson method is a simplified version of the proprietary
method, also developed by Jacobson. This method is differentiated from others Specify constraints and optimization criteria.
PART FOUR: SOFTWARE ENGINEERING CHAPTER OBJECTORIENTED ANALYSIS 587
It should be noted that work is underway to merge the and Rambaugh ning. At the business area level, an object model that describes the workings of
methods. The resultant set of notation and heuristics, called the Unified Method a particular business area (or a category of products or systems) can be defined.
combines the strong data emphasis of Rambaugh with the At an application level, the object model focuses on specific customer require-
behavioral and operational emphasis of ments as those requirements affect an application to be built.
OOA at the highest level of abstraction (the enterprise is beyond the
The Method Wirfs-Brock method does not make a clear scope of this book. Interested readers should see and
distinction between analysis and Instead, a continuous process for a detailed discussion. OOA at the lowest level of abstraction falls
that begins with the assessment of a specification and ends with de- within the general purview of object-oriented software engineering and is the fo-
sign is proposed. A brief outline of Wirfs-Brock’s analysis-related tasks follows: cus of all other sections of this chapter. In this section, we focus on OOA that is
conducted at the middle level of abstraction. This activity, called domain analysis,
is conducted when an organization wants to create a library of reusable classes
!" Evaluate the customer specification.
(components) that will be broadly applicable to an entire category of applications.
!" Use a grammatical parse to extract candidate classes from the specification.
!" Group in un to
!" Define responsibilities for each class.
20.2.1 Reuse and Domoin Analysis
!" Assign responsibilities to each class.
!" Identify relationships between classes. Object technologies are leveraged through reuse. Consider a simple example.
!" Define collaboration between classes based on responsibilities. The analysis of requirements for a new application indicates that 100 classes
!" Build hierarchical representations of classes to show inheritance relationships.
are needed. Two teams are assigned to build the application. Each will design
and construct a final product. Each is populated by people with the same skill
!" Construct a collaboration graph for the system. levels and experience.
Team A does not have access to a class library, so it must develop all 100
Although the terminology and process steps for each of these OOA methods dif- classes from scratch. Team B uses a robust class library and finds that 55
fer, the overall OOA processes are really quite similar. To perform object-ori- classes already exist. It is highly likely that:
ented analysis, a software engineer should perform the following generic steps:
1. Team B will finish the project much sooner than team A.
!" Obtain customer requirements for the 00 System. 2. The cost of team B’s product will be significantly lower than the cost of
Identify scenarios or use cases. product.
Build a requirements model. 3. The product produced by team B will have fewer delivered defects than
!"Select objects using basic requirements as a guide. team A’s product.
!" Identify attributes and operations for each system object.
Although the margin by which team B’s work would exceed team A’s accom-
!" Define structures and hierarchies that organize classes.
plishments is open to debate, few would argue that reuse provides team B will
!" Build an object-relationship model. a substantial advantage.
!" Build an object-behavior model. But where did the “robust class library” come from? And how were the en-
!" Review the 00 analysis model against use cases/scenarios. tries in the library determined to be appropriate for use in new applications?
To answer these questions, the organization that created and maintained the
library had to apply domain analysis.
These generic steps are considered in greater detail in Sections 20.3 and 20.4.
20.2 DOMAIN ANALYSIS 20.2.2 The Domain Analysis Process
Analysis for object-oriented systems can occur at many different levels of ab- Firesmith describes software domain analysis in the following way:
straction. At the business or enterprise level, the techniques associated with
OOA can be coupled with an information engineering approach (Chapter 10) in Software domain is the identification, analysis, and specification of
an effort to define classes, objects, relationships, and behaviors that model the common requirements from a specific application domain, typically for reuse on
entire business. This level of OOA is analogous to information strategy multiple projects within that application domain. [Object-oriented domain
588 PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER ANALYSIS 589
analysis the identification, analysis, and specification of common, reusable interest. Next, both 00 and non-00 “items” must be extracted. 00 items
capabilities within a specific application domain, in terms of common objects, include specifications, designs, and code for existing 00 application classes;
classes, subassemblies, and frameworks. . . support classes (e.g., GUI classes or database access classes); commercial
off-the shelf (COTS) component libraries that are relevant to the domain;
The “specific application domain” can range from avionics to banking, from and test cases. Non-00 items encompass policies, procedures, plans, stan-
multimedia video games to applications within a CAT scanner. The goal of do- dards, and guidelines; parts of existing non-00 applications (including
main analysis is straightforward: to or create those classes that are broadly specification, design and test information); metrics; and COTS non-00
applicable, so that they may be reused.” software.
Using jargon that was introduced earlier in this book, domain analysis
may be viewed as an umbrella activity for the software process. By this we Categorize the items extracted the domain. The items are or-
mean that domain analysis is an ongoing software engineering activity that ganized into categories, and the general defining characteristics of the cat-
is not connected to any one software project. In a way, the role of a domain egory are defined. A classification scheme for the categories is proposed,
analyst is similar to the role of a master toolsmith in a heavy manufacturing and naming conventions for each item are defined. When appropriate, clas-
environment. The job of the toolsmith is to design and build tools that may sification hierarchies are established.
be used by many people doing similar, but not necessarily the same jobs. The Collect a representative sample of applications in the domain. To
role of the domain analyst is to design and build reusable components that accomplish this activity, the analyst must ensure that the application in
may be used by many people working on similar, but not necessarily the same question has items that into the categories that have already been
applications. lined. Berard notes that during the early stages of use of object
Figure 20.1 illustrates key inputs and outputs for the domain technologies, a software organization will have few if any 00 applications.
analysis process. Sources of domain knowledge are surveyed in an attempt to Therefore, the domain analyst must “identify the conceptual (as opposed to
identify objects that can be reused across the domain. In essence‘domain analy- physical) objects in each application.”
sis is quite similar to knowledge engineering. The knowledge engineer investi-
gates a specific area of interest in an attempt to extract key facts that may be Analyze each application in the sample. The following steps
of use in creating an expert system or artificial neural network. During domain occur during domain analysis:
analysis, object (and class) extraction occurs. !" identify candidate reusable objects;
The domain analysis process can be characterized by a series of activities !" indicate the reasons that the object has been identified for reuse;
that begin with the identification of the domain to be investigated and end with
!" define adaptations to the object that may also be reusable;
a specification of the objects and classes that characterize the domain. Berard
!" estimate the percentage of applications in the domain that might
suggests the following
make reuse of the object; and
Define the domain to be investigated. To accomplish this, the analyst !" identify the objects by name, and use configuration management tech-
must isolate the business area, system type, or product category of niques (Chapter to control them.
In addition, once the objects have been defined, the analysis should esti-
mate what percentage of a typical application could be constructed using
the
Develop an analysis model for the objects. Theanalysis model will
service as the basis for design and construction of the domain objects.
technical literature In addition to these steps, the domain analyst should also create a set of reuse
class taxononmies guidelines and develop an example that illustrates how the domain objects
reuse standards could be used to create a new application.
Domain Domain analysis is the first technical activity in a broader discipline that
functional models Analysis some call domain engineering (Chapter 26). When a business, system, or prod-
Model uct domain is defined to be business strategic in the long term, a continuing ef-
domain languages
fort to create a robust reuse library can be undertaken. The goal is to be able
to create software within the domain with a very high percentage of reusable
components. Lower cost, higher quality, and improved time to market are the
FIGURE 20.1. Input and outputs for domain analysis arguments in favor of a dedicated domain engineering effort.
590 PART FOUR. OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER ANALYSIS 591
20.3 GENERIC COMPONENTS OF THE 00 ANALYSIS MODEL These by defining a sequence of operations that
achieve them.
The object-oriented analysis process conforms to the basic analysis Dynamic view of communication. Objects must communicate with one
and principles discussed in Chapter 11. Although the terminology, notation, another and do so based on a series of events that cause transitions from
and activities differ from conventional methods, OOA (at its kernel) addresses one state of a system to another.
the same underlying objectives. Rambaugh et al. discuss this when The
Dynamic view of control and time. nature and timing of events
they state: that cause transitions among states must be described.
Analysis is concerned with devising a precise, concise, understandable, As shown in Figure 20.2, de Champeaux and his colleagues define a
and correct model of the real world. The purpose of object-oriented analy- slightly different view of OOA representations. Static and dynamic components
sis is to model the real world so that it can be understood. To do this, you are identified for object internals and for inter-object representations. A dy-
must examine requirements, analyze their implications, and them rig- namic view of object internals can be characterized as an object life history, that
orously. You must abstract real-world features first, and defer small details is, the states of the object over time as various operations are performed on its
until later. attributes.
To develop a “precise, concise, understandable, and correct model of the real
world,” a software engineer must select from number of OOA nota- 20.4 THE OOA PROCESS
tions and processes. As we noted in Section 20.1.2, each OOA method (and
there are dozens of them) has a unique process and a distinct notation. And The OOA process does not begin with a concern for objects. Rather, it begins
yet, all conform to a set of generic process steps (Section and all pro- with an understanding of the manner in which the system will be
vide a notation that implements a set of generic components of an 00 analy people, if the system is human-interactive; by machines, if the system is in-
sis model. volved in process by other programs, if the system coordinates and
and Puhr define a set of generic representational com- controls applications. Once the scenario of usage has been defined, the model-
ponents that appear in all 00 analysis Static components are struc- ing of the software begins.
tural in nature and indicate characteristics that hold throughout the opera- The sections that follow define a series of techniques that may be used
tional life of an application. These characteristics distinguish one object from gather basic customer requirements and then define an analysis model for an
other objects. components focus on control and are sensitive to timing object-oriented system.
and event processing. They define how one object interacts with other objects
over time. The following components are identified
Static view of semantic classes.A taxonomy of typical classes was
in Chapter 19. Requirements are assessed and classes are extracted object interobject
(and represented) as part of the analysis model. These classes persist internals representations
throughout the life of the application and are derived based on the se-
mantics of the customer requirements.
Static view of attributes. Every class ‘must be described. The class object relationships
static
attributes associated with the class provide a description of the class as attributes states
components
well as a indication of the operations that are relevant to the class. operations transitions
Static view of relationships. Objects are “connected” to one another in
a variety of ways. The analysis model must represent these relationships
so that operations (that affect these connections) can be identified and so
that the design of an messaging approach can be accomplished.
Static view of behaviors. The relationships noted above define a set of communication
dynamic
behaviors that accommodate the usage scenario cases) of the system. object life history
components timing
FIGURE 20.2.
authors also provide an analysis of 23 OOA methods and indicate how they OOA
address these components.
PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAF’TER ANALYSIS 593
20.4.1 Use Cases central station that monitors For the purposes of this example, we
consider only the homeowner actor. The homeowner interacts with the product
Requirements gathering is always the first step in any software analysis ac- in a number of different ways:
tivity As we discussed in Chapter 11, requirements gathering can take the
form of a FAST meeting in which customer and developer meet to define basic !" inputs a password to allow all other interactions
system and software requirements. Based on these requirements, the software !" inquires about the status of a security zone
engineer (analyst) can create a set of scenarios that each identify a thread of !" inquires about the status of a sensor
usage for the system to be constructed. The scenarios, often called use cases
. presses the panic button in an emergency
provide a description of how the system will be used.
To create a use case, the analyst must identify the different types of !" activates/deactivates the security system
people (or devices) that use the system or product. These actors actually rep-
resent roles that people (or devices) play as the system operates. Defined some- A use case for system activation follows:
what more formally, an actor is anything that communicates with the system
or product and that is external to the system itself. 1. The homeowner observes the control panel (Figure 11.4) to de-
It is important to note that an actor and a user are not the same thing. A termine if the system is ready for input. If the system is not ready, the
typical user may play a number of different roles when using a system, whereas homeowner must physically close windows/doors so that the ready indica-
an actor represents a class of external entities (often, but not always people) tor is present. (A not ready indicator implies that a sensor is open, i.e., that
that play just one role. As an example, consider a machine operator (a user) who a door or window is open.)
interacts with the control computer for a manufacturing cell that contains a
2 . The homeowner uses the key pad to key in a four digit password. The pass-
number of and numerically controlled machines. After careful review of
word is compared with the valid password stored in the system. If the pass-
requirements, the software for the control computer requires four different
word is incorrect, the control panel will beep once and reset itself for addi-
modes (roles) for interaction: programming mode, test mode, monitoring mode,
tional input. If the password is correct, the control panel awaits further action.
and troubleshooting mode. Therefore, four actors can be defined: programmer,
tester, monitor, and troubleshooter. In some cases, the machine operator can play 3 . The homeowner selects and keys in stay or away (see Figure 11.4) to acti-
all of these roles. In others, different people’may play the role of each actor. vate the system. Stay activates only perimeter sensors (inside motion de-
Like other aspects of the 00 analysis model, not all actors are identified tecting sensors are deactivated). Away activates all sensors.
during the first iteration. It is possible to identify primary actors dur- 4 . When activation occurs, a red alarm light can be observed by the homeowner.
ing the iteration and secondary actors as more is learned about the sys-
tem. Primary actors interact to achieve required system function and derive Use cases for other homeowner interactions would be developed in a similar
the intended benefit from the system. They work directly and frequently with manner. It is important to note that each use case must be reviewed with care.
the software. Secondary actors exist to support the system so that primary ac- If some element of the interaction is ambiguous, it is likely that a review of the
tors can do their work. use case will indicate a problem.
Once actors have been identified, use cases can be developed. The use case Each use case provides an unambiguous scenario of interaction between an
describes the manner in which an actor interacts with the system. Jacobson actor and the software. It can also be used to specify timing requirements or
suggests a number of that should be answered by the use case: other constraints for the scenario. For example, in the use case noted above, re-
quirements indicate that activation occurs 30 seconds after the stay or
!" What are the main tasks or functions that are by the actor? key is hit. This information can be appended to the use case.
!"What system information wilt the actor acquire, produce, or change? Use cases describe scenarios that will be perceived differently by different
actors. Wyder suggests that quality function deployment can
!" Will the actor have to inform the system about changes in the external en-
be used to develop a weighted priority value for each use case. To accomplish
vironment? cases are evaluated from the point of view of all actors defined for the
!"What information does the actor desire from the system? system. A priority is assigned to each use case (e.g., a value from 1 to
!"Does the actor wish to be informed about unexpected changes? by each of the An average priority is then computed, indicating the per-
ceived importance of each of the use cases. When an iterative or incremental
In general, a use case is simply a written narrative that describes the role of
an actor as interaction with the system occurs.
The security system, discussed in earlier chapters, can be used
to illustrate how use cases can be developed. Recalling basic re- is discussed briefly in Chapter 11.
quirements, we can define three actors: the homeowner (the user), sensors (de- evaluation should be performed by individuals from the organization or business
vices attached to the system), and the monitoring and response subsystem (the function represented by an
594 PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER OBJECTORIENTED ANALYSIS 595
process model is used for object-oriented software engineering, the priorities In addition, objects and classes may be categorized by a set of characteristics:
can influence which system functionality is delivered first.
Tangibility. Does the class represent a tangible thing a keyboard or
sensor), or does it represent more abstract information (e.g., a predicted
outcome)?
20.4.2 Modeling
Inclusiveness. Is the class atomic (i.e., it does not include any other
classes) or is it aggregate (it includes at least one nested object)?
Once basic usage scenarios have been for the system, it is time to
identify candidate classes, and indicate their responsibilities and collabora- Sequentiality. class (i.e., it has its own thread of con-
tions. Class-responsibility-collaborator modeling provides a trol) or is by outside resources)?
simple means for identifying and organizing the classes that are relevant to Persistence. the class transient it is created and removed during
system or product requirements. Ambler IAMB951 CRC modeling in program operation); temporary (it is created during program operation and
the following way: removed once the program terminates); orpermanent (it is stored in a data-
base)?
A CRC model is really a collection of standard index cards that represent Integrity. Is the class corruptible (i.e., it does not protect its resources
classes. The cards are divided into three sections. Along the top of the card you from outside is it guarded (the class enforces controls on ac-
write the name of the class. In the body of the card you list the class responsi- cess to its resources)?
bilities on the let? and the collaborators on the right.
Using the class noted above, the “index card” created as part of the
In reality, the CRC model may make use of actual or virtual index cards. The CRC model might be extended to include the type of class and its characteris-
intent is to develop an organized representation of classes. Responsibilities are tics (Figure
attributes and operations that are relevant for the class. Stated simply, a
responsibility is “anything the class knows or does” Collaborators are Responsibilities
those classes that are required to provide a class with the information needed
to complete a responsibility, In general, a collaboration implies either a request Basic guidelines for identifying responsibilities (attributes and operations)
for information or a request for some action. were also presented in Chapter 19. To summarize, attributes represent stable
features of a class, that is, information about the class that must be retained
Classes
Basic guidelines for identifying classes and objects were presented in Chapter
19. To summarize, objects manifest themselves in a variety of forms (Section class name:
19.3.1): external entities, things, occurrences or events, roles, organizational
units, places, or structures. One technique for identifying these in the context class type: (e.g., device, property, role, event,
of a software problem is to perform a grammatical parse on the processing nar-
class characteristics: (e.g., tangible, atomic, concurrent,
rative for the system. All nouns become potential objects. However, not every
potential object makes the cut. Six selection characteristics were in responsibilities: collaborators:
Chapter 19: retained information, needed services, multiple attributes, common
attributes, common operations, and essential requirements. A potential object I I
should satisfy all six of these selection characteristics if it is to be considered
II
for inclusion in the CRC model. I
Firesmith [FIR931 extends the taxonomy of class types noted above by sug-
gesting the following additions:
Device classes. Model external entities such as sensors, motors, and key-
boards.
Property classes. Represent some important property of the problem en-
vironment (e.g., credit rating within the context of a mortgage loan appli-
cation). FIGURE 20.3.
Interaction classes.Model interactions that occur among other objects A CRC model index
(e.g., a purchase or a license). card
596 PART FOUR: SOFTWARE ENGINEERING CHAPTER OBJECT-ORIENTED ANALYSIS 597
to accomplish the objectives of the software specified by the customer. Attributes sponsibility for storing and manipulating a specific type of information.
can often be extracted from the statement of scope or discerned from an un- This responsibility should not, in general, be shared across a number of
derstanding of the nature of the class. Operations can be extracted by per- classes. If information is distributed, software becomes more difficult to
forming a grammatical parse on the processing narrative for the system. Verbs maintain and more challenging to test.
become candidate operations. Each operation that is chosen for a class exhibits 5. Share responsibilities among related classes, when There are
a behavior of the class. many cases in which a variety of related objects must all exhibit the same
Wirfs-Brock and her colleagues suggest five guidelines for allo- behavior at the same time. As an example, consider a video game that must
cating responsibilities to classes: display the following objects: player, player-body, player-arms,
head. Each of these objects has its own attributes (e.g., position, orienta-
1. System intelligence should be evenly distributed. Every application encom- tion, color, speed), and all must be updated and displayed as the user ma-
passes a certain degree of-intelligence, i.e., what the system knows and nipulates a joy stick. The responsibilities update and display must therefore
what it can do. This intelligence can be distributed across classes in a num- be shared by each of the objects noted. Player knows when something has
ber of different ways. “Dumb” classes (those that have few responsibilities) changed and update is required. It collaborates with the other objects to
can be modeled to act as servants to a few “smart” classes (those having achieve a new position or orientation, but each object controls its own dis-
many responsibilities). Although this approach the of in play.
a system straightforward, it has a few disadvantages:
!" It concentrates all intelligence within a few classes, making changes Collaborators
more
Classes fulfill their responsibilities in one of two ways: (1) A class can use its
!" It tends to require more classes and therefore more development effort.
own operations to manipulate its own attributes, thereby fulfilling a particular
Therefore, system intelligence should be evenly distributed across the responsibility, or a class can collaborate with other classes.
classes in an application. Because each object knows about and does only Wirfs-Brock and her colleagues define collaborations in the fol-
a few things (that are generally well-focused), the cohesiveness of the sys- lowing way:
tem is improved. In addition, side effects due to change tend to be damp-
ened because system intelligence has been decoupled across many objects. Collaborations represent requests from a client to a server in fulfillment of a
To determine whether system intelligence is evenly distributed, the re- client responsibility. A collaboration is the embodiment of the contract between
sponsibilities noted on each CRC model index card should be evaluated to the client and the server. We say that an object collaborates with another
determine if any class has long list of responsibilities. object if, to fulfill a responsibility, it needs to send the other object any mes-
This indicates a concentration of intelligence. In addition, the responsibil- sages. A single collaboration flows in one direction-representing a request
ities for each class should exhibit the same level of abstraction. For exam- from the client to the server. From the client’s point of view, each of its collab-
ple, among the operations listed for an aggregate class called checking ac- orations is associated with a particular responsibility implemented by the
count are two responsibilities: balance-the-account and server.
checks. The first operation (responsibility) implies a complex mathematical
and logical procedure. The second is a simple clerical activity. Since these Collaborations identify relationships between classes. When a set of classes all
two operations are not at the same level of abstraction, collaborate to achieve some requirement, they can be organized into a subsys-
checks should be placed within the responsibilities of check-entry, a class
tem (a design issue).
that is encompassed by the aggregate class checking account. Collaborations are identified by determining whether a class can fulfill
2. Each responsibility should be stated as generally as possible. This guideline each responsibility itself. If it cannot, then it needs to interact with another
implies that general responsibilities (both attributes and operations) should class. Hence, a collaboration.
reside high in the class hierarchy (because they are generic, they will ap- As an example, consider the As part of the activa-
ply to all subclasses. In addition, polymorphism (Chapter should be tion procedure (see the use case for activation in Section the control
used in an effort to define operations that generally apply to the superclass panel object must determine whether any sensors are open. A responsibility
but are implemented differently in each of the subclasses. named determine-sensor-status is defined. If sensors are open, control panel
3. Information and the behavior that is related to it should reside within the must set a status attribute to “not ready’ Sensor information can be acquired
same class. This achieves the 00 principle that we call encapsulation from the sensor object. Therefore, the responsibility determine-sensor-status
(Chapter Data and the processes that manipulate the data should be can be fulfilled only if control panelworks in collaboration with sensor.
packaged as a cohesive unit.
4. Information about one thing should be localized within a single class, not
distributed across multiple classes. A single class should take on the re- Section 19.3 for a delineation of classes for
PART OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 20: OBJECTORIENTED ANALYSIS 599
To help in the identification of collaborators, the analyst can examine three 4. When the token is passed, the holder of the class card is asked to describe
different generic relationships between classes the the responsibilities noted on the card. The group determines whether one
tionship, the has-knowledge-of relationship, and the depends-upon rela- (or more) of the responsibilities satisfies the use case requirement.
tionship. By creating a class-relationship diagram (Section the analyst 5. If the responsibilities and collaborations noted on the index cards cannot ac-
develops the connections necessary to identify these relationships. Each of the commodate the use case, modifications are made to the cards. This may in-
three generic relations is considered briefly in the paragraphs that follow. clude the definition of new classes (and corresponding CRC index cards) or
All classes that are part of an aggregate class are connected to the aggre- the specification of new or revised responsibilities or collaborations on ex-
gate via an is-part-of the classes for the isting cards. This modus operandi continues until the use case is finished.
video game noted earlier, the class player-body is-part-of player, as are
p l a y e r - a r m s , p l a y e r - l e g s ,and p l a y e r - h e a d .
When one class must acquire information from another class, The CRC model is a first representation of the analysis model for an 00
system. It can be “tested” by conducting a review that is driven by use cases
knowledge-of relationship is established. The determine-sensor-status responsi-
derived for the system.
bility noted earlier is an example of a has-knowledge-of relationship.
The depends-upon relationship implies that two classes have a dependency
that is not achieved by has-knowledge-of or For example, player-
head must always be to player-body vidoo is par- Defining and Hierarchies
ticularly violent), yet each object could exist without direct of the
other. An attribute of the player-head object called center-position is deter-
mined from the player-body. This information
via a third object, player, which acquires it from player-body. Hence, player- lyst begins to focus on the structure of the class model and the resultant hier-
head depends-upon player-body. archies that arise as classes and subclasses emerge. Coad and
In all cases, the collaborator class name is recorded on the CRC model in- suggest that a structure should be de-
dex card next to the responsibility that has spawned the collaboration. rived for the identified classes.
Therefore, the index card contains a list of responsibilities and the corre- To illustrate, consider the sensor object defined for and shown
sponding collaborations that enable responsibilities to be fulfilled. in Figure 20.4. Here, the generalization, sensor, is refined into a set of spe-
When a complete CRC model has been developed, the representatives from cializations-entry sensor, smoke sensor, and motion We cre-
the customer and software engineering organizations can walk through the ated a simple class hierarchy.
model using the following approach
1. All participants in the review (of the CRC model) are given a subset of the
CRC model index cards. Cards that collaborate should be separated (i.e., no sensor ,
reviewer should have two cards that collaborate).
2. All use case scenarios should be organized into categories.
3. The review leader reads the use case deliberately. As the review leader
comes to a named object, she passes the token to the person holding the
corresponding class index card. For example, the use case noted in Section
20.4.1 contains the following narrative:
1. The homeowner observes the control panel (Figure 11.4) de-
termine if the is ready input. If the is the home-
owner must physically close so that the ready indicator is pres- I
ent. not ready indicator implies that a sensor is open, i.e., that a door or
window entry sensor smoke sensor motion
When the review leader comes to “control panel,” in the use case narrative, the
passed to the person holding the control panel card. The phrase “im-
plies that a sensor is open” requires that the index card contains a
bility that will validate this implication (the responsibility FIGURE 20.4.
accomplishes this). Next to the responsibility on the index card is the structure
collaborator sensor. The token is then passed to the object. notation
PART FOUR: SOFTWARE ENGINEERING CHAPTER ANALYSIS 601
that contains a set of responsibilities and that has its own (outside) collabora-
control panel tors. A subsystem implements one or more contracts with its outside collabo-
rators. A contract is a specific list of requests that collaborators can make of
the
Subsystems can be represented within the context of CRC modeling by
a subsystem index card. The subsystem index card indicates the name of
the subsystem, the contracts that the subsystem must accommodate, and the
classes or (other) subsystems that support the contract.
represents Subjects are identical to subsystems in intent and content, but are rep-
III resented graphically. For example, assume that the control panel for
a whole-part
is considerably more complex than the one implied by Figure 20.5, contain-
structure
ing multiple display areas, a sophisticated key arrangement, and other fea-
tures. It might be modeled as an whole-part structure shown in Figure 20.6.
If the overall requirements model contains dozens of these structures
would not), it would be difficult to absorb the entire representa-
tion at one time. By defining a subject reference as shown in the figure, the
entire structure can be referenced by a single icon (the rectangle). Subject ref-
keypad screen
erences are generally created for any structure that has more than live or six
objects.
At the most abstract level, the OOA model would contain only subject ref-
erences such as those illustrated at the top of Figure 20.7. Each of the refer-
FIGURE 20.5. ences would be expanded into a structure. Structures for the control panel
Whole-part structure and sensor objects (Figures 20.6 and 20.4) are illustrated; structures for aye-
notation tern, sensor event, and audible alarm would also be created if these objects
required more than or six classification or assembly objects.
The doubled-headed arrows shown in at the top of Figure 20.7 represent
In other cases, an object represented in the initial model might actually be communication (message) paths between objects contained within the subject
composed of a number of component parts that could themselves be defined as references. These are derived as a consequence of the modeling activities de-
objects. These aggregate objects can be represented as a whole-part structure scribed in the next section.
and are defined using the notation represented in Figure 20.5. The
triangle implies as assembly relationship. It should be noted that the connect-
ing lines may be augmented with additional symbols (not shown) to represent
20.5 THE MODEL
cardinality. These are adapted from the entity-relationship modeling notation
discussed in Chapter 12.
Structure representations provide the analyst with a means for partition- The CRC modeling approach that has been used in earlier sections has estab-
ing the CRC model and representing that partitioning graphically. The expan- lished the first elements of class and relationships. The step in es-
sion of each class provides needed detail for review and for subsequent design. tablishing relationships is to the responsibilities for each class. The
CRC model index card contains a list of responsibilities. The next step is to de-
fine those collaborator classes that help in achieving each responsibility. This
establishes the “connection” between classes.
20.4.4 Defining Subjects and Subsystems A exists between any two classes that are connected.”
Therefore, collaborators are always related in some way. The most common type
An analysis model for a complex application may have hundreds of classes and of relationship is binary-a connection exists between two classes. When con-
dozens of structures. For this reason, it is to a concise sidered within the context of an 00 system, a binary relationship has a
sentation that is a digest of the CRC and structure models described above.
When a subset of all classes collaborate among themselves to accomplish a
set of cohesive responsibilities, they are often referred to as subjects
or Both subjects and subsystems are abstractions that that classes interact using client/server philosophy. In this ease the subsystem is
provide a or pointer to more detail in analysis model. When and outside collaborators clients.
viewed from the outside, a subject or subsystem can be treated as a black box “Other terms for relationship “association” and “connection” ICOA911.
602 PART FOUR. OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER 20. ANALYSIS 603
control panel control panel
subject
reference audible alarm
display area lite
n
keypad
20.6.
Subject reference
that is defined by which class plays the role of the client and
which acts as a server.
and his colleagues suggest that relationships can be
derived by examining the verbs or verb phrases in the statement of scope or FIGURE 20.7. An OOA model with references
use cases for the system. Using a grammatical parse, the analyst isolates verbs
that indicate physical location or placement in), com-
munications to, acquires from),ownership (incorporated by, is
posed and satisfaction of a condition (manages, coordinates, controls). These
provide an indication of a relationship.
- - A variety of different graphical notations has been proposed for the
is important to note that this is a departure from the bidirectional nature of relationships relationship model (e.g., Although
in data modeling (Chapter makes use of its own all are adapted from the entity-relationship
604 PART FOUR: SOFTWARE ENGINEERING CHAPTER 605
By developing an object-relationship model, the analyst adds still another
contains ‘control polls
system sensor dimension to the overall analysis model. Not only are the relationships between
objects identified, but all important message paths are defined (Chapter In
our discussion of Figure 20.7, we made reference to the arrows that connect
subject symbols. These are also message paths. Each arrow implies the inter-
change of messages among subsystems in the model.
20.6 THE OBJECT-BEHAVIOR MODEL
recognizes The CRC model and the object-relationship model represent static elements of
the 00 analysis model. It is now time to make a transition to the dynamic be-
havior of the 00 system or product. To accomplish this, we must represent the
behavior of the system as a function of specific events and time.
sensor The object-behavior indicates how an 00 system will respond to
event or stimuli. To create the model, the analyst must perform the fol-
lowing steps:
1. Evaluate all use cases (Section to fully understand the sequence of
20.8. interaction within the system.
is 2. Identify events that drive the interaction sequence and understand how
defined these events relate to specific objects.
3 . Create an event trace for each use case.
4 . Build a state-transition diagram for the system.
modeling techniques discussed in Chapter 12. In essence, objects are connected
5. Review the object-behavior model accuracy and consistency.
to other objects using named relationships. The cardinality of the connection
Chapter 12) is specified, and an overall network of relationships is established.
The object-relationship model (like the entity-relationship model) can be Each of the above steps is discussed in the sections that follow.
derived three steps:
1. Using the CRC index cards, a network of collaborator objects can be drawn. 20.6.1 Event Identification with Use Cases
Figure 20.8 represents the class connections for First the
objects are drawn connected by unlabeled lines (not shown in the figure) As we noted in Section 20.4.1, the use case represents a sequence of activities
that indicate some relationship exists between the connected objects. that involve actors and the system. In general, an event occurs whenever an
2 . Reviewing the CRC model index card, responsibilities and collaborators are 00 system and an actor (recall that an actor can be a person, a device, or even
evaluated and each unlabeled connected line is named. To avoid ambiguity, an external system) exchange information. Recalling the discussion presented
an arrowhead indicates the “direction” of the relationship (Figure 20.8). in Chapter 12, it is important to note that an event is Boolean. That is, an event
is not the information that has been exchanged; it is the fact that information
3 . Once the named relationships have been established, each end is evaluated
has been exchanged.
to determine cardinality (Figure Four options exist: 0 to 1, 1 to 1, 0
A use case is examined for points of information exchange. To illustrate, re-
to many, or 1 to many, For example, the system contains a sin-
consider the use case described in Section 20.4.1:
gle control panel (the cardinality notation indicates this). At least one
sensor must be present for polling by the control panel. However, there may 1. The homeowner observes the control panel (Figure 11.4) to de-
be many sensors present (the notation indicates this). One sensor can termine if the system is ready for input. If the system is not ready, the
recognize from 0 to many sensor events (e.g., smoke is detected or a homeowner must physically close windows/doors so that the ready indica-
in has occurred). tor is present. [A not ready indicator implies that a sensor is open, i.e., that
a door or window is
The steps noted above continue until a complete object-relationship model has 2. The homeowner uses the key pad to key in a four digit password. The
been produced. word is - the valid password stored in the system. If the pass-
PART SOFTWARE ENGINEERING CHAPTER 20: OBJECT-ORIENTED ANALYSIS
word is incorrect, the control panel will once and itself for addi- control
tional input. If the password is correct, the control panel awaits further ac-
panel
tion.
3. The homeowner selects and keys in stay or (see Figure 11.4) to acti- compare password = incorrect
vate the system. Stay activates only perimeter-sensors (inside motion de-
tecting sensors are deactivated). Away activates all sensors.
4. activation occurs, a red alarm light can be observed by the home-
owner. control ‘control
The underlined portions of the use case scenario noted above indicate events. panel panel “reenter”
An actor should be identified for each event; the information that is exchanged
should be noted, and any conditions or constraints should be indicated. password compare password = incorrect
As an example of a typical event, consider the underlined use case phrase compare password = correct
homeowner uses the key pad to key in a four digit password. the context of
the 00 analysis model, the actor homeowner transmits an event to the ob- control
ject control panel.The event might be called password entered. The informa-
panel
tion transferred is the four digits that comprise the password, but this is not “at rest” “comparing”
an essential part of the behavioral model. It is important to note that some
events have an explicit impact on the flow of control of the use case, while oth-
ers have no direct impact on the of control. For example, the event pass-
word entered does not explicitly change the flow of control of the use case, but
the results of the event compare password (derived from the interaction pass-
word is compared with the valid password stored in the system) will have an
explicit impact on the information and control flow of the software. “selecting”
Once all events have been identified, they are allocated to the objects in-
volved. Actors (external entities) and objects can be responsible for generating
events (e.g., homeowner generates the password entered event) or recognizing L activation successful
events that have occurred elsewhere (e.g., control panel recognizes the binary FIGURE 20.9. A representation of active state for the objectcontrol panel
result of the compare password event).
cur to force an object to make a transition from one active state to another. One
component of an object-behavior model is a simple representation of the active
20.6.2 State Representations
states for each object and the events (triggers) that cause changes between
these active states. Figure 20.9 illustrates a simple representation of active
the context of 00 systems, two different characterizations of states must be states for the control panel object in the system.
considered: Each arrow shown in Figure 20.9 represents a transition from one active
state of an object to another. The labels shown for each arrow represent the
!" the state of each object as the system performs its function event that triggers the transition. Although the active state model provides
!" the state of the system as observed from the outside as the system performs useful insight into the “life history” of an object, it is possible to specify
its function . tional information to provide more depth in understanding the behavior of an
object. In addition to specifying the event that causes the transition to occur,
The state of an object takes on both passive and active characteristics the analysis can also specify a guard and an action A guard is a
Boolean condition that must be satisfied in order for the transition to occur. For
A passive state is simply the current status of all of an object’s at-
example, the guard for the transition from the “at rest” state to the “compar-
tributes. For example, the passive state of the aggregate object player the
ing state” in Figure 20.9 can be determined by examining the use case:
video game application discussed earlier) would include the current position
and orientationof player (object attributes) as well as an other features of
player that are relevant to the game (e.g., an attribute that indicates magic if (password input = 4 digits) then make transition to comparing state;
wishes remaining). The active state of an object indicates the current status of
the object as it undergoes a continuing transformation or process. The object In general, the guard for a transition usually depends upon the value of one or
player might have the following active states: moving, at rest, injured, being more attributes of an object. In other words, the guard depends on the passive
cured, trapped, lost, and so on. An event (sometimes called a trigger) must state of the object.
PART FOUR. SOFTWARE ENGINEERING CHAPTER OBJECTORIENTED ANALYSIS
Homeowner Control panel System selects stay/away
system enters password
system ready
ready Control
enters password Homeowner
. panel
initiates beep ready for next action
beep sounded ready for activation/deactivation
I I
ready for activation/deactivation beep sounded initiates beep
I sensors activated/deactivated activate/deactivate sensors
selects red light on red light on request
activate/deactivate sensors
!
sensors activated/deactivated System
light on request
FIGURE 20.11. A partial event flow diagram for
red light on
Once a complete event trace has been developed, all of the events that
for next action cause transitions between system objects can be collated into a set of input
events and output events (from an object) This can be represented using an
event diagram events that flow into and out of an object are
noted as shown in Figure 20.11. A state-transition diagram (Chapter can
then be developed to represent the behavior associated with responsibilities for
FIGURE 20.10. A partial event trace for each
Like the structured analysis diagrams presented in Chapter 12, graphical
representation forms the basis for the 00 analysis model and provides an ex-
An action occurs concurrently with the transition or as a consequence of it cellent foundation for the creation of a software requirements specification.
and generally involves one or more operations (responsibilities) of the object.
For example, the action connected to the password (Figure 20.9) 20.8 SUMMARY
is an operation that accesses a password object performs a digit by
comparison to validate the entered password.
Object-oriented analysis methods enable a software engineer to model a prob-
The second type of behavioral representation for OOA considers a state
lem by representing objects, attributes, and operations as the primary model-
representation for the overall product or system. This representation encom-
ing components. A wide variety of object-oriented analysis methods have been
passes a simple event trace model that indicates how events cause
proposed in the literature, but all have a set of common characteristics: rep-
transitions from object to object and a state-transition diagram that depicts the
processing behavior of each object. resentation of classes and class hierarchies, creation of object-relationship
models, and derivation of object-behavior models.
Once events have been identified for a use case, the analyst creates a rep-
Analysis for object-oriented systems occurs at many different levels of ab-
resentation of how events cause flow from one object to another. Called an
straction. At the business or enterprise level, the techniques associated with
trace, this representation is a shorthand version of the use case. It represents
OOA can be coupled with an information engineering approach. This technique
key objects and the events that cause behavior to flow from object to object.
is often called domain analysis. At an application level, the object model focuses
Figure 20.10 illustrates a partial event trace for the system. Each
on specific customer requirements as those requirements affect an application
of the arrows represents an event (derived from a use case) and indicates how
to be built.
the event channels behavior between objects. The first event, system
ready, is derived from the external environment and channels behavior to the The OOA process begins with the definition of use cases-scenarios that
describe how the 00 system is to be used. The
homeowner. The homeowner enters a password. The events initiates and
how brhnvior ix A
in to und
traces follow ix
610 PART SOFTWARE ENGINEERING CHAPTER 20 ANALYSIS 611
tot (CRC) modeling technique is then applied to document classes and their at- Rambaugh, J. et al., Object-Oriented Modeling and Resign, Prentice-
tributes and operations. It also provides an initial view of the collaborations Hall, 1991.
that occur among objects. The next step in the OOA process is classification of K.S., and A. Goldberg, “Object Behavior Analysis,” Communi-
objects and the creation of a class hierarchy. Subsystems (subjects) can be used cations of the ACM, vol. 35, no. 9, September 1992, pp. 48-62.
to encapsulate related objects. The object-relationship model provides an indi- Sullo, G.C., Object Engineering, Wiley, 1994.
cation of how classes are connected to one another, and the object-behavior Taylor, D.A., Business Engineering with Object Wiley, 1995.
model indicates the behavior of individual objects and the overall behavior of R., B. and L. Weiner, Designing Object-Oriented
the 00 system. Software. Prentice-Hall, 1990.
Wyder, “Capturing Requirements with Use Cases,”
February 1996, pp.
REFERENCES
PROBLEMS AND POINTS TO PONDER
Ambler, S., “Using Use Cases,” Software Deuelopment, July 1995, pp.
53-61. 20.1. Select five object-oriented analysis methods and structured analysis (Chapter
Arango, G., and R. Concepts and Research and compare them using the modeling dimensions proposed by Fichman
Directions,” in Domain Analysis: Acquisition of Reusable Information for and Kemerer in Section
Software Construction, G. Arango and R. Prieto-Diaz IEEE Develop a classroom presentation on one of the OOA methods discussed in
Computer Society Press, 1959. Section Present the method in the context of a simple example.
Berard, E.V., A Comparison of Object-Oriented Development Methodolo- areas where a unique notation or approach is used.
gies, Berard Engineering, Inc., Gaithersburg, MD, 1992. 20.3. Conduct an abbreviated domain analysis for one of the following areas:
Berard, Essays on Object-Oriented Software Engineering, a. a university student record-keeping system
Wesley, 1993. b. an on-line service
G., Object-Oriented Analysis and Design, 2nd edition, Benjamin c. customer service for a bank
Cummings, 1994. d. a video game developer
G., and J. Rambaugh, Unified Method for Object-Oriented e. an application area suggested by your instructor
Deuelopment, Rational Software Corp., 1996. Be sure to isolate classes that can be applied across a number of applica-
de D., D. Lea, and P. Object-Oriented System tions in the domain.
Deuelopment, Addison-Wesley, 1993. 20.4. In your own words describe the difference between static and dynamic views
Coad, I?, and E. Object-Oriented Analysis, 2nd edition, Prentice- of an 00 system.
Hall, 1991. 20.5. Write use cases for the system discussed in this book.
Due, R., “Enterprise Modeling: Still in Pursuit,” Database Programming
cases should address the scenario required to define a security zone. A se-
and November 1992, pp. 62-65.
curity zone encompasses a set of sensors that can addressed, activated,
D.W., B.D. and S.N. Object-Oriented Systems
and deactivated as set, rather than individually, As many as 10 security
Analysis, Press, 1992.
zones can be defined. Be creative here, but stay within the bounds of the con-
Fichman, R.G., and C.F. Kemerer, “Object-Oriented and Conventional trol panel as it is defined earlier in the book.
Analysis and Design Methodologies,” Computer, vol. 25, no. 10, October
1992, pp. 22-39. 26.6. Develop a set of use cases for the PHTRS system introduced in problem
Firesmith, D.G., Object-Oriented Requirements Analysis and Logical 12.13. You’ll have to make a number of assumptions about the manner in
Design, Wiley, 1993. which a user interacts with this system.
Graham, I., Object-Oriented Methods, Addison-Wesley, 1994. 20.7. Develop a set of use cases listed in Table 20.1. or for a system or product
Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley, suggested by your instructor. Do a few hours of research on the application
1992. area and conduct a FAST meeting (Chapter with your fellow students to
Succeeding with the and OMT Methods, Lockheed-Martin and develop basic requirements (your instructor will help you coordinate this).
Rational Software Corporation, Addison-Wesley, 1996. 20.8. Develop a complete set of CRC model index cards for the product or system
Mattison, R., The Object-Oriented Enterprise, McGraw-Hill, 1994. you chose as part of problem 20.7.
Monarchi, D.E., and G.I. Pubr, “A Research for Object-Oriented 20.8. Conduct a review of the CRC index cards developed in problem 20.8 with
Analysis and Design,” Communications of the ACM, vol. 35, no. 9, your colleagues. How many additional classes, responsibilities, and
September 1992, pp. 3.547. were added as a consequence of the review?
612 FOUR: SOFTWARE CHAPTER 613
Worthwhile discussions of 00 techniques for prototyping are presented by
and Shafer Prentice-Hall, 1994)
SUGGESTED APPLICATION FOR PROBLEMS 20.7 THROUGH 20 12 and (Using Object Oriented Languages for Rapid Prototyping,
Hall,
The same Internet sources noted for Chapter 19 are equally applicable for
The PHTRS application introduced in problem 12.13 OOA. The Internet newsgroup is a useful source for information,
Software for a computer-based word-processing system discussion, and debate on OOA methods and tools. The FAQ for this
Real-time test monitoring system for gas turbine engines
contains a brief summary of OOA methods and points to additional references.
It can he found at:
for 0 manufacturing control system
Software for o video game of your choosing
A spreadsheet
A PC-based 3D graphics package Discussion of OOA issues can sometimes he found in comp.software-eng and
A system suggested by your instructor A Comparison of Object-Oriented Development Method-
ologies by Edward is available. Select “on-line documents” at:
20.10. Develop a class hierarchy for the product or system you chose as part of
20.7.
20.11. Develop a set of subsystems for the product or system you chose as part of Additional information on OOA and object technologies in general can be
problem 20.7. obtained at:
20.12. Develop an object-relationship model for the product or system you chose as
part of problem 20.7.
20.13. Develop an object-behavior model for the product or system you chose as
part of problem 20.7. Be sure to list all events, provide an event trace, de- Many references to OOA papers and books can he obtained at:
velop an event flow diagram, and define a state diagram for each class.
20.14. In your own words, describe how collaborators for a class are determined.
20.15. What strategy would you propose for defining subsystems for a collection of
classes? An up-to-date list of World Wide Web references for object-oriented analy-
20.16. What role does cardinality play in the development of an object-relationship sis can be found at:
model?
20.17. What is the difference between an active and a passive state for an object?
FURTHER READINGS AND OTHER INFORMATION SOURCES
Dozens of books address object-oriented analysis. Before selecting one, the
reader should select an OOA method that appears to serve local needs and then
select a book that describes the appropriate method. An excellent survey of
available methods is presented in and
Detailed discussions of OOA may be found in
nnd In addition, bookn by
and World in Slates,
Prentice-Hall, Martin and (Object-Oriented Analysis and Design,
Prentice-Hall, Goldstein and (Developing Object-Oriented Software
the Macintosh, Addison-Wesley, and (Object-Oriented
Prentice-Hall, 1993) contain useful discussion. and Argila
(Case Studies in Object-Oriented Analysis and Design, Prentice-Hall, 1995) pre-
sent two realistic case studies that illustrate the OOA process in detail.
CHAPTER 2 : DESIGN 615
design is difficult if not impossible to get “right” the first time. Before a design
is finished, they usually try to reuse it several times, modifying it each time.
Object-oriented design, object-oriented programming, and object-oriented
testing are the construction activities for 00 systems. In this chapter, we con-
OBJECT-ORIENTED
sider the first step in construction.
DESIGN
21.1 DESIGN FOR OBJECT-ORIENTED SYSTEMS
In Chapter 13 we introduced the concept of the design pyramid for conven-
tional software. Four design layers-data, architectural, interface, and proce-
dural-were each defined and discussed. For object-oriented systems, we
also define a design pyramid, but the layers are a bit different. As shown in
Figure 21.1, the four layers of the 00 design pyramid are:
The subsystem layer. Contains a representation of each of the subsys-
tems that enable the software to its customer defined requirements
and to implement the technical infrastructure that supports customer re-
quirements.
The class and object layer. Contains the class hierarchies that enable the
system to be created using generalizations and increasingly more targeted
0 design transforms the analysis model created using
object-oriented analysis (Chapter into a design model that serves as
a blueprint for software construction. Unlike conventional software design
specializations. This layer also contains design representations of each object.
The message layer. Contains the details that enable each object to com-
municate with its collaborators. This layer establishes the external and in-
methods, OOD results in a design that achieves a number of different levels of ternal interfaces for the system.
modularity. Major system components are organized into system-level “mod-
ules” called subsystems. Data and the operations that manipulate the data are
encapsulated into objects-a modular form that is the building block of an 00
system. In addition, OOD must describe the specific data organization of at-
tributes and detail of individual operations. These represent
data and algorithmic pieces of an 00 system and are a contributor to overall responsibilities
modularity.
The unique nature of object-oriented design lies in its ability to build upon
four software design concepts: abstraction, information hiding, func-
tional independence, and modularity (Chapter All design methods strive
for software that exhibits these fundamental characteristics, but only OOD pro-
vides a mechanism that enables the designer to achieve all four with less com-
plexity and compromise.
The job of the software designer can bc daunting. Gamma and his
colleagues provide a reasonably accurate picture of OOD when they state:
..
Designing object-oriented software is hard, and designing reusable object-ori-
ented software is even harder. You must pertinent objects, factor them into
classes at the right granularity, define class interfaces and inheritance hierar-
chies, and establish key relationships among them. Your design should be spe-
FIGURE 21.1.
cific to the problem at hand but also general enough to address future problems
and requirements. You also want to avoid redesign, or at least minimize it. The 00 design
Experienced object-oriented designers will tell you that a reusable and flexible
614
616 PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 2 : OBJECTORIENTED DESIGN 617
The responsibilities layer. Contains the data structure and algorithmic
design for all’attributes and operations for each object.
The design pyramid focuses exclusively on the design of a specific product or
system. It should be noted, however, that another “layer” of design exists, and
this layer forms the foundation on which the pyramid rests. The foundation
layer focuses on the design of domain objects (called design patterns later in
this chapter). Domain objects play a key role in building the infrastructure for
the 00 system by providing support for human-computer interface activities,
task management, and data management. Domain objects can also be used to
flesh out the design of the application itself.
2 1.1.1 Conventional vs. 00 Approaches
Conventional approaches to software design apply a distinct notation and set of
heuristics to map the analysis model into a design model. Recall Figure 13.1.
Each element of the conventional analysis model maps into one or more layers
of the design model. Like conventional software design, OOD applies data de-
sign (when attributes are represented), interface design (when a messaging
model is developed), and procedural design (in the design of operations). However,
architectural design is different. Unlike the architectural designs derived using The analysis model The design model
conventional software engineering methods, an 00 design does not exhibit a hi-
erarchical control structure.’ In fact, the “architecture” of an 00 design has FIGURE21.2. Translating the 00 analysis model into cm 00 design model
more to do with the collaborations among objects that with the flow of control.
Although similarity between the conventional and 00 design models does
exist, we have chosen to rename the layers of the design pyramid to reflect
more accurately the nature of an 00 design. Figure 21.2 illustrates the rela- 3. specification of procedural logic
tionship between the 00 analysis model (Chapter 20) and the design model 4. indication of end-to-end processing sequences
that will be derived from 5. representation of object states and transitions
The subsystem design is derived by considering overall customer require-
ments (represented with use cases) and the events and states that are exter- 6. definition of classes and hierarchies
nally observable (the object-behavior model). Class and object design is mapped 7. assignment of operations to classes
from the description of attributes, operations, and collaborations contained in 8. detailed definition of operations .
the CRC model. Message design is driven by the object-relationship model, and
9. specification of message connections
responsibilities design is derived using the attributes, operations, and collabo-
rations described in the CRC model. 10. identification of exclusive services
Fichman and Kemerer suggest 10 design modeling components
that may be used to compare various conventional and object-oriented design Because many conventional and object-oriented design approaches are avail-
methods: able, it is difficult to develop a generalized comparison between the two meth-
ods. It can be stated, however, that modeling dimensions 5 through 10 are not
supported using or its derivatives.
21.1.2 Design Issues
the discussion of factored control presented in Chapter 13.
important to that the is not For further Bertrand Meyer suggests five criteria for judging a design method’s
ability to modularity nnd relatesthese to object-oriented design:
618 PART FOUR: OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER OBJECTORIENTED DESIGN 619
!" decomposability-the facility with which a design method helps the designer spawns a set of design representations and a notation that enables the soft-
to decompose a large problem into subproblems that are easier to solve; ware engineer to create the design model in a consistent manner. In the para-
!" degree to which a design method ensures that program graphs that follow, corresponding OOD are presented in outline form.
components (modules), once designed and built, can be reused to The intent is to provide a snapshot of the OOD process that has been proposed
systems; by the of the
!" understandability-the ease with which a program component can be un-
derstood reference to other or other modules; The Method As we noted in Chapter 20, the method en-
compasses both a “micro-development process” and a “macro-development
!" continuity-the ability to make small changes in a program and have these
process.” The micro level defines a set of design tasks that are re-applied for
changes manifest themselves with corresponding changes in just one or a
each step in the macro process. Hence, an evolutionary approach is maintained.
very few modules; and
A brief outline of OOD micro-development process follows:
!" protection-an architectural characteristic that will reduce the propagation
of side affects if an error does occur in a given module. planning:
!" Cluster similar objects in separate architectural partitions.
From these criteria, Meyer suggests live basic design principles that
can be derived for modular architectures: linguistic modular units; few !" Layer objects by level of abstraction.
interfaces; small interfaces (weak coupling); (4) explicit interfaces; and !" Identify relevant scenarios.
information hiding. !" Create a design prototype.
Modules are defined as units when they “correspond to
syntactic units in the language used” That is, the programming lan- !" Validate the design prototype by applying it to usage scenarios.
guage to be used should be capable of supporting the modularity defined di-
rectly. For example, if the designer creates a subroutine, even the classical pro- Tactical
gramming languages (e.g., C, Pascal) could implement it as a syntactic !" Define domain-independent policies the “rules” that govern the use of
unit. But if a package that contains data structures and procedures and operations and attributes).
titles them as a single unit were defined, a language such as Ada (or other ob- !" Define domain-specific policies for memory management, error handling, and
ject-oriented languages) would be necessary to directly represent this type of other infrastructure functions.
module in the language syntax.
To achieve low coupling (a design concept introduced in Chapter the . Develop a scenario that describes the semantics of the policy.
number of interfaces between modules should be minimized (few interfaces) !" Create a prototype for each policy.
and the amount of information that moves across an interface should be min- !" Instrument and refine the prototype.
imized (small interfaces). Whenever modules do communicate, they should do . Review each policy to ensure that it “broadcasts its architectural vision”
so in an obvious and direct way (explicit interfaces). For example, if module X
and module Y communicate through a global data area (what we have called
common coupling in Chapter they violate the principle of explicit interfaces
Release
because the communication between the modules is not obvious to an outside
observer. Finally, we achieve the principle of information hiding when all in- \ !" Organize scenarios developed during OOA by priority,
formation about a module is hidden from outside unless that !"Allocate corresponding architectural releases to the scenarios.
tion is specifically defined as “public information.” !" Design and construct each architectural release incrementally,
The design criteria and principles presented in this section can be applied
!" Adjust goals and schedulepf incremental release as required.
to any design method (e.g., we can apply them to structured design). As we will
see, however, the object-oriented design method achieves each of the criteria
more efficiently than other approaches and results in modular architectures The Cood ond M e t h o d The Cord and method for OOD
that allow us to meet each of the modularity criteria most effectively. was developed by studying how “effective object-oriented designers” do their de-
sign work. The design approach addresses not only the application but also the
31.1.3 OOD landscape
general, OOD methods are identified the of the developer of the method,
even if the method has been given unique name or acronym.
A snapshot of a number of popular OOA methods was presented in Chapter 20. meaning of many of the steps outlined in the process descriptions that follow be
Each of the methods presented has a corresponding process for OOD that in 21.3 and 21.4.
620 621
PART FOUR: OBJECTORIENTED SOFTWARE CHAPTER 2 I : DESIGN
infrastructure for the application. A brief outline of Coad and Yourdon’s OOD Define a block to implement related analysis objects.
process follows: Identify interface blocks, entity blocks, and control blocks.
Describe how blocks communicate during execution.
Problem domain component:
Identify stimuli that are passed between blocks and their order of com-
!"Group all domain specific classes. munication
!" Design an appropriate class hierarchy for the application classes.
!" Work to simplify inheritance, when appropriate. !"Create an interaction diagram that shows how stimuli are passed between
!"Refine design to improve performance. blocks.
!" Develop an interface with the data management component. !" Organize blocks into subsystems.
!" Refine and add low-level objects as required. !" Review the design work.
!" Review design and challenge any additions to the analysis model.
The Rambaugh The Object Modeling Technique en-
Human interaction component: compasses a design activity that encourages design to be conducted at two dif-
!" Define the human actors. ferent levels of abstraction. System design focuses on the layout for the com-
ponents that are needed to construct a complete product or system. Object
!" Develop task scenarios. design emphasizes the detailed layout of an individual object. A brief outline of
!" Design a hierarchy of user commands. Rambaugh’s OOD process follows:
!"Refine the user interaction sequence.
!" Design relevant classes and class hierarchy. !" Perform system design
!" Integrate GUI classes as appropriate. Partition the analysis model into subsystems.
Identify concurrency that is dictated by the problem.
Task management component: Allocate subsystems to processors and tasks.
!" Identify types of tasks (e.g., event driven, clock driven). Choose a basic strategy for implementing data-management.
!" Establish priorities. Identify global resources and the control mechanisms required to access
!" Identify a task to serve as for other tasks. them.
!" Design appropriate objects for each task. Design an appropriate control mechanism for the system.
Consider how boundary conditions should be handled.
Data management component Review and consider trade-offs.
!" Design the data structures and layout,
!" Design services required to manage the data structures. !" Conduct object design
!" Identify tools that can assist in implementing data management. Select operations from the analysis model.
!" Design appropriate classes and class hierarchy. Define algorithms for each operation.
Select data structures that are appropriate for algorithms.
The Jacobson MethodThe design activity for OOSE (object-oriented software
Define any internal classes.
engineering) is a simplified version of the proprietary
method, also developed by Jacobson. The design emphasizes traceability Revise class organization to optimize access to data and improve com-
to the analysis model. A brief of process follows: putational efficiency.
Design class attributes.
!" Consider adaptations to make the idealized analysis model fit the real world
environment. !" Implement control defined in system design.
!" Adjust class structure to strengthen inheritance.
!" Design messaging to implement the object relationships (associations).
“A block is the abstraction for the representation of aggregate object. !" Package classes and associations into modules.
PART FOUR. SOFTWARE ENGINEERING CHAPTER 2 OBJECTORIENTED DESIGN
As we noted in Chapter 20, work is underway to merge the and Rambaugh
methods
1
The Wirfs-Brock defines a continuum of technical
tasks in which analysis leads seamlessly into design. A brief outline of
object
design-related tasks follows:
design
!" Construct protocols for each
Reline contracts between objects into refined protocols.
Design each operation (responsibility).
Design each protocol (interface design).
!" Create a design specification for each class.
Describe each contract in detail.
Define private responsibilities.
Specify algorithms for each operation.
Note special considerations and constraints.
FIGURE 2 1.3.
!" Create a design specification for each subsystem. Process flow for
OOD
Identify all encapsulated classes.
Describe contracts in detail for which the subsystem is a server.
Note special considerations and constraints. !" Review the design model and iterate as required.
Although the terminology and process for each of OOD dif- It is important lo note that the design steps discussed in this section are iter-
fer, the overall OOD processes are reasonably consistent. To perform object-ori- ative. That is, they may be executed incrementally, along with addition OOA
ented design, a software engineer should perform the following generic steps: activities, until a completed design is produced.
!" Describe each of the subsystems in a manner that is implementable.
Allocate subsystems to processors and tasks.
21.2 THE GENERIC COMPONENTS OF THE 00 DESIGN MODEL
Choose a design strategy for implementing data management, interface
support, and task management.
It is sometimes difficult to make a clear distinction between object-oriented analy-
Design an appropriate control mechanism for the system.
sis (Chapter and object oriented In essence, object-oriented analysis
Review and consider trade-offs. is a classification activity. That is, a problem is analyzed in an effort de-
termine the classes of objects that will be applicable as a solution is developed.
!" Object design: Analysis also determines object relationships and behavior. Object-oriented design
Design each operation at a procedural level, enables a software engineer to indicate the objects that are derived
each class and how these objects interrelate with one another. In addition, OOD
Defme any internal classes.
depicts how the relationships among objects are achieved, how behavior is to be
Design internal data structures for class attributes. implemented, and how communication is to be implemented between objects.’
The generic process flow from analysis to design is illustrated in
!" Message design:’ 21.3. Once a reasonably complete analysis model has been the
Using collaborations between objects and object-relationships, design
the messaging model.
‘Readers who not yet read Chapter 20 in ite entirety are urged do
that OOA is an iterative activity. It is entirely possible that the analysis will
protocol is a formal description of the messages a class will respond. revised as a consequence of design work.
624 PART FOUR: SOFTWARE ENGINEERING
625
CHAPTER OBJECTORIENTED DESIGN
ware engineer concentrates on the design of the system. This is accomplished
by describing characteristics of the subsystems required to implement both Analysis Model Design Model
tomer requirements and the support environment that is necessary for their
realization. classes objects
As subsystems are defined, they must be coordinated within the overall attribute8 data structures
context of customer requirements. Which subsystems are responsible for which methods algorithms
customer requirements? Within which subsystems do objects reside that were relationships messaging
defined during OOA? Wh‘ h b ems must operate concurrently and what
t FIGURE21.4.
behavior -*control
system components coordinate and control them? How are global resource8 Translating
managed by the subsystems? analysis model into
During subsystem design, it is the engineer to de- a design model
object design
fine four important design components
!" problem domain-the subsystems that are responsible for implementing cus-
tomer requirements directly; !" Design an appropriate control mechanism for the system.
!" human interaction-the subsystems that implement the user interface (this !" Consider how boundary condition8 should be handled.
included reusable GUI subsystems); !" Review and consider trade-offs.
!" tusk management-the subsystems that are responsible for controlling and
coordinating concurrent tasks that may be packaged within a subsystem or In the sections that follow, design activities that are related to each of these
among different subsystems; and steps are considered in more detail.
!" management-the subsystem that is responsible for and re-
trieval of objects.
Each of these generic components may be modeled (during with a series 213.1 Partitioning the Analysis
of classes as well as requisite relationships and behaviors. In addition, the de-
sign component8 are implemented by defining the protocol that for- of the fundamental analysis principles (Chapter is partitioning. In 00
mally describes the messaging model for each of the components. system design we partition the analysis model to define cohesive collections of
Once a subsystem has been defined and the design of each of the compo- classes, relationships, and behavior. These design element8 are packaged as a
nents noted above begins, the emphasis shifts to object design. At this level, the subsystem.
elements of the CRC model (Chapter are translated into a design realiza- In general, all of the elements of a subsystem share some property in com-
tion. In essence the translation illustrated in Figure 21.4 is accomplished. mon. They may all be involved in accomplishing the same function; they may
reside within the product hardware; or they may manage the same class
of resources. Subsystems are characterized by their responsibilities; that is, a
subsystem can be identified by the services that it provides When
21.3 THE SYSTEM DESIGN PROCESS used in the 00 system design context, a service is a collection of operations that
perform a specific function (e.g., managing word-processor files, producing a
three-dimensional rendering, translating an analog video signal into a com-
Although a number of authors suggest process models for 00 system design pressed digital image).
the sequence of activities proposed by Rambaugh and his colleagues As subsystems are defined (and designed), they should conform to the fol-
is one of the more definitive treatments of the subject. In the outline presented
lowing design criteria:
in Section 21.1.3, the following design steps were defined:
!" subsystem should have a well-defined interface through which all com-
Partition the analysis model into subsystems.
munication with the rest of the system occurs.
!" Identify concurrency that is dictated by the problem.
!" With the exception of a small number of “communication classes,” the classes
!" Allocate subsystems to processors and tasks. a subsystem should collaborate only with other classes within the sub-
!" Choose a basic strategy for implementing data management. system.
!" Identify global resources and the control mechanism8 required to !" The number of subsystems should be kept small.
!" Subsystems can be partitioned internally to help reduce complexity.
CHAPTER DESIGN
626 PART FOUR OBJECTORIENTED SOFTWARE ENGINEERING 627
!" The characteristics of the task are determined.
When two subsystems communicate with one another, they can establish a
client/server link or a peer-to-peer link In a link, each !" A coordinator task and associated objects are defined.
of the subsystems takes on one of the roles implied by client and server. Service !" The coordinator and other tasks are integrated.
flows from server to client in only one direction. In a services
may flow in either direction. The characteristics of a task are determined by understanding how the task is
The communication and information flow implied by the links described initiated. Event driven and clock driven tasks are the most commonly encoun-
above can be represented using a data diagram (Chapter In this case, tered. Both are activated by an interrupt, but the former receives an interrupt
each “bubble” in the DFD is a subsystem. from some source another processor, a sensor) whereas the latter
is governed by a system clock.
In addition to the manner in which a task is initiated, the priority and crit-
icality of the task must also be determined. High-priority tasks must have im-
213.2 Concurrency and Subsystem Allocation mediate access to system resources. High-criticality tasks must continue to on-
if is reduced or the system is operating in a
degraded state.
The dynamic aspects of the object-behavior model provide an indication of con-
currency among objects (or subsystems). If objects (or subsystems) are not ac- Once the characteristics of the task have been determined, object attri-
butes and operations required to achieve coordination and communication with
tive at the same time, there is no need for concurrent processing. This means
that the objects (or subsystems) can be implemented on the same processor other tasks are defined. The basic task template (for a task object) takes the
form
hardware. On the other hand, if objects (or subsystems) must act on events
asynchronously and at the same time, they are viewed as concurrent. When
subsystems are concurrent, two allocation options exist: Tusk name-the name of the object
Description-a narrative describing the purpose of the object
!" Allocate each subsystem to an independent processor. priority (e.g., low, medium, high)
Allocate the subsystems to the same processor and provide concurrency sup- list of operations that are object responsibilities ,
!"
port through operating system features. Coordinates by-the manner in which object behavior is invoked
Communicates G-input and output data values relevant to the task
Concurrent tasks are defined by examining the state diagram for
each object. If the flow of events and transitions indicates that only a single ob-
ject is active at any one time, a has been established. The This template description can then be translated into the standard design!
thread of control continues even when one object sends a message to another model (incorporating a representation of attributes and operations) for the task
object, as long as the object waits for a response. If, however, the ob- object(s).
ject continues processing after sending a message, the thread of control splits.
Tasks in an 00 system are designed by isolating threads of control. For ex-
ample, while the security system is monitoring its sensors, it can The Data Management Comwnent
also be dialing the central monitoring station for verification of connection.
Since the objects involved in both of these behaviors are active at the same Data management encompasses two distinct areas of concern: the manage-
time, each represents a separate thread of control and each can be defined as ment of data that are critical to the application itself, and the creation of
a separate task. If the monitoring and dialing activities occur sequentially, a an infrastructure for storage and retrieval of objects. In general, data manage-
single task could be implemented. ment is designed in a layered fashion. The idea is to isolate the low-level re-
To determine which of the processor allocation options noted above is ap- quirements for manipulating data structures from the higher-level require-
propriate, the designer must consider performance requirements, costs, and the ments for handling system attributes.
overhead imposed by interprocessor communication. Within the system context, a database management system is used as
a common data store for all subsystems. The objects required to manipulate that
database are members of reusable classes that are identified using domain
analysis (Chapter or are supplied directly by the database vendor. A detailed
The Management Component discussion of database design for 00 systems is beyond the scone of this
Coad and suggest the following strategy for the design of the
objects that manage concurrent tasks: readers should refer to or
629
PART FOUR: SOFTWARE ENGINEERING CHAPTER 21: OBJECT-ORIENTED DESIGN
The design of the data management component includes the design of the 21 Communication
attributes and operations required manage objects. The relevant are
appended to every object in the problem domain and provide information that Once each subsystem has been specified, it is necessary to define the collabo-
answers the question: How do I store myself! Coad and sug- rations that exist between the subsystems. The model that we use for
gest the creation of an object-serverclass “with services to (a) tell each object to-object collaboration can be extended to subsystems as a whole. Figure 21.5
to save itself and retrieve stored objects for use by other design components.” provides a schematic representation of collaboration. As we noted earlier in this
As an example of data management for the sensor object discussed as part chapter, communication can occur by establishing a link or a peer-
of the security system, the design could specify a flat called to-peer link. As the figure shows, we must specify the contract that exists be-
Each field would correspond to a named instance of sensor and would con- tween subsystems. Recall that a contract provides an indication of the ways in
tain the values of each sensor attribute for that named instance. Operations which one subsystem can interact with another.
within the object-serverclass would enable a specific object to be stored and , The following design steps can be applied to specify a contract for a sub-
retrieved when it is needed by the system. For more complex objects, it might system
be necessary to specify a relational database or an object-oriented database to
accomplish the same function.
1. List each request that can be made by collaborators of the subsystem.
Organize the requests by subsystem and define them within one or more
appropriate contracts. Be sure to note contracts that are inherited from su-
2 The Resource Management Component perclasses.
2 . For each contract, note the operations (both inherited and private) that are
A variety of different resources are available to an 00 system or product, and required to implement the responsibilities implied by the contract. Be sure
in many instances, subsystems compete for these resources at the same time. to associate the operations with specific classes that reside within a sub-
Global system resources can be external entities (e.g., a disk drive, processor, system.
or communication line) or abstractions (e.g., a database, an object). Regardless 3 . Considering one contract at a time, a table of the form shown in
of the nature of the resource, the software engineer should design a control Figure 21.6. For each contract, the following entries are made in the table:
mechanism for it. Rambaugh colleagues suggest that each re-
source should be owned by a “guardian object.” The guardian object is the gate- type of contract (i.e., or peer-to-peer)
keeper for the resource, controlling access to it and moderating conflicting re-
Collaborators-the names of the subsystems that are parties to the con-
quests for it. tract
Class-the names of the classes (contained within a subsystem) that
support services implied by the contract
21.3.6 The Human-Computer Interface Component Operation-the names of the operations (within the class) that imple-
ment the services
Although the human-computer interface component is implemented
within the context of the problem domain, the interface itself represents a crit-
ically important subsystem for most modern applications. The 00 analysis
model (Chapter contains usage scenarios (called use cases) and a descrip-
tion of the roles that users (called actors) play as they interact with the sys-
tem. These serve as input to the HCI design process.
Once the actor and his usage scenario are defined, a command hierarchy
is identified. The command hierarchy defines the major system menu cate-
gories (the menu bar or tool palette) and all subfunctions that are available
within the context of a major system menu category (the menu windows). The
command hierarchy is refined iteratively until every use case can be imple-
mented by navigating the hierarchy of functions.
Because a wide variety of HCI development environments already exist
or Windows), the design of GUI elements is not necessary. Reusable
classes (with appropriate attributes and operations) already exist for windows FIGURE 21.5.
icons, mouse operations, and a wide variety of other interaction functions. The A model of
implementer need only instantiate objects that have appropriate characteris- ration between
tics for the problem domain.
630 PART FOUR. OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER 2 1: DESIGN 631
21.4 THE OBJECT DESIGN PROCESS
Contract Type Collaborators Operation(s) Message Format
To borrow from a metaphor that was introduced earlier in this book, the 00
system design might he viewed as the plan of a house. The floor plan spec-
ifies the purpose of each room and the mechanisms that connect the rooms to
one another and to the outside environment. It is now time to provide the de-
tails that are required to build each room.
In the context of OOD, design focuses on the “rooms.” We must de-
velop a detailed design of the attributes and operations that comprise each
class, and a thorough specification of the messages that connect the class with
their collaborators.
2 1.4.1 Object Descriptions
FIGURE 21.6. Subsystem A design description of an object instance of a class or subclass) can take
one of two forms
message required to implement the 1. a protocol that establishes the interface of an object by defining
action between collaborators. each message that the object can receive and the related operation that the
object performs when it receives the message, and
An appropriate message description is drafted for each interaction between 2. an implementation description that shows implementation details for each
the subsystems. operation implied by a message that is passed to an object. Implementation
4. If the modes of interaction between subsystems are complex, a details include information about the object’s private part, that is, internal
collaboration graph, illustrated in Figure 21.7, is created. The collaboration details about the data structures that describe the object’s attributes and
graph is similar in form to the event flow diagram discussed in Chapter 20. procedural details that describe operations.
subsystem is along with its with other
systems. contracts that are invoked during an interaction arc noted as The protocol description is nothing more than a set of messages and a cor-
shown. The details of the interaction are determined by looking up the con- responding comment for each message. For example, a portion of the protocol
tract in the subsystem collaboration table (Figure 21.6). description for the object motion sensor(described earlier) might be:
MESSAGE (motion sensor) read: RETURNS sensor ID, sensor status;
which describes the message required to read the sensor. Similarly,
MESSAGE (motion sensor) set: SENDS sensor ID, sensor status;
sets or resets the status of the sensor.
request for system status request for alarm notification For a large system with many messages, it is often possible to create mes-
specification of type of alarm sage categories. For example, message categories for the system ob-
periodic status check configuration update ject might include system configuration messages, monitoring messages, event
messages, and so forth.
An implementation description of an object provides the internal (“hidden”)
\ details that are required for implementation but are not necessary for invoca-
FIGURE 21.7. tion, That is, the designer of the object must provide an implementation de-
communication
Abbreviated scription and must therefore create the internal details of the object. However,
another designer or implementer who uses the object or an other instance of
graph for
632 PART FOUR: OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER 2 : OBJECT-ORIENTED DESIGN 633
the object requires only the protocol description but not the implementation de- !" that an assign operation is relevant for the sensor object;
scription. . that a program operation will be applied to the system object; and
An implementation description is composed of the following information:
!" that arm and disarm are operations that apply to system (also that system
a specification of the object’s name and reference to class; a specification
of private data structures with indication of data items and types; a proce- status may ultimately be defined (using data dictionary notation) as
dural description of each operation or alternatively, pointers to such procedural
descriptions. The implementation description must contain informa- system status = [armed disarmed1
tion to provide for proper handling of all messages described in the protocol de-
scription. The operation program is allocated during OOA, but during object design it will
Cox characterizes the difference between the information con- be refined into a number of more specific operations that are required to con-
tained in the protocol description and that contained in the implementation de- figure the system. For example, after discussions with product engineering, the
scription in terms of “users” and “suppliers” of services. A user of the “service” analyst, and possibly the marketing department, the designer might elaborate
provided by an object must be familiar with the protocol for invoking the ser- the original processing narrative and write the following for program:”
vice, that is, for specifying is supplier of the service (the ob-
ject itself) must be concerned with the service is to be supplied to the user, enables the user to configure the system once it has been
that is, with implementation details. This is the objective of encapsulation, a installed. The user can install phone numbers; (2) define delay times for
concept introduced in Chapter 19. alarms; build- a sensor table that contains each its type, and its
-
location; load a password.
Therefore, the designer has refined the single operation program and re-
21.4.2 Designing Algorithms and Data Structures placed it with the operations install, define, build, and load. Each of these new
operations becomes part of the system object, has knowledge of the internal
A variety of representations contained in the analysis model and system data structures that implement the object’s attributes, and is invoked by send-
design provide a specification for all operations and attributes. Algorithms and ing the object messages of the form:
data structures are designed using an approach that differs little from the data
design and procedural design approaches discussed for conventional software
MESSAGE (system) install: SENDS telephone number;
An algorithm is created to implement the specification for each operation.
In many cases, the algorithm is a simple computational or procedural sequence which implies that to provide the system with an emergency phone number, an
that can be implemented as a self-contained software module. However, if the install message will be sent to system.
specification of the operation is complex, it may be necessary to modularize the Verbs connote actions or occurrences. In the context of object design for-
operation. Conventional procedural design techniques can be used to accom- malization, we consider not only verbs but also descriptive verb phrases and
plish this. predicates (e.g., “is equal to”) as potential operations. The grammatical parse is
Data structures are designed concurrently with algorithms. Since opera- applied recursively until each operation has been refined to its most detailed
tions invariably manipulate the attributes of a class, the design of the data level.
structures that best reflect the attributes will have a strong bearing on the al- Once the basic object model is created, optimization should occur. Rambaugh
gorithmic design of the corresponding operations. and his colleagues suggest three major thrusts for OOD optimization:
Although many different types of operations exist, they can generally be di-
vided into three brpad categories: operations that data in some . Review the object-relationship model to ensure that the implemented design
way (e.g., adding, deleting, reformatting, selecting); operations that perform leads to efficient utilization of resources and ease of implementation. Add re-
a computation; and operations that monitor an object for the occurrence of dundancy where necessary.
a controlling event. !" Revise attribute data structures and corresponding operation algorithms to
For example, the processing narrative contains the sentence enhance efficient processing.
fragments: “sensor is assigned a number and type” and “a master password is !" Create new attributes to save derived information, thereby avoiding recom-
programmed for arming and the system.” These two phrases indi- putation.
cate a number of things:
“‘See Chapter for details. ‘*Underlining has been added isolate important verbs.
CHAPTER 2 1 DESIGN
634 PART FOUR OBJECTORIENTED SOFTWARE ENGINEERING
A detailed discussion of 00 design optimization is beyond the scope this Referring once again to the example, we can define the highest-level
book. The interested reader should refer to and program component as:
PROCEDURE software
21.4.3 Program Components and Interfaces The component can be coupled with a preliminary design
for the following packages (objects):
An important aspect of software design is modularity-that is, the spec-
ification of program components (modules) that are combined to form a com- PACKAGE system IS
plete program. The object-oriented approach defines the object as a program TYPE system data
component that is itself linked to other components (e.g., private data, opera- PROC install, define, build, load
tions). But defining objects and operations is not enough. During design, we PROC display, reset, query, modify, call
must also identify the interfaces that exist between objects and the overall PRIVATE
structure (considered in an architectural sense) of the objects. PACKAGE BODY system IS
Although a program component is a abstraction, it should be repre- PRIVATE
sented in the context of the programming language with which the design is to STRING LENGTH
be implemented. To accommodate OOD, the programming language to be used verification phone number, telephone number, . . .
for implementation should be capable of creating the following program com- IS STRING LENGTH
ponent (modeled after Ada): sensor table DEFINED
'sensor type IS STRING LENGTH
PACKAGE program-component-name IS sensor number, alarm threshold IS NUMERIC;
TYPE specification 'of data objects PROC install RECEIVES (telephone number)
for operation install)
PROC specification of related operations .
END system
PRIVATE
PACKAGE sensor IS
data structure details for objects
TYPE sensor data
PACKAGE BODY program-component-name IS
PROC read,
PROC (interface description)
PRIVATE
. PACKAGE BODY sensor IS
PRIVATE
IS STRING LENGTH
END
PROC (interface description) IS sensor status IS STRING LENGTH
characteristics DEFINED
threshold, signal type, signal level IS NUMERIC,
hardware interface DEFINED
IS NUMERIC,
END
END sensor
END program-component-name
In the Ada-like PDL (program design language) shown above, a program
component is specified by indicating both data objects and operations. The spec- END software
ification-part of the component indicates all data objects (declared with the
TYPE statement) and the operations (PROC for procedure) that act on them.
Data objects and corresponding operations are specified for each of the pro-
The private part (PRIVATE) of the component provides otherwise hidden details
of data structure and processing. In the context of our earlier discussion, the gram components for software. The final step in the object design
PACKAGE is conceptually similar to objects discussed throughout this chapter. process completes all information required to fully implement the data
The first program components to be identified should be the highest-level and types contained in the PRIVATE portion of the package and all pro-
module from which all processing originates and all data structures evolve. cedural detail contained in the PACKAGE BODY.
636 PART FOUR. OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 21: DESIGN
To illustrate the detail design of a program component, we reconsider the create a solution. Gamma and his colleagues discuss this when they
package described above. The data structures for sensor attributes have state:
already been defined. Therefore, the step is to define the interfaces for
each of the operations attached to sensor: recurring patterns of classes and communicating objects in
many object-oriented systems. These patterns solve specific design problems
PROC read sensor status: OUT); and make object-oriented design more flexible, elegant, and ultimately
PROC set (alarm characteristics, hardware interface: IN) They help designers reuse successful designs by basing new de-
PROC test sensor status, alarm characteristics: signs on prior experience. A designer who is familiar with such patterns can
OUT); apply them immediately to design problems without having to rediscover
them.
The next step requires refinement of each operation associated
with the sensor package. To illustrate the refinement, we develop a processing Throughout the OOD process, a software engineer should look for every oppor-
narrative (an informal strategy) for read: tunity to reuse existing design patterns and to create new ones if reuse cannot
be achieved.
When the sensor object receives a read message, the read process is invoked.
The process determines the interface and signal type, polls the sensor interface,
converts characteristics into an internal signal level, and compares the in-
ternal signal level to a threshold value. If the threshold is exceeded, the sensor
Describing a Design
status is set to “event.” Otherwise, the sensor status is set to “no event.” If an
error is sensed while polling the sensor, the sensor status is set to “error.”
Mature engineering disciplines make use of thousands of design patterns. For
Given the processing narrative, a PDL description of the read process can be example, a mechanical engineer uses a two-step, keyed shaft as a design pat-
developed: tern. Inherent in the pattern are attributes (the diameters of the shaft, the di-
mensions of the etc.1 and operations (e.g., rotation, shaft con-
PROC read OUT); nection). An electrical engineer uses an integrated circuit (an extremely
IS BIT STRING complex design pattern) to solve a specific element of a new problem. All de-
IF sign patterns can be described by specifying four pieces of information
"B"
THEN
GET (sensor, exception: sensor status : raw. !" the name of the pattern
signal;' !" the problem to which the pattern is generally applied
CONVERT
!" the characteristics of the design pattern
I F
THEN sensor status : "event"; !" the consequences of applying the design pattern
ELSE sensor status : "no event";
The design pattern name is an abstraction that conveys significant mean-
ELSE {processing for other types of interfaces would be ing about its applicability and intent. The problem description indicates the en-
specified) vironment and conditions that must exist to make the design pattern applica-
ble. The pattern characteristics indicate the attributes of the design that may
RETURN sensor status; be adjusted to enable the pattern to accommodate a variety of problems. These
END read attributes represent characteristics of the design that can be searched (e.g., via
a database) so that an appropriate pattern can be found. Finally, the conse-
The PDL representation of the read operation can be translated into the ap- quences associated with the use of a design pattern provide an indication of the
propriate implementation language. The functions GET and CONVERT are as- ramifications of design decisions.
sumed to be available as part of a run-time library. The names of objects and subsystems (potential design patterns) should
be chosen with care. As we discuss in Chapter 26, one of the key technical
problems in software reuse is simply the inability to existing reusable
21.5 DESIGN PATTERNS patterns when hundreds or thousands of candidate patterns exist. The
search for the “right” pattern is aided immeasurably by a meaningful pat-
The best designers in any field have an uncanny ability to patterns that tern name along with a set of characteristics that help in classifying the ob-
characterize a problem and corresponding patterns that can be combined to ject
PART FOUR OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER OBJECT-ORIENTED DESIGN 639
can be as a pyramid composed of four layers. The foundation layer
21.5.2 Using Patterns in Design
focuses on the design of subsystems that implement major system functions;
the class layer the overall object architecture and the hierarchy of
In an object-oriented system, design patterns” can be used by applying two dif- classes required to implement a system; the message layer indicates how col-
ferent mechanisms: inheritance and composition. Inheritance is a fundamental laboration between objects will be realized; and the responsibilities layer iden-
00 concept and was described in detail in Chapter 19. Using inheritance, an tifies tho attribute? and that characterize each class.
existing design pattern becomes a template for a new subclass. The attributes Like OOA, many different OOD methods. Although each differs
and operations that exist in the part of the subclass. from its counterparts, all conform to the design pyramid and all approach the
Composition is a concept that leads to aggregate objects. That is, a problem design process through two levels of abstraction-design of the system and sub-
-may require objects that have complex functionality the extreme, a subsys- systems, and design of individual objects.
tem accomplishes this). The complex object can be assembled by selected a set During subsystem design, four components are addressed: the problem do-
of design patterns and composing the appropriate object (or subsystem). Each main component, the human interaction component, a task management com-
design pattern is treated as a black box, and communication among the pat- ponent, and a data management component. The problem domain component
terns occurs only via well-defined interfaces. implements the customer requirements for an 00 application. The other com-
Gamma and his colleagues suggest that object composition should ponents provide a design infrastructure that enables the application to operate
be favored over inheritance when both options exist. Rather than creating large effectively. The object design process focuses on the description of data struc-
and sometimes unmanageable class hierarchies (the consequence of the overuse tures that implement class attributes, algorithms that implement operations,
of inheritance), composition favors small class hierarchies and objects that re- and messages that enable collaborations and object relationships.
main focused on one objective. Composition uses existing design patterns Object-oriented programming extends the design model into the executable
(reusable components) in unaltered form. domain. An 00 programming language is used to translate the classes, attri-
butes, operations, and messages into a form that can be executed by a machine.
Object-oriented design represents a unique approach for software engi-
21.6 OBJECT-ORIENTED PROGRAMMING neers. To quote Tom Love
Although all areas of object technologies have received significant attention The roots of software problems may lie in the most traditional terms for de-
within the software community, no subject has produced more books, more dis- scribing our industry--data processing. We have been taught that data and pro-
cussion, and more debate than object-oriented programming There have cessing are two distinct “things” which are somehow fundamental to our busi-
been well over 100 books written on C++ programming, dozens dedicated to ness. That partitioning may be far more detrimental than we realize.
Smalltalk, a growing number dedicated to and many books dedicated to
less widely used 00 languages. OOD provides us with a means for breaking down the “partitions” between
The software engineering viewpoint stresses OOA and OOD, and considers data and process. In doing so, software quality can be improved.
OOP (coding) an important but secondary activity that is an outgrowth of
analysis and design. The reason for this is simple. As the complexity of systems
increases, the design architecture of the end product has a significantly stronger REFERENCES
influence on its success than the programming language that has been used.
And yet, “language wars” continue to rage.
The details of OOP are best left to books that are dedicated to the subject. and P. Gopinath, “Object-Oriented Real-Time Systems:
The interested reader should refer to one or more of the OOP hooks noted in Concepts and Examples,” Computer, vol. 25, no. 12, December 1992, pp.
“Further Readings and Other Information Sources” at the end of this chapter. 25-32.
LB00941 G., Object-Oriented Analysis and Design, 2nd edition, Benjamin
Cummings, 1994.
G., and J. Rambaugh, Unified Method for Object-Oriented
21.7 SUMMARY Rational Software Corp., 1996.
Brown, A.W., Object-Oriented Databases, McGraw-Hill, 1991,
Object-oriented design translates the OOA model of the real world into an im- Coad, P., and E. Object-Oriented Prentice-Hall, 1991.
plementation-specific model that can he realized in software. The OOD process Cox, B., “Software and Objective-C,” Spring, 1986.
Davis, A., “Object-Oriented Requirements to Object-Oriented Design: An
Easy Transition?” Systems Software, vol. 30, 1995, pp. 151-159.
de D., D. Lea, and Object-Oriented System
**Gamma and his have published a catalog of 23 design patterns for use
Development, Addison-Wesley, 1993.
in 00
PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 2 : 641
Fichman, R. and C. “Object-Oriented and Conceptual Design 21.9. Discuss how the data management component is implemented in a typical
Methodologies,” Computer, vol. 25, no. 10, October 1992, pp. 22-39. 00 development environment.
Gamma, E. et al., Design Patterns, Addison-Wesley, 1995. 21.10. Write a two or three page paper on object-oriented databases and discuss
Goldberg, A., and D. Smalltalk-80: The Language and Its how they might be used to develop the data management component.
Implementation, Addison-Wesley, 1983. 21.11. How does a designer recognize tasks that must be concurrent?
Jacobson, I., Object-Oriented Software Addison-Wesley,
21.12. Apply the OOD approach discussed in this chapter to flesh out the design
1992.
for the system. Define all relevant subsystems and develop object
Succeeding with the and OMT Methods, Lockheed-Martin and
designs for important classes.
Rational Software Corporation, Addison-Wesley, 1996.
Love, “Message Object Programming: Experiences with Commer- 21.13. Apply the OOD approach discussed in this chapter to the PHTRS system de-
cial Systems,” Productivity Products International, Sandy Hook, CT, scribed in problem 12.13.
1985. 21.14. Describe a video game and apply the OOD approach discussed in this chap-
Meyer, Bertrand, Object-Oriented Software 2nd edition, ter to represent its design.
Prentice-Hall, 1988. 21.15. You are responsible for the development of an electronic mail (e-mail) sys-
Design Patterns for Object-Oriented Software Development, tem to be implemented on a PC network. The e-mail system will enable
Addison-Wesley, 1995. users to create letters to be mailed to another user or to a specific address
Rambaugh, J. et al., Object-Oriented Modeling and Design, list. Letters can be read, copied, stored, etc. The e-mail system will make use
Hall, 1991. of existing word-processing capability to create letters. Using this descrip-
B.A., Object-Oriented Databases: Technology, Applications and tion as a starting point, derive a set of requirements and apply OOD tech-
Products, McGraw-Hill, 1994. niques to create a top-level design of the e-mail system.
Taylor, D.A., Object-Oriented Information Systems, Wiley, 1992. 21.16. A small island nation has decided to build an air traffic control sys-
Wirfs-Brock, R., B. Wilkerson, and L. Weiner, Object-Oriented tem for its one airport. The system is specified as follows:
Software, Prentice-Hall, 1990.
All aircraft landing at the airport must have a transponder that transmits
aircraft type and flight data in high-density packed format to the ATC
PROBLEMS AND POINTS TO PONDER ground station. The ATC ground station can query an for specific in-
formation. When the ATC ground station receives data, it is unpacked and
stored in an database. A computer graphics display is created from
21.1. The design pyramid for OOD differs somewhat from the pyramid described
the stored information and displayed for an air traffic controller. The display
for conventional software design (Chapter Discuss the differences and
is updated every 10 seconds. All information is analyzed to determine if
similarities of the two pyramids.
“dangerous situations” are present. The air traffic controller can query the
21.2. How do OOD and structured design differ? What aspects of these two design database for specific information about any plane displayed on the screen.
methods are the same?
21.3. Review the criteria for effective modularity discussed in Section 21.1.2. Using OOD, create a design for the ATC system. Do not attempt to imple-
Using the design approach described later in the chapter, demonstrate how ment it!
these criteria are achieved.
21.4. Select one of the OOD methods presented in Section 21.1.3 and prepare a
one hour tutorial for your class. Be sure to show all graphical modeling con- FURTHER READINGS AND INFORMATION SOURCES
ventions that the authors suggest.
21.5. Select an OOD method not presented in Section 21.1.3 (e.g., HOOD), and The object-oriented design literature is expanding rapidly. Books by Reil
prepare a one hour tutorial for your class. Be sure to show all graphical mod- Oriented Design Through Heuristics, Addison-Wesley, 19961, Gamma et al.
eling conventions that the authors suggest. Jacobson Rambaugh et al. Coad
21.6. Discuss how the use case can serve as an important source of information and and Wirfs-Brock, Wilkerson, and Weiner pro-
for design. vide excellent insight into this important area. In addition, the following books
21.7. Research a GUI development environment and show how the human-com- are worth reviewing:
puter interaction component is implemented in the real world. What design
patterns are offered and how are they used? Berard, E.V., Essays on Object-Oriented Software Engineering,
21.8. Task management for 00 systems complex. Do some research Wesley, 1993.
on OOD methods for real-time systems and how de Champeaux, D., D. Lea, and Object-Oriented System Develop-
task mnnagomcnt is in ment, Addison-Wesley, 1993.
PART FOUR. OBJECT-ORIENTED SOFTWARE ENGINEERING
CHAPTER 2 I OBJECTQRIENTED 643
Coad, D. North, and M. Object Models: Strategies, Patterns, smalltalk) are useful sources for information, discussion, and debate on OOD
and Applications, Prentice-Hall, 1995. methods, programming techniques, and tools.
Coleman, D. et al., Object-Oriented Development: The FUSION Method, The following resources (listed without further comment) contain useful in-
Prentice-Hall, 1994. formation on OOD and OOP, including additional references, articles, and in-
Hutt, T.F. Object Analysis and Design: Description of Methods, Wiley, formation:
1994.
Meyer, B., Reusable Software, 1995.
Page-Jones, M., What Every Programmer Should Know about
Oriented Design, Dorset House, 1995.
Schlaer, and S., Object Life Cycles: Modeling the World in States,
Prentice-Hall, 1992).
Wilkie, G., Object-Oriented Software Engineering, Addison-Wesley, 1993. An up-to-date list of World Wide Web references for object-oriented design
E., Object-Oriented Systems Design: An Integrated Approach, can be found
Prentice-Hall, 1994.
E. et al., Mainstream Objects, Prentice-Hall, 1995.
Buschmann and Meunier (Pattern-Oriented Software Architecture, Wiley, 1996)
shows how design patterns can help in the development of large-scale applica-
tions. Hutt (Object Analysis and Design, Wiley, 1994) has edited a collection
that presents and compares 16 different object-oriented analysis and design
methods.
Literally hundreds of books have been published on object-oriented pro-
gramming A sampling of OOP language-specific books follows:
Barnes, J., Programming in Ada95, Addison-Wesley, 1995.
Eckel, B., + Inside and Oat, McGraw-Hill, 1993.
Lakos, J., Large-Scale C+ + Software Design, 1996.
Eiffel: Rist, R.S., and R. Terwillinger, Object-Oriented Programming
in Eiffel, 1 9 9 5
Meyer, B, Object-Oriented Software Construction, 2nd edi-
tion, Prentice-Hall, 1995.
Java: Arnold, K.. and J. Gosling, The Programming Lan-
guage, Addison-Wesley, 1996.
Manger, J., Essential McGraw-Hill, 1996.
W.R., and J.R. Pugh, Programming in Smalltalk,
Prentice-Hall, 1995.
E. et al., with Style, Prentice-Hall, 1995.
The special requirements of real-time systems are covered by Selek and his
colleagues (Real-Time Object-Oriented Modeling, Wiley, 1995). The use of “ap-
plication frameworks” a mechanism for is by Lewis (edi-
tor) and his colleagues (Object-Oriented Application Frameworks, IEEE
Computer Society Press, 1995).
The same Internet sources noted for Chapters 19 and 20 are also applica-
ble for OOD. The Internet newsgroup comp.object and newsgroups dedicated
to 00 programming languages (e.g., comp.lang.C++ and comp.lang.
22: TESTING 645
, - ’
els of classes, class connections and relationships, system design and allocation,
and object design (incorporating a model of object connectivity via messaging).
At each stage, the models can be testing in an attempt to uncover errors prior
to their propagation to the next iteration.
OBJECT-ORIENTED
It can be argued that the review of 00 analysis and design models is es-
pecially useful because the same semantic constructs (e.g., classes, attributes,
operations, messages) appear at the analysis, design, and code levels. Therefore,
a problem in the definition of class attributes that is uncovered during analy-
TESTING
sis will circumvent side effects that might occur if the problem were not dis-
covered until design or coding (or even the next iteration of analysis).
For example, consider a class in which a number of attributes are defined
during the first iteration of OOA. An extraneous attribute is appended to the
class (due to a misunderstanding of the problem domain). Two operations are
then specified to manipulate the attribute. A review is conducted and a domain
expert points out the problem. By eliminating the attribute at this
stage, the following problems and unnecessary effort may be avoided during
analysis:
1. Special subclasses may have been generated to accommodate the unneces-
sary attribute or exceptions to it. Work involved in the creation of unnec-
essary subclasses has been avoided.
2. A misinterpretation of the class definition may lead to incorrect or extra-
n Chapter 16 we learned that the objective of testing, stated simply, is to find neous class relationships.
the greatest possible number of errors with a manageable amount of effort 3. The behavior of the system or its ‘classes may be improperly characterized
applied over a realistic time span. Although this fundamental objective remains to accommodate the extraneous attribute.
unchanged for object-oriented software, the nature of 00 programs changes
both testing strategy and testing tactics. If the problem is not uncovered during analysis and propagated further, the fol-
It might be argued that as OOA and OOD mature, greater reuse of design lowing problems could occur (and will have been avoided because of the earlier
patterns will mitigate the need for heavy testing of 00 systems. Exactly the review) during design:
opposite is true. Binder discusses this when he states:
1. Improper allocation of the class to a subsystem and/or tasks may occur dur-
reuse is a new context of usage and retesting is prudent. It seems likely ing system design.
that more, not less testing will be needed to obtain high reliability in
oriented systems. 2. Unnecessary design work may be expended to create the procedural design
for the operations that address the extraneous attribute.
To adequately test 00 systems, three things must be done: the 3. The messaging model will be incorrect (because messages must be designed
tion of testing must be broadened to include error discovery techniques applied for the operations that are extraneous).
to OOA and OOD models; (2) the strategy for unit and integration testing must
change significantly; and the design of test cases must account for the If the problem remains undetected during design and passes into the coding
unique characteristics of 00 software. activity, considerable effort and energy will be expended to generate code that
implements an unnecessary attribute, two unnecessary operations, messages
that drive inter-object communication, and many other related issues. In addi-
tion, testing of the class will absorb more time than necessary. Once the prob-
22.1 BROADENING THE VIEW OF TESTING lem is finally uncovered, modification to the system must be carried out with
the ever-present potential for side effects that are caused by change.
The construction of begins with the of During latter stages of their development, OOA and OOD models provide
sis and design (Chapters and Because of the evolutionary na- substantial information about the structure and behavior of the system. For
ture of the 00 software engineering paradigm, these models begin as relatively this reason, these models should be subjected to rigorous review prior to the
informal representations of system requirements and evolve into detailed mod- generation of code.
CHAPTER 22: TESTING
646 PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING
of collaborations imply a series of relation-
All object-oriented models should be (in this the “test-
ing” is used to incorporate formal technical reviews) for correctness, complete- ships (i.e., connections) between classes of the system. The object relation-
ness, and consistency within the context of the model’s syntax, se- ship model provides a graphic representation of the connections between classes.
All of this information can be obtained from the OOA model (Chapter 20).
mantics, and
To evaluate the class model the following steps have been recommended
22.2 TESTING OOA AND OOD MODELS 1. Revisit the CRC model and the object-relationship model. Cross check
ensure that all collaborations implied by the OOA model are properly re-
Analysis and design models cannot be tested in the conventional sense, because flected in both.
they cannot be executed. However, formal technical reviews (Chapter can be 2. Inspect the description of each CRC index card to determine if a delegated
used to examine the correctness and consistency of both analysis and design responsibility is part of the collaborator’s definition. For example, consider
models. a class defined for a point-of-sale check-out system and called credit sale.
This class has a CRC index card illustrated in Figure 22.1.
For this collection of classes and collaborations, we ask whether a re-
22.2.1 Correctness of OOA and OOD sponsibility (e.g., read credit card) is accomplished if delegated to the named
collaborator (credit card); that is, does the class credit card have an op-
eration that enables it to be read? In this case the answer is “yes.” The ob-
The notation and syntax used to represent analysis and design models will be tied ject relationship is traversed to ensure that all such connections are valid.
the specific analysis and design method that is chosen for the project. Hence,
syntactic correctness is judged on proper use of the and each model is 3. Invert the connection to ensure that each collaborator that is asked for ser-
reviewed ensure that proper modeling conventions have been maintained. vice is receiving requests from a reasonable source. For example, if the
During analysis and design, semantic correctness must be judged based on credit card class a request for purchase amount from the credit
the model’s conformance to the real world problem domain. If the model accu- sale class, there would be a problem. Credit card does not know the pur-
chase amount.
rately reflects the real world (to a level of detail that is appropriate to the stage
of development at which the model is reviewed) then it is semantically correct.
To determine whether the model does, in fact, reflect the real world, it should
be presented to problem domain experts, who will examine the class definitions
class name: credit sale
and hierarchy for omissions and ambiguity. Class relationships (instance con-
nections) are evaluated to determine whether they accurately reflect real world class type: transaction event
object connections.’
class characteristics: nontangible, atomic, sequential, permanent,
responsibilities:
22.2.2 Consistency of OOA and OOD Models
The consistency of OOA and OOD models may be judged by “considering the
relationships among entities in the model. An inconsistent model has repre-
sentations in one part that are not correctly reflected in other portions of the
model”
To assess consistency, each class and its connections to other classes should
be examined. The class-responsibility-collaboration (CRC) model and an ob-
ject-relationship diagram can be used to facilitate this activity. As we noted in
Chapter 20, the CRC model is composed on CRC index cards. Each CRC card
lists the class name, its responsibilities (operations), and its collaborators (other
classes to which it sends messages and on which it depends for the
‘Use can be invaluable in tracking analysis and design models against real world us- FIGURE 22.1. A example CRC index card used far review
age scenarios for the 00 system.
PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 22: OBJECTORIENTED TESTING 649
4. Using the inverted connections examined in step 3, determine whether class and each instance of a class (object) packages attributes (data) and the
other classes might be required or whether responsibilities are properly operations (also known as methods or services) that manipulate these data.
grouped among the classes. Rather than the individual module, the smallest unit is the
5. Determine whether widely requested might be combined lated class or object. A class can contain a number of different operations, and
into a single’responsibility. For example, read credit curd and get autho- a particular operation may exist as part of a number of different classes.
rization occur in every situation. They might be combined into a validate Therefore, the meaning of unit testing changes dramatically.
credit request responsibility that incorporates getting the credit card We can no longer test a single operation in isolation (the conventional view
ber and gaining authorization of unit testing) but rather, as part of a class. To illustrate, consider a class hi-
erarchy in which an operation X is defined for the superclass and is inherited
6. Steps 1 to 5 are applied iteratively to each class and through each evolu-
tion of the OOA model. by a number of subclasses. Each subclass uses operation X, but it is applied
within the context of the private attributes and operations that have been de-
fined for each subclass. Because the context in which operation X is used varies
Once design models (Chapter have been created, of the system in subtle ways, it is necessary to test operation X in the context of each of the
design and the object design should also be conducted. The design de- subclasses. This means that testing operation in a vacuum (the traditional
picts the subsystems that compose the product, the manner in which subsys- unit testing approach) is ineffective in the object-oriented context.
tems are allocated to processors, and the allocation of classes to subsystems. Class testing for 00 software is, the equivalent of unit testing for conven-
The object model presents the details of each class and the messaging activi- tional Unlike unit testing of conventional software, which tends to
ties that are necessary to implement collaborations between classes. focus on the algorithmic detail of a module and the data that flow across the
The system design is reviewed by examining the object-behavior model de- module interface, class testing for 00 software is driven by the operations en-
veloped during OOA and mapping required system behavior against the sub- capsulated by the class and the state behavior of the class.
systems designed to accomplish this behavior. Concurrency and task allocation
are also reviewed within the context of system behavior. The behavioral states
of the system are evaluated to determine which exist concurrently.
The object model should be tested against the object-relationship network 22.3.2 Integration Testing in the 00 Context
to ensure that all design contain necessary attributes and operations
to implement the collaborations defined for each CRC index card. In addition,
Because object-oriented software does not have a hierarchical control structure,
the detailed specification of operation details (i.e., the algorithms that imple-
conventional top-down and bottom-up integration strategies have little mean-
ment the operations) are reviewed using conventional inspection techniques.
ing. In addition, integrating operations one at a time into a class (the conven-
tional incremental integration approach) is impossible because of the “di-
rect and indirect interactions of the components that make up the class”
22.3 OBJECT-ORIENTED TESTING STRATEGIES
There are two different strategies for integration testing of 00 systems
The classical strategy for testing computer software begins with “testing in the The first, thread-bused testing, integrates the set of classes required
small” and works outward toward “testing in the large.” Stated in the jargon of respond to one input or event for the system. Each thread is integrated and tested
software testing (Chapter we begin with unit testing, then progress toward individually Regression testing is applied to ensure that no side effects occur. The
integration testing, and culminate with validation and system testing. In con- second integration approach, use-based testing, begins the construction of the sys-
ventional applications, unit testing focuses on the smallest compilable program tem by testing those classes (called independent classes) that use very few any)
unit-the subprogram (e.g., module, subroutine, procedure). Once each of these of server classes. After the independent classes are tested, the next layer of
units has been testing individually, it is integrated into a program structure classes, called dependent classes, use the independent classes are tested. This
while a series of regression tests are run to uncover errors due to interfacing sequence of testing layers of dependent classes continues until the entire system
the modules and side effects that are caused by the addition of new units, is constructed. Unlike conventional integration, the use of drivers and stubs
Finally, the system as a whole is tested to ensure that errors in requirements (Chapter 16) as replacement operations is to be avoided when possible.
are uncovered. Cluster testing is one step in the integration testing of 00 soft-
ware. Here, a cluster of collaborating classes (determined by examining the
CRC and object-relationship model) is exercised by designing test cases that at-
Unit Testing in the 00 Context tempt uncover errors in the collaborations.
When object-oriented software is considered, the concept of the unit changes.
Encapsulation drives the definition of classes and objects. This means that each design methods for 00 discussed in Sections 22.4 through 22.6
650 PART FOUR- OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER 22: OBJECTORIENTED TESTING 651
22.3.3 Validation Testing in an Context to obtain. Unless built-in operations are provided to report the values for class
attributes, a snapshot of the state of an object may be difficult to acquire.
At the validation or system level, the details of class connections disappear. Inheritance also leads to additional challenges for the test case designer.
Like conventional validation, the validation of 00 software focuses on user vis- We have already noted that each new context of usage requires retesting, even
ible actions and user recognizable outputs from the system. To assist in the de- though reuse has been achieved. In addition, multiple inheritance3 complicates
rivation of validation tests, the tester should draw upon use cases (Chapter testing further by increasing the number of contexts for which testing is re-
that are part of the analysis model. The case provides a scenario that has quired If subclasses instantiated from a superclass are used within
a high likelihood of uncovered errors in user interaction requirements. the same problem domain, it is likely that the set of test cases derived for the
Conventional black-box testing methods (Chapter 16) can be used to drive superclass can be used when testing the subclass. However, if the subclass is
validation tests. In addition, test cases may be derived from the object-behav- used in an entirely different context, the superclass test cases will have little
ior model and from the event flow diagram created as part of OOA. applicability and a new set of tests must be designed.
22.4 TEST CASE DESIGN FOR 00 SOFTWARE 22.4.2 Applicability Conventional Test Case Design Methods
Test case design methods for 00 software are in their formative stages. The white-box testing methods described in Chapter 16 can be applied to the op
However, an overall approach to 00 test case design has been suggested by erations defined class. Basis path, loop testing, or data flow techniques can
Berard help ensure that every statement in an operation has been tested. However,
the concise structure of many class operations causes some to argue that the ef-
1. Each test case should be uniquely identified and should be explicitly asso- fort applied to white-box testing might be better redirected to tests at a class level.
ciated with the class to be tested. Black-box testing methods are as appropriate for 00 systems as they are
for systems developed using conventional software engineering methods. As we
2. The purpose of the test should be stated.
noted earlier in this chapter, use can provide useful input in the design
3. A list of testing steps should be developed for each test and should contain of black-box and state-based tests
a. a list of specified states for the object that is to be tested
b. a list of messages and operations that will be exercised as a consequence
of the test 22.4.3 Fault-Bared Testing4
c. a list of exceptions that may occur as the object is tested
d. a list of external conditions (i.e., changes in the environment external to The object of fault-based testing within an 00 system is to design tests that
the software that must exist in order to properly conduct the test) have a high likelihood of uncovering plausible faults. Because the product or
e. supplementary information that will aid in understanding or imple- system must conform to customer requirements, the preliminary planning re-
menting the test quired to perform fault-based testing begins with the analysis model. The
tester looks for plausible faults (i.e., aspects of the implementation of the sys-
Unlike conventional test case design, which is driven by an input-process-out- tem that may result in defects). To determine whether these faults exist, test
put view of software or the algorithmic detail of individual modules, object-ori- cases are designed to exercise the design or code.
ented testing focuses on designing appropriate sequences of operations to ex- Consider a simple Software engineers make errors at the
ercise the states of a class. boundaries of a problem. For example, when testing a SQRT operation that re-
turns errors for negative numbers, we know to try the boundaries: a negative
number close to zero, and zero itself. “Zero itself” checks whether the pro-
grammer made a mistake like:
22.4.1 The Case Design Implications of 00 Concepts
As we have already seen, the 00 class is the target for test case design. Because
00 design concept that should he with extreme
attributes and operations are encapsulated, the testing of operations outside of
the class is generally unproductive. Although encapsulation is an essential de- 22.4.3 through 22.4.7 have been adapted from article by Brian posted on
the Internet This adaptation is included with the permission of the
sign concept for 00, it can create a minor obstacle when testing. As Binder author. For further discussion of these topics,
notes, requires reporting on the concrete and abstract state
code presented in this and following sections C+ For infor-
of an object.” Yet, encapsulation can make this information somewhat difficult mation, any good book on C++.
652 PART FOUR: SOFTWARE ENGINEERING CHAPTER 22: TESTING 653
if !"some types of faults become less plausible (not worth testing for)
!" some types of faults become more plausible (worth testing now)
instead of the correct: !" some new types of faults appear
When an operation is invoked, it may be hard to tell exactly what code gets ex-
ercised. That is, the operation may belong to one of many classes. Also, it can
As another example, consider a Boolean expression: be hard to determine the exact type/class of a parameter. When the code
the parameter, it may get an ‘unexpected value.
if !b The difference can be understood by considering a conventional function
call:
Multicondition testing and related techniques probe for certain plausible faults
in this expression, such as: =
should be an For conventional software, the tester need consider all behaviors attributed to
was left out where it was needed and nothing more. In an 00 context, the tester must consider the behav-
iors of base: : , of derived: : , and so on. Each time is
There should be parentheses around “!b invoked, the tester must consider the union of all distinct behaviors. This is
easier if good 00 design practices are followed and the difference between su-
For each plausible fault, we design test cases that will force the incorrect ex- perclasses and subclasses (in C++ jargon, these are called base and derived
pression to fail. In the expression above, = 0, b = 0 , = 0 make the classes) are limited. The testing approach for base and derived classes is es-
expression as given evaluate false. If the should have the sentially the same. The difference is one of bookkeeping.
code has done the wrong thing and might branch to the wrong path. Testing 00 class operations is analogous to testing code that takes a func-
Of course, the effectiveness of techniques depends on how testers per- tion parameter and then invokes it. Inheritance is a convenient way of pro-
ceive a “plausible fault.” If real faults in an 00 system are perceived to be “im- ducing polymorphic operations. At the call site, what matters is not the inher-
plausible,” then this approach is really no better than any random testing tech- itance, but the polymorphism. Inheritance does make the search for test
nique. However, if the analysis and design models can provide insight into what requirements more straightforward.
is likely to go wrong, testing find numbers By virtue of the architecture and construction of 00 systems, are some
errors with relatively low of effort. types of faults more plausible and others less plausible? The answer is “yes” for
Integration testing looks for faults in message connections. 00 systems. For example, because 00 operations aregenerally smaller, there
Three types of faults are encountered in this context: unexpected result, wrong tends to be a more integration required and more opportunities for integration
operation/message used, incorrect invocation. To determine plausible faults faults. Therefore, integration faults become more plausible.
as functions (operations) are behavior of operation must be
examined.
Integration testing applies to attributes as well as to operations. The “be-
\ haviors” of an object are by that its attributes are assigned. 22.4.5 lest Cases and the Class Hiemrchy
Testing should exercise the attributes to determine whether proper values oc-
cur for distinct types of object behavior. As noted earlier in this chapter, inheritance does not obviate the need for thor-
It is important to note that integration testing attempts to find errors in ough testing of all derived classes. In fact, it can actually complicate the
the client object, not the server. Stated in conventional terms, the focus of in- process.
tegration testing is to determine whether errors exist in the calling code, not Consider the following situation. A class base contains operations inher-
the called code. The operation call is used as a clue, a way to find test require- ited and redefined. A class derived redefines redefined to serve in a local con-
ments that exercise the calling code. text. There is little doubt that derived: has to be tested
because it represents a new design and new code. But does derived: :
it have to be retested?
If derived: : calls redefined, and the behavior of redefined
22.4.4 The Impact of 00 Programming on Testing has changed, derived: : inherited may mishandle the new behavior.
Therefore, it needs new tests even though the design and code have not changed.
There are several ways object-oriented programming can have an impact on It is important to note, however, that only a subset of all tests for
testing. Depending on to i : may have to be conducted. If part of the design and code
654 PART FOUR, SOFTWARE ENGINEERING CHAPTER OBJECTORIENTED TESTING 655
for inherited does not depend on redefined (i.e., does not call it or any code that Use Case: Print New Copy
indirectly calls it), that code need not be retested in the derived class. Background: Someone asks the user for a fresh copy of the document. It must
and are be printed.
tions with different specifications and implementations. They would each have a 1. Open the document.
set of test requirements derived from the specification and implementation. Those 2. Print it.
test requirements probe for plausible faults: integration faults, condition faults, 3. Close the document.
boundary faults, and so forth. But the operations are likely be similar Their ,
sets of test requirements will overlap. better the 00 design, the greater the Again, the testing approach is relatively obvious. Except that this document
tests need derived only for those didn’t appear out of nowhere. It was created in an earlier task. Does that task
quirements that are not satisfied by the base: affect this one?
To summarize, the base: tests are applied to objects of In many modern editors, documents remember how they were last printed.
class derived. Test inputs may be appropriate for both base and derived By default, they print the same way next time. After the the Final
classes, but the expected results may differ in the derived class. scenario, just selecting “Print” in the menu and clicking the “Print” button in
the dialog box will cause the last corrected page to print again. So, according
to the editor, the scenario should look like this:
22.4.6 Scenario-Based Test Design
Use Case: Print a New Copy
Fault-based testing misses two main types of errors: incorrect specifications 1. Open the document.
and interactions among subsystems. When errors associated with incorrect 2. Select “Print” in the menu.
specification occur, the product doesn’t do what the customer wants. It might 3. Check if you’re printing a page range; if so, click to print the entire docu-
do the wrong thing, or it might omit important functionality. In either circum- ment.
stance, quality (conformance to requirements) suffers. Errors associated with 4. Click on the “Print” button.
subsystem interaction occur when the behavior of one subsystem creates cir- 5. Close the document.
cumstances (e.g., events, data flow) that cause another subsystem to fail.
Scenario-based testing concentrates on what the user does, not what the But this scenario indicates a potential specification error. The editor does not
product does. It means capturing the tasks (via use cases) that the user has to do what the user reasonably expects it to do. Customers will often overlook the
perform, then applying them and their variants as tests. check noted in step 3 above. They will then be annoyed when they trot off to
Scenarios uncover interaction errors. To accomplish this, test cases must be the printer and find one page when they wanted 100. Annoyed customers
more complex and more realistic than fault-based tests. Scenario-based testing nal specification bugs.
tends to exercise multiple subsystems in a single test (users do not limit them- A test case designer might miss this dependency in test design, but it is
selves to the use of one subsystem at a time). likely that the problem would surface during testing. The tester would then
As an example, consider the design of scenario-based tests for a text edi- have to contend with the probable response, “That’s the way it’s supposed to
tor. Use cases follow: work!”
Use Case: the Final Draft
Background: It’s not unusual to print the “final” draft, read it, and discover
some annoying errors that weren’t obvious from the on-screen image. This use 22.4.7 Testing Surface Structure and Deep Structure
case describes the sequence of events that occurs when this happens.
1. Print the entire document. Surface structure refers to the externally observable structure of an 00 pro-
2. Move around in the document, changing certain pages. gram. That is, structure that is immediately obvious to an end user. Bather
3. As each page is changed, it’s printed. than performing functions, the users of many 00 systems may be given objects
4. Sometimes of pages is printed. to manipulate in some way. But whatever the interface, tests are still based on
user tasks. Capturing these tasks involves understanding, watching, and talk-
This scenario describes two things: a test and specific user needs. The user ing with the representative user (and as many nonrepresentative users as are
needs are obvious: a method for printing single pages and a method for worth considering).
printing a range of pages. As far as testing goes, there is a need to test editing There will surely be some difference in detail. For example, in a conven-
after printing (as well as the reverse). The tester hopes to discover that the tional system with a command-oriented interface, the user might use the list
printing function causes errors in the editing function; that is, that the two soft- of all commands as a testing checklist. If no test scenarios existed to exercise
ware functions are not properly independent. a command, testing has likely overlooked some user tasks (or the interface has
656 PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING CHAPTER 22: TESTING 657
useless commands). In a object-based interface, the tester might use the list of This represents the minimum test sequence for account. However, a wide va-
all objects as a testing checklist. riety of other behaviors may occur within this sequence:
The best tests are derived when the designer looks at the system in a new
or unconventional way. For example, if the system or product has a balance
based interface, more thorough tests will be derived if the test case designer
pretends that operations are independent of objects. Ask questions like, “Might
the user want to use this operation-which applies only to the scanner A variety of different operation sequences can be generated randomly For ex-
while working with the printer?” Whatever the interface style, test case design
ample:
that exercises the surface structure should use both objects and operations as
clues leading to overlooked tasks.
Deep structure refers to the internal technical details of an program. Test case
withdrawclose
That is, the structure that is understood by examining the design and/or code.
Deep structure testing is designed to exercise dependencies, behaviors, and Test case
communication mechanisms that have been established as part of the subsys-
tem and object design (Chapter of 00 software.
Tbe analysis and design models are used as the basis for deep structure These and other random order tests are conducted to exercise different class
testing. For example, the object-relationship diagram or the subsystem collab- instance life histories.
oration graph depicts collaborations between objects and subsystems that may
not be externally visible. The test case designer then asks: “Have we captured
(as a test) some task that exercises the collaboration noted on the object-rela-
tionship diagram or the subsystem collaboration graph? If not, why not?” 22.5.2 Partition Testing at the Class Level
Design representations of class hierarchy provide insight into inheritance
structure. Inheritance structure is used in fault-based testing. Consider a situ- Partition testing reduces the number of test cases required to exercise the class
ation in which an operation named has only one argument and that ar- in much the same manner as equivalence partitioning (Chapter 16) does for con-
gument is a reference to a base class. What might happen when caller is passed ventional software. Input and output are categorized, and test cases are designed
a derived class? What are the differences in behavior that could affect caller? to exercise each category. But how are the partitioning categories derived?
The answers to these questions might lead to the design of specialized tests. State-based partitioning categorizes class operations based on their ability
to change the state of the class. Again considering the account class, state op-
22.5 erations include deposit and withdraw, whereas non-state operations include
METHODS AT THE LEVEL
balance, summarize, and Teats are designed in a way that exercises
operations that change state and those that do not change state separately.
In Chapter 16, we noted that software testing begins “in-the-small” and slowly Therefore,
progresses toward testing “in-the-large.” Testing in-the-small for 00 systems
focuses on a single class and the methods that are encapsulated by the class. Test case
testing and partitioning are methods that can be used to exercise a *close
class during 00 testing
Test case
22.5.1 Random Testing for 00 Classes Test case changes state, while test case exercises operations that do not
change state (other than those in the minimum test sequence).
To provide brief illustrations of these methods, consider a banking application in Attribute-based partitioning categorizes class operations based on the at-
which an account class has the following operations: open, setup, deposit, with- tributes that they use. For the account class, the attributes balance and credit
draw balance, summarize, creditlimit, and close Each of these opera- limit can be used to define partitions. Operations are divided into three parti-
tions may be applied for certain constraints (e.g., the account must tions: operations that use credit limit, (2) operations that modify credit
be opened before other operations can be applied and closed after all operations limit, and operations that do not use or modify credit limit. Test sequences are
are completed) are implied by the nature of the problem. Even with these con- then designed for each partition.
straints, there are many permutations of the operations. The minimum behav- Category-based partitioning categorizes class operations based on the ge-
ioral life history of an instance of account includes the following operations: neric function that each performs. For example, operations in the account
class can be categorized in initialization operations (open, setup), computational
summarize, and
termination operations (close).
658 PART FOUR: SOFTWARE ENGINEERING CHAPTER 22 TESTING 659
22.6 TEST CASE DESIGN 1. For client class, use the list of class operators to generate a series of
random test sequences. The operators will send messages other server
classes.
Test case design becomes more complicated as integration of the 00 system
begins. It is at this stage that testing of collaborations between classes must 2. For each message that is generated, determine the collaborator class and
begin. To illustrate inter-class test case generation we expand the the corresponding operator in the server object.
banking example introduced in Section 22.5 to include the classes and col- 3. For each operator in the server object (that has been invoked by mes-
laborations noted in Figure 22.2. The of the arrows in the figure in- sages sent from the client object), determine the messages that it trans-
dicates the direction of messages, and the labeling indicates the operations mits.
that are invoked as a consequence of the collaborations implied by the mes- 4. For each of determine the next level of operators that are in-
sages. voked and incorporate these into the test sequence.
Like the testing of individual classes, class collaboration testing can be ac-
complished by applying random and partitioning methods as well as To illustrate consider a sequence of operations for the bank class rel-
based testing and behavioral testing. ative to an ATM class (Figure 22.2):
22.6.1 Multiple Testing
Kirani and Tsai suggest the following sequence of steps to generate A random test case for the bank class he
multiple class random test cases:
Test case
In order to consider the collaboratorsinvolved in this test, the messages asso-
ciated with each of the operations noted in test case are considered. Bank
password must collaborate with to execute the and
deposit Bank must collaborate with account to execute Hence, a new test
withdraw case that exercises the collaborations noted above is:
terminate Test case
User ATM Bank "!")*(!+,-+#*,!+((&+.#!#/.!" depositReqe[de-
Interface !
1
The approach for class partition testing is similar to the approach
used for partition testing of individual classes. A single class is partitioned as
discussed in Section 22.5.2. However, the test sequence is expanded to include
those operations that are invoked via messages to collaborating classes. An al-
deauthorize ternative approach partitions tests based on the interfaces to a particular class.
balance
withdraw As shown in Figure 22.1, the bank class receives messages from the ATM and
cashier classes. The methods within bank can therefore be tested by parti-
tioning them into those that serve ATM and those that serve cashier.
based partitioning (Section can be used to refine the partitions further.
22.6.2 Tests Derived from Behavior Models
Cashier
In Chapter 20, we discussed the use of the state-transition diagram as a
model that represents the dynamic behavior of a class. The STD for a class
FIGURE 22.2. graph for a banking application be used to help derive a sequence of tests that will exercise the dynamic be-
660 PART FOUR: SOFTWARE ENGINEERING CHAPTER 22: OBJECT-ORIENTED TESTING
Still more test cases could be derived to ensure that all behaviors for the class
have been adequately exercised. In situations in which the class behavior re-
sults in a collaboration with one or more classes, multiple are used to
track the behavioral flow of the system.
The state model can be traversed in a “breadth first” manner. In
this context, breadth first implies that a test case exercises a single transition
deposit (initial)
and that when a new transition is to be tested only previously tested transi-
tions are used.
Consider the credit card object discussed in Section 22.2.2. The initial
state of credit card is undefined (i.e., no credit card number has been pro-
vided). Upon reading the credit card during a sale, the object takes on a de-
fined state, that is, the attributes card numberand expiration datealong
with bank-specific identifiers are defined. The credit ‘card is submitted when
withdraw it is sent for authorization, and it is approved when authorization is received.
The transition of credit cardfrom one state to another can be tested by de-
riving test cases that cause the transition to occur. A breadth first approach
to this type of testing would not exercise submitted before it exercised unde-
withdrawal (final) fined and defined. If it did, it would make use of transitions that had not been
previously tested and would therefore violate the breadth first criterion.
FIGURE 22.3.
State-transition dia- nonworking
2 2 . 7
gram for account close
The overall objective of object-oriented testing-to find the maximum number
of errors with a minimum amount effort-is identical to the objective of con-
ventional software testing. But the strategy and tactics for 00 testing differ
significantly. The view of testing broadens to include the review of both the
havior of the class (and those classes that collaborate with it). Figure 22.3 analysis and design model. In addition, the focus of testing moves away from
illustrates a STD for the account class discussed earlier. Referring to the procedural component (the module) and toward the class.
the figure, initial transitions move through the empty and setup states. Because the 00 analysis and design models and the resulting source
The majority of all behavior for instances of the class occurs while in the work- are semantically coupled, testing (in the form of formal technical reviews) begins
ing state. A final withdrawal and close cause the account class to make during these engineering activities. For this reason, a review of CRC, object-re-
transitions to the non-working and dead states, respectively, lationship, and object-behavior models can be viewed as first stage testing.
The tests to be designed should achieve state coverage That is Once OOP has been accomplished, unit testing is applied for each class.
the operation sequences should cause the account class to make transitiod Class testing uses a variety of methods: fault-based testing, random testing,
through all allowable states: and partition testing. Each of these methods exercises the operations encapsu-
lated by the class. Test sequences are designed to ensure that relevant opera-
test case tions are exercised. The state of the class, represented by the values of its at-
tributes, is examined to determine if errors exist.
Integration testing can be accomplished using a thread-based or use-based
It should be noted that this sequence is identical the minimum test sequence Thread-based testing integrates the set of classes that collaborate
discussed in Section 22.5.1. Adding addition test sequences to the minimum se- respond to one input or event. Use-based testing constructs the system in lay-
quence: ers, beginning with those classes that do not make use of server classes.
Integration test case design methods can also make use of random and parti-
tion tests. In addition, scenario-based testing and tests derived from behavioral
test
models can be used to test a class and its collaborators. A test sequence tracks
the flow of operations across class collaborations.
test case 00 system validation testing is black-box oriented and can be accom-
t plished by applying the same black-box methods discussed for conventional
662 PART FOUR OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER 22: OBJECT-ORIENTED TESTING
software. However, scenario-based testing dominates the validation of 00 sys- 22.10. Derive tests using methods noted in problems 22.6 and 22.7 for the e-mail
tems, making the use case a primary driver for validation testing. system considered in problem 21.15.
22.11. Derive tests using methods noted in problems 22.6 and 22.7 for the ATC sys-
tem considered in problem 21.16.
REFERENCES 22.12. Derive four additional tests using each of the methods noted in problems
22.6 and 22.7 for the banking application presented in Sections 22.5 and
S., “Using Use July 1995, pp. 22.6.
Berard, E.V., Essays Object-Oriented Software Engineering, Volume
Addison-Wesley, 1993. FURTHER READINGS -AND OTHER INFORMATION SOURCES
R.V., “Testing Object-Oriented Systems: A Status Report,
vol. 7, no. 4, April 1994, 23-28. The literature for object-oriented testing is only beginning to evolve. Jorgensen
Binder, R.V., “Object-Oriented Software Testing,” of the Testing: A Approach, CRC Press, and McGregor
no. 9, 1994, p. 29. and Sykes (Object-Oriented Software Development, Van Nostrand Reinhold,
and W.T. Specification and Verification of
1992) present chapters dedicated to the topic. Beizer (Black-Box Testing, Wiley,
Oriented Programs,” Technical Report TR 94-64, Computer Science 1995) discusses a variety of test case design methods that are appropriate in
Department, University of Minnesota, December, 1994. an 00 context. Binder (Testing Object-Oriented Systems, Addison-Wesley, 1996)
“Understanding Quality in Conceptual Modeling,” and (MAR941 present detailed treatments of 00 Testing. In addition,
IEEE no. 4, July 1994, pp. 42-49. many of the sources noted for Chapter 16 are generally applicable to 00
B., Prentice-Hall, 1994. testing.
and Object-Oriented Testing The September 1994 issue of Communications of the ACM is dedicated
ACM, vol. 37, no. 00 testing. It presents a number of worthwhile a paper8 and a combined bib-
9, 1994, 59-77. liography that cover8 a broad spectrum of research on 00 testing.
The Internet newsgroup comp.object has an occasional posting on 00
testing. Unfortunately, the FAQ for this newsgroup (although comprehensive
PROBLEMS AND POINTS TO PONDER in many respects) does not currently address 00 testing. Further discussion
of 00 testing issues can sometimes be found in and
22.1. In your own words, describe why the class is the smallest reasonable unit comp.testing.
for testing within an system. The following Web sites contain bibliographies and other information on
0 0 t e s t i n g :
22.2. Why do we have to retest subclasses that are instantiated from an existing
if
the cases designed for the class’!
Why should “testing” with the OOA and OOD activities?
22.4. Derive a set of CRC index cards for and conduct the steps noted
22.2.2 to determine if inconsistencies The following sites contain discussions of 00 testing:
22.5. What is the difference between thread-based and use-based strategies for in-
tegration testing? How does cluster testing fit in?
22.6. Apply random testing and partitioning to three classes defined in the design
for the system that you produced for problem 21.12. Produce test
cases that indicate the operation sequences that will be invoked.
22.7. Apply multiple class testing and tests derived from the behavioral model to
An up-to-date list of World Wide Web references for object-oriented testing
the design.
can be found at:
22.8. Derive tents using methods noted in and 22.7 for the PHTRS ,
in 12.13.
22.9. Derive tests using methods noted in Problems 22.6 and 22.7 for video
game considered in problem 21.14.
CHAPTER 23: TECHNICAL METRICS FOR SYSTEMS 665
!" to better understand the quality of the product
!" to assess the effectiveness of the process
!" to improve the quality of work performed at a project level
TECHNICAL METRICS FOR Each of these objectives is important, but for the software engineer, product
quality must be paramount. But how do we measure the quality of an 00 sys-
tem? What characteristics of the design model can be assessed to determine
OBJECT-ORIENTED
whether the system will be easy to implement, amenable to test, simple to mod-
ify, and most important, acceptable to end users? These questions are addressed
throughout the remainder of this chapter.
SYSTEMS 23.2 THE DISTINGUISHING CHARACTERISTICS
Metrics for any engineered product are governed by the unique characteristics of
the product. For example, it would be meaningless to compute miles per gallon for
an electric automobile. The metric is sound for conventional (i.e., gasoline pow-
ered) cars, but it does not apply when the mode of propulsion changes radically.
Object-oriented software is fundamentally different from software developed us-
ing conventional methods. For this reason, technical metrics for 00 systems must
E
be tuned to the characteristics that distinguish 00 from conventional software.
arly in this book we noted that measurement and metrics are key com-
Berard defines characteristics that lead to specialized met-
ponents of any engineering discipline-and object-oriented software engi-
rics: localization, encapsulation, information hiding, inheritance, and object ab-
neering is no exception. Sadly, the use of metrics for 00 systems has pro-
straction techniques. Each of these characteristics is discussed briefly in the
gressed much more slowly than the use of other 00 methods. Ed Berard
sections that follow.’
notes the irony of measurement when he states:
Software people seem to have a love-hate relationship with metrics. On one
hand, they despise and distrust anything that sounds or looks like a measure- 23.2.1 localization
ment. They are quick to point out the “flaws” in the arguments of anyone who
talks about measuring software products, software processes, and (especially) Localization is a characteristic of software that indicates the manner in which
software people. On the other hand, these same people seem to have no prob- information is concentrated within a program. For example, conventional meth-
lems identifying which programming language is the best, stupid things ods for functional decomposition localize information around functions, which
that managers do to “ruin” projects, and whose methodology works in what sit- are typically implemented as procedural modules. Data driven methods local-
uations. ize information around specific data structures. In the 00 context, information
is concentrated by encapsulating both data and process within the bounds of a
The “love-hate relationship” that Berard notes is real. And yet, as 00 systems class or object.
become more pervasive, it is essential that software engineers have quantita- Because conventional software emphasizes function as a localization mech-
tive mechanisms for assessing the quality of designs and the effectiveness of anism, software metrics have focused on the internal structure or complexity
00 programs. of functions module length, cohesion, or cyclomatic complexity) or the
manner in which functions connect (e.g., module coupling).
Since the class is the basic unit of an 00 system, localization is based on
23.1 THE INTENT OF OBJECT-ORIENTED METRICS objects. Therefore, metrics should apply to the class (object) as a complete
The primary objectives for object-oriented metrics are the same as those for
metrics derived for conventional software: ‘This discussion has been adapted from
664
CHAPTER 23: TECHNICAL METRICS FOR SYSTEMS 667
PART FOUR OBJECTORIENTED SOFTWARE ENGINEERING
In addition. the relationship between and classes is 23.2.5 Abstraction
not necessarily one-to-one. Therefore, metrics that reflect the manner in which
classes collaborate must be capable of accommodating one-to-many and Abstraction is a mechanism that enables the designer to focus on the essential
to-one relationships. details of a program component (either data or process) without concern for
lower-level details. As Berard states: “Abstraction is a relative concept. As we
move to higher levels of abstraction we ignore more and more details, i.e., we
provide a more general view of a concept or item. As we move to lower levels
23.2.2 Encapsulation of abstraction, we introduce more details, i.e., we provide a more specific view
of a concept or item.”
defines encapsulation as “the packaging (or binding together) Because a class is an abstraction that can be viewed at many different lev-
of a collection of items. Low-level examples of encapsulation conventional els of detail and in a number of different ways (e.g., as a list of operations, as
software] include records and arrays, land] subprograms (e.g., procedures, func- a sequence of states, as a series of collaborations), 00 metrics represent ab-
stractions in terms of measures of a class (e.g., number of instances per class
tions, subroutines, and paragraphs) are mid-level for
per application, number of parameterized classes per application, and ratio of
For 00 systems, encapsulation encompasses the responsibilities of a class, . parameterized classes to nonparameterized classes).
including its attributes (and other classes for aggregate objects) and operations,
and the states of the class, as defined by specific attribute values. 2 3 . 3 METRICS FOR THE 00 DESIGN MODEL
Encapsulation influences metrics by changing the focus of measurement
from a single module to a package of data (attributes) and processing modules
(operations). In addition, encapsulation encourages measurement at a higher There is much about object-oriented design that is subjective-an experienced
level of abstraction. For example, later in this chapter metrics associated with designer “knows” how to characterize an 00 system so that it will effectively
the number of operations per class will be introduced. Contrast this level of ab- implement customer requirements. But as 00 design models grow in size and
straction to conventional metrics, which focus on counts of Boolean conditions complexity, a more objective view of the characteristics of the design can
complexity) or lines of code. both the experienced designer (who gains additional insight) and the novice
(who obtains an indication of quality that would otherwise be unavailable).
An objective view of design should have a quantitative component-and
that leads to 00 metrics. In reality, technical metrics for 00 systems can be
23.2.3 Information hiding applied not only to the design model, but also to the analysis model. In the sec-
tions that follow, we explore metrics that provide an indication of quality at the
00 class level and the operation level as well as metrics that are applicable for
Information hiding suppresses (or hides) the operational details of a program project management and testing.
component. information necessary to access the component is pro-
vided to those other components that wish to access it.
A well-designed 00 system should encourage information hiding. Therefore, 23.4 CLASS-ORIENTEDMETRICS
metrics that provide an indication of the degree to which hiding has been
achieved should provide an indication of the quality of the 00 design. The class is the fundamental unit of an 00 system. Therefore, measures and
metrics for an individual class, the class hierarchy, and class collaborations will
be invaluable to a software engineer who must assess design quality. In earlier
chapters we have seen that the class encapsulates operations (processing) and
Inheritance attributes (data). The class is often the “parent” for subclasses (sometimes
called “children”) that inherit its attributes and operations. The class often col-
Inheritance is a mechanism that enables the responsibilities of one object to be laborates with other classes. Each of these characteristics can be used as the
propagated to other objects. Inheritance occurs throughout all levels of a class basis for measurement.
hierarchy. In general, conventional software does not support this character-
istic.
Because inheritance is a pivotal characteristic in many 00 systems, many 23.4.1 The CK Metrics Suite
00 metrics focus on it. Examples (discussed later in this chapter) include num-
ber of children (number of immediate instances of a class), number of parents
(number of immediate generalizations), and class hierarchy nesting level (depth One of the most widely referenced sets of 00 software metrics has been pro-
of a class in an inheritance hierarchy). posed by Chidamber and Kemerer The authors have proposed six
PART FOUR: OBJECTORIENTED SOFTWARE ENGINEERING 669
CHAPTER 23: TECHNICAL METRICS FOR OBJECTORIENTED SYSTEMS
class-based design metrics referred to as the metrics suite) for 00
Weighted Methods per Class Assume that methods of complexity
. , arc defined for a class The specific complexity metric that is cho-
sen (e.g., cyclomatic complexity) should be normalized so that
plexity for a method takes on a value of
The number of methods and their complexity is a reasonable indicator of
the amount of effort required to implement and test a class. In addition, the
larger the number of methods, the complex the inheritance tree (all sub-
classes inherit the methods of their parents). Finally, as the number of meth-
ods grows for a given class, it is likely to become more and more application
specific, thereby limiting potential reuse. For all of these reasons, WMC should
be kept as low as is reasonable,
Although it would seem relatively straightforward to develop a count for
the number of methods in a class, the problem is actually more complex than
it seems. and discuss this issue when they write:
In order to count methods, we must answer the fundamental question “Does
method belong only to the class which defines it, or does it also belong to every
class which inherits it directly or indirectly?” Questions such as this may seem
trivial since the run-time will ultimately resolve them. However, the im-
plications for metrics may be significant.
One possibility is to restrict counting to the current class, ignoring inher- FIGURE 23.1. A
class hierarchy
ited members. The motivation for this would be that inherited members have
already been counted in the classes where they are defined, so the class incre-
ment is the best measure of its functionality-what it does reflects its reason Like most counting conventions in software metrics, any of the approaches out-
for existing. In order to understand what a class does, the most important lined above are acceptable, as long as the counting approach is applied
source of information is its own operations. If a class cannot respond to a mes- whenever metrics are collected.
sage (i.e., it lacks a corresponding method of its own) then it will pass the mes- I---
sage on to its parent(s).
Depth of the inheritance Tree This metric is defined as “the maximum
At the other extreme, counting could include all methods defined in the
current class, together with all inherited methods. This approach emphasizes length from the node to the root of the tree.” In Figure 23.1, the value
of DIT for the class hierarchy shown is 4.
the importance of thr state space, the class increment, in under-
As DIT grows, it is likely that lower-level classes will inherit many meth-
standing a class.
ods. This leads to potential difficulties when attempting to predict the behav-
Between these extremes lie a number of other possibilities. For example,
ior of a class. A deep class hierarchy (DIT is large) also leads to greater design
one could restrict counting to the current class and members inherited directly
complexity. On the positive side, large DIT values imply that many methods
from parent(s). This approach would be based on the argument that the spe-
may be reused.
cialization of parent-classes is the most directly relevant to the behavior of a
child class.
Number of Children (NOC) The subclasses that are immediately subordinate to
a class in the class hierarchy are termed its In Figure 23.1, class
has three children-subclasses and
As the number of children grows, reuse increases, but it is also true that
and the term thnn of the as NOC increases, the abstraction represented by the parent class can be di-
term in in this
luted. That is, there is a possibility that some of the children are not really
CHAPTER 23: TECHNICAL METRICS FOR SYSTEMS
670 PART SOFTWARE ENGINEERING 671
amine coupling and reuse. A sampling of metrics proposed by Lorenz and
members of the parent class. As NOC increases, the amount of test-
Kidd
ing (required to exercise each child in its operational context) will also in-
crease).
Size The overall size of a class can be determined using the follow-
ing measures:
Coupling Classes (CBO) The CRC model (Chapter may be
used to determine the value for CBO. In essence, CBO is the number of col-
laborations listed for a class on its CRC index card. !" the total number of operations (both inherited and private instance opera-
As CBO increases, it is likely that the reusability of a class will decrease. tions) that are encapsulated within the class
High values of CBO also complicate modifications and the testing that ensues !" the number of attributes (both inherited and private instance attributes) that
when modifications are made. In general, the CBO values for each class should are encapsulated by the class
be kept as low as is reasonable. This is consistent with the general guideline
to reduce coupling in conventional software. The WMC metric proposed by Chidamber and Kemerer (Section 23.4.1) is also
a weighted measure of class size.
Response for a Class (RFC) The response set of a class is “a set of methods that As we noted earlier, large values for CS indicate that a class may have too
can potentially be executed in response to a message received by an object of much responsibility, which will reduce the reusability of the class and compli-
that class” RFC is defined as the number of methods in the response cate implementation and testing. In general, inherited or public operations and
set. attributes should be weighted more heavily in determining class size
As RFC increases, the effort required for testing also increases because the Private operations and attributes enable’specialization and are more localized
test sequence (Chapter 22) grows. It also follows that as RFC increases, the in the design.
overall design complexity of the class increases. Averages for the number of class attributes and operations may be
computed. The lower the average value for size, the more likely that classes
of Cohesion in Methods Each method within a class, C, accesses within the system can be reused widely.
one or more attributes (also called instance variables) LCOM is the number of
methods that access one or more of the same If no methods access Number of Operations Overridden by a Subclass (NOO) There are instances
the same attributes, then LCOM is 0. when a subclass replaces an operation inherited from its superclass with a spe-
To illustrate the case where 0, consider a class with 6 methods. cialized version for its own use, this is called overriding. Large values for
Four of the methods have one or more attributes in common (i.e., they access generally indicate a design problem. As Lorenz and Kidd point out:
common attributes). Therefore, LCOM = 4.
If LCOM is high, methods may be coupled to one another via attributes. Since a subclass should be a specialization of its superclasses, it should pri-
This increases the complexity of the class design. In general, high values for marily extend the services of the superclasses. This should result
LCOM imply-that the class might be better designed by breaking it into two in unique n e w m e t h o d n a m e s .
or more separate classes. Although there are cases in which a high value for
LCOM is justifiable, it is desirable to keep cohesion high, i.e., keep LCOM If is large, the designer has violated the abstraction implied by the su-
low. perclass. This results in a weak class hierarchy and 00 software that can be
difficult to test and modify.
23.4.2 Metrics Proposed by and Kidd Number of Operations Added by o Subclass Subclasses are specialized by
adding private operations and attributes. As the value for increases, the
subclass drifts away from the abstraction implied by the superclass. In general,
In their book on 00 metrics, Lorenz and Kidd divide class-based as the depth of the class hierarchy increases becomes large), the value for
metrics into four broad categories: size, inheritance, internals, and externals. at lower levels in the hierarchy should go down,
Size-oriented metrics for the 00 class focus on of attributes and
erations for an individual class and average values for the 00 system as a
whole. Inheritance-based metrics focus on the manner in which operations Index
Specialization The specialization index provides a rough indication
of the degree of specialization for each of the subclasses in an 00 system.
are reused throughout the class hierarchy. Metrics for class internals look at
cohesion (Section 23.4.1) and code-oriented issues, and external metrics
“For a complete discussion, see
formal definition is bit complex. See for details.
672 PART FOUR: OBJECT-ORIENTED SOFTWARE ENGINEERING CHAPTER 23: TECHNICAL METRICS FOR SYSTEMS 673
Specialization can be achieved by adding or deleting operations or by Encapsulation
riding. The higher the value of LCOM, the
Lack of cohesion in methods
SI = X more states must be tested to ensure that methods do not generate side
effects.
where is the level in the class hierarchy at which the class resides and
Percent public and protected (PAP) Public attributes are inherited from
is the total number of methods for the class. The higher the value of
other classes and are therefore visible to those classes. Protected attributes
the more likely that the class hierarchy has classes that do not conform to the
are a specialization and are private to a subclass. This metric
superclass abstraction. the percentage of class attributes that are public. High values for
PAP increase the likelihood of side affects among classes. Tests must be de-
signed to ensure that such side effects are uncovered.
23.5 OPERATION-ORIENTED METRICS
P u b l i c a c c e s s t o d a t a m e m b e r s ( P A D ) This metric indicates the number of
(or methods) that cnn another a violation
Because the class is the dominant unit in systems, there have been fewer of encapsulation. High values for PAD lead to the potential for side effects
metrics proposed for class operations. and Shepperd discuss among classes. Tests must be designed to ensure that such side effects are
this when they state: uncovered.
Results of recent studies indicate that methods tend to be small, both in terms Inheritance
of number of statements and in logical complexity suggesting that
connectivity structure of a system may be more important than the content of Number of root classes (NOR) is a count of the distinct class hi-
individual modules. erarchies that are described in the design model. Test suites for each root
class and the corresponding class hierarchy must be developed. As NOR in-
creases, testing effort also increases.
There are, however, some insights that can be gained by examining average
characteristics for class operations. Three simple metrics, proposed by F a n i n ( F I N ) When used in the 00 context, fan-in is an indication of mul-
and Kidd are noted below: tiple inheritance. FIN 1 indicates that a class inherits its attributes and
operations from more than one root class. FIN 1 should be avoided when
Average operation size (OS,) Although lines of code could be used as an possible.
indicator for operation size, the LOC measure suffers from all of the prob- Number of children and depth of the inheritance tree we dis-
lems discussed in Chapter 4. For this reason, the number of messages sent cussed in Chapter 22, superclass methods will have to be retested for each
by the operation provides an alternative for operation size. As the number subclass.
of messages sent by a single operation increases, it is likely that responsi-
bilities have pot been well allocated within a class. In addition to the above Binder [BIN941 also defines metrics for class
The complexity of an operation can be computed complexity and polymorphism. The metrics defined for class complexity include
using any of the complexity metrics (Chapter proposed for three CK metrics (Section 23.4.1): weighted methods per class coupling
software Because operations should be limited to a specific re- between object classes and response for a class In addition, met-
sponsibility, the designer should strive to keep OC as low as possible. rics associated with method counts are also defined. The metrics associated
with polymorphism are highly specialized. A discussion of them is best to
Average number of parameters per opemtion The larger the number
Binder.
of operation parameters, the more complex the collaboration between ob-
jects. In general, should be kept as low as possible.
23.7 METRICS FOR OBJECT-ORIENTED PROJECTS
23.6 METRICS FOR OBJECT-ORIENTED TESTING
As we discovered in Part Two of this book, the job of the project manager is to
The design metrics noted in Sections 23.4 and 23.5 provide an indication of plan, coordinate, track, and control a’software project. In Chapter 19 we
also provide a general indication of the amount of testing
to exercise an 00 system.
Binder [BIN941 suggests a broad array of design metrics that have a direct
influence on the “testability” of an 00 system. The metrics are organized into
categories that
674 PART FOUR: SOFTWARE ENGINEERING CHAP TER 23 FOR
675
cussed some of the special issues associated with project management for 00 localization, encapsulation, information hiding, inheritance, and object ab-
projects. But what about measurement? Are there specialized 00 metrics that straction techniques-that make the class unique.
can be used by the project manager to provide additional insight into progress? The CK metrics suite six class-oriented software metrics that focus
The answer, of course, is on the class and the class hierarchy. The metrics suite also develops metrics to
The first activity performed by the project manager is planning, and one of the collaborations between and the cohesion of methods that re-
the early planning-tasks is estimation. Recall the evolutionary process model,’ side within a class. At a class-oriented can
where planning is revisited after each iteration of the software. Therefore, the with metrics proposed by and include measures of
plan and its project estimates are each iteration of OOA, OOD, class “size” and metrics that provide insight into the degree of specialization
and even OOP. for subclasses.
One of the key issues facing a project manager during planning is an esti- Operation-oriented metrics focus on the size and complexity of individual
mate of the implemented size of the software. Size is directly proportional to operations. It is important to note, however, that the primary thrust for 00 de-
effort and duration. The following 00 metrics can provide insight into sign metrics is at the class level.
software size: A variety of metrics to assess the testability
of on class
Number of scenario scripts (NSS) The number of scenario scripts or use and polymorphism.
cases (Chapter 20) is directly proportional to the number of classes re- characteristics the analysis and design model can assist the
quired to meet requirements, the number of states for each class, and the project manager for an 00 system in planning and tracking activities. The
number of methods, attributes, and collaborations. NSS is a strong indica- number of scenario scripts (use cases), classes, and subsystems all
tor for program size. information about the of effort required to implement a system,
N u m b e r of k e y c l a s s e s ( N K C ) A key class focuses directly on the business
domain for the problem and will have a lower probability of being imple-
mented via For this reason, high values for NKC indicate substan- REFERENCES
tial development work lies ahead. Lorenz and Kidd suggest that
between 20 and 40 percent of all classes in a typical 00 system are key
classes. The remainder support infrastructure (GUI, communications, data- Berard, E., “Metrics for Object-Oriented Software Engineering,” an
Internet posting on January 28, 1995.
bases, etc.).
Binder, Systems: A Status
Number of subsystems (NSUB) The number of subsystems provides insight 7. 4. April 1994, 22-29.
into resource allocation, scheduling particular emphasis on parallel ‘A Metrics Suite Object-Oriented
development), and overall integration effort. Software 20, no. 6, June 1994, pp.
476493.
The metrics NSS, NKC, and NSUB can be collected for past 00 and M.J. “Towards a Conceptual Framework
and related to the effort expended on the project as a whole and on individual for Object-Oriented Metrics,” ACM Engineering Notes, vol. 20,
process activities (e.g., OOA, OOD, OOP, and These data can also be used no. 2, April 1995, pp. 69-76.
along with design metrics discussed earlier in this chapter to compute “pro- \ Lorenz, M., and J. Kidd, Metrics, Prentice-Hall,
ductivity metrics” such as average number of per developer or average 1994.
methods per person-month. Collectively, these metrics can be used estimate Wilde, N., and Huitt, “Maintaining Object-Oriented Software,”
effort, duration, and other project information for the current project. January 1993, pp.
H., and Methods, New
York, 1990.
23.8 SUMMARY
Object-oriented software is fundamentally different from software developed PROBLEMS AND POINTS TO PONDER
using conventional methods. Therefore, the metrics for 00 systems focus
metrics that can be applied to the class and the design
23.1. Review the metrics presented in this chapter and in Chapter 18. How would
you characterize the syntactic and semantic differences between metrics for
evolutionary process model is most appropriate for 00 systems Chapters 2 and 19). conventional and 00 software?
will only until robust library of reusable components is developed for a par- 23.2. How does localization affect metrics developed for conventional and 00 soft-
ticulardomain. ware?
676 PART FOUR: OBJECTORIENTED SOFTWARE CHAPTER 23: TECHNICAL FOR OBJECTORIENTED SYSTEMS 677
23.3. Why isn’t more emphasis given to 00 metrics that address the specific char- metrics, but few address the subject in any detail. Books by Jacobson
acteristics of operations within a class? Oriented Software Engineering, Addison-Wesley, 1994) and Graham (Object-
33.4. Review the metrics discussed in this chapter and suggest a few that directly Oriented Methods, Addison-Wesley, 2nd edition, 1993) provide more treatment
or indirectly address information hiding. than most.
Lorenz and Kidd and (Object-Oriented Metrics:
23.6. Review the metrics discussed in this chapter and suggest a few that directly
or indirectly address abstraction. Measures of Complexity, Prentice-Hall, 1996) offer the only books dedicated to
00 metrics published to date. (Encyclopedia Engineering,
23.6. A class, X, has 12 operations. Cyclomatic complexity has been computed for J. Marciniak Wiley, 1994) has contributed a chapter on 00 metrics. Other
in the 00 system, and the average value of module complex- books dedicated to conventional software metrics (see “Further Readings and
ity is 4. For class X the complexity for operations 1 to 12 is 3, 8, 2, Other Information Sources” for Chapters 4 and 18) contain limited discussions
2, 5, 5, 4, 4, respectively. Compute WMC. of 00 metrics.
23.7. Referring to Figure and b, compute the value of DIT for each inheri- The majority of information on 00 metrics must be obtained papers
tance tree. What is the value of NOC for the class X2 for both trees? and articles published in the technical literature. Whitty (Object-Oriented
23.8. Refer to and present a one page discussion for the formal definition Metrics: People and Publications, 1995) has compiled one of the most compre-
of the LCOM metric. hensive object-oriented metrics bibliographies published to date. An electronic
23.9. In Figure 19.85, what is the value of for classes X3 and X4. version may be obtained from:
23.10. Referring Figure assume that four operations have been overrid-
den in the inheritance tree (class hierarchy), what is the value of SI for the
hierarchy?
23.11. A software team has completed five projects to date. The following data have’ The Internet sources noted throughout Part Four of this book are worth inves-
been collected for all size projects: tigating for discussions of 00 metrics. In addition, occasional discussions of 00
metrics are found in the Internet newsgroups comp.object,
eng, and comp.testing.
Project NKC Effort (days) Additional information on 00 metrics can be found at the following sites:
1 34 3 900
2 55 75 6 1575
3 122 260 8 4420
4 45 66 2 990
5 80 124 6 2480
A new in the early of OOA. It in that 96 use An up-to-date of World Wide Web reference8 for object-oriented metrics
will be developed for the project. Estimate: can be found at:
a. the total number of classes that will be required to implement the system;
b. the total amount of effort required to implement the system.
23.12. Your instructor will provide you with a list 00 metrics from this chapter,
Compute the values of these metrics for one or more of the problems noted
below:
a. the design model for the design,
b. the design model for the for the PHTRS system described in problem
12.13.
c. the design model for the video game considered in problem
d. the design model for the e-mail considered in problem 21.15.
the design model for the ATC system considered in problem
FURTHER READINGS AND OTHER INFORMATION SOURCES
A variety of books on OOA, OOD, and OOT (see “Further Readings and Other
Information Sources” in Chapters and make passing reference to 00
ADVANCED TOPICS
SOFTWARE
ENGINEERING
In this part of Software Engineering: A Practitioner’s Approach we consider a number of advanced
topics that extend your understanding of software engineering. In the chapters that follow, we
address the following questions:
!" What are ‘formal methods’ and how are they used to specify software?
!" What notation and mathematical preliminaries are required to formally describe software?
How does the cleanroom software engineering approach differ from conventional approaches?
. What are the key technical activities that are conducted during the cleanroom process?
!"How is domain engineering used as a precursor to building libraries of reusable compononta?
What technical issues must be considered when a reuse process is initiated?
What are the economic arguments that favor reuse?
!" What is business process and how does it set the stage for reengineering?
!" What are the key technical activities required for software reengineering?
!" How does the client/server architecture impact the way in which software is engineered?
!" What are the architectural options for establishing a CASE tools environment?
!" What are the future directions of software engineering?
Once these questions are answered, you’ll understand topics that may have a profound impact on
software engineering over the next decade.
FORMAL METHODS
S engineering methods can be categorized on a “formality” spectrum.
The analysis and design methods discussed earlier in this book would be
placed at the informal to moderately rigorous end of the spectrum. A combina-
tion of diagrams, text, tables, and simple notation is used to create analysis and
design models.
We now consider the other end of the formality spectrum. Here, a specifi-
cation and design are described using a formal syntax and semantics that spec-
ify system function and behavior. A formal specification is mathematical in
form (e.g., predicate calculus can be used as the basis for a formal specification
language).
In his introductory discussion of formal methods, Anthony Hall
states:
Formal methods are controversial. Their advocates claim that they can revolu-
tionize development. Their detractors think they are impossibly dif-
ficult. Meanwhile, for most people, formal methods are so unfamiliar that it is
to judge the competing claims.
In this chapter, we explore formal methods and examine their potential impact
on software engineering in the years to come.
24.1 BASIC CONCEPTS
The Encyclopedia of Software Engineering formal methods in
the following manner:
PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 2.4 FORMAL METHODS 683
Formal methods used in developing computer systems are mathematically Contradictions are sets of statements that are at variance with each other.
based techniques for describing system properties. Such formal methods pro- For example, one part of a system specification may state that the system must
vide frameworks within which people can specify, develop, and verify systems monitor all the temperatures in a chemical reactor while another part, perhaps
in a systematic, rather than ad hoc manner. written by another staff member, may state that only temperatures occurring
A method is formal if it has a sound mathematical basis, typically given by within a certain range are to be monitored. Normally contradictions that occur
a formal specification language. This basis provides a means of precisely defin- on the same page of a system specification can be detected easily, However, con-
ing notions like consistency and and, more relevant, specifica- tradictions are often separated by a large number of pages.
tion, implementation, and correctness. Ambiguities are statements that can be interpreted in a number of ways.
For example, the following statement is ambiguous:
The desired properties of a formal specification-lack of
tency, and completeness-are the objectives of all specification methods. The operator identity consists of the operator name and password; the pass-
However, the use of formal methods results in a much higher likelihood of word consists of six digits. It should be displayed on the security and de-
achieving these ideals. The formal syntax of a specification language (Section posited in the when an operator logs into the system.
24.4) enables requirements or design to be interpreted in only one way, elimi-
nating ambiguity that often occurs when a natural language (e.g., English) or In this extract, does the word “it” refer to the password or the operator identity?
a graphical notation must be interpreted by a reader. The descriptive facilities Vagueness often occurs because a system specification is a very bulky doc-
of set theory and logic notation (Section 24.2) enable a clear statement of facts ument. Achieving a high level of precision consistently is an almost impossible
(requirements). To be consistent, facts stated in one place in a specification task. It can lead to statements such as “the interface to the system used by
should not be contradicted in another place. Consistency is ensured by mathe- radar operators should be user friendly,” or “the virtual interface shall be based
matically proving that initial facts can be formally mapped (using inference on simple overall concepts which are straightforward to understand and use
rules) into later statements within the specification. and which are few in number.” A casual perusal of these statements might not
Completeness is difficult to achieve, even when formal methods are used. detect the underlying lack of any useful information.
Some aspects of a system may be left undefined as the specification is being Incompleteness is probably one of the most frequently occurring problems
created; other characteristics may be purposely omitted to allow designers with system specifications. For example, consider the functional requirement
some freedom in choosing an implementation approach; and it is impossible to
consider every operational scenario in a large, complex system. Things may The system should maintain the hourly level of the reservoir from depth sen-
simply be omitted by mistake. sors situated in the reservoir. These values should be stored for the past six
Although the formalism provided by mathematics has an appeal to some months.
software engineers, others (some would say, the majority) look askance at a
mathematical view of software development. To understand why a formal ap This describes the main data storage of a system. Suppose one of the com-
has merit, we must first consider the deficiencies associated with less mands for the system is
formal approaches.
The function of the AVERAGE command is to display on a PC the average wa-
ter level for a particular sensor between two dates.
24.1 Deficiencies of Formal Approaches’ Assuming that no more detail was presented for this command, the details of
the command would be seriously incomplete. For example, the description of
The methods discussed for analysis and design in Parts Three and Four of this the command does not include what should happen if a user of a system spec-
book made heavy use of natural language and a variety of graphical notations. ifies a date that was more than six months before the current one.
Although careful application of analysis and design methods coupled with Mixed levelsof abstraction occur when very abstract statements are inter-
thorough review can and does lead to high-quality software, sloppiness in the mixed randomly with statements that are at a much lower level of detail. For
application methods can create a variety of problems. A system example, statements such as
specificationcan contain contradictions, ambiguities, vagueness, incomplete
statements, and mixed levels of abstraction. The purpose of the system is to track the stock in a warehouse.
might be intermixed with
section and others in the first part of this chapter have been adapted from work con-
tributed by for the European version of the third edition of Engineering: When the loading clerk types in the withdraw command he or she will com-
A Approach. municate the order number, the identity of the item to be removed, and the
PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 24: METHODS
quantity removed. The system will respond with a confirmation that the sign directives, implementation directives, and project constraints intruding. It
is allowable. also helps the designer, because the system design specification exhibits the
properties of a model, providing only sufficient details to enable the task in
Although such statements are important in a system specification, specifiers hand to be carried out.
often manage to intermix them to such an extent that it becomes very difficult The final point to make about mathematics as a software development
to see the overall functional architecture of a system. medium is that it provides a high level of validation. It is possible to use a
Each of these problems is more common that we would like to believe. And mathematical proof to demonstrate that a design matches a specification, and
each represents a potential deficiency in conventional and object-oriented meth- that some program code is a correct reflection of a design.
ods for specification.
Formal Methods
24.1.2 Mathematics in Software Development
The aim of this section is to present the main concepts involved in the math-
Mathematics has many useful properties for the developers of large systems. ematical specification of software systems, without encumbering the reader
One of its most useful properties is that it is capable of succinctly and exactly with too much mathematical detail, To accomplish this, we a few simple
describing a physical situation, an object, or the outcome of an action. When an examples:
applied mathematician states that the solution to a particular equation is given
by the integral E x a m p l e 1 : A S y m b o l T a b l e A program is used to maintain a symbol table. Such
a table is used frequently in many different types of applications. It consists of
tan + a collection of items without any duplication. An example of a typical symbol
there is no argument about semantics. The person who solves the integral table is shown in Figure 24.1. It represents the table used by an operating sys-
knows exactly what is required, although how to solve the integral may take a tem to hold the names of the users of the system. Other examples of tables in-
large amount of effort. For example, the integral may be amenable to an ana- clude the collection of names of staff in a payroll system, the collection of names
lytical solution, or it may require simulation or another if of computers in a network communications system, and the collection of desti-
the upper and lower limits to the integral are known. Ideally, the software de- nations in a system for producing railway timetables.
veloper should be in the same position as the applied mathematician. A math- Assume that the table presented in this example consists of no more than
ematical specification of a system should be presented to him her, and a so- members of staff. This statement, which a constraint on the
lution developed in terms of a software architecture that implements the table, is a component of a condition known as a data invariant-an important
specification should be idea which we shall return to throughout this chapter.
Another advantage of using mathematics in the software process is that it
provides a smooth transition between software engineering activities. Not only
functional specifications but also system designs can be expressed in mathe-
Wilson
matics, and, of course, the program code is a mathematical notation-albeit a
rather long-winded one. 2. Simpson
The major property of mathematics is that it supports abstraction and is
an excellent medium for modeling. it is an exact medium there is lit- 3 . A b e l
tle possibility of ambiguity, specifications can be mathematically validated to 4.
uncover contradictions and incompleteness, and vagueness disappears
pletely. In addition mathematics can be used to represent levels of abstraction
in a system specification in an organized way. = 10
Mathematics is an ideal tool for modeling. It enables the bare bones of a
specification to be exhibited and helps the analyst and system specifier to val-
idate a specification for functionality without such issues as response time,
FIGURE24.1.
word of caution is appropriate at this point. The mathematical system specifications that
are presented in this chapter will not be succinct the integral. Software systems A symbol table used
complex, and it would be unrealistic to expect that they could be specified in one line for an operating I
of mathematics. system
686 PART FIVE. ADVANCED TOPICS SOFTWARE ENGINEERING CHAPTER 24. FORMAL METHODS 687
A invariant is a condition that is true throughout the execution of the Unused blocks
system that contains a collection of data. The data invariant that holds for the
symbol table discussed above has two components: that the table will con- 1 3 4 6 9 ’ Used blocks
tain no more than names and that there will be no duplicate names
in the table. In the case of the symbol table program described above, this
means that, no matter when the symbol table is examined during execution of
the system, it will always contain no more than staff identifiers and
.
will contain no duplicates.
Another concept that is important is that of a state. In the context of for-
mal a state is the stored data which a system accesses and alters. In
the example of the symbol table program, the state is the symbol table. Blocks are released
The final concept is that of an operation. This is an action that takes place
to queue when files
in a system and reads or writes data to a state. If the symbol table program is
Queued for entry into unused blocks are deleted
concerned with adding and removing staff names from the symbol table,’ then
it will be associated with two operations: an operation to add a specified name
to the symbol table and an operation to remove an existing name from the
table. If the provides the facility to check whether a specific name was
contained in the table, then there would be an operation that would return
some indication of whether the name was in the table.
An operation is associated with two conditions: a precondition and a FIGURE 24.2. File File File
condition. A preconditiondefines the circumstances in which a particular op- A block handler Block queue containing blocks from deleted files
eration is valid. For example, the precondition for an operation that adds a
name to the staff identifier symbol table is valid only if the name that is to be
added is not contained in the table and there are fewer than iden- For this subsystem the state is the collection of free blocks, the collection
tifiers in the table. The postconditionof an operation defines what happens of used blocks, and the queue of returned blocks. The data invariant, expressed
when an operation has completed its action. This is defined by its effect on the in natural language, is:
state. In the example of an operation that adds an identifier to the staff iden-
tifier symbol table, the postcondition would that the !" No block will be marked as both unused and used.
table has been augmented with the new identifier.
All the sets of blocks held in the queue will be subsets of the collection of cur-
rently used blocks.
Example 2: A Black Handler One of the more important parts of an operating
system is the subsystem that maintains files that have been created by users. There will be no elements of the queue that will contain the same block
Part of the filing subsystem is the block handler: Files in the file store are com-
posed of blocks of storage that are held on a tile storage device. During the op- The collection of used and blocks that are unused will be the total col-
eration of the computer, files will be created and deleted, requiring the acqui- lection of blocks that make up tiles.
sition and release of blocks of storage. In order to cope with this, the filing There will be no duplicate block numbers in the collection of unused blocks.
subsystem will maintain a reservoir of unused blocks and will also keep track
There will be no duplicate block numbers in the collection of used blocks.
of blocks that are currently in use. When blocks are released from a deleted
file they are normally added to a queue of blocks waiting to be added to the
reservoir of unused blocks. This is shown in Figure 24.2. In this figure a num- Some of the operations associated with this subsystem are:
ber of components are shown: the reservoir of unused blocks, the blocks that
currently make up the files administered by the operating system, and those !" An operation that adds a collection of blocks to the end of the queue
blocks that are waiting to be added to the reservoir. The waiting blocks are !" An operation that removes a collection of used blocks from the front of the
held in a queue, with each element of the queue containing a set of blocks from queue and places them in the collection of unused blocks
a deleted file. . An operation that checks whether the queue of blocks is empty
The precondition of the first operation is that the blocks to be added must be
that the term ‘state” has also been used in Chapters 12 and 20 as a representation of in the collection of used blocks. The postcondition is that the collection of blocks
the behavior of a system or objects. must be added to the end of the queue,
688 , PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 24: FORMAL METHODS
The precondition of the second operation is that the queue must have at which has a print limit of 750 lines, has two files, and persons,
least one item in it. The postcondition is that the blocks must be added to the awaiting printing, and that the size of the tiles are 650 lines and 700 lines,
collection of unused blocks. respectively.
The operation-checking whether the queue of returned blocks is The state of the spooler is represented by the four components Queues,
empty-has no precondition. This means that the operation is always defined, Limits, and Sizes. The data invariant has five components:
regardless of what value the state has. The postcondition delivers the value
true if the queue is empty and false otherwise. !"Each output device is associated with an upper limit of print lines.
!" Each output device is associated with a possibly queue of files
Example 3: A Print Spooler In multitasking operating systems, a number of
awaiting printing.
tasks make requests to print files. Often, there are not enough printing devices
!" Each tile is associated with a size.
to satisfy all current print requests simultaneously. Any print request that can-
not be immediately satisfied is placed in a queue awaiting printing. The part !" Each queue associated with an output device contains tiles that have a size
of an operating system that deals with the administration of such queues is smaller than the upper limit of the output device.
known as print spooler !" There will be no more than output devices administered by the
In this example we assume that the operating system can employ no more spooler.
than output devices and that each device has a queue associated with
it. We will also assume that each device is associated with a limit of lines in a A number of operations can be associated with the spooler. For example:
file which it will print. example, an output device that of 1000
lines of prinling will be with a queue that contains only files having
no more than 1000 lines of text. Print spoolers sometimes impose this con- !" An operation which adds a new output device to the spooler together with its
straint in order to forbid large printing jobs, which may occupy slow printing associated print limit
devices for exceptionally long periods. A schematic representation of a print !" An operation which removes a file from the queue associated with a partic-
spooler is shown in Figure 24.3. ular output device
As shown in the figure, the spooler state consists of four components: the !" An operation which adds a file to the queue associated with a particular out-
queues of tiles waiting to be printed, each queue being associated with a par- put device
ticular output device; the collection of output devices controlled by the spooler; !" An operation which alters the upper limit of print for a particular out-
the relationship between the output devices and the maximum file size that
put device
each can print; and the relationship the files awaiting printing and
!" An operation which moves a file from a queue associated with an output de-
their size in lines. For example, Figure 24.3 shows that the output device
vice to another queue associated with a second output device
Each of these operations corresponds to a function of the spooler. For example,
Device queues files printing the first operation would correspond to the spooler being notified of a new de-
vice.
ftax persons As before, each operation is associated with a precondition and a
For example, the precondition for the first operation is that the output
LP2 device name does not already exist and that there are currently less than
LAS1 output devices known to the spooler. The postcondition is that the
name of the new device is added to the collection of existing device names, a
new entry is formed for the device with no files being associated with its queue,
and the device is associated with its print limit.
The precondition for the second operation (removing a tile from a queue as-
sociated with a particular output device) is that the device is known the
Limits
spooler and that there is at least one entry in the queue associated with the
device. The postcondition is that the head of the queue associated with the
out device is removed and its entry in the part of the spooler that keeps tracks
file sizes is deleted.
The precondition for the operation described above (moving a file from
FIGURE 24.3. a queue associated with an output device to another queue associated with a
A print spooler second output device) is:
PART FIVE ADVANCED IN ENGINEERING CHAPTER 24 METHODS 691
!" The output device is known to the spooler. is to create a constructive set specification. The general form of the mem-
!" The second output device is known to the spooler. bers of a set is specified using a Boolean expression. Constructive set specifica-
tion is preferable to enumeration because it enables a succinct definition of large
!" The queue associated with the device contains the file to be moved. sets. It also explicitly defines the rule that was used in constructing the set.
!" The size of the tile is less or equal to the print limit associated with the sec- Consider the following constructive specification example:
ond output device.
The postcondition is that the file is removed-from one queue and added to an- This specification has three components, a : , a predicate, 3, and
other queue. term, The specifies the range of values that will be considered when
In each of the examples noted in this section, we have introduced the key forming the set, the Boolean expression1 defines how the set is to be
concepts of formal specification. This has been done without emphasizing the constructed, and, finally, the term gives the general form of the item of the set. In
mathematics that are required to make the formal. In the next the example above, stands for the natural numbers; thus, natural numbers are
section we consider these mathematics. to be considered, the predicate indicates that only natural numbers less than 3
are to be included, and the terms specifies that each element of the set will be of
the form Thus, the specification above defines the set:
24.2 MATHEMATICAL
IO,
To apply formal methods effectively, the software engineer must have an work- When the form of the elements of a set is obvious, the term can be omitted. For
ing knowledge of the mathematical notation associated with sets and sequences example, the set above could be specified as
and the logical notation used in predicate calculus. The intent of the section is
to provide an introduction. For a more detailed discussion the reader is urged
to examine books dedicated to these subjects and The sets that have been described above have all had elements that are single
items. Sets can be made from elements that are pairs, triples, and so on. For
example, the set specification
24.2.1 Sets and Constructive Specification
describes the set of pairs of natural numbers that have the form and
A set is a collection of objects or elements. Sets are used as a cornerstone of for- where the sum of and y is 10. This is the set
mal methods. The elements contained within a set are unique (i.e., no dupli-
cates are allowed). Sets with a small number of elements are written within (2,641, . .
with the elements separated by commas, For example, the set Another example of a constructive set specification is the set of pairs of nat-
17, ural numbers where the second element is 3 more than the element and
where the element is greater than 120. The specification is
is a collection of natural numbers and contains four elements The set
: I 120 . + 3))
Pascal, Ada, COBOL,
In the example above, it is tempting to use two variables. However, there is no
contains the names of programming languages. The collection of numbers need to do this because the second element of the pair can be expressed solely
in terms of the clement,
Obviously, a constructive set specification required to represent some com-
is not a set because of the repeating element 2. ponent of computer software can be considerably more complex than those
The order in which the elements appear within a set is immaterial. The noted above. However, the basic form and structure remain the same.
number of items in a set is known as its The operator returns a
set’s cardinality. For example, the expression
=4 24.2.2 Set Operators
implies that the cardinality operator has been applied to the set shown, with a
result indicating the number of items in the set. A specialized set of symbology is used to represent set and logic operations.
There are two ways of defining a set. A set may be defined by enumerating These symbols must be understood by the software engineer who intends to ap-
elements (this is how the sets noted above have been defined). The second ap- ply formal methods.
692 PART FIVE: ADVANCED TOPICS IN ENGINEERING 693
CHAPTER 24: METHODS
The a operator is used to indicate membership in a set. For example, the their results. The three most common operators are the union operator U,
expression sometimes known as “cup”; the intersection operator sometimes known as
“cap”; and the set difference operator
The intersection operator takes two sets and forms a set that contains all
has the value true if is a member of the set X and the value false otherwise. the elements in the set with duplicates eliminated. Thus, the result of the ex-
For example, the predicate pression
12 Tax, Compiler) U D2, D3,
has the value true since 12 is a member of the set. is the set
The opposite of the operator is the operator. The expression
Tax, Compiler,
The intersection operator takes two sets and forms a set consisting of the com-
has the value true if is not a member of the set X and false otherwise. For ex- mon elements in each set. Thus, the expression
ample, the predicate
n
13 1, 124,221
results in the set
has the value false. ,
The operators C and take sets as their operands. The predicate
as
The set difference operator, the name suggests, forms a set by removing the
elements of its second operand from the elements of its first operand. Thus, the
has the value if the members of the set A are contained in the set B and value of the expression
has the value false otherwise. Thus, the predicate
(New, Old, Sysparaml {Old,
results in the set
has the value true. However, the predicate
{New,
LP4, C RC2, HD3, LP4,
The value of the expression
has a value of false because the element RC5 is not contained in the set to the
right of the operator. b, n
The operator is similar to C . However, if its operands are equal it has
will be the empty set 0. The operator always delivers a set; however, in this
the value false. Thus, the value of the predicate
case there are no common elements between its operands so the resulting set
LP4, RC2, HD3, LPI, LP4, will have no elements.
The final operator is the cross productX , sometimes known as the
is true, and the predicate sian product. This has two operands which are sets of pairs. The result is a set
LP4, LP4, of pairs where each pair consists of an element taken from the first operand
combined with an element from the second operand. An example of an expres-
is false. sion involving the cross product is
A special set is the empty set 0. This corresponds to zero in normal math-
ematics. The empty set has the property that it is a subset of every other set.
Two useful identities involving the empty set are The result of this expression is
and
Notice that every element of the first operand is combined with every element
of the second operand.
A concept that is important for formal methods is that of a powerset. A
for any set A. These identities follow directly from the definition of u and , erset of a set is the collection of subsets of that set. The symbol used for the
presented below. operator in this chapter is It is a unary operator which, when
A number of binary operators take sets as their operands and have sets as I ”
694 PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER FORMAL 695
plied to a set, returns the set of subsets of its operand. For example, is a sequence. The items that form the first elements of the pairs are collec-
tively known as the domain of the sequence, and the collection of second ele-
ments is known as the of the sequence. In this book sequences will be
will be designated using angle brackets. For example, the sequence above would nor-
mally be written as,
Ill, 31, 2,
Jones, Wilson, Shapiro, Estavez
all the sets are subsets of
Unlike sets, duplication in a sequence is allowed and the ordering of a sequence
is important. Thus,
24.2.3 logic Operators Jones, Wilson, Shapiro Jones, Shapiro, Wilson
Another important component of a formal method is logic: the algebra of true
and false expressions. The meaning of common logical operators is well under- Jones, Wilson, Wilson
stood hy every software engineer. However, the logic operators that are associ-
ated with common programming languages are written using empty is represented as
keyboard symbols. The equivalent mathematical to these are shown
A are in formal specifications.
in Table 24.1. The only logic operator that is often missing in programming lan-
guage notation is the implies operator, It has two operands and is read as Catenation, , is a binary operator which forms a sequence that is con-
“the operand implies the second operand.” For example, structed by adding its second operand to the end of its first operand. For
example,
is read as is greater than 10 implies that is greater than 8.”
quantification is a way of making a statement about the ele- results in the sequence
ments of a set which is true for every member of the set. Universal quantifi-
cation uses the symbol V. An example of its use is 1, .
Other operators that can be applied to sequences are head, tail, front, and last.
The operator head extracts the element of a sequence; tail returns with
which states that, for every pair of values in the set of natural numbers, if is the last 1 elements in a sequence of length extracts the final ele-
greater than then is greater than ment in a sequence; and front returns with the first 1 elements in a se-
quence of length n. For example,
head =2
24.2.4 Sequences
tail 1.99, 101 101
A sequence is a mathematical structure which models the fact that its elements last 2, 3, 34, 101 = 101
are ordered. A sequence s is a set of pairs whose elements range from 1 to the
highest number element. For example, front 101 =
Jones), Wilson), Shapiro), Since a sequence is a set of pairs, all set operators described in Section 24.2.2
are applicable. When a sequence is used a state, it should be designated as
such by using the keyword For example,
COMMON LOGIC OPERATORS : seq FILES
and A
V describes a state with two components: a sequence of files and a natural
not number.
implies
696 PART ADVANCED IN SOFTWARE ENGINEERING CHAPTER 24: METHODS 697
24.3 APPLYING MATHEMATICAL NOTATION FOR FORMAL SPECIFICATION The mathematical components of the data invariant match four of the bulleted,
natural-language components described earlier. The first line of the data in-
To illustrate the use of mathematical notation in the formal specification of a variant states that there will be no common blocks used collection of
software component, we revisit the block handler example presented in Section blocks and the free collection of blocks. The second line states that the collec-
24.1.3. To review, an important component of a computer’s operating system tion of used blocks and free blocks will always be equal to the whole collection
maintains files that have been created by users. Part of this component is the of blocks in the system. The third line indicates that the ith element in the
block handler. The block handler maintains a reservoir of unused blocks and block queue will always be a subset of the used blocks. The final line states that
will also keep track of blocks that are currently in use. When blocks are re- if any two elements of the block queue are not the same, there will be no com-
leased from a deleted tile they are normally added to a queue of blocks waiting mon blocks in these two elements. The final two natural-language components
to be added to the reservoir of unused blocks. This has been depicted schemat- of the data invariant are implemented by virtue of the fact that used and free
ically in Figure 24.2. In this figure a number of components are shown: the are sets and therefore will not contain duplicates.
reservoir of free (unused) blocks, the blocks that currently make up the files The first operation that we shall define is one that removes an element
from the head of the block queue. The precondition is that there must be at
administered by the operating system, and those used blocks that are waiting
to be added to the reservoir. The waiting blocks are held in a queue, with each least one item in the queue:
element of the queue containing a set of blocks from a deleted file. The invari- 0
ant that describes the block handler has number of conditions:
The postcondition is that the head of the queue must be removed and
!" No block will be marked as both unused and used. placed in the collection of free blocks and the queue adjusted to show the
removal:
!" All the sets of blocks held in the queue will be subsets of the collection of cur-
rently used blocks. used’ = used \ head
!"There will be no duplicate block numbers in the collection of unused blocks.
free’ = free U head A
!" There will be no elements of the queue that will contain the same block num-
bers. = tail
!" The collection of used blocks and blocks that are unused will be the total col-
A convention used in many formal methods is that the value of a variable af-
lection of blocks that make ter an operation is primed. Thus, the component of the expression above
!" There will be no duplicate block numbers in the collection of used blocks. states that the new used blocks (used’) will be equal to the old used mi-
nus the blocks that have been removed. The second component states that the
There will be an assumed set which will consist of a set of every new free blocks (free’) will be the old free blocks with the head of the block
block number, and a set which is a set of blocks that lie between 1 queue added. The third component states that the new block queue will be
and The state will be modeled by two sets and a sequence. The two the tail of the old value of the block queue, that is, all elements in the
sets are used and free. Both contain blocks-the used set contains the blocks queue apart from the first one. A second operation is one that adds a collection
that are currently used in files and the free set contains blocks that are avail- of blocks to the block queue. The precondition is that is cur-
able for new tiles. The sequence will contain sets of blocks that are ready to be rently a set of used blocks:
released from files that have been deleted. The state can be described as
used
used, free : BLOCKS
The postcondition is that the set of blocks is added to the end of the block queue
BLOCKS and the set of used and free blocks remains unchanged:
This is very much like the declaration of program variables. It states that used = A
and free will be sets of blocks and that will be a sequence, each el-
ement of which will be a set of blocks. The data invariant can be written as used’ = used
used = free’ = free
There is no question that the mathematical specification of the block queue is
used free = A
considerably more rigorous than a natural language narrative or a graphical
V i : dom i used A model. The additional rigor requires effort, but the benefits gained from im-
proved consistency and completeness can be justified for many types of appli-
V i j : dom .i j in j=0 cations.
698 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER FORMAL METHODS
24.4 FORMAL LANGUAGES 24.5 USING Z TO REPRESENT AN EXAMPLE COMPONENT
Z specifications are structured as a set of structures that in-
A formal specification language is usually composed of three primary com- troduce variables and specify the relationship between these variables. A
ponents: a that defines the specific notation with which the spec- schema is essentially the formal specification analog of the programming lan-
ification is represented, (2) a semantics that helps to define a “universe of guage subroutine or procedure. In the same way that procedures and subrou-
objects” that will be used to describe the system, and a set of
tines are used to structure a system, schemas are used to structure a formal
relations that define the rules that which objects properly satisfy specification.
the specification.
In this section, we use the Z specification language to model the block han-
The domain of a formal specification language is often based on
dler example, introduced in Section 24.1.3 and discussed further in Section
a syntax that is derived from standard set theory notation and predicate cal-
24.3. A summary of Z language notation is presented in Table 24.2. The fol-
culus. For example, variables such as and describe a set of objects that lowing example of a schema describes the state of the block handler and the
relate to a problem (sometimes called the domain of discourse) and are used in data invariant:
conjunction with the operators described in Section 24.2. Although the syntax
is usually symbolic, icons (e.g., graphical symbols such as boxes, arrows, and
circles) can also be used if they are unambiguous.
The semantic domain of a specification language indicates how the lan- used, free BLOCKS
guage represents system requirements. For example, a programming language seq BLOCKS
has a set of formal semantics that enables the software developer to specify al-
gorithms that transform input to output. A formal grammar (such as can used free
be used to describe the syntax of the programming language. However, a pro- used free = A
gramming language does not make a good specification language because it can V i dom i used
represent only computable functions. A specification language must have a se-
mantic domain that is broader; that is, the semantic domain of a specification V i, j dom j
language must be capable of expressing ideas such as “For all in an infinite i j = 0
set A, there exists a in an infinite set such that the property holds
and y” Other specification languages apply a semantics that enables
The schema consists of two parts. The part above the central line represents
the specification of system behavior. For example, a syntax and semantics can
the variables of the state, while the part below the central line describes the
developed to specify states and state transitions, events and their on data invariant Whenever the schema representing the invariant and the state
state and timing.
is used in another schema, it is preceded by the A symbol. Thus, if the above
It is possible to use different semantic abstractions to describe the same
schema is used in a schema which, for example, describes an operation, then it
system in different ways. We did this in a less formal fashion in Chapters 12
would be written as A As the last sentence implies, schemas can
and 20. Data flow and corresponding processing was described using the
be used to describe operations. The following example of a schema describes the
data flow diagram, and system behavior was depicted with the
operation that removes an element from the block queue:
tion diagram. Analogous notation was used to describe object-oriented sys-
tems. Different modeling notation can be used to represent the same system.
The semantics of each representation provide complementary views of the
system. To illustrate this approach when forma1 methods are used, assume
that a formal specification language is used describe the set of events that
cause a particular state to occur in a system. formal relation depicts 0
all functions that occur within a given state. The intersection of these two used’ used head A
relations provides an indication of the events that will cause specific func- free’ free U head A
tions to occur. = tail
A variety of formal specification languages are in use today-CSP
HOR851, VDM and Z are represen-
tative formal specification languages that exhibit the characteristics noted The inclusion of A results in all the variables that make up the
above. In this chapter, the Z specification language is used for illustrative pur- state being available for the schema and ensures that the data
poses. Z is coupled with an automated tool called a “proof assistant” that stores Invariant will hold before and the operation has executed.
axioms, rules of inference, and application oriented theorems that lead to math- The second operation, which adds a collection of blocks to the end of the
ematical proof of correctness of the specification queue, is represented as
700 FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 24: FORMAL METHODS 701
A
BLOCKS
used
Z notation is based on typed set theory and first-order logic. Z providesconstruct,
=
called a describe a specification’s state space and operations, A schema
groups variable declarations with a list of predicates that constrain the possible values used’ = used A
of variable. In Z, the schema X is defined by the form free’ = free
- X
declarations By convention in Z, an input variable that is read from and does not form part
of the state is terminated by a question mark. Thus, Ablocks?, which acts as an
predicates
input parameter, is terminated by a question mark.
Global functions and constants are defined by the form
24.6 THE TEN COMMANDMENTS OF FORMAL METHODS
declarations
predicates The decision to make use of formal methods in the real world is not one that
is taken lightly. and Hinchley have coined “the ten command-
The declaration gives the type of the function or constant, while the predicate gives its ments of formal methods” as a guide for those who are about to apply this im-
value. Only an abbreviated set of i! symbols is presented in this table. portant software engineering
sets:
I. Thou shalt choose the appropriate notation. In order to choose ef-
S is declared as a set of
fectively from the wide array of formal specification languages, a soft-
ES is a member of S.
ware engineer should consider language vocabulary, application type to
is not a member of S.
be specified, and breadth of usage of the language.
S is a subset of Every member of S is also in
The union of S and It contains every member of S or or both, II. Thou shalt formalize, but not overformalize.It is generally not nec-
The intersection of S and It contains every member of both S and essary to apply formal methods to every aspect of a major system. Those
S\J The difference of S It contains every member of S except those components that are safety critical are first choices, followed by compo-
also in 7. nents whose failure cannot be tolerated (for business reasons).
Empty set: It contains no members. III. Thou shalt estimate costs.Formal methods have high start-up
Singleton set: It contains just x. costs. Training of staff, of support tools, and use of con-
The set of numbers 0, 1, 2, tract consultants result in high first-time costs. These costs must be
s: FX S is declared o finite set of considered when examining the return on investment associated
The maximum of the set of numbers S. with formal methods.
Functions: Thou shalt have a formal methods guru on call. Expert training
f is declared partial injection from X to and ongoing consulting are essential for success when formal methods
dom f The domain of f: the set of values for which is defined. are used for the first time.
ran f The range of the set of values taken by varies over the do V. Thou shalt not abandon thy traditional development methods.It
main of is possible, and in many case desirable, to integrate formal methods with
A function that with f except that is mopped to y. conventional and/or object-oriented methods (Chapters 12 and Each
f A function like f, except that is removed from its domain.
logic:
P It is true if both P ond true.
P implies Q: It is if either is true or P is
= No components of schema S change in on operation.
702 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 24: FORMAL METHODS
703
has strengths and weaknesses. A combination, if properly applied, can cult to represent. In addition, there are elements of a problem (e.g., hu-
produce excellent man-machine interfaces) that are better specified using graphical techniques.
VI. Thou sufficiently. Formal methods provide a concise, Finally, specification using formal methods is more to learn than other
and consistent method for documenting system require- analysis methods presented in this book and represents a significant “culture
ments. However, it is recommended that a natural-language commen- shock” for some software practitioners. For this reason, it is likely that formal,
mathematical specification techniques will form the foundation for a future
tary accompany the formal specification to serve as a mechanism for re-
inforcing the readers the system. generation of CASE tools. When this occurs, mathematically based specification
may be adopted by a wider segment of the software engineering
VII. .
T h o u s h a l t n o t c o m p r o m i s e t h y q u a l i t y s t a n d a r d s “There is noth-
ing magical about formal methods” and for this reason, other
(Chapter 8) must continue to be applied as systems are 24.8 SUMMARY
VIII. Thou shalt not be dogmatic. A software engineer must recognize that Formal methods provide a foundation for specification environments that lead
formal methods are not a guarantee of correctness. It is possible (some to analysis models that are more complete, consistent, and unambiguous than
would say, likely) that the final system, developed using for- those produced using conventional or object-oriented methods. The descriptive
mal methods. may have small omissions, minor bugs, and other attrib- facilities of set theory and logic notation enable a software engineer create
utes that do expectations. a clear statement of facts (requirements).
Ix. Thou shalt test, test, and test again. The importance of software test- The underlying concepts that govern formal methods are the data in-
ing has been discussed in Chapters 16, 17, and 22. Formal methods do variant-a condition that is true throughout the execution of the system that
not absolve the software engineer from the need to conduct well-planned, contains a collection of data; the state-the stored data which a system ac-
thorough tests. cesses and alters; and the operation-an action that takes place in a sys-
X. Thou shalt reuse. Over the long term, the only rational way to reduce tem and reads or writes data to a state. An operation is associated with two
software costs and increase software quality is through reuse (Chapter conditions: a precondition and a postcondition.
26). Formal methods do not change this reality. In fact, it may be that Discrete mathematics-the notation and heuristics associated with sets
formal methods are an appropriate approach when components for reuse and constructive specification, set operators, logic operators, and
libraries are to be created. forms the basis of formal methods. These mathematics are implemented in the
context of a formal specification language, such as Z.
like all formal specification languages, has both a syntactic and seman-
tic domain. The syntactic domain uses a that is aliened with
the notation of sets and predicate calculus. The domain enables the
24.7 FORMAL METHODS-THE ROAD AHEAD language to express requirements in a concise manner. The structure of Z in-
\ schemas-boxlike structures that introduce variables and specify
Although formal, based techniques are not as yet the those variables.
used widely in the industry, they do offer substantial over less formal A decision to use formal methods must consider start-up costs as well as
techniques. Liskov and Bersins summarize these in the following way: the cultural changes associated with a radically different technology. In most
instances, formal methods have highest payoff for safety-critical and
Formal specifications can be studied mathematically while informal specifica- critical systems.
tions cannot. For example, a correct program can be proved to meet its specifi-
cations, or two alternative sets of specifications can be proved equivalent. .
Certain forms of incompleteness or inconsistency can be detected automatically. REFERENCES
In addition. formal specification removes ambiguity and encourages greater [BOW941 and M.G. Hinchley, Ten Commandments of Formal Methods,
in the early stages of the software engineering process. Technical Report No. 350, University of Cambridge Computer
But problems remain. Formal specification focuses primarily on function Laboratory, Cambridge, UK, September 1994.
and data. Timing, control, and behavioral aspects of a problem are more Gries, D., and F.B. Schneider, A Logical Approach to Discrete Math,
Springer-Verlag, 1993.
engineering (Chapter is example of an integrated approach that
uses methods and conventional development notation. “It is important to note that others disagree. See
704 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 24: FORMAL METHODS 705
J.V., and J.J. Horning, Languages and Tools for Formal a. the data invariant
Specification, 1993. b. the state
of Methods,” ZEEE Software,September c. the operations that are likely for a phone book function
1990. 24.6. Develop a constructive specification for a set that contains of natural
C.A.R., Communicating Sequential Processes,Prentice-Hall numbers of the form such that the sum of and equals
International, 1985.
24.6. The installer for a PC-based application first determines whether an ac-
Hinchley, M.G., S.A. Concurrent Formal
ceptable set of hardware and system resources are present. It checks the
Development in McGraw-Hill, 1995.
hardware configuration to determine whether various devices (of many pos-
Jones, C.B., Systematic Software Development Using VDM, edition, 2nd sible devices) are present and determines whether specific versions of
Prentice-Hall, 1991. software and drivers are already installed. What set operator could he
Liskov, B.H., and Berzins, “An Appraisal of Program Specifications,” used to accomplish this? Provide an example in this context.
N.
in Software Specification Techniques, Gehani and A.T.
Addison-Wesley, 1986, 3. Attempt to develop a expression using logic and set operators for the following
statement: “For all and if is the parent of y and y is the parent of then
Marciniak, J.J. Encyclopedia of Software Engineering, Wiley, 1994.
Rosen, K.H., Discrete Mathematics and Its Applications, 3rd edition, is the grandparent of Everyone has a parent.” [Hint: Use the functions
McGraw-Hill, 1995. and to represent parent and grandparent functions, respectively.1
Spivey, J.M., Understanding Specification Language and Formal 24.8. Develop a constructive set specification of the set of pairs where the first el-
Semantics, Cambridge University Press, 1988. ement of each pair is the sum of two natural numbers and the sec-
Spivey, The Reference Manual,Prentice-Hall, 1992. ond element is the difference of the same two numbers. Both numbers should
S.A., Discrete Mathematics: A Unified Approach, McGraw-Hill, be between 100 and 200 inclusive.
1987. 24.9. Develop a mathematical description for the state and data invariant for
Wing, J.M., “A Specifier’s Introduction to Formal Methods,” IEEE problem 24.3. Refine this description in the specification language.
Computer, vol. 23, no. 9, September 1990, pp. 8-24. 24.10. Develop a mathematical the state and data invariant for
IWO0891 Woodcock, J.C., “Calculating Properties of Specifications, ACM problem 24.4. this description in the specification language.
Engineering Notes, vol. 14, no. 5, July 1989, pp. 43-54. 24.11. Using the notation presented in Table 24.2, select some part of the
rYou941 E., “Formal Methods,” Guerrilla Programmer, Cutter security system described earlier in this book and attempt to
Information Corp., October 1994. specify it with
24.12. Using one or more of the information sources noted in the references to this
PROBLEMS AND POINTS TO PONDER chapter or “Further Readings, and Other Information Sources,” develop a
half-hour presentation on the basic syntax and semantics of a formal
24.1. the types of’ deficiencies associated with less formal approaches to language other than
software engineering in Section 24.1.1. Provide three examples of each from
your own experience.
24.2. The benefits of mathematics as a specification mechanism have been dis- FURTHER READINGS AND OTHER INFORMATION SOURCES
cussed at length in this chapter. Is there a downside?
24.3. You have assigned to a software team that is developing software for a In addition to the books used as references in this chapter, a fairly large num-
fax modem. Your job is to develop the “phone book” portion of the applica- ber of books on formal methods topics has been published over the past few
tion. The phone book function enables up to names of addresses’ years. A listing of some of the more useful offerings is presented below:
to be stored along with associated company names, fax numbers, and other
related information. Using natural language define: R., S. Stepney, and in Practice,Prentice-Hall, 1994.
a. the data invariant J., Formal Specification and Documentation using A Case Study
b. the state Approach, International Thomson Computer Press, 1996.
the operations that are likely
Cooper, D., and R. in Practice,Prentice-Hall, 1995.
24.4. You have been assigned to a software team that is developing software,
D., S. and T. Ralston, Industrial Applicationof Formal
called that provides greater apparent memory for a PC
Methods to Model, Design and Analyze Computer Systems, Data
than physical memory. This is accomplished by identifying, collecting, and re-
Corp., Park Ridge, NJ, 1995.
assigning blocks of memory that have been assigned to an existing
tion but are not being used. The unused blocks are reassigned to applications A., An introduction to Formal Methods, 2nd edition, Wiley, 1994.
that require additional memory. Making appropriate assumptions and using Hinchey, M., and J. Applications of Formal Methods,Prentice-Hall,
natural language define: 1996.
PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING
J., and H. Haughton teds.), Object-Oriented Specification
Prentice-Hall, 1993.
Rann, D., J. Turner, and J. Whitworth, A Beginner’s Guide, Chapman
Hall. 1994.
CLEANROOM
Ratcliff, B., Introducing Specification Using Z: A Practical Case Study
Approach, McGraw-Hill, 1994.
D. Sheppard, An Introduction to Specification with Z and VDM,
SOFTWARE
McGraw-Hill, 1995.
The September 1990 issues of IEEE Software Engineering,
ENGINEERING
IEEE Software, and IEEE Computer were all dedicated to formal methods.
They remain an excellent source of useful information.
has edited a book that addresses formal methods and object tech-
nologies (Formal Object-Oriented Development, Springer-Verlag, 19961. The
book provides guidelines on the selective use of formal methods and how such
methods can in with
A wealth of formal methods information, including pointers to extensive
bibliographies, technical reports, specification languages, tools, and many other
useful pointers can be found at the NASA formal methods site and the Virtual
Library on Formal Methods:
he integrated use of conventional software engineering modeling, formal
/archive/formal-methods/ methods, program verification (correctness proofs), and statistical SQA
. have been combined into a technique that can lead to extremely high-quality
Additional discussion can be found in the newsgroups comp.specification. software. Cleanroom software engineering is an approach that emphasizes the
and need to build correctness into software as it is being developed. Instead of the
Comprehensive information on VDM (another formal specification lan- classic analyze, design, code, test, and debug cycle, the cleanroom approach sug-
guage) can be obtained at: gests a different point of view
The philosophy behind cleanroom software engineering is to avoid dependence
on costly defect removal processes by writing code increments right the first
time and verifying their correctness before testing. Its process model incorpo-
General information on formal methods, as well as research and position pa-
rates the statistical quality certification of code increments as they accumulate
pers and Web pointers can be obtained at:
into a system.
In many ways, the cleanroom approach elevates software engineering to
another level. Like the formal methods techniques presented in Chapter 24, the
An up-to-date list of World Wide Web references for formal methods can be cleanroom process emphasizes rigor in specification and design, and formal ver-
found at: ification of each element of the resultant design model using correctness proofs
that are mathematically based. Extending the approach taken in formal meth-
ods, the cleanroom approach also emphasizes techniques for statistical quality
control, including testing that is based on the anticipated use of the software
by customers.
When software fails in the real world, immediate and long-term hazards
abound. The hazards can be related to human safety, economic loss, or effective
operation of business and societal infrastructure. Cleanroom software engi-
neering is a process model that removes defects before they can precipitate se-
rious hazards.
707
708 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING
25.1 THE APPROACH
The philosophy of the “cleanroom” in hardware fabrication technologies is
ally quite simple: It is cost effective and time effective to establish a fabrica-
tion approach that precludes the introduction of product defects. Rather than
fabricating a product and then working to remove defects, the cleanroom ap-
proach demands the discipline required to eliminate errors in specification and
design and then fabricate in a “clean” manner.
The cleanroom philosophy was first proposed for software engineering by
Mills and his colleagues during the Although early experiences
with this disciplined approach to software work showed significant promise
it has not gained widespread usage. Henderson suggests
three possible reasons:
1. A belief that the cleanroom methodology is too theoretical, too mathematical,
and too radical for use in reel software development.
2. It advocates no unit testing by developers but instead replaces it with correct-
ness verification and statistical quality control-concepts that represent a ma-
jor departure from the way most software developed today.
3. The maturity of the software development industry. The use of cleanroom
processes requires rigorous application of defined processes in all life cycle
phases. Since most of the industry is still operating at the ad hoc level (as de-
fined by the Software Engineering Capability Maturity Model), the in-
dustry has not been ready to apply those techniques.
Although there are elements of truth in each of the concerns noted above, the
potential benefits of cleanroom software engineering far outweigh the invest-
ment required to overcome the cultural resistance that is at the core of these
concerns.
25.1.1 The Cleanroom Strategy
The cleanroom approach makes use of a specialized version of the incremental
software model (Chapter A “pipeline of software increments” is de-
veloped by small, independent software engineering teams. As each increment
is certified, it is integrated into the whole. Hence, functionality of the system
grows with time.
The of cleanroom tasks for each increment is illustrated in Figure
25.1. Overall system or product requirements are developed using the system
engineering methods discussed in Chapter 10. Once functionality has al-
located to the software element of the system, the pipeline of cleanroom incre-
ments is initiated. The following tasks occur:
I n c r e m e n t P l a n n i n g . A project plan that adopts the incremental strategy
is developed. The functionality of each increment, its projected size, and a
cleanroom development schedule are established. Special care must be taken
to ensure that certified increments will be integrated in a timely manner.
710 PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING
CHAPTER 25: CLEANROOM SOFTWARE ENGINEERING
711
Requirements Gathering. Using techniques similar to those intro-
duced in Chapter 11, a more detailed description of customer-level re- 25.1.2 What Makes Cleanroom Different?
quirements (for each increment) is developed.
B o x S t r u c t u r e S p e c i f i c a t i o n . A specification method that makes use of Dyer alludes to the differences of the cleanroom approach when he de-
structures is used to describe the functional specification. fines the process:
Conforming to the operational analysis principles discussed in Chapter 11,
box structures “isolate and creative definition of behavior, Cleanroom represents the first practical attempt at putting the software de-
data, and procedures at each level of velopment process under statistical quality control with a well-defined strategy
for continuous process improvement. To reach this goal, a unique cleanroom life
F o r m a l D e s i g n . Using the box structure approach, cleanroom design is
a natural and seamless extension of specification. Although it is possible to cycle was defined which focused on mathematics-baaed software engineering
for correct software designs and on statistics-based software for certification of
make a clear distinction between the two activities, Specifications (called
“black boxes”) are iteratively refined (within an increment) to become analo- software reliability,
gous to architectural and procedural designs (called “state boxes” and “clear
boxes,” respectively). Cleanroom software engineering differs from the conventional and
oriented views presented in Parts Three and Four of this book because:
C o r r e c t n e s s V e r i f i c a t i o n . The cleanroom team conducts a series of rig-
orous correctness verification activities on the design and then the code.
Verification (Sections 25.3 and 25.4) begins with the highest-level box 1. It makes explicit use of statistical quality control.
structure and moves toward design detail and code. The first 2. It verifies design using proof of cor-
level of correctness verification occurs by applying a set of “correctness rectness.
questions” If these do not demonstrate that the specification is 3. It relies heavily on statistical usage testing to uncover high-impact errors.
correct, more formal (mathematical) methods for verification are used.
Code Generation, Inspection, and Verification. box structure The Obviously, the cleanroom approach applies most, if not all, of the basic software
specifications, represented in a specialized language, are translated into engineering principles and concepts presented throughout this book. Good
the appropriate programming language. Standard walkthrough or inspec- analysis and design procedures are essential if high quality is to result. But
tion techniques (Chapter 8) are then used to ensure semantic conformance cleanroom engineering diverges from conventional software practices by
of the code and box structures, and syntactic correctness of the code. Then phasizing (some would say, eliminating) the role of unit testing and debugging,
correctness verification is conducted for the source code. and dramatically reducing (or eliminating) the amount of testing performed by
S t a t i s t i c a l T e s t P l a n n i n g . The projected usage of the software is ana- the developer of the software.’
lyzed and a suite of test cases that exercise the “probability distribution” In conventional software development, errors are accepted as a fact of life.
of usage are planned and designed (Section 25.4). As shown in Figure 25.1, Because errors are deemed to be inevitable, each program module must be unit
this cleanroom activity is conducted in parallel with specification, verifica- tested (to uncover errors) and then debugged (to remove errors). When the
tion, and code generation. ware is finally released, field use uncovers still more defects, and another test
and debug cycle begins. The rework associated with these activities is costly
Statistical Usage Testing. Recalling that exhaustive testing of com-
puter software is impossible (Chapter it is always necessary to design and time-consuming. Worse, it can be degenerative-error correction can (in-
a finite number of test cases. Statistical usage techniques execute advertently) lead to the introduction of still more errors.
a series of tests derived from a statistical sample (the probability distribu- In cleanroom software engineering, unit testing and debugging are re-
tion noted above) of all possible program executions by all users from a tar- placed by correctness verification and statistically based testing. These activi-
geted population (Section 25.4). ties, coupled with the record keeping necessary for continuous improvement,
make the cleanroom approach unique.
C e r t i f i c a t i o n . Once verification, inspection, and usage testing have been
completed [and all errors are corrected) the increment is certified as ready
for integration.
25.2 FUNCTIONAL SPECIFICATION
Like other software process models discussed elsewhere in this book, the
room process relies heavily on the need to produce high-quality analysis and Regardless of the analysis method that is chosen, the operational principles
design models, As we will see later in this chapter, box structure notation is presented in Chapter 11 always apply. Data, function, and behavior are mod-
simply another way for a software engineer to represent requirements and de- eled. The resultant models must be partitioned to provide increasingly
sign. The real distinction of the cleanroom approach is that formal verification
is applied to engineering models.
‘Testing is conducted, but by independent testing team.
712 PAR T ADVANCED TOPICSI N ENGINEERING 713
CHAPTER 25: ENGINEERING
greater detail. The overall objective is to move from a specification that cap-
tures the essence of a problem to a specification that provides substantial im-
plementation detail.
Cleanroom software engineering complies with the operational analysis
A
principles by using a method called box structure specification. “box”
the system (or some aspect of the system) at some level of detail. Through
a process of refinement, boxes are refined into a hierarchy in which
each box has referential transparency-“the information content of each box
specification is define its refinement, without depending on the im-
plementation of any other box” This enables the analyst to partition a
system hierarchically, moving from essential representation at the top to im-
plementation-specific detail at the bottom. Three types of boxes are used:
This box specifics the behavior of a or part of a sys-
tem. The system (or part) responds to specific stimuli (events) by applying’
a set of transition rules that map the stimulus into a response.
State This box encapsulates state data and services (operations) in a
manner that is analogous to In this specification view, inputs to the
state box (stimuli) and outputs (responses) are represented. The state box also FIGURE25.2.
represents the “stimulus history” of the black box, that is, the data encapsu- Box structure
lated in the state box that must be retained between the transitions implied. ment
Clear Box. transition functions that are implied by the state box are
defined in the clear box. Stated simply, a clear box contains the procedural tion is applied to a sequence, S*, of inputs (stimuli), S, and transforms them
design for the state box. into an output (response), R. For simple software components, fmay be a math-
ematical function, but in general, is described using natural language (or a
Figure 25.2 illustrates the refinement approach using box structure speci- formal specification language).
fication. A black box defines responses for a complete set of stimuli. Many of the concepts introduced for object-oriented systems (Chapter
can be refined into a set of black boxes. to , which each address a are also applicable for the black box. Data abstractions and the operations that
class of behavior. Refinement continues until a cohesive class of behavior is manipulate those abstractions are encapsulated by the black box. Like a class
identified (e.g. A state box is then defined for the black box hierarchy, the black-box specification can exhibit usage hierarchies in which
In this case contains and roquircd to imple- low-level boxes inherit the properties of those boxes higher in the tree structure.
ment the behavior defined by Finally, is refined into a set of
clear boxes and procedure design details are specified.
As each of these refinement steps occur, verification of correctness also oc-
curs. State-box specifications are verified to ensure that each conforms to the 25.2.2 State-Box Specification
behavior defined by the parent black-box specification. Similarly, clear-box
specifications are verified against the parent state box. The state box is “a simple generalization of a state machine” A state
It should be noted that specification methods based on formal methods is some observable mode of system behavior (recall the discussion of behavioral
(Chapter can be used in lieu of the box structure specification approach. The modeling and state-transition diagrams in Chapter 12). As processing occurs,
only requirement is that each level of specification can be formally verified. a system responds to events (stimuli) by making a transition from the current
to some new state. As the transition is made, an action may occur. The
Black-Box Specification
is
A black-box specification an abstraction that describes how a system re-
sponds to stimuli using the notation shown in Figure 25.3 The
FIGURE25.3.
A block-box
“See Part Four of this book. cation
25 715
714 PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING
FIGURE 25.5.
FIGURE 25.4. A clear-box specifi-
A cation
tion
state box uses a data abstraction to determine the transition to the next state Basic processing functions (described during earlier refinements of the
specification) are refined using a “stepwise expansion of mathematical func-
and the action (response) that will occur as a consequence of the transition.
As shown in Figure 25.4, the state box incorporates a black box. The stim- tions into structures of logical [e.g., if-then-else] and subfunctions,
ulus, S, that is input the black box arrives from some external source and a where the expansion carried out until all identified subfunctions could be
set of internal system states, Mills provides a mathematical description of directly stated in the programming language used for implementation”
the function, of the black box contained within the state box: The structured programming approach can be used effectively to refine
function, but what about data design? Here a number of fundamental design
concepts (Chapter come into play, Program data are encapsulated as a set
of abstractions that are serviced by subfunctions. The concepts of data encap-
where is a subfunction that is tied to a specific state When considered col-
sulation, information hiding, and data typing are used to create the data de-
lectively, the state-subfunction pairs define function
25.2.3 Clear-Box Specification
25.3.1 Design Refinement and Verification
The clear-box specification is closely aligned with procedural design and struc- Each clear-box specification represents the design of a procedure (subfunction)
tured programming. In essence, the subfunction g within the state box is re-
required to accomplish a state-box transition. With the clear box, the structured
placed by the structured programming constructs that implement g.
programming constructs and refinement are used as illustrated in
As an example, consider the clear box shown in Figure 25.5. The black box,
Figure 25.6. A program function, is refined into a of subfunctions
g, shown in Figure 25.4 is replaced by a sequence construct that incorporates
g and These in turn are refined into conditional constructs (if-then-else and
a conditional. These, in turn, can be refined into lower-level clear boxes as Further refinement illustrates continuing logical elaboration.
wise refinement proceeds.
At each level of refinement, the cleanroom performs a formal cor-
It is important to note that the procedural specification described in the
rectness verification. To accomplish this, a set of generic correctness conditions
clear-box hierarchy can be proved to be correct. This topic is considered in the
are attached to the structured programming constructs. If a function is ex-
next section. panded into a sequence g and (as shown in Figure the correctness con-
dition for all input to is:
25.3 DESIGN REFINEMENT AND VERIFICATION
“See Chapter 14 discussion structured
The design approach used in cleanroom software makes heavy use in it lees likely
of the structured programming philosophy (Chapter But in this case, will in conducting the
tured programming is applied far more rigorously.
716 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING 717
CHAPTER 25: CLEANROOM ENGINEERING
FIGURE 25.7.
Computing the .
part of square
root
single condition is checked for sequences; two conditions are tested for
else; and three conditions are verified for loops.
To illustrate correctness verification for a procedural design, we use a sim-
ple example first introduced by Linger and his colleagues The intent
FIGURE 25.6. is to design and verify a small program that finds the integer part, of a
refinement square root of a given integer, The procedural design is represented using the
flowchart in Figure 25.7.
!" Does followed by do ? To verify the correctness of this design, we must define entry and exit con-
ditions as noted in Figure 25.8. The entry condition notes that must be
greater than or equal to 0. The exit condition requires that remain unchanged
If a function is refined into conditional form, then else the
and take on a value within the range noted in the figure. To prove the design
correctness condition for all input top is:
to be correct, it is necessary to prove the conditions yes, and exit
shown in Figure 25.8 are true in all cases. These are sometimes called sub-
Whenever condition c is true does do and whenever c is false,
!"
proofs.
does do p?
1. The condition demands that 0 and = 01. Based on the re-
If a function m is refined as a loop, the correctness conditions for all input to quirements of the problem, the entry condition is assumed
m are: Therefore, the first part of the condition, 0 is satisfied. In the
the statement immediately preceding the condition sets
!" Is termination guaranteed? = 0. Therefore, the second part of the condition is also satisfied.
!" Whenever c is true does followed by m do m, and whenever c is Hence, is true.
false, does skipping the loop still do m? , 2. The loop condition may be encountered in one of two ways: directly from
(in this case, the loop condition is satisfied directly) or (2) via control
Each time a clear box is refined to the next level of detail, the correctness con- flow that passes through the condition cont. Since the condition is
ditions noted above are applied.
It is important to note that the use of the structured programming con-
structs constrains the number of correctness tests that must be conducted. A “A negative value for square root has no meaning in this context.
CHAPTER 25: CLEANROOM SOFTWARE ENGINEERING
PART FIVE: ADVANCED TOPICS SOFTWARE ENGINEERING 719
718
Subproofs:
= gl; END] ?
DO
f2 = [WHILE pl DO END]
WHILE
PI
DO = g8 END] ?
THEN ELSE END]
IF
P2
THEN f5 = END] ?
FIGURE 25.8. ELSE = END] ?
Proving the design
correct
END
FIGURE25.9.
A design with sub END
identical to the loop condition, is true regardless of the flow path that
proofs END
leads to it.
The condition is encountered only after the value of is incremented
by 1. In addition, the control flow path that leads to can only be in-
25.3.2 Advantages of Design Verification6
voked if the yes condition is also true. Hence if + it follows that
The condition is satisfied.
Rigorous correctness of each refinement of the clear-box design has
The yes condition is tested in the conditional logic shown. Hence, the yes
number of distinct advantages. Linger describes these in the follow-
condition must be true when control flow along the path shown.
ing manner:
The condition first demands that remain unchanged. An examination
of the design indicates that appears nowhere to the of an assignment !" It reduces verification to a finite process. Thenested, sequential way in which
operator. There are no function calls that use Hence it is unchanged.
control are organized in II clear box naturally defines a hierarchy
Since the conditional t fail reach the condition, that reveals the correctness conditions that must be verified. An axiom of re-
it follows that + In addition, the loop condition must still be true placement lets us substitute intended functions by their control
(i.e., Therefore, + and can be combined to satisfy structure refinements in the hierarchy of subproofs. For example, the
the exit condition proof for the intended function fl in Figure 25.9 requires proving that the
composition of the operations gl and g2 with the intended function f2 has
We must further ensure that the loop terminates. An examination of the loop the same effect on data as f 1. Note that f2 substitutes for all the details of
condition indicates that because y is incremented and the loop must its refinement in the proof. This substitution localizes the proof argument to
eventually terminate. the control structure at hand. In fact, it lets the software engineer carry out
The steps noted above are a proof of the correctness of the design of the proofs in any order.
the alnorithm noted in 25.7. We are now certain that the design will, in
fact, the integerpart of a square root.
more rigorous mathematical approach to design verification is possible.
25.7 through 25.9 have been
However, a discussion of this topic is beyond the scope of this book. Interested mission.
readers should refer to
FTWARE ENGINEERING
PART FIVE: ADVANCED TOPICS IN SO CHAPTER 25: CLEANROOM SOFTWARE ENGINEERING
It is impossible overemphasize the positive effect that reducing ver- and events that are often produced’by the user. But in complex systems, the
ification to a finite process has on quality, Even though all but the most possible spectrum of input and events (i.e., the use cases) can be extremely
trivial programs exhibit an essentially infinite number of execution paths, wide. What is the subset of use cases that will adequately verify the behavior
they can be verified in a finite number of steps. of the program? This is the first question that is addressed by statistical use
!" lets cleanroom teams verify line of design and code. Teams can carry testing.
out the verification through group analysis and discussion on the basis of the Statistical use testing “amounts to testing software the way users intend
correctness theorem, and they can produce written proofs when extra confi- use it” To accomplish this, cleanroom testing must determine
dence in a life-or mission-critical system is required. a usage probability distribution for the software. The specification (black box)
!" results in a near zero defect level. During a team review, every correctness for each increment of the software is analyzed to define a set of stimuli (inputs
condition of every control structure is verified in turn. Every team member or events) that cause the software to change its behavior. Based on interviews
must agree that each condition is correct, so an error is possible onlv if with potential users, the creation of usage scenarios, and a general under-
team member incorrectly verifies a condition. The requirement for standing of the application domain, a probability of use is assigned to each
agreement based on individual verifications results in software that stimuli.
has few or no before first execution. Test cases are generated for each according to the usage proba-
!" scales up. Every software system, no matter how laree. has too-level. clear- bility distribution. To illustrate, consider the security system dis-
cussed earlier in this book. Cleanroom software engineering is being used
box procedures composed of sequence, alternation,
Each of these typically invokes a large subsystem with thousands of lines of develop a software increment that manages user interaction with the security
system keypad. Five stimuli, listed in Table 25.1, have been identified for this
code-and each of those subsystems has its own top-level intended functions
and procedures. So the correctness conditions for these high-level control increment. Analysis indicates the percent probability of each stimuli. To make
selection of test cases easier, these probabilities are mapped into intervals
structures are verified in the same way as are those of low-level structures.
numbered between 1 and 99
Verification at high levels may take, and well be worth, more time, but it does
To generate a sequence of usage test cases that conform to the usage prob-
not take more theory.
ability distribution, a series of random numbers are generated between 1 and
produces better than unit testing. Unit testing checks only the effects 99. The random number corresponds to the interval on the probability distrib-
of executing selected test paths out of many possible paths. By basing ution (Table 25.1). Hence, the sequence of usage cases is defined randomly but
cation on function theory, the cleanroom approach can verify every possible corresponds to the appropriate probability of stimuli occurrence. For example,
effect on all data, because although a program may have many execution assume the following random number sequences are generated
paths, it has only one function. Verification is also more than unit
testing. Most verification conditions can be checked in a few minutes. but 13-94-22-24-45-56
unit tests take substantial time to and check.
81-19-31-69-45-g
It is important to note that design verification must ultimately be applied to 38-21-52-84-86-9’7
the source code itself. In this context, it is often called correctness verification.
the appropriate stimuli based on the distribution interval shown in
Table 25.1, the following use cases are derived:
25.4 CLEANROOM TESTING AD-T-AD-AD-AD-ZS
The strategy and tactics of cleanroom testing are fundamentally different from
AD-AD-ZS-T-T-PA
conventional testing approaches. Conventional methods derive a set of test
cases to uncover design and coding errors. The goal of cleanroom testing is to
validate software requirements by demonstrating that a statistical of The testing team executes the use cases noted above (and others) and verifies
use cases (Chapter have been executed successfully. software behavior against the specification for the system. Timing for tests is
recorded so that interval times may be determined. Using interval time, the cer-
tification team can compute mean-time-to-failure. If a long sequence of is
25.4.1 Use
The user of a computer program rarely needs to understand the technical de- called “certification teams.”
tails of the design. The user visible behavior of the program is driven by inputs tools used accomplish For further information,
722 PART FIVE. ADVANCED TOPICS IN SOFTWARE
CHAPTER SOFTWARE ENGINEERING 723
value of is mathematically to ensure that required reliability is
achieved.
PROGRAM STIMULI AND PROBABILITY DISTRIBUTION C o m p o n e n t m o d e l . A system composed of components is to be certi-
fied. The component model enables the analyst to determine the probabil-
ity that component will fail to completion.
Program stimulus Distribution Interval
C e r t i f i c a t i o n m o d e l . The overall reliability of the system is projected
l-49 and certified.
(AD) 50%
zone set 15%
15% 64-78 At statistical usage testing, the certification team has the in-
Query
Test (T) 15% 79-94 formation required to deliver software that has a certified that is com-
5% 95-99 puted using the each of these models.
Panic alarm (PA)
A detailed discussion of the computation of the sampling, component, and
models is beyond the scope of this book. The interested reader
should see and for additional detail.
conducted without failure, the is low and software reliability may be
high.
25.5 SUMMARY
Cleanroom software engineering is a formal approach to software development
25.4.2 Certification that can lead to software that has remarkably high quality It uses box struc-
ture specification (or formal methods) for analysis and design modeling, and
The verification and testing techniques discussed earlier in this chapter lead emphasizes correctness verification, rather than testing, as the primary mech-
to software components (and entire increments) that can be certified. Within anism for finding and removing errors. Statistical usage testing is applied to
the context of the cleanroom software engineering approach, certification im- develop the failure rate information necessary to certify the reliability of de-
plies that the reliability (measured by mean-time-to-failure, can be livered software.
specified for each component. The cleanroom approach begins with analysis and design models that use
The potential impact of certifiable software components goes far beyond a a box structure representation. A “box” encapsulates the system (or some as-
single cleanroom project. Reusable software components can be stored along pect of the system) at a specific level of abstraction. Black boxes are used to
with their usage scenarios, program stimuli, and probability distributions. represent the externally observable behavior of a system. State boxes encap-
Each component would have a certified reliability under the usage scenario and sulate state data and operations. A clear box is used to model the procedural
testing regime described. This information is invaluable to others who intend design that is implied by the data and operations of a state box.
to use the components. Correctness verification is applied once the box structure design is com-
The certification approach involves five steps plete. The procedural design for a software component is partitioned into a se-
ries of subfunctions. To prove the correctness of each of the subfunctions, exit
1. Usage scenarios must be created. conditions are defined for each of the subfunctions and a set of subproofs are
applied. If each exit condition is satisfied, the design must be correct.
2. A usage profile is specified.
Once correctness verification is complete, statistical usage testing com-
3. Test cases are generated from the profile. mences. Unlike conventional testing, cleanroom software engineering does not
4. Tests are executed and failure data are recorded and analyzed. emphasize unit or integration testing. Rather, the software is tested by defin-
5. Reliability is computed and certified. ing a set of usage scenarios, determining the probability of use for each
nario, and then defining random tests that conform to the probabilities, The er-
ror records that result are combined with sampling, component, and certification
1 through 4 have been discussed in earlier sections. In this section, we
concentrate on reliability certification. models to enable mathematical computation of projected reliability for the soft-
ware component.
Certification cleanroom software engineering requires the creation of
The cleanroom philosophy is a rigorous approach to software engineering.
three models
It is a software process model that emphasizes mathematical verification of cor-
rectness and certification of software reliability. The bottom line is extremely
S a m p l i n g m o d e l . Software testing executes random test cases and is low failure rates, which would be difficult or impossible to achieve using less
certified if no failures or less than a specified number of failures occur. The formal methods.
724 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 25: CLEANROOM SOFTWARE ENGINEERING 725
REFERENCES 26.5. Develop a box structure specification for the e-mail system presented in
problem 21.15.
Curritt, PA., M. Dyer, and H.D. Mills, “Certifying the Reliability of 25.6. A bubble sort algorithm is defined in the following manner:
Software,” IEEE Software Engineering, vol. SE-12, no. 1, January
1994. procedure bubblesort;
Dyer, M., The Approach to Quality Software var i, t, integer;
Wiley, 1992. begin
Hausler, P.A., R. Linger, and C. Trammel, “Adopting Cleanroom Software repeat until
Engineering with a Phased Approach,” IBM vol. 33, =
no. 1, January 1994, pp. 2tondo
Henderson, J., “Why Isn’t Cleanroom the Universal develop- if then begin
ment Methodology?” Crosstalk, vol. 8, no. 5, May 1995, pp. 11-14.
A.R., and H.D. Mills, “Box Structure Methods for System =
Development with Objects,” IBM Systems Journal, vol. 31, no. = t;
February 1993, pp. 232-251. end
Linger, R.M., H.D. Mills, and B.I. Witt, Structured Programming: Theory
and Practice, Addison-Wesley, 1979.
Linger, R.M., and H.D. Mills, “A Case Study in Cleanroom Software
Engineering: The IBM COBOL Structuring Facility,” COMPSAC Partition the design into subfunctions and define a set of conditions that
‘88, Chicago, October 1988. would enable you to prove that this algorithm is correct.
Linger, R., “Cleanroom Process Model,” IEEE Software, March 1994, 25.7. Document a correctness verification proof for the bubble sort discussed in
problem 25.6.
Mills, H.D., M. Dyer, and R. Linger, “Cleanroom Software Engineering:
Select a program component that you have designed in another context (or one
IEEE Software, September 1987, pp. 19-24.
assigned by your instructor) and develop a complete of correctness for it.
Mills, H.D., “Stepwise Refinement and Verification in Structured
Systems,” IEEE Computer, June 1988, pp. 23-35. 26.9. Select a program that you use regularly (e.g., an e-mail handler, a word
Musa, J.D., A. Iannino, and K. Okumoto, Engineering and Managing processor, a spreadsheet program). Create a set of usage scenarios for the
Software with Reliability Measures, McGraw-Hill, 1987. program. Define the probability of use for each scenario and then develop a
Poore, J.H., and H.D. Mills, “Bringing Software Under Statistical Quality program stimuli and probability distribution table similar to the one shown
Control, Quality Progress, November 1988, pp. 52-55. in Table 25.1.
Poore, J.H., H.D. Mills, and D. Mutchler, “Planning and Certifying 25.10. For the program stimuli and probability distribution table developed
Software System Reliability,” IEEE Software, vol. 10, no. 1, January problem 25.9, use a random number generator to develop a set of test cases
1993, pp. 88-99. for use in statistical use testing.
Wohlin, C., and P. “Certification of Software Components,” 25.11. In your own words, describe the intent of certification in the cleanroom
IEEE Software Engineering, vol. 20, no. 6, June 1994, pp. 494-499. ware engineering context.
26.12. Write a short paper that describes the mathematics used to define the cer-
tification models described briefly in Section 25.4.2. Use
and as a starting point.
PROBLEMS AND POINTS TO PONDER
26.1. If you had to pick one aspect of cleanroom software engineering that makes FURTHER READINGS AND OTHER INFORMATION SOURCES
it radically different from conventional or object-oriented software engi-
neering approaches, what would it be? readily available book on cleanroom software engineering is Dyer
26.2. How do an incremental process model and certification work together to Pro-
The Cleanroom Pamphlet (Software Technology Support Center, Hill
duce high-quality software? Base, UT, April 1995) contains reprints of a number of important articles.
26.3. Using structure specification, develop “first-pass” analysis and design Linger is one of the better introductions to the subject. Asset Source
models for the for Software Engineering Technology, ASSET, (United States Department of
25.4. Develop a box structure specification for a portion of the PHTRS system in- . Defense) offers an excellent six volume set of Cleanroom Engineering
troduced in problem 12.13. Handbooks. ASSET can be contacted at
CHAPTER 25: CLEANROOM ENGINEER ING
PART FIVE: ADVANCED TOPICS IN SOFTWARE 727
726
Case studies and experience reports:
Michael Deck of Cleanroom Software Engineering, Inc. has prepared a bib-
liography on cleanroom topics. Among the references are the following: Green, S.E., A. Kouchakdjian, and V.R. “Evaluation of the Cleanroom
Methodology in the Software Engineering Laboratory,” 14th Annual
Engineering Workshop, NASA Goddard Space Flight Center,
General and
November 1989.
Cobb, R.H., and H.D. Mills, “Engineering Software under Statistical Quality Hausler, P.A., “A Recent Cleanroom Success Story: The Redwing Project,
Control,” IEEE Software, November pp. 44-54. 17th Annual Software Engineering Workshop, NASA Goddard Space
Coffee, P., “Can Mass Testing Fix Windows’ Quality Woes?” PC Week, Flight Center, December 1992.
September p. 28. Responses in PC Week, October pp. 73, Head, G.E., “Six-Sigma Software Using Cleanroom Software Engineering
78. Techniques,” Hewlett-Packard Journal, June 1994, pp.
Deck, M.D., “Cleanroom Software Engineering: Quality Improvement and Tann, L-G., “OS32 and Cleanroom,” 1st Annual European
Cost Reduction,” Pacific Northwest Software Quality Conference, Symposium on Cleanroom Software Engineering, Copenhagen, Denmark,
October 1994, pp. 243-258. 1993, pp. l-40.
A.R., S.A. Becker, and L.B. Pedowitz, “Integrated CASE for Trammel, C.J., Binder, L.H., and Snyder, C.E., “The Automated Production
Cleanroom Development,” Software, March 1992, pp. 69-76. Control Documentation System: A Case Study in Cleanroom Software
Keuffel, “Clean Your Room: Formal Methods for the Computer ACM Engineering and Methodology, vol.
Language, July 1992, pp. 39-46. no. 1, January 1992, pp. 81-94.
Linger, Richard C., “Cleanroom Software Engineering for Zero-Defect Wohlin, C., “Engineering Reliable Software,” 4th Symposium on
Software”, 15th on Software Engineering, May 1993. Software Reliability Engineering, November 1993, pp. 36-44.
Lokan, C.J., “The Cleanroom Process for Software Development,”
Australian Computer Journal, vol. 25, no. 4, November 1993. Occasional discussions of cleanroom software engineering can be found in the
A detailed discussion of cleanroom
including descriptions of course8 offered in the subject area be
Management practices: found at the IBM Cleanroom Software Technology Center:
Deck, M.D., and Hausler, “Cleanroom Software Engineering: Theory
and Practice,” Software Engineering and Knowledge Engineering 90,
June 1990,
An extensive bibliography and articles for FTP have been prepared by
Linger, Spangler, R.A., “The IBM Cleanroom Software Engineering Cleanroom Engineering, Inc., and can be obtained at:
Technology Transfer Program,” Sixth SEZ on Software Engineering
Education, San Diego, CA, October 1992.
Specification, and review: An electronic mailing list and discussion group has been established for
cleanroom methods. Information can be obtained at:
Deck, M.D., “Using Box Structures to Link Cleanroom and Object-Oriented
Software Engineering,” Technical Report Cleanroom Software
Engineering, Inc., Boulder, CO, 1994.
Dyer, M., “Designing Software for Provable Correctness: The Direction for An up-to-date list of World Wide Web references for cleanroom software en-
Quality Software,” Information and Software vol. 30, no. 6, gineering can be found at:
July/August 1988, pp.
Testing and certification:
Dyer, M., Approach to Software Reliability Measurement,” Information
and Software Technology, vol. 29, no. 8, October 1987, pp. 415420.
Whittaker, J.A., and Thomason, M.G., “A Markov Chain Model for Statistical
Testing,” on Software Engineering, October 1994, pp.
812-824.
CHAPTER 26: REUSE 729
be established to encourage software engineers to reuse, rather than reinvent?
Is manaeement willing to incur the added expense associated with creating
reusable software Can the library of components necessary to ac-
complish reuse be created in a way that makes it accessible to those who need
SOFTWARE REUSE
it? Can components that do exist be found by those who need them?
These and many other questions continue to the community of re-
searchers and industry professionals who are striving to make software com-
ponent reuse a mainstream approach to software engineering. We look at some
of the answers in this chapter.
26.1 MANAGEMENT ISSUES’
A quick study of the possible benefits of reusing software reveals that there is
much more to be gained than a simple cost saving during the development of
a software product. For example, the reuse of a software component which is
known to be reliable introduces less risk than redesigning and recoding the
same component for each new application. issues can also be more
effectively addressed if one can focus attention on optimizing a set of reusable
components rather than having to continually re-optimize new versions of pre-
viously existing modules.
However, the obvious benefits of reuse are often outweighed by organiza-
human beings we learn the benefits of reuse as soon as we begin to per- tional roadblocks, a lack of understanding of the true nature of software reuse,
ceive our world in a rational manner. We reuse almost everything-ideas, and a weak or nonexistent strategy for encouraging and implementing reuse
objects, arguments, abstractions, processes-that makes up the fabric of every- technology. We consider each of these topics in the sections that follow.
day life. The well-worn phrase “reinventing the wheel” says it all. It makes lit-
tle sense--economically, intellectually, or pragmatically-to reinvent what has
already been invented. Reinventing the wheel has plagued the software com-
munity for almost half a century. 26.1.1 Roadblocks to Reuse
Peter Freeman discusses reuse in the following manner:
There remains confusion about what an increased emphasis on software
reusability might mean. Although many industry observers acknowledge that
Reu se is an activity, not an object. It is such a common activity, in general, that
some existing software development practices will have to change, they seem
most dictionaries don’t even list it; it is assumed that the intelligent reader will
unaware of which specific items will be different. There are a number of road-
understand that “reuse” means to “use something again.” We are familiar with
blocks to software reuse. In order to develop an effective reuse strategy, man-
recycling , and the general maxim of making something “do double duty.”
agers (and technologists) must understand what these roadblocks are.
In the context of creating software intensive systems, is
any procedure that produces (or helps produce) a system by reusing something
from a previous development effort. The only question then is what gets reused Few companies and organizations have anything that even slightly resem-
and what is the procedure that if followed will result in successful reuse. bles a comprehensive software reusability plan. Although many companies
and organizations have someone somewhere who is “researching” the idea,
few have any intention of implementing such a plan in the near future.
In the software engineering context, reuse is both an old and a new idea. Software reuse is hardly a “top-priority item” for many software firms.
Programmers have reused ideas, objects, arguments, abstractions, and processes Although an increasing number of software vendors currently sell tools or
since the earliest days of computing, but our approach to reuse has been ad hoc. components that provide direct for software reuse, the majority
Today, complex, high-quality computer-based systems be built in very
short timr This approach to rouse.
But a number of questions arise. Is it possible to construct complex sys-
‘This section contains edited and reorganized version of a series of articles written by
tems by assembling them from a catalog of reusable components? Can this be Edward posted on the Internet in 1994. This mater-
accomplished in a cost- and time-effective manner? Can appropriate incentives ial is used with his permission.
728
730 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING
CHAPTER 26: SOFTWARE REUSE
731
of software developers do not use them. Software products that assist in
known ways of increasing the generality of a software component to a very high
achieving reuse include those that provide infrastructure support (e.g., level.
repositories for reusable components, browsers), tools that help create Of course, there are trade-offs. Increasing the generality may decrease the
reusable components, and entire software reusability systems-tools and efficiency, or even increase the complexity. These and other considerations must
software components specifically designed to aid and foster the reuse of be balanced against such factors as the potential increased reliability resulting
software. from using a known verified component and the cost and time savings result-
Relatively lit&raining is available to help software engineers and man- ing from software reuse.
agers understand and apply reuse. do few training vehicles target Over the years, much has been learned about software reuse. Although
reuse, but the topic is mentioned only briefly in most training that ad- continues about specific issues, the following points are generally
dresses software engineering. accepted:
Many software practitioners continue to believe that reuse is “more trouble
than it’s worth.” It is not uncommon to hear technical personnel recite long !" Much more than source code can be reused. In fact, designs, plans, test data,
lists of the “disadvantages of reusing software.” Managers seem equally and documentation (among other items in the software configuration) can be
committed to maintaining the status quo. Even when managers purchase reused. Code reuse provides the smallest gains in productivity and
the tools and training necessary for rudimentary software reuse, staff re- ity. Significantly greater benefit is achieved by reusing designs and the doc-
sistance to the concept can still be high. umentation associated with “reusable source code.” Therefore, reusability is
Many companies continue to encourage software development methodologies not a concept that is limited to coding.
which do not facilitate reuse (e.g., functional decomposition), while discour- !" Research seems to indicate, and practice seems to show, that the majority of
aging others that seem to encourage reuse (e.g., object-oriented approaches). many software products can be assembled from reusable components.
Few companies provide incentives to produce reusable program components. !" There are any number of metrics associated with software reuse. They range
In fact, there are disincentives, The customer for the current project will be from metrics which measure the sheer bulk of source code and documenta-
hesitant to fund the extra expense required to develop reusable compo- tion reused in an application to metrics which measure the affects of soft-
nents. As a result, project managers push to get the job done with program ware reusability (e.g., software productivity metrics).
components that are as specific as possible.
Software reusability technology is indeed a collection of things. These things
In addition to the technical problems which must be addressed, many other include reusable components, taxonomies, reusability systems, composition con-
connected issues have an impact on reuse. Political, managerial, legal, cultural, cepts, methodologies, and others. This technology is more coupled with the size of
financial, marketing, and productization issues must also be considered. the product than it is with the scale at which the reuse is to take place.
Software design methods (Chapters 14 and do play an important part
in software reuse. Some methods enhance software reuse; others discourage it.
We have known for some time that software designs should be constructed so
26.1.2 A Hardware that they can easily be modified. We are only now beginning to understand that
by bringing software reusability issues to the first phases of the software
process, we can greatly enhance the impact of software reuse. Finally, by study-
In the computer hardware industry, reuse is the norm. For example, there are \ ing the designs of many systems within a particular application domain, can-
standard CPU chips, standard RAM, mathematical and ROM didate components for reuse can be isolated and developed.
chips. These and other integrated circuits are used in a wide variety of appli-
cations. A long time ago, electronics engineers discovered that one of the most
important axioms of reusability was generality
Unlike their counterparts, electronics engineers do not have to 26.1.3 Some for Establishing an Approach to
verify, for example, that every “op-code” supported by a particular CPU is exe-
cuted in a specific application, Nor do they have to demonstrate that every last The following steps will assist an organization in making the changes
byte of RAM is utilized. Electronics engineers have data that provide a quan- to fully exploit the concept of software reusability:
titative indication of the reliability of the chip.
How does one apply the above analogy to reusable software? Consider the 1. Establish an internal software reuse plan. Such a plan can help an orga-
&sign of a reusable software component. To be truly reusable, a software com- nization control both the quality and costs associated with software.
ponent must be usable in some place other than its current specific application 2. Require that software reusability be an integral part of any technical and
part of an application). To increase the chances of this happening, the soft-
managerial training. This should be especially true for object-oriented
ware engineer must make the component more general. In fact, there are training.
732 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 26: SOFTWARE REUSE 733
3. In accordance with an in-house software reusability plan, acquire the tools
and libraries that will most positively contribute to the reuse of software.
4. Encourage the use of methods and tools which have been demonstrated to
enhance the reuse of
5. Track and measure both the reuse of software and the impact of software
1
reuse. Policy decisions should be made on “hard data,” not on guesswork.
6. Management must let it be known that it actively encourages the reuse of
software. Customer
7. Recognize that more than just “modules” can be reused. Tools, test data, de-
signs, plans, environments, and other software items can be reused.
8. Above all, recognize that software reuse is not “business as usual.” A com-
mitment to software reuse will require some changes. These changes should
be introduced in an effective manner. Remember that the concept of soft-
ware reuse is alien to most technical and managerial personnel.
26.2 THE REUSE PROCESS Customer
Evaluation Construction Release
Reuse should be an integral part of every software process. In Chapter 2, a
“component assembly model” (Figure 26.1) was used to illustrate how a
library of reusable components can be integrated into a typical evolutionary FIGURE 26.1. The component assembly model
process model. Later in this section, we explore a process model that em-
phasizes the activities that must occur to make reuse happen. But first, it is
necessary to understand the “artifacts” that are reused when software engi- models and specifications. Models and specifications
neering occurs. for classes and objects (Chapter 20) are obvious candidates for reuse, In ad-
dition, analysis models (e.g., data flow diagrams) developed using conven-
tional software engineering approaches (Chapter can also be reused.
D e s i g n s . Architectural, data, interface, and procedural designs developed
26.2.1 Reusable Artifacts using conventional methods (Chapter are candidates for reuse. More
commonly, system and object designs (Chapter are reused.
We have already noted that software reuse encompasses more than just source S o u r c e c o d e . Verified program components written in compatible pro-
code. But how much more? Capers Jones defines 10 software artifacts gramming languages are candidates for reuse.
that are candidates for reuse:
U s e r a n d t e c h n i c a l d o c u m e n t a t i o n . It is often possible to reuse large
portions of user and technical documentation, even though the specific ap-
P r o j e c t p l a n s . The basic structure and much of the content (e.g., the
plications differ.
SQA plan) of a software project plan (see Part Two of this book) can be
reused from project to project. This reduces the time required to develop H u m a n i n t e r f a c e s . Probably the most widely reused software artifact,
the plan and the uncertainty associated with establishing schedules, risk GUI software is commonly reused. Because it can account for 60 percent of
analysis, and other features. the code volume of an application, the benefits of reuse are significant.
Cost estimates. Because similar function is often implemented in dif- D a t a . Among the most commonly reused artifacts, data encompasses in-
ferent projects, it to estimates (Chapter for that ternal tables, lists, and record structures, as well as files and complete
function with little or no modification. databases.
A r c h i t e c t u r e . There are relatively few distinct program and data archi- T e s t c a s e s . Whenever a design or code component is to be reused, the rel-
tectures (Chapter even when application domains are con- evant test case should be “attached” to it.
sidered. is to create a set of generic architectural templates (e.g.,
a transaction processing architecture) and establish those templates as a Table 26.1 [JON941 presents anecdotal data (from military and system pro-
reusable framework for design. jects) that indicate the return on a $1.00 investment after four years and 24
734 PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING
CHAPTER 26 SOFTWARE REUSE 735
Domain Engineering
VALUE OF SOFTWARE REUSE OVER FOUR YEARS
Reusable Four-year
Artifact Return
Project plans $2.00
Cost estimates 3.00
Architecture 1.50
Requirements models/specs 3
Designs 5.00 ,
Source code 6.00
User/technical documentation 1.50
interfaces 1
Data 3.50
Test 3.50
uses for each of the artifacts noted above. The overall impact is described by
Jones aggregate value of reusing all 10 artifacts generates
what is probably the best return of any known software technology.”
It is important to note that reuse extends beyond the deliverable artifacts
discussed above and also includes elements of the software engineering process.
Specific analysis modeling methods, inspection techniques, test case design
techniques, quality assurance procedures, and many other software engineer-
ing practices can be “reused.” For example, if a software team applies
room software engineering (Chapter 25) effectively, the approach may have rel-
evance to another project. To make this determination, it is necessary to define
a set of characterization functions (Section 26.3.2) that enable potential users
of cleanroom to make an appropriate determination on its applicability.
FIGURE 26.2. A process model that emphasizes reuse
2 6 . 2 . 2 A Process Model
A variety of process models have been proposed for reuse. Each emphasizes
parallel tracks in which domain engineering (Section 26.3) occurs concurrently 26.3 DOMAIN ENGINEERING
with software engineering. Domain engineering performs the work required to
establish a set of software artifacts that can be reused by the software engi- The intent of domain engineering is to identify, construct, catalog, and dissem-
neer. These artifacts are then transported across a “boundary” that separates
inate a set of software artifacts that have applicability to existing and future
domain engineering from software engineering. software in a particular application domain. The overall goal is to establish
Figure 26.2 illustrates a typical process model that explicitly accommo-
mechanisms that enable software engineers to share these artifacts-to reuse
dates reuse Domain engineering creates a model of the application them-during work on new and existing systems.
domain that is used as a basis for analyzing user requirements in the software
Domain engineering includes three major activities-analysis, construc-
engineering flow. The software architecture (and corresponding structure points, tion, and dissemination. An overview of domain analysis was presented in
see Section 26.3.3) provide input for the design of the application. Finally, af-
Chapter 20. However, the topic is revisited in the sections that follow. Domain
ter reusable components have been constructed (as part of domain engineer-
construction and dissemination are considered in later sections in this chapter.
ing], they are made available to the software engineers during the software
“rouse will not by elimination, but in-
construction
tegration” into the of software engineering practice greater
736 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 26: SOFTWARE REUSE 737
emphasis is placed on reuse, some believethat domain engineering will become !" Does the hardware remain unchanged between implementations?
as important as software engineering over the next decade. !"Can the hardware specifics be removed to another component?
!"Is the design optimized enough for the next implementation?
!" Can we parameterize a nonreusable component so that it becomes reusable?
26.3.1 The Domain Analysis Process !" Is the component reusable in many implementations with only minor
changes?
In Chapter 20, we discussed the overall approach to domain analysis within !"Is reuse through modification feasible?
the context of object-oriented software engineering. The steps in the process
!"Can a nonreusable component be decomposed to yield reusable components?
were defined as:
!"How valid is component decomposition for reuse?
1. Define the domain to be investigated.
An in-depth discussion of domain analysis methods is beyond the scope of this
2. Categorize the items extracted from the domain book. For additional information on domain analysis, see
3. Collect a representative sample of applications in the domain
4. Analyze each application in the sample
Develop an analysis model for the objects
26.3.2 Characterization Functions
It is important to note that domain analysis is applicable to any software en-
gineering paradigm and may be applied for conventional as well as object-ori- It is sometimes difficult to determine whether a potentially reusable artifact is
ented development. in fact applicable in a particular situation. To make this determination, it is
Prieto-Diaz expands the second domain analysis step noted above necessary to define a set of domain characteristics that are shared by all soft-
and suggests an eight-step approach to identification and categorization of ware within a domain. A domain characteristic some generic attribute
reusable artifacts: of all products that exist within the domain. For example, generic characteris-
tics might include the importance of safety/reliability, programming language,
1. Select specific functions/objects. concurrency in processing, and many others.
A set of domain characteristics for a reusable artifact can be represented
2. Abstract functions/objects. as where each item, in the a specific domain charac-
3. Define a taxonomy. teristic. The value assigned to represents an ordinal scale that is an indi-
4. Identify common features. cation of the relevance of the characteristic for artifact A typical scale
might be:
5. Identify specific relationships.
6. Abstract the relationships. 1: not relevant to whether reuse is appropriate
7. Derive a functional model. relevant only under unusual circumstances
2:
8. Define a domain language.
3: relevant; the artifact can be modified so that it can be used, despite
differences
A domain language enables the specification and later construction of applica-
4: clearly relevant, and if the new software does not have this charac-
tions within the domain.
teristic, reuse will be reuse may still be possible
Although the steps noted above provide a useful model for domain analy-
sis, they do not provide any guidance for deciding which software artifacts are 5: relevant, and if the new software does not have this charac-
candidates for reuse. Hutchinson and Hindley suggest the following teristic, reuse will be ineffective; reuse is not recommended
set of pragmatic questions as a guide for identifying reusable software
nents: When new software, is to be built within the application domain, a set of do-
main characteristics is derived for it. A comparison is then made between
!" Is component functionality required on future implemcntationn? and to determine whether the existing artifact can be effectively reused
in application
!" How common is the component’s function within the domain?
Table 26.2 lists typical domain characteristics that can have an
!" Is there duplication of the component’s function within the domain?
impact on software reuse. These domain characteristics must be taken into ac-
!" Is the component hardware-dependent? count in order to reuse an artifact effectively.
CHAPTER 26:
PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING 739
738
a as “a distinct construct
: within a structural model.” Structure points have three distinct characteristics:
A structure point is an abstraction that should have a limited number of in-
stances. Restating this in object-oriented jargon (Chapter the size of the
Personnel class hierarchy should be small. In addition, the abstraction should recur
Product Process
throughout applications in the domain. Otherwise, the effort required to ver-
Requirements stability Process Motivation ify, document, and disseminate the structure point cannot be cost-justified.
concurrent Process conformance Education The rules that govern the use of the structure point should be easily un-
Memory constraints Project environment Experience/training derstood. In addition, the interface to the structure point should be rela-
Application size Schedule constraints !" application tively simple.
User interface complexity Budget constraints !" process The structure point should implement information hiding by hiding all
Programming language(s) Productivity !" platform complexity contained within the structure point itself, This reduces the per-
!" ceived complexity of the overall system.
lifetime requirements Development team
Product quality productivity AH an
Product consider the domain of software for systems. This domain might
or complex alarm system for
industrial In case, however, a net of predictable structural
patterns are encountered:
Even when software to be engineered clearly exists within an application
domain, the reusable artifacts within that domain must be analyzed to deter- !" an interface that enables the user to interact with the system
mine their applicability. In some cases (hopefully, a limited number), “rein- !" a bounds setting mechanism that allows the user to establish bounds on the
venting the wheel” may still be the most cost-effective choice. parameters to be measured
!" a sensor management mechanism that communicates with all monitoring
sensors
26.3.3 Structural Modeling and Structure Points !" a response mechanism that reacts to the input provided by the sensor man-
agement system
When domain analysis is applied, the analyst looks for repeating patterns in !" a control mechanismthat enables the to control the manner in which
the applications that reside within a domain. Structural modeling is a monitoring is carried out.
based domain engineering approach that works under the assumption that
every application domain has repeating patterns (of function, data, and behav- Each of these structure points is integrated into a domain architecture.
ior) that have reuse potential. It is possible to define generic structure points that transcend a number of
Pollak and Rissman describe structural models in the following different application domains
way:
Application front end. The GUI, including all menus, panels, input, and
Structural models consist of a small number of structural elements manifest- command editing facilities
ing clear patterns of interaction. The architectures of systems using structural Database. The repository for all objects relevant to the application domain
models are characterized by multiple ensembles that are composed from ‘these
model elements. Thus, the complex interactions among the systems many ar- Computational engine.The numerical and nonnumerical models that
chitectural units emerge from simple patterns of interaction among this small manipulate data
number Reporting facility. The function that produces output of all kinds
Application editor. The mechanism for customizing the application to the
Each application domain can be by a structural model (e.g., air- needs of specific users
craft avionics differ greatly in specifics, but all modern software in this domain
has the same structural model). Therefore, the structural model is an archi-
tectural artifact that can and should be reused across applications within the security system has been used example in earlier chapters.
domain.
740 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING 741
CHAPTER 26: SOFTWARE REUSE
Structure points have been suggested as an alternative to lines of code and to create a new component-that design for reuse should be considered.
function points for estimation A brief discussion of As we have already noted, design for reuse requires the engineer
costing using structure points is presented in Section 26.62. to apply solid software design concepts and principles (Chapter But the
characteristics of the application domain must also be considered. Binder
suggests a number of key issues that should be as a basis
26.4 BUILDING REUSABLE COMPONENTS for design for reuse:
There is nothing magical about creating software that can be reused. Design Standard data. The application domain should be investigated, and stan-
concepts such as abstraction, hiding, functional independence, refinement, and dard global data structures (e.g., file structures or a complete database)
structured programming, along with object-oriented methods, testing, SQA, and should be identified. All design components can then be characterized to
correctness verification methods-all contribute to the creation of software make use of these standard data structures.
components that are In this section we will not revisit these topics. Standard interface protocols. Three levels of interface protocol should
Bather, we consider the reuse-specific issues that are complementary to solid be established: the nature of intramodular interfaces, the design of exter-
software engineering practices. nal technical (nonhuman) interfaces, and the human-machine interface.
Program templates. The structure model (Section 26.3.3) can serve as a
template for the architectural design of a new program.
26.4.1 Analysis and Design Reuse
Once standard data, interfaces, and templates have been established,
the designer has a framework in which to create the design. New components
The components of the analysis model were discussed in detail in Parts Three that conform to this framework have a higher probability for subsequent reuse.
and Four of this book. Data, functional, and behavioral models (represented in
a variety of different notations) can be created to describe what a particular
application must accomplish. Written specifications are then used to describe
these models and result in a complete description of requirements. 26.4.2 Methods
Ideally, the analysis model is analyzed to determine those elements of the
model that point to existing reusable artifacts. The problem is extracting in-
Like design, the construction of reusable artifacts draws on software engineer-
formation from the requirements model in a form that can lead to “specifica-
ing methods that have been discussed elsewhere in this book. Construction can
tion matching.” Bellinsoni and his colleagues describe one approach
be accomplished using conventional third generation programming languages,
for object-oriented systems:
fourth generation languages and code generators, visual programming tech-
niques, or more advanced tools.
Components’are defined and stored as specification, design, and implementa. A representative example of more advanced construction techniques has
tion classes at various levels of abstraction-with each class being an been developed by Inc. Called frame technology, the
neered description of a product from previous applications. The specification approach defines a set of adaptable, generic components called Like ob-
knowledge-is stored in the form of reuse-suggestion jects, frames encapsulate data and operations, but they extend the definition of
classes, which contain directions for retrieving reusable components on the ba- an object by incorporating mechanisms that enable a software engineer to
sis of their description and for composing and tailoring them after retrieval. adapt the frame by selecting, deleting, modifying, or iterating any of the
components that make up the frame.
Automated tools are used to browse a repository in an attempt to match the An application is constructed by assembling components from a frame hi-
roquiremont in with described for exist- erarchy. at the bottom of the hierarchy are analogous to worker mod-
ing reusable components (classes). Characterization functions (Section 26.3.2) ules in a architecture (Chapter 13). That is, they contain data struc-
and keywords are used to help find potentially reusable components, tures and operations that perform low-level system functions (e.g., operating
If matching that fit of the cur- system interaction, interface construction, database interaction). Frames that
application, the designer can extract these components from a reuse li- reside in the middle of the hierarchy focus on functions that are relevant to
brary (repository) and use them in the design of the new system. If design com- specific information systems domains (e.g., transaction processing, banking,
ponents cannot be found, the software engineer apply conventional or 00 service). At the top of the hierarchy is a “specification frame” that acts
design methods to create them. It is at this point-when the designer begins
‘In general, the preparations noted for design for should undertaken part of do-
learn more about these topics, Chapters 13, 14, 16, 17, and 2.5 main engineering (Section 27.3).
742 PART ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 26: SOFTWARE REUSE 743
as “the master blueprint for the system and the only frame that the developer A consortium of major companies (including IBM,
creates to the system” Apple, and Novell) proposed the standard for
uments and component software. The standard defines the services, control
infrastructure, and architecture that must be implemented to enable com-
ponents provided by one developer to interoperate with components pro-
\
26.4.3 Component-Based Development vided by another developer.
The Object Management Group has published a common
When reuse predominates during the of an application, the con- object request broker architecture An object request broker
struction approach is sometimes referred to as component-based development provides a variety of services that enable reusable components (ob-
or component software. As we have already seen, domain engineering provides jects) to communicate with other components, regardless of their location
the library of reusable components that are required for component-based de- within a system. When components are built using the stan-
velopment. Some of these reusable components are developed in-house, others dard, integration of those components (without modification) within a sys-
can be extracted from existing applications, and still others may be acquired tem is
from third parties. To use a client/server metaphor, objects within the client application
But how do we create a library of components that have a consistent struc- request one or more services from the ORB server. Requests are made via
ture-that can be acquired from a variety of different internal and external IDL or dynamically at run-time. An interface repository contains all nec-
sources and still be integrated into any system within an application domain? essary information about the service requests and response formats.
The answer lies in the adoption of a standard for such components. A set of four CORBA is discussed further in Chapter 28.
“architectural ingredients” should be present to implement compo- OLE 2.0. Microsoft has developed a component object model that
nent-based development: provides a specification for using objects produced by various vendors within
a single application. Object linking and embedding is part of COM
Data exchange model. Mechanisms that enable users and applications and defines a standard structure for reusable components. OLE is used as
to interact and transfer data (e.g., drag and drop, cut and pastel should be part of Microsoft’s operating systems (e.g., Windows 95, Windows NT).
defined for all reusable components. The data exchange mechanisms not
only allow human-to-software and component-to-component data transfer, Which of these standards will dominate the industry’? There is no answer
hut to at this time. Currently is used more widely (due to widespread use in
printer icon for output.) Windows-based applications). But many OMGKORBA tools and development
Automation. A variety of tools, macros, and scripts should be implemented environments are being introduced. For further discussion of component stan-
to facilitate interaction between reusable components. dards and the tools that support them see and
Structured storage. Heterogeneous data graphical data, voice, text,
and numerical data) contained in a “compound document” should be orga-
nized and accessed as a single data structure rather than a collection of 26.5 CLASSIFYING AND RETRIEVING COMPONENTS
separate files. “Structured data maintains a descriptive index of nesting
structures that applications can freely navigate to locate, create, or edit in- Consider a large university library. Tens of thousands of books, periodicals, and
dividual data contents as directed by the end user” other information resources are available for use. But to access these resources,
Underlying object model. The object model ensures that components de- a categorization scheme must be developed. To navigate this large volume of
veloped in different programming languages that reside on different plat- information, librarians have defined a classification scheme that includes a li-
forms can be interoperable. That is, objects must be capable of communi- brary of congress classification code, keywords, author names, and other index
cating across a network. To achieve this, the object model defines a standard entries. All enable the user to find the needed resource quickly and easily.
for component interoperability. The standard is language independent and Now, consider a large component repository. Tens of thousands of reusable
is defined using an interface definition language software components reside in it. But how does a engineer the
Because the potential impact of reuse on the software industry is enor- one she needs? To answer this question, another question arises: How do we
mous, a number of major companies and industry have proposed describe software components in unambiguous, classifiable terms? These are
standards for component software: difficult questions, and no definitive answer has yet been developed. In this sec-
tion we explore current directions that will enable future software engineers to
navigate reuse libraries.
excellent discussion of objects” that discussed briefly here
presented in documents be obtained at
745
744 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 26: SOFTWARE REUSE
26.5.1 Describing Reusable Components Indexing
Vocabularies
A reusable software component can be described in many ways, but an ideal
description encompasses what has called the 3C
content, and context.
The concept of a software component is description of what the compo-
Controlled
nent does” The interface to the component is fully described and the
semantics-represented within the context of pre- and postconditions-is iden-
tified. The concept should communicate the intent of the component.
The content of a component describes how the concept is realized. In essence, Terms not extracted
Classed Keyword Terms extracted
the content is information that is hidden from casual users and need be known from text
I I from text
only to those who intend to modify the component.
The context places a reusable component within its domain of
That is, by specifying conceptual, operational, and implementation
features, the context enables a engineer to the appropriate com-
ponent to meet application requirements.
To be of use in a pragmatic setting, concept, content, and context must be FIGURE 26.3. A
translated into a concrete specification scheme. There have been dozens of pa- taxonomy of indexing
pers and articles written about classification schemes for reusable software methods from library
The methods proposed can be categorized into three major areas: science
library and information science methods, artificial intelligence methods, and
hypertext systems. The vast majority of work done to date suggests the use of
library science methods for component classification.
Figure 26.3 presents a taxonomy of library science indexing methods. resize
Controlled indexing vocabularies limit the terms or syntax that can be used to via command
classify an object (component). Uncontrolled indexing vocabularies place no re-
strictions on the nature of the description. The majority of classification schemes via drag
for software components fall into three categories:
up/down shuffle
Enumerated Components are described by defining a hierarchical . .
structure in which classes and varying levels of subclasses of software compo- move
nents are defined. Actual components are listed at the lowest level of any path . .
in the enumerated hierarchy. For example, an enumerated hierarchy for win- close
dow might be . .
window operations The hierarchical structure of an enumerated classification scheme makes it
display easy to understand and to use. However, before a hierarchy can be built, do-
main engineering must be conducted so that sufficient knowledge of the proper
menu-based entries in the hierarchy is available.
open Window
system-based Faceted A domain area is analyzed, and a set of basic descriptive
sys Window features are identified. These features, called are then prioritized by im-
close portance and connected to a component. A facet can describe the function that
via pointer the component performs, the data that are manipulated, the context in which
. they are applied, or any other feature. The set of facets that describe a
nent is called the facet descriptor. Generally, the facet description is limited to
no more than seven or eight facets.
bibliography. As a simple illustration of the use of facets in component classification,
small subset of all possible operations noted.
is the following facet, descriptor:
744 PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 26. SOFTWARE REUSE 747
[function, object type, system type) Each of these functions interacts with or is embodied within the confines of a
reuse library.
Each facet in the facet descriptor takes on one or more values that are gener- The reuse library is one element of a larger CASE repository (Chapter 29)
ally descriptive keywords. For example, if function is a facet of a component, and provides facilities for the storage of a wide variety of reusable artifacts
typical values assigned to this facet might be: (e.g., specifications, designs, code, test cases, user guides). The library encom-
passes a database and the tools that are necessary to query the database and
from it. A component scheme (Section 26.51)
serves as the basis for library queries.
The use of multiple facet values enables copy to be re-
Queries are often characterized using the context element of the 3C Model
lined more fully.
described earlier. If an initial query results in a voluminous list of candidate
Keywords are assigned to the set of facets for each component in
is to narrow the list. and infor-
a reuse library. When a software engineer wants to query the library for
mation are then extracted (after candidate components are found) to assist the
ble components for a design, a list of values is specified and the library is
developer in selecting the proper component.
searched for matches. Automated tools can be used to incorporate a thesaurus
A of rouse libraries and tools that
This enables the search encompass not only keyword specified
manage them is beyond the scope of this book. The interested reader should see
by the software engineer, but also technical synonyms for those keywords.
and for additional information.
A faceted classification scheme gives the domain engineer greater flexibil-
ity in specifying complex descriptors for components Because new
facet values can be added easily, the faceted classification scheme is easier to
extend and adapt that the enumeration approach.
26.6 ECONOMICS OF SOFTWARE REUSE
Attribute-Value C l a s s i f i c a t i o n A set of attributes arc defined for all components
in a domain area. Values are then assigned to these attributes in much the Software reuse has an intuitive appeal. In theory, it should provide a software
same way as faceted classification. In fact, attribute value classification is sim- organization with advantages in quality and timeliness. And these should
ilar to faceted classification with the following exceptions: (1) There is no limit translate into cost savings. But are there hard data that support our intuition?
on the number of attributes that can be used; (2) attributes are not assigned To answer this question we must first understand what it is that can be
priorities; and the thesaurus function is not used. reused in a software engineering context and then what the costs associated
with reuse really are. As a consequence, it is possible to develop a cost-benefit
Based on an empirical study of each of the above classification techniques, analysis for reuse.
Frakes and Pole indicate that there is no clear technique and
that “no method did more than moderately well in search effectiveness. . It
would appear that further work remains to be done in the development of ef-
fective classification schemes for reuse libraries. 26.6.1 Impact on Quality, Productivity, and Cost
Over the past few years, considerable evidence from industry case studies
indicates that substantial business benefits can
26.5.2 The Reuse Environment ho from Product quality, development pro-
ductivity, and overall cost are all improved.
Software component reuse must be supported by an environment that encom-
passes the following elements: Quality In an ideal setting, a software component that is developed for reuse
would be to bc correct (see Chapter 25) and would contain no defects.
!" a component database capable of storing software components and the clas- In reality, formal verification is not carried out routinely, and defects can and
sification information necessary to retrieve them do occur. However, with reuse, defects are found and eliminated, and a
component’s quality improves as a result. Over time, the component becomes
!" a library management system that provides access to the database
virtually defect free.
!" a software component retrieval system (e.g., an object request broker) that al-
In a study conducted at Hewlett-Packard, Lim reports that the de-
lows a client application to retrieve components and services from the library fect rate for reused is 0.9 defects per KLOC, while the rate for newly de-
server veloped software is 4.1 defects per For an application that was com-
!" CASE tools that support the integration of reused components into a new posed of 68 percent reused code, the defect rate was 2.0 defects per KLOC-a
sign or implementation. 51 percent improvement from the expected rate, had the application been
748 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 26: SOFTWARE REUSE 749
veloped without reuse. Henry and Faller report a 35 percent These structure points are either reusable components or packages
provement in quality. Although anecdotal reports span a reasonably wide spec- of reusable components.
trum of quality improvement percentages, it is fair state that reuse provides Even though structure points are reusable, their adaptation, integration,
a nontrivial benefit in terms of the quality and reliability for delivered soft- and maintenance costs are not trivial. Before proceeding with reuse, the pro-
ware. , ject manager must understand the costs associated with the use of structure
points.
Productivity When reusable artifacts are applied throughout the software Since all structure points (and reusable components in general) have a past
process, less time is spent creating the plans, models, documents, code, and data history, cost data can be collected for each. In an ideal setting, the adaptation,
that are required to create a deliverable system. It follows that the same level integration, and maintenance costs associated with each component in a reuse
of functionality is delivered to the customer with less input effort. Hence, pro- library are maintained from each instance of usage. These data can then be an-
ductivity is improved. Although percentage productivity improvement reports alyzed to develop projected costs for the next instance of reuse.
are notoriously difficult to it appears that 30 to 50 percent reuse can As an example, consider a new application, X, that requires 60 percent new
result in productivity improvements in the 25 to 40 percent range. code and the reuse of three structure points, and Each of these
reusable components has been used in a number of other applications, and av-
Cost The net savings for reuse are estimated by projecting the cost of the erage costs for adaptation, integration, and maintenance are available.
project if it were developed from scratch, and then subtracting the sum of To estimate the effort required to deliver the following must be deter-
the costs associated with reuse, C,, and the actual cost of the software as de- mined:
livered, overall effort + +
can be determined by applying one or more of the estimation techniques
discussed in Chapter 5. The costs associated with reuse, include
where i the effort required to engineer and construct new software
!" Domain analysis and modeling components (determined using techniques described in Chapter
!" Domain architecture development E is the effort required to adapt and
!" Increased documentation to facilitate reuse is the effort required to integrate and
!" Maintenance and enhancement of reuse artifacts
!" and licenses for externally acquired components The effort required to adapt and and SP3 is determined by
!" Creation or acquisition and operation of a reuse repository
taking the average of historical data collected for adaptation and integration of
the reusable components in other applications.
!" Training of personnel in design and construction for reuse
Although costs associated with domain analysis (Section 26.4) and the opera-
tion of a reuse repository can be substantial, they can be amortized across 26.6.3 Reuse Metrics
many projects. Many of the other costs noted above address issues that are part
of good software engineering practice, whether or not reuse is a priority. A variety of software metrics have been developed in an attempt to measure
the benefits of reuse within a compulcr-based system. The associated
a ho
= (26.1)
26.6.2 Cost Analysis Using Structure Points
In Section 26.3.3, we defined a structure point as an architectural pattern that is the cost of developing with no reuse
where
recurs through a particular application domain. A software designer (or system
engineer) can develop an architecture for a new application, system, or product c is the cost of developing with reuse
by defining a domain architecture and then populating it with structure points.
It follows that can be expressed as a nondimensional value in the range
(26.2)
extenuating circumstances application problem complexity, team
structure and project duration, can impact on the pro- Devanbu and his colleagues suggest that be affected by the
ductivity of a project team. design of the system; since is effected by the design, it is important to
750 PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 26: REUSE 751
make a part of an assessment of design alternatives; and the benefits as- REFERENCES
sociated with reuse are closely aligned to the cost benefit of each individual
reusable component. The higher the value of the more attractive reuse
becomes. Adler, R.M., “Emerging Standards for Component Software, IEEE
A general measure of reuse in object-oriented systems, termed reuse Computer, vol. 28, no. 3, March 1995, pp.
age is defined as: L.C. and W.M. Thomas, “Domain Analysis for the
Reuse of Software Development Experiences,” 19th Annual
R (26.3)
Workshop, MD, December
where is the number of objects reused in a system 1994.
Bassett, What Is Frame Inc., Toronto, Canada,
is the number of objects built for a system October 1994.
El.951 R., M.G. Gugini, and B. Pernici, “Reusing Specifications in
follows that as increases, also increases. 00 Applications,” Software, March 1995, pp. 65-75.
Binder, R., is for Real,” Programmer. vol. 6,
Christensen, S.R., “Software Reuse Initiatives at Lockheed,”
vol. 8, no. 5, May 1995, pp.
26.7 SUMMARY . I? “Analytical and Empirical Evaluation of Software
Metrics.” Science Department,
University of Maryland, August 1995.
Component reuse offers inherent benefits in software quality, developer pro-
Frakes, and Pole, “An Empirical Study of Representation
ductivity, and overall system cost. And yet, many roadblocks must be overcome
Methods for Software Components,” IEEE Trans.
before the reuse process model is widely used throughout the industry.
vol. 20, no. 8, August 1994, pp. 617-630.
A variety of reusable artifacts can be acquired by a software engineer.
Freeman, I?, “A Perspective on Reusability,” in Software Reusability, I?
These include technical representations of the software (e.g., specifications, ar-
Freeman IEEE Computer Society Press, 1967, pp. 2-3.
chitectural models, design, and code), documents, test data, and even
Henry, E., and B. “Large Scale Industrial Reuse to Reduce Cost
related tasks inspection techniques).
and Cycle Time, ZEEE Software, September 1995, pp. 47-53.
The reuse process encompasses two concurrent subprocesses-domain en-
Hooper, J.W., and R.O. Chester, Software Reuse: Guidelines and Methods,
gineering and software engineering. The intent of domain engineering is to
Plenum Press, 1991.
identify, construct, catalog, and disseminate a set of software artifacts in a par-
Hutchinson, J.W., and Hindley, “A Preliminary Study of Large Scale
ticular application domain, engineering then extracts these artifacts
Software Reuse,” Software Engineering Journal, vol. 3, no. 5, 1988, pp.
for reuse during the development of a new system.
Analysis and design techniques for reusable components draw on the same
[JON941 Jones, C., “The Economics of Object-Oriented Software,” American
principles and concepts that are part of good software engineering practice.
Programmer, vol. 7, no. 10, October 1994, pp. 28-35.
Reusable components should be designed within an environment that estab-
Liao, H., and Wang, “Software Reuse Based on a Large
lishes standard data structures, interface protocols, and program architectures
Oriented Library,” Software Engineering Notes, vol. 18, no. 1, January
for each application domain.
1993, pp. 74-80.
Component-based development uses a data exchange model, tools, struc-
Lim, “Effects of Reuse on Quality, Productivity, and Economics,
tured storage, and an underlying object model to construct applications from
pre-existing components. The object model generally conforms to one or more ZEEE Software, September 1994, pp.
Linthicum, D.S., “Component Development special feature),
component standards (e.g., that define the manner in which an
Application Development Trends, June 1995, pp. 57-78.
application can access reusable objects. Classification schemes enable a devel-
PE., “Pattern-Based Architecture: Bridging Reuse
oper to and retrieve reusable components and conform to a model that
and Cost Management, Crosstalk, vol. 8, no. 3, March 1995, pp. 19-16.
identities concept, content, and context. Enumerated classification, faceted clas-
Orfali, R., D. and J. Edwards, The Essential Distributed Objects
sification, and attribute-value classification are representative of many compo-
nent classification schemes. Guide, Wiley, 1996.
Pollak, W., and M. Rissman,, ‘Structural Models and Patterned
The economics of software reuse are addressed by a single question: Is it
Architectures,” IEEE Computer, vol. 27, no. 8, August 1994, pp. 67-68.
cost effective to build less and reuse more? In general, the answer is “yes,” but
R., “Domain Analysis for Reusability,” ‘87,
a software project planner must consider the nontrivial costs associated with
Tokyo, October 1987, pp. 23-29.
the adaptation and integration of reusable components.
ADVANCED TOPICS IN SOFTWARE ENGINEERING 26: REUSE 753
R., and Experiences in Software Reuse,” American 26.12. Research the literature to acquire recent quality and productivity data that
Programmer, vol. 6, no. 8, August 1993, pp. support the use of reuse. Present the data to your class.
W., “Constructing Applications from Reusable Components,”
26.13. An object-oriented system is estimated to require 320 when complete.
IEEE Software, September 1994, pp. 61-68. It is further estimated that 190 objects can be acquired from an existing
W., Does Reuse Start?” Realities Workshop, repository. What is the reuse leverage? Assume that new objects cost $1000,
Syracuse University CASE Center, January 1990. and that it costs $600 to adapt an object and $400 to integrate an object.
“Third International Conference on Software Reuse
What is the estimated cost of the system? What is the value for
Summary,” Software Engineering Notes, vol. 20, no. 2, April 1995, pp.
21-22.
Whittle, B., “Models and Languages for Component Description and
Reuse,” Software Engineering Notes, vol. 20, no. 2, April 1995, pp. 76-89.
E., “Software Reuse,” Application Development Strategies, FURTHER READINGS AND OTHER INFORMATION SOURCES
Cutter Information Corp., vol. VI, no. 12, December 1994, p. 11.
The literature on reuse is growing rapidly. Lim (Managing Software Reuse,
Prentice-Hall, 1996) discusses management issues such as cost justification
and strategies to implement and deploy reuse in a corporate environment.
Bassett (Framing Software Reuse: Lessons from the Real World,
PROBLEMS AND POINTS TO PONDER 1996) describes an industry implementation of automated tools for achieving
reuse of large scale information systems projects. A more technical approach to
26.1. One of the key roadblocks to reuse is getting software developers to consider reuse has been written by Karlsson (Software Reuse: A Holistic Approach,
reusing existing components, rather than reinventing new ones. (After all, Wiley, 1995).
building things is fun!) Suggest three or four different ways in which a Tutorials by Freeman (Software Reusability, IEEE Computer Society
ware organization can provide incentives for software engineers to reuse. Press. 19871 and Trecz (Software Reuse: Emerging Technology, IEEE Computer
What technologies should be in place to support the reuse effort? Society Press, 1988) are excellent anthologies of early papers. Hooper and
26.2. Among the “reuse artifacts* discussed in this chapter wore project plans and Chester cover all important subtopics and present a comprehensive
cost estimates. How can these be reused and what are the benefits of doing bibliography. (Confessions of a Used Program Salesman:
so? Institutionalizing Software Reuse, Addison-Wesley, 19951 presents a some-
26.3. Do a bit of research on domain engineering and flesh out the process model times lighthearted, but meaningful, discussion of the issues associated with
outlined in Figure 26.2. Identify the tasks that are required for domain creating a reuse culture. Nierstresz and Tsichritzis (Object-Oriented Software
analysis nnd Prentice-Hall, 19961 have edited a book that presents the re-
26.4. How are characterization functions for application domains and component sults of a series of research projects related to object-oriented software com-
classification schemes the same? How are they different? position and reuse.
Collections edited by Biggerstaff and Perlis Reusability, Volumes.
26.5. Develop a set of domain characteristics for information systems that are
1 and 2, ACM Press, 19891 and Schaefer, and (Software
evant to a university’s data processing. Reusability, Ellis New York, 1994) contain useful insight into
26.6. Develop set of domain characteristics that are relevant for word-process- ing research and opinion. September 1994 issue of Software is ded-
ing/desk-top publishing software. icated to reuse and contains a number of useful articles.
26.7. Develop a simple structural model for an application domain assigned by Books on the prevailing standards for object reuse have been written by
your instructor or one with which you are familiar. Orfali (The Essential Distributed Objects Survival Guide, Wiley, 19951,
26.8 What is a structure point? and Essential CORRA, Wiley, and Denning Controls:
26.9. Acquire a copy of the most recent standard and prepare a Inside and Microsoft Press, 1995). Each of these books provides detailed
three to five page paper that discusses its major highlights. Get information technical descriptions of the object model.
on an object-request broker tool and illustrate how the tool achieves the The electronic newsletter “Reuse News” is published regularly and can
standard. be found posted on a number of software related newsgroups including
comp.object and comp.software-eng. A wide array of information sources
26.10. Develop an enumerated classification for an application domain assigned by
on reuse are available on the World Wide Web. Many contain pointers to
your instructor or one with which are familiar.
other sites. The following Web sites provide FTP for a wide variety of inter-
26.11. Develop a faceted classification scheme for an application domain assigned esting papers on reuse, including a discussion of reuse metrics and other re-
by your instructor or one with which you are familiar. lated topics:
754 PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 26 SOFTWARE 755
Reusable Software (CARDS)
Reuse Based on 00 Technology
The following Web sites contain general information on reuse, technical pa-
pers, and/or pointers to sources of information on reuse and related topics: An up-to-date list of World Wide Web references for software reuse can be
found at:
ARPS STARS Reuse Paper
ASSET
Courseware in Software Reuse
European SER Consortium
Loral Domain Engineering
Object Management Group
Pacific Software Research Center
SE Information
Design by Reuse
SPC Reuse Adoption Guidebook
ducts/reuse-adoption.gb.html
U.
Information on using the WWW to maintain a reuse library can be found at:
Reusable software libraries in a number of different application domains can
be accessed by exploring the following Web sites:
Defense Software Repository
page.html
Electronic Library Services
Guide to Mathematical Software
HPCC National Software Exchange
Public Software Archives
Public Ada Library
757
Software is often the realization of the business rules that Hammer dis-
cusses. As these rules change, software must also change. Today, major com-
panies have tens of thousands of computer programs that support the ‘old
business rules.” As managers work to modify the rules to achieve greater
and competitiveness, software must keep pace. In some cases, this
means the creation of major new computer-based systems, but in many oth-
ers, it means the modification and/or rebuilding of existing applications so
that they will be competent to meet the business needs of the twenty-first
century.
In this chapter we examine reengineering in a top-down manner, beginning
with an overview of business process reengineering and proceeding to a more
detailed discussion of the technical activities that occur when software is
reengineered.
27.1 BUSINESS PROCESS REENGINEERING
Business process reengineering extends far beyond the scope of informa-
tion technologies and software engineering. Among the many definitions (most
somewhat abstract) that have been suggested for BPR is one published in
Fortune magazine “the search for, and the implementation of, radical
change in business process to achieve breakthrough results.” But how is the
a seminal article written for the Harvard Business Michael search conducted, and how is the implementation achieved? More important,
Hammer laid the foundation for a revolution in management how can we ensure that the “radical change” that is suggested will in fact lead
thinking about business processes and computing: to results” instead of organizational chaos?
During the early there was much hype associated with BPR. Today,
It is time to stop paving the cow paths. Instead of embedding outdated processes the mood has mellowed. In fact, many of the early proponents of BPR have
in silicon we should obliterate them and start over. We should moderated their view considerably However, no one questions the need to make
“reengineer” our businesses: use the power of modern information technology business more competitive. Information technology is the means to this end.
to radically redesign our business processes in order to achieve dramatic im- Whether BPR has a role is a continuing topic of debate.
provements in their performance. An overview of business process reengineering is presented in this section.
Every company operates according to a great many unarticulated rules. Our intent is to establish a context into which software reengineering can be
Reengineering strives to break away from the old rules about how we organize placed.
and conduct our business.
Like all revolutions, Hammer’s call to arms’ has resulted in both positive and
27.1.1 Business Processes
negative changes. Some companies have made a legitimate effort to reengineer,
and the results have led to improved competitiveness. Others have relied solely
on downsizing and outsourcing of reengineering) to improve their bot- A business process is set of logically related tasks performed to achieve a de-
tom line. Too often, “moan” organizations with little for future growth fined Within the business process, people, equip-
have resulted ment, material resources, and business procedures are combined to produce a
But what is the nexus between business reengineering and software engi- specified result. Examples of business processes include:
neering? The answer lies in a “system view.”
!"designing a new product
!" purchasing services and supplies
!" hiring a new employee
‘Hammer’s notoriety and influence grew dramatically when he co-authored the best-selling
book, the Corporation !" paying suppliers
756
FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 759
758
Each demands a set of tasks, and each draws on diverse resources within the
business.
Every business process has a defined customer-a person or group that re-
ceives the outcome (e.g., an idea, a report, a design, a product). In addition,
business processes cross organizational boundaries. They require that different
organization groups participate in the “logically related tasks” that define the Information
In Chapter 10, we noted that every is actually a hierarchy of sub- Capabilities
systems. A business is no exception. Figure 27.1 illustrates the hierarchy in
which BPR The overall business is segmented into a number of busi-
ness systems (also called business functions). Each business system is com- FIGURE 27.2.
J
posed of one or more business processes, and each business process is defined The relationship be-
by a set of subprocesses. tween IT and BPR
BPR can be applied at any level of the hierarchy shown in Figure 27.1, but
as the scope of BPR broadens (i.e., as we move upward in the hierarchy), the
risks associated with BPR grow dramatically. For this reason most BPR efforts As an example, consider the notebook computer. As this technology became
focus on individual processes or subprocesses. widespread, it spurred changes in many business processes. Salespeople could
There is a strong cyclical relationship between the capabilities of informa- provide instant price quotes for even the most complex job or product. Product
tion technologies (IT) and the process reengineering that takes place within a catalogs disappeared and were replaced by CD-ROMs or diskettes, which could
business. As IT capabilities grow, they can drive business processes. be accessed on the spot. As the sales process changed, people in the field saw
Figure 27.2 illustrates this relationship. additional opportunity, Communication with the home office was a must, they
said. IT responded with new notebook computers (and appropriate software)
that provided cellular communication capabilities. The cycle continues.
The Business 27.1.2 Principles of Process Reengineering
In many ways, BPR is identical in focus and scope to the information engi-
neering process discussed in Chapter 10. In an ideal setting, BPR should occur
in a top-down manner, beginning with the identification of major business ob-
jectives and goals, and culminating with a much more detailed specification of
Business the tasks that define a specific business process.
Hammer suggests a number of principles that guide BPR activi-
ties when they begin at the top (business) level:
Organize outcomes, not tasks. Many companies have compartmen-
talized business activities so that no single person (or organization) has re-
sponsibility (or control) of outcome. It such cases, it is
to of work to debug
Process Process ! Process problems if they do occur. BPR should design processes that avoid this
problem.
Have those who use the o&put of the process perform the process. The
tent of this recommendation is to allow those who need business output to
control all of the variables that allow them to get the output in a timely
Business Business Business manner. The separate constituencies that are involved in a
Subprocess Subprocess !" !" ! Subprocess the smoother the ioad to an rapid outcome.
FIGURE 27.1.
The business-o #l.l.k Incorporate information processing work into the real work that produces
of the raw information. As IT becomes more distributed, it is possible lo-
PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27: 761
most information processing within the organization that produces the
raw data. This localizes control, reduces communication time, and puts
computing power in the hands of those who have a vested interest in the
information that is produced.
dispersed resources as though they were centralized.
huve become sophisticated that geo-
graphically diverse groups can be placed in the same “virtual office.” For
example, instead of running three engineering shifts at a single location, a
global company can run the one shift in Europe, a second shift in North
America, and a third shift in Asia. In each case, engineers will work dur-
ing daylight hours and communicate via high-bandwidth networks.
Link parallel activities instead of integrating their results. When different
constituencies are performing work in parallel, it is essential to design a
process that demands continuing communication and coordination.
Otherwise, integration problems are sure to result.
Put the decision point where the work is performed, and build control into
the process. Using software design jargon, this principle suggests a flatter
organizational architecture with reduced factoring.
Capture data once, its source. Data should be stored on-line so that once
collected it need never be re-entered.
Each of the above principles represents a “big picture” view of BPR. Guided by
these principles, business planners and process designers must begin process re- FIGURE 27.3.
design. In the next section, we examine the process of BPR in a bit more detail. A BPR model
each process that is to be redesigned. Within the context of BPR, use cases
identify a scenario that delivers some outcome to a customer. With the use
A BPR Model case as the specification of the process, a new set of tasks (that conform to
the principles noted in are designed for the process.
Like most ongineering activities, business process reengincering is iterative. A redesigned business process must be before it
Business goals and the processes that achieve them must be adapted to a is fully integrated into the business. This activity “tests” the process so that
changing business environment. For this reason, there is no start and end to refinements can be made.
BPR-it is an evolutionary process. A model for business process reengineering
is depicted in Figure 27.3. The model defines six activities: Refinement and instantiation. Based on feedback from the prototype, the
business process is refined and then instantiated within a business system.
Business definition. Business goals are identified within the context of
four key drivers: cost reduction, time reduction, quality improvement, and The BPR activities described above are sometimes used in conjunction with
personnel development and empowerment. Goals may be defined at the analysis tools The intent of these tools is to build a model of existing
business level or for a specific component of the business. to better analyze existing processes. In addition the model-
ing techniques commonly associated with information engineering activities such
Process identification. Processes that are critical to achieving the goals as information strategy planning and business area analysis (Chapter can be
defined in business definition are identified. They may then be prioritized used to implement the first four activities described in the process model.
by importance, by need for change, or in any other way that is appropriate
for the reengineering activity.
evaluation. The existing process is thoroughly analyzed and
measured. Process tasks are identified; the costs and time consumed by 27.1.4 Words of
process tasks are noted; and quality/performance problems are isolated.
Process and design. on dur- is not uncommon that a new business approach-in thin case at
ing the first three BPR activities, for an a and no thnt it a pariah.
PART ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27
Over the past few years, a debate has raged about the efficacy of BPR (e.g., produce new software because all available resources are expended maintain-
In an excellent summary of the case for and against BPR, ing old software.
Weisz summarizes the argument in the following way: Uninitiated readers may ask why so much maintenance is required and
why so much effort is expended. Osborne and Chikofsky provide a par-
It is tempting to bash as another silver-bullet fad. From several points of tial answer:
view-systems thinking, peopleware, simple history-you’d have to predict high
failure rates for the concept, rates to be borne out by empirical ev- Much of the software we depend on today is on average 10 15 years old. Even
idence. For many companies, the silver bull’& has apparently missed. when these programs were created using the best design and coding techniques
For others, though, the reengineering effort has evidently been fruitful known at the time land most were they were created when program size
and storage space were principal concerns. They were then migrated to new
BPR can work, if it is applied by motivated, trained people who recognize that platforms, adjusted for changes in machine and operating system technology
process reengineering is a continuous activity. If BPR is conducted effectively, and enhanced to meet new user needs-all without enough regard to overall
information systems are better integrated into the business process. architecture.
Reengineering older applications can be examined in the context of a The result is the poorly designed structures, poor coding, poor logic, and
based business strategy, and priorities for software reengineering can be es- poor documentation of the software systems we are now called on to keep run-
tablished intelligently. ning
But if business is a that is rejected by a com-
pany, software is something done. Tons of thou- ubiquitous nature underlies all software work. Change is in-
sands of legacy systems-applications that are crucial to the success of busi- evitable when computer-based systems are built; therefore, we must develop
nesses large and small-are in dire need of refurbishing or rebuilding. mechanisms for evaluating, controlling and making modifications.
Upon reading the paragraphs above, a reader may protest: “but I don’t
spend 60 percent of my time fixing mistakes in the programs I develop.”
Software maintenance is, of course, far more than “fixing mistakes.” We may
27.2 SOFTWARE define maintenance by describing four activities that are undertaken
after a program is released for use:
The scenario is all too common: An application has served the business needs
of company for 10 or During has !" corrective maintenance
and enhanced many times, People approached this work with the best !" adaptive maintenance
tions, but good software engineering practices were always shunted to the side !" maintenance or enhancement
(the press of other matters). Now the application is unstable. It still works, but
!" preventive maintenance or reengineering
every time a change is attempted, unexpected and serious side effects occur. Yet
the application must continue to evolve. What to do?
Unmaintainable software is not a new problem. In fact, the broadening em- Only about 20 percent of all maintenance work is spent “fixing mistakes.” The
phasis on software reengineering has been spawned by a software maintenance remaining 80 percent is spent adapting existing systems to changes in their ex-
“iceberg” that has been building for more than three decades. ternal environment, making enhancements requested by users, and
I neering an application for future use. When maintenance is considered to en-
compass all of these activities, it is relatively easy to see why it absorbs so
much effort.
27.2.1 Software Maintenance
Almost 30 years ago, software maintenance was characterized as an
“iceberg.” we hoped that what was immediately visible was all there was to it 27.2.2 A Sofhvare Reengineering Process Model
but we knew that an enormous mass of potential problems and cost lay under
the surface. In the early 1970s the maintenance iceberg was big enough to sink Reengineering takes time; it costs significant amounts of money, and absorbs
an aircraft carrier. Today, it could easily sink the entire Navy! resources that might be otherwise occupied on immediate concerns. For all of
The maintenance of existing software can account for over 60 percent of all these reasons, reengineering is not accomplished in a few months or even a few
effort expended by a development organization, and the percentage continues years. Reengineering of information systems is an activity that will absorb in-
to rise as more software is produced On the horizon we can foresee formation technology resources for many years. That’s why every organization
“maintenance-bound” software development organizations that can no longer needs a pragmatic strategy for software reengineering.
764 PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27: 765
A workable strategy is encompassed in a reengineering process model.
We’ll discuss the model later in this section, but first, some basic principles.
Beengineering is a rebuilding activity, and we can better understand the forward inventory
reengineering of information systems if we consider an analogous activity: re- engineering analysis
\
building a house. Consider the following situation:
Let’s assume that you’ve purchased house in another state. You’ve never
actually seen the property, but you acquired it at an amazingly low price, with
the warning that it might have to be completely rebuilt. How would you pro-
ceed?
data
!" Before you can start rebuilding, it would seem reasonable to inspect the rest
house. To determine whether it is in need of rebuilding, you (or a professional
inspector) would create a list of criteria so that your inspection would be sys-
tematic.
!" Before you tear down and rebuild the entire house, be sure that the struc-
ture is weak. If the house structurally sound, it may be possible to
code
model” without rebuilding much lower cost and in much less time). FIGURE 27.4. restructuring engineering
A software
!" Before you start rebuilding, be sure you understand how the original was process
built. Take a peek behind the walls. Understand the wiring, the plumbing, model
and the structural internals. Even if you trash them all, the insight you’ll
gain will serve you well when you start construction.
!" total effort applied to make these changes
!" If you begin rebuild, use only the most modern, long-lasting materials. This
may cost a bit more now, but it will help you to avoid expensive and !" date of last substantive change
consuming maintenance later. !" effort applied to make the last change
!" in which it resides
!" If you it. will result
!" applications with which it interfaces
in high quality-today and in the future.
!" database(s) that it accesses
Although the above principles focus on the rebuilding of a house, they apply !" errors reported over the past 18 months
equally well to the reengineering of computer-based systems and applications. I ’
!" number of users
To implement these principles, we apply a software reengineering process
!"number of machines on which it is installed
model that defines six activities shown in Figure 27.4. In some situations, these
activities occur in a linear sequence, but this is not always the case. For exam- !" complexity of:
ple, it may be that reverse engineering (understanding the internal working of a program architecture
program) may have to occur before document restructuring can commence.
code
The reengineering paradigm shown in the figure is a cyclical model. This
means that each of the activities presented as a part of the paradigm may be
revisited. For any particular cycle, the process can terminate after any one of !" quality of documentation
these activities. !" overall maintainability (scale value)
!" projected longevity years)
Inventory A n a l y s i s Every software organization should have an inventory of all
!" projected number of changes over the next 36 months
applications. The inventory can be nothing more than a spreadsheet model that
the following information: !" annual cost of maintenance
!"annual cost of
!" annual business value
!"
766 PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27: 767
information listed above should be collected for every active application. legacy systems have a relatively solid program architecture, but individual mod-
By sorting this information according to business criticality, longevity, current ules were coded in a way that makes them difficult to understand, test, and main-
maintainability, and other locally important criteria, candidates for tain. In such the within the suspect modules can be restructured.
appear. Resources can then be allocated intelligently. To accomplish this activity, the source code is analyzed using a restructur-
It is important to note that the inventory table described above should ing tool. Violations of structured programming constructs are noted and code is
revisited on a regular cycle. The status of applications (e.g., business critical- . then restructured (this can be done automatically). The resultant restructured
ity) can change as a function of time, and a result, priorities for code is reviewed and tested to ensure that no anomalies have been introduced.
ing will shift. Internal code documentation is updated.
Document Weak documentation is the trademark of many legacy R e s t r u c t u r i n g A program with weak data architecture will be difficult to
systems. But what do we do about it? adapt and enhance. In fact, for many applications, data architecture has more
to do with the long-term viability of a program than the source code itself.
Option Creating documentation is far too time-consuming. The system Unlike code restructuring, which occurs at a relatively low level of ab-
works, we’ll live with what we have. In some this is the correct ap- straction, structuring is a full reengineering activity. In most cases,
proach. It is not possible to re-create documentation for hundreds of com- data restructuring begins with a reverse engineering activity. Current data ar-
puter programs. If a program is relatively static, is coming to the end of its chitecture is dissected. When necessary, data models are defined (Chapter 121,
useful life, and is likely to undergo few changes, let it be! data objects and attributes are identified, and existing data structures are re-
viewed for quality.
Option Documentation must be updated, but we have limited resources. When data structure is weak (e.g., flat tiles are currently implemented,
We’ll use a “document when touched” approach. It may not be necessary to when a relational approach would greatly simplify processing), the data are
fully redocument an application. Rather, those portions of the system that
reengineered.
are currently undergoing change are fully documented. Over time, a
Because data architecture has a strong influence on program architecture
of useful and relevant documentation will evolve. and the algorithms that populate it, changes to the data will invariably result
Option The system is business critical and must be fully in either architectural or code-level changes.
Even in this case, an intelligent approach is to pare documentation to an
essential minimum. E n g i n e e r i n g In an ideal world, applications would be rebuilt using a au-
tomated “reengineering engine.” The old program would be fad into the engine,
Each of these options is viable. A software organization must choose the one analyzed, restructured, and then regenerated in a form that exhibited the
that is most appropriate for each case. aspects of quality. In the short term, it is unlikely that such an “engine”
will appear, but CASE vendors have introduced tools that provide a limited sub-
Reverse Engineering The “reverse engineering” has its origins in the hard- set of these capabilities that address specific application domains (e.g.,
ware world. A company disassembles a competitive hardware product in an ef- tions that are implemented using a specific database system). More important,
fort to understand its competitor’s design and manufacturing “secrets.” These these reengineering tools are becoming increasingly more sophisticated.
secrets could be easily understood if the competitor’s design and manufactur- Forward engineering, also called or reclamation not
ing specifications were obtained. But these documents are proprietary and are only recovers design information from existing software, but uses this infor-
not available to the company doing the reverse engineering. In essence, suc- mation to alter or reconstitute the existing system in an effort to improve
cessful reverse engineering derives one or more design and manufacturing overall quality. In most cases, reengineered software re-implements the func-
specifications for a product by examining actual specimens of the product. tion of the existing system and also adds new functions and/or improves over-
Reverse engineering for software is quite similar. In most cases, however, all performance.
the program to be reverse engineered is not a competitor’s, Rather, it is the
company’s own work (often done many years earlier). The “secrets” to be un-
derstood are obscure because no specification was ever developed. Therefore, 27.3 REVERSE ENGINEERING
reverse engineering for software is the process of analyzing a program in an ef-
fort to create a representation of the program at a higher level of abstraction Reverse engineering conjures up an image of the “magic slot.” We feed an un-
than source code. Reverse engineering is a process of design recovery. Reverse structured, undocumented source listing into the slot and out the other end
engineering tools extract data, architectural, and procedural design informa- comes full documentation for the computer program. Unfortunately, the magic
tion from an existing program. slot doesn’t exist. Reverse engineering can extract design information from
source code, but the abstraction level, the completeness of the documentation,
The most common type of (actually, the use of the degree to which tools and a human analyst work together, and the direc-
the term is questionable in this case) is code restructuring. Some tionality of the process are highly variable
769
768 PART ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27:
The abstraction of a reverse engineering process and the tools that are
used to effect it refers to the sophistication of the design information that can
be extracted from source code. Ideally, the abstraction level should be as high dirty code
as possible. That is, the reverse engineering process should be capable of de-
riving procedural design representations low level of abstraction); program I ,
and data structure information (a somewhat higher level of abstraction); data restructure
and control flow models (a relatively high level of abstraction); and entity-re- code
lationship models high level of abstraction). As the abstraction level in-
creases, the software engineer is provided with information that will allow eas-
ier understanding of the program. processing
The completeness of a reverse engineering process refers to the level of de-
tail that is provided at an abstraction level. In most cases, the completeness de-
creases as the abstraction level increases. For example, given a source code list-
ing, it is relatively easy to develop a complete representation. extract
Simple data flow representations may also be derived, but it is far more diffi- abstractions
cult to develop a complete set of data flow diagrams or a state-transition dia-
gram.
Completeness improves in direct proportion to the amount of analysis per- initial specification
formed by the person doing reverse engineering. refers to the de-
gree to which the human is “integrated” with automated tools to create an ef-
fective reverse engineering process. In most cases, as the abstraction level
increases, interactivity must increase or completeness will suffer,
If the directionality of the reverse engineering process is one-way, all in-
formation extracted from the source code is provided to the software engineer
FIGURE27.5. I
who can then use it during any maintenance activity. If directionality is final specification
way, the information is fed to a reengineering tool that attempts to restructure The reverse
or regenerate the old program. neering process
The reverse engineering process is represented in Figure 27.5. Before re-
verse engineering activities can commence, unstructured (“dirty”) source code
is restructured (Section 50 that it contains only the structured pro-
gramming This code easier to read and provides The overall funclionnlity of entire system must be understood before
the basis for all subsequent reverse engineering activities. more detailed reverse engineering work occurs. This establishes a context for
The core of reverse engineering is an activity called extract abstractions. further analysis and provides insight into interoperability issues among appli-
The engineer must evaluate the old program and from the (often undocu- cations within the system. Each of the programs that comprise the application
mented) source code, extract a meaningful specification of the processing that system represents a functional abstraction at a high level of detail. A block di-
is performed, the user interface that is applied, and the program data struc- agram, representing the interaction between these functional abstractions, is
tures or database that is used. created. Modules each perform subfunction and represent a defined pro-
cedural abstraction. Processing narratives for each model are created. In some
cases, system, program, and module specifications already exist. When this is
the case, the specifications are reviewed for conformance to existing
27.3.1 Reverse Engineering to Understand Processing Things more complex when the code inside a module is considered.
The engineer looks for sections of code that represent generic procedural pat-
The first real reverse engineering activity begins with an attempt to under- terns. In almost every module, a section of code prepares data for processing
(within the module), a different section of code does the processing, and another
stand and then extract procedural abstractions represented by the source code.
To understand procedural abstractions, the code is analyzed at varying levels section of code prepares the results of processing for export from the module.
of abstraction: system, program, module, pattern, and statement, Within each of these sections, we can encounter smaller patterns (e.g., data
‘Code be restructured using CASE tool that written in the history of program updated. AR
structures changes made, the code no to the
PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27: 771
770
idation and bounds checking often occurs within the section of code that pre- These enable a software engineer to identify classes within the program
pares data for processing). that interact with the global data structures.
A technique called program has been suggested as
one way to identify procedural patterns with a mode1 and then repackage these structure Regardless of its logical organization and physical
patterns into a meaningful function. Using an automated browsing tool, the lure, a database allows the definition of data objects and supports some method
software engineer isolates focusing operations-noncontiguous segments of for establishing relationships among the objects. Therefore, reengineering one
code that are functionally (semantically) related. Once focusing operations have database schema into another requires an understanding of existing objects
been isolated, factoring operations are Focused code segments are ex- and their relationships.
tracted from existing code and repackaged into a new module The be to define the existing data model
For large systems, reverse engineering is generally accomplished using a as a precursor to reengineering a new database model:
semi-automated approach. tools (e.g., are used to “parse” the
semantics of existing code. The output of this process is then passed to re- 1. Build an initial model. The classes defined as part of the model may
structuring and forward engineering tools to complete the reengineering be acquired by reviewing records in a flat database or tables in a rela-
process. tional schema. The items contained in records or tables become attributes
of a class.
2. Determine candidate keys. The attributes are examined to determine
whether they are used to point to another record or table. Those that serve
27.3.2 Reverse Engineering to Understand Data
as pointers become candidate keys.
3. Refine the tentative classes. Determine whether similar classes can be com-
Reverse engineering of data occurs at different levels of abstraction. At the
bined into a single class.
program level, internal program data structures must often be reverse engi-
neered as part overall reengineering effort. At the system level, global 4. Define generalizations. Examine classes that have many similar attributes
data files, databases) are often reengineered to accommodate to determine whether a class hierarchy should be constructed with a gen-
new database management paradigms (e.g., the move from flat file to rela- eralization class at its head.
tional or object-oriented database systems). Reverse engineering of the current Use that are analogous to the CRC ap-
global data structures sets the stage for the introduction of a new system wide proach (Chapter to establish associations among classes.
database.
Once information defined in the above steps is known, a series of transforma-
Structures Reverse engineering techniques for internal program tions can be applied to map the old database structure into a new
data focus on the definition of classes of This is accomplished by ex- database structure.
amining the program code with the intent of grouping related program vari-
ables. In many cases, the data organization within the code identifies abstract
data types. For example, record structures, tiles, other data structures
often provide an initial indicator of classes.
Breuer and Lano suggest the following approach for reverse en- 27.3.3 Reverse Engineering User Interfaces
gineering classes:
As sophisticated become de rigueur for computer-based products and
1. Identify flags and local data structures within the program that record im- terns of every type, the redevelopment of user interfaces has become one of the
portant information about global data structures (e.g., a or database). most common types of reengineering activities. But before a user interface can
be rebuilt, a reverse engineering activity should occur.
2. Define the relationship between flags and local data structures and the
For us to fully understand an existing user interface the structure and
global data structures. For example, a flag may be set when a is empty,
behavior of the interface must be specified. Merlo and his colleagues
or a local data structure may serve as a buffer that contains the last 100
suggest three basic questions that must be answered as reverse engineering of
records acquired from a
the
3. For every (within the that represents an array or file, --
list all other variables that have a logical connection to it. !" What are the basic actions that the interface must process-for example, key-
, strokes and mouse clicks?
!" What is a compact description of the behavioral response of the system to
‘For a complete discussion of these object-oriented concepts, Chapter 19. these actions?
772 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27: 773
!" What is meant by a “replacement,” or more precisely, what concept of equiv- agent, D. Alternatively, a mouse click (action can be initiated via a
alence of interfaces is relevant here? down menu agent, which interfaces directly with the print driver. Using the
summation operator defined for process algebra notation and indicated in
Behavioral modeling notation (Chapter can provide a means for represent- Figure 27.6, we can represent the print behavior as:
ing the answers to the first two questions noted Much of informa-
P=
tion necessary to create a behavioral model can be obtained by observing the
external manifestation of the existing interface. But additional information This states that agent P behaves in a manner that is identical to action c and
necessary create the behavioral model must extracted from the code. the resultant behavior of agent D or and the resultant behavior of
Process algebra may be used to represent the behavior of an interface in a agent
formal manner. and his colleagues put process algebra into con- A detailed discussion of process algebra and its use in interface
tent when they state: neering is beyond the scope of this book. The interested reader should see
or for more detail.
In describing processes that occur in interfaces, a key novelty is that certain
objects must be ready to respond to user inputs, which cannot be controlled, but
only rejected. Thus, one needs to capture the idea that there are at least two 27.4
concurrent active entities: the system and the Second, one must be able
to express certain “external” choices that are not under user control. These in-
Software restructuring modifies source code and/or data in an effort to make it
gredients, reactivity, concurrency, and external choice are basic to process al-
to future changes. In general, restructuring does not modify the over-
gebra. all program architecture. It tends to focus on the design details of individual
modules and on local data structures defined within modules. If the restruc-
The description of interface makes use of agents and actions. An agent is turing effort extends beyond module boundaries and encompasses the software
something that accomplishes some aspect of the system. Actions allow agents architecture, restructuring becomes forward engineering (Section 27.5).
to communicate with one another. In essence, process algebra is a shorthand Arnold defines a number of benefits that can be achieved when
notation for representing how agents and actions achieve the function of a UI. software is restructured:
The basic syntax is illustrated in Figure 27.6.
As an example, consider an modem interface that has a printer icon in a
!"Leads to programs that have higher quality-better documentation and less
tool bar. The printer icon P, is an agent. Printing can also be accomplished by
complexity; conformance to modern software engineering practices and stan-
a print command (action passed through the keyboard to a print driver
dards
!" Reduces frustration among software engineers who must work on the pro-
gram, thereby improving productivity and making learning easier
!" Reduces the effort required to perform maintenance activities
Name Notation Meaning !" Makes software easier to test and debug
An inactive agent 0 Restructuring occurs when the basic architecture of an application is solid,
Constant A the agent A even though technical internals need work. It is initiated when major parts of
the software are serviceable and only a subset of all modules and data need ex-
Prefix a.E do action a and behave like agent E tensive
Summation agent composed with agent
Composition I behave like agent or agent
Restriction \ L agent E restricted actions in the set L 27.4.1 Code Restructuring
Relabeling renaming of agent E according to function f
Substitution EIX replace agent X by agent E Code restructuring is performed to yield a design that produces the same func-
tion but with higher quality than the original program. In general, code
Recursion = the agent X such that X = E
is sometimes to make between extensive restructuring and redevel-
FIGURE 27.6. Process algebra notation opment. Both
774 PART FIVE. ADVANCED TOPICS SOFTWARE ENGINEERING CHAPTER 27: 775
structuring techniques Warnier’s logical simplification techniques Rather than waiting until a maintenance request is received, the develop-
model program logic using Boolean algebra and then apply a series ment or maintenance organization selects a program that will remain in use
of transformation rules that yield restructured logic. The objective is to take for a preselected number of years, (2) that is currently being used successfully,
“spaghetti-bowl” code and derive a procedural design that conforms to the and that is likely to undergo major modification or enhancement in the near
structured programming philosophy (Chapter 14). future. Then, option 2, 3, or 4 above is
This preventive maintenance approach was pioneered by Miller
under the title “structured retrofit.” He defined this concept as “the application
of today’s methodologies to yesterday’s systems to support tomorrow’s
27.4.2 Data Restructuring
.. At glance, the suggestion that we redevelop a large program when a
Before data restructuring can begin, a reverse engineering activity, analysis of working version already exists may seem quite extravagant. Before passing
source code, must be conducted. Ail programming language that judgment, consider following points:
contain data definitions, descriptions, and interface descriptions are
evaluated. The intent is to extract data items and objects, to get information 1. The cost to maintain one line of source code may be 20 to 40 times the cost
on data flow, and to understand the existing data structures that have been im- of initial development of that line.
plemented. This activity is sometimes called data analysis 2. Redesign of the software architecture (program and/or data structure) us-
Once data analysis has been completed, redesign commences. In its ing modern design concepts can greatly facilitate future maintenance.
simplest form, a data record standardization step clarifies data definition to
achieve consistency among data item names or physical record formats wit 3. Because a prototype of the software already exists, development produc-
an existing data structure or file format. Another form of redesign, called data tivity should be much higher than average.
name rationalization, ensures that all data naming conventions conform to lo- 4. The user now has experience with the software. Therefore, new require-
cal standards and that aliases are eliminated as data flow through the system. ments and the direction of change can be ascertained with greater ease.
When restructuring moves beyond standardization and rationalization, 5. CASE tools for reengineering will automate some parts of the job.
physical modifications to existing data structures are made to make the data
6. A complete software configuration (documents, programs, and data) will ex-
design more effective. This may mean a translation from one format to an- ist upon completion of preventive maintenance.
other, or in some cases, a translation from one type of database to another.
When a software development organization sells software as a product, pre-
ventive maintenance is seen in “new releases” of a program. A large in-house
27.5 FORWARD ENGINEERING software developer (e.g., a business systems software development group for a
large consumer products company) may have 500 to 2000 production programs
A program with control flow that is the graphical equivalent of a bowl of within its domain of responsibility. These programs can be prioritized by im-
spaghetti with “modules” that are 2000 statements long, with few meaningful portance and then reviewed as candidates for preventive maintenance.
comment lines in 290,000 source statements, and with no other documentation The forward engineering process applies software engineering principles,
must be modified to accommodate changing user requirements. We have the fol- concepts, and methods to re-create an existing application. In most cases for-
lowing options: ward engineering does not simply create a modern equivalent of an older pro-
gram. Rather, new and technology requirements are integrated into the
We can struggle through modification after modification, “fighting” the im- reengineering effort. The redeveloped program extends the capabilities of the
plicit design and source code to implement the necessary changes. older application.
We can attempt to understand the broader inner workings of the program
in an effort to make modifications more effectively.
We can redesign, recode, and test those portions of the software that require 27.5.1 Forward Engineering for Client/Server Architectures
modification, applying a software engineering approach to all revised seg-
ments. Over the past decade many mainframe applications have been reengineered to
We can completely redesign, recode, and test the program, using CASE accommodate client/server architectures (Chapter 281. In essence,
tools (reengineering tools) to assist us in understanding the current design.
There is no single “correct” option. Circumstances may dictate the option continuing, review Chapter 1. As management correctly responds to the specter of
even if the others are more desirable. “aging plant,” redevelopment has become mandatory in many companies.
776 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27: 777
tralized computing resources (including software) are distributed among many rules (defined by an existing or reengineered business process). Client ap
client platforms. Although a variety of different distributed environments can provide targeted functionality to the user community
be designed, the typical mainframe application that is reengineered into a The functions of the existing database management system and the data
client/server architecture has the following features: architecture of the existing database must be reverse-engineered as a precur-
sor to the redesign of the database foundation layer. In some cases a new data
!"application functionality migrates to each client computer; model (Chapter 12) is created. In every case, the C/S database is reengineered
!" new GUI interfaces are implemented at the client sites; to ensure that transactions are executed in a consistent manner; that all up-
!" database functions are allocated to the server:
dates are performed only by authorized users; that core business rules are en-
forced (e.g., before a vendor record is deleted, the server ensures that no related
!" specialized functionality computation-intensive may remain at accounts payable, contracts, or communications exist for that vendor); that
the server site; and queries can be accommodated efficiently; and that full archiving capability has
!" new communications, security, archiving, and control requirements must be been established.
established at both the client and server sites. The business rules layer represents software that is resident at both the
client and the server. This software performs control and coordination tasks to
It is important to note that the migration from mainframe to C/S computing ensure that transactions and queries between the client application and the
requires both business and software reengineering. In addition an “enterprise database conform to the established business process.
network infrastructure” must be established. The client applications layer implements business functions that are re-
Reengineering for applications begins with a thorough analysis of the quired by specific groups of end users. In many instances, a mainframe appli-
business environment that encompasses the existing mainframe. Three layers of cation is segmented into a number of smaller, reengineered desk-top applica-
abstraction (Figure 27.7) can be identified. The database sits at the foundation of tions. Communication among the desk-top applications (when necessary) is
a client/server architecture and manages transactions and queries. Yet these controlled by the business rules layer.
transactions and queries must be controlled within the context of a set of
27.5.2 Forward Engineering for Object-Oriented Architectures
Object-oriented software engineering is rapidly becoming the development par-
adigm of choice for many software organizations. But what about existing ap-
plications that were developed using conventional methods? In some cases, the
answer is to leave such applications “as is.” But in others, older applications
must be reengineered so that they can be easily integrated into large,
oriented systems.
Reengineering conventional software into an object-oriented implementa-
tion uses many of the same techniques discussed in Part Four of this book.
interface: process requests First, the existing software is reverse engineered so that appropriate data,
functional, and behavioral models can be created. If the reengineered system
extends the functionality or behavior of the original application, use cases
business rules (Chapter are created. The data models created reverse engineering
are then conjunction with CRC modeling (Chapter 20) to establish the
basis for the definition of classes. Class hierarchies, object-relationship models,
object-behavior models, and subsystems are defined, and object-oriented design
commences.
interface: transactions and queries As object-oriented forward engineering progresses from analysis to design,
invoked. the existing applica-
tion has a domain that is already populated by many object-oriented
Lions, it is rouse library and can be used during for-
ward engineering.
For he engineered from scratch, it may
to rouse algorithms und structures from existing
778 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27: 779
cation. However, these must be redesigned to conform to the object-oriented ar- A cost-benefit analysis model for reengineering has been proposed by
chitecture. Sneed Nine parameters are defined:
\ = current annual maintenance cost for an application
27.5.3 Forward Engineering User Interfaces current annual operation cost of an application
= current annual business value of an application
As applications migrate from the to the desk-top, users are no = predicted annual maintenance cost after reengineering
longer willing to tolerate arcane, character-based user interfaces. In fact, a sig- annual operations cost after reengineering
nificant portion of all effort expended in the transition from mainframe to = predicted annual business value after reengineering
client/server computing can be spent in the reengineering of client application
user interfaces. = estimated reengineering costs
Merlo and his colleagues suggest the following model for = estimated reengineering calendar time
user interfaces: risk = 1.0 is
I,
in
II
of in-
as:
in to
nnd remaining program must be consistent with the date that I, (27.1)
The costs associated with reengineering are defined using the following rela-
2. Remodel the behavior implied by the existing interface into a series of ab- tionship:
stractions that have meaning in the context of a Although the mode of
interaction may be radically different, the business behavior exhibited by C = + (27.2)
users of the old and new interface (when considered in terms of a usage
scenario) must remain the same. A redesigned interface must still allow a Using the costs presented in equations (27.1) and the overall benefit of
user to exhibit the appropriate business behavior. For example, when reengineering can be computed as:
database query is to be made, the old interface may require a long Cost benefit = (27.3)
of text-based commands to specify the query. The reengineered GUI may
streamline the query to a small sequence of mouse picks, but the intent and The cost-benefit analysis presented in the above equations can be performed
content of the query remain unchanged. all high-priority applications identified during inventory analysis (Section
27.2.2). applications that show the highest cost benefit can be targeted
3. Introduce improvements that make the mode of interaction more efficient.
The ergonomic failings of the existing interface are studied and corrected for reengineering, while work on others can be postponed until resources are
available.
in the design of the new GUI.
4. Build and integrate the new GUI. The existence of class libraries and fourth
generation tools can reduce the effort required to build the GUI signifi-
27.7 SUMMARY
cantly. However, integration with existing application software can be more
time-consuming. Care must be taken to ensure that the GUI does not prop-
agate adverse side effects into the remainder of the application. Reengineering occurs at two different levels of abstraction. At the business level,
reenginoering focuses on with the intont of making changes
to improve in some area of the business. At the software level
27.6 THE ECONOMICS OF REENGINEERING rccngincering and applications with the
of restructuring or reconstructing them so that they exhibit higher quality.
In a perfect world, every unmaintainable program would be retired immedi- Business process reengineering defines business goals, identifies
ately, to be replaced by high-quality, reengineered applications developed using and evaluates existing business processes (in the context of defined goals),
modern software engineering practices. But we live in a world of limited re- specifies and designs revised processes, and prototypes, refines, and instanti-
sources. Reengineering drains resources that can be used for other business ates them within a business. Like inform tion engineering, BPR has a focus
purposes. Therefore, before an organization attempts to reengineer an existing extends beyond software. The result o BPR often the definition of ways
application, it should perform a cost-benefit analysis. in which information technologies can better support the business.
780 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 27: 781
Software reengineering encompasses a series of activities that include in- Jaychandra, Y., Reengineering the Networked Enterprise, McGraw-Hill,
ventory analysis, document restructuring, reverse engineering, program and 1994.
data restructuring, and forward engineering. The intent of these activities is to Markosian, L. et al., “Using an Enabling Technology to Reengineer
create versions of existing programs that exhibit higher quality and better Legacy Systems,” of the ACM, vol. 37, no. May 1994,
maintainability-programs that will be viable well into the twenty-first cen- pp.
tury. Merlo, E. et al., “Reverse Engineering of User Interfaces,” Working
Inventory analysis enables an organization to assess each application sys- Conference on Reverse Engineering, IEEE, Baltimore, MD, May 1993, pp.
tematically, with the intent of determining which are candidates for 171-178.
neering. Document restructuring creates a framework of documentation that is Merlo, E., et al., “Reenginkering User Interfaces,” Software,
necessary for the long-term support of an application. Reverse engineering is January 1995, pp. 64-73.
the process of analyzing a program in an effort to extract data, architectural, Miller, J., in Techniques of Program and System Maintenance, G.
-and procedural design information. Finally, forward engineering reconstructs a Winthrop Publishers, 1981.
program using modern software engineering practices and information learned Milner, R., Concurrency, Prentice-Hall, 1989.
during reverse engineering. Ning, A. Engberts, and W. Kozaczynski, “Automated Support for
The costs and benefits of reengineering can be determined quantitatively. Legacy Code Understanding,” Communications of the ACM, vol. 37, no.
The cost of the status that is, the costs associated with ongoing mainte- 5, May 1994, pp.
nance of an existing application) are compared to the projected costs of the Osborne, W.M., and E.J. Chikofsky, “Fitting Pieces the Maintenance
reengineering and the resultant reduction in maintenance costs. In almost Puzzle,” January 1990, pp.
every case in which a program has a long life and currently exhibits poor main- Premerlani, W.J., and M.R. “An Approach for Reverse Engineering
tainability, reengineering represents a cost-effective business strategy. of Relational Databases,” Communications of the ACM, vol. 37, no. 5,
May 1994, pp. 42-49.
J.A., J.C. and M.W. Weeks, “Data Reengineering for
Systems,” Software Maintenance--1989, IEEE,
REFERENCES 1989, pp. 174-179.
Sneed. H. “Plannina the of Legacy Systems,”
Arnold, R.S., “Software Restructuring,” IEEE, vol. 77, no. 4, April January 1995,
1989, pp. Stewart, “Reengineering: The Hot New Managing Tool,” Fortune,
Bleakley, F.R., “The Best Laid Plans: Many Companies Try Management August 23, 1993, pp. 41-48.
Fads, Only to See Them Flop,” The Wall Street Journal, July 6, 1993. Swanson E.B., “The Dimensions of Maintenance,” 2nd Zntl.
and K. “Creating Specification From Code: on Software Engineering, IEEE, October 1976, pp.
Engineering Techniques,” Journal of Software Maintenance: Research J.D., Logical Construction Nostrand Reinhold,
and Practice, Volume 3, Wiley, 1991, pp. 145-162. 1974.
Canning, R., “The Maintenance vol. 10, no. 10, Weisz, M., “BPR is Like Teenage Programmer, vol. 8, no.
October 1972. 6, June 1995, pp. 9-15.
“Case Tools for Reverse Engineering,” CASE Outlook, CASE Consulting
Group, Lake Oswego, OR, vol. 2, no. 2, 1988, pp. l-15.
Chikofsky, E.J., and J.H. Cross, II, “Reverse Engineering and Design PROBLEMS AND TO PONDER
Recovery: A Taxonomy,” IEEE Software, January 1990, pp. 13-17.
Davenport, T.H., and J.E. Young, “The New Industrial Engineering:
Information Technology and Business Process Redesign,” Sloan 27.1. Consider any job that you’ve held in the last years. Describe the busi-
Management Summer 1990, pp. 11-27. ness in which you played a part. Use the BPR model described in
“Lean and Mean.” IEEE November 1995, Section 27.1.3 to recommend changes to the process in an effort to make it
101-102. more efficient.
Dickinson, B., Strategic Business Reengineering, LCI Press, 1995. 27.2. Do some research on the efficacy of business process reengineering. Present
Hammer, M., “Reengineer Work: Don’t Automate, Obliterate,” Harvard pro and con arguments for this approach.
Business July/August 1990, pp. 104-112. 27.3. Your instructor will select one of the programs that everyone in the class has
Hammer, M., and J. Champy, Reengineering the Corporation, developed during this course. Exchange your program randomly with some-
1993. one else in the class. Do not explain or walk through the program. Now, im-
M., “Maintenance Burden Begging for a Remedy,” plement an enhancement (specified by your instructor] in the program you
April 1993, pp. 53-63. have received.
782 YAK,
a. Perform all software engineering tasks including a brief walkthrough (but Extensive information about reengineering and a comprehensive bibliog-
not with the author of the program). raphy can be found at the Software Reengineering Web page:
b. Keep careful track of all errors encountered during testing.
Discuss your experiences in class.
27.4. Using some or all of the criteria for inventory analysis described in Section
27.2.2, attempt to develop a quantitative software rating system that could The following sites provide additional reengineering information and pointers:
be applied to existing programs in to pick candidate programs for
reengineering. The Asset Repository
27.5. Suggest alternatives to paper and ink or conventional electronic documen- ESEG at UMCP
tation that could serve as the basis for document restructuring. [Hint: Think
of new descriptive technologies that could be used to communicate the in-
REDO Project Archive (Esprit)
tent of the software.1
27.6. Some people believe that artificial intelligence techniques will increase the
abstraction level of tho reverse engineering process. some research on Reverse Engineering-Georgia Tech
this subject the use of AI for reverse engineering) and write a brief pa- reverse/
per that takes a stand on this point. UCSD Software Evolution Group
27.7. Why is completeness more to achieve as abstraction level increases?
27.8. Why must interactivity increase if completeness is to increase? WWW Virtual Library-SE
27.9. Get product literature on three reverse engineering tools and present their software-eng.html
characteristics in class.
27.10. Do some research on process algebra and develop a simple specification of a Reasoning Systems, Inc. has created an “On-Line Bibliography of Reengineering
process using the notation described in Figure 27.6. Papers” that is based on their Software Refinery product:
27.11. There is a subtle difference between restructuring and forward engineering.
What is it?
27.12. Research the literature to find one or two papers that discuss studies
of mainframe to client/server reengineering. Present a summary. An up-to-date list of World Wide Web references for software reengineering
can be found at:
27.13. How would you determine through in the cost-benefit model presented
in Section
FURTHER READINGS AND OTHER INFORMATION SOURCES
Reengineering is a “hot” topic in the software engineering community. Because
the technology that encompasses reengineering continues to evolve, technical
periodicals are best sources of information. The June 1995 edition of
American Programmer,the January 1995 edition of IEEE Computer,and the
May 1994 edition of Communications of the ACM are representative of many
periodicals that contain special features on reengineering topics.
Relatively few books have been dedicated to software reengineering. A good
starting point (dedicated to business process reengineering) is Hammer and
Champy’s best-selling book Arnold Reengineering,IEEE
Computer Society Press, 1993) has published an excellent anthology of impor-
tant papers that focus on software reengineering technologies. Berztiss
(Software Methods for Business Reengineering,Springer-Verlag, 19961 and
Spurr and her colleagues (Software Assistance for Business Reengineering,
Wiley, 1994) discuss tools and techniques that BPR. Aiken
Reverse Engineering, McGraw-Hill, 19961 discusses how to reclaim, reorganize,
and reuse organizational data.
CHAPTER 28: CLIENT/SERVER SOFTWARE ENGINEERING 785
with an emphasis on the special software engineering issues that must be ad-
dressed when such systems are analyzed, designed, tested, and supported.
CLIENT/SERVER
28.1 THE STRUCTURE OF CLIENT/SERVER SYSTEMS
Hardware, software, database, and network communications technologies all
SOFTWARE
contribute to distributed and cooperative computer architectures. In its most
general form, a distributed and cooperative computer architecture is illustrated
in Figure 28.1. A root system, typically a mainframe, serves as the repository
for corporate data. The root system is connected to servers (typically powerful
ENGINEERING
workstations or PCs) that have a dual role. The servers act to update and re-
quest corporate data maintained by the root system. They also maintain local
departmental systems and play a key role in networking user-level PCs via a
local area network
In a C/S structure, the computer that resides above another computer (in
Figure 28.11 is called the and computers at the level below are called
clients. The client requests and the server provides them. However,
within the context of the architecture represented in Figure 28.2, a number of
different implementations can be achieved
W hen a new computer-based system is to be developed, an engineer is
constrained by the limitations of existing technology and empowered
when new technologies provide capabilities that were unavailable to earlier
this context, “services” can be broadly interpreted to mean data, processing, or a combi-
nation of the two
engineers. At the turn of the century, the development of a new generation of
machine tools capable of holding very tight tolerances empowered the engineers
who designed a new factory process called mass production. Refore the advent
of the new machine tool technology, machines could not hold tight tolerances. Mainframe
Without tight tolerances, easily assembled interchangeable parts-the corner- root system
stone of mass production-could not have been built.
The evolution of distributed computer architectures has enabled system ,
and software engineers to develop new approaches to how work is structured
and how information is processed within an organization. New organizational
structures and new information processing approaches (e.g., decision support
systems, groupware, and imaging) represent a radical departure from the ear-
lier mainframe- and minicomputer-based technologies. New computing archi-
tectures have provided the technology that has enabled organizations to reengi-
neer their business processes (Chapter
In this chapter,’ we examine a dominant new architecture for information
processing--client/server systems. Client/server systems have evolved in
conjunction with advances in desk-top computing, new storage technologies,
improved network communications, and enhanced database technology. The ob-
jective of this chapter is to present a brief overview of systems
FIGURE 28.1.
Distributed, User-level . . . User-level
of this chapter have been adapted from course material developed by John Porter computer PC PC
for the Client/Server Curriculum offered at The Engineering School of Fairfield University, in a corpo- I
Used with permission. rate setting
784
786 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 28: CLIENT/SERVER SOFTWARE ENGINEERING 787
application operates. For example, a business application might produce a
variety of printed reports based on numeric input, calculations, database
User-level
information, and other considerations. A groupware application might pro-
vide the facilities for enabling bulletin board communication or e-mail. In
both cases, the application software may be partitioned so that some com-
ponents reside on the client and others reside on the server.
Database management.This component performs the data manipula-
tion by an application. Data manipulation and
management may be as simple as the transfer of a record or as complex as
the processing of sophisticated SQL transactions.
record request/reply In addition to these components, another software building block, often called
middleware, exists in all C/S systems. Middleware is comprised of software ele-
FIGURE 28.2. ments that exist on both the client and the server, and includes elements of net-
Client/server transaction work operating systems as well as specialized application software that supports
options group communication database-specific applications, object-request broker standards (Section 28.1.51,
groupware technologies, communication management, and other features that
facilitate the client/server connection. and his colleagues have re-
ferred to middleware as “the nervous system of a client/server system.”
F i l e s e r v e r s . The client requests specific records from a tile. The server
transmits these records to the client across the network.
D a t a b a s e s e r v e r s . The client sends structured query language
28.1.2 The Distribution of Software Components
quests to the server. These are transmitted as messages across the net-
work. The server processes the SQL request and the requested infor-
mation, passing only the results back to the client. Once the basic requirements for a client/server application have been deter-
mined, the software engineer must decide how to distribute the software com-
T r a n s a c t i o n s e r v e r s . The client sends a request that invokes remote
ponents discussed in Section 28.1.1 between the client and the server. When
procedures at the server site. The remote procedures can be a set of SQL
statements. A transaction occurs when a request results in the execution most of the functionality associated with each of the three components is allo-
cated to the server, a fat design has been created. Conversely, when the
of the remote procedure and transmission of the result back to the client.
client implements most user interaction/presentation, application, and
G r o u p w a r e s e r v e r s . When the server provides a set of applications that database components, a fat client design results.
enable communication among clients (and the people using them) using Fat clients are commonly encountered when file server and database server
text, images, bulletin boards, video, and other representations, a groupware architectures are implemented. In this case, the server provides data manage-
architecture exists. ment support, but all application and GUI software resides at the client. Fat
servers are often designed when transaction and groupware systems are im-
plemented. The server provides application support required to respond to
transactions and communication from clients. The client software focuses on
28.1 Components for Systems
GUI and communication management.
clients and fat servers can be used to illustrate the general approach
Instead of viewing software as a monolithic application to be implemented on for the allocation,of client/server software components. However, a more gran-
one machine, the software that is appropriate for a C/S architecture has sev- ular approach to software component allocation defines different
eral distinct components that can be allocated to the client or the server, or dis- rations:
tributed between both machines:
D i s t r i b u t e d p r e s e n t a t i o n . In this rudimentary client/server approach,
User interaction/presentation component. This component imple- database logic and the application logic remain on the server, typically a
ments all functions that are typically associated with a graphical user in- mainframe. The server also contains the logic for preparing screen infor-
terface (GUI). mation, using such as CICS. Special PC-based software is used to
A p p l i c a t i o n c o m p o n e n t . This component implements the requirements convert character-based screen information transmitted from the server
defined by the application within the context of the domain in which the into a GUI presentation on a PC.
788 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 28: CLIENT/SERVER ENGINEERING 789
R e m o t e p r e s e n t a t i o n . In this extension of the distributed presentation ondary search pattern. Application logic on the server would determine if the
approach, primary database and application logic remain-on the server, and secondary search is required. The response message to the client would contain
data sent by the by to the the record found as a result of either the primary or the search. The
alternate approach (the client implements the logic to determine if a second
Distributed logic. The client is assigned all user presentation tasks and search is required) would involve a message for the record retrieval, a re-
the processes associated with data entry such as field-level validation, sponse over the network if the record is not found, a second message contain-
server query formulation, and server update information and requests. The ing the parameters for the second search, and a with the re-
server is assigned database management tasks and the processes for client trieved record. If the second search is required 50 percent of the time, placing
queries, server file updates, client version control, and enterprise-wide the logic on the server to evaluate the first search and initiate the second
applications. search if necessary would reduce network traffic significantly.
final decision on component distribution should be based not only on
Remote data management.Applications on the server create a new the individual application, but on the mix of applications operating on the sys-
data by formatting data that have been extracted from elsewhere tem. For example, an installation might contain some applications that require
(e.g., from a corporate-level source). Applications allocated to the client are extensive GUI processing and little central database processing. This would lead
used to exploit the data that have been formatted by the server. to the use of powerful workstations on the client side and a bare bones server.
Decision support systems are included in this category. With this configuration in place, other applications would favor the fat client
Distributed databases.The data comprising the database are spread that the capabilities of the server would not need to be upgraded.
across multiple servers and clients. Therefore, the client must support data It should be noted that as the use of the client/server architecture matures,
management software components as well as application‘ and GUI compo- the trend is to place volatile application logic on the server. This simplifies de-
nents. ployment of software updates as changes are made to the application logic
28.13 Guidelines for Distributing Application Components
28.1.4 Linking C/S Components
While there are no absolute rules covering the distribution of application com-
ponents between the client and server, the following guidelines are generally A number of different mechanisms are used to link the various components of
followed: the client/server architecture. These mechanisms are incorporated into the net-
work and operating system structure, and are transparent to the end user at
The component is generally placed on the the client site. The most common types of linking mechanisms are:
client. The availability of windows-based environments and the comput-
ing power required for a graphical user interface makes this approach cost !" Pipes-widely used in UNIX-based systems, pipes permit messaging between
effective. different machines running on different operating systems.
If the database is to be shared by multiple users connected by the the !" Remote procedure calls-permit one process to invoke the execution of
database is typically located on the The database management sys- process or module which resides on a different machine.
tem and the database access capability are also located on the server, to- !" Client/server SQL interaction-used to pass SQL requests and associated
gether with the physical database. data from one component (typically on the client) to another component
Static data that are used for reference should be allocated to the client. This ically the DBMS on the server). This mechanism is limited to RDBMS appli-
places the data closer to the users that require them and minimizes cations only.
network and loading on the server,
In addition, object-oriented implementation of the C/S software components re-
The balance of the application component is distributed between the client sults in “linkage” using an object request broker. This approach is discussed in
and server based on the distribution that optimizes the server and client con- the following section.
figurations and the network that connects them. For example, the implemen-
tation of a mutually exclusive relationship typically involves a search of the
database to determine if there is a record that matches the parameters for a
search no found, an pnttcrn If the 28.1.5 Middleware and Broker Architectures
application that controls this search pattern is entirely contained on the server,
network is minimized. The first network transmission from the client to The C/S components discussed in the preceding sections are imple-
the server would contain the parameters for both the primary and the mented by objects that must be capable of interacting with one another within
PART WE. ADVANCED TOPICS IN SOFTWARE ENGINEERING
CHAPTER 28: CLIENT/SERVER SOFTWARE ENGINEERING 791
790
Because requests for objects across the network occur at run-time, a mech-
a single machine (either client or server) or An object re- anism for storing the object description must be established so that pertinent
quest broker is a middleware component that enables an object that re- information about the object and its location are available when needed. The
sides on a client to send a message to a method that is encapsulated by an ob- interface repository accomplishes this.
ject that resides on a server. In essence, the ORB intercepts the message and When a client application must invoke a method contained within an ob-
handles of the communication and coordination activities required to find ject elsewhere in the system, CORBA uses dynamic invocation to obtain per-
the object to which the message was addressed, invoke its method, pass ap- tinent information about-the desired method from the interface repository;
propriate data to the object, and transfer the resulting data back to the object create a data structure with parameters to be passed to the object; (3) create a
that generated the message in the first request for the object; and invoke the request. The request is then passed
A widely used standard for object-request brokers, called CORBA, has been to the ORB Core-an implementation-specific part of the network operating
developed by the Object Management Group The CORBA standard system that manages requests-and the request is fulfilled.
was discussed briefly in Chapter 26. The basic structure of a CORBA The request is passed through the core and is processed by the server. At the
architecture is illustrated in Figure 28.3. server site, an object adopter stores class and object information in a server resi-
When CORBA is implemented in a client/server system, objects and object dent interface repository, accepts and manages incoming requests from the client,
classes (Chapter 19) on both the client and the server are defined using an in- and performs a variety of other object management functions At the
terface description language a declarative language that allows a soft- server, IDL stubs that are similar to those defined at the client machine are used
ware engineer to define objects, attributes, methods, and the messages that are as the interface to the actual object implementation resident at the server site.
required to invoke them. In order to accommodate a request for a server-resi- Software development for modern systems is object-oriented. Using the
dent method by a client-resident object, client and server IDL stubs are cre- CORBA architecture described briefly in this section, software developers can cre-
ated. The stubs provide the gateway through which requests for objects across ate an environment in which objects can be reused throughout a large network
the C/S system are accommodated. For further information on CORBA and its overall impact on software engineer-
ing for C/S systems, the interested reader should refer to and
I H
28.2 SOFTWARE ENGINEERING FOR C/S SYSTEMS
Interface Client
Repository I
A number of different software process models were introduced in Chapter 2.
Although any of them could be adapted for use during the development of soft-
ware for C/S systems, an evolutionary paradigm that makes use of event-based
and/or object-oriented software engineering appears to work most effectively,
Client/server systems are developed using the classic software engineering
activities-analysis, design, construction, and testing-as the system evolves
from a set of general business requirements to a collection of validated soft-
ware components that have been implemented on client and server machines.
28.3 ANALYSIS MODELING ISSUES
The requirements activity for C/S systems differs little from the analysis mod-
eling methods applied for more conventional computer architectures. Therefore,
the basic analysis principles discussed in Chapter 11 and the analysis modeling
methods presented in Chapters 12 and 20 apply equally well to C/S software.
Because analysis modeling avoids the specification of implementation de-
tail, it is only as the transition is made to design that issues associated with
!" allocation of software components to client and server are
FIGURE 26.3.
The
architecture
PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 28: CLIENT/SERVER SOFTWARE ENGINEERING 793
However, evolutionary approach to software engineering is ap- 28.4.1 Conventional Design Approaches
plied for C/S systems, implementation decisions on the overall C/S approach
(e.g., fat client vs. fat server) may be made during early analysis and design
In client/server systems, the DFD can be used establish the scope of a system,
iterations.
identify the high-level functions and subject data areas (data stores), and permit
the decomposition of the high-level functions. In a departure from the traditional
DFD approach, however, decomposition stops at the level of an elementary busi-
ness process rather than continuing the level of an atomic process.
28.4 DESIGN FOR C/S SYSTEMS In the C/S context, an elementary business process can be defined as
a set of tasks performed without a break by one user at the client sites. The
When software is being developed for implementation using a specific computer tasks are either performed fully or not at all.
architecture, the design approach must consider the specific construction envi- The ERD also assumes an expanded role. It continues to be used to de-
ronment. In essence, design customized to accommodate the hard- compose the subject data areas (data stores) of the DFD in order establish
ware architecture. a high-level view of a database which is be implemented using a RDBMS.
software is designed implementation using client/server archi- Its new role is to provide the structure for defining high-level business objects
tecture, the design approach must be “customized” to accommodate the follow- (Section 28.4.2).
ing issues: Instead of serving as a tool for functional decomposition, the structure
chart used as an assembly diagram to show the components involved in
!" Dnta design (Chapter dominates the design process. To effectively use the the for an elementary business process. These components, consisting
capabilities of database management system (RDBMS) or of interface objects, application objects, and database objects, establish how the
oriented database management system the design of the data data are to be processed.
becomes even more significant than in conventional applications.
!" When the event-driven paradigm is chosen, behavioral modeling (an analy-
sis activity, Chapter should be conducted and the control-oriented as- 28.4.2 Database Design
pects implied by the behavioral mode1 should be translated into the design
model.
Database design is used to define and then specify structure of business ob-
!" The user interaction/presentation component of a C/S system implements all jects used in the client/server system. The analysis required to identify busi-
functions that are typically associated with a graphical interface ness is accomplished using inform&inn discussed
in in notation such as
!" An object-oriented view of of the can define business objects, but a repository
sequential structure that is provided by a procedural language, an object should be established to capture the additional information that cannot be fully
is provided by the linkage between an event initiated at the GUI documented using a graphical notation such as an ERD.
and an event handling function within the client-based software. In this repository, a business object is defined as information that is visi-
ble to purchasers and users of the system, not its implementors. Each ob-
Although debate continues on the best analysis and design approach for C/S ject (entity) identified in the ERD is expanded during design into: a data struc-
systems, object-oriented methods (Chapters 20 and appear to have the best ture (e.g., a file and its related fields); all definitions governing files;
combination of features. However, conventional methods (Chapters 12 and relationships among data items in the records of the file; validation rules for
can also be adopted. Conventional notation for analysis and design includes the these relationships; and business rules that specify the external view of the
data flow diagram the entity-relationship diagram and the struc- processing that is to occur for the data.
ture chart.” A wide array of design information must be developed during database de-
sign. This implemented using a relational database, can be main-
tained in a design repository modeled in Figure 28.4 Individual ta-
bles (the left side of the diagram) are used to define the following design
information for the client/server database:
!"Entities-are identified on the ERD for the new system.
and object-oriented database management systems are used heavily in C/S archi- !"Files-which implement the entities identified on the ERD.
tectures. !" File-to-field relationship-establishes the layout for the files by identifying
notation is discussed in detail in Chapter 12. which fields are included in which files.
CHAPTER ‘28: CLIENT/SERVER SOFTWARE ENGINEERING 795
!" Fields-defines the fields in the design data dictionary).
!" File-to-file relationships-identify related files that can be joined create
logical views or
!" Relationship the type of file-to-tile or file-to-field rela-
tionships used for validation.
. Field type-is used to permit of field characteristics from field su-
perclasses (e.g., date, text, number, value, price).
!"#$%$" type-the characteristics of the data contained in a field.
!" File type-is used to identify either the location of the file.
!" Field function-key, foreign key, attribute, virtual field, derived field, etc.
!" Allowed u&es-identifies allowed values for status-type fields.
!" Business rules--rules editing, calculating fields, etc.
An C/S toward
data management has accelerated. In C/S systems that implement
on both and
key issue is
in, how and and how in
dispersed across the nodes of a network’!
A relational database system enables easy access to distributed
data through the use of structured query language (SQL). The advantage of
SQL in a architecture is that it is “non-navigational” In an
RDBMS, the type of data are specified using SQL, but no navigational infor-
mation is required. Of the implication of this is that the RDBMS must
be sophisticated enough to maintain the location of all data and be capable of
defining the best path to it. In less sophisticated database systems, a request
for data must indicate what is to be accessed and where it is. If application soft-
ware must maintain navigational information, data management becomes
much more complicated for systems.
It should be noted that other data distribution and management tech-
niques are also available to the designer
M a n u a l e x t r a c t . The user is allowed to manually copy appropriate data
from a server to a client. This approach is useful when static data is re-
quired by a user and the control of the extract can be left in the user’s
hands.
S n a p s h o t . This technique automates the manual extract by specifying a
“snapshot” of data that should be transferred from a server to a client at
predefined intervals. This approach is useful for distributing relatively sta-,
tic data that require only infrequent update.
R e p l i c a t i o n . This technique can be used when multiple copies of data
must be maintained at different sites (e.g., different servers or clients and
servers). Here, the level of complexity escalates because data consistency,
updates, security, and processing must all be coordinated at multiple sites.
Fragmentation. In this approach, the database is fragmented
across multiple machines. Although intriguing in theory, fragmentation is
796 PART FIVE: ADVANCED IN SOFTWARE ENGINEERING CHAPTER 28: SOFTWARE ENGINEERING 797
exceptionally implement and is not, as yet, encountered fre- Interface
quently. Objects
(Components)
Database design, and more specifically, database design for C/S systems, are
topics that are beyond the scope of this book. The interested reader should
and for additional discussion.
Database
28.4.3 An Overview of a Design Approach FIGURE28.5.
Structure chart nota- Objects
tion for C/S (Components)
Porter suggests a set of steps for designing an elementary business
process that combine elements of conventional design with elements of
oriented design. It is assumed that a requirements model which defines busi-
ness objects has been developed and refined prior to the start of the design of than the primary over which an interface object is built. It should be
elementary business processes. The following steps are then used to derive the noted that if the primary tile over which an interface object is built is
design: processed in a different manner, a second set of SQL statements may be
used to retrieve a file in an alternate sequence. The second file processing
For each elomcntary should he identified on the structure chart as a sep-
updated, referenced, arate database object.
2 . Use files identified in step 1 as the basis for defining components or ob- A p p l i c a t i o n O b j e c t . Used by either a interface object or a database ob-
jects. ject, this component is invoked by either a database trigger or a remote
, procedure call. It can also be used to identify business logic normally as-
3 . For each component, the business rules and other business object sociated with interface processing that has been moved to the sewer for
information that for file. oration.
4 . Determine which rules are relevant to the process, and decompose the rules Data Couple. When one object invokes another independent object, a
down to a method level. message (Chapter is passed between the two objects. The data couple
5 . As required, define any additional components that are needed to imple- symbol (Figure 28.5) is used to denote this occurrence.
ment the methods. Control Couple. When one object invokes another independent object
and no data are passed between the two objects, a control couple symbol is
Porter suggests a specialized structure chart notation (Figure used.
28.5) for representing the component structure of an elementary business
process. However, a different symbology is used so that the chart will conform
to the object-oriented nature of C/S In the figure, different sym- 28.4.4 Process Design Iteration
bols are encountered:
The design repository (Section 28.4.2) used to represent business objects is also
I n t e r f a c e O b j e c t . This type of component, also called the user interac-
used to represent interface, application, and database objects (see the right
tion/presentation component, is typically built over a single file or a single
hand side of Figure 28.4). Referring to Figure 28.4, note that the following en-
file and related files that have been joined through a query. It includes
tities are
methods for formatting the GUI interface and the client-resident applica-
tion logic with on interface. also includes em-
bedded SQL statements, which specify the database processing performed !" how a business rule is to be implemented.
on the primary file over which the interface is built. If application logic nor- !" Elementary processes-defines the elementary business processes identified
mally associated with an interface object is implemented on a server in- in the analysis model.
-stead, typically through the use of the middleware tools, the application !" Process/component link-Similar to a bill of materials in manufacturing, this
logic operating on the server should be identified as a separate application table identifies the components that make up the solution for an elementary
object. business process. It is important to note that this linkage technique permits
Database Object. This type of component is used to identify database a given component to be included in the solution for multiple elementary
processing such as record creation or selection that is based on a tile other business processes.
798 PART FIVE: ADVANCED IN SOFTWARE ENGINEERING CHAPTER 28. CLIENT/SERVER SOFTWARE ENGINEERING 799
!" Components-describes the components shown on the structure chart. S e r v e r t e s t s . The coordination and data management functions of the
!" Business rule/component link-identifies the components that are server are tested. Server performance (overall response time and data
cant to the implementation of a given business rule. throughput) is also considered.
Database tests. The accuracy and integrity of data stored by the server
If a repository of the type described in Figure 28.4 is implemented using an is tested. Transactions posted by client applications are examined to ensure
RDBMS, the designer will have access to a useful design tool that provides re- that data are properly stored, updated, and retrieved. Archiving is also
porting to aid both construction and of a C/S system. tested.
T r a n s a c t i o n t e s t i n g . A series of tests are created to ensure that each
class of transactions is processed according to requirements. Tests focus on
28.5 TESTING the correctness of processing and also on performance issues (e.g.,
tion processing times and transaction volume testing).
The distributed nature of client/server systems poses a set of unique problems N e t w o r k c o m m u n i c a t i o n t e s t i n g . These tests verify that communica-
for software testers. Binder suggests the following areas of focus: tion among the nodes of the network occurs correctly and that message
passing, transactions, and related network occur without error.
!" Client GUI considerations Network security tests may also be conducted as part of this testing
!" Target environment and platform diversity considerations activity.
!" Distributed database considerations (including replicated data)
To accomplish these testing approaches, Musa recommends the de-
!" Distributed processing considerations (including replicated processes) velopment of operational profiles derived from client/server user scenarios. An
!" Nonrobust target environment operational profile indicates how different types of users interoperate with the
Nonlinear performance relationships C/S system. That is, the profiles provide a “pattern of usage” that can be ap-
plied when tests are designed and executed. For example, for a particular type
of user, what percentage of transactions will be inquiries? updates? orders?
The strategy and tactics associated with testing must be designed in a
To develop the operational profile, it is necessary to derive a set of user sce-
manner that allows each of the above issues to be addressed. narios Each scenario addresses who, where, what, and why. That is,
who the user is, where (in the physical architecture) the system interac-
tion occurs, what the transaction is, and why it has occurred. Scenarios can be
28.5.1 Testing Strategy derived during FAST meetings (Chapter or through less formal discussions
with end users. The result, however, should be the same. Each scenario should
provide an indication of the system functions that will be required to service a
In general, the testing of client/server software occurs at three different levels: particular user, the order in which those functions are required, the timing and
individual client applications are tested in “disconnected” mode-the oper- response that is expected, and the frequency with which each function is used.
ation of the server and the underlying network are not considered; the client These data are then combined (for all users) to create the operational profile.
software and associated server applications are tested in concert, but network The strategy for testing C/S architectures is analogous to the testing strat-
operations are not explicitly exercised; the complete C/S architecture, in- egy for software-based systems described in Chapter 17. Testing begins with
cluding network operation and performance, is tested. testing in-the-small. That is, a single client application is tested. Integration of
Although many different types of tests are conducted at each of the above the clients, the server, and the network is tested progressively. Finally, the en-
levels of detail, the following testing approaches are commonly encountered for tire system is tested as an operational entity.
C/S applications: Traditional testing views module/subsystem/system integration and test-
ing (Chapter 17) as top-down, bottom-up, or some variation of the two. Module
Application function tests. The functionality of client applications is integration in C/S development may have some top-down or bottom-up aspects,
tested using the methods discussed earlier in this book. In essence, the ap- but integration in C/S projects tends more toward parallel development and in-
plication is tested in standalone fashion in an attempt to uncover errors in tegration of modules across all design levels. Thus, integration testing in C/S
its operation. projects is sometimes best accomplished using a nonincremental or “big bang”
approach.
The fact that the system is not being built to use hardware
and software impacts system testing. The networked cross-platform nature of
section is a abbreviated and adapted version of a paper written by Daniel C/S systems requires that we pay considerably more attention to configuration
It is with the author’s testing and compatibility testing.
800 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 28: CLIENT/SERVER 801
Configuration testing doctrine forces testing of the system in all of the
known hardware and software environments in which it will operate.
1.0 Windows (Graphical User Interface) Testing
Compatibility testing ensures a functionally consistent interface across hard-
1.1 Business Scenario Identification ware and software platforms. For example, the windows-type interface may be
1.2 Test Case Creation visually different depending on the implementation environment, but the same
1.3 Verification basic user behaviors should produce the same results regardless of whether the
1.4 Test Tools client interface is IBM’s OS/2 Presentation Manager, Microsoft’s Windows,
Apple’s Macintosh, or Open Software Motif. The
2.0 Server suggests a client/server test plan outlined in Figure 28.6.
21. Test Data Creation
2.2 Volume/Stress Testing
2.3 Verification 28.5.2 C/S Testing Tactics
2.4 Test Tools
Even if the C/S system has not been implemented using object-technology, ob-
3.0 Connectivity ject-oriented testing techniques (Chapter make good sense because the
3.1 Performance replicated data and processes can be organized into classes of objects that share
3.2 Volume/Stress Testing the same set of properties. Once test cases have been derived for a class of ob-
3.3 Verification jects (or their equivalent in a conventionally developed system), those test cases
3.4 Test Tools should be broadly applicable for all instances of the class.
The 00 point of view is particularly valuable when the graphical user inter-
4.0 Technical Quality face of modem systems is considered. The GUI is inherently object-oriented
and departs from traditional interfaces because it must operate on many plat
4.1 Definitions
forms. In addition, testing must explore a large number of logic paths because the
4.2 Defect Identification
creates, manipulates, and modifies a broad range of graphical objects. Testing
4.3 Metrics is further complicated because the objects can be present or absent, they may ex-
4.4 Code Quality ist for a length of time, and they can appear anywhere on the desk-top.
4.5 Test Tools What this means is that the traditional capture/playbackapproach for
testing conventional character-based interfaces must he modified in order to
5.0 Functional Testing handle the complexities of the GUI environment. A functional variation of the
5.1 Definitions capture/playback paradigm called structured capture/playback has
5.2 Test Data Creation evolved for GUI testing.
5.3 Verification Traditional capture/playback input as keystrokes and output as
5.4 Test Tools screen images which are saved to compare against inputs and output images
of subsequent tests. Structured capture/playback is based on an internal (logi-
cal) view of external activities. The application program’s interactions with the
6.0 System Testing GUI are recorded as internal events which can be saved as “scripts” written in
6.1 Definition Microsoft’s Visual Basic, in one of the C variants, or in the vendor’s proprietary
6.2 Usability Testing language. A variety of useful tools (e.g., and have
6.3 User Satisfaction Surveys been developed to accommodate this testing approach.
6.4 Tools that do not address traditional data validation or path
6.6 Test Tools Tho black-box and white-hox discussed in Chapter
in many and object-oriented strategies
7.0 Testing Management in Chapter are appropriate both and server software.
FIGURE 28.6. 7.1 Test Team
A revised 7.2
28.4 SUMMARY
7.3 Required
plan bared on
7.4 Teat Analysis, and Tracking Mechanisms
Although client/server systems can adopt one or of the software process
nnd mnny of thn and testing methods
802 PART FIVE. ADVANCED TOPICS IN ENGINEERING CHAPTER 28 CLIENT/SERVER SOFTWARE ENGINEERING 803
lier in this book, the special architectural features of C/S require customization PROBLEMS AND POINTS TO PONDER
of the software engineering approach. In general, the software process model
applied for C/S systems is evolutionary in nature, and the technical methods 28.1. Using trade publications or Internet for background information,
often gravitate toward object-oriented approaches. The developer must describe define a set of criteria for evaluating tools for C/S software engineering.
objects that result in the implementation of user interaction/presentation, 28.2. Suggest five applications in which a fat server would seem to be an appro-
database, and components. The objects defined for these compo- priate design strategy
nents must be allocated to either the server machines, and can be
applications in which a fat client would seem to be an
linked via an object request broker.
Object request broker architectures support C/S in which client ob-
28.4. Do some additional research on the CORBA standard and determine how
jects send messages to server objects. The CORBA standard makes use of in-
the latest release of the standard addresses interoperability among different
terface definition language, and interface repositories manage requests for ob-
by
jects regardless of their location on the network.
Analysis and design for client/server systems make use of data flow and Research query and provide a brief example of
entity-relationship diagrams, modified structure charts, and other notation how a transaction might be characterized using the language.
that is encountered in the development of conventional applications. Testing 28.6. Research the latest advances in groupware and develop a brief presentation
strategies must be modified to accommodate tests that examine network com- for your class. Your instructor may assign a specific function to different pre-
munication and the interplay between software that resides on client and senters.
server. 28.7. A company is a new catalog sales division to sell casual
outdoor The catalog will be published on the World
Wide Web, and orders can be placed by e-mail, via the Web site, or via tele-
phone, or fax. A client/server system will be built to support order process-
REFERENCES ing at the Define a set of high-level objects that would be re-
quired for the order-processing system and organize these objects into three
Berson, A., Client Architecture, McGraw-Hill, 1992. component categories: the user interaction/presentation, database, and ap-
Binder, R., “A CASE-Based Systems Engineering Approach to plication.
Server Development,” CASE Trends, 1992. 28.8. Formulate business rules to establish when shipment can be made if pay-
Binder, R., “Scenario-Based Testing for Client Server Systems,” Software ment is by credit card for the system described in problem 28.7. Add addi-
vol. 3, no. 8, August 1995, pp. 43-49. tional rules if payment is by check.
Brown, A.W., Object-Oriented Databases, McGraw-Hill, 1991.
28.9. Develop a state-transition diagram (Chapter that defines the events and
Farley, K.J., “Software Testing For Windows Developers,” Data Based
states that would be visible to an order entry clerk working at a client PC
Advisor, November 1993, pp. 45-46,
within the catalog sales division (problem 28.7).
The conference presentation, 1993.
Hayes, “Automated Testing For Everyone,” OS/2 Professional, 2 8 . 1 0 . Provide examples of three or four messages that might result in a request
November 1993, 51. from a client for a method maintnined on the server.
D., “Managing Software Testing in the Client/Server Milieu,” (in
press).
and Zahavi, The Essential CORBA, Wiley, 1995. FURTHER READINGS AND OTHER INFORMATION SOURCES
Musa, J., “Operational Profiles in Software Reliability Engineering,”
IEEE Software, March 1993, pp. 14-32.
Orfali, R., D. Harkey, and J. Edwards, Essential Survival Although the basic methods% for analysis and design of client/server architec-
Guide, Wiley, 1994. tures are quite similar to more conventional systems, C/S-specific knowledge
Orfali, R., D. Harkey, and J. Edwards, The Essential Distributed Objects must be introduced. Orfali and his colleagues have written one of the
Guide, Wiley, 1996. more readable introductions to the technology. Watterson (Client/Server
Paul, L.G., “Client/Server Deployment,” December 18, Technology for Managers, Addison-Wesley, 1995) provides an introductory
1995. overview of the technologies involved and the application focus of early sys-
Porter, J., O-DES Design Manual, Fairfield University, 1994. tems. On a more detailed level, (Introduction to Networking, Que
Porter, J., Guide, McGraw-Hill, 1995. Corporation, 1994) and (Client/Server Computing, McGraw-Hill, 1993)
Quinn, S.R., J.C. Ware, and J. Spragens, “Tireless Testers; Automated provide a thorough discussion of technology issues.
Tools Can Help Iron Out the Rinks in Your Custom GUI Applications,” Tech-Ease (Client-Server Computing, Prentice-Hall, has published a
Infoworld, September 1993, pp. 78-79, 82-83, 85. general introduction to C/S systems and architectures. The following books are
D., Strategies, IDG Books, 1993. also worth examining:
PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING
Benson, A., Client/Server Architecture, 2nd edition, McGraw-Hill, 1996.
Goglia, P. A., Testing Applications, Wiley, 1993.
Inmon, W.H., Developing Client/Server Applications, Wiley, 1994
Koelmel, R. L., Implementing Application Solutions in a Client/Server
COMPUTER-AIDED
Environment, Wiley, 1995
Spohn, D.L., Data Network Design, 2nd edition, McGraw-Hill, 1996.
SOFTWARE
Because client/server technology is evolving so rapidly, industry periodicals
and electronic information resources may be the best source of current infor-
mation. The FAQ for the newsgroup comp.client-server can be found at:
or
ENGINEERING
Information on the latest CORBA standards can be obtained at:
A discussion of testing for C/S systems can be found at:
E has heard the saying about the shoemaker’s children: The shoe-
maker is so busy making shoes for’others that his children don’t have shoes
of their own. Over the past 20 years, many software engineers have been the
“shoemaker’s children.” Although these technical professionals have built com-
plex systems that automate the work of others, they have used very little au-
The Client/Server Coffeehouse provides a forum for Q&A among professionals tomation themselves. In fact, until recently software engineering was funda-
who are trying to implement C/S technologies: mentally a manual activity in which tools’ were used only at latter stages of
the process.
Today, software engineers have finally been given their first new pair of
software engineering (CASE). The shoes don’t come in
An up-to-date list of World Wide Web references for client/server software as many varieties as they would like, are often a bit stiff and sometimes un-
engineering can be found at: comfortable, don’t provide enough sophistication for those who are stylish, and
don’t always match other garments that software developers use. But they pro-
vide an absolutely essential piece of apparel for the software developer’s
wardrobe, and will, over time, become more comfortable, more usable, and more
adaptable to the needs of individual practitioners.
In earlier chapters of this book we have attempted to provide a reasonable
of the underpinnings of software engineering technology. In this
chapter, the focus shifts to the tools and environments that will help to auto-
mate the software process.
‘In many cases, the only tools available the software engineer were compilers and text ed-
itors. These tools address only coding-an activity that should take no than 20 percent
of the overall process.
806 PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 29: COMPUTERAIDED SOFTWARE ENGINEERING 807
29.1 WHAT IS CASE? individual tool
(point solution)
The best workshop for any craftsperson-a mechanic, a carpenter, or a software
engineer-has three primary characteristics: a collection of useful tools that
will help in every step of building a product; (2) an organized layout that en- data exchange
ables tools to be found quickly and used efficiently; and a skilled craftsman
who understands how to use the tools in effective manner. Software engi-
neers now recognize that they need more and varied tools (hand tools alone just tool bridges single source
won’t meet the demands of modern computer-based systems), and they need an partnerships
organized and efficient workshop in which to place the tools.
The workshop for software engineering is called an integrated project sup-
port environment (discussed later in this chapter), and the tool set that fills the
work shop is called computer-aided software engineering (CASE).
CASE tools add to the software engineer’s tool box. CASE provides the en-
consortium
gineer with the ability to automate manual activities and to improve engi-
standards
neering insight. Like computer-aided engineering and design tools that are
used by engineers in other disciplines, CASE tools help to ensure that quality
is designed in before the product is built.
IPSE
29.2 BLOCKS FOR CASE
vironments for software engineering are built on an environment architecture
addition, the
Computer-aided software engineering can be as simple as a single tool that environment architecture must consider the human work patterns that are ap-
supports a specific software engineering activity or as complex as a complete plied during the software engineering process.
environment that encompasses tools, a database, people, hardware, a network, The environment architecture, composed of the hardware platform and op-
operating systems, standards, and myriad other components. The building erating system support (including networking and database management soft-
blocks for CASE are illustrated in Figure 29.1. Each building block forms a ware), lays the ground work for CASE. But the CASE environment itself de-
foundation for the next, with tools sitting at the top of the heap. It is interest- mands other building blocks. A set of portability services provides a bridge
ing to note that the foundation for effective CASE environments has relatively between CASE tools and their integration framework and the environment ar-
little to do with software engineering tools themselves. Rather, successful en- chitecture. The integration framework is a collection of specialized programs
that enables individual CASE tools to communicate with one another, to create
a project database, and to exhibit the same look and feel to the end user (the
software engineer). Portability services allow CASE tools and their integration
, CASE Tools , framework to migrate across different hardware platforms and operating sys-
tems without significant adaptive maintenance.
The building blocks depicted in Figure 29.1 represent a comprehensive
foundation for the integration of CASE tools. However, most CASE tools in use
today have not been constructed using all of the building blocks discussed
above. In fact, some CASE tools remain “point solutions.” That is, a tool is used
to assist in a particular software engineering activity (e.g., analysis modeling),
but does not directly communicate with other tools, is not tied into a project
database, and is not part of an integrated CASE environment (I-CASE).
Although this situation is not ideal, a CASE tool can be used quite effectively,
even if it is a point solution.
The relative levels of CASE integration are shown in Figure 29.2. At the
low end of the integration spectrum is the individual (point solution) tool.
FIGURE29.1. When individual tools provide facilities for data exchange (most do), the in-
Case building blocks tegration level is improved slightly. Such tools produce output in a standard
808 PART ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 29: COMPUTER-AIDED SOFTWARE ENGINEERING 809
format that should be compatible with other tools that can read the format. In Process Modeling and Management Tools. If an organization works to
some cases, the builders of complementary CASE tools work together to form improve a business (or software) process, it must understand it. Process
a bridge between the tools (e.g., an analysis and design tool that is coupled with modeling tools (also called “process technology” tools) are used to represent
a code generator). Using this approach, the between the tools can pro- , the key elements of a process so that it can be better understood. Such tools
end products that would be to create using either tool separately. can also provide links to process descriptions that help those involved in
Single source integration occurs when a single CASE tools vendor integrates a the process to understand the work tasks that are required to perform the
number of different tools and sells them as a package. Although this approach process. In addition, process management tools can provide links to other
is quite effective, the closed architecture of most single source environments tools that provide support to defined process activities.
precludes easy addition of tools from other vendors. Project Planning Tools. Tools in this category focus on two primary ar-
At the high end of the integration spectrum is the integrated project sup- eas: software project effort and cost estimation, and project scheduling.
port environment Standards for each of the building blocks described Estimation tools compute estimated effort, project duration, and recom-
above are created. CASE tools vendors use these IPSE standards to build tools mended number of people using one or more of the techniques introduced
that will be compatible with the IPSE and therefore compatible with one an- in Chapter 5. Project scheduling tools enable the manager to define all proj-
other. ect tasks (the work breakdown structure), create a task network (usually
using graphical input), represent task interdependencies, and model the
amount of parallelism possible for the project (Chapter
29.3 A TAXONOMY OF CASE Risk Analysis potential risks and developing a plan to mit-
igate, monitor, and manage them is of paramount importance on large projects.
A number of risks are inherent whenever we attempt to categorize CASE Risk analysis tools enable a project manager to build a risk table (Chapter
tools. There is a subtle implication that to create an effective CASE environ- by providing detailed guidance in the identification and analysis of risks.
ment one must implement all categories of tools-this is simply not true. Project Management Tools. The project schedule and project plan must
Confusion (or antagonism) can be created by placing a specific tool within one
be tracked and monitored on a continuing basis. In addition, a manager
category when others might believe it belongs in another category, Some read- should use tools to collect metrics that will ultimately provide an indica-
ers may feel that an entire category has been omitted-thereby eliminating tion of software product quality. Tools in the category are often extensions
an entire set of tools for inclusion in the overall CASE environment. In addi- to project planning tools.
tion, simple categorization tends to be flat-that is, we do not show the hier-
archical interaction of tools or the relationships among them. Even, with these Requirements Tracing Tools. When large systems are developed, the de-
risks, it is necessary to create a taxonomy of CASE tools-to better understand livered system often fails to meet customer specified requirements. The ob-
the breadth of CASE and to better appreciate where such tools can be applied jective of requirements tracing tools is to provide a systematic approach to
in the software process. the isolation of requirements, beginning with the customer request for pro-
CASE tools can be classified by function, their role as instruments for posal or specification. The typical requirements tracing tool com-
managers or technical people, by their use in the various steps of the software bines human-interactive text evaluation, with a database management sys-
engineering process, by the environment architecture (hardware and software) tem that stores and categorizes each system requirement that is “parsed”
that supports them, or even by their origin or cost The taxonomy pre- from the original RFP or specification.
sented below uses function as a primary criteria. Metrics and Management Tools. Software metrics improve a manager’s
ability to control and coordinate the software and a practitioner’s
Information Engineering Tools. By modeling the strategic information ability to improve the quality of the software that is produced. Today’s met-
requirements of an organization, engineering tools provide a rics and measurement tools focus on process, project, and product charac-
“metamodel” from which specific information systems are derived. Rather teristics. -Management-oriented tools capture project-specific metrics (e.g.,
then focusing on the requirements of a specific application, these CASE defects per function point) that provide an overall in-
tools model business information as it moves between various dication of productivity or quality. Technically oriented tools determine
tional entities within a company. The primary objective for tools in this cat- technical metrics (Chapters 18 and that provide greater insight into the
egory is to represent business data objects, their relationships, and how quality of design or code. Many of the more advanced metrics tools main-
these data objects flow between different business areas within a company. tain a database of “industry average” measures. Based on project and
characteristics provided by the user, such tools “rate” local numbers
against industry averages (and past local performance) and suggest strate-
gies for improvement.
for vendors who offer representative tools for each category presented in the sections
that follow have been listed
in Other Information at the end Documentation Tools.Document production and desk-top publishing
of thin chapter. tools support nearly every aspect of software engineering and represent a
29
810 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING 811
window icons, scrolling mechanisms, device drivers and
substantial “leverage” opportunity for all software developers. Most soft-
so forth. However, these tool kits are being replaced by interface
ware development organizations spend a substantial amount of time de-
ing tools that enable rapid on-screen creation of sophisticated user inter-
veloping documents, and in many cases the documentation process itself is
faces that conform to the interfacing standard that has been adopted for
quite inefficient. It is not unusual for a software development organization the software.
to spend as much as 20 or 30 percent of all software development effort on
Prototyping Tools.A variety of different prototyping tools can be used.
documentation. For this reason, documentation tools provide an important
Screen painters enable a software engineer to define screen layout rapidly
opportunity to improve productivity.
for interactive applications. More sophisticated CASE prototyping tools en-
System Software Tools. CASE is a workstation technology. Therefore, the , able the creation of a data design, coupled with both screen and report lay-
CASE environment must accommodate high-quality network system soft- outs. Many analysis and design tools have extensions that provide a
ware, electronic mail, bulletin boards, and other communication capabili- option. tools generate skeleton Ada and C source code
ties. for engineering (real-time) applications. Finally, a variety of fourth gener-
Quality Assurance Tools. The majority of CASE tools that claim to focus ation tools have prototyping features.
on quality assurance are actually metrics tools that audit source code to Programming Tools. The programming tools category encompasses com-
determine compliance with language standards. Other tools extract tech- pilers, editors, and debuggers that are available to support most conven-
nical metrics (Chapter in an effort to project the quality of the software tional programming languages. In addition, object-oriented program-
that is being built. ming environments, fourth generation languages, graphical programming
Database Management Tools. Database management software serves as environments, application generators, and database query languages also
a foundation establishment of a CASE database (repository), which reside within this category.
we have also called the project database (Chapter Given the emphasis In
Integration and Testing Tools. their directory of software testing
on configuration objects, database management tools for CASE may evolve tools, Software Quality Engineering defines the following testing
from relational database management systems to object-oriented tools categories:
database management systems
Software Configuration Management Tools. Software configuration
management (SCM) lies at the kernel of every CASE environment. Tools . data acquisition-tools that acquire data to be used during testing
can assist in all five major SCM tasks-identification, version control, that analyze source code without exe-
change control, auditing, and status accounting. The CASE database pro- cuting test cases
vides a mechanism for identifying each configuration item and relating it
to other items; the control process discussed in Chapter 9 can be dynamic measurement-tools that analyze source code during
with the aid of tools; to
ration items CASE communication
simulation-tools that simulate functions of hardware or other ex-
tools can greatly improve status accounting (reporting information about
ternals
changes to all who need to know).
Analysis and Design Tools. Analysis and design tools enable a test management-tools that assist in the planning, development,
engineer to create models of the system to be built. The models contain a and control of testing
representation of data, function, and behavior (at the analysis level), and . cross-functional tools-tools that cross the bounds of the above cat-
characterizations of data, architectural, procedural, and interface design. egories.
By performing consistency and validity checking on the model, analysis
and design tools provide a software engineer with some degree of insight
into the analysis representation and help to eliminate errors before they It should be noted that many testing tools have features that span two or
propagate into the design, or worse, into implementation itself. more of the above categories.
Tools. (prototyping and simulation) tools Static Analysis Tools. Static testing tools assist the software engineer in
provide the engineer with the ability to predict the behavior of a deriving test cases. Three different types of static testing tools are used in
real-time system prior to the time that it is built. In addition, they enable the industry: code-based testing tools, specialized testing languages, and
the software engineer to develop mock-ups of the real-time system that al- requirements-based testing tools. Code-based testing tools accept source
low the customer to gain insight into its function, operation, and response code (or as input and perform a number of analyses that result in the
prior to actual implementation. generation of test cases. Specialized testing languages (e.g., ATLAS) enable
a software engineer to write detailed test specifications that describe each
Interface Design and Development Tools. Interface design and devel-
test case and the logistics for its execution. Requirements-based testing
opment tools are actually a tool kit of program components such as menus,
812 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 29: COMPUTER-AIDED SOFTWARE ENGINEERING 813
tools isolate specific user requirements and suggest test cases classes 29.4 INTEGRATED CASE ENVIRONMENTS
of tests) that will exercise the requirements.
Dynamic Analysis Tools. Dynamic testing tools interact with an exe- Although benefits can be derived from individual CASE tools that address sep-
cuting program, checking path coverage, testing assertions about the arate software engineering activities, the real power of CASE can only be
value of specific variables, and otherwise instrumenting the execution achieved through integration. The benefits of integrated CASE (I-CASE) in-
flow of the program. Dynamic tools can be either intrusive or clude smooth transfer of information (models, programs, documents, data)
sive. An intrusive tool changes the software to be tested by inserted from one tool to another and one software engineering step to the next; a
probes (extra instructions) that perform the activities mentioned above. reduction in the effort required to perform umbrella activities such as software
Nonintrusive testing tools use a separate hardware processor that runs configuration management, quality assurance, and document production; an
in parallel with the processor containing the program that is being increase in project control that is achieved through better planning, monitor-
tested. ing, and communication; and improved coordination among staff members
Test Management Tools.Test management tools are used to control and who are working on a large software project.
coordinate software testing for each of the major testing steps (Chapter 17). But I-CASE also poses significant challenges. Integration demands consis-
Tools in this category manage and coordinate regression testing, perform tent representations of software engineering information, standardized inter-
comparisons that ascertain differences between actual and expected out- faces between tools, a homogeneous mechanism for communication between the
put, and conduct batch testing of programs with interactive human-com- software engineer and each tool, and an effective approach that will enable
puter interfaces. In addition to the functions noted above, many test CASE to move among various hardware platforms and operating systems.
ngcmcnt tools serve as test drivers. A one or Although solutions to the implied by these challenges have been pro-
more test cases from a testing file, formats the test data to conform to the posed, comprehensive I-CASE environments are only to emerge.
needs of the software under test, and then invokes the software to be The term “integration” implies both “combination” and “closure.” I-CASE
tested. combines a variety of different tools and different information in a way that en-
ables closure of communication among tools, between people, and across the
Client/Server Testing Tools.The C/S environment demands specialized
software process. Tools are integrated so that software engineering information
testing tools that exercise the graphical user interface and the network is available to each tool that needs it; usage is integrated so that a common
communications requirements for client and server. look and feel is provided for all tools; and a development philosophy is inte-
Reengineering Tools.The reengineering tools category can be subdivided grated, implying a standardized software engineering approach that applies
into the following functions: modern practice and proven methods.
define integration in the context of the software process, it is necessary
!" reverse engineering to specification tools-take source code as and ‘to establish a set of requirements for I-CASE: An integrated CASE environ-
generate graphical structured analysis and design models, where-used ment should
lists, and other design information;
. code restructuring and analysis tools-analyze program syntax, gener- !" provide a mechanism for sharing software engineering information among all
ate a control flow graph, and automatically generate a structured pro- tools contained in the environment;
gram; and !" enable a change to one item of information to be tracked to other related in-
formation items;
. on-line system reengineering tools-used to modify on-line database systems
(e.g., convert IDMS or DB2 files into entity-relationship format). . provide version control and overall configuration management for all soft-
ware engineering information;
Many of the above tools are limited to specific programming languages !"allow nonsequential access to any tool contained in the environment;
degree support for n procedural rontcxt for software
of interaction with the soft-ware engineer. ing work that integrates the tools and data into a standard work breakdown
Next generation reverse and forward engineering tools will make structure (Chapter 7);
much stronger use of artificial intelligence techniques, applying a knowl-
. enable the users of each tool to experience a consistent look and feel at the
edge base that is application domain specific (i.e., a set of decomposition
interface;
rules that would apply to all programs in a particular application area
such as manufacturing control or aircraft avionics). The AI component will . support communication among software engineers; and
assist in system decomposition and reconstruction, but will still require !"collect both management and technical metrics that can be used to improve
interaction with a software engineer throughout the reengineering cycle. the process and the product.
CHAPTER 29 SOFTWARE ENGINEERING 815
814 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING
user interface layer
interface tool kit
presentation protocol
tools management services
CASE
object management layer
FIGURE29.3. integration services
Elements of I-CASE configuration management services
To achieve these requirements, each of the building blocks of a CASE archi- FIGURE 29.4.
tecture (Figure 29.1) must fit in a fashion. AH shown in Architectural model
Figure 29.3, building blocks--environment architecture, hard- for the integration access control functions
ware platform, and operating system-must be “joined” through a set of porta- framework
bility services to an integration framework that achieves the requirements
noted above.
The tools layer incorporates a set of tools management services with the
CASE tools themselves. Tools management services control the behavior
29.5 THE INTEGRATION ARCHITECTURE of tools within the environment. If multitasking is used during the execution
of one or more tools, TMS performs multitask synchronization and communi-
A software engineering team uses CASE tools, corresponding methods, and a cation, coordinates the flow of information from the repository and object man-
process framework to create a pool of software engineering information. The in- agement system into the tools, accomplishes security and auditing functions,
tegration framework facilitates transfer of and out of the pool. and collects metrics on tool usage,
To accomplish this, the following architectural components must exist: a data- The object management layer performs the configuration manage-
base to store the information, an object management system to manage changes ment functions described in Chapter 8. In essence, software in this layer of the
to the information, a tools control mechanism to coordinate the use of CASE framework architecture provides the mechanism for tools integration. Every
tools, and a user interface to provide a consistent pathway between actions CASE tool is “plugged into” the object management layer. Working in conjunc-
made by the user and the tools contained in the environment. Most models tion with the CASE repository, the OML provides integration services-a set of
(e.g., of the integration framework represent these compo- standard modules that tools with the repository. In addition, the OML
nents as layers. A simple model of the framework depicting only the compo- provides configuration management services by enabling the identification of
nents noted above is shown in Figure 29.4. all configuration objects, performing version control, and providing support for
The interface layer (Figure incorporates xtundurdized interface control, audits, and status accounting.
tool kit with a common presentation protocol. tool kit contains The repository layer is the CASE database:’ and the access control
functions that enable the object management layer to interact with the data-
software for human-computer interface management and a library of display
objects. Both provide a consistent mechanism for communication between the base. Data integration is achieved by the object management and shared repos-
interface and individual CASE tools. The presentation protocol is the set of itory layers.
guidelines that gives all CASE tools the same look and feel. Screen layout con-
ventions, menu names and organization, icons, object names, the use of the key-
board and mouse, and the mechanism for tools access are all defined as part of
Chapter 9 we to the repository the project database.
the presentation protocol.
816 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 29: COMPUTER-AIDED SOFTWARE ENGINEERING 817
29.4 THE CASE REPOSITORY integration-the database management system relates data ob-
jects so that other functions can be achieved,
Webster’s Dictionary defines the word “repository” as “any thing or person !" methodology enforcement-the E-R model of data stored in the repository can
thought of as a center of accumulation or During the early history of imply a specific paradigm for software engineering-at a minimum, the re-
software development, the repository was indeed a person-the programmer lationships and objects define a set of steps that must be conducted to build
who had to remember the location of all information relevant to a software proj- the contents of the repository; and
ect, who had to recall information that was never written down and reconstruct !" document standardization-the definition of objects in the database leads di-
information that had been lost. Sadly, using a person as “the center for accu- rectly to a standard approach for the creation of software engineering docu-
mulation and storage” (although it conforms to the dictionary definition), does ments.
not work very well. Today, the repository is a “thing”-a database that acts as
the center for both accumulation and storage of software engineering informa-
achieve these functions, the repository is defined in of a
tion. The role of the person (the software engineer) is to interact with the repos-
model. The metamodel determines how information is stored in the
using CASE tools that are integrated with it.
In this book, a number of different terms are used to refer to the storage how data can be accessed by tools and viewed by software engineers, how well
place for software engineering information: CASE database, project database, data security and integrity can be maintained, and how easily the existing
integrated project support environment database, data dictionary (a model can be extended to accommodate new needs
limited database), and repository. Although there are subtle differences be- The metamodel is the template into which engineering informa-
tween some of these terms, all refer to the thing-the center for accumulation tion is placed. An entity-relationship metamodel can be created, but other, more
and storage. sophisticated models are also under consideration. A detailed discussion of these
models is beyond the scope of this book. For further information, the interested
reader should see and
29.6.1 The Role of the Repository in I-CASE
The repository for an I-CASE is the set of mechanisms and data 29.6.2 Features and
structures that achieve data-tool and data-data integration. It provides the ob-
vious functions of a database management but in addition, the repos-
The features and content of the repository are best understood by looking at it
itory performs or precipitates the following functions
from two perspectives: What is to be stored in the repository and what specific
services are provided by the repository? In general, the types of things to be
. integrity-includes functions to validate entries to the repository, en- in the repository include:
sure consistency among related objects, and automatically perform “cascad-
ing” modifications when a change to one object demands some change to ob- the problem to be solved
jects that are related to it;
information about the problem domain
information &ring-provides a mechanism for sharing information among
the system solution as it emerges
multiple developers and between multiple tools, manages and controls multi-
user access to data and locks/unlocks objects so that changes are not inad- rules and instructions pertaining to the software process (methodology) be-
vertently overlaid on one another; ing followed
. integration-establishes a data model that can be accessed by all the project plan, resources, and history
tools in the I-CASE environment, controls access to the data, and performs the organizational context
appropriate configuration management functions;
A detailed list of types of representations, documents, and deliverables that
are stored in the CASE repository is included in Table 29.1.
A robust CASE repository provides two different classes of services: the
types of services that might be expected from any sophisticated database man-
‘Some of the other definitions of this word equally intriguing when we consider the cur-
rent state of engineering practice: a mom where things placed for agement system, and services that are specific to the CASE environment.
ing; building for exhibiting objects; vault.”
many investigators feel that object-oriented database management system is
the correct approach, others believe that relational do the joh adequately. section been adapted from with permission of CASE Consulting Group.
818 PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 29 COMPUTERAIDED SOFTWARE ENGINEERING 819
Data independence. CASE tools and the target applications are isolated
from physical storage so that they are not affected when the configuration
CASE REPOSITORY CONTENTS is changed.
Transaction control. The repository manages multipart interactions in
a manner that maintains the integrity of the data when there are con-
Enterprise information Construction
current users and in the event of a system failure. This usually implies
Organizational structure Source code; Object code
build instructions record locking, two-stage commits, transaction logging, and recovery pro-
Business area analyses cedures.
Business functions
Business rules Configuration dependencies Security. The repository provides mechanisms to control who can view and
Process models (scenarios) Change information modify information contained within it. At a minimum, the repository
information architecture should enforce multilevel passwords and permission levels assigned by in-
Validation and verification dividual users. The repository should also provide assistance for automatic
Test plan; data cases backup and archiving of selected groups of information-for
Application design
Regression project or
Methodology rules
Graphical representations Test results Ad hoc data queries and reports. The repository allows direct access to
System diagrams Statistical analyses its contents through a convenient user interface such as SQL or a
Naming standards Software quality metrics oriented “browser,” enabling user-defined analysis beyond the standard re-
Referential integrity ports provided with the CASE tool set.
structures Project management information Openness. Repositories usually provide a simple import/export mecha-
Process definitions Project plans nism to enable bulk loading or transfer. The interfaces are usually a flat
Closs definitions Work breakdown structure ASCII file transfer or a standard SQL interface. Some repositories have
Menu trees Estimates; Schedules higher-level interfaces that reflect the structure of their metamodels.
Performance criteria Resource loading; Problem reports
Timing constraints Change requests; Status reports Multiuser A robust repository must permit multiple developers
Screen definitions Audit information to work on an application at the same time. It must manage concurrent ac-
Report definitions cess to the database by multiple tools and users with access arbitration and
logic definitions locking at or For environments baaed on networking,
Behavioral logic multiuser support also implies that the repository can interface with com-
Requirements documents
Algorithms External/internal designs
mon networking and
Transformation rules User manuals
The CASE environment also makes special demands on the repository that
go beyond what is directly available in a commercial DBMS. The special fea-
tures of CASE include:
Many repository requirements are the same as those of typical applications
built on a commercial database management system (DBMS). In fact, most of Storage of sophisticated data structures. The repository must accom-
CASE repositories employ a DBMS (usually relational or object-ori- modate complex data types such as diagrams, documents and tiles, as well
ented) as the basic data management technology. The standard DBMS features as simple data elements. A repository also includes an information model
of a CASE repository supporting the management of software development in- (or describing the structure, relationships, and semantics of
formation include: the data stored in it. The metamodel must be extensible so that new rep-
resentations and unique organizational information can be accommodated.
Nonredundant data storage.The CASE repository provides a single The repository not only stores models and descriptions of the systems un-
place for the storage of all information pertinent to the development of der development, but also associated metadata (i.e., additional information
software systems, eliminating wasteful and potentially error-prone dupli- describing the engineering information itself, such as when a par-
cation. ticular design component was created, what its current status is, and what
other components it depends upon).
High-level access. The repository provides a common data access mecha-
nism so that data handling facilities do not have to be duplicated in each Integrity enforcement. The repository information model also contains
CASE tool. rules, or policies, describing valid business rules and other constraints and
820 PART FIVE: ADVANCED IN SOFTWARE ENGINEERING CHAPTER 29: COMPUTER-AIDED ENGINEERING 821
requirements on information being entered into the repository (directly or repository concept to the improvement of the software development process.
via a CASE tool). A facility called a trigger may be employed to activate the Among the many functions that link management supports is the ability to
rules associated with an object whenever it is modified, making it possible and assess the effects of change. As designs evolve to meet new re-
to check the validity of design models in real time. quirements, the ability to identify all objects that might be affected enables
tool interface.The repository information model more accurate assessment of cost, downtime, and degree of difficulty. It also
model) contains semantics that enable a variety of tools to interpret the helps prevent unexpected side effects that would otherwise lead to defects and
meaning of the data stored in the repository For example, a data flow dia- system failures.
gram created by a CASE tool is stored in the repository in a form based on
the information model and independent of any internal representations Requirements T r a c i n g A special function depending on link management is re-
used by the tool itself. Another CASE tool can then interpret the contents quirements tracing. This is the ability to track all the design components and
of the repository and use the information as needed for its task. Thus, the deliverables that result from a specific requirement specification (forward
semantics stored in the repository permit data sharing among a variety of tracking), as well as the ability to identify which requirement generated any
tools, as opposed to specific tool-to-tool conversions or “bridges.” given deliverable (backward tracking).
A
Process/project management. repository contains information not
only about the software application but also about the Configumtion M a n a g e m e n t Another function depending on link management is
tics of each particular and the organization’s general process for configuration management. A configuration management facility works closely
software tasks, deliverables). This opens up with the link management and versioning facilities to keep track of a series of
sibilities for automated coordination of technical development activity with configurations representing specific project milestones or production releases.
the project management activity. For example, updating the status of proj- Version management provides the needed versions, and link management
ect tasks could be done automatically or as a by-product of using the CASE keeps track of interdependencies. For example, configuration management of-
tools. Status updating could be made very easy for developers to perform ten-provides a build facility to automate the process of transforming design
without having to leave the normal development environment. Task as- components into executable deliverables.
signment and queries can also be handled by electronic mail. Problem re-
ports, maintenance tasks, change authorization, and repair status can be Audit Related to change management is the need for an audit trail that
coordinated and monitored via tools accessing the repository. establishes additional information about when, why, and by whom changes are
made. Actually, this is not a difficult requirement for a repository that has a
The following repository features are all encompassed by software config- bust information model. Information about the source of changes can be en-
uration management (Chapter They are re-examined here to emphasize tered as attributes of specific objects in the repository. A repository trigger
their interrelationship to I-CASE environments. mechanism is helpful for prompting the developer or the tool he or she is us-
ing to initiate entry of audit information (such as the reason for a change)
Venioning As a project progresses, many versions of individual work products whenever a design element is modified.
will be created. The repository must be able to save all of these versions to en-
able effective management of product releases and to permit developers to go
back to previous versions during testing and debugging. Versioning is done 29.7 SUMMARY
with a compression algorithm to minimize storage allocation, and permits re-
generation of any previous version with some processing overhead. Computer-aided software engineering tools span every step in the software
process and those umbrella activities that are applied throughout the process.
Dependency Tracking and Change Management The repository manages a wide CASE combines a set of building blocks that begin at the hardware and oper-
variety of relationships among the data elements stored in it. These include re- ating system level and end with individual tools.
lationships between enterprise entities and processes, among the parts of an In this we have considered a taxonomy of CASE tools. Categories en-
application design, between design components and the enterprise information compass both management and technical activities and span most software ap-
architecture, between design elements and deliverables, and so on. Some of plication areas. Each category of tool has been considered as a “point solution.”
these relationships are merely associations, and some are dependencies or The I-CASE environment combines integration mechanisms for data, tools,
mandatory relationships. Maintaining these relationships among development and human-computer interaction. Data integration can be achieved through
objects is called management. direct exchange of information, through common tile structures, by data shar-
The ability to keep track of all of these relationships is crucial to the in- ing or interoperability, or through the use of a full I-CASE repository. Tools in-
tegrity of the information stored in the repository and to generation of tegration can be custom-designed by vendors who work together or can he
based on it, it is important contributions of the through management software provided as part of the repository.
PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 29: COMPUTER-AIDED SOFTWARE ENGINEERING
822 823
Human-computer integration is achieved through interface standards that are categories noted in Section 29.3. Use Part Two of this book for additional
becoming increasingly common throughout the industry. An integration archi- guidance.
tecture is designed to facilitate the integration of users with tools, tools with 29.5. Do some research on object-oriented database management systems. Discuss
tools, tools with data, and data with data. why OODMS would be ideal for SCM tools.
The CASE repository has been referred to as a “software bus.” Information 29.6. Gather product information on at least three analysis and design tools.
moves through it, passing from tool to tool as the software process progresses.
It is also a storage place that Develop a matrix that compares features.
But the repository is much more than a
29.7. Gather product information on two tools. Develop a matrix that
combines sophisticated mechanisms for integrating CASE tools and thereby
improving the process through which software is developed. The repository is compares features.
a relational or object-oriented database that is “the center of accumulation and 29.6. Gather product information on at least three fourth generation coding tools.
storage” for software engineering information. Develop a matrix that compares features.
29.9. Are there situations in which dynamic testing tools are “the only way to go.”
If so, what are thev?
29.10. Discuss other human activities in which the integration of a set of tools has
REFERENCES provided substantially more benefit than the use of each of the tools indi-
vidually, Do not use examples from computing.
Forte, G., Search of the Integrated Environment,” CASE Outlook, . 29.11. Describe what is meant by data-tool integration in your own words.
March/April 1989, pp. 5-12. 29.12. In a number of places in this chapter, the terms and
Forte, G., “Rally Round the Repository,” Outlook, December 1989, are used. Describe what these terms mean in your own words.
pp. 5-27.
29.13. Can you think of additional configuration items that might be included in
Forte, G., “Integrated CASE: A Definition,” 3rd Annual
the repository contents shown in Table Make a list.
WORKERS User’s Group Conference, Cadre
Providence, RI, March 1990.
Griffen, “Repositories: Data Dictionary Descendant Can Extend
Legacy Code Investment,” Application Development April 995,
pp. 65-71. FURTHER READINGS AND OTHER INFORMATION SOURCES
Nichols, K.M., “Performance Tools,” IEEE Software, May 1990, pp. 21-23.
CASE: The Potential and the Pitfalls, QED Information Sciences, Inc.,
MA, 1989. A number of books on CASE were published in the 1980s in an effort to cap-
Sharon, D., and R. Bell, “Tools that Bind: Creating Integrated italize on the high degree of interest in the industry at that time. Subsequently,
Environments,” IEEE Software, March 1995, pp. 7685. relatively few books on the subject have appeared. Of -the books that have
Tools Reference Guide, Software Quality Engineering, been published, many suffer from one or more of the following failings: the
book only focuses on a narrow band of tools (e.g., analysis and design) while
Jacksonville, FL, 1995.
Welke, R.J., Systems on Models,” CASE Outlook, December claiming to cover a wider categorization; the book spends relatively little
1989, pp. ‘35-45. time on CASE and more time surveying (often poorly) the underlying meth-
ods that the tools deliver; the book spends little time discussing integra-
tion issues; and the presentation is outdated because of an emphasis on
specific CASE products. The books that follow have avoided at least some of
PROBLEMS AND POINTS TO PONDER these failings:
Braithwaite, Application Development Using CASE Tools, Academic
29.1. Make a list of all software development tools that you use. Organize them
according to the taxonomy presented in this chapter. Press, 1990.
29.2. What are the strengths of the “old-fashioned” software development envi- Fisher, C., CASE: Using Software Development Wiley, 1988.
ronment architecture that made use of a mainframe and terminals? What C., Computer-Aided Software Engineering: The Methodologies, the
are the disadvantages? Products and the Future, Prentice-Hall, 1990.
29.2. Using the ideas introduced in Chapter 14 and/or 19, how would you suggest Lewis, Computer-Aided Software Engineering, Van Nostrand Reinhold,
that portability services be built? 1990.
29.4. Build a paper prototype for a project management encompasses the McClure, C., CASE is Software Automation, Prentice-Hall, 1988.
824 PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING 29: COMPUTER-AIDED SOFTWARE ENGINEERING 825
Schindler, M., Computer-Aided Software Design, Wiley, 1990. Many of the electronic references contained in earlier chapters contain point-
Towner, L.E, CASE: Concepts and Implementation, McGraw-Hill, 1989. ers to specific CASE tools.
An up-to-date list of World Wide Web references for software reengineering
can be found at:
An anthology by Chikofsky (Computer-Aided Software Engineering, IEEE
Computer Society Press, 1988) contains a useful collection of early papers on
CASE and software development environments. The of current in-
formation on CASE tools are technical periodicals and industry newsletters.
Although there is great interest in I-CASE environments and the CASE
repository, relatively few books treat these subjects in detail. Garg and
(Process Centered Software Engineering Enuironments, IEEE Computer Society
Press, 1995) consider development environments that are driven by process
models. Books by Brereton (Software Engineering Environments, Wiley,
Charette (Software Engineering Enuironments, McGraw-Hill, and
Bar-stow, Shrobe, and Sandewall (Interactive Programming Environments,
McGraw-Hill, 1984) present different views of the “ideal” CASE environment
and provide an historical supplement to the information presented in this chap-
ter.
IEEE Standard 1209 (Evaluation and Selection of CASE presents a
set of guidelines for evaluating CASE tools for “project management processes,
processes, development processes, postdevelopment processes,
and integral processes.” Automated Software Engineering Academic
Publishers, URL: is a journal that discusses new ad-
vances in software tools.
A wide array of CASE tools information is available on the World Wide
Web. Every major CASE vendor maintains its own site, and many compendi-
ums of tools have been developed. An extensive CASE tools index has been de-
veloped and can be found at:
Many major CASE vendors provide Web sites. A of pointers,
organixcd by tool category, can be obtained nt:
Direct access to freeware and shareware CASE tools and a directory of CASE
Vendor Web sites can be obtained at the CASE Tools page:
Electronic copies of various tools integration standards (including can
be obtained at The MIT Microsystems Lab:
CHAPTER THE ROAD AHEAD
827
30.1 THE IMPORTANCE OF SOFTWARE-REVISITED
The importance of computer software can be stated in many ways. In Chapter
1, software was characterized as a differentiator. The function delivered by soft-
THE ROAD AHEAD
ware differentiates products, systems, and services, and provides competitive
advantage in the marketplace. But software is more than a differentiator. The
programs, documents, and data that are software help to generate the most im-
portant commodity that any individual, business, or government can
information. Pressman and describe software in the following
way:
Computer software is one of only a few key technologies that will have a
significant impact on nearly every aspect of modern society during the 1990s.
It is a mechanism for automating business, industry, and medium
a method of capturing valuable expertise for
use by others, a means for differentiating one company’s products from its com-
petitors, and a window into a corporation’s collective knowledge. Software is
pivotal to nearly every aspect of business. But in many ways, software is also
a hidden technology We encounter software without realizing it) when
we travel to work, make any retail purchase, stop at the bank, make a phone
call, visit the doctor, or perform any’of the hundreds of day-to-day activities
that reflect modern life.
n the 29 chapters that have preceded this one, we have explored a process Software is pervasive, and yet, many people in positions of responsibility
for software engineering. We have presented management procedures and have little or no real understanding of what it really is, how it’s built, or what
technical methods, basic principles and specialized techniques, people-oriented it means to the institutions that they (and it) control. More important, they
activities and tasks that are amenable to automation, paper and pencil nota- have little appreciation of the dangers and opportunities that software offers.
tion and CASE tools. We have argued that measurement, discipline, and an
overriding focus on quality will result in that meets the customer’s The pervasiveness of software leads us to a simple conclusion: Whenever a
needs, software that is reliable, software that is maintainable, software that is technology has broad impact-impact that can save lives or endanger them
better. Yet, we have never promised that software engineering is a panacea. build businesses or destroy them, inform government leaders or mislead them:
As we move toward the dawn of a new century, software and systems tech- it must be “handled with care.”
nologies remain a challenge for every software professional and every company
that builds computer-based systems. Max Hopper (HOP901 suggests the cur-
rent state of he states:
30.2 THE SCOPE OF CHANGE
Because changes in information technology are becoming so rapid and unfor-
giving, and the consequences of falling behind are so irreversible, companies
Change in the technologies that have an impact on computing seems to take
will either master the technology or die. . Think of it as a technology tread-
on a progression that can be called the 5-5-5 rule.’ A fundamentally new con-
mill. Companies will have to run harder and harder just to stay in place.
cept seems to move from initial idea to a mass market product in about 15
During the first 5 years a new idea is formulated and evolves into a pro-
Changes in software engineering technology are indeed “rapid and unforgiv- totype that is used to demonstrate basic concepts. The experimental prototype
ing,” but at the same time progress is often quite slow. By the time a decision is refined by scientists and engineers over the next 5 years, and the first prod-
is made to adopt a new method (or a new tool), conduct the training necessary
to understand its application, and introduce the technology into the software
development culture, something new (and even come along, and the
process anew.
‘The ideas for this discussion were first suggested in a presentation by Michael
In this chapter, we examine the road ahead. Our intent is not to explore Homer of the Digital Equipment Corporation.
every area of research that holds promise. Nor is it to gaze into a “crystal ball” ‘We of course, that the idea is a good one and that sufficient are available
and prognosticate about the future. Bather, we will explore the scope of change to nurture it.
and how change itself will affect the software process in the years ahead.
826
PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER 30: THE ROAD AHEAD 829
(reflecting the new idea) are introduced during this time. The final 5 years is being used to create a new approach to software-artificial neural net-
are spent introducing the product (and its descendants) to the marketplace. By works may lead to machine learning and the solution of “fuzzy”
the end of 15 years a new idea with technological merit can grow to en- problems that have heretofore been impossible to solve using conventional com-
compass a multibillion-dollar market (Figure Although the 5-5-5 rule is puter-based systems.
only an approximation, the 15 year time-span from initial idea to major mar- The influence of the soft sciences may help mold the direction of
ket seems to be a reasonable scale with which we can measure the evolution- research in the hard sciences. For the design of “future comput-
ary change in the computer business. ers” may be guided more by an understanding of brain physiology than by an
The changes in computing over the past four decades have been driven by understanding of conventional microelectronics.
advances in the sciences”-physics, chemistry, materials science, and en- The changes that will affect software engineering over the next decade will
gineering. The 5-5-5 rule seems to work reasonably well when new technolo- be influenced from four simultaneous directions: the people who do the
gies are derived from a basis in the hard sciences. However, during the next work; the process that they apply; the nature of information; and the
few decades, revolutionary advances in computing may well be driven by “soft underlying computing technology. In the sections that follow, each of these com-
sciences”-human psychology, neurophysiology, sociology, philosophy, and oth- ponents-people, process, information, and technology-is examined in more
ers. The gestation period for technologies derived from these disciplines is very detail.
difficult to predict.
For example, the study of human intelligence has been conducted for
, turies and has resulted in only fragmentary understanding of the psychology 30.3 PEOPLE AND HOW THEY SYSTEMS
of thought and the neurophysiology of the brain. However, significant progress
has been made over the’ past 30 years. Information derived from the soft A dilemma faces every company that must build modem computer-based sys-
tems. The software required for high-technology systems becomes more and
more complex, and the size of resultant programs increases proportionally.
gestation period for new computing hardware and has been There was time when a program that required 100.000 lines of code was con-
on Figure 30.1. The of new chip. until
than 4 sidered to be a large application. Today, the average program for a personal
computer application (e.g., word processors, spreadsheets, graphics programs)
is often many times that size. Programs built for use in industrial control, com-
Year in which a new technology can be puter-aided design, information systems, electronic instrumentation, factory
expected to reach the product stage: automation, and nearly every other “industry capable” application often exceed
lines of
1997 2002 The rapid growth in the size of the “average” program would present us
with few problems if it wasn’t for one fact: As program size increases,
the number of people who must work on the program also increases. Experience
that as the number of people on a software project team increases,
the productivity of the group may suffer. One way around this problem
is to create a number of software engineering teams (Chapter thereby com-
partmentalizing people into individual working groups. However, as the num-
ber of software engineering teams grows, communication between them be-
comes as difficult and time-consuming as communication between individuals.
Worse, communication (between individuals or teams) tends to be
that is, too much time is spent transferring too little information content, and
all too often, information “falls into the cracks.”
If the software engineering community is to deal effectively with the com-
munication dilemma, the road ahead for software engineers must include rad-
ical changes in how individuals and teams communicate with one another.
Electronic mail, bulletin boards, and centralized video-conferencing are now
concept p r o t o t y p e product “With the advent of object-oriented technologies and increased o f program components,
it is likely the number of lines of code must he built “from scratch” will decrease
FIGURE 30.1. overall of
The IO will
CHAPTER 30 THE ROAD AHEAD
830 PART FIVE ADVANCED TOPICS IN SOFTWARE ENGINEERING 831
“Yes, but only those with reference to changes.” A list of messages appears
commonplace as mechanisms for connecting a large number of people to an in-
formation network. The importance of these tools in the context of software en- on your screen. You on one item from the list and say “open.” In less than a
second, a video camera built into the workstation has tracked your move-
gineering work cannot be overemphasized. With an effective electronic mail or
ment at the time you said “open” and the system has calculated which item you
bulletin board system, the problem encountered by a software engineer in New
were looking at. You begin to read for a few momenta and then atop.
York City may be solved with the help of a colleague in Tokyo. In a very real
‘Please find all modules in the Factory Automation System that have been
sense, bulletin boards and Web sites become knowledge repositories that allow
changed in the last month. Store the names of the modules, the sources of the
the collective wisdom of a large group of to be brought to bear on
changes, and the date, and generate an action item for me to review them.
a technical problem or management issue.
“What version of the system would you like to use?” asks the agent as a
Video personalizes the communication. At its best, it enables colleagues at
scrolling window appears.
different locations (or on different continents) to “meet” on a regular basis. But
“All,” you reply.
video also benefit. It can be used as a repository for knowl-
“O.K.” says the agent.
edge about the software and to train newcomers on a project.
going through your mail the agent will have an “apprentice”
AH hardware and of the
perform the task you requested. That is, the agent “spawns” a task to perform
workplace will change. The following scenario, adapted from Pressman and
configuration management functions. Within seconds, the agent returns to do
provides one vision of a software engineer’s work environment
your bidding. Simultaneously, the apprentice is searching the CASE repos-
during the first decade of the twenty-first century: itory looking for module names.
“Good morning,” you say as you enter the office. “Can I have a word processor?” you ask the agent. A word-processing pro-
gram, not unlike the best that you see today, appears on the screen. You begin
Your workstation screen brightens, a window appears on the screen, an an-
drogynous face appears, and a very human voice says, “Good morning. You have dictating a letter (the keyboard or a handwriting tablet can also be wed). The
text appears on the screen as you speak each word. While you are dictating,
six voice mail messages, two facsimile transmissions and a list of daily action
you think of something for the agent to do. Using a pointing device, you click
items, Five development tasks are listed.” The face voice belong to your
on the agent’s window.
“agent,” an interface program that performs a variety of sophisticated clerical
duties. It has been customized to anticipate your needs, recognizes your voice, “I need a source listing for module Insert it at the
and can do many things at once--like answer your phone around the clock, look marker I’ll note in the text of the document I was working on. Also, call Emily
up information, communicate directly with you, and perform other data pro- Harrison in system engineering and tell her that I’ll be transmitting the docu-
cessing functions, Communication with the agent can be verbal or written, but ment later today.”
most people prefer to speak to their agents. “O.K.” responds the agent. Apprentices are spawned to generate the table
and make the call while you return to your dictation.
“Show me the action items and development tasks,” you say.
Immediately the list of action items appears on the display and the agent
begins to read the list aloud, highlighting each item as it is read. The environment implied by the above “conversation” will change the work
“Silence please, and hold the list,” you interrupt. “While you’re holding, patterns of a software engineer. Instead of a workstation used as a tool.
check any of the voice mail or fax transmissions for key words.” ware and software become an assistant, performing menial tasks, coordinating
You have just asked to perform an analysis of each incoming human-to-human communication, and in cases, applying domain-specific
message to determine whether it contains any of a set of key wardn (those could to enhance the engineer’s ability.
be people’s names, places, phone numbers or topics that you deem especially The acquisition of knowledge is changing in profound ways. On the Internet
important). As you scan the list of action items on the screen, you see two ap- a software engineer can subscribe to newsgroups that focus on technology
pointments, a few telephone calls to be made, and an anniversary present to be eas of immediate concern. A question posted within a newsgroup precipitates
purchased. answers from other interested parties around the globe. The World Wide Web
By the time you have scanned the list of action items agent’s face has provides a software engineer with the world’s largest library of research papers
reappeared on the screen, and reports, tutorials, commentary, and references in software
It’s early and you’re not tuned into the work day as yet. Embarrassed (but
why should you be, you’re communicating with a machine!), you ask, What did
I ask you to do?”
‘You asked me to check any of the voice mail or fax transmissions for key
words. Would you like a list?
“Further Readings Other Information Sources” throughout this book for starting
832 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER THE ROAD AHEAD 833
If past history is any indication, it is fair to say that people themselves will for incremental work products, risk analysis, planning and then plan revision,
not change. However, how they communicate, the environment in which they and customer feedback.
work, how they acquire knowledge, the methods they use, the discipline that But what activities must populate the evolutionary process? Over the past
they apply-and therefore, the overall culture for software development-will decade, the Capability Maturity Model developed by the Software
change in significant and even profound ways. Some of the changes that will Engineering Institute has had a substantial impact on efforts to im-
affect the people who do software engineering work are noted in Figure 30.2. prove software engineering practices. The CMM has generated much debate
(e.g., and yet, it provides a good indicator of the attributes
that must exist when solid software engineering is practiced.
30.4 THE “NEW” SOFTWARE PROCESS The use of object technologies (Part Four of this book) is a natural out-
growth of the trend toward evolutionary process models. Component-based
assembly (if it can be achieved widely) will have a profound impact on soft-
It is reasonable to characterize the first two decades of software engineering ware development productivity and product quality. The derivation of
practice as the era of “linear thinking.” Fostered by the classic life cycle model, reusable program components is a natural consequence of the object-oriented
software engineering was approached as a linear activity in which a series of paradigm.
sequential steps could be applied in an effort to solve complex problems. Yet, Component reuse provides immediate ‘and compelling benefits (Chapter
linear approaches to software development run counter to the way in which 26). When reuse is coupled with CASE tools for application prototyping, pro-
most systems are actually built. In reality, complex systems evolve iteratively, gram increments can be built far more rapidly than through the use of con-
even incrementally. It is for this reason that a large segment of the software ventional approaches. Prototyping draws the customer into the process.
engineering community is moving toward evolutionary models for software de- Therefore, it is likely that customers and users will become much more in-
velopment. volved in the development of software. This, in turn, may lead to higher
Evolutionary process models recognize that uncertainty dominates most user satisfaction and better software quality overall.
projects; that time lines are often impossibly short; and that iteration provides
the ability to deliver an incremental solution, even when a complete product is
not possible within the time allotted. Evolutionary models emphasize the need
30.5 NEW MODES FOR REPRESENTING INFORMATION
Over the past two decades, a subtle transition has occurred in the terminol-
ogy that is used to describe software development work performed for the busi-
ness community. Twenty years ago, the term “data processing” was the opera-
tive phrase for describing the use of computers in a business context. Today,
Internet
data processing has given way to another phrase-“information
that implies the same thing but presents a subtle shift in focus. The empha-
CASE tools and sis is not merely to process large quantities of data, but rather to extract
reusable components repositories meaningful information from this data. Obviously, this was always the intent,
formal methods multitasking but the shift in terminology reflects a far more important shift in management
and workstations PCs philosophy.
engineering When software applications are discussed today, the “data” and “in-
domain specific intelligent agents formation” occur repeatedly We encounter the word “knowledge” in some arti-
support for software
engineering multimedia ficial intelligence applications, but its use is relatively rare. Virtually no one
environments discusses wisdom in the context of computer software applications.
pattern recognition
Data is raw collection of facts that must be processed to be
virtual reality
semantic information meaningful. Information is derived by associating facts within a given context.
processing Knowledge associates information obtained in one context with other informa-
tion obtained in a different context. Finally, wisdom occurs when generalized
principles are derived from disparate knowledge. Each of these four views of
“information” is represented schematically in Figure 30.3.
FIGURE 30.2. To date, the vast majority of all software has been built to process data or
concept I prototype product
Influences on soft- information. Software engineers of the twenty-first century will be equally con-
ware engineers and cerned with systems that process knowledge. Knowledge is two-dimensional.
their work 5 10 Information collected on a variety of related and unrelated topics is connected
a34 PAR, ADVANCED TOPICS SOFTWARE ENGINEERING CHAPTER 30. THE ROAD AHEAD
835
30.6 TECHNOLOGY AS A DRIVER
information: The people who build and use software, the software engineering process that
associativity within is applied, and the information that is produced are all affected by advances in
no associativity
hardware and software technology. Historically, hardware has served as the
one context
technology driver in computing. A new hardware technology provides potential.
Software builders then react to customer demands in an attempt to tap the po-
tential. Figure 30.4 applies the 5-5-5 rule in an attempt to place various hard-
ware technologies in the overall evolutionary cycle. Placing a particular tech-
nology on the 5-5-5 curve can be difficult. For example, mobile computing
has currently evolved to the product stage, but it is not yet a ma-
ture market. Hence, it has been placed in the “prototype” stage of technology
wisdom: maturity.
knowledge:
creation of generalized The road ahead for hardware is likely to along two par-
associativity within
principles based on allel paths. Along path, hardware will continue to evolve at a
multiple contexts
FIGURE 30.3. With by traditional
An “information” existing knowledge on will continue grow.
from
the in technology may occur along another
path. The development of nontraditional hardware architectures (e.g., mas-
sively parallel machines, optical processors, neural network machines) may
in
changes in our approach to the software engineering. Since these nontradi-
to form a body of fact that we call knowledge. The key is our ability to associ-
tional approaches remain in the first segment of the 15 year cycle, it is
ate information from a variety of different sources that may not have any ob-
vious connection to one another and combine it in a way that provides us with
some distinct benefit.
To illustrate the progression from data to knowledge, consider census data
indicating that the number of births in 1991 in the United States was 4.1 mil-
lion. This number represents a data value. Relating this piece of data with
births for the preceding forty years we can derive a useful piece of informa-
tion-aging “baby of the 1950s were making a last gasp effort to have
children prior the end of their childbearing years. This piece of information
high-density optical/
can then be connected to other seemingly unrelated pieces of information-for magnetic storage
example, the current number of elementary school teachers who will retire dur-
ing the next decade; the number of college students graduating with degrees in
primary and secondary education; or the pressure on politicians to hold down
taxes and therefore limit pay increases for teachers.
Each of these pieces of information can be combined to formulate a repre-
optical processors
sentation of knowledge-there will be significant pressure on the education
system in the United States in the late and this pressure will continue molecular computers
for over a decade. Using this knowledge, a business opportunity may emerge.
There may be significant opportunities to develop new modes of learning that devices
are more effective and less costly than current approaches.
We have been processing data for almost forty years and extracting infor-
mation for over two decades. One of the most significant challenges facing the
software engineering community is to build systems that take the next step
along the spectrum-systems that extract knowledge from data and informa- FIGURE 30.4.
tion in a way that is practical and beneficial. Changes in hard-
ware
836 PART FIVE: ADVANCED TOPICS IN SOFTWARE ENGINEERING CHAPTER THE ROAD AHEAD 837
cult to determine which will survive to maturity and even more difficult to pre- never lose its importance and that effective analysis and design and compe-
dict how the world of software will change to accommodate them. tent testing will always have a place in the development of computer-based
We have already noted that software technology tends to react to changes systems.
in hardware technology. Applying the 5-5-5 rule to software technology (Figure
we find that the software products of today will be joined and possibly
displaced by software technologies in the first and second stages of maturity. 3 0 . 7 A CONCLUDING COMMENT
There is little doubt that the technologies shown in the prototype stage of
Figure 30.5 will become extremely important as the twenty-first century dawns.
It is interesting, and not altogether coincidental, that the fourth edition of this
In fact, reuse- and component-based software engineering may offer the best
book completes a 5-5-5 rule. The preliminary “concept” (the first edition) was
opportunity for order of magnitude improvements in system quality and time
published in 1982; a more refined “prototype” (the second edition) was released
to market.
in 1987; the not-so-final “product” (the third edition) was introduced in 1992.
The road ahead for software engineering will be driven by software tech-
Now, the fourth edition completes the last 5 year cycle. Over the past 15 years,
nologies. As software moves more forcefully into the realm of problems this book has changed dramatically-in scope, in size, and in content. Like soft-
(AI, artificial neural networks, expert systems), it is likely that an evolution-
ware engineering, it has grown and (hopefully) matured over the years.
ary approach to software development will dominate all other paradigms. As
An engineering approach to the development of computer software is a phi-
object-oriented approaches move to dominate the software community, evolu- losophy whose time has come. Although debate continues on the right para-
tionary paradigms for software engineering will be modified to accommodate
digm, the degree of automation, and the most effective methods, the underly-
component reuse. “Foundries” that build “software may become a major ing principles of software engineering are now accepted throughout the industry
new business. In fact, as time passes, the software business may be-
Why, then, are we only recently seeing their broad adoption?
gin to look very much like the hardware business of today. There may be ven-
The answer, I think, lies in the difficulty of technology transition and the
dors that build discrete devices (reusable software components), other vendors
cultural change that accompanies it. Even though most of us appreciate the
that build system components (e.g., a set of for human-computer interac-
tion), and system provide the end
of past practice.
Software engineering will change-of that we can be certain. But re-
To ease the transition we need many things-a more mature software process,
gardless of how radical the will
effective powerful acceptance by practitioners and support from
managers, and no small dose of education and “advertising.” Software engineer-
ing has not had the benefit of massive advertising, but as time passes the con-
cept In a way, this book is an “advertisement” for the technology,
You may not agree with every approach described in this book. Some of the
techniques and opinions are controversial; others must be tuned to work well
in different software development onvironmentn. It is my hope, how-
ever, that Software A Practitioner’s Approach has delineated the
problems we face, demonstrated the strength of software engineering concepts,
code generation
and provided a framework of methods and tools.
object-oriented As we begin our march into the new millennium, so&ware has become the
technologies
distributed/parallel most important product and the most important industry on the world stage.
systems graphical Its impact and importance have come a long, long way. And yet, a new genera-
programming
reuse/component tion of software developers must meet many of the same challenges that faced
based development earlier generations. Let us hope that the people who meet the
programming process-based ware the wisdom to develop systems that improve the hu-
environments man condition.
natural language
understanding formal
L
REFERENCES
Bollinger, T., and C., “A Critical Look at Capability
concept prototype
FIGURE 30.5. Software, July 1991, pp. 25-41.
Changes in software [GIL961 Gilb, T., “What is Six?” January 1996, pp. 97-98,
technology 103.
CHAPTER 30. THE ROAD AHEAD
PART FIVE. ADVANCED TOPICS IN SOFTWARE ENGINEERING 839
Hopper, M.D., “Rattling New Ways to Compete on Information,” Within the more narrow context of computing and software,
Harvard Business Review, May/June 1990. (Apprentices of Wonder, Bantam Books, 1989) describes the potential impact of
M., “Future Directions in CASE,” Lo du artificial hook that suggests radical changes in what we
Centre International de Communication Sophia will mean when the word “software” is used. Stoll Cuckoo’s Egg, Doubleday,
Antipolis, France, May 29, 1990. 1989) presents a fascinating look into the world of computer networks, hack-
M. et al., Capability Maturity Model for Software, Software ers, and computer security-topics that are of significant importance as we be-
Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1993. come an integrated “electronic Rise and Resurrection
Pressman, R.S., and S.R. Shock, House, 1991. of the American Programmer, Prentice-Hall, 1996) predicts the continuing dom-
Wasserman, Neural Computing: Theory and Practice, Van Nostrand inance of the software industry in the United States.
Reinhold. 1989. For historical interest, Alvin Bantam Publishers, 1990)
completed a trilogy that began with Future Shock by discussing the disinte-
gration of well-established power structures that is occurring throughout the
PROBLEMS AND POINTS TO PONDER world-a shift in power that he attributes directly to software and the infor-
mation that it produces. Many of his predictions are now reality
30.1. Get a copy of this week’s major business and news magazines (e.g., Newsweek, The publishes detailed reports that project future trends in
Time, Business Week). List every article or news item that can be used to il- many areas of computing technologies. Some of these can be obtained at:
the importance of
30.2. Select three “fundamentally new ideas” that have lead to major products.
Draw a and determine whether the 5-5-5 rule is too conservative, too
optimistic, or right on target. Byte is always a good source for information on current and fu-
30.3. Add additional features to the software engineer’s environment described in ture trends in software and computing in general. Its site can be visited at:
Section 39.3. Draw an annotated sketch that illustrates a software engineer’s
office in the year 2005.
30.4. Review the discussion of the evolutionary process models in Chapter 2. Do
some research and collect’ recent papers on the subject. Summarize the Somewhat more radical views can be obtained by visiting and
strengths and weakness of evolutionary paradigms based on experiences out- at:
lined in the papers.
30.5. Attempt to develop an example that begins with the collection of raw data
and leads to acquisition of information, then knowledge, and finally, wisdom.
30.6. Select any one of the hardware technologies represented at the concept level
in Figure 30.4 and write a two or three page paper that presents an overview An in-depth treatment of technology trends for the twenty-first century can
of the technology. Present the paper to your class. be found at:
30.7. Select any one of the software technologies represented at the concept level
in Figure 30.5 and write a two or three page paper that presents an overview
of the technology. Present the paper to your class.
FURTHER READINGS AND OTHER INFORMATION SOURCES The Institute for Learning Sciences has assembled an intriguing look at
the future impact of computing and software on education. It can be found at:
Books that discuss the road ahead for software and computing span a vast ar-
ray of technical, scientific, economic, political and social issues. Negroponte’s
best-selling book (Being Digital, Alfred A. Inc., 1995) provides a view of
computing and its overall impact in the twenty-first century. Naisbitt and Other discussions of current and future trends in computing can be
Aburdene William Morrow Co., 1990) provide an intrigu- using the standard search engines on the World Wide Web.
ing picture of changes that are already well underway. Rich and Waters
Programmer’s Apprentice, Addison-Wesley, present one view of “what to
expect in the future of software development.” Bowyer (Ethics and Computing,
IEEE Computer Society Press, 1995) considers the need for software “profes-
sionals to act responsible manner.”
INDEX 841
model, 760 relationships between, 598
principles of, 759 selection characteristics, 567
Business processes, 243, 757 taxonomy of, 594
Business system design 239 ng,
Classic life cycle model, 29
Capability maturity model 26, for reuse, 744
833 Cleanr oom process model, 709
Card and Glass metrics, 533 Cl software engineering, 45.
Cardinality, 304, 306, 604 707
for sets, 690 Internet sources, 729
Abstraction, 347 Bach, J., 451 CASE, 805 strategy for, 708
Acceptance tests, 506 Backfiring, 91 building blocks, 806 tasks. 708
Access control, 220 Backtracking, 512 integration options, 807, 813 testing, 720
Ackerman, A., 492 Baker, 64 Internet sources, 824 Clemm, G., 218
Action items, 193 Bang metric, 529 CASE repository, 816 Client, 785
Action paths, 376 computation of, 530 features and content, 818 Client/server systems, 7 8 4
Activity-chart, 438 Baselines, 210 role of, 817 analysis . g, 791
Actors, 592 V., 91 CASE tools, see also Tools components of, 8 6
Adaptation criteria, 161 Basis path, test cases, 460 taxonomy of, 808 d e s i g n r e p o s i t o r y 794
Adaptive maintenance, 25 Basis set, 458 Cause elimination,,512 design, 792
Albrecht, A., 85, 90 Bathtub curve, 10 Cavano, 92, 522 Internet sources, 804
Allocation, 251 Behavioral modeling, 316 Certification, 710, 721 00 design, 792
Alpha testing, 506 Behavioral models, 281 Champy, J., 4, 241 software engineering, 791
Analysis, SEC also Requirement analysis Behavioral testing, 470 Change, 18 structure of, 785
conventional vs. 00 approaches, 582 B., 449 Change control, types of, 222 testing, 798
296 255 Change control authority 220 812
methods, 334 Bennatan, E., 109 Change control process, 221 Cluster testing, 649
modeling, 281 E., 572, 589, 650 Change report, 220 Clusters, 501 . .
real-time software, 431 Beta testing, 506 Change request, 220 Coad and method, 584,619
Analysis model, elements of, 300 Bieman, J., 536 Changes, 810 Coad, P., 567, 626
Analysis modeling, 298 Big bang approach, 499 origins of, 210 COCOMO model, 121
Internet sources, 339 Binder, R., 644 Chaos model, 29 example of, 123
Analysis principles, 279 Black box testing, 454, 470 N., 409 structure of, 122
Analysis tools, 810 Boar, B., 285 Characterization functions, 737 Code generation, 31
Andriole, S., 286 Boehm, B., 38, 121, 140,488 Charette, R., 132 Code restructuring, 766, 773
Antibugging, 497 572, Check-in, 220 Cohesion, 357, 358, 665, 670
Application architecture, 237 method, 583,619 Check-out, 220 metrics, 536
Architectural description language, Boolean operators, 456 P., 305 Collaborators, 597
352 Bottom-up testing, 500 Chidamber, S., 667 Common process framework 26,
Architectural design, 373 Boundary conditions, 495 Chief programmer team, 64 69,572
optimization of, 391 Boundary value analysis 475 Chikofsky, E., 763 Communication,
process, 375 , Box structure specification, 710 customer, 104
Architecture, 351 black-box. 712 CK metrics suite, 667 techniques, 272
Architecture context diagram clear-box, 714 Class, description of, 556 Competitiveness, 9
259 state-box, 713 Class library, 43 Complexity adjustment factor, 86, 114
Architecture flow diagram Branch and relational operator Class size, 671 Complexity metrics, 538
261 testing, 466 Class-collaboration graph, 658 Component assembly model, 42, 733
Architecture template, 259 Brooks, F., 33, 102 Class-responsibility-collaborator (CRC) benefits of, 43
Arthur, A., 522 Bubble chart, 309 modeling, 594 Component reuse, 833
Artifacts, reusable, 732 Builds, 501 index card, Component-based development, 742
Associative data object, 307 area analysis 237, review of, 598 Components, Software
Atomic modules, 501 Business functions, 243 testing of. 647 Components,
Attributes, 302. 557 Business modcling. 35 Classes, 42, 594 classifying and retrieving, 743
specification of, 569 Business process reengineering characteristics, 595 786, 788, 789
Availability, 198 derivation of, 565 full-experience, 109
INDEX
INDEX
Components, (Continued) communication, 44, 71
24
off-the-shelf, 109 voice table, 278 P., 132
Cyclomatic complexity, 458, 538, 665 Definition-use chain, 467 Dyer, M., 711
partial experience, 110
reusable, 106. 740 computation of, 459 Degree of rigor, Dynamic analysis 812
64 299,
Composite information, 301 Dynamic models, 351
Computer-based system, definition of, Data abstraction, 347, 556 Democratic teams, 62
Data architecture, 237 Design, 31
232 Edgemon, J., 60
Data bases, real time, 428 architectural, 373 Edges, 456
Computer-aided software engineering,
also CASE, 24, 47, 367
Concurrency control, 428 Data conditions, 316 346 heuristics for, 361
Concurrent development model, 43 Data design, 371 data, 371 Efficiency, 519
Condition testing, 465 Data dictionary, 300 definition 341 Effort adjustment factor
content description, 333 evolution of, 344 122
Configuration audit, 223
Configuration objects, 214 definition of, 331 interfaces, 393 Effort distribution, 159
aggregate, 215 Data flow diagram 301.309-310 Internet sources, 369 Ejiogu, L., 525
relationships between, 215 creating, 323 object-oriented, 617 Encapsulation, 561,666
Configuration review, 506 Data flow graph, 309 principles, 345 metrics for, 673
Data flow testing, 467 procedural, 406
Configuration status accounting, 224 Endogenous inputs, 235
Configuration status reporting, 224 Data invariant, 685, 696 real time systems, 423, 442 Engineering change order
Configuration testing, 800 example of, 687 translation from analysis, 342 220
Consistency, of 00 models, 646 Data management component, 627 test cases, 453 Enhancement. 25
Data modeling, 35,301 typos of, 342 Enterprise modeling, 242
Constantine, L., 63
Constraints, 104 business-level, 244 Design methods, 371 Entity-relationship diagram
Constructive specification, 690 Data object, 301, 303, 332 Internet sources, 421
Context diagram, example of, 324 Data object description, 300 object-oriented, 619 buildine. 321
Context free questions, 105,273 Data object type hierarchies, 307 Design notation, tabular, 409 Entry point multiplier,
Data restructuring, 767, 774 Design patterns, 636 Environment
Context model, 309 . 807
Data source, 311 description of, 637 Equivalence class,
Context switching,
Data strong, 530 use of, 638 Equivalence partitioning 474
Contingency planning, 146
Control flow, 314 Data structure, 364 Design postprocessing, 390 Error handling paths,
Control flow model, creating, 325 Data structured systems development Design process, 343 Error index. 196
334 Design refinement, 714 Error messages, design of, 399
Control hierarchy, 352
Database design, 793 Design specification, 363 Errors, 80, 95, 188
Control item, 332
Control specification 301, Database management tools, 810 outline of, 364 Essential view, 284
Davis, A., 43, 279, 345, 450, 531 Design structure quality Estimation, 111
316,328
Control structure diagram 414 Davis, M., 48 534 expected value, 113, 114
Control structure testing, 464 do 116
Controllability, 462 Deadlines, 154 116
reasons for missing, 154 Design verification, observations on, 102
Controlled centralized teams, 62
Controlled decentralized teams, 62 advantages of, 719 problem-based, 113
Debugging, 509 example of, 717 process based, 118
Conveyor line sorting system
approaches, 511 Deutsch, M., 448
106,250 Estimation models, 120
CORBA, 743, 790 process, 106 empirical, 111
psychological considerations, 24
Corrective maintenance, 26 121
Decision tree analysis, 126 H., 537
Correctness, 93,519 LCC-oriented, 116, 121
Decomposability, 452 Dijkstra, E., 406 structure of, 120
of 00 models, 646
Correctness verification, 710 Decomposition, 67, 106, 111 Document restructuring, 766 Estimation table, process based,
techniques, 112 Documentation tools, 809
Coupling, 119
Coupling metrics, 537 Defect amplification model, 189 Domain analysis, 586 Event flow diagram, 609
Defect removal 92 activities, 588 Event flow, 318
Cox, B., 632
Critical modules, 503 computation of, 94 Domain analysis process, 587, 736 Event trace, 608
Critical path, 168, 170 for phases, 95 Domain characteristics, 737 Everett, 424
Critical path method, 170 Defects, 80, 95, 195 Domain engineering, 589, 735 Evolutionary models, 37
causes of, 81 Domain testing, 466
Crosby, I?, 179 Exhaustive testing, 454
Customer, 34, 136,272 cost impact, 188 Drivers, 498 Exogenous inputs, 235
types of, 502 External entity, 260, 310
INDEX INDEX
Facilitated aoulication Freedman, D., 187 I n d i c a t o r ’ Jacobson method, 584,620
techniques 106,274 Freeman, 371, 728 definition of, 77 Jacobson, I., 562, 584
Factoring, 381 Function 85. types of, 78 Jones, C., 732
Failure costs, 183 for and’ against, 89 Informal methods, deficiencies of, 682
Failure curve, computation of, 86, 117 Information, where-used/how-used, 332 Kaisen, 184
for hardware, 11 example, 117 Information content, 14,280 Kellner, M., 43
for software, 11 extended versions, 87 Information domain, 279 C., 667
Failure intensity, 493 88 Information engineering, 31, 231, 241 Key class, 574, 674
Failure model, 492 computation of, 89 critical success factors 242 Key indicators, 28
Fan-in, 352 Function strong, 530 Internet sources, 268 Key practices, 28
Fan-out, 352 Functional independence, 357 objectives, goals, 241 Key process areas 23
FAST team, 276 Functional modeling, 281, 309 overview, 237 characteristics of, 27
Fat client, 787 Functional specification, 711 Information engineering hierarchy, 238 Kidd, 573, 670
Fat s e r v e r , 787 Functionality, 91, 521 Information engineering tools, 808 Kraul, R., 65
Fault tree analysis, 199 Functions. 104 Information flow. 280 Kurki-Suono, R., 442
Faults, 188 Fundamental system model, 309,378 continuity, 323
F e a s i b i l i t y s t u d y , 253 FURPS, modeling. 247 Labor-rate, burdened, 120
outline of, 255 Information hiding, 356, 666 Language level, 540
Feature points, 88 Gaffney, J., 90 Information representation, 833 Languages, real time, 429
Feigenbaum, E., Gamma, E., 614 Information spectrum, 834 Layout appropriateness 539
Fenton, N., 512, 522 Gane, T., 299 Information strategy planning Levels of abstraction, 347
Firesmith, D., 587 Gantt chart, I72 N., 198, 200
diagram, 81 Garlan, D., 351 Information structure, 280 Librarian. 64
Flexibility, 519 D., 105, 273 Inheritance, 561,666 Linear sequential model, 29
Flow boundaries, 381, 388 Generalization-specialization metrics for, 673 activities. 31
Flow graph notation, 456 structure, 599 multiple, 563 32
Flowchart, 407 Gilb, 93, 134, 494 Inheritance tree, 669 Lines of code 113
Formal design, 710 Glass, R., 423 Inspections, see also Formal Technical Link weight, 463
Formal methods, 681 Glass-box testing, 455 Reviews, 191 Links, 456
basic concepts, 685 Grady, R., 79 Integrated CASE environment (I-CASE), T., 64
concerns about, 46 Graham, R., 262 807,813 Localization, 665
Internet sources, 706 Grammatical parse, 325, 602 Integration architecture, 814-815 Logic operators, 694
mathematical preliminaries, 690 Graph matrices, 463 Integration framework, 807, 814 Loop testing, 469
ten commandments of, 701 Integration testing, 491, 498 of, 469
Formal methods model, 46 incremental, 499 M., 573,670
Formal specification, see also Formal Hall, A., 681
Halstead’s metrics, 540 non incremental, 499
methods, 287,696 00 software, 649 Machine-level language, 14
example of, 696 Hammer, J., 4
Hammer, M., 756, 759 top-down, 499 Mailboxes. 430
Formal specification language, 698 94. 519 Maintainability, 93, 519, 521
Formal technical review 19, 138, Hare, D., 438
language Maintenance, 6, 25, 32, 209, 762
Hatley, D., 259, 299,315
Hazard analysis, 148, 198 742. 790 types of, 25
guidelines, 193 Interface design, 393 Make-buy decision, 125
meeting format, 191 Henry-Kafura metric, 533
models. 395 Manufacturing cell, 233
participants, 192 R., 136, 827
I?, 736 Martin, J., 128, 246
sign-off, 192
Hopper, M., 826 McCabe, T.,
40-20-40 rule, 159, 827 Interrupt handling; 426 McCall, J.. 92. 519. 522
interface 395
Forward engineering, 767, 774 Interrupt latency, 425 McCall’s quality
Humphrey, 43, 79
C/S architectures, 775, 426 P.. 4. 9
00 architectures, 777 Hutchinson, 736
analysis, 764
user interfaces, 778 9000-3 guidelines, 202 Mean-time-between-failures
Fourth generation techniques, 6, 14, 46, I-CASE, 807 9001 standard, 202 108,198
287 Implementation view, 284 requirements, 203 Mean-time-to-change 93
Frame technology, 741 Incremental model, 37 Mean-time-to-repair 198
Framework activities, 26, 38, 59, 69 Independent paths, Jackson System Development, 335 Measure, definition of, 77
Framework models, 351 Independent test group 490 Jackson, M., 335, 352 direct, 83
INDEX
INDEX
Measure, definition of, (Continued) Myers, G., 449,495
indirect, 83 Myers, W., 112, 125 state representations, 606
Measurement, 76 Myths, 17 OOA methods overview, 583 software process
principles, 524 OOA model, 601 PERT. 170
Petri nets, 199
S., 312 Naisbitt, 4 components of, 590
Message passing, 559 Pirbhai, I., 259, 299,315
Nassi-Shneiderman charts, 408 dynamic components,
Messages, 558 Polymorphism, 564
Node, 456 graphical notations, 603
Portability, 520
Methods, 23,558 Nonprocedural language, 14 partitioning, 625
weighted, 668 static components, 590 Portability services, 807
Metrics, 76 Object 571 OOA process, 591 784, 796
analysis model, 526 pyramid, 615 Postcondition, 686
Object descriptions, 631
attributes, 525 OOD, Precondition, 686
Object design; 621, 631
baseline productivity, 114 implementation description, 632 generic components of, 623 Pressman, R., 136, 827
class-oriented, 667 Object life history, 591 Internet sources, 642 Preventive maintenance, 25
cohesion, 536 Object model, 564 layers of, 615 R., 736
complexity, 538 optimization, 633 methods overview, 619 tools, 810
computation, 96 Object technique 585, modeling components, 616 Problem decomposition, see
coupling, 537 621 program components, 634 Decomposition
data collection, 96 Object-oriented, Problem solving, 29
translation from OOA, 617
definition of, 77 concepts, 551, 553 vs. conventional approaches, 616 Problem space, 565
design model, 532 Operability, Procedural abstraction, 347
concepts, Internet sources, 580
evaluation, 96 definition of, Operating systems, real time, 428 Procedural design, 406
function-based, 527 estimating, 575 O p e r a t i o n a l p r o f i l e , 799 Procedural layering, 407
high level design, 533 Procedure, 355
paradigm, 552 Operations, 558, 671
interface design, 539 in formal methods, 686 Process, 22, 48, 78
programming 638
Internet sources, 101,548 project, 571 metrics for, 672 phases, 24, 68
maintenance, 543 Internet resources, 52
project metrics, 573 of, 569
object-oriented projects, 573. 673 structures and hierarchies, 599 Organizational paradigms, 63 Process activation table (PAT), 316, 328
private, 79 Object-oriented analysis, see also OOA, Orr, K., 335 Process algebra, 772
product, 664 Osborne, A., 4 decomposition,
projects, 82 Osborne, 763 example of, 71
Object-oriented design, see
public, 79 614 \ Ott, L., 536 flow diagram, 248
reuse, 749 Process layer, 23
664 Outsourcing, 9, 127
size-oriented, 84 characteristics of, 665 Overloading, 564 Process maturity, 26
software quality, 91 design model, 667 Overriding, 562 Process maturity levels, 27
source code, Process metrics, 78
Internet sources,
specification quality, 531 product, 664 Page-Jones, M., 57 models, 28, 160, 165, 351
technical, 612 Object-oriented models, testing, 646 Pareto principle, 195 component assembly, 42
testing, 542 Object-oriented testing, see Testing, D., 357 concurrent development, 43
tools, 809 evolutionary, 37, 832
object-oriented Partition testing, 657
Meyer, B., 617 Object pool, 219 Partitioning, 67, 282 formal methods, 45
Mid-level language, Object request broker (ORB), also horizontal, 283 incremental, 37
Middleware, 787, 789 CORBA, 743 structured, 353 linear sequential, 29
Milestones, 157 architectures, 789 vertical, 284 object oriented. 572
Mills, 64 42, 551 32
330 Object, 606 34
Modality, 305-306 reuse, 734
Object-behavior model, 605 People management capability matu-
Modular design, 357 Objects, 556 spiral, 38
rity model, 58
Modularity, 348 Observability, 451 People, 58, 106 Process modeling, 35, 247
criteria, 350, 618 OOA, effort, Process modeling tools, 809
Module interconnection language, subsystems models, 600 communication and coordination, 65 Process specification (PSPEC),
217 event trace, 608 future trends, 829 312,330
Modules, refinement of, 383 Internet sources, 613 the players 60 Process states, 43
model, Perfective 25 Process technology, 47
modeling dimensions, 583
Morphology metrics, 634 object models, 601 Performance, 104, 521 engineering, 231,256
J., 492 state transition, 607 real-time. 425 overview, 239
Product, 48
Performance testing,
Internet resources,
INDEX INDEX
Productivity metrics, factors influenc- Quality function deployment design for, 740 staff size and experience, 140
ing, 91 277,593 approach for, 731 technical, 134
Program design language 330, Quality metrics, 92 construction methods, 741 technology, 139
411.456 Quality of conformance, 181 economics of, 747 RMMM Plan, 143
,
example, 413 Quality of design, 181 environment, 746 outline of 149
Program graph, 456 Queuing semaphores, 430 impact on quality, 747 Ross, D., 299
Program length, 540 Internet sources, 754 Round-robin reviews, 191
Program level, 540 Raccoon, L.B.S., 29 management issues, 729 Royce, 30
Program structure, 352,385, 392 Rambaugh method, 585,621 metrics, 749
refinement of, 383 Rambaugh, J., 602 process model, 734 SADT, 335
Programming tools, 811 Random testing, 656 process, 732 412,
Project, Rapid application development roadblocks, 729 739 592, 597, 605, 608, 6 3 0 ,
‘635,453, 566,
complexity, 103 34 value of, 734
concepts, 57 problems with, 35 Reverse engineering, 766767 Sandwich testing, 503
control, 172 Reactive system, 263 abstraction level, 768 Sarson, C., 299
coordination, 65 Real-time software, 423 data, 770 Scenario scripts, 573, 654, 674
database, 211 analysis of, 430 directionality, 768 Schedule,
deadlines, also Deadlines, 154 attributes of, 425 process, 769 macroscopic, 156
effort, 159 characteristics, 424 user interfaces, 771 tracking, 172
entry point, 39 Internet sources, 446 Review issues list, 192 Scheduling,
Internet resources, 75 modeling principles, 442 Review summary report, 192 basic principles, 156
issues, 71 queuing models, 432 Reviews, see also Formal technical compartmentalization, 156
library, 211 scenarios, 438 views, 187, 190 interdependency, 156
management, 102 systems of, 435 record keeping, 192 Internet s o u r c e s , 178
management tools, 809 Recovery testing, 507 reporting, 192 object-oriented projects, 576
metrics, 82 Recursive parallel model, 572 Risk, 103, 132 work tasks, see also Tasks, 164
size, 103 Reengineering, 756,762 analysis tools, 809 699
tracking, 172 economics of, 778 assessment, 145 Scope, 58, 66
Project objectives, 58 Internet sources, 783 components, 141 bounding, 59
Project plan, 174 process model, 763, 765 drivers, Sears, A., 539
outline 175 Reengineering tools, 812 estimation, 141 Security, 94
Project planning, Regression testing, 501 identification, 134 Security testing, 508
Internet sources, 131 Relationships, 303,601 impact, 144 Selective testing, 496
objectives, 104 Reliability, 197, 519, 521 Risk item checklist, 135 Sequences, 694
tools, 809 measures of, 198 Risk management, Server, 785
Project table, example of, 173 Repository, see also CASE repository, 147 Services, 558
Proof of correctness, 715 43. 211 Internet sources, 152 Set o p e r a t o r s , 691
Prototyping, 32 Requirements, 277 Risk mitigation, 143, 146 Sets, 690
description of, 33 Requirements analysis, see also example of, 147 M., 351
evolutionary, 286 Analysis, 31, 278 Risk monitoring, 143, 146 Shooman, M., 487
problems with, 34 Requirements gathering, see also example of, 147 Shnkiderman, B., 394
methods and tools, 287 Customer communication, Risk probability, 143 Simplicity, 452
Prototyping environments, 287 710 Risk projection, 141 43
Prototyping tools, 811 Requirements tracing, 821 Risk referent Sizing, 112
Pseudocode, 411 tools, 809 Risk table 141 types of, 113
Putnam, L., 112, 125 Resources, 106 Risks, 133 Software,
environmental, 110 business impact, 136 application types, 15
Quality, human, 109 business, 134 costs, 10
cost of, 182 670 customer-related, 136 definition of, 10
definition of, 181, 185 Responsibilities, 595 development environment, 139 evolution of, 5
factors affecting, 92 guidelines, 596 generic, 134 historical view, 4
measurement of, 93 Restructuring, 773 impact assessment, 142 impact of, 4
metrics, 92 137 questions, 8
variation, 180 components, 287 product size, 135 7
control. 181 I
57 I
850 INDEX
INDEX 851
Software architecture, 351 Software quality assurance plan, 200 Structural complexity, 533 System software tools, 810
properties, 351 outline of, 201 Structural modeling, 738 System specification, 264, 271
Software characteristics, 10 Software reengineering, 25 Structural models, 351 outline of, 265
Software components, see also Software reengineering, see Structural uncertainty, 103 System testing, 491, 507
Components, Structure, pancaked, 362
Software configuration, 19 Software reliability, see Reliability Structure chart, C/S systems, 797 Tai, K., 465
Software configuration item see see also Repository, Structure points, 739 Task analysis and modeling, 396
also Configuration objects, 212 cost analysis, 748 Task management component, 626
Software configuration management Software requirements analysis, see Structured analysis, 298 Task network, 168
(SCM), 209 Requirements analysis extended notation, 313 example of, 169
activities, 210 Software requirements specification, history of, 299 Task regions, 38
Internet sources, 227 290,609 mechanics of, 320 Task set, 26, 59, 160
process, 214 outline of, 291 Structured constructs, 407 selection of, 163
standards, 224 Software requirements, see Structured 411 Task set selector 161
tools, 810 Requirements Structured programming, 406 computation of, 162
Software crisis, 16 Software reuse, Reuse Structured query language (SQL), 786, Task synchronization, 430
Software design, see Design Software reviews, see Formal technical 795 Tasks, 164
Software engineering. 500 of, 166
definition of, 22, 23 Software risks, Risks Team leaders, 60
future trends, 826 Software safety, 148, 198 Subclass, 671 characteristics of, 61
using mathematics, 684 Software science, 540 Subjects, 600 Technology, future trends 835
Software engineering environment Software scope, 104 Subsystem collaboration table, 630 Technology impact 242
110 Software sizing, see Sizing Subsystem communication, 626 Technology infrastructure, 237
Software Engineering Institute team, 61 Subsystems, 601 Technology trends, Internet sources,
26, 137,833 choosing, 62 classes, 574 839
Software engineering paradigms, see jell, 64 Support infrastructure, 250 Test case design, 453
also Process model, 68 organization, 62 Supportability, 521 object-oriented software, 650
Software equation, 124, 158 paradigms for, 63 Synchronization control, 220 Test specification, 503
maintenance, see also Software testing, also Testing, 448 System, Testability, 451,519
Maintenance, 93, 762 Solution space, 565 allocation, 250 Testing,
Software maturity index 543 Specialization index, 671 benefits of, 257 basis path, 455
Software metrics, see Metrics Specification, bounding of, 250 black box, 470
Software myths, see Myths constructive, 690 computer-based, 232 client/server, 479
plant, 8 principles, 288 costs of, 258 control structure, 464
Software process, see also Process, 138 representation of, 289 definition of, 232 criteria for completion, 492
future trends, 832 review of, 292 domains, 235 deep structure, 656
Software process improvement, 78 Spiral model, 38 elements, 235 documentation, 479
statistical, 80 benefits, 41 risk analysis, 254 fault-based, 651
Software process models, see Process disadvantages of, 41 technical analysis, 256 for systems, 798
models framework activities, 39 trade off criteria, 252 477
Software project estimation, see Stability, 452 views 235 metrics for, 542
Estimation State, definition of, 317 world view, 234 multiple classes, 658
Software project management, see in formal methods, 686 System analysis, 253 object-oriented, 644
Project management State transition diagram 301, System architecture, 259 organizational issues, 490
Software project plan, see also Project 316,328 System complexity, 533 partitioning, 657
Plan, 271 example of, 329 System design, 621, 624 real-time systems, 480
Software quality, see Quality Statecharts, 438 object-oriented, 624 scenario-based, 654
Software quality assurance 179, Static analysis tools, 811 System elements, 232 strategic issues, 493
185,489 Statistical SQA, 195 hierarchy of, 233 strategies for 00, 648
activities, 186 example of, 196 System engineering, 31,231, surface structure, 655
formal approaches, 194 Statistical test planning, 710 hierarchy, 234 thread-based, 649
history of, 186 Statistical use testing, 710, 720 Internet sources, 269 use-based, 649
Internet sources, 207 refinement, 348 System image, 395 white-box, 455
statistical, 195 c., 4 System model, 236 Testing methods,
810 L., 65 modeling, 259 graph-based, 471
Software quality assurance group, 186 Stress testing, 508 System perception, 396 Internet sources, 485
INDEX
Testing objectives, 449 User interface tool kits, 401
Testing principles, 450 User interfaces,
Testing strategy, 487 design evaluation, 401
tools. 811 design issues, 398
Tests, of, 453 User model, 395
Thread of control, 626 User scenarios, see Use cases, 799
Threat, 94 Users, types of, 395
D., 16
Time allocation, 157 Validation, 488
Time stamps, 428 Validation test criteria, 506
chart, 170 Validation testing, 491, 505
A., 4 00 systems, 650
Tools, see also CASE, 24, 808 Variants, 219
taxonomy of, 808 Verification, 488
Total quality management 184 Version control, 218
Tracking, for an object-oriented project, Versions, 217
576 Vital few, 195
Transaction, 375
Transaction center, 376 Walkthroughs, see also Formal
Transaction flow, 375 Technical Reviews, 191
Transaction mapping, 387 Ward, 312
example of, 387 J., 335
Transform, 311 methodology, 334
Transform mapping, example of, 377 Wasserman, A., 347, 372
Transitivity, 473 Waterfall model, 29
Wear, 11
Umbrella activities, 25, 59 Weinberg, G., 105, 187, 273
Understandability, 452 White-box testing, 454
Unit testing, 491, 494 Whole-part structure, 600
00 software, 648 Wirfs-Brock method, 586, 622
procedures, 497 Wirfs-Brock, R., 596
Usability, 94, 519. 521 Wirth. N. 348
Use cases, 592,654 Work breakdown structure 170
events. 605 analysis tools, 761
of, 593
priority, 593 E., 4, 127,497, 567, 626
questions, 592
User friendliness, 94 Z language notation, 700
User interface design, 394 specifications, 699
guidelines, 403 M., 91
implementation tools, 400