IMS3230 - Information Systems Development Practices

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