System Development Lifecycles: Building a House

1. Lecture 2 System Development Lifecycles

2. Building a house • Definition phase • Analysis phase • Design phase • Programming phase • System Test phase • Acceptance phase • Operation phase

3. Lifecycles • System Development Lifecycles • covers the whole life of a system • technical products • Project Lifecycles • delivery of a specified product • technical products, quality products, management products

4. Development Lifecycle Models • Waterfall Model • “b” Model • “V” Model • Incremental Model • Traditional Approach • Structured Method • SSADM • Spiral Model

5. Waterfall Model • Feature • a number of sequential stages • a degree of iteration of work and products within a stage • very little iteration between stages • rework is carried in succeeding stages

6. Waterfall Model • Advantage • sequencing of activities • quality management • verification • validation • configuration management

7. Waterfall Model • Disadvantage • planning, control and risk management are not covered • Application • requirements are well understood • not likely to undergo significant business change

8. “b” Model • Feature • variation of the waterfall model • it takes its name from its distinctive “b” shape • maintenance and enhancement shown as a series of cycles each of which follows the same general sequence as the original development • Advantage • maintenance phase is adequately covered

9. “V” Model • Feature • variation of the waterfall model • the successive stages are shown in a “V” format • shows correspondence between the different stages of the project

10. “V” Model • Advantage • demonstrates elements of quality assurance in its treatment of the correspondence • Application • development work being provided by external contracts

11. Incremental Model • Feature • variation of waterfall model • phased delivery • Advantage • delivery and testing more manageable • allowing familiarization with the changes

12. Incremental Model • Disadvantage • difficult to break the delivery of system down into phases • introduce overheads of integration • Application • total scope and definition of requirements must be completed before the increments are defined.

13. Spiral Model • Feature • an evolutionary or iterative approach to systems development • project starts at the center of the spiral and progress outwards • at the center, the requirements will be poorly understood and will be successively refined with each rotation around the spiral

14. Spiral Model • the total cost of the project will increase as the length of the spiral increases • four quadrants • top left quadrant • top right quadrant • bottom right quadrant • bottom left quadrant

15. Spiral Model • Advantage • objective setting, risk management & planning • Application • requirements are not well formed or understood by the users • difficult to specify the requirements • difficult to determine how a proposed solution will perform in practice

16. Traditional Approach • Feature • unstructured and non-specific • variations of the waterfall model • Advantage • analyst can use “intuitive” methods of working • limited demands on the user’s time • documentation was relatively easy to understand, being mostly in English

17. Traditional Approach • Disadvantage • lack of user involvement • poor quality • abdication of responsibility by the users and blame for the developers • use of text-based • ambiguous and misunderstanding • emphasis on how rather than what

18. Structured Methods • Feature • have largely taken over the traditional approach in the development of IS projects • offer a set of techniques and tools to carry out the systems development work within a defined framework

19. Structured Methods • Advantage • user involvement • separation of logical and physical • emphasis on data • diagrammatic documentation • defined structure

20. Structured Methods • Disadvantage • users and analysts/developers need to be trained to understand the documentation • amount of time required from users will be much increased • lead to increased level of documentation and therefore of bureaucracy • disastrous to assume that the method, rather than the analyst, will do the work

21. SSADM • Structured Systems Analysis and Design Method • Three basic views of an information system • what information is stored and how it is interrelated • Logical Data Structure • how information is passed around • Data Flow Diagrams • how information is changed during its lifetime • Entity Life Histories

22. SSADM • Combines techniques into a well-established framework, provide alternative views of a system that cross-check each other to ensure that an accurate and complete picture of the system is formed

23. Overview of SSADM • Information systems planning • strategic planning for the development of future and existing information systems • partial SSADM support • Project Initiation • project is set up, terms of reference agreed, team members assigned, and plans drawn up • full SSADM support

24. Overview of SSADM • Feasibility study • decided whether project is technically possible, whether it can be financially and socially justified, and whether the new system will be accepted by the organization • full SSADM support

25. Overview of SSADM • Systems analysis • Analyze the current system and determine the requirements for a new system • full SSADM support • Business systems design • Detailed logical design of the new system is developed in a non-technical way • full SSADM support

26. Overview of SSADM • Physical design • convert logical design to physical design that fits the computer hardware and software selected • full SSADM support • Construction • programming, the assembly of programs into a system and testing • partial SSADM support

27. Overview of SSADM • Transition • transition from operating the old system to operating the new • partial SSADM support • Production • completely handed over to the users • no SSADM support

28. Overview of SSADM • Maintenance and review • correction of errors, adaptation to new software and hardware releases, and minor enhancements • Partial SSADM support

29. Principles of SSADM • Structures • define the frameworks of steps and stages and their inputs and outputs • stage 1 : analysis of system operations and current problems • stage 2 : specification of requirements • stage 3 : selection of technical options • stage 4 : logical data design • stage 5 : logical process design • stage 6 : physical design

30. Principles of SSADM • Techniques • define how the steps and tasks are performed • diagrammatic techniques • Data Flow Diagrams • Logical Data Structures • Entity Life Histories • Logical Dialogue Design

31. Principles of SSADM • non-diagrammatic techniques • relational data analysis • first cut rules • physical design control • quality assurance • project estimating

32. Principles of SSADM • Documentation • defines how the products of the steps are presented • documents • diagrams • forms • matrices • narrative reports