Additional paths and structures are captured while audio or video sources are recorded. For example, simple recordings can be replayed. In the end, there are several different recordings from one recorded session, e.g. a sequence of DOORS requirements discussed (sequence of Req.-IDs), specification structure (requirements within table of contents), and audio recording of discussion (time-indexed stream). All those parallel recordings are related through time stamps.
It is straightforward to link all recordings together for browsing, with an option to jump from one track of the record (audio, video, paths) to the other at common time-stamps. Looking at different perspectives (at the same recorded time) or following any of the paths creates an extended exploration space for learners. At the same time, the network of paths and structures is always associated with plain audio or video records that contextualize and explain things. One of the main values comes from guiding learners within a complex structure, such as a document or program.
We have also explored the opportunity to let a program search for suspicious or interesting patterns. In the FOCUS example, only a few trivial patterns were used, concerning hot spots (frequently executed or explained elements) and path deviations (when a method is executed but never explained) (issue explained but never executed).
Most approaches about design rationale include capturing as well as indexing and structuring. Raw data is considered unreadable and unsuited for learner use by some [13]. The task of abstracting and structuring raw data into more manageable rationale is indispensable.
According to this principle, the By-Product Approach is different. The recordings and paths and structural information usually add up to a large amount of data. A single Camtasia (screen video and audio) record of a one-hour meeting may easily be 100 MB large. However, there will be only a few of those essential meetings, and only a few recordings. This principle again represents a conscious and rather extreme decision: Do not care about a few Gigabytes of storage space, when they fit easily on a 2$-DVD. If no one takes the initiative to further extend or modify or transcribe recordings, the web of recorded “raw” data from one session might just be burnt on a DVD and represent a snapshot of the project history. If desired, it can always be loaded back into the computer and updated. It was our initial intention to keep the rationale alive over an extended period of time. During the experiments with the two case examples, we had to accept that this rarely happens. In most cases, the effort required for creating a snapshot is much less than the effort needed for continuous rationale management. This approach was shaped by observations in software projects and optimized from a pragmatic point of view. Continuing rationale management is certainly desirable from a methodological perspective.
