SYSTEM DEVELOPMENT METHODS

1
53901 SYSTEM DEVELOPMENT METHODS Session 3 --
SSADM Teddy So tkkso_at_graduate.hku.hk
2
Revision
3
Modeling Modeling is used extensively in
structured system development. A model of a
system represents a part of the real world.
Modeling is the process of abstracting and
organizing significant features of part of the
real world, or how we would like it to be. Each
model has its own advantages and limitations. A
model describes something about the subject, but
not everything. Different models illustrate
different things.
4
Models help system developer to communicate with
client and also help client to understand the
new system. They are helpful to tackle the
complexity of large systems. Two main
intellectual techniques are used to cope with
complexity Decomposition Use the divide and
conquer approach to keep on breaking the complex
problem into smaller problems until it is small
enough to be managed Abstraction Focus on the
most important elements while ignoring currently
other irrelevant details
5
(No Transcript)
6
The models employed in structured system
development make use of both techniques. During
the analysis of a system the same technique may
be used to model the system at different stages.
Different model techniques have their own
perspectives or focuses
7
(No Transcript)
8
(No Transcript)
9
Balancing Rules The data flows entering or
leaving a parent diagram should be equal to
those on the child diagram. New flows are not
introduced arbitrarily at lower, more detailed,
levels. What went wrong in the Level 2 diagram?
10
E-R Modeling and Normalization Data modeling has
its own terminology by describing data in terms
of entities, occurrences of entities, attributes
of entities, values of entities, entity keys,
and relationships between entities. Entity An
entity is an object about which the system
requires to hold data. It is represented as a
rectangle box in an E-R model diagram. The name
of the entity is written inside the rectangle
box. In a computer-based system an entity is
likely to be implemented as a computer file.
11
Occurrence Following the example entities above,
entity is a number of entities occurrences. An
occurrence of an entity describes one particular
supplier or product. In a computer-based system
occurrence is implemented as a record in a
computer file. Attribute It is the data item or
element that makes up an entity. In a
computer-based system attribute is implemented
as a field in a computer file. Value It is the
value of an attribute for a particular entity
occurrence. Key It is an attribute or groups of
attributes which has a unique value to identify
one occurrence of that entity.
12
Relationship A relationship is a link between two
entities. When designing an information system,
it is important to capture all significant
relationships. Sometimes it is useful to name
the relationship between two entities.
13
The Degree of Relationships
WIFE
14
First Normal Form An entity has an identifying
key and there are no repeating attributes or
groups of attributes. Second Normal Form An
entity in 1NF and has no attributes which
requires only part of the key to identify them
uniquely. Third Normal Form The entity in 2NF
and no non-key attribute depends on any other
non-key attribute.
15
Normalization consists of the following steps
http//www.sum-it.nl/cursus/dbdesign/english/logis
010.php3
16

• Entity Life Histories
• Different modeling techniques focus on different
  areas of
• developing a system. Data flow diagram focuses on
  the
• movement of data in a system at different levels
  of details. Data
• model focuses on the relationship between
  entities.
• Usually they are read from left to right and from
  top to bottom.
• However, it is by no means to imply the
  sequencing, iteration,
• order or timing of events in a system. To get a
  view of the ordering
• of events in a system, another approach needed.
• Entity Life Histories is a diagrammatic technique
  that provides a
• view of all possible life histories for any
  occurrence of a particular
• entity in a system. Typically it includes three
  stages / steps
• Creation
• Amendment / Updating
• Deletion

17
(No Transcript)
18
Sequencing
19
Repetition
20
Alternative
21
(No Transcript)
22
Events without Order
23
Suggested Solutions to Tutorial 1 Task 1a
24
Suggested Solutions to Tutorial 1 Task 1b
25
Suggested Solutions to Tutorial 1 Task 2a
26
Suggested Solutions to Tutorial 1 Task 1b
27
What is SSADM? SSADM stands for Structured
Systems Analysis and Design Method. It is a
set of standards developed in the early 80s for
the stages of system analysis and application
design of system development. It is one of the
most mature and widely adopted structured
methods for government computer projects in the
United Kingdom. SSADM uses a combination of
text and diagrams throughout the whole life
cycle of a system design, from the initial design
idea to the actual physical design of the
application.
28

• Advantages of Structured Methods
• Structured methods have the following
  characteristics
• It provides a clear requirements statement that
  everyone can understand and forms a firm
  foundation for subsequent design and
  implementation
• More effective use of experience and
  inexperienced staff
• Improved project planning and control
• Better quality systems

29
SSADM uses a prescriptive approach to achieve the
advantages mentioned above, specifying in
advance the modules, stages, and tasks which
have to be carried out, the deliverables to be
produced, and the techniques used to produce the
deliverables. SSADM adopts the Waterfall model
of systems development, where each phase has to
be completed and signed off before subsequent
phases can begin.
30
Strength of SSADM SSADM builds each step on the
work that was prescribed in the previous step
with no deviation from the model. Because of the
rigid structure of the methodology, SSADM is
praised for its control over projects and its
ability to develop better quality systems.
31
Weakness of SSADM However, it requires a
significant investment in training and learning
curves. Moreover, it does not cover the
construction, testing and implementation of
software.
32
Basic Principles of SSADM SSADM is a data-driven
method that there is a basic assumption when
employing this methodology. It assumes that a
system has an underlying and generic data
structure which changes very little over time,
although processing requirements may change.
This underlying data structure is modeled from
an early stage. The representation of this data
structure is checked against the processing and
reporting requirements and finally built into
the architecture of a system.
33

• The structured techniques of SSADM fit into a
• framework of steps, stages and tasks, each with
  defined
• inputs and outputs. Moreover, there are a number
  of
• forms and documents that are specified which add
• information to that held within the diagrams.
• Therefore, SSADM consists of three important
  features
• Structures -- Define the frameworks of steps and
  stages and
• their inputs and outputs
• Techniques -- Define how the steps and tasks are
  performed
• Documentation -- Define how the products of the
  steps are
• presented.

34
Structures of SSADM SSADM application development
projects are divided into five modules that are
further broken down into a hierarchy of stages,
steps and tasks 1. Feasibility Study -- the
business area is analyzed to determine whether a
system can cost effectively support the business
requirements. 2. Requirements Analysis -- the
requirements of the system to be developed are
identified and the current business environment
is modeled in terms of the processes carried out
and the data structures involved. 3.
Requirements Specification -- detailed functional
and non-functional requirements are identified
and new techniques are introduced to define the
required processing and data structures.
35
4. Logical System Specification -- technical
systems options are produced and the logical
design of update and enquiry processing and
system dialogues. 5. Physical Design -- a
physical database design and a set of program
specifications are created using the logical
system specification and technical system
specification.
36
The five modules can be further decomposed into
different stages Module 1 -- Feasibility Fea
sibility -- Stage 0 Module 2 -- Requirements
Analysis Investigation of Current System --
Stage 1 Business System Options -- Stage
2 Module 3 -- Requirements Specification Defin
ition of Requirements -- Stage 3 Module 4 --
Logical System Specification Technical System
Options -- Stage 4 Logical Design -- Stage
5 Module 5 -- Physical Design Physical
Design -- Stage 6
37
Stages of SSADM Module 1 -- Feasibility Study
The feasibility study consists of a single
stage (Stage 0 Feasibility), which involves
conducting a high level analysis of a business
area to determine whether a system can cost
effectively support the business requirements.
In stage 0 an overview DFD is produced together
with a high level LDS. At this stage the DFD will
represent the existing system warts and all and
the LDS may be incomplete and contain unresolved
MM relationships.
38
Module 2 -- Requirements Analysis Requirements
analysis consists of 2 stages -- Stage 1
Investigation of Current Environment Stage 2
Business System Options (BSO). During stage 1
the systems requirements are identified and the
current business environment is modeled in terms
of the processes carried out and the data
structures involved. DFDs and an LDS are used to
produce detailed logical models of the current
system. During stage 2 up to 6 business system
options are produced and presented. As a result,
one of these options (or indeed a hybrid
solution) is adopted and refined. DFDs and LDS
are produced to support each business system
option and the final chosen option. The
transition from stage 1 to stage 2 is a key part
of SSADM, this is where we move from a logical
model of the current system to a logical model
of the required system, i.e. this is where the
DFDs and LDS have to be refined to cater
new/changed requirements.
39
Module 3 -- Requirements Specification Requiremen
ts Specification consists of a single stage
(Stage 3 Definition of Requirements) which
involves further developing the work carried out
in module 2, detailed functional and
non-functional requirements are identified and
new techniques are introduced to define the
required processing and data structures. In
stage 3 the DFDs and LDS are refined and cross
validated in the light of the chosen business
system option. The LDS is enhanced using
relational data analysis (normalization). The
DFDs and LDS validated against the ELHs are also
produced during this stage. DFDs LDS and ELHs
are used as input to the subsequent stages of
SSADM.
40
Module 4 -- Logical System Specification Logical
System Specification consists of 2 stages
-- Stage 4 Technical System Options Stage 5
Logical Design. In stage 4, up to 6 technical
options specifying the development and
implementation environments are produced, and one
being selected. In stage 5 the logical design
of update and enquiry processing, and system
dialogues (menus etc.) is carried out.
41
Module 5 -- Physical Design Physical Design
consists of a single stage (Stage 6 Physical
Design) in which the logical system
specification and technical system specification
are used to create a physical database design
and a set of program specifications.
42
(No Transcript)
43
Techniques used by SSADM SSADM uses a
combination of three techniques Logical Data
Modeling -- the process of identifying, modeling
and documenting the data requirements of the
system being designed. The data is separated
into entities (things about which a business
needs to record information) and relationships
(the associations between the entities. Data
Flow Modeling -- the process of identifying,
modeling and documenting how data moves around
an information system. Data Flow Modeling
examines processes (activities that transform
data from one form to another), data stores (the
holding areas for data), external entities (what
sends data into a system or receives data from a
system, and data flows (routes by which data can
flow). Entity Behavior Modeling -- the process
of identifying, modeling and documenting the
events that affect each entity and the sequence
in which these events occur.
44

• Besides the three diagrammatic modeling
  techniques
• described above, there are some more techniques
  and
• procedures used including
• Relational data analysis
• First cut rules
• Physical design control
• Quality assurance
• Project estimating

45
Documentation Several different kinds of
document will be produced during a project such
as diagrams, forms, matrices, and narrative
reports. Working documents are produced as a
means of developing some of the diagrams. Other
documents are part of the formal documentation
standards of SSADM and are carried forward into
later steps of the project. In many cases
formal reports such as feasibility study reports
or full study reports will be required. Although
SSADM does not provide detailed recommendations
on the content or format of such reports as they
are often set by the organization, much of the
SSADM documentation including diagrams and forms
are needed to be integrated into these formal
reports.
46
Relationship between the Three Views It is a
very important principle of SSADM that the
different views of the system should be closely
related to one another. Each view is built up
separately and is then checked for consistency
and completeness by comparison with the other
views. The required system Data Flow Diagrams,
Logical Data Structure, and Entity Life
Histories are related to one another in defined
ways and can be checked against one another
before being signed off as correct. The
relationships described below focus on the rules
that apply in the required system definition
with some indication of how they can be used in
earlier stages.
47

• Relationship between Data Flow Diagrams and
• Logical Data Structures
• Logical Data Structures reflect the structure of
  stored data.
• A Data Flow Diagram shows data moving about the
  system and
• being stored in data stores.
• An Entity Description should be created to show
  all data items
• which are held and flow within the system.
• The rules that govern the relationship between
  the two views are
• Each data store should represent a whole number
  of entities
• Data items on data flows should belong to
  entities

48

• 1. Each data store should represent a whole
  number of entities
• A data store is related to one or more entities
• An entity may not appear in more than one data
  store
• However, there are two exceptions
• In the current system data is often duplicated.
  Therefore it is
• possible for an entity to appear in more than one
  data store.
• Transient data stores do not represent stored
  data and will
• therefore not be related to any entities on the
  Logical Data
• Structure.

49

• 2. Data items on data flows should belong to
  entities
• Another relationship between Data Flow Diagrams
  and the
• Logical Data Structures is in relating the data
  items flowing
• around a system to the data items attached to
  entities. This can
• be used when checking the data flow into and out
  of data stores
• to ensure that the data items denoted on the data
  flows appear in
• the Entity Descriptions relating to the data
  store.
• The only data items that may not appear on any
  Logical Data
• Structure are
• Transient items such as partial results
• Derived items for output from the system
• Moreover, some data flows may just have a label
  such as Error.
• It will not have any immediate relationship to
  the Logical Data
• Structure view.

50
(No Transcript)
51
An example showing the relationship between the
Data Flow Diagrams and Logical Data Structures
are displayed above A. The Customer and
Customer/Account Link entities relate to the
Customer Details data store B. The Bank
Account entity relates to the Bank Account data
store C. The Transaction entity relates to the
Bank Account data store D. The Bank Account
entity is described by a set of data items E.
The Balance data item on the Entity Description
relates to the Balance data item on the data
flow.
52

• Relationship between Logical Data Structures and
  Entity Life
• Histories
• An Entity Life Histories is constructed for each
  entity on the
• Required Logical Data Structure.
• The starting point for Entity Life Histories is
  the ELH matrix in
• which all entities from the Logical Data
  Structures are listed down
• on one side of the matrix and events added on the
  other side.
• The Entity Description and relationships to other
  entities are
• examined to ensure the completeness of the Entity
  Life History
• Each data item must be created, (possibly
  amended), and deleted by events on the Entity
  Life History
• Changes in relationships may be events that
  should be taken account of
• The Entity Life Histories is done be referring
  constantly to the Logical Data Structure and the
  supporting Entity Descriptions.

53
(No Transcript)
54
The relationships between the two diagrams
are A. An Entity Life history is dawn for each
entity on the Logical Data Structure. For
example, the Bank Account Entity Life History is
for the Bank Account entity on the Logical Data
Structure. B. In creating the entity, the event
New Customer and New Account will set a value
for the data item Date Opened. The data item
will not be updated by any subsequent event. C.
The deposit and Withdrawal events will update the
Balance data item each time they affect the Bank
Account entity.
55
Relationship between Entity Life Histories and
Data Flow Diagrams The events reflected in the
Entity Life Histories are triggers to the Data
Flow Diagram processes that update the system
data. Therefore, there should be some
indication of the events on the Data Flow
Diagrams. If the event is the arrival of input
data, then events can be directly related to
input data flows. If the events are not
associated with particular data flows, the
relationship between events and the data Flow
Diagrams are not so clear cut. However, each
process that updates a main data store must have
an event associated with it.
56

• In summary, the relationships between Entity Life
  Histories and
• Data Flow Diagrams are
• Each bottom level process on the Required System
  Data Flow Diagram that updates a main data store
  will be triggered by one or more events that
  appear on the Entity Life Histories.
• If an event is from an external source, it will
  probably be associated with an input data flow.
• If a process is triggered by something other than
  arrival of data, the event will not be shown
  explicitly on the Data Flow Diagram but can be
  inferred by inspection.

57
(No Transcript)
58
The relationships between Entity Life Histories
and Data Flow Diagrams A. The New Customer
event affecting the Bank account entity is
represented by the data flow from the Manager
external entity to Process 1. This was
identified as an event affecting this entity
because there is a data flow from the process to
the Bank Accounts data store, showing that an
entity is being updated. B. The Deposit and
Withdrawal events are related to the inputs to
Process 2. On closer inspection, several
different events may be identified by comparing
the Entity Life Histories and Data Flow Diagrams
as the input from the Employer will be a Pay
Deposit and the input from the Clerk will be a
Cash Deposit.
59
Summary Data Flow Diagram, Logical Data
Structure, and Entity Life History are all
related to each other in some way. It is very
important that the diagrams are consistent at all
times so that at any stage in a development
project the three views are showing different
aspects of the same thing.
60
Critique of SSADM

• The purpose of structured methodologies seems to
  have been
• to formalize the requirements elicitation process
  to reduce the
• chances of misunderstanding the requirements
• to introduce best practice techniques to the
  analysis and design
• process.
• SSADM (Structured Systems Analysis and Design
  Method) is a
• typical example of a structured methodology.
• It can reduce the chances of initial requirements
  being
• misunderstood and of the systems functionality
  straying from the
• requirements through the use of inadequate
  analysis and design
• techniques.

61
Critique of SSADM
However, SSADM assumes that the requirements (in
the form of an agreed requirements
specification) will not change during the
development of a project. Following each step
of SSADM rigorously can be time consuming and
there may be a considerable delay between
inception and delivery (which is typically the
first time the users see a working system).
The longer the development time the more chance
of the system meeting the requirements
specification but not satisfying the business
requirements at the time of delivery.
62
Reference http//www.webopedia.com/TERM/S/SSADM.h
tml http//www.comp.glam.ac.uk/pages/staff/tdhutc
hings/chapter4.html Ashworth, C. and Goodland,
M. (1998). SSADM A Practical Approach.
McGraw-Hill.
63
Assignment Grouping Max. number students of a
group 4 Max. number of groups in a tutorial
7