This paper Is an attempt to classify the process of Information systems development In different ways. The main perspective Is that Information systems should support business activities In organizations. The development process Is Illustrated by our V-model, ISAC-model and SIV-model. We have experience of applications of these models from Swedish Industry. At the end a three·dimensional classification In function analysis, object analysis and event analysis Is presented as a base for comparisons of Information systems development methodologies.
Information Systems Should Support
Business Activities A company Is running some kind of business activities. The direction and scope of the activities are gUided towards some business goals of the company. We can classify the activities In different ways: operative manual or administrative or automatable activities activities The operative activities realize the company's business goals. They produce the products and services for customers on the market. Operative activities are the real business activities in a company. Administrative activities are supporting activities. They control and coordinate the operative activities in order to fulfil the business goals. The administrative activities support operative activities with appropriate Information. Information systems are examples of administrative activities. Both operative and administrative activities can be executed In different ways. When people execute the work tasks, we have manual activities. If machines can execute the work, we have automatable activities. An example of this is computer-based activities. We can combine operativeiadmlnlstrative and manual/automatable parts in an activity matrix for a company. See figure 1 with an example from a car repair company.
( .. ( ( ~N
CAR ::I:NSPECTXON ENGINE
""ORIe: SHOP
Rgure 1 Aotivity matrix: car repair company The main perspective we have here Is that Information systems should support the business activities In a company. The Information systems should provide the desired effects and benefits for operative activities. This Is a pragmatic and praxlologlc view of Information systems [8,12,13). We are against a perspective saying that information systems are ends In themselves. This view leads to a separation between Information systems and business activities which Is purposeless.
Our perspective admits that a specific information system can support other Information systems before giVing direct effects to the operative activities. A trend Is to distinguish many small Information subsystems each giving support to a well defined local activity (function), rather than to find a totally Integrated Information system In a company.
An Information system consists of three main parts; Input messages, message processing and output messages. We have also processing rules which control the execution of the Information system. If the processing rules are formalized we can have computer·based Information systems. But If the processing rules are '1uzzy" and we need a lot of personal knowledge, judgement and Intuition, the information systems must be manual. A purposeful Information system shall help users to make good decisions and support their actions. 2
Life Cycle Of Information Systems Informatlon systems, like other products, are going through a life cycle. We can Identify four main phases In a life cycle for Information systems: 2 3 4
Information Systems Development Information Systems In Use (Operation) Information
Systems
Maintenance Management :z INFORMATION SYSTEM (OPERATION) ~ I N
USE After some time we need to maintain the information systems. Maintenance consists of measures for corrections, adaptations, improvements and reorganizations of information systems. The causes for maintenance can be changes in business activities, in the environment of the company or in information technology. Maintenance management Is taking place when Information systems are in use (operation).
An important task for maintenance management is to make regular follow-ups (reviews, audits) of the quality of information systems; at least once a year. A follow-up can lead to different outcomes: status quo maintenance measures renewed systems development need for withdrawal Information systems will at the end be obsolete or unprofitable. They will not give the desired support for the business activities In the company. The iast phase of the life cycle is therefore withdrawal of information systems. This can be the starting point for a new life cycle. 3
Classification Of Information Systems
Development We shall now concentrate on the process of information systems development. But development of information systems is only one possible strategy or measure to improve business activities in a company. Examples of other forms of corporate development are product/service development, market development and organization development. In a real case you often choose a combination of development measures In order to satisfy the business goals of the company. This points out the need for a business activity analysIs as a starting point for all development work. The business activity analysis can lead to different outcomes:
Information systems development other development status quo (current situation Is sUfficlentiy good) liquidation (of activities that are obsolete) ( ( ( We focus our interest on information systems development. The business activity analysis must have pointed out that information systems development is a possible and appropriate strategy for Improvements In the company.
Information systems development can be accomplished in different ways. We need to characterize the process of information systems development into some appropriate situations. A frame of reference will be presented in this sense. See figure 3. We first classify information systems development after the degree of "prespecification" into: acquisition of standard application packages development with help of ready-made subsystems use of application generators development with help of semi-manufactures built upon some kind of 4GL-tool specification and design of tailor-made systems development with help of new specifications from scratch ( ( ( 2 3 1 2 1 2 3 Each of these strategies represent a very special development milieu. They require quite different methodologies in order to accomplish the development work in a fruitful manner. Information systems development can also be regarded as an abstract or a concrete process by users. This leads to another way of classifying information systems development after the degree of "concreteness" into: analytical design an abstract model of the information systems is analyzed in detail, the requirement specification is "frozen" before an implementation takes place experimental design (prototyplng) a simplified prototype (experiment system) of the Information systems is quickly implemented. The users get a concrete picture and can define their information needs in a better way before a final implementation Informatlon systems development is always a change process. There is a need for a cooperation between users and systems analysts. We can classify information systems development after the degree of "user influence" on the process into: expert work systems analysts are regarded as experts and develop information systems on their own for the users (expert strategy) col/aborative work users and systems analysts develop information systems in collaboration within teamworks (anchoring strategy) user work users develop Information systems on their own (self-service), if needed the users can get help from the systems analysts during the development process (process strategy) Above we have classified information systems development after the degree of prespecificatlon, concreteness and user influence. They are independent classifications. We can therefore combine the different outcomes into 3 x 2 x 3 = 18 different situations of information systems development. In the past the dominating combination was "tailor-made systems with analytical design by expert work". In OTHER
DEVELOPMENT PRESPECIFICATION:
ACQU IS1Tl ON OF STANDARD APPLICATION
PACKAGES CONCRETENESS:
ANALYTICAL
DESIGN
USER INFLUENCE: EXPERT SERVICE INFORMATION SYSTEMS DEVELOPMENT USE OF APPLICATION GENERATORS
STATUS QUO,
LIQUIDATION SPECIFICATION AND DESIGN OF TAILOR-MADE SYSTEMS ( ABSTRACT -~--------i---------"EXPERIMENTAL DESIGN "PROTOTYPING" EXPERT WORK
COLLABORATI VE WORK
USER
WORK
CONCRETE
SELF SERVICE 1 2 3 4 5 6 2 3 the future we can have many more situations than we have sketched here. But a common denominator is the need for a business activity analysis before we choose our strategy for Information systems development. 4
What Is a Methodology? The concept of methodology for information systems development has been debated during a long period of time. Today most researchers agree upon the fact that a methodology gives a set of guidelines for a systematic way of working with development tasks. It is important to realize that every methodology is built upon: a perspective Including principles and values for good information systems and systems work a set of more or less defined concepts which the development work Is based upon Information systems development Is a comprehensive and complex work task. You have to tackle many problems and to decide upon many questions. Therefore a methodology have to divide the development work Into a number of perceivable phases. A useful methodology should consist of the following parts: a model with a number of development areas (phases) a method with a number of coherent work steps (method steps) for each development area a set of description techniques for actual document types produced during the work steps a set of tools like computer supports for document handling and to manage transitions between work steps In a real case you often have to choose between alternative methods. techniques and tools. Different situations may require different methodologies. We have also a possibility to combine some methodologies with each other and get a "methodology chain". Sometimes we use the concept approach as a synonym for methodology. But an approach could be a whole methodology or only some parts of It. 5
Development Models· Our Perspective The development process will now be Illustrated by some models from which we have derived experience from applications In Swedish Industry. They are: the V-model an overall model for corporate development the ISAC-model a general model for Information systems development the SIV-model a specific model for acquisition of standard application packages We also present the history and evolution of our development models with an emphasis on the ISAC-model. 5.1
V-model The V-model Is focused on corporate development with a connection to information systems development. It gives a broad perspective for development of business activities In organizations. The model has an ability to comprise different methods, techniques and tools. Our V-model consists of nine development areas (see figure 4): V1 V2 . V3 V4 V5 V6 V7 va V9
Business Diagnosis a short and rapid diagnosis of the company's business activities; this gives direction and scope for further development work Change Study (Change Analysis) a deeper and more detailed study of problems, needs for changes and alternative solutions for a delimited activity area in the company; this leads to a change programme Activity Study a study of Information systems and their potential contributions to the business activities, we classify the information systems in manual and computer-based parts Information Study (Information Analysis) a detailed study of the user's information needs; this leads to a requirement specification for each Information system with messages and processes System Design a technical design of data systems following the requirement specification; we create data/program structures and manual routines Realization we build and manufacture the Information systems according to the system design, such as program coding, data base organization and system tests Implementation means that the users start to utilize the developed or acquired information systems In their activities Foliow-up (Post Audit) we summarize experiences from using the Information systems; achieved results are checked against the change programme Business Assessment we check that the developed activity areas correspond to our visions from business diagnosis There is a logic that we draw the model as a "V". The development areas has a specific correspondence to each other. Business assessment Is a check to business diagnosis, follow-up Is a check to change study, Implementation shall fulfil the results from activity study and finally realization shall fulfil the results from Information study. ( ( ( (
BUSINESS DIAGNOSIS
VI BD
CHANGE STUDY
V2 CS v - MOD E L
SD We have used the concepts business activity analysis and information systems development many times. Business activity analysis corresponds to the development areas V1, V2 and V3 in the V-model. Information systems development corresponds to the areas V3, V4, V5 and V6. Two important features with the V-model are the possibilities to use the ISAC-approach (with computer support GraphDoc) and the SIV-approach (with computer support SIV-DOC). 5.2
ISAC-model The ISAC-modells general for Information systems development with an emphasis on tailor-made and generated systems. ISAC Is an acronym for "Information Systems work and Analysis of Changes". The ISAC-model consists of two main development areas according to the acronym:
Change Analysis
Investigation of problems and possible solutions for business activities In a company 2
Inlormation Systems Development ("Systemeerlng") analysis and design of information systems in order to support the business activities The ISAC-model corresponds to the development areas V2, V3, V4 and V5 in the V-model. The ISAC-approach is a complete methodology and it is published in a full version [14J and a short version [3]. For a summary of the short version, see figure 5. The most interesting feature of the ISAC-methodology Is the use of activity descriptions with A-graphs (activity graphs). The A-graphs show how Information systems support business activities In a company. A-graphs is a part of the . SDA-technlque for Systematic Description of Activities.
GraphDoc Is a powerful tool for drawing and updating A-graphs (and I-graphs). The computer support guarantees a consistent documentation. GraphDoc can be used during the development areas V1, V2, V3 and V4 In the V-model. In the ISAC-model GraphDoc Is used during work steps with graph drawing. There have been many attempts to produce computerized tools for the ISAC-methodology, but GraphDoc is the first really useful product in this sense. An interesting trend Is the use of knowledge based systems (expert systems) as computerized tools for the ISAC-methodology [11]. 5.3
SIV-model The SIV-modells a specific approach for acquisition of standard application packages to support business activities. The acronym SIV stands for "Standard application packages for Improved business Activities ( = "Verksamhet" In Swedish)". Application packages are more and more taking over the importance of self made systems [6,9]. The SIV-model consists of three main development areas (see figure 6): ( ( ~ ~ ~
INFORMATION
SYSTEMS DEVELOPMENT to
I' Z 3 4
I r 4 ANALYSIS OF n
Choice
between several available packages on the market for our delimited activity area (V3 in the
V-model)
Adaptation
of the application package and the business activities to each other (V4, V5 and V6 In the
V-model)
Installation
of the application package In real life to support the business activities (V7 in the V-model)
The SIV-model comprises the development areas V3 through V7 in the V-model. A change study
precedes and a follow-up succeeds the SIV-model. The SIV-approach is pUblished as a complete
methodology [
DEVELOPMENT
MODEL - .
- .
FOLLOW
UP S
I
V I CHOICE I
I ADAPTAT ION I
II NSTALLAT ION I
Flgur.6 SIV·model A special thing in this development milieu is that we have to make comparisons between our requirements for the business activities and the properties of the application packages. In this sense we need access to three types of documentation; activity description, package description and a compared description. See figure 7. Activity descriptions with A-graphs can be a powerful basis for both choice and adaptation of application packages.
SIV-DOC is a computer support for applying the SIV·approach in a more efficient manner. The tool is for the moment only a prototype in order to illustrate a choice of application packages on the market. A ( ( user defines a search profile for his demands and then scans through databases of application packages, SIV-DOC can be integrated with the tool GraphDoc and corresponds to the development areas V3 and V4 In the V-model. We will now present the history and evolution behind the ISAC-appro<lch, See figure 8, Information systems development starts with some perceived problems of the users and goes through a requirement specification to implementation of computer solutions, The first version of the ISAC-approach was developed In 1968, The information analysis area was Invented as a purposeful basis for system construction, At this time many systems were built without regarding the real information needs of the users, Information analysis became an Instrument for doing better computer programs, Empirical tests of the ISAC-approach showed that information analysis was not enough, We have to know if the information systems are a real support for the business activities, So around 1972 the development area activity analysis was Invented, Further empirical tests of the ISAC-approach showed that even activity analysis was not enough, We have to know If information systems are solutions to the existing problems or if other development measures should be taken, So around 1976 the development area change analysis was invented, At the same time system construction was divided Into data system design and equipment adaptation, The ISAC-approach now became a complete methodology and was published in a book [14].
After starting up Institute V during 1981 we have done some more empirical tests. Around 1982 we divided change analysis into two subareas; business diagnosis and change study. The business diagnosis is a broad change analysis for the whole business, while the change study is a delimited analysis for some activity area. After a change study you can choose between tailor-made, generated or package systems. All of this we try to take care of In the V-model. The SIV-model is an extension for dealing with application packages. 6
Classification Of Methodologies Many researchers have done a lot of work to classify different Information systems development methodologies [5,7,17,18,19,20]. A common approach Is to define a broad range of evaluation criteria for comparison of methodologies. It could be over hundreds of criteria to handle in a concrete evaluation situation. There is a need for a more comprehensive view of the available methodologies on the market today. We have for some time looked for a simple, complete and fruitful classification of methodologies. A proposal is to focus information systems development on three different aspects [15,16,22]: 2 3
Function analysis (process-driven perspective) (late 1960's) Object analysis (data-driven perspective) (mid 1970's) Event analysis (behaviour-driven perspective) (early 1980's) 1%8 1972
1976 m1:~1!'ON ~ ~
ACTIVITY ANALYSIS"""
CHANGE . ; / ANALySIS ............
~ ~\D!mY INFORMATl0ti-- INFORMATION TAILOR GENE- PACKAGE ANALYSIS ANALYSIS MADE RATORS 1982
BUSINESS ~ DIAGNOSIS /
CHANGE STUQY I SAC
- A P PRO AC H SYSTEM CONSTRUCTION
_ ___ - - - - . . . SYSTEM
DESIGN -----------....
DATA EQUIPMENT
ADAPTATION
C0I1PUTER
PROBLEM S Y S T E r1 S D E V E L o P M E N
T REQ, SPEC,
SOLUTION ( ( ( (
The classification also shows a historical evolution of methodologies. The first approaches for development of computer-based Information systems were function-oriented. As a reaction to these data-driven approaches somewhat later emerged on the market emphasizing an object view of the reality. They proposed that Information systems development should be built on data, which are more stable than functions [4,21]. Both functlon- and object-oriented methodologies originally proposed a static description of information systems. As a reaction to these behavior-driven approaches emerged considering properties such as triggers, dynamics and time-sequences. We use the term event analysis for this kind of approaches. A special kind of event analysis Is the use of routine analysis. An Interesting comment Is that routine analysis has been used for a very long period of time when designing manual routines In Information systems.
At the beginning the three different aspects or "schools" were competing with each other. But nowadays they more and more seek for appropriate combinations. The motive for this Is that the three aspects need to be complemented In real life applications. We think that a three-dimensional classification in function, object and event analysis could be a solid base for comparison of methodologies for Information systems development. See figure 9.
FUNCTION
ANALYSIS
OBJECT ANALYSIS
EUENT
ANALYSIS Function-oriented methodologies emphasize the analysis of purposeful functions and their connections within a delimited activity area. The development work follows a top-down approach with hierarchical decomposition of functions In a number of levels: 2 3 1 2
Activities and
subactlvltles Processes and
subprocesses Programs and
program modules Physical flow of goods/persons
(operative aspect) Informatlon flow of messages (administrative aspect) For every function we define appropriate Inputs and outputs. It Is often recommended to start the analysis with the outputs or the desired results from a function. The connections between the functions Is shown by the Input/output sets. We can distinguish two major types of connections: 2 3 2 3 4 The function analysis Is documented In function graphs. like A-graphs or data flow graphs. All of the function-oriented methodologies handle Information flows but a few focus attention on physical flows, foremost Scandinavian approaches. But at the end our Interest Is to sketch the functions and their Information needs. A typical way of working with function analysis Is as follows:
Break down the business area into purposeful functions Indicate the processing philosophy for the functions (manual. computer-based) Define exactly Inputs/outputs for the functions and make when necessary descriptions of the processes 6.2
Object Analysis Object-oriented methodologies emphasize the analysis of objects and information (data) about them in a delimited activity area. This "school" has many names like objecl/information/data/conceptual modelling. A typical way of working with object analysis Is as follows:
Identify purposeful objects (entitles) In the business area Describe necessary relations (associations) between two or more objects Indicate appropriate information (data) about the objects and the relations; this Is called attributes (properties) and consist of both identifiers and descriptors Define different constraints for objects, relations and attributes.
Examples are cardinality. transactions and value domains Object analysis is documented In special graphs, often called data or conceptual models. These could have a variety of complexity depending on how much constraints you want to show in the models. A possibility is to have teXl pages and tables as complements to the data models.
Data models of a reality can be constructed in different ways. It Is often recommended that we first make many small. local user models and then integrate these In several steps to a whole. global data model. This is called view integration of user needs. The data model can be used as a basis for normalization when we want to design data bases for an application. 6.3
Event Analysis Event-oriented methodologies emphasize the analysis of behaviour properties such as dynamics. triggers and transactions In a delimited activity area. The most essential thing is to sketch the time sequence for functions and data In a system. A special kind of event analysis is the use of routine analysis. More exactly a routine (or an errand) triggers a series of events and normally goes through several functions and uses different forms of data. all this in a certain time order. A typical way of working with routine (event) analysis Is as follows: ( (
Define relevant functions and data sets for every routine; Identify actual Interest groups which are responsible for different parts of a routine Describe the time sequence and the behaviour logic of the routine such as triggers and alternative/combined actions Routine analysis can be documented in different ways, like graphs, matrices and tables. Such routine sketches can be based on either some pedagogical (popular) symbols or some formal (correct) rules. Most methodologies for routine analysis focus on Information flows In a system (administrative aspect). Very few approaches also consider the physical flow of goods (operative aspect).
Another way of using event analysis Is to specify possible and allowed order between different parts In a system. This Is of special Interest for dlalogue·based systems. In a dialogue·based system we must describe the structure and order between different dialogues (or menues). This can be documented In State Transition Diagrams (STD). A dialogue Is often a smaller part of a business routine. Event analysis Is a complement to function and object analysis. Sometimes you tackle limited behaviour aspects also in function analysis (description of processes) and object analysis (description of transactions). But often it is not enough for synchronization of functions and objects/data to each other in a proper manner. 6.4
Examples Of Methodologies We will now give some examples of methodologies for function, object and event analysis. This is a selection of some well·known approaches from Scandinavia and from the International market. Most methodologies have a focus on one aspect and some have an equal emphasis on two aspects. Here are some examples: Function analysis: There are several computer supports emerging on the market today. They support either a specific methodology or a group of different methodologies from at least two of oUr aspects, We call the latter group integrated tools. Here are som examples: Function anaiysis:
GraphDoc (for ISAC), SIV-DOC, DASAK (for SAK) In a real situation we often need to combine at least two of the three aspects function, object and event analysis. We need an appropriate mix of the aspects. Normally one of the aspects have a dominating role, I.e. function analysis when we have a process-complex' application. There is a need for more research of how to transform the three aspects to each other. We can on a crude level think of three ways of working with the aspects, namely in: - Sequential way - Parallel way - Iterative way
Function analysis There Is a good motive to start the development work with at least a crude function analysis. This gives a delimitation of the business area as a basis for further discussions on data use and routine handling. A perspective for working with the aspects could therefore be as follows: 2
Object and event analysis (in paraliel) with possibilities to do necessary Iterations. We have some good experiences from this way of working. A proposed methodology for combining function analysis (step 1-3) and object analysis (step 4-7) could be as follows:
Break down the business area in purposeful functions with the help of A-graphs 2 3 4 5 6 7
Indicate manual and computer-based functions Define the interfaces (inputs/outputs) between functions Describe relevant interfaces with the help of visual layouts Construct a local data model for every Interface Integrate the local models to a global data model Check consistency, completeness and workability The function analysis is a top-down process while the object analysis Is a bottom-up process [10]. A proposed methodology for combining function analysis (step 1-3) and event/routine analysis (step 4-7) could be as follows:
Break down the business area In purposeful functions w~h the help of A-graphs Indicate manual and computer-based functions Define data sets (inputs/outputs) between functions Indicate purposeful routines (with events) for the business area Define which functions and data sets In the A-graphs that are affected by each routine Describe the time sequence for each routine going through the A-graphs Construct a routine sketch or a state transition diagram (STD) for every routine showing the order between different funtlons/data sets In the A-graphs
Car Repair Company. an Example We will now Illustrate how we can work w~h the three aspects function, object and event analysis In an example from a car repair company. The example follows the transformation rules outlined In section 6.5 above. The business area of the car repair company Is documented according to: Function analysis A-graphs (ISAC) using GraphDoc Object analysIs .
Data model (EASYDOC) using Modellator Event analysis Routine sketches (RutinfiOden) using RUTH (figure 10) (figure 11) (figure 12a, 12b) We have documented the current situation of our car repair company. The function analysis consists of two A·graphs; an overall graph of the "car repair company' and a detailed graph of the "repair shop". The object analysis consists of a data model shOWing a graph of relevant objects and their relations and a teXllIst of attributes; all this in a car repair environment. The event analysis consists of two routine sketches for "car handling" and "customer questions". 7
Conclusions The purpose of this paper Is to classify the process of Information systems development according to a frame of reference. The main perspective is that Information systems should support business activities. See figure 13. We have here the business activities In focus. There are many factors In a company which contribute and interact In order to achieve desired results In the business activities. On a crude level we have strategies for the physical flow of goods, Information systems and organization of work. Car Repair Company A-graph CO
C
'.
L -I-/ICftP~CITY, ~ORK
STRTUS Repair Shop A-graph C7
C7 Car repair company with repair shop
-2 CO'PlE1EO,'-WORKOROERr • RNSWER --j
--" ( consists of
.!~ SECTIOtl +
helongs to
WORKER requires
SPARK PART ,
SHOP CUSTOMER .
.
SUPPLIER
purchases I'"
delivers CUSTOMER
CUSTOMER
PART REPA I R
Address Telephone SHOP
Address Telephone SPARE Part-no Number in stock Part status Price SUPPLIER
Address
Telephone Agur8 11 Object analysis (Modellalor): Car repaIr environment
Car Handling
Routine Sketch B1 .
IHSPEC
B5 F1lE PlM 86 87 wo
REPAIR BB . REPORT 18 PRICES - 81 REQUES CustoAer reqUests -82 IliSPEC Inspect cars - 83 I/O PreliNinary workorder - 84 PLAN Work shop planning - OS FILE File on statistics of repair works -86 110 Delivered work order - 87 REPAIR Repair work (at sections) - 88 REPORT Report on used tine a parts - 89 11l\I • Invoicing - 18 PRICES Prices on work t iRe and spare parts -11 IIfJOIC Invoices to custoners ( ( Agure 12& Event analySis (RUTH):
Cat handling roullne I~ ANSWER s~ ~OST? 16 21 ( 5 13 CONIAC 28 QUEST ANSWER CONIAC
ANSWER 18 PRICES Agure 12b Event analysis (RUTH): Customsr questions routine ACTIVITIES INFORMATI ON
SYSTEMS
DEVELOPMENT METHODOLOGIES
EDUCATION Agure 13 Factors contrlbutrng to business lIoUvltle.
Information systems could be of different kinds such as package, generated or tailor-made systems. If information systems should give a good support for business we have to consider the whole life cycle. There Is always possibilities to Improve development, use and maintenance of Information systems. Information systems development Is Influenced by many factors such as project management, methodologies and cooperation principles. These factors have to be coordinated In a real situation. Information systems development methodologies can have positive effects In a company. But this requires that the methodologies lead to efficient development, which in turn lead to high-quality information systems, and furthermore to a good support for the business activities. It is also important how a company choose, educate and support a methodology. We have today a huge number of methodologies on the market. But It is rather easy to classlly them after function, object and event analysis. In the future a useful methodology must be supported by powerful computerized tools. [4] [9J
ANVESKOG, LENNART & J.A.RPERUD, JAN & LUNDEBERG, MATS & MELIN, SIGVARD & NILSSON, ANDERS (1983).
Verksamhetsutveckling - All Anpassa Standardsystem, Studentlilleratur, Lund (in Swedish, English summary of the SIV-methodology for "Adaptation" Is available from Institute V) ANVESKOG, LENNART & NILSSON, ANDERS & NOf;lD, INGE (1984).
Verksamhetsutveckllng - All Valla Standardsystem, Studentlilleratur, Lund (In Swedish, English summary of the SIV-methodology for "Cholce".ls available from Institute V) BOSTROM, BERNT & NILSSON, ANDERS & SELLDE'N, JAN (1986).
Systemerlng med Dators16d, Esselte Studium, Stockholm (in Swedish, English translation Is planned) BUBENKO JR, JANIS A. (1986).
Information System Methodologies - A Research View, SYSLAB Report No. 40, University of Stockholm (Also published in [19] ) CANNING, RICHARD G. (1979).
The Analysis of User Needs, EDP Analyzer, Vol. 17, No.1, January 1979 EDMUNDSON, BOB H. & JEFFERY, D. ROSS (1984).
The Impact of Requirements Analysis upon User Satisfaction with Packaged Software, Information & Management No.7, 1984, pp. 83-90, Elsevier, North-Holland FITZGERALD, G. & STOKES, N. & WOOD J.R.G. (1985).
Feature Analysis of Contempary Information Systems Methodologies, The Computer Journal, Vol. 28, No.3, 1985, pp. 223-230 GASPARSKI, WOJCIECH & PSZCZOLOWSKI, TADEUSZ (1983).
Praxlological Studies - Polish Contributions to the Science of Efficient Action, PWN- Polish Scientific Publishers, Warszawa and D. Reidel Publishing Company, Dordrecht, Holland GROSS, PAMELA HB & GINZBERG, MICHAEL J. (1984).
Barriers to the Adoption of Application Software Packages; Systems. Objectives. Solutions, No.4, 1984, pp. 211-226, Elsevier, North-Holland
HANANI, MICHAEL Z. & SHOVAL, PERETZ (1986).
A Combined Methodology for Information Systems Analysis and Design Based on ISAC and NIAM, Information Systems, Vol. 11, No.3, pp. 245-253 [11] KARAGIANNIS, DIMITRIS & SCHNEIDER, HANS-JOCHEN (1986).
Knowledge Based Systems for Information Systems Development - A case study with ISAC-prototypes, Institut IUr Angewandte Informatlk, Technical University of Berlin (