Slides week 3

3.1

Structured Systems Analysis and Design Method (SSADM);

Information Engineering

IMS5006 - Information Systems Development Practices

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

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

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


3.5

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


3.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: documentationself-checkingtried and tested techniques

tailorableteachable

3.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 emphasisedimportance 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)

3.8

SSADM highly structured

facilitates project management

documentation “pervades” SSADMe.g. completion of preprinted forms

stages and their activities are precisely defined as are their associated deliverables

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

3.10

SSADM phasesearlier version - Downs, Clare and Coe 1988: three phases1. feasibility study

examine the business and technical feasibility of the project

2. systems analysisanalyse the current system and problems, identify new requirements and technical options

3. systems designlogical data and process design, physical design

3.11

SSADM phases and stages1. feasibility study

stage 01: problem definitionstage 02: project identification

2. systems analysisstage 1: analysis of systems operations & current problemsstage 2: specification of requirementsstage 3: selection of technical options

3. systems designstage 4: data design stage 5: process designstage 6: physical design (Downs et al 1988)

3.12

SSADMcharacteristics 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

3.13

SSADM techniquesDowns, 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

3.14

SSADM: other SDLC phases construction and implementation:

output of physical design can interface with1. traditional programming (JSP)2. application generators3. 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 methodologye.g. LEAP developed by LBMS

3.15

SSADM: later versions version 4 - Avison and Fitzgerald 2003: five phases, seven stages

feasibility study0 Feasibilityrequirements analysis1 Investigation of current environment2 Business system optionsrequirements specification3 Definition of requirementslogical system specification4 Technical system options5 Logical designphysical design6 Physical design

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

3.17

SSADM version 4: Requirements Analysis1 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-examined2 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.

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

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

3.20

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

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

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

3.23

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


3.24

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


3.25

information strategy planningto build an information and technology architecture to support business strategy and objectives

business area analysisto 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

constructionto generate code, test, and install the system

cutover

Major phases of Information Engineering

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

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

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

3.29

Business area analysis: techniques data model

entity relationship modellingattribute collectionnormalisationcanonical synthesis

process modelprocess decomposition modelsprocess dependency diagrams

data and activity interactionentity lifecyclesprocess / entity matrix

3.30

Information engineering: phases 3 and 4

Phase 3 - individual systems planninguse 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 workuse the logical data and process models to design the external representations of the systemdirect end-user involvement is essentialidentify reusable proceduresuse prototypinguse JAD

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

3.32

Phase 5 - construction: technical design, create physical databasescreate modules and programs, unit testingsystem testing, documentation

Phase 6 - cutover:conversionfinal testingconduct traininginstall the system, review implementation

Information engineering: phases 5 and 6

3.33

Information Engineeringfeatures: 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

3.34

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


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