Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
IMS1805 Systems Analysis Topic 6: Analysis as a process within a process www.monash.edu.au 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 www.monash.edu.au 2 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 www.monash.edu.au 3 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 www.monash.edu.au 4 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 www.monash.edu.au 5 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 www.monash.edu.au 6 (a) The classical ‘waterfall’ model of systems development • 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” www.monash.edu.au 7 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 www.monash.edu.au 8 (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” www.monash.edu.au 9 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 www.monash.edu.au 10 (c) Iterative approaches to systems development • Aim to cycle through the development phases several times, enhancing the system each time Feasibility Analysis Construction Implementation Design • 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” www.monash.edu.au 11 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 www.monash.edu.au 12 (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?” www.monash.edu.au 13 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 www.monash.edu.au 14 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 www.monash.edu.au 15