=Paper=
{{Paper
|id=None
|storemode=property
|title=Information Systems Development: A Frame Of Reference and Classifications
|pdfUrl=https://ceur-ws.org/Vol-961/paper4.pdf
|volume=Vol-961
|dblpUrl=https://dblp.org/rec/conf/caise/Nilsson89
}}
==Information Systems Development: A Frame Of Reference and Classifications==
https://ceur-ws.org/Vol-961/paper4.pdf
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