A system flowchart is a concrete, physical model that documents, in an easily visualized, graphical form, the systems discrete physical components (its programs, procedures, files, reports, screens, etc.).
A system flowchart is a valuable presentation aid because it shows how the systems major components fit together and interact. In effect, it serves as a system roadmap. During the information gathering stage, a system flowchart is an excellent tool for summarizing a great deal of technical information about the existing system. A system flowchart can also be used to map a hardware system.
System flowcharts are valuable as project planning and project management aids. Using the system flowchart as a guide, discrete units of work (such as writing a program or installing a new printer) can be identified, cost estimated, and scheduled. On large projects, the components suggest how the work might be divided into subsystems.
Historically, some analysts used system flowcharts to help develop job control language specifications. For example, IBMs System/370 job control language requires an EXEC statement for each program and a DD statement for each device or file linked to each program. Consequently, each program symbol on the system flowchart represents an EXEC statement and each file or peripheral device symbol linked to a program by a flowline implies a need for one DD statement. Working backward, preparing a system flowchart from a JCL listing is good way to identify a programs linkages.
A system flowcharts symbols represent physical components, and the mere act of drawing one implies a physical decision. Consequently, system flowcharts are poor analysis tools because the appropriate time for making physical decisions is after analysis has been completed.
A system flowchart can be misleading. For example, an on-line storage symbol might represent a diskette, a hard disk, a CD-ROM, or some combination of secondary storage devices. Given such ambiguity, two experts looking at the same flowchart might reasonably envision two different physical systems. Consequently, the analysts intent must be clearly documented in an attached set of notes.
The first step in drawing a system flowchart is to identify the systems physical components by using such tools as automation boundaries (# 36). Some analysts prefer to use physical data flow diagrams (# 24) to document physical alternatives. A completed system flowchart is sometimes used to support the project planning stage (Part III). During the design stage (Part VI), a system flowchart serves as a high-level map of the system.
A system flowchart (or system flow diagram) is a concrete, physical model that documents, in an easily visualized, graphical form, the systems discrete physical components (its programs, procedures, files, reports, screens, etc.).
On a system flowchart, each component is represented by a symbol that visually suggests its function (Figure 37.1). The symbols are linked by flowlines. A given flowline might represent a data flow, a control flow, and/or a hardware interface. By convention, the direction of flow is from the top left to the bottom right, and arrowheads must be used when that convention is not followed. Arrowheads are recommended even when the convention is followed because they help to clarify the documentation.
Figure 37.1 System flowcharting symbols.
The symbols in Figure 37.1 conform to the International Organization for Standards (ISO) recommendation R1028 and to the American National Standards Institute (ANSI) Standard X3.5-1970, but other symbols are used, too. A given organization might define a unique internal standard, and some analysts substitute icons (or clip art images of physical components) for the symbols.
The flowchart for a complex system can be quite large. An off-page connector symbol (resembling a small home plate) can be used to continue the flowchart on a subsequent page, but multiple-page flowcharts are difficult to read. When faced with a complex system, a good approach is to draw a high-level flowchart showing key functions as predefined processes and then explode those predefined processes to the appropriate level on subsequent pages. Predefined processes are similar to subroutines.
For example, Figure 37.2 shows a system flowchart for processing a just-arrived shipment into inventory. Note that the shipment is checked (in a predefined process) against the Shipping documents (the printer symbol) and recorded (the rectangle) in both the Inventory file and the Vendor file using data from the Item ordered file.
Figure 37.2 Use predefined processes to simplify a complex system flowchart.
Figure 37.3 is a flowchart of the predefined process named Check shipment. When a shipment arrives, it is inspected manually and either rejected or tentatively accepted. The appropriate data are then input via a keyboard/display unit to the Record shipment program (the link to Figure 37.2). Unless the program finds something wrong with the shipment, the newly arrived stock is released to the warehouse. If the shipment is rejected for any reason, the Shipping documents are marked and sent to the reorder process.
Figure 37.3 A system flowchart for the predefined process named Check shipment.
Figure 37.4 shows one physical alternative for implementing an inventory system. At the top left, a Sales receipt is prepared as output from the Sell appliance predefined process. The data from the Sales receipt are then input to the Inventory program. Subsequently, a printed Cash flow report goes to the Financial system. Below the symbols that represent the system files are procedures to send advertising to customers, perform a physical inventory, process incoming shipments from suppliers, and reorder stock. Except for the predefined processes, each symbol represents one of the systems discrete components at a black-box level.
Figure 37.5 shows a different alternative for the inventory system. In this one, much of the systems logic is incorporated in a single Manage inventory program. Sales transactions, incoming shipments, and advertising still require manual procedures, but clerical personnel access the Manage inventory program to enter data and obtain information.
Figure 37.4 A system flowchart for one alternative inventory system.
Figure 37.5 A second alternative inventory system.
Note that each symbol on a system flowchart represents a discrete hardware component and either software or data. A process symbol (a rectangle) can represent a computer, a program, or both. An on-line storage symbol represents a disk drive, a file, or both. A printer symbol stands for a printer, a report, or both. A display screen represents a display unit, the data displayed on the screen, or both. A given flowline represents a hardware interface and a control or data flow. To further complicate matters, a given symbol might represent multiple components. For example, an on-line storage symbol might imply one or more hard disks, one or more CD-ROMs, or one or more diskettes.
Consequently, it is easy to misinterpret a system flowchart. Detailed notes are often attached to the diagram to clearly explain the creators intent.
The system flowcharts in this # were prepared using Visio. Numerous flowcharting programs are available, including Micrografxs Flowcharter and allCLEAR from SPSS.