View
37
Download
0
Category
Preview:
DESCRIPTION
Structured Systems Analysis. What we will cover. System modelling generally What is a model? Why model a system A summary of modelling approaches. The System. System modelling generally. O u t p u t s. Source 1. Recipient 1. I n p u t s. And lo …. Source 2. Recipient 2. - PowerPoint PPT Presentation
Citation preview
Structured Systems Analysis
What we will cover System modelling generally What is a model? Why model a system A summary of modelling approaches
Slide 2 of 20
System modelling generally
Slide 3 of 20
I
n
p
u
t
s
Source 1
Source 3
Source 2
Recipient 1
Recipient 2
Recipient 3
The System
O
u
t
p
u
t
s
a miracle happens!
And lo …
What is a model? That was a model! An abstracted representation of something
that enables the identification of relevant elements, components and their inter-relationships
For example: An OS map of North Staffordshire A YHA map of North Staffordshire A cycling map of North Staffordshire A road map of North Staffordshire
All show the same territory, but …
Slide 4 of 20
Why model a system?
to find out what is and/or what should be going on
to allow system developers to understand and communicate with system users/sponsors
to provide a framework that handles complexity, allowing decomposition
it’s cheaper to model than to build enables “look ahead”
Slide 5 of 20
Why model a system? - summary Enables you to “go there” in your head
before you write any code things can be identified and sorted into the
important and the not-so-important problems can be identified (and possibly even
solved) early clarifies woolly ideas allows issues to be raised and discussed early facilitates more sensible decisions helps you to find out what you don’t know saves embarrassment later
Slide 6 of 20
Modelling/development approaches Object oriented approaches Structured approaches Collaborative approaches
RAD, Prototyping, DSDM …….
Agile approaches SCRUM, XP etc Today’s challenge – what does SCRUM stand
for? prizes next time
Other approaches
Slide 7 of 20
Structured modelling Separates the consideration of:
what a system does (or is to do) from the data and the (relational) data structures that are
required to enable it to do it Is all Edgar Codd’s fault (from 1970) Process modelling - covers the what Data modelling - covers the structure of the data
needed to support what is happening Time and Event modelling – cover things that
Process Modelling doesn’t do very well Structured modelling includes some useful
techniques that are generically applicable Slide 8 of 20
Process Modelling does what it says on the tin! for any information system, models
processes (at various levels of detail) participants data required/processed/stored/transmitted
pictures give framework for detailed descriptions
Slide 9 of 20
Data Modelling
Models the data required to enable a system to perform it’s defined functions (processes)
and how this data should be structured when persisting
Loads more of this later in the module This is an area which improved greatly with
practice and, at first, seems incomprehensible and impossible
Slide 10 of 20
Useful structured modelling tools and techniques Included here as they do not really fit
neatly into the process and/or data categories Aim of a system Levelling Problem/Requirements lists Data dictionary
But, Process and Data modelling are implicitly included!
Slide 11 of 20
Aim of a system a (short) paragraph to define succinctly what
a system does (and does not) do For a company’s retail system
“To support the correct administration and accounting of ordering, packaging and sales of goods through its shop and mail order operations”
Slide 12 of 20
Aim of a system - examples A payroll system
“To enable the correct calculation of gross pay and deductions for all weekly paid employees. Funds will be transferred electronically.”
A lift system “To transport a maximum of eight people between
floors in a safe and timely manner”
Slide 13 of 20
Levelling
Slide 14 of 20
Found in SAD structured process modelling but generically applied often
Handles complexity through grouping of low level functions and/or by decomposing high level functions
Each level lower has more detail than higher level(s)
Links high and low level functions allowing simultaneous consideration of all levels
Levelling - graphically
Slide 15 of 20
Somethingcomplex
Somethingless complex
Somethingless complex
Somethingless complex
Somethingless complex
Somethingeven simpler
Somethingeven simpler
Somethingeven simpler
Somethingeven simpler
Somethingsimpler
Somethingsimpler
Somethingsimpler
Somethingsimpler
Problem/Requirements list A numbered list of all the problems with
the current system and (usually hence) requirements of a new system
Does not differentiate between whether issue is a problem or a requirement
Includes the sublime, the ridiculous and all points between
Serves as a check-list when conceiving and designing new system
Helps to prevent problems and requirements becoming lost in the maw (mire) of analysis and design methods
Slide 16 of 20
What we have covered System modelling generally Consideration of a model and what it is Why model a system Identification of different modelling
approaches. Elements of structured approaches Assignment guidance What comes next
Slide 17 of 20
References Essentials of Systems Analysis and Design,
Valachi, George and Hoffer, Pearson Prentice Hall
Software Engineering, Ian Sommerville, Addison Wesley, 2000
Software System Development – A Gentle Introduction – Briton and Doake, McGraw Hill
Slide 18 of 20
Recommended