Thursday, February 9, 2012

Evaluating High-Quality DFD

Note: Assignment 10 of System Analysis and Design

In systems analysis and design, there are a lot of tools used to understand fully the structure and the different processes of the system being studied. One of the tools used to recognize the structure of the system is by the use of visual diagrams. Visual diagrams help people to know the general overview of the system, which eventually would lead to the understanding of the whole system when presented with more types of the visual diagrams. There are many types of diagrams to model the systems. They may be diagrams that show the structure of the system or diagrams that depicts what happens in the system. There are also diagrams that depict the flow of data. One of them is the data flow diagram or DFD.


Data Flow Diagram
Data Flow Diagram or DFD is a structural diagram that illustrates the flow of data from external entities into the system, shows how the data moved from one process to another, as well as its logical storage (Ambler, 2009). Data Flow Diagram shows how the data is processed by a system in terms of inputs and outputs (SmartDraw). In short, DFD’s illustrates how the data flows and how it is handled by the system.

Data Flow Diagram Symbols
In Gane and Sarson notation of a Data Flow Diagram (Ambler, 2009), there are four symbols used to illustrate the flow of data.
· Squares for External Entities
Squares represent the external entities of the system. These external entities may be the source or the destination of the data. For example, in an enrolment system of a university, a student gives his or her basic information to the University for Them to have a record on him. Therefore, the student is a source of information and thus is drawn inside a square or a box.
External entities are named appropriately. Squares of the same name can be duplicated one or more times to avoid line crossing on the diagram. With this, the diagram would be much cleaner or organized well. In identifying an external entity, one must determine first the system boundary. The system boundary is the limitation of what the system is able to process. The external entities should be outside of the system being studied. External entities are usually beyond the area of influence of the system developer. Meaning, there are instances that some external entities could be omitted unintentionally. Thus, identifying external entities should be done carefully.
· Rounded Corner Rectangles for Processes
The rounded rectangles represent the processes of the system. Inside the rounded rectangle, there is a two-partitioned space or sometimes there are three. The top partition shows a number that depicts its process number or its order on the system. In the middle is the name of the process that is to be used. And on the bottom partition, it is written there the actor or the person involved on that particular process. It is him or her that receives the data and processes it. The processes we are talking about are the processes that take data as an input and do something to it; example is outputting it or storing it to a database.
Processes show that there is a change or transformation of data happening. So when there is a transformation, then it is obvious that there is an input data and an output data. Naming of the process should also be done rightfully. In naming the process, it should consist of a verb and an object of the verb. There is no subject on the name of the process and the word “process” should not be present on the process name. Each process should also represent only one function or action. So if there is an “and” on the name, then there are already two or more processes or functions. That process should be separated then.
On a system, there could be leveling of processes. With leveled processes, there are some processes that are sub-processes of a process. So to identify them easily and clearly, numbering the process is allowed. For the sub-process, one could identify them by using a decimal notation. For example, a main process has 3 sub-processes. So the main process, assuming it is the first process, would be 1 and the sub-processes would be 3.1, 3.2, and 3.3.
The arrangement of processes in a data flow diagram is generally from top to bottom and left to right. This is done to have a uniformity of the diagrams. It would also help to read and understand efficiently the flow of the data.
· Open-ended Rectangles for Data Stores
These open-ended rectangles are the data stores or storages. When we mean data stores, it could be physical or logical. Logical data stores are the databases or the XML files of the system while the physical data stores are the filing cabinets or the stacks of papers. Data stores are important because it has the summary of all the information gathered and to be used by the system.
· Arrows for Data Flows
Arrows represent the direction of the data flow. It shows where the data comes from and where the data goes into. It connects the three other shapes mentioned earlier. The data that we refer in the system may be the electronic data or the physical items such as the documents and papers.
When there are two or more processes that output data that flows to the same destination, then the arrows could be joined. This also means that when same data goes to two or more separate destinations, then the arrow could be forked or divided into multiple arrows going to multiple paths.
One thing to mind about the arrow or the data flow is that it should represent data only and not the control. To show the control of data, one can do that by using another type of diagrams. For in data flow diagram, it only shows how the data flows in the system.
In naming the arrows or data flow, it should be done by labeling it with the specific data that is passed either as an input or as an output. The name should not contain the word “data” for it is obvious already that the arrow represents a data.

Figure 1. Symbols on a Data Flow Diagram or DFD

Constructing Data Flow Diagram (DFD)
To construct a quality data flow diagram, a procedure should be followed so that we could be ascertained that the diagram we are making is correct and understandable even by a person that does not know a data flow diagram.
1. Identify and list external entities.
The first thing to do, and one of the most crucial parts in constructing a data flow diagram, is to identify all of the external entities. As what have mentioned previously about external entities, these are the objects that are beyond the system boundary. They are usually the source of data that goes into the system.
2. Identify and list input and output data.
The next step is to list down all the input data from the external entities to the system and all the output data from the system to the external entities.
3. Create the context diagram.
After identifying the external entities and the different input and output data, a context diagram could now be drawn. A context diagram is a diagram that shows the flow of data between the system and the external entities. The system is on the center and surrounding it are the external entities. The system is represented as one process that receives data from the external entities and outputs data to the external entities.
4.       Identify business functions.
Now that we have the context diagram, we could now delve deeper on the specifics functions and actions on the system. So we have to list down all the processes of the system.
5. Identify data connections between business functions.
As we are in knowledge that processes are done sequentially, we now have to identify the correct sequence of the processes. We also have to determine the data that flows between them.
6. Confirm data distribution and reception.
Next is to confirm that the data from the external entities goes into the system and is received by the correct process that needs the data.
7. Trace and record the data flows of the system.
Tracing and recording the data is done to ensure that the data flow is correct and there is no data that strayed to different process.
8. Connect diagram segments.
If there would be segmented diagrams, then we should find the connection between those diagrams. If possible, there should be no segmented processes on the system. All processes should be connected to each other.
9. Verify data flow source and destination.
We should now verify that in every process, the data that goes in must go out, even if there is no transformation of data that happened. In this step, we should check if there is an existing diagramming mistake such as a black hole, grey hole, or a miracle.
Black holes are processes that have input flows but do not produce output flows. Grey holes, on the other hand, are processes that produce output that could not possibly be produced given a certain input. And lastly, a miracle pertains to process that does not have any input but was able to produce an output flow.
10. Simplify and redraw the diagram.
After checking that there are no errors on the diagram, we could now simplify the diagram and redraw it to finalize.
11. Repeat step 1 if needed.
If still not sure on the finished diagram, we could go back to step 1 and verify for any changes that occurred in the new diagram that did not appear on the previous diagram.

Characteristics of a High Quality DFD
A high quality Data Flow Diagram should be:
· Accurate
A DFD’s accuracy is measured in terms of the number of the diagramming mistakes present such as the black holes, grey holes, and miracles. A high-quality DFD should not have any of these mistakes. To avoid the mistakes, one should follow carefully the guidelines on how to construct a data flow diagram.
· Readable
A Data Flow Diagram is readable when it is not too complex. Too much complexity could result to hard time in tracing the flow of data. Following the rule of arranging the processes from top to bottom and left to right would really help to decrease the complexity of the diagram. Numbering of the processes would also increase the readability of the DFD. Proper naming of the components of the system should also be done rightly.


Sources:

No comments:

Post a Comment