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) 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
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)
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. This is a detailed summary of research on design rationale providing researchers in software engineering with an excellent overview of the subject. Professional software engineers will find many examples, resources and incentives to enhance their ability to make decisions during all phases of the software lifecycle. Software engineering is still primarily a human-based activity and rationale management is concerned with making design and development decisions explicit to all stakeholders involved.
