Structured Systems Analysis and Design Method SSADM

1
IMS5006 - Information Systems Development
Practices

• Structured Systems Analysis and Design Method
  (SSADM)
• Information Engineering

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
  development
• essentially a linear process
• users know their current and future needs
• conceptual descriptions can be complete
• in the early lifecycle stages, system structure
  is more important than system behaviour
• specification techniques should be simple and
  graphical for users to understand easily

5
Structured Systems Analysis and Design Method
(SSADM)

• assumptions about information systems, systems
  development and the system developers 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

6
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

7
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)

8
SSADM

• highly structured
• facilitates project management
• documentation pervades SSADM
• e.g. completion of preprinted forms
• stages and their activities are precisely defined
  as are their associated deliverables

9
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

10
SSADM phases

• earlier version - Downs, Clare and Coe 1988
  three phases
• 1. feasibility study
• examine the business and technical
  feasibility of the project
• 2. systems analysis
• analyse the current system and problems,
  identify new requirements and technical
  options
• 3. systems design
• logical data and process design, physical design

11
SSADM phases and stages

• 1. feasibility study
• stage 01 problem definition
• stage 02 project identification
• 2. systems analysis
• stage 1 analysis of systems operations
  current problems
• stage 2 specification of requirements
• stage 3 selection of technical options
• 3. systems design
• stage 4 data design
• stage 5 process design
• stage 6 physical design (Downs et al
  1988)

12
SSADM

• characteristics Downs, Clare and Coe 1998
• hierarchical structure
• phases, stages, steps, tasks, techniques
• data driven design
• cross-checking
• separation of logical and physical
• tailorable
• user communication
• quality assurance
• documentation standards

13
SSADM techniques

• Downs, Clare and Coe 1988
• data flow diagrams
• logical data structuring (LDST)
• entity life histories
• dialogue design
• relational data analysis (RDA)
• composite logical data design (CLDD)
• process outlines
• system flow charts

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 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

16
SSADM version 4 Feasibility Study

• ensure the project identified in planning phase
  is feasible
• ( technically possible) and benefits gt 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

17
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.

18
SSADM version 4Requirements 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

19
SSADM version 4Logical 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.

20
SSADM version 4Physical 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

21
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

22
Information Engineering

• Martin and Finkelstein (1981), Martin (1989),
  several versions
• data oriented methodology
• full lifecycle coverage
• organisation-wide perspective on planning of
  information technology and information systems
• top-down analysis and development of
  organisations applications
• focus on data and activities
• well-supported by CASE tools e.g. IEW, IEF
• has evolved
• widely used

23
Information Engineering

• evolution
• data base technology
• data analysis and data management
• strategic data models, procedure formation
• 4GLs and productivity tools, e.g. code
  generators
• alignment of information systems planning with
  strategic business planning
• process modelling techniques
• CASE technology, encyclopedia, knowledge
  coordinator
• RAD (Rapid Application Development)
• object-oriented concepts

24
Information Engineering

• data centred
• model data requirements first, processes later
• (data is more stable)
• applications will be integrated by a common data
  framework
• information engineering
• an interlocking set of formal techniques in
  which enterprise models, data models and process
  models are built... and are used to create and
  maintain data processing systems
• James
  Martin (1986)
• use of diagrams as a communication and
  representation tool

25
Major phases of Information Engineering

• information strategy planning
• to build an information and technology
  architecture to support business strategy and
  objectives
• business area analysis
• to identify data and function requirements of
  each business area
• individual systems planning
• systems design
• to complete logical specifications for a system
  and convert these into physical design
  specifications
• construction
• to generate code, test, and install the system
• cutover

26
Phase 1 - information strategy planning

• corporate management and planners assess the
  organisation
• business mission, objectives, CSFs, performance
  measurements, organisation structure, current
  situation
• construct corporate data model
• determine major business functions
• identify business areas, including goals and CSFs
• determine
• information architecture (global entities and
  business areas)
• information systems architecture (business
  sytems)
• technical architecture (technology hw/sw/comms)
• information strategy plan (priorities)

27
Phase 2 - business area analysis

• identify and model in detail the fundamental data
  and activities required to support a business
  area
• ensure that requirements are independent of
  technology
• ensure that requirements are independent of
  current systems and procedures
• ensure that requirements enable business areas
  goals and CSFs to be supported
• ensure that requirements are independent of the
  current organisational structure
• a high-level executive sponsor is necessary

28
Business area analysis steps

• extract the relevant entity relationship model
  and business-function decomposition models
• identify relevant departments, locations,
  business goals, CSFs
• create a preliminary data model identify events,
  entity life cycles, initial attributes
• create a preliminary process model decompose the
  functions into processes
• model data and processes of existing systems for
  comparison
• involve all affected end-users in iteratively
  building
• a detailed data model, a detailed process model,
  entity / process matrices
• identify and prioritise system development
  projects

29
Business area analysis techniques

• data model
• entity relationship modelling
• attribute collection
• normalisation
• canonical synthesis
• process model
• process decomposition models
• process dependency diagrams
• data and activity interaction
• entity lifecycles
• process / entity matrix

30
Information engineering phases 3 and 4

• Phase 3 - individual systems planning
• use JRP for individual systems planning
• Phase 4 - system design
• concerned with how selected processes in the
  business are implemented in procedures and how
  these procedures work
• use the logical data and process models to
  design the external representations of the system
• direct end-user involvement is essential
• identify reusable procedures
• use prototyping
• use JAD

31
System design techniques

• prototyping
• detailed process models procedure design using
  access path and volumes analysis, dialogue flows
  and menu structures,
• physical database design, file design,
• screen displays
• menu flows
• report layouts
• on-line procedures and software
• batch procedures and software
• design verification and testing

32
Information engineering phases 5 and 6

• Phase 5 - construction
• technical design, create physical databases
• create modules and programs, unit testing
• system testing, documentation
• Phase 6 - cutover
• conversion
• final testing
• conduct training
• install the system, review implementation

33
Information Engineering

• features
• organisation-wide perspective aligned with
  strategic business planning
• comprehensive
• emphasis on user involvement e.g. JAD, JRP
• evolves by incorporating new techniques,
  concepts, technologies e.g. RAD, object-oriented
  concepts
• evolves from practice e.g. shortened ISP phase
• emphasis on automation e.g. 4GLs, I-CASE,
  prototypes
• primarily for database transaction processing
  systems
• little event or behaviour modelling

34
Information Engineering

• features
• after ISP phase, activities can proceed in
  parallel
• high level data and process model (co-ordinating
  model) enables this by highlighting interfaces
  and dependencies between systems etc.
• flexible paths through the methodology
• e.g. reverse engineering and re-engineering

35
References

• Prescribed text
• Avison, D.E. Fitzgerald, G. (2003).
• Information Systems Development
• Methodologies, Techniques and Tools. (3rd ed),
  McGraw-Hill, London.
• Chapters 20.1, 20.3