McCall / Mistrik / Paech Rationale Management in Software Engineering

1. Auflage 2007
ISBN: 978-3-540-30998-7
Verlag: Springer-Verlag
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)

E-Book, Englisch, 434 Seiten

Thirty years ago, I first entered the dark realm of software engineering, through a prior interest in documentation. In those days, documentation pretty much meant functional specifications. The idea that stakeholders in a system (its implementers, its end-users, its maintainers, and so forth) might want something other than an alphabetic list of function definitions was just taking hold. There was an exciting (to me) vision of stakeholders accessing and contributing to explanations of how and why aspects of a system work as they do, tradeoff analysis of concomitant downsides, and perhaps even accounts of why other possible approaches were not followed. There were many challenges to overcome in achieving this vision. The most formidable is the belief that people do not like to create or use do- mentation. This negative image of documentation is (unfortunately) more than just the bias of a few incorrigible system developers. It is more like a deep truth about human information behavior, about how human beings construe and act towards information. Humans are, by default, active users of information; they want to try things out, and get things done. When documentation is interposed as a prerequisite between people and a desired activity, they try to skip through it, circumvent it, or undermine it. Desi- ing information to suit the needs and interests of its users is an abiding challenge, but we have come a long way from functional specifications as the only answer.

Autoren/Hrsg.

McCall, Raymond

Mistrik, Ivan

Paech, Barbara

Inhaltsverzeichnis

1;Foreword;6
2;Preface;8
2.1;Introduction;8
2.2;Book Overview;9
3;Contents;12
4;Contributors;18
5;Rationale Management in Software Engineering: Concepts and Techniques;22
5.1;1.1 Introduction;22
5.2;1.2 Design Rationale Fundamentals;24
5.3;1.3 Approaches to Design Rationale;28
5.4;1.4 Uses of DR and DR Methods;37
5.5;1.5 Limitations of Current DR Approaches and Software;41
5.6;1.6 Rationale Management in Software Engineering;45
5.7;1.7 Tool Support for Rationale Management;57
5.8;1.8 Conclusion;64
6;Part 1 Fundamentals – Rationale Representation, Capture, and Use;70
6.1;Three Studies of Design Rationale as Explanation;74
6.1.1;2.1 Introduction;74
6.1.2;2.2 Explanations of Complex Systems;76
6.1.3;2.3 Design Rationale as Explanation Content;77
6.1.4;2.4 Three Cases of Design Rationale as Explanation;79
6.1.5;2.5 Challenges and Opportunities for Design Rationale as Explanation;88
6.1.6;2.6 Conclusion;89
6.2;Effective Design Rationale: Understanding the Barriers;93
6.2.1;3.1 Introduction;93
6.2.2;3.2 Design Perspectives and Rationale;94
6.2.3;3.3 The Fundamental Barriers;98
6.2.4;3.4 Transcending the Barriers;105
6.2.5;3.5 Conclusions;108
6.3;Rationale as a By-Product;111
6.3.1;4.1 Introduction;111
6.3.2;4.2 Origins of Rationale in Software Projects;112
6.3.3;4.3 Rationale as a By-Product;114
6.3.4;4.4 Case 1: Capturing Rationale in Software Prototypes;121
6.3.5;4.5 Case 2: Risk Analysis;124
6.3.6;4.6 Discussion;126
6.3.7;4.7 Conclusions;127
6.4;Hypermedia Support for Argumentation- Based Rationale: 15 Years on from gIBIS and QOC;130
6.4.1;5.1 Introduction and Overview;130
6.4.2;5.2 The Vision;131
6.4.3;5.3 The Design Rationale Capture Problem;132
6.4.4;5.4 Understanding Cognitive Overhead;133
6.4.5;5.5 Compendium;134
6.4.6;5.6 Reasoning Services and Verification;141
6.4.7;5.7 Revisiting ‘Intrusiveness’;142
6.4.8;5.8 Examples of Compendium in Use;143
6.4.9;5.9 Lessons Learnt and Conclusions;148
7;Part 2 Rationale Management for Requirements Engineering;152
7.1;A Hybrid Approach to Upstream Requirements: IBIS and Cognitive Mapping;156
7.1.1;6.1 Introduction;156
7.1.2;6.2 The Process;157
7.1.3;6.3 The Tool;163
7.1.4;6.4 Example;165
7.1.5;6.5 Experience;167
7.1.6;6.6 Discussion;169
7.2;From DREAM to Reality: Specificities of Interactive Systems Development With Respect To Rationale Management;174
7.2.1;7.1 Introduction;174
7.2.2;7.2 State of Art in Rationale Management for Interactive Systems;175
7.2.3;7.3 TEAM Notation;176
7.2.4;7.4 DREAM Tool;179
7.2.5;7.5 Case Study;184
7.2.6;7.6 Conclusion;189
7.3;The WinWin Approach: Using a Requirements Negotiation Tool for Rationale Capture and Use;192
7.3.1;8.1 Introduction;192
7.3.2;8.2 The Theory W and WinWin Spiral Model in Software Development Process;194
7.3.3;8.3 Fundamental WinWin Concepts;197
7.3.4;8.4 Tool Support for WinWin Requirements Negotiation;201
7.3.5;8.5 An Example – Using WinWin in Software Development ;203
7.3.6;8.6 Using the Captured Rationale to Improve Later Decisions ;207
7.3.7;8.8 Future Directions;208
7.3.8;8.7 Related Work;208
7.4;Design Rationale in Exemplary Business Process Modeling;210
7.4.1;9.1 Overview of Exemplary Business Process Modeling;210
7.4.2;9.2 The EBPM Paradigm;211
7.4.3;9.3 EBPM Models;214
7.4.4;9.4 Capturing Design Rationale;218
7.4.5;9.5 Relations to Other Approaches;224
7.4.6;9.6 Conclusion;225
7.5;Promoting and Supporting Requirements Engineering Creativity;228
7.5.1;10.1 Introduction;228
7.5.2;10.2 Overview of Design Rationale;229
7.5.3;10.3 Understanding the RE Process ;232
7.5.4;10.4 RE Creativity in Relation to Psychology of Problem Solving;237
7.5.5;10.5 Using DR to Support Creative RE Process;240
7.5.6;10.6 Summary and Conclusion;245
8;Part 3 Design Rationale and Software Architecting;250
8.1;A Framework for Supporting Architecture Knowledge and Rationale Management;256
8.1.1;11.1 Introduction;256
8.1.2;11.2 Background and Motivation;257
8.1.3;11.3 Managing Architecture Design Knowledge ;260
8.1.4;11.4 Conclusions and Open Issues;270
8.2;Capturing and Using Rationale for a Software Architecture;274
8.2.1;12.1 Introduction;274
8.2.2;12.2 Structuring Rationale;275
8.2.3;12.3 How will Architectural Design Rationale be Used? ;281
8.2.4;12.4 Capturing Rationale;284
8.2.5;12.5 An Example of Capturing and Using Rationale ;288
8.2.6;12.6 Summary;290
8.3;Rationale-Based Support for Software Maintenance;292
8.3.1;13.1 Introduction;292
8.3.2;13.2 Related Work;293
8.3.3;13.3 Rationale for Software Maintenance;295
8.3.4;13.4 The SEURAT System ;296
8.3.5;13.5 SEURAT Evaluation;310
8.3.6;13.6 Conclusions and Recommendations ;312
8.4;The Role of Rationale in the Design of Product Line Architectures – A Case Study from Industry;316
8.4.1;14.1 Introduction;316
8.4.2;14.2 Approach;317
8.4.3;14.3 The TFT-Panel Product Line ;321
8.4.4;14.4 Concept Assessment and Decision Making ;326
8.4.5;14.5 Conclusion;330
8.5;The Role and Impact of Assumptions in Software Engineering and its Products;332
8.5.1;15.1 Introduction;332
8.5.2;15.2 SPE Classification Scheme and its Implications ;333
8.5.3;15.3 E-type Programs and the Role of Assumptions ;338
8.5.4;15.4 A Principle of Software Uncertainty ;341
8.5.5;15.5 Examples of Invalidation of Assumptions ;342
8.5.6;15.6 Practical Approaches and Recommendations;343
8.5.7;15.7 Final Remarks;344
8.6;Design Decisions: The Bridge between Rationale and Architecture;348
8.6.1;16.1 Introduction;348
8.6.2;16.2 Software Architecture;349
8.6.3;16.3 Rationale in Software Architecture;352
8.6.4;16.4 Design Decisions: The Bridge Between Rationale and Architecture ;354
8.6.5;16.5 Archium;361
8.6.6;16.6 Related Work and Further Developments ;364
8.6.7;16.7 Summary;365
9;Part 4 Rationale for Organizing Bodies of Knowledge;368
9.1;Reusable Rationale Blocks: Improving Quality and Efficiency of Design Choices;372
9.1.1;17.1 Introduction;372
9.1.2;17.2 Reusable Rationale Blocks and the Design Space ;376
9.1.3;17.3 RRB Process;380
9.1.4;17.4 Illustrations;382
9.1.5;17.5 Discussion and Conclusions ;387
9.2;Defining Agile Patterns;391
9.2.1;18.1 Introduction;391
9.2.2;18.2 Motivation for Defining Agile Patterns ;393
9.2.3;18.3 Agile Pattern Definition Approach ;395
9.2.4;18.4 Using the Agile Patterns;403
9.2.5;18.5 Conclusions;407
9.3;Capturing and Reusing Rationale Associated with Requirements Engineering Process Improvement: A Case Study;409
9.3.1;19.1 Introduction;409
9.3.2;19.2 REPI Rationale ;411
9.3.3;19.3 Challenges Associated with REPI Rationale Capture and Reuse;414
9.3.4;19.4 Capturing Rationale: A Tested Method;415
9.3.5;19.5 A Snapshot of a Case Study ;419
9.3.6;19.6 Conclusion;423
9.4;Using Patterns for Sharing Requirements Engineering Process Rationales ;427
9.4.1;20.1 Introduction;427
9.4.2;20.2 Capturing Engineering Experience in Patterns ;428
9.4.3;20.3 Examples for RE Patterns ;433
9.4.4;20.4 Working With RE Patterns ;439
9.4.5;20.5 Conclusion;443
10;Index;446