2. Visualising Systems Paradigms
Models vary but there are
similarities. These
similarities fall into 3
specific areas:
• Methods – the
techniques used
• Tools - both automated
and semi automated
• Procedures - how the
process is managed
3. Structured Systems Analysis and
Design Methodology (SSADM)
• The most frequently used structured analysis methodology used in
the UK and it will be used during this course.
• Structured analysis focuses on what the system does rather than
how it does it.
• This means the emphasis is on the logical rather than the physical,
in other words it addresses what the system is meant to
accomplish.
• It is based on the assumption that the procedures of an
organisation are stable, that is they rarely vary, and that the data is
stored and used in a way that simply supports those procedures.
• The main characteristic of structured analysis is the top down,
functional decomposition of the system.
4. Systems Development Life Cycle
(SDLC)
• This approach is most appropriate to situations
where there are predictable Information Systems (IS)
requirements.
• This includes systems involving the entry of data
from input documents, often with high transaction
and processing volumes requiring validation of data
input.
• The SDLC stages can be clearly identified, scheduled,
monitored and controlled.
5. The Waterfall Model
This approach demands a
systemic, sequential
approach to software
development that
begins at system level
and progresses through
analysis, design, coding,
testing and
maintenance.
6. Problems with the Waterfall Model
1. Real projects rarely follow the sequential flow that the
model suggests; iteration always occurs and this creates
problems in the application of this method as it does not
allow any steps to be retraced, i.e. the designer can’t go
back to the analysis.
2. It is often difficult for the customer/user to state all their
requirements explicitly at the start of a project; the waterfall
model requires this and has difficulty allowing for the
uncertainty that exists at the beginning of many projects.
3. The customer must have patience because a working
version of the program will not appear until late in the
project.
7. Data Centred Approach
(Information Engineering)
• This approach takes the view that the structured analysis
approach produces a computer system that is rooted in the
past.
• In this approach data is regarded as a separate resource
within an organisation and processes become merely a means
of transforming it.
• The main problem with this approach is that it can often incur
a heavy front end loading, in terms of cost and time, before
results are produced.
• It’s adherents claim that once the front-end investment has
been made systems can be developed more rapidly than with
the structured approach.
8. Object-Oriented Approach (O-O)
• This methodology in some ways is similar to the data centred
approach in that it focuses on the data, however, it is also like
the structured analysis approach as it is also concerned with
what happens to the data.
• The main building block of the O-O approach is the object. An
object, in terms of the computer system development, is
something from the ‘real world’.
• Such objects also have properties, or attributes, that are of
interest to the developer of the system. These properties
relate to the data found in other approaches.
• An object is defined in programming terms as a unit that
packages together a set of data items and the knowledge of
how to manipulate that data.
9. Unified Modelling Language
Car
The “class” for this object
Engine size
Fuel capacity
No of passengers
Some of the attributes of
this object
Start ()
Stop ()
Forward ()
Reverse ()
Some of the operations that
this object can perform
10. Benefits of the O-O Approach
• More maintainable because the software is not based on the
existing functionality of the organisation.
• More reliable in terms of being able to re-use tested and
proven objects over and over again based on the fact that,
with only minor differences, a ‘car’ object in one system will
be the same as a ‘car; object in another system.
• More able to deal with the increasingly complex systems
required now and in the future; complex in terms of size and
in the new data types required, especially for Web based
applications where the traditional data types are unable to
cope with music and video images.
11. Prototyping
The “quick and dirty”
approach, the method used
when no method is used! It
is often overlooked as an
‘approach’ as such, being
considered to be a ‘poor
relation’ to the accepted
methodologies. However, it
has some undoubted
strengths and can be
considered as the Human
Computer Interface (HCI)
version of development.
Start
Stop
Requirements
gathering & refining
Engineer
product
Quick
design
Refine
prototype
Build
prototype
Customer
evaluation of
prototype
12. Soft Systems Methodology (SSM)
• The term ‘soft systems’ is used to distinguish this method
from the so-called ‘hard systems’ techniques that are used to
solve well defined technical problems. In simple terms, a
‘soft’ approach addresses the ‘what’ aspects of system
analysis and design while the ‘hard’ approach addresses the
‘how’ aspects of the problem.
• The strength of the SSM approach is that it focuses on some
real world situation perceived as problematic, such as where
the problem situation is unstructured, which is often the case
with large and complex organisations, or where user
requirements are unclear.
14. CATWOE?
•
C = Customers
Who is on the receiving end?
• A = Actors
Who are the actors who will 'do the doing', carrying out your solution?
• T = Transformation process
What is the process for transforming inputs into outputs?
• W = World View
What is the bigger picture into which the situation fits?
• O = Owner
Who is the real owner or owners of the process or situation you are
changing?
• E = Environmental constraints
What are the broader constraints that act on the situation and your ideas?