Figure 3.3: Three domains of discourse in the design process (Kensing & Munk- Madsen, 1993)
Table 3.2 illustrates the division between the two areas of knowledge. Abstract knowledge, if interpreted in the light of the three domains of discourse, can be separated into several areas of knowledge:
• Relevant structures on users’ present work: For example, analytical models of the current system;
• Visions and design proposals: For example, analytical models of the new system; • and Technological options: Simple reviews of design possibilities.
The main difference between abstract and concrete knowledge in practice is the emphasis placed on experience when looking at the areas of concrete knowledge:
• Concrete experience with users’ present work: Think-aloud experiments, observations, mock-ups etc.
• Concrete experience with the new system: testing prototypes, card games etc. • and Concrete experience with technological options: familiarity with similar types
of software etc.
User’s present work New system Technological options Abstract Concret Relevant structur { &%sers* present Concrete expenencft ^AtWers' p Visions and ^^daignprop OverView technolo. Concret % with r.'4 optior
Table 3.2: Six areas of knowledge in user-developer communication (Kensing & Munk-Madsen, 1993)
Kensing & Munk-Madsen's (1993) model gives us a robust taxonomy for differentiating between techniques. Data-flow diagrams, for example, are classified as being good at presenting relevant structures on the users present work and good for developing visions and design proposals. Conceptual modelling and rich pictures, two cornerstones of the SSM method, are also classified as being good for presenting relevant structures on the users present work. In addition, the authors also feel that rich pictures are good for developing a concrete understanding of the users present work.
Their theory is lacking when it comes to describe the choices between tools and techniques. Apart from highlighting the importance of covering all o f the knowledge areas during the life-time of the project; and highlighting the responsibilities of both users and developers in covering these areas, they only gives very general recommendations on tool usage:
"'The use o f any tool or technique must be adapted to the particular conditions o f each system development process. In particular, the users ’ prior experience with the tools and techniques must be considered. Some tools and techniques are almost always used successfully by developers and users working together. Others should rather be part o f an extended process, in which developers gather information in co-operation with users, produce descriptions in isolation, and finally present, discuss, and alter the descriptions again together with the users.
Techniques such as future workshops and mock-ups belong to the first category, while object-oriented analysis and conceptual modelling belong to the later j"'
p.83 (Kensing & Munk-Madsen, 1993).
Another problem with the authors approach is the manner in which they address communication purely on a developer-user basis, reflecting the concerns of the philosophical school that they ascribe to.
3.2.2.4 Observations
Each of the three approaches have attempted, in their own way, to bridge the gap between the dominant theories on system development, and the varying ways in which methodologies are interpreted. Davis’ (1982) toolbox of methodologies idea suggests that there is a methodology for every problem. While it is certainly true that some methodologies are more useful for some projects rather than for others, his basic thesis is that a methodology does not have to be customised; the right criteria have to be available to enable ^proper methodology choice \ While this theory is certainly interesting, I have highlighted a number of faults in Davis’ (1982) theory, or problems that would limit its application. The second theory to be explored was livari’s (1989) toolboxing methodology, where a number of techniques can be used within a methodological framework. This initially seems highly promising, unfortunately, current implementations of this theory are lacking when having to deal with the core problem of defining what?, how? and why? tools are most applicable. The implementation of Multiview in particular, suffers from a slight paradox; whilst the authors reject the idea of a ‘universal methodology’ their implementation does not offer sufficient flexibility in tool use or guidance on customisation for the inexperienced practitioner to make it truly contingent; whilst their promotion of the methodology is of a robust ‘one-size-fits-alT nature. The third set of theories promoted a toobox of techniques - without a methodological structure. This too was interesting, in that taxonomical classifications were developed; but lacked any strong rationale for the lack of guidance on suitability.
The interesting observation on the three is how closely their approaches represent their philosophical backgrounds. Davis’ (1982) theory is strongly rationalistic; the belief is that a distinct methodology will match a problem area. livari’s theory (and Avison & Wood-Harper’s (1990) implementation) illustrates influences from the systems, and particularly the socio-technical systems, tradition, where the nature of a methodology is contingent on the choice of strategies or social or technical options. Finally, the theories
of Benyon & Skidmore (1987) and Kensing & Munk-Madsen (1993) show the influence of craft-based approaches to systems development, where the emphasis is entirely on process rather than product-based development; i.e., a methodological approach to development is entirely rejected.
Figure 3.4 illustrates the scope and ambition of each of the three approaches. While option 2 is certainly the most ambitious o f the three approaches, by concentrating on one methodology, it fails to answer the central question o f this research.
Davis (1983) livari (1989) Benyon & Skidmore (1987) Organisation Methodology Organisation Methodology Organisation Methodology
Situation Situation Situation
Figure 3.4: Comparison of Theory
What all three approaches do provide is to give criteria by which we can use as a starting point in building a framework to identify the determinants o f methodology customisation. Table 3.3 illustrates the criteria that each suggest". This research starts with this list o f criteria - and others that are developed later on in this chapter. Given that the aim is to build a conceptual framework illustrating dependencies, then each of these criteria needs to be explored, through existing and empirical research carried out during this research to assess their suitability.
There are a number o f overlaps between the sets o f criteria suggested in Table 3.3, as would be expected - it can be argued that each approach is fundamentally interlinked (a factor illustrated with the vertical two-way arrows). The second part o f this chapter tries to do two important tasks:
" W hich seem to h av e b een d ev elo p e d b ased on o b serv atio n s o f th e ind u stry rath er th an em p irical research.
• expand on some of the criteria, particularly where there are existing models that try to build a theory illustrating the working of these determinants;
• add new criteria; from deterministic models that originate in compatible disciplines.