44222: Information Systems Development

1. 44222: Information Systems Development Dynamic Systems Development Method Ian Perry Room: C49 Extension: 7287 E-mail: I.P.Perry@hull.ac.uk http://itsy.co.uk/ac/0506/Sem1/44222_ISD/

2. Traditional Systems Development • Systems Development Life Cycle • (Anderson R G, 1989) • Define Development Strategy • Systems Analysis • Systems Design • Systems Development • System and User Documentation • System Implementation • System Testing • System Maintenance

3. Structured Systems-Development

4. 4 Logical Data Design 2 Specification Of Requirements 3 Selection of Technical Options 6 Physical Design Systems Design Specification 1 Analysis Requirements Specification 5 Logical Process Design Feasibility Study Report Information Systems in Business Harry M Pitman Publishing 1994. ‘Classic’ SSADMStructured Systems Analysis & Design Method

5. Problems with these Approaches? • Nothing! • If you have a well defined problem that can be solved by a sequential process with a fixed number of separate stages. • But! • What if the Users are not exactly sure of what they want the system to do? • What if the Implementors mis-interpretwhat the Users have asked for? • What if the system needs to be delivered within a short timescale?

6. Dynamic Systems Development Methodhttp://www.dsdm.org/ • What is DSDM? • The Dynamic Systems Development Method (DSDM) is a framework of controls for the development of Computer-based systems • It is independent of any particular set of tools and techniques. • It can be applied to Information Systems Development projects of any size. • Is especially good for Information Systems Development projects with very short deadlines.

7. DSDM - Continued • The lifecycle which DSDM uses is BOTH ‘iterative’ and ‘incremental’. • A move away from traditional systems development is essential if IT solution providers are to deliver working systems in the ever decreasing timescales demanded by businesses today. • Even within a traditional systems development environment, advantage can be gained from using components of the DSDM approach: • to ensure the right requirements are addressed. • to reduce the time to delivery.

8. When to use DSDM? • The application should have its functionality reasonably visible through the user interface (screens, reports, etc.): • to enable prototyping to be used to maximum benefit. • The project should be able to identify all of those who will use the end result: • these "Ambassador users" should participate throughout the life of the project providing a two-way communication channel between the business community and the IT community. • If the system is large, it should be able to be broken down into smaller components: • either for incremental delivery or for development by parallel teams.

9. DSDM Principles - A Summary • Active user involvement is imperative. • DSDM teams must be empowered to make decisions. • The focus is on frequent delivery of products. • Fitness for business purpose is the essential criterion for acceptance of deliverables. • Iterative and incremental development is necessary to converge on an accurate business solution. • All changes during development are reversible. • A collaborative and co-operative approach between all stakeholders is essential. • Testing is integrated throughout the life-cycle.

10. The ‘five’ Phases of DSDM • DSDM provides a generic process which must be tailored for use in a particular organisation dependent on the business and technical constraints. • DSDM outlines a five phase process: • feasibility study • business study • functional model iteration • design & build iteration • implementation

11. Feasibility Study • To assess the suitability of the application for a Rapid Application Development (RAD) approach. • To check that certain technical and managerial conditions are likely to be met. • The feasibility study typically lasts a matter of weeks (rather than months).

12. Business Study • To ‘scope’ the overall activity of the project and provide a sound business and technical basis for all future work. • the high-level functional and non-functional requirements are baselined. • a high-level model of the business functionality and information requirements is produced. • the system architecture is outlined. • and the maintainability objectives are agreed. • Like the feasibility study, the business study is a short phase, of no more than a month.

13. Functional Model Iteration • Prototyping to elicit requirements through demonstration and feedback. • Prototypes are built incrementally towards the tested system which is placed in the user environment during the implementation phase. • All prototypes in DSDM are intended to evolve into the final system and are therefore built to be robust enough for operational use & to satisfy any relevant non-functional requirements, such as performance. • The completed functional model will consist of all necessary high level analysis models and documentation supported by functional prototypes addressing detailed process & usability.

14. Design & Build Iteration • Ensuring that prototypes are sufficiently well engineered for use an operational environment. • The dividing line between Functional Model and Design & Build is not clear cut. • Some components of a system may well pass from the Functional Model Iteration to the Design & Build Iteration while other components are still very sketchy or even non-existent. • i.e. Design & Build activities may happen concurrently with the Functional Model activities. • Similarly, in very large DSDM projects, the actual implementation may be phased, so Design & Build may be concurrent with some of the Implementation.

15. Implementation • Put the latest increment into the operational environment, train the users, and review what has been achieved. • 4 four possible outcomes: • Everything delivered; no need for further development. • New functional area discovered during development; development returns to the Business Study phase and the whole process is worked through. • A less essential part of the functionality was missed out due to time constraints; development returns to the start of the Functional Model Iteration and adds the functionality to the delivered system. • A non-functional requirement was not satisfied as it well as it would have been, given more time; development returns to the Design & Build Iteration to rectify this.

16. Feasibility Study • RAD approach suitable? Business Study Functional Model Iteration Implementation • High level Requirements • Agree Plan • Identify Functional Prototype • Create Functional Prototype • Review Prototype • Implement • Train Users • User Approval • Review Business Design & Build Iteration • Agree Plan • Identify Design Prototypes • Create Design Prototypes • Review Design Prototypes The DSDM Lifecycle

17. How is DSDM Different? • Traditional approaches: • fix requirements, BUT allow time and resources to vary during development. • For DSDM; • time is fixed, resources are fixed as far as possible, BUT requirements are allowed to change. • A very important product of the Business Study is: • a clear prioritisation of the high-level functional and non-functional requirements. • DSDM projects guarantee to satisfy at least a minimum subset of these requirements.

18. DSDM & the HCHE Project • Time & Resources are fixed: • Deadlines & Teams. • Requirements might change: • Read the ‘HCHE’ Case Study carefully. • Use the Interviews with “ambassador users” to confirm requirements. • DSDM matched to ISD Assignments: • Business Study = Problem Statement • Functional Model = Prototype Documentation • Design & Build = Prototype (for use in documentation)