Software Engineering: Modern Approaches

Brief Contents Prefa C X IV Acknowledgmen ls Part I Part II •• XVII Introduction to Software Engineering Software ...

Author: Eric J. Braude | Michael E. Bernstein

1865 downloads 7639 Views 147MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Brief Contents

Prefa C X IV Acknowledgmen ls Part I

Part II

••

XVII

Introduction to Software Engineering Software Process

I TI, e Coa ls and T e rm ino logy o f Software Eng ineering

I

2 Inlroduclio n lO Q uality and Metrics in Software Engi nee ring 21

3 4 5 6

So ftware Process 32 Ag il e Software Processes 63 Q ualilY in the So ftwa re Process 80 So ftware Co nfig uratio n Manageme nt

120

Part 111

Project Management

7 Princi pl es o f So ftware Project Management I 140 8 Princ iples o f Software Projec t Management II 168 9 Q uality and M e trics in Projec t Manageme nt 21 3

Part IV

Requirement Analysis

10 Principles of Require me nts Anal ysis 2 30 I I Analyzing Hi gh -Level Requ irements 245 12 Analyzi ng De tail ed Requirements 278 13 Q uality and Metrics in Require me nts Analysis 331 14 Formal and Eme rg ing Me thod in Requireme nts AnalysiS (O nline chapte r) 349

Part V

Software Design

15 16 17 18 19 20 21

PaTt VI

Implementation

Part VII

Testing and Maintenance

22 Pri ncip les of Im p leme ntallo n 539 23 Q uality and Metrics in Imple me ntation 58 4 24 Rcfacloring 60 I ~--~----------------25 Inlroduc tl o n lO oftware T esting 62 1 26 Unit T e ting 630 27 Mo dule and Integratio n T esting 666 28 T e
C lossary 759 Index 767

Princ iples of So ftware Desig n 350 The Uni fie d Model ing Language 36 1 Softwa re Desig n Patterns 383 Softwa re Arch itecture 438 Detai led Design 476 Design Q uality a nd Metrics 508 Adva nced and Eme rgi ng Me tho ds in Software Design (O nline c ha pler) 538

Contents

Preface .

.

.

.

. .

. . . . . .. .. . . - .. .. ... .. . - . ........ ... .. .. . . .... .... . . • • • • The Issue of Scale . . • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • This Edition Compared with the First . .. . . .• . . .. ... . . . . . . . . . . . . . . . . . . . How Instructors Can Use This Book . . . . . . . . . . . .• . . . . . . . . . . . . . . . . .. ' "

..

•

XIV •

XIV •

XIV

.

Acknowledgments . ... _ . _ .. .

PART I

•

•

•

•

•

•

•

•

•

•

•

•

• •

•

• • • • •

•

•

•

xv

..

• •

•

• •

•

•

•

• • •

•

•

•

• •

•

•

•

XVlI

• • • •

Introduction to Software Engineering

I The Coals and Terminology of Software Engineering

1. 1

1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9

. . ... _ _ . . . . . .. .. . . .. . . _ .. What is Software Engineering ... .. . . . . . . . . . . _ . . . . . . . . . . . . . . . . . . . . . . . . . . Why Software Engineering Is Critical, So ftware Disaster ..... . . . ... ....•. . .. Why Software Fails or Succeeds .. . . .. .. . . . . . . . . . .. . . . . . . . . . _ . .. . ..•... Software Engineering Activities . . . . . . . . . . . . . .. .. . . . .... • • • • • • • • • • • Software Engineering Principles . . .. ... .. . . . . . . . . . . .' - . • • • • • • • • • • • Ethics In Software Engineering . ... . . . . . . . . .. ... . .. . • • • • • • • • • • • • • • • • • • • • Case Studies ..... . ..... . ... . . . . . . . . . . .. . • • • • • • • Sun'lmary

. ... . . . .. ... . . . . . . . - . . . . . . . . . . . . . . . . . . . ..

. ..... .

•

Exercises . . . . . . . . . . . . . ......... . . . . . . . . . . . . . . .. . ..... ,. Bibliography . . ... . . . . . . . . . . .. ,.. .. .... . . . . . . . . . . . . . . . . .

•

•

•••

•

•

•

••

2 Introduction to Quality and Metrics in Software Engineering . . . . . .. .. .. • . . .. • • 2. 1 The Meaning of Software Quality . .. . . . . . . . . . . .. . . . . . . . . . .•. • • • • • • 2.2 Defec ts in Softwa re . . . .... . .. . ... .. . . . . . . . . .. .. • • 2.3 Ve n~call o n and Validati o n . . . .. . ......... . . . . . .. ....... . 24 Planning for Qua lity . . . . . . . . . . . •. .. ..... . . . . . . ...... . • • • • 25 Metrics .... , ................ . . . . . . . . . . . . . .

26 27

PART II

lImm ary ., Exercises . . Bibl iogra phy .

•

••

•

•

• •

•

•

•

•

.,

......

..

•

•

• •

•

••

••

• ••

••

••

. . ..

••••

•

•

•

•

•

•

••

•

•••••

•

•

•••

••••••

,

•

• • •

•

••

••

•

•

••

•

•

•

•

•

•

2 3 4

5 10 12 14

19 19

20 21

•

12 23

25

• •

•

I

27 28 30 , 1

•1

Software Process

• • • 3 So!twar~ Process Ac tl vltl c' o f o(twar I'rocc~, • 3. I o(twarc: Pro css Models 32 • tud y S tud nt Team CUldanLc a,>~ 33

•

•

n,e

•

•

•

•

•

•

•

•

•

• •

•

•

• •

•

•

•

•

•

•

•

•

• • • •

•

•

• •

•

32 ,

, ,;,-

CONTENTS

.4

llfll lll o1f)f

E~Crc I 5c.:S

.......

•.. , •.

BIbliography .

.

. ..•........

.

••

..,

., .

.

•

• • •

. ............. .

'

.

• •

•

•

••

•

•

• • •

• •

•

••• ••• •••••••••• •

•

•

•

• •

......... ....

•

• • •

,'.

••

••

,

••••

••••••••

........ .. .

.

4 Agile Software Processes

4. 1

. . . . . . . . . . . . . . . • . . . . . .. ..•. .. .. ... .. . ., Agil e H i>tory and Agi le Manifesto , . . . • . . . . . • . . . , . . . . . . . . . . . . . . . . . .•. .

4.2 4.3 4 .4

Agile Princi ples .... , . . . . . . . . . . . . . . " . . . . . . .. . .. , . . . . . . . . . . . . . . . Agi le j\~clh o ds . . . . . .. .... .. . .......... . . .. . ......... ........... . Agi le Proces c:s .. , . .. . . . . . . . . . . . . . . ,.. . . . . . . . . . . . . . . . . . . . . . . .

4.5

Integrating Ag ile with No n.Agil e Proce es

4.6

umnlary

4 .7

Exerci ses

. . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

., . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,'

. . . ............................... .

63 64 65 66

68 74

n

.

78

. . . . . . . . . . . .... . . . . . . . . . . , . . . . . . . . . . . . . . . . . . .

79

5 Quality in th.e Software Process ..... . . . . . . . . . . . . . . , .. , . .... , . .. . . . . . . . . . . . . 5. 1 Principles o f Managing Quelity ... . .. , .. , ..•.... .. . . . . . . • . . • . . . . . . • . . • . . 5 ,2 Managin g Qua lity in Agile Processes .. . ..•. . . , . , , .. , ... , .. , .•.. , . . . . .. ..

80 81 82 83 87 92 93

Bibliograph y .....

..

. ........ . ...... . .................

59 60 62

5.3

Quality Planning . . . . . . . . . .. .. . . . . • . . . . . . . . .•.. . . .. . . . • . . . . . . . . .. . . .

54 5.5 5.6 5.7

Inspecti o ns .... .. .

5.8 5.9 5. I 0 5. I I

• •

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

• •

•

•

•

•

•

•

•

•

•

• • •

•

•

•

•

• •

•

•

•

•

•

• •

•

•

QA Reviews and Audits . . . . . . . . . . . . . . . .. . . . . . ... . . . . . . .. . ... . . . . . . . . . Defect j\1\anagenlent . . . . . .. ., .. . .... ... . . . . . •... , ...•.•. .. . . . . . . . . . .

Process Improvement and Process Metrics . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 96 O rga nizati o n. Level Q uality and the CMMI . . . . . . . . . . . . . . . . . . . , . . . • . . . . . . . 100 ease S tudy, Software Quality Assurance Plan for Encounter .. . . , .. . . • . ... . ..... 103 1 18 Summary . . . . . . , . . . . . . . . . . . . ... . . . . . . . . . . . . . .. . . . . . .......... . . . . I 18 Exercises . . . . . . . . . . . . . . . . . . . . . .. .. . . ... . . . . . . .. . . . . . . . . ' ... . . . . . . 11 9 Bibliograph y . . . . . . . ... , . . . . . . .. . . . . . , . .. ... . . . . . . . . . ... ... . .. . ' ..

6 Software Configuration Management . . . . . . . . . . . . . . . . . . .• .... . , ... .... ,...... 6, I Software Co nfiguration Management Goa ls . . . . . . . , ... . ...• . . . ,... . .. ... .. 6.2 SCM Activi ti es .. . . . . . . . . . . . . .. . ...... . . . .... . .. .. . . . . . . . ,.. . .... 6. 3 Co nfigu ra tio n Managemen t Pla ns ....• .... ... .. . . . . . . . . . . • . • . . . . . . . . . . . 6.4 Configura tion Management Systems ..... . .. . . . . , .... . •. , . ...•... . . . •. , . . 6.5 Case S tud y, Encounter Video Game ... , . . ... " .. . . ,. . . .. .. . .... ... ....

120 121 121 128 128 129

6 .6

Case Study : Eclipse . . . . . . ..

. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . ... . ...

134

6.7

Stude nt Team Guidance , Configu ration Management ...... .. , .... . . . . . . . . , . . .

136

6 .8

S ummary

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . .. ... . ,

137

6.9

Exercises ...... . Bibliography .. .

. . .. ........ . .. ....... . . . . .,.......... . .... . ... •••••

138 139

7 Principles of Software Project Management I, Organization. Tools. and Risk Man.g~ment , . 7. l oft-ware Project Orga nozatio n , . .. .. , . . , . . . . . . . , . . . . . . . . . . . . . . . . . ...

140 141

PART III

•

•

• • • • • • • • • • •

••

• • • • • • • • • • • • •• • •

• ••

••••••

Project Management

7 .2

Team S ize

. ... . . . . ..

......

. . . . . . . . . . .. . . . . . . . . . . .. .... . . . . . . . .

14-4

7.3 7.4 7.5

Geographically Distributed Development ... , . . • . . . . . . . . . . . . , .. , . . . . . . . . . , The Team Software Process . ,., ...... , " . . . . . .....• ',. ., .. , ...... o ftware Project Too ls and T ec hn ique, ., ... . •.•. , .,.,.. . . . . . . . . . . . . . . . .

146 I I

153

CONTENTS

7 .6 7 .7 7.8

Risk Management . . . . ... . . . ... ... . . . . . . . . . . . . . .... . . . . . . .. . .. ... . Student Team Cuidance, Organizing the Software Project's Management . . . . . . . _ . . . Summary . . . . . . . . . . . . . .. ..... . . . . . . . . . . . . .... . .... . . . . . ... . ....

159 162 165

7.9

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

166

Bibliography . . . ,. . .. . . . .

. . ............... _. . . . . . . . . . . . . . . . . . . . . .

167

8 Principles of Software Project Management It Estimation, Scheduling, and Planning . . . . . .

168

8. 1

Cost Estimation . ..

. . . .... , . . . . . . . . . . . ,... . ... . . . . . . . . . . .. ... . ... .

169

8 .2 S. 3 8.4 8.5 8 .6 8.7

Scheduling .. .... . .. . .. . .. . , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. The Software Project Management Plan . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . Case Study, Encounter Project Management Plan . . . . . . . . . _ .. _ .. . . . . . . . . . . . Case Study, Project Management in Eclipse .. ... . . ... _ .... _ . . . . . . . . . . . . . . Case Study, Project Management [or OpcnO[-fice . .. .. .. _ .. . . . . . . . _ . . .. _ . . . . Case Study, Student Team Cuidance .. . . . . . . . .. .... . .. . _ . . . . . . . . . _ . . .

8.8 8.9

Summar)' . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . ..... . .... ..... . . . . . . . . Exercises . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .. .

182 185 187 196 205 208 210 21 1 2 J2

Bibliogr.Jphy . . . . . . . . . . . . . . _ .... ... . . .. _ . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Quality and Metrics in Project Management .. .. _ . . . . . . . . . _ . _ . • . . . . . . . . . . . . .. 9.1 Cultivating and Planning Internal Quality .. . . . _ ... . _ .. _ . _ . . . . . . . . . _ . _ . . . . 9 .2 Project Metrics . . . . . . . . . . . . . . . . . . . . . . . . _ . . . . . . . . .... ... . .... _ . . . . . 9.3 Using Metrics for Improvement . . . . . . . . . . . . . .. . . . . . . . . . . . . _ . . . . . . . . . .. 9.4 Software Verification and Validation Plan . . . . . . . .. . . . . . . . . _ . . . . . . . . . . . . . . 9.5 Case Study , Software Verification and Validatio n Plan for Encounter . . . . . . . . . . . . . 9.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 9.7 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliography . ... . . . .. . . . . . . . . . . . . . . . . . . . . . . . .... . . . . . . . ... ... . ..

PART IV

213 214 215 219 223 225 228 228 229

Requirement Analysis

10 Principles of Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . - ... - . . . . . . . . . . . . . 10. 1 The Value of Requirements Analysis . . .. . . . . . . . . . . . . . . . . . . . . . . .. . 10.2 Sources of Requirements . . - . . . . . .. . . . . . . . . .. . . . . . . . . . . . . . . . . - ... . 10.3 High-/tvtl vs. Dctai/,J Requirements .... .. . ... - . . . . . . . . . . . . - - . . . . . . . . . . . 10.4

Types of Requirements . . ..

. ....... . . . . . . . • . . . . . . . . . . . . . . . . . . . . . . . . .

10.5

Nonfunctional Requirements . . . . . . ..

10.6 10.7 10.8 10 .9 10. 10 10. I I

Documenting Requirement s . . . . . . . . . . . . . . .. . . . .. ....•... , . . . . . . . . . . . Traceabi lity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. .. . ... - .. - . . . . . . . . . . . .

.....

. ..

Agile Methods and Requirem e nts ... .... . . . . . . . . . . . . . . .. . . . . . . .... Updating the Project to ReAec t Reqll1rements AnalYSIS . - ... - . . . . . . . . - . . . . . . Summary . . . . . . . . . . . .... .. .. . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . .. . . . . . .•.. Ex•.... rei'ses . . .

., .. . Blbll'oorapl,y

...

. . . ..

....

. .....

• •

• •

I I Analyzing High -Level Requirements . .... . .. .. .. . . . . . . . .. II I Examples of Cu'tomer Wants . , .. . . . . . .. . .. - . - . - .. , • • I 1.2 Sta ke ho lder V"l on . . . . . ., . . . . ... . I I 3 The Interview and Documentation Pro e s . . . . . .• ..•.•. ..

.

•

•

•

•

•

•

• •

•

•

•

•

• •

• • • • •

. . . .,

•

• •

• •

•

•

•

.,

.

• •

•

•

. . . .

•

230 231 231 232 233 233 238 239 239 241

243 244 244 245 246 247

24

vi

1\

CONTENTS

I 1.4 I 1.5 II.

11.7 I I .S I 1.9

11.1 0 11 . 1 I 11.12 I 1. 13

\'(/nl ing an ve"'iew .... . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . .... . . .. .. 249 Des ribing Main Funclion and U e Ca.es ...... •. ...... .. ... •. . . . . . . . . 249 Agile Methods for Hi gh · Level Req uirement s . . . . . . . . . . . . . . . . . . . • . . . . . . . . . .. 252 pecifying User Inlerfaces: Hi gh Level . . . . . . . . . • . . . . . . . . . . . . . . . .. .. ..... 254 e urily Requireme nts .. . . . . .. . .. .... . .. . . . . . . . . . . . . . . . . . . . . .. . . . . 258 Using Diagrams for Hi gh · Level Requiremenl ..... . .. .. .... ... .. ... . ....• 260 ase Study: High-Level Software Requiremen ts Specihcatlon ( RS) for the Encounter Video Came . .... . . . . . . . . . . . . . . _ ..... . .... . . _ . . 264 Case Study: High -Level Requirements fo r Eclipse .. . .... • . . . . . . . . . .... .. ... _ 268 Eclipse Platfonn Subproject (First of three) _ . . ... . . .. . ... . . . . . . . . . . . _ ... _ .. 269 ease Study: Hi gh -Level Requirements for OpenOfAce . . . . . . . . . . . . . . . . . . . . . . .. 273

11 . 14 Sunlmary

. . . . . . . . . . . . .. . . . . . . . . . . . ,.. .. . . . . . . . . . . . . . . . . . . . . . . . . .

275

1 1. 15 Exercises ..... . . ... .. .. . . ...... . .. ... , . . . . . . . . . . . . . . . . . . . . . . . . . ..

275

Bibliography .. . . . _ . .. ... .. .. .. . . . . . .. . . . .• ... .. . . ....... _ . . . . . . . 12 Analyzing Detailed Requirements ........ . . _ .... . . . . . . . . . . . . . . . . . _ ....... . _ 12 . 1 The Meaning of Detailed Requirements .. _ ..... _ . _ .. .... . _ . . .. . . .. . . _ . . .. 12.2 O rganizing Detailed Requirements .... .. _ .. . ....... . ...... . _ . . . . . . . . . . . . 12.3 User Interfaces: Detailed Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12 .4 Detailed Security Requi rements . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . . . . .. 12.5 Error Conditions .... .. . ... . . . . . . . . . . . . . .... . .. . ... . . . . . . . . . . . . . . . . 12.6 Traceability of Detailed Req uirements ... .... .... . . . . . . . . . . . . ... _ ... __ . .. 12 .7 Using Detailed Require ments to Manage Projects .. _ •. _ ....... . .... _ .... _ . .. 12.8 Prioritizing Requireme nts . .. . .. . .... . . .. .. . . . . _ . . ... . .. . .. . .... _ . _ . .. 12 .9 Associating Req uirements with Tests . .. _ . _ ... . .... __ .. . ..... _ . . . . . . . . . .. 12. 10 Agile Methods for Detailed Requirements .... . .. ... _ . ......... . . . . ..... _ _ _ 12 . 11 Usi ng T ools and the Web for Requirements Analysis ..... _ ....... . . . .... . _ . .. 12 . 12 The Effects on Projects of the Detailed Requirements Process . .. . . . . .. . . __ • . . . .. 12. 13 Student Project Cui de: Requirements for the Encounter ease Study _ .. . _ . .. _ . . . .. 12. 14 ease Snldy: Detailed Req Uirements for the Encounter Video Came ......•... _ . _ .. 12. 15 Summary . ... . ... , . . . . . . .... . .. . . . . . . . . . ,... .... . . . . . . . . . . . . . . . . 12. 16 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibli obrraphy . . . . . . . . . . . . . . . . . ....... ...... ... . . ,. . . . .... . . ....... 1 3 Quality and Metrics in Requirements Analysis

..... ..... _ . _ . • . . . . . . • . . . . • . . . . .. 13_1 Quality of Requirements for Agile Projects ..... _ .. _ . ... . _ . . .. . .. • . . _ . . ... ' 13.2 Accessibility of Requirements . . _ . _ ....... ..... •... _ .... _ ....• _ . . _ _ . . .. 13.3 Comprehensiveness of Requirem ents . _ . .. . . . _ .. ... ... . .. . .... . ......... _ 13.4 Understandability of Requirements .. . •...... _ . . _ .• _ . . _ . . .. ......... . . _. 13.5 Unambiguity of Requirements . .. . . ... .. . ........ . .... . _ •. .. ..... . .. _ .. 13 .6 Consistency of Requirements ... .. ........ . . .. . ..... . _ . . . . . . . . . . . • . . . 13.7 Prioritization of Requirements ....... _ . _ .. . ........ .. .. . _ ... _ .. . . _ .. . . , 13 .8 Security and High .Level Requirements ...... . ...... • . . . . . . . . . . . . . . . . . • _ . ' 13 .9 Self·Completeness of Requirements __ .. . ... _ .... . .• . .... . ..• . . . ...... _ _ _ 13_10 Testability of Rt:quifcments . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . • . • . . . . . . 13. 11 Traceability of Requirement . ... . ... .. .• __ . _ .. .. •......... _ ..• _ . . . . . .. 13. 12 Metrics for Requirements AnalysiS .... _ ... . •...... .. • . . . . . .. _ ..•.. _ •.. _

276 278 279 280 291 296 296 297 300 301 302 303 305 308 309 315 328 329 330

331 332 332 333 335 335 336 337 338 339 340 342 3~3

CONTENTS

13. I 3 In pc tlng DetaIled Requi~ments 13 . 14 ummary . . . . . . . , , • • • • • Exerc.ises I . 15 • • • • • • • • • • • • •

•

,

•

•

•

• • • • • • • •

•

• •

• • • •

• •

•

•

• • • • • •

•

•

•

• •

•

• • •

344 347

• •

•

•

•

•

•

. ... ... ..... . . ........ . . ... ... .

• • •

•

• • •

•

•

•

•

•

• • •

•

•

•

• •

•

• • • •

•

•

• •

•

•

•

•

•

• • • •

• •

•

348

•

349

14 Formal and Emerging Methods in Requirements Analysis : An Introduction

(Online 14. I 14.2 14.3 14.4 14.5 14.6 14 ,7 14,8

PART V

Chapter) .... ' . , , . , . , . , , .. . Provable Requ irements Method Introduction to Formal Methods Mathematical Preliminaries The Z ·Spec ificalion Language The B Language System T rade·offs for Usi ng a B· like system Summary Exercises Bibliography

• •

• •

•

•

•

•

•

• •

•

•

•

•

•

•

•

•

•

•

•

•

• • • • •

• • • • •

Software Design

15 Principles of Software Design .,' ,.,' .... . ... . , . . , .... , " " , . ,.' , . . .., .. ,. 15. 1 The Goals of Software Design ,.,., •. " .. ', . .. ' , .. " ... ," , ., .• ', ... ,. 15.2 Integrating Design Models ... , ... , . .. . . . . . . . . . • . . . . . . . . . . . . . . ' . . ' .•. '

350 35 1 354

15. 3

Framework.s ... . . . .. . . . . .. .. . . . . . . . . . . . . . . . . . . . . . . . . ........... . ..

357

15.4 15.5

IEEE Standards for Expressing Designs . , .. . . ... ' . . , ... . ' .... . ' , . . . . . . . , .. Summary . ..... , ' . , .... , . .. ' ,. , . , ' . , . , ' , ... , . ' , . , . , .. , . . . . . . . . . ,

359 359

15.6

Exercises ....... __ ... . .. . .. . . . . . ....... . ..... . . . . ... . . . . . . . . . . . "

360

16 The Unified Modeling Language , . . •. ,., . , .. ,., . . , . . ' , ' .. , , .. ' , , , • ' , .. . ... . 16. 1 Classes in UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . ....... , ...... . . 16 ,2 Class Relation hips in UML , .. " . , . " . , .... , . .• , .•...... . . . •. ' .... , .. 16.3

16.4 16.5

16,6 16.7

Multiplicity ..... ... ... . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . .. Inheritance . . . . . . . . . ....... .... . . ..... .. . . . . . . . . . . . . . . . . . . . . .. . Seque nce Diagrams ... ......... . . ............. ..... .. . • • • • • • • • • • • • State Diagrams ..... .. ..... .. ..... . ... . ............. . ........... . Activity DiaglClm ....... ..... . . . . . . . . . . . . . . . . . . . . .. . .. . . ... ... . Data Flow Models . . . . . . . . . . . ... .. . ..... . . . . . . . . . . . . . . . . . .. ..,.

16,8 .... , .... ' ,., .. , . . . . . . . . . . . 16.9 A DeSIg n Example with UML . , , , . , ' , . , " 16. 10 Summary . . . . . . . . . ,. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . .. ... ... . • • • • • • • • • • • • • • • • • • •• •• ••••••••••••••••• 16. I I ExerCises . . • • • • • • .. ....... . ........,. ....... . , , . . , . . " . BIbliography • •• •

.

•

..

. .. . .........,...... .... ............... . ' 17 Software Design Patterns , 17 . I Exam ples of a RecurrIng Dc"sn Purpose .. , ' , . ' .. , . " ' , . " .. ,,, ..... ... , . , .. , .. , . ,,. ,•, .. , •... 17 2 An Introduct Ion to Design Patterns . . , . ummary of D es ign Pallerns by Type ' rea tio nal , 17 3 , .. • •••• Slru IlJral , and Ilehavlora l , .. , ' " ,." , . ,. . • •• • ' h a raCLcri s [l c~ of I CSls n Pallern s: VI Cw pO lnt ~, Ro le. , and Level< " , 174 , , , , , Sci c.tcd reall o nal De
.

.'

'.

36 1 362

,' 6 1-

364 364 368 372 374 376 377 380 38 1 382 383

84 ~86

3'10 3<)6

400 408

CONTENTS

17.7 de ted Beh, vlOra l D , '/(n Patterns . .. . • • • • •• • •• •••• 17 8 De
.

•

•

•

•

.

•

•

•

•

•

•

••

••

.

•

417 .. 43 1 4 35 • 4 36 437

18 Software Architecture . . . . .. .. .... .. . . . .. . . . . . . . . . . . . ....••..... 18. 1 A Categorization of Arc hitectures ... . . . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . 18.2 Software Architecture AlternatIves .nd T hei r Class Mode ls ... .. .. . . . . .... 18. 3 Trading orr Architecture Alterna tives . . . . . . . . . . ..... .... ....... . . . . . . . . 1804 T ool for Arch itecnlres .. . . . . . . . . . . . . . . . . . . . . . . .. . . ...•.. . ..... ... 18.5 IEEE Standard for Expre sing Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • . . 18.6 Effects of Arch itecture Se lection on the Project Plan . ..... . .. .. .. ...... . 1S.7 Case Study: Prep.nng to Desig n Encou nter (Stude nt Project Guide conti nued ) ..... 18.8 Case Snldy : Software Design Docume nt for the Rol,.PlayiH9 ViJ
18. 13 Exercises .

. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . ........... •

•

•

•

•

•

•

•

•

•

•

•

•

•

• •

•

•

• • • • • • •

•

•

•

• • •

•

•

•

•

•

•

•

•

•

•

•

• • • •

•

•

•

•

•

•

•

•

Bibliography ... .. • . . . . . . . . . . . . . . . . . . . . . . . , .... .... . . .. _ . . . . . . . . . .

19 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . .. ...... . .... ... .. . . . . . . . . . . . . . 19. 1 Relating Use Cases, Architecture, and Detailed Design . . . . . . . . . . .... ..... . .. . 19.2 A Typica l Road Map fo r the "Detailed Design" Process . . . . . . . . . . . . . . . ....... . 19 .3 Object. Oriented Design Principles . . .... . .. . . . . . . . . . • . . . . . . . ... .... .. .. 19.4 DeSig ning agai nst Interfaces ....... .. ...... . ... . . . . •.... .. ...• . ....... 19.5 Specifying Classes. Fu nctio ns, and Algorit hm s . . . . . . . . . . . • . . . . . . . . . . . . . . . ... 19.6 Reusi ng Componen ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . .. 19.7 Sequence and Da ta Flow Diagrams for Detailed Design . . . . . . . . . . . . . . . . . . .. .. ' 19.8 Detailed Design and Agile Processes . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . ...... 19.9 Design in the Unified Development Process . . . . . . . . . . . ..•...... ... ... . .. . 19 . 10 IEEE Standard 890 for Detailed De ign .... ..... . . . ... . . . . . . . . .... .• .. . . 19. 11 Updating a Project \~it h Detailed Design . . . . . . . . . .. . . . . . . . . . . ... . . .•. . .. 19 . 12 Case Study: Detailed Design of Encounter . . . . . . . . . . . . . . • . . . . • . . . . .. • . . . . . 19. 13 Case Study: Detailed Design of Eclipse .... .... . . . . . . . . . . .. . • .. .. . . . . . . . . 19. 14 Sumnlary

438 439 439 453 454 455 455 457 460 462 466 468 473

474 475 476 477

478 479 481 482 485 486 490 490 491 491 494 503

. . . . . . . .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .• . •. ..

505

19 . 15 Excrc·ises . . . . . . . .. .. . ... . . . . . . . .. . .. .. . . . . . . . . . . . . . . . . . . . . ... ... . Bibliography . . . . . . . . . . . . . . .... .. .. . . . .... .. . .. ..... . . . ... . . . . . . . .

505 507

20 Design Quality and MetriCS . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . .. . . . •. .... 20. 1 Degree of Understandability. Cohesion. and Coup ling . . . • . . . . • . • . . . . . . • . . . . .. 20.2 Degree of SufAciency as a Quality Goal . . . . . . . . . . . . . . . . . . . . • . . .. ..••.... 20.3 Degree of Robustness as a Quality Goal . . . . . . . . . . .. . . . ......• . ... . • • . ... 20.4 Degree of FlexibIlity as a Design Quality Goal .. . .. . . . . . . . . . . . . • . . . . . • . •. . 20.5 Degree of Reusability .. a Design Quali ty Coal . .. . . . . . . . . . . . . . . . .....••... 20.6 Degree of Time EffiCie ncy as a Design QualifY Mu ure ...•. ..•. .. . . . . . . . . ..•

S08 510 510 11 512 13 517

CONIENTS

20.7 20.8 20.9 10. 10 10. 1 I 20. 12 20. 13

Degree of pace EfficIency as a Design Quality Measure . . . . . . . . • . . . . . . ... .... Degree 01 Reliability as a Design Quality Measure . . ... . ... ... ... • . . ....•... Deg ree 01 Secun' ty as a D eSlg" ' Q ua I'tty M c,asurc .... ... . . ... . . ............... . A essing Quality in Architec rurc Selection ... ... •......•.... .. • . .. . . . •. .. As essing the Quality of Detailed Designs . . . . . . . . . . . . . . ..... . . ... . . .... . . Sunlmary . . . . . . . .. .. .. .. .. ... . .. . .. . . . . . . . . . ... .... . .... . . . . . . . . . Exercises . . . . .... . . ..... . . . . . . . . .. .. . . . . . . . . . . . . . . . . . . . . . .. .... . .

Biblio~paphy . . . ...•..... ... ... . . . .. . .. . .. . ..... . ... . ..•... . ......

:2 t Advanced and Emerging Methods in Software Design (Online Chapter)

21 . 1 21 .2 11.3 21.4 21 .5 21 .6 2 I. 7

PART VI

•

•

• • •

•

•

•

•

•

•

• • •

538

Designing in a Distributed Environme nt Introduction to Aspect· Orie nted Programm ing Designing for Security with UMLsec Model · Driven Architecrures The Formal Design Process in B Summary Ex" rc isc Bibliography

Implementation

22 Principles of Implcmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 . 1 Agil e and N o n.Agile Approaches to Implementati o n .... . . . .... . ... ..•.. . . 22 .2 C hoosi ng a Programm ing Language . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .... 22 .3 Ident ifyi ng C lasses . . _ . . .. . . . . . . . . . ... . . . . . . . . .. ... . . . . . . . . . . ... . . . 22 .4 D efin ing M e tho ds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.5 Imple me ntati o n Prac tices .. . . . . . . . . . . . . . . . '. .. . . .... . . . . . . . . . . . . . . . 22 .6 Defe nsive Programming . . . . . . . . . . . . ... . .. . . ... . . . . .. . . . . . . .. .. . . . . . . 22 .7 Cod ing Standards .. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . - .. . ' . . . . . . . . . . . . . . . . .. ..•.. .. ..•. • ..... . 228 Comme nts • • • • • • • • • • •• . .. ..... . . . . . . . . . . . . . . .. . 22.9 T ools and EnViro nments (o r Programm ing 22 . 10 Case Srud y: Encounter Impl ementation . . .... . . . . . . . . . . . . . .. .. ... . . .. . 22. I I Case Stud y: Ec lipse .. . ,. . . . .... . .. .... . ..... ,... . . , . . . . . , .... . 22. 12 Case Stud y: O pcnO fAcc . . . .. . .. .. ... . . ....... .....• . . .. . ... . •. .. 22 . 13 Student T ea m G uidance (o r Impleme ntatio n . . . . . . . . .. , . . . . . . . . . .... . . . . ' . ,. ...... . .... . • • • • 22. 14 Summary . . . . .... ,.. ,. • 22. 15 Code Listings Referred to in th is haptc r ., . . . . . , . . . . . . . . . . ... . . .. . • • •• • .,., • • • •••• • • • • • • • • • • •• • •• ExerCises . 22. 16 •• •••• • • , ... . , ... • •• • • • • •• • • • BiblI ograp hy ., , .

.. ..

.

.

.. .

2, Quality and Me trl s in Implementatio n ., ...... . 23 . 1 Quality of Impleme ntatio n . .' . . 232 de In'pect lon, and Relatcd Q uali ty Pro edure, • 23 .3 Summary . . .., . .. .

23.4

519 521 523 525 531 536 536 537

Exer ,.CS

•

•

• •

•

•

•

.,

,

..

. , . . . . . . .. ..

. .

. ....,. .... .... . •••• .' ... . •

• ••

•

••

.,.". .

•

•••• •

•

•••

•

•

•

539 540 540 540 54 t 544 548 552 554 555 556 559 559 565 566 66 8t

58

58 4 M ,7

599 1)(

•

24 . 1 24 .2 24 .3 24 .4 24 5 24 .6 24.7

. . ................................ ... . . . . . . . . . . . . . . ..... . Big Refactori ngs . . . . . . . .. . . ....... .. ..... ... .. . . ........ ...... . o mposlng Methods ... . ..... . . . . . . . . . . .. .. . .. .. .. . .. .. .. . . . . . . . . . . Moving Fea tures between Object ......•. . . . . . . . . . . . . . . . • • . . . . . . • . . . . . . Organizi ng Data .... . .. ....... .... . ........ . .. .... . .... . . . . . . . . . . . . . Generalization . ... .. ...... ....... . ..... . .. . . . .... .. . . . . . .......... IntroducIng Modules ...... . . . . . . . . . . . . . . . • . . . . . . • . . . . . . . . . . . . . . .. . RefaclOri ng in Projects . . . .. . . . . . . . . . . . . .• . . . . . . • . . . . . . . . . . . . . . • . . . .

60 1 604 606 608 609 612 616 617

24 .8

Summary

.... . . . . . . . . . . . . . . . .. . . . . . . . . . .... ... . . . . . . . . . . . . . . . . . .

619

24 .9

Exercises . . . ... .... ..... . ............... .... ... . . .... . .. .... . . .. .. Bibliography .. .. .... ... .... . .. ... ..... . .... ..... . . . ........ .. ....

619

24 Rf!facloring

PART VII

620

Testing and Maintenance

25 Introduction to Software Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . • . . • .. 25 . 1 Testing Early and Ollen ; and the Agile Connection .... . •...... . .... . .. .. •.. 25 .2 Retesting: RegreSSIon Testi ng . . . . . . . . . . . .. . . . . . . . . . . .. • . .. .•..... .. •. . 25 3 Black Box and White Box Testing . . . . . . . . . • . • . . . . . . . . ..... •. . ..•....•.. 25,4 Unit Testin g vs. Post· Un it TC5ling ... . ... ... ..• ... .. .... . ... . ... .. . . ... 25 .5 Testing Object·Oriented Implementations . . . . . • . . . . . . . . • . . . . . . . . . . . . . . ... 25 .6 Documenting Tests . ...... .... . . ... .•..... . . . . . . . . . .. . . . . . . . . .. 25 .7 Te t Planning .... ... . . . . . . . . . . . . . . ........ . .............. . ... .. ... 25 .8 Testing Test Suite by Fault Injection . . . . . . . . . . . . ...... . .. .. . . . . . . .. .... . . . .... . . . . . . . . . . . . . . . . .... .. . . . . . • . . . . . . . . . . . .. .. 25 .9 Su mm ary 25 . 10 ExercIses . . . . . . . . . . . . . . . .... .... ........... ~ . . . . . . . . . . . . . . . . . . . . . . ..

621 622 622 623 624 625 626 626 628 628 629

26 Unit Testing ... ... . . . . . . . . .... . . .. . . ............ . .. . . . . . . . . . . .. .. . . .. . 26. 1 The Sources of U nIts for UnI t Testi ng . . ... . ...... . .....•......•. .. .. . . . 26.2 Un it Test Methods . .. .. .. . . . . . . .. .. . . . . . . ... . . . . ... .... . . 26.3 Testing Methods . . . . .. .. . . . . . . . . . . . . . . . . .. . .......... . ... . . .... . ... 26.4 T est·Dro ve n Development . .. ... . .. ... ..... .. ..... . .• . ... . ... . .... .. 26.5 Case Study: Encou nte r Video Game .. . •.. .. . . ...... .. . . . . . . . . . . . • .. . ... . . . . . . . . . . . . . . . . . . . . . .. . • . . . . . . . . . . . . . . . . . .. . . . . . . 26.6 Summary . . . 26.7 Exercises . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. ..... . . . . . . . . . ... ... .. BibliogTilphy ... .... . ....... ... . .... . ... . . . . . . . . . . . ... . .. ... ...

630 631 631 642 647 652

27 Module and Integration Testing . .....•. . . . . . . . . . . . . . . . . . . . . . ... . • ... • .. ... 27. 1 Stubs and Drivers . ... . . . . . . . . . . . . . . ..... . ... . . . . . . . . . . . . . . . .. ..... 27.2 Testing a Oass ..... . ...... ... .... .. . .......... . ... . ... . . . . . . . .....

666 667 668

.

. ...

. .

.

662

663 665

27.3 27.4 27.5 27.6

Integration . . ................... .. . . . . . . . . . . . .. ....... ...... . . .... Daily Bu.ilds ............... .. ....... ... ... . . . . . ........ . . . . . . . . . . .. Interface: Testing ... .. .. .... .. ... . . . . . . . . . . . . . . . . . . . . . . . ... .. . .. . . . Module Integration .. . . .... . . . .... . . ... . ........ . . . .... .... . . . . . ...

27.7 27.8

Case Study: Class Test for Encounter . . . . . . . . . . . . . . . . . • . • . . . • . . . . . . . . . . .. Case Study: Encounter Integration Plan .... .... . . . . .•. ....... .... . ... ... .

680 682 683 688

27.9 Su:mmary .... . . . ..... .... . . ...... ...... .. . .... . . . •.. .... .. . ..... 27. 10 Exercises . .............. . .................. . .. _ .. . . .. ...... . ...... ,

692 692

Bibliography .. . . .. . .......... .......... . ............ . ..... .

10-

•

•

•

•

••

672 679

693

CONTENTS

28 T ~tinll at th~ S)'$t~m Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 28 .1 28.2 28 .3 28.4 28.5 28 .6 28 .7 28 .8

28.9

Functional Testing . ..... .. .. . .. ..... . .. . . .. . •. . .................. " Nonfunctional Testing . ...... .... . .... .... . ........ ... ... ........ . .. Testing with Lightweight Requirements .............. ............... . . . . . T~tin8 hortly Before Release ...... . ...... . .. . .. . ...... . ............. Ca e Srudy: Encounter Software Test Documentation .. . . .... . .. ... ........ . . Case Study: Eclipse . . ..... . . ... ... .. . ............. . ... . ..... . ... . .. Case Study: OpenOffice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Sunlnla.ry ..... .. . . . . . .. . . ....... . ...... .. . .. ... . .. . . . . . . . . . . . . . .

69. 696 698 708 713 714 723 726 728

728

Exercises .. ... .. . ... . .. .. . . . . ... . ... . . ... . .. ... .. . .. . .. . . ..... . .. . Bibliography . .... . . . . .. . .. .. .... , . . . . . . . . . . . . .... ..... . . . .. . . .. . .

729

29 Software Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 1 T ypes of Software Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 .2 Issues of Software Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . .... . . . ......

730 73 1 734

29.3

Maintenance Process .. . ......... .. .. ...... . .. . . ... . _ . . . . . . . . . . . . . ..

736

29.4 29.5 29.6 29.7 29.8 29.9

IEEE Maintenance Standards . ..... .... . . .. .. .. . . . ........ . . . ..... . ... .

74 1 749 751 754 756 757 758

Software Evolution . . . ... . . , . . .... . .. . . ... . .... .. . . . . .......... .. . . .

Maintenance Metrics ..... . . . . ... . ... . . . . . . . . . . . . . ..... . ... , . . . . . . . .

. Case Study • • • • • • • • • • • • • • Summary • • • • • • • • • • • • . Excrcises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . •

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

••••

•

•

•

•

•

•

•

•

•

•

•

..

•

• • • • •

•

. . . ... . ..... .

•••••••

•

•

•

••

•

•

•

•••

• • • •

•

•

• • • •

•

•

• •

•

•

•

•

•

•

•

•

• •

• • • •

•

•

• •

•

•

•

•

•

•

•

•

• • • • •

•

•

•

• • •

•

•

•

•

•

• •

•

•

•

• •

• •

•

•

•

• •

•

• • •

• • •

•

• • •

•

•

•

•

•

• • •

• • •

•

•

•

• • • •

•

• •

•

•

••••

Bibliography . ... .. . .. .. . . . . . . . . . .. . . ... . . . . .... . ..... .... ...

Glossary . • Ind~x ... ..

•

. . . .

• • • •

•

•

• • •

•

• • •

•

• •

759 767

preface

Mu h of the mod"rn world nln ' n software As a result , ,oftware e ngineers arc e ntnl ted with signincant rc<po n o nlme but It IS a software e ngineer who makes the system a reality . T oday's . oftware eng.netr must be able to partl Ipate In mo rc than o ne kind of software process , work in agile tea ms, deal with custo mers , expres requirements clearly , crea te modul ar deSigns, utilize legacy and o pen
THE ISSUE OF SCALE A software application consists of tens, "undreds, even thousa nds of classes. This is very different from managi ng three o r rou r of them , and resu lts in the dragon of complexity suggested by this book's cover. As al 0 ugge ted there, however. thiS dragon ca n be subdued. Indeed, to deal with numerous and complex c1asse , softwa re engi neers ha ve at their di sposal a wide variety of too ls and techniques. These range from the waterfall process to agile methodologie . from hig hly Integ rated too l suites to refac toring and loosely coupled rool se ts. Underl ying this variety IS co ntinumg resea rch into reliable approaches, and an acknowledgment of the fac t that o ne Size docs 110t fit all projects.

THIS EDITION COMPARED WITH THE FIRST The ~rst edition or this book emphasized the object-oriented approach, which ha subsequently become widespread. It was also designed to help tudent teams cany out hands-on tenn projects through theory, exampb. case studies, and practical steps O bject-orientation and hands-on continue to be major fearunes or this edilio n. However, we hav~ widened the scope of the first editio n, especially by including extensive coverage of aglie methods .nd refactonng, together with deeper coverage of quality and SOrlWare design. Readers of the first edi tion made extensive usc of the complete video ga me case srud Y-d n example that they could follow "from soup to nu ts" but which was signiRca ntl y mo re comprehensive than a toy This edition retains and updates that case study, but it adds the exploration of a simpler example o n one hand (a DVD rental lore) and large, real, o pen source case stud ies o n the o ther. In parti cular, to provide students a feeling for the scope and complexity of real -world applicatio n , this book leads them through elected requirements, design, Implementati on, and mall1tenance or the Ecli pse and Ope nOfAee open souree projects. The ize, complexity, and transparency o r these projects provide s rude nt~ a wll1dow into
PREFACE

lYl.'ica ll y belongs to a cycle rather than t'o a si ngle waterfall sequence, In particular, our approach integrates agtle methodo lOgies co nsistently. This e dition also introduces somewhat advance d inAuentia l ideas, including model-driven arc hi. !ectu~s and aspect ·oriented programmmg . Nowadays, formal methods are mandated by government agenCies for the hig hest level s of security, and this book aims to educate readers in their possibilities. Due to print space limitations, some of thiS material is to be found in the online extension of thi s book. In summary, specifk features of thi s edit ion compared with the first arc as follows : • A sharpe n ing and standardizatio n of the material from the first edition • A strong agi le thread throughout, including a chapter o n agility alone and one devoted to refactonng. • A separate chapter on quality in six of the book's seven pans • Real -world case studies, taken from the Eclipse and OpenOffice o pen source projects • Greatly expanded coverage of software desig n and design patterns • New chapters on advanced, inAuential software engineering ideas • An o rganizati o n of many of the book's seve n parts as follows : • PrinCiples • Detail s • Quality • Advanced Methods

HOW INSTRUCTORS CAN USE THIS BOOK This book has been designed to accommodate multipl e approaches to the learnin g and teaching of software engineering . M ost instructors teach the fundamental s of soft,vare process. project management, requirements analysis, design . testing . implementation , and maintenance Beyond th is comm o n ground, however. instructors empl oy a wide va riety of styles a nd e mphases. The follOWing are majo r approaches. together with the sequence of c hapters that support each of them.

A.

Proass emphasis, con e ntrating o n how applications are develo ped All o f Parts I through IV; and C hapte rs 15, 22 , and 25 (th e remaining principles and intro ductio n ch apte rs)

B

Desi9" emphaSIS, whic h tca ches softwa re engi neeri ng primaril y as a design activity Princi pl es and introductio n· C hapters 1, 3, 7, and 10, all of Part Vi and haptcrs 22 and 25 (prln Iples and Introduc tion )

C.

Programmln9 a"d a9il, (mphaSlS , whic h emphasizes so ftware engi nee ring as a code -o riented a II vi ty that satisAes rcquircment~, emphaSizi ng agi le app roache Prin Iples and Introduction · hapl crs I , 3, 7. 10, and 15, all of Part VI I and C hap ters 25 and 26

D.

TlDo-sm,sl" coursr, project

whi h enables th e in~tructor to cover mo t top I s and a ' I ~n a lib tant lal hand, -o n

•

PREFACE

Df, All of the chapte ~ or

111

the book, either in sequence "ro m beginning to e nd

D2 In twO pa ses as follows : (i) Principles and i",rodu tion hapters in the Arst semeste r: C hapters 1, 3,7, 15,22 , and 25 (ii) The remaining chapters in the second semester E.

EmplJa,i, on

II

I" md,-on projecis " Old caSt ,'udies, which relics mos tly on an active team or individual project as

the vehicle for learning theory and principles Principles and introduction c hapters : C hapters I, 3, 7, IS, 22, 25 , and 26, and all case study sections in the remaining chapters F.

Tbtory and principles e,"ph"sis, conce ntrating o n what one can learn about software engineering and its underpinnings Principles and introduc tion chapters : Chapters I, 2, 3, 7 , 15, 22 , and 25, followed , as time allows, by C hapters 14 and 21 (emerging topics)

C. Qualily a,mmna and leslin9 rmpha,i, Principles and introduction: Chapters 1,3 , 7, and 10; Chapters 2, 5, 9 , 13, 20, 23 (quality ); and Chapters 25, 26, 27, and 28 (testing), The web site for this book , including review questions and the Encounter game case study, is www.wiley.com!coll egeJbraude. Eric Braude Michael Bernstein Boston , MA January 20 I 0

owl

ments

We owe a debt of gratirude to o ur srudents at Bosto n UniversIty's Metropohtan Coll ege. Working in myriad industries and busi nesses, they have give n us invaluable feedback . The Coll ege itself has provided a model place fonhe teaching and learning software engi nee ring . Ounha nks go to Dick Bostwick a nd T o m VanCourt, much of whose work in the first edition carries over to this o ne. We are grateful to the peo ple of Wiley fo r workin g with us through the painstaking process of writing and publishing th is book. We are particularly appreciative of the help from our editOrs, Dan Say re and Jonatha n Shipley; from Ceorgia King, Yee Lyn Song, and the indefatigable staff. We thank the reviewers of o ur manuscript, whose feedback has bee n invaluable : Arvin Agah , Un iversity of Kansas Steven C. Sha Her, Pennsylvania State University Stephen M . Thebaut , University of Florida Aravinda P. Sistla, Un iversity of Illinois, C hi cago James P. Purtilo, Unive rsity of Maryland linda M . O tt, Michigan T echnolog ical Un iverSity Jianwei Niu, Un iverSity of Texas, San Anto nio W illiam livel y, Texas A&M University Chung Lee , Ca li fornia State Un iversity, Pomona SudiptO Chosh , Colora do State Uni versity Max I. Fomitc hev, Pennsylvania State Un iversity Lawrencl" Bernstein, Steve ns Institute of T echnology John Dalbey, California Poly tec hn iC Un iversity Len Fisk , C alifornia State Un iversity, C h ico Ahmed M . Sa le m, Ca lifo rni a Sta te Un ive rSity , Sacramento Fred Strauss, New York Un iver ity Kai H . C hang, Auburn Unive rSIty Andre van de r H ock, UnI versity of Ca lifo rn ia , Irvine Saeed Monemi , Ca hfo rni a Po ly techn ic Unlver ity Robert M . C ubert, Un ivers Ity of Florida Chris T seng, San Jose State UniverSity Michael Jame Payne, Purdue Un ive rsity Ca ro l A. Wel lington , h ippensburg Un iversity ¥ifel Dong, UOIvcrSlty o f Ok laho ma Peter Blanc hfIeld , Nottingham Un iversity Desmond Creer, Queen'< UnIversi ty Belfast We IQ , Yan , Que!:n's University Belfa st bigham Mahmood, Derby Uni vers Ity ~rcl P,cterSo n, H OKcsc hool Van Amsterdam . book Id h ~ - po'
The Goals and Terminol • o So ware En ..• neenn

The Software Development Ufecycle

•

Why is software engineenng important?

•

Who and what does is consist of?

•

What are its main actMtles?

•

What ale the principles of software engineering?

•

What ethics are Involved ?

•

What sorts of case studies Will be used to illustrate the subject?

Figure 1.1 The context and learntng goals for this chapter

Th e goal o f o ftw arc eng ln ee nng , and the theme of thi S book, I th e creati o n of oftware sy tern th at meet the needs o f cu t o m e r and arc reliable, d fic lent , and ma i ntainable. In addition , the 'y tern h ou l d be pro duced 10 an eco no mica l fa sh io n, meeting prOject sc hedul es and budge t . ThIS I no ca y task, espeCiali (o r large , complex applicatio n TIllS c hapt cr Introduces th e fi eld o f oftwarc c ng ln ee fln g and e, pl. IO " h ow .t addresses th e<e goa ls. We hrst ex pl ., n the term "so ft ware c ngincenn g," sho " ' IOg th at.t on" h of man\' pan s.

2

CHAPTER 1 THE GOALS AND TERMINOLOGY OF SOFTWARE ENGIN EERING

1.1 WHAT IS SOFTWARE ENGINEERING?

OJIoI'." ",gln",;n!! b on englOeering dl scip hn~ thot lOvo lves all ospects of deve loplOg ond maintalOlO!! a software prodo t Enginee nng discl pline< suc h os lvii , I11cchonlca l. and clectricollnvolvc the deSIg n . analysIs, and con tm tlon of an "tibct for some prac tIca l purpose ' o ftwarc e nginee rin g IS no exce ptI o n to thiss->oftware produc ts certainly hav~ pra tica l purposes. Th~ IEEE deRnes Software Engineering [ I ) as follows , I. The app lication of a systematIc. disciplined , quanti Rab ie approach to the development, oper.lt lon and mainte nance of soft wore, that is, the application of englOeenng to so ftware .

2. The study of approac hes as in ( I) As this deRnition sugge ts, it's not on ly what is produ cd that's important but a lso II011J it is produced Eng,"eenng disciplines employ an established set of sysln.alic, dis iplin,d, and qlUmlifiab[, approaches to the development o f anifacts. By thoroughl y applyi ng an analogous set of approaches to the development of software, we can expect the production of software that is h ighly reliable, is maintainable, and meets speclRed requirements. A dISciplined approach is panlcularly imponant as the size of a software project grows. With increased size comes greatl y increased complexity, and applying a systematic and disciplined approach is criticaL One of the first uses of the phrase "software engi neeri ng" wa in 1968, by a NATO Study Group on Computer Science [2]. A conference was o rganIzed at that time, motivated by the "rapidly increasing imponance of computer systems in many actiVIties of society ." The Study Group focused their attention on the problems with software, and held a working conferen ce o n Software Engineering that turned out to see far into the future. The foll owing are some quo tes fro m the conference that summarize the cause for their concern: The basic pro blem IS that ccnain classes of systems arc placing demands o n us which are beyond our capabilities and o ur theori es and methods of design and production al this time .. It is large systems that arc encounteri ng great difficulties. We shou ld not expect the production of such systems to be easy. Panicularly alarming is the seemingly unavoidable fallibility of large software, since a mal . function in an advanced hardware-software system can be a matter of life and death . Programming management will continue to dt-scrve its current poor reputation for cost and schedule dfectiveness until such time as a more complete understanding of the program desIgn process is achieved. O ne of the problems that is central to the so ftware produc tion process is to identify the nature of progress and to find some way of measuring It. Today we tend to go o n for years. with tremendous investment to And that the sy tem, which wa not well understood to stan with, docs not work as anticipated. We build system like the Wright brothers built airplanes build the whole thing . push It off the cliff, le t it crash, and sIan over again. The Study G roup discussed possible tec hniqucs and me tho ds that mIght lead to solving these problems. They deliberately and provocatively used the term "software engineering," with an emphasis on engineering, as they wanted to "i mply the need for software manufacture to be based on the type of theoretICal foundations and practical disciplines that arc traditto nal in the establi hed branches of englOcering: The believed that If these foundations ond diSCIpline were applied to bUIlding software s stems, the qualtt of the resulting systems would be vastly improved. Today, many of the issues they identified are addre<sed by evolvlllS software engineering techniques and practices even as the ,cope of applications has incrcosed dramatically . Throughout this book we examIne these practices and explalll how they con tribute to prodUCing high. qunlity software. 8efor.. doing that,

WHY SOFTWARE ENGINEERING IS CRITICAl ' SOFTWARE DISASI ERS

however, it IS instructive to begin cxanllning why softwa re fails in th e first place, and how some fai lures can

tv"" le.d to ca tastrophic results.

1.2 WHY SOFTWARE ENGINEERING IS CRITICAL: SOFTWARE DISASTERS Even WIth the best of intentions, a large number of software projects tod.y are unsuccessful, wit h a large percentage never completed . Worse , quite a few software projects still end in d,saste r, causing a loss of money, rimc , and tragically , cvc nl ives. \Y/c review some reprcscnta[ivc samples here as cau ti onary ta les. In all

cases, the method employed were inadequate for th e complexi ty of the required application . Failures such as these motivate us to conti nually ask: How can we: apply softv.1are engi neeri ng methodologies to ensure the appropriate level of qualoty in software applications)

1.2.1 The Virtual Case File Project The FBI's Virtu.11 Case File system was intended to automate the FBI's cumbersome paper· based case system, allow agents to share invtstigative onfo rmati o n, and replace obsolete systems. Instead, after an expenditure of $ 170 millIon, the result did not accomplish these objectives at all . 111e effect ha been to inhibit the FB I from growing its • crime-fighting mission despite the growth in terrorism and the increased sophistication of many criminal

organizations. All of7oo,ooo lines of code, costing $ 100 million, had to be ahandoned. Poorly defined requirements, networking plans, and software development plans were cited by investigators as causes for thi disaster.

1.2.2 The Ariane project ' O n 4 June 1996, the maiden flight of the Ari..O( 5 launcher e nded in failure . O nl y about 40 seconds after in itiation of the flight sequence, at an altitude of .bout 3700 m, the launcher veered off its flig ht path, broke up and exploded: [3) The cost of develo ping Ari..O( during the preceding decade has been estimated at $7 bi llIo n. A significant fraction of this was wasted on June 4, 1996. Anlm, 5 itself. oneluding its speCific develo pment, has been va lued at $500 million . The source of the problem was desc ribed in the ofnc ial repo rt [3) as follows (italics added ), The internal Inertia l Referen ce System software exception was caused during execution of a data conversion from 64·bit flo. ting point to 16 -bit Signed intege r va lue. The floatong , point number which was converted had a value !o'Teater t han what could be represented by a 16·bit signed integer. This resulted in an Operand Erro r. T he data co nversion instru cti o ns (in Ad. code) were not protected (rom causi ng an Operand Error.. . Tht (rror occurrrd in a pari oj Ibt 5o!fwart that only performs a lignment of th e strap· down inertial platfo m1 . This software module computes mean· ingful resu lts on ly before lift ·off. As soo n as the launcher lifts off, this fu nction serves no purpose. In other words, the data conversIon code itself was ' correct" but was called upo n 10 execute when it should not have been . The defect lay wit hin controlling code. This ki nd of problem is easy to desc ribe but not ea y to aVOId because many people ore involved in large projects. Large projects become extraordin.nl>' omplex. Development efforts like AnaH' ca ll for extensive edu ca tI on and coordinati on w lthon project manage men t, quality as~rancc, conAguration management, architccture, detai led de i8 n, programmins, and te ling organizations. Dependmg on how th e project was organized an d designed , anyone of these organizat Io ns could have been partly responSIble for ,;eem!! to It that the code on qu(,,,ion wa< not called after Ilftofr.

1.2.3 Radiation Overdose As software co ntrol~ an ever-In rca~inu numher of devi (,S, It, rclmh llily " cominJ.( undt"r in rt:ali;lflgly tOt t-nsc scrutIny. I" the prOject manaflernent maUaz lnc 13..,lm" DebbIe ,.ge, Jo hn M om1lck, ~ nd Bcna Ramon. wro te

3

4

CHAPTER 1 THE GOALS ANO TEI1MINOLOGY OF SOFlWARE ENGINEERING

of a la,,,su1I allqjlng "nta,sive overdo,e, 01 gamnt. ray' partly due 10 Ilntitallons of lhe computer program lhat gUIded l>se or a panicu lar radiallolHherapy machine. TI,ey reponeclth ... following . "The International Atomte Energy genc saId In May 100 I lhal alleaSl flve of lhe dealhs were probably (rom rodiatlon pO"Ontng (from the rna hine) "nd al leasl 15 more pallenlS ri,ked devcioping 'serious compltca ltons' from rodial lon • [4 JThe defecl dId nOl show up unt il a ,ignificanl lIme afler rd ease, and o nl y after cenain scquenCL'S of operator action,. The fo ll owing des ribes the software defect , and IS quoted (rom [5]. etting the bending magnet tak,:s aboul 8 seco nds Mtl9n" ca lls a ubroutinc called Plim, to introduce a tIme delay . ince several magnels need to be ,et, Plim, is entered and exited several time A nag to indicate that bendi ng magnets arc being se t is initia lized upon e ntry to the Mti9n,' subrOlltlne and cleared at the end of Plim,. Furthe nnore, Plim, c hecks a hared variab le, set by the ke yboard handler, that indicates the presence of any edi ting requests. If there arc edits, then Plim, clears th e bending magnet variab le and exits to Mti9"" , whic h the n exits to Dattlll. But lhe edit change va riabl e IS c hecked by Plim, o nl y if lhe bending magnet flag is set. Since Pllm, clears it during its first execulion , any edlls performed during each succeeding pass lhro ugh Ptim, will not be recogntzed. T hus, an edit c hange of th e mode or energy, althoug h reflected on the operator's scree n and the mode/ energy offset variable, wi ll not be se nsed by Da I", I so il can index the app ropriate ca libration lables for the mac hine parameters. I This is a fairly involved explanatio n but no t al all beyond the complexity of man y software systems in existe nce today . When should th is type of e rror have been fo und] If sound ohware e ngi neering d iscipline h ad been employed during all phases of the project, there would have been several opportunities in the development process to detect it.

1.2.4 More Software Disasters

r

Readers who wish to know about more software disasters, big and small , are referred to Neumann 6), who discusses risks. problems, defects, and disaslers relati ng to reliability, safety, security vulnerabilities, integrity, and threats to privacy and well ·bei ng. Another source is the ACM publication Softwar, Engin,rring Nolrs and its Risks Forum [7].

1.3 WHY SOFTWARE FAilS OR SUCCEEDS Thankfully , nOl all software projects e nd in the rypcs of disasters described above, but fa r tOO many end in failure . What docs il mea n for a software project lO be unsuccessful] Simpl y put, an unsuccessful projcct is one thaI fails to meel expeclations. Mo re specincally, the undesi rable outcomes ma y include the followi ng , • Over budget • Exceeds schedule andlor misses market wi ndow • Doesn't meet staled customer requirements

• Lower quality than expected • Pcrfonna nce doesn't meet expectations

• Too difAcult to use Lc:v(nson . N.ncy , .nd Turner C.S., "An Inve
0

7,

SOFlWARE ENGINEERING AcnvmES

Falling to meet j ust one of these objectives can cause a project to be deemed unsuccessful. For example, if a project is completed under budget, meets all requirements and functionality, has high quality, good performance and is easy to use , it still may not be successful If the schedule was missed and no customers are willing to purcha e it as a result . Charette [8 ) notes that there are many underl yi ng reasons software projects are unsuccessful , including, • Unrealistic or unar!ic ulated project goals • Poor project manage ment • Inaccurate estimates of needed resources

• Badly defined system requirem e nts • Poor reporting of the project's sta tllS • Unmanaged risks • Poor communication among customers, developers. and users

• Inability to handle the project's complexity Other contributing factors are, • Poor software design methodology • Wrong or inefficient set of development tools • Poor testing met'hodology • Inadequate test coverage • Inappropriate (or lack of) software process' Unsuccessful software projects usually fall victim to several of these . T o reiterate , the goa l of software engineering, and the theme of this book, is the creation of software systems that are relidble, effiCient, maintainable, and meet the needs of cuSlOmers. Software engineering provides the tools and metho dologies necessary to accomplish these goals, resulting in the development of successful softwa re systems. We'll end this section on a positive note. The authors feel that software engineering has improved greatly, when measured fairly . Projects of equal ambition can typ icall y get done far more successfully now than 10 years ago. The issue really is that the ambition and scope of, applications have grown enomlOusly. The Eclipse software development platform , which this book uses as a ca e study, is an excellent example of a successful application . This is largely due to its Aexible design , inclusive requirements process, and thoro ugh testing.

1.4 SOFTWARE ENGINEERING ACTIVITIES The production of software systems can be extremely complex and present many challenges. Sy tltms, especially large ones, require the coordi nation of many plOpl" ca lled s takeho lders, who mus t be organized into t~am s and whose primary objective is to build a produ I that meets de ancd requireme nt The entire effort must be org,mud , C h.",,, , Rober!, ' Why oftwar< Fa ds: IEEE pcc,rum, Vol. 42, No. 9, epl
2005 IEEE

5

6

CHAPTER 1 THE GOALS AND TERMINOLOGY OF SOFTWARE ENGINEERING

• People • ProlCLl .takcholders • Product • TI,e software product plu$ a socia ted document>. • Project • The

J

tlville

amed Ollt to produce the product.

• Process • Framework wIthin which the tcam carries o ut the aClivilie necessary to build the product. Figure 1.2 The four "P's" that constitute software engineering into a cohesive proj
1.4.1 People People are the most Impo nant resource on a software project. It is through their effons that software is successfully constnlcted and delivered . Competent people must be recmitcd, trained, motivated, and provided with a growt h path , which is no easy task . They are the lifeblood of any successful project. Software development is often dictated by tight, market·driven deadlines and demanding lists of required product features . Because of th is, only well -o rganized groups of engineers, educated and experienced in the methods of software engineering, are capable of consistently carrying out these activities to everyone's satisfaction . The alternative is often chaos and, all too fTequently , disaster. Typicall y, severa l groups of people arc involved with and have a stake in a project's outcome. These are called its sliJk,hold,rs . TI,ey include business management , project management , the development team, customers, and end u ers. Although each group is motivated to see the project succeed, given their diverse roles each has a different pe~pective o n the process. This is discussed next, for each of the gToups cited.

Business Management These are people responsible for the busi ness side of the company developing the software. They include senior management (e.g., V.P. Finance), marketing (e.g" Product Manager), and development managers. Their primary focus is on business issues including pront, cost effectiveness, market competitiveness, and customer satisfaction. They are typically not panicularly knowledgeable abollt or involved in the technical aspecrs of the project.

Project Management Project managers are responsible for planning and tracking a project. They arc involved throughout, managing the people, proce>s, and activities . They continuously monitor progress and proactively implement necessary changes and improvements to keep the prOject on schedule and within budget.

SOFTWARE ENGINEERING ACTMTlES

Development Team Software engineers are re~ponsible for developing and maintaining the software. Software developme nt in lud~ many t~ks such as requirement gathering , software architecture and desig n, implementation , t~tlng, con Aguration management, and docume ntation . This book will have much to ay about each of these topi .. oft",are engineers arc motIvated by man y factors including technical innovation, low overhead (e .g., a minimum of business· type meetings), and having the time and support to stay involved in technology .

Customers C ustomers arc responsible for purchasing the software. They may o r may not actually use the software. Customers may be purchasing it for use by others in their organization . They are primarily interested in software that is cost-effective, meets speCific busi ness needs, and is of high quality . They are typically involved in some aspect of specifying requirem enrs, and si nce they arc paying for the project, they have the ultimate say in defining the requirements.

EndUsers End users are people who interact with and use software after it is Anished bei ng developed . End users are motivated by software that's easy to use and helps them pcrfo nn thei r jobs as efficientl y as poss.ible. For example, once they become accustomed to and are effective using a particular user interface, they are typically reluctant to accept major changes to it.

1.4.2 Product The products of a software development effon consist of much more than the source and object code. They also include project documentation (e.g., requirements d ocument, design spec ification ), test plans and results, customer documentation (e.g., installation guide, command reference ), and productivity measu rements. These products are o ften called artifacts, and arc summarized in Figure 1.3. Th is book describes the comp lete set of ani facts. Pan 111, o n software manage ment, describes project metrics and how they arc collected and used to measure productivity.

• Project documentation Documents produced during software dcR niti o n and deve lo pm e nt.

·Code Source and object. • Test doc uments Plans, cases, and r"sults. • Customer doc uments Documents explainln8 how to use and operate produ L • Productivity measure me nts Analyze project produ~tivity . figure 1.3 TIle main prQduct art facts of a software project

7

8

CHAPTER 1 THE GOALS AND TERMINOLOGY OF SOFTWARE ENGINEERING

I art IV , o n requirement' ,na ly,i>, ex pla in, how to produce requirements that speedy what the product " ""e nded to be Part V explaI ns how to 'fleci(y so ftware designs. hapter 20 de,crlbe, software architectures C hapter 2 1 de,crlbes how to specl(y the detaded de,igns. Design patterns, a standard means of com municatI ng Intelligently with each other about desIgn , arc described In haptcr 19. Part VI di cusses Implementation (progra mming), Cmph3>IZII11! standards and precIsIon . A major goal IS to help devel opers to wnte program that arc much easier to verify (or correctness Part VII describes how to test the part~ o( an app lication, a well as the whole. It includes test procedures that specify how te ts are onduc ted and the test cases that specIfy the input data for tests. Part VII also describe. the types o( customer documentaroon artiFacts that are produced and their purpose

1.4.3 Project A software project deRnes the activities and associated results needed to produce a software product. Every project involves a SIm ilar set of activities: planning , determining what's required, determining how the software hould be built to meet the requirements, implementing the softwa re, testing the software, and maintaining it once delivt·r<·d to customers. These major project activities are summarized in Figure J A . In addition to these activities, va ri ous development paradigms , techniques, and tools exist and arc employed on different projec ts. A development paradigm is a way of thinking about the process of producing software . An example of a development paradigm , and one that is in wide use today, is the obj,cI-orirnt,d paradigm . It was invented to make designs and code match the real world . That is, an object as represented in a software de ign is patterned after a real · world object. For example, suppose that a banking application is to be bu.ilt that includes support for customers, bank accounts, and transactions on the accounts. In an object·oriented paradIgm , these real ·word concepts are represented in the desig n and implementation by corresponding

• Planning • Plan , mo nitor, and control the software project. • Requ.irements analysis • Denne what to build. • Design • Describe how to build the software. • Implementation • Program the software. • Testing • Validate that software meets the requirements. • Maintenance

• Resolve problems, adapt software to meet new requirements. F"",. 1.4 Major actMtles of a software project

SOFTWARE ENGINEERING ACTMTlES

' · I~ II' \ ' ,.

~-.D/rect correspondence

Customer

Transaction

Account

object

object

object

Software design and imp/ementaoon artilacts

Figure 1.5 A key role of the object-oriented paradigm St:Jurce" GJaptucs reproduced WIth pe'lltlsslon from COlel,

clas es. This greatly faci litates identifying and applying modi fica li o ns to a d esig n necessi tated by change to real-world requirements. Fo r exa mple , if the steps executed durin g a particular lra",aclio" need to c hange. the design can more ea ily accommodate this since there's a corresponding lra",aclio" object in the d eS ign. The design representation fo r transactio ns is encap ulated within the transacti o n object, and mo di fica tio ns ca n be applied mo re easily. Th is is illu trated in Figure 1.5. In no n-o bject· oriented langua gcs . the representation of a real-wo rld concept such as a customer may be spread across man y d isconnccted pieces of source code .

1.4.4 Process A ,oJlrDare process is a framework for carrying out the activities of a project in an o rga nIZed and di sc iplined manne r. It imposes structure and hel ps guide the man y people and aCllv llies in a co bere nt manner A software prOject progresses through differe nt ph.,,; , each interrelated and bo unded by tim e. A softwa re process expresses the interrelationship among the phases by defining their o rder and frequency , as well as defining the deliverables of th e project. Figure I names the majo r pbases and indicate the o rder ,n which they arc usua lly perfonTlcd. SpeCific software process implementatio n are ca ll ed ,oJlwo" prom, mod,i,. The re arc severa l suc h model , but most are based on either the u>a'tryall o r il". I,., d,,,riopmCII' models. Each of thcsc IS brieA descn bed below Part 11 covers the evolutio n of software processes and de tails these plus several o the r of the most Importa nt process models. The lDaltrfall proem IS t he simp lest .oftwa rc process mo de l, and fonllS the basis fo r most ot hers. A pure ",atcrfall process dictates tha t phases arc impl emented in seque nce, with nO phasl' starting before the prev Io us one ha~ almost omp lctcd T hat is , phases arc execu ted In a tri ti y sequential order, uSliall y With mall overlaps Once a wa te rfall phase is fini shed It'S deemed co mpl ete for the projc t and there IS no need to return to It. Vanallons of waterfa ll eXist where already <.omple tcd pha. es may be reVISited and min or updates applied , as a result o f ",ork done o n subseq ue nt pha,cs . Waterfall begi ns with an in "ptl o n phase, wherl' tiw product is co nceived and buslI1c', objec ti ves de fmed . Next is th e spe Iheation of the rcquiIX'Il1ent , foll o wed by the d.c:s,sn pha,>c, the Imrl eme ntallon pha,c, thc tt" tln g phase, and Rnally the ma in tc nan (. ph.'e. FI/: ure , 6 "Iustrates the main pha ses and the ir se'lucnee T hi S mea n, that th e I)fOCes, goes aro und the Ir Ie of

Figure 1. ' Just o nce. Software development ra rely nce u" In th e ' lriU wa terfall seq uence . I,,,t ead, It SKIp, ba ~ and lort h somewhat among rcq Ulr(' mcnl ~1 deS ign , Imp lcm nt alw l\ , llnd lC!rIling In praLltL C, lheo, we oflt:n U!JC' drratwt'

9

10

CHAPTLR 1 THE GOALS AND TERMINOLOGY OF SOFTWARE ENGINEERING

Tlmo ,

Requlremenls Design Implemenlation Phases (ac/lvities)

)...Testing Maintenance Figure 1.6 The waterfall software development process

processes for software deve lopment , in whic h all or some of the waterfa ll process is repeated several times. Some processes dictate that activities may be carried out in parallel. In the agilt process, programmers typically view implementation as part of desig n rat he r th an an entirely separate phase . Here. most phases in the Circle of Figure I. I arc repeated frequently-as often as every two weeks . This book makes frequent reference to agile methods. When performed in a di scip lined manner, iterative styles can be highly beneficial. They are especial'ly u eful when the requirements arc only sketchily known at the start of a project. A subset of the system is constructed from a partial list of requirements, customer feedback is obtained , and additiona l requirements are generated . This cycle repea ts until the complete system is built . Since policy decisions about software process take place at a n organ izational level (company, department , group , etc.), there is a need to assess the software development capabilities of organizations_ The Capability Maturity Model" (CMM ) is suc h a measu re . T he CMM and its successor, the CMMI , were developed by the Software Engineering Institute. The software engineering capability of individual engineers can be developed and measured by th e Persona l Software Process SM (PSP) created by Humphrey (9 ). The hi g hli g hts of CMM I and PSP are woven through some chapters of this book. A third level of softwa re organization is Humphrey' Team Software Process" (TSP) [ 10], which describes the process by which team s of software engineers get their work done . The Internationa l Standards Organization (ISO) de~nes quality standards against which many organizations assess their softwa,.., development processes. Well thought·out documentation standards make it much easier to produce useho! , ,..,toable artifacts. Several standards are available. Many companies provide in-house standards. For the most part , this book applies the IEEE (Institute of Electrical and Electronics Engineers) software engIneering standard~, man of which arc also sanctioned by ANSI (American National Standards Institute). Standard focu the process by providing a baseline for engineer, instructor, and students. In pr"ctice, they are modified and tailored to speciRc projects. Software process is the subject of Part II of th is book

1.5 SOFTWARE ENGINEERING PRINCIPLES The Acid of software engineenng has matured greatly since it began ov~r 40 years ago. Throughout thIS tin,e practitioners have learned valuable le.son that contribute to the best practices of today. Sonte have become outdated, but many are still very relevant and widely implemented today. In hI< book [ II j, AI.n DaVIS

SOFTWARE ENGINEERING PRINCIPLES

I . A'laly QuaLty Numb"

f

2. High-QualIty oft.,mr I. Po sibl,

. Gin, Pru.INrts to C.-'om,,, EMly 4.

Ust

an

Approp';
5. M,ni,.izt In t,lI, '.al Dj~'a"c<

6 . '"SpiC'

oJ,

. Ptopl, Art ,Ix Kry

'0SU CCI'SS

figure 1.7 Major principles of software engineering

gathe red 20 I principles that form th e foundation o f software e ngi nee rin g . Figure 1.7 hig hli g hts some of the most imponant , and we exp lore eac h of the m .

Make Quality Number 1 There is nothing more important than d e li ve ring a quality product to custOmers- they simply will not tOlerate any thing less. H owever, different people have different ideas of what quality means, and it th erefore must be specified and measured. Prime examples of quality are how closel y softwa re meets the customer's requirements, h ow man y (o r few ) defects it has, and how much it costs to produce . Q ual ity measures nee d to be speCified in advance to ensure the correct targe ts are being pursued and m et. Thi s book contains several chapters devoted to quality but , m o re important, the notio n of quality is behind m ost of its conten t.

High-Quality Software Is Possible Although it may be difficult to produce hi g h -quality softwa re , following mo dem softwa re e ngi neering me thods and techniques has proven to meet reasonable quality goals. Exa mples include invo lving the customer, protOtyping , cond uc ting inspections, and employing incremental so ftware processes.

Give Products to Customers Early Many software projec ts fail because customers are g ive n th eir first look at so ltware too late in the developme nt cycle This was a maj o r m o tivation fo r the Introd uc tion of agi le methods It's virtuall y Impossible to know all the ,equi rement ~ in advance, and invo lvi ng c ustomers as early as possi ble is critica l to ge tting th e req uirements right . Thei r ea rl y invo lve me nt in h e lping to s pecify requirements is very important, but giving th e m wo rking software and having them use it is c ntica l to und erstand ing what th ey rca ll y need. C us to mers ma y think they want a particularfeature, or think th ey want a user inte rface to look a ce rtain way , but un til they ge t a versIO n of software to work with you ca n never be ure . Employ ing l ec hn ique~ suc h a ag ile processes, pro totyping, or incremental processes a llow c ustomers to ge t softwa re into th eir hands early in th e devel o pment cycle

Use an Appropriate Software Process There arc many 50ftware process models, and no si ng le o ne IS appropriate for every ty pe of project . For example, th e waterfall process work, wel l fO I' rrojcct~ w he re a ll o f th e req UIre ment arc well kn o wn up front. Conver.e ly , aHil" and ot her ,tera tive pmcc,sc< arC a il ed lo r w he n fe w req uire m e nts are kn o wn In advan e . Good sofrwar engInee rs and projec t I 'a d c r~ take th e tim e to und c~ t"nd th e type of projec t bei ng unde rtaken and u ~ an aprrop n 3tC model

11

'2

CHAPn:R 1

TtlE GOALS AND TERMINOLOGY OF SOFTWARE ENGINEERING

Minimize Intellectual Distance Th" pnn ,pic say' that (or an software
Inspect Code nm should be extended 10 read "In pect All Artifacts," where artdacis arc defined as any product of the software development process including technica l specificati ons , test plans, documentation , and code. Inspecti ons have been proven 10 Ind errors as early.< possible, increase quality , and decrease overall prOject co t.

people Are the Key to Success H ighly ski ll ed , motivated people arc probab ly Ihe most important factor contributing to the ucees, of a software project . Good people can make up for a variety of obstacles including poor tools, insufficient processes, and unforesee n problems. Good peopie will figure out a way to overcome these obstacles and make Ihe project a success. Poor performers without any of these obstacles will probably still fail. Hiring and retaining the best people is critical to prodUCing high·quality and successful software. So far, we have discussed the parts, principics, and activities of software engineering . Assuming that thesc are understood and assembled, we need 10 understand the socielal responsibilities of software engineers.

1,6 ETHICS IN SOFTWARE ENGINEERING Reliance o n the ethics of software engineers has become an essentia l part of contemporary culture. To take an example, it is simply nOI possible for a car driver to verify and validate the code for his car's cruise control or for a patienl or rad,ologi sl 10 verify the correctness of the code controlling the X·ray machine pOinting at his head. At some poinl, there is no choice but to assume that Ihe software crealed and installed in these and other systems has been implemented correctly, and in a manner consistent with the public interest. This is a matter of ,)hies. The Mrrri.rn- W,h,'rr [ 12J online dictionary defines ethics as, I the discipline dealing with what is good and bad and with moral duty and obligation 2_ a set of moral prinCiples Most disciplines operale under a Hrict set of ethical standards, as published in a cOllcsponding code of ethics, and software engineering is no exception . The ACM and IEEE have joinlly developed a o/flDarr E"9i"rffln9 Cod, oj Elhies and ProJ",ion.' Prac)i" [ 131. The ACMIIEEE·CS Joint Task Force on oftware Engineering Ethics and Professional Practices has recommended the document , and the ACNt and the IEEE·CS have jointly approved Ihc standard for leaching and practicing oftw.,.., engineerins_ The code includes a short and long version , with the shon version listed in Figure I.S. The shon versIOn descnbcs Ihe code at a high level of abstraction . The long version cont.ins a number of clause corresponding to Nch of the e.ght principles in Ihe short version, wilh each clause providing mo,.., details and examples. 80th versions arc conlained In [ 131.

ETHICS IN SOFTWARE ENGINEERING

PREAMBLE The short version of the code summari zes aspirations at a high level of the abstraction, the clauses that arc included in the full version give examples and detail of how these aspirations change the way we act as software engineerirlg professionals. Widl0U! the aspirations, the details ca n become legalistic and tedious, without the details, the aspirations can become high sounding but empty; together. the aspirations and the detatls form a cohesive code. Som..'are engi neers shall commit them elves to making the analysis , specification, design , development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health , safety and welfare of the public, software engineers shall adhere to the following Eight PrinCiples, I. PUBLIC· Software engineers shall act consistently with the public interest. 2. CLIENT AND EMPLOYER· Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. 3. PRODUCT· Software engineers shall ensure that their products and related modifications meet the hig hest professional standards possible. 4. JUDGMENT . Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT· Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance . 6. PROFESSION · Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES · Software engineers shall be fair to and supportive of their co lleagues. 8. SELF · Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the professio n. Figure 1.8 Software Engineering Code of Ethics and Professional Practice SOUrce: ACMIlEEE-CS. Software Engtneerlng COde of Elhlcs and Prolesslonal

Practlc~.

copyrIght

j"l

IEEE.

These precepts have practical conseq uence~ and ca n help guide a software e n gi n ~er toward a course of action when confronted with a difficult si tuation . A few exa mples follow , Example I. Suppose Ihat your manager asks you to joi n a tcam at work and assumes you arc suf~ iently skillcd in J~va . However, you don't know Java , but really want to work o n the project and think you'll be able to learn it quick ly and learn a valuable ski ll. Do you mention your lock of Java knowledge to your manager and risk berng pulled from thc project, or do you say nothing, evc n though your inexperience cou ld Jeopardize the success of the project? Clause 6.05 provides guicance, "Not promote their own rntcrest at the expense of the profession , clrent or empl oyer." Knowing th is , you could inform your manager that you do not currently have the necessaty Java knowledge , but present a case at the ame time for how you will lea rn enough in trnle . Example 2 . A software engineer workillll on ~cvcra l Rovernme nt contracts is "e n ouraged" b management w charge time aga "' ~ 1 the onlraCI wrth I'he h il< h e~t number of available h u", ~ hat do you do? Gurdane (or th rs is provided ny clause 4 04 "Not eng"He rn de cptl"c ~nanc lal Pr.l ti es such as bribety, doub le billinll, or olher inlproper Anancla l pm tl e< "

13

14

CHAPTER 1 THE GOALS AND TERMINOLOGY OF SOFlWARE ENGINEERING

Exomple 3 . You are asked to develop a complex, c ritl 31 pie c of softwa re for a commercial product you're working o n. You di s ove r a publ i do mai n version o f the ' ou ree cod e. You're tempted to use the source code as It will save mu h ti me and effon and allow you to move o nto the developme nt of another Important part of the sys tem soone r th.n expc ted However, It's not li censed to be used fo r commercia l purpo cs . What do you d o] Clause 2.02 provides gu idance: "Not knowingly usc so ftware that IS o bta ined o r retained ei the r illega lly or unethica ll y." These arc just a few exa m pic> of how softwarc e ngi neers can be co nfro nted wit h ethica l dilemmas. H avi ng a se t of guidelines grea tl y as 1st. the e ng ineer in making the ri g ht decision .

1.7 CASE STUDIES Read ing about softwa re engineering concepts alone is insufficient for gai ning a thorough understanding of the ubjec!. The best way to unify and reinforce the man y topics presen ted in th is boo k is to ( I ) learn how they are applied to the development of real software ap plicatio ns and (2) gain hands-on experi· ence devel opi ng a software application as part of a team To mee t the Rrs t objective , case studies have been developed o r described and are presented thro ugho ut the book . They serve as concrete exam ples of software appl icatio ns, a nd include appropriate artifacts as they are discussed and presented in the text. The case studies arc intro duced in the next few sections. T o meet the seco nd o bjective, students working in teams arc provided guidance as the y apply so ftware engineering concepts to the

develo pment of a g roup proJect. As they progress, students will ge nerate project artifacts and working co de. Artifac ts gene rated as part of the case studies can also be used as guidance in developing artifacts for the group project. There are three cases studies used in the text, as illustrated in Figure 1.9 . The Eneo."/tr Did,o gam , is a si ng le·p laye r, stand-alone video game application that is completely implemented through the course of this book in conjunction with online components. In addition , two open source projects are used to illustrate h ow open source prOjects are devel o ped: the Eclipse integrated development envi ro nm ent and the Op",Offic, office productivity suite . Open source projects arc developed differently from traditional software in that many

Encounter (created for this book)

1 Case Studies

Eclipse (open source)

Fllure

1.9 The main case studies used in this bOOk

OpenOlfice (open source)

CASE STUDIES

difkrent !><,ople, from ariou> orga nIza tIons, de . vc\op featun..'S and fun tions and thcn co ntribute them b. I:. to the ba e ·oftware applicatIon . In this wa

an open sourc

appli cation grow in fun l ion.

ality and all ne," fea tu res arc free ly avai lab le for o thers to use and budd o n. Variou o ther examples arc used in this book , includIng a vidco store app \'ca tlo n.

Ihe Jo"i9" character. C haracter> engage each other when they arc in Ihe same arca atlhe arne time. The rc ult of an engagement depe nds o n thc values of the haracters' qualilie and on the locatio n where It occurs. O nce an engagement is complete, the play· er's c haracter is moved 10 a random area . Players can se t the va lues of the lf qual ili es except while engaglOg a Joreig n character. The new quality values take cffect o nly aflc r a delay. •

1.7.1 Encounter Video Game The En o unter video game is a si ngle.p layer, sta nd . alone VIdeo game applicatIOn A player is assigned a main chara ter, and Encounter si mulates all o r part of the lifetime of that character Success in playing the game is measured by attaining a points goa l for the playe r or by the ability of the playe r to survI ve fo r a give n time limit. Figure 1.10 shows a ty pical scree n shot: the courtyard area co ntaining a playe r· contro lled charac ter, Elena. Came characters beg in wit h a nxed number o f points allocated equally amo ng qualities including coneal tration, stamina, inltlligftKt. pali(Jlct. and strnlgtb . The game co nsists of movement among a set of areas. The main characte r moves between them , encountering a game · generated character ca lled

'1,

1.7.2 Eclipse Open Source Project The seco nd case ludy is Eclipse . Ecl ipse [ 14] is an extensible, highly co nfigurabl e o pen ,ounce IDE (integrated develo pm ent e nviron ment). An IDE pro· vide an enviro nment and sct of lools fo r the devel · op me nl of softwa re app lications. II provides loo ls to build , run . and debug app \'cati ons, the abili lY 10 share arllfacts such a code and object WIth a tcam, and suppo rt for and intcgral10 n wi th vcrsion contro l. lkcallse Eclipse is o pe n source, ILS source code and des ign arc fTeely available and readi ly extensible by th ird parties thro ugh the use of plug · in s. In fa ct, Eclipse is co nsidered a plaifo,," . It isn'l a '·flni shed" product, and is intcnded fo r contin o uo us and indefi nite exten io n [ 15]. Numerous open

Figure 1.10 SnapShot (rom the Encounter case StuCly video game: Flena In the courtyard

15

16

CHAPTER 1 THE GOALS AND TERMINOLOGY OF SOFTWARE ENGINEERING

,"cr Interfa e a nd fe atUre set s lInllar to o ther ol~ce ,u ll e> suc h a, M lc roso fl II,ce OpcnOlflce org also wo rk, lran'pa re nti y With a Va rtCIY of Ale formats, Including those o f MI ro solt OlRcc' [ 16 ] A tYPical O[lc n fr, c' >c reen, hot IS s hown In hgurc I 12 The Orc n frlCc proJc 1 encou rages partlcipa lio n by d eve lopers, as ,he tYPical developer-o rie nted Web page ,ho ws in Fig ure 1. 13. We w tll dt<cu,s the management of the O penOfRcc projec t In rart II I. H ere i a summary, quoted fro m a n Opc nOm c Web si te .

fOllnd JI lhe home of lhe

, o ur<:c cx tcn'lons c..a n b

E lip,e ProlC t, www .ceilp ·c org. Eclipse ha, bee n ,ue (",full y used ~, ~ tool for wide -ra ng ing app lic ation t pc, ,uch ", J~v~ d evd o[lIllent, 'I cb services, embedded d cv lcl' programming, and ga me program ming CO il tes ts. T h e Ecli pse plat (o ml itself provides a programming languagc-agnot\ti lofTastnlc turc. uppOr! fo r specific lan guages IS pro Vided b plug · in s, and ea h plug -In must ad he rt· to th e
There a re three categories 01 ac ti ve proj ects in O pe nOlfice.o rg : Acap"d, which

whe re most tl'chni ca l project art: loca ted , [ncubalor. w h ic h hou es ex pe rime nta l projects and e nd eavors, a nd Nalia, -u"'9 , whic h includes proje c ts proIS

1.7.3 Open Office Project

vi d ing info rmari o n, resources, builds/ and forums in a user's nat ive language.

Th e third case stud y that we Will u<e in th is book is Ope nOfRce (ope nofRcc.o rg ), "a multi -p lat form office produc ti vity suite . It incl ud es the ke y d es kt o p applications, such as a wo rd proce sor, spreadsheet,

- .In [fme . arc The Accep te d Projects at a POlOt sh o wn in Figures 1.14 and 1.15.

presentation manager, and dr2wing program , with a

•

, • CD hd'1""

fe"

,"01 II I'

• .,. 'I~III~ ~ ""-('YO'\l • ..... 7

•

U;". ~ I

.. an "

5J f'''_ ~~

•

.,.

o.unl

4 " L .. ..... - : '" """ . Iln.~'or'\OI.Q ... .

""_ 'L-""_ r; •,, •-c-, ..,.......z" _ . ".

· -. ..., . ~

-

"

•• q ,

q u

. ... oJ

_

rt

d o,

.

...._ ' , '''''''' ••• d " .....

•

~ ... _

' " '.II:

. .

. . . .':

..

"

7

~ ...

= ..vfI ....".

.-s,. _Ib-..., ~. 1 .~...al l

-~

,-_ c..

•

»~ -

.

.....

• •

~!)

;Jl....ul

L I'* . ~

. . . .:.:0 . .. ""->

• Rr+

.,rtf .....

8 ,," ' ,, _ 1' " .... •

5'

,

, t ab ' o. "

,",'I' ",

? tar....

'l'!_." " 'A

_

_ _ _ ,,_,.- ' ''1'' Uo. l _ .. , ~. . ( ct •• n ...... k> .... ,.,.,.

· ",.-1\ _' 1'.'_. l"'.

I,.

2 _ ""''':' ....... h<: _' . ~J .

_ '.rla'. ~I

..... "

" 1. 0

'O r

• nUI/I ..... "II_.o.cWl _o- V.., ,_eO. Tlu.1 •

• c.. .... ,~ ..· ~ t • •

It'

Co .~r.~\cc

"I ..a

I~ I \ ' .I

I~I~ · .~ I

••

• •• •• • ••••• ••• ••••• •••••• •• ••• •• ••• •• •• ••• ••• ••••• ••••• •• • ••••• •• • •• ••••••••• ••

..........

.. • ,,·"at _ . ... 'L .. -""'" ·.-," • .

o:'>'>rpo.f"~U'''

: - rl l _ . U . .. 1 OCu~p ... LO'" . rl leV. .. u. l . . oo<.J\. ... _ .

••

. ., •

C<"'!JI . ~'"

.

• ( .... ~ •• _f , - , , _

·, · .

~

,....

, - . . _ I .......

. · _ . 1(-'''''•

~ .....u

../0> .. - 11I..u

• CI'm ..... , . P -

-

• ~UN r

"

•

I

0

,..

,t.

•

~ .. "'Io ....... 11 ~'..... .

•

1M If'~ ''a,d,o. ~ .If ~·

•

IIfId.I". ,I,..

, ~~

. .... ~ ...... ~. .. 11.

' Tr*'

•

FIgure 1.11 A typical screenshot of the Eclipse Interactive development environment

~

CASE STUDIES

" iii • • le 31 .... . 1

I

-

nu s u· an OpenOfI1C c Tal documer.t

•If

•

Figure 1.12 A typical screenshot of the OpenOffice word processor

-

•

d

-

Ruourc.~

SurnnHomc list' SUM, (en) Consul't01nlS SuMY

Mit 1'1 0 LIII,I OOCIIIMMill -1Jn I S!)VfU CCdt

Thank you!

Opcnom ce.ofg : An Inlmdurtfon Ab(!1It tb Qotvm~nU! IOf!

QP':nQ!!i( r

rn J

Otg

NU!,h• •

Wher. to 10 from h' f. W. M, yOtJ 10 ""'Mt wit.c 1 ~' Q ;:,nOma Qrg"""DSJI"O gfn acquaonled WUI 0lJf c~ ,. OIJI ptOflCl' and our way of brng You should Coro.llMI m411'19.At !rIISIM'?'!, to 0pen0l'IIc.. 01]. Iht /!kmA Us P'gt . 1M DorWDfnli1'2n. lht Op"nO!!}!;' gIg ID' NysH,,' pllge. W lhe P'Sart, ~ Then you mighl consllife, 'Inldpdn!) Our cOtJ\lTIlJnlly If open for atlJor;e 10 pMJaolhf No matstf If you II1t fIG( • i»Uv"rntnet 01 a Itchn,cal orieratd person, ttlilt lJ II pitH fOf you In Oft. Of I\"\Of't of OUi PJOJKfS 10 htlp the d .... lopmtnl. mpro..lI'Ilrd Of p1orTIollOfl 0111'1, OpenC)!F,ct 0" " . . . . . . 'l.IIIf

By VI, 1111 of t~,

Webt"' , tOY :agrtl 10 ~ bound by Ihn. Po tNt: IT)(I •

firm' Qf Un

Tho W ~'P IniO 11'1, p.nlClp.ahon IS by tvbscntll1'l910 ont Ot mol' dour nwting ~1t1 piCj.Cl(t) ~ fHI you I;iln h.M • cOl'llnbuJ lon 10

!PI''''' !1'I_

8t1ow otl. 5OfI'\f of our m*'9 1m. that nvgl'll bt fA V'dtfHl F 01 • MI ~lI\g plU M -cit the MI,t'"' US" pag. on OpnQk. R'q "b ...

I. " p rlC ?,

1

t nt . . . .

....... . .. ; LIl . . . . . . 01 2 oOIl1ee org

9'

' ytJI"

'om,...

..... (rd art

i)1

yG,I,.... ,...,., ...... ......,

Figure 1.13 Typical OpenOffice communication with development

-

17

18

CHAPTER 1 THE GOALS AND TERMINOLOGY OF SOFTWARE ENGIN EERING

... ~ '5

"em (ramewcrt

Mllbecs "",,[, ".arne.crt ,ml'O

Dotsn.r Atrir!tgg!sand fnylRM\tO l

tOOls

M@!l" HoBmICbcl

db,

frW

Scboenhft!!. DO. RPbll!;[

"t.t"'"

(fK t~

Dos:ument,uQD

scopn Ctq

documt,.,tttion

End·UHr docu.... Up ap.nOfficu"V·

k lrml!

MiOia

'ICtemal

This pr'CIJ.ct will ho,t .. lh. __ tem.

V¥IOVS

c:onlpOittnu ~

C:(IIM aIow~

Honms,hr! (K Il09)

11'11 Ahrrn, . Chosl,.!)

\jrM!ht, SYit'm I tytr

ChaSSQf prof MIt •.

••

H,DOH Pgbfng

PO Y09l;t.

Figure 1.14 Accepted OpenOffice projects at a point in time. 1 of 2 SOUrce: OpenOfflc.e. http://projects.openofficeorgtaccepted html

!

Pitt.

'Y"/lfS'P'

-

liOn

,Nwhtng

MartetllQ

-

The POJKt I\.nt. '''0 ow 9uwth -.d use 01 0) lilCimc. oPt tK~" . errc.u iI'K'tudIt: dItv,' ,.- .. eol'teroll. ':If1I, pot'r: outt...ch. PonWig to ,..... ~t1'oii'iS .

C),IIity AmI..ce: t . .mt and

o;.:nO....OI9

801Ml.r. SCRtt CIII. Cgn:Ion Sh!.!m

lM'1a

Sr..skbg' YoX'D" CgntBl'

"'*"

fih

Nlbtl ,

~

The",,!'

Q',"fwlC'l9" tIuiIdI of

'.,.t ... ' ertlan.

Rithi.

;sal'tlya:c-.. ce,'j It tltlo

. .. ,.

MtUn u .,·"Sb,

.".,

.

I.U: 10'''''0

--

uti

LAII.JiWIIIM:

Pet!',

-

•••

..

...

.. $ 12 • ~.

-: ... _-_ ... i TIl.

or 1M PIrIIjICt.

11= wad ... C~

Figure 1.15 Accepted OpenOffice projects at a point in time. 2 of 2

1.8 SUMMARY Developing complex software systems in a successful mann~ r has historically been very difficuh. The goal of software engineering IS to define a fra mework for creating software systems that are reliable, efficient, and maintainable, and meet the needs of customers. As illustrated in Section 1.2 on software disasters, producing software that is unrel iable ca n have catastrophic consequences Although most software does not end in disaster, care mu t be take n to avoid the many commo n pitfa lls and mistakes that can plague a software project . The 4 P's of software engi neeri ng-people, product , project, and process encompass the different aspects of defining, building, and mana gi ng software. The people arc the mo t important part , as they not only create the software but also are the customer for who the work is bei ng do ne. The work products include not only source and object code , but also a complete set of artifacts descri bing the system. A software process model dennes a framework for ca rrying ou t the di ffe rent phases of a software project. It imposes order and stnlCNrc to a project. Underlying software engi neering is a set of time- tested principies. KnOWing these prinCiples helps to understand the mo tiva tio n for the softwa re engineering methodology presen ted in this book Software engineering is a profession that carries with it certain ethical respon ibilitles. The ACM and IEEE have jointly publi hed a code of ethics to he lp gUide software prolessionals in their work . This book uses three main case studi es throughou t as realistic examples of software project

1_9 EXERCISES 1. Besides those listed in this chapter, what additionai expectations do you think oft-ware products

may fail to meet? 2. Research a rece nt real-world "software di aster." In you r own words, describe the underlYing cause of the problem . What could have been done to avoid itl 3. What ar~ the four P's of software engineenngl (Reca ll them without consulting the book .) BneAy describe each . 4. In a paragraph , name at least two of the most impo rtant deficiencies you can think of In the rrporil"g of project progress that co ntribute to an unsuccessfu l projec t outcome. 5. Expla in

myour own

words why people arc invariabl y the most important resource o n a project.

6. For the stakeh older groups listed in the text, give an example of a project mOllvatio n fo r each_ 7. You arc developing a second-generation custom order entry application fo r a particular customer Explain and give examples of at least two types of problems that can arise if the customer is nOt involved in defi ning the new applicati on, and their first use of the application i after it i com pleted 8. Why does the use of standards make it eaSier to ge nera te usefu l, re liable docum entsl Wh y isn't their use a gua,".'t< that hi gh-qual ity docume nts "ill be produc<:dl 9. Expla in the di ffe re nce between a oftware process and a so ftware process model. 10 . Figure 8 lists the ACMlIEEE Sojlwart E"gi"rrri"g oJ, oj Elhics .IId P,ojtS5IoII.1 P,ac';Ct. Drawing eit her fro m your own expe ricn c~ or from a hypothetica l Si tuati on , aescribe a sce nano that adhere to one of the e ight pnnclples. Now describe a sce naroo th at Violates o ne of the pnnClple<>

Metrics in Software Engineering

PlaMlng

The Software Development Ule Cycle

•

What does ·sohware quality" mean?

•

What are ·defecls· In applications?

•

What IS the difference between verifica tion and validation in software

development? •

How do you measure software

quality?

o.Ign Figure 2.1 The context and learning goals for this chapter

Budding sofTwa re that ex hlblt< a lu gh level of qua li ty" one of the majo r themes of till book and !< J c rll lea I faClor in the produ t,on of ,"cce"fu l
22

HAPTER 2 INTRODUCTION TO QUAUTY AND METRICS IN SOFTWARE ENGINEERING

Planning

Maintenance

Phaaes Requiring Quality and Metrics Requirements / Anal is

J

IDesign I

Integration and System Testing

Implementation and Unn TesUng

Figure 2.2 Software development phases requiring the application of metrics

These mea
2.1 THE MEANING OF SOFTWARE QUALITY Everyone wants "qua lity," but what exactl y does software quality mean] There are varying views o n this. Some measure qua lity in terms of categories such as reliability, portability, and so o n. H owever, if one of theseportability, for exampl e-is not a requireme nt o f the product in any fOffil , then it is not releva n t. Some feel that the mo re an application c han ges the wo rld for the better, the mo re quality it possesses. Others defi ne oftware quality in temlS of how well a development process is followed , or how ex:ensively the emerging product is tested . Ultimately, it is hest for a n o rganization to defi ne fo r itself and its cu.stomers what it means by "quality ." Above all, it is importa nt that "software quality" has a consistent mea ning within the project's stakeholders. A definition fo llows that will be used throug hout th is book. To give some background, let us first co nsider a "quality" plain old -fashioned lead ~ n ci l (frequently yellow). All would agree that such a pencil mu t first sa tisfy its requirements, typically including that it ·shall be solid wood; shall have a lead core with designated hardness; shall have an era er that can erase most of what the lead has deposited o n plain pape r, shall have the required leng th; etc." To be a 4uality o ld-style penci l, however, we expect additional attributes suc h as that it is "harder than usual to break, lasts twice as lo ng as average pencils, has a very cf/cctive eraser, etc." To summarize, a quality co"vrnlio"al item has attriootes beyond its requirements. In software engi neeri ng , however, this is "01 the typical definition of quality. What is different about software appli cations is that they inevitably contain defects. Every defect is a deviation fTo m requi re ments, regardless of whether the requirements are carefully written down . Hence we cannot think about the quality of software the same way we think about the quality of a lead pencil. Instead, a good deR nition of software quality IS the follOWing:

The more closely a software product meets Its requII'ements, the hig her its quality .

Figure 2.3 illustrates thIS view of quality .

DEFECTS IN SOFTWARE

100%

Requlr •. ".nte

(."4 ren. Ind ~) \ ~

0%

, \ I I I

Typical quality focus

I

Figure 2.3 The meaning of software quality: the degree to which the actual requirements are met .$Otft'e. Q~ucs reoroctuced Wtth Dell 'us.s.'on from COfel

We have not yet di cussed how requirement are gathered and generated . For now, let us as ume that requirements arc generated with the be t kno wledge available during requirements analysis . Even in this case, after the software has been developed and the product has been shipped to custome rs. it may be discovered that some requirements are in fact incorrect or missing . In these cases the software is co nstructed usi ng the requirements as documented, and we would say the software meets all its ncplicirly specified requireme ntS but .t may not fully satisfy its customers. There are a number o f di ffe rent ways thi s can happen . As an example, if customers are not consulted during requirements den nit. o n the system i constructed without their input. When they eventually usc the so ftware they may nnd it does no t function as they wish and are dissati fleet Even if customers are consulted and provide input, it is possible they will sti ll be di ssatisfied o n using the software. For example, suppose that a software system implements a user interface, with scree n layouts and menus specified in a requirements document . If customers are not given an o pportuni ty to use the interface before the product is released , they may nnd that what appears to work well o n paper is actually cumbersome to use. In these scenarios and others, we would say the product docs nOt exhibit high quality because it does not satisfy the customer. Therefore a mo re compl"te definition of quality \~ould be,

The mo re closely a software product mee ts its specined requirem ents, and those reql11rcments mee t the wants and needs of its customers, the higher its quality .

T echni ques for gathering requirements and ensuring customer . atisfaction arc covered in Part IV an requirements ana lys.s. Besides the benent of custome r satisfaction, producing high.quality software provide · other adva ntages It has often been shown that a correlation exist betwee n products with the least number of defects and the honest schedules. There .s also a corrclaiion between poor quality and chedulc overruns, and hetwee n poor quality and increa
2.2 DEFECTS IN SOFTWARE A dt/a:l1Il a pha,., of software appl.ca tion .s defined a< a dev.at .o n from what'< reqUIred for that plu e. In pr.1 l1 ~e , most software system~ Lo ntaln def· t, and therefore do not ent.rely meet their rcqlll rc meOl\ TI,e software d.S3stc...., described.n hapt r I i1lu
23

24

CHAPTER 2 INTRODUCnON TO QUALITY AND METRICS IN SOFTWARE ENGINEERING

Idellllf InR and remov ln ~ a, malty ddc to\<;blc, a. ea rl y as pos"ble, throughout produc t development, eithcr b ' ,nspccho n 0 1art lfa ts or te,'lng of the system For examp le, II ,oftware 15 ,n the ImplementatIon phase, the code Illa d viatc fro mthe>ofiW'lre de,,!!n f> roduced In the preVlou deSIgn phase, o rot may be coded in soc h a way as to produ c an incorrect out put n,e Ie
2. To remove as many of these defects a ea rl y In the development process as posSIble.

T o the A,,; t pOint , defec ts discovered and «'paired durin g softwa re development will no t be found by custome,,;, of cou,,;c. The more defec ts that ca n be removed , the higher the quality of software is likely to be, and the mo re the cu tomer will be sati sAed . T o the seco nd pOllll , as softwa re is developed a nd defects are introduced (which is, in practice, Inev.table ). the earlier they arc discovered the less they cost to repair. Acco rd.n g to Boehm [2J and o the,,;, the cost of defect repair after software is released to custome,,; can be 100 times greate r as compared to Axing the same defect early in the devciopment cycle. Various studies show various cost esca lat.o n factO";, but they all rep ort a dramatic rise in the cost of detection and repair. Figure 2.4 shows o ne est. mate of the relative cost of defect repair during each stage of development . Fo rc xample, if a defect is Int roduced dUring the require ments phase, assume that itcosts $1 to detect and repair if done during that same phase. If it slips through to the implementation phase, the same defect will cost $20 to rcpair. If it falls all the way throu gh to mai nte nance, which is when custo m",,; arc using the software, the cost can be $100 to repair. The reason for this .nc rease in repai r cost in subsequent phases can be illustrated with an example ( I ]. Suppose you have an application that perform s a large number of Alc reads and writes . As part of your devclo pment process, at the e nd of the design phase you conduct an inspection of the design and discov"r two defects: o ne in the algorithm that performs file reads and writes; the other in the allocation of memory to ho ld the file records. Assume that the work required to fix these defects after the inspection takes two days to complete, and the steps take n arc as fo llows: I . Mo dify the algo rithm to

fix the defect.

2. Conduc t an inspec tion o f the reworked design to verify its correctness.

Requirements

~ ~

O••lgn

Malnr-nee

1-- Implementallon _

T..t

filii" 2.4 Cost of detecting and repairing a defect during maintenance, depending on the phase in

1/1ieCled

VERIFICATION AND VAliDATION

Suppose, ,"stead, that the defects went undetected and pas~ed through to the implementation phase. The dcf«ts would be: harder to detect and could now affect several hundred lines of code. If the defect5 are detected during a code inspection, the work required to Ax them could take a week to complete. The step required would be: as follows : I. Modify the algorithm to Ax the defect.

2. Conduct an inspec tion of the reworked design to verify its COrr«tness. 3. Recode the affected portion of the code . 4. Conduct an inspection of the reworked code to verify it is correct and co nform s to the re wo rked design. Suppose now that the defects went undetected and pas cd through to the te n ng phase. The defects would be even harder to detect and now take more time to fix . In addition to the o nc week reqUired If found during code inspection , the following additional work would be requ ired : 5. Assistance from the tester to recreate the defects. 6. Discovery of the exact cause of the defect within the software. 7. Dedicated machine time to support debugging . 8. Retesting the fix to enSure it works correctly. These activities can take an additional week to a month , dependin g o n ho \" dlrflcult it is to isolate and repair the defect. This example Illustrates the cost of not detecting and re pairing defects as close to thei r injection as possible and wh y every eHort must be made to detect and repair defects as earl y as possible .

2.3 VERIFICATION AND VALIDATION Software verification and validation (V&V) is a process implemented througho ut the software li fe cycle to ensure rhe 101i0wlOg. I. Each step in the development process is carried o ut co rrectly . Thi s is ailed v"ijica lio .. .

2. Each artifact produced meets its requirements as speci fi ed in pri o r phases. Th is IS ca ll ed va/ldalion . The IEEE Glossary [3) defines these terms as lo llows. Verification: 'The process 0 1 evaluanng a system o r co mpo nent to detennll1e whe ther the produc ts o f a give n devel o pme nt phase allS fy th e conditio ns impo cd at Ihe start of th at phase." Forc xampl e, is the soltware design sufficient 10 impl ement Ihe preVIO usly speCifi ed requirements Does the code full y and correc tl y Imple ment the d esi g n ~ Validation : "T'he process o f evaluating a sys tem o r compo nent durms o r at the end of the develo pme nt process to determine whether It sa ti fi e pecifi ed reqUirements." In o ther wo rds, does the Imple me nted system meel the spe Ined user requ ireml'l\lsl Vcr;fira llon .. om parable to keeping your balance current 111 your he kbook based o n vour dall actl It ' As you Wrtlc c hecks and make deposit , you c nt erthe amount In the c heckbook register MI d upda te the balan c

25

26

CHAPTER 2 INTRODUCTION TO QUAUTY AND METRICS IN SOFTWARE ENGINEERINQ

h time u make an entry you heck that your anthmetlc " correct and your new balance I~ right Thi, IS anJlogou to e n,uring that each phase ,n the ,ofiwarc devclol>ment procesS is camcd out correctly ValidallD" I omparab lc to balanein!! yo ur he kbook when the bank's statement amves. You match all the tr," ". lion in thc monthly ,tatcment wuh those In your rC!!'ster, ensuring that nonc have been omitted or entered in orre tl y and that the tran action amounts In your regi ster mat h those in the s tatement. In addition, you vahdate that the ending balance in your regl ter matches that in the statcment. Even thoogh you kept your balan c up-to -date, ml~takcs may have been made. Validallon cat hes those mIStakes a nd ensureS the correCtness of yo ur balance. This IS analogous to testi ng of a software system . The twO l11alO activities invo lved durin g V & V are inspection a·nd software testing. Inspections, and

1:..

also review"' . arc verification actlvitic and involve peer examination

or projc

t artifacts ( requirement s. deSIgn ,

code, etc.) to discover clefc ts. The idea is to And as man y defects as pOSSible as ea rl y as possible. Inspections arc covered in greater detail In C hapter 5. Testing is the principal part of validation . oftware testing IS primarily a validation actiVity, occumng at the e nd of a development cycle to ensure that sofrware satisnes its user requ ireme nts. Testing involves providing the system with a sct of inputs, and validating that the system behavior and output matc h what is expected. Any deviation from an expected outcome i, considered a defect. Te ting is covered in detail in Part VII. ote that it is a combination of verinca tio n-primarily in the form of inspections and validationprimarily," the form of testing-that consistently produces high-quality software. Testing alone is not ufncient. No matter how talented software engineers are at fixing defects, if the quality level is low entering validation , as measured by latent defects (tho e present but not necessarily known ), there IS a high probability that va lidati o n will take sig nificantly longer than expected and the quality level will remain lower than desired . As many defects as possi ble must be removed from the artifacts before validation begins. V&V and quality practices, as they relate to each major software phase and activity , is included in the quality chapter ncar the e nd of each part of this book . Figure 2.5 summarizes these V&V concepts. To reinforce the verlncatio n/ validation distinction , let us perform V&V on a simple example. Suppose that the customer wants an application that "solves linea r equations of the form ox + b = c: We translate this into user requirements such as ;

1. The user shall be able to input numbers a,

b, and c up to

10 digits each, with up to four places following

the deC imal point. 2. The application shall produce a soluti o n to the eq uation ax mathematically exact answer.

+ b= c

that is within 1/ 1000 of the

The n we implement a program to satisfy these requirements .

• Verincalion: Ensuring that each artifact is built in accordance with it specincations - "Are we bUilding the product righd' - Mostly inspections and rev iews .

• Validation:

hecki ng that each completed artifact satisfies Its pccincations.

- "Arc we bUilding the right product)" - Mostly t""', ng.

Agure 2.5 Verification vs. validation

PlANNING FOR QUALITY

It i our respon ibtiity to ensure that we have butit the application correctly by checkinll that we proceeded appropriately (rom the begInning of the process to the end , Th,s is the IJtriji,alio" process. For convenience, we will number the development ph ..es as follows . I, ~t the customer's req,,,rements. 2. \X/Ole down the requirements in detail. 3. Obtain the customer' approval o( the requirements statement. 4.

Code the application . (For Simp licity , we have omitted a desIgn phase .)

5. Test the application . Verincation checks the following questions, I. Do the requirements express what the customer really wants and needs, Some verification issues here arc as follows , Is ax + b = , the correct torml What are the precision requirements] What i( 0 is entered for al 2. Are we carrying out the process o( obtaini ng the customer's approval in an appropriate manner) Some verification issues here arc as (ollows, Are we allowing the customer adequate time] Are we exp laining all needed terms to the customer) 3. Does the code implement the written requirements in every respect ] Thi s requires an inspection o( the code itself, in which the requirements are considered o ne at a time and the matching code is perused. This could include a mathematica l proof. (Strictly speaking, verincation does not cal l for executing the code.) 4. Do the proposed tests adequate ly cover the application ] For an application o( realistic Ize, this would include an inspection of the test plans, test cases, and te t procedures . Th,s is se parate from te ting itself, a validation Slep discussed below . Val idatio n of, this product consists of obtaining the customer's approval o( the wrillen , completed requirements and executing a set of tests on the comp leted code . For example, we enter a = I , b = I, and c = I , and validate that the program produces x = O. To summarize our diSCUSSIOn of the VII< V process , at any given mom(:t.ll a oftware engllletr is eIther creating an artifact , verifying it as he does so, or va lidating a completed artifact . nlis is illustrated in Flsure 2.6.

2.4 PLANNING FOR QUALITY SlIlee quality practices arc implemented throug hout the software life cycle , it " Important to expre s qualit app ro. he~ and goa ls in writing ea rl y in a project- in other words , w~ 1I hdore thc goals arc used in tracklll!! the prOJect's quality. Agile projec ts emphasize the allalllme nt of qualtty through o nt inual intcra tl o n wllh tlw ell,t omer III person, -arly ImplementatIon , and conllnual , cumulattve te tlng. Tlte IEEE has published several
28

CHAPTER 2 INTRODUCTION TO QUAUTY AND METRICS IN SOFiWAR ENGINEERING

l

k

PartiAlly comploled

Artllect

undor construction

A, ,

,,

arlilaci

Process

'1

" ,,

, Creation •

,,

,,

,,

Compleled artifact

Process

I

/

,,

Venfication

Validation

I

,

,,

,

, , ,

I

,

,

,,

,,

, ,

,

/

"

Software engineer

Figure 2.6 verification and vahdation of an artifact: before completion vs. after SOUrc"

Graphics reproduced with permission from Corel

included ,n th e pla n arc listed below . Details of the SQAP are covered in Chapter 5. The plan includes the following , • The organizati onal stnlcture of the quality team

• A list of documentation to be crea ted governing the development , verification and validation , usc and maintenance of the software (e.g., software requirements speCificatio n, verification and validation plan, so ftwa re deSign pecification, etc.) • The defi nit ion and schedule of inspections to be conducted and how they are to be conducted • The metrics to be coll ected, monitored, and analyzed • Reference to software test plans • H ow problem reporting is to be managed and conducted The V&V Plan is t he manner in which the So ftware Quality A'5urance Plan is supported by verification and validation . The IEEE has published a Software Verification and Validation Plan (SWP) framework (IEEE Std 10 12- 2004 ) to assist in documenting the speCific V&V practices to be implemented. The contents and application of the SVVP are covered in C hapter 9.

2.5 METRICS Metrics arc numerical measures that quantify the degree to which oftware or a proces possesses a given attribute Examples of metries are "defects pcr thousand lines of code" and "average software module sizl': Metrics are collec ted and anal yzed throughout the software life cycle, and help with the following , • Detemlliling software quality level • Estimating project schedules • Tracking schedule progress • Determining software size and compleXity

METRICS

• o.,teml1ning proJecl co I Improvemen l

When gools such as software qualily level and project cost are not expressed specifically enough, they m. be subje t to differing interprelalions . The,e difference can ause confusion and conAiet . For example, a goal stated as 'The application should crash vcry seldom" is not specific. How do you measure "very seldom"? Is it once per day? Per week? Per year? A more preci e goal would be 'l1,e application should crash no more than 3 time per year: Stated this way, the goal is not open to interpretation and is measurable. Without quantifiable, objective measures to provide visibility into a project it is difficult to measure a project's progress in terms of wh"'ther it is on schedule, whether it is meeting its quality goals, and whether it is ready to ship to customers. In addition, "you can't improve what you don't measure." Continuous improvement of an organization's processes and software is predicated on collecting metrics and selling quantitative improvement goals for future project . To be uccessfully utilized , metric collection commences at the onset of J project and continues throughout the entire hfe cycle , through maintenance . Metnc collection and analysis can take a significant amount of managerial and engineering effort , but the payoff is well worth it. Software metrics can be classified into two broad categories, prodlici metrics and proms metrics. Product metrics measure characteristics of the software product , o r system , including its size, complexlry, perform. ance, and qualiry level For example, size can be expre sed in the number of lines of code, p"jormancc as the number of transaction per second , and qua lily I,vel as number of defects per thousand lines of code, which is commonly referred to as defect density . Process merrics measure attributes of the software processes, methods, and tools employed during software development and maintenance of a software sy tem . Process metrics include project effort, schedu le adherence, defe I repair rate, and productivity . For example, proj,el 4Jorl can be expressed as the number of person months of development , and d,Jrcl "pair ral' as the number of defects repaired per week. Many other metrics can be collected, and they arc di scussed in grea ter detail in the quality and metrics chaplers later in the book . Chapter 9 describes metrics collection and utilization in more detail. The next section discusses metrics and their use in measuring quality

2.5.1 Quality Metrics Since quality is the degree to which oftwarc satisfies its requirements, we must be able to measure thi s degree of compliance It.s useful to identify a set of software quality mEtrics, whic h arc a subset of the total metric collected for a project, These metrics are peclAcally focused on the quality characteri
D4,,' 4tHsily IS Ihe number of defects relative to the so ftware ,izc

_ 12 C is tYllicall y "xpre
29

30

CHAPTER 2 INTRODUCTION TO QUAUTY AND METRICS IN SOFTWARE ENGINEERING

qu~ill . III gcncral. lhe hill her lhc defe I den-Ily , lhe lower lhe qual,lY OrgnnizallcJI" tYPIc.,lIy characterize

defe "h I ' pc or hy ,everily, 10 distlnl(liish lhelr relative Importance n,c followlnK I< an example of how a 11IgIl-<eveni defc t would be dcllned and of a quailty goa l based on the definition. A la,< I ddc I IS deRned as a reqUireme nl lisled in seCl lo n 3 of the oftwarc ReqUirements peCll alion lhallhe appilcatlon fails to sat"fy The app l ic~ lion
2.6 SUMMARY Quality o;oftware is a major theme of lhis book . Quality can be defined as "the more closely a software product meets the wants and needs of liS cuslomers." There are many advanta/!es to produong quality software ",ciud",g Increased customer satisfaction, reduced developmenl hedules, and reduced project OSL Quality practttt< are implemented at the beginn",!! of the software life cycle and last through product release into maintenance. Defects in software a.re deviatIOns from requirements As many defects as possible hould be removed during product dL"Veiopmcnt, so these defect will not be delivered to C\I tomers. The earlier in lh" life

BIBUOGRAPHY

cycl~ dckcrs are d~tc tcd, the casler they are to repair and the less they cost to flx . Studies have shown that ddc:crs d ll'Cted and n:paln,"d after software IS released to customers can cost up to I 00 times as much as if the same defects were repaired shortly after they were introduced. Verin ation and valldallon (V&V) is a process lor verilying that artifacts produced dunng the life cycle contain a few defec ts.s po sible and validating that software satisAes its requirements. Verincation answers the question. "Are we build,ng the product righo" Validation answers the questIon , "Arc we bUilding the right product · Metrics are numerical measures collected throughout the software lile cycle, and quantify the degt'ec to which software and processe possess certain allributes. They help with determining quality level , estimating schedules, tracking chedu le progress, detcmlining software size and complexity , determining project cost, and improving processes. Metrics related to quality include defect denSity, mean time to failure , customer problems, and customer sa tislaction.

2.7 EXERCISES I. In addition to the reasons stated in this chapter, name at least two other advantages to producing

quality software. 2. It has been noted that the later in the lile cycle defects go undetected, the harder they are to discover and repair. In your own words, describe two reasons why this is true. 3. (a) Describe in your own words the difference between verificntion and validation . (b ) What are the advantages and disadva ntages 01 speCifyi ng a V&V plan before a plan for conducting your specific project? 4. (a) What are metTics? (b) Give a reason why you understand metrics to be important. 5. (a) In your own words, describe the difference between product and procm mCtncs. (b ) For each of the following objectives, state a mctric you would use to help in achieving Ihe objective, state whether it is a product or process metric, and exp lain how it would be applied. i. ii . iii . iv.

Avoid project schedule delays. Measure continuous quality improvement from one project to the next. Identify software parts that are exhibiting quality problems. Establish a baseline for improvi ng schedule accuracy .

BIBUOGRAPHY J WhJllcn, NC.iI, "Mu""~1119

SoJllDUrt DCOf/oPMOlI ProJteb," John Wiley b ons,

p 195 , 1995

1 Both-m. Barry, '"S4Iwart EI191n''''"9 EC01101f1IC1," PrenllcC'·I-bll, 198 1 1 "JE.EE S~ndatd lo,,~ry of So(IW'tuC' E"f'(InCCnnH TcrmlnoloK)'." IEEF. td 6 10 12· 1990, D ece mber 1990, pp 80·S1 4 K.in, Stephen N . 2003, "Mtlfln "rId MoJtls '" fllmlfr Ouo/rly EI19""rrrtfg, $ccond Edi llon, Acld,\.on.W C'... IC'y, Pt"Jl"'Son Edu

.)1101'1

In .

pp 86- 100 S GiGO SylU:nIS, G.u:tomer S,un.f"cllon Metric", hllp IIwwlII f.. 1~() com/wC'blibouva 501<1 208laoou l.ISCO_ClpproJ l\..to_ Quilhtv_ CU)Wmcf,Jal_ wrvcy html l .. <xclIi\oCd Noy 4, 200C>J

31

Software Process

....nlng

The Software Development Ufecycle

•

What are the main activities of software processes?

•

What are the main software process types?

•

How would a learn such as a student team go about setecting a process?

Figure 3.1 The context and learning goals for this chapter A software project progresses through a se ries of activities, sta rti ng at it conception and con tinuifl8 even beyo nd its reicllsc to customers. There are numerous ways (or individual and team s to organize these

activities. T ypically, a prOject is organized into pba,es, each wllh a prescribed se t of activities conducted during that phase. A ",flu/art proces, prescribes the interrelatio nship among the phase byexpre sing their order and frequency , a well as defi ning the deliverables of th" project. It also speciRes criteria for moving from one phase to the next. Specific software processes, called software process ",odd, or life cycle modds are described. Th is chapter is o rga nized to first des ribe the individual activitie of ofrware proce ses, and thcn to describe process modds the variou ways in which these aCtl vi lieS can be pursued In addition to the activities prescribed by proce s models, there is a et of ge neri actiVities, called "mbrdla acIIV";es , that are implemen ted throughout the life of a proJect. For instance, projec ts contain certain

THE ACTIVITIES OF SOFTWARE PROCESS

risks th at if the cume 10 pass ca n affec t the uccessful outcome o f the so ftware. Risks need to be identiAed , mo Ol tored , and ma naged thro ugh out the life of a project. Th is is an umbrella ac tivity known as risk management Ot her umbrella activities include projc t man age me nt, con Agu ratio n ma nageme nt, and quality manage me nt. Project ma nageme n t is covered in Part III , con Rgu rat ion ma nageme nt in C h apter 6, and quality man.geme nt t h ro ug ho ut, but especia ll y in Pa rt VI1. People someti mes associa te process with overhead, unnecessary pape rwork, lo nge r schedul es, and so on. In other words , they fee l that process d oesn't add v.lue, o r wor e, tha t it adversely affects the success of a projec t. Whe n imp le me nted incorrectl y, sofrware processes ca n indeed lead to undesirable results. H owever, as " 'e explain in th is c hapte r, if p rocesses are applied with a degree of flexi bil ity and ada ptab ili ty , they are o f grea t be ncAt a nd invaluabl e to the successful o utcome o f projects. In certai n situat ions, a versio n 01 working softw are contain ing a subset of th e overall pro duc t func tio nal ity is req uired earl y in the overall schedule. This versio n of the emerg in g pro duc t, called a prototypt, typ ica lly impl eme.nts fu nc ti o nal ity th at is deemed a risk to the project. T y pica l rcaso ns to bu ild prototypes include provi ng tec hnical feas ibil ity and validating the usab ili ty of a user interface. Pro totypes are covered III de tail in Secti o n 3.2.3. I. T o rei n fo rce the contents of th is c hapte r a nd to provi de gui dance to snlde nts at the sa me ti me, thi s c hapler e nds with a sectio n devo ted to getting stude nt teams started with a te ml projec t.

3.1 THE ACTIVITIES OF SOFTWARE PROCESS Most software process mo dels prescribe a similar set 01 phases and ac tiv ities. The differe nce between models is the orde r and freque ncy o f the phases. Some process models, suc h as the wate rfa ll , exec ute each ph ase o nl y o nce. O the rs, suc h as ite rative mod els, cycl e throug h multiple times . This section desc ribes th e phases that are prevale nt in most softwa re process model s, and is summarized in Figure 3.2. Th e ph ases in Fi gure 3. 1 and Figure 3.2 are ide ntical , except that Fi gure 3. 1 co mbines ince pti o n and planning . The partS are explained bel ow. SpeCific process mo dels a nd h ow they impleme nt the phases are covered In Section 3.2.

1. Inception

Software produc t is co nceived a nd d eA ned. 2. Planning In itia l schedule, resources a nd cost arc dete rmined . 3. Requirements Analysis Spcc ify w h a t the ap pl ica ti o n must do , answcrs "what7" 4. Desig n Specify th e parts and how they fi t; a nswer< "how7" 5. Imple me ntation Wri te the code . 6 T esting Exe.::ute the app il atio n with In put test data 7 . Mainte na nce Re palf d feets and add capabi lity. Figure 3.2 The main phases of a software project, showing Inception as a separate phase

33

CHAPTER 3 SOFTWARE PROCESS

Inception

(

.

d Wh h Th, Is the phase where illlti31produ t Idca, arc formulat ed and a Vl
be built. Malor hlllctio naloty and project cope is deAned . Target customers and market segm~nts are idcntlAed . Customers and takeholders may be con,ulted (o r hl gh . level Input Into software functlonaloty. However, stakeholder involvement at LillS stage ,s doffere nl from that during the subsequent requirements analy is phase. Dunng Inception, the goal i to galher very high level feedback. As an example, suppose a company is considering budd ing a video store applicatio n. A market ana lysis may be conducted to determIne the existe nce of competing video store applications. A summary of their features and an analysIS of their tre ngths and weaknessc is compi led. The commercia l uceess o( the propo cd application is determined by identifying potential new customers and contacting them for Info rmation concemlng, • Their satisfaction with their current application • Ideas for needed fun ctionality and feature • Their likelihood of adopti ng a new product As an example , suppose that a currenrly deployed ystem requires custom hardware, but potential customers would prefer using standard Windows PCs. Based on this analysis and feedback , the need for and Viability of the proposed applocation is determined. If· it is deemed prom iSing, high . level functionality for the application is deAned based on the feedback received, and the project proceeds to the planning phase.

Planning Once a high . level idea for the application is developed , a plan is formulated to produce it. Since this is still very early in the overall life cycle and detailed infom,ation is not yet available, the plan will be a rough estimale. However, some plan must be in place to understaAd the scope and cost of the project . A project plan that ide ntifies the high.level activities, work ilems, schedule, and resources IS developed. From this informatio n a cost estimate can be developed. This ste p is very important to determine the feasibility of a project . For example, if the cost is deemed to be too high , a reduction in features may necessaty. If the product release date is too late, more resources may be added It is critica l that the e types of problems be identified as early as possib le so corrective action can be taken . The results of this phase arc typically captured in a oftware Project Management Plan (SPMP). The SPMP and project management are covered in Part IV. Because the plan is only a rough one at thi stage, it is necessary to modify and adapt it throughout the lofe of the project. For example, suppose that during subsequent requirements analysis potential new customers arc identiAed and additional functionality is requested. Using the video store application as an example , suppose a request is received to add additional workstations to stores so customers can retrieve detailed movie information, such as release date, movie

studio, cast, director, producer, genre, and so on. This new fun ctionality may require additional proj«t resources and changes to the schedule. The SPMP would be updated as a result . Some life cycle models, such as the spiral model described below, prescribe speciAc points in Ihe process where planning information is revisited and updated when required . Agile projects, as will be seen , keep planning to a minimum. In addition to the activities described above , a plan is developed for managing project artifact such as technical specifica tions and source code . This is known as to.HfiouCQtlOH ""'""Q(D!",t, and mcludes tasks such as tracking changes to artifacts and handling multiple versions. Configuration man.gement is pl.nned .t th.l early project stage, before the first project artifacts are generated. Configuration management is cove~d .n detail in Chapter 6.

THE ACTIVITIES OF SOFTWARE PROCESS

Requirements Analysis During this phase . detail~d infolmation regarding customer wants and needs. and problems the software is Intended to solve are gathered . Info mlatlo n ga thered and documented is in much greater d~tail than it was in the inception phase. During inceptio n. only e nough information is required to start planning the project. During ~quiremcnts analysis, speciAc product functions and features are denned along with requirements such as performance, reliability. and u ability. Requirements are ge nerated in a form that is completely readable and understa ndable by customers. Hi gh-level requirements in particular are typically expressed in ordinary English (or the loca l language) . Various techOlques arc used to o btain this information, including customer interviews and brainstorming sessIo ns. Requirements describe what the application is intended to accomplish . They are specified in sumcient detail 50 they can be used as input for the subseq uent design phase, which defines how the software will be buill. The resul ts of the analysis arc typically captured in a formal Software Requirements Specification (SRS ), which serves as input to the next phase.

Software Design The purpose of software design is to deAne how the software will be constructed to sa tisfy the requirements. That is. the internal struCture of the so ftware is deAned . The two main levels of software design are software architecture and detailed design . Software architecture is analogous to the overall blueprints of a hou e as a whole. Blueprints specify the number of rooms and their layo ut . door and window locations, number of Aoors, and so on. Software architecture speCifics how the software is broken into subsystems o r modules and the software interfaces between them . For example. the architecture for a video store application may consist of components such as a user interface module, a problem domain module. and a database module . Agile projects general1y perform design . implementation , and much testing in an intcrweaved fashion rather than cal1ing OUt design as a separate phase. The detailed design is analogous to the details contained in a house blueprint. In house plans. details such electrical wiring and plumbing are specified . In software . details such as al gorithms and data structures are speCified. Other aspects of software design include user interface design and database desig n. The output of software de ign is specified in a SofJware Design Document (SOD) and is used as input to the implementation phase. Software design is covered in detail in Part V.

Implementation This phase consists of programming. which is the translation of the software design develo ped in th e previous phase to a programm ing language. It also involves integration . the a sembly of the so ftware parts. The outPUt consists of program code that is ready to be tested for correCtness. For agile techniques. desig n implementation and muc h test 109 arc performed in tandem .

Testing In this phasc . the code produced durin g the implementat io n phase IS testcd fo r correctne s. Testing is performed at three Icvels. First . Individual modules are tes ted by develo pers. econd. modules are integrated and lested to e nsure that they interface properly . Third . once all the modules have been integrated, the e ntire ~ystcm is tested to e nsure that it meets the user req uirements. ystem testing is typical1y co nducted by an indepe nde nt quality assura nce (QA ) tea m. Rcca l1 from hapter 2 that this testIn g proccs, IS called ""I,dalloll . Once system testing has been comple ted, severa llevc1< of uSlOmer tcstin!! are co nducted . During brill Ir li"9 the software is as 10<" to the final rciea,e as possible. and i given to part o f the e ll ta mer community with th e understanding lhat they report any defec ts the y And . The goa l is to uncover a set of problem, that could o nl ' be ruscovcred wllh lhi s type of "rcal -world" tes tlnl!. O nce beta testing is comple te, at' ,plalll( If 11'''9 IS

35

36

CHAPTER 3

SOFTWARE PROCESS

condu Icd o nlhc "fi nal" release of
Maintenance Aher the sohware IS released to u tomers, the ma on le nance phase commences. During maintenance, modiAcations arc made 10 the sohware that "rbe Ihrough one of the fo ll owi ng : • The repair of software ddecls Ihal a rc dIscovered durin g no m,,1 customer use of the system

• ell

lomer request for enhancements

• A desire to imp rove at tributes of the system suc h a pcrformance o r reli abil ity Mod, fica t, o ns to the . oftware arc bundled togethe r, and new versio ns of th e software with these mo di ficati o ns arc re leased . Maintenance is discussed in detail in C hapter 29. Figure 3.3 shows examples of artifacts produced durin g each phase fur our example video store appl ication.

• Inception

" . .. An applica ti o n is needed to kee p track of vi deo rental s . . . " • Planning (Software Project Management Plan ) " . . . The project will take 12 months, require 10 people and cost $2M ... " • Requirements Analysis (Product , Software Req uire me nts Spec .) " ... The clerk shall e nter video title, re ntcr name and date rented . The system shall . .. .. • Design (Software Design Document, Diagrams and text) .. ... classes DVD, Vid,oSlore , . . . , related by . . . " •

Implem ~ntatio n •

(Source and object code )

. class DVD \ String title, . ..

I...

• Testing (Software T est Documentation, test cases a nd test results) " . . . Ran test case: Rrnl "Th, Ma ln'x" 001 OcI J , ro,l "Stoll'seui'" 001 Oct Result : "Stalli"uil" du, Oct " 200. balancc of $8. (comrt) .. "

4I

return -T/', Ma.x tn' ·" 0" O~ 0 . 1..1 f

•

•

• Maintenance (Modir.cd requirements, desig n, code, and text) Defect repair, "ApplicatIon crashes when balance is $10 a nd attempt IS made to

. d" ,n W

,"

Enhancement, "Allow searching by d irecto r."

Fllllre 3.3 The main phases applied to a video store application

rent

"G

0"'

W'tb tbt I

SOFTWARE PROCESS MOOELS

3.2 SOFTWARE PROCESS MODElS ftwan:: proces model deAne the order and freque ncy of phases in a project. The following sections describe the most important process models, starting with the classical waterfall process .

3.2.1 The Waterfall Process Model One of the oldest oftware process models was deAned by Royce [ I] and is called the wa t,rjall proms. Despite its many weaknesse (described later in the section), the waterfall process is still in Widespread use today and is the basis for many other more effective processes. FIgure 1.6 in Chapter I illu trates the phases of the waterfall process . Note that Royce's mode l begi ns with the requirements phase he did not include inception and planning phases. In practice, o rganizations implementing a wa terfall process wou ld typicall y start with these phases. The waterfall executes in a ~cwentiaJ manner through each phase, conclud ing with maintenance. output from o ne phase is used as input for the next, implying that a phase is not tarted until the previous o ne has completed . It is accepted in waterfall processes that there is a small overlap between adjacent phases. As an example , some personnel wi ll be performing the last part of requirements analysis while others will have already started the design phase . The waterfall process is c haracterized by documents generated by the time each phase is completed. These include requirements specification and design specification, for example . Also, there are usual ly entrance and exit criteria between phases to e nsure that a phase is completed successfull y before moving on . In practice, an iterative re lationship between successive phases is usually inevitable. For example , after the requirements are comple ted, unforeseen design d ifficult ies may arise. Some of these issues may resu lt in the modiAcation or removal of co nflicti ng o r no n. implementable req uirements. Thi s may happen everal times, resulting in looping between requirements and desig n. Another example of feedback is between maintenance and testing. Defects a re discovered by custo mers after the software is released. Based on the nature of the problems, it may be determined there is inadequate test coverage in a particular area of the software. Additiona l tests may be added to ca tc h these types of defects in future sohwa re releases. A genera l guIdeline, often accepted to sti ll bewithin the wa.terfa ll framework , is that feedback loops should be restricted to adjacent phases . This min imize potent ially expe nsive rework if the feedback were to spa n multiple phases. An modified model ill ustrati ng this iterative relationship i sh ow n in Figure 3.4 .

n,e

time

•

ReQuiremenls Design Implementallon Phases (aerlvilles)

Tesllng

Malnlenance Figure 3..4 The waterfaU software development process In pracllce: fcedMck Is IneVitable

37

38

CHAPTER 3

SOFlWARE PROCESS

A n,.lor limitati o n of the waterfa ll pro.:e>, i~ th at the tC\ling phase DC ur~ at the end of the development c de th e f,rs t time the ,y,te m is tes ted a a w ho le. Maj or Issue<
Advantages

• S".plt 'llid tasy

fo

uSt: Phases arc executed and compl e ted senall y, with speCIfic e ntrance a nd exit criteria for

movinS between phases. O rde rly execu ti on of phases is easy to comprehe nd .

• Pracfiad for many yta~ and ptOplr I,aat milch txptritna ",iii,

i~

The process is well understood , a nd many people

are com fortab le with its execution .

• Easy

fo

manag' du,

fo

fb , rigidi fy of fh, mod,l: Each phase has speciAc deliverables and a review process.

• Facililales al/ocahon of rrsourcrs (due to sequential nature of phases): Distinct phases fac il itate allocation of perso nnel With distinct skills.

• Works "" II for smallcr proj,cls ",hm rrqui,rmcnls arr D'ry w,lI

undt~ food :

It isn't necessa ry to add complexity of

iteration if requirement arc well known up fTo nt.

Disadvantages

• R,qui"mcnls mu,1 bt h,o",n up fron l: It's di ffic ult to imagi ne every detail in advance. Most projects start out with some uncertai nty, a nd mo re de tails are learned as the prOject prog resses.

• Hard 10 rs limalt reliably , T o ga in conAde nce in an estimate, there may be the need to design and implement parts, especia lly riskier o nes. Estimates become mo re preCise as the project progresses.

• No f"dback of ,y,fem by ' Iakrholdm unlil afltr l" ling phaSt: The process does not facilitate intermediate versions. Stakeholders often need reassurance of progress and confirmation that what is being develo ped meets requirements.

• Major problem, ",ill, system artn·1 discolXfld unlil lal, in proms : The testi ng phase is where these problems are found , but it leaves very little time for correctio n, resulting in potentially d isastrous effects on projec t schedule and cost.

• LAck of par.Ilt/lSm : Each phase is executed to completion . Disjointed parts of the system could otherwise be completed in parallel.

• inrfficitnl USt of mourers : T eam members can be idle while waiting for o thers to complete their dependent tasks or for phases programming.

to

complete. Also, someone good at requireme nts analy is is not neee sarily good at

Ikcause of fac tors like these, alternative (but related) proce ses are often emplo ed , and these are covered in subsequent sections.

SOFTWARE PROCESS MODELS

3.2.2 Iterative and Incremental Development The wa",rfall process is c harac terized by a seque ntial executio n through the phases. It is generally agreed that the order of the phases d ictated by the waterfall i fundamental : ga the r requirements. c reate a sohware desig n to realize the requireme nts. imple me nt the design, and test the implementation. The problem arises. however. when this is caled up to gather all the requirement . d o all of the design. implement all of the code. and test all of the system in a linear fashion [2]. Except for rhl' emallce' o( projects this is imP'1'ctical. As the system is developed and renned , more i lea rned and a need arises to revisit each of the phases. That is, software is mo re naturally developed in a cyclica l manner. where a part o f the system is deve lo ped and tested. feedback is ga thered . and based o n the feedback more of the system is developed. This reAects the fact that not everything is unders tood at the start of a proj~ct. Ilrraliv( processes accept thi s cyclica l nature and are discussed in the rest of th is section . Figure 3. 1 is drawn in a way that reflects this. ~n ilcraliv< process is typined by reDba ted executi o n of tbe walerfall pbases. in whole o r in part. resulting in a ren nement of th e req uire me nts, design. and implementation . An iterative process is incrm", lol if each iteration is relativel y small. At the conclusion of SlI c h an iteration . a piece of operat io nal code is p roduced that suppo rts a subset of the nna l produc t functionality and (eatures. Project artifacts suc h as plans, speci flcatio ns. and code evolve during eac h phase and ove r the life of the project. Artifacts are co nsi de red comple te only when the software is released . As defined by Cockburn (3). incremental development is "a sch eduling a nd staging strategy that allows pieces of the system to be devel o ped at different times o r rates and integrated as they are completed: This implies that iterations need no t be executed serially, but can be develo ped in parallel by separa te teams of people . Successive increments implement an inc reasi ng set o f functionality and features until the nnal iteration . which produces the nnal product. Figure 3.5 illu.s trates this concept for a project with three iterations. Note that the output of each testing phase is a working subset of the nnal p roduc t that incrementally contains more functionality . An iteration other than an incremental one is sometimes defined as "a self-contai ned m ini -project. with a well-denned outcome: a stable. integrated and tested release" [2]. That is, each itera ti on is a self-contained

•• •• • • • • • •

1

,,,

First iteration completed X •

-

Requlrements analysls

••• 1

•• • •

_.•• • ,•

,

• •

td•

Design

,

Cod Ing

T...tlng

•

• •• •• •, • ,•

•

•

•

-• • ••

•

2 • .,_.• • ,• • •

•

, 2

.,•

•

,

,• •

•• • ••

• •

-•

• • • • • •,

•

m ,

,

• • •

CD: •

• •

• • •

SCHEDULE

•

1

Iteralion' ~ .

• ••

•

MIL EST 0 N E S:

•

• ••

•

• • •

1

•• •

•

•

._.,• • • • •• •• • ,• • • •

CD: _.• •

• •

•• •

•

I 2

SottwarL-l

SottwarL-l

Sub"t

Subset

lime

••• I •

Product released X ,• , • ••

• • •

• ••

•

•

a ,• • • • • • •

•,

• •

0 : • • • •• •

•• • • •• •

~

-

• •

-

• ,• • •• • • ,• ••

f-

,

f-

•

co: , , • •

• • •

--

•

['

I

Final --1 Version

Flgure 3.5 The IteratiVe software development process: an example with three Itera tions Sourc:t COCt:btxn, AI'R eit " UN&..e!I"K loocmofH.8I OoYelopment,'· JDnuatY 1993. hup'/lahstnl1 COCkburn USlUnravoUnx r!ncremontal ~ dCve.lQpn'lent.

39

.0

CHAPTER 3 SOFTWARE PROCESS

pro) t with It- ow n set of actlvitlc>, plan , o bjective , and tnea~urablc eva luation Crlterl. , The ' re lea<e" is a workln~ vCrlilo n of cd internall y by the project team or externa lly by stakeholders and cu,t merli. Type of rel eases an be [2J • A proof of Oil 'p I, or f,lISibi lily ' IIIdy, that Is used to demonstra te or invest igate feasibi lity of a particular aspect of the software . Thi includes producing software or simulations These are covered in Section 3.2.32 • A prolotyp, that is a workmg verliion of software demo n trating a parti cular capabi lity that is deemed high risk . Prototypes are covered in Section 3 2 3, t , • An "internal" release that is o nl y used by the devel o pment tea m and is used to ensure tha t develo pment is on track, elicit feedback, and provide a basis fo r further devcio pment and addi tiona l capabili ties. • An "external" release that IS shipped to customCrli fo r evaluation . Trea ting each iterati o n as a self·contained project allows clear and manageable objectives to be set, and reduces overall projec t complexity by breaking it down into small er pieces. By produci ng working software at the end of each Iteratio n, project progress can mo re easily be mOnito red and planned, and feedback can be ci ici ted to ensure that its capabi lities arc meeting stakeho lder requireme nts. Typically, early iterations ge nerate softwa re releases that address aspects of the project with the highest risk . In this way, as the project progresse the overall proJec t risk level is reduced. An example o f an iterative and incremental process that is used within parts of Microso ft is reported by Cusumano and Selby [4]. to wh ic h the y give the name "synch·and·stabilize: Product features are defined at a high level during the initial phase of a project, with the idea that many Will evolve as product development proceeds. The product is divided into parts, each co nsisting of a set of features , with small teams aSSigned to each part. The project is also diVided into parts, o r iteratio ns. each with its own completion milestone. Each iteration includes several features . Feature teams employ incremental synchronizati o n by combining their work and stabili zi ng the resulting system o n a daily or weekly basis In this way the evolving software application is continually kept in a "working" state .

3.2.3 Prototyping, Feasibility Studies, and Proofs of concept Prototypes and feasibility studies are impo rtant techniques in software development, and are explicitly included as formal steps, o r phases, in several process models. We discuss them now in more detail.

3.2.3.1 Prototyping On begi nning a software projec t, we are usuall y faced with factorli that we do no t yet fully underlitand . The look and feel o f gra phical user interfaces (CU ls) that will sati fy the custo mer is o ne common example. T iming is ano ther. For example, suppose that we plan to build a Java application to control an airplane. A critical issue to pm down very early would be; Will the Java Virtu.1 Machine be fast e noughl Each unknown factor o r risk is best confronted as oon as possible so that its severity can be assessed and a plan developed to deal with it. Risk management is dealt with in detail in C hapter 8. ProlotyPi"9 is an important risk management tec hnique. It is a partial implementation o f the target appl ication useful in identi fyi ng and retiring ri ky p.lrtS of a project. Prototyping can also be a way to obtain ideas abollt the customer's requirements. An inc,. a,e in o nc's underlitanding of what is to come can save expensive rework and remove future roadblocks before they occur. Agile processes contain some of the beneAts of proto typi ng because they deal at all times with worlt,ng code, However, they do not have all of the beneAts, since prototypes proceed in parallel with the main threod of the project, whether agile o r not.

SOFlWARE PROCESS MODELS •• , •••••

••••••••••••••••••

.. Prototype Implements

Prototype

Project beginning

,:~-

risky parts of this activity lirsl

·0_ •°

~,

Main project timeline

Key:G= end of a unit 01 time

0

....

•

•• •• •

time = Activity wilh risk

Figure 3.6 An illustration of prototyping in the context of a development project

As Figure 3.6 hows , work on a prototype typically progresses in parallel with regular work o n the project. The risks are prioritized and the prototype is geared towa rd as many of the mosi imporrant ones as time allows. In the example shown in Figure 3.6, the prototype ignores the large risk near Ihe beginning of the project because it will be dealt with early in the ordinary course of the project in any c ase. Large programs, such as billion dollar defense projects, utilize extenSive prototyping to retire risks and to guide the requirements and design of the real thing . For example , before the U.s. Navy built the Aegis generation of shipboard systems, it built an entire scaled -back version , complete with software and hardware , installed o n a s hip for the purpose. Thi s prototype served to indicate to the Navy what the main problems might be with the eventual systems . It also helped the Navy to deve lop the requireme nts and design of the eventual system. Simple gra phics showing curs usi ng paint · type too ls may be s uf~cient if the prototype's goa l i to envision the interfaces. The more extensive the prototype, the mo re risks can be retired with it and the more easily a customer's requirements can be understood . O n the o ther hand, protorypes are themselves software applications , so extensive prototypes arc expensive . A rou gh assessment as to whether or nOt to build a prototype is shown in Figure 3.7. Th e table in the figure illustrates, for example , that a re latively inexpensive prototype with high va lue s hould probably be built. "High value" means that building the protorype helps th e

Calculate payoff In detail

no

Calculate payoff In detail

Figure 3.7 A rough calculation of whether developing a prototype would be wo rth It

.1

CHAPTER 3 SOFTWARE PROCESS

t Payoff from building prototype ($'s saved per $1 spent)

optlllUll expenditure on prototype

full

project expenditure

0/0 expenditure on prototype

0%

1000/0

GUI

only Figure 3.8 Concept of when It is worthwhile to build a prototype (near the beginning)

cu tomer understand better what kind of product is likely to emerge , helps the e ngi neers understand better what kind of product shou ld emerge, andlo r retires a development risk . Many cases fa ll into the "maybe" ca tegory of the table in Figure 3.7, and more detailed analysis is required to assess the value of protorypi ng. \'l/e are seekin g an optimal level of effort to be spent on a prototype, as sugge ted by Figure 3 8. As the expe nditure o n a protorype increases, its usefu lness increases, but so docs Its drain on the project's budget As a resuil , there is a point at which the payoff is optimal (the maxImum point for the curve ), and some point beyond which funds are ac tually being squandered (w here the curve drops be low the horizo ntal axis). As an exa mple, consider an e -commerce application in which a clothing company wants to sell goods on line, retain customer pronles, and allow customers to obtai n pictures of themselves wearing clothing from the ca tolog . A typical calculati o n about prototypes factors the cos t of protoryping features and the potenti.1 for using prototype code in th e nnal product . Figure 3.9 gives nnancial estIma tes fo r prototyping four parts of the clothing ve ndo r application ,

I . CUI screenshots 2. T ransaclioll security 3. Complete transaction 4 . Customer tri es o n clothing

For each of the fo ur app licat io n features consi de red fo r the prototype, severa l estimates can made, the cost of building the feature , the percentage of the feature's implementation that will be reused in the applicatIOn itself (i.e., not di scarded ), and the "gross benefit" from the effort. The gro benefit here estimates the gain from prototypin g the feature , excludin g reuse of th e code and excluding all e · ~nses . For example, as show n in Figure 3.9, we have estimated that if the "Customer trie on clothing" feature were to be prototypcd, it would save a minimum $20,000 in development co fS Thi estimate I based on factors suc h as the fo llow ing,

SOFTWARE PROCESS MODELS

Cross IkneRI

ProlOlyP<'

<xcluding code reu..,

Estimated cost

min

max

B

D

E

fe.1Ure J. CUI

$10,000

$10,000

$ 80,000

Perccn~g.

of prolOtyP<'

Net P.yoH

code reuscod In

appliation

C 50%

• mm

D-( . -C)B $5 ,000 ,

soecnshots 2 . T ransaclion secu rity 3. Complete

$50,000 $SO,OOO

transac,t ion

4 . C us to mer tries on

$120,000

$10,000 $10,000

$300,000 $400,000

80% 50%

-

$20,000

$140.000

30%

mOl(

$0

-- $30,000 -$64,000

.~

E- r .-C)B

1

$40,000

$75 ,000

-

$290,000

-

$56,000

clothing

..,

$145 ,000 •

$200,000

I

$85 ,000

I I

- $4 ,000

J

Figure 3.9 Payoff calculation example for building a prototype for a clothing application

LI , 'J"" v • Preventing lime wasted o n proposed requirements that the prototype shows are not reall y needed (e.g ., mi nimum of th ree un needed requirements out of 100, $300,000 budgeted for the requirements phase = $9000 saved) • Im p le me n ti ng a sohware desig n for the "trying o n clot hes" feature, thereby retiring some development risks (e.g ., esti mate that t h is wi ll save a minimum of one pe~on - week of design time = $2000) • Rewo rk th at would have resulted fTOm the customer cha nging requirements only after seeing the developed product (e .g ., rework minimum of three requirements at $3000 each = $9000) The minimum savings therefore is $9000 + $2000 + $9000 = $20 , 000. Estimating the cost of building the prototype ca n usc approximation techniques like those described in Chapter 8. An estimation of code reuse can be performed by identifying the classes of the prototype and determining which are likely to be usable in th e actua l app lication. This type of estimation often consists of adding up the estimation of sma ller parrs, which is often more feasib le . Bracketing each estimate between a minimum and a max-imum can help to make this process a little easier for the estimator. Once these estimates are made, the best· and worst ·case scenarios for each feature can be computed. This is shown in Figure 3.9. The minimum payoff value is obtained by taking the most pessimistic combination : the highest costs, the lowest g ross benefits , and the lowe t reuse percentages. The maximum payoff is calculated correspondingly. For example, the maxImum payoff (the most optimistic alternative) for the ' CUI screenshot" prototype feature is as fo ll ows: [ma xi mum estimated benefit ] - [ minimum estimated com 1 = $80 , 000 - [(minimum estimated cost) x (percent not reusable )]

= $80 , 000 - [ $10 , 000 x 50% ] = $75,000

U

CHAPTER 3

SOFTWARE PROCESS

v rJ~illB is o ne way to deal with the >pread bel ween bcsl and worst ca'c, The result ~ugke
3.2.3.2 Feasibility Studies It IS o metim~ unccrtain whether proposed requirement can actually be implemented in practice. In other words, an entire project is at risk rather Ihan a few spcciRc requ irements. In addition, the project would not be feasible If Ihe ri k were to be realized . In such cases, Jtasibll/l)' sludirs may be advisable. These are partial implementations or simulations of the app:ication. For example, conSIder the fea sibility of a Java Internetbased Encounter video game, and Ids say we suspect performance will be so slow that the game would be of negligible Interesl 10 an yo ne . A feasibility study could consist of setting up a message · passi ng simulation at the anticipated rale from a number of players, but with dummy content. Delays could then be estimated by clocking the simulation . Simulations can be expensive to create since they arc applications in themselve , sometimes requiring software engineering artifacts of their own such as a requirements speCification! The author was once involved with a si mulation of a large system und~r development. The simulati on grew into a large program , which was needed while engineers developed the rea l system. No one took the requirements for the simulation seriously because it was not "the real thing ." As a result, even though the development community relied on the simu lation , the cost of maintaining and using it became astronomical. Making cha nges required tracking down an employee who "knew the system." Feasibility simulations arc common in large defense programs that invo lve extensive software and hardware.

3.2.4 Spiral Model One of the earliest and best known iterative proces es is Barry Boehm's Spiral Model [5). It is called a spiral because Boehm concept1Jalized development iterating as an outward spIral, as shown in Figure 3. 10. Boehm's spiral model is a risk· driven process in which iterations have the specified goals shown in Figure 3. 10. (Recall that risks are potential events or situations that can adversely affect the success of a projcct.) A project starts at the cenler, as it were , and each cycle of the spiral represents one iteration. The goal of each cycle is to increase the degree of system definition and implementation , while decreaSing the deglee of risk. Risk management is built into the process in that very early in each iteration , project risks are identified and analyzed and a plan for the iteration is created that includes mitigati ng some or all of the risks. As an example, suppose that at the beginning of a cycle a risk is identified with the screen layout of a portion of the user interface. Software could be developed to implement pan of the user interface so feedback can be eliCIted from takeholders. Doing this mitigates risk early in a project and leaves ample time to implement necessary changes. Thu the ov...11 project risk reduces the funher along you arc in the process. After the major risks arc addressed and mitigated, the project transitions to a waterfall model , as shown in the outer spiral of Figure 3. 10 Each iteration in Boehm's spiral model consists of the follOWing steps, 1. IdentificatIOn of critical objectives and constraints of the product. 2. Evaluation of project and process alternatIves for achievlll8 the objectives.

SOFTWARE PROCESS MODELS

COST

Dele,uutE

ntROUCH

EVALUATE AL i EJdU.l1VEI

8108

oe,Ec11V£l. A1.. ftRNATIV£S, CONsntAJNTI

1DE>m'Y, RE SOLVE R.tSKS

RISK ANALYSIS

,

RISK NtAl. Y&lS

RISK ANAL YSIS

",

OP EllA naHAl: PROTOTYPE

.,

COMM'iiriEHT PAR Ii flOtt

RJSK

'.,

-'

ROTOiTP £,

AHAI,., PROTOTY PE., ~ ~R:OTO· TYPE 1

,,

"EVIEW ROTS PlAH Uf'E CYCLE PLAN

- -- -

_ COHCEPTOF OPERA nON

EKlLATlOHS

SOflWARE

"an: DEVELOP· MEHT PLAN

INTECRATION

"HOttST PLAN NEXT

PLAN

MOOELS

-- - --

BEHCHMAR KS

OETA.D.. ED DESlCN

SOFlWARE PRODUCT OESI CH

ReQUIREMENTS VALIDATION

... ... ...

"

CODE '" UNIT "-

OESK;H VALIDAnON AND VER'FICAl1OH

PHAS£S ,

\ ACCEPT. ' IMPLEMEH. \ ANtE TEST

TAllON

" INTECRA·' nONAHO

TEST

,

lEST

D£VELOP. VER IFY NEXT LEVEL PRODUCT

Figure 3.10 Boehm's spiral model for software development Source: Boehm, B. w.o"A Splral MOClel of SOftware Development and Enhancement." IEEE COrnputtf. Vol, 21 , NO

5. May 1988, pp

61-n

3. Ide ntification of risks . 4. Cost·effec tive resolutio n of a sub et of ri sks uSi ng analysis, emulation , benchma rks, models, and prototypes.

5. Developmen t of projec t deliverables including requ ireme nts, deS ig n. impl ementa tion , a nd testi ng. 6. Pla nni ng for next an d fu ture cycles-the overa ll project plan is updated , including sc hedul e, cost, and numbe r of remaini ng iterations. 7. Stakeholder review of iteration de hve rables and their commitme nt' to proceed based o n thei r objective

being mel. Each traversa l o f the spira l resu lts in in remental deliverable<. Ea rl y Itera tio ns produce eithe r model , emulatio ns, be nc hmarks, or pro totypes, a nd later Itera tio ns fo llo w a more waterfa ll· like process and increme ntall y pro du " more complete versio ns of the softwa re Th is implies that ea rl y Iterations may exclude srcp 5, and late r ite rat io ns may exclude
4S

CHAPTER 3 SOF1WARE PROCESS

Ith ug h Boehm" ori!! inal conception wa, risk. drtven , the piral Model ca n also be driven by a ,eque n c f fun tlonallty sets For example, Iteratlnn I for an o nline video .on · demand appileatlon could be to Implement the database of video, and it API , Itera tion 2 could be to implement the CU ls, and so on Key advantases and disadvantages of the spiral model are li sted next. Advantages of the spiral model

• Risks IIrr ,nm'"g,d ,arly m,d ,hrougholl"'" proem : Ri k, are reduced before they beco me problematic, as they are considered at all stages. A a re
oj'u'lIrr ro%rs as ,h, proj,e' progrrsscs It is a reali sti c approach to the devciopment of large·scale sof·tware. Errors and unattractive alternatives arc eliminated early .

• PIn,,.irr9 is

b,,,"

111'0

iI" procrss : Each cycle in ludes a planning tep to help mon itor and keep a project on track

Disadvantages of the spiral model

• Compli a"d

'0 u,,: Risk analysi

requires highly speCific experti e. There is inevitably some overlap between

iterations.

• Mtry b, oo"kill jor ,mall projrclS: The complication may not be necessary for smaller projects. It does AOt make sense if the cost of risk analysis is a major part of the overa ll project cost. Boehm's spira l model has been very influential in giving ri e to many styles of iterative development model , including, we believe, the unified process, discussed next.

3.2.5 Unified Process and the Rational Unified Process The Unified Software Development Process (U SDP) was first described by Jacobson , Boach, and Rumbaug h in 1999 [6 J and is an outgrowth of earlier methodologies developed by these three authors-namely, Jacob on's "Objectory methodology ," the "Booch methodology" [7]. and Rumbaugh et al : s Object Modeling Technrque [8]. The USDP is generically referred to as the U.ifird Proem (UP). IB M's Rational Software division has developed a detailed refinement to the UP called the Ratio•• l Ulliflrd Proms (RUP ), which is a commercial product providing a set of process guidelines and tools to help automate the process. The UP is a "use·case driven, architecture·centric, iterative and incremental" software process [6J. Iterations are grouped into fou r "phases," shown on the horizontal axis of Figure 3. 1 I , lllcrpllcm, Elaboralimr. COlls'ruelioll, and Tra.silloll . The UP's lise of the term "phase" is different from the common usc of the term. In fact , referring to the figure , the term "discipline" is the same as the common use of · phasc" that we use in thiS book. Each UP "phase" consists of one or more iteration , shown across the bottom of Figure 3. 11. Iterations are relatively short (e.g., threc weeks), the outcome of which is a tested , integrated, and executable partial ystem . Iteration are built on the work of previous itera~ions, and thus the Anal product is constructed incrementally . Each iteration cycles through a set of nine diSciplines, whi hare hown on the vertic.1 axis of Figure 3. 11 : business modeling , requirements, design , implementation and test activities, plus supporting activities slIch as configuration management , project manag menl , and environment [9J . Fur examp le , during an iteration some requirements may be cho. en , the desilln enhanced to support those requirements, and the requirement. implemented and te ted . The hOri zon tal "hump ' next to each discipline show the relative effort expended on each diScipline during iterations. For example, the

•

SOFTWARE PROCESS MODELS

Phases Oil..: lpllne.

II T.-n. I

II

•, ,, ,

Business Modeling

Requirements Analysis & Design

Implemenlation Tesl Deploymenl

Configuration & Change Mgml Project Management Environment

,, , :,

,, ,,

rr~=::~~:::-;:== ::;:;;;;;::;:;:;~

I tr_ I

EIob"

Ebb' 2

..----

c:r I T~ I I

~ Ic.:;' I

T;r

Iterations Figure 3.11 The unified softwa re development process: its " phases" vs. traditIOnal phases SOUrce' Adapted from Ambler. S. w.. "A Manager's Intfoductlon to the Rational undlea Process (RUP)." AmbySoft (OeCember 4, 2OOS) , http://Www ambysoh..COOV do't'mlOaclSlmanagerslntTOToRUP.pdr.

largest requ ire me nts effort is expend ed du ri ng Inception a nd Elaborati o n, and the large ' t Implementation effort during Constructio n. Th e fo ll owing arc desc riptio ns oi the work conducted during each of the UP "phase ", Inception • Establish feasibility • Make busi ness case • Establish product visio n and scope • Esti mate cost and schedule, includi ng major milestones • Assess critical risks • Build o ne o r more p ro totypes Elabora tion • Specdy requirements in greater detail • Create architectural baseline • Perfonm iterative implementation of core architecture • Refine rISk as essment and resolve hIghest ri k Items • DeAne metrics • ReAne project plan , Including detailed plan for brg lnlllng

onstn.1 t lo n lIerallo n<

47

48

CHAP 1ER 3 SOFlWARE PROCESS

•

oml letc remaining reqUirement

• Do Ilera tl vc IInplcmcntJfion of rema ining dC'ign • 1110roughl), te't Jnd prepare system (or deployment T r.nsition • Conduct beta te'ts •

orrect defects

• Create use r m"nuais

• Deliver the system for production • Train end users, cu tomers and support' • Conduct lesson learned Ea h UP phase concludes with a well -defined milestone , where key deciSions are made and specific goals defined Figure 3. 12 shows these milestones and where they are fulfilled in the process . The typical amount of time spe nt in each UP phase is shown in Figure 3. 13 ( IOj. However, this varies depending on the type o( project. For example, projects that contain o nl y mino r enhancements with known requirement may spend morc time in the Construction phase, while projects for which very little is known about requirements may spend more time in the Inceptio n and Elaboration UP phases . The advantages and disadvantages of the unified rocess are summarized below. Advantages of the unified process • Mosl asptcls of a prOllel art accolm lrd Jar: The UP is very inc1usivI=, covering most work related to a software developme nt project such as establishing a business case.

• Tht UP

IS malur< ,

The process has existed for several years and has bee n quite Widely used .

............

-

1

I

Utecycle ObJective.

lItecycle

(LCO) • Scope concurrence • Initial requirements definition

Archlteclure (LCA) • Requirements stability • A,rchltecture stability • Risk acceptance • Cost acceptance • AeaHslk chance to

• Plan concurrence • Risk acceptance • Process acceptance • Business case • Project plan

..J

CGnIIru-..Ibl

,.,...."

In ltle' Operational C.""b lllty (IOC ) • Syslem Slability • Requirements stability • Prepared stakeholders • Risk acceptance • Cost acceptance • ProJect plan

Product RelNn (PR) • Business acceptance

• Opera lions acceptance • Suppon acceptance • Cost and estlmare acceptance

succeed • Project plan

Figure 3. 12 Objectives for the unified process S<;IurU. ,.Mpte(l fromAJ'nblef. S W . "A Managor"s Introduction 10 the RDtJoMl unjf'ie
dOYmk'leOslmenagerSJntroToRUP octf

SOFlWARE PROCESS MODELS UP Phaa•• - Typical Time DI •• rlbution

Transition 10%

Inception 10%

Elaboration 25%

Construclton 55%

Figure 3.13

lYPical time distribution of the rational unified process's "phases"

SOurce: Adapted from Ambler. S. W . "A Manager'Slntrodoctlon [0 the Ra !MJoaI unified Process CRUPI "~ Ambysoft (DeceOlDef 4, 2005}" nttPJtwww.amoysoft.conv dovJnkwk!managet"SfFltrOToRUP pdf,

Disadvantages of the unified process • Tht UP was originally conctivtd oj Jor /nrgr projtclS, This is fine . except that many modem approaches perform work in small self-contained phases. • Th, procm may bt ovtrkill Jor smnll Proltc/s , The level of compl ication may not be necessary for smailer project . Practitioners and vendors of the unified process have modified It to be morc like an agi le proccs , discussed next.

3.2.6 Agile Processes This sectio n Introduces agile processcs. C hapter 4 is dcvotcd entirel y to agi le methods, and agi lity is referenced and compared throu ghout this book In 2001 . a group of industry cxpcrt~ , disillusioned with some ommo nly held software engi neeri ng beltefs and practices. met to discus way to Improve softwa re development. Thei r goa l was to produce a et of values and princ ipl es to help spced up development and effectively re~ po nd to change . The group ca lled themselves the Agile Alliance, in cssence to capture th elf goa l or produ Ing a mcthodology that wa< efficient and adaptable . The resu lt of their work was the MmllJrsloJor Agi/t SoJlu)(I(( D".,lopmtlll [ 1 11. . 1 0 knO\~n as the Ag,k ManiJ,slo , which co ntains the va lues and pron iples they defi ned. All agil, software pro c< is o nc that embrace~ and co n/o rm s to the Agile Manifesto. whi ch i, umm arized In Figure . 14 . Ag"e processes are hrghly Itera tive and incremental They comm only cmpl oy the foll owing: • Sma ll , close -knit tea mS • Rt:gular, frequent , dr ~c ,pli ned

ustomer reqUlremenh

• I11t c lln g~

• A code-centric approach, docu mentation nn an a' · needed bnSl< (e,g . h, gh·level reqlllrcment' statement< only)

49

50

CHAPTER 3 SOFlWARE PROCESS

• .. . indi vidual s and interactio ns o ve r pro e,sC' •

Jnd t o l ~

. . . wo rkin g software

over o mprchenslvc docum ental ion

• .. , customer collaboration ove r ontra cl nego tiati on

• . . . respo nding to change over fo ll o wIn g a plan Figure 3.14 Main points of the Agile Manifesto

• C u tom er repre entativcs wo rk ing w ithin th e team

• The use of use r sto ries as the ba sis fo r requirements indivi dua l tasks

end -to-end accounts of ho w uscrs need

:0

acco mpl ish

• Rerncto ring, a kind o f d isciplined code Improvement explalOed full "" C hapter 24 • Pair programm ing, In whi ch tw o programmers work at a single wo rkstati o n • Con ti nual un it· ccs ting, and acceptance tests as means o f setting customer ex pectations

Figure 3. 15 shows how the repeated iterati o ns o f an agile process arc executed over time. "Sto ry" is a task required of th e application as th e eu tomer co nceives it.

Demonstrate fulfillment of previous stories ,, ,, ,, ,, ,, ,, ,,

Accumulating functionality Identity stories for th is iteration • Interact with customer , • Cement mutual undersranding ,, ,, Implement stori es ,, ,, ,, • Work incrementally , ,, , , • Develop test bank In parallel ,, ,, ,, Typical ,, " ," Iteratio'l, _- --

---

----

nme; composed of equal iterallon Intervals ~

Figure 3.15 The agUe process

J

SOFTWARE PROCESS MODELS

Ke ad>
$

and di advantage o( ag.le proce es arc ummaflzcd below.

Advantages of an agile process

• n.. praitel alw"Y' ha, d,,"o"'lrabl, ","/r"

The end product o( each iteration is working software .

• DnJtlo/ltrS tn.d 10 b, mort •• o/illnl,d, Developers prefer to produce working art.lacts and tend not to like creating documentation .

• C.'lamm

a" abl, 10 /lrollld, b,u" ",/""""",1, b, a"St

Ihry cnll

s" II"

,"ol"i"g proJllc/,

Disadvantages of an agile process

• Probl""aric.1 for lnrg, appli alia" , Agile methods are more readil y used for smaller projects. There is debale about their utility for large projects.

• Docum",lallon outpul is qutSliOHabl" Since documentation takes second place, there i a question a. to whether necessary documentat.on will ever be produced.

3.2.7 Open-source Processes Open·source software is developed and maintained by people on a volunteer basis. All project artifacts, from requirements documents through sourCe code, are available 10 anyone . The re are several open -source software development Web sites on the Internel Ihat aggregale and reference open source projects, including SourceForge.net and Freshmeat.ne!. As of 2009, SourceForge.nel hosted more than 100,000 projects and had over 1,000,000 registered users. Hosting sites provide source code reposi tories and utilities for projecl management, issues discussion , and source control. The case studies in this book dlustratc two well known open source projects, Eclipse and Open Office . Open-source projects typically get started when someone develops an applicat.on and posts it to a host Web site V.rtually anyone ca n propose new requirements, and since the source code is freely ava.lable, anyone can implement requirements that arc not part of the o(ficial baseline. There is a process by which proposals and implementations arc elevated in priority and a process for accepting new code and capabdity into the basehne. If defects arc (ound, they are reponed and others may work on fix ing them . This process is repeated, and the application grows .n capabdity and $tability . In this wa y, open -source projects arc developed in an .terative manner. In addition, by exercising aA appltc.tion many times, the open - o urce communtty affects a huge testi ng process. Some reasons why an individual o r company makes a project open source arc listed .n F.gure 3. 16 and 3.17, a,n d reasons why they may nOI arc listed in Figure 3. 18. A pnmary reaso n to make a proj" t ope n ,ource is to leverage a large number of resources that might not otherwi<e be avadable A principal reason to no t make ,o(tware open source., to keep artifacts h.dden from current and prospc live competitors. o me (e .g., Ferguson [ 12] and Kapor) believe that o pen oftw.re Us.ng common me ln s, O code Qualtty was lound roug hl y equal to Ihat 01 _ , nnd 101lnd to be supe-rior for mainta.nabd.ty . or at wo"t equa l n me o ( Ih el r result, nre Ih wn In F.gurn 3 19 and 3 lO .

51

52

CHAPTER 3 SOFTWARE PROCESS

open-source users find rewards in collaborative development 11 Alnn Joe" 1/ 1/100S hur i/www adtmas , o m/article .a
•

Banking on open source Dresdner Klci nwo rt W asse rstc," (DrK W ) believes it found development success wirh OpenAdapter by creat.n g a va nation o n the co llaborative mo del the open·source community pioneered . . . . . "We open sourced the 1001 within DrKW and told people that if they needed to change OpenAdapter sligh tly, they were free to do that," Howe says, "A lot of developers decided they co uld make a name for themselves by cont ri buting to the software ." Today, more than 100 applications in the bank use the mtegra tion tool.

T o tap simdar expertise outside DrKW, the bank tumed 10 ColiabNet, a commercial project· develo pme nt plalfo rm from ColiabNet in Brisbane, California. ColiabNet provides a number of services, inclYd ing version control tools and discussion fon.ms common in free open ·source clearing. houses such as SourceFo rge . .. . ColiabNet helped the bank establish a separate legal entity called Ihe So ftware Conservanc y, which owns Ihe inlt,lIeetual rights to OpenAdapter. The site publi shes the latest stable build of the sofrware, which anyone can download. Users can also send in complaints and error reports and suggest bug Axes. So far, DrKW has received input from devel opers at competing banks and from companies outside the financial industry. Collaboration co nsists of lechnical subjects, nol information that involves trade secrets or conRdenlial customer data. Devciopers .nterested in becoming more involved in OpenAdapler's evolution can gain access to the source code by signing a legal agreemenl that assigns the intellectual property rights of Iheir code to the Software Conservancy. About 20 developers now hold such status.

ompanies mI x and match opcn·source and proprietary processes according to buslncs

nttds F.gu re 3.2 1 suggests Ihal the pro porti on of o pen·source o r pro pnelary sofrware used. a bll IIle deci ion ta ke n .n Ihe eonlex l of ex penses and revenues over t.me. An important factor is the expense of tn. lo ring and •

••

malnta lnill g open SOurce

SOFTWARE PROCESS MODELS

@

Leveraging large number of resources

© Professional atisfaction © To enable ta,loring and integratio n © Academic and research

© To gain extensive testing © To maintain more stably Figure 3.16 Some reasons for making a project open source. 1 of 2

© To damage the prospects of a competitor's product © To gain market knowledge © To support a core business © To support services Figure 3.17 Some reasons for making a project open source, 2 of 2

® Documentation inconsistent or poor ® No guarantee that developers will appear ® No management control

® No control over requirements ® Visibility to competitors Figure 3.111 Some reasons agamst making a project open source

Project

,

Mnemonic Code

I •

,, I

No, of

Total Code Application Type Opel.tins 'Y'km appliatlon

Figure 3,19 Maintainability index comparing

Size (KLOCs)

I

~1C!'asc'5

Project Evolution

m('a u~d

Path

13 I

OSS project that ga"" birth to a CSS project while still evolvi"8 a OSS

ass and CSS for the same application, 1 of 2

Scx.vQr ~, toanrVs, I SIbmC'IOS. L Artgclls, and A. Ofltonomoo " open source softwaro dOYOk>prnCOl shol.dd str ive ~ even greater cooe RlIlntAtnotlilaty " ~dons of tn..t Ae M. Vol 47. NO, 10. OCtober 2004, copyrlgh l (" 2004 ASsocIaOOn lor computing MachInery. Inc. Rop'Ii"Ued by pbll'rtsOO

53

5'

CHAPTER 3 SOFTWARE PROCESS

Figure 3.20 Maintaina bility Index comparing OSS and CSS for the same application. 2 of 2 Source SamoLadas. monls. I Stametos. L Angel.S. and A. Qlkonomou. "open source SOftware oevelopment ShOUld strive for even greater code rnamtalnabIJty .. CommunlCatloos 01 the ACM, VOl 47, NO 10, October 2004, copyright, 2004 , As.soclallon for COmputIng MaChinery. Inc Reprtnted by PeHI''ViM.

Various tools and e nviro nments are available to faci litate open -source development. Figure 3.22 shows a sche matic diagram of o ne sllc h tool. Collabnet. "Subversion" is an o pen -source version control system used for many open·source prOjec ts

Key adva ntages and disadvantages of o pen -source processes are summarized below. Advantages of open source

• TI" work oj mauy moy b, obloiudj"" For projects that mo tivate o thers. work can be o btained from motivated o utSiders.

• Dn"lopm I",d

10

b, mort moliva l,d. because they choose to work o n it.

• Op",-sollrcr applieoliolls art v'ry w,lI ltSl,d, because they arc continuall y exercised by many and usually have efficient testin g processes .

Release I

I

Sales. service. /

productivity ....

I I

Cumulative

revenue

I I

I I

Time

CumulaUve expense " "

I

Open ~ource :

development : maintenance I I

Proprielary • I

Fllllr. 3.21 Hybrid open-source/ proprietary processes

CASE STUDY: STUDENT TEAM GUIDANCE

•

ColiabNet TeamForge: Structure & Features My Workspace

Community & Projects

'-*"' • ..,.. ' '''melt ' _

.. .. -=..:I

'we&. AI'IJI' ICb

,

I

...-

t

+

u...-.p.'I O'.

i

Pp'e;rtt

_rapEl.

... " ' . . . . . .

""

$

: ...

Oft.4., ' .... _ .,. ~

,:.elk 1M' ,","". do · dl ,.., 'tI 1'Ot-u.

...

\.Mit" Uk_40 _~..ub,no

lAc ....... .,.,

.,.~'-

we"e", ' 1'Oj«U

M. 'I' "tOl'I/to.w

..,tfkU MId t ooh

(,,,"",.0-0_

b, p la~

eo • 'i

•

prw.

,

--

•

,--

•

2,

,.,,' ..., 7,="

•

--

v, ..., ' 'ns

-

"

•

...

•

-

-

."' __ .0.111 C

La

I.

lOCI .. ~1101 In •

Figure 3.22 ColiabNet TeamForge: Structure and Features Source" CollabNet. httpJ/WWWopencoll8bnevproductslsleetc.apabllltles html

Disadvantages of open source

• Tbry art flIlflilablt

10 Oil'

m.d all : Th. is part of the barga.n

• DOCunlrntlliio Pl 15 qucstio"ablr: Developers are not cont;islc m

• DtSi9" dorum(1,'alioll '(lids

In

what they produ e

'0 b, poor. It seems that the ope n·source proce"

has espcc .ally great trouble keep.ng designs and code sy nc h ronized, a nd so dcsign docum e nts are ofte n poor or even no nex.sten t To ,einfo rce th e concepts o n pro esses de> ribed '" thl< chapter, we continue w.th ca e stud.c

3.3 CASE STUDY: STUDENT TEAM GUIDANCE T o re",force the many softwa re c ng",cen ng o ncepts and practice 'n trodu cd in th" book , .t's best,f ou are develop.ng a oftwan: project .n parallel You will ga lll the mo,t If the prOject .s a tea m dfort a< th.s I> ho\, most real . world ,oft ware project arc exc lItcd At the e nd of most major parl< of the book a 'C lion ( lIch a' th. s one) enti tl ed Ttam Gu.da" (ca n be found . gu .d .ng 'o u throllg h th e different pha,,,, of o llr group proJe t

55

56

CHAPTER 3

SOFlWARE PROCESS

u will he a,ked to ~c nera te speciO artd act<, and exa mple, WIll bc provIded , howi ng how real and i at hetl ca l tea m, 1(0 about develo pIng apD" atlOI1, We WIll o ft'cn USc the Encou nter VIdeo game case: study all exa mple to dlu,trate team gUIdance 1any students look back o n the lf tcam proce,' as a Slgn lncant learnIng adve nture If the team aVO Id, a few co mm o n i)lli all , th e adve nture an be a most enlI g htenin g and useful experience From o ur i,ast experie nce , the bes t size for stude nt g roup, IS (our Or five . Any less and the workload fo r each
Y h a,

mea nln g(ul way

T,p di tnbutcd th roughe ut th e te-xt arc desig ned to help groups maximize the benefit of group work. In add,ti o n, cxerelseS at the e nd o ( th e chapter assign peclAc art ifacts to be developed as the prOject progresses through the o ftware Ide cycle. T he fo llo,"ing sectIo ns provide gui dance for hnld ing an initial team meetIng , developing a team com muOIc;ltion plan. and exercisi ng the commun ica tion plan

3.3.1 Team Guidance

Initial Team Meeting

T o start 0(1 ,he project , the team shou ld have an inItial meetlO g and make the decision sho wn in Figure 3.23.

Agenda All meet lOgs should have a wnnen age nda and specific start and end times.

Team Leader Decide who your Ars t team leader wi ll be (being a tcam leader provides yo u with valuable experience but puts additional demands o n your time and communication skills) . To distribute the beneAt of team leadership practice . It can be beneAClal to swa p team leadership about halfway through the projec t. Both team leaders can be chose n up front , and they ca n back each other up in case of emergency.

i . Set agenda and tIme limits 2. C hoose the team leader. 3. Get everyone's commitmC!nt to required tim e.

o

DeAne an expected average number o( hours per week.

o

Cather da!es of planned abse nces.

4. Take a reali stic ce nsus of team skills. o Commo n problem : inflated programming skill claims. 5. Begi n form ing a vision o( the application . 6. DeCIde how team will communicate. 7 Take meeting minutes with concrete .cllon Itcms. Figure 3.23 initial student team meetlng-generai Issues

•

CASE STUDY: STUDENT TEAM GUIDANCE

Time Commitment A big source of frustratIon in tudent teams is a lack of commItment of some team members. It is far better to d, cuss commitment at the beginning than to try to fix a problem after the project is under way. To reduce ~he rc entment that follows when some team members feci they arc contributing much more than others, set In advance an expected number of hours of commitment per week . This al,o helps to make members work more efficiently .

Team Skills For tudent projects there is often a trade ·off between producing an impressive · looking product and learning new skill . To produce the most impressive product , team members would speciahze along the hnes of their greatest strengths. This is a typical industrial mode . They may al 0 be tempted to sk ,mp on document.tion In order to demonstrate more features . T o learn the most, however, team members need to try actiVIties '"ith which they are inexperienced (e .g., team leade rs hIp). They also need to do thing rig ht. Teams deCIde how and when to trade off between goals by speCifying when they WIll specia hze and whe n they wi.ll try new role Instructors try to establi sh evaluation criteria that encourage learning.

Vision All projects start out with a vision for the software to be developed In industry thIS is tYPI call y initiated by the marketing department, which develop bUSIness req uirements fo r the product For ,tudent projec ts, the product vision includes the purpo e of the application , major (u nctionality and operatio ns, and major ",puts and outputs .

Communication Plan Decisions need to be made as early as possible as to how the team will handle commUnicatIon . The next section covers this in detail.

Meeting Minutes During team mcetings, a member is de ignated to write the meet ing minute The purpose of meeting minute is twofold. First, al l important decisions or agreements that are reached are recorded , ' 0 they are not forgotten and can be referred back 10 if necessary . As an example, during the meeting it rna)' be decided that Coogle Docs will be used for storing all project speciRcation . This decision is recorded in the meeting mInutes. The second purpose of meeting minutes is 10 record unresolved issues that require follow up action. These arc referred to as achon itrm s. Each action Item is assigned to one or more team members with a target date for

completion . An example action item might be that Joe is to investigate and recommend a sourCe o ntrollOol for managing the project's source code, and is to complete his actIon In one week. It is a good Idea to revie," open action items at the start of each team meeting.

3,3,2 Team Guidance Communication Plan When a softwa re prOjec t IS IOltiated in IOdustry, a set of project gUIdelines, 1001s, and commUOlcatlon procedures IS tYPIcally established 10 ensure that the project IS cxecllled a effiCIently as pOSSIble ThIS hould also be done for you r f(roup proje t. Many team problem ari,<." (rom a failure to 01l1tnunicatc fully ThI S problem i nOt Itm ited to ,tudent prOjcct,_ Real -world teams suffer from 11 as well. Errecl1ve verbal com01uOl ation means maklOl: sure our thoughts are fully understood and I, steninll 10 what o thers arc ,ay'ng Th, " ntl al (or team' to be

57

58

CHAPTER 3 SOFTWARE PROCESS

I L"len

10

all Wllh on enl'" tl n

• Don't pre-judl!e 2

"ve all leam member; a turn •

ce Ihe value on every idea,

3 Oon'l make as,u mp" on • Ask quesl lo n to clarify, -\ , \'(fhc n in doubl , om munica le Figure 3.24 Key precepts of communication

uccesshll. The pre epts shown in Figure 3.24 will h e lp you avoid ma ny communication problems. They sound simple but ca n be hard to follow , especially during times of stress. C reate pol,ei" for commun ica ting and sharin g informatio n with each other, oncludi ng gUi delines for g roup ed'li llg and merging of documents, setti ng up a nd agreei ng to meeti ng times, sharing project artifacts, and so o n DeCide on procedures lor how yo u will ge nerate docume nts for the projec t. You pro bably ha ve to deal wi th di ussing the scope and co nte nts of a document , writing initial dra fts, ed iting th e drafts, gettong group agree me nt on edi ts, merging drafts and producin g the final document Many teams-i ncludin g some stude nt learn s-a rc widely di stributed geogra phically, and the means of commun ication becomes especi all y important. Large projects arc often developed by multiple groups at mul tiple si tes, someti mes in multiple countries. Mergers, acquiSitions , "ollshoring," dis persed speCialists, and joi nt ve ntures ofte n ro ult on people at multipl e si tes working together on projects. An increasi ng number 01 products are available to lacilitate group work, including groupware, video conferencing, and in tant messagi ng . Each com municatio n medium has speCific stren gths. In an y case, wellrun face -to -Iace meetings are very hard to beat. II possible, schedule re gular face -to-face meetings at least once a week lor a n hour. It is hard to conve ne an unscheduled meetin g but easy to cancel a scheduled meeting . You can make It a goa l to limit actual meetings to less time. However, il the committed time is short-say a hall hour -you will ~nd It very difficult to make lo nge r meetings because people will build the sho rt time Iomit in to their schedul es. If you think that your tcam may need to meet additionally, it is advisable to agree o n when that would be each week. Set aside the time and aim to aVOid a meeting. This provides a posi tive goal and it avoi ds the problem 01 repeatedl y trying to find a common time when meetings are nee ded. When you set meeti ng times, specify an end time . Meetings typically expand to fill the allotted time. You should always have an agenda for your meetings, otherwise your meetings will be less organized and not as productive as they could be_ E-mail is an essential tool, but can be pro bl ematic due to unpredictable delays. Messages can become unsynchro nized , damagi ng the threads of d ia logs. This is e pecially senous near the end 01 a project when communica ti on is (TC:quent and of immediate importance

Use a shared Web Site, wiki , o r chat -ty pe faCility . For example, at the time 01 thiS writin!! , a number of frec collaboration too ls arc available fTOm Coogle. Do not merely state that you will use a particular tool such as Microsoh Word lor word processin,_ Specify a version number, and exchange a lew documen ts to be sure everyone c an read and edit them. Don't c hange versions during the project without ensuring compatibility first , Document your decisions in a team (om... ". iratio. Pin. , as outloned in Figure 3.25.

SUMMARY

1 Meetings : TN'" ' vIII meet each Monday fro m .. to .. In tllHal do Plot rtpln ( In('(~lo -fa t nltttlt19 wtlh rt'"ott II1t(/II'9s u,lIns

.

(('molt mttlh1gs

arc

de.lr/Y .JJtt"hve. 2. Meeting alternative : Team members should keep Fndays open from

.. to

.. In case an additional

meetlng is required

Standards: Word processor, pread heet, compi ler,

•

•

4 E-mail : Pote · mails~; require acknowledgement]

nvtol (-milll is poor jar

j"lflISiv(

collaboratioll

5. Collaboration: Tools for group collaboration and discussion _ e .g. Yahoo Croups , Wiki too l, Coogle tools, ... 6. Other tools: Microsoft Project (scheduling), Croup calendar,

•

•

•

Figure 3.25 Communication planning-forms of communication

3.3.3 Team Guidance Test Communication Plan It is important to test the methods speciRed in you r Com munica ti on Plan so you can make necessary adjustments as early as possible in the project. This will avoid scra mbling for alternatives a the project workload increases . Search the Web for the latest information o n a topic determined by the instnlctor. Note at least four of Its baSIC goals and at least five of the techniques it uses. Have everyone in the group contribute ome information. Create a document containing your group's results, and practice how you 'vIII utd ize your procedures for group editing and reviews. How 'viII yo u o rganize thi random activity] H ow can you obtai n a useful result instead of a conglomerallon of unco nnected text

3.4 SUMMARY A software project progresses through a ~erles of activities, staning .t Its conccl>ti on .nd conllmllng all the way through its release Project arc orga nized into phase , each with a set of aC!IVllies conducted during that phase. A soflw.rt process preSCribes the interrelationship among the ph.,es by expressing their order and frequency, as well as defining the deliverable of the proJect. SpeC ific sofrwdre processes arc called ,of'"'ar, prow, ,"odd, or 11ft u ltlng in a reflncl11e nt of the reqUirement , de"gn , o"d Implementation . AI the on IU 51O " 01 an Iteration, operational ode IS produLcd that uppom a ,ub~el of the nnal pr du t' lun 1I0 nolit)' Project artifacts such a~ plans, > p ~Clh atlon<, and ode evol ve durinl! ca h pha~e and owr the Id e 01 tlw pr Ie t Examples of lterallve Pfl)CC" s melude the

/1".,,",

59

60

CHAPTER 3 SOFTWARE PROCESS

A~,/, pro e"e< arc 1"8 hl

itl'raII ve , and elllphas,ze workln~

ode Ih roughout, as wel l as frequent

,ntcra tinn.; with th e U\lOIlU.:r.

A PllllolyPt ' a partia l lI11pl emcnlallon of the largel app licali o n u clu l ,n ,dent"'}'ing and re llring rISky part> of a projc 1. 11 can roce , lIIodel. inco rpo rale prolo lypes ,n o ne or more o f Ihelr Iterallons omC lImes, it " unclear whe lh er certa,n requiremenls ca n be ,mplemenled In pract,ce, plac,ng the enl.re prOject at " k. In su h cases, !((I"bd, ly " lIdits may hc advisable, wh.c h are partIal Im plementations or si mula lions of the app hCJ lio n. In o pen· ource proces <s, so ftw are is developed and malnlained by peo ple o n a volunteer basis. Sou rce code 's open 10 all , and th ere Is a process for virtua lly anyolle to susgest and Impl eme nt e nhancements and . ubmil and repalfddccts This process is re pea ted and the app hcat .o n grows in ca pabili ty and stabIli ty. In thIs wa , ope n· source proje ts are developed ,n an iterat,ve manner. In addit,o n, by exercising an application many tim es, th e ope n-course community rtlnctlons as a huge test ing process.

3.S EXERCISES 1. During whi ch process phaseCs) would each of the fo ll owi ng aClivities occur;>

a. Creating a project schedule b. De leml irlin g Ihe need for a bar code reader c. Req uestin g the additio n o f a fi le backup ca pability d. Performi ng a feasibility ana lysis e. Documenting the software interface to an SQL database

f. Acceptance of the softwa re applicallon by the customer 2. G ive an example of a software project that wou ld beneAt much mo re hom usi ng the waterfall process than fro m using most of the alternative processes. Explain your reasoning. 3. Describe the d ifference between iftr.,i., and incrt",,,,,., development. Describe the ways in which they arc related. 4. Give an example of a software project that would beneht mo re fro m usi ng an iterative and .ncremenlal process than fro m using most of the alternati ve processes. Explain your reasoning. 5. a In your own words, explain hmv the spiral model utilizes risk anal ysis and risk mitigation. b. Exp lain why Ihe o uter spiral of the spiral mode l utilizes Ihe waterfall process , and how the spiral model miligates the inherent disadvantages of the waterfall process. 6. Give an example of a software project that would beneR t much mo re from usi ng the spiral process than from usi ng most of the alternalive processes. \'(frite a paragraph explain ing yo ur answer. 7. How do the phases of the unified proce .. (UP) differ from the pha es usually deRned for oftware processes' 8. Describe Ihe pros and cons of each va lue listed in the Agi le Manife
EXERCISES

Communication For the following exercises, consider as a group how you will perform them , check the hints below, then carry out the assignments . TI . Decide who your team leader{s) will be . Note that being team leader provides you with practice that may be hard to get otherwise. T2 . Decide how your team will communicate, specify your communication tools and methods, and test your communication methods. Be specific: YOll may change the specifks later. T3 . Search the Web for the latest mfomlation on a topic determined by the instructor (e .g., the TSP). Note at least four of its basic goals and at least five of the techniques it uses. Post the references to the course forum or \'(feb site If there is one. and annotate your posting with the name of your group . State individual or gTOUp opi nio n of the topic or issue. Your team respo nse should be 4-7 pages long .

Hints for Team Exercises TI hints: To distribute the beneRts of team leadership practice, It can be beneficial to swap team leadership about halfway through the semester. Both team leaders ca n be chosen up fTont , and they can back each other up in case of emergency. Such backing up is a good practice in any case, because the probability of a team leader having to quit a project o r a class can be high . ote that the second half of a project typically requires the team leader to make decisions more quickly than the first half T2 hints : Examples are telepho ne, meetings, e-mail , forums , chat facilities , and Web sites. I. Schedule regular face-to-face meetings at least once a week, if possible It is hard to convene an unscheduled meeting but easy to cancel a scheduled o ne . 2. E-mail is an essential tool. but can be problematiC due to unpredictable delay . Messages can become unsynchronized, damaging the threads (subjects) of dialog . This is espeCially senous near the end of a proiect when communication is frequent and of immediate Importance . 3. Use a shared Web si te or chat.type facility . Free services are available at hnp://groups.yahoo. com!, for example . 4. Do not merely state, 'We will use Superword for word processing ." Specify a version number, and exchange a few messages to be sure. Don't c hange versions dunng the project without ensuring compatibility Rrst. 5 Try out all the standards and methods you have chosen . Throughout this program of study, validate your plans and inte"tions with practical tests whenever possible. Try to u e at I~ast two independent tests. In genera l, assume that your project Will be much more demanding In the future than it is at the beginning . T3 hints: Usc th is activity to strc ~ your communication system . Forexample , you may want to set up a Web site to which team members are to add new TSP mformation How will you orllaniu thi random actlvlty7 How can you obtain a useful rc. ult In tcad of a conglomeration of unconne ted text7

61

62

CHAPTER 3 SOFTWARE PROCESS

BIBLIOGRAPHY I. Ro "O c, \: " ·M~n"t4lng the DC'v(lopmcnt o r Large Sohw3 rc YS It'lm o ncc:pts 3nd Tt'chnlquc'l: IEEE WESCON "70 , Aul\Kt 1970. pp 1- 9 2 BluMer, Kurt , .lnd Spence', I • 2007, "Mmt4~t"g hffolljW So/tuum DwdopMmf P,o), 's:' Addjson -Wc~IC)" , Peirson EduC1tlon, Inc. kbum. Alistair · Unr.wdlllM I nc ~m('nl
Agile Software Processes

Planning

..... The Software Development Ufecycle

•

How did agile melhods come about?

•

What are the pnnclples 01 agility?

•

How are agile processes carried out?

•

Can agile processes be combined with non-agile ones?

Design Figure 4.1 The context and learning goals for this chapter

In the t9905, agile softwa re development came In lO being as an a ltern ",ve to the existing classl al approa hes to ofrware engineering that were percelvt·d to be too · pro ess·heavy · TI,e e claSSical approaches emphasize the need to plan projects In advJncc, cxpn:s, requirements In writing, provide: """tten deSign sa ti sfYi ng the reqUIrement , wrlle odc ba ed o n these de\lgn' an,fying the written requiremcnts, and fina ll y 10 test the results A we ulstll<>ed in hapt er I and 3. how<'Vcr, Illany prOjects (ollowlng the e steps exh ibit major prol lem, A primary rea,on I< that >takeholders do not ~ uallv kn w at the mCeptlon of a proJeu entirely ,,,hat they reqUire Ag"e process!:, addre" thl< shan oOllng Thl' hapter dc(,n~s w hat" meant by as"e dewlopment, des nbe< ,evera l peclfic softwa re proce"e. that adhere to allile pnnclples and arc thus ons ldered procc"e" and d"Lu ses h ow all " e and non -ag ile pr c'>es can be coOlhtncd

.B"e

6.

CHAPTER 4 AGILE SOFlWARE PROCESSES

4.1 AGILE HISTORY AND THE AGILE MANIFESTO gro up of II1du, try ex perl, me t "' 200 I to d l cuss way' o f Improv in g on the the n wrrent
",St.

• Clo<e co lla boration betwee n prog ramm ers and busi ness experts • Face · to·l-ace communi catio n
Individuals and Interactions (over processes and tools) For decades, manage ment practice has emphasized the hi g h value of commun icat io ns. Agile pract ic~s emphasize the Sig nifica nce of hi g hl y ski lled ind ividuals and the enhanced expertise that emerges from '"teractions among them . Altho ug h processes and tools are Important, skilled people should be allowed to

We are uncovering better ways of develop ing software by do ing it and helping others do it Through this work we have come to value:

1. Individuals and interactions over process~s and tools

2. Working software over compre h e nsiv~ documentation

3. Customer collabor.ation over co ntrac t negotiation 4 . Responding to change over following a plan

That is, while there is value in the items on the right, we value the it~ms o n the left mo~ .

FIlii" 4.2 The AgIle Manifesto

AGILE PRINCIPLES

adapt the proce5 and modify the tools as appropriate to ge t their job done as efficiently as possible. As suggested III [ 3J. agile ",ethods offer generative values rather than prescriptive rules, a nllnimum set of values. observed in all IllIation , that generate appropriate practices tor specia l situations . Individuals and teams usc these rulC'S when problems ari c a a basis for ge nerating soluti o ns that are appropria·te for the projecl. ereali iry IS emphasized as a major means for problem solving. Thi s is in contrast to more rigid sofrware proce e , whi h pre cribe a set of predetermined rules and force teams to adapt themselves to these rules. Agile practices uggest that the laner approach is not effective and actually adds to the risk of project failure .

working Software (over comprehensive documentation) orking software is considered the be t indicator of project progress and whether goals are being mel. Teams can produce pages of documentation and supposedly be on schedule , but these are really promises of what they expect to produce . Agile practices emphasize producing working code as early as possib le . As a project progresses , sofrware functionality is added in smalllncremenlS such that the softwa re base continues to function as an operatio nal system. In this way team members and stakeholders always know how rhe real system is functioning . Although Significant, working software is of greatly dimin ished value with out reaso nable documenta · tion. Agile practices emphasize that project teams determine for themselves the level of documentation that is absolutely essential.

Customer Collaboration (over contract negotiation) This statement emphasizes the fact that development team arc in business to proVide value to cuSlOmers. Keeping as close as possible to your customer is a long-established maxi m of good business practice . Many programmers are disconnected from the cuSlOmer by organizational layers and intermediaries, It is highly desirable to remove this barrier. All stakeholders, including customers, should work logether and be on the same team. Their different experiences and expertise should be merged with goodwililhat allows the team to change direction quickly as needed to keep projects on track and produce whal i needed. Contrac ts and project charters with customers are necessary, but in o rder to adapt to inevitable change, collabo ration is also nece sary [3].

Responding to Change (over following a plan) Producing a project plan forces ream members to think through a project and develop contingencies . However, change is inevirable, and agile practit ioners believe that change should no t only be planned for but also embraced_ Very good project mana gers plan to respond to change, and rhis is a reqUirement for teams operatlllg at the most effecti ve leve ls, as you will see when we discuss rhe hi ghest capabi lity levels of the CMM I in Section III of this book. As changes to the plan occur, the team h ould not tay focu 'ed on the outdated plan but deal instead with the changes by ad.ptlng the plan as necessary [3). Agile practices rely on short iterations of one ro six weeks to prOVide timel y project feedback and IIl fo rmati o n necessary to as ess project progress and respond as necessary.

4.2 AGILE PRINCIPLES In addItion to the va lues dcscnbed in Figure 4.2, Ihe aUlhors of th e Agile Mani!e to oU llined a se t of ~uidi n g prlllcipies that ,upport the manifesto. The,,, arc quoted from [ I) (bold added ). • "Our nIghest priority .. to sa tisfy the custo mer through early and con tlnuo u. deltvcry f valuable suftware • Welcome changin g requi remen ts, even lale In development. Ajlilc pro esses harness OJstomer's competitive advanta~e .

hange for the

65

66

CHAPTER 4 AGILE SOFTWARE PROCESSES

• Deliv~r working software frequently , from a couple of weeks to a o uple o f mo nth •. with a prefer nce to tI,. shaner timesca le. • BU5mess p~op l e and developer must work together dally throughout the prOject • Build projects around motivated ind ivid uals. C,VC them the e nvironment and support they need, and trust them to get the job done. • The most effiCient and effective method of conveying Infonnation to and With," a development team IS face-to-face conversation .

• Working software i the primary measure of progress. • Agile process. promote sustainable developme nt. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attemion to technical excellence and good design enhances agi li ty . • Simplicity-the art oJ maXi mizing the amount of work not do ne-i s essential. • The best architectures, requirements, and designs e merge from self-organizi ng teams. • At regular interva ls, the team reflects o n how to become more effective , then tunes and adjusts its behavior accordingly." Many of these principles are implemented in prac tice by the agile methods de cribed in the next section .

4.3 AGilE METHODS This section describes some of the methods by which many agile processes practice the principles in the Agile Manifesto. Figure 4.3 shows the manner in wh ich agi le methods implement the Agi le Manifesto, a. fo ll ows. Agile processes common ly employ small . close-knit teams; periodic customer requirements meetings; a codece ntric approach ; documentation on an as-needed basis (e.g ., high-level requirements statements o nl y); customer representatives working withi n the rcam ; rcfactoring; pair programming; continual unit-testi ng" and acceptance tests as a means of setting customer expectations .

We next e laborate on the topics not already explai ned above. Pa" programming is a fo nn of continua l inspection by one team member of the work of a teammate. Typically, while one programs, the other inspects and devises tests. These roles are reversed for periods 0 time that the pair detennines. Documenling 0" an a5-ntcd,d basi, usually ,"valves writing some high -level reqUirements but not detailed requireme nts. These arc freque ntl y collected in the fonn of '"'' 5/0ries . A user story is a Slgn ltkant task that the user wants to accomplish wit h the applicatio n. According to Cohn (4), every II er story consists of the follOWing; • A written description • Conversations with the customer that establish a mutual understanding of • T eslS intendcd to validatc that the user story has been implemented

It

purpo e and content

-

1. Individuals and interactions over tools

-

--

and

2. Working software over comprehensive documentation MANIFESTO _

3. Customer collaboration over contract negotiation 4. Respond ing to change over fOllowing

RESPONSES :

a plan

a. Small, close-knit team of peers

y

b. Periodic customer requirements meetings

y

c. Code-centric

y

y

y

y

y

d. High-level requirements statements only

y

y

e. Document as needed

y

y

f. Customer reps work within team

y

y

g. Refactor h. Pair programming and no-owner code

y y

i. Unit-test-intensive; Acceptance-test-driven

y

y

j. Automate testing

y

y

Figure 4.3 ways to address the principles of the Agile Manifesto Examples of user sto ries fo r a video sto re applica ti o n are as fo ll o ws, • "The use r ca n search for all D VDs by a opve n d irecto r." • 'The user can establi sh a n acco unt tha t re me mbe rs all tra n ac tions wit h the c ustomer · • 'The u. e r can view all ava ilable in fo rmatio n o n any DVD " o"lI"unl i"llractlo" a nd contac t With the cu to me r is ac hi eved In twa wa ys. Fi rs t, the wo rk periods ( 1- 6 wee ks, usually ) in whic h the each batc h o f reqUire me n t arc to be flll Rlled are speciRed With a tea m that Involves the custo me r ('co nd, a cUSto me r re presenta tive I< e ncouraged to be part of the tea m. TI,e e mphaS IS o n worki ng soflwart is rea lized by mea ns o f coding versio n o f the applica tio n a nd sho '"lng them to the custo me r. These arc usually clo el y tied to corres po nding test< Indeed , Icsl-dnvOi drvclop",mt an allile a pproach , actua lly has devel o pers wfIte test< even before devel opi ng the code

68

CHAPTER 4 AGILE SOFTWARE PROCESSES

Oblaln requirements for next perlod's' segment

Obtain hlgh-tevel requirements

Relector to clean up

Relactor to accommodate new requ irements

Modify code and test code base to handle additional requirements

• Typically 1-6 weeks

Figure 4.4 A typical agile development iteration

Rcfa

1011"9 is a process of altering the fonm of a code base while retainin g the same functionality . The

usual goa l of a rdacto rln g is to make the design amenable to the addition of functionality , thereby satisfying the agile deSIre 10 respo nd "'CillO c hange. The very fact that the discipline of rcfactoring has been developed IS a majo r f.clO r mak ing agile methods possible This book covers rdacto ring in Chapt.er 24 . Although refactorin g is discussed latcr in the book , much of it will be useful before then and can be referred to throughout the book. Agile metho d. employ the developmen.t cycle shown in Figure 4 .4 . T y picall y , the requirements are expressed in terms of lIser stories . Past experience in the project allows the team to assess its _docily , an assessment of the relati ve diCficulty of tories and the rate at which it is able to implement them The schedule effects of agile me thods can be seen in Fib>tJre 4.5 . Planning is attenuated because there is less to plan . Requirements analysis, design, and testing are often conRned to high levels. The emphasis is mostly code ce ntered .

4.4 AGILE PROCESSES "Agi le developmen t" isn't itself a spe iRe process or methodology Instead , it refer.; to any software proc('Ss that captures and embraces the fundamental va lues and principles espoused in the Agile Ma.nifesto. The following sectio ns illustrate and describe three agile processes as repre cntative examples. • Extreme programming (XP) • C rystal

• Serum

AGILE PROCESSES

• Time line Plan lor agile methods

C,"'X <,-. " '~I-. ...........~ ..........:.~;.o..~...... ""\"'~J:1: t
" . .'

-_.

' ••

Implement in agile fashion System tests not covered by agile method:

Figure 4.5 The agile schedule

4.4.1 Extreme Programming In 1996, Kent Beck and co lleagues bega n a project at DaimlerC hrysler [51 using an approach to software development that appeared to make marters muc h simpler and more efficie nt. The methodology he developed and used became know n as Exl""" Prograrnrni>lg (XP) [6]. Beck [6] cites fo ur "values" gUidi ng extreme programmi ng, communication , sImplicity, feedback , and courage. These are summarized in Fig,,"'s 4 .6 and 4 ,7. XP programmers communi cate continuall y with their customers and fc ll ow programmers. TI,ey keep their design simple and clean , They obta in feedback by testing their software, starting on day o ne. They deliver parts of the system to the customers as early as possible and Impleme nt changes as suggested , With this foundation , XP programmers are able to ·courageously· respo nd to c hangi ng requi rements and techno logy [5]. XP was created to deal effectively with projects in wh ich requirements c han ge . In fact , XP expects requirements to be modified and added , O n man y projects, custo mers start with o nl y a vague idea of what they want. As a prOject progTesses and a customer sees working software , specifks of what they want become progressively firm .

I. Communication

• Customer on site • Pair programm Ing • CodIn g st.1ndards 2, Simplicity

• M e taphor: e ntity names drawn from COmm o n met"phor • S,mplest d eSIg n (or c urrent reqUIrements • R.efac tOnng

Figure 4.6 The "values" of extreme programming, 1 of 2 SOuru- 8.:;)'... YMYt, •.~ PtOSfMlming Eltplak'wl EmbrAce Chang.," ~ddl50n·w8S1BV. '000

69

10

CHAPTER 4 AGILE SOFlWARE PROCESSES

I Feedback alwa y, a u!!hl

• • •

onlJnual l c..~ "tln g Ol1tll1UOU' 'nlegra tl o n (al leasl dad y ) mall ",lease (small e' l usdul feature ,el )

2 Courage

• Planning and esti matio n with • a llectlve code owner-hip •

u ~ t O lll cr

use r stones

ustain ablc pace

Figure 4.1 The "values" of extreme programming, 2 of 2 SOUtre. Beck.. Kenl "Extreme Programming EkJ)Ialned' Embrar.e Chango," Addlson·Wesley, 2000

XP projecls are divided inlO ilerations lasting from one

to three weeks . Each iteratio n produc~s

soft ware that is fu lly tesled . Al the beginning of each , a planning mecli ng is held to determine the COQ t~nts of the iteration . Th is is "just · in . time" planning, and it facilitates th e mcorpora ti o n of changing requirement s.

As code is devel o ped , XP rel ies o n continual integrati o n ralhe r that assembling large, s~ parately developed mo dules. In the same spint , releases are modest in added ca pability . The idea is to bite off a small amount of new ca pability, integrate and lesl it thoroughl y, and the n re peal Ihe process. EXITeme prog ramming recog nizes Ihe all . loo . frequent breakdown in c usto me r devel o per reiationsh ips, w h e r~ eac h pa rry de velops a scpa ralc concep l of what's need ed and also h ow much th~ features will cost to devel o p. Th e resull of Ihis mi smatc h is , all too often , a mad dash for deadlines, including lo ng workin g ho urs and a n un suslainable pace. In respon se, eXlreme progTamming promot~s a modus vive ndi thaI's susta mable in the lo ng term . In addition , it requires every developer to acknowledge up front Ihat all code is everyo ne's commo n property , to be worked on a the project's needs require . In o lhe r words, no code "belo ngs" to a prog rammer. This is in keeping wilh engineering practice , where a bridge blueprint , fo r exampl e, is the product of an o rga nizalio n and nOI the personal property of o ne desig ner. XP is unique in usin g twelve practices Ihat dicta le how programmers should carry out their daily jobs. These twel ve practices arc summarized next (7). I. Planning Process . Req uirements, usuall y in Ihe form of user stories, are deR ned by cuslomers and given a relative priority based o n cost esti mates provided by the XP team . Slories arc assigned to reieases, and Ihe team breaks each slory into a set of tasks to imp le ment. \Y/e described user stories in Section 4.3. 2. Small Releases. A si mple system is buill and pUl inlo produclion early Ihat includes a minimal set or useful reatures. The syslem is updated frequentl y and incrementally thro ughout the deveiopmenl process. 3. Test-Driven Development. Un il tests are wrinen thaI functionalllY is aClually wrilten .

10

leSI funclionality, before the code to implement

4 Refactorlng . Code is regularly modi fie d or rew ritte n 10 keep It simple and mainlainable Chang~.~ Incorporated as soo n as de Acie ncies are idenlified. We ,"troduced rdoc toring in S~tion 4.3 and cover It in delail in C hapter 24 5. Design Simplicity. Desig ns are created 10 solve the known reqUirements, not 10 solve future rcqui~ ments. If necessary, code will b~ refa lored to implemenl fulure dcsisn needs.

AGILE PROCESSES

6. Pair Programming . This was described in Section 4. 3 7. Collective Code Ownership. All the code for the system is owned by the entire team. Programmers can mod,fy any pan of the ystem necessary to complete a feature they're working o n. Th ey ca n also improve an part of the system . S. Coding Standard. For a team to effectively hare ownership of all the code, a common cod,ng standard must be fo llowed. 11,is e nsures that no matter who writes a piece of code, it will be easi ly understood by the entire team . 9. Continuous Integration . Code is checked into the system as soon as it's comple ted and tested. Thi s can b" as freq uent as severa l tim e per da y. In this way the system is as close to production quality as possi ble. 10. On-Site Customer. A customer re prese ntative is available full · tim e to determine requirements, sct priorities , and answer questions as the programmers have the m. The effect of being there is that commun ication improves, with less hard -copy docume ntati on-ofte n o ne of the most expensive parts of a software project. I I . Sustainable Pace. XP tea ms are more productive and make fewer mi stakes if they're not burned out and

tired. Their aim is not to work excessive overtime, and to keep themse lves fresh , healthy, and effective. 12. Metaphor. XP teams share a common visio n of the system by deR ning and using a commo n system of describing the art ifacts in the project.

4.4.2 Serum Serum is an agile methodo logy deve lo ped in the early 1990s . It is named after the part of a rugby ga me that , in U.s. foot ball terms, is a cross between the kickoff and a quarterback snap . As deRned by the Merriam Webster dictionary, a scrum is "a rugby play in which th e fo".ards of each si de come together in a tight fo rmat ion and struggle to gai n possessio n of th e ball using thei r fect when it is tossed in among them ." In o ther words, scrum is a process that follows "o rganized c haos." It is based o n the no tio n that the developme nt process is unpredic table and complicated, and can only be deRncd by a loose set of activities . Within this framework , the development team is empowered to de Rne and execute the necessary tasks to succes fully develop software. The flow of a ty pica l sc rum project is show n in Figure 4.8. A project is broken ,ntO teams, or scn,ms, of no more than 6-9 members. Each team focuses o n a e lfcontai ned area of work . A scrum master is appoi nted and is responsi ble for conducti ng the daily se rum meeti ngs, mea uring progress, mak ong decisions, and clearing ob tacle that get in the way of team progress. The daily scru m meetings shou ld last no more than 15 minutes . During the mee ting the Scrum master, allowed to ask team memb"r< o nly three questio ns [8]: I. What ,tem< have been comp leted since the last serum meeting: 2. What issue< have been di covered that need to be reso lved) 3. What new assignments make sense for the team to complete untol the nex t scrum mee ting) At the begonning of a projec l, a lost of cu

71

72

CHAPTER 4 AGILE SOFTWARE PROCESSES

every 24 hours l S·mlnute dally meetings 1) Done since laSt meeting?

2} Have any obstacles'?

Sprint Backlog 01 assigned features ••••

Backlog items expanded by team

3) What will

30 days

Product Backlog

you do belore next

meetrng?

New Functionality Demonstrated at end of sprint

Prioritized product features desired by customer .

Figure 4.8 The serum work flow SOUrce: QuoteCI and edited from t\rtf)'jfWvrIW coouolchaos.com/aboul

control of how they are to successfull y complete the spnnt. At the e nd of a sprint a customer demonstration is conducted for the cuStomer. It serves several purposes, including [8],

t . Demonstrating to the custo mer what has been accomplished . 2. Giving th e develo pers a sense of accomplishment . 3. Ensuring that the software is properly integra ted and tested 4 . Ensuring that real progress is made o n the project.

At the co nclusion of the dem o nstration, the leftover and new tasks are gathered, a new backlog is created r and a new spri nt commences.

4.4.3 Crystal Crystal is a family of agile methods devel oped by Alistair Cockburn . Each Crystal method shares common characteristics of "frequent delivery, close communication, and reRective improvement" (9 ). ot .11 projects are the same , so differe nt Crystal methodologies were crea ted to address differences," project size and critica lity. Figure 4.9 shows the different methodologies and the size project they are best suited to. Crystal methods are characterized by a color, starting at clcar for smaIJ teams and progressing through to or""9'. mi. and so on as the number of people increa ·os. For example, Crystal lear IS geared for smaIJ teams of approxima tely 6 people, YeIJow for toams of t 0-20 people; Orange for teams of 20-40 people , and so o n, The other axis deRnes the critica lity of a project, where L IS loss of life, E IS loss of es enllal monies. D IS loss of discretionary monies, and C is loss of comfort . Note that the row for los of life" nOt shaded in Figure 4.9. This is because Cockburn had no experience applying Crystal to the e types of projects when he .... ated th...

AGILE PROCESSES

L6

,,,

............. , E6

Clear

loss 01 life E ; loss of essential monies D ; loss of discretionary monies C ; loss of comfon

L;

Figure 4.9 Coverage of various crystal methodologies SOUrce; Adapted trom CocXburn. AlistaIr, "Crystal Clear A Human-Powered MethodOlogy for Small Teams," Aadlson-wesJey, 2005

chart. Crystal Clear doesn't explici tl y suppo rt the E6 box, although Cockburn no tes that teams may be able to adapt the process to accommodate such projec ts. Ano ther restrictio n of Crysta l is that it is al'plic2ble o nl y to colocated teams. Cockburn believes that deve lo pers do no t read ily accept the demands of fl"Y process (docu mentatio n, sta ndards, e tc ). H e strongly recomme nds accepting thi s by Introduci ng the most limited amou nt of process needed to get the job do ne successfull y, ma xi mizing the likelih ood that team members will actua ll y fo llow the process. All Crysta l methodo logies arc built around three commo n pri o rities (9} I Safery in the project o utco me.

2. EffiCiency in development. 3. Habitability of the conventio ns (I.e ., the ability of devel o pers to abide by the pro es itself) . Crystal projects exhib it seven prope rti es to varyi ng degrees (9) I

Frequent delivery .

2 Reflective Improvement. 3 4.

lose commun ication

P -"ona l safety.

5 Fow, 6 Easy a"ccss

to

exp rt use rs

7 Technical ~nvlronm""nt With au to mated t('''tln~ , con If.:ura ti on manage men t, and Ircqllcnt In H:..:ratl n.

73

74

CHAPTER 4 AGILE SOFlWARE PRO ESSES

III

n,e I1r,t three p,opertl '~rc commo n to the ry\tallJmlly The others Cdn be ad ded ,n any order to rc."c the I'Ke llhood o f 1)l'o)ec t ,afety and SULtesS.

4.5 INTEGRATING AGILE WITH NON-AGILE PROCESSES Th e advantage. 0 1 agile meth ods in lude the abll,ty to adjust eas ily to emcrlling and c hangi ng rC'Iu".ment' n,c d,sadvantage in lude awkward ro le for de iBn and dowmentat, o n ockburn's Crystal fam,ly 01 meth dologies alrcady acknowledges that different k,nds of appllcallons must be treated d,fferently . L"Ven when the metho ds are ag de . oft",.re pro e. s, after all , oncerns the order in which we perform act,vities' Fo r example, deSigning Ars t and then coding from the des'gn One extreme IS the waterfall process. As we have seen, there are many IIm,talions in our ab d,ty to thorough ly perform the waterfall sequence:' o nce, or even a few times, 'terat,vely. hangea ble and unknown requirements are a principal rea on Regardless of the development process we use, we must make trade ·offs in deciding ho w ex tens,vely to pursue a phase befo re movlO8 to ano ther phase. o nSider, for examp le . the issue of how much effort to spend on planning a software enterprise. One extreme project situation is when we are certain of obtaining all of the requirements of the end date , of the high ·level deSign , and of who wi ll be working on the job. In that case, we can and probably should devel op a de tailed plan . The other extreme prOject ,tuation is when ,_e have little idea of any of these factors , believing that they wdl beco me clear only after the project is under way . In that ca e, planning at a detailed level would be a wa te o f time at best becau e it could not be even nearl y accurate, and would probably even be misleading. We ha ve no choice in this case but to begin the process , and revi sit the plan as required. The extremes are Illustrated In Fi gure 4. 10. Agile methods provide beneAts bur also costs, and these depend o n several factors . Some are shown in Figure 4. 1 I. In order to gain the advantages of both agi le and non·a gile' processes, we try to integrate them . The means by wh,ch this can be performed depend on several !actors, but particularly on the size of the job. As of

100%

---------------------• Can obtain all require",sntSr

• Certain of end dale • Certain of hlglHe.el design Advisable delallievel 01 plans

.-

• Certain of personnel ~HIGH

DETAIL PlAN

~LOW

_ _ _ _ _ _ _ _ _ _ _ _ Extent o(

0%

knowledge

•

' .' .., "

,, ,

,, ,

, ,, ,, •

100%

Figure 4.10 HOw detailed should plans be? Some: authors c haracterize n n 'JKilc processes For C'x.lmplc. one practice j, to 311 them "plan ~based ." The- autho~ do not believe ,n a I\lOglc Ch"fiJcteri zatlon like thi~ of non-agile proc~s~C's; hence thc= blankf!'l tenn -non.oglle · I

•

INTEGRATING AGILE WITH NON·AGILE PROCESSES

Benetlts 01 Aglig

Costs 01 Agile

@ Motivates developers

® Hard lor new panlcipants

@ Thoroughly tested. usually

®Sensltive to individuals

@Easler to estimate each cycle

®Hard 10 estimate lull lob

@ Responsive to customer

®Umlls learn size

©Always demonstrable sohware

Figure 4.11 Trade-ofts between agile and non·agile processes

2009, the conventional wisdom concerning the agile/non .agile split is shown roughly in Figure 4. I 2, The larger the job , the more non-agile process is required. Agile processes empha ize code first, whereas non.agile ones advocate coding on ly from well· documented designs and designing o nl y from well·documented requirements. These approaches appear to be almost contradictory, so combining (hem requires substantial ski ll and care . We will co ncentrate on methods for doing this in large jobs, where th e c hallenges are greatest. We will ca ll the two options "oll-agiledrivrn and agile-driu
4.5.1 A Non-Agile-Driven Approach A common non·agile-driven approach is to initiall y approach the job without agility , then fit agile methods Into the process after sufficient work has been done to define the agile ro les and portions. We develop a plan , create a ca rehll high. level design, and decompose the work into portions that can be implemented by teams In the agile manner. One can superimpose upon each agile team a process by whic h the accumulating Percent agile vs. non'agile

t

100%

.,-

C>

,

'c" 0

..

Z

i

I SmaJ/

Large

Job slzo

Figure ' .12 conceptual agJle/non-aglle combination options: some conventional wisdom, circa 2009

75

76

CHAPTER 4 AGILE SOFTWARE PROCESSES

- - - - - - - ; : : : : : - - - - - - -•• rima I

Requirements documentation 4

Design documentation

._--......-

2

... .

Coding and testing

System testing

", .

-

-

--

3

6

• High level Figure 4.13 Integrating agile with non-agile methods, : time line for a single iteration

requirements are gat hered . and placed wit h in a master requirem e nts document. The sa me can be do ne with the accu mulati ng design . Domg thi with design is mo re d ifficult because design parts may actually be replaced a nd mo dified as rd.ctoring takes place. Requirements tend to accu mulate as much as they change. The seque nce of eve nts is as fo ll ows, I. Hi gh . level requi re ments are developed for the first iterat ion .

2. A I" gh .level design is develo ped based o n the h igh .level req uirements. 3. Agile develo pment by tcams begins. based o n these hi gh · level docume nts. 4 . Full require ments documentatio n is ga the red fro m the wo rk do ne by the agile tea ms as it progresses

5. The design documentation i ga thered from the agile teams at regular interva ls to update the design document.

6. System testi ng not covered by the ag il e process is performed at the end . if necessary. 7 . The process is repeated fo r eac h iterallon . This is illustrated for o ne watcrfailiteration in Figure 4 . 13. Figure 4 . 14 shows thiS for multiple iterations.

4.5.2 An Agile-Driven Approach For an agile .driven approach to large jobs. a (small ) agile team can be set to work o n signincant a p«ts of the project until the o utline of an architecture appear. At that point . non ·agile methods are used. This ma invo lve reintegrating agile programming again as described in the no n·agi le ·driven approach above. This has muc h In common with building a prototy pe . H owever. the differe n e IS that the initial work i performed larl!cly to develop an architecture rather than retire flSks . In add itio n. the work I no t planned a throw.away cod e. One agile -drive n approach is shown in Figure 4 . 15 .

SUMMARY

Time

M I L E S T 0 N E S First /teralion' completed X

Product released X

SCHEDULE Iteration number

_.

•

'

1

.

•

d ocumentatlon

---

'- -

oeslgn _

.-

_ _N _

Coding and t estlng

- -.----

•

l'

-

•

"Tf _. - .- -

.

•I

d ocumentallon

3

w_._.

•

Requlrements •

2

--

--

• ..

._._- --t•

-

s ystem testing

,

'-•

--

• ....i.

---t-'

-

--

-,

I 2

I

3

'High level Figure 4.14 Integrating agile with non·agile methods 2: time line for multiple iterations

Initial agile development

I--~

I

I \ /~

Requirements documentation Design documentation

\

f

\

'i

:

I

\ \ \

' ''iL_ _.....J1

Coding and testing (Including agility?) Figure 4.15 An agile-driven approach to large jobs

The case sludy sectio ns fo r Ihis part o f the book (wh ich ap pear in Ch apters 5 and 6) ca n lai n two case studies thaI combine agil e and no n·agile methods.

4.6 SUMMARY Agi le software develo pm e nt was crea ted as an allernative 10 exi ling plan. based approaches thaI were perceived 10 be too process heavy and ngid. A gmu p o f industry ex perts mel in 200 1 to share the. r v. io n fo r an alternative to these types o f pro esses. They crea ted the Agi le Mani fes to to ca pture their Ih ollghls fo r a process th aI wa~ ada p ta ble, lea n, and as d".

77

78

CHAPTER 4 AGILE SOFTWARE PROCESSES

• TI,e need to collaborate close ly wilh cm lomors and other ,takeholders •

omtl'lUniCJIIOI1 over

do umentatlon

• Frequent delivery of workll1!; software

•

elf orga niz II1g reams 4

• TI,e need to embrace and plan for changing requirements Any process that embraces Ihe fundamental values of the ag ile manifesto is considered an agile process. Examples include extreme programmll1g , scrum , and Crys lal. E '\Teme programmIng is ba ed o n four prin iples : communicat Ion . feedback , simphclty, and courage. It promotes practices such a lest-driven development, refactorl ng, pair· programming , collective code owner· ship. continuous integration, and on·sitc customer.

Serum deAnes a framework , o r a loose set of activIties Ihal arc employed by the crum team . At the beginning of a project , a btl klog of work. or requirements, is identified . Deve/opers work on a subset of reqUIrements in the backlog in 30-day Sprill!S . Once a spri nt begins, the team is gIven the freedom to employ any methods deemed necessary to complete their work sucLessfull y. A customer demo occurs al the end of each sprint. A new set of work is defined from the backlog fo r the next spri nt and the cycle continues. Crystal is a fam ily of methodologies that address projects of differe nt size and crit icality . Crystal methods share the following characteristics: frequent delivery, reAective improvement, close communication, personal safety, focus , and easy access to expert users, and a lechn ica l e nvironment with automated teSling, configuration management, and frequent integrati o n. Agile and non· agile process ca n be integrated o n projects in order to gain the advantages of both . The means by which this ca n be performed depend o n severa l factors but particularly on the size of the project. One approach IS to Initiate a job without agility, then incorporate agile methods into the process after enough work has been accomplished in defining agile roles and responsibi lities. Another approach is to initiate a job with an agile approach until the outlines of an architec!l;re appear. At that poinl , non ·agile methods are used_This may involve reintegrating agile programming again as described in the no n.agi le-drive n approach above.

4.7 EXERCISES I. The Agile Manifesto favors working software over exte nsive documentation . Under what circumstances can thi s calise problems if taken to an extre me]

2. . . In your own words, explain how agile processes adapt to and embrace cha nging requirements. b. Describe a scenario in which this mi ght be counterproductive 3. Name three benefit of the XP practice of testi ng oftware from "day one," always having working software available. 4. During the daily IS -minute scrum meeti ng, the leader is only allowed 10 a k the same thlee questions . What two additional questions mig ht you want to ask] For each , explain lIS benefit toward achieving the goals of the meeting. 5. In your own words, explain how Crystal adapts to various types 01 projCCts.

79

I Bcd. Kcee,sed November S. 2009}. 2. HicMlilllh, Jim , -H131ory Agik /\It4_iftsJd," 2001. httpJlwww ~&II~miln.fC:Slo.orglhlsIOry. htmllaccC\scd Novcmha S, 2009] 1 HQJh~nlth. JIm.. ~nd A Cock.bum, -Agile Sortware Dcvclopnlcnt~ 11" Uusjn~s of Innovallon: IEEE C~,..ftr, Vol. 34, No 9, $q>'<mber 2001 , pp. nO-ll2 . • . Cohn. M.rt. -Usn IOn" AppIJ,J For Agik Sol'..." Dno
uality in the Software Process

The Software Development Ute Cycle

•

Whal are the principles of managing quality?

•

How do you plan for "quality?'

•

Whal are inspections and how do you carry them out?

•

How do you carry oul reviews and audits?

•

How do you measure and improve sohware processes?

•

In wi1at way does CMMI assess organizational quality?

•

What does a sohware quality plan look like?

Figure 5.1 The context and learning goals for this chapter

This chapter discusses the manner in which we integrate and manage quality throughout the software development process. ThIS is an integral part of project planning. and it affects every phase of development. As part of planning, documents are produced detailing the quality approach to be taken, including specinc quality goals. techniques 10 be employed, melrics 10 be collected, tc~ts to be run , and t he manner i n which

PRINCIPLES OF MANAGING QUAUTY

• Quail! princIples --
•

uality planning --
• In peetlon -peer processes focused on Quality • Reviews and audits -~extcmal Quality as essment • Defeet manage me nt -identiRcatlon , tracking, and resolution of defec ts • Process improvement

--
Figure 5.2 Quality in the software process

defeets are to be handled. All of these contribute to an effective development process with a focus o n qual ity, result ing in the development of a high .quality oftware product. The integration of Quality in the software process is summarized in Figure 5.2. Each topic mentioned in the figure is described in thi s chapte r.

5.1 PRINCIPLES OF MANAGING QUALITY An overall approach to quality is guided by several principles . The planning and practIces described In thIS chapter are implemented WIth these principles in mind, as follows . F,rst and foremost , quality IS something the entire devel o pment team is responsible for . not ju
I. Focu. c.ontinuously on qualtty .

2 A qualtty assurance proce" must be dcAned 3. The or8aniz~tion must follow its qualIty assuran c process 4 . Ftnd and rcpair defec ts as early in the development pro

Asur. 5.3

Key prlnciPles of manag1ng quality

CS<

a\ po<>lble

81

82

CHAPTER 5 QUALITY IN THE SOFTWARE PROCESS

If defect found . . . Reason (by one estimate):

... soon after creatIon

. . . at IntegratJon time

Hours to .. .. detect •

.. repa ir Total

0.7 to 2

0.2 to 10

0.3 to 1.2

9+

1.0 to 3.2

9.2 to 19+

Figure 5.4 Cost to repair a defect. depending on time elapsed since injection

roo

that developers write tests befo re co d ing, and then write code to pass their test . is discussed in more detai l In C hapter 27 Q ualit y assuran ce (QA ) refers to actions taken to assure that a product under construction attains reqlllred levels o f quali ty . The second and th ird principles listed in Figure 5.3 state that a QA process must be defi ned and fo ll o wed. Thi s IS ho w so much quality has been encouraged by the International Standards O rga nI za tIo n (ISO ) standard 900 I "Quality Systems-Mode l for quality assurance in d esign , develop· ment , productIOn . in talla ll o n, and servici ng." Many compani e have c reated documents describing their offiCIal Q A process. ISO In SIS ts o n the exi stence of such documents for companies seeking its certification. H oweve r, I 0 recog ni zed that a do cumented procedure is only a part of quality assurance. In practice, do um ented quaht y procedures are often ig nored wit h impunIty; hen ce ISO's second principle, which e nsures that empl oyees actua ll y fo llOWIn g qua lity procedures. Quality planning is discussed in mo re detail in Secti o n 5 3. The fourth softw are quality principle listed in Figure 5.4 is to find and fix defects as early as possible: i.e .. to prevent them from persisting for more than a sing le phase . Figure 5,4 provides dara fro m one of the author's clients o n the relative cost o f allo wing a defect to persist. Many organizations have rried to measure the difference in cost. and It is always found to be very large . A rule of thumb sometimes used is that a defcet costIng a do llar to fi nd and repair soon afte r its creation costs a hundred do ll ars to fi nd and repair if del ivered to the customer The main consequence of this principle is that it most often pay to spend significant resources findin g and fi xing defects as earl y as possible rather than allOWing them to remain undetected and active.

,

5.2 MANAGING QUALITY IN AGILE PROCESSES Agile and non ·aglle projects arc equa lly concerned with producing quality products. but agile methods go about this in different ways . In particular, agile response to t he prinCIples of Section 5. 1 are as follows: I Focusing continuously o n quality Agile processes fulfi ll this principle by creat Ing increments from close customer contact , b testIng th¢m during development, and via prearranged customer acceptance tests.

QUALITY PlANNING

2. DcAn.nll a qual.ty as,uran e proces Ag.le proccs rdy On rhe activities jll t listed for a QA pro ('55 , rather than o n documentation ueh as the IEEE ·tand~rd di IIssed in this c hapter \'ifhcther th. .s sufAcient , especially for large projects, remains 3 subje t of debate. 3. follOWing the organization' quality ",surance process Whether or not one doubts the adequacy of agil.ty for quality .n large prOjects, team members arc generall ",dl motlVilted , and they usually follow agreed· upon methods very faithfu ll y. 4. Finding and repairing defects a early in the development proce" as possible

Here, agile methods show their greatest stre ng th , s.nce they are code centric and thus try out implementation and testing of the pieces as soon as II is possible

5.3 QUAUlY PLANNING We begin planning for qualoty early in the development Iofe cycle . Documents arc written that denne an overall approach, including quality goa ls and techniques for every deve lopment phase (the Software Quality Assurance Plan ), how the product will be verified and va lidated (the Software Verincation and Validatoon Plan ), and how testing is planned , specined , and reported (the Software Test Documents ). Th e Software Quality Assurance Plan (SQAP) is desc ribed below, the Software Verification and Validation Plan (SVYP) is described in C hapte r 9, and the Software Test Documents (STD ) arc descri bed In the testing chapters of Part VII .

5.3.1 Software Quality Assurance Plan The Software Quality Assurance Plan (SQAP) specines the overa ll quality plan , policies, and procedures that will be followed by the team It provides guidelines so that quality aClions are nOt an afterthought but something conSCiously and deliberately stnven for and practiced throughout the development proce s. It orients the project toward prevention denning procedures for proactively mo nitorong and improving processes and quality, ensuring that qualoty practices are defi ned and implemented, and ensunng that problems are identified and resolved as early as possib le. T o do this, the QAt> answers the questions posed .n F.gure 5.5 The rest of this section addro<se< these question in turn .

1. Who will be ReSponsible for Quality? An ond.vidual or group is .dent ified as be.ng responsible for as
2, What Quality DocumentatIon Is Generated? The SQAP spec.f.es the docun1~n t s tt) be generated for a prOject and how they ar to be he ked for a ura y Examples of do um~nts are the

o ffw ar

Requirement, . peclOcut.on (

l.

oftwar

Des.!!n Document

13

a.

CHAPTl:R 5 QUAUTY IN THE SOFlWARE PROCESS

I

\xfho wi ll he rc>pon,ible (o r qualhy)

A PC:f"\OI1 , a

O1 anJ~('r. J group, an organiza ti on , etc.

2 ~ hat doc umentalion will be ge nerated to guide developme nt, venRcation and va lidat ion, usc and malOtcOJn (' of the o ftwilrc7 3

~

h at standards will l>e u<ed to e nsure quality)

D ocumentatio n tandards, codlllg tandud , e tc 4. \\'lha t metrics will be used to mo nItor quality) Pro duct and proces, metrics

5. \\'lhat procedures will be used to manage the quality process) Meetings , audi ts , reViews , etc.

6. What kind of testing will be performed) 7. \\'lhat quality as urance techniques will be used) Inspections, proofs of co rrec tness, tests, etc. 8. H ow will defects be handled) Figure 5.5 What's needed from a Quality plan

(SOD), Software VeriRcatlon and Validation Plan (SVVP), User Documentation, and the Sohware Co nRguration Management Plan (SCMP). The SRS deRncs the requirements (or the software, and the SOD describes how the software is designed to meet the requirements. The SRS and requirements are covered in Part IV. The SOD and software design are covered in Part V. The SVVP describes methods used to verify that the requirements speciRed in the SRS are the right set of requirements, that the requirements arc correctly implemented by the SOD , and thai the design in the SOD is correc tl y implemented by the code. VeriRcati o n methods include inspection , analysis, and testing. Inspecti o n is described in detail in Section 5.4 . User documentation describes how the sohwarc shall be successfully and correctly used . It also describes error messages and corrective action to take as a result. The SCMP detai ls how changes to software and documents are managed , and is described in greater detail in Chapter 7.

• I QA person per 3-7 developers • Excludes developer testing counted as developer time • Includes post-developer testing • Ideally performed by external QA per onnel FIgure 5_6 Typical estimate of QA requirements per developer

QUAlITY PlANNING

3. What Standards will be Used to Ensure Quality? Adopting consistent document templates contributes to the production of quali ty documentation. The use of IEEE tandud documents as outlined in this text , for examp le ensures that documents contain all the necessary Content and can be easily rcad and unde rstood by team members. Coding standards dictate such things as variable and module naming , commenti ng, and logic structure. Consistently developed code aids in different team members being able to better understand it and make updates.

4. What Metrics will be Used to Monitor Quality? The SQAP deAnes the quality metrics to be coll ected and ana lyzed. Examples of quality metries ,"c1ude defect den ity, mean time to fa ilure, customer problems, and customer sat isfaction. Metrics are dIScussed in detail in C hapters 3 and 9, among orhers.

5. What Procedures will be Used to Manage the Quality Process? Meetings, audits, and reviews are some of the techniques employed to manage the quality process. They are described in more detail in Secrion 5.5.

6. What Kind of Testing will be Performed? Both the Software Verincati on and Val idation Plan and the Software Test Documents specify the tests to be executed.

7. What Quality Assurance Techniques will be Used? Inspectio ns, proofs of correct ness, rests, and so on are all techn iques used ro assure product quali ty. Secrion 5.4 in particular describes the inspection process in greater derail. Proofs of correc tness and testing are described in this book as well.

8. How will Defects be Handled? As denned in Chapter 2, defects arc devia tio ns from requiremen ts. Procedures for ident ifyi ng and managing them are deAned in the SQAP. Defect management is covered in detail in Section 5.6.

5,3.2 IEEE Quality Documents The IEEE has publ ished several standards related to software qual ity, as fo ll ows, • IEEE 730· 2002: Standard for Software Q uality Assurance Plans • IEEE 10 12· 2004, Standard for Software Ve rincation and Validatio n • IEEE 829· 1998, Standard for Softwa re Test Documentat ion These documents relate to the software developme nt pha es as hown '" Figure 5.7. Figures 5 II and 5.9 summarize the contents of IEEE Standard 730 ·2002 Standard for oftware Qualit Assurance Plans. The case study se tion ncar the end of thl< c hapter con!>ins a ample QAP r r the Encounter Video game.

as

86

CHAPTER S QUAUTY IN THE SOFTWARE PROCESS

Projoct Management

IQ. PIIn 7ID I

"

r-----__.: ,-EXPlains quality policies ,",' ', ....... \ ......... ""

Requirements Analysis

.....---_--, I

I I

~v.v PIIn 1cn2~

t-•

-

Design

Explains verification and validation procedures ......... __

----

,

_.

........

\

' II

Implementallon

.........

-- ---- -1L _

=--_.......J1

li _.... _....: ..

Explains plans, procedunts, and test cases

Figure 5.7 The main IEEE software quality documents

6. Reviews

I. Purpose

2. Referenced documents 3. Management

6.I

Purpose

6 .2

Minimum requirements

3. 1 O rga nization 3 .2

Tasks

3.3 3.4

Responsibilities

QA estimated resources

4 . Documentation

4. I

Purpose

4 .2

Minimum d.ocumentation requirements

4 .3

Other

5. Standards,

practices,

conventions,

and

6. 2 . I

Software speci ficatio ns review

6.2 .2

Architecture design rcvie,,'

6 .2 . 3

Detailed design review

6 .2.4

V&V plan review

6 .2.5

Functional audit

6 .2 .6

Physical audit

6 .2 .7

In -process audits

6 .2 .8

Managerial review

6.2 .9

SCMP review

6 .2 . 10

Post-implementation review

metrics

5. I Purpose 5 .2

o ntent

6.3

7 .- 15. See next figure

Figure S.B IEEE SOftware Quality Assurance Plan table of contents 1 of 2 Sourer. IEEE Sid 730-2002..

Other reviews and audits

INSPECTlONS

7 . T est may rde re n e Softw are Test Documentation.

S. Problem reporting and corrective action

9. Tools, t",chniques, and methodologies may reference SPM P. 10.

Media control

I I.

Supplier control

12 . Records collection , maintenance, and retention 13 . Training 14 .

Risk management may relerence SPMP.

15. Glossary 16. SQAP change procedure and history Figure 5.9 IEEE SOftware Quality Assurance Plan table of contents 2 of 2 Scuce: IEEE Std 7.30-2002.

5.4 INSPECTIONS An i"Sp,elicm is a quality technique that locuses o n review ing the details of a project art ilact (requ irements, designs, code, etc .) in an organized and th orough manner. Inspectio ns arc perlormed pen odi call y duri ng all software e ngineering phases by the artifac t's autho r and by o ther e ngineers. The purpose is to assure the artifact's correctness by seeking delects. A meeting 01 inspectors is held at wh ic h ddects arc ident ified . The repair 01 defect is the author's respo nsibility . The Inspectio n concept was develo ped by Michael Fagan [ I Jwhile he was at IBM He obse rved that the author o f a wo rk IS usuall y able to repair a deiect o nce he recognizes its prese nce. Thus, a process is needed whereby the delec ts in a wo rk arc ca lled to the author's attenti on as ea rly as possi ble. Thi implie that inspections should be a peer process beca use inspec tions arc perfo rmed o n work in process rather than on fin ished product. ince inspectio ns we re o riginally introduced to improve code, the y arc often referred to as ·code inspections," but thei r value has bee n shown 10 bc grea test whe n used earl y in thc process , lo ng be fo re code is produced . They arc used proA tabl y a< soon a~ the firs t project documents are produced. For example, requirements speCIfica tio ns, project management, and configuratIo n rlans should all be inspected.

5.4.1 Inspection Principles GuIding prinCIples lor conducti ng inspectIo ns arc It . ted below. The
17

CHAPITR 5 QUAliTY IN TIlE SOFTWARE PROCESS

I

PCCO' pro eS5

2. pe IRed rob 3 Delcc t dete tio n i" lead of defee l repair 4 U se of heck!'sts

5 Arlif" t readiness 6 . Adequate preparallon 7 . Metrics COllec lio n 8. Time limll

1. Peer Process Inspecli o ns arc co nduc lcd by a group of individual; who are familiar with the artifact under reView They may be software engineers, members of other departments such as softwa re quality assurance, marketing, sales, or cu tomers. The inspec tion is a peer process with an overriding goal of discovering defects The work ,n progress is under inspection , not the performance of the author, and therefore it is not a supervisor· subordinate process. An author is responsible mainly for the product he or she submits aJttr inspection, not before. The work brought 10 the inspection should be the author's best effort, not a draft .

2. Specified Roles Inspections work bcst whcn speCific roles arc assigned to each participant . The moJrralor is responsible for leading the inspection and seeing that it is conducted in a productive and ef~cie nt manner. The moderator schedules the meeting and ensure that it starts and ends on time. with the latter bems accomplished by maintaining an appropriate pace throughout. It is very easy for participant.s to get bogged down in details and to try to solve problems during the meeting. It is the job of the moderator to prevent this from happe ning and to keep Ihe meeling moving along . However, the moderator must 31so ensure that the pace is not 100 fast as to miss defects. When defects are identified, the moderator is responsible for e nsuring that there is consensus from the team . Thu , to be effective a moderator should be: technically competent The modera tor is also an inspector. TI,e job can sometimes involve sensitive issues,

such as having to moderate among hostile participants wilh differing opinions. As de robed by Wiegers, "Moderators hould be trained in how to conduct inspections, including how to keep p3rticipan~ with strong technical ski lls but low socia l skills from killing each other." [2J The a""hor is the person responsib le for the work product itself, and repairs all ddects found (offline). The author is also an inspector, looking for defects along with other inspectors. In order to avoid bias, the author should not serve in any other role. Authors must remain objective throug hout the inspection and not become defensive. This ca n be hard as others arc ~nding "faults" with their work. The record" is responsible for writing down descriptio ns and classifications of th~ defec~ found, and for recording the action items. If the inspection team is very smali, the moderator could also take on this role, but it usually is best to have someone else assume this responsibility . The recorder is also an inspector.

A "aJ" is responsible for leading the team through the work In an appropriate and thorough ",anner. This person selects the most effective sequence for presenting the work product and answer qu~stions ~ by the in
INSPECTIONS

All particIpants on an Inspectio n act as inspecto~, In addition to any other rcsp'onsibil,ties they may have. It i important to invite people who can make a significant contribution and have the expertise to identify defect to the in pection. Examples of people who should attend arc other prOject membe~, those responsible for testing o r maintaining the product, and depending on what artifact is being develo ped, customer and busi ness repre,entatives. Depending on the artifact being inspected, there may be a requirement for specia lized inspectors. For example, a Joc""d ,"spec/or inspects for a specific criterion (e.g., rellabiliry). A sprcial;z,d ;IIspec/or is a specialist in the area covered by the artifact under onspection (e.g., a radar expert for a radar contro l applicatio n).

3. Defect Detection, not Defect Repair Inspections should focus on identifying defects, and specIfically excl ude any discu sion of their repair The repaor process is left to the autho r, and no time should be spent durong inspectio ns even suggesting repai~ . All repair suggestions should be made offline. This is rypically one of the hardest things to control-many partIcIpants love to discuss potential solutions and it is quite easy to fall onto intemlinablc tcchnica l discu sions regarding the best approach. This IS where a strong moderator i essential. It is key to not let this rype of d,scuss,on continue and instead to remind people that the goal of the meeting is to identify defects, not repaor them .

4. Checklists A checklist can be very useful in providing gui dance to inspectors, describing specific areas to pay attention to. Each rype of artIfact such as project plan , requirements peci~cation , design peclncatlon , configuratio n management plan , source code, and so o n should have its own check lost, as each requires dIfferent areas of focus . Example questions to ask when examining a requirement speci fica tIo n mig ht be as follows : Is each requirement verinable by testi ng] Is each requirement uniquely identified] For code inspecti o ns, ques tI ons to ask might be: Are there any variables that are unused or rcdundanols the code adequately commented] Good examples of checkl ists can be found In (3).

5. Artifact Readiness The artifact under review should be in the best sta te of readiness that the author IS capable of. For document there shou ld not be many , if any , sections with "to be determined : Code should compi le cleanly \'(fhen a group of people takes ti me to ide nt ify a defect that the author would have fou nd wi!h reasonable effort , a significa nt amount of time is wasted .

6, Adequate Preparation Inspections are not the sa me as reviews, manage ment overviews, or education sessions Inspectors have to

work. at the same level of detail as the author. (This is what make, inspections time ·consumong and thus expensive.) The artifact under review is distributed several days before the meeting, all owi ng inspectors adequate time to study the maten al, identify defec ts, and prepare questions to ask at the in pectlo n Inspection.aidi ng software can save time by allowing inspectors to enter de criptions of defect they discover while preparing The recorder accesses and ed Its these at inspection meetongs

7. Metrics COllection During inspectIons, metrics arc collected and analyzed Examples of metries to colic t arc a fo ll ows: • Number of defects discovered , by severiry and type • Number of ddcc t ~ dl .covcred by each ca tegory of stakeho lder Inspe ting the artifact

89

90

CHAPll'R 5 QUALITY IN THE SOFlWARE PROCESS

•

umber of del cet< per r~!!e rev Iewed

• Revle

rotc (number of pOHe ho ur )

For , everi ty , a Impl e lo,,,f,ca ll o n su h 0' l' IIIWI , ",,"or, and lev'" ~o n be used For Iy pe , ca tc/jo " es such as 1l11 '3,m g uncti on, Inco rrect JlInctl o n, pcrrorrn ancc , il nd usabil ity an be used Thl ~ class ificat ion tOpIC IS d,sc u,sed In e tl o n 5,6. 1 The me trl , w ll ec te d fro lll in pc li o n, arc analy zed and th e resu lts used lo r seveml purposes First, they arc use d to pred, t th e dnc,e n y of future review If a company h., ", formatIon o n th e rate 01 rev,cw lor a part ,cul ar am /oc t, ,t can u'e th at to predl t ho w lo ng to , hedul e lor a luture review of a SI mIlar art ,/a t e o nd , co untin g the number 01 defec ts discove red dUrin !! each sto ge o f deve lo pment is useful ,n pred,c ting th number 01 defe t, rn hllurt proJectS Even Illo rc spec d, c , o untln!! th e number 01 defects d,scovered by a p,rrhC'lllnrslnkrholdtr «- .g ., marke tIn g , cuSto lller, QA ) is also usefu l. For exam ple, dunn g a req uire me nts revIew lewe r than ex pc ted ddc t are d, scovered by the customer represe ntative , ,t could rnd,ca te e Ither a lack 01 preparation o r 1111 und ers tandrn g 01 requirements by that perso n . In ei ther ca e , this would mise a red Aag and a lollow-up Ill eeti ng WIth the custome r wo uld e n ue to und ersta nd the cause lor the discrepan cy .

.r

8. Time Limit InspectIO ns sho uld not be Illorath o n 'cssions, wh ,c h ca n occur if the mo de rn to r docs not keep th e meeting mov ing along. After a certain am o unl of lime , participants will nOt be as foc used a needed_ Each sesSIon shQuld be kept to a ma xi mum 0 two ho urs, and il it is no t completed by then a follow -up session should be rescheduled

5.4.2 Inspection Process The inspecti o n process loll ows an o rde rl y flow 01 steps, each adhering to th e princi ple described above. The steps are ummanzed in F' gure 5. 10 .

1. PLANNING

- - - .j Overview I }

Non-nominal process

/

_-- - -

2_ PREPARATION .......

--

Nominal process

4. REWORK "- -

-

Causal Analysis

--

5.

Figure 5.10 The parts of the Inspection process, emphasizing the main sequence of actMtles

INSPECTIONS

1. Planning. The process begins w.th planning . Th.s oneludes decidong which inspecrion mttries to collect , identifying tool to be used in recording and analyzing these dara, dec.ding who will part.cipate on in pect.ons and wh"n they w.1I take place, and distributing the materoals s~veral days prior to the meeting . Typically, the moderatOT is re ponsoble for thcse tasks. LA. Overview meeting . If necessary , an overview meeting can be organized to explain the artifact under Inspection. Since meetings are expensive, this should be avoided unless obviously necessary . 2. Preparation . The next step for each inspection con ISts of preparation. Here, in pectors review the work in compl ete detail al their ow n workstallons (e .g., c he king that the code under inspccl.on correctly implements the detailed design ), pos ibly using checklisl provided for guidance Whal makes the .nspection process valuable, but also expenSIve , is the fact that this lime' co nsuming process is performed by several people in complele detail. The process .s not a "review," because inspectors work at the same level of derail as the author In pectors frequenlly enter the defects they And intO a database (e g., Web· accessible) together with descriptions and c1assiAcations. ThIS help to prevent duplo ca tio n, and it minimizes unnecessary meeting time . Some prefer to u e paper to record their defects. and orne conSIder the number of inspec(Qrs who recognize a given defe t to be a useful metric. 3. Inspection meeting. When every participant is prepared , the inspection meetin g takes place . Durong th.s meeting , the participants honor their deSignated roles. Of I>articular importance is (Q not cry and solo, problems that arc raised, but instead to ensure that they are recogn.zed as defects, to record lhem as action items on ly, and to move o n. 4. Rework. Normally , the author is able to repair all defeclS, working alo ne. This.s the rework phase. If the inspection meeting deCides, however, that the defects are so pervasive that a reinspecti o n ' 5 required, then the item is recycled through the process. 4A. Causal analysis . If the defects are due to a mi su nderstandi ng or Widespread mISco nception , It may be necessary to ca ll a separate mecling at which these causes are analyzed and discussed Again , since meetings are expensive, these should not be scheduled casually, 5. Follow-up. Aher the author repairs the defects identified during the inspectio n meet.ng, a brief follow· up meeting is conducted at which the moderatOr and the author con Arm that the defects have Indeed been repaired. This is not intended to bea detailed review by the moderator. Theonus forrepairison the author, who is responsible for the work. If the number of defects repaired is high , a follo\~-up inspection may be required 6. Improve process. Organizations shou ld always analyze the efAcacy of their pro e ses and strive to improve them . For Inspection , the group meets from lime to time to review the inspection process itself, and decides how it can be improved . They exa mine the metric collected, including the Ii t of defec ts , and decide how the development process can be improved to reduce and/or prevent the same types of defectS in the future . Fi8ure 5. 1 I shows the average relative times for each inspection process step, u cd as reference data b one of the .uthor's c1.ents The Inspec ti o n meeting t.me in Figure 5. 1 I is shown as o ne hour for the sake of reference Ind ividual compan.es or developme nt 8roups record .n'pection times and quanti lies in pected, and lhey e tllnatt' future inspections based o n these historical data . The IIme< ,hown in Figure 5. 1 I may d.sturb the uninitlaled , wh may wonder whether it rea lly does take that Io n!! to check code. Producong profe Slonal.qualoty produ t ~s .ndeed lake a substantial 'mounl of time, and a~y fa. lure 10 recog n.ze lhe true co t end. lip o n,um.ng f.r more t.me in the end , Inspect. on, have bee n esti mated by .chan. and Mc e un k [4 J to o n'Ulne a, onu h is 10· 15 percent of the development budgel.

91

92

CHAPT£R 5 QUALITY IN THE SOFTWARE PROCESS

Rewor\( Analysis

One company's estimates 1 hr x (1 person) 1 hr x (3- 5 people) 1 hr x (2-4 people) 1 hr x (3-5 people) 1 hr x (1 person) 1 Ilr x (3-5 people)

Total:

7-21 person-hours

Planning Overview Preparation Inspection meeting

Figure 5.11 Inspection time/costs per 100 non-commented lines of code Inspecti on are expensive because they co n urn e the time of everal e nginee rs. Nevertheless, various s tudle (fo r example, [ I ]) have h own that they payoff handsomely. This is due to the astronomical cost of detecllng and repairing defects undiscovered untd cia e to delivery time. Quantified benefits of ,"spcctlOns from sour es uch as IB M , ICL, and Standard Bank , for example, are summarized in [5 ]. Appc ndi x D of the case stud y sh ows an example of a form for reporting t he results of an inspection .

5.5 QA REVIEWS AND AUDITS The QA organizallon works wi th th e project leadership to defi ne the manner in w h ich external quality assessment will be perfonned , specifies this in th e SQAP, and execute it during the course of the proj~.ct . External QA activities are either rrol(WS (sometimes called walk-throughs ), which are scheduled in advanc~ , or a"dllS, which are not so scheduled_ A project can expect both types of activities. Figures 5 . 12 and 5 . 13 show th~ range of options for QA involvement in reviews and audits, starting fro m the most invasive to the least.

• Participate In a ll meet ings Including fonna ll ve sessions and inspections. • Review all documents Participate in a ll inspec tio ns (but d o not attend all meetings ). • Attend final reviews and revie,,, all completed documents • Review sci en completed documents But do not participate ot herwise. Figure 5.12 Options for QA reviews

• Audit at unrestricted random times Includes visiting with e ngineers . Includes inspecting any document at any time. • Audit random meetings • Aud it ra nd om ly from a speCified list of meetings • Audit wit h notice • No audi ting Figure 5.13 Options for QA audits

DEFECT MANAGEMENT

Benofits of Frequent Intervention

Costs 01 Frequent Intervention

© Helps in aSSessing prOject

®Time needed to get

status

documents ready

© May help to improve process

® Engineer time taken to explain

or project

® OAtime

Figure 5.14 Comparing frequent VS. occasional QA intervention Frequ~nt intervention by QA has the advantage of provIdin g QA personnel with greatly improved

understanding of the health of the project. but it may disrupt the project by frequently calling for documents or for engineers' time. This trade·off is summarized in Figure 5. 14.

5.6 DEFECT MANAGEMENT Projects encourage the submission of defect repOrlS by all team members. Usually, a screening process that ~nsures def~ct reports are valid and accurate is put in place . To manage defects, QA standardizes on the manner in which defects are defi ned and tracked . These data can then be compared between different projects so that estimates can be made rega rding new projects . We explain this standardization next.

5.6.1 Classifying Defects Teams classify each defect by its stv"ily (how serious it is), priority (i ndicati ng when it will be handled), It s type ( th~ kmd of problem ) and its soure< (the phase during which it was injected). These classification arc illustrated in Figure 5. 15.

• Severity

How serious is the defect? • Priority

?•

In which order will defects be repaired?

? "

~

- - --

• Type What kind of problem is involved?

L" '"

• Source

During which phase

1

was it injected?

1""'- 1 fl&ure 5.15 Defect classification

93

9.

CHAP I ER S QUAUTY IN THE SOFlWARE PROCESS

No more than two decl,tona ar. required.

Defec, Hverlty 10 m%r

el.

"I v

Defeel severity Is 'rlv'.'

else 2

V Classify as "medium"

Clasally a. "major"

Clasally a. "1r/vl.,"

Figure S.16 The triage decision metl10d applied to defect severity classification

A Si ngle severity classlncation scheme can be used for all artifacts. It is possible 10 be very discriminating among levels of severity, but this consumes time. The results should be worth the time. One of the authors has frequently e ncountered teams using diSCriminating classincation schemes that consume significant decision · making time and yet the data that they produce are not utilized by the organization . Deciding the severity level of a defect fa lls into can sometimes be difficult. Triage is a useful and simple decision -making technique when confronted with a large number of possibilities, a situation occurri ng often in software engineeri ng. Utdl zi ng triage for defect classincation has the advantage of being fast to perform because eaeh classification requires answering just one or two questions as shown in Figure 5. 16. Once a list of defects develops, the team approaches the major ones first (they can be placed in order with the ' major' category if necessary). Once they have becn attended to, the medium severity defects can be handled. The team gelS to the trivial o nes o nly after this, if time allows. A simple way to classify the severity of defects when using triage is shown in Figure 5. 17. Although triage is fast, the three·category classincation lumps together all defects that fail requirements, whether serious o r not. Thus, "name neld is not purple, as required" and "system crashes every minute' Ca "shows lopper" si nce its effects are catastrophic for the applicatio n) are given the sa me severity, which is rather extreme. Shows toppers usually need to be separa ted . To address this, the IEEE has deAned a more refined classification of defect severity as shown in Figure 5. 18. The "None" category is added to collect unprioritized defects.

• Major

Causes a requirement to be unsatisfied. • Medium Neither major nor Irioial. • Trivial Defect doesn't affect opera tion or maintenance. Figure 5.17 Classifying defect severity by triage

DEFECT MANAGEMENT

• Urgent Failure causes system crash , unrecoverable data loss, or jeopardizes personnel. • High Causes impairment of critical system functions, and no workaround solution exists. • Medium Causes impairment of critical system functions, though a workaround solution docs ex.ist.

• Low Causes inconvenience or annoyance.

• None None of the above.

Figure 5.18 IEEE 1044.1 Severity classification A defect's Priority is the order in which the team plans to address .t. This is somewhat aligned with the defect's severity but is not identical. For example, a defect can be classified as "urge nt" but it may not be necessary to repair it immediately. For the sake of project effiCiency, fo r example , its repair may be batched with a set of repairs to the same part of the product. Different phases use different defect type classificatioll' . For example. a defect in the requirements may concern ambiguity but "ambiguity" docs not apply very well to code. On the other hand, code may have a logic defect but "logic" does no t apply to requirements in the same way. Some types of defects an common to all artifacts, as listed in Figure 5. 19. The 'OUret of a defect is the phase in which it was introduced (or '''jecred ). For example, you ma y d iscover while testing a video store application that it does not-but should-accept the video /(, A Mad. Mad. Mad, Mad World because the requirements document stated that no word rn a title should be repeated more than once (supposedly to prevent bad data entry). Even though the defect may have been discovered during the testing phase, its ,ourer phase was requirements analysis.

5.6.2 Tracking Defects Table 5. 1 shows a typical way to track known defect.s . The information is u.s ed to manage ongoing work and to record defect history for postmortem and estimation purpos~s . • Omission Something is missi ng.

• Unnecessary The part in questio n can be omitted . • Nonconformance with standards • Inconsistency

The pan in question contradicts other part(s). • UnciassiRed None 01 the above. figure 5.19

Common defect types across all artifacts

95

96

CHAPTER 5 QUAUTY IN THE SOFlWARE PROCESS

Man bug. tracking program, a.,<: indispensable 111 tra king "nd managing defects. Bugzil/a i< an cxample of an o pen , o uree defect·tracking sy
5.7 PROCESS IMPROVEMENT AND PROCESS METRICS Even a very good process has to adapt to changes such as new technology and new kinds of requirements. For these reasons, very effective software development organizations include a mtla·proass with every software process: a process for improving the process itself. This usually takes the form of meetings at the end of phases to review the effectiveness of the process used with a view to improving it for furure projects. A meta·process is outlined in Figure 5.20. To measure the dfectiveness of a process, an organization has to use it for several projects and then compare the project metrics. Table 5.2 gives an example. These results suggest that process U is the most effective, since it produces the best results in every category. Process V is the worst for the opposite reasons. Matters are not often so simple, however. For example, suppose that we had to choose between Waterfall and "Waterfall + Incremental." The latter process is superior in defect count, developer cost, and customer satisfaction, but it scores worse in the other categories. Making the call depends on the relative importance of the factors to the organization . Figure 5.21 lists a sequence of actions that can be taken throughout the life of a project in order to continually improve the process. Figure 5.22 is an example of the kind of data that can be collected about the process. It is applied to the process of collecting detailed requirements, which is covered in Part IV , but the table is applicable to most phases. The numbers are illustrative only, and should not be regarded as industry standards. A comparison with the organization's normative (typical ) data reveals deAciencies in the team's meeting process and in their individual execution (i .e., the actual writing process). This exposes problems in meetmgs . for example, which were subjectivc:1y evaluated 2 out of 10 by the team . It was determined (though not visible in the data) that the meeting process would improve if the straw man proposal brought to the meeting was more complete i.e. an explicit proposal that can be used as a basis for discussion . The other problem observed in the example shown In Figure 5.22 seems to occur during the execution step, where the actual work of writing the requirements is performed . The defect rate is higher than normal (5 versus 3) and the self·assessed quality is a little below average (4). Comp.red with company norms, there appears to be room to spend more time executing the work (i.e ., as individuals ), thereby redUcing the defect count and improving the subjective self·assessment. You can observe from this process that a tandard for counting the parts of the phase is fundamental to our ability to measure it. In this case, we are counl1ng "detailed reqUirements," a concept that will be explained in Chapter 4. Even in the absence of historical data , the team predicts what the values of the metrics should and will be. With these advance predictions, teams tend to work better, and they tend to remember results. ll>e dat.. collected become the basis for furure historical darn. Man.ging all of this is not technically d.ffkult, but it Ns

Table 5.1 A typical way to track known defects Defect Tracking NO. 1

Name

Description

Checkout flicker

Checkout screen 4 nickers when old DVDs are checked out by hitting the Checkout button.

Discovering engineer

Responsible engineer

Date opened

Kent Bain

Fannie Croft

1/4/04

April Breen

1/4/06

Source

Severity

Type

Integration

Med

GUI

Being worked; begun V1 0/04

Requirements

High

Math

Not worked yet

Status

-t Bad fine

2

• •

• •

•

•

•

• •

•

•

• •

• •

• • •

Fine not correct for first·nun DVDs checked out for 2 weeks, as displayed on screen 7. • •

•

•

• •

• •

•

Fannie Croft

•

•

•

• •

•

• •

• • •

•

• • •

• • •

•

•

• •

•

•

• • •

•

•

•

• • •

• •

•

• •

•

• • •

• • •

•

•

• • •

•

•

• •

Tested with suite 9023

m

l:l

-

•

Resolved •

~ •

• •

•

•

•

• •

•

•

:s

91

CHAPTER 5 QUALITY IN THE SOFTWARE PROCESS

QVlpul

Inpul

Prac1lces to discard

Metrlc data on multiple projects using the process

Pract ices to retain Practices to Introduce

Figure 5.20 The process improvement meta-process to be d o ne at th e sam e ti m e as many oth er urge nt ac t ivities. For t h is reaso n, t h e assignment of cl ear respo nsib i lities and th e regular revie w o f th e m etric data are wor ked o ut at th is ea rl y sl age i n th e process. As you wi ll see in the ne xt sectio n , process impro vemen t fee dback se parates g rea t dev el o pm ent o rg ani zations fro m m erel y good o nes.

Table 5.2 Data from multiple projects used to compare processes

Waterfall

Waterfall + Incremental

Process U

Process V

1.3

0.9

0.7

2.1

Development cost per detailed requ irement

51 20

5100

58S

S135

Developer salisfaC1ion index (1 to 10 ; best)

4

3

4

3

Customer satisfaction index (1 to 10 ; best)

4

6

6

2

Cost per maintenance request

S130

5140

59S

5165

Variance in schedule on each phase :

+20%

+70%

- 10%

+80%

+20%

+65%

- 5%

. 66%

23%

51 %

66%

Process -" Average over 10 projects: Major defects identified w ithin first 3 months per 1000SLOC in delivered product

•

00 aC1ual duration - projected duration projected duration 1 x Variance in cost : 100 x aC1ual cost - projected cost projected cost

Design fraction : lolal dtSig . limt lotal progralflm i.g timt Humphrey: Should be at least 50%.

PROCESS IMPROVEMENT AND PROCESS MEI RICS

I . Identify and define metrics tcam will use by phase

Includt- . . tim~ spent o n research, execution, and review · . size (e.g ., lines of code) · .. number o f defects detected per un it (e .g., lines of code) include Source · .. quali ty self-assessment of each o n scale of 1- 10 main lOi n bell -shaped di stribution 2. Document t hese In the SQAP.

3. Accumulate hi to rica I data by phase. 4. Decide whe re (he metTic data will be placed . As the project progTesses SQAP) SPMP) AppendIX? 5. Desig nate engineers (0 manage collectio n by phase . QA leader or phase leaders (e.g., design leader) 6. Schedule reviews of data for lesso ns learned . Specify whe n and how to feed back improvement. Figure 5.21 A process for gathering process metrics

Requirements Document 200 detailed requirements

Meeting

Research

Execution

Personal Review

0.5 x 4

4

5

3

6

% of total time

10%

20%

25%

15%

30%

% of total time: norm for the organization

15%

15%

30%

15%

25%

2

-

8

5

-

4

-

6

Defects per 100

N/A

N/A

N/A

5

per 100: organization norm

NIA

NlA

NlA

3

4

Hours spent per detailed requirement

0.01

0.02

0 .025

0.015

0.03

Hours spent per detailed requirement; organization norm

0.02

0.02

0.04

0.01

0.03

Hours spent

Self-assessed quality 1- 10

Process Improvement summary

Improve st. awman brought to meeting

Spend 10% more time executing

productivity: 200/22 = 9.9 detailed requirements per hour

Figure 5.22 COllecting project metrics for phases

Inspection

99

100

CHAPTER 5 QUALITY IN THE SOFTWARE PROCESS

5.8 ORGANIZATION-LEVEL QUALITY AND THE CMMI · o/tWJ'" development orga ni za tio ns pcrlCldKally as,e S and upgrade their overa ll capabi llly . ln the 1980sthe nonproht o ftwa ..: Engineeri ng Institute ( EI) establl
5.8.1 Level 1 : Initial The "In itial" CMM I level is the mos t primitive status that a so ftware o rganization can have. Organizations at level I ca n be sai d o nl y to be capable o f pro dUCin g software (i .e ., "someth ing") . The o rga nization has no recognized process for software pro duction . and th e quality of products and projects depends entirely on the indi vidual s pe rfo rm ing th e design a nd implementation . T ea ms de pend o n metho ds prOVided by membe rs of the gro up w h o take initiative o n the process to be fo ll owed. Fro m project to project, these could be very good o r very poor. The success of o ne projec t has little relatio n to the success of another unless they are sim ilar and e mploy the sa me so ftware engineers. W h en a project is completed, noth ing is kno wn o r reco rded abo ut its cost, schedule, o r qua lity. Ne w projects are as uncertain of success as past o nes . For rn a t organi za ti ons, th is is unacceptable.

IncreaSing maturity

•

LevelS OPTlMIZfNQ

'r

Level 4 QU4NTTTAnvUY MAHAOEO

Level 3 DEfINED

,

Level 2 MANAGED

Level 1 INITIAL

Figure 5.23 CMMI model for organization with staged processes

ORGANIZATlON·lfVEl QUAlITY AND THE CMMI

Table 5.3 SEI specifications of capabilities required for each level (see [7J for a full description) level. Title. and Summary

Expected Outcome

Characteristics

Undefined; ad hoc

Unpredictable; depends entirely on team individuals

Organizations often produce products, but they are freQuently over budget and miss their schedules.

2. MANAGED

Preceding level plus:

Measurement and control

Project outcomes are qualitatively predictable

3. DEANED

Preceding level plus:

Processes standardized

Projects consistent across the organization; qualitatively predictable

4.QUANTITATIVElY MANAGED

Preceding level plus:

Processes measured

Metrics available on process; quantitatively predictable

5. OPTIMIZING

Preceding level plus:

Improvement meta·process

Processes improved and adapted using process metrics

1.INITIAl.

Respect organizational policies Follow established plans Provide adeQuate resources EStablish responsibility and authority Provide training Establish configuration management Monitor and control: Take corrective action • • Evaluate process and product relatIVe to plans: address deviations

EStablish process objectives Ensure process Objectives met Establish orderly tailoring Describe processes rigorously Be proactive

set quantitative goals for key subprocesses Control key subprocesses with statistical techniques Identify and remedy variants

Establish quantitative process improvement objectives Identify and implement innovative process Improvements Identify and implement Incremental process improvements Evaluate process improvements against quantitative objectives

101

102

CHAPTER 5 QUALITY IN THE SOFlWARE PROCESS

5.8 .2 level 2: Managed 11,c "Managed" MM I level applies to o rga ni zatio n, apab le of trackin g projec ts as they unfold Such organizations make plans, manage co nfiguratio ns, and maintain records of project costs and schedules They al 0 descnbe the functionality of ea h produ t in writing. It i. therefore pOSS ible to predict the cost and sch edule of very si mil ar projects pcrfonllcd by a very Similar team . Although level 2 orga ni za tions track projec ts, no tandard development process for the o rga nizat ion is 8ll arantced.

5.8.3 level 3: Defined The "Defined" CMM I level applies to o rga ni zations that do ument and enforce a standard process. Suc h a process I typica lly o ne of those described in the previous c hap te rs (waterfall, spiral , etc.). Some o rganiza · tio ns adopt existi ng sta ndards suc h as IEEE's, while o thers de fi ne their own . Ro ug hl y speakin g, as long as manageme nt enforces coordi nated , professional standards, and e ngi neers imple me nt them unifOnll!y, the orga nization is at level 3. Training is typically required for an o rganization to reach level 3. Teams are allowed Aexibility to tai lo r the o rga nizatio n's sta ndards fo r speCia l c ircumstances. Level 3 includes o rga niza tion-wide standards for project manageme nt, complete configuratio n ma nageme nt, inspections, design notation, and testing. Level 3 o rga nizatio ns lack ge neral predictive capabi lity. They arc able to make predictions only for projects that arc very si milar to o nes perf'Onlled in the past.

5.8.4 level 4: Quantitatively Managed The "Qua ntitatively Managed" CMM Ilevei applies to o rga nizati o ns that can predict the cost and schedule of jobs. A commo n way to do this is to usc statistical techniques and hi storical data. Such an organization c1assilles jobs and their compo ne nts; it measures and reco rds the cost and time to design and implement these; the n it uses these me tric data to predict the cost and schedule of subseque nt jobs. As Humphrey has pninted out, this is no t "rocket science," but it does require a significa nt amou nt of orga ni zation , as well as an ability to analyze the data . Level 4 requires a complete, metric·oriente d quality plan . Even though level 4 is a hi gh level o f capability, it is no t the highest. Software engineering c hanges rapidly. Forexample, the object-oriented paradigm made rapid inroads in the 1990s, reuse and new component concepts are having a growi ng impact. Future improvements and paradigms are unp",dictable. Thus, the ca pabilities of. level 4 orga ni zatio n that does not adapt and Improve may actuall y decline over time.

5,8.5 levelS: Optimizing Rather than trying to predict future c hanges, it is preferable to institute pem1ane nt proe,JurtS fo r ""king and exploiting new and improved meth ods and tools. Level 5 organizations, at the · Opti mizing" CMMI level build in prace 5 improveme nt. In other words, their process (actually a meta -process) includes a systematic way of evaluatin g the o rb'
5.8.6 Relationship of the CMMI to the PSP, TSP As we have seen, the C MMI is a measure of ca pability at the orga nizationa Vcorporatc level Wall~ Humphn: and the Software Engtnceri ng Institute have also deA ned coord inated proce<s models a t the learn levcl.nd at

CASE STUDY: SOFTWARE QUAlITY ASSURANCE PlAN FOR

the indiv.dual engineer level. These are called the Tea .. Softwa,. Process (TSP) and the PtrSO,,,t/ SoftlDa" Procn, (PSP), respectivciy. The PSP, TSP, and CMMI frameworks fonn a relatively coordinated set of capabilities and procedures at the indiVidual, team, and organizational levels, respectively. We will describe the TSP in the project management chapters and the PSP in the implementation chapters.

5.8.7 Relationship of the CMMI to Agile Methods CMMI appears to be almost contradictory to agility because it is process heavy . However, CMMI and agility are at different levels. CMMI is used to assess the capability of organizations as a whole to produce good applications. Those that use agi le methods are just as interested in such an assessment as those that are not, and it is reasonable to assume that CMMI will evolve to assess devc10pment organizations of all kinds.

5.9 CASE StUDY: SOFTWARE QUALITY ASSURANCE PLAN FOR ENCOUNTER The Software Quality Assurance Plan (SQAP ) for Encounter is based on IEEE Sid 730-2002 Slandard for Soflware Qua[ilyAs,uran« Plan,. The table of contents was outlined in Figures 5.8 and 5.9.

ENCOUNTER SOFTWARE QUALITY ASSURANCE PLAN

Th aulbor i, indebled

bi, ,'udenls for inspeclion, of Ibi, do"" ..enl and for Iheir improv""o.,, 10 Ih, original. 10

Note to the Student, Organizations usually have a standard quality assurance procedure. The SQAP for each project relics on this and provides projectspecific QA plans. We will effectively combine two such documents here.

The table o f contents of this SQAP follows that of IEEE standard 730·2002 in most esse ntial s.

Revision History

This assumes the existence of a method whereby revision numbers of documents are assigned.

Version I 1.0.0 E. Braude, created 1/ 17/99 1. 1.0 R. Bostwick, reviewed 5/ 30/99, added substance to Sections 7 through cnd I . I . I E. Braude, integra ted and revised contents

5/ 31 /99 Approvals,

Title

Engineering Manager

Version 2

~ :1.1-0

2.0.0 E. Braude, significant edits of Section 5.2 1/ 18/04

6115104

20. 1 E. Braude, edits 1/23/04 2. 1.0 E. Braude, edits in many sections rc pond ing to reviews by student 6/ 17/04

QAManager

£WiWv..

6111104

Project Manager

a. !J'Cuil1

617104

Author

£"1KauiU

611104

Table of Co ntents I . Purpose 2. Rcferen cd Do lIments

103

10.

CHAPTER 5

3

QUAUTY IN THE SOFTWARE PROCfSS

M~l1 all~ m e nt

1

fRanl 2oltion

2 Ta
3. Re,ponsibiliticS 3.4 QA Estimated Rc,ources

Typically, mD't of the conten t of a SQAP are common to all of the o rganization's proJCClt. EngOlleers would need SImply to taIlor pans 10 the projec t in question.

4. Documenlation 4 . I Purpose

4.2 Minimum documentation requirements 4.3 O ther 5 . Standards 5. 1 Purpo e 5.2 Conte nt

6 . Reviews

1. purpose This docu me nt des ribes the means by wh,ch the Encounter project will produce and maintain a h,gh. quality product. It is also tnte nded to describe mech · anisms for improving the quality assurance process itse lf. "Q uality" is d~fi n ed as the degree to which the applicatio n satisfies its requ ireme nts.

6 . 1 Purpose 6 .2 Minimum req uirem e nts

6.3 O ther reviews and audits 7 . Test 7. 1 7 .2 7 .3 7.4

Unit Test Integration T est System Test User Acceptance Test

There is no separate "scope" s~tion in the IEEE standard, so we have insened it bere. "Scope" contains vital information sucb as whether this document appli~ to the first rdease only or to maintenance as well.

8. Pro blem Re porting and Corrective Adion

The scope of this document compnses the artifacts of all releases.

9 . T ools, Tec hniques, and Methodo logy

2. Referenced Documents

10. Media Control

See Section 4.2.

I I . Supplier Control

12. Reco rds Collection, Maintenance, and Retention

3. Management

13. Training

3.1 Organization

14. Risk Management

15. Glossary

16. Sqap C hange Procedure and History Appendix A - Metric History for this Project Appendix B - Problem Reporting Form Appendix C - Change Reporting Form Appendix D - Inspection Meeting Report Form Appendix E - Document Baselining Checklist

State the rol~ that are involved in ensurina quality. Actual nam~ are provided in Section 3.3. The process described in tbis case is a ..... of internal and exte"",1 quality as,unnce.

This section assumes the description of the organizational Slructur<: of the Encounter project in 4.2 of th~ SPMP. This document will r<:fer to the quality work of d~velopers as "internal : In addition, for the Arst three iterations of Encounter, a quality assurance enaine"r

CASE STUDY; SOFTWARE QUAUTY ASSURANCE PLAN FOR ENCOUNTER

will be designated who will be responsible to the manager of QA. The QA leader will take the lead for project-wide quality Issues QA tasks will be referred to 3S "" temal :

• Carryi ng out the reviews and inspections spcciAed rn Section 6 of this document

3.2 Tasks

3.3 Responsibilities

Summarize what needs to be done.

External QA tasks shall include, for all iterations: " Maintaining this document • Documenting the quality of the evolving product and associated artifacts • Managing external review meetings

• Ensunng that veriAcation takes place and logging verification • Preparing for and attending all inspections • Post·unit testing Documentation

as

per the Software T cst

• Engaging in activities designed to improve the quality assurance process itself • Keeping the project leader apprised of QA prog· ress through weekJy written reports " Carrying o ut the audits speciAed in Section 6 of this document • Providing the development team with feedback from QA's activities • Assign defect repair to softwa re engineers • Identifying methods and tools for collecting and maintaining melrics

Internal QA tasks sha ll include, for all iterations: • Each team member responsrble for the quality of hr~ or her work , as deRned rn this document • Marntaining an issue datahase • Collec trng the metrics desill natc by thr~ and other project documents

• Unit lesting as per eCI manual 023 .2

State what roles will fulfill what job functions .

It is the quality assurance leader's responsibility to see to it that the tasks in Section 3.2 are performed and to ensure that the prescri ptron s in this document are followed , including scheduling the reviews spec· ified. For the first three iteratio ns, the QA leader will perfo rm all of the quality control (QC) functions . For subsequent iteratio ns , the QC team , appointed by the QA department manager, will take over this function . The quality leade r and the QC team are responsible for all non ·unit testing. (See Part VII of the book for background informatron on these types of tests). A description of the QC team will be supplied. The project leader will be respo nsible fo r ensuring that inspections and unit tests are per-

formed . The schedules are to be placed in the SPMP.

No names are assigned to these roles here because they are in the Software Project Management Plan, which is their proper place. Duplicating a name here would require us to update more than one document when there are changes. The leaders de ignated in the SPMP are re o spo nsible for the quality of th eir respective areas (requirements, design, etc .). They shall e nsure that the designated metrics are collec ted and that the quality self·asse sments as outlined in cction 5.2 of thi document Me onducted. Each member of the Encounter development team is responsrble for quality as spc iAed In ce tr o n 4.5 of the company document ' ual it resp n~ibrlr · tres of engi neers at I." Thrs in ludes teSlIng rndividual method, and ornbrnatr o ns of methods in a las. ("unrt testinR') .

105

106

CHAPTER 5

QUAUTY IN THE SOFTWARE PROCESS

• oftwa rc Vc ri flcallon and Val idallon Plan (SVVP)

3.4 QA Estimated Resources 11,,, e,nmated n ',our es reqUired fo r ter are as fo llows, •

A un Encoun ·

ne engineer working halftime for the Arst tI",d of the proje t

• One engi neer work inS fu ll time for the ccond th ird of the project • One engi nter work ing full time for the last third of the project • An additional engi neer working half tllne for the last third of the prOJec t

VenAc.tlo n and Validation Report ( VVR) (No/t Th " book does nOt cover the VVR )

• oftwarc

• Maintenance Plan In addit io n to the<e documents, the Java
4.3 Other - i ntenti onally left blank

4. Documentation 4.1 Purpose The purpose of this sectio n is to ident ify the docu · mentallon that wi ll be used to ensure quality.

4.2 Minimum Documentation Requirements

This ection lists all of the project documen· tation , since the documentation is a major

factor ensuring the quality of the product. Note that the User's Manual is excluded, it is a deliverable rather than a project document . The following documents wi ll be produced , • Software Quality Assurance Plan (SQAP; this document) • Software Configuration Management Plan (SCMP) • Software Project Managcment Plan (SPMP) • Sof·tware Requirement Specifications (SRS) • Sohware Design Document (SDD ) • Software T est Documentation and the tcst doeu· ment that It refers to (STD )

It is customary to make a comment like this SO that no one wastes time looking for what may be missi ng.

5. Standards, Practices, Conventions, and Metrics 5.1 Purpose Th is sec tion describes the standards, practices , con· ventio ns, and metrics to be used for the Encounter project. These are intendcd not only to ensure qua lity of the Encounter product but also to obtalll qua ntitative metric data on the SQA process itself. These data arc to be used to help el evate the CM 11 level of Caming Consolidated Industries (CC I) fr.om level 2 to level 3.

5.2 Content Describe the standards, practices, con~n tions, and metrics to be used. Organintionwide quality goals can be supplied here or in a separate appendix . Thc contents of this S(Ction should be a speCific as possible, For example , sta tcments such as ' quality should be a< hlllh as po<slblc· should be avoided.

CII.SE STUDY: SOFTWARE QUAUTY ASSURANCE PLAN FOR ENCOUN IEft

Standards:

An oj EjjrcliJ}f Comm"HlcalioHby Justin Zobel (Springer

The IEEE documentation standards as of July I , 2004, w,th appropnate modiAcations. are to be u ed for all documentation . The standards for Jav. ndoc commentlOg will be fol!owed as found at http]/ j."• .sun.com!j2 e!javadoclwriti ngdoccommentsl mdex.hmll and http}/java.sun .comlj2se!javadod writingapi pecslindex .hrm L Documentation stan. dards or templates developed by the company may supersede these at the discretion of management. Uni fled Modeling Language standards, as spec. iAed in ... shall be used in th is project . Refer to the Co nve nt ions section below for additional standards.

Practices: I . Because delaying qualiry is expensive, GCI Inc .

strong ly precepts thought. "internal

encourages engineers to apply quality while working, rather than as an after· This is referred to in the company as qualiry." It includes all unit testing.

2. GCI lnc.'s policy is that the QA department provides independent, external testing. The QA department at GCI also has a role in educat ing engineers in the practice of internal quality and working with project mangers to ensure that it takes place . 3. All project artifacts are inspected and are made easily avail.ble to the tea m o nce released by the developer. 4. All project artifacts are placed under conflgura .

tion management, where the co ntents can be ~en by anyone in the team at any time ( ee the Software ConAguration Management Plan for details). 5. The development process i< to be reviewed at least once for improvement, and the written results forwarded to the software engineering laboratory (see Section 6.2. 10).

Verlag. TI,e codi ng conventions as lound at http}/java. sU I1 .comldocslcodeconvlhtmVCodeConvenlions.doc .html will be followed .

Metrics: This section is liable 10 be extensive. The numbers used here would be based on histori· cal data obtained from the group that is devel· oping Encounter. GCI's li st of standard metrics, found at http:// xxx, sho uld be gathered as speCified there. The following includes some of them . For every process and document, metrics shall include the following , I . Time spe nt by individual s on preparation and .

revIew .

2. Number of defects per unit (e .g .. lines of code), classified per Section 8 of this document. 3. Quality se lf·assess me nt 01 the QA process and performance on a sca le of 1 through 10, ap· proximately in a bell·shaped distribution; se ll· assessment scores wi II not be used fo r the evaluation of personnel by manage ment; failure to produce them, however. may negativel y af· fect the evaluatio n of an engi neer by manage· ment, however.

We would specify all metrics to be collected on this project. Possible metrics are described in Chapter 6.

The standard for defect classification is given '" cctio n 8 of this document.

Quality Goals: Conventions: Where fellSiblc , wrlt,ng wnve nt Jon& hauld conform to the suggestions In Wri'IH9 for (omp""r cin,a Tb,

G I quality goa ls for delivered products nre as follows, measured in tenn of defc ts detected within two month< of delivery .

107

108

CHAPTER 5 QUALITY IN THE SOFTWARE PROCESS

•

known " rili al" or \ enous" defects rcmalll III ,lI\

delivered artifa t

In additIon . • Reql1lT1:mcnts. No morc than one "medium ," and

no more than three "trivIal " defectIve detailed requirements per 100 • Design : No mo re than o ne "mcdlllm" defect pcr nve diagrams. A "dtagram" is any Agure that uses about a page of easily legible parts

one responSIble Lu,tom 'r representative. They w,1I be led by the requtrement, leader, who WIll deter. mine their frequency and scope

6.2.1A software Requirements Inspections After they have been revIewed, all requ irement, will be inspe ted in ac o rdance with GCI , Inc 's document G I 345678 "Inspections and Review procedures at GCI." Requtrements sections must be completed and sig ned within a week of beginning the desig n

• P eudocodo No more than two "medium" defects per 1000 lines pseudocode is described

In

C hapter 19.

6.2.2 Architecture Design Reviews

The data from thIS project are to be reported as Appendix 1 to this document.

Th,s I a review of alternative architectures with the entire team . The review will be led by the design leader in accordance with GCI 345678 on a freque ncy to be determined . The team will provide feedback , which will be reAected in the final design.

6. Reviews and Audits

6.2.2A Architecture Design Inspections

• Code: No more than two "medium" defects per KLoC ( 1000 lines of non ·commented code)

6.1 Purpose The purpose of reviews and audits is to continua lly focus engineers' attention on the quality of the applicatton as it develops. Rroi,ws effect this in a scheduled and thorough manner. Audits do so on the basis of random sampling with short notice.

6.2 Minimum Requirements Large projects require the full set of reviews and audit listed here . Student teams should tty to conduct reviews and inspections of requirements and design , as well as postmortem reviews. "Reviews· are discussions of proposed artifacts. "Inspections· are conducted on completed artifacts presented to the team . The SQAP d~s not call out inspections as a heading, so the author has inserted section "A~s for this purpose.

After they have been reviewed, architectures will be inspected in accordance with GCI, Inc.'s inspectIon process manual , document GCI 345678. Architec· ture sections must be completed and signed off within a week of beginning detailed design.

6.2.3 Detailed Design Reviews These are reviews of all proposed detailed designs In the prese nce of the entire development team . They will be led by the design leader, who will determine their frequency and scope, but at least one design review will be conducted per iteration . If possible, the architecture will be decomposed into detailed designs of its parts, and these will undergo separate detailed deSIgn reviews.

6.2.3A Detailed Design Inspections After they have been reviewed, detailed desIgns will be inspected in accordance with GCI, Inc.'s inspection process manual , document GCI 345678. DetaIled design sections musl be completed and _igned off within a week of beginning implementation.

6.2.1 Software Requirements Reviews

6.2.3 Test Plan Reviews

These are walk -throughs of all proposed require ments in the presence of the entire team and at least

The e are reviews of all proposed test plans in the presence of the entire team . They will be led b Ihe

CASE STUDY: SOFTWARE QUALITY ASSURANCE PlAN FOR ENCOUNTER

QA l..ader, who WIll detemlin~ their f~quency and scope. The t t plan will be de o mpo cd into pans, and these will undergo separate reviews.

exceptions arc at the discretion of the VP for Engi . neering . It is the project leader's re ponsibility to schedule this review and provide the appropriate documentatio n and software demonstrations.

6.2.3A Test Plan Inspections Aft~r the>' have been reviewed, test plans will be in peeted in accordance with CO , Inc.'s inspection process ma nual , document CCI 345678. Test pl.n sections must be completed and sig ned off within a week of beginning testing .

6.2.4 Verification and validation Plan Review V&V is to be conducted by an independent team (i.e., not associated with QA), fo llowing the process d~tailed in CO 345678. The QA e ngineer will review the SVV plan prior to its execution .

6.2.5 Functional Audits The QA leader shall be responsible fo r auditing the product relative to the SRS. The audit will follow company guideli nes in ' CO 8902: Rel ease Proc~dur~s. "

6.2.9 SCMP Review The QA leader shall review the status of configura. tion management o n a monthly basis in a manner indepe ndent of the procedures speCified in the SCMP.

6.2.10 post-Implementation Review As with all GCI projects, the Encou nter team shall co nduct post· implementation reviews to provide data for future projects. These will include reviews of the project phase just completed and reviews of the QA process itself. The QA team o r QA leader shall fi le a process improveme nt report fo r every phase , and for the QA process itself. with the manager of the software engi neering laboratory.

6.3 Other Reviews and Audits -intentionally left blank

6.2.6 Physical Audits Prior to each delivery , the QA leader is responsible for checking that the physical software and its documentation designated for delivery are complete and the corr~ct versio n.

6.2.7 In-Process Audits

7. Test This section describes how testing is to be managed. The text here should refer to, but not duplicate. the software test documentation.

Proj~ct personnel should expect rando m audits of

their work. These will consi st of visits to the work si~ by individuals or teams designated by division managem~nt . A day's no tice shall usually be given for all visits, but audits without notice shall Ulke place as well. The subject of these audits will be the curre nt work of teams and individuals that has been alloca ted to the project All project artifacts wi ll be made freely available to all leam members and auditors at all times. It w111 be organized in a clear, standard fash Ion, so that audits will be po<siblc wilhout any nOltCe.

6.2,8 Managerial Review The Encoun~r prOJe t shall he rcvlewed by the VP for Enl!IOeenng during the first week of every month .

The responsibi lities for testing were described in cction 3.3. Refer to the Software Test Docume n · tation for detail s o n testing Encounter.

8. Problem Reporting and Corrective Action This section explains how defects come to be recognized, described, and repaired. They do not follow the details of IEEE standards. The reader is refelled to the IEEE standards, as wdl as 10 Humphrey [H) for additional defect $c:verity and IYpe lassl/lcalions.

109

110

CHAPTER 5

QUAUTY IN THE SOFtWARE PROCESS

The team will us,," the lJugzilla defect manage . mcnt system .

The code nnd ps,udocod, defects tyP"S arc a~ [oilows, • Syntax

Instead of describing 8ugzllla, we will de· scribe a hypothetical manual ddect system for the sake of clarity, even though a soft· ware-based system is common practice and far preferable. Such sysu,ms also allow for a dialog thread involving, typically, testers and devciopers.

• Logic • Data (I e ., allows a wrong variable value) • Insecure (allows unacceptable security breach) The workflow of a defect status is: I . Open: defect found by tester

The Problem Reporting Form to be usrd by the Encounter development team in response to a software problem report generated by QA is shown in Appendix B. To use this form , engineers should retrieve the form from www .a.b .c .d . The defect number will appear automatically , and the site will ensure that the appropriate fie lds are fi lled in. The values for s"miry arc as follows ,

• Crilieal, Causes the application to crash with sig· nincant frequency

• S,rious, Causes at least o ne documented require· ment to be unmet

• T rioial , Could be allowed to stand ad infin itum without impeding the user from exercising a required feature • Mtdium : Is neither serious nor trivial

The documentation defect types are as follows : • Incorrect

• Missing material

• Unclear • Ambiguous • Incomplete • Redundant (within or between documents) • Contradictory • Obsolete

2. Assigned: defect assigned to an engineer 3. Corrected: defect nxed by engi neer 4 . Closed : defect closed by tester

If the defect is reopened, the defect will move from the Corrected state to an Open state. The QA leader will create and the QA team will maintain a database of problem reports that describe the defiCiencies, discrepancies, and anomalies for Encounter. They will ensure that defects are conSiste ntly recorded on this form and that they are routed and repaired in a consistent manner. Problem reports shall be routed in accordance with the SCMP. Full traceability as to their effects and status shall be maintained, including after they are repaired. After iteration three, when a problem is encountered, the QA manager will distribute the problem report to the members of the Change Control Board (CCB). For the first three releases, the configuration specialist will carry out the functions of the QA team, and the projcct leader will perform all of the CCB functions in accordance with the SPMP. The CCB evaluates the problem report and then assigns a priority to the report of either j",,,,,dinl,, 10 b, do"" or oplio"nl. The problem report is then assigned by the CCB to the Encounter devdopment team , QA, or CM for resolution. The CCB determines the schedule for problem report .(solu· tion based on problem report priority and analysis report results . After the problem in the report is corrccted, the QA team review thc results .nd the QA manager reports on the review to the cca If nccessary, the process i repeated .

CASE STUDY. SOFTWARE QUAlITY ASSURANCE PLAN FOR ENCOUPlTER

9. Tools, Techniques, and Methodologies QA re hnlquc~ Include the aud,ting of standards, rt:qu iremen~ rra ing, de" gn venncatlon . software In'l'«l1ons, and the verin atl on 01 1 mlal methods. The QA tool, o n.i t of software verincation progTams. checklIsts, med,a labels, and ac eptance stamp . Checklo ts ",ill be obtai ned fTO m the compan 's software engoneering laboratory, and tailo red for En ounter. These arc augmented by NASA checklists at [9). C heckl ists include the following : • Review checklist are used at formal meetings, for document reviews, and for inspectio ns. • Checklists will be used for verifying the qualIty of the following activitie and documents· PrelimI nary Design Review , Critical Design Review , Test Readiness ReView, Functional ConAgurati on Audit, Physical ConRguration Audit , SRS, SDD , SPMP, and Software Development Folders. • Separate checkli sts and form arc used for software audit purposes.

This book contains checklists throughout. These checklists involve meeting and inspec t10n procedures, for example. T cams often begin with published checkli ts, and augment thelil according to additional spcciAc needs of thelf projects. Additional SQA tools, techn iq ues. and meth odologies for config uratio n manage ment arc described on the SPMP.

10. Media Control Describe the meaM by which d,sks, tapes, and so on will be managed TI,e SQA team verifies that the ,,,ftware mcdi a are bwlt and co nfigured per the CM P and th3t authorized chanRes have hee n ," ~ ra ll ed and te,tcd In

addillon, the QA team verofles that the so ftware media arc duplocated using only the procedures identified in the CMP. SQA acceptance Is indicated by an SQA stamp on the media label. The SQA audIt report for media co ntrol are intended as fllrther evi dence that QA procedures have been foll owed All backup medIa WIll be stored olfsite as described in the SCMP.

11. Supplier Control

This section concerns re lationships with suppliers 01 software and hardware. h describes how and by whom these relationships are to be handled. The SQA team verifies all commerCIal thirdparty products provided by the suppliers during incoming inspection by reviewing the packing slip that identify the products and theor version numbers. The QA manager is responsible for en uring that all thord party software and hardware meets the expected reqllirements. TI,e products WIll be va lida ted by the QA manager through installarion and accepta nce tests. A QA representative will be responsible for te tlng all new versions_ He will also be responsible for the relationship wit h the external vendor.

12. Records Collection, Maintenance, and Retention

This section describes how phy ~ical records will be handled and who will be responsible for them . Include disk ,Ies that arc not under conAguration control. Th e SQA record< colle ted and ar hIved ,hall on lude the fo ll ow on g, • T •• k reports • AnOll1aly report, not handl ed 1» l t he rCB"lar problem. rcrortinli oncehan l 111

111

CASE STUDY: SOFlWARE QUALITY ASSURANCE PLAN FOR ENCOUNTER

Appendix A: Metric History for This Project preparation Time

Defects Product

SCMP

Defect Unit

Section

Expected Rate

Actual Rate

Expected Time

Review Time Expected Time

Actual Time

Actual Time

-t-

1 minor defect per section

SPMP

Section

1 minor defect per section

SQAP

Section

1 minor defect per section

SRS

Section

1 minor defect per section

SOD

Section

1 minor defect per section

SIP

Section

1 minor defect

+

per section SWP

Section

1 minor defect per section

SWR

Section

1 minor defect per section

Requirements

D-Requirement

1 medium and

3 trivial defects per 100

Pseudocode

Diagram

1 minor defect per 5

KLOC

2 medium

defects COde

KLOC

2 medium

defects

Code Defects A frcc online tool ca lled "Refa to rl t" fTom hup j/www re f. tont. om estimate LOC. N 1..0 • and LO .

s hallll~cd

b , the Projc t 1"nol:cl to

113

112

CHAPTER 5 QUALITY IN THE SOFTWARE PROCESS

•

lem a",. including rc:conlmcndl1tion" 10 rl"SpOnSI ·

ble partlc, o

Logbook of QA" tivl tics

o

Audit report

o

igl1ed-off checklist< from reviews Jnd audits

o

Mlllutes of inspections

o

Metrics for the QA process itself

Besides verifying the archive procedure speciRed in the S MP, QA shall separately archive its OW" records at least once a week . These records arc retained throughout the operation and maintenance phase.

13. Training

record,n/! mctfl es QA Will also conduct monthly three-hour cla>'es for development team members 10 keep them Informed of qua lity goa ls, lools, and tec hl1lque< T tJm members ca n waive atlendance at the,c meellnt;( by sco flng perfectly on a muiliple. hOlce qUIz available al GCllmomhly/SQAlquiz. Ea h team member is reqUIred to attend a three -hour course on wntll18 slyies and conventions conducted by QA .

14. Risk Management QA tea," members are encouraged to Identify risks as early as pOSSible and direct them to the project leader The procedures for risk management are speCified in Sectio n 5.4 of the SPMP.

15. Glossary • •

•

•

Includes SQA training speciRc to this project.

16. SQAP Change Procedure and History The SQA o rganization will conduct an initial four-hour orientation on quality for the development team This will include a pre entation o n the metrics to be used and a workshop on how to use tools for

•

•

•

(The material in the following appendices was supplied by Jane Dyson .)

114

CHAPTER 5 QUALITY IN THE SOFTWARE PROCESS

Appendix B: Problem Reporting Form lOde lllumhcr:_ _ _ _ _ _ _ _ __ 2 Pro po«d by · _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ 3. Documcnts I scctions affcc ted : _ _ _ _ _ _ _ _ _ _ _ _ __ 4 . Documcnt dcfc t ty pe. 3.

Mis ing matcrial

b.

L1nclear

c

Ambiguous

d.

Incompl etc

e

Redundant (within or between documents)

f.

Contradicto ry

g.

O bsolete Source code affec ted (fo r source code defec ts):

5. Packa ge(s) _ _ _ _ _ __ 6 . 0.ss(es)'_ _ __ _ _ __ _ 7 . Met hod(s)_ __ _ _ _ __

8. Severi ty :

a.

High

b.

Med ium

c.

Low

9 . Code defect type : a.

Syntax

b.

Logic

c.

Data (i.e., allows a wrong variable value)

d.

Insecure (allows unacceptable security breach)

CASE STUDY: SOFlWARE QUALITY ASSURANCE PLAN FOR ENCOUmER

10. Phase mjected (earl,est phase with the defect). a.

Requirements

b.

Architecture

c.

DetaIled design

d

Code

e.

Implementatio n

II . Detailed descriptio n: _ _ _ _ _ _ _ _ _ _ __

12. Priori ty:

a.

___ Immediate

b.

___ Intermediate

c

___ Deferred

13. Reso lut ion : _ __ 14. Status:

a.

___ Closcd

b.

___ Opc n

Sign -off: 15. Description and plan inspected: _ _ __ 16_ Resolution code and rest plan inspected: _ _ __ 17. Change approved for incorporation , _ _ _ _ __

Appendix C: Change Reporting Form I . Change number: _ __

2. Proposed by: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ 3. Documenlslsections affected: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ __ 4. Reaso n for change or addition : •

•

•

5. Enhancenlent:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

•

•

•

6. Decails: •

•

•

Signatures: Descroption and plan inspected (QA tcam leader) _ _ __ Resolution code and test plan inspected (QA team leader) _ __ _ hang" approved for incorpor.Jtlo n (Team leader) _ __

115

116

CHAPTER 5 QUAUTY IN THE SOFlWARE PROCESS

Appendix 0 : Inspection Meeting Report Form A ompl cl cd I", pc li on " kC lin g Report must be ,.,el uded at the end of each document. Only the latest report i rcqlllrcd . Inspection Meeting Report PROJECT: DATE:

STARTING TIME :

ENDING TIME:

PRODUCED BY: TYPE OF INSPECTION:

0

INITIAL INSPECTION

0

REWORK INSPECTION

DOCUMENT NUMBER AND REVISION : BRIEF DESCRIPTION: APPRAISAL OF THE WORK UNIT:

0

InspectIon not completed (co ntinuatio n sc heduled for

0

No further inspection required

0

Minor revisions required

0

Major revisions req uired

)

MATERIALS PRODUCED

0

Issucs list (Not Au thor's Responsibility)

0

Issues list for Au thor

0

Traceabi lity Issues)

participant

Role(s) Author Moderator Recorder Inspector Inspector Inspector Inspector Inspector

Org.fDept.

CASE STUDY: SOFTWARE QUAUTY ASSURANCE PLAN FOR ENCOUNTER

Inspection Meeting Report Issues Ust ISSUES, NOT FOR AUTHOR Issue

Issue must be resolved prior to Document Baseline? YIN

Response

Assigned To

1.

2. etc.

ISSUES FOR AUTHOR Issue

Re~onse

1.

2. etc.

Appendix E: Document Baselining Checklist Document Baselining Checklist Item

0

Inspection Meeting Report completed and all issues resolved .

0

Revised document sent out for consensus after Inspection.

0

All comments accepted via Word's Track Changes. Track changes feature then turned off.

0

Check for clean requ irements traceability completed. (SRS only)

0

All high-level requirements have been allocated to detailed requirements. (SRS only)

0

Final traceability report generated and stored. (SRS only)

Comment I Initials

117

118

CHAPTER 5 QUALITY IN THE SOFTWARE PROCESS

5.10 SUMMARY Quaht practi es arc IIllcgrJ ted throughout Ihe devciopment process Thcy 'tart wIth planning, when , pc If, documents u h a the Sohware Quality A\Surance PI.n (SQAP) and the Software VenAcalion and ValIdatIon Plan (SVVP ) are produced , describing the qua lity policie" procedures. and practIces to be Implemented. The QAP is the m.,t er qu. hty plan and specifies the people and o rganizati o n, rcspon,ible for quality. the proJe t documentallon to be produ cd , the metric, to be co llec ted , the procedures to be practIced. and the techniques to be IInplement ed . It IS an impo rtant document as it sets the expectatIons regarding quality early in a project and helps guide its implementation . In pections are an important qllality technique that involve peer reVlcw of all project artIfacts including documents, test plans, and code . Their goa l is to identi fy defects as close to their mtroduction as possible so that they can be repaired quickly. Co nsiderable research has shown that the cost to repair a defect increase dramatically the longer It i all owed to per;ist in the software. Quality reviews and audits by a quality assurance (QA) orga nization are benencial. An external QA group IS mdependent of the people developing the softwa re and o ther artifacts and can objectIvely assess quality. Again , a sess ing quality and addressing it throughout the devel o pm ent process helps identify problems as earl y as possible. Problems arc identi fied by team members throug hout the development process and are submitted as d4rcls. A scrcelll ng process is implemented to ensure that the defects are accurate and va ltd. A classilkation system is employed to understand the severi ty of each defect and priority fo r its repair. In addi1ion, maintaining metrics such as number of defects, time to repair, and so o n is useful for comparison with other projects and in making estimates for future projects. Improvi ng the effective ness 01 the overall software process is accomplished throug h implementation 01 a meta · process. Th is inc ludes the co ll ection of pl ocess merrics, and meetings at the end of projects phases to analyze the metrics. In additIon , lesso ns· learned meetings are co nducted at the end of a project to analyze project successes and identify areas of improve ment. The Software Engi neeri ng Institute has deve loped a comprehensive meta·process for assessi ng an o rganization's overa ll capabi lity . The process is ca lled the Capabil ity MatUrity Model IntegratIon (CMMI), and it de Rnes several leve ls of ca pabil ity and maturity an organization can measure itself against. The levds range from the lowest, Levell Initial , to the hi ghest, Levell Optimizing . At the Initial level an organization can produce so.ftware but has no recognized process. At the Optimizing leve l, an organization implements a meta · process for process improvement

5.11 EXERCISES 1. In a paragraph , explain why it is important to document quality procedures at the beginning of a

projec t rather than later on. 2. The number of people attending an inspection can have a direct impact o n the effectiveness of the review. list the di advantages of having either too few or too many people attend an mspect ion. 3. Give two advantages and two disadvantages to using standards for documentatio n of the various software phases. 4. Why is it generally a good idea to. have a cross· functional group be parI of an inspection team What type of review (that is, during what development phase) might It not be a good ide.

BIBUOGRAPHY

5. Your instructor will pair up student project teams. Conduct an inspection of an ani fact produced by the other team, such as a SCMP or SPMP. Use an inspection checklist, such as one found in [3]. to guide your in pection. 6. Give an example of a delecr that might be clossiAed with a hi gh severity but a low priority. Be spcciAc with your answer. 7. (a) In your Own words, describe each of the CMMI levels.

(b) How does applying the CMMI levels promote organizationaJ quality7 Explain this paragraph or two, using your own words .

•

In

a

BIBLIOGRAPHY t. Figan, M. "Design and Cod~ Inspections 10 Reduce Erro~ 10 Progr.sm Devdopmrnt " flL\.1 SYJ/.nII) J01Inwi. Vol IS, 0 3, 1976, pp. 182-21 1. 2. Wiegers, Kilrl. "-Improvlng QUJ hty lluough Soft ..... a~ Inspections: Procm 1.. ~C1, 1995. http llww\Ol' procc5SImP3ct c.omlanlclesl inspects hIm! [accessed November 15. 2009}. 3. Wiegers. Karl, "Goodies for Peer Revie.....s... PrOC'rf$ Impacl, 1utp 11W\tt"'W prOCCSSUT\polCl com/pr....,good,,:, [olccosed ()'.'cmw 15 2009) .. Gchani , Naronn, and A. McUunck, "SojtWtJr, SptCIji. af/(7PI Ttd""qulS. " InternatIonal Computer Science ~nes, Addlwn -Wesley. 1985 5 Cllb, T., and D Cr.aham. " Softuu~rt 'nJPtrIlO"." Addl~n · Wes ley, 1993 6. Bugzil1~ . hnp:llbugzi lla orglaOOu t html [accessed December 10, 2009 ] 7. upability Maturity Model )!': lotegr.nion (a 'MIS:-" J, Version I I, hup Jlwww !!oC' emu cdulpubldocumenl oz·reportv pdfl 02 ln0I2 .pdf [,cc..sed December 8. 2009 J. 8, Humphrey. Watts 5., -A D'SClpli"( for 5
119

Software Configuration Management

•

What is the purpose of software configuration management?

•

What activities does it consist of?

•

How do you plan for configuration

The Solrware

management?

Development

Ufecycle

•

What tools are available to support it?

•

How is configuration management handled in large projects. in praclice?

Figure 6.1 The context and learning goals for this chapter

Many artifacts are produced in the course of developing a software product, uch as specIfications (e.g., requirements, design), source and executable code, test plans ond test data, user documentation, and supporting software (e.g., compilers, editors) Each undergoes numerous reVISions, and keepIng tTack of the vanous versions needs to be managed in a reliable and con istent manner. Soffware Configuralion 1\ InnagC!lloll (SCM) IS the process of identifying, tTacking, and storing all the artIfacts on a project. In the context of SCM, each 01 these artifacts is referred to as a ConAguration item (0 ).

SCM ACIIVmES

1 conrnbut to overall software quality in that it supportS a reliable way to control a project's arti~ ts For c ample, the (]vI proces ensure that the proper source mes are included when building the softw,re, tern and that the orrcct project documentatIon IS retrieved when required . 1any , tlvitie contribute to configura tIo n management . including identiAcalton of artifacts as configuration items, storage of artifucts In a repository, managing changes to artifacts, tracking and reporting these changes, auditing the CM proces to ensure it's being implemented correctly , and managing software builds and relea cs. Many of these activitIes arc labor intensive, and SCM systems help automate the process.

6.1 SOFTWARE CONFIGURATION MANAGEMENT GOALS We first define the overall goal of software configuratIon management: b.,,/i"t .-Itly, outrwrilr .-Irfy. 'tumio", Q.d disasltr rtCoorry. Baseli n" safety is a process of accepting new or changed Cis fo r Ihe current version of the developing product (the baseline), and safely storing them in a common repository so that they ca n be retrieved when needed later in a proJect. Overwrite salety means that team members can safely work on Cis simu llancously , and changes can be applied so they do not overwrite each other. Overwrite safery is needed when the follOWing kInd of sequence occurs.

1. A. Engineer Alan works on a copy of

CI X from the common reposi tory.

B. Brenda simultaneously works on an identica l copy of X.

2. Alan make changes to X and puts the moddled X back in the repository.

3. Brenda also makes changes to X and wants to replace the version of X in the com mo n repository WIth the •

new versIOn .

Overwrite safery assures that Brenda's changes don't si mpl y replace Alan's, bUI Instead are added correctly to Alan's. Reversion occurs when a team needs to revert to an earlier version of a CI. This IS typically reqUired when mistakes transition a project to a bad state-for exa mple, when it is found that a new version of a CI turns ou( to cau.se so many problems that it is preferable to revert to a prevlou verSIon . ReversIon requIres knowing wh,ch version of each C1 makes up a previous version of the project Disaster recovery is a stronger form of rcversion-it is thc process of retainIng oldcr versions of an applicatIon for f\Jture use in case a disaster wipes out a newer version . These four goals, fundamental for configuratio n manage me nt , arc summari zed in F,gure .2.

6.2 SCM ACTIVITIES There are several SCM acttvitie and best pracltce th at arc Impl emented to successfully meet the gal. JUSt descnbed They are maInly the following . I . ConfIguration Idenltficalton .

2. Saseltne control 3 Chan!!e control 4. Version contm/

121

' 22

CHAPTER 6

SOFTWARE CONFtGURA liON MANAGEMENT

• B.seline S.fety n
Is arc .fely storcd In a repository and can he retrieved when neussary

• Overwrite Safcty En ure that engineer, hanges to the 'arne

I arc applied corre tiy

• Reversion Ensure ability to revert

10

earlier version .

• Disaster Recovery Retain backup copy In case of disaster Figure 6.2 Major goals of configuration management

5 Configuration auditing. 6 . ConRguralion tatus reporting. 7 . Rele.se management and delivery. Each of thcse IS desCribed in the folloWing ections.

6.2.1 Configuration Identification The first step in configuration mana gement is to ident ify a project's artifacts , o r configuration items (CIl, that are to be controll ed for the proJect. As deSCribed in the introduction , candi date C is include source and object code, project speCifications, user documentation, te t plans and data, and supporting softwarc such as compilers , editors, and so on . Any artifact that wi ll undergo modification or need to be rerrieved at some time aher its creat ion is a candidate for becoming a CI. Individual fi les and documents arc usually C is and so are classes. Individual method may also be C is, but thIS not usually the case . A CI may consist of other Cis. C is are too large when we can't keep track of individua l Items that we need to and we are forced to continually lump them wit h other items. Cis are too small when the size forces us to keep track of ite ms whose history is not relevant enough to record separately . Once selected, a C I is attached with identifying information that stays with it for its lifetime. A unique identifier, name , date, author, revision history , and st.tus are typical pieces of information associated wit h a CI.

6.2.2 Baselines While an artifact uch a source code or a document is under development , it undergoes frequent and ", formal changes. Once It has been formally reviewed and approved, it forms the basis for further development, and subsequent changes come under con tro l of configuration management poli ies. uch an approved artifact is called a bas"i", . IEEE Std 1042 defines a baseline as a " pecificatlon or produ t that ha been formally rcviewrd and agreed to by re ponsi blc management, th.tthereafter serves as the basis for further development , and can be changed on ly through fo rmal change control pro cdure " Baseline, not only rerer to individual C I< but also to collection of Cis .t kc proje t milestones. The are created by recording the ver>lo n nllmber of all the Is at that time and .ppl ins a Version I.belto uniqud identify .t. Milc>lones can occur when ,oft ware is internally rdca<ed to a testing organization, or when a

SCM ACTIVITIES

A baseline is an individual or group of Cis labeled at a key projec1 milestone.

Each version below is a baseline .

.. 0.3.4.2

v 0.4.1

.. 0.3.4.3

/ - CI 's

Update

Removal

Addition

A1 E3

05

figure 6.3 Transitioning from one baseline to the next

version of software IS packaged for release to a customer. For example, a new software version is created and a set of source files and documentation that constitute software release 1.0 are grouped together, given a unIque label such as "version 1.0," and are recorded as belonging to the same baseline. This allows all the fi les constituting software release 1.0 , and their correct versions, to always be correctl y idenllfied and g rouped together. If files belonging to a baseline are added . deleted , or modiAcd , an updated baseline is crea ted with a new version number. Figure 6.3 illustrates ,his concept. Once baseline are created and labeled, they are utilized in a proJect for three primary reasons ( I], I. Reproducibility

2. Traceability 3. Reporti ng These are explained next. I . Reproducibility means that you can reproduce a panicular software version o r set of do umentatio n

when necessary . This i required during product development as well as during ma intenance . For example, software is shipped to customers, and different cu tomer ma y usc different vcr ions In thc meantime, the project tcam is developing a new software release, and as a result is updating many of the Cis u.s ed in previous software releases If a problem is reported by a customer nonn ing an o lder software verSion, because It was saved as a baseline the o lder versio n can by resurrected by the projc t team and used to identify and repaor the source of th e problem . 2. Traceability means that relations hips between various project artifacts can be e tabllShcd and re og · nized. For exa mple, test cases can be ti ed to requirements, and requ irement> to deSIg n. 3 Reporting mea ns that aJ) lhe cleme nt o f ~ ba c line an DC dctennlned and the o ntenlS of various ba e1,ne~ can be com pared Th,s apab,loty ca n be ulllozcd when trying to Identify problem I l l ' n,'''' relea<e of software. Instead of performong a length y debuBgi ng effort , diffcrcn e< In , ource file, bet\ ee n the previous and current o ftware verSIons ca n be analyzed Th,s may be enotlgh to Ide ntl! the wlIrce 01 the problem If no t, knowing exactly what c hange< occurred ca n pOInt to rOlential rOOl callSC', 'reed,ng up the debuggIng effort a nd leading to faslcr and ca
123

124

CHAPTER 6 SOFTWARE CONFIGURATION MANAGEMENT

6.2.3 Change Control onfiS\lratio n items undergo han!!" throughout the course of development and ma intenance:, as a result of error con'cctio n and enhancemenl. Defects d iscovered by rest lnll o rgan Izations and customers ne~esSltatc repair Rel ease of software in lude e nhancements to eXIsting fu nctio nailty or the addition of new hlnctionality . 1'"119' cOl1 lrol, . 1 0 known a co nAguration control , includes a tivltl e. to request. evaluate , approve o r disapprove, and implement these changes to baselined I [2]. The formality of these activitIes varies g reatl y from prOject to project For example, requesting a change ca n ran ge fro m the most informal no d irect oversight for changi ng a C I- to a fo rmal process filling out a (om, or request lI,dic"ung th e I and reason for change, and ha vi ng the request approved by an independent group of people before it ca n be released . Regardl ess of the formality of the process, c hange contro l involves Identification, documentation , analysis , evaluation , approval , verificatio n, impl eme ntatioIl , and release as described next (2).

Identification and documentation The CI in need of change is identiRed, and d ocumentatio n is produced that includes ," fo rmat ion SLtch as the fo ll owi ng: • Name of requester • Description and extent of the change • Reason fo r the chan ge (e .g., defects fixe d ) • Urgency • Amount of time required to complete change • Impac t o n o ther Cis or impact on the system

Analysis and evaluation Once a C I is baselined , pro posed changes arc analyzed and evaluated fo r correctness, as well as the potential ,mpact o n the rest of the system. The leve l of anal ysis depends o r the stage of a project. During ea.rlier stages of development, it is custo mary for a small group of peer develo pers andlor the project manager to review changes. The closer a project gets to a rel ease milesto ne , the more closely proposed changes are scrutiniud, as there is less time to recover if it is incorrect or causes unintended side effects. At this latter stage, the eva luation is often conducted by a change contro l board (CCS), which consists of experlS who are qualined to make these ty pes of decisions. The CCB is rypically compri sed of a cross- fun ctional group that can assess the impact of the proposed change. G roups represe nted include project manage me nt , marketing, QA, and development. Issues to consider during the evaluation are as follows , • Reason for the change (e.g., bug flx , performance improvement , cosmetic) • Number of lines of code chan ged • Complexity • Other sou rce flies affected • Amou nt of independent testing req uired to validate the c hange C hanges are ei ther accepted Into the current release. rejec ted o utrI ght, or deferred to a ubsequent release .

SCM ACTIVITIES

Approval or disapproval Once a change request is evaluated , a decisIon is made to eIther approve or djsa pprove the requesl- Changes that arc technically sound may still be disapproved or deferred. For example, if software IS very close to being rele~sed to a customer, and a proposed change to a source file reqUIres many complex modificatIons, a deC! Ion to defer repair may be in order so as to not destabilize the software base. The change may be scheduled for a h'Nre relea,e .

verification, implementation, and release Once a change is approved and implemented , it must be verified for correctness and released .

6.2.4 Version Control Version control supports the management and storage of Cis as they arc created and modI fied throughou t the software development life cycle. It SllPPOrtS the ability to reproduce the precise sta te of a CI at any point in time. A configuration management SYSlem (al 0 known as a version control system) automates much of this process and provides a repository for SlOIing versioned Cis. It also allows team membe rs to work on artifacts concurrently, Aagging potential conflicts and applying updates correctly. A good version con trol system supports the following capabilities, 1. Repository

2. Checkout/Checkin 3. Branching and mergi ng 4. Builds 5. Version labeling These arc explained in the fo llowi ng sections.

6.2 .4.1 Repository At the heart of a version contro l system is the repository, which is a centralized database that sto res all the artifacts of a project and keeps track of their various versions. Repositories must support the ability to locate any version of any artifact quickly and reliably .

6.2.4.2 Checkout and Checkin Whenever a user needs to work o n an artifact , they request access (also known 35 ch,cko"l ) from the repository, perfonm their work , and store the new version (also known as ch,ckill ) back in the repository. The repositOry is responSIble for automatically assigning a new version number to the artIfact. Files can usually be checked out either lock,d or ""'ock,d. When checking out locked, the file IS held exclUSIvely by the requester and only that perso n can make modin atlon to the file and check in tho e changes. Others may check OUt the fi le unlocked, which mean s it is read ·only and they only receIve a copy Concurrent wnte pnvileges ca n be achieved by branching, which IS explainod in the next section. When checkIng 111 a Ale , versIon control systems record the user making the change and ask the person to includ.e an explanation o( why the Ale was changed and the nature o( the changes ThIS makes it ea>ler to see how a Ale ha~ evolved over tIme , who has made the changes, and why they were made

125

126

CHAPTER 6

SOFlWARE CONFIGURATION MANAGEMENT

File A (a) John branches. _---.... v1 .2 01 fila A

/

(c) Sally branches v 1.2 otfile A

1.2

o

o

' -__~ (d) Sally mod~ies her copy 01 v 1 .2 of

(b) John modifies his copy 01 vl.2 of ~__-....

file A

~---.... tileA

1

1

1.3

(e) John merges his ..........__~ changes to me A

(f) Sally merge. her changes to file A

1.4 (g) v1.4 contains both sets of changes Figure 6.4 Branching and merging changes

6.2.4.3 Branching and Merging Projects are Illos t ofte n developed by teams of people . Version co ntro l syste ms provide mechanisms to allow team members to work on the same se t of files concurre ntl y (branching ) and correctl y apply changes to common files 0 that no ne are lost or overwritten (mtrging ). This is also known as overwri te safery Figure 6.4 depicts an example, in which Jo hn creates a branel, by checking out versio n 1.2 of file A. A branch is a private work area in a version control system that allows you to make changes to baselined files without conflicting with other team members. John maintains a private copy of the fi le o n his branch and makes his changes. Concurrently , Sall y also needs to work on file A. so she creates he r own branch and checks out versio n 1.2 H er copy starts out the sa me as John's si nce he has not yet checked in his updates. O nce)ohn finishes his changes, he c hecks in his mes to the reposi tory, and the file is given a new version number 1.3. Later, Sally finishes her modifications to A and wants to check in the file . If the version contro l system allowed her to just replace the current copy of file A (versio n 1.3, which now includes John's changes) with her copy, John's changes would be lost. Instead , the versio n control system supports mrrgl"g , which intell igently applies Sally's changes to version 1.3 and creates a new version 1.4 with both of their cha nges applied cor reetly. If the set of c hanges are made to various parts of the same fi le , the system ca n usually perform the merge operation automa tica ll y. If the ::hanges conflict wi th each other, as when the same lines of code are c hanged, the system Wi ll ask the u or to merge the c hanges manuall y. In this case the system will sh ow the user which lines overlap so that person can apply the changes correctl y.

6.2.4.4 Builds Version contro l systems provide support so as to reliably and reproducibly compile and build the latest version of software fi les into an executable , usable file . A user ca n specify which branch of code to build from , all OWing concurrent development. In addition to the executable Ric, builds produce logs containing lhe Rle versions comprising the build .

SCM ACTIVITIES

6.2.4.5 Version Labeling
6.2.5 Configuration Audits As defined by IEEE 1028 · 2008 (3]. a software audit is "an independent exami nation of a software product , software proce , o r Set of software processes performed by a th ird party to a sess compliance with specifications, sta ndards. contractual agreements, or other cri teria." In the contex t of co nfi guratio n manage · ment, the goals of a configuration audit are to accompl,sh the following : • Verify that proper procedure arc being followed , such as formal technica l reviews. • Verify that SCM policies, uch as those defined by change control , are followed . • Deterrnine whether a oftware baseline is comprised of the correct configuratio n item . For example, arc there extra items includcd 7 Are there items missing7 Are the versions of ind,vidual ,tems correct( Configuration audits are typically conducted by the quality assurance group.

6.2.6 Configuration Status Reporting Configuration sta tus reporting supports the development process by providing the necessary ,nformation concerning the softwa re configuration . Ot her parts of the configuration process, such as change and version control, provi de the raw data . Configuration statu reportin g includes the extraction , arrangement, and formation of reports according to the requests of users (4 J. Configuration repo rts include such infomlat'On as the following· •

ame and vcr ion of Cis

• Approval h,story of changed Cis • Software release conte nts and compamon between releases • Number of changes per CI • Average time taken

to

change a

I

6.2.7 Release Management and Delivery Release management and del,very define how
127

128

CHAPTER 6 SOFTWARE CONFIGURATION MANAG MENT

I

3 . 3 .2

Inlrodu tlo n

.2 3 2. I 3 .2 .2

•

rgJ nl ZJtlo n

1\·1 respo nslbtlltl c,

.2.3 App ll able policies, directl vcs. end pro cdu re~

3 .2.4 3. 3

Ma nagcllIe nt of the

M proce>'

M activi ties 3. 3. I

o n~g u ra tl o n identi fica ti o n

3 .3. 1. 1

Idc nti fy lllg co nfigurat io n Na mIng co nfig urati o n items

3. 3. 1.3

Acq uinn g config uratio n •

Items

3. 3 2 . I

Requ estIng changes

3.3 .2 .2

-valuattng c hanges

3 .3 .2 . 3

ApprovIng or dt<.pprovtng changes

3. 3.2 4

Im plem enti ng changes

3 . 3.3

o nfiKuration status accounting

3. 3 .4

onfigu ration evaluation and rCVlews

3 3.5

Interface co ntrol

3 .3 .6

Subcontractor / vendo r control

3.3.7 Re lease manaKement and delivery

Ite ms

3. 3. 1.2

o nflK"rati o n contro l

3 .4

SCM schedules

3.5

C M reso urces

3 .6

SCM plan mai nte na nce

Figure 6.5 IEEE 828·2005 Software configuration Management Plan table of contents SOUrce IEEE Std 828-2005

6.3 CONFIGURATION MANAGEMENT PLANS T o speci fy how the softwa re co nfiguratio n is to be managed o n a project, it is not suffici ent me rel y to poi nt to the co nfi gura tt o n manageme nt tool that will be used. There is mo re to the process, suc h as what activities are to be do ne, how they arc to be im plemented, who is respo nsible fo r implem enting them, when they will be completed. and what resource are req uired- both human and mac hine [2]. The IEEE has developed a standard for oftwa re config uratio n managemer,t plans. IEEE 82 8· 2005. Th is ca n be very useful in maki ng sure that all bases have bee n covered In the process of C M. Figure 6.5 shows the re leva nt conte nts of th is standard, whI ch arc Included in C hapter 3 of the plan. The topics to be pecificd in Sectio n 3.3 of the SCMP arc largely covered in Section 6.2 of th is chapter. Sectio n 3.3.3 of the SCM P doc-uments the mea ns by whi ch the st"tus of SCM i to be communicated (e.g., in writing. o nce a week). Sectio n 3.3.6 applies if a C M tool is used o r if configuratio n management is handled by a ubcontractor The IEEE sta ndard describes the purpose of each section of the above outline in detail. IEEE 828 · 2005 ,s used in the Encoun te r case stud y later in th is chapter.

6.4 CONFIGURATION MANAGEMENT SYSTEMS Fo r all but the most tri vial applicatio n. a co nfig uration management system (also known as a version control system) is indispensable fo r mana8m8 all the artifacts o n a project. Microsoft's SourceSafe™ i in commo n use. VS is a commo n enviro nment. as well as Subversio n and others.

6.4.1 Concurrent Version System (CVS) The Concurrent Version System (CVS) is a commonly used, frec, o pen ource configura tio n management system. C VS Implements a client-server architecture, With users running client V softw3l'e o n their

CASE STUDY: ENCOUNTER VIDEO GAME

• Up-Lo·dare Is id~ntlCal to the latcst revision in the repo ItOry. • Locally Modified File has been edited but has not replaced latest revision . • N""ds a Patch om~one else has committed a newer revision to the repository .

• Needs Merge You have modified the nle but someo ne else has committed a newer revision to the reposi tory. • Unknown Is a temporary fi le or never added . Figure 6.6 File status possibilities in CVS

machines, and a CVS seTVer storing a repository of project fi les. Users check out projects (using the chtekoul command); make changes; check in (usi ng the com mil command); and merge with the changes of others who checked out at the sa me time (using th e updQI' command ). C VS automatically increments the version number of fi les or directories (e.g., fro m 2.3.6 to 2.3.7). The status possibilit ies for a fi le are shown in Figure 6.6. 6.5 CASE STUDY: ENCOUNTER VIDEO GAME

What follows is a configuratio n management plan for Encounter. The Softwa re Configuration Manage· ment Plan (SCMP) for Encoun ter is based on IEEE Std 828·2005 Standard for Software Configuratio n Management Plans. The tabl e of contents of the relevant sections is outl ined in Figure 6.8, which is Chapter 3 of the IEEE specificanon.

Signature

Date

Engineering Manager

".:;.....,

6/ 15/ 04

QA Manager

£. 'Wiluv.

6/ 11 /04

project Manager

a. !I~"itJ.

6f7/ 04

ENCOUNTER SOFTWARE CONFIGURATION MANAGEMENT PLAN

Author

l.. $ 'QU4c

6/1/ 04

APPROVALS

Revision History

Note: to the Student, It ii a good idea to have cach team member Sign off on the phYSIcal document. This pro· ces, focuses their attention on the fact that they Ire accountable for Its contents, and they will be more likely to ensure that It Is the dowment they intend

Title

This assume<; the existence of a method whereby revision numbers of documents are assigned. Versio n I I 0.0 E. Br""dc '

re.ted first d",ft 11/9

1.1.0 R. Ilosrwick · Rr viewed 1/ 10/99

129

130

CHAPTER 6 SOFTWARE CONFIGURATION MANAGEMENT

I 1.1 E. Braude. Expanded 3.2 1/ 18199 1.20 E Braude· Reviewed for re lcasc5/ 18199

A , pc ifl ~ engine r, prOVided by the A or~a . nlz.llon, woll be d e"~ n ate d "s the "conAguratlon !eadcr" fo r Ihe durati o n of the pro) ·ct

1.2. 1 E. Braude, r-inal edltong4/ 30/99

3.2.2 SCM ReSponsibilities Version 2 2.0 .0 E. Braude: Significant edit of section xx S/2/99 2.0 I E. Braude: edits S/ 13/04 The table of conte nts of this SCMi' follows that of IEEE standard 828·200S .

3.1. Introduction

3.2.2.1 Configuration Leader

This Software Co nfiguration Management Plan (SCMP) describes how the artifacts for the Encoun · ter video game project arc to be managed .

3. 1. 1 Definitions Approved Cis: Cis signed off by project management Artifact: A Anal or interim product of the project (e.g., a document , source code, object code, test result) Master Ale: A particular designated Ale for this project, defined in Section 3.3. 1.2

3.1.2 Acronyms

CI: configuration item-an item tracked by the configuration system CM: configuration manageme nt-the process of maintaining the relevant versions of the project SCMP: the Software Configuration Management Plan (this document)

3.2. SCM Management 3.2.1 Organization

5..... ho .. this is

tatc the tasks that each role must carry out If thi is not tated, essential actiVitieS will not be done, and ome activities will be done by more than one team member Include backup reo sponSlbilitie~ In case the main individual is incapacitated .

be manaRed. Supply role (.), but lID names or R:lponsibillties. Names In: supplied In a liter section. 10

"Responsible" does not necessarily imply that the individual does all of the work merely that he or she organizes the work and sees to it that the work is done.

The configuration leader shall be responsible for organizing and managing configuration manage· ment (CM ). Whenever possible, the configuration leader shall discuss CM plans with th~ devdopment team prior to implem entation. He or she will main · tain this document (the SCMP). The configuration Ieadcr is responsible for the installation and main · tenance of the conRguration management tool(s) speciRed in Section 3.2.3. Archiving is to be per· formed in accordance with department policies 1234S . The SCM leader shall be responsible for ac· quiring, maintaining, and backing up the configura· tion tools used He or she shall also develop a plan of action if tools become unsupported (e.g., by dis· continuance of the vendor). Additional respon Ibili · ties of the configuration leader are stated in Section 3. 1-3 .6.

3.2.2.2 Project Leader The project INder and his or her manager will take over the config\lration leader's function only under exceptional circumstances. They are respon
CAse STUDY: ENCOUNTER VIDEO G6~E

rd""ant means of access [0 documents throughout the life:: of the project. The project leacler shall ensure that arch iving is performed in accordance with the policies In Section 3.2.3 below. Additio nal responsibilities of the managers are stated in Sections 3.3. 3 and 3.3.4 .

5. CM passwords should ~ changed in accordance with corporate security practices, with the fol· lowi ng addition, No password shall ~ changed until the project leader, h is manager, and the manager of QA have all been notified and have acknowledged the notiRcati o n.

3.2.2.3 Engineers It is the responsib ility of eac h

6. The prOject leader and department manager are to have complete access to all documents under co nfiguration at all times. Access verificatio n form www.ultracorp .division3 .accessVeriRcati on is to be subm'tled evety two weeks by the project leader to his or he.r manager.

engineer to abide by the CM rules that the configu. ration leader publi shes. Engineers are also referred to ' Standard Engi neering Respo nsibilities," docu ment 56789. Additional responsibilities of the engineers arc stated in Section 3.3 below .

3.2.3 Applicable Policies, Directives, and Procedures

7 . The Encounter project will u e SuperCMTool

release 3 4, a configuration management product b), SuperCMT001.

These are fictitious names. Activities such as CM are generally conducted in accordance with group or corporate guidelines. Student teams should identofy and li st their policies in this sectioa . Policy 3 should be included .

8. Arch iving is to be perfonned in accordance with de partment policies 12 3456.

3.3. SCM Activities I . Configuration management for th is project shall

be carried o ut in accordance with the corporate guidelines for configuration management , cor· po rate document 7890 versio n 6 (8/ 15/98 ). 2. In accordance with division software improvement policies, midstream and pOS1· project review ses· sions are required, where improvements to these guidelines are to be doalmented for the benefit of the o rganization. These sessions are required to help prepare the d ivision for level 5 CMM certl fi · cation. The sdf·a sessment rt.'SUlts are to be sent to the manager of Software Self-Assessment wi thtn three weeks of the assessment session. All "room for improvement" section are to contai n sub tan·

tive matenal , with speCific example . 3. All curre nt and previo usly released versio ns of Cis will be rctalned.

3.3.1 configuration Identification Th is section states how conAguration items (Cis) come into being and how they get their names. Witho ut such procedure being 5tated and followed , chaos results.

3.3.1.1 Identifying Configuration Items The project leader shall be rcspon ible fo r identifying all Cis. Engtnecrs wishing to pro pose Cis shall secure hiS or her agreement, via c·mail or otherwise. If the project leader is unavailable for one busi ness day fo llowi ng the engi neer's c·mai led proposal for inciuslO n, the config · uration leader shall have the authonty to a cept the proposed item.

4. The master Ale (defined in ection 3 3. 1.2) can be

accessed o nl y by the conngu rallon leader and , In his Or her absen e, the department manager

3.3.1.2 Naming Configuration Items The on figuratio n leader shall have the rt"Spons,blhry fo r

131

132

CHAPTER 6

SOFTWARE CONFIGURATION MANAGEMENT

labellOg all fo ll ow,

Is T he file

co n vc nll O Il~

shall be a,

Root directory , Encount er ubd, rcc tory

R or DD or ..

o ntrol th rough upcr MTool A read·only version of th e I IS ava .l ablc to all englnce r~ Under no cirwm
3.3.2 Configuration Control

File N· N· N xxx correspond",!; to ve""on N.N.N For example, vc r Io n 2 'I 8 of the SR will be o n me Encounle r/S RS/2_ 4_8.0<1. The texl m~ Master 10 Ihe root directory states Ihe versions of the Is that compri e Ihe current and prior tates of th e prOjeCt For exa mple, Master could melude mfo rmati on such as: The current versio n of Encounter is 3.7. 1. It compn everSio n 2.4.8 of the SRS, verSion 1 4 of the SOD. The previous version of Encounter was 3.6. 11 . It comprised version 2.4.8 of the SRS, version 1.3 of the SOD. Thi s Informatio n shall be maintained in a table of the followi ng form . Encounter SRS verSio n SDD version.... Release

3.3.1 .3 Acquiring Configuration Items In specifying this section , imagine the most stressful part of the project, which is the implementation phase, involving several people in parallel. The process has to be very orderly, but it also has to allow engineers reasonable access to the parts of the project so that they can start work Quickly. Engineers requiring Cis for modification shall check them out using SuperCMTool's checkout procedure. Note that SupcrCMTool prompts the user with a form requesting an estimate of how long the checkout is anticipated , and store this mformation for all requesters of the CI. Anyone requiring a CI that is currently checked out should nellOtiate with the current owner of the CI to transfer

This section spells out the procen whereby configurallon Items are changed. This prDCeH should be Aexible enough to allow Quick changes, but controlled enough to keep changes very orderly so that they improve the application, not damage it.

3.3.2.1 Requesting Changes As specified in the Software Project Management Plan (see Part III ). the team will designate an "inspector engineer who is allocated to each team member. Before requesting a change, engineers must obtain an inspection of the proposed change from an inspection team or, if this is not pos ible. from their inspector engineer. To request the incorporation of a changed Cf into the baseline, form www.ultracorp.division3 .Encounter .submitCi must be submitted to the configuration leader and the project leader, along with the changed CI and the original CI.

3.3.2.2 Evaluating Changes For larger proj~ts , a group of people, often called the Change Control Board, evaluatrs and approves changes. SlUdent teams must make this process reasonably simple. The project leader or designee will evaluate all proposed changes. The project leader must also specify the required Quality standards for incorporation .

3.3.2.3 Approving or Disapproving Changes The project leader must approve proposed changes. If the project leader is unavailable for thn:e business days follOWing the submission of a proposed change, the configuration leader shall have the authority to approve chan!!es.

CASE STUDY: ENCOUNTER VIDEO GAME

3.3.2.4 Implementing Changes To avoId chaos, it is natural to give to the eM leader the responsib,l,ty for incorporating changes; this can create a bottleneck at imple. mentation time, however. Before this "c runch" occurs, the CM leader should find ways to remove this bottleneck by distributing as much work as feasible to the engineers making the changes.

Once a CI is approved for incorporation into the baseline, the co nfi guration leader shall be reo sponsible for coordinating the testing and integra· tion of the changed CI. Thi s should be performed in accordance with the regression test documentation described in the Software Test Documentation . In particular, the configuration leader shall coordinate the building of a version for testing . Version releases must be cleared with the project leader, or with the manager if the project leader is absent.

3.3.3 Configuration Status Accounting The configuration leader shall update the configu· ration summary at least once a week on the project configuration Web si te www.ultracorp .divi sion3/ EncounteriCo nfiguration . SuperCMTool's sta.(Us report will be a sufficient format for the summary .

3.3.4 Configuration Audits and Reviews In industry, random audits are often employed. They are not commonly conducted by student teams due to a lack of resources, although rome teams have carried them out successfully. PeriodiC reviews, as part of the regular team meetings, do not take much time , and they arc recommended .

Configuration efforts will be subjoct to random audits throughout the project's hfe cycle by the IV&V team .

3.3.S Interface Control The CM system interfaces with the project Web site. This interface shall be managed by the configuration leader.

3.3.6 SubcontractorNendor Control The con~guration leader shall track upgrades and bug reports of SuperCMT001. He or she should be prepared with a backup plan in case the maintenance o f Super. CMTool is discontinued. This plan is to be sent to the project leader within a month of the project's ,"ception .

3.4 SCM Schedules TI,e SCM schedule can be prOVIded here, or combined with the project chedule in the SPMP. In the latter case, this section would not repeat the schedule, but would merely point to the SPMP.

The schedule for configuration management reporting , archiving, and upgrad ing is shown In

Figure' 6.7.

3.5 SCM Resources The configuration leader will require an estimated average of six hours a week to maintain the system config urati on for the fir t half of the project, and t,_elve hours a week for the seco nd half We have cho ' en no t to call o ut separately the time spent by the ot her team members o n configuration management.

3.6 SCM Plan Maintenance The project manager shall schedule a review by the CM leader of the cnnfiguration at least once every two weeks, preferably a. an agenda Item for a regularly scheduled weekly project mee tIng The CM lead~r shall review CM status, and report on the proposed detailed pro edures to be fo ll owed at code and ontegratlo n time

All project documents undergo change throughout the duration of the project. The SCMP is especiDlly sensitive to change, ho",· ever, because It controls change Itself.

133

134

CHAPTER 6

SOFlWARE CONFIGURATION MANAGEMENT

Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Stable eM

eM reviews

---4 --'. ' • Ve ndor backup plan due - -- tttH Ufftff --

eM process Im provement session

---

I

I Random IV and V audits

Figure 6.7 Configuration management schedule Due to the Importa n c~ of a stable SCM plan , all changes to this document mllst be ap proved by the entire Ctvl team In vic w of the soft\\fare de velopment o rganiza · tlon' goal to anain CMM level 5. the conR ll urati o n leader will do the following for the CM process improvem ent se sions:

• Review the effective ness of this plan • Qua ntify 10 se due to defects In this plan • Re view the effectiveness of Super CMT 001 • In vestigate the literature fo r new CM meth ods; q uanti fy the costs and beneRts of improveme nts • Investigate new CM tools • Sugges t speciRc improvements to this CM process • list the beneRts of improvements • Provide cost cstimates on effecting the improvements • Prioritize the costibeneRt ratios of all the slIg · gested chan ges

6.6 CASE STUDY: ECLIPSE CONFIGURATION MANAGEMENT IN ECLlPSE 1 Open o urce projects such as Eclipse arc developed by geographical ly dispersed e ngineers who have I

This section is bilsed on information rrom (6).

difrerent so urce code access requirements. Most are de velopi ng their own plug " ns, which are exten · sions to existing Eclipse code and fu nctio nal ity, and o nl y require access to Ecl ipse source code for debu gg in g their work. Others may want to change existi ng Eclipse sou rce code if they are Rxing a bu g, o r add code if the y are develop ing a feature . Th ese develo pe rs require write·access to Eci ipse code . Source code is managed in Eclipse using CVS (Concurrent Versioning System ), which is the de facto version co ntrol system fo r open source proj· ects. Eclipse integrates a built ·i n CVS CUI, making version control very easy to use . CVS implements a c lient· server architec ture, with the Eclipse repository housed o n a ce ntral server at dev.eclipse.org that stores all the Eclipse source code. In ge neral there arc two classes of Eclipse users as follows , I. Those that want to read andlor modify Eclipse

code but don't have write access to the reposi tory

CV

2. Those that do have write pemlissio n for the Eclipse source code and can modify and update the CVS repository . These people are call (o mmllttrs

The fo llOWing IS quoted from [7) and d~cri~ these t'Wo classes of lI<ers .

CASE STUDY: ECUPSE

Anonymous CVS For pc::opl~ who actually want to change Ecllp e code but who do not have the required commit rights In that area, all clements of the Ecl,pse proje t arc available via anonymous access to the development repo itory. U 108 anonymous acce> you can checkout code, modify it locally, but cannot write it bad. to the repository. Th,s is handy if you would like to fix a bug or add a feature . eet the code via anonymous access, do your work. and then pass the work on to a commilter for inclusion in the reposi tory. .. All committers mu t use SH (Secure SHeil ) to acce the CVS repOsitory if they wish to use their u er id and password (o.e. , If they want to write to the repository). Full CVS Developc::rs WIth commit right have individual user ids and password, in the Ecl,pse prOject development reposItory. As a committer you can use SSH (Secure SHeil ) to connect to the CVS rcpository as follows . .... Once your information is authenticated , you can browse the repository and add projects to your workspace. If you do some changes that you'd like to contribute, after testing and enswing that you have followed the contribution guideline~ , you are free to release your changes to the rcpository . Of course, you can only release changes to projects for which you have commit rights. Note that you can use the SSH protocol and your Eclipse user id to access projects for which you arc not a committer, but you will not be able to release changes.

• Major- thi s numb('r i incrcmcnlcd each time there is a breakage in the API

These points arc summarized in Figure 6.8.

VERSION NUMBERING Eclipse plug·ins use a versio n·numb""ng scheme that captures the nature of the c hanges implemented by the plug.in . Versi on numbers are co mposed of four parts as follows : Major. minor. service , and qualifer. Major. mitior. and suvir! are Integers, and qualifltr IS a stn ng.

• Minor-this number i increme nted for "extemally visible" changes • Service-this indicate a bug Ax or ot her change not visible through the API • QualiAer-thls indicates a partIcular build

OHiclal

Eclipse Code Base (CVS)

Write access with password

General User

Com miller

Figure 6.8 Eclipse configuratIon management

135

136

CHAPTER 6 SOFTWARE CONFIGURATION MANAGEMENT

Firs t develop me n t s trea m I 0.0

Second development s trea m I 0. 100 (ind ica tes a bug flx ) I I 0 (, ne w AP I hJ bccn Introduced) Thc plug -IO ship a, I 1.0 Third dev~ l op m ~ n t s tream 1.1. 100 (IOd,ca tes a bug flx )

2.0.0 (indi ates a brca kln g c hange) The plug-in . hips as 2.0.0 Mai nte na nce stream afte r I . I .0 I. I. I

Th e plug" n ship as 1. 1.1 Figure 6.9 Eclipse plug-I n version num bering ' of 2 Source, EclIpse Wilt!. I'lttPl tw1ki eclIpse OrgIVersion_Numbenng.

The exa mple shown In Figure 6.9 and 6 10, take n fro m hnp j/wiki .ec ilpse .o rg, s ho ws ho w the versio n numbe r c h anges as a result of plug· in devel o pment. The descripti o n sh o ws that bug fixcs , new

applicatio n programming Interfaces, and shipping to the community are rcAected in the numbering in partic ular ways.

6.7 STUDENT TEAM GUIDANCE: CONFIGURATION MANAGEMENT Student tea ms sho uld create a Software Configuratio n Management Plan (SG\1 P) for their projcct using IEEE Std 828· 2005 as a template and the Encou nter SCMP in Section 6.5 guidance . The rest of this section descnbes how to o rga nize fo r this task. co

'"'CI>" -

"

II:

First dey stream

Malntenonco 51'~m ef'tef

Second dev stream

Third dey stream

Figure 6 .10 Eclipse plug-In version numbering 2 of 2 Sour" EdIpse WIkI, hUP:JIWlIeJ.ecllps8.cwgNOfsAon_Numbtf1ng

SUMMARY

1. Roughl

ske tc h out your SCMP

a

Detemlme procedures for making changes.

a a

Omit tool references unless already identified o nc . See the case study fo r an example .

2. Specify what you need from a CM tool a

For class usc, maybe o nly locking and backup.

3. Evaluate affordable tool agai n t needs and budget a Commercial tools arc in wide use. a

For class use, try f,.ee docum ent sto rage Web si tes[ simple method of checking out, e.g .. re naming, can be too si mple .

4 . Finalize your SCMP Figure 6.11 Planning configuration management

Figure 6. 1 1 shows how teams can go about deci ding their configuration manage me nt met hods. When there is insufficient time to learn a CM environment, teams have succeeded reasonably well with simple Web sites, such as www.yahoogroup •.com . thatalio wdocument sto rage. Asimple checkout system is needed, one of which is to change the document type. Fo r example, when the SQAP is checked out to Joe, the file is changed from sqap.txl to sqap.jor . Alth ough configuration management applies to both documents and source code, the file-naming convention usually has to be planned separately For example, we canno t change ",yClass.java to myClass.jor without disrupting compilation . Some groups maintai n twO directo ri es. O ne contains the current baseline, wh ich cannot be changed witho ut a formal process. The other directory contains versions that arc currently being worked on . Trial CM tools or free ones such as CVS and Subversion are available. Coogle supports frce docum ent hosting with Coogle Docs and has support fo r versio n control. Be sure that your process does not rely on excessive manual intervention , and that it does not result in a bottleneck where o nc person is overl oaded. If you are co nsidering usin g a tool, be sure that the le ngth of th e learnin g curve ju tifies its use. There are many other software e ngineering aspects to learn besi des usi ng a particular CM too l. Whatever system yo u select , try it out first o n an imagined implementation . Makc sure that the process is smooth. You do not wallt to worry about your CM process durin g the impleme ntati o n phase , when time is limited. In the work world , however, professional CM tools arc a neces ity .

6,8 SUMMARY Software configuration manage ment (SCM ) is a process fo r managi ng all th e artifacts produced o n a oft'ware project, including source code, specifications, and suppo rt ing software. Planning for SCt", stans earl y in a project, starting with the Softwa re o nfiguratio n Management Pl an. It specifics the SCM activitie to be implemented throughout development and so ftware ma inte nance, such as Iden tification, change conn'ol, v."ion co ntrol , audits, status reporting, and rel ease management. Ea rl y in a projec t, artil-acts arc ide nti fied a5 config uratio n items ( I) to be stO red in a repo Itory and managed . After a C I IS reVIewed and approved It become part of a basehne and i< offiCIally managed by M pohcies. ArtdaclS go throug h ineV Itable change, being newly crea ted or modified due to ei ther error correc tion or enhancement. S M denne, actIv Ities to request, eva luate, approve o r disapprove, and implement changc, \0 basdi ncd Cis.

137

138

CHAPTER 6

SOFTWARE CONFIGURATION MANAGEMENT

A ~c l'equIJ-cmCIll of ,1, the abdllY to reproclu e Ihe precIse "alc of all I, 01 any POlf11 In lIme A VCI';lon Iltra l , '>tem (al,o kn own ", a cOllfigurallo n manaK me nl sy,tcm) au to mal ,mu h c,r th IS proce,s and provide< a rcP<"' t )ry for to nng ver
6.9 EXERCISES I. In your own wo rds , deA ne the term cOHfigliralion il,," and desc ribe Its purpose .

2. \'(Ihy is it necessary fo r compilers to be idcntiRcd as configuratio n items? Describe a scenario that illustrates whe n th,s is l1l'cessary . 3 Describe the four goal of configuratio n l11anageme" t in your own wo rds. and explain why each is important.

4 . If you are devel o ping a software app lication usi ng an incremental process, at what points would you minima ll y c rea te baselines) 5. Explain the difference bel'ween change co ntro l and version control. 6 . Agile processes pro mote conti nuo us integration. which results in branching and merging at very frequent in tcrval (as ofte n as every few hours). Describe one advantage and disadvantage of branching and mergi ng so freq uentl y. Describe one advantage and disadvantage of branching and merging less frequentl y. 7 . As mentioned in the T eam Guidance sectio n (Sectio n 6.6), forsmaliteams it may not be necessary to utilize a n aut omated conRguration management syste m. Describe the process you would follow to perfo rm branch ing and merging wit h out such a sy tem . 8. Research a configuration m"nagement system such as Subve~ion or CVS. Describe how it implements the seven SCM activities listed in Section 6 .2.

TEAM EXERCISE For the team exercise. consi der as a group how you wil l perform it, check the hints below, and then carry out the assignment.

eM Plan Produce a software configuration manaBeme nt plan for your team project using IEEE tandard 828· 1990. The case >tudy should guide your team. but your document will be mo~ SPCCIOC, I't'Rectlng t~

BIBUOGRAPHY

panicular resources avaIlable to you. Do not include material unless it contributes to the document's goals. Avoid bottlenecks and unnecessary procedures. Include procedures for what to do if people cannot be reached and deadlines loom. Bdore you begin . estimate the number of defects per page the team thinks it will discover during the fi nal review. Keep track of and report the time spent on this eHort by individual members and by total team effort . State the actual defect denSity (average number of defects per page). Assess your team's effectiveness in each stage on a scale of 0 to 10. Summarize the results using the numerical results, and state how the tcam's process could have been improved. Criteria, I . Practica lity , H ow well does the plan ensure that docum ents and their versions will be secure,

coordinated, and available7 (A = plan very likely to ensure coordination and availability) 2. Specifics, H ow specific is the plan in terms of suitably naming places and participants7 (A = no doubt as to what engi neers must do) 3. Process as essment and improvement, To what degree did the team understand the strengths and weaknesses of its process, and how speCific are its plans for improvement7 (A = full , quantitative understandin g, with plans for improvement very speCific and realistic )

Hints forTeam Exercise Do not fi ll in sections that arc as yet unknow n; add only parts that you are confi de nt of being able to implement within the semester. Make your plan realistic. For example, don't state that "all other team members will review each contributor's work" unless you are reaso nably sure that this ca n be done within the probable constraints oi your project. It is too earl y to make any assu mptions about the architecture and des ign of the application .

BIBLIOGRAPHY 1 8cllagio, David, and T

Mliligon. "Softwa re Co nRguratlon Management Strategies Jond IBM Rational C lea rnsC' A Practical

Introductio n,· IBM Prcss/PcMson pic, 2005, p 7 2 "IEEE Standard for Sortware Conflguralio n Manogcmcnt Plans: fill Srd 8 28 - 2005 . August 2005 . 3 "IEEE StJndard for Software RcvlC' ....·s and Audits," JEEE Std lo n - l OOS, August 1008 4 Ha~~, Anne M J, "ConMJlt'tJ llon Mand91'n1(r1' Prr"cipl,I and PractICc," Addlso n.Wesley, 2003, p. 25 S "Systems and so hwau: cn8tnt't'nn~-So ft''A'art' Ide cycle procc'ic;;cc;;,· IEEE Sid 1220 7·1008 Second edItion. January 2008 , p 69

6 Eclt psc, http}I""",,'W ecl Ipse 018 (acC('sscd AuA'U'i' 13, 2009 ] 7 Echpsc-. hup Jlwww eclipse org/eci lpsc/ [Jccc ..scd Augllst 13, 2009 )

139

principles of Software project Management I: Organization, Tools, and Risk Management

The Software Development Ufacycle

•

How are software development prOjects organized?

•

What is an appropnate team size?

•

What happens when teams are geographically distributed?

•

What tools and techniques are available to support projects?

•

How do you handle risks?

•

How are projects managed In practice? In student teams?

Figure 7.1 The context and learning goals for this chapter

SoltlDa" project ""'H"9c""Ht is the process of planni ng . organIzing. and monlto nng the development of a oftware prOject from its Inception to its completion . It incorporates a set of tool s and technique practIced b the person or people responsible for a project during every phase of develo pment. The person respon ible I the proJcct ",aHa9" (a tenn usually u cd for larger projects) or tca", lcad" (a tcnn typically u cd for smalkr

PRINCIPLES OF PROJECT MANAGEMENT I: ORGANIZAnON, TOOLS, AND RISK MANAGEMENT

• Customers are sddom sure 01 what they want. •

ustomers change their requirements and plans may not be updated.

• It i hard to estimate up front Ihe magnitude of the effort required . • It.s hard to coordinate the many requirements , the design elements corresponding to each requirement , and the correspondi ng code. • There may be unforeseen technical difficulties to overcome .

• It is not easy to maintain constructive interpersonal team dynamics . Time pressures cause stress, and [earn members have differing opi nions.

Bur rbm ohslaclts co .. all br oV(rcomr/ Figure 7.2 SOme challenges of software project management

projects or teams). Sometimes the perso n responsible is called the project manager and has o ne or more subordinate team leaders. In all cases, these people practice project management. C ritical to the success of a project is the organization of the project team . Many different organizational structures are possible . each with a set of strengths and weaknesses. It is very difficult to deliver a quality, full y accepted softwa re application o n time and within budget. Figure 7.2 gives some of the main reasons . Software project management addresses these issues by incorporating a range of activities and structure into a project , including project orga nizati on, {ools, and

support, management of project risks, project estimation and scheduling, project docume ntatio n and tracking. These are summarized in Figure 7.3 and explained in this chapter.

• Organization o

How is the project team structured?

• Project Management Tools o

What tools are available to support project mana gement?

• RJsk Management o H ow arc risks to the project's success identified and mitigated ? • Estimation

o

How long will the projec t take to o mplete and how many resources are reqUIred ?

• Scheduling o What are the different parts of the project , in what order will the y be completed , ,nd who will work on each part] • Documentation and Monitoring o How j~ a project plan c rea lcd , a nd how i, the plan monito red to c n
Fleur. 7.3 What does software proJeCI management add ress?

141

'42

CHAPTER 7

PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT I: ORGANIZATION, TOOLS, AND RISK MANAGEMENT

T he rest ot Ih" ch"p ter foeu,,,s o n the o rga nizatio nal stru ture" too ls, and rISk management that support proJ Ct managc ment T he next hapt er, whl~h ompletes our d,scuS
7 ,1 SOFTWARE PROJECT ORGANIZATION The way," whic h a compan y is o rga nized has a direct bearing on how proJeu, are executed, Some ompanlcs

rganlze around th c lf proJec ts. In these companu.:s pro)cl.l managers have t(rcat autonomy, with

team member di rec tl y reporti ng to tht'm. O ther o mpanie orga",ze arou nd functional areas such as devci o pment, marke ting, fi nance , and so on , givi ng projec t manage rs respo n ibility for monitoring and reporting o n proje t progress. O ther compan ies empl oy an organization that mixes both of these In ge neral, there are three type of orga niza ti o nal Slnl c turc : projtCf-orjwttd, j 'Hlcliotl -oriw ttd , and m(lfrtx . W e examine each of

these," the ect lo n that (ollow.

7.1. 1 project-Oriented organization In projecl-orien ted organiza tions , personne l arc o rga nized around the projects of t he compa ny. When a new projec t is initia ted, a project manager is assigned to head up the projecl. O ne o( their first tasks is (orm ing the team , whi ch is made up of new hires or people who are finishing o ther prOJects. The project team comprises people from multiple functional area such as marketing, fi nance, development, and so o n. Team members report to the project manager, who is thei r ult imate boss. They are attached in all ways to a parti cular project, and have no o rganizational affilia tion with peo ple o n other projects . This type o( o rganization is illustrated in Figu re 7.4. The principal rca on to o rganize around projects is to develo p loyalty to the project rather than to the functiona l manager [ I]. Since employees are dedica ted to a si nglc project, they can focus their ti me and energy o n that project. Th is increases the predi ctability o( sc hedul es as there IS less chance of team membe rs spending unschedul ed time o n other projects. H owever, th is type of o rganization has the potential disadvantage of isolat ing engi neers professio nally and redUCi ng the amount o( reu e and profeSSional stimulatio n between projects as a resu lt o f this isolat io n.

Senior Manager

Prolect Manager

Project Manager

Project Manager

Project Team (Mar1<etlng, Finance, Sohware, OA)

Project Team (Mar1<eting, Finance , Software, OA)

Project Team (Mar1<eting, Finance. Software , OA)

Figure 7,4 project-orlented organization

SOFTWARE PROJECT ORGANIZATION

President

I

Finance

Marketing

Oevetopment

OA

Finance

Managers

Marketing Managers

Sohware Managers

OA

Finance

Marketing

Personnel

Personnel

Sohware Engineers

Managers

OA

Engineers

Figure 7.5 Function-oriented organization

7 _1.2 Function-Oriented Organization F","ction-orirnttd organizntiolls arc a very common type of structure. A compa ny is organ ized IntO groups based on their fu nctions , such as marketing, Anance, development , QA , and so o n. Th is type of structure is dlus trated in Figure 7.5 . In this form , functional orga nizations have projects, but the scope of their prOjects IS lim ited to the boundaries of ,heir group responsibilities. As an example, if a software functional group is working o n the user interface (UJ ) software of a larger software product , only the UI software being developed is considered the current project fo r that group. Functional managers in this kind of organization act a project managers. re pon ible for the" projects as well as the hiring, Aring, a nd salaty of their team members. Managers may be responsIble for multiple projects. TI,is structure has the advantage of clear and responsible decision· makin g c hannels However, because managers arc responsible for multiple projects , their knowledge of proje ts is nece sari ly limited by their available time. In addition , they must wei gh carefully the needs of each and e nsure that they don't favor one over the other. If one of their projects is falling behind schedule, for example , they may shift personnel from another project to the lagging project . ThIs may cause a delay," the other project.

7 _1 ,3 Matrix Organization A-latrix organization, are a c ro s between project - and function -oriented organizations. They try to gain the advantages of both project-onented and function -oriented organizatIOns. In a matrix orga nizatio n, employ ees belong to a functional g roup (e.g ., marketing, engineering ) but arc loa ned to projects based o n the" expertise_Thus, a software eng,"eer's supervisor- who" responsible for evaluating that person-would be a member of the softwa re engIneering fun tlonal unit . Within ea h project o n which the person is ,,'orking, howl>ve r, he or she would be supervI sed by a project leader Eng,"cers arc u uall y In vo lve d o n a regular baSIS with one project, sometimes two, but ~e ld om mo re. FIgure 7_6 illustrall><; the reponing srru lure of a matfl x organlzatron In lh" .tm lUre, a prOject manager" aSSIgned to each project For example, Oscar Man IS' mcmber of the marke ting depanment alld a<signed to the airline r=rvati on proJec t, headed by Al PruItt For all proJe t-related aCtiVItieS, Oo;car repom directly 10 I

1U

144

CHAPTER 7 PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT I: ORGANIZATION, TOOLS. AND RISK MANAGEMENT

Project

Malrix

rgani zll tlon

.-'"oc:

-v c:

Airline reservation project

Bank accounting proiect

Molecular analysis project

Fluid mechanics project

AI Pruitt Full lime

Quinn Parker Full time

Ruth Pella Full tIme

Fred Parson< Full tIme

Marketing dept Oulia Pitt, mgr)

Oscar Mart Full time

Pete Merrill Full time

ue More Half tIme

Elton

Engineering dept Ooe Roth, mgr)

Hal Egberts

Proiect manage me nt dept

Mar~ton

Full time

::>

Ll-.

•

•

•

•••

Mary Ericson

Ben Ehrlich

.

, .

." •

• •

Len Engels •

••

•••

•••

Figure 7 .6 Matrix organization

However, Oscar's boss is Julia Pill , a manager in the marketi ng department. Julia would consult with AI when doing performance apprai sals. An advantage to this approac h is that project managers maintain focus and have responsibility for the success of the .. projects . Functional managers are focused o n the content of their functional area and can more easi ly coo rdinate the efforts of their g roup members, some of whom may work on multiple projects For example . the software manager of a database group might recogn ize that multiple projects have similar requirements for accessi ng a database . The manager can coordi nate a software design that is ge neral enough to be used by multiple projects. We will consider team size next.

7.1.4 Agile Organization Agile teams consist of technacal people. The .. principal no ntechnical contact is with the customer. Stili, function s of the kind mentioned above conti nue to be required. An example is Anance . Every o rganization needs to understand the costs and benents of projects. Agile teams become adept at estimation , and so nnance people-who are not part of the agile team itself-have good shon ·term data and forecasts but are required to be agi le as well. This is because agi le teams are not plan -driven . n,e upshot is that the nontechnical people must base their work on good but relatively short-term data.. They perform their work by interacting with the customer and WIth the development team .

7.2 TEAM SIZE To be precise, a "team" is a group of people who work closely together on a daily basis. One mIght imagin~ that the appropriate size of a team depends strongly o~ the size of the application (large team for large applications, etc.) but th IS is not so . Large teams (not necessarily groups-keep the deRnitoon of "team' in mind) have the advantage of div iding the work Into many pans but the disadvantage of communication lhat i

TEAM SIZE

I Effectiveness per developer

Developer communicales regularly with 11 people.

Developer .r~-

O~--

communicates regularly with no one.

I

3

7

I Number of people with whom developer must interact frequently

Key:

0; engineer

f"tgUre 7.7 Options for team size showing extremes

time-consuming and error-prone. A significant aspect of such communication is the need for tea m members to explain what they are doing. Having to keep forty people up-to -date on a daily basis , for example, requires a lot of meeting time. In his ciassic work , Th, Mylhical MnH -MoHth [2]. Fred Brooks pomted out that adding !><,ople to a failing project invariably makes mailers worst . In other words, for many projects the disadva ntage of increased communication channels, which are panicularly heavy during the learning process of new team members, may often outweigh the advantage of divisio n-of- Iabor. What is the optimal size of a team ? This is a mattcr of trading off the benefit of haVing many helping hands against the cost of communication among them . The optimal size depends on the nature of the projec t, Routine projects can usually benent from larger team sizes because a lot is understood about what each person should do. Let's consider extremes for a typical project, shown In Figure 7.7. The vertical axi reAccts the effectiveness per developer. Experience of the authors and others shows that the number of develop,:rs with whom each developer needs to interaa on a regular basis should normally be between three and seven. (Humphrey (3) suggt'Sts four to elght.). Formal studies on the effect of team size on performance are rare. At one extreme shown in Figure 7.7, the developer works without interactmg regularly with anyone on an individual basis. Although no time i spent on communication, such isolation typically results In misunderstandin!." of what is required of that developer, leading to a relatively low level of effectiveness. At the other extreme, the developer has to intern t regularly with so many tndiv,duals that there is not enough time left to perform development itself, again resultinG in relative ineffectiveness. In panicular, true "regular communication" could entail speaking with someone for an average of approximately two hours a week_ If an engincer were In regular communtcation with ten others, then fully one half of his time would be spent communicating, leavmg only half of the week for hIS tndivldual contnblItion. Project organizers, whether planning twenty -person or hundred-person projects, have to a count for thiS. Figure 7.8 Illustrates these potnts as follows. If you pick a team size such as three and draw a venicalline, it into,..;e ts the blue area between two values of 'effectiveness per developer ' TI,e inexactn""s of this measure leads us to talk in telms of ranges rather than absolutes. We arC interested in picking a team ,izc that yields the most effiCIent work on a per-developer basis. Figure 7.8 shows this occumnlj between team siz"" of about three and seVen As the number of participants in a prole t grow>, an orilanlzation where everyone is a peer b<:comc ImposSible to usc because thft number of commu nica tio n llilk (between all of the pairs) grow . With the square of the number of panicipants Three people entail three Itne, of o",munl 3tion, four pt'oplc cntatl ix, nyC people ten, six pee. pic fifteen . " people rcqlttre (II - I) + (II - 2) + ... + I = II (/I - 1)12 hnes of Olnrllun lcat lon . This grows With the square of H ne hundred people would have til participate rCHttlorly In 4,950 lines 11 communlcationl One alternative for laflje pro, e~t' 1< the orga nizotilln ,huwn til l' lgttrc 7 _, In whic h peN

1U

146

CHAPTER 7

PRI NCIPLES OF SOFTWARE PROJECT MANAGEMENT I' ORGANIZATION, TOOLS. AND RISK MANAGEMENT

r Ellectiveness per developer

Dovoloper communlcalos regularly with 11 people. Communlca llon lime outweighs /)Onefils 01

Approxlmat" optimal ra ng"

Interaction.

"

Developer communlcales regularly wllh no one. No communlcallonllme is lost. bul developer is too Isolated and has no help.

,• 7

Number ot people with whom developer must interact frequently

Key:

0

= engineer

Figure 7.8 Range of optimal size for beneficial interaction

Team of leaders

Figure 7.9 A peer organization arrangement for larger projects groups remain small , and one member of each group is deSignated the communicator with the other peer groups . This type of organization tries to preserve the benefits of small teams. but it harnesses the large number of people to bui ld a large application . Note that team leaders have double the amount of communication rime than non · team leaders.

7 .3 GEOGRAPHICALLY DISTRIBUTED DEVELOPMENT Independent of whether a team IS project-oriented , fun ction -oriented, or m.trixed, team members maY be either collocated or geographically distributed . The latter prese nt a unique et of challenge Managers naturally try to make usc of worldwide programming talent to optimize costs and improve quality , a process sometimes called oifsbonn9 . The Internet and collaboratIon tool have mad .. offshonng increasingly practical. per-hour costS of remOle progra mmers are traded off against the ommunlcation

n,e

GEOGRAPHICAllY DISTRIBUTED DEVELOPMEHT

•

me ofR e arca

+ -

ideal for group commun Ica tIon labor rates suboptl1nal

• Same city , different offices communIcatIon fair reasonabl y good communication

+

+

-

common culture

labor rates suboptimal

• Same country, diflerent cities

+

common culture

-

communication difficult

• Mul ti -cou ntry

+

labor rates optimal

-

communication most difficult

-

culture issue problematical

,• Figure 7.10 Possible locations of distributed team SOc.rce. GraphICS reprodUCed wtth penTlfssion from COrel

problems incurred by physica l remoteness . TIlls trade ·ofl depends large ly o n the degree of need for continual interaction wIth the customer. Options lor remote tcams are illustrated in Figure 7 10. Bob Schudy , a colleague 01 the authors who has extcn ive experien e wIth offshon,,!:, lists its advantages, • Work can be done around the clock • Good ·quality work is available • There is potcntial for cost savi ng He lists the lollowing a, dIsadvantages . • Incre'hed ddfi ulry lor the offsho re per<;onnel to understand reqU1remenlS • The lack

01 IOIomlal " hallcr" thaI an smooth progre"

• Tim d,fference< lor (VIrtua l) meellngs

1. 7

148

CHAPTER 7 PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT I' OflGANIZATION, TOOLS, AND RISK MANAGEMENT

Costs 01 OHahorlng

® Communications hampered ® Cultural dilteronces ® Increased projecl

Benefits 01 OflshQriog @ Lower oltshore labor rales

© Work continues during

U,S.

management coslS

night time

Figure 7 ,11 TO offsilQre or not to offshore •

urprises in ski ll CIs

• Travelmg ills, e pec lall y for westerner; in the East Schud y includes Ihe following in his remedies for these disadvantages, • Meet face -to -fuce initially and periodical ly , • U se various media (c ha t, VO IP, conference calls, etc.) . • tv'ake sure there is strong on ite management'.

o rne of the trade -o ffs that arc accounted for in deciding whether and how muc h to offshore are shown in Figure 7 I t _ Figure 7 , IllS an e xample of how a project can be distributed among "ncar-shore" (same country; remote locatio n ) a nd offs ho re , Fi gu re 7 . 13 shows how tasks coul d be allocated in a distributed development project _ The particular allocations are shown as exa mples o nl y, and were quoted by a group at IB M _ IBM lis ts the methods in Figures 7 14, 7, t5. and 7, 16 for dealing with distributed development The word · reqUlrements" in the Rgure refer; to what is needed about the process, not the reqUirements of anyone application_ CDD stands for geographically distributed development. UML is a deSign notatio n covered in this book.

--., !{l

---!:!.'" '" ~

-'"

'0

u

w- e.

.-5 <:

--!{l'" 0

'-' =>

<: 0

'-' ~ <:

c

E '-' 0 c 't:: => .,

--

,0 -

-.,'" --., <: <:

8. E 0

U

-., <:

E >.

-.,c0

0

-g

--

0

a..

Figure 7 .12 Example of how tasks can be allocated In a distributed development project . Souru 18M, c.opyr18t't (j ;l lntcmallonal BuSiness MacJllnos COrporation, rtPrInted WIth pOfmlSSlOr\, httDJlwww3 software ibm comlibn'd,./'plltl,~~'¥'" weblgvkleslGC34 2500 00 IXl'

GEOGRAPHICALLY DISTRIBUTED DEVELOPMENT

In -house team

Remo te subcontracto r

• Business analysis

• Testing on pre· release builds

• New feature development and related testing

• Testing maintenance rc1ea es of current version

• Requirements: capturing, doCUmenting, and

• Build and deployment

managing

• Selected project management

• System architecture, modeling

• Mainta ining current version

• Project management

• Unit testing components modiAed during maintenance

• Creating and modifying requirements for maintenance

Figure 7.13 An allocation of tasks SOUrce IBM, COP'Il'IgTlt

,~

Intemaoooal Business Machines COrporation. reprlnle
aprOSIcammaranollndex.html.

- -

---~~-~

REQUIREMENTS United leams despite diverse languages and cultures

-IBM RESPONSE

• Enable brow<er-based access to Ihe same knowledge base for all teams • Provide easy access 10 guidelines, template and tool mentors based on underl yi ng best practices • Visually communica te discipline workAow and interactions wilh the Unined Modeling Language (U ML)

Reduc tio n in work transfer issues

• Imple me nt a fTamework based on core process workflows fro m business modeling through deployment • Use a phased approach to software development that detads execution for each disci pline

Easy-to-navlgate pro · cess that is not over· whelming for users

• Jump-slart planning and gel new team members up to speed fast with knowledge assets and guidance

Demonstrated progress toward expected return on investment for CDD projects

• Track metrics th roug h out the project life cycle

AbIlity to assess and manage distributed resources efAc lcntly

• Maintain a broad and deep understanding of an organization's capacity, skills inventory, total workload and resource de mand

• All ow users to create personal process views that are central to individual needs • Provide intuitive naVIgation wi th a browser- based interface

• Report on variance measurements and adjust process to ach,eve desired results • Track project progress and quality through quantitative analysis

• Optimize ski ll usage with resource planning to align mission-cntical resources with h,gh-priority projec3

Figure 7.14 Tools and methods for distributed development, IBM. 1 of 3 SOlI"

I:BIA., copyngtlt (' internatiOnal ~5 MaChines Corpotillon, reprinted wltn pet'mlsslOn. nnp JI'WItWl softwatO iOOl C

\': eblpArx:lGC34'25CO<X:I pdf

1_9

150

CHAPTER 7 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT I: ORGANIZATION, TOOLS, AND RISK MANAGEMENT

I cmo nstrated proBreSs tow."d expeLl<'d return o n II, ,,'lInerll for ,I D prOjects

o

Abrlity to assess and manage dr stributed resources efAcrently

Scalable projec t

o

Track metncs throughout the projecl life Lycle Report on vorian e measurements and adjust proc~s to achieve: dcsl~d ,eoul~

o

Track project progres and quality through quantitative .oalysls

o

Maintain a broad and deep understanding of an organiUltion's capaCity, skills rnventory, tOl.1 workload and resource demand

o

Optimize ski ll usage with resource plannrng to alrgn mission-critical resources with high-priority projects

o

Centra lize sensitive schedu le, budget and resource data while allowing secure, high -performance access anywhere in the world

management so lution o

Consistentl y executed processe

Implement native scheduling, resource loading and ·what-if" scenarios that avoid performance issues by integrating with third·party scheduling products

• Capture and reuse successfu l GOD engagement models, work breakdown structures and workAows to ensure execution against IT governance requirements and best practices • Enable reusable project templates and task guidance based on a proven process, so teams never have to start planning from scratch

Accurately tracked labor costs for in ·house

• Accurately track labor expenses and budget for time and materials or fixedbid resources

or external re ourers

Figure 7.15 Tools and methods for distributed development, IBM, 2 of 3 SOUrce; IBM, copynght ~ InternatIOnal BuSiness MaChines corporation, reprinted with permisSIon. htU>:t/WwW3.soltwure.it>m convlbmdVpub/softwaretrabOflall weofgl"udeslGC34-2500-00 pdf

-

-

REQUIREMENTS Quick and easy Implementati on to start col-

laboratin g in days, not mo nths

Consolidated work arca where team s can more effectively com muni ·

care and co ll aborate on project issues

IBM RESPONSE • Facilitate discussions, set up chat rooms and combine team calendars with ready-to-use templates • Leverage out-of-the box functionality that users can customize themselv~ • Centralize installation on one server • Create a centralized location to post and share project documents that can be viewed and modified by other team members • Share team member project calendars • Track feedback from other team members • Enable the creation of forums and partiCipation in threaded discussions • Allow team members to share files in real time via Web conferencing

Figure 7.16 Tools and meU,ods for distributed development, IBM, 3 of 3 sou('~ 10M. eopyngnt

Intem800n81 Business MachInes coworatJon. repr1otl!(l with pmml$:Sloo. nttoJMww3.50ttwate Ibm.

webigWoeslGC3H5OO
THE TEAM SOFTWARE PROCESS

IBM RESPONSE n demand

omnlunl .

carion optIons for di . tributcd team mcmbe"

• Let users know which team members are available for collahoratlon through IOregrated presence awareness • PrOvide lOstant messaglOg fo r real . time, ~~on · to·person communication • Leverage browser·based confcre nci ng to share presentations and meeting materials

b.!,ty for all di para!e project membc~ to e· curdy conneCt to the team workplace through the intranet, Interner o r mob.!e devi es

• Enable full-featured browser-based a nd mobile access to presence , instant m saging and team spaces

Figure 7.16 (Contmued )

7.4 THE TEAM SOFTWARE PROCESS Te.am s avoid reinventing procedures thar arc common to everal sohwan: devci opment proJects- O rgan iza .

tions create procedures or gUi delines in adva nce for tea ms to apply . \'(fans Humphrey's Tm., Soj,","" Proem '" CTSP) [3] does this in a detailed manner. The TSP proVIdes gllidance to gTOUpS o n each of the prole t development phases aftcr requirements analysis. Humphrey has reponed encollraglng re lilt in estabhshlng matunty goa ls and procedures for software teamwork. The objective of [he T P are sho wn In Figures 7. 17 and 7. 18. Whether or not a team uses the TSP, much can be learned from It. TSP share, ,everal charactenstlcs with agile teams, sllch as the autonomy of teams . TSP is heaVIl y metric·oriented , and alt houg h ag .!e me th ods are not, they do take seri ousl y the velocIty measure. The TSP's emphaSIS on team inillative and bottom -up interacllo n encourages an In r<'ased degree of profe sionalism among so ftware eng inee r For exa mpl e, H umphrey Slates that it is unprofcs<1 o nal fo r enginee~ to prOVIde management with sc hedules that ca nno t be accomplished , cvt'n ,,,he n requested to do so. He counsels negotiation In such a sitllatl o n The phdosophy here IS sllll1lar to that for agdc project'

• Build self·dlrec ted tea m ~ • 3-20 c ngln ce~ • establtsh 0'''' goa l\ • es tabltsh ow. process a nd plans • track work •

how manager\ how 10 rn anagt: (came;

• <-oaeh • motrvaLe

• sustain peak perforllla" e

figure 7,17 Objectives of the Team SOftware Process, 1 of 2 SotHt;B GfIlPh'Cl r8Qfodu'~ 'HIm r~ f,om COt

I

151

152

CHAPTER 7 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT I: ORGANIZATION, TOOLS, AND RISK MANAGEMENT

•

cierate • make

MM Improveme nt

/\'IM 5 "normal"

• · Provlde Improvement 8U1de llnes to hi gh-maturity organizations"

• "Facilitate university teachin g of industrlal .grade teams" Figure 7.18 Objectives of the Team Software Process, 2 of 2

Professlo nalt sm, Humphrey reminds us, involves an oblt ga tio n to Serve society responsib ly, In addition to serving employers Also nOleworthy is the TSP's emphaSIS o n " oaching" by managemen t external to the team. Managemcrrl I expected not simply to give orders and specify deadl ines, but to provide guidance, tools, and ot her required resources In this respect, TSP is beller able to handle teams with varyi ng degre'!s of experience and kills. T Pi orga ni zed around Iterations of the waterfall sequence; It requires that the team "launch" each iteration at a mee ting where a number of predeAncd Issues are addressed. Humphrey provid(~ numerous detailed scripts and checkl ists to support the TSP. Figure 7. 19 su mmarizes these points regarding TSP The phases can be iterated severa l limes, requiring several launches. Launch is lies to be settled are shown in Figure 7.20. Humphrey recommends that the items listed in Figure 7.21 be produced by each phase launch. Much of thi is covered by procedures and IEEE documents discu"ed in this book .

7 .4 .1 Introductory Team Software Process (TSPi) Formal training for TSP is beyond the scope of a stude nt team working together during a softwa,e engineering course . For exa mple, it requires t he already extensive Personal Software Process. The TSPi is a sca led·dow n versio n of the TSP designed to At in an academic semester. The TSPi roles arc /tam ltadt!', drutlopmt>llmaHagtr. pla""",g maHagtr, quality/proem ",."ag" , and support "'all.g". In the TSPi the "support manager is responsib le for obtailling and 'upplying all the tools and environments, such as compiler., fo r ~xample. Humphrey describes a spcciRc emester.long schedule for the TSPi , consisting of three it~rations ( h~ ca ll s them "cycles") as hown in Figure 7.22 . The Idea of this schedule template is that data obtained from each cycle is used to estimate the metncs for the next cycle. Cycle 1 is comparatively long because it includes the team's first progression through th~ stages. It is intended to be a "minimal function workin!: subset of the final product." Cycle 3 is long enough to

• Team initiative • Bottom -up interaction

• Professionalism among software engineers • Negotiate schedules • Emphasis on "coaching" by management Provide guidance, tools . and other reqUired re ources • PartiCipants required to be PSP trained • Organized around iterations Each requires a "launc h" • Numerous detailed scripts Figure 7.19 TSP praC1ices

SOFTWARE PROJECT TOOLS AND TECHNIQUES

o o o

Process to be u cd QuaillY goal Manner 01 tracking quahty goa l

DHow tca m WIll make decision s

o

What to do if qua lity goals no t aHai ned o

o

What to do if plan no t approved o

o o

Fallback posHio ns

fallback positio ns

Define team ro les As isn tcam roles

Figure 7.20 ISSUes to senle at TSP launch Source. Humphrey. Watts S . "InUOCIuction to tfle Te.lm Software Prorv ss (The SEJ serk!:s reprodUCed WIth ptlllll ssaon from

iO

SOftware EngJneenng)." Ac1C!rSOO W """ey. 2000, P 496 GraphICS

wei

wrap up the job completely n, is Icaves a reiallvel y sho rt m,ddle cycle "Strategy" (phase t 01 an Ileralion ,n Figure 7.22 ) rerers to the overa ll way in wh"ICh th e team wdl go about budding Ihe cycle ,n ques ti on Th" requires a hi gh.levei discussio n 01 the requirements, a conceptual design, and an overall assembly plan For the components. The results are then made into the concre te plan (phase 2), the wnllen reqUirements (phase 3 ), and so on .

7.5 SOFTWARE PROJECT TOOLS AND TECHNIQUES Projec t manage rs and teams use a variety of 100is and techlll Q.ue to manage a soFtware proJect, such as A E tools, budd vs. buy decisions, language selectio n, deC ISion making w,th t"age , and the u e of project variables . Each is described In the sections that loll ow.

I. Writte n tea m goa ls

2. Defi ned team roles 3. Process development plan 4 Quality plan 5 Project' suppo rt plan co mputers, sofrware, per o onei , etc 6. Overall development plan and schedul e 7 Detailed plan lor each cng,neer 8. Projec t risk assessment 9 Project StalUS report Figure 7.21 Artifacts to be produced at launch .Sour", ~. Watts S. "",t/OOUCUOn to tJ1e- Tetam SOftware Proc: c ss CTh9 5£1serIeS N'1 Software EngJneenng)," AdOII5OI'j \~. 1tXIO. p. 496

1S3

154

HAPTER 7

PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT I: ORGANIZATION, TOOLS, AND RISK MANAGEMENT

Week

--

-

1 1 1 1 1 1

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Delivery

Cycle 1 launch

• Cycle 2 launch

Milestones

<dele 3 launch

• I

1. Stralegy

2. Plan

Iteration 1

3. Requiremenls 4. Design 5. Implemenlalien 6. Tesl 7. PeSlmenem

Iteration 2

, I

Iteration 3

•

I

,

1. Stralegy ....

11. Slralegy.... I •

Figure 7.22 TSPI cycle structure (Humphrey) SOurce Humphrey, Watts S. "Introduction to the Team SOftware Process O'he Sfl Senes In Software Englneering>," Addison·WE '!"/. 2000. P 496

7.5.1 Tool Selection A numbe r of vendors e ll lools and e nviro nm e nts for he lping e ngi neers to devel op software applications These arc so me lim es referred to as computer·aided software engineering (CASE) loo ls, and o metlmcs as "integrated loo ls " to.·lany are packaged with o r connected wi th de velo pmenl environments such as Microsoft's VI ual Stud io Th ey ma y also be a coll ec li o n of tools obta ine d fro m unre lated ou rce Figure 7 23 lists some pos ible lools. They Include scheduli ng loo ls sllc h as M icrosoft Project . co nfigurat io n manage ment tools such as Sou rce Forge or C VS, requiremenl< manage ment lools uch as Rat io nal' Re qlllsitePro. design representation . t)' plca ll y With U ML too ls such a Borland' T ogether, code- budding tools like Am , and tesling Sllpport lOols sllch as Ralio nal's T estMa nager. Large projecls Si mpl y ca nnot be managed with out at leasl some of these co mpone nt ; In particular, configura tion manage ment too ls arc indispensable

chedulin g

•

•

•

•

•

•

•

•

•

Managing requirements

•

•

•

Drawing deSi gn especially UML

onfigll ralion management

• • •

Code build

• • •

Testing te st case manage ment automation

Figure 7.23 Potential CASE 1001 components .soc.vu. Graphics reprOd!JC8CJ wu:n p; e:mission 'rom cent

TOOlS AND TECHNIQUES

BUi1dcosl ! Bwcosl

Comments multi-year costs nol accounted for

- : : : : thousands)

Supplies

$ 0

•••••••••••••••••••••••••••••••••••••

• ••••••••

FirSI-jlerson perspeclive $ 5

$40

••••••••••••••••• ••• •••••••••••• •••••• • ••• • • •••••••••••• • •••••••

$ 0

•••••••••••••• •• •••••• • ••••• ••• • ••••• ••••••••• •••••••••••••••••

3-D

$10

Putchase Ajax engine

$ 1

Ajax

has Ihis fealure

. ............................................ "

Cuslomlze Ajax applicalion

•••••••• • •••• ••• ••••• •••••••••••••••• • ••••••• • • ••• ••••••• • ••••• • ••••••••• ••• ••••••••••••• •••••••• • •••• ••••••••

Lighl refleclion

$15

$10

TOTALS

$30

$51

"""

Cuslomize Ajax applicallon

•

BuI Id, do not buy

Figure 7.24 Example of build vs. buy decision making for a video game graphics engine

7.5.2 Build or Buy Decisions Tools and applications Ihal promise to help or form Ihe basi. for new applicalion are often available For example, in planning for a Web ·based auclion app lication , we would compare the purchase of ready ·made auction software with developing our own app licalion fTOm scralch Typicall y, we delay thcse deci ions untd the requirements are known, bUI they arc discussed here si nce Ihey are a part of proje I management A rational manner for approaching Ihis kind of decision is 10 make a IIsl of expenses and to eSllnlale the magnitude of each alternative. An example is shown in Figure 7.24 , ",hich iiiustraies the decislon ·making process concerning the purchase of Ihe (hypothetical ) Ajax graphics sofrware thai would help us enhance Ihe graphics of our video game. Figure 7.24 reduce'S [he decision to a comparison of numbers, which is a common way of deciding among altemarives. In other words, II computes the bottom line wllh and withoul purchasing Apx' sofrware. It breaks oul the relevant desired graphics features and estimates Ihe co I of cacho Ajax Implement> Feanlre I. firsl.person perspective, completely (i .e , conlinually d, plays Ihe view of Ihe scenc fTOm Ihe player's perspectIve). On Ihe Ofher hand, Ajax does nOI do a complele Job of handling 3·D (Feature 2), so we WIll have to pro&""m 10 compensate for Ihis. Finally, we need light rcnrclion (Feature 3), where the scene gives Ihe impression of a lIght sOllrce shinIng onlo ilfrom a si ngle direction. Ajax helps here, but we will have 10 perfoml considerable programming to make II work The ",ble in Figure 7.24 could be an appendix to Ihe projcci plan or Ihe Software Design Document. A more realistic version of the lable would com l>are Ihe com on a muillycar ba IS, and wou ld In lude mainltnan e expenses. The more features we are reqUired to implemenl ourselves, the less attracllve Ihe purchase Many deciSIon ca n be framed in a cost compamon form like tillS Mamlalning a wnllen re ord of deciSIons such as quanlilative budd -or· buy trade·offs helps In commlllll aling Ihesc decI> lons to Ihe learn and oth~rs . The form can be refined and updaled as more mforma lio n becomes known , and II aIds postmortem and pfocess Improvemenl.

7.5.3 Language selection Allhough Ihe Identlficallon of an Impl ememallon language or language IS freque ntly a de I~n de I"on , lanljuagcs arc of len Idcnllf,ed ncar the belllnnlnK of Ihe prole I OI1lCl lmeS Ih,s dec ",on ",trJI!{hdo"".rd a< when Ihe organlZ3110n mandale, a I.nguag· , or whell a language" Ihe on ly one apoble of IInpit:menllllj.: Ih~

155

, S6

CHAPTER 7 PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT I: ORGANIZATION, TOOLS, AND RISK MANAGEMEm

Factor

Bencftt of

Weight (t - / 0)

Iknefl! of Language 1 1 10 10 = besl

I to 10 = bHt

una....'

1

Internet -friendly

)

-

8

2

Familiarity to deve! ormcnt tea m

8

-

3

9

Compilatio n speed

s-

2

8

7

3

-3 .. 8 + -8 .. 3 + -5 • 2+

-3 * 2 + -8 .. 9 + -5 * 8+

,-

Runtime speed o n processo r p

Score

-1 * 7 =

65

1*3 = 121

-

--

Figure 7.25 Example of method for deciding language choice requirement . Sometimes, however, the implementation must be chosen from several alternallves. A common wa y to deCide among alternative is to first list the factors involved , and then to give factor each a weight (measure of 'Illponance). After that , each alternative I scored relative to each factor Calculations are then made that produce a total score for each alternative. Figur~ 7.25 shows examples of factors and weights that could enter onto suc h a de termination . The weig hts are faclOrs in arriving at the botlOm line . For example, the score fo r language I is 1. * 8 + J! .. 3 + .2. • 2 + ! .. 7 (weights underlined ). Dec' sion -making tab les such as this arc no t subs titutes for mabn g judg me nts, they merely decompose large deCISions (e g., wh at langua ge 10 c hoose) into smalle r o nes (e .g ., Java is mo re Web-friendly than C + +). Suc h decompositio ns provide mo rc s tabili ty , but th e conclusions that they provide are se nsitive to the weighting c hose n, the factors selec ted, and th e judgments made . Their results should be compared wi th commo n se n e co nclusio ns.

7.5.4 Decision Making with Triage Execu ting projects is frequently an overwhelmin g experience . For example , a "to do" list of wants and needs accumulates qUickly, g rows during the project more tha n it shrinks, a nd can easi ly induce a feeling of futility. The natural way to deal wi th this is to prioritize. A complete prioritization is frequently overwhelmed by events, h owever. For exa mple, if we have a list of 100 things to do , a nd time for probably only 20 of them, then It is a wa te of time to meticulously order all 100. Triag, can be useful for situations like this. Instead of a le ngth y decision process, triage requires o ne to make no more tha n two decisions about each item , as shown on Figure 7.26. O nce this has been performed, items from the "do at once" category a~

• Among top items in importance') If so, place it in

I

categoty

• Otherwise, could we ignore without substantially aHecrlng project} If so, place it in • Otherwise (do not spend decision time on this) Pia e in

category

Figure 7.26 using triage In project management

SOFTWARE PROJECT TOOLS AND TECHNIQUES

Number of ....eks before del/very

Schedule Quality

Number of

requirements

Cost Functionality

Defect count

Number of engineers

o

Figure 7.27 Variables available to the project manager

carried out unt il they are e xhauste d (if eve r). and the n we move o n to the middle list, and so o n. When necessary , items can be prioritized with in their category. The benefit of this is that little time is wasted In splitting hairs o r wonderi ng about the exact o rder of ac tio ns that wi ll never be performed . As reported in Bu,i"ts' W"k (4), for example, triage teams were used by Microsoft in combing through bug reports durin g the debugging of Windows™ 2000. Next , we consider what rools the project manager has at h and to steer his o r her prOject to success.

7.S.S project Variables To achieve project objectives, the project leader has fo ur va riables that conceivably can be manipulated.: co,t, schdul" q"ality. andju"ctio"ality. As Figure 7 .27 suggests, this is something of a balanCing act, because there are man y trade·offs among these four attributes . For example, if the project leade r is asked to spend less time producing the application (affecting sch,dul, ), he or she has to negotiate for reduced requirements (affecting j,,"cllo"ality ), Increased defect expectations (affecting quality ), or inc reased labor (affecting co,t; assum ing that mo re people ca n be used effectively) in order to offset the reduced time. Project management deals constantly with trade ·offs among these va riables. T o make the best decisions, we quantify these trade·offs whenever we ca n. One wa y to VISualize them is by means of a "bulls ·eye" di agra m, suggested for this purpose by Humphrey. In a bulls·eye dia gra m, each of the va riables IS plotted by means of an axis originating at the cente r. This is s hown for the cost parameter in Fi gure 7 .28 . The axes are drawn symm e tric all y re lative to each o ther. In the bull s·eye d,a gram shown in Figure 7.29, there are four variables , so that they form 90· deg ree angles.

Parameter: Projected cost (S) Unfavorable

Iaroet : $70K ... __ .............. "_.. Favorable

MOIl teyprabl, : $OK ...... -.. ~

f1cure 7.28 IntrOductJon to bull·eye figure for project variables

157

158

CHAPTER 7 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT I. ORGANI ZATION, TOOLS, AND RISK MANAGEMENT

, ProJocted cost ($)

... ' ...... - Tarael: $70K

Taraet: 100%

\ ...,\ Pro1ected , Projected I > '-00% (unct/onallty - - - ~S=8'itl;::'SIif.led5-+---~,..-- schedule ( % requirements (fatal weeks to saUsfied) ,.,.. _.., comp/ele) '.'.

\• Targel: 30 wl<s

Taraet: 4 defectsIKloc ... .................... . Projected quality (de/eel densllyj

I Figure 7.29 Bulls·eye framework example for project variables The va ria bles h ave to be arran ged so that o n eac h of th ese axes, th e origill is th e most favorablt va lue, and th e ta rget va lue , m ark ed o n eac h axis th e same di sta nce fro m the o rigi n, fo rm ing a quad ri latera l. (If there we re five va ria bles, they wo uld fo rm a regular pe ntago n, etc. ) Fo r example, o n the "projec te d functio nality' ax is, th e o rigi n de notes "man y mo re than the deSignated requirem e nts sa t,sfied ," while the unit mark represents " I 00% of the re qu ire ments sati sfied ." TI,e actual values co uld lie o utsid e the po lygon if they exceed goa ls, as shown in Figure 7.30 . The status o f a project can be visualized using the solid po lygon o bta ined by joining the values on the axes and fi lling ,n the res ulting polygo n. The m o re the resulting po lygo n li es within the Origi nal regular polygo n , the he alth,e r th e projec t . The example project sh o wn in Fi gu re 7 .30 f
• Projected cost

--- -----

Taraet100%

,

Acblfl:

•

.' ................... Target; $701<

90%

, •, ,

Projected' , (unctlonallty' - - - -

Aaa/: 1.5

ProJ«ted schedule

,,

---

•

,

•,

qu.llty

Figure 7.30 Bulls·eye figure for project variables on a particular project

---

Tal!!8\: 30 wI<s AIifwI: 20 . .

RISK MANAGEMENT

Organizational I . The team may not have the reqUired Java skills to exccute the job on time because several of them have no t used Java in a bus: ness environment. 2 . We ma y lose a team me mbe r. Technical 3.

An off-the-shelf database mana ge ment system may not be versatil e e nough to cover the types of operations required of a vIdeo store.

4.

We Intend to u e Web services, but no o ne in the team has used these before.

Figure 7.31 Example risks in video store a pplication

7.6 RISK MANAGEMENT All projects invo lve a degree of risk. These arc issues that ca n potentially cause problems such as a delay of the schedule o r increased project costs. Figure 7.3\ shows some risks from the video store example. We try to confront risks as soo n as possible rather than waiting fo r them to confront us in the proces of build ing the application . Th is is ca lled risk maun9"",,, I. and it consists of the activities in Figure 7 32 . Perhaps the hardest part of risk manageme nt is iden ti Rcatio n , because it requires imagining parts of the process that may not seem at first to harbor a ny risks. Once a risk is identified, it is important and vety useful to express the risk with as much precision as possible . For examp le, "a team member may get sick" is too vague a descriptio n. Much bette r would be "sick ti me will exceed the company norm by 50% due to an unu ual number of youn g parents in the team ." Figure 7 .33 illustrates a way to thinking about ri sks, It shows two obstacles to a project . We ge nera l.ly dea l with risks wi th o ne of two di fferen t stra tegies. They arc cOllq.usl (such a building a traffic ligh t at the roa d ) or nuoida"" (e.g ., routing the path around the h ouse). These two strategies arc Illustrated in Figure 7 .34 . Teams develop a plan to address eac h risk and assig n an individual who sees 10 it that the plan is carried out. The c halle nge here is to develop a concrete plan and avoid ge neral statem e nts such as "we will alil ea m Java: For exa mple , we ca n address the "inadequate Java ski lls" risk mentio ned in Figure 7.3 \ by conquest : 'Tom , Sue, a nd Jack wi ll pass level 2 Java cert inca tion by Dece mber 4 by attending a Super Education Serv.ces

I. Identify risks by imagini ng all worst -c ase sce narios: lasts for approxi matciy

Am thtrd of project.

2. Analyze each risk to understand it potential impact on the project. 3. Typically too man y risks give n time . H e nce , prioritize .dentiAed risks

lO

e nable foc u on most enou .

4. In dealing with each risk, c hoos< to conquer or avoid it. Co nquering 0 risk mea n In vesti ga ting it and takIng action so thac the eve nt docs not mate rialize Avo ldin\;\ mea ns c h angi ng plans so that the I sue never occurs.

5 F,nally , develop a pla n to retire each ri k

Figure 7.32 The main risk management activities

159

160

CHAPTER 7 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT I' ORGANIZATION. TOOLS, AND RISK MANAGEMENT

Risk 2: House blocks path

Risk t: Road blocks path •

••

•

• • • •

Project start Figure 7.33 Retirement by conquest or avoidance risk examples SOurce CraPhlcs reproduced wrtn J)efmlsslon rrom Corel

Intermed iate Java cour ·e." Alterna ti vely, the risk can be retired by avo idance: "Use C ++ instead of Java" (assuming that the team is skilled In C+ +). A reti rement strategy for the "Web services know ledge immature' risk IS to set up a couple of sa mple Web services and write access code for key Video store functions that use them . If the resu lts are satisfactory, we will have empl oyed risk reti rement by conquest. Table 7. 1 illustrate o ne way to perrOm) risk prioritization . First , the risks the mselves shou ld be deSCribed fully . The priority de pends o n fac to rs such as the likelih ood of the risk and the seriousness of its impact on the project. A h,gh,prlorit y task has a low.pri ority ",,,.lur because people usually rerer to their "highest priOrity" a priority number I The more expe nsive it is to deal with a risk. the lower its priority. In particular, when managing a risk becomes a very large amou nt of work, we may be better off not working on it

2. Retirement by avoidance

Risk 1

1. Retirement by conquest

Figure 7.34 Retirement by conquest or avoidance SOcxee GraohJC:S reorOCluced wltn pc:.j.lkslon from COf~

Table 7.1 A way to perform risk prioritization ~

No. Title

Estimated likelihood of occurring (L : l · l0 with 1 low est IIke-lihood)

Estimated impact (1:1· 10 with 1 lowest Impact)

Estimated cost of managing (M: l-l0 with 1 lowest cost)

priority number (lowest number handled first) Retirement Responsible (11 - L) . (1, - n . M plan person

1

Insufficient Java skills: See note 1

8

9

9

3 . 2 . 9 = 54

See note 3

Jared

2

WebSeMces immature: See note 2

3

7

2

8 , 4·2 = 64

See note 4

Jen

•

•

Target

completlon date 10/ 15

8/3

•

'"-

V>

"

3:

i

m

3: m

!i

...... ...

162

CHAPTER 7 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT I; ORGANIZATION. TOOLS, AND RISK MANAGEMENT

In ad an ~ at all, but simpl y dealing wllh the ,,'ue In volved when It aCluaJl y arlS", I or exa mple. If the o nly wa to anticipate a mk "to Om li1J t an expen Ive Imulatlo n, thell we may simply have to acce pt the risk Note I 11,c n
7.7 STUDENT TEAM GUIDANCE: ORGANIZING THE SOFTWARE PROJECT'S MANAGEMENT This section describes how the student team o rganizes for the development task, prOVide a hypot het ical account of interactions among students, and gUides students in producing a Software Project Management Plan.

7.7 .1 Team Guidance

Student Team Organization

Student teams are usually organized as peers. T o make pecr teams effective. the team leader encourages consensus but keeps the chedule firmly in mind, making clear and timely deCisions when requi red. In ruden! teams, team leaders tend to mtervene too "ttle. Meeting drag 00 unreaso nabl y in the quest for consensus or agreement , and the team leader is not experienced enough to make a resoluti o n. Being Arm Without alienating team members is a valuable skill. A ke y to this IS en uring that team members' opi nions are respectedwhether adopted o r not. Fi gure 7.35 lists the steps for orga nizing a team . particularly a student team . One effective management arrangement for a team is to pair up developers by haVIng them work together some-or even all-of the time. The lalter is called pair programmi"g . Another way is to deSignate team members as leads for the project phases with a backup for cach oT ypi ca ll y, the lead and the backup work together, o r the backup serves as a continual in pector. ready to take over the lead role If necessary The project arrangement shown in Figure 7.36 is deSigned to make each perso n the backup fo r the actiVity on which his or her primary activity is dependent. Once a projec t leader has settled the procedural aspect< of team organization . it IS time to consider what really counts with team members: how they feel about what they are doing. If a person belongs to a motivated and well -organized team . he will probably enJoy his work and the team wtll probably produ e a good product. People are motivated when they are respected and arc engaged in an activity that the feel ennch them . Part of each member's Job is to create those conditions for himself and others The project leader creates a well -organized project by settmg schedules and limits, with the team' as=ment. In partl ular. when it comes to meetings the issues In Figure 7.37 can be u<,ak privately to the

STUDENT TEAM GUIDANCE: ORGANIZING THE SOFlWARE PROJECT'S MANAGEMENT

I.

Sdect team leader. Responsibi lllies: o o

e n ure that all project aspects are a tive All all gaps

2. Designate leader roles and document responsibilities. team leader: proposes and maintains . SPMP configuration manageme nt leader: ... S MP qualoty assurance leader: . .. SOAP. STP requirement manage ment leader: ... SR.S design leader: .. SDD implementation leader: . " cod, bas, 3. Specify leaders' responsibilities . o

propose a straw-man artifact (e .g., SRS, design)

o

seek team enhancement and acceptance

o

ensure that deSignated artifact is maintained and o bserved

o

maintain corresponding metrics if applicable

4. Designate a backup for each Icadcr Figure 7.35 One way to organize a team

individual. If no significant change is observed in that person's behavior after about a week, the proJect leader should confirm th ~ team's concern and th en di scuss th e issue with the instructor. Instruc tors will either remove the individual from the team or discuss wa ys to app o rti on credit accordingl y.

7.7.2 Team Guidance Team Meetings One activity regularly requircd of project managers is to hold meetings. Figure 7 38 lists som e good mee tin g practices from which all team members can benefit. The ite m s marked with a si ng le asrensk sho uld be perfo rmed before the meetIn g . Since gro ups are not particularly good at c reatin g artifacts from sc ratch (especially designs ). it is far better for someo ne to bring to the meetin g a tentative ("straw · man") ve rsio n of the artifact to form the ba sis fo r di scussi on . For example , the design leader brings a t
backs

up ...

Team leader Configuration management leader Ouality assurance leader Requirements management leader Design leader ImplementaJlon leader

Figure 7.36 A wwy to back up leaders within a learn

163

162

CHAPTER 7 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT I; ORGANIZATION, TOOLS, AND RISK MANAGEMENT

In ad an e at all , but '1"'1 Iy deallnll wIth the IS~ue involv d when It a tuall y aro \e, I' or example, 01 the only wa to antIcipate a ri>k i, to co n,lO~1 tan expemive ,imu lation , lhen we ma y ~ Impl y ha ve to aLeepl the r"k. Note I The rosk 0< that the leam duc, nOt have enough ,k oll, n java 10 handle the programmIng requored by tillS proJe t wIthin the lime requIred N o te 2. TI,e ri k I that a lthoullh Web erv lce lechno lollY "a good ChOILl', tec hnIcally spcak,ng, It IS new to the Industry at the tIme of thIS prolect , and ItS Immaturoty ma y reatc dolf'c ult,e, N o te 3. jen, Os ar, an d Alf ho uld pa,s level twO java c
7.7 STUDENT TEAM GUIDANCE: ORGANIZING THE SOFTWARE PROJECT'S MANAGEMENT This section describes how the student team o rganizes for the development task, prOVIdes a hypothetic
7.7.1 Team Guidance

StudentTeam Organization

Student teams are u uall y o rga nized as peers. T o make peer teams effective, the team leader encourages consensus but keeps the sc hedule Rrmly in mind, making clear and timciy deciSIons when required . In tudent teams, team leaders tend to intervene too little . Meetings drag o n unreaso nably in the quest fo r con ensus or agreement, and the team leader i not expe rienced e noug h to make a resolutio n. BeIng Rrm without al,enating team me mbers is a valuable skill. A key to thi s is e nsurong that team members' opi ni o n ane respectedwhether adopted or not. Figure 7.35 lists the steps for o rga niZ Ing a team , partIcularly a student team . One effective manageme nt arrangement for a tea011 IS to paor up developers by haVI ng them work together some or even all of the time. The latter is ailed pnir progmml.i"9 . Anot her way is to designate team me mbers as leads for the projec t phases with a backup for each . TypIcally, the lead and the ba kup work togethe r, o r the backup se rves as a continual inspector, ready to take over the lead role If necessary. The project arrangement shown in Figure 7.36 is desig ned to make each person the backup for the actIvity on which hi s o r her primary activity is de pe ndent. Once a project leader has settled the procedural aspects of team orga nization , it is time 10 con Ider what really counts with team members, how they feci about what they arc doing If a person belong to a motivated and well·organized team , he will probably enjoy his work and the team will probably produce a good product. People arc motIvated when they arc respected and arc e ngaged In an activit that the ' feel enriches them. Part of each member's Job is to create those conditions fo r hIm elf and others. The proJe t lead« crcates a well ·orga nized project by sellIng schedules and limits, with thc Icam's agreement In partIcular, when it o ones to mee tings the issues in Figure 737 ca n be usefu l In the case of student leams, ""tv'" (o"'/lb""o" i, often . majOr problem · som~ team member> m3\' fc-el that a member IS not contributing enough . A team member who feds th" wav ,hould dISCU<, the I su~ WIth the project leader If there is ge ne ral agreement about tl"', the proje t leader ,hould spea ~ provatcl ' to the

STUDENT TEAM GUIDANCE: ORGANIZING THE SOFlWARE PROJEcrS MANAGEMENT

I. Sd«t [cam leader.

Rcspons,b,l i tics: o o

en . ure that all prOject a pects arc active fill all gaps

2. Designate leade r roles and document responsi bilities. team leader. proposrs and 'MI"la;., .. . SPMP configur
3. Spedfy leaders' responsibilities . o

pro pose a str
o

seck team e nhan eme nt and acceptance

o

ensure that designated artifact is mai ntai ned and ob erved

o

maiorain correspond ing me trics if app licable

4. Desi gnate a backup fo r each leader Figure 7.35 One way to organize a team

individual. If no significant change is o bserved in th at person's be hav,o r aft r about a week , the prOject leader should confiml the team's co ncern a nd the n d,scuss the issue with the Instructo r Instructors will either remove the Ind ivi dual fro m the team o r di cus ways to apportion cred it accordingl y

7.7.2 Team Guidance Team Meetings One activity re gularl y req uired of project mana gers is to hold meetings. Figure 7.38 list some good meeting prac tices fro m which all tea m members ca n benefit. The items marke d with a si ng le asteri sk sh ould be performed before the meeting. Ince groups are not partic ul a rl y good at creating artifacts from sc ratch (e peCiafly designs ), it is far better for omeone to bring to the meeting a tentative {"st raw . man"} versio n of the artifact to form th e basis for d iSCUSS io n. For exa mple , th e d e ign leader brings a tentallve design , o r the team leader brin gs a tentative work breakdown. The ve r ion s h ou ld no t be overly speCific , because there must be plenty of room for input b y the me mbers.

Team leader Configuration management leader Quality assurance teader backs

up .. ,

Requirements management leader Design leader ImplemenlaUon leader

Figure 7.36 A way to back up leaders within a team

'63

,~

CHAPTER 7 PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT I: ORGANIZATION, TOOLS, AND RISK MANAGEMENT

• Develop an . genda In ~dva n ce of mec lIn g, with everyo n 's 'I!rccmenl. • SCt lime limits (or meeting a a whole and for each a!le nda item . Allow exIra lc n or Aft.en mInutes for unanll clpated Items. • Designate SO meone to tak e minutes, ilt Icas t for a l ion i tems.

• At mcetll' g, begin by brieOy reviewing the age nda a nd tIme limits. • De,ill na le o meonc

10

walch lime and warn of time lim ils.

• Insist o n o ne person speaking at a time . Listen to people, even if their idea seem ourrageous. (Probably aren't ) • Move unproductive d i cu sions offline. Figure 7.37 Planning and conducting meetings

Man meeting participants, but especially students, compla in that meetings last too long WIthout acco mphshing e nough. \'(rhe n the approximate time fo r discussio ns is ag reed to in advance, however, members tend to focus o n th e issues te be resolved, and meetings ca n be quite effective. Decid ing when to all ow (urt he r discussion and whe n to break il o ff is a duly of Ihe learn leader. The keys to doing this are whether the discu sion is productive, and whether lhe discussion of the present topic is preventing the di scussio n of more impo rta nr o nes, g iven the time remaining. II is al so the leader's task to ensure that the discu sion remallls focused and that a conclusion is reac hed. At times, the leader must step in and make a decisio n, because co nsc n us is nOI always possible. The member recordin g ac tion items also records decisions take n. Th,s should generall y be do ne 111 a crisp form-minutes are meant primarily to remind everyone of the decisio ns made. I. "DistrIbute Start time, e nd time, and agenda with approxi mate times. o

li st impo rtant items fi rst .

2. ·Ensure that "straw ·man" Ite ms arc pre pared . 3. Slart o n time 4 . H ave somco ne record action items.t 5. Have someo ne track time and prompt membe rs. 6. eet agreement o n the age nda and timing . 7. Watc h timin g throughout, and end on time. o

Allow exceptio ns for important d iscussio n.

o

StOP excessive discussio n; take ofAine.

8. Keep d iscussio n o n the subject. 9. ··E ·mail ac tion items and decision summary.

·in advance o f mCelln!!

lactions membe" must perform

Figure 7.38 Team guidance team meetings

··aflcr meetlO l!

SUMMARY • I . (;(,t agreement on agenda and time allo atlon

2. (;(,t volunteers to: ... record dcci ions laken and actIon items . .. watch time and prompt members 3. Repon progres on project schedule _ 4. Discus strawman artifact( ) 5. Discuss risk retirement -

•

10 tnUl

x mill

fO min

6 . , 7., ... < more agenda items> (I nclude metrics and ['rocess improvement]) n Review acrion items

5 mUl

F'lgUre 7.39 Specifying agendas

One good management practIce is to create and follow agendas for meetings. Some items, such as concise status reviews, arc almost always appropriate. Risk retirement (cove red in Section 10.4 ) sho uld be a mandatory agenda item at most meetings during the first third of the project. Metrics and process improvement are sometimes appropriate topics. These are discussed after a phase has been completed, not necessarily at every meeting. An examp le of a generic age nda is shown in Figure 7.39.

7,8 SUMMARY Software project management is the process of planning, o rganizing , and mo nitonng the deve lopme nt of a software project from inception to completion . A project is typically headed by a project manager, who IS responsible for the daily project activities. Companies can be organized in severa l different ways, each havin g an effect o n how a project team is organized and run . In a projtct-arir>lttd organization , people arc organized around the projects of the compan y. Every employee is assigned to a proJect, which is their primary focus. In aJ"ncilon-aritlltrd organizati o n, people ~long to a functional group such a.s marketing or sohwar-e development. Each functional gro up has its own projects centered around their area of responsibility. Managers assume the ro le of project managers A mnlnx organization is a cross between project· a nd function ·orien ted organizations. Employees belong to a functional group (e .g ., marketing , engineering) and are loaned to projects based o n their cxpertise They directly repon to their functional manager, who is responsible for directl y supervisi ng the m Thcy also indirectly repon to the project manager, who IS respo nsible for the daily actiVIties of the project. The size of a project team has a direct effect on the success of a project. Team that arc large ca n d ivide tht work into manageable pans, However, large teams have the dIsadvantage of requiring communication that IS time -consuming and error· prone_ Expenence shows that the optimal number of people WIth whom a person needs to interact with o n a regular basis hould norma ll y be between three and eight. Not all prOject tcams arc colloca ted W,th the advent of lIs'"g rem ote developers , project teams ma y be split across conti nents Th, s is known as off hOrlng . There arc many advantages to u ing remote tcams, IIc h as COSt savi ngs and the benefh of qu.),ty work . H owever, the re a rc di sadvanta ges to be over o me, slic h as time zone differences, cu ltural differences, and potential communIcatio n ddn lIltles. Se tting lip reglliar fa <' · W· lace m«tmgs and having strong o n 'Slte manageme nt arc key elements to mak,n g offshOring work . SM Watts Humphrey's Ttam oJllQart Procm (TSP ) deAnes a
165

166

CHAPTER 7 PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT!. ORGANIZATION, TOOLS, AND RISK MANAGEMENT

in n:" , ed dcl!'"cc of rrofe",onall<11l among 'oftW"I'C enHineers . A.. an c~am pl , Humphrey stale. that It IS lInprofes 'ional forengin ccrs 10 provi d~ managemenl wil h ,e hedul e.that ca nnot be accompl,shed , even when ,..,que,ted to do so. ProJe t m""ager and team< carry Out many lask< a, part of Ihelr job, 'ncludlng project scheduling, onhguration management , reqUirement< man.gement, drawIIlH de"gns, building code, and testing As mu,h as po
7.9 EXERCISES I. a. De cribe in your own wo rds the st.ructure of a project.based organization , and explain how it promote the successfu l delivery of software. b. Name twO lo ng· term disadvantages of a project-based o rga nization. 2. a. Describe in you r own words the structure of a function·based o rganization , and explain how it promotes the successhtl ddivery of softwa re. b. Name two lo ng. te rm disadvantages of a hillctlo n·based orga ni zation. 3. a. Describe in yo", own words the structu re of a matrix organization , and explain how it promotes the successfu l delivery of software b. Name two lo ng·tem, disadvantages of a matrix organization . 4. Write a paragraph explaining why adding people to a project docs not ne essaril schedule and may worsen it .

Imp ro~

•

It

5. Co nsider a project team you have been a m ~ mber of, either as part of a student leam Or in industry De'cribe the o rga nization of Ihe tcam, and des ribe in sufAc ient detail two a peets th~t worked well and two that did no t work well 6. Consider a softwa re prOjec t under devel op m ~ nt , with half of the e n 8 lnc~rs In one \lOle zone and the o th er half in another time zone twelve hou rs away H ow would 011 recomm .. nd the pro)CCt

BIBUOGRAPHY

t~am be organized) Describe two challeng~ that need to be overcome due to the time.zone

difference.

7. a. Explain how a bulls·eye diagram can help visualize the progress of a software project. b. Suppose you are managing a project that has the following goals, ·Cost: lOOK · Schedule, 12 months · Quality , 12 defeetslKloc . Fun·e tionality, 90% requirements implemented Draw a bull -· eye diagram that shows on ly one of these goals being met or exceeded. 8. Why plan for risk identiAcation and retirem ent when developing a project plan) In a paragraph or two, answer thi s in your own words.

9. Describe a kind of project under which risk identiAeation and retircment would pro bably off. Explain.

"01

pay

10. Suppose that your team IS tasked to implement a system that provides Web· based books. l1,e application is intended to execute on desktops, be downioadable, and be automallcally upgraded over time via the Internet. You arc to assume the following · i. The team includes employees who are based at a new offshore Site. ii . The application is to be rcady in a month . iii . Preliminary plans call for a Java implementation on a PC model that is due 10 amve in two weeks. No one in the team is ,.ell versed in Java . They all know C. + we ll. You arc concerned about the risks associated with items (i) and (II i) above. Explain the kinds of risks these are , your speCific responses, and the kind of soluti on YOll arc propo ing. II. You have been tasked to build a ystem for managi ng online DVD rentals. Descri be four plausib le

risks and indicate how you would retire them. Be as concrete as possi ble in describi ng the ri sks

BIBUOGRAPHY I Heldman, Kim. "PMP P'O)'C1 !vt4M#Cfflml Pro/mlo",,' Exam Sillily CIl/dr," SybexlWll t'y Publ lshlO~ Inc .. 2007 p. 17. 2 8rooh. Frederick P., '7bt My/b,eDI A-tan·M01'Irh Essays on SojlWilte Ett9,"cmn9. Altnll'crsary EJ,hon Addl;;on.\X!c<;ley . 1995 3 Humphrey , Walts S .. "1,.,,011111, 110" 10 ,bt Tcom Soilll'llft Proem (1lH Sfl Smd '" ojllN " E"9t"(m"'9'~" Addl ..on · \'(I~lcy, 1000, p 496 .. Iht' MOlht'r of All So hwilrc Pro,ec ls,· BIA.5i"lH \Vuk, Fc:bnlJry 22 . 1999

167

principles of Software project Management II: Estimation, Scheduling, and Planning

....nnlng

The Software Development LIfe Cycle

•

How do you estimate the cost of a sohware Job?

•

What are good ways to go about creating a project schedule?

•

What does a Sohware Project Management Plan look fike?

•

How are prOjects planned in practice?

•

What are good ways for student teams to plan their proJects?

Figure 8.1 The context and learning goals for this chapter

This chapter explaIns the methods that prOject managers use to e timate the ost. of a prOject and way to
COST ESTIMATION

1.1 COST ESTIMATION The proc:<:sS of esrimating project co

(i.e., for Axed ca pabilitle , quality level , and schedule) often starts at the inception of a projcct and continues even after coding has begun . There are severa l speciAc techniques used to estimare cost that are described in the following sections. Before doing so, however, let's examine how plecise we can expect such estimates to be. fS

8.1.1 Estimate Precision When a project is ini riated , the team ca n typicall y have o nl y a vague idea o f its cost. TI,e more we learn about the requirements for the product and the more desig n we perforn1 , the more precise we ca n be about its cost. This is illustrated in Figure 8.2. Since complete precision is a practical Impossibility in most cases, a range is a good way to express projected cost. There is always a need to estimate a 'ball park range" from a summary requiremenfs statement , hence the cost estimation following conceptualization shown in Figure 8.2. Our assumption here is that the goa l consists of auaining a set of capabi lilles rather than starti ng With a fixed amount and asking what capabilities ca n be implemented for that amo unt (a related but different process). The fourfold <sri mation error shown in Figure 8.2 is from a study reported by Boehm [ 11. For an application that will eventuall y cost $ 100,000, for example, estimates made after the application's concept has been developed can be as low as $25,000 and as high as $400,0001We use various techniques to sharpen our esti mate of a project's cost as earl y as possible , which amounts to reducing the height of the vertical lines In Figure 8.2. O nly at the latter e nd of implementation can we have complete confidence in our estimates. (The estimates are far less useful at that time, h oweve r, si nce most of the fu nds will a lready ha ve been spen!!) It puzzles some people that we ca n eve n begin to think about the costs of a project without detailed requirement.s , but this is a common practice in o the r Acids. For exampl e, one can gain a ro ugh estimate of the cost of building a h ouse without any desig n or detailed requirements. One can use rules of thumb such as

$4

Rough range of cost estimates after _ - - - <'(lOceptualization phase. Assumes evenlual, actual cost of $1 ConceptualIzation phase

$1

$3

$.25

_ _ Requirements analysis

I

$1

Design

I

Rough range 01 cost estimates a ller requirements analysis $2

I

$1

Implementation I lntegrationITeat

Fleure • .2 Range of error in estlmatlng costs narrows as the project progresses

I•

169

170

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II: ESTIMATION, SCHEDUUNG, AND PLANNING

"" u,e, In th IS area O,t about $ 100 per "ll'are foo t to budd: dnd so J I ,C)OO. ,(]uare. foot house w.II c.ost about $ 100,000 A good way to appro. " proje t cost estima ti o n at the very early sta~e' of a project IS to develop c,t ima te in severa l independe nt way, a nd the n combin e th e re
8.1.2 Estimation Methods Cost esti mation methods fo r agile projec ts, described in ectio n 8. 1.6, focu o n esti mating rhe upcoming itera tio n ("sprin t" in scnlm te rn,s), based o n its requ ired user story o r stories, as well as experience from past itera tio ns. These arc small ·sca le estimates but it is part and parcel of the agil e philosophy that large projects arc composed of sma ll deliveries. Now let's turn 10 estimatio n of projects in the la rge that are not necessarily agi le in whole or in part. Whether o r not o ne actually uses the methods described, they do contain many hard ·won ideas that ca n be con figured for various situations, including variations in ag de estimation . Figure 8.3 sho ws a typical road map for the earl y estimatio n of project co t a nd duratio n. The next section shows an example of the usc of lines of code and past projects. The function point methodo logy and COCOMO (Construc tive Cost Model) are explained below.

8.1.3 Estimating Lines of Code without Function Points This section discusses ways to estimate lines o f code at a very earl y stage, well before any design has been performed. O nce desig n work is performed , the me thods are based o n the parts of the design and become far more precise, as ind icated in Figu re 8.2. Several estimation methods , no tabl y the COCOMO and COCOMO II model , de pe nd o n the number of lines of code. "COCO MO " stands for Boeh m's "Constnlc tive Cost Mo del" [ 1]. At the very earl y stages of a project . COCOMO may not sou nd very useful because coding is a long way off when o ne is in the project planning stage . By compari ng the product with other products, however, esti mating hnes of code may well be feasible . For example, we could estimate that our current sate li ite co ntTOI job is comparable to our last satellite job, which requi red 3 millio n hnes o f FORTRAN . H owever, our currenr job has the add itio nal requirement of being able to mo nito r hurricanes. It may be possi ble to roughly e timate the ize of th is additional piece based on other hurrica ne trackers (700,000 lines of FORTRAN , for example). When impicmentation languages change, mdustry ·standard language conversio n factors arc used.

I. Usc comparisons with past Jobs to e timate cost and duration d irectly or to estimate line of code and / or Use function point metho d to estimate lines of code.

i.

Compute unadjusted function points.

ii.

Apply adjustment process.

2. Use lines of code estimates to compute labor and duratio n usmS

Figure •. 3 A roadmap for estimating the cost of a software project

(II) fo nmula .

COST ESTIMATION

Orglniutions wonting above Cap;lbillty Maturity Models level I must be able to record the person hours Ind duntion of the pans of jobs. In the ab ence 01 such data, we would have to compare our Encounter "dec Illme, for "xample, with other game . It is difficult, impossible even, to obtain data directly from comp;lnles other than one's own, although trade publications and general industry studIes sometimes provide pI~1 data. For example, we may know from industry announcements that "BugEye Inc." has worked on its rw: iI same for two years, The announcement may even mention a number of programmers. Such data is suspect, however, sin e companies regard their development knowledge as a corporate asset, and commonly or underrepon numbers as the case may be. In the absence of historical data , it may be necessary to compare the project with related projects, (simulations, lor example, in the ca e of our video game). Let's say that we have very little experience programming gam~, and some experience programming simulations and Java. Our lines-aI-code estimation may have to be something like the follOWing : lance wrote a nongraphical simularoon of a simple queue in C. + , which required about 4-8 pages of code_ At about 30-50 non -comment lines pcr page, this totals 120 400 lines. We will assume that Java requires the same number of lines. The first commercial release of Encounter has 4-15 such queu~ and 30-90 additional components of comparable size to make It interesting, so that yields between [( 120 lines) x ( 34 components)] minimum and [(400 lines) x ( 105 components)] maximum as our range, or approximately 5,000 to 42 ,000 lines of code. The use of graphics multiplies the effon by 1.5 to 4, depending on the degree of sophistication , so this gives us a range 01 1.5 x 5, 000 to 4 x 42 , 000 = 7 .5 to 170 K-lines (thousands of lines) of code. (NoI" The case study in this book encompasses a prototype. which is far less ambitious than Ihe version o n which this estimate is based.) By documenting such data o n a spreadsheet, we establish a baseline, and we ca n then sharpen our estimates as the project goes forward . Note that the range 7 .5 to 170 K-lines is consistent With Figure 8.2, in which a 16-fold range in es timate is expected at the conceptualization stage. The preceding calculation is a bottom -up approximation , sillce it estimates the cost of the whole from the cost of the pans. An example of a top -down approximation follows , lIsi ng indu try data (or, preferabl y, historica l data from the organization performing the work). Suppose we know that a very good video game required the servIces 01 5-20 expert programmers for 1- 2 years. Since we can invest only 1/ 10 of the amount that was invested on that ga me , we WIll assu me that ours will ha ve about 1/ 10 of its ca rability. A suming 5-25 lines of (fully testedl) Java code per day, this yields ( 1/ 10 capability of th,,(amous game) x (5 - 25 lines per day ) x (5 - 20 programmers) X ( I - 2 years) X( 48 - 50 weeks pcr year) x ( 35 - 60 hOllrs per week ) ~ 4_2 - 300 K - lines of code This range is different from the bottom -up «timate obta illed previously , but it helps to grollnd our ideas about the job'~ magnitude, Since the method" ed this lime is quite different . Free estimation tools, 'u h a, those at www.con
8_1,4 Function Points SUrtlllg In 1 ~79 WIth All recht (2 ), th e mo re (undame nt,,1 nOli on OfJ""Cllo" pO;III. wa> developed to assess the size of a prOject Without ha Ving to kno w II, de
171

'72

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II; ESTIMATION, SCHEDUUNG, AND PlANNING

durat.on by cOl1l parison with th e fun t.on pOint values 0 1 ot her proJects . Functton POtllts arc a\tra<.t.ve .n oncept , s",ec they try to /let to the hcan 0 1 a future produc l" ca pability H owever, It take. a grcat deal of rra ti e to appl y them in an accura te and o", .Stcnt manner

8.1.4.1 Calculating Function Points Funerion pOint calculat. o n compri ses th ~ following teps '

Function Point Step 1 Ide nttfy th e luncltons (e .g ., "retrieve ," "dISplay") th at the app lica t.o n must have. The Inte rn a ti o nal Function Point U ers Croup (lFP U C ; ee [3)) has published c riteria as to what constitutes a "fu nct .on" of an applicat.on in th is e n e . TI, ey consider user-le vel functiona lity, rather than programming -level functions as in C Typically , a function is the equivalent of processing a scr ee n o r form on the mo nito r. For o ur role-playing vi deo ga me prototype , for example, we ca n .dentify the followi ng fun ctions. I

e t up the c harac ter representing the playe r.

2 . Encounter a rorelgn character.

Function Point Step 2 For each such function , compute its funct io n point co ntribution from the sources shown in Figure 8.4 The followi ng summarizes the sensc o f each contributing factor. The g uidelines have to be carefully fo ll owed , otherwise it is hard to o btain consistent estimates . • Exlmlal j"puls, O nl y inputs th at affect the function in a differe nt way fro m each othe r are counted as sepa rate . Thus, a funct.on of an application th at subtrac ts two numbers would have EI = I , no t EI = 2. On the o ther hand , if the character A ca n be input to req uest an addition and S for subtraction, these would contribu te 2 to EI. • Exl,,,,"1 ou lpuls, Only o utputs that account to r true eparate algo rithm .c o r no ntrivial funct io na lities should be counted . For exampl e , a process that o utputs a charac ter in several font would be counted as I ; ellor

External Inquiries (EIN)

~ ~

Function •

Internal Log;",,' Fifes (ILF)'

•

LagIcII

cf

External OUlpuls (EO)

External Inpuls

File

Figure 8.4 Function point computation for a single function SOtJrC.t' IluemaUof\ll Ful'lCtlol'l PoInt Usen Group. nUp'JMww.lfpug 0fJ

, Internal logical grouping of user data into files

COST ESTIMATION

PARAMETER

imple

Ext. inputs El Ext. outputs EO

• • •

)(

Ext. inquiries ElN

)(

Complex

J

or

•

•

•

or

• •

•

J

or

•

•

7

or

· .. 5

or

•

• • •

6 :

5 or

• • •

7 :

6 :

4 or

•

•

•

•

4 or

•

•

•

10 or

•

•

Int. logical files lLF

)(

Ext. logical Ales ELF ) (

•

•

"

7 or

15 : .. 10 = _

Count Total

I I I I I I

I I I I I I

Figure 8.5 Function point computations (IFPUG)

messages are not counted . Chart representatio ns of data are counted as 2 ( I fo r the data and I for the formatting ). and data sent to separate nontrivial destinati o ns (e.g ., printer) (3).

• Ext""al inquiry: Each independent inquiry is counted as I. • Inttmal logical files : This counts each unique logica l group of user data crea ted by or mainta ined by the application . Combi nati o ns of suc h logica l g roupings arc not counted; each functional area of the application dealing with a unique logical grouping increases the count by o ne.

• Extmsallogical files: This counts each unique gro uping of data o n fi les external to the app hca lio n.

Function Point Step 3 As shown in Figure 8.5, each o f these parameter values IS the n fac to red by a numbe r, depend ing o n the degree of complexity of the parameter in the applica ti o n . IFPUG [3) has publi sh ed derailed description of the mean ing of · simple" and "complex" in this context. Applying this process to the two selec ted functions of the Encounter video game me nti o ned above, we obtain the s preadsheet tables shown in Figures 8.6 and 8.7 . These fig ure arc hi ghl y pre liminary , but the y do beglO to provide estimate parameters for the job . The lo tal unadj usted func tio n point e limat e for th ese twO Encounter fun c tio ns is 25

+

16 = 41 .

Function Point Step 4 Next , one computes weights for the fOllrteen ge nera l hara tcristlcs of th e project. ea h bct"'een 0 and This is shown for the twO selected Encounter funclions in Figures 8.8 and 8 9 . \Vlc have actually u cd a range for tach o( these to reAe t our cu rre nt uncertainty abou t the ap pl ica tio n. O ncc again , It takes on iste nt expenence 10 assc~s the appropria le values for th e e variab le . For example, fa to r 6 a
173

174

CHAPTER & PRINCIPLES OF SOFTWARE PROIECT MANAGEMENT II : ESTIMATION, SCHEDUUNG, AND PLANNING

Ext. Inputs

olm'

Factor

COInI'

I

3

I

Nmn,

comm.,nts:

Co mp/eK

S"b-

(ormt

Faclor

lolal,

1

6

13

MedlulII

Imp/"

Foclor

Qualities

Ready/ move

Ext. outputs

o

4

o

Ext. inquirks

o

3

Int . logical Ales

I

7

o o

5

10

Total

o

7

o

o

6

o

o

15

7

o

10

5

25

Data about the user's c haracter

comments:

Ext. inl.,rface Rles

o

5

I

7

Data about the user's character

comments :

Figure 8.6 Unadjusted function point computation for first Encounter functions: "Set up player character."

Medium

Simp/It

Complex

S"b-

(D util

factor

CO lmt

Factor

counl

Factor

lolal,

Ext. inputs

o

3

o

.

o

6

o

Ext. outputs

1

.

o

5

o

7

,

o

6

o

o

15

7

o

10

5

R,porf

co," mtHts;

Oil

",,,/I,

Ext. inquiri.,s

o

3

o

Inl. logical Ales

f

7

o

Ext. inr.,rface RI"$ COIII""" I, 011

10

Data about flu user's charnelcr

commel1ts:

-

Total

f

s

o

7

aba., /'" .,"', cbaracttr

Figure 8.7 Unadjusted function point computation for Orst Encounter functions: " Encounter foreign character."

16

COST EST1MATION

Incldenlal

Average

EssenliBi

0----- 1----- 2 ----- 3 --___ 4 _____ 5 None

Moderale

Significant

Ca" Study

1. Req uires backup/ recovery7 2_ Data communicattons required, 3. Distributed processi ng functIOns ' 4. Performance critical , 5. Run on existing heaVil y utihzed environmenO 6. Requi res online dara entry' 7. Multiple screens for input'

0-2 0- .

o ]-4

0- .

5

' -5

(co""",ud) Figure B.B General characteristics for function point adjustment. numbers 1-7

Function Point Step 5 Fi nally , th e (adjusted) function point total is ca!culated by the formula shown in Figure 8 10 This equation tates that if there are no special demands at all on the apphcatlon ( tora l ge neral characteristics = 0 ), then the fu nction poinr mea ure should be sca led down from the unadjusted (raw ) score by 35 % (whIch explains the ' 0 .65") . Otherwise the measure should be caled up from the unadjusted amount by o ne percentage po int for each general characteristic unit. For the case study, a reasonable allocation of ge neral cha rac tenstics is shown In Figures S.8 and 8 9 . The total value of these is between 24 and 43 , so the Rnal (i.e ., adjusted) funct Io n poi nt computati o n IS 41

X

[0.65 +0.0 1

X

(24 to 41 )] = 41

X

[0.89 to 1.06] ", 36 t0 43

8.1.4.2 Converting Function Points to Lines of Code Once accurately obtained. function poi nts arc very useful. For example, they can be used a ompariso n met rics. allowing organizations to estimate jobs based o n function point mernes of previou Jobs. They can be converted to lines of code using tandard tables. lines of code can then be used to estimate total effort In person- months as well as duration (see the next section o n COCOMO ). For example, [4] estimates 5 3 hncs of Java source per function poi nt. Using th is factor for the Encounter example, we anticipate Average

Incidental

0----- 1 None

Essenlial

2 ----- 3----- 4 ----- 5 Moderale

Signlficanl

8. Master fields updated online, 9. Inputs, outputs , inquiries of Rle complex' 10. Internal processing complex II Code designed for reuse? 12. ConversIon and installation included? 13 Multiple installatIon in d.rfcrent organizatIons? 14. Must facliitate c hange and ease of usc by use r?

Case Study ]-.

,- 2 .-]

2- ' 0-2

1-3

'-5

figure B.9 General characteristics for function point adjustment numbers 8- 14

17 5

176

CHAPTER S PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II: ESTIMATION, SCHEDUUNG, AND PLANNING

(Adjustcd) Fun tio n Points = (UnJdju,tcd fun ction pOints] X [0.65 + 0.0 I X ( lolal gcnera l charac teri stics)] Figure 8.10 computation o( adjusted (unction points

(361044 ) 53"" 1. 9 - 2.3 K-Hne of Java source As expecled , thi s is much lower than the previous estimates of -\.2 -300 and 7.5· 170 K-lines of Java source. This is true because " applies to o nl y two "function s' for Encounler, whereas the larger e limale were for a full game.

8.1.4.3 A Further Function Point Example Let's consider a system that tracks Video rentals. We will conRne the appJ.cali o n to a cus tomer-oriented appl icatio n, in which customers rent videos and need informalion about availability. \VIe assume that the application requires two Poles only, o ne for custo mers and a second for videos. The unadjusted functi o n po int computation is as shown in Figure 8. 1 I . Now we estimate the adjus tment faclors , as shown in Figure 8 . 12 , yielding a "General Characteristics' total of 35 .

Medium

Simple

Ext. inputs

Sub·

cotmt

factor

COUIII

factor

COllttl

factor

lolal,

2

3

f

4

o

6

/0

Na ..t , pi,. , Ext. outputs

Complex

o

4

Tolal

Vidto dala 5

I

o

7

5

Amosml dut

Ext. inquiries

o

3

o

Int. logica l files

2

-

Customers, Videos

Ext. interface Ales

6

10

o

15

..

7

o

10

o

Jl

Availability

- ncpla""'io",

ncplaoallO"

o

f

o

7

s

o

Figure 8.11 Unadjusted (unctlon point scores (or vide store example

COST ESTIMATION

None

tncidental

0---1

Moderats

A vs"'ge

Significant

Essential

2---3---4

1. Requires backup/recovery' ... ... ............ .. ...... .. . 2. Data communications required' .......... ....... ... . 3. Distributed processing functions' .... ..... ...... .. . 4 . Performance critical, •• • •• • •••• •• • • • • • • • • • • • • • • • • • • • • • • • • • 5. Run on existing heavily utilized environment7 6. Requires online data entry' . .... ... .. ................. . 7. Multiple screens for inpun ..... ..... .. ... ... ... ...... . 8 . Master fidds updated online' ... .... .. .. ............ . . 9. Inputs, outputs, inquiries of files complex, .... . 10. Internal processi ng complexL ... ............. ... '" I I. Code designed for reuse' .......... ... .... .... ... .. . . 12. Conversion and installation included' .... .... . . 13. Multiple installation in different o'lls ., .... .. .. . 14. Must facilitate change case of usc h y user' .. .

5

•

0

0 )

, 5 )

5

2

,

3 3 3 2

Tolal 35

Figure 8.12 FP adjustment fa ctors for video store example

The Function Point formu la gives Function points = [unadjusted fu nction points] x [0.65 = 33 x [0.65 + 0.0 1 x 35 ] - 33

+ 0.01

x (total general characterIStics )]

This yie lds 33 x 53 = 1, 749 lines of no n-comm ented source lines of Java code . The function point method is summed up by Capers Jones in [5], a practiced advocate of function pOInt applicatio n. See also [6 ].

8.1.5 Estimating Effort and Duration from Lines of Code O nce lines of code have been estima ted , either throug h use of historical data, by companson to related projects, or via function points, they can be used to estimate labor reqUIrements and prOject duratIon uSIng Barry Boehm's COCOMO model [ I) COCOMO is based o~ the idea that project outcomes, plo tted as graphs, have a consistent basic shape A para meterized formula is found for the shape, so that to obtain the graph for a particular project, he si mpl y has to detemline the parameters fo r it.

8.1.5.1 COCOMO I Boehm observed that the labor required to develop applicatIons tends to in rea e faster than the applicalto n's SIZC. He found In his init Ial rc earch that the exponentIal fun Iton, WIth exponent close to 1.12. expresses thIS rtlationship quite well Boehm's model also says that the duratIon tncreases exponentia lly \ IIh the erfon , but WIth an exponent less than 1 (the exponent used III th , case is clo e to 0 35 ). Th,s rell t, the observalto n that .fter. c;.,n.atn sIze (the "knec' In curvc (2)), additional reqUIred effort ha on ly a gradual lengthenIng effect on th~ time It takes to complete the project TI,CSC are illustrated In F,gure 8 13, wher~ L ",ho n for "Iine< of ode '

1n

178

CHAPTER 8 PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT II: esnMATloN, SCHEOUUNG, AND PLANNING

(1 ) ellort' lor Increasing LDC , '2 (y _ 3.. . ) ~

(2) Duration lor Increasi ng ellort' (y _ 2.5 .. 0.35)

,

Exponent < 1 > 1

Applies to design through Integrlll/on lind testing ' Ellort = total person-months required Figure 8.13 Meaning of the COCOMO formulas Source Boehm., Barry. " Sol tware EngIneerIng EconomIcs," Prentice Hall, 1981

U lng data fro m num erous projects, Roehm estimated the parameters fo r these re latio nsh ips, assuming an e xponential re lations hip. H is fo rmulas arc illustrated in Figure 8. I 4 . In this system, organic applications an: stand-alone applicatio ns suc h as classica l (i.e ., no n -Web-enabled ) word processors or our Encounter case study . Embrddrd applicati o ns are integral to h ardware -softwa re sys tems (e .g ., an anti lock braking system). S""idew hed apphcatio n arc in between . A Web-enabled Encou nter, for example , is semi -detac hed: it is not o rganic , but neither is it as heavi ly e mbedded as the code in an antilock braking system, for example. En counter would commU ni cate with the Inte rnet via signals that are o nly occasiona l when compared with the frequency o f C PU Instruc tion execu tio n. Boehm's mo del says r,rst that the required effort and durat ion ha ve separa te models (fo rmulas) fo r each ty pe o f appli cat ion (differing in factors a and b). For examp le, a sta nd-alone job with 20,000 lines of code would take 2.4 x 20 1.05 '" -I person -mo nths duratio n if organic (stand -alone) but about 3.6 x 20 1.2'" 76 person-mo nth if e mbedded _ The duration formu la ca n be expressed directly 111 te rms of line of code (KLOC) as follows: l

Duration = c x Effon = c x (a

X

KLOCb)J = c x

i

X

KLOCIJ

At nrst glance, Boehm's duration fo rmu la may appear strange because the relations h ip between effort and duration seems to be simpler than his form ula indicates. For example, If we kn ow that a job ,..,quills 120

Effo rt in Person-months = a Duration = c x Effort'

Software Project

a

-

b -

c-

Organic Sem i ·detached Embedded

2.4 3.0 3.6

1.05 I. I 2 1.20

2.5 2.5 2.5

FIgure 8.14 Original COCOMO I formulas SolKco Bco'1m, BatTy. "SOftware Englneetlng Economics," P,oouat Hall.. 1981 ,

X

KLOC

d0 .38 0.35 0.32

COST ESTlMAnON

pc:r.;on .months, and we put ten people onto it, won't it get done in 12 months? This would indeed be the Ca3e if we could usefully and con istently employ all 10 people on the project from day 1 through day 365 , but this is not usually possible Consider, for example , day 1 Since all the engineer.; can't know much about the project (it has just begun ), what u dill activities could all ten engineers do that day; It follows that if we allocate 10 engineer.; (Tom the first day , the 120 per.;on .mo nth job w,1I actually take longer than 12 month . Boehm's duration fonnula has the strange property of being Independent of the number of people put on the jobllt depends only On the size of the job. Actually, the formula assumes that the prOject Will have roughly an appropriate number of people available to it at any given time (for example, one on day I , th irty on day 100, assuming that is what's needed). Boehm's model , whi h has been tested extensively and is widely respected , has been refined over time, and has been largely updated with the more complex CO OMO II , described next. A great deal of practice is required to use even COCOMO I effectively. It i< best used along With an independent method and a healthy dose of common sense (sometime called a "saOity c heck") . U"ng Boehm's basic formula on the prototype ver.;ion of Encounter (conSISting of two basic hIOction ), With 4· 300 K·hne. of code, we obtain 10 to 1,000 pcr.;on.months of effort , and 6 to 35 months in duration, as shown in Figure 8 15.

8.1.5.2 COCOMO II COCOMO (I ) is somewhat identified with the Watcrfall process because it does not speCifically account for iterative development. It mu t be used anew for each iteration , and docs not account for factors such a whether the iteration is early or late in the process. For this rca on and others, Boehm updated it to COCOMO II. (See, for example, httpi/sunset.usc edulresearch/ COCOMO IIl) The n of COCMO I can be interpreted as a scaling factor. COCOMO II replaces it with a product of various scaling factors F F" SF" " SF <, and SF, . This al lows for a more refined set of parameters. The b parameter In COCOMO I expressed the number of times KLOC is multipl ied . CO COMO II replaces thIS with a product of seventcen quantillc EM ,

-a

K -

b

-

approx. nK" b

Effort LO

2.4

4.2

1.05

10

HI

2.4

300

1.05

1000

c

P

d -

approx.

-

-

cP" d

Du~lion

LO

2.5

10

0 .38

HI

2.5

1000

0 .38

Flaure ' ,15 using COCOMO I to estimate the magnitude of the Encounter effort

6

179

180

CHAPTER 8

PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT II: ESTIMAnON, SCHEDULING, AND PLANNING

Effort In Person ,mo nth s

=

{I

X

n,

,'?EM,

L,

w here n = 1.0 I + I' SF, EM, ore multiplica ti ve cost dnvers SF, a rc sca ling cost dri ver Figure 8,16 Basic COCOMO II Formula SOUrce Boehm, Barry. " SO/tw;lfC ErlS'lncerlng Economics," Prentice Hall, 1981 . httP l/sunset uscec!U/researchlCOCOMOIV

(so eoch replace KLO in CO O M O I) These arc called l11ulliplica l,", co,1 d,,",,,, and they allow for m o r~ re~ nem c nt in dc>cribmg the produc t and project. The CO OMO II Effort fom1U l. is shown in Figure 8. 16. 11,e sym bol ] (cap ital p) is the product symbol For ex,mpl e, ,k' means I ' X 2' X 3' X 4' . Fi gure 8. 17 lists the ty pes of the quantities SF, and EM}' The SF, parame ter, for examp le, allows for fac tonng in the maturity o f the develo pment o rgani za ti o n. The SF, parameter allows for the degree of risk re maining in the projec t. The va lue o f SF. is hi gh for initial iterations a nd low for later ones The EM .. parameter account for the modern practice of developi ng in several physical locations. Each of th~ porametcrs has a de fi ned scale.

n:

8.1.6 Assessments for Agile projects: Story Points and velocity This eetion di scusses esti mation techniques for agi le projects . In o rder to commit to delivering capabil ity at the e nd o f a cycle , a team must assess th e effor! req uire d . As with fun c tion points, ,lory pOlnls are a means by which to measure the size of a story as it relates to implementation . Unlike function po ints, however, which attempt abso lute measure me nt, Sto ry points are a relative measure . In other words, they compare sto nes w ithin a project o nl y. Th e size ra ngc is typically betwee n I and 10, and the size of a Story is based on the team's hi story o f implementing stories in past cycles of the project. One way to establish story poi nts is to take a n executed story that the team considers to be average, assign it 5 story points , and use it as a yardstick (or fu ture stories . Another is to select a vcry small implemented story, count it as 1 point, and thcn calculate all o ther stories as multiples o( it . A mo re sophisticated way is to create a plot as shown in Figure 8. 18 . A big ad va ntage of agile meth od s is that they involve man y entire creation cycles. In a pure waterfall, team member find it difficult to estimate the size and completion time of a job because they will not usuall y have performed o ne just like thi s in the past, with the same participants. Agile methods, on the other hand , facilitate th e assessment of how much completed work a team is capable of producing by relying o n observed past performance within the same project. Recall that in physics, velOCity is defined as di,'a"ct co"md p" lime 'IIIil. Similarl y , agile project velocity is defined as the amolln l of fun "o"alily lilO' unil. This translates into story points per cycle. Assuming the constancy of cycle (e.g ., alway two weeks), the reliability of a ve locity calculatio n depe nds only o n the ability to accurately as ess story points With the ex perie nce o f repeatedly making thi s estimate, te om mcrease their estimation accuracy as the proJeCt prog resses. Sec Figure 8 . 19. As effective as this kind o( agi le estimation is, it requires augmentation when larger scale estimation i required. The reader is referred to ohn, Agilt Eslimaling and Planlling , Prent.ce Hall, for example, for further reading.

,."lta ""

COST ESTIMATION

Sym.

Abr.

SF,

PREC

Precendentedness

FLEX

Development Flex,bility

-

,...

,

SF, SF,

Name

-

, RESL

-

Architecture and Risk Resoluti on

SF.

TEAM

Team cohesion

SF,

PMAT

Process Maturity

-

EM ,

-

-

-

-

RELY

Required Software

DATA

Data Base Size

EM,

CPLX

Product Complexity

EM,

RUSE

Required Reusabili ty

EM,

DOCU

Documentation Match to life-cycle Needs

EM.

T IME

Time Constraint

EM,

STOR

Storage Constraint

EM .

PVOL

Pladonn Volat ility

EMg

ACAP

Analyst Capability

EM IO

PCAP

Programmer Capability

EM"

AEXP

Applications Experience

EM"

PEXP

Platfonn Experience

EM "

LTEX

Language and Tool Experience

EM

PCON

Pe ~o nncl

-

"

Cont inu ity

0>

T OOL

Use O f Software Tools

EM , 6

SITE

Multi ·Si te Development

EM 17

SCED

Required Development Schedule

EM

Fl&ure '

-

"

.17 Basic COCOMO II cost drfvers

~" 8OllYrl. Barry. ·'SQftwate Engineering ECOOOiTiJCS," Prentice HaJJ, 1981 , htlP IIS1Jnsetusc edlJ/reSoeNd'VCOCOM08I.

111

182

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II' ESTIMATION, SCHEDULING, AND PlANNING

10

Upper bound , Estimated size In story points • Actual size In person·hours

•

~

0

• 0

•

• 01

I

• • t , Com pule past e rror % 2. Estimale using compaMson , 3. factored by Irend in past errors % 0

1/

•

1

2

3

4

5

6

7

e

Cyclo number

Figure 8.18 Estimating story points

• DeAnitlOn , Number of story points the team ca n execute per cycle • Relies on history of perfonnance and consistcncy of story points a

\'qit hln this project and past ones

• Depe nds on accurate story poi nts Figure 8.19 Velocity in agile development

8.2 SCHEDULING Project estimates are used as input for co nstruc ting project sc/"d" I". Teams develop schedules so that everyone knows what to expect, ,. hat to do, and when to do it. Figures 8.20, 8.2 I , and 8 22 step through a tYPical schedule construction using a spread; heet . Substa ntial projects arc best' perfo nmed with specialized tools such as Microsoft Project . Softwa re project sched ul ing confro nts a fundamental c h icken .and·egg problem , as fo llows. Part of a software e ngi neering project is to ga ther the requi re ments but until we know the requirements fo r the application , we ca n't say h ow lo ng it will rake to do the job and so, strictly speaking , we can't schedule it. There are severa l approaches to breaking out of this loo p. One is t'o develop a sche dul e o nly afte, the req uireme nts ha ve been speciRed . Although thi is logical, it is no t often used. The main reasons fo r thi arc a follows , I. As me nti o ned befo re, it is usuall y imprac tical to specify all req uireme nts up fro nt.

2. Management uSllally needs to know llP front how much time the project will consume and how muc h it will cost. A common way to approach these issues is to begin With deadl ines and to ae am pi ish as mJn of the important requi reme nts as possible with the speClAcd time and Ananei.1 resources , and the n to i~rate this process. For the purposes of dIScussion, this is the approach used herc. The AT'i t step is to show the deadline for ddiverables to the cus to mer. In Ollr ca e , we wtll
I

I

T

I

I

Schedule for VideoStore Application

4-

January

1

t

t Milestones

2

February

3

4

1

2

1"

I I I

I I Ap ~1

March

3

Prototype X

4

1

2

3

X Freeze requirements

4

t

May

1

2

3

1

4

Final product X

I .

-- -

-

Figure 8.20 Building a schedule part I-setting milestones

1

l'i

~' -

2

3

4

- '" -

1

2

3

1

~

:r: m

Figure 8.21 Building a schedule Part II-shOWing phases

o C c z

Cl ~

e:

~

\:

2 ~

~

CD

4

4

1

2

"0

3

-z

;0

-

n

"0

f;;

V>

o."

~

~

;0 ITt

"0

e'" ITt

~

~

~ m

;::

ITt

1

1

11111

1

1

1

1 1

1 1

11111

I

1 1 1

1

1 1 1

~

1

4

--

"

1 -•

~ I ' I

I

~;:: -o~ z

•

~

I

ITt

g C Z

Figure 8.22 Building a schedule part III- showing work breakdown structure

'"

• ~

Z

o "0

~Z

-Z

'"

THE SOFTWARE PROJECT MANAGEMENT PlAN Oependendes: subset of schedule

Critical paths: sequences of dependencies

---., ---i-,

-

phise I dBHllled

'

- -

-

-

I

•

phue I delilled

--I --r-- -

-

,

phase II detailed

-

-

Figure 8.23 Dependerrcies shown in schedules

technique used in setti ng a sc hedule is to build in buffers to compensate for factors that we don't or can't know about. For example, our schedu le assumes four weeks per month , whICh provides at least o ne unscheduled week. This is shown in Figure 8.20. Some project managers frown on approaches like thi s because they hide things. Now we work backward from the mil estones to show the times for the various phases, as shown in Figure 8.21 . Finally , the team needs to ensure that people are availab le to do the work . This requires a work b".ktiown (WBS) showing who will do what work. Figure 8.22, for example, Includes a WBS In the example of Figure 8.22 , the last week of design requires Just o ne person and the first week of implementation requires twO eng,neers . Schedules show the intended o rder of tasks. 11 task A is schedu led to be performed prior to task 13, this docs not necessari ly imply that 13 depends o n A. For example, we may have selected the order because it i more convenie nt to perform task A befo re /J. However, if task X depends on ta k Y, then task Y should be scheduled to complete before task X begins, and the dependency should be made clear on th~ s hedu1c. We can denote dependencies o n a schedule, as show n In Figure 8.23 These become ,mportant whenever we want to aller the schedule. They are al so necessary in detennining the proJect's rillcnl pnl" : the sequence of activities that ",usl be performed, and the order in which they must be performed To ummarize: The dependencies form a subset of the schedul e, and the crit,ca l paths are seque nce of depend ... n ies

"ruc'u"

8,3 THE SOFTWARE PROJECT MANAGEMENT PLAN The prOject plan is docume nted <0 that everyone knows what to do and when to do ,t . There are many formats forsu h a plan. We will use IEEE Soltware Project Management Plan ( PMI') standard 105 · 1 98 for this purpose. TI,e table of contents for 1058 · 1998 I< show n in Figure 8 24 , and is used 111 the ca e ,tudy 111

115

186

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II: ESTIMATION, SCHEDUUNG, AND PLANNING

I Overview

/)

Tech nica l process plans

1. 1

Project ~ul1lrnary

6. I

Prote , model

I .2

Evo lution o f the S PMP

6 .2

Mellwds, lOols, and te hn lqucs

2 Refe re nces

3 Den nilions 4. Project organ iution

4. I 4 .2 4 .3

Exte rnal interfoces Internal struc ture Roles and responsib il ities

5 Ma nage rial p rocess p la ns 5 . I Projec t start·up plan 5 .2

W o rk plan

5.3

C ontrol plan

5 .4

Risk management p lan

5 .5

Project closeout plan

6.3 Inlras lruc lU'C plan 6.4

Produc t acceptance plan

7. Su ppor ti ng p rocess p lans 7 . I Configuration manage ment plan

7 .2

Verification and validation plan

7 .3

D ocumentation plan

7.4

Quali ty assuranc e plan

7.5

Reviews and audits plan

7 .6

Problem resolution p lan

7 .7

SubCOnl"raClOr man.gement plans

7 .8

Process improvement plan

8. Additio na l pla ns

Figure 8.24 IEEE 1058-1998 software Project Management Plan table of contents

Section 8.4 . The IEEE standard is someti mes viewed as belonging only to "document-heavy" projects. In fact , its parts should be used when and o nl y whe n they provide value . Agile project leaders can gain by perusing the topics and dec iding how a nd when the issue me ntioned is to be hand led . Non-agile projects are not bound to usc a ection unless the effort IS worth it. Prob lems arise w hen needed issues arc igno red and when docume ntation is used for no productive purpose. Section 1. 1 in the SPMP-the overview-sh ou ld ide ntify the project but should not cover its requireme nts (i.e ., descriptions of its behavio r). These arc cove red in the Software Requireme nts Specifica· tion , described in Part " of this book. Repeating th at materia l in the SP{\'IP would violate the principle of single· source documentation (to say each thing in one place only). Section 1.2 dcscrib", t he ways in which the SPMP itself is expected to grow a nd c hange. The Software Co nAguration Management Plan (SCMP) hould have been developed by th is ti me (see C hapter 6), so that versions of the SPMP can be properly controlled . A reference to the SCMP is provided here. Section 4. 1 describes the ways in which orga nl ZJtions wi ll co mmunicate with the development team This depends o n t he project's stakeho lders (the people w ho have an intere t in it). For example, how will engineering interface with marketing (regu lar meeti ngs, E-mail, etc .) Section 4.3 speeiAes the responsibili. tics of project personnel. Section 5.2, the Work Plan , caR co ntain the project's schedule. Section 5.3, the Control Plan, peciAes who will manage , con trol , andlor review the project, together with how and when this IS to be done. For example, sen io r management needs to know how projects arc progressing, so we would de. cnbe the process for keepi ng them informed here. Risk ma nagement (Section 5.4) was described in hapter 7. Constraints on the languages and tools used are provided in the "technical proce s plans: L"CtlOn 6 for exa mple, 'This project shalilisdava from Su n, versio n 1.2. 1, and Rational Rose versi,o n I: Section 6. 1 refers to the software development process to be u
CASE STUDY: ENCOUNTER PROJECT MANAGEMENT PLAN

In Section 7, the • upponing Process Plans references or dc:scnlxs activill'" that suppon the development process, such as configuration management and quality assurance. If the suppon function is descrilxd in separate documents (e .g ., the configuratIon manage ment plan or the quality plan ), we reference those document ·. Otherwise, We describe the upport hlnction In full. These and other aspects of the SPMP are explained fun her In the ca e study at the end of this pan of the book. The reader will find a ample SPMP for the Encounter cases study in SectIOn 8.4 of thIS chavter, wh,ch conforms to IEEE standard 1058· 1998 Excerpts from management documentatIon for the Eclipse and OpenOffice open source projects can be found in ections 8.5 and 8 6 res pectively. In compari ng them , the reader will notice the benefits of using a standard but also some of the limitallons in ncxlbility.

8.4 CASE STUDY: ENCOUNTER PROJECT MANAGEMENT PLAN The Software Project Management Plan for Encounter sh own in thIS section i based on IEEE

1. Overview

SId

1.1 project Summary

IOS8-199B

Slandard for Soflware Pro)tCI M"'''9''"''''

PI.ns. Figure 8 .24 is lhe table of content for the doc ume n t. Approvals

TItle

Signature

Date

Engineering Manager

!I. '}onI.>

7/ 15/ 04

QA Manager

£WiUn.

7/ 11104

Project Manager

a. ~.u jU

7/7/ 04

Author

£. !1J.tl uA~

7/ 1/ 04

Revision History Version I 1.0.0 E. Braun: Created first draft 6/ 1/98

Note to the Student: This should be at a hI g h enough level that 11 does not need to change milch over time. Derads should appear in sub equent sections, not this one. This summary should not substi· tute for any pan of the requirements document.

Thi s projecl is organized to produce a role· p laying video ga me called Encounter ThIS ga me will be developed in several stages Ince the customer intends to specify the requirements in
1.2 Evolution of the SPMP

1.1 .0 R. Chadwick: Revlewcd 1/ 1 1/99 I 1.1 E Braun: Expanded 3.2 1/ 19/99 1.2.0

R.

Chadwick: RevIewed for release 5/ 19/99

1.2 . 1 V Brahms: Final editing 4/ 30199

Versio n 2 2.00 E. Braun : Updated to 5/18/2004

1998 standard

Explai ns how and by whom this document will be maintained. It will have 10 be mo(hfied In severa l ways (e .g., with a more detailed schedule as more is known about the reqUlremc.-nts ). If a concrete plan is not Pllt In place to maintain this docum"nt, It will be worked on sporadically or not at all.

187

188

CHAPTER8 PRINCIPL 5 OF $OFlWAREPROJECTMANAGEMENT II: ESTIMATION. SCHEDULING. AND PlANNING SPMP = Softwa re Project M anagement Pla n (th is document ) SRS = o frwa re Requ irements pcci fi ca tio n SDD = o ftware De ign Document STP = Softw are T est Pla n tbd = ro be decided

h" docum ent wdl be m a '"t a ll, ~ d o n a wC('k ly h.
2. References 4 . project organization [IEEE) Th e appl. able IEEE standards are pub lished on "IEEE Standards Collecti on," 1997 edition. [MPA L5) Th.s document is to co nform to the company's "MaSler Pl an for the Attainment of CMM Level 5 " [Braude) l1,e princi pal source of textbook ref· erence matenal is 50fl.,ort E"gi""",'g , A" Objtcl-Onmltd PmptClovt by E. Braude (Wiley, 2000).

3 . Definitions

CI = Configuration Item CMM = Capa bility Ma turity Model, the SE I's model fo r o rganizationa l imp rovement IEEE = Institute of Electrica l and Electronics Engineers QA = Qua lity Assurance SEI = Software Engineering Institute, Pittsburgh , PA SCMP = Software Cor-figuration M anagement Plan

4.1 Externa l Interfaces Name the people and organizations with whom the team shou ld communicote. The projecttcam will interface with the fo llow. ing individuals and organizat ions, VP, Engi neering (for tech nical and standards direction), Marketing (for requi rements), Came Laboratory (for advanced game features). and the quality assurance engineer.

4.2 Internal structure Figure 8.25 shows the organ izati o n of the Encounter project within Camin g Industries Consolidated. The project will be organized as a team of peers with designated roles. The role are team leader, conRguratio n management leader, qual ity assurance leader. requirements management leader. design

President

I

VP Marketing

•"

VP Engineering

j"' I IV&V I I Soltware I Englneerlng

-

"

."

.

Labs

Game Lab

Game 123

Figure 8.25 Organization of Gaming Industries Consolidated

Encount. r

SOA

CASE STUDY: ENCOUNTER PROJECT MANAGEMENT PlAN

Team leader

Ualson

CM

QA

Leader

leader

VP Engineering

SPMP

Requiremcnts Manaaement Leader

Marketing

SCMI'

Responsibility

SQAP STP

Leader

Leader

Software • • engmecnng lab

SDD

SRS

Code base

Figure 8.26 Encounter project responsibilities

leader, and implementation leader. In addition . there are liaison roles to marketing and to the software engineering labora tory .

4.3 Roles and Responsibilities The responsibilities of the participants in the project are shown in Figure 8 .26. Being responsible for a doc ument Includes the following , • Making sure that the document is created on time • Having the team leader identify the writers of the document • Keeping the document up· to-date throughout the project life cycle

s. Managerial Process Plans

5.1 Project Startup Plan This seclion spc:cifles the planning activities thaI will be conducted once: the project is under way It IS i plan 10 conduct planning- . meta·plan, if you like.

5. 1. 1 Estimation Plan As a project progresses, our ability to estimate its cost and duration improve (but also become progressively less useful). This section explains when and how we intend to perform these •

•

estimations.

Estimations of prOject cost and duration Will be made following the specification of hi gh -level re o quirements (using funcroon poonts), detailed require · ments (uSing a method to be determined), and aftcr high- level design The latter estimates will be made by com pari o n with past projects Before beginnrng requirement analYSIS, we have estimated the size of this effort in three differ· ent ways: 1. Usin g an informal top·down e tim.te based on the expenence of team members With somewhat sim ilar p,oJects. 2. Usi ng a to p·down approximation with industry game development data. 3. USing fun tion pOint on two known function s, extrapolating to the cnllre application . The results are shown on Figure 8 27

,,,

'90

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II: ESTIMATION, SCHEDULING, AND PLANNING

Mini

( I)

Comment

Max 170

(2)

4.2

00

(3)

1 1.4

46

1.9 · 2.3 for two identified func ti ons, 6 ·20 times as many in comple te a pplication

Most conservative

1 1.4

300

Maximum o( minimums and maximum of maximums

Least conservative

4.2

46

Mini mum o f min im ums and minimum of maxi mums

Widest range

4.2

300

Minimum of min imums and maxi mum of maximums

-

Narrowest range

1 1.4

46

-

tvtaxi mum of min imum s and m inimum of maximums

Figure 8.27 Very rough estimate of application size prior to requirements analysis

There arc many ways of presenting this data, dependi ng on the needs of manageme nt and the development staff. So me of these are shown in Figure 8.27. In the absence of wrinen requirements, estimates are necessarily very rough. The estimates themselves can be an appendix to this document instead of he re within the body, and updated as the project progresses.

The reaso n fo r the very wide ran ge is tha t the figu res have been obta ined with negli gi ble interac· tio n wi th the customer.

5.1.2 Staffing Plan

Th e impleme ntation leader wil l e nsure that all team members arc supplied with the selected devel· opment environment within two weeks of project starr .

5.1.4 Project Staff Training Plan All staff me mbers whose Java profiCiency level is less than "advanced," as defi ned by the Ajax certification, will be trained by Uni versal Training Inc. courses wit hin the (irst mo nth of the project. The objective will be to attain advanced· level profiCiency.

5.2 Work Plan 5.2. 1 Work Activities

The ro les will be fi lle d as fo ll ows.

5.1.3 Resource Acquisition Plan This section indicates how resources will be obtained other than staff (computers, soft· ware, etc .)

ThIS sectio n specifies how the work will be subdivided . Th~ work o n th iS project w ill be diVide d inlO con Aguratio n manage me nt, qunlity a<surance (i n· eluding testi ng), reqUirements annl is, d", lgn, and

CASe STUDY: ENCOUNTER PROJECT MANAGEMENT PlAN

Leader

Fadlitator

Rc:sponslbilty

Report at wc:c:kly meeting

x

Marketing

QA

Game lab

Risk

liaison

liaison

liaison

retirement

x

x

x

Orculate wc:c:kly report Orculate biweekly report Orculatc: monthly report

I.

·Report forma ts 1

see CI 34 : "monthly project status fo rm"

2

sec CI 87: "mo nthly marketing status form "

3

see CI 344 : "weekly QA status form "

4

see CI 48 : "biweekl y game lab result form"

Figure 8.28 Program monitOring and control

Name Ed Braun

Team uader

CM uader

QA Leader

Requ . Mngmnt Leader

Implementation Leader

X

X X

AI Pruitt

X

Fern T ryfill

X

Hal Furnass

X

Karen Pders i.JailOn with

Design uader

VP Eng.

Rgure 8.29 StaHlng plan for Encounter

Marketing

Soft. Eng. Lab

'9'

192

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II: ESTIMATION, SCHEDUUNG, AND PLANNING

Monlh ,

, SCMP complete ,

-Mon,h 3

Monlh 2

2 3 4

,

2 3 4

,

,2 3 4

2 3 4 t 2 3 4

Begin system testIng ' , SOAP complete

Milestones

Month 5

Month 4

Delivery ,

, SPMP rei. , complete Freeze requirements ' Iteration'

, Iteration 2

Risk Identification and retirement

I

I Preg:. for maintenance

I

I

Figure 8.30 High·level chart of tasks with fixed delivery date, ordered by completion imp lementati on. The prOject roles and responslbili . ties are shown in Figure 8.26 .

5.2.2 Schedule Allocation 11 we are given a Axed completio n date and have identiAed the process that we will use, we may have enough Information to provide a high.level schedule. We increase the amount of detail in the schedule as more becomes known about the design. The schedule is shown in Figure 8.30. Refer to the SQAP for the schedule of quality activitIes.

5.2.3 Resource Allocation The work breakdown structure is shown in rlgure 8.31 . The bottom line shows t~e person · month available for each month . We have not yet pcrfonned any design, so it is too early to name the engineers who will work on speCific pam. These names will be added he~ after the designs for the various configu· rations have been detennined.

I

Ie , Including bc:ncAts

5.2.4 Budget Allocation The budget allocation, shown in Table S. I, matches the work breakdown structure shown in Figure 8.32, and includes an additional 10 percent to cover unantIcipated cOSts. Loaded I labor rates arc $4,000 per week.

5.3 Control Plan The IEEE describes this section as ' ",etria, reporting mechanisms, and contlol plocedlUcs necessary to measure, ~port, and conllol the product requirements, the project scheduk!, budget, resources, and the quality of worlt processes and work products.' It is usually advisable to schedule regular team meetings (typically weekly; sometimC!S short daily stand·up meetings). When there is no business to conduct, such meetings can easily be canceled. On the other hand, sched, uling a meeting on short notice m~y be when team members have other commitllknlS. Even teams that work to~ther every ~y need to schedule negular review meetings to avoid drifting. The meeting convener should __ mally cancel a meeting if there ~rc no qcncIa it~~lmIiS.

CASE STUDY: ENCOUNTER PROJECT MANAGEMENT PlAN

Month 1

- r-,--.--!1

2

3

4

1

Month 2

Month 3

Month 4

Month 5

- - ---.----.-+---.-....,..-,--+-.---.--.--1

234

1

234

1

234

1

234

SCMP Milestones

6

6

Complete testing

SQAP

6 Freeze requirements

SPMP rei. 1

6

Delivery

6

Iteration 1

Tasks

..... Risk I&R

Iteration 2 ....!.;;;"""""..............""'"

E. Braude

11111111111111111111

J . Pruitt

111111111111111111

F. Try1111

1111111111111

H. Fumass

111111111111

1111111

K. Peters

11111111

1111111

F. Smith (tech support)

.5 .5 .5 .5 .5 .5

TOTAL

~

.5 .5

.5 .5 .5 .5

~

.5 .5 .5 .5 .5 .5

5 . 55 . 55 . 55.55.55.55 . 54.54.54.54 . 54 . 54 . 54 . 54 . 54 . 54~3 . 5

F'1gUre 8.31 Work breakdown structure. excluding clerical work

The ~ ntire team w, lI meet at the begi nn,ng of ~ach phase (reqUire me nt s, d esig n, and imple me nta · tio n) within each it~rati o n . There w,lI be wee kl y project m~e t ing< on Tuesdays from 10:00 a.m. to noon. T ~am members are requested to keep Friday mornings from 9:00 a.m to I I :00 a.m. o pe n fo r an additio nal meet ing, in case suc h a meeting becomes

nece sary. The team leader wli l inform the team by Thursday at 4:30 p.m. if the lotter meeting is to take place .

5.3.1 Requirements Control Plan The req uirements leader will report to the project leader o n the status of the SRS in wnting each Tucsday.

5.3.2 Schedule Control Plan

Table 8 • 1 Budget allocation

T he project leade r wi ll report to the tea m o n the status of th e
Month Number

Allocation

1

596,800

2

S96,8oo

5.3.3 Budget Control Plan

3

S87,120

The rrojectlcader wi ll rcpurtto management on the
4

S87,120

5

S77,440

5.3.4 Quality Control Plan

Total

$445,280

T he A representallve wi ll I" v,de wnlten re f' rtto the manaR ' r QA , w llh copie. to th e proJ

nr

193

...• ~

'" ;!1 ""z

n -

•

RIsk Tide (details alven above)

likelihood 1-10 , . /east likely

Superi mpose

1

Impact 1- 10 , =/east

impact

3

""m Retirement Cost 1- 10

Priority (lowest

, =/owest cost

handled first)

1

8

10

numb~r

Retirement / Mitigation Plan

Responsible Engineer

Ta'llet Completion Date

a."

V>

a

~

'"

IT' -0

Expe rim e nt wi th Java images

P R-

1/99

images

'"-ma

<:l

:;::

Deficient Java skills

2

Alan Gray maybe pulled off th is project

3

6

9

7

3

80

8

288

9

H .T .. K.M .,V.I.,and L.D to Jttc nd trai ning course begin . ninS 1/5/99 at Ultra T rai ning Corp. obtai n Java level 2 certl nca tio" by 3/ 1/99 and leve l 3 ce rt ifica tI o n by 4/ 15/99

Susa n Ferns to

In Sp t::Cl

all of

H. L

4/ 15/99

> z

~

IT'

:;:: m

~

-m-

"

~ -

SF.

Continual

Ala,,'s work

:;:: -~

a z •

~ :r IT'

o C

•

• •

•

•

•

•

•

•

•

•

FIgure 8_32 sample risk analysis for Encounter case study

• • •

,

..

C

-

Z C>

-> Z

o

~z

-

a

CASE STUDY; ENCOUi'ITER PROJECT MANAGEMENT PlAN

kader, on a chcdule to be determined by the manager o f QA .

5.3.5 Reporting Plan The written repo rts referred to in this section (5.3) will be via e · mai l. Issue affecting human safe ty will be reported to all project personnel and managc . ment , regardless o f the plan in th is document.

and eve n if they are, we do no t know ho w lo ng it Will take to come up to speed. ThiS co uld dama ge the project irreparabl y. •

••

5.5 Project Closeout Plan Encou nte r will no t be ma intained and released be · yo nd 2006 A phase·out plan for the second half of 2006 wi ll be develo ped.

5.3.6 Metrics Collection Plan Sec the Software Quality Assurance Plan.

6. Technical Process Plans 5.4 Risk Management Elaborate on the risks a specific ''bad happen· ings·, do not leave as generic titles. For exam · pie, "deficient Java skills· by itself does not specify the issue. Perhaps the project can be performed adequately by a team whose Java skills have deficiencies.

Figure 8.32 shows a format for risk reporting and retirement. Each project meeting i to have an agenda item for risk identification brainsto rming and reporting o n risks that have been identified. Risk # I : "Superimpos in g images" co nce rns image manipulall o n In Java. Thi s is a reqUired capability, becau se characters have to move abo ut, superimposed on backg ro und image . No o ne in the team has experien ce with placing th e im age o f a character against a backg ro und witho ut carrying a rectan gle alon g with th e c harac ter. We do no t know whether th i is easy , difficult , o r impossi bl e to do. Ri sk N2: "De fic ie nt Java skill s" indicates the fact that 40 percent o f the team is no t suffi ci entl y skilled in Java to implem ent the movement and interactio n o f c haracte r ima ge . We anti ci pate th at it will also be necessary to sca le th e ga me e nvi ro n· ment , but no o ne o n th e team has any experience With th is. W e do no t know whethe r th e ca pabil it ies that our cu, to me r ha in mind are doable wlthJ ava ,

Here is where we describe the process to be used (waterfa ll , iterative, etc.).

6.1 Process Model Th e first two versio ns of this project wi ll be executed using a spiral develo pment process wi th an Itera tio n correspo nding to each versio n. The first iterat ion will be a wo rking pro to type but wi ll be fu ll y documented The seco nd iterati o n will result in versio n I of Encounter. The number of subsequent iteratio n and the naruro of versio n 1 arc to be decided afte r the custome r has witnessed a dcmo nsrratlo n

6.2 Methods, Tools, and Techniques The Encounter projec t will usc Rational Rose™ for design and will be Implemented In Java O bject. O rientatio n is to be used thro ugho ut. Javadoc wlil be used fo r documentatio n as mu h as possible (sec the SR fo r this requireme nt) Refer to ectlo n 2. 1 (process model) fo r a de cripti o n o f the process.

6.3 Infrastructure Plan The En o unto< team Will reqUire model 9 1234 P s, Internet access, 100 G il torage o n FeliX. and the Ajax team co llabo ra tio n applicatio n upport.

195

196

CHAPTER 8

PRINCIPLES OF SOFTWARE PROJECT MANAG M ENT II. ESTIMATION, SCHEDUUNG, AND PLANNING

"n plclllc ntcd for Ec l, ps T he , haded material Con.
6.4 Product Acceptance Plan

ECLIPSE DOCUMENTATION

" Ianageme nl and "We, lo r re pro,c ntat lves will r,nalIze acccp tan e c ntena ' \fit hill three weeks or proJcc t start A cp t. " cc tests w il l take p lace a t the M e office with", a wcek of the proJect comple tio n date .

T he ho me page for "pse documentation IS at "docuht tp j/www.ecli psc.org/eclipseh ndex.php me ntati on .' T h iS ",eludes use r manuals Documen tation IS classified as a subprojec t in Itself

7. Supporting Process Plans

Note to the Student: Documentat ion is so substantial that it is designated as a (sub )project unto itself.

Thi s section references plans supporti ng pro cesses that span the duration of the software project such as the SCMP, SVVP, a nd SQAP.

ORGANIZATION OF THE ECLIPSE PROJECT

8. Additional Plans N o ne

8.5 CASE STUDY: PROJECT MANAGEMENT IN ECLIPSE The material In thi s section is quoted , edited , or adapted fro m the Ecl ipse Web sites as the y existed at various pOints In time. It is no t a formal SPMP but rather a descript io n of h ow projec t m..na gement is

The Eclipse project conSISts of several 'TopLevel Projects_" A management committee is respo nsible fo r each of these . Each top-l~eI project consists of several (non -top-Ievel) projects. Each project has a project lead, the project p la ns, a nd the developme nt team _The developmen t team consists of developers and "committers." Only the latter have the authority to comm it artifacts to the baseline_ These are explai ned later in th is section . This is largely special to open source projects.

Sec Figure 8.33 for the project tructure_

Proposed Eclipse Project Structure and Roles Top Lovel Project B

Top Level Project A

Project 1

ProJOC'Ilead

Prole~

2

Project 3

Development Toam

Subsystem(s)

Comm.nors

Top Level Project C

Project Management Committee (PMC)

Project Plan

T"" lask2

T.... 3

Figure 8.33 EcJJpse proJeC1-ploposed structure and roles SOtNce: Ed.pose Protect. hltp'J IWWW ecJ~ org.IOr'gIOOCuIllE ntslECllpseS2(C s 'llocltnentYa2OProceS$1It202OOJ~ t 1_OK2QF~pdf

CASE STUDY: PROJECT MANAGEMENT IN ECUPSE

CHARTER FOR THE ECLIPSE TECHNOLOGY (TOP·lEVEl) PROJECT The "Eclipse Technology Project" diflers ITOm the "Eclips.... Project." The following document includes a description of project management in Eclipse. It is fou nd .t http-Jlec1,psc .org! technology/ technology -ch.rter.html and h.s been reform.tted and .nnotat .... d by the author. As described below, • project can migrate from being an "Eclips.... Technology Project" to being an .. Eclips .... Project: This "ch.rter" docume nt mainly d .... cribes organization .nd manag.... ment. Without committing this kind of thing to paper, there would be little c hance of a successful outcom .....

overview This is a good overview. It includes the overall motivation lor the project and, as with.1I good overviews, does not attempt to provide comple!e descriptions. It starts by providing the motivation for Eclipse.

The Eclipse Tec hn o logy Top-Level Project (the ' Eclipse T echnology Project") is an o pen source sofrware researc h and development proJec t. whi ch encapsulates three related activity streams. each of which is based o n or uses the Eclipse Platfom, andlor Eclipse Tool s: I. Academic research projec ts and o ther exploratory investiga ti ons ("Research Stream'), 2_ Development of educational matenals , tNc hing aids • and courseware ("Education Stream"), 3 Incubati on of smail -sca le . innovative platform and tools projects ("Incubators Stream").

small , informally structured prOjects that add new capabl),ties to the Eclipse software b.se (l ncub.tors Stream). fos ter gre.ter communtty .w.reness and underst.ndlng of Eclipse (Education Stream). or explore researc h ISsues in Eclipse -re levant dom.ins uc h as program m"'g I.nguage , tools, .nd development envlfo nments (Rese.rch Stream). The Eclipse T echno logy Project IS Inte nded to : I . Provide the o pen source commun ity with a

lighter-weig ht .Itern.tlve to the I.rger scale, more strucrured development activities carried out by othe r PMCs, .nd 2. C rea te o pportu nitte for rese.rc hers, ac.de mlcs, and educators to playa Significant ro le Within the Eclipsc com munity

Scope A "Scope" seClion in • docume nt often refers to the scope of the document itself, th.t is, the exte ntth.tthe document is intended to cover. Th.t is not the case here _ This section describes the scope of the .ctu.1 Eclipse Techno logy Project .

The scope of the Eclipse T ech nology Project Will encomp. s a Wide v.nety of small prOjects rather than a few large o nes. Although .ntlClp.tln g e no rmous diversity In the coment of these aClIvitle , from a process·oriented viewpoin t the y will all share important common characteristiCS, which argues (or a commo n management envelo pe:

• Focus on pr
MiSSion

• Sma ll teams

The mISsion of the Ec),pse Te hno logy Projec t IS to pruvlde a ho me With", the Ec),p>c Foundat io n for

• Rcsour e comm itm e nts te ntalt ve, due to vol unte~r labo r o r la k of ponsor funding

197

198

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II ESTIMATION, SCHEOUUNG, AND PLANNING

• I cvclopmc nt ol tcn ross·cuts the ~CO I)C o f <evera l o ther E Ilpse Foundation Proje ts

n,e

Eclipse T ec hno logy Pmjt t serves as a inSIe pOint of fo us for such teams, and provides the m wit h a h o me wllhin the Echpsc commuI1Ity . In man y cases uccessful Researc h Projects wi ll evo! c into IOcuintor

I

and Incubator.-. in turn ma y

migrate to oth er Projc 1 ManJgcmcnt

project Management Committee This section speciAes the Eclipse project man· agement by specifying the responsibilities of the project manageme nt committees.

The projects under thi s c harte r are managed by a group known as the Project Management Com· mittee PMCs are expected to e nsure that, • Each projec t opera tes effec ti vcly by providing leaders hip to gUide the project's overall direc tio n and by removing obstacles , solVing prob lems, and resolVing conAlcts. • All project plan s, tec hni cal documents, and repo rts are publicly available. • All projects operate usi ng o pe n source rules of meritocracy .

• Ensunng that prOjeL t plans arc produced. • WorklnS WIth the Eclipse Management Organlza . tion (the EMO ) to c'tabhsh the development processes a nd infrastructure nceded for the devd. opment team to be errective

o mmittecs

(PM s), ei ther by me rgi ng into an existing project, or by fo mllng the basi for a new o ne . . .

engagement:

rCl110vtng ob,r" 1«, so lVIng problem" and resolv. ing conflIcts.

tran sparency ,

and

open panicipation . These principles work to · gether. Anyone ca n panici pate in a project. This ope n Interaction, (Tom answerin g questions to

repon ing bugs to makIng code co ntributions to c reating dcsig n~, enables everyone to recogni ze and utilize the Contribut ions.

Documents should explain abbreviations lhe Arst time they arc introduced, like lhis, but also include them in a glossary SO that the readrr knows where to look for an explanation. 1ne reader is expected to know the meaning of "the Eclipse Management Organization: This is normal , the project management for a softw~ developme nt effort typically reports to a higher. level person or body within the company.

• Reco mmendin g new projects

to

the EMO .

• Recomme ndin g the initial se t of project commit· ters for each new projec t overseen by the PMC, and e tabl ish ing the procedures consistent with thi s charter for votin g in new committers.

• H elping to ensure that the projects overseen by the PMC have e nough contributors, and working to fill vacancies in role .

• Produci " g "how to get involved' g uidelines to help new pote Atia l contributors get started . • Coordinating rel ationsh,ps with other Eclipse Foundation Projects. • FaCilitating code or other donations by individual or companies .

• Making reco mme ndat ions to the EcI ,p e Founda· tion Board

The PM C has the fo ll OWi ng responsi bilities, • Providing the leadersh Ip and viSIon to guide the projcctJs overall direction in a manner con~i s t e nt

(This IS the overall controlling Eclipse.)

body for

with the Eclipse FoundatIon Architectural Roadl11ap. • Providing assistance and
regarding contributio ns proposed under Ilcensrs other than the 'tandJrd .,., ,,,..d by EcI,p5C

CASE STUDY: PROJECT MANAGEMENT IN ECUPSE

• Working Wifh the EMO and committers to ensure that in-bound contributions arc made in accordance with the Eclipse Foundation IP. (Jntenectual Property)

Policy. • Acting as a focal point for the community in re:p=enting the projects it oversees.

Since Eclipse is open source, this documenta. tion has to include procedures that ensure the continued existence and health of the Project Management Committees (PMCs) themselves.

monitor the main roject mailing list and the devel opor mailing lists for all projects and components they are overseeillg.

Roles Many roles in an open source development are: typically different from commercial develop· ment roles. They depend on volunteers and not paychecks. For that re:ason, there: is Increased potential for participants to come and go. This document de;cribes policies to deal with this. The projects under this charter arc operated as meritocracies: the more you con tribute , and the

The PMC lead is appointed by the Board. The initial PMC is selected by the PMC lead. Thereaher, to become a member of the PMC, an individual must be nominated by another member of the PMC and unanimously approved by all PMC members. In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by unanimous vote of remaiOlng PMC members. PMC members may resign at any time by delivering notice of their resignati o n to the PMC lead. The PMC is responsib le for produci ng and maintaining the project charter. Development must conform to any rulcs or processe outlined in the charter, so a change to the development process may necessitate a change to the charter. C hanges to the charter are approved by the board The work of the PMC is shared by the PM C members. All PMC member arc expectcd to contflbute actively In particular. PMC membt-rs arc expected to take responSlb"ity for overseeing crtain areas of work in the project, and reporting to the PMC on these arcas. Active participation in the user new
higher the quality of your contribution , the more you are all o,,'ed to do H owever, with this comes increased responsibi lity.

Users Users are the people who use the output from the project. Output will typicall y consis t of software and research . Software in this context means intellectual properlY in electronic form , including source and binary code , documentati on, courseware, reports ,

and

pape~ .

Developers Users who conrribute soft\vare or research become developers. Developers are encouraged to partici pate in the user newsgroup(s), and should monitor the developer mailing list associated with their area of co nrributi o n. \XIhen appropnate, dc velope~ may also contribute to development desig n discus io ns related to their area of conrnbution. Developer are expected to be proactive In reporting problems In the bug tracking system .

Committers Develope~

who gIve frequent and valuable ontnbu · tions to a project , or compo nent of a proJcct (Ill the

199

200

CHAPTER g PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II ESTIMATION, SCHEDULING, AND PLANNING

ca,c o( large proJcct,), an h,ve Ihelr 'talll' promoted to that o( J • (1II1mIIlC( for that project or omp!}nenl ~,p<'t.tivcly A comnllllcr h", wTite access to the sou~e de repo>l tory (or the .«ocIJted proJcct (or o mpo· nem), and gall" votlllS rights allowlnB them to affect the fu t\J~ of the proJcct (or compone nt).

The followlIlg par
In order for a developer to become a committer o n a particular project overseen by the PMC, another comminer for the some project (or component as appropriate) can nominate th,t developer, or the de· veloper can ask to be nominated. Once a developer is nominated , the committers fo r the project (or compo· nent) will vote. If there arc at least three positive votes and no nega tive votes, the developer is recommended to the PMC for commit privileges. If the PMC also approves, the developer IS converted into a comminer and given write access to the source code repository for that project (or component ). Becoming a commincr is a privilege that is earned by contributlllg and showing discipline and good judgment. It is a responsibiliry that should be neither given nor taken lightly.

A good management document anticipates negative circumstances like the following .

At times , comminers may go inactive for a variety of reasons. The decision.making process of the project relies on active commincrs who respond to di cussions and votes in a constnlctivc and timely

manner. The PMC is responsible for ensuring the smooth operation of the project. A committer that is disruptive , docs not participate actively, or has been inactive for an extended period may have his or her commit status removed by the PMC. Active participation in the user ncwsgroup and

the appropnate developer mailing Ii ts is a responsi· bi lity of all committers, and is critical to the success of the proJect. Committers Jre required to monitor and contribute to the use r newsgroup

omm llleT> arc reqUITed to monitor the devel· op r m.dmg Ii t .<soc,ated With all prOjects and compo ncnts for which they have commit pnvdeges ThiS 1<" ond ltJon of being granted <.Ommit righi, to the prOject or component. It IS mandatory bccau~ commltters must participate in votlllg (which In orne ca,es reqUIres a certam minimum number of votes) and must respond to the mailing list III a timely !-ashion in order to faCilitate the smooth oper
information from the submitter. Committers are responsible for updating problem report. when they have done work related to the problem .

projects The work under this Top · Levei Project is further organized into projects. New projects must be con· siste nt with the mission of the Top. Level Project, be recommended by the PMC, and conRrmed by the EMO. Projects can be discontinued by decision of the board. When a new project is created, the PMC nominates a project lead to act as the technical leader and nominatcs the initial set of commit~rs for the project , and these nommatlons arc approved by the EMO . Project leads arc accountable to the PMC for the success of their project .

Project Organization This section describes the o ....niDliun projcclS within Eclipse,

of

CASE STUDY: PROJECT MANAGEMENT IN ECUPSE

G"oen the fluid nanu'e of EcI ,p<e Te hno logy Projects, organozational c hanges arc possible , in par. t,cul • .., d,viding a Project into components; dividing a Project into two or more independent ProJect . and merging t"'o or more Projects into a song Ie Project. In ea h case the initiative for the c hange may come either fro m within the Project or from the PMC , but the PMC mu t approve any ch ange, and approval must be confirmed by the EMO. If a project wishes to di vide into compo nents, commit privileges arc no nnall y gra nted at the com . ponent level , and the committe rs fo r a given com . ponent vote o n issues specific to that component . Components are established and discontinued by the PMC When the PMC creates a component it ap· points a component lead to ac t as the techn ica l leader and names th e initial set of comm itteTS for the component. The compone nt lead is designated as a committer fo r the project and represents the component in discussions and votes pertaining to the project as a whole. Component committers do no t participate in votes at the level of the project as a whole, unless they are also the component lead . In cases where new projects are be ing created , either by splitting or by mergi ng , the usual proce· dures as set forth in this c harter are fo llowed . In particular, developers will not necessanly have the same rights after an o rganizatio nal c hange that they enjoyed in the previous strucn" e .

This section is a useful checklist for most softwao-e projects.

The PMC works with the EMO to e nsure the required infrastructure (or the project. The project tnfrastructure w,lI ,"elude, at monimum: o

o

o

Bug Database Bugz ilia database for trac kin g bug< and feature requests Source: Repository - One or more V reposi to · roe, COntalnin/! all the ~oftware for the projec ts Web Ile- A W eb \lte Will onta in in formati o n about the proJect, In 11Idlll~ docum e ntallOn,

report, and papers, coursewarr, downloads o( reo lease" and thIS c harte r. o

o

o

General Mailing List-Ma,ling list for develop· ment dl scu sions pertaining to the project as a whole or that cross projects Th is mailonB list IS open to the publoc. Project Mailing List-Development maili ng list for technica l di scussions rel ated to the project. This mailing lost is ope n to the public. Compone nt Mailing List-Development mailing list for techn ica l di scussions related to the compo · ne nt. This mading li st IS o pe n to the public.

The Development Process In this section, the phrase "release cyde" wi ll refer to a signiri'cant block of project activity , which corre · sponds to an ac tu a-l rel ease cyele in the case of incubators or Education Projects , o r to a majo r stage of a phased Research Project.

This assumes an interactive development pro· cess. However, each iteration is actually released, and so must be a usable version of the product.

Each project lead must produce a development plan for the release cycle, and the development plan must be approved by a majority of committees of the project. The plan must be submitted to the PMC for review. The PMC may proVide feedback and advice on the plan, but approval rests with the p,oject committees.

The document mandates he re that each project provide a requirements document. It would have been better to be more speCific about where such documents arc deployed : it is not easy to And Ectip e requirement docume nts in prac tice, and It Is questionable that they exist in many cases. Even for non ·open source project , It an be dlmcult to understand the extent of doc ume ntation . This IS sreatly larifled wilt'n an organization stondardi zes o n documt'nt a· t'on types (e.f( ., selected IEEE ta ndards).

201

202

CHAPTER 8 PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT II" STlMA TlON, SCH DULING, AND PLANNING

EJLh proj 0 11 Its

t mll
cb .. he , th e rcqulrc mcnl C:; .1nd pnontl zall ul1l.i

it i \ orking al't' II'\! ,n the curre nt re i , e cy Ie, In addll,on , each proJe l n""t PO,l J release p lan sh o wll1 g the date and co nt e nt o f the nex t major rel ease , in ludlng any mJJo r mdc .. to ll c!t. and must

kee p this plan lip to date T h e o mm itters o f a prOjec t o r compo ne nt d eCIde whic h hanges ma y be o mmittcd to the m" tel' code hase o f a project o r compo nent , respec · ti vely Three + I ("yes" votes) \Vllh no - I (" no" votes or vetoes) a rc needed to approve a code hange, Vetoes must be fo ll owed by an exp lanati o n fo r the veto within 24 ho ur or the veto becomes invalid , All vo tes are co nduc ted v,a the devel oper mailing list assoCia ted wi th th e prOjec t o r compo nent.

Special rules ma y be eSlabli he d by the PMC for prOjec ts o r co mpone nts with fewer than three co mmitters. For effiCIe ncy , o me code c han ges fro m so me contribut ors (e ,g " feature addit io ns, bug Axes) ma y b e app roved in advance , o r ap · p roved ,n prinCip le based o n a n o utiine of the work , in w hi c h case th ey may be comm itted Arst a nd c h a nged as needed , wi th co nnic ts reso lved by majo rity vote o f the co mmitters of the project o r compo ne nt, as appli cable , The master copy of the co de base mllst res ,d e o n the projec t W eb site, where it is acce si bl e to all users , de vel opers , and c o mmitters, Committe rs must c h eck the ir c h anges and new work into the master code base as promptly as po sible (subject to any c heck · in vo tin g rules that ma y be in effec t) in order to fosler co llabo ratio n am o ng widel y di stri · buted gro ups and so that the late t work is always availabl e to everyo ne , The PM C , responsible for workin g with the Eclipse Foundatio n to establish a release e ngi neering and build process to ensure that builds can be reliably produce d on a regular and frequent basis from rhe ma ster code base and made available for download from the projec t Web si te . Builds in this context are intended to include not only code but also reports , documentation , and

Th" docume nl docs not eS labllsh quality goal As a resull, there ,s s'gn,hcant vanatlO!> in the qua li ty of Edpse prOjeCIS, A commer· c ial e fforl would be ",uc h more , pc(.,nc ,n this res pel. L

All development techn,cal diSCUSSIOns are con· ducted u Ing the development mailing lists, If d,scussio n< are held offl ine, the n a summary must be posted to the mailing list to keep the o ther comminers informed.

Licensing All co ntribut,o ns to projects unde r this c h arter must adhe re to Ihe Eclipse Foundation Intellectual Prop · e rty Po licy ," Eclipse i o rganized into the Platfo rm , JOT, and POE subprojects as fo llows [7].

In describing the management of • projcct, it may be necessary, as here, to refer to particular requirements or design issues. Otherwise, we try to separate project processes from require· ments , Requirements are not known during the Arst iteration of project management docu· ments but they do become known more during subsequent iterations,

Platform

'The platfo m, project provides the co", frameworks and services upon which all plug . in '"-xtensions are created . It al 0 provide the runtime in which plug · ins are loaded, integrated, and executed. The primary purpose of the platfom, subproject" to enable other tool developers to ea ily build and de liver integratro tools."

JOT

courseware.

Each project is responsible for establishing test plans and the level of testing appropriate for the project ,

"The JOT (lnlHl Droclopm(nl Tool ) proJcct provides the tool plug. ins that implement a Java IDE Sl'pportil18 lhe developme nt o f any Java applicatIOn, IOciUdlO8 E II~

CASE STUDY: PROJECT MANAGEMENT IN ECUPSE

"I
A method of prOViding some shon·t¢rm doc· ument history.

PI,as, smd com",mls aboul Ihis drafl p"'n ecl 'pse·[email protected] d",t/op
10 Ih,

POE 'T he PDE (Plug.I" Dwt/opmrool En voro"mnl l) project provides a number of views and editors that make is easier to build plug . ins for Eclipse Usi ng the POE, you can create your plug·in manifest file (plugon xmll, specify your plug· in runtime and other required plug·ins, define extension points, including the or specific markup, associate XML Schema files with

As an application, Eclipse has f,al1ms . As a platform, Eclipse has to have an API stl, a means for interfacing with il (or programmers extending It.

the extension point markup so extensions can be

Thos document lays out the feature and API set for the next feature release o( Eclipse aher 2. 1, designated rel ease 3.0 (Why Eclipse "3.0") .

validated, create extensions on other plug.in exten· sion points , etc. The POE makes integrating plug·ins easy and fun ." These subprojects are further decomposed . For example, the Platform subp roject is broken down into componen ts. Each component operate like a

A hyperlinked table of contents like the fol· lowing is useful. Notice the emphasis here on deliverables and schedule, expressed in the first item .

project unto its ow n, wi th its own se t of com m it·

ters, bug catcgorie5, and mailing lists. These are as follows [8],

Release deliverables Release milesto nes

Project Name

DeSCription

AnI

EclipsclAnt integration

Compare

Universal compare facility

•

•

•

Targct operating environments

Compatibility with previous releases Eclipse Platform subproject

•

Java development tools UDT) subproject

DRAFT PROJECT PLAN FOR ECLIPSE RELEA.SE 3,0 The following is excerpted and quoted from the projec t plan for release 3 of Eclipse [9]. It provides an example of a specific project plan when compared with the c harter LAsI rwistd Friday, J.nuary 30, 200< (' ",arb 1.lmsli09 chan9cs IInC( Ih, prtOIOU S drnfl of Oclob" 27, 2003 ) .

Plug·in development subproject

environment

(POE)

This part is a seop" statement. It also specifies the management of this document and pro· vides an overview.

Plans do no t materialize Ollt of nowhere, nor are they entirely stiltic To ensure that the plannong process

203

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II: ESTIMATION, SCHEDULING, AND PLANNING

I tran<po",nt and open to the en tire E itp
PM:: = Project Management Contmi[t",e .

The Irs t part of the plan deals with the impo r. tant matte rs of re lea c deliverables, release mil e· stones, target operatin g envi ronments. and release-

to·release compa ttbility. These are all things that need to be clear fo r any release, even if no featllre were to change.

The remainder of the plan consists of plan items for the various Ecli pse subprojec ts. Each plan item covers a feature o r AP I that is to be added to Ecli pse, or some aspect of Eclipse that i< to be improved. Each plan ite m h as its own e ntry in the Eclipse bugzilla database, with a title and a concise summary (usua lly a si ngle paragraph ) that exp lains the work item at a SUitably high e nough level so that everyone can readily understand what the work item is witho ut haVi ng to understa nd the nitty ·gritty detail.

Note that, in place of a detailed requirements document, the detailed requirements are effec· tively provid",d via the Bugzilla database, where there is no real distinction between required fearur"" and a bug in what's been implemented. Bugzilla is an open source defect tracking appli· cation. 5<-e httpJlwww.bugzilla.org/. A refer· ",nee on Eclipse's specinc use of Bugzilla is at httpsJ/bugs.eclip"".orglbogsldocslhtml

• • • •

A seri"" of dots, as her", (an "ellipsis), indicates that the .uthor omitted material from the original in the inrer",st of brevity. The activi · t;"'s listed in the next paragraph are consid",red Nmaint",nancc: the topic covered in the last p." of this book,

WIth the preVIOllS re lease as the starting pOInt, !his i< the p lan for how we wi ll enhance and Improve It h xinl! bUf(s, imprOVIn g te
This provides more on the sCOp'" of thIS docu· ment. The activities listed are cODsidered "mainte nance: covered in the last pan of this book . A three · part scheme for require· ments priority is used , with the added ore· jected" category. This merely k","'P' track of requirements that were proposed at some point .nd rejected.

The c urrent status o( each plan item is noteel Committed plan item A committed plan item is o ne that we have decided to addr""s for the release . Proposed plan item-A proposed plan item is o ne that we arc considering addr""sing for the release. Although we are actively inves:igating it, we are not ye t in a position to commit to it or to say that we won't be able to address it. After

due conSidera tio n, a proposal will either be committed, deferred, o r rejected. Deferred plan item A reaso nable proposal that will not make it in to this release for orne reason is marked as deferred with a brief no te as to why it was defellcd. Defellcd plan items may resurface as committed plan item at

a later point . Rejected plan item Plan items that were praposed but judged unworkable are marked as rejected plan items, with an accompan ing Slun' mary of why they were dlsml sed. Keeping tT3Ck of rejected Items avoid, repeatmg the di. ion.

CASE STUDY: PROJECT MANAGEMENT FOR OPENOFFICE

tria8~ classiRcOflon , except Ihill ilems considered and rej~c ted are milinlilin~ lor reference.

This is more or

I~ss

a

Release oeliverables The release deliverables have the sa me fo rm as previous releases, namely , o

o

8.6 CASE STUDY: PROJECT MANAGEMENT FOR OPENOFFICE The case tud y ,n thi S sectio n pro vides excerp ts fro m the O pe nOffice pro ject management plan Fo r the most pa rt. we will use the same headings as fo und in the offiCial O pe nOfnce docume ntatio n

OPEN OFFICE PROJECT GUIDELINES

Source cod~ release fo r EcI,p c ProJect, ava il able as versions tagged "R3 0" in the Ecl ipse Project CVS repository . •

•

•

Note to the Stude nt: n,e fo llo wing is take n fto m h ttp Jlwww.o pcn. o fRce o tg/ d ev d ocs/guidel ine s. html . with mino r editing. It is titled ' CUldelines fo r Partici· pating on OpcnOfficc.org' and constitutes a proj· ect manageme nt subject.

•

Release Milestones Release milestones occurrin g at ro ughl y six· week intervals exist to facilitate coarse ·grained plann ing and staging . The milestones are as fo llo ws.

There is an attempt here to pace milestones at regular intervals to facilitate regular communi· cation . Oth~rwise, long gaps wo uld occur in which no communication is guaranteed, which is undesirable .

o

o

o

Friday June 6, 2003-M ilesto ne I (3. 0 M I ), stable build reflecting progress Friday Jul y 18, 2003-Has been tested and vali · dated In the targe t o pe ratin g co nfig ura tio ns Ii ted below. •

•

OpenOfflCe.o rg IS an open source prOject th ro ug h which Sun Mic rosystems has relea ed the tec hno logy fo r the S t a rOffice!T~" prod uc ti Vity
commun i allOn

mcc harllsms,

such as mailing lISts and fo rum O pe nOffi e.org has cstabli hed the necessary fac dot ies to make thi S open ·sour e tech no logy ava" · abl e to all inte re
The remainder of the mat e rial at http ,llwww. ecl ipse .org/ec I i p se/deve I0 pmen tl ec Ii pse_ proj~c,-plan_ 3_0 . html c onsis ts o f require· ments, and are excerpt e d In C h a pter 18, th e ~quirements Analysl part of thl ~ boo k.

and

Es tabl IS hm e nt of open, XML· ba<ed standards fo r of Ace p rod uc ti Vity fi lc fo rm ats and la nguage ' lIldc · pe nde nt bind"' gs to compo ne nt AP I.

• Ope n a c'\!!o to the source.' code: Vl a

V ver-C; lon·

to e nanl e ",nova tio n for bUil ding the next ~c n cra ll o n ope n-network pro du [lVll seNI C: ' 111 8

or

205

206

CHAPTER 8 PRINCIPLES OF SOFlWARE PROJECT MANAGEMENT II. EST IMA nON, SCHEDULING, AND PLANNING

GOVERNANC E

OpenO/A e participant: members, ckvelol'Cn, and prOject leads . The e are explained next."

For a proprietary project, thIs would correspond to a management section. MEMBERS penOfRce org I governed b), the Communtty CounCIl , which is constituted by member> from the Open fA e .org community . They creJled the charter establishing the ouncll ll,e Council holds penodic meetings by IRC a well as conducting business via discu [email protected] .org mail list. Both IRC records and mail · ltst archives are public Agenda items may be proposed by any member and should be sent to [email protected] .org . For more information, go to the Council Web ite. The following ections describe guidelines regarding technIcal roles and responsibilities at OpenOffi e org and handling of source code. Sub· stantia l enhancements or mod lAcations of these guidelines need approval of the Communiry Council. For guidelines on the protocols for proposing projects 10 OpenOfflce.o rg , please sec Protoco ls for Project Proposal.

ROLES AND RESPONSIBILITIES Everybody can help no matter what their ro le. The more a person gels involved in the project . the more h e or she develops a trusting relationship with others. Those who have been long ·term and valuable contributors to the project earn the right to commit directly to the source repository. OpenOfflce.org respects the rights of its com· munity to post messages and use the mading lists to further the aims of the project. In fact , we cncour· age people to usc Ihe mailing lists. To this end , we will do our best to I,mil "spam" and to ensure that communication among community members

I

car-

ried out politely and efficiently . We have posted some "Mai l·List Guidelines" that detaIl our

"Members" rders to those persons who have JOIned the project by regi tering WIth OpenOfficc.org and have a u ername A member may not have subscribed to a mailing list, and a subscriber to a mailing list who is uSing Ihe project may not have registered, only tho e who have regIStered arc members. It IS strongly encouraged that all members joi n the general and relevant specinc prOject lists as well as joining a particular project. Initially, one can only Join as an observer, a role that allows one to contribute to the project and otherwise participate in it. DEVELOPERS

Written rules like these are essential for getti ng the job done. Without them, there would be c h aos a nd no OpenOfnce.

Project members who give frequent and valu· ab le contributions to a project can have their status promoted to that of a "deve loper" for that project. A developer has write access to the ource code repos, itory . A "content developer" has write access to a project's documentatIon but not to the source code In order for a contributor to become a developer, another developer has to nominate that contributor The project lead may convert the contributor into a developer and give write acces to the source code repository for the project. Al times, deveiopers may go inactive for a variety of reasons. A developer who ha been Inactive for six months or more rna

lose his or her

status as a developer. In Ihis ase or if the value of a developer's contributions dimlllishe wTit~ access may be revoked by the responsible project lead. A commItted change mu1 I1t of a I

commitment.

We would sute here something like the follOWing: "There are several categories 0/

CASE STUDY: PROJECT MANAGEMENT FOR OPENOFFICE

'bug

fu, commit The situation must be rescinded

bcfoit the cha~ can be included in any public release. belongs on a location whe~ ipOLi8c ruI~ lI~ gIVen for committing code to

This

OpenOIficf:.

PROJECT LEADS There are three main categories of public projects in OpcnOfAce.org : • Accepted projects ("projec ts") • Incubator • Native-lang All accepted projec ts must have two leads. It is up to each project to determine the actual cor.te n. of the roles each lead will take o n . Nati ve- lang and incubator projects may have o ne lead . Size and complexity are the determining factors : a large proj ect requires two leads .

P,-esumably, the ~qui~ment lor two committed project leads minimizes the risk that a lead becomes unavailable, thereby threatening the health of the project_ This is a facet of risk management.

A project lead is res po nsibl e fo r givin g guid ance and directions fo r his o r he r project a nd it part in the OpenOffk e .o rg e ffo rt _ The lead es pecia ll y should make sure that q uestio ns abo ut his o r her project are answered a nd tha t a frie ndly and up portive enviro nm e nt is c reate d . Co ntributio ns. maillist diSCUSSions, and fo rum inte rc hanges. as we ll .s is>ucs and other adminis tra tive duties should be handled in a n e ncourag ing a nd pro du li ve fa hlo n. Los o f project lead ~ t a tus may occur no . o nl y due to contrtbullo n inac t iVIty (as descrtbed fo r de velo pers ) but a lso because o f m lSsrn g ful Alime nt of responsibilitIes fo r the projec t the project lead is 10

c harge o f. Any member o f the affected projec t may ask fo r the C ommun ity CounCIl to reconsIder a project lead , o r to interve ne in disputes o r questio ns co ncern ing project leadc",hlp _ A decision by the Commun ity C ouncil IS requ ired to revoke project lea d status. A ny me mber o f a project is el Igi ble fo r e lection to projec t lead of tha t project Electio ns arc arranged by th e project concerned . A list of our current project leads can be fo und in the Irs. of projects.

SCHEDULE See httpl/d,:velopme nLopcnoffice.orglre leaseslOOo_ 2_0_timetable.htrnL

SOURCES This section is effec tivel y a Software Configu ration Manageme nt Plan .

The codebase is mai nta ined in share d info rma tio n re posi .o n es usrn g C VS O nl y developers and project leads have write access to these reposi tOries Eve ry o ne has re ad access via a no nymous CVS or the Web fro nt end _ All sourc e cod e co mm itted to th e p roject' re posi to ries mus t be cove red by LC PL and S ISS L Fil es in the rcp o itory must conta in a h eade r acco rdin g to th e O pen OfRcc.o rg te mpl ates (avai lable fo r code and makefi lcs). Co ntrib uto rs of source code large r .h an s mall c ha nges must have sig ne d the JO Int copy rr g ht a sig nme nt fo rm before the ir co ntributi o n can be comm itt ed to the rep osi tory . Strai ghtlo rw ard patc hes and fea ture Impleme ntat ions can be committed wi tho ut prior no llce o r di scussio n. Doubt ful c hanges and large -sca le overhauls need \0 be d iscussed before comm itting them into the re pository . An y c hange th at affects the se mantics o f a n eXIstIn g API hrnc tion. co nfigura tI o n datal o r Alc fo rmalS o r other major arc3!t m us t re CIVC a pproval A proJe t lead may Info rma l! ap prove c ha nge< with in h,s or her project n,e re are .h ree dIffe re nt ty pes of c han ges·

207

208

CHAP IER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGE MENT II ESTIMATION, SCHEDULING, AND PLANNING

Info Recommended

Required

Informational notice about an API change; no developer action necessary, Use the new API as soon as possible. The old API is obsolete and might go away In the near future. New code should always use the new API. Not com plying with the new API will break the build or cause runtime failure. Developer acbon IS mandatory.

This gives a grea t deal of d iscreti o n to project leads. A more fo rmal process, involving more people , may be Impractical for an open source project like this. Proposal< for mterproject changes of type "rec· ommended" or "reqUired' must be published wi th the sugg"'ted change date to the interfucc d iscussion mailing hst After o ne week of review, a change announcement mus t be published to thc interface anno unce mailing list Dunng this announcement period, dependi ng projects have to prepare their projects fo r the changt-s so that t he fo llowi ng build Will not break They are n..-sponslblc for reflecting th e c han ge In th ei r proJect , no t the requester. W ithin the two weeks of diSCUSS ion/a nno uncem ent, project leads may ra ise a Aag, and project leads majority has to deCide about ca ncellation o f the c hange requt-st.

IOtO prac tice by a h ypothetical stude nt prOject team, using the Encounter case study as In example.

• Before beginning the Software Project Man · agement Plan (SPMP), t he team met at least o nce to diSCUSS the prOject in ge nera l te rms, a nd Ed Braun wa elected a team leader. The configura tio n man· age me nt plan (SCMI') and quality plan (SQAP) were written.

PREPARING FOR THE PROJECT PLANNING MEETING Well befo re the mee .ing , Ed looked through the IEEE SPMP headi ngs (refer to Figure 8.24 ) for the major issues, and drafted material for each of them . in t he cascoof the Encou nter vi deo ga me, he co nsidered th ese to be the project o rga nizatio n (primary and backup roles, and their responsibilities) (Section 4.3 in Figure 8. 1), risk manage ment (5.4), and the sched· ul e (5.2 ). Ed also drafted a brief parag raph for Sectio n 1.1 (project summaty ). He left the staffing plan blank (i.c., who nils what ro le) because he felt it best to have membe rs volunteer for roles at the meeting. He planned fo r th e remain ing issues to be ri lled in a fter the meeting. Via e · mail , Ed asked

fo r a volunteer to pcr(onn cost estimation, since this Th= documents provide a flavor for the man· agement of the OpenO fficc project. They arc not intended to be complete.

8.7 CASE STUDY: STUDENT TEAM GUIDANCE TI'l is section describes a hypothetical account of inter· actions among students as they prepare and conduct a project planning meeting, and guides students in producing a Software Project Management Plan .

8.7 ,1 Team Guidance: Steps to a Project Management Plan for Encounter Note to the Srudent: This section explains how the principles explalOcd in this part 01 the book arc translated

,

i a .ec hnical task that requires sig nifica nt lead time, and IS best done by o ne or at most two people. Ed wro te up opti ons fo r objectives and priorit · ies ra.her than selecting the top priority, since he did no t want the group to fee l rai lroaded int o a deCisio n. H e included "attaining quality goals," "developin g so met hing that the members ca n usc" (a favorite of his), and "complete project o n schedule" as opt;ons fo r thc top prio rity. He was pretty su re that the group would ag ree to a flat ro le · based o rgani za tion as d esCribed in ection 9 4, so he wrote this into the straw man document. V ia e· matl , Ed asked team members to think about the ns ks that they consider threatening to the project , and to send write -up to him 48 hours befo re ,he meeting, in the fom, of Table 8, 1 in Sect ion 10.4 . Karen was concerned about the g roup' Java cap.bili"es. he commullIcoted with the reS! of the te.m about their knowledge of Jav.,

,

CASE STUDY: STUDENT TEAM GUIDANCE

lind d~crib"d this risk a speclRcally as she could . She also ~searc:hed companies that provide o n-SIte training 3t short notice. Her step -by-step rIsk ~ti~ment plan was included in the malerial she sent to Ed. Hal Furnass had a concern about superimposing images in Java , and he sent h is n sk identification and retirement write · up to Ed . The latter collected these in the straw man SPMP, and listed them in priority. Ed then drafted the following agenda for the m~ting .

Meeting to be held in Engineering 397 at 10:00 a.m. to 11 :30 a.m. Friday, September I 1. Appoint record keeper and time keeper (5 min · utes, 10:05)

2. Approve agenda and times for this meeting (5 minutes, 10: 10) 3. Review SPMP sections supplied by Ed (25 m in· utes, 10:35 ) 4. Allocate remaining SPMP section to writers (20 minutes, 10:55) 5. Arrange review process (via e-mail andlor meet ing) (5 minutes, 1 1:00) • 6. Brainstorm for additional risks ( 10 mlOutes, 11:1 0)

7. Rev iew action items (5 minutes, I 1: 15) 8. Miscellaneous business ( 10 minutes, I 1:25 ) Ed e -mailed the agenda and his straw man SPMP to the team members two days before the meeting, and asked them to read it over before the m~ting . His version of the SPMP contained all of the IEEE headings .

THE INITIAL PROJECT PLANNING MEETING At the meetIng , Ed asked Fern to re cord action ILems and major deciSIons, and asked AI to watc h the time and remInd the team if It exceeded planned l,mits, It wa s unders tood th at the se two roles would rotate among the members In futllr., meetings Most of Ed's Id eas were accepted . Sev. eral c hanges to Ed's proposed schedul e we re

suggested . Hal pushed very hard for a buffer week in which no tasks are assigned . Karen pointed out that no work hould be aSS Igned during the week before the midterm . There was also a discussion of using a simple waterfall to avoid the compl, cat ,ons of revisiting document , but thI S was dismIssed as not reRecting the real world . Fern pushed for Incremental development because she wanted to begin coding as soon as possible , but there was little support for this because the team did not even have architecture yet . Members felt that "quality" was an area they needed the most practIce with Arter considerable debate about building an eXCIting computer game, the team decided that "the attai nment of the specified quality parameters" would be its top priority. It ,",'as recog nized that a quality ga me worth playi ng was ou t of the questoon in the time available, and that the actual capabi lities would be have to be minimal. When the tea m arrived at role allocation, Karen volu nteered Immediately for the "design leader" role . There were three volunteers for "imp lementation leader" and no ne for QA leader Ed compromised by suggestIng that two of the three people plit roles as QA and implementatio n leaders, switch ing halfwa y throu g h the semester. The other roles were filled , and Ed reminded them of their responsibilities , and of theIr addotional backu p ro les, as stated in the SPMP. The dis cussion of h ow to allocate the wflting of the SPMP went over its planned I,mot , but the discussion was productive and to the point , so Ed did not try to curtail it. It was de cided that on ly two team members besi des Ed would write the SPMP , and the rest would reVIew their writing , since ot would be too difficult in a
209

210

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II: ESTIMATION, SCHEDULING, AND PLANNING

110allzc the do lIment A tcn tatl c meeting was se t for l ondo at II · 0 a m . In Arts 283 in C" C It was

nece ory, and Ed was ta ske d wit h Informin!! th e team by unday ni g ht at 8.00 p .m. w he th er the meetinS wou ld be reqlllred or not. Fern reviewed the dcci ion made , who was to "'nrc what sect ions , and when the duc dales were , The meellng adjourned.

COMPLETING THE PROJECT MANAGEMENT PLAN In wrillng the document details, the team rea lized that vanou issues had not been disQJsscd at the meeting, Including th e deta ils of "mo nito rin g and contro lling" (Section 5 3 in Figure 8.24 ) Hal's Init"! write·up of this section spoke or man y meetings at which the project was to be reviewed , but most of the other member< fe lt that many of the meetings were un · necessary . After reading several propo als, Ed tned to resolve the c·mail discus ion by proposing that project monitonng be accomplished at weekly meeti ngs, supplemented by meeting at the inception of each phase (which he would try to fold into weekly meetings as well ). The team agreed. To allow for the possibility that more project meet ings would be needed, a second

weekly !Hne was selected which members would keep available, but would be used only If reqUired. /

The case srudy contains material concemmg liaison activtties. These are shown for illustratio n purposes, and would not normally be the res ponsibility of stude nt teams. Some teams mi ght want to designate a member as liaison to the instructor. Thi s is usua ll y best performed by the team leade r. If the project has a true customer (i.e., the project is not just an inven· tion of the team itsel f), then a liaison to the custome r would be required , the requirements leader wou ld normally ha ve this task. If the

•

projec t were an agile o ne, a customer repre·

<entative would be part of the team.

8.7.2 Team Guidance Management Plan

Software project

Stude nt teams shou ld c reate a Sofeware Project Ma nage me nt Plan (SPMP) fo r their project using IEEE Std 1058· 1998 as a template, the Team Guid· ance in the previous section, and the Encounter SPMP in Section 8.4 as guidance.

8.8 SUMMARY Projc:ct costS are estimated as early as prOject Ini tiation, well before the requirements arc defi ned. The earlier the estimate is made the greater the margin of erro r, and we therefore use ranges as a way to calculate estimates. For example, during c..onceptualizarion , co t estima tes ca n have a fou rfo ld estimatio n error,· afte r deSign , a ewofold error. Project eStimates are done by nrst fi nding something objective to measure , such as lines of code (LOC). Since this is done before any code IS ...'ritten , the applicati on IS compared to the LOC of si milar or related software produced in the same company, and the LOC of the new app lication is extrapolated fro m that. Ano th er way to produce LOC is to compute f.II Clioli POilil' , which objectively measure the intended fu nctionality of the new software. The function point calcu lation produces a si ngle number that is then converted to lines of code using a standard conversion . Once LOC arc calcu lated, the COCO 10 model can be used to compute an eHort estimate. Agile projects can be estimated by the use of story points, whic h are assigned based on a compa ri on of new stories to existi ng stories. For example, an average story 1S give n a score or 5, ilnd all new Slories art' compared to that story. Once an estimate is made, a detailed schedule is constructed that lists all the tasks, their duration, th.,r dependence on each other, and the resource assigned.

,

,

EXERCISES

A ... project . .m format.on . ..ncludml! . project . " plan is created that includ es aII prOject organization , roles and respons.b.Iot.es ' ks . It aIso mcludcs . . ' project estimate • sched U Ic, an d ns references to such doc'Ument5 as configurallon management , and verification and valodation plans.

8.9 EXERCISES 1. Describe in at least one paragraph at least two consequences of failing to develop a written project plan.

2. Suppose you are tasked with computing the numbcr of function poi nts for a small application . Assume the application implements the following functionality measures, all of which can be c haractcrized as having medium complexity: - number of external inputs: 4 - number of external outputs, 5 - number of external queries: 2 - number of internal logical files : 2 - number of external files : 3 - Suppose also that the application has the following ge nera l characteristics: - requirements backup, 0 - data communications: 0 - distributed processing: 1 - performance critical : 2 - hea vi ly utilized: 1 - online entry: 4 - multiple screens: 3 - master fidds: 3 - RIc inquiries: 2 - internal processing: 3 - reuse: 2 - conversion and installation : I - multiple installations: 0 - change and ease of use: 5 Compute the number of function points for this application . 3. Cost estimation is important , but can you cite. circumstance under which .t is probably not worthwhile performong at all? Explain yo ur answcr. 4. Give one major advantage and one major disadvantage to the use of function points on estimation 5. Ust a part of the SPMP that you r student tcam IS probably unable to supply at this stage of the project. Th.s refers to a part you will have to return to after mo re work has Ix.'en performed on the prOject 6 Explaon why project planning is considered one of the phase in the software Io fe cycle and al umbrdla act.vity that stretches acros several phases

0

an

211

212

CHAPTER 8 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT II: ESTIMATION, SCHEDUUNG, AND PLANNING

TEAM EXERCISE SPMP Develop a oftw.re Project Manageme nt Plan for YOllr project. Use (or tail o r, or improve upon) the IEEE sta ndard, as shown ," the cas. srud y bel ow, Include at least two ite ratio ns ," the sche dule, Obtain a roug h estimate of the size of the produc t, Befo re you begi n, es timate the number o f defects per page th e team th inks it will discover during its fIOa l revlc,,'. Keep track of, and report the time spent by individual members and by total team effort in the fo llowing stages: research , docume nt preparation , review (including inspections). Show the actual defect density (ave rage number of defects per page). Assess your team's effectiveness in each stage ," a scale of 0 to 10. Summarize in a narra tive, usi ng the numerica l results, and state how the team's progress could have been improved . The team is encouraged to usc additional metrics if they co ntribute to effec tiveness in this and future efforts. Criteria: I.

j

I

Degree of clarity o f the plan and addendum (A = very clea r writing; all specifics included, especially of risk retirement)

2. Degree of realism of the plan and addendum . (A = sets realistiC goals a nd procedures (neither too ambitious no r too modest» 3. Extent to whic h the plan and addendum include all relevant speCifics. (A = relevant specifics included) 4 . Exte nt to which the plan and adde ndum exclude irrelevant mate rial. (A =

> 95% of knowable,

< 5% if details supplied

Irrel eva nt) Usefulness of you r self·assessme nt.

BIBLIOGRAPHY iJ<x'hm, Barry -Sojhm1rc EltglPlccnrtg EC01l0FfllCS, ~ Prentice Hall , 198 1 2 Albrtthl , A J, "Mea surmg Applicauo n Development ProductiVity: ProadrflJ' of fix )oi,,' SHAREICUIDEflBM APPOCIlII01f DtlJtlopst7ll 1.

S1"'Posnlllt. Octo ber 1979, pp. 83-92 3. I nternatIonal function POlOt U sers Croup (D~cmbcr 1999) htlpj/~. ifpU8 org ( acccs~d November 15. 2009] 4 ·'Functton PO'"t Ungu.1ges Table VersIon 0 ," Quant ltiltlVe: Sohwilre: Management . Apri l 2005 hnpJIwv.'W q-s-m coml1q c rcsourccsl

5 6 7 8

9.

funcllo n.polnt -Ianl!:'uascs-tablellnde:x.html {JccC'Osc:d November 15. 2009 } jonc-s, Caper;, "Ap plied SojJIl,jj rf McalVfrI'Il"I1 Clobnl Alfo1 /y5IS oj P,o;/wCfl('nf)' a1fd Qwa/Jty,·' 3rd edLtLon, McGraw- Hill Osbome M~dl.l, lOOS Dorfman , M , and R A. Thayer (ed'\: and contnbu lon.). "Software: Enslntc:rtn8." IEEE COIII~rtT SOC-IrC)', No,,~mbc:r 1999_ Ecl ipse:. httpJI""",,-w.c:c1tpse:org/cclipscli ndex php [acccmd December 10, lOO9] Ec1tpsc. hnp,J/ww'W eclipse orglplatformlindex php Eclipse. http IIwww.«lipscorw.C.CI I.... c/de:vdopmc:n tl«Jlp<;c_pro.tc~_ploln_3_0 hlml ,

,

•

uality and Metrics in project Management

"

-

The Software Development Life Cycle

•

How do you cultivate a quality mind-set in a project?

•

What are examples of project matries?

•

How do you use metries 10 improve

proJects?

•

What Is a software verification and validation plan?

•

What is a good example of a planned verification and validation?

Figure 9.1 The context and learning goals for this chapter

• Soft'wa re qua hty docs nOI come about by a ci d e m Achieving II Slarts by cu ltivolm g a quality culture withm the prOject team . It also req uires careful plann ing and mo nlto nn g, with project manaKcrs continuously asking ques lio n suc h as the fo ll OWing Ihro ug h o ut the h f~ of a projecl. • Is the prOject on schedule ) Is it late) • Arc too many defec ls being d , covered ) Too few )

21.

CHAPTER 9

QUAUTY AND METRICS IN PROJECT MANAGEMENT

• Are dcle ts being Axed too slowly) • I testing progressing at the desired pa~e ) Agile teams become adept at answeri ng these questions for tcam · level work. Continua l interaction wlth the ustomer, short, mutually deAned spri nts, and con tinual testing mcan that questions like these arc being continually asked and answered In the co ntext 01 the team and customer rcpre entative. On the other hand, the scope of the project can exceed a single group, in which case various non .agile techniques a re applied a, well. As introduced in Chapter 2, the answers to these and si milar questions are provided by metrics, which arc data collected and analyzed throughout a project. Examp les of project metrics are dtftclS ptr KLOC (thousa nd lines of code), lilltS codtd ptr ",an-",onl/, (MM ), and Irst case f'Xtcuti01f rale. Each provides an objective measure of a project and its processes. Metrics are an

important tactical tool of Ihe project manage r. They allow tho manager to continuously assess project quality a nd c hedule, identify problem areas, and gai n Insights into the project that allow him o r her to make proactive decisions to head off problems. As an example, if during the testing of the software an unusually high number of defects are discovered in a particular soltware module, action ca n be taken to proactively remedy the root cause, such as conducti ng a co de inspection, redeSigning the module, or executing unit tests.

Without metrics, it is difficult to know how a project is executing and the quality level of the software. Metrics help not only current projects but also future o nes. This is because future projects base metric targets o n pa.st • ones.

Targets must be established to effectively utilize the metrics collected. For example, if 50 teSt cases are executed during the nrst week 01 system testing, is the testi ng team making good progress or poor progress) The answer depends o n the test case execution goa l deRned during project planning. If the plan called for executing 100 te t cases, then lhe answer is poor progress; if the plan was 20 teSt cases , then the answer is good progress. This also aS$Umes a Standard for "test case." The goa ls are establi shed by analyzing metries collec ted during prior projects and using them as baselines.

9.1 CULTIVATING AND PLANNING INTERNAL QUALITY T"'rmal quality rders to the quahty activities undertaken by the development team itse lf. Th is calls for cultivating a quality culture among the development tcam , an attribute of good leadership. The essential goal here is a sense of shared responsibi lity and pride amo ng the team members. Fundamental gai ns in a quality attitude accrue when the project ieader continuously ensures that the work is very o rde rl y, and that the team's effort 3_fC focused on appropriate: pri orities. We plan for the management of a projecl and its internal quali ty assurance procedures at the same time.

Internal qual Ity procedures, standards, and habIts arc active throughout the project management plan , the requ.irements, the design, and the code. Exltm,,1 provision for quality is specified in a eparate set of documents, the quality assura nce plan, the verification and validation plan, and the test documentation . The relationship of internal and externa l quality activities is illustrated in Figure 9 .2. The interna l management of quality is as much a mind-set as a document ct. It begin with a conRguration management plan that ensures con iSlc nl and 5.tlfe documentation. (For example, we were t'O

ir

implement the wrong versio n 01 the design document, the code would not match the requirements for the impie.mentation , and thus would hardly be a high-quality productl) Most project management plans de ignate team member; with specific responsibilities. Table 9. 1 shows an exampl e of respon ibility designation in which each member also has a backup responsibility. Each activity

•

PROJECT METRICS

/

Internal quality actIvItIes Plan pro/eci}

Introduce continuous quality

Perform reqUirements analysis

att~ude

Include tests lor each requirement

-

Create design

Include tesls lor each unit Implement

Perform unit tests

Perform Inspections -

"

---"r ------------- - ------------ -- ----- --- -- External gualirt activities

Plan QA , V&V Perform quality assurance

Perform system testing

-

Figure 9.2 Managing quality-internal and external activities to promote quality In projects leader promotes an atti.tude of quality for his activity. The backup members can act as palf Inspectors for each leader.

9.2 PROJECT METRICS Proj'c1 ",,'rics are those that apply across the board or ha ve broad implications during a project rather than being vety focused . The metrics process starts by identifying which mctries to collect . setting target goals for each . and regularl y monitoring and reviewing them th roughout the project. Th is is described in detail in the sectio ns that follow .

Table 9.1 Example of responsibilities for documentation, with backup Name

Primary Responsibility

Backup Responsibility

Alice Jarman

Team leader

configuration management

Bruce Stern

Configuration management

security

Bob Crowder

Internal quality

Team leader

sarah Fournier

Security

Internal Quality

Hans Ughtman

Requirements

Release

Vladimir Norsk

Design

Requirements

John Green

Implementation

Design

Susan Klein

Release

Implementation

215

216

CHAPTER 9 QUAUTY AND METRICS IN PROJECT MANAGEMENT

9.2.1 Identification DUri ng proje t planning, the metries to be collected are Identified . Some arc applicable to all phases (e.8., defect ) wh.le o the rs o nl y apply to a spec.fic phase (e.g, test case execution ). While there are many metric< to chose from . some of the most usefu l arc as follows [ I ].

•

• Project mile tones • Testing progress • Defect detection and defect injectio n per phase • Defect resolutio n

\Vle discuss each of these next.

Project Milestones A plan IS created early in a proje.c tthat contains a detailed schedule. including milesto nes, which are concrete objectives that must be achieved at speCific times. A project manager monito rs the progress of a pmject against these milestones to determ .ne whether it is on schedule. Project scheduling and the establishment of milesto nes were covered in Chapter 10. The obvious metric here is the number of days between a milestone's schedule and the day on which it was actually reached.

Testing Progress

•

A test plan is usually constructed before any formal testi ng commences . It includes information regarding the types of test cases to run and detailed information regarding each test case. The most common mctrics to collect during formal te ling arc the ralt oj ItSI cast t'Xtculioti and the )lumbrr oj passrd ttst cast'S , With these two metrics, project mana gers ca n determine whether testing is proceeding on schedule.

)

•

Defect Injection and Detection Defect metrics are probably the most common type of metric collected. Defects occur during each development pha e, but such defects may have been incurred (or "injected") during a previous pha... The drJecr dclrcl'ion ratt is measured for a given detection phase and a given injection phase. For example, a "defect detection rate of 0.2 per 100 requirements defects at the implementation phase· means that one defect in the requirements is detected, on average, when implementing a set of 500 requirements . Figure 9.3 shows an example project in which these data have been collected. It also shows the longevity of defects, phase of injection vs. phase of detection. For the sake of simplicity, we have omitted the test and post.dclivety pha.ses, which would complete the picture. Let's focus on the detailed requJrements part of Figure 9.3. It shows that two defects per 100 were detected during the requirements phase (assessed by means of inspections). This compares favorably with the organization's norm of 5 per I00. looking across the "detailed requirements" row, we observe that our process detected fewer than the normal rate of requirements ddects during subsequent phases. This seems to toll uS that our project, and possibly the process we are using, is comparatively effective when it comes to producing

quality requirements. However, it is also possible that our detection process is worse than usuali This bears investigation . To complete the table, we would include similar defect data collected during testing, and during a specific rime (e.g., three months) after product delivety. The results for d(Sign defects in Figure 9.3 are as follows . We detected more than the usual number of design defects during inspections at the time they were injected, but recognized fewer design defects at later

t

PROJECT MElldCS

Defects detected, Per 100 requirements/per . • in the design/per KLoC. etc. This project/llonn Phase in which defect was in jected

-

Phase in whic h defect was detec ted

Detailed requirements

Design

Implementation

Deployment

215

0 .5/ 15

O. I/O.l

3/ 1

3/ 1

IIJ

-

-

212

sh -

Detailed •

reqUirements

Design

-

-

Implementation Deployment

-

-

3/2

3/ 12

-

Figure 9.3 Examples of defect count-injection phase VS. detection phase

stages. Since it is more expe nsive to detect and repair a defect lalcr in the process, Ih, s indicates that ou r project seems to be superior to the o rganization norms. Figure 9 .3 also con",ins Information abo ut defects detected after deploymenl to customers , whic h is surely the most Im portant metnc In the end .

Defect Resolution Tracking defect detectio n tells us the rate at which we arc fi nding defects. giving an indication of the qualtty of the evolving product. Equally important is the met ric d,Jrcl rtSollllioll . wh ich measures the rate at which defects are being resolved. Defect detection and defect closure arc complimentary . Fo r example . even If defect detectio n is meeting o r beating the plan. if the defect resolution rate is bel ow plan . the backlog of ope n defects increases and the qualiry and schedule of the project suffer.

9.2.2 Planning Once the set of merrics to be collected is identified. a plan is t'Stablished with targets for each metTic. The be'St way to derive targets is to use the metrics collected during previous projects as a baseline. adjusted as neces<;ary Without projections based o n prc-vious projects, it is very difficult for project managers to kn ow whether a project is meeting expectations. An example of a plan used to track dcf,rt d,lrclloll and d,Jtrt mollifioll is shown in Figure 9 4. Figure 9.4 tracks the number of defects submirted and resolved weekl y versus the plan . Each week the actual number of defects discovered is fi lled in and compa red wi th the plan . In this example. note that the number of open defects for the first three weeks is g reater t han what had been anlicipated. At the e nd of week 3/ 10-3/ 16, 103 defects are open vs. a plan of 66 . Armed with thi s knowledge . th e prOject manager can take appropriate corrective action Similar plans are c reated for each of the other melnes collected .

9.2.3 Monitor and Review DUTlng the Ide of a proJecl it is a good Idea for key members of the project team to revlcw the metn cs On a regu lar basiS, usually week ly . One good way to do this is for the prOject mana ge r to c reate a pa ke t of IOformatlon co ntall"ng metfl cs c harts as shown In Figure 9.4 T h IS helps pre se nt th e info rmat IOn In a GonClse format for eaSie r review . H owever, JUSt presenting lhe se oVervIew e h art 111 a nOt be enollg h For example, in additIon to th e defec t pl a n ~hown In Figure 94 . ,ddillonal'llfo rm a ll o n ~lI h a detailed

217

218

CHAPTER 9

QUAUTY AND METRICS IN PROJECT MANAGEMENT

Build 44 45 46 47 48 49 50 51

20 10

TROUBLE!

5

o Figure 9.4 Example of tracKing defect resolution-recognizing problems with defects remaining open

defect re ports ma y be Incl uded to better uncie"tanci the ou ree of the probl e m bei ng d is ove red If thIS I ~ done fo r each of the mc-tn S Incl ud ed In the report , the amoun t of i nforrnalion Ciln become ovcrw hclnlln g Al lh ough it I S sti li a good Idea to Include It all , I t is common to crC
so me t,me s ,n the form o f a pro),rt dn ,I,/'onrJ . A dashboard pre Cllt a co ncise , g raphical summary of esse nti al InfOrmal lo n re ga rding the ge neral health of J project. Th is IS analogo l1 ~ t'o an automobile d ashboard . wh ich co ntains gauge.:; slic h as fue l leve l, odometer, and engine temperature , (0 quickl y a crta ln th e ge neral S1aru and hc alth of a cor F'g ure 9 .5 shows an examp le dashbca rd from the

J

PROGRESS PRODUCTIVITY

E... ,

1 ~ V~

(8CWP)

s 10

•

COMPLETION

Adual'-' T••' ' '....

tACWPI

Coo,Qlr"lJ uu" COh;:'.U ~ On T..,...

StD>*

I I I

---

, ,,,

SAp •• d T1me

'j

CHANGE

Figure 9.5 example of a project management dashboard Source- SOftware Program Mana,gen NetwOrt tsPMNJ, MltDIIW'ww5PI'M COlli ProviOtd DV AMERICAN SYStEMS With

pefrT\l'S:SlOn

USING METRICS FOR IMPROVEMENT

OJI. arr Progra .. AlII""g,'! N,'ulork l2J

Th e ty pe of 1I1formatlon cO llla in~d ,n a d .. hboard Includes the

following· • MilestOne ompl~tion • R~uirements changes •

onnguratloR changes

• tilff turnover • Staff overtime hours • Quality metries such as defe ts per phase • Risk analysis With this concise project rnformation , stakeholders can focus therr attent ion o nl y o n those metrics not conforming to plan. For "xample, it can be noted fTOrn Figure 9.5 that the plan ca lls fo r two requirements change per month, but in the period covered by the dashboard three requirements changed. Stakeholders can now look at more detailed informatio n regarding the requirements that changed to determine whether they pose a risk to the project. Other merncs that are meeting or beating the plan need no t be examined In great detail.

9.3 USING METRICS FOR IMPROVEMENT Companies strive to Improve their projec t ext:= ution in tw O ways:

• By improvement within a project, from one phase to the next

• By improvement across projects, from one project to the next But how do you Ide nti fy what needs improvement? There is a wise saying that ")'OU ca n't improve what you don't measure: Metrics provide the measures that allow projec t managers to identi ty how a prOje t IS performing, the areas requiring the most improvement , and the objective data needed to measure the ratc of improvement . The next two section desc ribe how this is accompli hed within and across project.

9.3.1 Improvement within a Project The first step to Improve qualrty fro m o ne deve lo pment phase to the next is to coll ect me trics dunng cach phase. Table 9.2 shows a summary chart that ca n be used, which include< prov i io ns for o mpariso n with P3>t projects The data ca n be used In twO ways· I. To assess the hea lth of ea h phase's artrfact .

Fo r example , If the defect ra te for o ur req uirement s IS 0.7 pel' page and the compan y's average " 0.3 per page, then we have Identified an i<sue with our requirement, (The o nccp t of a defect 111 a page I docume ntat ion has to be carefull y dcnncd to cn
219

220

CHAPTER 9

QUAUTY AND METRICS IN PROJECT MANAGEMENT

• Table 9.2 Data on actMties relating to document creation and error rates DraftlngTO RevlewlngT1 Finalizing" post·mortelll

TOTAL

Research

Meeting

Timet'

120

30

210

130

140

30

660

% Time

18%

5%

32%

15%

21%

10%

NlA

- 14%

- 7%

- 15%

- 30%

- 16%

- 18%

N/ A

N/ A

N/ A

22

N/ A

N/ A

N/ A

28

Productivity

TBO"

TBOll

6.3

TBO"

TBO"

N/A

2.512

(Average procuctMty)

TBO"

TaO

TBO"

TBO"

TBO"

TBO"

18.3"

Self·assessed Quality"

3

S

2

1

5

9

N/ A

Defect rate LS

N/ A

N/ A

1.513

N/ A

TBO"

N/ A

N/ A

(Average defect rate)

N/ A

N/ A

(1 .1)

N/A

TBO

N/ A

N/A

Process Improvement note #

(1)

(2)

(3)

(Average % tlme)l2 Quantity'"

I

'

(4)

•

,-, •

•

The informatio n in T able 9 2 is examined, co lumn by column, identifying data that are different from par. For cach datum below par, we de vise concrete actions that the team will perform differently for the next phase . For each datum above par, we look for beneficial techniques that may be applied in future phases. "Self-assessments" arc comparat ive, subjecti ve scores that the team assigns Various activities . One

"..

way to collect the m for four actiV iti es, le t us say, is to ask each team member to allocate 5 x 4 = 20 points among the fou r activities, each score being betwee n 0 and 10. The averages indicate how well the team as a whole th inks it performed o n each activity. Th is i a subjecti ve measure that can be profitably compared with other metrics .

Here

IS

an explanation of the superscripts in Table 9.2.

Left-Hand Column II Spent Ll

by

entire tcam , in person -hours

The average amount of time spent on these acti vi ties in one of the following (select one), entire organization o n all projects, e ntire orga nization on si milar projects (the ideal ), this department on all projects, this department o n similar projects, this team o n prior phases.

U

For documents, to tal number of pages produced in the case of documents. For code, X 1000 lines of no n-commented code. A line of non- commented code is de fi ned as < A precise definition is provided here. perhaps showi ng examples of how to count lines for common constructs such as for loops.>

L'

This is a judgment that the team makes about the quality of the activity's product It is subjective but ca n be very useful. A good way to obtain self-critiCism is to force the average of these numbers to be five on a scale of 0 to t O.

t

USING METRICS FOR IMPROVEMENT

This I a key metri . It i necessary to deAne the following : • What severity of defects will be counted (usually any besides trivial) • When in the proccs thesc are counted (so as to be consistent for the sake of comparison) Top Row 1'0 Spent

b>, team members preparing the an ifact to the best of their ability; before submitting anifac! to the rest of the team for review

TI

I nc Iudes inspectIOns ' .

T:l

After review; responding to comments from the rest of the team

In~rior

of Table

II Measuring productivity for these activities is a more advanced concept and is covered later. 12

Pages per hour = (total pages)*60/{ total time in minutes)

13

Found during the "finalizing" stage

1<

This metric is determined by the end of the project detected that were injected during th is phase.

or even during maintenance-when defects are

The following notes correspond to the last row in Table 9.2 and are examples of speCific process •

•

Improvement actions.

I. Our self·assessed quality measure on rmarch was 3. The team spent a percentage of time on this actlviry that is close to the norm, so the remed y is not to spend more time on research . If there were know n reasons why research was on the poor side (e.g., a new procedure or very unfamiliar type of application) then the data here may not be a cause for alarm . O therwise . the team would discuss how to improve the research process in the future . 2. The drajliHg of the artifact was poo r in several respects. It too k more than twice as lo ng to draft a page than is usual; the product of drafting was significantly poo rer than the self·assessed average of nve; and the defect rate was significant ly higher Ihan the norm. The table by itself proVIdes no explanations or trade · offs to deal with this, it merely indicates the problem . The tcam con iders the particular circumstances of the activity and deci des what went wrong and how to fix it. For example, perhaps the main reviewer wa Ed and his mother became ill during the actIvity The team may conclude that there was not enough backup for lead writers, for example . 3. The next problematical activity was ,rui,wing, where the score waS lowe
221

222

CHAPTER 9

QUAUlY AND MEIRICS IN PROJECT MANAGEMENT

Our self·evaluatio n gIve S o rcs of 3 to review and 8 to resea rch o ut of a forced average of 5. We spent 15% of our time o n revi ew and 25 % o n resea rch . We will spend 20% on each of these activIties for the next pha e

,,

O ur ddect rate decl ined steadily except fo r thi s phase , when it rose. This seemed to be due to a lack of commo n vi sion prio r to divid ing the writing. In past phases, we succeeded in establishi ng a common vision of what we wanted to do before beginning to write our parts. Before begi nning to write the next document we will conflnn a shared vision . The ratio of requirements time to design time was 1.2, which is lower than this ratio from past successful projects in the compan y. O ur design self·eva luatio n was 6, more than average . On our next project, we plan to spend 10% more time on requirements analysis at the expense of design time.

,

•

Figure 9.6 Using project metries to improve software development processes

•

Teams set aside time at the end of each phase to assess the conclusions drawn from me tries, and to write down how it will improve its process during the next phase. Figure 9.6 shows examples of improvement conclusions.

9.3.2 Improvement across projects Companies strive to improve their perfomlance from project to project. No matler how efficient they are, the be

l

orga nizations know th ey can always improve. Th ey iden tify area s for improvement and specify actions

that w"l lead to the desi red improvements in those areas o n subsequent projects. Ste ps that can be taken to achieve these improvements are as fo ll ows, 1. Ide nti fy several areas for Im provement that arc important to the company. Examples include ~uality,

,cb,dul, prrdiclahility. and ,fficorncy. 2. Identify and coll ect metnes ,hat measure perfo rmance in each of ,hese areas. These metrics arc used as baselines for setting goa ls in future projec ts. 3. As part of project planning fo r a future project, establi sh goals for improvement in each of the identified areas, usi ng melrics from prior proj ects as a base line.

4. Identify speCific actions to implement that will support achievement of the goals. As an example, Figure 9.7 Ii51 fo ur arcas ,hat have been identified for improvement, S<'brdul,. prrdiClahilily. cIficimcy, and timt-lo-mn,kcL A metnc is identiflcd fO accurately measure project performance i n each area. Note that the re may be severa l appropriate metrics to usc in each area, but fo r simp licity we are only identifying one. An improvement goal is identified for each category, and speCific ac tions arc defined to bc implemenl
,

I

SOFlWARE VERIFICATION AND VAUDAnON PLAN

Improvement

Metric

Description

Quality

Defect KLOC

New defects fo und dunng forma l QA testing , per c hurned KLOC

10 %

~diCtability

% schedu Ie accuracy

% improvement across releases

5%

.

Coal

Improvement

-

-

-

-

Efficiency

MMlKLOC

Pre -QA deve lopme nt effo rt per c hurned KLOC

10 %

Time to Market

Cale nda r rim elKLOC

Pre -QA ca le ndar time per c hurned KLOC

15%

Figure 9.7 Improvi ng projects across the organization

examples of Improvement goals

9.4 SOFTWARE VERIFICATION AND VALIDATION PLAN Recall that "(rificalio" respo nds mainl y to the question "Are we correctly building th ose artifacts in the present phase that were specified in t he previo us phases7" Validalion res po nds to the q uestion "Do rhe artifac ts JUSt completed in the prese nt phase sat isfy their speciRcations from previo us phasesi' IEEE 10 12-2004 Softwa re Ve rificatio n a nd Validati o n Pla n. whose hea din gs are reprodu ed in Figu re 9.9, provides a framework for expressing the manner in w h ich V&V is to be carried o ut. Th is specificatio n is writte n during in itia l p roject pla nn ing , a nd complime nts the Software Q uali ty Assurance Plan covered in Chapter 6 and the case study in C hapte r 8. The annexes to IEEE V &V S tandard 10 12- 1998 are as fo llows , Annex A. Mapping of ISO/ IEC 12207 V&V requirem e nts to IEEE Std 10 12 V&V activities a nd tasks B_ A software integrity level sc he me

C.

De~nition of independent verification a nd va lidatio n ( IV&V)

Improveme nt Category: Quality Actions, I. Identify compone nts o f so ftware that

o ntaine d most dekc ts.

2 Plan to conduc t de"lI n a nd Lode reviews in these areas. 3. Plan to re fac to r seve ra l o f these are as during slIhscqucnt projec t

FIgure 9.8 Example Improvement plan

223

22'

CHAPIER 9 QUALITY AND METRICS IN PROJECT MANAGEMENT

I Purpase 2 Referenced da cuments DcRni tlans

5.4 5.5

Opera tian V&V Maintenance V&V

6. V&V repartlng requirements

6. I Reparti ng

4. V&V 'Overview 4.1

OrganIzatIOn'

6 .2

Administrative

4 .2

Ma ter c hedule

6 .3

Documentatian

4 .3

Saftware integrity level scheme

4.4

Resaurce summary

7. 1

Anomaly reparti ng and resalution

4.5

R~ponsibi l i t ies

7 .2

Task iteratian palicy

4 .6

T 0'01 , techniques, and me thodologies

7 .3

Deviatian palocy

7 .4

Standards, practic~ , and canventions

5. V&. V pracesses 5.1

Management 'Of V&V

5 .2

Acq uISi tIo n V&V

5 .3

Development V&V

7. V&.V administrative requirements

8. V&V dacumentation requirements 'Subheadings arc typical examples (IEEE )

Figure 9.9 tEEE 1012·2004 Software Verification and Validation Plan-table of contents Source IEEE Std 1012·2004

C I Technical Independence C2 Managerial independence C3 Fi nanCIal independe nce C4 Farms of independence C4 . t Classical IV&V C 4.2 Modified IV&V C4.3 InternallV&V C4.4 Embedded V&V D. V&V 'Of rcusab le saftware E. V&. V metrics E. ! Metrics for evaluati ng saftwar< develapment processes and products E.2 Metrics for evaluating V&.V tasks and for Improvi ng the quality and coverage of V&.V tasks F. Example 'Of V&V organizatia nal re latianship to other praject res pa nsibilities G. Optional

V~.v

task descriptions

H. Other r
I. Definitians from existing standards (na rmative) Copyright

IEEE 2003

An ideal pracedure is for an outside group to perform V&V. This is ca lled '.d,Jontdtttt Vtnjk.rio. ""d V.lid.riml (IV&V).

CASE STUDY: SOFTWARE VERIFICATION AND VALIDATION PLAN FOR ENCOUNTER

TI,e next

s~ tion in the

hapter gives an example of a

VVP case stlldy .

9.5 CASE STUDY: SOFTWARE VERIFICATION AND VALIDATION PLAN FOR ENCOUNTER

4.3 Resource Summary Note to the SlUdent, This ~ction shows an example of Software Veritlcation and Validation Plan for the Encounter vicko game project, organized in accordance with IEEE 1012-2004. In the interests of space. various ~tions have been omitted.

1. purpose This document provides the verification and validation procedures that will be followed for the devel · opment of the Encounter video game .

2. Referenced Documents Software Project Management Plan Software Configuration Management Plan

3. Definitions

4. V&V Overview

4.1 Organization This section describes how the V&V effort will be organized (i n terms of roles) and how it relates to the development pha es.

The verification and validation of Encounter IS roordinated with eac h phase of every ite ration .

This section describes the person-hours required for V&V or the amount required to fund an external organization for IV&V.

Verification will be perfonmed Internally. Valida · tio n will be perfonmed partly by project e ngineers. The costs of this IOternal work are built into the SPMP. Validation will also be perfonmed by one 01ernal QA engineer. This person will consume four perso n.months.

4.4 Software Integrity Level Scheme The integrity level of software expresses how critical it is. Software components that potentially threaten safety have the highest integrity level. The IEEE standard describes four levels, high, major, moderate, and low. A tool supporting infonmal research, for example, would probably be required to have only a low integrity level.

The Encounter application is required to ha ve moderate integrity.

4.5 Responsibilities The development team members will • Perform verifica ti on ac tivities throughout the proj· ect, including Inspecti o ns within all pha ~cs • Perform and doc ument all unit testi ng uSing )Unit • Validate requirements d ocuments with the marketI• ng mCl nagcr

4.2 Master Schedule The QA e ngineer will Because of the orgamUllon of V&V "' de\ c rlbed "' Section 4. 1, the VI!< V schedul e loll ow< directly to the Ploject schedule as defined In th e SPMI'

• Verify that the teal11 h.\ lo llo wed lIs docume nted procedures, ln iudins tho. e cie< ribedil1thbd ume nt

225

226

CHAPTER 9

QUAUTY AND METRICS IN PROJECT MANAGEMENT

• Perform all post -unit te tin g

• Arc all cntlca l marketing factors identified?

• Report the =ults to the team and management

• Docs any conce pt Imply a SIi!nificant risk to pro~Ct completion) If so, should that concept be mitigated?

• Maintain this document

,

5.3.2 Requirements V&V

4.5 Tools, techniques, and methodologies To be supp hed

The Encounter SRS WIll be verified by answenng the follOWin g questions,

5. life Cycle V&V

• Are all critical requirements that were identified during the concept phase speCified)

5.1 Management of V&V

• Is the SRS organized traceability )

The V&V dforton Encounter (i ntemal and external) will be supervised by the manager of Quality Assurance.

• Does the SRS account for all required interf.ces with other systems?

In

a way that facilitates

• Does any requirement imply a significant risk to

Each of the following sections describes how V&.V of every process will be conducted. When this is to be performed internally, it can be included in the corresponding docu· ment (SPMP, SRS, etc.), and this V&V docu· ment can refer to those.

project completion) If so, sho uld that requirement be mitiga ted ) The Encounter SRS will be validated by expos· Ing it to the marketing department and to a sample of 30 game players.

5.3.3 Design V&V

5.2 Acquisition V&V ' Acquisition" is the process by which an organization obtains software. Using third·party software relieves the development organiza · tion of having to reinve nt the wheel. However, it places a burden on the organization to certify the Quality of such software. Many disasters have been expenenced because this step was avoided.

Each vendor·supplied tool used for the development of Encounter will be valIdated by the QA engineer.

The Encounter SOD WIll be verified by answering the fo ll owi ng question , • Arc all requirements accommodated by the design)

5.3.4 Implementation V&V The Implementation of Encounter will be verified by answering the follOWIng qu('Stions, • Are all requirements fully verified) • Is the code organized in a way that faCilitates traceability back to deSIgn and req uirements) • I all code documented according to standards • Is all code thoroughly documented )

5.3 Development V&V 5.3.2 Test V&V 5.3.1 concept V&V Conceptual work on the Encounter game concept will be verified by answering the following questions.

The test documentatIon of Encounter will be verified by answering the follOWing verifiCJIIOn Questions, and the .ahdation questions that follo,,'_

CASE STUDY: SOFTWARE VERIFICATION AND VAUDATION PlAN FOR ENCOUNTER

• Are ~II critical cequ",:mcnlS in tended to be fu ll y rested at every level of det~iI (e .g ., human safe IY) ~ • I

the

test

phdo ophy

adequate

for

the

requirements'

• Are the test plans complete a specined in the test philosophy • Are the test cas~s complele as specified in the test philosophy For the test plans and procedures, th e reader is referred to the Softwa re Test Documentation. These plans and procedu res are deSIgned to accommodate the following validatio n questions. • Do the defect cou nt . defeCl rate, outsta nding defects, and defec t seve rity anest 10 an acce ptable product? • If not, what success rate wi ll be required to allain acccptabi Iity7 • Do they account fo r all of the metri s peciRed in the SQAP ~

6.1 Reporting The QA person attached to the prOject reports the sta lus of V&V weekly to the manager of QA and copies the team leader.

6.2 Administrative This describes who is responsible for the V&V reporting effort. The project leader is respo nsib le for ensuring that all V&V reporting is performed.

6.3 Documentation A single repon that includc'S all version of the result of

the tasks described in this document is maintained.

7. V&V Administrative Requirements This describes who is respo nsible for the V&V effort.

5.8 Operation V&V This part verines that the application is appro· priately supported after deployment to users . To be supplied

5.9 Maintenance V&V TI,e maintenance plan hall be veri ned agai nst corn · pany mamtenanee crite ria , specified in the com· pany's mai ntena nce requirements and procedures, documenl 890.23.

7.1 Anomaly Reporting and Resolution The QA engIneer attached to the Encounter prOject wi ll mainta in th e current state and the history of each defect fo und . T he QA enginee r will rnai ntalll all metrics identi fie d in the SQAP o n a Web site and WIll e·mail a list of all anomalies (including defects) Ih at he or she deem to have excessive repa ir time· Iones. This includes defecls with no repair duration es timates and tho e that have exceeded their planned compictl on date . The Bugzil la fa cility will be used.

7.2 Task Iteration Policy 6. Reporting Requirements Th,s includes who reports the resu lts of the V.. V effort and to whom do they provi de

thcie report~,

Th ,s seclion explains the circumstance under whi h VsN tasks are repea led be au C 01 results obta Ined o r because of changes in the project.

227

228

CHAPTER 9

QUALITY AND METRICS IN PROJECT MANAGEMENT

v

Any pro posal to deVIate from this plan requires th e approval 0 1 the QA manager and the project

V tasks wlil be ropea ted at the discretIon of the QA repre e ntatl ve, but these wlil Include the f 1I 0"'lng c riteria .

manager

• A n inspectio n w hose defects count is more than 20

7.4 Standards, Practices, and Conventions

percent greater than the norm

• A test whose defects count grea ter than the norm

IS

more than 20 percent

• An entire phase ,f the previous phase c han ge by mo re than 20 percent.

7.3 Deviation policy Describes the procedures required to deviate from this plan .

These arc set down for all company prOjects at http:// •

•

8. V&V Documentation Requirements Section 6 de cribed what should be reponed. Section 8 covers the means for noting in writing the results of V&V. It specifics the form that all V&V documentation must take. For example, it could be organized as an appendix to this document.

9.6 SUMMARY Quality In project manage ment begins by cultivating a quality culture within the project team . Members develo p a shared r.spon Iblilty and pride . Many projects designate team members with speCific responsibili. tICS, and each actIvity leader promotes an attitude of qua lity for h is activity. En unng quality reqUIres carefu l planning and mo nIto rin g throughout. Metrics arc collec ted and analyzed, providing means of concretely assessing how well a project is executing . There are many useful metrics, some of the most ba IC arc projecl mtl,,'oHr plaIH"d '" fulfillrd , drJecl rOIlHI" and ",rruIIOH . After identifying the metries to be collected, a plan is created with goals for each . Targets are created by analyzing previous projec ts and using metrics fro m tho e a a baseline. If targets aren't established, project managers will not know whether a prOject IS o n track. During the course of a project, the team meets regu larl y to review the metrics. In addition to the detailed data , a grap h ical summary often known as a projrrl dasl,board is c reated. The dashboard presents the key metries in a clear, conCIse manner, allowing the team to quickly ascertain how each is aspect of the project is perfom"ng against the plan. Successful companies strive to improve the overa ll quality of their performance, both during the course of a project and between successive projects. Metrics are analyzed in each case to identify areas requiring the most improvement. SpeciRc actions arc then enacted, and metrics objectively measure whether the improvements arc providing {he anticipated results . The Sol-tware Verification and Validation Plan is an important part of project quality. It specifies a plan for generati ng artifacts based on specificatioAs of previous phases (otrifiralion), and for building software that meets customers wants and needs (validalloH) . IEEE to t2 · 2004 provides a framework for this document.

,,,1

9.7 EXERCISES I . In your own words, define · proJect metrics" and explain how they are used in managing a projcct. 2. The defect pl.n in Figure 9.3 shows the number of open defects falling behind plan st.ning in week I . Assuming you are the project m.nager, at what point would you start taking corrective aclton'

BIBUOGRAPHY

Would it be aftcr the Arst week, or would you wait a number of weeks to see whether the situation Impro v Arc there any other metrics you might collect to help you deci de? Write a paragraph to e):pl~ in

Ollr an wer.

3 D~cribc in your own words how a project manager could utilize a project dashboa rd in managing a project. 4. What metrics related to software testing mi ght you include in a weekly project metrics report to provide insIgh t into the status of the te ting process? Explain your choices. 5. For each of the remaining ca tegories in Figure 9.7 (predictability, efAciency, time to market), Clcate an acti on plan to reac h th e stated improvement goals. Use Figure 9 .8 as a template for your plans. Include a minimum of three actio ns to take for each ca tegory .

I EAM EXERCISE V&V Plan TI. Produce the relevant parts of a V&V plan usi ng IEEE standard 10 12 · 1986. Measure and report o n the metrics described in Team Exercise TI in C hapter 6. Criteria: 1 Practicality: H ow well does the plan ensure that the work will be adequately veriRed and validated?

(A = completely practicable in the environment of the project) 2 SpeciRcs: H ow speciRc is the plan in terms o( sui tably naming places and participants? (A = spell s out exactly how V& V will be performed in the e nvi ronment o( the development) 3 Team participa·nt pe rce pt io n: T o what degree are partici pants likel y to perceive your plan as a help to them ? (A = written in a way that respects the time and efforts of engi neers)

SQAP T2 . Produce a rea list IC softwa re qua lity assu rance plan for your project. Measure the time spen l o n thi s dlort by indivi dual mcmbers and by the complete team . Provide the corresponding metric data and self-assessment for this assign me nt , as described in Team Exercise in Chap ter S. Critcna: as (or Team Exerci se in C hapter 8.

BIBUOGRAPHY I la ird, unda M . Ind M

rol Srerman,

hware Mea suremen t and E~ um;ulon A Practica l Appro') h/'

P9 181- 192 1 SohwJr~ P,oKram ManDQl'!l1 Nl"two r'k (S PM N) hup Ilwww ~ nl1ln com.

W"ry- I'IIUlC"IOKt,

1006,

229

I

,

principles of Requirements Analysis

Planning Maintenance

The Software Development LIfe Cycle

•

Why the term requirements "analysis?-

•

What is the value 0' written requIrements?

•

Where do requirements come from?

•

What is the difference between high·level and detailed requirements?

•

What is the difference between functional and nonfunctional requirements?

•

How do you document requirements?

•

What does traceability mean?

•

How do agile teams handle requirements?

•

How can student teams gather reQuirements?

Figure 10.1 The context and learning goals for this chapter

Bdore a software system is deSIgned and implemented, one needs to understand what that system .s intended to do. This intended functionality is referred to as the rc4""",,,,,t5, and the process of gai ning the necessary understanding of this is col lled rrqulrrmrnts ,malYSIS. An application for Video store management , for

example, could mean different things to different people, each a somewhat differing set of require ments. One intop",r3tion could be an application that track. employee t.me and outputS paychecks; another, an e·m.,J

SOURCES OF REQUIREMENTS

• The proce of underst4ndinl! wh4t's wanted and needed in an apph ation For exa mpl e, yo u may know that you a colo nia l hou e in New England, bUI you may no t know that you will pro babl y ""d a baseme nt for it .

U'.,.'

• W e exp re require me nts in writing to comp le te our understand ing a nd to create a contract betwee n develo per and custo me r. FIgure 10.2 The meaning of requirements analysis

appl ication that processes Customer ren ta l req uests; a third , an a pplicatio n th at records rented vi deos and computes charges; and so o n. As in mOst busi ness endeavors, the reliable and professio nal way to specify what IS agreed upo n i to ex press it in writi ng. Therefore the o utput of requirements analysis is a software requirements speciReatio n (SRS). T hese po ints are ummarized in Figure 10.2. A requirement specioes wha l the customer wants. Th is no rmall y docs no t include any th ing about how the applicatio n is d esig ned o r programmed . Specifyin g a req uireme nt is like tell ing a cont racto r lhat you wa nt a 12 foot by 15 foot roo m added to yo ur house . You gene rally do no t specify how yo u wa nt the contracto r to build the additio n thai is a desig n a nd const ructio n issue.

10.1 THE VALUE OF REQUIREMENTS ANALYSIS A dd ective requirement (i.e., o ne not re paired before the requirements document is fina lI zed ) turns o ut to be very expensive. It i·s an estimated 20 to 100 times mo re ex pensive to re pair if allowed to slip thro ug h the develo pment process compared with re pairing it soo n afte r it is incurred, In Anancia l term s, if the cost of Rnding and repairing a defec t at requ irements time is $1 , then the cost of Rnding and fixing that same defect at the end of the deve lo pme nt process is $20 to $1 00. The damage that re ults fro m the custo mer's poo r experience with the appl icatio n is a fa cto r addit io nal to the expense involved. G iven the trem endous be neRt of detecting and re pairing defec ts at requirements time, "' hy are so many projects damaged by poor o r no nexiste nt requ irements anal ysis) A princ ipal reason is tha t custo mers usually do no t know at the beg inning o f a projec t all that they want o r need . Instead , they learn to understand what they themselves want o nl y while th e project progresses. Th e Encounter case stud y is an example of th is uncertainty; it has a purpose, but o ne whose de ta ils are still in fo rma tio n. Thi s book emphasizes ite rative develo pm ent and the close alig nm ent be tween the requirements, deSig n, and implem entation Agi le method s are a prime exampl e. Engi neers usi ng a well ·orga nized ite ra tive process gathe r requirement , desig n for those requi reme nts, and impl eme nt for them in coordinated ite rati o n ~ .

10.2 SOURCES OF REQUIREMENTS We usually th ink of cu,'omm as the source of requirements since a ppli at,o n. are bUIlt fo r them. In p ractice, matters are ra rely sim ple here because t he people paying for an applica tio n, the peo pl e who will be u ing the appllcallon, and the people de >uPP') rt the addI ti o n wi th p,ers ra ther than WIth a reg ular fou nela tion,

231

232

CHAPTER 10 PRINCIPLES OF REQUIREMENTS ANALYSIS

t

Doclslon support system lor mlillary IBeIICS

•

Unconstra/n«J

Encountor video game

• •

Type 01

•

Corpora Ie payroll system

Factory control system

application

• • Highly

•

Enhancemenllo corporate payroll system

Flight CDntrol system for airliner

Missile guidance system

constrained

I Relatively low

ApproxImate % of requirements

•

gstheled from people

Figure 10.3 Source of reQuirements people and other sources Source" AMpted Irom ..Software Reqwem€I1ts-SEI Cumculum MOdule SEI·CM· 19-1 2 ,. by JOhn W Brackett copyright ," 2009 call1Egie Mt'Oon ~ WI!!, spec'al pel I i iksJon from Its SOftware Engineering InsUtute.

Requirement arise fro m mult iple sources, mostly from stakeholders, but also from documents and even from books As shown in Figure to.3, Brackett [ I ) has plotted severa l types of applications to illustrate the degree to which requirements are gathered from people, as opposed to other sources such as written material Figure 10.3 classifIes applications by the degree to which they are constrained by nature restrictions on the application that cannot be altered. For example, an appl ication that describes the trajectory of a ball is constrained by graVity; chemICal reactions arc constrained by physical laws. Generally speaking, the less constrained a problem , the morc its requirements must be obtained fTom people. At one constraint extreme, for example, is our Video game case study. Being the product of pure imagination, it relies on people for most of its requirement.<.

10.3 HIGH-LEVEL VS . DETAILED REQUIREMENTS A typical reqUirements document is large A detailed description of every requirement, although nccessary in some fonn or other, can be mlnd · numbing to read. Imagine, for example, a document that spells out evety detail of every property of MICrosoft Word™ . It would certainly no t read like a novell For thIS reason, we often divide requ iremen ts documents into two parts, "igl>-fro" and d,tai/,d , The first part of a requITements documen, is an overview, which is relatively readable and is wdl suited to customers Its contents are referred to as the

high-ltvd or hSlSI:1t'Ss requirements . Anyone wanting to get an idea of

what the application IS all about read the high-level requirements. In many organizations, the mark
fonnally necessary, the hi gh -level requirements often Include a de cri ption of why the application is being built, and they state the benents to both the developing organization and the customer [2). In some organization s the: hlgh .level requirements fonn a separate document such as a -market requirements-

document In thiS book we will include the high-level requirements In the SRS. As an example, the video tore application high-level reqUirements might contain sentences like the following ,

NONFUNCTIONAL REQUIREMENTS

The V,deo

tore .ppl. at,on sh.1I enable clerks to che k DVDs in and out

The followIOg hows a ketch

f the maIO u er ,nterface. . . .

The second part of a o mpl ete requirements do um ent con is ts of the complete particulars. They are espeCially u for developers, who need to know precisely what they have to build . These arc the d.l.i/.d rrquiJtm(IJts. Although de ta iled requirements are used frequently by developers, the y should be understandable 10 the u IOmer, and hou ld not conta in developer Jargon wh ere possi ble . Here are o rne examples from the ",deo slOre applicatio n.

,,"11

The dail y late charge o n a DVD shall be computed at half the regular two·day rental rate, up to the value of the DVD listed in the "Interga lactic Video Ca talog." '\>Vhen the amo unt owed reaches this value, the to tal late charge is computed as this amount plus $5 . When the "comm it" butto n is pressed o n CU I 37, the CUI shall diS3PP('ar and CUI 15 shall appear with a superimposed g ree n bo rder (RC B = 6, 32 , 8) and the name and address 6elds Riled with the data for the custo mer. One challenge of writing the hig h·l cvel and detail ed requirements is to ensure that they remam consistent over time. Thi s is facili tated by kee ping the hi g h. level requirement at a hi g h enough level-for example , "Clerk can enter customer particulars." Thi klOd of statement te nds no t to change very much O n the other hand, the details are provided in full in the detailed requirements and are much more liable to evolve. A corresponding examp le is, "Clerks ca n enter th e customer's Rrst name of I to 10 alphabe tical characters in the text neld shown in ngure 34 , a second name of I to 15 alphabetical characte rs . .."

10.4 TYPES OF REQUIREMENTS Requir-ements are commonly cla.ssiRed as either i""" ioll.' o r "o"i"""io,,.1. Thi s classiRcari o n applies to both high. level and detailed requ irements. Each type IS described in the sectio ns that fo ll ow.

10.4.1 Functional Requirements

Fu.d,o•• ' rtquirrmtnls, also known as beh.viora' reqUirements, spec,fy serv, ces that the application mus t provide (e.g., 'The appltcation shall compute the va lue of the lIse r's stock po rt fo liO ."). An appltcation all ows entities Interacting with it (ty pica ll y users) 10 accomplish tasks. Such an enti ty IS fTequent1 y a perso n, but it ca n also be a machine o r eve n ano the r program . Ai""elio,,,,1 "q"i,,",",' speCifies something specinc thatlhe applica tion allows such an entity to accomplish . In o ur video store application , fo r example, the fo ll OWing are fun ctio nal requin:ments .

The appli ca tion allows clerks to check o ut DVDs The applicatio n allows clerks to di splay the cu\to me r's ac ount tatus

10.5 NONFUNCTIONAL REQUIREMENTS

Any requirement that docs no t ~pcc ify fu nct,ona llty prOVided by tht· app lt atlo n I< "0..j"",,,0,,,,1 For cxarnri~ , • requJrement such ., "the ap plica tio n shall dllatll< In ics> th an two seco nd • "no t functional , b ·c.ausc ,t does nnt
233

23<1

CHAPTER 10 PRINCIPLES OF REQUIREMENTS ANALYSIS

somcthlnfl abou t th m). No nfun tio na I req uirements need to be , pc iAc, quantit.able, and testable. Consider a nonfun tlo nal requirement that read, The systcm shall ret neve user informatio n qui kly. This reqUirement is vague (e.g., what docs reln"It mcan l), no t quantifiable (e .g , how fast i quicidy7), and therefore no t able to be tested. An imp roved versIOn of the requirement would be as follows Once the OK butlon is pressed o n the "Retrieve Account In formation " sc reen, the user's account info rmati o n shall be displayed in less than 3 seco nds. This requirement IS specific (because it identi fies a specific button o n a specific screen), '1uantiAable (because of the specific response time), and testable . The documentatio n shou ld make it clear exactly what "the O K bUlton" refers to. Major no nfunct ional categories are· qua/il'" (e.g., reliability, availability, maintainability, etc.), Co", I'
10.5.1 Quality Attributes Rdlabllity "4u""",,,I, specify "the ability of the software to behave consistently in a user· acceptable manner when subjected to an environment in which It was intended to be used." [ 3]. In other words, it is the extent to which defects wi ll be detected by users dUring no rmal operation . This kind of requirement recogn izes that applications are unli ke ly to bc perfect , but limits the extent of imperfection in quantified terms. The following is an example , and assumes that a definition of 'kve l o ne faults" has been provided. The Airport Radar Application (ARA) shall experience no more than two level-one fau lts per mo nth . • Quality attributes • • • • •

Reliability and availability (observed fau lts, ave rage uptime) Performance (speed, throughput, storage) Security (maliciOUS and non malicious compromi se of data o r functionality ) Maintainability (cost to maint.,n) Portability (move to a different operating environment)

• Constraints on the applicatio n or it developm ent

• Extemal interfaces th.t the application "talks to" • Hardware

• Other software • Communication with external agents

• User interfaces

• Error handling Figure 10.4 NOnfunctJonal requirement categories

NONFUNCTIONAl REQUIREMENTS

to

A"",labi/ity losdy rdated 10 re"abllity. quantifie< Ihe degree to which the application is to be ava lable lIS u el'5 The followlllg i an example . ARA shall be avaIlable at level one on eIther the primary or the backup computer 100% of the l1mc.

ARA hall be unavailable on one of thcse computers at level o ne or two for no more than 2% of the time in any 30-day period. Often . high-availability requiremcnts are specified in terms of "the nincs." For example , Ave-nines, or 99999% availability, means that a sy tern ca n o nl y have a yea rl y downtime of 5.256 minutes. This type of requirement might be documented as fo llows. The system shall support "nve-nines" availability.

Ptr/o"",,",, rrqui,,,,,,,,', specIfy timing constrai nts that the application must observe. These include elapsed time for computat ions (speed), throughput, and storage (e.g., RAM usage, secondary storage usage, etc)_ The follOWing i an example . The Stress Analyzer shall produce a stress report of type five in less than a minute of elapsed time . Performance requirements are a critica l part of ,wl-,im, applications , where actions must complete within specified time lim its. Examples include collision avoidance software. Aight control applications, and antilock brake controls. The follOWing is an example . The computation of brake Auid pressure shall complete within o ne millisecond .

Stcurity "qui",,,,,,,, co ncem mal icious Intent toward a system. Th is makes security different from other requirements, which specify application behavior when used by well-intentioned people. One can specify requi rements that contribute towa rds security. These call for concrete measures, such as login procedures, password lengths, and so on, that contribute to making the product more secure. On the o ther hand, imp"cit security requirements are far more di fficu lt to deal with . Implicitly, no o ne wants an application that is vulnerable to attack. so the requirement exists in the abstract. H owever, the nature of many future attacks is not predictable, and so there is no way to specify a requi rement for their defense exccpt In genera l tcrms that are of little value. Mainlainability rrqu"""",', specify how easy or difncult it i to modify the softwa re. as a result of fixing a defect or implementing an en hancement. For exa mple , the easier it i to understand the software, the easier it is to maintain . Maintainability can be measured by th e time it takes to repair defects. The f-ollowing is an e.ample of a maintainability requirement. The average time fo r a maintenance engineer 10 repair a sevcrity ·2 defect shall be no greate r than 8 person -hou rs .

Portabil,IY rrqu",mtnl' Identify those parts o f the sohwarc that may need to run in dilferent operating environments, as well a ~ ho w ea
235

236

CHAPTel 10 PRINCIPLES OF REQUIREMENTS ANALYSIS

• Platform • E.xample: The application must execute on any I CH Linux computer . • Development Media • Example: Tl,e applicatIon must be implemented in Java. • Example. Rational Rose must be used for the design . Figure 10.5 Examples of constraints Tl,e maximum amount of effort to port the graphics subsystem from Windows to Linux shall not exceed 2 person · months.

10.5.2 Constraints A COll s/ralll/ o n an applicatIOn is a requirement that limits the available options for developing it. Recall that requirements are genera lly "what" statements. '"How" is usually left to the design . Constraints can be thought of as exceptions to this. Figure I 0.5 shows some examples. Design or implementation constraints describe limits or conditions on how the application is to be designed or implemented. These (nonfunctional ) requirements arc not intended to replace the design process they merely specify conditions imposed upon the project by the customer, the environment, or other CIrcumstances. They Include accuracy , as in the following example. The damage computations of the Automobile Impact Facility (AEF) shall be accurate to within one centimeter.

Tool alld lallguag< cOlls lra ;II /S are often imposed. These include historical practices within the organization, compat ibility , and programmer expenence. Here is an example.

The AEF is to be Implemented in Java and developed on the Eclipse platform .

D",gll cOlls/ra ;II/' arc imposed on the project because stakeholders require them . They can be speciAed in the requirements document or the design document. Such constraints restrict the design freedom of developers. The fo llowing requirement IS an example . 1he AEF shall utilize the Universal Crunch Fom, to dIsplay impact results. The constraint of having to follow certain , /alldards is often determined by company or customer policies. Here are examples. Documentation for AEF shall confom, to Federal Cuideline 1234.56. The AEF code is to be documented using company code documentation guidelines version 5.2. Projects arc frequently constnined by the hardware platforms they must use The following is an example. AEF shall run on Ajax 999 model 12345 computers with at least 128 megabytes of RAM and 12 Gigabytes of disk space.

NONFUNCTIONAl REQUIREMENTS

• Hardwa~ • Example: "The application must Inte rface with a mode l 1234 bar code reader." • Software • Example: "The application sha ll usc the compan y's payro ll system to retrieve sa lary Inlormatio n." • Example: 'The application shall use version 1. 1 of the Apache server." • Communications

• Example : 'The application shall communica te with human resources application via the company

.

Ifltranel. "

• Example: "The fonnat u cd to transmit "article expected" messages to cooperating shipping companie shall usc XML standard 18 3.34 publ is hed at http :// .... .. Figure 10.6 '!)'pes of external interface requirement for an application. with examples

10.5.3 Extemallnterface Requirements Applications are frequently required to interface with other systems . The Internet is a commo n example of such an external system. Interface requirements describe the format with whic h the application commu· nicates with its environme nt. Figure 10 .6 shows the common types. with examp les 01 each .

10.5.4 User Interface Requirements: prinCiples User interlace design is sometimes included with the "design" phase of software develo pment , but it ca n more properly be considered part of the requirements phase . This book takes the latter perspec tive . including o nl y sofllDare design in the "design" phase, and not grap hi c desig n. Customers commonly conceive of an application by visualizing its graphical user interface (C UI ), so a good way to help thelll describe the application is to develop draft CU ls. Our goal here is to provide some of the essentials of userinterlace design. This is quire different fro m the I,elm lra! design of the application, w hi ch is covered in Part IV. The latter includes considerations of what C UI c lasses to se lect and how to relate the m to other classes. In developing user interfaces for app lications, it is ideal to work with a professional de ig ner, who is trained In user behavio r. co lo r usa ge , and tec hniques of la yout desig n. Fo r many proje ts, however, especially smaller ones, software engineers must design use r interfaces with no such aSSIsta n e . Thus, we lis t some guidelines for user interface design . Calitz [4] provides eleven s teps fo r develo ping user Interfaces. We have adapted these. as s how n in Figure 10.7. Each o f these steps is applicable to the high · level req uire ments process andlor the detailed reqUirements processes. Steps I and 2 are described in C hapter II. Steps 3- 11 arc explored in C hapter 12.

10.5.5 Error-Handling Requirements Rtquiremcnt\ a nalySiS dea ls with two kinds of erro r~ . The first arc th ose that actors make (e ntit ks '"terac tillg with the application suc h as a user or ot he r syste m ), the Sc o nd consi,ts of errors that developers make Errorhandling rcqu"cment~ 'pecify how the applic ation responds to diffe rent· type< of errors. Figure 10.81i ts some of the ways of dealing With errors ~garding the flrs t kind of e rror. error-handling requirements explain h o w the application mli't re'pond to anoma lies In I[S enviro nm e nt For e xam ple. whal ,liould the application do if It rc e lves a m,-,,,asc fro lll

237

238

CHAPTel 10 PRINCIPLES OF REQUIREMENTS ANALYSIS

'rp 'rp

Know your user 1 : Under.tand the bUSlne<s funct.on in que t.on J Apply prinCIples of good creen design S"P' Scl«:t the appropriate kind of window< Itp s: Develop system me nus Sirp 6 Sclect the appropriate device-based contro ls SI,P 7: Choose the appropriate screen-ba cd contro l SI,P 8' Organize and layout windows S'rp 9 : Choose app rop riate color. SI'P 10: Create meaningful .cons S" P f f : Provide effective me sage, feedback , and gu.dance f:

',p

(Hl ) (H ) (H , 0 ') (H, O) (H ,O) (H) (H ) (H , D)

(0 ) (H , O)

(0 )

Figure 10.7 Steps for constructing user interfaces Sourte" "'rlatll!!d from Gafttz.

w~

'!he Bsentlal Guide to user mter13Ct' Deslgl'l Arl lntroductoo to GUI Prind oleS and Techniques," .JOhn WIJef So Sons, 1996.

• Ignore

• Warn user • Allow unlimited retries

• Log and proceed anyway • Substitute default values • Shut down Figure 10.8 Options for error-handling requirements another applicatio n that is not in an agreed-upon format l lt is preferable to specify th is in the requirements document r.uhcr than leave the cou~e of action to programmers alo ne.

The second bnd of error refer. to actions that the application sh ould take if it nnds il,d! having comm.tted an error-that is, becau e of a defect in its constructio n. This kind of error requirement is applied very selectively, because our aim is to produce defect-free applications in the fir.t place rather than cover our mistakes with a large set of error- handlmg requirements. In particular, when a functio n is ca lled with improper parameters, we program a continuation of the application onl y if such an erroneous continuation is prdcrablc to the actual cessat.on of the application. As an example, suppose that we have to specify the requireme nts for a device that automatically applies doses of intravenous drugs. U ser. arc entitled to assume that the application .s thoroughly specified, designed, implemented, and inspected, so that the drug composition and dosage computations arc correct. Nevertheless, it would be wise in a case like this to specify a n independent check of the composition and do age of the drugs before administering them , and to specIfy error handli ng accordingly_Error-processing requlTemenlS in this case may consist of a comple te stop of the application, or. temporary halt and a notincation to the operator of the device indic.ting the problem.

10_6 DOCUMENTING REQUIREMENTS The output of requirements analysis is what the IEEE calls the software requirements specification (SRS)There are several ways In which an SRS can be organized. As we will sec in C hapter I I and beyond, the Ecl,pse open source prOject is organized around three "subprojects." Within each, requiI'Cment are orgamud

AGILE METHOOS AND REQUIREMENTS

I. InlOoduction

1.1. Purpo>c 1.2. op

1.3 Definition , acronyms, and abbreviations IA . References 1.5 Overvi~w 2. Overall description 2. 1. Produ t perspectiv~ 2 . 1.1. System in terface 2. 1.2. U ser interfaces 2. 1.3. H ardware interface 2. 1.4 . Software interfaces 2. 1.5. Communications interface

2 I 6. Memory constraint. 2 I 7. Operations 2 1.8. Site adap tation requirement' 2.2 . Product functions 2.3. User characteristics 2.4. onstraints 2.5. Assumptions and dependencies 2.6 . Apportioning of requirements 3. Specific req uireme nts (sec Figure 9) Appendixes

Figure 10.9 IEEE 830-1998 Software Requirement Specifications table of contents. 1 of 2 SA ' ~~

IEEE Std 830-1998

around several "themes ." The OpenOfflce open source project organizes its requirements III four main pans, a word processor, a sp readshee t, a presentation faCility , and an illustration 100i. In this book we will ofte" use and modify IEEE tandard 830 · 1998 [6 ], ,hown In Figures 10 .9 and 10. 10. The IEEE sta ndard was developed and maintai ne d by a committee of very experienced software engineers . It is very helpful , but it requires mo difi ca li o n and tailoring 10 respond to changes In tools, languages, and p ractices . The Arst two sections of the landard , "In troduction" and "Overa ll desc ription ," correspond to the high. leve l requirement s and arc cove red in C hapter 11 . Section 3 of the standard, the "SpeCific requirements," corresponds to the detailed requirements . It is expanded and applied in Chapter 12 . ext we turn our attention to the essential links of the SRS to the resl of the projecl.

10.7 TRACEABILITY

Tractability is the abilrty to readily understand how the parts of eparate project artifacts relate to ea h other. In particular, it links indiVidual requirements With other project artifacts. (Sec, fo r examp le, [7 ]). A detailed requirement is traceable if there arc clear links between it, the design c lement that accommodates II , the ode that implements it , the inspection that verifies it, and the test that validates It. Figure 10 . 1 I shows relationships between the artifacts, based on a si ng le requirement. Table 10. 1 is an example of how a c hange in a requirement for DVDs in the video stOft application causes c hanges in the remaining artifacts. Hyperlrnking is a c onven ie nt way to transitIOn easrl y between art ifac ts. In particular, the requirements document can be placed on the Internet or an intranet, Jnd dependent artifac t can be connected v •• hyperlinks

10.8 AGilE METHODS AND REQUIREMENTS Agile prOCesses specify requirements analys" by " t e\lablilmpie

239

240

CHAPTER 10 PRINCIPLES OF REQUIREMENTS ANALYSIS •

3. I

External interlaces

3.2 Functional requireme nts -organized by feature , o bject, user class, etc . 3 .3

Performance requirements

3.4

Logical database requirements

3.5

Design constraints 3.5 . I

3.6

Software sys tem attributes

3.6 . I 3.6 .2 3.6 .3 3.6.4 3.6 .5 3.7

Rehability Availability Secunty Maln tai nabil ity Portability

Organizing the specific requirements

3.7. I 3.7.2 3.7 .3 3.7 .4 3.7 .5 3.7 .6 3.7 .7 3.8

Standards compl ia nce

System mode - or U ser class - o r Objects (see right ) - or Feature - or

Stimulus - or Response - o r Functional h ierarchy - or

Additiona l comments

Figure 10 .10 IEEE 830-1998 Software Requirement Specifications table of contents, 2 of 2-detailed requirements SOtIrre IEEE SUi 8JO.1998

and clear enough for all stakeholders to understand and relate to. This vision is kept as concise as possible without compro miSing the shared vision itself. Examples arc as follows, An appl ication that allows VIdeo store personnel to manage DVD re ntals A Web-based calendar program fo r individuals and depalllllents A system that analyzes individual. suscep ,ibility to d isease based o n the ir gene tic infonnation The vision stage is followed by multiple iterations that are typically 2-4 weeks in duration. Such an iterative style ha the advantage of kee ping misunderstandings to a minimum and allowing all concerned to grapple with the requiroments being considered. The requirements for each cycle are gat herod by means of lISt' ,writs narratives, always told from the us"-s perspective, of how the application is to be used. This process is summarized in Figure 10. 12 and described in more detail in the sections ,hat follow.

UPOAnNG THE PROJECT TO REflECT REQUIREMENTS ANALYSIS

Requirement 1---- accommodates-- Design Element

implements

relales 10

relales 10

implements

'<- validales ---:

Test verifies

verifies

---

verities

Code

verifies

Inspection

FIgure 10.11 Traceability among project artifacts Table 10.1 How a change in a requirement for OVOs in a video store application causes changes in other artifacts

Onginal version Requirement

The title of a OVO shall consist of between 1 and 15 English characters.

Revised version The title of a OVO shall consist of between 1 and 15 characters, available in English, French, and Russian.

Design element OVO title: String

Code

class OVO

class OVO

(

(

String title

•

•

•

Title title

•

)

~ing

..QYQ.

•

• •

•

)

class TItle ... Inspection report

Test report

InspeC1ion # 672:

Inspection # 935:

4 defects; follow-up Inspection #684.

1 defect; no follow-up Inspection required.

Test N 8920 . . .

Test # 15084 ...

10,9 UPDATING THE PROJECT TO REFLECT REQUIREMENTS ANALYSIS A project's document sct is a liVing e ntity It has to be "fed and cared for" at regu lar intervals thrOullhOlIl the life o( the project TYPically, when a pha e IS executed, severa l documenl must be updated For very large projects, the proce" of analYZlnR the customer's requirements IS (ormal and or~anl zl'd , Forexampie, the U.S_Department of Defense (000) ohe n publ"hcs a requesl for propo
241

2~2

CHAPTER 10

PRINCIPLES OF REQUIREMENTS ANALYSIS

Develop common vision

Specify user slories and lests

Each cycle: beginning

Write tests lor Each cycle: end

Each

Code

Figure 10.12 Agile requirements analysis

an SRS alone. Such an RFP contains a very hi g h level descripti o n of th e project. The RFP can be thought of as specifying the hig h . level requi re me nts. Contrac to rs res pond to the RFP, and a winner is chosen who creates dctailed require ments. To en ure that th e requirements are sa ti sfac tory, numerous meetiF'lgs are held. These

involve contracto r perso nn el , civi l serva nt specialists and managers, unifo rm ed ofRcers of the Navy or Air Force, and o th ers. The rcsu ltlrlg RS ca n be th ousands of pa ges lo ng. The winning contractor mayor may not be c hose n to perform the actual design and development of the application . Once h' gh · level requirements have been ga thered, the SPMP CJn be updated as shown in Figure 10. 13. Such upd a ting occ urs through ou t the' li fe cycle of an application. The result ing schedule wou ld rypica ll y be like that show n in Figure 10 . 14, containing more detail than th e schedule show n when th e SPMP was o n gi nall y drafted (C hapter 8) but still not ve ry detailed. In

Status after Initial Draft

Status after Obtaining High-Level Requirements

,WI"lo""

Initial

More milesto nes; more specific

Risks

Ide nti fy initia l risks

Reti re risks ide nti Red previously, identify more risks now th at more is known about the project

Sc/xdwl,

Very rough

Preliminary project schedul e

.Desig nate h ig h -level

Cosl EsI;""'lio"

requ irement' engineers

Designated e ngi neers fo r derailed requirements analysis

Very rough

First estimates based o n job conte nt

Figure 10.13 updating project plans after obtaining high-level requirements

I

.3 ...... '.1& 1' [ . ...1 (~a"t'b ~~4S.S

L

AlcHed\le

~

0eI7' 7 ~de,.."

1 '" '.EYote ,...

'! ICC

e ........ rele.u .....2 -0et0 - 0,

-

- 00.1 -

--

C~rec:,.MemerlS

tS$b ISO

-

! - _._------

I I

Figure 10.14 Typical schedule after obtaining high-level requirements

particular, we may know that release 0.0 .2 shou ld be made on November 13, but It may be too early to deCide other parts of the schedule . Cost estimation ca n be improved once hi gh -level requirement have been analyzed. Th e main Improvement stems from the increased understandlOS that developers gain concerning the scope and nature of the application _ Func tion pOLn! estimates (described in C h apter 8) can be made more comp lete , and 0 ca n the estimates derived from them for schedule and labor. Direct bOllom -up e timates can be improved as well. Another factor limiting rhe number of Iterations of the requirements IS the hi g h degree of coord lOatio n required to keep the project documents and th e ource code coordinated . 1111 is o ne reason that hi ghly iterative development techniques such a agile meth ods do not rea ll y atrempt to wnte detailed requirements documents.

10,10 SUMMARY Requirement analysis IS the process of unde rstanding whal ', ,"anted a nd needed 10 an application . The output of requirements analysis IS a software req uireme nts spe Ihcation ( R ), whi h serves as IOput IOtO the design process. The R document used in thi s book is IEEE standard 830 - 1998 ReqUirements arc divided into hig h -leve l a nd detailed rcqlliremen ... Hi gh -level reqUlrement< arc al 0 called business requlfcments These deSCribe why the app li ation IS belOS built and
2«

CHAPTER 10 PRINCIPLES OF REQUIREMENTS ANALYSIS

Iter.ttlon Each requirement IS u.ually ba cd on a """lory along with an explicit acceptance test. A uscrStory IS a hig h . level piC e of req uired runctional iry a seen by the antiCipated user. Detailed reqUirements arc usually expressed in terms of unit te ts r.tther than being wrinen explic itly . After requ irements analysis IS completed (or after each iteration," an Iterative process), the project plan I updated to reflect the new details known about the application . The more requirements that are known, the closer the schedule omes to being fina lized .

10.11 EXERCISES I

Explain wh y a defective requirement could be 100 times more expensive to fix after software is deployed ve rsus being fixed during requirements analysis .

2. Give an examrle or a so rtware application in which the customer is the sa me as the end user. Give an example in which they are different. In each case . identify the customer and end user. 3. In your own words, explain the difference between hi gh.level and detailed requirements. Give an example of a h igh -level and detailed rcq'Jirement for a typical word rrocessi ng application. 4. In your own words , describe the difference between functional and nonfunctional requirements. 5. Explain wh y the foll owing requirement is not sufficient. How would you amend it( " The o rder e ntry system shall not crash more than 5 times per year. The system shall recover from each crash as quickly as possible to avoid down time." 6. Bracken makes the po int that the more constrained an arrlication , the less reliance we have on people as the source of requ irement . (Refer to his graph in Figure 10.3 comparing "approximate percent o f requirements gathered from people" with "type of application.") Can you think of any applications that do not rail on the graph's diago nal ) 7. Agile requirement; ga theri ng calls for a customer representative to work continually with the development team generating requirements . Describe a scenario in which this type of arrangement may produce poor requirementS .

8. What are three major advantages and disadvantages of describing detailed requirements with unit testsi

BIBLIOGRAPHY 1. Brackett , ] "Softw3R' Rcqulrt~mC'nls SEI CU rriculum Module SE I· CM · 19- 1.2: January 1990. hupJlwww sc: ,.cmu.~dul1lbr.uy1 absrracw rcpof'tsl9OcmO19 dm 3cc~srd N ov('m~r 1S, 2009 J.

r

2. W iegers, Kl.rl E., W Mort Abcwr SO/llNrr RC4I1'ttM",fJ. Mic lO
3. Davis. AIVl M ., NSoJlll'IJrt RtqvlrtWlm lj Ob"trlt F"",ho"). a"J Staid", Prentice: Hall, 1993 , p 310 4 Callt'Z, W .• "11.1( EJsmlldl ~wJ( to Uw Irs'tr/act 00'9" k ,,,troJlI( llI1II !D CUI Pmlclp~ amJ Trcbrsrqllt)," John Wilcy & Son .., 1996 S. Alexander, lan , ;tnd Ncoll Malden (Ed itors), ~Sc",,"nos, Siono. US( Cam.. nr~h IIx Systmls Drotloplfln" Llt-Cyru" (pJ.pc'm;u:k), John WIley & Sons. 200 .. 6. ~I EEE Rccomme:ndC'd Pri)c~icc: (or $o(IWolr'C Rc:quJre:me:nts pc:-cl t\ca tions,· IEEE SrJ !JG- I90S, June: 1998 7 Wle:gert, K;ul E. ~Sof'1l)Q rr Rcqllll'CMnfb," Microsoft Prc:ss. 2003.

Analyzing High-Level Requirements

Planning

•

What are examples of customer wants?

•

What does stakeholder

•

How do you mtervlew for and document requirements?

•

How does one write an "overview" requ irements section?

•

How do you write -mcun functions" and use cases?

•

What agile methods are there lor dealing with high-revel requirements?

•

How do you SpeClty user Interfaces at a high level?

•

How does one frame secunty requirements?

•

How do you use dIagrams for h,gh·levet requ Irements?

•

What are examples 01 high· level requirements In practice?

VISion

mean?

Maintenance

The Software Development .-___ '___ Lifeeyele Require,i.e"t•

• ".iysls lion

Design

FIgure 11 .1 The context and learning goals for this chapter

2.6

CHAPTER 11

ANAL YlING HIGH· LEVEL REQUIREMENTS

Hi g h . level reqUire men ts descnbe the purpo e o( an appl.cation and ilS Intended functiona lity. They can al a descnbe the app lication's beneRts to both th e cu>tomer and the dcveloplng organization. This chapter de cnbe th e process w hereby we collect, ana lyze, and specify the requirements at a hi g h level . It is help(ul to express hi gh . level requ irements usi ng both text and dia grams, in o rder to convey a complete understanding of the intended application . Hig h . leve l requirements arc of great interest to all stakeholders, particularly eu to mers, who purchase and ult imately usc the applicati o n based on it require ments .

11.1 EXAMPLES OF CUSTOMER WANTS T y pically , at the time that requirements analysis com me nces, the customer is still (orming concepts of what he o r she wants and needs. ThIS is an.logou< to the requirements·ga thering ph.se between an architect and a client . Fo r ex. mpl"" a client may want a house with (our bedroom s and a large li vi ng room , but nevertheless rel ic o n th e architect to help clarify what he wants .nd needs (e .g ., a ranch house with a living roo m with ealing (or ten ). As an example , consider the Encounter case study. The (allowing is a fragment of customer thinking obta ined by a myt h ica l marketing depal tlllcnt. Encounter is to be a role -playing ga me that simulates all or pan o( the player's lifetime. It should be of interest to bo th male and (emale ga me players. Figur<'S I 1.2 and I 1.3 summarize the hi gh.level requirements (or the Encounter case srudy. The complete descnptlon of Enco unt er hi g h -level reqUirements is contained in Section 2 of the SRS, Overall Description. The requ irements sta tements In Figures 11 .2 and 11 .3 arc at a very high level with detail purposely omitted. For exa mple, th e requ irement "Each quality has a value" does not specify what those values are. SpeCific values are documented in the deta iled req uirements o( Section 3 of the SRS.

• • • •

Ro le·pla yi ng ga me that si mulates all or part of the lifetime of the player's character. Ca me chacac ters no t und er the player's control called "fo reig n" c haracters. Ca me cha rac ters ha ve a number of
• C haracters ""ncounter" each other when in th e same area, and may then "engage" each other.

Figure 11.2 High·level requirements for Encounter, 1 of 2

• The result of the engagement depe nds on the va lues o( their qualities and o n the arca in which the engagement takes place_ • Player characters may reallocate their qualities, except while a foreign character

IS

present.

• Realloca tion takes dfect aftcr a dela y, during which the player may be forced to engage . • Success is measured ... o by the "life points" maximum attained by the player - o r o by living as long as possibl e. Figure 11.3 High·level requirements for Encounter, 2 of 2

STAKEHOLDER VISION

At thiS rag~

requlI"cmcnrs analysis, there are usually unrcsolved bsues such as whether there is to be onc or several h.ra ters under the control of the player, what should occur when two character; Interact, and w~fher thc same an be played over the Internet. It IS the task of the development team to work With customers to clarify their wants and needs_ A common pro ess is to interview the customer, which is d~bed III Section 11 .3. In

Customer nccds can be Subt ler to las ify than their lV.n'" since customers arc typically less conscious of them . For example, a cu tomer may W.II' a musi application that allows computer novices to write music but may "ltd a periodic auto-save function to avoid lOSing work. Whether such a feature i a requirement or part of thc design dcpends on what is agreed between the developer and the customer. If the customer. having underilood auto-saving, wants this feature , thcn it becomes a requirement_ The customer may be content , however, to Icave it to the designer as to how to accommodate the computing needs of novice users. In that case, auto -saving would not be a requirement, but a desig n element.

11_2 STAKEHOLDER VISION The people who have some interest III the Outcome of the product are ca ll ed its ".ktl,old"s. As an example, consider the creation of an c-commerce W'cb SIte. One set of stakeholders consists of the site's Visi tors . Typically, their primary requirement is the ease with which they can And and purchase needed items . Thc company's owners are stakeholders, too. Their primary requirement may be proflt, sho rt - or long-term . For this reason, they may want the si te to emphasize high -margin items. Marketing, another gTOUp of stake holders, may rcquire the Web site to track visitors . The application's developers are stakeholders, 100. For example they may want 10 use new development tec hnology to keep up to date. In the case of packaged (shrink-wrapped) applications such as word processors, spreadsheets, and development environments, as well as their equivalents (such a do,vnloaded applications ), the deve lopment team pays a gTeat deal of attention to the acceptability of the application by as many users as possible. Although this can be a difncult marketing problem , it is clear that the users arc the most signincant stakeholders_ For many large projects, identifying the most imponant stakeho lders is complex. n,e ·customer" is often the pany paying to have the application developed, but even this is not clear-cut For example, the Navy may be paying for an application , but the developers' day -to- day customer may be a civil servant rather than a naval ofncer. Then again , arc not the taxpayers the "customers," since they arc actually paying for the application] The customer of a subco ntractor is the prime contractor. The Ctl tomer for shrink -wrapped applications is a composite of potential customers established by the marketi ng depaltlllenl. WRen an application is intended for Internal company usc, such as claims processing within an insurance company, the customer i~ an IIlternal organization . ConAicting takcholder interests ca n ea
247

248

CHAPT€R 11

ANALYlING HIGH-LEVEL REQUIREMENTS

may hold differing co ncep ts of what a software application enta,ls_ For exa mple, th e poss ible concept of operations for ' a weather syste m" could be • a facility for {"urning raw weather service information ,nto graphica l form or

• a real -tim e system fo r forecasting the weather or • af.\ application for alerting users to weather anomalies These diffe rin g co ncepts of operations lead to very d iffe rent applicationSi The project manager o r requirements engineer helps the stakeholders to clarify their concept of operatio ns , ince custo mers usua ll y lack the means with which to express such concepts, engineers can propose appropriate techn,que uc h a usc cases, data flow d iag rams, or Slate transit io ns, w h ich are described below These tec hni ques are also used for desi g n , as sh own in Part IV.

11.3 THE INTERVIEW AND DOCUMENTATION PROCESS Much of the analysis of requirements IS a person -to-person activity , organized to produce an application satisfyi ng the customer_ Figure 11.4 summarizes the process of preparing for and interviewi ng the customer to

ehcit their require ments. ince there are ryp lcally several stakeholders who want to provide th eir input, the Hrst issue is deciding whom to interview. Recall that requirements co m ing from different stakeholders may be contradictory. It is often effective to Interview a small number of primary stakeholders, and then solicit co mments from other key stake ho lders. Two interviewers at each session arc preferable to one, since a typica l interviewer tends to miss POIn[ . Bringing a recorder can help. with permission requested in advance. The most sig nifica nt person to Interview IS ofte n the most difficult to chcdule time with , so perseverance is called for. Interviewi ng the wrong

Befo're interview: 1. list and prioritize "customer" Interviewees • most likely to delenninc project's success. 2. Schedule interview with fixed sta rt and end times.

• at least twO from development team should attend . • prepare to recordi At interview : 3 _ Concentrate o n listening . Don't be passive, probe and encourage. • persi t in undt'rstandlng wants and exploring "tcds. • walk through use cases, also data flow ) state diagram s) Take 'horough nOles. 4 . Schedule follow -up mee' lng for validation .

After interview : 5 . Draft SRS hi g h -level requirements using a tandard.

6 . Contact customer for commen t'S. Figure 11_4 One way to handle Interviews with the customer

DESCRIBING MAIN FUNCTIONS AND USE CASES

ptOI'le can I.. sult III wa>ted o me and dfort. The e",,,, ' 8 ,1e process in particular tn, ist' that the customer communlt. supply ju
After the meeting , the hig h . level requirements are draft ed on a fo rm at such as the IEEE tandard. The draft should be provided to the customer communi ty fo r co",ments, and successive interviews arc conducled unt" there is sati sfactio n \vith the high · lcvel requirements. The great challe nge we fa ce is expressin g clearly wh at custo mers wa nt and need. W o rd alone ca n be appropriate, but for many applicati o ns, narrative text needs to be supplement ed by Rgllrcs of van ous k,nds. The following sectio ns describe how to express hig h· level requ irements.

11 .4 WRITING AN OVERVIEW An overview is inte nded to all ow readers to quickly understand the mai n purpose o ( the ,ntended applocation. O therwise, it sho uld be as sho rt as possible and should seldo m need alteration whe n projec t deta" s change The ch allenge o f writing a good ove rview is usuall y underesum ated. pro bably becau e it is often thoug ht that ,f one knows what a subject is about then summariz ing it sho uld no t be d ifficult The follOWi ng is an example for the video sto re appltcation, in th is ase, a songle se nte nce suffices V to re is inte nded to help video sto res manage DVD inve ntory and rentals. II IS tempt ing to add mo re details to thi s, but good requirements document< arc organtzed to provide detaI ls 111 o rderl y sta ges, so add ing mo re detai ls hcre wo uld result on dup lica ti o n and could reduce readabil, ty . "Manage D VD onvc ntory and re ntals" prOVIdes substantive info rmat io n but 's genera l enouglt so that changes on requirements detai l< are unl ikely to fo rce ,t to change .

11.5 DESCRIBING MAIN FUNCTIONS AND USE CASES FollOWi ng an overview sectio n, h, gh · level req uorement s u
249

250

CHAPTER l'

ANAL ¥ZING HIGH-LEVEL REQUIREMENTS

narrative of how Ihe application is used [3) . They have become a very effcclive way to express many fun tional high-Icvel reqUIrements. As an exa mple , when using J word processor, we usually ( 1) relrieve a fllc, (2 ) cha nge and add teX! , and Ihe n ( 3) store the resull. Functional hi g h -level requirement. are often naturally cxpre sed as an inleraCli o n belween th e applicalion and agencies eXlernal 10 it, suc h as the user. Agile projects rend 10 employ Ihe idea of IISer slo';t!. TI,esc are si mdar to usc cases but arc broader in scope and have dis llnc t c rileria . U scr stories are de cribed in Sect Ion I J .6. A use case IS ide ntified by its name and by Ihe Iype of u erof the applIcation, called theaclor. The main part of a usc case documcn a typical inleraction bctween an actor and the application , often called a scmario. A scenario consists of a numbered list of steps. Each step should be simply described and include who is carrying out the SlCp. A good way 10 start wriling a usc case is to list the tnai" sllcem sct"nrio, which is the sequence of steps that lead 10 a succt'Ssful o ul come. A single use case should nOI attemprto accouni for a significant number of branches. Other scenarios of Ihe usc case , such as error conditions, are ty pically documented as ext""j""s . For example, Rrlnroc

n File would be a typical use case for a \\lord processor, with the user as actor. The main success scenario

contains Ihe following seq ue nce of seven steps. NOle Ihal each step stans with Ihe entity Ihal execules Ihe slep. ln Ihe case of an error in ope ning the selected file . an alternalive is doc umenled in the Extensions secllon , RetTieve a File Main Success Scenano I. User clicks File menu 2_ Syslem displays op lions new and open 3. U ser clicks open 4. Sy lem displays Ale WIndow

5_ User enters directory and file name 6. User hits open button 7. System retrieves referenced file into word processor window Extensions

7a5ystem dISplays error ind icati ng file could no t be opened It is possible for a single person to use a system in several differenl ways, adopling Ihe roles of differenl actors. In UML, a usc case diagram shows Ihe actors, the use cases, and Ihe relalionship between Ihem. A use case diagram is a useful 1001 for d iagrammatically summarizing Ihe sel of aCIOrs and usc cases without having to show allihe delails of Ihe usc cases. Figure J 1.5 is an example of a use case dia gra m, wilh Ihe names of Ihe use cases shown in Ihe ovals, and the actors drawn outside the rectangle with lines connecting Ih<'TTl 10 the use cases Ihey inleract with. As furlher examples of use cases, Figures 11 .6 and 11 .7 contain examples of lise case scenarios for the I"ilialit< and E"ga9' Forcigll ChMaclcr use cases for lhe Encounler case ludy. The aclor in each of Ihese usc cases is the player of Encounter. Each use case is a sequence of aClions laken by the player and Ihe Encounter game, as shown for Ihe IniJializt lise ease. The Engag, Forrigll Charnelrr use case is a typical sequence of actions by Encountcr and Ihe player, whenever Ihe player's main characler and a fo",ign charaCier arc in the same area .1 the same lime. The aClor in the 5" Rub usc case is a game designer. The actor describes Ihe ability of Encounler 10 support the ediling of rule forcharacler interaction. The Trawl 10 Adjomol Arta usc case is explained in the case srudy accompanying this book. The Stl Rules use case is nOI included in t~ case ludy ",quiremcnts.

DeSCRIBING MAIN FUNCTIONS AND USE CASES

ActOG

Initialize

/ Player

Travel 10 adjacent area

/

Engage foreign character

"'-

""-

Designe r

)

Set rules

figure 11.5 Use cases for Encounter-a UML use case diagram

Initializ~

I. Systtm displays player's main character in the dressing room .

2. 3. 4. 5.

Sysltm P/Qytr P/Qy" Systtm

displays a window for semng his character's qualities. allocates the qualities of his main character. chooses an exit from the dressing room . moves player's main character into the area on the other si de of the exi t.

Figure 11.6 Initialize Use case

Engag~

Foreign Character

I. Sysrtm displays the foreign character in the same arca as the player's.

2 Sys/tm exc hanges quality values between the two characters. 3. Systtm displays the re ults of the cngagement. 4. Sysltm displays player's character In a random area . Agure 11.7 Engage Foreign Character use case

The actor need not be a human role- It ca n he another syste m th at lIses the application. For example, if the application under development I a robot con trol y.tent, then the actor cou ld be a fa tory au tomation system that uses the robot contro l sy~tcm Use cases can handle limi ted branching, but .r there is more than one leve l of bran h,ng, the exte n"on Idea. dc~cnDcd above, ca n be tned Ot herw l e the ",. ca," should probably he decomposed Into other lise cases Even a slOgle branch in a lise cas lead to an awkward description . Forcxample, the follOWing ould be a usc case for a personal budgeting aprl,cation f User selects "add checks' or ' reconcl lr a count"

2 If ' add che<.k. selected ,

251

252

CHAPrER 11

3

ANAl YZl NG HIGH-LEVEL REQUIREMENTS

ne .et lo n happen> not her a lio n happe ns

5

. (one o r more stcps)

•

6 . If ' reconclle account" selected: 7 One action happens S. Another actIon happens

9

• •

Th is would be better decomposed '"to "select o ptio ns," "add c hecks: ' and "reco nci le accoun t" use cases. Use case are like tones and so they provide excellent insight into applications. They can be expressed at d.ffe nng level of generality. The Uni Red Software Development Process [4] reco mmends using detailed use cases to specIfy a large fractIo n of the requirements. A usc C35e that is si milar to an existing o ne yields li((le addit io nal value . Usc cases sho uld be stq"mlial, or el e orlhogollal to eac h other. T wo usc cases are sequentia l if o ne can follow the o ther. Orrhogo"al is not a preCISely deli ned term , but o rthogonal use cases take completely different views o r options. For example, in a warehouse appl,catio n, usc cases based o n a fo reman actor and a Rnancial anal ys t actor would typIcally be o rth ogonal. In the Encounter case study, Sri Rul" is o rth ogo nal to £"gag, Forrig" Cbaraeltr. Chapter 14 shows how use cases are combined to produce new usc cases; it also introduces inheritance among usC' ca cs. Jacobson's [2 ] inspiration fo r the idea of use cases was that, despite the huge number of potential executIon . mos t applIca ti o ns are conceive d of in term s of a relat ively small number of typical interactions.

He suggests starting application desig n by writing usc cases, then usi ng them to drive class selection. This technique is demo nstrated in C hapte r 12. Use cases are also the basis for system·level test plans. Many established documentation standards, including the IEEE's, predate use cases and they must be augmented to accom modate them. The Encounter case study describes them in Section 2.2 ' Product Functions' of the SRS, as th IS IS the sect Io n that describes the functi o nal high -level requirements. Although use cases arc often identified with object-o riented methods, they can be used with any development methodology.

11,6 AGilE METHODS FOR HIGH-lEVEL REQUIREMENTS HIgh -level reqUIrements fo r ag de projects arc collected and understood in a manner si milar to that for non-agile methods except that the requirements process operates ," pieces and continues continuously through most of the li fe of the project. Non-agi le processes requi re a time when requirements are frozen (,.e , beyond which the customer has no right to change them). Agile processes, o n the other hand, accept frequent chang~ in require ment as a necessity How can one of these be a valid approach without the other being invalid] Th .. difference lies in the level of truSt e ngendered by very close customer contact. If the customer's trusted represe ntative works continuall y as part of the development team , it is unlikely that he will suddenly ask fOf un reaso nable requirements In agile processes, selected h igh-level requirements arc elaborated upon within each iteration. Each is usuall y based on a ",,,slory or slori", each accompanied by an explici t acceptance teSt A uscr story is a high-level piece of required functionality as seen by the antlcipaled user. According to B~k and West [5] a use r story must be discrete, estImable, teStable, and prioritized, as described in Figure 11.8. Compared with use ca es, us"r stories are described less by their form than by these qualities. Having to be estImable is o ne d ifference, and this is ill ustrated in the example below. User stories can al a be more utens;ve than usc' cases.

AGILE METHOOS FOR HIGH·LEVEL REQUIREMENTS

I. From US.,'S P"l"$pcctive

2. Dlscret., • Single functionality, feature , o r expectation . • Not neees anly precise. 3. Estimable • Developers can estimate required effort. 4. Testable 5. Priori tized • By customer, in consultation . 6. Can be Ilt in a Single cycle.

Figure 11.8 Required qualities of a user story

Beck and West [5J give an example of how to ga ther user stories. Thc custo mer starts wi th the fo ll owi ng story.

0.0 Will outpeifom1 all other u",dill9 machilles This is fine cxcept that it's no t estimable-there is no way to esti mate th e effoft reqll1red to carry out th is job. Consequently , the developer probes fo r more speCific stories to o btain estimable ones, a process known as splitfing. 1.0 Payment. Will accept all killds oj paym"'t' 2.0 Freshness. Will sell

110

stale or ou tdaled mcrchalldise

3.0 Restocking. Will auton,atically request rcstockill9 oj iteltls selli1l9 best ill tl" arm 4.0 Communication . Will (omm lm icntt with tht cus lonur

10

prtvw l tran sactio" (rrars

This is an improvement, but these are still not estimable, so further splitting is required. Recall that prioritization is also ca lled for . The agilc programmcr the n requests more speCtfics concernin g the highest priority story. If this were ' .0 Pay",,,,t , the uscr mi ght provide the following : I. t Accept coins

1.2 Accept

('''''"ey

1.3 Accept debit card 1.4 Accept mdit card

1.5 Acapt debIt or mdit card

1.6 Accept Jortlg'rl coilts {HId 1.7

OHVCrl

Uta

W,b Irallsaclioll

( UfralC)',

at least

C'IH 0 5 Jar snits III

Europt

("ur(tHeirs

1.8 Ellsu" Ihal pay",,,,t m"IS or t')(",ds tb, cosl oj th, "ltCled /Jrod" I

1. 9 Makr chall9'

253

254

CHAPTER 1 1

ANALVZING HIGH·LEVEL REQUIREMENTS

0 .0 WI/I

outperform all

o/h8r wmding machines

NOI eSlim able

Spill P8ymen~

Accspt all kinds 01 psyments

Spill

2.0 Freshness. Sell no stale or outdated

1. t Accept coins

1.0

merchandise

3.0 Restocking. Automatically request restocking 01 Items sell/ng best In tha

area 4 .0 . ...

t 2 Accept currency

t .3 Accept debit card 1.4 Accept credit card 1.5 Accept debit or credit

card via Web transaction 1.6 Accept loreign coins

NOl eSlim2ble

Needs prioritlzalion

••••

Figure 11 .9 SplItting user stones

The plrlling process is Illustrated in Fi gu re 11.9.

11.7 SPECIFYING USER INTERFACES: HIGH lEVEL Th e speCIficat Io n of a user iNerface at a hi gh leve l is often included rn the high . level requirements. Recall fro m SectIo n 106.4 rhe fo ll OWi ng steps in specifyi ng user interfaces. Step I . Know your user Step 2 . U nderstand the busrness function rn questio n Step 3. Apply pnnClples of good screen desig n Step 4 .

•

W e wrll discu s Steps 1 and 2 in thi c hapte r as the y app ly o nl y to h ig h · level requirements. The rem ai ning sleps arc described the nex t chapter, on dctcu led requirements.

11.7.1 Step 1: Know Your User ThIS step invo lves understandin g the narure of th e applicatio n's eve ntual u ers. Figure 11 . 10 outlines ome of the fac tors Involved The c heck lis t IS a way of ensunn g that we know the ba IC c haracteristics of the anticipated u ers, and that we documen t our as: umptions. These characteristics determine the nature of the

user interface. In genera l, users with less educa ti on, trainin g. skill , and moti va tion rcquir~ grca t~r simplicity, more explanation , and more help. This may have to be traded o ff against ef~de ncy and speed. It is 011<11

desirable to provide several levels of uscr interface, dependin g o n th e leve l

01

the user.

11.7.2 Step 2: Understand the Business Function ThIs Slep requires the d esig ner to understand th e purpo e of the particula r proposed u or interface in I.nms of the application's overall purpose. For example, If th e busines purpose is the stocki ng of. warehouse, we may

SPECIFYING USER INTERFACES: HIGH lEVEl

• u,vd of knowledge and experience • Computer literacy (high; moderate, low) • 5) tem expenence (h igh; moderate, low) • Experien e with Imdar application (h,gh , mode ra te; low) • Education (h igh school; college; adva nced degree) • Read,ng level (> 12 years schoolmg, 5- 12; < 5) • T yp ing skd l ( 135 wpm; 55 wpm; 10 wp m ) • Characteristics of the user's tasks and jobs • Type of use of this ap plication (mandatory, dIScretio nary ) • Frequency of u e (co ntinual; fTcque nt, occasional, o nce .in .a-lifclIme) • T umover rate for employees (h, gh , moderate; low) • Impo rtance of task (h igh , moderate; low) • Repetitiveness of task (hig h; moderate; low) • Training antici pated (extensive, self-trainin g through manuals; no ne ) • Job category (executive; manage r; pro feSSio nal; secreta ry; clerk, etc. ) • Psychological characteristics of the user • Probable anitude towa rd job (posi tive; neutral; negative ) • Probable motivatio n (hig h , mo de rate, low) • Cognitive style (verbal vs. spatial , analytic vs. intuitive, concrete vs. abstract) • Physical characteristics of the user • Age (young; middle aged, elderly ) • Gender (male, female ) • Handedness (left, ri ght, ambidextrous ) • Physical handi caps (blind, defective vision ; deaf, mOlOr handicap)

Figure 11 .10 KnOw your user when developing requirements Sot.rce: Adapted from GaUtz. w.. '''Tl'Ie fsse"t~1 Guide to User Interlace Oestgn: Ar11nvoauClJon to GUI pnno ples and technIQues: ' John Wiley & sons, 1996

want the user interface to reflect the layout of the warehouse floor. The seque nce of screens that appear typica lly reAects the manne r in which use rs no rmall y carry out their tasks for thc business at hand. Sometimes the execut ion of a program ca n b e e nvisaged by displayi ng a se ries of C UI images . For exam pic , OAe could provi de a fair co ncep tion o f Encounter by di splayi ng a seq ue nce of scrcen sh o ts. Figures 11. 11 a nd 11.12 arc exa mpl es of preliminary C UI sketches forsc lling the qua lities of an Encou nter character. Upon being show n C Uls, the customer typicall y realize that he needs more or wants o meth ing different. In the exa mple how n in Figure 11.11 , it could well occur to the cus to mer tha tthc C UI for c hangi ng

Ouallbes

Value chosen

11.11 Preliminary sketch of user Interface for setting game character qualities

255

256

CHAPTER 11 ANALYZING HIGH·lEVEL REQUIREMENTS

Name 01 adjacent area

Name 01 adjacenl area

Name of adjacent area

Name of adjacent area

Figure 11 .12 Preliminary Encounter screen shot SOOrCf!- GraphKS reproduced WIth permiSSion frorn COfet,

the value of qualitIes is awkward because the total number of points may not change. The cu tamer would also probably observe that the CUI is no t visually appealing. The process of Rnalizing the CUI is very interactive. The detaIled requirements provide precise CUI specification , as explained in C hapter 12.

11.7.3 GUI Transitions Applicallons typica lly involve multiple CU ls. The high ·level requirements describe the required mouse aCllon that take the user from one CU I to another. Figure 11 . 13 shows a useful way to represent the transitions between CUls. When a particular CU I IS present on the monitor, the application can be co nsidered to be in a partIcular ,tal,. Changing from one CU I state to another is ca lled a l,a" ,;l1o" . States a-nd tran itl ons are actually more general concepts, and are described further in Section 11.9.2.

Indicates slart stale /

cricJc 'slock OVO"

An event

(usually a

___- - - - - - - - - - . - - . . ., mouse action)

GUI (a stale)

StockIng DVD GUI

GUI

Transition Hit ·commlt" butt""

Figure 11 .13 GUI transitions for video store application Introduction SOurce' copvrfpn .I. E. J 0l1Ude. Jdll Whey & sons. 2003.

SPECIFYING USER INTERFACES: HIGH !.£VEL

Select ------~-;:==== "stock OVO'

Select

•

',egi;;s;:;te:,---:::7L..-:.~-::=====:: ~---~

customer"

Select

Se/ect "egis/ef

' check our

customer"

•

Se/ect

Chac:Idng Out DVD

' check our

• Hit "commitbutton

~~~~. ____________•__~CI=='I=~=.;lg~l_n_D_VD __~

FIgure 11.14 GUI transitions for video store application Source: Copynght

E. J Braude. JOhn WIley & SOns, 2003.

A typical CUI/ transition diagram for the video store example is show n in Figure 11 . 14 . While a particular CUI is being displayed , an application is said to be in a particular , 'aic. We explore states further in Section 11.9.2 . Figures 11 . 15-11 . 19 show rough sketches of the CUls referenced in Fi gure I 1. 14. The deta iled requirements provide compete detail.

Select Procedure StockDVD

@

Register customer

(0)

Check out DVD

@ @

Check in DVD

Figure 11 .15 Rough sketch of "Select Procedure GUI" referenced in Figure 11 .14

Stock DVD ntle

I

I

Number 01 copies

fl&ure 11 ,16

Rough sketch of "Sketch of Stock DVD GUI" referenced In Figure 11 .14

257

2S1

CHAP~R 11

ANAlYlING HIGH·LEVEL REQUIREMENTS

Register Customer First name

I

I

Last name

I

I

Figure 11.17 Rough sketch of " Register Customer GUI" referenced in Figure 11.14

Check Out DVD DVD name

~

I Customer

~

I

Figure 11 .18 Rough sketch of "Check out DVD Gur' referenced in Figure 11 .14

Check In DVD DVD name

Figure 11.19 Rough sketch of "Check in DVD GUI" referenCed In Figure 11.14

11 .8 SECURITY REQUIREMENTS Many security requirements can be dfeC1ively expressed at a high level because we can express security goals without having to anllcipate all of the specific breaches that can OCCur Here is an example from the Eclipse project. The Eclipse Platform should provide the basic framework for a security mechanism that can be used by all plug· ins. Including a simple credentials store and u er authentication Additionally,

SECURITY REQUIREMENTS o ConAd~ntiality o

"C'

D.t3 passed not vi,Ible to the unauthorized.

o Nonr~pudi.tion

o

• Pani~ can prove the eXistence of agreement!:.. Integrity "I"

Ability to alidate no tlaltered in transit. o Auth~ntication "A" o Ability to vahdate user's ident Ity . o Authorization • P~rmi sion to deal with the subject . • Availability o

o

For example, a compromised by denial-or-service anacks

FIgure 11 _20 Common security requirements key pans of the Platform itself should be secured , such as the abi lity to onstall plug-ins, whIch might need to be restricted in certain products or (or certain users. I Standard c1assilkations for h igh-level security requirements are shown in Figure 11 .20_ They are mmetimes collected into the acronym "CIA." which stands for "Confidemiality , Integrity, and Authentica tion ." Figure 11.20 add 1I0llrtpud,alloll , which is the ability for panics to a eomract to prove reliably that the contract was indeed made _ It also adds nlllhonZailoll , which specifies who may access what panicular information, and availability, wh,ch speCifies reaction to denial-of-se rvice attacks. Denial -of-service attacks are activities, such as Aoodlng a Web site automatically with requests, that make i difficult for anyone else to access it. We ensure that these propenies are satisfied by suitable corresponding requirement at the detaded level. However, ill-meaning perpetrators devise ways to compromise systems by explOIt ing combonations of propenies that the sy tem does 1101 possess. To explain th,s, consider a (non -software) set of requ irement that were already devised to ensure that ,he funds in a prominent Irish bank werc secure. These required that two bank managers, each possessing a dIfferent key, were required to unlock a major safe. TI,ey .1 0 reqUIred COnstant guards for the managers. Both procedures wcre fa ithfully observed . It is important to understand ,hat for perpetrators, exi ting sccu rity mcasures simp ly con titllte a set of constrain, wilh,n which they work, elling them to seck opponunities that the constr.ints do not cover In the case of the bank example , there wa no requltement for guards on the f.milie of ,hese two officia ls. Observing th is combina tion of prope nies that the system did "01 po seS5, enminals took ho>to go the famil ,es of both managers and by this mean ocrced the officers into obtaonong the bank's cash on their behalf_ PrIVacy is often hnked with or considered part of ,ccurity . This is because the purpose of many exp loits" to gaon accts, to data to whIch the perpe trator" not entit led , thereby compromising its pro a _ One t:Xamplc of priva y regulations IS the Health Insurance Ponability and Ac ount.bility A t of 1996 (HIPAA ), whIch regulate> hea lth inlo mla tlo n rea ted o r maIntained by health care prOVIders who CI1!l"llt in tksignated e lectronIC hea lth care tran a tlons _The Department of Health and Human ervlCes IS respon ,ble for implementong and enforCIn g HIPAA The a t took cHeu on April 2003 _ The main thrust of HIPAA I to en>ure that an ,"dlvldual\ health infoml.,ion 1< u,ed lor health purp
259

260

CHAPTER 11

ANAL YlING HIGH·LEVEL REQUIREMENTS

• n,e H ea lth Insur.ln cl' Po rt abilIty and A counl abiltl y Ac t passed In 2000 a nd 2002 ; 2003 compha" e • Regu lales health information c rea ted o r mallltalned by health care providers • U Department of H calth and Human rrvlces rc< po nslble fo r Im plementin g

•

and enfo rCi ng

lalll thrust· Ensure th at an IndI vIdual's hea llh In fo ml . tl o n IS used only for health pu rpo
Figure 11 .21 MaIn poInts of HIPAA Source HIPAA Act of 1996

pertaini ng to an indi Vidua l is housed (·Iectron icall y an d/or is rrtm mitted over telecommunicati o ns system s!

netwo rks. The standard mandate safeguards for ph ysical stora ge and maintenance, transmission, and access to IIldividua l health info rmat io n. EntitIes reqUIred to co mpl y with the standard include any health care provider, hea lth care clearing house, o r health plan that electronicall y maintaIns o r tronsmils health information pt'Ttaining to an in divi dual · Figure II 2 1 ummarizes these poi nts.

11.9 USING DIAGRAMS FOR HIGH-LEVEL REQUIREMENTS Acc o rd ing to D avi [6 ) and WIegers [7 ), no SIngle VIew o f requirem ents gives a complete understanding, and It IS o h en hel pfu l to represent hig h ·leve l req uire me nts usi ng dIag rams. What IS o ften needed is a combination of text and dIa g rams to convey a complete pic ture of the Inte nded apphcatlon . We introduce two types of dI agram used to descnbe hI g h . level reqUIre men ts: da ln flow and ' Ialt lra tl,illotl dia grams. We are using them he re to express requ irement . Thcy arc often used to ex press deSIg ns as wdl , and this can be confusing. The dIffere nce to watc h fo r IS not so much th e fo rm of ex pressio n as whe ther th e attempt IS to express ' what" (requ ireme nts) o r "how' (desig n)

11.9.1 Data Flow Diagrams Some requirements are na turoll y described as th e flo w of data am o ng processi ng e leme nts. Fo rexample, imagllle that our customer is tryin g to explalll what he want fro m an ATM banking applicatIo n, startm g with depo It and affecting accounts at several locations In a Jain flow dlagra .. , the Hod" , sho wn as CIrcles or rectangles, represent processing Untts. ThearrolDS between nodes deno te th e Ao w of data . The arrows are annotated wilh the data's type . Dalll , to,rs-places where data reside, such as databases arc den o ted by a pair of honzontallincs enclosing the name of the data store. ExIt""" a9C>1CtCs such as the user and printers arc represented by rectangles. For the ATM application , the dtpo,il functi o nality mig ht get the deposit from the user and check tht deposit tronsawon to ensure that It IS legitimate. These '"nnions arc represented by clfcles In Figure I I n . Next , the type of data Rowing between the functions is noted on the figure- the account number and the depOSit amount. The user IS involved. too, and so IS represented A function to create a ~lI",mary of account'S, 10 give another example', requires input from a store, as shown .

A more complete data flow diagram for the ATM requirement would be as shown in Figure II 23.

UStNG DtAGRAMS FOR HtGH'lfVEt REQUtREMEPlTS Processing 81811.801

Input Get deposit

i-----UIIr

ACCOUnt no.

Direction of data now

and deposff

Outout

Dala type

Prtnlet I

•• • •••

Validate deposit

Balance

query

I Data store

Account

Account __ dala

Create account summary

database

figure 11.22 Data flow diagram explanation of symbols

The complete diagram of Figure 11 .23 includes the "member banks" data score , which is a list of banks allowing a deposit at this ATM. It also shows the data Aow for the response to a query, in which details about an account are displayed. ExpreSSi ng these requirements in text form only would be marc difRclllr than using a data Row diagram to help describe them . Notice that data Aow diagrams do not show COnlroi. For example, the ATM application does not indicate what function occurs first . Standards used for the symbols differ among organizations (e .g ., rectangles ca n be used for the processi ng elements rather than circl",,). Whether or not data flow diagrams are helpful for expressing requirements depends upon the application . For example, the ATM data Aow diagram in Figure 11. 23 clarifies for many re.ders what behavior the application is mcant to exhibit, whereas video game requirements would probably not be

Member banks

Get deposit

I

Bank nDtnB

User

Error

Inquiry

Account

..-

Account II & deposll

Get

j

Error

account display

Validate

Validate deposit

Inquiry Account II

Account II

Display

Make

account

Inquiry

Prfm'

& deposir

Account

dar. Do deposit

transaction

BaIanC6 query

'\J

06po!U Account "'"""unl 1,.n08elion _.- _. database -- 00/8

11 ,23 partial data flow diagram lor ATM application

Create account summary

261

262

CHAPTER 11

ANAL ¥ZING HIGH-lEVEL REQUIREMENTS

descnbed well uSin g a data now diagram . When usinM these dia gra m' for require ment s , peClnc.tlon, there i~ a "snlAcant dan ge r of hpp inl! into perfo n"in g desig n ,"stead o f analyzlnB reqUirements. For example, If an appitcatio n IS reqUired to tra ck the now o f o rders within a compan y, then a data now diagra m (DFD) shOwing thl proces at a h ig h level would be an appro priate form for hi g h-level reqUi re me nts because the DFD " nceded to ex press the o utcomes O n the other hand, consider an application that is required to apply a complex formula . A DFD explain,"!! the calculation process would be part of the design , but nOt the req Ui re me n15- the fomlula would be uffi cient for expressing the requirement . We will r<-vislt data Aow d iagra ms in Pan IV, the de ig n ectlon of the book.

11.9.2 State Transition Diagrams Sometimes, an application, or pan thereof, is best th o ught of a being in one of several slalrs. The Sta te of an application is its si tuati o n o r s tatus. States are sometimes called "phases" or "stages ." Although a state often correspo nds to a CU I and vice versa, the state concept is more general than C Uls_The idea is to divide the applrcatlon into sta tes so that the application is always in o ne of these states. Note that the states we arc de fi ning arc based o n the requirements of the appl,c.ation-not its software design . For example, it might be useful to think of an o nlrne sho pper at a bookselling si te as being either in "browsing" state (looking at book info rmati o n) or in "purchasing" state (providing credit card information , etc.). A diagram that depicts the different states and the transitions between states is ca lled a sial, lrallsilion diagram . There arc several pOSSible Enco unter states,

• 5,l/mg up· the stare during which the game is being set up • P"ilOring. equipping th e players character with qualities such as "strength" and "intelligence" can be performed as lo ng as no foreign c haracter is present

• Wa iliHg. noth ing is happe ning in the ga me th at is experienced by the user • Engaging the state in which the player's character and the foreign c haracter arc exchanging quality va.lucs The e sta tes arc sh own in a UML state transi ti o n diag ram," Figure 11 .24. For eve nt -driven applications, diagrams Irke this can be an effective way for the custo mer and developer to obtain a shared concept of how the: application IS meant to work . After identi fyi ng the states, the Imn silions between states are added. TranSitions, denoted by arrows, arc each labeled with th e name of t he ro," 1 that causes the object to change from one state to another. Events arc

Preparing

_~ Setting up

,

,••

(initial state)

I

Player clicks quaNties

Complete setup

I I

,I

menu •

(final state) , •

Wailing

ForBign character __--j ' - - - - enters 8f8a

Figure 11 .24 Partial Encounter state transition diagram

,, ,

Engaging

USING DIAGRAMS FOR HIGH-LEVEL REQUIREMENTS

Stale EY..~

Coodilioo

Player

moves to

adjacent ~ 8rea

{foreign character absent]

{foreign character present]

Engaging SIal9

Condition

Figure 11_25 Using conditions In Slate transilion diagrams occurrences that can cause a c han ge in the object's state . A t)'pical eve nl on a CUI is a mo use c lick. The soli d circle denotes the startin g state. The final state IS d e pic ted by the solid circle inside another ci rcle. States and transitions ca n apply 10 entitic at many levels. For example, a ship ca n be in one of several stales, such as Sailing , Docking , or Dock,d . Parts of the shi p ca n be in evera l states, For example , a cabin can be in Occupied or Unoccup"d state. Sometimes, when an objec t is in a give n state and an eve nt occurs, the object can tran itlOn to one of

several states, depending on a condition . For exa mple, when thl- player decides to move h er character 10 an adjacent area, the ga me tranSItions rTOm th e Waitillg state into one of two states. O ne possi bili ty is to transition back to Waili"g state (if the foreign c haracter is absent from the e ntered area ); th e o ther is to transition to the Engaging state (if the fo reign c hara c ter is prese nt in th e entered area ). In UML, co nditi o ns arc de noted b y square bra cke ts, as sh ow n in Figure 11 .25 . The complete state transition d iag ra m for Encounter is sh ow n ID Figure I 1.26 O nce the player has fi n ish ed scumg up the Encounter ga me , the latter transitions from s,lIillg Up state into Waiting state. If Encounter IS in

Se\1Ing up

Ptayer dismIsses

Reporting Setting qualltle$

report Player completes setup

window

Player set qualities window

requasts status

Foreign chartJcter

enters area

enters area

moves to adjacent area

{foreign choracter pro.ent]

• Fleur. 11 _26

requests to __- set qualities

Player

Playor quits

Player

Encounter sUite transilion diagram

Engaging

~-===

263

264

CHAPTER 11

ANAL VZING HIGH·LEVEL REQUIREMENTS

\\fmfl"9 ,tatc and a forc l!!1l harac ter e llterl, the n Ellco""ler trln,itlo n, IIlto E1I9a91119 sta tc F,gurc 11.26 ,nd,catc, th.t th c pro c-; . of setlll1g qual ity va luc< .nd the pro e» of repOrllllg the re,ldts of an e ncounter ca n b<: int el1\Jpted by thc amv.1 of the foreI g n c haracte r The laller allse< a new encounte r to commence Immcdiately. A sta te Iransltio n 1110 del is a good way to explaIn the o llce pt of opera tI o ns of Encounter State tran Itio n model arc commo nl y used as de Ig n 100is a well (sec hapter 16 ) Whe ther o r no t they should b<: used to exprcss 11Ig h . level reqUlremellts, as we are dOlllg here , depends o n the apphcation in questIon and h ow helpful doi ng so IS fo r the custo mer. Tim ma y require ome edu cati o n of the cu tomer. For man y app1.catl oIlS, each tate correspo nds to a C UI H owever, there .. a wide variety III what we may de Rne as a state . ll,e tate d iag",m in Figure 11 .26 corre po nds rOll ghl y to the pre cnce of VIsua l artifacts on the mo nito r, but thcsc are no t C Uls. Fo r example, when the foreign ch.",ctcr FreddIe appear o n the monitor, the app1.catlOn t",nsltio ns to E1I9n91119 tate, but rreddie is Just an additio nal g",ph,ca l clement, not a scpa"'te CUI.

11.10 CASE STUDY: HIGH-lEVEL SOFTWARE REQUIREMENTS SPECIFICATION (SRS) FOR THE ENCOUNTER VIDEO GAME

Note to the Student: Using a standard 10 write the SRS helps one to cover all of the aspecrs of requirements that readers need to know about, and provides a recognized structure. Seve",1 standards are avail· able , but we WIll concen""te on the IEEE Stan· dard. The complete IEEE 830·1998 standard can be found in [8). Most organizations allow modi · fkation of the standard to tailor it for their own use In fact, the template used below modi Res the standard by omitting some less important sec· lions and by addlllg sections on concept of ope",lions and use cases. The reader can com· pare the case study headings with the standards shown III Figures 8 and 9 of Chapter 10. In the case study portion of this chapter, Sections I and 2 cover the high .level require · ments. The remainder of the document, Sections 3 and 4, containing the detailed requircillents, IS

provided in the case study at the end of Chapter 12 . Recall that customer requirements are not intended to be detailed enough to develop the design and implementation thi is the purpose of rhe detailed reqUIrements.

History of versions of thIS document,

1/ 19/98 Hal Furness Initial draft 1/29/9 8 Karen Peters: Reviewed for technical accu",cy, changes made throughout

2/ 1/98 Hal Furness: Entire document reviewed for small improvements 2/ 19/98 Karen Peters: Document reviewed and suggestio ns made 2/29/98 Karen Peters: Moved use ca.ses to Section 2.2 3/ 1/98 Hal Furness, Improved thro ughout; sense not changed

wording

5/20/04 Enc B","n, Updated to 830·1998 standard 14/ 20/08 Eric Brannen, Edited to improve as· sorted clarifications

1. Introduction 1.1 Purpose The purpose of this entire document (not the purpose of the application ).

This document provides all of the reqlliren1cn~ fo r the Encounter video game Parts 1 and 2 are II1tended pnman ly for customers of the ,pplicatlOn, but will al
tended primarily for
be 01

mtcrt: t to

ustomers.

CASE STUDY: HIGH-LEVEL SOFlWARE REQUIREMENTS SPECIFICATION (SRS) FOR THE ENCOUNTER VIDEO GAME

1.2 SCOpe (The Iospccts of the application this document is intended to cover.)

Thi document covers the requirements for release 0.0. I of Encounter. Me ntion will be made throughout thIS document of sele ted probable fea . rures of furure relea es. The purpose of this is to guide devdopers in se lecting a design that will be able to accommodate the full ·scale application .

Encounter is to be a role-playing game that simulates the lifetime of the player's main character. It should be of interest to both men and women. The measure of 'success' in playing Encounter is up to the player. Typically. success will be measured by the ' life points' maxImum attaoned by the player or by the ability of the player to live as long a life as possible. Some game characters arc to be under the contro l of the player. The rest. called "foreign" characters. are to be under the application's control. Came characters will have a fixed total number of points allocated amo ng qualities such as strength. stamina, patience, and so o n. C harac ters encounter

1.3 Definitions. Acronyms. and Abbreviations See Table 3.3 .

1.4 References Software ConHguration Management Plan (SCMP) for Encounter version 1.0 Software Design Description (SDD ) fo r Encounter version 1.2 Software Project Management Plan (SPMP) for Encounter version 1.2 Software Quality Assurance Plan (SQAP) for Encounter version 1.0 Software User Documentation Plan (SUDP) fo r Encounter version 1.0 Software Test Documentation (STD ) for Encounter version 1.0

1.5 Overview Intentionally omitted.

The author of this document felt no need for this section. and ontends to cover the overview in Section 2.

2. OVerall Description MAke this !leneral enough so that it oS unlikely to chanllC much in future versions. Avoid tC&lelllcn" that are repeated on later sections.

each other when they are in the same area at the same time. and may then engage each orher. The result of the engagement depends on the values of (heir qualities and on the environ ment in which the engagement takes place. Engagements are not necessarily violent or adversa nal. Players have restricted opportu nities to reallocate their qualities . One of the player-controlled characters will be referred to as the "main" player character.

In early versions of this game. there wi ll be only o ne player·controlled character and one foreign c haracrer. The eventual nature of the characters is 10 be determined fro m insights gained from surveys and locus groups. It is expected that initial releases will not have anionation Encounter should eventua ll y be hig hl y customl zable. so that users can eit her start with predefined games . substitute predesig ned char· acte rs and rules of engagement. or devise their own characters and ndes of engageme nt. The design shou ld support expansio n into a fa mily of games. including Intemet ·based multiple playoc versions.

2.1 Product Perspective In this secti on. Encounter is com pared with other related or competing product . This os a useful way to prOVide perspective on the application . Subheading 2. 1. 1 of thos section h.s been changed from the IEEE standard to accommodate "concept of operattons."

265

266

CHAPTfR 11

ANAL Y2ING HIGH·LEVEL REQUIREMENTS

· n OUnter IS Intended to tu lAIl the need (or prog",mme'" to have a g rea ter IOnuen c OVer the ntent o( video ga mes with additiona l program · ming It IS al 0 intended for a somewha t mature clientele Encounter is IOtended to appea l to bo th ge nders . The de iBn and documentation (or Encoun · ter will make it convellient to expand and modify the ga me. It IS anticipated that Encounter will be used as a legacy application for expansion IOtO applications such as o ffice Interaction simulati o ns .

2.1.1 Concept of operations This section conveys the overall concept of the application by whatever mea ns are most natural for doing so. In the case of Encounter, the requirements developers deci ded that state/transitions best convey the concept.

the sta ndard IEEE head lOg ' u.>er in terfaces" 10 empha ize Ihal the«: arc not the detailed C Uls

2 .1 .2 .1 Area User Interface Concept The areas In whic h encounters take place sha ll have an appear· ance very ro ug hl y like that shown in Figure 11. 12. 2 .1 .2 .2 User Interface Concept for Setting Quality Values When sctti ng the values o( game characters under his control, the player uses an In terface o( the form sketched approximately in Figure 11 . 11. The scroll box i u cd to identify the qua lity to be SCt, and the tex t box IS used (or setting the value.

2.1.3 Hardware Interfaces None. Future releases wi ll uti lize a joy tick.

2.1.4 Software Interfaces No ne .

Encounter can be 10 o ne o( the (oll owing states (also shown 10 Figure 11 .26), • Setting up. The state set up by the playe r

10

which the game is bei ng

• Reporting. The system is displayi ng a window sh owi ng the sta tus of the players character(s). • Se tting qualities. EquipPing the players character With qualities. Thi s process consumes arbitrilry

amounts o( time, and can be perfo rmed as long as no torelgn character i pre cnt

• Engagi ng . The state that app lies whenever a for· cign character and the player's main character are present in an area

3t

the same time .

• Waiting. The: player and the (oreign character(s)

2. 1.5 Communications Interfaces No ne . Future releases wi ll Inte rface wi th the Internet via a modem.

2.1.6 MemoryConstraints Encounter sha ll require no more than 16 MB of RAM and 20 MB of secondary storage (see test plan < test refere nce to be supplied ».

2. 1.7 Operations No rmal and special operatio ns required by the use r, uch as modes of operatio n, da ta proc· essing support functio n , a nd back up and re· covery operations .

• are not actIve.

This state/transit Ion is tested by integration test < to be supplied> .

2.1.2 User Interface Concepts The followlOg figu,..,. are preliminary sketches of key I'ser i nl~c(s o nly , used to proVIde PCISPCC· live o n the producl. All lhe user int., laces are ~pccifi.ed in derail in Section 3. We have modified

It shall be possible to ave and re trieve a game.

2.1.8 Site Adaptation Requirements Req uiremen ts for execution o n a particular installat ion; versions in various la"B"lIcs (e.g., French, Japa nese, panish ). No ne.

CAse STUDY: HIGH·LEVEL SOFlWARE REQUIREMENTS SPECIFICAnON (SRS) FOR THE ENCOUNTER VIDEO GAME

2.2 Product Functions

I. Player h its hyperlink connecling displayed area to adjaccnI area

Summary or the major funcltons of the applica. tion. This section is more detailed than Section ' .5, but does notattemptto supply all details, as doM in Section 3. The writers of this SRS ckcided that use cases are an appropriate man. ner in which to specify the overall functionality

of Encounter.

2. Syslcm di plays (he indIcated adjacent arca Including player's c haracter

2.2.3 Encounter Foreign Character Use case ActOr: Player of Encounter U sc case: I. System moves a foreign game character into the area occupied by the player, or Player moves into an area containing a foreign character

This section specifies Ihe required overall func . tionality of the applicalion, but is nOI Inlended to provide the complele specifications. Sectio n 3 pro. vides the requirements in complele detail

2. Syslem causes the two c haraclers to engage

2.2.1 Initialize Use Case

4. If eilher the player's characler or the foreign charac ler has no pOinls, the game terminates

Actor: Player of Encounter Use case: Figure I 1.27 gives the lexl of Ihe JnitJalizt use ca e. The use case is shown in con text with the Eneo"nl" foreign ebameltr use case and the Sri ",It, use case. Initialize is Ihe typica l sequence users execule at the beginning of a session. This use case cOfT~ponds to test < Iesl referen e to be supplied> in the Software T eSI D ocumeOia tion.

2.2.2 Travel to Adjacent Area Use Case Actor: Player of Encounlcr U se case:

Actors

Travel 10 adjacenl area Encounler foreign charaCler

Designer

5. O therWise, Syste m moves the player's character to a random area different from that in which Ihe encounier tOok place, and displays it there

2.3 User Characteristics Indicate what kind of people the typical users are likely 10 be. Examples: novice, software professional , accoumant with five years of computer usage, etc.

Initialize Initialize

Player

3. Syslem displays the result of the engagemenl

Sal rulos

11 .27 Initialize use case (or Encounter

- - 1. Syslem displays playefs main character In the dressing room. 2. Syslem displays a window 'or setting his charactefs qual~les.

3. Player allocates the qualities his main character. 4. Player ohooses an exit 'rom the dressing room. 5. System moves playefs main character Into the a_ on Ihe other side of the .xlt.

0'

267

268

CHAPTER 11

ANAL VZING HIGH·LEVEL REQUIREMENTS

The u cr IS expected to be approXImately 203 ye.n; o( age

the devel o pers. It IS antIcIpated that they WIll be part o( a futurc release "OptIonal" requITement. will be Impleme nted at the dI scret io n o( the developers.

2.4 Constraints These are all conditions that may limit the developer's options. They can onginale from many sources.

Encounter shall operate o n PCs nlnning Windows XP or later at a minimum peed o( 500 1Hz. Java shall be the implementation language.

2.5 Assumptions and Dependencies (Any assumptions being made future hardware.)

(or example,

11.11 CASE STUDY: HIGH-LEVEL REQUIREM.ENTS FOR ECLIPSE

Note to the Student: This section discusses published requirements for Eclipse. There is no single requirements docu· ment (or Eclipse the requirements arc spread over multiple documents. The authors have reconstructed a partial requirements document from thesesourcesata single pointin time, p.lacing them roughly in IEEE fonnat for the sake of comparison. The result is necessarily incomplete, and illustrates a shortcoming of many 0 pen source projects. Most of the material below is quoted directly (but selectively, of course) from the Eclipse documentation online at the time.

o ne

2.6 Apportioning of Requirements (Order in which requirements are to be implemented .)

The requirements described In SeC1ions I and 2 of this document are referred to as "customer requireme nts"·, those in Section 3 are referred to as "detailed requirements ,f The primary audience for customer requirement is the customer community, and the secondary audience is the developer commu nity. The reven;e IS true (or the detailed requirements These two levels o( requirements are intended to be consistent. Inconsistencies arc [0 be logged as defects . In the event that a r('quiremcnl is stated within both the customer req uirements and the detailed requirements, the application shall be built (rom the detailed requirement version since it is more detailed . '"Essential'" requirements (rdefred to in Section 3) are to be implemented (or this ven;ion of Encoun · ter. "Desirable' requirements are to be implemented in this release i( possible, but are not committed to by

'The Eclipse Project is an open source software development project dedicated to providing a robust, full.featured, commercial ·quality, industry platfonn (or the development of highly integrated tools. The mis· sion o( the Eclipse Project IS to adapt and evolve the eclipse technology to meet the needs of the eclipse tool building community and its users, so that the vision of eclipse as an industry platfonn is realized: ' 'The Eclipse workbench consists o( lOim/olDS. Each window contains part,. Each part can be a vittD or an wilo,. A pmPte/iv< is a physical conRguration o( pans. Figure I 1.28 shows a typIcal Eclipse screenshot: ' This example is a Java perspective (as indicated in the shortcut bar). This pen;pective consists o( a Windows Explorer-type of view, an editor, and other parts, including the console view.

This panicular window is used merely as an example, to make the speci6cation more understandable not as a detailed spedRcalion-

, From http://www.eclips• .orWp.oJcc.slindex.h.ml. • Ibid.

ECUPSE PLATFORM SUBPROJECT (FIRSl OF THREE!

..,

P .... 'ucth •

.. . ... l

•

~.r

1u,,11

J...

.. To Ch&l\ir ql.u 9"eT. t'ld ~ _ , 'JO t .o : WHY' . , Pr.,faaac: ' C E bit:T. t ~ ca,.cod " aDI1 " . ~_ ••

•

~::~1

. . .

. .. , 7

7

)"otu ,U

• • ••. \\ )Mo ......

,.y...

.El.... ueut .. C""' 1109 ..

l S part. )."tuI "log bordC1" .. " ."port , •••••• 1 l1'9 . . ... l ..

.. "'It • •

Ho,90'tuLt

#-.o.Q

~ .P.£ SF«

, lb..,lIctJ ..)

J

5 1"'091 1 hllll Lc_ • _ . S tr t"9l

SUuri J e!ht,lt.c-.• • aew S t r\lr9{ c .... r ( I hId "tcu' . II '0' c ....r l J eo:hlS!:. :n:t cu t a ' Z J

-1

!.J( -u....,......• _._"

..

·c

n

.

•

- Cu , '

---

_.erE

0Copf

lotu.h""

Agure 11 .28 Eclipse GUI SOUrce: Edlpse, flttp :JIWWW e<:lrpse org/articlesJAttic~UI-GoidellneslJndex.hltnl.

The following three sections are quoted from Eclipse documenration WIth some adaptanon .

11 .12 ECLIPSE PLATFORM SUBPROJECT (FIRST OF THREE) Note to the Student: Since Eclipse IS organized around three sub· projects, it is natural to org.nize the summary requirements in the same way . With l ~ each project, summary requirements are organized ilround """,,cral "themes." Th,s IS a way to orga· nize the (high· level ) reqUIrements and allow latitude at the samc tIme The the mes do pro · vide content , but they avoid pecifying d etails.

The Eclip e Platfo rm provIde. the fun dam ental building blo ks of the Eclip e projects Plan tasks arc new features of the Ec hpse Platfo rm o r igmhcan t reworking of exi tlng feature lany of the hanges under con. iderallo n for the next release of the Echpse Platform addre s three majo r themes, a follows · • U ser experience theme. ImprOVIn g Eclipse from the poin! of vIew of the e nd u e r • Responsive UI theme . Making it easIer 10 wnte EcI ,p e plug· ,ns that keep the UI re ·pon"ve • Rich client platform theme. Ce nera hzl ng Echl',e into a platform fo r building no n. ID E appJ.ca tlo ns In addtno n, there are Impo nant E itp<e PI.tfoml Improvement, that do not natu rally ht IntO a ny of the above themes The<£: are a tegori:ed as f 1I0w< •

ther E IIp e PI . tfo m1 IIems

269

270

CHAP I ER 11

ANAL YlING HIGH -LEVEL REQUIREMENTS

Belo w a", examples elaborating upo n these .

User EXperience Theme Th, the me incl ude, Imp rovi ng bo th the "o ut o f the box" experience

0

th at new users arc producti ve

too lbars, and le ng thy nat l, sts of preferences Th .. pro blem IS aCllte In large Eclipse-based produ cts. The Plat fo rm sho uld provi de add itI o nal ways fo r control _ ling wo rkben h clutter, such as funher menu and toolbar custo ml za bil ity, d isting UIshing be tween novIce and ad va nced func tio ns, suppanln!! d.rfc rent de· veloper roles. and ma rc speci fic o bject contributions fo r panicular me ty pes ., ( 37929)"

fas te r, and fi nd ing bellc r ways to scalc up to large num bers of plug .ins witho ut overwh e lmin g the user.

Committed Items (Eclipse Platform subproject, User Experience theme) The requ irements h ere arc grouped by priority. ' Commltted" IS the highest priority. The o thers are · proposed" and "deferred." Completion of a requirement is denoted with a green

c heck mark.

Improve UI scalability "Des pIte dfo n s to e nsure UI scalabili ty WIth a large base of avai lab le tools, the Ecli pse wo rkben c h still Intim idates ma ny user'S wi th

II_pm·

The number given above in parentheses is a link to the following bug cntc",d in Eclipse's BUgzilia bug database, https/ /bugs.eciipse.orglbugsl show_ bug.cgi7id =37929. This and other requirements are managed in the same way as defects The reason is that both deRne work to be done on an existing application. Each Bugzilla location contains extensive discussion about the requi~ . ment and the progress made imple",enting it. This amounts t'O the detailed specification. common way of specifying detailed requirements in open source projects. The begiAning of Bugzilla Item 37929 is shown in Figure 11.29 and Figure 11.30. We w;1I rerum to the subject of requirements tools in Chapter 12.

long menus, wide

ht l7nf r;-.. ....,!mp:tO'l' m.... '.)

&.aLiK &:It.!!IIcn.~ ... .. ,....,

~

¢'«nt.,.

w.... t .

• C' .f!! .." ~

r."': , "' "'" .. ,~ • ;: ' .., ~'" 1t'~I:DI'·'" :hI I

"''''"It

Figure" .29 USing Bugzilla in Eclipse to track bugs and detailed requ irements, 1 of 2

ee•

ECUPSE PLATFORM SUBPROJECT (F(RSf OF THREE) Leaw as RESOt VB» m Rn (' a.opmbvj r Marie. bua as VERn I F I) (" Mark hue as CLOSEn t:'

Vltw Due Acdvll)' I Format For Pabidn& Description:

- - AdduJCnaJ CO" ....'"

!!l. Prom.hm.us RN..,.s200J..Oj.21 1/.·/ 8 - •••

--AddlhOnaJ Co,.""", !!l. From MorPMus 200J·Q6.08 14..40 - -

I ~ olad af ter ceadlDO the [cllp3e Pr o) e c ~ Dratt 3.0 pIon tha t 1n ecl l ~e 3.0 that tble bUQ q01QO to be a4dre3~ed , but I a130 V&nt tbe peo ple who 13 going to eusdce~5 t.h13 bUQ to pc ovld.e Cop 1 ' ~ t o do ~bC' lIICnu and t. oo lbar cU3t.D:lll ECot i o n ( 1 ,e, 01108 u.s to remove WlVDJlt.ed IIICQ\,I 1tc....., peoor" "Q~ l c ally ) • It .,..... .. a .. a

~"

...... r .... '; .... ~ ... ,.. r _ ... .. . ; ... . . . ...... " .... .-.-. . .. .. _ _ .. ......... r ,..,. . ........

_ "'_,.v

FIgure 11.30 USing Bugzifla in Eclipse to track bugs and detailed requirements. 2 of 2

Improve initial user experience Users who are new to a n Eclipse·based product ca n find the ir first experiences with it overwhelming , even dauntin g. The initial experie nce would be improved if a product cou ld preconfigu rc the work · bench to show o nl y the subset of function that a new user really needs; welcome pages could be personal . ized for part icular use rs roles or levels o f ex perience . . " (37664 )

Improve U/ affordances . , . (3767 1) "Work romp/tId

proposed Items (Eclipse Platform subproject, User Experience theme) The ' proposed" category is the second most im · portant priority. Note that these requirements are expressed in an exploratory, less specific, manner. Requirements analysis still has to be performed to transform these into commil1ed items.

Th e fo ll owi ng work items are being ac tively Investi gated , but we arc no t yet ab le to promise any solutIOn for th is rolea c .

Allow editors to open files outside workspace This is a way of tracking the status of requirements.

A ommo n reque t is to be able to use Ecil psc to open a fi le that i not part of the workspace, or " erhap' even o ne o n a remote ys tc m, In add ilion, appli ation

271

272

CHAPTER 11

ANAl VZING HIGH-LEVEL REQUIREMENTS

would like to provide fi le exte nsion associa tio n so that doub le -cl icking o n a Ale in th e 0 de kto p would open th e assoc iated Ecli pse edi tor. The o perat io ns and capabi lities ava dab le o n th ese 'outsi d~ of the workspace" Ales wo uld need to be deA ned . (37935 )

Improve workspace synchronization with file system . ... De tails o mitted

(. recently deferred item) Provide a general purpose navigator (36961) ... These arc just a few examples Ihat illustrate the organiza tion o f th ese documents.

Other Eclipse Platform Items The foll o wing are examples from the Eclipse Platform subprojec t within this "theme."

Content-type-based editor lookup. ... Details o mitted

Deferred Items (Eclipse Platform subproject, User Experience theme) The Ecl ipse project t racks requ ire ments that may never be imple me nted. This enables them to be revived , provides history, and discourages th e m fro m bei ng pro po ed again. It helps to clarify th e project's directi o n.

These items are next In line fo r chis release. As comm ltters complete th eir assigned tasks or add i· tiona l help becomes available , some of Ih csc items may be comm ilted for Ih is release:

Add table of contents support to wizards (36947) .. . D etails omitted

Add project templates (36960) . .. J - .. (. recently de-committed item) Aid ongoing learning (37666) More tracking the status of requirementS. "Decommitted" means, dfectiv¢ly. "dropped'

Design Constraints: Compatibility of Release 3. 0 with 2.0 and 2.1 Thissecti o n is qlloted from note'. It consists of no nfunctional requirements, and one example is expanded here. A "breaking" change is one that preve nts some applications from executing on the new version that did execute on the old one. N o te also that this paragraph contains po licy elements for requirements rather than requirements themselves.

' Ecl ipse 3.0will be compatible with Eclipse 2.0and 2. 1 to the greatest extent possi ble. The nature and sco pc of some of the key plan ilems are such that the only feasi ble solutio ns wo uld break compatibility. Since breaki ng changes are a di nlption to the Eclipse commun ity, they ca nno t be taken lig htly. We (the Eclipse PMC) wi ll have an opcn d i cussio n with the community before approving a proposed breaking change for inclusion in 3.0. In other regards, Eclipse 3.0 will be compatible with 2.0 and 2. 1. W e also aim to minimize the effort requi red 10 po rt an existing plug-in to Ihe 3.0 APls. We wi ll provi de a comprehensive EeU"" 3 .0 Port"'9 Guide that covers all areas of breaking AP I c hanges and describes how to po rt eXisling 2. I plug-ins to 3.0. Up-to-date drafts of Ihe Eclipse 3.0 Porting Guide will be included with miic-slo ne builds so that It'S possible to climb .baaed the 3.0 rel eu e wago n at th e earl y stages. o r to estimate the amou nt of effort Ihat wi ll be involved in eventually porting exisling plug-ins 10 3.0'• hu pJ/www ecl ipse oeg/e Ilpse/developmen t! cc hps<-proje l_pl.n_L0..20040 130.htm l.

CASE ST1.JOY: HIGH-LEva REQUIREMEIflS FOR OPENOFFICE

11.13 CASE STUDY: HIGH-lEVEL

REQUIREMEN I S FOR OPENOFFICE

nather than to SpeCify its requirements. The follOWing is found at http jlwww.openofflce org/productlwriter.html _

This s«tion is intended to give the reade r an Idea of the O~nOfflce requirements. No~ 10 the Student,

The prose below has been adapted by the iUlhol'5 from httpJlwww.openofflce.org/prod _ uaJ which was written with a partially marketil18 Ravor. For example, we have replaced "WRITER is a powerful tool _. _" with "WRITER is a tool . _ ... "You can easily integrate images" has been replaced by "It facilitates integrating images.' OpenOffice requirements are decomposed at this top level as shown next .

OpenOfflce consists of the following , • WRITER is a 1001 for creating profeSSional docu ments, report , newsletters, and brochures. It facil itates integrating images and c harts in doc uments, creating everything from business letters to com plete books with professional layo uts , as well as creating and publish Web content. • CALC is a spreadsheet that facilitates the absorpti o n of numerical information . It e nables users to calculate, analyze, and visually communicate data. Advanced spreadsheet functions and decision making facilitate sophisticated data analysis. C harting tools ge ne..,te 20 and 3D charts. • IMPRESS is used for the creation of multim edia presentatio ns. It allows specia l effects, animation , and drawing tools. • DRAW faCilitates the pro duc tio n of everything from si mple dia gra ms to d y nam ic 3D il·lustratlo ns and special e ffetts. • The Da tabase User Tools faci litatt'S day to day database work in a Simple preadsheet-like form Th<-y su ppo rt dBASE databases and ODSC or JDBC

High-Level Requirements for WRITER It appears that th e: o nl y hi g h -level desCription of WRITER IS wntten in a style to attract users

"WRITER ha everything you would expect from a modem, fu ll y equipped word processor. It's si mple enough for a qUic k memo, powerful enough to creale comple te books with conte nt , d iagra ms, i ndexes. elc. You're fTee to conce ntrate o n your

message, while WRITER makes It look great The Auio-Pllol takes all the hassle out of prodUCing sta ndard documents such as letters, faxes, agendas, minutes. You arc of course iree to create your own templates. The SIyI,SI puts the power of srylc sheets IntO the hands of every user. You're free to add words and phrases to the Aulo Corrcc1 dlClionary, which can c heck your spelling as yo u type Aulo ompltlt suggests com mo n word_ and phrases to complete what YOll are ty ping Ali loFormal takes care of lhe fo rmatting as you write, leavi ng you fTee to concentrate o n your message.

Trxl fram" and linking mean you arc free to lay o ut newsle tters, Ayers, etc. exactly the wa y you want them to be. Increase the usefulnes of your lo ng, complex docume nts by generatmg a table of contents o r mdexing terms, bibliographical references, dl uslr.! tl ons, ta bles, and o ther objects. You are free to choose yourow n email sofrware-","' RITER offers direc t connection to email sohware . Make your documents freely available with WRITER's HTML expo rt to the Web, o r publish in Portable Document Format (. pd to g uarantee that what YOli write IS what you r reader sees Of cour;.c, you are free to u e old Microsoft W ord docume nts, o r save your work in W o rd format fo r end ing to people who are still locked int o Microsoft product>.'

-

We would ex press these mo re following .

like the

WRITER s hall be a fu ll -feot ured word proce, · or It hall all ow Ihe crea ti on o f "nlple d and complete books With o nte nl " d,.gr>n" Ifl dexe , e tc An e.amplc IS sh o wn In FI~lIre I I , I

273

27.

CHAPTER 11

ANAl YlING HIGH-LEVEL REQUIREMENTS

""""'-.4. ..

.... " .... t..

1'10

~

.~

M

"urn.", (,,, t

M"'~

'1lI0I'I''. 6: =rlo. d IN ,• • ",om CDs, ,.I m!"~ ........ rtd I ~om

Of

""" ,,.nch. collO", ~(. T"t'II!' o,eftO'!U.OI" fP1'\"\hEl)' h.I~ WI tt..IMdb .. d:, bed Ibn bu, IdOI~ . "oud WI _ _ c. ~" L l

bat,..

~UII'P LJ ~G)e ' . _

...

""".$ "'" ~ ,.06:. t:JCIi,,..... Ltd ... _

o8lcw .....,."7 ... Ja" fl. MI kI _

Ow 1IICII1' dltU ,..'

.

I\u 001_n btoUt '

...

Hi g'"

.an' ••

~ !MeDte aM .f~ u l

IsIh Is

RA y.A/'.... IttJOI."",, ·ou todqMfd~Itt . . . h

bllJ_rsMWIplluavws.rs

. . . J.,,_I'I(

Mfl&

COI$

~~f'>fI

"U' H>,dIMtOWltl1ls

fir

£N.'

fo,,,.,.

51)01 _ _ ii4iJ'ld

~.s OIl 'Cu £V0*

Figure 11 .31 Example of document open in WRITER SOUrce OpenOfflce. htUll /WwW ~ce orgIprodUCVplxtwriter-Oig.png.

WR ITER's Aulo-P,/OI feature shall fac ditate th e creation of standard doc uments such as letlers, faxes , agendas, mimHes. The ry/is l featu re shall allow th e user to easdy vary th e sryle of a docume nt. The Aulo omel dieliollQr), feature shall check spell ing duro ing or afte r te t entry The AuloComp/crt feature shall uggests common words and phrases to comple te a partia ll y typed sentence The A"loForma l feature shall handk formattmg while th e u er e nters text. Tht lext fram es and /ill/UII9 feature shall all ow the user to Ae xi bl y fo ml at newslellers, Oyers, etc. WRITER shall generate a table of contents, mdexes, bibliogra phiGlI ",ferences, Illustrations, and rabi es. It shall prOVide dli~ct connL'C!ion toe-mail software, export KTML to the Web, publish in Portable Document Format, and save work 111 M,crosoft Word fom,.t We will skip addItional reqUIrements for O~nOffice . It carries man y of its detailed

requirem e nts in an app licatio n coiled (rather unpoe tically ) /,,"tzilla . Issuezi lla consists of "issues ." An issue could be a bug but it could also be a task . This is similar to Eclipse's use of Bugzilla . Some Ope nOfnce projects have created

more careful

requirements

documents. For example, the OpcnOffice PROJECT Management Toolset (draft a, ') and the OpenOfflce Bibliographic module (draft at .) .

, h"plloopm openofll e o rgiR lesldocument 171/ I S43100PM_Requoremen"_D"cu,,,on_DraftJ\ I. pdf os of 2005. h t t p J1wv..'W .gCOCII jC'S.com/ma nI ;;h_k.....1grJwaVBi blio_ h'ml a of 2005 6

rtq

EXERCISES

11.14 SUMMARY Thi chapter has described the process whereby the high . level requirements for a product arc obtained and rKorded ,n a manner ctear to the customer and developing organization . High.level requirements describe the purpose of an application. its intended functionality. and Its bencht . The high ·level requirements arc documented on a form uch as Sections 1 and 2 of IEEE 830· 1993 Software Requirements SpecIfications. Variou techniques for ell itlng ane:! record ing high .level requirements are used Onc way to gather requirements is to interview stakeholders and potential customers. A combinatIon of text and diagrams is used to document the requirements. The following guidelines can be used to choose the appropriate form . • If a requirement is simple and stands alone, express it in clear sentences within an appropriate sectio n of the SRS.

• If a requirement is an interaction between the user and t'he application, express it via a use casco • If the requirement involves process elements, each taking inputs and prodUCIng outputs, U e a data Row diagram . • If a requirement involves states that the application can be in (or parts can be on), usc a statc transitIon diagram. States often correspond to CUls. Use cases are Widely applicable for describing customer requirements because the y capture user application interactions. If a state transition diagram expr~sses what the customer wants and needs and the customer understands the diagram, then its use is appropriate . The sa me ho lds for data fl ow d iagrams User interfaces arc speCified as part of the high . level requirements . Two importa nt principles for defining high. level user interfaces are to ( 1) know your user and (2) understand the busine s function in question . High.level requirements for agile projects arc collected continuously through most of the life of the project. Each requirement is expressed with a US" slory. A u er story is a high. level piece of reqUired functionality as secn by the anticipated user.

11.15 EXERCISES 1. Describe In your own words the dIfference between custo mer "mills and custo mer IItcds. PrOVIde an na mple that illustrate the difference . • 2 list four of what you consider to be the most impo rtant h ,g h. level requirement~ for an appl, atlOn that tracks bar·coded InvOIces withIn a compan y

3 IntervIew two separate people about their hi gh. level requlrement< for the bar·code appto ation speCIfied in Exe rCISe 2. mparc the requirement gathered frnm each interviewee How si molar or dIfferent an apphcat lon dId each of thtm e nvi sio n ~ How c1,d It o mpare with the h, gh. level requirements you I!e n erate d ~ Wrote a paragraph summarizIng the sunolarlto c< and dlffere n es, thl' importance o f Intervlewln/( different stakc hold ." for their viSIon of a o ftwa re al>pll ~tion, and how you might re( on ile the diff ren cs

275

276

CHAPTI:R 11

ANAL YlING HIGH·LEVEL REQUIREMENTS

\,(t hat I a usc ase) I the following a usc case) Why or why not) 'Tho sys te m shall provide advice for Ih e beginning Windows user on how to execut< Windows operations." 5. Write a usc case for one of the hi gh. level requiremenls " sled ,n Exercise 2. 6 Why is II importanl to show customers preliminary sketc hes of C Ul s as early in the development cycle as possible) Cive what YOll consider 10 be o ne o r two of the most important reasons. 7 . Your customer needs to specify u er interface •. Discuss twO o r three of each of the pros and Cons of the fo llowing means for doing this in the conte xt of the application (large o r small ) and the nature of the C UI (complex or imple). a. Ske tching using ha nd drawings, your own o r draw n by a gra phic artist b Sketc hing using graphiCS tools, such as Paint or PowerPoint

c. Using the C UI ·building features of the target la nguage of the application 8. D raw a data flow diagram to ex press the high.level requirements of an application that tracks the flow of orders wit h in a company. 9 . Consider an application that manages patients in a docto r's of Ace. Patients call for an appointment and thei r information is entered into the application . Patients ca n call to reschedule or cancel appointments . Afte r a patient is seen by a doctor, the patient may be referred to ano ther doctor for treatment' if necessary. Draw a state · transition diagram to express the h igh. level re quirements for this application.

TEAM EXERCISES TI 1. 1 Write the high·l evel requirements for a n application decided upon by the ream. Follow tho form of IEE£830·1993. Track the a mount of rime spont doing this exercise. Decide what fraction ofth. requirements are understood by the tea m. Estimate how long it wo uld take to obtain 95 porcenr of rhe requi rements. State how the process you used could have been improved. Be speci fic, a nd provide examples. TIL2

a. Identify an individua l outside the team who needs a modest a ppl ica tion. You will be gathering high· level requirements from this ind ividua l, thcn showi ng thcm to him or her. b. With yeu r ·custome r: identi fy metric, for how he or she will evaluate yo ur high· level requirements. Also determine the time limit fo r an interview (e.g ., a half hourl. c. Interview the customer, and write th e high·lcvcl requirements. d. H ave the customer evaluate and com ment on your high· lcvel req uirements in accordance with the

chosen metrics.

BIBLIOGRAPHY I

~OntS. AI.,n. &~n. Wixom, 3.nd DaVid T eg3rdcn , "5)'5,,"j AMI)'lJ1IHld On'I" wi th UMl. Vffl)OfI ] 0 AI' Ol,«f.Ortt14r.cJ Ap~,OItCb. · John

Wlln"

Son~. p

139, 1005

BIBUOGRAPHY l. JoooI>wn. Iv... · Ol,od 0M0"" So!..,." E.gl• .m,,/' A U.. C." On·... App,..cb." (Addison. W«ley Obj
277

Analyzing Detailed Requirements

~--

Matntanence

The Software Development Ufecycle

Rgure 12.1 The context and learning goals for this chapter

•

What ways are there to organize detailed requirements?

•

How do you express user interfaces in detail?

•

How do you express security requirements in detail?

•

What kinds of error conditions can be specified?

•

What is traceability and why Is It important?

•

What ways are there to prioritize requirements?

•

Why associate requirements with tests?

•

How do agile methods relate to detailed requiremen1s?

•

How do you use tools for requirements analysis?

THE MEANING OF DETAILED REQUIREMENTS

ft~r luSh -level requIrement are spe Ifled , tYPI ally (or an iteration , the next ste p in rcquorcments i is to define the deraIled req uirements. The purpose 01 de taIled requirements is to provide the reader WIth absolutel y .lIth.t's requored of the application . W,th o ne exce pti o n, the re i no where cI e fo r the team to state <XiI Ily what thIS conSIsts of. For e ample, if we do no t state here that the title of a VIdeo mu.t appear In • t6-poont font on th e mo no tor, then we aSSume that thos will no t appear In the produ ct The "exception" mentio ned above refers ro the pOSSIbility 01 eother stat Ing each detail ed requ irem ent as a comment In the so urce code or of expecting source code and its unit tests to effectively specify the requirement. Thi tends to be the approa h oI agile projects, which we discus ed previous ly. Ag ole projects do not rule out the kind of documentation char we di scus In this c hapter, but they value working code ahead of Sll

h separa te documentation.

This chapter concenrratcs on wriue n deta iled reqUireme nts. However, whe ther o ne writes down d~tailed requirement in these ways o r not , there is no c hOICe but to eventua ll y think them thro ug h. In fact , they fo rm a common currency of app licatio ns, as it were Detail ed requirements arc usuall y d ivi ded on to sectIons, including funct io nal requirements, no nfunc ti o nal requirem e nts, and CUI deta ols

12,1 THE MEANING OF DETAILED REQUIREMENTS Detailed requorements provide software e nginee" with a ba is lo r deSIg n and Implementatio n. n,ey are sometimes called "specific requirements," "functi o nal speCificat io ns," o r "developer requirements." Detail ed requirements consist of a complete liS! of specific prope rtI es and functionality th a t th e application must possess, expres ed In complete detail. Eac h of these requ irements is labe led, and tracked thro ug h imple· mentation . Detailed requirements a re consistent wit h, and e laborate upon , the h Ig h -level req uireme nts _They ar< inte nded to be read primarily by developers -h owever, customers are inte rested in the m as we ll , and should be able to understand and commen t on them wi th few exceptions. Recall that the primary aud ie nce fo r the h ig h ·level re.q uire m ents consists of customers. As the case studies in this book demonstrate, when it comes to software e ngineeri ng, "the deVIl is In the deta,ls: For example, in 1999 NASA lost a weather sa te ll ite wo rth a rep o rt ed I $125 mill,o n, reportedl y because control data they had assumed to be in metric fo m, was no t [ I J .. the root cause for the loss of the M eO spacecraft was the failure 10 usc metric unit s in the coding of a ground software file , "Small Forces," used in trajectory mo de ls. SpeCIficall y , thruster performa nce data in English units instead of me tric units was u ed in the software app loc.toon code titled SMJORCES (s mall forces). A fi le ca lled Angular M o me ntum Desaturation (AMD ) contained the o utput dara from the SM JO R ES so ftware. The data In the AMD fi le wa< require d to be III me tric units pe r existing o ltw.re Intwface docume ntatI o n, and the trajectory modelers assumed the data was provided in metric unIts per the requireme nts.' This descri ptIo n ,mpl,es that the req uireme nts stated the need for metnc un Its but the oftw.rc d id no t Implement the requi re me nts correc tly A fascinating fact os that thIS defe twas Ide nti ,ed with", mere day, afler the d,saste r. Th, s mea ns thai it may not be hard to loc.te a defect o nce we kn ow it I present. The pro llcm is often OUr Ignorance o( liS presence The d etailed requi rements lo rm the first lone 01dde nse agilln tthe corruption r OmIssion of dcta ofs Far fro m beIng the mindless ac ti VIty that it mig ht flrs t appear, !;e tlln g all the requ Irement' down In complete detaIl Inv'Jlves the d ifficu lt tasks 01 orga ni zo ng people and the " th u"ht proce" . To understand this challcng~ , Imag Ine the task of or)(anlz lng a 20-volume req uo re me nt< document (' t , " c1lectlve nllp jinc"" bbc en uk/ l /hJ", ,"cd"5 14 76~ tm , hp j/ltp hq no .. 80y/ puiJ/paoircpIlrt
279

280

CHAPTER 12

ANALYliNG DETAILED REQUIREMENTS

that a N A englOeer, for example, would know cxa tly where to add o r look (or a
12.2 ORGANIZING DETAILED REQUIREMENTS Requirements c hange constantly, and so written reqUIrements should be well ·orga nized a nd easy to update To apprec Iate th e value of carefu ll y o rga nizi ng de taIled req uire me nts, consi de r the following rather random attempt at wrillng detaIled reqUire ments for the Encounter game. No te that these requireme nts are still raw and arc no t in pected . Every c haracte r in the Encounter video game shall have a name. Every game c haracter has the same set of qualities, each with a floating po int value . Encounter shall take less than a seco nd to ~omput e the results of an engagement. Each area has a speCIfic set of "qualities nceded." For example, combat areas require strength and lamina ; li ving rooms require sensi tivity and intellect.

Whe n two Encounter game characters are in the same area at the same time they may either choose or be obliged by the game to e ngage each other. Every game ch arac te r shall have an amount of life points. The sum of the values of qualities of a game character relevant to the area in question shall be referred to as the character's area value. In an engagement, the sys tem compares the area values of the characters

and computes the result of the e ngagement . The name of any c haracte r in Encounter shall have no more than 15 letters. A It grows, an uno rganized list hke the o ne above quickly becomes unmanageable. • Its very size makes It hard to understand as a unit even before it grows into the hundreds, if not thousands. • The reqUIrementS arc of mixed types, performance requirements must be dealt with differently from functiona l requireme nts , (or example.

• Some reqUIrements naturally belong with related o nes.

• It is d ifficult to loca te a speCific reqUIrement. Functional detailed requirements can be organized acconding to several claSSifications, including by feature , use case, CUI , state, and class. We describe each method in more detail in subseque nt sections. Tools for managing requirements can help a great deal. Nevertheless, the decision as to how to organize detailed requirements 111 the first place is important because teams reler to them continually if the document is well done. The IEEE standard 830-1998 provides document templates for several ways to classify the detailed requirements. Figure 12.2 shows the conventional and the object,oriented classification templates of the IEEE 830. 1998 standard. The object-oriented claSSIfication uses classes/objects as a me thod of organizing the functional requirements. The SRS is often tailored to corporate or team needs by adding or modifying sections as appropriate. For example, the 00 organization lacks a section equivalent to 3.4 in the non-OO organization 10gical database requirements." The Encounter case study uses a modi Red form of the IEEE 00

ORGANIZING DETAILED REQUIREMEIfTS 3. Specific ""quirements (non-OO) 3 . I External interfaces 3.2 Functional ...,quirements 3.3 Performance ""quirements 3.4 Logical database requirements 35 Design constraints 3.5 . I Standards compliance 3.6 Software system attributes 3.6. I Reliability 3.6.2 Availability 3.6.3 Security 3.6.4 Maintainability 3.6.5 Portability 3.7 Organizing specific req u irements 3.7. I System mode - or 3.7.2 User class - or 3.7.3 Objects (sec right ) - or 3.7.4 Feature - or 3.7.5 Stimulus - or 3.7.6 Response - or 3.7.7 Functional hierarchy - or 3.8 Additional comments

3. Specific requirements (00) 3. 1 External interface requirements 3. 1. 1 User Interfaces 3. 1 2 Hardware interfaces 3. 1.3 Software Interfaces 3. 1.4 Communtcations interface 3.2 ClasseS/Objects 3.2. I Class/Object I 3.2. 1. 1 Attributes 3.2. 1.2 functional reQutrcmen ts 3.2. 13 Events . •

••

3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3 6 Other requirements

Figure 12.2 IEEE 830-1998-specific requ irements, 00 and non-OO organizations SOUtce: IEEE Std 830-1998.

style and includes a sectIon for usc cases. Fi gure 12 .3 maps the detatled requirements section o( Sect Ion 3 to the requirtments ca tegory it describes. It may be advisable to o rga nize detailed reqUIrements int o a comb",.lio" of lasslficatlons For example, a feature· based organization could be used within the co"figllring, txcculmg , and backing liP tates of an accou ntIn g application . The requirements for a factory automation system cou ld be orga ntzed at the h, gh. t levd by function (i ntake, part manufacturing, and assembly), they co uld then be o rga ni zed by clas withIn eac h. This means the metho d o( organizing detailed requirements is somellmes related to the probable architecture or implementation of the appitcation For example, if the deSIgn is :0 be object-onented, detailed requirements organtzed by use case or class should be considered because they faclittatt traceabtlity. If the application lends itself to an obvious functional breakdown, then o rga ni ztng the requirement by (.>lUre hIerarchy may be appropriate.

12,2,1 Organizing Detailed Requjrements by Feature The oldest manner of orga nt ZII11( detaIled reQ Ulrement< IS by feature . This amount to prOVIding a SImple Itst of functional,ty such a< the fo ll OW Ing , f'Or th e Encounter VIdeo game Many (eatures are defined bv J IImulus . and-response pa", as for requirement 12 7.

211

282

O1APTER 12

ANALYZING DETAILED REQUIREMENTS

3. Specillc requlremenlS 3.1. EXie mal inlerlaee - - - - - - - Inlerface requ lrome nts requ irements 3.1.1. User inlerlaces 3.1.2. Hardwa re inlerfaces 3.1.4. Communications interlaces 3.2. ClassesiObjecls

Funct10nal requirements

-see section tbd3.3. 3.4.

3.5. 3.6.

Performance requirements ... Oesign constraints ~ Othe r n? nrUnclionai Sofiware syslem altribules ~l requirements Other requirements

Figure 12.3 IEEE 830· 1998-specific requ irements, 00 style interpreted as functional and nonfunctional detailed requirements SOUrce. IEEE Std 8JO. 199S .

125 . The re shall be a SCI of hy perlinked locat io ns at eve ry exi t to every area. 126. The fo reig n c harac te r shall move fro m area to adjacent area at ra nd o m times, with an average of three seconds 127. Whe n the use r clicks o n th e "Set qual ities" butto n, the window in fig ure xx appears on Ihe mo nitOr. Arra ngi ng req uire me n ts by fea ture has Ihe advanta ge o f simpli ciry but the di sadvantage of in· accessibi lity ; th is is because it all ows jumpin g fro m a feature in o ne pan o f th e applicat io n to a feature In a com pletely d iffe re nt pa rt. For example , if we wa nted to c han ge the manne r in w hich the fo rei g n character moves about, we wo uld have to de termin e tha t th e relevant requirement is number 12 6. H ow would we kn ow

w h at o t her req uire me nts are affec te d] Searc h tOo ls can help a g reat deal. Ano th er disadvantag e is the lack of traceabi lity. For examp le , what pa rt (s) o f th e cod e does requirem e nt 12 5 map ta l One wa y ro im pose o rd er o n fun c tio nal feature lisls is to arran ge them in a fun c tio n hitrnrcby (i .e., by dec o mposing the ap plicati o n into a set of h ig h . level fun c tio ns, and th e n Ihese into subfunc ti o ns, etc.). For exa m ple, the requ ireme nts fo r a ho me b ud get program could be d ecomposed into ( I) dJeckill9 functi o ns, (2) sa viN9s func ti o ns, and (3) i"" " 'm,,,t fu nc ti o ns. The required ChlCkill9 fu nc tio nality co uld be furth er decomposed into checkbook fu nctions, reconcilwtio" . and rcporlj"g, and so on.

12,2.2 Organizing Detailed Requirements by Use Case US( cam (Intro duced in C ha pte r I I) ex ploi t th e o bservati o n that many requ irem e nts occur naturally in o perati o nal seq ue nces. Fo r exa mple , an ind ividual requ ireme nt suc h as "a video sto re applicat io n shall allow ente nn g th e title of a new vid eo" ty picall y takes place as pan of a seqll,"cr o f transactio ns . A usc case diagram sh OWing a collectio n of usc cases fo r a vi deo store applicat io n is illus trated in Figu re 12.4 . The auth o rs ad vocate provid ing use cases fo r hi g h · level req uire ments . O ne may have the o ption of usi ng this same organi zing p rin ciple fo r d eta iled requ ire men ts. In this case we would gTOUp the detailed requireme n ts acco rd ing to eac h use case, Aes hin g out the ste ps o f each use c ase in complete detai l. The fo llo w ing is an exa mple of how o ne suc h groupin g o f req uire me nts wo uld appea r in the SRS. 3.7. I C hecking in

DVDs

Th is is a deta iled versio n o f sec tio n xx. (N o te I,
ORGANIZING DETAILED REQUIREMENTS

9

/' Clerls

Activate

2. System displays main menu

-

Check in DVD

1. User swipes bar code

2. Sysr... II displays due dala 3 . .,.

Check out DVD )

Y -( Stock DVD

Buyer

1. User hits arry key

}---

( ........ .)

,.. . . . 2. 1. User obtains

"

·slocl( screen 2. User enters name of DVD 3 . . ..

IL

Figure 12.4 Organizing requirements by use case for the video store example

The applicatio n shall provide the following capabil ity to interact wIth store clerks. These requirements assume that the main scree n is on the mo nitor (Note 2) 3.7. 1.1 Step I , Chtck III button (Note 3)

The clerk shall be able to hit the Chrck III bulton , whereupon the (b,ck In screen WIll appear (described in section xx above). 3.7.1.2 Step 2, Filling in fields (Note 4) The clerk shall be able to fill in the following text fields In the (b, k In s rcen

•

3.7. 1.2. 1 Video name field

This field shall allow for 30 alphanumeric characters, including blanks. •

•

•

Note I , This paragraph corresponds to the Chrd:in9 in DIID usc case described in the hlgh. level requirements .

Note 2, This section introduces the usc case and states prrcondlrions. if any. A preco ndition I a fact assumed true at the inception of the usc case. Note 3, This corre ponds to the nrst step of the use case. Note 4, Since these are the detailed requirements, they must specify the requirements completel y. The details will not be speCified elsewhere. The Unified Software Development Process favors orga ni ZIng all requirements by u e ca e . Aglie methods de ·emphasize detailed requirements in favor o( workong code , but they emphaSIze organization of requirements by user tory.

12.2.3 Organizing Detailed Requirement by GUI ApplicatIons display CUI , and thes" are the means by whIch users think o( them, 0 It ca n be natural to prOVIde requaremcnts organIzed In thIS way . Using thI S style , rhe requaremcnt (or the Encountt"r video g"me would be ,omethonll like the followIOIl ·

33

284

CHAPTfR 12

ANALVZlNG DETAILED REQUIREMENTS

I Are. CUI , Arca C Uls shall have Ihe appe.rance shown in figure xx. When the user clicks o n the ' Set qual,ties" button , the wi ndow in figure xx appears o n the monitor. When the user clicks o n ... . 2. Dungeon C UI . . . 3. Living Room C UI 4.

•

•

•

et Qua lity C UI ....

5 Vicw Q ualities Window

• • •

The advdntagc of organizi ng requirements by CUI is its direct connectio n with the usc of the application . Anot her advantage is traceability, we have a good chance of tracking the requirements associ ated with a given CU I class. One disadvantage of rhis means of o rganizatio n is that it ofren fail s to cover all of the requirements. ln the Encounter example, we need to describe the requirements for the interaction of the player's character and the foreign character. No C UI paragraph is a natural container for this. Perhaps the closest is "Area CUls: However, this is not a uitable place for specifyi ng the manner in which characters exchange points. Another disadvantage IS rhat given functionality is often associated with several CUls. As an example , Figure 12 .5 illustrates an organization of the video store requirements by CUI. Specificatio n of individual CUls is discussed further iA Section 12.3.

3.1 Sslecting Procedures

S'ock oVo

The GUI for selecting procedures shall be as shown in Agure 1. 1\ shall be possible to select from the following procedures by clicking on a radio button. followed by the "go· button .... Select Proc edure Slock OW Af95 '" CUSIOmef'

Cte " ous DVD Choc:II. In OVD

@ @ @ @

I Nl.nIber 01

Figure 2

roc: .,

1 :1

'--' I ~~-

3.3 Checking out DYDs Figure 1

9

The GUI for checking oUl DVDs shall be as shown in Figure 3. 1\ shall be possible to ... Checl< DIJ. DVo

avo """'" Figure 3

1 i ........ _

,

-- .'-

,

3.2 Stocking DVDs The GUI for stocking DVDs shall be as shown in Figure 2. 1\ shall !>e possible to enter a DVD Into the systelll using the GUlln figure ... The application shall save the title expressed In up to 30 aJphanumeric characters and the number of copies. The laner shall range between 1 and 100. inclusive. •• •

3.4 Registering Customers

... -. Regtster Customer Fw.tnl me

1

I Figure 4

Figure 12.5 organizing requirements by GUf, for the video store example

ORGANIZING DETAILED REQUIREMENTS

12.2.4 Organizing Detailed Requirements by State This styl.e consists o f collec ting In o ne place the deta iled require ments that apply to each state. For example. the reqUIrem e nts fo r an appl icatio n that control a c hemical process might be best classified by the states in whIch the process c an Rnd it e lf (sla rlin1 up, " aclin9 . coo/in9. etc.). With in each state classiflcation the """IS that affee.t the applicatio n while in that state are listed. Classificatio n by state c an be approp~ate when the I"'C'qulrements fo r each state arc qu itC' di tinc t. For example , an accounting system may be required to behave

entirely difkre ntl y de pe nding o n whe ther it is in the confi9 urin9 , ex,eu Iln9 , o r btlckin9 up state. Although the Encounter case study requ ire me nts could be o rgan ized by state , we decided that there are more advantages to organtzlng them by class, which we describe next.

12.2.5 Organizing Requirements by Class In the object ·oriente d (o r "cia s') style lo r orga nizi ng requirements, a ca tego rizatio n is fi rs t perlomled equivalent to selec ting clas os; then the individual requirem e nts arc placed into the resulting classes. C lasses used to categorize th e requirements arc kn own as domain cl asses. D omain cl asses represent real· wo rld objects

or concepts in the applica tio n . Fo r exampl e, a banki ng applicatio n would have do ma in classes such as bank mslomt!', cbrckin1 accounl, and savings balm",. A commo n first Step in ide nti fyi ng doma in classes is to ga ther the nouns or th~ir equivalent used in the high · level requirements W e then make ea h fu nctional detailed requirement correspond to a functi on in the target language. Th is promotes one-la-one traceability from

detailed requirements to metho ds. Agile meth ods use a si mtlar approach in that detai led requireme nts are organized by tests 01 classes. One disadvantage o f organi zi ng requ irements by classes IS the risk that we later c hange the cl asses, thereby breaking the correspo nde nce between require ment and design. ThIs is d IScussed by Jo rdan, Smila n, and Wilkinson in [2]. In fa ct, some develo pers use classes lo r o rga nizing the require me nts but do not seriously aim to usc these classes fo r the desig n. In this case, traceability is compromi sed , but there IS Ie s pressure to identify lasting classes ve ry earl y in the process. Ano ther disadva ntage of th is classincation is that it requ ires us to select classes very earl y in the develo pme nt cycle , and man y argue that we a re effectively perlorm ing design in doin g so. Let's look at the fll cou nl, r game case study as an exa mple. Picking classes such as Play,rebamelt! and Arm at re quire ments time is harmless since the Implem enta tio n is very likel y to use these classes. On the other hand, it can be reasonabl y argued that having the ArmConn" 'lolI objects refere nce the Alta objects that they connec t i a design decisio n. The great advantage to o rganizing requirements by classes th at will be used in the desig n is that it promotes tight corres po nde nce be twee n req uireme nts, design, and Impleme ntatio n. This is a key be nefi t fo r using the 0 0 paradi gm in a ny case. In add iti o n, cla ses that correspo nd to real ·wo rld concepts are muc h more likely to be reu sed than those th at do no t. For many appl ica tI o ns, the benefi ts o f usi ng a cl ass·oriented classincation meth od o utweigh ItS drawbac ks in the authors' o pinions. A ty pIca l seque nce fo r obtai ning fu nc ti o nal de tail ed requ ire me nt UStO g the 00 style is a fo llo ws, I. List the concepts me nti o ned in the u e cases a nd othe r hi gh . level requireme nts (usuall y, man y of the

nouns). 2. TI,e resulting collect Io n 01 classes is tY PI call y incomple te . T ry to uncover re mai nIng "do mai n" cl asses. Th IS proce~s is ex pl ai ned below Inspect thl collecti o n o f classes. 3, For each o f the cl as es obtaIned , Wrtte down all o f the req uired fu nc tio nality of the app ltcation pnman ly penai nm g to tha t class, as shown In the Enco unter ase stud y This I do ne In the fo rm of at mbute. and fu nc tl o ns For exam pl e , "every c usto me r s hall have a namc" (an anrtbute ltsted under paragra ph Cllslo,"rrs )

285

286

CHAPTER 1i

ANAL YlING DElAILED REQUIREMENTS

1. Obtain domain classes and objec18 Irom use requirements diagram,

r

ca,., and high. level

,

2. Add additional 8I88ntlal domain Inspect the resulting c:ollec1lon 01 classes

3. For each class, speclly the required attributes specify the required lunctlonalily speclly how Its objects react to events dra« test plans lor each inspect the results 4, Inspecl against high-level requirements 5. Verily with customer where possible When complete:

16.Release I

Figure 12.6 Road map for detailed requirements using the 00 style

and "the appli catIon shaU be able to compute the tota l assets of each customer" (a function listed under ( 1I510rn,,, ) In the (req uireme nts) document that you arc writing, avoid usi ng the term "class." Use ord inary, no ntechni ca l English. Specify the events that the o bjects of the class arc requi red to handle. 4. Inspect the detailed requirements as the process progresses . 5. Idea lly, test plans for each detailed requireme nt should be devised at the same time, as explained below. 6 . Inspected the detailed requireme nts against the hi gh-level requireme nts. 7. Verify the detailed requ ire me nts with the custo mer. 8. Rel ease the requirements , or return to Step 1 ror more requirements.

Reca Jl that the primaJY audience for de tailed require me nts consists of developers. However, customers are vitaJly interested in the deta ils, too . Figure 12.6 summari zes these steps. It is a commo n error when classifying requirements by class to use the language of uesign instead of plain English. For example, the foJlowing language is acceptable .

It shall be possible to o btai n the number of days delinque nt o n any account. The following is 1101 acceptable in a requirements document.

•

g"D,/illqu'IJ IDays() returns the numbe r of days delinquent On the accou nt. In other words, object-orientat ion is u cd here o nl y as an or8a n izin~ pnnciple for the req uirements. Th< use o f 00 for design and implementation is I>crfonned later.

ORGANIZING DETAILEO REQUIREMENTS

Player

(') flSl

"vel)'

le.son'Ne

IExit II Combat I you candidal" closs can think of IEncounter I (this 11s1), then IMap II Result I down (2) drastically cut to a lew IRoolI' I ~ essential classes. IScore I IConnection Hype~ink I

IForeign Character I IGame Character I IPlayer Window I IExit Choice Window I IQuality I IGame I IOoor I

Figure 12.7 candidate doma in classes for the Encounter video game We ide ntify the classifying class~s carefull y and co nservatively, identi fyi ng th e d o ma in classes of th e application . As an additional example, the d o ma,n of an applicatio n simulating a bank mig ht conta in classes Bank Cuslom" (the corresponding class name in Java o r C • • can have no blanks, of co urse) and Tell" but no t Filr or DatabQ st-not even Cllstomrr or Tm"5action . Th e latt er arc not specia l to the applicat ion in question . Our goal is to identify a minimum but suffici ent set of do ma in classes that include all of the speCific requirements. Each CUI usuall y results in a d o main class . As another example of d o main class selectio n, consider an appl icatio n th at manages visi ts to a Web site. Some candidate domain classes are Sitt Visitor, Sile Visit, and Silt Missiou. Requirements pertaining to the visitor (e .g., data about visitors, and functio nal ity such as displaying vis itor profi les ) wou ld be collected wit h the Sile Visilor classification . If the application fCquires us to track the reaso ns fo r each visi t, thcn a d o mo," class Sile Mission would be appropriate . The corresponding requ ireme nts would be coll ected w,th in Sile Miss,on. Fo r example , the requirement on the applicatio n co uld be that visitors submit a form stating th e lf goals in visil1 ng the site. After identifying classes from the use cases and other hi g h · leve l requiremen ts, an effective way to complete the identification of key do main classes is to use a '·Iist and cu t" process. Th,s co nsist' of (Step I ) listing every reasonable candidate class you can think of, and th e n (Step 2) agg ressivcll' paring down th e list to a few esse ntial classes. We elaborate o n th ese Sleps nex t. (Step I) Figure 12.7 s hows candidate classes for the Encounter game elected from the te.xt of the h ig h · level requirements. The UniRed Modeling Language (UML) no tat io n for a clas is a recta ng le containing the class name. (Step 2) We now Riter th e classes identi fied. Note firs t that il is fa r easier to add a clas later than to remove one that has become embedded in the design and implementJtio n, so that if there is d ou bt about the usefulness of a candidate clas we eliminate it. The rationale used fo r the fin al se!cc t, o n of do ma in cI.ssl"S fo r the case study is given ne xt.

En,oun'", Change to EncouHlcrGnm, to make its purpose clearer (we may also need th e plain "encounte r" conccpl as we ll ).

Game: Not a domam class-toO ge nera l (,YO mal' rc,ntro duce this later when scek'"8 useful generalization ).

Ga .. , Ch.r.cler: Too ge neral to be in the do ma in (we may re '"tro duce this later when seek,ng useful ge neralizations).

217

288

CHAPTER 12 ANAL YlING DETAILED REQUIREMENTS

Pia cr: Plny,r

Foreign

barnelrr

IS

a preferable name (mo re speciAc to the domain ).

I,.raner: OK (foreig n char.c ters aC I

In

w.ys tha I arc differenl from player c haracters).

Eneoullirr O,atan,,: OK (ge nera lization of PlayerCharacl" , Fo"i9n Charnet", CIC., of the app lic.tion )

IS

still wllhin the domain

Qua/lly: O mi t-try to h.ndle as si mple attribute of Enco unt" Characl" . Room : O m il- not sure if we need th is; already ha ve A"a . 000, : Omi t- no t sure we'll need it .

Exit: NOl sure if we need Ihis; leads

lO

neighbo rin g area. T ry as si mple attribute of A"a

o mit for now

Rult: Omit-not sure we'll nee d it. Arta : O K (The .stulc reader will note th.t this decisio n is defective .) EligagrmMl1. OK Passageway. We do need to connect are.s, bUI we do not yet know what form these connections will rake . U sc EtiCo lmtrrArcnCOntH'ction instead.

Resuit : Omi t-iI's vague.

Combal: O mit-no t sure we'll nee d it- already h.ve Ellgag""",1.

5 Ort: Omi l- try .s attribute of o ther classes. Playrr Quality Window : This is needed to express the Initi.lize use case. EXit Goier WilidolD: O mit- not needed

clic k o n exit hyperlinks.

Map : Omit-not requi red at this Slage (maybe in a future versio n). Engagrmtlll Display: OK-needed by usc case tho ugh will try to postpone by substituting a command line ir:tcrface .

The resulti ng classes arc shown in Figure 12.8. The figure includes the inheritance relationships present among these classes denoted with a tria ngle. UML no tation is covered in de tail in C hapte r 16.

EncounterCharaCler

En counterAreaConnection

If PlayerCharacte,

ConnectionHyperlink ForeignCharacter

(1) list every

reasonable

I Playe!OuaJltyWindow I

IEngagement I I EncountelGame I ~~~ I EngagementDisplay I ICey

Figure 12,8

IA ...."

., d r, ';>. &I'd code, b&ank:a I t! I'W\IIIfd

candidate class you can think 01 then (2) drastJ. cs1ly CUI do .. " 10 B few 8ss&ntiBl e'e ..ss (Ih/s /1st).

I

crasse-; for the Encounter video game, showing only Inheritance relationships

ORGANIZING DETAn ED REQUIREMENTS

Th~ classes in Figure 12.8 may relate in ways besides inh~ritance. For CJGImple, EHCo"nler Arc. ConHeclion will probably .ggreg~te two Arta objects. However, our concern here is only wilh the core application classo<, using them to organ .ze the requirements . Relat.onsh lps among classe, arc , hown where necessary. Using Inheritan e enables some degree of leverage. For example, after 51ating the requirement' for EHCO"nllr Characler we do not need to repeat these requirement' in describing Player Cbaraeler and Forti9n Characler. The Eneo"Hlrr QaracltT class is shown in italics in Figure 12.8 becau,e it i, abstract- thi, declare, that there will be no actual characters beside player·controlled and foreig n c haracters. The IEEE 830· 1998 SRS standard designates a place where the purpose of each class is stated, together with its key attributes and fu nctio ns. The stan dard ca lls for uSIng the decimal numbe ring system fro m each class (e .g ., 3.2.5) to eac h of its attribute requirements (e.g ., 3.2.5 . 1) and each of its function requirements (e.g ., 3.2.5.2). In stead, we will arrange classes alphabetically to make it easier to add and

~move classes. Such insertions are necessary as the applicatio n grows. It is important to number requirement.s, however, in order to be able to manage the m, so we do this within each class as show n in the case study. Sometimes, only "essential" requirements are numbered since onl y they mllSt be tTaced for now. A good reference for this style of organizing specific requirements is Jordan , Smilan, a nd Wilkinson [2]. T o assist in trac;ng detailed requirements it can he lp to give a name to each o ne, a in the case stud y. For example · 3.2.A. 7 Preferred qualities

[essential] Each area shall favor a set of qualities. Including "desirable" and "optio nal" detailed requireme nts is beneRcial for several reasons. First, the scope of the application can be co ntrolled by implementing the requ irements in a planned order. Second , ~tati ng future requirements provi des directi o n to designers, helping them to create designs that can accommodate fuiure features . One technique for indicating which requirements have actually been designed for and implemented is to start by including a disclai mer with each , as in the follow ing exa mple. When organizing deraile d requirements by class, .t's sometimes a c hall enging issue to decide under what class to state the requirement. Consider the following require me nt example, Every Encounter character shall have a name ... This requirement shou ld be classified with "Encounter C harac ters," We wi ll explain below the relarion of this with a CUI requireme nt. The following require me nt «quires more consi deration. Whenever the player's main cha rac ter en ters an area , rhat arca and all the characters in it shall be displayed o n the mo nitor, Class candidates to classify this function are Playrr haraelrr and Arro . TI,e requirement effectively calls for an event h an dl er A na tura It n'gger'lng c lass fo r handling the entry event would be lhe area e ntered . because . .It IS aware 0 f W' h Ie h c h aracters .'" h ab 1't I' t. The area entered could display itself and the c harac ters It contaons, the requirement stated above could rea o nabl y be classified under Arm . . 0 d ' to dcal with /I.diu;d""/s. 099"9al;0Ils , and GUis ce ntered o.n a SIng le theme. For W eo ften lin It necessary example, for a video tore manageme nt application , we need to deal with the followon!! . \0

•

' d I V.' dual D VDs7 For exa mple, what are the l en~ th lim.tallons of lhel r Wh ilt are the reqUire d properr'1e~ 0 f on titlc\7

2"

290

CHAPIER 12 ANALYllNG DETAILED REQUIREMENTS

• What are the required propertie of the co llecti o n of DVDs? For example, what is the requirement for stocking new CUls? • What are the specincations of a CUI that displays info nnauon about DVDs? For example, what are the limitations on the text shown? (CUI speCifica tions often change Frequently.) TI,inking ahead, we recognize that the e will be separate classes when we come to design time, so we organize the requirements document paragraphs to anticipate this. It is u ually best to begin with lhe paragraph that describe the requirements o n the ",JiviJuals: in thi case, DVD . This speCifies the required degree of detail that the application is required to store . It is referenced by other paragraphs. 3.2.DV DVDs • • •

3.2.DV. t Attributes of DVDs 3.2.DV. I.X Director's Name The application shall retain the name of the director of each DVD . This shall consist of the director's la t name, in a fonn of between I and 30 characters, which can consist of a·z, A·Z, and a hyphen . In the case of multiple directors, only the first alphabetically shall be retained. •

•

•

3.2.DC DVD CUI The CUI displaying a DVD shall have the appearance of figure xx. •

•

•

3.2.DC. 1 Attributes of DVDs •

•

•

3.2.DC. I.X Director's Name Appearance The director's name shall be dispiayed in the location shown in figure xx , in accordance with requirement 3.2.DV. I.X, but limited to the first 20 characters. . .. •

•

3.2.DC.3 Events Pertaining to the DVD CUI •

•

•

3.2.DC.3.X OK Button When the "OK" button is pressed •

•

•

•

•

•

3.2.DI DVD Inventory • • •

3.2.01.2 Functionality of DVD Inventory • •

•

3.2.D1.2.x Stocking a DVD The application shall allow new DVDs to be added to [he inventory, up to a maximum of one million . ... • •

•

USER INTERFACES: DETAILED REQUIREMENTS

rgaOlzmg

pnncipl.

Advontage<

))1Sadva11lage<

By Feature

©

® Docs

By U se Case

© ©

Mops well to why we ore bUIlding the appl,ca ti on Easy to understand Easy to understand

By CUI

©

Easy to understand

By State

© ©

Easy to understand Design th Inkin g begins early

By Class

not map well to 00 code

® Hard to locate random requirement

® U c cases may overlap ® Hard to trace to deSIgn and code ® Coverage IS hmited ® Not every function appears in a CUI ® Functionaliry of C Uls overlap ® Hard to trace to design and code ® ClaSSification can be unclear to the cus tomer

® H ard to allocate requirements to state ® C1assi 1catlon can be unclear to the

© Easy to trace to code © Easy to locate random

cu)tomcr

requirement

©

Design thinking begins early

Figure 12.9 ways to organize detailed requirements advantages and disadvantages

12.2.6 Classification Methods: Advantages and Disadvantages Figure 12.9 ummanzes the d iffe rent way to organize fu nc tio nal detailed requirements that we discussed the previous: sections, along with th eir relative advflntagcs and disadvantages

12.3 USER INTERFACES: DETAILED REQUIREMENTS Recall the follOWing ste p in specifyi ng user IOterfaces. Step 1 Kn ow your u er Step 2, Understa nd th e bu
10

question

Step 3, Apply pnnClple of good scrcen dC<1gn Step 4 Select the appropnate kInd of windows Step 5. Develop system menus Step 6

elect th e appropriate devlce ·b.,cd contr I

Slep 7: 0100se the appropriate s rcen -ba<ed control, Step 8

rganize and layout w lndow<

Sl<:p 9

hoO\e appropnate colors

Step 10

rcate meanIngful Icons

Step 11 J) rovlde c (fclive me>sage, fe" dl" , k, alld

"llId"n~c

D

In

291

292

CHAPTER 12 ANALYZING DETAILED REQUIREMENTS

• En~ure consl ten cy amo ng the Screen. of d es l ~ n a tcd "PPloc.t lons, and among
• Provide captions Figure 12.10 Principles of good SCfeen deSign Source GaJItz. W • • :"e E.ssenbal GOlde to user Interlace DeslgJ1

An IntroouctlOO 10 GUt Prindp~ and TechniQues," JOhn Wiley ~

Sons, 1996

Steps I and 2 were descnbed in the previous C ha pter I I since they apply primarily to hi g h ·level requ irements We now describe the remai nin g steps fo r specifyi ng detailed user interlace requirements, whIch are esse ntiall y a detailed descriptIOn of each C UI screen.

step 3: Apply the principles of good screen design Figure 12 . I 0 li sts some majo r clements of good scree n design. The figure includes several lac tors that often app ly to mak In g an interface pleasing Alth o ug h these serve o nl y to introduce the subject of visual effects, th ey arc nevertheless usa ble by the average software e ngi nee r. As an example, we app ly some of th ese principles to an example o f a sClcen used to input information about customers and the ir accounts. An ini tial attempt at a C Ul,s show n in Figure 12 . 1 I. To improve the interface, we start at the to p left . placing the most impo rtant clements firs t, and grouping like elements. Figure 12. 12 illustrates Type:

checking 0

Branch:

Main SI. 0

Privileges

First name Middle name Last name Street City State/county

Elm SI. 0

newsletter 0

I I I I I I

mml o

savings 0

CO o

High SI. 0

discounts 0 quick loans 0

I I I I I I ,

.

4 _ ...........

•

-'~

-

~

•.

..

~

• ..

Figure 12.11 Applying principles of good screen deslgr>-"Before" scuu: GaDa. W • ''lne ESS 'ltial G'oOt to user Interface ~ All introduction to GVi PPrIInIt<~' ' l anct Ted~." JOI't, 'Mtey 3; SOns.. 1996

USER INTERFACES: DETAILED REQUIREMENTS

,--, -.

New Customers

-

Branch

•

. -. - ' . •

r Account type

0 Main St.

r Privileges

0 checking 0 savIngs

0 Elm 5 1.

0 newslener 0 discounts

0 mmf

0 High 51.

o

0 quick loans

CD

Figure 12.12 Applying prinCiples of good screen design-" After"

the improvement that the applicarion or th ese p n nciples can bring. Figu re 12 13 shows where so me of rhe principles of good screen des ig n were applied.

Step 4: Select the appropriate kind of windows Each user interface purpose can be served most effectively by o ne ortwo panicular types of windows Figures 12. 14 and 12. I Slisr five common CU I purposes and a window type thai sarisfies each olthem The Window types employ Windows™ terminology, but are typical.

-----·~w..Qustomers ""' I

I

M ~hg,a li~~ ~/(l.rl1~!1t~ Last

p '- ---

I

o Elm SI. o High SI.

-:r ~ City I r~ StatQ/co

o (. '- SvmmQUJ! o I .. , . .. o CD

GfOUQ

J/kBRIBroeOIS

--4

SI,eet

Branch - Use capr/ons Account type o checking o Main 51.

Fl&ure 12.13

EXQBCted position

----- ~dOre~ -

- Name

First

dl!~~a

ProQOoioo

How principles of good screen design were applied

~~e.J<9~tmJq

::::J

I

I •

Border around like elemenrs r Privileges

o newsletter

o diso 6il1~

o

quick loans

293

294

CHAPTER 12

ANALYZING DETAILED REQUIREMENTS

I . Purpose: display properties of an enllly - property window

Propertie s u f autumobile 18g

Brand Model ~ID=----_ _ 893·8913·789014

2. Purpose: obtain additional information so as 10 carry out a particular task or command •. dialog window Help Word

This screen 0

All screens 0

Figure 12.14 Types of windows, 1 of 2

Step 5: Develop system menus Some rules for the creation of main menus, provided by Calitz [ 3], arc shown in Figure 12. 16. Users require a stable, comprehensible anchor for applications, hence the need for a constant main menu The number of Item on thIS menu sho uld usua lly be between r,ve and nine, because most of us feel comfortable with chOICes of thi size. For example, the word proce sor with which this book is being typed ha nrne m.rn menu items F,lr, Edit , \I"",, III Strl , Fonnat , Tools , Tahir , Willdo"" and Hrlp . The number of items could have been far higher, Since there IS plenty of space for more . However, we would probably have to 3. Purpose: provide information - message window

ABC alerl message

Caution: "age" must be < 120

~

4. Purpose: present a set of controls - paleNe window

5. Purpose: amplify infonnation

- pop·up window

This Is • pop-up window, designed to

provide on·t/le-fty

am~ification

Figure 12.15 Types of windows, 2 of 2

• Provide a main

meflU

• Display all relevant alternative (only) • March the menu structure to the tructure of (he application's task • Mmimize the number of menu levels Figure 12.16 Developing system windows

USER INTERFACES: DETAILED REQUIREMENTS

continually search the l1sl for the option we require, and this outweighs the benefit of increasing the choICes. The main menu items arc determined by the bUSIness at hand-in this case the processi ng of texL Thus, for example, gTaphics command are placed o n a secondary menu.

Step 6: Select the appropriate device-based controls "Device· based contro ls· are the physical means by which users communicate their desires to the application. They include joysticks, trackballs, graphics tablets, touch screens, mice, microphones, and keyboards.

Step 7: Select the appropriate screen-based controls "Screen· based controls" are symbo ls that appear o n th e mOOIto r, by mea ns of which the user no tiRes the application of his or her input and intentions n1CSC include Icons , buttons. text boxes, select ions, and rad io buttons. The rule for arranging screen· based cont ro ls in a Window arc Virtuall y the same as those for screen design in general (see Figure 12 . 10. Their numbe r is, agai n, ryp lca ll y berween five and nine. Th is number can be increased, however, when a hierarchy is used . For example, In Figure 12. 13 th ere are rwc nry o ptions to select from , but the interface is manageable because th ese Iwen ty items arc orga ni zed 1010 SIX grou ps.

Step 8: Organize and layout windows The rules for layi ng out multiple windo ws are si mil ar 10 Ihose for ind iVidua l screm desig n (involvIOg symmetry, proportion, ctc.) as in Figure 12. 10, but Ihey IOvo lve arrangemen ts such as til ing and cascading. The latter terms 3re illustrated in Figure 12. 17.

Step 9: Choose appropriate colors When used with skill and taste, color ca n enhance displa ys. Colors do no t aUlo malicall y make a user inlcrface more uschll or more attractive, however, and they can ca ily worsen It. According to ren owned designer Paul

~C~a~s~c~agdrrm~guw~m~d~O~w~S! --------lcon

,-

Tiled

t - windows --I

First

I

Last

I

I

Account type ·

Radio __

checking

0 savings

button

o mml Button - - Acure 12,17 COmmon GUI terms rnc;u teproGuced WIth

pe4iiifS31()n It om

corel

r - -

I

Screen

- Name

Text bOX - - - .

~

I

New Customer

+\ CIInceII

I

-.:J

& I .....a
boc'

Privileges

o

newsletter

q. discounts

-

~AAIIY...

" IJ.QIr

C1J.~k

29S

296

CHAPTI:R 12 ANALYZING DETAILED REQUIREMENTS

r

Rand , ·co lor is comple. ity person, ,cd" 4) oftware e ng,nc"" who do not have a profe'slonal desIgner with whom to work .hould be very panng aod On<ervallve about the u c of co lor. Try black and white ~r
12.4 DETAILED SECURITY REQUIREMENTS \'qriting the detailed requirements for security measu res is a maftcr of being entirely speciRc about the n«ded secunty measures. Some of these are shown in Figures 12. 18 a nd 12. 19 When II comes to security logolls, for example, we may want to requITe that if there is no keystroke o n the application for ten minutes, it logs off auto matically. Audit tra,ls for security breaches arc important. Some of these requITements are easy enough to specify but difflcult to implement. For example, how would an application know that it has experienced a security breach)

12.5 ERROR CONDITIONS For each requirement, we ask what would happen if ,t were to take place under erroneous circ umstances. As an example, let's take a requirement example put forward by Myers [5]. as shown in Figure 12.20.

1. U ser id entification capabi lities • Rules on IDs, name clashes, restnctions, etc 2 . Person or entity au the ntication capabilities • Exact requirements permitting acces to resources

3. Security logoff • Measures to prevent unattended or unusual usage 4 . Aud it trails of security. related events • Type, outcome, state at the time , date and lime, Source

Figure 12.18 oetalled security requirements. I of 2

5. Password speciRcations • length , composition, allows characters, etc. 6 . Controls to en ur. data integrity 7 . Retrievable record of encryption methods 8. Information on security attributes of the system

Figure 12.19 oetalled security requirements. 2 of 2

,

-

/

TRACEABILITY OF DETAILED REQUIREMENTS

AjtnCclto" lballtlls w!xlbtr Ihr,. "","bm produCt all equilalerallriangle (all sides equal), an i,osceles I'ia ngle (exactly !wo sid~ equal), or a sca/en, lriangl, (all sides different),

fIIu1'e 12,20

Requirement example, without necessary erro,s

A junclion lI,al Idls wh,lI", a lriplel oj nu",bm prodllc" , 1. an ,qui/alera/lriangl, (whose ,id" are all 9rea ler Ihan zero and etlllOl). in which cast .1 oll lpul, 'f' al Ih, prompl, or

2, an isoscel" lIian9 /' (whoSt ,id" are grealer Ihall uro, exaclly Iwo oj which are eqllal, and Ihaljorm a lriangl,), in which cast il oUlpul, '/' al Ih, ,ysltm, or

3, a sealen, Iriangl, (whoSt ,id" are all grealer IIJan zero, which jorm a lri,,'g/r, m.d Ihal is n,ilh,ttquilaleral nort,o,etl,,). ill which caSt il ollipuis '5' al Ib, prompl. or 4. no Irian91" ill wbich caSt il oulpuls 'N' a l Ih, prompl. FIgure 12.21 A more complete version, accounting for errors

This requirements specification is not complete because it does not account' for error conditions. The version in Figure 12.21 is more complete . A lack of error conditions in requi rements specifications becomes

especially g laring when the function is tes ted, si nce the tester forces error co nd iti o ns and needs to know ,,,hat the required output is. Sound requirements analysis does not tum a blind eye to "illegal" input: it deals with th em directly. For example, it IS tempting to assume that a C UI for the triangle requirement d oes nOt perm it th e input of negative nUiTlbers, and so the function docs not have to deal with erroneous data . Such an assumption is unwise because it transfers the "legality" part of the triangle require ment to reqUirements o n code clients of ou r triangle htnction , This increas~ the dependence among parts of the applicatio n, whereas we always try to obta in independent parts. Although it i, good practice to trap invalid user input at the CU I leve l and to o blige the user to e nter o nl y legal va lues, this does not subsl'itute for good requirements and error recognitio n elsewhere . The auth ors recommend requiring the trapping of incorrect data at many , if no t all . possible points. Th is is equivale nt to a long-established engineering practice of practicin g redundancy to pro mo te safety,

12.6 TRACEABILITY OF DETAILED REQUIREMENTS Chapter 13 di scusse the qualities that we want requirements to possess , an d metrics fo r meas"ring them . We will call out o ne property he re because it is fundamental to how we think about req uirement<'

IraClabtlily . Imagone an application with 1,000 speC ific requirement , Without, clean tTa ce fro m each requirement through the deSIgn o f the app li cat.o n to th e actual code that Implement s it, it IS very dlmcult to e n ure that such an application remains In compliance wHh th e requirements , When th e reqUIrements change, wh ich i safe to assum e , this becomes eve n mo ,e dtfficult The capaci ty to map each detailed requirement to .tS rtl<:vam pan ts) of the design and implemen tat Io n is called Ira ea btli ty . We Rrst di cuss the tra eab.h ty of functional requirements, th en nonfu nc ti o nal req uire me nt<. One way to help a ompllSh traceabi lity IS to map ea~ h functIona l d e tailed req UIreme nt to a Specl function o f the target language Th .. t 'c hn.qu e is used III th e Encounter a e stud y. FIgure 12 22 .ho" '$ rart<

297

298

HAPTER 12 ANALYZING DETAILED R

QU IR~M ENTS

Design

:..----=--=----::---:0

Code Implementing MY-D-Aequireme:=n:::t Code Test plan

My-D-Aequirement

Test plan inspec1ion Test report

r,.:e~po~rt:,=i~~~~=~':":':===::....J

=

key Iraces •• 0 - ; delailed

Figure 12.22 A thorough trace of an invidivual detailed requ irement

of the project that we would like to keep linked to have comple te traceability. Achieving and maintaining this deg ree of tra ceabili ty durin g devel o pment is a major c hallenge . As an exa mpl e, co nsider the fo llo win g functional require ment for th e Encounler video game case srudy \'(Ihen a foreIgn ga me c haracter e nters an area co ntaining th e player's main c haracte r, or vIce versa, they engage each o ther. The m ea nin g of this stateme nt is clear. What re mains to be seen , however, is what part or parts of the desig n and code will be respo nsi ble for implementin g this requireme n t. Whe n usi ng thc 00 paradigm we can link this requi rement to a speCific function of a speCific class. The issue of w ha t class is responsible fo r a function is not trivial , and it ari ses repeatedl y when usin g the 00 ty le . For the above example, ArrD objects would be able to recognI ze that an engagement i to take p.1ace s ince the y would presumabl y be aware of th ei r inhabitants. In particular, th IS requireme nt wtll be traceable to peclhe event-handling code for th e Arra class. As the project proceeds, the requ irements d ocument hou ld be kept consistent with the d esig n and the implementation . When requirements are hard to trace through desig n and code , however, d evelopers tend to avoid updating the requirements d ocument when mak ing c han ges to the ource code becau. e of the extens,,'e effor! required . Ultimately , such a deteri o rati o n of documents result in escalatin g development and mainte nance expenses. ThIS pheno menon is illustrated by th e following example.

Dnxloptr Bill j, ask,d 10 make cbang" 10 1/" implemnllallon /.Jill find, il difficlIlt to COlln,, ' Ih, cod, b, j modifyin!J to 'he corrtspondiJlg pflrts oj tht rtqu;rrmtttis documtnt l cotlStqurnl/y. ht flllls to "pdale rlx

Devtloper CD n"," i, task,d 10 m"k,

"CU, modific,, 'ions. Sh,

dOCUmN1111110Pl

imp'''"'"1s 'I(", cod•. Irsl, il. "nd b,gi", Updali"!J lbe rt4uirtmrnls documrnl. Howrotr, rtltryOtlt Itlls htr "0110 botbtr, 1>0lnting oul IIl(lltht rrqUlrt'"rtt ts dOClfn't"rtt is out oj dal, in ,ever. I pltlCCl affd no Oil' lrusls il"ery milch They ber il makes "0 Sm,' 10 lake II" I,m, 10 ptrJ«1 her pm' w/"" /10 01/' will "tid Ih, Jocumenl ."y",ay So Carmnl mo"" Oil 10 do 011", programmill!J n,. '/I<",,,,,"nrs b(hocttl fht rt4U1rmttJIls JocufTItn' find the codt ('O" ';"U( 10 Wldttl

,,1/

TRACEABIUlY OF DETAILED REQUIREMENTS

Regu,,,,,,,ent 1783 178 4

Module 1

Module 2

Module 3

getimerestO showAccountO

computeSa lO showAddressO

showNameO showNameO

FIgure 12.23 Example of a requirements traceability matrix

When a requirements document as a whole is untrustworthy. even the most conscientious developer

balks at properly updating his or her particular part. On the other hand , when the documents are clearly crosS' referenced, and management makes documentation a job performance requirement, engineer< do keep them in very good professional shape. In other words, the system used to match detailed requirements with the designs, and code thaI imp lement them , must be very clear and co ncrete. When the code implementing a requirement needs to exist in several parts of the implementation,

tracing is achieved by means of a requirements lracmbi!ily ",alrix of which Figure 12.23 is an example. Here, requirement I 783 is implemented by the action of fun cti o ns 9rll"lm,10 in module I , compIII,Ba!O in module 2, and ,howNa"" O in module 3. A change in this requiremenl necessi tates a change on o ne or more of these functions. This must be carefull y managed because Ihese func tions may participate in satisfying other requirements (e .g .. ,bowNa",,() is used to implement requirement 1784 as well ). As a result, changes made to satisfy one ",quirement may compromise another. Since many· to· many relationships are difficult to manage , we try to make the mapping between requirem ent and function one-to-onc.

We want each detailed requirement to be traceable forward and backward . The preceding discussion concerns forward traceabiliry of functional requirements from detailed requirement to implementation. Backward traceability of a detailed requirement means that the requirement is a clear conseq uence 01 one or more high .level requ irements. For example, the detailed requirement Foreign characters should move fTO m area to area at intervals averaging 5 seconds can Ix: traced back to the fo ll o wing hi g h . level requirement, which was part 01 Section 2.0 in the SRS . The rest [of the c haracters), called "foreign " character<, arc to be under the application's control. This backward traceabiliry is a basis for the inspectio n o f detailed requirements. Compiete traceability is Obtaoned when each detailed requirement is Ionked to a spedRc ekment of design , and to a unit test, as suggested by F'gure 12.22 . lt indicates the advantage of a ti ght trace (correspondence) between each individual functional requ' reme nt, the part of the design Inte nded to handle the requ irement , and the pan of the code that implements it. These are coupled with the focused tcst lor the requtreme nt , ca ll ed a 1..,;llrsl. Unit tests are the subject of Chapter 26. The preceding discussion concerned functional req uireme nt , but how do we trace nonfun ctional requireme nts1 This ca n be dimcu ll because more than o ne pari 01 th e design .nd implementation may contribute to satisfyi ng a nonlun tiona I rcqutremcnl. For example, a req uireme nt that every En Olonter t n!!"gem"nt com plete In less than o ne second could involve ode in an Ellgagr",ml class, .neVor a Gill'" b.,mcl" class, . "eVor an A"a clas<. ur oblccti ve at requlremen ls tllne is 10 specify nonlun tlo nal require ments. clearly as possi ble . In o rd er to larify nonl"nctlor.. 1 requ ireme nt , we will al,o lo uch o n des,s n and tmplementafion issues.

299

300

CHAPTER 12

ANALYZING OEl AI LEO R(QUII1EMENTS

InspOCI

- - - - -••......1,mPlemenlatlon l

,,-/

t

,/

I I

,/

,/

I

,/

I

,/

Relevant

.,/

components

Implemented by whole application

tests ...

,/ ,/

,/ ,/

I I I I I I

Nonlunctional Requirement · - - - tested by - - - - • System Test Figure 12.24 Tracing and testing lunctional vs. nonfunctional requirements

O ne goa l of the design phase is to isolate each no nfunctio nal requirement

In

a se parate design clement

In the case of performance reqUirements , an iutempl IS made to isolate time -enrical processing units

Appropriate , inspectab le, nonfunctional comme nts accompany each function that is aHected by performance requirements. Preferably, these are quantitative, as in "must complete in less than one mollisecond In the worst case ." Simila rl y , in cases where storage constraints arc spec lfled , we identify functions that generate the most stora ge. Expenence shows that a relatively small percentage of function s in an application account for most of the processing, so searching for a few principal time ·consuming ones can be fruitful. Let's return to the "one· seco nd" performance requirement example for Encounter engagements mentioned above . At design and implementation time, we seek typica l rime-consuming components in the computation of engagements

These components include loops, graphics displays, and netwo rk communication . Loops and commUnication arc not involved in computing engagements, and a test is implemented to ensure that the graphics and CUls required for an engagement execute f.. st enough . Probably, the function that consumes most of the time is either the function to "e ngage a foreign character" of the E"9a9"""'1 class, or the function to dISplay engagement results. To validate nonfunctional requirements we therefore tic each ohhem to a test plan, preferably at the time of writing the requirement . Figure 12.24 illustrates the typical relationship of functional and nonfunctional requirements to implementation and testing, discussed above. It illustrates the fact that several elements may contribute to nonfunctional requirements, and that system or integration testing is typically required to validate nonfunctional requirements because verifying them (i.e ., prior to execution) can be dimcult.

12.7 USING DETAILED REQUIREMENTS TO MANAGE PROJECTS Detailed requirements can be considered the "currency" of 3 project because they track the amount that' been accomplished. For example, a project manager can track the project as in Table 12 1 Recall that It's import.nt for developers to qUickly Rnd rclevant requirements sections to enable them to easily keep a requircll1.-nts document up-to-date. In the IEEE requirements format, functional requirements arc III ection 2. If we ,,'ere to number the paragraphs 3.2. 1, 3.2.2, ... , It would be time-consuming to locate the paragraph pertaonlfl/.! to a CU51.",,, class, for example. For this reason , the authors usc an alphanumeric labcll n8 uch 3 2. U for Customers, 3.2.DV for DVD<, ct .

PRIORfTlZJNG REQUIREMENTS

301

Table 12.1 Example of a table that facilitates the tracing of a rCQulrement with video

12.8 PRIORITIZING REQUIREMENTS It is usuall y diffic ult- if not impossible-to imp le ment oil desired fun c tio nah ty of an appiocat lo n o n sc hedule and within budge t. As discussed in C hapte r 8 , one may trade o ff copabilily , schedll le , qual.ty level , a nd COS I. Thus, the schedule , budget , and quality leve l can no t be chan ged, the o nl y alternative is to vary ca pabd ity-th at I to reduce the:: requirements that are implemented . Thi s reduct ion prace One techniqu e

IS

S IS

.r ,

perfo rm ed in a planned manner.

to prioritize the specific requirem ents. Rank ing all requirements is usually a waste of time

Instead, many organizatio ns classify requirements in to three (sometime fo ur) catego nes. \'I/e wi ll ca ll th em -essential ," udesirable," and "optio nal." The usc of three categories

IS

an applicati on of triage des nbed In

Chapter 5. We fi rst implement all of the esse ntial requirements. The de irable and o pllo nal req uirem en ts indicate the direction in which the app licatio n is headed and thus inAuence th e des.g n F.gure 1225 gives an example of req uirements prioritization .

Some specul ate that as muc h as 80 percent of the real benents of man y appiocatio ns accrue fro m as fe w as 20 percent of the requireme nts. Thus, if prioritization is perfo rmed well (e.g., calhng ro ughl y 20 percent-no mo re- "essential"), o ne can possibly achieve most of an appl.catio n's be ne fit with o nl y a frac tio n of the wo rk. Th is is a useful point to keep in mind if the project begins to run o ut o f time. The preliminary draft of a n SRS sho w n in Figure 12.26 co nrains so me pri o rnized deta.led requiremen ts fo r the first release of Encounter. They are provided here, "warts" and all , to g .ve the reader a feel fo r i<sues that mu t be dealt with. Some of the "desirables" wi ll become "esse nt ials" in future releases. The requirements are in dr.l ft form and are clearly in need of reorg anization. They arc improved upon later In this chapter and in the ca e Stud y The prioritizallon of requirements usually re lat es to the itCr.llio n that wi ll .mpl ement them Fo r ",
[essentia l] Every gnme cho,"el" ',as II" sam' " , of qual.,irs . [deSirable] Each ar(Q hns 0 5<1 of preferred qllal"irs [optional ] Th, play,,'s characler sholl o!l' w.lh tv'ry nlCou"ler. Th((lge rale call bt " , 01 5
FIgure 12.25 Exa mple of prioritization of detailed requirements

302

CHAPTER 12 ANALYZING DETAILED REQUIREMENTS

PREUt>.IINARY I RAFr I FnUlU I11c r de laried rcqulI'c ,n e nt' (n,e , e ~re no t e l (lrHJ nlzed , , ce th e ca e , wci y (IIr an lIl1proved form ,) (no t rn'pcucd ll c, se nl ml l Every ga me c h.l rac te r In th c Encounler video I!amc
[ I10 t "'
IS

o nne ted to ol her areas by eXIts

(no t In< pecred )( e se nt ia l] Whenever ~n EI1 o unter ga me c haracte r e nle " an arca cont.,nrng anot her game c ha racter and o ne of them is pla yer- o nlro ll ed, th e c hara te" may c lthe r c hoo
value 01 the player's stamllla , Assumin g p, + p, > f, + f" we wou ld ha ve p: = p, 1/2, Ia' = f/ 2 where x' de no tes the value of x after th e transaction ,

+ f/ 2, p; =

p.

+ fJ2, f:

=

[ no t inspected][optiona l] Encountershall take less than a second ro compute the resuits of an engagement. [ not inspected ][ o pti o nal ] The player's c haracter shall age with every e ngagement. The age rate can be sel at e rup rim e , Its default is one year per engagement. [ no t II1spected](o ptio nal ] Playe r-controlled c haracte rs lose o r gai n th e values of their c ha racters at the end o f every engagement at the rate 01 +2% when und e r 30 and - 2% when ove r 30_ Figure 12,26 Preliminary SRS fragment showing prioritization and status of deta iled requirements

ro compute th e resul ts o f an engagement" in rhe second iteration , it could appear with h ig her priority in a subsequent iterati on. Th e requirements for an iteration arc maintained in an identi fi able manner. TI'1 helps In unders tandin g subsequent requirements.

12_9 ASSOCIATING REQUIREMENTS WITH TESTS As each de tailed requirement is written , tesrs for the rcq urrement 'ClJy each detailed requirement by mean of a test

AGILE METHODS FOR DElAll ED REQUIReMENTS

T est input for Requir<:ment NNN

Harry

X

Ex pected o utput

H arry X

" " (bl ank)

,. (bl ank)

1234567890 12345 1234567890 123456

1234567890 12 345 1234567890 12345 . ...

. .

'

"

Figure 12.27 Example of association between detailed requirements and their tests

To rake an e xam pi c, o ne of Our req uire ments is as follows, Requ irem e nt N N N . Every ga mc c haracter in the Encounte r video game shall have a unique name containin g be tween I and 15 c haracters. Requirements of th e attnbute type like th is rea ll y specify get- and set · fu nctions, so that Figure 12 27 constitu tes the begi nn ings of a test plan fo r th is requirement Part VII covers these teSts In detail.

12.10 AGILE METHODS FOR DETAILED REQUIREMENTS • In an agile project, th e de ta il ed requ ire me nts arc u uall y expressed In terms of in ·code comments and '"11t tests rat her than be ing writt c n ex pl ici tl y in a se parate docume nt. For examp le , conside r a traditiona l requ irem e nt such as th e fo llOW ing . Customers sh all be able to e nte r th e name of a D VD in th e text box, up 10 20 alphanumeric characters. The appl icatio n shall check th is, wll h punctua lio n marks replaced by blanks, Wllh the DVD inventory , a nd d isplay accordin gly "Sorry , we don't stock thIS DVD" or "Added to your Ii t." Th is is replaced with o nc o r mo rc lests as show n in lisling I , aug mented by code comments and eqUivalent data e ntry in the correspo ndi ng CUI. Assume that the se tu p code in the unit test contains the followIOg

1: Example of JUnit testing. typically used in agile methods

DVDSearch dVD Se a rch = n ew DVDSe a rch() ; public void t est Lookup ( ) {

/1 "Gone Wi th Th e Wi nd ' , should be present dVDS e arc h . d oSearch ( " Gone With Th e Win d " ) ; a sse r t Eq uals ( dVDSear ch , searchResu 1t , true) ; a sse r tE q uals( dVDSearch . outputMessage , " Added to your list " ) ; II " War a nd Peace ' , should be absent dVDSeaICh . doSearch( " War and Peace " ) ; a ssertE quals ( dVDSealch . sealchResult , false) I

303

304

CHAPTER 12 ANALYZING DEl AiLED REQUIREMENTS

assertE qual s( dVD Searc h.outpu t Message , " Sorry , we don ' t this OVO' , ) ; •

•

•

•

stock

•

•

}

Fi gure 12.28 "lImmarizcs lhls discuss ion. The adva nt" g~ o f uSing tes ts as a requirement is that thi s i concre tc , th e d Isad va ntage is th at It IS not complete. There i. nothin g to sto p us from including th o ro ug h d eta iled req uirements with the un it tcst. ho wever, thereby gainin g agi le and, to some ex ten t, no n.agile ad va nla gcs Thi i show n in Figure 12.29

-.OJ

o Z

C ust o mer shall be able to enter rhe name of a OVO ,n rhe tex t box , up to 20 alphanumenc c harac ters. The app hcation shall check rhi s. wi th punc tuati o n marks replaced by blanks, with the OVO inve ntory , and display accordingly "Sorry, we d o n't stock this OVO" o r "Added to your liSt." (Excerpt from requirements d ocument. )

-.-

public void testLookup( ) { I I ' 'Gone with The Wind" should be present dVDSearch. doSearch ( .. Gone With The Wind" );

CD

«•

c:

OJ

CD

«

•

•

•

I I ' 'War and Peace' , should be absent dVDSearch.doSearch( "War and Peace" •

•

);

•

Figure 12.28 Unit tests and code comments as detailed requirements in agile processes

I· Requirement 3.4.2: Customer s shall be able to enter the name of a DVO in the text box, up to 20 alphanumer ic char acter s . The app licat ion shall check this, with punctuat ion marks repla ce d by blanks, wi th the DVD inventory, and display accordingly' 'S orry , we d o n't stock this DVD" or , 'Add ed to your list. ' , -I public void testLookup() { II ' 'Gon e With The Wind" should be pres e n t dVDSearch. doSearch ( .. Gone With The IHnd" ) ; •

•

•

I I ' 'War and Peace' , should be absent dVDSearch. doSearch ( "War and Peace" •

•

);

•

Figure 12.29 Comblnlng agile and non·aglle methods In handling delalled requirements

USING TOOLS AND THE WEe FOR REQUIREMENTS ANAl. YSIS

, . Understand next requirement

o. Understand high-level

5. Refeetor code 10 clean uP. ele.

2. Refactor code base 10 prepare for Ihe requirement, jf necessary

requirements

4. Modify code

base 10 pass Ihe test

3. Write tests validating the

F'tgUre 12.30 The agile programming cycle

When unit tests arc used as detailed requirements, [hey are some times written btJort the code is written This style is known a !<sf-dn"nl drur/opmtnl. It bui lds upon the existi ng code base, and IS ca rried out in the following sequence. I. Understand the required new or modified functiona lr ty.

2. If needed, refact o r the code to prepare it for the new func ti onality. Rdactoring preserves the code's functio nal ity, ne ither increaSIng nor dec reasi ng its actual h'llcti o na lity. It IS discussed in detar! In Chapter 24 3. Write test code that would test thIS functiona lity If It eX Isted . This is usuall y done with a tool slIch a J U nit This te t will fa d initIall y beca use the functiona lity it tests does no t ye t eXIS t 4. Add to the code base until th e test pa ses. 5. If necessary, refactor the code base to make it clear and coherent. Test ·driven development IS described funher in C hapter 27. Recall that agile development co nsists of the cycle shown "' F,gure 12 30. Refact o ring, de cribed In Chapter 24 , IS esse ntia l to the pro ess In two ways. It IS u
12.11 USING TOOLS AND THE WEB FOR REQUIREMENTS ANALYSIS Tool, can htlp th e process o f ca ptunng and managIng r ·q urrcment<- for example , hy >o""n~ , ,ltegon z; n!:. p"oritizlng, asslgnlns , and tracklnu them One be neA t o f >uc h tool, i> to kn o w who" worklllg on what requirement at what tIme Ton" <.a n also help to o nt",1 '·fea ture crce p'· -the pr t" by w h, c h leatur~s that ire not r.ally nece.sary are add ed to th e app lrca tron W,th th e approprI"te t 0 1<. a projec t !tader can more eaSIly asseos the tatu, "f r.qUlrt·ments a nal y", I or exa mpl e , th e leacler an N" ly d e tcII'lIOl' the percenl"!!"

305

306

CHAPTER 12

ANALYZING DETAILED REQUIREM ENTS

j:ilatuB

edPd1¥

aQlllOOlllllWl QUmb.or

Essontlol

"T

No.

OpUonol

slor1od

Ooa.gned

F,oC'tJon wmplOIO Roady lor

' /3

213

lor

'nopoction Inspoetod

Ooslroble

Imogr••lon UN'

'I liad

tested

8&§PQQsible QDgIO~Q[

T

-t

Figure 12.31 Example spreadsheet lor tracking ;equlrements

of essenti al deta iled reqUire ments implemented and full y tested by QA. Bugz ill a (someti mes in a version with the unappealing name "Issue zi ll a"), an open sou rce too l for manag ing reqUi re men ts, was descnbed In .he Ecl ipse hig h· level requi reme nts case
12.11.1 Simple projects For simple project , much of this can be performed usi ng a si mple Web ·bascd spread sheet, as illustrated In Fi gure 12.3 1. Howeve r, fo r most reasonabl y sized projec ts a req Uire men ts tool is esse ntial. The "deSigned for" desi gnati o n in Figure 12.3 1 ind ica.es that the require me nt is accounted for in the desig n. "Un it tested" means that the code implementing the req uireme nt has unde rgo ne testi ng in stand·alo ne fash ion . "IntegratIOn testing" means that the application has bee n tested to verify that it impl ements the requ irement. A table such as .hat in Figure 12.3 1 is mai ntai ned as part o f a project s'atus document that can be attached to the SPMP The e lls in th is marri x could be hyperlinked to releva nt parts of the project's documents, thereby preserving slngle·source documen.atio n for detailed req uirements (i.e., e liminating duplication ). For example, ,.. ____ _ Hvpedink from Jaya Source I to CorresQonding 0 • Reauirement Using /ava doc

t

ro ,.I

Engagement Requirement 1 ("Engaging a foreign character") . ... Implementallon commenls ... .

"'

The purpose of this melflod Is stated in SRS. The purpose is not repealed with the source!'!'fIe.

.,.

public engageForelgnCharacter( ... ) ( • •

•

•

•

)

FllUre 12.32 Hyperllnk from Java source to corresponding detailed requirement using Javadoc

USING TOOLS AND THE WEB FOR REQUIREMENTS ANALYSIS

h)'JlCrlinks from the ourcecode to the corresponding detailed requirement can be accompli hed with toolssuch a Javadoc.J.""doc converts certain Java source code comments into an HTMLdocumcnt describing thc classes and Iheirmethods (sec, for example , [6 ]). By insening hyperlinks to the SRS within the e commenlS, the HTML document produced by Javadoc hyperllnks to the SRS. This IS illumated In Figure 12.32 , where the detailed requirement corresponding to the method CllgagtForrig. Characttrf) is hyperlinked from the document that Javadoc produces from the ouree code. The usc of dodtts make thIS process increasingly convenient. The trend is for continual improvements in the process by which prog rammers will be able to more easily go back and forth between the SRS , the deSi g n, the graphical user interfaces, and the source code.

12.11.2 IBM's Requisitepro™ For substantial projects, professional tool s are needed to track reqUIrements. The shee r number of detailed requirements usually make this necessary. One example is IBM's Requ is llePro™ product. The fo llowing figures, describing it, are taken from hllp.//www.lbm.com/deve lo perwo rk ra tio nailli braryl53 47 html F,gure 12.33 shows a window for sClling the properties o f an Individual detai led req uirement RequisitePro allows various views o f the requ ireme nts as a who le This helps projec t managers and software engineers to manage and track their progress FI gure 12.34 is o ne example .

I

W •• I

I

....."or T,..·

.

,

:' :

I

...

t

!lr:

U

'0,

--

I

ned",

-

I Cb

f.

J r,IT;.~h~E.'---------------~iJ

\It

Ic

As&!

:a::

U 11

• c

..

Figure 12.33 Setting properties of a requirement In IBM'S RequisitePro"" SlraoonaVliDra1y!S247 htmt

Figure 12.34 A view of a collection of reqUIrements In RequlsltePro SoI¥ck IBM, hUDHYMW_iDm comIde~eIoptNo'Of'tslrttiOMlllibrbfYJ'5.247 htrnl

rM

307

308

CHAPTER 12

ANALYZING DEl All D 11EQUIREMENTS

,'2'

't

1$9

•

•

, 0 _II/ll,,.d,. 1.0. J m t

erell-"I

-

-

~I

Figure 12.35 History of a requirement In RequisitePrc™ Source 18M, hupJ/www Ibm cOlTVde\IeloperworkSlrotlonaVllbraryl S247111mJ

It is possi ble to query this requ irements database-ill other words, to obtain all requirements satisfying a desired criterion , su h as those pertaining to security As individual requirements are wo rked on

by softwar~

engineers, tools hke RequisitePro,.M .IIow the "history" to be tracked, a sho wn in F,gure 12.35 . H,story refers to an account of the work perfomlcd to sa ti sfy th e requirement at various points in time .

12.12 THE EFFECTS ON PROJECTS OF THE DETAILED REQUIREMENTS PROCESS Once detailed reqUIrements have been coll ected, the project documents can be updated to reflect the improved project knowledge. We w"l take as an example the reqUIred updates to the SPMP , which can be updated as sh own In Figure 12.36. Detailed requ irements are placed under conA guratl o ll control. One issue to be addressed is what level of detaIl should be counted as a software conn gura tion item (CI ). ertainly , Section 3 as a whole ("SpecIfic requ"ements") of the SRS (using the IEEE standard ) could be a CI Each class could be a CI. Individual requ"ements are typIcally too nne· grai ned to be Cis. \'qhe n the list of requIrements grows into the hundred , i"cotfSIsttHCltS Can easily arise . Oassifying requirements by classes, classe; by packages, and packages by subpackages, and the like becomes a necesSIty. The packages typically correspond to subsystems in the ove rall organizatIon of the application. Although rompl","css is a goal for which we strive In collecting requirement , it i usually an elusive goal For substantial applications, there is seldom a natural "last" requirement-just the last one before requirements freeze . For th is reason , we strive for self·complctcncss: ensuri ng that all of the requirement!' necessary to accompany each requirement arc present.

Large ·scale projects require increasi ng organizational fomlality (not to be confused WIth formal method» . The SRS may have to be divided into separa te volumes. A single section on Our (tiny ) case rudy could <"xpand IntO a 700· page volume. Extensive management work is required to schedule the development and onspection of detailed requirements. PrOjects WIth hundreds of spednc requ"ements need requIrement manallement tool The suecc<sful WIdespread usa~e or thdava package< ha shown, however, that I.rge collections of reqlllrementlo are manageable when the functionality IS organized by well·deRned po kalles, oubpa kag.: and la c> The rewards of good requirement< analY>ls arc sub tantlal onvcrsely, the penaltl<'S or poor requirements are substa ntial too. For examp le, Faulk [7], repom on • Covernment A counting Of c study of the C heyenne Mountain Upgrade project on wh,ch "reqllirements· related problems· ulted on. 600

STUDENT PROJECT GUIDE: REQUIREMENTS FOR THE ENCOUNTER CASE STUDY

- latus after Initlol draft

R"ull of updating afltr higl!.lrod

Result of updating .fter detailed

rtq,Hrrmt"'S

reqUirements

•

Milestones

Initial

Mort d,'ai/,d

More detailed

Risks

Idenl ify

Relire t'isks idrn·

Retire risks identiAed. ide ntify more ri sks

lijI,d P,roio",/y, serk mort risks Schedule

Personnel

Very h ig h

Prtlinmwry pro)-

level

,el leh,d,,/,

D esignate C-

£"9111(((S dcslg . "a I,d fo, D·

requirements

Cost Estimation

engin~ers

rrqu irrmrols mUllySIS

Crude

Firs! csritlln l(s

eStimates

baltd

0"

CO ll 1(")1 1

job

Mo re det.ailed, shows c1.ss and method development ta,klng DeSig nate softwa re architects

Improve d cSlimalc using more specific function points and/or past experience with similar requirement

Figure 12.36 updating a project upon completion of detailed requirements ana lYSIS

million cost overrun . an eight ·yea r delay , and dimin IS hed capabilit y. Debates continue abo ut the perce nta ge of large projectS that turn ou t badly versus the percentage that turn out well. Many large projects do a fi ne job of requirements anal ysic;. Th e author can arrest to thi s fro m persona l experience

12.1 3 STUDENT PROJECT GUIDE: REQUIREMENTS FOR THE ENCOUNTER CASE STUDY This section illustrates how the requirements princi ple . covered III this book arc translated into practice, by u ing the video game case stud y as an exa mple It use the o bJec t-o ncntcd sty le of expresslll!: reqUirements Recall that thiS organiZing style has the advantage of improved tra cea bil ity and the disadvJnta ge o f diminished readability compared with o ther organizations such a. by use casco11,e ca« study IS continued III
1. Preparing Hal Furness, haVi ng bee n elected the requirements leader. wa< re<po nsi blc for o rgan izing the anal y
by preparati o n Interview, WfllC · Up, and review The I1l clrics they chose were dl tJtcd mo,t1 y b l

company policy. and were a< follows • Time taken • Pagei of hlgh . level req uirement> wn ll e n

309

310

CHAPTER lZ ANALYZI NG DETAILED REQUIREMENTS

• - eif ,. " c"I1lCIH o f Ih · artlfa t, On a < ale 01 I- I! (nut rn anJuted by ,,",pa ny po litY)

• Dele tS lound dunn" ""pc tioll' . a, appli~:tble The ~a dcr IS referred to SectIo n 4 01 thi s guide to ,cc the,e metfl (' arran Ke d In tabu la r fo rm a~n made ,ure that the syk 10 cietern"ne WIth whom to speak 10 get hlg lNevcl rcqu l ~l1lenl . Hal unde~l ood Ihal no ne of the team knew muc h aboul Video gam<.,.. He deCIded 1.0 Interview people who fTeq uc ntl y play ga mes and are intereSlcd In g ivi ng Iherr tIIn e lor a modest fee . H e made o ntact with Betty Si ms, President of Amaleur Ga mers Intern all o nal, an enthu lastl game player who saw a bnght luture for VIdeo ga mes as vehIcles lor fun , community involvement , a nd educat Ion Betty also knl"W man y ga rn ers. H al and Karen decided to wnle up requirements speclfica llons based o n BellY's "'put and then show the spc ificd tl o ns to others. The rest o f the team was to inv{"sti ga le oth er avc nue~ for input at the sa me: t lm ~ .

At a weekly meelin!!, H al prese nted a plan for requ rrements analysis, as fo llows, Week 1, Hal and Karen , Interview Betty, begi n draft ing h ig h · level requirements . Fern and AI: Seck o lhe r candidates fo r requrrem ents input Week 2 : Fern and AI: Report candidates

10

weekly mee ting .

T ea m, Selec l o ne o r two addil ional people

10

supply requirements.

Hal and Karen, Complete draft of high . level requiremenlS, e ·mail to Betty for comments; arrange to interview the deSig nated additional people; c· mail existi ng specifica tion to them; c reate a complele requireme nrs docume nt fo r iteration t ; place under conAglirat io n comro l.

Week 3 : T eam , Approve the SRS for iteration I. H al and Karen: Interview deSignated people. edit and expa nd the specification; c·mail to all interviewees; collate respo nses, edit docume nt, leaVi ng selected issues for team resoluti o n; plan detailed requirements analysis (sec the Part V 01 this book). Week . : T eam, Provide input on the draft SRS; approve plan fo rdetailed req uirements analysis (see Part Vol Ihisbook) Hal and Karen, Write up SRS and e·mail to all interviewees.

Week 5 , Hal and Karen: Resolve issues raised by interviewees, write up results; e ' ma,1 to team, begIn impleme nting detailed requirements process (sec C hapter 13). Team : I~ spect h'lIh . levei requirement•.

STUDENT PROJECT GUIDE: REQUIREMENTS FOR THE ENCOUNTER CASE STUDY

Despite the expense, Hal felt .t impon.nt to have the cntlfe team inspect the high . level requirements because of the do ument's importa nce In general , the team planned to use thrce·perso n inspection teams. Hal heduled the first interv.ew with Betty .n Room 1428 of the Stewan Building from 10,00 a.m. to 11 :30 o.m. He .·moiled h er a bnef write ·up of the project's history, and created the foilowoog very simple agenda. 10:00 a.m.-l0: 15 a.m. Hal : motives for the project 10: 15 a.m.-l 1,30 a.m. Interview of Beny: customer requirement Hal decided not to introduce more details because he wanted BellY's requirement to influence the rcst of the meeting.

2. Interviewing the Customer Hal and Karen arrived at the interview with Betty, equipped with good sound recordoog equ.pment. Betty could not understand why anyone would want to build a video game unless it competed with the best available. Hal explained that this was just a firs t step. to provide the team with expenence in this kood of programming, to get an idea of the scope of work required, and to show the investors what could be accompli shed with a given amount of funding . Other motives were to dctermine whether there was any merit to the ideas that v.deo ga mes have potentially wide appeal , and arc applicable to educatio n. Aftcr this, the meeting became more focused The tape recorder was turncd on and Hal and Karen began to take detaded notes. Betty's contention was that role·playing games (not action games) held the most promise for broadening the playcr community . She disc ussed the minimum capability that a prototype would need . Th i in luded areas where the game characters would engage , ways to get from one area to the ot her. ways to cause intoractions among characters, and what wo uld happen when ,he c haracters engaged . Hal and Karen ,ned to separ.te the issues and features as they arose . into "c rucial for the first itera tion," "can be post poned ." and ' other (Le., they used a triage method). The importance of the requirements lis,ed in "other" would be determined later. Given the script.like nature of ,he requirements Beny described, Hal focused on ob,a'OIng use coses fro m her. He asked her to describe typical scenari os for the game. Be'ty de cribed wha, happens ,vhen two characters interact Kare n took no 'es and expressed thi s as a use case-a sequence of action 13ken by the player and/or the game-a nd then read it back to Beuy . Beny couldn't- think of any o ,her scenarios . Hal felt that there IOU t be more, and a_ked how the ga me gets staned. This resulted .n a second use ase. The third use case th.t they recognized explained how the pla)'cr mOves his character from one area to another. These three use cases seemed '0 be a satisfactory begin ning. Hal and Karen felt that there mig ht be additional essential use cases, but 'hey would have to gather ,hcm la,er. Berty , Kare n , and Hal sketc hed a few screens together. One showed a typ.cal encoun,er, .nd another showed a screen for en teri ng the qualities of ga me ch arac'crs. The re was considerable d i cussion of the perspect.ve that the player wou ld have. Betty wanted a player perspec'ive where the vicw shown on the mon i,or is the v.ew seen by the player. Karen felt ,hat 'he reqUITed complexi ty for ,h .. view would rake ,hc proJec, well beyond their modes, initial budget . It was agreed ,ha' a modified fro m·above view would be adequate for the prototype. The screen sketches reflected ,his. TI,ey agreed ,h>! conSIderable re lIlement of the user .n,erface would be required Because of the in,erfaces that ,hey sketched, Karen fel ' that 'he go me could reall y be underst od an i b), meaM of states Betty was not famoliar with th. tem" but she was comfortab le describing ,vha' he called ,he "mode<;" of a typica l role . play.ng game, wh.ch ,urned o ut be the sa me oncept. Karen ond Hal ,hen ,ke t hed out the requ.red ,ratc' of the gome, and rev.ewed w.th Kare n h ow ,he Rame golS from One s'a'e to all ,11 r

'0

311

312

CHAPTER 12

ANALYZING DETAILED REQUIREMENTS

H ~ I bro II ctll",d 'n:d cI~rofy ", !! the gJl1le lurther by analyz ing lhe lI"w ,, ( data, but , oon (cal,~d that the data Ilow I CI" lll'C live added httle va lue Karen I" vlewed he r no tes with the o ther, A (ew pOlOt ' nceded carre tl ng, but th ' re wa, lIene ral :lgrecmcn l on the de~ ripti n.

3. Writing Up the software Requirements Specification Hal and Karen diVided the task o f WfltIOg up the RS by ,ec tio ns They used the IEEE R standard, $cctlons I and 2 ( eetlo n can I>t> o f the detJded requirements, the proce s (or whic h" d, >cus,ed In the Stude nt Project C",de for h ~pter 4). T o avoid onOicling wri te·ups, they made ,ure that their sect io ns wc re as Independent as possible. Hal remembered IllS previous project, where the team pe nt sa muc h time reconciling pieces written by different people that It would have been quicker for one perso n to pe rfo rm the entire tas k alo ne They disclls<ed how to proorotl ze the req",rement" becau Cit wa, becomin g lear that o therwise the list of requirements would become fa r larger than the team could handl e. Hal ,.anted to rank the m all , but Kare n pointed out th at the effort Invo lved would be large ly wasted- most of the top -ranking reqUirements would ge t done anyway , so the ir exact order would not be important. Almost none o f the botto m ones wo uld get done , a the lime spent ra nk ing them also would be wa red . They deCided to use a tTiage method to rank requirement into essential at o ne extreme, optio nal a t th e other, and desirable for the middle category (which simply means neither essential no r optional) . They felt that it might be necessary to rank the deSirable reqUireme nts later. Th IS saved a grea t dea l of useless debating time. They de cribed their claSSification scheme 10 ectio n 2.6 of the SRS ("Apportioning of reqUi rements") . Section 2. 1. I (concept of operation , containing the sta te diagram fo r the game) took Hal the longest time to write because he had to translate Berty's info rmal comme nts into a concrete fDim . They tried to cross-reference appropria te sections of the SRS with correspo nding ,,'Sts even though the teStS we re still sketchy This helped to clarify the requirements themselves. however. When Betty looked at the test for Section 2. 1. 1, she recognized that Hal and Karen did not understand some of the issues. In particular, whe n the game is in Reporting state and the foreign character enters the area contai ning the player's character, the tcst did not expect anything to happen Betty saw thi< as detrimental and as a way for the player to effectively halt the game. The defect was added to the list of defects wi th a "major" categorizatio n. nt Karen sketc hed the user inte rfaces using PowcrPoint a a draWing tool , rather than building them wit h Java, the target lan guage. She considered PowerPolnt adequate because the Uls in thi s part of the SRS are meant to be sketches-the de tailed Uls are specificd in Section 3- and, in any casc, they wcre liable to be c hanged a g reat deal ThIS helped Hal and Karen to show the sketches to Betty and the o thers, obtain feedback , and then specify the Uls exactly for the de tai led req ui re ments.

4. Following Up The SRS Sections I and 2 we re .·mailed to Betty. She realized that Hal and Karen had included o nl y twO o f the three lise cases, and the third use case describing moveme nt of the player's character was absent. Thi defect was logged with a high priority. Betty was surprised to see that the SRS did not reAect several is ue that she thought he had made clear were importa nt , and was humbled to see that the SR reflected ' requirements" that he had offhandedl me ntioned but now realized would be a waste of time. The latter IOciuded the ability of the player to change outfits while an engagement is progressing. She had numerous comme nt , mOSt of which Hal and Kanen responded to, and some of which were added to the list of defects, Hal e ·mailed the R cction I and 2 to the team to e nable the m to prepare for an inspection . Team leader Ed had learned about Arlan Howard , a market ing executive who wa very familiar With the video game industry The financial backers were willing to fund fun her requirements analysis at the customer I ~d, and Hal and Karen pre pared to mee t with How~rd The I~tt er wa. no t able to ~r.nr them more th. n half

STUDENT PROJECT GUIDE: REQUIREMENTS FOR THE ENCOUNTER CASE STUDY

-

thiS projcct II

Writ,,·up (results 01 insp"ction)

organization

norm

Preparation

I ntervi"w

Review

TIme spent (minuteS)

200 minutes

170 minutes

270 minutes

250 minutes

... TIm" sp"nt

250/ 890 = 28 %1120%

170/ 890 = 19%1123%

270/ 890 = 30%1127%

200/ 890 = 22 %112 9%

Quantity

TOIllI 14.8 hours

15 pages

procluced Productivity (= TIme! qldntity)

xlf·assessed

15/ 14.8 = 1.01 pgs/hrll 0 .9 5 9

5

9

2

quality

( 1-10) IXI
Process improvement

1.3 per pagel/ 1.0 I oer page Spend ~20% less rime • prepanng

Spread inter· • vIew time more evenly among people

Check mate · rial morc (hor· o ug hly priorto

Spend ±30% more time revIewing

inspection

F"lgUre 12.37 Example of postmortem data and analysis an hour since he was very busy. Karen developed a prioritized list of questions and topics and mailed them and the existing draft 01 SRS Chapters I and 2 to H oward . They planned to wrap up the high . level requiremenlS with Howard. The team also planned the process of developing the detailed requiremenrs .

5. Metrics and Postmortem for High-Level Requirements The high. level requirements were ubjected 10 an inspection by the enri re team and the defects were recorded. For the next weekly meeting, Hal and Karen sum mari zed the metrics as shown in Figure 12.37 . The team agreed on the postmortem ob ervatlons shown .

6. Preparing for Detailed Requirements Hal and Karen had completed their write · up 01 lhe hi g h .level reqUIrements, ba ed o n di cussion and Intervlcws with Betry Sims and Arlan Howard. Th ey used the IEEE standard, whose headings prompted them lor the nonfunctional requirements such as CUls, performance, and hardware platfol'lllS Now they had to Identify the manner In which they would organize the fun tiona I Detailed Require me nts. They antiCIpated haVing to revisit and update Ihe S R many tim es, coordi nating the de
R$, lhe deSig n, and the code.

313

314

CHAPTER 12 ANALVZING DETAILED REQUIREMENTS

11, y 11,; , dis lIs' cd orHa", z i n ~ ,he de,ail ed rC'1uorcmcn" by ,late< and a~ '''H'' , bJ,cd on the "at · "anSlllon d1J81-:lm de,c nbed "' ,he h'/lh .!cvc! requiremcn» Thl< or/oCallizatlon me thod would <-" nmt o( al.\t I,he .K,ions that a player would take, , uc h as hck,nl! an eX it hyperhnk o n an area , (o llowed by the effects o( th" a tI n They both agreed thai till wou ld be an undef\tandable organization, bu, dec ided that It would no t 'nce to the nnplemcn,ati on a, well as rhey wanted They began ,earch,ng (or other way' In whic h to rganize ,he detailed requiremcn,s. Hal wa- ,n (avor of organ lzi n!! the funct ional detailed reqlllre men ,s by use ase, especia ll y Since he wan ted to loll ow the Llnl ,ed Software Devciopment Process H e sa id ,hat , at tillSstage, the Video game could most cas d be thought of In terms of the srlth'9 up u~c cas.e, th e ,"OVfI19 lUHOIIg tlJt ga mt OfClU u~c case, and the MI9"9"'9 thtJortigll bflraclrr lise case . He point'cd out how co nvcnit:nl ll would be to use JUSt these three use cases as the to tal e"ent of rhe (unctiona l requirement . He was also ex Ited about the prospect o( perhaps being able ' 0 reuse these u e ca e, for specifying future games Karen agreed tha, the requirements would be qui te easy to understand if orga nized by use case , but she had several 01 jections. The first wa that some requirements would be pan of more lhan one use case. An example is what happe ns when an exit fro m a room is clicked . T hi s could be pan of a ll of the three use cases they had ide"tined, and so it would nOt be clear where to look lor i, Karen's ot her o bjection was the fact that mapping from the usc cases ' 0 the code would not be as clean a ,he orgaOlza,ion she had ,n mind. Finally, she pointed out that the organization was no t yet equipped to properly archive use cases for future reu e. Karen wanted to orga nize functional use cases by class, which , she aid, faCi litated traceabiliry (rom requirements to implementatio n. She wanted to pick ,hem ca refully enough to ensure that they would be used as part o( the design (and Implementation). Hal pointed out a disadvantage of thi approach · the fact that it (oFCed them to deCide very carl yon some o( the classes tha, they would u e II11mpie mentIOg the application . He was worried about the pOSSibility ,hat they ma y later c hange their minds about the selection . After further discussion , they deci ded that o rgani zi ng the detai!cd requircmenls by class had more benents lhan drawbacks, and they committed to this method . They decided ' 0 be very co nse rvative about class se lection , however.

7. Classifying the Detailed Requirements Hal and Karen firs t took each usc case, and identified what object o( what class In"iated the action and what object has the responsibi lity (or carrying out the action . This process prompted them to create andlor identify classes. They fou nd it necessary to ca ll Betty and Arlan several times to clarify use case steps they thought they had understood but really didn't. Hal listed the classes and objects mentioned in the usc cases. They then brainstormed , couring every aspect of Encounter they cou ld reasonable ima gi ne for additional po sible classcs. As a Rnal step in the class selection process, they dras'ically cut the list down to an essenl i. 1 few , but taking care to pre erve all of the clas es referred to in the use cases. The final list consisted o( Arra, E"COIIMI,rCharn I", En co"nlrrGam" En9a9"'I(>11 E"9a9rnomlDisplay , Con",elio"Hyprrl;"k , Forri9"CJ,ara clrr, Play,rCl,ara Irr, and PlayrrQ"alily Window. They now Rnalized the headings of the SRS in Section 3.2 ("SpeciRc requITements"). They collected the delailed requirements related to areas in Subsection 3.2.A, corresponding to th<' Area class. They ordered these subsectio ns alphabetically because they anticipated adding classes later. They sumllSed that if they were to have ordered topics by number (e.g., PlayrrCbara I" being 3.2. 14), then locating an individual rcqll1rement would have been more difficult, because the user of the SRS would have to search many of ,he 3.2.N subsections be(ore Rnding the one applicable. The next class being EncolonlrrArra 0" "relion , they numbered the next . ubsecl10n ' .2. EAC, and so on . W ithin each cla.ssiRcat·ion, they crea ted subsection$ for al/rib"I" , nltiti",].IM lionlll,ly, and n.... l$ .

8. Writing the Detailed Requirements Karen and Hal wrote Section 3. 1 on uscr interfaces by Riling in derail, On the sketches the had made forth. h.gh. level requirements, then aski ng Oelty, as well as the human factors dep.nment, to rev iew them. Know,"s that thiS would be the Anal document from which the<" were to be bUilt, the>' hod ,he Cll tomer .g"-'" on e"ery detoll

CASE STUDY: DelAILED REQUIREMENTS FOR THE ENCOUNTER VIDEO GAME

Thcy checked their interview notes with Betry and Arlan as to the properties ("attributes) of each classification (cia s). For ex~mplc , thcy asked what propenlcs we re required for the connections between cwo Encounter areas. (One property of such co nnec tio ns was "the first area" connected , and another was ' the second area.") For each class , they asked themselves what entities (instances of the class) were required for thc game . For exa mple, there would ha ve to be a dressi ng room arca and a courtyard arca They then asked what functionality the class had to possess . For exa mpl e, a functionality of each Encounter character is the ability to configure the values of it·s qualities (requirement 3.2.EC.3 .2). Finally, they listed all of the events that In tances of the class were req uired to rcspond to (fo r example , clicking on an exit from an area l. Onc aspect that di turbed them was the time reqUired for new va lues to take effect. They realized that this wa a key aspec t to the ga me, if no time were to e lapse , the playe r would si mpl y set the qualities pertaining to the current area to a maxi mum , and little skill would be required to play the ga me 11,e delay made the game interesting , but the problem was, h ow much delay should there be) 11,cy con ide red stati ng "to be decided" for the durat io n, but finally concluded that th is would no t help. They deCided to specify fo ur seconds, feelin g that changing this amount should be straightforwa rd . Karen was concerned about the iml'recision of some of the requirements, espeCially those co ncerning the manner in which qualiry poi nts shoul
9. Following Up: Metrics and postmortem on Detailed Requirements The requirements analysis team asked Be lty, Arlan, and Ihe res I of the team to Ins pect Ihe detaded requirements. They performed thIS inspeclion primarily agai nsllhe 11Igh -level reqUIreme nts by ensuring Ihat every part of Ihe high-level requiremen t were elaboraled upo n by delai led reqUire me nts. They also e mployed a c heckli Ilike the one described in Table 13.3 of Chapler 13. Several defecls were fo und, whi ch H al and Kare n recorded and repa"ed . The resu lts of thiS proces were Similar to Ihose de c ribed In Figure 12 37.

12,14 CASE STUDY: DETAILED REQUIREMENTS FOR THE ENCOUNTER VIDEO GAME Th,s seclion compleles the requirem e ntS sjJeclRca ·

3.1 Exte rn a l Interface Re qu iremen ts

tlon of the Encounter vid eo ga me in IEEE format.

3.1.1 User Interfaces 3, Detailed Requirements Note to the Student. The IEEE term u.ed in this hcadJllg IS ·speclfic" requirements We have substituted the te rm 'ck~lled" to be ~onslstenl with the lext

Section 2. 1.2 in the SR for the En ounlcr VIdeo lIame showed o nly ketc hes of u cr interfa In order 10 proVide product p
31 5

316

CHAPTEI! 12

ANALYZING DETAILED IlEQUIREMENTS

Note : Each part of Ihls Ilgure Is s pecifi ed - - - sepa rately In Section 3.

COURTYARD

living

dressing

room

room Elena

Current hfe

points: 56.38

(SelQU....... )

Value

1~'2i·1

16.18

Figure 12.38 Detailed requirement for Encounter courtyard GUI Source. Gtaptbcs reproduCed WIth pcrmlssK>n from Corel.

be given in this section. Since we are using the object style of specification in this case study, the details of each window arc packaged with their classes In Section 3.2.2 in the SRS. In any case, this section should explain the physical relation· ships among graphical elements (e.g ., cascading, tiled, superimposed).

same lIser interface is used to

ho w the statuS

of the player's c haracter. An interface of ty pe a above will alwa ys be present on the monitor. When called for by these requ irements, inte rfaces of type b o r c will be superimposed . This requirement i teSted in Software Test Docu · mentation (STD). < test reference goe here > .

3. 1.2 Hardware Interfaces Encounter takes place in areas. Figure 12.38 shows a tYPical screen shot of the courtyard area , with a player.contro lled character, a foreign charac · ter, and the results at an engagement. This interface

The hardware that Encounter (which is a software application) deals with

takes up the ent ire monitor scree n. Areas have

connections to adjacent areas, labeled by hyperlinks. Clicking o n one of these hyperlinks moves the player's character into the corresponding area. The entire sct of '"te rfaces is as follows : a. One user interface for each area, specified in Section 3.2AR below . b. A uscr interface for
None (I n a fUlur~ release, Encounter will be control· lable by a joystick.)

3.1.3 Software Interfaces Other software with which Encountler must '"tlerface: an enmplle would be a prin~r drwct None

CASE STUDY; DETAILED REQUIREMENTS FOR THE ENCOUNTER VIDEO GAME

(In a futu~ ~Iease , Encounter wtll be playable from IntergalactIC Internet Gaming Slle .)

3.1.4 communication Interfaces one (In a future release, Encounter shall Interface with the Internet via a modem with at lea t 56 Kb/s.)

referred to elsewhere in the project, could not be disrurbed. TI,e requirements would not be alphabetically ordered. As a ~sult, one would have to go through the requirements one by one to locate a particular one.

3.2.AR Areas

3.2 Detailed Requirements by Category The IEEE uses the heading "Classes/objects" for Section 3.2. Th,s assumes an audience that knows object orientation. It is necessary to untkrstand 00 to create this section but it is not necessary in ordeno read and understand it.

Since we ane classifying the detailed requirements by class, we first list the classes that we have (very carefullyl ) chosen . These are not all of the classes that will be used by the application merely the core classes pertainmg to the domain of the application , which arc adequate for organizing all of the requirements. In this case, for example, all of them are aspects of the Encounter video game.

Categories for the Encounter video game suffi cient for expres.ing the requirements arc Area, EncounterCharactcr, EncounterCame , Engagement, EngagementDisplay, ForeignCharactcr, PlayerChar. acter, and PlayerQualityWindo,,, .

The nunlbering "3.2.Area.N .N ... :' etc. u ed in Section 3.2 makes it easier for us to insert, remoye, and locate nequirements by organizing alphabetically the classes that contaIn them. ThInk in terms of hundreds of require · menls. If we were 10 number the classes usong -'3.2, 1 .. ""'3.2.2 . . ,If elc. , then in crting nh' classes would have to be done at the end of the I'$!, sincc exlslln8 numbenng, already ,o j

F,rst, we de cribe what the class (i .e., this classification of requirements) refers to.

An area IS a place viewab le on the monitor. All aCllvities of Encounter (I ncluding engagements) take place in areas. Rooms, gardens, and courtyard are examples of areas.

3.2.AR.1 Attributes of Areas Here we tell what properties each object (specific entity) of the class must possess.

3.2.AR.1.1 Area implemented)

Name (essential;

not yet

The statement above in parentheses indicatcs the priority and the sta tus of the requirement. Once the requirement is coded and tested, the statement "not yet implemented" is either deleted or changed to "implemented." "Essential" requ;rements are implemented first. Once a requirement has been designed for and Implemented, "essential" can be removed. This is one technique for tracking the state of the application and its relationship WIth this SRS. Another technique is to specify the iteration to whIch the requirement applies.

Every

n ounter area \yill have a lIfl1quc nJme

con"sting of I to 15 chara tcrs . Acceptable hara te" ,hall onSl
317

318

CHAPTER 12

ANALYZING DETAILED REQUIREM ENTS

TC~l plan

< Idcrcn

C 1'0 t(' ..,1

goe, he re >

E. l13ttnbute.type requirement map5 to a pairof get· and set· fun lions. TI,i. document suggests how ea h requirement can be hyperlinked to a lIllIt test in the Software Test Documentallon.

alternative would have becn to express these requirement a, (un lio ns: for example, "Encounter
3.2.AR.1 .2 Area Image (essentia l; not yet implemented) There ,h.1I be an image to display eac h Area object on th e enllre momtor. The image ,hall fill the enllre mo nitor

3.2.AR .2.1 Courtyard Area (essential; not yet implemented) There sha ll be an Area object with the name "courtya rd" requiring the quailtlcs stamina and strmgth . The preilmlna ry courtyard Image hown III Figure 12.39 IOcludt·s a map of nearby arca5 .

3.2.AR.1.3 Area·Specific Qual ities (essential; not yet implemented) O nly some game character quali"e shall be applicable in each area. The spec i~c qualities required for cach area are spcci~ed in Section

3.2.AR .2 .2 Dressing Room Area (essentia l; not yet implemented) There hall be an area With nam<.' "dressing room" requirin g no qualities. Its

preliminary image, shown in Figure 12 .40, include a map of ncarby areas.

3.2.AR.2 .

3.2.AR .2 Area Entities We designate specific area objects that muSI exist wi th in the appl ication. This section has been added to the IEEE standard. The

3 .2.AR .2.3 Dungeon Area (essential; not yet implemented) Th ere shall be an area with name "dungeon" reqllirin g the qualities stam ina and pa -

tience. Its preliminary image shown in Figure 1241 includes a map of nearby areas.

kitchen

COURTYARD dressing

living

room

room

--I I".-1

"*"11 ,

IGot

lEnd ....1

Figure 12.39 Encounter courtyard Image

"","""" 0"

'lQ fOOo" Doj~ I i)I'I

""'" fOOOItO

.....

CASE STUDY: DETAILED REQUIREMENTS FOR THE ENCOUi'lTERVIDEO GAME

DRESSING ROOM

I
ID1ngflQn

...

IOktoIrt

eo..,...

'"

1'1\)

IOJIIi CUIoI:lfl

Figure 12.40 Encounter dressing

...., ...., 10'0Wl1

room image

E. J. Staude• ..IOhn \\Iiley & Sons. 2001

3.2.AR.2.4 Kitchen Area (essentia l; not yet implemented) There shall be an arca with name "kitchen" requi ring the quality concenrrati on. The preliminary kitchen image shown in Figure 12.42 Includes a map of nearby areas.

3 .2.AR.2.S Living Room Area (essential; not yet implemented) There shall be an area Wllh name "hv i ng room" rcquiri ng the quali ti es co ncen tra ti o n and

stam ina Its prelim inary image show n In Figure 1243 includes a map of nea rby area

DUNGEON

dressing room

stl!d v

'00''' IClUih

Figure 12.41 Encounter dungeon Image

319

320

CHAPreR 12 ANALYZ1NG OETA1LEO REQUIREMENTS

KITCHEN

...

I

GoUla...

I

ISelqt"~

lEnd gem. I

I'C«IWI

Courtyard

I

,-

Drou '''IQ

""""'~.

""'"

01.1 'IQ' t;II ,

""""

.oom

Figure 12.42 Encounter kitchen image Source COpyright, E. J Braude, John WHey & Sons, 200 1

3.2.AR.2.6 Study Area (essential; not yet implemented) There shall be an area with the nam e "study" requinng (he quality concentrati on. Its pre -

liminary image shown in Figure 12.44 includes a map of nearby areas.

3.2.AR.3 Area Functionality This is the required functionaliry that pertains specifically to areas. Every functional

LIVING ROOM

courtyard

study

.

('o ' ....

00 , ' ... 00.

Figure 12.43 Encounter Illiing room Image

7~

0 M

-

u PI '-. ..

- , 'I)

CASE STUDY: DETAILED REQUIREMENTS FOR THE ENCOUNTER VIDEO GAME

Living

room

STUDY

DUDgfOD

-

00

eo..n,..!

'0 1--

-

.....

Figure 12.44 Encounter study Image

capability of the application should belong to one of these sections.

No ne

3.2.AR.4 Events Pertaining to Areas

3.2.AR.4.3 Interrupting Engagements (optional; not yet implemented) Players are able to interrup t e ngagements on a rando m basis. On ave ra ge, the playe r ca n stop o ne of every te n e ngage· nlents by executing the proced ure to set qualities. The u er tries to inte rrupt an e ngageme nt by at · te mpting to set the pl ayer's qualities. If the ga me doe no t all o w th iS, no indi catio n is give n; th e ga me

proceeds as if the attc mpt had not been made. We separate the events that pertain to are as from the attributes, objects, and metho ds. An event is an action that occurs to the application and is instigated from outside of the application.

3.2.AR.4.1 Display on Entry of Player Character (essential; not yet implemented) Whe nevcr the player's main c hara te r e nte rs a n arca , that a rea and the characters in ,t ha ll be displayed on the mo nitor. fIlli ng the mo nito r.

3.2.AR.4.2 Handling Engagements (essential; not yet implemented) W he n a fore ,g n ga me character e nters an a rea conta ,n, ng the p layer', maon ch.aracter, or Vice versa, th ey engage co h o ther.

3.2 .AR.4.4 Pressing the Set qualities Button (essential; not yet implemented) W he n the user presses the S{I q,wlilirs bUllo n, a w,"dow for selling the va lues of qualities a ppears superimposed o n the area, provi ded th at the re is no fo reign c harac te r in th e arca. Sec 3.2.PQ fo r the speciHcat ion of th is wondow.

3.2.AR.4.S Pressing the End game Button (optional; not yet implemented) W hen the user presses the £ull g(Jmt butto n, the gil mc [c ml inalCS. No add itio nal scree ns a ppear.

The previous sentenct, an inverse require· me nt, was fe lt to be necessary because games o ftc n do display a summary o f • se slon.

321

322

CHAPTER 12 ANALYZING DETAILED REQUIREMENTS

3 .2.AR .4 .6 Pressing the Get status Button (opt ion al; not yet implemented) When the user prc" cs the Gti sla/us bUllo n, In engagement display willdow appears shoWIIl8 thc Statu< of thE player'> haracter before and aftcr the last cnllage menl.

Kitchen courtyard

living

room

DreSSing

room

Oungeon

Sludy

3.2 CH Connection Hyperlinks Between Areas Conne tlon h)'pe rllll ks arc hyperlinks placed at each arca eXit, show ing the Mea to whic h it I S connected

Key

I . """"""'"

Figure 12.45 Encounter area configuration reqUirement

3.2.CH .1 Attributes of Connections Hyperlinks 3.2.CH .1.1 Connection (essential; not yet implemented) Each connection hype rl ink corrcsponds to an area connect ion

3 .2.CH.2 Connection Hyperlink Entities (essential; not yet implemented) Thc re are two co nnectio n hyperl inks corresponding to each are. connection, one in each area of the co nnec ti o n.

3.2 .CH .3 Functionality of Connection Hyperlinks None 3.2.CH.4 Events pertaining to Connection Hyperlinks 3.2 .CH.4.1 User Clicks on a Connection Hyperlink The effect of clicki ng a connection hyperli nk is th.t th e player's character is displayed i n the area on the other si de of- the area connectio n.

3.2.CO Connections between Areas Characters travel from area to adjacent area by means of connections. Each of these connects two areas. Figure 12.45 shows the required connections among the areas. 3.2.CO.1 Attributes of connections between Areas 3 .2.CO.1.1 First and Second Areas (essential; not yet implemented) Each connection shall connect a pai r of areas, which we Will ca ll the "first" and "second" areas.

3.2.CO .2 Connec tion s Entities 3.2 .CO .2. 1 Dressing Room-<:ourtyard (essential; not yet implemented) The,. shall be a con necrion between the dreSSi ng room and the courtyard 3.2.CO.2.2 Dungeon-Study (essential ; not yet implemented) There shall be a connection betwee n the dungeon and the srudy. 3.2.CO .2 .3 Study-Living Room (essential; not yet implemented) T here shall be a connection between the study and the living room . 3.2.CO.2.4 Courtyard-Living Room (essential; not yet implemented) There sha ll be a connection between the courtyard and the living room. 3.2 .CO .2.S Dressing Room-Dungeon (essential ; not yet implemented) There shall be a connection between the dreSSing room and the dungeon 3.2.CO.2.6 Courtyard- Kitchen (essential; not yet implemented) There shall be a connection between the courtyard and the kitchen 3.2.CO .3 Functionality of Area Connections None 3.2.CO.4 Events pertaining to Area Connections 3.2.CO .4.1 Moving a Character throug h a Connection (essential; not ye t implemented) onneetlons are disp layed J< h perlink, .t the borders 01

CASE STUDY: DETAILED REQUIREMENTS FOR THE ENCOUNTER VIDEO GAME

areas whenever the player's charactcr i in thc area . When the user cI.ck such a hypcrlink, the linked .re. is displayed with thc character in this area.

Elena

Cunenllile points: 56.68

3.2.EC Encounter Characters

Value 16.18

3.2.EC.1 Attributes of Encounter Characters 3.2.EC.1.1 Names of Encounter Characters (essential; not yet implemented) Every game character in the Encounter video game shall have a unique name . The speciRca ti o~s for names shall be the same as those for Area names, speCified in 3.2. AR.I. 3.2.EC.1 .2 Qualities of Encounter Characters (essential; not yet implemented) Every gome character has the same set of qualities. Each quality sha ll be a nonnegative floating po.nt number wit h at least one decimal of precision. These arc all init.al · ized equally so that the sum of their values is 100. The value of a quaiory ca nnot be both greater than 0 and less than 0.5. For the first release the qualities shall be concen· tration, intelligence, patience, stamina, and strength. 3.2.EC.1 .2 Image of Encounter Characters (essential; not yet implemented) Every game character shaH have an image.

Palience

Figure 12.46 Required user Interface for status SOU/ceoCraphlcs reproduced with permiSSJon from COre(

equal to the sum of the quality values. The values of the remainin g qualities are automatica lly adjusted 0 as to maintain their mutual proportions, except (or

resultin g quant ities less than one, wh.ch are replaced by quality values of zero

3.2.ED Engagement Displays (essential; not yet implemented) There shall be a window displaying the re ult of engage ments. The format IS shown .n Fib",re 12.46 . 3.2.ED.4 Engagement Display Events 3.2.ED.4.1 Dismissing the Display (essentia l; not yet implemented) When the user hits OK, the display disappears.

3.2.EG The Encounter Game 3.2.EC.2 Encounter Character Entities The characters of the game arc described among the types of Encounter characters. 3.2.EC.3 Functionality of Encounter Characters 3.2.EC.3.1 Living points (essential; not yet implemented) The Encounter game shall be able to produce the sum of the va lues of any charac· tds qualities, ca lled its livinS pointS. 3.2.EC.3.2 Configurability of Encounter Character Quality Values (essential; not yet implemented) Whenever an Encou nter character .s alone in an area, the value of any of .t qu.iotlCs m.ay be set The va lue chosen mu' t he le<> than or

The requirements in thi s secti o n penaln to the ga me

as a whol e. 3.2.EG .1 Attributes of the Encounter Game 3.2.EG .1.1 Duration (optional; not yet implemented) A record shall be kept of the durat.on of tach game, timed from when the playcrbegi ns the game. 3.2.EG.2 Entities of the Encounter Game 3.2.EG.2.1 Single Game (essential; not yet implemented) There shall be a .ngle s,me Future rdea es will allow several ver<.ons of the game to run at the same t.me

323

324

CHAPTER 12

ANALYZING DETAILED REQUIREM NTS

3.2.EN Engagements All c nfotJ ~(" m 'nl

h3"Ct r hJra ter

h Ih(' II1l cra<.tion between J p:a nlC o ntrollcd by the rla yer and , fo rc.w.

3 .2.EN.1 Attributes of Engagements 3 .2 .EN .2 Engagement Entities pemlancnt cng"semcn l

To take .. nU111e n al exam pl of a n cngllg ment in tim area If the pl. ye r\ ,tam.na w.lue " 7 and ConCe f1lra110n value" 19. and Fredd . - the fnr ' I!ncr'~
No ne

There arc no

Playe r, , tanllna 7 + I 112 = 12 .5 ; co nce ntrat.o n 19 + (0.6 )/2 ~ 19 3[0 ]

ent iti es .

1 1/ 2 = 5.5; co ncentral10n 0 because (06)/2 .5 less Ihan 0.5

3 .2 .EN .3 Functionality of Engagements 3 .2.EN .3.1 Engaging a Foreign Character (essential; not yet implemented)

This particular requireml'nt is mathematical in nature and so Ihere is no attempt to replace the mathematics with natural language, which would risk compromising it~ precision . The use of natural language to explain the mathematics is a good practice, however.

3.2.FC Foreign Characters A fo reig n charac ter .s an Encounter characler not under the players control 3.2.FC.1 Attributes of Foreign Characters Sec Encounter character requirements. These are initial ~

ized to be equal.

In future releases, foreign characters may mu When an engagement takes place, the "slro nger of the two c haracters is the o ne whose values of area_reciAc qual ities sum to the greater amount. The system transfers half the values of each area -speCIfic quality of the weaker to the stronger No transfer of points takes place

if

neither character is stronger.

If ei ther c haracler has no poi nts after the value reallocations arc made, the game ends. If the game docs nOI e nd, Ihe player's c haracler is moved to a rando m area and the results of the engagemenl arc d.splayed . As an example of the value reallocalions, suppose that the player engages a fore ign character in an area preferring stamina and concentration . If p~ is the value

of the player's stamina , and assuming p, + p~

> J. + fe.

tate into new forms.

3 .2 .FC.2 Foreign Character Entities

This section tells that there is only one foreign character.

3 .2 .FC.2 .1 Freddie Foreign Character (essential; not yet implemented) Therc shall be a forc.gn character named "Freddie: who e image IS shown in Figure 1247. Th.s character shall i01lially have a total of 100 POlOts that arc d1
we would have p: =p. + i/ 2, P: =P. + i/ 2.1: = i/ 2, andi: = i) 2.

3 .2 .FC.3 Functionality of Foreign Characters

The reader will recognize th. delect in the last equation, which should be = // 2. We will leave the defeci Inlact as an example.

i:

3 .2.FC .3.1 Foreign Character Movement (essential; not yet implemented) A long as It is alive, a forc.g n character should move from area to adjacent Mea '" rand om interval'\ J,vt:ragins t~·o seconds. After being present in an area for J rando m

CASE STUDY: DETAILED REQUIREMENTS FOR THE ENCOUNTER VIDEO GAME

/' ,. ,I

,!

called the "main" character. The nature of this con· trol is subject to the restrictions peclned in the remaining requirements. ThIS character shal l initially have a lotal of 100 POints that are dislnbuted equa lly among its quailtie 3.2.PC .2.2 Additional Characters under the Control of the Player (optional; not yet implemented) The player shall be able to introduce characters other than the main cha racter that the player con trols. Detads are to be decided 3.2.PC .3 Player Character Functionality 3.2.PC.3 .1 Configurability of the Player Character Quality Values (essential; not yet implemented) Whenever all fortlgn players are absent from the a·rea containIng th e player'" main character,

the player may set the value of any quality of the main character uSing the Player Quality Window shown In Figure 12.49 The value chosen must be less than or equal to the sum of the qua lity va lue Th e values of th e remaining qualities are automat i-

ca lly adjusted

0

as to maintain their mutual propor·

tions , except for resulting quantities It:ss than 05 ,

Figure 12.47 Foreign character Freddie image requirement SOUrce Grapnlcs reproduceo with peofmlSSlQn from corel.

amount of time averaging o ne seco nd , all of the character's life pOint are divided among the quail ties relevant to the area , such Ihat the va lues of each quality arc as close to equa l as po Sib le

3.2.PC Player Characters These are Encounter characters under Ihe conrrol of the play("!" 3.2.PC.1 Attributes of Player Characters ee EncOUnter characLCr aunbutts Player character Im age Un be sdected from one of the Images in Figure 1248

wh ich arc replaced by quailty value of zero 3.2.PC.3.2 ConfigurabiJity of the Player Char· acter Images (desirable; not yet imple· mented) The 1>layer shall have the option to choose the image represenllng hiS or her maio charac ter fro m at least two Images These o ptions

are shown

III

Figure 11 48 .

3.2.PC.3.3 Aging of the Player Character 1m· ages (optional; not yet implemented) The main player character hall automatica lly IIlcrcase each quality b), a percentage for the Irst half of hi or her hfe, then decrease each qua llt)' by the same percent · age for the second half Delails arc to be deCided

3.2.PQ The Player Quality Window Thl ...

I

a Window from ,,,h leh the pl ay er

Ill')

JlloCJtt"

3.2.PC .2 Player Character Entities

the va lue< of hI> or her h,racte"

3.2.PC.2. 1 Player' s Main Character The playt'r shall have (.ontr,,1 over a parll lIlar U3me (. haracttr

3.2.PQ.1 Attributes of the Player Quality window The wlndnw for ,ett"'~ the qllahtlC> 01

325

326

CHAPTER 12 ANALYZING 0[1 AILED REQUIREMENTS

•

Elena

Boris

Sean

Figure 12.48 Player character image options Source' GraphiCS rcoroduCed wlttl permISSIon from COrel

a player ch>r.cter In Encounter is shown by means of • typical example in Figure 12.49. The g.me charac· ler icon appears In the center, and Its name appears at the left top of the screen. The character's life poi nts .ppt.r in the center. On the left center is a li st box

displayi ng four of the qualities at a time . Cltck.,ng on one of these qualities allows the player to sdect a va lue for It in the text box o n the right. An explan · ation of how the arlthmelic

IS

performed

Choose the quality _ _

Image

you wish 10 set

Choose Ihe value 01 _-, the quality selected 16.3

Explanation

"r"'he valuos of the~quC:a:-:,n;:;io~s~n~o:-:t-:sp=ec~lfi;;:ca:::;;lIy7c:;h::o::s=en~r.::m~a:-;in""'ln-:t::-h.-:-sa-m-e-- proportJon to each other. Values less than 1.0 are counted as zero. E.g.,

be(Qf9: Slrenglh = 10.0 . endurance = 60.0 . intelligence = 30 ,0 . pallance = 0 0 (curront hfe poInts 100 + 60.0 ... 30.0 + 0 = 100 0) change: strength trom 10.0 to 20.0 after;

strength

.c

20, endurance == 53.33, intelligence

Figure 12,49 User Interface required GUI for setting quality values

sour"

GraphlCl reprOduCed wllJ'I pe.,nlssb'l Irom Corel

shown

10

a pale yellow box in the lower part of the screen

Currenllile points; 100.0

Shawn

IS

:r

26.66

CASE STUDY: DETAILED REQUIREMENTS FOR THE ENCOUNTER VIDEO GAME

Color backgrounds for the name, life points, and value boxes are to be pale turquoise. 3.2.PQ .2 Player Quality Window Entity 3.2.PQ.2.1 Window for Allocating Qualities (essential; not yet implemented) A window hall be avai lable under the conditIOns de cribed above to all ocate the value of the player character. The willdow 'hall have the appea rance of the C UI hown in SectIon 3. 1. 1 2 of this specificatIon. 3.2.PQ.3 Player Quality Functionality 3.2.PQ.3.1 Initiating the Display (essential; not yet implemented) The player quality menu shall be able to display it elf. 3.2.PQ.4 Player Quality Window Events 3.2.PQ .4.1 Displaying the Value of a Quality (essential; not yet implemented) When the player clicks on a quality in the li st box on the left. the value of that quality sha ll be disp layed in the text box on the right. 3.2.PQ.4.2 Setting the Value of a Quality (essential; not yet implemented) When the user enters a legitimate value for a quality and hIts the -enter" button, the value of that qua li ty is set to the amount entered. If the value is invalid, an error window shall appear stating "invalid value: try again ." 3.2.PQ.4 .3 Dismissing the Window (essential; not yet implemented) When the user hits the OK button , a time of four seconds elapse , after which the window disappea r . At th e end of this time period (i .e., if there arc nO interruptIons) the va lue allOCations are made .

3 .3 Performance Requirements Pcrfom,ance reqUIrements include required speeds andlor tIme to complete. Unless docu · mented in a different section of the SRS, they may also include memory usage (RAM andlor disk), noted either statically or dynamically (i.e., memory required at runtime). TI,e applicatIon shall load and di play the Initial image In less than a minute.

Engageme nts shou ld execute III less than one second. TI,ese requirements are te ted In STD < refe r· ence to lest goes here >. 3 .4 Design Constraints This section speCifics restnctions on design . If there is no material in [his section , designers

are free to create any (good) desig n that satisnes the requirements. For example, we can add the design constraint "one·story" to the fo ll owi ng: "A house with four bedrooms. all of which are less than a thirtY·second walk from the fami ly room ."

Encounter shall be desi gned using UML and objec t·ori ented design It shall be implemented in Java . The software shall run a a Java application on Window 95. lt shall be designed a way that makes it relatively easy to chan ge the n.tles under whIch the

tI'

game operates so that o r-hers can customize the game.

3.5 Software System Attributes

3.5. 1 Reliability 3.2.PQ.4.4 Interruption (essentia l; not yet implemented) Upo n Interruption of the dl play of the quality value window, the window van l hes Note that interruption s , hall be aused by a forei~n character entering the arca . Note also in thi s case that the qualtty value are not hanged and th at an engagement takes place.

Encounter shall fatl not more than o nce III every 1,000 encounter< T est documentatio n < reference to te t goe here > 3.5.2 Availability En ou nter hall be ava tl able for play on an I n.tn ni nR \'(11ndows 95 onI (i.e ., no ot her appl icOl lo n

327

328

CHAPTER 12 ANALYZING DETAILED REQUIREMENTS

'Im U h;)" CO ll~l y ) , T COr"t dOCUmClllt'lli On

rderence to

4,

supporting Information

te,t goe, he re >. NOlie

3.5.3 Security

4.1 Table of Contents and Index N o t Inclueled

Future release will allow access to saved ga",es only with a password .

4.2 Appendixes Not 1I1c1uded

3,5,4 Maintainability Appendices may Include

3.5.4.1 Changing (essential)

Characters and Areas It
characters and areas.

3.5.4.2 Globally Altering Styles (desirable) It

(a ) Sample VO formats, deSCflp110nS of COSt analysis stud ies, or results of user surveys (b) Supporting or background Informa-

tion that ca n help the readers of the

shall be straI ghtforwa rd to globally alter the style of the areas and connectIOns (Style changes reAect dif, ferent levels of game play in the same environment. )

SRS (c ) A description of the problem to be

3.5.4.3 Altering Rules of Engagement (oP-

solved by the software (d ) Special packaging instructions for

tional) Rules of engagement should be relativel y easy to c hange. 3.6 Other Requirements

the code and the media to meet security, export, initial loading, or other requirements State explicitly whether or not each appendix is to be an official part of the SRS .

None

12.1S SUMMARY Detailed requirements ("developer" or "detailed" rcquirements) arc written primarily with designers and developers in mind. They are created from hi g h · level req uirements, as well as from conti nued customer Interac tio n . Detaded requirements must be testable, traceable , and consiste nt. Since they become numerous they must be classified systematically. There are severa l ways to orga nize de tailed requirements including b featu re , use case , CUI , state , and domain class. Agile projects tend not to create documents separate from the code and tests with detailed requirements Detailed req uirements must be traceable to the desi g n and implementation that realize them and to the tests that vahdate them. Without a clean trace from each reqUIrement through the design of the appli atlon to the actual code that Implements it, it is very difficult to en ure that such an app(,catlon remains in compliance with the requirements When the requirements change, which i safe to a sume, this become< even more difficult. Detailed requirements must also be traceable in the o ther direction , to the 11Igh-level reqUIrements they arc derived from , fa ensure that all arc fully specified. Since it is difficult to Implement all desi red functi o nality, requ irement are often prionllzed . Jtegones such as ",roliol, d"irablt . and opilo""1 are used to deSl gn.:e pnOrities. OrganizatI o n, ommit to dd,vc ring essential functionality, and if there is time they Implement desirable and then o ptional feJtu,,:

EXERCISES

Once detailed "'qulrements have been collec ted, the project documents are updated to reAect the improved project knowledge . For example, schedules are updated with more accurate dates and risks arc ,..,tired and more info rmation is learned.

12.16 EXERCISES I. To what audience arc detailed requirements primaril y targeted, 2. Name five wa ys of o rganizing derailed requirements. 3. What is wro ng wirh rhe fo llo wing Derail ed requirement , Ex pl aIn how you wo uld fi x them. a. HomtBudgtf shall di splay a co nve nient interface fo r entering personal data. b. SalCoHlro' shall compute the predicted tim e it takes to c ircl e the Earth o n the current orbit, and the actual time taken to circle the Earth o n the previous orbit. c. /II v<sIKin9 shall determine the best investment stra tegy . 4. What are three advantages and three disadva ntages of o rgani zing delailed req uirements by class rather than by feature, 5. Suppose that you are definin g the requirem ents fo r an applicatio n that simulates the movement of customers in a bank. list fi ve classe, that can be used to o rganize the req uire ments. 6. Provide detailed requirements fo r each class identi fie d in Exe rcise 3 by describong o ne attribu te and one function corresponding to each class. 7. When identifyin g do main classes (as in Fi gure i 2.8), wh y is it usefu l to denote the rel atI o nship between them (i.e., inheritance, aggregatio n), 8. Applying the principle of goo d screen desig n outl ined in Step 3 of Section 12.3 sketch good C UI screens fo r a ho me finan ce applicatio n that , a. displays a summary of a user's fi nanc ial ho ldings, o rganized by ty pe of ho ld,ng, and b. allows a user to input rhe details fo r a new ho ldi ng . r I'sted 'In Exerc ise 6 , assign a priority (e .g., essential , desi rable, I 9. For cac h d etal'1e d requorcmen o ptional ) and explain wh y you chose th em. · '1ar t 0 F'19u re 12.27 Ihat spccines test input and output fo r o ne o f the attribute 10. C reate a c h art SImI identified in Exercise 6.

IEAM EXERCISE

SRS . If YOll are u In s an iterative , t h e SRS fo r your a p pl 'lca rio n · Use o r mod ify the IEEE W rotc .standard " apprQac h , try to .In d 'Ica te what requirement< arc to be Impl emented In each itera tIo n.

329

330

CHAPTER 12 ANALYZING DETAILED REQUIR EMENTS

Tra k the t me SpCIlI o n thi' by individuals a nd by the "roup Hrcak thl ~ tIme Into appro prtate o tl vi ties Measu re the effec tivene, o f you r effort. (Feci free to develop yo ur o wn mctrics, sec also tea m exercises III previou< c hapters ,) Indi ate ho w the pro CS5 yo u u
( I ) Degree of clarity

(2) Exte nt to which the plan includes all relevant del'ai ls and excl ude, irrelevan t materia l (3) EffectIveness o f your <elf· measurement and process imp roveme nt descrtption

BIBLIOGRAPHY I Booch. C r.:ady . "Ob} ,-Qnt'll lcd APlIII)'lls (mJ Dwgtl Ull ih ApplicaIlOrtJ,"Add lso n. Wc",lcy , 1994 1 Jordan, R. hard, Ruth Smllan, .lnd Alex Wilkinso n, -Sut'am IIll1n8 the: Project Cycle with O bJect-Onc nted ReqUIrements,· OOPSLA Co"JruPlcr PfOCttil'"9s ( 1994), pp. 287-300. 3 Cahtz, W , "The ES).t'rl hul Glmle 10 Uw Irt,nfaa Df1j9" At! '"'rOdUf flon 10 CLiI PnrtnplN arlll Tcconufuf1," John Wiley Sons, 1996
uality and Metrics

Planning

The Software Development Lile Cycle

Requlr.II,ents .RIIIy'"

•

What is meant by the accessibility 01 requirements?

•

Comprehensiveness?

•

Understandability?

•

How do you assess the degree of ambiguity of requirements?

•

Consistency?

•

Prioritization?

•

What is meant by the degree of security in requirements?

•

In what sense can requ irements be complete?

•

Teslable?

•

Traceable?

•

What melrics are suitable for these qualities?

Figure 13.1 The context and learning goals for this chapter

This chapter deSCribes measures of q uality In requirements expresses what the customer wantS and needs, the h ighe r Its quality less Important than the "bl!! pic ture ," but a misSing requirements numerous case studlcs show Recall , fo r example, th ove rlooked COnversion that dispatched a $ 125 million spa ecraft to obli Vio n

The \Vle u de tail de ta il

mo re a requireme nts docume nt uall y think of de tails as being far ca n se n ously affect projects , a o f metnc-to- no nme tnc dl>tance

332

f tAPTER 13

Hm

QUALITY AND M ETRICS IN REQUIREM ENTS ANAL VSIS

a ccssible I ~ ca h rcqum.~ rn c nl '

•

· · .. · · •

•

o mprc he nslve I, the SR ) unders tandable I> caLh req Ui rement ) unambiguous IS each reqUIrem en t? onsistent "the R ) effec ti vely prioritized arc the reqUirem e nl<) secure IS the requirement' self·co mplete IS the SR ) testable is each req uirement ( traceable

I S ell

h requirement ]

Figure 13.2 Attributes of requirements analysis that promote Quality

To he lp e nsure that the requ irem e nts are indeed covered, we foclls on qual ll Ie, that requirem ent< should po oss They sho uld be complete and consiste nt; eac h one should be capab le of being traced through to the design and impl eme ntatio n , tested for valid,ty, and implemented accord,ng to a rational pri omy, Figure 132 Iosts these attribu tes and tells what we sho uld look for in good requireme nts. We can systematically revIew and inspect req uire ments based o n thi s li st . For example , a set of co nsistent requi rements is fa r more Iokel y to express wha t stakeho lders want and need than a se t with contradic tions. Th is c hapter disc usses ho w each of these qualities ca n be mea.sllred . "Targe t va lues" refers to the numerical goa ls set in the project relative to various metrics. Metrics are most useful when their target values arc pecihed i. advancr. For exampl e , we could state in advance that , based o n experie nce o n past projects, requirement will be considered ' complete" whco the rate of modinca tio n and addition is less than t percent per week. Projects are greatl y improved when the QA organization is Involved in rhe requirements a nalySIS stage. In particular, QA ve rifies that the intended development process is being execu ted in accordance with plans QA sho uld participate in inspec ti o ns o f requirements docume nts. They tend to have a healthy perspective bec ause they lInderstand rhat they will ha ve (0 validare the product based on the requirements. In poorly o rganized projects, QA may be handed an appl ication with little or no req uire ment documentation and asked to test it Th is begs the question , "what is the application supposed to do)"

13.1 QUALITY OF REQUIREMENTS FOR AGILE PROJECTS Before d,scussi ng the attributes of req uireme nts analysis qualoty lIS ted above, let us discuss the quality of reqUirements for agile processes. Th e primary process for requirements here consists of el iciting user stories

from th e customer, along with acceptance te ts, and then subjecti ng the imp le mentatIon to th ose te t upon completion. In addition , the custo m.er must feel satisRed with the result. Thi s mayo r may no t be supported b significant documentatI o n. Quality has to be assessed , if not measured acco rdon g to th is sta ndard. Th,s entaIl computing the fraction of acceptance te sts passed and making an assessme nt of th e custo mer' rcaclIon. possible via a que stionnaire . Si nce the customer-usually in the foml of a team member rcpre entatlVC' ISo part of the developme nt effort, requirements assessment include the performance of the customer Given the nature of req uireme nts analysis, this is all to the good .

13,2 ACCESSIBILITY OF REQUIREMENTS To deal with a set of req ui rements, we should be ab le to access the o nes we want, when we want them ThIS IS til.
COMPREHENSIVENESS OF

• Ea" of getting

REQUIREME~S

to statement of detailcd requirements .

• Metric: 0, tX'III.tly /o,,!/ aotrag, access Ii",' (compand ",ilb Ih, orga Hizalion, Horm) to: aOtfagc acctss rime as fasf as Ca H be rxptC'tJ

flCUre 13.3 The accessibility of requirements

We do this by num bering them in same way . A good numbering system allows uS to kn ow whe the r the requireme nt has bee n imp le mented , for example, and to trace it to the code that actually carries it out. A projcct's requirements change continually throughout itS life cycle. For example, when a programmer tries without success to implement a requirement and explains this to the customer, the latter freq ue ntl y Rnds mi sing pam in the requirement . The SRS must then be accessed to ascertain whether these mi sing requirements were present, and included if they were not. Taking an example from the video store case study, the CUSfOmer (i n this case, the video store) may question why a DVD's play time does not appear o n the mo nitor. The developers and the customer will want to know whet her this wasspecified in the SRS. Where in that docume nt should they look to determinc this7 Rummaging through poorly organized documents is time ·co nsuming and therefore expensive . H cre is a c hecklist for improving the accessibility of requirements: • Do you know where the h igh -level requirements arc stated7 • Do you know w here t he detailed requirements are lis ted? • Arc the detailed requirements o rganized in groups, preferably with each gTOUp correspondin g level requirement7

[0

a hi gh -

• Are all of the detailed require ments orga nized infO a list, o r a clearly understood Ii t of list 7 • Can you look up requirements by keyword7 By subject matteO By use case7 By G UI ? By uscr type7 • Can you look up requirements by other cri teria relevant to the particular app licatio n o r pfOJec t7 One accessibility metric is the avtragt time ,aken '0 access (J dtta il('d mtuim11M1t. To measure {hi . a sampJt: would be taken of exi ting and missi ng requirem e nts, and severa l people would be timed fi nding these or ascertaining that they are absent. Statistica ll y speaking , 150 is a good sa mple size . Smaller sample sizes are unreliable but are probably better than nothi ng . In selecting a sample , one uses a process that is as rand o m as time allows. For example, o ne could ask eac h of a group of people fa miliar with the pro posed appli catio n to contribute ten potential detai led requ ireme nts, then pick at random fro m the combined hst to obtain samples

to seek. AcceSSibili ty IS summarized in Figure 13.3.

13.3 COMPREHENSIVENESS OF REQUIREMENTS A quality SRS e xpresses all of the require ments fo r a produc t. By co",p"hrns,.""",, we mean the exte nt to ",h i h the customer's wants and needs arc included. An appropriate metric would thus be pcrccIJI"9c oj Ihc cli slomc,S rcq.irrmtllis aPPtJlriHg iHIb, SRS. An o bvio us way to e nsure thi S i to have the ustOl1lcrvalidate it , but th i i not a simple matte r, as the poi nt in Figure 13.4 sugges t. The comprehe nsiveness of requi rements fo rms an elusive and vague goal , and ye t the co",pl e~enc<~ of requirements is key to the successful o mplc tion of a pro lcct and the Ira king of progrc ' Each Itcra tlo n

333

334

CHAPTER 13

QUALITY AND METRICS IN REQUIREMeNTS ANALYSIS

• Not cnotl ~ h resources LO ~a t isf cvC".'ry c.. u\lumer wl.; h • Prlonll zc '0 Ihal cOl11prehenslve within each bat h of reqUirement, • ustolllcr can ttlwon't read en tire RS • I\bkc R J< to lollow • U sc a ,tandard • "Read" SR to custo mer • limitations of self.inspectlons • lIbject to peer Inspe ti o n • Con tradictory s takeholder requirements need to be s. ,isfted • Apply diplomatic kills and expec t compronll<e

Figure 13.4 Issues in attaining comprehensive requirements

make the requirement mo re comprehensive. One way to deal with the evolVing set of require ments is to Include requirements of h,turc iterations and of all priorities In measuring comp leteness. An example IS s hown In Table 13. 1. Thi s perspective helps us to assess how close our plans arc to sa tisfyi ng the customer's wants and needs. A mo re tractable measure is stij.compl","tSS, in which the requ irements contain all materials th at its partS reference. However, this is somewhat different , and is discussed bel ow. Here is a checkltst for improving the comp rehensive ness of requirements: • Summarize, or give a very short preliminary description of needed requirements that have not been

included yet. • Is the customer satisfied that the requirement' reAect all of his or her needs and wishes • What fraction of the listed requirements are slated for implementation in the current release releases )

Future

Figure 13.5 shows two useh, I comprehensiveness metrics . The IEEE define a rather complex measure of completeness in 982 2· 1988 A3S. 1. This is a fonnul. involving 18 observed quantities (e.g ., "number of condition optio~s without processing") and 10 weights (e .g., the relat ive importance of "defined functions used") . It measures the degree to which there are loose ends within a set of detailed requirements.

Table 13.1 Including future requirements Requirement NO.

1780 781

782

Priortty

~

Every DVD record shall contain the title. up to 60 alphanumeric characters

2

3

Every customer record shall include the customer's credit card number, consisting of 16 digits.

1

2

Description

,

..

UNAMBIGUITY OF REQUIREMENTS

Lrt T = total numb~r of documented derailed r~quir~ments (all priorities, all iteration )

ME [RIC: %

Requir~ments ;mpl em~nted

=

100 .. [no. of requirements Implemented]

T

METRIC: %

R~quirements Curr
*

100 [( no. of requirements implemented)+ (no. of top priority reqUIrements in current iteration )]

T Ftgure 13.5 lWo useful comprehensiveness metrics

13.4 UNDERSTANDABILITY OF REQUIREMENTS Understandabi lity appears to be a hi g hl y subjective qua lity because it depends o n peoples' o pIni o n. However, it can be measured . For example, a random set of people from an appropriate population can be asked to express on a form their opinio n 01 a requirements docum ent Table 13.2 is an example of an opinion form-in this case applied to a u or interface . Here is a c hecklist fo r imp roving the compreh en · siveness of requirement s.

• Are the requirements written in language that its ty pical reader would understand7 • Do they use the vocabulary of the cl ient problem domain 7 • Do the requirements describe only external behavi o r-that is, as seen from the user's POlOt of view l ("U ser" can include external sys tems rather than just people .) • Do the requirements avoid stating ',010 the problem is to be solved, what tec hniques are to be used, o r ho'" the application is to be designed7 (The except io ns to this are when such peCl fica tio n are indeed req uited up front .)

13.5 UNAMBIGUITY OF REQUIREMENTS Unless a derailed require m e nt is written cl earl y and unambig uo usl y , we wo,,'t be able to detcmllnc whether It has been properly implemented . Figure 13.6 illustrate an e xa mple of an ambiguous requ lte ment , fo llowed by an Improved version . The o ri ginal requirement seems to allow the player to c hange the qualitIes 01 a ga me character at any time durin g the game This would take the hlO o ut of the ga me , because the player would simply set quality va lues to their larges t possi ble re levant values and there wo uld 1><: little room for tryIng •

various strategics_ Here is a ch eckl iSt fo r improving the no nambi guity of rcqL1lremcntS

• For each reqUIreme nt, IS there o nl y o ne way that

0

ty pica l reader would IOterpre t "

• Fo r each requ irem e nt , arc terms aVOIded that could be underswod

10

mo re than o ne way7

F,gure 13.7 shows a me tric for ambi g uity that de pe nds o n a trioge meas ureme nt deCIde whether the d.:talled reqUIrement ha e xac tl y o ne clear meo ning (score of 2 ), o r mony mca n1l1gs ( corc 0 ), o the " vl
335

336

CHAPTtR 13 QUAUTY AND METRICS IN REQUIREMENTS ANALYSIS

TIlt ~lu rr ",m "(lilt lilt. qurr/lll N of Ell OUl.ltr d)arntl(~

X At

tim e) Prol>,bl

nut. W ould have to te,t under , 11 IrcumStJIl CS, mJny nOt intended , incurnng unn c:tessary ex pense and produ Ing a wrong re,ult all

Better vers ion .

Wb",w" all /orei911 playm Olll(1j'II"19

rh( play,,)

cballg, Ib, q"al,ly

ItWit I

are

ab,,"1 fro", II" arM

Iwrt,

"til,,,, 0/ 'h"

lu, flu

pfaYfr may

ham ''', kuPlll9 Ih,

s'Wn tolal oj 11)( qUf,lily vailllS Iwd){ltIgtd n Jr Playe rQualityWindow , ( " 5«11011 tbd ) is

""d

for Ihis purpo". Chall9" Ink, ,//rel /o14r "collds afl" II" "OK" b,,/loll is press"l. Figure 13.6 An example of ambiguity ,n requ irements

A metric (range: 0 to I 00) 100. 2:: lunambiguity 01 each detailed requirement (0- 2))

2.lnumber 01 detailed ,.quirement.)

o=

could have man y meanings, 2 = clearl y cne meaning

Figure 13.7 A metric for unambiguity

13.6 CONSISTENCY OF REQUIREMENTS A set 01 detailed requirements is cOIISllI",1 if there arc no contradictions among them . As the number of detailed require ments grows, inconsistency tends to become difRcult to detect. Inconsistency is illustrated by the three requirements in Figure 13.8.

Requirement 14. Oilly basic food slapl« sball b,

carri,d by gam, char.elm •

• •

•••

Requirement 223 . f",ry 9am, charael" shall carry wdlu.

. . .,. Requirement 497. Flour, bull". mill!. and sali shall b, co.sid",d ,''' only basic food slapl«.

Fl&Ure 13.'

Example Of Inconsistency In reqoirements

PRIORITlZAnON OF REQUIREMENTS

Means: No contradiction , in whole or in part Example: .,

...

..... The DVD

~

classificatlon order shall be the order of preference of the customer. ...

OVOS shall be classified alphabetically as drama.

comedy, ho"or .....

Metric: Percentage of contradicted requirements Figure 13.9 Consistency in requirements

The object·oriented style of organization of requirements helps to avoid inconsislenCle by classifying detailed requirements by class and by decomposing the m in,o a si mpl e form This IS not a guarantee of consistency, however, and so requirement inspections include a c heck for consi ,ency. H ere I a checkli , for improving the consistency of requirements, • For each requ iremen" are there olher requirements that could lea d

'0 co ntradicting or annulhng i,)

• For each requirement , are there other requ irements that arc very similar and so can reate Inconsislencles?

• Does each requirement avoid a chair. of conseque nces tha, ca n', be readily fo ll owed )

A consistency metric is Ih, prrc,"lag, oj d,lail,d rrq llir",,,,lIs partly or wholly cOlllmd,clcd r/5<whrrr. T o ob,ai n such a metric, one would consider a sample of de ,ailed requirements - I 50 would be appropria,e-and investiga,e each one in tum determine whether i, is co ntradicted elsewhere in ,he document.lllis en,ad, comparing" to all of the remaining detailed requirements . Figure 13.9 prOVides ano,her example. This measure is imperfect because it accounts on ly for pairs of Inco nSIS tent reqUIrements A Figure I 8

'0

illustrates, inconsistency can fesult (-rom a se t

of requirements

13.7 PRIORITIZATION OF REQUIREMENTS Since qua lily is ultim ate ly de Aned by customer sa lisfacllon, the re qUirements ana lysIS proce, "con tinuall y directed toward the customer's conce pl of sa ti sfacll o n . T eams 'YP lca ll y show stake holders Interim a com· plishments, and stakeho lders then IIlnutnce lhe course of the work accord ing ly . Be ausc of thIS. ,h,' priority of requ ireme nlS and thus the order In which requirements arc Im plemented , as de cnbed III hapter 12makes a SlgniAcant d iffere nce in the custo mer's sa ll sfa tion In math ematical lan guage, ,hi IS a non · commutat ive operation si nce the SRS seque nce impttP1m1f rcquirrmrll l A (hen pllHf fa Implnllcnl

frqUlrCII1(Ht

B

rC'qulf('moll

A

may well produce a dilferent produc t from irnplrmOl I rrquJrcmtnf H then pi,," 10 ,,"plnnrll'

337

338

CHAPTER 13

QUALITY AND METRICS IN REQUIREMENTS ANALYSIS

-''>lIme three prioml zatl o n . IJlgIJ, In,Jium , and low Me tn Vanatl o n fro m . IJi!lb = • ,"til""" = • IOlv Let T = to tal number of de tail ed requl ,cmems

100. [T -IT / 3 - l1I gh l - IT / 3 - nledium l-IT /3 - lowl] T

o=

worst; 100 = best

Figure 13.10 A metric for measuring the quality of prioritization

There are effective and ineffective prio riti za tio ns. Fo r example, g iVing most req uirements the hIghest pn o rity Indicates poor planning. Ranking low . prio rity requiremenlS IS usuall y a waste of time because they are unl ikely to be all im plemented. As me ntio ned , when stake ho lde rs see the Impl eme ntatio n of reqUIrements, they tend to change subsequent requirements. An effective priori tizat ion tries to account fo r these faccars

H ere is a c hecklist fo r improvi ng the prioritization of re q uirements. • Is it clear what requirement sho uld be worked o n (irst] Seco nd ) • Arc the prio rit ies at a hi gh level consistent with th ose at the detai led leve l) • Is there a pnoritlzation process in place such that it will remain clear what is the ne xt importan t requ irement

that sho uld be wo rked o n) • Is the prioritization appropriately matched with customer expectations?

• Is the prioritization appropriately matc hed with project risks? As ume that each req uirement is in o ne of three priorities. H ow would we measure the quality of the prioritizationr

A good quality prioritization categorizes requirements into equal parts, indicating that no

category has been neglected. Figure 13. 10 sho ws a metric fo r this. For example, if 900 requirements arc very well prio riti zed, each category would contain 300 requirements and the fo rmula would g ive 100 . [900 - 0 - 0 - 0 V900 = 100%. O n the o ther hand, if 700 were classified as h igh priority, 100 as medium and 100 as low, the me tric would yield 100. [900 -1300 - 7001-1 300 - 1001-1300 - 100111900 = 100' 100/900 = 11.1 % Th e low percentage indicates poor prioritization.

13.8 SECURITY AND HIGH-LEVEL REQUIREMENTS Security ca n be dea lt with a an actual (explicit ) requirement or as on at~ributo of require ments. For example. "All passwords shall be unavailable except to the system administrato." I on explicit requirement of an application. On the other hand . 'The requirements in our SRS will cause (ewer than 10 security brea hos of level I or greater (defined elsewhere) in a century of COntinuous operation under the threat e nvII'Onmcnt of 2009" is not a requirement in the ordinary sense. It is an attribute of the requirements. Security In requirements is a special case in that It deal s with deliberate explOIts o n the p.ln of o the l'S to misuse It. Traditional requirements, after aH, are intended to specify what an application sbowlJ do, and have not

SEl.F·COMPLEI ENESS OF REQUIREMENTS

.ddJtssed misuse. This i changing . To an increasing extent, requirements documeOls are addressing the security ~ by including such content as misus< casts. These arc similar to the idea , me ntioned earlier, of inverse requirements. The following are examples of misuse cases use cases that the system is required to disallow. An automated user of the application eMters a known user ID and more than 10 password per second. A user accesses more than 30 customer records in a si ngle si tting and transmits these to another address within 10 seconds of accessi ng the m. Here is a checklist for improving the security aspects of req uirements, • Consider the places in the pro posed application where intrusion appears to be possib le. Are concrete security requ irements stated fo r those places] • Has the conRdentiali ty of data, where applicable, been specificall y required] • Has the security of user identiry been speCified] • Has the security of passwords been ex plicitly call ed for] • Has the ownership of Rles or access been speciRed ] • Has encryption been called for when appropriate l • Have speCific, known security exploits ("hac ks") been speCified aga insO An example is "SQL Injection shall be prevented." (SQL injection is a mea ns of unautho ri zed database access.) Ha ve speCific and po tential exploits been speciRed against vi a misuse cases]

13.9 SELF-COMPLETENESS OF REQUIREMENTS TypiCally, a requirement depends o n o ther requirem e nts. A set o f requirements is " If·com plttt If it contai ns every part whose inclusion is necessi tated by parts already present. Figure 13 II illustrates an incomplete et of «quirements. Without the speci Rcatio n of how a video is to be "displ ayed," thi s se t of requi rements is incomplete as a unit. As anothe r example, suppose that the SRS for a ca le ndar application contai ns the fo llowi ng requi rement.

Th, applicalioll ,hall rttain all ",jormatioll t>ltrrrd by tht "'" jor tach appoilltmtllt.

REQUIREMENTS I. Tht applicalion lhall di,play a DVD ill slock Ivbtll a lilk i, mtrrrd at Iht prompt, ot""wi" il ,IJall di,play

"OUT OF STOCK. " 2. Tht applica llon shall display all oj Iht ,10"" DVD, by any dirtclor whost las t namt i, ", Iurd at Iht promp t Thts< ,hall bt di,playtd Ollt by 001t Advall ill9 tlJrollgh Iht DVDs ,hall bt con lrolltd by Iht lorward artOI/1 kry I'..:o",pktt: Lacks s pcc ,f, atl on o n how to display a videol Fi&ure13.11 An example of self·lncompleteness In requirements

339

340

CHAPTER 13 QUALITY AND METRICS IN REQUIREMENTS ANALYSIS

'\

h~n

J

rc"QlIIrCI1lCnt I~ pre se nt,

,n mu~l tJlI tho~c

nc e'SllJled h y II, pre'en e A mcln

(0

= best, I poor, no theoretical upper li mi t)

[number of mi ssing necessa ry associated requirement s]

Inumber 01 detailed requirements present] Figure 13.12 A metric for self·completeness

The prese n e of th is requirement ncce sita tcs a requirement describing means forentcnng apPointment information

meaning

It also necessitates a reqUirement explaining means (or displaying this Information . TI,is IS the

01 "sell-completion ." Here is a c hecklist lor improVing the sell-completeness 01 requ iremcnts

• For eac h requirement stated, are all th e requirements prese nt that it rclers to] • For each requirement stated , arc all the requirem e nts present that It depends on ] To measure sell·completen ess, we look a t each detailed requirement and note any necessary associated reqUirement that is missing . An appropriate metric is shown in Figure 13. 12 .

The number

01 miSSing requirements is determined by sampling.

13,10 TESTABILITY OF REQUIREMENTS Each detailed requirement must be leslablt; that is, it must be possible 10 definitely validate that the requirement is operative in the finished app lication by testing lor it. Figure 13. 13 provides an example 01 a non testable requirement, and sh ows what it would take to make the requirement testable.

TI" sysl,", shall display Ibt differolCt ill salary b,lw,," Ib, clioll mid 1/" worldwidt aocra9' for Ih, snmt Jradt.

X

ca n't be tested because the average mentioned cannot be determi ned (even th oug h it exist ).

Better;

Th, syslt'" sl,a/J display 1/" d,f}","" ill salary b,lwtrll Ih, eli",1 alld II" "Iimaltd loorldwid, .",ragt for Ih, ,am, Irad, as ~"blishtd by Iht Ulliltd Nalloll' Oil {IS Web ,ilt www.tbd al th, limt of Ih, display . Figure 13,13 An example of testability

•

TESTABIUTY OF REQUIREMENTS

Table 13.2 Example of a user satisfaction questionnaire User satisfaction

o = of no value; 5 = average satisfaction; 10 = a pleasure to use Quality

Score

1. OVerall appearance 2. Layout of text areas 3. Layout of buttons 4. Readability 5. Ease of entering data 6. Degree to which erroneous data entry is prevented • •

•

• • •

Requirements that are no t testable arc of negligi ble va lue. It would be impossible to assess whether such a requirement has been attained. This is an all·or.no th ing property. The re is lit tle value in the "degree of testability" of a requirement. Testability can sometimes be used to specify a detailed C UI requirement. Fo r example , instead of specifying a CUI in complete detail we may prefer to provide a test suc h a the following , The CUI for entering DVDs shall ha ve the Rclds and butto ns listed in figu re xx, and its deSign shall score an average of at least 8.5 out of l Oon the user satisfactio n questionnaire In Table 13.1 . An effective way to ensure testability and to ensure the clari ry of a requ irement at the sa me time is to include tests with the requirement. Figures 13 . 14 and 13 . 15 illustrate an example. Agile programming applies this test orientation but sho rt ·ci rc llit's the prose by e ncodin g the test up front , usi ng it as a requirement, in effec t . A reasonable testabil ity me tric IS the fo ll owi ng,

The percentage oj dr,ailed requi"",en" ,ha' are accompanied by a '" , Even when a requirement is tes table , executing a test may be d ifficult o r time-co nsum ing. T o be complete, we sometimes need to consider the cos, oj as part of the considerati o n. A very h igh cost

',,'i"9

The video store app lication s hall impl eme nt a discount program as follows, • • • •

One DVD , no di scount Two DVDs, 20% d isco unt fo r the second DVD Three DVDs: 40% di scount for the second and th ird DVD All videos beyond the th ird are dl counted at 40% . 13.14 Including tests witlh requirements, 1 of 2- the requirement

341

342

CHAPTER 13 QUAUTY AND METRICS IN REQUIREMENTS ANALYSIS

I 2

U\lo me r

we" Jo nes re nt, o n ' OVO He b c hJrl(ed the rq!ul. r rc nt31 o( $ 5 00

ustomer T r re," Edward, re nts two OVO, $4 00 (20% d" ounl ) (o r the e o nd .

he i, c h3rgcd th e rc~ul ar rel1t31 o( $5 .00 fo r the f,m and

usto me r ll,eodo re L, sl renlS Ihree OVOs He, c harged the regul ar re ntal of $500 for the nrst, $4 00 (20% d,s ounl ) (o r the second , and $3.00 (40% d i ount ) (o r the thIrd . 4.

usto me r Fred Harari rent < !lve OVOs. He IS c ha rged Ihe re~ul a r re ntal o ( $5.00 (o r the first, $4 00 (20% di s ount) for th ~ seco nd , and $3.00 (40% d, s o unt) (o r Ihe third. The fo urth and nfth OVOs are harged at $3.00 (40% dlScot'"t ).

Figure 13.1 S Including tests with requirements 2 of 2- Ule tests

inAuences our c ho ,ce and pnoriry of requirements. For example, suppose that we cons,de r adding to our online video service the follOWing requirement:

Fo r each movie entered by the customer, the appltcation shall di splay a number from 0 to 5 that provides the ystem's estimate o( how much he will like the movie . This e t,mate 's based on the , .. .

customers past viewing ratings .

ThIS can be tested, but the expense of doing so properly ma y d,ssuade us from making it a hi gh prio ri ry Reco mmendation algorithms have become a competitive activity amo ng providers, with large rewards provided fo r the creators o f the most (measurably) effective ones. like this one, many requirements are strongly associated with business decisions.

Here i a c hecklist for improving the testability of requirements, • Is Ihe requirement clear enough to devise inpu t/output data samples lhat exercise it) Specify the tests. • Is there a set o f tests that, if passed. provides significant confidence that the requirement will have bee n satisfied? • If one reasonable person in the cuSlomer community proposed a set of tests for the reqUIrement, would another probably agree that it tests the requirement?

13.11 TRACEABILITY OF REQUIREMENTS T raceabiliry was defined in Chapter 10. Our concern here is how to measure a .et of requirements in th, respect. A requirement is traceable if it maps in a completely clear manner to the design clement that accommodate it. the code that implements it, and the tests that test ,t . \'(Ihen the 0 0 or "class" organizat ion o( requirement writing is used, the mapping to the class within the des'gn and to the code can be comple tely clear. It requires work and clear th"'king to mainta", such clariry, however. For e ample , a Cuslolll" paragraph that speCifies the rentals that each customer can have could compromise traceabili ry The design would probably have the clas«, C""O'"" , DVD, DVDRrtJlnl , and DVDRrnlnls. The requirementS orgal1lzallon should reAect this. Organizing cla.scs by funclIona lt ty, CU ls, use cases, and so on has vanous advantages, as dis u sed "' Chapter 12 , but traceabiliry is 110t a strength for most o( them . One would have to pen,« cach deta,led requirement and ask whe ther a will clearly map to a class.

METRICS FOR REQUIREMENTS ANAlYSIS

(Range: 0 to 100) tOO'

L: [traceability of each detailed requirement (0 -

2)J

2 . [number of detaIled reqUlrementsJ 0= untraceable, 2 = clearly traceable to a specific class F1gUre 13.16 A traceability metric

Here is a checklist for improving the traceability of requirements: • For each detailed requirement . is it clearly conceIvable that an ide ntifiabl e part of the code base will Implement it? (It's ideal when a single method implements a SIngle deta ded requirement. ) • Is it clearly conceivable that a ing le, identifiable pan of a software design ..nd implementatio n could contain itl (A detailed requirement that must be spread over several probable main modules is not easily traceable. Traceability can be measured as in Figure 13. 16. Usi ng 2 as a measure allows the appl,catio n of triage for a give requirement , where 0 = u,,'raccablt, 2 = Jldly 'ra ctablt , J othtnVlst .

13.12 ME I RjCS FOR REQUIREMENTS ANALYSIS The previous sections of thi s chapter described metri cs for a number of requirements qualities , acceSSIbility, comprehensiveness, understandability, unambiguousness, consistency, deg ree of pri omizatio n, secu rity, se lfcompleteness, testability , and traceabi lity_ Additio nal metrics ca n be considered . The fo llowing li st of quality assurance metrics includes requirements analysis metrics in IEEE Standard 982.2-1988 ("IEEE Cuide for the Use of IEEE Standard Dictionary of Measure to Produce Reliable Software"). Some measure the qualities we have already discussed in a different manner. • Percentage of unambiguous speCIfic requirements (IEEE metric 6) • Degree of completeness (IEEE metrics 23 and 35 ) • Percentage of misdassined detailed requirements (in the object. oriented sty le, thIS measures the percent· age allocated to the wrong dass ) • Traceabil ity (IEEE me tric 7) • Degree of atomIcity (indIvisible

1010

smaller parts)

• ConSistent with the re mai ning reqUIrem ents (IEEE metries 12 and 23 ) • Measures of the effectiveness of reqUIrements inspectIon • Percentage of missIOI! or defec tI ve requirements found per hour of in spection • Musures of the effectIveness of the requirements analy is proces • Uxt per det-a ded reqUIre ment • On a gross baSIS (!'Ota l lim e spen t/number o f dctoded ,.eq ulfe mcnt ~ )

343

344

CHAPTER 13 QUALITY AND METRICS IN REQUIREMENTS ANAL VSIS

• 0 " a In a"~ ,,,al b"" (

oq

10

He t one more)

reqlllrcrncnb arc

- rnodifled - elimlnaled - added •

1easure of the degree of o mpl e tcncss of the requIrement, . ThIs can be e't lmated from the rate, after the official "nd of dctarled requirements collectio n, a t whic h specIfic requrrem e nts are . .. - mod ified - added

13.13 INSPECTING DETAILED REQUIREMENTS The reader is referred to C hapter 5 for a descriptio n o f the inspection process In general. Detailed requirements are the Arst software process documents that ca n be inspected agarnst pnor docum e ntatio n (the h igh.level requirements). Inspectors prepare For the inspection by reading over the hIgh . level requirements and companng the detailed requirements with them. It ca n be very productive to Inspeci requ ireme nts against each of the qua lities and metrics listed above . The rest of thi s section proVides an example of a detailed requirements inspection. H e re is an un inspected versio n of detailed require ments For the Encounter video game case study o n which we will perfo rm an example inspec tion, entering the results in a table (see Tabl e 13.3 ). We empl oy the technique of auto mati cally adding the "no t inspected yet" comment to each . It is removed when the inspectio n takes place. The Anal versio n of these requirements, re sulting from the inspecti on, is shown in the accompanyi ng Encounter case study.

Arm R'4u ir"''''11 I ("Art. name"). (Not inspected ye t) Every area shall ha ve a name of up to t 5 characters.

Art. R'4uir"""11 Art. object.

2

("Art. image") . (Not inspected ye t) There shall be an Image in gif fo rm to display each

Art. Rr4ui"'''''11 3 ("Display area method") . (Not inspected yet ) Whenevcr a player character enters an arca, that area and the c harac te rs in it shall be displayed. Art. Rr4uir"""11 , ("Courtyard object"). (Not inspected ye t) There shall be an Art. o bject with name "courtyard: Its image shall be that shown in Figurc xx o n pagc xx. Art. Rr4uirrmrnl 5 ("Dressing room object"). (Not inspected ye t) Therc shall be an Area object with name "dr<ssing room" and blank background image. The dreSSing room shall be adjacent to the courtyard area.

Encou,,'er Rr4uirrmrr,' f ("Engaging a foreign character"). (No t inspected yet) When an engagement takes place, the Following computation IS performed, The sum of the values of qualities of a game char.Jcter relevant to the area in question shall be refcrred to as the characters area value. (In this release, all qualities will cou nt as equal.) In an cngagement, the system compares the area values of the characters and ITan fer< to the stronger, hal fofthe points of the weaker. For example, suppose the pl.yer cn!!ages a foreign character In an area requiring stamina and attention span, and ps is the value of the player's stamrna, et . A Imlog p., + p. > f, + f" wewould have p,' = P. + f/ 2, Po' = p. + f/2 , F,' = (,12 , fo' = f/2 where xl is the vallie 0 x.fter the transaction.

Table 13.3 Example of a foml used for the Inspection of detailed requirements Traceable forward Note 14

NO.

Requirement Description

Traceable backward

Comprehensive Consistent

Feasible unambiguous

Clear precise

1001

Area Requirement 1

Note 2

Note 1

Yes

Yes

NO 1

Yes

NOl

N02

No 1, 2

Yes

1002

Area Requirement 2

Yes

Yes

Yes

Yes

N0 3

Yes

No3

Note 3

Yes

Yes

1003

Area Requirement 6

Yes

NOle 5

Nole 5

Yes

N03

N03

NO S

Yes

Yes

Yes

1004

Area Requirement 3

Yes

Yes

Yes

Yes

Yes

Yes

NOle6

Note 3

Yes

Yes

1005

Area Requirement 4

Yes

Nole 7

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

1006

Engagement Re.9ulrement ,

NOle2

Yes

Yes

Yes

Yes

Yes

Yes

Nole 3

Yes

Yes

1007

Encountercharacter Yes Requirement 1

NOle 1

Yes

Yes

No 1

Yes

NO 1

N0 2

No 1, 2

Yes

1008

EncounterCharacter Requirement 2

Yes

No 11

Yes

Yes

Yes

NOl e 8

Yes

N06

Yes

Note 9

1009

Encountercharacter R~ulrement 3

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Note 3

Yes

Yes

1010

EncounterCharacter NOle " R~ulrement 4

Yes

Yes

Yes

Yes

NOle 12

NOle 12

No 7

Yes

Yes

1011

EncounterGame Requirement 1

Yes

Yes

Yes

Yes

Yes

Yes

NOle 13

Yes

Yes

Yes

Yes

NO8,9

Yes

Yes

Yes

1012 1013

Yes

foreign Character Requirement 1

Note 11

Pla~er Character

Yes

Yes

Yes

Yes

1015

VI

m

Plaler Character Requirement 2

Yes

Pla~er Character

Yes

Requirement 3

-z

."

Yes

Yes

Yes

Yes

Requirement, 1014

Modifiable Testable

Yes Yes

Yes Yes

Yes Yes

No 12 NOle 10

NO 10

Yes

NO 12

NO 12

Nole 10

Yes

Note 15 Nole 3 Yes

Yes NO 12 Yes

Yes Yes Yes

n

:::t

z

C> 0

~

... ~ m

0

'"Dmc -m '";::: m

~

VI

~

346

CHAPTER 1J

QUALITY AND METRICS IN REQUIREMENTS ANALYSIS

Ell 0,,"1, I),,,,, I" R,qlll"'","1 , ("Name of ga me haracld '). (NOI ,nspecled yel l !- very game charac tcr ,n lhe En o U/ncr video ga me shall have a uni que name o f up 10 15 chara l e r~ E" 0""1,, I ,",' c har. ler has 1001n, where pa lie n C, and

Rrq,,;rrmn"

("Qua lities of !;,me charac lers''). (NOI Inspec led yel l Every game lhe same scI of qual ,.lies, each having. floating pOlin value These arc In'tialized 10 n is lhe Ilum ber of quali lies. The qua l'lie, are allentiOn 'pan , endurance , intelligence, strenglh . I"

1

E" 0,,"1, l>araelrr R,qlllrtl","1 J ("Image of game h.racler" ). (NOI In spe ted yel l Every game character w,lI be shown uSing all image that lakes up no mo re lhan 1/8 of the monilOr screen Elleo,,"lrr IJaracl" R'q,,;rnllClI I < (,'Engagemenl wllh foreig n haracler") . (Nol lnspcctcd yel l Whenever an Encounler ga me charac ler enters an area con lai ning anol her ga me c haracler and one of lhem is player. controll ed, lhe player c harac ler may either chao e or be obliged by lhe ga me to engage the olher characler \XI' hel her lhere is a c hoice o r not is co nrro ll ed by lhe game in a random way o n a 50% basis Elleollt"trGam, R,qlll"mClII Encou nterGa me objecl.

("Encounter game objec!"). (NOI

I

In

pecle d ye t) There shall be a Si ngle

("Freddie foreign characte r object") . (NOI inspecled yet ) There shall be a foreig n c haracte r named "Freddie," all of whose qualities have equal values and whose Image is shown in Figure 4.57.

FOrtl911Charaeltr R,q"",m,"1

I

PlaytrCh.,.eltr R,qlllrnllcIII

I

("Conngurability"). (NOI inspected ye ll Whenever all foreign players are absent fro m an area , the player may set the values of his o r her qua li ties us ing the PlayerQuall ty. Window , as long as the sum of the qual ity values rema ins lhe same.

Play,rCharaclrr RC4" irtnlCllI

("Main playe r character") . (No t inspecled yel l The player shall have complele control over a part icu lar game character called the main c haracter.

PI.yrrCharaelrr R'4"irCltl""

2

("liVing points") (Not inspected yet). Encounter shall produce lhe sum of the values of lh e charac ler's qualities, ca lled its livi ng points. J

We will show ty pical results of an inspection of these requirements. O ne inspection comment aboot thiS sel as a who le is that the requirements do not support enough expansion of the game into a competitive product. A more particular defect is that the requirements do no t properly specify lhe delay involved in settin g a player's quality va lues, during the delay the player is subjected to an engagemenl in an unprepared state . (If the delay is too small , the player simpl y se ts the qualities required fo r the area as high as possible and lhe game is not much of a challenge.) Let's inspecl the list of proposed detailed requirements one al a time Table 13.3 IS an example of a form that can be used for lhe mspection of detailed requirements. applied to the above list. Most of the melrics preVi ously described in lhi s chapter ca n be computed fro m th is table The table co nta ins "Notes" and "No" notes. H ere are the "No" no tes, I. Can a game character or arca have a name with no c ha racters? 2. The number 15 IS rigid. 3. Only o ncl 4. If the player controls several characlers, arc all of their areas 10 be displayed or does this have to do onl ' with the mam playe r characte r?

SUMMARY

5. Filling th~ cntire monItor screen7 6. It should ~ "asler to add new qualities o r remove them . 7 When is there a Freddie7 When does he appear7 S. In future releases, characters may mutate. 9. Clarify what stays the sam". 10. Can th" value of a qual ity be negative7 II. Ambiguous, because the player can't contro l everything that happens to the main character at all times .

12. Refine "complete contro1." The "Notes" are as follows , I. Is any k"yboard character acceptable7

2. Check validity with the customer. 3. It is unclear how modifiable this shou ld be. 4. It is hard to answer "complete" because it is unclear. See the note referenced in the "Clear" column fo r the issue. 5. We assume that the customer has some leeway in exactly what the "courtyard" will look Ioke . 6. Are there dressi ng room exits to any other area7 7. This is somewhat clumsily written, could lead to misunde rstandi ng . S. It is usually preferable to have a si ngle requirement match each attribute. Thi s doc not appear necessary, as the qualities will be treated alike. 9. Produce at any time] On request7 Show at all times7 10. These details arc not mentioned in the high · level requirements, check with customer. II. Clarify "50% basis," if possible.

12. For Internet versions, it may become necessary to have more than o ne instance of an EncounterGame object. We will not exclude this possibility in future iterations. 13. It is not clear in what directIons this could be modified. 14. Is the requirement wrinen in such a way that it will be possible to trace it through to the code that implements it7

13.14 SUMMARY The quality of a requirements document is reRected in how well it expresse customer wants and nec:ds. T o hdp ensure that requirements are of high quality, we focu s o n attributes the y shou ld posses . TI,ey Include the follOWing: • AccesSIble • Comprehensive

347

348

CHAPTER 13

• L1nJ",bl ~u •

QUAUTY AND METRICS IN REQUIREMENTS ANALY IS

liS

on~ls t cnt

• Pnontlzed •

cure

•

e1 f·complc te

• Testable • Traceable Requircl11enrs arc Inspccted aftcr they are writtcn . They are the Ar t softwa re process documents that can be inspected against prior documentation (the customer reqUirements). It ca n be very productive to Inspect requirements against each of the attributes listed above.

13.15 EXERCISES 1. (This is intended to bc a closed book exercise .) list the qualities that requirements should possess

(o ne example · precise). In your own words, dcscribe the meaning of each . 2. Explain why the following requirement fo r a book sa les site is ambiguous. Modify the reqUirement to make it unambiguous. "Orders that include speCia l edition books and overnight delivery or exceed $ t 00 must be processed ove r the phone." 3. Provide an exa mple of three requirements for an order entry system that are inconsistent . How would you modify thelll to make them consistent? -I . For the order entry system in Exercise 3, provide three requirement

that are not testable, and expla in why each is not testable . Provide a modified version of each requirement to make it testable.

5. Your instructor will pair up stude nt project teams. Conduct an inspection of the other team·s detailed requirements. Evaluate thc requirements against the list of metrics described in thi chapter Prepare a table such as Table t 3.3 to summarize your results.

Formal and Emerging Methods in Requirements Analysis: An Introduction Online Chapter

14.1 PROVABLE REQUIREMENTS METHODS 14.2 INTRODUCTION TO FORMAL METHODS 14.3 MATHEMATICAL PREliMINARIES 14.4 THE Z-SPECIFICATION LANGUAGE 14.5 THE 8 LANGUAGE SYSTEM 14.6 TRADE-OFFS FOR USING A B-LlKE SYSTEM 14.7 SUMMARY 14.8 EXERCISES

To access this online chapter please visit www .wiley.com/cottege/braude.

principles of Software Desi n

Planning

/:

Maintenance

•

What are the goals of software design?

•

How do you use various design

models for a single application?

Testing

The Software Development Life Cycle

•

What are use case model , class models, data flow models, and state models?

•

How are frameworks used in design?

•

What are the IEEE standards for

RequIrements

IIfI8IWsIs Implemelltation

-.;:::

expressing designs?

DMIgn

•

How does a team prepare for design in practice?

Figure 15.1 The context and learning goals for this chapter

A ·sorrware deSIgn" is a representatio n, o r model . of the software to be built. Its purpose is to enable programmers to implement the requirements by desi g nating the projected parts of the implementation . It i a et of document containi ng text and d iagrams to serve as the base o n which an application can be fully programmed. A complete software design should be so explicit that a programmer could code the application from it without the need for any other document Software des. g ns arc like the blueprints of a building that arc sufAcient for a contractor to build the required budding. They can be understood in two parts: high · level desig n, often referred to as ' software archite ture: which is ge nerall y indispensable, and all other design, referred to as "detailed design ." It can be beneficial to make designs very deta iled, short of being actual code. Th. is becallse engineers can exam ine a derailed design for defects and improvements prior to the creation of code rather than examining

THE GOALS OF SOFTWARE OESIGN

only Ih~ code The beneAts of a fully detaIled desIg n arc balanced agai nst the time: required to document and maintain detail~d designs. For large elfo"s, level s in between high level and detailed desIgn may be identified This chapter introduce the concepts, needs, and terminology of software design. It sets the stage for the ~m.jning chapters in thIS pa" of the book, whic h include various co nc rete examples.

15,1 THE GOALS OF SOFTWARE DESIGN The first goal of a software design IS to be sufjimtll for atlsfying the requirements. U ually, software designs muSt also anticipate changes in the requ irements, and so a se ond goal is jlrxibi/ily. Ano ther goal of software design IS rohosllKSS: the ability of the pro duct to anticipate a broad variety of input. These and other goals are summarized in Rgu~

15.2.

These goals sometimes oppose o ne anot her. Fo r example , to make a de ign effiCIe nt il ma y be necessary to combine modules in ways that limit Aexib di ty. In fac t, we trade off goals agai nst each other in ways that depend on the project's priorities A software design is sujlie;," 1 if it provi d es the compo ne nts for an Imple me nta tio n that satIsfies the rcquirements . To assess such suffiCie ncy , o ne needs to be able to understand it. This fact is obvious, but it has profound consequences. It can be d ifficult to create an understandable deSIg n for applications due to the large number of optIons that are typically available . Open Office, for exa mple, is a ve ry comple x applicatio n when viewed in complete detail. Yet Ope nOffke is simple when viewed a t a hI gh level, as consisting of a few subapplications: word processing, spreadsheet, presentations, and database. Modulnr;1y is thus a key to understandability . So ftware is modular when it is di VIded into separalely named and addressable components. Modular software is muc h easier to understand than mo no lithic software, and parts can be replaced without affecting othe r parts. It is easier to plan , develop, mod ify, document, and «-st . \\:'hen software is modular you can more easily assign different people to work on differe nt part . A design is a form of communication. In its most elementary form , it documents the res ult of a des igner's thought process, and is used to communicate back to h imself thereafter when he needs to know wha t he designed. Thi s IS fine if the designer is to be the o nl y person who has this need , but a projec t usuall y Involves several people throughout its lifetime . If a design is not ulldm lolldnb/, fo r them, it IS of lim ited val ue, and the project's health is at risk. Design implification , in particular, frequentl>' results in a better de ign . Understandability is usuall y achieved by o rga nizing the design as a progression fro m a high level w ith a manageable number of parts, then increasing the detail o n the parts. A good software archItect and designer forms a clear mental mo de l o f h ow the appl icati on WIll work al an ov"allievel , then develops a decomposi tion to match thI S mental mod e l. She firs t asks the key modularity

• • • • • • • • • • •

Sufficiency: handles the requ irements UndersliJndability: can be understood by intended audience Modularity: divided into well -de n ned parts Cohesion: organized so like- minded clem e nts are grouped together Coupling: organized to minimize de pende nce between elements Robustness: can deal WIth WIde va ri ety of input Flexibility: can be r<:adiiy mo difie d to handle c ha nge in reqUIrements . Reusability: can u e parts of the desig n a nd implementation 111 o the r app ll ca ll o ns Information hiding: module interna ls are hIdde n from ~tl:ers EffiCiency: executes wi thin acceptable lime a nd <pace IlInlts Reliability; execute< WIth acceptable fa dure rate 15.2 Principal goals of software design

351

352

CHAPTER 15 PRINCIPLES OF SOFTWARE OE51GN

=

High cohesion (parts belong together)

Component

Low coupling (mInimal contact)

Figure 15.3 High cohesion and low coupling-bridge example question such as: What Rve or six modules shou ld we usc to decompose a personal nnance applicatIon) What four or five modul e neat ly encompass a word processi ng application ? After decIding this, she turn ' 0 decomposing the components , and so on. This process is sometimes ca ll ed "recursive design " because i, repeats the design process o n design compone nts at successively fine scales. Software decomposition itsel f involves consideration of cohrsioll and couplillg. Cohesion within a module is the degree 10 which the module's elements belong toge,her. In other words, " is a measure of how focused a module is . The idea is no' just 10 diVide softwa re into arbitrary partS (i.e., modularity ), but 10 keep related issues in the same pa rt. Coupling descnbes ,he degree to which modules communicate with ot her mo dules. The higher the degree of coupling, the h arder it i 10 understand and change the system . To modularize effectively, we maximiz, cobtsion and 111illimizr coupling . Th is principle helps to decompose complex tasks inlO simpler o nes. Software engineering uses Unified Modeling u.nguage (UML) as a principal means of explaining desi gn. Understanding softwa re design concepts by means of analogous physical artifacts is helpful to orne, and we will employ this mean on occasion . Figure 15.3, for example , suggests coupling/coheSIon goals by showing an architecture for a bridge, in w hich each of the six components has a great deal of coheSion and where the coupling betwee n them is low. The parts of each bridge component belong together (e.g., the co ncrete and the embedded metal reinforcing it )-this is high cohesion . On the oth er hand, each component depends on just. few o,her components two or ,hree , in fact. This is low coupling . The "Steel truss" III F,gure 15.4, on 'he o,her hand , shows many component dependIng on each other at o ne place. We would question this high degree of coupling.

Component

High coupling

Figure 15.4 A Questionable architecture high coupling In a truss

X

•

lliE GOAl S OF SOFlWARE DESIGN

• Oblilinin.9

,"Ort

or

',,5 oJ wi,.,., alrtady prm,,'

Example: handle more kinds of accounts without nceding to change the existi ng design or code • Adding "tw killd, oJ Jllllcliollalily Example: add wilhdraw to existing dtposil function

• Cha"ging j""Cliollalily Example: allow withdrawals to create an overdraft

fl&Ure 15.5 ASpects of flexibility: ways in which an application may be required to change

Low coupling and high cohesion are particularly important for software design because we rypica lly need to modify applications on an ongoing basis. Compare the life cycle of a typical software application with that of the bridge in Figure 15.3: the likelihood that the software will require mod ,Rcatlon is many time greater. Low coupledlhigh cohesion architectures arc far easier to modify, since they tend to minimize the effects of changes. The number of top-level packages in an architecture should be small so that people can compre hend the result. A range of "7 ± 2" is a useful gUideline , although specinc projects ca n vary greatly from tim range for special reasons. As an example, OpenOfnce would be hard to understand if we decomposed it into 100 parts instead of four as follows : "word processi ng, spreadsheet, presentations, and databa e." The mind has much trouble thinking of 100 separate things at more or less the sa me time. The difference between small - and large-scale projects (such as OpenOfnce) is the amount of nesting of modules or packages. Projects rypica ll y decompose each top -level package into subpackages, these into subsubpackages, and so o n. The "7 ± 2" guideline applies to each of these decompositions. A design or implementation is robll" if it is able to handle miscellaneous and unusual conditions. These include bad data , user error, programmer error, and e nviro nmental conditions. A design for the video sto re application is robust if it deals with attempts to enter DVDs with wrong or inconsi tent information, or customers who don't ex.ist or who have unusuall y long names, o r if it handles late rental situations of all kinds . Robustness is an important consideration for applications that must handle commUnication . The requirements of an application can change in many ways, and as a resu lt a design must bejl""blt to accommodate these changes. Fi gure 15.5 illustrates ways in which an application may change. A set of previously used drsi9" partm" is a useful resource for flexible designs. DeSign patterns are discussed in Chapter 17. We design so t·hat parts of our own applications can be rr"ltd by others and ourselves _ Figure 15.6 lists the rypes of artifacts that often ca n be reused .

We can reuse .... • Object code (or equivalent) Example: sharing dlls between word processor and spreadsheet • aas~s in sou rce code form Example: Customer class used by several applications Thus, we write gene ri c code w henever possible • As~mblies of rdated classes Example: the java.awt package • Patterns of class assemblies

FIlii,. 15.6 Types of reuse

353

35'

CHAPTtR 15 PRINCIPLES OF SOFTWARE DESIGN

cI""

A an example of I." reli'>c, o n
15.2 INTEGRATING DESIGN MODELS The architectural drawings o f an of~ce bUilding comprise th e fro nt eleva tio n, the si de elevation. the electrical plan . the plumbing plan . and so o n. In o ther words. several diffe rent views are req uired to express a bUlldlng's arch itecture. Similarly. several different views arc required to exp ress a software desig n. They are ca lled modds Four important models are shown in Fi gure 15.7, and they are expl ai ned next. Several ideas here are taken from the Un iRed Software Develo pment me thod o f Booch. Jacobson. and Rumbaugh. Figure 1includes an example fro m the Encounter video gam e case study to illustrate the four models and how the fi t together. The subseque nt sectio ns o f th is chapter elabo rate o n these mode ls so that they ca n be contra ted and combined with each o ther. Subsequent chapters in th is parr of the book prOVide detailed examples of each

15.2.1 Use Case Model This section describes several levels o f use cases and related concepts. The " , follOWing four parts:

ClISt

",odd conSIStS of the

I. The ,,", i"61 " SC CQStS : a narrati ve fon11 . suitable fo r devcl opcr. to ·cu to mer commun i ation, descnblng the required basic sequences of ac tio ns

INTEGRATING DESIGN MODELS

To express requirements, architecture, and detailed design Use case model

Glass model

"00 this ... •

"wffh objects of these classes .. .' e.g .. with Engagement .. . classes

e.g.". engage foreign character

Target Application

State model

Data flow model

~reac t;ng

"'in this way ... ..

e .g .. character scores flow from .. . to ...

to these events ,.,.

e.g .. when foreign character enters • Video game example

Figure 15.7 Models to express deSigns (and parts of requirements) 2. Their re fi nement into regu lar u" cam. descnbed in Chapter I I 3. Their transfo rma tio n into "qu"'ctdiagrallls (covered in Chapter 16). which in rurn ca n be in stages of re fi ne me nt:

twO

successive

(a) With informal functionality desc riptio ns, at first lacking all details (b) With specific functio n names and howing all details

4. SCOtarios: instances of use cases th at contain specifics. and that can be used for testing. For example . a scenario of the use case step

( uslomtr cboosts accounl would be something like

John Q Smilh choosts ch,eking acco",,'

1234 5 .

The usc case model e xpresses wha t the applicatio n is supposed to do. as suggested In FIgure 15.8.

15.2.2 Class Models Classes are the building blocks -mo re preCisely, the ty pes of budding blocks of deSIgns Cia . mo dels consist of paekagts (a groupi ng of clas es ) that decompose Into smaller packages. and 0 on. whIch dccompo c Into classes. and these, in turn . decompose primarily into met hods. Thl IS shown in Figure 15 .9. We cover doso;cs in more detail in Chapter 16

15.2.3 Data Flow Models

The class modd descnbes the kind, of objects Involved; It does not show a

n,C

tual objects dalll jlo.' ,"oJd, o n the olher hand , shows specdi o bJcc t< and the type of data fl oWIn!! between them It IS related to the cia ,

355

356

CHAPTER 15

PRINCIPLES OF SOFTWARE DESIGN

Uso cue modol : BUlin•••

------------

u•• c•••

U.. ce.. ~ ; ~;

~; ~;

~~

~

~

~

~

~

~

~~

e laborated by _.

~~

Sequence dl.gram

r------------1 Target Application

Scenario.

I

Class model

..

State model '

Data flow model Figure 15.8 The role of use case models in design

model , because the objects invo lved must belong 10 the classes III the class model. We discuss data flow d,agrams in C hapter 16. Fi gure 15 . t 0 shows the parts of a data Aow model.

15.2.4 State Models Sta te models reflec t react ions to eve nts. Events incl ude mOllse ac tions and c hanges in variable va lues. Events arc no t described in class mo del s or component models, but they do occur in the state model. We in troduced sta tes in Chapter 11 as o ne way to describe the requirements of an application . The states in that conte xl describe the external behaVIOr of the application . The states we arc referring to here reAect the state of

Use case model

Class model

I

Package

~"

Consists

,,

of ...

Cla.s Terget Application

Data flow modol

State model

'--

Figure 15.9 The role of class models In design ~ JIt(;U:l5on. lVII, "Object oriented SOltwMe Englneerlna: A I.M case

DI'iven Approach," Addtson·wesley. 1992

FRAMEWORKS

Use case model

1 Class model

Target Appllmlon

Data flow model

State model

Processing eta"le"t

organized by ...

,,

~----1 ,

,,

,,

"

,

Data type

I

Data store

I

Subprocesslng eleonant

Figure 15.10 The role of component mOdels in design $OUt't'e.:

1aCObson, IVar, " Object Oriented Software Engineering: A use case Driven Approach:' Ad<3!son·WesIcy, 1992.

Use case model

Class model Target Application

Component model

State model : "reacting to these events "

I

States

~n------1

Substates

decompose Into ...

I

Transitions

I

I

Figure 15.11 The role of state mode ls in design Sourt:e: Jacobson, rwr. "ObJect Or~nted SOftware Englneenng: A use case Driven Approach, " AOdrSOfl·Wesley, 1992. elements in a software design . The role of stare mo del s is shown in F.gu re 15 . 11 . n,ey are described in more detail in Chapter 16 .

15,3 FRAMEWORKS

As we have secn, the rruSt of compo ne nts is a major goa l in so ftware development . If an o rga nization ca n't leverage its investments in the ski ll of it designers a nd programmers by usi ng their work severa l times over, competitors who do so will be faster to market with superior produc ts. Th e parts of an application that are particu lar to it and arc not reused arc often ca lled Its bus11ltsS log'c. Bus iness classes arc es ent.ally the doma.n classes d.scussed In Chapter 12. Where do we keep the lasses slated for reuse] H ow do we orgaOlze the m] Shou ld we build.n rela tlonsh.ps among thesc classcs] Do they control the application or does the app ilca no n co ntro l lhem ] n , e computlOg

357

358

CHAPTER 15

PRINCIPLES OF SOFTWARE DE IGN

--;::"=.-::...=-:..-.., - . -., ,.-. Aenloilioms

~u._._

Rontals

- -, RenialCuslomer$

'-_.

..

- --.~-.-

---

_...._ .. __

.R._~._

.-

•

'"

•

---~

Figure 15.12 A framework for rental applications

community ha learned from experience that merely making a list of avadab le fun ctio nality docs nOI necessanly result in reuse . We have learned . however, that arrangements like the Java AP I (co here nt se ts of classes) do indeed lend themselves to highly successful reuse. The Java AP ls (3D, 20, SWing , etc.) arc Jramrworks . A Jrm"rwork , sometimes ca lled a library, is a collection of software artifacts usable by several different applications. These ani facts arc typically implemented as classes , together with the software reqUired to utilize them . A framework is a kind of common denominator for a fami ly of applications. Progressive development o rganizations designate selected classes as belonging to their framework . Typically. a framework begins to emerge by the time a development o rganization develops its second to founh application . As an example , consider the Renlal fra mework shown in Figure 15. 12 that our video store application could use. This architecture divides th e clements into the items that can be rented (books, DVDs, etc.), the people who can rent them , and the rental reco rds that associate members from the first two pans. The individual classes in the fra mework will be suppl ied later. Frameworks like these are usually obtained in a combin ed botto m·up and to p .down manner; boltom .up by examin ing the tructure of actual application architectures such as the video store application, seeking more general forms; and top·down by conceptualizing about the needs of a particular family of applications such as rentals. Classes within a framework may be related. They may be abstract or co ncrete . Applications may use them by means of inheritance, aggregation , o r dependency. Alternatively, as we wil l see below, a framework may feel like a generic application that we customize by inserting our own pans. Figure 15. 13 shows the relationship between framework classes, domain classes, and the remaining design classes. The design for an application consists of ( I ) the domain classes (that are special to the F•• hb.wortlcl•••••

,---------I I I I I 1M dfJ,.,1ed "u/gn

I I I

I

/ The CI,•• Madl' .."

"'1 I I I I

I

DMIgn

cI8....

: I I I I I I I I 1

I

L _________ _I

Flpre 15.13 ClaSS model VI. architecture and detailed design

SUMMARY

1. Inb Oductlon ..' 1.1 Purpose ArchltectUN 1.2 Scope ,• '" ' .'. 1.3 Definitions, acronyms, f .... and abbreviations ! •• • • 2, ReleNnce.

• 3. Decomposition description

3.1 Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decompoSition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description

4, Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies 5. Interlace description 5.1 Modute Interface 5.1.1 Module 1 description 5.1.2 Mod ule 2 description 52 Process Interface 5.2.1 Process 1 description 5.2.2 Process 2 descri ption 6. Detailed design 6.1 Module detailed design 6.1.1 Module t detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data e ntity 1 deta il 6.2.2 Data entity 2 detail

figure 15.14 IEEE 1016·1998 SOD example table of contents

application ), (2 ) some of the fram ewo rk classes (generall y speaki ng, no t all are needed ), and ( 3) the remaini ng classes needed to co mplete th e design , w h ic h we are call ing simpl y "desig n" classes. The design classes consist ofthose required fo r the architecture and th ose that are not. The latte r a re effectIve ly the detai l design classes, requ ired to comple te the d esig n. These three co nstitute th e class mo d e l fo r th e application . All of the domain classes are in the de ta iled d esig n because th ey are very specinc. The fra mework classes used are part of the application's architecture. The framework classe s used in th e desig n a re part of an a ppl icati o n's arc h itecture , as show n in the figu re. The domain classes are usuall y part of th e d e ta iled d esig n si nce they arc speCific to the ap pl ication and are not architectural in nature .

15,4 IEEE STANDARDS FOR EXPRESSING DESIGNS The IEEE So ftware D esig n Docum e n t (SO D ) sta ndard 10 16· 1998 provi des guid e lines for the documentation of design. The table o f con ten ts is shown In Figu re 15. 14 . IEEE guideli ne explain how the SOD could be organi zed fo r va n ous arc h itectural styles , most of w h ich are deSCribed above . The case study uses the IEEE standard, WIth a few mo d ifica tio ns, to account fo r a n e mphas is o n th e o bject·on ented perspective As show n In F'gu re 15 14, Sections I t hrough 5 ca n be co n id ered software arc h itecture , and Secllo n 6 ca n be considered the detailed design, to be covered in th e next c hapter.

15.5 SUMMARY Softwa re desig n 's a mo d el of the ,ntended oftware appllca " on , as spc , Aed by its req uire me nts A software design is analogous to the b luepri nts of a house. Good software designs should ex h,b,t the fo llowing c haracteri tI d; , u nders tandab diry, modu lar· ,ty, high cohesion , low coupl, n!!, robust ness, flcX lb d,ty, reu,abi l, ty, ",forma tio n I" di ng, err, ,en y , and re habll l!}', Whe n expreSSI ng a software dcs l!!n, ill S he lpfu l to use evera l d iffe re nt conne ted VICW , or mo dels use .. se model de nbes what the app hcatlon I< ,ntended to do from the po,nt of view of th ~ 11 er _ eql1en e

359

360

CHAPTeR 15 PRINCIPLES OF SOFTWARE DESIGN

d,agra m< arc de ri ved fro m u\e a es and de< rlbe ubJecl' and the
•

<.:ustom tzal Ion.

1S.6 EXERCISES I . Write a pa ragrap h deSCri bi ng what a "so hwa re de ig n" is, and why it IS impo rtant . 2. In YOllr o wn wo rds, defi ne th e goals of software desig n and ex plai n why each goal is important. 3. In yo ur own wo rds, de Ane the fo ll OWin g term s; nl odufnrily , coh" io" , and coupli"g. Why is each a desirable property of software designs7 4. Ca n a design be cohesive and exhibit a high degree of coupling7 Explain your answer and provi de an exam ple .

5. H ow might coupl ing and reusability be relatcd7 H o w might cohesion and re usabi lity be related7 Explain your answer and provide o ne example fo r each . 6. In your own wo rds, expla in what is meant by robus/II"' . Belo w is code fo r a meth od dioid,(). Make the method mo re ro bust in at least two ways.

public double divide ( Double aNumerator, Double aDenominator ) {

return aNumerator. doubleValue ( ) / aDenominator. doubleValue () ; }

7. U si ng the Internet, research o ne of the many Java API framewo rks (e .g., Sw ing, JMF, 20 , 3D ) In a few paragraphs, describe the design of the framework and how it accommodates re u e. 8. Provide a modulari za tion fo r an appl icatio n that advises clients o n stock picks, and enables them to tra nsfer funds am o ng vari ous stocks and savi ngs accounts. Expl ai n yo ur solu tio n. Hi" k One reasonabl e solutio n employs fo ur packages.

Language

Planning

y

- j Maintenance

•

Whal is Ihe UML notalion lor classes and packages of classes?

•

How does UML represenl class

relahonships such as Int:lentance,

• The Software Development Life Cycle

Requirements analysis

aggregallon, and dependency?

•

What IS a sequence diagram?

•

How do UML achvily diagrams relale 10 lIow charts?

088lgn

Figure 16.1 The context and learning goals for UliS chapter

Reca ll that a "software des,gn" I a reprcolrw.re to be budt For many yea" SOftware engineer rel.cd on a miomewhalllnrc ialeci graphica l mca n for gc u",J.C acro" the pOint of thcor designs Their prln Ipal mcans were data now diagrams, lIow har", and wa s to p'CILIre Ihe locallon of phY\Jca l nics These wcr never vcry all,fac lory W,lh the adve nl and ""de accep lan c of obJect-onented methods , leader"> In the \o ftwar{' engineerin g communlly begJn to poo l :lnd rd i1tc th eir ,dcJ\ for notJtlon Jnci

gra phical reprc ~c nt a tl o n of oftwa re deS ign, la<"" , lor exa mple , now needcd I" he rq I'l' chapter we ,"troelu e the UML, wh, h " now a Widely accepted , IM~ d y w.p h,Lal nOta lion lUI CXpr SS ln!! "bJect.onentcd de"w" The lI t- IL standard" nu n'J.;cd by the nonproil l bleL t i\lanagcmcnt

362

CHAPTER i6

THE UNiFiED MODELING LANGUAGE

Canister ~-- Class name / _- -..- n-u-rn""'C"'a- n-;l""' st:e--rs-:7In"t- - numWafers: int - - Anribute: type .. :Vlsible . size: noat Irom without .. dlsplayO ~_ _ Operations , _ ' . getNumOpenSlotsO .. setStatusO ResponSibilities: -- describes each

canister unde rgoing fabrication

Place for ~--

comments

Figure 16.2 Class details in UML

Croup consortium of compa nies (www.o mg .org ), and ta kes hundreds of pages 10 formally specify. As a result, UML tends to be incl usive (some say too muc h so), incorporating da ta flow and , in effect , flowcharts; but It contains much more that we do not have s pace in this book to include . The part> that we do cover, however are adequate for m ost of o ur needs . UML is an excell ent ste p in the direction of imp roving software engi neering, but wi ll probably be improved upo n as the d isc ipltne evolves. The c hapter describes class relatio nships in UML, includin g inherita nce (Class Models, Section t 6.2 ) a wa y to represent control among fu nc tio ns (Seque nce Diagrams, Sectio n 16 .5 ), diagrams of state , events, and transitions (Section 16.6), its moderni zatio n o f fl ow c harts (Ac tiv ity Diagrams , Sec tion 16 .7 ), a nd finally data flow diagrams (Sectio n 16 .8 ). Section 16 .9 shows an exampl e that combines these.

16.1 CLASSES IN UMl Classes in UML are represented by rectangles o ntain ing the class name at a minimum . The detailed version includes attribute and operatio n names, signii Nres, visibility, return types, and so o n. Figure 16.2 shows a clas from the detailed design of an application that controls the Aow in a chip man ufactu nn g plant of canisters holding wafers Not all of the attributes need be specified in the class model. Wle show as much detai l as nceded, neither more nor less. Showing more deta il clutters a diagram and can make It h arde r to understand. Some required attributes may be left 10 the discretio n of the implementers. It is also commo n to o m it accessor hrnctions from class model (e .g ., gelSiu() and sctSize()) si nce these can be inferred from the pre ence of the corresponding attributes (,m). As an example of a class , co nsi de r an application tha t as ists the u er in drawing a Simple figure of a person using geo metric shapes. We'd probably want a Rectangle class for this with attributes such as 'm9th and h".dlh. Since the app licatio n is supposed to be smart, we'd want it to use the concept of a foot (e.g., to kno'" where feet bel o ng), so we'd probably want a Foot class. By int rodUC ing these c1asse , we arc improVing the cohesion of related parts, such as the attributes of a foot , the understandability of the dl" Ign , and ,ts mo dularity . W e are also hiding information until it's needed . Thi example will be explored a \~e go through this c hapter, and will be described as a whole in cetion 169

16.2 CLASS RELATIONSHIPS IN UMl This sectio n discusses the way In whIch UML collec t< cla«es and such rel.tionships call ed associations.

In

packages It .lso inllod" es

CLASS RELAnONSHIPS IN UMl

and

" ,

pllClulge of classes

-"

.. -

myPackage

mySubPackage

.

" '-

-

class MyFIrstClass ( ... )

'w,, _ •

1

MyClass

.I·

....,_ . .

_..

-•

package myPackage.mySubPackage; class MyClass ( ... )

subpackage / - hidden-

MyFlrslClass -'

./

Bcccess/blllty of classes from outside package -'---

IC visible »

•

public package myPackage; class MySecondClass ( .. . )

-,

MySecondClass

/

~

Figure 16.3 UMl notation for packages and Java implementation

16.2.1 packages The U nified Modeling La nguage uses the te rm Pllckng, for collecting desig n elements suc h as classes. UML packages can contain subpac ka ges , or an y material s associated with an applicatio n, Includ ing source code, designs, documentati o n , and so o n. Figure 16.3 shows the UML nota ti o n for packages a nd sub packages. Classes within a package can be speCified as access ible o r as inaccessi ble fro m code external to the package. "Package" also happens to be the nam e of collectio ns of Java classes. Java packages trans late into file directories; thei r subpac kages decompose into subd irectories, and so o n. The Java implementation of this is shown in Figure 16.3.

16.2.2 Associations Attri butes arc o ne way of sh owi ng the properties of a class, and arc ge nerall y used to de no te si mple types such as integers o r Boolean s. Msocia lioll is an additi o nal method of indi ca tin g clas properties, and is commonly used to denote that objects of two classes de pend on each other in a strucnlra l way . ASSOCIations are drawn with a solid line belween two classes. We ca n a nnota le th e relati o nsh ip, which may be o ne- o r two·way . Twoway associa tions are problematical because we nee d to be sure lhat bo th e nds of the implied info rmat io n are kept consistent. This is illus trated in Figu re 164 . Consider a n application that a Sl tS the use r In drawin g a Sim ple fig ure of a person . We ma y want a FooISb.", class if the sh ape of a foo t needs to be described (promoting the "sufflclc ncy" of the design ). There wouJd be an association between FoorShap, a nd FOOl , indicat ing coupl ing be tween the two Th is example i described as a whole in eClio n 16 9

363

364

CHAPTER 16 niE UNIFIED MODEUNG LANGUAGE

employs

~

Employer •

IS

employed by

,---il

Employee

class Employer ( Employee! J employees; •

• • • •

) class Employee ( Employer! J employers; •

•

• • •

)

Figure 16.4 UML notation for associations

/

16.3 MULTIPLICITY The ends of an association line can be annotated wirh "lI/hipliClty, which describes the numerical relationship. or the number of instances, of each class. For example , consi der the Employ"IEmploy" relationship as shown in

Employ" indicates that each insta nce (object) of an Employ« can be assoCiated w ith 1-3 Instances of an Employ". Conversely , the " I. .• " next to E"p/oy" mean that each instance of an Employer can be associated with a minimum of one Employtr (with no maximum ), In ocher words, the Fi gure 165. The "1..3" next to

I

multiplicity next to a class indicates how many instances of th;n class are associated with one instance of the class at the other end of the association line. A single value ca n be used to indicate an exact number of objects,

If a multiplicity is not present neXl to a class, the assumed value is I . This is also illustrated in Figure 16.5 , which shows that one Employee

IS

associated with exactly one PcnoPlalInfo instance , and vice versa.

16.4 INHERITANCE In UML, illbmlancc desCribes a relationship between classes in ..... hich o ne class assumes the attributes and operations 01 another It is often thought of as an "is·a" rdation ship. Forcxamplc, since an

Employ" "i.-;," Pm"" , we can express their relationship with inheritance by saying thal an Employee inherits from a Person . U"I,L

Employer

employs

1..3

•

~

is employed by

1..•

Employee

, Personallnfo Figure 16.5 Multiplicity of associations In UML •

INHERITANCE

... and

"'-

MyPack8ge package MyPackage: abstract I MyAbstractClass . . . . MyAbslraclClass ---I-~Inheritance

package MyPackage: class MyDerivedClass

MyAbstractClass

r l---. int atl; •

• • • •

void myFunctlon( ReferencedClass r ) (

•

00

)

}

MyDerivedClass an: Int

- - attrllwte

Lm2yF:..u:::n.::c:.:ti::o:.:n~()_....::.°cperatlon

""':::===:::'_-"'/

Figure 16.6 Inheritance in UML and Java implementation

indicates inheritance with an open rriangle. We refer to the class being Inherited from (e.g . PmoH ) as a basc class, the class dOing the inheriting (e.g .• Em ployu ) is a d"ivd class. Figure 16.6 shows an example of a package consistin g of two class. ; MyAhstractClass and MyOmv,dCla ss . with MyO,rivcdClass inheriting from MyAh,tractClass . Abstract classtS-that is, those classes that ca nnot be instantiated into objects are denoted with ital ic . [H !!ifacts are collections of method prototypes (name, parameter ty pes. retum types, and exceptions thrown ) Classes rraliu interfaces by implementing the methods that the interface promises. The UML notatio n IS shown 111 Figure 16.7 It is customary to arrange class models 0 that base classes are physicall y above derived cia se H oweverl this positioning is not necessary in any technical sense .

UML Notation ......

Interiace MyAbstractClass . ...

Interiace

,~ --- - -- - - - -------~, : Mylnterlace :, : myMethod()

.

i

'------7\..------' --------

rsallzsllon I

class MyClass imple,ents Mylnteriace

,,

(

-----------------.. • • • • •

)

I I MyClass myMethod()

Fllllr. 14.7 Interfaces In UML and Java Implementation

365

366

CHAPTER t 6

THE UNIFIED M ODELING LANGUAGE

on
16.4.1 Aggregation Aggrr9alion IS a type of a soci al ion Ih al can be Iho ug hl of as a w ho le- part re lalio nshi p . It IS d e no led wi th an ope n diam ond nexl 10 th e aggregat o r (wh o le ). Agg regalio n ind icates Ih e Slruc lU ra l Inclusio n of objects of o ne cl ass by ano th er, and is usuall y imple me nted by mea ns of a cl ass (w ho le ) ha vi ng a n attribule whose type is the Incilided class (part). Agg rega tio n is sho wn in Fig ure 16.8, w llh bo th Company and Employ"Dirrclory each co nsi der
I

belween Fool and FoolSbapr probabl y turns OUI. mo re specificall y. 10 be an aggregatio n of FootShapt by FOOl. T h iS exa mple is descri bed as a who le in Sec ti o n 16.9

t

16.4.2 Composition Compo' i/ion is a stro nge r fo rm of aggregati o n in wh ic h th e aggregated o bjecl exists o nl y duri ng the lifetim e (and fo r the benefi t o f) th e composi ng object-n o o lher o bject may refe rence it. T he composed obJecl is created and destroyed whe neve r Ihe composi ng objecl is creal ed and de
Company

---

1:

{

Elhpk,yse amp;

,

---

aggreglltlon

-

dB'S

EmployeeDtr. "tory

/\

amp

{ Employee amp;

in! 811; )

'\ ~-

dass Company

•

•

"-

/

• • •

I

Employee

•

emp

my Function()

•

I

aggreglltlon

att: int

f.-..

I

101 a1l;

EmploveeOlrectory

• • • • •

)

att: int

/

"

myFunctionO

fllu re 16.' UML representation of aggregation and Java Implementation .

1

INHERITANCE

Company

composition

att: int , , , , , , , , , , ,

myFunctionO

Employee

,,

• composition

~

/

/

/

emp

"

/ dass Company

class Employee emp: { }

...

• • •

EmployeeDirectory

class EmployeeDirectory { class Employee emp:

{

(.

att: int

. .)

myFunctionO

• •

}

• •

•

•

•

}

/

/

/

/

"

Figure 16.9 UML representation of composition and Java implementation

16.4.3 Dependency

Drp",d",'Y,

denoted with a d o tted line arrow, means t hat o ne class depends upon another In the sense that if

the class at arrow's end were to chan ge. then thi s would affect the dependent class Stnctly speaking, dependency Includes association, aggregation . co mpositio n , and inheritance. However, these relati o nships have their own notati o n , and we usuall y reserve dependen cy to indi cate that a metho d of o ne class utilizes another class, and to relate packages. Thi s is shown in Figure 16. 10.

Dependence: UML Notation ... and ... Typical Implementation MyDependentClass att: int

u

u

•• u

••

_

u u

MyReferencedClass

u

• dependence

myFunctionO

f-------"";"

(reference to s class)

cl... MyDependentClass ( • • • • •

void myFunctionl( MyAelerencedClass r)

•

( • •• )

I

_ _ _ . _ _ __

t.

, --

paramete,

I

MyAel.rencedClass myFunction2( ... )

( . .. )

I

- , - - -- -' or relum type

void myFuncUon3( ... ) I MyAeferencedClass m ...

)

·~I_______ ~~~

~

or local variable type

)

Figure 16.10 UML reprcsentatlon and Java Implementation of dependence (excluding Inheritance and aggregation)

367

368

CHAPTER 16

THE UNIFIED MODEUNG lANGUAGE

CustomerMailAppllcatlon

customer

goneraleMaliO getCuslomerTypeFromUser() malnO

CuSfomor

1

eleateMallO

r ,,_ I

I

... - - _

--,

',--

I

I

,

""

I I

""

- ---

DelinguentCustomer

MountalnCuslomer

createMailO

crealeMaliO

--- ---

--

RegularCu stomer creat.Mail()

Cus1omerMailApplication

generateMaliO getCuslomerTypeFromUserO malnO

customer

1

Customer eleateMa/tO

Figure 16.1 1 Exa mple of a class diagram (class model) for a customer mall application

16 .4.4 Class Diagrams Class diagrams help us to vi,ualize the des'gn of applicatio ns. They describe the ty lX"S of objects in the application, thm amibutes and ope"'tions, and the sta tic rciatio nsh ips between them I l l. Co nSIder an applica tio n produCIng e· mail text fo r various kinds of customers. A possi ble UML class diagram IS show n in Figure 16. 1 1. It says that the class ( uslommvlmlApp"Ca llo" has a variable named customer, which is of type Customer. Since ( £Islam" is abstract, the custom" va nablc IS either a DclmqunltCuslomrr, MOttntainCU51omcr, or RtgularCuslom« When nUlomcr.ma frMnil() is called, o ne of the three versions of crwfll\1ailO is called, depending o n the class that cu, 'omer belongs 10. The stre ng th of class diagr.m s is that they help us to envisage th e buildtns blocks of an application . Note , howeve r, that they do no t indicate the way in which the appli cari o n execu tes. In the C usto me r Mail Appl ica tion class model , fo r exa mple, there is no way to tell w hat me th od execu tes after mai.t(). Sequence dtagrams, d iscussed in Sectio n 16.5, prov,de this capabi lity .

16.4.5 Object Diagrams An object diagram shows objec ts and th ei r relat ionships. A n objec t is a particular realization of a class , so

object models arc dCTlved from class model s There .re many possi ble o bject model s deriving from a class model. Fo r example, let's retum to th e class mode l in Figure 16.4 . Figure 16 . 12 ho ws o ne objec t mo del that derives from it . Wh c:: rc::as class models are compile -time rel atio nships, object model s are us ua ll y runtime: relationships. Figu re 16. 12 shows that the o bject njaxCorp Co,"pa"y employ th e objects ,"c,Employ« .nd joe, Employ« It .Iso sh ows that the o b ject ahcCorp·Compa"y employs th e objec t Joc.Em ploy«.

16.5 SEQUENCE DIAGRAMS

Use cases arc a good complement to classes because they de fi ne steps through wh,ch a use r and an ap pltcation transi tion . To use them i n design, however. we refine them into a more:: technical fann So that class and

methods that enable them can be ident,fied. In .ddition , there arc many «que nce of 'C(,on ' th.t applications

I

SEQUENCE DIAGRAMS Class Model

IEmployer I

t ..n

1..3

IEmployee I

One Particular Derived Object Model

sue:Employee ajaxCorp:Employer jjOe:Employee abcCorp:Employer Figure 16.12 Example of a class model and a particular object model in UML derived from it

need to be designed for but are not use cases. The number of possible sequences o( (unction ca ll s even common ones-is very large, whereas the number of use cases is kept relativel y small (4- 20 (or small jobs and at most hundreds for extremely large ones). Sequence diagrams are graphical represe ntati o ns o( control Aow, and are particularly useful for describing executions that involve several object" as found tn the sce nario of a u e case. Sequence diagrams rcquire us to think tn terms of objects and funct io ns. The lifctime of each object involved is shown as a solid vertical line, with the name of the object and ItS class al Ihe top . Each tnl eraclio n between objects is shown by means o( a horizontal arrow from the objecl initiatJng Ihe service to Ihe objecl sup.plying the servicc. As an example we develop a sequence diagram (or Ihe Ch"k 0 141 use ca e for Ihe video store appl ication. Figure 16. 13 shows a beginning sequence diagram (or Ihe usc case. Note 2 Clerk

Originates 'rom use case:

:MainScreen

:BarCodeReader

bar code 2. Applicalion prompls

1. User swipes

order

for rental duration 3. User enters duration ...

doCheckoul0

:Checkoul0ptionDisplay readO I

Step 1 01 use case

NOle 3 :Checkout

,

Step 2 01

usecas8

InltlaleO Note 4

NOle 1

I

ShowO

I I I I I I I

•

flcure 16.13 Beginning of a sequence diagram for Check Out use case In Video store design

369

370

CHAPTER 16

THE UNIFIED MODEUNG LANGUAGE

The (01l0w\I'8 no te explain the cOlTCspol1ding (ca tllrcs o ( the d,a grn rn ' a te I · In a
o tc 2 U sc cases Jrc 1Illtliltcd either by the use r, as thi S o nc IS, or by (In o bj ec t I nitiation bcgin at the to p Icft of the dia g ram , a nd a solid verti ca l linc be neat h thIS sy mbo l IS drawn to ,nd,ca te that thc e ntit ), alread y eX ists W e ca n uppl y preconditions to specify assumpti o ns that apply at the incep t ion of the ,equencc. Note 3· cqllc ncc diagrams sho w the initia ti on and execution

or il sequence or functions. The

obj ec t at th e be gi nning of each arrow {t1 ilra lC5 work , the objec t a l [h e en d of the arro w ca m(s Old the

wo rk 0 1 th e me th o d Ind icated . Eac h clo ogated recta ng le den o tes the execu tio n of a meth o d o ( the ccrrc~ pondlOg o bject In o ur Ch,ek Q", seq uence diagra m, the clerk initiates the seco nd (un c tion by swipin g the bar code reader over the VIdeo. \Vle then determ ine w ho o r what should execu te th e respo nd ing function . Since a

bar code reader recognizes a swipe, we may decide that a Bar od,Rtadcr o bject would be approp riate (or d ealing With actions relat ing to the ph ys ical re ader, and th at th e requ ired fun ction o( Ba,Cod,R,adcr will be nam ed "adO. There will be o nl y one BarCodcRcadcr objec t (or the entire application, so the no tat io n ",BarCodcRcadcr" to rep rese nt th is o bject is su(RcierH . There is no need to nome a BarCod,R,adcr object; we ma y deCide la te r to make the "adO method o( 13a,Cod,R,adrr static, in whic h case no actua l BarCod,R,adrr object would be invo lved Note 4· We can ca pture the c h eckout process with a Grekoul class. The BarCoJ,Rcadrr o bject then c reates a Grekoul o bject. We h ave used a fac tory meth od iHiliat' O here to create and initia lize the

:MainScreen

User

I

:BarCodeReader

:CheckoutOplionDisplay

doCheekoutO

I

1.

:Checkoul

II

:Account

I

2. t inlliateO

2.2 ereateO 2.3 showO 3. setDuralionO This sequence diagram originates from Use case:

t. User swipes bar oode 2. AppllC8tion prompts lor rental duration 3. User enters duration 4. AppllcaUon

stores record

5. Application prints C\Jstomer's account status

--

Figure 16.14 sequence diagram for Check Ouf use case In video store design

4.

storeO

I

I

SEQUENCE DIAGRAMS

Player

ncounter

Game

Ireddie: mainPlayer· ForeignCharact er Character. PlayerCharacter I I I I I I I create and display I move

I I I I

create and display move

I

U

figure 16.1 S A sequence diagram showing concurrence

Chtcko"t object. The method j"jtlat'() then creates a display for choosing checkout optio ns and shows it on the co nsole . A comple le sequence diagram for the usc case is given "' Figure 16 t 4. In the previous sequence diagrams, the solid arrow head indica te s)"I(I](ollo"s method ca ll s, meaning that the caller receives control back when an operation is comple[c. Sequence diagra ms show aSYJlcbrollous

messages using either stick arrow heads o r half·arrows. An asynchronous message means that the caller does not wait for an opera ti o n to complete. InSlead, control returns immediatd y back to the caller and th e result . if any, is processed at a later time. The called method executes in a separate thread, either by spaw r.ing a new thread or executing wi!hin an existing thread. The elongated recta ngle at the end of the arrow represents a thread that executes in parallel. As an example , we migh t want the game characters of Encounter to move independently from area to area during the action . This is shown in Figure 16. 15 with both a PlayrrClJaractrr and ForrigilCharactrr runn ing in epa rate threads . Figures 16. 16 and 16. 17 summarize the steps needed to create a sequence diagram . When the initia to r is the user, a simple label at the to p suffkes, rather than a rectangle. Note that the object responsi ble for executing the method named o n the arrow is at the O ld (no t the begin ning ) of the arrow. 1. Identify the use case whose sequence diagram you will build (il applicable) 2. Identify which entity initiates the use case - lne user, or - an object 01 a class

." . "... . ..

myObject :M Class

'

'

• name thO ob;oct, if posSJb&e

"

3. II not the user. draw a rectangle to represent Ihls Initiating object at lelt toP .. ........ .. .. , • - use UML ob/«l:C/sss notallon ~ ~ : 4. Draw an elongated rectangle beneath this to represent ' Ihe execullOn 01 the operation I n ~iating Ihe process • • 5, Draw an arrow pointing right Irom it • •

'.

Fl&ure 16.16 Steps for building a sequence Oiagram, 1 012

•

371

372

CtiAPTER 16

THE UNIFIED MODELING LANGUAGE

operation initiated

.

myObJeC1 1 ;MyClass l

myObJect :MyClass

6. Identify which onilly handles tho

I I

.... ..

- an objOCI 01 a claM • l'\llmo Ihe Cl.lss

ClPOra6onO

• name tM OOIOC1

7. Labellhe arrow With the name of the operation .... '"

.... ...

,

8. Show a process beginning. uSing

an elongated rectang le

. .....

••

.. .

..

. •

.•

•

'

.. .

"

I

•

• •

9 ...... ConUnue with each new statement of the use case

Figure 16.17 Steps for building a seQuence diagram. 2 of 2

16.6 STATE DIAGRAMS We intro du ced th e co ncepr of state and transi tion s In C hapte r 11 as a way lO some times express requi reme nts A slale diagram shows the states of the objects of a class , the eve nts to which th e object arc sensitive , and the resultin g transitio ns between rhem , State di ag ram s are also kn o wn as sfa lc-Iransihou diagrams o r Slllftcharts .

16.6.1 States and Substates In UML. sub>!ates of a statc arc Impl y show n as nested rounded rectangles. Figure 16. 18 sho ws the states and su bstatcs th at ma y be present '" an O. /i",Shopprr class. It shows that while a sho ppe r is c hecking out , she can be having her c redit valida ted . The stall" 1l1complclt indIcates tha t the shopper has signaled a readiness to check out but has not yet subm itted credIt card info nmation. The black dot and arrow ind icate that O"/"" S/JOpp,, objects are initiall y In the Browsi.9 statc.

16.6.2 Events In the context of state models, an wrnl is somethin g whose occurrence affects o bjects of the c1uss in question, Exa mples of eve nts arc a butto n click o n a Bultoll o bject or (], chJnge in the value of an o bject's variable.

Browsing

( ltemsChosen )

CheckingOut ( IncomPlete ) ( CreditUnderValidation )

[ CreditDonied

1

Figure 16.'1 States and substates for OnllneShOpper class

[ Complete

1

STATE DIAGRAMS

{credit card ~ data Incomplete]

Incomplete I- Hit Sub;'it _ __ bunon

{credit card data complete]

.. ( CreditUnderValidation )

Figure 16.19 Conditions on events in UML and the resulting difference in transitions

16.6.3 Transitions An event may cause an object to !rtmSlrio" from its current state to another state We denote a tran si ti on with an

arrow, labeled with the name of the event causmg the transi ti o n. Fo r example. when a S/'opptr o bject In IH complcie state subm its valid credit card informati o n, It transi tions from IH comple'e state to C"d,tU"d"lIalidatio" state Sometimes, when an obj ect is in a gi ven stJte and an event occu rs, th e object can transition to one

or

several states, depending on a co"diho" . For example, when a sho pper submits credit card Informallon (by clicking the mouse or hirtlOg r"t" ), the resulting tran sit io n depends o n whether o r not the d ata are compl ete. As shown in Figure, 6. ' 9, conditions arc deno ted by square bracke ts In UML.

16.6.4 OnlineShopper State Diagram Example A complete state · transition dia g ram fo r the O"li",Shoppcr is sh o wn in Figure' 6.20 When the Shopptr o bject enters the ChcckingOut state, It automatically en ters the substate Incomplete (mo re preCisely, Ch, kingOul.

IH compl"c).

select item

put back last item

Browsing _ _ _ select item - -

(credit card data

ltemsChosen

Hit checkou' buNon

Incomplete hit

hit Submit button

)I

Duit hltDK

{credit card da'a complete]

Credit Unde rValida,ion denial received

validation

hilDK

received CreditDenied Comple'e

F1gur. 16.20 State· trans !Jon diagram for OnlineShopper class

373

374

OiAPTER 16

THE UNIFIED MODEUNG LANGUAGE

16.6.5 The Relationship between States and GUts When an oppllcalion IS displaying a CUI , o ne can think 0(" as being in a particular statc Mouse or keyboard OCtion- arc romls thot affect this state. Although we ma y well want to define , totes that do not correspond to CUls, and vice versa , , State-CU I correspondence ca n bc made (or many appi
16.7 ACTIVITY DIAGRAMS Flowcharts arc among thc oldest graphica l met hod (or depicting the Aow o( co ntro l o( algorithm' The UML uses an extended fo nn of Aowchart called Activity Diagram s. The no tali o n (or activity diagrams is shown In Figure 16.21 . This example includes parallelism, shOWing the aClivitles Do" Ta,k and Do AMol/", Ta ,k operating in parallel. Control is no t passed to Do fum Mort until both have completed. Figure 16.22 containS an activity diagram (or a sclNaln'O method , showing the most commonly used Am.chart constructs; decisions (diamo nds ) and proces es (ovals). The fo llowing example shows on act ivi ty diag ram involVinG two classes . It describes the backward chaiOlng algonthm (or expert systems , and illustrates how Aowcharting can be helpful in exp laining complex algorithms. Experl arc usua ll y based on knowledge In the (arm of rules. which take the (orm

,y,',m,

tltltcrtdmt AND QulcccdrJ11 AND . .. AND (wtcccdrtl l

~ cO lI scq utHf

",here Qtllcccd(J1 IS and cotlscqumls arc Jacls. For example . animal is mammal AND QtII"wI

IS

stn'pcd

=> animal is zebra

OUf facts will si mply be string such as "a nimal is mammal."

0 0 Something

00 Something More

[condition true)

OoA Task

0 0 Another Task

else

In

parallel

00 Even More

Agure 16.21 UML actMty chart n01anon

ACTMTY DIAGRAMS

else

Parameter and settings make sense

Nominal pa th

Set name to · delauIlName·

Output notification to console

else

Parameter name 100 long

jkOfeCIIld fN/void SSIName{ s/rifl(JJJName) ( II Check IeQitimacy 01 parameter and senings I/( (1IN.lile = null ) 11 (maxNumChsrs/nName(j <= 0) II (rrwtNumClIars1nName() >a/III meUmitOINameLM>gthO ) ) ( name ;: new String( -ds{aultNa",. - );

S)sta II.out.printin

Sel name to parameter

Truncate name

( ·clelau/lNllme seIecIed byGa/n8Chamcter.selNameO·); }

Me II TruncaIB IfaName too long l/(aName.lBngthO >maxNumChsrs/nNameO ) name = new Stnng ( aNarne.fJ6tBytesO, 0, maxNumCharslnNamoO ) : else II assign the pammeter name name = new Strlng(aName };

}

Figure 16.22 Activity diagram example

The pro blem is to build a program that, given the fo llow in g,

B, 0 , and • a ilst of fact s, such as -A, -

.

• a list of rules such as A..R=:-L, - AkB=:-C, - and B.. C=:- -R det C. B(kIl OWII )& vu,1drdu crd) =:> R; A(kllowlI )&R vu,' drducrd) =:- L.

We will store the current list o f known facts as a static Vrclor of Fa I ea llcd jacILi" , ond Ihe ),st of known rules as a static Veclor of Ruf, called ",frllasr . We wi ll simplify the elup of these lists by hard coding the example given above In the Facl and Rulr cla« es. T il i, Is hown in Figure 16.23. O ur emphaSis IS o n the harder part · the "backcha ining" algorithm provrBack() fo r establishing whether o r not a given fact, wh ic h we Will name sou9/' IFacl, call be deduced from the given facts and rules A 1I0wch,rt '" thiS algorirhm is shown In Figure 16 24 Th is aCll vlty d' .lI'am he lp< to Si mplify an o d, erw lse complex algofl th m. An in pc tlo n 01the ,el1 " "" diallram mlg hl un ove r th e fa t lh . I " fads to tenTI ln.tc If Ihere " a "u lar haln In the ru le b.'1: su h a< X =:> Y and Y ~ X

375

376

CHAPTER 16 THE UNIFIED MODElING LANGUAGE

static ruloBase

slaUc I.CILIsl ~ Facl conlent addFaclO proveBackO

1

consequent

l..n

antecedents

Rule addRule() proveAnlecedenls() lorwardChaJnO

I

--------------------- )

Sel Facl.laclLisl 10 Ihe known lacls and a Rule,ruleBase to Ihe known rules, Creale Facl objec1 soughtFacl Execule soughIFact,proveBack( ruleBase );

Figure 16,23 A class model for chaining rules In expert systems

Facl

I I I I

Rule else

I I I

in lactUst

I

I I

I I

I I I I I I I

Another rule R exists with sough/Fact as its consequent

Apply R,prDveAnlecedents() •

else

Report FALSE

I I

I proof succeeded

else

I ,--_ _--, I

RepMTRUE :

• Prove that every

antecedent fact is true

• Figure 16,2 4 Activity for soughlFact.proveBackO involving two classes

16.8 DATA FLOW MODELS D.ta Aow models wer< intToduced in Ch.pter II when we discussed requirements, Rec.llth.t they consi t of aclia", . each of which takes place at a "odt . The UML not.t,on for thIs is exemplofied in Figure 1625. Each node ha s Input and ourput pi"s indicating the corresponding data type . Data stores are shown with rectangles

and a data"o", stereotype,

A DESIGN EXAMPLE WITH UML

Parts lisl

Parts lisl Part order

Process

Price lisl

part order Credil card dala

Charge credit card

Ship part order

Charge amount

.. datastore .. Charge amount

Figure 16.25 Data flow models in UML an example source' ADopted f,om Jacobson. IVar, Grady Booch ana James Rumoaugh. "The UnIfied SOftware Development Process," (AOOISOIl·Wes!ey Object Technology seria). AMISOn-WE s!ey, 1m

16.9 A DESIGN EXAMPLE WITH UMl As an example that illustrates several parts of the UML notatio n in this chapter, consider a graphics studio specializing in drawing stick peop le. A CUI for this is dlustratcd in Figure 16 .26. We will focus only on the "foot" requirements. Certainly, there is a need for Rtela"gl, and Elll psr clas os. The first question is whether we need a Fool class. When we drag a rectangle near the end of a leg, the application has to know that we want it to be placed at the end o f that leg In a standard positio n. Althoug h it may well be possible to do this without the application ·'knowlI1!;·' about leg- and fee t, it IS muc h c'asier to

D 0

0

Facilitate dra wing stick figures

0

Drag to vicinity to auto-complete

0

Feet can be rectangles or ellipses

o

(Rest to be specified)

0

6

Releasing dragged Ilgure anywhere In this area causes illo appear in posltlon al end 01 lell leg

Fllur. 16.26 Specifications (or figure.-drawlng example appllcallon

377

378

CHAPTER 16

THE UNIFIED MODELING LANGUAGE

Rectangle

Ellipse

Fool Figure 16.27 Bad attempt at class model for "A foot Is either an ellipse of a rectangle" Rectangle

Foot

"" RectangleFool

El hpse Fool

Figure 16.28 Better attempt al class model for "A foot is either an ellipse of a rec1angle" cany out if Ltg and Fool classes arc used . (For exa mple , a lLg object would aggregate a Fool object). The next quesllon IS h ow to re late the classes FOOl, R,clnngl" and EII, plt. Co nside r the pOSSIbility sh ow n in F,gure 16.27. n, is class model says that a Fool object is bot h an e llipse and a rectangle, which is not co rrec t. A berter optio n is th e class model in Figure 16.28 . This mod el is at least not incorrect as the firs t anempt was . It IS a little clumsy , however, in that it prohferates classes (ElIip,tFoot, Rtclangl,Fool, elc.). Th is is nol te nab le (do we need RtaClaJlg/,Ear, elc.I) . It also uses multiple inherita nce, whic h is problematical In general, and not available In Java . Now consider the option shown in F,gure 16.29. This is a reasonable solution excep t fo r o ne very awkward ISSUC : it makes every ElIips( in our application a kind of FoolSbape, a nd likewise fo r every Reelallg/,. For o ne thin S, thi s cenalnl y lim its the reusab ihty of the Ellipst class. For anot her, It is rather strange to Ihink of ellipses as FoolShapes in any case. Finally, if we continue with thi s, Ellipst ma y also have to be a HnJldShnpe objec t etc. One way to deal WIth t hese problems i fo r FoolShape to depend only "lightl y· on Elliplt and Reclangle as sh own In Figure 16. 30. Foot

FootShape

...-..•. ".

....v

.-

Ellipse

.'

./

/' , .' " ",

..... . .~

'"

"

'.

I Reclangle

Figure 16.29 Another atremp, at class model for "A foot Is either an ellipse of a rec1angle" FootShape I drawAsE llipseO drawAsRectangle(h

Foot drawO I I

, Ellipse draw()

\ \

Rectangle drawo

Figure 16.30 Best atteillpt so far at class model for "A foot Is either an ellipse of a rectangle"

A DESIGN EXAMPLE WITH UMl

Area releaseCursorO

,, ,,

~-------------

-

"- ,

,

- - - - - - - GeometricFigure ~~

leg

,,

,,

,,

/

~

~

FoolShape drawAsEilipseO drawAsReclangleO

Fool draw()

,, Ellipse drawO

~

---

, ....

-- ---

-- --

....-~ ........ ....

-------------

/

-- /

/

/

/

'~-..,

p OSition ,-:

'

"-

....

....

.... . . ..

" - - - - - - - - -....

Reclangle drawO

Figure 16.31 A class model showing all dependenc ies in drawing application class model

This class model shows that the restrictions o n the shape of Fool objects are rentcted in the methods of FooIShap, . They reference only Ellips< and Rtclallg/, at this point , but can readily be augmented to accept other geometric shapes. We can no w fill in more detai ls, as shown in Figure 16.31 . The Area's rt/,as,(ursorO method handles the auto-placement (at th e end of legs in the cases shown ), and this information is passed along to the anatomical object (Fool in th is case ); olherwise the drau10 of Ellip s, and Rtclallg/, are used to do actual drawing . The class Posilion could be avoided . It contain the x- and y -coordinates. For example, drawAsEllips,(Posilioll oPosilioll) in FoolShap, cou ld have the following form .

void dr awAsEllipse ( Posit ion aPosition ) {

Ellipse ellipse: new Ellipse ();

II the dependency shown in the

ellipse _draw( aPosition ) ;

c lass model II the actual work drawing the ellipse

. . . . }

Showing a ll of the dependencies in a class model can make for a complicated diagram , and for this reason dependencies are often omitted. (This i< perhaps like swee ping thinSs under th e rug l) The sequence diagram in Figure 16,32 specifics how the classes and methods work together, and show< details aboUl parameters The sequen e diagram speclAcs that when a geometric Agu re IS dragged to an area and the cursor It released , the "ttllS' u" orO method of Arm execu tes with Ihe C,om,'n',Fig"rr as parameter The At,a Obll'Ct deduces which anatomical obje t IS Involved (Fool in thiS case), <0 It ca lls upon that obie t to dra, ",elf, It als o knows whar gcometn form IS required

379

380

CHAPTER 16 "!'HE UNIFIED MODEUNG LANGUAGE

:FoolShape

:Fool

:Area

: Ellipse I

-----+.,., releaseCursor

( GeomelncFigure aGeomelncFigure)

draw ( Leg .Leg, GeometrlcFlgure aGeomelrlcFigure)

drawAsEllipse'

( PositIon aPosition) draw( aPosihon)

I I I I I

, or drawAsRectangle() ...

Figure 16.32 Sequence diagram lor figure drawing application

16.10 SUMMARY The Unified Mo deling Language (UML ) is a widely accepted graphi cal nolation for expressing object oriented designs. UML defines several ways classes can be related TI,ese are sum marized in Figure 16.33 . UML models are diagram that show either th e cla.sses of a software design and how they are related , o r the Aow of control 01 a design . Figure 16.34 summarizes the UML models covered in this chapler.

• Package • Group of related classes • Inheritance

• Take on attributes and operations from o ther classes • "is-a" relationship

• For example, an Employee "is-a" Person • Association • Structural relationship between classes

• Aggregation • Structural mclusion of object on one class • "whole -part" relationship

by another

• Composition • Stro nger rorm of aggrega ti on • Included object is created and destroyed when including object is created and destroyed • Dependency • One class depend on another • Changes to depended ·on class aHect dependent class

Figure 16.33 various relatlonships between classes that can be shown In UML class diagrams

/

EXERCISES

• Oass Modds • class~s of a design and their ~ I ation sh ip • Obj«t Modd • obj«ts of a desIgn and their relationship • Sequence Diagrams • seque nc~ of method ca lls among object • usually corresponds to a usc ca e • State Diagrams • states of a design clement • transitions among states caused

by

events

• Activity Diagrams • Row of contro l • si milar to Row charts • Data Flow Model • show processing elements and the data that Row between them Figure 16.34 UML models

16.11 EXERCISES I. Name three major re lati onsh ips that could eXISt between classe A and B. Describe them in your

own words. Express each

10

UML and in a typical Java implementation

2. Explai n the difference between aggrega tIo n and composition. Cive an example to support your answer. 3. Which of the following classes inherit irom whic h7 Exp la In YOllr reasoning.

WOnt1. Ellips<. Al1ilnal. 2DF,gurt. Circ/, 4. D raw the class diagram for the fo llowing code . Explain the correspondence between the code and the diagram .

abstract class A ( ) class B (

B( ) ( ) )

class C extends A (

B b = new B ( ) ; )

5 A library ha, a aile li o n of 'tcm< (boob and magazine ) avai lahle to loan patrons Forea h 'tem ,n the ollection . the system mJ,nt"", dDta about 'IS t,tle, au thor, and unique ,eI In adel,t,on , the

381

382

CHAPIER 16 "!'HE UNIFIED MODELING LANGUAGE

cop right year is malntolned (or books , and the edit io n number I; mo intalned (or magaz ines. Draw a UML clas. diagram representing the library item;. Be sur< to include the required attributes. HI.' U sc in heritance

In

your model

6 Show a class d13 gram (o r an application that displays automobiles. Depending o n the user's request, It dl plays a tYPical Ford, T oyota, or C he vy, tOset herwith Interactive pages o( In(onnation about each We want to be able 10 easil y add new auto mobile brands to the application in the fulUre and to reuse parts o( the deSign where possible. 7. Suppose that your car has a buill ' ln applicalion that dISplays the status of Ihe cngi ne parts at all times. Draw a UML stale diagra m (or Ihe 5larl" class that describes the automo bile's starter o nl y. Explain your reasoning.

N o te that the starter is some times connected to and sometimes disengaged from the car's motor The ~tarter react s to actions involVing the car key. The key ca n be in one of three positions:

vertical , 90·, and I BO·. B. ConSider an applicalion used at a doctor's office. The application schedules patient appointments and maintains patient medical hi stories. Suppose the application design contains an Appomtmrn ! class to lrack appoi ntments, and a Medica /Hillory class (or each patie nt. H ow would yo u draw Ihe U ML class relatio nship between these two classes)

9. Consider Ihe fo llOWing use case for a web e·commerce app lication, Use Case Name, "Select Item" Actor, Shopper Precondition : Actor has req uested product list Sce nario:

I. 2. 3. 4.

Applicati on displays product list User selects item on product list User cl icks "add item to shopping cart" bunon System acknowledges Item placed in shop ping cart

Draw a UML sequence diagram (or this use case. Explain your reasoning. 10. Draw a UML activity diagram for the "Select hem" usc case

In

Exercise 9. Explain your reasoning.

BIBLIOGRAPHY I Fowler, M :mm, "UNLL DIJftIJcJ A Bnt! Ci1Aldt 10 1lH- SwnJnrJ Ob}tcl MoJtli"9LA"9~"gt.~ 3rd ed Addlson-Wnl cy. p 99 , l~' ......... 2. )KOOwn, Ivat. Grady Booch .nd ) OImes RumbOlush, 'Th U'UfitJ SoJIv'4rt DtlHloplflt'n1 P~m." (Addl~n- \\:/ec; lc y O bJcct T C'Chnology Sene'S), Addison · W(1.I~ . 1999

MaIntenance

TIle Sof~vare Development Ufecycfe

Requirements analysis

•

What are examples of a recurnng design purpose?

•

What are ·creational" design patterns?

•

What are "structural'" design pattems?

•

What are

•

Can design panems be thought ot,n

~ behavloral"

desIgn patterns?

terms of roles and basic forms ?

Figure 17.1 The context and learning goals for thiS chapter

DesIgn pauerns co ncern class co mb,n all o ns and accompanyong algonthm, that fu lfill com mOn desIgn purposes Eac h desIgn pallern cx prcs es a desIgn co ncep t rath e r th a n an onllcXlble da , combination The aecompanylnj( algonthms cxpre the pauern's b."e opera ll o n Thl c hap te r" Intended to famolianze the reader w Ith th e purpose, of de
Camma "t al [ I ], th e clas"c ref ·re nce (or the su h) ee t hapt e r I dc
384

CHAPTER 17

SOFlWARE DESIGN PATTERNS

17 .1 EXAMPLES OF A RECURRING DESIGN PURPOSE 17 .1.1 A Simple Example ll,crc are m.ny applica tio ns In whICh w~ defIOe. clas bu, for wh ich oilly onc In"an c wdl be needed As an cxa m pic. householders arc forevcr co n,ernpla'ing ,he moderOl z. " oll of ,helf kl ,chen<, or.en usi ng software '0 vISualize 'he posSibili',cs Usi ng a K,rcim, class would be nalUral. Now suppose ,ha' a reqUirement IS that the applica'ion does not allow ma rc than ooe kllchen to be under conSi derati on. It IS always. good idea for an apphcallon to enforce what it mtends, so the patt ern needed here IS rhe enfo rce ment of th e o ne· in lance .onl y

reqUirement The Singleton design pauern . describcd in ec tl on 17.5. 1, fits th is bill.

17.1 .2 A More Complex Example Let's con 'lnue wi ,h ,he kllchcn application, which we will call Kirch", V"u>tr. "enables ,he user ' 0 first layou t th e parts of a kit chen \v' uhout comm itting to a style. The overall interface

IS

shown in Figure 17 .2.

Here is a usc casco

Layo ut a Kitc hen Preconditi o ns: No ne I.

U5(r clicks o n ,he "wall cabinet" icon.

2 AppllClltiotl displays a wall cabinet in the center o f the work area.

3 Usn reSizes the wall c abinet.

Uscr drags ,he wall cablnc,

'0

a posi tion "' ,he upper half of ,he work arc • .

0 Wall cabinet

menu

.!1 l1

Counter

./ display area

0

styles

Floor cabinet

~

""

Modem

11b[I.,.,;;c;;;;laSS;;;;;;;, ICdl~

,

Anllque

Figure 17.2 Graphical Interface to the KltchenVlewer example application

I~ Arts & Cra". I

EXAMPLES OF A RECURRING DESIGN PURPOSE

UStr rdease the cu~or. 6. Appfiralio" places the w.1I abinct In the nearest conforming position . 7. User clicks o n the "Aoor cabine t" icon . 8 Appfirallo/l display a tloor cabIOet ,n the center o( the work area.

9.

•

••

Once the layout process IS complete, the kitchen appea~ as in the example hown in Figure 17 .3. After a kitchen has been sketc hed 10 the above ",anner, Kilchen V Icwer allows the user to try various styk-s (or the wall cabinets, t100r abine ts, and countertops . When the user selects "Antique," for example, thc design appea~ as in Figure 17.4.

Counlerlop

I 0

,

\

I

0

0

•

\i

0

I I

,,

II

,

I 0

0

0

,, ,I I

I 0

0

0

/

, •

Agure 17.3 An example of a kitchen being deSigned with KitchenViewer

. 1. I ,, , "

r -Arts Fllllre , 7.4 selecting an antique style using KltchenViewer

& Crahs

I

385

386

CHAPITR 17

SOFlWARE DESIGN PATIERNS

What are our specific de Ign purposes for Kitchen V,cwcr7 The procedure o f re ndenng the va nous " ylcs IS baSically the ,.me, rega rdl cs, of the style, and we should "01 ha ve mo re than o nc copy of thi S procedure In Our application. In particular, we shou ld avoid code , u h as .he fo ll OWin g

Counter counter = new Counter ( ) ; draw( counter);

This is because no amount of added codc wtll enable thIS to draw va mble rypes of counters at runtime. Better deSign thinking than thIS IS required, and it is usuall y set up ' 0 all ow po/ymorpi",,,, , a Single block of code then executes In severa l possible ways , de pending o n the context O ne approac h IS to dC'sign the kitchen appitcatlon so as to provide a method such as rrndtrKllrbrn(mySly/t}, somehow parame .e riz ing the rendering procedure With a requ ired srylc. We would need to Agure o ut what kind of a thing mySIyI, sho uld be , and how mld"K,lrbm() uses It. Thi . kind of design purpose recurs, and we ca n descnbe it a fo llow . An application mus' ("oPis/ruet aJamily oj objects al nwfin1c; TI}t JfSigtl mu sl mabie dJolCt omO.19 srorral farnilltS oj styks.

ThIS purpose can be approached wi th the Abstract Fac tory des ign pattern , which is dis cussed in Section 17 .5 2.

17.2 AN INIRODUCTION TO DESIGN PATTERNS To illustrate how patlcrns express ideas, think about how yOll might describe your housing prefere nces to a realtor. The term "ranch style," ror example, denotes a usefu l hOllse pattern . It conveys an idea rather than a

completely specific de ign.

17,2.1 Example Application: Without Applying Design Patterns As an example of a so ftware deS ig n pattern , let's rcturn to the Kitchen V icwe r example . Reca ll that we wan1

to be able to provide a method such as rtlldtrKllrh,"(mySIy/,). Now we need to ela borate on what mySIy/' means

The method 'rnd"Kirrb",() uses the classes K,lrhrn , \VaI/Cab""I , and so on, and we wtll make it a member of a class called 0,,,,1. If we temporarily forgel o ur purpose of parameterIZing the style, the method rtlldtrKilrhrn () would look somethi ng like listing 17. 1. This code would have to be repeated (or every style , result ing in more error. pronc and far less

mai ntainable code . (Sooner or later, code that IS supposed to be duplicated becomes different places.) A class diagram for this would look like Figure 17.5.

In

different

The result is reJ>('tltl vc and complicated. As a result . it is inflexi ble , hard to prove correc t, and hard to reu e.

17 .2.2 Example Application: Applying a Design Pattern Now let's fulfill our KitchenVlewer design purpose by applYing the Abstract Factory deSign pattern. ~ ell assume that some object will have the rcsponSibiliry for creating .he kllchen. Here IS the Key, Instead of that object directly creating AIIriqu,Wal/C,bi.,r objects, for example, a parameterized version of mldtrKil "'"0

AN INTRODUCnON TO DESIGN PATIERNS

17.1 : The method renderKifChen{j in KitchenViewer

II

VERSION IGNORING OUR DESIGN PURPOSES

I I Determine the style · . . I I case statement? II Assume that the antique style was selected .

I I Create the ant ique wall cabinets Ant iqueWallCab inet ant iqueWallCabinet 1 = new Ant iqueWallCab inet () ; Ant iqueWallCabinet ant iqueWallCabinet2 = new Ant iqueWallCabinet () ; •

•

•

II Create the antique floor cabinets AntiqueFloorCabinet ant iqueF loorCabinet 1 = new AntiqueFloorCabinet () ;

AntiqueFl.oorCabinet antiqueFloorCabinet2 = new Antiqu eF l oorCabinet () ; •

•

•

I I Create the kitchen object, assuming the existence of

add()

methods

Kitchen antiqueKitchen = new Kitchen(); antiqueKitchen.add( antiqueWallCabinetl, . . . ); II rest of parameters specify location antiqueKitchen.add ( antiqueWallCabinet2, . . . ); •

•

•

antiqueKitchen.add ( antiqueFloorCabinetl, . . . ) ; antiqueKitchen. add ( antiqueFloorCabinet2, . . . ) ; • • •

I I Render •

•

antiqueKitchen

•

ddegate. their creation , replacing phrase. such as the foll owing,

nell Ant iqueWa llCab 1net ( "

//applles o nly to antique style: Replacet with the follo'W'lnq.

myStylo. getwallC~b inet ();

Ilapplles to the s tyl e c hosen at

runtia\C~

AI nuntime, the class of ,.ySlylt determines lh e version of gtlW,,1/ nbilltl() executed , th ereb ' produclllg Ihe approprrate kind of wall ca binct To carry out tl", dclc~at lo n of re<ponsibility, we Introduce a new do s, ,.,hich we'll all KlichtHSlylt, supporting methods gtIWnI/Cn hllltl(), gtlFloor "h,"tl(), and <0 on Kllcht. I It Will

387

388

CHAPTER!7

SOFTWARE DESIGN PAlTERNS

Chent (onderK.tchenO

---- - - - ---

---- --

___ __ - -

Kitchen

WallCsbinot

;

;

;

;

;

;

;

;

;

;

;

;

;

;

I I

/

I

/ /

I

/

I

/

I

/ /

I

/

I I

/

;

/

\

\ \

FlOOrCobFnel

\ \ \ \ \

\

I

/

ModernWaliCabtnet

\"

/

/ ;

I

/

;

;

1\

~"'/

",/

;

;

-- ..,.

I

AnllqueWal1CablnOI

" I I

I I

\

I

I

I I

ModemFloorCablnct

AnlJqueFloorCabinel

Figure 17.5 A design for KitchenViewer without design patterns

have subclasses, which we'll name Mod,,,,KSlyl,, A"'iq",KS'yl" and so o n, each supporting se parate imple · mentatio n of g,llVaIlC,bi"ct[), g,IFloorCabi",'(), and so o n This is show n in Figure 17.6. Recall that, due to polymorphism, executing ",yStyk.g"FioorCah",,,() has di ffere nt effects when "'yStyk is an object of ModmtKStyk vetsus an object of AHliq",KStyl,. The class model in Figure 17.7 is a more complete vetsio n. Notice that th e client code rdere nces K, Ich,", K,'ch",Styl" WaliCabi"ct , an d FloorCabi",' , but docs not rde rence pecinc wall cabinet sty les or Ooor cabi net sty les. For example, the class A"liq",W"IlCabi",' does not appear in the clie nt code. T o sec how th is wo rks, let's assume that at runtime, "'ySlyl, is an object of the class Mod,,,,Sryl,. In this case, when the method ","ItrKilch",() executes a statement such as

WallCabinet wallCabinet7 = myStyle, getWallCabinet () ;

WaDCabinet

FIoorCabln8t

C;

lI"IFIooiCabi""'1I

...

AnllqueWallCablnet

,,

gelWatlCab1nelO getFloofCobOnelO

,.,--,---':'::_"'1' ;

getWalICablnel() '

;

AntlquoAoorCablnol ;;

, ModemKSfV1e

.. ....J

.... ,-

gelAoorCabinetO

I AootC'tNl getFlootC.~1() I rerum r4N .'cdllfoRoooc.btnlIO: ) Figure 17.6 The Idea behind the Abstract Factory design pattern

;

AN INTRODUCTION TO DESIGN PATTERNS

Cl"",'

. ..

rendef1(ltChOn( K1tCl'lenSty1e)

,, KItchen

,,• ,

--

~Wo!!('·, ... 1(1

AoorCaolnot

,

I '--...n I'lIIiW U:OC'l.,hrwl.O.

M odemKS!y!e

ModcmWallCtlbln81 • •

•

'. •

Anllgue KStyie getWauCablnel()

••

• • •

.- - - ' - -

•

•

•

•• • • ••

,.

AnllqueWaUCabinet

••

•

••

••

...

••

gelFloorCablnelO

AntiqueAoorCablnel

Figure 17.7 The Abstract Factory design pattern applied to KitchenV,ewer the metho d grIWaIlCab"1(rO is the ve rsio n defined ,n the class ModrrnSry/r, and so it actuall y returns a

Mod,rnWa/iobject.

Th. metho d rt1,drrKirch", (Kirr/m,Sry/r n,ySry/r) looks Itke li sting 17 .2 Th is version of rmdcrKird""O is much morc versatile than the pre vIous version since It IS not written fo r any particular sty le . Figure 17.8 de cribes Ihe Abs trac t Fac tory desig n pattern in ge neral.

Ustlng 17.2: The method renderKltchen(KitchenStyle myStyle) in KitchenVlewer

II Create the wall cabinets : Type determined by the class of myStyle WallCabinet wallCabinetl = mYStyle . getWallCabinet () ; WallCabinet wallCabinet2 = myStyl e . getWallCabinet ( ) ; •

•

•

I I Create the floor cabinets : Type determined by the class of myStyle II Create the kitchen object (in the style required) PloorCabinet floorCabinetl = myStyle. get Floor Cabinet () ; Floor Cab inet floor Cabinet 2 = mySty le . get Floor Cab inet ( ) ; •

•

•

Kitchen kitchen = new Kitchen(}; kitchen . add( wallCabinetl , . . . } ; kitchen . add( wallCabinet2 , . . . } ; •

•

•

kitchen.add( floorCabinetl , . . . } ; kitchen . add ( f loorCabinet2 , . . . J ; • • •

389

390

CHAPTER 17

SOFTWARE DESIGN PATIERNS

--

------

Style 9O/CompoilentAO go/Compollom80

CUenl doOper.tion( Stylo mySlylo)

--" -" --.",.

-"-"

""

,;'"

I I I

Collection

\ \

I

\ \

\

I

\

I

\

I

\

I

' " ComponantA l

, Stylel

getComponentAO getComponenLBO

,

ComponentS

,

L,

Style 1CompcmentA

,• , , ,,

,1

Styte2COmponentA

---- ---- -- ' ,- -- - - - --- , --, , $tyle2 ,,

gelComponenlA 0 getComponentB 0

.., Style ! COmponentS

--- -- ------- -- --- --- -- ---

Style2ComponentB

Figure 17.8 The Abstracr Facrory design pattern

The client method JoOpcralloH (Style myS/yle) builds an inslance of Collecrioll in the style indicaled by myStyle by calling mySryle.getCompoH".tAO and myStyle.grtCompolln.tB() . If myStyle is a Styl" object, for example, these two operat.o ns produce Styl" Compo"",tA and Styl" CompolI".tB objects, respectively. The pattern thus ensures a consistent style throughout We have mentioned that desi g n panerns , ho uld no t be rega rded in a literal manner. For example , the desig n," the above figue< could also appear as shown in Figure t7 .9 . In this alternative. Collerrioll aggregates Sty I" CIi",r docs nOl rderence Style directly, doOprratioll O takes no parameters, and Collertioll has methods for getting the vari"us components. Collerrioll', aggregated Styl, obJeci is instantiated at runtime . perhaps with separate se tup code . When JoOprrarioll O calls grtCompolI",tA() in Collrerioll , conlrol is de legated to getCompolI",rA() in the aggregated Styl, object. This is still the Abstract Factory pattern . The Abstrac t Faclory palle", is described in more delail in Section 17.5.2.

17 .3 SUMMARY OF DESIGN PATTERNS BY TYPE : CREATIONAl, STRUCTURAL. AND BEHAVIORAL Gamma et a!. [ 1] classified deSIgn patterns in one of three ca tegones, dependmg upon whether with one of the following , • Creating a colleclion of objects in Aoxible ways (
It

has

10

do

SUMMARY OF DESIGN PATIERNS BY TYPE: CREATIONAl., STRUCTURAl. AND BEHAVIORAl

Client

doOperatlonO

--- -- "-

-

StylB gBtComponentA O getComponentB{)

/

/

Collection

/ /

gelComponentAO gelComponentB()

/

/

,, ,, ,,

/ /

ComponentA

,, ,

CamponentB

7J: , , ,

"'i Style 1ComponentA , ,

Style 1 , Style2ComponentA , getComponentA() , , getCamponentBO - --- , -- - - - ~ ,- , - -- - . - - , Style l CamponentB , Style2 ,, getComponentAO getComponentBO --- -------- - - - ------- --- - Style2ComponentB

---

-

Figure 17.9 The Abstract Factory design pattem alternative

These categones arc useful for recognizing when 0 panern may be needed and as the beg.nning of a guide to sciectlng which one may be appropriate. Next , we wi ll elabo rate on each uSing exam ple applications

17.3.1 Creational Design Patterns Creat.onal design patterns help us to flexibly set up co llecti ons of o bjects for subsequent processing. They allow the creation of seve ral possible collec t.o ns fro m a single block of code, but wllh properties sllch as· • Creating many versions of the collecti on at runtIme • (0"llra'"'"9 the objects created: for exa mple, ensurin g that there' is o nly instonce of its class

Table 17. 1 summanze the use and nature of key creat. ona l dcs.gn pallerns The ab tract factory and SIngleton pallerns are descnbed .n more detail .n sub equent seCll o ns.

17.3.2 Structural Design patterns Structural des.gn pallerns he lp us ' 0 arra nge co lkc llo n of o b,eCt in fo rms such a hnked lISts or trees They are u.dul when we want to manage omplex dala conSISting of ossa iatcd o bject . Table 172 summanzes the u~ and nature of k(1'
de'."

10 wb\Cquent scCClonr. a .. rcprc~e nlallvc: examples

of Slru Ctllfil l

dC:'S18n pattcrn~

391

392

CHAPTER 17 SOFlWARE DESIGN PATTERNS

Table 17 • 1 A summary of key creatlonal design patterns Example Application Purpose Satisfied by This Pattern Design Pattern Name

Approximate Design Purpose Satisfied by This pattern

Design for the following requirements without repeating code unnecessarily. Make the design easy to change.

Outline of the Design pattern

Create objects at runtime WIth flexibility that constructors alone cannot provide.

From a single version of control code, generate mail messages tailored to vanouS custOmers.

Create desired objects by using methods that return the objects.

Create coordinated fam ilIes of objects at runtime, chosen from a set of styles .

Display a ki tchen layout, allowing the user to select a style at runtime. (See Section 17.2.2.)

Encapsulate each family in a class whose methods return objects rn that style.

Prototype

Create an aggregate object in which selected parts are essentially copIes.

Display a kitchen layout. allowing the user to select at runtime a type of wall cabinet. or a type of noor cabinet, etc.

Create the objects ofthe type by cloning a prototype.

Singleton (see Section 17.5.1)

Ensure that a class has at most one InstantIation, accessible throughorJI the application.

Build an application to evaluate the results of a lab experiment Ensure that there is exactly one Experiment object at runtime, and ensure that it can be accessed by any method in the application. (see section 17.5.1.4.)

Make the constructor private and obtain the unique object by means of a public method that returns it.

Factory

Abstract Factory (see Section 17 5.2)

Table 17.2 A summary of key structural design patterns Ex3mple of Design Purposes satisfied by This Pattern DeSign Pattern Name

Approximate Design purposes satisfied by ThlsPattem

Represent a tree of objects.

Composite

Allow client code to access uniform functionality distributed in the subtree rooted by any node.

Decorator

Allow objects and functlonafity to be added to an object 8t runtime.

Design for the following requirements without repeating code unnecessarily. Make the deSign easy to change.

Summary of the Design pattern

Represent the organization chart of a company. Allow client code to call prrntOrganizationOon any Employee object, printing the names of the employee and all subordinates, if any. Allow the additIOn and removal of subtrees at runtime.

Have compoSite objects aggregate other composite objects.

Allow the user of an online clothing store to see his or her Image dressed in a variety of clothes.

Link the objects using aggregation.

(continued )

SUMMARY OF DESIGN PATTERNS BY TYPE: CREATIONAL STRUCTURAL. AND BEHAVIORAL

TIllie 17.2 (continued) Adapter (see section 17.6.2)

Facade (see secuon 17.6.1)

Flyweight

Proxy

Ailowan application to make use of external (e. g., legacy) functionality.

Design a loan application from scratCh. but allow It to use any vendor's classes that compute monthly payment calculations.

intrOduce an inherited Intermediary class relating the application and the class with desired functionality.

Manage software architectures involving large numbers of classes.

Design the architecture of a student loan software application so that one group of developers can concentrate on the loan option database, another on the user Interface (simultaneously). and a thlfd on payment calculations. Minimize coordination problems.

For each package, Introduce an object that IS the sole access to objects within the package.

Obtain the benefits of having a large number of Individual objects withoLit excessive runtime space requirements.

We want to be able to visualize a room with stenciling. There are five stencil patterns but thousaQds of potential stenCil marks on the walls. This might be easy to do if each mark were a separate object. but we can' t afford the memory required, and it's impractical to name all of these separate objects.

Share objects by parameterizing the methods with variables expressing the eontext.

Some methods are remote, or require lots of resources to execute (time or space). Ensure that they can be executed, but no more often than necessary.

Assume that rendering an image consumes a significant amount of time and space because the image data has to be read from a file, fill a buffer, and then be rendered . If the buffer is already filled by a previous invocation of the method, then Invoking the function should not repeat this step.

Introduce a class standing between the requesUng methods and the resource.

17,3,3 Behavjoral Design Patterns When an application runs, much behavior generally occurs among the objects. An example IS when a method in one object calls several methods In an obJcct of a dlHerent class. Sometimcs wc want to control and label behavior 111 order to parameterize it or reuse It Each behaViora l pattern captures a kind of behav ior among a collectio n of objects Let's consider the follOWing example of mutual behaVior among

Ship and TlIgbonl objects

Let's say that we

want to cstimate the amount of lime required to bring sh i ps Into and out of a harbor and tran pon them to dry

dock

for maintenance, based o n their Size, and 0 on Imagine that thIS i, a omplex calcu lation ,hat requires a

systematic simulation o f the ,ransportation process !'igore 17. 10 suggests a configulUt.on The classes

Ship and Tugbonl

are natural closs ch Oices, blll obJcc ts of rhe e lasse, play different role ,

depending on whether 'he ship IS entering , leaVing, or head i ng for d ry d ock applications In which we ca n usc •

SI" p and TIIgboll l, we

111

e th erc arc many pOlentl.1

d o no t wont th e,. la'5e' to depend o n ca h o th er,

J,

"'88«ted by Fil!ure 17. 1 I We have a bchtlvloral design purpose h ere occa u,c we wan' to 'CI>Jfate the interd ependen t behaVior of

(hcse

objects from the objects them,elve, The Mediator design pattern doe, th". Figure 17 12 ,how, the

core Idea of Mediator

393

394

CHAPlER 17 SOFlWARE DESIGN PATIERNS

I

U"

,

~

-

,.-

;.--J hA

h~ obstacles

-- ""

Algorithms express mu tual behavior

'- • "

.,..

\•

,

~ 10 dry dock .;

Figure 17.10 Example of behavioral design goaf-tugboat and ship port entry

Harbor application

Ship

I

1..n

--......:......:- Tugboat

Customs application: reuse Ship alone

ILongshoreman I Figure 17.11 Avoiding design dependency in port entry example

In this deSi gn. Ship and Tugboal classes do not refer to each other Instead. the I.r.. IIIgPo,./ class contro ls how objects of

Ship and Tugboat behave to es timate the tim e for that maneuve r.

The full Mediator pattern allow (or the fact that the mediated clas es may need to com mun ica te (e.g., to respond to events on either of them). T o accomplish th is. the media ted classes ca n be made to subclass a bast' c1a~s that aggregates a genenc media tor class (PortNLsSlOt1 ) TIll S is shown in Figure 17. 13. a te that 111 Figure 17. 13 the Ship class docs depend on the class V",tI , wh, h depends on P0r1Ml5lI0n , so we can not usc the ShIp class wi thout these [Vo'o, These dcpcnclcn ics arc much more acceptable , however, than

Ship LeavingPort eSlimateTImeO

Tugboat Agure 17.12 The Mediator design pattern concept applied to the POrt entry example

SUMMARY OF OESIGN PATIERNS BY TYPE: CREATIONAL STRUCTURAL, ANO BEHAVIORAl.

PortMlssJon

Vessol

eStlmaleTImeO

-z;;

if Med1al0f base class

Ship

Tugboal

Ente ringPort

eSlimateTlme O

LeavlogPort estimate TimeO

-t-

8eingMainlained

eslimaleTimeO

Figure 17.13 Applying the Mediator design pattern to the port entry example having Ship depend for. 1I lime o n Tugboat Ships are always vessel<, and they usually have missions, but they are only someti mes assoCIated w ith tugboats. T able 17.3 summarizes th e usc and nature of key behavioral design pattern . The Interpreter, O bserver, and State patterns are described in more detail in subsequent sections as examples of strucrural design patterns. Table 17.3 A summary of key behavioral design patterns Example of Design purposes Satisfied by this Pattern Approximate Design Pattern Name

Design Purposes satisfied by This pattern

Chain of Responsibility

We want a collection of objects to exhibit functionaltty. At design time we want to be able to easily add or delete objects that handle all or part of the responsibility.

Design a GUI for a Web applicabOn to view automobiles with requested color, etc. The display Is dynamic, depending on the model. etc. chosen. Reuse the GUI parts among the displays.

Link objects to each other via aggregation. Each performs some of the work. and then calls on the next object in the chain to continue the work.

Command

Make the execulton of operations more flexible, For example, enable " undoing."

Allow users of an application to retract their last four decisions at any time (the " undo" problem).

capture each command In a class of its own.

Interpreter SectIon 17.7 1)

Parse an expression.

Design an application that takes as Input an order for a network of PCs, expressed In a standard syntax. The output consIsts of Instructions for assembling the network. (See Section 17.7.1.5)

Introduce a class to capture expressions, and allow expression classes to aggregate expression classes

Design for the following requirements without repeating code unnecessarily. Make the design easy to change.

Summary of the Design pattern

• (continued )

395

396

CHAPTER 17 SOFlWARE DESIGN PATIERNS Table 17 • 3 (contmued) Example of Design Purposes satisfied by This Pattern Approximate Design pattern Name

Design Purposes Satisfied by This pattern

Design for the following requirements without repeating code unnecessarily. Make the

summary of the Design pattem

~ Mediator (see above)

capture the interaction oetween objects without having them reference each other (thus permitting their reuse).

Build an application that estimates the amount of time required to bring ships into and out of a harbor, and to transport them to dry dock for maintenance, but ensure that the Ship and Tugboat classes can be reused separately.

capture each Interaction In a separate class, which aggregates the objects involved.

Observer (see Section 17.7 .2)

A set of objects depends

Keep management, marketing. and operations departments up to date on sales data. Each of these departments has different requirements for the data.

Capture the data source as a class. Allow It to loop through the observer objects, calling an update() method.

State (see Section 17.7.3)

At runtime, vary the effect of invoking an object's methods depends upon the object's state.

Customers fill out an order form on a Web site, and then hit the " enter" button. The result must depend upon the state of the form data: " Product Information Complete," " personal Information Incomplete," " Credit Check In Progress," etc.

Aggregate a class representing the state with operative method dOAction(j. Subclasses effect the reqUired actions of substates With their own versions of doActionO.

Template

Allow an algorithm to execute partial variants at runtime .

Organize the huge number of traffic light algorithms in a city by arranging them into a few basic forms, with variants tailored to specific locations.

Have a base class contain an overall method, but with functlon calls where variability is needed. Have subclasses implement these function calls to capture the reqUired variability.

on the data in a single object. Design a way in which they can be updated when that single object changes attribute values.

17.4 CHARACTERISnCS OF DESIGN PATTERNS; VIEWPOINTS, ROLES, AND LEVELS DeSign pattems are partially described by class d iagra ms, but they also ca n be th oug ht about in two ways. th e stolle and dynamic viewpoin ts of th e pattern. This secti o n cxplui ns these two view polIHs. It also describes th e' (fbstracl and non· abstract (concrclc ) levels of design patterns FI nall y I it' covers the ways I n which de ign patt~rn arc embedded In applications, The st'luic vs. d ynamic vicwpoim~ . ab tra ct '"S. conCret(' levels. and embedding issues are acwally characteristic of mOSI deSig ns, a nd are not Itm itcd to de ign patterns, These characteristics arc su mmarized in Figures 17. 14 and 17. iS .

CHARACTERISTICS OF DESIGN PATIERNS: VIEWPOINTS. ROLES. AND lEVELS

• Ifinopo,"ls-ways to descnbe patterns I . Sialic, class model (building blocks) 2. Dy>lumic, sequence or state diagram (operation)

• wls--
• Roles-the "players" '" pattern u age I. AppllCutloli of the design pattern itse lf 2. Oi,,,I, of the design pattern application 3. S,lup code initialize and controls FIgure 17.14 Some characteristics of design patterns. 1 of 2

(class O( classes)

1.-CII"", - - -role -- "-

_ --

I I I

I I I I

-- ---- --

-- --,..

3. Role: Application of the design panem A. Static viewpoint

B. Dynamic viewpoint

,-------, : A 8 ~ 0) Abstract level

,_-

',.L

:C

I

D

: (iI) Concrete level

DOD

•

_ _ _ _ _ _ _ _ .J

(sequence or stste diagram)

(crass model)

- - - -> : Reference dIrection

(class or classes)

Figure 17.15 Some characteristics of design patterns. 2 of 2

17.4.1 TWo Viewpoints for Describing a Pattern: static and Dynamic DeSign patterns arc dlustrated with class models. showi ng the cia ,cs "wolved and their mutual relation h'l)s, this IS a stallCviewpoint

orthe pallcrn

The function, of thc'\(" c1as .. cs execute:

In

panlCular sequcn c , ho \\revcr,

which class models do not illustrate Th is is the dyn"ntlC ViewpOint 01 the poltern . and reqUire, appropriate means of exprc~slOn .

We'll use the Kit hen V fewer eXJ mplc to IlIlI~lratc the: ~tatlC and dynanll viey,r po lIll\ The StJlI VI(,WPOlllt was shown in Figure 17.7. TIm ViewpOin t doc< not
PI

rure T () cxprc.., .. the

d y namiC VICWpO lIll ,

we often U~l' ... cquence

dlJ 8r.l 1ll'. J" IlIlI,lrillC

I In

397

398

CHAPTER 17 SOFTWARE OESIGN PATTERNS

Cllont

I

I

mvStyle.KlfchoflStyle

,,

rr __ ~m~YS~~~le~.~~~~ ~ Lf. gelWauCabinotO

- IFmyStyte BELONGS TO ModOmKS'Y'<>-

------, waltCablnet I Mode rnWallCa binOI

myStyte: ModemKSlylo

,, ,

rendcrKItcl'len (myStyte )

gOIWallCabinetO MOdomWallCabinotO

l1 I

- IFmyS'Y/o BELONGS TO AnllquoKStyt"', wallCablnel1 : AntlqueWaJICablnel

myS~I. :

AntiqueKSlyle

, ,I

:__~g~.~IW_'~I~IC~'~bi_ne~I~()__~ AnllqueWaliCablnetO

~

'11

I

Figure 17.16 Abstract Factory sequence diagram (or Kitchenviewer Figure 17 16. It shows the dynamic vIewpoint of the KltchenVicwer application of the Abstrac! Factory d«ign pattern .

17.4.2 TWo Layers of a Pattern: Abstract and Concrete allct: that within the KitchcnVlcwer Abstract Factory pattern application , some of the classes are abstract. In conformance with Gamma et al. [ I ] we wi ll ca ll non·abst ra ct classes "concrete." Figure 17. 17

, "

, , ,

" KlfchenSty/e

, , '

, ,"

, ' '

"

,

,

,

•

,

•

• • • • ••

,

-,

Waf/Cabinet

• • •

,

-,

"~ ~...

FloorCsb,oet

Abstract level •• Concrele level ...JO

+

KHchcnJ O

ModemWaUCab'nel MOdomKStyle

,, '

'-

,

" '"

'

" ,

'

"

AntiqueKStyle

AnllqueWaUCablnet

----

"

••

"

'"

• - ,P'.-

, , , , , ,

"

,

•

, , , , ,

,

,

•

•

,

ModemFloorCo.l)(net

-----. ---- ---- -- ---.

Figure 17.17 Concrete and abstract layers in design pattems

, ,

--

AnflqueAootCabtnGt

CHARACTERISTICS OF DESIGN PATIERNS: VIEWPOINTS, ROLES, AND LEVELS

",arrang~ th~ physIcal placement of cia C In F;gure 177 to e mphasIze the abstract and conc rete groupings ailed Ill),'" Th~ mterface of cl,ents with a design palte rn application u ually needs to be at the abstract la yer. This can ~ s~en in the code for rmd"Kitd"!l O, which is wntten in term s of KltchenSt)'le (and doesn', reference ModemKSryle o r A!lloqu,KSt),/e ), W.II .bl/ltl (not ModentWallCabl!lrl o r AHloqueWaIlCabm
17,4.3 Three Roles Involved in Pattern usage: Pattern Application, Client, and setup This section cxplains the th ree pans orroles-on volved in the usage of a desIgn pallem on a design. n,is dIScussion is designed to help the srudenl surmount common problems uSIng design pallerns. The thrce roles arc as fo llows, • The applicati o n of the desig n panem itself • The code that uti /o zes tim application (the "client role") • The code , of required , that inot ializes or changes the desig n panern application (the "setup ro le") These theee ro les arc shown on Figure t 7. 18, and arc explai ned next.

17.4.3.1 The Design Pattern Appl ication Role A design pattem-the desig" pa llcrn appllCn loo,,-involves a specific class model. For example , K,tchenVicwcr, described in this c hapter, contains an appl,cation of the Abstract Factory design paltern Th is is the ubstance of the d~ign pattern .

17.4.3.2 The Client Role Many pans of a program can potentially usc a desig n pattem application We usuall y rde r to these pans as eli", " of the paltem application. Each client is typicall y a method, but we often regard the method's class as the c/oent In

1. Deslgn PaNem Application

2. Client Rote

I Interacts with the design pat/em only through Its Interface r

3. Setull. Rofe No limitations

DPCllent

,,

-

, I, ,

, ,[}:;~--

-- --

Res' of the A[!()tication

,.

--, DPlnterface I

,

,,

, , ,

, ,,

,

Interface to the pattem (frequently abstract; possibly

I

several classes)

---- ------ -- --------.

------

0 0 0 0 0 Flsure 17,18 The three roles Involved In design pa ttern usage

-- -- -

--~

Rest of the design pat/ern application

J

399

400

CHAPTER 17

SOFTWARE DESIGN PA TIERNS

1<,

Ihe K,t henV,ewerd<""lln, for example, the ,,,,dlrK,1 ImtO method chen l of the dec methods and cI",scs onSlitule the ",,,,mce of the pallern apphcat,o n. In the case of the K,tchenVicwcr deSign, for ex,mple, the '"terl.ee con"StS of ti,e cia, e K,lc/'",Sry/" K' ICh'fI, WoIICnb,,"I, and Floor au",,1. I,ents may nOlrder to any other parts of thIS p'lIem app /'callon, and they generally do not overlap the desig n pallern ,pplicatlon.

17.4.3.3 The Setup Role The third role involved

the usage of design p.llems is not terribl y Significant. but o ne ca n get co nfused If o ne docs not recog 01 zc its pn:sc ncc: and necessi ty , It co nsists of the code that initiali zes o r hangcs the design pauern applica non code at runtim e. YOli ca n think of th is as a ja nitoria l or housekeeping-role In th e KitchenV,ewer des'gn , fo r example, cI,ents specifically do not reference particular styles, such as Mod,,,,KSry/, Reca ll that rrndrrKilc/'",O takes a Kilc/',,,Slyl, object as parameter, and deliberatel y docs not rderence any subclass of Kilch,,,Sry/c. How arc these speCific style objects selected and instantiatedl Th, s is the task of what we w.ll call the Stlup rol,. In the KitchcnViewer de 'gn, ,t is the code that r« po nd to cl icks o n ,he "Style" buttons ," Figure 17 4 by ,"Slantiallng a Kitcb",Styl, object and calling ,mdrrKitcb,"O wi th this parameter va lue 10

Setup code needs access to man y parts or the applicati o n, is no rmall y runtime inten ivc , and is ty pically no t Intended ror reuse Thi is becau e it tend s to be speci al to th e application and beca use it d epends o n too many other classes. O nc can think of the setup role as not overlappin g ei th er the client o r the design paucrn

application, although both arc possible.

17.5 SELECTED CREATIONAL DESIGN PATTERNS 11,is section dcscnbcs the SIOgleton and Ab tract Factory design patterns as examples of creationa l design pattems.

17 .5.1 Singleton

17.5.1 .1 Design purpose of Singleton •

Alt hough a typica l class allows the crea tion of many insta nct."S at nlntime. we ohen want a class to have exactly o ne instance throughout th e appli cati o n, and no more. For example, many applications maintain a profile of the use r. Often, there is no need fo r more than one U S(( instance at runtime . In f
DeSign Purpose Ensure that th ere is exactl y one insta nce of a class S. Be abl e to obtain the instance from anywht.·re In the appli ca ti o n DeSign Pattern Summary

Make the constructor of 5 private; define a private stallc .tt"bute for 5 of type 5, define a public accessor for it

Figure 17.19 DeSign purpose of Singleton

•

SELECTED CREATIDNAL DESIGN PATTERNS

We ",(er to the desired un ique instantia tion as the ""glrlo" of the class. and the class as a Smgltlo" class.

17.5.1.2 The Singleton Interface for Clients As an example. if an apphcation ha< a U", class as described above, chcnt mothods 'uch as ocrifyAcctSs() .nd snuIbn,,,IToU rr() would require a reference to the Si ngleton of Ustr To get the Si ngleton , they would con t.in • st.tement such. the following :

User user = User . getTheUser ( ) ; This requires that grln"Ustr() is a static method of LIm . NotICe again that a statement such as the (ollowing:

User user = new User () ;

would crea te a truly new U'tr object , fai ling to guara nt ee the require men t that th ere be only o ne U,,, instance.

17.5.1.3 TheS;ngleton Class Model The first issue is· where do we put the sing le insta nce of our class) We wi ll nam e the class in question S. A good place is within 5 itself, as a static variable. So far so good- but the problem is, what's to StOP another pan of the appliCation from including the following sta:emen t

S myVeryOwnlnstanceOfS = new S ( ) ; We prevent this by making thc const ructo r SOprivate. The o nl y remaining ISSUC is a way to obtain the singkton, to do th iS we include in 5 a public statIC acce sor meth od The Singleton design patlern IS actua ll y a specia l case of Factory in which the obje treturned I the o ne and only in tance of the class With the Factory met hod. Si ngleton IS thus in the Delegation form · the method getti ng the Singleton delegates ItS creation to the construc tor. The class model for Si ng leton IS , hown in Figure 17.20. Let's sum up thIS dl
MyOass grISmglrlo"OjMYC/fIl'() Our di'KuSSlo n on Inl(lcton doc not aU Io m.1I ally extend to clients operat ing "' parallel thread" needing a e" to a SlnK'c to ll abJeCl

401

402

CHAPTER 17 SOFTWARE DESIGN PATIERNS

Client

, I I

Singleton Design Pattern

I I I I

MyClass getSingletonOfMyClassO: MyClass

"

slngletonOfMyCla.. -static,.

1

FIgure 17.20 SlI7gleton class model

I . Dcnne a priva,. static member vari.ble of MyCiass of type MyCl.ss private static MyClass sing letonOfMyClas s

II:

new MyClass () ;

2. Make the constructor of MyCiass priv.tc private MyCla.ss () I / .

. . . . constructo r co de . . . . "' / ) ;

3. Dennc a public static mcthod to

.CtcSS

the member

publlC static f1yClass getSingletonOfMyClass ()

I ret.urn singletonOft1yClass ;

I

Figure 17.21 The Singleton design pattern, applied to MyClass

17.5.1.4 Example Singleton Application: "Experiment" Let's look al Ihe following example, An applicalion evaluates the results of lab experiments. The application for this phase does no substantive evaluation . takes no input, and always prints the (ollowlOg message to the console:

Tht analYSIS shows Ibal tin cxptrimrnr was n rtSo~"dj"9 success There is 10 be exactly one Exprri .."" objoct .t runtime, and it can be accessed by any mcthod in the application. Each time the method is called, it displays the following message on the console to verify it was called,

Noting thai the Exptn°".mt si"9'tfon rrjcrmc(d n limcs so

Ittr

The output would havc the appearance ,hown in Figure 17.22 . The simple c1.ss model for this experiment example is shown," Figure '7.20.

E_---

SELECTED CREAnONAL DESIGN PAffiRNS

Output otEng that the Expenmt", si ngleton referenced I tEmes so far The anal

SI

show that the experiment was a reliounding success ..

Figure 17.22 Output for Singleton Expe"ment example

E~ment IheEx~riment;

IClient f- - - - -

Ex

riment

theExperiment

analyzeO getTheExperimenr{): Experiment

.. static ..

reportResultsO

1

Figure 17.23 APplication of Singleton to Experiment example

17.5.2 Abstract Factory Now we turn our attent Eon to the creation ofjamilirs of o bjects. ThE S kEnd of problem was discu< cd En SectEo n 17. 1 using the KitchcnMasrer example.

17.5.2.1 Design Purpose of Abstract Factory Our design purpose here IS to create a fami ly of related o bjects, chosen at runtEme from several pOSSible families. You can ofte n think of a "family" here as a "style" choice . \VIc want to be able to ",nte code that appl ies to these families without committ ing to one parlEcular family . As an example, consider a word processor requirement that all ows th e user to view a document in everal styles Modern word processors all ow users to view documents in a variety of ways, for example, En outli ne form, shOWing only the headings. We w:ll si mpli fy this for Ellustration. TYP Ecal input to our pnmitive word processor i shown En FEgure 17.24 .

- Enter title , My Life

-

- Enter Heading o r '··done", Birth

- Enter Heading or "·done". Ad ulthood

Entcr text

I 8rew up playing in the wood

-+ Emcr text.

- EntC< Headi ng o r "· done· ·don(·

I was born In a sma ll mountaEn hut - Enter Headlni( or "·done·'· Youth

Flcure 17.24 Word processor Interaction,

(toll

1

of 2- lnput

""!ltd )

•

403

404

CHAPTER 17 SOFTWARE DESIGN PAITERNS

1

....

." .

» Enler Ihe style you wanl displayed:

» Enter tile style you want displayed:

big

small

Option 1

,

Option 2 My Lile

--- Title: MY LIFE ---Section 1. - BIRTH -I was born In a mountain hut ." .

Birth I was born in a mountain hut .... Youth

Section 2. - YOUTH ---

I grew up sturdy ".

I grew up sturdy ... Adulthood Section 3. - ADULTHOOD --•• • •

Figure 17.2S Word processor interaction, 2 of 2-output options

The application prints the document in a variety of styles. For si mplicity, we will use ,mall and big styles. In ,mall style output , all headings are in left-justified lowercase a nd end with a colon. In bl!! style they are capitalized with sectio n numbering, and so o n . The tide a nd the various subheadings appear differently in these IWO styles. \VIc can assu me that mo re sty les wi ll be required in the future . The o utput for "small" a nd "big" styles is shown in Figure 17 .25 . \Vle want a design with a clean separation into the wo rd manipulC)tion pan and the srylc choice part. We

capture the various kinds of headings wi th classes In general , a · style" In volves a fa m ily of classes. For example, CapitalStyle ,nvolves the classes Capit"ITit/e , CapilalLc"elrHcndin9 , Ca," laILevei2Hcnding , and so o n, so the proble m is to be able to c ha nge the fa mil y at run time . The purpose of Abstract Factory, as expressed by Gamma et aI. , is as shown ,n Fig ure 17 .26. The rest of this sec tion explains the pattern that fulfills this purpose

Design Purpose "Provide an interface for creating families of related or dependent objects without s pecifying their concrete classes .'"

Design Pattern

Capture fa mily creat ion 10 a clas comaining a facto ry meth od for each class in Ihe fa m ily . Figure 17.26 Design purpose of Absttact Factory

'Erich Gamma e( ai , "D~19n P;1t1C!ms, E1c.mc.'nts of Rcn~ablC' ObJC'cl ·OncmC'd Software: Addi~on . \'(I~.h~y. 1995.

--------------------------------~-------~

SELECTED CREATIONAL DESIGN PATTERNS

Client

Ensemble setAbSlraC1FacloryO doAFunclion()

'"

-"

-"

-"

-" -"

-"

-"

-"

I I I

I I I

\

I

\ \

I

\

\

I

Abstract Factory·

\

Sty leA Factory

......

"" "" ""

\

I I

\\ '<.,. . . . . .......... \ " .......... , "

StyleBFactory

AbstractFactory getAPanl0bjeciO getAPal120bjeciO

""

"

Style ....

..J

• relationships within panem apphcallon not shown

Figure 17.27 The interface to Abstract Factory

17.5.2.2 The Abstract Factory Interface for Clients Oient code has acce£s La the ent ily 10 be co nstructed wilh Ihe fa mll, es We wi ll name Ihis class EII s""bl, In general. The class AbslraclFaclory encapsu lates the sryle of Ihe EII" ..bl, pans. The Inlerface fo r the client has the appearance of Figure 1727 . For a discussion on a narrowe r intcrbce alterna tive using the Facade deSIgn pattern , sec SectIon 17.6. 1. I . Fo r our word processor example , the role of EIIs""bl, would be held by a class such a OocllmClfl, wh,ch

suppo rts methods dependent upo n Slyl, (our Abstract Factory). First the chent or setup code-ha to determine the required sry le, ty pica lly de pend ing o n use r input as in the fo ll ow ,n g

Style currentStyle; ... II interact with the user currentStyle = new SmallStyle ( ) ; _ . . or curren tStyle = new LargeStyle ( ) ; •

•

•

document . setStyle ( currentStyle ) ; O nce the ty le has been sc t, the client makes calls to OocII,"rll l uch do ""'rIIl dlSplay(J. A cia. model for thIS would have the appea rance of F,gure 17 28 . But what does a "sty le" cla.s look hke, and how does it ac hieve our purposesl

17.5.2,3 The Abstract Factory Class Model The Abstract Factory deIyle cI~s,cs ,s nJm ed Abs lflltlF" lory The ,dea IS that e.ch AbslrtICIFtlCIOry ,ub Ia<' In lerprets ,I> fa~lory m e l ho ds to produce obit I> of, s,ng le,t Ie Abstract faclory IS ,n th' dcle/(.lIon form , dd el!a llll ~ the "ge lle r " of Ob,CC h 10 Ol1, lru l(lro. all In Ihe deslfcd style

405

406

CHAPTER 17

SOFTWARE DESIGN PAITERNS

Document

Slyle

setStyle() display() /

// r---'---, r - - - ' - /' Small Style LargeStyle

/ / /

/

/

/

/

//~----:::-------

--- -r':'" ~~ /

/ //

"

/

•

•

•

• • •

•

/"

IClient

L _ _......:.A.::p:.::P:..li.:.ca.:.t:..io:..n_o .:.'.:.A .:.b:..s:..l.:. ra_C_1

_F._a_cI_o-,ry~

FIgure 17.28 The interface of Abstract Factory applied to word processor example

For th.e "ke of SimpliCIty we wi ll iliustTate this with just one sty le to beglO with . Let's call the class whose complex objects arc to be constructed, ElIsrmblt. pigllre 17.29 shows how E" Stmblt objects are constructed in a style encapsulated as SlyltA . E"s""blt consists of parts, Pari' objects, Pari> objects. and so on. The attribute abslraclFaclory of E" s""blt is instantiated with a SlyltAFaclory objec, 10 ,his case. When a Pari' objec, is required, the gtlAParl,Objtcl() method of abslraelFaclory is c,lIed . The virtual function property implies Ihat the gtIAParl , Objtcl() method of StyltAFaclory is actu,lIy c,lIed, ,nd it returns a ParifStyltA object. Similarly, when griParl2 0 bjtcl() of Ens""blt is called. it returns a Parl>StylcA object. Thus, all of the parts obtained are in the same style . 11,e p,rtial class model is shown in Figure 17.29. The full Absiraci Faclory class model . with two styles (AbslraclFaclory subclasses) is shown in Figure 17.30.

As dIscussed in t'he section above on client intcrf-accs, the client may interface with the AbsrracrFacrory ,nd PariX classes bu, specifically not with Ihe ,ubclasses of Par" . Pari> , and so on .

Ensemble r I 1 1

I

aMb.&::tFaclory

AbstractFactory gelAPan lOblectO golAPar120blectO

1

selAbstract FactoryO doAFunctionO

y Part2

I I

L C.

1 1

1

I I I I I 1 1 1 1

I 1 1

7'i

Part 1

-1

I

I

Part! StyieA

"

I 1 1 1

I I I I

Part2StyleA

1 1

,,

1

.........................

,,

, ,

-cr.e. ........

"

,

,

,

StyleAFactory

:.J:~panl0biectO

IAPar12Objoe'O I

------------ ---- - - ---- ----- - - - -- Client

Figure 17.29 The Idea of the Factory design pattern

I I I 1

I I 1 1 1

I I ----

SELECTED CREAnONAL DESIGN PATIERNS

-,

AbstractFactory 1 getAPartl0blecl() getAPart20blecl()

abstraclFaclory

Ensemble doAFunctlonO

1.. n

1..n

Partt

-I I ~

Part2

Part...

I I I

I I

I I

I I

Part1 StyieA I I I

I I I I I

"-

"-

Part 1StyieB

.... .... "-

"-

-creat... "

I

....

"-

,

"-

"

.... ....

.- " "

.... " ,,,' ," .... , , .... .... " .... ,- " "

Sty leA Factory

I I

Part2StyleB

Part2StyleA

""C"- _

,-

,-

,-

StyleBFactory

-- - --- --

I I

I I I I I

I I

Style ....

I I I I I

~

_ -'7

Client

-----------~

I1_______________________ _

Figure 17.30 Abstract Factory

17.5.2.4 The Abstract Factory Sequence Diagram A sequence dIagram for Abstract Fa ctory , including th e se ttlnB up of the parti cu lar "sty le" (the Ab,lracl Fa ctory object ), is shown In Figure 17.3 1

17.5.2.5 EXample Abstract Factory Application : Word Processor We now show the deSIg n of our Word Processor example USlnS the Abstract Fa tory deSIgn pattern The follOWing use ca es describe the app licalJon View a Docume nt Precondition : none I ApplICa tIon requests the tit le of the do umenl

2 US" provlde< th e litle

3. The "Headlngffext" usc case (see below) IS executed unttl the user enters "do ne"

4 AppllCa/lo" reque tS a style (r01l1 a lISt

5 UStr ent ' r' a sty le from the It,t 6 Applica tion ou tpu" th e do ument to the monitor In the sty le r" rdere n cd above

407

408

CHAPTER 17 SOFlWARE DESIGN PA" ERNS

:Cllent

:Ensemble

abstractFactory :StyleXFactory

r

abstractFactory :AbstractFactory

I , ~

Style XFaclo

...J

0' Selecting

a sryle

setAbstraclFaclory (abstracIFaclory)

I

I .,..

:Pa rU StyleX

I

doAFunctlon O

----

Assume that this method

requIres a

./

-

""~

/

ParUobject

getAPa rUO

I I

ge tAPa rUO

...../1

Part.J SlyleXO Virtual

function

,•I

,

Creating

a ParU

objeclln required styIe

+rl

•

j

property

Figu re 17.31 Sequence diagram for Abstract Factory

Provide Hcadingrrext Preco nditlons- user has provided the title 1. ApplICa ti on reques-ts a header 2. Usrr provides hcadcr tcxt

3 AppJlca lrol1 requcs ts text 4.

U", provides tcxt to fit with thc header Thc class modcl IS shown In Figure 17.32 . T ypical output is shown in Figure 17.33.

17.6 SELECTED STRUCTURAL DESIGN PATTERNS This seClion describes the Facadc and Adap
17 .6.1 Facade: Interfacing with a Collection of Classes 17.6.1.1 The Design Purpose of Facade In bUilding applications we parcel out sets of classes to separate developers Th is reqUires the clear modularization of the design Developers typically require the
SElECTED STRUCTURAL DESIGN PATIERNS

Document geIAH.ad,ngO gelATilleO grtDocumenlFromUserO

r-------,

gelAHeadlngO

I Displa yable I

gelA Tit/eO

:

dlsplayQ

---

--

O•. n

L

O••n

Text• __ "-_--I Heading value v value '---

D,splayable

1

'--7\""',-_.J

~

I

I I

I I I I

I

value

:--7\:--

,

LargeHeading

I~

d,splayO

displayO

dlsplayO

- - -

:

Title

SmaliHeading

'--~---Ioj create» -

Style

style

~

r

LargeTitie d,splayO

~-~-r-~-~-~-~~~~-~--~----- - -

c.:::.- -

~

LargeStyle

gelAHeadingO

gelAHeadingO gelATille()

gelAnlleO ~,

_.:::7

Client gelStyleF romUser() dlsplayDocumenl()

Figure 17.32 Abstract Factory applied to word processor

-

Enter the title of your document·

MY LIFE - Enter heading o r '-done', Birth ......,. Emc r the text: I was born In a mountain hut

- Enter heading or '-do ne'· Youth '"""'7

Enter the tex t·

I grew up sturd y - Enler headin g o r '-done' -done - Enter the
- -T,tle MY LlFESectIon I J

IlIKTH-

wac, b(}rn In a moun lain hut

•

Section 2 Youth- I grew up ,turdy

Figure 17.33 InteraC110n for word processor applica tion

-- - ----------- --~

409

410

CHAPTER 17 SOFlWARE OESIGN PATIERNS

Desig n Purpose Provide an IIlter(ace LO a packa ge of classes. Design Pallern Summary Denne a inglelOn tha, ",he o le means (or ob,alll lllg (un c 'ionali ,y (rom ,he package.

Nol<, The clas,es need no ' be o rga nlZl:d as a package; mo re ,han o ne class may be used (o r ,he (acade. Figure 17.34 oesign purpose of Facade

'0

for developlllg, so ,hat classes and packages ohe n ,elalC each o,her as clien! and server. The client a nd server portio ns are deve lo ped re la'ively independently-,he problem is ,h., services arc typica ll y in va rious Sla' es o( comple
content, o r perhaps wi, h none at all .) Clients o( ,he package have a conc rete reprosen,a'ion of 'he package's fu nctionality to use during development . Th is Jdva ntagc extends to maintena nce.

If maintainers can upgrade rhe way in which

functionality is coded wi,hou , d islU rbing the fa~a de , 'hey can be assured ,ha, all clients of the package are not affected . The Facade objee, is a ,y picaliy a singlelOn . Figure 17.34 summan zes the design purpose and technique of Facade

17.6.1.2 Interface for Clients of Facade Suppose ,ha' a package contains a collection of classes and tha, 'he cl ient code, extemal to th e package, requires a «rvice myCMtlhod() provided by a class C in th e package The c1 ,en' may interface o nly with the Facade object, which we Will ca ll Ih,FacadrOhjrcl. Thus, the clien' code calls a method suc h as Mrt/)odOjFaeaa,Q of Ih,Facad,Objtcl in order to accomplish this purpose.

17.6.1 .3 The Facade Class Model The Faead, class model shows c1ien" inlCrfaci ng with a single class of a package, bu, With no o ,hers. Actually, there is nothing to stop us from designaring more than o ne class as a Fncadt class. The non-Facadt c1as es a~ no' ac"<sible to code extemal to the packa ge. The Faeaar structure IS ,n 'he Delegation form since the Faead, object delcgales commands classes intemal its package. This IS Illus trated In Figure 17 35 .

'0

'0

SELEC I EO STRUCTURAl DESIGN PATIERNS

, 1

Client

"-

..

-

" "This cat! repla ced

by t an d 2.

Fat;;ade

""

Client can't

- exposed.. cMelhodOfFacadeO

""

reference C

I I I I

"

2

I-not eXPOSed-I

I- not eXPOSed- I

C .. not exposed..

I.. not e~posed.. 1

myCMelhod()

I-nol exposed-I

I .. not

exposed.. j

Figure 17.35 Facade deSign pattern structure

A call that ",ould o ther"" e refer to an o bject o f a class wIthin th~ package IS repl aced by a ca ll to a method of the Farad, object ThIS metho d ca n then referen ce the obJect'" que
:Client

:C

si ngleton

'--

:Facade cMethodOfFacadeO myCMelhodO

(return it any)

---- -- - - - - -(relurn If any)

- --- ----------

Figure , 7 .36 sequence diagram for Facade

4"

412

CHAPTtR 17

SOFTWARE DESIGN PATTERNS

MyGameEnglne

MyGame . '6CJJde IJ

MyGameCharacters

MyGameCast f.,fsellde"

MyGameEnvironment

MyGameEnvironment ,.fscs del>l

Figure 17.37 Using Facade for the architecture of the Encounter video game

17.6.1.4 Examples of Facade Applications

17.6.1.4.1 Using Facade for a videogame Architecture use o f FacJdc In the arc h itec ture of a vi deo ga me is shown In r:l gurc 17 .37. The ga me's classes afC divided Into three packages. One pe rta ins to thr c harac te rs that move abo ut, the seco nd co ntainS the classes thal desc ribe t he maze, and the third co nta ins the co ntro l of the ga me. Communica tion with ga me c haracters must occur via th e si ngle MyGamcClISt o bject. Refe rence to parts of the ga me's e nviro nment must occur lhroug h th e JvlyGamrE,wiro"mClf l o bject, and references to the game englOc mUSt occ ur 'hro ugh ,he MyGa m( object.

TI1C'

17.6.2 Adapter: Interfacing in a Flexible Manner 17.6.2.1 The Design Purpose of Ada pter Su ppose that a preex isting app li cation, o r eve n just a preexi ting object, prOVides functionality that o ur applicat io n req UIres. For exa mpl e , th e exis tin g appli ca ti on co uld co mpute the pnncipal Design Purpose Allow an app lication to usc ex ternal functionality in a rctargcta blc manner.

Design Pallorn Summary Write the application against an abstrac t versio n of the ex te rnal class, introduce a subclass ,ha, aggregates 'he exte rnal class. Figure 17.38 Design purpose and summary for the Adapter design pattem

SELECTED STRUCTURAL DESIGN PATTERNS

obtained trom \nVC ling .ll!pv<:n amOunt (or a given number of year In a pcclaltypc of Investment , and WC' want to u~c lhl) (lin [tonality In u~ing Ihi~ functionality . however, we want to modify our own

application as Imle a po<slblc . \VIe also w.nt to be able to easily witch to alternatwe ImplementatIon> of tht· required functlonaltty F,gure 17 38 ummartze the e purposes and the baSIC Adapter technIque

17.6.2.2 Interface for Clients of Adapter The "client" IS the apphcatlon that must 1I e the ex. ling funcnonahry We create a deSign

In

whICh the chent

doe not directly Interract' wtlh the t:XiSllflg fun uonalay, however In lead. It Interra cs with <:In Clbstracl

method of an app roprtately named ab trac t class. The laller must be In tan!tated al runtime with an object of a concrete ubclass. as exp lained next.

Let' call the ab,tract cia

AbslrnclClass . and ItS relevant method we need sta>ldllIForR
· -. - . AbstractClass anAbstractClassObject: ... .. II setup code instantiates ... nAbstrdctC!a.s"Ob)ect •

•

•

•

anADstractClassObject.clientNameForRequ1redMethod() ; Il usetheexternalfunctionality •

• •

• •

Setup code , tYPically executed at initialization , must in tanliatc cwAbslraCICltlSsOb)(ct at runtime In

somethIng like the fo ll owing manner.

• • • • •

if(

...

{ •

)

Ile . g .,

•

•

from a setup file anAbstractClassObj ec t = new ConcreteSubclassOfAbstractClass ( ) ; •

17.6.2.3 The Adapter Class Model The d ..s model for IIdapt" IS ba ed on ,he delegation foml because an Adapl" o bject delegate> the o mmand to the tars,;eted ommand , as
17.6.2.4 The Adapter sequence Diagram Adapter works by handIng off function ca lls to cilclltNllnt,ForR,qllll"iAI
413

.1.

CHAPTER 17 SOFTWARE DESIGN PAmRNS

alent

adaplee

( ad'poee.requlredMoUIOdO:)

I

Figure 17.39 The Adapter class mOClel

:Client

I :AbstractClass I

:Adapter

•

d 'entNameFotftequ1redMethodO

I I I I I I I I I I I I I

adaptee :RequiredClaSS

RequiredMelhodO

Figure 17.40 Sequence dlagram for Adapter

17.6.2.5 Example Applications of Adapter Lds consider a Rnanci.1 application that needs to use the met hod

computeValue( float years, float interest, float amount) of a legacy class Pn"cipit . We want to b<: ab le to e.sily switch to other impleme nt.tio ns of th is functionality if necessary. We write our applica"on by giving our own names to the function of interest, and the class/object that owns the function. For example , we can name a method as follows,

.mount ( float or iqinal"mount, float nllmYears, float intRate ) in the class F""",cial. This cia" is made abstract, as illustrated in Figu~ 17.41 .

SELECTED STRUCTURAL DESIGN PATTERNS

AI!~lIcation

., Ada~latJon

Legacy system

Financial amountO

Principle computeValue()

...J

Client

FinancialAda pter

IOO)cyAdolplee

amountO "

"

.-------~~~----. (

legacyAdaptee.computeValueO: )

Figure 17.41 An application of the Adapter design pattern

The Adaprc::r design pauern in this case co nsists of a class, which we wli l name: FlllulICltJ lAdap lt r here, ",hlch onherits fro m the application' c las (Flllllllnal on ou r case), and whIch aggregates the legacy cia s Pmlnpal. This could be Impleme nted as follows .

class FinancialAdapter extends Financial {

Pr incipal legacyAdaptee = null ; / / Constructors go here . . .

/**

This method uses the legacy computeValue () meth od * / floatamount (floa toriginalAmount , floatnumYears , floatintR ate) {

return legacyAdaptee . computeValue ( originalAmount , numYears , i ntRate ) ; }

}

The new application IS W,;ltt'l aga inst the clas ... Fmannai , but o 'cudcd at runt ime with

OJ

FmtH1CIaiAdapltr

object Setup code instantiates the Flt1tHlClfil obJcc t a'\ a FlllolicIfI1Adtlptr Insta n (' For example , the

be wflttt'n

w ith a method parametenzing Fmatl cw/ , such a~ th c

Ilcnt cou ld

roll0,o,I,ng

void executeF inanceApplica t ion ( F inanc ial aF inanc ial ) ; It cou ld ,hen b~ exe~utl·d "",h ,he followIng s" rr p 'tatement th"",,llZe' ,h e opprop""c ,ciop,cr obIt: t

executePinanceApplication( new FinancialAdaptcr () ) ;

41 5

416

CHAPTER 17 SOFTWARE DESIGN PATTERNS

octlonListencr

ActlonLislener Resull 0 1 bunon (!f§SS

MyBulton

MyClass

addAClIOnUslenerO

myMethodO ~

Mylistener ~

actionPerlormedO

Figure 17.42 Adapter and the Java API

'0

All ca lls the amo unlO method of Fillan,ia/ arc passed to the legacy method compulrVa/urO I. IScasy to adapt the applicatIon to an implementation ofamo,,"10 in a new class. We would on ly ha ve to change the code on FinmlCialAJllplrr. The rest of the applocallo n would not be affected. Being able to re target code by makong loealozed c hanges like this is valuable for development and maintenance. The alternative is making changes

In

mult iple locatio ns, which is error-prone.

17.6.2.6 Adapter and the Java API arc adapters for the following reason. Suppose that we want myMrlhod() in MyOaS5 to execute whenever myBllffotl is pressed.. T o do this , we introduce a class MyListrncr that implements thc ActionLslcncr onterface . The class model is shown on Figure 17.42 . The class MyLis lrtl cr IS the adapter class in thi s casco At runtime ....u: ca n insta nt ia te aclionLisltH" with an Acllotlustcntr subcla ss in lance slich as MyListtncr, according to thc effect we require when the button is clicked. nle code in Myl3ulto" rderenccs only Acliol1USlt1ltr, not any particular subcla s.

lava

liSlClftr5

17.6.2.7 Comments on Adapter • Instead of aggrega ting RrquirrdClass on Figure 17.39, we could onherit from it, as long as the language allows multIple inheritance. Thi s is shown in Figure 17.43 .

AbslractClsss

Cllen.

(

Figure 17.43 Adapter example inheritance version

requtredMethod():)

SELECTED BEHAVIORAl DESIGN PATTERNS

~ ' c m. , be .tlSfied to make Abslra 10alS an Interface If the language does not suppo rt multiple ,"hentJn c le g ,I.va) • Adapter

IS

often usC' d when we

reate an application U1\lng library c1as es. bu t where we want to retain the t other "brary clas e< For ~xampl e . we n1lgln use Verlo, In a Java application to store a

lle.,ib,l, ty to >ck· oilcctlo n, but find that It I> ,omcwha t awkward for the purpo e In question. \'(Ic could rhen de Ig n and code thc application so that It use. an Ideal class of ou r IIl ve nti o n to store a co ilec tl on (e g., AUlomobilts ,vith meth ods SlonA IIIO() e tc,), Then we wo uld incorporate a n adapter to fit th iS to Vrrlor \'(Ihen a mo re " " table o ilrc tlo n managemenr

l as~ appears, we could then ea

dy retarge t to

it , nceding to change onl y rhe adap ter

• Rewrntng (0 the fina ncial example, lO preserve the opti on to retarge t a1 runtim e , we cou ld rela in

FuulHClalAdap'rr, but Int roduce a new Adaptu class FlllmlClnfAdaptrr2 , inheri ting (rom FU1anCIai Whenever we want to targe t the application to the t(o nd lega )' SYCi lem , we wou ld execute th e applICatIOn Wit h the

following .

execut eFinanceApplication( new Financ ialAdapter2() ) ;

17.7 SELECTED BEHAVIORAL DESI'GN PATIERNS This seClio n describes the Interprete r a nd Observer d t's ign patterns as exa mpl es of particu lar behaVioral design patterns.

17.7.1 Interpreter: parsing Expressions 17.7.1.1 Interpreter Design Purposes and Examples Appl icati ons must somellmes deal wit h n:prcs5Io"S written Ir. J grommar. A comp lier, fo r example, must deal with r xpressions wntt'c n in the grammar of a programming languJge. Compdcrs are th e: most common example,

but the,. arc many other needs for the interpretation of g rammars, The following X/l.tL, for example , IS an expression, and the gram mar (ca ll ed a sci",,, • . no t exp liCi tl y g ive n here ) >pecii;e the permISSible form for the XML used In thiS context. •

«engl.neer > > « nam e» John Q . Doe

« /name» «task» Un iversal payroll Application <<' /task > > «task>.lnterglactic Web Site Analyzer «/task>.<.-task»

417

"a

CHAPTER 17 SORWARE DESIGN PAffiRNS

Financial For ecaster «/task» «/engineer » Our purpose is to desig n an interpreter for gra mma rs. In th e XML example, our Interpreter should ~ able to interpret the fo llowi n g expresSIO n as we ll .

• «engineer» «name» Sue W. Smith «/name» «task» Fr iendly Server Application «/task» «task» Intergalactic Web Site Analyzer «/task» «/engineer»

There are two parts relating to the Interpreter desig n pattern : pars"'9 and inlcrprcting . Parsi ng is the process of converting an input-usually a string-into a trce of objects consistent with rhc c lass model . In the XML example, this would include picking o ut individual pieces suc h as the engineer's name. Interpreting consis ts of performing useful functionality with the result of the parsing phase. The purpose and baSic technique of Interpreter are summarized in Figure 17.44.

17.7.1.2 Interpreter Interfaces for Clients Once an expression has been parsed and represented usi ng the Inltrprder class model , clients interface with an Ab.t,acIExprnsio. object that is the root of the parse tree. The client typica ll y ca lls an i."rprt'() method o n th is

Oesign Purpose Interpret expressions written

In

a fannal grammar.

Oesign Pattern Summary Represent th e grammar using a recursive design pattern fonn : Pass the: interpretatio n to

aggregated o bjects.

Fllllre '7'" Design purpose and summary of Interpreter

...----------------------------....

-

SELECTED BEHAVIORAl DESIGN PATIERNS

Client

- - ------

AbstractExpression inlerprel()

Figure 17.4S Interface to Interpreter design pattern

objecl. In the above XML example, suppo e that the twO express,o n formed by parsmg the twO 'nputs are joh.Do,XML and "" ""IJ,XML Suppose that the appitca l10 n IS Intended to co nvert XML to conversano nal pro e. When the client execute Johl1DorXA1L '"trrprd(). the fo llow m8 m' ght be output

En9'"W Joh" Q Dor IS ••o.king Oil th, joJJowI119 Ihm prowls, UI1 ..",,,J PnyroJJ AppJi "lrOl1. J"trrgnlaclle W,b Sift A"alyzer. mid Finml ial ForcctJStcr.

The class model for the clien t/deSig n pattern Interface looks like F'gure 17.45

17.7.1.3 The Interpreter Class Model The Interpreter deSig n paltern has th e Rccurs l v~ (orm because ex pressIO ns can con tain fu rth er expressions. The class model is showr. in Figure 17.46

wh ich the Interpretation function IS simple, or No" Tm"il1"IExprrssion o bjects The latter aggregate Ab, lrll IExprrsslon objects ,n turn The ,"I,rprrt() /unctio n o n a NOl1Trfmm"IExprmiol1 objec t operate by perfo mllllg required work o n the object It elf. then essentially commanding each of Its aggregated AhslraeIEx!)((ssiol1 objects to execute Its mlrrprrl() method. Th IS has much in common wit h the dynam ic viewpOint of the Composite design pattern AbstractExprcssJolI objects are ei th er TcrnliualExprrssioll objects,

0 11

17.7.1.4 The Interpreter Sequence Diagram The sequence diagram in

F,gun: 17..17 cap rure s th e Intcrprctilt ion process.

17.7.1.5 Example Interpreter Application: Network Assembly As an example of In terpreter. consider an applicat ion that handles orders from customers fcr networked computer systems, and genera tes installation ins[fuctlons Forcxali1ple,conslderthcorderrora network shown In Figure 17.48.

IClient ~-

------

AbstractExpression Inlerprel()

TerminalExpression InlorprolO

Figure 17.46 The Interpreter design pattern

1..n

Non Terminal Expression Inl.rpralO

419

420

CHAPTER 17

SOFTWARE DESIGN PAmRNS

:Client

AbstractExpresslon NonterminalExpression

:NonterminalExpression Interpretl)

... ..

create and interpretO

TerminalExpression

~

create and InterpretO

...

..l.

Figure 17.47 The Interpreter sequence diagram

It con
a 8001\ Ihz system wi th 768M B of RAM a 5001\Ihz system with 51 2MB of RAM T h ,s is Ill ustrat ed In F,gure 17.4 8. Th iS o rde r ca n be expressed usi ng the fo ll owmg ex pressio n

{ ( 700 51 2 ) } { { ( 800 76 8 ) } { ( 500 512 ) } }

assemble .. ..

800 Mhz and 768 MB

• .

-

"'-; .

700 Mhz and 512 MB

500 Mhz and 512 MB Figure 17.48 EXample of a virtual machine " program" SOCICf GraphicS reprodU(:.ed wttrl pel " ,!ss'on from Corel

twO

SELECTED BEHAVIORAL DESIGN PATTERNS

ll,e ou'pu' prod
IS

All 110 is to th e console .

as fo llow

1 The application prompts the user to enter an order

2. The appit at ion d,splay the gramma r to be u cd. 3. The apphcat, o n display, an examp le

4 . TIle user e nters an order.

5 The appit ca t, on echoes th e o rd er. Figure 17.49 speciAes th e grammar for th e orders and hows typ,ca l inpu t. The ord er exa mp le ,n Figure 17.49 is ,ndeed a legi tim ate expresSIo n in th e grammar speCIfied , as the fo llOWing veri Ae . co mpo nent -

nc r sys tem

{

-lo

} { comp o ne nt } -

component

{{ compo ne nt } {compo ne nt} } { computer { { { compo nen t} {compo ne nt} } {computer }} { (cp u ram ) { { {compute r } {computer }} { (cpu ram ) }} { (444 -1-1 ) { { { (cpu ram) } { (cpu ram ) }} { (333 33 ) }} { (44444 ) ( { { ( 11111 ) } { (22222 ) }}«33333) }}{ (44444 )

}} ~

}}->

}

The output of the interpretati on process-instructio ns on how to assemble thi S ncf\.... o rklng ord er- are

as shown in Figures 17 .50, 17.5 1, and 17 .52 In this case, th e user se lected th e exa mple prov,ded by the application. Our Arst ta k is to parse the ,nput and create the corresponding set of aggregated objects. After that, t he output is generated in respo nse to a clie nt ca ll ing aNr,workOrdtr.asscmblr(). ll,e metho d a"""blrO takes the place of ,",crpr<'O in this example , The Inte rpret at, o n of a primi,i1lc e lement alone (e.g .• a CP U In the examp le ) 15

Please deSCribe a network on one line uSing th e follOWing grammar for 'component ' Blank paces arc ignored . compo nent :; = net system I comp ut e r net system . = { component 1 { component computer = (cpu ram ) cpu-:

1 1{ compo ne nt 1

= Intcger

ram - = Integer xamp lc: { { {(400 4 111 ( 900 3)) 1 {( 600 3)1 1 { (750 10 ) 1

An '"put With a sy ntae ll

{ 1{( 11

I I I ill (222 22 ))

<"rror w,lI be iJ.:norcd With lit comment.

1 {( 333 33 )1 1 { (444

You chrxe { { {( III Il ll1 (222 22 ))

44 )

1

1 {(3 n 11 )111

Aaure 17.49 Input loe networ1< assembly example

( 44 " 44 )

1

421

422

CHAP I ER 17

SOFTWARE DESIGN PAffiRNS

Pk.se de>eribe • network on one line USI08 the (olloWIOB grammar (or 'compone nt ' Blank paces arc ,gnorod. Inputs w,th sy nt.ctic error< will be ignored withou t comment. component ::

= net system I computer

net system ;: = (component ) (component ) computer ;: = (c pu ram )1 cpu :: = Integer ram :: = integer

I (component )

Examp\c, ({{( 400 4 )){ (900 3)1) {(600 3»)) {(750 10») {{{ (400 4)11 (900 3) 11 1(600 3)11 {(750 10 ») .. . Do some work with the order . ... Assemble a network from either one or two parts as (allows,

'* F,rst Part, Assemble a network, which we will name 'component 1', as (allows, Assemble a network , which we will name 'cornponent2', from eit her one or two parts as follows ,

-

Assemble a network, which we will name 'component3', from either one or twO parts as follows ,

-

Build computer component3 , (rom th e (allowing parts, CPU with specifications . .. . .' 400 and Figure 17.50 Output for network assembly example, , of J

si mple (see the CPU class

10

the listing). What remains is to execute an i"trrprrt() function when applied to a

morc compl(x expression.

Applying the Interpreter design pattern to the netwo rk order example, we obtain the class diagram shown in Figure 17.53 . For simplicity , we assume that every network consists of just two components , so that each SyS'tmr object aggrogates two Compo"",t objects. This can be easily extended to mar< than two. The so~rce code for the implementation is contained in the accompanying textbook Web site.

17.7.2 Observer 17.7.2.1 The Design Purposes of Observer Softwaro roquiremenlS and design frequently involve a source of data, together with a number of chents that must be updated whenever the data changes. As an example, suppos< that the headquarters of Internation.1 Hamburger Corporation maintains data on its s(rvcr abour hamburger ~11es throughout thc- count-ry Distribur~d cli~nts for this data include Senior Management, Marketing, and Operations. The data c hange

,

SELECTED BEHAVIORAl DESIGN PATTERNS

RAJ\\ w,th spe ,Rcatlon< .

.4

erond part --

As cmble a network, wh, h we wdl name componenl4 , as follows. A emble a network, wh ,ch we w,lI name 'compone nt 5', from c ,the r one or IwO pans a follows , ~

Budd computer componcnl5, fro m ,he fo ll owi ng parts: CPU wllh specifica tio ns.. .. 900 and RAM w It h specIficat Ions .... 3

-Now co nnect componC'nl3 wi th componenl4 to comple te cornponent2second pan : -+ Assemble a ne lwo rk , whIc h we will name com po ne nt6 , as fo llows· Assemble a network , which we will name 'cornpo ne nl7', from eithcr o ne or two parts as follows· Budd com pUler compo ne nt7, fro m Ihe followlOg parts: CPU with speciflCat,o ns..... 600 and RAM with pecifications ..... 3 -

ow connect co rnponent2 with component6 to complete component 1-

Figure 17.51 Output for network assembly example, 2 of 3

continually , and each of headquarters' clients nee ds 10 updale li S dISpla y accord, ng to thelf various requireme",s. Lei's say , for example , Ihat Stlllor IVlaIl"gcmclIl's bar c hart muS! be lIpdated afte r a 5 percent change has takcn place, Il'tnrkclillg d, splays a new P'C c hart when a c hange of atieasl I percenl has rake n pia e , and OperatlollS reqUIres lables 10 be updaled when every c hange lake place .

~ Second part Now assem bl e a nClwo rk, which we will name 'compone nt S', as follows

Assemble a network, whIC h we wd l name 'com po ne nI9', from eilher one o r two parts a fo ll ows: Budd computer com ponent9, from Ihe fo llo wIO t! parIS' 750 PU WIth speclC. al lo n, and 10 RAM wllh speCIficati ons

• • Now con nect component I With componentS to 00 more work wllh Ihc o rder. Flcure 17.52 Output for networK assembly example, 3 of 3

gC I th e rC!l.ulting n(, (work =

---

4 23

.2.

CHAPTER 17 SOFTWARE DESIGN PATTERNS

-----------....., : 99[!1PQ'lltnl I Client r ------L---> 8ssemb/eO 1 ____ __ _ _ _ ~

0 .. 1 1

----- --- -

r -- --------

I I I

I

:

I I I I I

component 1

NetSl/stem assemble() J<

I

component2

t; ,

I I

:

cpu

Computerf: assemble()

CPU describeQ

RAM ram

describe()

,,

~

,,

•

••

Setup gelinpulFromUser() parseO

Figure 17.53 Application of Interpreter design pattern Th~ Observer design pattern is imcndcd to address these rcquirern~ nts . Irs purposes and basic techn ique

arc summarized in Figure 17 .54 .

17.7.2.2 Observer Interfaces for Clients Suppose that the abstr.lct class Sour('( IS aware of {he data source. Whenever a client want'S all observers to ,ake notice (Iypically, of a c han ge in Ihe data ), il ca lls a de sig naled melhod of So.rer . In Ihe modd below, Ih,s mClhod is named "OlifyO. The c hen, IS sh,elded from Ihe manncr in which Observer ca,,-ies oul thos process.

17.7 .2.3 The Observer Class Model The partic in the Ob!'crver design pattern requiring updating arc known as observers, and arc subclasses of a

single abstract class, which we will call Ob5
Design Purpose Arrange for a «I of objects to be affecled by a single object. DeSign Pattern Summory The single object aggregates Ihe set, calling • method wilh a fixed name On each member. FIgure 17.54 The design purpose and summary of the Obselver pattern

.. SELECTED BEHAVIORAL DESIGN PATIERNS

Server part

Client part ,-- -.

--- -- - --- - - - - -.-- .-- -- - - - ----, Observer

Source nOlily(/f:(

1.. n

updale()

Lr

2 '-

fOl all Observers 0 :

o.updateO: ConcreleObserver

ConcreteSource state

observerS tate

3

r -1:

updateO

..J

Figure 17.55 The Observer design pattern

\"lIe will follow a equencc of step to . how how

Obs~rver op~rates

Step I The lie n'! references a known '"terface object, requesti ng that the observer, be no tified For example, the client could be a process programmed to no ll ee that the data ha changed , or It could be a c1oek·dri ven ta k In the model , this is shown as a (1,<11/ object telling the SOllrer object to execute Its lIolify() functio n. Step 2 The IIoli/Y() meth od calls the II pdn l' () func tion o n eac h of Ohscro" object that It agg regate, Step 3 The Impl e me nta ll on of II pda l' O depends o n th e part icular (ollerrl,Ohs",'" to which It belongs Usually, updnl'O compares the (ollere/,Oh,,,,·,, o bjec t's sta te (variabl e va lues ) wlfh that of the cen tral dat a ouree on the serve r, then deCides whether or not to change It S va nable va lue,>

accordlOgl y It probably perform ot he r actions uch a erea lln g a new dlSpla

1ne class model tells u that evel)' Ohscro" reference, a

object. In fact , the 'ollIT",Ob,,",,, Will reference the oncrt !tSOufet obj e 1 at nm tl me H ow do the COllnclcObcn'(r objects kn ow to reference the Conc rete ou rce object] \"lIe could pas a reference to It 10 the parameters 01 IIpdnl'(), ", IS do ne In the Java PI 011 "

(sec Section 1772 .5).

17.7.2.4 Example Observer Applications

17.7,2.4.1 " Hamburgers " Observer Example ApplYing shown

In

bscrver to o ur Inte rnauo nal H ambu rger

orpora tl o n problem , we o btain. modd ,uch a, thai

Figure 1756

17.7.2.4.2 Mutual Funds Observer Example We ",'(1 Ulke., ano ther exa mple .pp(,cauon "I b,erver the updating of mutllal fllnd po nfo ll , 1\llItU. 1fu nd, mull1plc slock'} , ('0 Ih a l when it parll <..ulJr ') 10 k\ pn e t hJngco;; , It arlC_h till' "Iut., 0 1alllhc nlutual funds th at In vc') l In It orrn all y. '!ouch change, In J 1)(0 k.... pn \' j'lrc IrJ lhmlllcd t'lt:ttrootLali In o\lr t:\ \unplc

IOV(:\t "1

425

426

CHAPTER 17 SOFlWARE DESIGN PAmRNS

Cllonl

,,

,- - --

Cliont opa

Sow' part ,- --- - ------ --- - - -

-- --- - -

Source

1.. n

Observer

-)

update!!

notify()

SenlorManagement

forecast Headquarters

Marketing

update()

demand

marketinaOemand

/ If( abs( hq.demand - marketlngDemand) > 0.01 ) • ( marketing Demand = hq.getDemandO;

updale() doDisplay()

doDisptayO; )

Figure 17.56 Observer applied to International Hamburger Corporation

we will make the change to Awesome Inc.'s stock by hand. The application will then display the resulting changes in the mutual funds canying Awesome stock. We will use the OhsrrvtrlOhsrrvahlt java API to cany out this d~sig n and implc:mentation . The main usc case is as follows ; I. The application reports the status of mutual funds that invest in Awesome Inc.

2. The following repeats until the user signiAes quitting. 2. 1. The application prompts the user to supply a price for Awesome stock. 2.2. The user enters a price in decimal f.orm. 2. 3. The application reports the status of mutua) funds that invest in Awesome Inc.

Figure 17.57 shows a typical scenario. The cia" model is shown in Figure 17.58 . This cia" model uses OhStrotr classes in the java API , which arc discussed next.

17.7.2.5 ObseNer in the Java API Many of the design panerns discussed in this book are present in the java API. However, one recognizes them by their form rather than by ~ame. Observer is one of the few pattems explicitly called alit by name in the java API. The java API Ohstnltt class model is shown in Figure 17.59. The java API uses virtually the same terms as Gamma ct al. Notice that "pJa/t( . ) is a callback method in the sense that it provides Ohstrvtr objects a reference to its source, thereby enabhng them to compare their data and so on with the OhSlrvahl, object in executing "pJa/t(j . Because update is implcmc:ntcd as a callback, there is this no need for concrete Obsrrvtr classes to maintain rdcrenc('S to the ObsfflJQblt object.

SELECTED BEHAVIORAl DESIGN PAIIERNS

otc, HGrowt hMulualFund qarts w"h 3 sharcs of Awesome, assumes price of 1.0, and has non-Awesome holdings totalling 4000 'ote· kdGrowthMutualFund ,tarts wi th 2 hares of Awesome, assumes price of 1.0, and has non· Awesome holdings totalling 300.0 NOle, LoGrowthMut\JalFund lart with I share of Awesome, assumes price of 1.0, and has non -Awesome holdlnb'S totalling 200.0 Enter 'quit': Any other Input l o com inue.

go on Enter the CUrTent price of Awesome Inc. In deCimal form . 32. 1 Value of Lo Growth MUlua l Fund changed fTOm 201 .0 to 232 I Value of Med Growth MUlual Fund changed from 302 .0 to 364.2 Value of Hi Growth Mutua l Fund changed fTO m 403 .0 10 496.3 Enter 'quit': Any other Input to co nt inue.

go on Enecr lhe CUrTcnt price of Awesome Inc. in deC imal form . 21.0 Value of Lo Growth Mutual Fund changed from 232 . 1 10 221 .0 Value of Med Growth Mmual Fund changed from 36 4.2 10 342.0 Value of Hi Growlh Mutua l Fund changed fro m 496 .3 10 463 .0 Enter 'quit': Any other input to continue. Figure 17.57

va example for mutual fund application

r---::-:-

---- ---------------1 I I

r- ----------------,

Observable

Observer

I

notifyObservers()

>--

I

I

updste( Observable, Object ) :

~-------~---- ---I I

Mutua/Fund

I

value

I

numAw8someShar8S

I

I I

I I

Awesomelnc

Client

Key-

price

IJava API CI8ssi

LongTermMutualFund ------

MediumTormMutualFund HIGrowthMulualFund

IOovelOPO' Cta.ss I

Figure 17.58 ODserver example class dlagram-mutual funds example

....

updatel ... )

~7

428

CHAPTER 17

SOFTWARE DESIGN PAmRNS

Observpble

,I<

Observer

nO/ifyOirverso k - - - - - - - -- updale( Observable, Objecl)

~ MyConcreleObserver

observerS late

MyObservable subjecl

Key:

I

Java API Class

II

Developer Class

updale( .. ,)

I

Figure 17.S9 Observer in tl1e Java API

17.7.2.6 Comments on Observer • Observer also goes by the widely used name of "Model -View-ContToller" (MVC ), altho ug h there arc slight differences in emphaSIS. The "Model" in MVC is the So ure, in Figu,e 17.55 (the Obsrrvabl, in the Java API ). The 'Views" are the Ob,nv" o bjects, an d th e "Control " is client and possibly setup code. MVC emphasizes the fact that the mo del is data and the views are C Uls, whereas Observer is conceived wi th broader applica tion

• Observer aflows the additio n and removal of observers without d.sruptin g existi ng observer code. Only the loop In Obsrrvabl,.nol1jy() must be augmented. Some times th e process of adding and removi ng o bservers is co nside red part of the panern (rather than being a "setup" function ). • Observer may be di sadvantageous if very few of the observers need to rcact to changes (in w hich case the numerous nmi Rcatio ns waste resources).

• Obscrotr is di sa dvantageous when update is morc naturall y implemented ce ntrall y , or w hen update policies among observers have very little in commun .

• Obsrrvrr ca n't work if the observable cannot have a reference to all of the observers For example, we would not usc it in a clien t/server situation unless we were wi ll ing for the server to maintain references to all clients.

• In general, having the observers update themselves (as opposed to eXlerna l sohware perfo nm ing it) .s good o bject· o riented design because it keeps related fu nctionali ty together.

17.7.3 State

17.7.3.1 The Design Purposes of State Many co ntemporary applications are "covent -driven," A word processor, (or exa mple, waits (or the use r to click on an Icon or menu item, and o nly then reacts . Evc:nt·driven applicatio ns are often de igncd as STate-transi tion

systems. When a system behave by essentially transitioning among a set ofslalts , the State des.gn pattern can be helpful. For exampl e. we can descriix the Encounter vi deo game at runt ime in term s of the state it is IO- i t could transition among the StltH1g .up , WailiJ19 . StttiHg-
SELECTED BEHAVIORAL DESIGN PATIERNS

Design Purpose Cau<e an ob)c t to behave ,n a manner determined

by

IlS state

Design Pattern Summa ry Aggregate a I
hould al 0 be capab le of gracefull y absorbI ng new Slate and actIon handltng without dt
17.7.3.2 State Interfaces for Clients To use the State pattern , the lient imply makes a call o n a spe iRc method of a specik object The cl,ent" sh,elded from the various possible dfects of ca ll ing the method, whICh depend o n the object's
17.7.3.3 The State Class Model In general terms, suppose that we want to use a method doR rq"rsl() of an object 'arg" of class Ta'9" , whcre doR,qursl() can behave in different ways, according to la,g
17.7.3.4 Example State Appl ications The Encounter VIdeo game ca n typIcally be In a variety of sta tc, When you Slart to play the game, you rna have the o pportunity to sct yOllr characte ri stl s (" elllng Up" Slate ) When yo u ate III the mId" of lI11l'ra ting WIth othe r characters, your state IS dl lferent ("Engag In g"
Chenl I

,

;

/'

Target

•dcRequeslO

/

Tarqe tState

lorgetStalc

Figure 17.61 1M basic structure of the State design pattern

1

handleRequosf{)

429

430

CHAPTER 17 SOFTWARE OESIGN PA ITERNS

CHent

( l argel51al e,handleRequoslO: )

I

T

Targ et

•daRcqueslO

TsroelSlate

l.rgeI518le

,

1

handleRequesrll 71

TargelSlaleA

TargelSlaleB • • • • • •

handleRequeslO

handleRcqueslO

Figure 17.62 The Siale design pattern: doRequestO behaves according to the state of Target

play In tha·t case . If the ga me tnterface had the appearance in Figu re 17.63 , the dfect of pressing the ScI Omractcn sl/cs button would depend on th e state

or the game at the

time .

Figure 1764 shows how the Statc design pattem can be used to handle the states and actions of Encounter The cia s MyGame has an attribute called , laic of type MyGmncSlalt The type of the , Ialt o bject (I.e ., " 'hich subclass of '"lyGamtSla le It belongs to ) delCrmines what happe ns whe n stlo,araCltri, It C5(J is called o n a MyGamt obJect , The code for st lo,aracltnslt«(J In MyGamt passes contro l to Ihe handltCfick() function of slalt. Each subclass of MyGarntSlalt Im plements l,andleCfick(J in its o,,,n manne r. For example , if MyGame is in Wailing state, then the effect of clicking o n the "Sct C haracteristics" huna n is that a wi ndow appears thro ug h which the playe r ca n change hiS charactenst lcs . O n the o ther hand, if MyCa,"c is in ScltmgQutlilhcS state , then nothing happens because the user IS alread y s elling his characteri stics.

Set Characteristics

FIgure 17.63 GUI for Encounter role-playing game ~

COt.rtesy of

Tom vancoun and Cent

DESIGN PATTERN FORMS: DELEGATION AND RECURSION

MyGame

I~

stale

setCharacteristicsO _

handleClickO •

t stato.handieCIlckO.

I

Setting Up

Waiting

SettingCharacteristics

Engaging

handleClick(

handleClick~

handleChckO,

handleChckO

I, I showWindowO; •.. J/ more

I

,

I

I

I showWindOwO: ... JI more

i

,,I

I

{ /I already respondJJl9 .. /I disp{ay message

I I/ do noth'ng . ,_ /I dISplay message

I

I

I

Figure 17.64 The State design pattern applied to the Encounter role-plaYing game

17.7.3.5 Commen ts on State • The State design pattern is particularly beneficial when new states are likely

to

be needed

In

the hltu re.

• State does not hand le the question of how to set up the sUCCesSIve state (if required ) once ha"d',E"",tO has been perfonned. Although State doc no t hand le the tranSition funcllon , it can be a useful fnmework In wh ich to implement transi tion . For example , halld',E""" O ca n contain code that swaps In the new Slate A possible companion to ('he State deSign pancrn IS a state-transitIOn table whose entries indicate \~hal new state the object tranSitions into for each "current s tale~vent occurrence" pair • Whetheror not the State de ig n pattern IS applied, tate -onented arc hlte tures have been used with success for many applications (see, for example, the work of Sh laer and Mell or (2 )) Real-time apphca tions lend to benefit especially from the sta te architecture because they often rely o n a sratc/event perspective

17.8 DESIGN PATTERN FORMS: DELEGATION AND RECURSION As the exa mpl es of deSign patterns above Iliu trate , they occur ," a ),mlted number of forms We could >a y that there are patterns to the design patterns meta patterns. If yo u like . Mo,t deSign pallern are based on the dcltgahoH or ftcursiotl forms , as descnbed In thIS secti on.

17 .8.1 The Delegation Design Pattern Form ConSider a ta,k that needs do,"~ , the o bjec t thai initiates it , and an object thai doc< the actua l ",ork 0" '91111°" IS a proc"", by which the Initi ator emp loy, a th"d obJc tto get the work done by the doer. An example from re.llife IS the usc of a rcalLor In whic h th e . c ller (the InllialDr) wants to cllto a buyer (the doer, In thiS a<e) To ach ieve nex,bd,ty, the KltchenV,ewer dC
new Ant iqueWallcabinet () ; / / applies only to ant ique style

431

432

CHAPTER 17 SOFTWARE OESIGN PATTERNS

.. , c1lenIFunc;Iron{ ... )

.. InlermediaryFunctlon(

(

... inlermodla.ryFuncllon( .. ) .. ,

( .,' r&qutredFunctionO , ..

j

j

)

Client cllentFunctionO

- - - - - - - - - - - -

~

IntermedlaryFunctionO

" "

I I

!

,X ,,

I I

I

replace

"

I

,

-!t ." requlredFuncllonO

FIgure, 7.65 The idea of delegation

with

il

version that delegates construction to an intcm1e diary method

myStyle . getWallCabinet () ; / / appli es to whatever style is chosen at runtime

11,e Abstract Factory design pattern replaces several dircci m
functi onali ty to the methods of an abstract class. When we apply Abst rac t Factory in Figure 17.7, fo r example, the work of crea ting a Wal/Cahi"" object is de legated to the methods of a KilchrnSIyI, object. A common lorm of Delegation is illustrated in Figure 17.66 . where an abstract class is aggregated and acts as a base class for severa l concrete subclasses. The client calls the method ml,rjacrM"bod() of the interface class OP/"',rjacr. In turn, inltrjacrM"hod() delegates the reqUired fu nctionality to its aggregated Oorr&" object, do,rObjrcl. The functiona lity is carried out by having dorrObjecl execute a method that we have named do/l( ). At runtime do,rObjrct is an object of either the class Co"" ",OO''' , Co"crtItOom , and so o n. Since the effect of do/t() depends on runtime cond itions, so docs the effect of i"l,rjaccM,'hod(J. The class OP/III,rjfl" thus has the followi ng fonm .

class DPlnterface ( DoerBase doerObject; •

• • • •

public void interfaceMethod () { doerObject . dolt (); } }

DESIGN PA ITERN FORMS: DELEGA liON AND RECURSION

Client I I I

I

... inte~aceMethod( ... ) ! ( ... doerObject.doltO ... ~ , .,

I I I

r.-~ DPlnteriace

doerObject

DoerBase

IntertaceMethodO

ConcreteDoer1 doltO

dol/O

ConcreteDoer2 doltO

...

Figure 17.66 Basic deSign pattern form nu mber , -delegation DelegatIon . Implemented using ,he virtual functio n property. is the most common form of deSIgn patterns . Another common form is Recursion : the usc of slnK,u res '0 cffcctl\·ely reference ,hcmselve,

17.8.2 The Recursion Design Pattern Form Several deSIgn patterns require re ursion- In o,her words, part of ,he pattern essen tially uses I,self For example, recurSIon is useful for represe ntIng a linked list of objects ir. wh, h each objec, of a cia> agg rega ,e another o bjec, of the ame class. Anot her examp le IS construc'ing a graphical user In,erface tha, al low> fo r Windows within Windows withIn windows .

. and so o n. In lhl'> case, the \\'mdoIP object aggregates itself In a recur Ive patte rn fo rm , a duallnhcrnancc-aggrcgal1 o n relario nshlp eXists between 3 base class and a 5t:Jbclass. as shown In F, gure 1767 No,ice tha, the Recur
deleganon doubles back o n Itself From the dynamI C VIeWpOint , in a RecursIve form ,he ct.en, ca lls a me' hod of the Intedace, which we'll name doOptration () If the object actually belongs to ,he subclass Rcn",,,,r IllS! , ,hen execut"' g li S doOprrahon () Involves the o bjec t(s) of aggrrgalt T hese objec" may once aga ", ca ll doOprmholl(), and so on Let's take as an cxample ,he case where RccII,""on/3asr ",he la> Employer , doOprrallollO " ,he me,hod pnnrOrgan'ZIlhonO, and Rrcurs,"cC/ass i< the class SII pm",or The Idea " to produ c a prin,out f all ,hc ~mployecs of an o rga nIZatI on The d a« model IS shown In F,gure 17 68 The method pnnrOrganlZllr.onO In SuprnJlSor would be prowammed nrst pnnt ,he
'0

objects o f the clil~'" up,rVl sor. prltl l () rgaH IZtl ll otfO pnnt) th a l ) lIpcrvl,or's n a m~ Jnd the pnntln g pro (' '\ rcpt"ill' re ur!lo lveiy Thl~ rccur'iIVC pr(lce~) eve ntuall y print all or th t: nJmcs The c1J" uprn11,or Ihl! ha, the:

fQlJ owlng form

433

434

CHAPTER 17 SOFlWARE DESIGN PAmRNS

RecurslonBase

Client - - - - -

;> doo".,. r'on(j

t:;>

NonrecursiveClass

RecursiveClass

doOpe,atlon(j

doO".,.tlonq

p

aggrega.e

I

I . void doOperation( ... )

II ... aggrega •• ... } :

-

I

y

Figure 17 .67 Basic design pattern lorm number 1--<ecurslon

IClient fu_u

Employee p,lnro,ganIZlltlon(j

IndividualContrlbutor

Supervisor

pnntOrganlzalionO

prlntO'ganlzalionO ,

Gid

supervisees

•

pnntOrganlzation( ... )

I ... supervisees.printOrganizationO ...

J

~.

_____________________~t~>~'

Figure 17.68 The Recursion design pattern lonn applied to an organizational chart

class Supervisor extends Employee {

Vector supervisees;

void printOrqanization(

•.• )

SUMMARY

{

•

•

•

supervisees.printOrganization();

•

•

•

}

}

17.9 SUMMARY This chapter I ntrodu cd design pattern", which are used to ~atlsfy recurring de IS" purposes A df.:slgn partcm ,'\

a g-roup of cia ~c ( th e sIalic

VleWpOll1t )

that

tnteraClll1

a recognizable ..... ay (the d)'lwmlC

V ICWPOlnt )

Typically. a

desIgn pattern consists of an abstracl level of clas<es and a nonabSlraCl ("concrete") levd Three roles ( et of codd a", involved In the u<e of de Ign paltern<, lhe appl'
everal deSign patterns also u c a (orm o( ,tClm/OfI ,

In

whl h a class

rderences either Itself or a base class from which it inherits DeSign patterns can be rOllghly c1as ,ned as (7w llonal , sfru 11m,', o r btb,wlora'- Crw I/orlllI patterns create nonrnvlal object ensembles In a manner determll1ed at runtime. Structural pancrns are used to represent collectIons of objects. Bd,.",oral patterns deal AeXlbl y with behaVI or among a ot of objects This chapter descri bed the following crealio na l design patterns by ,yay of example The S,n gleton pattern i used to enforce classes with o nly a SIngle in tance. The Abstract Factory pattern IS used when an interreiated family of classes is required but in a vanety of "styles " A "style" In thi< sense IS a haraCtenSllc appli~ablc to every object in the family .

The

follOWing behaVioral dcc;;i gn patterns

WCft"

discussed . Facade

IS

a way to treal a group of c1a ss~s JI:; a

unit. by provIding ItS functionality only through a slOglc object Adapter IS a way to SWItch u er obJe t ty pes of given functionalIty at runtime The chapter al
of

tal C II:; used to deSign Clpphcation pilrt" bel:;t th ought

term of a SCt of stales These points are summa rized In Figure 17.69. The reader i referred to Fowler (3) and VIl<sldes (4] [or further exploratIons of dC
• DC'Slgn Pattern s are recurring designs sat lsfy mg rc urnng dec;;lgn purposes:

• Des<:nbed by Static and DynamiC Viewpoints • TypIca lly cias, models and
435

436

CHAPTER 17 SOFTWARE DESIGN PATTERNS

17.10 EXERCISES I. Which of the following arc applications of deSign pallerns) Exp lain your conclusio ns.

(a) An obJect,orlenta ted design (b ) The ab ili ty 10 vary the order

10

whi ch a

pn,,'O method

IS

app lied to the ciemen ts of a Veelor

(c) Varying the order 10 which a method is applied to the clements of a collection of objects by introduclOg a ciass who e methods IOciude a method like go ToNtxIEl""ml() (d ) Cap turing the mutual beha Vior of a pair of objects o f twO classes (e) Capturi ng the mutual behaVior of a pair o f objects of twO classes by introducing a third class aggregating the two clas es 2. Char.lctcnzc the fo llowing design purpose as , ,(aIlOMl, structllral, or btlJovioral. Explain your conclusion clearly.

We must build an application with 15 different screens involvlOg va ri ous combina tio ns of 6 us., interface contro ls (e.g .. list boxes) arranged in a si mple grid Pe rfo rm ing a mouse ac tion o r text e nt ry o n a co ntro l (e.g .. a butto n) in a screen affects other controls o n the same scree n. In all o ther respects the screens are not related and are not si milar in appearance. The compOSition of th ese

screens is very unlikely to change . 3. Characterize the fo llowing design purpose as erralronal , structural, or bthavioml. Explain your

conclusion clearl y We must build a hum.m resources application dealing with the management structure at a large co mpany . We nee d to represent the organ ization chart withi n the applicati o n. 4 . Cha ra cterize the follOWing design purpose as ertel tional , structu ral , or bthapioral. Explain your

cone/uSion clea rl y. We must build an application that allows users to build and change their stock portfolio with a various ki nds of mutual fund picks from specified subcategories. The mutual fund categories ar< ttchPlology , old mdustrits , utilities , rtal (stal(, and mining . The application allows users to pICk categories. It then milkes portfolio recommendations depending o n the user's choice. For eXilmple, the user can

ask fo r a low· risk portfolio of utilities and mining Slocks. and the application describes its recommendat ions within these constra ints.

5. Consider the followi ng two statement . (al Obstrotr consists of an object of a class that reflects a data source, togethe r with o bjects of classes that depend o n the data source. (bl When the data changes value, a method with the name "pdateO is called o n each observing object. Which of these two tatcm ents takes a static viewpoint and w hich a dynam ic' viewpoi nt

6. The following figure shows the Obstro" desig n pattern class model. Group the classes to show ab,tract and co"crete levels. Group the classes to show the three ,oles descTibed in this chapter. 7. (a) What two design pattern form. are mentioned

10

th is chapteo

BIBUOGRAPHY

(b ) ~ h,ch of the

".0 fomls IS more lIkely '0 u'c virtual functions ) Explain your answer Jnd gIve

In example

(c ) Wh,ch of ,he two form IS a I",krd

I'si of obJtCIS Ioke1y

'0

be) Explain your an wer

(d ) Wh,ch of the two forms IS the Observer pallern In Exercise 61

S. Re ('arch the Java wing soflwarc ar hltcclUre, such as Java wmg, and descnbe In a few paragraphs how It make usc of the Observer pallern Draw a cla<s dIagram a part of your an<wcr 9 Research the Java EE p ia, form and desenbe In a few paragraph, how i, makes usc of ,he Facade de Ign pattern Draw J clas<: diagra m as part o( your solullon

BIBLIOGRAPHY 1 c'mma Ench. Richard Helm . Ralph }ohn ..on and John VI''iSl dcc; D(~I!1" PQlftnt ~. El('lllmh of Rrw.wbft Ob}tcl.OnnlkJ 50//11',1'1 Wc .. lcy. 199 '2 Shlaer, Sally. and tcphcn Melio r "Ohle, Lfrrydn /\loJrlIl19 1M World.,\ lollI'S, You m o n 3 Foy,·lcr, l\'brtln Pull"" H(mhl"9 f)MI9" Pallen" AppJltJ " Acid ..:;on '«'c"lcy I?'J$ of VIISS,dc-s, John ~' . MPOII(n.~ of E"'crpnSt AI'P',collon J\rrhl lrdlm " Addlf;on· \,(/c 'iIc)' 2002

Pr~ ~

199 1

dd"on .

43 7

Software Architecture

The Software Development Ule Cycle

•

How do you classify software architectures?

•

What are data flow architectures?

•

What are three-tier architectures and their generalizations?

•

What makes database-centric systems a separate type of architecture?

•

What are service-oriented architectures?

•

What IEEE standards are there for expressing designs?

•

What do real -world architectures look

like? Figure 18.1 The context and learning goals for this chapter

Th IS p.rt of the book , oncern ed with desig n, began by dcscnbing design go.ls and principles and then described patterns of design that reCur th roughout. This chapte r describes d<sig n at the high leve l, and the chapter that foll ows at the detailed level. A sofl wtlrt archlfcch~ rt descnbes the overa ll compo nents of an apP'!ic,Hi on and how they relate 10 each oth er. Its design go. Is, as discussed," C hapter 15, include suffiCIency , understandabil Ity , modularity, hlSh cohesion, low coupl ing, robustness, fl exibi l, ty, reusability , err,clency, and reliability. For a give n softwa",

SOFlWARE ARCHITECTURE ALTERNATIVES AND THEIR CLASS MODELS

• Oatatlo,"l architecture!!. • PIpes and filters • Batch sequentIal • Independent ompon('nt

• Clicm · elVer systems • Parallel communicating proccs es: • Event systems • Servlce ·oriented (added )

• Virtual machine • Interpreters • Rule ·based systems • RepOSitory architectures • Databases • Hypertext ~ystcms • Blackboards • layered arc hitecture..,

Figure 18.2 Shaw and GarJan's categonzation of software archItectures SCUte: Shaw, M.G and 0 Gartan. " Soltware AlcMecture PefspecUves on an Eme'ging OIsctphnc," PrentICe Hall, 1996

devel opment project, lhere may be several possible app ropna te architectures, and elecllng one depends upon [he goals that ont wants to emphasize. Flexibility , to choo c one of these qualities, is a key goal of many archilectures-the ability to accommodate new features. This uc;uall y Invo lves Inrro duClng abstraction Into the praces For C"xample , we mIght want the architecture for the Encounter Video game case study to support not Just thIS partICular ga me , but any role. plaYi ng video game Attaoning one de irable deSIgn property ma y entail a trade ·off agaonst others For example , a de Igner who uses abstlactions to obtaon a fleXIble architecture may make" harder lO understand

18.1 A CATEGORIZATION OF ARCHITECTURES Shaw and Garlan [ 1] have claSSIfied software arch"ectures 111 a u cful manner Theor cia Slficallon, somewhat adapted here, is shown in Figure J 82 . Section 18.3 explaons these ",ch"ectu res There IS a WIde variety of problems requinng software solutions, and lhere is a wide va ri ety of archItectures needed to deal with them In most cases, the architecture is unique to ,he problem Sometimes, o ne of the a rch itec lures Identi fied by Shaw and Garlan matc hes the problem, in many cases they si mpl y proVIde Ideas o n whIch to base the architecrure. This is Similar to arch itecture in hOUSl' construction, In which claSSIcal and standa rd Ideas prOVide inspiration for great architecture but arc nor c;imply copied

18,2 SOFTWARE ARCHITECTURE ALTERNATIVES AND THEIR CLASS MODELS The softwa re archItect develops a mental model of how th e application I meant to \ o rk, often with nve to seven components The JrChlltCl '., mental model depends on the app li ca ti o n In qUl:.'!)l\on . of COll r~ e , but may benent from architecture< that o ther ha ve de veloped In th e p. t, JUpcn" on brodge de>!gn benents from the study of preVIously budl suspe ns Io n brodges . ThIS section e laborate< o n the arch ll ec· IUr<S claSSIfIed by h aw and Garlan They calegonze architec tures as dota flow , ondependent compo · ncnb, vlrrua l machlne'l , repository archItectures. and layered aT h,lcclllrcli. Figure: 1 2 summanz.e'" th('~e and 'heor subcate!!orocs, and the re~t of thl sec ti on cxp l"n< th e m It also add , serv l e · oroc nled

architectures.

18,2,1 Data Flow Architectures Some applIcatIons are best VIewed a, data Oc,wlng among proce'Slng unlt< DOll 1I0w dl.!;"m, (I 1'0<) IIiUstralC 5uch VI('WS Ea h pro csson~ unit of th e OFf') " de,,!
439

440

CHAPT£R 18 SOFTWARE ARCHITECTURE

member

Gel

banks

User

deposil

J". no"'"

Gel Inquiry tlccounl no

act:ovnt no. and doposlt

Validate

Validale deposil scoounl no.

Inquiry Display account

aca>unl no.

Make

Inquiry Printer

'''''depoSIt Do deposit

tJccount

balana>

dDra

query

doposll

transactlon

trat'lSBction -

.. account_

S=>
dols

Create account summary

dalabase

Figure 18.3 partial data flow diagram for an ATM application

emanates (rom sources , such as the uscr, and eve ntually flows back to uscrs, o r into sinks such as account

data bases. The c le ments of the DFD no tation were explained i n C hapter 16 . A banking application is sh own in Figu re I S.3. Data Row from the user to a "Get deposit" process, which se nds the account number and the deposi t amount to a procc,ss designed to check th ese data for consistency . If they arc consistent, the data may be sent

to a process that crcates a tran sac tion , and so on. DFD s can be nested . For example. the "Create inquiry tran sac tion" ca n itself be decomposed Into a morc detailed data flow diagram .

The functions of a data Row d iagra m may reside on morC than one physical platfo rm . Figure IS .4 shows one possible allocation.

ATM

o

Get deposit

Get Inquiry

Display account

Consortium server

Bank

server Make Inquiry

Do deposit transactIon Create account summary

Validate deposll Valldale inquiry

Figure 18,4 Platforms in data flow architectures, and an example

SOF1WARE ARCHITECTURE ALTERNATIVES AND THEIR ClASS MODELS

18.2.1 .1 Pipe and Filter One kind of data Ilow ar hltceturc.
In

Fi gure 18 6 .

the applI ca ti o n malntaln ~ ac Qunt> as tran saC ti o n, arrive at rand o m l1nH;S from co mmu nica ti o n

lines The arc hitec ture Includes;) lCP for logg in g lran,a C ll on~

In

case of system fa ilure The Withdraw

Jo lmDotAc olUltNum 11 J OAmOUPlt$3S00 00 , or Just Jobn. DoCf 2J 45 SJ 500 oo'-that IS, a character stream and bank address input such a< llallkNu"'9876 The proce ing elem ent , hown in ellipses. wai t untd alf o f the reqUIred Input has arnved before performin g function would ha ve withdrawal Input su h as

their op"ratl o n stream>

filler

hlter

filte r

IiIter

filter

pipe filter < stream

FIgure 18.5 Pipe and filter architectures

Requirement: Maintain wi red fi na ncial transactions . - - - - - - account data - - - - ,.--- account data - -

_,-- I Ba nk d a ta

L

deposit

, account data

Iransaction

r

depoSIt data

a na lyze

Comm _ _ _ bank address

transaction

transaction result

~L'---...... re cord

'--~

wllhdrawal

transaction result

withdraw

L _ _ ___ account data - -- ---'

FIgure 18.6 Example of a plpe·and·fllter architecture, to mai ntain Wired fInancial transaction

Log

441

442

CHAPTER 18 SOFTWARE ARCHITECTURE

Transaction analyzeO recordO

l..n

Bank

Account w~hdrawO

r

depositO

Figure 18.7 Obtaining a ctass model from a data flow architecture bank account example

There is no absolutel y uniform way to map data fl ow diagrams (DFDs) on to class models, however, functi o nal units of the DFD can frequently map directl y o nt o methods of classes, as shown in Figure 18.7.

n,e Incrl!asing usc of distributed computing is acccieratlng the applicatio n of stream · onented computing because rem o te function ca lling is often implemented by convening the call to a stream of characters . nlls IS do ne in Web services, for example. These use seria lization, which converts objects to XML charactersITeams. ln additio n, l/O is often implemented u ing streams, and performing 1/0 in a language such as Java often amounts to a Rltering process of the kind we have discussed .

18.2.1.2 Batch Sequential In the special case where the processing clements arc only given batches of data , the result is a blilch s
Requirement: Manage bank funds available for mortgages and unsecured lending. Architecture: Account balances

Collect mortgagelunds

-«

Mortgage pool

>--

Collect unsecured funds

Unsecured pool

Figure 18.8 Example of a batch-sequential data flow architecture creating a mortgage pool r : Accounts package : o

--- -- -- -------- -----

.-.----.... -.. -.------ - ----- - --------------~,, •

,,• • • ,•

Customer

:.-.--. -- - .------------------~

;: LA_c_c_o_u_n_t --:: ---!:

•·

.... ----.----.-.- ..

: Bank package :

:

~--.------.-.------.----

.. ,

:

-

' _..

Bank

:

getMtgPOOIO : getUnsecurePoolO : _.. _.',

----_.------- -.--...

Figure 18.9 Class madeller batch sequential data now--
SOF1WARE ARCHITECTURE ALTERNATIVES AND THEIR ClASS MODELS

For dcca dt" • data flow has been the: mos t CO rnm o n way of

be

u~c:ful

(or some lime to come EnSlAccrs nawrnlly think

cxpr~~sl n g architectures, and

ol data

It IS bou nd

to

Oowlng, from one prace Si ng "statio n" to

th~ n ~x t and of proce<slng taking place at ca h ta t Ion . The disadvantage of data fl ow d,agrams include the fact that they do not map very cleanly to code , whether obje t .onented or no t An excep lt on to thIS appites to specIfic data flow language, (,ome beIng actuall y graph ,c In nature ). wh Ich arc butlt around the very co ncept of data ilow We WIll use the data flow mo del once again when we dISCUSS detatled deSIgn In C hapter 19

18.2.2 Independent Components The i"Jcpmdnll compOHfll ts arch ,tecture consl IS of componen ts operatIng

In

parallt:1 (at least in prul Clplc )

and commUnicating wit h each ot her from time to time An obVIOUS Instance of thiS can be found on the

World W,de W eb. where milli on, of servers a nd browsers operate conttnuou Iy

In

para ll el and penod ,cally

communicate with each other.

·Components" arc portIons of software th at do no t change and that do not rcqutre kn owledge of the software usi ng them .

IT assemblies and JavaBca ns are example component technologIes

omponents

sati fy gui de l",es aImed at maktng them self·conta lned. They use other components by aggregatton, and generally Interact wi th other components throug h {'vents

The case studies tnclude a d,scussion of the Eclipse project. Ecl ,pse

IS

a development platform deSIgned

to accomm odJtc plllg-IIIS Th ese arc independent component that can be created by developers fo r vanou~

purposes. and added to the platform wit hout affec ttn g exi ting functio naitty

18.2.2.1 Tiered and Client-Server Architectures In a df(nt-S(rv(r architecture, the server componc nt serves th e needs of the chcnt upon rcque~t Clie nt -

server r~ latl o n s h ips have the advantage of low coupitng between the parti CIpating compone nt s. When morc than o ne person perfo rm s Implem entatI on It is natural to parcel out a package of clas es to each developer o r g ro up of deve lopers , and deve lo pers ty pica ll y req UIre the services of classes for wh ,ch ot hers are res po nsib le In other words , de ve lope r;' packages arc o r. e n re lated as citent and ,erver The prob lem IS that these service arc typica ll y in va ri ed sla tes of rC3dln es 3'> the app lica ti on I - In the process of being built .

A server componen t acts morc eHcclIve ly when its Interface IS narrow - arrow" m(,.-a ns that the mterface (essentially a colle tlOn of fun tion, ) co nta ins only neCCSs.1ry part>. IS coll ected ,n one pia e. and" clea rl y defined As exp laIned 10 hapte r 17. th,· Facade deSIg n pattem es tabl"hes Ju
malnfram terminal arch Itectures Olcnt/'>crver an. h,ttcturcs have c;ub ...equent l>, bee mc more ;,ophl heated J

and more va ned

orne arc now de~igncd as three· tlcf arch lt ecture~ Instl'ad of the ongmal two tlC~ (chent

and server) Tht third tl c r it t< betwee n the c1 ,cn l and the erver, prov Id,ng, Itsehtl level of II1d,rc tlon A C()mmon allocalton of (unction IS to de Ign the C UI fo r thc cl ,e nt , the database management, 'tem . or procedure management for the mIdd le layer. and »sorted app l,c, tlo n prosra ms a ncllor the dataha,e Iheli lor the thtrd la ye r The mIddl e la ye r ca n he a com mo n data "bitS" that br kef< commltnt a lto n ItcrnJtlwlv the mIddle layer can operate vIa a \l.nliard ",eh a, M ,cro,oft', ET . " (IIIMIt! FInall y the World ~ Ide \'(Ieb Un be: onlJldcred a bre d of ellcn ... rrver ar hnc(. turc In whl h "one- wrvrr/tcn ... of <..ht.""n l," .'> ft'plJ.ccd hy un krver/mdl,oo> of iten" ·

443

U.

CHAPTER 18 SOFTWARE ARCHITECTURE

18.2.2.2 The Parallel Communicating Processes Architecture Ano ther type of "Illdepe ndent o mpo nent" arch itecture idc ntlAed by Shaw anel Ca rl an" named pa,alle' (OmnHOllcnf"'9 processc . TIlls archilc lUre I characterized by scvcr;\ 1prace C". or threads. execut ing at the ~amt tIme. In h,s classIC book [2l. D'Jk,tra showed that co nceivIng a process suc h as the combIna tion of parallel parts can actuall y SImplify deSIg ns. An example of this is a SImul ation of customers In a bank Trad,t,onally, man y such simulati o ns were deSIgned withou t paral1eh m by sto ring and handlIng the events Involved . Such deSigns can sometimes be imphAc d, however, if th e movement of each customer IS a SCpM.1tc process (c 8 ., a thread o bject in Java ). uch a paralle l commun icating process dcsi.g n has the advantage that" matc hes more closely to the activitIes that it simulates A good refere nce to parallel communlca "ng processes in the Java context IS [ ]. The parallel proce ses may run o n a si ngle platfo rm o r o n separate platforms , as illustrated on Figure 18. 10. Encou nter uses th is architectural parallel eleme nt by havong the foreign c haracter Freddie move Independently from area to adjace nt area while the game progresses. This thread "communicate s" w henever

Freddie fi nds himself in the same area as the player character A UML notation that expresses parallelism was dIScussed in C hapter 16. Th is no tation, used in Figures 18. 11 and 18. 12, shows an architecture for a banking appl ication desig ned to handle multiple transactions occurri ng simultaneously o n automated teller machines (ATMs). This particular arc hitecture allows the customer to initiate tran sac ti ons without hilving to wait for completion. even w hen the transaction

,akes Significant time. The applicatio n may , for example, inform a customer that funds he deposited will not be immedIately available-that is, not wait for the completio n of that process befo re making the announcem~n[

When customer II uscs an ATM , an o bject for customer II is created (Step 1 in Figure 18. 1 1J. Customer II cr~ates SCSSIOII m (2) Sessio n m then retrieves an Accou~1t object such as customer t1 checki ng (3). The retneval.s

pcrfom1ed a ynchro no usly, and a thread , o r parallel process, is created because it may take time. Th is allows the custome r to carry out other bu si ness in the meantimc . The method call rc trievi ng the Accolmt object is de noted by • Slick arrow head indicating that the 5"';011 o bject proceeds in parallel with th is constructio n, returnin g to th e customer object. Si nce we are dealing at an archhecturallcvcl . we arc omitting details here

uc h as showing the thread objects involved and showi ng how the 5os;01l objects kn ow that thIS is its required

Platform 1

Platform 2

I

comun/catlon

e xecutJon

Figure 18.10 Platforms for communicating processors

Platform 3

SOFTWARE ARCHITECTURE AlTERNATlVES ANO THEIR CLASS MODELS

Requirement: Manage A TM traffic. Architecture beginning with first session: Customer_n

session_m

:Customer:

:Sesslon

create

customer_n_ checkJng

:Account

0:

.:

®

retrieve"

0

°

deposit·

deposlt-+j (",ore wo~

(thread detail omitted), Figure 18.11 Example of parallel communicating processor architecture diagram

managing ATM traffic. fragment of secuence

call. The Cuslom" object Immediately pcrfoml s a deposit "ansaClion by sending a me< age to t h e

5,,,,0"

object (4 ). TI,C 5",io>l object executes the d c poSit by sending a depos it message async h ronously to the

Ac oU>l 1

object. spawning a new thread ( 5 ). Other w o rk can go on-lilcluding by o th er seSSIOn s

whde the deposit IS

processed

In parallel , o[her Customt'r obj ects such as customer s are creating and operatmg on other <':;CSSlons such a seSSion

k.

This is shown

In

Fi gure 18 12 .

Figure 18. 13 shows the beginning of a class m o del that handle

thIS kind of architecture

Requirement: Manage ATM traffic.

customer_

s_saving : Account

Architecture:

6)

Customer_n

sesslon_m

:Cuslomer:

:Session create

customer 5 -Customer

I

retrieve" : create

'"

4 depoSlt+j

Withdraw

;

0:

..J

customer_n_ checking :Accounl

session_k :Sesslon

0

I

ret neve'

r_0 ::;5_

+-- - --n

d_e_P_OS_It_.

---+j

Withdraw'

f - - -- - -

U (Ihread detail omitted)" Figure 18. 12 Example of parallel communicating processor architecture

managing ATM trafOc - secuence diagram

445

446

CHAPTER 18

SOFTWARE ARCHITECTURE

,---------- .,

I

~

; Sessions : ., ,, ,

,,------.•, ,,, ,, Session , ,,

'--

Figure

18,13

•

---- ... . •

, ,

,-

, .

.

,_.-._.------. _. ___ • ____________ _______ _______ _ CuSlomers __________ J' , ,, ,• ,, ,,, ,, ~ Account ,, J" ,, depositO , ,, ,

,,,

•

.

,, ,,

withdrawO relrleveO

Customer •

-- -----.---_.-----

,

• •

Example of parallel communicating processor architecture managing ATM traffic-<:Iass model

18.2.2.3 Event Systems Architectures and the State Design Pattern Let's tum to

"""I

'Y,'mos , the third type of "independent component" architecture cla ssi~ ed by Shaw and

Carlan . Thi s architecture views apphca ti ons as a set of components, each of which wa lts until an eve nt occurs

that affects it. Many contemporary applications are event systems. A word processor, for example, waits for the user ' 0 click on an Icon or menu item. It then reacts accordingly, by stonng the fi le, enlarging fonts, and so o n. Event systems arc ofte n ful fi lled as state transition systems, which were Introduced in Chapter 11 . \,(,hen a system behaves by essentially transitioning among a set of states, the State design pattern should be conSidered fo r the design. This design pattern was explained In Chapter 17. For example, we have described the overall requirement fo r Encounter In terms of the state diagram in Figure I 1.26 of Chapter 11 . Encounter tranSit ions among the Sellin9 up. Wailin9 , Sellin9 qualilies , Reporting, and Engagln9 states, among others. Our design should capture this behavior effectively. It should also be capable of gracefully absorbing new states and action handling as the game becomes more complete, without dISrupting the existing design. For these reasons, we wdl app;)' the State design pattern described in Chapter 17 to Encounter. The State pattern solves the problem of how to use an object without having to know its state. In the CQntex't of Encounter we want to

be able

to wnte co ntrolling code that handles mouse actions but does not

reference the possible stales that the ga me can be in , or the specific effects of the mouse actions. This makes it possible to add new game situations without disrupting th is controlling code.

Figure 18.14 begi nsto show how the State design pattern can be used to handle the states and actions of Encounter. The framewo rk class RPGame ("Role· playi ng ga me") has an attribute called ,'ale , which is of rype Gam,sln'e . The subtype of slale (i.e., which subclass of GameS'ale it belongs to) determ ines what happens when handl,Ellrn'() is called on an RPGame object. The code for /,andleEv",l () in RPGam, passes contTOl to the h."dl,Ev", ,() function of state.

--

,- -I I

I I

I I I

•

: RolePiayingGame I _____1

.-------------------------------~-------

Slale

RPGame handleEventO

I I I

(

-- --- '

state.handleEvent{); )

------------ . ----- --------- . ------ -

EncounterGame 18.14

GameState handleEvenlO

I

Figure

--------,

Beginning of tl1e State design pattern applied 10 EnCOunter

I I

iI

I I I I

I I

-,

SOFTWARE ARCHITECT1.!RE ALTERNATIVES AND THEIR ClASS MODELS

------------,

lRolePlayingGam-:J -- -------

RPGame handleEvenlO

state

GameState hand/eEven'!)

( slale.handleEvonIO;)

--

EncounterGame

--- ------------

Waiting handleEvenlO

1

SettingUp handleEvenlO

f:::, ... ---- - -----

~

--1------------

~

: EncounterGam e 1l 1

Setting Qualities handleEvenlO

Reporting handleEvenlO

Engaging handleEvenlO

1 ~-------------------------------------------------

Figure 18.15 State design pallern applied

10

the Encounter video game

As shown in Figure 1815, each subclass of Gam,5Ial, implements handl,E"cnIO In its own manner. For example, if Encounler is in 5,"in90ualilirs state , and the event is the arrival of a foreign character. then the window pcrrOitting the setting of characler quality values disa ppears because th IS IS wha t the method ba.dl,E"rnIO in 5,111.90ual,Il<' is programmed to do An additional co nsequence of ,hIS particular even t/Slate comblOa tion IS that Encounter transition to rhe EII9agrng state , as required by the tate · tranSitIOn diagram This lransition is Implemenled by code
EncounterGame.setState ( newEngaging( » ;

The nexi ttme an event occurs in Ihe ga me, the I,alldI,E"oI IO funcllon of En9119in9 Will exeCUle, rcOectt ng the fac t ,h al the game IS now in Ih e En91191119 tat e

18.2.3 Virtual Machines AVlnual machmt ardulel.lurc::

trea lS an appli cation as a program written In a special-purpose language BecJuse

an Interpreter for such a language ha< lO be budt, lhl arch,tect"rc [.lays off on l If everal "program>' arc to be wmten '" the lanljUaHC, ge nerallng several appl,cal ,ons The Impl ementall on of a tO mpltlc vlftual rna h,ne requ lfe< the buddln!; of an Ifllcrprett r The lnt(:rpreLation requlrt:<; us to execute an o perall n- Iel 's JII It 1tI1trl'rt"() on a pro gram wntten In our lanllWge The 'nterpretall on of a prlmil ive clem ent alone (e g , a I'U '" the exa",ple of ~ h aplcr 17, ",here lhe part, of a " PU " are no t relevant ) " genera ll y Simple (flJr lhe ex.lIll l>lo, tim cou ld be >lmpl 10 pnnt lake

447

448

CHAPTER 18 SOFTWARE ARCHITECTURE

ho w to execute an i"'trprt'() (unct.on when ap pl. ed to a mo re complex "program ." T o do th .. , we may usc th e Interpreter de>l g n pattern. V.rtuaIOl" h". e arChllee!Ures arc advantageous .f th e application co ns"ts o f the process.ng of compit-x entit.es, and if these e nt itic , II h as th e v rders in the example , arc readi ly describable by a gramma r.

PU o ut f.t bo "l. The problem

IS

An add iti onal exa mple rcq uinng a Virtual machine is an app lica ti on th at provi des Cilmplc uscr-Jevd

prog ramming of a special purpose language. A nonprogra mmer use r, for exa mpl e, is ca pable of writlnS a "pt a s.mple program- uch a the fo 110"'111 g,

Balance checki ng / add excess to account + subt r a c t def ic it fr om sav ing; Save report / c : Reports + standard h e adings + except replace "Ed" by " Al " Pr i ntR e p o rt / sta ndard head i ngs e - mail reporttoJay n e@ xyz.net .

A virtual machine architecture parses and interprets such scripts . The idea of such architectures is dillst rated in Figure 18. 16.

18.2.4 Repository Architectures An architecture built pnmarily around data is called a rrposilory architecture. The most common of these arc ~ .. tcms deSIgned to p{'rfonn transactions against a databa se. For example, an electnc compa ny maintains a

database of custo me rs that ",eludes details about them , such as power usage eac h month , balance, payment hiStory, repa irs. and so on T ypical operations again st th is database are adding a new customer, crediting a pa ymem , rcquc tin g a payment history, reque sting a list of all customers more than three months in arrears.

and so o n. A typica l deSI gn for this kind of repository architecture is shown in Figure 18. 17 . This figure mixes the Aow of data between eMities (solid !tnes) and control (dashed lines). "Control" meJns that one of the en tities prompt th e operation of the other-for example. rurns It on and off. Other examples of applications with reposi tory architectures include interactive development environ .

me nlS (ID E ). IDEs apply processes such as ed.ting and co mpiling to a dalabase of source and object Ales. O ur Encounter exa mple in its simplest form docs not include a database.

if, however. it were to grow

Into a ga me Wilh man y ind ivi dual characters, then we might requ ire a database rather than J Aat Ale for storing t'he characters ThIS would certainly be true if we wanted to allow the user to ca ll up statIStics such as "list the characters Wilh strength under 10," and so on. Structured Query Language (SQI.) is a common way to express queries (sec, for example, [4]).

Application I

Application 2

Program I written in language understood by inte'l''''tcr

Program 2 written in language understood by intC'l'reler

I interpret~r I

I lnle'l'rc:ler I

Figure 18.16 Virtual machine archltectur~es;-lleveraging the Interpreter concept to facilitate the implementation of multiple applications

SOFTWARE ARCHITECTURE ALTERNATIVES AND THEIR CLASS MODElS

Analysis process 1

-

-~ • ••

Analysis process

Control

•••

• ••• ••

n

DBMS Key: Control flow : II Data flow: ..

~

Database

..

Figure 18 .17 A typical repository architecture

Blackboard architecture , developed for artificial intelligence applications, art reposltones that behave in accordance with posting ndes. The reader IS referred to [5] and [6] for a detailed treatment of blackboard archlt~ctures

The final ryPl" of repository architectures we

m ention

here

IS

the hypertext architecture The

m OS l

common u e of hypertext is on the Web. An application that manages the artifacts of a software engineering application is another example . The word "repoc;ilory" is often used in industry to den o te an app lication [hat provi des a und,ed view of a

collection of databases (, e., not just one). Th i relates to data wa rehouses RepositOries do not change the structure of these databases, but they allow lIn,jonn acce s to them ThIS is a peclal case of repository architectures as defined by Carlan and Shaw Repo nory architecrures occupy a significant frilctlOn of applications. Since so many architectures make

databases their core When the proces In g i negligible compared to the fonnattlng of data from the databa e, repOSitory architecture are appropriate . On the other hand , the presence of a large database can sometime mask the fact that a large amount of procesSing may dnve the architecture Ad hoc da,abase programmmB (e g., "stored procedure ") can eas ily mushroom into messy applitatlOns, wh ich perhaps should be conceived differently from the repository model.

18.2.5 layered Architectures An archltecturalltlytr I a coherent co llection of software artifacts, t)' picdlly a pa kage of classes In Its common form, a laye r u,es at mOst one other layer, and I used by at most one other layer. Budding appl, .t,on layer by layer ca n greatly <,mpl,fy the proce<s orne layers, such as framewo rks, ca n erw several applica tion> We have already seen the layered appro. h applied to the Entounter applICation , where clas«s '" the Encounter packa,!cs ",hent from cla<st' In the framework pack.ge> TI" " hown '" Figure 18 18 n,e Agure 'hows how we might orga ni ze the u'e of a 3·D graph ItS ens,"e", a laye r acce Sible from the Role· Pla 'Ing Came layer Fll!Ure 18 19 ,how, an examp le of a layered art hlle ture fran AJax bank pnntlng appil atlon n,ere arc four layers In thiS arth,tecture, and FI~urc 18 19 show, dependency 111 the reve". dire tl on ompared to Figure I ~ 18 The appli allon layer, AJax Bank P"ntlnl;, h., 10 do With prlntlnR and f rmattlnN II " olilit Upon (, e , u'>,,,) the Aunun!> and the AJax Bank ommon las> layer, The latter are blllh upon a \'endo l ~ppiled layer, which ~onlalns ~enera l utilitl su h as
449

,SO

CHAPTER 18

SOFTWARE ARCHITECTURE

3D

onglne loyer

D .. uses ...

Role-playing 9IIme Ilyer

ICharacters I

IRolePlayingGame I ILayoul I . - uses-

Application layer Encounter Characters

Encounter Environment

IEncounter Game I

Figure 18.18 Layered architectures. and example of 3D engine and video game

Requirement: Print monthly statements. Architecture: -uses" Ajax bank printing Layer I Accounts Layer I Ajax bank common IIbra.-Y' Layer Vendor-supplied Layer

+

Figure 18.19 Example of layered architecture for Ajax Bank-highest level view package of classes. For example, the Ajax com mo n library comprises classes used throughout Ajax applications, and addresses such issues as the bank's logo and its regulation s. The "using" relationship can be inheritance, aggregation , or object reference. In the example, only aggregation IS applied between layers, as shown In Figure 18.10.

18.2.6 Sen/ice-Oriented Architectures ScrvlCe-Orirnled Architectures (SOAs) arc gaining in usage. They are closely related to the idea of software as a service and cloud computing, and warrant inclusion with those discussed above. SO As arc combinations of S(flJicts: components that provide functionality according to an interf'ace speciAcation They differ from many

other application architectures in that they describe a sc t of interoperable components thilt can ~

dynamically harnessed to create functionality-rather than as a way to create a si ngle application SOAs arc in the spirit of facade objects, and include Web services as a means of Implementation. SOAs ace not necessarily obJect·oriented. In the case of Web servic« there is no assurance of globally defined classes as we have proVided for Facade In prior examples. For example, suppose that an SOA is for a businessto · busin~ss application concerning orJm. In an SO A, we would not assume that a unique Order class is known to and usable by all service suppliers and consumers. Web services in particular deals with this by dennln8 3 schema for an orderdat. structure, and referencing the schema when Web services Involve orders. Thi uses a Web service capability known as Web Seroicr D<scnption LAnguage and has the dfect of making an Order closs known to clients. This is summarized in Figures 18.21 , 18.12, and 18.23 .

SOFTWARE ARCHITECTURE ALTERNATIVES AND THEIR CLASS MODELS

Architecture

• •

t

~u s es"

Ajax bank printing Layer Acoounrs Layer Ajax bank common library Layer Vendor-supplied Layer

Class model: (relatIonships WIthin packages nol shown)

,-- - _. ,,

,,,

--_. _.. _. -----_. ---:'

IPrinter_-_._----_. I Formatter ----_ _- _ ..

------- ... : Accounts : r - - - - --. _. _------ --------., , Account Customer ,, , ,

,----====,-;'

iI

I

:'-_" Ajax bank co mmon library ,, w . ,, - - - - -- -- - - ..

----

Page

.. - - _ .. _-

_. "

,, ,, ,

Vendor·supplied layer nol shown

---- --- ----- --- . .. _- --- - -- ----- ... ,-- - ---- .... -. _- ---- ---. --- --- . ,

,, ,,

pnnting :,

Ajax bank

.._----_._- ---_ .... ---_ . . _- _. _--.,

,,,

Ajax Logo AjaxDisciaimer Regulations , , -----.----_.-._-- --------- .. ---------_ .. _-- .. ------_ .----- --.-- ------ .. __ .,

Figure 18.20 Layered architecture example uSing aggregation

Based o n compo nents th at provi de han ctio naln y accordin g to an interface spec

• Princ ipally via Web ervlces • In Ihe spiril of faca de o bjecls • NOl necessari ly 00 Example, An app lica ll o n co nce rnin g ordm • Wouldn'I assume an Ordrr class known 10 3 11 • Instead_ Defi ne an ordrr schema , refe rence when Web services involve orders Figure 1·S.21 Service-oriented architectures, 1 of 3 Servlcc -onented architecture,> e nvisage () network (mos tl y an Interne-t ) ·domlnated cnVlronml'm

which applications (and pans of app licatio ns) arc no t permanen dy wedded

10

In

each o lher Ralher SOAs

~ek to allow dy nam iC li nk ing of serviceS. For exa mple.-: , suppa e that you walll to write an appl. atlon that

orders
(The rderence for Figure 18 21 , 18 22, and 18 23 " l7] ) • ' Fire and forget"

• Stateless as much a< po-"ble • Extenslbte • Add,l",nal fun~lI o nalil Y eas il y added • Discoverable • Accou nt fo r Q ua lity o f Service

• h),

exa mpl ', security

FIgure 18.22 service-Oriented architectures, 2 of 3

In

order 10 Invoke It

451

452

CHAPTER 18 SOFTWARE ARCHITECTURE

• "Fife ,nd forget' • Sta teless 3') much as pOI:i'11 Ie • Extensible • Add,tional fun tionahty ea" ly added • Discoverable • Account for Quali ty of Service • For cXiimple. security

Figure 18.23 service-oriented architectures, 3 of 3

This defln<..'"S the components or the bu iness such as the customer data base and bu int."Ss. Credit poltcics arc cxampk--s of the latter. The s(nllCt 1t1Ier/aCt layer dennes the ser necs available that arc based upon the busincs proCl'SSCS. It specifics functionality such as listing all customers In the database and checking a transaction for conforma nce 10 buslncss rules. The laytr con iSt5 of applicat io ns buill usi ng the sCIVice internee la yer. These points are shown In Figure 18.24. crvice-onented architectures frequently uSc a bUSUltss proctss

"'Y"

.ppr.c."""

18.2.7 Using Multiple Architectures within an Application Applications typically use severa l subsidiary arc hitectures wIth in an overa ll architeclU re. Figure 18.25 shows how the fra mework for role-plaYing video games could use everal of the architecture types lIsted by Carlan and Shaw. It could make se nse, fo r example, to orga ni ze the ArtifMt, package as a database. The game characters could be VIewed as parallel communicati ng processes. We will design the overall control of the game as an event-driven sy tern .

Appplication A

Application B

Appplication C

(J

.. usesService Interface Layer

.. usesBusiness

Figure 18.24 Llyerlng for service-orlented architec1ures SOUn:f'. AQIc)ted from En. nlOfT'laS. " seMc:e
TRADING OFF ARCHITECTURE AlTERNAnVES

CharaCfers RolePlayingGame

Parallel communicatmg ___

processes

--______----

Rule-based

system

___ Event system Poslble

---------'

- -j'- architecture types used

Layoul

Database • system Layered _ _ _ _ __ system

Arlifacls

Database

system

Encounter Layout

Figure 18.25 Example of the use of multiple subsidiary archltectures-Encounter video game extension

18.3 TRADING OFF ARCHITECTURE ALTERNATIVES Since the hOler of a software archlte ture IS 0 lI11p Ortanl , It IS wi se to create more th.m one alternati ve for consideration . As an example, we will create and compare two Jrchit cctllrC'S fo r the video store applicat ion

For the nrs. candida.e, we separate .hl· applica'lOn In.o .hrce majo r pans, The "back ·end" da.abase , the middle pan , w hich cOnlains the bus lncss logic, and .he C Ul s. This IS • 1/",,·II(r archi.ecture . It IS often an appropria.e choice when some or all of .he .iers resi de on phYSically separa.e plattomlS In parllcular, If .he CUls are all on PCs, the middle la ye r on • server, and the databases controlled by a database managemen. system , then three· tier architectures map neatly to separare hardware and software unitS Note that there IS no n~ccsslty that hardware decompositions bt., the sam(.' as sofrware archltcctures, we ma y want a logical

(conceptual ) view of an applic.llon to be cnllre ly independen. of .he hardware platform, hosting " (These are the phYSlca' VICW vs .he 'oglCa' view .) App lYIl1£ three tiers to .he video Store applicallon, ,,'e cou ld ob .aln the architecture In Figure 18.26

,

VSOperalions

VSGUls

Presenta tIon

lIer

I

Figure 18,26 Three-lier architecture alternative

VSData

Dala tier

453

4S.

CHAPTER 18 SOFlWARE ARCHITECTURE

[" .......;;;;:;~~...............-..............'...........................'.................~;;;.~;~~,..~~~::::;~..............'..···...............··1 I

,

,

!I I I

I.,

: II

I

VSCuslomers

i i

I

I

1.. _ ••_ .... __ ..................... .....................

_

_

........................................... ............... ........'

1

........... .i•

Figure 18.27 Altemauve architecture for a video store application

The strength of this architecture IS that it's easy to unders tand. Anolher strength is that since the CUI part IS separate from the rental ope rati o ns it can be changed withoul di sturbin g the latter. O ne weakness is the coupling between the GUh package and the V50ptratio", package; there may be severa l CUI classes corresponding to the C. "om" class, for example. Therc is also cou pling between the classes in the V5Data package and the classes in V50p"alio", . A second architecture ca nd idate IS show n in Figure 18.27. Th is architecture g rou ps all of the classes pertaining to the vi deos in a package. The R",tal, package contains classes that relate videos and customers. The C" stomm package contains the classC"5 pertaining to customers, includi ng assoClaled CUls. A third option would be to group all d isplays in a package. Figure 18.28 summarizes onc opi nion of th ese architecture alternatives.

18,4 TOOLS FOR ARCHITECTURES Various computer·aided software engineering (CASE) tools arc used to facilitate the software engineering process. Some tools represent classes and Iheir relationships, such as Rat io nal Rose by IBM Corporation. These tools facilotate the drafting of object models, linking them with the correspo ndin g source code and sequence diagrams.

In selocting a modeli ng tool , a list of the requireme nts fo r the tool

IS

drawn up using procedures si milar

to the requirements analysis process for software application development. Here is an example of some requirements for modeling tools .

• Essential: Facilitate drawing object mo dels and sequence diagrams

• Essential , C real e classes quickly

Three-tier

Alternative

Understandable ) Flexible)

Yes Yes, CUI easy to change

Yes Yes, Basic building blocks easy to identify

Reusable)

Not very, Each layer is spocial to video store rentals Perhaps

Yes, Easy to generalize to generic rentals

Easy to construct)

Figure 18.21 A comparison of arChitectures example

Yes, Clear potential to use Facade

EFFECTS OF ARCHITECTURE SELECTION ON THE PROJECT PLAN

• Es ~ntt"

Ed,t cI,sses ea"ly

• Dcslrnble· hould cost no more than $X per user • Deslrnblc. Zoom Into part< of the model • Desirable. Possible to Ju mp direclly from the obJecl model 10 the source code • Optoonal , Reverse englneero ng available (i e., create object models from source code) • Oplional. Use color coding for tatu of class Implemental io n Tool packages frequen tl y try to span arch,teclllre, detaoled desIgn , and ImplementatIon . Varoous vendors are developong the capabi lity to hyperlink from source code to documentatoo n and VIce versa Implementati on-oriented tools uch as Javadoc can sometomes be use ful to supplement the desIgn process Javadoc is useful for navigatlllg packages because it provides an alphabeticallosting of classes and the parent hi~rarchy of each class. Interac tive development environments (IDEs) are delIvered with compolers and arc WIdely u ed as partial modeling tools. Object -Oroented IDEs ge nera ll y show inhentance In graphICal fonn , and developers are frequently auracted to these
18.5 IEEE STANDARDS FOR EXPRESSING DESIGNS The IEEE Software DeSIgn Document (SOD) slandard 10 16- 1998 provides gui delInes for Ihe documentation of deSIg n . The lable of cOntenlS is shown In F,gure 18.29 IEEE guidelones explain how the SOD could be written for various archilectural ryles, most of which are de
18_6 EFFECTS OF ARCHITECTURE SELECTION ON THE PROJECT PLAN Once: an architecture ha< bee n selecled, Ihe schedule ca n be made ma re >peclr, and more detaIled In partl ular, Ihe order in whIch part< are bUIlt can be dctennlncd For examp le , on the cas. study 11m, kes <ell," to fir" develop the (hamCler! fram ework pack.ge , followed by Ihe speCIfic EllcoulllrrCl",,,, I", appl,cat,on package S,n c thes packages w oll nOI be comple ted In Ihe ('''1 Iter.tlon f the ' llIr.I , we n.nte the

455

456

CHAPTER 18

SOFTWARE ARCHITECTURE

1. Introduction 1.1 1.2

1.3

•

4. Dependency description

Purpose Architecture Scope ..... Definitions, acronyms. ' and abbreviations IAI 5. •

2. References

4 .1 Intermodule dependencies 4 .2 Interprocess dependencies 4.3 Data dependencies Interlace description 5 . 1 Module interlace

y

5.1.1 Module 1 description 5.1.2 Module 2 descriplion 5 .2 Process interlace

3. Decomposition description 3. 1 Module decomposition 3. t. t Module 1 description 3. t . t Modute 2 descnption 3.2 Concurrent process decomposition

5.2. 1 Process 1 descriptIon 5.2.2 Process 2 description

6. Detailed design 6 .1 Module detailed design

3.2.1 Process 1 descrlpt jon 3.2.2 Process 2 descripl10n

6.1.1 Module 1 detail 6.2.2 Module 2 detail 6 .2 Data detailed design 6.2.1 Data entity t detail 6.2.2 Data entity 2 detail

3.3 Data decomposition 3.3.1 Data entry 1 descriplion 3.3.2 Data entry 2 description

Figure 18.29 Tlte architecture parts of IEEE 1016-1998-500 table of contents SOurce" IEEE Sttll016-199S.

corre ponding tasks ' Charac ters I" and "EncounterCharacters I." Arrows indicate depe ndence of packages on others. For example, "EncounterC haracters ('. cannot be completed with out th e completion of "C haracters I: as shown i n Figure 18. 30 . The sch edule sh ows th at "Integrati on and Te st I" canno t begIn until all of the other tasks In Iteration I have been completed.