IDEF0 Lessons Learned Darold K. Smith UGS Corp, Systems Engineering Consulting Services 4088 County Road 3326; Greenville, TX USA +1.903.883.0781 [email protected] Copyright © 2006 by Darold K. Smith. Published and used by INCOSE with permission. Abstract. The IDEF0 methodology is becoming widely used as a tool in all types of systems. If a program is considering using IDEF0, there are serious pitfalls to avoid to assure that using IDEF0 provides as accurate and complete system definition that IDEF0 is capable of supporting. The pitfalls are illustrated with three case histories to support the lessons learned. Some lessons apply to other methodologies beyond IDEF0. Although IDEF0 has been in use for many years, it is still being applied to new programs and the lessons learned are timely. IDEF0 Background Readers searching for a functional analysis methodology find many favorable statements about IDEF0 methodology and its use for US government projects. Some of these are excerpted below for background reference. "In 1991 the National Institute of Standards and Technology (NIST) received support from the U.S. Department of Defense, Office of Corporate Information Management (DoD/CIM), to develop one or more Federal Information Processing Standards (FIPS) for modeling techniques. The techniques selected were IDEF0 (FIPS-183 1993) for function modeling and IDEF1X (FIPS-184 1993) for information modeling.1" "IDEF0 (Integration DEFinition language 0) is based on SADT™ (Structured Analysis and Design Technique™), developed by Douglas T. Ross and SofTech, Inc. In its original form, IDEF0 includes both a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive methodology for developing models2". IDEF0 is the preferred functional / process modeling methodology cited in the IDEF0 standard and is the graphical diagramming tool used in the Data Standardization Procedures (DoD8320 1998). US Government projects, including Department of Defense (DoD), one of which is the DoD Architecture Frameworks (DoDAF), while not requiring IDEF0 for graphical modeling, use it to illustrate system views. According to the IDEF0 Standard3, "IDEF0 is a modeling technique based on combined graphics and text that are presented in an organized and systematic way to gain understanding, support analysis, provide logic for potential changes, specify requirements, or support systems level design and integration activities. An IDEF0 model is composed of a hierarchical series of diagrams that gradually display increasing levels of detail describing functions and their interfaces within the context of a system. …" 1 IDEF0 Background, p v. 2 IDEF0 IDEF0 Approach, p vii" 3 IDEF0 3.1 Model Concepts, p 19. 1382 "IDEF0 is an engineering technique for performing and managing needs analysis, benefits analysis, requirements definition, functional analysis, systems design, maintenance, and baselines for continuous improvement. IDEF0 models provide a "blueprint" of functions and their interfaces that must be captured and understood in order to make systems engineering decisions that are logical, affordable, integratable and achievable. The IDEF0 model reflects how system functions interrelate and operate just as the blueprint of a product reflects how the different pieces of a product fit together. When used in a systematic way, IDEF0 provides a systems engineering approach to: "1. Performing systems analysis and design at all levels, for systems composed of people, machines, materials, computers and information of all varieties - the entire enterprise, a system, or a subject area …." From the front matter4, "As a function modeling language, IDEF0 has the following characteristics: "1. It is a coherent and simple language, providing for rigorous and precise expression, and promoting consistency of usage and interpretation. (emphasis added)…" IDEF0 Standard Content: The IDEF0 standard contains these sections: 1. Section 3. IDEF0 Models: IDEF0 Model Syntax: Box (activity), Arrows (data), and Labeling Diagramming: Functional Decomposition, Arrow Rules, and Node Trees 2. Appendix A, IDEF0 Concepts: Progressive Decomposition and Disciplined Teamwork 3. Appendix B, User's Guide to Creating IDEF0 diagrams: Applying standards in Section 3. 4. Appendix C, Review Cycle Procedures and Forms: Create Review Materials (Kit) IDEF Model Walk-Through Procedures Tool Availability: One can create IDEF0 diagrams with any basic drawing package, such as Microsoft PowerPoint™, by following the syntax conventions in the standard. A search of the internet for IDEF0 Diagramming Tools produces scores of hits, ranging from basic Visio™ templates to specialized IDEF0 tools. The simpler tools, such as the Visio shapes provided by Microsoft, provide a template of shapes for creating IDEF0 diagrams but that have no methodology enforcement. Users can, through the Visio API capabilities, customize stencils that enforce the IDEF0 standards to a degree. High end specialized IDEF0 tools provide high adherence to the IDEF0 standard and provide "bundling" control of "arrows" (flow) between functions. Methodology Selection Rationale: Based on the above information, many projects select IDEF0 as the functional decomposition methodology. There is also a tendency to select free or low-cost tools because of budget constraints and no perceived need for training, particularly when program managers don't appreciate the need for producing high-quality systems engineering work products. 4 IDEF0 IDEF Approach, p vii. 1383 IDFEF0 Limitations SADT, as developed by Ross, includes two complementary methodologies, activity modeling and data modeling. IDEF0 focuses on the activity modeling. As a source of confusion, one of the few books on SADT (Marca 1988) uses “SADT” interchangeably with IDEF0 but the only passing reference to data modeling is in the preface (DRoss 1988). Thus, in spite of the statements about rigor and precision in the IDEF0 standard as described in the background information above, a number of key elements of the SADT methodology that did support rigor were stripped out in IDEF0, the most significant is data modeling. Several important concepts are not embraced in the IDEF0 standard: Data Store and Data Dictionary. Data, in the context of this paper, is any entity that is an output or input of any function5 and is essential for properly defining or understanding the behavior of the process within the context of the system of interest. IDEF0 classifies data flows into one of four classes, Input, Control, Output, or Mechanism (ICOM) with associated rules of how they are represented and used in activity diagrams6. So what about data store and data dictionary? Data Store: Data stores provide a mechanism for temporarily or permanently storing data for future access by one or more activity. A data store represents a repository that provides the capability of future retrieval of data. Examples of data stores are paper records, computer memory (dynamic and programmable memory, disk and tape storage), databases, physical storage bins for manufacturing processes, energy storage devices (spring, battery, momentum, heat), etc. This lack of data store in IDEF0 as a shortcoming is cited in DoDAF V II (DoDAF VII 2003): "A unique element of a SV-4 not found in an IDEF0 activity modeling is a system data store, which is used as the source or destination (sink) of an information flow in the form of an information repository. For convenience and consistency, DATA-STORE has been incorporated in the CADM as an additional subtype of PROCESS-ACTIVITY.7" Data Dictionary: The concept of a data dictionary was popularized in 1978 by the book Structured Analysis and System Specification (DeMarco 1978). There are two types of data flows, composite and primitive8. It is essential that each composite data flow in the system be defined by its constituent composite and / or primitive data flows and each primitive data flow be unambiguously defined for the purposes intended in the system. In IDEF0, a data dictionary capability is alluded to in the topic Branching Arrows and bundling and unbundling of arrows9 but practitioners that are not familiar with the data dictionary concept are likely to not recognize the concept at all. Data Flow Balancing: Data flow balancing is the process of assuring that all data flows that enter or exit a diagram are accounted for on the corresponding activity on the parent diagram and all data flows that enter or exit a function on the diagram are accounted for in any child diagram. For IDEF0 activity diagrams, this process includes tunneled10 data flows. Although not completely omitted in the IDEF0 standard, the only discussion about this concept 5 Function in this paper includes process and any IDEF0 activity. 6 Inputs are considered consumed or transformed by a function to produce the output(s) of the function. 7 DoDAF V II, p 5-31, CADM Support for Systems Functionality Description (SV-4). 8 Primitive data flows are those that have the lowest level of definition in the system. A primitive data flow for system functional decomposition may be left as a non-elemental definition, i.e., not sufficiently detailed to implement detail design, but sufficient to derive an unambiguous detailed design from. 9 IDEF0 3.3.2.5, p 23, Branching Arrows text and Figure 11 Arrow Fork and Join Structures. 1384 in the IDEF0 standard is in an appendix describing the review process to11 "…test the arrow interface from the parent to the child. "Criteria for acceptance: 1. There are no missing or extra interface arrows. 2. Boundary arrows are labeled with the proper ICOM codes. 3. Child arrow labels are the same or an elaboration of its parent's matching arrow. Labels convey the correct and complete arrow contents. 4. Examination of the connecting arrows reveal no problems in the parent diagram. (An added interface may create a misunderstanding of the message conveyed by the parent.)" Case Histories Three brief case histories are presented that are the source for illustrating the IDEF0 lessons learned. Case 1: Company X Applies IDEF0 to Business Expansion Plans Company X is behind schedule developing requirements for a new and large program.