Evaluating a DFD
On the previous assignments we have created different types of diagrams to conceptualize the pre-enrollment system of the university. These diagrams could help us understand the floe of data, how it is used, and who administers it. On this assignment we are tasked to analyze what characteristics should be considered upon evaluating a data flow diagram.
According to Wikipedia data flow diagram (DFD) is defined as a graphical representation of the flow of data through an information system. DFDs can also be used for the visualization of data processing (structured design).On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process. Data flow diagrams (DFDs) offer a graphical technique for summarizing the movement of data between the processing steps that occur within a business process. They isolate the collections of data, or data stores, which accumulate during a process, and identify the sources of data that arise outside process boundaries.
Upon constructing a DFD, there are a lot of things to be considered by the analyst. Analyst should take into consideration the type of system they are creating and other factors as well. This is the job of a system analyst. A systems analyst researches problems, plans solutions, recommends software and systems, and coordinates development to meet business or other requirements. They will be familiar with multiple approaches to problem-solving. Analysts are often familiar with a variety of programming languages, operating systems, and computer hardware platforms. Because they often write user requests into technical specifications, the systems analysts are the liaisons between vendors and IT professionals. They may be responsible for developing cost analysis, design considerations, and implementation time-lines.
In creating a dataflow diagram here are some characteristics that might be taken into consideration by the analyst.
* Two-dimensional summary
DFD should offer a way to summarize the data flow characteristics of a process on a single page. As such they can provide a useful and concise summary of system-related process attributes.
DFD should offer a way to summarize the data flow characteristics of a process on a single page. As such they can provide a useful and concise summary of system-related process attributes.
* Completeness
DFDs offer a way to check the completeness of your process model, particularly as regards your understanding of the data that would be required by an information system. It should be clear that the needed data are clearly projected on the DFD and if their processing step procedure could be used by subsequent steps and if all the data present in the DFD are usable by an information system. DFDs can provide a fast way to generate further questions that need to be asked about the process.
* Processing, not processes
DFDs refer to "process" steps. It might be more useful to think of DFD "processes" as processing steps rather than process activities. In essence, DFDs ask one to refer to the information systems implications of any processing work that occurs during the tasks that comprise a business process. DFD terminology tends to confuse the term "process" in its connotation with business process with the term "process" that refers to a computational process executing within software. Whether this represents the presumption among information engineers that everything is just a version of a computational process is a subject for further discussion at a later time (and the winner of the debate receives the Golden Nerd Award); the point here is that it is safer to think of DFD "processes" as processing steps.
DFDs offer a way to check the completeness of your process model, particularly as regards your understanding of the data that would be required by an information system. It should be clear that the needed data are clearly projected on the DFD and if their processing step procedure could be used by subsequent steps and if all the data present in the DFD are usable by an information system. DFDs can provide a fast way to generate further questions that need to be asked about the process.
* Processing, not processes
DFDs refer to "process" steps. It might be more useful to think of DFD "processes" as processing steps rather than process activities. In essence, DFDs ask one to refer to the information systems implications of any processing work that occurs during the tasks that comprise a business process. DFD terminology tends to confuse the term "process" in its connotation with business process with the term "process" that refers to a computational process executing within software. Whether this represents the presumption among information engineers that everything is just a version of a computational process is a subject for further discussion at a later time (and the winner of the debate receives the Golden Nerd Award); the point here is that it is safer to think of DFD "processes" as processing steps.
* Patterns
DFDs can provide a shorthand for understanding patterns that exist within the data flows supporting business processes. They can show, for example, where large amounts of data are collected, stored, transferred, generated, used, and delivered. They can highlight areas of potentially extraneous activity, and can suggest process components that do not receive the information support that they deserve (or need).
DFDs can provide a shorthand for understanding patterns that exist within the data flows supporting business processes. They can show, for example, where large amounts of data are collected, stored, transferred, generated, used, and delivered. They can highlight areas of potentially extraneous activity, and can suggest process components that do not receive the information support that they deserve (or need).
* Comprehensive
When creating a DFD, the analyst should consider if the whole DFD may be easily understood by the audience specially the intended readers.
References:
http://faculty.babson.edu/dewire/Readings/dfddiag.htm
http://en.wikipedia.org/wiki/Data_flow_diagram
http://en.wikipedia.org/wiki/Systems_analyst
0 comments:
Post a Comment