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

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

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

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

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

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)

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

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

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

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.

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

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.

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

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

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

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