Software Design 2e - DIM

186The rationale for methodto be aware of the potential that is present in the basic materials, and to know thebounds upon the capabilities of the system that will execute the process (whether thisbe a cook or a computer!).A design method intended for producing recipes might be able to provide someguidance as to how a recipe should be organized, presented and described, and wouldbe able to provide advice on:nnnhow to lay out the instructions to the cook (for example, terms to use and/or appropriateforms of measure);the best use of photographs, tables and so on;making suggestions about possible variants.But it cannot be more specific than this. Decisions about detailed issues – such as thechoice of ingredients and the amounts of each to be used, the length of time in theoven, the oven temperature to be used – must all depend upon the nature of the dishand the materials, not upon the format used for developing the recipe.Because a software design method provides a form of ‘process’ that is used todesign another process, it is all too easy for the inexperienced to fall into the trap ofbelieving that a design process is itself a recipe – but that is not so at all, as the aboveexample demonstrates. Instead, a recipe is something that is output from the designprocess, rather than being the model for the design process itself.One way in which it is possible to increase the amount of guidance from a methodslightly is to focus it upon a particular domain of problems. By concentrating upon(say) data-processing problems, or information-retrieval systems, it is possible to givesomewhat tighter guidance for some of the decisions that the designer needs to make.However, even this will be limited in the extent to which it can be usefully carried out.(In the ultimate, of course, we could narrow down the problem domain until themethod would be only suited to one problem!) In practice, most methods are aimed atreasonably wide domains so as to try to optimize their use: hence the benefits of familiaritywith the method.To make their forms as prescriptive as possible, design methods are based ondefining a set of carefully itemized sequences of actions that should be performed bya designer. Indeed, it is usually the only practical way of describing the process partof a method – as an analogy compare the complexity of writing and comprehendingprograms that contain parallel threads of execution with that of writing and comprehendingsequential programs. However, observed design practices suggest that experiencedsoftware designers may work on several different threads of action in parallel,and that these may also be at different levels of abstraction (Guindon and Curtis,1988; Visser and Hoc, 1990). So a design method that is described purely in termsof sequential actions can provide only a very inadequate approximation to expertbehaviour, although this might be partly offset by the iterations that are necessary indesign activity. (A further factor that may offset this disadvantage is that, as designersgain expertise, they may be better able to adapt a method to their needs, and so employparallel activities where their use would be appropriate.)The purpose of this section is not to encourage the idea that design methodsshould not be used, but rather to point out that they have limitations and that these