Software Design 2e - DIM

the viewpoint of the maintenance team who may later need to extend and modify thedesign. Unfortunately, while designers may diligently record the actual decisions, it ismuch rarer to record the rationale that forms the basis for the final choice. (Experiencesuggests that this is not a problem that is confined to software engineering alone: itseems to occur in many other branches of engineering practice too.)Beginning with the original task of design, the recording of rationale is likely to beencouraged if the design process includes any form of design audit. Such an audit mayconsist of peer review of the designer’s ideas, or may be something more formal that isconducted by the project manager. Whatever the form, if audits are held, they will bemore systematically and usefully performed if the reasons for decisions are recorded.There is an even stronger need on the part of the system maintenance task (whichis thought to involve around 50–80 per cent of programmer and designer effort). Inorder to modify or extend a design, the maintenance designers need to be able to recapturethe original models that were used by the designers of a system. Only when theyhave a reasonably complete model can they reliably decide how to implement theirchanges in the most effective manner (Littman et al., 1987). Possessing some record ofthe reasons for the existing structure can help both with recreating this model and withevaluating the effects of any changes. In turn, the reasons for the change need to beadded to the records kept by the maintainers, in order to maintain a consistent andcomplete history of the system design.So a major motivation for recording the reasoning behind any design decisions is oneof quality control, both at the design stage and also much later, during maintenance.Only if we have a complete picture can we hope to fully understand a design, and thisis an essential factor in producing a good, reliable design.Unfortunately, while software design methods generally provide good forms ofsupport for recording decisions about product issues, usually through diagrams orother notation, they are generally weaker on process matters, such as recording thereasons for the decision. While the recording of decisions and their reasons can fairlyeasily be made a part of design practice, it is relatively hard to enforce it unless there isa strong quality control system in operation.The way in which design decisions are recorded is obviously somewhat dependentupon the design process adopted. Some work has been performed to look at ways ofmodelling this process of design deliberation – the ‘Potts and Bruns model’ (Potts andBruns, 1988; Lee, 1991) – and it has been demonstrated for the JSD method. As yet,though, there is little or no general tool support that can be used for this task.An important issue in terms of recording decisions about a design has been raisedby Parnas and Clements (1986). They have observed that, even if the design processactually used to produce a design is not a rational one, the documentation that isfinally produced should still make it appear as though it were. In other words, thedocumentation should be written as though the ‘ideal’ design process was the one thatwas followed. Indeed, they argue that since design will never be a rational process (aswe have been observing throughout this and the preceding chapter), any documentationproduced will always need to ‘fake’ this appearance of rationality.The principal benefits of such an approach are that new members of a design teamshould be able to absorb knowledge about the project much more easily, and also thatthe eventual task of maintaining the system will also be made easier. Parnas andClements observe that even for a scientific document such as a mathematical proof, the39Recording design decisions