Rationale management in software engineering

Allen H. Dutoit, Raymond McCall, Ivan Mistrik, Barbara Paech3540309977, 9783540309970, 9783540309987

The emphasis on new and changing technologies and process models in today’s software development obscures the fact that software engineering is still primarily a human-based activity and that the success of a software project largely depends on the decisions made by humans during engineering. Rationale management is concerned with making these design and development decisions explicit to all stakeholders involved.

Dutoit, McCall, Mistrik and Paech begin their book with a historical survey of different rationale approaches. It is followed by four parts describing: the fundamental problems and possible solution approaches in rationale management, rationale management during requirements engineering, rationale management during software architecting, and rationale management for organizing reusable bodies of knowledge.

The result is a detailed summary of research on design rationale. It provides researchers with an excellent state-of-the-art overview, and professional software engineers will find many examples, resources and incentives to enhance their ability to make decisions during all phases of the software lifecycle.

Allen Dutoit, Ray McCall, Ivan Mistrik and Barbara Paech have done an excellent job of this in “Rationale management in software engineering”. The chapters in this volume show how design rationale can be incorporated into the heart of the software development process – into requirements engineering, software architecture, and code design. (John M. Carroll, Edward M. Frymoyer Professor of Information Sciences and Technology, Penn State University, USA, ACM CHI Lifetime Achievement Award)

---

Table of contents :
Contents……Page 12
Foreword……Page 6
Preface……Page 8
Contributors……Page 18
1.1. Introduction……Page 22
1.2. Design Rationale Fundamentals……Page 24
1.3. Approaches to Design Rationale……Page 28
1.4. Uses of DR and DR methods……Page 37
1.5. Limitations of Current DR Approaches and Software……Page 41
1.6. Rationale Management in Software Engineering……Page 45
1.7. Tool Support for Rationale Management……Page 57
1.8. Conclusion……Page 64
Part 1: Fundamentals – Rationale Representation, Capture and Use……Page 70
2.1. Introduction……Page 74
2.2. Explanations of Complex Systems……Page 76
2.3. Design Rationale as Explanation Content……Page 77
2.4. Three Cases of Design Rationale as Explanation……Page 79
2.5. Challenges and Opportunities for Design Rationale as Explanation……Page 88
2.6. Conclusion……Page 89
3.1. Introduction……Page 93
3.2. Design Perspectives and Rationale……Page 94
3.3. The Fundamental Barriers……Page 98
3.4. Transcending the barriers……Page 105
3.5. Conclusions……Page 108
4.1. Introduction……Page 111
4.2. Origins of Rationale in Software Projects……Page 112
4.3. Rationale as a By-Product……Page 114
4.4. Case 1: Capturing Rationale in Software Prototypes……Page 121
4.5. Case 2: Risk Analysis……Page 124
4.6. Discussion……Page 126
4.7. Conclusions……Page 127
5.1. Introduction and Overview……Page 130
5.2. The Vision……Page 131
5.3. The Design Rationale Capture Problem……Page 132
5.4. Understanding Cognitive Overhead……Page 133
5.5. Compendium……Page 134
5.6. Reasoning Services and Verification……Page 141
5.7. Revisiting ‘Intrusiveness’……Page 142
5.8. Examples of Compendium in Use……Page 143
5.9. Lessons Learnt and Conclusions……Page 148
Part 2: Rationale Management for Requirements Engineering……Page 152
6.1. Introduction……Page 156
6.2. The Process……Page 157
6.3. The Tool……Page 163
6.4. Example……Page 165
6.5. Experience……Page 167
6.6. Discussion……Page 169
7.1. Introduction……Page 174
7.2. State of Art in Rationale Management for Interactive Systems……Page 175
7.3. TEAM Notation……Page 176
7.4. DREAM Tool……Page 179
7.5. Case Study……Page 184
7.6. Conclusion……Page 189
8.1. Introduction……Page 192
8.2. The Theory W and WinWin Spiral Model in Software Development Process……Page 194
8.3. Fundamental WinWin Concepts……Page 197
8.4. Tool Support for WinWin Requirements Negotiation……Page 201
8.5. An Example Using WinWin in Software Development……Page 203
8.6. Using the Captured Rationale to Improve Later Decisions……Page 207
8.8. Future Directions……Page 208
9.1. Overview of EBPM……Page 210
9.2. The EBPM Paradigm……Page 211
9.3. EBPM Models……Page 214
9.4. Capturing Design Rationale……Page 218
9.5. Relations to Other Approaches……Page 224
9.6. Conclusion……Page 225
10.1. Introduction……Page 228
10.2. Overview of Design Rationale……Page 229
10.3. Understanding the RE Process……Page 232
10.4. RE Creativity in Relation to Psychology of Problem Solving……Page 237
10.5. Using DR to Support Creative RE Process……Page 240
10.6. Summary and Conclusion……Page 245
Part 3: Design Rationale and Software Architecting……Page 250
11.1. Introduction……Page 256
11.2. Background and Motivation……Page 257
11.3. Managing Architecture Design Knowledge……Page 260
11.4. Conclusions and Open Issues……Page 270
12.1. Introduction……Page 274
12.2. Structuring Rationale……Page 275
12.3. How Will Architectural Design Rationale Be Used?……Page 281
12.4. Capturing Rationale……Page 284
12.5. An Example of Capturing and Using Rationale……Page 288
12.6. Summary……Page 290
13.1. Introduction……Page 292
13.2. Related Work……Page 293
13.3. Rationale for Software Maintenance……Page 295
13.4. The SEURAT System……Page 296
13.5. SEURAT Evaluation……Page 310
13.6. Conclusions and Recommendations……Page 312
14.1. Introduction……Page 316
14.2. Approach……Page 317
14.3. The TFT-Panel Product Line……Page 321
14.4. Concept Assessment and Decision Making……Page 326
14.5. Conclusion……Page 330
15.1. Introduction……Page 332
15.2. SPE Classification Scheme and its Implications……Page 333
15.3. E-type Programs and the Role of Assumptions……Page 338
15.4. A Principle of Software Uncertainty……Page 341
15.5. Examples of Invalidation of Assumptions……Page 342
15.6. Practical Approaches and Recommendations……Page 343
15.7. Final Remarks……Page 344
16.1. Introduction……Page 348
16.2. Software Architecture……Page 349
16.3. Rationale in Software Architecture……Page 352
16.4. Design Decisions: The Bridge Between Rationale and Architecture……Page 354
16.5. Archium……Page 361
16.6. Related Work and Further Developments……Page 364
16.7. Summary……Page 365
Part 4: Rationale for Organizing Bodies of Knowledge……Page 368
17.1. Introduction……Page 372
17.2. Reusable Rationale Blocks and the Design Space……Page 376
17.3. RRB Process……Page 380
17.4. Illustrations……Page 382
17.5. Discussion and Conclusions……Page 387
18.1. Introduction……Page 391
18.2. Motivation for Defining Agile Patterns……Page 393
18.3. Agile Pattern Definition Approach……Page 395
18.4. Using the Agile Patterns……Page 403
18.5. Conclusions……Page 407
19.1. Introduction……Page 409
19.2. REPI Rationale……Page 411
19.3. Challenges Associated with REPI Rationale Capture and Reuse……Page 414
19.4. Capturing Rationale: A Tested Method……Page 415
19.5. A Snapshot of a Case Study……Page 419
19.6. Conclusion……Page 423
20.1. Introduction……Page 427
20.2. Capturing Engineering Experience in Patterns……Page 428
20.3. Examples for RE Patterns……Page 433
20.4. Working With RE Patterns……Page 439
20.5. Conclusion……Page 443
D……Page 446
P……Page 447
T……Page 448
W……Page 449