Information Systems • Development A Frame Of Reference And Classifications ( Anders G. Nilsson The Institute for Development of Activities In Organizations Institute V Box 6501 S·11383 STOCKHOLM, Sweden Abstract: 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. Keywords: Application package, classification, computer support, development model, function/object/event analysis, Information systems development, life cycle, methodology, transformation. Please note: This paper Is related to the report by Bernt T. Bostrom "Information Systems Development: Supporting Methodologies With Computerized Tools". 1 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 or administrative activities manual or automatable 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 FUNCTION OPERATIUE MANUAL CAR ::I:NSPECTXON AUTOMATABLE ENGINE DXAGNOSTXCS • ""ORIe: S H O P ADMINISTRATIUE PLANNING INVOICXNG 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: ( Information Systems Development 2 Information Systems In Use (Operation) 3 Information Systems Maintenance Management 4 Information Systems Withdrawal There is an interaction between these phases. See figure 2. We start with Information systems development. This means work with analysis and design of Information systems. We create or acquire information systems which shali fulfli user needs and requirements. After that It Is time for the users to begin to utilize the Information systems In their activities. The Information systems are now In use or operation. 2 .. SYSTEMS DEUELOPMENT ....-IM~INTENANCEI...... WITHDRAWAL ~ • .! ~ :z INFORMATION SYSTEM IN USE (OPERATION) Figure 2 Ufe cycle 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) 3 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 2 use of application generators development with help of semi-manufactures built upon some kind of 4GL-tool ( 3 specification and design of tailor-made systems development with help of new specifications from scratch 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: 1 analytical design an abstract model of the information systems is analyzed in detail, the requirement specification is "frozen" before an implementation takes place 2 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: 1 expert work systems analysts are regarded as experts and develop information systems on their own ( for the users (expert strategy) 2 col/aborative work users and systems analysts develop information systems in collaboration within teamworks (anchoring strategy) 3 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 4 BUSINESS ACTIVITY ANALYSIS ( OTHER INFORMATION STATUS QUO, DEVELOPMENT SYSTEMS LIQUIDATION DEVELOPMENT PRESPECIFICATION: ACQU IS1Tl ON USE OF SPECIFICATION OF STANDARD APPLICATION AND DESIGN OF APPLICATION GENERATORS TAILOR-MADE PACKAGES SYSTEMS CONCRETENESS: CONCRETE ABSTRACT -~--------i---------"- ANALYTICAL EXPERIMENTAL DESIGN DESIGN "PROTOTYPING" USER INFLUENCE: EXPERT- SERVICE .. SELF- SERVICE EXPERT COLLABORATI VE USER WORK WORK WORK Flgule 3 Classillcallon 01 Infolmollon 'ystems development 5 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: 1 a perspective Including principles and values for good information systems and systems work 2 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: 3 a model with a number of development areas (phases) 4 a method with a number of coherent work steps (method steps) for each development area 5 a set of description techniques for actual document types produced during the work steps 6 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 2 the ISAC-model a general model for Information systems development 3 the SIV-model a specific model for acquisition of standard application packages 6 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 Business Diagnosis a short and rapid diagnosis of the company's business activities; this gives direction and scope for further development work ( V2 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 ( . V3 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 V4 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 V5 System Design a technical design of data systems following the requirement specification; we create data/program structures and manual routines V6 Realization we build and manufacture the Information systems according to the system design, such as program coding, data base organization and system tests V7 Implementation means that the users start to utilize the developed or acquired information systems In their activities va Foliow-up (Post Audit) we summarize experiences from using the Information systems; achieved results are checked against the change programme V9 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. 7 v - MOD E L VI V9 BUSINESS BUSINESS DIAGNOSIS ASSESSMENT BD BA ( V2 VB CHANGE FOLLOW STUDY UP CS FU V3 V7 ACTIVITY IMPLEMEN- STUDY TATION AS 1M ( V4 V6 INFORMAT.ION, REALIZA- STUDY TION IS RE V5 SYSTEM DESIGN SD Flguro 4 V·modol 8 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): 9 ~ ~ ~ "SYSTEMEERING" INFORMATION CHANGE SYSTEMS DEVELOPMENT .. TAILOR-MADE ANALYSIS .. GENERATORS .. PACKAGE to I' CURRENT Ir FUTURE I PRODUCT~~l ~FRVlrF~ 1 ACTIVITY. STUDIES 2 1 I NFORMATTON I ANALYSIS 3 1 SYSTEM DESIGN PROBLEM ANALYSIS Cl t ANALYSIS OF CHANGE Cl 2~~~6~ERS J t ACTIVITY DESCRIPTION • t STRUCTURE. ANALYSIS t DATA SYSTEMD CREATION ALTERNATIVES PRODUCT ION Z USER Cl II CJIIE Z CLASSIFICA- Cl Z MESSAGE Cl Z DATA STRUC- Cl ANALYSIS Z ACTIVITY • TION ANALYSIS TURE DESIGN DESCRIPTION . 3 ACTIVITY • PERSONNEL 3 CONTRIBUTION CJ 3 PROCESS Cl 3. PROGRAM Cl0 DESCRIPTION 3 EVALUATION Cl ANALYSIS ANALYSIS DESIGN 4 GOAL STUDY D 4 DECISION ON ORGANIZATIOl h 4 PRIORITY Cl 4 ANALYSIS OF n 4 DESIGN OF Cl EVALUATION DEVELOPMENT Cl. : RATING COMPLETENESSr MANUAL PARTS. S D MEASURES :! L--- I ~ • CONS I STENCY Figure 5 ISACmodel 1 Choice between several available packages on the market for our delimited activity area (V3 in the V-model) 2 Adaptation of the application package and the business activities to each other (V4, V5 and V6 In the V-model) 3 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 [1,2]. It has a customer perspective when dealing with application packages towards a vendor. ( DEVELOPMENT MODEL ( S I V CHANGE I CHOICE I FOLLOW STUDY -. I ADAPTAT ION I -. UP IINSTALLAT 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. ACTIUITY PACKAGE DESCRIPTION DESCRIPTION COMPARISON COMPARED DESCRIPTION Figure 7 Documentation (according to SiV) 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 11 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. 5.4 Evolution We will now present the history and evolution behind the ISAC-appro