LUIGIDOLLOSA

10754903

BOOK REVIEW 6

BOOK: Systems Analysis and Design

AUTHORS: Kendall & Kendall

REFERENCE #: QA 76.9 S88 K45 2002

CHAPTER: 9- Using Data Flow Diagrams

QUOTE: “The data flow approach serves as a useful exercise for analysts to enable them to better understand the interrelatedness of all subsystems.”

REVIEW:

     In business organizations, the integral role of making use of a Data Flow Diagram is to clearly illustrate the logical flow of data and information to bring about increased understanding and clarity of an existing system. DFD’s are basically the systems analyst’s tool to implement effective analysis and design to a reference system. Moreover, it allows analysts and other people belonging to a workgroup to understand and comprehend the logicality of a whole system and, as well, its subsystems by the visual representation of related and connected data flows.

     In constructing a very comprehensive Data Flow Diagram, it is a must to firstly be introduced to its basic elements- the symbol and shapes which characterize the data flow, storage, and transformation. A rectangle with soft edges ( aka rounded rectangle), represent any system process (data processing and transformation). To represent a data sender-receiver, or an outside entity to a process, DFD’s employ the shape of a double square. Arrows denote the data movement while a rectangle with an open end represents a database or data storage.

     The prime source of a Data Flow Diagram is a comprehensive system narrative which is comprised of all the details on the data processes and transformations, inputs, outputs, resources and sources, and storage. System analysts extract essential information on this organizational narrative to employ a macro-level analysis of the business process and so as to be able to draw a general context diagram by usage of the said methodology.

     The first phase is drawing of a level 0 data flow diagram wherein the data processes and data storage are included. After which, a child diagram is created by the analyst to each of the processes included in the level 0 DFD. What remain unchanged are the inputs and, as well, the outputs, and the only altered components are the data storages themselves. In order to delve more onto the keenly details of the data flow depictions, analyst ‘explode’ the initial DFD which is accomplished on the previous step.

     From there, the system analyst constructs a physical DFD from the logical DFD, so as to partition it for the implementation of the coding phase. During which, each data process is assessed to categorize it as whether an automated or manual process. If it is identified as an automated procedure, it is clustered to a set of computer programs, either online or batch.

     Other methodologies that further facilitate the creation of a well-constructed Data flow Diagram are event response tables and Use-Case Diagrams. Furthermore, the chapter discussed six particular considerations in DFD partitioning. These include identifying if a process is utilized by user groups, the process is executed in synchrony or the process has similar tasks. Batch data processes can be merged to provide processing efficiency. Likewise, processes can be combined as well in a single program for data consistency. To add, processes can be partitioned also to different programs for security.

     Data Flow Diagrams are advantageous to a great extent due to the simplicity of notation. Moreover, it allows analysts to possess greater information on users. This simply results to system analysts being able to better visualize concrete data movements without the burden of being attached to a distinct physical implementation. This allows them to gain a more conceptual framework of the interrelatedness of the system and its components and to further perform an analysis to an existing system to discern distinct data, information, and defined processes.