IMS 3230 — Information Systems Development Practices Blended

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

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 1970 s 2

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 3

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 4

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 5

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

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 7

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 8

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 9

SSADM version 4: Requirements Analysis 1 Investigation of current environment § § § 2 § § 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 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. 10

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 11

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

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 13

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 14

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 15

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