MIS485 1

An.

Processmodeling-DataFlowDiagramsHandout..pdf

Home >Information Systems homework help >MIS485 1

MIS485: Capstone Project in MIS

2MGT 400 - Project Management

Textbook: Farrell, P. J., (2017). IT Capstone

Project (3rd Edition), Kendall Hunt

Publishing.

Structuring System Requirements: Process modeling-

Data Flow Diagrams.

Process Modeling for Structured Analysis

Process Modeling

• Graphically represents the processes that capture, manipulate, store, and distribute data between a system and its environment and among system components.

• Data-flow Diagrams (DFD) • Graphically illustrate movement of data between external

entities and the processes and data stores within a system

Process Modeling (continued)

• Modeling a System’s Process • Utilize information gathered during requirements

determination

• Structure of the data is also modeled in addition to the processes

• Deliverables and Outcomes • Set of coherent, interrelated data-flow diagrams

Process Modeling (continued)

• Deliverables and Outcomes (continued) • Context data-flow diagram (DFD)

• Scope of system

• DFDs of current system • Enable analysts to understand current system

• DFDs of new logical system • Technology independent

• Show data flows, structure and functional requirements of new system

Process Modeling (continued)

• Data-flow Diagramming Mechanics • Represent both physical and logical information systems,

manual or computer based.

• Four symbols are used • See Figure 6-3

• Developed by Gane and Sarson

Definitions and Symbols

Comparison of DeMarco

and Yourdon

and Gane and Sarson

DFD symbol sets

Definitions and Symbols (Cont.)

• Process: works or actions performed on data (inside the system)

• Data store: data at rest (inside the system)

• Source/sink: external entity that is the origin or destination of data (outside the system)

• Data flow: arrows depicting movement of data

Data-Flow Diagramming Mechanics

 Data Flow • Depicts data that are in motion and moving as a unit

from one place to another in the system

• Drawn as an arrow

• Select a meaningful name to represent the data

Data-Flow Diagramming Mechanics (continued)

 Data Store • Depicts data at rest

• May represent data in • File folder

• Computer-based file

• Notebook

• Drawn as a rectangle with the right vertical line missing

• Label includes name of the store as well as the number

Data-Flow Diagramming Mechanics (continued)

 Process • Depicts work or actions performed on data so

that they are transformed, stored, or distributed

• Drawn as a rectangle with rounded corners

• Number of process as well as names are recorded

Data-Flow Diagramming Mechanics (continued)

 Source/Sink • Depicts the origin (Source) and/or destination (Sink)

of the data.

• Sometimes referred to as an external entity.

• Drawn as a square symbol.

• Name states what the external agent is.

• Because they are external, many characteristics are not of interest to us.

Developing DFDs

 Context Diagram • A data-flow diagram of the scope of an organizational

system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system.

Note: only one process symbol, and no data stores shown

Developing DFDs: An Example

• Hoosier Burger’s Automated Food Ordering System

Context Diagram contains no data

stores

Context Diagram

Developing DFDs (continued)

 Level-O Diagram • A data-flow diagram that represents a system’s major

processes, data flows, and data stores at a higher level of detail.

• Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-level) DFDs.

Developing DFDs: An Example (continued)

– Next step is to expand the context diagram to show the breakdown of processes (Figure 6-6)

Level-O Diagram

Data-Flow Diagramming Rules

 Basic rules that apply to all DFDs:

• Inputs to a process are always different than outputs. – Processes purpose: is to transform inputs into

outputs.

• Objects always have a unique name – Every process has a unique name.

• In order to keep the diagram uncluttered, you can repeat data stores and data flows on a diagram

Data-Flow Diagramming Rules (continued)

 Process A. No process

can have only outputs (a miracle)

B. No process can have only inputs (black hole)

C. A process has a verb phrase label

 Data Store D. Data cannot be

moved from one store to another

E. Data cannot move from an outside source to a data store

F. Data cannot move directly from a data store to a data sink

G. Data store has a noun phrase label

 Source/Sink H. Data cannot move

directly from a source to a sink

I. A source/sink has a noun phrase label

Data-Flow Diagramming Rules (continued)

 Data Flow J. A data flow has only one direction of flow between symbols K. A fork means that exactly the same data go from a common

location to two or more processes, data stores, or sources/sinks

L. A join means that exactly the same data come from any two or more different processes, data stores or sources/sinks to a common location

M. A data flow cannot go directly back to the same process it leaves N. A data flow to a data store means update O. A data flow from a data store means retrieve or use P. A data flow has a noun phrase label

Data Flow Diagramming Rules (Cont.)

Incorrect and correct ways to draw DFDs

Decomposition of DFDs

 Functional decomposition • An iterative process of breaking a system

description down into finer and finer detail.

• Creates a set of charts in which one process on a given chart is explained in greater detail on another chart.

• Continues until no subprocess can logically be broken down any further.

Decomposition of DFDs (Cont.)

 Level-1 diagram results from decomposition of Level-0 diagram.

 Level-n diagram is a DFD diagram that is the result of n nested decompositions from a process on a level-0 diagram.

 Primitive DFD is the lowest level of a DFD.

Level-1 DFD

Level-1 DFD shows

the sub-processes

of one of the

processes in the

Level-0 DFD.

This is a Level-1

DFD for Process

4.0.Processes are labeled 4.1, 4.2, etc. These can be further

decomposed in more primitive

(lower-level) DFDs if necessary.

Level-1 diagram showing the

decomposition of Process 4.0

from the level-0 diagram for

Hoosier Burger’s food-ordering

system

Level-n DFD

shows the sub-

processes of

one of the processes in the

Level n-1 DFD.

This is a Level-2

DFD for Process

4.3. Processes are labeled 4.3.1, 4.3.2, etc. If this is the

lowest level of the hierarchy, it is called a primitive DFD.

Level-2 diagram showing the decomposition of

Process 4.3 from the level-1 diagram for Process

4.0 for Hoosier Burger’s food-ordering system

Balancing DFDs

 When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition

• This is called balancing

 Example: Hoosier Burgers

• In the context diagram, notice that there is

• One input to the system:

• the customer order • Three outputs:

• Customer receipt

• Food order

Balancing DFDs (continued)

• Example (Continued)

• Notice level-0 DFD.

• We have the same inputs and outputs

• No new inputs or outputs have been introduced

• We can say that the context diagram and level-0 DFD are balanced

Balancing DFDs: An Unbalanced Example

• In context diagram, we have one input to the system, A and one output, B

• Therefore. these DFDs are not balanced

• Level-0 diagram has one additional data flow, C

Balancing DFDs

• We can split a data flow into separate data flows on a lower level diagram

Guidelines for Drawing DFDs

1. Completeness • DFD must include all components necessary for the

system • Each component must be fully described in the

project dictionary or CASE repository

2. Consistency • The extent to which information contained on one

level of a set of nested DFDs is also included on other levels

Guidelines for Drawing DFDs (continued)

3. Timing • Time is not represented well on DFDs • Best to draw DFDs as if the system has never started

and will never stop

4. Iterative Development • Analyst should expect to redraw diagram several

times before reaching the closest approximation to the system being modeled

5. Primitive DFDs • Lowest logical level of decomposition • Decision has to be made when to stop

decomposition

Guidelines for Drawing DFDs (continued)

 Rules for stopping decomposition: • When each process has been reduced to a single

decision, calculation or database operation. • When each data store represents data about a single

entity. • When the system user does not care to see any more

detail. • When every data flow does not need to be split further

to show that data are handled in various ways. • When you believe that you have shown each business

form or transaction, online display and report as a single data flow.

• When you believe that there is a separate process for each choice on all lowest-level menu options.

Using DFDs as Analysis Tools

• Gap Analysis • The process of discovering discrepancies between two or

more sets of data-flow diagrams or discrepancies within a single DFD

• Inefficiencies in a system can often be identified through DFDs

Process Modeling for Electronic Commerce Application

• Process modeling for electronic commerce projects is no different than other projects

• See Pine Valley Furniture example; next Table.

Summary

• Data-flow Diagrams (DFD) • Symbols

• Rules for creating

• Decomposition

• Balancing

• DFDs for Analysis

• DFDs for Business Process Reengineering (BPR)

• Logic Modeling • Decision Tables

• Process Modeling for the Internet