Posts

Showing posts from December, 2010

Data Flow Diagram - How to Evaluate DFD for Correctness

Evaluating Data Flow Diagrams for Correctness It is essential to evaluate all DFDs carefully to determine if they are correct. Errors, omissions and inconsistencies can occur for several reasons, including mistakes in drawing the diagrams. But the presence of what appears to be an error may in fact point out a deficiency in the system or a situation in which users are not aware of how certain processes operate. These questions are useful in evaluating data flow diagrams: ·    Are there any unnamed components in the data flow diagram (data flows, processes, stores, inputs or outputs)?             ·    Are there any data stores that are input but never referenced?             ·    Are there any processes that do not receive input?             ·    Are there any processes that do not produce output?             ·    Are there any processes that serve multiple purposes? If so, simplify by exploding them into multiple processes that can be better st

Data Flow Diagram - Guidelines for Process Naming in DFD

Guidelines for Process Naming ·    Select names that indicate the action taking place. Selecting an action verb and an object to receive the action is most appropriate.             ·    Be sure the name fully describes the process. (If a process both edits and validates invoice data, it should not be labelled EDIT INVOICES).             ·    Select process names that explain the linkage between inflows and outflows of data.             ·    Avoid vague process names, such as PROCESS, REVIEW, ASSEMBLE, HANDLE or ORGANISE.             ·    Use lower-level process names that are much more specific and descriptive than those associated with high-level processes.             ·    Assign process names that are unique to the activity they describe. The process numbering system introduced earlier further identifies processes especially between levels of detail. The highest level diagram (Context) need not be numbered. All lower level diagrams should be

Rules for Drawing Logical DFD

General Rules for Drawing Logical Data Flow Diagrams .    Any data flow leaving a process must be based on data input to the process.             .    All data flows are named; the name reflects that data flowing between processes, data stores, sources and sinks. .    Only data needed to perform the process should be an input to the process. .    A process should know nothing about, that is, be independent of any other process in the system; it should depend only on its own input and output. .    Processes are always running; they do not start or stop. Analysts should assume a process is always ready to function or perform necessary work. .    Output from processes can take one of several forms: a)        An input data flow with information added by the process (for example, an annotated invoice). b)         A response or change of data form (such as a change of  £’s profit to profit percentage. c)         Change of status (from unapproved to

Data Flow Diagram - Phsical DFD to Logical DFD Conversion

Deriving the Logical View Physical DFDs are a means to an end, not an end in themselves. They are drawn to describe an implementation of the existing system for two reasons: ·    to ensure a correct understanding of the current implementation (users are generally better able to discuss the physical system as they know it through people, workstations and days of the week.) ·    the implementation itself may be a problem or limiting factor; changing the implementation, rather than the system concept may provide the desired results. A logical view steps back from the actual implementation and provides a basis for examining the combination of processes, data flows, data stores, inputs and outputs without concern for the physical devices, people or control issues that characterise the implementation. A logical data flow diagram is derived from the physical version by doing the following: ·    Show actual data needed in a process, not the document

Data Flow Diagram - Decomposition Process of DFD

Decomposition of top-level DFDs The Level 1 DFD presents us with an overview of the system, a description that could come from a preliminary interview with departmental managers, perhaps. Now we must examine each process in more detail and break it down into other processes. The following steps explain how this is done. Step 1. Make each process box the system boundary. All data flows to or from that process are now flows across the lower-level system boundary. Step 2. Draw, outside the new boundary, the sources and recipients of these flows, as shown on the higher level DFD, (these can be external entities, data stores or other processes. Ensure the labelling is consistent with the higher level. Step 3. Identify and draw the processes at the lower levels that act on these data flows. Number the sub-processes with a decimal extension of the higher level number. i.e. Level 1, Process 3 will break down to processes 3.1, 3.2, 3.3 etc. Those pro