1. IMS3230 - Information Systems Development Practices
Blended approaches:
Structured Systems Analysis and Design Method
(SSADM)

2. Structured Systems Analysis and Design Method (SSADM)
A comprehensive and structured approach to systems development
A “baseline” for comparison and evaluation of other methodologies and for themes in systems development
The true successor to the traditional SDLC approach with new techniques and tools developed since the 1970s

3. Structured Systems Analysis and Design Method (SSADM)
assumptions about information systems:
relatively stable
routine processing, well-defined interaction
free-standing, developed from "scratch"
globally defined data, processes
complete and objectively definable
information is well-structured

4. Structured Systems Analysis and Design Method (SSADM)
assumptions about information systems, systems development and the system developer’s roles:
system developer is the “expert” who has the technical knowledge to provide a solution
system developer “owns” the methodology and controls the development process
users have the business knowledge and must work with/support system developers as necessary to ensure requirements are met
users will own the system, must sign off

5. SSADM
developed by LBMS and Central Computing and Telecommunications Agency (CCTA) in the UK
accepted by CCTA in January 1981 as the standard approach within the UK civil service
requirements: documentation
self-checking
tried and tested techniques
tailorable
teachable

6. SSADM mature, widely used in UK in particular
typically medium to large projects
“data-driven” due to emphasis originally on data modelling and database technology
later versions are more balanced:
role of users emphasised
importance of processes and functions
version 4 in 1990
earlier version has 6 stages (Downs, Clare and Coe 1988)
version 4 has 7 stages (Avison and Fitzgerald 2003)

7. SSADM prescriptive reductionist comprehensive
has evolved with use: versions, CASE tool
templates e.g. micro SSADM, maintenance SSADM
SDLC phases: feasibility, systems analysis, system design
focus on functional and technical aspects

8. SSADM: later versions
version 4 - Avison and Fitzgerald 2003: five phases, seven stages
feasibility study
0 Feasibility
requirements analysis
1 Investigation of current environment
2 Business system options
requirements specification
3 Definition of requirements
logical system specification
4 Technical system options
5 Logical design
physical design
6 Physical design

9. SSADM version 4: Feasibility Study
ensure the project identified in planning phase is feasible
(= technically possible) and benefits > costs
prepare for the study (assess the scope)
define the problem (compare requirements with current situation)
identify and select feasibility option (consider broad alternatives in terms of business requirements and technical options)
produce feasibility report
techniques: interviewing, document review etc., broad DFDs and ER model

10. SSADM version 4: Requirements Analysis
1 Investigation of current environment
detailed physical DFDs and ER model of current processing and data,
logical DFDs, functional and non-functional “requirements catalogue”,
scope and feasibility study results re-examined
2 Business system options
cost-justified requirements only, determine and agree on functionality,
business options meeting minimum requirements: cost, technical constraints, development schedule, benefits and impact, training, etc.

11. SSADM version 4: Requirements Specification
3 Definition of requirements
logical data model (ER) extended,
attribute collection and normalisation,
DFDs extended,
full documentation of all data, processes and events,
entity life history diagrams,
prototyping can be used for important dialogues and menu structures

12. SSADM version 4: Logical System Specification
These stages occur in parallel:
4 Technical system options
environment in which system will operate - hardware, software, contraints (e.g. performance, security, service levels)
5 Logical design
design what the system is required to do
user involvement, refer to any prototypes, define dialogues and menu structures for specific user roles, ELHs used to define update and enquiry processing, data validation rules etc.

13. SSADM version 4: Physical Design
map the logical design onto a specific physical environment: functional component implementation map (FCIM)
6 Physical design
roles of the technologists stressed
users and analysts verify final design satisfies user requirements,
convert data model, specify programs, procedures etc.
specific activities depend on specific environment (system type, size, technical platform etc.
SSADM ends: subsequent activities build, test and install the system

14. SSADM: other SDLC phases
construction and implementation:
output of physical design can interface with
1. traditional programming (JSP)
2. application generators
3. application packages
prototyping can be used in design and construction
automated support tools are available
a project management methodology can be used
organisational IT/ IS planning:
use a planning methodology
e.g. LEAP developed by LBMS

15. SSADM
a structured approach: well-defined structure for its use, for training, and for managing projects
supported by CASE tools
clearly defined deliverables and quality review checkpoints
relies on availability of skilled personnel
systems development is about providing technical solutions to business problems

16. References Avison, D.E. & Fitzgerald, G. (2003).
Prescribed text:
Avison, D.E. & Fitzgerald, G. (2003).
Information Systems Development:
Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London.
Chapter 20.1
Refer to additional references in the readings at the unit web page and in the prescribed text