SSADM:
Structured Systems Analysis
and Design Methodology
"the successor to the Conventional approach"
but with more rigour: clearer guidelines and tighter rules to follow
Developed by:
Learmonth & Burchett Management Systems
Central Computing and the Telecommunications Agency
who were the main UK Civil Service training provider
Reference: Goodland & Slater (1995)
There is frequent use of Diagrams!
Three views of the system
| Data flow diagrams |
show how information is passed around |
| Entity Relationship Models |
show what information is stored
and how it is inter-related |
| Entity Life Histories |
show how information is changed
during its lifetime |
The objective during development
using SSADM is to always use these 3 views – and make sure they are inter-related
LDS = Logical Data Structure = end
product of Entity Relationship Modelling
LDS – DFD
relationship
An LDS shows entities stored in the
system
-
Each entity will have a set of attributes
and these attributes may well appear as names ("labels") on data flows
– especially those flows into and out of data stores
-
Entities and data stores represent stored
data
-
An
entity is a grouping of related attributes
-
By
the principle of avoiding redundancy, an entity should not appear in more
than one data store i.e. you should not encounter an entity split across
different data stores
-
A
data store cannot be made up of less than one entity
-
Data
stores may be made up of more than one entity
However
-
The above may NOT apply in the current
system, where DUPLICATION of data has occurred
LDS – ELH relationship
-
Each entity in the LDS requires a life
history diagram
-
For each attribute of an entity there
must be some event which creates it
-
Equally, the must some event which can
delete it
-
There are possibly (but not definitely)
events which amend those attribute values
-
Drawing the life history of each entity
ensures that all events that are likely to occur will be reflected in the
data
-
What these relationships are can be
obtained using an entity/event matrix
SSADM - unlike the
Conventional Approach is DATA driven
Works
on the Assumptions:
-
business methods
change often
-
IS processes will
need to reflect changes
-
underlying data
in the system changes very little
Modelling
the data is at the core of SSADM
Data
modelling begins very early in the development of an IS
Representation
of the data is checked against
-
processing
-
reporting requirements
before being built into the system’s architecture
SSADM is an analysis and
design methodology
There is no:
-
Implementation
-
Maintenance
-
Testing
-
Review
of the Conventional
Approach
SSADM modules and stages:
Feasibility
Study
0
Feasibility
-
Prepare for the
feasibility study
-
Define the problem
-
Select feasibility
options
-
Create feasibility
report
Requirements
Analysis
1 Investigation
of Current Environment
-
Establish analysis
framework
-
Investigate and
define requirements
-
Investigate current
processing
-
Investigate current
data
-
Derive logical
view of current services
-
Assemble investigate
results
2
Business
system options
-
Define business
system options
-
Select business
system options
-
Define requirements
Requirements
Specification
3
Definition
of Requirements
-
Define required
system processing
-
Develop required
data model
-
Derive system
functions
-
Enhance required
data model
-
Develop specification
prototypes
-
Develop processing
specification
-
Confirm system
objectives
-
Assemble requirements
specification
Logical
System Specification
4
Technical
system options
-
Define technical
system options
-
Select technical
system options
-
Define physical
design module
5
Logical Design
-
Define user dialogues
-
Define update
processes
-
Define enquiry
process
-
Assemble logical
design
Physical
Design
6
Physical
design
-
Prepare for physical
design
-
Create physical
data design
-
Create function
component implementation map
-
Optimise physical
data design
-
Complete function
specification
-
Consolidate process
data interface
-
Assemble physical
design
|
Feasibility
Study
|
Requirements
Analysis
| Stage 1 |
Investigate Current
Environment |
| Stage 2 |
Business Systems
Options |
|
Requirements Specification
| Stage 3 |
Definition of
Requirements |
|
Logical Systems Specification
| Stage 4 |
Technical System
Options |
|
Physical Design
|
|
|
|
| SSADM makes use of phases (stages)
and sub-phases, all precisely detailed. |
|
| This allows project management tools
to be used alongside the methodology. |
|
In recent versions the emphasis
on data has been balanced by focussing
more on the users needs. |
|
A feasibility
study is usually NOT included: there is an underlying assumption that the
project needs to go ahead.
Analysis is separated from design:
aids
elimination of ‘paralysis by analysis’:
a
wealth of information on the current system can overwhelm the systems analysis
team and could influence design of the new
system
but:
user requirements should be paramount
Essentially the 6 phases of SSADM cover:
| Systems Investigation |
| Systems Analysis |
|
Without a feasibility study there
is increased emphasis in:
-
Investigate
and define requirements sub-phase of Investigation of Current
Environment stage
-
Define requirements
sub-phase of Business System Options stage
order to determine tto
define how the IS will be achieved
Entity Life Histories
Why we need 3 views – why we need
ELHs:
DFDs - do not show
any sequencing, iteration or timing of events
Does a customer
place an order before receiving the details of card designs?
LDS - shows relationships between data objects
Does not show anything about system processes i.e.
no information about sequence or iteration
This is provided
by ELHs
Essentially a diagrammatic technique
which provides a picture of all possible outcomes for a particular entity
in the system:
In Just-A-Line (current) system:
CUSTOMER entity
-
Creation - each time a customer
places an order
-
Amendment - if the customer's details
change during the life of the order
-
Deletion - when the order is
delivered or when it is cancelled
Examples:
Entity Life Histories
Scenario:
A student wishing to enter University
starts off by applying – an applicant. On receipt of the application the
admissions tutor can make the applicant an offer or reject the applicant.
The offer to the applicant may be unconditional or conditional of examination
performance. An accepted student, whether conditional or unconditional,
may withdraw their application at any time.
Accepted students start their course
and become registered. They may or may not graduate. Registered students
may suspend studies for ill-health etc. and may return to graduate or else
leave non-graduated.
Sequence:
Selection:
Iteration:
Together:
The Software Development Life
Cycle
This is essentially:
The
waterfall model
-
The waterfall model of the software development process is
within the same paradigm as the traditional life cycle description
-
The development process is seen as being made up of a series
of distinct phases, or stages, each of which can be completed, and 'signed
off'
-
Typically the completion of a stage is marked by the submission
of a set of defined deliverables
Iteration within the Waterfall
model
A major problem with
software design is the need for iteration - typically required for, and
a result of, verification and validation (described in Boehm, 1981,
quoted by Somerville):
-
"Verification:
'Are we building the product right?'
-
Validation:
'Are we building the right product?"
Asking these questions
at the end of each development phase may result in a decision to repeat
(iterate) the phase and sometimes require a reworking of a previous phase
Iteration can be included
within the waterfall model, but tends to reduce the manageability of a
project. To deal with this, a strategy is used whereby a phase is 'frozen'
after a specified number of iterations.
Problems with this approach:
-
No "real" specification so no verification is possible
-
Maintenance likely to be difficult and costly because of
lack of documentation and multiplicity of changes from initial proposal
-
Many alterations likely, engendering ill-defined structure
-
Typically requires highly skilled practictioners
However, some classes of system need this approach, particularly
where the final system is "proposed", rather than specified
| Artificial intelligence |
| Scientific experimentation |
A prototype is:
An original or model, after which anything is formed
The first thing, or being, of its kind
A pattern, exemplar, or archetype
Websters 20th Century Dictionary
Prototyping in systems development is the process of creating
a "cut-down" version, or part of a system so that users can:
-
Get an idea of what the system will offer; and
-
Provide feedback on whether the system is what is required
| Prototyping helps to identify misunderstandings |
|
between users &
software developers
|
Advantages of prototyping:
-
Identification of misunderstandings between users and developers
-
Detection of missing user services
-
Identification of difficult-to-use or confusing user services
-
Requirements validation aid (discovering inconsistencies)
-
Early availability of a working (limited) system
-
May serve as a basis for specification for a "production
quality" system
Possible Dangers of prototyping:
-
Users may not give up prototype
-
Prototype may become basis of implementation (but lacks safety-critical
features)
-
May be used as a basis for contract with software engineers
- "please build one like this"
-
Non-functional requirements cannot be adequately expressed
-
Omission of functions in prototype may mean prototype not
used in same way as fully operational system
-
AND may encourage inadequate problem analysis
-
OR falsely indicate that system will work, but in fact does
not when loaded with real data or large volumes of data
-
May be an unacceptably large proportion of the total cost
of the system development
Key benefits of SSADM:
-
Teachable
-
Effective use of both experienced
and inexperienced staff
-
Great resilience against loss of
key staff
-
Improved involvement of end user
over Conventional Approach
-
Earlier/better validation of stages
of analysis and design
-
More complete and less ambiguous
specifications
-
More maintainable systems
-
Improved management control of systems
development
Management control of SSADM:
PRINCE
PRojects IN a Controlled Environment
Principle = decomposition
PRINCE components:
-
Organization
-
Products
-
Plans
-
Controls
-
Activities
Activities:
Project control techniques break
down large and complex projects into:
The work breakdown structure
Then:
-
time and resouce requirement is assigned
to each
done largely by
experience of similar activities in past projects
Then:
-
inter-relationships = dependencies
established
All these can be entered to a project
control (CASE) tool that will draw up a network diagram
Using the "activity on the node"
diagrammatic technique:
Activities
on Critical Path
From a network diagram
Gantt charts
Estimating:
-
some form is necessary at the beginning
of the project (need to decide if it really is worthwhile) – likely to
be inaccurate
-
scope of project not known
-
requirements may change
-
unforeseen problems may arise
-
skills and technology may change
-
as project progresses estimates are
likely (=should) get progressively more accurate
Initial estimates:
-
top-down – reliance on experience of
project manager or professional, organisational estimator –looks at the
whole project
-
size of the application
-
technology employed
-
development team
-
project manager will then consider:
and work backwards, using the resources
allocated so far
Can it be done with these guesstimates?
Refined Estimates
-
probably later in the project, take a bottom-up approach
-
break project down to low-level activities
-
estimate the effort each activity is likely to need
Function Point Analysis
-
the "scientific" approach
-
function points map very closely to SSADM events and enquiries
– "logical transactions"
-
function point size is based on
-
number of input data items
-
number of output data items
-
number of different entity types navigated in the transaction
-
FPA calculates size of the system:
-
Number of unadjusted function points
-
Adjust these by size = technical complexity of each
-
From this amount of effort required in the project is calc’d:
-
Project size ¸Productivity
-
Productivity:
-
Person hours per function point – based on previous projects