Your SlideShare is downloading. ×
IED Classification   Avison & Taylor
IED Classification   Avison & Taylor
IED Classification   Avison & Taylor
IED Classification   Avison & Taylor
IED Classification   Avison & Taylor
IED Classification   Avison & Taylor
IED Classification   Avison & Taylor
IED Classification   Avison & Taylor
IED Classification   Avison & Taylor
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

IED Classification Avison & Taylor

1,812

Published on

IED Classification Avison & Taylor

IED Classification Avison & Taylor

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,812
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Journal of Information Technology (1997) 12, 73± 81 Information systems development methodologies: a classi® cation according to problem situation D.E. AVISON School of Management, Southampton University, Southampton SO17 1BJ, UK V. T AYLOR Ordnance Survey, RomseyRoad, Southampton SO16 4GU, UK Information systems development methodologies are frequently classi® ed according to themes or features. Yet potential users are more concerned with the situations in which different approaches are appropriate. In this paper, ® ve problem situation types are identi® ed: (1) well-structured problem situations with a well- de® ned problem and clear requirements, (2) well-structured problem situations with clear objectives but uncertain user requirements, (3) unstructured problem situations with unclear objectives, (4) situations where there is a high user interaction with the system and (5) complex problem situations. Typical information systems development methodologies are placed in each of these groups. Some strengths and weaknesses of this classi® cation are discussed. One conclusion is that most projects will fall within the category of complex problem situations, for organizations (and therefore their information systems needs) are invariably complex in terms of the human and social aspects at least as much as any technological ones. The Multiview approach is discussed in more detail because the authors claim it is suitable for such situations. Introduction traditional, general systems, human activity systems, participative, structural and data. Avison and Fitzgerald Avison and Fitzgerald (1995) de® ned an information (1988) suggested that it is unrealistic to include general systems development methodology as `a system of systems theory as an approach (although it has been procedures, techniques, tools and documentation aids, in¯ uential), but added planning and prototyping to the usually based on some philosophical view, which help list of themes. Maddison (1983), Fitzgerald et al. (1985) the system developers in their efforts to implement and Olle et al. (1991) classi® ed information systems a new information system’ (abridged from p. 10). development approaches according to their features, Many different development methodologies exist and including the stages of the life cycle that they encom- Bubenko (1986) suggested that there are hundreds. pass, deliverables and the techniques used. Nevertheless, Structural Systems Analysis and Design For most practical purposes, however, the problem Methodology (SSADM) (now version 4) has been for practitioners is about which methodology or combi- selected as the mandatory methodology for UK nation of methodologies to use in particular problem Government projects since 1981 (Ashworth and situations. The classi® cations mentioned above do Goodland, 1990). Despite the many methodologies not help much in these decisions. An attempt is existing, on the one hand and the SSADM `UK stan- made in this paper to classify information systems dard’ , on the other, many information systems are development approaches according to the characteris- developed without the use of a standard information tics of the problem situations to which they are most systems development methodology. This is due in part applicable. to the inappropriateness of some methodologies in some situations so that, even in one organization, a `standard’ approach may not be used in all situations. Classifying information systems The ® rst purpose of this paper is to identify types of development methodologies situation and to match these types of situation with information systems development approaches. In this section, a classi® cation for information systems The conventional way of classifying information development methodologies is suggested. Four classes systems development approaches is according to theme are suggested to re¯ ect four different types of problem or by way of a feature analysis. Thus, Wood-Harper situation. However, a ® fth class is later proposed which and Fitzgerald (1982) described six main themes: re¯ ects `complex problem situations’ .
  • 2. 74 Avison and Taylor The classi® cation divides the methodologies into Class 1: methodologies applicable to well- four main types for four different problem situations de® ned, well-structured problem situations with as follows. clear objectives (1) Class 1. Well-structured problem situations Tradition information systems development method- with a well-de® ned problem and clear require- ologies, often described as `hard’ approaches, attempt ments. The appropriate methodologies for these to ® nd the `best’ solution for a clearly de® ned problem. situations include methodologies based on the The earliest computer system development method- traditional systems development life cycle ologies fall into this category. The traditional system (SDLC), frequently referred to as the waterfall development life cycle approach, for example that of model. the National Computing Centre in the UK (Daniels (2) Class 2. Well-structured problem situations with and Yeates, 1971), is typical of these approaches and clear objectives but uncertain user requirements. has the following steps: feasibility study, systems inves- Methodologies such as those based on data tigation, systems analysis, systems design, implemen- modelling, process modelling or prototyping are tation and review and maintenance. likely to be appropriate in these situations. Such approaches have proved useful for well- (3) Class 3. Unstructured problem situations with structured problem situations with clear objectives. unclear objectives. Soft systems approaches, in Typically this has involved `computerizing’ manual which the perspectives of those involved are systems or `recomputerizing’ operational computer stressed, are likely to be appropriate in these applications where radical changes are not desired. The situations. approach tends to be limited to routine operational (4) Class 4. Situations where there is a high user problem situations and is much less suitable for sup- interaction with the system. These situations porting management decision making. The approach require approaches that stress the needs of the models processes and is therefore applicable only to people who will interact with the system. situations where these processes are fairly stable. Such Sociotechnical approaches will be most appro- systems tend to be developed by data-processing people priate in these situations. in larger organizations or consultants, perhaps using `off the shelf’ packages on microcomputers, in smaller We will look at each of these classes in more detail organizations or departments within larger organiza- in this paper, along with a brief description of those tions. The requirements need to be well known and approaches appropriate to each situation. Of course, understood and easily communicated. Users are only as with any classi® cation, some methodologies cannot given a limited say in the decision making and analysts be neatly ® tted into one of the classes given above. are not expected to question why a system should be For example, prototyping has been included as suit- developed or its objectives as the new computer system able for the class of problems with clear objectives but is expected to re¯ ect the status quo. uncertain requirements. This is the right classi® cation for prototyping in its purist form. However, it has also been argued that prototyping could be used during Class 2: methodologies applicable to well- certain stages of the traditional SDLC (Dearnley and structured problem situations with clear Mayhew, 1983). It may also be a useful tool to use objectives but uncertain user requirements alongside participative methodologies. Many problem situations will have characteristics of This class of approaches attempts to resolve some of two or more of the classes above and will therefore the limitations of the traditional approach and therefore require parts of several methodologies to be used. As is more appropriate to many of the problem situations this is often the case in systems development, some found today. There are also `hard’ approaches, in that authors have suggested a contingency approach where stress is placed on the technical aspects of information a framework for choosing the methodologies and/or systems, but no assumption is made that the require- tools and techniques is suggested. For this reason we ments are straightforward and easy to communicate add a ® fth class of methodologies of information to system developers. This opens up the possibility of systems development to be used in situations as more ambitious computer applications than those follows. feasible using the approaches of class 1. The methodologies in this class may be divided into (5) Class 5. Complex problem situations, com- four groups. These are structured methodologies such bining two or more of classes 1± 4, requiring a as STRADIS ± Structured Analysis and Design of contingency approach to information systems Information Systems (Gane and Sarson, 1979) and development. YSM (Yourdon, 1989), data analysis methodologies,
  • 3. Information system development methodologies 75 such as information engineering (Martin, 1989) or the Some methodologies that fall into this general approach found in Avison (1992), blends of the two category, such as SSADM and MerISE, are a mixture of such as MerISE (Quang and Chartier-Kastler, 1991) structured and data analysis approaches. This would and SSADM (Ashworth and Goodland, 1990) and, seem to be a natural progression as systems developers ® nally, prototyping (for example, Martin, 1991). see the need for both process and data modelling and Dearnley and Mayhew (1983) discussed prototyping also see the usefulness of the techniques of both as part of the SDLC and Schoval and Pliskin (1988) approaches, such as data-¯ ow diagrams and entity- described prototyping in the context of structured relationship diagrams, respectively. Many information methodologies. systems development methodologies started as `pure’ Structured methodologies stress the tasks that need data modelling or process modelling approaches, to be performed in order to achieve a given objective. but have developed to a more blended approach as They make use of diagrammatic techniques such as they `® lled the gaps’ noticed by systems developers data ¯ ow diagrams, decision tables and decision trees. and users alike. SSADM developed in this fashion, Along with structured walk-throughs, these techniques though its original emphasis is data oriented. It has help to improve the understanding of the requirements three views: logical data structures (entity-relationship by providing better communications with users and to diagrams), data-¯ ow diagrams and entity life histories, verify the analysts’ understanding of the needs of the which show how entities change over time (and to some users. Yourdon (1988) suggested that a well-structured extent combine a data and process diagram in one). approach to documenting someone’ s thoughts about a MerISE, on the other hand, set out as a combination of problem or a situation can aid both that person’ s the data-oriented and process-oriented approaches and thinking and his or her ability to convey this under- the separate treatment of data and processes is equally standing to others. Daniels and Yeates (1988) stated thorough and as the data view is modelled on three that the aims of structured analysis are to involve the stages from conceptual and logical through to physical, user more in the speci® cation of the problem and to so is the equivalent process-oriented view. However, carry out the analysis and to present the results in a although such blended approaches combine the advan- clearer and more formal way. Structured approaches tages of the two underlining themes, they do not address are suitable to the group of problem situations in class some basic situations, in particular, those where there is 2 where the processes that the system is to perform a high degree of con¯ ict. are fairly stable. The ® nal group of approaches relevant to situations Where the processes that the system is to perform are where requirements are unclear is prototyping. This is less stable, data analysis approaches may be more appro- a strategy for determining requirements wherein the priate. These approaches emphasize data modelling user needs are extracted, presented and developed by rather than process modelling. Their proponents argue building a working model of the ultimate system ± that even if the applications change, the fundamental quickly and within context (Boar, 1984). From rudi- building blocks of the data will still be appropriate. The mentary statements of requirements, a simple system main technique used is entity-relationship modelling may be built using such tools as CASE (Computer (Chen, 1976). The data model is useful as it gives a Assisted Systems Engineering), fourth generation framework from which to develop systems and results in systems and the like. Users can learn what is the poten- an understanding of the data attributes, the entities and tial of the system to be designed, the analysts can learn the relationships between the entities. A data modelling what are the users’ needs and management, users and methodology (Systems Documentation) aims to build a analysts together can become clearer about what are conceptual data model to determine and specify the the system requirements. This process of developing requirements of the information system. More rounded the prototype is usually made iteratively. Once all these data approaches are to be found in Avison (1992) and stakeholders are `happy’ with the system, the proto- Macdonald (1986). Although there are strong advocates type `becomes’ the operational system. Prototyping of the data approach, Benyon and Skidmore (1987) facilitates experimenting with the user, but not at pointed out that the emphasis on data and the rigour of the expense of the user (Avison and Wilson, 1991). its techniques can lead to the development of neat tech- However, a survey of developers and users by nical systems that ignore or contradict the political Mahmood (1987) suggested that improved communi- reality. In other words, in the context of this paper, they cation between the developers and Myers (1988), may be suitable for well-structured problem situations among many others, emphasized the use of prototyping with clear objectives but uncertain user requirements. for user interface design. This may suggest incorpo- However, where there is a high degree of con¯ ict, the rating prototyping into the SDLC or other approaches approach may be less suitable and the approaches found as an improved way of systems investigation, rather under classes 3, 4 and 5 may be more applicable. than viewing prototyping as a systems development
  • 4. 76 Avison and Taylor approach in its own right. Where the problem is well In such circumstances, technically viable systems can structured, the objectives and requirements fairly clear fail because of `people problems’ . ETHICS ± Effective and the environment stable, prototyping within the Technical and Human Implementation & Computer- SDLC can ensure that the exact requirements are based Systems (Mumford, 1995) is one methodology detailed and various design options tried. How- which encourages user involvement. If users are ever, `pure’ prototyping is a useful methodology when involved in the decision making related to the new user requirements are unclear, the project is small project, then they are more likely to be committed to and conventional systems development is likely to take it. As Land and Hirschheim (1983) argued, although too long. information systems are usually seen as technical systems which have behavioural and social conse- quences, they are really social systems which rely to Class 3: methodologies applicable to an increasing extent on information technology. unstructured problem situations where the Through participation, (1) the interests of the indi- objectives are unclear viduals using the system are protected, (2) individuals The two classes of situation discussed above call for can use the systems as a basis for the redesign of their `hard’ methodologies. In many situations where infor- jobs and working environment, (3) they are more likely mation systems are to be developed, the objectives of the to support the system, motivating them, leading to system may be unclear or may be clear to some individ- higher productivity and (4) the various skills and uals or groups but con¯ ict with the objectives of others. knowledge of people to be incorporated into the system In such situations `soft’ approaches are more appro- is enabled. priate as they do not assume an agreed objective nor that ETHICS is based on the sociotechnical view that, an `optimal’ solution may be found. The most well to be effective, information systems must ® t closely known is Checkland’ s soft systems methodology (SSM) with both the social and technical factors. The (Checkland and Scholes, 1990) which is expressed in an approach concentrates on providing tools for partici- information systems context in Wilson (1990). In many pative analysis and objective setting, leaving the more managerial situations, the questions `what are the objec- technical work of design to computer professionals (the tives?’ and `what are we trying to achieve?’ are part of the `facilitators’ ). Alternative participative approaches problem. Checkland recognized that human activity include sociotechnical systems (STS) (Paddock, 1986) systems only exist in the minds of individuals and there- and information systems work and analysis of change fore the perspective (Weltanschauung) of a particular (ISAC) (Lundeberg, 1982). individual will affect his or her view of the problem Participative approaches may not work in situations situation and system objectives. where people do not wish to participate or in coercive Through the development of a rich picture, possibly situations where the objectives of the system include expressed in a rich-picture diagram (Avison et al., the reduction of costs and redundancies (Mumford, 1992), an attempt is made to model all the aspects of the 1995). The ease with which participation may be problem situation including issues, problems, con¯ icts accomplished will be dependent on the culture and and so on. Such a process will not resolve the con¯ ict, politics of the organization as well as the individuals but aims to identify it. When formulating the root de® - themselves (see also Avison and Myers, 1995). It will nition, which is used to identify problems and systems be more dif® cult to obtain true participation between and building conceptual models, which show the different users at different levels of a bureaucratic hier- minimum activities required by the system described by archical organization where people are very conscious the root de® nition, we can compare the real world and of their position or grade and power than more organic this systems world, identifying feasible and desirable organizations where these are much less explicit. changes and suggesting potential action to improve However, many organizations are attempting to move the problem situation. The analysis and subsequent away from bureaucratic structures so as to make them understanding of the problem situation leads to this more ¯ exible and, therefore, participative approaches improvement. In the context of this paper, such action may become more widespread. could be the development of information systems. Problems with single situation approaches Class 4: methodologies applicable to situations where there is a high user interaction with the Many authors have suggested, as we do in this paper, system and/or user acceptance is important that there is no best methodology for all situations Many potential information systems will involve many (Jackson and Keys, 1984; Avison and Wood-Harper, users who will be greatly affected by the new system. 1991). It would seem dif® cult, if not impossible, for
  • 5. Information system development methodologies 77 example, to design an appropriate system using a `hard’ Q1– How is the information System uman-Activity approach when the problem is ill-de® ned or use a 1 H orma supposed to futher the aims of the nf ti 2 I -Tec on organisation using it? participative approach in cohersive situations. Davis cio hnic So al Q2– How can it be fitted into the 3 u working lives of the people in the (1982) suggested that a methodology should be chosen -Comp ter organisation using it? n Int depending on the particular characteristics of the H uma Q3 – How can the individuals erf a c e 5 Technical systems development project. Episkopou and Wood- concearned best relate to the compu in terms of operating it and using the Harper (1986) also suggested that a suitable approach 4 output from it? should be determined by examining certain variables Q4 –What information processing in and around the problem situation. They devised a function is the system to perform? Q5 –What is the technical specificatio framework to select an approach based, in the main, of a system that will come close enou on assessing the characteristics of the problem solver to meeting the identified requirement and problem owner. The classi® cation of methodologies in this paper Figure 1 The Multiview1 framework could be used to help in the process of choosing a methodology. However, there are problems associated with using certain characteristics of the problem to choose an appropriate methodology. For example, Skidmore, 1987). The latter approach lacks a guiding many problem situations and information systems framework, documentation and other standards. development projects are multifaceted, suggesting Although it could be argued that very skilled analysts that methodologies in more than one class would be may successfully employ such an approach, this is appropriate. Furthermore projects take on different normally not appropriate because of a fear that such characteristics as they progress. A project may be ill- skilled staff would be dif® cult to control, a lack of such structured at the outset, demanding softer techniques, skilled staff being available and dif® culties concerning but a well-structured objective set and requirements contracts and compliance with quality standards. The de® nition may result, at which time harder techniques method engineering movement (see, for example, will be appropriate. One view, therefore, is that Brinkkemper et al., 1996), which does suggest using different methodologies are complementary. However, techniques, such as entity-relationship modelling and analysts may not know a number of methodologies tools, in particular CASE tools, according to situation, suf® ciently well to choose and use the `appropriate’ might also be deemed inappropriate because of its ones as the situation merits. For this reason, a single largely technological viewpoint. Complex situations contingency approach may be the most useful in more are usually so because of the mix of human, social and complex situations. organizational complexity, as well as technical dif® culty. Avison and Wood-Harper (1986) described Multi- view as an exploration in information systems develop- Class 5: complex problem situations requiring a ment. Multiview provides a framework guiding analysts contingency approach to information systems in their choice of techniques and tools in any particular development problem situation and also recommends documentation Re¯ ecting on the classi® cation given, many readers and other standards, these being one of the main forces might argue that most information systems develop- for using an information systems development method- ment projects will fall within class 5. Of course this may ology in the ® rst place. There are many situations in re¯ ect the bias of the author or the roughness of the which Multiview has been used successfully. classi® cation itself. There certainly needs to be further Multiview (Avison and Wood-Harper, 1990, 1991) work on the classi® cations of problem situations rather is a ¯ exible framework where the techniques and tools than the methodology themes or features. But, as Avison are chosen according to the particular problem situa- et al. (1988, p. 379) argued `Every situation is different tion and the stage in the development of the infor- and the analyst should have the opportunity to explore mation system. In the original de® nition, it has ® ve and create a unique method for each situation.’ We will phases (see Figure 1): (1) analysis of the human activity therefore discuss Multiview, which provides a frame- system, (2) analysis of the information (entities and work for developing information systems. It has been functions), (3) analysis and design of the sociotech- designed for such complex problem situations. nical system, (4) design of the human± computer inter- A contingency approach, such as Multiview, is face and (5) design of the technical aspects. more appropriate than one where analysts choose a The approach is described in full in Avison and methodology from the number available (Davis, 1982), Wood-Harper (1990), but suf® ce it to say in the for reasons given above, or one where analysts choose context of this paper that stage 1 is heavily in¯ uenced tools and techniques from a `tool box’ (Benyon and by the work of Checkland (class 3 above), stage 2 by
  • 6. 78 Avison and Taylor the methodologies described in class 2 of this paper, stage 3 by Mumford, described in their latest versions in Checkland and Scholes (1990) and Mumford Organisational Information anallysis analysis & (1995), (class 4 above) and stage 5 by those items modelling outlined in classes 1 and 2 above. The authors argue that to be complete in human as Information well as in technical terms, the methodology must systems provide help in answering the following questions. development (1) How is the computer system supposed to further the aims of the organization installing it? Socio-technical Technical design (2) How can it be ® tted into the working lives of analysis & design and construction the people in the organization that are going to use it? (3) How can the individuals concerned best relate Figure 2 The Multiview framework (version 2) to the machine in terms of operating it and using the output from it? (4) What information system processing function is Would-be the system to perform? History developers (5) What is the technical speci® cation of a system of an IS that will come close enough to doing the things Perceived Analyst that have been written down in the answers to world the other four questions? Issues, needs and expectation s These questions would seem to cover complex situ- CULTURE ations. Whereas a strategic approach (for example, Organisational Information Situation Business Systems Planning) might address question 1, anallysis modelling participative approaches, such as ETHICS (Mumford, Analysis of : Methodology 1995), might address questions 2 and 3, a prototyping 1. Interventio n 2. Social context approach, such as rapid applications development 3. Political aspects Socio-technical Technical design (Martin, 1991) might address questions 3 and 4 and analysis & design and construction the conventional and structured approaches, such as SSADM (Ashworth and Goodland, 1990) address questions 4 and 5, Multiview attempts to address all Reflecting and these questions and to involve all the role players or modifying stakeholders in answering these questions. (method must be systemically desirable Although we have stated that phases might be omit- and culturally feasible) Contingent socially- ted or reduced in scope or executed in a different constructed ISD method sequence, the description of Multiview is in terms of the `layers in an onion’ (as in Figure 1) or as a series of ® ve STREAM OF CULTURAL LOGIC-BASED ANALYSIS STREAM OF ANALYSIS broad steps. However, this is described as an `ideal type’ which will guide the analyst who will redesign it for any Figure 3 Constructing the information systems develop- practical situation. Although Avison and Wood-Harper ment methodology (adapted from Checkland and Scholes, (1990) argued that `the waterfall model is inappropri- 1990, Wood-Harper and Avison, 1990, and Avison and ate’ (p. 265), the earlier description in the book gives Wood-Harper, 1995) the impression of a waterfall model, despite further denials from the methodology authors using Multiview in practice. This led to dif® culties where, for example, antithesis of the waterfall model and explicit in address- users required further explanation on how to go from ing class 5 problem situations. stage 1 (essentially a description of the problem situa- tion using SSM rich pictures, root de® nitions and con- ceptual models) to stage 2 (a combination of the data The development of Multiview modelling used in information engineering and the process modelling used in STRADIS). A further re® n- In Multiview2 (Avison et al., in press), the ® ve stages ing of Multiview has led to another de® nition and this have been reduced to a four-box structure of organi- is described in the next section. It is more explicitly an zational analysis, information analysis and modelling,
  • 7. Information system development methodologies 79 sociotechnical analysis and design, and technical design place on each of the major aspects shown in Figure 2 and construction. This proposed new framework for and when to give them particular emphasis. There is Multiview is given in Figure 2 and it shows the four a major learning process for the analyst in having to parts of the methodology mediated through the actual choose between techniques and tools. There are also process of information systems development. The four problems of quality, control and planning when using parts of human activity systems analysis or organiza- a contingency approach. tional analysis (which examines organizational behav- Nevertheless, Multiview may be considered for use iours), sociotechnical systems analysis and design in complex unstructured information system develop- (which examines work systems) and technical design ment projects involving many users as, in such cases, and construction (which examines technical artefacts) the investigation needs soft analysis. Hard structured are integrated through the information analysis and techniques, such as process and data modelling, will modelling stage which acts as a bridge between the also be required. Furthermore, the balance between other three, communicating and enacting the outcomes the social and technical designs in Multiview is likely in terms of each other. In this way Multiview offers to give the correct emphasis in such projects. an exploratory though perhaps not systematic guide to any information systems development intervention, together with a re¯ exive, learning methodological Conclusions process. The emphasis placed on each of the four parts of Multiview will change as the information system is Systems analysts need to identify the basic character- being developed and is contingent on the particular istics of the environment in which they are to develop situation. an information system and choose a methodology or There are also differences in the details between the contingency approach for the development of that two versions of Multiview which re¯ ect published particular system. To facilitate this process, ® ve research over the intervening years and, more impor- problem situation types have been identi® ed: (1) well- tantly, experience in using Multiview during this structured problem situations with a well-de® ned period. Thus, for example, (1) stakeholder analysis problem and clear requirements, (2) well-structured strengthens the conceptual analysis of SSM and ethical problem situations with clear objectives but uncertain analysis in organizational analysis, (2) there is a migra- user requirements, (3) unstructured problem situations tion from structured methods to object-oriented with unclear objectives, (4) situations where there is a analysis in formation analysis and modelling, (3) ethno- high user interaction with the system and (5) complex graphic approaches supplement the tenets of ETHICS problem situations, combining two or more of classes in sociotechnical systems analysis and design and (4) 1± 4. prototyping, CASE, evolutionary and rapid develop- Many if not most situations in organizations are ment approaches are more strongly suggested in tech- likely to be closer to the class 5 complex problem situ- nical design and construction. ations than the others and a rede® nition of Multiview However, although the authors recommend a contin- is proposed as being particularly appropriate for such gent approach to information systems development, situations because of its broad scope and contingency Multiview2 should not be used to justify random or `philosophy’ . uncontrolled development. The terms `methodology’ This attempt at a classi® cation is rudimentary at and `method’ tend to be used interchangeably, present. Some methodologies or problem situations although they can be distinguished insofar as a method may ® t into more than one category of the classi® ca- is a concrete procedure for getting something done tion; only a limited number of problem situation char- while a methodology is a higher-level construct which acteristics have been included and many features of provides a rationale for choosing between different problem situations that may be important to the methods (Oliga, 1988). In this sense, an information methodology choice have not been included in the clas- systems methodology, such as Multiview2, provides a si® cation. One major omission, for example, is the basis for constructing a situation-speci® c method culture of the organization and this may greatly in¯ u- (Figure 3), which arises from a genuine engagement ence the effectiveness of an approach in a particular of the analyst with the problem situation (Wastell, situation. People have different cognitive styles and as 1996). a result may work more effectively with some method- This paper should not be interpreted as suggesting ologies than others. Other characteristics of the that a contingency approach such as Multiview is the problem situation, such as the development time scale answer to all problem situations. In any case, and constraints on the way development can take place, Multiview is not a simple approach for a complex situ- may also be important factors in in¯ uencing the ation. The analyst has to decide on the emphasis to methodology choice.
  • 8. 80 Avison and Taylor We are therefore aware of the dangers of being tion Systems Development, 2nd edn (McGraw-Hill, simplistic, both in our judgements of the different types Maidenhead). of problem situation and the appropriate methodolo- Benyon, D. and Skidmore, S. (1987) Towards a tool-kit for gies for each type, but we believe that further research the systems analyst. Computer Journal, 30, 2± 7. Boar, B.H. (1984) Application Prototyping: A Requirements into different situation types and the appropriateness De® nition Strategy for the 80’ s (Wiley, New York). of approaches for each of these types is particularly Brinkkemper, S., Lyytinen, K. and Welke, R.J. (eds) (1996) relevant to the real situation confronted by systems Method Engineering: Principles of Method Construction and analysts and groups of users as they search for an Tool Support (Chapman & Hall, London). appropriate approach for their particular problem Bubenko, J.A., Jr, (1986) Information system methodologies ± situation. a research view, in Information Systems Design Metho- dologies: Improving the Practice, Olle, T.W., Sol, H.G. and Verrijn-Stuart, A.A. (eds) (North Holland, Amsterdam). Acknowledgements Checkland, P.B. and Scholes, J. (1990) Soft Systems Methodology in Action (John Wiley, Chichester). I wish to thank Richard Vidgen, Bob Wood and in Chen, P.P.S. (1976) The entity-relationship model ± toward a uni® ed view of data. ACM Transactions on Database particular Trevor Wood-Harper who are working with Systems, 1, 1. me on a new de® nition of Multiview. Daniels, A. and Yeates, D.A. (1971) Basic Training in Systems Analysis, 2nd edn (Pitman, London). Daniels, A. and Yeates, D.A. (1988) Basic Systems Analysis References (Pitman, London). Davis, G.B. (1982) Strategies for information requirements Ashworth, C. and Goodland, M. (1990) SSADM: A Practical determination. IBM Systems Journal, 21, 4± 30. Approach (McGraw Hill, Maidenhead). Dearnley, P.A. and Mayhew, P.J. (1983) In favour of system Avison, D.E. (1992) Information Systems Development: A prototypes and their integration into the systems devel- Database Approach, 2nd edn (McGraw-Hill, Maiden- opment cycle. Computer Journal, 26, 36± 42. head). Episkopou, D.M. and Wood-Harper, A.T. (1986) Towards Avison, D.E. and Fitzgerald, G. (1988) Information systems a framework to choose appropriate IS approaches. development: current themes and future directions. Computer Journal, 29, 222± 228. Information and Software Technology, 30, 458± 466. Fitzgerald, G., Stokes, N. and Wood, J.R.G. (1985) Feature Avison, D.E. and Fitzgerald, G. (1995) Information Systems analysis of contemporary information systems method- Development: Methodologies, Techniques and Tools, 2nd ologies. Computer Journal, 28, 223± 230. edn (McGraw-Hill, Maidenhead). Gane, C.P. and Sarson, T. (1979) Structured Systems Avison, D.E. and Myers, M. (1995) Information systems Analysis: Tools and Techniques (Prentice-Hall, Englewood and anthropology: an anthropological perspective on IT Cliffs, NJ). and organizational culture. Information Technology & IBM (1975) Business systems planning, in Advanged Systems People, 8, 43± 56. Development/Feasibility Techniques, Cougar, J.D., Cotter, Avison, D.E. and Wilson, D. (1991) Controls for effective M.A. and Knapp, R.W. (eds) (Wiley, New York) prototyping. Journal of Management Systems, SA± 58, pp. 236± 314. 41± 53. Jackson, M.C. and Keys, P. (1984) Towards a system of sys- Avison, D.E. and Wood-Harper, A.T. (1990) Multiview: An tems methodologies. Journal of Operations Research, 35, Exploration in Information Systems Development (McGraw- 473± 486. Hill, Maidenhead). Land, F.F. and Hirschheim, R. (1983) Participative systems Avison, D.E. and Wood-Harper, A.T. (1991) Information design: rationale, tools and techniques. Journal of Applied systems development research: an exploration of ideas Systems Analysis, 10, 91± 107. in practice. Computer Journal, 34, 98± 112. Lundeberg, M. (1982) The ISAC approach to speci® cation Avison, D.E. and Wood-Harper, A.T. (1995) Experience of in information systems and its application to the orga- using Multiview: some re¯ ections, in Information Systems nization of an IFIP working conference, in Information Provision: The Contribution of Soft Systems Methodology, Systems Design Methodologies: A Comparative Review, Stowell, F.A. (ed.) (McGraw-Hill, Maidenhead) pp. Olle, T.W. Sol, H.G. and Verrijn-Stuart, A.A. (eds) 102± 117. (North Holland, Amsterdam) pp.173± 234. Avison, D.E., Fitzgerald, G. and Wood-Harper, A.T. (1988) Macdonald, I.G. (1986) Information Engineering, in Information systems development: a tool-kit is not Information Systems Design Methodologies: A Comparative enough. Computer Journal, 31, 458± 466. Review, Olle, T.W., Sol, H.G. and Verrijn-Stuart, A.A. Avison, D.E., Golder, P.A. and Shah, H.U. (1992) An SSM (eds) (North Holland, Amsterdam). toolkit: rich picture diagramming. European Journal of Maddison, R.N. (ed.) (1983) Information System Information Systems, 1, 397± 407. Methodologies (Wiley, Heyden). Avison, D.E., Wood-Harper, A.T., Vidgen, R.T. and Wood, Mahmood, M.A. (1987) Systems development methods ± a J.R.G. (in press) Multiview: An Exploration in Informa- comparative investigation. MIS Quarterly, 11, 293± 311.
  • 9. Information system development methodologies 81 Martin, J. (1989) Information Engineering: A Trilogy (Prentice- Biographical notes Hall, Englewood Cliffs, NJ). Martin, J. (1991) Rapid Application Development (Prentice- David Avison is Professor of Information Systems and Hall, Englewood Cliffs, NJ). Head of the Department of Management at Mumford, E. (1995) Effective Requirements Analysis and Southampton University. He also has considerable Systems Design: The ETHICS Method (Macmillan, experience in information systems practice. He is Basingstoke). Myers, B.A. (1988) Creating User Interfaces by Demonstration President of the UK Academy of Information Systems (Academic Press, New York). and Vice-chair of the International Federation of Oliga, J. (1988) Methodological foundations of systems Information Processing (IFIP) working group 8.2. methodologies, in Critical Systems Thinking: Directed David is joint editor of the McGraw-Hill series of texts Readings, Flood, R.L. and Jackson, M.C. (eds) (Wiley, in information systems and is also joint editor of Chichester). Blackwell Scienti® c’ s Information Systems Journal now Olle, T.W., Sol, H.G. and Verijn-Stuart, A.A. (eds) (1982) in its seventh volume. He has published 16 books (plus Information Systems Design Methodologies: A Comparative one translation from the French) as well as a large Review (North Holland, Amsterdam). number of papers in learned journals, edited texts and Paddock, C.E. (1986) A critical view of factors affecting conference papers. He has given the plenary addresses successful application of normative socio-technical systems development approaches. Information and at recent information systems conferences in The Management, 10, 49± 57. Netherlands, Australia, Bahrain, the UK and the Quang, P.T. and Chartier-Kastler, C. (1991) Merise in USA. His research areas include information systems Practice (Macmillan, Basingstoke) (translated by D.E. development and he is one of the co-authors of the and M.A. Avison (1989) from the French Merise Multiview methodology. Appliqu‚ e (Eyrolles, Paris). Schoval, P. and Pliskin, N. (1988) Structured prototyping: Vicky Taylor is Senior Policy Researcher at Ordnance integrating prototyping into structural systems develop- Survey, Southampton. She did her MSc in Management ment. Information and Management, 14, 19± 30. Science at the University of Southampton and is a Wastell, D. (1996) The fetish of technique: methodology as graduate member of the Institute of Personnel and a social defence. Information Systems Journal, 6, 1. Development. Her main research interests are now in Wilson, B. (1990) Systems: Concepts, Methodologies and Applications, 2nd edn (Wiley, Chichester) pp. 25± 40. the area of human resource policy and systems. Wilson, J. and Rosenberg, D. (1988) Rapid prototyping for user interface design, in Handbook of Human± Computer Address for correspondence: Department of Interaction, Helender, M. (ed.) (North Holland, Management, Southampton University, Southampton Amsterdam). SO17 1BJ, UK. Wood-Harper, A.T. and Fitzgerald, G. (1982) A taxonomy of current approaches to systems analysis. Computer Journal, 25, 12± 16. Yourdon, E. (1988) Managing the Systems Life Cycle (Prentice Hall, Englewood Cliffs, NJ). Yourdon, E. (1989) Modern Structured Analysis (Prentice Hall, Englewood Cliffs, NJ).

×