MIS 524 - Click here to jump start point
Introduction
Not until the advent of tools that support the application of methods and methodologies to business needs analysis have we been able to accurately define the information system requirements and bridge the gap between information systems requirements definition and software systems development. The new generation of business process analysis and modeling methodologies are supported by robust, relatively low-cost automated tools. This has enabled business area analysts and software professionals to be more effective in capturing "as-is" models of organizational business practices, thus establishing a baseline from which to understand and improve those practices. Additionally, an integrated view or model of the enterprise's information model can be formulated allowing for greater visibility across organizational boundaries, thus providing for elimination of redundant or "stove-piped," software systems. Overall, a more comprehensive view of the information needs of the enterprise can more easily be derived, and a better foundation of requirements can be generated for the software systems development process.
The Integrated DEFinition (IDEF) methodology is a suite or family of methods that supports a paradigm capable of addressing the modeling needs of an enterprise and its business areas. IDEF technologies have grown over the past four to five years, the Department of Defense is a prime user of the technologies, and some of the largest U.S. corporations have adopted the IDEF technologies for competitive advantage. Although IDEF was originally intended for use in systems engineering, the suite of IDEF methods is evolving and contains the necessary notations to support software development. Several attempts to apply these methods to software development have been made. Some have succeeded and several attempts are under way that combine various methods from the IDEF family of methods into a customized methodology. When constructed properly, IDEF0, IDEF1, IDEF1X, and IDEF3 models can be complementary to software engineering paradigms such as information engineering. It is certain that other models from the IDEF family of methods will be applied as software system development efforts demonstrate successes.
Background
IDEF's roots began to form when the Air Force, in response to the identification of the need to improve manufacturing operations, established the Integrated Computer-Aided Manufacturing (ICAM) program in the mid-1970s. The requirement to model functions (processes), data, and dynamic (behavioral) elements of the manufacturing operations resulted in the initial selection of the Structured Analysis and Design Technique (SADT) method (SADT is a registered trademark of SofTech). SADT was developed by SofTech's Doug Ross in the early 1970s. A subset of SADT was the basis for the Air Force's ICAM language notation. A major development from the ICAM program was the Integrated DEFinition methodology or IDEF as it is now called [3]. This methodology was to be used as a regimented approach to analyzing an enterprise, capturing "as-is" process models, and for modeling activities (organizational units) within an enterprise. Thus, an enterprise could develop a basis for process improvement planning and have a foundation to define information requirements.
The IDEF Family of Methods
The IDEF0 method is used to specify function models, which are "what do I do" models. These are descriptive models that show the high-level activities of a process. As shown in Figure 1, the model indicates major activities and the input, control, output, and mechanisms associated with each major activity. IDEF0 models let the modeler portray a view of the process, the inputs (I), controls (C) over the process, outputs (O), and the mechanisms (M) acting on the process (these are collectively referred to as ICOMs, pronounced "eye coms"). The processes can be further decomposed to show lower-level activities and ICOMs, but at some point the required view may require another notation be used to portray such things as branch control.
IDEF1 is used for information modeling, which captures conceptual views of the enterprise's information. It is an analysis method to capture, communicate, analyze, and understand the information needs of the enterprise. The models simply identify the enterprise's concepts of information such as department and employee and the concept that there is a relationship between the two, such as employee works in a department. IDEF1 is not a method for designing the database, but is a tool for the enterprise to understand the information it deals with, so information resource management can be supported.
IDEF1X is used for data modeling, which captures the logical view of the enterprise's data and is based on an entity relationship model. It is a design method for logical database design once the information system requirements are known. The focus is on the actual data elements of the information system to be developed.
IDEF2 Simulation Model Design method is used to represent time varying behavior of resources in a manufacturing system. It has been replaced by various commercial products and notations.
The IDEF3 Process Description Capture method is used to capture behavioral aspects of a system [2]. From domain experts, descriptions are captured in which the precedence and causality relationships between activities and events of the process are shown. Thus, IDEF3 is a structured method used to express how a system or an organization works and show different user views of the system. IDEF3 consists of two modeling modes: the Process Flow Description (PFD), which describes how things actually work in the organization, and the Object State Transition Description (OSTD), which summarizes an object's allowable transitions in a particular process. The PFD provides a process- centric view, and the OSTD view provides, among other elements, entry and exit criteria. These two complementary views more than adequately describe a process.
The IDEF4 object-oriented design method was developed to support the object-oriented paradigm. IDEF4 supports the object-oriented design method. It currently supports design to implement C language applications.
IDEF 5 through IDEF14 have not been pursued in depth at this time. Some academic work has been done in several areas, and the future of these methods is uncertain. IDEF 5 through 14 exist today in various stages and are intended to provide the capability to describe additional views listed in Table 1.
| IDEF0 | Function Modeling |
| IDEF1 | Information Modeling |
| IDEF1X | Data Modeling |
| IDEF2 | Simulation Model Design |
| IDEF3 | Process Description Capture |
| IDEF4 | Object-Oriented Design |
| IDEF5 | Ontology Description Capture |
| IDEF6 | Design Rationale Capture |
| IDEF8 | User Interface Modeling |
| IDEF9 | Scenario-Driven IS Design |
| IDEF10 | Implementation Architecture Modeling |
| IDEF11 | Information Artifact Modeling |
| IDEF12 | Organization Modeling |
| IDEF13 | Three Schema Mapping Design |
| IDEF14 | Network Design |
| Table 1: Suite of IDEF Methods (Current and in Development) [2]. | |
|---|---|
Space does not permit a detailed description of each method. A brief overview of IDEF0 will give you a feel for some process modeling basics associated with IDEF modeling.
IDEF0 Basics
The Integrated Computer-Aided Manufacturing Definition (IDEF) language consists of a variety of notations embodied in a suite of modeling methods. The IDEF0 method is based on a notation for specifying ICOMs, activities, and arrows that represent "data" associated with the ICOMs. Inputs are the typical things such as resources consumed or transformed by a process. Output are the typical things created by the transformations of the inputs by the process. Controls are the standards, policies, guidelines, etc., that guide the process. Mechanisms are the agents (people, manual tools, automated tools, etc.) that accomplish the actions delineated within the process. Figure 1 is an abstract view of IDEF0 notation.
IDEF0 notations are combined into diagrams that describe activation of the activities, not flow. IDEF0 allows for decomposition of diagrams by providing for "exploding" top-level parent diagrams into lower-level child diagrams. The hierarchy of diagrams is maintained via a numbering schema that ties parent and child diagrams. Figure 2 shows this with an A0, A1, and A12 numbering as an example.
A simple use of ICOMs in a high-level IDEF0 functional process model is shown in Figure 3. The overall process represented is a software system modification. In the block numbered A24, (Hold CDR), the process represented is merely a high-level view of a technical review known as the Critical Design Review. Notice that the Input is simply the product or products ("raw materials") to be reviewed ("transformed"), the Output is the approved product (approved design package), the Mechanism is the review team (implied for all reviews but would be an arrow coming into the bottom of the A24 block), and the Controls are the organization's policy on technical reviews (DOD-STD-1521), CDR agenda, etc. Note that the arrows fork, e.g., schedule, allowing "data" to control multiple activities. Not shown is the ability to portray "data" joins. Also note that while the organization's policy document is a source document used by the review team for guidance, it is not "consumed" or transformed by the process. Thus, it is a Control of the process vs. Input to the process. What's missing from this notation is the ability to indicate what entry and exit criteria signify when the process can start and what signals completion of the process. The ICOMs do, however, portray the activation constraints for an activity.
Since IDEF0 presents one view, a question one should pose is can one use other modeling notations in combination with IDEF0. A single notation can be used alone with some degree of success, but using complementary modeling notations is best. IDEF0 and other IDEF notations can be used in a complementary fashion, but IDEF0 can also be used in conjunction with notations of other methods or methodologies. Entry, Task, Validation, eXit (ETVX) modeling is an approach developed in the 1980s by IBM in their Programming Process Architecture project. An IDEF0 model and an ETVX model can be used in a complementary fashion. Figure 3 shows an IDEF0 model for the high-level processes associated with the design work for a software system modification. The IDEF0 processes could be hierarchically decomposed using IDEF0 notation, but the need for a view that shows validation of these decomposed processes exists. One way to show the required view is to complement the IDEF0 process models with ETVX models. An example ETVX model for the Preliminary Design Review block A22 of Figure 3 is shown in Figure 4. The ETVX diagram shows more detail with regard to the specific tasks of the PDR, shows the entry and exit criteria, and indicates the verification and validation required within the PDR process. Note the usefulness of the exit criteria. When viewing PDR as a high-level process, the tendency is to think the PDR is complete when the participants exit the meeting(s). The ETVX diagram allows one to specify in detail what constitutes completion of the review, e.g., items reviewed and approved and action items assigned.
Current Usage
The IDEF methods are just several more additions to the 300 plus methods that already exist. Why was IDEF developed, and why is it evolving? The answer lies partly in the timing of the appearance of IDEF. While many CASE tools existed that could have been (and have been) the basis for a business process modeling paradigm, the IDEF notation was perceived as a "user friendly" notation, and tools were springing up to support the notation. The business user's perception was probably that this notation and tool is for someone like me, and that the other "stuff," called CASE, is for those other guys, the "technobabblers" and "technocrats." Other reasons for the gaining momentum of IDEF are the following. The DoD boosted its support for IDEF under the DoD's Corporate Information Management initiative in which IDEF was chosen as its de facto standard for business process modeling. Various organizations in DoD have committed to the IDEF methodology for business process modeling activities. Other federal agencies with initiatives to reengineer government have bought in. Reported successes with business process modeling, major corporations rightsizing (formerly downsizing), and quality initiatives have driven major corporations to rebuild to remain competitive or even to survive.
Use in Operational Settings
IDEF is used in several areas such as Business Process Engineering (BPE) and Reengineering (BPR), software process definition and improvement, and even in the software development and maintenance arenas.
BPE and BPR are active and dynamic fields where organizations are trying to stay competitive by increasing quality and improving productivity. This entails understanding current processes in order to improve upon those processes and provides an ability to establish a baseline of improved processes from which to restructure and reorganize the enterprise.
Software process improvement is an area where government and industry are aggressively pursuing maturing the organization to increase its capability to develop and maintain high-quality software systems in a timely manner. The underlying processes of the software lifecycle are being modeled and studied to find ways to capture and catalog effective processes, improve those processes, and to provide for process reuse.
The STSC is using IDEF0 in operational settings with Air Force clients of the STSC's process support services. An IDEF0-based process extraction workshop is available. The STSC, using IDEF0, has worked with software support organizations that seek to capture current practices and with organization process action teams involved with general business process improvement.
Software Development Paradigms
Organizations are beginning to use the IDEF methodology as a front end to their software development approach. Capturing the processes, information models, and data models provides a sound basis for designing software systems.
Use in Training Settings
The IDEF methodology can be employed in training as well as in operational settings. The STSC uses IDEF0 in a variety of workshops that provide basic IDEF0 modeling skills. The STSC provides an IDEF0 reader's course, and formal arrangements can be made with the STSC for an IDEF0 authors course.
The STSC recently became authorized to provide the SEI's Defining Software Processes Workshop. While ETVX is the notation used in the course presentations to get basic concepts across, the exercises the students work on during group exercises, in many cases, are accomplished using IDEF0. (Note: Experience in this workshop has shown though that at some point the students need to apply a second notation as the level of abstraction becomes more detailed. ETVX is a good complement to the IDEF models).
Conclusions
For business process modelers, the IDEF methodology offers a well-defined and rigorous approach to capture and understand the organization's operations and its information architecture. This provides a foundation for process reengineering and process improvement.
But for software developers, adoption of new methods and methodologies in the past, in many instances, was due to an element in Pandora's box--hope. This "Pandora's Box Syndrome" and the momentum garnered in the software industry by organizations jumping on the CASE bandwagon led to adopting solutions before understanding the problem to be solved. It is the responsibility of the adopting agency to understand its problem space first, determine the appropriate methods, then, and only then, select a modeling tool. No government-wide mandate to adopt IDEF exists. However, the momentum gathered to date and the ever present "Pandora's Box Syndrome" supports IDEF's continued use, experimentation, and evolution.
Summary
The suite of IDEF notations has developed into a methodology designed to provide the multitude of viewpoints required to adequately describe business area processes and software lifecycle processes and activities.
One notation is insufficient to adequately describe the views, in terms of activities, data, controls, and sequencing, required to adequately define a process. The family of IDEF model notations is currently being developed to expand the capabilities of IDEF for expressing the views necessary to support various process modeling paradigms.
It is beyond the scope of this article to say whether or not the IDEF method is a significant substitute for either the traditional software methodologies practiced today or for the emerging methodologies coming into vogue. It is safe to say that the IDEF process modeling method is useful as a complementary view of the process(es) and dimensions of the software development lifecycle activities being employed.
Robert P. Hanrahan, CCP
Software Technology Support Center
Ogden ALC/TISEA
7278 Fourth Street
Hill AFB, UT 84056-5205
Voice: 801-775-5555, Ext. 3091 DSN 775-5555, Ext. 3091
Fax: 801-777-8069 DSN 777-8069
Internet:
hanrahar@software.hill.af.mil
About the Author
Robert (Bob) P. Hanrahan has been with the STSC for six years. He is an STSC technology domain lead for Process, Software Engineering Environments, and Artificial Intelligence technologies, and is a co-author of several STSC technology reports on Software Engineering Environment and Requirements Analysis and Design technologies. He has recently been authorized by the Software Engineering Institute to present their Defining Software Processes Workshop. Hanrahan holds a bachelor of science in computer technology from New York Institute of Technology and a master of science in computer science from Utah State University. He also holds the prestigious Certified Computer Professional designation awarded by the Institute for the Certification of Computer Professionals. He is currently an adjunct lecturer in the Computer Science and Computer Information Systems programs of Park College, sponsored by the Ogden Air Logistics Center Education Office.
References
Process Support Available
The Air Force Software Technology Support Center's (STSC) process technologies group can provide general process technologies information, lists of process modeling tools for IDEF and other methodologies, training sources, and support group sources. The STSC can assist in identifying IDEF tools, provide names of experienced users of candidate tools organizations are considering, and through formal arrangements, participate substantially in helping to select tools for projects.
The central focal point for IDEF research information in the DoD is the IDEF program office located at Armstrong Laboratory, AL/HRGA, Wright-Paterson AFB, Ohio, 45433, tel. 513-255-9946 or DSN 785-9946. Current and future research directions for the IDEF family of methods are under their purview.
The major support group for the IDEF methodology is the Society for Enterprise Engineering (formerly the IDEF Users Group). This is a nonprofit organization that meets throughout the year at various locations in the United States.