Skip to main content

2008 | Buch

Rationale-Based Software Engineering

verfasst von: Janet E. Burge, John M. Carroll, Raymond McCall, Ivan Mistrik

Verlag: Springer Berlin Heidelberg

insite
SUCHEN

Über dieses Buch

Many decisions are required throughout the software development process. These decisions, and to some extent the decision-making process itself, can best be documented as the rationale for the system, which will reveal not only what was done during development but the reasons behind the choices made and alternatives considered and rejected. This information becomes increasingly critical as software development becomes more distributed and encompasses the corporate knowledge both used and refined during the development process. The capture of rationale helps to ensure that decisions are well thought out and justified and the use of rationale can help avoid the mistakes of the past during both the development of the current system and when software products (architecture and design, as well as code) are reused in future systems.

Burge, Carroll, McCall, and Mistrík describe in detail the capture and use of design rationale in software engineering to improve the quality of software. Their book is the first comprehensive and unified treatment of rationale usage in software engineering. It provides a consistent conceptual framework and a unified terminology for comparing, contrasting and combining the myriad approaches to rationale in software engineering. It is both an excellent introductory text for those new to the field and a uniquely valuable reference for experienced rationale researchers. The book covers the use of rationale for decision making throughout the software lifecycle, starting from the first decisions in a project and continuing through requirements definition, design, implementation, testing, maintenance, redesign and reuse.

Inhaltsverzeichnis

Frontmatter

Introduction

Frontmatter
1. What is Rationale and Why Does It Matter?
As the term is used here, rationale is the reasoning underlying the creation and use of artifacts. Software engineering research on rationale aims to devise methods and systems for managing rationale throughout the software engineering process. Managing rationale includes eliciting it, recording it, indexing it for retrieval, editing it, and retrieving it for those who need it. Recorded rationale can play a valuable role in every stage of the software lifecycle and for every participant in that lifecycle. It can help developers to create better software by enabling them to learn from the successes and failures of the past. It can facilitate coordination and collaboration within development teams, aid in identification and analysis of requirements, as well as design, testing and maintenance. It can even help users to understand the systems they use.
2. What Makes Software Different
Research on rationale in software engineering was originally inspired by research on rationale for the design of physical artifacts. While there is still much that software engineering can learn from the latter, it is important to recognize that the process of software development differs in crucial ways from the processes of developing physical artifacts. These differences have important consequences for the successful implementation of rationale management. One consequence is that software development has unique and urgent problems that rationale management can do much to solve. Another is that the ways in which software differs from a physical artifact provide unique advantages for implementing rationale management in software engineering.
3. Rationale and Software Engineering
Software engineering, the process of developing software intensive systems, is a complex area. This chapter introduces software engineering as well as the potential benefits in capturing, maintaining, and reusing rationale to support it.
4. Learning from Rationale Research in Other Domains
While issues of rationale usage in software engineering (SE) often differ crucially from those of rationale usage in other domains, there is still the possibility of learning a great deal from research on other domains. This is suggested by the fact that rationale research in SE originally derived from Rittel's much earlier rationale research in architecture (building design), urban planning and policy making. In addition to this work, which is still not widely known in SE circles, there is research on rationale that has been going on in various engineering disciplines for as much as 20 years. All of this work provides potentially valuable lessons for SE researchers and developers. This chapter will look at some examples of this work that could have important implications for rationale research in SE.
5. Decision-Making in Software Engineering
This chapter examines human decision-making, its role in software engineering, and the role that rationale can play in the decision-making that occurs within software engineering.

Uses for Rationale

Frontmatter
6. Presentation of Rationale
This chapter examines issues of presentation for software engineering rationale (SER). The substance, the content of rationale is always mediated by some presentation. The presentation could be free form, natural language text, or a formal, symbolic language; it could be printed sheets of paper, or three-dimensional displays in a virtual environment. The presentation of rationale has its own effects on the utility of rationale as an information resource in software development.
7. Evaluation
Software Engineering Rationale (SER) can play several roles in supporting system evaluation. One is to support the evaluation of decision alternatives by providing the means to capture the arguments for and against each alternative. The rationale can be used to automatically calculate support for alternatives and present it to the developer to assist them in making, or revising, their decisions. Rationale also supports usability evaluation by providing a process for analyzing use scenarios via Scenario-Claims Analysis (SCA) (Carroll and Rosson 1992; Carroll 2002). In this chapter, we discuss a number of approaches for using rationale to evaluate the alternatives to assist with decision-making and also how SCA supports usability evaluation.
8. Support for Collaboration
This chapter examines collaboration with respect to design rationale. On the one hand, this is a discussion of how collaboration can support the development, codification and use of design rationale. On the other hand, it is a discussion of how rationale supports collaboration in design and development.
9. Change Analysis
Keeping track of how changes in decisions require changes in other decisions is crucial in design and development. By capturing decision tasks and decision alternatives in the rationale, and by recording the dependencies between these decisions, we can help to anticipate the effects of changes and identify the different kinds of inter-decision dependencies. In this chapter we explain the implications of change analysis for rationale usage and rationale support systems in software engineering.

Rationale and Software Engineering

Frontmatter
10. Rationale and the Software Lifecycle
Software development can be modeled using a number of different lifecycle,or process, models. These include the waterfall model, the spiral model, the Unified Process, V-Model, and others. In this chapter, we will describe these models and how rationale capture and use supports the development process followed in each of them.
11. Rationale and Requirements Engineering
Many of the decisions that have the greatest impact on the software development process are made during requirements analysis. Software Engineering Rationale(SER)can support this process by providing the ability to capture the decisions and the reasons behind them starting at these earliest phases. SER also supports requirements traceability throughout the process by directly mapping the development options chosen to the requirements that provide their rationale and by providing rationale for the requirements, thereby mapping requirements back to their source. In this chapter, we describe how rationale can support requirements engineering.
12. Rationale and Software Design
More has been written about software design rationale than about any other topic in research on software engineering rationale. Much work has gone into identifying the value of design rationale for software developers, maintainers and users; but realizing this value requires that approaches to rationale capture and delivery be successfully integrated into the processes of software design. This chapter looks at the complexities of this task and a variety of approaches that researchers have adopted for dealing with them.
13. Rationale and Software VV&T
Designing and developing effective verification, validation, and testing strategies is always a challenge. The testing strategy needs to take into account the crucial balance between cost and quality and make appropriate tradeoffs depending on the specific project. In this chapter, we will investigate whether the presence of Software Engineering Rationale (SER) can assist in determining how and what to test.
14. Rationale and Software Maintenance
Software maintenance can be very expensive part of the software development process. Anyone working in the software industry during the years leading up to the year 2000 (Y2K) is all too familiar with the often unexpectedly long life-span of many software systems. The difficulties of maintaining these systems are acerbated because the original developers are often not available. Software Engineering Rationale (SER) would provide insight into why the system is the way it is by giving the reasons behind the decisions made during design and implementation. Rationale could help to indicate where changes might be needed during maintenance if design goals change and help the maintainer avoid repeating earlier mistakes by explicitly documenting alternatives that were tried earlier that did not work. In this chapter we will look at these and other ways that rationale can assist with software maintenance.
15. Rationale and Software Re-use
In this chapter, we describe how Software Engineering Rationale(SER)can be used during many types of software re-use, including how rationale can assist during Component-Based Software Engineering, with Software Product Lines and COTS-based software development.

Frameworks for Rationale-Based Software Engineering

Frontmatter
16. A Conceptual Framework
Exploiting the full potential of rationale in software engineering requires a comprehensive understanding of that potential. Such understanding must be based on a conceptual framework that describes how and where ratioale usage can support SE. This framework should identify where and how rationale can be used in software projects. It should also provide a set of concepts for comparing proposed approaches to rationale and for relating them to the various aspects of software engineering.
17. An Architectural Framework
A rationale-based approach to software engineering requires rationale management systems that can integrate the many types of rationale with each other and with the processes of creating software engineering artifacts. Accomplishing this integration in turn requires that such systems be actively connected with software engineering tools, external communication sources and persistent stores of reusable rationale. This chapter describes an architectural framework for such integrative rationale management systems.
18. Rationale-Based Software Engineering: Summary and Prospect
This chapter summarizes the main points of this book and looks at the prospects for rationale to aid software engineers in dealing with the problems of future software development. It concludes that while the potential of rationale to aid software engineering is great, several crucial issues must be resolved if this potential is to be realized.
Backmatter
Metadaten
Titel
Rationale-Based Software Engineering
verfasst von
Janet E. Burge
John M. Carroll
Raymond McCall
Ivan Mistrik
Copyright-Jahr
2008
Verlag
Springer Berlin Heidelberg
Electronic ISBN
978-3-540-77583-6
Print ISBN
978-3-540-77582-9
DOI
https://doi.org/10.1007/978-3-540-77583-6

Premium Partner