Beyond methodologies: keeping up with information systems development approaches through dynamic classification

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

Beyond Methodologies: Keeping up with Information Systems DevelopmentApproaches through Dynamic Classification

Juhani IivariDepartment of Information

Processing ScienceUniversity of Oulu

P.O. Box 333FIN-90570 Oulu, Finland

[email protected]

Rudy HirschheimCollege of Business

AdministrationUniversity of Houston

Houston, TX [email protected]

Heinz K. KleinSchool of Management

SUNY BinghamtonBinghamton, NY

[email protected]

Abstract

There are hundreds of information systems developmentmethodologies (ISDMs) which differ significantly fromeach other. Yet, the number of ISDMs that an organiza-tion can consider for adoption or adaptation must bequite small for practical reasons. In order to make oninformed choice for the selection of preferred ISDMs ahierarchical classification is needed that separates fun-damental or “essential” features from “accidental” de-tails. The principal purpose of this paper is to proposesuch a classification that would allow academics andpractitioners alike keeping up with continuing growth ofthe “methodology jungle”. According to this structure,an ISDM is merely an instantiation of one or more in-formation systems development approach (ISDA). ISDAscomprise the essential features, which are then inheritedby the ISDMs belonging to that class. One importantimplication of organizing the field of ISDMs into a com-prehensible number of ISDAs, is to shift the discussionfrom individual ISDMs to the features of more generalISDAs, as expressions of the essences of their instancemethodologies. The condensed presentations of ISDAsmake it possible to broaden the methodological reper-toire of systems developers. They allow flexible, situa-tion-specific “methodology engineering” in which anISDM is adapted to a specific ISD project through aninstantiation of an appropriate ISDA.

1. Introduction

Even though a universally accepted, rigorous and concisedefinition of an information systems development meth-odology (ISDM) is lacking, the core idea is clear: a sys-tematic procedure for completing either a system or one ofseveral major stages of the systems development life cycle.An ISDM consists of goals, principles, specific methodsand tools, which are selected on the basis of an underlyingrationale or systems development philosophy (cf. [37] foran introduction to related terms). The number of different

0-7695-0001-3/99 $1

ISDMs is truly remarkable. Jayaratna [21] estimates thatthere are over a 1000 ISDMs. This proliferation can beexpected to continue ([10], [19]).

Given the effort directed to the development of ISDMsone would expect a lively discussion on how to selectmethodologies in practice either for direct application oradaptation (“reengineering”) and on how to cataloguethem as a prerequisite to study the merits of various fea-tures and identify the most useful ones. However, neitherseems the case – even though feature analyses were startedas early as in the 1970’s (cf. [35], [36]) and later show-cased in one of the CRIS conferences ([27]-[29]). Basi-cally, their level was too detailed in two respects. Firstly,ISDMs seem to represent a too detailed level of granular-ity for a meaningful comparison (see section 2.1). Sec-ondly, clearly not all features are equally central to anISDM and this suggests focusing on a few fundamentals.One wonders how an informed choice can be made for theinitial selection of the preferred ISDMs without a good,hierarchical classification that separates fundamental or“essential” features from related details.

The principal purpose of this paper is to propose such aclassification that would allow academics and practitio-ners alike to keep up with the continuing growth of the“methodology jungle”. Our proposal is based on distin-guishing “essential” from “accidental” features – meta-phorically applying Brooks’ [4] distinction between ‘es-sences’ and ‘accidents’ of software products. It is hy-pothesized that the number of “essential” features bywhich ISDMs can differ is relatively small. As was notedin [11], a complete ISDM necessarily includes severalaccidental features. While these are important for com-pleteness, in practical application, they do not define itsessence. Hence the choice between fundamentallydifferent, i.e. “contrasting” ISDMs can be based on a moreparsimonious catalogue of features.

The organization of the paper is as follows. Section 2summarizes the basic ideas upon which the arguments ofthis paper build. Of critical importance in this section isthe distinction between information systems development

0.00 (c) 1999 IEEE 1

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

approaches (ISDAs) and ISDMs. Section 2 illustrates thisdistinction with a framework that provides a conceptualroof for the spectrum of currently known approaches. Theclassification introduced in section 2 is, however, “static”and would therefore become quickly obsolete. Hencesection 3 proposes a procedure on how to insert a newISDM in the classification structure. Section 4 offers twoexamples of how to use the procedure. Section 5 reflectsupon the implications of the ideas proposed in this paper.

2. Literature review and background

2.1 The need for ISDM classification

The proliferation of ISDMs has led to the need to analyze,compare and reflect upon alternative ISDMs [34]. At leasttwo principal lines of research can be distinguished in theprevious work on ISDM comparisons. One has mainlyfocused on a so-called ‘feature analysis’ (e.g. [35]; [7];[9]; [23], [27]; [8]). Another, more recent research ap-proach, uses formal meta-modeling (e.g. [14]; [31]). Thefeature analyses research stream has varied using a moreor less arbitrary set of features (e.g. [36], [3]; [24]) tomore theory-based frameworks (e.g. [35]; [22]) andreference models for an information system (e.g. [26];[16]) or the ISD process (e.g. [20]; [21]). One of the mostambitious attempts to systematically compare informationsystems and software development methods is offered by[34]. We shall refer to their work more explicitly below.

The key problem with this prior work is that most ofthe existing comparisons have taken place at the level ofspecific ISDM, because it focussed on whole methodolo-gies as the unit of analysis. In distinction to this, Fitz-gerald’s study [11] of how seasoned practitioners benefitfrom knowing an ISDM suggests that they “frame it at ahigher level of granularity”. He concludes “that the mul-tiplicity of manuals which accompany many methodolo-gies and prescribe in a very detailed fashion the exactmanner in which development should take place is notsuited to the actual needs of developers in practice.” (p.207) Based on other, more theoretical work there is rea-son to believe that this study has revealed a very typicalphenomenon of how experienced experts “recode” thedetails of specific ISDMs into larger “chunks” of knowl-edge. They are thereby able to remember relevant meth-odological principles and use them effectively. The mostfundamental implication of this insight is to shift the dis-cussion from alternative ISDMs and tools as a unit ofanalysis to a higher level of granularity, at which the IScommunity’s thinking can benefit from comparing andcontrasting features at the level of ISDAs rather thanISDMs.

To this end this paper proposes groupings of ISDMs,called “approaches” (ISDAs), as a more explicit and cen-tral concept to structure the field. It has been common to

0-7695-0001-3/99 $1

implicitly group ISDMs by their similarity into families orclusters. Examples of such groupings are the family ofstructured ISDMs and object-oriented (OO) analysis anddesign ISDMs. The tenet of the paper is that one shouldmove beyond strict ISDMs to focus on more generalISDAs (“A” as in “Approach”), which may comprise anumber of more specific ISDMs (M as in “Methodology”)as their instances. These general ISDAs may be conceivedof as prototypical classes that share a number of commonfeatures with their member ISDMs. The general ISDAsdefining the essences of their member ISDMs may beconceived of as templates which help to generate moredetailed ISDMs “on the fly”, possibly combining existing“ISDM fragments” [13]. The key issue then is how toidentify the most general features of ISDMs that can beused to group them into “approaches”. The benefits ofthis can be illustrated with some typical numbers. One canestimate that current ISDMs of the order 1000 can beclassified into a more comprehensible number (perhaps 20to 30) of ISDAs – a reduction of 30 to 50 times. In thisway, ISDAs provide condensed forms of knowledge rep-resentation for alternative ways of conducting systemsdevelopment. They can facilitate comparisons betweenISDAs by directly focussing on essential features ratherthan accidental ones.

2.2. A framework for ISDM classification

Initially, the proposed framework will have two levels: Atthe bottom are concrete ISDMs (as may be documented inmanuals or texts like [38]) that at the next higher level arerelated to approaches. As will become clear in sections 3and 4, more intermediate levels can be constructed asneeded to keep the classification up to date. An ISD ap-proach (ISDA) is interpreted as a class of specific ISDMssharing a set of related features. In defining the features,Song and Osterweil [34] were a source of inspiration, inparticular with their notion of ‘concept’ in their “typehierarchy”. They define a ‘concept’ as an idea that influ-ences the design of a software development method, anddistinguish concepts such as ‘problem’, ‘principle’,‘guideline’, ‘criterion’ and ‘measure’. In building on theseideas, we identified four features. They seemed to beidentifiable in all ISDMs that we studied (for illustrationsof these features see table 1). Therefore we took them tobe essential building blocks of ISDAs, because they driveinterpretations and actions in IS development. An ISDA’sgoal specifies its general purpose. Guiding principles andbeliefs form the common “philosophy” (cf. [1]) of theISDA. They help to ensure that the ISDM instances of aspecific approach form coherent wholes. Fundamentalconcepts largely define the nature of an IS implicit in theapproach, the focus and unit of analysis in ISD. Principlesof the ISD process express essential aspects of the ISDprocess in the ISDA.

0.00 (c) 1999 IEEE 2

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

Table 1, illustrates the features of an ISDA further. Incol. 1, “to provide maintainable software” is an exampleof a goal related to SA/SD [38]; “the design of moduleswith high cohesion and weak coupling”, one of its guidingprinciples. “Data flow” and “cohesion” are two of itsfundamental concepts; finally, “to apply a situation-dependent process model” is one of its principles of theISD process. The framework proposed by Song andOsterweil [34] helps to illustrate those definitions furtherby noting similarities and differences. They provideexamples such as to produce changeable programs(problem), achieve high cohesiveness (principle), find anoun to identify objects (guidelines), coupling andcohesiveness (measure). The examples suggest that theconcept ‘problem’ in [34] is close to the ISDA ‘goal’ inour framework. Their ‘principles’ are similar to our‘guiding principles and beliefs’. Their ‘guidelines’ are

Figure 1: Hierarchy of ISDMs and ISDAs

structured according to the actions in the software processand in that sense resemble our ‘principles of the ISDprocess’. However, they seem to be at a much moredetailed level. Our ‘fundamental concepts’ notion relatesto their concept of ‘artifact’ but also includes conceptsrelated to their ‘measures’. ‘Fundamental concepts’ alsocover major ‘design issues’ in the framework of Song andOsterweil (e.g. essential model vs. implementation modelin the case of SA/SD).

An ISDA may include zero, one, or more concreteISDMs as its instances. As an example of the first case (i.e.zero ISDM instances), consider the interactionist approach(cf. [19]), which to our knowledge has not been developed

SA/

SDIM

SA-

basedSSM

TU-

ist PWP DSS STD Infol. OO Inter-

action.

S

A

D

T

M

S

A

I

E

N

I

A

M

I

S

A

C

O

O

A

D

O

O

S

E

R

D

D

S

p

r

a

g

u

e

&

C

a

r

s

o

n

K

e

e

n

&

S

c

o

t

t

M

o

r

t

o

n

E

T

H

I

C

S

P

a

v

a

W

i

n

o

g

r

a

d

&

F

l

o

r

e

s

S

A

M

P

O

C

h

e

c

k

l

a

n

d

&

S

c

h

o

l

e

s

W

i

l

s

o

n

F

A

O

R

ISD approaches

Goals

Guiding principles

Fundamental concepts

Principles of the ISD

process

Detailed concepts

Notations

Techniques

Tools

Heuristics

ISD methodologies

0-7695-0001-3/99 $1

into any specific ISDM. On the other hand, the OOapproach comprises a number of ISDM instances. Ourclaim is that the concept of an ISDA makes it meaningfulto compare various approaches, which may be in quitedifferent stages of their development in terms of the num-ber of their ISDM.

This line of reasoning leads to a hierarchical structure -- our framework -- depicted in Figure 1. At the bottom, weidentify examples of specific ISDMs, which includedetailed concepts, notations, activities, and techniques,which may be accidental features (such as notations) oridiosyncratic to the specific ISDM (e.g. the concept ofqualifier in [32], among the OO methodologies). The topof Figure 1 describes eleven ISDAs. Table 1 summarizesfive of these eleven in more detail (see [18], for a moredetailed introduction). The framework includes an inheri-tance structure in which each ISDM inherits the features ofits ISDA (goals, guiding principles and beliefs, funda-mental concepts, and principles of the ISD process).1

Our interpretation of the five ISDAs is not necessarilyunambiguous. It would, of course, be preferable if the de-velopers of the ISDMs had themselves articulated the es-sences of the ISDA and ISDM they proposed. Because thiswas not the case, we were obliged to rely on our owninterpretation and judgement. One should also note thatone could have a more refined analysis, distinguishingsub-approaches within the main approaches listed in fig. 1.Perhaps this would have allowed for a more unambiguousinterpretation. However, this is beyond the scope of thispaper (see for example [15] and [30], for reviews ofdifferent semantic information/data models underlying theIM approach, and [25], and [12], for a review of the STDapproach).

Because the stock of approaches and methodologies iscontinuously changing, the proposed classification struc-ture would become irrelevant in a short time unless it caneasily be updated. The reason for this is that an ISDM mayrepresent a new type of ISDA that is not yet represented inthe classification structure. Hence the classification has tobe made “dynamic” in the following sense: An 'insertion'of a new ISDM may prompt a generalization of existingclasses. The main purpose of this paper is to propose aprocedure for doing this. The procedure will assure thatany new methodology M can be either be "assimilated" byassociating it with an existing class (approach) or"accommodated" by redefining the classification structurein such a way that M will fit.

3. A procedure for classifying ISDMs

1 Observe that inheritance in our context does not only concern ISDA’sattributes (goals, guiding principles and beliefs, fundamental conceptsand principles of the ISD process) but also their values (i.e. the specificpositions an approach takes with regard to the above attributes).

0.00 (c) 1999 IEEE 3

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

We do not claim that the following procedure will be acomputer algorithm even though it has been rendered inpseudo-code notation in section 3.2. In particular, humanjudgement is required for the analysis of a new approach'sor methodology's features, to state criteria for theselection of the candidate classes (cf. step 2 further below)

0-7695-0001-3/99 $10

and the resolution of other ambiguities. We shall return tothis issue at the end of this section.

Table 1. Summaries of the five IS development approaches

Structured Approach InformationModelling

SociotechnicalApproach

Object-Oriented Approach SSM Approach

Goal To provide an approachwhich helps to produce highquality (reliable and main-tainable) software in a pro-ductive way

To provide an ap-proach for enterprise-wide development ofinformation systems(databases) which en-ables coordinateddevelopment of inte-grated applicationsystems and theirlong-term evolution

To provide an ap-proach for ISD whichenables future users toplay a major part in thedesign of the system,to cater for jobsatisfaction objectivesin addition to moretechnical and opera-tional objectives, andto ensure that the newtechnical system issurrounded by a com-patible well-function-ing organizationalsystem

To provide an approach whichhelps to ensure that the prod-ucts are delivered to the useron time and within budget, thatthe products meet user re-quirements, that user requeststo modify the system and/of fixbugs are responded to in atimely fashion, that increas-ingly sophisticated productsare offered so as to keep acompetitive edge, that thechanges in standards and de-livery technology are kept upand the project team feelsmotivated and successful

To provide alearning method-ology to supportdebate on desir-able and feasiblechanges

GuidingPrinci-ples andBeliefs

Separation of the essentialmodel from the implementa-tion model; Careful docu-mentation to make the de-velopment process visible;Graphical notations; Top-down partitionable transfor-mation / process models tohide complexity; Unambigu-ous, minimally redundantgraphic specification; Bal-ancing of models; Designmodules with high cohesionand weak coupling

Data for a stable basisfor information sys-tems; Separation ofconceptual and inter-nal schemas; Theconceptual schemaforms the core modelfor an informationsystem; Applicationsare built on top of theconceptual schema; ISdevelopment shouldbe based on an engi-neering rigorousmethodology

Self-design of a worksystem; Minimal criti-cal specification;Open-ended designprocess; Fit betweenthe social and techni-cal subsystems; Jointoptimization; Redun-dant functions

Seamless analysis, design andimplementation; Encapsulation;Information (implementation)hiding

User of notionalsystem modulescalled ‘human ac-tivity systems’ toilluminate dif-ferent Weltan-schauungen whichmay be applied toany social system;An informationsystem is asystem to supportthe truly relevanthuman activitysystem

Fund-amentalcon-cepts

Essential model vs. imple-mentation model; Trans-formation; Data flow; Datastore; Terminator; Module;Cohesion; Coupling

Universe of Dis-course; Information/database; Conceptualschema; Externalschema; Entity; Rela-tionship; Attribute

Technical system;Social system; Vari-ance; Unit operation;Technical needs;Social needs (jobsatisfaction)

Problem domain vs. imple-mentation domain; Object andclass; Encap-sulation; Infor-mation hiding; Inheritance;Polymorphism; Com-munication between objects

Weltanschauung;Human ActivitySystems; Rootdefinition; Rele-vant system

Princi-ples ofthe ISDProcess

A step by step process at thedetailed level of analysis anddesign activities; Situationdependent at the ‘strategiclevel’ (waterfall orconcurrent prototyping)

Incremental concep-tual schema design;View integration

User participation;Sociotechnical design;Evolution

Iterative and incremental de-velopment; Reuse

Stream of culturalanalysis; Streamof logic-basedanalysis

3.1 An outline of the procedure

The basic idea of the following procedure is to identifythose ISDAs of which the new ISDM is an instance (case1) or which underlie the new ISDA or ISDM (case 2). Incase 2, an ISDM may represent a new ISDA that is not yetrepresented in the classification structure or the 'inser

tion'2 of a new ISDM may cause a generalization of exist-ing classes. We shall refer to following procedure as theINSERT(M) procedure. If a new methodology M has to beinserted in the classification the first case to check is

2 We refer to this procedure as an 'insertion' in that we are, as it were,'inserting' a particular ISDM into the framework.

.00 (c) 1999 IEEE 4

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

whether it fits under an existing class (case of assimila-tion). This judgment would be based on analyzing thecorrespondence of the features of the new M and the exist-ing classes. If that fails, then one needs to check if an ex-isting class can somehow be modified or generalized toassimilate M. This can be done by selecting probablecandidate classes and generalizing them by deleting ormodifying some of their features. Again the features of thegeneralized or modified class must correspond to the fea-tures of M.

If the checks so far do not succeed at accommodatingM (or the new approach), then a new class with multipleinheritance has to be formed (for details see pass 3, steps12-21 below). In this case the ISDM must be abstractedinto a separate approach (step 12). After that the procedurefollows the logic of the single hierarchy as describedabove. First, the procedure (steps 14-15) checks, whetherany of the existing candidate classes shares a strict subsetof the features that the new class abstracted from M. If itdoes, then the new class is inserted as its subclass. Nextthe procedure checks whether any of the candidate classescan be generalized (steps 16-18) or modified (steps 21) sothat the resultant class shares a strict subset of features ofthe new class formed from M. If so, the new class formedfrom M is inserted as its subset. This pass ends when allthe features of the ISDM (or the new class formed from it)are inherited in the resultant class structure (steps 15, 18and 21) or modified (steps 19-21) or the set of candidateclasses has been exhausted (step 13).

Two cases have to be distinguished. In case A selectingthe relevant features from the existing classes can form anew class. In this case the new class formed from M formsan 'intersection' approach which inherits all its featuresfrom its superclasses. It is unique, however, in the sensethat none of its superclasses includes all its features. CaseB is that the new M proposes some features that are notyet contained in any existing class. In this case the featureswill remain in the class formed from M.

3.2 Semi-formal specification

The following procedure INSERT(M) describes moreprecisely the classification process for the insertion of aspecific methodology M (or IDSA) in the existing classi-fication structure than the general outline presented insection 3.1.1. Insert M as an instance of the class ‘ISD methodolo-

gies’. Analyze the features F = F, i.e. goals, guidingprinciples, fundamental concepts and principles of theISD process underlying M.

0-7695-0001-3/99 $1

2. Consider whether there are candidate classes C = {C}for M.3 If ‘no’ form a class C’’ with M as its instance.4

Insert C’’ as an instance of the class ‘ISD approaches’and go to step 23.

M an instance of an existing class C3. Select a candidate class C ∈ C. If all candidate classes

analyzed, go to step 5.4. Analyze whether the features of C and those underlying

M are equivalent, i.e. F(C) = F(M). If ‘yes’ insert M aninstance of C, insert C as an instance of ISD ap-proaches (if not already done) and go step 24. If ‘no’go to step 3.

M an instance of a modified class C’5. Select a candidate class C ∈ C. If all candidate classes

analyzed, go to step 12.6 Consider whether C can be generalized to a class C’ so

that C’ includes a strict subset of immediate andinherited features of C (i.e. F’ = F(C’) ⊂ F(C)), andthat the features C’ are equivalent to features underly-ing M, i.e. F(C’) = F(M). If ‘no’, go step 9.

7. Form a class C’ with a subclass C. Associate the sub-set F’ of (immediate and inherited) features of C (F’ ⊂F(C)) to be generalized with C’. The features of C notto be generalized remain in C (i.e. F(C) = F(C) - F’).Insert C’ as a subclass of all the classes of which Cwas a subclass. Delete from the C’ those features thatit inherits from its superclasses. Insert M as an instanceof C’.

8. If C’ inherits features not-to-be-generalized (i.e. F ∈F(C)), search the class C* from which the feature wasinherited. Do CLEAN(C*,F). Repeat step 8 until no F∈ F(C) is inherited by C’. If any of the not-to-be-generalized features is inserted in C’, delete them. In-sert C’ as an instance of ISD approaches. Go to step22.

9. Consider whether a subset F* ⊆ F(C) of the immedi-ate and inherited features of C can be modified to fea-tures F’ = {F’} so that C and C’’’, in which C includesto-be -modified features F* and C’’’ includes themodified features F’, are subclasses of C’, and thefeatures of C’’’ and M are equivalent (i.e. F(C’’’) =F(M)). If ‘no’, go to step 5.

10. Associate the not-to-be-modified features of C withC’ (i.e. F(C’) = F(C) - F*). The to-be-modifiedfeatures remain in C (i.e. F(C) = F*). Associate themodified features with class C’’’ (i.e. F(C’’’) = F’).Insert C and C’’’ as subclasses of C’. Insert C’ as asubclass of all the classes of which C was a subclass.

3 I.e. classes the features of which are close to those underlying M.The features include both inherited and immediate features of the classin question.4 C’’ with M as its instance shares the goals, guiding principles,fundamental concepts and principles of the ISD underlying M.

0.00 (c) 1999 IEEE 5

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

Delete from the C’ those features that it inherits fromits superclasses. Insert M as an instance of C’’’.

11. If any of the to-be-modified features (i.e. F ∈ F(C) -F*) is inherited by C’, search the class C* from whichthe feature was inherited. Do CLEAN(C*,F). Repeatstep 11 until no modified features are inherited by C’.If any of the to-be-modified features is inserted in C’,delete them. Insert C’ as an instance of ISD ap-proaches. Go to step 22.

M and multiple inheritance12. Form a class C’’ with M as its instance. Associate all

the features underlying M with C’’. i.e. F(C’’) = F(M).Insert C’’ as an instance of the class ‘ISD approaches’.

13. Select a candidate class C ∈ C. If all candidate classesanalyzed, go to step 22.

14. Analyze whether C shares a subset of features of C’’,i.e. F(C) ⊂ F(C’’). If ‘yes’ insert C’’ as a subclass ofC. If ‘no’ go to step 16.

15. If all the features of C’’ are inherited in the classstructure, go to step 22. Otherwise go to step 13.

16. Consider whether C can be generalized to a class C’ sothat C’ includes a strict subset of immediate andinherited features of C (i.e. F(C’) ⊂ F(C)), and that C’shares a subset to features of C’’, i.e. F(C’) ⊂ F(C’’).If ‘no’, go step 19.

17. Form a class C’ with a subclass C. Associate thesubset F’ of (immediate and inherited) features of C(F’ ⊂ F(C)) to be generalized with C’. The features ofC not to be generalized remain in C (i.e. F(C) = F(C) -F’). Insert C’ as a subclass of all the classes of whichC was a subclass. Delete from the C’ those featuresthat it inherits from its superclasses. Insert C’’ as asubclass of C’.

18. If C’ inherits features not-to-be-generalized (i.e. F ∈F(C)), search the class C* from which the feature wasinherited. Do CLEAN(C*,F). Repeat step 18 until no F∈ F(C) is inherited by C’. If any of the not-to-be-generalized features is inserted in C’, delete them. If allthe features of C’’ are inherited in the class structure,go to step 22. Otherwise go to step 13.

19. Consider whether a subset F* ⊆ F(C) of the immedi-ate and inherited features of C can be modified to fea-tures F’= {F’} so that C and C’’’, in which C includesto-be -modified features F* and C’’’ includes themodified features F’, are subclasses of C’, and C’’’shares a subset of features of C’’(i.e. F(C’’’) ⊂F(C’’)). If ‘no’, go to step 13.

20. Associate the not-to-be-modified features of C withC’ (i.e. F(C’) = F(C) - F*). The to-be-modifiedfeatures remain in C (i.e. F(C) = F*). Associate themodified features with class C’’’ (i.e. F(C’’’) = F’).Insert C and C’’’ as subclasses of C’. Insert C’ as asubclass of all the classes of which C was a subclass.

0-7695-0001-3/99 $1

Delete from the C’ those features that it inherits fromits superclasses. Insert C’’ as a subclass of C’’’.

21. If any of the to-be-modified features (i.e. F ∈ F(C) =F*) is inherited by C’, search the class C* from whichthe feature was inherited. Do CLEAN(C*,F). Repeatstep 21 until no modified features are inherited by C’.If any of the to-be-modified features is inserted in C’,delete them. If all the features of C’’ are inherited inthe class structure, go to step 22. Otherwise go to step13.

22. Consider which of the new classes C’ and C’’’ aremeaningful as potential ISD approaches. Insert them asinstances of the class ‘ISD approaches’ (if not alreadydone).

23. The classification has been performed successfully.

Procedure CLEAN(C,F):1. Delete the feature F from C and insert it to all sub-

classes of C.2. If C becomes empty (i.e. does not include any imme-

diate features), insert all its subclasses as subclasses ofall its superclasses and delete C.

3. If C had instance methodologies insert them using theprocedure INSERT(M).

Even though the above procedure INSERT looks likean computer algorithm, its execution requires humanjudgment, especially step 1, analysis of the features (i.e.goals, guiding principles, fundamental goals and principlesof the ISD process) underlying the ISDM to be inserted,and step 2, selection of the candidate classes. Step 2 doesnot state criteria for the selection of the candidate classesbut obviously genealogical dependencies of ISDMs shouldbe considered in addition to sharing of common features.Also steps 6, 9, 16 and 19 include significant elements ofhuman judgment. Finally, step 22 is essentially humanjudgment.

The above procedure includes three “passes”. Pass 1(steps 3 and 4) checks whether a new ISDM is an instanceof any of the candidate classes. If it is, it is simply insertedas an instance of the class in question. Pass 2 (steps 5-11)checks whether an ISDM can be considered an instance ofsome class when an existing candidate class is generalizedby deleting or modifying some of its features. Pass 3(steps 12-21) deals with the situation of multipleinheritance. In this case the ISDM must be abstracted intoa new approach (step 12). The third pass ends when all thefeatures of the ISDM (or the new class formed from it) areinherited in the resultant class structure (steps 15, 18 and21) or the set of candidate classes have been analyzed (step13).

The application of the above procedure may includerenaming of existing classes to better capture the newclassification structure. This aspect will be illustratedbelow when the procedure is applied.

0.00 (c) 1999 IEEE 6

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

4. Two examples

To illustrate the procedure, we shall insert Object Model-ing Technique (OMT [32]) and Multiview [2] into theframework of Figure 1. OMT is used to illustrate the re-vision of the class hierarchy in the case of the object-ori-ented approach. Multiview on the other hand illustratesmultiple inheritance.

4.1 OMT as an OO approach

To classify OMT [32] requires a careful analysis of itsgoals, guiding principles, fundamental concepts and prin-ciples of the ISD process (step 1). Even though OMT hasinfluences from ‘Information modelling’, the ‘SA/SDapproach’ and the ‘OO approach’, we will treat the lastone as a relevant candidate class in its case (step 2).

Let us assume that the ‘OO approach’ considers fea-tures listed in Table 1 as fundamental. An essential featureof OMT is that it does not adhere to encapsulation in theOO analysis ([33], [17]). Let us call its encapsulationprinciple “weak encapsulation”. Therefore OMT cannot beconsidered an instance of the ‘OO approach’ as interpretedin Table 1, assuming that encapsulation refers to “strictencapsulation”, i.e. encapsulation throughout the OOdevelopment process (step 4).

The next question is whether OMT could be consideredan instance of the class resulting from the deletion ofsome features of the class ‘OO approach’ (steps 5 and 6).The possible feature to be deleted would be “strict encap-sulation”. Because OMT adheres to “weak encapsulation”,the total deletion of the capsulation principle does notwork in this case. So we can skip steps 7 and 8.

Let us analyze whether OMT can be inserted is an in-stance of the class ‘OO approach’ when its features aremodified properly (steps 9-11). In this case the “strictencapsulation” principle of the ‘OO approach’ must be

0-7695-0001-3/99 $1

modified to “weak encapsulation” that does not requireencapsulation in the OO analysis (step 9). In order to makethe names of classes more descriptive, let us change thename of the existing class ‘OO approach’ to ‘Strictlyencapsulated OO approach’. Thus now forms a new class,‘OO approach’. It adopts the goals, guiding principles,fundamental concepts and principles of the ISD process ofthe class ‘Strictly encapsulated OO approach’, except“strict encapsulation”. Let us also form a class 'Weaklyencapsulated OO approach' that includes “weak encapsu-lation”. Assuming that the above generalization is mean-ingful, step 10 constructs a class structure, in which theclass ‘OO approach’ has two subclasses, ‘Strictly encap-sulated OO approach’ and ‘Weakly encapsulated OO ap-proach’. Step 10 inserts OMT as an instance of the latterclass. Step 11 cleans the classification structure in the casethat the class ‘OO approach’ inherits the feature “strictencapsulation”. Finally, step 22 poses the questionwhether a class with features of the ‘OO approach’, whichdo not include any encapsulation principle, is a meaningfulISDA. If it is considered meaningful, it will be addedamong ISDAs (this might need again a renaming of theclass). If not, it is just a conceptual node in theclassification structure that is not expected to have meth-odology instances independently of the methodology in-stances of its subclasses.

4.2 Multiview and multiple inheritance

Multiview [2] is an ISDM that explicitly attempts to rec-oncile ideas from several ISDAs, most notably SSM,sociotechnical design, structured analysis and informationmodelling. Therefore it provides an excellent case to il-lustrate multiple inheritance.

Table 2 summarizes the characterizing features underly-ing Multiview. The characterizations in Table 2 followclosely the vocabulary of Multiview in order to preservethe authenticity of its interpretation.

Table 2. Characteristic features underlying MultiviewGoals Multiview provides a methodology for exploration into IS development (i: SSM).

More specifically, it helps in providing answers to the following questions:1. How is the IS supposed to further the aims of the organization? (i: SSM)2. How can it be fitted into the working lives of the people in the organization who are going to use it? (i:STD)3. How can the individuals concerned best relate to the computer in terms of operating it and using the output from it?4. What information processing function is the system to perform?5. What is the technical specification of a system that will come close enough to doing the things that you have written down in the answers to the other four questions?

Guiding To develop an information system, which is complete in both technical and human terms,principles requires multiple viewpoints comprising the viewpoints of human activity, information analysis,and beliefs sociotechnical aspects, human-computer interface and technical design.

The multiple viewpoints should be combined in a reasonably coherent “methodology framework”Analysis of human activity system: To search for a particular worldview, Weltanschauung, to form the basis fordescribing system requirements (i: SSM)

0.00 (c) 1999 IEEE 7

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

Information analysis: To analyze the entities and functions of the system, independent of how the system will eventuallydevelopAnalysis and design of the sociotechnical aspects: To produce a ‘good fit’ design, taking into account people and theirneeds and the working environment on the one hand, and the organizational structure, computer systems and necessarywork tasks on the other (i: STD)

Design of the human-computer interface: The dialogue should be related to who will be using the system. Design of technical aspects.

Funda- Analysis of Human Activity System (Human Activity System, Weltanschauung, root definition,mental relevant system, conceptual model (i: SSM), rich picture)concepts Information analysis: Functional analysis (function, event, dataflow)

Information analysis: Data analysis (entity, relationship, attribute)Socio-technical design (technical objectives, social objectives, technical alternatives, social alternatives (i: STD))Human-computer dialogueTechnical aspects (processing application, information retrieval, database maintenance, control, recovery, monitoring)

Principles Flexibility of the process within Multiviewof the ISD Five stages of IS analysis and designprocess Analysis of human activity system: A modification of the seven-stage model of [5]

Information analysis: Top-down decomposition of functions based on the primary task conceptual model; constructionof data flow models; verification of functional and entity modelsAnalysis and design of the sociotechnical aspects: Sociotechnical design, user participation (i: STD)

One can easily identify SSM and STD as clear candidateclasses in the sense of step 2 of the above procedure. Arudimentary comparison of the features of the IM ap-proach (Table 1) with Table 2 suggests that the latter doesnot form a reasonable candidate class for Multiview.Multiview has only adopted a few specific techniques(such as the ER model) from IM without other features.The relationship with the SA/SD approach is more com-plicated. Multiview has clearly adopted dataflow dia-grams. Although not stated explicitly, one could also insistthat it implicitly adheres to the goals and most of theguiding principles of the SA/SD approach. Despite thispossibility, we will focus on only two candidate classes,SSM and STD.

Referring to steps 3 and 4 of the above procedure, it isclear that Multiview cannot be inserted as an instance ofeither of the two candidate classes. Neither can the candi-date classes be generalized by removing features of theoriginal class nor their features modified in such a waythat Multiview could be regarded as an instance of thegeneralized or modified class (step 5 and step 9). So, let usproceed to step 12 of the above procedure.

Step 12 implies that Multiview forms an ISDA, thefeatures of which have been summarized in Table 3. Let usanalyze SSM first as a candidate class (step 13). It is clearthat the features of SSM as listed in Table 2 do not form asubset of features of Multiview in Table 3 (in particularthe stream of cultural analysis is missing in Multiview).Generalization of SSM by removing the stream of culturalanalysis (step 16) leads to a class of features which form asubset of the features of Multiview. Let us name the newclass ‘SSM-core’ and the original class ‘SSM-1990’.

0-7695-0001-3/99 $1

‘SSM-1990’ forms a subclass of ‘SSM-core’, inheritingall the features of ‘SSM-core’. The only non-inheritedfeature of ‘SSM-1990’ is the stream of cultural analysis.Let us insert Multiview as an ISDA a subclass of ‘SSM-core’.

Let us return to STD as a candidate class. According toour interpretation Multiview does not specifically em-phasize guiding principles such as minimal critical speci-fication and open-ended design, concepts such as varianceand unit operation and the evolutionary nature of the ISDprocess. This leads again in step 16 to a generalization inwhich a class ‘STD-reduced’ is formed. It includes all thefeatures of the original STD approach except the featuresmentioned above. The original STD approach, renamed‘STD-complete’ includes the omitted features and as asubset of the class ‘STD-reduced’ inherits all its features.The STD ideas of Multiview can be interpreted to coverthe features of the ‘STD-reduced’. Therefore Multiviewcan be inserted as a subset of ‘STD-reduced’.

When finalizing, there is the question whether the newclasses, ‘Multiview’, ‘SSM-core’ and ‘STD-reduced’ canbe considered reasonable ISDAs (step 22). Because ‘SSM-core’ corresponds to the version of SSM by [5], it can beregarded as an ISDA. To our knowledge, ‘STD-reduced’does not have any instance methodologies. Therefore, letus take a position that it does not form an ISDA of itself.To summarize, the above procedure leads us to considerMultiview as an ISDA that inherits from ‘SSM-core’ and‘STD-reduced’. The inherited features of Multiview areindicated by i:SSM and i:STD in Table 2, respectively.Additionally, Multiview includes a number of otherfeatures, e.g. the modification of the 7-stage model of [5]

0.00 (c) 1999 IEEE 8

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

and rich pictures from the SSM origin. Neither of thesewas interpreted as essential features of SSM in section 3.2.

The above example indicates that insertion of a newISDM does not necessarily lead to the most “elegant” classstructure. The resultant class structure would have beenmore elegant, had the initial structure more faithfullyrecorded the genealogy of SSM as an approach. In fact, onecould have identified in section 2.2 two versions (sub-approaches) of SSM: ‘SSM-1981’ and ‘SSM-1990’,corresponding to the two books ([5],[6]) of Checkland.The latter corresponds to a class with the same nameabove. ‘SSM-1981’ would have included the seven-stageprocess model as one of its principles of the ISD process.Both these would be subclasses of ‘SSM-core’ as definedabove. In this situation Multiview could have been in-serted directly as a subclass of ‘SSM-1981’.

5. Conclusions

In essence, we have provided concepts for moving thediscussion from ISDMs as principal units of analysis to ahigher level of granularity. The number of levels is flexi-ble and easily adjusts if progress is reflected in higherlevels of abstraction for discussing the “features’ of ap-proaches. This is the key point in which this paper goesbeyond earlier work published. Keeping the hierarchicalfeature inheritance structure “dynamic” and thereby up todate, should help to focus any future discussion on theessential rather than accidental features of ISDMs andISDAs. To illustrate these ideas that paper introduces twoexemplars on how to identify and summarize ISDA fea-tures. Of course, as any language evolves, so the represen-tation scheme may be extended in future work.

The first and more obvious implication of the paper isthat it organizes the field of methods and tools of ISD in amore comprehensible way through the development of astructure that distinguishes ISDMs and ISDAs. In this way,hundreds of ISDMs can be reduced to a few dozens ISDAscharacterized by their essential features. The reductiondoes not go at the expense of comprehensiveness oraccuracy, because the underlying categories are “leveled”(allowing for the representation of all details if needed atthe bottom level) and can easily be restructured to reflectnew principles and tools of ISD to reflect new knowledge.

This brings up a more subtle implication, which re-lates to language and knowledge dissemination. As notedabove, existing research on ISDM use in practice hasconsistently found that ISDMs, as far as they are used, areapplied adaptively customizing the ISDM to fit theorganization and project in question. However, when ISDis taught, this is not reflected in the way texts and teachers“represent” the principles of ISD. Typically the focus ison the specific details of one or two “widely practiced”ISDMs such as structured analysis or a specific objectoriented methodology. We think that a major obstacle for

0-7695-0001-3/99 $1

overcoming this has been the lack of a suitable languagethat affords to talk about principles of ISD in generalwithout resorting to motherhood statements andtrivialities. The terms in this paper constitute a proposalfor such a language, a starting point from which seasonedanalysts (and text book writers) can take off to develop anew vocabulary that encourages novices and their trainersto separate essentials from details and accidentals. Thedynamic version of the proposed framework allows us tocontinually capture the expert knowledge and insightsembedded in the continually emerging ISDM base. Wetherefore should think of it as a dynamic knowledge rep-resentation scheme. Currently, the collective knowledgeabout ISD, which has been built since the late fifties withthe emergence of the first life cycle methodologies, re-mains elusive and difficult to assimilate because it is toowidely dispersed in hundreds of ISDMs.

Hence the condensed presentations of ISDAs at thecore of this paper can be brought to bear on specific ISdevelopment project situations. In addition to the intel-lectual contributions, this has also practical implicationsbecause, at best, only a few ISDMs are likely to be mas-tered in practice by any one individual. The simplifyingconcepts of an ISDA may allow practitioners to widentheir “methodology” repertoire.

References

[1] Avison, D.E. and Fitzgerald, G., (1995), InformationSystems Development: Methodologies, Techniques andTools, Second edition, McGraw-Hill, NY

[2] Avison, D.E. and Wood-Harper, A.T., (1990), Multiview,An exploration in information systems development,Blackwell Scientific Publications, Oxford

[3] Brandt, I., “A comparative study of information systemsdesign methodologies, in [27], pp. 9-36

[4] Brooks, F. Jr., (1987), "No silver-bullet, Essence and ac-cidents in software engineering", Computer, April, pp. 10-19

[5] Checkland, P., (1981), Systems Thinking, Systems Prac-tice, John Wiley & Sons, Chichester

[6] Checkland, P. and Scholes, J., (1990), Soft SystemsMethodology in Action, John Wiley & Sons, Chichester

[7] Cotterman, W., Couger, J.D., Enger, N. and Harold, F.(eds.), (1981) Systems Analysis and Design: A foundationfor the 1980s, North-Holland, Amsterdam

[8] Cotterman, W., and Senn, J. (eds.) (1992), Challengesand Strategies for Research in Systems Development,Wiley, Chichester

[9] Couger, J.D., Colter, M. and Knapp, R., (1982), AdvancedSystems Development/ Feasibility Techniques, Wiley, NewYork, NY

[10] Fitzgerald, B., (1996), “Formalized systems developmentmethodologies: a critical perspective”, ISJ, vol. 6, No. 1,pp. 3-24.

0.00 (c) 1999 IEEE 9

Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999

[11] Fitzgerald, B., (1997), “The use of systems developmentmethodologies in practice: a field study”, JIS, Vol. 7,No.3,pp. 201-212

[12] Fok, L.M., Kumar, K. and Wood-Harper, A.T., (1987),“Methodologies for socio-technical systems (STS) de-velopment: A comparative review”, in DeGross, J.I. andKriebel, C.H. (eds.): Proceedings of the Eighth Inter-national Conference on Information Systems, Pittsburgh,Pennsylvania, pp. 319-334

[13] Harmsen, F., Brinkkemper, S. and Oei, H., (1994), "Situ-ational method engineering for information system projectapproaches", Verrijn-Stuart, A.A. and Olle, T.W. (eds.),Methods and Associated Tools for the InformationSystems Life Cycle, IFIP Transactions A-55, North-Holland, Amsterdam, 1994, pp. 169-194

[14] Hong, S., van den Goor, G. and Brinkkemper, S., (1993),"A formal approach to the comparison of object-orientedanalysis and design methodologies", Proceedings of theTwenty Sixth Annual Hawaii International Conference onSystems Sciences, Vol. X, IEEE Computer Society Press,pp. 689-698

[15] Hull, R. and King, R., (1987), “Semantic database mod-eling; Survey, applications, and research issues”, ACMComputing Surveys, Vol. 19, No. 3, pp. 201-260

[16] Iivari, J., (1994), "Object-oriented information systemsanalysis: A comparison of six object-oriented analysismethods", in Verrijn-Stuart, A.A. and Olle, T.W. (eds.),Methods and Associated Tools for the Information Sys-tems Life Cycle, IFIP Transactions A-55, North-Holland,Amsterdam, pp. 85-110

[17] Iivari, J., (1995), “Object-orientation as structural,functional and behavioral modelling: A comparison of sixmethods for object-oriented analysis”, Information andSoftware Technology, Vol. 37, No. 3, pp. 155-163

[18] Iivari, J. and Hirschheim, R. and Klein, H., (1998), “Aparadigmatic analysis contrasting information systemsdevelopment approaches and methodologies”, InformationSystems Research, Vol. 9, No. 2, pp. 164-193

[19] Iivari, J., Hirschheim, R., and Klein, H. K. (1999), “Un-tangling the methodology jungle”, submitted for pub-lication.

[20] Iivari, J. and Kerola, P., “A sociocybernetic frameworkfor the feature analysis of information systems designmethodologies”, in [27], pp. 87-139

[21] Jayaratna, N., (1994), Understanding and EvaluatingMethodologies, NISAD: A Systematic Framework,McGraw-Hill, Maidenhead

[22] Lyytinen, K., (1987), “A taxonomic perspective of in-formation systems development: Theoretical constructsand recommendations”, in Boland, R. and Hirschheim,R.A., Critical Issues in Information Systems Research,John Wiley & Sons, Chichester, 1987, pp. 3-41

[23] Maddison, R., Bakert, G., Bhabuta, L., Fitzgerald, G.,Hindle, K., Song, J., Stokes, N. and Wood, J. (1983), In-formation Systems Methodologies, Wiley-Heyden,Chichester

[24] Monarchi, D.E. and Puhr, G.I., (1992), "A research ty-pology for object-oriented analysis and design", Communi-cations of the ACM, Vol. 35, No. 9, pp. 35-47

0-7695-0001-3/99 $1

[25] Olerup, A., (1989), “Socio-technical design of computer-assisted work: A discussion of the ETHICS and Tavistockapproaches”, Scandinavian Journal of InformationSystems, Vol. 1, pp. 43-71

[26] Olle, T.W., Hagelstein, J., Macdonald, I.G., Rolland, C.,Sol, H.K., Van Assche, F.J.M. and Verrijn-Stuart, A.A.,(1988), Information Systems Methodologies, A frame-workfor understanding, Wokingham, England, Addison-Wesley

[27] Olle, T.W., Sol, H.G. and Tully, C.J. (eds.), (1983), In-formation systems design methodologies: a featureanalysis, North-Holland, Amsterdam

[28] Olle, T.W., Sol, H.G. and Verrijn-Stuart, A.A. (eds.),(1982) Information systems design methodologies: acomparative review, North-Holland, Amsterdam

[29] Olle, T.W., Sol, H.G. and Verrijn-Stuart, A.A. (eds.),(1986) Information systems design methodologies: im-proving the practice, North-Holland, Amsterdam

[30] Peckham, J. and Maryanski, F., (1988), “Semantic datamodels”, ACM Computing Surveys, Vol. 20, No. 3, pp.153-189

[31] Rossi, M. and Brinkemper, S., (1996), “Complexity matrixfor systems development methods”, Information Systems,Vol. 21, No. 2, pp. 209-227

[32] Rumbaugh J., Blaha, J., Premerlani, W. Eddy, F. andLorensen W., (1991), Object-Oriented Modeling andDesign, Prentice-Hall, Englewood Cliffs, NJ

[33] Rumbaugh, J., (1994), “The life of an object model, Howthe object model changes during the development”,Journal of Object Oriented Programming, Vol. 7, No. 1,pp. 24-32

[34] Song, X. and Osterweil, L.J., (1992), “Toward objective,systematic design-method comparisons”, IEEE Software,Vol. 9, No. 3, pp. 43-53

[35] Taggart, W.M.Jr. and Tharp, M.O., (1977) “A survey ofInformation Requirements Analysis Techniques”, Com-puting Surveys, Vol. 9, No. 4, pp. 273-290

[36] Townsend, D.F., (1980), Systems analysis: Key to the fu-ture, Datamation, Vol. 26, No. 10, pp. 145-148

[37] Wynekoop, J.L. and Russo, N., (1995), "Systems devel-opment methodologies: Unanswered questions”, Journalof Information Technology, Vol. 10, pp. 65-73.

[38] Yourdon, E., (1989), Modern Structured Analysis,Prentice-Hall, Englewood Cliffs, New Jersey, NJ

0.00 (c) 1999 IEEE 10