STRUCTURED SYSTEMS ANALYSIS PART ONE CM00308 - 1 Systems Development Tools Techniques & Methods.
-
Upload
brandon-chapman -
Category
Documents
-
view
212 -
download
0
Transcript of STRUCTURED SYSTEMS ANALYSIS PART ONE CM00308 - 1 Systems Development Tools Techniques & Methods.
STRUCTURED SYSTEMS ANALYSIS PART ONE
CM00308 - 1Systems Development Tools Techniques &
Methods
What we will cover Slide 2 of 20
ApologiesSystem modelling generallyWhat is a model?Why model a systemA summary of modelling approaches
System modelling generally Slide 3 of 20
Source 1
Source 3
Source 2
Recipient 1
Recipient 2
Recipient 3
The SystemI
n
p
u
t
s
O
u
t
p
u
t
s
a miracle happens!
And lo …
What is a model? Slide 4 of 20
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 …
Why model a system? Slide 5 of 20
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 buildenables “look ahead”
Why model a system? - summary
Slide 6 of 20
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
Modelling/development approaches
Slide 7 of 20
Object oriented approachesStructured approachesCollaborative approaches
RAD, Prototyping, DSDM …….
Agile approaches SCRUM, XP etc Today’s challenge – what does SCRUM stand for? prizes next time
Other approaches
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 itIs all Edgar Codd’s fault (from 1970) Process modelling - covers the whatData modelling - covers the structure of the
data needed to support what is happeningTime and Event modelling – cover things that
Process Modelling doesn’t do very wellStructured modelling includes some useful
techniques that are generically applicable Slide 8 of 20
Process Modelling Slide 9 of 20
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
Data Modelling Slide
10 of 20
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 moduleThis is an area which improved greatly
with practice and, at first, seems incomprehensible and impossible
Useful structured modelling tools and techniques Slide
11 of 20
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!
Aim of a system Slide
12 of 20
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”
Aim of a system - examples Slide
13 of 20
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”
Levelling Slide
14 of 20
Incredibly useful for those of us bears with very little brain
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 Slide
16 of 20
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
A word or two about your assignment Slide
17 of 20
StartIt!
What we have covered Slide
18 of 20
System modelling generallyConsideration of a model and what it isWhy model a systemIdentification of different modelling
approaches. . . Elements of structured approachesAssignment guidanceWhat comes next
What’s next? Slide
19 of 20
Process Modelling proper Where and why it fits into Software Development Data Flow Diagrams – what and how More on levelling How it all fits with other structured modelling
techniques
References Slide
20 of 20
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