Download aspects of analysis (from context to specification)

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