How to create idef0 diagram. Coursework: Developing a Greenhouse Enterprise Model Using IDEF0, DFD and IDEF3 Design Methodologies. Decomposition diagram A3

Often, developers are asked not only to identify and solve a problem in the company's work, but also to determine what role it plays in the company's structure. Because it is much more important to understand how a malfunctioning unit interacts with others than simply understanding why it is not working properly. Therefore, identifying any problem begins with studying the work of the company and drawing up its functional model.

Often, developers are asked not only to identify and solve a problem in the company's work, but also to determine what role it plays in the company's structure. Because it is much more important to understand how a malfunctioning unit interacts with others than just understanding why it is not working properly. Therefore, identifying any problem begins with studying the work of the company and drawing up its functional model.

You will say that the manager should have a functional model of the company, regardless of what kind of company we are talking about. But, as practice shows, in most cases this model is absent.

Graphics advantage

What are IDEF0 models? Graphic schemes with their own characteristics and the rules for their construction. Why graphics? Because it is effective. This can be seen in several examples.

Let's imagine that the military plan of military operations was explained in words, and not with the help of maps with graphic symbols applied to them. Now it seems impossible, but until the second half of the 19th century it was exactly so. Graphics help to understand what to explain and, accordingly, to understand what is difficult enough.

It's the same with business processes: many technical assignments can be executed in the form of graphical notations, which will significantly simplify the task for developers, and save money for customers.

Benefits of IDEF0 forIT-specialists

Developers' activities, whether it is, for example, installing a CRM or creating an effective ERP, is associated with making changes to an already established system. And in order to do it right, you first need to study how this system works. After studying it, the developer writes a commercial proposal in which he sets out his vision of the situation, the actions necessary to solve the problem, as well as the expected result. Such a document can take more than a dozen pages. On the one hand, this is good, because the client gets the maximum amount of information he is interested in. On the other hand, it takes time to study a lengthy text. successful businessman often not.

So how is it possible to convey the essence without resorting to voluminous texts? Graphics! It is she who allows you to shorten what is written, clearly demonstrating the necessary information. After all, one image can replace hundreds of words. And in relation to the use of graphics in describing business processes, this is 100% true.

Let's first understand what notation and IDEF0 are and what they are for.

Notation for describing business processes: what is it

Notation is a format in which business processes are represented in the form of graphical objects used in modeling, and directly modeling rules. Notation is a kind of graphical language that allows you to represent the functioning of a company, demonstrating the relationship between departments and divisions. That is, the notation can be considered a kind of programming language in business intelligence.

IDEF0 is ...

IDEF0 is a functional modeling method and graphical notation that is used to describe and formalize business processes. The peculiarity of IDEF0 is that this methodology is focused on the subordination of objects. IDEF0 was developed for enterprise automation back in 1981 in the United States.

Functional model of the company

The functional model IDEF0 is blocks, each with multiple inputs and outputs. Each block has controls and mechanisms that are detailed to the required level. The most important function is located in the upper left corner. It connects to the rest of the arrows and function block descriptions. Each arrow or activity has its own meaning. Due to this, such a model is used to describe any administrative and organizational processes.

Arrow types

Incoming tasks are set.

Outgoing display the result of the activity.

Managers(arrows from top to bottom) are control mechanisms.

Mechanisms(arrows from bottom to top) are used to carry out the necessary work.

When working with a functional model, the following rules are adopted. For example, arrows are named with nouns (rules, plan, etc.), blocks - with verbs (keep records, conclude an agreement).

IDEF0 allows you to exchange information, while due to its versatility and visibility, the exchange participants will easily understand each other. IDEF0 has been carefully developed and improved, you can work with IDEF0 using various tools, for example, ERWIN, VISIO, Bussines studio.

IDEF0 also has an undeniable advantage. This technique was developed relatively long ago, and over three decades it has undergone thorough grinding and adjustment. Therefore, it is possible to create a functional model of a company quickly and with a minimum probability of error.

Naturally, there are other methodologies, so why do we recommend IDEF0? You can cut off a piece of metal pipe with a hacksaw, but, you see, it is much easier to do this with a grinder. The same with IDEF0: there is no more functional tool for modeling, with it you can easily and quickly get the result you need.

How a functional model is created

Let's analyze the creation of a functional model using the example of writing an article.

Main unit will be called "Article Writing".

What is needed to write an article is reflected in incoming arrows- "Experience", "Further reading".

Control arrows for writing an article - "Outline of the article", "Requirements for registration", "Rules of the Russian language".

Mechanisms are directly the author himself, copywriter, editor, software. How are these mechanisms organized? The author creates the text by recording its audio version. The copywriter transfers the text to text format, focusing on the publication plan, observing the requirements of the publisher and the rules of the Russian language. Then the editor is connected to the work, who checks the article, correcting speech, spelling and punctuation errors. Software is the programs and tools that the participants in the process used to create the article.

All of the above is only a general scheme of work, so it needs to be detailed.

Let's go back to our model and decompose the common block into several related elements.

So, the whole process of writing an article can be divided into 4 stages:

1. Prepare an audio version.
2. Prepare printed text.
3. Editing and preparing text for printing.
4. Publication of the article.

The diagram reflects information about which controls and mechanisms are involved at which stage. For example, in order to create a quality text, the author uses his own experience and knowledge, as a guide uses the publication plan and the requirements of the publisher. The copywriter, creating the printed version of the text, and the editor, when correcting it, use the rules of the Russian language. To publish an article, for example, in an online publication, special software is required.

When preparing a functional model, the performer is guided by the purpose of its creation and his point of view.

Functional modeling is effectively used in making various management decisions. In our example of the article writing process, there are two specialists - a copywriter and an editor. And with the necessary optimization of project financing according to the scheme, it is not difficult to determine how to do this. The copywriter and the proofreader have similar working methods, so all the work can be offered to the copywriter, since he works directly with the audio text, which the editor cannot do. In this case, the copywriter can be offered to do this work for half of the amount that was intended for the editor. Yes, from this, the quality of the text may be lost, but the optimization task was completed successfully. And it would be more difficult to do this without a visual diagram.

Notation creation processIDEF0

There are many programs for creating notations. Some are designed to create functional models, while others allow you to work with any graphic objects. And for someone, at the first stage, a sheet of paper, a pencil and an eraser is enough.

Before proceeding to the description of the company's work, that is, directly to the creation of the notation of business processes, one should study the principles of the company's functioning. For this, an interview is conducted by a third-party specialist. First of all, the head of the company answers the question, then the specialists who supervise other stages of work.

The first stage of work results in two notations. One will reflect business processes in their original form. This notation will be created based on the results of the interview, and each detail must be agreed with the head of the company and its employees. It is imperative that your understanding of the existing business processes in the company coincides with reality, this requires confirmation at all levels.

The second notation can be called "As it should be". It is created on the basis of the first one with changes made in accordance with the task at hand.

IDEF0 standard and its requirements

We talked about the basic requirements of IDEF0 just above.

1. The main element is in the upper left corner.
2. Each element must have incoming and outgoing arrows. Moreover, the incoming arrows are on the left, on the right - the outgoing ones.
3. Control elements are located at the top, mechanisms at the bottom.
4. When placing several blocks on one sheet or screen, subsequent ones are placed to the bottom right of the previous one.
5. Schemes should be created so that the arrows intersect the minimum number of times.

Errors when working with IDEF0

As with any activity, errors occur when performing functional modeling. Let's analyze the most typical ones.

Using multiple colors

It is important to remember that in functional modeling all elements are important, there are no more important or less important ones. When modeling on paper or in one of the computer programs users try to make the diagram more visual by coloring blocks and arrows in different colors... However, in practice, this not only does not make the diagram more visual, but, on the contrary, leads to confusion and to the fact that the perception of what is depicted is distorted.

Therefore, the ideal option is a black and white scheme without the use of additional color options. This not only helps to eliminate misunderstandings, but also disciplines the creator of the model directly, which favorably affects the readability and clarity of the model.

Large number of blocks

When composing a functional model of a company's work, its authors often try to reflect everything, even the smallest details. It turns out a diagram with a huge number of blocks and arrows. As a result, its readability and clarity are reduced.

To avoid this error, use the detail that will be enough to understand the issue. Detailed detailing is prepared only if it is really needed to resolve an important issue.

Changing the structure when fixing errors

When creating a diagram, it is important that more than one process is not left without incoming, outgoing or other important elements. For example, if you want to remove an author from the schema, then you need to remove all elements and arrows directly related to him. If they remain in the scheme, then there will be misunderstanding and confusion, since during detailing they will lead to no one knows where.

The same situation arises with the addition of a block. If you need to fill in any information, check to see if you have provided the required attributes. This should be closely monitored, since when modeling complex business processes, even a slight change in one part will entail changes in another.

Names of blocks and controls

The rules for naming model elements are quite simple, but it is extremely important to remember them: control arrows are called nouns, blocks are called verbs. This rule is written in the IDEF0 standard and helps to avoid confusion and errors.

Benefits of using IDEF0

Visibility. By depicting the work of the company in the form of a diagram, it becomes clear how the company works, where problems can arise and how to prevent their occurrence.

Mutual understanding, exclusion of the possibility of misinterpretation of the scheme. The visibility and accessibility of the functional model, representing the work of the company in the form of blocks and control elements, will help you when discussing with the management of the functioning of their company. By the way, if necessary, a glossary is created for the functional model, which contains all the terms and conventions. Thus, the possibility of misunderstanding between you and the manager, employees of the company is minimized.

Simplicity and time saving when creating a model. Of course, it takes a lot of time to be good at functional modeling. First of all, you need to learn how to present a huge amount of information in the form of a laconic scheme, i.e. be able to filter and compress the original data. But the time and effort spent on training more than pay off later. After all, it won't take much time to create a functional model and present it in an accessible way.

Minimum probability of error. Working according to the IDEF0 standard requires strict adherence to its rules. This disciplines the performer and eliminates the possibility of errors. In addition, any non-compliance with the standard becomes immediately noticeable.

And finally

For two business analysts, functional models can only be the same if the structure of the company is extremely simple. In other cases, the models will differ from one another. This is natural, because each analyst has his own certain experience, his own understanding of the functioning of the company, his own point of view on how to solve the tasks assigned to him. A business analyst develops a functional model from the point of view of a manager, imagines how he would solve the assigned tasks.

In our opinion, the IDEF0 tool will be useful not only for professional business analysts, but also for those who directly analyze their business and strive to build an effective management system.

Learn to see and understand the functional structure of your business!

At present, in Russia, interest in the generally accepted standards of management in the West has sharply increased, however, in real management practice, there is one very indicative moment. Many leaders can still be baffled by the direct question of organizational structure company or about the scheme of existing business processes. The most advanced managers who regularly read economic periodicals, as a rule, begin to draw hierarchical diagrams that are understandable only to them, but in this process they usually quickly come to a dead end. The same applies to employees and managers of various services and functional units. In most cases, the only set of rules set out in accordance with which an enterprise should operate is a set of individual provisions and job descriptions... Most often, these documents were drawn up more than one year ago, are poorly structured and not interconnected and, as a result, simply gather dust on the shelves. For the time being, such an approach was justified, since during the formation of the Russian market economy, the concept of competition was practically absent, and there was no particular need to consider costs - the profit was gigantic. As a result, over the past two years, we have seen a completely understandable picture: large companies that grew in the early 90s are gradually losing their positions, right up to their complete withdrawal from the market. This is partly due to the fact that the enterprise did not implement management standards, the concept of a functional model of activity and mission was completely absent. With the help of modeling various areas of activity, it is possible to efficiently analyze bottlenecks in management and optimize the overall business scheme. But, as you know, at any enterprise, only those projects that directly bring profit are of the highest priority, therefore, it is usually only during a tangible crisis in the management of the company that we are talking about the survey of activities and its reorganization.

At the end of the 90s, when the market was sufficiently competitive and the profitability of enterprises began to fall sharply, managers felt enormous difficulties in trying to optimize costs so that products remained both profitable and competitive. It was at this moment that the need to have before your eyes a model of the enterprise's activity that would reflect all the mechanisms and principles of the interconnection of various subsystems within the framework of one business was clearly manifested.

The very concept of "modeling business processes" came into the everyday life of most analysts simultaneously with the appearance on the market of complex software products designed for complex automation of enterprise management. Such systems always imply a deep pre-project survey activities of the company. The result of this examination is an expert opinion, in which recommendations for elimination are made by separate points. " bottlenecks”In the management of activities. On the basis of this conclusion, immediately before the implementation of the automation system, the so-called reorganization of business processes is carried out, sometimes quite serious and painful for the company. This, and naturally, a team that has developed over the years is always difficult to force to “think in a new way”. Such complex surveys of enterprises are always complex and significantly different tasks from case to case. There are well-tried methodologies and standards for solving such problems of modeling complex systems. These standards include the methodologies of the IDEF family. With their help, it is possible to effectively display and analyze the models of the activity of a wide range of complex systems in various sections. At the same time, the breadth and depth of examination of the processes in the system is determined by the developer himself, which allows not to overload the created model with unnecessary data. V currently The following standards can be attributed to the IDEF family:

IDEF0 is a functional modeling methodology. With the help of the visual graphic language IDEF0, the system under study appears to developers and analysts in the form of a set of interrelated functions (functional blocks - in terms of IDEF0). Typically, IDEF0 modeling is the first step in learning about any system;

IDEF1 - a methodology for modeling information flows within the system, which allows you to display and analyze their structure and relationships;

IDEF1X (IDEF1 Extended) is a methodology for building relational structures. IDEF1X belongs to the type of methodologies "Entity-relationship" (ER - Entity-Relationship) and, as a rule, is used to model relational databases related to the system in question;

IDEF2 is a methodology for dynamic modeling of systems evolution. Due to the very serious difficulties of analyzing dynamical systems, this standard was practically abandoned, and its development was suspended at the very initial stage. However, at present there are algorithms and their computer implementations that make it possible to transform a set of static IDEF0 diagrams into dynamic models based on “colored Petri nets” (CPN - Color Petri Nets);

IDEF3 is a methodology for documenting the processes occurring in the system, which is used, for example, in the study of technological processes in enterprises. IDEF3 describes the scenario and workflow for each process. IDEF3 has a direct relationship with the IDEF0 methodology - each function (functional block) can be represented as a separate process by means of IDEF3;

IDEF4 is a methodology for building object-oriented systems. IDEF4 tools allow you to visually display the structure of objects and the underlying principles of their interaction, thereby allowing you to analyze and optimize complex object-oriented systems;

IDEF5 is a methodology for the ontological study of complex systems. Using the IDEF5 methodology, the ontology of a system can be described using a specific vocabulary of terms and rules, on the basis of which reliable statements about the state of the system under consideration at a certain point in time can be formed. Based on these statements, conclusions are drawn about further development system and its optimization is carried out.
In this article, we will look at the most commonly used functional modeling methodology IDEF0.

The history of the IDEF0 standard

The IDEF0 methodology can be considered the next stage in the development of the well-known graphical language for describing functional systems SADT (Structured Analysis and Design Teqnique). Several years ago, a small edition of the book of the same name was published in Russia, which was devoted to describing the basic principles of constructing SADT diagrams. Historically, IDEF0 as a standard was developed in 1981 as part of an extensive industrial automation program called ICAM (Integrated Computer Aided Manufacturing) and was proposed by the US Air Force. The IDEF family of standards itself inherited its designation from the name of this program (IDEF = ICAM DEFinition). In the process of practical implementation, the participants of the ICAM program faced the need to develop new methods for analyzing interaction processes in industrial systems. At the same time, in addition to an improved set of functions for describing business processes, one of the requirements for the new standard was the availability of an effective methodology for interaction within the framework of “analyst-specialist”. In other words, the new method was supposed to provide group work on the creation of the model, with the direct participation of all analysts and specialists involved in the project.

As a result of the search for appropriate solutions, the IDEF0 functional modeling methodology was born. Since 1981, the IDEF0 standard has undergone several minor changes, mostly of a limiting nature, and its last revision was released in December 1993 by the US National Institute for Standards and Technology (NIST).

Basic elements and concepts of IDEF0

The graphic language IDEF0 is surprisingly simple and harmonious. The methodology is based on four main concepts.

The first is the concept of an Activity Box. A functional block is graphically depicted in the form of a rectangle (see Fig. 1) and personifies some specific function within the framework of the system under consideration. According to the requirements of the standard, the name of each functional block must be formulated in the verb mood (for example, “produce services”, not “production of services”).

Each of the four sides of a functional block has its own specific meaning (role), while:

Each functional block within the framework of a single considered system must have its own unique identification number.

Figure 1. Functional block.

The second “whale” of the IDEF0 methodology is the concept of an interface arc (Arrow). Also, interface arcs are often called streams or arrows. The interface arc displays a system element that is processed by a function block or otherwise affects the function displayed by this function block.

The graphical display of the interface arc is a unidirectional arrow. Each interface arc must have its own unique name (Arrow Label). As required by the standard, the name must be a noun turnover.

With the help of interface arcs, various objects are displayed that, to one degree or another, determine the processes taking place in the system. Such objects can be elements of the real world (parts, cars, employees, etc.) or streams of data and information (documents, data, instructions, etc.).

Depending on which of the sides this interface arc is suitable for, it is called “inbound”, “outbound” or “control”. In addition, only functional blocks can be the “source” (beginning) and “sink” (end) of each functional arc, while the “source” can only be the output side of the block, and the “sink” can be any of the three remaining ones.

It should be noted that any functional block, according to the requirements of the standard, must have at least one control interface arc and one outgoing one. This is understandable - each process must follow some rules (displayed by the control arc) and must produce some result (outgoing arc), otherwise it makes no sense to consider it.

When constructing IDEF0 - diagrams, it is important to correctly separate the incoming interface arcs from the control ones, which is often not easy. For example, figure 2 shows the function block “Process workpiece”.

In a real process, the worker performing the processing is given a workpiece and technological instructions for processing (or safety rules when working with the machine). It may be a mistake to think that both the workpiece and the document with technological instructions are incoming objects, but this is not so. In fact, in this process, the workpiece is processed according to the rules reflected in the technological instructions, which should be respectively displayed by the control interface arc.

Figure 2.

Another thing is when technological instructions are processed by the chief technologist and changes are made to them (Fig. 3). In this case, they are displayed as an already incoming interface arc, and the control object is, for example, new industrial standards, based on which these changes are made.

Figure 3.

The above examples emphasize the seemingly similar nature of incoming and outgoing interface arcs, but there are always certain distinctions for systems of the same class. For example, in the case of considering enterprises and organizations, there are five main types of objects: material flows (parts, goods, raw materials, etc.), financial flows (cash and non-cash, investments, etc.), document flows (commercial, financial and organizational documents), information flows (information, data of intent, oral instructions, etc.) and resources (employees, machines, machines, etc.). In this case, in various cases, all types of objects can be displayed by incoming and outgoing interface arcs, which control only those related to the flows of documents and information, and only resources can be displayed by arcs-mechanisms.

The obligatory presence of control interface arcs is one of the main differences of the IDEF0 standard from other methodologies of the DFD (Data Flow Diagram) and WFD (Work Flow Diagram) classes.

The third basic concept of the IDEF0 standard is Decomposition. The decomposition principle is used when breaking down a complex process into its constituent functions. In this case, the level of detail of the process is determined directly by the model developer.

Decomposition allows you to gradually and structured represent the system model in the form of a hierarchical structure of individual diagrams, which makes it less congested and easy to digest.

The IDEF0 model always starts with a view of the system as a whole - a single functional block with interface arcs extending beyond the considered area. Such a diagram with one functional block is called a context diagram, and is denoted by the identifier “A-0”.

The explanatory text for the context diagram must indicate the Purpose of building the diagram in the form of a brief description and fix the point of view (Viewpoint).

Defining and formalizing the purpose of developing an IDEF0 - model is an extremely important point. In fact, the goal identifies the relevant areas in the system under study that should be focused on first. For example, if we model the activities of an enterprise in order to build in the future on the basis of this model information system, then this model will differ significantly from the one that we would develop for the same enterprise, but with the aim of optimizing supply chains.

The point of view defines the main direction of development of the model and the level of detail required. A clear fixation of the point of view allows you to unload the model, abandoning the detailing and research of individual elements that are not necessary, based on the chosen point of view on the system. For example, the functional models of the same enterprise from the point of view of the chief technologist and the financial director will differ significantly in the direction of their detailing. This is due to the fact that, ultimately, the CFO is not interested in the aspects of processing raw materials on production machines, and the chief technologist does not need drawn diagrams. financial flows... The correct choice of point of view significantly reduces the time spent on building the final model.

In the process of decomposition, the functional block, which in the context diagram displays the system as a whole, is drilled in another diagram. The resulting diagram of the second level contains functional blocks that display the main subfunctions of the functional block of the context diagram and is called a child diagram (Child diagram) in relation to it (each of the functional blocks belonging to a child diagram is respectively called a child block - Child Box). In turn, the parent function block is called the parent block in relation to the child diagram (Parent Box), and the diagram to which it belongs is called the parent diagram (Parent Diagram). Each of the sub-functions of the child diagram can be further detailed by a similar decomposition of the corresponding functional block. It is important to note that in each case of decomposition of a functional block, all interface arcs included in this block or outgoing from it are fixed in the child diagram. This achieves the structural integrity of the IDEF0 model. The principle of decomposition is clearly shown in Figure 4. You should pay attention to the relationship between the numbering of functional blocks and diagrams - each block has its own unique serial number on the diagram (the number in the lower right corner of the rectangle), and the designation at the right angle indicates the number of the child diagram for this block ... The absence of this designation means that there is no decomposition for this block.

There are often cases when individual interface arcs do not make sense to continue to be considered in child diagrams below a certain level in the hierarchy, or vice versa - individual arcs have no practical meaning above a certain level. For example, an interface arc depicting a “detail” at the entrance to the function block “Process on lathe”Does not make sense to reflect on the diagrams of higher levels - it will only overload the diagrams and make them difficult to understand. On the other hand, there is a need to get rid of separate “conceptual” interface arcs and not detail them deeper than a certain level. To solve such problems, the IDEF0 standard provides for the concept of tunneling. The Arrow Tunnel designation in the form of two parentheses around the beginning of the interface arc denotes that this arc was not inherited from the functional parent block and appeared (from the "tunnel") only in this diagram. In turn, the same designation around the end (arrow) of the interface arc in the immediate vicinity of the receiver block means the fact that in the child diagram of this block this arc will not be displayed and will not be considered. Most often it happens that individual objects and their corresponding interface arcs are not considered at some intermediate levels of the hierarchy - in this case, they are first “plunged into the tunnel” and then, if necessary, “returned from the tunnel”.

The last of the IDEF0 concepts is the Glossary. For each of the IDEF0 elements: diagrams, functional blocks, interface arcs, the existing standard implies the creation and maintenance of a set of relevant definitions, keywords, narratives, etc. that characterize the object displayed by this element. This set is called a glossary and is a description of the essence of this element. For example, for the “payment order” control interface arc, the glossary may contain a list of fields of the document corresponding to the arc, the required set of visas, etc. The glossary harmoniously complements the graphical language, providing the diagrams with the necessary additional information.

Figure 4. Decomposition of functional blocks.

Principles of limiting the complexity of IDEF0 diagrams

Typically IDEF0 models carry complex and concentrated information, and in order to limit their congestion and make them readable, the corresponding complexity limits are adopted in the corresponding standard:

Limiting the number of functional blocks in the diagram to three to six. The upper limit (six) forces the designer to use hierarchies when describing complex items, and the lower limit (three) ensures that there is enough detail on the corresponding diagram to justify its creation;

Limiting the number of interface arcs suitable for one functional block (leaving one functional block) to four.
Of course, it is not at all necessary to strictly follow these restrictions, however, as experience shows, they are very practical in real work.

Discipline of group work on the development of the IDEF0-model

The IDEF0 standard contains a set of procedures that allow a large group of people from different areas of the modeled system to develop and agree on a model. Typically, the development process is iterative and consists of the following conditional stages:

Creation of a model by a group of specialists related to various areas of the enterprise. This group is called Authors in terms of IDEF0. Building an initial model is a dynamic process during which authors ask competent people about the structure of various processes. Based on the existing provisions, documents and survey results, a draft (Model Draft) of the model is created.

Distribution of the draft for review, approval and comments. At this stage, there is a discussion of the draft model with a wide range of competent persons (in terms of IDEF0 readers) in the enterprise. At the same time, each of the diagrams of the draft model is criticized and commented in writing, and then transferred to the author. The author, in turn, also agrees in writing with the criticism or rejects it, outlining the logic of decision-making and returns the revised draft for further consideration. This cycle continues until the authors and readers come to a consensus.

Model approval. The approved model is approved by the head of the working group in the event that the authors of the model and the readers have no disagreements about its adequacy. The final model is a consistent view of the enterprise (system) from a given point of view and for a given purpose.
The visibility of the IDEF0 graphic language makes the model quite readable for those who did not take part in the project of its creation, as well as effective for holding shows and presentations. In the future, on the basis of the constructed model, new projects can be organized aimed at making changes in the enterprise (in the system).

Features of the national practice of using functional modeling by means of IDEF0

V last years interest in the methodologies of the IDEF family is growing steadily in Russia. I constantly observe this, looking at the statistics of calls to my personal web page (http://www.vernikov.ru), which briefly describes the basic principles of these standards. At the same time, I would call interest in such standards as IDEF3-5 theoretical, and in IDEF0 quite practically justified. As a matter of fact, the first Case-tools allowing to build DFD and IDEF0 diagrams appeared on the Russian market back in 1996, simultaneously with the release of the popular book on the principles of modeling in the SADT standards.

Nevertheless, most executives still regard the practical application of modeling in IDEF standards as a fashion statement rather than an effective way to optimize the existing business management system. Most likely this is due to a pronounced lack of information on the practical application of these methodologies and with the indispensable software bias of the vast majority of publications.

It is no secret that almost all projects for the survey and analysis of financial and economic activity enterprises now in Russia are in one way or another related to the construction automated systems management. Thanks to this, the IDEF standards in the understanding of the majority have become conditionally inseparable from the implementation information technologies, although with their help it is sometimes possible to effectively solve even small local problems, literally with the help of a pencil and paper.

When conducting complex enterprise survey projects, the development of models in the IDEF0 standard allows you to visually and effectively display the entire mechanism of enterprise activity in the desired context. Most important, however, is the collaboration that IDEF0 provides. In my practice, there were quite a few cases when the construction of the model was carried out with the direct help of employees of various departments. At the same time, the consultant explained to them the basic principles of IDEF0 in a fairly short time and taught them to work with the corresponding application software. As a result, employees of various departments created IDEF diagrams of the activities of their functional unit, which were to answer the following questions:

What goes to the unit “at the entrance”?

What functions, and in what sequence, are performed within the unit?

Who is responsible for each of the functions?

What is the executor guided by when performing each of the functions?

What is the result of the unit's work (output)?

After agreeing on draft diagrams within each specific department, they are assembled by the consultant into a draft enterprise model, in which all input and output elements are linked. At this stage, all the discrepancies of individual diagrams and their controversial places are recorded. Further, this model again passes through the functional departments for further coordination and making the necessary adjustments. As a result, in a fairly short time and with the involvement of a minimum of human resources from a consulting company (and these resources, as you know, are very expensive), an IDEF0-model of an enterprise is obtained according to the “As is” principle, and, which is important, it represents an enterprise with positions of employees who work in it and thoroughly know all the nuances, including informal ones. In the future, this model will be transferred for analysis and processing to business analysts who will look for bottlenecks in company management and optimize key processes, transforming the “As is” model into the corresponding “As should be” view. Based on these changes, a final conclusion is made, which contains recommendations for reorganizing the management system.

Of course, such an approach requires a number of organizational measures, primarily on the part of the management of the surveyed enterprise. This is due to the fact that this technique involves the assignment of some employees additional responsibilities on the development and practical application of new methodologies. However, in the end, this pays off, since the additional one or two hours of work of individual employees over several days can significantly save money on paying for consulting services to a third-party company (which in any case will tear away from the work of the same employees with questionnaires and questions). As for the employees of the enterprise themselves, in one way or another, I have not met any expressed opposition on their part.

The conclusion from all this can be done as follows: it is not at all necessary to come up with solutions for standard problems every time. Whenever you are faced with the need to analyze a particular functional system (from a spacecraft design system to the process of preparing a complex dinner), use methods that have been tried and tested over the years. One of these methods is IDEF0, which allows you to solve complex life problems with the help of its simple and understandable tools.

Known today not only in narrow circles, the abbreviation IDEF0 is the first methodology to standardize work on business processes. It was developed in the middle of the last century as part of an aerospace project in the United States and, having shown its effectiveness, has become a federal standard. In our country in 2000, a document was prepared " Functional Modeling Methodology IDEF0. Guidance document Functional Modeling Methodology IDEF0 Guidance Document. Official edition. Gosstandart of Russia RD IDEF0 - 2000. Developed by the Research Center CALS - Technologies "Applied Logistics". Adopted and put into effect by the Resolution of the Gosstandart of Russia 2000, Moscow”, But as a standard it was never approved. Although this did not prevent this methodology from becoming one of the most popular tools for graphical modeling of business processes in our country. In this article, I invite you to review the IDEF0 model and assess the current relevance of this approach.

Basic concepts and abbreviations

Let's understand a little about the names of the key elements of the methodology. The IDEF0 graphic standard is part of the SADT (Structured Analysis and Design Technique) methodology. IDEF is an abbreviation for ICAM Definition, and ICAM is derived from Integrated Computer Aided Manufacturing, which translates as integrated computerization of production. The SADT methodology is a whole family of 15 different models, which together were supposed to allow the study of the structure, parameters and characteristics of production-technical and organizational-economic systems.

IDEF0 is a functional model, which is the core of all other structures, it links together information and material flows, organizational structure, control actions and the very activity of the company. The graphical standard for modeling processes is also called notation. That is, notation is a system of requirements and rules for constructing an activity model in one form or another. Therefore, it is appropriate to call IDEF0 the notation that is part of the SADT methodology.

IDEF0 notation is a fairly rigorous technique that was originally developed, like technical design standards, for manual modeling. Therefore, it contains requirements for the placement of arrows, the format of all elements, the content of the information frame for the IDEF0 diagram, etc. Since the company's activities are a complex multi-level system of actions, there are always many schemes, and an unambiguous systematization and navigation through all elements of the model is required. Now this is done mainly by computer systems that support modeling in this notation. On the territory of Russia, the most famous and available systems today are AllFusion Process Modeler and Business Studio. I plan to devote separate articles to the review of these systems.

Functional block

The central element of the IDEF0 model is the function, which is displayed on the diagram as functional block- a rectangle, inside which the action is indicated in the form of a verbal noun. The action can be very different in scale - from the activities of the company in general and to specific manipulation in particular. Examples: "Production and sale of ceramic tableware" and "Drawing on a product".

Mandatory function block elements in IDEF0

Regardless of the scale of actions, all functions are displayed uniformly and necessarily contain 4 key streams, which are rigidly assigned to the sides of the functional block:

• on the left - inputs or resources used to perform the function;
• on the right - outputs or results of the function execution;
• on top - control actions that determine how and how many results should be produced;
• below - mechanisms that reflect who and with the help of what should do this work.

This approach allows you to save a little on explanations in the diagrams and to achieve unambiguity in the display of flows, which makes the whole model slender.

To build a functional model, the IDEF0 methodology requires the following rules to be observed.

1. Inputs are resources that transfer their value to outputs completely, that is, they are spent on creating a result in full, and mechanisms are resources that transfer their value only partially (equipment through depreciation, and people through wages).
2. Management is a necessary element of the model, since it binds all actions to the company's system of regulations, clearly indicating which rules and requirements must be observed in the process of performing the function. Often this flow is treated formally, but the scheme loses its rigor and sometimes even meaning.
3. Each functional block must have at least one arrow on each side (since there can be no work without resources or results, and an instruction without an executor or instruction will be incomplete).

The considered scheme is a “building block” of the IDEF0 approach. Functional modeling involves a gradual transition from the general to the particular through decomposition. Decomposition is "deepening" into the function under consideration, dividing it into smaller functions. At the same time, when the top-level function is presented in a generalized manner and after it is decomposed, it is appropriate to call it a process.

Context diagram

At the highest level, the company is presented as a "black box" in which some activity takes place, which translates entrances to exits. This level is usually called "", that is, a diagram describing the context of the company's activities. Additionally, the context diagram displays the key characteristics of the entire model.

1. The goal is a specific formulation of the purpose of the model, by which the accuracy of the model construction can be checked in the future.
2. Point of view - on whose face the model is built, since the model is always dependent on its author and focus of attention. If we build a general model of an enterprise, then it is usually presented from the point of view of its director.
3. The model type is an indication of what information is displayed on the diagrams. There can be 2 principal options: AS IS ("as is") or TO BE ("as will be"). This separation is necessary, since we can build models for both the analysis of activity and its transformation. We must be clearly aware of what we are doing, and also convey this information to others.

Thus, the context diagram contains in the most generalized form a description of the company's activities, which is permeated by the flows connecting the company with the outside world. I think we should also dwell on them in more detail.

Main streams

Experience has shown that, despite the seeming simplicity and formality of this level, it is often necessary to stay at it for a long time, since all the results that are significant for the owner and the market must be reflected here. An error can lead to the creation of models that do not fulfill the tasks set for the business. To verify that significant flows are reflected, make sure that all 4 main flow types are present in your diagram.

1. Material: materials and components at the entrance and finished products at the exit.
2. Customer: a potential customer entering and a satisfied customer.
3. Financial: at the entrance, these are usually investments, customer payments (revenue), loans and other income; the output is payments to suppliers, taxes, loan payments and profits.
4. Informational: at the input, these are all flows of information about the external environment (market conditions, competitors' behavior, technological innovation etc.), and the output is the flow of information that the company communicates about itself to the world (all advertising information, as well as all types of reporting to regulatory authorities).

Please note that a company is an open system, and nothing appears or disappears in it. A company is only able to convert incoming streams into outgoing streams, and if it does it well, then an additional cash flow(profit), reflecting, in a sense, the quality of the entire system.

(click to enlarge)

It is good if you highlight each of these types of flows with your own color so that you can easily distinguish the movement of resources and do not miss important points... For example, it is often possible to observe the absence of a client in the company's flows, therefore, work with him is based on a leftover principle - the client often feels like an obstacle for the company's employees, whose tasks are focused on processing the flow of documents.

Control arrows can be represented by only 1 type of flow - information flow, which can be divided into 2 subspecies. The first is documents such as:

• laws and regulations;
• orders, orders;
• instructions and regulations;
• plans;
• design documentation, etc.

The second is undocumented information, which most often includes the requirements of the owners.

And, finally, mechanisms - there are only 2 types of flows: equipment (material) and performers (departments and people). There can be no documents here, just as there can be no people on the control points!

The model provides continuous numbering for navigation. The context diagram is numbered "A-0". In the future, each functional block gets its own number, no matter how deep the decomposition is.

Decomposition

After working out the flows of the context diagram, we can proceed to decomposition. Moving to a level below, as if opening a "black box", we first see a blank sheet with arrows that have been attached to the functional block.

(click to enlarge)

And here the actual functional modeling begins - we must understand what set of actions can connect these flows and ensure that all the requirements are met. The difficulty lies in the fact that there are a lot of actions in the company, and on the diagram we have the right to display no more than 9 functions, otherwise the diagram will become unreadable and, accordingly, useless.

It is not always easy to arrange complex activities in such a way that they remain visual, readable, and at the same time complete. Most often, they resort to dividing the entire variety of processes into main large blocks, the most significant of which are the following.

1. Creation of a product (result).
2. Promotion and sale - working with customer flow.
3. Support for product creation activities are secondary processes that are necessary to comply with government requirements or to ensure the convenience of work (personnel and accounting, transport services, cleaning of premises, etc.).
4. Creation of management flows is the activity of developing management solutions that will determine the requirements for all processes of the company.

The figure below shows the decomposition diagram of our example.

(click to enlarge)

In the diagram, the processes should be arranged diagonally - this is called dominance principle, which implies the arrangement of functional blocks from left to right and from top to bottom - in order of importance or in chronological order. Block numbering is the same.

Further work on the model is similar to the first step - each functional block of the first level is decomposed. The block numbering will contain the number of the first level: A1.1… A1n, A2.1… A2.n, etc.

Conclusions about the relevance of the notation

Within the framework of this article, it was possible to display only the basic concepts of IDEF0-notation using a short example of IDEF0, by which, of course, it is difficult to judge the methodology as a whole. But quite a lot of experience in using this notation in practice allows me to draw the following conclusions.

1. The model has good visualizing potential, but, in my opinion, its greater importance is in the disciplining effect. The rules and limitations incorporated into the methodology force us to develop a systematic and strict attitude to the models, which has a very good effect on the quality of the final result.
2. The model allows you to build communication flows between seemingly not strongly connected things: to connect the front and back office subsystems with management, which is much worse for other notations.
3. The approach is simple and understandable for most of the project participants. Building and reading diagrams in this notation is limited only by the desire to delve into the intricacies of business flows.

Some of the above arguments make one think that this approach is the best and only one for a complete modeling of activities. But do not forget that the functional model is designed only for the upper level of modeling. The use of the IDEF0 notation for the design of work at the performer level leads to the fact that the diagrams are purely illustrative and on their basis it is impossible to build a sensible regulation, since they do not contain:

• concretizing the events of starting and stopping the process;
• conditions for the transition from one action to another;
• the ability to visually display all resources and performers without overloading the diagram with arrows.

Therefore, if you use this notation for the tasks for which it is intended (structuring top-level activities), then IDEF0 is practically the only notation today that allows you to do this meaningfully and accurately.

V project management this modeling standard is most applicable where you need to link different projects or processes with visual flows. At the same time, the graphical model will make it possible to more rationally distribute responsibility and resources by tasks. The logic of the project's tasks, reflected in the diagrams, will help prepare a better quality calendar plan in the form of a Gantt chart.

SADT methodology (Structured Analysis and Design Technique - methodology of structural analysis and design) is a set of methods, rules and procedures designed to build a functional model of a system.

The development of this methodology was initiated by Douglas Ross (USA) in the mid-60s. XX century Since then, system analysts from SofTech, Inc. improved SADT and used it to solve a wide range of problems. Telephone network software, diagnostics, long-term and strategic planning, automated production and design, computer system configuration, personnel training, financial and procurement management are some of the areas where SADT can be used effectively. The wide range of areas indicates the versatility and power of the SADT methodology. In the program "Integration of computer and industrial technologies Integrated Computer Aided Manufacturing (ICAM) by the US Department of Defense has been recognized as a useful SADT. This led to the publication of a part of it in 1981 called IDEF0 (Icam DEFinition), as federal standard to develop software... Under this name, SADT has come to be used by thousands of professionals in military and industrial organizations. The last revision of the IDEF0 standard was released in December 1993. National Institute of Standards and Technology (NIST).

This methodology competes with data flow oriented (DFD) methods in describing the functional aspect of an information system. In contrast, IDEF0 allows:

Describe any systems, not just information systems (DFD is meant to describe software);

Create a description of the system and its external environment before defining the final requirements for it. In other words, with the help of this methodology, one can gradually build and analyze the system even when it is still difficult to imagine its implementation.

Thus, IDEF0 can be applied in the early stages of building a wide range of systems. At the same time, it can be used to analyze functions existing systems and developing solutions for their improvement.

The basis of the IDEF0 methodology is a graphical language for describing processes. A model in IDEF0 notation is a collection of hierarchically ordered and interconnected diagrams. Each diagram is a unit of system description and is located on a separate sheet.

Model (AS-IS, TO-BE or SHOULD-BE) may contain 4 types of charts [ , ]:

Context diagram;

Decomposition diagrams;

Node tree diagrams;

For exposition only diagrams (FEO).

Context diagram (top-level diagram), being the top of the tree structure of diagrams, shows the purpose of the system (main function) and its interaction with the external environment. Each model can have only one context diagram. After the description of the main function, functional decomposition is performed, that is, the functions that make up the main one are determined.

Further, the functions are divided into subfunctions and so on until the required level of detail of the system under study is reached. The diagrams that describe each such fragment of the system are called decomposition diagrams ... After each decomposition session, examination sessions are held - subject area experts indicate the correspondence of real processes to the created diagrams. The found inconsistencies are eliminated, after which they proceed to further detailing the processes.

Node tree diagram shows the hierarchical dependence of functions (works), but not the relationship between them. There can be several of them, since the tree can be built to an arbitrary depth and from an arbitrary node.

Exposure charts are built to illustrate individual fragments of the model in order to display an alternative point of view on the processes occurring in the system (for example, from the point of view of the organization's management).

6.3. Elements of the graphic notation IDEF0

The IDEF0 methodology has found widespread acceptance and application, primarily due to the simple graphical notation used to build the model. The main components of the model are diagrams. They display the functions of the system in the form of rectangles, as well as the connections between them and the external environment by means of arrows. Using only two graphic primitives (rectangle and arrow) allows you to quickly explain the rules and principles of building IDEF0 diagrams to people unfamiliar with this methodology. This advantage allows you to connect and activate the customer's activity in describing business processes using a formal and visual graphic language.

The following figure shows the basic elements of the IDEF0 graphical notation.

Rice. 6.1. Elements of the graphic notation IDEF0

The rectangle represents work (process, activity, function or task) , which has a fixed goal and leads to some end result. The name of the job must express the action (for example, "Manufacturing a part", "Calculation of permissible speeds", "Formation of the list of the centralized house number 3").

The interaction of works between themselves and the outside world is described in the form of arrows. IDEF0 distinguishes 5 types of arrows :

- entrance (English input) - material or information that is used and transformed by work to obtain a result (output). The login answers the question "What is to be processed?" The input can be either a material object (raw materials, a part, an exam ticket) or one that does not have clear physical contours (a query to the database, a question from a teacher). It is assumed that the work may not have any entry arrows. Entry arrows are always drawn as entering the left side of the work;

- control (English control) - control, regulatory and regulatory data that guides the work. The department answers the question "In accordance with what is the work being done?" Management influences the work, but is not transformed by it, i.e. acts as a limitation. As a management, there can be rules, standards, regulations, prices, oral instructions. Control arrows are drawn as part of the upper face of the work. If, when building a diagram, the question arises of how to correctly draw an arrow from above or to the left, then it is recommended to draw it as an input (arrow on the left);

- output (English output) - material or information that represents the result of work. The output answers the question "What is the result of the work?" The output can be either a material object (a part, a car, payment documents, a statement) or an intangible one (data sampling from a database, an answer to a question, a verbal indication). Exit arrows are drawn outgoing from the right side of the work;

- mechanism (eng. mechanism) - resources that perform work. The mechanism answers the question "Who is doing the work or by what means?" The mechanism can be the personnel of the enterprise, the student, the machine, the equipment, the program. The arrows of the mechanism are drawn as entering the lower edge of the work;

- call (English call) - the arrow indicates that some of the work is being done outside the block in question. The exit arrows are drawn out of the bottom edge of the work.

6.4. Types of links between jobs

After determining the composition of functions and the relationships between them, the question arises about their correct composition (association) into modules (subsystems). This implies that each separate function must solve one, strictly a specific task... Otherwise, further decomposition or separation of functions is required.

When combining functions into subsystems, it is necessary to strive for the internal connectivity (between functions within a module) to be as strong as possible, and external (between functions included in different modules) as weak as possible. Based on the semantics of the methodology links, we introduce a classification of links between functions (works). This classification is an extension. The types of bonds are listed in order of decreasing importance (binding strength). In the examples cited, thickened lines highlight the functions between which there is the considered type of connection.

1. Hierarchical relationship (relationship "part" - "whole") takes place between the function and the subfunctions of which it consists.

Rice. 6.2. Hierarchical relationship

2. Regulatory (control, subordinate) communication reflects the dependence of one function on another, when the output of one job is sent to control another. The function from which control leaves should be considered regulatory or controlling, and into which it enters - subordinate. Distinguish direct control link when control is transferred from a higher-level work to a lower-level one (Fig.6.3), and management feedback when control is transferred from the downstream to the upstream (Fig. 6.4).

3. Functional (technological) communication occurs when the output of one function serves as input to the next function. From the point of view of the flow of material objects, this relationship shows the technology (sequence of work) of processing these objects. Distinguish direct connection at the entrance when the output is transferred from the higher-level work to the lower-level one (Fig.6.5), and input feedback when the output is transferred from the downstream to the upstream (Figure 6.6).

Rice. 6.5. Direct connection at the entrance	Rice. 6.6. Input Feedback

4. Consumer communication occurs when the output of one function serves as the mechanism for the next function. Thus, one function consumes the resources generated by the other.

Rice. 6.7. Consumer communication

5. Logical link observed between logically homogeneous functions. Such functions, as a rule, perform the same work, but in different (alternative) ways or using different initial data (materials).

Rice. 6.8. Logical link

6. Collegial (methodical) communication takes place between functions whose operation algorithm is determined by the same control. An analogue of such communication is the joint work of employees of one department (colleagues), subordinate to the chief, who gives instructions and orders (control signals). Such a connection also arises when the algorithms for the operation of these functions are determined by the same methodological support (SNIP, GOST, official regulatory materials, etc.), which serves as a management.

Rice. 6.9. Methodical connection

7. Resource connection occurs between functions that use the same resources for their work. Resource-dependent functions generally cannot run concurrently.

Rice. 6.10. Resource link

8. Information communication takes place between functions using the same information as input.

Rice. 6.11. Information communication

9. Temporary connection occurs between functions that must be executed concurrently before or concurrently after another function.

In addition to the cases indicated in the figure, this connection also takes place between other combinations of control, input and mechanism entering one function.

Rice. 6.12. Temporary connection

10. Random connection occurs when there is little or no specific connection between functions.

Rice. 6.13. Random connection

Of the above types of links, the strongest is the hierarchical link, which, in fact, determines the combination of functions into modules (subsystems). Regulatory, functional and consumer ties are somewhat weaker. Functions with these links are usually implemented in one subsystem. Logical, collegial, resource and informational connections are among the weakest. The functions that possess them, as a rule, are implemented in different subsystems, with the exception of logically homogeneous functions (functions connected by logical connection). Temporary connection indicates a weak dependence of functions from each other and requires their implementation in separate modules.

Thus, when combining functions into modules, the first five types of links are most desirable. The functions associated with the last five links are best implemented in separate modules.

IDEF0 has conventions (rules and guidelines) for creating diagrams to make it easier to read and examine the [,] model. Some of these rules are CASE-supported automatically, others must be manually enforced.

1. Before building a model, it is necessary to decide which model (s) of the system will be built. This implies defining its type AS-IS, TO-BE or SHOULD-BE, as well as defining the position from which the model is built. The "point of view" is best thought of as a place (position) of a person or object, in which one must stand in order to see the system in action. For example, when building a model for the operation of a grocery store, you can choose a seller, cashier, accountant or director from among the possible applicants from the point of view of which the system is being considered. Usually, one point of view is chosen, which most fully covers all the nuances of the system's operation, and, if necessary, FEO diagrams are built for some decomposition diagrams, displaying an alternative point of view.

2. The context diagram displays one block showing the purpose of the system. It is recommended for it to display 2–4 arrows going in and out from each side.

3. The number of blocks on the decomposition diagrams is recommended within the range of 3–6. If there are two blocks in the decomposition diagram, then it, as a rule, does not make sense. With a large number of blocks, the diagram becomes oversaturated and difficult to read.

4. Blocks on the decomposition diagram should be arranged from left to right and from top to bottom. This arrangement allows you to more clearly reflect the logic and sequence of work. In addition, the arrow routes will be less confusing and have a minimum number of intersections.

5. The absence of both control and input arrows for the function is not allowed. This means that the launch of this function is not controlled and can occur at any arbitrary moment in time or never at all.

Rice. 6.14. Function without control and input

A block with only control can be viewed as a call in a program of a function (procedure) without parameters. If the block has an input, then it is equivalent to calling a function with parameters in the program. Thus, a block without control and input is equivalent to a function that is never called for execution in the program.

In fig. 6.7–6.12, displaying fragments of IDEF0 diagrams, there are blocks without input and control. This should not be viewed as an error, as it is implied that one of these arrows must be.

6. Each block must have at least one outlet.

Rice. 6.15. No exit function

Works without results are meaningless and should not be modeled. An exception is the work displayed in the AS-IS model. Their presence indicates the inefficiency and imperfection of technological processes. In the TO-BE model, these works should be absent.

7. When constructing diagrams, you should minimize the number of intersections, loops and turns of arrows.

8. Feedbacks and iterations (cyclic actions) can be depicted using backward arcs. Feedback on the input is drawn by the "lower" loop, feedback on the control - by the "upper" (see Fig. 6.4 and 6.6).

9. Each block and each arrow in the diagrams must have a name. It is allowed to use branching (decomposition) or merging (composition) arrows. This is due to the fact that the same data or objects generated by one job can be used in several other jobs at once. Conversely, the same or homogeneous data and objects generated by different jobs can be used in one place.

Rice. 6.16. Branching arrows

In this case, it is allowed to assign qualifying names to different branches of the arrow after branching (before merging). If any branch after the branch is not named, then its name is considered to correspond to the arrow name recorded before the branch.

So, in fig. 6.16 controls included in the blocks "Manufacturing of parts" and "Assembling the product" have clarifying meanings and are part of more general management"Blueprints". All drawings are used for the operation of the "Quality Control" block.

It is not allowed to draw arrows in the diagram when they are not named before and after branching. In fig. 6.17 the arrow included in the block "Generation of standard lists" does not have a name before and after branching, which is an error.

Rice. 6.17. Wrong naming of arrows

10. When constructing diagrams for better readability, the arrow tunneling mechanism can be used. For example, in order not to clutter up the diagrams of the upper levels (parent) with unnecessary details, in the decomposition diagrams the beginning of the arc is placed in the tunnel.

Rice. 6.18. Tunneling arrows

V this example when building a model of conducting New Year's party the mechanism "two axes" will not be displayed on the diagrams of the upper levels, when reading which a fair question may arise: "Why do we need two axes at the New Year's party?"

Likewise, you can tunnel with the opposite goal - not allowing the arrow to appear on lower-level diagrams. In this case, parentheses are placed at the end of the arrow. In the context diagram (see Fig. 6.21), the "Path Service Engineer" mechanism is tunneled, which is included in the "Determination of Allowable Speeds" block. This decision was made, since the engineer is directly involved in all the work displayed on the decomposition diagram of this block (see Fig. 6.22). In order not to show this connection and not to clutter up the decomposition diagram, the arrow was tunneled.

11. All arrows entering and leaving the block, when building a decomposition diagram for it, should be displayed on it. The exception is tunneled arrows. The names of the arrows dragged onto the decomposition diagram must match the names shown on the top-level diagram.

12. If two arrows run parallel (start from the same facet of one job and end at the same facet of the other job), then, if possible, they should be combined and called a single term.

Rice. 6.19. Merging links

13. Each block in the diagrams must have its own number. To indicate the position of any chart or block in the hierarchy, chart numbers are used. The block on the top-level diagram is denoted by 0, the blocks on the second-level diagrams - by numbers from 1 to 9 (1, 2, ..., 9), the blocks on the third level - by two numbers, the first of which indicates the number of the detailed block from the parent diagram, and the second block number in order on the current diagram (11, 12, 25, 63), etc. The context diagram has the designation "A - 0", the first level decomposition diagram is "A0", the decomposition diagrams of the next levels consist of the letter " A "followed by the number of the block to be decomposed (for example," A11 "," A12 "," A25 "," A63 "). The figure shows a typical diagram tree (node ​​tree diagram) with numbering.

Rice. 6.20. Hierarchy of charts

In modern CASE-tools, work numbering mechanisms are supported automatically. CASE tools also provide automatic construction of node tree diagrams that contain only hierarchical links. The top of such a diagram can be any node (block), and it can be plotted to any depth.

6.6. An example of building an IDEF0 model for a system for determining permissible speeds

Calculating the permissible train speeds is a laborious engineering task. When a train passes any section actual speed the movement of the train should not exceed the maximum permissible. This maximum permissible speed is set based on operating experience and specially conducted tests on the dynamics of movement and the impact on the track of the rolling stock. Not exceeding this speed guarantees the safety of train traffic, comfortable conditions for passengers, etc. They are determined depending on the type of rolling stock (brand of locomotive and type of carriages), parameters of the superstructure (such as rails, ballast, sleepers) and plan (radius curves, transition curves, elevation of the outer rail, etc.). As a rule, to establish the permissible speeds, it is necessary to determine at least two (on straight lines) and five (in curves) speeds, from which the final permissible speed is selected, as the lowest of all calculated. The calculation of these speeds is regulated by the Order of the Ministry of Railways of Russia No. 41 of November 12, 2001 "Standards for the permissible speeds of rolling stock on 1520 (1524) mm gauge railway tracks of the Federal Railway Transport".

As noted, building the IDEF0 model begins with representing the entire system as a simple component (context diagram). This diagram shows the purpose (main function) of the system and the required input and output data, control and regulatory information, and mechanisms.

The context diagram for the problem of determining the permissible speeds is shown in Figure 6.21. To build the model, the BPwin 4.0 product from Computer Associates was used.

Rice. 6.21. Context diagram of the system for determining the permissible speeds (methodology IDEF0)

As background information, on the basis of which the determination of the permissible speeds is carried out, are used:

Project data for a new line or reconstruction project (contains all the information necessary for the implementation of the project, namely mileage, axes of separate points, line plan, etc.);

Detailed longitudinal profile (contains information similar to that discussed above);

Passport of the track distance (contains information similar to that discussed above, as well as information about the upper structure of the track (VSP));

Data on the results of the survey of the track plan by the track measuring car;

List of elevations of the outer rail in curves (contains information about the plan of the track).

Some of the original information can be taken from different sources... In particular, information about the plan (parameters of the curves) can be taken from the project of a new line or a reconstruction project, a detailed longitudinal profile, a passport of the track distance, etc.

Control data are:

Instructions of the head of the track service of the road or the Department of tracks and structures of Russian Railways for the calculation;

Order No. 41, containing normative and reference information, procedure and formulas for determining permissible speeds;

Information about the current or planned train traffic (data on the brands of the circulating locomotives and the types of cars used);

Information about the planned repairs of the track, reconstruction and reorganization of structures and devices.

The result system operation should be:

Sheets of permissible speeds, containing all types of calculated speeds and allowing you to establish the reason for their limitation;

Bulletin of the Order of the head of the road on the establishment of permissible speeds on the tracks and separate points (Order "N") in accordance with the form adopted on the road. The approved Order "N" officially fixes the permissible train speeds;

Standard forms No. 1, 1a and 2, containing the planned permissible speeds for the development of the train schedule.

The speeds contained in Order "H" and standard forms may differ from those calculated and shown in the allowable speed sheets. This is due to the fact that they reflect the speed limits not only by the design of the rolling stock, VSP parameters and curves, but also by the state of devices and structures (deformation of the roadbed, skew of the contact network supports, etc.). In addition, they are adjusted taking into account the planned track repairs, reconstruction and reorganization of structures and devices, etc.

Once built, the context diagram is detailed using a first-level decomposition diagram. This diagram shows the functions of the system that must be implemented within the main function. The diagram for which the decomposition is performed, in relation to the diagrams that detail it, is called parent ... The decomposition diagram in relation to the parent is called subsidiary .

The decomposition diagram of the first level for the problem under consideration is shown in Figure 6.22. As a rule, when constructing a decomposition diagram, the original function (to be decomposed) is divided into 3–8 subfunctions (blocks). In this case, the blocks on the decomposition diagram are recommended to be placed from left to right, top to bottom, so that the sequence and logic of interaction of subfunctions is better visible.

Rice. 6.22. Level 1 Decomposition Diagram (IDEF0 Methodology)

The sequence of performing functions for solving the problem under consideration is as follows:

Input and correction of reference information and data on road sections (blocks 1 and 2);

Preparation of an assignment for calculation (block 3). It indicates for which section and track, as well as the brand of the locomotive and the type of wagons, the calculation should be performed;

Calculation of permissible speeds in accordance with the procedure and formulas specified in Order No. 41 (block 4). The initial information is the data along the path of the section (plan, upper structure of the track, etc.) and the standards selected on the basis of the task for the calculation;

Formation of lists of permissible speeds (block 5). Based on the results of the calculation, several types of output documents are created, which, on the one hand, allow to identify the reason for the speed limits, on the other hand, act as the basis for the preparation of regulated documents;

Formation and preparation of the draft Order "N" and standard statements (blocks 6 and 7).

After the first-level decomposition diagram is built, separate diagrams (second-level decomposition diagrams) are built for the functions indicated on it. Then the process of decomposition (building diagrams) continues until further detailing of functions loses its meaning. For each atomic function that describes an elementary operation (that is, a function that does not have a decomposition diagram), a detailed specification is drawn up that defines its features and implementation algorithm. Flowcharts of algorithms can be used to supplement the specification. Thus, the process of functional modeling consists in gradually building a hierarchy of functions.

6.7. ICOM codes

The arrows going into and out of the block in the top-level diagram are the same as the arrows going into and out of the lower-level diagram, because the block and the diagram represent the same part of the system (see Fig. and ). As a consequence, the boundaries of the top-level function are the same as the boundaries of the decomposition diagram.

ICOM codes (acronym for Input, Control, Output, and Mechanism) are for identifying boundary arrows. The ICOM code contains a prefix corresponding to the type of arrow (I, C, O or M) and a sequence number (see figure).

Description of the business process diagrams "Accounting for computer equipment of the enterprise"

Description of IDEF0 diagram

To build a business process, an IDEF0 diagram was used. The IDEF0 methodology prescribes the construction of a hierarchical system of diagrams - single descriptions of system fragments. First, a description of the system as a whole and its interaction with the outside world is carried out (context diagram). Three levels of the diagram were built:

1. Contextual

2. Functional decomposition

Figure 1 - Context diagram "Accounting for enterprise computer equipment"

Figure 1 shows a context diagram of the business process "Accounting for enterprise computer equipment". It displays the system as a whole and its interaction with the main external flows of information.

Arrows are indicated in the context diagram.

Arrow types:

Input (input materials: computers and accessories)

Output (output is a report)

Control arrows are documents and managers

The arrows of the mechanisms are employees and equipment

Input information for processing:

Computers - PCs (personal computers) located in the enterprise

Components - materials required for upgrading computers (video cards, motherboards, processors, cases, power supplies, memory modules)

Output streams:

Report - a ready-made report on the accounting of computer equipment of the enterprise

Input controls:

Rules - conditions that must be met in order to achieve the goal.

Orders - the task assigned to the enterprise (to keep records of computer equipment at the enterprise using certain information systems)

Managers are directors and general managers of the enterprise.

Input Resources:

PC - computers with the help of which accounting is carried out.

Employees are specialists who carry out instructions assigned by management. After constructing a conceptual model, a functional decomposition was carried out - the system is divided into subsystems and each subsystem is described separately (decomposition diagrams).

Figure 2 shows a functional decomposition of four jobs.

Figure 2 - Functional decomposition "Accounting for enterprise computer equipment"

The following types of work were identified:

1) Registration of deliveries - the process in which the id is assigned to the product, sent to storage, to the warehouse and information about the product is entered into the program.

The work Registration of supplies includes seven boundary arrows (entrance, control, mechanism) and an internal arrow leaves (connection by entrance).

Arrow communication at the entrance between the works Registration of deliveries and Maintenance of the computer (computer);

Arrows of entry, exit, control are repeated in subsequent works.

2) Computer maintenance - the process in which the assembly, repair and modernization of computers takes place.

The Computer Maintenance work includes four boundary arrows (input, control, mechanism, output) and several internal arrows (input communication, input feedback).

Arrow control - rules, orders, leader;

Arrow connection at the entrance between the jobs Computer Maintenance and Placement (entering data into the database), between the jobs Computer Maintenance and Reporting (entering data into the database);

3) Placement - the process in which the placement of computers in offices (offices) takes place.

Arrows control - rules, orders, leader;

Arrow mechanism - employees;

Arrow link on input between Spreading and Reporting (assigning an id);

4) Drawing up a report - the final stage of the accounting process, which consists of summarizing totals obtained by performing the previous data of the current accounting.

Then each subsystem is broken down into smaller decompositions, and so on, until the desired degree of detail is achieved.

Figure 3 is a diagram showing the work of Procurement in more detail.

As a result of detailing, the main functions were highlighted. The section "Registration of supplies" includes seven main arrows (entry, exit, control, mechanism).

Arrow entry - computers and accessories;

Control arrows are rules, orders and a leader. Forking arrows;

Mechanism arrows, branching - PC, employees;

Arrows of entry, control, mechanisms are repeated in all works.

1) Assignment of numbers - assignment of individual numbers to computers and accessories.

Entry arrows - computers and accessories. Arrow computers are repeated in subsequent works, except for the compilation of the report;

Control arrows - rules, orders and leader;

Mechanism Arrows - PC and Employees;

Arrow link at the entrance between the works Assigning a number and Sending goods to the warehouse (transfer), between "Assigning a number" and "Putting on the balance sheet" (entering into the base);

2) Sending goods to the warehouse - sending the goods with the assigned number to the warehouse.

Exit Arrow - Computer;

Control arrows - rules, orders and leader.

Arrow link at the entrance between the works "Sending goods to the warehouse" and "Putting on the balance sheet" (quantity);

3) Balancing - entering information into a computer.

Control arrows - rules, orders and leader;

Mechanism Arrows - PC and Employees;

Figure 4 is a diagram detailing computer maintenance in more detail.

As a result of detailing, the main functions performed in the process of Computer maintenance were highlighted.

The computer maintenance work includes 4 boundary arrows (input, output, control, mechanism). Internal arrows (input feedback, input communication).

1) Assembly of computers - configuration of computers for individual orders of managers.

Login arrow - computers;

Control arrows - rules, orders and leader;

Mechanism Arrows - Employees;

Arrow link at the entrance between the works: "Assembling computers" and "Repairing computers" (computer);

2) Computer repair - assembly of computers approved for improvement.

Login arrow - computers;

Exit arrow - entry into the base;

Control arrows - rules, orders and leader;

Mechanism Arrows - Employees;

Arrows of entry, exit, control, mechanism are branching;

Arrow link at the entrance between the works: "Computer repair" and "Upgrade" (accessories);

3) Upgrade - improvement, improvement, upgrade of the computer.

Exit arrow - entry into the base;

Control arrows - rules, orders and leader;

Mechanism Arrows - Employees;

Arrows of control, mechanism are branching;

Figure 5 shows the Reporting Chart in more detail. The work decomposition. Reporting includes 4 boundary arrows (input, output, control, mechanisms). Internal arrows (input feedback, input communication).

As a result of the work, the following functions were derived:

1) Data collection - collection of information for analysis and decision making.

Enter arrow - assigning id;

Control arrows - rules, orders and leader;

Arrows of entry, control, mechanism are branching;

Arrow link on the entrance between jobs: Data collection and Data validation (records);

2) Data verification - verification of information and sending it to the preparation of a report.

Login arrow - assigning an id, entering data into the database;

Exit arrow - Report;

Control arrows - rules, orders and leader;

Mechanism Arrows - Employees, PC;

Arrows of entry (assignment of id), control, mechanism are forking;

Input feedback arrow from “Data Check” to “Data Acquisition” (repeated check).

DFD diagram description

The Computer Maintenance work decomposition Figure 1 defines four internal activities, two external entities, and two data stores.

Figure 1 - Computer maintenance

1) Computer assembly - the process of assembling a computer from existing components.

2) Drawing up a report - a process that consists of summarizing the final indicators obtained by performing the work of the current accounting.

3) Diagnostics - performance check

4) Upgrade - improvement, improvement, upgrade of the computer.

External entities: computers and components

Data stores:

1) Warehouse - a place where assembled and upgraded computers are stored.

2) DB - a database that stores all reports and all information about the work done.

We collect information about the computer and select components for its assembly. Then we assemble the computer and send it to the warehouse for storage, but besides that, after assembling it, we can first send it for diagnostics, check for operability, and then only to the warehouse. After diagnosing the assembled computer, we send the data to compile a report on the work done and enter the information into the Database.

We also have another external entity, this is a computer. We send it for modernization, after which it is for diagnostics to check its operability, then we draw up a report and enter information about the work done in the Database. Or, after the modernization, we send the goods to the warehouse, and then we carry out diagnostics, draw up a report and enter the information into the Database.

The work decomposition "Reporting" Figure 2 defines three internal activities, three external entities, and two data stores.

1) Data collection - collection of information about computers and components.

2) Validation - checking the data for accuracy.

3) Report - writing a report on the work done.

External entities: components, computers, manager.

Data warehouse - Data about computers and components, report data.

Collecting information about computers and accessories, then sending them for storage. After that, we check the data for accuracy, draw up a report and send it back for storage to the first data warehouse (Figure 2), or send the report data to the second data warehouse (Figure 2) and then send it to the manager for verification.

The manager checks, makes notes, corrections and sends for re-checking. After that, the report is sent for storage until the manager is re-checked.

Description of IDEF3 diagram

In the work decomposition Computer maintenance (Fig. 1), several intersections are defined that connect one or several jobs, several internal jobs.

1) Repair - assembling the computer with prefabricated components

2) Assembly - bringing the computer back to normal

3) Upgrade - computer upgrade

4) Computers - a product after assembly and modernization

5) Send to warehouse - send to storage after improvement (assembly)

6) Diagnostics - performance check.

7) Report - information about the work done.

Intersections - Connectors:

1) J2 - all actions start at the same time.

2) J6 - Confluence Junction. A node that collects many arrows into one, indicating the need for the condition of completing the work-sources of arrows to continue the process.

3) J7 - it is shown that these conditions cannot be simultaneously fulfilled.

4) J9 - these actions end at the same time after which a report on the work done is drawn up.

The IDEF3 diagram shows that the J2 junction has two branching arrows for work (build and upgrade) that start at the same time. Only after these works are completed, the finished product (computer) comes out, connects the J6 intersection. After that, there is a connection at the intersection J7, which shows that two works (sending goods to the warehouse and diagnostics) cannot be performed simultaneously. After completing the previous work, the process of drawing up a report on the work is underway, which is connected by the junction J9.