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

Size: px

Start display at page:

Download "Overview. What is system analysis and design? Tools and models Methodologies"

Dustin Hodges
5 years ago
Views:

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

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

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

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

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

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

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

8 Reasons for Failure Complexity Shifting requirements Bad estimation Bad management New technology

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

10 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

11 Generic development phases: Initiation Development Implementation Operation & Maintenance

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

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

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

15 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

16 Models Representations Simplify reality Require training Appropriate to problem

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

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

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

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

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

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

23 Focus in ER diagrams Structured Logical Process independent Minimal

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

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

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

27 Entities as Tables Student No Name Date of Birth Course A. Shearer 12/10/1973 Sports Studies C. Dickens 24/06/1835 English L. Pavarotti 30/02/1962 Performing Arts Attributes Key Attribute Value Occurrence of Student

28 Relationships Show how entities affect each other Two directions - two sentences Client offers owned by Property

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

30 Resolving Many-to-manys Hide information Difficult to physical represent Student attend is attended by Module

31 Resolving Many-to-manys Student Module attend is attended by is by Attendance is at

32 Optionality Optional - relationship MAY hold Mandatory - relationship MUST hold Two directions Teacher teach taught by Module_

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

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

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

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

37 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

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

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

40 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!

41 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?

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

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

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

45 Example DD entry CustomerDetails = Title + {initial} + Surname + Address + (CustomerPhone) Title = [Mr Mrs Ms Dr Rev] Address = [Number Name] + Street + {District} + (PostCode)

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

47 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

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

49 Data-flows Movement of data between processes No change of data during flow One end MUST attach to a process StockInventory

50 Processes Main feature of DF diagrams Change data Appear as boxes: 4 Location Do something to something *

51 Data stores Where data is stored inside the system Named by what they store Read does not mean Delete D3 Customer Details D3 Customer Details

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

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

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

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

56 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...

57 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

58 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

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

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

61 Levels of Data Flow Diagram a. 1 decomposes into a decomposes into a

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

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

64 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?

65 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?

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

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

68 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

69 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

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

71 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

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

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

74 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

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

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

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

78 Special Structures Quit and Resume quit from anywhere Parallel Structures Null events

79 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

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

81 Building ELH s Identify events Classify events creation, deletion, modification Order the events Repeat and innovate

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

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

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

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

86 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?

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

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

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

90 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

91 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!

92 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

93 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

94 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

95 Event instigate flow because Data flow write to written to Data Store made up of stored in Attributes belong to have (LDS) Entity

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

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

98 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.

99 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.

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

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

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

103 Stages of SSADM Stage No. Stage Name Module 0 Feasibility Study Feasibility Study 1 Investigation of Current Environment Requirements Analysis 2 Business System Options 3 Definition of Requirements Requirements Specification 4 Technical System Options 5 Logical Design Logical Systems Specification 6 Physical Design Physical Design

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

105 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

106 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

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

108 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

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

110 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

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

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

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

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

Introduction to Some Requirements Specification Tools (EEM, ELH, ECD, EAP) -Some Basic Concepts- Dr. Ernest Cachia

Introduction to Some Requirements Specification Tools (EEM, ELH, ECD, EAP) -Some Basic Concepts- Dr. Ernest Cachia SSADM Diagram Relationships DFD * ERD ELH Entity Life History (ELH) Diagrams Some basic