SYSTEMS DEVELOPMENT METHODOLOGIES WHAT IS A METHODOLOGY Procedures

SYSTEMS DEVELOPMENT METHODOLOGIES

WHAT IS A METHODOLOGY? Procedures + Techniques + Tools + Phases = Method + Philosophy = Methodology

WHAT IS A PHILOSOPHY? e. g. building a system that: - makes most use of computers or - is the cheapest to run or - is implemented earliest or - is the most adaptable or - is best liked by its users or etc.

WHY USE A METHODOLOGY? To introduce structure into design To increase the likelihood of success Previously: Problem - User - Programmer - Change - Create Problem - User - Programmer etc With Methodologies: Problem - Analysis - Design - Implementation - Success

EXAMPLES OF SYSTEMS DEVELOPMENT METHODOLOGIES 'Hard' Methodologies SSADM (Structured Systems Analysis and Design Methodology) STRADIS (Structured Analysis and Design) JSD (Jackson Structured Design) 'Soft' Methodologies ETHICS SSM (Soft Systems Methodology) Mix of 'hard' and 'soft' MULTIVIEW

SSADM (Structured Systems Analysis and Design Methodology) Features: Data Driven Detailed rules Comprehensive manuals For Covers all elements of life cycle Used by Civil Service It works! Against Overkill for small projects

Stages Analysis 1. Analysis of Current System 2. Specification of Required System 3. Technical Options Design 4. Detailed Data Design 5. Detailed Procedure Design 6. Physical Design Control

1. Analysis of Current System Identify bottlenecks/dissatisfaction Use interviews/questionnaires etc. Produce DFDs, LDSs Agree current system model with users

2. Specification of Required System Expand current system to include new requirements Include data and process aspects Include audit, security and controls Produce a consolidation of people's views

3. Technical Options Centralised vs. Distributed On. Line vs. Batch Response times Staffing level implications Other resource implications

4. Detailed Data Design Define data and data relationships Ensure data structure meets: Screen/Report requirements Processing requirements

5. Detailed Procedure Design Catalog all functions Check against data structure Perhaps prototype Check logical design meets requirements

6. Physical Design Control Produce plan for building/testing system Include program specs, operating procedures Consolidate documentation

STRADIS (Structured Analysis and Design) Features: Solution found from a number of possible modules and interfaces Uses a selection of tools and techniques For Suited to any size system Against More about defining the solution than the problem

Stages 1. Initial Study 2. Detailed Study 3. Define and Design Alternative Solutions 4. Physical Design

1. Initial Study Aim to select systems which will: Reduce costs Increase revenue Improve services Speak to users and managers Produce overview DFD Decide whether to progress to next stage

2. Detailed Study Identify users of new system Draw level 1 DFD Produce lower levels of DFD Produce process descriptions Produce detailed cost/benefit analysis

3. Define and Design Alternative Solutions Convert organisational objectives into system objectives (i. e. make them specific, not general) Produce level 1 DFD for new system Produce three alternative solutions: quick and cheap (some objectives met) longer and more costly (most met) longest and most expensive (all met)

4. Physical Design Produce all logic and error handling Produce data dictionary Produce report and screen formats Produce files/database Identify clerical tasks All down to a level where costs can be detailed

JSD (Jackson System Development) Features: Extension to JSP (Jackson Structured Programming) Transformation from program specification to implementation For Models a dynamic world Against Orientated towards software rather than organisational needs Several elements of life cycle missing e. g. requirements analysis user interface database design

Stages Entity Action step Entity Structure step Initial Model step Function step System Timing step Implementation step

Entity Action step Define entities that perform or suffer actions e. g. customer, supplier but by behaviour rather than relationship Traditional entity modelling = static JSD = dynamic

Entity Structure step Draw diagrams to show life history (Boxes) Initial Model step Create model to simulate entity activity (Pseudo-code) Function step Add necessary functions to produce output (e. g. account balance) System Timing step Add delays to reflect real world (e. g. user requirements, technical restrictions) Implementation step Allocate processors to processes

ETHICS (Effective Technical and Human Implementation of Computer-Based systems) Features: Adopts an ethical philosophy Technology + Social + Organisational Improved job satisfaction and working life Involves users in design decisions For Well accepted by users Against Treated with suspicion by management Users may not have necessary skills

STAGES Why Change System Boundaries Description on Existing System Definition of Key Objectives and Tasks Diagnosis of Efficiency Needs Diagnosis of Job Satisfaction Needs Future Analysis Specifying and Weighing Efficiency and Job Satisfaction Needs and Objectives Organisational Design of the New System Technical Options Preparation of A Detailed Work Design Implementation Evaluation

Why Change As the name implies, If not conclusive, then don't System Boundaries Consider effect upon the following areas: Business Activities Existing Technology Parts of the Organisation's environment Description of Existing System In terms of inputs, outputs and processes Definition of Key Objectives and Tasks Roles, Purposes, Responsibilities and Functions

Diagnosis of Efficiency Needs Identify weak links Diagnosis of Job Satisfaction Needs Standard Questionnaire Future Analysis Allow flexibility for enhancements etc

Specifying and Weighing Efficiency and Job Satisfaction Needs and Objectives Key step Produce objectives based on previous steps Rank these into primary and secondary All primary objectives must be met As many as possible secondary should be met

Organisational Design of the New System Identify operating activities Identify coordination activities Identify development activities Identify control activities Identify special skills required Identify key roles or relationships

Technical Options Evaluate options for software, hardware, HCI in terms of efficiency, job satisfaction and future change. The Preparation of a Detailed Work Design the system in detail Identify data flows, tasks, groups etc Ensure objectives are still being met

Implementation Plan implementation in detail Strategy Education and Training Co-ordination Evaluation Check Objectives met

SSM (Soft Systems Methodology) Philosophy: A System is more than the sum of its parts Models of data and processes are simple, Involve people and they become ill-defined or 'fuzzy‘ For Deals with the real world Against Too much analysis, not enough design

Stages Produce rich picture Include clients, participants and tasks Identify CATWOE: C lient - beneficiary or victim A ctor - agent of change T ransformation - the change taking place W orld view (Weltanschauung) - assumptions O wner - the sponsor E nvironment - the wider system

MULTIVIEW Features Mix of hard and soft For Best of both worlds Against Hotch-Potch of techniques

Stages Analysis of human activity systems Look at organisation, its purpose and problems Information modelling Analyse entities and functions Analysis and design of the socio-technical system Consider people, needs, working environment Design of the Human-Computer Interface Command, Form, Menu, Icon/Mouse, Natural Language? Design of the technical sub-systems Combine Entity model and Technical requirements

Outputs are: Applications - processes Information - produced Database - used Control - error checking Recovery - repairing mistakes Monitoring - keeping track for management