Www.monash.edu.au IMS1805 Systems Analysis Topic 3: Doing analysis (cont)

Slides:



Advertisements
Similar presentations
Chapters 7 & 9 System Scope
Advertisements

Chapter 7 Structuring System Process Requirements
Copyright Irwin/McGraw-Hill Data Modeling Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Chapter 4 Enterprise Modeling.
Chapter 4.
Systems Analysis and Design 9th Edition
IMS1805 Systems Analysis Topic 2: Introduction to some key techniques for systems analysis in IS.
IMS1805 Systems Analysis Topic 4: How do you do it? Guidelines for doing analysis (continued from last week)
IMS1805 Systems Analysis Topic 3: Doing analysis (cont from Monday)
Topics Creating DFD Physical and logical DFD Event driven modeling
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models September 29, 2008.
IMS1805 Systems Analysis Topic 3: Doing analysis.
IMS1805 Systems Analysis Topic 4: How do you do it? Guidelines for doing analysis.
IMS1805 Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)
Data and Process Modeling
IMS1805 Systems Analysis Topic 3: Doing analysis.
IMS1805 Systems Analysis Topic 3: Doing analysis (cont from Monday)
© Copyright 2011 John Wiley & Sons, Inc.
Modeling the Processes and Logic
IMS1805 Systems Analysis Topic 3: Doing analysis (cont from last week)
Chapter 4.
IMS1805 Systems Analysis Topic 2: Introduction to some key techniques for systems analysis in IS.
DATA FLOW DIAGRAMS IT 155.
Process Modeling SYSTEMS ANALYSIS AND DESIGN, 6 TH EDITION DENNIS, WIXOM, AND ROTH © 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 1 Roberta M. Roth.
Chapter 7 Structuring System Process Requirements
6 Systems Analysis and Design in a Changing World, Fourth Edition.
© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye.
Traditional Approach to Requirements Data Flow Diagram (DFD)
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
Systems Analysis and Design in a Changing World, Fifth Edition
Modeling System Requirements:Events and Things
Chapter 1: Data Flow Diagram Structuring System Process Requirements
Chapter 6 The Traditional Approach to Requirements
Data and Process Modeling
Systems Analysis and Design in a Changing World, Fifth Edition
1 Chapter 2 Revision: Documentation DFD System FC.
10/12/2001Data Structure1 Relationships Between The Data Flow Diagram and The Systems Design Activities Mohammad A. Rob School of Business and Public Administration.
1 Lecture 3: Introducing Data Flow Diagrams (DFDs) Section 1 - The Concept of Diagrams Why use Diagrams? Diagrams as Working Documents Systems Analysis.
Phase 2: Systems Analysis
Chapter 7 Structuring System Process Requirements
Chapter 4 System Models A description of the various models that can be used to specify software systems.
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.
AN INTRODUCTION BUSINESS PROCESS DOCUMENTATION WITH DATA FLOW DIAGRAMS.
Section 11 : Normalisation
Database Design - Lecture 2
Conceptual Design versus Logical Design. Conceptual Data Design Prepared at beginning of project High level view of how the client sees the data Top down.
CSC 240 (Blum)1 Introduction to Database. CSC 240 (Blum)2 Data versus Information When people distinguish between data and information, –Data is simply.
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
IFS310: Module 6 3/1/2007 Data Modeling and Entity-Relationship Diagrams.
Data Flow Diagrams (DFDs)
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Systems Analysis and Design 8th Edition
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Lecture 3 : Hard Systems Modelling UFCE8V-20-3 Information Systems Development SHAPE Hong Kong 2010/11.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Modeling the Processes and Logic.
DBS201: Data Modeling. Agenda Data Modeling Types of Models Entity Relationship Model.
7-1 Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition.
Data Flow Diagrams 1. What is a Data Flow Diagram?  A data flow diagram (DFD) is a graphical representation of the movement of data between external.
CompSci 280 S Introduction to Software Development
G063 - Data flow diagrams.
System models October 5, 2005.
G063 - Data flow diagrams.
System Design By Kustanto.
Presentation transcript:

IMS1805 Systems Analysis Topic 3: Doing analysis (cont)

2 Recap of last three lectures The importance of understanding the purpose of analysis Some important purposes: Organisational; Technological; Development team The purposes behind various types of models (FDD/DFD/ERD/O-O/Soft systems)

3 Agenda Aim: To develop further your skills in using analytical techniques To identify some of the main problem areas students have in applying these techniques

Issues in process modelling: (a) physical vs logical models Physical actions versus information transformations People/places/times vs logical information events Note: Physical models are not ‘wrong’ – unless you are asked for a logical model! Why bother with the distinction? The importance of “seeing” pure information elements, not physical objects Examples from tute exercise

5 Issues in process modelling: (b) actions and data flow elements Relating physical actions to information processes Understanding/interpreting actions as data flow elements other than processes Seeing the overall picture: recognising the problems arising from poor process selection and re-thinking the process Examples from tute exercise

6 Issues in process modelling: (c) hierarchy and abstraction in processes The concept of hierarchy of processes Low-level vs high-level processes Composite (multi-process) processes vs single processes Implications for process names Why bother with the distinction? The importance of “seeing” both top and bottom level processes Examples from tute exercise

7 Issues in process modelling: (d) naming data flow elements ‘Bad’ names vs ‘good’ names Processes = verb + name (what transformation occurs + what data is transformed) High-level process names vs low-level process names Names as a clue to how clearly you are thinking Examples from tute exercise

8 Issues in process modelling: (e) testing your process model Putting the pieces together for an FDD: Every element of the diagram is a process Every low-level (child) process is a component of its associated higher-level (parent) process Every high-level (parent) process is fully described by its associated lower-level (child) processes Putting the pieces together for a DFD: Every process must have data inputs and data(/info) outputs Every data input/output must have a process at one end and either a process, data store or external agent at the other end All inputs must be used by a process to create all its outputs Processes ‘fit together’ in the same levels as in the FDD Examples from tute exercise

Issues in data modelling: (a) choosing your entities ‘Things’ which are involved in or part of the system vs ‘things’ about which the system needs to store information The first test for any entity: what are its attributes? (ie what does this system need to store as information about it (and why)?) Seeing an entity as a table in a database Examples from tute exercise

10 Issues in data modelling: (b) distinguishing attributes and entities Features which are inherently part of something (attributes) vs features which are connected/related to it. (Perhaps a different entity or an attribute of a different entity?) The first test for any attribute: does it have attributes as well? (ie does this system need to store as information about it?) If so, should it be an entity in its own right? Seeing an attribute as a field (column) in a database record Examples from tute exercise

11 Issues in data modelling: (c) identifying relationships What connections does the system need to be able to make between entities? Seeing a relationship as the basis for setting rules for a database to enforce about its entities Seeing a relationship as the basis on which queries can be built between database tables Examples from tute exercise

Issues in soft systems modelling: (a) identifying stakeholder positions Do all people involved in a system have attitudes towards it OR are people neutral users who simply supply/extract information? Do people involved in a system have ‘rights’ which should be acknowledged and taken into account? Is it sensible to ignore people’s attitudes/rights towards a system? Examples from tute exercise

Issues in O-O modelling: (a) identifying objects How easy is it for you to identify: Actions? Processes? Entities? How easy is it for you to identify objects? How easy is it to create objects from composites of processes and entities? Examples from tute exercise

14 Administration Assignment documents New assignment deadline No lecture on Monday, August 29th