- The Seven Basic Principles
- Scope of Subject Matter That Can Be Handled by IDEF0
- Benefits Resulting from the Use of IDEF0
- Features of IDEF0 Analysis
- Comparison to Data Flow Diagramming
- Understanding a Top-Level IDEF0 Diagram of an Enterprise
- Levels of Abstraction in IDEF0 Models
- The Role of Data Analysis Compared to IDEF0 Function Analysis
This chapter is from the book
This chapter is from the book
This chapter is from the book
Comparison to Data Flow Diagramming
Most popular in past decades, the data flow diagram approach to modeling a computer software system is still used today for software design. It provides a picture of the data that are input to and output from the software. Figure 3-3 shows that Location of Assembly and Quality Measurements are input to a Scheduling Database of information about the status of a part. When a process has been completed, the assembly machine sends a “Process Complete” Status signal to the database, as an additional input. Thus, the database has a running record of where the part is located and which processes have been performed. As output, the software produces a report on the status of the part.
)
Figure 3-3: A Data Flow Diagram to Track Assembly Status.
Figure 3-4 shows the same information as Figure 3-3, but this time as an IDEF0 diagram.
)
Figure 3-4: Same Track Assembly Status Data Flow Using IDEF0 Format.
Note that the interfaces between the activity boxes in the IDEF0 diagram are represented by arrows, depicting one activity supplying input to or controlling one or more other activities (as we shall see in Figures 3-5 through 3-7). Unlike the simpler data flow diagram, the interactivity relationship can include data flow, raw material flow, management and other forms of control, resources (such as people, machines, and computers), and whatever else must be included to model the complete enterprise’s operational details.
)
Figure 3-5: Assembly Status Tracking IDEF0 Diagram, with Physical Parts Assembly Added.
)
Figure 3-6: Previous Diagram, with Controls Added.
)
Figure 3-7: Complete IDEF0 Diagram, with Mechanisms Added.
Figures 3-5 through 3-7 detail information that is not shown on the data flow diagram. Whereas a data flow diagram is adequate to depict information needed by a computer software program, it is not adequate for reengineering purposes, since there are other factors influencing an enterprise’s operations. These other factors must be included if the reengineering process is to be understood and designed, and the changeover process controlled. The IDEF0 model shows what controls each activity and who performs it, as well as the resources needed by each activity.
Figure 3-5 shows the addition of the physical part proceeding through the stages of manufacturing, from Unassembled Part entering box 1 to Completed Part leaving box 3.
Figure 3-6 adds controls to each IDEF0 activity box. For example, we see that there is an Assembly Schedule that controls when the part is prepared for processing. Company Manuals are used to control the remaining three activities. These controls must be carefully considered when making changes, and therefore are important to include in the reengineering effort.
Finally, Figure 3-7 shows what mechanism performs each process. This includes people (for example, Test Engineers for box 3) as well as support tools and systems (for example, Testing Facilities for box 3). A common practice is to document the elements of the enterprise’s organization chart as mechanisms in the model in order to show the assignment of responsibility to specific organizational elements. In the TO-BE picture, the revised organizational responsibility is likewise shown.
An important difference between data flow diagrams and IDEF0 diagrams is the scope of the topic covered: DFDs were intended to depict fine detail needed by a software design specification, whereas IDEF0 diagrams were designed to capture very complex topics such as the operation of the aerospace industry, a government agency, or a business.
IDEF0 syntax may be used to capture fine detail, as we have just shown in the series of diagrams comparing the information content of DFDs to IDEF0 diagrams. However, many of the features of IDEF0 have the objective of handling great complexity, not depicting fine detail. The purpose and viewpoint statements of an IDEF0 model are examples of features that enable handling complexity.
While the purpose of a set of data flow diagrams is to depict the operation of computer software, the purpose of an IDEF0 model may be one of many, since the modeling method is applicable to any “system” comprised of “things” and “happenings.” Focusing the analysis effort by purpose shortens the list of enterprise elements that must be modeled during a reengineering effort. In other words, the analyst must narrow the topic to be modeled and decrease complexity.
An IDEF0 model must also select a specific viewpoint. If all viewpoints of an enterprise were to be included in a single model, the information would be too complex to understand.