| System
Development, Methodologies and Modeling |
Last edit December 2006
Introduction
We are looking at how an analyst (or analyst team) designs information
systems - at the Requirements Analysis
and Design phases of the systems development life cycle.
The
Traditional Life Cycle
The diagram above shows the 'Traditional' systems development life cycle,
highlighting the stages in which modelling is typically used. (However,
modeling, and the techniques we will look at can be, and are used in every
type of system development process. The above diagram is itself a model!)
The problem for the analyst is
that any real world system is complex and computers somewhat limited in
functionality. The analyst needs to abstract from the target system
(ie: the system being analysed) the important data and activities/processes
which must be incorporated in a computerised system to make it useful.
In the last thirty years a number of
methodologies,
incorporating a variety of techniques, have been developed to make the
analysis and design stages more manageable. Almost every methodology has
at its heart at least one modeling technique.
Methodologies
In the initial Project Selection phase, a major decision is what system
development life cycle (SDLC)
will be used during the project.
A second major decision is what methodology
will be used - although often this decision is made by default when an
analyst or consultant team is chosen. There are many different methodologies
used in systems development.
"A methodology is a collection
of:
procedures,
tools, and
documentation aids
which will help the systems developers .. to implement a new information
system. .. It is usually based on some philosophical view, otherwise
it is merely a method, like a recipe." (Avison and Fitzgerald,
1991:4)
'Philosophical' in this context
can be understood as referring to the underlying attitudes and viewpoints,
and the different assumptions and emphases to be found within the methodology.
For example, some 'philosophies' on which a methodology might be based:
-
Systems are 'hard', structured, mechanistic.
-
Systems are 'soft', unstructured, organic.
-
Make as much use of computers as possible.
-
Include users in all phases.
-
Describe problems in order to generate solution.
-
Concentrate on solutions rather than problems.
-
Use prototypes wherever possible.
-
Use an evolutionary process; etc.
Why use a
methodology?
-
To introduce structure into design and make it more manageable
-
To make the analysis and design process more accessible to non-experts
Some
methodologies
Avison & Fitzgerald (1991) describe a number of methodologies eg:
-
Gane and Sarsons (STRADIS),
-
IE (Information Engineering),
-
SSADM (Structured Systems Analysis and Design Methodology),
-
JSD (Jackson Systems Development),
-
SSM (Soft Systems Methodology,
-
ETHICS etc.
Modeling
Computer systems
are models of the real world - they abstract
from the complexity of the real world.
The analyst observes the complexity of the real world and constructs
a model of (parts of) the target system in her head. Using systematic modeling
techniques the target system can be modeled on paper, or, using a Computer
Aided Software Engineering (CASE) tool, in a computer package. Some CASE
tools (in theory) will process the model to produce the required new system
- at the press of a key!
You as model
For example, you exist in model form in a number of systems. It has
been estimated that every human being in England 'exists' - ie: has a virtual
existence - in at least 20 database systems - and I would suggest this
is a very low estimate.
A number of the systems in which you 'exist' are within UWE. As a student
you must be in the Admissions, Library, Student Union, and Faculty systems.
Other systems which will include a representation, or model, of you
are Government and Banking Systems, as well as, perhaps, Supermarket and
Utilities systems.
One thing that all these systems have in common is that the 'you' which
they model is an abstraction - usually
your name and only those details which are relevant to the particular system.
Events which happen to you in the real world are (or should be) mirrored
in the model, but only those events which are seen to be relevant to that
system.
How up-to-date a computerised model is, is dependant on the efficiency
of the system's methods of data capture.
Assignments
as Example
As a student you do assignments. Assignments are modeled in the computer
system solely by a record of the mark or grade achieved for each assignment.
When you get an assignment grade or mark, then the 'you' in the Faculty
system has a mark allocated (usually by a member of staff entering the
mark via a terminal).
For the assignment, the model of you in the system does not do
anything other than receive a mark. Sometimes the 'you' in the Faculty
system gets the mark before the real-world 'you', sometimes vice-versa,
and it is always possible for the computer model of 'you' to have a different
mark or grade!
What is a model?
Douglas T. Ross (in Marca 1988) suggests that a
model answers questions; that the definition of a model is:
| M models
A
if
M
answers
questions about A |
Why model?
We need to model complex systems in the real world in order to understand
them. For example: we create computerised models of the real world to manipulate
large amounts of data and hence derive information which can assist in
decision making.
An analysts will create diagrammatic models of a target or proposed
system in order to:
-
understand the system, and
-
communicate:
-
to demonstrate, or clarify, understanding of the existing system and/or
to obtain feedback from users/clients;
-
to describe unambiguously the proposed computer system to users/clients
and to the programming team.
Modeling techniques are extremely useful in tackling the complexity which
is found when attempting to analyse and understand a system. Models are
also extremely useful communication tools; ie: complex ideas and concepts
can be captured on paper and can be shown to users and clients for clarification
and feedback; or for distribution to other professionals, team members,
contractors etc. In this respect, the final models created in the Design
and Development phases of a system are essentially paper
based prototypes.
Modeling
Techniques
The three most important modeling techniques used in analysing and building
information systems are:
-
Data Flow Diagramming (DFDs)
-
Logical Data Structure modelling (LDSs)
and
-
Entity Life Histories (ELHs)
Data Flow Diagrams (DFDs)
model events and processes (i.e. activities
which transform data) within a system. DFDs examine how data flows
into,
out of, and within the system. (Note: 'data' can be understood as
any 'thing' (eg: raw materials, filed information, ideas, etc.) which is
processed within the system.
See: Data Flow Diagrams (DFDs). |
|
Logical Data Structures (LDSs)
represent a system's information and data in another way. LDSs map the
underlying data structures as entity types, entity attributes, and the
relationships between the entities.
See: Logical Data Structures (LDSs) - Getting started.
|
|
| Entity Life Histories (ELHs)
describe the changes which happen to 'things' (entities) within the system. |
|
These three techniques are common to many methodologies and are widely
used in system analysis. Notation and graphics style may vary across methodologies,
but the underlying principles are generally the same.
In SSADM (Structured Systems Analysis and Design
Methodology - which has for a number of years been widely used
in the UK) systems analysts and modelers use the above
techniques to build up three,
inter-related, views of the target system, which are cross-checked
for consistency.
Data
Flow Diagrams (DFDs)
SSADM uses different sets of Data Flow Diagram to describe the target
system in different ways; eg:
-
WHAT the system does
-
HOW it does it
-
WHAT it should do
-
HOW it should do it
Another way of looking at it is that, in SSADM, DFDs are used to answer
the following data-oriented questions about a target system:
What processing is done?
When? How? Where? By whom?
What data is needed? By
whom? for what? When? |
However, we are not interested, here, in the development process in
detail, only in the general modeling technique. Essentially, DFDs describe
the information flows within a system.
DFD Principles
-
The general principle in Data Flow Diagramming is that a system can be
decomposed into subsystems, and subsystems can be decomposed into lower
level subsystems, and so on.
-
Each subsystem represents a process or activity in which data is processed.
At the lowest level, processes can no longer be decomposed.
-
Each 'process' (and from now on, by 'process' we mean subsystem and activity)
in a DFD has the characteristics of a system.
-
Just as a system must have input and output (if it is not dead), so a process
must have input and output.
-
Data enters the system from the environment; data flows between processes
within the system; and data is produced as output from the system
Basic DFD Notations
In a DFD,
a process may be shown as a circle,
an oval, or (typically) a rectangular box; and
data are shown as arrows coming
to, or going from the edge of the process box.
(SSADM)
DFD Notations
SSADM uses 4 diagramming notations in DFDs
-
Processes transform or manipulate
data. Each box has a unique number as identifier (top left) and a unique
name (an imperative - eg: 'do this' - statement in the main box area) The
top line is used for the location of, or the people responsible for, the
process.
-
Data Flows depict data/information
flowing to or from a process. The arrows used to represent the flows must
either start and/or end at a process box.
-
Data Stores are some location
where data is held temporarily or permanently.
-
External Entities , also known
as 'External source/recipients, are things (eg: people, machines, organisations
etc.) which contribute data or information to the system or which receive
data/information from it.
|
|
DFD Levels
| The 'Context Diagram ' is
an overall, simplified, view of the target system, which contains only
one process box, and the primary inputs and outputs. |
 |
The Context diagram above, and the one which follows, are a first
attempt at describing part of a 'Home Catalogue' sales system. In the modeling
process it is likely that diagrams will be reworked and amended many times
- until all parties are satisfied with the resulting model. A model can
usefully be described as a co-ordinated set of diagrams.
| The Top or 1st
level DFD, describes the whole of the target system.
The Top levelDFD
'bounds' the system -and shows the
major processes which are included within the system. |
|
Each Process box in the Top Level diagram may
itself be made up of a number of processes, and where this is the case,
the process box will be decomposed as a second level diagram.
Any box in the second level decomposition
may be decomposed to a third level. Very complex systems may possibly require
decomposition of some boxes to further levels.
Decomposition stops when
a process box can be described with an Elementary Function Description
using, for example, pseudocode.
Each box in a diagram has an identification
number (derived from the parent - the Context level is seen
as box 0) in the top left corner.
References
C.Ashworth & M.Goodland (1990) ' SSADM A Practical Approach',
McGraw-Hill.
D.E.Avison & G.Fitzgerald (1991) 'Information Systems Development',
Blackwell.
David A. Marca (1988), 'SADT. Structured Analysis and Design Technique',
McGraw-Hill.
Back to TOP
