1. www.monash.edu.au IMS1805 Systems Analysis Topic 6: Analysis as a process within a process

2. www.monash.edu.au 2 Agenda Aim: To examine the place of analysis within the system development process To illustrate how the nature of development affects the content and approach to analysis

3. www.monash.edu.au 3 1. Analysis as an activity: Recap Elements of analysis (from early lectures) Observation Perception Explanation Representation Variations in the scope and depth of these elements Changing the focus of analysis to suit the circumstances

4. www.monash.edu.au 4 Analysis as the source of understanding Analysis as a ‘big picture’ process – providing a ‘sketch’ or framework within which more precise details can be filled out Elements of the ‘big picture’ analysis: The context of the system overall The main system components and the context in which they operate The key elements of each system component

5. www.monash.edu.au 5 Analysis as the source of a specification Analysis as a specification for design and construction – provides a detailed statement of what is required for each system component Elements of the detailed specification analysis: The precise requirements for each system element The inter-relationships/connections between system elements The standards for testing and validating system elements

6. www.monash.edu.au 6 2.Analysis as a component of a systems development activity Systems development as an activity The engineering approach to development and construction Key development phases: Feasibility: Decide if/how development should be done Analysis: Decide WHAT it is that has to be built Design: Decide exactly HOW it should look Construction: Build it Implementation: Install it and start using it Varying the engineering model of development

7. www.monash.edu.au 7 Sequential phases of development: Feasibility study Analysis Design Construction Implementation Each phase is separate and distinct from the others Each phase must be completed before the next phase can begin Motto: “Until you can specify exactly what you want, you don’t know what to build” (a) The classical ‘waterfall’ model of systems development

8. www.monash.edu.au 8 Analysis in the ‘waterfall’ model Begins with a clear outline of what needs to be analysed Ends with a clear and complete specification of what has to be designed and then built Output = the ‘Systems Requirements Specification’ All aspects of analysis (from context to specification) for all system components are completed within the one development phase Analysis can be treated as a ‘once-off’ activity independent of other phases

9. www.monash.edu.au 9 (b) Prototyping approaches to systems development Aim to start by constructing prototype system elements to help clarify feasibility, analysis and design phases Preliminary analysis, design and construction Feasibility Analysis Design Construction Implementation Prototypes (working models) are needed to help clarify requirements Throw away the prototype when you are ready to start building the real thing Motto: “Until you have seen and used something (even if only a prototype), it’s hard to know what you want”

10. www.monash.edu.au 10 Analysis in prototyping development approaches Analysis can only begin from an initial user (and developer) experience of a working model Two phases of analysis: one relating to prototype, and one relating to the final product development Output of prototype phase = a clearer picture of what is possible and what is required Analysis for context/understanding is carried out in the development of the prototype Analysis for specification is carried out in the ‘normal’ development process

11. www.monash.edu.au 11 (c) Iterative approaches to systems development Aim to cycle through the development phases several times, enhancing the system each time Evolution enable ‘continuous improvement’ The ‘best bits’ of each iteration can be used next time around Motto: “The more often you do it, the better will be the end product” Analysis Design Feasibility Construction Implementation

12. www.monash.edu.au 12 Analysis in the iterative approaches to development Full and complete analysis of system requirements is not realistic – continuous evolution of needs Analysis aims to develop framework within which system can be further developed and expanded over time Analysis provides specification of elements only for the system components planned for this iteration Analysis learns from experiences of development phases in earlier iterations – ie all development phases contribute to one another on an on-going basis

13. www.monash.edu.au 13 (d) Packaged approaches to systems development System is not constructed from scratch, but is built around pre-packaged software; often customised to suit organisational needs Development life-cycle now eliminates or drastically reduces software analysis, design and construction phases Replaced by phases for analysis/evaluation of competing packages, selection of most suitable, and assessment of customisation options Motto: “Why build when you can buy it off the shelf?”

14. www.monash.edu.au 14 Analysis in the iterative approaches to development Analysis is as much about understanding what a package can do as it is about what a user needs Organisational focus of analysis may be mainly about understanding how work practices need to change to accommodate the package Specification of system elements is often not required – package has already done it! Extent of customisation needs and capabilities will determine how much ‘traditional’ analysis and specification is required

15. www.monash.edu.au 15 The Exam General comments about exams (and my approach to them) Structure Comparison with last year Content: The nature of analysis Analysis for information systems System modelling techniques Reading and understanding models Cross-connecting between models Writing/creating models Some points on revision and examination technique