IDEF0 methodology

The main of the three methodologies supported by BPwin is IDEF0. IDEF0, refers to the IDEF family, which appeared in the late sixties under the name SADT (Structured Analysis and Design Technique). IDEF0 can be used to model a wide range of systems. For new systems, the use of IDEF0 aims to define requirements and specify functions for the subsequent development of a system that meets the requirements and implements the selected functions. With respect to already existing systems, IDEF0 can be used to analyze the functions performed by the system and display the mechanisms through which these functions are performed. The result of applying IDEF0 to a system is a model of that system, consisting of a hierarchically ordered set of diagrams, documentation text, and dictionaries linked to each other by cross-references. The two most important building blocks of IDEF0 diagrams are the business functions or activities (represented in the diagrams as boxes) and the data and objects (represented as arrows) that link the activities. In this case, the arrows, depending on which side of the work rectangle they enter or which side they exit from, are divided into five types:

· Entry arrows (included in the left side of the work) - depict data or objects that are changed during the execution of the work.

· Control arrows (included in the upper bound of the work) - depict the rules and restrictions according to which the work is performed.

· Exit arrows (go out of the right side of the work) - depict data or objects that appear as a result of the work.

Mechanism arrows (included in the bottom edge of the work) - depict the resources necessary to complete the work, but do not change during the work (for example, equipment, human resources ...)

· Call arrows (go out of the bottom of the work) - depict the relationship between different diagrams or models, pointing to some diagram, where this work is considered in more detail.

All jobs and arrows must be named. The first diagram in the IDEF0 diagram hierarchy always depicts the functioning of the system as a whole. Such diagrams are called context diagrams. The context includes a description of the purpose of the modeling, scope (a description of what will be considered as a component of the system and what as an external influence), and point of view (the position from which the model will be built). Usually, the point of view of the person or object responsible for the operation of the simulated system as a whole is chosen as the point of view.

Figure 7.1. Function block and interface arcs

The activities in the diagrams are shown as rectangles (functional blocks). Each job depicts a function or task and is referred to by a verb or a verb phrase denoting an action, such as "Making a product", "Customer service", etc. The arrows are marked with a noun and represent objects or information that links the works to each other and to the outside world.

After the description of the context, a functional decomposition is carried out - the system is divided into subsystems and each subsystem is described in the same syntax as the system as a whole. Then each subsystem is divided into smaller ones and so on until the desired level of detail is reached. As a result of such a partition, each fragment of the system is depicted on a separate decomposition diagram.

After the context is described, the construction of the following diagrams in the hierarchy is carried out. Each subsequent diagram is a more detailed description (decomposition) of one of the works in the above diagram. An example of context work decomposition is shown in Fig.7.2 and Fig.7.4. The description of each subsystem is carried out by an analyst together with an expert in the subject area. Usually the expert is the person who is responsible for this subsystem and, therefore, thoroughly knows all its functions. Thus, the entire system is divided into subsystems to the desired level of detail, and a model is obtained that approximates the system with a given level of accuracy. Having received a model that adequately reflects the current business processes (the so-called AS IS model), the analyst can easily see all the most vulnerable places in the system. After that, taking into account the identified shortcomings, it is possible to build a model of a new organization of business processes (the TO BE model).

One of the most important features of the SADT methodology is the gradual introduction of increasing levels of detail as the diagrams that represent the model are created.

Figure 7.2, which shows the three diagrams and their relationships, shows the structure of the IDEF0.-model. Each component of the model can be decomposed into a different diagram. Each diagram illustrates the "internal structure" of a block in the parent diagram.

Figure 7.2 - An example of a context diagram

As you can see in Figure 7.2, BPwin allows you to highlight activities and arrows with different colors, as well as link arrow names to the arrows themselves (an arrow named “Reporting”), which increases the visibility and readability of the diagram.

Figure 7.3 - An example of a decomposition diagram

Figure 7.4 - An example of a context diagram

Figure 7.5 - Decomposition Diagram Example

Chart hierarchy

The construction of an IDEF0 model begins with the representation of the entire system in the form of the simplest component - one block and arcs representing interfaces with functions outside the system. Because a single block represents the entire system as a whole, the name given in the block is generic. This is also true for interface arcs - they also represent the complete set of external interfaces of the system as a whole.

Then the block that represents the system as a single module is detailed in another diagram using several blocks connected by interface arcs. These blocks represent the main subfunctions of the original function. This decomposition reveals a complete set of subfunctions, each of which is represented as a block, the boundaries of which are defined by interface arcs. Each of these sub-functions can be decomposed in a similar way for a more detailed view.

In all cases, each subfunction can contain only those elements that are included in the original function. Also, the model cannot omit any elements, i.e., as noted, the parent block and its interfaces provide context. Nothing can be added to it, and nothing can be removed from it.

The arcs entering and exiting a block in a top-level diagram are exactly the same as the arcs entering and leaving a lower-level diagram, because the block and the diagram represent the same part of the system.

Figure 7.6 - Structure of the SADT model. Diagram decomposition

Figure 7.7 - Compliance must be complete and consistent

Some arcs are attached to the diagram boxes at both ends, while others have one end left unattached. Unconnected arcs correspond to the inputs, controls, and outputs of the parent block. The source or destination of these boundary arcs can only be found in the parent diagram. The unattached ends must match the arcs in the original diagram. All boundary arcs must continue on the parent diagram for it to be complete and consistent.

As noted, the mechanisms (arcs on the underside) show the means by which functions are performed. The mechanism can be a human, a computer, or any other device that assists in this function (figure 7.8).

Rice. 7.8. Mechanism example

Each block in the diagram has its own number. A block of any diagram can be further described by a lower level diagram, which, in turn, can be further detailed with the required number of diagrams. Thus, a hierarchy of diagrams is formed.

To indicate the position of any diagram or block in the hierarchy, diagram numbers are used. For example, A21 is a diagram that details box 1 in diagram A2. Similarly, A2 details box 2 in diagram A0, which is the topmost diagram of the model. Figure 7.9 shows a typical diagram tree.

Figure 7.9 - Hierarchy of charts