The term approach refers to a set of guiding principles for someone to follow in order to achieve a certain goal. The By-Product Approach is defined by two goals and seven principles:
Goals:
(1)Capture rationale during specific tasks within software projects
(2)Be as little intrusive as possible to the bearer of the rational
Principles
(1)Focus on a project task in which rationale is surfacing
(2)Capture rationale during that task (not as a separate activity)
(3)Put as little extra burden as possible on the bearer of the rationale (but maybe on other people)
(4)Focus on recording during the original activity, defer indexing, structuring etc. to a follow-up activity carried out by others.
(5)Use a computer for recording and for capturing additional task-specific information for structuring
(6)Analyze recordings, search for patterns
(7)Encourage, but do not insist on further rationale management
All together, the principles shift effort away (1) from the time when project tasks are being carried out and (2) from experts and bearers of design rationale. Therefore, it may look from their perspective like the rationale is really “captured as a by-product of doing normal work.” This is what counts. It justifies the name “By-Product Approach”.
The style of describing a “method” or “approach” by a list of interconnected principles was successfully used by Beck in his widely known description of extreme Programming [2].
The principles respond to the challenges mentioned in Sects. 4.1 and 4.2. They were inferred from observations and hypotheses in the above-mentioned attempts to capture rationale. Like in Beck’s description of extreme Programming, principles are not fully comprehensible by reading their titles only. In the remainder of this section, each principle will be explained with respect to the entire approach. Neither goals nor principles may sound extremely new or innovative. The difference is in their details and their combination.
For the purpose of the following discussion, a learner role is introduced. A learner in this context is a person who will need to use a certain kind of rationale in the future. Without support, a learner might simply talk to the bearer of the rationale and search additional material to read. This is a tedious task, as experts are often busy or not available. There may be a larger group of learners sharing similar interests and information needs. Instead of asking the same questions again and again, capturing rationale and keeping it persistent will assist in distributing it. Moreover, by focusing and supporting the teaching process the By-Product Approach is intended to pay off even with only one learner involved.
The By-Product Approach can be applied to different situations and activities in software engineering. It helps to identify rewarding activities and to design specific computer support. To build those software features,
