As described in Sect. 1.4, there are many different uses of rationale. Clearly, rationale can be provided on all decisions during SE. According to the sketch of the new version to be published in summer 2006, SPICE distinguishes the following process areas:
−Acquisition and supply (CUS1 and CUS2)
−Engineering (CUS3, ENG1, and ENG2)
−Operation (CUS 4)
−Support Processes (SUP1 to SUP8)
−Management (MAN1 to MAN4)
−Reuse (ORG6)
−Process improvement (ORG1, ORG2, and ORG5)
−Resource and infrastructure (ORG3 and ORG4)
In the following, we describe these process areas and analyze how ration-ale management could support ongoing or future activities.
When we defined DR in Sect. 1.2.1, we used a broad definition of the design process. But no reasonable definition of design is broad enough to encompass all the processes described in SPICE. Many of these processes involve decision making that is not part of design. If we consider carefully how the rationale associated with these decisions is generated and used, it becomes clear that the concept of DR is not broad enough to include all the rationale that needs to be managed in SE We have defined the term DR in a way that corresponds to how it is typically defined in the literature. In this definition, DR includes two things: (1) rationale generated by designers, regardless of who makes use of that rationale and (2) rationale used by designers, regardless of who generates that rationale. Thus, if rationale generated by designers is used by software maintenance personnel, it is typically called DR. If rationale, generated by software maintenance personnel is used by designers, e.g., to design a future version of the software, then it is also typically called design rationale.
This definition of DR might seem to suggest that the only rationale in SE is design rationale. But we can see that this is not so by looking carefully at decisions taken in the no design processes of an SE project, for example, decision made in software maintenance. The people who make such decisions often do so, on the basis of explicitly stated rationale. Some of this rationale might be useful for design, as indicated earlier, and we could, according to our definitions, count this as DR. It is quite possible, however, that some of the rationale is only useful for maintenance, e.g., for keeping track of which maintenance decisions have been made and what the justification was for these decisions. In this case, the label DR is not appropriate. We would have to call this something like maintenance rationale. Once we acknowledge the legitimacy of such a term, however, it seems that some of what we have called DR might with equal justification be labeled maintenance rationale. By extension we can see that every process within SE has an equal claim to having rationale of its own.
Since design is only one of many SE processes, the term DR is not general enough to encompasses all the types of rationale that a rationale management systems needs to deal with in SE. In the following sections we will therefore use the term software engineering rationale (SER) to encompass all these different types of rationale. We use the term rationale when we do not specifically address the difference between SER and DR.
There is every reason to expect that the discussion on DR (SER for design) presented in the previous sections will be true for every other kind of SER. There may, however, turn out to be additional facets.
