IMS5006 - Information Systems Development Practices

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

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

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

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

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 organisation’s 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 area’s 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