SYSTEMS DEVELOPMENT METHODOLOGIES

1. SYSTEMS DEVELOPMENT METHODOLOGIES

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

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

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

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

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

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

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

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

10. 3. Technical Options Centralised vs. Distributed OnLine vs. Batch Response times Staffing level implications Other resource implications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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