software engineering | More Info | Notesale | Buy and Sell Study Notes Online | Extra Student Income | University Notes

Search for notes by fellow students, in your own course and all over the country.

Browse our notes for titles which look like what you need, you can preview any of the notes via a sample of the contents. After you're happy these are the notes you're after simply pop them into your shopping cart.

My Basket

Buy These Notes

You have nothing in your shopping cart yet.

Title: software engineering
Description: full notes on software engineering

Buy These Notes Preview

Document Preview

Extracts from the notes are below, to see the PDF you'll receive please use the links above

Software Engineering
A

PRACTITIONER’S

APPROACH

McGraw-Hill Series in Computer Science
Senior Consulting Editor
C
...
Liu, National Tsing Hua
University
Consulting Editor
Allen B
...
Pressman, Ph
...

Boston Burr Ridge, IL Dubuque, IA Madison, WI
New York San Francisco St
...
1221 Avenue of the
Americas, New York, NY, 10020
...
All rights reserved
...
, including, but not limited to, in any network or other electronic
storage or transmission, or broadcast for distance learning
...

1 2 3 4 5 6 7 8 9 0 DOC/DOC 0 9 8 7 6 5 4 3 2 1 0
ISBN 0073655783
Publisher: Thomas Casson
Executive editor: Betsy Jones
Developmental editor: Emily Gray
Marketing manager: John Wannemacher
Project manager: Karen J
...

Typeface: 8
...
5 Leawood
Printer: R
...
Donnelley & Sons Company
Library of Congress Cataloging-in-Publication Data
Pressman, Roger S
...
Pressman
...

p
...
— (McGraw-Hill series in computer science)
Includes index
...
Software engineering
...
Title
...
Series
...
758
...
1—dc21
00-036133
http://www
...
com

To my parents

ABOUT THE AUTHOR

R

oger S
...
For over three decades, he has

worked as a software engineer, a manager, a professor, an author, and a consultant, focusing on software engineering issues
...
Pressman worked on the development of
CAD/CAM systems for advanced engineering and manufacturing applications
...

After receiving a Ph
...
in engineering from the University of Connecticut, Dr
...

Dr
...
S
...
, a consulting
ﬁrm specializing in software engineering methods and training
...
He also
designed and developed the company’s software engineering training and process improvement products—Essential Software Engineering, a complete video curriculum that is among
the industry's most comprehensive treatments of the subject, and Process Advisor, a selfdirected system for software engineering process improvement
...

Dr
...
In addition to Software Engineering: A Practitioner's
Approach, he has written A Manager's Guide to Software Engineering (McGraw-Hill), an
award-winning book that uses a unique Q&A format to present management guidelines
for instituting and understanding software engineering technology; Making Software Engineering Happen (Prentice-Hall), the ﬁrst book to address the critical management problems
associated with software process improvement; and Software Shock (Dorset House), a treatment that focuses on software and its impact on business and society
...
Pressman is on
the Editorial Boards of IEEE Software and the Cutter IT Journal, and for many years, was
editor of the “Manager” column in IEEE Software
...
Pressman is a well-known speaker, keynoting a number of major industry conferences
...
He is a member of the ACM, IEEE, and Tau Beta
Pi, Phi Kappa Phi, Eta Kappa Nu, and Pi Tau Sigma
...
1
1
...
2
...
2
...
3
Software: A Crisis on the Horizon? 11
1
...
5
Summary 15
REFERENCES 15
PROBLEMS AND POINTS TO PONDER 16
FURTHER READINGS AND INFORMATION SOURCES
CHAPTER 2

THE PROCESS

17

19

2
...
1
...
1
...
2
The Software Process 23
2
...
4
The Linear Sequential Model 28
2
...
6
The RAD Model 32
2
...
7
...
7
...
7
...
7
...
8
Component-Based Development 42
2
...
10
Fourth Generation Techniques 44
2
...
12
Product and Process 46
2
...
1

The Management Spectrum 56
3
...
1
The People 56
3
...
2
The Product 57
3
...
2
The Process 57
3
...
3
The Project 57
3
...
2
...
2
...
2
...
2
...
3
The Product 67
3
...
1
Software Scope 67
3
...
2
Problem Decomposition 67
3
...
4
...
4
...
5
The Project 71
3
...
7
Critical Practices 74
3
...
1
4
...
2
...
2
...
3
Software Measurement 87
4
...
1
Size-Oriented Metrics 88
4
...
2
Function-Oriented Metrics 89
4
...
3
Extended Function Point Metrics 91
4
...
5
Metrics for Software Quality 95
4
...
1
An Overview of Factors That Affect Quality 95
4
...
2
Measuring Quality 96
4
...
3
Defect Removal Efﬁciency 98
4
...
6
...
6
...
6
...
7
Managing Variation: Statistical Quality Control 100
4
...
9
Establishing a Software Metrics Program 105
4
...
1
5
...
3

Observations on Estimating 114
Project Planning Objectives 115
Software Scope 115
5
...
1
Obtaining Information Necessary for Scope 116
5
...
2
Feasibility 117
5
...
3
A Scoping Example 118
5
...
4
...
4
...
4
...
5
Software Project Estimation 123
5
...
6
...
6
...
6
...
6
...
6
...
6
...
7
Empirical Estimation Models 132
5
...
1
The Structure of Estimation Models 132
5
...
2
The COCOMO Model 133
5
...
3
The Software Equation 135
5
...
8
...
8
...
9
Automated Estimation Tools 139
5
...
1
6
...
3

145

Reactive versus Proactive Risk Strategies 146
Software Risks 146
Risk Identiﬁcation 148
6
...
1
Assessing Overall Project Risk 149
6
...
2
Risk Components and Drivers 149
6
...
4
...
4
...
4
...
5
Risk Reﬁnement 156
6
...
7
Safety Risks and Hazards 158
6
...
9
Summary 159
REFERENCES 160

xii

CONTENTS

PROBLEMS AND POINTS TO PONDER 161
FURTHER READINGS AND INFORMATION SOURCES
CHAPTER 7

PROJECT SCHEDULING AND TRACKING

162
165

7
...
1
...
2
...
2
The Relationship Between People and Effort 170
7
...
1
An Example 170
7
...
2
An Empirical Relationship 171
7
...
3
Effort Distribution 172
7
...
3
...
3
...
3
...
3
...
4
Selecting Software Engineering Tasks 177
7
...
6
Deﬁning a Task Network 180
7
...
7
...
7
...
8
Earned Value Analysis 186
7
...
10
The Project Plan 189
7
...
1

8
...
3

8
...
5

8
...
7
8
...
1
...
1
...
1
...
1
...
3
...
3
...
4
...
4
...
5
...
5
...
5
...
8
...
8
...
9
8
...
10
...
10
...
11
The SQA Plan 218
8
...
1
...
1
...
2
The SCM Process 230
9
...
4
Version Control 232
9
...
6
Conﬁguration Audit 237
9
...
8
SCM Standards 238
9
...
1

PA R T T H R E E — C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
CHAPTER 10

SYSTEM ENGINEERING
10
...
2

230

243

245

Computer-Based Systems 246
The System Engineering Hierarchy 248
10
...
1
System Modeling 249
10
...
2
System Simulation 251
10
...
4
Product Engineering: An Overview 254
10
...
5
...
5
...
5
...
5
...
5
...
5
...
6
System Modeling 262
10
...
1
11
...
2
...
2
...
2
...
2
...
3
Analysis Principles 282
11
...
1
The Information Domain 283
11
...
2
Modeling 285
11
...
3
Partitioning 286
11
...
4
Essential and Implementation Views 288
11
...
4
...
4
...
5
Speciﬁcation 291
11
...
1
Speciﬁcation Principles 291
11
...
2
Representation 292
11
...
3
The Software Requirements Speciﬁcation 293
11
...
7
Summary 294
REFERENCES 295
PROBLEMS AND POINTS TO PONDER 296
FURTHER READINGS AND INFORMATION SOURCES 297
CHAPTER 12

A N A LY S I S M O D E L I N G
12
...
2
12
...
3
...
3
...
3
...
4
Functional Modeling and Information Flow 309
12
...
1
Data Flow Diagrams 311
12
...
2
Extensions for Real-Time Systems 312
12
...
3
Ward and Mellor Extensions 312
12
...
4
Hatley and Pirbhai Extensions 315
12
...
6
The Mechanics of Structured Analysis 319
12
...
1
Creating an Entity/Relationship Diagram 319
12
...
2
Creating a Data Flow Model 321
12
...
3
Creating a Control Flow Model 324
12
...
4
The Control Speciﬁcation 325
12
...
5
The Process Speciﬁcation 327
12
...
8
Other Classical Analysis Methods 330
12
...
1
13
...
2
...
2
...
3
Design Principles 340
13
...
4
...
4
...
4
...
4
...
4
...
4
...
4
...
4
...
4
...
5
Effective Modular Design 352
13
...
1
Functional Independence 352
13
...
2
Cohesion 353
13
...
3
Coupling 354
13
...
7
The Design Model 357
13
...
9
Summary 359
REFERENCES 359
PROBLEMS AND POINTS TO PONDER 361
FURTHER READINGS AND INFORMATION SOURCES 362
CHAPTER 14

ARCHITECTURAL DESIGN
14
...
2

14
...
4

14
...
6

14
...
1
...
1
...
2
...
2
...
3
...
3
...
4
...
4
...
4
...
5
...
5
...
6
...
6
...
7
...
7
...
8
Reﬁning the Architectural Design 394
14
...
1

The Golden Rules 402
15
...
1
Place the User in Control 402
15
...
2
Reduce the User’s Memory Load 404
15
...
3
Make the Interface Consistent 404
15
...
2
...
2
...
3
Task Analysis and Modeling 408
15
...
4
...
4
...
5
Implementation Tools 415
15
...
7
Summary 418
REFERENCES 418
PROBLEMS AND POINTS TO PONDER 419
FURTHER READINGS AND INFORMATION SOURCES 420
CHAPTER 16

COMPONENT-LEVEL DESIGN

423

16
...
1
...
1
...
1
...
1
...
2
Comparison of Design Notation 432
16
...
1

17
...
3
17
...
5

437

Software Testing Fundamentals 438
17
...
1
Testing Objectives 439
17
...
2
Testing Principles 439
17
...
3
Testability 440
Test Case Design 443
White-Box Testing 444
Basis Path Testing 445
17
...
1
Flow Graph Notation 445
17
...
2
Cyclomatic Complexity 446
17
...
3
Deriving Test Cases 449
17
...
4
Graph Matrices 452
Control Structure Testing 454
17
...
1
Condition Testing 454

xvii

CONTENTS

17
...
2
Data Flow Testing 456
17
...
3
Loop Testing 458
17
...
6
...
6
...
6
...
6
...
6
...
7
Testing for Specialized Environments, Architectures, and Applications
17
...
1
Testing GUIs 469
17
...
2
Testing of Client/Server Architectures 469
17
...
3
Testing Documentation and Help Facilities 469
17
...
4
Testing for Real-Time Systems 470
17
...
1

477

A Strategic Approach to Software Testing 478
18
...
1
Veriﬁcation and Validation 479
18
...
2
Organizing for Software Testing 479
18
...
3
A Software Testing Strategy 480
18
...
4
Criteria for Completion of Testing 482
18
...
3
Unit Testing 485
18
...
1
Unit Test Considerations 485
18
...
2
Unit Test Procedures 487
18
...
4
...
4
...
4
...
4
...
4
...
4
...
5
Validation Testing 495
18
...
1
Validation Test Criteria 495
18
...
2
Conﬁguration Review 496
18
...
3
Alpha and Beta Testing 496
18
...
6
...
6
...
6
...
6
...
7 The Art of Debugging 499
18
...
1
The Debugging Process 499
18
...
2
Psychological Considerations 500
18
...
3
Debugging Approaches 501
18
...
1

Software Quality 508
19
...
1
McCall’s Quality Factors 509
19
...
2
FURPS 511
19
...
3
ISO 9126 Quality Factors 513
19
...
4
The Transition to a Quantitative View 513
19
...
2
...
2
...
2
...
3
Metrics for the Analysis Model 517
19
...
1
Function-Based Metrics 518
19
...
2
The Bang Metric 520
19
...
3
Metrics for Speciﬁcation Quality 522
19
...
4
...
4
...
4
...
5
Metrics for Source Code 531
19
...
7
Metrics for Maintenance 533
19
...
1
20
...
2
...
2
...
2
...
2
...
2
...
3
Identifying the Elements of an Object Model 553
20
...
1
Identifying Classes and Objects 553
20
...
2
Specifying Attributes 557
20
...
3
Deﬁning Operations 558
20
...
4
Finalizing the Object Deﬁnition 559
20
...
4
...
4
...
4
...
4
...
5
Summary 566
REFERENCES 566
PROBLEMS AND POINTS TO PONDER 567
FURTHER READINGS AND INFORMATION SOURCES 568

xix

CONTENTS

CHAPTER 21

O B J E C T - O R I E N T E D A N A LY S I S

571

21
...
1
...
OO Approaches 572
21
...
2
The OOA Landscape 573
21
...
3
A Uniﬁed Approach to OOA 575
21
...
2
...
2
...
3
Generic Components of the OO Analysis Model 579
21
...
4
...
4
...
4
...
4
...
5
The Object-Relationship Model 591
21
...
6
...
6
...
7
Summary 598
REFERENCES 599
PROBLEMS AND POINTS TO PONDER 600
FURTHER READINGS AND INFORMATION SOURCES 601
CHAPTER 22

OBJECT-ORIENTED DESIGN
22
...
1
...
OO Approaches 605
22
...
2
Design Issues 607
22
...
3
The OOD Landscape 608
22
...
4
A Uniﬁed Approach to OOD 610
22
...
2
...
2
...
2
...
2
...
2
...
2
...
2
...
3
The Object Design Process 618
22
...
1
Object Descriptions 618
22
...
2
Designing Algorithms and Data Structures 619
22
...
3
Program Components and Interfaces 621
22
...
4
...
4
...
5
Object-Oriented Programming 625
22
...
1
23
...
2
...
2
...
3
Object-Oriented Testing Strategies 636
23
...
1
Unit Testing in the OO Context 636
23
...
2
Integration Testing in the OO Context 637
23
...
3
Validation Testing in an OO Context 637
23
...
4
...
4
...
4
...
4
...
4
...
4
...
4
...
5
Testing Methods Applicable at the Class Level 644
23
...
1
Random Testing for OO Classes 644
23
...
2
Partition Testing at the Class Level 644
23
...
6
...
6
...
7
Summary 648
REFERENCES 649
PROBLEMS AND POINTS TO PONDER 649
FURTHER READINGS AND INFORMATION SOURCES 650
CHAPTER 24

638

TECHNICAL METRICS FOR OBJECT-ORIENTED
SYSTEMS
24
...
2

653

The Intent of Object-Oriented Metrics 654
The Distinguishing Characteristics of Object-Oriented Metrics
24
...
1
Localization 655
24
...
2
Encapsulation 655
24
...
3
Information Hiding 655
24
...
4
Inheritance 656
24
...
5
Abstraction 656
24
...
4
Class-Oriented Metrics 658
24
...
1
The CK Metrics Suite 658
24
...
2
Metrics Proposed by Lorenz and Kidd 661
24
...
3
The MOOD Metrics Suite 662
24
...
6
Metrics for Object-Oriented Testing 664
24
...
8
Summary 666
REFERENCES 667
PROBLEMS AND POINTS TO PONDER 668
FURTHER READINGS AND INFORMATION SOURCES 669

654

xxi

CONTENTS

PA R T F I V E — A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G
CHAPTER 25

FORMAL METHODS

671

673

25
...
1
...
1
...
1
...
2
Mathematical Preliminaries 682
25
...
1
Sets and Constructive Speciﬁcation 683
25
...
2
Set Operators 684
25
...
3
Logic Operators 686
25
...
4
Sequences 686
25
...
4
Formal Speciﬁcation Languages 689
25
...
6
The Ten Commandments of Formal Methods 693
25
...
8
Summary 695
REFERENCES 695
PROBLEMS AND POINTS TO PONDER 696
FURTHER READINGS AND INFORMATION SOURCES 697
CHAPTER 26

C L E A N R O O M S O F T WA R E E N G I N E E R I N G

699

26
...
1
...
1
...
2
Functional Speciﬁcation 703
26
...
1
Black-Box Speciﬁcation 705
26
...
2
State-Box Speciﬁcation 705
26
...
3
Clear-Box Speciﬁcation 706
26
...
3
...
3
...
4
Cleanroom Testing 712
26
...
1
Statistical Use Testing 712
26
...
2
Certiﬁcation 714
26
...
1
27
...
3

27
...
3
...
3
...
3
...
4
...
4 2
Component Engineering 734
27
...
3
Analysis and Design for Reuse 734
27
...
5
...
5
...
6
Economics of CBSE 739
27
...
1
Impact on Quality, Productivity, and Cost 739
27
...
2
Cost Analysis Using Structure Points 741
27
...
3
Reuse Metrics 741
27
...
1

747

The Structure of Client/Server Systems 748
28
...
1
Software Components for c/s Systems 750
28
...
2
The Distribution of Software Components 750
28
...
3
Guidelines for Distributing Application Subsystems 752
28
...
4
Linking c/s Software Subsystems 753
28
...
5
Middleware and Object Request Broker Architectures 753
28
...
3
Analysis Modeling Issues 755
28
...
4
...
4
...
4
...
4
...
4
...
5
Testing Issues 761
28
...
1
Overall c/s Testing Strategy 762
28
...
2
c/s Testing Tactics 763
28
...
1

29
...
3
29
...
5

769

The Attributes of Web-Based Applications 771
29
...
1
Quality Attributes 773
29
...
2
The Technologies 773
The WebE Process 774
A Framework for WebE 775
Formulating/Analyzing Web-Based Systems 776
29
...
1
Formulation 776
29
...
2
Analysis 778
Design for Web-Based Applications 779
29
...
1
Architectural Design 780
29
...
2
Navigation Design 783
29
...
3
Interface Design 785

xxiii

CONTENTS

29
...
7

Testing Web-Based Applications 786
Management Issues 787
29
...
1
The WebE Team 788
29
...
2
Project Management 789
29
...
3
SCM Issues for WebE 792
29
...
1

Business Process Reengineering 800
30
...
1
Business Processes 800
30
...
2
Principles of Business Process Reengineering 801
30
...
3
A BPR Model 802
30
...
4
Words of Warning 804
30
...
2
...
2
...
3
Reverse Engineering 809
30
...
1
Reverse Engineering to Understand Processing 810
30
...
2
Reverse Engineering to Understand Data 811
30
...
3
Reverse Engineering User Interfaces 812
30
...
4
...
4
...
5
Forward Engineering 814
30
...
1
Forward Engineering for Client/Server Architectures 816
30
...
2
Forward Engineering for Object-Oriented Architectures 817
30
...
3
Forward Engineering User Interfaces 818
30
...
7
Summary 820
REFERENCES 820
PROBLEMS AND POINTS TO PONDER 822
FURTHER READINGS AND INFORMATION SOURCES 823
CHAPTER 31

C O M P U T E R - A I D E D S O F T WA R E E N G I N E E R I N G
31
...
2
31
...
4
31
...
6

What is CASE? 826
Building Blocks for CASE 826
A Taxonomy of CASE Tools 828
Integrated CASE Environments 833
The Integration Architecture 834
The CASE Repository 836
31
...
1
The Role of the Repository in I-CASE 836
31
...
2
Features and Content 837
31
...
1
The Importance of Software—Revisited 846
32
...
3
People and the Way They Build Systems 847
32
...
5
New Modes for Representing Information 849
32
...
7
A Concluding Comment 852
REFERENCES 853
PROBLEMS AND POINTS TO PONDER 853
FURTHER READINGS AND INFORMATION SOURCES 853

P R E FA C E
hen a computer software succeeds—when it meets the needs of the people

W

who use it, when it performs ﬂawlessly over a long period of time, when it is

easy to modify and even easier to use—it can and does change things for the better
...
We
all want to build software that makes things better, avoiding the bad things that lurk
in the shadow of failed efforts
...
We need an engineering approach
...
Today, it is recognized as a subject worthy of
serious research, conscientious study, and tumultuous debate
...
Software
process models, software engineering methods, and software tools have been adopted
successfully across a broad spectrum of industry applications
...
Many individuals and companies still develop software haphazardly,
even as they build systems to service the most advanced technologies of the day
...
And as a result,
the quality of the software that we produce suffers and bad things happen
...
The status of software engineering is a study in contrasts
...

The ﬁfth edition of Software Engineering: A Practitioner's Approach is intended to
serve as a guide to a maturing engineering discipline
...
The format
and style of the ﬁfth edition have undergone signiﬁcant change, making the presentation more reader-friendly and the content more easily accessible
...
The book has been
revised to accommodate the dramatic growth in the ﬁeld and to emphasize new and
important software engineering practices
...
The Web site, which I call

xxv

xxvi

P R E FA C E

SepaWeb, can be found at http://www
...
com/pressman
...

Like all Web sites, SepaWeb will evolve over time, but the following major content areas will always be present: (1) a broad array of instructor resources including
a comprehensive on-line Instructor’s Guide and supplementary teaching materials
(e
...
, slide presentations to supplement lectures, video-based instructional aids); (2)
a wide variety of student resources including an extensive on-line learning center
(encompassing study guides, Web-based resources, and self-tests), an evolving collection of “tiny tools,” a case study, and additional supplementary content; and (3) a
detailed collection of professional resources including outlines (and samples of) software engineering documents and other work products, a useful set of software engineering checklists, a catalog of software engineering (CASE) tools, a comprehensive
collection of Web-based resources, and an “adaptable process model” that provides
a detailed task breakdown of the software engineering process
...

The 32 chapters of the ﬁfth edition have been organized into ﬁve parts
...
Part One, The Product and the Process,
presents an introduction to the software engineering milieu
...
Part Two, Managing Software Projects, presents topics that
are relevant to those who plan, manage, and control a software development project
...
Part Four, Object-Oriented Software Engineering,
presents object-oriented methods across the entire software engineering process,
including analysis, design, and testing
...

The ﬁve-part organization of the ﬁfth edition enables an instructor to "cluster" topics based on available time and student need
...
For example, a "design course" might emphasize only Part Three or Part Four; a "methods course" might present selected chapters in Parts Three, Four, and Five
...
By organizing the ﬁfth edition in this way, I attempted to provide an instructor with a number of teaching options
...

An Instructor's Guide for Software Engineering: A Practitioner's Approach is available from SepaWeb
...

A comprehensive video curriculum, Essential Software Engineering, is available to
complement this book
...
Further information on the video
can be obtained by mailing the request card at the back of this book
...
Even when the writing stops,
information extracted from the technical literature continues to be assimilated and
organized
...
Many have been referenced within
the pages of each chapter
...
I also wish to thank the reviewers of the fifth edition: Donald H
...
Livadas, University of Florida; Joseph Lambert,
Pennsylvania State University; Kenneth L
...
Their comments and criticism have
been invaluable
...
Bruce is responsible for much of its design and pedagogical content
...
My thanks to each of you
...

As the editions of this book have evolved, my sons, Mathew and Michael, have
grown from boys to men
...
Nothing has ﬁlled me with more pride
...
"
Roger S
...
S
...
Web site at
http://www
...
com/ese or e-mail a request for information to info@rspa
...

USING THIS BOOK

T

he fifth edition of Software Engineering: A Practitioner’s Approach (SEPA) has been
redesigned to enhance your reading experience and to provide integrated links to the

SEPA Web site, http://www
...
com/pressman/
...
g
...

A comprehensive video curriculum, Essential Software Engineering, is available to complement this book
...
Further information on the video can be obtained by mailing the request card at the back of this book
...

Practical advice from
the real world of
software engineering
...

The advice icon provides pragmatic guidance that can help
you make the right decision or
avoid common problems while
building software
...

“Important words”

The question mark icon asks
common questions that are
answered in the body of the
text
...

The quote icon presents interesting quotes that have relevance to the topic at hand
...

The SepaWeb pointer indicates
that further information about
the noted topic is available at
the SEPA Web site
...
checklists icon
points you to detailed checklists
that will help you to assess the
software engineering work
you’re doing and the work
products you produce
...
documents
icon points you to detailed document outlines, descriptions
and examples contained within
the SEPA Web site
...
S
...
Web site at
http://www
...
com/ese, or e-mail to info@rspa
...

PA R T

One
THE PRODUCT AND
THE PROCESS

n this part of Software Engineering: A Practitioner’s Approach, you’ll
learn about the product that is to be engineered and the process
that provides a framework for the engineering technology
...
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?
• What advanced process models have been proposed for software engineering work?
Once these questions are answered, you’ll be better prepared to
understand the management and technical aspects of the engineering discipline to which the remainder of this book is dedicated
...
9

T

component-based
assembly
...
Software,

much attention
...
Then government ofﬁcials voiced their concern, busi-

ness and industry leaders committed vast sums of money, and ﬁnally, dire warn-

failure curves
...
5

world as we then knew it
...
12

help thinking of an unintentionally prophetic paragraph contained on the ﬁrst

reuse
...
It stated:

software
characteristics
...
It is the engine that drives business

software
engineering
...
It serves as the basis for modern scientiﬁc investigation and engi-

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

neering problem solving
...
the
list is almost endless
...
And as
we move into the twenty-ﬁrst century, it will become the driver for new advances in
everything from elementary education to genetic engineering
...
It encom-

ing a process that leads to a high-quality result

passes programs that execute within a computer

that meets the needs of the people who will use

of any size and architecture, documents that

the product
...

data that combine numbers and text but also

What is the work product? From the point of view of

includes representations of pictorial, video, and

a software engineer, the work product is the pro-

audio information
...
But from the user’s viewpoint, the work

ally everyone in the industrialized world uses it

product is the resultant information that somehow

either directly or indirectly
...

Why is it important? Because it affects nearly every

How do I ensure that I’ve done it right? Read the

aspect of our lives and has become pervasive in

remainder of this book, select those ideas appli-

our commerce, our culture, and our everyday

cable to the software that you build, and apply

activities
...

3

4

PA R T O N E

THE PRODUCT AND THE PROCESS

In the ﬁve years since the fourth edition of this book was written, the role of software as the “driving force” has become even more obvious
...
In the euphoria created by the promise
of a new economic paradigm, Wall Street investors gave tiny “dot-com” companies
billion dollar valuations before these start-ups produced a dollar in sales
...
The United States government has
litigated against the software’s industry’s largest company, just as it did in earlier eras
when it moved to stop monopolistic practices in the oil and steel industries
...
As its

“Ideas and
technological
discoveries are the
driving engines of
economic growth
...
Some of these technologies are targeted at a specific application
domain (e
...
, Web-site design and implementation); others focus on a technology
domain (e
...
, object-oriented systems); and still others are broad-based (e
...
, operating systems such as LINUX)
...
And yet,
people bet their jobs, their comfort, their safety, their entertainment, their decisions,
and their very lives on computer software
...

This book presents a framework that can be used by those who build computer
software—people who must get it right
...

1
...
It is a product and, at the same time, the vehicle for delivering a product
...
Whether it resides within a cellular phone or operates inside a
mainframe computer, software is an information transformer—producing, manag-

Software is both a
product and a vehicle
for delivering a
product
...
As the vehicle used
to deliver the product, software acts as the basis for the control of the computer (operating systems), the communication of information (networks), and the creation and
control of other programs (software tools and environments)
...
Software
transforms personal data (e
...
, an individual’s ﬁnancial transactions) so that the data
can be more useful in a local context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information networks (e
...
, Internet) and provides the means for acquiring information in all of its forms
...
Dramatic improvements in hardware performance, pro-

CHAPTER 1

THE PRODUCT

5

found changes in computing architectures, vast increases in memory and storage
capacity, and a wide variety of exotic input and output options have all precipitated
more sophisticated and complex computer-based systems
...

Popular books published during the 1970s and 1980s provide useful historical
insight into the changing perception of computers and software and their impact on

“For I dipped into the
future, far as the
human eye could
see, Saw the vision
of the world, and all
the wonder that
would be
...
Osborne [OSB79] characterized a "new industrial revolution
...
" Feigenbaum and McCorduck [FEI83] suggested
that information and knowledge (controlled by computers) would be the focal point
for power in the twenty-ﬁrst century, and Stoll [STO89] argued that the "electronic
community" created by networks and software was the key to knowledge interchange
throughout the world
...
" Yourdon

“Computers make it
easy to do a lot of
things, but most of
the things that they
make it easier to do
don't need to be
done
...
S
...
”
Hammer and Champy [HAM93] argued that information technologies were to play a
pivotal role in the “reengineering of the corporation
...
g
...
These authors demonized the computer, emphasizing legitimate concerns but ignoring the profound beneﬁts that have already been
realized
...
As the Internet grew in importance, his change of heart proved
to be correct
...
g
...

Although the predictions of the Y2K doomsayers were incorrect, their popular
writings drove home the pervasiveness of software in our lives
...
Software’s role continues to
expand
...
And yet, the same questions asked of the lone programmer are being
asked when modern computer-based systems are built:

6

PA R T O N E

THE PRODUCT AND THE PROCESS

• Why does it take so long to get software ﬁnished?
• Why are development costs so high?
• Why can't we ﬁnd all the errors before we give the software to customers?
• Why do we continue to have difﬁculty in measuring progress as software is
being developed?
These, and many other questions,1 are a manifestation of the concern about software and the manner in which it is developed—a concern that has lead to the adoption of software engineering practice
...
2

S O F T WA R E
In 1970, less than 1 percent of the public could have intelligently described what
"computer software" meant
...
But do they?
A textbook description of software might take the following form: Software is (1)
instructions (computer programs) that when executed provide desired function and per-

should
? Howdeﬁne
we
software?

formance, (2) data structures that enable the programs to adequately manipulate information, and (3) documents that describe the operation and use of the programs
...
But we need
more than a formal deﬁnition
...
2
...
When hardware is built, the
human creative process (analysis, design, construction, testing) is ultimately translated into a physical form
...

Software is a logical rather than a physical system element
...
Software is developed or engineered, it is not manufactured in the classical
sense
...

Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different
...
He states: “Instead of asking ‘why does software cost so much?’ we need to begin asking ‘What have we done to make it possible for today’s software to cost so little?’ The answer to
that question will help us continue the extraordinary level of achievement that has always distinguished the software industry
...
1
Failure curve
for hardware
“Infant
mortality”
Failure rate

“Wear out”

Time

ity is achieved through good design, but the manufacturing phase for hardware can
introduce quality problems that are nonexistent (or easily corrected) for software
...
Both activities require
the construction of a "product" but the approaches are different
...
This means that software projects cannot be managed as if they were manufacturing projects
...

2
...
"
Figure 1
...
The relationship,
often called the "bathtub curve," indicates that hardware exhibits relatively 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 to a steady-state level
(ideally, quite low) for some period of time
...
Stated
simply, the hardware begins to wear out
...
In theory, therefore, the failure rate curve for software should take the form of
the “idealized curve” shown in Figure 1
...
Undiscovered defects will cause high failure
rates early in the life of a program
...
The idealized curve is a gross oversimpliﬁcation of actual failure models (see Chapter 8 for more information) for software
...
But it does deteriorate!
This seeming contradiction can best be explained by considering the “actual curve”
shown in Figure 1
...
During its life, software will undergo change (maintenance)
...
2
Idealized and
actual failure
curves for
software

THE PRODUCT AND THE PROCESS

Failure rate

Increased failure
rate due to side
effects

Change
Actual curve

Idealized curve

Software engineering
methods strive to
reduce the magnitude
of the spikes and the
slope of the actual
curve in Figure 1
...

Time

changes are made, it is likely that some new defects will be introduced, causing the
failure rate curve to spike as shown in Figure 1
...
Before the curve can return to the
original steady-state failure rate, another change is requested, causing the curve to
spike again
...

Another aspect of wear illustrates the difference between hardware and software
...
There are no
software spare parts
...
Therefore, software maintenance involves considerably more complexity than hardware
maintenance
...
Although the industry is moving toward component-based assembly, most

Most software
continues to be
custom built
...

Consider the manner in which the control hardware for a computer-based product
is designed and built
...
Each
integrated circuit (called an IC or a chip) has a part number, a deﬁned and validated
function, a well-deﬁned interface, and a standard set of integration guidelines
...

As an engineering discipline evolves, a collection of standard design components
is created
...
The reusable components have been created so that the
engineer can concentrate on the truly innovative elements of a design, that is, the

CHAPTER 1

THE PRODUCT

9

parts of the design that represent something new
...
In the software world, it is something that has only begun to be achieved on a broad scale
...
In the 1960s, we built scientiﬁc subroutine libraries
XRef
Software reuse is
discussed in Chapter
13
...

that were reusable in a broad array of engineering and scientiﬁc applications
...
Today, we have extended our view of reuse to encompass not only algorithms but also data structure
...
For example, today's graphical user
interfaces are built using reusable components that enable the creation of graphics
windows, pull-down menus, and a wide variety of interaction mechanisms
...

1
...
2

Software Applications

Software may be applied in any situation for which a prespeciﬁed set of procedural
steps (i
...
, an algorithm) has been deﬁned (notable exceptions to this rule are expert
system software and neural network software)
...
Content
refers to the meaning and form of incoming and outgoing information
...
” Software that controls an automated machine (e
...
, a
numerical control) accepts discrete data items with limited structure and produces
individual machine commands in rapid succession
...
An engineering analysis program accepts data that have a predeﬁned order,
executes the analysis algorithm(s) without interruption, and produces resultant data
in report or graphical format
...
A multiuser operating system, on the other hand, accepts inputs that have varied content and arbitrary timing, executes algorithms that can be interrupted by external conditions, and
produces output that varies as a function of environment and time
...

It is somewhat difﬁcult to develop meaningful generic categories for software applications
...
The
following software areas indicate the breadth of potential applications:
System software
...
Some system software (e
...
, compilers, editors, and ﬁle management utilities) process complex, but determinate, information structures
...
g
...
In either case, the system software
area is characterized by heavy interaction with computer hardware; heavy usage by
multiple users; concurrent operation that requires scheduling, resource sharing, and
sophisticated process management; complex data structures; and multiple external
interfaces
...
Software that monitors/analyzes/controls real-world events
as they occur is called real time
...

Business software
...
Discrete "systems" (e
...
, payroll, accounts receivable/payable, inventory) have evolved into management information system (MIS) software that accesses
one or more large databases containing business information
...
shareware
...
In addition to conventional data processing application,
business software applications also encompass interactive computing (e
...
, pointof-sale transaction processing)
...
Engineering and scientiﬁc software have
been characterized by "number crunching" algorithms
...
However, modern
applications within the engineering/scientiﬁc area are moving away from conventional numerical algorithms
...

Embedded software
...
Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets
...
g
...
g
...

Personal computer software
...
Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business ﬁnancial
applications, external network, and database access are only a few of hundreds of
applications
...
The Web pages retrieved by a browser are software that
incorporates executable instructions (e
...
, CGI, HTML, Perl, or Java), and data (e
...
,

CHAPTER 1

THE PRODUCT

11

hypertext and a variety of visual and audio formats)
...

Artificial intelligence software
...
Expert systems, also called knowledgebased systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing are representative of applications within this
category
...
3

S O F T WA R E : A C R I S I S O N T H E H O R I Z O N ?
Many industry observers (including this author) have characterized the problems
associated with software development as a "crisis
...
g
...
Yet, the great suc-

“The most likely way
for the world to be
destroyed, most
experts agree, is by
accident
...
We
cause accidents
...
Robert Glass, the author of a number of books on
software failures, is representative of those who have had a change of heart
...
”
It is true that software people succeed more often than they fail
...
What we
really have may be something rather different
...
” Yet, in terms of overall software quality and the speed with which computer-based systems and products are developed,
there has been no "turning point," no "decisive time," only slow, evolutionary change,
punctuated by explosive technological changes in disciplines associated with software
...
" This deﬁnition may give us
a clue about the real nature of the problems that have plagued software development
...
2 The
word afﬂiction is deﬁned as "anything causing pain or distress
...
" It is far more accurate to describe the problems we
have endured in the software business as a chronic afﬂiction than a crisis
...

12

PA R T O N E

THE PRODUCT AND THE PROCESS

properly
...

We live with this afﬂiction to this day—in fact, the industry prospers in spite of it
...

1
...
Unlike ancient myths that often provide
human lessons well worth heeding, software myths propagated misinformation and

“In the absence of
meaningful standards,
a new industry like
software comes to
depend instead on
folklore
...
Software myths had a number of attributes that made them insidious; for
instance, they appeared to be reasonable statements of fact (sometimes containing
elements of truth), they had an intuitive feel, and they were often promulgated by
experienced practitioners who "knew the score
...
However, old attitudes and habits are difﬁcult to modify, and remnants
of software myths are still believed
...
Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality
...

Myth:

We already have a book that's full of standards and procedures for building

software, won't that provide my people with everything they need to know?
Reality:

The book of standards may very well exist, but is it used? Are software

practitioners aware of its existence? Does it reﬂect modern software engineering practice? Is it complete? Is it streamlined to improve time to delivery while still maintaining a focus on quality? In many cases, the answer to all of these questions is "no
...

Reality:

It takes much more than the latest model mainframe, workstation, or PC

to do high-quality software development
...

Myth:

If we get behind schedule, we can add more programmers and catch up

(sometimes called the Mongolian horde concept)
...

In the words of Brooks [BRO75]: "adding people to a late software project makes it

CHAPTER 1

THE PRODUCT

13

later
...
However, as new people
are added, people who were working must spend time educating the newcomers,
thereby reducing the amount of time spent on productive development effort
...
spmn
...

ple can be added but only in a planned and well-coordinated manner
...

Reality:

If an organization does not understand how to manage and control software

projects internally, it will invariably struggle when it outsources software projects
...
A customer who requests computer software may be a person
at the next desk, a technical group down the hall, the marketing/sales department,
or an outside company that has requested software under contract
...
Myths lead to false expectations (by the
customer) and ultimately, dissatisfaction with the developer
...
You may not be
able to develop every
detail, but the more
you know, the less risk
you take
...

Reality:

A poor up-front deﬁnition is the major cause of failed software efforts
...
These
characteristics can be determined only after thorough communication between customer and developer
...

Reality:

It is true that software requirements change, but the impact of change

varies with the time at which it is introduced
...
3 illustrates the impact of
change
...
The customer can review requirements and recomXRef
The management and
control of change is
considered in detail in
Chapter 9
...
When changes are requested
during software design, the cost impact grows rapidly
...
Change can cause upheaval
that requires additional resources and major design modiﬁcation, that is, additional
cost
...
Change, when requested
after software is in production, can be over an order of magnitude more expensive
than the same change requested earlier
...

14

PA R T O N E

THE PRODUCT AND THE PROCESS

F I G U R E 1
...
5–6×
1×

Definition

Development

After release

Practitioner's myths
...
During the early days of software,
programming was viewed as an art form
...

Myth:

Once we write the program and get it to work, our job is done
...
" Industry data ([LIE80], [JON91], [PUT97]) indicate that
between 60 and 80 percent of all effort expended on software will be expended after
it is delivered to the customer for the ﬁrst time
...

Reality:

One of the most effective software quality assurance mechanisms can be

applied from the inception of a project—the formal technical review
...

Myth:

The only deliverable work product for a successful project is the working

program
...
Documentation provides a foundation for successful engineering
and, more important, guidance for software support
...

Reality:

Software engineering is not about creating documents
...
Better quality leads to reduced rework
...

Many software professionals recognize the fallacy of the myths just described
...
Recognition of software realities is the
ﬁrst step toward formulation of practical solutions for software engineering
...
5

THE PRODUCT

15

SUMMARY
Software has become the key element in the evolution of computer-based systems
and products
...
But early “programming” culture and history have created a set of problems that persist today
...
Software is composed of programs, data, and documents
...
The intent of software engineering is to provide a framework for
building software with higher quality
...
, The Mythical Man-Month, Addison-Wesley, 1975
...
et al
...

[DEM95] DeMarco, T
...
9
...
A
...
McCorduck, The Fifth Generation, Addison-

Wesley, 1983
...
, Software Failure, Management Failure—Amazing Stories and
Cautionary Tales, Wiley, 1997
...
L
...

[GLA98] Glass, R
...
, “Is There Really a Software Crisis?” IEEE Software, vol
...
1, January 1998, pp
...

[HAM93] Hammer, M
...
Champy, Reengineering the Corporation, HarperCollins
Publishers, 1993
...
, Applied Software Measurement, McGraw-Hill, 1991
...
and J
...

[LEV95] Levy, S
...
55
...
, “The New Digital Galaxy,” Newsweek, May 31, 1999, p
...

[LIE80]

Lientz, B
...
Swanson, Software Maintenance Management, Addison-

Wesley, 1980
...
, Megatrends, Warner Books, 1982
...
, The Invisible Computer, MIT Press, 1998
...
, Running Wild—The Next Industrial Revolution,
Osborne/McGraw-Hill, 1979
...
and W
...

[STO89] Stoll, C
...

[TOF80] Tofﬂer, A
...

16

PA R T O N E

THE PRODUCT AND THE PROCESS

[TOF90] Tofﬂer, A
...

[YOU92] Yourdon, E
...

[YOU96] Yourdon, E
...

[YOU98a] Yourdon, E
...

[YOU98b] Yourdon, E
...
Yourdon, Time Bomb 2000, Prentice-Hall, 1998
...
1
...
Provide examples of two or three products and at least one system in
which software, not hardware, is the differentiating element
...
2
...
How have the early days affected software development
practices today?
1
...
Many authors have discussed the impact of the "information era
...
Review one of the pre-1990 references in Section 1
...

1
...
Choose a speciﬁc application and indicate: (a) the software application category
(Section 1
...
2) into which it ﬁts; (b) the data content associated with the application;
and (c) the information determinacy of the application
...
5
...
Develop a realistic doomsday
scenario (other than Y2K) where the failure of a computer program could do great
harm (either economic or human)
...
6
...
risks and prepare a summary of risks to
the public that have recently been discussed
...

1
...
Write a paper summarizing recent advances in one of the leading edge software application areas
...

1
...
The “myths” noted in Section 1
...
Attempt to add one or two “new” myths to each category
...
The vast majority discuss programming languages or software applications, but a few discuss software itself
...

Negroponte's (Being Digital, Alfred A
...
Books by Norman [NOR98] and Bergman (Information Appliances and Beyond, Academic Press/Morgan Kaufmann, 2000) suggest that the widespread impact of the PC will decline as
information appliances and pervasive computing connect everyone in the industrialized world and almost every “appliance” that they own to a new Internet
infrastructure
...
DeMarco (Why Does Software Cost So Much? Dorset House, 1995) has produced a collection of amusing and insightful essays on software and the process
through which it is developed
...
An up-to-date list of World Wide Web references
that are relevant to software can be found at the SEPA Web site:
http://www
...
com/engcs/compsci/pressman/resources/product
...
23
component-based
development
...
40
evolutionary process
models
...
43
4GT
...
21

THE PROCESS
n a fascinating book that provides an economist’s view of software and soft-

I

ware engineering, Howard Baetjer, Jr
...
The process is a dialogue in which the
knowledge that must become the software is brought together and embodied in the
software
...
It
is an iterative process in which the evolving tool itself serves as the medium for communication, with each new round of the dialogue eliciting more useful knowledge
from the people involved
...
24

Indeed, building computer software is an iterative learning process, and the

prototyping
...
32
software
engineering
...

What is it? When you build a

building
...
The road map that
you follow is called a ‘software process
...

What is the work product? From the point of view
of a software engineer, the work products are the

Who does it? Software engineers and their man-

programs, documents, and data produced as a

agers adapt the process to their needs and then

consequence of the software engineering activi-

follow it
...

ties deﬁned by the process
...
However, the quality, timeliness,

if left uncontrolled, become quite chaotic
...

19

20

PA R T O N E

THE PRODUCT AND THE PROCESS

But what exactly is a software process from a technical point of view? Within the
context of this book, we deﬁne a software process as a framework for the tasks that
are required to build high-quality software
...
” A software process deﬁnes the approach that
is taken as software is engineered
...

More important, software engineering is performed by creative, knowledgeable
people who should work within a deﬁned and mature software process that is appropriate for the products they build and the demands of their marketplace
...

2
...
”
Scott Whitmire

the subject still serves as a basis for discussion:
[Software engineering is] the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efﬁciently on real machines
...
It says little about the
technical aspects of software quality; it does not directly address the need for customer satisfaction or timely product delivery; it omits mention of the importance of
measurement and metrics; it does not state the importance of a mature process
...
What “sound engineering principles” can be applied to computer software development? How do we “economically”
build software so that it is “reliable”? What is required to create computer programs
that work “efﬁciently” on not one but many different “real machines”? These are the
questions that continue to challenge software engineers
...
(2) The study of approaches as in (1)
...
1
...
Referring to Figure 2
...
Total quality management and similar philosophies foster a
continuous process improvement culture, and this culture ultimately leads to the

CHAPTER 2

21

THE PROCESS

F I G U R E 2
...
The
bedrock that supports software engineering is a quality focus
...
Software engineering process is the glue that holds the technology layers together and enables rational
and timely development of computer software
...
The key process areas form the basis for management control of software projects and establish the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc
...

Software engineering methods provide the technical how-to's for building software
...

sis, design, program construction, testing, and support
...

Software engineering tools provide automated or semi-automated support for the
process and the methods
...
CASE combines software,
hardware, and a software engineering database (a repository containing important
information about analysis, design, program construction, and testing) to create a
software engineering environment analogous to CAD/CAE (computer-aided
design/engineering) for hardware
...
1
...
Regardless of the entity to be engineered, the following
questions must be asked and answered:
•

What is the problem to be solved?

•

What characteristics of the entity are used to solve the problem?

22

PA R T O N E

THE PRODUCT AND THE PROCESS

•
•

WebRef
Crosstalk is a journal that
provides pragmatic
software engineering
advice and comment
...
stsc
...
af
...

Throughout this book, we focus on a single entity—computer software
...
In this section,
the generic characteristics of the software process are considered
...

The work associated with software engineering can be categorized into three
generic phases, regardless of application area, project size, or complexity
...

addresses one or more of the questions noted previously
...
That is, during deﬁnition, the software engineer attempts to identify what information is to be processed, what function and performance are desired, what system behavior can be expected, what interfaces are to
be established, what design constraints exist, and what validation criteria are required
to deﬁne a successful system
...
Although the methods applied during the definition phase will vary
depending on the software engineering paradigm (or combination of paradigms) that
is applied, three major tasks will occur in some form: system or information engineering (Chapter 10), software project planning (Chapters 3, 5, 6, and 7), and requirements analysis (Chapters 11, 12, and 21)
...
No such
faith comforts the
software engineer
...
”
Fred Brooks

The development phase focuses on how
...

The methods applied during the development phase will vary, but three speciﬁc technical tasks should always occur: software design (Chapters 13–16, and 22), code generation, and software testing (Chapters 17, 18, and 23)
...
The support phase reapplies the
steps of the deﬁnition and development phases but does so in the context of existing
software
...
Even with the best quality assurance activities, it is likely that the
customer will uncover defects in the software
...

Adaptation
...
g
...
Adaptive maintenance results in modiﬁcation to
the software to accommodate changes to its external environment
...
As software is used, the customer/user will recognize additional functions that will provide benefit
...

Prevention
...

this, preventive maintenance, often called software reengineering, must be conducted to enable the software to serve the needs of its end users
...

In addition to these support activities, the users of software require continuing support
...

Today, a growing population of legacy programs1 is forcing many companies to
pursue software reengineering strategies (Chapter 30)
...

The phases and related steps described in our generic view of software engineering are complemented by a number of umbrella activities
...

2
...
2
...
A number
of task sets—each a collection of software engineering work tasks, project milestones,

1

The term legacy programs is a euphemism for older, often poorly designed and documented software that is business critical and must be supported over many years
...
2
The software
process

THE PRODUCT AND THE PROCESS

Common process framework
Framework activities
Task sets
Tasks
Milestones, deliverables
SQA points

Umbrella activities

work products, and quality assurance points—enable the framework activities to be
adapted to the characteristics of the software project and the requirements of the
project team
...

Select a common
process framework
that is tuned to the
product, the people,
and the project
...

In recent years, there has been a signiﬁcant emphasis on “process maturity
...
To determine an organization’s
current state of process maturity, the SEI uses an assessment that results in a five
point grading scheme
...
The SEI approach provides a measure of the global effectiveness
of a company's software engineering practices and establishes ﬁve process maturity
levels that are deﬁned in the following manner:
Level 1: Initial
...
Few processes are deﬁned, and success depends on individual effort
...

Basic project management processes are established

to track cost, schedule, and functionality
...

2

These topics are discussed in detail in later chapters
...

The software process for both management and engi-

neering activities is documented, standardized, and integrated into an organizationwide software process
...

WebRef

This level includes all characteristics deﬁned for level 2
...
sei
...
edu

Level 4: Managed
...
Both the software process and products are quantitatively
understood and controlled using detailed measures
...

Level 5: Optimizing
...
This level includes all characteristics deﬁned for level 4
...
The results
of the questionnaire are distilled to a single numerical grade that provides an indication of an organization's process maturity
...

The KPAs describe those software engineering functions (e
...
, software project plan-

Every organization
should strive to
achieve the intent of
the SEI CMM
...

ning, requirements management) that must be present to satisfy good practice at a
particular level
...

•

Commitments—requirements (imposed on the organization) that must be met
to achieve the goals or provide proof of intent to comply with the goals
...

•

Activities—the speciﬁc tasks required to achieve the KPA function
...

•

Methods for verifying implementation—the manner in which proper practice
for the KPA can be veriﬁed
...
The following
KPAs should be achieved at each process maturity level:3
Process maturity level 2
• Software conﬁguration management
• Software quality assurance
3

Note that the KPAs are additive
...

26

PA R T O N E

THE PRODUCT AND THE PROCESS

• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management
Process maturity level 3
• Peer reviews

WebRef
A tabular version of the
complete SEI-CMM,
including all goals,
commitments, abilities, and
activities, is available at
sepo
...
mil/
CMMmatrices
...
The key practices are policies, procedures, and activities that must occur before
a key process area has been fully instituted
...
" Assessment questions are
designed to probe for the existence (or lack thereof) of a key indicator
...
3

S O F T WA R E P R O C E S S M O D E L S
To solve actual problems in an industry setting, a software engineer or a team of engi-

“Too often, software
work follows the
ﬁrst law of bicycling:
No matter where
you're going, it's
uphill and against
the wind
...
1
...
1
...
This strategy is often referred to as a process model or a software engineering paradigm
...
In an intriguing paper on the nature of the
software process, L
...
S
...

CHAPTER 2

27

THE PROCESS

F I G U R E 2
...
3a) in which four distinct stages are encountered: status quo, problem deﬁnition,
technical development, and solution integration
...
g
...
The generic software engineering phases and steps deﬁned in Section 2
...
2
easily map into these stages
...
It can be used at the macro level when the entire application is
considered, at a mid-level when program components are being engineered, and

28

PA R T O N E

THE PRODUCT AND THE PROCESS

even at the line of code level
...
In Figure 2
...

Realistically, it is difﬁcult to compartmentalize activities as neatly as Figure 2
...
Yet, this simpliﬁed 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 deﬁnition, technical develop-

All stages of a
software process—
status quo, problem
deﬁnition, technical
development, and
solution integration—
coexist simultaneously
at some level of detail
...
Given
the recursive nature of Figure 2
...

Raccoon [RAC95] suggests a “Chaos model” that describes “software development [as] a continuum from the user to the developer to the technology
...

In the sections that follow, a variety of different process models for software engineering are discussed
...
It is important to remember that each of the models has been characterized in a way that (ideally) assists in the control and coordination of a real software project
...

2
...
Figure 2
...
Modeled after a conventional engineering cycle, the linear sequential model encompasses
the following activities:
System/information engineering and modeling
...
This system view is essential when software must interact with other elements
such as hardware, people, and databases
...
A pattern is deﬁned and then
applied recursively at successively smaller scales; patterns fall inside patterns
...

CHAPTER 2

F I G U R E 2
...
Information engineering encompasses requirements gathering
at the strategic business level and at the business area level
...
The requirements gathering process is intensiﬁed and focused speciﬁcally on software
...
Requirements for both the system and the software are documented and reviewed with the customer
...
Software design is actually a multistep process that focuses on four distinct
attributes of a program: data structure, software architecture, interface representations, and procedural (algorithmic) detail
...

begins
...

Code generation
...

The code generation step performs this task
...

Testing
...
The testing process
focuses on the logical internals of the software, ensuring that all statements have
been tested, and on the functional externals; that is, conducting tests to uncover
errors and ensure that deﬁned input will produce actual results that agree with required
results
...
Software will undoubtedly undergo change after it is delivered to the customer (a possible exception is embedded software)
...
g
...
Software support/maintenance reapplies each of the
preceding phases to an existing program rather than a new one
...
However, criticism of the paradigm has caused even active
supporters to question its efﬁcacy [HAN95]
...

Real projects rarely follow the sequential ﬂow that the model proposes
...

As a result, changes can cause confusion as the project team proceeds
...

It is often difﬁcult for the customer to state all requirements explicitly
...

3
...
A working version of the program(s) will
not be available until late in the project time-span
...

In an interesting analysis of actual projects Bradac [BRA94], 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 team to complete dependent tasks
...

Each of these problems is real
...
It provides a template into
which methods for analysis, design, coding, testing, and support can be placed
...

While it does have weaknesses, it is signiﬁcantly better than a haphazard approach
to software development
...
5

THE PROTOTYPING MODEL
Often, a customer deﬁnes a set of general objectives for software but does not identify detailed input, processing, or output requirements
...
In these, and many
other situations, a prototyping paradigm may offer the best approach
...
5) begins with requirements gathering
...
A "quick design" then occurs
...
g
...
The quick design leads to the construction of

CHAPTER 2

31

THE PROCESS

F I G U R E 2
...
The prototype is evaluated by the customer/user and used to refine
requirements for the software to be developed
...

tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done
...

If a working prototype is built, the developer attempts to use existing program fragments or applies tools (e
...
, report generators, window managers) that enable working programs to be generated quickly
...
It may be too slow, too big, awkward
in use or all three
...
When a new system concept
or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the ﬁrst time
...
You will do that
...

The prototype can serve as "the ﬁrst system
...
But this may be an idealized view
...
Users get a feel for the actual system and

32

PA R T O N E

THE PRODUCT AND THE PROCESS

developers get to build something immediately
...

The customer sees what appears to be a working version of the software,
unaware that the prototype is held together “with chewing gum and baling
wire,” unaware that in the rush to get it working no one has considered overall software quality or long-term maintainability
...

Quality almost always
suffers as a result
...
Too often, software development management
relents
...

The developer often makes implementation compromises in order to get a
prototype working quickly
...

After a time, the developer may become familiar with these choices and forget all the reasons why they were inappropriate
...

Although problems can occur, prototyping can be an effective paradigm for software engineering
...
It is then discarded (at least in part) and the
actual software is engineered with an eye toward quality and maintainability
...
6

THE RAD MODEL
Rapid application development (RAD) is an incremental software development process
model that emphasizes an extremely short development cycle
...
If requirements are well understood and project scope is constrained, the RAD process enables a development team
to create a “fully functional system” within very short time periods (e
...
, 60 to 90 days)
[MAR91]
...
The information ﬂow among business functions is modeled in
a way that answers the following questions: What information drives the business
process? What information is generated? Who generates it? Where does the information go? Who processes it? Business modeling is described in more detail in Chapter 10
...
The information ﬂow deﬁned as part of the business modeling phase
is reﬁned into a set of data objects that are needed to support the business
...
6
The RAD
model

Team #3
Team #2

Team #1

Business
modeling

Business
modeling

Data
modeling

Process
modeling

Business
modeling

Data
modeling

Application
generation

Testing
&
turnover

Process
modeling

Data
modeling

Application
generation

Process
modeling

Testing
&
turnover

Application
generation

Testing
&
turnover

60–90 days

acteristics (called attributes) of each object are identiﬁed and the relationships between
these objects deﬁned
...

Process modeling
...

Processing descriptions are created for adding, modifying, deleting, or retrieving a
data object
...
RAD assumes the use of fourth generation techniques
(Section 2
...
Rather than creating software using conventional third generation
programming languages the RAD process works to reuse existing program components (when possible) or create reusable components (when necessary)
...

Testing and turnover
...
This reduces overall testing time
...

34

PA R T O N E

THE PRODUCT AND THE PROCESS

The RAD process model is illustrated in Figure 2
...
Obviously, the time constraints
imposed on a RAD project demand “scalable scope” [KER94]
...
Each major function can be addressed by a separate RAD team and then
integrated to form a whole
...

For further information
on component-based
development, see
Chapter 27
...

•

RAD requires developers and customers who are committed to the rapid-ﬁre
activities necessary to get a system complete in a much abbreviated time
frame
...

•

Not all types of applications are appropriate for RAD
...
If high performance is an issue and performance is to be
achieved through tuning the interfaces to system components, the RAD
approach may not work
...
This occurs when a new
application makes heavy use of new technology or when the new software
requires a high degree of interoperability with existing computer programs
...
7

E V O L U T I O N A R Y S O F T WA R E P R O C E S S M O D E L S
There is growing recognition that software, like all complex systems, evolves over a
period of time [GIL88]
...
In these and similar situations, software engineers need a process model that has been explicitly designed to
accommodate a product that evolves over time
...
4) is designed for straight-line development
...
The prototyping model (Section
2
...
In general, it is not designed to deliver a production system
...

CHAPTER 2

35

THE PROCESS

Evolutionary models are iterative
...

2
...
1

The Incremental Model

The incremental model combines elements of the linear sequential model (applied
repetitively) with the iterative philosophy of prototyping
...
7, the
incremental model applies linear sequences in a staggered fashion as calendar time
progresses
...
For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document production

The incremental model
delivers software in
small but usable pieces,
called “increments
...

functions in the ﬁrst increment; more sophisticated editing and document production
capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment
...

When an incremental model is used, the first increment is often a core product
...
The core product is used by the customer (or undergoes detailed review)
...
The plan addresses the modiﬁcation of the core
product to better meet the needs of the customer and the delivery of additional
features and functionality
...

System/information
engineering
Analysis

Increment 2

Increment 1

Design

Analysis

Increment 3

Design

Design

Analysis

Delivery of
2nd increment

Test

Code

Increment 4

F I G U R E 2
...
5) and other evolutionary approaches, is iterative in nature
...

model focuses on the delivery of an operational product with each increment
...

Incremental development is particularly useful when stafﬁng is unavailable for a
complete implementation by the business deadline that has been established for the
project
...
If the core product
is well received, then additional staff (if required) can be added to implement the next
increment
...
For
example, a major system might require the availability of new hardware that is under
development and whose delivery date is uncertain
...

2
...
2

The Spiral Model

The spiral model, originally proposed by Boehm [BOE88], is an evolutionary software
process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model
...
Using the spiral model, software is developed in a series of incremental releases
...
During later iterations,
increasingly more complete versions of the engineered system are produced
...
6 Typically, there are between three and six task regions
...
8 depicts a
spiral model that contains six task regions:
•

Customer communication—tasks required to establish effective communication between developer and customer
...

•

Framework activities
apply to every
software project you
undertake, regardless
of size or complexity
...

•

Engineering—tasks required to build one or more representations of the
application
...
g
...

6

The spiral model discussed in this section is a variation on the model proposed by Boehm
...
More recent discussion of Boehm’s
spiral model can be found in [BOE98]
...
8
A typical spiral
model

37

THE PROCESS

Planning
Customer
communication

Risk analysis

Project entry
point axis

Engineering

Customer
evaluation

Construction & release

Product maintenance projects
Product enhancement projects
New product development projects
Concept development projects

•

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
...
For small projects, the

? What is a
“task set”?

number of work tasks and their formality is low
...
In all cases, the umbrella activities (e
...
, software conﬁguration management and software quality assurance) noted in Section 2
...

As this evolutionary process begins, the software engineering team moves around
the spiral in a clockwise direction, beginning at the center
...
Each pass through the planning region
results in adjustments to the project plan
...
In addition, the project manager adjusts

Adaptable process model

the planned number of iterations required to complete the software
...
An alternative view of the spiral model can be considered by examining the project entry point
axis, also shown in Figure 2
...
Each cube placed along the axis can be used to represent the starting point for different types of projects
...
If the concept is to be developed into an actual product, the process
proceeds through the next cube (new product development project entry point) and
a “new development project” is initiated
...
In essence, the spiral, when characterized
in this way, remains operative until the software is retired
...
g
...

The spiral model is a realistic approach to the development of large-scale systems
and software
...
The spiral model
XRef
Evolutionary models,
such as the spiral
model, are particularly
well-suited to the
development of objectoriented systems
...

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
...
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 problematic
...
It may be difﬁcult to
convince customers (particularly in contract situations) that the evolutionary approach
is controllable
...
If a major risk is not uncovered and managed, problems will
undoubtedly occur
...
It will take a number of years before efﬁcacy of
this important paradigm can be determined with absolute certainty
...
7
...
7
...
The objective of this activity is to elicit project
requirements from the customer
...

Unfortunately, this rarely happens
...
Successful
negotiation occurs
when both sides
“win”
...

The best negotiations strive for a “win-win” result
...

7

Dozens of books have been written on negotiating skills (e
...
, [FIS91], [DON96], [FAR97])
...
Read one
...
9
The WINWIN
spiral model
[BOE98]
...
Identify stakeholders'
win conditions
1
...
Reconcile win conditions
3b
...
Evaluate process and
product alternatives and
resolve risks
7
...
Validate product and
process definitions

5
...
Rather than a single customer communication activity, the following activities are deﬁned:
1
...
”8

2
...
”

3
...

Negotiating skills

Successful completion of these initial steps achieves a win-win result, which becomes
the key criterion for proceeding to software and system deﬁnition
...
9
...

In essence, the anchor points represent three different views of progress as the
project traverses the spiral
...
For example, as part
of LCO, a set of objectives establishes the definition of top-level system/product
requirements
...
For example, as part of LCA, the software project team must demonstrate that it has evaluated
the applicability of off-the-shelf and reusable software components and considered
their impact on architectural decisions
...

40

PA R T O N E

THE PRODUCT AND THE PROCESS

anchor point and represents a set of objectives associated with the preparation of the
software for installation/distribution, site preparation prior to installation, and assistance required by all parties that will use or support the software
...
7
...
These are examples of trying to track
extremely complex sets of activities using overly simple models
...
[a
large] project is in the coding phase, there are personnel on the project involved in activities
typically associated with many phases of development simultaneously
...
personnel are writing requirements, designing, coding, testing, and integration testing
[all at the same time]
...
Kellner's more recent work [KEL91] uses statecharts [a notation that represents the states of a process] to represent the concurrent relationship existent among activities associated with a speciﬁc event (e
...
, a requirements change during late development),
but fails to capture the richness of concurrency that exists across all software development
and management activities in the project
...
[A concurrent process model] is driven by user needs, management decisions, and review results
...
For example, the engineering
activity deﬁned for the spiral model (Section 2
...
2) is accomplished by invoking the
following tasks: prototyping and/or analysis modeling, requirements speciﬁcation,
and design
...
10 provides a schematic representation of one activity with the concurrent process model
...
Similarly, other activities (e
...
, design or customer communication) can be represented in an analogous manner
...
For example, early in a project the customer communication
activity (not shown in the figure) has completed its first iteration and exists in the
awaiting changes state
...
If, however, the customer indicates that changes in
requirements must be made, the analysis activity moves from the under development state into the awaiting changes state
...
For example,
9 It should be noted that analysis and design are complex tasks that require substantial discussion
...

10 A state is some externally observable mode of behavior
...
10
One element of
the concurrent
process model

41

THE PROCESS

None
Analysis activity
Under
development
Awaiting
changes
Under review
Under
revision
Baselined

Done

Represents a state of a
software engineered activity

during early stages of design, an inconsistency in the analysis model is uncovered
...

The concurrent process model is often used as the paradigm for the development of client/server11 applications (Chapter 28)
...
When applied to client/server, the
concurrent process model defines activities in two dimensions [SHE94]: a system
dimension and a component dimension
...
The component dimension is addressed
with two activities: design and realization
...

In reality, the concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of a project
...

42

PA R T O N E

THE PRODUCT AND THE PROCESS

confining software engineering activities to a sequence of events, it defines a network of activities
...
Events generated within a given activity or at some other place in the activity
network trigger transitions among the states of an activity
...
8

COMPONENT-BASED DEVELOPMENT
Object-oriented technologies (Part Four of this book) provide the technical framework for a component-based process model for software engineering
...
If properly designed and implemented,
object-oriented classes are reusable across different applications and computer-based
system architectures
...
11) incorporates many

XRef
The underlying
technology for CBD is
discussed in Part Four
of this book
...

of the characteristics of the spiral model
...
However, the component-based
development model composes applications from prepackaged software components
(called classes)
...
This
is accomplished by examining the data to be manipulated by the application and the
algorithms that will be applied to accomplish the manipulation
...

F I G U R E 2
...
For a more detailed discussion, see Chapter 20
...
Once candidate classes are identified, the class
library is searched to determine if these classes already exist
...
If a candidate class does not reside in the
library, it is engineered using object-oriented methods (Chapters 21–23)
...
Process flow then returns to the spiral and will ultimately re-enter the
component assembly iteration during subsequent passes through the engineering activity
...
Based on studies of reusability, QSM Associates, Inc
...
2, compared to an industry norm of 16
...
[YOU94]
Although these results are a function of the robustness of the component library, there
is little question that the component-based development model provides signiﬁcant
advantages for software engineers
...

The uniﬁed software development process [JAC99] is representative of a number of
component-based development models that have been proposed in the industry
...
Using a combination of iterative and incremental development, the uniﬁed process deﬁnes the function of the system by applying a scenario-based approach
(from the user point of view)
...

2
...

THE FORMAL METHODS MODEL
The formal methods model encompasses a set of activities that leads to formal mathematical speciﬁcation of computer software
...
A variation on this approach, called cleanroom software engineering [MIL87, DYE92], is currently applied by some software development organizations
...
Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily, not through
ad hoc review but through the application of mathematical analysis
...

Although it is not destined to become a mainstream approach, the formal methods model offers the promise of defect-free software
...

The development of formal models is currently quite time consuming and
expensive
...

Because few software developers have the necessary background to apply
formal methods, extensive training is required
...

It is difﬁcult to use the models as a communication mechanism for technically unsophisticated customers
...
g
...

2
...
The tool then automatically generates source code based on the developer's specification
...
The 4GT paradigm for software engineering
focuses on the ability to specify software using specialized language forms or a
graphic notation that describes the problem to be solved in terms that the customer can understand
...
Initially, many of the tools noted previously were available only for
very speciﬁc application domains, but today 4GT environments have been extended
to address most software application categories
...
Ideally, the
customer would describe requirements and these would be directly translated into
an operational prototype
...
The customer may be unsure of
what is required, may be ambiguous in specifying facts that are known, and may be
unable or unwilling to specify information in a manner that a 4GT tool can consume
...

For small applications, it may be possible to move directly from the requirements
gathering step to implementation using a nonprocedural fourth generation language
(4GL) or a model composed of a network of graphical icons
...

efforts, it is necessary to develop a design strategy for the system, even if a 4GL is to
be used
...

Implementation using a 4GL enables the software developer to represent desired
results in a manner that leads to automatic generation of code to create those results
...

To transform a 4GT implementation into a product, the developer must conduct
thorough testing, develop meaningful documentation, and perform all other solution
integration activities that are required in other software engineering paradigms
...

Like all software engineering paradigms, the 4GT model has advantages and disadvantages
...
Opponents claim that
current 4GT tools are not all that much easier to use than programming languages,
that the resultant source code produced by such tools is "inefficient," and that the
maintainability of large software systems developed using 4GT is open to question
...

The use of 4GT is a viable approach for many different application areas
...

2
...

3
...

To summarize, fourth generation techniques have already become an important
part of software engineering
...
8), the 4GT paradigm may become the dominant approach to
software development
...
11

THE PRODUCT AND THE PROCESS

PROCESS TECHNOLOGY
The process models discussed in the preceding sections must be adapted for use by
a software project team
...

Process technology tools allow a software organization to build an automated
model of the common process framework, task sets, and umbrella activities discussed
in Section 2
...
The model, normally represented as a network, can then be analyzed
to determine typical work ﬂow and examine alternative process structures that might
lead to reduced development time or cost
...
Each member of a software project team can use such
tools to develop a checklist of work tasks to be performed, work products to be produced, and quality assurance activities to be conducted
...

2
...
In a brief essay, Margaret Davis [DAV95] comments on the duality of product and process:
About every ten years, give or take ﬁve, the software community redeﬁnes "the problem"
by shifting its focus from product issues to process issues
...

“[If it is developed
thoughtlessly and
applied mindlessly,
process can
become] the death
of common sense
...
Howard

While the natural tendency of a pendulum is to come to rest at a point midway between
two extremes, the software community's focus constantly shifts because new force is
applied when the last swing fails
...
The swings also do not solve "the problem" for they
are doomed to fail as long as product and process are treated as forming a dichotomy
instead of a duality
...
The dual nature of light, which seems to be simultaneously particle and wave,
has been accepted since the 1920's when Louis de Broglie proposed it
...
You can never derive or understand
the full artifact, its context, use, meaning, and worth if you view it as only a process or
only a product
...
That is, we derive feelings of satisfaction from reuse of our products by ourselves or others
...
Thinking of a reusable
artifact as only product or only process either obscures the context and ways to use it or
obscures the fact that each use results in product that will, in turn, be used as input to some
other software development activity
...

People derive as much (or more) satisfaction from the creative process as they do
from the end product
...

"Any activity becomes
creative when the
doer cares about
doing it right, or
doing it better
...
A
creative software professional should also derive as much satisfaction from the process
as the end-product
...
The duality of product and process is one important element in keeping creative people engaged as the
transition from programming to software engineering is ﬁnalized
...
13

SUMMARY
Software engineering is a discipline that integrates process, methods, and tools for
the development of computer software
...
The principles, concepts, and
methods that enable us to perform the process that we call software engineering are
considered throughout the remainder of this book
...
, H
...
85
...
et al
...
Software Engineering, vol
...
5, May 1995, pp
...

[BOE88] Boehm, B
...
21, no
...
61–72
...
, “Anchoring the Software Process,” IEEE Software, vol
...

4, July 1996, pp
...

[BOE98] Boehm, B
...
31, no
...
33–44
...
, D
...
Votta, “Prototyping a Process Monitoring
Experiment,” IEEE Trans
...
SE-20, no
...
774–784
...
, The Mythical Man-Month, Addison-Wesley, 1975
...
, “Rapid Application Development in Action,” Managing System
Development, Applied Computer Research, vol
...
5, May 1994, pp
...

[DAV94] Davis, A
...
Sitaram, “A Concurrent Process Model for Software
Development,” Software Engineering Notes, ACM Press, vol
...
2, April 1994,
pp
...

[DAV95] Davis, M
...
, “Process and Product: Dichotomy or Duality,” Software Engineering Notes, ACM Press, vol
...
2, April 1995, pp
...

[DON96] Donaldson, M
...
and M
...

[DYE92] Dyer, M
...

[FAR97] Farber, D
...
, Common Sense Negotiation: The Art of Winning Gracefully,
Bay Press, 1997
...
, W
...
Patton, Getting to Yes: Negotiating Agreement

Without Giving In, 2nd edition, Penguin USA, 1991
...
, Principles of Software Engineering Management, Addison-Wesley,

1988
...
, “Farewell to Waterfalls,” Software Magazine, May 1995, pp
...

[HUM89] Humphrey, W
...
Kellner, “Software Process Modeling: Principles of
Entity Process Models,” Proc
...
Conference on Software Engineering, IEEE
Computer Society Press, pp
...

[IEE93]

IEEE Standards Collection: Software Engineering, IEEE Standard 610
...

[JAC99]

Jacobson, I, Booch, G
...
Rumbaugh, The Uniﬁed Software Develop-

ment Process, Addison-Wesley, 1999
...
, Software Process Modeling: Value and Experience, SEI Technical Review—1989, SEI, 1989
...
, “Software Process Modeling Support for Management Planning and Control,” Proc
...
Conf
...
8–28
...
and R
...

[MAR91] Martin, J
...

[MDE93] McDermid, J
...
Rook, “Software Development Process Models,” in
Software Engineer’s Reference Book, CRC Press, 1993, pp
...

[MIL87] Mills, H
...
, M
...
Linger, “Cleanroom Software Engineering,”
IEEE Software, September 1987, pp
...

CHAPTER 2

THE PROCESS

49

[NAU69] Naur, P
...
Randall (eds
...

[NIE92]

Nierstrasz, O
...
Gibbs, and D
...
35, no
...
160–165
...
et al
...

[RAC95] Raccoon, L
...
S
...
20
...
1, January, 1995, pp
...

[ROY70] Royce, W
...
, “Managing the Development of Large Software Systems:
Concepts and Techniques,” Proc
...

[SHE94] Sheleg, W
...
1, no
...
28–33
...
, “Software Reuse,” Application Development Strategies, vol
...
12, December 1994, pp
...

PROBLEMS AND POINTS TO PONDER
2
...
Figure 2
...
This implies an organization quality program such as Total Quality Management
...

2
...
Is there ever a case when the generic phases of the software engineering process
don't apply? If so, describe it
...
3
...
Do some research
and determine if any new KPAs have been added since the publication of this book
...
4
...
Discuss the way in which you would apply the loop to (1) understand requirements for a word-processing product; (2) develop an advanced spelling/
grammar checking component for the word processor; (3) generate code for a program module that determines the subject, predicate, and object in an English language sentence
...
5
...
6
...
Name two or three applications that would be more difficult to
prototype
...
7
...
Research the literature and provide
a summary of a typical CASE tool that supports RAD
...
8
...
Present a scenario for applying the model to the software
...
9
...
10
...
Find three or four recent papers on the subject and summarize
them for the class
...
11
...

2
...
Provide three examples of fourth generation techniques
...
13
...
Industry periodicals such as Application Development Trends,
Cutter IT Journal and Software Development often contain articles on software engineering topics
...

Many software engineering books have been published in recent years
...
Three anthologies that cover a wide range of software
engineering topics are
Keyes, J
...
), Software Engineering Productivity Handbook, McGraw-Hill, 1993
...
, (ed
...

Marchiniak, J
...
(ed
...

Gautier (Distributed Engineering of Software, Prentice-Hall, 1996) provides suggestions
and guidelines for organizations that must develop software across geographically
dispersed locations
...
Pressman and Herron (Software Shock, Dorset House, 1991) consider
software and its impact on individuals, businesses, and government
...
Practitioners from industry, government, and academia are contribut-

CHAPTER 2

THE PROCESS

51

ing important new work
...

A wide variety of software engineering standards and procedures have been published over the past decade
...
ISO 9000-3
guidelines provide guidance for software organizations that require registration to
the ISO 9001 quality standard
...
Fairclough (Software Engineering Guides, Prentice-Hall, 1996) provides a
detailed reference to software engineering standards produced by the European Space
Agency (ESA)
...
An up-to-date list of World Wide Web references
that are relevant to the software process can be found at the SEPA Web site:
http://www
...
com/engcs/compsci/pressman/resources/process
...
In the chapters that
follow, you’ll get answers to the following questions:

I

• How must the people, process, and problem be managed
during a software project?
• What are software metrics and how can they be used to
manage a software project and the software process?
• How does a software team generate reliable estimates of
effort, cost, and project duration?
• What techniques can be used to formally assess the risks
that can have an impact on project success?
• How does a software project manager select the set of
software engineering work tasks?
• How is a project schedule created?
• How is quality deﬁned so that it can be controlled?
• What is software quality assurance?
• Why are formal technical reviews so important?
• How is change managed during the development of
computer software and after delivery 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
...
74
common process
framework
...
65
problem
decomposition
...
70
scope
...
60
team leader
...
60
team toxicity
...
73

QUICK
LOOK

n the preface to his book on software project management, Meiler Page-

I

Jones [PAG85] makes a statement that can be echoed by many software
engineering 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
...

What Page-Jones describes are symptoms that result from an array of management and technical problems
...

In this chapter and the six that follow, we consider the key concepts that
lead to effective software project management
...
Chapter 4 presents
process and project metrics, the basis for effective management decision making
...
The man-

What is it? Although many of us
(in our darker moments) take Dil-

coordinate the interface between the business and
the software professionals
...
Project

many people working over a relatively long time
...

and control of the people, process, and events that

What are the steps? Understand the four P’s—peo-

occur as software evolves from a preliminary con-

ple, product, process, and project
...

organized to perform software work effectively
...
A software engineer man-

stood
...
The project

toring, and controlling technical tasks
...
Senior managers

products, establishing quality checkpoints, and

55

56

PA R T T W O

QUICK
LOOK

M A N A G I N G S O F T WA R E P R O J E C T S

establishing mechanisms to mon-

How do I ensure that I’ve done it right? You’re

itor and control work deﬁned by

never completely sure that the project plan is right

the plan
...
However, a project man-

duced as management activities commence
...

change, and evaluating quality
...
Chapter 7 discusses the activities that are required to
define project tasks and establish a workable project schedule
...

3
...
The order is not arbitrary
...
A manager who fails to encourage comprehensive customer
communication early in the evolution of a project risks building an elegant solution
for the wrong problem
...
The manager
who embarks without a solid project plan jeopardizes the success of the product
...
1
...
”
Bill Curtis

The People

The cultivation of motivated, highly skilled software people has been discussed since
the 1960s (e
...
, [COU80], [WIT94], [DEM98])
...

The people management maturity model deﬁnes the following key practice areas
for software people: recruiting, selection, performance management, training, compensation, career development, organization and work design, and team/culture
development
...

The PM-CMM is a companion to the software capability maturity model (Chapter 2) that guides organizations in the creation of a mature software process
...

3
...
2
XRef
A taxonomy of
application areas that
spawn software
“products” is discussed
in Chapter 1
...
Without this information, it is impossible to deﬁne reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic
breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress
...
In many cases, this activity begins as part of the system engineering or business process engineering (Chapter 10) and continues as the first step in software
requirements analysis (Chapter 11)
...
Scope identiﬁes the primary data, functions and behaviors that characterize the product, and more important, attempts to bound these characteristics in a
quantitative manner
...
Although very little detail is discussed, the alternatives enable managers
and practitioners to select a "best" approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces, and
myriad other factors
...
1
...

The Product

The Process

A software process (Chapter 2) provides the framework from which a comprehensive plan for software development can be established
...
A number of different task sets—tasks, milestones, work products, and
quality assurance points—enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team
...
Umbrella activities are independent of any one framework activity and occur throughout the process
...
1
...
And yet, we still struggle
...
Although the success rate for

1

In this context, the term product is used to encompass any software that is to be built at the
request of others
...
g
...

58

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

software projects has improved somewhat, our project failure rate remains higher
than it should be
...
Each of
these issues is discussed in Section 3
...

3
...
They answered in the following way:
VP 1: I guess if you had to pick one thing out that is most important in our environment,

“Companies that
sensibly manage
their investment in
people will prosper
in the long run
...

VP 2: The most important ingredient that was successful on this project was having
smart people
...
The most important
thing you do for a project is selecting the staff
...

VP 3: The only rule I have in management is to ensure I have good people—real good
people—and that I grow good people—and that I provide an environment in
which good people can produce
...
And yet, all of us, from senior engineering vice presidents to
the lowliest practitioner, often take people for granted
...
In this section we examine the players who participate in the software process
and the manner in which they are organized to perform effective software engineering
...
2
...
Senior managers who deﬁne the business issues that often have signiﬁcant
inﬂuence on the project
...
Part of the
answer, I think, is that a substantial number of these “failed” projects are ill-conceived in the ﬁrst
place
...

CHAPTER 3

PROJECT MANAGEMENT CONCEPTS

59

2
...

3
...

4
...

5
...

Every software project is populated by people who fall within this taxonomy
...
And that’s the job of the team leader
...
2
...
They simply don’t have the right mix of
people skills
...
” [EDG95]
In an excellent book of technical leadership, Jerry Weinberg [WEI86] suggests a
MOI model of leadership:
Motivation
...

Organization
...

“In simplest terms,
a leader is one who
knows where he
wants to go, and
gets up, and goes
...
The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application
...
That is, a software project manager should concentrate on understanding the problem to be solved, managing the ﬂow of ideas, and at the same time, letting
everyone on the team know (by words and, far more important, by actions) that quality counts and that it will not be compromised
...
An effective software project manager can diagnose the
technical and organizational issues that are most relevant, systematically structure a solution or properly motivate other practitioners to develop the solution, apply lessons learned from past projects to new situations, and remain

60

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

ﬂexible enough to change direction if initial attempts at problem solution are
fruitless
...
A good project manager must take charge of the project
...

A software wizard may
not have the
temperament or desire
to be a team leader
...

Achievement
...

Inﬂuence and team building
...
The manager must
remain under control in high-stress situations
...
2
...
For better or worse, organi-

“Not every group is a
team, and not every
team is effective
...
Concern with the practical and political
consequences of organizational change are not within the software project manager's scope of responsibility
...

The following options are available for applying human resources to a project that
will require n people working for k years:
1
...

2
...

3
...

? How should a
software
team be organized?

Although it is possible to voice arguments for and against each of these approaches,
a growing body of evidence indicates that a formal team organization (option 3) is
most productive
...
Mantei [MAN81] suggests three generic team
organizations:

CHAPTER 3

PROJECT MANAGEMENT CONCEPTS

61

Democratic decentralized (DD)
...
Rather, "task coordinators are appointed for short durations and
then replaced by others who may coordinate different tasks
...
Communication among team
members is horizontal
...
This software engineering team has a deﬁned
leader who coordinates speciﬁc tasks and secondary leaders that have responsibility for subtasks
...

Communication among subgroups and individuals is horizontal
...

Controlled Centralized (CC)
...
Communication between the leader
and team members is vertical
...

•

The size of the resultant program(s) in lines of code or function points
(Chapter 4)
...

•

The degree to which the problem can be modularized
...

•

The rigidity of the delivery date
...

Because a centralized structure completes tasks faster, it is the most adept at handling simple problems
...
Therefore such teams have a greater probability of success when working on difﬁcult problems
...
A DD structure is best for difﬁcult problems
...

with a CC or CD structures when subgrouping can be easily accommodated
...
It has
been found that DD team structures result in high morale and job satisfaction and
are therefore good for teams that will be together for a long time
...
When high modularity is
possible (and people can do their own thing), the CC or CD structure will work well
...
Decentralized teams generally require more time to complete a
project than a centralized structure and at the same time are best when high sociability is required
...
A closed paradigm structures a team along a traditional hierarchy of authority (similar to a CC team)
...
”
Peter Drucker

innovative when working within the closed paradigm
...
The random paradigm structures a team loosely and depends on individual
initiative of the team members
...
But
such teams may struggle when “orderly performance” is required
...
The open paradigm attempts to structure a team in a manner that achieves
some of the controls associated with the closed paradigm but also much of
the innovation that occurs when using the random paradigm
...
Open paradigm
team structures are well suited to the solution of complex problems but may
not perform as efﬁciently as other teams
...
The synchronous paradigm relies on the natural compartmentalization of a
problem and organizes team members to work on pieces of the problem with
little active communication among themselves
...
This structure
was ﬁrst proposed by Harlan Mills and described by Baker [BAK72]
...
See
Chapter 9 for details
...

The chief programmer may be served by one or more specialists (e
...
, telecommunications expert, database designer), support staff (e
...
, technical writers, clerical
personnel), and a software librarian
...
e
...
The
importance of a librarian cannot be overemphasized
...

A variation on the democratic decentralized team has been proposed by Constantine [CON93], who advocates teams with creative independence whose approach
to work might best be termed innovative anarchy
...
To achieve a

“No matter what the
problem is, it’s
always a people
problem
...

•

The distribution of skills must be appropriate to the problem
...

Regardless of team organization, the objective for every project manager is to help
create a team that exhibits cohesiveness
...
" But many of these groups just don't seem like teams
...
What is
missing is a phenomenon that we call jell
...

Once a team begins to jell, the probability of success goes way up
...
They don't need to be managed in the traditional
way, and they certainly don't need to be motivated
...

DeMarco and Lister contend that members of jelled teams are signiﬁcantly more productive and more motivated than average
...
At a
minimum, be certain
to avoid a “toxic
environment
...

But not all teams jell
...
She deﬁnes ﬁve factors that “foster a potentially toxic team environment”:
1
...

2
...

3
...

64

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

4
...

5
...

Jackman suggests a number of antitoxins that address these all-too-common
problems
...
In
addition, bad news should not be kept secret but rather, delivered to the team as early
as possible (while there is still time to react in a rational and controlled manner)
...
A software team can avoid frustration if it is
given as much responsibility for decision making as possible
...

An inappropriately chosen software process (e
...
, unnecessary or burdensome
work tasks or poorly chosen work products) can be avoided in two ways: (1) being
certain that the characteristics of the software to be built conform to the rigor of the
process that is chosen and (2) allowing the team to select the process (with full recognition that, once chosen, the team has the responsibility to deliver a high-quality
product)
...
The team itself should estab-

“Do or do not; there
is no try
...

Every software team experiences small failures
...
In addition, failure by any member of the team must be viewed as a failure
by the team itself
...

In addition to the ﬁve toxins described by Jackman, a software team often struggles with the differing human traits of its members
...
Some people gather information intuitively, distilling
broad concepts from disparate facts
...
Some team members are comfortable making decisions only when a logical, orderly argument is presented
...
” Some practitioners want

3

Formal technical reviews are discussed in detail in Chapter 8
...
Others prefer a more spontaneous environment
in which open issues are okay
...
A detailed discussion of the
psychology of these traits and the ways in which a skilled team leader can help people with opposing traits to work together is beyond the scope of this book
...

3
...
4

Coordination and Communication Issues

There are many reasons that software projects get into trouble
...
Uncertainty is common, resulting in a continuing stream of changes that ratchets the project team
...
New software must communicate with existing
software and conform to predeﬁned constraints imposed by the system or product
...
To deal with them effectively, a software engineering team must
establish effective methods for coordinating the people who do the work
...
Formal communication
is accomplished through “writing, structured meetings, and other relatively noninteractive and impersonal communication channels” [KRA95]
...
Members of a software team share ideas on an ad hoc basis,
ask for help as problems arise, and interact with one another on a daily basis
...

? How do we
coordinate

Formal, interpersonal procedures focus on quality assurance activities

the actions of
team members?

(Chapter 8) applied to software engineering work products
...

Informal, interpersonal procedures include group meetings for information dissemination and problem solving and “collocation of requirements and
development staff
...

66

PA R T T W O

F I G U R E 3
...

Interpersonal networking includes informal discussions with team members
and those outside the project who may have experience or insight that can assist
team members
...
Figure 3
...

Referring to ﬁgure, the perceived value (rated on a seven point scale) of various coordination and communication techniques is plotted against their frequency of use on
a project
...
Techniques that fell below
the line were perceived to have less value
...
It is also important to note that early software quality assurance mechanisms
(requirements and design reviews) were perceived to have more value than later
evaluations of source code (code inspections)
...
3

PROJECT MANAGEMENT CONCEPTS

67

THE PRODUCT
A software project manager is confronted with a dilemma at the very beginning of a
software engineering project
...
A detailed analysis of software requirements would provide necessary information for estimates, but analysis often takes
weeks or months to complete
...
Yet, a plan is needed "now!"
Therefore, we must examine the product and the problem it is intended to solve
at the very beginning of the project
...

3
...
1 Software Scope
The ﬁrst software project management activity is the determination of software scope
...
How does the software to be built ﬁt into a larger system, product, or
business context and what constraints are imposed as a result of the context?

If you can’t bound a
characteristic of the
software you intend to
build, list the
characteristic as a
major project risk
...
What customer-visible data objects (Chapter 11) are
produced as output from the software? What data objects are required for input?
Function and performance
...
A statement of software scope must be bounded
...
g
...
g
...
g
...

3
...
2

Problem Decomposition

Problem decomposition, sometimes called partitioning or problem elaboration, is an
activity that sits at the core of software requirements analysis (Chapter 11)
...
Rather,

In order to develop a
reasonable project
plan, you have to
functionally
decompose the
problem to be solved
...

Human beings tend to apply a divide and conquer strategy when they are confronted with a complex problems
...
This is the strategy that applies as
project planning begins
...
Because both cost and schedule estimates are functionally oriented, some
degree of decomposition is often useful
...

XRef
A useful technique for
problem decomposition,
called a grammatical
parse, is presented in
Chapter 12
...
The project manager must ﬁrst
establish a statement of scope that bounds these features (as well as other more mundane functions such as editing, ﬁle management, document production, and the like)
...
The
project team learns that the marketing department has talked with potential customers and found that the following functions should be part of automatic copy editing: (1) spell checking, (2) sentence grammar checking, (3) reference checking for
large documents (e
...
, Is a reference to a bibliography entry found in the list of entries
in the bibliography?), and (4) section and chapter reference validation for large documents
...
Each can be further reﬁned if the decomposition will make planning easier
...
4

THE PROCESS
The generic phases that characterize the software process—deﬁnition, development,
and support—are applicable to all software
...
In Chapter 2, a wide array of software engineering paradigms were discussed:
•
•

the prototyping model

•

Once the process
model is chosen,
populate it with the
minimum set of work
tasks and work
products that will result
in a high-quality
product—avoid
process overkill!

the linear sequential model

the RAD model

•

the incremental model

•

the spiral model

•

the WINWIN spiral model

•

the component-based development model

•

the concurrent development model

•

the formal methods model

•

the fourth generation techniques model

The project manager must decide which process model is most appropriate for (1)
the customers who have requested the product and the people who will do the work,

CHAPTER 3

PROJECT MANAGEMENT CONCEPTS

69

(2) the characteristics of the product itself, and (3) the project environment in which
the software team works
...
Once the preliminary plan is established, process decomposition begins
...
We explore these activities brieﬂy in the sections that
follow and present a more detailed view in Chapter 7
...
4
...
Each function to be engineered by the software team must pass through the set of framework
activities that have been deﬁned for a software organization
...

•

Remember :
framework activities
are applied on every
project—no
exceptions
...

•

Risk analysis—tasks required to assess both technical and management risks
...

•

Construction and release—tasks required to construct, test, install, and provide user support (e
...
, documentation and training)
...

The team members who work on a product function will apply each of the framework activities to it
...
2 is
created
...

cessing software discussed earlier) is listed in the left-hand column
...
Software engineering work tasks (for each framework activity) would be entered in the following row
...
These activities are considered in
Chapters 5 and 7
...
Framework
activities always remain the same, but work tasks will be selected based on a number of adaptation criteria
...

er
ing

Common process
framework activities

En
gin
e

F I G U R E 3
...
4
...
A relatively small project
that is similar to past efforts might be best accomplished using the linear sequential
approach
...
If the deadline is so
tight that full functionality cannot reasonably be delivered, an incremental strategy
might be best
...
g
...
6
Once the process model has been chosen, the common process framework (CPF)

Always apply the CPF,
regardless of project
size, criticality, or type
...

is adapted to it
...
It will work for linear models, for
iterative and incremental models, for evolutionary models, and even for concurrent
or component assembly models
...

But actual work tasks do vary
...
See Section 3
...
3
...
Develop list of clariﬁcation issues
...
Meet with customer to address clariﬁcation issues
...
Jointly develop a statement of scope
...
Review the statement of scope with all concerned
...
Modify the statement of scope as required
...
They represent a process
decomposition that is appropriate for the small, relatively simple project
...
Such a project might require the following work tasks for
the customer communication activity:
Adaptable process model

1
...

2
...

3
...

4
...

5
...

6
...

7
...

8
...

9
...

10
...

Both projects perform the framework activity that we call “customer communication,” but the ﬁrst project team performed half as many software engineering work
tasks as the second
...
5

THE PROJECT
In order to manage a successful software project, we must understand what can go

“At least 7 of 10
signs of IS project
failures are
determined before a
design is developed
or a line of code is
written
...
In an excellent paper
on software projects, John Reel [REE99] deﬁnes ten signs that indicate that an information systems project is in jeopardy:
1
...

2
...

3
...

72

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

4
...

5
...

6
...

7
...

8
...

9
...

10
...

Jaded industry professionals often refer to the 90–90 rule when discussing particularly difﬁcult software projects: The ﬁrst 90 percent of a system absorbs 90 percent
of the allotted effort and time
...
The seeds that lead to the 90–90 rule are contained
in the signs noted in the preceeding list
...
Start on the right foot
...
It
is reinforced by building the right team (Section 3
...
3) and giving the team
the autonomy, authority, and technology needed to do the job
...
Maintain momentum
...
To maintain momentum, the project manager must pro-

A broad array of resources
that can help both
neophyte and experienced
project managers can be
found at
www
...
org,
www
...
com, and
www
...
com

vide incentives to keep turnover of personnel to an absolute minimum, the
team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way
...
Track progress
...
g
...
In addition, software process and project measures (Chapter 4) can
be collected and used to assess progress against averages developed for the
software development organization
...
Make smart decisions
...
” Whenever possible,
decide to use commercial off-the-shelf software or existing software components, decide to avoid custom interfaces when standard approaches are

7

The implication of this statement is that bureacracy is reduced to a minimum, extraneous meetings are eliminated, and dogmatic adherence to process and project rules is eliminated
...

CHAPTER 3

PROJECT MANAGEMENT CONCEPTS

73

available, decide to identify and then avoid obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks (you’ll
need every minute)
...
Conduct a postmortem analysis
...
Evaluate the planned and actual
schedules, collect and analyze software project metrics, get feedback from
team members and customers, and record ﬁndings in written form
...
6

THE W5HH PRINCIPLE
In an excellent paper on software process and projects, Barry Boehm [BOE96] states:
“you need an organizing principle that scales down to provide simple [project] plans for
simple projects
...
He calls it the WWWWWHH principle, after a series of questions that
lead to a deﬁnition of key project characteristics and the resultant project plan:

?

What
questions
need to be
answered in order
to develop a
project plan?

Why is the system being developed? The answer to this question enables
all parties to assess the validity of business reasons for the software work
...

Who is responsible for a function? Earlier in this chapter, we noted that the
role and responsibility of each member of the software team must be deﬁned
...

Where are they organizationally located? Not all roles and responsibilities
reside within the software team itself
...

How will the job be done technically and managerially? Once product
scope is established, a management and technical strategy for the project must
be deﬁned
...

Boehm’s W5HH principle is applicable regardless of the size or complexity of a software project
...

74

PA R T T W O

3
...
” These practices are “consistently used by, and considered
critical by, highly successful software projects and organizations whose ‘bottom line’
performance is consistently much better than industry averages” [AIR99]
...
What are the top ten risks for this project? For
each of the risks, what is the chance that the risk will become a problem and
what is the impact if it does?
Empirical cost and schedule estimation
...
Do you have in place a metrics program to give an early indication of evolving problems? If so, what is the current requirements volatility?

Airlie Project Quicklook

Earned value tracking
...
Do you track and periodically report
the number of defects found by each inspection (formal technical review) and
execution test from program inception and the number of defects currently
closed and open?
People-aware program management
...
Each of the critical practices just noted is addressed in detail throughout Part Two of this book
...
8

SUMMARY
Software project management is an umbrella activity within software engineering
...

8

9

The Airlie Council is a team of software engineering experts chartered by the U
...
Department of
Defense to help develop guidelines for best practices in software project management and software engineering
...
Other best practices will be discussed in later chapters
...
People must be organized into effective teams, motivated to do high-quality software work, and coordinated to achieve effective communication
...
The process must be adapted to the people and the problem
...
Finally,
the project must be organized in a manner that enables the software team to succeed
...
Software engineers can be
organized in a number of different team structures that range from traditional control hierarchies to “open paradigm” teams
...
In general, formal
reviews and informal person-to-person communication have the most value for practitioners
...
Each of these topics is considered in the chapters that follow
...

[BAK72] Baker, F
...
, "Chief Programmer Team Management of Production Programming," IBM Systems Journal, vol
...
1, 1972, pp
...

[BOE96] Boehm, B
...
13, no
...
73–82
...
, “Work Organization: Paradigms for Project Management
and Organization, CACM, vol
...
10, October 1993, pp
...

[COU80] Cougar, J
...
Zawacki, Managing and Motivating Computer Personnel,
Wiley, 1980
...
et al
...
Software Engineering, vol
...
11, November 1988, pp
...

[CUR94] Curtis, B
...
, People Management Capability Maturity Model, Software
Engineering Institute, 1994
...
and T
...
, Dorset House, 1998
...
, “Right Stuff: How to Recognize It When Selecting a Project
Manager,” Application Development Trends, vol
...
5, May 1995, pp
...

[FER98] Ferdinandi, P
...
, “Facilitating Communication,” IEEE Software, September
1998, pp
...

76

PA R T T W O

[JAC98]

M A N A G I N G S O F T WA R E P R O J E C T S

Jackman, M
...
43–45
...
and L
...
38, no
...
69–81
...
, "The Effect of Programming Team Structures on Programming
Tasks," CACM, vol
...
3, March 1981, pp
...

[PAG85] Page-Jones, M
...
vii
...
S
...
18–23
...
, On Becoming a Technical Leader, Dorset House, 1986
...
, Managing Software Maniacs, Wiley, 1994
...
, “Timeboxing for Top Team Performance,” Software Development, March 1994, pp
...

PROBLEMS AND POINTS TO PONDER
3
...
Based on information contained in this chapter and your own experience, develop
“ten commandments” for empowering software engineers
...

3
...
The Software Engineering Institute’s people management capability maturity
model (PM-CMM) takes an organized look at “key practice areas” that cultivate good
software people
...

3
...
Describe three real-life situations in which the customer and the end-user are
the same
...

3
...
The decisions made by senior management can have a signiﬁcant impact on
the effectiveness of a software engineering team
...

3
...
Review a copy of Weinberg’s book [WEI86] and write a two- or three-page summary of the issues that should be considered in applying the MOI model
...
6
...
Your job is to build an application that is quite similar to others your
team has built, although this one is larger and more complex
...
What team structure would you choose
and why? What software process model(s) would you choose and why?
3
...
You have been appointed a project manager for a small software products company
...
Because competition for the home entertainment
market is intense, there is signiﬁcant pressure to get the job done
...
8
...
Your job is to manage the development of the next generation version of its
widely used word-processing software
...
What team structure would you choose
and why? What software process model(s) would you choose and why?
3
...
You have been appointed a software project manager for a company that services the genetic engineering world
...
The work is R&D oriented, but the goal to to produce a product within the next year
...
10
...
1, based on the results of the referenced study, documents are perceived to have more use than value
...
11
...
Write a statement of scope that bounds this problem
...
12
...
3
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
An excellent four volume series written by Weinberg (Quality Software Management,
Dorset House, 1992, 1993, 1994, 1996) introduces basic systems thinking and management concepts, explains how to use measurements effectively, 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
...
Brooks (The Mythical Man-Month,
Anniversary Edition, Addison-Wesley, 1995) has updated his classic book to provide
new insight into software project and management issues
...
Bennatan (Software Project
Management in a Client/Server Environment, Wiley, 1995) discusses special management issues associated with the development of client/server systems
...
The definitive book on this subject has been written by

78

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

DeMarco and Lister [DEM98], but the following books on this subject have been published in recent years and are worth examining:
Beaudouin-Lafon, M
...

Carmel, E
...

Humphrey, W
...
, Managing Technical People: Innovation, Teamwork, and the Software Process,
Addison-Wesley, 1997
...
S
...

Jones, P
...
, Handbook of Team Design: A Practitioner's Guide to Team Systems Development,
McGraw-Hill, 1997
...
S
...

Mayer, M
...

Another excellent book by Weinberg [WEI86] is must reading for every project
manager and every team leader
...
House (The Human Side of Project Management, AddisonWesley, 1988) and Crosby (Running Things: The Art of Making Things Happen, McGrawHill, 1989) provide practical advice for managers who must deal with human as well
as technical problems
...

A wide variety of information sources on software project issues are available on
the Internet
...
mhhe
...
mhtml

CHAPTER

4
KEY
CONCEPTS
backﬁring
...
98

SOFTWARE PROCESS AND
PROJECT METRICS
easurement is fundamental to any engineering discipline, and soft-

M

ware engineering is no exception
...
Lord

Kelvin once said:

function points
...
86
process metrics
...
95
size-oriented
metrics
...
100
SSPI
...

The software engineering community has ﬁnally begun to take Lord Kelvin's
words to heart
...
Measurement can be applied to the software process with the intent of
improving it on a continuous basis
...
Finally, measurement can be used by software engineers to help assess the quality of technical work products and to assist in
tactical decision making as a project proceeds
...

measures that enable software

With measurement, trends (either good or bad)

people to gain insight into the efﬁcacy of the soft-

can be spotted, better estimates can be made,

ware process and the projects that are conducted

and true improvement can be accomplished over

QUICK
LOOK

using the process as a framework
...

and productivity data are collected
...
These measures are often nor-

and productivity improvements have occurred
...
The result is analyzed and compared to past

so that remedies can be developed and the soft-

averages for similar projects performed within the

ware process can be improved
...
Trends are assessed and conclusions

Who does it? Software metrics are analyzed and

are generated
...
Measures are
often collected by software engineers
...

ish individual performance
...

as a function of effort and time applied and measures of the "ﬁtness for use" of the
work products that are produced
...
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 it help us plan and estimate
more accurately?
In their guidebook on software measurement, Park, Goethert, and Florac [PAR96]
discuss the reasons that we measure:
There are four reasons for measuring software processes, products, and resources: to characterize, to evaluate, to predict, or to improve
...

We evaluate to determine status with respect to plans
...
We also evaluate to assess achievement of quality goals and to
assess the impacts of technology and process improvements on products and processes
...
”
Tom Gilb

We predict so that we can plan
...

We do this because we want to establish achievable goals for cost, schedule, and quality—
so that appropriate resources can be applied
...
Projections and estimates based on historical data also help us analyze risks
and make design/cost trade-offs
...

4
...
Because measure

CHAPTER 4

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

81

can be used either as a noun or a verb, deﬁnitions of the term can become confusing
...
Measurement is the act of determining a measure
...
”

“Not everything that
can be counted
counts, and not
everything that
counts can be
counted
...
g
...
Measurement
occurs as the result of the collection of one or more data points (e
...
, a number of
module reviews are investigated to collect measures of the number of errors for each)
...
g
...
1
A software engineer collects measures and develops metrics so that indicators
will be obtained
...
An indicator provides insight that enables the project manager or software engineers to
adjust the process, the project, or the process to make things better
...
Each
team must conduct design reviews but is allowed to select the type of review that it
will use
...
Assuming all other parameters equal, this provides the project manager
with an indicator that formal review methods may provide a higher return on time
investment than another, less formal review approach
...
The metric provides the manager with
insight
...

4
...
We measure power consumption, weight, physical dimensions, temperature, voltage, signal-to-noise ratio
...
Unfortunately, measurement is far less common in the software engineering world
...

1

This assumes that another measure, person-hours expended, is collected for each review
...
Process indicators enable a software engineering organization to gain insight

WebRef

into the efﬁcacy of an existing process (i
...
, the paradigm, software engineering tasks,

A comprehensive software
metrics guidebook can be
downloaded from
www
...
nasa
...
pdf

work products, and milestones)
...
Process metrics are collected across all projects and
over long periods of time
...

Project indicators enable a software project manager to (1) assess the status of an
ongoing project, (2) track potential risks, (3) uncover problem areas before they go
“critical,” (4) adjust work ﬂow or tasks, and (5) evaluate the project team’s ability to
control quality of software work products
...
In fact, measures that are collected by a project team and
converted into metrics for use during a project can also be transmitted to those with
responsibility for software process improvement
...

4
...
1

Process Metrics and Software Process Improvement

The only rational way to improve any process is to measure speciﬁc attributes of the
process, develop a set of meaningful metrics based on these attributes, and then use
the metrics to provide indicators that will lead to a strategy for improvement
...
”
Referring to Figure 4
...

formance
...
The complexity of the product
can have a substantial impact on quality and team performance
...
e
...

In addition, the process triangle exists within a circle of environmental conditions
that include the development environment (e
...
, CASE tools), business conditions (e
...
, deadlines, business rules), and customer characteristics (e
...
, ease of
communication)
...
That is, we derive a set

?

How do I
measure the
effectiveness of a
software process?

of metrics based on the outcomes that can be derived from the process
...
We also derive process metrics by measuring the characteristics of speciﬁc
software engineering tasks
...
1
Determinants
for software
quality and
organizational
effectiveness
(adapted from
[PAU94])

83

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

Product

Customer
characteristics

Business
conditions

Process

People

Development
environment

Technology

performing the umbrella activities and the generic software engineering activities
described in Chapter 2
...
Because it is natural that individual software engineers 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 individual only
...

The “private process data” philosophy conforms well with the personal software
process approach proposed by Humphrey [HUM95]
...
It provides the forms, scripts, and standards that help them estimate and plan their work
...
A fundamental PSP principle is that everyone is different and that a method that is effective for one
engineer may not be suitable for another
...

Humphrey recognizes that software process improvement can and should begin at
the individual level
...

Some process metrics are private to the software project team but public to all
team members
...
2 These
data are reviewed by the team to uncover indicators that can improve team performance
...
Project level defect rates (absolutely not attributed to an individ-

Public metrics enable
an organization to
make strategic
changes that improve
the software process
and tactical changes
during a software
project
...

Software process metrics can provide signiﬁcant beneﬁt as an organization works
to improve its overall level of process maturity
...
Grady [GRA92] suggests a “software metrics etiquette” that is appropriate for both managers and practitioners as
they institute a process metrics program:
•

Use common sense and organizational sensitivity when interpreting metrics
data
...

? What
guidelines

•
•

should be applied
when we collect
software metrics?

Don’t use metrics to appraise individuals
...

•
•

Never use metrics to threaten individuals or teams
...
” These data are merely an indicator for process improvement
...

As an organization becomes more comfortable with the collection and use of
process metrics, the derivation of simple indicators gives way to a more rigorous

WebRef

approach called statistical software process improvement (SSPI)
...
asq
...
Failure analysis
works in the following manner:
1
...
g
...

2
...

2
3

See Sections 4
...
1 and 4
...
2 for detailed discussions of LOC and function point metrics
...
A
defect is a ﬂaw that is uncovered after delivery to the end-user
...
2
Causes of
defects and
their origin for
four software
projects
[GRA94]

85

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

Logic
20%
Data handling
10
...
0%

Standards
6
...
7%

Error checking
10
...
5%
User interface
11
...
The number of errors and defects in each category is counted and ranked in
descending order
...

Use SSPI techniques to
gain that
understanding
...
The overall cost of errors and defects in each category is computed
...
Resultant data are analyzed to uncover the categories that result in highest
cost to the organization
...
Plans are developed to modify the process with the intent of eliminating (or
reducing the frequency of) the class of errors and defects that is most costly
...
2)
[GRA94]
...
Grady suggests the development of a ﬁshbone
diagram [GRA92] to help in diagnosing the data represented in the frequency diagram
...
3, the spine of the diagram (the central line) represents
the quality factor under consideration (in this case speciﬁcation defects that account
for 25 percent of the total)
...
g
...
The spine and ribs
notation is then added to each of the major ribs of the diagram to expand upon the
cause noted
...
3
...
3
A ﬁshbone
diagram
(adapted from
[GRA92])

M A N A G I N G S O F T WA R E P R O J E C T S

Missing

Ambiguous

Specification
defects
Wrong customer queried
Customer gave
wrong info
Inadequate inquiries
Used outdated
info
Incorrect

Changes

The collection of process metrics is the driver for the creation of the ﬁshbone diagram
...

4
...
2

Project Metrics

Software process metrics are used for strategic purposes
...
That is, project metrics and the indicators derived from them are used
by a project manager and a software team to adapt project work ﬂow and technical
activities
...

The ﬁrst application of project metrics on most software projects occurs during
estimation
...
As a project proceeds, measures of effort and calendar time expended are compared to original estimates (and
the project schedule)
...

As technical work commences, other project metrics begin to have signiﬁcance
...
In addition, errors uncovered
during each software engineering task are tracked
...

The intent of project metrics is twofold
...
Second, project metrics are used to assess
product quality on an ongoing basis and, when necessary, modify the technical
approach to improve quality
...
This leads to a
reduction in overall project cost
...
g
...

•

Outputs—measures of the deliverables or work products created during the
software engineering process
...

In actuality, this model can be applied to both process and project
...
Therefore the output from one activity becomes input to the next
...

4
...
g
...
g
...
Software metrics can be categorized similarly
...

?

What is the
difference
between direct and
indirect measures?

Direct measures of the product include lines of code (LOC) produced, execution speed,
memory size, and defects reported over some set period of time
...

The cost and effort required to build software, the number of lines of code produced, and other direct measures are relatively easy to collect, as long as specific
conventions for measurement are established in advance
...

We have already partitioned the software metrics domain into process, project,
and product metrics
...
Project metrics are then consolidated to create process metrics that are public
to the software organization as a whole
...
Individuals on two different project
teams record and categorize all errors that they ﬁnd during the software process
...

vidual measures are then combined to develop team measures
...
Team B found 184 errors
...
However, if the measures are normalized, it is possible to create software metrics that enable comparison to broader organizational averages
...
3
...
If a soft-

?

What data
should we
collect to derive
size-oriented
metrics?

ware organization maintains simple records, a table of size-oriented measures, such
as the one shown in Figure 4
...
The table lists each software development project that has been completed over the past few years and corresponding
measures for that project
...
4) for project alpha:
12,100 lines of code were developed with 24 person-months of effort at a cost of
$168,000
...

Further information for project alpha indicates that 365 pages of documentation were
developed, 134 errors were recorded before the software was released, and 29 defects

Project
alpha
beta
gamma
•
•
•

F I G U R E 4
...
doc
...

Three people worked on the development of software for project alpha
...
From the rudimentary
Metrics collection
template

data contained in the table, a set of simple size-oriented metrics can be developed
for each project:
•

Errors per KLOC (thousand lines of code)
...

•

$ per LOC
...

In addition, other interesting metrics can be computed:
•

Errors per person-month
...

•

$ per page of documentation
...
Most of the controversy swirls around the
use of lines of code as a key measure
...

a large body of literature and data predicated on LOC already exists
...
e
...

4
...
2 Function-Oriented Metrics
Function-oriented software metrics use a measure of the functionality delivered by
the application as a normalization value
...
Function-oriented

WebRef

metrics were ﬁrst proposed by Albrecht [ALB79], who suggested a measure called the

Comprehensive
information on function
points can be obtained at
www
...
org

function point
...

Function points are computed [IFP94] by completing the table shown in Figure 4
...

Five information domain characteristics are determined and counts are provided in

4

A defect occurs when quality assurance activities (e
...
, formal technical reviews) fail to uncover
an error in a work product produced during the software process
...
5
Computing
function points

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

Weighting factor
Measurement parameter Count

Simple Average Complex

Number of user inputs

×

3

4

6

=

Number of user outputs

×

4

5

7

=

Number of user inquiries

×

3

4

6

=

Number of files

×

7

10

15

=

Number of external interfaces

×

5

7

10

=

Count total

the appropriate table location
...
Each user input that provides distinct applicationoriented data to the software is counted
...

Number of user outputs
...
In this context output refers to

Function points are
derived from direct
measures of the
information domain
...
Individual data items within a report
are not counted separately
...
An inquiry is deﬁned as an on-line input that
results in the generation of some immediate software response in the form of
an on-line output
...

Number of ﬁles
...
e
...

Number of external interfaces
...
g
...

Once these data have been collected, a complexity value is associated with each
count
...
Nonetheless, the determination of complexity is somewhat subjective
...
65 + 0
...
5
...
The interested reader should see [IFP94] for details
...
Does the system require reliable backup and recovery?
2
...
Are there distributed processing functions?
4
...
Will the system run in an existing, heavily utilized operational environment?
6
...
Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8
...
Are the inputs, outputs, ﬁles, or inquiries complex?
10
...
Is the code designed to be reusable?
12
...
Is the system designed for multiple installations in different organizations?
14
...
The constant values in Equation (4-1) and
the weighting factors that are applied to information domain counts are determined
empirically
...

•

Defects per FP
...

•

Pages of documentation per FP
...

4
...
3

Extended Function Point Metrics

The function point measure was originally designed to be applied to business infor-

Extending function
points are used for
engineering, real-time,
and control-oriented
applications
...
To accommodate these applications, the data dimension (the information domain values discussed previously) was emphasized to the
exclusion of the functional and behavioral (control) dimensions
...
A number of extensions to the basic
function point measure have been proposed to remedy this situation
...

92

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

The feature point measure accommodates applications in which algorithmic complexity is high
...

To compute the feature point, information domain values are again counted and
weighted as described in Section 4
...
2
...
An algorithm is deﬁned as "a bounded computational problem that is included within a speciﬁc computer program” [JON91]
...

compuserve
...

Another function point extension for real-time systems and engineered products
has been developed by Boeing
...

Called the 3D function point [WHI95], characteristics of all three software dimensions
are “counted, quantiﬁed, and transformed” into a measure that provides an indication of the functionality delivered by the software
...
3
...
Counts of retained data (the internal program data structure; e
...
, files) and
external data (inputs, outputs, inquiries, and external references) are used along with
measures of complexity to derive a data dimension count
...
For the purposes of 3D function point computation, a
“transformation” is viewed as a series of processing steps that are constrained by a
set of semantic statements
...
7
A state represents some externally observable mode of behavior, and a transition
occurs as a result of some event that causes the software or system to change its
mode of behavior (i
...
, to change state)
...
To enter the auto-dial state from a resting state,
the user presses an Auto key on the keypad
...
Upon entry of the code and
hitting the Dial key (another event), the wireless phone software makes a transition
to the dialing state
...

To compute 3D function points, the following relationship is used:
index = I + O + Q + F + E + T + R

6

7

(4-2)

It should be noted that other extensions to function points for application in real-time software
work (e
...
, [ALA97]) have also been proposed
...

A detailed discussion of the behavioral dimension, including states and state transitions, is presented in Chapter 12
...
6
Determining the
complexity of a
transformation
for 3D function
points [WHI95]
...
Each complexity weighted value is computed using the following relationship:
complexity weighted value = NilWil + NiaWia + NihWih

(4-3)

where Nil, Nia, and Nih represent the number of occurrences of element i (e
...
, outputs) for each level of complexity (low, medium, high); and Wil, Wia, and Wih are the
corresponding weights
...
6
...
In fact, each
of these measures results in the same value if only the data dimension of an application is considered
...

The function point (and its extensions), like the LOC measure, is controversial
...
Opponents claim that the method requires
some "sleight of hand" in that computation is based on subjective rather than objective data; that counts of the information domain (and other dimensions) can be difﬁcult to collect after the fact; and that FP has no direct physical meaning—it's just a
number
...
4

M A N A G I N G S O F T WA R E P R O J E C T S

RECONCILING DIFFERENT METRICS APPROACHES
The relationship between lines of code and function points depends upon the programming language that is used to implement the software and the quality of the
design
...
To quote
Albrecht and Gaffney [ALB83]:
The thesis of this work is that the amount of function to be provided by the application (program) can be estimated from the itemization of the major components8 of data to be used
or provided by it
...

The following table [JON98] provides rough estimates of the average number of lines
of code required to build one function point in various programming languages:
Programming Language

? If I know
the number
of LOC, is it
possible to
estimate the
number of
function points?

LOC/FP (average)

Assembly language

320

C

128

COBOL

106

FORTRAN

106

Pascal

90

C++

64

Ada95

53

Visual Basic

32

Smalltalk

22

Powerbuilder (code generator)

16

SQL

12

A review of these data indicates that one LOC of C++ provides approximately 1
...
Furthermore, one LOC of a

Use backﬁring data
judiciously
...

Visual Basic provides more than three times the functionality of a LOC for a conventional programming language
...
e
...

LOC and FP measures are often used to derive productivity metrics
...
Should the LOC/person-month (or
FP/person-month) of one group be compared to similar data from another? Should
managers appraise the performance of individuals by using these metrics? The answers
8

It is important to note that “the itemization of major components” can be interpreted in a variety
of ways
...
A maintenance
organization might view project size in terms of the number of engineering change orders (Chapter 9)
...

CHAPTER 4

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

95

to these questions is an emphatic “No!” The reason for this response is that many
factors inﬂuence productivity, making for "apples and oranges" comparisons that can
be easily misinterpreted
...
However, in order to use
LOC and FP for estimation (Chapter 5), a historical baseline of information must be
established
...
5

METRICS FOR SOFTWARE QUALITY
The overriding goal of software engineering is to produce a high-quality system, application, or product
...
In

WebRef

addition, a good software engineer (and good software engineering managers) must

An excellent source of
information on software
quality and related topics
(including metrics) can be
found at
www
...

com

measure if high quality is to be realized
...

A good software engineer uses measurement to assess the quality of the analysis and
design models, the source code, and the test cases that have been created as the software is engineered
...

rather than subjective ways
...
Private
metrics collected by individual software engineers are assimilated to provide projectlevel results
...
Metrics derived from these measures provide an indication of the effectiveness of individual and group software quality assurance and control activities
...
g
...
Error data
can also be used to compute the defect removal efﬁciency (DRE) for each process framework activity
...
5
...

4
...
1

An Overview of Factors That Affect Quality

Over 25 years ago, McCall and Cavano [MCC78] deﬁned a set of quality factors that
were a ﬁrst step toward the development of metrics for software quality
...
e
...
In their work, the authors describe the

96

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

relationship between these quality factors (what they call a framework) and other
aspects of the software engineering process:
First, the framework provides a mechanism for the project manager to identify what
qualities are important
...
Such factors as maintainability and portability have been shown in recent years to have signiﬁcant life cycle cost
impact
...

Thirdly, the framework provides for more interaction of QA personnel throughout the
development effort
...
quality assurance personal can use indications of poor quality to help identify [better] standards to be enforced in the future
...
It is interesting to note that nearly every aspect of
computing has undergone radical change as the years have passed since McCall and

Surprisingly, the factors
that deﬁned software
quality in the 1970s
are the same factors
that continue to deﬁne
software quality in the
ﬁrst decade of this
century
...
But the attributes that provide an indication
of software quality remain the same
...
Even as computing
architectures undergo radical change (as they surely will), software that exhibits high
quality in operation, transition, and revision will continue to serve its users well
...
5
...
Gilb [GIL88] suggests deﬁnitions and measures for each
...
A program must operate correctly or it provides little value to
its users
...
The most common measure for correctness is defects per
KLOC, where a defect is deﬁned as a veriﬁed lack of conformance to requirements
...
For quality assessment purposes, defects are
counted over a standard period of time, typically one year
...
Software maintenance accounts for more effort than any
other software engineering activity
...
There is no way to measure maintainability directly; therefore, we
must use indirect measures
...
On average, programs that are maintainable will have a
lower MTTC (for equivalent types of changes) than programs that are not
maintainable
...
When the ratio of spoilage to overall project cost
(for many projects) is plotted as a function of time, a manager can determine
whether the overall maintainability of software produced by a software
development organization is improving
...

Integrity
...
This attribute measures a system's ability to withstand attacks (both accidental and intentional) to its security
...

To measure integrity, two additional attributes must be deﬁned: threat and
security
...
Security is the probability (which can be estimated or derived from
empirical evidence) that the attack of a speciﬁc type will be repelled
...

Usability
...
If a program is not user-friendly, it is often
doomed to failure, even if the functions that it performs are valuable
...
Detailed discussion of this topic is contained in Chapter 15
...
Chapter 19 considers this topic in additional detail
...
5
...
In essence, DRE is a measure of the ﬁltering ability of quality assurance and control activities as they are applied throughout all process framework activities
...

The ideal value for DRE is 1
...
Realistically, D will be greater than 0, but the value of DRE can still approach 1
...
In fact, as E
increases, it is likely that the ﬁnal value of D will decrease (errors are ﬁltered out before
they become defects)
...

DRE can also be used within the project to assess a team’s ability to ﬁnd errors
before they are passed to the next framework activity or software engineering task
...
If
DRE is low during
analysis and design,
spend some time
improving the way you
conduct formal
technical reviews
...
Those errors that are not found during the review
of the analysis model are passed on to the design task (where they may or may not
be found)
...

A quality objective for a software team (or an individual software engineer) is to
achieve DREi that approaches 1
...

4
...
As we noted earlier in this chapter, the problem is cultural
...
"Why do we need to do this?" asks a harried project manager
...

In this section, we consider some arguments for software metrics and present an
approach for instituting a metrics collection program within a software engineering

CHAPTER 4

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

99

organization
...
Realistically, though, establishing a successful company-wide software metrics program is hard work
...

The caveat suggested by the authors is well worth heeding, but the beneﬁts of measurement are so compelling that the hard work is worth it
...
6
...
If we do not measure, there no real way of determining whether we are improving
...

By requesting and evaluating productivity and quality measures, senior management can establish meaningful goals for improvement of the software engineering
process
...
If the process through which it is developed can be improved, a direct

“We manage things
‘by the numbers’ in
many aspects of our
lives
...
”
Michael Mah
Larry Putnam

impact on the bottom line can result
...
Hence, measurement is
used to establish a process baseline from which improvements can be assessed
...
Software project managers are concerned with more mundane (but equally important) issues: developing meaningful project estimates, producing higher-quality
systems, getting product out the door on time
...
We have already
noted that the baseline serves as a basis for estimation
...
9
At the project and technical levels (in the trenches), software metrics provide immediate beneﬁt
...

100

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

Answers to these questions can be determined if metrics have been collected and
used as a technical guide
...

4
...
2 Establishing a Baseline
By establishing a metrics baseline, beneﬁts can be obtained at the process, project,
and product (technical) levels
...
The same metrics can serve many masters
...
4 or as complex as a comprehensive database containing dozens of project measures and the metrics derived from them
...

4
...
3

Metrics Collection, Computation, and Evaluation

The process for establishing a baseline is illustrated in Figure 4
...
Ideally, data needed
to establish a baseline has been collected in an ongoing manner
...
Therefore, data collection requires a historical investigation of past projects

Baseline metrics data
should be collected
from a large,
representative
sampling of past
software projects
...
Once measures have been collected (unquestionably
the most difﬁcult step), metrics computation is possible
...
Finally, metrics must be evaluated and
applied during estimation, technical work, project control, and process improvement
...

4
...
g
...
In fact,
there is often signiﬁcant variability in the metrics we collect as part of the software
process
...
7
Software
metrics
collection
process

101

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

Software
engineering
process

Software
project

Software
product

Data
collection

Measures

Metrics
computation

Metrics

Metrics
evaluation

Indicators

Since the same process metrics will vary from project to project, how can we tell if
improved (or degraded) metrics values that occur as consequence of improvement activ-

“If I had to reduce
my message for
management to just
a few words, I’d say
it all had to do with
reducing variation
...
Edwards
Deming

ities are having a quantitative impact? How do we know whether we’re looking at a statistically valid trend or whether the “trend” is simply a result of statistical noise? When
are changes (either positive or negative) to a particular software metric meaningful?
A graphical technique is available for determining whether changes and variation in metrics data are meaningful
...
e
...
e
...
Two different types of control
charts are used in the assessment of metrics data [ZUL99]: (1) the moving range control chart and (2) the individual control chart
...
Over the past 15 months,
the organization has collected Er for 20 small projects in the same general software
development domain
...
8
...
2 for project 3 to a high of 5
...
In an
effort to improve the effectiveness of reviews, the software organization provided
training and mentoring to all project team members beginning with project 11
...

102

PA R T T W O

F I G U R E 4
...

Calculate the moving ranges: the absolute value of the successive differences between

each pair of data points
...

“If we can’t tell
signals from noise,
how will we ever
know if changes to
the process are
improvement—or
illusions?”
Richard Zultner

2
...
plot this (“mR bar”) as the center line on

your chart
...

Multiply the mean by 3
...
Plot this line as the upper control limit [UCL]
...

Using the data represented in Figure 4
...
9
...
71
...
58
...
” Hence, the metrics dispersion is stable
...
Plot individual metrics values as shown in Figure 4
...

2
...

3
...
660 and add Am computed in step 2
...
Plot the
UNPL
...
Multiply the mean of the mR values (the mR bar) by 2
...
This results in the lower natural process
limit (LNPL)
...
If the LNPL is less than 0
...
0
...
Compute a standard deviation as (UNPL Ϫ Am)/3
...
If any of the standard deviation
11 The discussion that follows is a summary of steps suggested by Zultner [ZUL99]
...
9
Moving range
control chart

Differences in successive
Er values

CHAPTER 4

103

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

4
UCL = 5
...
5
3

mR bar

2
...
5
1
0
...
10
Individual
control chart

Er, errors found/review hour

Projects

6

ϩ1␴

5
4

Am

3
Ϫ1␴ (std
...
0, it need not be plotted unless the metric being evaluated
takes on values that are less than 0
...

WebRef
The Common Control
Chart Cookbook covers
the topic at some length
and can be found at
www
...
com/
tqmtools/
ctlchtprinciples
...
8, we derive an individual
control chart as shown in Figure 4
...

Zultner [ZUL99] reviews four criteria, called zone rules, that may be used to evaluate whether the changes represented by the metrics indicate a process that is in
control or out of control
...
A single metrics value lies outside the UNPL
...
Two out of three successive metrics values lie more than two standard deviations away from Am
...
Four out of ﬁve successive metrics values lie more than one standard deviation away from Am
...
Eight consecutive metrics values lie on one side of Am
...
10, the metrics data
are derived from a stable process and trend information can be legitimately inferred
from the metrics collected
...
10, it can be seen that the variability of Er decreases after project 10 (i
...
, after an effort to improve the effectiveness of
reviews)
...
Since the control chart indicates that the process is stable,
it appears that efforts to improve review effectiveness are working
...
8

METRICS FOR SMALL ORGANIZATIONS
The vast majority of software development organizations have fewer than 20 soft-

If you’re just starting
to collect software
metrics, remember to
keep it simple
...

ware people
...
However, it
is reasonable to suggest that software organizations of all sizes measure and then
use the resultant metrics to help improve their local software process and the quality and timeliness of the products they produce
...
In the
end, the programs provided a foundation for taking care of customers and for planning and
carrying out future work
...
In the paragraphs that follow, we examine how these guidelines

?

How do I
derive a set
of “simple”
software metrics?

relate to metrics for small shops
...
But
how do we derive a “simple” set of software metrics that still provides value, and how
can we be sure that these simple metrics will meet the needs of a particular software
organization? We begin by focusing not on measurement but rather on results
...
For
example, “reduce the time to evaluate and implement change requests
...

•

Effort (person-hours) to perform the evaluation, Weval
...

CHAPTER 4

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

•

Effort (person-hours) required to make the change, Wchange
...

•

Errors uncovered during work to make change, Echange
...

Once these measures have been collected for a number of change requests, it is possible to compute the total elapsed time from change request to implementation of
the change and the percentage of elapsed time absorbed by initial queuing, evaluation and change assignment, and change implementation
...
These metrics can be assessed in the context of quality data, Echange and Dchange
...
In addition, the defect removal efﬁciency can be computed as
DRE = Echange / (Echange + Dchange)
DRE can be compared to elapsed time and total effort to determine the impact of
quality assurance activities on the time and effort required to make a change
...
These costs can show a substantial return on investment if the insights derived from metrics data lead to meaningful process improvement for the software organization
...
9

ESTABLISHING A SOFTWARE METRICS PROGRAM
The Software Engineering Institute has developed a comprehensive guidebook [PAR96]
for establishing a “goal-driven” software metrics program
...
Identify your business goals
...
sei
...
edu

2
...

3
...

4
...

5
...

6
...

7
...

8
...

106

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

9
...

10
...

A detailed discussion of these steps is best left to the SEI’s guidebook
...

Because software supports business functions, differentiates computer-based systems or products, or acts as a product in itself, goals defined for the business can
almost always be traced downward to speciﬁc goals at the software engineering level
...

For example, consider a company that makes advanced home security systems which
have substantial software content
...
Improve our customers’ satisfaction with our products
...
Make our products easier to use
...
Reduce the time it takes us to get a new product to market
...
Make support for our products easier
...
Improve our overall proﬁtability
...
Examples of entities
include development resources, work products, source code, test cases, change
requests, software engineering tasks, and schedules
...
g
...
The questions derived as a consequence of the creation of an entity-question list lead to the derivation of a set of subgoals that relate
directly to the entities created and the activities performed as part of the software
process
...
” The following
list of questions might be derived for this goal [PAR96]:
•

Do customer change requests contain the information we require to adequately
evaluate the change and then implement it in a timely manner?

•

How large is the change request backlog?

•

Is our response time for ﬁxing bugs acceptable based on customer need?

•

Is our change control process (Chapter 9) followed?

•

Are high-priority changes implemented in a timely manner?

Based on these questions, the software organization can derive the following subgoal: Improve the performance of the change management process
...

The SEI [PAR96] provides detailed guidance for steps 6 through 10 of its goaldriven measurement approach
...

4
...
Measures of speciﬁc attributes of the
process, project, and product are used to compute software metrics
...

Process metrics enable an organization to take a strategic view by providing insight
into the effectiveness of a software process
...
They enable
a project manager to adapt project work ﬂow and technical approach in a real-time
manner
...
Sizeoriented metrics use the line of code as a normalizing factor for other measures such
as person-months or defects
...

Software quality metrics, like productivity metrics, focus on the process, the project, and the product
...

Metrics are meaningful only if they have been examined for statistical validity
...

Measurement results in cultural change
...
In general, a goal-driven approach helps an organization focus on the
right metrics for its business
...

REFERENCES
[ALA97] Alain, A
...
Maya, J
...
Desharnais, and S
...
Pierre, “Adapting Function
Points to Real-Time Software,” American Programmer, vol
...
11, November
1997, pp
...

108

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

[ALB79] Albrecht, A
...
, “Measuring Application Development Productivity,” Proc
...
83–92
...
J
...
E
...

Software Engineering, November 1983, pp
...

[ART85] Arthur, L
...
, Measuring Programmer Productivity and Software Quality,
Wiley-Interscience, 1985
...
, Software Engineering Economics, Prentice-Hall, 1981
...
B
...
L
...

[GRA92] Grady, R
...
, Practical Software Metrics for Project Management and Process
Improvement, Prentice-Hall, 1992
...
, “Successfully Applying Software Metrics,” Computer, vol
...
9, September 1994, pp
...

[GRA99] Grable, R
...
, “Metrics for Small Projects: Experiences at SED,” IEEE
Software, March 1999, pp
...

[GIL88]

Gilb, T
...

[HET93] Hetzel, W
...

[HUM95} Humphrey, W
...

[IEE93]

IEEE Software Engineering Standards, Standard 610
...
47–48
...
0, International Func-

tion Point Users Group, 1994
...
, Programming Productivity, McGraw-Hill, 1986
...
, Applied Software Measurement, McGraw-Hill, 1991
...
, Estimating Software Costs, McGraw-Hill, 1998
...
, “Making Sense of Measurement for Small Organizations,” IEEE
Software, March 1999, pp
...

[MCC78] McCall, J
...
and J
...
Cavano, "A Framework for the Measurement of Software Quality," ACM Software Quality Assurance Workshop, November 1978
...
E
...
B
...
A
...

[PAU94] Paulish, D
...
Carleton, “Case Studies of Software Process Improvement Measurement,” Computer, vol
...
9, September 1994, pp
...

[RAG95] Ragland, B
...
8, no
...
29–30
...
and T
...
96
...
A
...
43–53
...
E
...
12, no
...
11–19
...
1
...

4
...
Suggest three measures, three metrics, and corresponding indicators that might
be used to assess the service department of an automobile dealership
...
3
...

4
...
Why should some software metrics be kept “private”? Provide examples of three
metrics that should be private
...

4
...
Obtain a copy of Humphrey (Introduction to the Personal Software Process, AddisonWesley, 1997) and write a one- or two-page summary that outlines the PSP approach
...
6
...
Can you add three more rules
to those noted in Section 4
...
1?
4
...
Attempt to complete the fishbone diagram shown in Figure 4
...
That is, following the approach used for “incorrect” speciﬁcations, provide analogous information for “missing, ambiguous, and changed” speciﬁcations
...
8
...
9
...

Team B found 184 errors
...
10
...
Will your case hold up when dozens or hundreds of projects are considered?
4
...
Compute the function point value for a project with the following information
domain characteristics:
Number of user inputs: 32
Number of user outputs: 60
Number of user inquiries: 24
Number of ﬁles: 8
Number of external interfaces: 2
Assume that all complexity adjustment values are average
...
12
...

4
...
The software used to control a photocopier requires 32,000 of C and 4,200
lines of Smalltalk
...

4
...
McCall and Cavano (Section 4
...
1) deﬁne a "framework" for software quality
...

4
...
Develop your own metrics (do not use those presented in this chapter) for correctness, maintainability, integrity, and usability
...

4
...
Is it possible for spoilage to increase while at the same time defects/KLOC
decrease? Explain
...
17
...

4
...
A software organization has DRE data for 15 projects over the past two years
...
81, 0
...
87, 0
...
63, 0
...
90, 0
...
61, 0
...
73,
0
...
74, 0
...
83
...

FURTHER READINGS AND INFORMATION SOURCES
Software process improvement (SPI) has received a signiﬁcant amount of attention
over the past decade
...
Worthwhile additions to the literature include:
Burr, A
...
Owen, Statistical Methods for Software Quality, International Thomson Publishing, 1996
...
and N
...
), Elements of Software Process Assessment and Improvement, IEEE Computer Society, 1999
...
A
...
D
...

CHAPTER 4

S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S

111

Garmus, D
...
Herron, Measuring the Software Process: A Practical Guide to Functional Measurements, Prentice-Hall, 1996
...
, Introduction to the Team Software Process, Addison-Wesley Longman, 2000
...
H
...

Humphrey [HUM95], Yeh (Software Process Control, McGraw-Hill, 1993), Hetzel [HET93],
and Grady [GRA92] discuss how software metrics can be used to provide the indicators necessary to improve the software process
...

Weinberg (Quality Software Management, Volume 2: First Order Measurement, Dorset
House, 1993) presents a useful model for observing software projects, ascertaining
the meaning of the observation, and determining its signiﬁcance for tactical and strategic decisions
...
The Software Productivity Consortium (The Software Measurement Guidebook, Thomson Computer Press, 1995) provides useful suggestions for instituting an effective metrics
approach
...

Park, et al
...

The newsletter IT Metrics (edited by Howard Rubin and published by Cutter Information Services) presents useful commentary on the state of software metrics in the
industry
...

A wide variety of information sources on software process and project metrics are
available on the Internet
...
mhhe
...
mhtml

CHAPTER

SOFTWARE PROJECT
PLANNING

5

oftware project management begins with a set of activities that are collectively called project planning
...
Whenever estimates are made, we look into the future and accept some
degree of uncertainty as a matter of course
...
139
decomposition
techniques
...
123

...
More seriously, they reﬂect

feasibility
...
e
...
because

make/buy
decision
...

outsourcing
...
Useful techniques for time and effort
estimation do exist
...
Past
experience (of all people involved) can aid immeasurably as estimates are developed and reviewed
...

problem-based
estimation
...
130
resources
...
115

What is it? Software project plan-

tems and products cost considerably more to build

ning actually encompasses all of

than a large house, it would seem reasonable to

the activities we discuss in Chap-

QUICK
LOOK

develop an estimate before you start creating the

ters 5 through 9
...

chapter, planning involves estimation—your

What are the steps? Estimation begins with a descrip-

attempt to determine how much money, how

tion of the scope of the product
...
The problem is then decomposed

system or product
...
It is advisable to generate your esti-

and software metrics data collected from past

mates using at least two different methods (as a

projects
...
Problem complexity and risk are con-

Why is it important? Would you build a house with-

sidered before a ﬁnal estimate is made
...
However, if you have experience

and time involved for each is

and follow a systematic approach, generate esti-

generated
...

How do I ensure that I’ve done it right? That’s hard,
because you won’t really know until the project has

5
...

O B S E R VAT I O N S O N E S T I M AT I N G
A leading executive was once asked what single characteristic was most important
when selecting a project manager
...
" We might add: "and the courage to
estimate when the future is cloudy
...
”
Capers Jones

mit to quantitative predictions when qualitative information is all that exists
...

Project complexity has a strong effect on the uncertainty inherent in planning
...

The ﬁrst-time developer of a sophisticated e-commerce application might consider
it to be exceedingly complex
...
A number of quantitative software complexity measures have been proposed [ZUS97]
...
However, other, more subjective
assessments of complexity (e
...
, the function point complexity adjustment factors
described in Chapter 4) can be established early in the planning process
...
As size increases, the interdependency among various elements of the
software grows rapidly
...

ble
...

The degree of structural uncertainty also has an effect on estimation risk
...

1
2

Systematic techniques for risk analysis are presented in Chapter 6
...
Increases in project size can have a geometric impact on project cost and schedule (M
...

CHAPTER 5

S O F T WA R E P R O J E C T P L A N N I N G

115

The availability of historical information has a strong inﬂuence on estimation risk
...
”
Aristotle

lems arose
...

Risk is measured by the degree of uncertainty in the quantitative estimates established for resources, cost, and schedule
...
The software planner should demand completeness of function, performance,
and interface deﬁnitions (contained in a System Speciﬁcation)
...

However, a project manager should not become obsessive about estimation
...
g
...
In such approaches, it is possible3 to revisit the estimate
(as more information is known) and revise it when the customer makes changes to
requirements
...
2

PROJECT PLANNING OBJECTIVES
The objective of software project planning is to provide a framework that enables the
manager to make reasonable estimates of resources, cost, and schedule
...
Therefore,
update your estimates
as the project
progresses
...
In addition, estimates
should attempt to deﬁne best case and worst case scenarios so that project outcomes
can be bounded
...
In the following sections, each of the activities associated with software project planning is discussed
...
3

S O F T WA R E S C O P E
The ﬁrst activity in software project planning is the determination of software scope
...
A statement of software scope
must be bounded
...
Functions described in the statement
3

This is not meant to imply that it is always politically acceptable to modify initial estimates
...
And yet, many
customers demand (incorrectly) that an estimate once made must be maintained regardless of
changing circumstances
...
Because both cost and schedule estimates are functionally
oriented, some degree of decomposition is often useful
...
Constraints identify limits
placed on the software by external hardware, available memory, or other existing
systems
...
3
...
A need has
been deﬁned and basic goals and objectives have been enunciated, but the information
necessary to deﬁne scope (a prerequisite for estimation) has not yet been delineated
...
The first meeting between the software engineer (the analyst) and the customer can be likened to the awkwardness
of a first date between two adolescents
...

Yet, communication must be initiated
...

The ﬁrst set of context-free questions focuses on the customer, the overall goals
and beneﬁts
...
Gause and
Weinberg call these "meta-questions" and propose the following (abbreviated) list:
• Are you the right person to answer these questions? Are answers "ofﬁcial"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
These questions (and others) will help to "break the ice" and initiate the communication that is essential to establish the scope of the project
...
In fact,
the Q&A session should be used for the ﬁrst encounter only and then be replaced
by a meeting format that combines elements of problem solving, negotiation, and
speciﬁcation
...

set
...
History has
shown that this approach works poorly
...

With these problems in mind, a number of independent investigators have developed a team-oriented approach to requirements gathering that can be applied to
help establish the scope of a project
...

5
...
2

Feasibility

Once scope has been identiﬁed (with the concurrence of the customer), it is reason-

"It's 106 miles to
Chicago, we got a
full tank of gas, half
a pack of cigarettes,
it's dark and we're
wearing sunglasses
...
"
The Blues Brothers

able to ask: “Can we build software to meet this scope? Is the project feasible?” All
too often, software engineers rush past these questions (or are pushed past them by
impatient managers or customers), only to become mired in a project that is doomed
from the onset
...
not everything imaginable is feasible, not even in software, evanescent as it may appear
to outsiders
...
You have done projects
like this one before
...

Projects on the margins of your experience are not so easy
...
Do some of these requirements pose risks that would make the

Technical feasibility is
important, but
business need is even
more important
...

project infeasible? Can these risks be overcome? The feasibility team ought to carry initial
architecture and design of the high-risk requirements to the point at which it can answer
these questions
...

Meantime, the cartoon people [senior managers] are drumming their ﬁngers nervously
on their large desks
...
Do it!”
Many of the projects that appear in the newspapers a few years later as whopping failures got started this way
...
Once scope is understood, the software team and others must work to determine if it can be done within
the dimensions just noted
...

5
...
3

A Scoping Example

Communication with the customer leads to a deﬁnition of the data and control that
are processed, the functions that must be implemented, the performance and constraints that bound the system, and related information
...
The statement of scope for CLSS
follows:
The conveyor line sorting system (CLSS) sorts boxes moving along a conveyor line
...
The boxes pass by a sorting station that contains a bar code reader
and a PC
...
Boxes pass in random order and are evenly spaced
...
CLSS is depicted schematically in Figure 5
...

CLSS software receives input information from a bar code reader at time intervals that
conform to the conveyor line speed
...
The software will do a look-up in a part number database containing a maximum
of 1000 entries to determine proper bin location for the box currently at the reader (sorting
station)
...
A record of the bin destination for each box will be maintained for later
recovery and reporting
...
Based on the
number of pulses generated between the sorting station and the shunt, the software will
produce a control signal to the shunt to properly position the box
...
1
A conveyor
line sorting
system

119

S O F T WA R E P R O J E C T P L A N N I N G

1
Conveyor line
motion
2
ID no
...

ID no
...

3

4
Bar code

Sorting
station

Shunt
5
Control
connection

6

The project planner examines the statement of scope and extracts all important software functions
...

•

Read pulse tachometer
...

•

Do database look-up
...

•

Produce control signal for shunt
...

In this case, performance is dictated by conveyor line speed
...
The CLSS

Adjust estimates to
reﬂect difﬁcult
performance
requirements and
design constraints,
even if scope is
otherwise simple
...

Function, performance, and constraints must be evaluated together
...
The effort and cost required
4

In reality, the functional decomposition is performed during system engineering (Chapter 10)
...

120

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

to develop CLSS software would be dramatically different if function remains the same
(i
...
, put boxes into bins) but performance varies
...
Function, performance, and constraints are intimately connected
...
The planner
considers the nature and complexity of each interface to determine any effect on
development resources, cost, and schedule
...

to include (1) the hardware (e
...
, processor, peripherals) that executes the software
and devices (e
...
, machines, displays) indirectly controlled by the software, (2) software that already exists (e
...
, database access routines, reusable software components, operating system) and must be linked to the new software, (3) people that
make use of the software via keyboard or other I/O devices, and (4) procedures that
precede or succeed the software as a sequential series of operations
...

The least precise aspect of software scope is a discussion of reliability
...
Classic hardware reliability characteristics like mean-time-between-failures
(MTBF) can be difficult to translate to the software domain
...
" For
example, software for an air trafﬁc control system or the space shuttle (both humanrated systems) must not fail or human life may be lost
...
Although it may not be possible to quantify software reliability as pre-

?

What is the
primary
source of
information for
determining
scope?

cisely as we would like in the statement of scope, we can use the nature of the project to aid in formulating estimates of effort and cost to assure reliability
...
In cases where a speciﬁcation has not been
developed, the planner must take on the role of system analyst to determine attributes and bounds that will inﬂuence estimation tasks
...
4

RESOURCES
The second software planning task is estimation of the resources required to accomplish the software development effort
...
2 illustrates development resources
as a pyramid
...
At a higher level, we encounter reusable software components—software building blocks that can dramatically reduce development costs and
accelerate delivery
...
Each
resource is speciﬁed with four characteristics: description of the resource, a state-

CHAPTER 5

S O F T WA R E P R O J E C T P L A N N I N G

121

F I G U R E 5
...
The last two characteristics can be viewed as a time window
...

XRef
The roles software
people play and the
team organizations
that they populate are
discussed in Chapter 3
...
4
...
Both organizational position (e
...
, manager, senior software engineer)
and specialty (e
...
, telecommunications, database, client/server) are speciﬁed
...

The number of people required for a software project can be determined only after
an estimate of development effort (e
...
, person-months) is made
...

5
...
2

Reusable Software Resources

Component-based software engineering (CBSE)5 emphasizes reusability—that is, the

To be reused
effectively, software
components must be
cataloged,
standardized, and
validated
...
Such building blocks, often
called components, must be cataloged for easy reference, standardized for easy application, and validated for easy integration
...
Existing software that can be acquired from a
third party or that has been developed internally for a past project
...

Full-experience components
...

122

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

built for the current project
...

Therefore, modiﬁcations required for full-experience components will be relatively low-risk
...
Existing speciﬁcations, designs, code, or
test data developed for past projects that are related to the software to be
built for the current project but will require substantial modiﬁcation
...
Therefore, modiﬁcations
required for partial-experience components have a fair degree of risk
...
Software components that must be built by the software team speciﬁcally for the needs of the current project
...
If off-the-shelf components meet project requirements, acquire them
...
6 In addition, risk
is relatively low
...
If full-experience components are available, the risks associated with modiﬁcation and integration are generally acceptable
...

3
...
If extensive modiﬁcation is required before the components can be properly integrated with other elements of the software,
proceed carefully—risk is high
...

Ironically, reusable software components are often neglected during planning, only
to become a paramount concern during the development phase of the software
process
...
In this way technical evaluation of the alternatives can be conducted and timely acquisition can occur
...
4
...
Hardware provides
a platform that supports the tools (software) required to produce the work products
that are an outcome of good software engineering practice
...
In fact, industry data indicate that cost, time to market, and the number of defects
delivered to the ﬁeld all are reduced
...

CHAPTER 5

S O F T WA R E P R O J E C T P L A N N I N G

123

organizations have multiple constituencies that require access to the SEE, a project
planner must prescribe the time window required for hardware and software and
verify that these resources will be available
...
For example, software for a numerical control (NC) used on a class of machine tools may require a speciﬁc machine tool (e
...
,
an NC lathe) as part of the validation test step; a software project for advanced pagelayout may need a digital-typesetting system at some point during development
...

5
...
An order of magnitude error in estimates of

“In an age of
outsourcing and
increased
competition, the
ability to estimate
more accurately
...
”
Rob Thomsett

software cost had relatively little impact
...
For complex, custom systems, a large
cost estimation error can make the difference between proﬁt and loss
...

Software cost and effort estimation will never be an exact science
...
However, software project estimation can
be transformed from a black art to a series of systematic steps that provide estimates
with acceptable risk
...
Delay estimation until late in the project (obviously, we can achieve
100% accurate estimates after the project is complete!)
...
Base estimates on similar projects that have already been completed
...
Use relatively simple decomposition techniques to generate project cost and
effort estimates
...
Use one or more empirical models for software cost and effort estimation
...
Cost estimates
must be provided "up front
...

The second option can work reasonably well, if the current project is quite similar to past efforts and other project inﬂuences (e
...
, the customer, business conditions, the SEE, deadlines) are equivalent
...

The remaining options are viable approaches to software project estimation
...
Decomposition techniques take a "divide and conquer"
approach to software project estimation
...
Empirical estimation models can be used to complement decomposition techniques and offer a potentially valuable estimation
approach in their own right
...
g
...
g
...

Automated estimation tools implement one or more decomposition techniques or
empirical models
...
In such systems, the characteristics of the
development organization (e
...
, experience, environment) and the software to be
developed are described
...

Estimation tools

Each of the viable software cost estimation options is only as good as the historical data used to seed the estimate
...
In Chapter 4, we examined the characteristics of some of the software metrics that provide the basis for historical estimation data
...
6

DECOMPOSITION TECHNIQUES
Software project estimation is a form of problem solving, and in most cases, the
problem to be solved (i
...
, developing a cost and effort estimate for a software project) is too complex to be considered in one piece
...

In Chapter 3, the decomposition approach was discussed from two different points
of view: decomposition of the problem and decomposition of the process
...
But before an estimate can be made, the
project planner must understand the scope of the software to be built and generate
an estimate of its “size
...
6
...

the degree to which the planner has properly estimated the size of the product to be
built; (2) the ability to translate the size estimate into human effort, calendar time,
and dollars (a function of the availability of reliable software metrics from past projects); (3) the degree to which the project plan reflects the abilities of the software
team; and (4) the stability of product requirements and the environment that supports the software engineering effort
...
Because a project estimate is only as good as the estimate of the size of the work to be accomplished, sizing represents the project planner’s first major challenge
...
If a direct
approach is taken, size can be measured in LOC
...

Putnam and Myers [PUT92] suggest four different approaches to the sizing problem:
“Fuzzy logic” sizing
...
To apply this approach, the

software that
we’re planning to
build?

qualitative scale, and then reﬁne the magnitude within the original range
...

Function point sizing
...

Standard component sizing
...

For example, the standard components for an information system are subsystems, modules, screens, reports, interactive programs, batch programs, ﬁles,
LOC, and object-level instructions
...
To illustrate,
consider an information systems application
...
Historical data indicates that 967 lines of COBOL
[PUT92] are required per report
...
Similar estimates and
computation are made for other standard components, and a combined size
value (adjusted statistically) results
...
This approach is used when a project encompasses the use
of existing software that must be modiﬁed in some way as part of a project
...
g
...
Using
an “effort ratio” [PUT92] for each type of change, the size of the change may
be estimated
...
This is accomplished by developing optimistic (low), most likely, and pessimistic (high) values for
size and combining them using Equations (5-1) described in the next section
...
9 for a discussion of estimating tools that make use of a historical database and the
other sizing techniques discussed in this section
...
6
...
LOC and FP data are used in two
ways during software project estimation: (1) as an estimation variable to "size"
each element of the software and (2) as baseline metrics collected from past projects and used in conjunction with estimation variables to develop cost and effort
projections
...
Yet both have a num-

do
? Whatand
LOCFP-oriented
estimation have
in common?

ber of characteristics in common
...
LOC or FP (the estimation variable) is then estimated for each function
...

Baseline productivity metrics (e
...
, LOC/pm or FP/pm9) are then applied to the
appropriate estimation variable, and cost or effort for the function is derived
...
This
will enable you to
compute domainspeciﬁc averages,
making estimation
more accurate
...

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 productivity
metric suspect
...
That is, projects should be grouped by team size, application area, complexity, and other relevant parameters
...
When a new project is estimated, it should ﬁrst be allocated to a domain,
and then the appropriate domain average for productivity should be used in generating the estimate
...
When LOC is used as the estimation variable, decomposition10 is absolutely essential and is often taken to considerable levels of detail
...

deﬁne product scope;
identify functions by decomposing scope;
do while functions remain
select a functionj
assign all functions to subfunctions list;
9 The acronym pm stands for person-month
...
However, a list of standard components (Section
5
...
1) may be used instead
...
It does not consider every logical contingency
...
If this is
not the case, then another sizing approach must be applied
...

For FP estimates, decomposition works differently
...

files, inquiries, and external interfaces—as well as the 14 complexity adjustment
values discussed in Chapter 4 are estimated
...

Regardless of the estimation variable that is used, the project planner begins by
estimating a range of values for each function or information domain value
...
An implicit indication of the degree of uncertainty is provided
when a range of values is speciﬁed
...
The expected value for the

?

How do I
compute the
expected value
for software
size?

estimation variable (size), S, can be computed as a weighted average of the optimistic
(sopt), most likely (sm), and pessimistic (spess) estimates
...
We assume that there is a very small probability the actual size result
will fall outside the optimistic or pessimistic values
...
Are the estimates correct? The only reasonable answer to this question is: "We can't be sure
...
Even then,
common sense and experience must prevail
...
6
...
A review of the System Speciﬁcation indicates that the software is to execute on an engineering workstation and must interface with various
computer graphics peripherals including a mouse, digitizer, high resolution color display and laser printer
...
The engineer will interact and control the CAD system through a user interface
that will exhibit characteristics of good human/machine interface design
...
Design analysis modules will be developed to produce the required output, which will be displayed on
a variety of graphics devices
...

This statement of scope is preliminary—it is not bounded
...
For example,
before estimation can begin the planner must determine what "characteristics of good

Many modern
applications reside on
a network or are part
of a client/server
architecture
...

human/machine interface design" means or what the size and sophistication of the
"CAD database" are to be
...
3, is developed
...
For
example, the range of LOC estimates for the 3D geometric analysis function is optimistic—4600 LOC, most likely—6900 LOC, and pessimistic—8600 LOC
...
3
Estimation
table for the
LOC method

129

S O F T WA R E P R O J E C T P L A N N I N G

Function

Estimated LOC

User interface and control facilities (UICF)
Two-dimensional geometric analysis (2DGA)
Three-dimensional geometric analysis (3DGA)
Database management (DBM)
Computer graphics display facilities (CGDF)
Peripheral control function (PCF)
Design analysis modules (DAM)

2,300
5,300
6,800
3,350
4,950
2,100
8,400

Estimated lines of code

33,200

Applying Equation (5-1), the expected value for the 3D geometric analysis function is 6800
LOC
...
By summing vertically in the esti-

Do not succumb to the
temptation to use this
result as your
estimate
...

mated LOC column, an estimate of 33,200 lines of code is established for the CAD system
...
Based on a burdened labor rate of $8000 per
month, the cost per line of code is approximately $13
...
12

5
...
4

An Example of FP-Based Estimation

Decomposition for FP-based estimation focuses on information domain values rather
than software functions
...
4, the project planner estimates inputs, outputs, inquiries, ﬁles, and external

WebRef

interfaces for the CAD software
...
spr
...
Figure 5
...

Information domain value Opt
...

Est
...
4
Estimating
information
domain
values

20

16

22

28

22

5

88

Number of files

4

4

5

4

10

42

Number of external interfaces

2

2

3

2

7

15

Count total

320

12 Estimates are rounded-off to the nearest $1,000 and person-month
...

130

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

Each of the complexity weighting factors is estimated and the complexity adjustment factor is computed as described in Chapter 4:
Factor

Value

Backup and recovery

4

Data communications

2

Distributed processing

0

Performance critical

4

Existing operating environment

3

On-line data entry

4

Input transaction over multiple screens

5

Master ﬁles updated on-line

3

Information domain values complex

5

Internal processing complex

5

Code designed for reuse

4

Conversion/installation in design

3

Multiple installations

5

Application designed for change
Complexity adjustment factor

5
1
...
65 + 0
...
5 FP/pm
...

Based on the LOC estimate and the historical productivity data, the total estimated
project cost is $461,000 and the estimated effort is 58 person-months
...
6
...
That is, the process is decomposed into a relatively small
set of 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
...
Functions and related software process activities may be represented as part of a table similar to the one presented in Figure 3
...

Once problem functions and process activities are melded, the planner estimates
the effort (e
...
, person-months) that will be required to accomplish each software process
activity for each software function
...
2
...
e
...
It is very likely the labor rate will vary for each task
...

CHAPTER 5

F I G U R E 5
...
50
0
...
50
0
...
50
0
...
50

2
...
00
4
...
00
3
...
00
2
...
40
0
...
00
1
...
75
0
...
50

5
...
00
3
...
50
1
...
50
2
...
50

20
...
50

16
...
25

0
...
25

1%

1%

1%

n/a
n/a
n/a
n/a
n/a
n/a
n/a

8
...
35
8
...
00
5
...
25
5
...
00

CC = customer communication CE = customer evaluation

Costs and effort for each function and software process activity are computed as
the last step
...
5, such as
breaking analysis into
its major tasks and
estimating each
separately
...
If both sets of estimates show reasonable agreement, there is
good reason to believe that the estimates are reliable
...

5
...
5

An Example of Process-Based Estimation

To illustrate the use of process-based estimation, we again consider the CAD software introduced in Section 5
...
3
...

Referring to the completed process-based table shown in Figure 5
...
The engineering and construction
release activities are subdivided into the major software engineering tasks shown
...
These are noted in the total row at the bottom of the table
...
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
...
If desired, labor
rates could be associated with each software process activity or software engineering task and computed separately
...
If the estimates
are within a 20
percent band, they can
be reconciled into a
single value
...
The average estimate (using all three
approaches) is 53 person-months
...

What happens when agreement between estimates is poor? The answer to this
question requires a re-evaluation of information used to make the estimates
...
The scope of the project is not adequately understood or has been misinterpreted by the planner
...
Productivity data used for problem-based estimation techniques is inappropriate for the application, obsolete (in that it no longer accurately reﬂects the
software engineering organization), or has been misapplied
...

5
...
Values for LOC or FP are estimated using the
approach described in Sections 5
...
2 and 5
...
3
...

Therefore, the model is
domain sensitive
...

The empirical data that support most estimation models are derived from a limited sample of projects
...
Therefore, the results
obtained from such models must be used judiciously
...
7
...
The overall structure of such models takes the form [MAT94]
E = A + B x (ev)C

(5-2)

where A, B, and C are empirically derived constants, E is effort in person-months, and
ev is the estimation variable (either LOC or FP)
...
The model should be
run using the results of completed projects
...
If agreement
is not good, model coefﬁcients and exponents must be recomputed using local data
...
g
...
Among the many
LOC-oriented estimation models proposed in the literature are
E = 5
...
91
E = 5
...
73 x

Walston-Felix model

(KLOC)1
...
2 x (KLOC)1
...

Boehm simple model

E = 5
...
047

Doty model for KLOC > 9

FP-oriented models have also been proposed
...
39 + 0
...
62 x 7
...
7 + 15
...
The implication is clear
...
7
...
The original COCOMO model became one of the most widely
used and discussed software cost estimation models in the industry
...

Like its predecessor, COCOMO II is actually a hierarchy of estimation models that
address the following areas:
Application composition model
...
usc
...
html

and system interaction, assessment of performance, and evaluation of technology maturity are paramount
...
Used once requirements have been stabilized
and basic software architecture has been established
...
Used during the construction of the
software
...
Three different sizing options are available as part of the model hierarchy:
object points, function points, and lines of source code
...
It should be noted that other, more

14 Part of the reason is that these models are often derived from relatively small populations of projects in only a few application domains
...
1
Complexity
weighting for
object types
[BOE96]

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

Object type

Complexity weight
Simple

Medium

Difficult

Screen

1

2

3

Report

2

5

8
10

3GL component

sophisticated estimation models (using FP and KLOC) are also available as part of
COCOMO II
...
Each object
instance (e
...
, a screen or report) is classiﬁed into one of three complexity levels (i
...
,
simple, medium, or difﬁcult) using criteria suggested by Boehm [BOE96]
...

Once complexity is determined, the number of screens, reports, and components
are weighted according to Table 5
...
The object point count is then determined by
multiplying the original number of object instances by the weighting factor in Table
5
...
When component-based development or general software reuse is to be applied, the percent of reuse (%reuse) is
estimated and the object point count is adjusted:
NOP = (object points) x [(100 Ϫ %reuse)/100]
where NOP is deﬁned as new object points
...
Table 5
...
2
Productivity
rates for object
points [BOE96]

PROD = NOP/person-month

Developer's experience/capability

Very
low

Low

Nominal

High

Very
high

Environment maturity/capability

Very
low

Low

Nominal

High

Very
high

4

7

13

25

50

PROD

CHAPTER 5

S O F T WA R E P R O J E C T P L A N N I N G

135

for different levels of developer experience and development environment maturity
...
A complete discussion of these is beyond
the scope of this book
...

5
...
3

The Software Equation

The software equation [PUT92] is a dynamic multivariable model that assumes a speciﬁc distribution of effort over the life of a software development project
...
Based on these data, an estimation model of the form
E = [LOC ϫ B0
...
qsm
...
17 The productivity parameter can be derived for local conditions
using historical data collected from past development efforts
...

15 As noted earlier, these models use FP and KLOC counts for the size variable
...
” For small programs (KLOC = 5 to 15), B = 0
...
For programs
greater than 70 KLOC, B = 0
...

17 It is important to note that the productivity parameter can be empirically derived from local project data
...
Minimum development time is deﬁned as
tmin = 8
...
43 in months for tmin > 6 months
E = 180

Bt3

in person-months for E ≥ 20 person-months

(5-4a)
(5-4b)

Note that t in Equation (5-4b) is represented in years
...
14 (33200/12000)0
...
6 calendar months
E = 180 ϫ 0
...
05)3
E = 58 person-months
The results of the software equation correspond favorably with the estimates developed in Section 5
...
Like the COCOMO model noted in the preceding section, the software equation has evolved over the past decade
...

5
...
Software engineering managers are faced with a
make/buy decision that can be further complicated by a number of acquisition
options: (1) software may be purchased (or licensed) off-the-shelf, (2) “fullexperience” or “partial-experience” software components (see Section 5
...
2) may
be acquired and then modified and integrated to meet specific needs, or (3) software may be custom built by an outside contractor to meet the purchaser's
specifications
...
In many
cases, it’s worth living
without the special
features!

the software to be purchased and the end cost
...
g
...
For more expensive software products, the
following guidelines can be applied:
1
...
Deﬁne measurable characteristics whenever possible
...

Estimate the internal cost to develop and the delivery date
...
Select three or four candidate applications that best meet your speciﬁcations
...
Select reusable software components that will assist in constructing the
required application
...

137

S O F T WA R E P R O J E C T P L A N N I N G

Develop a comparison matrix that presents a head-to-head comparison of key
functions
...

5
...

6
...

In the ﬁnal analysis, the make/buy decision is made based on the following conditions: (1) Will the delivery date of the software product be sooner than that for internally developed software? (2) Will the cost of acquisition plus the cost of customization
be less than the cost of developing the software internally? (3) Will the cost of outside support (e
...
, a maintenance contract) be less than the cost of internal support?
These conditions apply for each of the acquisition options
...
8
...
For example, Figure 5
...
In this case, the software engineering organization can (1) build system X from scratch, (2) reuse existing “partial-experience” components to construct the
system, (3) buy an available software product and modify it to meet local needs, or
(4) contract the software development to an outside vendor
...
6
A decision tree
to support the
make/buy
decision

Simple (0
...
70)

$450,000

Build
Minor changes
(0
...
20)
Buy

Major
changes
(0
...
80)
Minor changes
(0
...
30)

Without changes
(0
...
40)

$310,000

$490,000

$210,000
$400,000

$350,000
$500,000

138

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

If the system is to be built from scratch, there is a 70 percent probability that the
job will be difﬁcult
...
A
"simple" development effort is estimated to cost $380,000
...
For the build path,

WebRef
An excellent tutorial on
decision tree analysis can
be found at
www
...
co
...

html

expected costbuild = 0
...
70 ($450K) = $429K
Following other paths of the decision tree, the projected costs for reuse, purchase
and contract, under a variety of circumstances, are also shown
...
40 ($275K) + 0
...
20($310K) + 0
...
70($210K) + 0
...
60($350K) + 0
...
6, the
lowest expected cost is the "buy" option
...
Availability, experience of the developer/vendor/contractor, conformance to requirements, local "politics," and the
likelihood of change are but a few of the criteria that may affect the ultimate decision to build, reuse, buy, or contract
...
8
...
”
Steve McConnell

tal question: “Is there a way that we can get the software and systems we need at a
lower price?” The answer to this question is not a simple one, and the emotional discussions that occur in response to the question always lead to a single word: outsourcing
...
Software engineering activities are
contracted to a third party who does the work at lower cost and, hopefully, higher
quality
...

The decision to outsource can be either strategic or tactical
...
At the tactical level, a project manager determines whether
part or all of a project can be best accomplished by subcontracting the software work
...
A detailed discussion of the financial analysis for outsourcing is beyond the

CHAPTER 5

S O F T WA R E P R O J E C T P L A N N I N G

139

scope of this book and is best left to others (e
...
, [MIN95])
...

On the positive side, cost savings can usually be achieved by reducing the num-

WebRef

ber of software people and the facilities (e
...
, computers, infrastructure) that support

Useful information
(papers, pointers) on
outsourcing can be found
at
www
...

com

them
...
Since software is a technology that differentiates its systems, services, and
products, a company runs the risk of putting the fate of its competitiveness into the
hands of a third party
...
The only way to blunt
the trend is to recognize that software work is extremely competitive at all levels
...

5
...
These automated estimation tools allow the planner to estimate cost and effort and to perform
"what-if" analyses for important project variables such as delivery date or stafﬁng
...
Sizing of project deliverables
...
Work products include the external representation of
software (e
...
, screen, reports), the software itself (e
...
, KLOC), functionality
delivered (e
...
, function points), descriptive information (e
...
documents)
...
Selecting project activities
...

3
...
The number of people who will be available to
do the work is speciﬁed
...

4
...
Estimation tools use one or more models (e
...
,
Section 5
...

5
...
Given the results of step 4, costs can be computed by allocating labor rates to the project activities noted in step 2
...
Predicting software schedules
...

140

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

When different estimation tools are applied to the same project data, a relatively
large variation in estimated results is encountered
...
This reinforces the notion
that the output of estimation tools should be used as one "data point" from which
estimates are derived—not as the only source for an estimate
...
10

SUMMARY
The software project planner must estimate three things before a project begins: how
long it will take, how much effort will be required, and how many people will be
involved
...

The statement of scope helps the planner to develop estimates using one or more
techniques that fall into two broad categories: decomposition and empirical modeling
...
Empirical techniques use empirically derived expressions for effort and
time to predict these project quantities
...

Accurate project estimates generally use at least two of the three techniques just
noted
...
Software project estimation can never be an exact science, but a combination of good historical data and
systematic techniques can improve estimation accuracy
...
M
...

[BOE81] Boehm, B
...

[BOE89] Boehm, B
...

[BOE96] Boehm, B
...
13, no
...
73–82
...
, et al
...

[BRO75] Brooks, F
...

[GAU89] Gause, D
...
and G
...
Weinberg, Exploring Requirements: Quality Before
Design, Dorset House, 1989
...
and R
...
Chester, Software Reuse: Guidelines and Methods, Plenum
Press, 1991
...
, “How Software Estimation Tools Work,” American Programmer,
vol
...
7, July 1996, pp
...

[MAT94] Matson, J
...
Barrett, and J
...
Software Engineering, vol
...
4,
April 1994, pp
...

[MIN95] Minoli, D
...

[PHI98]

Phillips, D
...

[PUT92] Putnam, L
...
Myers, Measures for Excellence, Yourdon Press, 1992
...
and W
...
105–107
...
and W
...

[ZUS97] Zuse, H
...

PROBLEMS AND POINTS TO PONDER
5
...
Assume that you are the project manager for a company that builds software
for consumer products
...
Write a statement of scope that describes the software
...
If you’re unfamiliar with home security systems, do
a bit of research before you begin writing
...

5
...
Software project complexity is discussed brieﬂy in Section 5
...
Develop a list of
software characteristics (e
...
, concurrent operation, graphical output) that affect the
complexity of a project
...

5
...
Performance is an important consideration during planning
...

5
...
Do a functional decomposition of the home security system software you
described in problem 5
...
Estimate the size of each function in LOC
...
6
...

5
...
Using the 3D function point measure described in Chapter 4, compute the number of FP for the home security system software and derive effort and cost estimates
using the FP-based estimation technique described in Section 5
...
4
...
6
...
Assume average complexity and average developer/environment maturity
...

5
...
Use the software equation to estimate the home security system software
...

5
...
Compare the effort estimates derived in problems 5
...
5, and 5
...
Develop a
single estimate for the project using a three-point estimate
...
9
...
8, determine whether it’s reasonable to
expect that the software can be built within the next six months and how many people would have to be used to get the job done
...
10
...
Alternatively, acquire one or more on-line models for estimation from Web-based sources
...
11
...

5
...
It seems odd that cost and schedule estimates are developed during software
project planning—before detailed software requirements analysis or design has been
conducted
...
13
...
6
assuming that every branch has a 50–50 probability
...

Jones (Estimating Software Costs, McGraw-Hill, 1998) has written the most comprehensive treatment of the subject published to date
...
Roetzheim and Beasley (Software Project Cost and Schedule Estimating: Best Practices, Prentice-Hall, 1997) present many useful models and suggest step-by-step guidelines for
generating the best possible estimates
...

Putnam and Myer’s detailed treatment of software cost estimating ([PUT92] and
[PUT97b]) and Boehm's books on software engineering economics ([BOE81] and

CHAPTER 5

S O F T WA R E P R O J E C T P L A N N I N G

143

COCOMO II [BOE00]) describe empirical estimation models
...
An excellent
book by DeMarco (Controlling Software Projects, Yourdon Press, 1982) provides valuable insight into the management, measurement, and estimation of software projects
...

Lines-of-code cost estimation is the most commonly used approach in the industry
...
Lorenz and Kidd (Object-Oriented Software Metrics,
Prentice-Hall, 1994) and Cockburn (Surviving Object-Oriented Projects, AddisonWesley, 1998) consider estimation for object-oriented systems
...
An up-to-date list of World Wide Web references that are relevant to software estimation can be found at the SEPA Web site:
http://www
...
com/engcs/compsci/pressman/resources/
project-plan
...
154
components and
drivers
...
148
mitigation
...
157

n his book on risk analysis and management, Robert Charette [CHA89] presents a conceptual deﬁnition of risk:

I

First, risk concerns future happenings
...
The
question is, can we, therefore, by changing our actions today, create an opportunity
for a different and hopefully better situation for ourselves tomorrow
...
151

places
...

reﬁnement
...

risk exposure
...
146
risk table
...
159
safety and
hazards
...
The future is our concern—
what risks might cause the software project to go awry? Change is our concern—how will changes in customer requirements, development technologies,
target computers, and all other entities connected to the project affect timeliness and overall success? Last, we must grapple with choices—what methods
and tools should we use, how many people should be involved, how much
emphasis on quality is "enough"?

What is it? Risk analysis and

Lots of things can go wrong, and frankly, many

management are a series of steps

often do
...
Many prob-

sures to avoid or manage them—is a key element

lems can plague a software project
...

QUICK
LOOK

potential problem—it might happen, it might not
...
”

idea to identify it, assess its probability of occur-

Next, each risk is analyzed to determine the like-

rence, estimate its impact, and establish a con-

lihood that it will occur and the damage that it

tingency plan should the problem actually occur
...
Once this information is

Who does it? Everyone involved in the software

established, risks are ranked, by probability and

process—managers, software engineers, and cus-

impact
...

impact
...
” Software is a difﬁcult undertaking
...

ect
...
Contingency plans for risk management

aged should be derived from thorough study of

should be realistic
...
"
Before we can identify the "right risks" to be taken during a software project, it is
important to identify all risks that are obvious to both managers and practitioners
...
1

R E A C T I V E V S
...
In the movies that carried his name, Indiana Jones, when
faced with overwhelming difﬁculty, would invariably say, “Don’t worry, I’ll think of
something!” Never worrying about problems until they happened, Indy would react
in some heroic way
...
Yet, the majority of

“If you don't actively
attack the risks, they
will actively attack
you
...
At best, a reactive strategy
monitors the project for likely risks
...
More commonly, the software team does
nothing about risks until something goes wrong
...
This is often called a fire fighting mode
...

A considerably more intelligent strategy for risk management is to be proactive
...
Potential risks are
identiﬁed, their probability and impact are assessed, and they are ranked by importance
...
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
...

6
...
1
• Loss—if the risk becomes a reality, unwanted consequences or losses will
occur
...
To accomplish this, different categories of
risks are considered
...
That is, if project risks become real, it is
likely that project schedule will slip and that costs will increase
...
In Chapter 5, project complexity, size, and the degree of structural uncertainty were also
deﬁned as project (and estimation) risk factors
...

If a technical risk becomes a reality, implementation may become difﬁcult or impossible
...
In addition, specification ambiguity, technical
uncertainty, technical obsolescence, and "leading-edge" technology are also risk factors
...

Business risks threaten the viability of the software to be built
...
Candidates for the top ﬁve business risks are
(1) building a excellent product or system that no one really wants (market risk), (2)
building a product that no longer ﬁts into the overall business strategy for the company (strategic risk), (3) building a product that the sales force doesn't understand
how to sell, (4) losing the support of senior management due to a change in focus or
a change in people (management risk), and (5) losing budgetary or personnel commitment (budget risks)
...
Some risks are simply unpredictable in advance
...

“[Today,] no one has
the luxury of getting
to know a task so
well that it holds no
surprises, and
surprises mean
risk
...
g
...
Predictable risks are extrapolated from past project experience (e
...
, staff turnover, poor
communication with the customer, dilution of staff effort as ongoing maintenance
requests are serviced)
...
They can and do
occur, but they are extremely difﬁcult to identify in advance
...

148

PA R T T W O

6
...
By identifying known and predictable risks,
the project manager takes a ﬁrst step toward avoiding them when possible and controlling them when necessary
...
Be certain
to spend the time to
identify as many
product-speciﬁc risks as
possible
...
2: generic risks and product-specific risks
...
Product-speciﬁc risks can be identiﬁed only
by those with a clear understanding of the technology, the people, and the environment that is speciﬁc to the project at hand
...
The checklist can
be used for risk identiﬁcation and focuses on some subset of known and predictable
risks in the following generic subcategories:
• Product size—risks associated with the overall size of the software to be built
or modiﬁed
...

• Customer characteristics—risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a
timely manner
...

• Development environment—risks associated with the availability and quality
of the tools to be used to build the product
...

• Staff size and experience—risks associated with the overall technical and
project experience of the software engineers who will do the work
...
Questions relevant to each
of the topics can be answered for each software project
...
A different risk item checklist
format simply lists characteristics that are relevant to each generic subcategory
...
Drivers for performance, support, cost, and schedule are discussed in
answer to later questions
...
”
Tim Lister

posed in the literature (e
...
, [SEI93], [KAR96])
...
However, a relatively short list of questions [KEI98] can be used
to provide a preliminary indication of whether a project is “at risk
...
3
...
The questions
are ordered by their relative importance to the success of a project
...
Have top software and customer managers formally committed to support
the project?
2
...
Are requirements fully understood by the software engineering team and
their customers?
4
...
Do end-users have realistic expectations?
6
...
Does the software engineering team have the right mix of skills?
8
...
Does the project team have experience with the technology to be
implemented?

WebRef
Risk Radar is a risk
management database
that helps project
managers identify, rank,
and communicate project
risks
...
spmn
...
html

10
...
Do all customer/user constituencies agree on the importance of the project
and on the requirements for the system/product to be built?
If any one of these questions is answered negatively, mitigation, monitoring, and
management steps should be instituted without fail
...

6
...
2

Risk Components and Drivers

The U
...
Air Force [AFC88] has written a pamphlet that contains excellent guidelines
for software risk identiﬁcation and abatement
...
In the context of this discussion, the risk
components are deﬁned in the following manner:
• Performance risk—the degree of uncertainty that the product will meet its
requirements and be ﬁt for its intended use
...

• Support risk—the degree of uncertainty that the resultant software will be
easy to correct, adapt, and enhance
...

The impact of each risk driver on the risk component is divided into one of four impact
categories—negligible, marginal, critical, or catastrophic
...
1 [BOE89],

Components
Performance

Support

Cost

Schedule

Category
Failure to meet the requirement
would result in mission failure

Failure results in increased costs
and schedule delays with expected
values in excess of $500K

2

Significant
degradation to
nonachievement
of technical
performance

Significant financial
shortages, budget
overrun likely

1

Failure to meet the requirement would
degrade system performance to a point
where mission success is questionable

Failure results in operational delays
and/or increased costs with expected
value of $100K to $500K

2

Some reduction
in technical
performance

Some shortage of
financial resources,
possible overruns

1

Failure to meet the requirement would
result in degradation of secondary
mission

Costs, impacts, and/or recoverable
schedule slips with expected value
of $1K to $100K

2

Minimal to small
reduction in
technical
performance

Sufficient financial
resources

1

Failure to meet the requirement would
create inconvenience or nonoperational
impact

Error results in minor cost and/or
schedule impact with expected value
of less than $1K

2

No reduction in
technical
performance

Possible budget
underrun

1

Catastrophic

Critical

Marginal

Negligible

Nonresponsive or
unsupportable
software

Minor delays in
software
modifications

Responsive
software
support

Easily supportable
software

Note: (1) The potential consequence of undetected software errors or faults
...

F I G U R E 6
...
The impact category is
chosen based on the characterization that best ﬁts the description in the table
...
4

RISK PROJECTION
Risk projection, also called risk estimation, attempts to rate each risk in two ways—the
likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur
...

6
...
1 Developing a Risk Table
A risk table provides a project manager with a simple technique for risk projection
...
2
...
2 Sample risk table prior to sorting

2

The risk table should be implemented as a spreadsheet model
...

152
F I G U R E 6
...
0

A project team begins by listing all risks (no matter how remote) in the first column of the table
...

lists referenced in Section 6
...
Each risk is categorized in the second column (e
...
,
PS implies a project size risk, BU implies a business risk)
...
The probability value
for each risk can be estimated by team members individually
...

Next, the impact of each risk is assessed
...
1, and an impact category is determined
...

Once the first four columns of the risk table have been completed, the table is
sorted by probability and by impact
...

the top of the table, and low-probability risks drop to the bottom
...

The project manager studies the resultant sorted table and deﬁnes a cutoff line
...
Risks that fall below the line are
re-evaluated to accomplish second-order prioritization
...
3, risk
impact and probability have a distinct inﬂuence on management concern
...

CHAPTER 6

R I S K A N A LY S I S A N D M A N A G E M E N T

153

tor that has a high impact but a very low probability of occurrence should not absorb
a signiﬁcant amount of management time
...

All risks that lie above the cutoff line must be managed
...
”
Ben Franklin

or alternatively, a collection of risk information sheets developed for all risks that
lie above the cutoff
...
5 and 6
...

Risk probability can be determined by making individual estimates and then developing a single consensus value
...
Risk
drivers can be assessed on a qualitative probability scale that has the following values: impossible, improbable, probable, and frequent
...
g
...
7 to 1
...

6
...
2

Assessing Risk Impact

Three factors affect the consequences that are likely if a risk does occur: its nature,
its scope, and its timing
...
For example, a poorly deﬁned external interface to customer hardware (a
technical risk) will preclude early design and testing and will likely lead to system
integration problems late in a project
...
Finally, the timing of a risk considers when
and for how long the impact will be felt
...

Returning once more to the risk analysis approach proposed by the U
...
Air Force
[AFC88], the following steps are recommended to determine the overall consequences
of a risk:

we
? How dothe
assess
consequences of a
risk?

1
...

2
...
1, determine the impact for each component based on the criteria shown
...
Complete the risk table and analyze the results as described in the preceding
sections
...

For example, assume that the software team deﬁnes a project risk in the following manner:
Risk identiﬁcation
...
The remaining functionality will have to
be custom developed
...
80% (likely)
...
60 reusable software components were planned
...
Since the average component is
100 LOC and local data indicate that the software engineering cost for each LOC is $14
...

Risk exposure
...
80 x 25,200 ~ $20,200
...
If RE is greater
than 50 percent of
project cost, the
viability of the project
must be evaluated
...
The total risk exposure for all risks (above the cutoff in
the risk table) can provide a means for adjusting the ﬁnal cost estimate for a project
...

The risk projection and analysis techniques described in Sections 6
...
1 and 6
...
2
are applied iteratively as the software project proceeds
...
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 positions of still others
...
4
...
During risk assessment, we further examine the accuracy of the estimates that
were made during risk projection, attempt to rank the risks that have been uncovered, and begin thinking about ways to control and/or avert risks that are likely to
occur
...
For most
software projects, the risk components discussed earlier—performance, cost, support, and schedule—also represent risk referent levels
...
4
Risk referent
level
Projected schedule overrun

Referent point (cost value, time value)

Project termination will occur

Projected cost overrun

formance degradation, cost overrun, support difﬁculty, or schedule slippage (or any
combination of the four) that will cause the project to be terminated
...

Once risk exposure
exceeds the referent
level, the project may
be terminated
...
In the context of software risk analysis, a risk referent level
has a single point, called the referent point or break point, at which the decision to
proceed with the project or terminate it (problems are just too great) are equally
weighted
...
4 represents this situation graphically
...

In most cases it is a region in which there are areas of uncertainty; that is, attempting to predict a management decision based on the combination of referent values
is often impossible
...
Deﬁne the risk referent levels for the project
...
Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels
...
Predict the set of referent points that deﬁne a region of termination, bounded
by a curve or areas of uncertainty
...
Try to predict how compound combinations of risks will affect a referent
level
...
g
...

156

PA R T T W O

6
...
As time
passes and more is learned about the project and the risk, it may be possible to reﬁne
the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor,
and manage
...
That is, the risk is stated in the following form:
Given that then there is concern that (possibly)
...
4
...

This general condition can be reﬁned in the following manner:
Subcondition 1
...

Subcondition 2
...

Subcondition 3
...

The consequences associated with these reﬁned subconditions remains the same (i
...
,
30 percent of software components must be customer engineered), but the reﬁnement
helps to isolate the underlying risks and might lead to easier analysis and response
...
6

R I S K M I T I G AT I O N , M O N I T O R I N G , A N D M A N A G E M E N T
All of the risk analysis activities presented to this point have a single goal—to assist
the project team in developing a strategy for dealing with risk
...
”
Napolean

• risk avoidance
• risk monitoring
• risk management and contingency planning
If a software team adopts a proactive approach to risk, avoidance is always the best
strategy
...
For example, assume
that high staff turnover is noted as a project risk, r1
...
70 (70 percent, rather high) and the impact, x1, is projected at level 2
...

To mitigate this risk, project management must develop a strategy for reducing

WebRef
An excellent FAQ on risk
management can be
obtained at
www
...
cmu
...
faq
...
Among the possible steps to be taken are
• Meet with current staff to determine causes for turnover (e
...
, poor working
conditions, low pay, competitive job market)
...

• Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave
...

• Deﬁne documentation standards and establish mechanisms to be sure that
documents are developed in a timely manner
...

• Assign a backup staff member for every critical technologist
...
The project manager
monitors factors that may provide an indication of whether the risk is becoming
more or less likely
...

“We are ready for an
unforseen event that
may or may not
occur
...

• Interpersonal relationships among team members
...

• The availability of jobs within the company and outside it
...
For example, a risk mitigation step noted here called
for the deﬁnition of documentation standards and mechanisms to be sure that documents are developed in a timely manner
...
The project manager should
monitor documents carefully to ensure that each can stand on its own and that each
imparts information that would be necessary if a newcomer were forced to join the
software team somewhere in the middle of the project
...
Continuing the example, the project is

158

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

well underway and a number of people announce that they will be leaving
...
In addition, the project manager
may temporarily refocus resources (and readjust the project schedule) to those functions that are fully staffed, enabling newcomers who must be added to the team to
“get up to speed
...
” This might include video-based
knowledge capture, the development of “commentary documents,” and/or meeting
with other team members who will remain on the project
...
For example, spending the time to "backup" every critical technologist costs money
...

risk management, therefore, is to evaluate when the beneﬁts accrued by the RMMM
steps are outweighed by the costs associated with implementing them
...
If risk aversion steps for
high turnover will increase both project cost and duration by an estimated 15 percent, but the predominant cost factor is "backup," management may decide not to
implement this step
...

For a large project, 30 or 40 risks may identiﬁed
...
Experience
indicates that 80 percent of the overall project risk (i
...
, 80 percent of the potential
for project failure) can be accounted for by only 20 percent of the identiﬁed risks
...
g
...
For this reason, some of the risks identiﬁed, assessed, and projected may
not make it into the RMMM plan—they don't fall into the critical 20 percent (the risks
with highest project priority)
...
7

SAFETY RISKS AND HAZARDS
Risk is not limited to the software project itself
...
These risks are typically associated with the consequences of software failure in the ﬁeld
...
Although the probability
of failure of a well-engineered system was small, an undetected fault in a computerbased control or monitoring system could result in enormous economic damage or,
worse, signiﬁcant human injury or loss of life
...
Today, computer hardware and software are used regularly to control safety critical systems
...
Subtle design faults induced by human error—some-

WebRef

thing that can be uncovered and eliminated in hardware-based conventional con-

A voluminous database
containing all entries from
the ACM’s Forum on Risks
to the Public can be found
at
catless
...
ac
...
html

trol—become much more difﬁcult to uncover when software is used
...
If hazards can
be identiﬁed early in the software engineering process, software design features can
be speciﬁed that will either eliminate or control potential hazards
...
8

THE RMMM PLAN

A risk management strategy can be included in the software project plan or the risk
management steps can be organized into a separate Risk Mitigation, Monitoring and
Management Plan
...

Some software teams do not develop a formal RMMM document
...
In most cases,
the RIS is maintained using a database system, so that creation and information entry,
priority ordering, searches, and other analysis may be accomplished easily
...
5
...
As we have already discussed, risk mitigation is a problem avoidance activity
...
In many cases, the problems that occur during a project can be traced to more than one risk
...

6
...
And yet, most software project managers do it informally and superficially, if
they do it at all
...

160

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

F I G U R E 6
...
The remaining functionality will have to be custom
developed
...

Subcondition 2: The design standard for component interfaces has not been
solidified and may not conform to certain existing reusable components
...

Mitigation/monitoring:
1
...

2
...

3
...

Management/contingency plan/trigger:
RE computed to be $20,200
...

Develop revised schedule assuming that 18 additional components will have to be
custom built; allocate staff accordingly
...

Originator:

D
...
Laster

Risk analysis can absorb a signiﬁcant amount of project planning effort
...
But the
effort is worth it
...
" For the software project manager, the enemy is risk
...
S
...

[BOE89] Boehm, B
...
, Software Risk Management, IEEE Computer Society Press,
1989
...
N
...

CHAPTER 6

R I S K A N A LY S I S A N D M A N A G E M E N T

161

[CHA92] Charette, R
...
, “Building Bridges over Intelligent Rivers,” American Programmer, vol
...
7, September, 1992, pp
...

[DRU75] Drucker, P
...
H
...

[GIL88]

Gilb, T
...

[GLU94] Gluch, D
...
, “A Construct for Describing Software Development Risks,”
CMU/SEI-94-TR-14, Software Engineering Institute, 1994
...
M
...

[HIG95] Higuera, R
...
, “Team Risk Management,” CrossTalk, U
...
Dept
...
2–4
...
W
...

[KEI98]

Keil, M
...
, “A Framework for Identifying Software Project Risks,” CACM,

vol
...
11, November 1998, pp
...

[LEV95] Leveson, N
...
, Safeware: System Safety and Computers, Addison-Wesley,
1995
...
D
...
Krieger Publishing Co
...

[SEI93] “Taxonomy-Based Risk Identification,” Software Engineering Institute,
CMU/SEI-93-TR-6, 1993
...
, “The Indiana Jones School of Risk Management,” American
Programmer, vol
...
7, September 1992, pp
...

[WIL97] Williams, R
...
A
...
J
...
75–81
...
1
...

6
...
Describe the difference between “known risks” and “predictable risks
...
3
...

6
...
You’ve been asked to build software to support a low-cost video editing system
...
The result can then be output to tape
...

6
...
You’re the project manager for a major software company
...
4
...
Create a risk table for the project
...
6
...

6
...
Develop a risk mitigation strategy and speciﬁc risk mitigation activities for three
of the risks noted in Figure 6
...

6
...
Develop a risk monitoring strategy and specific risk monitoring activities for
three of the risks noted in Figure 6
...
Be sure to identify the factors that you’ll be monitoring to determine whether the risk is becoming more or less likely
...
9
...
2
...
10
...
2 and then create risk
information sheets for each
...
11
...
2 using a CTC format
...
12
...
4
...

6
...
Can you think of a situation in which a high-probability, high-impact risk would
not be considered as part of your RMMM plan?
6
...
Referring the the risk referent shown on Figure 6
...
If so, suggest a scenario in which this might happen
...
15
...
Do a Web search to get current information
...
16
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
The software risk management literature has expanded signiﬁcantly in recent years
...
Karolak
[KAR96] has written a guidebook that introduces an easy-to-use risk analysis model
with worthwhile checklists and questionnaires
...
His abbreviated treatment provides a good introduction to the subject
...
B
...
Ward, Project Risk Management: Processes, Techniques and Insights,
Wiley, 1997
...
R
...

Wideman, R
...
(editor), Project & Program Risk Management: A Guide to Managing Project
Risks and Opportunities, Project Management Institute Publications, 1998
...
Jones deﬁnes 60 risk factors that can affect the outcome
of software projects
...
Charette [CHA89] presents a
detailed treatment of the mechanics of risk analysis, calling on probability theory and
statistical techniques to analyze risks
...
Gilb (Principles of Software Engineering Management, Addison-Wesley, 1988)
presents a set of "principles" (which are often amusing and sometimes profound) that
can serve as a worthwhile guide for risk management
...

The Software Engineering Institute has published many detailed reports and guidebooks on risk analysis and management
...
Every
issue of the ACM Software Engineering Notes has a section entitled "Risks to the Public" (editor, P
...
Neumann)
...

A wide variety of information sources on risk analysis and management is available on the Internet
...
mhhe
...
mhtml

CHAPTER

PROJECT SCHEDULING AND
TRACKING

7
KEY
CONCEPTS
adaptation
criteria
...
181
earned value
...
187
lateness
...
189
project tracking
...
168
task network
...
172
timeline chart
...
181

QUICK
LOOK

n the late 1960s, a bright-eyed young engineer was chosen to "write" a computer program for an automated manufacturing application
...
He was the only person in his technical group who
had attended a computer programming seminar
...

His boss gave him the appropriate manuals and a verbal description of what
had to be done
...

He read the manuals, considered his approach, and began writing code
...

"Really great," said the young engineer with youthful enthusiasm, "This was
much simpler than I thought
...
"
The boss smiled
...
They planned to meet again in a week’s
time
...
At an individual level, software
engineers themselves
...
Now it’s time to connect the dots
...
These interdepen-

That is, you have to create a network of software

dencies are very difﬁcult to understand without a

engineering tasks that will enable you to get the

schedule
...
Once the network is created,

progress on a moderate or large software project

you have to assign responsibility for each task,

without a detailed schedule
...
In a nutshell, that’s software

tasks dictated by the software process model are

project scheduling and tracking
...
Effort and

Who does it? At the project level, software proj-ect

duration are allocated to each task and a task

managers using information solicited from soft-

network (also called an “activity network”) is

165

166

PA R T T W O

QUICK
LOOK

M A N A G I N G S O F T WA R E P R O J E C T S

created in a manner that enables

work, (2) effort and timing are intelligently allo-

the software team to meet the

cated to each task, (3) interdependencies between

delivery deadline established
...

How do I ensure that I’ve done it right? Proper sched-

cated for the work to be done, and (5) closely
spaced milestones are provided so that progress
can be tracked
...

I'll get them ironed out and be back on track soon
...

"No problem," said the engineer
...
"
If you've been working in the software world for more than a few years, you can ﬁnish the story
...

This story has been repeated tens of thousands of times by software developers
during the past three decades
...
1

BASIC CONCEPTS
Although there are many reasons why software is delivered late, most can be traced
to one or more of the following root causes:
•

An unrealistic deadline established by someone outside the software development group and forced on managers and practitioner's within the group
...
”

Changing customer requirements that are not reﬂected in schedule changes
...

•

Predictable and/or unpredictable risks that were not considered when the
project commenced
...

•

Human difﬁculties that could not have been foreseen in advance
...

•

Capers Jones

A failure by project management to recognize that the project is falling
behind schedule and a lack of action to correct the problem
...

Sometimes such deadlines are demanded for reasons that are legitimate, from the
1

If you’re wondering whether this story is autobiographical, it is!

CHAPTER 7

PROJECT SCHEDULING AND TRACKING

167

point of view of the person who sets the deadline
...

7
...
1

Comments on “Lateness”

Napoleon once said: "Any commander in chief who undertakes to carry out a plan
which he considers defective is at fault; he must put forth his reasons, insist on the
plan being changed, and ﬁnally tender his resignation rather than be the instrument
of his army's downfall
...

The estimation and risk analysis activities discussed in Chapters 5 and 6, and the
scheduling techniques described in this chapter are often implemented under the

“I love deadlines
...
”
Douglas Adams

constraint of a deﬁned deadline
...
[and] reﬂect the pressure back to its originators" [PAG85]
...
After careful estimation and risk analysis, the software
project manager comes to the conclusion that the software, as requested, will require
14 calendar months to create with available staff
...
External market
pressures have dictated the date, and the product must be released
...
So, what to do?
The following steps are recommended in this situation:

? What should
we do when

1
...
Determine the estimated effort and duration for the project
...
Using an incremental process model (Chapter 2), develop a software engineering strategy that will deliver critical functionality by the imposed deadline, but delay other functionality until later
...

3
...
Be certain to note that all estimates are
based on performance on past projects
...
2 The following comment is appropriate:
"I think we may have a problem with the delivery date for the XYZ controller
software
...

But, more likely, the percent of improvement in team performance must be greater than 50 percent
...

168

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

rates for past projects and an estimate that we've done a number of different
ways
...
"
4
...

First, we can increase the budget and bring on additional resources so that

XRef

we'll have a shot at getting this job done in nine months
...

this will increase risk of poor quality due to the tight timeline
...
This will make the preliminary version of the product somewhat
less functional, but we can announce all functionality and then deliver over
the 14 month period
...
We'll wind up with nothing that can be delivered to
a customer
...
Past history and our best estimates say that it is unrealistic and a recipe for disaster
...
The
unrealistic deadline evaporates
...
1
...
His response was as simple as it
was profound: "One day at a time
...
Some of these tasks lie outside the mainstream and may
be completed without worry about impact on project completion date
...
4 If these "critical" tasks fall behind schedule, the completion
date of the entire project is put into jeopardy
...

There are many
excellent project
scheduling tools
...

The project manager’s objective is to deﬁne all project tasks, build a network that
depicts their interdependencies, identify the tasks that are critical within the network,
and then track their progress to ensure that delay is recognized "one day at a time
...

Software project scheduling is an activity that distributes estimated effort across the
planned project duration by allocating the effort to speciﬁc software engineering tasks
...

4

The critical path will be discussed in greater detail later in this chapter
...
During early
stages of project planning, a macroscopic schedule is developed
...
As the project gets under way, each entry on the macroscopic
schedule is reﬁned into a detailed schedule
...

“Overly optimistic
scheduling doesn’t
result in shorter
actual schedules, it
results in longer
ones
...
In the ﬁrst, an end-date for release of a computer-based system
has already (and irrevocably) been established
...
The second view of software scheduling assumes that rough chronological bounds have been discussed but
that the end-date is set by the software engineering organization
...
Unfortunately, the ﬁrst situation is encountered far more frequently than
the second
...
The project must be compartmentalized into a
number of manageable activities and tasks
...

Interdependency
...
Some tasks must occur in sequence while others
can occur in parallel
...

uct produced by another is available
...

Time allocation
...
g
...
In addition, each task must be
assigned a start date and a completion date that are a function of the interdependencies and whether work will be conducted on a full-time or part-time
basis
...
Every project has a deﬁned number of staff members
...
For
example, consider a project that has three assigned staff members (e
...
, 3
person-days are available per day of assigned effort5)
...
Each task requires 0
...
More effort has been allocated than there are people to do the work
...
Every task that is scheduled should be assigned
to a speciﬁc team member
...
For our purposes, however, we assume 100 percent
availability
...
Every task that is scheduled should have a deﬁned outcome
...
g
...
Work products are often
combined in deliverables
...
Every task or group of tasks should be associated with
a project milestone
...

Each of these principles is applied as the project schedule evolves
...
2

T H E R E L AT I O N S H I P B E T W E E N P E O P L E A N D E F F O R T
In a small software development project a single person can analyze requirements,
perform design, generate code, and conduct tests
...
(We can rarely afford the luxury of approaching a ten person-year effort with one person working for ten years!)
There is a common myth (discussed in Chapter 1) that is still believed by many
managers who are responsible for software development effort: "If we fall behind
schedule, we can always add more programmers and catch up later in the project
...

Unfortunately, adding people late in a project often has a disruptive effect on the project, causing schedules to slip even further
...
While teaching, no work is done, and the project falls further behind
...
Although communication is absolutely essential to successful software
development, every new communication path requires additional effort and therefore additional time
...
2
...
When these four engineers are placed on a team
project, six potential communication paths are possible
...
We shall assume
that team productivity (when measured in LOC) will be reduced by 250 LOC/year for
each communication path, due to the overhead associated with communication
...
5 percent
less than what we might expect
...
The jury is still out!

CHAPTER 7

PROJECT SCHEDULING AND TRACKING

171

The one-year project on which the team is working falls behind schedule, and with
two months remaining, two additional people are added to the team
...
The productivity input of the new staff is the

The relationship
between the number
of people working on a
software project and
overall productivity is
not linear
...
Team
productivity now is 20,000 + 1680 Ϫ (250 x 14) = 18,180 LOC/year
...

Based on the people/work relationship, are teams counterproductive? The answer
is an emphatic "no," if communication improves software quality
...
Hence, productivity and
quality, when measured by time to project completion and customer satisfaction, can
actually improve
...
2
...
An Empirical Relationship
Recalling the software equation [PUT92] that was introduced in Chapter 5, we can
demonstrate the highly nonlinear relationship between chronological time to complete a project and human effort applied to the project
...

Rearranging this software equation, we can arrive at an expression for development effort E:

As the deadline
becomes tighter and
tighter, you reach a
point at which the
work cannot be
completed on
schedule, regardless of
the number of people
doing the work
...

E = L3/( P3t4 )

(7-1)

where E is the effort expended (in person-years) over the entire life cycle for software
development and maintenance and t is the development time in years
...

This leads to some interesting results
...
If eight people are assigned
to the project team, the project can be completed in approximately 1
...
If, however, we extend the end-date to 1
...
8 person-years
...

7
...
3

Effort Distribution

Each of the software project estimation techniques discussed in Chapter 5 leads to
estimates of work units (e
...
, person-months) required to complete software devel-

?

How much
effort should
be expended on
each of the major
software
engineering
tasks?

opment
...
7 Forty percent of all effort is allocated
to front-end analysis and design
...

You can correctly infer that coding (20 percent of effort) is de-emphasized
...
The characteristics of
each project must dictate the distribution of effort
...
Requirements analysis may comprise 10–25 percent of project effort
...
A range of 20 to 25
percent of effort is normally applied to software design
...

Because of the effort applied to software design, code should follow with relatively
little difﬁculty
...
Testing and
subsequent debugging can account for 30–40 percent of software development effort
...
If
software is human rated (i
...
, software failure can result in loss of life), even higher
percentages are typical
...
3

D E F I N I N G A TA S K S E T F O R T H E S O F T WA R E P R O J E C T
A number of different process models were described in Chapter 2
...
Regardless of whether a software team chooses a linear sequential paradigm, an iterative paradigm, an evolutionary paradigm, a concurrent paradigm or some permutation, the process model
is populated by a set of tasks that enable a software team to deﬁne, develop, and ultimately support computer software
...
The set of tasks that would be
appropriate for a large, complex system would likely be perceived as overkill for a
small, relatively simple software product
...
Hence, the name 40–20–40 no longer applies in a
strict sense
...

A task set is a collection of software engineering work tasks, milestones, and deliv-

A “task set” is a
collection of software
engineering tasks,
milestones, and
deliverables
...
The task set to
be chosen must provide enough discipline to achieve high software quality
...

Task sets are designed to accommodate different types of projects and different
degrees of rigor
...
Concept development projects that are initiated to explore some new business
concept or application of some new technology
...
New application development projects that are undertaken as a consequence
of a speciﬁc customer request
...
Application enhancement projects that occur when existing software undergoes major modiﬁcations to function, performance, or interfaces that are
observable by the end-user
...
Application maintenance projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end-user
...
Reengineering projects that are undertaken with the intent of rebuilding an
existing (legacy) system in whole or in part
...

When taken in combination, these factors provide an indication of the degree of rigor
with which the software process should be applied
...
3
...
The degree of rigor is a function of many

The task set will grow
in size and complexity
as the degree of rigor
grows
...
As an example, small, non-business-critical projects can generally be addressed with somewhat less rigor than large, complex business-critical
applications
...
Four different degrees of rigor
can be deﬁned:
Casual
...
In general, umbrella tasks will be minimized
and documentation requirements will be reduced
...

Structured
...
Framework activities and related tasks appropriate to the project type will be
applied and umbrella activities necessary to ensure high quality will be

174

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

applied
...

Strict
...
All umbrella activities will be applied and
robust work products will be produced
...
The process framework will be applied for this project, but

If everything is an
emergency, there’s
something wrong with
your software process
or with the people who
manage the business
or both
...
“Back-ﬁlling” (i
...
, developing a complete set of
documentation, conducting additional reviews) will be accomplished after
the application/product is delivered to the customer
...
To accomplish this, project adaptation criteria are deﬁned and a task set selector value is computed
...
3
...
Eleven adaptation criteria [PRE99]
are deﬁned for software projects:
•
•

Number of potential users

•

Mission criticality

•

Application longevity

•

Stability of requirements

•

Ease of customer/developer communication

•

Maturity of applicable technology

•

Performance constraints

•

Embedded and nonembedded characteristics

•

Project staff

•

Adaptable Process Model

Size of the project

Reengineering factors

Each of the adaptation criteria is assigned a grade that ranges between 1 and 5, where
1 represents a project in which a small subset of process tasks are required and overall methodological and documentation requirements are minimal, and 5 represents
a project in which a complete set of process tasks should be applied and overall
methodological and documentation requirements are substantial
...
An emergency is not the same as a project
with tight time constraints
...
1

175

PROJECT SCHEDULING AND TRACKING

COMPUTING THE TASK SET SELECTOR

Adaptation Criteria

Grade

Weight
Conc
...

Enhan
...

Product
Reeng
...
20

0

1

1

1

1

_____

Number of users

_____

1
...
10

0

1

1

1

1

_____

Longevity

_____

0
...
20

0

1

1

1

1

_____

Ease of communication

_____

0
...
90

1

1

0

0

1

_____

Performance constraints

_____

0
...
20

1

1

1

0

1

_____

Project stafﬁng

_____

1
...
10

0

1

1

1

1

_____

Reengineering factors

_____

1
...
3
...
Review each of the adaptation criteria in Section 7
...
2 and assign the appropriate grades (1 to 5) based on the characteristics of the project
...
1
...
Review the weighting factors assigned to each of the criteria
...
8 to 1
...
If modiﬁcations are required to better reﬂect local circumstances, they should be made
...
Multiply the grade entered in Table 7
...
The entry point
multiplier takes on a value of 0 or 1 and indicates the relevance of the adaptation criterion to the project type
...
1 for each adaptation criteria individually
...
Compute the average of all entries in the Product column and place the result
in the space marked task set selector (TSS)
...

176
TA B L E 7
...

Entry Point Multiplier
NDev
...

Maint
...

Size of project

2

1
...
4

Number of users

3

1
...
3

Business criticality

4

1
...
4

Longevity

3

0
...
7

Stability of requirements

2

1
...
4

Ease of communication

2

0
...
8

Maturity of technology

2

0
...
8

Performance constraints

3

0
...
4

Embedded/nonembedded

3

1
...
6

Project stafﬁng

2

1
...
0

Interoperability

4

1
...
4

Reengineering factors

0

1
...
0

Task set selector (TSS)

2
...
3
...
2

casual

1
...
0

If the task set selector
value is in an overlap
area, it usually is OK to
choose the less formal
degree of rigor, unless
project risk is high
...
4

strict

The overlap in TSS values from one recommended task set to another is purposeful
and is intended to illustrate that sharp boundaries are impossible to deﬁne when making task set selections
...

Table 7
...
The
project manager selects the grades shown in the Grade column
...
Therefore, entry point multipliers are selected from the
NDev column
...
8
...
The ﬁnal decision is made once all project factors
have been considered
...
4

PROJECT SCHEDULING AND TRACKING

177

S E L E C T I N G S O F T WA R E E N G I N E E R I N G TA S K S
In order to develop a project schedule, a task set must be distributed on the project
time line
...
3, the task set will vary depending upon the project type and the degree of rigor
...
3
may be approached using a process model that is linear sequential, iterative (e
...
, the
prototyping or incremental models), or evolutionary (e
...
, the spiral model)
...
For example, concept development projects that succeed often evolve into new application development projects
...

As a new application development project ends, an application enhancement project sometimes begins
...
Therefore, the
major software engineering tasks described in the sections that follow are applicable to all process model ﬂows
...

Concept development projects are initiated when the potential for some new technology must be explored
...
g
...
Concept
development projects are approached by applying the following major tasks:
Concept scoping determines the overall scope of the project
...

Technology risk assessment evaluates the risk associated with the technology to be implemented as part of project scope
...

Concept implementation implements the concept representation in a
manner that can be reviewed by a customer and is used for “marketing” purposes when a concept must be sold to other customers or management
...

A quick scan of these tasks should yield few surprises
...

The software team must understand what must be done (scoping); then the team
(or manager) must determine whether anyone is available to do it (planning), consider the risks associated with the work (risk assessment), prove the technology in
some way (proof of concept), and implement it in a prototypical manner so that the
customer can evaluate it (concept implementation and customer evaluation)
...

178

PA R T T W O

F I G U R E 7
...
1 Concept scoping

1
...
2 Preliminary concept planning
1
...
6 Customer reaction

1
...
That is, an actual concept development project might approach these
activities in a number of planned increments, each designed to produce a deliverable
that can be evaluated by the customer
...
1
...
With each iteration, the deliverable should converge toward the deﬁned end product for the concept development stage
...
1 through 1
...
2
...

7
...
4 may be used to define a macroscopic
schedule for a project
...
Refinement begins by taking each major task
and decomposing it into a set of subtasks (with related work products and milestones)
...
4
...
2
Concept
development
tasks using an
evolutionary
model

179

PROJECT SCHEDULING AND TRACKING

Preliminary concept planning
Technology risk assessment

Planning
Engineering/
construction

Project definition
Concept scoping

Proof of concept

Re-engineering

Application
Application enhancement
maintenance

New Application
development

Concept implementation
Customer reaction

Release

Customer
evaluation
Task deﬁnition: Task I
...

I
...
1
Identify need, beneﬁts and potential customers;
I
...
2
Deﬁne desired output/control and input events that drive the application;
Begin Task I
...
2
I
...
2
...
1
...
2 Derive a list of customer visible outputs/inputs
case of: mechanics
mechanics = quality function deployment
meet with customer to isolate major concept requirements;
interview end-users;
observe current approach to problem, current process;
review past requests and complaints;
mechanics = structured analysis
make list of major data objects;
deﬁne relationships between objects;
deﬁne object attributes;
mechanics = object view
make list of problem classes;
develop class hierarchy and class connections;
deﬁne attributes for classes;
endcase
I
...
2
...
1
...
1
...
1
...

180

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

I
...
3
...
1
...
2

FTR: Review output and input data objects derived in task I
...
2;
Derive a model of functions/behaviors;
case of: mechanics
mechanics = quality function deployment
meet with customer to review major concept requirements;
interview end-users;
observe current approach to problem, current process;
develop a hierarchical outline of functions/behaviors;
mechanics = structured analysis
derive a context level data ﬂow diagram;
reﬁne the data ﬂow diagram to provide more detail;
write processing narratives for functions at lowest level of reﬁnement;
mechanics = object view
deﬁne operations/methods that are relevant for each class;
endcase
I
...
3
...
1
...
1
...
1
...
1
...
1
...
1
...
1

The tasks and subtasks noted in the process design language reﬁnement form the
basis for a detailed schedule for the concept scoping activity
...
6

D E F I N I N G A TA S K N E T W O R K
Individual tasks and subtasks have interdependencies based on their sequence
...
When

The task network is a
useful mechanism for
depicting intertask
dependencies and
determining the critical
path
...

A task network, also called an activity network, is a graphic representation of the
task ﬂow for a project
...
In its
simplest form (used when creating a macroscopic schedule), the task network depicts
major software engineering tasks
...
3 shows a schematic task network for a
concept development project
...
Because parallel tasks occur asynchronously, the
planner must determine intertask dependencies to ensure continuous progress toward
completion
...
That is, tasks that must be completed on schedule if the project

CHAPTER 7

181

PROJECT SCHEDULING AND TRACKING

I
...
risk
assessment

I
...
2
Concept
planning

I
...
Risk
assessment

I
...

I
...
5b
Concept
implement
...
3c
Tech
...
5c
Concept
implement
...
6
Customer
reaction

Three I
...
3 A task network for concept development

as a whole is to be completed on schedule
...

It is important to note that the task network shown in Figure 7
...

In a detailed task network (a precursor to a detailed schedule), each activity shown
in Figure 7
...
For example, Task I
...
1 shown in Section 7
...

7
...
Therefore, generalized project scheduling tools and tech-

For all but the simplest
projects, scheduling
should be done with
the aid of a project
scheduling tool
...

Program evaluation and review technique (PERT) and critical path method (CPM)
[MOD83] are two project scheduling methods that can be applied to software development
...
Tasks, sometimes called the project work breakdown structure (WBS), are deﬁned for the product
as a whole or for individual functions
...

Boundary time calculations can be very useful in software project scheduling
...
Riggs [RIG81] describes important boundary times that may be discerned from a PERT or CPM network: (1) the earliest time that a task can begin when
all preceding tasks are completed in the shortest possible time, (2) the latest time for
task initiation before the minimum project completion time is delayed, (3) the earliCASE tools
project/scheduling and
planning

est ﬁnish—the sum of the earliest start and the task duration, (4) the latest ﬁnish—
the latest start time added to task duration, and (5) the total float—the amount of
surplus time or leeway allowed in scheduling tasks so that the network critical path
is maintained on schedule
...

Both PERT and CPM have been implemented in a wide variety of automated tools
that are available for the personal computer [THE93]
...

7
...
1

Timeline Charts

When creating a software project schedule, the planner begins with a set of tasks (the
work breakdown structure)
...
Effort, duration, and start date are then input for
each task
...

As a consequence of this input, a timeline chart, also called a Gantt chart, is gen-

A timeline chart
enables you to
determine what tasks
will be conducted at a
given point in time
...
A timeline chart can be developed for the entire project
...

Figure 7
...
It depicts a part of a software
project schedule that emphasizes the concept scoping task (Section 7
...
All project tasks (for concept scoping) are
listed in the left-hand column
...

When multiple bars occur at the same time on the calendar, task concurrency is
implied
...

Once the information necessary for the generation of a timeline chart has been
input, the majority of software project scheduling tools produce project tables—a tabular listing of all project tasks, their planned and actual start- and end-dates, and a
variety of related information (Figure 7
...
Used in conjunction with the timeline chart,
project tables enable the project manager to track progress
...
1
...
1
...
1
...
1
...
1
...
1
...
1
...
1
...
4 An example timeline chart

Week 1

Week 2

Week 3

Week 4

Week 5

184

Work tasks
I
...
1 Identify needs and benefits
Meet with customers
Identify needs and project constraints
Establish product statement
Milestone: Product statement defined
I
...
2 Define desired output/control/input (OCI)
Scope keyboard functions
Scope voice input functions
Scope modes of interaction
Scope document diagnostics
Scope other WP functions
Document OCI
FTR: Review OCI with customer
Revise OCI as required
Milestone: OCI defined
I
...
3 Define the function/behavior

F I G U R E 7
...
5 p-d
2 p-d
1 p-d
1
...
7
...
If it has
been properly developed, the project schedule deﬁnes the tasks and milestones that
must be tracked and controlled as the project proceeds
...

software status
reporting can be
summarized in a
single phrase: ‘No
surprises!’
...

•

Determining whether formal project milestones (the diamonds shown in Figure 7
...

Comparing actual start-date to planned start-date for each project task listed
in the resource table (Figure 7
...

•

Meeting informally with practitioners to obtain their subjective assessment of
progress to date and problems on the horizon
...
8) to assess progress quantitatively
...

Control is employed by a software project manager to administer project
resources, cope with problems, and direct project staff
...
e
...

is being made and milestones are being reached), control is light
...
After a problem has been diagnosed,10 additional resources may be
focused on the problem area: staff may be redeployed or the project schedule can
be redefined
...
The
time-boxing strategy recognizes that the complete product may not be deliverable
by the predeﬁned deadline
...

The tasks associated with each increment are then time-boxed
...
A “box” is put around each task
...

The initial reaction to the time-boxing approach is often negative: “If the work isn’t
ﬁnished, how can we proceed?” The answer lies in the way work is accomplished
...
The role
of the project manager is to diagnose the underlying problem and act to correct it
...
11 The remaining 10 percent, although important, can
(1) be delayed until the next increment or (2) be completed later if required
...

7
...
7
...
Each provides the project manager with an indication of progress, but an assessment of the information provided is somewhat subjective
...

whether there is a quantitative technique for assessing progress as the software team
progresses through the work tasks allocated to the project schedule
...
It is called earned
value analysis (EVA)
...
The total hours to do the whole project are
estimated, and every task is given an earned value based on its estimated percentage of
the total
...
It enables us to
assess the “percent of completeness” of a project using quantitative analysis rather
than rely on a gut feeling
...
”
To determine the earned value, the following steps are performed:

? How do I
compute
earned value to
assess progress?

1
...
During the estimation activity (Chapter 5), the
work (in person-hours or person-days) of each software engineering task is
planned
...
To determine
progress at a given point along the project schedule, the value of BCWS is the
sum of the BCWSi values for all work tasks that should have been completed
by that point in time on the project schedule
...
The BCWS values for all work tasks are summed to derive the budget at completion, BAC
...
Next, the value for budgeted cost of work performed (BCWP) is computed
...

11 A cynic might recall the saying: “The ﬁrst 90 percent of a system takes 90 percent of the time
...
”

CHAPTER 7

PROJECT SCHEDULING AND TRACKING

187

Wilkens [WIL99] notes that “the distinction between the BCWS and the BCWP is that the
former represents the budget of the activities that were planned to be completed and
the latter represents the budget of the activities that actually were completed
...
An SPI value close to 1
...
SV is simply an absolute indication of variance from the planned schedule
...
acq
...
mil/
pm/

provides an indication of the percentage of work that should have been completed
by time t
...

It is also possible to compute the actual cost of work performed, ACWP
...
It is then possible to compute
Cost performance index, CPI = BCWP/ACWP
Cost variance, CV = BCWP – ACWP
A CPI value close to 1
...
CV is an absolute indication of cost savings (against planned costs)
or shortfall at a particular stage of a project
...
This enables the software project
manager to take corrective action before a project crisis develops
...
9

ERROR TRACKING
Throughout the software process, a project team creates work products (e
...
, requirements speciﬁcations or prototype, design documents, source code)
...

creates (and hopefully corrects) errors associated with each work product
...
Error tracking can be used as one means for assessing the status of a current project
...
To review
brieﬂy, the software team performs formal technical reviews (and, later, testing) to
ﬁnd and correct errors, E, in work products produced during software engineering

188

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

tasks
...
Defect removal efﬁciency (Chapter 4) has been deﬁned as
DRE = E/(E + D)
DRE is a process metric that provides a strong indication of the effectiveness of
quality assurance activities, but DRE and the error and defect counts associated with
it can also be used to assist a project manager in determining the progress that is
being made as a software project moves through its scheduled work tasks
...
The project manager calculates current values for Ereq, Edesign, and
Ecode
...
If current results vary
by more than 20% from the average, there may be cause for concern and there is certainly cause for investigation
...
1 for project X, yet the organizational average is 3
...
If the second scenario appears likely, the project manager should take

The more quantitative
your approach to
project tracking and
control, the more likely
you’ll be able to
foresee potential
problems and respond
to them proactively
...

immediate steps to build additional design time12 into the schedule to accommodate
the requirements defects that have likely been propagated into the design activity
...
For example, if a system is composed of 120 components, but 32 of
these component exhibit Edesign values that have substantial variance from the average, the project manager might elect to dedicate code review resources to the 32
components and allow others to pass into testing with no code review
...

12 In reality, the extra time will be spent reworking requirements defects, but the work will occur
when the design is underway
...
10

PROJECT SCHEDULING AND TRACKING

189

THE PROJECT PLAN
Each step in the software engineering process should produce a deliverable that can
be reviewed and that can act as a foundation for the steps that follow
...
It provides baseline
cost and scheduling information that will be used throughout the software process
...
It must (1) communicate scope and resources to software management,
technical staff, and the customer; (2) deﬁne risks and suggest risk aversion techniques;
(3) deﬁne cost and schedule for management review; (4) provide an overall approach

Software Project Plan

to software development for all people associated with the project; and (5) outline
how quality will be ensured and change will be managed
...
If the
plan is used only as an internal document, the results of each estimation technique
can be presented
...

Similarly, the degree of detail contained within the schedule section may vary with
the audience and formality of the plan
...
That
is, the project team revisits the plan repeatedly—updating risks, estimates, schedules
and related information—as the project proceeds and more is learned
...
11

SUMMARY
Scheduling is the culmination of a planning activity that is a primary component of
software project management
...

Scheduling begins with process decomposition
...
A task network
depicts each engineering task, its dependency on other tasks, and its projected duration
...
Using the schedule as a guide, the project manager
can track and control each step in the software process
...
, The Mythical Man-Month, Anniversary Edition, AddisonWesley, 1995
...
W
...
M
...
11, no
...
19
...
, A Discipline for Software Engineering, Addison-Wesley, 1995
...
, Practical Project Management, Dorset House, 1985, pp
...

190

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

[PRE99] Pressman, R
...
, Adaptable Process Model, R
...
Pressman & Associates, 1999
...
and W
...

[RIG81]

Riggs, J
...
, Wiley,

1981
...
, “Project Management Software That’s IS Friendly,” Datamation,
October 1, 1993, pp
...

[WIL99] Wilkens, T
...
, “Earned Value, Clear and Simple,” Primavera Systems, April
1, 1999, p
...

[ZAH95] Zahniser, R
...
34–38
...
1
...
How should
you proceed if you’re faced with one?
7
...
What is the difference between a macroscopic schedule and a detailed schedule
...
3
...

7
...
In Section 7
...
1, we present an example of the “communication overhead” that
can occur when multiple people work on a software project
...
Hint: You can
assume that reviews reduce rework and that rework can account for 20–40 percent
of a person’s time
...
5
...
Describe them
...
6
...
Using Putnam's
software equation (described in Section 7
...
2), develop a table that relates number of
people to project duration for a software project requiring 50,000 LOC and 15 personyears of effort (the productivity parameter is 5000 and B = 0
...
Assume that the software must be delivered in 24 months plus or minus 12 months
...
7
...
First, act as the customer (if you're a student,
that should be easy!) and specify the characteristics of a good system
...
) Using the estimation methods discussed in Chapter 5, develop an effort and
duration estimate for OLCRS
...
Deﬁne parallel work activities during the OLCRS project
...
Distribute effort throughout the project
...
Establish milestones for the project
...
8
...
3 as a guide compute the TSS for OLCRS
...
Select a project type and an appropriate task set for the project
...
9
...
Be sure to show tasks and milestones and to attach effort and duration estimates to each task
...

7
...
If an automated scheduling tool is available, determine the critical path for the
network deﬁned in problem 7
...

7
...
Using a scheduling tool (if available) or paper and pencil (if necessary), develop
a timeline chart for the OLCRS project
...
12
...
4 in much the
same way as concept scoping was reﬁned in Section 7
...

7
...
Assume you are a software project manager and that you’ve been asked to
compute earned value statistics for a small software project
...
At
the time that you’ve been asked to do the earned value analysis, 12 tasks have been
completed
...
The following scheduling data (in person-days) are available:
Task

Planned effort

Actual effort

1

12
...
5

2

15
...
0

3

13
...
0

4

8
...
5

5

9
...
0

6

18
...
0

7

10
...
0

8

4
...
5

9

12
...
0

10

6
...
5

11

5
...
0

12

14
...
5

13

16
...
0

—

15

8
...

7
...
Is it possible to use DRE as a metric for error tracking throughout a software
project? Discuss the pros and cons of using DRE for this purpose
...
O'Connell (How to Run Successful Projects II: The Silver Bullet,
Prentice-Hall, 1997) presents a step-by-step approach to project management that
will help you to develop a realistic schedule for your projects
...
McConnell (Software Project Survival Guide, Microsoft Press, 1998), Hoffman and Beaumont (Application Development: Managing a Project's Life Cycle, Midrange
Computing, 1997), Wysoki and his colleagues (Effective Project Management, Wiley,
1995), and Whitten (Managing Software Development Projects, 2nd ed
...
Boddie (Crunch Mode, Prentice-Hall, 1987) has written a
book for all managers who "have 90 days to do a six month project
...
Among the many offerings available are
Kerzner, H
...

Lewis, J
...
, Mastering Project Management: Applying Advanced Concepts of Systems Thinking,
Control and Evaluation, McGraw-Hill, 1998
...

A wide variety of information sources on project scheduling and management is
available on the Internet
...
mhhe
...
mhtml

CHAPTER

SOFTWARE QUALITY
ASSURANCE

8

he software engineering approach described in this book works toward
a single goal: to produce high-quality software
...
204
formal technical
reviews
...
216

The problem of quality management is not what people don't know about it
...
214

problem is what they think they do know
...
Everybody is for it
...
195

certain conditions, of course
...
(Even though they

quality costs
...
) Everyone thinks execution is only a matter of following

software safety
...
(After all, we do get along somehow
...
199

ple feel that problems in these areas are caused by other people
...
201

take the time to do things right
...
218

Some software developers continue to believe that software quality is something you begin to worry about after code has been generated
...

statistical SQA
...
194

What is it? It’s not enough to

ity in all software engineering activities, it reduces

talk the talk by saying that soft-

the amount of rework that it must do
...

you say “software quality,” (2) create a set of

What are the steps? Before software quality assur-

activities that will help ensure that every soft-

ance activities can be initiated, it is important to

ware engineering work product exhibits high

deﬁne ‘software quality’ at a number of different

quality, (3) perform quality assurance activities

levels of abstraction
...

Who does it? Everyone involved in the software engineering process is responsible for quality
...

What is the work product? A Software Quality Assurance Plan is created to deﬁne a software team’s
SQA strategy
...
If a software team stresses qual-

formal technical review summary report
...
Other work prod-

improve your defect removal efﬁciency (Chapters

ucts associated with process

4 and 7), thereby reducing the amount of rework

improvement may also be generated
...

How do I ensure that I’ve done it right? Find

SQA encompasses (1) a quality management approach, (2) effective software engineering technology (methods and tools), (3) formal technical reviews that are applied
throughout the software process, (4) a multitiered testing strategy, (5) control of software documentation and the changes made to it, (6) a procedure to ensure compliance with software development standards (when applicable), and (7) measurement
and reporting mechanisms
...
”

8
...
Certainly when we watch snow
falling it is hard to imagine that snowﬂakes differ at all, let alone that each ﬂake possesses a unique structure
...
In fact, the
closer we look, the more differences we are able to observe
...
For example, if two “identical” circuit boards are examined

“People forget how
fast you did a job —
but they always
remember how well
you did it
...

closely enough, we may observe that the copper pathways on the boards differ slightly
in geometry, placement, and thickness
...

All engineered and manufactured parts exhibit variation
...
However, with
sufﬁciently sensitive instruments, we will likely come to the conclusion that no two
samples of any item are exactly alike
...
A manufacturer wants to minimize
the variation among the products that are produced, even when doing something relatively simple like duplicating diskettes
...
S
...
Reprinted with permission
...

Or can we? We need to ensure the tracks are placed on the diskettes within a
specified tolerance so that the overwhelming majority of disk drives can read the
diskettes
...
The disk duplication machines
can, and do, wear and go out of tolerance
...
In the
software context, we
strive to control the
variation in the process
we apply, the
resources we expend,
and the quality
attributes of the end
product
...

But how does this apply to software work? How might a software development
organization need to control variation? From one project to another, we want to minimize the difference between the predicted resources needed to complete a project
and the actual resources used, including staff, equipment, and calendar time
...
Not only do we want to minimize the
number of defects that are released to the ﬁeld, we’d like to ensure that the variance
in the number of bugs is also minimized from one release to another
...
) We would like to minimize the differences in speed and accuracy of our hotline support responses to customer problems
...

8
...
1

Quality

The American Heritage Dictionary defines quality as “a characteristic or attribute of
something
...
However, software, largely an intellectual entity, is more
challenging to characterize than physical objects
...
These properties
include cyclomatic complexity, cohesion, number of function points, lines of code,
and many others, discussed in Chapters 19 and 24
...

“It takes less time to
do a thing right than
explain why you did
it wrong
...
The
grade of materials, tolerances, and performance speciﬁcations all contribute to the
quality of design
...

Quality of conformance is the degree to which the design specifications are followed during manufacturing
...

In software development, quality of design encompasses requirements, speciﬁcations, and the design of the system
...
If the implementation follows the design and the resulting system meets its requirements and performance goals, conformance quality is
high
...
DeMarco [DEM99] reinforces this view when he
states: “A product’s quality is a function of how much it changes the world for the
better
...

8
...
2

Quality Control

Variation control may be equated to quality control
...
Quality control includes a feedback loop to the process that
created the work product
...

This approach views quality control as part of the manufacturing process
...
A key concept of quality control is
that all work products have deﬁned, measurable speciﬁcations to which we may compare the output of each process
...

8
...
3

Quality Assurance

WebRef

Quality assurance consists of the auditing and reporting functions of management
...
qualitytree
...
htm

The goal of quality assurance is to provide management with the data necessary to
be informed about product quality, thereby gaining insight and conﬁdence that product quality is meeting its goals
...

8
...
4

Cost of Quality

The cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities
...
The basis of normalization is
almost always dollars
...
Furthermore, we can evaluate the effect of changes in dollar-based terms
...
Prevention costs include
•

quality planning

•

formal technical reviews

•

test equipment

•

training

Appraisal costs include activities to gain insight into product condition the “ﬁrst time
through” each process
...
Rest assured
that your investment
will provide an
excellent return
...
Failure costs may be subdivided into internal failure costs and
external failure costs
...
Internal failure costs include
•

rework

•

repair

•

failure mode analysis

External failure costs are associated with defects found after the product has been
shipped to the customer
...
Figure 8
...

Anecdotal data reported by Kaplan, Clark, and Tang [KAP95] reinforces earlier cost
statistics and is based on work at IBM’s Rochester development facility:

198

PA R T T W O

F I G U R E 8
...

Design

Code

Dev
...
Spend time
ﬁnding errors early in
the process and you
may be able to
signiﬁcantly reduce
testing and debugging
costs
...
Assuming a programmer cost of $40
...
00 per defect
...
Suppose that there had been no inspections, but that programmers had been extra careful and only one defect per 1000 lines of code [signiﬁcantly better
than industry average] escaped into the shipped product
...
At an estimated cost of $25,000 per ﬁeld ﬁx, the cost
would be $5 million, or approximately 18 times more expensive than the total cost of the
defect prevention effort
...
This in no way negates the results just noted
...

8
...

However, this was not always the case
...
Edwards Deming [DEM86] and had its ﬁrst true test in
Japan
...
Throughout the
1970s and 1980s, their work migrated to the western world and was given names

TQM can be applied to
computer software
...

such as “total quality management” (TQM)
...

The ﬁrst step, called kaizen, refers to a system of continuous process improvement
...

The second step, invoked only after kaizen has been achieved, is called atarimae
hinshitsu
...
For example, the software process may be affected
by high staff turnover, which itself is caused by constant reorganization within a company
...
Atarimae hinshitsu would lead management to suggest changes in the
way reorganization occurs
...
eng
...

edu/

lated as “the ﬁve senses”), concentrates on the user of the product (in this case, software)
...

Finally, a step called miryokuteki hinshitsu broadens management concern beyond
the immediate product
...
In the
software world, miryokuteki hinshitsu might be viewed as an attempt to uncover new
and profitable products or applications that are an outgrowth from an existing
computer-based system
...
Until a mature software process (Chapter 2) has been achieved, there is little point in moving to the next
steps
...
3 S O F T WA R E Q U A L I T Y A S S U R A N C E
Even the most jaded software developers will agree that high-quality software is an
important goal
...
"
Many deﬁnitions of software quality have been proposed in the literature
...

2

See [ART92] for a comprehensive discussion of TQM and its use in a software context and
[KAP95] for a discussion of the use of the Baldrige Award criteria in the software world
...
In fact, a
deﬁnitive deﬁnition of software quality could be debated endlessly
...

Software requirements are the foundation from which quality is measured
...

2
...
If the criteria are not followed, lack of
quality will almost surely result
...

A set of implicit requirements often goes unmentioned (e
...
, the desire for
ease of use and good maintainability)
...

8
...
1 Background Issues
Quality assurance is an essential activity for any business that produces products to
be used by others
...
”
Yogi Berra

responsibility of the craftsperson who built a product
...
During the 1940s, more formal approaches to
quality control were suggested
...

Today, every company has mechanisms to ensure quality in its products
...

The history of quality assurance in software development parallels the history of
quality in hardware manufacturing
...
Standards for quality

An in-depth tutorial and
wide-ranging resources for
quality management can
be found at
www
...

gov
...
Extending the definition presented earlier, software quality
assurance is a "planned and systematic pattern of actions" [SCH98] that are required
to ensure high quality in software
...
" The implication for software is that many different constituencies have
software quality assurance responsibility—software engineers, project managers,
customers, salespeople, and the individuals who serve within an SQA group
...
That is, the people who perform SQA must look at the software from the customer's point of view
...

8
...
2 SQA Activities
Software quality assurance is composed of a variety of tasks associated with two different constituencies—the software engineers who do technical work and an SQA
group that has responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting
...
Only reviews
are discussed in this chapter
...

The charter of the SQA group is to assist the software team in achieving a highquality end product
...
These activities are performed (or facilitated) by an independent SQA group that:

? Whatofisanthe
role

Prepares an SQA plan for a project
...
The

ning and is reviewed by all interested parties
...
The software team selects a process for the work to be performed
...
g
...

Reviews software engineering activities to verify compliance with the deﬁned
software process
...

202

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

Audits designated software work products to verify compliance with those
deﬁned as part of the software process
...

Ensures that deviations in software work and work products are documented
and handled according to a documented procedure
...

Records any noncompliance and reports to senior management
...

In addition to these activities, the SQA group coordinates the control and management of change (Chapter 9) and helps to collect and analyze software metrics
...
4

S O F T WA R E R E V I E W S
Software reviews are a "ﬁlter" for the software engineering process
...

Too few and the ﬂow
is “dirty
...
Use metrics
to determine which
reviews work and
which may not be
effective
...

and defects that can then be removed
...
Freedman and
Weinberg [FRE90] discuss the need for reviews this way:
Technical work needs reviewing for the same reason that pencils need erasers: To err is
human
...
The review process is, therefore, the answer to the prayer
of Robert Burns:
O wad some power the giftie give us
to see ourselves as other see us
A review—any review—is a way of using the diversity of a group of people to:
1
...
Confirm those parts of a product in which improvement is either not desired or not
needed;
3
...

Many different types of reviews can be conducted as part of software engineering
...
An informal meeting around the coffee machine is a form of
review, if technical problems are discussed
...
In this book, however, we focus on the formal technical review, sometimes
called a walkthrough or an inspection
...
Conducted by software engineers (and
others) for software engineers, the FTR is an effective means for improving software
quality
...
4
...
” The deﬁnition for fault in the hardware
context can be found in IEEE Standard 610
...
(b) An incorrect step, process, or data deﬁnition in a computer program
...
In common usage, the terms
"error" and "bug" are used to express this meaning
...

Within the context of the software process, the terms defect and fault are synonymous
...
In earlier chapters, we used the term error to depict a quality problem that is discovered by software
engineers (or others) before the software is released to the end-user (or to another
activity in the software process)
...
The obvious beneﬁt 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 (by TRW, Nippon Electric, Mitre Corp
...
However, formal review techniques have been shown to be up to 75 percent effective [JON86] in uncovering design
ﬂaws
...

To illustrate the cost impact of early error detection, we consider a series of relative costs that are based on actual cost data collected for large software projects
[IBM81]
...
0 monetary unit
to correct
...
5 units; during testing, 15 units; and after release, between 60 and
100 units
...

204

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

F I G U R E 8
...
4
...
The model is illustrated schematically in Fig-

“Some maladies, as
doctors say, at their
beginning are easy
to cure but difﬁcult
to recognize
...
”

ure 8
...
A box represents a software development step
...
Ten preliminary design

be inadvertently generated
...

In some cases, errors passed through from previous steps are ampliﬁed (ampliﬁcation factor, x) by current work
...

Figure 8
...
Referring to the ﬁgure, each
test step is assumed to uncover and correct 50 percent of all incoming errors withdefects are ampliﬁed to 94 errors before testing commences
...
Figure 8
...
In this case, ten initial preliminary design errors are ampliﬁed to 24 errors before testing commences
...
Recalling the relative costs associated with the discovery and correction of errors, overall cost (with and without review for our hypothetical example) can be established
...
3 and 8
...
5 cost units for design, 6
...
Using these data, the total cost for development and maintenance when reviews are conducted is 783 cost units
...

To conduct reviews, a software engineer must expend time and effort and the
development organization must spend money
...
Formal tech-

CHAPTER 8

F I G U R E 8
...
5
x = 1
...
4
Defect
ampliﬁcation,
reviews
conducted

Preliminary design

0
0

Detail design

70%

3 2
1

10

2
1 •1
...
They should be conducted
...
5

FORMAL TECHNICAL REVIEWS
A formal technical review is a software quality assurance activity performed by software engineers (and others)
...
In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation
...

The FTR is actually a class of reviews that includes walkthroughs, inspections,
round-robin reviews and other small group technical assessments of software
...
In the sections that follow, guidelines similar to those for a
walkthrough [FRE90], [GIL93] are presented as a representative formal technical review
...
5
...
”

the following constraints:
•

Between three and ﬁve people (typically) should be involved in the review
...

author unknown

•

The duration of the review meeting should be less than two hours
...
For example, rather than attempting to review an
entire design, walkthroughs are conducted for each component or small group of
components
...

The focus of the FTR is on a work product (e
...
, a portion of a requirements speciﬁcation, a detailed component design, a source code listing for a component)
...

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
...
Each reviewer is expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar with the work
...

The review meeting is attended by the review leader, all reviewers, and the pro-

WebRef
The NASA SATC Formal
Inspection Guidebook can
be downloaded from
satc
...
nasa
...
html

ducer
...
The FTR begins
with an introduction of the agenda and a brief introduction by the producer
...
When valid problems or errors are discovered, the recorder notes each
...
The decision made, all FTR attendees complete a
sign-off, indicating their participation in the review and their concurrence with the
review team's ﬁndings
...
5
...
These are summarized at the end of the review meeting and a review issues
list is produced
...

A review summary report answers three questions:
1
...
Who reviewed it?
3
...
It
becomes part of the project historical record and may be distributed to the project
leader and other interested parties
...
An issues list is normally attached to the summary report
...
Unless this is done, it is possible that issues raised
can “fall between the cracks
...

8
...
3 Review Guidelines
Guidelines for the conduct of formal technical reviews must be established in advance,
distributed to all reviewers, agreed upon, and then followed
...
The following represents a minimum
set of guidelines for formal technical reviews:
1
...
An FTR involves people and egos
...
One way to be
gentle is to ask a
question that enables
the producer to
discover his or her own
error
...
Conducted improperly, the FTR can take on the aura of an
inquisition
...
The review leader should conduct the review meeting to ensure that
the proper tone and attitude are maintained and should immediately halt a
review that has gotten out of control
...
Set an agenda and maintain it
...
An FTR must be kept on track and on schedule
...

3
...
When an issue is raised by a reviewer, there may
not be universal agreement on its impact
...

4
...
A
review is not a problem-solving session
...
"
Ralph Waldo
Emerson

be accomplished by the producer alone or with the help of only one other
individual
...

5
...
It is sometimes a good idea for the recorder to make notes
on a wall board, so that wording and priorities can be assessed by other
reviewers as information is recorded
...
Limit the number of participants and insist upon advance preparation
...
Keep the
number of people involved to the necessary minimum
...
Written comments should be
solicited by the review leader (providing an indication that the reviewer has
reviewed the material)
...
Develop a checklist for each product that is likely to be reviewed
...
Checklists should be developed for analysis,
design, code, and even test documents
...
Allocate resources and schedule time for FTRs
...
In
addition, time should be scheduled for the inevitable modiﬁcations that will
occur as the result of an FTR
...
Conduct meaningful training for all reviewers
...
The training should stress both
process-related issues and the human psychological side of reviews
...

10
...
Debrieﬁng can be beneﬁcial in uncovering problems with the review process itself
...

Because many variables (e
...
, number of participants, type of work products, timing and length, speciﬁc review approach) have an impact on a successful review, a

CHAPTER 8

S O F T WA R E Q U A L I T Y A S S U R A N C E

209

software organization should experiment to determine what approach works best in
a local context
...

8
...
In addition, quality can
be deﬁned in terms of a broad array of quality factors and measured (indirectly) using
a variety of indices and metrics
...
Correctness proofs
are considered in
Chapter 26
...
It can be argued that a computer program is a mathematical object
[SOM96]
...
If the requirements model (speciﬁcation) and the
programming language can be represented in a rigorous manner, it should be possible to apply mathematic proof of correctness to demonstrate that a program conforms exactly to its speciﬁcations
...
Dijkstra [DIJ76] and Linger, Mills,
and Witt [LIN79], among others, advocated proofs of program correctness and tied
these to the use of structured programming concepts (Chapter 16)
...
7

S TAT I S T I C A L S O F T WA R E Q U A L I T Y A S S U R A N C E
Statistical quality assurance reﬂects a growing trend throughout industry to become
more quantitative about quality
...
Information about software defects is collected and categorized
...
An attempt is made to trace each defect to its underlying cause (e
...
, nonconformance to speciﬁcations, design error, violation of standards, poor
communication with the customer)
...
Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all possible causes), isolate the 20 percent (the "vital few")
...
Once the vital few causes have been identiﬁed, move to correct the problems
that have caused the defects
...
Find
them, ﬁx them!”
Lowell Arthur

those elements of the process that introduce error
...
Some of the defects are uncovered as software is being developed
...
Although hundreds of different errors are uncovered, all can be
tracked to one (or more) of the following causes:
•
•

intentional deviation from speciﬁcations (IDS)

•

violation of programming standards (VPS)

•

error in data representation (EDR)

•

inconsistent component interface (ICI)

•

error in design logic (EDL)

•

incomplete or erroneous testing (IET)

•

inaccurate or incomplete documentation (IID)

•

error in programming language translation of design (PLT)

•

ambiguous or inconsistent human/computer interface (HCI)

•

The Chinese Association
for Software Quality
presents one of the most
comprehensive quality
Web sites at
www
...
org

misinterpretation of customer communication (MCC)

•

WebRef

incomplete or erroneous speciﬁcations (IES)

miscellaneous (MIS)

To apply statistical SQA, Table 8
...
The table indicates that IES, MCC, and EDR
are the vital few causes that account for 53 percent of all errors
...
Once the vital few causes are determined, the
software engineering organization can begin corrective action
...
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 candidates pop to the top of the stack
...
In some cases, software organizations have
achieved a 50 percent reduction per year in defects after applying these techniques
...
After
analysis, design, coding, testing, and release, the following data are gathered:
Ei

=

the total number of errors uncovered during the ith step in the software engineering process

CHAPTER 8

TA B L E 8
...

%

No
...

%

No
...
The weighting factors for each phase
should become larger as development progresses
...

At each step in the software process, a phase index, PIi, is computed:
PIi = ws (Si/Ei) + wm (Mi/Ei) + wt (Ti/Ei)
The error index is computed by calculating the cumulative effect on each PIi, weighting errors encountered later in the software engineering process more heavily than
those encountered earlier:
EI = ⌺(i x PIi)/PS
= (PI1 + 2PI2 + 3PI3 +
...
1 to
develop an overall indication of improvement in software quality
...

Interested readers should see [SCH98], [KAP95], or [KAN95]
...
8

S O F T WA R E R E L I A B I L I T Y
There is no doubt that the reliability of a computer program is an important element
of its overall quality
...

WebRef
The Reliability Analysis
Center provides much
useful information on
reliability, maintainability,
supportability, and quality
at rac
...
org

Software reliability, unlike many other quality factors, can be measured directed and
estimated using historical and developmental data
...
To illustrate, program X is estimated
to have a reliability of 0
...
In other words, if program X were to be executed 100 times and require eight hours of elapsed processing
time (execution time), it is likely to operate correctly (without failure) 96 times out of 100
...
Yet, even within this deﬁnition, there are gradations
...
One failure
can be corrected within seconds while another requires weeks or even months to
correct
...

8
...
1 Measures of Reliability and Availability
Early work in software reliability attempted to extrapolate the mathematics of hardware reliability theory (e
...
, [ALV64]) to the prediction of software reliability
...

failure due to design defects
...
g
...
Unfortunately, the opposite is true for software
...

There has been debate over the relationship between key concepts in hardware
reliability and their applicability to software (e
...
, [LIT89], [ROO90])
...

If we consider a computer-based system, a simple measure of reliability is meantime-between-failure (MTBF), where
MTBF = MTTF + MTTR
The acronyms MTTF and MTTR are mean-time-to-failure and mean-time-to-repair,
respectively
...
Stated simply, an end-user is concerned with failures, not with the total
error count
...
For example, consider a program that has been in operation for 14 months
...
The MTBF of such obscure errors might be 50 or even 100 years
...
Even if every one
of the ﬁrst category of errors (those with long MTBF) is removed, the impact on software reliability is negligible
...

Software availability is the probability that a program is operating according to requirements at a given point in time and is deﬁned as
Availability = [MTTF/(MTTF + MTTR)] ϫ 100%
The MTBF reliability measure is equally sensitive to MTTF and MTTR
...

8
...
2 Software Safety
Leveson [LEV86] discusses the impact of software in safety critical systems when she
writes:
Before software was used in safety critical systems, they were often controlled by conventional (nonprogrammable) mechanical and electronic devices
...
Human
design errors are not considered since it is assumed that all faults caused by human errors
can be avoided completely or removed prior to delivery and operation
...
Subtle design faults induced by human error—some-

“I cannot imagine
any condition which
would cause this
ship to founder
...
”
E
...
Smith, captain
of the Titanic

thing that can be uncovered and eliminated in hardware-based conventional control—become much more difﬁcult to uncover when software is used
...
If hazards can be identiﬁed early in the software engineering process, software design features can be speciﬁed that will either eliminate
or control potential hazards
...
Initially,
hazards are identiﬁed and categorized by criticality and risk
...
4 To be effective, software must be analyzed

WebRef
Worthwhile papers on
software safety (and a
detailed glossary) can be
found at
www
...
com/
hotlist/topicssafety
...
For example, a subtle user input error (people are
system components) may be magniﬁed by a software fault to produce control data
that improperly positions a mechanical device
...
Analysis techniques such as fault tree analysis
[VES81], real-time logic [JAN86], or petri net models [LEV87] can be used to predict
the chain of events that can cause hazards and the probability that each of the events
will occur to create the chain
...
That is, the speciﬁcation can contain a list of undesirable events
and the desired system responses to these events
...

Although software reliability and software safety are closely related to one another,

?

What is the
difference
between software
reliability and
software safety?

it is important to understand the subtle difference between them
...
However, the occurrence of a failure does not necessarily result in a hazard
or mishap
...
That is, failures are not considered in a vacuum, but are
evaluated in the context of an entire computer-based system
...

Those readers with further interest should refer to Leveson’s [LEV95] book on the
subject
...
9

M I S TA K E - P R O O F I N G F O R S O F T WA R E
If William Shakespeare had commented on the modern software engineer’s condition, he might have written: “To err is human, to ﬁnd the error quickly and correct it
is divine
...
Called poka-yoke
(mistake-prooﬁng), Shingo’s concept makes use of poka-yoke devices—mechanisms
that lead to (1) the prevention of a potential quality problem before it occurs or (2)
the rapid detection of quality problems if they are introduced
...
For exam4

This approach is analogous to the risk analysis approach described for software project management in Chapter 6
...

CHAPTER 8

S O F T WA R E Q U A L I T Y A S S U R A N C E

215

ple, the ignition switch for an automobile will not work if an automatic transmission
is in gear (a prevention device); an auto’s warning beep will sound if the seat belts are
not buckled (a detection device)
...
If a device is too complicated or expensive, it will
not be cost effective
...
campbell
...

edu/faculty/jgrout/
pokayoke
...
That is, the poka-yoke device is integrated into an
engineering activity
...
Thus, it
provides rapid feedback and error correction
...
To illustrate, we consider the following problem [ROB97]:
A software products company sells application software to an international market
...
For example, the English language menu item for “Close” has the
mnemonic “C” associated with it
...
” To implement the appropriate
menu entry for each locale, a “localizer” (a person conversant in the local language and
terminology) translates the menus accordingly
...

The use of poka-yoke for testing various application menus implemented in different
languages as just described is discussed in a paper by Harry Robinson [ROB97]:5
We ﬁrst decided to break the menu testing problem down into parts that we could solve
...
There was the content aspect: the simple text translations, such
as changing "Close" to "Fermer
...

The second aspect of the message catalogs was the structure, the syntax rules that a
properly constructed target catalog must obey
...

As an example of what is meant by structure, consider the labels and mnemonics of an
application menu
...
Each menu, regardless of its contents or its locale, must obey the following rules listed in the Motif Style Guide:
•

Each mnemonic must be contained in its associated label

•

Each mnemonic must be unique within the menu

5

The paragraphs that follow have been excerpted (with minor editing) from [ROB97] with the permission of the author
...

There were several possibilities for how to mistake-proof the menu mnemonics:
Prevention device
...
This approach would prevent mistakes, but the problem
of choosing a good mnemonic is difﬁcult and the effort required to write the program would
not be justiﬁed by the beneﬁt gained
...
We could write a program that would prevent the localizer from choosing mnemonics that did not meet the criteria
...

Detection device
...
Our localizers could run the programs on their translated message catalogs before sending the catalogs to us
...

Detection device
...

This approach is the path we are currently taking
...

Several small poka-yoke scripts were used as poka-yoke devices to validate the structural
aspects of the menus
...

The poka-yoke scripts were small (roughly 100 lines), easy to write (some were written
in under an hour) and easy to run
...
Each locale contained 100 menus, for a
total of 1200 menus
...
Few of the problems we uncovered were earth-shattering, but in total they would have
amounted to a large annoyance in testing and running our localized applications
...
The poka-yoke technique can be applied at the design,
code, and testing levels and provides an effective quality assurance ﬁlter
...
10

T H E I S O 9 0 0 0 Q U A L I T Y S TA N D A R D S 6
A quality assurance system may be deﬁned as the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management
6

This section, written by Michael Stovsky, has been adapted from “Fundamentals of ISO 9000” and
“ISO 9001 Standard,” workbooks developed for Essential Software Engineering, a video curriculum
developed by R
...
Pressman & Associates, Inc
...

CHAPTER 8

S O F T WA R E Q U A L I T Y A S S U R A N C E

217

[ANS87]
...

These systems cover a wide variety of activities encompassing a product’s entire life
cycle including planning, controlling, measuring, testing and reporting, and improving quality levels throughout the development and manufacturing process
...

The ISO 9000 standards have been adopted by many countries including all mem-

WebRef

bers of the European Community, Canada, Mexico, the United States, Australia, New

Extensive links to ISO
9000/9001 resources
can be found at
www
...
ab
...
htm

Zealand, and the Paciﬁc Rim
...

After adopting the standards, a country typically permits only ISO registered companies to supply goods and services to government agencies and public utilities
...
In turn, manufacturers of
these products often require their suppliers to become registered
...

To become registered to one of the quality assurance system models contained in
ISO 9000, a company’s quality system and operations are scrutinized by third party
auditors for compliance to the standard and for effective operation
...
Semi-annual surveillance audits ensure continued compliance to the
standard
...
10
...
For a quality system to be ISO compliant, these processes must
address the areas identiﬁed in the standard and must be documented and practiced
as described
...

ISO 9000 describes
what must be done to
be compliant, but it
does not describe how
it must be done
...
However, ISO 9000 does not describe how an organization should implement these quality system elements
...

8
...
2 The ISO 9001 Standard
ISO 9001 is the quality assurance standard that applies to software engineering
...
Because the ISO 9001 standard is applicable to all engineering

218

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

disciplines, a special set of ISO guidelines (ISO 9000-3) have been developed to help
interpret the standard for use in the software process
...
In order for a software organization to
become registered to ISO 9001, it must establish policies and procedures to address
each of the requirements just noted (and others) and then be able to demonstrate
that these policies and procedures are being followed
...

8
...
Developed by the SQA group, the plan serves as a template for SQA activities that are instituted for each software project
...
Initial sections describe the purpose and scope of the document and indicate those software
process activities that are covered by quality assurance
...
The management section

The SQA plan

of the plan describes SQA’s place in the organizational structure, SQA tasks and activities and their placement throughout the software process, and the organizational
roles and responsibilities relative to product quality
...
These include
•

project documents (e
...
, project plan)

•

models (e
...
, ERDs, class hierarchies)

•

technical documents (e
...
, speciﬁcations, test plans)

•

user documents (e
...
, help ﬁles)

In addition, this section deﬁnes the minimum set of work products that are acceptable to achieve high quality
...
g
...
In addition, all project, process, and (in
some instances) product metrics that are to be collected as part of software engineering work are listed
...
It
provides an overview of the approach for each review and audit
...
It
also deﬁnes test record-keeping requirements
...

The remainder of the SQA Plan identiﬁes the tools and methods that support SQA
activities and tasks; references software conﬁguration management procedures for
controlling change; deﬁnes a contract management approach; establishes methods
for assembling, safeguarding, and maintaining all records; identiﬁes training required
to meet the needs of the plan; and deﬁnes methods for identifying, assessing, monitoring, and controlling risk
...
12

SUMMARY
Software quality assurance is an umbrella activity that is applied at each step in the
software process
...

SQA is complicated by the complex nature of software quality—an attribute of
computer programs that is deﬁned as "conformance to explicitly and implicitly speciﬁed requirements
...

Software reviews are one of the most important SQA activities
...
The formal technical review is a stylized
meeting that has been shown to be extremely effective in uncovering errors
...
Statistical SQA
helps to improve the quality of the product and the software process itself
...

In summary, we recall the words of Dunn and Ullman [DUN82]: "Software quality
assurance is the mapping of the managerial precepts and design disciplines of quality assurance onto the applicable managerial and technological space of software
engineering
...
When the mapping is successfully accomplished, mature software engineering is the result
...
H
...
), Reliability Engineering, Prentice-Hall, 1964
...

[ART92] Arthur, L
...
, Improving Software Quality: An Insider's Guide to TQM, Wiley,
1992
...
J
...
40, no
...
47–52
...
, Software Engineering Economics, Prentice-Hall, 1981
...
, Quality Is Free, McGraw-Hill, 1979
...
E
...

[DEM99] DeMarco, T
...

[DIJ76]

Dijkstra, E
...

[DUN82] Dunn, R
...
Ullman, Quality Assurance for Computer Software, McGrawHill, 1982
...
P
...
M
...
, Dorset House, 1990
...
and D
...

[GLA98] Glass, R
...
103–
104, 107
...
, ISO 9000 Quality Systems Development Handbook: A Systems Engineering Approach, Butterworth-Heinemann, 1998
...

IEE94]

Software Engineering Standards, 1994 ed
...

[JAN86] Jahanian, F
...
K
...
Software Engineering, vol
...
9, September 1986,
pp
...

[JON86] Jones, T
...
, Programming Productivity, McGraw-Hill, 1986
...
H
...

[KAP95] Kaplan, C
...
Clark, and V
...

[LEV86] Leveson, N
...
, "Software Safety: Why, What, and How," ACM Computing Surveys, vol
...
2, June 1986, pp
...

[LEV87] Leveson, N
...
and J
...
Stolzy, "Safety Analysis Using Petri Nets, IEEE Trans
...
SE-13, no
...
386–397
...
G
...

[LIN79]
1979
...
, H
...
Witt, Structured Programming, Addison-Wesley,

CHAPTER 8

[LIT89]

S O F T WA R E Q U A L I T Y A S S U R A N C E

221

Littlewood, B
...
Bittanti, ed
...
141–209
...
D
...
Iannino, and K
...

[POR95] Porter, A
...
Siy, C
...
Toman, and L
...
Votta, "An Experiment to
Assess the Cost-Beneﬁts of Code Inspections in Large Scale Software
Development," Proc
...
C
...
92–103
...
, “Using Poka-Yoke Techniques for Early Error Detection,” Proc
...
119–142
...
, Software Reliability Handbook, Elsevier, 1990
...
C
...
I
...
), Handbook of Software Quality
Assurance, 3rd ed
...

[SCH94] Schmauch, C
...
, ISO 9000 for Software Developers, ASQC Quality Press, 1994
...
J
...

[SHI86]

Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-yoke

System, Productivity Press, 1986
...
, Software Engineering, 5th ed
...

[VES81] Veseley, W
...
, et al
...
S
...

PROBLEMS AND POINTS TO PONDER
8
...
Early in this chapter we noted that “variation control is the heart of quality control
...
2
...
3
...
Discuss them
...
4
...

8
...
Can a program be correct and still not exhibit good quality? Explain
...
6
...
7
...
What is the ﬁrst thing that you should do? What's next?
8
...
Besides counting errors, are there other countable characteristics of software
that imply quality? What are they and can they be measured directly?

222

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

8
...
A formal technical review is effective only if everyone has prepared in advance
...
10
...
Is this a good idea? Why?
8
...
Review Table 8
...
Suggest corrective actions using information presented in other chapters
...
12
...
1 information and this percentage distribution, compute the overall
defect index for the organization
...

8
...
Research the literature on software reliability and write a paper that describes
one software reliability model
...

8
...
The MTBF concept for software is open to criticism
...
15
...
List at
least three hazards for each that can be directly linked to software failures
...
16
...

8
...
Suggest a few poka-yoke devices that might be used to detect and/or prevent
errors that are commonly encountered prior to “sending” an e-mail message
...
18
...
Prepare a presentation that discusses three ISO 9001 requirements and how they apply in a software context
...
Books by Deming [DEM86]
and Crosby [CRO79] do not focus on software, but both books are must reading for

CHAPTER 8

S O F T WA R E Q U A L I T Y A S S U R A N C E

223

senior managers with software development responsibility
...
Kan (Metrics and Models in Software Quality Engineering, Addison-Wesley, 1995) presents a quantitative
view of software quality
...
Oskarsson (An ISO 9000 Approach to
Building Quality Software, Prentice-Hall, 1995) discusses the ISO standard as it applies
to software
...

The following is a small sampling of useful sources:
Clapp, J
...
, et al
...
, 1995
...
H
...
S
...

Fenton, N
...
Whitty, and Y
...

Ferdinand, A
...
, Systems, Software, and Quality Engineering, Van Nostrand-Reinhold, 1993
...
P
...

Ince, D
...

Ince, D
...

Jarvis, A
...
Crandall, Inroads to Software Quality: “How to” Guide and Toolkit, PrenticeHall, 1997
...
, Software Quality: A Framework for Success in Software Development, Addison-Wesley, 1994
...
H
...

Wallmuller, E
...

Weinberg, G
...
, Quality Software Management, four volumes, Dorset House, 1992, 1993, 1994,
1996
...
C
...

An anthology edited by Wheeler, Brykczynski, and Meeson (Software Inspection:
Industry Best Practice, IEEE Computer Society Press, 1996) presents useful information on this important SQA activity
...

Musa (Software Reliability Engineering: More Reliable Software, Faster Development
and Testing, McGraw-Hill, 1998) has written a practical guide to applied software reliability techniques
...
(Contributions to Hardware and Software Reliability Modelling,
World Scientific Publishing Co
...
Storey (Safety-Critical Computer Systems, Addison-Wesley, 1996) and Leveson [LEV95] continue to be the most
comprehensive discussions of software safety published to date
...

A wide variety of information sources on software quality assurance, software reliability, and related subjects is available on the Internet
...
mhhe
...
mhtml

CHAPTER

9
KEY
CONCEPTS
access control
...
227
change control
...
237
conﬁguration's
objects
...
230
SCIs
...
230
status reporting
...
234
version control
...
And change
increases the level of confusion among software engineers who are
working on a project
...
Babich [BAB86] discusses this when he states:

C

The art of coordinating software development to minimize
...
Conﬁguration management is the art of identifying, organizing, and controlling modiﬁcations to the software being built by a programming
team
...

Software configuration management (SCM) is an umbrella activity that is
applied throughout the software process
...

It is important to make a clear distinction between software support and
software conﬁguration management
...

controls you
...
It’s very easy

And because it happens, you

for a stream of uncontrolled changes to turn a

need to control it effectively
...
For that rea-

tion management (SCM) is a set of activities

son, SCM is an essential part of good project man-

designed to control change by identifying the

agement and solid software engineering

QUICK
LOOK

work products that are likely to change, estab-

practice
...
Once this is accomplished,

and auditing and reporting on the changes

mechanisms for version and change control can

made
...
To ensure that quality is main-

Who does it? Everyone involved in the software engi-

tained as changes are made, the process is

neering process is involved with SCM to some

audited; and to ensure that those with a need to

extent, but specialized support positions are some-

know are informed about changes, reporting is

times created to manage the SCM process
...

225

226

PA R T T W O

QUICK
LOOK

M A N A G I N G S O F T WA R E P R O J E C T S

What is the work product? The

How do I ensure that I’ve done it right? When

Software Conﬁguration Manage-

every work product can be accounted for, traced,

ment Plan defines the project

and controlled; when every change can be

strategy for SCM
...

neering change orders
...
Software conﬁguration management is a set of tracking and control
activities that begin when a software engineering project begins and terminate only
when the software is taken out of operation
...
In this chapter, we discuss the speciﬁc activities that enable us to manage change
...
1

“There is nothing
permanent except
change
...
C
...
The items
that comprise all information produced as part of the software process are collectively called a software conﬁguration
...
A System Speciﬁcation spawns a Software Project Plan and Software Requirements Speciﬁcation (as well as hardware related documents)
...
If each SCI simply
spawned other SCIs, little confusion would result
...
Change may occur at any time, for any reason
...
”
What is the origin of these changes? The answer to this question is as varied as
the changes themselves
...

•

New customer needs demand modification of data produced by information
systems, functionality delivered by products, or services delivered by a
computer-based system
...

•

227

Budgetary or scheduling constraints cause a redeﬁnition of the system or
product
...
SCM can be
viewed as a software quality assurance activity that is applied throughout the software process
...

9
...
1 Baselines

Most software changes
are justiﬁed
...

Rather, be certain that
you have mechanisms
in place to handle
them
...
Customers want to modify requirements
...
Managers want to modify the project strategy
...

As time passes, all constituencies know more (about what they need, which approach
would be best, how to get it done and still make money)
...
The IEEE (IEEE Std
...

610
...

One way to describe a baseline is through analogy:
Consider the doors to the kitchen in a large restaurant
...
The doors have stops that allow them to be opened only in the appropriate direction
...

If, however, he leaves the kitchen, gives the customer the dish and then is informed of
his error, he must follow a set procedure: (1) look at the check to determine if an error has

A software
engineering work
product becomes a
baseline only after it
has been reviewed and
approved
...

A baseline is analogous to the kitchen doors in the restaurant
...

However, once a baseline is established, we ﬁguratively pass through a swinging oneway door
...

228

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

Modified
SCIs
Project database
Software
engineering
tasks

SCIs

Approved

Formal
technical
reviews

SCIs
Stored
SCIs

Extracted
SCM
controls

SCIs

F I G U R E 9
...

BASELINES:
System Specification
Software Requirements
Design Specification
Source Code
Test Plans/Procedures/Data
Operational System

In the context of software engineering, a baseline is a milestone in the development of software that is marked by the delivery of one or more software conﬁguration items and the approval of these SCIs that is obtained through a formal technical
review (Chapter 8)
...
Errors are found and corrected
...
Further changes to the program architecture (documented in
the Design Speciﬁcation) can be made only after each has been evaluated and approved
...
1
...
1
...
After SCIs are reviewed and
approved, they are placed in a project database (also called a project library or software repository)
...
However, this extracted SCI can be modiﬁed only if SCM
controls (discussed later in this chapter) are followed
...
1 illustrate the modiﬁcation path for a baselined SCI
...
1
...
In the extreme, a SCI could be considered to be a single section of a large speciﬁcation or one test case in a large suite of

CHAPTER 9

229

S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T

F I G U R E 9
...
More realistically, an SCI is a document, a entire suite of test cases, or a named
program component (e
...
, a C++ function or an Ada package)
...
That is, speciﬁc versions of editors, compilers, and other CASE tools are "frozen"
as part of the software conﬁguration
...
Although problems are rare, it is possible that a
new version of a tool (e
...
, a compiler) might produce different results than the original version
...

In reality, SCIs are organized to form conﬁguration objects that may be cataloged
in the project database with a single name
...
Referring to Figure 9
...
However, each of the
objects is related to the others as shown by the arrows
...
That is, data model and component N are part of the object
Design Speciﬁcation
...

230

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

If a change were made to the source code object, the interrelationships enable a software engineer to determine what other objects (and SCIs) might be affected
...
2

THE SCM PROCESS
Software configuration management is an important element of software quality
assurance
...
However, SCM is also
responsible for the identiﬁcation of individual SCIs and various versions of the software, the auditing of the software conﬁguration to ensure that it has been properly
developed, and the reporting of all changes applied to the conﬁguration
...
cs
...

edu/users/andre/
conﬁguration_
management
...

9
...
Two types of objects can be
identiﬁed [CHO89]: basic objects and aggregate objects
...
For example, a basic object might be a section of a requirements speciﬁcation,
a source listing for a component, or a suite of test cases that are used to exercise the
code
...

Referring to Figure 9
...
Conceptually,
it can be viewed as a named (identiﬁed) list of pointers that specify basic objects such
as data model and component N
...
" The object name is a character string that
identiﬁes the object unambiguously
...
The structure of the project database will be
discussed in greater detail in Chapter 31
...

CHAPTER 9

S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T

•

a project identiﬁer

•

The interrelationships
established for
conﬁguration objects
allow a software
engineer to assess the
impact of change
...
g
...
" For example, data types, speciﬁc functions, or even variable
names may be considered to be object resources
...

Conﬁguration object identiﬁcation must also consider the relationships that exist
between named objects
...

The relationship deﬁnes a hierarchy of objects
...
4 data model;
data model design speciﬁcation;
XRef
Data models and data
ﬂow diagrams are
discussed in Chapter
12
...

It is unrealistic to assume that the only relationships among objects in an object hierarchy are along direct paths of the hierarchical tree
...
For example, a data model is interrelated
to data ﬂow diagrams (assuming the use of structured analysis) and also interrelated
to a set of test cases for a speciﬁc equivalence class
...

The interrelationships between conﬁguration objects can be represented with a
module interconnection language (MIL) [NAR87]
...

The identiﬁcation scheme for software objects must recognize that objects evolve
throughout the software process
...

It is possible to create an evolution graph [GUS89] for any object
...
3
...
0 undergoes revision and becomes object 1
...
Minor corrections and changes
result in versions 1
...
1 and 1
...
2, which is followed by a major update that is object
1
...
The evolution of object 1
...
3 and 1
...
0
...

Changes may be made to any version, but not necessarily to all versions
...
4? How does the marketing department know what customers currently have

232

PA R T T W O

M A N A G I N G S O F T WA R E P R O J E C T S

F I G U R E 9
...
3

obj
2
...
0

obj
1
...
4

obj
2
...
2

obj
1
...
1

CASE Tools—SCM

obj
1
...
1
...
1? How can we be sure that changes to the version 2
...

A variety of automated SCM tools has been developed to aid in identiﬁcation (and
other SCM) tasks
...
To achieve earlier versions (of documents or programs) changes
(cataloged by the tool) are "subtracted" from the most recent version [TIC82]
...

VERSION CONTROL
Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process
...
This is supported by associating attributes with each software version, and then allowing a conﬁguration to be speciﬁed
[and constructed] by describing the set of desired attributes
...

These "attributes" mentioned can be as simple as a speciﬁc version number that is
attached to each object or as complex as a string of Boolean variables (switches) that
indicate specific types of functional changes that have been applied to the system
[LIE89]
...
3
...
Each version of the software is a collection of SCIs
(source code, documents, data), and each version may be composed of different variants
...
4
Object pool
representation
of components,
variants, and
versions [REI89]

233

S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T

Variants

Entities

Versions
Objects

“Any change, even a
change for the
better, is always
accompanied by
drawbacks and
discomforts
...
3 Entity 4 is used only when the software is implemented using color displays
...
Therefore, two variants of the version can be deﬁned: (1) entities 1, 2,
3, and 4; (2) entities 1, 2, 3, and 5
...
One or more attributes is assigned for each variant
...

Another way to conceptualize the relationship between entities, variants and versions (revisions) is to represent them as an object pool [REI89]
...
4, the relationship between configuration objects and entities, variants and versions can be represented in a three-dimensional space
...
A variant is a different collection of
objects at the same revision level and therefore coexists in parallel with other variants
...

A number of different automated approaches to version control have been proposed over the past decade
...

3

In this context, the term entity refers to all composite objects and basic objects that exist for a
baselined SCI
...

234

PA R T T W O

9
...
But the forces that make it necessary also make it annoying
...
But it can also fix a big failure or enable wonderful new capabilities
...

“The art of progress is
to preserve order
amid change and to
preserve change
amid order
...
Access
and synchronization
control avoid
confusion
...

Bach recognizes that we face a balancing act
...
Too little, and we create other problems
...
For such projects, change control combines human procedures and automated
tools to provide a mechanism for the control of change
...
5
...
The results
of the evaluation are presented as a change report, which is used by a change control
authority (CCA)—a person or group who makes a ﬁnal decision on the status and priority of the change
...
The ECO describes the change to be made, the constraints that must be
respected, and the criteria for review and audit
...
The object is then "checked in" to the database and appropriate version control mechanisms (Section 9
...

The "check-in" and "check-out" process implements two important elements of
change control—access control and synchronization control
...
Synchronization control helps to ensure that parallel changes, performed by two different people, don't overwrite one another [HAR89]
...
6
...
An access control function ensures that the software engineer
has authority to check out the object, and synchronization control locks the object in
the project database so that no updates can be made to it until the currently checkedout version has been replaced
...
A copy of the baselined object, called the extracted version,

4

Although many change requests are submitted during the software support phase, we take a
broader view in this discussion
...

CHAPTER 9

235

S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T

F I G U R E 9
...
After appropriate SQA and testing, the modiﬁed version of the object is checked in and the new baseline object is unlocked
...
This feeling is not uncommon
...
Most software developers who have change control mechanisms (unfortunately,

236
F I G U R E 9
...

It’s likely that “too
much” will be the right
amount
...
”
Bumper sticker

many have none) have created a number of layers of control to help avoid the problems alluded to here
...

The developer of the configuration object (SCI) in question may make whatever
changes are justiﬁed by project and technical requirements (as long as changes do
not affect broader system requirements that lie outside the developer's scope of work)
...
Once an SCI becomes a baseline, project level change control is
implemented
...
In some cases, formal generation of change requests, change reports, and ECOs
is dispensed with
...

When the software product is released to customers, formal change control is instituted
...
5
...
Depending on the size and character of a software project, the CCA may be
composed of one person—the project manager—or a number of people (e
...
, representatives from software, hardware, database engineering, support, marketing)
...
How will the change affect hardware? How will the change affect
performance? How will the change modify 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
...
6

? What are the
primary
questions that we
ask during a
conﬁguration
audit?

S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T

237

C O N F I G U R AT I O N A U D I T
Identification, version control, and change control help the software developer to
maintain order in what would otherwise be a chaotic and ﬂuid situation
...
How can we ensure that the change has been properly implemented? The
answer is twofold: (1) formal technical reviews and (2) the software conﬁguration
audit
...
The reviewers
assess the SCI to determine consistency with other SCIs, omissions, or potential side
effects
...

A software conﬁguration audit complements the formal technical review by assessing a conﬁguration object for characteristics that are generally not considered during review
...
Has the change speciﬁed in the ECO been made? Have any additional modiﬁcations been incorporated?
2
...
Has the software process been followed and have software engineering standards been properly applied?
4
...
Have SCM procedures for noting the change, recording it, and reporting it
been followed?
6
...

However, when SCM is a formal activity, the SCM audit is conducted separately by
the quality assurance group
...
7

S TAT U S R E P O R T I N G
Conﬁguration status reporting (sometimes called status accounting) is an SCM task that
answers the following questions: (1) What happened? (2) Who did it? (3) When did it
happen? (4) What else will be affected?
The flow of information for configuration status reporting (CSR) is illustrated in
Figure 9
...
Each time an SCI is assigned new or updated identiﬁcation, a CSR entry
is made
...
e
...
Each time a conﬁguration audit is conducted, the results are reported

238

PA R T T W O

Develop a “need to
know list” for every
SCI and keep it up-todate
...

9
...
Output from CSR may be placed in an on-line database [TAY85],
so that software developers or maintainers can access change information by keyword category
...

Conﬁguration status reporting plays a vital role in the success of a large software
development project
...
Two developers may
attempt to modify the same SCI with different and conﬂicting intents
...
The person who would recognize serious side effects for a proposed
change is not aware that the change is being made
...

S C M S TA N D A R D S
Over the past two decades a number of software conﬁguration management standards have been proposed
...
However, more recent ANSI/IEEE standards, such as ANSI/IEEE Stds
...
828-1983, No
...
No
...

9
...
SCM identiﬁes, controls, audits, and reports modiﬁcations
that invariably occur while software is being developed and after it has been released
to a customer
...
The configuration is organized in a manner that
enables orderly control of change
...
In addition to documents, programs, and data, the development environment that is used to create software can also be placed under conﬁguration control
...
Changes to a baselined object result in the creation of a new version of that
object
...
Basic and composite objects form an object pool from
which variants and versions are created
...

Change control is a procedural activity that ensures quality and consistency as
changes are made to a conﬁguration object
...

CHAPTER 9

S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T

239

The conﬁguration audit is an SQA activity that helps to ensure that quality is maintained as changes are made
...

REFERENCES
[BAB86] Babich, W
...
, Software Conﬁguration Management, Addison-Wesley, 1986
...
, “The Highs and Lows of Change Control,” Computer, vol
...
8,
August 1998, pp
...

[BER80] Bersoff, E
...
, V
...
Henderson, and S
...
Siegel, Software Conﬁguration Management, Prentice-Hall, 1980
...
C
...
Scacchi, "Assuring the Correctness of a Conﬁgured Software Description," Proc
...
Workshop on Software Conﬁguration Management,
ACM, Princeton, NJ, October 1989, pp
...

[CLE89] Clemm, G
...
, "Replacing Version Control with Job Control," Proc
...

Workshop on Software Conﬁguration Management, ACM, Princeton, NJ, October 1989,
pp
...

[GUS89] Gustavsson, A
...
2nd Intl
...
114–117
...
, "Conﬁguration Management," HP Professional, vol
...
6, June
1989
...

[LIE89] Lie, A
...
, "Change Oriented Versioning in a Software Engineering Database," Proc
...
Workshop on Software Conﬁguration Management, ACM, Princeton, NJ, October, 1989, pp
...

[NAR87] Narayanaswamy, K
...
Scacchi, "Maintaining Conﬁgurations of Evolving Software Systems," IEEE Trans
...
SE-13, no
...
324–334
...
, "Orthogonal Version Management," Proc
...
Workshop on Software Conﬁguration Management, ACM, Princeton, NJ, October 1989, pp
...

[TAY85] Taylor, B
...
Conf
...
15–23
...
F
...
6th Intl
...
Software Engineering, IEEE, Tokyo, September 1982, pp
...

PROBLEMS AND POINTS TO PONDER
9
...
Why is the First Law of System Engineering true? How does it affect our perception of software engineering paradigms
...
2
...

9
...
Assume that you're the manager of a small project
...
4
...
How would the database handle different versions of the same program? Would source code be handled differently than documentation? How will two
developers be precluded from making different changes to the same SCI at the same
time?
9
...
Do some research on object-oriented databases and write a paper that describes
how they can be used in the context of SCM
...
6
...
1
...

9
...
Research an existing SCM tool and describe how it implements control for versions, variants, and conﬁguration objects in general
...
8
...
Describe ﬁve additional relationships that might be useful in
the context of a project database
...
9
...
Alternatively, read two or three of the papers on SCM and describe
the different data structures and referencing mechanisms that are used for version
control
...
10
...
5 as a guide, develop an even more detailed work breakdown
for change control
...

9
...
Develop a checklist for use during conﬁguration audits
...
12
...
(AntiPatterns and Patterns in Software Conﬁguration Management, Wiley, 1999)
...

Lyon (Practical CM: Best Conﬁguration Management Practices for the 21st Century,
Raven Publishing, 1999) and Mikkelsen and Pherigo (Practical Software Conﬁguration
Management: The Latenight Developer's Handbook, Allyn & Bacon, 1997) provide pragmatic tutorials on important SCM practices
...
S
...
Berlack (Soft-

CHAPTER 9

S O F T WA R E C O N F I G U R AT I O N M A N A G E M E N T

241

ware Conﬁguration Management, Wiley, 1992) presents a useful survey of SCM concepts, emphasizing the importance of the repository and tools in the management
of change
...

Buckley (Implementing Conﬁguration Management, IEEE Computer Society Press,
1993) considers configuration management approaches for all system elements—
hardware, software, and ﬁrmware—with detailed discussions of major CM activities
...
Whitgift (Methods and Tools for Software Conﬁguration
Management, Wiley, 1991) contains reasonable coverage of all important SCM topics, but is distinguished by discussion of repository and CASE environment issues
...

Because SCM identiﬁes and controls software engineering documents, books by
Nagle (Handbook for Preparing Engineering Documents: From Concept to Completion,
IEEE, 1996), Watts (Engineering Documentation Control Handbook: Conﬁguration Management for Industry, Noyes Publications, 1993), Ayer and Patrinnostro (Documenting
the Software Process, McGraw-Hill, 1992) provide a complement to more-focused SCM
texts
...

A wide variety of information sources on software conﬁguration management and
related subjects is available on the Internet
...
mhhe
...
mhtml

PA R T

Three
CONVENTIONAL
METHODS FOR
SOFTWARE
ENGINEERING
n 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 computer software
...

243

CHAPTER

10
KEY
CONCEPTS
application
architecture
...
251
data
architecture
...
247
product
engineering
...
256
requirements
engineering
...
246
system
modeling
...
260

SYSTEM ENGINEERING

lmost 500 years ago, Machiavelli said: "there is nothing more difﬁcult
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
...

Although technology has made great strides since Machiavelli spoke, his words
continue to ring true
...
Instead of concentrating solely on software, system engineering
focuses on a variety of elements, analyzing, designing, and organizing those
elements into a system that can be a product, a service, or a technology for the
transformation of information or control
...
When a
product (in this context, a product includes everything from a wireless telephone to an air trafﬁc control system) is to be built, the process is called product engineering
...
Although each is applied
in a different application domain, both strive to put software into context
...
If you rush to build

stood
...
Before you worry

QUICK
LOOK

and other system elements must be identiﬁed; and

about the trees, understand the forest
...
These activities are the foundation of system

ing information from the customer; requirements

engineering
...

dated by both practitioners and customers
...
” In this context, the ”for-

changes are properly controlled
...

sequence of system engineering
...
As

model, but it must communicate the operational,

important, expect changes to the system require-

functional, and behavioral characteristics of the

ments and manage them using solid SCM (Chap-

system to be built and provide insight into the sys-

ter 9) methods
...

is, both business process engineering and product engineering1 work to allocate a
role for computer software and, at the same time, to establish the links that tie software to other elements of a computer-based system
...

10
...
We speak of political systems and educational systems, of avionics systems and
manufacturing systems, of banking systems and subway systems
...
We use the adjective describing system to understand the context in which the
word is used
...
a set or arrangement of things so related as to form a unity or organic whole; 2
...
, classiﬁed and arranged in an orderly form so as to show a logical plan linking the various parts; 3
...

an established way of doing something; method; procedure
...
System is a special word
...

The goal may be to support some business function or to develop a product that can
be sold to generate business revenue
...
However, in this book, the
term system engineering is generic and is used to encompass both business process engineering
and product engineering
...
Computer programs, data structures, and related documentation
that serve to effect the logical method, procedure, or control that is required
...
Electronic devices that provide computing capability, the interconnectivity devices (e
...
, network switches, telecommunications devices)

Don’t be lured into
taking a “softwarecentric” view
...

that enable the ﬂow of data, and electromechanical devices (e
...
, sensors,
motors, pumps) that provide external world function
...
Users and operators of hardware and software
...
A large, organized collection of information that is accessed via
software
...
Descriptive information (e
...
, hardcopy manuals, on-line
help ﬁles, Web sites) that portrays the use and/or operation of the system
...
The steps that deﬁne the speciﬁc use of each system element
or the procedural context in which the system resides
...
For example, a marketing department transforms raw sales data into a proﬁle of the typical
purchaser of a product; a robot transforms a command ﬁle containing speciﬁc instructions into a set of control signals that cause some speciﬁc physical action
...

One complicating characteristic of computer-based systems is that the elements
constituting one system may also represent one macro element of a still larger
system
...
As an example, we consider a "factory automation system"

Complex systems are
actually a hierarchy of
macro elements that
are themselves
systems
...
At the lowest level of the hierarchy we have
a numerical control machine, robots, and data entry devices
...
The elements of the numerical control machine include
electronic and electromechanical hardware (e
...
, processor and memory, motors,
sensors), software (for communications, machine control, interpolation), people (the
machine operator), a database (the stored NC program), documentation, and procedures
...

Each is a computer-based system
...
The manufacturing cell is a computer-based system that may have elements of its own (e
...
, computers, mechanical fixtures) and also integrates the macro elements that we have
called numerical control machine, robot, and data entry device
...
In some cases, macro elements may share a generic
element
...
In other cases, generic elements are exclusive
to one system
...
1
The system
engineering
hierarchy

Business or
product domain

World view

Domain of interest

System element

Domain view

Element view

Detailed view

The role of the system engineer is to deﬁne the elements for a speciﬁc computerbased system in the context of the overall hierarchy of systems (macro elements)
...

10
...
1
...
” That is, the entire
business or product domain is examined to ensure that the proper business or technology context can be established
...
Within a speciﬁc domain, the need for targeted system
elements (e
...
, data, software, hardware, people) is analyzed
...
At the top of the
hierarchy, a very broad context is established and, at the bottom, detailed technical
activities, performed by the relevant engineering discipline (e
...
, hardware or software engineering), are conducted
...

WV = {D1, D2, D3,
...

Di = {E1, E2, E3,
...
, Ck}
In the software context, a component could be a computer program, a reusable program component, a module, a class or object, or even a programming language statement
...
However, the world view
portrays a clear definition of overall functionality that will enable the engineer to
understand the domain, and ultimately the system or product, in the proper context
...
2
...
Whether the focus is on the world view
or the detailed view, the engineer creates models that [MOT92]
•

engineering model
accomplish?

Deﬁne the processes that serve the needs of the view under consideration
...

•

Explicitly deﬁne both exogenous and endogenous input3 to the model
...

To construct a system model, the engineer should consider a number of restraining
factors:

2

3

In some situations, however, system engineers must ﬁrst consider individual system elements
and/or detailed requirements
...

Exogenous inputs link one constituent of a given view with other constituents at the same level or
other levels; endogenous input links individual components of a constituent at a particular view
...
Assumptions that reduce the number of possible permutations and variations,
thus enabling a model to reﬂect the problem in a reasonable manner
...
One domain of the product
enables the representation of 3D human forms
...
The system engineer makes certain
assumptions about the range of allowable human movement (e
...
, legs cannot be wrapped around the torso) so that the range of inputs and processing
can be limited
...
Simpliﬁcations that enable the model to be created in a timely manner
...
The system engineer is mod-

A system engineer
considers the following
factors when
developing alternative
solutions: assumptions,
simpliﬁcations,
limitations, constraints,
and customer
preferences
...
Although a service order can
be derived from many origins, the engineer categorizes only two sources:
internal demand and external request
...

3
...
For example, an aircraft avionics
system is being modeled for a next generation aircraft
...

4
...
For example, the technology infrastructure for the three-dimensional rendering system described previously is a single G4-based processor
...

5
...
The preferred solution sometimes comes into conﬂict with other
restraining factors
...

The resultant system model (at any view) may call for a completely automated
solution, a semi-automated solution, or a nonautomated approach
...
In essence, the system engineer simply modiﬁes the relative inﬂuence of different system elements (people, hardware, software) to derive models of
each type
...
2
...
M
...
" In
fact, for at least one class of system—the reactive system—we continue to do this today
...

If simulation capability
is unavailable for a
reactive system,
project risk increases
...

That is, real-world events are monitored by the hardware and software that form the
computer-based system, and based on these events, the system imposes control on
the machines, processes, and even people who cause the events to occur
...

Unfortunately, the developers of reactive systems sometimes struggle to make
them perform properly
...
In a very real sense,
the construction of many real-time systems was an adventure in "ﬂying
...
" If the system crashed due to incorrect function, inappropriate behavior, or
poor performance, we picked up the pieces and started over again
...
g
...
If the system fails, significant economic or human loss could
occur
...

Today, software tools for system modeling and simulation are being used to help
to eliminate surprises when reactive, computer-based systems are built
...
Modeling and simulation tools
enable a system engineer to "test drive" a speciﬁcation of the system
...
3

details and specialized modeling techniques that are used to enable a test drive are
discussed brieﬂy in Chapter 31
...
Michael Guttman [GUT99] describes
the challenge when he states:
[T]oday's computing environment consists of computing power that's distributed over an
enterprise-wide array of heterogeneous processing units, scaled and conﬁgured for a wide
variety of tasks
...

252

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

However, the price for this change is largely borne by the IT [information technology]
organizations that must support this polyglot conﬁguration
...
It must design, implement,
and support its own unique conﬁguration of heterogeneous computing resources, distributed logically and geographically throughout the enterprise, and connected by an appropriate enterprise-wide networking scheme
...
These diverse and incremental changes must be coordinated across a distributed environment consisting of hardware and software supplied by dozens, if not hundreds, of vendors
...

When taking a world view of a company’s information technology needs, there is little doubt that system engineering is required
...
Business process engineering is one approach for creating an overall plan for

Three different
architectures are
developed during BPE:
data architecture,
application
architecture, and
technology
infrastructure
...

Three different architectures must be analyzed and designed within the context
of business objectives and goals:
•

data architecture

•

applications architecture

•

technology infrastructure

The data architecture provides a framework for the information needs of a business
XRef
Data objects are
discussed in detail in
Chapter 12
...
The individual building blocks of the architecture are the data
objects that are used by the business
...
For example, an information engineer might deﬁne the data object customer
...
A relationship
indicates how objects are connected to one another
...
The two objects can be connected by the relationship purchases; that is, a customer purchases product A or product A is purchased
by a customer
...

XRef
A detailed discussion of
software architecture is
presented in Chapter
14
...
In the context
of this book, we consider the application architecture to be the system of programs
(software) that performs this transformation
...

The technology infrastructure provides the foundation for the data and application
architectures
...
This includes computers, operating systems,
networks, telecommunication links, storage technologies, and the architecture (e
...
,
client/server) that has been designed to implement these technologies
...
Referring to Figure 10
...
However,
if it’s clear that these
activities haven’t been
done, inform the
stakeholders that the
project risk is very
high
...
ISP views the entire business as an entity
and isolates the domains of the business (e
...
, engineering, manufacturing, marketing, ﬁnance, sales) that are important to the overall enterprise
...

The domain view is addressed with a BPE activity called business area analysis
(BAA)
...
It is only
concerned with specifying what is required in a business area
...

BAA views the business area as an entity and isolates the business functions and procedures that enable the business area to meet its objectives and goals
...
But at this level, these characteristics are all bounded by the business area being analyzed
...

Once an information system has been isolated for further development, BPE makes
a transition into software engineering
...

254

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 10
...
The architecture and infrastructure are implemented by constructing an
appropriate database and internal data structures, by building applications using
software components, and by selecting appropriate elements of a technology infrastructure to support the design created during BSD
...

The integration activity also places the new information system into the business
area context, performing all user training and logistics support to achieve a smooth
transition
...
4

PRODUCT ENGINEERING: AN OVERVIEW
The goal of product engineering is to translate the customer’s desire for a set of deﬁned
capabilities into a working product
...
2 is associated
with information engineering, the predecessor of modern BPE
...

CHAPTER 10

255

SYSTEM ENGINEERING

F I G U R E 10
...
The architecture encompasses four distinct system components: software, hardware, data (and
databases), and people
...
g
...

Referring to Figure 10
...
The overall requirements of the product are elicited from the customer
...
Once these requirements are known, the job of requirements engineering
is to allocate function and behavior to each of the four components noted earlier
...
System
component engineering is actually a set of concurrent activities that address each of
the system components separately: software engineering, hardware engineering,
human engineering, and database engineering
...
Part of

256

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

the role of requirements engineering is to establish the interfacing mechanisms that
will enable this to happen
...
For software engineering, this means analysis and design
modeling activities (covered in detail in later chapters) and construction and integration activities that encompass code generation, testing, and support steps
...
Design maps the analysis model into data, architectural, interface, and software component-level designs
...
5

REQUIREMENTS ENGINEERING
The outcome of the system engineering process is the speciﬁcation of a computerbased system or product at the different levels described generically in Figure 10
...

“The hardest single
part of building a
software system is
deciding what to
build
...
No other part
is more difﬁcult to
rectify later
...

Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the speciﬁcation,
and managing the requirements as they are transformed into an operational system
[THA97]
...
sei
...
edu/
publications/
documents/92
...
tr
...
html

requirements analysis and negotiation

•

WebRef

requirements elicitation

requirements management

10
...
1 Requirements Elicitation
It certainly seems simple enough—ask the customer, the users, and others what the
objectives for the system or product are, what is to be accomplished, how the system or product ﬁts into the needs of the business, and ﬁnally, how the system or product is to be used on a day-to-day basis
...

Christel and Kang [CRI92] identify a number of problems that help us understand
why requirements elicitation is difﬁcult:

CHAPTER 10

?

Why is it so
difﬁcult to
gain a clear
understanding of
what the
customer wants?

•

SYSTEM ENGINEERING

257

Problems of scope
...

•

Problems of understanding
...

•

Problems of volatility
...

To help overcome these problems, system engineers must approach the requirements
gathering activity in an organized manner
...

Assess the business and technical feasibility for the proposed system
...

•

Deﬁne the technical environment (e
...
, computing architecture, operating
system, telecommunications needs) into which the system or product will be
placed
...
e
...

•

Deﬁne one or more requirements elicitation methods (e
...
, interviews, focus
groups, team meetings)
...

•

Identify ambiguous requirements as candidates for prototyping
...

tify key requirements
...
For most systems, the work products include
•

A statement of need and feasibility
...

258

PA R T T H R E E

•

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

A list of customers, users, and other stakeholders who participated in the
requirements elicitation activity
...

•

A list of requirements (preferably organized by function) and the domain
constraints that apply to each
...

•

Any prototypes developed to better deﬁne requirements
...

10
...
2 Requirements Analysis and Negotiation
Once requirements have been gathered, the work products noted earlier form the
basis for requirements analysis
...

?

What
questions
must be asked
and answered
during
requirements
analysis?

As the requirements analysis activity commences, the following questions are
asked and answered:
•

Is each requirement consistent with the overall objective for the
system/product?

•

Have all requirements been speciﬁed at the proper level of abstraction? That
is, do some requirements provide a level of technical detail that is inappropriate at this stage?

•

Is the requirement really necessary or does it represent an add-on feature
that may not be essential to the objective of the system?

•

Is each requirement bounded and unambiguous?

•

Does each requirement have attribution? That is, is a source (generally, a
speciﬁc individual) noted for each requirement?

•

Do any requirements conﬂict with other requirements?

•

Is each requirement achievable in the technical environment that will house
the system or product?

Requirements Analysis

•

Is each requirement testable, once implemented?

It isn’t unusual for customers and users to ask for more than can be achieved,
given limited business resources
...
”

CHAPTER 10

SYSTEM ENGINEERING

259

The system engineer must reconcile these conﬂicts through a process of negotiation
...

Proceed with extreme
caution
...
Risks associated with each requirement are identiﬁed and
analyzed (see Chapter 6 for details)
...
Using an iterative approach, requirements are eliminated, combined, and/or
modiﬁed so that each party achieves some measure of satisfaction
...
5
...
A speciﬁcation can be a written document, a graphical model, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these
...
However, it is sometimes
necessary to remain ﬂexible when a speciﬁcation is to be developed
...
However, usage scenarios may be all that are
required for smaller products or systems that reside within well-understood technical environments
...
It serves as the foundation for hardware engineering, software engineering, database engineering, and human engineering
...
The specification bounds each allocated system element
...

10
...
4 System Modeling
Assume for a moment that you have been asked to specify all requirements for the
construction of a gourmet kitchen
...
You could specify all cabinets and appliances and even indicate where they are to reside in the kitchen
...
In order to fully specify what is to be built, you would need
a meaningful model of the kitchen, that is, a blueprint or three-dimensional rendering that shows the position of the cabinets and appliances and their relationship to
one another
...

260

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

We build system models for much the same reason that we would develop a blueprint or 3D rendering for the kitchen
...
Further discussion of system modeling is presented in Section 10
...

10
...
5 Requirements Validation
The work products produced as a consequence of requirements engineering (a system speciﬁcation and related information) are assessed for quality during a validation step
...

A key concern during
requirements
validation is
consistency
...

The primary requirements validation mechanism is the formal technical review
(Chapter 8)
...

Although the requirements validation review can be conducted in any manner that
results in the discovery of requirements errors, it is useful to examine each requirement against a set of checklist questions
...
g
...
It is best for the
review team to examine small portions of the speciﬁcation, so that attention can be focused on a
speciﬁc aspect of the requirements
...

WebRef
An article entitled
“Making Requirements
Management Work for
You” contains pragmatic
guidelines:
stsc
...
af
...
asp

10
...
6 Requirements Management
In the preceding chapter, we noted that requirements for computer-based systems
change and that the desire to change requirements persists throughout the life of the
system
...
Many of these activities are identical to the software conﬁguration management techniques discussed in Chapter 9
...
Each requirement
is assigned a unique identiﬁer that might take the form

where requirement type takes on values such as F = functional requirement, D = data

Many requirements
management activities
are borrowed from
SCM
...
Hence, a requirement identiﬁed as F09 indicates a functional requirement assigned requirement number 9
...
Shown
schematically in Figure 10
...
Among many possible traceability tables are the following:

When a system is
large and complex,
determining the
“connections” among
requirements can be a
daunting task
...

Features traceability table
...

Source traceability table
...

Dependency traceability table
...

Subsystem traceability table
...

Interface traceability table
...

In many cases, these traceability tables are maintained as part of a requirements database so that they may be quickly searched to understand how a change in one requirement will affect different aspects of the system to be built
...
4
Generic
traceability
table

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Specific aspect of the system or its environment
Requirement

A01 A02 A03 A04 A05

Aii

R01
R02
R03
R04
R05

Rnn

10
...
Hatley and Pirbhai [HAT87] have extended this
view to include two additional system features—user interface processing and maintenance and self-test processing
...

The UML approach can
be applied at the
system level and is
discussed in Chapters
21 and 22
...

Using a representation of input, processing, output, user interface processing, and
self-test processing, a system engineer can create a model of system components
that sets a foundation for later steps in each of the engineering disciplines
...
The system engineer allocates system elements to each of ﬁve processing regions within the
template: (1) user interface, (2) input, (3) system function and control, (4) output, and
(5) maintenance and self-test
...
5
...
A system
context diagram (SCD) resides at the top level of the hierarchy
...
That is, the SCD deﬁnes
all external producers of information used by the system, all external consumers of
information created by the system, and all entities that communicate through the
interface or perform maintenance and self-test
...
5
System model
template
[HAT87]

User interface processing

Input
processing

Process and control
functions

Output
processing

Maintenance and self-test

To illustrate the use of the SCD, consider the conveyor line sorting system that was
introduced in Chapter 5
...
The boxes will pass by a sorting station where they will be identified
...
Boxes pass in random order and are evenly spaced
...

The SCD provides a
“big picture” view of
the system you must
build
...
Reﬁne the
SCD hierarchically to
elaborate the system
...
The PC executes all CLSS software, interacts with the bar code reader
to read part numbers on each box, interacts with the conveyor line monitoring equipment to acquire conveyor line speed, stores all part numbers sorted, interacts with a
sorting station operator to produce a variety of reports and diagnostics, sends control signals to the shunting hardware to sort the boxes, and communicates with a
central factory automation mainframe
...
6
...
6 represents an external entity—that is, a producer or
consumer of system information
...
The symbol for the entire system (or, at lower
levels, major subsystems) is a rectangle with rounded corners
...
The labeled

264

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 10
...
The external entity bar code reader
produces input information that is labeled bar code
...

The system engineer refines the system context diagram by considering the
XRef
The SFD is a precursor
to the data ﬂow
diagram, discussed in
Chapter 12
...
6 in more detail
...
Referring to Figure 10
...
Information flow across the
regions of the SCD is used to guide the system engineer in developing the SFD—
a more detailed "schematic" for CLSS
...
In addition,
the system template partitions the subsystem processing into each of the five
regions discussed earlier
...
hasys
...
html

or more system elements (e
...
, hardware, software, people) as allocated by the
system engineer
...
Each
rounded rectangle in the original SFD can be expanded into another architecture template dedicated solely to it
...
8
...

CHAPTER 10

F I G U R E 10
...
A narrative description of each subsystem and a deﬁnition of all data that ﬂow between subsystems become important elements of the System Speciﬁcation
...
7

SUMMARY
A high-technology system encompasses a number of elements: software, hardware,
people, database, documentation, and procedures
...

System engineering begins by taking a “world view
...
Focus is then narrowed
to a “domain view,” where each of the system elements is analyzed individually
...

266

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 10
...
The intent
of business process engineering is to derive comprehensive data architecture, application architecture, and technology infrastructure that will meet the needs of the business strategy and the objectives and goals of each business area
...

Product engineering is a system engineering approach that begins with system
analysis
...

System engineering demands intense communication between the customer and
the system engineer
...

After requirements have been isolated, a system model is produced and representations of each major subsystem can be developed
...

CHAPTER 10

SYSTEM ENGINEERING

267

REFERENCES
[CRI92]

Christel, M
...
and K
...
Kang, “Issues in Requirements Elicitation,” Software

Engineering Institute, CMU/SEI-92-TR-12 7, September 1992
...
M
...

[GUT99] Guttman, M
...

[HAR93] Hares, J
...
, Information Engineering for the Advanced Practitioner, Wiley, 1993,
pp
...

[HAT87] Hatley, D
...
and I
...
Pirbhai, Strategies for Real-Time System Specification,
Dorset House, 1987
...
, Information Engineering: Book II—Planning and Analysis, PrenticeHall, 1990
...
, "Systems Modeling and Description," Software Engineering
Notes, vol
...
2, April 1992, pp
...

[SOM97] Somerville, I
...
Sawyer, Requirements Engineering, Wiley, 1997
...
, Enterprise Architecture Planning, QED Publishing, 1993
...
H
...
Dorfman, Software Requirements Engineering, 2nd ed
...

PROBLEMS AND POINTS TO PONDER
10
...
Find as many single-word synonyms for the word system as you can
...
2
...
Your hierarchy should extend down to simple system elements (hardware, software, etc
...
"
10
...
Select any large system or product with which you are familiar
...
Describe the set
of elements that make up one or two domains
...

10
...
Select any large system or product with which you are familiar
...

10
...
Business process engineering strives to deﬁne data and application architecture as well as technology infrastructure
...

10
...
Information strategy planning begins with the definitions of objectives and
goals
...

268

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

10
...
A system engineer can come from one of three sources: the system developer,
the customer, or some outside organization
...
Describe an "ideal" system engineer
...
8
...
Develop a set of questions that you should ask as a system engineer
...
Propose at least two different allocations for the system based on answers to
your questions
...
In class, compare your allocation to those of fellow students
...
9
...
Discuss the interplay among attributes and
attempt to provide a method for grading each so that a quantitative "feasibility number" may be developed
...
10
...
Attempt to write a "cookbook" set of guidelines that a technical
manager could apply
...
11
...

10
...
Write a system module narrative that would be contained in system diagram
speciﬁcations for one or more of the subsystems deﬁned in the SFDs developed for
Problem 10
...

10
...
Research the literature on CASE tools and write a brief paper describing how
modeling and simulation tools work
...

10
...
Based on documents provided by your instructor, develop an abbreviated
System Speciﬁcation for one of the following computer-based systems:
a
...
a digital scanner for a personal computer
c
...
a university registration system
e
...
an interactive hotel reservation system
g
...
6
...
15
...

10
...
Are there situations in which formal system speciﬁcation can be abbreviated
or eliminated entirely? Explain
...

Among those that have appeared are
Blanchard, B
...
, System Engineering Management, 2nd ed
...

Rechtin, E
...
W
...

Weiss, D
...
, Software Product-Line Engineering, Addison-Wesley, 1999
...

In recent years, information engineering texts have been replaced by books that
focus on business process engineering
...
Lozinsky (Enterprisewide Software Solutions: Integration Strategies and Practices, Addison-Wesley, 1998)
addresses the use of software packages as a solution that allows a company to migrate
from legacy systems to modern business processes
...
Books by Hares [HAR93], Spewak [SPE93], and Flynn
and Fragoso-Diaz (Information Modeling: An International Perspective, Prentice-Hall,
1996) also treat the subject in detail
...
An excellent IEEE tutorial by Thayer
and Dorfman [THA97] discusses the interrelationship between system and softwarelevel requirements analysis issues
...

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

270

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

System Thinking, Wiley-Interscience, 1976 and On the Design of Stable Systems, WileyInterscience, 1979) have become classics and provide an excellent discussion of "general systems thinking" that implicitly leads to a general approach to system analysis
and design
...

A wide variety of information sources on system engineering and related subjects
is available on the Internet
...
mhhe
...
mhtml

CHAPTER

11
KEY
CONCEPTS
analysis
principles
...
288
FAST
...
288

ANALYSIS CONCEPTS AND
PRINCIPLES

oftware requirements engineering is a process of discovery, reﬁnement,
modeling, and speciﬁcation
...
Models of the required data, information and control ﬂow, and operational behavior are created
...
Donald Reifer [REI94] describes the software requirement engineering process in the following way:

S

information
domain
...
286

lution of user needs and the specification of the external behavior of a system to

prototyping
...
Notice that like all engineering disciplines, requirements

requirements
elicitation
...
279
speciﬁcation
principles
...
294
use-case
...

Both the software engineer and customer take an active role in software
requirements engineering—a set of activities that is often referred to as analysis
...
The developer
acts as interrogator, consultant, problem solver, and negotiator
...
The result

(Chapter 10)
...

QUICK
LOOK

specific requirements that must be achieved to

What are the steps? Data, functional, and behav-

build high-quality software
...
To perform the job

mation from the customer
...

pleteness, and consistency
...
However, for com-

then validated by both software engineers and

plex business applications, a “system analyst”—

customers/users
...

What is the work product? An effective representation of the software must be produced as a

271

272

PA R T T H R E E

QUICK
LOOK

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

consequence of requirements

How do I ensure that I’ve done it right? Software

analysis
...

cation or even a symbolic model
...
”
Douglas Hofstadter

11
...
Communication content is very high
...
Ambiguity is probable
...
"

R E Q U I R E M E N T S A N A LY S I S
Requirements analysis is a software engineering task that bridges the gap between
system level requirements engineering and software design (Figure 11
...
Requirements engineering activities result in the speciﬁcation of software’s operational characteristics (function, data, and behavior), indicate software's interface with other
system elements, and establish constraints that software must meet
...
Requirements analysis provides the software designer with a representation of information, function, and behavior that can
be translated to data, architectural, interface, and component-level designs
...

Software requirements analysis may be divided into ﬁve areas of effort: (1) prob-

“We spend a lot of
time—the majority
of total project
time—not
implementing or
testing, but trying to
decide what to
build
...
Initially, the analyst studies the System Speciﬁcation (if one exists) and the Software Project Plan
...
Next, communication for analysis must be established so that problem recognition is
ensured
...

Problem evaluation and solution synthesis is the next major area of effort for analysis
...
1
Analysis as
a bridge
between
system
engineering
and software
design

A N A LY S I S C O N C E P T S A N D P R I N C I P L E S

273

System
engineering

Software
requirements
analysis

Software
design

interface characteristics, and uncover additional design constraints
...

For example, an inventory control system is required for a major supplier of
auto parts
...

around to update a card file, (3) multiple reorders to the same vendor because
there is no way to associate vendors with components, and so forth
...
For instance,
the customer desires a daily report that indicates what parts have been taken from
inventory and how many similar parts remain
...

Upon evaluating current problems and desired information (input and output), the
analyst begins to synthesize one or more solutions
...
Once this information has been established, basic architectures for implementation are considered
...

274

PA R T T H R E E

? What should
be my
primary focus at
this stage?

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Throughout evaluation and solution synthesis, the analyst's primary focus is on
"what," not "how
...
The model serves as a foundation for software design and as the basis for the creation of speciﬁcations for the
software
...
The customer may be unsure of precisely what is required
...
For these, and many other reasons, an alternative approach to requirements
analysis, called prototyping, may be conducted
...

11
...
A customer has a problem that may be amenable to
a computer-based solution
...

Communication has begun
...

11
...
1 Initiating the Process
The most commonly used requirements elicitation technique is to conduct a meet-

"He who asks a
question is a fool for
ﬁve minutes; he
who does not ask a
question remains a
fool forever
...
The ﬁrst meeting between a software engineer (the analyst) and the
customer can be likened to the awkwardness of a ﬁrst date between two adolescents
...

Yet, communication must be initiated
...
That is, a set of questions that will
lead to a basic understanding of the problem, the people who want a solution, the
nature of the solution that is desired, and the effectiveness of the ﬁrst encounter itself
...
For example, the analyst might ask:
1

Davis [DAV93] argues that the terms what and how are too vague
...

CHAPTER 11

A N A LY S I S C O N C E P T S A N D P R I N C I P L E S

•

Who is behind the request for this work?

•

Who will use the solution?

•

What will be the economic beneﬁt of a successful solution?

•

275

Is there another source for the solution that you need?

These questions help to identify all stakeholders who will have interest in the software to be built
...

The next set of questions enables the analyst to gain a better understanding of the
problem and the customer to voice his or her perceptions about a solution:
•

“Plain question and
plain answer make
the shortest road out
of most
perplexities
...
Gause and
Weinberg [GAU89] call these meta-questions and propose the following (abbreviated)
list:
•

Are you the right person to answer these questions? Are your answers "ofﬁcial"?

If a system or product
will serve many users,
be absolutely certain
that requirements are
elicited from a
representative
cross-section of users
...

•

Are my questions relevant to the problem that you have?

•

Am I asking too many questions?

•

Can anyone else provide additional information?

•

Should I be asking you anything else?

These questions (and others) will help to "break the ice" and initiate the communication that is essential to successful analysis
...
In fact, the Q&A
session should be used for the ﬁrst encounter only and then replaced by a meeting
format that combines elements of problem solving, negotiation, and speciﬁcation
...

11
...
2 Facilitated Application Speciﬁcation Techniques
Too often, customers and software engineers have an unconscious "us and them"
mind-set
...
History has
shown that this approach doesn't work very well
...

WebRef
One approach to FAST is
called “joint application
design” (JAD)
...
bee
...
htm

It is with these problems in mind that a number of independent investigators have
developed a team-oriented approach to requirements gathering that is applied during early stages of analysis and speciﬁcation
...
FAST has been used predominantly by the information systems community, but the technique offers potential for improved communication in applications of all kinds
...
2 Each makes use of a
slightly different scenario, but all apply some variation on the following basic guidelines:
•

? What makes
a FAST

A meeting is conducted at a neutral site and attended by both software engineers and customers
...

•

An agenda is suggested that is formal enough to cover all important points
but informal enough to encourage the free ﬂow of ideas
...

•

A "deﬁnition mechanism" (can be work sheets, ﬂip charts, or wall stickers or
an electronic bulletin board, chat room or virtual forum) is used
...

To better understand the ﬂow of events as they occur in a typical FAST meeting, we
present a brief scenario that outlines the sequence of events that lead up to the meet-

“Facts do not cease
to exist because
they are ignored
...

Initial meetings between the developer and customer (Section 11
...
1) occur and
basic questions and answers help to establish the scope of the problem and the overall perception of a solution
...
" A meeting place, time, and date for FAST
are selected and a facilitator is chosen
...
The product request is distributed
to all attendees before the meeting date
...
, Falls Church, VA
...

system, other objects that are to be produced by the system, and objects that are used
by the system to perform its functions
...
Finally, lists of constraints (e
...
, cost, size, business rules) and performance
criteria (e
...
, speed, accuracy) are also developed
...

As an example,3 assume that a FAST team working for a consumer products company has been provided with the following product description:
Our research indicates that the market for home security systems is growing at a rate of 40
percent per year
...
The product, tentatively called
SafeHome, will use appropriate sensors to detect each situation, can be programmed by the
homeowner, and will automatically telephone a monitoring agency when a situation is
detected
...
But even
with additional information, ambiguity would be present, omissions would likely exist,
and errors might occur
...

The FAST team is composed of representatives from marketing, software and hardware engineering, and manufacturing
...

Each person on the FAST team develops the lists described previously
...

motion detectors, an alarm, an event (a sensor has been activated), a control panel,
a display, telephone numbers, a telephone call, and so on
...
In a similar
fashion, each FAST attendee will develop lists of constraints (e
...
, the system must
have a manufactured cost of less than $80, must be user-friendly, must interface
directly to a standard phone line) and performance criteria (e
...
, a sensor event should
be recognized within one second, an event priority scheme should be implemented)
...
Once
agreement has been established, each participant presents his or her lists for discussion
...
Alternatively, the lists may have been posted on an electronic bulletin board or posed in
3

This example (with extensions and variations) will be used to illustrate important software engineering methods in many of the chapters that follow
...

278

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

a chat room environment for review prior to the meeting
...
At this stage, critique and debate are strictly

Avoid the impulse to
shoot down a
customer’s idea as
“too costly” or
“impractical
...
To do this, you
must keep an open
mind
...

After individual lists are presented in one topic area, a combined list is created by
the group
...
After combined lists for
all topic areas have been created, discussion—coordinated by the facilitator—ensues
...
The objective is to develop a consensus list in each topic
area (objects, services, constraints, and performance)
...

Once the consensus lists have been completed, the team is divided into smaller
subteams; each works to develop mini-speciﬁcations for one or more entries on each
of the lists
...
For example, the mini-speciﬁcation for the SafeHome object control
panel might be
•

mounted on wall

•

size approximately 9 ϫ 5 inches

•

contains standard 12-key pad and special keys

•

contains LCD display of the form shown in sketch [not presented here]

•

all customer interaction occurs through keys

•

used to enable and disable the system

•

software provides interaction guidance, echoes, and the like

•

connected to all sensors

Each subteam then presents each of its mini-specs to all FAST attendees for discussion
...
In some cases, the development of mini-specs will uncover new objects, services, constraints, or performance
requirements that will be added to the original lists
...
An issues list is maintained so that these ideas will be acted on later
...
A consensus

“The beginning is the
most important part
of the work
...
Finally, one or more participants (or outsiders) is assigned the task of writing the complete draft speciﬁcation using all inputs
from the FAST meeting
...
See Section 11
...
4 for details
...
But the team approach provides the beneﬁts of many points of view, instantaneous discussion and reﬁnement, and is a concrete step toward the development
of a speciﬁcation
...
2
...
Originally developed in Japan and ﬁrst used at the Kobe Shipyard of Mitsubishi Heavy Industries, Ltd
...

in the early 1970s, QFD “concentrates on maximizing customer satisfaction from the
software engineering process [ZUL92]
...
QFD identifies three types of requirements
[ZUL92]:
Normal requirements
...
If these requirements are
present, the customer is satisﬁed
...
That’s
how “requirements
creep” sets in
...

Expected requirements
...
Their absence will be a cause for signiﬁcant dissatisfaction
...

Exciting requirements
...
For example, word processing software is requested with standard features
...

In actuality, QFD spans the entire engineering process [AKA90]
...
We present an overview

WebRef
The QFD Institute is an
excellent source for
information:
www
...
org

of only these concepts (adapted for computer software) in the paragraphs that follow
...
Information deployment identiﬁes both
the data objects and events that the system must consume and produce
...
Finally, task deployment examines the behavior of the system or
product within the context of its environment
...

280

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

QFD uses customer interviews and observation, surveys, and examination of historical data (e
...
, problem reports) as raw data for the requirements gathering activity
...
A variety of diagrams, matrices, and
evaluation methods are then used to extract expected requirements and to attempt
to derive exciting requirements [BOS91]
...
2
...
The scenarios, often called use-cases [JAC92], provide a description of how the system will be used
...

To create a use-case, the analyst must ﬁrst identify the different types of people
(or devices) that use the system or product
...
Deﬁned somewhat more formally,
an actor is anything that communicates with the system or product and that is external to the system itself
...
A typical
user may play a number of different roles when using a system, whereas an actor
represents a class of external entities (often, but not always, people) that play just
one role
...
After careful review of requirements, the software
for the control computer requires four different modes (roles) for interaction: pro-

Use-Cases

gramming mode, test mode, monitoring mode, and troubleshooting mode
...
In
some cases, the machine operator can play all of these roles
...

Because requirements elicitation is an evolutionary activity, not all actors are identiﬁed during the ﬁrst iteration
...
Primary

Use-cases are deﬁned
from an actor’s point
of view
...

actors interact to achieve required system function and derive the intended beneﬁt
from the system
...
Secondary
actors support the system so that primary actors can do their work
...
The use-case
describes the manner in which an actor interacts with the system
...
2
SafeHome
control panel

281

A N A LY S I S C O N C E P T S A N D P R I N C I P L E S

SAFEHOME

off
away
stay
instant
bypass
not ready

alarm
check
fire

armed

power

away

1

2

3

max

test

bypass

stay

4

5

6

instant

code

chime

7

8

9

0

#

ready
*

panic

•
•

WebRef
A detailed discussion of
use-cases, including
examples, guidelines, and
templates is presented at
members
...
com/
acockburn/papers/
OnUseCases
...

Recalling basic SafeHome requirements (Section 11
...
2), we can deﬁne three actors:
the homeowner (the user), sensors (devices attached to the system), and the monitoring and response subsystem (the central station that monitors SafeHome)
...
The homeowner
interacts with the product in a number of different ways:
•

enters a password to allow all other interactions

•

inquires about the status of a security zone

•

inquires about the status of a sensor

•

presses the panic button in an emergency

•

activates/deactivates the security system

A use-case for system activation follows:
1
...
2) to determine if the system is ready for input
...
[A not ready indicator implies that a sensor is open; i
...
, that
a door or window is open
...
The homeowner uses the keypad to key in a four-digit password
...
If the password is incorrect, the control panel will beep once and reset itself for

282

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

additional input
...

3
...
2) to activate
the system
...
Away activates all sensors
...
When activation occurs, a red alarm light can be observed by the homeowner
...
It is important to note that each use-case must be reviewed with care
...

Each use-case provides an unambiguous scenario of interaction between an actor
and the software
...
For example, in the use-case just noted, requirements indicate that activation occurs 30 seconds after the stay or away key is hit
...

Use-cases describe scenarios that will be perceived differently by different actors
...
To accomplish this, use-cases are evaluated from the point of view of all actors defined for the system
...
g
...
5 An average priority is then computed, indicating the perceived importance of each of the usecases
...

11
...
Investigators have identiﬁed analysis problems and their causes and have
developed a variety of modeling notations and corresponding sets of heuristics to
overcome them
...
However, all analysis methods are related by a set of operational principles:
1
...

2
...

? What are the
underlying

3
...

4
...

5

Ideally, this evaluation should be performed by individuals from the organization or business
function represented by an actor
...
The analysis process should move from essential information toward implementation detail
...
The
information domain is examined so that function may be understood more completely
...
Partitioning is applied to reduce complexity
...

In addition to these operational analysis principles, Davis [DAV95a] suggests a set6
of guiding principles for requirements engineering:
•

Understand the problem before you begin to create the analysis model
...
This
often leads to elegant software that solves the wrong problem!

•

“A computer will do
what you tell it to
do, but that may be
much different from
what you had in
mind
...
Since the perception of the quality of software is often
based on the perception of the “friendliness” of the interface, prototyping
(and the iteration that results) are highly recommended
...
This is the ﬁrst step
in establishing traceability back to the customer
...
Building data, functional, and behavioral
models provide the software engineer with three different views
...

•

Rank requirements
...
If an incremental process model (Chapter 2) is applied,
those requirements to be delivered in the ﬁrst increment must be identiﬁed
...
Because most requirements are described in a
natural language, the opportunity for ambiguity abounds
...

A software engineer who takes these principles to heart is more likely to develop a
software speciﬁcation that will provide an excellent foundation for design
...
3
...
Interestingly, this
term contains a key to our understanding of software requirements
...
For more
information, see [DAV95a]
...
This fundamental statement of objective is true whether we build batch software for a payroll system or real-time embedded software to control fuel ﬂow to an automobile engine
...
An event

The information
domain of a problem
encompasses data
items or objects that
contain numbers, text,
images, audio, video,
or any combination of
these
...
For example, a pressure
sensor detects that pressure exceeds a safe value and sends an alarm signal to monitoring software
...
Therefore, data (numbers, text, images, sounds, video, etc
...

The ﬁrst operational analysis principle requires an examination of the information
domain and the creation of a data model
...
To fully understand the information domain, each of these
views should be considered
...
For example, the data object, paycheck, is a composite of a number of important pieces of
data: the payee's name, the net amount to be paid, the gross pay, deductions, and so
forth
...
Similarly, the content of a control object called system status might be
defined by a string of bits
...

Data and control objects can be related to other data and control objects
...
During the analysis of the information domain,
these relationships should be deﬁned
...
Referring to Figure 11
...
Along this transformation path (or paths), additional information may be introduced from an existing data store (e
...
, a disk file or memory buffer)
...
Data and control that move between two transformations (functions) deﬁne
the interface for each function
...
Are data or control items to be organized as an n-dimensional table or as
a hierarchical tree structure? Within the context of the structure, what information is
related to other information? Is all information contained within a single structure or

CHAPTER 11

F I G U R E 11
...
It should be noted that data
structure, a related concept discussed later in this book, refers to the design and implementation of information structure within the software
...
3
...
When the entity is a physical thing (a building, a plane, a machine), we can build
a model that is identical in form and shape but smaller in scale
...
It must be capable of representing the information that software transforms, the functions (and subfunctions) that enable the transformation to occur, and the behavior of the system as
the transformation is taking place
...

Functional models
...
When functional models of an application are created,
the software engineer focuses on problem speciﬁc functions
...
e
...
Over a series of iterations, more and more functional detail is
provided, until a thorough delineation of all system functionality is represented
...
Most software responds to events from the outside
world
...
A computer program always exists in some state—an externally
observable mode of behavior (e
...
, waiting, computing, printing, polling) that
is changed only when some event occurs
...
g
...
A
behavioral model creates a representation of the states of the software and
the events that cause a software to change state
...

•

The model becomes the focal point for review and, therefore, the key to a
determination of completeness, consistency, and accuracy of the speciﬁcations
...

The analysis methods that are discussed in Chapters 12 and 21 are actually modeling methods
...

11
...
3 Partitioning
Problems are often too large and complex to be understood as a whole
...
It may be
performed horizontally
or vertically
...
The fourth operational analysis principle suggests that the information, functional, and behavioral domains of software can be partitioned
...
Conceptually, we establish a hierarchical representation of function or information and then
partition the uppermost element by (1) exposing increasing detail by moving vertically in the hierarchy or (2) functionally decomposing the problem by moving horizontally in the hierarchy
...
2
...
The software allocation
for SafeHome (derived as a consequence of system engineering and FAST activities)
can be stated in the following paragraphs:
SafeHome software enables the homeowner to configure the security system when it is
installed, monitors all sensors connected to the security system, and interacts with the
homeowner through a keypad and function keys contained in the SafeHome control panel
shown in Figure 11
...

CHAPTER 11

F I G U R E 11
...
Each sensor is assigned a number and type, a master password is programmed for
arming and disarming the system, and telephone number(s) are input for dialing when a
sensor event occurs
...
After a delay time that is speciﬁed by the homeowner during system conﬁguration activities, the software dials a telephone number of a monitoring service, provides
information about the location, reporting the nature of the event that has been detected
...

All interaction with SafeHome is managed by a user-interaction subsystem that reads
input provided through the keypad and function keys, displays prompting messages on the
LCD display, displays system status information on the LCD display
...

The requirements for SafeHome software may be analyzed by partitioning the information, functional, and behavioral domains of the product
...
Figure 11
...
The problem is partitioned by representing constituent SafeHome software functions, moving horizontally in the functional hierarchy
...

The subfunctions associated with a major SafeHome function may be examined

“Furious activity is no
substitute for
understanding
...
H
...
5
...

The partitioning approach that we have applied to SafeHome functions can also
be applied to the information domain and behavioral domain as well
...
As the problem is partitioned,
interfaces between functions are derived
...

288
F I G U R E 11
...
3
...
For exam-

Avoid the temptation
to move directly to the
implementation view,
assuming that the
essence of the
problem is obvious
...

ple, the essential view of the SafeHome function read sensor status does not concern
itself with the physical form of the data or the type of sensor that is used
...
Similarly, an
essential data model of the data item phone number (implied by the function dial
phone number) can be represented at this stage without regard to the underlying data
structure (if any) used to implement the data item
...

The implementation view of software requirements presents the real world manifestation of processing functions and information structures
...
However, most
computer-based systems are speciﬁed in a manner that dictates accommodation of
certain implementation details
...
The sensor detects illegal entry by
sensing a break in an electronic circuit
...
The analyst must
recognize the constraints imposed by predeﬁned system elements (the sensor) and
consider the implementation view of function and information when such a view is
appropriate
...

CHAPTER 11

A N A LY S I S C O N C E P T S A N D P R I N C I P L E S

289

We have already noted that software requirements engineering should focus on
what the software is to accomplish, rather than on how processing will be implemented
...
Rather, an implementation model represents the current
mode of operation; that is, the existing or proposed allocation for all system elements
...

11
...
”
Bernard Boar

is applied
...
In some cases it is possible to apply operational analysis principles and derive a model of software from which
a design can be developed
...
Finally, some circumstances
require the construction of a prototype at the beginning of analysis, since the model
is the only means through which requirements can be effectively derived
...

11
...
1 Selecting the Prototyping Approach
The prototyping paradigm can be either close-ended or open-ended
...
Using this approach, a prototype
serves solely as a rough demonstration of requirements
...
An open-ended approach, called
evolutionary prototyping, uses the prototype as the ﬁrst part of an analysis activity that
will be continued into design and construction
...

do I
? Whatfor to
look
determine
whether or not
prototyping is a
viable approach?

Before a close-ended or open-ended approach can be chosen, it is necessary to
determine whether the system to be built is amenable to prototyping
...
8
In general, any application that creates dynamic visual displays, interacts heavily
with a user, or demands algorithms or combinatorial processing that must be developed in an evolutionary fashion is a candidate for prototyping
...
If a candidate application
(one that has the characteristics noted) will require the development of tens of thousands of lines of code before any demonstrable function can be performed, it is likely
8

A useful discussion of other candidacy factors—”when to prototype”— can be found in [DAV95b]
...
6
Selecting the
appropriate
prototyping
approach

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Question
Is the application domain understood?
Can the problem be modeled?
Is the customer certain of basic system
requirements?
Are requirements established and stable?
Are any requirements ambiguous?
Are there contradictions in the requirements?

Throwaway
prototype

Evolutionary
prototype

Additional
preliminary
work required

Yes
Yes
Yes/No

Yes
Yes
Yes/No

No
No
No

No
Yes
Yes

Yes
No
No

Yes
Yes
Yes

to be too complex for prototyping
...

Because the customer must interact with the prototype in later steps, it is essential that (1) customer resources be committed to the evaluation and reﬁnement of the
prototype and (2) the customer is capable of making requirements decisions in a
timely fashion
...
Is project management willing and able to work
with the prototyping method? Are prototyping tools available? Do developers have
experience with prototyping methods? Andriole [AND92] suggests six questions (Figure 11
...

11
...
2 Prototyping Methods and Tools
For software prototyping to be effective, a prototype must be developed rapidly so
that the customer may assess results and recommend changes
...
g
...
Fourth generation techniques (4GT)
encompass a broad array of database query and reporting languages, program and application generators, and other very high-level nonprocedural
languages
...

Reusable software components
...
Melding prototyping and program component reuse will

9

In some cases, extremely complex prototypes can be constructed rapidly by using fourth generation techniques or reusable software components
...
It should be noted that an existing software product can be used as a prototype for a "new, improved" competitive
product
...

Formal speciﬁcation and prototyping environments
...

Today, developers of these formal languages are in the process of developing
interactive environments that (1) enable an analyst to interactively create
language-based speciﬁcations of a system or software, (2) invoke automated
tools that translate the language-based speciﬁcations into executable code,
and (3) enable the customer to use the prototype executable code to reﬁne
formal requirements
...
5

S P E C I F I C AT I O N
There is no doubt that the mode of speciﬁcation has much to do with the quality of
solution
...
The quality, timeliness, and completeness of the software suffers as a consequence
...
5
...
Requirements are represented in a manner that ultimately leads to successful software implementation
...
” It should, however,
capture the essense of
what the customer
requires
...
Separate functionality from implementation
...
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 environment
...
Establish the context in which software operates by specifying the manner in
which other system components interact with software
...
Deﬁne the environment in which the system operates and indicate how “a
highly intertwined collection of agents react to stimuli in the environment
(changes to objects) produced by those agents” [BAL86]
...
Create a cognitive model rather than a design or implementation model
...

6
...
” A speciﬁcation is always a model—an abstraction—of some

292

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

real (or envisioned) situation that is normally quite complex
...

7
...

This list of basic speciﬁcation principles provides a basis for representing software
requirements
...
In the next
section we examine a set of guidelines for creating a speciﬁcation of requirements
...
5
...
However, if requirements are committed to paper or an electronic presentation medium (and they almost always should be!) a simple set of guidelines is well
worth following:

?

What are a
few basic
guidelines for
representing
requirements?

Representation format and content should be relevant to the problem
...
However, the representation forms contained within
the speciﬁcation are likely to vary with the application area
...

Information contained within the speciﬁcation should be nested
...
Paragraph and diagram numbering schemes
should indicate the level of detail that is being presented
...

Diagrams and other notational forms should be restricted in number
and consistent in use
...

Representations should be revisable
...
Ideally, CASE tools should be available to update all representations
that are affected by each change
...
g
...
There appears to be little doubt that symbology
and arrangement affect understanding
...
Familiarity often
lies at the root of a person's preference, but other more tangible factors such as spatial arrangement, easily recognizable patterns, and degree of formality often dictate
an individual's choice
...
5
...
The function and performance allocated to software as part of system engineering are refined by establishing a complete information description, a detailed
functional description, a representation of system behavior, an indication of performance requirements and design constraints, appropriate validation criteria, and other
information pertinent to requirements
...
830-1984), and the U
...
Department of Defense have all proposed candidate
formats for software requirements specifications (as well as other software engineering documentation)
...

Actually, the Introduction may be nothing more than the software scope of the planning document
...
Information content, ﬂow, and structure are documented
...

A description of each function required to solve the problem is presented in the
Functional Description
...
The
Behavioral Description section of the speciﬁcation examines the operation of the software as a consequence of external events and internally generated control characteristics
...
How do we recognize a
successful implementation? What classes of tests must be conducted to validate function, performance, and constraints? We neglect this section because completing it
demands a thorough understanding of software requirements—something that we
often do not have at this stage
...
It is essential that time and attention be
given to this section
...
The bibliography
contains references to all documents that relate to the software
...
The appendix contains information that supplements the speciﬁcations
...

294

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

In many cases the Software Requirements Speciﬁcation may be accompanied by an
executable prototype (which in some cases may replace the speciﬁcation), a paper
prototype or a Preliminary User's Manual
...
That is, heavy emphasis is placed on user input and the
resultant output
...

11
...
Because the speciﬁcation forms
the foundation of the development phase, extreme care should be taken in conducting the review
...
However, to fully
explore each of these domains, the review becomes more detailed, examining not
only broad descriptions but the way in which requirements are worded
...
g
...

Once the review is complete, the Software Requirements Speciﬁcation is "signedoff" by both the customer and the developer
...
Requests for changes in requirements after the speciﬁcation is ﬁnalized will not be eliminated
...

Even with the best review procedures in place, a number of common speciﬁcation
problems persist
...
During the review, changes
to the speciﬁcation may be recommended
...
Modern software engineering environments (Chapter 31) incorporate CASE tools that have been developed to help solve these problems
...
7

SUMMARY
Requirements analysis is the ﬁrst technical step in the software process
...

Analysis must focus on the information, functional, and behavioral domains of a
problem
...

In many cases, it is not possible to completely specify a problem at an early stage
...
To properly conduct prototyping
special tools and techniques are required
...
Review is essential to ensure that the developer and the customer have the same
perception of the system
...

REFERENCES
[AKA90] Akao, Y
...
, Quality Function Deployment: Integrating Customer Requirements in Product Design (translated by G
...

[AND92] Andriole, S
...

[BAL86] Balzer, R
...
Goodman, "Principles of Good Specification and Their
Implications for Speciﬁcation Languages," in Software Speciﬁcation Techniques (Gehani,
N
...
McGetrick, eds
...
25–39
...
, Application Prototyping, Wiley-Interscience,1984
...
L
...

[CUR85] Curtis, B
...

[DAV93] Davis, A
...

[DAV95a] Davis, A
...

[DAV95b]

Davis, A
...

[GAU89] Gause, D
...
and G
...
Weinberg, Exploring Requirements: Quality Before
Design, Dorset House, 1989
...
and E
...
), “Requirements Gathering: The Human
Factor,” special issue of CACM, vol
...
5, May 1995
...
, Object-Oriented Software Engineering, Addison-Wesley, 1992
...
W
...
, "Software Storming: Combining Rapid Prototyping and

Knowledge Engineering,” IEEE Computer, vol
...
5, May 1989, pp
...

[REI94]

Reifer, D
...
, “Requirements Engineering,” in Encyclopedia of Software Engi-

neering (J
...
Marciniak, ed
...
1043–1054
...
M
...
T
...
), "Rapid Prototyping in Software Development," special issue of IEEE Computer, vol
...
5, May 1989
...
, “Capturing Requirements with Use-Cases,” Software Development,
February 1996, pp
...

296

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

[ZAH90] Zahniser, R
...
, "Building Software in Groups," American Programmer, vol
...
7–8, July-August 1990
...
, “Quality Function Deployment for Software: Satisfying Customers,” American Programmer, February 1992, pp
...

PROBLEMS AND POINTS TO PONDER
11
...
Software requirements analysis is unquestionably the most communicationintensive step in the software process
...
2
...
For example, workers may feel that
job security is threatened by a new automated system
...
3
...

11
...
Throughout this chapter we refer to the "customer
...
Be careful here, there may be more to this problem than you ﬁrst imagine!
11
...
Develop a facilitated application speciﬁcation techniques "kit
...

11
...
Your instructor will divide the class into groups of four or six students
...
Your job is to deﬁne requirements for the SafeHome security system described in this chapter
...

11
...
Is it fair to say that a Preliminary User's Manual is a form of prototype? Explain
your answer
...
8
...
Represent (using any notation
that seems appropriate) information ﬂow in the system, information content, and any
information structure that is relevant
...
9
...
First perform horizontal partitioning; then perform vertical partitioning
...
10
...

CHAPTER 11

A N A LY S I S C O N C E P T S A N D P R I N C I P L E S

297

11
...
Build a paper prototype (or a real prototype) for SafeHome
...

11
...
Try to identify software components of SafeHome that might be "reusable" in
other products or systems
...

11
...
Develop a written speciﬁcation for SafeHome using the outline provided at
the SEPA Web site
...
) Be sure to apply the questions that are described for the speciﬁcation review
...
14
...
Thayer and Dorfman (Software Requirements Engineering, 2nd ed
...
Graham and Graham (Requirements Engineering and Rapid
Development, Addison-Wesley, 1998) emphasize rapid development and the use of
object-oriented methods in their discussion of requirements engineering, while MacCauley (Requirements Engineering, Springer-Verlag, 1996) presents a brief academic
treatment of the subject
...
Wood and Silver (Joint Application Development, 2nd ed
...

Cohen and Cohen (Quality Function Deployment, Addison-Wesley, 1995), Terninko
(Step-by-Step QFD: Customer-Driven Product Design, Saint Lucie Press, 1997), Gause
and Weinberg [GAU89], and Zahniser [ZAH90] discuss the mechanics of effective
meetings, methods for brainstorming, and elicitation approaches that can be used to
clarify results and a variety of other useful issues
...
Rosenburg and Scott (Use-Case Driven
Object Modeling with UML: A Practical Approach, Addison-Wesley, 1999), Schneider et
al
...

Information domain analysis is a fundamental principle of requirements analysis
...

298

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

A recent book by Harrison (Prototyping and Software Development, SpringerVerlag, 1999) provides a modern perspective on software prototyping
...
Other
books by Pomberger et al
...
(Prototyping with Objects, Prentice-Hall, 1996)
examine prototyping from the object-oriented perspective
...

A wide variety of information sources on requirements analysis and related subjects is available on the Internet
...
mhhe
...
mhtml

CHAPTER

12
KEY
CONCEPTS
analysis model 301
behavioral
modeling
...
324
CSPECs
...
328
DFDs
...
302
ERDs
...
309
PSPECs
...
322
real-time
extensions
...
319

ANALYSIS MODELING

t a technical level, software engineering begins with a series of modeling tasks that lead to a complete speciﬁcation of requirements and a
comprehensive design representation for the software to be built
...
Over the years many methods have been proposed for analysis modeling
...
The ﬁrst, structured analysis, is a classical
modeling method and is described in this chapter
...
Other commonly used
analysis methods are noted in Section 12
...

Structured analysis is a model building activity
...
Structured analysis is not a single method applied consistently by all who use it
...

In his seminal book on the subject, Tom DeMarco [DEM79] describes structured analysis in this way:

A

Looking back over the recognized problems and failings of the analysis phase, I
suggest that we need to make the following additions to our set of analysis phase
goals:

What is it? The written word is a

ber of different points of view
...
Analysis modeling uses a combi-

omissions will be uncovered
...
Data model-

more important, straightforward to review for cor-

ing deﬁnes data objects, attributes, and relation-

rectness, completeness, and consistency
...
Functional modeling indicates how data

Who does it? A software engineer (sometimes called

are transformed within a system
...
Once prelimi-

elicited from the customer
...
A specification incorporating the

299

300

PA R T T H R E E

QUICK
LOOK

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

model is created and then validated by both software engineers
and customers/users
...

How do I ensure that I’ve done it right? Analysis modeling work products must be reviewed for correctness, completeness, and consistency
...
This applies particularly to the
Target Document [software requirements speciﬁcations]
...
The Victorian novel speciﬁcation is out
...

•

We have to differentiate between logical [essential] and physical [implementation] considerations
...

•

Something to help us partition our requirements and document that partitioning before
speciﬁcation
...

•

New tools to describe logic and policy, something better than narrative text
...
But the method has prospered and has gained a substantial following in the software engineering community
...
1

A BRIEF HISTORY
Like many important contributions to software engineering, structured analysis was
not introduced with a single landmark paper or book
...
The
problem is expecting
otherwise and
thinking that having
problems is a
problem
...
" Researchers (e
...
, [STE74], [YOU78]) needed a graphical notation for representing data and the processes that transformed it
...

The term structured analysis, originally coined by Douglas Ross, was popularized
by DeMarco [DEM79]
...
In the years that followed, variations of the structured analysis approach were suggested by Page-Jones
[PAG80], Gane and Sarson [GAN82], and many others
...

CHAPTER 12

301

A N A LY S I S M O D E L I N G

By the mid-1980s, real-time "extensions" were introduced by Ward and Mellor
[WAR85] and later by Hatley and Pirbhai [HAT87]
...

Attempts to develop one consistent notation have been suggested [BRU88], and modernized treatments have been published to accommodate the use of CASE tools
[YOU89]
...
2

T H E E L E M E N T S O F T H E A N A LY S I S M O D E L
The analysis model must achieve three primary objectives: (1) to describe what the
customer requires, (2) to establish a basis for the creation of a software design, and
(3) to deﬁne a set of requirements that can be validated once the software is built
...
1
...
Three different diagrams surround the the core
...
The ERD is the notation that is used to conduct the data

Pr
oc

pe
ss
(
ion

Data flow
diagram

t
ica

Entity
relationship
diagram

c if

PS P E C

Data
obj
ect
de
sc
rip
ti

es

on

)

Data dictionary

State-transition
diagram

F I G U R E 12
...
The attributes of each data object noted in the ERD can be described
using a data object description
...
The DFD provides additional
information that is used during the analysis of the information domain and serves as
a basis for the modeling of function
...

The state transition diagram (STD) indicates how the system behaves as a consequence of external events
...
The STD serves as the basis for behavioral modeling
...

The analysis model encompasses each of the diagrams, speciﬁcations, descriptions, and the dictionary noted in Figure 12
...
A more detailed discussion of these
elements of the analysis model is presented in the sections that follow
...
3

D ATA M O D E L I N G
Data modeling answers a set of speciﬁc questions that are relevant to any data processing application
...
The ERD, described in detail later in this section, enables a software engineer to identify data objects and their relationships using a graphical notation
...
”
Martin Modell

transformed, and produced within an application
...
The ERD is especially useful for applications in which data and the relationships that govern data are complex
...
4 and used to represent how data are transformed), data modeling considers data independent of the processing that transforms the data
...
3
...

CHAPTER 12

F I G U R E 12
...
A data object is a representation of almost any composite information that must be understood by software
...
Therefore, width (a single
value) would not be a valid data object, but dimensions (incorporating height, width,

A data object is a
representation of any
composite information
that is processed by
computer software
...

A data object can be an external entity (e
...
, anything that produces or consumes
information), a thing (e
...
, a report or a display), an occurrence (e
...
, a telephone call)
or event (e
...
, an alarm), a role (e
...
, salesperson), an organizational unit (e
...
, accounting department), a place (e
...
, a warehouse), or a structure (e
...
, a ﬁle)
...
2) can be viewed as a data object in the sense that either
can be deﬁned in terms of a set of attributes
...

Data objects (represented in bold) are related to one another
...
datamodel
...
The relationships are always deﬁned by the context of the problem
that is being analyzed
...
1 Therefore, the data object can be represented as
a table as shown in Figure 12
...
The headings in the table reflect attributes of the
object
...
The body of the table represents speciﬁc instances of the data object
...

1

This distinction separates the data object from the class or object deﬁned as part of the object-oriented paradigm discussed in Part Four of this book
...
3
Tabular
representation
of data objects

Naming
attributes

Ties one data object to another,
in this case, owner

Identifier

Instance

Make
Lexus
Chevy
BMW
Ford

Model
LS400
Corvette
750iL
Taurus

Descriptive
attributes

ID#
Body type
AB123
...

Sports
XZ765
...
Sedan

Referential
attributes

Color Owner
White RSP
Red
CCD
White LJL
Blue
BLF

Attributes
...
They can be used to (1) name an instance of the data object,
(2) describe the instance, or (3) make reference to another instance in another table
...

In addition, one or more of the attributes must be deﬁned as an identiﬁer—that is, the
identifier attribute becomes a "key" when we want to find an instance of the data
object
...
Referring to the data object car, a reasonable identiﬁer might be the ID
number
...
The attributes for car might serve well for
an application that would be used by a Department of Motor Vehicles, but these attributes would be useless for an automobile company that needs manufacturing control software
...
g
...

Relationships
...
Consider two data objects, book and bookstore
...

the simple notation illustrated in Figure 12
...
A connection is established between
book and bookstore because the two objects are related
...
We can define a set of
object/relationship pairs that deﬁne the relevant relationships
...

•

A bookstore displays books
...

•

A bookstore sells books
...

CHAPTER 12

F I G U R E 12
...
Figure 12
...

It is important to note that object/relationship pairs are bidirectional
...
A bookstore orders books or books are ordered by a
bookstore
...
3
...
However, additional information related to these basic elements must also be understood
...
But a simple pair that states: object X relates to object Y does not provide enough information for software engineering purposes
...
This leads to a data modeling concept called cardinality
...
The data model must be capable of representing the number of occurrences objects in a given relationship
...
For example, if context is not considered for a bidirectional relation, Figure 12
...
In such cases, rephrasing is necessary
...
Cardinality is usually expressed
as simply 'one' or 'many
...
Taking into consideration all combinations
of 'one' and 'many,' two [objects] can be related as
•

One-to-one (l:l)—An occurrence of [object] 'A' can relate to one and only one occurrence of [object] 'B,' and an occurrence of 'B' can relate to only one occurrence of 'A
...
'
For example, a mother can have many children, but a child can have only one mother
...
'
For example, an uncle can have many nephews, while a nephew can have many uncles
...
It does not, however, provide an indication of whether or not a particular data object must participate in the relationship
...

Modality
...
The modality is 1 if an occurrence of
the relationship is mandatory
...
A customer indicates that
there is a problem
...
However, if the problem is complex, multiple repair actions may be
required
...
5 illustrates the relationship, cardinality, and modality between
the data objects customer and repair action
...
5
Cardinality
and modality

is provided with

Modality: Mandatory
Implies that in order to
have a repair action(s),
we must have a customer

Repair action

Modality: Optional
Implies that there may
be a situation in which a
repair action is not necessary

CHAPTER 12

F I G U R E 12
...
That
is, a single customer can be provided with zero or many repair actions
...
The vertical bar indicates one and the three-pronged fork indicates many
...
The second vertical bar on the left indicates that there must be a customer
for a repair action to occur
...

12
...
3 Entity/Relationship Diagrams
The primary purpose of
the ERD is to represent
entities (data objects)
and their relationships
with one another
...
3
...
These pairs can be represented graphically using the entity/relationship
diagram
...
A set of primary components are identiﬁed for the ERD: data objects, attributes, relationships, and various type indicators
...

Rudimentary ERD notation has already been introduced in Section 12
...
Data
objects are represented by a labeled rectangle
...
In some variations of the ERD, the connecting line
contains a diamond that is labeled with the relationship
...
3
...

The relationship between the data objects car and manufacturer would be represented as shown in Figure 12
...
One manufacturer builds one or many cars
...
7
An expanded
ERD

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Licenses

Dealership

Stocks

Manufacturer

Builds

Car

Contracts

Transports

Shipper

the context implied by the ERD, the speciﬁcation of the data object car (data object
table in Figure 12
...
3)
...

Expanding the model, we represent a grossly oversimpliﬁed ERD (Figure 12
...
New data objects, shipper and

Develop the ERD
iteratively by reﬁning
both data objects and
the relationships that
connect them
...
In addition, new relationships—transports, contracts,
licenses, and stocks—indicate how the data objects shown in the ﬁgure associate with
one another
...

In addition to the basic ERD notation introduced in Figures 12
...
7, the analyst can represent data object type hierarchies
...
For example, the data object
car can be categorized as domestic, European, or Asian
...
8 represents this categorization in the form of a hierarchy [ROS85]
...
An associative data object is represented as shown in Figure 12
...
In the ﬁgure, each of the data objects that model the individual subsystems is associated with
the data object car
...
8
Data objecttype
hierarchies

Car

European

Swedish

German

F I G U R E 12
...
In most
cases, the data modeling approach is used to create one piece of the analysis model,
but it can also be used for database design and to support any other requirements
analysis methods
...
4

F U N C T I O N A L M O D E L I N G A N D I N F O R M AT I O N F L O W
Information is transformed as it ﬂows through a computer-based system
...
Input may be a control

310

PA R T T H R E E

External
entity

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Input data

External
entity
Intermediate
data

Transform
#1

Intermediate
data

Transform
#2

External
entity

Transform
#3

Intermediate
data

Output data

Transform
#4

Data store
input

Data store
output

Data store

Output data

Input data
External
entity
F I G U R E 12
...
The transform(s) may comprise a single logical
comparison, a complex numerical algorithm, or a rule-inference approach of an expert
system
...
In effect, we can
create a ﬂow model for any computer-based system, regardless of size and complexity
...
A computer-based system is represented as an information transform as shown in Figure
12
...
A rectangle is used to represent an external entity; that is, a system element
(e
...
, hardware, a person, another program) or another system that produces information for transformation by the software or receives information produced by the
software
...
An arrow represents one
or more data items (data objects)
...

The DFD is not
procedural
...

Simply show the ﬂow
of data
...
The simplicity of DFD notation is one reason why structured analysis techniques are widely used
...
Procedure or sequence may be implicit
in the diagram, but explicit logical details are generally delayed until software design
...

CHAPTER 12

311

A N A LY S I S M O D E L I N G

12
...
1 Data Flow Diagrams
As information moves through software, it is modiﬁed by a series of transformations
...

the transforms that are applied as data move from input to output
...
10
...
In fact, DFDs may be partitioned into levels that represent increasing
information ﬂow and functional detail
...
In so doing, it satisﬁes the
second operational analysis principle (i
...
, creating a functional model) discussed in
Chapter 11
...
Additional processes (bubbles)

Reﬁnement from one
DFD level to the next
should follow an
approximate 1:5 ratio,
reducing as the
reﬁnement proceeds
...
For example, a level 1 DFD might contain ﬁve or six bubbles with interconnecting arrows
...

As we noted earlier, each of the bubbles may be reﬁned or layered to depict more
detail
...
11 illustrates this concept
...
We reﬁne the F model into transforms f1 to f7
...
11
Information
ﬂow
reﬁnement

Z

f1

z2

z1

f41

Y

f42

x1

y1

f43

f44

x2
f45
y2

Z

312

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

and output to each reﬁnement must remain the same
...
Further reﬁnement

Although information
ﬂow continuity must
be maintained,
recognize that a data
item represented at
one level may be
reﬁned into its
constituent parts at the
next level
...
Again, the input (X, Y) and output (Z) remain unchanged
...
For example, an arrow shown in a DFD represents a data
object that is input to or output from a process
...
But what is the content of the data implied by the arrow or
depicted by the store? If the arrow (or the store) represents a collection of objects,
what are they? These questions are answered by applying another component of the
basic notation for structured analysis—the data dictionary
...

DFD graphical notation must be augmented with descriptive text
...
The process speciﬁcation describes the input to a function, the algorithm that is applied to transform the input, and the output that is produced
...

12
...
2 Extensions for Real-Time Systems
Many software applications are time dependent and process as much or more control-oriented information as data
...
Aircraft avionics, manufacturing process
control, consumer products, and industrial instrumentation are but a few of hundreds
of real-time software applications
...
These extensions, developed by Ward and Mellor [WAR85] and Hatley and Pirbhai [HAT87] and illustrated in
the sections that follow, enable the analyst to represent control ﬂow and control processing as well as data ﬂow and processing
...
4
...

•

Control information is passed throughout the system and associated control
processing
...
12
Timecontinuous
data ﬂow

Monitored
temperature

313

A N A LY S I S M O D E L I N G

Input
“continuous”

Output
“continuous”

Monitor
and adjust
temperature
level

Corrected
value

Temperature
set point

•

Multiple instances of the same transformation are sometimes encountered in
multitasking situations
...

In a signiﬁcant percentage of real-time applications, the system must monitor timecontinuous information generated by some real-world process
...

time test monitoring system for gas turbine engines might be required to monitor
turbine speed, combustor temperature, and a variety of pressure probes on a continuous basis
...
One extension to basic structured analysis
notation, shown in Figure 12
...
The double headed arrow is used to represent time-continuous ﬂow
while a single headed arrow is used to indicate discrete data ﬂow
...
The process shown in the figure produces a
time-continuous output, corrected value
...
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 often likely that the input and output of time-continuous data will be performance sensitive)
...
Obviously, the digital system collects data in a quasi-continuous fashion using techniques such as high-speed polling
...

In conventional data flow diagrams, control or event flows are not represented
explicitly
...
13
Data and
control ﬂows
using Ward
and Mellor
notation
[WAR85]

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Movement
alarm

Status of each
fixture
Parts status buffer
Bit string

Start/stop
flag

Robot
initiation
control

Monitor
fixture &
operator
interface
Operator
commands

Process
activate

Operator
settings

Process
robot
commands

Position
commands

Robot movement
record
Robot command file

representation of control ﬂow from the data ﬂow diagram
...
Continuing the convention established for data flow diagrams, data flow is
represented using a solid arrow
...
A process that handles only control ﬂows, called a control process,
is similarly represented using a dashed bubble
...

“The environment of
a real-time system
often contains
devices that act as
the senses of the
system
...
13 illustrates control ﬂow and processing as it would be represented using
Ward and Mellor notation
...
As components to be assembled by a robot are
placed on ﬁxtures, a status bit is set within a parts status buffer (a control store)
that indicates the presence or absence of each component
...
The process will read operator commands only when
the control information, bit string, indicates that all ﬁxtures contain components
...
Other data ﬂows occur as a consequence of
the process activate event that is sent to process robot commands
...
This can occur in a multitasking environment when tasks are spawned as a result of internal processing or external events
...
In addition, each robot may have its own

CHAPTER 12

A N A LY S I S M O D E L I N G

315

robot control system
...

12
...
4 Hatley and Pirbhai Extensions
The Hatley and Pirbhai [HAT87] extensions to basic structured analysis notation focus
less on the creation of additional graphical symbols and more on the representation
and speciﬁcation of the control-oriented aspects of the software
...
Unlike Ward and Mellor, Hatley and Pirbhai suggest that dashed and solid notation be represented separately
...
The CFD contains the same processes as

The CFD shows how
events move through a
system
...

the DFD, but shows control ﬂow, rather than data ﬂow
...
In essence, the solid bar can be viewed as a
"window" into an "executive" (the CSPEC) that controls the processes (functions) represented in the DFD based on the event that is passed through the window
...
6
...
A process speciﬁcation is used to describe
the inner workings of a process represented in a ﬂow diagram
...
12 and 12
...
Data ﬂow diagrams are used to represent data and the processes
that manipulate it
...
The
interrelationship between the process and control models is shown schematically in
Figure 12
...
The process model is "connected" to the control model through data
conditions
...

A data condition occurs whenever data input to a process result in control output
...
15, part of a flow model for an automated
monitoring and control system for pressure vessels in an oil refinery
...
When the absolute tank pressure is greater than an allowable
maximum, an above pressure event is generated
...
As we noted earlier, the vertical solid bar into which the above pressure event ﬂows is a pointer to the CSPEC
...

The control speciﬁcation (CSPEC) contains a number of important modeling tools
...
6
...
14
The relationship
between data
and control
models
[HAT87]

data input

Process Model
DFDs

data output

PSPECs
process
activators

Control Model

data
conditions

CFDs

control output

CSPECs
control input

Data flow diagram
Absolute tank
pressure

Control flow diagram

Converted
pressure

Check &
convert
pressure

Check &
convert
pressure
Max
pressure
PSPEC

F I G U R E 12
...
16
Level 1 CFD for
photocopier
software

317

A N A LY S I S M O D E L I N G

Paper feed status
(jammed, empty)

Start/stop

Alarm

Manage
copying

Produce
user
displays

Read
operator
input
Perform
problem
diagnosis
Reload
paper

Full
Repro
fault

processes are activated by a given event
...
15 might indicate that the above pressure event would cause a process
reduce tank pressure (not shown) to be invoked
...
The STD is a behavioral model that relies on the
deﬁnition of a set of system states and is described in the following section
...
5

B E H AV I O R A L M O D E L I N G
Behavioral modeling is an operational principle for all requirements analysis meth-

?

How do I
model the
software’s
reaction to some
external event?

ods
...
The state transition diagram represents the behavior of a system by depicting its states and the events that cause the system to change
state
...
g
...

A state is any observable mode of behavior
...
4
...
Each of these states represents a mode of behavior of the system
...

To illustrate the use of the Hatley and Pirbhai control and behavioral extensions,
consider software embedded within an office photocopying machine
...
16
...

318

F I G U R E 12
...
" For example, the paper feed status and
start/stop events ﬂow into the CSPEC bar
...
If we were to examine the CSPEC internals, the start/stop event would be shown to activate/deactivate the manage copying process
...
It should be noted that all vertical
bars within the CFD refer to the same CSPEC
...
However, this ﬂow does not activate the process
but rather provides control information for the process algorithm
...
17
...
”
A reviewer upon
puzzling over an
extremely complex
STD
...
Each arrow is labeled with a ruled expression
...
The bottom value indicates
the action that occurs as a consequence of the event
...
Note that states do not necessarily correspond to processes on a one-to-one basis
...
16
...
6

A N A LY S I S M O D E L I N G

319

T H E M E C H A N I C S O F S T R U C T U R E D A N A LY S I S
In the previous section, we discussed basic and extended notation for structured
analysis
...
Therefore, be
certain to use ERDs,
DFDs, and STDs when
you build the model
...
To illustrate the use of these heuristics, an adapted version of the
Hatley and Pirbhai [HAT87] extensions to the basic structured analysis notation will
be used throughout the remainder of this chapter
...
Through this discussion, the notation introduced in Section 12
...

12
...
1 Creating an Entity/Relationship Diagram
The entity/relationship diagram enables a software engineer to fully specify the data
objects that are input and output from a system, the attributes that deﬁne the properties of these objects, and their relationships
...
The following approach is
taken:

? What steps
are required

1
...
These “things” evolve into a
or consume information
...
Taking the objects one at a time, the analyst and customer deﬁne whether or
not a connection (unnamed at this stage) exists between the data object and
other objects
...
Wherever a connection exists, the analyst and the customer create one or
more object/relationship pairs
...
For each object/relationship pair, cardinality and modality are explored
...
Steps 2 through 4 are continued iteratively until all object/relationships have
been deﬁned
...

New objects and relationships will invariably be added as the number of iterations grows
...
The attributes of each entity are deﬁned
...
An entity relationship diagram is formalized and reviewed
...
Steps 1 through 7 are repeated until data modeling is complete
...
Referring back to the processing narrative

320

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 12
...
3
...
To accomplish this,
each object is drawn and lines connecting the objects are noted
...
18, a direct connection exists between homeowner and control
panel, security system, and monitoring service
...

Once all connections have been deﬁned, one or more object/relationship pairs are
identified for each connection
...
For example, considering the object/relationship pair security system monitors
sensor, the cardinality between security system and sensor is one to many
...
Using the ERD notation introduced in Section 12
...
19
Developing
relationships
and
cardinality/
modality

321

A N A LY S I S M O D E L I N G

Monitors

Enables/disables
Security
system

Tests

Sensor

Programs

connecting line between security system and sensor would be modiﬁed as shown
in Figure 12
...
Similar analysis would be applied to all other data objects
...
Since we are considering the
software that must support SafeHome, the attributes should focus on data that must
be stored to enable the system to operate
...

12
...
2 Creating a Data Flow Model
The data ﬂow diagram enables the software engineer to develop models of the information domain and functional domain at the same time
...
At the same time, the DFD reﬁnement results in a corresponding reﬁnement of
data as it moves through the processes that embody the application
...
There is a natural tendency to overcomplicate the data flow diagram
...

Again considering the SafeHome product, a level 0 DFD for the system is shown
in Figure 12
...
The primary external entities (boxes) produce information for use by
the system and consume information generated by the system
...
For example, user commands
and data encompasses all configuration commands, all activation/deactivation

322

PA R T T H R E E

F I G U R E 12
...

The level 0 DFD is now expanded into a level 1 model
...
That is, we isolate all nouns (and
noun phrases) and verbs (and verb phrases) in the SafeHome narrative originally presented in Chapter 11
...
3
SafeHome software enables the homeowner to configure the security system when it is
installed, monitors all sensors connected to the security system, and interacts with the home-

The grammatical parse
is not foolproof, but it
will provide you with
an excellent jump start
if you’re struggling to
deﬁne data objects
and transforms
...
2
...
Each sensor is assigned a number and type, a master password is programmed for
arming and disarming the system, and telephone number(s) are input for dialing when a
sensor event occurs
...
After a delay time that is speciﬁed by the homeowner during system conﬁguration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected
...

All interaction with SafeHome is managed by a user-interaction subsystem that reads
input provided through the keypad and function keys, displays prompting messages on the
LCD display, displays system status information on the LCD display
...

Referring to the "grammatical parse," a pattern begins to emerge
...

CHAPTER 12

323

A N A LY S I S M O D E L I N G

Control
panel
Configure
system

User commands
and data

Interact
with
user

Configure
request

Start
stop

Password

Activate/
deactivate
system

Process
password

Valid ID msg
...

Display
messages
and status

Display
information

Sensor
information

Control
panel
display

Alarm

Alarm type
Telephone
number tones

Telephone
line

F I G U R E 12
...
All nouns are either external entities (boxes), data or control objects
(arrows), or data stores (double lines)
...
g
...
Therefore, by
performing a grammatical parse on the processing narrative for a bubble at any DFD

Be certain that the
processing narrative
you intend to parse is
written at the same
level of abstraction
throughout
...
Using this information, a level 1 DFD is shown in Figure 12
...

The context level process shown in Figure 12
...
Similarly, the information
ﬂow between processes at level 1 has been derived from the parse
...
Elaboration of the content of inputs and output at DFD levels 0 and 1 is postponed until Section 12
...

The processes represented at DFD level 1 can be further reﬁned into lower levels
...
22
...

324

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 12
...

That is, until the process represented by the bubble performs a function that would
be easily implemented as a program component
...

For now, we strive to reﬁne DFDs until each bubble is "single-minded
...
6
...
As we have already noted, however, a large class of applications are "driven" by events rather than data; produce control information rather than reports or
displays, and process information with heavy concern for time and performance
...

The graphical notation required to create a control ﬂow diagram was presented
in Section 12
...
4
...
Events and control items (dashed arrows) are then
added to the diagram and a "window" (a vertical bar) into the control speciﬁcation is
shown
...
g
...
To select potential candidate events, the following guidelines are suggested:

? How do I
select
potential events
for a CFD, STD,
and CSPEC?

•

List all sensors that are "read" by the software
...

•

List all "switches" that are actuated by an operator
...

•

Recalling the noun/verb parse that was applied to the processing narrative,
review all "control items" as possible CSPEC inputs/outputs
...

•

Focus on possible omissions—a very common error in specifying control; for
example, ask: "Is there any other way I can get to this state or exit from it?"

A level 1 CFD for SafeHome software is illustrated in Figure 12
...
Among the events
and control items noted are sensor event (i
...
, a sensor has been tripped), blink
ﬂag (a signal to blink the LCD display), and start/stop switch (a signal to turn the
system on or off)
...
When a control item emanates from a process and flows into the CSPEC
window, control and activation of some other process or an outside entity is implied
...
6
...
The CSPEC contains a state
transition diagram that is a sequential speciﬁcation of behavior
...
The underlying attributes of the CSPEC were introduced in Section 12
...
4
...

Figure 12
...
The labeled transition arrows indicate how the system responds to
events as it traverses the four states deﬁned at this level
...
For example, the STD
(Figure 12
...
Yet, there appears to be no way, other than the occurrence
of sensor event, that will allow the system to return to reading user input
...
23 Level 1 CFD for SafeHome
F I G U R E 12
...

Examine the STD to determine whether there are any other anomalies
...
The PAT represents information contained in the STD in the context of processes,
not states
...
The PAT can be used as a guide for a designer
who must build an executive that controls the processes represented at this level
...
25
...
The modeling notation that provides this information is discussed in the next
section
...
6
...
The content of the process speciﬁcation can
include narrative text, a program design language (PDL) description of the process
algorithm, mathematical equations, tables, diagrams, or charts
...

Input events
Sensor event
Blink flag
Start/stop switch
Display action status
Complete
In progress
Time out

0
0
0

0
0
1

0
1
0

0
1
0

1
0
0

0
0
0

0
0
0

0
0
0

0
1
0

1
0
0

0
0
0

0
0
1

0

0

0

0

1

0

0
0
1
1

1
1
0
0

0
0
1
0

0
0
1
1

1
0
1
0

1
0
1
1

Output
Alarm signal

Process activation
F I G U R E 12
...
21)
...

Process password receives a four-digit password from the interact with user function
...
If the master
password matches, is passed to the message and status display
function
...
If the password matches an entry within
the table, is passed to the message and status display function
...

If additional algorithmic detail is desired at this stage, a program design language
representation may also be included as part of the PSPEC
...

12
...
In each representation data objects and/or control items play a role
...
This is accomplished with the data dictionary
...
This important modeling
notation has been deﬁned in the following manner [YOU89]:
The data dictionary is an organized listing of all data elements that are pertinent to the system, with precise, rigorous deﬁnitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores and [even] intermediate
calculations
...
" Although the format of dictionaries varies from tool to tool, most
contain the following information:
•

Name—the primary name of the data or control item, the data store or an
external entity
...

•

Where-used/how-used—a listing of the processes that use the data or control
item and how it is used (e
...
, input to the process, output from the process,
as a store, as an external entity
...

•

Supplementary information—other information about data types, preset values
(if known), restrictions or limitations, and so forth
...
That is, if an analysis team member decides to name a newly derived data item xyz, but xyz is already in the dictionary, the CASE tool supporting the dictionary posts a warning to indicate duplicate
names
...

“Where-used/how-used” information is recorded automatically from the ﬂow models
...
Although
this may appear unimportant, it is actually one of the most important beneﬁts of the
dictionary
...
For large
projects, it is often quite difﬁcult to determine the impact of a change
...

The notation used to develop a content description is noted in the following table:
Data Construct

Notation

Meaning

=
Sequence

is composed of

+

and

Selection

[|]

either-or

Repetition

{ }n

n repetitions of

( )

optional data

*
...
As a sequence of data items
...
As a selection from among a set of data items
...
As a repeated grouping of data items
...

To illustrate the use of the data dictionary, we return to the level 2 DFD for the
monitor system process for SafeHome, shown in Figure 12
...
Referring to the ﬁgure,
the data item telephone number is speciﬁed as input
...
The data dictionary provides us with a precise deﬁnition of telephone number for the DFD in question
...
The data dictionary entry begins as follows:
name:

telephone number

aliases:

none

where used/how used:

assess against set-up (output)
dial phone (input)

description:
telephone number = [local number|long distance number]
local number = preﬁx + access number
long distance number = 1 + area code + local number
area code = [800 | 888 | 561]
preﬁx = *a three digit number that never starts with 0 or 1*
access number = * any four number string *

The content description is expanded until all composite data items have been represented as elementary items (items that require no further expansion) or until all composite items are represented in terms that would be well-known and unambiguous
to all readers
...
For example, the deﬁnition of area code indicates that only three
area codes (two toll-free and one in South Florida) are valid for this system
...
Although we might
assume that the telephone number represented by the DFD in Figure 12
...

For large computer-based systems, the data dictionary grows rapidly in size and
complexity
...
For this
reason, CASE tools should be used
...
8

O T H E R C L A S S I C A L A N A LY S I S M E T H O D S
Over the years, many other worthwhile software requirements analysis methods have
been used throughout the industry
...
An overview of three important analysis methods:

DSSD, JSD, and SADT

•

Data Structured Systems Development (DSSD) [WAR81], [ORR81]

•

Jackson System Development (JSD) [ JAC83]

•

Structured Analysis and Design Technique (SADT) [ROS77], [ROS85]

CHAPTER 12

A N A LY S I S M O D E L I N G

331

is presented within the SEPA Web site for those readers interested in a broader view
of analysis modeling
...
9

SUMMARY
Structured analysis, a widely used method of requirements modeling, relies on data
modeling and ﬂow modeling to create the basis for a comprehensive analysis model
...
Data and control ﬂow diagrams
are used as a basis for representing the transformation of data and control
...
A behavioral model is created using
the state transition diagram, and data content is developed with a data dictionary
...

The original notation for structured analysis was developed for conventional data
processing applications, but extensions have made the method applicable to realtime systems
...

REFERENCES
[BRU88] Bruyn, W
...
, "ESML: An Extended Systems Modeling Language Based
on the Data Flow Diagram," ACM Software Engineering Notes, vol
...
1, January
1988, pp
...

[CHE77] Chen, P
...

[DEM79] DeMarco, T
...

[GAN82] Gane, T
...
Sarson, Structured Systems Analysis, McDonnell Douglas,
1982
...
J
...
A
...

[JAC83]

Jackson, M
...
, System Development, Prentice-Hall, 1983
...
T
...
,
1981
...
, The Practical Guide to Structured Systems Design, Yourdon
Press, 1980
...
and K
...
Software Engineering, vol
...
1, January 1977, pp
...

[ROS85] Ross, D
...
18, no
...
25–35
...
P
...
J
...
L
...
13, no
...
115–139
...
, A Practical Guide to Logical Data Modeling, McGraw-Hill, 1993
...
D
...

[WAR85] Ward, P
...
and S
...
Mellor, Structured Development for Real-Time Systems
(three volumes), Yourdon Press, 1985
...
N
...
L
...

[YOU89] Yourdon, E
...
, Modern Structured Analysis, Prentice-Hall, 1990
...
1
...
1 and write a
brief paper that outlines how the perception of structured analysis has changed over
time
...

12
...
You have been asked to build one of the following systems:
a
...

b
...

c
...

d
...

e
...

Select the system that is of interest to you and develop an entity/relationship diagram that describes data objects, relationships, and attributes
...
3
...
4
...
2
...

12
...
Using the context-level DFD developed in Problem 12
...
Use a "grammatical parse” on the context-level processing narrative to get yourself started
...
Use meaningful names for each transform
...
6
...
2
...

12
...
Does the information flow continuity concept mean that, if one flow arrow
appears as input at level 0, then one ﬂow arrow must appear as input at subsequent
levels? Discuss your answer
...
8
...
16
...
16?
Ward and Mellor do not use this notation
...
9
...
13
...
13? Hatley and Pirbhai do not use this notation
...
10
...

12
...
Develop a complete ﬂow model for the photocopier software discussed in
Section 12
...
You may use either the Ward and Mellor or Hatley and Pirbhai method
...

12
...
Complete the processing narratives for the analysis model for SafeHome software shown in Figure 12
...
Describe the interaction mechanics between the user
and the system
...
13
...
A description follows:
Citizens can log onto a Web site and report the location and severity of potholes
...
), district (determined from street address), and repair priority
(determined from the size of the pothole)
...
Finally, a
damage ﬁle is created to hold information about reported damage due to the pothole and
includes citizen's name, address, phone number, type of damage, dollar amount of damage
...

Using structured analysis notation, develop a complete analysis model for PHTRS
...
14
...

Do a few hours of research on the application area and conduct a FAST meeting
(Chapter 11) with your fellow students to develop requirements (your instructor will
help you coordinate this)
...

12
...
Software for a video game is to be developed
...
14
...
16
...

Review their literature and write a brief paper that summarizes generic features that
seem to distinguish one tool from another
...
All cover the subject
adequately, but only a few do a truly excellent job
...
Books by Hoffer et al
...
, 1998), Kendall and Kendall (Systems
Analysis and Design, 2nd ed
...
, McGraw-Hill, 1996), Robertson and
Robertson (Complete Systems Analysis, 2 volumes, Dorset House, 1994), and PageJones (The Practical Guide to Structured Systems Design, 2nd ed
...
Yourdon's book on the subject [YOU89] remains among
the most comprehensive coverage published to date
...

However, Edwards (Real-Time Structured Methods: Systems Analysis, Wiley, 1993) also
covers the analysis of real-time systems in considerable detail, presenting a number
of useful examples drawn from actual applications
...
Cutts
(Structured Systems Analysis and Design Methodology, Van Nostrand-Reinhold, 1990)
and Hares (SSADM for the Advanced Practitioner, Wiley, 1990) describe SSADM, a variation on structured analysis that is widely used in the United Kingdom and Europe
...
(Information Modeling: An International Perspective, Prentice-Hall, 1996),
Reingruber and Gregory (Data Modeling Handbook, Wiley, 1995) and Tillman [TIL93]
present detailed tutorials for creating industry-quality data models
...
An interesting book
by Hay (Data Modeling Patterns, Dorset House, 1995) presents typical data model “patterns” that are encountered in many different businesses
...

A wide variety of information sources on structured analysis and related subjects
is available on the Internet
...
mhhe
...
mhtml

CHAPTER

DESIGN CONCEPTS AND
PRINCIPLES

13
KEY
CONCEPTS
abstraction

...
346
coupling
...
353

he designer's goal is to produce a model or representation of an entity
that will later be built
...

Diversiﬁcation is the acquisition of a repertoire of alternatives, the raw material of
design: components, component solutions, and knowledge, all contained in cata-

data structure
...
During convergence, the designer chooses and com-

design concepts
...
The second

design principles 340

phase is the gradual elimination of all but one particular conﬁguration of components,

functional
independence
...

information
hiding
...
343
partitioning
...
338
reﬁnement
...

Software design, like engineering design approaches in other disciplines,
changes continually as new methods, better analysis, and broader understanding

What is it? Design is a mean-

apply to the application to be built
...
It

design approach
...

QUICK
LOOK

set of predeﬁned criteria for “good” design
...
The concepts and

sense, windows and doors in the wrong place
...
a mess
...

complex than a house; hence, we need a blue-

Who does it? Software engineers design computer-

print—the design
...
At the data and archi-

ments model
...
Each is a
work product of the design process
...
During each

How do I ensure that I’ve done it right? At each

design activity, we apply basic concepts and prin-

stage, software design work products are

ciples that lead to high quality
...
The speciﬁcation is composed

and consistency with the requirements and with
one another
...
Software design methodologies lack the depth, ﬂexibility, and quantitative
nature that are normally associated with more classical engineering design disciplines
...
In this chapter, we explore the fundamental concepts and principles that are applicable to all software design
...

13
...
Beginning once software requirements have been analyzed and speciﬁed, software design is the ﬁrst of three techni-

“The most common
miracles of software
engineering are the
transitions from
analysis to design
and design to code
...
Each activity transforms information in a manner that ultimately results
in validated computer software
...
The ﬂow of information during software design is illustrated in Figure 13
...

Software requirements, manifested by the data, functional, and behavioral models,
feed the design task
...

The data design transforms the information domain model created during analysis
into the data structures that will be required to implement the software
...
Part of data design may occur in conjunction with the design of software architecture
...

The architectural design deﬁnes the relationship between major structural elements
of the software, the “design patterns” that can be used to achieve the requirements

ao

Data flow
diagram

Interface
design

(PSPEC)

Data
Dictionary

Componentlevel design

cation
c ifi

Dat

Pro
c
pe
ss

tion
rip
sc
de
Entityrelationship
diagram

337

DESIGN CONCEPTS AND PRINCIPLES

es

bje
ct

CHAPTER 13

Architectural
design

State-transition
diagram
Co

n tr

ol s
p e ci

S
f i c a ti o n ( C

PE

Data
design

C)

The analysis model

The design model

F I G U R E 13
...
The architectural design representation—the framework of a computer-based system—can be derived from the
system speciﬁcation, the analysis model, and the interaction of subsystems deﬁned
within the analysis model
...
An interface implies
a ﬂow of information (e
...
, data and/or control) and a speciﬁc type of behavior
...

The component-level design transforms structural elements of the software architecture into a procedural description of software components
...

During design we make decisions that will ultimately affect the success of software construction and, as important, the ease with which software can be maintained
...

Design is the place where quality is fostered in software engineering
...
Design is
the only way that we can accurately translate a customer's requirements into a ﬁnished software product or system
...
Without design,
we risk building an unstable system—one that will fail when small changes are made;
one that may be difﬁcult to test; one whose quality cannot be assessed until late in
the software process, when time is short and many dollars have already been spent
...
2

THE DESIGN PROCESS
Software design is an iterative process through which requirements are translated
into a “blueprint” for constructing the software
...
That is, the design is represented at a high level of abstraction—
a level that can be directly traced to the speciﬁc system objective and more detailed
data, functional, and behavioral requirements
...
These
can still be traced to requirements, but the connection is more subtle
...
2
...

McGlaughlin [MCG91] suggests three characteristics that serve as a guide for the evaluation of a good design:

“To achieve a good
design, people have
to think the right
way about how to
conduct the design
activity
...

•

The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software
...

Each of these characteristics is actually a goal of the design process
...
Later in this chapter, we discuss design quality criteria

? Are there
generic
guidelines that
will lead to a
good design?

in some detail
...
A design should exhibit an architectural structure that (1) has been created
using recognizable design patterns, (2) is composed of components that
exhibit good design characteristics (these are discussed later in this chapter),
and (3) can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing
...
A design should be modular; that is, the software should be logically parti-

“There are two ways
of constructing a
software design:
One way is to make
it so simple that
there are obviously
no deﬁciencies, and
the other way is to
make it so
complicated that
there are no obvious
deﬁciencies
...
”
C
...
R
...

3
...

4
...

5
...

6
...

7
...

These criteria are not achieved by chance
...

13
...
2 The Evolution of Software Design
The evolution of software design is a continuing process that has spanned the past
four decades
...
Procedural aspects of design deﬁnition evolved into a philosophy
called structured programming [DAH72], [MIL72]
...
Newer design approaches (e
...
, [JAC92], [GAM95]) proposed an object-oriented approach to design derivation
...

Many design methods, growing out of the work just noted, are being applied
throughout the industry
...
Yet, all of these methods
have a number of common characteristics: (1) a mechanism for the translation of
analysis model into a design representation, (2) a notation for representing functional
components and their interfaces, (3) heuristics for reﬁnement and partitioning, and
(4) guidelines for quality assessment
...
These principles and concepts are considered in the sections that follow
...
3

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

DESIGN PRINCIPLES
Software design is both a process and a model
...
It is
important to note, however, that the design process is not simply a cookbook
...

The design model is the equivalent of an architect’s plans for a house
...
g
...
g
...
Similarly, the design model that is created for software provides a variety of different views of the computer software
...

Davis [DAV95] suggests a set1 of principles for software design, which have been
adapted and extended in the following list:
•

The design process should not suffer from “tunnel vision
...
4
...
Because a single
element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisﬁed by
the design model
...
Systems are constructed using
a set of design patterns, many of which have likely been encountered before
...

Time is short and resources are limited! Design time should be invested in
representing truly new ideas and integrating those patterns that already exist
...

That is, the structure of the software design should (whenever possible)

Design consistency and
uniformity are crucial
when large systems
are to be built
...

mimic the structure of the problem domain
...
A design is uniform if it appears that one person developed the entire thing
...
A
design is integrated if care is taken in deﬁning interfaces between design
components
...
For more information, see
[DAV95]
...
The design
concepts discussed in the next section enable a design to achieve this principle
...
Welldesigned software should never “bomb
...

•

Design is not coding, coding is not design
...
The only design decisions made
at the coding level address the small implementation details that enable the
procedural design to be coded
...
A variety of design concepts (Section 13
...

XRef

•

Guidelines for
conducting effective
design reviews are
presented in Chapter 8
...
There is sometimes a tendency to focus on minutiae when the design is
reviewed, missing the forest for the trees
...

When these design principles are properly applied, the software engineer creates a design
that exhibits both external and internal quality factors [MEY88]
...
g
...
2 Internal quality factors are of importance to software
engineers
...
To achieve
internal quality factors, the designer must understand basic design concepts
...
4

DESIGN CONCEPTS
A set of fundamental software design concepts has evolved over the past four decades
...
Each provides the software designer with a foundation from
which more sophisticated design methods can be applied
...

342

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

M
...
Jackson once said: "The beginning of wisdom for a [software engineer] is to
recognize the difference between getting a program to work, and getting it right"
[JAC75]
...
"

13
...
1 Abstraction
When we consider a modular solution to any problem, many levels of abstraction can

“Abstraction is one of
the fundamental
ways that we as
humans cope with
complexity
...
At the highest level of abstraction, a solution is stated in broad terms using
the language of the problem environment
...
Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution
...
Wasserman [WAS83] provides a useful deﬁnition:
[T]he psychological notion of "abstraction" permits one to concentrate on a problem at
some level of generalization without regard to irrelevant low level details; use of abstraction also permits one to work with concepts and terms that are familiar in the problem environment without having to transform them to an unfamiliar structure
...
During system engineering, software is allocated as an element of
a computer-based system
...
" As we move
through the design process, the level of abstraction is reduced
...

As we move through different levels of abstraction, we work to create procedural
and data abstractions
...
An example of a procedural abstraction would
be the word open for a door
...
g
...

walk to the door, reach out and grasp knob, turn knob and pull door, step away from
moving door, etc
...
In the context of the procedural abstraction open, we can deﬁne a data abstraction called door
...
g
...
It follows that the procedural abstraction open would
make use of information contained in the attributes of the data abstraction door
...
For example, the Ada package is a programming language mechanism
that provides support for both data and procedural abstraction
...

CHAPTER 13

DESIGN CONCEPTS AND PRINCIPLES

343

Control abstraction is the third form of abstraction used in software design
...
An example of a control abstraction is the
synchronization semaphore [KAI83] used to coordinate activities in an operating system
...

13
...
2 Reﬁnement
Stepwise reﬁnement is a top-down design strategy originally proposed by Niklaus Wirth
[WIR71]
...

A hierarchy is developed by decomposing a macroscopic statement of function (a
procedural abstraction) in a stepwise fashion until programming language statements
are reached
...
This successive decomposition or reﬁnement of speciﬁcations terminates when all instructions are expressed in terms of any underlying computer
or programming language
...

Every reﬁnement step implies some design decisions
...
the programmer be aware of the underlying criteria (for design decisions) and of the existence of
alternative solutions
...
The difference

There is a tendency to
move immediately to
full detail, skipping the
reﬁnement steps
...

Perform stepwise
reﬁnement
...

Reﬁnement is actually a process of elaboration
...
That
is, the statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the
information
...

Abstraction and reﬁnement are complementary concepts
...
Refinement helps the designer to reveal low-level details as design progresses
...

13
...
3 Modularity
The concept of modularity in computer software has been espoused for almost ﬁve
decades
...
4
...

344

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

It has been stated that "modularity is the single attribute of software that allows
a program to be intellectually manageable" [MYE78]
...
e
...

The number of control paths, span of reference, number of variables, and overall complexity would make understanding close to impossible
...

Let C(x) be a function that deﬁnes the perceived complexity of a problem x, and
E(x) be a function that deﬁnes the effort (in time) required to solve a problem x
...
It does take more time to solve a
difﬁcult problem
...
”
H
...
Mencken

in human problem solving
...
Considering Expression (13-2) and the condition implied by Expressions
(13-1), it follows that
E(p1 + p2) > E(p1) + E(p2)

(13-3)

This leads to a "divide and conquer" conclusion—it's easier to solve a complex problem when you break it into manageable pieces
...
It is, in
fact, an argument for modularity
...
Refer-

Don’t overmodularize
...

ring to Figure 13
...
Given the same set of requirements, more modules means smaller individual size
...

These characteristics lead to a total cost or effort curve shown in the ﬁgure
...

CHAPTER 13

345

DESIGN CONCEPTS AND PRINCIPLES

F I G U R E 13
...
2 do provide useful guidance when modularity is
considered
...
Undermodularity or overmodularity should be avoided
...

Another important question arises when modularity is considered
...

deﬁne an appropriate module of a given size? The answer lies in the method(s) used
to deﬁne modules within a system
...
If a design method provides a systematic
mechanism for decomposing the problem into subproblems, it will reduce
the complexity of the overall problem, thereby achieving an effective modular

?

How can we
evaluate a
design method to
determine if it will
lead to effective
modularity?

solution
...
If a design method enables existing (reusable)
design components to be assembled into a new system, it will yield a modular solution that does not reinvent the wheel
...
If a module can be understood as a standalone unit (without reference to other modules), it will be easier to build and
easier to change
...
If small changes to the system requirements result in
changes to individual modules, rather than systemwide changes, the impact
of change-induced side effects will be minimized
...
If an aberrant condition occurs within a module and
its effects are constrained within that module, the impact of error-induced
side effects will be minimized
...
" There are situations (e
...
, real-time software,

346

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

embedded software) in which relatively minimal speed and memory overhead introduced by subprograms (i
...
, subroutines, procedures) is unacceptable
...
Code may be developed "in-line
...

13
...
4 Software Architecture

WebRef
The STARS Software
Architecture Technology
Guide provides in-depth
information and resources
at
www-ast
...

lmco
...
html

Software architecture alludes to “the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system” [SHA95a]
...
In a broader sense, however, components can be generalized to represent major system elements and their interactions
...

This rendering serves as a framework from which more detailed design activities are
conducted
...

Shaw and Garlan [SHA95a] describe a set of properties that should be speciﬁed as

“A software
architecture is the
development work
product that gives
the highest return on
investment with
respect to quality,
schedule and cost
...

part of an architectural design:
Structural properties
...
g
...
For example, objects are packaged to
encapsulate both data and the processing that manipulates the data and interact via the
invocation of methods
...
The architectural design description should address how
the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics
...
The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems
...

Given the specification of these properties, the architectural design can be represented using one or more of a number of different models [GAR95]
...

Five different types of
models are used to
represent the
architectural design
...
Dynamic models address the behavioral aspects of the program architecture, indicating how the structure or system conﬁguration may change
as a function of external events
...
See Chapter 28 for details
...
3
Structure
terminology
for a call and
return architectural style

M
Fan-out
b

a

Depth

d

t

e

g

c

k

m

l

n

h

o

p

q
Fan-in

i

r

j
Width

or technical process that the system must accommodate
...

A number of different architectural description languages (ADLs) have been developed to represent these models [SHA95b]
...

13
...
5 Control Hierarchy
XRef
A detailed discussion of
architectural styles and
patterns is presented in
Chapter 14
...
It does not represent
procedural aspects of software such as sequence of processes, occurrence or order
of decisions, or repetition of operations; nor is it necessarily applicable to all architectural styles
...
The most common is the treelike diagram (Figure 13
...
However, others
(considered in Part
Four) are applicable
...
4 However, other notations, such as Warnier-Orr [ORR77] and Jackson diagrams
[JAC83] may also be used with equal effectiveness
...
Referring to Figure
13
...
Fan-out is a measure of the number of modules
that are directly controlled by another module
...

4

A call and return architecture (Chapter 14) is a classic program structure that decomposes function into a control hierarchy where a “main” program invokes a number of program components,
which in turn may invoke still other components
...
For
example, referring to Figure 13
...

Module h is subordinate to module e and is ultimately subordinate to module M
...
g
...

The control hierarchy also represents two subtly different characteristics of the
software architecture: visibility and connectivity
...
For example, a module in an object-oriented system
may have access to a wide array of data objects that it has inherited, but makes use
of only a small number of these data objects
...
Connectivity indicates the set of components that are directly invoked or used as
data by a given component
...
5

13
...
6 Structural Partitioning
If the architectural style of a system is hierarchical, the program structure can be partitioned both horizontally and vertically
...
4a, horizontal partitioning deﬁnes separate branches of the modular hierarchy for each major program
function
...
The simplest approach to horizontal partitioning deﬁnes three partitions—input, data transformation (often called
processing) and output
...
On the negative side, horizontal partitioning often
causes more data to be passed across module interfaces and can complicate the overall control of program ﬂow (if processing requires rapid movement from one function to another)
...
A program
component can inherit control logic and/or data from another component without explicit reference in the source code
...
A
structure chart (Chapter 14) indicates connectivity
...
4
Structural
partitioning

Function 1

Function 3

Function 2
(a) Horizontal partitioning

Decision-making
modules

“Worker”
modules
(b) Vertical partitioning

Vertical partitioning (Figure 13
...
Toplevel modules should perform control functions and do little actual processing work
...

The nature of change in program structures justifies the need for vertical parti-

“Worker” modules
tend to change more
frequently than control
modules
...

tioning
...
4b, it can be seen that a change in a control module
(high in the structure) will have a higher probability of propagating side effects to
modules that are subordinate to it
...
In general,
changes to computer programs revolve around changes to input, computation or
transformation, and output
...
e
...
For this reason vertically partitioned structures
are less likely to be susceptible to side effects when changes are made and will therefore be more maintainable—a key quality factor
...
4
...
Because the structure of information will invariably affect the ﬁnal procedural design, data structure is as important as program structure to the
representation of software architecture
...
Entire texts (e
...
, [AHO83], [KRU84],
[GAN89]) have been dedicated to these topics, and a complete discussion is beyond
the scope of this book
...

The organization and complexity of a data structure are limited only by the ingenuity of the designer
...
”
Baruch Spinoza

that form the building blocks for more sophisticated structures
...
As its name implies, a scalar
item represents a single element of information that may be addressed by an identiﬁer; that is, access may be achieved by specifying a single address in memory
...
For example, a scalar item may be a logical entity one bit long,
an integer or ﬂoating point number that is 8 to 64 bits long, or a character string that
is hundreds or thousands of bytes long
...
Vectors are the most common of all data structures and open the door to
variable indexing of information
...
The most common n-dimensional space is the two-dimensional matrix
...

Items, vectors, and spaces may be organized in a variety of formats
...
Each node contains the appropriate data organization (e
...
, a vector) and one or more pointers that
indicate the address in storage of the next node in the list
...

Other data structures incorporate or are constructed using the fundamental data

Spend at least as
much time designing
data structures as you
intend to spend
designing the
algorithms to
manipulate them
...

structures just described
...
A hierarchical structure is commonly encountered in applications that require
information categorization and associativity
...
For example, a stack is a conceptual
model of a data structure that can be implemented as a vector or a linked list
...

CHAPTER 13

351

DESIGN CONCEPTS AND PRINCIPLES

F I G U R E 13
...
4
...
Software procedure focuses on the processing details of each
module individually
...

There is, of course, a relationship between structure and procedure
...
That is, a procedural representation of software is
layered as illustrated in Figure 13
...
6

13
...
9 Information Hiding
The concept of modularity leads every software designer to a fundamental question: "How do we decompose a software solution to obtain the best set of modules?" The principle of information hiding [PAR72] suggests that modules be

6

This is not true for all architectural styles
...

352

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

"characterized by design decisions that (each) hides from all others
...

Hiding implies that effective modularity can be achieved by deﬁning a set of independent modules that communicate with one another only that information necessary to achieve software function
...
Hiding deﬁnes and enforces access
constraints to both procedural detail within a module and any local data structure
used by the module [ROS75]
...
Because most data and procedure are hidden from other
parts of the software, inadvertent errors introduced during modiﬁcation are less likely
to propagate to other locations within the software
...
5

EFFECTIVE MODULAR DESIGN
All the fundamental design concepts described in the preceding section serve to precipitate modular designs
...
A modular design reduces complexity (see Section 13
...
3),
facilitates change (a critical aspect of software maintainability), and results in easier
implementation by encouraging parallel development of different parts of a system
...
5
...
In landmark papers on software
design Parnas [PAR72] and Wirth [WIR71] allude to reﬁnement techniques that enhance
module independence
...

Functional independence is achieved by developing modules with "single-minded"
function and an "aversion" to excessive interaction with other modules
...

tion of requirements and has a simple interface when viewed from other parts of the
program structure
...
Software with
effective modularity, that is, independent modules, is easier to develop because function may be compartmentalized and interfaces are simpliﬁed (consider the ramiﬁcations when development is conducted by a team)
...
To
summarize, functional independence is a key to good design, and design is the key
to software quality
...

Cohesion is a measure of the relative functional strength of a module
...

13
...
2 Cohesion
Cohesion is a natural extension of the information hiding concept described in Section 13
...
9
...
Stated simply, a cohesive module should (ideally) do just one thing
...

Cohesion may be represented as a "spectrum
...
The scale for cohesion is nonlinear
...
In practice, a designer need not be
concerned with categorizing cohesion in a speciﬁc module
...

At the low (undesirable) end of the spectrum, we encounter a module that performs a set of tasks that relate to each other loosely, if at all
...
A module that performs tasks that are related logically (e
...
,
a module that produces all output regardless of type) is logically cohesive
...

As an example of low cohesion, consider a module that performs error processing for an engineering analysis package
...
It performs the following tasks: (1) computes supplementary data based on original computed data, (2) produces an error report
(with graphical content) on the user's workstation, (3) performs follow-up calculations requested by the user, (4) updates a database, and (5) enables menu selection for subsequent processing
...
Combining the functions into a single module can serve only to increase
the likelihood of error propagation when a modification is made to one of its processing tasks
...
When processing elements of a module are related and must

If you concentrate on
only one thing during
component-level
design, make it
cohesion
...
When all processing elements concentrate on one area of a data structure, communicational cohesion is present
...

As we have already noted, it is unnecessary to determine the precise level of cohesion
...

354

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 13
...
5
...

Coupling depends on the interface complexity between modules, the point at which
entry or reference is made to a module, and what data pass across the interface
...
Simple connectivity

Coupling is a
qualitative indication of
the degree to which a
module is connected to
other modules and to
the outside world
...

Figure 13
...
Modules a
and d are subordinate to different modules
...
Module c is subordinate to module a and is accessed via a conventional argument list, through which data are passed
...
e
...
A
variation of data coupling, called stamp coupling, is found when a portion of a data
structure (rather than simple arguments) is passed via a module interface
...

At moderate levels, coupling is characterized by passage of control between modules
...

Avoid them
...
6 where a “control ﬂag” (a variable that controls decisions in a subordinate or
superordinate module) is passed between modules d and e
...
For example, I/O couples a module to speciﬁc devices, formats,
and communication protocols
...
High coupling also occurs when a number of modules reference a global data area
...
6
...
g
...
Module c initializes the
item
...
Let's assume that an error
occurs and g updates the item incorrectly
...
The apparent cause of abort is module k; the actual cause, module g
...
However, this does not mean that the use of global data is necessarily "bad
...

The highest degree of coupling, content coupling, occurs when one module makes
use of data or control information maintained within the boundary of another module
...
This mode of coupling can and should be avoided
...
Variants of external coupling, however, may be introduced during coding
...

13
...
The program structure can be manipulated according to the following set of heuristics:
1
...
Once the program structure has been developed, modules

“The notion that good
[design] techniques
restrict creativity is
like saying that an
artist can paint
without learning the
details of form or a
musician does not
need knowledge of
music theory
...

may be exploded or imploded with an eye toward improving module independence
...
An imploded module is the result of combining the processing implied by two or more modules
...
When
high coupling is expected, modules can sometimes be imploded to reduce
passage of control, reference to global data, and interface complexity
...
Attempt to minimize structures with high fan-out; strive for fan-in as depth
increases
...
7 does not make
effective use of factoring
...
7
Program
structures

x

a

c

b

i

d

m

j

e

g

f

h

k

r

p

n

q

Avoid a "pancaked" structure

module
...
The structure takes an oval shape, indicating a number of
layers of control and highly utilitarian modules at lower levels
...
Keep the scope of effect of a module within the scope of control of that module
...
The scope of control of module e is
all modules that are subordinate and ultimately subordinate to module e
...
7, if module e makes a decision that affects module r,
we have a violation of this heuristic, because module r lies outside the scope
of control of module e
...
Evaluate module interfaces to reduce complexity and redundancy and improve
consistency
...

Interfaces should be designed to pass information simply and should be consistent with the function of a module
...
e
...
The module in question should be reevaluated
...
Deﬁne modules whose function is predictable, but avoid modules that are overly
restrictive
...
7 Modules that have internal "memory" can be unpredictable unless

A detailed report on
software design methods
including a discussion of
all design concepts and
principles found in this
chapter can be obtained
at
www
...
dtic
...
ToC
...

A module that restricts processing to a single subfunction exhibits high
cohesion and is viewed with favor by a designer
...

6
...
" This
design heuristic warns against content coupling
...
Pathological connection refers to branches or
references into the middle of a module
...
7

THE DESIGN MODEL
The design principles and concepts discussed in this chapter establish a foundation
for the creation of the design model that encompasses representations of data, architecture, interfaces, and components
...

In Figure 13
...
The symbolism of
this shape is important
...
Like the pyramid, we want to create a software design that is
stable
...

It is interesting to note that some programmers continue to design implicitly, conducting component-level design as they code
...
The smallest
change may cause the pyramid (and the program) to topple
...
Each method enables the designer

7

A "black box" module is a procedural abstraction
...

13
...
First, the overall
scope of the design effort is described
...

Next, the data design is speciﬁed
...

The architectural design indicates how the program architecture has been derived
from the analysis model
...

Software Design
Speciﬁcation

The design of external and internal program interfaces is represented and a detailed
design of the human/machine interface is described
...

Components—separately addressable elements of software such as subroutines,
functions, or procedures—are initially described with an English-language processing narrative
...
Later, a procedural design tool is used to translate the narrative
into a structured description
...
The purpose of
this cross reference (usually represented as a simple matrix) is (1) to establish that
all requirements are satisﬁed by the software design and (2) to indicate which components are critical to the implementation of speciﬁc requirements
...
Once program structure and interfaces have been established, we
can develop guidelines for testing of individual modules and integration of the entire
package
...
In such cases, this section may be deleted from the Design Speciﬁcation
...
Special considerations caused by the necessity for program
overlay, virtual memory management, high-speed processing, or other factors may
cause modiﬁcation in design derived from information ﬂow or structure
...

The ﬁnal section of the Design Speciﬁcation contains supplementary data
...
It may be advisable to develop a Preliminary Operations/Installation
Manual and include it as an appendix to the design document
...
8

SUMMARY
Design is the technical kernel of software engineering
...
Design results in representations of software that can be assessed for quality
...
Design principles guide the software engineer as the
design process proceeds
...

Modularity (in both program and data) and the concept of abstraction enable the
designer to simplify and reuse software components
...
Program and data structure contribute to an overall view of software architecture, while procedure provides
the detail necessary for algorithm implementation
...

We conclude our discussion of design fundamentals with the words of Glenford
Myers [MYE78]:
We try to solve the problem by rushing through the design process so that enough time will
be left at the end of the project to uncover errors that were made because we rushed through
the design process
...

We have not concluded our discussion of design
...
These methods, combined with the fundamentals in this chapter, form the basis for a complete view of software design
...
V
...
Hopcroft, and J
...

[BAS98] Bass, L
...
Clements, and R
...

[BEL81] Belady, L
...
J
...

[BRO98] Brown, W
...
, et al
...

[BUS96] Buschmann, F
...
, Pattern-Oriented Software Architecture, Wiley, 1996
...
, E
...
Hoare, Structured Programming, Academic Press,
1972
...
, 201 Principles of Software Development, McGraw-Hill, 1995
...
, "Modularity," in Advanced Course on Software Engineering (F
...

Bauer, ed
...
128–182
...
et al
...

[GAN89] Gonnet, G
...
, AddisonWesley, 1989
...
and M
...
I (V
...
Tortora, eds
...

[JAC75]

Jackson, M
...
, Principles of Program Design, Academic Press, 1975
...
A
...

[JAC92]

Jacobson, I
...

[KAI83]

Kaiser, S
...
, The Design of Operating Systems for Small Computer Systems,

Wiley-Interscience, 1983, pp
...

[KRU84] Kruse, R
...
, Data Structures and Program Design, Prentice-Hall, 1984
...
, “Some Notes on Program Design,” Software Engineering
Notes, vol
...
4, October 1991, pp
...

[MEY88] Meyer, B
...

[MIL72] Mills, H
...
, "Mathematical Foundations for Structured Programming," Technical Report FSC 71-6012, IBM Corp
...

[MYE78] Myers, G
...

[ORR77] Orr, K
...
, Structured Systems Development, Yourdon Press, 1977
...
L
...
14, no
...
221–227
...
, J
...
Irvine, "Software Engineering: Process, Principles and Goals," IEEE Computer, vol
...
5, May 1975
...
and D
...

[SHA95b] Shaw, M
...
, “Abstractions for Software Architecture and Tools to Support Them,” IEEE Trans
...
SE-21, no
...
314–335
...
and D
...

[SOM89] Sommerville, I
...
, Addison-Wesley, 1989
...
, G
...
Constantine, "Structured Design," IBM Systems Journal, vol
...
2, 1974, pp
...

[WAR74] Warnier, J
...

[WAS83] Wasserman, A
...
Freeman and A
...
), 4th ed
...
43
...
, "Program Development by Stepwise Reﬁnement," CACM, vol
...
4, 1971, pp
...

[YOU79] Yourdon, E
...
Constantine, Structured Design, Prentice-Hall, 1979
...
1
...
2
...
3
...
3
...

13
...
Apply a "stepwise reﬁnement approach" to develop three different levels of
procedural abstraction for one or more of the following programs:
a
...

b
...

c
...

13
...
Is there a case when Expression (13-2) may not be true? How might such a
case affect the argument for modularity?
13
...
When should a modular design be implemented as monolithic software? How
can this be accomplished? Is performance the only justiﬁcation for implementation
of monolithic software?
13
...
Develop at least five levels of abstraction for one of the following software
problems:
a
...

b
...

c
...

d
...

e
...

As the level of abstraction decreases, your focus may narrow so that at the last
level (source code) only a single task need be described
...
8
...
How is information hiding used to achieve the decomposition?
13
...
Discuss the relationship between the concept of information hiding as an
attribute of effective modularity and the concept of module independence
...
10
...
Bring in samples of your best and worst work
...
11
...
How does this construct affect coupling? information
hiding?

362

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

13
...
How are the concepts of coupling and software portability related? Provide
examples to support your discussion
...
13
...

13
...
What is the purpose of developing a program structure that is factored?
13
...
Describe the concept of information hiding in your own words
...
16
...
Adams (Conceptual Blockbusting, 3rd ed
...
Finally, a classic text by Polya (How to Solve It, 2nd ed
...

Following in the same tradition, Winograd et al
...

A fascinating book edited by Wixon and Ramsey (Field Methods Casebook for Software
Design, Wiley, 1996) suggests ﬁeld research methods (much like those used by anthropologists) to understand how end-users do the work they do and then design software that meets their needs
...

McConnell (Code Complete, Microsoft Press, 1993) presents an excellent discussion of the practical aspects of designing high-quality computer software
...
, Boyd and Fraser Publishing, 1999) presents an introductory discussion of software design that is useful for those beginning their study
of the subject
...
, IEEE, 1983)
...
Good discussions of software design
fundamentals can be found in books by Myers [MYE78], Peters (Software Design: Methods and Techniques, Yourdon Press, 1981), Macro (Software Engineering: Concepts and

CHAPTER 13

DESIGN CONCEPTS AND PRINCIPLES

363

Management, Prentice-Hall, 1990), and Sommerville (Software Engineering, AddisonWesley, 5th ed
...

Mathematically rigorous treatments of computer software and design fundamentals may be found in books by Jones (Software Development: A Rigorous Approach,
Prentice-Hall, 1980), Wulf (Fundamental Structures of Computer Science, Addison-Wesley, 1981), and Brassard and Bratley (Fundamental of Algorithmics, Prentice-Hall, 1995)
...

Kruse (Data Structures and Program Design, Prentice-Hall, 1994) and Tucker et al
...
Measures of design quality, presented from both the technical and management
perspectives, are considered by Card and Glass (Measuring Software Design Quality,
Prentice-Hall, 1990)
...
An up-to-date list of World Wide Web references that are
relevant to design concepts and methods can be found at the SEPA Web site:
http://www
...
com/engcs/compsci/pressman/resources/
design-principles
...
394
architecture
...
368
data warehouse
...
375
factoring
...
371
styles
...
389
transform
mapping
...
This
description is extended by Freeman [FRE80]:

D

[D]esign is an activity concerned with making major decisions, often of a structural
nature
...
Design builds coherent, well planned representations of programs that
concentrate on the interrelationships of parts at the higher level and the logical operations involved at the lower levels
...

Software design methods are derived from consideration of each of the three
domains of the analysis model
...

Methods required to create “coherent, well planned representations” of the
data and architectural layers of the design model are presented in this chapter
...

What is it? Architectural design

priate architectural style for the requirements

represents the structure of data

derived during system engineering and software

and program components that

requirements analysis
...
It

Why is it important? In the Quick Look for the last

considers the architectural style that the system

chapter, we asked: “You wouldn’t attempt to build

will take, the structure and properties of the com-

a house without a blueprint, would you?” You also

ponents that constitute the system, and the inter-

wouldn’t begin drawing blueprints by sketching

relationships that occur among all architectural

the plumbing layout for the house
...

look at the big picture—the house itself—before

Who does it? Although a software engineer can

you worry about details
...

tems are to be built
...
The “system architect” selects an appro-

vation of one or more representations of the

365

366

PA R T T H R E E

QUICK
LOOK

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

architectural structure of the

structure is created during architectural design
...
Alternative architectural

In addition, component properties and relation-

styles or patterns are analyzed to

ships (interactions) are described
...
Once an alter-

stage, software design work products are

native has been selected, the architecture is elab-

reviewed for clarity, correctness, completeness,

orated using an architectural design method
...

encompassing data architecture and program

14
...
Historically, architectures have been implicit—
accidents of implementation, or legacy systems of the past
...

Today, effective software architecture and its explicit representation and design have
become dominant themes in software engineering
...
1
...
At the most simplistic level, we consider the overall shape of the physical structure
...
It is the manner in which the various
components of the building are integrated to form a cohesive whole
...
umassd
...
html

vicinity
...
It is the aesthetic feel of the structure—the visual impact of
the building—and the way textures, colors, and materials are combined to create the
external facade and the internal “living environment
...
And ﬁnally, it is art
...

The architecture is not the operational software
...

This deﬁnition emphasizes the role of “software components” in any architectural

“The architecture of a
system is a
comprehensive
framework that
describes its form
and structure—its
components and
how they ﬁt
together
...
In the context of architectural design, a software component can be
something as simple as a program module, but it can also be extended to include
databases and “middleware” that enable the conﬁguration of a network of clients and
servers
...
At the
architectural level, internal properties (e
...
, details of an algorithm) are not speciﬁed
...

In this book the design of software architecture considers two levels of the design
pyramid (Figure 13
...
In the context of the preceding discussion, data design enables us to represent the data component of the
architecture
...

14
...
2 Why Is Architecture Important?
In a book dedicated to software architecture, Bass and his colleagues {BAS98] identify three key reasons that software architecture is important:
•

Representations of software architecture are an enabler for communication
between all parties (stakeholders) interested in the development of a computer-based system
...

•

The architecture highlights early design decisions that will have a profound
impact on all software engineering work that follows and, as important, on
the ultimate success of the system as an operational entity
...

The architectural design model and the architectural patterns contained within it are
transferrable
...
3
...

368

PA R T T H R E E

14
...
This data model is then reﬁned
into progressively more implementation-speciﬁc representations that can be processed
by the computer-based system
...

The structure of data has always been an important part of software design
...
At the application level, the translation of a data model (derived as part of
requirements engineering) into a database is pivotal to achieving the business objectives of a system
...

In every case, data design plays an important role
...
2
...
The data design

“Data quality is the
difference between a
data warehouse and
a data garbage
dump
...
But today, businesses large and

the software component level and, when necessary, a database architecture at the
application level
...
It is not unusual for even a moderately sized business to
have dozens of databases serving many applications encompassing hundreds of gigabytes of data
...
g
...

WebRef
Up-to-date information on
data warehouse
technologies can be
obtained at
www
...
com

To solve this challenge, the business IT community has developed data mining
techniques, also called knowledge discovery in databases (KDD), that navigate through
existing databases in an attempt to extract appropriate business-level information
...
An alternative solution, called a data
warehouse, adds an additional layer to the data architecture
...

In a sense, a data warehouse is a large, independent database that encompasses
some, but not all, of the data that are stored in databases that serve the set of applications required by a business
...
A data warehouse is organized by major business
subjects, rather than by business process or function
...

Integration
...
The intent is
to enable access to
“knowledge” that
might not be otherwise
available
...

Time variancy
...
For a data warehouse, however, data
can be accessed at a speciﬁc moment in time (e
...
, customers contacted on
the date that a new product was announced to the trade press)
...

Nonvolatility
...

These characteristics present a unique set of design challenges for a data architect
...
g
...
The interested reader should see the Further Readings and
Information Sources section of this chapter for additional references
...
2
...
Wasserman [WAS80]
has proposed a set of principles that may be used to specify and design such data
structures
...
Recalling that requirements analysis and design often overlap, we consider
the following set of principles [WAS80] for data speciﬁcation:

? What are
principles

1
...
Representations

be applied to data
...
For example, speciﬁcation of a multiringed linked list may nicely satisfy
data requirements but lead to an unwieldy software design
...

2
...
The design of an efﬁcient data structure must take the operations to be
performed on the data structure into account (e
...
, see [AHO83])
...
The
data structure is to be manipulated in a number of major software functions
...
Speciﬁcation of the abstract data type may simplify software design considerably
...
A data dictionary should be established and used to deﬁne both data and program design
...
A data dictionary explicitly represents the relationships among data
objects and the constraints on the elements of a data structure
...

4
...
A process of stepwise reﬁnement may be used for the design of data
...
The top-down approach to data design provides beneﬁts that are
analogous to a top-down approach to software design—major structural
attributes are designed and evaluated ﬁrst so that the architecture of the data
may be established
...
The representation of data structure should be known only to those modules that
must make direct use of the data contained within the structure
...
This principle alludes
to the importance of these concepts as well as "the importance of separating
the logical view of a data object from its physical view" [WAS80]
...
A library of useful data structures and the operations that may be applied to
them should be developed
...
Data structures can be designed for
reusability
...

7
...
The implementation of a sophisticated

CHAPTER 14

ARCHITECTURAL DESIGN

371

data structure can be made exceedingly difﬁcult if no means for direct speciﬁcation of the structure exists in the programming language chosen for implementation
...

14
...
The builder

The ABLE project at CMU
provides useful papers
and examples of
architectural styles:
tom
...
cmu
...
g
...
But more important, the
architectural style is also a pattern for construction
...

The software that is built for computer-based systems also exhibits one of many
architectural styles
...
g
...
In the section that follows, we consider
commonly used architectural patterns for software
...
3
...
A data store (e
...
, a ﬁle or database) resides at the

“The use of patterns
and styles of design
is pervasive in
engineering
disciplines
...
Figure 14
...
Client software accesses a central repository
...
That is, client software accesses the data
independent of any changes to the data or the actions of other client software
...

1

The terms styles and patterns are used interchangeably in this discussion
...
1
Data-centered
architecture

PA R T T H R E E

Client
software

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Client
software

Client
software
Client
software

Data store
(repository or
blackboard)

Client
software

Client
software

Client
software

Client
software

Data-centered architectures promote integrability [BAS98]
...
In addition, data can be passed among clients using the blackboard mechanism (i
...
, the blackboard component serves to coordinate the transfer of information between clients)
...

Data-ﬂow architectures
...
”
Norman Simenson

output data
...
2a) has a set of components, called
ﬁlters, connected by pipes that transmit data from one component to the next
...
However, the ﬁlter does not require knowledge of
the working of its neighboring ﬁlters
...
This pattern (Figure 14
...

Call and return architectures
...
A number of substyles [BAS98] exist within this category:
• Main program/subprogram architectures
...
Figure 13
...

CHAPTER 14

373

ARCHITECTURAL DESIGN

F I G U R E 14
...
The components of a main program/
subprogram architecture are distributed across multiple computers on a network
Object-oriented architectures
...

data and the operations that must be applied to manipulate the data
...

Layered architectures
...
3
...

At the outer layer, components service user interface operations
...
Intermediate layers
provide utility services and application software functions
...
2 Once requirements engineering uncovers the characteristics and constraints of the system to be built, the architectural pattern (style) or combination of
patterns (styles) that best ﬁts those characteristics and constraints can be chosen
...

374

PA R T T H R E E

F I G U R E 14
...

14
...
2 Organization and Reﬁnement
Because the design process often leaves a software engineer with a number of architectural alternatives, it is important to establish a set of design criteria that can be
used to assess an architectural design that is derived
...
How is control managed within the architecture? Does a dis-

architectural style
that has been
derived?

within this control hierarchy? How do components transfer control

tinct control hierarchy exist, and if so, what is the role of components
within the system? How is control shared among components? What is
the control topology (i
...
, the geometric form3 that the control takes)? Is
control synchronized or do components operate asynchronously?

3

A hierarchy is one geometric form, but others such as a hub and spoke control mechanism in a
client/server system are also encountered
...
How are data communicated between components? Is the ﬂow of data
continuous, or are data objects passed to the system sporadically? What is the
mode of data transfer (i
...
, are data passed from one component to another or
are data available globally to be shared among system components)? Do data
components (e
...
, a blackboard or repository) exist, and if so, what is their
role? How do functional components interact with data components? Are data
components passive or active (i
...
, does the data component actively interact
with other components in the system)? How do data and control interact
within the system?
These questions provide the designer with an early assessment of design quality and
lay the foundation for more-detailed analysis of the architecture
...
4

A N A LY Z I N G A LT E R N AT I V E A R C H I T E C T U R A L D E S I G N S
The questions posed in the preceding section provide a preliminary assessment of
the architectural style chosen for a given system
...
”
M
...
Escher

effectively
...
The ﬁrst method uses an iterative method
to assess design trade-offs
...

14
...
1 An Architecture Trade-off Analysis Method
The Software Engineering Institute (SEI) has developed an architecture trade-off analysis method (ATAM) [KAZ98] that establishes an iterative evaluation process for software architectures
...
Collect scenarios
...
sei
...
edu/
ata/ata_method
...

2
...
This information
is required as part of requirements engineering and is used to be certain that
all customer, user, and stakeholder concerns have been addressed
...
Describe the architectural styles/patterns that have been chosen to address the
scenarios and requirements
...

• Process view for analysis of system performance
...

376

XRef
A detailed discussion of
quality attributes is
presented in Chapters
8 and 19
...
Evaluate quality attributes by considering each attribute in isolation
...
Quality attributes for architectural design assessment include
reliability, performance, security, maintainability, ﬂexibility, testability, portability, reusability, and interoperability
...
Identify the sensitivity of quality attributes to various architectural attributes for a
speciﬁc architectural style
...
Any attributes that are signiﬁcantly affected by
variation in the architecture are termed sensitivity points
...
Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5
...
For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases,
within some range, by increasing the number of servers)
...
However, the
security of the system might vary inversely with the number of servers (because
the system contains more potential points of attack)
...
It is an element, potentially
one of many, where architectural trade-offs will be made, consciously or unconsciously
...
Based on the results of steps 5 and
6, some architecture alternatives may be eliminated, one or more of the remaining
architectures may be modiﬁed and represented in more detail, and then the ATAM
steps are reapplied
...
4
...

The ATAM approach discussed in Section 14
...
1 is representative of a useful but undeniably qualitative approach to design analysis
...
Asada and his colleagues [ASA96] suggest a number of pseudoquantitative techniques that can be used to complement the ATAM approach as a
method for the analysis of architectural design quality
...

CHAPTER 14

ARCHITECTURAL DESIGN

377

These criteria, sometimes called design dimensions, often encompass the quality attributes deﬁned in the last section: reliability, performance, security, maintainability,
ﬂexibility, testability, portability, reusability, and interoperability, among others
...
Once the software
architecture has been proposed, it is assessed by assigning a “score” to each of its
design dimensions
...
Worst-case scores4 are then assigned to a hypothetical
design, and a total score, Sw, for the worst case architecture is computed
...
5 We then calculate a spectrum index, Is,
using the equation

“A doctor can bury his
mistakes, but an
architect can only
advise his clients to
plant vines
...

If modiﬁcations are made to the proposed design or if an entirely new design is
proposed, the spectrum indices for both may be compared and an improvement index,
Imp, may be computed:
Imp = Is1 Ϫ Is2
This provides a designer with a relative indication of the improvement associated
with architectural changes or a new proposed architecture
...

Design selection analysis is another model that requires a set of design dimensions
to be deﬁned
...

For example, if a proposed architecture would achieve excellent component reuse,
and this dimension is required for an idea system, the reusability dimension has been
achieved
...

We calculate a design selection index, d, as
d = (Ns/Na) ϫ 100
where Ns is the number of design dimensions achieved by a proposed architecture and
Na is the total number of dimensions in the design space
...

Contribution analysis “identifies the reasons that one set of design choices gets
a lower score than another” [ASA96]
...

The design might be optimal, but constraints, costs, or other factors will not allow it to be built
...
A set of “realization mechanisms” (features of the architecture) are identified
...
The cells of the
matrix indicate the relative strength of the relationship (on a numeric scale of 1
to 10) between a realization mechanism and a requirement for each alternative
architecture
...
The QDS
is relatively easy to implement as a spreadsheet model and can be used to isolate why one set of design choices gets a lower score than another
...
4
...
These dependencies are driven by information/control ﬂow within the system
...
For example, for two
components u and v, if u and v refer to the same global data, then there exists a shared
dependence relationship between u and v
...
For example, for two components u and v, if u must complete before
control ﬂows into v (prerequisite), or if u communicates with v by parameters, then there
exists a ﬂow dependence relationship between u and v
...
For example, for two components u and v, u and v cannot execute at the
same time (mutual exclusion), then there exists a constrained dependence relationship
between u and v
...
Simple metrics for evaluating these
dependencies are discussed in Chapter 19
...
5

M A P P I N G R E Q U I R E M E N T S I N T O A S O F T WA R E
ARCHITECTURE
In Chapter 13 we noted that software requirements can be mapped into various representations of the design model
...
3
...
In fact, there is no practical
mapping for some architectural styles, and the designer must approach the translation of requirements to design for these styles in an ad hoc fashion
...
6 The mapping technique to be presented enables a designer to derive reasonably complex call
and return architectures from data ﬂow diagrams within the requirements model
...
Stevens, Myers, and Constantine [STE74] were early
proponents of software design based on the ﬂow of data through a system
...

Structured design is often characterized as a data ﬂow-oriented design method

?

What steps
should we
follow to map
DFDs into a call
and return
architecture?

because it provides a convenient transition from a data flow diagram to software
architecture
...

The type of information ﬂow is the driver for the mapping approach required in
step 3
...

14
...
1 Transform Flow
Recalling the fundamental system model (level 0 data flow diagram), information
XRef
Data ﬂow diagrams are
discussed in detail in
Chapter 12
...
For example, data typed
on a keyboard, tones on a telephone line, and video images in a multimedia application are all forms of external world information
...
Information enters the system along
paths that transform external data into an internal form
...
At the kernel of the software, a transition occurs
...
Data moving along these paths are called outgoing ﬂow
...
8 When a segment of a data ﬂow diagram exhibits these characteristics,
transform ﬂow is present
...
For example, the architecture of one
or more components of a client/server architecture might be call and return
...
g
...

An obvious mapping for this type of information ﬂow is the data ﬂow architecture described in Section 14
...
1
...
Examples include systems that will undergo substantial change over
time or systems in which the processing associated with the data ﬂow is not necessarily sequential
...
4
Transaction
ﬂow
Transaction
Action
paths
Transaction
center

T

14
...
2 Transaction Flow
The fundamental system model implies transform ﬂow; therefore, it is possible to characterize all data ﬂow in this category
...
When a DFD takes the form shown in Figure 14
...

Transaction ﬂow is characterized by data moving along an incoming path that converts external world information into a transaction
...
The hub of information ﬂow from which many action paths emanate is called a transaction center
...
For example, in a transaction-oriented ﬂow, information
ﬂow along an action path may have transform ﬂow characteristics
...
6

TRANSFORM MAPPING
Transform mapping is a set of design steps that allows a DFD with transform flow
characteristics to be mapped into a speciﬁc architectural style
...

14
...
1 An Example
The SafeHome security system, introduced earlier in this book, is representative of
many computer-based products and systems in use today
...
It also interacts with a user through

CHAPTER 14

F I G U R E 14
...
The level 0 data ﬂow diagram for
SafeHome, reproduced from Chapter 12, is shown in Figure 14
...

During requirements analysis, more detailed flow models would be created for
SafeHome
...

14
...
2 Design Steps
The preceding example will be used to illustrate each step in transform mapping
...

Step 1
...
The fundamental system model
encompasses the level 0 DFD and supporting information
...
Both documents describe information ﬂow and structure
at the software interface
...
5 and 14
...

Step 2
...
Information
obtained from analysis models contained in the Software Requirements Speciﬁcation
is reﬁned to produce greater detail
...

(Figure 14
...
8
...
That is, the process implied by a transform performs a single,
distinct function that can be implemented as a module9 in the SafeHome software
...
8 contains sufﬁcient detail for a "ﬁrst cut" at the design
of architecture for the monitor sensors subsystem, and we proceed without further
reﬁnement
...

382
F I G U R E 14
...

Display
messages
and status

Valid ID msg
...
Determine whether the DFD has transform or transaction ﬂow characteristics
...
However, when an obvious transaction characteristic (Figure 14
...

The ﬂows are
partitioned and
program structure is
derived using the
appropriate mapping
...
In this step, the designer
selects global (softwarewide) ﬂow characteristics based on the prevailing nature of
the DFD
...
These
subﬂows can be used to reﬁne program architecture derived from a global characteristic described previously
...
8
...
8), we see data entering the software along one
incoming path and exiting along three outgoing paths
...
Therefore, an overall transform characteristic will be assumed for
information ﬂow
...
7
Level 2 DFD
that reﬁnes the
monitor sensors
process

Sensor ID
type,
location

Assess
against
setup

Sensor
information

Generate
alarm
signal

Alarm
type

Alarm
data
Telephone
number

Sensor ID,
type

Sensor
status

Dial
phone

Telephone
number tones

Step 4
...
In the preceding section incoming ﬂow was described as a path

Vary the location of
ﬂow boundaries in an
effort to explore
alternative program
structures
...

in which information is converted from external to internal form; outgoing ﬂow converts from internal to external form
...
That is, different designers may select slightly different points in the
flow as boundary locations
...
Although care should be taken when boundaries are selected, a variance of one bubble along a ﬂow path will generally have little impact on the ﬁnal program structure
...
8
...
An argument can be made to readjust a boundary (e
...
The
emphasis in this design step should be on selecting reasonable boundaries, rather
than lengthy iteration on placement of divisions
...
8 Level 3 DFD for monitor sensors with ﬂow boundaries

CHAPTER 14

385

ARCHITECTURAL DESIGN

F I G U R E 14
...
Perform "ﬁrst-level factoring
...
Factoring results in a program structure in which top-level

Don’t become
dogmatic at this stage
...
If
common sense
dictates this approach,
do it!

modules perform decision making and low-level modules perform most input, computation, and output work
...

When transform ﬂow is encountered, a DFD is mapped to a speciﬁc structure (a
call and return architecture) that provides control for incoming, transform, and outgoing information processing
...
9
...

•

A transform ﬂow controller, called alarm conditions controller, supervises all
operations on data in internalized form (e
...
, a module that invokes various
data transformation procedures)
...

Although a three-pronged structure is implied by Figure 14
...
The number of modules at the ﬁrst level should
be limited to the minimum that can accomplish control functions and still maintain
good coupling and cohesion characteristics
...
Perform "second-level factoring
...
Beginning at the transform center boundary and moving outward
along incoming and then outgoing paths, transforms are mapped into subordinate
levels of the software structure
...
10
...
10 illustrates a one-to-one mapping between DFD transforms

Keep “worker”
modules low in the
program structure
...

and software modules, different mappings frequently occur
...
Practical considerations and measures of design quality dictate the outcome of secondlevel factoring
...

Second-level factoring for incoming ﬂow follows in the same manner
...
The transform center of monitor sensors subsystem software is
mapped somewhat differently
...
A completed ﬁrst-iteration architecture is shown in Figure 14
...

The modules mapped in the preceding manner and shown in Figure 14
...
That
is, if a control module
does nothing except
control one other
module, its control
function should be
imploded at a higher
level
...
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
...

•

Information that is retained by a module, such as data stored in a local data
structure
...

•

A brief discussion of restrictions and special features (e
...
, ﬁle I/O, hardwaredependent characteristics, special timing requirements)
...
However, further reﬁnement and additions occur regularly during this period of design
...
10 Second-level factoring for monitor sensors

Set up
connection
to phone net

Generate
pulses to line

388
Monitor
sensors
executive

Sensor
input
controller

Acquire
response
info

Alarm
conditions
controller

Establish
alarm
conditions

Alarm
output
controller

Select
phone
number

Read
sensors

F I G U R E 14
...
Refine the first-iteration architecture using design heuristics for
improved software quality
...
Modules are exploded or
imploded to produce sensible factoring, good cohesion, minimal coupling, and most
important, a structure that can be implemented without difﬁculty, tested without confusion, and maintained without grief
...
High cohesion
and low coupling
should be your goal
...
4, as well as practical considerations and common sense
...
6) cannot be achieved
...

Many modiﬁcations can be made to the ﬁrst iteration architecture developed for
the SafeHome monitor sensors subsystem
...
The incoming controller can be removed because it is unnecessary when a
single incoming ﬂow path is to be managed
...
The substructure generated from the transform ﬂow can be imploded into the
module establish alarm conditions (which will now include the processing
implied by select phone number)
...

3
...

The reﬁned software structure for the monitor sensors subsystem is shown in Figure 14
...

The objective of the preceding seven steps is to develop an architectural representation of software
...
Modiﬁcations made at this time require
little additional work, yet can have a profound impact on software quality
...
" If code is the only
representation of software, the developer will have great difﬁculty evaluating or reﬁning at a global or holistic level and will, in fact, have difﬁculty "seeing the forest for
the trees
...
7

TRANSACTION MAPPING
In many software applications, a single data item triggers one or a number of information ﬂows that effect a function implied by the triggering data item
...
12
Reﬁned
program
structure for
monitor sensors

Monitor
sensors
executive

Acquire
response
info

Establish
alarm
conditions

Read
sensors

Alarm
output
controller

Produce
display

Generate
alarm
signal

Set up
connection
to phone net

Generate
pulses to line

called a transaction, and its corresponding ﬂow characteristics are discussed in Section 14
...
2
...

14
...
1 An Example
Transaction mapping will be illustrated by considering the user interaction subsystem
of the SafeHome software
...
6
...
13
...
A single data item, command type, causes the data ﬂow to fan outward from a hub
...

It should be noted that information ﬂow along two of the three action paths accommodate additional incoming ﬂow (e
...
, system parameters and data are input on the
"conﬁgure" action path)
...

14
...
2 Design Steps
The design steps for transaction mapping are similar and in some cases identical to
steps for transform mapping (Section 14
...
A major difference lies in the mapping
of DFD to software structure
...
13 Level 2 DFD for user interaction subsystem with ﬂow boundaries

Display
messages
and status

Produce
invalid
message

“Try again”
message

Display
information

392

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Step 1
...

Step 2
...

Step 3
...
Steps 1, 2, and 3 are identical to corresponding steps in transform mapping
...
13 has a classic transaction ﬂow characteristic
...
Therefore, flow
boundaries must be established for both ﬂow types
...
Identify the transaction center and the flow characteristics along
each of the action paths
...
The transaction center lies at the origin of a number
of actions paths that flow radially from it
...
13, the
invoke command processing bubble is the transaction center
...
e
...
Boundaries that deﬁne a reception path and
action paths are also shown in the ﬁgure
...
For example, the "password" path (shown enclosed by
a shaded area in Figure 14
...
Incoming, transform,
and outgoing ﬂow are indicated with boundaries
...
Map the DFD in a program structure amenable to transaction processing
...
The structure of the incoming branch is developed
in much the same way as transform mapping
...
The structure of the dispatch

First-level factoring
results in the derivation
of the control hierarchy
for the software
...

branch contains a dispatcher module that controls all subordinate action modules
...
This process is illustrated schematically in Figure 14
...

Considering the user interaction subsystem data flow, first-level factoring for
step 5 is shown in Figure 14
...
The bubbles read user command and activate/deactivate system map directly into the architecture without the need for intermediate control modules
...
Controllers for system conﬁguration and password processing are created as illustrated in Figure 14
...

Step 6
...
Each action path of the data ﬂow diagram has its own information ﬂow
characteristics
...
The action path-related "substructure" is developed using the design
steps discussed in this and the preceding section
...
13
...
A

CHAPTER 14

393

ARCHITECTURAL DESIGN

Transaction
control

F I G U R E 14
...
An alarm and warning message (outgoing ﬂow)
are produced (if a match is not obtained)
...
The resultant software architecture is shown in Figure 14
...

User
interaction
executive

Read
user
command
F I G U R E 14
...
16 First-iteration architecture for user interaction subsystem

Step 7
...
This step for transaction mapping is identical to the
corresponding step for transform mapping
...

14
...
After the program structure has been developed and reﬁned, the following tasks must be completed:

? What
happens
after the
architecture has
been created?

•

A processing narrative must be developed for each module
...

•

Local and global data structures are deﬁned
...

CHAPTER 14

ARCHITECTURAL DESIGN

•

A set of design reviews are conducted
...

A processing narrative is (ideally) an unambiguous, bounded description of processing that occurs within a module
...
The interface description describes the design of internal module
interfaces, external system interfaces, and the human/computer interface {Chapter 15)
...
Restrictions and/or limitations
for each module are also documented
...
The purpose of a restrictions and limitations section is to reduce
the number of errors introduced because of assumed functional characteristics
...
The review emphasizes traceability to software requirements, quality of the software architecture, interface descriptions, data structure descriptions, implementation and test practicality,
Software Design
Speciﬁcation

and maintainability
...
"
The software designer should be concerned with developing a representation of software that will meet all functional and performance requirements and merit acceptance based on design measures and heuristics
...
As we discussed earlier in this chapter, alternative architectural styles may be
derived, reﬁned, and evaluated for the "best" approach
...

It is important to note that structural simplicity often reﬂects both elegance and
efﬁciency
...

14
...
It depicts the
structure and organization of software components, their properties, and the connections between them
...
Therefore, data
design is an integral part of the derivation of the software architecture
...

Data design translates the data objects defined in the analysis model into data
structures that reside within the software
...
At a higher level of abstraction, data design may lead to
the deﬁnition of an architecture for a database or a data warehouse
...
Each style describes a system category that encompasses a set of
components that perform a function required by a system, a set of connectors that
enable communication, coordination and cooperation among components, constraints that deﬁne how components can be integrated to form the system, and semantic models that enable a designer to understand the overall properties of a system
...
This is accomplished by determining the sensitivity of selected quality
attributes (also called design dimensions) to various realization mechanisms that
reﬂect properties of the architecture
...
A data ﬂow diagram is mapped into program structure using one of two mapping approaches—transform mapping or transaction mapping
...
The DFD is mapped into a structure that allocates control to input,
processing, and output along three separately factored module hierarchies
...
The DFD is mapped into a structure that allocates control to a
substructure that acquires and evaluates a transaction
...

Once an architecture has been derived, it is elaborated and then analyzed against
quality criteria
...
In the chapters that follow, the design focus
shifts to interfaces and components
...
V
...
Hopcroft, and J
...

[ASA96] Asada, T
...
, "The Quantified Design Space," in Software Architecture
(Shaw, M
...
Garlan), Prentice-Hall, 1996, pp
...

[BAS98] Bass, L
...
Clements, and R
...

CHAPTER 14

ARCHITECTURAL DESIGN

397

[BUS96] Buschmann, F
...

[DAH72] Dah
...
, E
...
Hoare, Structured Programming, Academic Press,
1972
...
J
...
, Addison-Wesley,
1995
...
B
...
L
...
), Springer-Verlag, 1973, pp
...

[FRE80] Freeman, P
...

(P
...
Wasserman, eds
...
2–4
...
H
...
cait
...
edu/cait/papers/prism/vol1_no1
...
et al
...

[KIM98] Kimball, R
...
Reeves, M
...
Thornthwaite, The Data Warehouse
Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses, Wiley, 1998
...
C
...
D
...
I
...

[MAT96] Mattison, R
...

[MYE78] Myers, G
...

[PRE98] Preiss, B
...
, Data Structures and Algorithms: With Object-Oriented Design Patterns in C++, Wiley, 1998
...
and D
...

[SHA97] Shaw, M
...
Clements, “A Field Guide to Boxology: Preliminary Classiﬁcation of Architectural Styles for Software Systems,” Proc
...

[STE74] Stevens, W
...
Myers, and L
...
13, no
...
115–139
...
, "Principles of Systematic Data Design and Implementation," in Software Design Tehcniques (P
...
Wasserman, ed
...
,
IEEE Computer Society Press, 1980, pp
...

[WIR71] Wirth, N
...
14,
no
...
221–227
...
and L
...

[ZHA98] Zhao, J, “On Assessing the Complexity of Software Architectures,” Proc
...

Software Architecture Workshop, ACM, Orlando, FL, 1998, p
...

PROBLEMS AND POINTS TO PONDER
14
...
Using the architecture of a house or building as a metaphor, draw comparisons with software architecture
...
2
...
Begin by delineating the classical data
structures encountered in software work and then describe criteria for selecting from
these for particular types of problems
...
3
...

14
...
Write a three- to ﬁve-page paper that describes how data mining techniques
are used in a business context and the current state of KDD techniques
...
5
...
3
...

14
...
Some of the architectural styles noted in Section 14
...
1 are hierarchical in
nature and others are not
...
How would the architectural styles
that are not hierarchical be implemented?
14
...
Select an application with which you are familiar
...
3
...

14
...
Research the ATAM (using [KAZ98]) and present a detailed discussion of the
six steps presented in Section 14
...
1
...
9
...
Using best guesses where
required, identify a set of design dimensions and then perform spectrum analysis and
design selection analysis
...
10
...

14
...
Some designers contend that all data ﬂow may be treated as transform oriented
...
Use an example flow to
illustrate important points
...
12
...
13
...

14
...
Using a data ﬂow diagram and a processing narrative, describe a computerbased system that has distinct transform ﬂow characteristics
...
6
...
14
...
Deﬁne ﬂow boundaries
and map the DFD into a software structure using the technique described in Section 14
...

14
...
Using requirements that are derived from a classroom discussion, complete
the DFDs and architectural design for the SafeHome example presented in Sections

CHAPTER 14

ARCHITECTURAL DESIGN

399

14
...
7
...
Document your
design
...
16
...

14
...
Given a set of requirements provided by your instructor (or a set of requirements for a problem on which you are currently working) develop a complete architectural design
...
This problem may be assigned to a team, rather than an individual
...
Books by
Shaw and Garlan [SHA96], Bass, Clements, and Kazman [BAS98] and Buschmann
et al
...
Earlier work by Garlan (An
Introduction to Software Architecture, Software Engineering Institute, CMU/SEI-94TR-021, 1994) provides an excellent introduction
...
Mowbray (CORBA Design Patterns,
Wiley, 1997) and Mark et al
...
Shanley (Protected Mode Software Architecture, Addison-Wesley, 1996) provides
architectural design guidance for anyone designing PC-based real-time operating systems, multi-task operating systems, or device drivers
...

Data modeling is a prerequisite to good data design
...
The design of data warehouses has become increasingly important in

400

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

recent years
...
[KIM98]; and Inmon [INM95]
cover the topic in considerable detail
...
Typical examples are
Horowitz, E
...
Sahni, Fundamentals of Data Structures in Pascal, 4th ed
...
H
...
, 1999
...
H
...
,
Addison-Wesley, 1997
...
, Data Structures and Other Objects Using Java, Addison-Wesley, 1998
...
R
...

Sedgewick, R
...

Standish, T
...
, Data Structures in Java, Addison-Wesley, 1997
...
A
...

General treatment of software design with discussion of architectural and data
design issues can be found in most books dedicated to software engineering
...
, Addison-Wesley,1996) are representative of
those that cover design issues in some detail
...
(Software Architecture and Design Principles, Thomson Publishing, 1994), and Budgen (Software Design, Addison-Wesley,
1994)
...
,
Prentice-Hall, 1988)
...

A wide variety of information sources on software design and related subjects is
available on the Internet
...
mhhe
...
mhtml

CHAPTER

15

USER INTERFACE DESIGN

response time
...
The “doors, windows, and utility connections” for computer software make up the interface
design of a system
...
e
...
e
...
In this chapter we focus exclusively on the
third interface design category—user interface design
...
411

Frustration and anxiety are part of daily life for many users of computerized infor-

user types
...
They struggle to learn command language or menu selection sys-

variability
...
Some people encounter such serious

KEY
CONCEPTS
actions
...
405
error processing
...
402
help facility
...
406
design process
...
404

T

cases of computer shock, terminal terror, or network neurosis that they avoid using
computerized systems
...

tion medium between a human

What are the steps? User interface design begins

and a computer
...
Once user tasks have been

and actions and then creates a screen layout that

identified, user scenarios are created and ana-

forms the basis for a user interface prototype
...
These form the basis for the creation of

interface by applying an iterative process that

screen layout that depicts graphical design and

draws on predeﬁned design principles
...

efforts to accomplish your goals, you won’t like it,

Tools are used to prototype and ultimately imple-

regardless of the computational power it exhibits

ment the design model, and the result is evalu-

or the functionality it offers
...

401

402

PA R T T H R E E

QUICK
LOOK

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

What is the work product? User

How do I ensure that I’ve done it right? The prototype

scenarios are created and screen

is “test driven” by the users and feedback from the

layouts are generated
...

iterative fashion
...
It is true that graphical
user interfaces, windows, icons, and mouse picks have eliminated many of the
most horrific interface problems
...
Yet, someone spent time and
energy building each of these interfaces, and it is not likely that the builder created these problems purposely
...
Who is the user? How does the user learn to interact with
a new computer-based system? How does the user interpret information produced by the system? What will the user expect of the system? These are only a
few of the many questions that must be asked and answered as part of user interface design
...
1

THE GOLDEN RULES
In his book on interface design, Theo Mandel [MAN97] coins three “golden rules”:
1
...

2
...

3
...

These golden rules actually form the basis for a set of user interface design principles that guide this important software design activity
...
1
...

“What I really would like,” said the user solemnly, “is a system that reads my mind
...
That’s all, just that
...

There was absolutely nothing wrong with the user’s request
...
She wanted to control the
computer, not have the computer control her
...
But for whom? In many cases, the
designer might introduce constraints and limitations to simplify the implementation
of the interface
...

Mandel [MAN97] deﬁnes a number of design principles that allow the user to maintain control:

? How do we
design
interfaces that
allow the user to
maintain control?

Define interaction modes in a way that does not force a user into unnecessary or undesired actions
...
For example, if spell check is selected in a word-processor menu, the
software moves to a spell checking mode
...
The user should be able to enter and exit the mode with little or
no effort
...
Because different users have different interaction
preferences, choices should be provided
...
But every action is not amenable to every interaction mechanism
...

Allow user interaction to be interruptible and undoable
...
”
Douglas Adams

something else (without losing the work that had been done)
...

Streamline interaction as skill levels advance and allow the interaction to
be customized
...
It is worthwhile to design a “macro” mechanism that enables an
advanced user to customize the interface to facilitate interaction
...
The user interface should move
the user into the virtual world of the application
...
In essence, the interface should never require that the user interact at a level
that is “inside” the machine (e
...
, a user should never be required to type operating
system commands from within application software)
...
The user
feels a sense of control when able to manipulate the objects that are necessary to
perform a task in a manner similar to what would occur if the object were a physical thing
...

404

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

15
...
2 Reduce the User’s Memory Load
The more a user has to remember, the more error-prone will be the interaction with
the system
...
Whenever possible, the system should “remember” pertinent information and assist the user with an interaction scenario that assists recall
...
When users are involved in com-

interfaces that
reduce the user’s
memory load?

should be designed to reduce the requirement to remember past actions and

plex tasks, the demand on short-term memory can be signiﬁcant
...
This can be accomplished by providing visual cues that enable a user to
recognize past actions, rather than having to recall them
...
The initial set of defaults should make sense
for the average user, but a user should be able to specify individual preferences
...

Deﬁne shortcuts that are intuitive
...
g
...
g
...

The visual layout of the interface should be based on a real world

“The interface from
hell: ‘Enter any 11digit prime number
to continue
...
For example, a bill payment system should use a check book and
check register metaphor to guide the user through the bill paying process
...

Disclose information in a progressive fashion
...
That is, information about a task, an object, or some behavior should be presented ﬁrst at a high level of abstraction
...
An example, common to many word-processing applications, is the underlining function
...
However,
every underlining capability is not listed
...
g
...

15
...
3 Make the Interface Consistent
The interface should present and acquire information in a consistent fashion
...
Mandel [MAN97] deﬁnes a set of design principles that help make the interface consistent:

? How do we
design
interfaces that are
consistent?

Allow the user to put the current task into a meaningful context
...

It is important to provide indicators (e
...
, window titles, graphical icons, consistent color coding) that enable the user to know the context of the work at hand
...

Maintain consistency across a family of applications
...

If past interactive models have created user expectations, do not make
changes unless there is a compelling reason to do so
...
g
...
A change
(e
...
, using alt-S to invoke scaling) will cause confusion
...
In the sections that follow, we examine the interface design process itself
...
2

U S E R I N T E R FA C E D E S I G N
The overall process for designing a user interface begins with the creation of different models of system function (as perceived from the outside)
...

15
...
1 Interface Design Models
Four different models come into play when a user interface is to be designed
...
ibm
...
Unfortunately, each of these models may differ signiﬁcantly
...

A design model of the entire system incorporates data, architectural, interface,
and procedural representations of the software
...
1
The user model establishes the proﬁle of end-users of the system
...
In addition, users can
be categorized as
•

Novices
...

“USER, n
...
' “

•

Knowledgeable, intermittent users
...

•

Dave Barry

Knowledgeable, frequent users
...

The system perception (user's model) is the image of the system that end-users
carry in their heads
...
The
accuracy of the description will depend upon the user's proﬁle (e
...
, novices would
provide a sketchy response at best) and overall familiarity with software in the application domain
...

The system image combines the outward manifestation of the computer-based
system (the look and feel of the interface), coupled with all supporting information
(books, manuals, videotapes, help ﬁles) that describe system syntax and semantics
...

When the system image and the system perception are coincident, users generally
feel comfortable with the software and use it effectively
...

The models described in this section are "abstractions of what the user is doing
or thinks he is doing or what somebody else thinks he ought to be doing when he

1
2
3

Of course, this is not as it should be
...

In this context, syntactic knowledge refers to the mechanics of interaction that is required to use
the interface effectively
...

CHAPTER 15

F I G U R E 15
...
In essence, these models enable the interface
designer to satisfy a key element of the most important principle of user interface
design: "Know the user, know the tasks
...
2
...
Referring to Figure 15
...
User, task, and environment analysis and modeling
2
...
Interface construction
4
...
1 implies that each of these tasks will occur more than
once, with each pass around the spiral representing additional elaboration of requirements and the resultant design
...

The initial analysis activity focuses on the profile of the users who will interact

“I never design a
building before I've
seen the site and
met the people who
will be using it
...
Skill level, business understanding, and general receptiveness to the
new system are recorded; and different user categories are defined
...
In essence, the software engineer attempts to
understand the system perception (Section 15
...
1) for each class of users
...
Those tasks that the user performs to accomplish the goals of the system
are identiﬁed, described, and elaborated (over a number of iterative passes through
the spiral)
...
3
...

Among the questions to be asked are
•

Where will the interface be located physically?

•

Will the user be sitting, standing, or performing other tasks unrelated to the
interface?

•

Does the interface hardware accommodate space, light, or noise constraints?

•

Are there special human factors considerations driven by environmental factors?

The information gathered as part of the analysis activity is used to create an analysis model for the interface
...

The goal of interface design is to deﬁne a set of interface objects and actions (and

the
? Whatofisuser
goal

their screen representations) that enable a user to perform all deﬁned tasks in a man-

interface design?

ner that meets every usability goal defined for the system
...
4
...
As the iterative design process continues,
a user interface tool kit (Section 15
...

Validation focuses on (1) the ability of the interface to implement every user task
correctly, to accommodate all task variations, and to achieve all general user requirements; (2) the degree to which the interface is easy to use and easy to learn; and (3)
the users’ acceptance of the interface as a useful tool in their work
...

Therefore, there is no need to attempt to specify every detail (for the analysis or design
model) on the ﬁrst pass
...

15
...
Later in this book, we consider object-oriented analysis as a modeling
approach for computer-based systems
...

Task analysis can be applied in two ways
...
To understand the tasks that must be performed to accomplish the goal of the

CHAPTER 15

U S E R I N T E R FA C E D E S I G N

409

activity, a human engineer4 must understand the tasks that humans currently perform (when using a manual approach) and then map these into a similar (but not
necessarily identical) set of tasks that are implemented in the context of the user
interface
...

Regardless of the overall approach to task analysis, a human engineer must ﬁrst
deﬁne and classify tasks
...
For example, assume that a small software company wants to build a

Human tasks are
deﬁned and classiﬁed
as part of task
analysis
...

Alternatively, objects
and actions are
identiﬁed and reﬁned
...
By observing an interior designer at work, the engineer notices that interior design comprises a number
of major activities: furniture layout, fabric and material selection, wall and window
coverings selection, presentation (to the customer), costing, and shopping
...
For example, furniture layout can
be reﬁned into the following tasks: (1) draw a ﬂoor plan based on room dimensions;
(2) place windows and doors at appropriate locations; (3) use furniture templates to
draw scaled furniture outlines on ﬂoor plan; (4) move furniture outlines to get best
placement; (5) label all furniture outlines; (6) draw dimensions to show location; (7)
draw perspective view for customer
...

Subtasks 1–7 can each be reﬁned further
...
On the other
hand, subtask 7 can be performed automatically in software and will result in little
direct user interaction
...

XRef
Object-oriented analysis
techniques can be
applied during task
analysis
...

An alternative approach to task analysis takes an object-oriented point of view
...
For example, the furniture template would be an object in this approach to task analysis
...
The design model for the interface
would not provide a literal implementation for each of these actions, but it would
define user tasks that accomplish the end result (drawing furniture outlines on the
floor plan)
...
Ideally, the individual has had some training in human engineering and user interface design
...
4

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

I N T E R FA C E D E S I G N A C T I V I T I E S
Once task analysis has been completed, all tasks (or objects and actions) required by
the end-user have been identified in detail and the interface design activity commences
...
Establish the goals5 and intentions for each task
...
Map each goal and intention to a sequence of speciﬁc actions
...
Specify the action sequence of tasks and subtasks, also called a user scenario,
as it will be executed at the interface level
...
Indicate the state of the system; that is, what does the interface look like at
the time that a user scenario is performed?
5
...

6
...

7
...

Always following the golden rules discussed in Section 15
...
g
...

15
...
1 Deﬁning Interface Objects and Actions
XRef
A complete discussion
of the grammatical
parse can be found in
Section 12
...
2
...
To accomplish this, the user scenario is parsed in
much the same way as processing narratives were parsed in Chapter 12
...
Nouns (objects) and verbs (actions) are isolated to create a list of objects and actions
...
Target, source, and application objects are identiﬁed
...
g
...
g
...
The implication of this action is to create a hard-copy report
...
For example, a mailing list is used to store names for a mailing
...

5

Goals include a consideration of the usefulness of the task, its effectiveness in accomplishing the
overriding business objective, the degree to which the task can be learned quickly, and the degree
to which users will be satisﬁed with the ultimate implementation of the task
...
Like other interface
design activities, screen layout is an interactive process in which graphical design
and placement of icons, deﬁnition of descriptive screen text, speciﬁcation and titling
for windows, and deﬁnition of major and minor menu items is conducted
...

To provide a brief illustration of the design steps noted previously, we consider a
user scenario for an advanced version of the SafeHome system (discussed in earlier
chapters)
...
A PC application allows the homeowner to check the status of the house

XRef
The scenario described
here is similar to usecases described in
Chapter 11
...
A preliminary user scenario for the interface follows:
Scenario: The homeowner wishes to gain access to the SafeHome system installed in his
house
...
g
...

To access SafeHome from a remote location, the homeowner provides an identiﬁer and
a password
...
g
...
Once validated, the user (with full access privileges) checks
the status of the system and changes status by arming or disarming SafeHome
...

The user views the interior of the house via strategically placed video cameras
...

Homeowner tasks:
•

accesses the SafeHome system

•

enters an ID and password to allow remote access

•

checks system status

•

arms or disarms SafeHome system

•

displays ﬂoor plan and sensor locations

•

displays zones on ﬂoor plan

•

changes zones on ﬂoor plan

•

displays video camera locations on ﬂoor plan

•

selects video camera for viewing

•

views video images (4 frames per second)

•

pans or zooms the video camera

6

The video option enables the homeowner to place video cameras at key locations throughout a
house and peruse the output from a remote location
...

The majority of objects noted are application objects
...

A preliminary sketch of the screen layout for video monitoring is created (Figure
15
...
To invoke the video image, a video camera location icon, C, located in ﬂoor
plan displayed in the monitoring window is selected
...
The video image window appears, displaying streaming video from the camera located in the living room (LR)
...
To select a view from another camera, the user simply drags and drops a different camera location icon into the camera icon in the upper left-hand corner of
the screen
...
2 Preliminary screen layout

S
Video Image—LR

CHAPTER 15

U S E R I N T E R FA C E D E S I G N

413

video monitoring mode (state)
...

15
...
2 Design Issues
As the design of a user interface evolves, four common design issues almost always surface: system response time, user help facilities, error information handling, and command labeling
...
Unnecessary iteration, project delays, and customer frustration often result
...

System response time is the primary complaint for many interactive applications
...
g
...

System response time has two important characteristics: length and variability
...
However, a very brief response time can also be detrimental if the user is being
paced by the interface
...

If variable response is
unavoidable, be
certain to provide
some visual indication
of progress, so that
the user is aware of
what is happening
...
Low variability enables the user
to establish an interaction rhythm, even if response time is relatively long
...
1 to 2
...
The user is always off balance, always wondering whether something "different" has occurred behind the scenes
...
In some cases, a simple question addressed to a knowledgeable colleague
can do the trick
...
In many cases, however, modern software provides on-line
help facilities that enable a user to get a question answered or resolve a problem
without leaving the interface
...
An integrated help facility is designed into the software from the beginning
...
Obviously, this reduces the time
required for the user to obtain help and increases the "friendliness" of the interface
...
In
many ways, it is really an on-line user's manual with limited query capability
...

There is little doubt that the integrated help facility is preferable to the add-on approach
...

•

How will the user request help? Options include a help menu, a special function key, or a HELP command
...

•

How will the user return to normal interaction? Options include a return button displayed on the screen, a function key, or control sequence
...

Error messages and warnings are "bad news" delivered to users of interactive systems when something has gone awry
...

There are few computer users who have not encountered an error of the form:

Spend twice as much
effort and expend
twice as many words
on troubleshooting as
you think you’ll need
for your help facility,
and you’ll probably get
it about right
...
An error message presented
in this manner does nothing to assuage user anxiety or to help correct the problem
...

•

The message should provide constructive advice for recovering from the error
...
g
...

•

The message should be accompanied by an audible or visual cue
...
"

•

The message should be "nonjudgmental
...

CHAPTER 15

U S E R I N T E R FA C E D E S I G N

415

Because no one really likes bad news, few users will like an error message no matter how well designed
...

The typed command was once the most common mode of interaction between
user and system software and was commonly used for applications of every type
...
A number of design issues arise when typed commands are provided as a mode of interaction:
•
•

Will every menu option have a corresponding command?
What form will commands take? Options include a control sequence (e
...
,
alt-P), function keys, or a typed word
...
It is confusing and often error-prone for a user to type
alt-D when a graphics object is to be duplicated in one application and alt-D when a
graphics object is to be deleted in another
...

15
...
To
accommodate this iterative design approach, a broad class of interface design and
prototyping tools has evolved
...

Using prepackaged software components to create a user interface, a UIDS provides built-in mechanisms [MYE89] for
•
•

handling errors and displaying error messages

•

providing feedback (e
...
, automatic input echo)

•
7

validating user input

•

CASE Tools
User Interface Design

managing input devices (such as a mouse or keyboard)

providing help and prompts

It should be noted that in some cases (e
...
, aircraft cockpit displays) the ﬁrst step might be to simulate the interface on a display device rather than prototyping it
...

15
...
Evaluation can span a formality spectrum that ranges from an informal "test drive," in which a user provides
impromptu feedback to a formally designed study that uses statistical methods for
the evaluation of questionnaires completed by a population of end-users
...
3
...
The prototype is
evaluated by the user, who provides the designer with direct comments about the
efﬁcacy of the interface
...
g
...
3
The interface
design
evaluation
cycle

Preliminary
design

Build
prototype #1
interface
Build
prototype #n
interface

User
evaluates
interface

Design
modifications
are made

Interface design
is complete

Evaluation
is studied by
designer

CHAPTER 15

U S E R I N T E R FA C E D E S I G N

417

(e
...
, 80 percent of all users did not like the mechanism for saving data ﬁles)
...
It is an interface
where the mind and
body can connect
with the universe
and move bits of
it about
...

The evaluation cycle continues until no further modiﬁcations to the interface design
are necessary
...
If a design model of the interface has been created, a
number of evaluation criteria [MOR81] can be applied during early design reviews:
1
...

2
...

3
...

4
...

Once the ﬁrst prototype is built, the designer can collect a variety of qualitative
and quantitative data that will assist in evaluating the interface
...
Questions can
be all (1) simple yes/no response, (2) numeric response, (3) scaled (subjective)
response, or (4) percentage (subjective) response
...
Were the icons self-explanatory? If not, which icons were unclear?
2
...
How many different actions did you use?
4
...
Compared to other interfaces you've used, how would this rate—top 1%, top
10%, top 25%, top 50%, bottom 50%?
If quantitative data are desired, a form of time study analysis can be conducted
...

A complete discussion of user interface evaluation methods is beyond the scope
of this book
...

418

PA R T T H R E E

15
...
If the interface is poorly designed, the user’s ability to tap the computational power of an application may be severely hindered
...

Three important principles guide the design of effective user interfaces: (1) place
the user in control, (2) reduce the user’s memory load, and (3) make the interface
consistent
...

User interface design begins with the identification of user, task, and environmental requirements
...

Once tasks have been identiﬁed, user scenarios are created and analyzed to deﬁne
a set of interface objects and actions
...
Design issues such as response time, command and action structure,
error handling, and help facilities are considered as the design model is reﬁned
...

The user interface is the window into the software
...
If the “window” is smudged,
wavy, or broken, the user may reject an otherwise powerful computer-based system
...
, "Evaluating User Interface Designs," User Interface Design for Computer Systems, Halstead Press (Wiley), 1988
...
, The Elements of User Interface Design, Wiley, 1997
...
(ed
...

[MOR81] Moran, T
...
, "The Command Language Grammar: A Representation for the
User Interface of Interactive Computer Systems," Intl
...
15, pp
...

[MYE89] Myers, B
...
, "User Interface Tools: Introduction and Survey, IEEE Software,
January 1989, pp
...

[NOR86] Norman, D
...
, "Cognitive Engineering," in User Centered Systems Design,
Lawrence Earlbaum Associates, 1986
...
, User Interface Design for Computer Systems, Halstead Press (Wiley),
1988
...
, Designing the User Interface, 3rd ed
...

CHAPTER 15

U S E R I N T E R FA C E D E S I G N

419

PROBLEMS AND POINTS TO PONDER
15
...
Describe the worst interface that you have ever worked with and critique it
relative to the concepts introduced in this chapter
...

15
...
Develop two additional design principles that “place the user in control
...
3
...
”
15
...
Develop two additional design principles that “make the interface consistent
...
5
...
A desktop publishing system
...
A computer-aided design system
...
An interior design system (as described in Section 15
...
2)
...
An automated course registration system for a university
...
A library management system
...
An Internet-based polling booth for public elections
...
A home banking system
...
An interactive application assigned by your instructor
...

15
...
Perform a detailed task analysis for any one of the systems listed in Problem
15
...
Use either an elaborative or object-oriented approach
...
7
...
6, deﬁne interface objects and actions for the application you have chosen
...

15
...
Develop a set of screen layouts with a definition of major and minor menu
items for the system you chose in Problem 15
...

15
...
Develop a set of screen layouts with a definition of major and minor menu
items for the advanced SafeHome system described in Section 15
...
1
...
2
...
10
...
5 through 15
...

15
...
Provide a few examples that illustrate why response time variability can be
an issue
...
12
...
That is, the system would automatically recognize the error type

420

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

and provide a help window with suggestions for correcting it
...

15
...
Develop an interface evaluation questionnaire that contains 20 generic questions that would apply to most interfaces
...
Summarize the results and report
them to your class
...
It is recommended reading for anyone who is serious about doing high-quality
interface design
...

However, books by Mandel [MAN97] and Shneiderman [SHN90] continue to provide
the most comprehensive (and readable) treatments of the subject
...

Task analysis and modeling are pivotal interface design activities
...
Wood (User Interface Design: Bridging the Gap from User Requirements to Design,
CRC Press, 1997) considers the analysis activity for interfaces and the transition
to design tasks
...
A formal method for design of
user interfaces, based on state-based behavior modeling has been developed by Horrocks (Constructing the User Interface with Statecharts, Addison-Wesley, 1998)
...
Books by Rubin (Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests, Wiley, 1994) and Nielson
(Usability Inspection Methods, Wiley, 1994) address the topic in considerable detail
...

The Apple staff (MacIntosh Human Interface Guidelines, Addison-Wesley, 1993) dis-

CHAPTER 15

U S E R I N T E R FA C E D E S I G N

421

cusses the now famous (and much copied) Macintosh look and feel
...

In a unique book that may be of considerable interest to product designers, Murphy (Front Panel: Designing Software for Embedded User Interfaces, R&D Books, 1998)
provides detailed guidance for the design of interfaces for embedded systems and
addresses safety hazards inherent in controls, handling heavy machinery, and interfaces for medical or transport systems
...

A wide variety of information sources on user interface design and related subjects is available on the Internet
...
mhhe
...
mhtml

CHAPTER

16
KEY
CONCEPTS
box diagram
...
425
decision table
...
432
graphical
notation
...
The intent
is to translate the design model into operational software
...
The translation can be challenging, opening the door to the introduction of subtle errors that are difﬁcult to ﬁnd
and correct in later stages of the software process
...
429

Software seems to be different from many other products, where as a rule higher

repetition
construct
...
425

...
424

with
...
424

quality implies a higher price
...
effective programmers

Although these words were spoken many years ago, they remain true today
...
”

What is it? Data, architectural,

build it
...
To accomplish this, the design must be rep-

sistency with earlier design representations (i
...
,

resented at a level of abstraction that is close to

the data, architectural, and interface designs)
...
Component-level design establishes the

provides a means for assessing whether data struc-

QUICK
LOOK

algorithmic detail required to manipulate data

tures, interfaces, and algorithms will work
...
The processing nar-

component
...

Why is it important? You have to be able to determine whether the program will work before you

cedural design model using a set of structured
programming constructs
...

423

424

PA R T T H R E E

QUICK
LOOK

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

What is the work product? The

design is examined to determine whether data

procedural design for each com-

structures, interfaces, processing sequences, and

ponent, represented in graphical,

logical conditions are correct and will produce the

tabular, or text-based notation, is the primary work

appropriate data or control transformation allo-

product produced during component-level design
...

walkthrough or inspection is conducted
...
In essence, the program is created using the design model as a guide
...
g
...
Regardless of the mechanism that is used to represent the componentlevel design, the data structures, interfaces, and algorithms deﬁned should conform
to a variety of well-established procedural design guidelines that help us to avoid
errors as the procedural design evolves
...

16
...

“When I'm working
on a problem, I
never think about
beauty
...
But when I
have ﬁnished, if the
solution is not
beautiful, I know it
is wrong
...
Buckminster
Fuller

In the late 1960s, Dijkstra and others proposed the use of a set of constrained logical constructs from which any program could be formed
...
" That is, each construct had a predictable logical structure, was entered at the top and exited at the bottom, enabling a reader to
follow procedural ﬂow more easily
...
Sequence implements processing steps that are essential in the speciﬁcation of any algorithm
...
These three constructs are fundamental to structured
programming—an important component-level design technique
...
Complexity metrics (Chapter 19)
indicate that the use of the structured constructs reduces program complexity and
thereby enhances readability, testability, and maintainability
...
To understand this process, consider the way in which
you are reading this page
...
The structured constructs are

CHAPTER 16

425

C O M P O N E N T- L E V E L D E S I G N

F I G U R E 16
...
Understanding is enhanced when

Structured
programming provides
a designer with useful
logical patterns
...

Any program, regardless of application area or technical complexity, can be
designed and implemented using only the three structured constructs
...
Section 16
...
1 considers this issue in further detail
...
1
...
There is no question that graphical tools, such as the
ﬂowchart or box diagram, provide useful pictorial patterns that readily depict procedural detail
...

A ﬂowchart is quite simple pictorially
...

A diamond represents a logical condition, and arrows show the ﬂow of control
...
1 illustrates three structured constructs
...
Condition, also called ifthen-else, is depicted as a decision diamond that if true, causes then-part processing
to occur, and if false, invokes else-part processing
...
The do while tests a condition and executes a loop task
repetitively as long as the condition holds true
...
The selection (or select-case) construct shown in the figure is actually an extension of the

426
F I G U R E 16
...
A parameter is tested by successive decisions until a true condition occurs
and a case part processing path is executed
...

If using them without
“violation” results in
unnecessary
complexity, it’s
OK to violate
...
2
...
Another if-then-else forms the else part of
the larger condition
...

By nesting constructs in this manner, a complex logical schema may be developed
...
2 could reference another module, thereby accomplishing procedural layering implied by program structure
...

More important, additional complication of all logical tests along the path of escape
can cloud software control ﬂow, increase the possibility of error, and have a negative impact on readability and maintainability
...
In general, use
them to document or
evaluate design in
speciﬁc instances, not
to represent an entire
system
...
Option 1 is obviously the ideal
approach, but option 2 can be accommodated without violating of the spirit of structured programming
...
Developed by Nassi and Shneiderman [NAS73] and extended by Chapin
[CHA74], the diagrams (also called Nassi-Shneiderman charts, N-S charts, or Chapin
charts) have the following characteristics: (1) functional domain (that is, the scope of

CHAPTER 16

427

C O M P O N E N T- L E V E L D E S I G N

F I G U R E 16
...

The graphical representation of structured constructs using the box diagram is
illustrated in Figure 16
...
The fundamental element of the diagram is a box
...
To represent if-then-else,
a condition box is followed by a then-part and else-part box
...
Finally, selection is represented using the graphical form shown at
the bottom of the ﬁgure
...
A "call" to a subordinate module can be represented
within a box by specifying the module name enclosed by an oval
...
1
...

In many software applications, a module may be required to evaluate a complex combination of conditions and select appropriate actions based on these conditions
...
The table is difﬁcult to misinterpret and may

428

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

even be used as a machine readable input to a table driven algorithm
...
Decision tables are an excellent example
...

Decision table organization is illustrated in Figure 16
...
Referring to the ﬁgure, the
table is divided into four sections
...
The lower left-hand quadrant contains a list of all actions that are possible based on combinations of conditions
...
Therefore, each column of the matrix may be interpreted
as a processing rule
...
List all actions that can be associated with a speciﬁc procedure (or module)
...
List all conditions (or decisions made) during execution of the procedure
...
Associate speciﬁc sets of conditions with speciﬁc actions, eliminating impossible combinations of conditions; alternatively, develop every possible permutation of conditions
...
Deﬁne rules by indicating what action(s) occurs for a set of conditions
...
4
Decision table
nomenclature

Action #4
Action #5

1

2

3

4

n

CHAPTER 16

429

C O M P O N E N T- L E V E L D E S I G N

To illustrate the use of a decision table, consider the following excerpt from a processing narrative for a public utility billing system:
If the customer account is billed using a ﬁxed rate method, a minimum monthly charge is
assessed for consumption of less than 100 KWH (kilowatt-hours)
...
However, if the account is billed using a variable rate method, a Schedule A rate structure will apply to consumption below 100 KWH,
with additional consumption billed according to Schedule B
...
5 illustrates a decision table representation of the preceding narrative
...
e
...
As a general rule, the decision table can be effectively used to supplement other procedural design notation
...
1
...
e
...
e
...
In this
chapter, PDL is used as a generic reference for a design language
...
The difference
between PDL and a real programming language lies in the use of narrative text (e
...
,
English) embedded directly within PDL statements
...
However, PDL tools currently exist to translate PDL into a programming lan-

Rules
Conditions

1

2

3

4

5

Fixed rate acct
...

F

F

T

T

F

Consumption <100 kwh

T

F

T

F

Consumption ≥100 kwh

F

T

F

T

Actions
Min
...
5
Resultant
decision table

Other treatment

430

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

guage “skeleton” and/or a graphical representation (e
...
, a ﬂowchart) of design
...

A program design language may be a simple transposition of a language such as
Ada or C
...

It’s a good idea to use
your programming
language as the basis
for the PDL
...

Regardless of origin, a design language should have the following characteristics:
•

A ﬁxed syntax of keywords that provide for all structured constructs, data
declaration, and modularity characteristics
...

•

Data declaration facilities that should include both simple (scalar, array) and
complex (linked list or tree) data structures
...

A basic PDL syntax should include constructs for subprogram deﬁnition, interface
description, data declaration, techniques for block structuring, condition constructs,
repetition constructs, and I/O constructs
...

It should be noted that PDL can be extended to include keywords for multitasking
and/or concurrent processing, interrupt handling, interprocess synchronization, and
many other features
...

16
...
4 A PDL Example
To illustrate the use of PDL, we present an example of a procedural design for the
SafeHome security system software introduced in earlier chapters
...
g
...
In the PDL that follows, we
illustrate some of the important constructs noted in earlier sections
...
The designer can adapt as required
without worry of syntax errors
...
The following PDL deﬁnes an elaboration of the procedural
design for the security monitor component
...
monitor;
INTERFACE RETURNS system
...
value IS upper bound SCALAR;
message IS STRING LENGTH VAR;
END signal TYPE;
TYPE system
...
type DEFINED
smoke
...
alarm IS INSTANCE OF signal;
water
...
alarm IS INSTANCE OF signal;
burglar
...
number IS area code + 7-digit number;
•
•
•
initialize all system ports and reset all hardware;
CASE OF control
...
switches (cps):
WHEN cps = "test" SELECT
CALL alarm PROCEDURE WITH "on" for test
...
bound
...
input PROCEDURE;
WHEN cps = "burglar
...
off" SELECT deactivate signal [burglar
...
switch is turned off
reset all signal
...
type = smoke, ﬁre, water, temp, burglar;
READ address [alarm
...
value;
IF signal
...
type]
THEN phone
...
type];
set alarm
...
timeseconds;
PARBEGIN
CALL alarm PROCEDURE WITH "on", alarm
...
type], phone
...
monitor

Note that the designer for the security
...
ENDPAR that speciﬁes a parallel block
...
In this case, implementation details are
not considered
...
2

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

C O M PA R I S O N O F D E S I G N N O TAT I O N
In the preceding section, we presented a number of different techniques for representing a procedural design
...
With this thought in mind, we examine criteria that may be
applied to compare design notation
...
In addition, the notation should enhance "code to" ability so that
code does, in fact, become a natural by-product of design
...

The following attributes of design notation have been established in the context
of the general characteristics described previously:

? What criteria
can be used
to assess design
notation?

Modularity
...

Overall simplicity
...

Ease of editing
...
The ease with which a design representation can be edited can
help facilitate each software engineering task
...
Notation that can be input directly into a computer-based
development system offers signiﬁcant beneﬁts
...
Software maintenance is the most costly phase of the software life
cycle
...

Structure enforcement
...
Design notation that enforces the
use of only the structured constructs promotes good design practice
...
A procedural design contains information that can be
processed to give the designer new or better insights into the correctness and quality of a design
...

Data representation
...
Ideally, design notation should represent such
data directly
...
Automatic veriﬁcation of design logic is a goal that is paramount
during software testing
...

CHAPTER 16

C O M P O N E N T- L E V E L D E S I G N

433

"Code-to" ability
...
Notation that may be converted easily to source code
reduces effort and error
...
However, it appears that program design
language offers the best combination of characteristics
...
Editing can be accomplished with any text editor or word-processing system, automatic processors already exist, and the potential for "automatic code generation" is good
...
The pictorial nature of ﬂowcharts and box
diagrams provide a perspective on control ﬂow that many designers prefer
...
And many other design representations (e
...
, see [PET81], [SOM96]), not
presented in this book, offer their own unique beneﬁts
...

16
...
Component-level design
depicts the software at a level of abstraction that is very close to code
...
To accomplish this, the designer uses one of a number
of design notations that represent component-level detail in either graphical, tabular, or text-based formats
...
The intent
of structured programming is to assist the designer in deﬁning algorithms that are
less complex and therefore easier to read, test, and maintain
...
and G
...
9, no
...
366–371
...
and K
...
National

Computer Conference, AFIPS Press, 1975, pp
...

434

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

[CHA74] Chapin, N
...
4, no
...
341–357
...
, "Programming Considered as a Human Activity," in Proc
...
, 1965
...
, “The Humble Programmer,” 1972 ACM Turing Award Lecture,

CACM, vol
...
10, October, 1972, pp
...

[DIJ76]

Dijkstra, E
...
Buxton et al
...
), Van Nostrand-Reinhold, 1976
...
B
...

[LIN79]

Linger, R
...
, H
...
Mills, and B
...
Witt, Structured Programming, Addison-

Wesley, 1979
...
and B
...

[PET81] Peters, L
...
, Software Design: Methods and Techniques, Yourdon Press, 1981
...
, Software Engineering, 5th ed
...

PROBLEMS AND POINTS TO PONDER
16
...
Select a small portion of an existing program (approximately 50–75 source
lines)
...
Does the program excerpt have constructs that violate the structured programming philosophy? If so, redesign the code to make it conform to structured programming constructs
...
2
...
Provide examples from three programming languages
...
3
...
4–16
...
Your instructor may assign speciﬁc design
notation to particular problems
...
4
...
Refer to a book on data structures if you are unfamiliar with these sorts
...
5
...
Derive your own requirements and assume that all tax
computations are performed by other modules
...
6
...

16
...
Develop a procedural design of a program that will numerically integrate a
function f in the bounds a to b
...
8
...

16
...
Develop a procedural design for a program that will solve the Towers of Hanoi
problem
...

16
...
Develop a procedural design for all or major portions of an LR parser for a
compiler
...

16
...
Develop a procedural design for an encryption/decryption algorithm of your
choosing
...
12
...
Be certain that your argument addresses the criteria presented in
Section 16
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
The work of Linger, Mills, and Witt (Structured Programming—Theory and Practice,
Addison-Wesley, 1979) remains a deﬁnitive treatment of the subject
...
Other books that focus on procedural design issues include those by Robertson (Simple Program Design, Boyd and Fraser Publishing, 1994), Bentley (Programming
Pearls, Addison-Wesley, 1986 and More Programming Pearls, Addison-Wesley, 1988),
and Dahl, Dijkstra, and Hoare (Structured Programming, Academic Press, 1972)
...

In general, programming language books address procedural design in some detail
but always in the context of the language that is introduced by the book
...
A
...
C
...
L
...

[ANT96] Antonakos, J
...
and K
...

[FOR99] Forouzan, B
...
and R
...

[OBR93] O'Brien, S
...
and S
...

436

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

[WEL95] Welburn, T
...
Price, Structured COBOL: Fundamentals and Style, 4th ed
...

A wide variety of information sources on software design and related subjects is
available on the Internet
...
mhhe
...
mhtml

CHAPTER

SOFTWARE TESTING
TECHNIQUES

17
KEY
CONCEPTS
basis path
testing
...
To quote Deutsch [DEU79],

T

behavioral
testing
...
459

occur at the very inception of the process where the objectives
...
465

Because of human inability to perform and communicate with perfection, software

control structure
testing
...

cyclomatic
complexity
...
463
ﬂow graphs
...
458
OA testing
...
440
testing
objectives
...
Errors may begin to
or imperfectly specified, as well as [in] later design and development stages
...

The increasing visibility of software as a system element and the attendant
"costs" associated with a software failure are motivating forces for well-planned,
thorough testing
...
In the
extreme, testing of human-rated software (e
...
, ﬂight control, nuclear reactor
monitoring) can cost three to five times as much as all other software engineering steps combined!

What is it? Once source code has
been generated, software must

testing process progresses, testing specialists may
become involved
...
Your goal is to design a series of test

sufﬁcient
...
These techniques provide sys-

the specific intent of finding and removing all

tematic guidance for designing tests that (1) exer-

errors
...
and performance
...

What are the steps? Software is tested from two dif-

Who does it? During early stages of testing, a soft-

ferent perspectives: (1) internal program logic is

ware engineer performs all tests
...
Software requirements

nal requirements is designed and documented,

are exercised using “black box”

expected results are defined, and actual results

test case design techniques
...

both cases, the intent is to ﬁnd the maximum num-

How do I ensure that I’ve done it right? When you

ber of errors with the minimum amount of effort

begin testing, change your point of view
...

to “break” the software! Design test cases in a dis-

What is the work product?

A set of test cases

designed to exercise both internal logic and exter-

ciplined fashion and review the test cases you do
create for thoroughness
...
Software testing fundamentals define the overriding objectives for software testing
...
In Chapter 18, testing strategies and software debugging are presented
...
1

S O F T WA R E T E S T I N G F U N D A M E N TA L S
Testing presents an interesting anomaly for the software engineer
...
”
Robert Dunn

concept to a tangible product
...
The engineer creates a series of
test cases that are intended to "demolish" the software that has been built
...

Software engineers are by their nature constructive people
...

Beizer [BEI90] 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
...
So goes the myth
...

Therefore, testing and test case design is an admission of failure, which instills a goodly
dose of guilt
...
Punishment for
what? For being human? Guilt for what? For failing to achieve inhuman perfection? For not
distinguishing between what another programmer thinks and what he says? For failing to
be telepathic? For not solving human communications problems that have been kicked
around
...

17
...
1 Testing Objectives
In an excellent book on software testing, Glen Myers [MYE79] states a number of
rules that can serve well as testing objectives:
1
...

objectives when
we test
software?

2
...

3
...

These objectives imply a dramatic change in viewpoint
...
Our
objective is to design tests that systematically uncover different classes of errors and
to do so with a minimum amount of time and effort
...
”
David Parnas

will uncover errors in the software
...
In addition, data collected as testing is conducted provide a good indication of software reliability and some indication
of software quality as a whole
...
It is important
to keep this (rather gloomy) statement in mind as testing is being conducted
...
1
...
Davis [DAV95] suggests
a set1 of testing principles that have been adapted for use in this book:
•

All tests should be traceable to customer requirements
...
It follows that the
most severe defects (from the customer’s point of view) are those that cause
the program to fail to meet its requirements
...
Test planning
(Chapter 18) can begin as soon as the requirements model is complete
...
For more information, see
[DAV95]
...
Therefore, all tests can be planned and designed before any
code has been generated
...
Stated simply, the
Pareto principle implies that 80 percent of all errors uncovered during testing
will likely be traceable to 20 percent of all program components
...

•

Testing should begin “in the small” and progress toward testing “in
the large
...
As testing progresses, focus shifts in an attempt to ﬁnd errors in
integrated clusters of components and ultimately in the entire system (Chapter 18)
...
The number of path permutations for
even a moderately sized program is exceptionally large (see Section 17
...
For this reason, it is impossible to execute every combination of paths during testing
...

•

To be most effective, testing should be conducted by an independent
third party
...
For reasons that have
been introduced earlier in this chapter and are considered in more detail in
Chapter 18, the software engineer who created the system is not the best
person to conduct all tests for the software
...
1
...
This enables the individuals charged with testing to design effective test cases more easily
...
stlabs
...

htm

describes testability in the following manner
...
Since
testing is so profoundly difﬁcult, it pays to know what can be done to streamline it
...
, can be useful in negotiating with them
...
Sometimes, testability is used to mean how adequately a particular set of

2

The paragraphs that follow are copyright 1994 by James Bach and have been adapted from an
Internet posting that ﬁrst appeared in the newsgroup comp
...
This material is used
with permission
...
It's also used by the military to mean how easily a tool
can be checked and repaired in the ﬁeld
...
The checklist that follows provides a set of characteristics that lead
to testable software
...
"The better it works, the more efﬁciently it can be tested
...

“Testability” occurs as
a result of good
design
...

• No bugs block the execution of tests
...

Observability
...
"
• Distinct output is generated for each input
...

• Past system states and variables are visible or queriable (e
...
, transaction logs)
...

• Incorrect output is easily identiﬁed
...

• Internal errors are automatically reported
...

Controllability
...
"
• All possible outputs can be generated through some combination of input
...

• Software and hardware states and variables can be controlled directly by the
test engineer
...

• Tests can be conveniently speciﬁed, automated, and reproduced
...
"By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting
...

• Software modules can be tested independently
...
"The less there is to test, the more quickly we can test it
...
g
...

442

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

• Structural simplicity (e
...
, architecture is modularized to limit the propagation of faults)
...
g
...

Stability
...
"
• Changes to the software are infrequent
...

• Changes to the software do not invalidate existing tests
...

Understandability
...
"
• The design is well understood
...

• Changes to the design are communicated
...

• Technical documentation is well organized
...

• Technical documentation is accurate
...
e
...

And what about the tests themselves? Kaner, Falk, and Nguyen [KAN93] suggest
the following attributes of a “good” test:

? What are the
attributes of
a “good” test?

1
...
To achieve this goal, the
tester must understand the software and attempt to develop a mental picture
of how the software might fail
...
For
example, one class of potential failure in a GUI (graphical user interface) is a
failure to recognize proper mouse position
...

2
...
Testing time and resources are limited
...

Every test should have a different purpose (even if it is subtly different)
...
In an effort to uncover an error in password input, the tester designs a
series of tests that input a sequence of passwords
...
However, each

CHAPTER 17

S O F T WA R E T E S T I N G T E C H N I Q U E S

443

valid/invalid password should probe a different mode of failure
...
If it is accepted, an error is present
...
However, the invalid input 8081 or 8180 has a subtle
difference, attempting to demonstrate that an error exists for passwords
“close to” but not identical with the valid password
...
A good test should be “best of breed” [KAN93]
...
In such cases, the test that has the highest
likelihood of uncovering a whole class of errors should be used
...
A good test should be neither too simple nor too complex
...
In general,
each test should be executed separately
...
2

TEST CASE DESIGN
The design of tests for software and other engineered products can be as challeng-

“There is only one
rule in designing test
cases: cover all
features, but do not
make too many test
cases
...
Yet, for reasons that we have already
discussed, software engineers often treat testing as an afterthought, developing test
cases that may "feel right" but have little assurance of being complete
...

A rich variety of test case design methods have evolved for software
...
More important,
methods provide a mechanism that can help to ensure the completeness of tests and
provide the highest likelihood for uncovering errors in software
...
testworks
...
The ﬁrst test approach is called black-box testing
and the second, white-box testing
...
Although they are designed to uncover errors,
black-box tests are used to demonstrate that software functions are operational, that
input is properly accepted and output is correctly produced, and that the integrity of

444

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

external information (e
...
, a database) is maintained
...

White-box testing of software is predicated on close examination of procedural

White-box tests can be
designed only after a
component-level design
(or source code)
exists
...

detail
...
The "status of the program" may be
examined at various points to determine if the expected or asserted status corresponds to the actual status
...
" All we need do is deﬁne all logical paths, develop
test cases to exercise them, and evaluate results, that is, generate test cases to exercise program logic exhaustively
...
For even small programs, the number of possible logical paths
can be very large
...
After
some basic data declaration, the program contains two nested loops that execute
from 1 to 20 times each, depending on conditions speciﬁed at input
...
There are approximately 1014 possible paths that may be executed in this program!
To put this number in perspective, we assume that a magic test processor ("magic"
because no such processor exists) has been developed for exhaustive testing
...
Working 24 hours a day, 365 days a year, the processor would work for 3170

It is not possible to
exhaustively test every
program path because
the number of paths is
simply too large
...
This would, undeniably, cause havoc in most development
schedules
...

White-box testing should not, however, be dismissed as impractical
...
Important data
structures can be probed for validity
...

17
...
Using
white-box testing methods, the software engineer can derive test cases that (1) guarantee that all independent paths within a module have been exercised at least once,
(2) exercise all logical decisions on their true and false sides, (3) execute all loops at
their boundaries and within their operational bounds, and (4) exercise internal data
structures to ensure their validity
...
g
...
Errors tend to creep into our work
when we design and implement function, conditions, or control that are out
of the mainstream
...

•

We often believe that a logical path is not likely to be executed when, in fact, it
may be executed on a regular basis
...
”

times counterintuitive, meaning that our unconscious assumptions about
ﬂow of control and data may lead us to make design errors that are uncovered only once path testing commences
...
When a program is translated into programming language source code, it is likely that some typing errors will occur
...
It is as likely that a typo will exist on
an obscure logical path as on a mainstream path
...
Blackbox testing, no matter how thorough, may miss the kinds of errors noted here
...

17
...
The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for deﬁning a
basis set of execution paths
...

17
...
1 Flow Graph Notation
Before the basis path method can be introduced, a simple notation for the representation of control ﬂow, called a ﬂow graph (or program graph) must be introduced
...
1
...

To illustrate the use of a ﬂow graph, we consider the procedural design representation in Figure 17
...
Here, a ﬂowchart is used to depict program control structure
...
However,
they serve as a useful tool for understanding control ﬂow and illustrating the approach
...
1
Flow graph
notation

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

The structured constructs in flow graph form:
Sequence

If

While

Case

Until

Where each circle represents one or more
nonbranching PDL or source code statements

Figure 17
...
Refer-

Draw a ﬂow graph
when the logical
control structure of a
module is complex
...

ring to Figure 17
...
A sequence of process boxes and a decision diamond can
map into a single node
...
An edge must terminate
at a node, even if the node does not represent any procedural statements (e
...
, see
the symbol for the if-then-else construct)
...
When counting regions, we include the area outside the graph as a
region
...
A compound condition occurs
when one or more Boolean operators (logical OR, AND, NAND, NOR) is present in a
conditional statement
...
3, the PDL segment translates into the
ﬂow graph shown
...
Each node that contains a condition is called a predicate node and is characterized by two or more edges emanating from it
...
4
...
When used in the context of the basis path testing
method, the value computed for cyclomatic complexity deﬁnes 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 conducted to ensure that all statements have been
executed at least once
...
When stated in terms of a ﬂow
4

A more-detailed discussion of graphs and their use in testing is contained in Section 17
...
1
...
2
Flowchart, (A)
and ﬂow
graph (B)

1

2

3

4

6

7

8

5

9

10

11
(A)

1
Edge
Node

2,3

6
7

R2

R3

4,5

8
Region

R1

9

10

11
(B)

R4

448

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 17
...

...

IF a OR b
then procedure x
else procedure y
ENDIF

a

b

y

x

x

graph, an independent path must move along at least one edge that has not been traversed before the path is deﬁned
...
2B is
path 1: 1-11
path 2: 1-2-3-4-5-10-1-11
path 3: 1-2-3-6-8-9-10-1-11
path 4: 1-2-3-6-7-9-10-1-11
Note that each new path introduces a new edge
...
It
can be used for test
planning as well as
test case design
...

Paths 1, 2, 3, and 4 constitute a basis set for the ﬂow graph in Figure 17
...
That
is, if tests can be designed to force execution of these paths (a basis set), every statement in the program will have been guaranteed to be executed at least one time and
every condition will have been executed on its true and false sides
...
In fact, a number of different basis sets can be derived
for a given procedural design
...

Cyclomatic complexity has a foundation in graph theory and provides us with an
extremely useful software metric
...
The number of regions of the ﬂow graph correspond to the cyclomatic complexity
...
Cyclomatic complexity, V(G), for a ﬂow graph, G, is deﬁned as
V(G) = E Ϫ N + 2

CHAPTER 17

S O F T WA R E T E S T I N G T E C H N I Q U E S

449

where E is the number of ﬂow graph edges, N is the number of ﬂow graph
nodes
...

3
...

Referring once more to the ﬂow graph in Figure 17
...
The ﬂow graph has four regions
...
V(G) = 11 edges Ϫ 9 nodes + 2 = 4
...
V(G) = 3 predicate nodes + 1 = 4
...
2B is 4
...

17
...
3 Deriving Test Cases
The basis path testing method can be applied to a procedural design or to source
code
...
The procedure average, depicted in PDL in Figure 17
...
Note that average, although an extremely
simple algorithm, contains compound conditions and loops
...
Using the design or code as a foundation, draw a corresponding ﬂow
graph
...
”
Robert Dunn

sented in Section 16
...
1
...
4, a
ﬂow graph is created by numbering those PDL statements that will be
mapped into corresponding ﬂow graph nodes
...
5
...
Determine the cyclomatic complexity of the resultant ﬂow graph
...
5
...
It should be noted that V(G) can be determined
without developing a ﬂow graph by counting all conditional statements in the
PDL (for the procedure average, compound conditions count as two) and
adding 1
...
5,
V(G) = 6 regions
V(G) = 17 edges Ϫ 13 nodes + 2 = 6
V(G) = 5 predicate nodes + 1 = 6

450

PA R T T H R E E

F I G U R E 17
...

INTERFACE RETURNS average, total
...
valid;
INTERFACE ACCEPTS value, minimum, maximum;

1

TYPE value[1:100] IS SCALAR ARRAY;
TYPE average, total
...
valid;
minimum, maximum, sum IS SCALAR;
TYPE i IS INTEGER;
i = 1;
2
total
...
valid = 0;

sum = 0;
DO WHILE value[i] <> –999 AND total
...
input by 1;
IF value[i] > = minimum AND value[i] < = maximum
THEN increment total
...
valid > 0 10
11 THEN average = sum / total
...
Determine a basis set of linearly independent paths
...
In the case of procedure average, we expect to specify six
paths:
path 1:

1-2-10-11-13

path 2:

1-2-10-12-13

path 3:

1-2-3-10-11-13

path 4:

1-2-3-4-5-8-9-2-
...

path 6:

1-2-3-4-5-6-7-8-9-2-
...
) following paths 4, 5, and 6 indicates that any path through the
remainder of the control structure is acceptable
...
In this case, nodes
2, 3, 5, 6, and 10 are predicate nodes
...
Prepare test cases that will force execution of each path in the basis
set
...
Test cases that satisfy the basis set
just described are

CHAPTER 17

451

S O F T WA R E T E S T I N G T E C H N I Q U E S

F I G U R E 17
...

“[Software
engineers]
considerably
underestimate the
number of tests
required to verify a
straightforward
program
...

Path 2 test case:
value(1) = Ϫ999
Expected results: Average = Ϫ999; other totals at initial values
...

First 100 values should be valid
...

Path 4 test case:
value(i) = valid input where i < 100
value(k) < minimum where k < i
Expected results: Correct average based on k values and proper totals
...

Path 6 test case:
value(i) = valid input where i < 100
Expected results: Correct average based on n values and proper totals
...
Once all test cases have
been completed, the tester can be sure that all statements in the program have been
executed at least once
...
g
...
That is, the combination of data required to
traverse the path cannot be achieved in the normal ﬂow of the program
...

17
...
4 Graph Matrices
The procedure for deriving the ﬂow graph and even determining a set of basis paths
is amenable to mechanization
...

A graph matrix is a square matrix whose size (i
...
, number of rows and columns)
is equal to the number of nodes on the ﬂow graph
...
A simple example of a ﬂow graph and its corresponding graph matrix [BEI90]
is shown in Figure 17
...

Referring to the ﬁgure, each node on the ﬂow graph is identiﬁed by numbers, while
each edge is identiﬁed by letters
...
For example, node 3 is connected to node 4 by
edge b
...
However, by adding a link weight to each matrix entry, the graph matrix
can become a powerful tool for evaluating program control structure during testing
...
In its simplest
form, the link weight is 1 (a connection exists) or 0 (a connection does not exist)
...

•

The processing time expended during traversal of a link
...

•

The resources required during traversal of a link
...
6
Graph matrix

Connected to
node
1
2
Node

1
a

f

3

2

c

5

c

d

4

d

4

g

g

Flow graph

F I G U R E 17
...
The graph
matrix in Figure 17
...
7
...

Represented in this form, the graph matrix is called a connection matrix
...
7, each row with two or more entries represents a predicate
node
...
4
...

Beizer [BEI90] provides a thorough treatment of additional mathematical algorithms that can be applied to graph matrices
...

454

PA R T T H R E E

17
...
4 is one of a number of techniques for control structure testing
...
In this section, other variations on control structure testing are discussed
...

17
...
1 Condition Testing5
Condition testing is a test case design method that exercises the logical conditions

Errors are much more
common in the
neighborhood of
logical conditions than
they are in the locus of
sequential processing
statements
...
A simple condition is a Boolean variable or a relational expression, possibly preceded with one NOT (¬) operator
...
A compound condition is composed of two
or more simple conditions, Boolean operators, and parentheses
...
A condition without relational expressions is referred to as a Boolean expression
...

If a condition is incorrect, then at least one component of the condition is incorrect
...

•

Boolean variable error
...

•

Relational operator error
...

The condition testing method focuses on testing each condition in the program
...
First, measurement of test coverage of a condition is simple
...

The purpose of condition testing is to detect not only errors in the conditions of a
program but also other errors in the program
...
5
...
5
...
C
...

CHAPTER 17

S O F T WA R E T E S T I N G T E C H N I Q U E S

455

for detecting errors in the conditions contained in P, it is likely that this test set is also
effective for detecting other errors in P
...

A number of condition testing strategies have been proposed
...
For a compound condition C, the
true and false branches of C and every simple condition in C need to be executed at
least once [MYE79]
...
For a relational expression of the form

Even if you decide
against condition
testing, you should
spend time evaluating
each condition in an
effort to uncover
errors
...
If is incorrect and E1 and E2 are
correct, then these three tests guarantee the detection of the relational operator
error
...

For a Boolean expression with n variables, all of 2n possible tests are required (n > 0)
...

Error-sensitive tests for Boolean expressions can also be derived [FOS84, TAI87]
...

Tai [TAI89] suggests a condition testing strategy that builds on the techniques just
outlined
...

The BRO strategy uses condition constraints for a condition C
...
, Dn), where Di (0 < i ≤ n)
is a symbol specifying a constraint on the outcome of the ith simple condition in condition C
...

For a Boolean variable, B, we specify a constraint on the outcome of B that states
that B must be either true (t) or false (f)
...

456

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

As an example, consider the condition
C1: B1 & B2
where B1 and B2 are Boolean variables
...
The value (t, f) is a condition constraint
for C1 and is covered by the test that makes the value of B1 to be true and the value
of B2 to be false
...
If C1 is incorrect due to one or more Boolean
operator errors, at least one of the constraint set will force C1 to fail
...
A condition constraint for C2 is of the form (D1, D2), where each of D1 is t or f and D2 is
>, =, <
...
Note that t for (E3 = E4) implies = and that
f for (E3 = E4) implies either < or >
...
Coverage of the preceding constraint set will guarantee detection of Boolean and relational operator errors in C2
...
A condition constraint for C3 is
of the form (D1, D2), where each of D1 and D2 is >, =, <
...

17
...
2 Data Flow Testing
The data ﬂow testing method selects test paths of a program according to the locations of deﬁnitions and uses of variables in the program
...
g
...

To illustrate the data flow testing approach, assume that each statement in a
program is assigned a unique statement number and that each function does not
modify its parameters or global variables
...
The deﬁnition of variable X at statement S is said to
be live at statement S' if there exists a path from statement S to statement S' that contains no other deﬁnition of X
...

One simple data ﬂow testing strategy is to require that every DU chain be covered

It is unrealistic to
assume that data ﬂow
testing will be used
extensively when
testing a large system
...

at least once
...
It has been shown
that DU testing does not guarantee the coverage of all branches of a program
...
In this situation, the else branch of the if statement is not necessarily covered by DU testing
...
To illustrate this, consider the application of
DU testing to select test paths for the PDL that follows:
proc x
B1;
do while C1
if C2
then
if C4
then B4;
else B5;
endif;
else
if C3
then B2;
else B3;
endif;
endif;
enddo;
B6;
end proc;
To apply the DU testing strategy to select test paths of the control ﬂow diagram, we
need to know the deﬁnitions and uses of variables in each condition or block in the
PDL
...
The DU
testing strategy requires an execution of the shortest path from each of Bi, 0 < i ≤ 5,

458

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

to each of Bj, 1 < j ≤ 6
...
) Although there are 25 DU chains of variable X, we need only ﬁve
paths to cover these DU chains
...

If we apply the branch testing strategy to select test paths of the PDL just noted,
we do not need any additional information
...
(After the selection of a path of a program, we need to determine whether the path is feasible for
the program; that is, whether at least one input exists that exercises the path
...
However, the problems of measuring test coverage and selecting test paths
for data ﬂow testing are more difﬁcult than the corresponding problems for condition
testing
...
5
...
And yet, we often pay them little heed while conducting software tests
...

It’s well worth
spending time
designing tests that
fully exercise loop
structures
...
Four different classes of loops [BEI90] can be deﬁned: simple
loops, concatenated loops, nested loops, and unstructured loops (Figure 17
...

Simple loops
...

1
...

2
...

3
...

4
...

5
...

Nested loops
...
This would result in an impractical number of tests
...
Start at the innermost loop
...

2
...
g
...
Add
other tests for out-of-range or excluded values
...
8
Classes of
loops

Nested loops
Simple loops
Concatenated
loops

Unstructured
loops

3
...

4
...

Concatenated loops
...
However, if two

You can’t test
unstructured loops
effectively
...

loops are concatenated and the loop counter for loop 1 is used as the initial value for
loop 2, then the loops are not independent
...

Unstructured loops
...

17
...
That is, black-box testing enables the software engineer to
derive sets of input conditions that will fully exercise all functional requirements for
a program
...
Rather,
it is a complementary approach that is likely to uncover a different class of errors
than white-box methods
...

Unlike white-box testing, which is performed early in the testing process, blackbox testing tends to be applied during later stages of testing (see Chapter 18)
...
Tests are designed to answer the following questions:
•

How is functional validity tested?

•

How is system behavior and performance tested?

•

What classes of input will make good test cases?

•

Is the system particularly sensitive to certain input values?

•

How are the boundaries of a data class isolated?

•

What data rates and data volume can the system tolerate?

•

What effect will speciﬁc combinations of data have on system operation?

By applying black-box techniques, we derive a set of test cases that satisfy the following criteria [MYE79]: (1) test cases that reduce, by a count that is greater than one,
the number of additional test cases that must be designed to achieve reasonable testing and (2) test cases that tell us something about the presence or absence of classes
of errors, rather than an error associated only with the speciﬁc test at hand
...
6
...

software and the relationships that connect these objects
...
” Stated in another way, software testing begins by creating a graph of important objects and their relationships and then
devising a series of tests that will cover the graph so that each object and relationship is exercised and errors are uncovered
...
g
...
7
6

7

In this context, the term object encompasses the data objects that we discussed in Chapters 11
and 12 as well as program objects such as modules or collections of programming language
statements
...
4
...
The nodes of the program graph contained instructions (program objects) characterized as either procedural design representations
or source code, and the directed links indicated the control ﬂow between these program objects
...

CHAPTER 17

F I G U R E 17
...
0 sec)

Document
window

Allows editing of
Is represented as
Contains
Document
text

Attributes:
Start dimension: default setting
or preferences
Background color: white
Text color: default color
or preferences

(B)

The symbolic representation of a graph is shown in Figure 17
...
Nodes are represented as circles connected by links that take a number of different forms
...
A bidirectional link, also called a symmetric link, implies that the relationship
applies in both directions
...

As a simple example, consider a portion of a graph for a word-processing application (Figure 17
...

The node weight of document window provides a list of the window attributes that
are to be expected when the window is generated
...
0 second
...
In reality, a far more detailed graph would have to be generated as a precursor to test case design
...
These test cases are designed
in an attempt to ﬁnd errors in any of the relationships
...
The nodes represent steps in some transaction (e
...
, the steps required to make an airline reservation using an on-line
service), and the links represent the logical connection between steps (e
...
,
ﬂight
...
input is followed by validation/availability
...

The data ﬂow diagram (Chapter 12) can be used to assist in creating graphs
of this type
...
The nodes represent different user observable states
of the software (e
...
, 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
...
, order-information is veriﬁed during inventory-availability look-up and is followed by customer-billing-information
input)
...

Data ﬂow modeling
...
For
example, the node FICA
...
withheld (FTW) is computed from
gross
...
62 ϫ GW
...
The nodes are program objects and the links are the
sequential connections between those objects
...

A detailed discussion of each of these graph-based testing methods is beyond the
scope of this book
...
It is worthwhile, however, to provide a generic outline of the graph-based
testing approach
...
That

? What generic
activities are
required during
graph-based
testing?

is, objects and attributes are identiﬁed
...
To provide an indication of the start
and stop points for the graph, it is useful to deﬁne entry and exit nodes
...
In
general, links should be named, although links that represent control ﬂow between
program objects need not be named
...
e
...
Loop testing (Section
17
...
3) can also be applied at the behavioral (black-box) level
...

Each relationship is studied separately so that test cases can be derived
...
Transitivity can be illustrated
by considering three objects, X, Y, and Z
...

The symmetry of a relationship (graph link) is also an important guide to the design
of test cases
...
The UNDO feature [BEI95] in many personal computer applications implements limited symmetry
...
This should be thoroughly tested and all exceptions (i
...
, places
where UNDO cannot be used) should be noted
...
These reﬂexive relationships should also be tested
...
By this
we mean that tests should be designed to demonstrate that no nodes have been inadvertently omitted and that node weights (object attributes) are correct
...
Each relationship is tested based on its properties
...
A transitive relationship is tested to demonstrate that transitivity is present
...
When link
weights have been speciﬁed, tests are devised to demonstrate that these weights are
valid
...
5
...

17
...
2 Equivalence Partitioning
Equivalence partitioning is a black-box testing method that divides the input domain of
a program into classes of data from which test cases can be derived
...
g
...
Equivalence partitioning strives to deﬁne a test case that uncovers classes
of errors, thereby reducing the total number of test cases that must be developed
...
Using concepts introduced in the preceding

Input classes are
known relatively early
in the software
process
...

section, if a set of objects can be linked by relationships that are symmetric, transitive, and reﬂexive, an equivalence class is present [BEI95]
...
Typically, an input condition
is either a speciﬁc numeric value, a range of values, a set of related values, or a Boolean
condition
...
If an input condition speciﬁes a range, one valid and two invalid equivalence
classes are deﬁned
...
If an input condition requires a speciﬁc value, one valid and two invalid
equivalence classes are deﬁned
...
If an input condition speciﬁes a member of a set, one valid and one invalid
equivalence class are deﬁned
...
If an input condition is Boolean, one valid and one invalid class are deﬁned
...
The user can access the bank using a personal computer, provide a six-digit
password, and follow with a series of typed commands that trigger various banking
functions
...

Input condition, range—values deﬁned between 200 and 999, with
speciﬁc exceptions
...

Input condition, value—four-digit length
Input condition, value—six-character string
...

Applying the guidelines for the derivation of equivalence classes, test cases for each
input domain data item can be developed and executed
...

CHAPTER 17

S O F T WA R E T E S T I N G T E C H N I Q U E S

465

17
...
3 Boundary Value Analysis
For reasons that are not completely clear, a greater number of errors tends to occur
at the boundaries of the input domain rather than in the "center
...

that boundary value analysis (BVA) has been developed as a testing technique
...

Boundary value analysis is a test case design technique that complements equivalence partitioning
...
Rather than focusing
solely on input conditions, BVA derives test cases from the output domain as well
[MYE79]
...
If an input condition speciﬁes a range bounded by values a and b, test cases
should be designed with values a and b and just above and just below a
and b
...
If an input condition speciﬁes a number of values, test cases should be developed that exercise the minimum and maximum numbers
...

3
...
For example, assume that a
temperature vs
...
Test cases should be designed to create an output report
that produces the maximum (and minimum) allowable number of table
entries
...
If internal program data structures have prescribed boundaries (e
...
, an array
has a deﬁned limit of 100 entries), be certain to design a test case to exercise
the data structure at its boundary
...
By applying these
guidelines, boundary testing will be more complete, thereby having a higher likelihood for error detection
...
6
...
g
...
In such applications redundant
hardware and software are often used to minimize the possibility of error
...
In such situations,
each version can be tested with the same test data to ensure that all provide identical output
...

466

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Using lessons learned from redundant systems, researchers (e
...
, [BRI87]) have
suggested that independent versions of software be developed for critical applications, even when only a single version will be used in the delivered computer-based
system
...

When multiple implementations of the same speciﬁcation have been produced,
test cases designed using other black-box techniques (e
...
, equivalence partitioning)
are provided as input to each version of the software
...
If the output is different, each of the applications is investigated to determine if a defect in one or more
versions is responsible for the difference
...

Comparison testing is not foolproof
...
In addition,
if each of the independent versions produces identical but incorrect results, condition testing will fail to detect the error
...
6
...
That is,
the number of input parameters is small and the values that each of the parameters
may take are clearly bounded
...
g
...
However, as the
number of input values grows and the number of discrete values for each data item
increases, exhaustive testing become impractical or impossible
...
The orthogonal array testing method is particularly useful in finding errors associated with
region faults—an error category associated with faulty logic within a software
component
...

To illustrate the difference between orthogonal array testing and more conventional “one input item at a time” approaches, consider a system that has three input
items, X, Y, and Z
...
There are 33 = 27 possible test cases
...
10
...
This results in relatively limited coverage of the input domain (represented by
the left-hand cube in the ﬁgure)
...
The L9 orthogonal array has a “balancing property [PHA97]
...
10
A geometric
view of test
cases [PHA97]

Z

Z

Y

Y
X

One input item at a time

X

L9 orthogonal array

domain,” as illustrated in the right-hand cube in Figure 17
...
Test coverage across
the input domain is more complete
...
Four parameters, P1, P2, P3, and P4, are passed to the send function
...
For example, P1 takes on values:
P1 = 1, send it now
P1 = 2, send it one hour later
P1 = 3, send it after midnight
P2, P3, and P4 would also take on values of 1, 2 and 3, signifying other send functions
...
Phadke [PHA97]
assesses these test cases in the following manner:
Such test cases are useful only when one is certain that these test parameters do not interact
...
These faults are called single mode faults
...
Thus its ability to detect faults is limited
...
The number of tests required is 34 = 81, large, but manageable
...

The orthogonal array testing approach enables us to provide good test coverage
with far fewer test cases than the exhaustive strategy
...
11
...
11
An L9
orthogonal
array

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Test
case

Test parameters
P1

P2

P3

P4

1

1

1

1

1

2

1

2

2

2

3

1

3

3

3

4

2

1

2

3

5

2

2

3

1

6

2

3

1

2

7

3

1

3

2

8

3

2

1

3

9

3

3

2

1

Phadke [PHA97] assesses the result of tests using the L9 orthogonal array in the
following manner:
Detect and isolate all single mode faults
...
For example, if all test cases of factor P1 = 1 cause
an error condition, it is a single mode failure
...
11]
will show errors
...
In this example, by noting that tests 1, 2, and
3 cause an error, one can isolate [logical processing associated with “send it now” (P1 = 1)]
as the source of the error
...

Detect all double mode faults
...
Indeed, a double mode
fault is an indication of pairwise incompatibility or harmful interactions between two test
parameters
...
Orthogonal arrays [of the type shown] can assure the detection of only
single and double mode faults
...

A detailed discussion of orthogonal array testing can be found in [PHA89]
...
7

TESTING FOR SPECIALIZED ENVIRONMENTS,
A R C H I T E C T U R E S , A N D A P P L I C AT I O N S
As computer software has become more complex, the need for specialized testing
approaches has also grown
...
5 and 17
...
In this section we consider testing guidelines for specialized environments,
architectures, and applications that are commonly encountered by software engineers
...
7
...

Graphical user interfaces (GUIs) present interesting challenges for software engineers
...

But, at the same time, the complexity of GUIs has grown, leading to more difﬁculty
in the design and execution of test cases
...
Finite state modeling graphs may be used to derive a series of tests
that address speciﬁc data and program objects that are relevant to the GUI
...
A wide array of GUI testing tools has
appeared on the market over the past few years
...

17
...
2 Testing of Client/Server Architectures
Client/server (C/S) architectures represent a significant challenge for software
testers
...

need to service multiple clients from a centralized (or in some cases, distributed)
database, and the coordination requirements imposed on the server all combine to
make testing of C/S architectures and the software that reside within them considerably more difficult than stand-alone applications
...

17
...
3 Testing Documentation and Help Facilities
The term software testing conjures images of large numbers of test cases prepared to
exercise computer programs and the data that they manipulate
...

Errors in documentation can be as devastating to the acceptance of the program
as errors in data or source code
...
It is for this reason that that documentation testing should be a meaningful part of every software test plan
...
The ﬁrst phase, review
and inspection (Chapter 8), examines the document for editorial clarity
...

Surprisingly, a live test for documentation can be approached using techniques
that are analogous to many of the black-box testing methods discussed in Section
17
...
Graph-based testing can be used to describe the use of the program; equivalence partitioning and boundary value analysis can be used to deﬁne various classes
of input and associated interactions
...
The following questions should be answered during both phases:

? What
questions
should be
addressed as we
test
documentation?

•

Does the documentation accurately describe how to accomplish each mode
of use?

•

Is the description of each interaction sequence accurate?

•

Are examples accurate?

•

Are terminology, menu descriptions, and system responses consistent with
the actual program?

•

Is it relatively easy to locate guidance within the documentation?

•

Can troubleshooting be accomplished easily with the documentation?

•

Are the document table of contents and index accurate and complete?

•

Is the design of the document (layout, typefaces, indentation, graphics) conducive to understanding and quick assimilation of information?

•

Are all software error messages displayed for the user described in more
detail in the document? Are actions to be taken as a consequence of an error
message clearly delineated?

•

If hypertext links are used, are they accurate and complete?

•

If hypertext is used, is the navigation design appropriate for the information
required?

The only viable way to answer these questions is to have an independent third party
(e
...
, selected users) test the documentation in the context of program usage
...

17
...
4 Testing for Real-Time Systems
The time-dependent, asynchronous nature of many real-time applications adds a new
and potentially difﬁcult element to the testing mix—time
...
e
...
In many situations, test data provided when a real-

CHAPTER 17

S O F T WA R E T E S T I N G T E C H N I Q U E S

471

time system is in one state will result in proper processing, while the same data provided when the system is in a different state may lead to error
...
e
...
These same
operator interrupts, if input when the machine is in the "jammed" state, cause a display of the diagnostic code indicating the location of the jam to be lost (an error)
...
Software tests must consider the impact of hardware faults on software processing
...

Comprehensive test case design methods for real-time systems have yet to evolve
...
The ﬁrst step in the testing of real-time software is to test each
task independently
...
Each task is executed independently during these
tests
...

Behavioral testing
...
ondaweb
...
cgi/forums/
sti
...
These analysis activities can serve as
the basis for the design of test cases that are conducted when the real-time
software has been built
...
6
...
g
...
For example, events for the photocopier might be user
interrupts (e
...
, reset counter), mechanical interrupts (e
...
, paper jammed),
system interrupts (e
...
, toner low), and failure modes (e
...
, roller overheated)
...
The behavior of the system model (developed during the analysis activity) and the executable software can be
compared for conformance
...
The behavior of the software is examined to detect behavior errors
...
Once errors in individual tasks and in system behavior
have been isolated, testing shifts to time-related errors
...
In addition, tasks that communicate via a message queue or data store
are tested to uncover errors in the sizing of these data storage areas
...
Software and hardware are integrated and a full range of
system tests (Chapter 18) are conducted in an attempt to uncover errors at
the software/hardware interface
...

Therefore, testing the handling of these Boolean events is essential
...
Tests are then designed to assess the following system characteristics:
• Are interrupt priorities properly assigned and properly handled?
• Is processing for each interrupt handled correctly?
• Does the performance (e
...
, processing time) of each interrupt-handling
procedure conform to requirements?
• Does a high volume of interrupts arriving at critical times create problems in function or performance?
In addition, global data areas that are used to transfer information as part of interrupt processing should be tested to assess the potential for the generation of side
effects
...
8

SUMMARY
The primary objective for test case design is to derive a set of tests that have the highest likelihood for uncovering errors in the software
...

White-box tests focus on the program control structure
...
Basis path testing, a
white-box technique, makes use of program graphs (or graph matrices) to derive
the set of linearly independent tests that will ensure coverage
...

Hetzel [HET84] describes white-box testing as "testing in the small
...
g
...

Black-box testing, on the other hand, broadens our focus and might be called "testing in the large
...
Black-box testing techniques focus on the
information domain of the software, deriving test cases by partitioning the input and
output domain of a program in a manner that provides thorough test coverage
...
Boundary value analysis probes the program's
ability to handle data at the limits of acceptability
...

Specialized testing methods encompass a broad array of software capabilities and
application areas
...

Experienced software developers often say, "Testing never ends, it just gets transferred from you [the software engineer] to your customer
...
" By applying test case design, the software engineer can achieve more complete testing and thereby uncover and correct
the highest number of errors before the "customer's tests" begin
...
, Software Testing Techniques, 2nd ed
...

[BEI95]

Beizer, B
...

[BRI87]

Brilliant, S
...
, J
...
Knight, and N
...
Levenson, "The Consistent Comparison

Problem in N-Version Software," ACM Software Engineering Notes, vol
...
1, January 1987, pp
...

[DAV95] Davis, A
...

[DEU79] Deutsch, M
...
Jensen
and C
...
), Prentice-Hall, 1979, pp
...

[FOS84] Foster, K
...
, "Sensitive Test Data for Boolean Expressions," ACM Software
Engineering Notes, vol
...
2, April 1984, pp
...

[FRA88] Frankl, P
...
and E
...
Weyuker, "An Applicable Family of Data Flow Testing
Criteria," IEEE Trans
...
SE-14, no
...

1483–1498
...
G
...
Weiss, "An Experimental Comparison of the Effectiveness of Branch Testing and Data Flow," IEEE Trans
...
SE-19,
no
...
770–787
...
, The Complete Guide to Software Testing, QED Information Sciences, 1984
...
E
...
Software Engineering, vol
...
4, July 1982, pp
...

[JON81] Jones, T
...
, Programming Productivity: Issues for the 80s, IEEE Computer Society Press, 1981
...
, J
...
Q
...
, Van
Nostrand-Reinhold, 1993
...
and P
...
89029N, Reston, VA, June 1989
...
, "A Software Complexity Measure," IEEE Trans
...
SE-2, December 1976, pp
...

[MYE79] Myers, G
...

[NTA88] Ntafos, S
...
, A Comparison of Some Structural Testing Strategies," IEEE
Trans
...
SE-14, no
...
868–874
...
S
...

[PHA97] Phadke, M
...
, “Planning Efﬁcient Software Tests,” Crosstalk, vol
...
10,
October 1997, pp
...

[TAI87]

Tai, K
...
and H
...
Su, "Test Generation for Boolean Expressions," Proc
...
278–283
...
C
...
14, no
...
58–61
...
J
...
I
...
Software Engineering, vol
...
5, May 1980, pp
...

PROBLEMS AND POINTS TO PONDER
17
...
Myers [MYE79] uses the following program as a self-assessment for your ability to specify adequate testing: A program reads three integer values
...
The program
prints a message that states whether the triangle is scalene, isosceles, or equilateral
...

17
...
Design and implement the program (with error handling where appropriate)
speciﬁed in Problem 1
...
Execute the cases and show your results
...
3
...
1
...
4
...
4 through 16
...

17
...
Specify, design, and implement a software tool that will compute the cyclomatic complexity for the programming language of your choice
...

17
...
Read Beizer [BEI95] and determine how the program you have developed in
Problem 17
...
Extend your
tool to process execution probabilities or link processing times
...
7
...
5
...
2
...
8
...
5
...
2
...
9
...
5
...

17
...
Extend the tool described in Problem 17
...
It will be necessary to perform this function interactively with the tester
...
11
...
Give at
least three examples in which white-box testing might give the impression that "everything's OK," while black-box tests might uncover an error
...
12
...
13
...

17
...
Using boundary value analysis, derive a set of test cases for the PHTRS system described in Problem 12
...

17
...
Do a bit of outside research and write a brief paper that discusses the mechanics for generating orthogonal arrays for test data
...
16
...

17
...
Do some research on a client/server system with which you are familiar
...

17
...
Test a user manual (or help facility) for an application that you use frequently
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
Software engineering presents both technical and management challenges
...

476

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

A number of excellent books are now available for those readers who desire additional information on software testing technology
...

Myers [MYE79] remains a classic text, covering black-box techniques in considerable detail
...
His later book [BEI95] presents a concise treatment of important methods
...
Mosley (The Handbook
of MIS Application Software Testing, Prentice-Hall, 1993) discusses testing issues for
large information systems, and Marks (Testing Very Big Systems, McGraw-Hill, 1992)
discusses the special issues that must be considered when testing major programming systems
...
It is for this reason that many
organizations automate parts of the testing process
...
An excellent source of information on automated tools for software testing is the
Testing Tools Reference Guide (Software Quality Engineering, Jacksonville, FL, updated
yearly)
...

A number of books consider testing methods and strategies in specialized application areas
...

Mosley (Client/Server Software Testing on the Desk Top and the Web, Prentice-Hall,
1999) discusses the test process for clients, servers, and network components
...

A wide variety of information sources on software testing and related subjects is
available on the Internet
...
mhhe
...
mhtml

CHAPTER

18
KEY
CONCEPTS
alpha and beta
testing
...
482
debugging
...
488
ITG
...
488
regression
testing
...
The strategy provides a road map that describes
the steps 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
...

A software testing strategy should be flexible enough to promote a customized testing approach
...

Shooman [SHO83] discusses these issues:

A

In many ways, testing is an individualistic process, and the number of different types
of tests varies as much as the different development approaches
...
492

our only defense against programming errors was careful design and the native intel-

system testing
...
We are now in an era in which modern design techniques

unit testing
...
495

that are inherent in the code
...

V&V
...
If it is conducted haphazardly, time

tant, but so is the strategy you use

is wasted, unnecessary effort is expended, and

to execute them
...
It

plan for your tests? Should you test the entire pro-

would therefore seem reasonable to establish a

QUICK
LOOK

gram as a whole or run tests only on a small part

systematic strategy for testing software
...
” By this we mean that

system? When should you involve the customer?

early testing focuses on a single component and

These and many other questions are answered

applies white- and black-box tests to uncover

when you develop a software testing strategy
...
After indi-

Who does it? A strategy for software testing is devel-

vidual components are tested they must be inte-

oped by the project manager, software engineers,

grated
...

constructed
...

477

478

PA R T T H R E E

QUICK
LOOK

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

These tests are designed to

How do I ensure that I’ve done it right? By reviewing

uncover errors in requirements
...
An effective test plan and procedure will

approach to testing by defining a plan that

lead to the orderly construction of the software

describes an overall strategy and a procedure

and the discovery of errors at each stage in the

that deﬁnes speciﬁc testing steps and the tests that

construction process
...

These “approaches and philosophies” are what we shall call strategy
...
1 In this chapter, we focus our
attention on the strategy for software testing
...
1

A S T R AT E G I C A P P R O A C H T O S O F T WA R E T E S T I N G
Testing is a set of activities that can be planned in advance and conducted systematically
...

A number of software testing strategies have been proposed in the literature
...
ondaweb
...
htm

Testing begins at the component level2 and works "outward" toward the integration of the entire computer-based system
...

•

Testing is conducted by the developer of the software and (for large projects)
an independent test group
...

A strategy for software testing must accommodate low-level tests that are necessary
to verify that a small source code segment has been correctly implemented as well
as high-level tests that validate major system functions against customer requirements
...
Because the steps of the test strategy occur at a time when dead-

1

Testing for object-oriented systems is discussed in Chapter 23
...
See Chapter 23 for details
...

18
...
1 Veriﬁcation and Validation
Software testing is one element of a broader topic that is often referred to as veriﬁcation and validation (V&V)
...
Validation refers to a different set
of activities that ensure that the software that has been built is traceable to customer
requirements
...

"Are we building the product right?"

Validation:

"Are we building the right product?"

The deﬁnition of V&V encompasses many of the activities that we have referred to
as software quality assurance (SQA)
...

“Testing is an
unavoidable part of
any responsible
effort to develop a
software system
...

Testing does provide the last bastion from which quality can be assessed and, more
pragmatically, errors can be uncovered
...
As they say, "You can't test in quality
...
" Quality is incorporated into software
throughout the process of software engineering
...

Miller [MIL77] relates software testing to quality assurance by stating that "the
underlying motivation of program testing is to afﬁrm software quality with methods
that can be economically and effectively applied to both large-scale and small-scale
systems
...
1
...
The people who have built the software are now asked to test the software
...
Each of these
interests mitigate against thorough testing
...
The software engineer creates a computer program, its
documentation, and related data structures
...
When testing commences, there is a subtle, yet deﬁnite, attempt to
"break" the thing that the software engineer has built
...
So the builder
treads lightly, designing and executing tests that will demonstrate that the program
works, rather than uncovering errors
...
And, if
the software engineer doesn't ﬁnd them, the customer will!
There are often a number of misconceptions that can be erroneously inferred from
the preceeding discussion: (1) that the developer of software should do no testing at
all, (2) that the software should be "tossed over the wall" to strangers who will test

An independent test
group does not have
the “conﬂict of
interest” that builders
of the software have
...
Each of these statements is incorrect
...
In many cases, the developer also conducts integration testing—a testing
step that leads to the construction (and test) of the complete program structure
...

The role of an independent test group (ITG) is to remove the inherent problems
associated with letting the builder test the thing that has been built
...
When you
test, try to break the
software
...
After all, personnel in the independent group team are paid to ﬁnd errors
...
The developer and the ITG work closely throughout a software project to ensure
that thorough tests will be conducted
...

The ITG is part of the software development project team in the sense that it
becomes involved during the speciﬁcation activity and stays involved (planning and
specifying test procedures) throughout a large project
...

18
...
3 A Software Testing Strategy
The software engineering process may be viewed as the spiral illustrated in Figure
18
...
Initially, system engineering deﬁnes the role of software and leads to software
requirements analysis, where the information domain, function, behavior, performance, constraints, and validation criteria for software are established
...
1
Testing
strategy

481

System testing
Validation testing
Integration testing
Unit testing

Code
Design
Requirements
System engineering

inward along the spiral, we come to design and ﬁnally to coding
...

A strategy for software testing may also be viewed in the context of the spiral (Figure 18
...
Unit testing begins at the vortex of the spiral and concentrates on each unit
(i
...
, component) of the software as implemented in source code
...
Taking another turn outward on
the spiral, we encounter validation testing, where requirements established as part of
software requirements analysis are validated against the software that has been constructed
...
To test computer software, we spiral out along streamlines that broaden the scope of testing with each turn
...
The steps are shown in Figure 18
...
Initially, tests focus on each component individually, ensuring that it functions properly as a unit
...

unit testing
...
Next, components must be assembled or integrated to
form the complete software package
...
Black-box
test case design techniques are the most prevalent during integration, although a limited amount of white-box testing may be used to ensure coverage of major control
paths
...
Validation criteria (established during requirements analysis) must be
tested
...
Black-box testing techniques are used
exclusively during validation
...
2
Software
testing steps

High-order
tests

Requirements

Integration test

Design

Code

Unit
test

Testing
“direction”

The last high-order testing step falls outside the boundary of software engineering and into the broader context of computer system engineering
...
g
...
System testing veriﬁes that all elements mesh properly and that overall
system function/performance is achieved
...
1
...

One response to the question is: "You're never done testing, the burden simply

? When are
we done

shifts from you (the software engineer) to your customer
...
This sobering fact underlines the importance of other software quality assurance activities
...
"
Although few practitioners would argue with these responses, a software engineer needs more rigorous criteria for determining when sufﬁcient testing has been
conducted
...
995
...
3
Failure
intensity as a
function of
execution time

S O F T WA R E T E S T I N G S T R AT E G I E S

Predicted failure intensity, l(t)

l0

Execution time, t

Using statistical modeling and software reliability theory, models of software failures (uncovered during testing) as a function of execution time can be developed
[MUS89]
...

The instantaneous failure intensity, l(t) can be derived by taking the derivative of
f(t)
l(t) = l0 / (l0 pt + 1)

(18-2)

Using the relationship noted in Equation (18-2), testers can predict the drop-off of
errors as testing progresses
...
3)
...

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 established, but the empirical
approaches that currently exist are considerably better than raw intuition
...
2

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

S T R AT E G I C I S S U E S
Later in this chapter, we explore a systematic strategy for software testing
...
Tom Gilb
[GIL95] argues that the following issues must be addressed if a successful software
testing strategy is to be implemented:

? What
guidelines

Specify product requirements in a quantiﬁable manner long before

lead to a
successful testing
strategy?

errors, a good testing strategy also assesses other quality characteristics such

testing commences
...
These should be
speciﬁed in a way that is measurable so that testing results are unambiguous
...
The speciﬁc objectives of testing
should be stated in measurable terms
...

XRef
Use-cases describe a
scenario for software
use and are discussed
in Chapter 11
...
Use-cases that describe the interaction scenario for
each class of user can reduce overall testing effort by focusing testing on
actual use of the product
...
” Gilb
[GIL95] recommends that a software engineering team “learn to test in rapid
cycles (2 percent of project effort) of customer-useful, at least ﬁeld ‘trialable,’
increments of functionality and/or quality improvement
...

“Testing only to enduser perceived
requirements is like
inspecting a building
based on the work
done by the interior
decorator at the
expense of the
foundations, girders,
and plumbing
...
Software
should be designed in a manner that uses antibugging (Section 18
...
1)
techniques
...
In addition, the design should accommodate automated
testing and regression testing
...
Formal technical reviews (Chapter 8) can be as effective as testing in uncovering
errors
...

Conduct formal technical reviews to assess the test strategy and test
cases themselves
...
This saves time and
also improves product quality
...
The test strategy should be measured
...

18
...
Using the component-level design description as a
guide, important control paths are tested to uncover errors within the boundary of
the module
...
The unit test is white-box oriented,
and the step can be conducted in parallel for multiple components
...
3
...
4
...
The local data structure is examined to ensure that
data stored temporarily maintains its integrity during all steps in an algorithm's exeUnit Testing

cution
...
All independent paths (basis
paths) through the control structure are exercised to ensure that all statements in a
module have been executed at least once
...

Module

F I G U R E 18
...
If data do not enter and exit properly, all other tests are moot
...

Selective testing of execution paths is an essential task during the unit test
...
Basis path and loop testing are effective
techniques for uncovering a broad array of path errors
...
Comparison and control ﬂow are closely coupled to one another (i
...
, change of ﬂow frequently occurs after a comparison)
...

Good design dictates that error conditions be anticipated and error-handling paths
set up to reroute or cleanly terminate processing when an error does occur
...
Unfortunately, there is a tendency to incorporate error handling into software and then never test it
...
In one transaction processing module, a practical joker placed the following error handling message after a series
of conditional tests that invoked various control flow branches: ERROR! THERE IS NO
WAY YOU CAN GET HERE
...
If you don’t, the
path may fail when it
is invoked,
exacerbating an
already dicey situation
...
Error description is unintelligible
...
Error noted does not correspond to error encountered
...
Error condition causes system intervention prior to error handling
...
Exception-condition processing is incorrect
...
Error description does not provide enough information to assist in the location of the cause of the error
...
Software often fails at its boundaries
...
5
Unit test
environment
Driver

Interface
Local data structures
Boundary conditions
Independent paths
Error handling paths

Module
to be
tested

Stub

Stub

Test
cases
RESULTS

i passes is invoked, when the maximum or minimum allowable value is encountered
...

18
...
2 Unit Test Procedures
Unit testing is normally considered as an adjunct to the coding step
...
Select critical
modules and those
with high cyclomatic
complexity and unit
test only them
...
A review of design information provides
guidance for establishing test cases that are likely to uncover errors in each of the
categories discussed earlier
...

Because a component is not a stand-alone program, driver and/or stub software
must be developed for each unit test
...
5
...
Stubs serve to replace modules that are subordinate (called by) the
component to be tested
...

Drivers and stubs represent overhead
...
If drivers and stubs are kept simple, actual overhead is relatively
low
...
In such cases, complete testing can be postponed until the
integration test step (where drivers or stubs are also used)
...
When
only one function is addressed by a component, the number of test cases is reduced
and errors can be more easily predicted and uncovered
...
4

I N T E G R AT I O N T E S T I N G 3
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
...
Sadly, the
list goes on and on
...
The objective is to take unit tested components and build a program structure
that has been dictated by design
...

Integration testing
should be conducted
incrementally
...
All components are combined in
advance
...
And chaos usually results! A set
of errors is encountered
...
Once these errors are corrected,
new ones appear and the process continues in a seemingly endless loop
...
The program
is constructed and tested in small increments, where errors are easier to isolate and
correct; interfaces are more likely to be tested completely; and a systematic test
approach may be applied
...

18
...
1 Top-down Integration
Top-down integration testing is an incremental approach to construction of program

When you develop a
detailed project
schedule you have to
consider the manner in
which integration will
occur so that
components will be
available when
needed
...
Modules are integrated by moving downward through the control hierarchy, beginning with the main control module (main program)
...

Referring to Figure 18
...
Selection of a major path is somewhat arbitrary
and depends on application-speciﬁc characteristics
...
Next, M8 or (if neces3

Integration strategies for object-oriented systems are discussed in Chapter 23
...
6
Top-down
integration

M1

M2

M5

M3

M6

M4

M7

M8

sary for proper functioning of M2) M6 would be integrated
...
Breadth-first integration incorporates all components
directly subordinate at each level, moving across the structure horizontally
...
The next control level, M5, M6, and so on, follows
...
The main control module is used as a test driver and stubs are substituted for
all components directly subordinate to the main control module
...
Depending on the integration approach selected (i
...
, depth or breadth ﬁrst),
subordinate stubs are replaced one at a time with actual components
...
Tests are conducted as each component is integrated
...
On completion of each set of tests, another stub is replaced with the real
component
...
Regression testing (Section 18
...
3) may be conducted to ensure that new
errors have not been introduced
...

XRef
Factoring is important
for certain architectural
styles
...

The top-down integration strategy veriﬁes major control or decision points early
in the test process
...
If major control problems do exist, early recognition is essential
...
For example, consider a classic transaction structure (Chapter 14) in which a complex series
of interactive inputs is requested, acquired, and validated via an incoming path
...
All input processing (for
subsequent transaction dispatching) may be demonstrated before other elements of
the structure have been integrated
...

?

What
problems
may be
encountered when
the top-down
integration
strategy is
chosen?

Top-down strategy sounds relatively uncomplicated, but in practice, logistical problems can arise
...
Stubs replace lowlevel modules at the beginning of top-down testing; therefore, no signiﬁcant data can
ﬂow upward in the program structure
...

The ﬁrst approach (delay tests until stubs are replaced by actual modules) causes
us to loose some control over correspondence between speciﬁc tests and incorporation of speciﬁc modules
...
The
second approach is workable but can lead to signiﬁcant overhead, as stubs become
more and more complex
...

18
...
2 Bottom-up Integration
Bottom-up integration testing, as its name implies, begins construction and testing
with atomic modules (i
...
, components at the lowest levels in the program structure)
...

A bottom-up integration strategy may be implemented with the following steps:

are
? What for the
steps
bottom-up
integration?

1
...

2
...

3
...

4
...

Integration follows the pattern illustrated in Figure 18
...
Components are combined to form clusters 1, 2, and 3
...

as a dashed block)
...
Drivers
D1 and D2 are removed and the clusters are interfaced directly to Ma
...
Both Ma and
Mb will ultimately be integrated with component Mc, and so forth
...
7
Bottom-up
integration

Mc

Ma

D1

Mb

D2

D3

Cluster 3
Cluster 1

Cluster 2

As integration moves upward, the need for separate test drivers lessens
...

18
...
3 Regression Testing
Each time a new module is added as part of integration testing, the software changes
...
These changes may cause problems with functions that previously worked
ﬂawlessly
...
” Run
regression tests every
time a major change is
made to the software
(including the
integration of new
modules)
...

In a broader context, successful tests (of any kind) result in the discovery of errors,
and errors must be corrected
...
Regression testing is the activity that helps to ensure that changes (due
to testing or for other reasons) do not introduce unintended behavior or additional
errors
...
Capture/playback tools enable the
software engineer to capture test cases and results for subsequent playback and comparison
...

•

Additional tests that focus on software functions that are likely to be affected
by the change
...

As integration testing proceeds, the number of regression tests can grow quite large
...
It
is impractical and inefﬁcient to re-execute every test for every program function once
a change has occurred
...
4
...
It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess its project on a
frequent basis
...
Software components that have been translated into code are integrated into
a “build
...
The software
is rebuilt (with new
components added)
and exercised every
day
...

2
...
The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project
behind schedule
...
The build is integrated with other builds and the entire product (in its current
form) is smoke tested daily
...

The daily frequency of testing the entire product may surprise some readers
...
McConnell [MCO96] describes the smoke test in the following manner:
The smoke test should exercise the entire system from end to end
...
The smoke test should
be thorough enough that if the build passes, you can assume that it is stable enough to be
tested more thoroughly
...
Because smoke tests are conducted daily, incompatibilities and other show-stopper errors are uncovered early, thereby reducing the likelihood of serious schedule impact when errors are uncovered
...
If there's
no heartbeat, the
project is dead
...
Because the approach is construction (integration) oriented, smoke testing is likely to uncover both functional
errors and architectural and component-level design defects
...

•

Error diagnosis and correction are simpliﬁed
...

•

Progress is easier to assess
...
This improves team
morale and gives managers a good indication that progress is being made
...
4
...
g
...
In general, the advantages of one strategy tend to result in disadvantages for the other strategy
...
Problems associated with stubs may
be offset by the advantage of testing major control functions early
...
This drawback is tempered by easier test case
design and a lack of stubs
...
In general, a combined approach (sometimes called
sandwich testing) that uses top-down tests for upper levels of the program structure,
coupled with bottom-up tests for subordinate levels may be the best compromise
...
A
critical module has one or more of the following characteristics: (1) addresses several software requirements, (2) has a high level of control (resides relatively high in
the program structure), (3) is complex or error prone (cyclomatic complexity may be
used as an indicator), or (4) has deﬁnite performance requirements
...
In addition, regression tests should focus on
critical module function
...
4
...
This document contains a test plan, and a test procedure, is a work product of the software process, and becomes part of the software
conﬁguration
...
Testing is divided into
phases and builds that address speciﬁc functional and behavioral characteristics of
Test Speciﬁcation

the software
...

•

Data manipulation and analysis (symbol creation, dimensioning; rotation,
computation of physical properties)
...

•

Database management (access, update, integrity, performance)
...
Therefore, program builds (groups of modules) are
created to correspond to each phase
...
Internal and external interfaces are tested as each
module (or cluster) is incorporated into the structure
...
Tests designed to uncover functional errors are conducted
...
Tests designed to uncover errors associated with
local or global data structures are conducted
...
Tests designed to verify performance bounds established
during software design are conducted
...
Start and end dates for each phase
are established and "availability windows" for unit tested modules are deﬁned
...
Finally, test environment and resources are described
...

The detailed testing procedure that is required to accomplish the test plan is
described next
...
A listing of all test cases (annotated for subsequent reference) and
expected results is also included
...
Information contained in this section can be vital during software maintenance
...

Like all other elements of a software configuration, the test specification format
may be tailored to the local needs of a software engineering organization
...

18
...
Validation can be deﬁned in many ways,
but a simple (albeit harsh) deﬁnition is that validation succeeds when software func-

Like all other testing
steps, validation tries
to uncover errors, but
the focus is at the
requirements level—
on things that will be
immediately apparent
to the end-user
...
At this point a
battle-hardened software developer might protest: "Who or what is the arbiter of reasonable expectations?"
Reasonable expectations are deﬁned in the Software Requirements Speciﬁcation—
a document (Chapter 11) that describes all user-visible attributes of the software
...
Information contained in
that section forms the basis for a validation testing approach
...
5
...
A test plan outlines the classes of tests to be conducted
and a test procedure deﬁnes speciﬁc test cases that will be used to demonstrate conformity with requirements
...
g
...

After each validation test case has been conducted, one of two possible conditions exist: (1) The function or performance characteristics conform to speciﬁcation
and are accepted or (2) a deviation from speciﬁcation is uncovered and a deﬁciency
list is created
...
It is often necessary to negotiate with the customer to establish a method for resolving deﬁciencies
...
5
...
The intent
of the review is to ensure that all elements of the software conﬁguration have been
properly developed, are cataloged, and have the necessary detail to bolster the support phase of the software life cycle
...

18
...
3 Alpha and Beta Testing
It is virtually impossible for a software developer to foresee how the customer will
really use a program
...

When custom software is built for one customer, a series of acceptance tests are
conducted to enable the customer to validate all requirements
...
In fact, acceptance testing can be conducted over a period of weeks or months, thereby uncovering cumulative errors that might degrade the system over time
...
Most software product builders
use a process called alpha and beta testing to uncover errors that only the end-user
seems able to ﬁnd
...
The software is
used in a natural setting with the developer "looking over the shoulder" of the user
and recording errors and usage problems
...

The beta test is conducted at one or more customer sites by the end-user of the
software
...
Therefore, the
beta test is a "live" application of the software in an environment that cannot be controlled by the developer
...
As a result of problems reported during beta tests, software engineers make
modiﬁcations and then prepare for release of the software product to the entire customer base
...
6

SYSTEM TESTING
At the beginning of this book, we stressed the fact that software is only one element
of a larger computer-based system
...
g
...
These tests fall outside the scope of the

CHAPTER 18

S O F T WA R E T E S T I N G S T R AT E G I E S

497

software process and are not conducted solely by software engineers
...

A classic system testing problem is "ﬁnger-pointing
...

Rather than indulging in such nonsense, the software engineer should anticipate

“Like death and
taxes, testing is both
unpleasant and
inevitable
...

System testing is actually a series of different tests whose primary purpose is to
fully exercise the computer-based system
...
In the sections that follow, we discuss the types of system tests
[BEI84] that are worthwhile for software-based systems
...
6
...
In some cases, a system must be fault tolerant; that is, processing faults must not cause overall system function to cease
...
stqe
...

Recovery testing is a system test that forces the software to fail in a variety of ways
and veriﬁes that recovery is properly performed
...
If recovery requires human intervention, the
mean-time-to-repair (MTTR) is evaluated to determine whether it is within acceptable limits
...
6
...
Penetration spans a broad range of activities: hackers who attempt to
penetrate systems for sport; disgruntled employees who attempt to penetrate for
revenge; dishonest individuals who attempt to penetrate for illicit personal gain
...
To quote Beizer [BEI84]: "The system's security must, of course, be tested for invulnerability from frontal attack—but
must also be tested for invulnerability from ﬂank or rear attack
...
Anything goes! The tester may attempt to acquire passwords

498

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

through external clerical means; may attack the system with custom software designed
to breakdown any defenses that have been constructed; may overwhelm the system,
thereby denying service to others; may purposely cause system errors, hoping to penetrate during recovery; may browse through insecure data, hoping to ﬁnd the key to
system entry
...
The role of the system designer is to make penetration cost more than the
value of the information that will be obtained
...
6
...
Stress tests
are designed to confront programs with abnormal situations
...
”
Boris Beizer

Stress testing executes a system in a manner that demands resources in abnormal
quantity, frequency, or volume
...
Essentially, the tester attempts to break the program
...
In some situations (the most common occur in mathematical algorithms), a very small range of
data contained within the bounds of valid data for a program may cause extreme and
even erroneous processing or profound performance degradation
...

18
...
4 Performance Testing
For real-time and embedded systems, software that provides required function but
does not conform to performance requirements is unacceptable
...
Performance testing occurs throughout all steps in the testing
process
...
However, it is not until all system elements are fully integrated that the true performance of a system can be ascertained
...
That is, it is often necessary to measure
resource utilization (e
...
, processor cycles) in an exacting fashion
...
8
The debugging
process

Test
cases

Execution
of cases
Additional
tests

Suspected
causes

Results

Regression
tests
Corrections

Identified
causes

Debugging

mentation can monitor execution intervals, log events (e
...
, interrupts) as they occur,
and sample machine states on a regular basis
...

18
...
Test
case design can be conducted, a strategy can be deﬁned, and results can be evaluated against prescribed expectations
...
bugnet
...
That is, when a test case
uncovers an error, debugging is the process that results in the removal of the error
...

A software engineer, evaluating the results of a test, is often confronted with a "symptomatic" indication of a software problem
...
The poorly understood mental process that connects a symptom to a cause
is debugging
...
7
...
4 Referring
to Figure 18
...
Results
are assessed and a lack of correspondence between expected and actual performance is encountered
...
Not only does the developer test software prior to release, but the customer/user tests software every time it is used!

500

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

of an underlying cause as yet hidden
...

The debugging process will always have one of two outcomes: (1) the cause will
be found and corrected, or (2) the cause will not be found
...

Why is debugging so difﬁcult? In all likelihood, human psychology (see the next
section) has more to do with an answer than software technology
...
The symptom and the cause may be geographically remote
...
Highly coupled program structures
(Chapter 13) exacerbate this situation
...
”
John Gould

2
...

3
...
g
...

4
...

5
...

6
...
g
...

7
...
This is particularly common in embedded
systems that couple hardware and software inextricably
...
The symptom may be due to causes that are distributed across a number of
tasks running on different processors [CHE90]
...
g
...
g
...
As the consequences of an error increase, the amount
of pressure to ﬁnd the cause also increases
...

18
...
2 Psychological Considerations
Unfortunately, there appears to be some evidence that debugging prowess is an innate
human trait
...
Although experimental
evidence on debugging is open to many interpretations, large variances in debugging ability have been reported for programmers with the same education and experience
...
It has elements of problem
solving or brain teasers, coupled with the annoying recognition that you have made a mistake
...
Fortunately, there is a great sigh of relief and a lessening of tension when
the bug is ultimately
...

Although it may be difﬁcult to "learn" debugging, a number of approaches to the problem can be proposed
...

18
...
3 Debugging Approaches
Regardless of the approach that is taken, debugging has one overriding objective: to
ﬁnd and correct the cause of a software error
...
Bradley [BRA85] describes the
debugging approach in this way:
Debugging is a straightforward application of the scientific method that has been developed over 2,500 years
...

Take a simple non-software example: A lamp in my house does not work
...
I plug the suspect lamp into a working socket
and a working appliance into the suspect circuit
...

In general, three categories for debugging approaches may be proposed [MYE79]:
(1) brute force, (2) backtracking, and (3) cause elimination
...
After that, get
help!

cient method for isolating the cause of a software error
...
Using a "let the computer ﬁnd the error" philosophy,
memory dumps are taken, run-time traces are invoked, and the program is loaded
with WRITE statements
...
Although the
mass of information produced may ultimately lead to success, it more frequently leads
to wasted effort and time
...
Beginning at the site where a symptom has been uncovered,
the source code is traced backward (manually) until the site of the cause is found
...

The third approach to debugging—cause elimination—is manifested by induction
or deduction and introduces the concept of binary partitioning
...
A "cause hypothesis" is

502

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

devised and the aforementioned data are used to prove or disprove the hypothesis
...
If initial tests indicate that a particular cause hypothesis shows promise,
data are reﬁned in an attempt to isolate the bug
...

We can apply a wide variety of debugging compilers, dynamic debugging aids ("tracers"), automatic test case generators, memory dumps, and cross-reference maps
...

Any discussion of debugging approaches and tools is incomplete without mention
of a powerful ally—other people! Each of us can recall puzzling for hours or days over
a persistent bug
...
Instantaneously (it seems), the cause of the error is uncovered
...
A fresh viewpoint, unclouded by
hours of frustration, can do wonders
...
But, as we have already noted,
the correction of a bug can introduce other errors and therefore do more harm than
good
...
Is the cause of the bug reproduced in another part of the program?
In many situations, a program defect is caused by an erroneous pattern of
logic that may be reproduced elsewhere
...

2
...
If the correction
is to be made in a highly coupled section of the program, special care must
be taken when any change is made
...
What could we have done to prevent this bug in the ﬁrst place? This
question is the ﬁrst step toward establishing a statistical software quality
assurance approach (Chapter 8)
...

18
...
Yet we are only beginning to understand the subtleties of systematic
test planning, execution, and control
...
To fulfill this objective, a
series of test steps—unit, integration, validation, and system tests—are planned and
executed
...
Validation testing demonstrates traceability to software requirements, and system testing validates
software once it has been incorporated into a larger system
...
With each testing step, the level of abstraction with
which software is considered is broadened
...
Beginning with a symptomatic indication of a problem, the debugging activity
must track down the cause of an error
...

The requirement for higher-quality software demands a more systematic approach
to testing
...

In this chapter, we have examined the strategic test space, considering the steps that
have the highest likelihood of meeting the overriding test objective: to ﬁnd and remove
errors in an orderly and effective manner
...
, Software System Testing and Quality Assurance, Van Nostrand-

Reinhold, 1984
...
, Software Engineering Economics, Prentice-Hall, 1981, p
...

[BRA85] Bradley, J
...
, "The Science and Art of Debugging," Computerworld, August
19, 1985, pp
...

[CHE90] Cheung, W
...
, J
...
Black, and E
...
106–115
...
and R
...
158
...
, “What We Fail to Do in Our Current Testing Culture,” Testing

Techniques Newsletter, (on-line edition, ttn@soft
...

[MCO96] McConnell, S
...
13, no
...

[MIL77] Miller, E
...
1–3
...
D
...
F
...
19 –27
...
, The Art of Software Testing, Wiley, 1979
...
L
...

[SHN80] Shneiderman, B
...
28
...
, "Three Questions About Each Bug You Find," ACM Software
Engineering Notes, vol
...
5, July 1989, pp
...

[WAL89] Wallace, D
...
and R
...
Fujii, "Software Verification and Validation: An
Overview," IEEE Software, May 1989, pp
...

[YOU75] Yourdon, E
...

PROBLEMS AND POINTS TO PONDER
18
...
Using your own words, describe the difference between veriﬁcation and validation
...
2
...
Are an ITG and an SQA group made up of the same people?
18
...
Is it always possible to develop a strategy for testing software that uses the
sequence of testing steps described in Section 18
...
3? What possible complications
might arise for embedded systems?
18
...
If you could select only three test case design methods to apply during unit
testing, what would they be and why?
18
...
Why is a highly coupled module difﬁcult to unit test?
18
...
The concept of "antibugging" (Section 18
...
1) is an extremely effective way to
provide built-in debugging assistance when an error is uncovered:
a
...

b
...

c
...

18
...
Develop an integration testing strategy for the any one of the systems implemented in Problems 16
...
11
...
Assume
that all modules (or classes) have been unit tested and are available
...

18
...
How can project scheduling affect integration testing?
18
...
Is unit testing possible or even desirable in all circumstances? Provide examples to justify your answer
...
10
...

CHAPTER 18

S O F T WA R E T E S T I N G S T R AT E G I E S

505

18
...
Develop a complete test strategy for the SafeHome system discussed earlier
in this book
...

18
...
As a class project, develop a Debugging Guide for your installation
...
Publish the guide for others in your local environment
...

Kaner, Nguyen, and Falk (Testing Computer Software, Wiley, 1999); Hutcheson (Software Testing Methods and Metrics: The Most Important Tests McGraw-Hill, 1997); Marick (The Craft of Software Testing: Subsystem Testing Including Object-Based and
Object-Oriented Testing, Prentice-Hall, 1995); Jorgensen (Software Testing: A Craftsman's Approach, CRC Press, 1995) present treatments of the subject that consider
testing methods and strategies
...
(Testing Computer Software, 2nd ed
...

Hutcheson (Software Testing Methods and Metrics, McGraw-Hill, 1996) presents testing methods and strategies but also provides a detailed discussion of how measurement can be used to achieve efﬁcient testing
...
Beizer [BEI84] presents an interesting "taxonomy of bugs" that
can lead to effective methods for test planning
...

A wide variety of information sources on software testing and related subjects is
available on the Internet
...
mhhe
...
mhtml

CHAPTER

19
KEY
CONCEPTS
analysis metrics 517
architectural
metrics
...
526
design metrics
...
533
measurement
principles
...
We use measures to better understand the attributes of the models that we create
and to assess the quality of the engineered products or systems that
we build
...
Absolute measures, such as
voltage, mass, velocity, or temperature, are uncommon in the software world
...

Because software measures and metrics are not absolute, they are open to
debate
...
516

butes of entities in the real world in such a way as to deﬁne them according to clearly

quality factors
...
522

to be unmeasurable
...
531

are made based on them]
...
532

deﬁned rules
...
, but they exist [and important decisions
unmeasurable” in order to improve our understanding of particular entities is as powerful in software engineering as in any discipline
...
The

pline
...

built
...
Technical metrics help software engi-

conducted more objectively and assessed more

QUICK
LOOK

neers gain insight into the design and construction of the products they build
...

quantitatively
...

tative element to the creation of computer soft-

Next, data required to derive the formulated met-

ware
...
Once computed, appropriate

may not be enough
...
The

and design models, source code, and test cases
...
Deﬁne only

arising out of analysis, design, code, or test
...

But some members of the software community continue to argue that software is
unmeasurable or that attempts at measurement should be postponed until we better understand software and the attributes that should be used to describe it
...

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 defined rules
...
This enables the engineer to discover and correct potential problems before
they become catastrophic defects
...
In this chapter, our focus shifts to measures that can be used to assess
the quality of the product as it is being engineered
...

19
...
But how do we deﬁne quality? In Chapter 8, we proposed a number
of different ways to look at software quality and introduced a deﬁnition that stressed
conformance to explicitly stated functional and performance requirements, explic-

“Every program does
something right, it
just may not be the
thing that we want
it to do
...

There is little question that the preceding deﬁnition could be modiﬁed or extended
and debated endlessly
...
Software requirements are the foundation from which quality is measured
...
1
1

It is important to note that quality extends to the technical attributes of the analysis, design, and
code models
...

CHAPTER 19

509

T E C H N I C A L M E T R I C S F O R S O F T WA R E

2
...
If the criteria are not followed, lack of
quality will almost surely result
...
There is a set of implicit requirements that often goes unmentioned (e
...
, the
desire for ease of use)
...

Software quality is a complex mix of factors that will vary across different applications and the customers who request them
...

19
...
1 McCall’s Quality Factors
The factors that affect software quality can be categorized in two broad groups:
(1) factors that can be directly measured (e
...
, defects per function-point) and (2) fac-

It’s interesting to note
that McCall’s quality
factors are as valid
today as they were
when they were ﬁrst
proposed in the
1970s
...

tors that can be measured only indirectly (e
...
, usability or maintainability)
...
We must compare the software (documents, programs, data) to some datum and arrive at an indication of quality
...
These software quality factors, shown in
Figure 19
...

Referring to the factors noted in Figure 19
...
The extent to which a program satisfies its specification and fulfills the customer's mission objectives
...
The extent to which a program can be expected to perform its intended function
with required precision
...
]

Maintainability
Flexibility
Testability

Portability
Reusability
Interoperability

PRODUCT REVISION

F I G U R E 19
...
The amount of computing resources and code required by a program to perform
its function
...
Extent to which access to software or data by unauthorized persons can be
controlled
...
Effort required to learn, operate, prepare input, and interpret output of a program
...
”
Tom DeMarco

Maintainability
...
[This is a very limited deﬁnition
...
Effort required to modify an operational program
...
Effort required to test a program to ensure that it performs its intended function
...
Effort required to transfer the program from one hardware and/or software system environment to another
...
Extent to which a program [or parts of a program] can be reused in other
applications—related to the packaging and scope of the functions that the program
performs
...
Effort required to couple one system to another
...
Therefore, a set of metrics are deﬁned and used to develop expressions for each of the factors according to the following relationship:
Fq = c1 ϫ m1 + c2 ϫ m2 +
...
Unfortunately, many of the metrics deﬁned by McCall
et al
...
The metrics may be in the form of a checklist that is used to "grade" specific attributes of the software [CAV78]
...
is a 0 (low) to 10 (high) scale
...
The ease with which conformance to standards can be checked
...
The precision of computations and control
...
The degree to which standard interfaces, protocols, and bandwidth are used
...
The degree to which full implementation of required function
XRef
The metrics noted can
be assessed during
formal technical
reviews discussed in
Chapter 8
...

Conciseness
...

Consistency
...

Data commonality
...

CHAPTER 19

T E C H N I C A L M E T R I C S F O R S O F T WA R E

511

Error tolerance
...

Execution efﬁciency
...

Expandability
...

Generality
...

Hardware independence
...

Instrumentation
...

Modularity
...

Operability
...

Quality Factors

Security
...

Self-documentation
...

Simplicity
...

Software system independence
...

Traceability
...

Training
...

The relationship between software quality factors and these metrics is shown in
Figure 19
...
It should be noted that the weight given to each metric is dependent on
local products and concerns
...
1
...
Hewlett-Packard [GRA87]
developed a set of software quality factors that has been given the acronym FURPS—

Auditability
Accuracy
Communication
commonality
Completeness
Complexity
Concision
Consistency
Data commonality
Error tolerance
Execution efficiency
Expandability
Generality
Hardware Indep
...

Traceability
Training

x

Usability

Interoperability

Reusability

Portability

Testability

Flexibility

Maintainability

Quality
factor

Integrity

Software
quality
metric

Efficiency

F I G U R E 19
...
A
...
)

functionality, usability, reliability, performance, and supportability
...

•

Usability is assessed by considering human factors (Chapter 15), overall aesthetics, consistency, and documentation
...

•

Performance is measured by processing speed, response time, resource consumption, throughput, and efﬁciency
...

The FURPS quality factors and attributes just described can be used to establish
quality metrics for each step in the software engineering process
...
1
...
The standard identiﬁes six key quality attributes:
Functionality
...

Reliability
...

“Any activity becomes
creative when the
doer cares about
doing it right, or
better
...
The degree to which the software is easy to use as indicated by the
following subattributes: understandability, learnability, operability
...
The degree to which the software makes optimal use of system
resources as indicated by the following subattributes: time behavior, resource
behavior
...
The ease with which repair may be made to the software as
indicated by the following subattributes: analyzability, changeability, stability,
testability
...
The ease with which the software can be transposed from one
environment to another as indicated by the following subattributes: adaptability, installability, conformance, replaceability
...
1
...
1
...
However,
they do provide a worthwhile basis for indirect measures and an excellent checklist
for assessing the quality of a system
...
1
...
We strive to develop precise measures for software quality and are sometimes frustrated by the subjective nature of the activity
...
g
...
In these situations, quality is judged
in the most fundamental and direct manner: side by side comparison of objects under identical conditions and with predetermined concepts
...
However, this type of judgement is very subjective; to have
any value at all, it must be made by an expert
...
To help solve
this problem, a more precise deﬁnition of software quality is needed as well as a way to
derive quantitative measurements of software quality for objective analysis
...
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 ﬁneness
...
"

In the sections that follow, we examine a set of software metrics that can be applied
to the quantitative assessment of software quality
...
The complicating factor is the precise relationship between the
variable that is measured and the quality of software
...
2

A F R A M E W O R K F O R T E C H N I C A L S O F T WA R E M E T R I C S
As we noted in the introduction to this chapter, measurement assigns numbers or
symbols to attributes of entities in the real word
...
Although the theory of measurement (e
...
, [KYB84]) and its application to computer software (e
...
, [DEM81],
[BRI96], [ZUS97]) are topics that are beyond the scope of this book, it is worthwhile

“Just as temperature
measurement began
with an index ﬁnger

...
”
Shari Pﬂeeger

to establish a fundamental framework and a set of basic principles for the measurement of technical metrics for software
...
2
...
Fenton [FEN94]
characterizes this research as a search for “the impossible holy grail
...
By analogy, consider a metric for evaluating an attractive car
...
Since any one of these characteristics may be at odds with others,
it is difﬁcult to derive a single value for “attractiveness
...

CHAPTER 19

T E C H N I C A L M E T R I C S F O R S O F T WA R E

515

Yet there is a need to measure and control software complexity
...
g
...
cs
...
de/
~zuse/

independence, and other attributes discussed in Chapters 13 through 16)
...
But here again, problems arise
...
This is counter to the representational theory of measurement
...

It is fair to ask, however, just how valid technical metrics are
...
There are a number of reasons why this is so; the most commonly cited is the impracticality of conducting relevant
experiments
...
2 Measurement is essential if quality is to be achieved
...
2
...
Roche [ROC94]
suggests a measurement process that can be characterized by ﬁve activities:
•

? What are of
the steps

Formulation
...

an effective
measurement
process?

•

Collection
...

•
2

Analysis
...

A vast literature on software metrics (e
...
, see [FEN94], [ROC94], [ZUS97] for extensive bibliographies) has been spawned, and criticism of speciﬁc metrics (including some of those presented in
this chapter) is common
...

516

PA R T T H R E E

•

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Interpretation
...

•

Feedback
...

The principles that can be associated with the formulation of technical metrics are
[ROC94]

? What rules
should we

•

The objectives of measurement should be established before data collection

observe when we
establish technical
measures?

•

Each technical metric should be deﬁned in an unambiguous manner
...

application (e
...
, metrics for design should draw upon basic design concepts
and principles and attempt to provide an indication of the presence of an
attribute that is deemed desirable)
...

Although formulation is a critical starting point, collection and analysis are the activities that drive the measurement process
...
Don’t obsess
over the “perfect”
metric because it
doesn’t exist
...

•

Valid statistical techniques should be applied to establish relationships
between internal product attributes and external quality characteristics (e
...
,
is the level of architectural complexity correlated with the number of defects
reported in production use?)
...

In addition to these principles, the success of a metrics activity is tied to management
support
...

19
...
3 The Attributes of Effective Software Metrics
Hundreds of metrics have been proposed for computer software, but not all provide
practical support to the software engineer
...

Ejiogu [EJI91] deﬁnes a set of attributes that should be encompassed by effective
software metrics
...
It should be relatively easy to learn how to derive the
metric, and its computation should not demand inordinate effort or time
...
The metric should satisfy the engineer’s
intuitive notions about the product attribute under consideration (e
...
, a metric that measures module cohesion should increase in value as the level of
cohesion increases)
...
The metric should always yield results that are
unambiguous
...

•

Consistent in its use of units and dimensions
...
If dozens of
“counts” have to be
made and complex
computations are
required, it’s unlikely
that the metric will be
widely applied
...
For example, multiplying people on the project teams by programming language variables in the program results in a suspicious mix of units
that are not intuitively persuasive
...
Metrics should be based on the analysis
model, the design model, or the structure of the program itself
...

•

An effective mechanism for high-quality feedback
...

Although most software metrics satisfy these attributes, some commonly used metrics may fail to satisfy one or two of them
...
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 same information about the
software
...

19
...

M E T R I C S F O R T H E A N A LY S I S M O D E L
Technical work in software engineering begins with the creation of the analysis model
...
Therefore, technical metrics that provide insight into the quality of the
analysis model are desirable
...
Such is the nature of software metrics
...
3
Part of the
analysis model
for SafeHome
software

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Sensors

Test sensor
Password

Zone setting

Zone inquiry
User

SafeHome
user
interaction
function

Sensor inquiry
Panic button

Messages
User
Sensor status

Activate/deactivate

Activate/deactivate
Password, sensors
...
These metrics examine the analysis model with the intent of
predicting the “size” of the resultant system
...

19
...
1 Function-Based Metrics
The function point metric (Chapter 4) can be used effectively as a means for predicting the size of a system that will be derived from the analysis model
...
g
...

tation, illustrated in Figure 19
...
Referring to the ﬁgure, a data ﬂow diagram (Chapter 12) for a function within the SafeHome software4 is represented
...
The function displays a series of prompting messages and sends appropriate
control signals to various components of the security system
...

CHAPTER 19

519

T E C H N I C A L M E T R I C S F O R S O F T WA R E

Weighting Factor
Measurement parameter

Count

Simple

Average

Complex

Number of user inputs

3

×

3

4

6

=

9

Number of user outputs

2

×

4

5

7

=

8

Number of user inquiries

2

×

3

4

6

=

6

Number of files

1

×

7

10

15

=

7

Number of external interfaces

4

×

5

7

10

=

20

Count total

50

F I G U R E 19
...
One ﬁle
(system conﬁguration ﬁle) is shown
...
These data, along with the appropriate complexity, are shown in Figure 19
...

The count total shown in Figure 19
...
spr
...
htm

FP = count total ϫ [0
...
01 ϫ ⌺ (Fi)]
where count total is the sum of all FP entries obtained from Figure 19
...
" For the purposes of this example, we
assume that ⌺ (Fi) is 46 (a moderately complex product)
...
65 + (0
...

Assume that past data indicates that one FP translates into 60 lines of code (an objectoriented language is to be used) and that 12 FPs are produced for each person-month
of effort
...

Assume further that past projects have found an average of three errors per function
point during analysis and design reviews and four errors per function point during
unit and integration testing
...

520

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

19
...
2 The Bang Metric
Like the function point metric, the bang metric can be used to develop an indication
of the size of the software to be implemented as a consequence of the analysis model
...
” To compute the bang metric, the software engineer
must ﬁrst evaluate a set of primitives—elements of the analysis model that are not
further subdivided at the analysis level
...
The number of transformations (bubbles) that
appear at the lowest level of a data ﬂow diagram (Chapter 12)
...
we should
also be asking
ourselves the more
basic question,
‘What will we do
with metrics
...
The number of attributes of a data object, data elements are not composite data and appear within the data dictionary
...
The number of data objects as described in Chapter 12
...
The number of connections between data objects as
described in Chapter 12
...
The number of user observable states in the state transition dia-

Michael Mah and
Larry Putnam

gram (Chapter 12)
...
The number of state transitions in the state transition diagram (Chapter 12)
...
Functions that lie outside
the system boundary but must be modiﬁed to accommodate the new system
...
Those data elements that are input to the system
...
(DEO)
...

Retained data elements
...
Those data elements that are retained
(stored) by the system
...
The data tokens (data items that are not subdivided
within a functional primitive) that exist at the boundary of the ith functional
primitive (evaluated for each primitive)
...
The relationships that connect the ith
object in the data model to other objects
...
Function-strong

5

The acronym noted in parentheses following the primitive is used to denote the count of the particular primitive, e,g
...

CHAPTER 19

T E C H N I C A L M E T R I C S F O R S O F T WA R E

521

applications (often encountered in engineering and scientiﬁc applications) emphasize the transformation of data and do not generally have complex data structures
...

RE/FuP < 0
...

0
...
4 implies a hybrid application
...
5 implies a data-strong application
...

To compute the bang metric for function-strong applications, the following algorithm is used:
set initial value of bang = 0;
do while functional primitives remain to be evaluated
Compute token-count around the boundary of primitive i
Compute corrected FuP increment (CFuPI)
Allocate primitive to class
Assess class and note assessed weight
Multiply CFuPI by the assessed weight
bang = bang + weighted CFuPI
enddo

The token-count is computed by determining how many separate tokens are “visible” [DEM82] within the primitive
...
The corrected CFuPI is determined from a
table published by DeMarco
...
0

5

5
...
6

15

29
...
2

The assessed weight noted in the algorithm is determined from 16 different classes
of functional primitives deﬁned by DeMarco
...
6 (simple data
routing) to 2
...

For data-strong applications, the bang metric is computed using the following
algorithm:

522

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

set initial value of bang = 0;
do while objects remain to be evaluated in the data model
compute count of relationships for object i
compute corrected OB increment (COBI)
bang = bang + COBI
enddo

The COBI is determined from a table published by DeMarco
...
0

3

4
...
0

Once the bang metric has been computed, past history can be used to associate it
with size and effort
...

19
...
3 Metrics for Speciﬁcation Quality
Davis and his colleagues [DAV93] propose a list of characteristics that can be used
to assess the quality of the analysis model and the corresponding requirements speciﬁcation: speciﬁcity (lack of ambiguity), completeness, correctness, understandability,
veriﬁability, internal and external consistency, achievability, concision, traceability, mod-

By measuring
characteristics of the
speciﬁcation, it is
possible to gain
quantitative insight
into speciﬁcity and
completeness
...
In addition, the authors note that high-quality speciﬁcations are electronically stored, executable or at least interpretable, annotated by
relative importance and stable, versioned, organized, cross-referenced, and speciﬁed at the right level of detail
...
[DAV93] suggest that each can be represented using one or more metrics
...
g
...

To determine the speciﬁcity (lack of ambiguity) of requirements, Davis et al
...
See
[DAV93] for more details
...
The closer the value of Q to 1, the lower is the ambiguity of the
speciﬁcation
...
The Q2 ratio measures the percentage of necessary functions that have been
speciﬁed for a system
...
To
incorporate these into an overall metric for completeness, we must consider the
degree to which requirements have been validated:
Q3 = nc/[nc + nnv]
where nc is the number of requirements that have been validated as correct and nnv
is the number of requirements that have not yet been validated
...
4

METRICS FOR THE DESIGN MODEL
It is inconceivable that the design of a new aircraft, a new computer chip, or a new
ofﬁce building would be conducted without deﬁning design measures, determining
metrics for various aspects of design quality, and using them to guide the manner in

“Measure what is
measurable, and
what is not
measurable, make
measurable
...
And yet, the design of complex software-based systems
often proceeds with virtually no measurement
...

Design metrics for computer software, like all other software metrics, are not perfect
...
Many experts argue that further experimentation is required before design
measures can be used
...

In the sections that follow, we examine some of the more common design metrics for computer software
...

19
...
1 Architectural Design Metrics
Architectural design metrics focus on characteristics of the program architecture
(Chapter 14) with an emphasis on the architectural structure and the effectiveness of
modules
...

524

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Card and Glass [CAR90] deﬁne three software design complexity measures: structural complexity, data complexity, and system complexity
...

Data complexity provides an indication of the complexity in the internal interface

Metrics can provide
insight into structural,
data and system
complexity associated
with the architectural
design
...

Finally, system complexity is deﬁned as the sum of structural and data complexity,
speciﬁed as
C(i) = S(i) + D(i)

(19-3)

As each of these complexity values increases, the overall architectural complexity of
the system also increases
...

? Is there a
way to
assess the
complexity of
certain
architectural
models?

An earlier high-level architectural design metric proposed by Henry and Kafura
[HEN81] also makes use the fan-in and fan-out
...
Henry and Kafura extend the deﬁnitions of fanin and fan-out presented in this book to include not only the number of module control connections (module calls) but also the number of data structures from which a
module i retrieves (fan-in) or updates (fan-out) data
...
Like the Card and Glass metrics noted previously, an increase
in the Henry-Kafura metric leads to a greater likelihood that integration and testing
effort will also increase for a module
...
e
...
Referring to Figure 19
...

CHAPTER 19

525

T E C H N I C A L M E T R I C S F O R S O F T WA R E

Node

a

Arc

c

d

e

i

b

j

k

l

p

q

r

Depth

f

g

n

m

h

Width
F I G U R E 19
...
For the architecture
shown in Figure 19
...
For the architecture shown in Figure 19
...

width = maximum number of nodes at any one level of the architecture
...
5, width = 6
...
For the architecture shown in Figure 19
...
06
...
S
...
Using concepts similar to those proposed in IEEE Std
...
1-1988
[IEE94], the Air Force uses information obtained from data and architectural design
to derive a design structure quality index (DSQI) that ranges from 0 to 1
...

S2 =

the number of modules whose correct function depends on the source of
data input or that produce data to be used elsewhere (in general, control
modules, among others, would not be counted as part of S2)
...

S4 =

the number of database items (includes data objects and all attributes that
deﬁne objects)
...

S7 =

“Measurement can
be seen as a detour
...
”

the total number of unique database items
...

Once values S1 through S7 are determined for a computer program, the following
intermediate values can be computed:
Program structure: D1, where D1 is deﬁned as follows: If the architectural
design was developed using a distinct method (e
...
, data ﬂow-oriented
design or object-oriented design), then D1 = 1, otherwise D1 = 0
...
167)
...
If the DSQI is significantly lower than average, further design work and review are indicated
...

19
...
2 Component-Level Design Metrics
Component-level design metrics focus on internal characteristics of a software component and include measures of the “three Cs”—module cohesion, coupling, and complexity
...

The metrics presented in this section are glass box in the sense that they require
knowledge of the inner working of the module under consideration
...
Alternatively, they may be delayed until source code is available
...
Bieman and Ott [BIE94] deﬁne a collection of metrics that pro-

It is possible to
compute measures of
the functional
independence—
coupling and
cohesion—of a
component and to use
these to assess the
quality of the design
...
The metrics are
deﬁned in terms of ﬁve concepts and measures:
Data slice
...
It should be noted that both program slices (which focus on statements and conditions) and data slices can be deﬁned
...
The variables deﬁned for a module can be deﬁned as data
tokens for the module
...
This set of data tokens lies on one or more data slice
...
These data tokens are common to every data slice in a
module
...
The relative stickiness of a glue token is directly proportional to
the number of data slices that it binds
...
These metrics can be interpreted in the following manner [BIE94]:
All of these cohesion metrics range in value between 0 and 1
...
A procedure with no superglue tokens, no tokens that are common
to all data slices, has zero strong functional cohesion—there are no data tokens that contribute to all outputs
...

Strong functional cohesion and adhesiveness are encountered when the Bieman and
Ott metrics take on a maximum value of 1
...
However, to illustrate the character of these metrics, consider the metric for
strong functional cohesion:
SFC(i) = SG [SA(i))/(tokens(i)]

(19-6)

where SG[SA(i)] denotes superglue tokens—the set of data tokens that lie on all data
slices for a module i
...

528

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

Coupling metrics
...
In Chapter
13, coupling was discussed in qualitative terms
...
The
measures required to compute module coupling are deﬁned in terms of each of the
three coupling types noted previously
...
isse
...
edu/
faculty/ofut/rsrch/
abstracts/
mj-coupling
...

The higher the value of mc, the lower is the overall module coupling
...
33
We would expect that such a module exhibits low coupling
...
33 implies low coupling
...
02
and the implied coupling would be high
...

CHAPTER 19

T E C H N I C A L M E T R I C S F O R S O F T WA R E

529

In order to have the coupling metric move upward as the degree of coupling
increases (an important attribute discussed in Section 18
...
3), a revised coupling metric may be deﬁned as
C = 1 Ϫ mc
where the degree of coupling increases nonlinearly between a minimum value in the
range 0
...
0
...
A variety of software metrics can be computed to determine
the complexity of program control ﬂow
...

As we discussed in Chapter 17, a graph is a representation composed of nodes and
links (also called edges)
...

McCabe and Watson [MCC94] identify a number of important uses for complexity
metrics:
Complexity metrics can be used to predict critical information about reliability and
maintainability of software systems from automatic analysis of source code [or procedural design information]
...
During testing and maintenance, they
provide detailed information about software modules to help pinpoint areas of potential instability
...
4
...

Cyclomatic complexity
is only one of a large
number of complexity
metrics
...
Experimental studies indicate distinct relationships
between the McCabe metric and the number of errors existing in source code, as well
as time required to ﬁnd and correct such errors
...
Collecting data from a number of actual
programming projects, he has found that cyclomatic complexity = 10 appears to be
a practical upper limit for module size
...
See
Chapter 17 for a discussion of cyclomatic complexity as a guide for the design of
white-box test cases
...
The author presents the basic
deﬁnitions for metrics in each category (e
...
, there are a number of variations on the
cyclomatic complexity metric) and then analyzes and critiques each
...

530

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

19
...
3 Interface Design Metrics
Although there is signiﬁcant literature on the design of human/computer interfaces
(see Chapter 15), relatively little information has been published on metrics that would
provide insight into the quality and usability of the interface
...
A typical GUI uses layout entities—graphic
icons, text, menus, windows, and the like—to assist the user in completing tasks
...
The absolute and relative position of each layout entity, the frequency with
which it is used, and the “cost” of the transition from one layout entity to the next all
contribute to the appropriateness of the interface
...
e
...
”
Leon Alberti
(1404–1472)

sequence of actions according to the following relationship:
cost = ⌺ [frequency of transition(k) ϫ cost of transition(k)]

(19-7)

where k is a speciﬁc transition from one layout entity to the next as a speciﬁc task is
accomplished
...
Cost may be characterized in terms of time, processing delay, or any other reasonable value, such as the
distance that a mouse must travel between layout entities
...

To compute the optimal layout for a GUI, interface real estate (the area of the
screen) is divided into a grid
...
For a grid with N possible positions and K different layout entities
to place, the number of possible layouts is represented in the following manner
[SEA93]:
number of possible layouts = [N!/(K! ϫ (N Ϫ K)!] ϫ K!

(19-9)

As the number of layout positions increases, the number of possible layouts grows

Interface design
metrics are ﬁne, but
above all else, be
absolutely sure that
your end-users like the
interface and are
comfortable with the
interactions required
...
To find the optimal (lowest cost) layout, Sears [SEA93] proposes a tree
searching algorithm
...
e
...
The interface designer can use the change in layout appropriateness,
∆LA, as a guide in choosing the best GUI layout for a particular application
...

Nielsen and Levy [NIE94] report that “one has a reasonably large chance of suc-

CHAPTER 19

T E C H N I C A L M E T R I C S F O R S O F T WA R E

531

cess if one chooses between interface [designs] based solely on users’ opinions
...
”

19
...
composite measures of (software) complexity" [CUR80]
...
”

ware science proposed the ﬁrst analytical "laws" for computer software
...
These follow:
n1 = the number of distinct operators that appear in a program
...

N1 = the total number of operator occurrences
...

Halstead uses these primitive measures to develop expressions for the overall program length, potential minimum volume for an algorithm, the actual volume (number
of bits required to specify a program), the program level (a measure of software complexity), the language level (a constant for a given language), and other features such
as development effort, development time, and even the projected number of faults
in the software
...
Operands
encompass all program
variables and
constants
...

Theoretically, a minimum volume must exist for a particular algorithm
...
In actuality, L must always be less than 1
...
However, experimental veriﬁcation of Halstead's ﬁndings have been made for a number of programming languages (e
...
, [FEL89])
...
A discussion of this
work is beyond the scope of this text, but it can be said that good agreement has been
found between analytically predicted and experimental results
...

19
...
g
...
In general, testers must rely on analysis, design,
and code metrics to guide them in the design and execution of test cases
...
3
...

ing effort
...
g
...
The team can then project “expected values” of these characteristics for the current project
...
3
...
The number of functional primitives (FuP), data elements (DE), objects (OB), relationships (RE), states
(ST), and transitions (TR) can be used to project the number and types of black-box
and white-box tests for the software
...

Architectural design metrics provide information on the ease or difﬁculty associated
with integration testing (Chapter 18) and the need for specialized testing software (e
...
,
stubs and drivers)
...
In
addition, cyclomatic complexity can be used to target modules as candidates for extensive unit testing (Chapter 18)
...
For this reason, the tester should expend above average effort to uncover errors in such modules
before they are integrated in a system
...
5)
...

As tests are conducted, three different measures provide an indication of testing
completeness
...
This provides
an indication of the completeness of the test plan
...
A reasonably accurate estimate of the number of
basis paths can be computed by adding the cyclomatic complexity of all program
modules
...
Priority indicates the severity
of the problem
...

19
...
However, metrics
designed explicitly for maintenance activities have been proposed
...
982
...
The following information is determined:
MT = the number of modules in the current release
Fc

= the number of modules in the current release that have been changed

Fa

= the number of modules in the current release that have been added

Fd

= the number of modules from the preceding release that were deleted in
the current release

The software maturity index is computed in the following manner:
SMI = [MT Ϫ (Fa + Fc + Fd)]/MT

(19-15)

As SMI approaches 1
...
SMI may also be used as metric for planning software maintenance activities
...

534

PA R T T H R E E

19
...
Metrics provide the insight necessary to create effective analysis and
design models, solid code, and thorough tests
...
It should be programming language
independent and provide effective feedback to the software engineer
...
The function point and the bang metric each provide a quantitative means for evaluating the analysis model
...
Architectural
design metrics consider the structural aspects of the design model
...
Interface design metrics provide an
indication of layout appropriateness for a GUI
...

Using the number of operators and operands present in the code, software science
provides a variety of metrics that can be used to assess program quality
...
However, many other technical metrics can be used to guide the testing process and as a mechanism for assessing the maintainability of a computer
program
...
R
...
M
...
Software Engineering, vol
...
728–738
...
M
...
M
...

Software Engineering, vol
...
8, August 1994, pp
...

[BRI96]

Briand, L
...
, S
...
R
...
Software Engineering, vol
...
1, January
1996, pp
...

[CAR90] Card, D
...
and R
...
Glass, Measuring Software Design Quality, Prentice-Hall,
1990
...
P
...
A
...
ACM Software Quality Assurance Workshop, November 1978, pp
...

[CHA89] Charette, R
...
, Software Engineering Risk Analysis and Management, McGrawHill/Intertext, 1989
...
"Management and Experimentation in Software Engineering,"
Proc
...
68, no
...

[DAV93] Davis, A
...
, “Identifying and Measuring Quality in a Software Requirements Speciﬁcation, Proc
...
Software Metrics Symposium, IEEE, Baltimore, MD,
May 1993, pp
...

[DEM81] DeMillo, R
...
and R
...
Lipton, “Software Project Forecasting,” in Software
Metrics (A
...
Perlis, F
...
Sayward, and M
...
), MIT Press, 1981, pp
...

[DEM82] DeMarco, T
...

[DHA95] Dhama, H
...
29, no
...

[EJI91]

Ejiogu, L
...

[FEL89]

Felican, L
...
Zalateu, “Validating Halstead’s Theory for Pascal Pro-

grams,” IEEE Trans
...
SE-15, no
...

1630–1632
...
, Software Metrics, Chapman and Hall, 1991
...
, “Software Measurement: A Necessary Scientific Basis,” IEEE
Trans
...
SE-20, no
...
199–206
...
B
...
L
...

[HAL77] Halstead, M
...

[HEN81] Henry, S
...
Kafura, “Software Structure Metrics Based on Information
Flow,” IEEE Trans
...
SE-7, no
...
510–518
...
, Making Software Measurement Work, QED Publishing, 1993
...

[KYB84] Kyburg, H
...
, Theory and Measurement, Cambridge University Press, 1984
...
J
...
Software Engineering, vol
...
308–320
...
, P
...
Walters, "Factors in Software Quality," three
volumes, NTIS AD-A049-014, 015, 055, November 1977
...
J
...
W
...
32, no
...
1415–1425
...
J
...
H
...
7, no
...
5–9
...
, and J
...
Performance,"

CACM, vol
...
4, April 1994, pp
...

[ROC94] Roche, J
...
, “Software Metrics and Measurement Principles,” Software Engineering Notes, ACM, vol
...
1, January 1994, pp
...

[SEA93] Sears, A
...
Software Engineering, vol
...
7, July 1993, pp
...

[USA87] Management Quality Insight, AFCSP 800-14 (U
...
Air Force), January 20, 1987
...
, Software Complexity: Measures and Methods, DeGruyter, 1990
...
, A Framework of Software Measurement, DeGruyter, 1997
...
1
...
Using [ZUS97], [FEN91], [ZUS90], [KYB84] or some other source, write
a brief paper that outlines the main tenets of measurement theory
...

19
...
McCall’s quality factors were developed during the 1970s
...
Can you draw any conclusions based on this fact?
19
...
Why is it that a single, all-encompassing metric cannot be developed for program complexity or program quality?
19
...
Review the analysis model you developed as part of Problem 12
...
Using the
guidelines presented in Section 19
...
1, develop an estimate for the number of function points associated with PHTRS
...
5
...
13
...
3
...

Is the PHTRS system function strong or data strong?
19
...
Compute the value of the bang metric using the measures you developed in
Problem 19
...

19
...
Create a complete design model for a system that is proposed by your instructor
...
4
...
Also compute the Henry-Kafura and morphology metrics for the design model
...
8
...
There are 96 modules that perform control and coordination functions and 490 modules whose function depends
on prior processing
...
There are 140 unique data base items and 90 different database segments
...

Compute the DSQI for this system
...
9
...
Be sure to indicate how data
slices, data tokens, glue, and superglue tokens are determined
...
10
...
Using Dhama’s metric described in Section 19
...
2, compute the coupling value for each module
...
11
...
You may choose the language
...
12
...

The tool should enable you to assign the transition cost between layout entities
...
)
19
...
Develop a small software tool that will perform a Halstead analysis on programming language source code of your choosing
...
14
...
Are
the data compelling? Recommend guidelines for the application of these metrics
...
15
...
Present your ﬁndings to the class
...
16
...
The latest release required that 90 of these
modules be changed
...
Compute the software maturity index for the system
...
Zuse [ZUS97] has written the most thorough treatment of technical metrics published to date
...
Oman and Pﬂeeger (Applying Software
Metrics, IEEE Computer Society Press, 1997) have edited an anthology of important
papers on software metrics
...
D
...
E
...
Y
...
Software Engineering Metrics and Models,
Benjamin/Cummings, 1984
...
E
...
L
...
,
PWS Publishing Co
...

Grady, R
...
Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, 1992
...
, et al
...

Sheppard, M
...

The theory of software measurement is presented by Denvir, Herman, and Whitty in an
edited collection of papers (Proceedings of the International BCS-FACS Workshop: Formal Aspects of Measurement, Springer-Verlag, 1992)
...

538

PA R T T H R E E

C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

A comprehensive summary of dozens of useful software metrics is presented in
[IEE94]
...
An appendix provides discussion and many references
...
An up-to-date list of World Wide Web references that are
relevant to technical metrics can be found at the SEPA Web site:
http://www
...
com/engcs/compsci/pressman/resources/
tech-metrics
...
In the chapters that follow, we address the following questions:

I

• What basic concepts and principles are applicable to objectoriented thinking?
• How do conventional and object-oriented approaches differ?
• 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 understand classes,
their relationships, and behaviors?
• What are the elements of an object-oriented design model?
• What basic concepts and principles are applicable to the
software testing for object-oriented software?
• 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
...
547
class hierarchy
...
546
CPF for OO
...
550
inheritance
...
548
OO estimation
...
562
OO process
model
...
546
operations
...
560

OBJECT-ORIENTED CONCEPTS
AND PRINCIPLES

e live in a world of objects
...
They can
be categorized, described, organized, combined, manipulated, and
created
...

An object-oriented approach to the development of software was ﬁrst proposed in the late 1960s
...
Throughout the 1990s, object-oriented software
engineering became the paradigm of choice for many software product builders
and a growing number of information systems and engineering professionals
...
An important question is why?
The answer (like many answers to questions about software engineering) is
not a simple one
...
Object technologies do lead to a number of inherent benefits that provide advantage at
both the management and technical levels
...
This important characteristic enables classes

solution
...
The

libraries of reusable classes and objects
...
The

software engineering, the object-oriented para-

objects are manipulated with a collection of func-

digm is attractive to many software development

tions (called methods, operations, or services) and

organizations
...
Objects are categorized into

exhibit design characteristics (e
...
, functional inde-

classes and subclasses
...

a description of attributes, behaviors, operations,

What are the steps? Object-oriented software engi-

and messages
...

approaches
...

architecture, interface, and com-

How do I ensure that I’ve done it right? At each

ponent-level detail; implementation (using an

stage, object-oriented work products are reviewed

object-oriented language) transforms design into

for clarity, correctness, completeness, and consis-

code; and testing exercises the object-oriented

tency with customer requirements and with one

architecture, interfaces and components
...

What is the work product? A set of object oriented
models is produced
...
Object-oriented software
is easier to maintain because its structure is inherently decoupled
...
In addition, object-oriented systems are easier to adapt and
easier to scale (i
...
, large systems can be created by assembling reusable subsystems)
...
Throughout the remainder of
Part Four of this book, we consider methods that form the basis for an engineering
approach to the creation of object-oriented products and systems
...
1

T H E O B J E C T - O R I E N T E D PA R A D I G M
For many years, the term object oriented (OO) was used to denote a software development approach that used one of a number of object-oriented programming languages (e
...
, Ada95, Java, C++, Eiffel, Smalltalk)
...
Edward Berard notes this when he states
[BER93]:
The benefits of object-oriented technology are enhanced if it is addressed early-on and

“With objects, it’s
actually easier to
build models [for
complex systems]
than to engage in
sequential
programming
...
Those considering object-oriented technology must assess its impact on the entire software engineering process
...
Software engineers and
their managers must consider such items as object-oriented requirements analysis (OORA),
object-oriented design (OOD), object-oriented domain analysis (OODA), object-oriented
database systems (OODBMS) and object-oriented computer aided software engineering
(OOCASE)
...
1
The OO
process model
Planning

Identify
candidate
classes

Risk
Analysis

Construct
n th iteration
of system

Customer
Evaluation

Engineering,
Construction & Release

Look up
classes
in library

Put new
classes
in library

Customer
Communication

Extract
classes
if available

Engineer
classes
if unavailable
OO
OO
OO
OO

analysis
design
programming
testing

nologies when we engineer software using the classical methods
...
Later in this
chapter, it will be
referred to as a
recursive parallel
model
...
Although any one of these models could be adapted for use with OO, the
best choice would recognize that OO systems tend to evolve over time
...
Referring
to Figure 20
...

The OO process moves through an evolutionary spiral that starts with customer
communication
...
Planning and risk analysis establish a foundation for the OO project plan
...
OO soft-

WebRef

ware engineering emphasizes reuse
...
net/cetus/
software
...
When a class cannot be found in the
library, the software engineer applies object-oriented analysis (OOA), object-oriented
design (OOD), object-oriented programming (OOP), and object-oriented testing (OOT)
to create the class and the objects derived from the class
...

The object-oriented view demands an evolutionary approach to software
engineering
...
As the OO analysis and design models evolve, the need for additional classes becomes apparent
...

20
...
What is an object-oriented viewpoint? Why is a method con-

“Object-oriented
programming is not
so much a coding
technique as it is a
code packaging
technique, a way for
code suppliers to
encapsulate
functionality for
delivery to
customers
...
g
...
In the discussion that follows, we attempt to synthesize
the most common of these
...
Chair is a member (the
term instance is also used) of a much larger class of objects that we call furniture
...

For example, all furniture has a cost, dimensions, weight, location, and color, among
many possible attributes
...
Because chair is a member of furniture, chair inherits all attributes deﬁned for the class
...
2
...
2
Inheritance
from class to
object

CHAPTER 20

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

545

Once the class has been deﬁned, the attributes can be reused when new instances
of the class are created
...
Chable inherits all of the attributes of furniture
...
See
Chapter 12 for details
...
Every object in the class furniture can be manipulated in
a variety of ways
...
g
...
Each of these
operations (other terms are services or methods) will modify one or more attributes of
the object
...
To do this, move must have "knowledge"
of these data items
...
All valid operations (e
...
, buy, sell, weigh)
for the class furniture are "connected" to the object deﬁnition as shown in Figure
20
...

Class: furniture
Cost
Dimensions
Weight
Location
Color
Buy
Sell
Weigh
Move

Object: chair

Object: chable
Cost
Dimensions
Weight
Location
Color
F I G U R E 20
...
”
Jim Rumbaugh
et al
...
Encapsulation means that all of this information is packaged under one name and can be reused as one speciﬁcation or program component
...
Coad and Yourdon [COA91] deﬁne the
term this way:
object-oriented = objects + classiﬁcation + inheritance + communication
Three of these concepts have already been introduced
...

20
...
1 Classes and Objects
The fundamental concepts that lead to high-quality design (Chapter 13) apply equally
to systems developed using conventional and object-oriented methods
...
A class is an OO concept that encapsulates the
data and procedural abstractions required to describe the content and behavior of
some real world entity
...
4 to describe a class (and objects derived from a class)
...

The data abstractions (attributes) that describe the class are enclosed by a “wall”
of procedural abstractions (called operations, methods, or services) that are capable
of manipulating the data in some way
...
Therefore, the
class encapsulates data (inside the wall) and the processing that manipulates the data
(the methods that make up the wall)
...
4
An alternative
representation
of an objectoriented class

Operations:

CHAPTER 20

547

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

the impact of side effects associated with change
...
All of these design characteristics lead to highquality software
...

Stated another way, a class is a generalized description (e
...
, a template, pattern,
or blueprint) that describes a collection of similar objects
...
A superclass is a collection of classes, and a subclass is a
specialized instance of a class
...
A class hierarchy for the class furniture is
illustrated in Figure 20
...

20
...
2 Attributes
We have already seen that attributes are attached to classes and objects, and that
they describe the class or object in some way
...
Most physical objects have features such as shape, weight, color, and type of material
...
A feature may be seen as a
binary relation between a class and a certain domain
...
5
A class
hierarchy

Chair

Desk

“Chable”

Subclasses of the
furniture superclass
Instances of chair

548

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

The “binary relation” implies that an attribute can take on a value deﬁned by an enumerated domain
...
For example, assume that a class automobile has an attribute color
...
In more complex situations, the
domain can be a set of classes
...
Each

The values assigned to
an object’s attributes
make that object
unique
...

The features (values of the domain) can be augmented by assigning a default value
(feature) to an attribute
...
It may also be useful to associate a probability with a particular feature by
assigned {value, probability} pairs
...
In
some applications (e
...
, manufacturing planning) it might be necessary to assign a
probability to each of the colors (white and black are highly probable as automobile
colors)
...
2
...
These algorithms are called operations, methods, or
services1 and can be viewed as modules in a conventional sense
...
For example, the operation GetColor for the
object automobile will extract the color stored in the color attribute
...

the particular instance of a class
...
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
...
Operations encapsulated by the second and third objects act on the stimuli,
returning necessary information to the ﬁrst object
...

20
...
4 Messages
Messages are the means by which objects interact
...
The behavior is accomplished when an operation is executed
...

CHAPTER 20

F I G U R E 20
...
6
...

“Messages and
methods
[operations] are two
sides of the same
coin
...
”
Greg Voss

As an example of message passing within an OO system, consider the objects
shown in Figure 20
...
Four objects, A, B, C, and D communicate with one another
by passing messages
...
Operation op10 completes and sends a return value to B
...
The receiver [object] responds to the message by ﬁrst choosing the operation that implements the message name, executing this operation, and then returning
control to the caller
...
7
Message
passing
example

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

A

B

op1
op2

op3
op4
op5
Message
Return value
C

D

op6
op7
op8
op9

op10
op11
Return value

Messaging ties an object-oriented system together
...

20
...
5 Encapsulation, Inheritance, and Polymorphism
Although the structure and terminology introduced in Sections 20
...
1 through 20
...
4
differentiate OO systems from their conventional counterparts, three characteristics of object-oriented systems make them unique
...
This provides a number of important benefits:

? What are the
primary

•

The internal implementation details of data and procedures are hidden from
the outside world (information hiding)
...

•

Data structures and the operations that manipulate them are merged in a single named entity—the class
...

•

Interfaces among encapsulated objects are simpliﬁed
...

Hence, interfacing is simpliﬁed and the system coupling tends to be reduced
...
A subclass Y inherits all of the attributes and operations associated with its
superclass, X
...
Reuse has been accomplished directly
...
2 Therefore,
the class hierarchy becomes a mechanism through which changes (at high levels)
can be immediately propagated through a system
...
In fact, whenever a new class is to be created, the software engineer has
a number of options:
•

The class can be designed and built from scratch
...

•

The class hierarchy can be searched to determine if a class higher in the hierarchy contains most of the required attributes and operations
...

•

The class hierarchy can be restructured so that the required attributes and
operations can be inherited by the new class
...

To illustrate how restructuring of the class hierarchy might lead to a desired class,

“Whereas an object is
a concrete entity
that exists in time
and space, a class
represents only an
abstraction, the
‘essence’ of an
object, as it were
...
8
...
8A enables us to derive classes X3 and X4 with characteristics 1, 2, 3, 4, 5 and 6
and 1, 2, 3, 4, 5, and 7, respectively
...
To derive this class, called X2b in the example,
the hierarchy may be restructured as shown in Figure 20
...
It is important to note
that restructuring the hierarchy can be difﬁcult, and for this reason, overriding is sometimes used
...
As Jacobson notes, when overriding is used “inheritance is not transitive” [JAC92]
...
This is called multiple inheritance, and it is controversial
...
Because multiple
inheritance sequences are more difﬁcult to trace, changes to the deﬁnition of a class
that resides high in the hierarchy may have an unintended impact on classes deﬁned
lower in the architecture
...

For the purposes of this example, “characteristics” may be either attributes or operations
...
8
Class
hierarchy:
original (A),
restructured (B)

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

X1

X1

char1
char2
char3

char1
char2
char3
+ char4 + char5

+ char4

X2

X2

char1
char2
char3
char4
char5

char1
char2
char3
char4
+ char5

+ char6

+ char8

+ char7
X2b

X2a
X3

X4

char1
char2
char3
char4
char5
char6

char1
char2
char3
char4
char5
char7

(A)

char1
char2
char3
char4
char8

char1
char2
char3
char4
char5
+ char6
X3

+ char7
X4
char1
char2
char3
char4
char5
char7

char1
char2
char3
char4
char5
char6

(B)

Polymorphism is a characteristic that greatly reduces the effort required to extend
an existing OO system
...
”
David Taylor

cation that must draw four different types of graphs: line graphs, pie charts, histograms, and Kiviat diagrams
...
To accomplish this in a conventional application
(and maintain module cohesion), it would be necessary to develop drawing modules
for each type of graph
...
A new drawing module would have to be created for each graph type and then
the control logic would have to be updated for each graph
...
Using a concept called overloading [TAY90], each subclass deﬁnes an operation called draw
...
The object receiving the message will invoke
its own draw operation to create the appropriate graph
...
But no changes are required within any object that wants
a graph drawn because the message graphtype draw remains unchanged
...
This in turn decouples objects from one another, making each more
independent
...
3

IDENTIFYING THE ELEMENTS OF AN OBJECT MODEL
The elements of an object model—classes and objects, attributes, operations, and
messages—were each deﬁned and discussed in the preceding section
...

20
...
1 Identifying Classes and Objects
If you look around a room, there is a set of physical objects that can be easily iden-

“The really hard
problem [in OO] is
discovering what are
the ‘right’ objects in
the ﬁrst place
...
But when you
"look around" the problem space of a software application, the objects may be more
difﬁcult to comprehend
...
Objects are determined by underlining
each noun or noun clause and entering it in a simple table
...
Therefore,
when we isolate potential objects, we also identify members of potential classes
...
9
How objects
manifest
themselves

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Occurrences
Things

Roles
Organizational units
Places
Structures

External entities

Class name
Attributes:

Operations:

noted
...
What should we look for once all of the nouns have been isolated?
Objects manifest themselves in one of the ways represented in Figure 20
...
Objects
can be

do
? Howout I
pick

•

External entities (e
...
, other systems, devices, people) that produce or consume information to be used by a computer-based system
...
g, reports, displays, letters, signals) that are part of the information
domain for the problem
...
g
...

•

Roles (e
...
, manager, engineer, salesperson) played by people who interact
with the system
...
g
...

•

Places (e
...
, manufacturing ﬂoor or loading dock) that establish the context of
the problem and the overall function of the system
...
g
...

5

In this context, the term event connotes any occurrence
...

CHAPTER 20

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

555

This categorization is but one of many that have been proposed in the literature
...

It is also important to note what objects are not
...
For example, if the developers of
software for a medical imaging system deﬁned an object with the name image inversion, they would be making a subtle mistake
...

Inversion of the image is an operation that is applied to the object
...
" As Cashman [CAS89]
states: "the intent of object-orientation is to encapsulate, but still keep separate, data
and operations on the data
...
In Chapter 12, we performed a "grammatical parse" on a processing narrative for the SafeHome system
...
2
...
Each sensor is assigned a number and type, a master password is programmed for
arming and disarming the system, and telephone number(s) are input for dialing when a

A grammatical parse
can be used to isolate
potential objects
(nouns) and
operations (verbs)
...

When a sensor event is sensed by the software, it rings an audible alarm attached to the
system
...

The number will be redialed every 20 seconds until telephone connection is obtained
...
Keyboard interaction
takes the following form
...
Note that we call each entry in the list a potential object
...

Coad and Yourdon [COA91] suggest six selection characteristics that should be

? How do I
know
whether a
potential object is
a good candidate
for use in an OO
system?

used as an analyst considers each potential object for inclusion in the analysis model:
1
...
The potential object will be useful during analysis only
if information about it must be remembered so that the system can function
...
Needed services
...

3
...
During requirement analysis, the focus should be on
"major" information; an object with a single attribute may, in fact, be useful
during design, but is probably better represented as an attribute of another
object during the analysis activity
...
Common attributes
...

A potential object
should satisfy most or
all of these
characteristics if it is to
be used in the analysis
model
...
Common operations
...

6
...
External entities that appear in the problem space
and produce or consume information essential to the operation of any solution for the system will almost always be deﬁned as objects in the requirements model
...
The decision
for inclusion of potential objects in the analysis model is somewhat subjective, and
later evaluation may cause an object to be discarded or reinstated
...
With this in mind, we apply the selection characteristics to the list of potential SafeHome objects:
Potential Object/Class

Characteristic Number That Applies

homeowner

rejected: 1, 2 fail even though 6 applies

sensor

accepted: all apply

control panel

accepted: all apply

installation

rejected

system (alias security system)

accepted: all apply

CHAPTER 20

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

number, type

rejected: 3 fails, attributes of sensor

master password

557

rejected: 3 fails

telephone number

rejected: 3 fails

sensor event

accepted: all apply

audible alarm

accepted: 2, 3, 4, 5, 6 apply

monitoring service

rejected: 1, 2 fail even though 6 applies

It should be noted that (1) the preceding list is not all-inclusive, additional objects
would have to be added to complete the model; (2) some of the rejected potential
objects will become attributes for those objects that were accepted (e
...
, number and
type are attributes of sensor, and master password and telephone number may become
attributes of system); (3) different statements of the problem might cause different
"accept or reject" decisions to be made (e
...
, if each homeowner had an individual
password or was identiﬁed by voice print, the homeowner object would satisfy characteristics 1 and 2 and would have been accepted)
...
3
...

In essence, it is the attributes that deﬁne the object—that clarify what is meant by the
object in the context of the problem space
...
In the former,
attributes such as name, position, batting average, ﬁelding percentage, years played, and games
played might be relevant
...

Attributes are chosen
by examining the
problem statement,
looking for things that
fully deﬁne an object
and make it unique
...
In addition, the following question
should be answered for each object: "What data items (composite and/or elementary) fully deﬁne this object in the context of the problem at hand?"
To illustrate, we consider the system object deﬁned for SafeHome
...
Using the content description notation deﬁned
for the data dictionary and presented in Chapter 12, we can represent these composite data items in the following manner:
sensor information = sensor type + sensor number + alarm threshold
alarm response information = delay time + telephone number + alarm type
activation/deactivation information = master password + number of allowable tries + temporary password
identiﬁcation information = system ID + veriﬁcation phone number + system status

558
F I G U R E 20
...
10)
...
3
...
More speciﬁcally, an operation changes one or more attribute values that are
contained within the object
...

?

Is there a
reasonable
way to categorize
an object’s
operations?

Although many different types of operations exist, they can generally be divided
into three broad categories: (1) operations that manipulate data in some way (e
...
,
adding, deleting, reformatting, selecting), (2) operations that perform a computation, and (3) operations that monitor an object for the occurrence of a controlling
event
...
To
accomplish this, the grammatical parse is again studied and verbs are isolated
...
For example, from the SafeHome processing narrative presented earlier in this
chapter, we see that "sensor is assigned a number and type" or that "a master pass-

CHAPTER 20

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

559

word is programmed for arming and disarming the system
...

•

That a program operation will be applied to the system object
...
For example, program implies specifying phone numbers, conﬁguring system characteristics
(e
...
, creating the sensor table, entering alarm characteristics), and entering password(s)
...

In addition to the grammatical parse, we can gain additional insight into other
operations by considering the communication that occurs between objects
...
Before continuing with the speciﬁcation of operations, we explore this matter in a bit more detail
...
3
...

In Section 20
...
3, operations were culled from a grammatical parse of the processing narrative for the system
...

The generic life history of an object can be deﬁned by recognizing that the object
must be created, modiﬁed, manipulated or read in other ways, and possibly deleted
...
Some of the
operations can be ascertained from likely communication between objects
...
Other messages can be considered and operations derived
...
10
...

After attributes and operations are deﬁned for each of the objects identiﬁed to this
point, the beginnings of an OOA model would be created
...

560

PA R T F O U R

20
...
Do not
assume that OO
somehow relieves you
of this responsibility
...
Establishing a common process framework for a project
...
Using the framework and historical metrics to develop effort and time estimates
...
Establishing deliverables and milestones that will enable progress to be measured
...
Deﬁning checkpoints for risk management, quality assurance, and control
...
Managing the changes that invariably occur as the project progresses
...
Tracking, monitoring, and controlling progress
...
net/cetus/
oo_project_mngt
...
But, because of the unique nature of object-oriented software, each of these
management activities has a subtly different feel and must be approached using a
somewhat different mind-set
...
The fundamental principles of management stay the same, but the
technique must be adapted so that an OO project is properly managed
...
4
...
It identiﬁes the paradigm that is applied to build and maintain software and
the tasks, milestones, and deliverables that will be required
...
The CPF is always
adaptable so it can meet the individual needs of a project team
...

XRef
The common process
framework deﬁnes
basic software
engineering activities
...

As we noted earlier in this chapter, object-oriented software engineering applies
a process model that encourages iterative development
...
The common process framework that is used to manage an OO project must be evolutionary in nature
...
In essence the
recursive/parallel model works in the following way:
•

Do enough analysis to isolate major problem classes and connections
...

CHAPTER 20

? How do we
apply a
recursive/parallel
model for OO
software
engineering?

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

561

•

Extract reusable objects from a library to build a rough prototype
...

•

Get customer feedback on the prototype
...

•

Reﬁne the design to accommodate your changes
...

•

Assemble a new prototype using objects from the library and the new objects
you’ve created
...

•

Get customer feedback on the prototype
...

The recursive/parallel model is quite similar to the spiral or evolutionary paradigm
...
What makes the recursive/parallel model different
is (1) the recognition that analysis and design modeling for OO systems cannot be
accomplished at an even level of abstraction and (2) analysis and design can be
applied to independent system components concurrently
...

•

Reapply the decomposition process to each of the independent components
to decompose each further (the recursive part)
...

•

Continue this process until completion criteria are attained
...

To control the recursive/parallel process framework, the project manager must

In many ways, the
architecture of an OO
system makes it easier
to initiate work in
parallel
...

recognize that progress is planned and measured incrementally
...

Each iteration of the recursive/parallel process requires planning, engineering
(analysis, design, class extraction, prototyping, and testing), and evaluation activities (Figure 20
...
During planning, activities associated with each of the independent program components are planned and scheduled
...
) During early stages of engineering, analysis and design occur iteratively
...
11 Typical process sequence for an OO project

intent is to isolate all important elements of the OO analysis and design models
...
During evaluation, reviews, customer evaluation, and testing are performed for each
increment, with feedback affecting the next planning activity and subsequent increment
...
4
...
Because an
overriding goal for OO projects should be reuse, LOC estimates make little sense
...
FP analysis may provide
value for estimating OO projects, but the FP measure does not provide enough granularity for the schedule and effort adjustments that are required as we iterate through
the recursive/parallel paradigm
...
A scenario script (analogous to use-cases dis-

These metrics can be
used to supplement
the FP metric
...

cussed in Chapter 11) is a detailed sequence of steps that describe the interaction between the user and the application
...
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 exercise the system once it is constructed
...
Key classes are the “highly independent compo-

A detailed discussion of
OO metrics is presented
in Chapter 24
...
Because key classes are central
to the problem domain, the number of such 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
...
Support classes are required to implement the
system but are not immediately related to the problem domain
...
In addition, support classes can be developed for each of
the key classes
...

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
...
In general, key
classes are known early in the project
...
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 simpliﬁed
...
Non-GUI applications have between one and two times the number
of support classes as key classes
...
A subsystem is an aggregation of classes that support a function that is visible to the end-user of a system
...

6

Technical metrics for OO systems are discussed in detail in Chapter 24
...
4
...
However, this in no way
precludes the use of a systematic approach
...
That is, estimates should be derived using
a number of different techniques
...
Therefore, it is worthwhile to
supplement conventional software cost estimation with an approach that has been
designed explicitly for OO software
...
Develop estimates using effort decomposition, FP analysis, and any other
method that is applicable for conventional applications
...
Using OOA (Chapter 21), develop scenario scripts (use-cases) and determine
a count
...

project progresses
...
Using OOA, determine the number of key classes
...
Categorize the type of interface for the application and develop a multiplier
for support classes:
Interface type

Multiplier

No GUI

2
...
25

GUI

2
...
0

Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes
...
Multiply the total number of classes (key + support) by the average number of
work-units per class
...

6
...

Scheduling for object-oriented projects is complicated by the iterative nature of the
process framework
...
Thinking back to the spiral model (Chapter
2), a major iteration would correspond to one 360º traversal of the spiral
...
Lorenz and

CHAPTER 20

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

565

Kidd suggest that iterations of between 2
...

Number of completed contracts
...
A contract is an excellent milestone and at least one contract should be associated with each project iteration
...

20
...
4 Tracking Progress for an OO Project
Although the recursive/parallel process model is the best framework for an OO project, task parallelism makes project tracking difﬁcult
...
In general, the following major milestones
can be considered “completed” when the criteria noted have been met
...

Class attributes and operations associated with a class have been deﬁned
and reviewed
...

•

A behavioral model (Chapter 21) has been created and reviewed
...

Technical milestone: OO design completed
•

The set of subsystems (Chapter 22) has been deﬁned and reviewed
...

•

Task allocation has been established and reviewed
...

•

Attributes and operations have been designed and reviewed
...

Technical milestone: OO programming completed
•

Each new class has been implemented in code from the design model
...

•

Prototype or increment has been built
...

566

PA R T F O U R

•

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

A class-responsibility-collaboration network (Chapter 23) has been developed and reviewed
...

•

Test cases are designed and cluster testing (Chapter 23) is completed and the
classes are integrated
...

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 different increments are delivered to the customer
...
5

SUMMARY
Object-oriented technologies reﬂect a natural view of the world
...
Each class contains a set of attributes that describe it
and a set of operations that deﬁne its behavior
...
External entities, things, occurrences, roles, organizational units, places, and structures can all be represented as objects
...
Processing operations are part of the object and are initiated by passing the object a message
...
New objects can be instantiated from a class
...
Encapsulation packages data and the operations that manipulate
the data into a single named object
...
Polymorphism enables a number of different operations to have the same
name, reducing the number of lines of code required to implement a system and facilitating changes when they are made
...
OO software evolves iteratively and
must be managed with the recognition that the ﬁnal product will be developed over
a series of increments
...
V
...

[BOO86] Booch, G
...
Software Engineering, vol
...
2, February 1986, pp
...

CHAPTER 20

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

567

[BOO91] Booch, G
...

[BUD96] Budd, T
...
, AddisonWesley, 1996
...
, "Object Oriented Domain Analysis," ACM Software Engineering Notes, vol
...
6, October 1989, p
...

[CHA93] de Champeaux, D
...
Lea, and P
...

[COA91] Coad, P
...
Yourdon, Object-Oriented Analysis, 2nd ed
...

[COX86] Cox, B
...
, Object-Oriented Programming, Addison-Wesley, 1986
...

[JAC92]

Jacobson, I
...

[LOR94] Lorenz, M
...
Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994
...
, "What Is Object-Oriented Programming?" IEEE Software, vol
...
3, May 1988, pp
...

[TAY90] Taylor, D
...
, Object-Oriented Technology: A Manager’s Guide, AddisonWesley, 1990
...
1
...
Yet, like all technologies, OO has flaws
...

20
...
In this chapter we did not consider the case in which a new object requires an
attribute or operation that is not contained in the class from which it inherited all
other attributes and operations
...
3
...
2
...
4
...

20
...
Review the objects deﬁned for the SafeHome system
...
6
...
Deﬁne a set of classes (and subclasses) for the interface entities that typically appear in the GUI
...

20
...
Provide an example of a composite object
...
8
...
A class named document is identiﬁed
...

20
...
Research two different OO programming languages and show how messages
are implemented in the language syntax
...

20
...
Provide a concrete example of class hierarchy restructuring as described in
the discussion of Figure 20
...

20
...
Provide a concrete example of multiple inheritance
...

20
...
Develop a statement of scope for a system requested by your instructor
...
Apply the selection criteria discussed in Section 20
...
1 to determine whether
the class should be used in the analysis model
...
13
...

20
...
Provide three or four specific examples of the key class and support class
described in Section 20
...
2
...
Taylor’s abbreviated treatment
[TAY90] remains a classic introduction to the subject
...

Zamir (Handbook of Object Technology, CRC Press, 1998) has edited a voluminous
treatment that covers every aspect of object technologies
...
Gardner et al
...

CHAPTER 20

O B J E C T- O R I E N T E D C O N C E P T S A N D P R I N C I P L E S

569

The unique nature of the OO paradigm poses special challenges to project managers
...

Eeles and Sims (Building Business Objects, Wiley, 1998), Carmichael (Developing
Business Objects, SIGS Books, 1998), Fingar (The Blueprint for Business Objects, Cambridge University Press, 1996), and Taylor (Business Engineering with Object Technology, Wiley, 1995) address object technology as it is applied in a business context
...

A wide variety of information sources on object technologies and related subjects
is available on the Internet
...
mhhe
...
mhtml

CHAPTER

21
KEY
CONCEPTS
class diagrams
...
584
collaboration
...
582
domain analysis
...
594
object-relationship
model
...
579
responsibilities
...
590
reuse
...
590
UML
...
581

OBJECT-ORIENTED ANALYSIS

hen a new product or system is to be built, how do we characterize
it in a way that is amenable to object-oriented software engineering? Are there special questions that we need to ask the customer?
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 (OOA)—the ﬁrst technical activity that is performed as part of OO software engineering
...
Coad and Yourdon
[COA91] consider this issue when they write:

W

OOA—object-oriented analysis—is based upon concepts that we ﬁrst learned in kindergarten: objects and attributes, classes and members, wholes and parts
...

OOA is grounded in a set of basic principles that were introduced in Chapter 11
...
OOA

(objects) that represent the problem to be solved,

provides you with a concrete way to represent

the manner in which the classes relate to and

your understanding of requirements and then test

interact with one another, the inner workings

that understanding against the customer’s per-

(attributes and operations) of objects, and the com-

ception of the system to be built
...
All of these things are

of use-cases—a scenario-based description of

accomplished during object-oriented analysis

how actors (people, machines, other systems)

(OOA)
...
Class-

Who does it? The definition of an object-oriented

responsibility-collaborator (CRC) modeling trans-

analysis model encompasses a description of the

lates the information contained in use-cases into

static and dynamic characteristics of classes that

a representation of classes and their collabora-

describe a system or product
...
The static and dynamic

formed by a software engineer
...

interclass communication and a depiction of class
behavior over time
...
The OO

the elements of the object-oriented analysis model

analysis model is composed of graphical or

are reviewed for clarity, correctness, complete-

language-based representations that deﬁne class

ness, and consistency with customer requirements

attributes, relationships, and behaviors, as well as

and with one another
...
These principles form the foundation for the
approach to OOA presented in this chapter
...
To accomplish this, a number of tasks must occur:
1
...

“A problem wellstated is a problem
half-solved
...
Classes must be identiﬁed (i
...
, attributes and methods are deﬁned)
...
A class hierarchy must be speciﬁed
...
Object-to-object relationships (object connections) should be represented
...
Object behavior must be modeled
...
Tasks 1 through 5 are reapplied iteratively until the model is complete
...
But a limited number of key ideas appear repeatedly,
and it is these that we will consider in this chapter
...
1

O B J E C T - O R I E N T E D A N A LY S I S
The objective of object-oriented analysis is to develop a model that describes computer software as it works to satisfy a set of customer-deﬁned requirements
...
The analysis model depicts information, function, and behavior within the context of the elements of the object model described
in Chapter 20
...
1
...
OO Approaches
Is object-oriented analysis really different from the structured analysis approach that
was presented in Chapter 12? Fichman and Kemerer [FIC92] address the question
head-on:

CHAPTER 21

O B J E C T- O R I E N T E D A N A LY S I S

573

We conclude that the object-oriented analysis approach
...
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
principles of object-orientation: encapsulation, classiﬁcation of objects, and inheritance
...
Data are considered separately from the processes that transform the
data
...
The structured analysis approach makes heavy use of functional decomposition (partitioning of the data ﬂow diagram, Chapter 12)
...
Identiﬁcation/classiﬁcation of entities1

? What can
criteria

2
...
Other entity relationships
4
...
Large-scale model partitioning
6
...
Detailed speciﬁcation for functions
8
...
End-to-end processing sequences
10
...
Entity communication (via messages or events)
Because many variations exist for structured analysis and dozens of OOA methods (see
Section 21
...
2) have been proposed over the years, it is difﬁcult to develop a generalized comparison between the two methods
...

21
...
2 The OOA Landscape
The popularity of object technologies spawned dozens of OOA methods during the
late 1980s and into the 1990s
...

A detailed discussion of these methods and their differences is beyond the scope of this book
...
The interested reader should refer
to Berard [BER99] and Graham [GRA94] for detailed comparisons
...
Among the most widely used were3
The Booch method
...
” The micro
level deﬁnes a set of analysis tasks that are reapplied for each step in the
macro process
...
Booch’s OOA
micro development process identiﬁes classes and objects and the semantics of
classes and objects and deﬁnes relationships among classes and objects and
conducts a series of reﬁnements to elaborate the analysis model
...
Rumbaugh [RUM91] and his colleagues devel-

“The central activity
of working with
objects is not so
much a matter of
programming as it is
representation
...
The analysis activity creates three models: the object
model (a representation of objects, classes, hierarchies, and relationships),
the dynamic model (a representation of object and system behavior), and the
functional model (a high-level DFD-like representation of information ﬂow

David Taylor

through the system)
...
Also called OOSE (object-oriented software engineering), the Jacobson method [JAC92] is a simpliﬁed version of the proprietary objectory method, also developed by Jacobson
...

The Coad and Yourdon method
...
Modeling notation is relatively simple and guidelines for developing the analysis model are
straightforward
...

• Deﬁne a generalization/speciﬁcation structure
...

• Identify subjects (representations of subsystem components)
...

• Deﬁne services
...
Wirfs-Brock, Wilkerson, and Weiner [WIR90] do
not make a clear distinction between analysis and design tasks
...
A brief outline of Wirfs-Brock et al
...

CHAPTER 21

O B J E C T- O R I E N T E D A N A LY S I S

575

• Evaluate the customer speciﬁcation
...

• Group classes in an attempt to identify superclasses
...

• Assign responsibilities to each class
...

• Deﬁne collaboration between classes based on responsibilities
...

• Construct a collaboration graph for the system
...
To perform object-oriented
analysis, a software engineer should perform the following generic steps:
1
...

A set of generic steps
are applied during
OOA, regardless of the
analysis method that is
chosen
...
Identify scenarios or use-cases
...
Select classes and objects using basic requirements as a guide
...
Identify attributes and operations for each system object
...
Deﬁne structures and hierarchies that organize classes
...
Build an object-relationship model
...
Build an object-behavior model
...
Review the OO analysis model against use-cases or scenarios
...
3 and 21
...

21
...
3 A Uniﬁed Approach to OOA
Over the past decade, Grady Booch, James Rumbaugh, and Ivar Jacobson have collaborated to combine the best features of their individual object-oriented analysis

“UML has uniﬁed
some of the existing
OO notations, thus
creating a single
point of reference for
many important
concepts
...
The result, called the Unified Modeling
Language (UML), has become widely used throughout the industry
...
Eriksson and Penker [ERI98] explain these rules in the following way:
The syntax tells us how the symbols should look and how the symbols are combined
...
The semantic
rules tell us what each symbol means and how it should be interpreted by itself and in the
context of other symbols; they are compared to the meanings of words in a natural language
...
The interested reader should see [BOO99], [RUM99], and [JAC99]
...
This corresponds in natural
language to the rules for constructing sentences that are clear and understandable
...
Each view is deﬁned by a set of diagrams
...
This view represents the system (product) from the
user’s (called actors in UML) perspective
...
Be
certain that you get
the user model view
right
...

approach of choice for the user model view
...
5
Structural model view
...
That is, static structure (classes, objects, and relationships) is
modeled
...
This part of the analysis model represents the
dynamic or behavioral aspects of the system
...

Implementation model view
...
net/cetus/
oo_uml
...
2

system are represented as they are to be built
...
The structural and behavioral aspects of the
environment in which the system is to be implemented are represented
...
UML design modeling (considered in Chapter 22) addresses the
behavioral model, implementation model, and environmental model views
...
At the business or enterprise level, the techniques associated with OOA can be
coupled with a business process engineering approach (Chapter 10) in an effort to

The objective of
domain analysis is to
deﬁne a set of classes
(objects) that are
encountered
throughout an
application domain
...

deﬁne classes, objects, relationships, and behaviors that model the entire business
...
At an application level, the object model focuses on specific customer requirements as those
requirements affect an application to be built
...
Interested readers should see [EEL98], [CAR98], [FIN96], [TAY95], [MAT94],
5

If you have not already done so, please read Section 11
...
4 for a detailed discussion of use-cases
...
OOA at the lowest level of abstraction falls within the general purview of object-oriented software
engineering and is the focus of all other sections of this chapter
...
This activity, called domain analysis,
is performed when an organization wants to create a library of reusable classes (components) that will be broadly applicable to an entire category of applications
...
2
...
Consider a simple example
...

Two teams are assigned to build the application
...
Each team is populated by people with the same skill levels and experience
...
Team B uses a robust class library and ﬁnds that 55 classes
already exist
...
Patterns
within the software
will become more
consistent, leading to
better maintainability
...

1
...

2
...

3
...

Although the margin by which Team B’s work would exceed Team A’s accomplishments is open to debate, few would argue that reuse provides Team B with a substantial advantage
...

21
...
2 The Domain Analysis Process
Firesmith [FIR93] describes software domain analysis in the following way:
Software domain analysis is the identiﬁcation, analysis, and speciﬁcation of common requirements from a specific application domain, typically for reuse on multiple projects within
that application domain
...

sis, and speciﬁcation of common, reusable capabilities within a speciﬁc application domain,
in terms of common objects, classes, subassemblies, and frameworks
...
The goal of domain analysis is straightforward: to ﬁnd or create those classes that are broadly applicable, so
that they may be reused
...
1 Input and output for domain analysis

Using terminology that was introduced earlier in this book, domain analysis may
be viewed as an umbrella activity for the software process
...
In a way, the role of a domain analyst is similar to the role
of a master toolsmith in a heavy manufacturing environment
...
The role of the domain analyst is to design and build

“If an organization is
to make a major
investment in
software reuse, it
needs to know what
components to
consider in the
development of such
a model
...

Figure 21
...
Sources of domain knowledge are surveyed in an attempt to identify objects
that can be reused across the domain
...
The knowledge engineer investigates a speciﬁc area of interest in an attempt to extract key facts that may be of use in creating an expert system
or artificial neural network
...

The domain analysis process can be characterized by a series of activities that
begin with the identiﬁcation of the domain to be investigated and end with a speciﬁcation of the objects and classes that characterize the domain
...
To accomplish this, the analyst

XRef
A complete domain
analysis strategy must
consider architecture as
well as components
...

must ﬁrst isolate the business area, system type, or product category of interest
...
OO items include
speciﬁcations, designs, and code for existing OO application classes; support
classes (e
...
, GUI classes or database access classes); commercial off-theshelf (COTS) component libraries that are relevant to the domain; and test
cases
...

Categorize the items extracted from the domain
...
A classiﬁcation scheme for the categories is proposed and nam-

CHAPTER 21

O B J E C T- O R I E N T E D A N A LY S I S

579

ing conventions for each item are deﬁned
...

Collect a representative sample of applications in the domain
...
Berard
[BER93] notes that during the early stages of use of object-technologies, a software organization will have few if any OO applications
...
”
Analyze each application in the sample
...

• Indicate the reasons that the object has been identiﬁed for reuse
...

• Estimate the percentage of applications in the domain that might make
reuse of the object
...
In addition, once the objects
have been deﬁned, the analyst should estimate what percentage
of a typical application could be constructed using the reusable
objects
...
The analysis model will
serve as the basis for design and construction of the domain objects
...
sei
...
edu/
str/descriptions/
deda
...

Domain analysis is the ﬁrst technical activity in a broader discipline that some call
domain engineering
...
The goal is to be able to create software within the domain with
a very high percentage of reusable components
...

21
...
Although the terminology, notation, and

580

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

activities differ from conventional methods, OOA (at its kernel) addresses the same
underlying objectives
...
[RUM91] discuss this when they state:
Analysis
...
The purpose of object-oriented analysis is to model the real
world so that it can be understood
...
You must abstract real-world features ﬁrst,
and defer small details until later
...
Monarchi and Puhr [MON92] deﬁne a set of generic
representational components that appear in all OO analysis models
...
These characteristics distinguish one object from
other objects
...
They deﬁne how one object interacts with other objects over time
...
A taxonomy of typical classes was identi-

?

What are the
key
components of an
OOA model?

ﬁed in Chapter 20
...
These classes persist throughout
the life of the application and are derived based on the semantics of the customer requirements
...
Every class must be explicitly described
...

Static view of relationships
...
The analysis model must represent these relationships so
that operations (that affect these connections) can be identiﬁed and the
design of a messaging approach can be accomplished
...

Dynamic components
are inﬂuenced by
timing and events
...
The relationships just noted deﬁne a set of
behaviors that accommodate the usage scenario (use-cases) of the system
...

Dynamic view of communication
...
The nature and timing of events that
cause transitions among states must be described
...

CHAPTER 21

O B J E C T- O R I E N T E D A N A LY S I S

581

De Champeaux, Lea, and Faure [CHA93] deﬁne a slightly different view of OOA
representations
...
A dynamic view of object internals can be characterized as an object life history; that is, the states of the object change over time as
various operations are performed on its attributes
...
4

THE OOA PROCESS
The OOA process does not begin with a concern for objects
...
Once
the scenario of usage has been deﬁned, the modeling of the software begins
...

21
...
1 Use-Cases
As we noted in Chapter 11, use-cases model the system from the end-user’s point of
view
...
See Chapter 11
for additional
information
...

•

To provide a clear and unambiguous description of how the end-user and the
system interact with one another
...

During OOA, use-cases serve as the basis for the ﬁrst element of the analysis model
...
Like many elements of the analysis model, the use-case diagram can be represented at many levels of abstraction
...
Actors are entities that interact with the system
...

To illustrate the development of a use-case diagram, we consider the use-cases
for the SafeHome security system described in Section 11
...
4
...

For the purpose of this example, only the homeowner is considered
...
2A depicts a high-level use-case diagram for the homeowner
...
2A, two use-cases are identiﬁed (represented by ovals)
...
For

582

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

F I G U R E 21
...
2B represents a use-case diagram that elaborates the interacts
function
...
A detailed discussion of use-case modeling using UML is best left to books (e
...
, [ERI98], [ALH98])
dedicated to this OOA method
...
4
...
Classresponsibility-collaborator (CRC) modeling [WIR90] provides a simple means for
identifying and organizing the classes that are relevant to system or product requirements
...
The cards
are divided into three sections
...

In the body of the card you list the class responsibilities on the left and the collaborators on
the right
...
The intent is
to develop an organized representation of classes
...
Stated simply, a responsibility is “anything the class knows or does” [AMB95]
...

In general, a collaboration implies either a request for information or a request for
some action
...
To
summarize, objects manifest themselves in a variety of forms (Section 20
...
1): external entities, things, occurrences, or events; roles; organizational units; places; or
structures
...
All
nouns become potential objects
...

Six selection characteristics were deﬁned:

? How do I
determine
whether a
potential object is
worthy of
inclusion on a CRC
index card?

1
...
The potential object will be useful during analysis
only if information about it must be remembered so that the system can
function
...
Needed services
...

3
...
During requirements analysis, the focus should be on
"major" information; an object with a single attribute may, in fact, be useful
during design but is probably better represented as an attribute of another
object during the analysis activity
...
Common attributes
...

5
...
A set of operations can be deﬁned for the potential
object and these operations apply to all occurrences of the object
...
Essential requirements
...

A potential object should satisfy all six of these selection characteristics if it is to be
considered for inclusion in the CRC model
...

Property classes represent some important property of the problem
environment (e
...
, credit rating within the context of a mortgage loan
application)
...
g
...

In addition, objects and classes may be categorized by a set of characteristics:
Tangibility
...
g
...
g
...
Is the class atomic (i
...
, it includes no other classes) or is it
aggregate (it includes at least one nested object)?
Sequentiality
...
e
...
Is the class transient (i
...
, it is created and removed during program operation), temporary (it is created during program operation and
removed once the program terminates), or permanent (it is stored in a
database)?
Integrity
...
e
...
e
...
3)
...
To summarize, attributes represent stable features of a class;
that is, information about the class that must be retained to accomplish the objectives of the software speciﬁed by the customer
...

the statement of scope or discerned from an understanding of the nature of the class
...
All verbs become candidate operations
...

Wirfs-Brock and her colleagues [WIR90] suggest five guidelines for allocating
responsibilities to classes:

CHAPTER 21

F I G U R E 21
...
g
...
g
...
System intelligence should be evenly distributed
...
This intelligence can be distributed across

responsibilities to
a class?

responsibilities) can be modeled to act as servants to a few “smart” classes

classes in a number of different ways
...
Although this approach makes the ﬂow
of control in a system straightforward, it has a few disadvantages: (1) It concentrates all intelligence within a few classes, making changes more difﬁcult, and (2) it tends to require more classes, hence more development
effort
...
Because each object knows about and does only
a few things (that are generally well focused), the cohesiveness of the system is improved
...

To determine whether system intelligence is evenly distributed, the

If a class has an
extraordinarily long list
of responsibilities, you
should consider
partitioning its
deﬁnition into more
than one class
...
This
indicates a concentration of intelligence
...
For example, among
the operations listed for an aggregate class called checking account a
reviewer notes two responsibilities: balance-the-account and check-off-

586

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

cleared-checks
...
The second is a simple clerical activity
...

2
...
This
guideline implies that general responsibilities (both attributes and operations)
should reside high in the class hierarchy (because they are generic, they will
apply to all subclasses)
...

3
...
This achieves the OO principle that we have called encapsulation (Chapter 20)
...

4
...
A single class should take on the
responsibility for storing and manipulating a speciﬁc type of information
...
If
information is distributed, software becomes more difﬁcult to maintain and
more challenging to test
...
Responsibilities should be shared among related classes, when
appropriate
...
As an example, consider
a video game that must display the following objects: player, player-body,
player-arms, player-legs, player-head
...
g
...
The responsibilities update and
display must therefore be shared by each of the objects noted
...
It collaborates with the
other objects to achieve a new position or orientation, but each object controls its own display
...

Wirfs-Brock and her colleagues [WIR90] deﬁne collaborations in the following way:
Collaborations represent requests from a client to a server in fulﬁllment of a client responsibility
...

...
A single collaboration ﬂows in one direction—
representing a request from the client to the server
...

Collaborations identify relationships between classes
...
The
collaboration involves
the passing of
messages
...

Collaborations are identiﬁed by determining whether a class can fulﬁll each responsibility itself
...
Hence, a collaboration
...
7 As part of the activation procedure (see the use-case for activation in Section 11
...
4), the control panel object
must determine whether any sensors are open
...
If sensors are open control panel must set a status attribute
to “not ready
...
Therefore, the responsibility determine-sensor-status can be fulﬁlled only if control panel
works in collaboration with sensor
...
By creating a class-relationship diagram (Section 21
...
4), the analyst develops the connections necessary to identify these relationships
...

All classes that are part of an aggregate class are connected to the aggregate class
via an is-part-of relationship
...

When one class must acquire information from another class, the has-knowledgeof relationship is established
...

The depends-upon relationship implies that two classes have a dependency that
is not achieved by has-knowledge-of or is-part-of
...
An attribute of the
player-head object called center-position is determined from the center position of
player-body
...
Hence, player-head depends-upon player-body
...
Therefore, the index
card contains a list of responsibilities and the corresponding collaborations that enable
the responsibilities to be fulﬁlled (Figure 21
...

7

See Section 20
...

588

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

When a complete CRC model has been developed, the representatives from the
customer and software engineering organizations can review the model using the
following approach [AMB95]:

? What is an
effective
approach for
reviewing a CRC
model?

1
...
Cards that collaborate should be separated (i
...
, no
reviewer should have two cards that collaborate)
...
All use-case scenarios (and corresponding use-case diagrams) should be
organized into categories
...
The review leader reads the use-case deliberately
...
For example, a use-case for SafeHome contains
the following narrative:
The homeowner observes the SafeHome control panel to determine if the system is
ready for input
...
[A not-ready indicator implies
that a sensor is open, i
...
, that a door or window is open
...
The
phrase “implies that a sensor is open” requires that the index card contains a
responsibility that will validate this implication (the responsibility determinesensor-status accomplishes this)
...
The token is then passed to the sensor object
...
When the token is passed, the holder of the class card is asked to describe
the responsibilities noted on the card
...

5
...
This may
include the deﬁnition of new classes (and corresponding CRC index cards) or
the speciﬁcation of new or revised responsibilities or collaborations on existing cards
...
When all use-cases (or
use-case diagrams) have been reviewed, OOA continues
...
4
...
Using UML notation, a variety of class diagrams can be
created
...

To illustrate, consider the sensor object deﬁned for SafeHome, shown in Figure
21
...
Here, the generalization class, sensor, is reﬁned into a set of specializations—

CHAPTER 21

589

O B J E C T- O R I E N T E D A N A LY S I S

F I G U R E 2 1
...
The attributes and operations
noted for the sensor class are inherited by the specializations of the class
...

In other cases, an object represented in the initial model might actually be composed of a number of component parts that could themselves be deﬁned as objects
...
5
...
It should be noted that the connecting lines may be augmented with
additional symbols (not shown) to represent cardinality
...

Control panel

Keypad
F I G U R E 21
...
The expansion of each class
provides needed detail for review and for subsequent design
...
4
...
For this reason, it is necessary to deﬁne a concise representation that
is a digest of the CRC and structure models just described
...

When a group of all classes collaborate among themselves to accomplish a set of
cohesive responsibilities, they are often referred to as subsystems or packages (in UML
terminology)
...
When viewed from the outside, a subsystem can be treated as a black box that contains a set of responsibilities and that
has its own (outside) collaborators
...
A contract is a speciﬁc list of requests that collaborators can make of the subsystem
...
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
...
For example, assume that the control panel for SafeHome is considerably more complex that the one implied by Figure 21
...
It might be modeled
as the composite aggregate structure shown in Figure 21
...
If the overall requirements model contains dozens of these structures (SafeHome would not), it would be
difﬁcult to absorb the entire representation at one time
...
Package references can be created for any structure that has multiple objects
...
7
...
Structures for the control panel and sensor objects (Figures 21
...
6) are shown in the ﬁgure; structures for system, sensor event
and audible alarm would also be created
...
7 represent dependence relationships between the packages shown
...
The solid arrows represent composition
...

8

Recall that classes interact using a client/server philosophy
...

CHAPTER 21

F I G U R E 21
...
Control panel
Control panel

Subsystem
(package)
reference

Keys

Keypad

Display area

FKs
LCD display

21
...
The ﬁrst step in establishing relationships is to understand the responsibilities for each class
...

The next step is to deﬁne those collaborator classes that help in achieving each responsibility
...

A relationship exists between any two classes that are connected
...
The most common type of relationship is
binary—a connection exists between two classes
...

9 Other terms for relationship are association [RUM91] and connection [COA91]
...

592

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

SafeHome

6
...
System

3
...
Audible alarm

4
...
7 An analysis model with package references

Rumbaugh and his colleagues [RUM91] suggest that relationships can be derived
by examining the stative verbs or verb phrases in the statement of scope or use-cases
for the system
...
These provide an indication of
a relationship
...
8
Relationships
between
objects

593

O B J E C T- O R I E N T E D A N A LY S I S

Contains

Polls

System

Control panel
1:1

1:1

Sensor
1:1

1:m

1:1

1:1

Recognizes

Produces
0:n

0:k
Audible
alarm

Sensor
event

The Uniﬁed Modeling Language notation for the object-relationship model makes
use of a symbology that has been adapted from the entity-relationship modeling techniques discussed in Chapter 12
...
The cardinality of the connection (see Chapter 12) is speciﬁed and an overall network of relationships is established
...
Using the CRC index cards, a network of collaborator objects can be
drawn
...
8 represents the class connections for SafeHome objects
...

2
...
To
avoid ambiguity, an arrow head indicates the “direction” of the relationship
(Figure 21
...

3
...
8)
...
For example, the SafeHome system contains a single control panel (the 1:1 cardinality notation indicates this)
...
However,
there may be many sensors present (the 1:m notation indicates this)
...
g
...

The steps just noted continue until a complete object-relationship model has been
produced
...
Not only are the relationships between objects
identiﬁed, but all important message paths are deﬁned (Chapter 20)
...
7, we made reference to the arrows that connected package symbols
...
Each arrow implies the interchange of messages
among subsystems in the model
...
6

T H E O B J E C T - B E H AV I O R M O D E L
The CRC model and the object-relationship model represent static elements of the
OO analysis model
...
To accomplish this, we must represent the behavior of the
system as a function of speciﬁc events and time
...
To create the model, the analyst must perform the following steps:

? What are
the steps
required to build
an object-behavior
model?

1
...
4
...

2
...

3
...

4
...

5
...

Each of these steps is discussed in the sections that follow
...
6
...
4
...
In general, an event occurs whenever an OO system
and an actor (recall that an actor can be a person, a device, or even an external system) exchange information
...
That is, an event is not the information
that has been exchanged but rather the fact that information has been exchanged
...
To illustrate, reconsider the use-case for SafeHome described in Section 11
...
4:
1
...
2) to determine if the
system is ready for input
...
[A not-ready indicator implies that a
sensor is open, i
...
, that a door or window is open
...
The homeowner uses the keypad to key in a four-digit password
...
If the password is incorrect, the con-

CHAPTER 21

O B J E C T- O R I E N T E D A N A LY S I S

595

trol panel will beep once and reset itself for additional input
...

3
...
Stay activates
only perimeter sensors (inside motion detecting sensors are deactivated)
...

4
...

The underlined portions of the use-case scenario indicate events
...

As an example of a typical event, consider the underlined use-case phrase “homeowner uses the keypad to key in a four-digit password
...
The event might be called password entered
...
It is important to note that some events have an explicit impact
on the ﬂow of control of the use-case, while others have no direct impact on the ﬂow
of control
...

Once all events have been identiﬁed, they are allocated to the objects involved
...
g
...
g
...

21
...
2 State Representations
In the context of OO systems, two different characterizations of states must be considered: (1) the state of each object as the system performs its function and (2) the
state of the system as observed from the outside as the system performs its function
...
A

As you begin to
identify states, focus
on externally
observable modes of
behavior
...

passive state is simply the current status of all of an object’s attributes
...
g
...
The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing
...
An event (sometimes called a trigger) must occur to force
an object to make a transition from one active state to another
...
9
A
representation
of active state
transitions

Compare password = incorrect

Control
panel

Password entered

Control
panel

Control
panel

"Re-enter"
Compare password = incorrect
Compare password = correct

"At rest"

"Comparing"

Activation successful

Control
panel

"Selecting"

an object-behavior model is a simple representation of the active states for each
object and the events (triggers) that cause changes between these active states
...
9 illustrates a simple representation of active states for the control panel
object in the SafeHome system
...
9 represents a transition from one active state of
an object to another
...
Although the active state model provides useful insight into the
“life history” of an object, it is possible to specify additional information to provide
more depth in understanding the behavior of an object
...
A guard is a Boolean condition that must be satisﬁed in order for the transition to occur
...
9 can be determined by examining the use-case:
if (password input = 4 digits) then make transition to comparing state;

In general, the guard for a transition usually depends upon the value of one or more
attributes of an object
...

An action occurs concurrently with the state transition or as a consequence of it
and generally involves one or more operations (responsibilities) of the object
...
9) is an operation that accesses a password object and performs a digit-by-digit comparison to
validate the entered password
...
10
A partial event
trace for SafeHome

597

O B J E C T- O R I E N T E D A N A LY S I S

Homeowner

Control panel

System

System ready
Enters password
Initiates beep
Beep sounded
Ready for activation/deactivation
Selects stay/away
Activate/deactivate sensors
Sensors activated/deactivated
Red light on request
Red light on
Ready for next action

The second type of behavioral representation for OOA considers a state representation for the overall product or system
...

Once events have been identiﬁed for a use-case, the analyst creates a represen-

A transition from one
state to another
requires that an event
occur
...

tation of how events cause ﬂow from one object to another
...
It represents key objects and
the events that cause behavior to ﬂow from object to object
...
10 illustrates a partial event trace for the SafeHome system
...
The ﬁrst event, system ready, is derived
from the external environment and channels behavior to the homeowner object
...
The event initiates beep and “beep sounded” and
indicates how behavior is channeled if the password is invalid
...
The remaining events and traces follow the
behavior as the system is activated or deactivated
...
This can be represented using an event ﬂow diagram [RUM91]
...
11
...

598

PA R T F O U R

System
ready

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Selects stay/away
Enters password
Control
panel

Homeowner
Ready for next action
Ready for activation/deactivation
Beep sounded
Sensors activated/deactivated
Red light on

Initiates beep
Activate/deactivate sensors
Red light on request

System

F I G U R E 2 1
...
A complete discussion of these graphical representations and the language descriptions that underlie
them is beyond the scope of this book
...

21
...
Like earlier OO analysis methods, the
Uniﬁed Modeling Language builds an analysis model that has the following characteristics: (1) representation of classes and class hierarchies, (2) creation of objectrelationship models, and (3) derivation of object-behavior models
...
At the business or enterprise level, the techniques associated with OOA can be
coupled with a business process engineering approach
...
At an application level, the object model focuses on speciﬁc customer requirements as those requirements affect the application to be built
...
The class-responsibility-collaborator modeling technique is then applied to document classes and their attributes and operations
...
The next step
in the OOA process is classiﬁcation of objects and the creation of a class hierarchy
...
The objectrelationship model provides an indication of how classes are connected to one another,
and the object-behavior model indicates the behavior of individual objects and the
overall behavior of the OO system
...
S
...

[AMB95] Ambler, S
...
53–61
...
and R
...
and R
...
), IEEE Computer Society Press, 1989
...
, S
...
Farmer, Object Oriented System Analysis and
Design Using UML, McGraw-Hill, 1999
...
V
...

[BOO94] Booch, G
...
, Benjamin Cummings, 1994
...
, I
...
Rumbaugh, The Uniﬁed Modeling Language User
Guide, Addison-Wesley, 1999
...
, Developing Business Objects, SIGS Books, 1998)
...
, D
...
Faure, Object-Oriented System Development, Addison-Wesley, 1993
...
and E
...
, Prentice-Hall,
1991
...
and O
...

[ERI98]

Eriksson, H
...
and M
...

[FIC92]

Fichman, R
...
and C
...
Kemerer, “Object-Oriented and Conventional Analy-

sis and Design Methodologies,” Computer, vol
...
10, October 1992, pp
...

[FIN96]

Fingar, P
...

[FIR93]

Firesmith, D
...
, Object-Oriented Requirements Analysis and Logical Design,

Wiley, 1993
...
, Object-Oriented Methods, Addison-Wesley, 1994
...
, Object-Oriented Software Engineering, Addison-Wesley, 1992
...
, G
...
Rumbaugh, Uniﬁed Software Development Process,

Addison-Wesley, 1999
...
, The Object-Oriented Enterprise, McGraw-Hill, 1994
...
E
...
I
...
35, no
...
35–47
...
, et al
...

[RUM99] Rumbaugh, J
...
Jacobson, and G
...

[SUL94] Sullo, G
...
, Object Engineering, Wiley, 1994
...
A
...

[WIR90] Wirfs-Brock, R
...
Wilkerson, and L
...

600

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

PROBLEMS AND POINTS TO PONDER
21
...
Obtain one or more books dedicated to the Uniﬁed Modeling Language and
compare it to structured analysis (Chapter 12) using the modeling dimensions proposed by Fichman and Kemerer [FIC92] in Section 21
...
1
...
2
...
Present the diagram in the context of a simple example, but provide
enough detail to demonstrate most important aspects of the diagrammatic form
...
3
...
A university student record-keeping system
...
An e-commerce application (e
...
, clothes, books, electronic gear)
...
Customer service for a bank
...
A video game developer
...
An application area suggested by your instructor
...

21
...
In your own words describe the difference between static and dynamic views
of an OO system
...
5
...
The usecase should address the scenario required to deﬁne a security zone
...
As many as ten security zones can be deﬁned
...

21
...
Develop a set of use-cases for the PHTRS system introduced in Problem 12
...

You’ll have to make a number of assumptions about the manner in which a user interacts with this system
...
7
...
Software for a general-purpose personal digital assistant
...
Software for a video game of your choosing
...
Software that sits inside a climate control system for a car
...
Software for a navigation system for a car
...
A system (product) suggested by your instructor
...

CHAPTER 21

O B J E C T- O R I E N T E D A N A LY S I S

601

21
...
Develop a complete set of CRC model index cards on the product or system
you chose as part of Problem 21
...

21
...
Conduct a review of the CRC index cards with your colleagues
...
10
...
7
...
11
...
7
...
12
...
7
...
13
...
7
...

21
...
In your own words, describe how collaborators for a class are determined
...
15
...
16 What role does cardinality play in the development of an object-relationship
model?
21
...
What is the difference between an active and a passive state for an object?

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
Use-cases form the foundation of object-oriented analysis, regardless of the OOA
method that is chosen
...

Virtually every recent book published on object-oriented analysis and design emphasizes UML
...
In addition, the following books are representative of dozens
written on UML technology:
Douglass, B
...

602

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Fowler, M
...
Scott, UML Distilled, 2nd ed
...

Odell, J
...
and M
...

Oestereich, B
...

A wide variety of information sources on object-oriented analysis and related subjects is available on the Internet
...
mhhe
...
mhtml

CHAPTER

22
KEY
CONCEPTS
component-level
design
...
614

OBJECT-ORIENTED DESIGN

bject-oriented design transforms the analysis model created using
object-oriented analysis (Chapter 21) into a design model that serves
as a blueprint for software construction
...
Gamma and his colleagues [GAM95] provide a reasonably accurate picture of OOD when they state:

O

design criteria
...
624

software is even harder
...
604

the right granularity, deﬁne class interfaces and inheritance hierarchies, and estab-

object design
...
608
OOD pyramid
...
Your design should be speciﬁc to the problem at
hand but also general enough to address future problems and requirements
...
Experienced object-oriented designers will tell you that a reusable and ﬂexible design is difﬁcult if not impossible to get

OO programming 625

"right" the ﬁrst time
...
619

times, modifying it each time
...
612
system design
...
610

Unlike conventional software design methods, OOD results in a design that
achieves a number of different levels of modularity
...
” Data and the operations that manipulate the data are encapsulated into objects—a modular form

What is it? The design of object-

to be built from scratch, but many others may be

oriented software requires the def-

reused if appropriate design patterns are recog-

inition of a multilayered software

nized
...

a description of the communication mechanisms

What are the steps? OOD is divided into two major

that allow data to flow between layers, subsys-

activities: system design and object design
...
Object-oriented design accom-

tem design creates the product architecture, deﬁn-

plishes all of these things
...

system functions and identifying the classes that
are encapsulated by subsystems that reside at

Why is it important? An object-oriented system draws

each layer
...
Some of these deﬁnitions will have

interface, data management functions, and task

603

604

PA R T F O U R

QUICK
LOOK

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

management facilities
...

How do I ensure that I’ve done it right? At each stage,

ing attributes, operations, and message detail
...

that is the building block of an OO system
...
These represent data and algorithmic pieces of an OO system and are
contributors to overall modularity
...
All design methods strive for software that
exhibits these fundamental characteristics, but only OOD provides a mechanism that
enables the designer to achieve all four without complexity or compromise
...
In this chapter, we consider the ﬁrst
step in construction
...
1

DESIGN FOR OBJECT-ORIENTED SYSTEMS
In Chapter 13, we introduced the concept of a design pyramid for conventional software
...
For object-oriented systems, we can also deﬁne a design pyramid, but the layers are a bit different
...
1, the four layers of the
OO design pyramid are
The subsystem layer contains a representation of each of the subsystems
that enable the software to achieve its customer-deﬁned requirements and to
implement the technical infrastructure that supports customer requirements
...
”
Ivar Jacobson,
Grady Booch, and
James Rumbaugh

The class and object layer contains the class hierarchies that enable the
system to be created using generalizations and increasingly more targeted
specializations
...

The message layer contains the design details that enable each object to
communicate with its collaborators
...

The responsibilities layer contains the data structure and algorithmic
design for all attributes and operations for each object
...
1
The OO design
pyramid

Responsibilities
design

Message
design
Class and object
design

Subsystem
design

The design pyramid focuses exclusively on the design of a speciﬁc product or system
...
The foundation layer focuses on
the design of domain objects (called design patterns later in this chapter)
...
Domain objects can also be used to ﬂesh out the design of the application
itself
...
1
...
OO Approaches
Conventional approaches to software design apply a distinct notation and set of
heuristics to map the analysis model into a design model
...
1, each
element of the conventional analysis model maps into one or more layers of the
design model
...
It is important
to note that the architecture of an OO design has more to do with the collaborations
among objects than with the ﬂow of control between components of the system
...
Figure 22
...
1
1

It is important to note that the derivation is not always straightforward
...

606

At
tri
bu

PA R T F O U R

s
te

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

c o ll a b o r at
tions,
or s
era
op
,

CRC
index
cards

Responsibilities
design

Objectrelationship
model
Message
design

Use cases

Class and object
design
Object-behavior
model
Subsystem
design

The analysis model

The design model

F I G U R E 22
...
Class and object design is mapped from the description of attributes, operations, and collaborations contained in the CRC model
...

Fichman and Kemerer [FIC92] suggest ten design modeling components that may
be used to compare various conventional and object-oriented design methods:

? What can
criteria
be used to
compare
conventional and
OOD methods?

1
...

2
...

3
...

4
...

5
...

6
...

7
...

8
...

9
...

10
...

CHAPTER 22

O B J E C T- O R I E N T E D D E S I G N

607

Because many conventional and object-oriented design approaches are available, it
is difﬁcult to develop a generalized comparison between the two methods
...

22
...
2 Design Issues
Bertrand Meyer [MEY90] suggests ﬁve criteria for judging a design method's ability
to achieve modularity and relates these to object-oriented design:
•

to decompose a large problem into subproblems that are easier to solve
...
kinetica
...
html

Decomposability—the facility with which a design method helps the designer

•

Composability—the degree to which a design method ensures that program
components (modules), once designed and built, can be reused to create
other systems
...

•

Continuity—the ability to make small changes in a program and have these
changes manifest themselves with corresponding changes in just one or a
very few modules
...

? What basic
principles

From these criteria, Meyer [MEY90] suggests ﬁve basic design principles that can be

guide us in the
design of modular
architectures?

small interfaces (weak coupling), (4) explicit interfaces, and (5) information

derived for modular architectures: (1) linguistic modular units, (2) few interfaces, (3)
hiding
...
That is, the programming language to be
used should be capable of supporting the modularity deﬁned directly
...
g
...
But if a package that contains data structures and procedures and identiﬁes them as a single unit were deﬁned,
a language such as Ada (or another object-oriented language) would be necessary
to directly represent this type of component in the language syntax
...
Whenever components do communicate, they should do so in an obvious and direct way ("explicit interfaces")
...
Finally, we

608

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

achieve the principle of information hiding when all information about a component
is hidden from outside access, unless that information is speciﬁcally deﬁned as public information
...
g
...
As we will see, however, the object-oriented design method achieves each of the criteria more efﬁciently
than other approaches and results in modular architectures that allow us to meet
each of the modularity criteria most effectively
...
1
...
These methods established the foundation for modern OOD notation, design heuristics, and models
...
As we noted in Chapter 21, the Booch method
[BOO94] encompasses both a “micro development process” and a “macro
development process
...
Design is
hard
...
Micro development deﬁnes a set of
“rules” that govern the use of operations and attributes and the domain-speciﬁc policies for memory management, error handling, and other infrastructure functions; develops scenarios that describe the semantics of the rules
and policies; creates a prototype for each policy; instruments and reﬁnes the
prototype; and reviews each policy so that it “broadcasts its architectural
vision” [BOO94]
...
The object modeling technique [RUM91] encompasses a design activity that encourages design to be conducted at two different levels of abstraction
...
The
analysis model is partitioned into subsystems, which are then allocated to
processors and tasks
...

Object design emphasizes the detailed layout of an individual object
...
Data structures that are appropriate for attributes and algorithms are represented
...
A messaging model is created to implement the object relationships (associations)
...
The design activity for OOSE (object-oriented software engineering) [JAC92] is a simpliﬁed version of the proprietary objectory
method, also developed by Jacobson
...
First, the idealized analysis model is
adapted to ﬁt the real world environment
...
Communication between blocks during execution is
deﬁned and the blocks are organized into subsystems
...
The Coad and Yourdon method for OOD
[COA91] was developed by studying how “effective object-oriented designers” do their design work
...

The Wirfs-Brock method
...

design
...
Each operation (responsibility) and protocol (interface
design) is designed at a level of detail that will guide implementation
...

Although the terminology and process steps for each of these OOD methods differ, the overall OOD processes are reasonably consistent
...
Describe each subsystem and allocate it to processors and tasks
...

2
...

3
...

4
...

5
...

6
...

7
...

2

A block is the design abstraction that allows for the representation of an aggregate object
...

610

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

It is important to note that the design steps discussed in this section are iterative
...

22
...
4 A Uniﬁed Approach to OOD
In Chapter 21, we noted that Grady Booch, James Rumbaugh, and Ivar Jacobson combined the best features of their individual object-oriented analysis and design meth-

WebRef
An extensive tutorial and
listing of UML resources
including tools, papers,
and examples can be
found at
mini
...
html

ods into a uniﬁed method
...
4
During analysis modeling (Chapter 21), the user model and structural model views
are represented
...

UML is organized into two major design activities: system design and object design
...

Bennett, McRobb, and Farmer [BEN99] discuss this issue in the following way:
In terms of object-oriented development, the conceptual architecture is concerned with the
structure of the static class model and the connections between components of the model
...
The code architecture
defines how the program code is organized into files and directories and grouped into
libraries
...

The deﬁnition of the “subsystems” noted by Bennett et al
...
Object
design describes
objects at a level of
detail that can be
implemented in a
programming
language
...

UML object design focuses on a description of objects and their interactions with
one another
...
The visibility5 for all class
attributes is deﬁned and interfaces between objects are elaborated to deﬁne the details
of a complete messaging model
...
User interface design in UML draws on the same concepts and
principles discussed in Chapter 15
...
6

4
5

6

Booch, Rumbaugh, and Jacobson have written a set of three deﬁnitive books on UML
...

Visibility indicates whether an attribute is public (available across all instantiations of the class),
private (available only for the class that speciﬁes it), or protected (an attribute that may be used
by the class that speciﬁes it and its subclasses)
...
This expedites the design and implementation of GUIs
...
3
Process ﬂow for
OOD
Object-oriented
analysis
System
design

Task management
design
Object
design

Data management
design
Human interface
design

Data management design establishes a set of classes and collaborations that allow the
system (product) to manage persistent data (e
...
, ﬁles and databases)
...
The process ﬂow for design is illustrated in
Figure 22
...
7
Throughout the UML design process, the user model view and structure model
view are elaborated into the design representation outlined above
...

22
...
The system design process encompasses the following activities:

?

What are
the steps of
the system design
process?

•
•

Identify concurrency that is dictated by the problem
...

•

Develop a design for the user interface
...

•
7

Partition the analysis model into subsystems
...

Recall that OOA is an iterative activity
...

612

PA R T F O U R

•

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Design an appropriate control mechanism for the system, including task
management
...

•

Review and consider trade-offs
...

22
...
1 Partitioning the Analysis Model
One of the fundamental analysis principles (Chapter 11) is partitioning
...
Strive
to achieve good
functional
independence as you
design subsystems
...
These design elements are packaged as a subsystem
...

They all may be involved in accomplishing the same function; they may reside within
the same product hardware, or they may manage the same class of resources
...
When used in the OO system design
context, a service is a collection of operations that perform a speciﬁc function (e
...
,
managing word-processor ﬁles, producing a three-dimensional rendering, translating an analog video signal into a compressed digital image)
...

•

With the exception of a small number of “communication classes,” the
classes within a subsystem should collaborate only with other classes within
the subsystem
...

•

A subsystem can be partitioned internally to help reduce complexity
...
In a client/server link, each of the
subsystems takes on one of the roles implied by client and server
...
In a peer-to-peer link, services may ﬂow in either
direction
...
Each layer [BUS96] of an OO system contains one or more subsystems and represents a different level of abstraction of the functionality required
to accomplish system functions
...

CHAPTER 22

O B J E C T- O R I E N T E D D E S I G N

613

For example, a four-layer architecture might might include (1) a presentation layer
(the subsystems associated with the user interface), (2) an application layer (the subsystems that perform the processing associated with the application), (3) a data formatting layer (the subsystems that prepare the data for processing), and (4) a database
layer (the subsystems associated with data management)
...

Buschmann and his colleagues [BUS96] suggest the following design approach for
layering:
1
...
That is, decide how subsystems will be grouped in

? How doa I
create

a layered architecture
...
Determine the number of layers
...

3
...
Be certain that communication between subsystems (classes) on one
layer and other subsystems (classes) at another layer follow the design philosophy for the architecture
...
Design interfaces for each layer
...
Reﬁne the subsystems to establish the class structure for each layer
...
Deﬁne the messaging model for communication between layers
...
Review the layer design to ensure that coupling between layers is minimized
(a client/server protocol can help accomplish this)
...
Iterate to reﬁne the layered design
...
2
...
If classes (or subsystems) are not active at the

In most cases, a multiprocessor
implementation
increases complexity
and technical risk
...

same time, there is no need for concurrent processing
...
On the other
hand, if classes (or subsystems) must act on events asynchronously and at the same
time, they are viewed as concurrent
...

Concurrent tasks are deﬁned [RUM91] by examining the state diagram for each
object
...
The thread of control

8

In a closed architecture, messages from one layer may be sent only to the adjacent lower layer
...

614

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

continues even when one object sends a message to another object, as long as the
ﬁrst object waits for a response
...

Tasks in an OO system are designed by isolating threads of control
...
Since the
objects involved in both of these behaviors are active at the same time, each represents a separate thread of control and each can be defined as a separate task
...

To determine which of the processor allocation options is appropriate, the designer
must consider performance requirements, costs, and the overhead imposed by interprocessor communication
...
2
...

•

A coordinator task and associated objects are deﬁned
...

The characteristics of a task are determined by understanding how the task is initiated
...
Both

“Discipline and
focused awareness

...
”
John Poppy

are activated by an interrupt, but the former receives an interrupt from some outside
source (e
...
, another processor, a sensor) while that latter is governed by a system
clock
...
High-priority tasks must have immediate access
to system resources
...

Once the characteristics of the task have been determined, object attributes and
operations required to achieve coordination and communication with other tasks are
deﬁned
...
g
...

CHAPTER 22

O B J E C T- O R I E N T E D D E S I G N

615

22
...
4 The User Interface Component
Although the user interface component is implemented within the context of the problem domain, the interface itself represents a critically important subsystem for most
modern applications
...
The design of
the interface follows
the approach deﬁned in
Chapter 15
...
These serve as input to the user interface design process
...
The command hierarchy deﬁnes major system menu categories (the menu bar or
tool palette) and all subfunctions that are available within the context of a major system menu category (the menu windows)
...

Because a wide variety of user interface development environments already exist,
the design of GUI elements is not necessary
...
The implementer need only instantiate objects
that have appropriate characteristics for the problem domain
...
2
...
In general, data management is designed in
a layered fashion
...

Within the system context, a database management system is often used as a common data store for all subsystems
...
A detailed discussion of database
design for OO systems is beyond the scope of this book
...
The relevant attributes are appended
to every object in the problem domain and provide information that answers the question, “How do I store myself?” Coad and Yourdon [COA91] suggest the creation of an
object-server class “with services to (a) tell each object to save itself and (b) retrieve
stored objects for use by other design components
...
” Each
record would correspond to a named instance of sensor and would contain the values of each sensor attribute for that named instance
...

616
F I G U R E 22
...
For more complex objects, it might be necessary to specify a relational
database or an object-oriented database to accomplish the same function
...
2
...
Global system
resources can be external entities (e
...
, a disk drive, processor, or communication
line) or abstractions (e
...
, a database, an object)
...
Rumbaugh
and his colleagues [RUM91] suggest that each resource should be owned by a
“guardian object
...

22
...
7 Intersubsystem Communication
Once each subsystem has been speciﬁed, it is necessary to deﬁne the collaborations
that exist between the subsystems
...
Figure 22
...
As we noted earlier in this chapter, communication can occur by
establishing a client/server link or a peer-to-peer link
...
Recall that a contract provides an indication of the ways in which one subsystem can interact with another
...
List each request that can be made by collaborators of the subsystem
...
Be sure to note contracts that are inherited from
superclasses
...
5 Subsystem collaboration table

2
...
Be sure to associate the operations with speciﬁc classes that reside
within a subsystem
...
Considering one contract at a time, create a table of the form shown
in Figure 22
...
For each contract, the following entries are made in the

Every contract between
subsystems is
manifested by one or
more messages that
move between objects
within the subsystems
...
e
...

Collaborators—the names of the subsystems that are parties to the contract
...

Operation—the names of the operations (within the class) that implement
the services
...

Draft an appropriate message description for each interaction between the
subsystems
...
If the modes of interaction between subsystems are complex, a subsystem-collaboration diagram, illustrated in Figure 22
...

The collaboration graph is similar in form to the event ﬂow diagram discussed in Chapter 21
...
The contracts that are invoked during an
interaction are noted as shown
...
5)

618

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Control
panel
subsystem

Request for system status
Specification of type of alarm
Periodic status check
F I G U R E 22
...
3

Request for status
Assign zone
Test status

Sensor
subsystem

Request for alarm notification
Periodic check-in
Require for configuration update

Central
communication
subsystem

THE OBJECT DESIGN PROCESS
Borrowing from a metaphor that was introduced earlier in this book, the OO system
design might be viewed as the ﬂoor plan of a house
...
It is now time to provide the details that are
required to build each room
...
”
Bennett and his colleagues [BEN99] discuss object design in the following way:
Object design is concerned with the detailed design of the objects and their interactions
...
Object design is particularly concerned with the speciﬁcation of attribute types, how operations function, and how objects are linked to other objects
...
Local data structures are deﬁned (for attributes) and algorithms (for operations) are designed
...
3
...
Don’t
let the architecture just
happen
...
Implementation details include information about the object's
private part; that is, internal details about the data structures that describe the object’s
attributes and procedural details that describe operations
...
For example, a portion of the protocol description for the object motion sensor (described earlier) might be
MESSAGE (motion
...
ID, sensor
...
Similarly,
MESSAGE (motion
...
ID, sensor
...

For a large system with many messages, it is often possible to create message categories
...

An implementation description of an object provides the internal ("hidden") details

To achieve the beneﬁts
of information hiding
(Chapter 13), anyone
who intends to use an
object needs only the
protocol description
...

that are required for implementation but are not necessary for invocation
...
However, another designer or implementer who uses the object or other instances of the object requires only the protocol description but not the implementation description
...
The implementation description must contain sufﬁcient information to provide for proper handling of all messages described in the protocol description
...
A user of the service provided by an object must
be familiar with the protocol for invoking the service; that is, for specifying what is
desired
...

22
...
2 Designing Algorithms and Data Structures
A variety of representations contained in the analysis model and the system design proXRef
Virtually every concept
presented in Chapter 13
is applicable here
...

vide a speciﬁcation for all operations and attributes
...

An algorithm is created to implement the speciﬁcation for each operation
...
However, if the speciﬁcation of
the operation is complex, it may be necessary to modularize the operation
...

620

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Data structures are designed concurrently with algorithms
...

?

Is there a
way to
categorize
operations
(methods)?

Although many different types of operations exist, they can generally be divided
into three broad categories: (1) operations that manipulate data in some way (e
...
,
adding, deleting, reformatting, selecting), (2) operations that perform a computation, and (3) operations that monitor an object for the occurrence of a controlling
event
...
" These two phrases indicate a number of things:
•

That an assign operation is relevant for the sensor object
...

•

That arm and disarm are operations that apply to system (also that system
status may ultimately be deﬁned (using data dictionary notation) as
system status = [armed | disarmed]

The operation program is allocated during OOA, but during object design it will be

An operation is reﬁned
in much the same way
that we reﬁne a
function in
conventional design
...

reﬁned into a number of more speciﬁc operations that are required to conﬁgure the
system
...
The
user can (1) install phone numbers; (2) deﬁne delay times for alarms; (3) build a sensor table
that contains each sensor ID, its type, and location; and (4) load a master password
...
Each of these new operations
becomes part of the system object, has knowledge of the internal data structures
that implement the object's attributes, and is invoked by sending the object messages
of the form
MESSAGE (system) --> install: SENDS telephone
...

Verbs connote actions or occurrences
...
g
...
The grammatical parse is applied recursively until each operation has been reﬁned to its most-detailed level
...
Rumbaugh and
his colleagues [RUM91] suggest three major thrusts for OOD design optimization:
•

Review the object-relationship model to ensure that the implemented design
leads to efﬁcient utilization of resources and ease of implementation
...

•

Revise attribute data structures and corresponding operation algorithms to
enhance efﬁcient processing
...

A detailed discussion of OO design optimization is beyond the scope of this book
...
For a discussion of how
these concepts translate into the UML process, the reader should examine [JAC99]
and [RUM99]
...
3
...

The object-oriented approach deﬁnes the object as a program component that is itself
linked to other components (e
...
, private data, operations)
...
During design, we must also identify the interfaces between
objects and the overall structure (considered in an architectural sense) of the objects
...
To accommodate OOD, the programming language to be used for implementation should be
capable of creating the following program component (modeled after Ada):
PACKAGE program-component-name IS
TYPE speciﬁcation of data objects
•
•
•
PROC speciﬁcation of related operations
...
1 (interface description) IS
•
•
•
END
PROC operation
...
The speciﬁcation part of the component indicates all data objects (declared with the TYPE statement) and the operations (PROC for procedure) that act on them
...
In the context of our earlier discussion, the PACKAGE is conceptually similar to objects discussed throughout this chapter
...
Referring once
again to the SafeHome example, we can deﬁne the highest-level program component
as
PROCEDURE SafeHome software

The SafeHome software component can be coupled with a preliminary design for the
following packages (objects):
PACKAGE system IS
TYPE system data
PROC install, deﬁne, build, load
PROC display, reset, query, modify, call
PRIVATE
PACKAGE BODY system IS
PRIVATE
system
...
number, telephone
...

IS STRING LENGTH (8);
sensor
...
type IS STRING LENGTH (2),
sensor
...
threshold IS NUMERIC;
PROC install RECEIVES (telephone
...
id IS STRING LENGTH (8);
sensor
...
characteristics DEFINED
threshold, signal type, signal level IS NUMERIC,
hardware
...
characteristics, timing
...
The ﬁnal step in the object design process completes all information required to fully implement data structure and types contained
in the PRIVATE portion of the package and all procedural detail contained in the PACKAGE BODY
...
The data structures for sensor attributes have already
been deﬁned
...
id, sensor
...
characteristics, hardware
...
id, sensor
...
characteristics: OUT);

The next step requires stepwise reﬁnement of each operation associated with the
sensor package
...

informal strategy) for read:
When the sensor object receives a read message, the read process is invoked
...
If the threshold is exceeded, the sensor status is set to "event
...
" If an error is sensed while polling the sensor, the sensor status is set to "error
...
id, sensor
...
signal IS BIT STRING
IF (hardware
...
type = "s" & alarm
...
signal
...
status := error) raw
...
signal TO internal
...
level;
IF internal
...
level > threshold
THEN sensor
...
status := "no event";
ENDIF
ELSE {processing for other types of s interfaces would be speciﬁed}
ENDIF
RETURN sensor
...
status;
END read

624

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

The PDL representation of the read operation can be translated into the appropriate
implementation language
...

22
...
For
further discussion, see
Chapter 14
...
Gamma and his colleagues [GAM95] discuss this when they state:
[Y]ou’ll find recurring patterns of classes and communicating objects in many objectoriented systems
...
They help designers reuse successful designs by basing new designs on prior experience
...

Throughout the OOD process, a software engineer should look for every opportunity
to reuse existing design patterns (when they meet the needs of the design) rather
than creating new ones
...
agcs
...
htm

22
...
1 Describing a Design Pattern
Mature engineering disciplines make use of thousands of design patterns
...
Inherent in the pattern are attributes (the diameters of the shaft, the dimensions of the
keyway, etc
...
g
...
An electrical engineer uses an integrated circuit (an extremely complex design pattern) to solve a speciﬁc element of a new problem
...
”
Frank Buschmann
et al
...
Design forces describe the data, functional, or behavioral requirements associated with part of the software for which the

CHAPTER 22

O B J E C T- O R I E N T E D D E S I G N

625

pattern is to be applied
...
In essence, design forces describe the
environment and conditions that must exist to make the design pattern applicable
...
”
William Brown
et al
...
These attributes represent characteristics of the design that
can be searched (e
...
, via a database) so that an appropriate pattern can be found
...

The names of objects and subsystems (potential design patterns) should be chosen with care
...
The search for the “right” pattern is aided
immeasurably by a meaningful pattern name along with a set of characteristics that
help in classifying the object [PRE95]
...
4
...
Inheritance is a fundamental OO con-

The Portland Pattern
Repository publishes an
evolving collection of
design patterns at:
c2
...
Using inheritance, an existing design
pattern becomes a template for a new subclass
...

Composition is a concept that leads to aggregate objects
...
The complex object can be assembled by selecting a set of design patterns and composing the appropriate object (or subsystem)
...

Good design always
strives for simplicity
...

Gamma and his colleagues [GAM95] suggest that object composition should be
favored over inheritance when both options exist
...
Composition uses existing design patterns (reusable components)
in an unaltered form
...
5

OBJECT-ORIENTED PROGRAMMING
Although all areas of object technologies have received signiﬁcant attention within
the software community, no subject has produced more books, more discussion, and

10 Buschmann [BUS96] and Gamma et al
...

626

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

more debate than object-oriented programming (OOP)
...

The software engineering viewpoint stresses OOA and OOD and considers OOP
(coding) an important, but secondary, activity that is an outgrowth of analysis and
design
...
As the complexity of systems increases, the
design architecture of the end product has a significantly stronger influence on its
success than the programming language that has been used
...

The details of OOP are best left to books dedicated to the subject
...

22
...
The OOD process
can be described as a pyramid composed of four layers
...
The class layer
speciﬁes the overall object architecture and the hierarchy of classes required to implement a system
...

Like OOA, there are many different OOD methods
...
UML and other
methods approach the design process through two levels of abstraction—design of
subsystems (architecture) and design of individual objects
...
In addition to developing subsystems, their interactions, and their placement in architectural layers, system design considers the user interaction
component, a task management component, and a data management component
...
The object design process focuses on the
description of data structures that implement class attributes, algorithms that
implement operations, and messages that enable collaborations and object relationships
...
Object-oriented programming extends the design model
into the executable domain
...

CHAPTER 22

O B J E C T- O R I E N T E D D E S I G N

627

REFERENCES
[BEN99] Bennett, S
...
McRobb, and R
...

[BIH92]

Bihari, T
...
Gopinath, “Object-Oriented Real-Time Systems: Concepts

and Examples,” Computer, vol
...
12, December 1992, pp
...

[BOO94] Booch, G
...
, Benjamin Cummings, 1994
...
, I
...
Rumbaugh, The Uniﬁed Modeling Language User
Guide, Addison-Wesley, 1999
...
W
...

[BUS96] Buschmann, F
...
, A System of Patterns: Pattern Oriented System Architecture, Wiley, 1996
...
, D
...
Faure, Object-Oriented System Development, Addison-Wesley, 1993
...
and E
...

[COX85] Cox, B
...

[DAV95] Davis, A
...
30, 1995, pp
...

[DOU99] Douglass, B
...

[FIC92]

Fichman, R
...
Kemerer, "Object-Oriented and Conceptual Design

Methodologies," Computer, vol
...
10, October 1992, pp
...

[GAM95] Gamma, E
...
, Design Patterns, Addison-Wesley, 1995
...
and D
...

[JAC92]

Jacobson, I
...

[JAC99]

Jacobson, I
...
Booch, J
...

[MEY90] Meyer, B
...
, Prentice-Hall,
1988
...
, Design Patterns for Object-Oriented Software Development, AddisonWesley, 1995
...
, et al
...

[RUM99] Rumbaugh, J
...
Jacobson, and G
...

[RAO94] Rao, B
...
, Object-Oriented Databases: Technology, Applications and Products,
McGraw-Hill, 1994
...
A
...

[WIR90] Wirfs-Brock, R
...
Wilkerson, and L
...

628

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

PROBLEMS AND POINTS TO PONDER
22
...
The design pyramid for OOD differs somewhat from the pyramid described for
conventional software design (Chapter 13)
...

22
...
How do OOD and structured design differ? What aspects of these two design
methods are the same?
22
...
Review the ﬁve criteria for effective OO modularity discussed in Section 22
...
2
...

22
...
Using outside references on UML, prepare a one-hour tutorial for your class
...

22
...
Select an older OOD method presented in Section 22
...
3 and prepare a onehour tutorial for your class
...

22
...
Discuss how the use-case can serve as an important source of information for
design
...
7
...
What design patterns are offered and
how are they used?
22
...
Task management for OO systems can be quite complex
...
g
...

22
...
Discuss how the data management component is implemented in a typical
OO development environment
...
10
...

22
...
How does a designer recognize tasks that must be concurrent?
22
...
Apply the OOD approach discussed in this chapter to ﬂesh out the design for
the SafeHome system
...

22
...
Apply OOD approach discussed in this chapter to the PHTRS system described
in Problem 12
...

22
...
Describe a video game and apply OOD approach discussed in this chapter
to represent its design
...
15
...
The e-mail system will enable users to create letters to be mailed to another user, general distribution, or a speciﬁc address list
...
The e-mail system will use existing
word-processing capability to create letters
...

22
...
A small island nation has decided to build an air trafﬁc control (ATC) system
for its one airport
...
The ATC ground station can query an aircraft for speciﬁc information
...
A computer graphics display is created from the stored information and displayed for an air trafﬁc controller
...
All information is analyzed to determine if "dangerous situations"
are present
...

Using OOD, create a design for the ATC system
...
, Prentice-Hall, 1997); Reil (Object-Oriented Design
Through Heuristics, Addison-Wesley, 1996); and Walden and Nerson (Seamless ObjectOriented Software Architecture: Analysis and Design of Reliable Systems, Prentice-Hall,
1995) cover OOD in considerable detail
...

Many recent books published on object-oriented design emphasize UML
...
In addition, many of the books referenced in the Further Reading and Information Sources section of Chapter 21 also address design in considerable detail
...
In addition to [BUS96] and [GAM95],
many recent books are dedicated to the subject:
Ambler, S
...
, Process Patterns: Building Large-Scale Systems Using Object Technology, Cambridge University Press, 1999
...
O
...
C
...

630

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Fowler, M
...

Larman, C
...

Martin, R
...
, et al
...

Rising, L
...
Coplien (eds
...

Pree, W
...

Vlissides, J
...

Vlissides, J
...
, J
...
Coplien, and N
...

Hundreds of books have been published on object-oriented programming
...
P
...

Barclay, K
...
Savage, Object-Oriented Design with C++, Prentice-Hall, 1997
...
and R
...

Jezequel, J
...
, Object-Oriented Software Engineering with Eiffel, Addison-Wesley, 1996
...
, M
...
Kern, Java Design: Building Better Apps and Applets, 2nd ed
...

Lewis, J
...
Loftus, Java Software Solutions: Foundations of Program, AddisonWesley, 1997
...
, Smalltalk by Example: The Developer's Guide, McGraw-Hill, 1997
...
R
...
R
...

Books that cover OOD topics using two or more OO programming languages provide
insight and comparison of language features
...
, Object-Oriented Programming With C++ and Smalltalk, Prentice-Hall, 1998
...
, Objects Unencapsulated: Java, Eiffel and C++, Prentice-Hall, 1999
...
P
...

A wide variety of information sources on object-oriented design and related subjects is available on the Internet
...
mhhe
...
mhtml

CHAPTER

23

OBJECT-ORIENTED TESTING

integration
...
Although this fundamental objective remains unchanged for
object-oriented software, the nature of OO programs changes both testing strategy and testing tactics
...
Exactly the
opposite is true
...
645

[E]ach reuse is a new context of usage and retesting is prudent
...
634

more, not less, testing will be needed to obtain high reliability in object-oriented

OOD review
...

KEY
CONCEPTS
class-level
testing
...
634
fault-based
testing
...
644
random testing
...
641
structure tests
...
637
unit testing
...
The deﬁnition of testing must be broadened to include error discovery techniques (formal technical reviews) applied to OOA and OOD models
...
Unit testing loses much of its meaning, and integration strategies change signiﬁcantly
...

validation
...
In order to ﬁnd

that encapsulate collaborating classes
...

requirements
...
Because the OO analysis and

orate with one another and subsystems commu-

design models are similar in structure and con-

nicate across architectural layers
...

with the review of these models
...
A series of tests are designed

gram before it gets to the customer with the spe-

that exercise class operations and examine

631

632

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

whether errors exist as one class

What is the work product? A set of test cases to exer-

collaborates with other classes
...

ter testing, along with fault-based approaches,

How do I ensure that I’ve done it right? When you

are applied to fully exercise collaborating classes
...
Try hard

Finally, use-cases (developed as part of the OO

to “break” the software! Design test cases in a dis-

analysis model) are used to uncover errors at the

ciplined fashion and review the test cases you do

software validation level
...

23
...
Because of the evolutionary nature of the OO
software engineering paradigm, these models begin as relatively informal representations of system requirements and evolve into detailed models of classes, class connections and relationships, system design and allocation, and object design
(incorporating a model of object connectivity via messaging)
...

“Because of their
ability to detect and
correct defects in
upstream work
products, technical
reviews are at least
as important in
controlling cost and
schedule as testing
...
g
...
Therefore, a problem in
the deﬁnition of class attributes that is uncovered during analysis will circumvent side
effects that might occur if the problem were not discovered until design or code (or
even the next iteration of analysis)
...
An extraneous attribute is appended to the class (due to a
misunderstanding of the problem domain)
...
A review is conducted and a domain expert points out the
error
...
Special subclasses may have been generated to accommodate the unnecessary attribute or exceptions to it
...

2
...

CHAPTER 23

O B J E C T- O R I E N T E D T E S T I N G

633

3
...

If the error is not uncovered during analysis and propagated further, the following
problems could occur (and will have been avoided because of the earlier review) during design:
1
...

2
...

3
...

If the error remains undetected during design and passes into the coding activity, con-

There’s an old saying
about “nipping
problems in the bud
...

siderable effort will be expended to generate code that implements an unnecessary
attribute, two unnecessary operations, messages that drive interobject communication, and many other related issues
...
Once the problem is ﬁnally uncovered, modiﬁcation of the system must be carried out with the ever-present potential for side effects that are caused
by change
...
For this reason, these
models should be subjected to rigorous review prior to the generation of code
...

23
...
However, formal technical reviews (Chapter 8) can be used to
examine the correctness and consistency of both analysis and design models
...
2
...
Hence, syntactic correctness is judged on proper use of the symbology; each model is reviewed
to ensure that proper modeling conventions have been maintained
...
If the model accurately

634

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

reﬂects 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
...
Class relationships (instance connections) are evaluated to
determine whether they accurately reﬂect real world object connections
...
2
...
An inconsistent model has representations in
one part that are not correctly reﬂected in other portions of the model” [MGR94]
...
The class-responsibility-collaboration model and an object-relationship
diagram can be used to facilitate this activity
...
Each CRC card lists the class name, its responsibilities (operations), and its collaborators (other classes to which it sends messages
OOA Models

and on which it depends for the accomplishment of its responsibilities)
...
e
...
The object-relationship model provides a graphic representation of the connections between classes
...

To evaluate the class model the following steps have been recommended [MGR94]:

? What steps
should we

1
...
Cross check
to ensure that all collaborations implied by the OOA model are properly

take to review
the class model?

represented
...
Inspect the description of each CRC index card to determine if a delegated responsibility is part of the collaborator’s deﬁnition
...
This class has a CRC index card illustrated in Figure 23
...
For this collection of classes and collaborations, we ask whether a responsibility (e
...
, read

XRef

credit card) is accomplished if delegated to the named collaborator (credit

Additional suggestions
for conducting a CRC
model review are
presented in Chapter
21
...
That is, does the class credit card have an operation that enables it to
be read? In this case the answer is, “Yes
...

3
...
For example, if the
credit card class receives a request for purchase amount from the credit sale
class, there would be a problem
...

1

Use-cases can be invaluable in tracking analysis and design models against real world usage scenarios for the OO system
...
1 An example CRC index card used for review

4
...

5
...
For example, read credit card and get
authorization occur in every situation
...

6
...

Once the OOD model (Chapter 22) is created, reviews of the system design and
the object design should also be conducted
...
The object model presents the details of each class
OOD Model

and the messaging activities that are necessary to implement collaborations between
classes
...
Concurrency and task allocation are also reviewed within
the context of system behavior
...
Use-case scenarios are used to exercise the user
interface design
...
In addition, the detailed speciﬁcation of operation details (i
...
, the algorithms that implement the operations) are
reviewed using conventional inspection techniques
...
3

O B J E C T - O R I E N T E D T E S T I N G S T R AT E G I E S
The classical strategy for testing computer software begins with “testing in the small”
and works outward toward “testing in the large
...

The best tester is the
one who gets the
most bugs ﬁxed
...

are run to uncover errors due to interfacing between the modules and side effects

ing, and culminate with validation and system testing
...
g
...
Once each of these units has been tested
individually, it is integrated into a program structure while a series of regression tests
caused by the addition of new units
...

23
...
1 Unit Testing in the OO Context
When object-oriented software is considered, the concept of the unit changes
...
This means that each class and
each instance of a class (object) packages attributes (data) and the operations (also
known as methods or services) that manipulate these data
...

Because a class can contain a number of different operations and a particular operation may exist as part of a number of different classes, the meaning of unit testing
changes dramatically
...
It is not
advisable to test
operations in isolation
...
To illustrate, consider a class hierarchy in which
an operation X is deﬁned for the superclass and is inherited by a number of subclasses
...
Because the context in which operation X is used varies in subtle ways, it is necessary to test operation X in the context of each of the subclasses
...

Class testing for OO software is the equivalent of unit testing for conventional software
...
4 through 23
...

CHAPTER 23

O B J E C T- O R I E N T E D T E S T I N G

637

testing for OO software is driven by the operations encapsulated by the class and the
state behavior of the class
...
3
...
In addition, integrating operations one at a time into a class (the conventional incremental
integration approach) is often impossible because of the “direct and indirect interactions of the components that make up the class” [BER93]
...

The ﬁrst, thread-based testing, integrates the set of classes required to respond to one
input or event for the system
...
Regres-

The OO testing
integration strategy
focuses on groups of
classes that collaborate
or communicate in
some manner
...
The second integration
approach, use-based testing, begins the construction of the system by testing those
classes (called independent classes) that use very few (if any) of server classes
...
This sequence of testing layers of dependent classes continues until the entire system is constructed
...

Cluster testing [MGR94] is one step in the integration testing of OO software
...

23
...
3 Validation Testing in an OO Context
At the validation or system level, the details of class connections disappear
...
To assist in the derivation of validation tests, the tester should draw upon the use-cases (Chapter 20) that are part of the

XRef
Virtually all of the
black-box testing
methods discussed in
Chapter 17 are
applicable for OO
...
The use-case provides a scenario that has a high likelihood of uncovered errors in user interaction requirements
...
In
addition, test cases may be derived from the object-behavior model and from event
ﬂow diagram created as part of OOA
...
4

T E S T C A S E D E S I G N F O R O O S O F T WA R E
Test case design methods for OO software are still evolving
...
Each test case should be uniquely identiﬁed and explicitly associated with the
class to be tested
...
The purpose of the test should be stated
...
A list of testing steps should be developed for each test and should contain
[BER93]:
a
...

b
...

c
...

d
...
e
...

e
...

Unlike conventional test case design, which is driven by an input-process-output view
of software or the algorithmic detail of individual modules, object-oriented testing
focuses on designing appropriate sequences of operations to exercise the states of a
class
...
4
...
Because
attributes and operations are encapsulated, testing operations outside of the class is
generally unproductive
...
As Binder [BIN94a] notes, “Testing

WebRef

requires reporting on the concrete and abstract state of an object
...
rbsc
...
Unless built-in operations are provided to report the values for class attributes, a snapshot of the state of
an object may be difﬁcult to acquire
...
We have
already noted that each new context of usage requires retesting, even though reuse
has been achieved
...
If subclasses
instantiated from a superclass are used within the same problem domain, it is likely
that the set of test cases derived for the superclass can be used when testing the subclass
...

23
...
2 Applicability of Conventional Test Case Design Methods
The white-box testing methods described in Chapter 17 can be applied to the operations deﬁned for a class
...
However, the con3

An OOD concept that should be used with extreme care
...

Black-box testing methods are as appropriate for OO systems as they are for systems developed using conventional software engineering methods
...

23
...
3 Fault-Based Testing4
The strategy is to
hypothesize a set of
plausible faults and
then derive tests to
prove the hypothesis
...
Because the product or system must conform to customer requirements, the preliminary planning required to perform faultbased testing begins with the analysis model
...
e
...
To determine
whether these faults exist, test cases are designed to exercise the design or code
...
5 Software engineers often make errors at the boundaries of a problem
...
"Zero itself" checks whether the programmer made a mistake
like
if (x > 0) calculate_the_square_root();

instead of the correct
if (x >= 0) calculate_the_square_root();

Because fault-based
testing occurs at a
detailed level, it is best
reserved for operations
and classes that are
critical or suspect
...
In the previous expression, (a=0, b=0, c=0) will make the expression as given
evaluate false
...

4

5

Sections 23
...
3 through 23
...
7 have been adapted from an article by Brian Marick posted on the
Internet newsgroup comp
...
This adaptation is included with the permission of the author
...

The code presented in this and the following sections uses C++ syntax
...

640

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Of course, the effectiveness of these techniques depends on how testers perceive
a "plausible fault
...
However,
if the analysis and design models can provide insight into what is likely to go wrong,
then fault-based testing can find significant numbers of errors with relatively low
expenditures of effort
...
Three types of faults are encountered in this context: unexpected result, wrong
operation/message used, incorrect invocation
...

Integration testing applies to attributes as well as to operations
...
Testing should
exercise the attributes to determine whether proper values occur for distinct types of
object behavior
...
Stated in conventional terms, the focus of integration testing
is to determine whether errors exist in the calling code, not the called code
...

23
...
4 The Impact of OO Programming on Testing
There are several ways object-oriented programming can have an impact on testing
...
”
Cem Kaner et al
...

•

Some types of faults become more plausible (worth testing now)
...

When an operation is invoked, it may be hard to tell exactly what code gets exercised
...
Also, it can be hard
to determine the exact type or class of a parameter
...
The difference can be understood by considering a conventional function call:
x = func (y);

For conventional software, the tester need consider all behaviors attributed to func
and nothing more
...
Each time func is invoked, the tester must
consider the union of all distinct behaviors
...
The testing approach for
base and derived classes is essentially the same
...

CHAPTER 23

O B J E C T- O R I E N T E D T E S T I N G

641

Testing OO class operations is analogous to testing code that takes a function
parameter and then invokes it
...
At the call site, what matters is not the inheritance, but the polymorphism
...

By virtue of OO software architecture and construction, are some types of faults
more plausible for an OO system and others less plausible? The answer is, “Yes
...
Therefore,
integration faults become more plausible
...
4
...
In fact, it can actually complicate the testing process
...
A class base contains operations inherited and
redeﬁned
...
There is little doubt the derived::redeﬁned() has to be tested because it represents a new design
and new code
...

If derived::inherited() calls redefined and the behavior of redefined has changed,
derived::inherited() may mishandle the new behavior
...
It is important to note, however, that
only a subset of all tests for derived::inherited() may have to be conducted
...
e
...

Base::redeﬁned() and derived::redeﬁned() are two different operations with different
specifications and implementations
...
Those test requirements probe
for plausible faults: integration faults, condition faults, boundary faults, and so forth
...
Their sets of test requirements will overlap
...
New tests need to be derived
only for those derived::redeﬁned() requirements that are not satisﬁed by the base::redeﬁned() tests
...

Test inputs may be appropriate for both base and derived classes, but the expected
results may differ in the derived class
...
4
...
When errors associated with incorrect speciﬁcation occur, the product doesn't do what the customer wants
...
But in either circumstance, quality (conformance to requirements) suffers
...
g
...

Scenario-based testing concentrates on what the user does, not what the product

Scenario-based testing
will uncover errors that
occur when any actor
interacts with the OO
software
...
This means capturing the tasks (via use-cases) that the user has to perform,
then applying them and their variants as tests
...
But to accomplish this, test cases must be
more complex and more realistic than fault-based tests
...

As an example, consider the design of scenario-based tests for a text editor
...
This use-case describes the
sequence of events that occurs when this happens
...
Print the entire document
...
Move around in the document, changing certain pages
...
As each page is changed, it's printed
...
Sometimes a series of pages is printed
...
The user needs are
obvious: (1) a method for printing single pages and (2) a method for printing a range
of pages
...
The tester hopes to discover that the printing function causes errors
in the editing function; that is, that the two software functions are not properly independent
...

Use-Case: Print a New Copy
Background: Someone asks the user for a fresh copy of the document
...

1
...

2
...

3
...

Again, the testing approach is relatively obvious
...
It was created in an earlier task
...
By
default, they print the same way next time
...
So, according to the editor, the correct
scenario should look like this:

CHAPTER 23

O B J E C T- O R I E N T E D T E S T I N G

643

Use-Case: Print a New Copy
1
...

2
...

3
...

4
...

5
...

But this scenario indicates a potential speciﬁcation error
...
Customers will often overlook the check noted
in step 3 above
...
Annoyed customers signal speciﬁcation bugs
...
The tester would then have to contend
with the probable response, "That's the way it's supposed to work!"

23
...
7 Testing Surface Structure and Deep Structure
Surface structure refers to the externally observable structure of an OO program
...
Rather than performing
functions, the users of many OO systems may be given objects to manipulate in some
way
...
Capturing these
tasks involves understanding, watching, and talking with representative users (and
as many nonrepresentative users as are worth considering)
...

There will surely be some difference in detail
...
If no test scenarios existed to exercise a command, testing has
likely overlooked some user tasks (or the interface has useless commands)
...

The best tests are derived when the designer looks at the system in a new or unconventional way
...
Ask questions like, “Might the user want to
use this operation—which applies only to the Scanner object—while working with
the printer?" Whatever the interface style, test case design that exercises the surface
structure should use both objects and operations as clues leading to overlooked tasks
...
That is,
the structure that is understood by examining the design and/or code
...

The analysis and design models are used as the basis for deep structure testing
...
The test case design then asks: “Have we captured (as a test) some task that
exercises the collaboration noted on the object-relationship diagram or the subsystem collaboration diagram? If not, why not?”
Design representations of class hierarchy provide insight into inheritance structure
...
Consider a situation in which
an operation named caller has only one argument and that argument is a reference
to a base class
...

23
...
” Testing in the small focuses on a single class
and the methods that are encapsulated by the class
...

23
...
1 Random Testing for OO Classes
To provide brief illustrations of these methods, consider a banking application in
which an account class has the following operations: open, setup, deposit, withdraw,
balance, summarize, creditLimit, and close [KIR94]
...
g
...
Even with these constraints, there are many
permutations of the operations
...
A
strategy similar to
orthogonal array
testing (Chapter 17)
can be used to
improve testing
efﬁciency
...
However, a wide variety of
other behaviors may occur within this sequence:
open•setup•deposit•[deposit|withdraw|balance|summarize|creditLimit]n•withdraw•close

A variety of different operation sequences can be generated randomly
...

23
...
2 Partition Testing at the Class Level
Partition testing reduces the number of test cases required to exercise the class in
much the same manner as equivalence partitioning (Chapter 17) for conventional

CHAPTER 23

O B J E C T- O R I E N T E D T E S T I N G

645

software
...
But how are the partitioning categories derived?

? What
testing
options are
available at the
class level?

State-based partitioning categorizes class operations based on their ability to change
the state of the class
...
Tests are designed in a way that exercises operations that change state
and those that do not change state separately
...

Attribute-based partitioning categorizes class operations based on the attributes
that they use
...
Operations are divided into three partitions: (1) operations that
use creditLimit, (2) operations that modify creditLimit, and (3) operations that do not use
or modify creditLimit
...

Category-based partitioning categorizes class operations based on the generic function that each performs
...
queries (balance, summarize, creditLimit) and termination operations (close)
...
6

INTERCLASS TEST CASE DESIGN
Test case design becomes more complicated as integration of the OO system begins
...
To illustrate “interclass test case generation” [KIR94], we expand the banking example introduced in Section 23
...
2
...

Like the testing of individual classes, class collaboration testing can be accomplished by applying random and partitioning methods, as well as scenario-based testing and behavioral testing
...
6
...
For each client class, use the list of class operations to generate a series of
random test sequences
...

646

PA R T F O U R

ATM
user
interface

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

cardinserted
password
deposit
withdraw
accntStatus
terminate

verifyAcct
verifyPIN
verifyPolicy
withdrawReq
depositReq
acctInfo

validPIN
validAcct

ATM
verifyStatus
depositStatus
dispenseCash
print AccntStat
read CardInfo
getCashAmnt

Bank

openAcct
initialDeposit
authorizeCard
deauthorize
closeAcct

Cashier

creditLimit
accntType
balance
withdraw
deposit
close

Account

Validation
info

F I G U R E 23
...
For each message that is generated, determine the collaborator class and the
corresponding operation in the server object
...
For each operation in the server object (that has been invoked by messages
sent from the client object), determine the messages that it transmits
...
For each of the messages, determine the next level of operations that are
invoked and incorporate these into the test sequence
...
2):
verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|acctInfoREQ]n

A random test case for the bank class might be
test case r3 =

verifyAcct•verifyPIN•depositReq

In order to consider the collaborators involved in this test, the messages associated
with each of the operations noted in test case r3 is considered
...
Bank must collaborate with account to execute depositReq
...
3
State transition
diagram for
account class
[KIR94]

open

647

O B J E C T- O R I E N T E D T E S T I N G

Empty
Empty
acct
acct

Empty
Set up
acct
acct

setup Accnt

deposit (initial)

deposit
Empty
Working
acct
acct

balance
credit
accntInfo

withdraw

withdrawal (final)

Empty
Dead
acct
acct

close

Empty
Nonworking
acct
acct

The approach for multiple class partition testing is similar to the approach used
for partition testing of individual classes
...
4
...
However, the test sequence is expanded to include those operations
that are invoked via messages to collaborating classes
...
Referring to Figure 23
...
The methods
within bank can therefore be tested by partitioning them into those that serve ATM
and those that serve cashier
...
4
...

23
...
2 Tests Derived from Behavior Models
In Chapter 21, we discussed the use of the state transition diagram as a model that represents the dynamic behavior of a class
...
Figure 23
...
6 Referring to the ﬁgure, initial transitions move through the
empty acct and setup acct states
...
A ﬁnal withdrawal and close cause the account
class to make transitions to the nonworking acct and dead acct states, respectively
...
3
...

648

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

The tests to be designed should achieve all state coverage [KIR94]
...
5
...
Adding additional test sequences to the minimum sequence,
test case s2:

open•setupAccnt•deposit(initial)•deposit•balance•credit•withdraw (ﬁnal)•close

test case s3:

open•setupAccnt•deposit(initial)•deposit•withdraw•accntInfo•withdraw (ﬁnal)•close

Still more test cases could be derived to ensure that all behaviors for the class have
been adequately exercised
...

The state model can be traversed in a “breadth-ﬁrst” [MGR94] manner
...

Consider the credit card object discussed in Section 23
...
2
...
e
...
Upon reading the credit card during a sale, the object takes on a defined state; that is, the
attributes card number and expiration date, along with bank specific identifiers are
defined
...
The transition of credit card from one
state to another can be tested by deriving test cases that cause the transition to
occur
...
If it did, it would make use of transitions that had not been previously tested and would therefore violate the breadth-first
criterion
...
7

SUMMARY
The overall objective of object-oriented testing—to find the maximum number of
errors with a minimum amount of effort—is identical to the objective of conventional
software testing
...
The
view of testing broadens to include the review of both the analysis and design model
...

Because the OO analysis and design models and the resulting source code are
semantically coupled, testing (in the form of formal technical reviews) begins during
these engineering activities
...

CHAPTER 23

O B J E C T- O R I E N T E D T E S T I N G

649

Once OOP has been accomplished, unit testing is applied for each class
...
Each of these methods exercises the operations encapsulated by the
class
...

The state of the class, represented by the values of its attributes, is examined to determine if errors exist
...
Thread-based testing integrates the set of classes that collaborate to respond to
one input or event
...
Integration test case design methods
can also use random and partition tests
...
A
test sequence tracks the ﬂow of operations across class collaborations
...
However, scenario-based testing dominates the validation of OO systems, making the
use-case a primary driver for validation testing
...
, “Using Use Cases,” Software Development, July 1995, pp
...

[BER93] Berard, E
...
, Essays on Object-Oriented Software Engineering, vol
...

[BIN94a] Binder, R
...
, “Testing Object-Oriented Systems: A Status Report,” American
Programmer, vol
...
4, April 1994, pp
...

[BIN94b] Binder, R
...
, “Object-Oriented Software Testing,” CACM, vol
...
9, September 1994, p
...

[KIR94]

Kirani, S
...
T
...

[LIN94]

Lindland, O
...
, et al
...
11, no 4, July 1994, pp
...

[MAR94] Marick, B
...

[MGR94] McGregor, J
...
and T
...
Korson, “Integrated Object-Oriented Testing and
Development Processes,” CACM, vol
...
9, September 1994, pp
...

PROBLEMS AND POINTS TO PONDER
23
...
In your own words, describe why the class is the smallest reasonable unit for
testing within an OO system
...
2
...
3
...
4
...
2
...

23
...
What is the difference between thread-based and use-based strategies for integration testing? How does cluster testing ﬁt in?
23
...
Apply random testing and partitioning to three classes deﬁned in the design
for the SafeHome system that you produced for Problem 22
...
Produce test cases
that indicate the operation sequences that will be invoked
...
7
...

23
...
Derive tests using methods noted in Problems 23
...
7 for the PHTRS
system described in Problem 12
...

23
...
Derive tests using methods noted in Problems 23
...
7 for the video game
considered in Problem 22
...

23
...
Derive tests using methods noted in Problems 23
...
7 for the e-mail
system considered in Problem 22
...

23
...
Derive tests using methods noted in Problems 23
...
7 for the ATC system considered in Problem 22
...

23
...
Derive four additional tests using each of the methods noted in Problems
23
...
7 for the banking application presented in Sections 23
...
6
...
Binder (Testing Object-Oriented Systems: Models, Patterns,
and Tools, Addison-Wesley, 2000) has written the most comprehensive treatment of
the subject published to date
...
Marick (The Craft of Software Testing: Subsystem Testing Including Object-Based
and Object-Oriented Testing, Prentice-Hall, 1995) covers testing for both conventional
and OO software
...

(Testing Object-Oriented Software, IEEE Computer Society, 1998) and Braude (Object
Oriented Analysis, Design and Testing: Selected Readings, IEEE Computer Society, 1998)
...

Jorgensen (Software Testing: A Craftsman’s Approach, CRC Press, 1995) and McGregor and Sykes (Object-Oriented Software Development, Van Nostrand-Reinhold, 1992)
present chapters dedicated to the topic
...

Binder (Testing Object-Oriented Systems, Addison-Wesley, 1996) and Marick [MAR94]
present detailed treatments of OO testing
...

A wide variety of information sources on object-oriented testing and related subjects is available on the Internet
...
mhhe
...
mhtml

CHAPTER

24
KEY
CONCEPTS
abstraction
...
658
class-oriented
metrics
...
656
encapsulation
...
656
information
hiding
...
655
Lorenz and Kidd
metrics
...
662
operation-oriented
metrics
...
665

TECHNICAL METRICS FOR
OBJECT-ORIENTED SYSTEMS

arly in this book we noted that measurement and metrics are key components of any engineering discipline—and object-oriented software engineering is no exception
...
Ed Berard
[BER95] notes the irony of measurement when he states:

E

Software people seem to have a love-hate relationship with metrics
...
They
are quick to point out the "ﬂaws" in the arguments of anyone who talks about measuring software products, software processes, and (especially) software people
...

The “love-hate relationship” that Berard notes is real
...
These measures enable an engineer to
assess the software early in the process, making changes that will reduce complexity and improve the long-term viability of the end product
...
664
What is it? Building OO software

tive analysis
...
OO metrics have been

attributes that constitute a class
...
Technical met-

before a system is built
...

Who does it? Software engineers use OO metrics to
help them build higher-quality software
...

What are the steps? The ﬁrst step in the measurement
process is to derive the software measures and met-

Why is it important? As we stated in the Quick Look

rics that are appropriate for the representation of

for Chapter 19, qualitative assessment of computer

software that is being considered
...
Once computed, appropriate metrics are analyzed based

analysis and design models, source code, and test
cases
...
The results of the analysis are interpreted

establish the objectives of measurement before

to gain insight into the quality of the software, and

the data collection begins, deﬁning each OO met-

the results of the interpretation lead to modiﬁca-

ric in an unambiguous manner
...

quality of a software engineering work product
...
1

THE INTENT OF OBJECT-ORIENTED METRICS
The primary objectives for object-oriented metrics are no different than those for metrics derived for conventional software:
•

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

Each of these objectives is important, but for the software engineer, product quality must
be paramount
...

24
...
For example, it would be meaningless to compute miles per gallon for an
electric automobile
...
e
...
Objectoriented software is fundamentally different than software developed using conventional methods
...

Berard [BER95] deﬁnes ﬁve characteristics that lead to specialized metrics: localization, encapsulation, information hiding, inheritance, and object abstraction techniques
...
1
1

This discussion has been adapted from [BER95]
...
2
...
For example, conventional methods for
functional decomposition localize information around functions, which are typically
implemented as procedural modules
...
In the OO context, information is concentrated by
XRef
Technical metrics for
conventional software
are discussed in
Chapter 19
...

Because conventional software emphasizes function as a localization mechanism,
software metrics have focused on the internal structure or complexity of functions
(e
...
, module length, cohesion or cyclomatic complexity) or the manner in which
functions connect to one another (e
...
, module coupling)
...

Therefore, metrics should apply to the class (object) as a complete entity
...
Therefore, metrics that reﬂect the manner in which classes collaborate must be
capable of accommodating one-to-many and many-to-one relationships
...
2
...
Low-level examples of encapsulation [for conventional software]
include records and arrays, [and] subprograms (e
...
, procedures, functions, subrouXRef
Basic design concepts
are discussed in
Chapter 13
...

tines, and paragraphs) are mid-level mechanisms for encapsulation
...

Encapsulation inﬂuences metrics by changing the focus of measurement from a
single module to a package of data (attributes) and processing modules (operations)
...

For example, later in this chapter metrics associated with the number of operations
per class will be introduced
...

24
...
3 Information Hiding
Information hiding suppresses (or hides) the operational details of a program component
...

A well-designed OO system should encourage information hiding
...

656

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

24
...
4 Inheritance
Inheritance is a mechanism that enables the responsibilities of one object to be propagated to other objects
...

In general, conventional software does not support this characteristic
...
Examples (discussed later in this chapter) include number of children
(number of immediate instances of a class), number of parents (number of immediate generalizations), and class hierarchy nesting level (depth of a class in an inheritance hierarchy)
...
2
...
As Berard states: “Abstraction is a relative concept
...
e
...
As we move to lower levels of abstraction, we introduce more details, i
...
, we provide a more speciﬁc view of a concept or item
...
g
...
g
...

24
...
But, as an OO design model grows in size and complexity, a
more objective view of the characteristics of the design can beneﬁt both the experienced designer (who gains additional insight) and the novice (who obtains an indication of quality that would otherwise be unavailable)
...
Size is deﬁned in terms of four views: population, volume, length, and
functionality
...
Volume measures are identical to population
measures but are collected dynamically—at a given instant of time
...
g
...
Functionality metrics provide an indirect indication of the value delivered to the customer by an OO application
...
Like size, there are many differing views of software complexity [ZUS97]
...

Coupling
...
g
...

Sufficiency
...
” Stated another way, we ask: “What properties does this abstraction (class) need to possess to be useful to me?”
[WHI97]
...
g
...
”
Scott Whitmire

eling—that is, that the abstraction (class) possesses the features required
of it
...
The only difference between completeness and sufﬁciency
is “the feature set against which we compare the abstraction or design component [WHI97]
...
Completeness considers multiple points of view,
asking the question: “What properties are required to fully represent the
problem domain object?” Because the criterion for completeness considers
different points of view, it has an indirect implication about the degree to
which the abstraction or design component can be reused
...
Like its counterpart in conventional software, an OO component
should be designed in a manner that has all operations working together to
achieve a single, well-deﬁned purpose
...

A NASA technical report
addressing quality metrics
for OO systems can be
downloaded from
satc
...
nasa
...
html

Primitiveness
...
A class that exhibits a high degree
of primitiveness encapsulates only primitive operations
...
The degree to which two or more classes are similar in terms of
their structure, function, behavior, or purpose is indicated by this measure
...
As we have seen earlier in this book, design changes can occur
when requirements are modiﬁed or when modiﬁcations occur in other parts
of an application, resulting in mandatory adaptation of the design component
in question
...

658

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

Whitmire’s derivation of metrics for these design characteristics is beyond the
scope of this book
...

In reality, technical metrics for OO systems can be applied not only to the design
model, but also the analysis model
...
In
addition, metrics applicable for project management and testing are also explored
...
4

CLASS-ORIENTED METRICS
The class is the fundamental unit of an OO system
...
In earlier chapters, we
saw that the class encapsulates operations (processing) and attributes (data)
...
The class often collaborates with other classes
...
2

24
...
1 The CK Metrics Suite
One of the most widely referenced sets of OO software metrics has been proposed
by Chidamber and Kemerer [CHI94]
...
3
Weighted methods per class (WMC)
...
, cn are deﬁned for a class C
...
g
...
0
...
The number of methods and their complexity are reasonable indicators of the amount of effort required to implement and test a class
...

larger the number of methods, the more complex is the inheritance tree (all subclasses inherit the methods of their parents)
...
For all of these reasons, WMC should be kept as low as is
reasonable
...
Those who champion measurement theory demand a degree
of formalism that some of the OO metrics do not provide
...

Chidamber, Darcy, and Kemerer use the term methods rather than operations
...

CHAPTER 24

T E C H N I C A L M E T R I C S F O R O B J E C T- O R I E N T E D S Y S T E M S

659

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
...
However, the implications for metrics may be
significant
...

The motivation for this would be that inherited members have already been counted in the
classes where they are deﬁned, so the class increment is the best measure of its functionality—what it does reﬂects its reason for existing
...
If a class cannot respond
to a message (i
...
, it lacks a corresponding method of its own) then it will pass the message on to its parent(s)
...
This approach emphasizes the importance of the state
space, rather than the class increment, in understanding a class
...
For example, one could
restrict counting to the current class and members inherited directly from parent(s)
...

Like most counting conventions in software metrics, any of the approaches just outlined is acceptable, as long as the counting approach is applied consistently whenever metrics are collected
...
This metric is “the maximum length from
the node to the root of the tree” [CHI94]
...
1, the value of DIT for
the class-hierarchy shown is 4
...

Use DIT and other
related metrics to give
yourself a reading on
the complexity of class
hierarchies
...
This leads to potential difﬁculties when attempting to predict
the behavior of a class
...
On the positive side, large DIT values imply that many methods
may be reused
...
The subclasses that are immediately subordinate
to a class in the class hierarchy are termed its children
...
1,
class C2 has three children—subclasses C21, C22, and C23
...
That is, some of the children may not
really be appropriate members of the parent class
...

660

PA R T F O U R

F I G U R E 24
...
The CRC model (Chapter 21) may be
used to determine the value for CBO
...
As CBO increases, it is likely that the
reusability of a class will decrease
...
In general, the CBO values for each class should be kept as low as is reasonable
...

The concepts of
coupling and cohesion
apply to both
conventional and OO
software
...

Response for a class (RFC)
...
RFC is the number of methods in the response set
...
It also follows that, as RFC increases, the overall design complexity of the class
increases
...
Each method within a class, C, accesses
one or more attributes (also called instance variables)
...
4 If no methods access the same
4

The formal deﬁnition is a bit more complex
...

CHAPTER 24

T E C H N I C A L M E T R I C S F O R O B J E C T- O R I E N T E D S Y S T E M S

661

attributes, then LCOM = 0
...
Four of the methods have one or more attributes in common (i
...
,
they access common attributes)
...
If LCOM is high, methods may
be coupled to one another via attributes
...
In general, high values for LCOM imply that the class might be better designed
by breaking it into two or more separate classes
...
”
Brian HendersonSellers

a high value for LCOM is justiﬁable, it is desirable to keep cohesion high; that is, keep
LCOM low
...
4
...
Size-oriented
metrics for the OO class focus on counts of attributes and operations for an individual class and average values for the OO system as a whole
...

Metrics for class internals look at cohesion (Section 24
...
1) and code-oriented issues,
and external metrics examine coupling and reuse
...
The overall size of a class can be measured by determining the following measures:
•

The total number of operations (both inherited and private instance operations) that are encapsulated within the class
...

The WMC metric proposed by Chidamber and Kemerer (Section 24
...
1) is also a
weighted measure of class size
...
This will reduce the reusability of the class

During review of the
OOA model, the CRC
index cards will
provide a reasonable
indication of expected
values for CS
...

and complicate implementation and testing
...

Private operations and attributes enable specialization and are more localized in the
design
...
The lower the average values for size, the more likely that classes within the
system can be reused widely
...
There are instances when
a subclass replaces an operation inherited from its superclass with a specialized version

5

For a complete discussion, see [LOR94]
...
This is called overriding
...
As Lorenz and Kidd point out:
Since a subclass should be a specialization of its superclasses, it should primarily extend
the services [operations] of the superclasses
...

If NOO is large, the designer has violated the abstraction implied by the superclass
...

Number of operations added by a subclass (NOA)
...
As the value for NOA increases, the subclass drifts away from the abstraction implied by the superclass
...

Specialization index (SI)
...
Specialization can be achieved by adding or deleting operations or by overriding
...
The higher is the value of SI, the more likely
the class hierarchy has classes that do not conform to the superclass abstraction
...
4
...
A sampling
of MOOD metrics follows:

“Analyzing OO
software in order to
evaluate its quality
is becoming
increasingly
important as the
paradigm continues
to increase in
popularity
...

Method inheritance factor (MIF)
...
TC is deﬁned as the total number of
classes in the architecture, Ci is a class within the architecture, and
Ma(Ci) = Md(Ci) + Mi(Ci)
where

CHAPTER 24

T E C H N I C A L M E T R I C S F O R O B J E C T- O R I E N T E D S Y S T E M S

663

Ma(Ci) = the number of methods that can be invoked in association with Ci
...

Mi(Ci) = the number of methods inherited (and not overridden) in Ci
...

Coupling factor (CF)
...
The MOOD metrics suite
deﬁnes coupling in the following way:
CF = ∑i ∑j is_client (Ci, Cj)]/(TC2 Ϫ TC)
where the summations occur over i = 1 to TC and j = 1 to TC
...

Polymorphism factor (PF)
...
[t]hus, PF is an indirect measure
of the relative amount of dynamic binding in a system
...

Mo(Ci) = the number of overriding methods
...

Harrison and her colleagues [HAR98] present a detailed analysis of MIF, CF, and PF
along with other metrics and examine their validity for use in the assessment of design
quality
...
5

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

O P E R AT I O N - O R I E N T E D M E T R I C S
Because the class is the dominant unit in OO systems, fewer metrics have been proposed for operations that reside within a class
...

However, some insights can be gained by examining average characteristics for methods (operations)
...
See
Chapter 19 for details
...
Although lines of code could be used as an indicator for operation size, the LOC measure suffers from all the problems discussed in
Chapter 4
...
As the number of messages sent by a single operation increases, it is likely that responsibilities have not been well-allocated within
a class
...
The complexity of an operation can be computed
using any of the complexity metrics (Chapter 19) proposed for conventional software
[ZUS90]
...

Average number of parameters per operation (NPavg)
...
In
general, NPavg should be kept as low as possible
...
6

METRICS FOR OBJECT-ORIENTED TESTING
The design metrics noted in Sections 24
...
5 provide an indication of design
quality
...

Binder [BIN94] suggests a broad array of design metrics that have a direct inﬂuence on the “testability” of an OO system
...

Encapsulation
Lack of cohesion in methods (LCOM)
...

6

See Section 24
...
1 for a description of LCOM
...
Public attributes are inherited from other
classes and therefore visible to those classes
...
This metric indicates the percentage of
class attributes that are public
...
Tests must be designed to ensure that such side effects are
uncovered
...
This metric indicates the number of classes

OO testing can be
quite complex
...
Use
them
...

High values for PAD lead to the potential for side effects among classes
...

Inheritance
Number of root classes (NOR)
...
Test suites for each root class and the
corresponding class hierarchy must be developed
...

Fan-in (FIN)
...
FIN > 1 indicates that a class inherits its attributes and operations from more
than one root class
...

Number of children (NOC) and depth of the inheritance tree (DIT)
...

In addition to these metrics, Binder [BIN94] deﬁnes metrics for class complexity
and polymorphism
...
4
...
In addition, metrics associated with method counts are
deﬁned
...
A discussion of them is best left to Binder
...
7

METRICS FOR OBJECT-ORIENTED PROJECTS
As we discovered in Part Two of this book, the job of the project manager is to plan,
coordinate, track, and control a software project
...
But what about
measurement? Are there specialized OO metrics that can be used by the project manager to provide additional insight into progress?8 The answer, of course, is, “Yes
...
4
...

A worthwhile discussion of the CK metrics suite (Section 24
...
1) for use in management decisionmaking can be found in [CHI98]
...

early planning tasks is estimation
...
Therefore, the plan (and its project estimates) are revisited after each iteration of OOA, OOD, and even OOP
...
Size is directly proportional to effort and duration
...
The number of scenario scripts or use-cases
(Chapters 11 and 21) is directly proportional to the number of classes required to meet
requirements; the number of states for each class; and the number of methods, attributes, and collaborations
...

Number of key classes (NKC)
...
9
For this reason, high values for NKC indicate substantial development work
...
The remainder support infrastructure (GUI, communications, databases, etc
...
The number of subsystems provides insight into
resource allocation, scheduling (with particular emphasis on parallel development)
and overall integration effort
...
g
...
These data can also be used along with
the design metrics discussed earlier in this chapter to compute “productivity metrics”
such as average number of classes per developer or average methods per personmonth
...

24
...
Therefore, the metrics for OO systems focus on measurement
that can be applied to the class and the design characteristics—localization, encapsulation, information hiding, inheritance, and object abstraction techniques—that
make the class unique
...
The metrics suite also develops metrics to assess the
9

This will be true only until a robust library of reusable components is developed for a particular
domain
...
At a class-oriented level, the CK metrics suite can be augmented with metrics
proposed by Lorenz and Kidd and the MOOD metrics suite
...

Operation-oriented metrics focus on the size and complexity of individual operations
...

A wide variety of OO metrics have been proposed to assess the testability of an
OO system
...
Many of these metrics have been adapted from the CK metrics
suite and metrics proposed by Lorenz and Kidd
...

Measurable characteristics of the analysis and design model can assist the project
manager for an OO system in planning and tracking activities
...

REFERENCES
[BER95] Berard, E
...
software-eng, January 28, 1995
...
V
...
37, no,
...
29
...
R
...
F
...
Software Engineering, vol
...
6, June 1994, pp
...

[CHI98]

Chidamber, S
...
, D
...
Darcy, and C
...
Kemerer, “Management Use of Met-

rics for Object-Oriented Software: An Exploratory Analysis,” IEEE Trans
...
SE-24, no
...
629–639
...
I
...
J
...
20, no
...
69–76
...
, S
...
Counsell, and R
...
Nithi, “An Evaluation of the MOOD Set
of Object-Oriented Software Metrics,” IEEE Trans
...
SE-24,
no
...
491–496
...
and J
...

[WHI97] Whitmire, S
...

[WIL93] Wilde, N
...
Huitt, "Maintaining Object-Oriented Software," IEEE Software, January 1993, pp
...

[ZUS90] Zuse, H
...

[ZUS97] Zuse, H
...

668

PA R T F O U R

O B J E C T- O R I E N T E D S O F T WA R E E N G I N E E R I N G

PROBLEMS AND POINTS TO PONDER
24
...
Review the metrics presented in this chapter and in Chapter 19
...
2
...
3
...
4
...

24
...
Review the metrics discussed in this chapter and suggest a few that directly
or indirectly address the abstraction design characteristic
...
6
...
Cyclomatic complexity has been computed for
all operations in the OO system and the average value of module complexity is 4
...
Compute the weighted methods per class
...
7
...
8, compute the value of DIT for each inheritance tree
...
8
...

24
...
Referring to Figure 20
...
10
...
8B, assume that four operations have been overridden in the inheritance tree (class hierarchy), what is the value of SI for the hierarchy?
24
...
A software team has completed ﬁve OO projects to date
...
It is estimated that 95 use-cases will be developed for the project
...
The total number of classes that will be required to implement the system
...
The total amount of effort required to implement the system
...
12
...

Compute the values of these metrics for one or more of these problems:
a
...

b
...
13
...
The design model for the video game considered in Problem 22
...

d
...
15
...
The design model for the ATC system considered in Problem 22
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
A variety of books on OOA, OOD, and OOT (see Further Readings and Information
Sources in Chapters 20, 21, and 22) make passing reference to OO metrics, but few
address the subject in any detail
...
, 1993) provide more treatment than most
...
Lorenz and Kidd [LOR94] and
Hendersen-Sellers (Object-Oriented Metrics: Measures of Complexity, Prentice-Hall,
1996) offer the only other books dedicated to OO metrics
...

A wide variety of information sources on object-oriented metrics and related subjects is available on the Internet
...
mhhe
...
mhtml

PA R T

Five
ADVANCED TOPICS
IN SOFTWARE
ENGINEERING
n this part of Software Engineering: A Practitioner’s Approach, we
consider a number of advanced topics that will extend your
understanding of software engineering
...

671

CHAPTER

25
KEY
CONCEPTS
data invariant
...
683
formal methods
guidelines
...
687
languages
...
686
operations
...
678

FORMAL METHODS

oftware engineering methods can be categorized on a "formality" spectrum that is loosely tied to the degree of mathematical rigor applied during analysis and design
...
A combination of diagrams, text, tables, and simple notation is used to create analysis and design models, but little mathematical rigor has been applied
...
Here, a speciﬁcation and design are described using a formal syntax and semantics that specify system function and behavior
...
g
...

In his introductory discussion of formal methods, Anthony Hall [HAL90]
states:

S

sequences
...
Their advocates claim that they can revolution-

set operators
...
Their detractors think they are impossibly difﬁcult
...
678

while, for most people, formal methods are so unfamiliar that it is difﬁcult to judge

Z schemas
...

Z notation
...

What is it? Formal methods

critical systems, failure can have a high price
...

complete, consistent, and unambiguous than

In such situations, it is essential that errors are

those produced using conventional or object-

uncovered before software is put into operation
...
Set theory and logic notation

Formal methods reduce speciﬁcation errors dra-

are used to create a clear statement of facts

matically and, as a consequence, serve as the

(requirements)
...

consistency
...

state, and operations for a system function
...

Why is it important? In safety-critical or mission-

out the execution of a function that contains a collection of data, The state is the stored data that a

673

674

PA R T F I V E

QUICK
LOOK

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

function accesses and alters; and

What is the work product? A specification repre-

operations are actions that take

sented in a formal language such as Z or VDM is

place in a system as it reads or

produced when formal methods are applied
...
An operation is associated

How do I ensure that I’ve done it right? Because for-

with two conditions: a precondition and a post-

mal methods use discrete mathematics as the

condition
...

mal methods
...
1

BASIC CONCEPTS
The Encyclopedia of Software Engineering [MAR94] deﬁnes formal methods in the following manner:
Formal methods used in developing computer systems are mathematically based techniques
for describing system properties
...

A method is formal if it has a sound mathematical basis, typically given by a formal
speciﬁcation language
...

The desired properties of a formal speciﬁcation—consistency, completeness, and
lack of ambiguity—are the objectives of all speciﬁcation methods
...
The

“[F]ormal methods
have tremendous
potential for
improving the clarity
and precision of
requirements
speciﬁcations, and in
ﬁnding important
and subtle errors
...

formal syntax of a specification language (Section 25
...
g
...
The descriptive facilities of set theory and logic notation (Section 25
...
To be consistent, facts stated in one
place in a speciﬁcation should not be contradicted in another place
...

Completeness is difficult to achieve, even when formal methods are used
...
Things may simply be omitted by
mistake
...
To understand why a formal approach has merit, we
must ﬁrst consider the deﬁciencies associated with less formal approaches
...
1
...
Although
careful application of analysis and design methods, coupled with thorough review
can and does lead to high-quality software, sloppiness in the application of these
methods can create a variety of problems
...

Spend the time to
create a
comprehensive index
for speciﬁcations and
other documents
...

Contradictions are sets of statements that are at variance with each other
...
Normally, contradictions that occur on the same page
of a system speciﬁcation can be detected easily
...

Ambiguities are statements that can be interpreted in a number of ways
...
It should be displayed on the security VDU and deposited in the login ﬁle when
an operator logs into the system
...

“Making mistakes is
human, Repeating
‘em is too
...
It can
lead to statements such as “The interface to the system used by radar operators should
be user-friendly” or “The virtual interface shall be based on simple overall concepts
that are straightforward to understand and use and few in number
...

Incompleteness is probably one of the most frequently occurring problems with
system speciﬁcations
...
These values should be stored for the past six months
...

676

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

This describes the main data storage part of a system
...

However, some will
not be uncovered
...

The function of the AVERAGE command is to display on a PC the average water level for a
particular sensor between two times
...
For example, the description of the command does not include what should happen if a user of a system speciﬁes a time that
was more than six months before the current hour
...
For example, statements such as
The purpose of the system is to track the stock in a warehouse
...
The system will respond with a conﬁrmation that the removal is allowable
...

Each of these problems is more common than we would like to believe
...

25
...
2 Mathematics in Software Development
Mathematics has many useful properties for the developers of large systems
...
Ideally, the software engineer should be in the same position as the applied mathematician
...
2
Another advantage of using mathematics in the software process is that it provides
a smooth transition between software engineering activities
...

2

A word of caution is appropriate at this point
...
Software systems are notoriously complex, and it would be unrealistic to expect that they could be speciﬁed in
one line of mathematics
...
Because it is an exact medium there is little possibility of
ambiguity: Specifications can be mathematically validated for contradictions and
incompleteness, and vagueness disappears completely
...

Mathematics is an ideal tool for modeling
...
It also helps the designer,
because the system design speciﬁcation exhibits the properties of a model, providing only sufﬁcient details to enable the task in hand to be carried out
...
It is possible to use a mathematical proof to demonstrate
that a design matches a speciﬁcation and that some program code is a correct reﬂection of a design
...

25
...
3 Formal Methods Concepts
The aim of this section is to present the main concepts involved in the mathematical speciﬁcation of software systems, without encumbering the reader with too much
mathematical detail
...

Example 1: A Symbol Table
...
Such
a table is used frequently in many different types of applications
...
An example of a typical symbol table is
shown in Figure 25
...
It represents the table used by an operating system to hold the
names of the users of the system
...

Assume that the table presented in this example consists of no more than MaxIds

A data invariant is a
set of conditions that
are true throughout the
execution of the
system that contains a
collection of data
...
This statement, which places a constraint on the table, is a component of a condition known as a data invariant—an important idea that we shall
return to throughout this chapter
...
The data invariant that holds for the symbol
table just discussed has two components: (1) that the table will contain no more
than MaxIds names and (2) that there will be no duplicate names in the table
...
1
A symbol table
used for an
operating
system

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

1
...
Simpson
3
...
Fernandez
MaxIds = 10

5
...

7
...

9
...

is examined during execution of the system, it will always contain no more than

In formal methods, a
“state” is stored data
that the system
accesses and alters
...

MaxIds staff identiﬁers and will contain no duplicates
...
In the context of formal methods,3 a
state is the stored data that a system accesses and alters
...

The ﬁnal concept is that of an operation
...
If the symbol table program is concerned with
adding and removing staff names from the symbol table, then it will be associated
with two operations: an operation to add a speciﬁed name to the symbol table and
an operation to remove an existing name from the table
...

An operation is associated with two conditions: a precondition and a postcon-

A “precondition”
deﬁnes the
circumstances in which
a particular operation
is valid
...

dition
...
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 also if there are fewer than MaxIds staff identifiers in the table
...
This is defined by its effect on the state
...

3

Recall that the term state has also been used in Chapters 12 and 21 as a representation of the
behavior of a system or objects
...
2
A block
handler

679

FORMAL METHODS

Unused blocks
1 3 4 6 9

Used blocks
2 5 7 8 10
11 12

Blocks are released
to queue when files
are deleted

Queued for entry into unused blocks

5 8 11

2
File #1

7

File #2

File #3

Block queue containing blocks from deleted files

Example 2: A Block Handler
...
Part of the
ﬁling subsystem is the block handler
...
During the operation of the computer,
ﬁles will be created and deleted, requiring the acquisition and release of blocks of
storage
...
When blocks
are released from a deleted ﬁle they are normally added to a queue of blocks waiting
to be added to the reservoir of unused blocks
...
2
...
The waiting blocks are held in a

Brainstorming
techniques can work
well when you need to
develop a data
invariant for a
reasonably complex
function
...

queue, with each element of the queue containing a set of blocks from a deleted ﬁle
...
The data invariant, expressed in natural
language, is
•

No block will be marked as both unused and used
...

•
•

No elements of the queue will contain the same block numbers
...

680

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

•

The collection of unused blocks will have no duplicate block numbers
...

Some of the operations associated with these data are
•

An operation that adds a collection of blocks to the end of the queue
...

•

An operation that checks whether the queue of blocks is empty
...
The postcondition is that the collection of blocks must be
added to the end of the queue
...
The postcondition is that the blocks must be added to the collection of
unused blocks
...
This means that the operation is always deﬁned, regardless of
what value the state has
...

Example 3: A Print Spooler
...
Often, there are not enough printing devices to satisfy
all current print requests simultaneously
...
The part of an operating system
that deals with the administration of such queues is known as a print spooler
...
We will
also assume that each device is associated with a limit of lines in a ﬁle which it will
print
...
Print spoolers sometimes impose this constraint in order to forbid large print
jobs that may occupy slow printing devices for exceptionally long periods
...
3
...
For example, Figure
25
...

CHAPTER 25

F I G U R E 25
...
The data invariant has ﬁve components:
•
•

States and operations
are analogous in many
ways to the class
deﬁnition for OO
systems
...

Each output device is associated with an upper limit on print lines
...

•
•

Each ﬁle is associated with a size
...

•

There will be no more than MaxDevs output devices administered by the
spooler
...
For example,
•

An operation that adds a new output device to the spooler together with its
associated print limit
...

•

An operation that adds a ﬁle to the queue associated with a particular output
device
...

•

An operation that moves a ﬁle from a queue associated with an output device
to another queue associated with a second output device
...
For example, the
ﬁrst operation would correspond to the spooler being notiﬁed of a new device being
attached to the computer containing the operating system that administers the
spooler
...

For example, the precondition for the ﬁrst operation is that the output device name
does not already exist and that there are currently less than MaxDevs output devices
known to the spooler
...

The precondition for the second operation (removing a ﬁle from a queue associated with a particular output device) is that the device is known to the spooler and
that at least one entry in the queue is associated with the device
...

The precondition for the fifth operation described (moving a file from a queue
associated with an output device to another queue associated with a second output
device) is
•

The ﬁrst output device is known to the spooler
...

•

The queue associated with the ﬁrst device contains the ﬁle to be moved
...

The postcondition is that the ﬁle is removed from one queue and added to another
queue
...
But we do so without emphasizing the mathematics that are
required to make the speciﬁcation formal
...

25
...
The intent of the section is to provide a brief
introduction
...
g
...

CHAPTER 25

FORMAL METHODS

683

25
...
1 Sets and Constructive Speciﬁcation
A set is a collection of objects or elements and is used as a cornerstone of formal
methods
...
e
...
Sets with a small number of elements are written within curly brackets
(braces) with the elements separated by commas
...

The order in which the elements appear within a set is immaterial
...
The # operator returns a set's cardinality
...

? What is
constructive
set speciﬁcation?

There are two ways of deﬁning a set
...
The second
approach is to create a constructive set speciﬁcation
...
Constructive set speciﬁcation is
preferable to enumeration because it enables a succinct deﬁnition of large sets
...

Consider the following constructive speciﬁcation example:
{n : ‫ | ގ‬n < 3
...
The signature speciﬁes the range of values that will be considered when forming the set, the predicate (a Boolean expression) defines how the set is to be constricted, and, finally, the term gives the general form of the item of the set
...
The predicate indicates that only natural numbers less than 3 are to
be included; and the term speciﬁes that each element of the set will be of the form n
...
For example, the preceding set could be speciﬁed as
(n : ‫ | ގ‬n < 3}
All the sets that have been described here have elements that are single items
...
For example, the
set speciﬁcation

684

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

{x, y : ‫ | ގ‬x + y = 10
...
This is the set
{ (1, 81), (2, 64), (3, 49),
...
However, the basic form and structure remain the same
...
2
...
These
symbols must be understood by the software engineer who intends to apply formal
methods
...
Spend
the time to familiarize
yourself with each, if
you intend to apply
formal methods
...
For example, the expression
x෈X
has the value true if x is a member of the set X and the value false otherwise
...

The opposite of the ෈ operator is the
x

operator
...
For example,
the predicate
13

{13, 1, 124, 22}

has the value false
...
The predicate
AʚB
has the value true if the members of the set A are contained in the set B and has the
value false otherwise
...
However, the predicate
{HD1, LP4, RC5} ʚ {HD1, RC2, HD3, LP1, LP4, LP6}
has a value of false because the element RC5 is not contained in the set to the right
of the operator
...
However, if its operands are equal, it has the value
true
...

A special set is the empty set ٠
...

The empty set has the property that it is a subset of every other set
...

The union operator takes two sets and forms a set that contains all the elements

“Mathematical
structures are among
the most beautiful
discoveries made by
the human mind
...
Thus, the result of the expression
{File1, File2, Tax, Compiler} ʜ {NewTax, D2, D3, File2}
is the set
{Filel, File2, Tax, Compiler, NewTax, D2, D3}
The intersection operator takes two sets and forms a set consisting of the common
elements in each set
...

The set difference operator, \, as the name suggests, forms a set by removing the
elements of its second operand from the elements of its ﬁrst operand
...

The value of the expression
{a, b, c, d} ʝ {x, y}
will be the empty set ٠
...

The ﬁnal operator is the cross product, ؋, sometimes known as the Cartesian product
...
The result is a set of pairs where
each pair consists of an element taken from the first operand combined with an

686

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

element from the second operand
...

A concept that is important for formal methods is that of a powerset
...
The symbol used for the powerset operator in this chapter is ‫
...
For example,
‫}}3 ,2 ,1{ ,}3 ,2{ ,}3 ,1{ ,}2 ,1{ ,}3{ ,}}2( ,}1{ ,٠{ = }3 ,2 ,1{ ސ‬
since all the sets are subsets of {1, 2, 3}
...
2
...
The meaning of common logical operators is well understood by
every software engineer
...

The equivalent mathematical operators to these are
ٙ

and

ٚ

or

¬

not

=
>

implies

Universal quantiﬁcation is a way of making a statement about the elements of a set
that is true for every member of the set
...

An example of its use is

᭙ i, j : ‫
...

25
...
4 Sequences
A sequence is a mathematical structure that models the fact that its elements are
ordered
...
For example,
{(1, Jones), (2, Wilson), (3, Shapiro), (4, Estavez)}

CHAPTER 25

FORMAL METHODS

687

is a sequence
...
In this book, sequences are designated using angle brackets
...
Therefore,
Ό Jones, Wilson, Shapiro΍ ϶ Ό Jones, Shapiro, Wilson΍
The empty sequence is represented as Ό ΍
...
Catenation, ៣,
is a binary operator that forms a sequence constructed by adding its second operand
to the end of its ﬁrst operand
...

Other operators that can be applied to sequences are head, tail, front, and last
...
For example,
headΌ2, 3, 34, 1, 99, 101΍ = 2
tailΌ2, 3, 34, 1, 99, 101΍ = Ό3, 34, 1,99, 101΍
lastΌ2, 3, 34, 1, 99, 101΍ = 101
frontΌ2, 3, 34, 1, 99, 101΍ = Ό2, 3, 34, 1, 99΍
Since a sequence is set of pairs, all set operators described in Section 25
...
2 are applicable
...
For example,
FileList : seq FILES
NoUsers : ‫ގ‬
describes a state with two components: a sequence of ﬁles and a natural number
...
3

A P P LY I N G M AT H E M AT I C A L N O TAT I O N F O R
F O R M A L S P E C I F I C AT I O N
To illustrate the use of mathematical notation in the formal speciﬁcation of a software component, we revisit the block handler example presented in Section 25
...
3
...
The block handler maintains a reservoir of unused
blocks and will also keep track of blocks that are currently in use
...
This has been depicted schematically in
Figure 25
...
4

? How can I
represent
states and data
invariants using
the set and logic
operators that
have already been
introduced?

A set named BLOCKS will consist of every block number
...
The state will be modeled by two sets and a
sequence
...
Both contain blocks—the used set contains
the blocks that are currently used in files and the free set contains blocks that are
available for new ﬁles
...
The state can be described as
used, free: ‫ ސ‬BLOCKS
BlockQueue: seq ‫ ސ‬BLOCKS
This is very much like the declaration of program variables
...
The data invariant can be written as
used ʝ free = ٠ ٙ
used ʜ free = AllBlocks ٙ

᭙ i: dom BlockQueue
...
i ≠ j = BlockQueue i ʝ BlockQueue j = ٠
>
The mathematical components of the data invariant match four of the bulleted,
natural-language components described earlier
...
The second line states that the collection of used blocks and

Extensive information on
formal methods can be
found at
archive
...
ox
...
uk/formalmethods
...

The third line indicates the ith element in the block queue will always be a subset
of the used blocks
...
The final two natural language components of the data invariant are implemented by virtue of the fact that used and free are sets and therefore will not
contain duplicates
...
The precondition is that there must be at least one item in the
queue:
#BlockQueue > 0,
The postcondition is that the head of the queue must be removed and placed in the
collection of free blocks and the queue adjusted to show the removal:

4

If your recollection of the block handler example is hazy, please return to Section 25
...
3 to review
the data invariant, operations, preconditions, and postconditions associated with the block
handler
...
Hence, the ﬁrst component of the preceding expression states
that the new used blocks (used’)will be equal to the old used blocks minus the blocks
that have been removed
...
The third component states that the new block queue will be equal to the tail of the old value of
the block queue; that is, all elements in the queue apart from the ﬁrst one
...
The precondition

? How do I
represent
pre- and postconditions?

is that Ablocks is currently a set of used blocks:
Ablocks ʕ used
The postcondition is that the set of blocks is added to the end of the block queue and
the set of used and free blocks remains unchanged:
BlockQueue' = BlockQueue ៣ ΌAblocks΍ ٙ
used' = used ٙ
free' = free
There is no question that the mathematical speciﬁcation of the block queue is considerably more rigorous that a natural language narrative or a graphical model
...

25
...

The syntactic domain of a formal speciﬁcation language is often based on a syntax that is derived from standard set theory notation and predicate calculus
...
2
...
g
...

The semantic domain of a speciﬁcation language indicates how the language represents system requirements
...
A formal grammar (such as BNF) can be used to describe the
syntax of the programming language
...
A speciﬁcation language must have a semantic domain that is broader; that is,
the semantic domain of a speciﬁcation language must be capable of expressing ideas
such as, "For all x in an inﬁnite set A, there exists a y in an inﬁnite set B such that the
property P holds for x and y" [WIN90]
...
For example, a syntax and semantics can be developed to specify states and state transition, events and their effect on
state transition, synchronization and timing
...
We did this in a less formal fashion in Chapters 12 and 21
...
Analogous notation
was used to describe object-oriented systems
...
The semantics of each representation provides
complementary views of the system
...
Another formal relation
depicts all functions that occur within a given state
...

A variety of formal speciﬁcation languages are in use today
...
In this chapter, the Z speciﬁcation language is used for illustrative purposes
...

25
...
A schema is
essentially the formal speciﬁcation analog of the programming language subroutine
or procedure
...

In this section, we use the Z specification language to model the block handler
example, introduced in Section 25
...
3 and discussed further in Section 25
...
A summary of Z language notation is presented in Table 25
...
The following example of a
schema describes the state of the block handler and the data invariant:

CHAPTER 25

TA B L E 2 5
...
Z provides a construct, called a schema, to
describe a speciﬁcation’s state space and operations
...
In Z, the schema X is deﬁned by the form
———X–––––––––––———————————————
declarations
————————————————————————
predicates
————————————————————————
Global functions and constants are deﬁned by the form
declarations
————————————————————————
predicates
The declaration gives the type of the function or constant, while the predicate gives it value
...

Sets:
S:‫ސ‬X
x෈S
x S
SʕT
SʜT
SʝT
S\T
{x}
‫ގ‬
S:‫ކ‬X
max (S)

S is declared as a set of Xs
...

x is not a member of S
...

The union of S and T: It contains every member of S or T or both
...

The difference of S and T: It contains every member of S except those also in T
...

Singleton set: It contains just x
...

S is declared as a ﬁnite set of Xs
...

Functions:
f:X >→ Y
dom f
ran f
f ᮍ {x → y}
{x} ᭠ f
–

f is declared as a partial injection from X to Y
The domain of f: the set of values x for which f (x) is deﬁned
...

A function that agrees with f except that x is mapped to y
...

Logic:
PٙQ
P = Q
>
␪ S’ = ␪ S

P and Q: It is true if both P and Q are true
...

No components of schema S change in an operation
...
BlockQueue i ʕ used ٙ

᭙ i, j : dom BlockQueue
...
The part above the central line represents the vari-

WebRef
Detailed information on
the Z language, including
FAQ, can be found at
archive
...
ox
...
uk/z
...

Whenever the schema representing the data invariant and state is used in another
schema it is preceded by the ⌬ symbol
...
As the last sentence implies, schemas can be used to describe operations
...

The second operation, which adds a collection of blocks to the end of the queue,
is represented as
———AddBlock—————————————————
⌬BlockHandler
Ablocks? : BLOCKS
—————————————————————————
Ablocks? ʕ used
BlockQueue' = BlockQueue ៣ ΌAblocks?΍
used' = used ٙ
free' = free
——————————————————————————

CHAPTER 25

FORMAL METHODS

693

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

25
...

Bowan and Hinchley [BOW95] have coined “the ten commandments of formal methods” as a guide for those who are about to apply this important software engineering approach
...
Thou shalt choose the appropriate notation
...

Follow these
“commandments” and
be sure that everyone
has received proper
training
...

2
...
It is generally not necessary
to apply formal methods to every aspect of a major system
...

3
...
Formal methods have high startup costs
...
These costs must be considered when examining the return on investment associated with formal methods
...
Thou shalt have a formal methods guru on call
...

5
...
It is
possible, and in many cases desirable, to integrate formal methods with con-

WebRef

ventional or object-oriented methods (Chapters 12 and 21)
...
cl
...
uk/
users/mgh1001

strengths and weakness
...
6
6
...
Formal methods provide a concise,
unambiguous, and consistent method for documenting system requirements
...

5
6

This treatment is a much abbreviated version of [BOW95]
...

694

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

7
...
“There is nothing
magical about formal methods” [BOW95] and for this reason, other SQA
activities (Chapter 8) must continue to be applied as systems are developed
...
Thou shalt not be dogmatic
...
It is possible (some
would say, likely) that the ﬁnal system, even when developed using formal
methods, may have small omissions, minor bugs, and other attributes that do
not meet expectations
...
Thou shalt test, test, and test again
...
Formal methods do not
absolve the software engineer from the need to conduct well-planned, thorough tests
...
Thou shalt reuse
...
Formal methods do not change this reality
...

25
...
Liskov and Bersins [LIS86] summarize these in the following way:
Formal speciﬁcations can be studied mathematically while informal speciﬁcations cannot
...
Certain forms of incompleteness or inconsistency can be detected automatically
...

But problems remain
...

Timing, control, and behavioral aspects of a problem are more difﬁcult to represent
...
g
...
Finally, speciﬁcation using formal methods is more difﬁcult to learn than methods such as structured analysis and
represents a signiﬁcant "culture shock" for some software practitioners
...
When and if this occurs, mathematically
based speciﬁcation may be adopted by a wider segment of the software engineering
community
...
See [YOU94]
...
8

FORMAL METHODS

695

SUMMARY
Formal methods provide a foundation for speciﬁcation environments leading to analysis models that are more complete, consistent, and unambiguous than those produced using conventional or object-oriented methods
...

The underlying concepts that govern formal methods are, (1) the data invariant, a
condition true throughout the execution of the system that contains a collection of
data; (2) the state, the stored data that a system accesses and alters; and (3) the operation, an action that takes place in a system and reads or writes data to a state
...

Discrete mathematics—the notation and heuristics associated with sets and constructive speciﬁcation, set operators, logic operators, and sequences—forms the basis
of formal methods
...

Z, like all formal speciﬁcation languages, has both syntactic and semantic domains
...
The semantic domain enables the language to express
requirements in a concise manner
...

A decision to use formal methods must consider startup costs as well as the cultural changes associated with a radically different technology
...

REFERENCES
[BOW95] Bowan, J
...
and M
...
Hinchley, “Ten Commandments of Formal Methods,”
Computer, vol
...
4, April 1995
...
and F
...
Schneider, A Logical Approach to Discrete Math, Springer-

Verlag, 1993
...
V
...
J
...

[HAL90] Hall, A
...
11–20
...
G
...
A
...

[HOR85] Hoare, C
...
R
...

[JON91] Jones, C
...
, Systematic Software Development Using VDM, 2nd ed
...

696

PA R T F I V E

[LIS86]

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Liskov, B
...
, and V
...
Gehani and A
...
McKittrick (eds
...
3
...
J
...
), Encyclopedia of Software Engineering, Wiley, 1994
...
H
...
, McGraw-Hill,
1995
...
M
...

[SPI92]

Spivey, J
...
, The Z Notation: A Reference Manual, Prentice-Hall, 1992
...
A
...

[WIN90] Wing, J
...
, "A Speciﬁer's Introduction to Formal Methods," Computer, vol
...
9, September 1990, pp
...

[YOU94] Yourdon, E
...
, October 1994
...
1
...
1
...
Provide three examples of each from your
own experience
...
2
...
Is there a downside?
25
...
You have been assigned to a team that is developing software for a fax modem
...
The phone book
function enables up to MaxNames people to be stored along with associated company names, fax numbers, and other related information
...
The data invariant
...
The state
...
The operations that are likely
...
4
...
This is accomplished by identifying, collecting, and reassigning blocks of memory that have been assigned to an existing application but are not being used
...
Making appropriate assumptions and using natural language, deﬁne
a
...

b
...

c
...

CHAPTER 25

FORMAL METHODS

697

25
...
Develop a constructive speciﬁcation for a set that contains tuples of natural
numbers of the form (x, y, z2) such that the sum of x and y equals z
...
6
...
It checks the hardware conﬁguration to determine whether various devices (of many possible devices) are present,
and determines whether speciﬁc versions of system software and drivers are already
installed
...

25
...
Attempt to develop a expression using logic and set operators for the following statement: “For all x and y, if x is the parent of y and y is the parent of z, then x is
the grandparent of z
...
” Hint: Use the function P(x, y) and
G(x, z) to represent parent and grandparent functions, respectively
...
8
...
Both numbers should be between
100 and 200 inclusive
...
9
...
3
...

25
...
Develop a mathematical description for the state and data invariant for Problem 25
...
Reﬁne this description in the Z speciﬁcation language
...
11
...
1, select some part of the SafeHome security system described earlier in this book and attempt to specify it with Z
...
12
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
In addition to the books used as references in this chapter, a fairly large number of
books on formal methods topics have been published over the past decade
...
, Formal Speciﬁcation and Documentation using Z: A Case Study Approach, International Thomson Computer Press, 1996
...
, A Programming Approach to Formal Methods, McGraw-Hill, 2000
...
and R
...

Craigen, D
...
Gerhart, and T
...
, 1995
...
, Z: An Introduction to Formal Methods, 2nd ed
...

Harry, A
...

Hinchley, M
...
Bowan, Applications of Formal Methods, Prentice-Hall, 1995
...
and J
...

Hussmann, H
...

Jacky, J
...

Lano, J
...
Haughton (eds
...

Rann, D
...
Turner, and J
...

Ratcliff, B
...

D
...

The September 1990, issues of IEEE Transactions on Software Engineering, IEEE Software, and IEEE Computer were dedicated to formal methods
...

Schuman (Formal Object-Oriented Development, Springer-Verlag, 1996) has edited
a book that addresses formal methods and object technologies, providing guidelines
on the selective use of formal methods, and showing how such methods can be used
in conjunction with OO approaches
...

A wide variety of information sources on formal methods and related subjects is
available on the Internet
...
mhhe
...
mhtml

CHAPTER

26
KEY
CONCEPTS
black-box spec
...
704
certiﬁcation
...
701

CLEANROOM SOFTWARE
ENGINEERING

he integrated use of conventional software engineering modeling (and
possibly formal methods), program veriﬁcation (correctness proofs), and
statistical SQA have been combined into a technique that can lead to
extremely high-quality software
...
Instead of the classic analysis, design, code, test, and debug cycle, the
cleanroom approach suggests a different point of view [LIN94]:

T

clear-box spec
...
706
functional spec
...
707
state-box spec
...
712
stimulus
...
713
veriﬁcation
...
Its process model incorporates the statistical quality certiﬁcation of code increments as they accumulate into a system
...
Like the formal methods presented in Chapter 25, the cleanroom
process emphasizes rigor in speciﬁcation and design, and formal veriﬁcation of
each design element using correctness proofs that are mathematically based
...

What is it? How many times

if we could dramatically reduce the number of

have you heard someone say “Do

mistakes (bugs) introduced as the software is

it right the first time”? That’s the

QUICK
LOOK

designed and built? That’s the premise of clean-

overriding philosophy of cleanroom software engi-

room software engineering
...
A “box”

construction commences and certiﬁcation of soft-

encapsulates the system (or some aspect of the

ware reliability as part of the testing activity
...
Correct-

bottom line is extremely low failure rates that

ness veriﬁcation is applied once the box structure

would be difﬁcult or impossible to achieve using

design is complete
...

verified for each box structure, statistical usage

Who does it? A specially trained software engineer
...
The software is tested by deﬁning a set of usage scenarios, determining the prob-

Why is it important? Mistakes create rework
...
Wouldn’t it be nice

random tests that conform to the probabilities
...
Statistical use testing exercises

bility for the software component
...
Test data

clear-box speciﬁcations are developed
...

are recorded
...

The hazards can be related to human safety, economic loss, or effective operation of
business and societal infrastructure
...

26
...
Rather than fabricating a product and
then working to remove defects, the cleanroom approach demands the discipline
required to eliminate defects in speciﬁcation and design and then fabricate in a “clean”
manner
...
”
Harlan Mills

Dyer, and Linger [MIL87] during the 1980s
...
Henderson [HEN95] suggests three possible reasons:
1
...

2
...

3
...
The use of cleanroom processes
requires rigorous application of defined processes in all life cycle phases
...

Despite elements of truth in each of these concerns, the potential beneﬁts of cleanroom software engineering far outweigh the investment required to overcome the
cultural resistance that is at the core of these concerns
...
1
...
A “pipeline of software increments” [LIN94] is developed by
small independent software engineering teams
...
Hence, functionality of the system grows with time
...
1
...
Once functionality has been assigned to the software element of the system, the pipeline of cleanroom increments is initiated
...
A project plan that adopts the incremental strategy is
developed
...
Special care must be taken to
ensure that certiﬁed increments will be integrated in a timely manner
...
Using techniques similar to those introduced in
Chapter 11, a more-detailed description of customer-level requirements (for
each increment) is developed
...
A speciﬁcation method that makes use of box
structures [HEV93] is used to describe the functional speciﬁcation
...
1
The cleanroom
process model

SE — system engineering
RG — requirements gathering
BSS — box structure specification
FD — formal design
CV — correctness verification

CG — code generation
CI — code inspection
SUT — statistical use testing
C — certification
TP — test planning

C

702

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

to the operational analysis principles discussed in Chapter 11, box structures
“isolate and separate the creative deﬁnition of behavior, data, and procedures

WebRef

at each level of reﬁnement
...
cleansoft
...
Using the box structure approach, cleanroom design is a
natural and seamless extension of speciﬁcation
...

Correctness veriﬁcation
...
Veriﬁcation (Sections 26
...
4) begins with the highest-level box structure
(speciﬁcation) and moves toward design detail and code
...

It is a habit
...
If these do not demonstrate that the speciﬁcation is correct, more
formal (mathematical) methods for veriﬁcation are used
...
The box structure speciﬁcations, represented in a specialized language, are translated into the
appropriate programming language
...
Then correctness veriﬁcation is conducted for the source code
...
The projected usage of the software is analyzed and
a suite of test cases that exercise a “probability distribution” of usage are planned
and designed (Section 26
...
Referring to Figure 26
...
Use-cases
provide excellent input
to the statistical test
planning process
...

Statistical use testing
...
Statistical use techniques [POO88] execute a series of tests
derived from a statistical sample (the probability distribution noted earlier) of
all possible program executions by all users from a targeted population (Section 26
...

Certiﬁcation
...

Like other software process models discussed elsewhere in this book, the cleanroom
process relies heavily on the need to produce high-quality analysis and design models
...
The real distinction of the
cleanroom approach is that formal veriﬁcation is applied to engineering models
...
1
...
To reach this goal, a cleanroom unique life cycle was deﬁned which focused on mathematics-based software engineering for correct software designs and on statistics-based
software testing for certiﬁcation of software reliability
...

1
...

2
...

3
...

Obviously, the cleanroom approach applies most, if not all, of the basic software
engineering principles and concepts presented throughout this book
...
But cleanroom
engineering diverges from conventional software practices by deemphasizing (some
would say, eliminating) the role of unit testing and debugging and dramatically
reducing (or eliminating) the amount of testing performed by the developer of the
software
...
Because
errors are deemed to be inevitable, each program module should be unit tested (to

“It’s a funny thing
about life: if you
refuse to accept
anything but the
best, you very often
get it
...
Somerset
Maugham

uncover errors) and then debugged (to remove errors)
...

The rework associated with these activities is costly and time consuming
...

In cleanroom software engineering, unit testing and debugging are replaced by
correctness veriﬁcation and statistically based testing
...

26
...
Data, function, and behavior are modeled
...

704

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

models must be partitioned (reﬁned) to provide increasingly greater detail
...

Cleanroom software engineering complies with the operational analysis principles by using a method called box structure specification
...
Through a process of
stepwise reﬁnement, boxes are reﬁned into a hierarchy where each box has referential transparency
...
This enables the analyst to partition a system hierarchically, moving
from essential representation at the top to implementation-speciﬁc detail at the bottom
...
The black box speciﬁes the behavior of a system or a part of a
system
...

State box
...
In this speciﬁcation view, inputs to
the state box (stimuli) and outputs (responses) are represented
...

Clear box
...
Stated simply, a clear box contains the procedural
design for the state box
...
2 illustrates the reﬁnement approach using box structure speciﬁcation
...
BB1 can be reﬁned
into a set of black boxes, BB1
...
n, each of which addresses a class of behavior
...
g
...
1
...

A state box (SB1
...
1) is then deﬁned for the black box (BB1
...
1)
...
1
...
1
...

Finally, SB1
...
1 is reﬁned into clear boxes (CB1
...
1
...

Box structure
reﬁnement and
veriﬁcation of
correctness occur
simultaneously
...

State-box specifications are verified to ensure that each conforms to the behavior
deﬁned by the parent black-box speciﬁcation
...

It should be noted that speciﬁcation methods based on formal methods (Chapter
25) can be used in lieu of the box structure speciﬁcation approach
...

CHAPTER 26

705

C L E A N R O O M S O F T WA R E E N G I N E E R I N G

F I G U R E 26
...
1
...
1

SB1
...
1

BB1
...
1

BB1
...
1
...
3

BB1
...
2

BB1
...
1
...
2

BB1
...
3

BB1
...
2
...
3 [MIL88]
...
For simple
software components, f may be a mathematical function, but in general, f is described
using natural language (or a formal speciﬁcation language)
...

for the black box
...
Like a class hierarchy, the black box speciﬁcation can exhibit usage hierarchies in which low-level boxes inherit the properties
of those boxes higher in the tree structure
...
2
...
Recalling the
discussion of behavioral modeling and state transition diagrams in Chapter 12, a state
is some observable mode of system behavior
...
3
A black-box
speciﬁcation

S

f : S*

R

R

706

PA R T F I V E

F I G U R E 26
...

As the transition is made, an action may occur
...

Referring to Figure 26
...
The stimulus, S,
that is input to the black box arrives from some external source and a set of internal
system states, T
...
When considered collectively, the state-subfunction pairs (t, g) deﬁne the black box function f
...
2
...

programming
...

As an example, consider the clear box shown in Figure 26
...
The black box, g,
shown in Figure 26
...
These, in turn, can be reﬁned into lower-level clear boxes as stepwise reﬁnement proceeds
...
This topic is considered in the next section
...
3

CLEANROOM DESIGN
The design approach used in cleanroom software engineering makes heavy use of
the structured programming philosophy
...

CHAPTER 26

F I G U R E 26
...
g
...
cdrom
...

The structured programming approach can be used effectively to reﬁne function,
but what about data design? Here a number of fundamental design concepts (Chapter 13) come into play
...
The concepts of data encapsulation, information hiding, and data typing are used to create the data design
...
3
...
With the clear box, the structured programming constructs and stepwise reﬁnement are used as illustrated in Figure 26
...

A program function, f, is reﬁned into a sequence of subfunctions g and h
...
Further reﬁnement illustrates continuing logical reﬁnement
...
To accomplish this, a set of generic correctness conditions are attached
to the structured programming constructs
...

708

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

F I G U R E 26
...
If you
“violate” the
constructs, correctness
proofs are difﬁcult or
impossible
...

It is important to note that the use of the structured programming constructs constrains the number of correctness tests that must be conducted
...

To illustrate correctness veriﬁcation for a procedural design, we use a simple example ﬁrst introduced by Linger, Mills, and Witt [LIN79]
...
The procedural design is represented using the ﬂowchart in Figure 26
...

CHAPTER 26

F I G U R E 26
...
8
...
The exit condition requires that x remain unchanged and take on a value within
the range noted in the ﬁgure
...
8 are true in all cases
...

sqrt

entry: [x ≥ 0]

y := 0

init: [x ≥ 0, and y = 0]

loop: [y2 ≤ x]

(y + 1)2 ≤ x
F I G U R E 26
...
The condition init demands that [x ≥ 0 and y = 0]
...
3 Therefore, the ﬁrst
part of the init condition, x ≥ 0, is satisﬁed
...
Therefore, the
second part of the init condition is also satisﬁed
...

2
...
These are called
subproofs
...
Since the cont condition is identical to
the loop condition, loop is true regardless of the ﬂow path that leads to it
...
The cont condition is encountered only after the value of y is incremented by
1
...
Hence, if (y + 1)2 ≤ x, it follows that y2 ≤ x
...

4
...
Hence, the yes
condition must be true when control ﬂow moves along the path shown
...
The exit condition ﬁrst demands that x remain unchanged
...
There are no function calls that use x
...
Since
the conditional test (y + 1)2 ≤ x must fail to reach the exit condition, it follows
that (y + 1)2 ≤ x
...
e
...

Therefore, (y + 1)2 > x and y2 ≤ x can be combined to satisfy the exit condition
...
An examination of the loop condition indicates that, because y is incremented and x ≥ 0, the loop must eventually terminate
...
7
...

A more rigorous mathematical approach to design veriﬁcation is possible
...
Interested readers
should refer to [LIN79]
...
3
...
Linger [LIN94] describes these in the following manner:
•

It reduces veriﬁcation to a ﬁnite process
...

This section and Figures 26
...
9 have been adapted from [LIN94]
...

CHAPTER 26

F I G U R E 26
...
An axiom of
replacement [LIN79] lets us substitute intended functions with their control
structure reﬁnements in the hierarchy of subproofs
...
9 requires proving that the
composition of the operations g1 and g2 with the intended function f2 has
the same effect on data as f1
...
This substitution localizes the proof argument to the
control structure at hand
...

proofs in any order
...
Even though all but the
most trivial programs exhibit an essentially inﬁnite number of execution
paths, they can be veriﬁed in a ﬁnite number of steps
...
Teams
can carry out the veriﬁcation through group analysis and discussion on the
basis of the correctness theorem, and they can produce written proofs when
extra conﬁdence in a life- or mission-critical system is required
...
During a team review, every correctness condition of every control structure is veriﬁed in turn
...
The requirement
for unanimous agreement based on individual veriﬁcation results in software
that has few or no defects before ﬁrst execution
...
Every software system, no matter how large, has top-level,
clear-box procedures composed of sequence, alternation, and iteration structures
...
So the correctness conditions for these high-level
control structures are veriﬁed in the same way as are those of low-level
structures
...

•

It produces better code than unit testing
...
By basing
veriﬁcation on function theory, the cleanroom approach can verify every possible effect on all data, because while a program may have many execution
paths, it has only one function
...
Most veriﬁcation conditions can be checked in a few minutes, but
unit tests take substantial time to prepare, execute, and check
...
In this context, it is often called correctness veriﬁcation
...
4

CLEANROOM TESTING
The strategy and tactics of cleanroom testing are fundamentally different from conventional testing approaches
...
The goal of cleanroom testing is to validate software requirements by demonstrating that a statistical sample of use-cases (Chapter
11) have been executed successfully
...
4
...
The user-visible behavior of the program is driven by inputs and events
that are often produced by the user
...
e
...
What subset of usecases will adequately verify the behavior of the program? This is the ﬁrst question
addressed by statistical use testing
...
To accomplish this, cleanroom testing teams (also called certiﬁcation teams)
must determine a usage probability distribution for the software
...
Based on interviews
with potential users, the creation of usage scenarios, and a general understanding
of the application domain, a probability of use is assigned to each stimuli
...
To illustrate, consider the SafeHome security system discussed earlier in
this book
...
Five stimuli
have been identiﬁed for this increment
...
To make selection of test cases easier, these probabilities
are mapped into intervals numbered between 1 and 99 [LIN94] and illustrated in the
following table:
Program Stimulus

Probability

Interval

Arm/disarm (AD)

50%

1–49

Zone set (ZS)

15%

50–63

Query (Q)

15%

64–78

Test (T)

15%

79–94

5%

95–99

Panic alarm

To generate a sequence of usage test cases that conform to the usage probability
distribution, a series of random numbers between 1 and 99 is generated
...

Hence, the sequence of usage test cases is deﬁned randomly but corresponds to the
appropriate probability of stimuli occurrence
...
Timing for tests is recorded so that interval times may
be determined
...
If a long sequence of tests is conducted without failure, the MTTF is low
and software reliability may be assumed high
...
For further information, see [DYE92]
...
4
...
Within the context of
the cleanroom software engineering approach, certiﬁcation implies that the reliability (measured by mean-time-to-failure, MTTF) can be speciﬁed for each component
...
Reusable software components can be stored along with their
usage scenarios, program stimuli, and probability distributions
...

This information is invaluable to others who intend to use the components
...
Usage scenarios must be created
...
A usage proﬁle is speciﬁed
...
Test cases are generated from the proﬁle
...
Tests are executed and failure data are recorded and analyzed
...
Reliability is computed and certiﬁed
...
In this section, we concentrate on reliability certiﬁcation
...
Software testing executes m random test cases and is
certiﬁed if no failures or a speciﬁed numbers of failures occur
...

Component model
...

The component model enables the analyst to determine the probability that
component i will fail prior to completion
...
The overall reliability of the system is projected and
certiﬁed
...

A detailed discussion of the computation of the sampling, component, and certiﬁcation models is beyond the scope of this book
...

26
...
It uses box structure speciﬁ-

CHAPTER 26

C L E A N R O O M S O F T WA R E E N G I N E E R I N G

715

cation (or formal methods) for analysis and design modeling and emphasizes correctness veriﬁcation, rather than testing, as the primary mechanism for ﬁnding and
removing errors
...

The cleanroom approach begins with analysis and design models that use a box
structure representation
...
Black boxes are used to represent the externally observable behavior of a system
...
A clear box is used to model the procedural design that is implied by the
data and operations of a state box
...
The
procedural design for a software component is partitioned into a series of subfunctions
...
If each exit condition is satisﬁed,
the design must be correct
...
Unlike
conventional testing, cleanroom software engineering does not emphasize unit or
integration testing
...
The error records that result are combined
with sampling, component, and certiﬁcation models to enable mathematical computation of projected reliability for the software component
...
It is a
software process model that emphasizes mathematical verification of correctness
and certiﬁcation of software reliability
...

REFERENCES
[CUR86] Curritt, P
...
, M
...
D
...
SE-12, no
...

[DYE92] Dyer, M
...

[HAU94] Hausler, P
...
, R
...
Trammel, “Adopting Cleanroom Software
Engineering with a Phased Approach,” IBM Systems Journal, vol
...
1, January
1994, pp
...

[HEN95] Henderson, J
...
8, No
...
11–14
...
R
...
D
...
31, no
...
232–251
...
M
...
D
...
I
...

716

PA R T F I V E

[LIN88]

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Linger, R
...
and H
...
Mills, “A Case Study in Cleanroom Software Engi-

neering: The IBM COBOL Structuring Facility,” Proc
...

[LIN94]

Linger, R
...
11, no
...
50–58
...
D
...
Dyer, and R
...
4, no
...
19–24
...
D
...
21, no
...
23–35
...
D
...
Iannino, and K
...

[POO88] Poore, J
...
and H
...
Mills, “Bringing Software Under Statistical Quality Control,” Quality Progress, November 1988, pp
...

[POO93] Poore, J
...
, H
...
Mills, and D
...
10, no
...
88–99
...
and P
...
Software Engineering, vol
...
6, June 1994, pp
...

PROBLEMS AND POINTS TO PONDER
26
...
If you had to pick one aspect of cleanroom software engineering that makes
it radically different from conventional or object-oriented software engineering
approaches, what would it be?
26
...
How do an incremental process model and certiﬁcation work together to produce high-quality software?
26
...
Using box structure speciﬁcation, develop “ﬁrst-pass” analysis and design models for the SafeHome system
...
4
...
13
...
5
...
15
...
6
...

26
...
Document a correctness verification proof for the bubble sort discussed in
Problem 26
...

26
...
Select a program component that you have designed in another context (or
one assigned by your instructor) and develop a complete proof of correctness for it
...
9
...
g
...
Create a set of usage scenarios for the program
...
4
...

26
...
For the program stimuli and probability distribution table developed in Problem 26
...

26
...
In your own words, describe the intent of certiﬁcation in the cleanroom software engineering context
...
12
...
4
...
Use [MUS87], [CUR86], and [POO93]
as a starting point
...
(Cleanroom Software Engineering: Technology and Process, Addison-Wesley, 1999) provides an in-depth treatment of all important aspects of the cleanroom
approach
...

Becker and Whittaker (Cleanroom Software Engineering Practices, Idea Group Publishing, 1996) present an excellent overview for those who are unfamiliar with cleanroom practices
...
Linger [LIN94] produced
one of the better introductions to the subject
...
ASSET can be contacted at
info@source
...
com
...
asset
...
htm
...

Michael Deck of Cleanroom Software Engineering has prepared a bibliography on
cleanroom topics
...
D
...

Deck, M
...
A
...

Lokan, C
...
, "The Cleanroom Process for Software Development," The Australian Computer
Journal, vol
...
4, November 1993
...
, "Cleanroom Software Engineering for Zero-Defect Software," Proc
...

Keuffel, W
...
39–46
...
R
...
A
...
B
...
69–76
...
H
...
D
...
44–54
...
A
...
D
...
, "Cleanroom and Organizational Change," Proc
...

Linger, R
...
, "Cleanroom Process Model," IEEE Software
...
50–58
...
C
...
A
...

Speciﬁcation, Design, and Review
Deck, M
...
, "Cleanroom and Object-Oriented Software Engineering: A Unique Synergy," 1996
Software Technology Conference, Salt Lake City, UT, April 24, 1996
...
D
...
01b, Cleanroom Software Engineering, 1994
...
, "Designing Software for Provable Correctness: The Direction for Quality Software,"
Information and Software Technology, vol
...
6, July–August 1988, pp
...

CHAPTER 26

C L E A N R O O M S O F T WA R E E N G I N E E R I N G

719

Testing and Certiﬁcation
Dyer, M
...
29 no
...
415–420
...
E
...
40–50
...
, "Quality Software via a Cleanroom Methodology," Embedded Systems Programming, September
...
36–52
...
A
...
G
...
Software Engineering, vol
...
812–824
...
E
...
40–50
...
R
...
D
...
32, no
...
232–251
...
, "OS32 and Cleanroom," Proc
...
1–40
...
A
...
17th Annual
Software Engineering Workshop, NASA Goddard Space Flight Center, December 1992
...
J
...
H
...
E
...
on Software
Engineering and Methodology, vol
...
1, January 1992, pp
...

Design verification via proof of correctness lies at the heart of the cleanroom
approach
...

A wide variety of information sources on cleanroom software engineering and
related subjects is available on the Internet
...
mhhe
...
mhtml

CHAPTER

27

COMPONENT-BASED
SOFTWARE ENGINEERING

classiﬁcation
...
Programmers have reused ideas, abstractions, and processes since the earliest
days of computing, but the early approach to reuse was ad hoc
...
This mitigates toward a more organized approach to reuse
...
” Clements [CLE95] describes CBSE in the following way:

component-based
development
...
[CBSE] embod-

KEY
CONCEPTS
adaptation
...
723
CBSE process
...
727

component types 724
composition
...
725
economics of
reuse
...
In the
same way that early subroutines liberated the programmer from thinking about
details, [CBSE] shifts the emphasis from programming software to composing software systems
...
At its
foundation is the assumption that there is sufficient commonality in many large
software systems to justify developing reusable components to exploit and satisfy

qualiﬁcation
...

structure points
...
Is it possible to construct complex systems
by assembling them from a catalog of reusable software components? Can this

QUICK
LOOK

What is it? You purchase a
“stereo system” and bring it home
...

been

Why is it important? It takes only a few minutes to

designed to fit a specific architectural style—

assemble the stereo system because the compo-

connections are standardized, communication

nents are designed to be integrated with ease
...
Assembly is easy

Although software is considerably more complex,

because you don’t have to build the system from

it follows that component-based systems are eas-

hundreds of discrete parts
...
In

thing
...
The

structure, thereby leading to a higher-quality

application is then assembled using these com-

result
...

What are the steps? CBSE encompasses two parallel engineering activities: domain engineering and

721

722

PA R T F I V E

QUICK
LOOK

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

component-based development
...

ciﬁc intent of ﬁnding functional, behavioral, and

What is the work product? Operational software,

data components that are candidates for reuse
...

software components, is the result of CBSE
...

systems and the application as a whole
...
We look at some of the answers in
this chapter
...
1

ENGINEERING OF COMPONENT-BASED SYSTEMS
On the surface, CBSE seems quite similar to conventional or object-oriented software
engineering
...
An architectural design (Chapter 14) is established, but rather than
moving immediately into more detailed design tasks, the team examines requirements to determine what subset is directly amenable to composition, rather than construction
...
1 If the requirement(s)
cannot be changed or deleted, conventional or object-oriented software engineering methods are applied to develop those new components that must be engineered to meet the requirement(s)
...
System requirements and architecture deﬁne

? What are
the CBSE

the components that will be required
...

That is, “the services that are provided, and the means by which consumers
access these services” [BRO96] are described as part of the component interface
...
The software
engineer must use a process of discovery and analysis to qualify each component’s ﬁt
...
In Chapter 14, we noted that software architecture represents design patterns that are composed of components (units of
functionality), connections, and coordination
...
”

and coordination
...
These components must be
adapted to meet the needs of the architecture or discarded and replaced by
other, more suitable components
...
Architectural style again plays a key role in the
way in which software components are integrated to form a working system
...
g
...

Component update
...
e
...

Each of these CBSE activities is discussed in more detail in Section 27
...

1

The implication is that the organization adjust its business or product requirements so that
component-based implementation can be achieved without the need for custom engineering
...

724

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

In the ﬁrst part of this section, the term component has been used repeatedly, yet
a deﬁnitive description of the term is elusive
...

•

Run-time software component—a dynamic bindable package of one or more
programs managed as a unit and accessed through documented interfaces
that can be discovered in run time
...

•

Business component—the software implementation of an “autonomous” business concept or business process
...
In addition to COTS components, the CBSE
process yields:

XRef
Certiﬁcation of
software components
can be accomplished
using cleanroom
methods
...

•

Qualiﬁed components—assessed by software engineers to ensure that not
only functionality, but performance, reliability, usability, and other quality factors (Chapter 19) conform to the requirements of the system or product to be
built
...

•

Assembled components—integrated into an architectural style and interconnected with an appropriate infrastructure that allows the components to be
coordinated and managed effectively
...

Because CBSE is an evolving discipline, it is unlikely that a unifying definition will
emerge in the near term
...
2

THE CBSE PROCESS
In Chapter 2, a “component-based development model” (Figure 2
...
The CBSE process, however, must be characterized in a manner that not only identiﬁes candidate components but also qualiﬁes each
component’s interface, adapts components to remove architectural mismatches,
assembles components into a selected architectural style, and updates components
as requirements for the system change [BRO96]
...
1
A process
model that
supports CBSE

725

C O M P O N E N T- B A S E D S O F T WA R E E N G I N E E R I N G

Domain Engineering
Software
Architecture
Development

Domain
Analysis

Domain
Model

Component-Based
Development

Analysis

Reusable
Component
Development

Structural
Model

Component
Qualification

Architectural
Design

Component
Adaptation
Component
Composition

Component
Engineering

Repository
Reusable
Artifacts/
Components

Component
Update
Application
Software

Testing

The process model for component-based software engineering emphasizes parallel tracks in which domain engineering (Section 27
...
Domain engineering performs the work required to

WebRef

establish a set of software components that can be reused by the software engineer
...
odateam
...

Figure 27
...
Domain engineering creates a model of the application domain that is used
as a basis for analyzing user requirements in the software engineering ﬂow
...
3
...
Finally, after reusable components have
been purchased, selected from existing libraries, or constructed (as part of domain
engineering), they are made available to software engineers during component-based
development
...
3

DOMAIN ENGINEERING
The intent of domain engineering is to identify, construct, catalog, and disseminate
a set of software components that have applicability to existing and future software

726

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

in a particular application domain
...

Domain engineering includes three major activities—analysis, construction, and

“Domain engineering
is about ﬁnding
commonalities
among systems to
identify components
that can be applied
to many systems,
and to identify
program families
that are positioned
to take fullest
advantage of those
components
...
An overview of domain analysis was presented in Chapter 21
...
Domain construction and dissemination are considered in later sections in this chapter
...
As greater emphasis is placed
on reuse, some believe that domain engineering will become as important as software engineering over the next decade
...
3
...
The steps in the process were deﬁned
as:
1
...

2
...

3
...

4
...

5
...

It is important to note that domain analysis is applicable to any software engineering paradigm and may be applied for conventional as well as object-oriented development
...
Select speciﬁc functions or objects
...
Abstract functions or objects
...
Deﬁne a taxonomy
...
Identify common features
...
Identify speciﬁc relationships
...
Abstract the relationships
...
Derive a functional model
...
Deﬁne a domain language
...

CHAPTER 27

C O M P O N E N T- B A S E D S O F T WA R E E N G I N E E R I N G

727

Although the steps just noted provide a useful model for domain analysis, they
provide no guidance for deciding which software components are candidates for
reuse
...

For additional information on domain analysis, see [PRI93]
...
3
...
To make this determination, it is necessary
to define a set of domain characteristics that are shared by all software within a
domain
...
For example, generic characteristics might include the importance of safety/reliability, programming language, concurrency in processing, and
many others
...
The
value assigned to Dpi represents an ordinal scale that is an indication of the relevance
of the characteristic for component p
...
1

Domain Characteristics Affecting Reuse [BAS94]

Product

Process

Personnel

Requirements stability
Concurrent software
Memory constraints
Application size
User interface complexity
Programming language(s)
Safety/reliability
Lifetime requirements
Product quality
Product reliability

Process model
Process conformance
Project environment
Schedule constraints
Budget constraints
Productivity

Motivation
Education
Experience/training
• application domain
• process
• platform
• language
Development team
productivity

4:

clearly relevant, and if the new software does not have this characteristic,
reuse will be inefﬁcient but may still be possible

5:

clearly relevant, and if the new software does not have this characteristic,
reuse will be ineffective and reuse without the characteristic is not recommended

When new software, w, is to be built within the application domain, a set of domain

WebRef
A worthwhile report
addressing object
technology, architectures,
and domain analysis can
be found at
www
...
cmu
...

html

characteristics is derived for it
...

Table 27
...
These domain characteristics must be taken into account in order to
reuse a component effectively
...
In some cases (ideally, a limited number), “reinventing the wheel” may
still be the most cost-effective choice
...
3
...
Structural modeling is a pattern-based domain
engineering approach that works under the assumption that every application domain
has repeating patterns (of function, data, and behavior) that have reuse potential
...
The architectures of systems using structural models are characterized by multiple ensembles that are composed from these model elements
...

CHAPTER 27

C O M P O N E N T- B A S E D S O F T WA R E E N G I N E E R I N G

729

Each application domain can be characterized by a structural model (e
...
, aircraft
avionics systems differ greatly in speciﬁcs, but all modern software in this domain
has the same structural model)
...

McMahon [MCM95] describes a structure point as “a distinct construct within a

? What is a
“structure
point” and what
are its
characteristics?

structural model
...
A structure point is an abstraction that should have a limited number of
instances
...
In addition, the abstraction should recur
throughout applications in the domain
...

2
...
In addition, the interface to the structure point should be relatively
simple
...
The structure point should implement information hiding by isolating all
complexity contained within the structure point itself
...

As an example of structure points as architectural patterns for a system, consider
the domain of software for alarm systems
...
In every case, however, a set of predictable structural
patterns are encountered:
•
•

A structure point can
be viewed as a design
pattern that can be
found repeatedly in
applications within a
speciﬁc domain
...

A bounds setting mechanism that allows the user to establish bounds on the
parameters to be measured
...

•

A response mechanism that reacts to the input provided by the sensor management system
...

Each of these structure points is integrated into a domain architecture
...

•

Database—the repository for all objects relevant to the application domain
...

•

Reporting facility—the function that produces output of all kinds
...

Structure points have been suggested as an alternative to lines of code and function
points for software cost estimation [MCM95]
...
6
...

27
...
Using analysis and architectural design methods discussed earlier in
this book, the software team reﬁnes an architectural style that is appropriate for the
analysis model created for the application to be built
...
Hence, the task ﬂow for component-based development has two parallel paths
(Figure 27
...
When reusable components are available for potential integration into
the architecture, they must be qualified and adapted
...
The resultant components are then “composed”
(integrated) into the architecture template and tested thoroughly
...
4
...
Some of these
reusable components are developed in-house, others can be extracted from existing
applications, and still others may be acquired from third parties
...
It is for this reason that a sequence of component-based development activities are applied when a component is proposed for use
...
g
...

2

It should be noted that the architectural style is often inﬂuenced by the generic structural model
created during domain engineering (see Figure 27
...

CHAPTER 27

C O M P O N E N T- B A S E D S O F T WA R E E N G I N E E R I N G

731

The interface description provides useful information about the operation and use
of a software component, but it does not provide all of the information required to
determine if a proposed component can, in fact, be reused effectively in a new application
...

considered during
component
qualiﬁcation?

•

Development and integration tools required by the component
...
g
...

•

Service requirements, including operating system interfaces and support
from other components
...

•

Embedded design assumptions, including the use of speciﬁc numerical or
nonnumerical algorithms
...

Each of these factors is relatively easy to assess when reusable components that have
been developed in-house are proposed
...
However, it is much more difﬁcult to determine the internal workings
of COTS or third-party components because the only available information may be
the interface speciﬁcation itself
...
The implication of “easy integra-

“Component
integrators need to
discover the function
and form of
software
components
...
To miti-

for all components in the library, (2) common activities such as data management
exist for all components, and (3) interfaces within the architecture and with the external environment have been implemented in a consistent manner
...
When a software team has full access to the internal design
and code for a component (often not the case when COTS components are used)
white-box wrapping is applied
...
Gray-box wrapping is applied
when the component library provides a component extension language or API
that enables conflicts to be removed or masked
...
The software team must determine whether the effort required to adequately wrap a component is justiﬁed or whether a custom component (designed to
eliminate the conﬂicts encountered) should be engineered instead
...
To accomplish
this, an infrastructure must be established to bind the components into an operational system
...

Among the many mechanisms for creating an effective infrastructure is a set of
four “architectural ingredients” [ADL95] that should be present to achieve component composition:
Data exchange model
...
g
...
The data exchange mechanisms not only allow
human-to-software and component-to-component data transfer but also transfer among system resources (e
...
, dragging a ﬁle to a printer icon for output)
...
A variety of tools, macros, and scripts should be implemented
to facilitate interaction between reusable components
...
Heterogeneous data (e
...
, graphical data, voice/video,
text, and numerical data) contained in a “compound document” should be
organized and accessed as a single data structure, rather than a collection of
separate ﬁles
...

Underlying object model
...
That is, objects must be capable of communicating across a network
...

Because the potential impact of reuse and CBSE on the software industry is enormous, a number of major companies and industry consortia3 have proposed standards for component software:

3

An excellent discussion of the “distributed objects” standards is presented in [ORF96] and
[YOU98]
...
The Object Management Group has published a common
object request broker architecture (OMG/CORBA)
...
omg
...
When components are built using the OMG/CORBA standard, integration of those components (without modiﬁcation) within a system
is assured if an interface deﬁnition language (IDL) interface is created for every
component
...
Requests are made
via an IDL or dynamically at run time
...

CORBA is discussed further in Chapter 28
...
Microsoft has developed a component object model
(COM) that provides a speciﬁcation for using components produced by various vendors within a single application running under the Windows operating system
...
microsoft
...
From the point of view of the application,
“the focus is not on how [COM objects are] implemented, only on the fact
that the object has an interface that it registers with the system, and that it
uses the component system to communicate with other COM objects”
[HAR98]
...
The JavaBean component system is a
portable, platform independent CBSE infrastructure developed using the Java
programming language
...
sun
...
The JavaBean component system encompasses a set of tools, called the Bean Development Kit (BDK), that allows
developers to (1) analyze how existing Beans (components) work, (2) customize their behavior and appearance, (3) establish mechanisms for coordination and communication, (4) develop custom Beans for use in a speciﬁc
application, and (5) test and evaluate Bean behavior
...
Although many developers have standardized on one of the standards, it is likely that large software organizations may choose to use all three
standards, depending on the application categories and platforms that are
chosen
...

734

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

27
...
2 Component Engineering
As we noted earlier in this chapter, the CBSE process encourages the use of existing
software components
...
That is, new software components must be developed and integrated with
existing COTS and in-house components
...

Nothing is magical about creating software components that can be reused
...
5 In this section we will not revisit these topics
...

27
...
3 Analysis and Design for Reuse
The components of the analysis model were discussed in detail in Parts Three and
Four of this book
...
Written speciﬁcations are then used to describe these models
...

Ideally, the analysis model is analyzed to determine those elements of the model
that point to existing reusable components
...
As you build the
analysis model ask
yourself, “Is it likely
that this object or
function has been
encountered in other
applications of this
type?” If the answer
is, “Yes,” a
component may
already exist
...
”
Bellinzoni, Gugini, and Pernici [BEL95] describe one approach for object-oriented
systems:
Components are deﬁned and stored as speciﬁcation, design, and implementation classes
at various levels of abstraction—with each class being an engineered description of a product from previous applications
...

Automated tools are used to browse a repository in an attempt to match the requirement noted in the current specification with those described for existing reusable
components (classes)
...
3
...

If speciﬁcation matching yields components that ﬁt the needs of the current application, the designer can extract these components from a reuse library (repository)
and use them in the design of new systems
...

5

To learn more about these topics, see Chapters 13 through 16 and 20 through 22
...

As we have already noted, DFR requires the software engineer to apply solid soft-

Although special issues
must be considered
when reuse is an
objective, focus on the
basic principles of
good design
...

ware design concepts and principles (Chapter 13)
...
Binder [BIN93] suggests a number of key
issues6 that form a basis for design for reuse:
Standard data
...
g
...
All design components can then be characterized to
make use of these standard data structures
...
Three levels of interface protocol should be
established: the nature of intramodular interfaces, the design of external
technical (nonhuman) interfaces, and the human/machine interface
...
The structure model (Section 27
...
3) can serve as a
template for the architectural design of a new program
...
New components that conform to this framework have a higher probability for subsequent reuse
...
Construction can
be accomplished using conventional third generation programming languages, fourth
generation languages and code generators, visual programming techniques, or more
advanced tools
...
5

CLASSIFYING AND RETRIEVING COMPONENTS
Consider a large university library
...
But to access these resources, a categorization scheme must be developed
...
”
Samuel Johnson

librarians have deﬁned a classiﬁcation scheme that includes a Library of Congress
classiﬁcation code, keywords, author names, and other index entries
...

Now, consider a large component repository
...
But how does a software engineer find the one she
needs? To answer this question, another question arises: How do we describe software components in unambiguous, classiﬁable terms? These are difﬁcult questions,
and no deﬁnitive answer has yet been developed
...

6

In general, the design for reuse preparations should be undertaken as part of domain engineering
(Section 27
...

736

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

27
...
1 Describing Reusable Components
A reusable software component can be described in many ways, but an ideal description encompasses what Tracz [TRA90] has called the 3C model—concept, content,
and context
...

The concept of a software component is “a description of what the component
does” [WHI95]
...
The concept should communicate the intent of the component
...
In essence, the
content is information that is hidden from casual users and need be known only to
those who intend to modify or test the component
...
That is, by specifying conceptual, operational, and implementation features,
the context enables a software engineer to ﬁnd the appropriate component to meet
application requirements
...
ssg
...
af
...
html#GD

To be of use in a pragmatic setting, concept, content, and context must be translated into a concrete speciﬁcation scheme
...
g
...
The methods proposed can be categorized into
three major areas: library and information science methods, artificial intelligence
methods, and hypertext systems
...

Figure 27
...
Controlled
indexing vocabularies limit the terms or syntax that can be used to classify an object
(component)
...
2
A taxonomy
of indexing
methods
[FRA94]

Uncontrolled

Keyword

Terms extracted
from text

Terms not extracted
from text

Enumerated

Descriptors

With syntax

Faceted

Subject
headings

Without syntax

Thesaurus

CHAPTER 27

C O M P O N E N T- B A S E D S O F T WA R E E N G I N E E R I N G

737

of the description
...
Components are described by a hierarchical

? What are
options

structure in which classes and varying levels of subclasses of software com-

available for
classifying
components?

ponents are deﬁned
...
For example, an enumerated hierarchy for
window operations7 might be
window operations
display
open
menu-based
openWindow
system-based
sysWindow
close
via pointer

...

move

...

The hierarchical structure of an enumerated classiﬁcation scheme makes it
easy to understand and to use
...

Faceted classiﬁcation
...
These features, called facets, are then
ranked by importance and connected to a component
...
The set of facets that
describe a component is called the facet descriptor
...

7

Only a small subset of all possible operations is noted
...
For example, if function is a facet of a component,
typical values assigned to this facet might be
function = (copy, from) or (copy, replace, all)
The use of multiple facet values enables the primitive function copy to be
reﬁned more fully
...
When a software engineer wants to
query the library for possible components for a design, a list of values is
speciﬁed and the library is searched for matches
...
This enables the search to encompass not only the keyword speciﬁed by the software engineer but also technical synonyms for those keywords
...
Because new facet values can be added easily, the
faceted classiﬁcation scheme is easier to extend and adapt than the enumeration approach
...
A set of attributes is deﬁned for all components in a domain area
...
In fact, attribute value classiﬁcation is
similar to faceted classiﬁcation with the following exceptions: (1) no limit is
placed on the number of attributes that can be used; (2) attributes are not
assigned priorities, and (3) the thesaurus function is not used
...
” It would appear that further
work remains to be done in the development of effective classiﬁcation schemes for
reuse libraries
...
5
...

•

A library management system that provides access to the database
...
g
...

•

CBSE tools that support the integration of reused components into a new
design or implementation
...

The reuse library is one element of a larger CASE repository (Chapter 31) and provides facilities for the storage of software components and a wide variety of reusable
artifacts (e
...
, speciﬁcations, designs, code fragments, test cases, user guides)
...
A component classiﬁcation scheme (Section
27
...
1) serves as the basis for library queries
...
If an initial query results in a voluminous list of candidate components, the query is reﬁned to narrow the list
...

A detailed discussion of the structure of reuse libraries and the tools that manage
them is beyond the scope of this book
...

27
...
In theory, it should
provide a software organization with advantages in quality and timeliness
...
But are there hard data that support our intuition?
To answer this question we must ﬁrst understand what actually can be reused in
a software engineering context and then what the costs associated with reuse really
are
...

27
...
1 Impact on Quality, Productivity, and Cost
Considerable evidence from industry case studies (e
...
, [HEN95], [MCM95], [LIM94])

CBSE is an economic
“no brainer” if the
components available
are right for the job
...

indicates substantial business beneﬁts can be derived from aggressive software reuse
...

Quality
...
In
reality, formal veriﬁcation is not carried out routinely, and defects can and do
occur
...
Over time, the component becomes virtually defect free
...
9 defects per KLOC, while the rate for newly developed

Although empirical
data vary, industry
evidence indicates that
reuse does provide
substantial cost
beneﬁt
...
1 defects per KLOC
...
0 defects per KLOC—a 51 percent improvement from the expected rate, had the application been developed without reuse
...
Although
anecdotal reports span a reasonably wide spectrum of quality improvement percentages, it is fair to state that reuse provides a nontrivial beneﬁt in terms of the
quality and reliability for delivered software
...
When reusable components are applied throughout the software
process, less time is spent creating the plans, models, documents, code, and data
that are required to create a deliverable system
...
Hence, productivity
is improved
...

Cost
...

Cs can be determined by applying one or more of the estimation techniques discussed in Chapter 5
...

•

Domain architecture development
...

•

Support and enhancement of reuse components
...

•

Creation or acquisition and operation of a reuse repository
...

Although costs associated with domain analysis (Section 27
...

8

Many extenuating circumstances (e
...
, application area, problem complexity, team structure and
size, project duration, technology applied) can have an impact on the productivity of a project
team
...
6
...
3
...
A software designer (or system engineer) can develop an architecture for a new application, system, or product by defining a domain architecture and then populating it with structure points
...

Even though structure points are reusable, their qualification, adaptation, integration, and maintenance costs are nontrivial
...

Since all structure points (and reusable components in general) have a past history, cost data can be collected for each
...
These data can then be analyzed to
develop projected costs for the next instance of reuse
...
Each of these reusable
components has been used in a number of other applications and average costs for

? Is there a
quick
calculation that
allows us to
estimate the cost
beneﬁt of
component reuse?

qualiﬁcation, adaptation, integration, and maintenance are available
...

Equal = effort required to qualify SP1, SP2, and SP3
...

Eint

= effort required to integrate SP1, SP2, and SP3
...

27
...
3 Reuse Metrics
A variety of software metrics have been developed in an attempt to measure the benefits of reuse within a computer-based system
...

Creuse is the cost of developing S with reuse
...

A general measure of reuse in object-oriented systems, termed reuse leverage
[BAS94], is deﬁned as
Rlev = OBJreused/OBJbuilt

(27-3)

where
OBJreused is the number of objects reused in a system
...

27
...
And yet, many roadblocks remain to
be overcome before the CBSE process model is widely used throughout the industry
...
These include technical representations of the software (e
...
,
speciﬁcations, architectural models, designs), documents, test data, and even processrelated tasks (e
...
, inspection techniques)
...
The intent of domain engineering is to
identify, construct, catalog, and disseminate a set of software components in a particular application domain
...
In addition, componentbased development engineers new components that are based on the custom requirements of a new system,
Analysis and design techniques for reusable components draw on the same principles and concepts that are part of good software engineering practice
...

Component-based software engineering uses a data exchange model, tools, structured storage, and an underlying object model to construct applications
...
g
...
Classiﬁcation schemes enable a developer to ﬁnd and retrieve reusable components and
conform to a model that identiﬁes concept, content, and context
...

The economics of software reuse are addressed by a single question: Is it cost
effective to build less and reuse more? In general, the answer is, “Yes,” but a software project planner must consider the nontrivial costs associated with the qualiﬁcation, adaptation, and integration of reusable components
...
M
...

28, no
...
68–77
...
R
...
C
...
M
...
of the 19th Annual Software Engineering Workshop, NASA/GSFC, Greenbelt, MD, December 1994
...
, M
...
Gugini, and B
...
65–75
...
, “Design for Reuse Is for Real,” American Programmer, vol
...

8, August 1993, pp
...

[BRO96] Brown, A
...
and K
...
Wallnau, “Engineering of Component Based Systems,”
Component-Based Software Engineering, IEEE Computer Society Press, 1996, pp
...

[CHR95] Christensen, S
...
, “Software Reuse Initiatives at Lockheed,” CrossTalk, vol
...
5, May 1995, pp
...

[CLE95] Clements, P
...
, “From Subroutines to Subsystems: Component Based Software Development,” American Programmer, vol
...
11, November 1995
...
, et al
...

[FRA94] Frakes, W
...
and T
...
Pole, “An Empirical Study of Representation Methods
for Reusable Software Components,” IEEE Trans
...
SE-20, no
...
617–630
...
, “Navigating the Distributed Components Landscape,” Cutter IT
Journal, vol
...
2, December 1998, pp
...

[HEN95] Henry, E
...
Faller, “Large Scale Industrial Reuse to Reduce Cost and
Cycle Time,” IEEE Software, September 1995, pp
...

[HOO91] Hooper, J
...
and R
...
Chester, Software Reuse: Guidelines and Methods,
Plenum Press, 1991
...
W
...
G
...
3, no
...
208–212
...
and Wang, F
...
18, no
...
74–80
...
C
...
23–30
...
S
...
57–78
...
E
...
8, no
...
10–16
...
, D
...
Edwards, The Essential Distributed Objects Survival Guide, Wiley, 1996
...
, “Domain Analysis for Reusability,” Proc
...
23–29
...
, “Issues and Experiences in Software Reuse,” American Pro-

grammer, vol
...
8, August 1993, pp
...

[POL94] Pollak, W
...
Rissman, “Structural Models and Patterned Architectures,”
Computer, vol
...
8, August 1994, pp
...

[STA94] Staringer, W
...
61–68
...
, “Where Does Reuse Start?” Proc
...

[TRA95] Tracz, W
...
20, no
...
21–22
...
, “Models and Languages for Component Description and Reuse,”
ACM Software Engineering Notes, vol
...
2, April 1995, pp
...

[YOU98] Yourdon, E
...
), “Distributed Objects,” Cutter IT Journal, vol
...
12,
December 1998
...
1
...
Suggest three or four different ways that a software organization can
provide incentives for software engineers to reuse
...
2
...
Consider project
plans and cost estimates
...
3
...
1
...

27
...
How are characterization functions for application domains and component
classiﬁcation schemes the same? How are they different?

CHAPTER 27

C O M P O N E N T- B A S E D S O F T WA R E E N G I N E E R I N G

745

27
...
Develop a set of domain characteristics for information systems that are relevant to a university’s student data processing
...
6
...

27
...
Develop a simple structural model for an application domain assigned by your
instructor or one with which you are familiar
...
8
...
9
...
Get information on an object request broker tool and illustrate how the tool achieves the standard
...
10
...

27
...
Develop a faceted classiﬁcation scheme for an application domain assigned
by your instructor or one with which you are familiar
...
12
...
Present the data to your class
...
13
...
It is further estimated that 190 objects can be acquired from an existing repository
...
What is the
estimated cost of the system
...
Allen, Frost, and Yourdon (Component-Based Development
for Enterprise Systems: Applying the Select Perspective, Cambridge University Press,
1998) cover the entire CBSE process, using UML (Chapters 21 and 22) as the basis for
their modeling approach
...
Fowler (Analysis Patterns: Reusable Object Models,
Addison-Wesley, 1996) considers the application of architectural patterns within the
CBSE process and provides many useful examples
...

746

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Leach (Software Reuse: Methods, Models, and Costs, McGraw-Hill, 1997) provides
a detailed analysis of cost issues associated with CBSE and reuse
...

Dozens of books describing the industry’s component-based standards have been
published in recent years
...
A sampling for the three standards discussed in this chapter follows:
CORBA
Doss, G
...
, CORBA Networking With Java, Wordware Publishing, 1999
...
, CORBA for Real Programmers, Academic Press/Morgan Kaufmann, 1999
...
, CORBA 3 Fundamentals and Programming, Wiley, 1999
...
, J
...
Russell, Enterprise CORBA, Prentice-Hall, 1999
...
, K
...
Ewald, and C
...

Kirtland, M
...

Many organizations apply a combination of component standards
...
(COM-CORBA Interoperability, Prentice-Hall, 1999), Pritchard (COM and
CORBA Side by Side: Architectures, Strategies, and Implementations, Addison-Wesley,
1999), and Rosen et al
...

JavaBeans
Asbury, S
...
R
...

Valesky, T
...
, Enterprise Javabeans: Developing Component-Based Distributed Applications,
Addison-Wesley, 1999
...
and M
...

A wide variety of information sources on component-based software engineering
and component reuse is available on the Internet
...
mhhe
...
mhtml

CHAPTER

28
KEY
CONCEPTS
analysis
modeling
...
756
architecture
...
750
conﬁguration
options
...
753
database design
...
752
middleware
...
753
testing
...
Before the advent of this advanced machine tool technology,
machines could not hold tight tolerances
...

When a new computer-based system is to be developed, a software engineer is constrained by the limitations of existing computing technology and
empowered when new technologies provide capabilities that were unavailable
to earlier generations of engineers
...

New organization structures and new information processing approaches
(e
...
, intra- and Internet technologies, decision support systems, groupware,
and imaging) represent a radical departure from the earlier mainframe- and
minicomputer-based technologies
...

A

What is it? Client/server (c/s)

Why is it important? The impact of c/s systems on

architectures dominate the land-

business, commerce, government, and science is

scape of computer-based sys-

pervasive
...
g
...
Everything from automatic teller networks

ponent-based development, object request bro-

to the Internet exist because software residing on

kers, Java) change the way in which c/s systems

one computer—the client—requests services

are built, a solid software engineering process

QUICK
LOOK

and/or data from another computer—the server
...

Client/server software engineering blends con-

What are the steps? The steps involved in the

ventional principles, concepts, and methods dis-

engineering of c/s systems are similar to those

cussed earlier in this book with elements of

applied during OO and component-based soft-

object-oriented and component-based software

ware engineering
...

tionary, beginning with requirements elicitation
...

client or the server side of the c/s architecture
...
Imple-

engineering process—formal technical reviews

mentation and testing strive to exercise both client

assess the analysis and design models, specialized

and server functionality within the context of com-

reviews consider issues associated with component

ponent integration standards and the architecture
...

neering
...

In this chapter, we examine a dominant architecture for information processing—
client/server (c/s) systems
...
The objective of this chapter 1 is to present a brief overview of
client/server systems with an emphasis on the special software engineering issues
that must be addressed when such c/s systems are analyzed, designed, tested, and
supported
...
1

THE STRUCTURE OF CLIENT/SERVER SYSTEMS
Hardware, software, database, and network technologies all contribute to distributed
and cooperative computer architectures
...
”

cooperative computer architecture is as illustrated in Figure 28
...
A root system, sometimes a mainframe, serves as the repository for corporate data
...

The servers update and request corporate data maintained by the root system
...

In a c/s structure, the computer that resides above another computer (in Figure
28
...

The client requests services,2 and the server provides them
...
2, a number of different implementations can be achieved [ORF99]:

Alex Berson

1

2

Portions of this chapter have been adapted from course material developed by John Porter for the
client/server curriculum offered at The BEI Engineering School of Fairﬁeld University
...

In this context, services can be broadly interpreted to mean data, processing, or a combination of
the two
...
1
Distributed,
cooperative
computer
architectures
in a corporate
setting

Mainframe
root system

Server #1

Server #2

...

User-level
PC

LAN

User-level
PC

User-level
PC

File servers
...
The server
transmits these records to the client across the network
...
The client sends structured query language (SQL)
requests to the server
...
The server processes the SQL request and ﬁnds the requested information, passing back the results only to the client
...
The client sends a request that invokes remote procedures at the server site
...
A transaction occurs when a request results in the execution of the
remote procedure with the result transmitted back to the client
...
2
Client/server
options

Record request/reply
SQL request/reply
Transaction
Group communication

Server

750

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Groupware servers
...

28
...
1 Software Components for c/s Systems
Instead of viewing software as a monolithic application to be implemented on one
machine, the software that is appropriate for a c/s architecture has several distinct
subsystems that can be allocated to the client, the server, or distributed between both
machines:
User interaction/presentation subsystem
...
client-server
newsgroup can be found
at
www
...
org/
faqs/client-serverfaq/

all functions that are typically associated with a graphical user interface
...
This subsystem implements the requirements
deﬁned by the application within the context of the domain in which the
application operates
...
A groupware application might provide the facilities for enabling bulletin board communication or e-mail
...

Database management subsystem
...
Data manipulation and management may be as simple as the transfer of a record or as
complex as the processing of sophisticated SQL transactions
...
Middleware comprises software components that

Middleware establishes
the infrastructure that
enables c/s software
components to
interoperate
...
1
...
Orfali, Harkey, and Edwards [ORF99] have referred to middleware as “the
nervous system of a client/server system
...
1
...
1
...
When most of the functionality associated with each of the three subsystems
is allocated to the server, a fat server design has been created
...

A “fat” client
implements most
application-speciﬁc
functions at the client
...

Fat clients are commonly encountered when file server and database server
architectures are implemented
...
Fat servers are
often designed when transaction and groupware systems are implemented
...
The client software focuses on GUI and communication management
...
However, a more granular approach to
software component allocation deﬁnes ﬁve different conﬁgurations:

? What are
conﬁguration
options for c/s
software
components?

Distributed presentation
...
The server also contains the logic for preparing screen information, using software such as CICS
...

Remote presentation
...

Distributed logic
...
The server is
assigned database management tasks and the processes for client queries,
server ﬁle updates, client version control, and enterprise-wide applications
...
Applications on the server create a new data
source by formatting data that have been extracted from elsewhere (e
...
,
from a corporate level source)
...
Decision support systems are included in this category
...
The data forming the database is spread across
multiple servers and clients
...

In recent years, there has also been considerable emphasis on thin-client technology
...
Thin clients (network computers) offer substantially lower
per unit cost at little or no signiﬁcant performance loss when compared to desktop
machines
...
1
...
The availability of PC-based, Windows-based environments and the

“Some analysts view
client/server
computing as the
fourth wave of
[change in the
history of]
computing
...

If the database is to be shared by multiple users connected by the LAN,
it is typically located on the server
...

Static data that are used for reference should be allocated to the client
...

The balance of the application subsystem is distributed between the client and
server based on the distribution that optimizes the server and client conﬁgurations
and the network that connects them
...
If no match is found, an

Although distribution
guidelines are
worthwhile, every
system must be
considered on its own
merits
...

alternate search pattern is used
...
The ﬁrst network transmission from the client to the server would contain the parameters for both the primary and secondary search patterns
...
The response message to the client would contain the record found as a result of either the primary or the secondary search
...
If the second search
is required 50 percent of the time, placing the logic on the server to evaluate the ﬁrst
search and initiate the second search, if necessary, would reduce network trafﬁc by
33 percent
...
For example, an installation might contain some applications that require extensive GUI
processing and little central database processing
...
With this conﬁguration in place, other applications would favor the fat client approach so that the
capabilities of the server do not need to be upgraded
...
This simpliﬁes deployment of software updates
as changes are made to the application logic [PAU95]
...
1
...
These mechanisms are incorporated into the network and
operating system structure and are transparent to the end-user at the client site
...
Widely used in UNIX-based systems, pipes permit messaging between
different machines running on different operating systems
...
These permit one process to invoke the execution of
another process or module which resides on a different machine
...
This is used to pass SQL requests and associated data from one component (typically on the client) to another component
(typically the DBMS on the server)
...

In addition, object-oriented implementation of the c/s software subsystems results
in “linkage” using an object request broker
...

28
...
5 Middleware and Object Request Broker Architectures
The c/s software subsystems discussed in the preceding sections are implemented

An ORB enables an
object that resides on a
client to send a
message to a method
encapsulated by an
object that resides on a
server
...
An object request broker is middleware that enables an object that resides on a client to send a message
to a method that is encapsulated by an object that resides on a server
...

WebRef
The latest information on
component standards can
be obtained at
www
...
com,
www
...
com/
COM, and
java
...
com/beans

Three widely used standards that implement an object request broker philosophy—
CORBA, COM, and JavaBeans—were discussed brieﬂy in Chapter 27
...

The basic structure of a CORBA architecture is illustrated in Figure 28
...
When
CORBA is implemented in a client/server system, objects and object classes (Chapter 20) on both the client and the server are deﬁned using an interface description language, a declarative language that allows a software engineer to define objects,

754
F I G U R E 28
...
In order to accommodate a request for a server-resident method by a client-resident object, client and
server IDL stubs are created
...

Because requests for objects across the network occur at run time, a mechanism
for storing the object description must be established so that pertinent information
about the object and its location are available when needed
...
”
Thomas Mowbray
and Raphael
Malveau

accomplishes this
...
The request is then passed to the ORB core—an
implementation-specific part of the network operating system that manages
requests—and the request is fulﬁlled
...
At the server
site, an object adapter stores class and object information in a server-resident interface repository, accepts and manages incoming requests from the client, and performs a variety of other object management functions [ORF99]
...

CHAPTER 28

C L I E N T / S E RV E R S O F T WA R E E N G I N E E R I N G

755

Software development for a modern c/s system is object oriented
...

For further information on CORBA and its overall impact on software engineering for
c/s systems, the interested reader should refer to [HOQ99] and [SIE99]
...
2

S O F T WA R E E N G I N E E R I N G F O R C / S S Y S T E M S
A number of different software process models were introduced in Chapter 2
...

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 software components that have
been implemented on client and server machines
...
3

A N A LY S I S M O D E L I N G I S S U E S
The requirements modeling activity for c/s systems differs little from the analysis
modeling methods applied to more conventional computer architectures
...
It should be
noted, however, that, because many modern c/s systems make use of reusable components, the qualiﬁcation activities associated with CBSE (Chapter 27) also apply
...
3 However, because an evolutionary
approach to software engineering is applied for c/s systems, implementation decisions on the overall c/s approach (e
...
, fat client vs
...

28
...
In
essence, the design should be customized to accommodate the hardware architecture
...
1
...

756

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

When software is designed for implementation using client/server architecture,
the design approach must be “customized” to accommodate the following issues:
•

Data and architectural design (Chapter 14) dominate the design process
...

Although c/s software
is different, you can
use conventional or
OO design methods
with very few
modiﬁcations
...

•

The user interaction/presentation component of a c/s system implements all
functions that are typically associated with a graphical user interface
...

•

An object-oriented view of design (Chapter 22) is often chosen
...

Although debate continues on the best analysis and design approach for c/s systems,
object-oriented methods (Chapters 21 and 22) appear to have the best combination of
features
...

28
...
1 Architectural Design for Client/Server Systems
The architectural design of a client/server system is often characterized as a communicating processes style
...
A server exists to serve data to one or more
clients, which are typically located across a network
...
If the

XRef
A detailed discussion of
architecture is presented
in Chapter 14
...

If the server works asynchronously, it returns only data to the client (which has its own
thread of control)
...
3) is used to implement this synchronous or asynchronous communication
...
The use of IDL allows application software components to
access ORB services (components) without knowledge of their internal workings
...

CHAPTER 28

C L I E N T / S E RV E R S O F T WA R E E N G I N E E R I N G

757

The ORB also has the responsibility for coordinating communication among
components for both the client and server
...

•

All component (object) references are interpreted and reconciled
...

•

Objects are activated and deactivated
...

•

Security features are implemented
...
To
accomplish this CORBA uses a bridging concept
...
Both protocols are CORBA compliant,
but because of internal implementation differences, they must communicate to a
“bridge” that provides a mechanism for translation between internal protocols
[BAS98]
...

28
...
2 Conventional Design Approaches for Application Software
In client/server systems, the data ﬂow diagram (Chapters 12 and 14) can be used to
establish the scope of a system, identify the high-level functions and subject data
areas (data stores), and permit the decomposition of the high-level functions
...

In the c/s context, an elementary business process (EBP) can be deﬁned as a set of
tasks performed without a break by one user at a client site
...

The entity relationship diagram also assumes an expanded role
...

Its new role is to provide the structure for defining high-level business objects
(Section 28
...
3)
...
These components, consisting of interface objects,
application objects, and database objects, establish how the data are to be processed
...
4
...
The analysis required to identify business objects is
accomplished using business process engineering methods discussed in Chapter 10
...

In this repository, a business object is deﬁned as information that is visible to the
purchasers and users of the system, not its implementers
...
The
following design information is collected for the client/server database [POR94]:
•

Entities are identiﬁed within the ERD for the new system
...

•

“The organization of
data in a database
has to represent the
underlying meaning
or semantics of the
data correctly and
efﬁciently
...

•

Fields deﬁne the ﬁelds in the design (the data dictionary)
...

•

Relationship validation identiﬁes the type of ﬁle-to-ﬁle or ﬁle-to-ﬁeld relationships used for validation
...
g
...

•

Data type speciﬁes the characteristics of the data contained in a ﬁeld
...

•

Field functions include key, foreign key, attribute, virtual ﬁeld, derived ﬁeld,
and the like
...

•

Business rules are the rules for editing, calculating derived ﬁelds, and so on
...
In c/s systems that implement this approach, the
data management component resides on both the client and the server
...
That is, how are data distributed between the client and server and dispersed across the nodes of a network?

CHAPTER 28

C L I E N T / S E RV E R S O F T WA R E E N G I N E E R I N G

759

A relational database system enables easy access to distributed data through the
use of structured query language
...
In an RDBMS, the type of data is speciﬁed using SQL,
but no navigational information is required
...
In less sophisticated database systems, a request
for data must indicate what is to be accessed and where it is
...

It should be noted that other data distribution and management techniques are
also available to the designer [BER92]:

? What
options
exist for
distributing data
within a c/s
system?

Manual extract
...
This approach is useful when static data are required by a
user and the control of the extract can be left in the user’s hands
...
This technique automates the manual extract by specifying a
“snapshot” of data that should be transferred from a server to a client at predeﬁned intervals
...

Replication
...
g
...

Here, the level of complexity escalates because data consistency, updates,
security, and processing must all be coordinated at multiple sites
...
In this approach, the system database is fragmented across
multiple machines
...

Database design and, more speciﬁcally, database design for c/s systems are topics that are beyond the scope of this book
...

28
...
4 An Overview of a Design Approach
Porter [POR95] suggests a set of steps for designing an elementary business process
that combines elements of conventional design with elements of object-oriented
design
...
The following steps are then used to derive the design:
1
...

2
...

760
F I G U R E 28
...
For each component, retrieve the business rules and other business object
information that has been established for the relevant ﬁle
...
Determine which rules are relevant to the process, and decompose the rules
down to a method level
...
As required, deﬁne any additional components that are needed to implement
the methods
...
4) for representing
the component structure of an elementary business process
...
Referring to the ﬁgure, ﬁve different symbols are encountered:
Interface object
...
It includes methods for
formatting the GUI interface and client-resident related application logic
...
If application logic normally
associated with an interface object is implemented on a server instead, typically through the use of the middleware tools, the application logic operating
on the server should be identiﬁed as a separate application object
...
This type of component is used to identify database processing such as record creation or selection based on a ﬁle other than the primary ﬁle over which an interface object is built
...
For example, the second ﬁle processing technique should be identiﬁed separately on the structure chart as a separate database object
...
Used by either an interface object or a database object,
this component is invoked by either a database trigger or a remote procedure
call
...

CHAPTER 28

C L I E N T / S E RV E R S O F T WA R E E N G I N E E R I N G

761

Data couple
...
The data couple symbol is used to
denote this occurrence
...
When one object invokes another independent object and
no data are passed between the two objects, a control couple symbol is used
...
4
...
4
...
The following entities are
identiﬁed:
•

Methods describe how a business rule is to be implemented
...

•

Process/component link identiﬁes the components that make up the solution
for an elementary business process
...

•

Business rule/component link identiﬁes the components that are signiﬁcant to
the implementation of a given business rule
...

28
...
Binder [BIN92] suggests the following areas of focus:
•

Client GUI considerations
...

Useful c/s testing
information and resources
are presented at
www
...
net/
~djmosley/

•

Distributed database considerations (including replicated data)
...

•

Nonrobust target environment
...

The strategy and tactics associated with c/s testing must be designed in a manner
that allows each of these issues to be addressed
...
An updated an expanded discussion can be
found in [MOS99]
...
5
...

Although many different types of tests are conducted at each of these levels of
detail, the following testing approaches are commonly encountered for c/s applications:

? What types
of tests are

Application function tests
...

using the methods discussed in Chapter 17
...
The coordination and data management functions of the
server are tested
...

Database tests
...
Transactions posted by client applications are examined to ensure
that data are properly stored, updated, and retrieved
...

Transaction tests
...
Tests focus on the correctness of processing and also on performance issues (e
...
, transaction processing times and transaction volume)
...
These tests verify that communication
among the nodes of the network occurs correctly and that message passing,
transactions, and related network trafﬁc occur without error
...

XRef
Requirements elicitation
techniques and usecases are discussed in
Chapter 11
...
An operational proﬁle indicates how different types of users interoperate with the c/s system
...
For example, for a particular type of user, what percentage
of transactions will be inquiries? updates? orders?
To develop the operational proﬁle, it is necessary to derive a set of user scenarios
[BIN95] that are similar to use-cases discussed earlier in this book
...
That is, who the user is, where (in the physical c/s architecture) the system interaction occurs, what the transaction is, and why
it has occurred
...
The result, however, should be

CHAPTER 28

C L I E N T / S E RV E R S O F T WA R E E N G I N E E R I N G

763

the same
...
These data are then combined (for all users) to create the operational proﬁle
...
”
Kelley Bourne

software-based systems described in Chapter 18
...
That is, a single client application is tested
...
Finally, the entire system is tested as an
operational entity
...
Module integration in
c/s development may have some top-down or bottom-up aspects, but integration in
c/s projects tends more toward parallel development and integration of modules
across all design levels
...

The fact that the system is not being built to use prespeciﬁed hardware and software affects system testing
...

Conﬁguration testing doctrine forces testing of the system in all of the known hardware and software environments in which it will operate
...
For example, a Windows-type interface may be visually different depending on the implementation environment, but the same basic user behaviors should produce the same
results regardless of the client interface standard
...
5
...
Once test cases have been derived for a class of objects (or their equivalent in a conventionally developed system), those test cases should be broadly applicable for all instances of the class
...
The GUI is inherently object oriented and departs
from traditional interfaces because it must operate on many platforms
...
Testing is further complicated
because the objects can be present or absent, they may exist for a length of time, and
they can appear anywhere on the desktop
...
A functional variation of the capture/playback
paradigm called structured capture/playback [FAR93] has evolved for GUI testing
...
Structured capture/playback is based on an internal (logical) view of
external activities
...

Tools that exercise GUIs do not address traditional data validation or path testing
needs
...

28
...
In general, the software process model applied for c/s systems is evolutionary in nature and the technical methods often gravitate toward
object-oriented or component-based approaches
...
The components (objects) deﬁned for these subsystems must
be allocated to either the client or server machines and can be linked via an object
request broker
...
The CORBA standard makes use of interface deﬁnition language, and interface repositories manage requests for objects regardless of
their location on the network
...
Testing strategies must be
modiﬁed to accommodate tests that examine network communication and the interplay between software that resides on client and server
...
, P
...
Kazman, Software Architecture in Practice,
Addison-Wesley, 1998
...

CHAPTER 28

[BIN92]

C L I E N T / S E RV E R S O F T WA R E E N G I N E E R I N G

765

Binder, R
...

[BIN95]

Binder, R
...
3, no
...
43–49
...
W
...

[FAR93] Farley, K
...
, “Software Testing for Windows Developers,” Data Based Advisor, November 1993, pp
...

[HOQ99] Hoque, R
...

[ORF99] Orfali, R
...
Harkey, and J
...
, Wiley, 1999
...
, Client Server Software Testing on the Desk Top and the Web,
Prentice-Hall, 1999
...
, “Operational Profiles in Software Reliability Engineering,” IEEE
Software, March 1993, pp
...

[PAU95] L
...
Paul, “Client/Server Deployment,” Computerworld, December 18, 1995
...
, O-DES Design Manual, Fairﬁeld University, 1994
...
, Synon Developer's Guide, McGraw-Hill, 1995
...
, CORBA 3 Fundamentals and Programming, Wiley, 1999
...
, Client/Server Strategies, IDG Books, 1993
...
1
...

28
...
Suggest ﬁve applications in which a fat server would seem to be an appropriate design strategy
...
3
...

28
...
Do some additional research on the CORBA standard and determine how the
latest release of the standard addresses interoperability among different ORBs provided by different vendors
...
5
...

28
...
Research the latest advances in groupware and develop a brief presentation
for your class
...

28
...
A company is establishing a new e-commerce division to sell casual apparel
and outdoor merchandise
...
A

766

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

client/server system will be built to support order processing at the company site
...

28
...
Deﬁne business rules to establish when a shipment can be made if payment
is by credit card for the system described in Problem 28
...
Add additional rules if payment is by check
...
9
...
7)
...
10
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
Although software engineering methods for client/server systems are quite similar
to conventional and OO systems, specialized knowledge and techniques are required
...
, IDG Books Worldwide, 1999) and
Zantinge and Adriaans (Managing Client/Server, Addison-Wesley, 1997)
...
On a more sophisticated level, Orfali
and his colleagues [ORF99] and Linthicum (Guide to Client/Server and Intranet Development, Wiley, 1997) provide detailed guidelines for engineering c/s applications
...
, McGraw-Hill, 1996) discusses component
and architecture issues
...
Sinclair and Merkow (Thin Clients Clearly Explained, Morgan
Kaufmann, 1999), Friedrichs and Jubin (Java Thin-Client Programming for a Network
Computing Environment, Prentice-Hall, 1999), Dewire (Thin Clients, McGraw-Hill, 1998),
and Kanter (Understanding Thin-Client/Server Computing, Microsoft Press, 1998) provide worthwhile guidance on how to design, build, deploy, and support thin-client
systems
...
Books by Goldman,
Rawles, and Mariga (Client/Server Information Systems: A Business-Oriented Approach,
Wiley, 1999); Shan, Earle, and Lenzi (Enterprise Computing with Objects: From
Client/Server Environments to the Internet, Addison-Wesley, 1997); and Gold-Bernstein

CHAPTER 28

C L I E N T / S E RV E R S O F T WA R E E N G I N E E R I N G

767

and Marca (Designing Enterprise Client/Server Systems, Prentice-Hall, 1997) consider
c/s in a broader enterprise context
...
Heinckiens and Loomis (Building Scalable Database Applications: Object-Oriented Design, Architectures, and Implementations, Addison-Wesley,
1998) emphasize database design in their guide for building client/server applications
...
Schneberger
(Client/Server Software Maintenance, McGraw-Hill, 1997) presents a framework for
controlling c/s software maintenance costs and optimizing user support
...
The following represents a small sampling:
Anderson, G
...
, Client/Server Database Design with Sybase: A High-Performance and FineTuning Guide, McGraw-Hill, 1997
...
J
...

Bates, R
...
, Hands-on Client/Server Internetworking, McGraw-Hill, 1997
...
H
...

Orfali, R
...
Harkey, Client/Server Programming with JavaBeans, Wiley, 1999
...
, Building Internet Client/Server Systems, McGraw-Hill, 1999
...
Both authors provide indepth discussion of testing strategies, tactics, and tools
...
An up-to-date list of World Wide Web references that are
relevant to c/s systems can be found at the SEPA Web site:
http://www
...
com/engcs/compsci/pressman/resources/
client-server
...
778
architectural
design
...
783
formulation
...
785
navigation
design
...
787
quality
attributes
...
780
testing
...
771
WebApp
categories
...
774

WEB ENGINEERING

he World Wide Web and the Internet have drawn the general populace
into the world of computing
...
Arguably, the Web and the Internet that empowers it are
the most important developments in the history of computing
...
They have become integral to daily life in the ﬁrst
years of the twenty-ﬁrst century
...
It was a time of little discipline, but enormous enthusiasm and creativity
...
The prevailing attitude seemed to be “Get it done fast, and get
it into the ﬁeld, we’ll clean it up (and better understand what we really need to
build) as we go
...
788

QUICK
LOOK

What is it? Web-based systems
and applications (WebApps)

Who does it? Web engineers and nontechnical content developers create the WebApp
...
Web engineering is the process used

and large companies (e
...
, e-commerce), the

to create high-quality WebApps
...
That’s why a dis-

but it borrows many of software engineering’s

ciplined approach to WebApp development is

fundamental concepts and principles, empha-

necessary
...
There are subtle differences in the way

Web engineering applies a generic approach that

these activities are conducted, but an overriding

is tempered with specialized strategies, tactics, and

philosophy that dictates a disciplined approach

methods
...

the WebApp
...
Architectural, naviga-

design models, test procedures) are produced
...

tional, and interface design are

How do I ensure that I’ve done it right? Use the same

conducted
...
Because WebApps

assess the analysis and design models, special-

evolve continuously, mechanisms for conﬁgura-

ized reviews consider usability; testing is applied

tion control, quality assurance, and ongoing sup-

to uncover errors in content, functionality, and

port are needed
...

What is the work product? A variety of Web engineering work products (e
...
, analysis models,

It seems to me that just about any important product or system is worth engineering
...
You should probably also control changes to
it as you work and have some mechanism for ensuring the end result’s quality
...

“The engineering
principles of
planning before
designing and
designing before
building have
withstood every
prior technology
transition; they’ll
survive this
transition as well
...

But what if the current ad hoc approach to Web development persists? In the
absence of a disciplined process for developing Web-based systems, there is increasing concern that we may face serious problems in the successful development, deployment, and “maintenance” of these systems
...
This phrase connotes a morass of poorly
developed Web-based applications that have too high a probability of failure
...
When this happens, confidence in the entire
Internet may be shaken irreparably
...

In order to avoid a tangled Web and achieve greater success in development and
application of large-scale, complex Web-based systems, there is a pressing need for
disciplined Web engineering approaches and new methods and tools for development, deployment, and evaluation of Web-based systems and applications
...

Web Engineering (WebE) is concerned with the establishment and use of sound
scientiﬁc, engineering, and management principles and disciplined and systematic

CHAPTER 29

WEB ENGINEERING

771

approaches to the successful development, deployment, and maintenance of highquality Web-based systems and applications [MUR99]
...
1

T H E AT T R I B U T E S O F W E B - B A S E D A P P L I C AT I O N S
There is little debate that Web-based systems and applications1(we will refer to these
collectively as WebApps) are different than the many other categories of computer
software discussed in Chapter 1
...
The
following attributes are encountered in the vast majority of WebApps:2
Network intensive
...
It resides
on a network and must serve the needs of a diverse community of clients
...
Alternatively, an application may be placed on an intranet
(implementing communication across an organization) or an Extranet (internetwork communication)
...
In many cases, the primary function of a WebApp is to use

WebApps are network
intensive, content
driven, and
continuously evolving
...

hypermedia to present text, graphics, audio, and video content to the enduser
...
Unlike conventional application software that
evolves over a series of planned, chronologically spaced releases, Web applications evolve continuously
...

Some argue that the continuous evolution of WebApps makes the work performed
on them analogous to gardening
...
Web site
development is often much more about creating an infrastructure (laying out the garden)
and then "tending" the information which grows and blooms within this garden
...
e
...
A good initial architecture should allow this growth to occur in a controlled and consistent manner
...
e
...

In the context of this chapter, the term Web application encompasses everything from a simple
Web page that might help a consumer compute an automobile lease payment to a comprehensive Web site that provides complete travel services for business people and vacationers
...
We could have "garden nurseries"
where young plants (i
...
, design patterns for Web sites) are "grown
...
But, unlike a garden, Web applications must serve (and adapt to) the needs
of more than the gardener
...
Web-based applications have an immediacy [NOR99] that is not
found in any other type of software
...

Quick and wrong are
rarely an acceptable
result
...
3 Developers must use
methods for planning, analysis, design, implementation, and testing that
have been adapted to the compressed time schedules required for WebApp
development
...
Because WebApps are available via network access, it is difﬁcult, if
not impossible, to limit the population of end-users who may access the application
...

Aesthetics
...
When an application has been designed to market or sell products or
ideas, aesthetics may have as much to do with success as technical design
...
The following application categories are most commonly encountered in
WebE work [DAR99]:
•
•

Customizable
...

•

WebApps?

Download
...

•

? How can we
categorize

Informational
...

Interaction
...

•

User input
...

•

Transaction oriented
...
g
...

•

Service oriented
...
g
...

•

Portal
...

3

Reasonably sophisticated Web pages can be produced in only a few hours
...
The user queries a large database and extracts information
...
The user queries a collection of large databases and
extracts information
...
The key is living within the constraints
imposed by the characteristics and still producing a successful WebApp
...
1
...
Individual viewpoints vary widely
...
Some demand copious information,
others desire an abbreviated presentation
...

But how is WebApp quality perceived? What attributes must be exhibited to achieve
goodness in the eyes of end-users and at the same time exhibit the technical characteristics of quality that will enable a Web engineer to correct, adapt, enhance, and
support the application over the long term?
In reality, all of the general characteristics of software quality discussed in Chapters 8, 19, and 24 apply to WebApps
...

Olsina and his colleagues [OLS99] has prepared a “quality requirement tree” that
identiﬁes a set of attributes that lead to high-quality WebApps
...
1 summaDetailed quality
requirement tree for
WebApps

rizes their work
...
1
...
A Web engineer must be familiar with all three in order to build
high-quality WebApps
...
Recalling our discussion from the preceding chapters, three major infrastructure standards
are available for Web engineers: CORBA, COM/DCOM, and JavaBeans
...

774

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

F I G U R E 29
...
In some cases,

“The Internet is a
risky place to
conduct business or
store assets
...
”
Dorothy Denning
and Peter Denning

unauthorized access may be attempted by internal personnel
...
A
variety of security measures are provided by the network infrastructure, encryption
techniques, ﬁrewalls, and other measures
...
For more information, the interested reader
should see [ATK97], [KAE99], and [BRE99]
...
However, as the size and complexity of applications grow, a new standard—XML— has been adopted for the next generation of
WebApps
...
Using an XML meta-language description, the meaning of the custom
tags is deﬁned in the information transmitted to the client site
...

29
...
Immediacy and continuous evolution dictate an iter-

CHAPTER 29

775

WEB ENGINEERING

ative, incremental process model (Chapter 2) that produces WebApp releases in
rapid fire sequence
...

on requirements elicitation and modeling) and an application architecture that
can be highly specialized (thereby making demands on design)
...
g
...

29
...
To accomplish this, it is necessary to
develop a WebE framework that encompasses an effective process model, populated
by framework activities4 and engineering tasks
...
2
...
2 The WebE process model

4

Recalling the discussion of process models in Chapter 2, framework activities are performed for
all WebApps, while engineering tasks are adapted to the size and complexity of the WebApp to be
developed
...
Planning estimates overall project cost, evaluates risks associated with the development
effort, and deﬁnes a ﬁnely granulated development schedule for the initial WebApp
increment, with a more coarsely granulated schedule for subsequent increments
...
Requirements for graphic design (aesthetics) are
also deﬁned
...
2
...
The intent of these tasks is to design, produce, and/or

W3C, an industry
consortium that provides
access to WWW
information of interest to
Web engineers can be
accessed at
www
...
org

acquire all text, graphics, audio, and video content that are to become integrated into
the WebApp
...
5) are conducted
...
The content deﬁned in the engineering activity is merged with
the architectural, navigation, and interface designs to produce executable Web pages
in HTML, XML, and other process-oriented languages (e
...
, Java)
...
e
...
Testing exercises WebApp navigation; attempts to uncover errors in
applets, scripts, and forms; and helps ensure that the WebApp will operate correctly
in different environments (e
...
, with different browsers)
...
This is the point at which changes are requested (scope extensions occur)
...

29
...
Formulation allows the customer and the developer to establish a common set of goals and objectives for the construction of the
WebApp
...
Analysis is a technical activity that identiﬁes
the data, functional, and behavioral requirements for the WebApp
...
4
...
For example, assume that the manufacturer of home security systems has
decided to establish an e-commerce Web site to sell its products directly to consumers
...
com5 will allow consumers to conﬁgure and purchase all components required
to install a home/business security system
...
The objective is to
bound the overall intent of the site
...
, an answer to
the second question is stated:
SafeHomeInc
...
It will also allow us to increase sales by a projected
25 percent over current annual sales and will allow us to penetrate geographic regions
where we currently do not have sales outlets
...
com are homeowners and owners of small businesses
...
com Web site
...

Informational goals
...

•

Applicative goals
...

In the content of the SafeHomeInc
...

Examination of the answers to the questions just posed might lead to the statement
of an applicative goal:
SafeHomeInc
...
e
...

Once all informational and applicative goals have been identified, a user profile is
developed
...

778

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

including their background, knowledge, preferences and even more” [GNA99]
...
com, a user proﬁle would identify the characteristics of a typical purchaser of security systems (this information would be supplied by the SafeHome Inc
...

Once goals and user proﬁles have been developed, the formulation activity focuses
on a statement of scope (Chapter 5) for the WebApp
...
In addition, however, it is useful
to indicate the degree of integration to be expected of the WebApp
...
g
...
Connectivity issues are considered at this stage
...
4
...
Scope deﬁned
during the formulation activity is elaborated to create a complete analysis model for
the WebApp
...
The full spectrum of content to be provided by the

“Successful
knowledge products
[WebApps] allow
customers to meet
their needs better,
faster, or cheaper
themselves, rather
than working
through employee
end-users
...
”
Mark McDonald

WebApp is identiﬁed
...
Data modeling (Chapter 12) can be used to identify and describe
each of the data objects to be used within the WebApp
...
The manner in which the user interacts with the
WebApp is described in detail
...

Functional analysis
...
All operations and functions
are described in detail
...
The environment and infrastructure in which the
WebApp resides are described in detail
...
In addition, the infrastructure (i
...
, the component infrastructure and the degree to which a database will be used to
generate content) for the WebApp should be identiﬁed at this stage
...
It can be argued that the continuous evolution of WebApp requirements may make obsolete any document before it is ﬁnished
...
At a minimum, the
information collected during the preceding four analysis tasks should be reviewed,
modified as required, and then organized into a document that can be passed to
WebApp designers
...
5

WEB ENGINEERING

779

D E S I G N F O R W E B - B A S E D A P P L I C AT I O N S
The immediate nature of Web-based applications coupled with the pressure for con-

WebRef
A worthwhile source of
practical guidelines for
Web site design can be
found at
www
...
com/ibm
/easy/design/
lower/f060100
...
The problem, of course, is that solving the immediate problem (quickly) can result in compromises that affect the ability of the application to evolve over time
...

In order to perform Web-based design effectively, a Web engineer should work to
reuse four technical elements [NAN98]:
Design principles and methods
...
Effective modularity (exhibited by high cohesion and low coupling), information
hiding, stepwise elaboration, and other software design heuristics lead to
Web-based systems and applications that are easier to adapt, enhance, test,

“To some, Web design
focuses on visual
look and feel
...

Others might even
consider Web design
to be about the
technology used to
build interactive Web
applications
...
”
Thomas Powell

and use
...
Hypermedia deﬁnes
“objects” that interact via a communication protocol that is loosely analogous to messaging
...

In addition, a variety of hypermedia design methods have been proposed
(e
...
, [ISA95], [SCH96])
...
Interactive hypermedia applications (WebApps) have been
constructed for more than a decade
...

Design patterns
...
In the context of WebApps, design
patterns can be applied not only to the functional elements of an application,
but to documents, graphics, and general aesthetics for a Web site
...
A template can be used to provide a skeletal framework for any
design pattern or document that is to be used within a WebApp
...
The use of constructive templates implicitly relies on the separation of hypermedia document contents from
the speciﬁcation of its presentation: source data are mapped into the hypertext
structure as speciﬁed in the template
...
3
Linear
structures

Linear

Linear
with
optional flow

Linear
with
diversions

Each of the four reusable design elements is discussed in greater detail in the sections that follow
...

Avoid this trap
...

29
...
1 Architectural Design
Architectural design for Web-based systems and applications focuses on the deﬁnition of the overall hypermedia structure of the WebApp and the application of design
patterns and constructive templates to populate the structure (and achieve reuse)
...

WebApp Structures
Overall architectural structure is tied to the goals established for a WebApp, the content to be presented, the users who will visit, and the navigation philosophy (Section
29
...
3) that has been established
...

? What
structural
options are
available for
WebApp design?

Linear structures (Figure 29
...
A classic example might
be a tutorial presentation in which pages of information along with related graphics,
short videos, or audio are presented only after prerequisite information has been pre-

6

Content design is a nontechnical activity that is performed by copywriters, artists, graphic designers, and others who generate Web-based content
...

CHAPTER 29

WEB ENGINEERING

781

F I G U R E 29
...
The sequence of content presentation is predefined and generally linear
...
In such cases, the structures shown in
Figure 29
...
As content and processing become more complex, the
purely linear ﬂow shown on the left of the ﬁgure gives way to more sophisticated linear structures in which alternative content may be invoked or a diversion to acquire
complementary content (structure shown on the right side of Figure 29
...

Grid structures work
well when content can
be organized
categorically in two or
more dimensions
...
4) are an architectural option that can be applied when
WebApp content can be organized categorically in two (or more) dimensions
...
The horizontal dimension of the grid represents the type of club to be sold (e
...
, woods, irons,
wedges, putters)
...
Hence, a user might navigate the grid horizontally to
ﬁnd the putters column and then vertically to examine the offerings provided by those
manufacturers that sell putters
...
On one
hand, it facilitates
navigation
...
” Don’t
overdo horizontal
connections within a
hierarchy
...

Hierarchical structures (Figure 29
...
Unlike the partitioned software hierarchies discussed in Chapter 14
which encourage flow of control only along vertical branches of the hierarchy, a
WebApp hierarchical structure can be designed in a manner that enables (via hypertext branching) ﬂow of control horizontally, across vertical branches of the structure
...
It should be noted, however, that although such branching allows rapid
navigation across WebApp content, it can lead to confusion on the part of the user
...
5
Hierarchical
structures

A networked, or “pure Web,” structure (Figure 29
...
Architectural components (in
this case, Web pages) are designed so that they may pass control (via hypertext links)
to virtually every other component in the system
...

The architectural structures discussed in the preceding paragraphs can be combined to form composite structures
...
6
Networked, or
“pure Web,”
structure

CHAPTER 29

WEB ENGINEERING

783

another part of the architecture may be networked
...

Design Patterns
XRef
Further discussion of
design patterns may be
found in Chapters 14
and 22
...
In the context of Web-based systems and applications, design patterns can be
applied at the architectural level, the component-level, and at the hypertext (navigational) level
...
Hypertext-level design patterns focus on the design of navigation features
that allow a user to move through WebApp content in a facile manner
...
”
Christopher
Alexander

Cycle—a pattern that returns the user to a previously visited content node
...

•

Contour—a pattern that occurs when cycles impinge upon one another,
allowing navigation across paths deﬁned by the cycles
...

•

Mirrorworld—content is presented using different narrative threads, each
with a different point of view or perspective
...

•

Sieve—a pattern that guides a user through a series of options (decisions) in
order to direct the user to speciﬁc content indicated by the sequence of
options chosen or decisions made
...

These hypertext design patterns can be reused as content is translated into a format
that allows navigation through a WebApp
...
5
...
To accomplish this, the designer must (1) identify the
semantics of navigation for different users of the site and (2) deﬁne the mechanics
(syntax) of achieving the navigation
...
For example, roles
might be visitor, registered customer, or privileged user
...
A visitor may have
access to only limited content while a registered customer may have access to a much
broader range of information and services
...

The WebApp designer creates a semantic navigation unit (SNU) for each goal associated with each user role [GNA99]
...
A SNU is
created for each goal
...
The SNU
represents a speciﬁc
navigational goal for a
speciﬁc type of user
...
A WoN represents the best navigation way or path for users with
certain proﬁles to achieve their desired goal or sub-goal
...

The structure of a WoN is made out of a set of relevant navigational nodes (NN) connected by navigational links, including sometimes other SNUs
...

During the initial stages of navigation design, the WebApp structure (architecture and
components) is assessed to determine one or more WoN for each user goal
...
g
...
The WoN are then organized into SNUs
...
Among
many possible options are text-based links, icons, buttons and switches, and graphical metaphors
...

In addition to choosing the mechanics of navigation, the designer should also
establish appropriate navigation conventions and aids
...
Audio or visual feedback should be designed to provide the user
with an indication that a navigation option has been chosen
...
These are but a few of dozens of design conventions that
make navigation user-friendly
...

CHAPTER 29

WEB ENGINEERING

785

29
...
3 Interface Design
The interface design concepts, principles, and methods presented in Chapter 15 are
all applicable to the design of user interfaces for WebApps
...
”
Jakob Nielsen and
Annette Wagner

acteristics of Web-based systems and applications require a number of additional
considerations
...
” Regardless of the value of
its content, the sophistication of its processing capabilities and services, and the overall beneﬁt of the WebApp itself, a poorly designed interface will disappoint the potential user and may, in fact, cause the user to go elsewhere
...
Nielsen and Wagner [NIE96] suggest a few simple guidelines based on their redesign of a major WebApp:

are
? What basic
some
guidelines for the
design of a Web
site’s look and
feel?

•

Server errors, even minor ones, are likely to cause a user to leave the Web
site and look elsewhere for information or services
...
Therefore, do not force the user to read
voluminous amounts of text, particularly when the text explains the operation of the WebApp or assists in navigation
...

•

Users prefer not to scroll
...

•

be available on all pages that are available to the user
...
usability
...
htm

Navigation menus and headbars should be designed consistently and should
rely on browser functions to assist in navigation
...
For example, a simple button might be a better navigation option than an aesthetically pleasing, but
vague image or icon whose intent is unclear
...
The user
should not have to search the screen to determine how to link to other content or services
...
It need not be flashy, but it should always be well structured and ergonomically sound
...
Interested readers should see
[SAN96], [SPO98], [ROS98], or [LYN99] among hundreds of offerings for additional
guidance
...
6

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

T E S T I N G W E B - B A S E D A P P L I C AT I O N S
In Chapter 17, we noted that testing is the process of exercising software with the
intent of ﬁnding (and ultimately correcting) errors
...
In fact, because Web-based systems and applications reside
on a network and interoperate with many different operating systems, browsers,
hardware platforms, and communications protocols, the search for errors represents
a signiﬁcant challenge for Web engineers
...
The following steps summarize the approach:

? What steps
do we follow
to test a
WebApp?

1
...
This
“testing” activity is similar in many respects to copy editing a written document
...

2
...
Use-cases, derived as part of the analysis activity, allow a Web engineer to exercise each usage scenario against the architectural and navigation

“Innovation is a
bittersweet deal for
software testers
...
”
James Bach

design
...
g
...
In addition,
the navigation links (Section 29
...
2) are reviewed to ensure that they correspond with those speciﬁed in each SNU for each user role
...
Selected processing components and Web pages are unit tested
...
Each Web
page encapsulates content, navigation links, and processing elements
(forms, scripts, applets)
...
In many cases, the smallest testable unit is
the Web page
...

4
...

The strategy for integration testing depends on the architecture that has been

XRef
Integration strategies
are discussed in
Chapters 18 and 23
...
If the WebApp has been designed with a linear, grid,
or simple hierarchical structure, it is possible to integrate Web pages in much
the same way as we integrate modules for conventional software
...
Thread-based testing (Chapter 23) can be used to integrate the set of Web pages (a SNU may be used to
deﬁne the appropriate set) required to respond to a user event
...
Regression testing is applied to ensure that
no side effects occur
...
Test cases are derived
to uncover errors in the collaborations
...
The assembled WebApp is tested for overall functionality and content delivery
...
To assist in the derivation of validation tests, the
tester should draw upon use-cases
...

6
...
A cross-reference matrix that deﬁnes all probable operating systems,
browsers,7 hardware platforms, and communications protocols is created
...

7
...
A population of users that encompasses every possible user role is
chosen
...

Because many WebApps evolve continuously, the testing process is an ongoing activity, conducted by Web support staff who use regression tests derived from the tests
developed when the WebApp was ﬁrst engineered
...
7

MANAGEMENT ISSUES
Given the immediacy of WebApps, it is reasonable to ask: “Do we really need to spend
time managing a WebApp effort? Shouldn’t we just let a WebApp evolve naturally,
with little or no explicit management?” More than a few Web developers would opt
for little or no management, but that doesn’t make them right!
Web engineering is a complicated technical activity
...

often working in parallel
...
In order to avoid confusion, frustration,
and failure, planning must occur, risks must be considered, a schedule must be established and tracked, and controls must be deﬁned
...

7

Browsers are notorious for implementing their own subtly different “standard” interpretations of
HTML and Javascript
...
browsercaps
...

788

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

29
...
1 The WebE Team
The creation of a successful Web application demands a broad array of skills
...
”
Scott Tilly and
Shihoug Huang

aspects to [Web] application software that there is a (re)emergence of the renaissance person, one who is comfortable operating in several disciplines
...

WebE teams can be organized in much the same way as the software teams discussed in Chapter 3
...

Among the many skills that must be distributed across WebE team members are component-based software engineering, networking, architectural and navigational design,
Internet standards/languages, human interface design, graphic design, content layout, and WebApp testing
...
Because WebApps are inherently con-

? What roles
do people

tent driven, one WebE team member role must focus on the generation or

play on a WebE
team?

collection of content
...
For example, marketing or sales staff may provide product information and graphical images, media producers may provide video
and audio, graphic designers may provide layout design and aesthetic content, copywriters may provide text-based content
...

Web publisher
...
In addition,
someone must act as liaison between technical staff that engineers the
WebApp and nontechnical content developers and providers
...

Web engineer
...
The Web engineer should also have a solid
understanding of component technologies, client/server architectures,
HTML/XML, and database technologies as well as a working knowledge of

8

These roles have been adapted from Hansen, Deshpande, and Murgusan [HAN99]
...

Support specialist
...
Because WebApps continuously evolve, the support specialist is responsible for corrections, adaptations, and enhancements to the site, including updates to content,
implementation of new procedures and forms, and changes to the navigation
pattern
...
Often called the Web master, this person has responsibility
for the day-to-day operation of the WebApp, including
•

Development and implementation of policies for the operation of the
WebApp
...

•

Implementation of security procedures and access rights
...

•

Coordination of change control procedures (Section 29
...
3)
...

The administrator may also be involved in the technical activities performed
by Web engineers and support specialists
...
7
...
9 Process and project metrics, project planning (and estimation), risk analysis and management, scheduling and tracking, SQA and SCM were
all considered in some detail
...
But in practice,
the WebE approach to project management is considerably different
...
In
such cases, a business (the customer) asks for a ﬁxed price quote for WebApp development from two or more vendors, evaluates competing quotes, and then selects a
vendor to do the work
...

10 Although reliable industry data are difﬁcult to ﬁnd, it is safe to say that this percentage is considerably higher than the one encountered in conventional software work
...
To date, virtually no WebE metrics have been
published in the literature
...
Therefore, estimation is purely qualitative—based on past
experience with similar projects
...
Hence, experiential estimation, although useful, is open to considerable error
...
And yet, the “continuous evolution” characteristic discussed
in Section 29
...
How can the contracting
organization and the outsourcing vendor control costs and schedule when requirements are likely to change dramatically as a project progresses? How can scope creep
be controlled, and more important, should it be controlled, given the unique nature
of Web-based systems and applications?
At this stage in the history of project management for WebApps, the questions precipitated by the differences just noted are not easy to answer
...

Initiating a project
...
State your quality
requirements
quantitatively
...
Get contractual
guarantees
...
Use proven track
record suppliers
...
Build and expand
the system in
evolutionary stages
...
Consider
appropriate
systematic
redundancy at many
levels to allow some
degree of operation
when failures
occur
...
Many of the analysis activities discussed in Section 29
...
The audience for the WebApp is identiﬁed; internal stakeholders
who may have interest in the WebApp are listed; the overall goals for the
WebApp are deﬁned and reviewed; the information and services to be delivered by the WebApp are speciﬁed; competing Web sites are noted; and qualitative and quantitative “measures” of a successful WebApp are deﬁned
...

2
...
Obviously, an
expert Web developer will create a complete design, but time and cost can be
saved if the general look and feel of the WebApp is identiﬁed for the outsourcing vendor (this can always be modiﬁed during preliminary stages of the
project)
...
g
...
This information should be
added to the product speciﬁcation
...
A rough project schedule, including not only ﬁnal delivery dates but also milestone dates, should be developed
...

CHAPTER 29

WEB ENGINEERING

791

4
...
This should include the naming of a vendor liaison and the identiﬁcation of the liaison’s responsibilities and authority, the deﬁnition of quality
review points as development proceeds, and the vendor’s responsibilities
with respect to interorganizational communication
...
11
Selection of candidate outsourcing vendors
...
Many have become adept at the WebE process, but many

“If you’re only willing
to pay peanuts, you
get monkeys
...
In order to select candidate Web developers, the
contractor must perform due diligence: (1) interview past clients to determine the
Web vendor’s professionalism, ability to meet schedule and cost commitments, and
ability to communicate effectively; (2) determine the name of the vendor’s chief Web
engineer(s) for successful past projects (and, later, be certain that this person is contractually obligated to be involved in your project); and (3) carefully examine samples of the vendor’s work that are similar in look and feel (and business area) to the
WebApp that is to be contracted
...

Assessing the validity of price quotes and the reliability of estimates
...
For this reason, some vendors will embed substantial
safety margins into the cost quoted for a project
...
The question is not “Have we gotten the best bang for our buck?” Rather,
the questions should be
•

Does the quoted cost of the WebApp provide a direct or indirect return on
investment that justiﬁes the project?

•

Does the vendor that has provided the quote exhibit the professionalism and
experience we require?

If the answers to these questions are, “Yes,” the price quote is fair
...
The formality associated with project management tasks (performed by both the vendor and the
contractor) is directly proportional to the size, cost, and complexity of the WebApp
...

792

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

checkpoints, engineering work products, customer review points, and major milestones should be developed
...
Mechanisms for quality assurance and change control should be explicitly deﬁned in writing
...

Assessing the development schedule
...
That is, work tasks and
minor milestones should be scheduled on a daily timeline
...

Managing scope
...

This allows the development team to “freeze” the scope for one increment so that an
operational WebApp release can be created
...
This approach enables the
WebApp team to work without having to accommodate a continual stream of changes
but still recognizes the continuous evolution characteristic of most WebApps
...
However, they will help both the contractor and the
vendor initiate work smoothly with a minimum of misunderstandings
...
7
...
As WebApps become increasingly important to business survival and growth, the need for conﬁguration control

“The most effective
way to cope with
change is to help
create it
...
W
...
Why? Because, without effective controls, improper changes to a WebApp
(recall that immediacy and continuous evolution are the dominant attributes of many
WebApps) can lead to (1) unauthorized posting of new product information, (2) erroneous or poorly tested functionality that frustrates visitors to a Web site, (3) security
holes that jeopardize internal company systems, and other economically unpleasant
or even disastrous consequences
...
Four issues [DAR99] should be considered when developing tactics for WebApp conﬁguration management—content, people, scalability,
and politics
...
A typical WebApp contains a vast array of content—text, graphics,
applets, scripts, audio and video ﬁles, forms, active page elements, tables,
streaming data, and many others
...

One approach is to model the WebApp content using conventional data modeling techniques (Chapter 11), attaching a set of specialized properties to
each object
...
g
...
For
example, if a content item is changed hourly, it has temporary longevity
...

People
...
Many content creators have no

Controlling change
during WebE projects is
essential, but it can be
overdone
...
Your initial goal
should be to avoid the
ratcheting effects of
uncontrolled change
...
The application grows and changes in an
uncontrolled fashion
...
The techniques and controls applied to small WebApps do not
scale upward well
...
As size and complexity
grows, small changes can have far-reaching and unintended effects that can
be problematic
...

Politics
...
In some instances Web developers are housed outside the IT organization, creating potential communication difﬁculties
...

Conﬁguration management for WebE is in its infancy
...
The vast majority of SCM tools lack the features that allow

794

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

them to be adapted easily to WebE
...

29
...
As WebApps grow in importance, a disciplined Web engineering approach—based on the principles, concepts, process, and
methods that have been developed for software engineering—has begun to evolve
...
They are network intensive, content driven, and continuously evolving
...
Three technologies—component-based development, security, and
Internet standard markup languages—are integrated with more conventional software engineering technologies during WebApp development
...
Planning estimates overall project cost, evaluates risks associated with the development effort, and deﬁnes a development schedule
...
The engineering activity incorporates two
parallel tasks: content design and technical design
...
Web
engineering makes use of an iterative, incremental process model because the development timeline for WebApps is very short
...

REFERENCES
[ATK97] Atkins, D
...
, Internet Security: Professional Reference, New Riders Publishing, 2nd ed
...

[BER98] Bernstein, M
...
9th ACM Conf
...
21–29
...
, The Concise SGML Companion, Addison-Wesley, 1997
...
, Mastering Network Security, Sybex, 1999
...
, et al
...

[DAR99] Dart, S
...
First ICSE Workshop on Web Engineering, ACM, Los Angeles, May 1999
...
macarthur
...
edu
...
htm)
...
, M
...
Stiles, Elements of Web Design: The Designer's
Guide to a New Medium, 2nd ed
...

[GAM95] Gamma, E
...
, Design Patterns, Addison-Wesley, 1995
...
and F
...
First ICSE Workshop on Web Engineering, ACM, Los Angeles, May 1999
...
, Y
...
Murugesan, “A Skills Hierarchy for Web
Information System Development,” Proc
...

[ISA95]

Isakowitz, T
...
, “RMM: A Methodology for Structured Hypermedia

Design,” CACM, vol
...
, no
...
34–44
...
, Designing Network Security, Cisco Press, 1999
...
, “Web Engineering or Web Gardening?” WebNet Journal, vol
...

2, January–March 1999
...
J
...
Horton, Web Style Guide: Basic Design Principles for Creating Web Sites, Yale University Press, 1999
...
, WebE home page,
http://ﬁstserv
...
uws
...
au/san/WebEHome, July 1999
...
and P
...
Ninth ACM Conf
...
11–20
...
and A
...
CHI

'96 Conference on Human Factors in Computing Systems, ACM Press, 1996, pp
...

[NOR99] Norton, K
...
First ICSE Workshop on Web Engineering, ACM, Los Angeles, May
1999
...
, et al
...
First ICSE Workshop on Web Engineering, ACM, Los Angeles, May 1999
...
J
...

[POW98] Powell, T
...
, Web Site Engineering, Prentice-Hall, 1998
...
S
...
104–110
...
and P
...

[SAN96] Sano, D
...

[SCH96] Schwabe, D
...
Rossi, and S
...
Hypertext ‘96, pp
...

[SPO98] Spool, J
...
, et al
...

[STL99] St
...
and E
...

[TIL99]

Tilley, S
...
Huang, “On the Emergence of the Renaissance Software

Engineer,” Proc
...

PROBLEMS AND POINTS TO PONDER
29
...
Are there other generic attributes that differentiate WebApps for more conventional software applications? Try to name two or three
...
2
...

29
...
Do a bit of research and write a two- or three-page paper that summarizes
one of the three technologies noted in Section 29
...
2
...
4
...
”
29
...
Answer the three formulation questions for a Web site that you’re familiar
with
...

29
...
Develop a set of user proﬁles for SafeHomeInc
...

29
...
Develop a complete list of informational and applicative goals for SafeHomeInc
...

CHAPTER 29

WEB ENGINEERING

797

29
...
Produce a set of use-cases for SafeHomeInc
...

29
...
How does content analysis differ from interaction and functional analysis?
29
...
Conduct a content analysis for SafeHomeInc
...

29
...
Suggest three “golden rules” that would help guide the design of WebApps
...
12
...
13
...
What architectural structure did the site designers select?
29
...
Do a bit of research and write a two- or three-page paper that summarizes
current work in WebApp design patterns
...
15
...
com or a Web site assigned
by your instructor
...
16
...
com or a Web site assigned by your instructor
...
17
...

29
...
Describe how project management for Web-based systems and applications
differs from project management for conventional software
...
Lowe and Hall (Hypertext and the Web: An Engineering Approach, Wiley, 1999) and
Powell [POW98] provide reasonably complete coverage
...

In addition to [LYN99] and [DIN98], the following books provide useful guidance
for technical and nontechnical (content and aesthetic) aspects of WebApp design:
Baumgardt, M
...

Donnelly, D
...
, Cutting Edge Web Design: The Next Generation, Rockport Publishing, 1998
...
E
...

Niederst, J
...
Koman, Web Design in a Nutshell: A Desktop Quick Reference, O'Reilly and
Associates, 1998
...
, Designing Web Usability, New Riders Publishing, 2000
...
and R
...

Menasce and Almeida (Capacity Planning for Web Performance: Metrics, Models,
and Methods, Prentice-Hall, 1998) address the quantitative assessment of WebApp
performance
...
Net Books, 1999) provides
detailed guidance for those Web engineers who specialize in security issues
...
Mosley (Client Server Software Testing on the Desk Top and the Web, Prentice-Hall, 1999) has written one of the few books
that address testing issues associated with WebApps
...

A wide variety of information sources on Web engineering is available on the Internet
...
mhhe
...
mhtml

CHAPTER

30
KEY
CONCEPTS

REENGINEERING
n a seminal article written for the Harvard Business Review, Michael Hammer [HAM90] laid the foundation for a revolution in management thinking
about business processes and computing:

abstraction
level
...
801

It is time to stop paving the cow paths
...
802

icon and software, we should obliterate them and start over
...
811

our business processes in order to achieve dramatic improvements in their performance
...
807

neering strives to break away from the old rules about how we organize and con-

economics
...
814
inventory
analysis
...
813
reverse
engineering
...
804

QUICK
LOOK

Every company operates according to a great many unarticulated rules
...

Like all revolutions, Hammer’s call to arms resulted in both positive and negative changes
...
Others relied solely
on downsizing and outsourcing (instead of reengineering) to improve their bottom line
...

During this ﬁrst decade of the twenty-ﬁrst century, the hype associated with
reengineering has waned, but the process itself continues in companies large

What is it? Consider any tech-

ing companies)
...

you well
...
It breaks too often, takes longer to

world
...
What to do? If the prod-

changing at a pace that puts enormous compet-

uct is hardware, you’ll likely throw it away and

itive pressure on every commercial organization
...
But if it’s custom-built soft-

Both the business and the software that supports

ware, that option may not be available
...
You’ll create a product with

pace
...
That’s what

(BPR) deﬁnes business goals, identiﬁes and evalu-

we call reengineering
...
The software reengineering process

799

800

PA R T F I V E

QUICK
LOOK

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

encompasses inventory analysis,
document restructuring, reverse

process and/or the reengineered software that
supports it
...
The intent

same SQA practices that are applied in every

of these activities is to create versions of existing

software engineering process—formal technical

programs that exhibit higher quality and better

reviews assess the analysis and design models,

maintainability
...
g
...

interoperability
...
The nexus between business reengineering and software engineering lies
in a “system view
...
As
these rules change, software must also change
...
” As managers work to modify the rules to achieve greater effectiveness and competitiveness,
software must keep pace
...
1 But in many others, it means the modiﬁcation or rebuilding of
existing applications
...

30
...
Among the many definitions (most some-

“To face tomorrow
with the thought of
using the methods
of yesterday is to
envision life at a
standstill
...
” But how is the search conducted, and how
is the implementation achieved? More important, how can we ensure that the “radical change” suggested will in fact lead to “breakthrough results” instead of organizational chaos?

30
...
1 Business Processes
A business process is “a set of logically related tasks performed to achieve a deﬁned
business outcome” [DAV90]
...

CHAPTER 30

REENGINEERING

801

rial resources, and business procedures are combined to produce a speciﬁed result
...
Each demands a
set of tasks and each draws on diverse resources within the business
...
g
...
In addition, business
processes cross organizational boundaries
...

In Chapter 10, we noted that every system is actually a hierarchy of subsystems
...
The overall business is segmented in the following

As a software
engineer, your
reengineering work
occurs at the bottom
of this hierarchy
...
If this
hasn’t been done,
your work is at risk
...

BPR can be applied at any level of the hierarchy, but as the scope of BPR broadens (i
...
, as we move upward in the hierarchy), the risks associated with BPR grow
dramatically
...

30
...
2 Principles of Business Process Reengineering
In many ways, BPR is identical in focus and scope to business process engineering
(Chapter 10)
...

Hammer [HAM90] suggests a number of principles that guide BPR activities when

WebRef
Extensive information on
business process
reengineering can be
found at
www
...
com/
BPR
...
Many companies have compartmentalized business activities so that no single person (or organization) has responsibility (or control) of a business outcome
...
BPR should design processes that avoid
this problem
...

The intent 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
manner
...

802

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Incorporate information processing work into the real work that produces the raw information
...
This localizes control, reduces communication time, and puts
computing power in the hands of those that have a vested interest in the
information that is produced
...
”
Friedrich Wilhelm
Nietzsche

tralized
...
”
For example, instead of running three engineering shifts at a single location,
a global company can run one shift in Europe, a second shift in North America, and a third shift in Asia
...

Link parallel activities instead of integrating their results
...
Otherwise, integration problems are sure to result
...
Using software design jargon, this principle suggests
a ﬂatter organizational architecture with reduced factoring
...
Data should be stored on-line so that
once collected it need never be re-entered
...
Guided by these
principles, business planners and process designers must begin process redesign
...

30
...
3 A BPR Model
Like most engineering activities, business process reengineering is iterative
...
For this reason, there is no start and end to BPR—it is an
evolutionary process
...
1
...
Business goals are identiﬁed within the context of four
key drivers: cost reduction, time reduction, quality improvement, and personnel
development and empowerment
...

Process identiﬁcation
...
They may then be ranked by
importance, by need for change, or in any other way that is appropriate for
the reengineering activity
...
1
A BPR model

Business
definition

Refinement &
instantiation

Process
identification

Prototyping

Process
specification
and design

Process
evaluation

Process evaluation
...
Process tasks are identiﬁed; the costs and time consumed by process
tasks are noted; and quality/performance problems are isolated
...
Based on information obtained during
the ﬁrst three BPR activities, use-cases (Chapter 11) are prepared for each
process that is to be redesigned
...
With the use-case as
the speciﬁcation of the process, a new set of tasks (which conform to the
principles noted in Section 30
...
1) are designed for the process
...
A redesigned business process must be prototyped before it is
fully integrated into the business
...

Reﬁnement and instantiation
...

These BPR activities are sometimes used in conjunction with workﬂow analysis
tools
...
In addition, the modeling techniques commonly
associated with business process engineering activities such as information strategy
planning and business area analysis (Chapter 10) can be used to implement the ﬁrst
four activities described in the process model
...
1
...
Over the years,
debate has raged about the efﬁcacy of BPR (e
...
, [BLE93], [DIC95])
...
From several points of view—systems thinking, peopleware, simple history—you’d have to predict high failure rates for the
concept, rates which seem to be borne out by empirical evidence
...
For others, though, the reengineering effort has evidently been fruitful
...
If BPR is conducted effectively, information
systems are better integrated into the business process
...

But even if business reengineering is a strategy that is rejected by a company, software reengineering is something that must be done
...

30
...
During that time it has been corrected, adapted, and

WebRef

enhanced many times
...
sei
...
edu/
reengineering/

good software engineering practices were always shunted to the side (the press of
other matters)
...
It still works, but every time a change
is attempted, unexpected and serious side effects occur
...
What to do?
Unmaintainable software is not a new problem
...

30
...
1 Software Maintenance
Thirty years ago, software maintenance was characterized [CAN72] as an "iceberg
...
In the early
1970s, the maintenance iceberg was big enough to sink an aircraft carrier
...
Uninitiated readers may ask why so much maintenance is required and why so much effort is expended
...
Even when
these programs were created using the best design and coding techniques known at the
time [and most were not], they were created when program size and storage space were
principle concerns
...

The result is the poorly designed structures, poor coding, poor logic, and poor documentation of the software systems we are now called on to keep running
...
Change is inevitable
when computer-based systems are built; therefore, we must develop mechanisms
for evaluating, controlling, and making modiﬁcations
...
”
Gerald Berns

Upon reading the preceding paragraphs, a reader may protest: "but I don't spend
60 percent of my time ﬁxing mistakes in the programs I develop
...
" We may deﬁne maintenance by
describing four activities [SWA76] that are undertaken after a program is released for
use
...
Only about 20 percent of all maintenance work is
spent “ﬁxing mistakes
...
When maintenance is considered to
encompass all of these activities, it is relatively easy to see why it absorbs so much
effort
...
2
...
For all of these
reasons, reengineering is not accomplished in a few months or even a few years
...
That’s why every organization needs a pragmatic
strategy for software reengineering
...
We’ll discuss the model later in this section, but ﬁrst, some basic principles
...
Consider the following situation
...
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
...
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 systematic
...
” Be sure
that your consideration
of legacy software
applies steps that are
just as obvious
...
A lot more
money is at stake
...
If the house is structurally sound, it may be possible to “remodel”
without rebuilding (at much lower cost and in much less time)
...
Take a peek behind the walls
...
Even if you trash them all, the insight you’ll gain
will serve you well when you start construction
...

This may cost a bit more now, but it will help you to avoid expensive and
time-consuming maintenance later
...
Use practices that will result
in high quality—today and in the future
...

To implement these principles, we apply a software reengineering process model
that deﬁnes six activities, shown in Figure 30
...
In some cases, these activities occur
in a linear sequence, but this is not always the case
...

The reengineering paradigm shown in the ﬁgure is a cyclical model
...
For
any particular cycle, the process can terminate after any one of these activities
...
Every software organization should have an inventory of all
applications
...
g
...
By sorting this information according to business
criticality, longevity, current maintainability, and other locally important criteria, candidates for reengineering appear
...

It is important to note that the inventory should be revisited on a regular cycle
...
g
...

CHAPTER 30

F I G U R E 30
...
Weak documentation is the trademark of many legacy
systems
...
Creating documentation is far too time consuming
...
In some cases, this is the correct approach
...
If a program is relatively static, is coming to the end of its useful life, and is unlikely

Create only as much
documentation as is
required to enhance
understanding of the
software, not one
page more
...
Documentation must be updated, but we have limited resources
...
It may not be necessary to fully redocument an application
...
Over time, a collection of useful
and relevant documentation will evolve
...
The system is business critical and must be fully redocumented
...

Each of these options is viable
...

Reverse engineering
...
A company disassembles a competitive hardware product in an effort to understand its competitor's design and manufacturing "secrets
...
But these documents are proprietary and unavailable to the company doing

808

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

the reverse engineering
...

Reverse engineering for software is quite similar
...
Rather, it is the company's own
work (often done many years earlier)
...
Therefore, reverse engineering for software is the process of analyzing a program in an effort to create a representation of
the program at a higher level of abstraction than source code
...
Reverse engineering tools extract data, architectural,
and procedural design information from an existing program
...
The most common type of reengineering (actually, the use of
the term reengineering is questionable in this case) is code restructuring
...
In such
cases, the code within the suspect modules can be restructured
...

Violations of structured programming constructs are noted and code is then restructured (this can be done automatically)
...
Internal code documentation is updated
...
A program with weak data architecture will be difﬁcult to adapt
and enhance
...
comp
...
ac
...

Unlike code restructuring, which occurs at a relatively low level of abstraction,
data structuring is a full-scale reengineering activity
...
Current data architecture is dissected
and necessary data models are deﬁned (Chapter 12)
...

When data structure is weak (e
...
, ﬂat ﬁles are currently implemented, when a relational approach would greatly simplify processing), the data are reengineered
...

Forward engineering
...
” The old program would be fed into the engine, analyzed, restructured, and then regenerated in a form that exhibited the best aspects of
software quality
...
g
...
More important, these reengineering tools
are becoming increasingly more sophisticated
...
In most
cases, reengineered software reimplements the function of the existing system and
also adds new functions and/or improves overall performance
...
3

REVERSE ENGINEERING
Reverse engineering conjures an image of the "magic slot
...
Unfortunately, the magic slot doesn't exist
...

The abstraction level of a reverse engineering process and the tools used to effect
it refers to the sophistication of the design information that can be extracted from

XRef
The notation discussed
here is explained in
detail in Chapter 12
...
Ideally, the abstraction level should be as high as possible
...
As the
abstraction level increases, the software engineer is provided with information that
will allow easier understanding of the program
...
In most cases, the completeness decreases as the

Three reverse
engineering issues
must be addressed:
abstraction level,
completeness, and
directionality
...
For example, given a source code listing, it is relatively
easy to develop a complete procedural design representation
...

Completeness improves in direct proportion to the amount of analysis performed
by the person doing reverse engineering
...
In most cases, as the abstraction level increases, interactivity must
increase or completeness will suffer
...
If directionality is two way, the information is

810

PA R T F I V E

F I G U R E 30
...

The reverse engineering process is represented in Figure 30
...
Before reverse engineering activities can commence, unstructured (“dirty”) source code is restructured

WebRef

(Section 30
...
1) so that it contains only the structured programming constructs
...
iit
...
ca/
projects/dr/dr
...

The core of reverse engineering is an activity called extract abstractions
...

30
...
1 Reverse Engineering to Understand Processing
The ﬁrst real reverse engineering activity begins with an attempt to understand and
then extract procedural abstractions represented by the source code
...

2

Code can be restructured automatically using a “restructuring engine”—a CASE tool that restructures source code
...
This establishes a context for further
analysis and provides insight into interoperability issues among applications within
the system
...
A block diagram, representing the
interaction between these functional abstractions, is created
...
A processing

“There exists a
passion for
comprehension, just
as there exists a
passion for music
...
”
Albert Einstein

narrative for each component is created
...
When this is the case, the speciﬁcations are
reviewed for conformance to existing code
...

The engineer looks for sections of code that represent generic procedural patterns
...
Within each
of these sections, we can encounter smaller patterns; for example, data validation
and bounds checking often occur within the section of code that prepares data for
processing
...
CASE tools are used to “parse” the semantics of existing code
...

30
...
2 Reverse Engineering to Understand Data
Reverse engineering of data occurs at different levels of abstraction
...
At the system level, global data structures (e
...
, ﬁles,
databases) are often reengineered to accommodate new database management paradigms (e
...
, the move from ﬂat ﬁle to relational or object-oriented database systems)
...

Internal data structures
...
4 This is accomplished by examining the program code with the intent of grouping related program variables
...
For example, record structures, files, lists, and other data structures often provide an initial
indicator of classes
...
As changes
are made, the code no longer conforms to the speciﬁcation
...

812

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Breuer and Lano [BRE91] suggest the following approach for reverse engineering

Relatively insigniﬁcant
compromises in data
structures can lead to
potentially catastrophic
problems in future
years
...

of classes:
1
...
g
...

2
...
For example, a ﬂag may be set when a ﬁle is empty; a
local data structure may serve as a buffer that contains the last 100 records
acquired from a central database
...
For every variable (within the program) that represents an array or ﬁle, list all
other variables that have a logical connection to it
...

Database structure
...
Therefore, reengineering one database schema
into another requires an understanding of existing objects and their relationships
...
Build an initial object model
...
The items contained in records or tables become attributes of a class
...
Determine candidate keys
...
Those that serve as
pointers become candidate keys
...
Reﬁne the tentative classes
...

4
...
Examine classes that have many similar attributes
to determine whether a class hierarchy should be constructed with a generalization class at its head
...
Discover associations
...

Once information deﬁned in the preceding steps is known, a series of transformations [PRE94] can be applied to map the old database structure into a new database
structure
...
3
...
Therefore, the redevelopment of user interfaces has become one

CHAPTER 30

REENGINEERING

813

of the most common types of reengineering activity
...

To fully understand an existing user interface (UI), the structure and behavior of
the interface must be speciﬁed
...
g
...
Much of the information necessary to create a
behavioral model can be obtained by observing the external manifestation of the
existing interface
...

It is important to note that a replacement GUI may not mirror the old interface
exactly (in fact, it may be radically different)
...
For example, an old UI requests that a user provide a scale
factor (ranging from 1 to 10) to shrink or magnify a graphical image
...

30
...
In general, restructuring does not modify the overall
program architecture
...
If the restructuring effort extends
beyond module boundaries and encompasses the software architecture, restructuring becomes forward engineering (Section 30
...

Arnold [ARN89] deﬁnes a number of beneﬁts that can be achieved when software
is restructured:
•

?

What
beneﬁts are
derived from
restructuring?

Programs have higher quality—better documentation, less complexity, and
conformance to modern software engineering practices and standards
...

•

Effort required to perform maintenance activities is reduced
...

Restructuring occurs when the basic architecture of an application is solid, even
though technical internals need work
...
5

30
...
1 Code Restructuring
Code restructuring is performed to yield a design that produces the same function
but with higher quality than the original program
...
g
...
Real
beneﬁt is achieved
only when data and
architecture are
restructured
...
The objective is to take "spaghetti-bowl" code and
derive a procedural design that conforms to the structured programming philosophy (Chapter 16)
...
A resource exchange diagram maps each program module and the resources
(data types, procedures and variables) that are exchanged between it and other modules
...

30
...
2 Data Restructuring
Before data restructuring can begin, a reverse engineering activity called analysis of
source code must be conducted
...
The
intent is to extract data items and objects, to get information on data flow, and to
understand the existing data structures that have been implemented
...

Once data analysis has been completed, data redesign commences
...
Another form of redesign, called data name rationalization,
ensures that all data naming conventions conform to local standards and that aliases
are eliminated as data ﬂow through the system
...
This may mean a translation from one ﬁle format to another, or in some
cases, translation from one type of database to another
...
5

F O R WA R D E N G I N E E R I N G
A program with control ﬂow that is the graphic equivalent of a bowl of spaghetti, with
"modules" that are 2,000 statements long, with few meaningful comment lines in
5

It is sometimes difﬁcult to make a distinction between extensive restructuring and redevelopment
...

CHAPTER 30

REENGINEERING

815

290,000 source statements and no other documentation must be modiﬁed to accommodate changing user requirements
...
We can struggle through modiﬁcation after modiﬁcation, ﬁghting the implicit
design and source code to implement the necessary changes
...
We can attempt to understand the broader inner workings of the program in
an effort to make modiﬁcations more effectively
...
We can redesign, recode, and test those portions of the software that require
modiﬁcation, applying a software engineering approach to all revised segments
...
We can completely redesign, recode, and test the program, using CASE
(reengineering) tools to assist us in understanding the current design
...
Circumstances may dictate the ﬁrst option even
if the others are more desirable
...
Then, option 2, 3, or 4 is applied
...
This concept is deﬁned as "the application of today's methodologies to yesterday's systems to support tomorrow's requirements
...
Before passing judgment, consider the following points:
1
...
You can think
of a thousand reasons
to delay it, and you’ll
get away with
procrastinating for
quite a while
...

of initial development of that line
...
Redesign of the software architecture (program and/or data structure), using
modern design concepts, can greatly facilitate future maintenance
...
Because a prototype of the software already exists, development productivity
should be much higher than average
...
The user now has experience with the software
...

5
...

6
...

When a software development organization sells software as a product, preventive maintenance is seen in "new releases" of a program
...
g
...
These programs can be ranked by importance and then reviewed as
candidates for preventive maintenance
...
In most cases, forward engineering does not simply create a modern equivalent of an older program
...

The redeveloped program extends the capabilities of the older application
...
5
...

Over the past decade many mainframe applications have been reengineered to accommodate client/server architectures
...
Although a variety of different distributed environments can be designed, the typical mainframe application that is reengineered into a client/server architecture has the following features:
•

Application functionality migrates to each client computer
...

•

Database functions are allocated to the server
...
g
...

•

New communications, security, archiving, and control requirements must be
established at both the client and server sites
...
In addition, an “enterprise network infra-

In some cases, c/s or
OO systems designed
to replace a legacy
application should be
approached as a new
development project
...
In
some cases, you may
be better off rejecting
the old and creating
identical new
functionality
...

Reengineering for c/s applications begins with a thorough analysis of the business environment that encompasses the existing mainframe
...
4) can be identiﬁed
...
Yet these
transactions and queries must be controlled within the context of a set of business
rules (deﬁned by an existing or reengineered business process)
...

The functions of the existing database management system and the data architecture of the existing database must be reverse engineered as a precursor to the
redesign of the database foundation layer
...
In every case, the c/s database is reengineered to ensure that transactions are executed in a consistent manner, that all updates are performed only by
authorized users, that core business rules are enforced (e
...
, before a vendor record
is deleted, the server ensures that no related accounts payable, contracts, or com-

CHAPTER 30

F I G U R E 30
...

The business rules layer represents software resident at both the client and the
server
...

The client applications layer implements business functions that are required by
speciﬁc groups of end-users
...
Communication among
the desktop applications (when necessary) is controlled by the business rules layer
...
The interested reader should see [VAS93],
[INM93], and [BER92]
...
5
...
But what about existing applications that
were developed using conventional methods? In some cases, the answer is to leave
such applications “as is
...

818

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Reengineering conventional software into an object-oriented implementation uses
many of the same techniques discussed in Part Four of this book
...
If the reengineered system extends the functionality or behavior of the original application, use-cases (Chapters 11 and 21) are created
...
Class hierarchies, object-relationship models, object-behavior models, and subsystems are
deﬁned, and object-oriented design commences
...
If the existing application exists within
a domain that is already populated by many object-oriented applications, it is likely
that a robust component library exists and can be used during forward engineering
...
However,
these must be redesigned to conform to the object-oriented architecture
...
5
...
In fact, a signiﬁcant portion
of all effort expended in the transition from mainframe to client/server computing
can be spent in the reengineering of client application user interfaces
...
Understand the original interface and the data that move between it

follow to
reengineer a user
interface?

other elements of a program interact with existing code that implements the

and the remainder of the application
...
If a new GUI is to be developed, the data that ﬂow between the GUI
and the remaining program must be consistent with the data that currently
ﬂow between the character-based interface and the program
...
Remodel the behavior implied by the existing interface into a series
of abstractions that have meaning in the context of a GUI
...
A redesigned interface must still
allow a user to exhibit the appropriate business behavior
...
The reengineered GUI may
streamline the query to a small sequence of mouse picks, but the intent and
content of the query remain unchanged
...
Introduce improvements that make the mode of interaction more
efﬁcient
...

4
...
The existence of class libraries and
fourth generation tools can reduce the effort required to build the GUI signiﬁcantly
...
Care must be taken to ensure that the GUI does not propagate adverse side effects into the remainder of the application
...
6

THE ECONOMICS OF REENGINEERING
In a perfect world, every unmaintainable program would be retired immediately, to
be replaced by high-quality, reengineered applications developed using modern software engineering practices
...
Reengineering drains resources that can be used for other business purposes
...

A cost/benefit analysis model for reengineering has been proposed by Sneed
[SNE95]
...
”
Sign in auto
dealership
suggesting a
tune-up

current annual maintenance cost for an application
...

P3 =

current annual business value of an application
...

P5 =

predicted annual operations cost after reengineering
...

P7 =

estimated reengineering costs
...

P9 =

reengineering risk factor (P9 = 1
...

L

expected life of the system
...
e
...
2
...
Those applications that show the highest cost/beneﬁt can be targeted for reengineering, while
work on others can be postponed until resources are available
...
7

SUMMARY
Reengineering occurs at two different levels of abstraction
...
At the software level, reengineering examines information systems and applications with the intent of restructuring or reconstructing them so that they exhibit higher quality
...

BPR has a focus that extends beyond software
...

Software reengineering encompasses a series of activities that include inventory
analysis, document restructuring, reverse engineering, program and data restructuring, and forward engineering
...

Inventory analysis enables an organization to assess each application systematically, with the intent of determining which are candidates for reengineering
...
Reverse engineering is the process of analyzing
a program in an effort to extract data, architectural, and procedural design information
...

The cost/beneﬁt of reengineering can be determined quantitatively
...
In almost every case in which a program
has a long life and currently exhibits poor maintainability, reengineering represents
a cost-effective business strategy
...
S
...
IEEE, vol
...
4, April 1989,
pp
...

[BER92] Berson, A
...

CHAPTER 30

REENGINEERING

821

[BLE93] Bleakley, F
...
, “The Best Laid Plans: Many Companies Try Management Fads,
Only to See Them Flop,” The Wall Street Journal, July 6, 1993, p
...

[BRE91] Breuer, P
...
and K
...
3,
1991, pp
...

[CAN72] Canning, R
...
10, no
...

[CAS88] "Case Tools for Reverse Engineering," CASE Outlook, CASE Consulting Group,
vol
...
2, 1988, pp
...

[CHI90]

Chikofsky, E
...
, and J
...
Cross, II, "Reverse Engineering and Design Recov-

ery: A Taxonomy," IEEE Software, January 1990, pp
...

[DAV90] Davenport, T
...
and J
...
Young, “The New Industrial Engineering: Information Technology and Business Process Redesign,” Sloan Management Review, Summer 1990, pp
...

[DEM95] DeMarco, T
...
101–102
...
, Strategic Business Reengineering, LCI Press, 1995
...
, “Reengineer Work: Don’t Automate, Obliterate,” Harvard Business Review, July–August 1990, pp
...

[HAN93] Manna, M
...
53–63
...
H
...

[JAY94]

Jaychandra, Y
...

[MER93] Merlo, E
...
, “Reverse Engineering of User Interfaces,” Proc
...
171–178
...
, et al
...
64–73
...
, in Techniques of Program and System Maintenance, (G
...
)
Winthrop Publishers, 1981
...
M
...
J
...
10–11
...
J
...
R
...
37, no
...
42–49
...
A
...
C
...
W
...
Conf
...
174–179
...
, "Planning the Reengineering of Legacy Systems," IEEE Software,
January 1995, pp
...

[STE93] Stewart, T
...
, “Reengineering: The Hot New Managing Tool,” Fortune, August
23, 1993, pp
...

[SWA76] Swanson, E
...
, "The Dimensions of Maintenance,"Proc
...
Conf
...
492–497
...
, Client/Server Strategies, IDG Books, 1993
...
D
...

[WEI95] Weisz, M
...
8, no
...
9–15
...
1
...
Describe the business
process in which you played a part
...
1
...

30
...
Do some research on the efﬁcacy of business process reengineering
...

30
...
Your instructor will select one of the programs that everyone in the class has
developed during this course
...
Do not explain or walk through the program
...

a
...

b
...

c
...

30
...
Explore the inventory analysis checklist presented at the SEPA Web site and
attempt to develop a quantitative software rating system that could be applied to
existing programs in an effort to pick candidate programs for reengineering
...
6
...
5
...
(Hint: Think of new
descriptive technologies that could be used to communicate the intent of the software
...
6
...
Do some research on this subject (i
...
, the use of AI for reverse engineering) and write a brief paper that takes a
stand on this point
...
7
...
8
...
9
...

30
...
There is a subtle difference between restructuring and forward engineering
...
11
...
Present a summary
...
12
...
6?

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
Like many hot topics in the business community, the hype surrounding business
process reengineering has given way to a more pragmatic view of the subject
...
Later, Hammer (Beyond Reengineering: How
the Processed-Centered Organization Is Changing Our Work and Our Lives, HarperCollins 1997) reﬁned his view by focusing on “process-centered” issues
...
(Business Process Improvement Workbook, McGrawHill, 1997), Hunt (Process Mapping: How to Reengineer Your Business Processes, Wiley,
1996), and Carr and Johansson (Best Practices in Reengineering: What Works and What
Doesn't in the Reengineering Process, McGraw-Hill, 1995) present case studies and
detailed guidelines for BPR
...
Berztiss (Software Methods for Business Reengineering, Springer, 1996) and Spurr et al
...

Relatively few books have been dedicated to software reengineering
...

Miller (Reengineering Legacy Software Systems, Digital Press, 1998) “provides a framework for keeping application systems synchronized with business strategies and technology changes
...
Cook
(Building Enterprise Information Architectures: Reengineering Information Systems, Prentice-Hall, 1996) discusses the bridge between BPR and information technology
...
Arnold (Software Reengineering, IEEE Computer Society Press, 1993) has put together an excellent anthology of early papers that focus on
software reengineering technologies
...
An up-to-date list of World Wide Web
references can be found at the SEPA Web site:
http://www
...
com/engcs/compsci/pressman/resources/
reengineering
...
826
CASE tools
...
833
IPSE
...
834
object management
layer
...
837
repository
functions
...
835
tools taxonomy
...
Prior to the 1990s, many software developers were
the "shoemaker's children
...

Today, software engineers have their ﬁrst new pair of shoes—computer-aided
software engineering (CASE)
...

In earlier chapters of this book we have attempted to provide a reasonable
understanding of the underpinnings of software engineering technology
...

E

What is it? Computer-aided soft-

ject milestone have substantial beneﬁt
...
Tools can

assist software engineering man-

provide new ways of looking at software engi-

agers and practitioners in every activity associ-

neering information—ways that improve the

ated with the software process
...
This leads

QUICK
LOOK

project management activities, manage all work

to better decisions and higher software quality
...
If a full tool set

and test work
...

Who does it? Project managers and software engineers use CASE
...

What is the work product? CASE tools assist a software engineer in producing high-quality work

Why is it important? Software engineering is difﬁcult
...
In addition, the availability of automa-

Tools that reduce the amount of effort required to

tion allows the CASE user to produce additional

produce a work product or accomplish some pro-

customized work products that could not be

825

826

PA R T F I V E

QUICK
LOOK

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

easily or practically produced

tools can be used effectively, a software process

without tool support
...
Only

neering practices—not to replace them
...

31
...
Software engineers now recognize that they
need more and varied tools along with an organized and efﬁcient workshop in which
to place the tools
...

CASE provides the software engineer with the ability to automate manual activities and to improve engineering insight
...

31
...
The building blocks for CASE are illustrated

“The most valuable
CASE tools are those
that contribute
information to the
development
process
...
1
...
It is interesting to note that the foundation for effective CASE
environments has relatively little to do with software engineering tools themselves
...
In
addition, the environment architecture must consider the human work patterns that
are applied during the software engineering process
...
But the CASE environment itself

CHAPTER 31

F I G U R E 3 1
...
A set of portability services provides a bridge between
CASE tools and their integration framework and the environment architecture
...
Portability services allow CASE tools and their integration framework to migrate across different
hardware platforms and operating systems without signiﬁcant adaptive maintenance
...
1 represent a comprehensive foundation for the integration of CASE tools
...
In fact, some CASE tools remain
"point solutions
...
g
...
Although this situation is not ideal, a CASE tool can be used quite effectively,
even if it is a point solution
...
2
...

Integrated tools help
the team develop,
organize, and control
work products
...

of the integration spectrum is the individual (point solution) tool
...
Such tools produce output in a standard format that should be compatible
with other tools that can read the format
...
g
...
Using this approach, the
synergy between the tools can produce end products that would be difﬁcult to create using either tool separately
...

Although this approach is quite effective, the closed architecture of most single-source
environments precludes easy addition of tools from other vendors
...
2
Integration
options

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Individual tool
(point solution)

Data exchange

Single source

Tool bridges &
partnerships

IPSE

At the high end of the integration spectrum is the integrated project support environment (IPSE)
...
CASE tool vendors use IPSE standards to build tools that will be compatible with the IPSE and therefore compatible with one another
...
3

A TA X O N O M Y O F C A S E T O O L S
A number of risks are inherent whenever we attempt to categorize CASE tools
...
Confusion (or antagonism) can
be created by placing a speciﬁc tool within one category when others might believe
it belongs in another category
...
In addition, simple categorization tends to be ﬂat—that is, we do
not show the hierarchical interaction of tools or the relationships among them
...

CASE tools can be classiﬁed by function, by their role as instruments for managers
or technical people, by their use in the various steps of the software engineering
process, by the environment architecture (hardware and software) that supports them,
or even by their origin or cost [QED89]
...

CHAPTER 31

C O M P U T E R - A I D E D S O F T WA R E E N G I N E E R I N G

829

Business process engineering tools
...

ments of an organization, business process engineering tools provide a "meta-model"
from which specific information systems are derived
...
The primary objective for
tools in this category is to represent business data objects, their relationships, and
how these data objects ﬂow between different business areas within a company
...
If an organization works to improve

XRef
The elements of the
software process are
discussed in Chapter 2
...
Process modeling tools
(also called process technology tools) are used to represent the key elements of a
process so that it can be better understood
...
Process management tools provide links to other tools that
provide support to deﬁned process activities
...
Scheduling
methods are discussed
in Chapter 7
...
Tools in this category focus on two primary areas: software project effort and cost estimation and project scheduling
...
Project scheduling tools enable the manager to deﬁne all project 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
...

Risk analysis tools
...
Risk analysis tools enable a project manager to build a risk table by providing detailed guidance in the identiﬁcation and analysis of risks
...

Project management tools
...
In addition, a manager should use tools to collect metrics that will ultimately provide an indication of software product quality
...

Requirements tracing tools
...

the cracks
...
The objective of requirements tracing tools is to provide a systematic
approach to the isolation of requirements, beginning with the customer request for
proposal or specification
...

Metrics and management tools
...

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

to improve the quality of the software that is produced
...
Management-oriented tools
capture project speciﬁc metrics (e
...
, LOC/person-month, defects per function point)
that provide an overall indication of productivity or quality
...

Documentation tools
...
More detail
is presented at the
SEPA Web site
...
Most software development organizations
spend a substantial amount of time developing documents, and in many cases the
documentation process itself is quite inefﬁcient
...
For this reason, documentation tools provide an
important opportunity to improve productivity
...

XRef
SQA is presented in
Chapter 8
...
CASE is a workstation technology
...

Quality assurance tools
...
Other tools extract technical metrics (Chapters 19 and
24) in an effort to project the quality of the software that is being built
...
Database management software serves as a foun-

XRef
The software repository
is discussed in Chapter
9
...
Given the emphasis on conﬁguration objects, database management
tools for CASE are evolving from relational database management systems to objectoriented database management systems
...
Software configuration manage-

XRef
SCM activities,
including identiﬁcation,
version control, change
control, auditing, and
status accounting, are
discussed in Chapter 9
...
Tools can assist in all ﬁve major
SCM tasks—identification, version control, change control, auditing, and status
accounting
...

Analysis and design tools
...
The models contain a representation of
data, function, and behavior (at the analysis level) and characterizations of data, archi-

CHAPTER 31

XRef
Analysis and design are
discussed throughout
Parts Three and Four of
this book
...
1 By performing consistency and validity checking on the models, analysis and design tools provide a software engineer
with some degree of insight into the analysis representation and help to eliminate
errors before they propagate into the design, or worse, into implementation itself
...
PRO/SIM (prototyping and simulation) tools [NIC90] provide the

XRef
Prototyping and
simulation are
discussed brieﬂy in
Chapter 10
...
In addition, these tools enable the software engineer to
develop mock-ups of the real-time system, allowing the customer to gain insight into
the function, operation and response prior to actual implementation
...
Interface design and development tools

XRef
The elements of user
interface design are
presented in Chapter
15
...
However,
these tool kits are being replaced by interface prototyping tools that enable rapid onscreen creation of sophisticated user interfaces that conform to the interfacing standard that has been adopted for the software
...
A variety of different prototyping tools can be used
...

applications
...
Many analysis and design tools
have extensions that provide a prototyping option
...
Finally, a variety of
fourth generation tools have prototyping features
...
The programming tools category encompasses the compilers, editors, and debuggers that are available to support most conventional programming languages
...

XRef
WebE is discussed in
Chapter 29
...
The activities associated with Web engineering are supported by a variety of tools for WebApp development
...

XRef
Software testing is
discussed in Chapters
17, 18, and 23 as
well as 28 and 29
...
In their directory of software testing tools, Software
Quality Engineering [SQE95] deﬁnes the following testing tools categories:
•

Data acquisition—tools that acquire data to be used during testing
...

1

Analogous representations are provided by object-oriented analysis and design tools
...

•

Simulation—tools that simulate function of hardware or other externals
...

•

Cross-functional tools—tools that cross the bounds of the preceding categories
...

Static analysis tools
...
Three different types of static testing tools are used in the industry: codeXRef
White-box testing
methods are discussed
in Chapter 17
...
Code-based testing tools accept source code (or PDL) as input and perform a
number of analyses that result in the generation of test cases
...
g
...
Requirements-based
testing tools isolate speciﬁc user requirements and suggest test cases (or classes of
tests) that will exercise the requirements
...
Dynamic testing tools interact with an executing program, checking path coverage, testing assertions about the value of speciﬁc variables,
and otherwise instrumenting the execution ﬂow of the program
...
An intrusive tool changes the software to be tested
by inserting probes (extra instructions) that perform the activities just mentioned
...

Test management tools
...

nate software testing for each of the major testing steps
...
In addition to the functions noted, many test
management tools also serve as generic test drivers
...

ware under test, and then invokes the software to be tested
...
The c/s environment demands specialized testing
tools that exercise the graphical user interface and the network communications
requirements for client and server
...
Tools for legacy software address a set of maintenance activities that currently absorb a signiﬁcant percentage of all software-related effort
...

other design information
...

•

On-line system reengineering tools are used to modify on-line database systems (e
...
, convert IDMS or DB2 ﬁles into entity-relationship format)
...

31
...
The benefits of integrated CASE (I-CASE) include (1) smooth
transfer of information (models, programs, documents, data) from one tool to
another and one software engineering step to the next; (2) a reduction in the effort
required to perform umbrella activities such as software configuration management, quality assurance, and document production; (3) an increase in project control that is achieved through better planning, monitoring, and communication; and
(4) improved coordination among staff members who are working on a large software project
...
Integration demands consistent rep-

CASE tools integration
demands a database
that contains
consistent
representations of
software engineering
information
...
Comprehensive I-CASE environments have emerged more slowly than originally expected
...

The term integration implies both combination and closure
...
Tools
are integrated so that software engineering information is available to each tool that
needs it; usage is integrated so that a common look and feel is provided for all tools;
a development philosophy is integrated, implying a standardized software engineering approach that applies modern practice and proven methods
...

•

Enable a change to one item of information to be tracked to other related
information items
...

•

XRef
Process-related issues
are discussed in
Chapters 2, 4, and 7
...

Allow direct, nonsequential access to any tool contained in the environment
...

•

Enable the users of each tool to experience a consistent look and feel at the
human/computer interface
...

•

Collect both management and technical metrics that can be used to improve
the process and the product
...
1) must ﬁt together in a seamless fashion
...

31
...
The integration
framework facilitates transfer of information into and out of the pool
...
Most
models (e
...
, [FOR90], [SHA95]) of the integration framework represent these components as layers
...
3
...
3) incorporates a standardized interface tool kit
with a common presentation protocol
...
Both provide a consistent mechanism for communication between the interface and individual CASE tools
...
3
Architectural
model for the
integration
framework

C O M P U T E R - A I D E D S O F T WA R E E N G I N E E R I N G

835

User interface layer
Interface tool kit
Presentation protocol

Tools management services

CASE
tool

Tools layer

Object management layer
Integration services
Configuration management services

Shared repository layer
CASE database
Access control functions

tools the same look and feel
...

The tools layer incorporates a set of tools management services with the CASE
tools themselves
...
If multitasking is used during the execution of one or more tools,
TMS performs multitask synchronization and communication, coordinates the ﬂow

WebRef
Resources for CASE tool
integration and integrated
software engineering
environments can be
obtained at
see
...
ﬂinders
...

au/seweb/ti/

of information from the repository and object management system into the tools,
accomplishes security and auditing functions, and collects metrics on tool usage
...
In essence, software in this layer of the framework architecture provides the mechanism for tools integration
...
Working in conjunction with the CASE repository, the OML provides integration services—a set of standard modules that couple
tools with the repository
...

The shared repository layer is the CASE database and the access control functions
that enable the object management layer to interact with the database
...

836

PA R T F I V E

31
...
" During the early history of software development, the repository was indeed a person—the programmer who had to remember
the location of all information relevant to a software project, who had to recall information that was never written down and reconstruct information that had been lost
...
Today, the repository is a
"thing"—a database that acts as the center for both accumulation and storage of software engineering information
...

In this book, a number of different terms have been used to refer to the storage
place for software engineering information: CASE database, project database, integrated project support environment (IPSE) database, requirements dictionary (a limited
database), and repository
...

31
...
1 The Role of the Repository in I-CASE
The repository for an I-CASE environment is the set of mechanisms and data structures that achieve data/tool and data/data integration
...

•

Information sharing provides a mechanism for sharing information among
multiple developers and between multiple tools, manages and controls multiuser access to data and locks or unlocks objects so that changes are not
inadvertently overlaid on one another
...

•

Data/data integration is the database management system that relates data
objects so that other functions can be achieved
...

CHAPTER 31

•

C O M P U T E R - A I D E D S O F T WA R E E N G I N E E R I N G

837

Document standardization is the deﬁnition of objects in the database that
leads directly to a standard approach for the creation of software engineering
documents
...
The
meta-model determines how information is stored in the repository, how data can be
accessed by tools and viewed by software engineers, how well data security and
integrity can be maintained, and how easily the existing model can be extended to
accommodate new needs [WEL89]
...
A detailed discussion of these models is beyond the scope of this book
...

31
...
2 Features and Content
The features and content of the repository are best understood by looking at it from
two perspectives: what is to be stored in the repository and what speciﬁc services are
provided by the repository
...

•

Information about the problem domain
...

•

Rules and instructions pertaining to the software process (methodology)
being followed
...

•

Information about the organizational context
...
1
...

Many repository requirements are the same as those of typical applications built
on a commercial database management system (DBMS)
...
The DBMS features that support the management of software development information include

? What typical
DBMS
features support
CASE?

•

Nonredundant data storage
...

•

High-level access
...

838

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

TA B L E 3 1
...
CASE tools and the target applications are isolated from
physical storage so they are not affected when the hardware conﬁguration is
changed
...
The repository implements record locking, two-stage
commits, transaction logging, and recovery procedures to maintain the
integrity of the data when there are concurrent users
...
The repository provides mechanisms to control who can view and
modify information contained within it
...
The repository allows direct access to its
contents through a convenient user interface such as SQL or a formsoriented "browser," enabling user-deﬁned analysis beyond the standard
reports provided with the CASE tool set
...
Repositories usually provide a simple import/export mechanism
to enable bulk loading or transfer
...
A robust repository must permit multiple developers to
work on an application at the same time
...
For environments based on networking, multiuser support also implies that the repository can interface with common networking protocols (object request brokers) and facilities
...
The special features of CASE
repositories include

? What
special

•

Storage of sophisticated data structures
...
A repository also includes an information model (or metamodel) describing the structure, relationships and semantics of the data
stored in it
...
The repository not only stores models and descriptions of systems under development,
but also associated meta-data (i
...
, additional information describing the
software engineering data itself, such as when a particular design component was created, what its current status is, and what other components it
depends upon)
...
The repository information model also contains rules,
or policies, describing valid business rules and other constraints and requirements on information being entered into the repository (directly or via a
CASE tool)
...
net/cetus/oo_
db_systems_1
...

•

Semantics-rich tool interface
...
For example, a data ﬂow diagram created by
a CASE tool is stored in the repository in a form based on the information
model and independent of any internal representations used by the tool itself
...
Thus, the semantics stored in the
repository permit data sharing among a variety of tools, as opposed to speciﬁc tool-to-tool conversions or "bridges
...
A repository contains information not only
about the software application itself, but also about the characteristics of
each particular project and the organization's general process for software
development (phases, tasks, and deliverables)
...
For example, updating the status of project tasks could
be done automatically or as a by-product of using the CASE tools
...
Task assignment and queries
can also be handled by e-mail
...

The following repository features are all encompassed by software conﬁguration
management (Chapter 9)
...
As a project progresses, many versions of individual work products will be created
...

The CASE repository must be able to control a wide variety of object
types, including text, graphics, bit maps, complex documents, and unique
objects like screen and report deﬁnitions, object ﬁles, test data, and results
...

To support parallel development, the version control mechanism should
permit multiple derivatives (variants) from a single predecessor
...

Dependency tracking and change management
...

These include relationships between enterprise entities and processes,
among the parts of an application design, between design components and
the enterprise information architecture, between design elements and deliverables, and so on
...
Maintaining these relationships among development objects is called link management
...
The impact of
change can be tracked
if this feature is
available
...
Among the many functions that link management supports is the
ability to identify and assess the effects of change
...
It also helps prevent unexpected side effects that would otherwise lead
to defects and system failures
...
For example, if a data ﬂow diagram is modiﬁed, the repository can
detect whether related data dictionaries, screen deﬁnitions, and code modules also require modiﬁcation and can bring affected components to the
developer's attention
...
This special function depends on link management
and provides the ability to track all the design components and deliverables
that result from a speciﬁc requirement speciﬁcation (forward tracking)
...

Conﬁguration management
...
Version management provides the needed versions, and link management keeps track of interdependencies
...
An audit trail establishes additional information about when,
why, and by whom changes are made
...
A
repository trigger mechanism is helpful for prompting the developer or the
tool that is being used to initiate entry of audit information (such as the reason for a change) whenever a design element is modiﬁed
...
7

SUMMARY
Computer-aided software engineering tools span every activity in the software process
and those umbrella activities that are applied throughout the process
...

In this chapter, we consider a taxonomy of CASE tools
...
Each
category of tool is considered a "point solution
...
Data integration can be achieved through direct
exchange of information, through common ﬁle structures, by data sharing or interoperability, or through the use of a full I-CASE repository
...
Human/computer integration is achieved
through interface standards that have become commonplace throughout the industry
...

The CASE repository has been referred to as a "software bus
...
But

842

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

the repository is much more than a "bus
...
The repository is a relational or objectoriented database that is "the center of accumulation and storage" for software engineering information
...
, "In Search of the Integrated Environment," CASE Outlook,
March–April 1989, pp
...

[FOR89b] Forte, G
...

5–27
...
, "Integrated CASE: A Deﬁnition," Proc
...
User's Group Conference, Cadre Technologies, Providence, RI, March 1990
...
, “Repositories: Data Dictionary Descendant Can Extend Legacy

Code Investment,” Application Development Trends, April 1995, pp
...

[NIC90]

Nichols, K
...
, "Performance Tools," IEEE Software, May 1990, pp
...

[QED89] CASE: The Potential and the Pitfalls, QED Information Sciences,1989
...

[SHA95] Sharon, D
...
Bell, “Tools That Bind: Creating Integrated Environments,”
IEEE Software, March 1995, pp
...

[WEL89] Welke, R
...
, "Meta Systems on Meta Models," CASE Outlook, December 1989,
pp
...

PROBLEMS AND POINTS TO PONDER
31
...
Make a list of all software development tools that you use
...

31
...
Using the ideas introduced in Chapters 13 through 16, how would you suggest that portability services be built?
31
...
Build a paper prototype for a project management tool that encompasses the
categories noted in Section 31
...
Use Part Two of this book for additional guidance
...
4
...
Discuss
why OODMS would be ideal for SCM tools
...
5
...
Develop a matrix that compares features
...
6
...
7
...
Do
not use examples from computing
...
8
...

31
...
In a number of places in this chapter, the terms meta-model and meta-data
are used
...

31
...
Can you think of additional conﬁguration items that might be included in the
repository contents shown in Table 31
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
A number of books on CASE were published in the 1980s and early 1990s in an effort
to capitalize on the high degree of interest in the industry at that time
...
Among the early offerings that still have
value are
Bergin, T
...
, Computer-Aided Software Engineering: Issues and Trends for the 1990s and
Beyond, Idea Group Publishing, 1993
...
S
...

Brown, A
...
, D
...
Carney, and E
...
Morris, Principles of CASE Tool Integration, Oxford University Press, 1994
...
and R
...

Lewis, T
...
, Computer-Aided Software Engineering, Van Nostrand-Reinhold, 1990
...
, Information Engineering: CASE Practices and Techniques, Wiley, 1993
...
, IEEE
Computer Society, 1992) contains a useful collection of early papers on CASE and
software development environments
...
The best sources of current information
on CASE tools are the Internet, technical periodicals, and industry newsletters
...
” A detailed report by Wallnau and Feiler (Tool Integration and Environment
Architectures, Software Engineering Institute, CMU/SEI-91-TR-11, May 1991), although
dated, remains one of the best discussions of CASE environments readily available
...
An upto-date list of World Wide Web references can be found at the SEPA Web site:
http://www
...
com/engcs/compsci/pressman/resources/CASE
...
849
people
...
848
scope of change
...
846
technology
...
We presented both management procedures and technical methods, basic principles and specialized techniques, people-oriented
activities and tasks that are amenable to automation, paper and pencil notation and CASE tools
...

Yet, we have never promised that software engineering is a panacea
...
Although he wrote these words more
than a decade ago, Max Hopper [HOP90] describes the current state of affairs:

I

Because changes in information technology are becoming so rapid and unforgiving,
and the consequences of falling behind are so irreversible, companies will either
master the technology or die
...
Companies
will have to run harder and harder just to stay in place
...
By the time a decision

What is it? The future is never

soothsayers? Why do major multinational corpo-

easy to predict—pundits, talking

rations hire consulting firms and think tanks to

heads, and industry experts not-

prepare forecasts? Why does a substantial

withstanding
...

shaped by more modest technologies that some-

What are the steps? There is no formula for predict-

how modify the direction and width of the thor-

ing the road ahead
...
Therefore, we won’t try to predict the

lecting data, organizing it to provide useful

future
...

will be at some future time
...

845

846

PA R T F I V E

QUICK
LOOK

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

How do I ensure that I’ve done it

(with the exception, thankfully, of predictions of

right? Predicting the road ahead

the end of the world)
...
In fact, it’s

to extrapolate them ahead in time
...

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 newer (and even better) has come along, and the process
begins anew
...
Our intent is not to explore every area
of research the holds promise
...
Rather, we explore the scope of change and the way in which change
itself will affect the software engineering process in the years ahead
...
1

T H E I M P O R TA N C E O F S O F T WA R E — R E V I S I T E D
The importance of computer software can be stated in many ways
...
The function delivered by software differentiates products, systems, and services and provides competitive advantage in the
marketplace
...
The programs, documents,
and data that are software help to generate the most important commodity that any
individual, business, or government can acquire—information
...
It is a mechanism for automating business, industry, and government, a medium for transferring new technology, a method of
capturing valuable expertise for use by others, a means for differentiating one company's
products from its competitors, and a window into a corporation's collective knowledge
...
But in many ways, software is also
a hidden technology
...

Software is pervasive, and yet, many people in positions of responsibility have little or
no real understanding of what it really is, how it's built, or what it means to the institutions
that they (and it) control
...

The pervasiveness of software leads us to a simple conclusion: Whenever a technology has a broad impact—an impact that can save lives or endanger them, build

CHAPTER 32

THE ROAD AHEAD

847

businesses or destroy them, inform government leaders or mislead them—it must be
"handled with care
...
2

THE SCOPE OF CHANGE
The changes in computing over the past 50 years have been driven by advances in
the "hard sciences"—physics, chemistry, materials science, engineering
...
The gestation period for the computing technologies that may be derived from

“The best thing about
the future is that it
comes one day at a
time
...

The inﬂuence of the soft sciences may help mold the direction of computing research
in the hard sciences
...

The changes that will affect software engineering over the next decade will be
inﬂuenced from four simultaneous sources: (1) the people who do the work, (2) the
process that they apply, (3) the nature of information, and (4) the underlying computing technology
...

32
...
The rapid growth in the size of the "average" program would present us with
few problems if it wasn't for one simple fact: As program size increases, the number
of people who must work on the program must also increase
...
One way around this problem is to create a number of software engineering teams, thereby compartmentalizing people into
individual working groups
...
Worse, communication (between individuals or teams) tends
to be inefﬁcient—that is, too much time is spent transferring too little information content, and all too often, important information "falls into the cracks
...
E-mail, bulletin
boards, and centralized video conferencing are now commonplace as mechanisms
for connecting a large number of people to an information network
...
With an effective electronic mail or bulletin board system, the problem encountered by a software engineer in New York City may be solved with the help of a
colleague in Tokyo
...

Video personalizes the communication
...
But video
also provides another beneﬁt
...
”
Alvin Tofﬂer

software and to train newcomers on a project
...
Intelligent agents will enhance the engineer's ability by cross-checking engineering work
products using domain-speciﬁc knowledge, performing clerical tasks, doing directed
research, and coordinating human-to-human communication
...
On the Internet, a software engineer can subscribe to newsgroups that focus on technology areas
of immediate concern
...
The World Wide Web provides a software engineer with the world’s largest library of research papers and reports, tutorials, commentary, and references in software engineering
...
However, the ways in which they communicate, the environment in which
they work, the way in which they acquire knowledge, the methods and tools that they
use, the discipline that they apply, and therefore, the overall culture for software development will change in signiﬁcant and even profound ways
...
4

T H E " N E W " S O F T WA R E E N G I N E E R I N G P R O C E S S
It is reasonable to characterize the ﬁrst two decades of software engineering practice as the era of "linear thinking
...
Yet, linear approaches to
software development run counter to the way in which most systems are actually
built
...
It is for this
reason that a large segment of the software engineering community is moving toward
evolutionary models for software development
...

CHAPTER 32

THE ROAD AHEAD

849

deliver a partial solution, even when a complete product is not possible within the
time allotted
...

What activities must populate the evolutionary process? Over the past decade, the
Capability Maturity Model developed by the Software Engineering Institute [PAU93]
has had a substantial impact on efforts to improve software engineering practices
...
g
...

Object technologies, coupled with component-based software engineering (Chapter 27), are a natural outgrowth of the trend toward evolutionary process models
...
”
Elbert Hubbard

Both will have a profound impact on software development productivity and product quality
...
When
reuse is coupled with CASE tools for application prototyping, program increments
can be built far more rapidly than through the use of conventional approaches
...
Therefore, it is likely that customers
and users will become much more involved in the development of software
...

The rapid growth in Web-based applications (WebApps) is changing both the software engineering process and its participants
...
But in the case of WebApps, immediacy, security, and aesthetics become dominant concerns
...
g
...
The software that has grown out of Web engineering work has already resulted in radical
economic and cultural change
...

32
...
Thirty years ago, the term data processing was the operative phrase for describing the use of computers in a business context
...
The emphasis is not merely to process large quantities of data
but rather to extract meaningful information from this data
...

When software applications are discussed today, the words data and information
occur repeatedly
...
1
An
“information”
spectrum

PA R T F I V E

A D VA N C E D T O P I C S I N S O F T WA R E E N G I N E E R I N G

Data:
no associativity

Information:
associativity within
one context

Knowledge:
associativity within
multiple contexts

Wisdom:
creation of generalized
principles based on
existing knowledge
from different sources

applications, but its use is relatively rare
...

Data is raw information—collections of facts that must be processed to be meaningful
...
Knowledge
associates information obtained in one context with other information obtained in a
different context
...
Each of these four views of "information" is represented
schematically in Figure 32
...

“Wisdom is the
power that enables
us to use knowledge
for the beneﬁt of
ourselves and
others
...
The key is our ability to associate information from a variety of different sources

Thomas J
...
Software engineers are now equally concerned with systems that process
knowledge
...
Information collected on a variety of
related and unrelated topics is connected to form a body of fact that we call knowl-

with some distinct beneﬁt
...
9 million
...
Relating this piece of data with birthrates for the preceding
40 years, we can derive a useful piece of information—aging "baby boomers" of the
1950s and early 1960s made a last gasp effort to have children prior to the end of
their child-bearing years
...

The census data can then be connected to other seemingly unrelated pieces of information
...

CHAPTER 32

THE ROAD AHEAD

851

in primary and secondary education, the pressure on politicians to hold down taxes
and therefore limit pay increases for teachers
...
Using this knowledge, a business opportunity may emerge
...

The road ahead for software leads toward systems that process knowledge
...
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 information in a way that is practical and
beneficial
...
6

TECHNOLOGY AS A DRIVER
The people who build and use software, the software engineering process that is
applied, and the information that is produced are all affected by advances in hardware and software technology
...
A new hardware technology provides potential
...

The road ahead for hardware technology is likely to progress along two parallel

“The new electronic
independence
recreates the world
in the image of a
global village
...
Along one path, hardware technologies will continue to evolve at a rapid pace
...

But the real changes in hardware technology may occur along another path
...
g
...
Since these nontraditional approaches are not yet mature, it
is difﬁcult to determine which will survive and even more difﬁcult to predict how the
world of software will change to accommodate them
...

Reuse and component-based software engineering (technologies that are not yet
mature) offer the best opportunity for order of magnitude improvements in system
quality and time to market
...
There may be vendors that
build discrete devices (reusable software components), other vendors that build
system components (e
...
, a set of tools for human/computer interaction) and system integrators that provide solutions (products and custom-built systems) for the
end-user
...
But regardless of
how radical the changes are, we can be assured that quality will never lose its importance and that effective analysis and design and competent testing will always have
a place in the development of computer-based systems
...
7

A CONCLUDING COMMENT
It has been 20 years since the ﬁrst edition of this book was written
...
I remember the rejection letters from publishers, who argued (politely, but ﬁrmly) that there
would never be a market for a book on “software engineering
...

Over the past 20 years, this book has changed dramatically—in scope, in size, in
style, and in content
...

An engineering approach to the development of computer software is now conventional wisdom
...
Why, then, are we seeing their
broad adoption only recently?
The answer, I think, lies in the difﬁculty of technology transition and the cultural
change that accompanies it
...

To ease the transition we need many things—an adaptable and sensible software
process, more effective methods, more powerful tools, better acceptance by practitioners and support from managers, and no small dose of education and "advertising
...
In a way, this book is an "advertisement" for the technology
...
Some of the techniques and opinions are controversial; others must be tuned to work well in different software development environments
...

As we begin a new millennium, software has become the most important product and the most important industry on the world stage
...

CHAPTER 32

THE ROAD AHEAD

853

have come a long, long way
...
Let us hope that
the people who meet the challenge—software engineers—will have the wisdom to
develop systems that improve the human condition
...
and C
...
25–41
...
, “What Is Level Six?” IEEE Software, January 1996, pp
...

[HOP90] Hopper, M
...
, "Rattling SABRE, New Ways to Compete on Information,"
Harvard Business Review, May–June 1990
...
, et al
...

[PRE91] Pressman, R
...
, and S
...
Herron, Software Shock, Dorset House, 1991
...
1
...
g
...
List every article or news item that can be used to illustrate the
importance of software
...
2
...
Discuss how people, communication, and process has to
evolve to accommodate the development of “next generation” WebApps
...
3
...
Describe the elements of the environment (hardware, software,
and communications technologies) and their impact on quality and time to market
...
4
...
Do
some research and collect recent papers on the subject
...

32
...
Attempt to develop an example that begins with the collection of raw data and
leads to acquisition of information, then knowledge, and ﬁnally, wisdom
...
6
...

F U R T H E R R E A D I N G S A N D I N F O R M AT I O N S O U R C E S
Books that discuss the road ahead for software and computing span a vast array
of technical, scientific, economic, political, and social issues
...
Dertrouzos and Gates (What Will Be: How the New World
of Information Will Change Our Lives, HarperBusiness, 1998) provide a thoughtful discussion of some of the directions that information technologies may take in the ﬁrst
few decades of this century
...

Negroponte's (Being Digital, Alfred A
...

Kroker and Kroker (Digital Delirium, New World Perspectives, 1997) have edited a
controversial collection of essays, poems, and humor that examines the impact of
digital technologies on people and society
...
Shenk (Data Smog: Surviving
the Information Glut, HarperCollins, 1998) discusses the problems associated with an
“information-infested society” that is suffocating from the volume of information that
information technologies produce
...

For those interested in technical issues, Luryi, Xu, and Zaslavsky (Future Trends in
Microelectronics, Wiley, 1999) have edited a collection of papers on probable directions for computer hardware
...

Kurzweil (The Age of Spiritual Machines, When Computers Exceed Human Intelligence,
Viking/Penguin Books, 1999) argues that, within 20 years, hardware technology will
have the capacity to fully model the human brain
...
Devlin (InfoSense: Turning Information into Knowledge, W
...
Freeman & Co
...
Gleick (Faster: The Acceleration of Just About Everything, Pantheon Books,
2000) discusses the ever-accelerating rate of technological change and its impact on
every aspect of modern life
...

A wide variety of information sources on future trends in computing is available
on the Internet
...
mhhe
...
mhtml

INDEX

Abstraction, 342, 367, 406,
656
Abstraction level, 809
Acceptance tests, 496
Access control, 234
Action path, 380, 392
Activity network, 180
Actors, 280, 581
Adaptable process model,
174
Adaptation, 22, 174
Adaptive maintenance, 23,
805
Aggregate objects, 230, 625
Airlie council, 74
Alpha testing, 496
Analysis, 271, 286
methods, 330
model, 284, 299, 301, 734
principles, 282
for reuse, 734
tools, 830
of WebApps, 778
Anchor points, 39
Antibugging, 486
Application architecture, 253
Application categories, 9
Application generation, 33
Application object, 760
Appraisal costs, 197
Architectural design, 336,
346, 365, 394
c/s systems, 756
metrics, 523, 532
model, 367
quantitative, 376
spectrum analysis, 377
WebApps, 780
Architectural framework,
43
Architectural styles, 371,
375
Architecture, 346, 366, 367,
525, 725
call and return, 372
complexity of, 378
data centered, 371
data-ﬂow, 372
dependencies, 378
iteration, 394
layered, 373
mapping requirements
into, 378
models, 346
object-oriented, 373,
613
organization and
reﬁnement, 374, 389
trade-off, 375
WebApps, 780
Architecture description
language, 347
Associative data object, 308

Attributes, 304, 544, 547,
557, 660
Audit trails, 841
Availability measures, 212
Back-to-back testing, 466
Backtracking, 501
Bang metric, 520, 532
Baselines, 227
Basic objects, 230
Basis path testing, 445, 449
Basis set, 448, 450
Bathtub curve, 7
Behavior model view, 285,
317, 576
Behavioral testing, 459
Beta testing, 496
Black-box, 705
testing, 443, 459
Booch method, 574, 608
Bottom-up integration, 490
Boundary value analysis
(BVA), 465
Bounding, 115, 128
Box diagram, 426
Box structure, 701, 704
BPR, 245, 251, 800–802
hierarchy, 254
tools, 829
Branch testing, 455
Bubble, 310
Builds, 490, 492
Business area analysis, 253
Business, 802
modeling, 32
object, 758
process reengineering,
see BPR
processes, 800
Business system design
(BSD), 253
Call and return
architecture, 372, 385
Capability maturity model
(CMM), 24
Capture/playback, 491, 764
Cardinality, 305, 320, 683
CASE, 12, 825
building blocks, 826
integrated
environments, 833
integration, 827, 834
layers, 834
tools taxonomy, 828
CASE database, 835
CASE repository, 836, 837
special features, 839
Cause elimination, 501
Certiﬁcation, 702, 714
Certiﬁcation teams, 712
Change, 13, 22, 29, 225
Change control, 234–236
Change control authority
(CCA), 234, 236

Change management, 840
Change request, 234
Chaos model, 28
Characterization functions,
727
Check in, 234
Check out, 234
Chief programmer team, 62
Chunking, 424
CK metrics suite, 658
Class collaboration, 646
Class connections, 591
Class diagram, 589
Class hierarchy, 551, 588
test cases for, 641
Class relationships, 587
Class-responsibilitycollaborator models,
see CRC model
Class size, 661
Class testing, 636
Classes, 544, 584, 753
generalization/
specialization, 588
identiﬁcation of, 554
key, 563
metrics for, 658
representation of, 546
support, 563
testing, 636, 644
Classic life cycle, 28
Cleanroom, 43, 699–701
certiﬁcation, 714
design, 706
design reﬁnement, 707
design veriﬁcation, 710
differentiating
characteristics, 703
stepwise reﬁnement, 708
testing teams, 712
veriﬁcation, 707
Clear-box speciﬁcation, 706
Client, 748
Client/server applications,
41
Client/server software, 748
analysis modeling, 755
conﬁgurations, 751
design, 755, 759
engineering, 747
testing, 761, 763, 832
Cluster, 490
Cluster testing, 637
Coad and Yourdon method,
574, 690
COCOMO II model, 133
Code generation, 29, 702
Code restructuring, 808
Cohesion, 324, 353, 526,
527, 657, 661
Collaborations, 587
Collaborator classes, 591
Collaborators, 583

COM, 733, 753, 773
Commercial off-the-shelf
(COTS) components, 722
Common process
framework (CPF), 23, 70
for OO, 560
Communication processes,
756
Comparison testing, 465
Compartmentalization, 169
Completeness, 809
Complexity, 657
Complexity metrics, 529
Component adaptation,
723, 731
Component-based
assembly, 8
Component-based
development, 42, 730,
773
Component-based software
engineering, 121, 721, 723
economics of, 739
process, 724
tools, 739
Component-based systems,
722
Component classiﬁcation,
737
Component composition,
723, 732
Component engineering,
734
Component-level design,
337, 423
Component object model,
see COM
Component qualiﬁcation,
723, 730, 731
Component retrieval
system, 739
Component update, 723
Component wrapping, 731
Components, 126, 371
acquisition of, 122
classiﬁcation of, 735,
737
c/s systems, 750
description of, 622, 724
design of, 623
distributed, 750
metrics for, 526
reusable, 9
Composability, 607
Composite object, 231
Compositional relation, 229
Compound condition, 446,
454
Computer-aided software
engineering, see CASE
Concurrency, 613
Concurrent development
model, 40

855

856

INDEX

Concurrent engineering, 40
Concurrent process model,
40, 41
Concurrent tasks, 613
Condition testing, 454
Condition-transitionconsequence (CTC)
format, 156
Conﬁguration audit, 237
Conﬁguration objects, 229
identiﬁcation, 231
WebApps, 793
Conﬁguration review, 496
Conﬁguration status
reporting, 237
Connection matrix, 453
Connections, 320
Construction and release,
36
Constructive set
speciﬁcation, 683
Content developer, 788
Context-free questions,
116, 274
Context model, 311
Contingency planning, 156
Continuity, 607
Control abstraction, 343
Control chart, 101, 102
Control couple, 761
Control ﬂow, 314, 318, 528
Control ﬂow diagram, 315
Control ﬂow model, 324
Control hierarchy, 347
Control item, 328
Control modules, 348
Control objects, 284
Control process, 314
Control Speciﬁcation
(CSPEC), 302, 315, 325
Controllability, 441
CORBA, 733, 753, 773
Core product, 35
Correction, 22
Corrective maintenance,
805
Correctness, 96, 438, 509,
707
veriﬁcation of, 702, 712
Cost, 740
Cost estimation, 74, 123
Cost performance index,
187
Cost risk, 150
Cost variance, 187
Coupling, 354, 526, 607,
657
metrics for, 528, 661,
663
CRC model, 582, 588, 634
index cards, 583, 635
metrics for, 660
Critical modules, 493
Critical path, 181
Critical path method (CPM),
181
Customer, 271
Customer communication,
36, 71
Customer evaluation, 37
Customer voice table, 280
Cyclomatic complexity, 446,
448, 449, 493, 529

Data, 850
Data abstraction, 342, 546,
368
Data architecture, 252
Data-centered architecture,
371
Data condition, 315
Data couple, 761
Data design, 336, 367, 369
Data dictionary, 301, 312,
328, 329, 370
Data exchange model, 732
Data ﬂow, 379, 528
Data-ﬂow architecture, 372
Data ﬂow diagram, 31, 302,
315, 321, 379, 381, 518
Data ﬂow model, 321, 462
Data ﬂow testing, 456
Data invariant, 677, 681, 688
Data items, 310
Data management
component, 615
Data mining, 368
Data model, 284, 305
Data modeling, 32, 302, 368
Data network, 302
Data object, 284, 303, 308,
310, 328, 342, 623
Data relationships, see
Relationships
Data restructuring, 808
Data structure, 349, 350,
368, 811
Data structured systems
development (DSSD), 330
Data warehouse, 368, 369
Database, 247
Database design, c/s
systems, 758
Database management,
tools, 830
Database object, 760
Database structure, 812
Debugging, 499–502
Decision table, 428
Decision tree, 137
Decision tree analysis, 137
Decomposability, 441, 607
Decomposition, 67, 119,
124, 127
Defect ampliﬁcation, 204
Defect removal efﬁciency,
98, 105, 187
Defect tracking, 74, 98, 188,
209, 445
cost of, 203
Deﬁciency list, 495
Deﬁnition phase, 22
Deﬁnition-use chain, 457
Degree of structural
uncertainty, 114
Dependency tracking, 840
Depth, structure, 347
Design, 29, 335–339
component level, 423
principles of, 340
for reuse, 734
test cases, 443
tools, 830
Design concepts, 341
Design heuristics, 355
Design iteration, 386
Design mapping, 385, 386

Design model, 340, 357
Design notation, 432
graphical, 425
tabular, 427
text-based, 429
Design patterns, 371, 375,
605, 624, 625, 779, 783
Design process, 338
Design review, 395
Design selection index,
377
Design Speciﬁcation, 228,
358, 386
Design structure quality
index, 525
Detection device, 215, 216
Development environment,
120
Development phase, 22
Directionality, 809
Distributed subsystems,
752
Do-while, 425
Document restructuring,
807
Documentation, 14, 247, 830
Domain analysis, 576–578,
740
process, 726
Domain architecture, 740
Domain characteristics, 728
Domain engineering, 579,
725
Domain language, 726
Domain objects, 605
Domain testing, 455
Driver, 487, 490
Dynamic analysis, 832
Earned value analysis, 74,
186
Efﬁciency, 510, 513
Effort
distribution, for
software projects, 172
estimate, 123, 124
relationship, 171
Effort validation, 169
Elaboration, 67, 343
Empirical estimation, 124
Encapsulation, 548, 550,
655
Engineering, 36
Engineering change order
(ECO), 234
Enhancement, 23, 805
Entity relation diagram
(ERD), 301, 307, 319
Entry point multiplier, 176
Environment model view,
576
Equivalence class, 464
Equivalence partitioning,
463, 464
Error detection, 203
Error index, 210
Error messages, 414
Error tracking, 187
Errors, 98, 187
Essential view, 288
Estimates, 114, 115
accuracy of, 124
three-point, 125
Estimation, 123, 128, 131

decomposition
techniques, 126
empirical, 124, 132
FP-based, 126, 129
LOC-based, 126, 128
object-oriented projects,
564
problem based, 126
process-based, 130
WebApps, 791
Estimation models, 132
Estimation risk, 114
Estimation table, 131
Estimation tools, 124, 139
Estimation variables, 127
Event ﬂow, 314
Event trace model, 597
Events, rules for
determining, 325
Evolution graph, 231
Evolutionary process
model, 34, 37, 179
Expected cost, 138
Expected value, 125, 127
External entity, 263, 310, 554
External failure costs, 197
Facilitated application
specification techniques
(FAST), 117, 275–277,
289
consensus list, 278
Factoring, 349, 385–386
Failure, deﬁnition of, 212
Failure costs, 197
Failure curves, 8
Failure intensity, 483
Failure mode analysis, 197
Fan-in, 347, 355, 524
Fan-out, 347, 355, 524
Fat client, 751
Fat server, 750
Fault, 203, 639
Fault-based testing, 639
Fault tree analysis, 214
Feasibility, 117
Feature points, 91
Finger-pointing, 497
Finite state modeling, 462
First law of system
engineering, 226
Fishbone diagram, 85
Flexibility, 510
Flow boundaries, 383
Flow graphs, 445, 449
compound conditions,
446
nodes, 446
notation, 446
Flow model, 310
Flowchart, 425
Formal design, 702
Formal methods, 673–677
concerns about, 44
future directions, 694
mathematical notation,
687
mathematical
preliminaries, 682
operations, 678, 681
state, 678
ten commandments of,
693
Formal methods model, 43

857

INDEX

Formal speciﬁcation
language, 689
Formal technical review,
14, 64, 197, 205, 237, 484,
see also Review
OO models, 635
user interface, 417
Formulation, 776
Forward engineering, 808,
814
c/s systems, 816
object-oriented
systems, 817
user interfaces, 818
Fourth generation
techniques (4GT), 44–45,
290
40-20-40 rule, 172
Framework, 23
Framework activities, 69
Function deployment, 279
Function points, 89
complexity adjustment
values, 91
computation of, 90, 519
estimation, 562
extended metrics, 91
pros and cons, 93
Function speciﬁcation, 703
Functional decomposition,
68
Functional independence,
352
Functional model, 285, 309,
310
Functionality, 512, 513
Fundamental system
model, 311, 379, 392
FURPS, 511
Gantt chart, 182
Glass-box testing, 444
Golden rules
interface design, 402
WebApp design, 779
Grammatical parse, 322
Graph matrix, 452
Graph notation, 461
Graphs, symmetry of, 463
GUI, see Interface entries
Hardware, 247
Hazard analysis, 159
Hazards, 213
Help facility, 413, 414
Hiding, 351
Horizontal decomposition,
287
HTML, 774
Human resources, 60
I-CASE, 836, see also CASE
Identiﬁcation, 237
If-then-else, 425
Implementation, 618
model view, 576
view, 288
Increment planning, 701
Incremental development,
168
Incremental model, 35
Independent path, 446
Independent test group
(ITG), 480
Indexing methods, 736
Indexing vocabularies, 736

Information context, 284
Information deployment,
279
Information determinacy, 9
Information domain, 90,
127, 283, 321
Information ﬂow, 284, 309,
311
Information hiding, 351,
655
Information strategy
planning (ISP), 253
Inheritance, 550, 656, 662
metrics for, 665
multiple, 551
Initial operational
capability, 39
Input, 249
Inspections, 206, see also
Formal technical review
Instance, 544
Integrated CASE
environment, 827, see
also CASE
Integration testing, 481,
488, 493
documentation, 494
OO software, 637, 640
strategies, 489
Integrity, 97, 510
Interaction modes, 403
Interdependency, 169
Interface actions, 408, 411
Interface constraints, 403
Interface description
language, 753
Interface design, 337, 401,
408, see also User
interface design
activities, 410
tools, 831
WebApps, 785
Interface design model, 405
Interface objects, 401, 410,
760
Interfaces, 621, 530
Internet standards, 774
Interoperability, 510
Intersubsystem
communication, 616
Inventory analysis, 806
ISO 9000 standard, 201,
216, 217
Jackson System
Development (JSD), 330
Jacobson method, 574, 609
Javabean components, 733,
753, 773
Kaizen, 199
Key classes, 563
Key indicators, 26
Key practices, 26
Key process area (KPA), 21,
25
Knowledge, 850
Knowledge discovery, 368
Lateness, comment on, 167
Layered architecture, 373
Layering, 612, 613
Layout appropriateness, 530
Legacy programs, 23
Level of abstraction, 676
Life cycle architecture, 39

Life cycle objectives, 39
Linear sequential model,
28, 30, 34
Lines of code, (LOC), 88
Linguistic modular units,
607
Link weight, 452
Localization, 655
Logical constructs, 424
Loop constructs, 425
Loop testing, 458
Loops, types of, 458
Lower natural process
limit, 102
Maintainability, 96, 510,
513
Maintenance, 805
metrics for, 533
request, 815
Make/buy decision, 136
Mean-time-to-change
(MTTC), 97
Mean-time-between-failure
(MTBF), 212
Measurement, 79, 80, 87,
507, 515
Measures, 80, 87
LOC and FP, 94
Messages, 548–549
protocol description,
619
Meta-questions, 275
Methods, 21, 545, see also
Operations
metrics for, 660
Metrics, 74, 80, 507, 516
analysis model, 517
architectural design,
523
collection of, 100
complexity, 524, 529
design model, 523
encapsulation, 664
error tracking, 188
framework for, 514
function oriented, 89,
518, 532
GUIs, 530
inheritance, 665
integration of, 98
maintenance, 533
OO projects, 665
OO software, 653
OOD, 658
OOT, 664
operations, 664
productivity, 126
reconciling, 94
reuse, 741
size-oriented, 88, 89
small organizations,
104
software components,
526
software metrics, 79
software quality, 95, 510
source code, 531
speciﬁcation quality,
522
technical, 516
testing, 532
tools, 829
Metrics baseline, 100

Metrics computation, 100
Metrics evaluation, 100
Metrics guidelines, 105
Metrics variation, 100
Middleware, 753
Milestones, 57
OO projects, 565
Mini-speciﬁcations, 278
Modality, 306, 320
Modularity, 343, 352
effective, 345
guidelines, 355
Module interconnection
language, 231
Module size, 345
Modules, 343
cost of, 344
complexity of, 344
subordinate, 348
superordinate, 348
MOOD metrics suite, 662
Morphology, 524
Multiple class testing, 645
Multiple instances, 313
Nassi-Shneiderman charts,
426
Navigation design, 783
Navigation nodes, 784
Negotiation, 38, 276
90-90 rule, 72
Object, 544–545, 703
generic life history, 559
selection criteria, 556
Object adapter, 754
Object-behavior model,
594, 613
Object deﬁnition, 559
Object descriptions, 618
Object design, 618
algorithms, 619
data structures, 619
Object life history, 581
Object management layer,
835
Object model, 553, 732
testing of, 636
Object modeling technique,
574, 608
Object-oriented (OO), 542,
544
contract, 565
estimation, 562, 564
milestones, 565
process model, 543
project management,
560
project metrics, 562
scheduling, 564
tracking projects, 565
Object-oriented
architecture, 373
Object-oriented metrics,
653–654
Lorenz and Kidd, 661
MOOD suite, 662
Object-oriented paradigm,
542
Object-oriented
programming (OOP), 625
Object-oriented projects,
560
Object-oriented software,
656

858

INDEX

Object point, 134
Object pool, 233
Object-relationship model,
591, 593
testing of, 634
Object/relationship pairs,
320
Object request broker
(ORB), 753
Observability, 441
OOA (object-oriented
analysis), 571, 574
vs
...
conventional
approaches, 605
data management, 611
design issues, 607
generic steps, 609
layers of, 604
mapping to OOA, 606
methods, 608
object design, 618
pyramid, 604
system design process,
611
OOD model, 632–634
OOT (object-oriented
testing), 631, 638
behavior models, 647
deep structure, 643
impact of OOP, 640
interclass, 645
metrics for, 664
partition testing, 644
random testing, 644
state-based partitioning,
645
strategy, 636
surface structure, 643
thread-based, 637
Operability, 441
Operations, 545, 548, 558,
620, 623, see also
Methods
metrics for, 660, 664
testing issues, 636
Orthogonal array, 466
Outsourcing, 13, 138
Outsourcing vendors, 791
Overloading, 553

Overriding, 551
Package references, 592
Packages, 590
Pareto principle, 209, 440
Partition testing, 644–645
Partitioning, 67, 286, 612
horizontal, 287, 348
vertical, 288, 349
Pathological connection,
357
Pattern of usage, 762
Patterns, 371, 375, see also
Design patterns
People, 170, 247
communication issues,
65
roles of, 58
People/work relationships,
171
Perfective maintenance, 23
Performance, 512
Performance risk, 150
Performance testing, 498
Personal software process
(PSP), 83
PERT, 181
Petri net models, 214
Phase index, 211
Planning, 36
Poka-yoke, 214
Polymorphism, 552
metrics for, 663
Portability, 510, 513
Portability services, 827
Postcondition, 678, 682
Postmortem analysis, 73
Precondition, 678, 682
Predicate, 683
Predicate node, 446
Presentation protocol, 834
Prevention device, 215, 216
Preventive maintenance, 23
Private process data, 83
PRO/SIM, tools, 831
Problem decomposition, 67
Problem solving, 59
Procedural abstraction, 342
Procedural design, 423
Procedures, 247
Process, 20, 46, 57, 310, see
also Software process
adaptation criteria, 174
evolutionary model, 179
generic phases, 68
object-oriented, 543
Process activation table,
315, 327
Process decomposition, 70
Process evaluation, for
BPR, 803
Process identiﬁcation, for
BPR, 802
Process indicators, 82
Process layer, 21
Process maturity, 24
Process metrics, 82, 101
Process model, 26
CBSE, 725
interface design, 407
object-oriented, 543
selecting, 68
Process modeling, 33, 829

Process speciﬁcation
(PSPEC), 302, 312,
327–328
for BPR, 803
Process technology, 46
Processing narrative, 322,
557, 623
Producer, 206
Product, 46, 57, 67, see also
Software
Product engineering, 254255
Productivity, 740
Productivity metrics, 94,
126
Program components, 621
Program design language,
327, 429, 430, 622
Program graph, 445
Program structure, 385,
392, 351
terminology, 347
Programming, tools, 831
Progress, tracking of, 72
Project, 57, 71
avoiding problems, 72
constraints, 120
danger signs, 71
degree of rigor, 173
function, 119
performance, 120
reasons for failure, 65
Project coordination, 66
Project complexity, 114
Project database, 228
Project entry point, 37
Project indicators, 82
Project library, 228
Project management, 75
critical practices, 74
four Ps, 56
object-oriented, 560
tools, 829
WebE, 787, 789
Project metrics, 86–87
Project planning, 115
tools, 829
Project resources, 120–122
Project risks, 147, 149
Project scheduling, 165
Project size, 114
Project tables, 182
Project tracking, 165
Proof of correctness, 709
Protection, 607
Protocol description, 618
Protocols, 609
Prototype, 31, 289
Prototyping
BPR, 803
environments, 291
evolutionary, 289
problems with, 32
tools, 290, 831
throwaway, 289
Prototyping methods, 290
Prototyping model, 30
Prototyping paradigm, 30,
289
Pseudocode, 429
Public metrics, 84
Quality, 195, 739

conformance, 195
cost of, 196, 197
design, 195
deviations, 202
quantitative view, 513
Quality assurance, 196, 200
tools, 830
Quality concepts, 194
Quality control, 194, 196
Quality costs, 197
Quality factors, 95, 341
ISO 9126, 513
McCall, 509
Quality ﬁlter, 14
Quality function
development (QFD), 279,
289
Quality measurement, 96
Random testing, 644
Rapid application
development (RAD), 32,
34
Real time logic, 214
Recorder, 206
Recovery testing, 497
Recursive/parallel model,
560–561
Reengineering, 799
economics of, 819
process model, 805
tools, 832
Referent point, 155
Reﬁnement, 343
for BPR, 803
Regression testing, 491
Relationships, derivation
of, 592
Reliability, 509, 512, 513
measures, 212
Repeat-until, 425
Repository, 836
Requirements, types of, 279
Requirements analysis,
258, 272
Requirements database, 261
Requirements elicitation,
256, 274, 280
steps, 257
work products, 257
Requirements engineering,
255, 256
guiding principles, 283
steps, 256
Requirements gathering, 701
interfaces, 402
Requirements
management, 261
Requirements model, 556
Requirements negotiation,
259
Requirements review, 260
Requirements speciﬁcation,
259
Requirements tracing,
tools, 829, 841
Requirements validation,
260
Resource management
component, 616
Responsibilities, 583
allocation of, 585
identifying, 584

859

INDEX

Restructuring, 813
code, 814
data, 814
Reusability, 43, 510
Reusable components, 722,
736
categorization of, 726
identiﬁcation of, 727
Reusable software
components, 290
Reuse, 551, 577, 721, 734
cost, 740
environment, 738
leverage, 742
library, 739
metrics, 741
Reverse engineering, 807,
809
of data, 811
of processing, 810
of user interfaces, 812
Review, 206–208 see also
Formal technical review
issues list, 207
leader, 206
meeting, 206
reporting, 207
summary report, 207
Rework, 197
Risk analysis, 36, 145
tools, 829
Risk assessment, 154
Risk components and
drivers, 148
Risk driver, 150
Risk estimation, 151
Risk exposure, 153
Risk identiﬁcation, 148
Risk impact, 151
Risk information sheet, 159
Risk item checklist, 148
Risk management, 74, 157
strategies, 146
Risk mitigation, 156
Risk Mitigation, Monitoring,
and Management Plan,
153, 159
Risk monitoring, 157
Risk planning, 153
Risk probability, 151
Risk projection, 151
Risk referent level, 154
Risk reﬁnement, 156
Risk table, 151
Risks, 146, 148
business related, 147
hazards, 158
management concern,
152
safety, 158
technical, 147
Round robin reviews, 206
Rumbaugh method, 574,
608
SafeHome, 277, 281, 286,
320, 322, 325, 329, 380,
411, 518, 555, 581, 587,
594, 614, 619, 622, 713,
729, 777
Sandwich testing, 493
Scalability, of WebApps,
793

Scenario-based testing, 641
Scenario script, 563
Schedule estimation, 74
Schedule performance
index, 187
Schedule risk, 150
Schedule variance, 187
Scheduling, 168, 181, 792
milestones, 170
object-oriented projects,
564
outcomes, 170
responsibilities, 169
tracking of, 185
Schemas, 690
SCM, 225, 230, 841
standards, 238
tools, 232
resources, 231
tools, 830
WebApps, 792
Scope, 57, 67, 68
Scope of control, 356
Scope of effect, 356
Screen layout, 411
Security, 97, 774
Security testing, 497
Semantic domain, 689
Semantic navigation unit
(SMU), 784
Sensitivity testing, 498
Sequence construct, 425
Server, 748–749
Services, 545, see also
Methods; Operations
Sets, 683
logical operators, 686
operators, 684
sequences, 686
SGML, 774
Shared repository layer,
835
Simplicity, 441
Size, 656
Size-oriented metrics, for
OO software, 661
Smoke testing, 492–493
Software, 6, 9
deterioration of, 8
history of, 5
importance of, 846
impact of, 4
project characteristics,
65
role of, 4
scope of change, 847
Software architecture, 346,
366, 725, see also
Architecture
Software components, 8,
42, 120, 367, see also
Components
user interface, 415
Software conﬁguation, 14,
226
items, 226, 228, see also
Conﬁguration objects
management, see CSM
Software crisis, 11
Software engineering, 4, 20
c/s systems, 755
environment, 122

generic view, 21
mathematics, 676
methods, deﬁciencies,
675
paradigm, 26, 68
road ahead, 845
tasks, 177, see also
Tasks
work tasks, 69
Software Engineering
Institute (SEI), 24, 105
Software equation, 135,
171
Software librarian, 62
Software maintenance,
804, see also Maintenance
Software maturity index,
99, 533
Software myths, 12
Software procedure, 351
Software process, 20, see
also Process
improvement, 82
models, 26, 64, 848
Software project(s)
estimation, 123
failure of, 57
gathering requirements,
11
lateness, 166
management, 55
planning, 113, see also
Project planning
scheduling, see
Scheduling
Software Project Plan, 198,
226
Software prototyping, 289,
see also Prototyping
Software quality, 199, 338,
508
metrics, 95
Software quality assurance,
24, 199, 479, see also
Quality assurance
activities, 201
audits, 202
formal approaches to,
209
group, 200
plan, 201
SQA Plan, 201, 218
Software reengineering,
804, see also
Reengineering
Software reliability, 212,
483, see also Reliability
Software repository, 228
Software requirements, 13,
292
analysis, 29, 272, see
also Requirements
analysis
engineering, 271
Software Requirements
Speciﬁcation, 293, 226,
327, 381, 495
Software reuse, 9, 43, see
also Reuse
Software reviews, 202, see
also Formal technical
review

Software risks, 146, see also
Risks
Software safety, 159
Software science, 531
Software scope, 67, 115,
118, see also Scope
Software sizing, 124
Software team, 60, 170, see
also Teams
Software testing, 437, see
also Testing
Software safety, 213
Source code, metrics, 531
Span of control, 347
Speciﬁcation, 291
Speciﬁcation language, 689
Speciﬁcation principles, 291
Speciﬁcation review, 294
Spiral model, 36, 38
Spoilage, 97
Stability, 442
Stakeholders, 275
Standards, 12
State-based models, 596
State-box speciﬁcation, 705
State diagram, 613
State model, 648
State transition diagram
(STD), 302, 317, 318, 325
Statement of scope, 68, 557
States, types of, 595
Static analysis, tools, 832
Statistical modeling, 483
Statistical process control,
100
Statistical quality
assurance, 209
Statistical software process
improvement (SSPI), 84
Statistical use testing, 702,
712
Status accounting, 237
Stepwise elaboration, 409
Stepwise reﬁnement, 343
Stress testing, 498
Structural complexity
metric, 524
Structural model view, 576
Structural modeling, 728
Structural partitioning, 348
Structure points, 725, 728,
729
cost analysis, 741
Structured analysis, 299,
300, 310
Hatley and Pirbhai
extensions, 315
mechanics, 319
real time extensions, 312
Ward and Mellor
extensions, 312
Structured analysis and
design technique (SADT),
330
Structured constructs, 424,
426
Structured design, 379
Structured English, 429
Structured programming,
339, 424, 706
Structured query language
(SQL), 749

860

INDEX

Structured retroﬁt, 815
Structures, 588
Stubs, 487
Style, see Architectural style
Subclass, 547
Subﬂow, 382
Subjects, deﬁnition of, 590
Subproofs, 709
Subsystem collaboration
table, 617
Subsystems, 563, 590, 612
allocation of, 613
communication, 612,
616
Superclass, 547, 551
Support, 29
Support classes, 563
Support phase, 22
Support risk, 150
Supportability, 513
Symbol table, 677
Synchronization control,
234
Syntactic domain, 689
System, 246
complexity, 524
component
engineering, 255
components, 249
constraints, 250
domains, 249
elements, 249
engineer, 249
world view, 248
System context diagram
(SCD), 262
System design, activities,
611
System engineer, 264
System engineering, 245
hierarchy, 248
System ﬂow diagram, 264
System image, 405
System information
engineering, 28
System model, 262
restraining factors, 249
System modeling, 249, 259,
262
System perception, 405
System response time, 413
System simulation, 251
System software, tools, 830
System Speciﬁcation, 120,
128, 259, 226, 265, 381
System testing, 481, 496
Task analysis, 408
Task deployment, 279
Task management
component, 614
Task modeling, steps, 409
Task network, 180, 181
Task regions, 36
Task set, 23, 37, 172
Task set selector
computation of, 175
interpretation of, 176
Task template, 614
Tasks, 57, 614
major, 177
reﬁnement of, 178
Team leaders, 59

Team organization, 60, 63
Teams, 61
jelled, 63
organizational
paradigms, 62
toxic, 63
Technology infrastructure,
253
Templates, 779
Test cases, 442, 443, 449
Test coverage, 467
Test management, tools, 832
Test Speciﬁcation, 494
Testability, 440, 510
Testing, 29, 197
alpha and beta, 496
behavioral methods,
462
big-bang, 488
black-box methods, 459
boundary value
analysis, 465
c/s architectures, 469
c/s systems, 762
completion criteria, 482
control structure, 454
data ﬂow, 456
document and help
facilities, 469
equivalence
partitioning, 463
fundamentals, 438
graph-based, 460
GUIs, 469
integration, 488
logical conditions, 454
loops, 458
metrics for, 532
object-oriented, 631,
638
objective of, 439
organizational issues,
479
orthogonal array, 466
principles of, 439
real-time systems, 470
regression, 491
schedule, 494
specialized
environments, 468
strategic issues, 484
strategies for, 477
system-level, 496
thread based, 637
tools, 831
WebApps, 786
white-box methods, 444
Thin client, 751
3D function point, 92
Time allocation, 169
Time-boxing, 185
Time-continuous data ﬂow,
313
Timeline charts, 182
Timing modeling, 462
Tools, 12, see also CASE
management services,
835
Top-down integration, 488
Total quality management
(TQM), 199
Traceability tables, 261

Transaction, 380
Transaction center, 380,
392
Transaction ﬂow, 380
modeling, 462
Transaction mapping, 389,
390, 393
Transform, 310
Transform center, 379, 383
Transform ﬂow, 379
Transform mapping,
380–381
Umbrella activities, 23, 37,
57
UML, 43, 575
notation, 581
object design, 610
system design, 610
views, 576
Understandability, 442, 607
Uniﬁed development
process, 43
Uniﬁed modeling language,
see UML
Unit testing, 481
common errors found,
486
considerations, 485
OO software, 636
procedures, 487
Upper natural process limit
(UNPL), 102
Usability, 97, 510, 512, 513
Usage scenarios, 259, 280,
615, 713, 762, see also
Use-case
Use-case, 54, 280, 289, 375,
581, 615, 636
diagram, 581
examples of, 281, 642
User interface
component, 615
consistency of, 405
design, see User
interface design
development systems,
415
layout of, 404
prototype, 408, 416
toolkit, 415
User interface design, 401,
see also Interface design
evaluation, 416
golden rules, 402
issues, 413
model, 405
principles of, 403
process model, 407
requirements gathering,
402
reviews, 417
User model, 405
User model view, 576
User satisfaction, 196
Users, 406
memory load, 404
types of, 406
Validation, 479
Validation criteria, 278,
293, 495, 481, 495
Validation testing
criteria, 495

OO software, 637
Value analysis, 279
Variant, 233
Variation between samples,
194
Variation control, 194
Veriﬁcation, 479
Version control, 232
automated approaches,
233
Versioning, 840
Versions, 232
Vital few causes, 209
Walkthroughs, 206
Waterfall model, 28
Ways of navigation, 784
Wear, 7
Web-based applications,
see WebApps
Web engineer, 779, 788
Web engineering, see WebE
Web publisher, 788
WebApps, 771
architecture of, 780
categories, 772
characteristics of, 772
cost estimates, 791
design patterns, 783
quality attributes, 773
structures, 780
WebE, 769, 770
activities, 775
administrator, 789
analysis, 778
design, 779
development schedule,
792
formulation, 776
interface design, 785
management issues,
787
navigation design, 783
outsourcing, 791
politics of, 793
project management
guidelines, 790
SCM issues, 792
support specialist, 789
teams, 788
testing, 786
tools, 831
WebE process model, 775
W5HH principle, 73
Where-used/how used,
329
White-box testing, 444
Width, structure, 347
WINWIN spiral model, 38
Wirfs-Brock method, 574,
609
Work breakdown structure
(WBS), 181
Work products, 57
Work tasks, 69
XML, 774
Z notation, summary of,
691
Z speciﬁcation language,
690, 692
Zero quality control, 215
Zone rules, 103

Title: software engineering
Description: full notes on software engineering

Buy These Notes Preview

Notesale: Turn your study into money

Already a Member? >

Search for notes by fellow students, in your own course and all over the country.

My Basket

Document Preview