77,99 €
inkl. MwSt.
Versandkostenfrei*
Versandfertig in 1-2 Wochen
payback
39 °P sammeln
  • Gebundenes Buch

Rationale is the justification behind decisions. It is captured and used in different forms in software engineering. Rationale increases the developers' understanding of the system, facilitating evolution and maintenance. In the 1980s, the software engineering community focused on general-purpose approaches for rationale, such as IBIS, QOC, or DRL. However, these approaches entail the formalization of tacit knowledge, introducing much overhead and disruption during development. These challenges shifted the initial interest in general-purpose approaches to specialized situations in which…mehr

Produktbeschreibung
Rationale is the justification behind decisions. It is captured and used in different forms in software engineering. Rationale increases the developers' understanding of the system, facilitating evolution and maintenance. In the 1980s, the software engineering community focused on general-purpose approaches for rationale, such as IBIS, QOC, or DRL. However, these approaches entail the formalization of tacit knowledge, introducing much overhead and disruption during development. These challenges shifted the initial interest in general-purpose approaches to specialized situations in which rationale is particularly beneficial. For example, design patterns feature rationale describing when the pattern is applied. Distributed projects make rationale explicit for the collaboration of participants who never met in person. In recent years, rationale research has become fragmented in many different communities and less identifiable as a research endeavor by itself. Consequently, this goal of this book is to bring under a single roof the available knowledge on fundamental rationale approaches and their applications to software engineering
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.
Autorenporträt
Allen H. Dutoit, TU Munich, Germany / Raymond McCall, University Colorado, Boulder, CO, USA / Ivan Mistrik, Fraunhofer Institute, Darmstadt, Germany / Barbara Paech, University Heidelberg, Germany
Rezensionen
Ten years ago, with Tom Moran, I edited a book entitled "Design Rationale." I think that book has held up quite well, though a decade onward it does seem a bit prefatory. It is past time for another detailed summary of research on design rationale. 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 Carroll, School of Information Sciences and Technology, Penn State University, USA)