Identifying system improvements: Logicalisation

Slides:



Advertisements
Similar presentations
Data Flow Diagram (DFD) Overview
Advertisements

Technical System Options
Systems Analysis Requirements structuring Process Modeling
1 Information Systems Development (ISD) Systems Development Life Cycle Overview of Analysis Phase Overview of Design Phase CP2236: Information Systems.
IFS310: Week 3 BIS310: Structured Analysis and Design 5/4/2015 Process Modeling and Data Flow Diagrams.
Chapter 7 Structuring System Process Requirements
Systems Documentation Techniques
Section 07 (a)DFD to ERD Link1 HSQ - DATABASES & SQL By MANSHA NAWAZ 07 (a) - DFD to ERD Link And Franchise Colleges.
System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different.
Tenure and Promotion The Process: –Outlined in Article 15 of the FTCA. When you are granted tenure, you are also promoted to Associate (15.7.6). One application.
Data Flow Diagrams Levelling Them; Process Modelling Using Function Decomposition CSE Information Systems 1.
© Copyright 2011 John Wiley & Sons, Inc.
1 CP2236 Information Systems Design Business & Technical System Options Required System Logical Data Flow Modelling Larger versions of slides 17,20,23,24.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Communication Notation Part V Chapter 15, 16, 18 and 19.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 71 System models l Abstract descriptions of systems whose requirements are being analysed.
IMS1805 Systems Analysis Topic 4: How do you do it? Guidelines for doing analysis.
Further Data Modelling …and the effect of time. Plan Introduction Structured Methods –Data Flow Modelling –Data Modelling –Relational Data Analysis –Further.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Process Modeling Fundamentals. Three Ways to Understand a System By its processes What are the systems main processes? What are the systems main processes?
Unit 7 University of Sunderland COMM1B Information Systems Analysis Process Modelling: Introduction to Data Flow Modelling Information System Analysis.
Systems Analysis and Design. Plan Introduction Structured Methods –Data Flow Modelling –Data Modelling –Relational Data Analysis Feasibility Maintenance.
Spreadsheets in Finance and Forecasting Project Session 3b(ii) Data Flow Diagrams.
© Copyright 2011 John Wiley & Sons, Inc.
L ECTURE 9 – PROCESS MODELLING PART 1 Data Flow Diagrams for Process Modelling Multi-level Data Flow Diagrams Logical Vs Physical DFDs Steps to Construct.
Data Flow Modelling II. Plan Introduction Structured Methods –Data Flow Modelling –Data Modelling –Relational Data Analysis Feasibility Maintenance.
Data Flow Diagrams Continued. Checking Your Diagram Label flows uniquely. Put boundaries onto each diagram. Data flows are data only – not orders. Each.
System analysis and design
Systems Documentation Techniques
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
Chapter 7 Structuring System Process Requirements
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
National Diploma in Systems Analysis and Design Data Flow Modelling.
staffs.ac.uk Process Model. staffs.ac.uk Contents Provide definitions Explain the components and representations Introduce a step.
Data Flow Diagrams (DFDs)
Chapter 1: Data Flow Diagram Structuring System Process Requirements
Accounting systems design & evaluation 9434SB 12 April 2002.
Managing the development and purchase of information systems (Part 1)
Business Process Modeling
1 Lecture 3: Introducing Data Flow Diagrams (DFDs) Section 1 - The Concept of Diagrams Why use Diagrams? Diagrams as Working Documents Systems Analysis.
Systems Analysis & Design Data Flow Diagrams. End Home Data Flow Diagrams – Definition  A data flow diagram is a pictorial model that shows the flow.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Week 5: Business Processes and Process Modeling MIS 2101: Management Information Systems.
The Structured Specification. Why a Structured Specification? System analyst communicates the user requirements to the designer with a document called.
Chapter 3 Systems Documentation Techniques Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 3-1.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
CB1004 Modelling Business Systems 71 Modelling Business Systems 7 Systems Methods.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Process improvement with PISO ® PISO ® Structured Analysis Techniques... workplace creativity driven by strategy... workplace creativity driven by strategy.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
(Spring 2015) Instructor: Craig Duckett Lecture 10: Tuesday, May 12, 2015 Mere Mortals Chap. 7 Summary, Team Work Time 1.
1 Introduction to Software Engineering Lecture 1.
SYSTEMS ANALYSIS AND DESIGN TOOLS DATA FLOW DIAGRAMS.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28Slide 1 CO7206 System Reengineering 4.2 Software Reengineering Most slides are Slides.
Assessment at KS4 Bury C of E High School Engaging Parents Information.
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
SYSTEMS ANALYSIS AND DESIGN ITDB 2101 HAND OUT # 3 1.
7-1 Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition.
Software Development Lifecycle- SDLC Design- using DFDs.
Business System Development
(Winter 2017) Instructor: Craig Duckett
Data Flow Diagrams.
Chapter 1: Data Flow Diagram Structuring System Process Requirements
PDA IN APPLICATIONS OF ICT IN LIBRARIES Levels 7 & 8
Chapter 4: documenting information systems
Information Systems Development (ISD) Systems Development Life Cycle
Presentation transcript:

Identifying system improvements: Logicalisation Information System Analysis COMM1B Unit 13 Technique - Normalisation LDM - top down Normalisation - more mathematical and rigorous - scientific - BOTTOM UP arrives at relationships via a different route. Developed by Edgar Codd in 70’s for IBM -Applied principles of mathematical set theory and algebra to the organisation of data -data previously stored in ad hoc fashion -data files often mirrored paper documents, or the way data was entered onto the system -data duplication rife causing redundancy -data duplication causes problems with maintenance and flexibility Looked at system to decide on entities and then determine relationship between them. Not very precise, and may be puzzled as to why some entities are linked to others. Discussed the sorts of relationships - business relationships Relationships come about because of the way businesses operate eg A CUSTOMER places an ORDER therefore the customer is related to an order in a business sense. Looking at a totally different approach

Identifying Potential System Improvements Examining an existing system can lead to the identification of the potential for improved processing activity. This often results in: Construction of a modified model to support this change.

Identifying possible system improvements Problems lead to requirements (See Unit 14) Requirements Catalogue Operational and Strategic Objectives may bring about change Covered in COMM1F Business Process Re-engineering (BPR) Process Improvement for Strategic Objectives (PISO) Start with logicalisation of current system

System Modelling Why model the current system? Develop an understanding and feel for the information system Systems adapt and evolve over a period of time Often results in a system which does not fully reflect what the system was intended to do The old system may need to be changed or even replaced to accommodate new business requirements This technique called NORMALISATION Will look at normalisation by examining steps 1, 2, 3, and 4 Will find out what these strange terms mean as we go through the lecture. Normalisation is a bottom up approach looks at the DATA ITEMS in a system Group similar data items together - ENTITIEs Relationships developed between entities by looking at the data items present in more than one entity Coming at the problem from the opposite direction from entity modelling (LDM) 1

Current System Model Current Physical Model Current Logical Model Describes how the present system is implemented Current Logical Model Reflects the policy behind the system without the physical circumstances and constraints of the existing system forces the analyst to think logically and abstractly forms the basis for the specification of the required system

Stages of Systems Analysis and Design Investigate and analyse system Current PHYSICAL System Model Perform Logicalisation Current LOGICAL System Model Add New System Requirements, Consider Business System Options Required LOGICAL System Model Add Implementation Details, Consider Technical System Options Required PHYSICAL System Specification

Logicalisation The beginning of the ‘transformation’ of the old system to the new system Mainly involves reconstructing the set of levelled DFDs Physical DFDs show What is done, Where and How it is done, Who does it Logical DFDs only show What is done Refined entity model after normalisation

Simple Example of Physical level 1 DFD Party details 1 You M1 Diary Discuss party details and record interest Person details Party enquiry Party details M2 Phone directory Colleague Party invitation 2 You response Invite guest by telephone Tickets * 3 You M3 Address Book Produce and send out tickets to party M1 Diary

Logicalised level 1 DFD Colleague Party details Party Data 1 Communicate and record party data Party/contact data contact details D2 Contact Data

Example The following example of a student assessment system is used to illustrate the technique of logicalisation taken directly from Lejk and Deeks, chapter 9

Level 1 Current Physical DFD

Level 2 Current Physical DFD

Level 2 Current Physical DFD

Level 2 Current Physical DFD

Steps in Logicalisation Step 1- Rationalise Data Flows Remove all reference to physical items eg. tickets, order form etc. Replace with actual data being passed eg. order details

Rationalise Data Flows Physical Application form Student record Assignment and exam marks Stamped addressed envelope Pink top copy Logical Application details Student details Student marks Request for results Order details

Steps in Logicalisation Step 2 - Rationalise Data Stores An entity must be represented by one and only one data store a logical data store may represent a logical grouping of entities Remove any reference to a physical storage facility and prefix with D identifier eg. Appointments Diary becomes Appointments transient data stores should be removed (but may reappear in the required physical DFD, eg. for batch processing)

Entity Model for Current System

Physical Data Store/Entity cross reference

Guidelines for Data Stores Logical data stores typically contain entities: that are created at the same time that are linked via relationships whose attributes form part of the same major input/output data flows

Entity Model for Current Student Assessment System

Logicalised Data Store / Entity Cross reference

Steps in Logicalisation Step 3 - Rationalise bottom level processes Remove all reference to location or responsibility, i.e. leave it blank Remove processes which re-organise existing data e.g. sorting or collating data Processes 4.1 and 4.2 are no longer needed Where a process remains clerical or exists simply for physical reasons, remove it. Replace with an external entity, eg. Process 1 - preparation and marking of assessments by Subject Tutor Subject Tutor becomes an external entity

Rationalise Bottom Level Processes Remove processing that cannot be automated i.e. a process which requires subjective or expert decisions e.g. awarding a degree Process 3, moderate and finalize results by Board of Examiners reviews student results takes account of mitigating evidence arrives at a consensus decision the “doers” of such processes become external entities of the system so Board of Examinersw (BOE) becomes an external entity

Rationalise Bottom Level Processes If data is unaltered by a process replace it with a data flow Remove any physical aspects of the process e.g. add reservation in red becomes confirm reservation Combine processes which perform the same function or duplicated processes Combine related processes (often connected by direct data flows between them)

Guidelines for Processes Split over-complex processes into simpler processes Regroup “bottom level” processes by function rather than location Reconstruct the resultant top level DFD

Level 1 Current Logical DFD of System

Level 1 Current Physical DFD of System

Further Reading Lejk and Deeks Philip L Weaver An Introduction to Systems Analysis Techniques Chapter 9 Logicalisation Philip L Weaver Practical SSADM version 4 Pitman Publishing Chapter 3 p 112-115