Mood's In Control
With reference to assignments 8 and 9, what characteristics does an analyst(you) examine when evalauating DFD quality?
When developing any type of computer program, from a simple command-line game to an ornate operating system, one of the most important things a programmer can do is to create a data flow diagram. Though it may be a bit annoying, creating a data flow diagram will allow the programmer to create a program with minimal discomfort in programming the actual code and further increase the productivity of the programmer (or programming group).
The most important thing a data flow diagram does is to keep the program organized. Programmers use data flow diagrams to plan exactly how their new program is going to accomplish its intended purpose. While more simpler programs could probably be made without using a data flow diagram for organization, creating more complex ones, especially with groups of programmers, definitely requires the use of a data flow diagram to help keep the program on track.
Now, for evaluating DFD quality. A high-quality set of DFDs is readable, is internally consistent, and accurately represents system requirements. Accuracy of representation is determined primarily by consulting users and other knowledgeable stakeholders. A project team can ensure readability and internal consistency by applying a few simple rules to DFD construction. Analysts can apply these rules while developing the DFDs or during a separate quality check after preparing DFD drafts.
Minimizing Complexity
People have limited ability to manipulate complex information. If too much information is presented at once, people experience a phenomenon called information overload.Information overload is the difficulty in understanding that occurs when a reader receives too much information at one time. When information overload occurs, a person has difficulty in understanding. The key to avoiding information overload is to divide information into small and relatively independent subsets. Each subset should contain a comprehensible amount of information that people can examine and understand in isolation.
Ensuring Data Flow Consistency
An analyst can often detect errors and omissions in a set of DFDs by looking for specific types of inconsistency. Three common and easily identifiable consistency errors are as follows:
• Differences in data flow content between a process and its process decomposition
• Data outflows without corresponding data inflows
• Data inflows without corresponding outflows
A process decomposition shows the internal details of a higher-level process in a more detailed form. In most cases, the data content of flows to and from a process a one DFD level should be equivalent to the content of data flows to and from all processes in a decomposition DFD are said to be “in balance”.
Note the use of the term data content in the previous paragraph. Data flow names can vary among DFD levels from a number of reasons, including decomposition of one combined data flow into several smaller flows. Thus, the analyst must be careful to look at the components of data flows, not just data flow names. For this reason, detailed analysis of balancing should not be undertaken until data flows have been fully defined.
Balancing is the equivalence of data content between data flows entering and leaving a process and data flows entering and leaving a decomposition DFD.
Unbalanced DFDs may be acceptable when the imbalance is due to data flows that were ignored at the higher levels.
Another type of DFD inconsistency can occur between the data inflows and outflows of a single process or data store. By definition, a process transforms data inflows into data outflows. In logical DFD, data should not be needlessly passed into a process. The following consistency rules can be derived from these facts:
• All data that flows into a process must flow out of the process or be used to generate data that flows out of the process.
• All data that flows out of a process must have flowed into the process or have been generated from data that flowed into the process.
Those that I mentioned above are the characteristics that I examine when evaluating Data Flow Diagram. I based those factors from what I read and learned in Systems Analysis and Design In a Changing World, fifth edition book by John W. Satzinger since those that he mentioned there are the most important factors that an analyst should consider and examine when evaluating data flow diagram.
The most important thing a data flow diagram does is to keep the program organized. Programmers use data flow diagrams to plan exactly how their new program is going to accomplish its intended purpose. While more simpler programs could probably be made without using a data flow diagram for organization, creating more complex ones, especially with groups of programmers, definitely requires the use of a data flow diagram to help keep the program on track.
Now, for evaluating DFD quality. A high-quality set of DFDs is readable, is internally consistent, and accurately represents system requirements. Accuracy of representation is determined primarily by consulting users and other knowledgeable stakeholders. A project team can ensure readability and internal consistency by applying a few simple rules to DFD construction. Analysts can apply these rules while developing the DFDs or during a separate quality check after preparing DFD drafts.
Minimizing Complexity
People have limited ability to manipulate complex information. If too much information is presented at once, people experience a phenomenon called information overload.Information overload is the difficulty in understanding that occurs when a reader receives too much information at one time. When information overload occurs, a person has difficulty in understanding. The key to avoiding information overload is to divide information into small and relatively independent subsets. Each subset should contain a comprehensible amount of information that people can examine and understand in isolation.
Ensuring Data Flow Consistency
An analyst can often detect errors and omissions in a set of DFDs by looking for specific types of inconsistency. Three common and easily identifiable consistency errors are as follows:
• Differences in data flow content between a process and its process decomposition
• Data outflows without corresponding data inflows
• Data inflows without corresponding outflows
A process decomposition shows the internal details of a higher-level process in a more detailed form. In most cases, the data content of flows to and from a process a one DFD level should be equivalent to the content of data flows to and from all processes in a decomposition DFD are said to be “in balance”.
Note the use of the term data content in the previous paragraph. Data flow names can vary among DFD levels from a number of reasons, including decomposition of one combined data flow into several smaller flows. Thus, the analyst must be careful to look at the components of data flows, not just data flow names. For this reason, detailed analysis of balancing should not be undertaken until data flows have been fully defined.
Balancing is the equivalence of data content between data flows entering and leaving a process and data flows entering and leaving a decomposition DFD.
Unbalanced DFDs may be acceptable when the imbalance is due to data flows that were ignored at the higher levels.
Another type of DFD inconsistency can occur between the data inflows and outflows of a single process or data store. By definition, a process transforms data inflows into data outflows. In logical DFD, data should not be needlessly passed into a process. The following consistency rules can be derived from these facts:
• All data that flows into a process must flow out of the process or be used to generate data that flows out of the process.
• All data that flows out of a process must have flowed into the process or have been generated from data that flowed into the process.
Those that I mentioned above are the characteristics that I examine when evaluating Data Flow Diagram. I based those factors from what I read and learned in Systems Analysis and Design In a Changing World, fifth edition book by John W. Satzinger since those that he mentioned there are the most important factors that an analyst should consider and examine when evaluating data flow diagram.
