Overview What is system analysis and design Tools

Overview • What is system analysis and design? • Tools and models • Methodologies

Information Systems • • What is a system? Why do systems fail? What is systems analysis and design? How do we do systems analysis?

What is a system? • A collection of parts • that work together • to achieve a goal/task

What is an information system? • Parts? – Usually on of the parts is a computer • Task? • The difficulty is getting the parts to work together

Complexity in Systems • • IS are needed for large/complex tasks Solve complexity by partitioning More parts More interaction Complexity

Bad Systems • • Fail to meet requirements Poor performance Poor reliability Unusability

Badly Produced Systems • Not to schedule • Not to budget • Runaway = 100% over budget or schedule

Reasons for Failure • Complexity – Shifting requirements – Bad estimation – Bad management – New technology

Need for Structure • • Must tackle complexity Structure partitioning of problem Organised interaction of parts Ensure you achieve the task

System Development Life Cycle • An ordering of a set of system development activities/phases. • Can be either sequential (serial) or nonsequential (e. g. contingent). • Contains guidance on how to progress from one phase to the next

Generic development phases: Initiation Development Implementation Operation & Maintenance

Links between phases: Initiation Problem statement; “vision” scenario, requirements Development Executables, user documentation etc Changes in scope, schedule, etc. An operational IS Implementation Design or programming errors Operation & Maintenance Implementation glitches: e. g. missing requirements

Standard System Life-cycle Problem Definition Feasibility Study System Analysis System Design Physical Design Implementation Maintenance

System Development Life-Cycle • • Stages Milestones Output/product/deliverable Waterfall technique Distilled experience

Systems Analysis and Design • Central to the life-cycle • Analysis: defining the problem – From requirements to specification • Design: solving the problem – From specification to implementation

Models • • Representations Simplify reality Require training Appropriate to problem

Models in Analysis and Design • • Focus ideas Aid communication with user Highlight omissions and errors Blueprint for the system

Good Models • Maintainable and disposable – CASE tools • Graphics v. Text • Understandable

The Main Models • Entity relationship diagram • Data-flow diagram • Entity life-history

Some Remarks • All three models represent the same system • There is no unique correct model • Need more than one attempt

Case Studies • • • Replace requirements Informal Ambiguous Realistic! (Nearly) Estate Agent System in handbook

Entity Relationship Diagrams • Centrality of data – DBA and DA • Represents structure of data • Shows relationships within data

Focus in ER diagrams • • Structured Logical Process independent Minimal

Components of ER Diagram • Entities with lists of attributes • Occurrences as set of values • Relationships – two directions - two sentences – degree – optionality

Entity • Block of information • Represents a type of thing • Occurrences are instances of the entity Student

Attributes • • Belong to an entity Simple item of data Values are the data for an occurrence Candidate keys and primary keys

Entities as Tables

Relationships • Show entities affect each other • Two directions - two sentences

Degree • Number of occurrences in relationship • Remember two directions • Three types: – one to one – one to many (or many to one) – many to many

Resolving Many-to-manys • Hide information • Difficult to physical represent

Resolving Many-to-manys

Optionality • Optional - relationship MAY hold • Mandatory - relationship MUST hold • Two directions

Components of ER Diagram • Entities with lists of attributes • Occurrences as set of values • Relationships – two directions - two sentences – degree – optionality

Building ER Models • Based entirely on requirements • Process must be repeated several times • Alternative to normalisation

Steps to ER modelling • • Identify entities List attributes Identify relationships Repeat several times

Identify Entities • One or two obvious ones • Use nouns in case study – entity or attribute • Not the whole system!

List Attributes • Again obvious ones for some entities • Use nouns in case study – complex attributes might be entities • Use imagination – for deliveries need addresses – for phone calls need phone numbers

Identify Relationships • • • Consider each pair of entities Begin drawing Consider degree Consider optionality Resolve many-to-manys

Repeat • • Is there enough data to do the job? Identify new entities and attributes Fit them to existing model Do it again!

Representing Relationships • Each entity needs a primary key • Use a foreign key for many-to-one • The “many” entity has a foreign key attribute • One-to-ones are rare or incorrect!

Validation • Is there any repetition of data or relationships? • Are all attributes and entities relevant? • Are all many-to-manys resolved? • Are the one-to-one relationships sensible?

The Data-Dictionary • Description of ALL information on EVERY item of data • Precisely defines the diagrams • Adds new detail • Backbone uniting all diagrams

ERD and Dictionary • • Description of every entity Lists of attributes & descriptions Volumetrics Description of relationships

DD Notation • • • = consists of; + sequence { } repetition; ( ) optional [ ] selection between alternatives | alternative separator *…. * comments

Example DD entry • Customer. Details = • Title + {initial} + Surname + Address + (Customer. Phone) • Title = [Mr|Mrs|Ms|Dr|Rev] • Address = [Number|Name] + Street + {District} + (Post. Code)

Data-flow Diagrams • • Clarify requirements Represent processes Interaction between processes Non-technical yet formal

Focus in DF diagrams • • • Data input to the system Data output from the system Movement of data between processes Storage of data within system Top-down decomposition

External Entities • Provides inputs, receives outputs • Different from Logical Data Structure • Represent types of things Customer

Data-flows • Movement of data between processes • No change of data during flow • One end MUST attach to a process Stock Inventory

Processes • Main feature of DF diagrams • Change data • Appear as boxes:

Data stores • Where data is stored inside the system • Named by what they store • “Read” does not mean “Delete”

Components of DF Diagrams • • Processes change data Data flows between processes External entities interact from outside Data stores hold data internally

From Logical to Physical Current Logical Required/New Logical Current Physical Required/New Physical

Building DF diagrams • Identify system boundaries • Begin construction – Follow inputs – Follow events • Fill in gaps • Repeat

Identify System Boundaries • Identify external entities • Identify their inputs and outputs • Entities stand for types

Follow Inputs • • • Start with important external entity Make a process to receive its input Define the process Determine outputs of the process Follow the outputs. . .

Follow Events • Happenings in the case study – Either inputs or temporal events • Make a process for the event • Identify inputs and outputs • Backtrack inputs or follow outputs

Fill in Gaps • Is there enough data for each process to work? • Where necessary add new inputs and backtrack • Have all outputs been produced? • Check data store usage

Repeat • Look for omitted functionality • Add new processes where necessary • Only finished when every word is either included or deliberately omitted!

Levelling • • Levels help to simplify huge systems Context diagram - level 0 Level 1 - system overview Successive levels expand a process of the previous level

Levels of Data Flow Diagram 1 a. decomposes into a. 1. 1 1. 2 1. 3 decomposes into 1. 3. 1 1. 3. 2 a.

Features of Levelling • Diagrams must balance • Numbering indicates the level • Bottom level is the process description – flowcharts, English and structured English

Making Levels • • Start with context diagram Expand complicated processes Simplify diagrams by grouping Balance

Validation of DF Diagrams I • Is every DF attached to a process? • Does every process have an input and an output • Are names sensible? • Do data-flows cross?

Validation of DF Diagrams II • Do all diagrams balance? • Are all external entities on context diagram and level 1? • Are all processes and data stores numbered correctly?

DFD and Dictionary • • Description of data-flows Description of external entities Description of data stores Description of process

Process Description • Explains bottom level processes • Removes ambiguities – Structured English – Formal English – Pseudocode

LDS and DFD • LDS represents data stored • Data stores are where data is stored • Each data stores is made up of one or more entities • Recorded in data dictionary

Data-flows and Attributes • Data flows to a data store add data to entities • Data flows from a data store take data from entities • Data flows are made up of attributes or data items

Entity Life-Histories • • Design technique Introduce time into the models Represent ordering of events Fill in holes in analysis

What are events? • Events affect entities – change the values of data • Look for writes to data stores • Inputs or temporal events • Events happen at a definite point in time

Extracting Events • • Verbs and verb-phrases Make a list of candidate events Decide what entities are affected Work out which attributes change

Ordering Events • One thing follows another - SEQUENCE • Either one thing or another happens OPTION • Something happens many times ITERATION

Other Orderings? • Sequence, options and iteration are all that computers can do • Other orderings are not necessary • Other orderings give simplicity • Describe them as we need them

Tree Structure • • Root is the entity itself Branches have nodes Leaves are the events Parents, children and siblings

Leaves • Represent events • Three types: – creation – deletion/destruction – modification • Events affect attributes

Nodes • Represent: – sequences, [blank] – iterations, * – options, O • Do not mix types of nodes! • Iteration is always an only child.

Special Structures • Quit and Resume – quit from anywhere • Parallel Structures • Null events

Reading ELH’s • Read left to right – Creation on left – Death on right • Children explain how to do parent • Quit - read the box and then jump

Components of ELH • Root is the entity • Leaves are events • Nodes indicate ordering: – sequence, iteration, optionality

Building ELH’s • Identify events • Classify events – creation, deletion, modification • Order the events • Repeat and innovate

Identify Events • In data-flow model • From inputs and temporal events • Happenings in case study

Classify Events • Creation, deletion, modification • Entity-event matrix • Modification events affect attributes

Order Events • • Creation events on the left Deletion events on the right Order events using different types of node Use special structures if necessary

Repeat and Innovate • Review case study – look for creation and deletion events • Define sensible modification events • Match business practices

Validation • Are there a root entity, a creation event and a deletion event? • Do modification events modify? • Are the nodes correctly arranged? • Are quit and resume correctly labelled?

ELH and Dictionary • Description of events • Attributes effected by events • Entity-event matrix

Models • • Models are simplified representations Real or conceptual. Suppress some aspects Emphasize others

Models in systems development • Impossible to use a single model • Hence a variety of models. • Every models specialises in some aspect of the system.

Three Views of the System • Logical Data Models (LDM) – WHAT is stored and how it is inter-related • Data Flow Models (DFD) – how information is PASSED AROUND • Entity Life Histories (ELH) – how information is CHANGED

Relationship between the Three Views • Three models are related a defined way • Cross-checking for completeness and consistency • Intelligent tools could produce‘first drafts’ from other models!

ER Diagram v. DF Diagram • A data store corresponds to one or more entities • Each entity is in some data store • Data flows to and from a data store are composed of attributes • Exceptions: Transient data

ER Diagram v. ELH • Each entity has a creation and deletion event • Modification events affect attributes including foreign keys • Each attribute is given a value • EEM relates all events and entities

DF Diagram v. ELH • Events are inputs or temporal events • Events eventually cause input to data stores • One event may cause more than one such input

Data Dictionary • Data about data – Data elements and data structures – Data-flows – Data-stores – Entity descriptions • CASE tools

Methodologies • What is a methodology? • Why use a methodology? • Which methodology?

What is a methodology? • • Integrates tools and techniques Usually an underlying philosophy Justified by experience A methodology may or may not prescribe a Life Cycle Model.

Methodology is not a LCM • A LCM specifies and orders the development activities • A methodology offers the tools • Although most methodologies specify a LCM, some don’t.

Why Use a Methodology? • • Distilled experience/best practice Ensures user involvement Helps inexperienced analysts Provides planning and control

Which Methodology? • SSADM – data driven, highly prescriptive • Yourdon – freer, emphasis on DFD, real-time aspects • OO and incremental methodologies • SDLC is central to all

SSADM • • Open - developed by UK government Mature Waterfall fitting with standard life-cycle User involvement

Stages of SSADM

Feasibility Study • • Technical - is it possible? Financial - is it affordable? Organisational - is it compatible? Ethical - is it socially acceptable?

Investigation of the Current Environment • • • Analyst learns business Old system is core of the new system Data model is built Users are involved System boundaries are defined

Products of Stage 1 • User Catalogue • Requirements Catalogue • Current Services Description • • Current environment logical data structure Context diagram Levelled set of DFD’s (current logical) Data dictionary

Business System Options • Brainstorming of ideas – degree of automation – boundary and distribution of system – cost v. benefit – impact • Product is a single selected option

Requirements Specification • Full specification inside framework of the business option • Must match requirements • Must be free from error and ambiguity • All three models are employed and others

Products of Stage 3 • Data Dictionary • Requirements Catalogue • Processing Specification • user/role function matrix • function definitions • models (required LDM, ELH, ECD)

Technical System Options • Second brainstorming stage – hardware and software – cost of implementation – staffing and other physical considerations – format of human-computer interface • Product is a single selected option

Logical Design • Detailed design of human computer interface • User dialogues • Update processes • Enquiry processes

Physical Design • Huge and technical! • All design converted to detailed physical implementation plan • Optimised for size and performance

Advantages of SSADM • • • Three different views Mature Separation of logical and physical Well-defined techniques User involvement

Disadvantages of SSADM • • • Large investment in training User involvement Difficult to change requirements No short-term benefits Incomplete life-cycle coverage