=Paper=
{{Paper
|id=None
|storemode=property
|title=SVEA - A User Driven and Data Driven System Development Method
|pdfUrl=https://ceur-ws.org/Vol-961/paper9.pdf
|volume=Vol-961
|dblpUrl=https://dblp.org/rec/conf/caise/StenstromS89
}}
==SVEA - A User Driven and Data Driven System Development Method==
https://ceur-ws.org/Vol-961/paper9.pdf
April 1989
SVEA
A user driven and data driven
system development method
( by
lng-Marie Stenstrom and Eskil Swende
IRM Consult AB, Bromma, Sweden
(
SVEA - which in Swedish stands for "Strukturerad VErksamhetsinriktad Arbetsmodell" can be
translated to a "Structured Business Oriented Methodology".
The main strength of SVEA is speed in development resulting in higher quality EDP-systems.
By user driven we mean a method where users take active part in the development. The essence of
the working method is seminars, where the users knowledge of their business is transformed into
business models describing the data, the routines (both manual an computerized) and the organisation.
By data driven we mean a method, where the data definitions and the data structures build a stable
foundation for both databases and programs. The method builds on the philosophy that the basic data
structure in a company is stable while the information requirements and the organisation will
frequently undergo changes. It is therefore important that databases and EDP-systems can comply
with changes.
A prerequisite for high quality system development using a CASE tool is that a systems development
method is firmly embedded in the organisation. It is important that analysts do not hide behind a tool
and expect the tool to do all the communication for them.
SVEA is a method which focuses on the user. SVEA facilitates the interaction and communication
with the users securing a thorough analysis of business requirements.
The SVEA model
(r{t
"Trimming
phase"
P~(j\tl1 ~ ...... i"j
l'toovcriON
PWCR"'''S (
r((
" Construction
phase"
" Modelling
phase"
"Initiation phase"
1
Change of roles
By tradition all work to define system requirements and system specifications have been mn by EDP-
experts. Too quickly and too early the solutions have been described in technical terms causing
problems for the user to understand whether the system is reflecting his business or not. In SVEA
logical models of data and business work flows are created and then transferred to technical
solutions.
The role of the EDP-expert has shifted from interviewing the users, to becoming consultant/advisor
guiding the users in describing their business and specify their system requirements.
Expert so/wions are rep/aced ........ .....by IIser so/wions with expert Sllpport
To achieve this change we need simple models and working methods supporting an open and creative
discussion between the project members.
But still the models must be stringent and unambiguous; which means that a model should only be
possible to interpret in one way.
2
Systems development according to SVEA can briefly be described as
The Initiation Phase consisting of ...
The Outline stel>
This step can be described as an intensive pre-study.
The main purpose is to find the scope of the project by defining goals, restrictions, problems and
alternative solutions.The major part of the work takes place during a two day seminar attended by
users from the part of the business involved in the intended project. The work and discnssions are
stimulated by a couple of easy-to-use tools and the result is documented in a report.
The seminar must be well prepared and followed-up. The total Outline step takes two to eight weeks
depending on project size and complexity.
(
The data modelling
This is a two day seminar-activity involving users in describing the structure of data in the business.
As earlier mentioned SVEA is a data-driven method giving high priority to data and the infoffilation
resource in the business. The description technique in the data model is stringent giving the EDP-
expert an exact model of how data should be stored in the the database. To create a stable high-quality
data model is, however, not always an easy task. There are two main reasons for this.
First, data is nOllllally not well defined and consistent in the business. Two persons mean different
things by the same term, i e order could mean customer order, production order or purchase order. It
is also very common that the same data, i e customer is identified differently from user to user.
The second reason is til at data and the information resource arc very abstract in its nature and therefore
difficult to describe and define.
3
The data modelling seminar starts with a 3 hour education of users including a group task. The
remaining part of the seminar (12 hours) is intensively used to create the data model for the business
concerned.
To increase quality and stimulate discussion the participants are divided into two well balanced groups
of 5 to 7 persons in each group. The two groups work individually for one hour and then their results
are compared to reach one common data model. The groups are separated again, and the work goes
on step by step...
The seminar are guided by two experienced analysts.
Data modelling also includes creation of tables to which the various data elements are allocated
( according to fixed rules. This process is called normalization and is developed by the English
mathematician Ted Codd, giving high stringency to the model.
The rule of thumb is that data should be placed in the table where it is dependent on
( the key
the whole key
and nothing but the key.
As we will see these tables are essential in the SVEA model.
CIiellt
Pr.tresp.
. Region
r Mr ,rh responsibility
... PrOllIct """
(
P'"
group
~
r
~ StlllrWd
r ,
cd. tool , ••_ •
r, r 11
Type
" .... PrOllIct 1-0 Stodc .. of_
Poilt
grade tooIbGlneL.
r i"I r ,
TrlllSQCtion Till
"""
t""
4
The Modelling Phase consisting of...
The Routine Description
Now we concentrate on illustrating the future "business work flow" and describe activities, documents,
responsibilities etc. Here we describe how the EDP-system should cooperate with manual routines. It is
also useful to describe the dialog at the terminal.
It is of the utmost importance to realise that a computer system cannot guarantee a success by itself if the
present routines in the organisation are poor. However if the "work-flow" in the organisation is reviewed
together with the new functions of the computer system we stand a much higher chance of success.
The users are of course actively involved in describing the status today and discussing and analysing future
routines. Also here the essence of the analysis takes place in seminars, in this situation we invite 5-6 users
to each session.
The "routine description method" has its origin in Norway. The combination of a few easy-to-Iearn
symbols, reprinted on note-pads (easy to attach and move on the white board), makes the description both
simple and effective. (
Sale of
pMlct.
Enter_of SloclW-
T_
CUSTOMER
In each routine the required data is allocated to the table concerned. These tables are exactly the same tables
as earlier described in the data model. If a table is missing we simply add the required table in the data
model.
As these tables already are described the routine description process is much easier and much more
stringent. The routine description is data driven!
5
We now have tables from the data model and tables from the routine description. An impoflant step to
reach high quality is to verify that these tables are identical.
We may find out that a table is missing in the data model. Or the opposite that a table in the data model
is not used or that is has not any routine to handle it.
Another impoflant pm'pose of tlus verification is to complete the tables. From the data modelling
senunar we have identified most tables, but not necessarily all data in each table.
Input and Output Specification
Now all screens and reports identified in the description of routines must be described in detail.These
descriptions clarify input/output data in the various screens/ reports together with processing rules.
( Here we also specify frequencies for accessing screens/tables and our requirements for response
times.
Table Specification
After establishment of tables in the data model we have to complete all tables with data. The
documentation from the routine descriptions together with the specifications of reports and screen
layouts are required to complete the tables. Another important activity is to standardize all data names
and to enter relevant information about data elements into a data dictionlUy.
Before creating a table it is important to coordinate/check with existing tables in the business. We
should not create a new table if an existing table can be used.
Prototyping
SVEA strongly sUppOflS prototyping. In the Modelling phase of SVEA it is recommended that a
prototyping tool is used to clarify the system functions. In the routine description step the dialogue at
the temlinal is described in an simple way. But it is still only a model. By using a prototyping tool it is
possible to give the user an early real-life-picture of how the system will work after implementation. It
is easy to adjust the prototype, if the user find out in the simulation that something is wrong or can be
improved.
Easier to describe.....
......and to react
6
However, it is important to stress that it is a prototype, and not the final system. For some application
the remaining work after prototyping will be insignificant. In other applications a lot of work
concerning security, backup, response times, programming and database design still remains to be
done.
The Construction Phase
Now the physical databases will be designed, programs will be specified/coded/tested and suggested
changes in the organisation will be outlined in detail. The way the work in this phase is developed will
very much depend of the computer environment.
The Trimming Phase
Here the final trimming of the database, program/system and organisation takes place before the
system is implemented.
Acquisition of application packages
In most companies the backlog in system development is several years long and tends to increase.
One way to reduce the backlog is to purchase system packages for standard applications and instead
concentrating the in house resources on developing the EDP-systems most critical to the business.
When choosing the best package on the market the nornlal way is to study the dialogue and the rep0l1s
produced in the package.
The most important factor is however often overlooked i e the database and the data definitions. To
adapt and change the dialogues and reports are an easy and cheap task compared to the change of data
structure or data definitions.
The best way to make this analysis is to compare your own data model with the data model describing
the database in the package.
7
Experience of the SVEA model
Several investigations state mistakes discovered early in the development process are easy to correct,
early mistakes discovered late are however very expensive.
Interviews with experienced user of the SVEA model (mostly in large companies) can be
summarized as followed:-
* SVEA has an advantage in stressing high quality in the early definition phases.
* SVEA promotes agreement and commitment from and between users
( * SVEA is outstanding in its simplicity - you get to results rather than producing heavy
volumes of documentation
* SVEA's backbone is user interaction resulting in stable data base structures built on
Business Knowledge.
* SVEA promotes consensus around the way business should be operated and consensus
on concepts and interpretations.
* SVEA is speed without loosing quality!
SVEA takes advantage of and is enforced by the latest development in information technology, such
as relational databases, prototyping tools and development tools such as CASE.
8