IDEF0: what is it and how is it used. Building idef3 (and idef0) diagrams - in which program should I do it? Development of a computer program in idef0

Gennady Vernikov

At present, interest in management standards generally accepted in the West has sharply increased in Russia, however, in real management practice, there is one very significant 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 and regularly reading economic periodicals managers, as a rule, begin to draw hierarchical diagrams understandable only to them alone, but in this process they usually quickly come to a standstill. The same applies to employees and heads of various services and functional units. In most cases, the only set of stated rules under which an enterprise must operate is a set of separate regulations and job descriptions. Most often, these documents were compiled more than one year ago, they are poorly structured and unrelated to each other and, as a result, they 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 the costs - the profit was gigantic. As a result of this, over the past two years we have seen a quite understandable picture: large companies, which grew up in the early 90s, are gradually losing their positions, up to a complete withdrawal from the market. This is partly due to the fact that management standards were not introduced at the enterprise, the concept of a functional model of activity and mission was completely absent. Through simulation various areas activities, it is possible to effectively analyze "bottlenecks" in management and optimize the overall business scheme. But, as you know, in any enterprise, only those projects that directly bring profit have the highest priority, so it is usually a question of examining activities and reorganizing it only during a tangible crisis in the management of the company.

In the late 1990s, when the market began to become more competitive and the profitability of enterprises began to fall sharply, managers felt great difficulty in trying to optimize costs so that products remained both profitable and competitive. Just at that moment, the need to have before our eyes a model of the enterprise's activity, which would reflect all the mechanisms and principles of the interconnection of various subsystems within one business, clearly manifested itself.

The very concept of "business process modeling" came into the life of most analysts simultaneously with the appearance on the market of complex software products intended for integrated automation enterprise management. Such systems always involve a deep pre-project survey company activities. The result of this survey is an expert opinion, in which recommendations are made in separate paragraphs to eliminate "bottlenecks" in the management of activities. Based on 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 is, of course, a team that has developed over the years is always difficult to make "think in a new way." Such comprehensive surveys of enterprises are always complex and differ significantly from case to case. There are well-established methodologies and standards for solving such problems of modeling complex systems. These standards include the IDEF family of methodologies. With their help, you can effectively display and analyze the activity models of a wide range of complex systems in various sections. At the same time, the breadth and depth of the examination of processes in the system is determined by the developer himself, which allows not to overload the created model with unnecessary data. Currently, the following standards can be attributed to the IDEF family:

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

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

IDEF1X (IDEF1 Extended) - a methodology for building relational structures. IDEF1X belongs to the Entity-Relationship (ER) type of methodology and is typically used to model relational databases relevant to the system in question;

IDEF2 is a methodology for dynamic modeling of systems evolution. Due to the very serious difficulties in the analysis dynamic systems this standard was practically abandoned, and its development was suspended at the very initial stage. However, currently there are algorithms and their computer implementations, allowing you to turn a set of static IDEF0 diagrams into dynamic models built on the basis of "colored Petri nets" (CPN - Color Petri Nets);

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

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 system ontology can be described using a certain vocabulary of terms and rules, on the basis of which reliable statements about the state of the system under consideration at some point in time can be formed. Based on these statements, conclusions are drawn about further development system and optimize it.
Within the framework of this article, we will consider the most commonly used IDEF0 functional modeling methodology.

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). A few years ago, a small edition of a book of the same name was published in Russia, dedicated to describing the basic principles of constructing SADT diagrams. Historically, IDEF0 as a standard was developed in 1981 as part of an extensive automation program industrial enterprises, which bore the designation ICAM (Integrated Computer Aided Manufacturing) and was proposed by the US Department of the Air Force. The IDEF family of standards itself has 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 "analyst-specialist". In other words, new method was supposed to ensure 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 restrictive, and its last revision was released in December 1993 by the US National Institute of Standards and Technology (NIST).

Basic elements and concepts of IDEF0

The IDEF0 graphical language is remarkably simple and harmonious. The methodology is based on four main concepts.

The first of these is the concept of an Activity Box. The functional block is graphically depicted as a rectangle (see Fig. 1) and represents some specific function within the considered system. According to the requirements of the standard, the name of each functional block must be formulated in the verbal mood (for example, "to produce services" and not "to produce services").

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

The top side is "Control";

The left side is "Input";

The right side is set to "Output";

The bottom side has the value "Mechanism" (Mechanism).

Each functional unit within the single system under consideration must have its own unique identification number.

Figure 1. Function block.

The second "whale" of the IDEF0 methodology is the concept of an interface arc (Arrow). Also, interface arcs are often called flows or arrows. An interface arc represents 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 one-way arrow. Each interface arc must have its own unique name (Arrow Label). According to the standard, the name must be a turnover of a noun.

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

Depending on which side the given interface arc approaches, it is called "incoming", "outgoing" or "controlling". In addition, the "source" (beginning) and "receiver" (end) of each functional arc can only be functional blocks, while the "source" can only be the output side of the block, and the "receiver" can be any of the remaining three.

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 occur according to some rules (displayed by the control arc) and must produce some result (outgoing arc), otherwise its consideration does not make any sense.

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 "Process workpiece" function block.

In a real process, the worker performing the processing is given a workpiece and technological instructions for processing (or safety regulations when working with the machine). It may mistakenly appear that both the workpiece and the document with technological instructions are input objects, but this is not the case. In fact, in this process, the workpiece is processed according to the rules reflected in the technological instructions, which should be respectively depicted 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 already displayed by the 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 controlling 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, verbal orders, etc.) and resources (employees, machines, machines, etc.). In this case, in various cases, incoming and outgoing interface arcs can display all types of objects that manage only those related to the flow of documents and information, and only resources can be displayed as arcs-mechanisms.

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

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

Decomposition allows you to gradually and structuredly represent the system model in the form of a hierarchical structure of individual diagrams, which makes it less overloaded and easily digestible.

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 function block is called a context diagram, and is denoted by the identifier "A-0".

In the explanatory text for the context diagram, the purpose (Purpose) of constructing the diagram in the form short description and fixed point of view (Viewpoint).

Definition and formalization of the IDEF0 development goal - models is extremely important point. In fact, the goal determines the relevant areas in the system under study, which need to be focused 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 determines the main direction of the development of the model and the level of detail required. A clear fixation of the point of view allows you to unload the model, refusing to detail and study individual elements that are not necessary, based on the chosen point of view on the system. For example, functional models of the same enterprise from the points of view of the chief technologist and financial director will differ significantly in the direction of their detailing. This is due to the fact that, in the end, the financial director is not interested in the aspects of processing raw materials on production machines, and the chief technologist is not interested in the drawn schemes of financial flows. Right choice 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 detailed 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 the child diagram is respectively called a child block - Child Box). In turn, the functional block - the ancestor is called the parent block in relation to the child diagram (Parent Box), and the diagram to which it belongs - the parent diagram (Parent Diagram). Each of the subfunctions of the child diagram can be further detailed by a similar decomposition of its 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 on 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 corner indicates the number of the child diagram for this block . The absence of this designation indicates that there is no decomposition for this block.

Often there are cases when it does not make sense to continue to consider individual interface arcs in child diagrams below a certain level in the hierarchy, or vice versa - individual arcs do not make practical sense above a certain level. For example, an interface arc depicting a "detail" at the input to the "Process on" function block. lathe" it does not make sense to reflect on diagrams of higher levels - this will only overload the diagrams and make them difficult to read. On the other hand, it may be necessary to get rid of individual "conceptual" interface arcs and not detail them deeper than a certain level. To solve such problems in The IDEF0 standard provides for the concept of tunneling.The notation "tunnel" (Arrow Tunnel) in the form of two parentheses around the beginning of the interface arc indicates that this arc was not inherited from the functional parent block and appeared (from the "tunnel") only on this diagram. turn, the same designation around the end (arrow) of the interface arc in the immediate vicinity of the receiver block means the fact that this arc will not be displayed and considered in the child diagram of this block. interface arcs are not considered at some intermediate levels of the hierarchy - in this case, they first "dive into the tunnel", and then, if necessary, "return from the tunnel".

The last of the IDEF0 concepts is the Glossary. For each of the elements of IDEF0: diagrams, function blocks, interface arcs, the existing standard implies the creation and maintenance of a set of appropriate definitions, keywords, narrative statements, etc., which 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 control interface arc "payment order", the glossary may contain a list of fields corresponding to the arc of the document, the required set of visas, etc. The glossary harmoniously complements the visual graphic language, providing the diagrams with the necessary additional information.

Figure 4. Decomposition of functional blocks.

Principles for 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 restrictions are adopted in the corresponding standard:

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

Limiting the number of interface arcs approaching 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.

The discipline of group work on the development of an IDEF0 model

The IDEF0 standard contains a set of procedures that allow the development and approval of a model by a large group of people belonging to different areas of activity of the system being modeled. Typically, the development process is iterative and consists of the following conditional steps:

Creation of a model by a group of specialists related to various areas enterprise activities. This group is called Authors in IDEF0 terms. The construction of the initial model is a dynamic process during which the authors ask competent persons about the structure 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 consideration, approvals and comments. At this stage, the draft model is discussed 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 with the criticism in writing or rejects it with a statement of the logic of the decision and again returns the corrected draft for further consideration. This cycle continues until authors and readers reach 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 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 people who did not take part in the project of its creation, as well as effective for demonstrations 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 using IDEF0 tools

In recent years, interest in Russia to the methodologies of the IDEF family has been steadily growing. I constantly observe this when looking at the statistics of hits 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 the interest in such standards as IDEF3-5 theoretical, and in IDEF0 it is quite practically justified. As a matter of fact, the first Case-tools that allow building DFD and IDEF0 diagrams appeared on the Russian market back in 1996, simultaneously with the release of a popular book on the principles of modeling in SADT standards.

However, most managers still regard the practical application of modeling in the IDEF standards more as a tribute to fashion than efficient way optimization existing system business management. This is most likely due to a pronounced lack of information on practical application of these methodologies and with an indispensable software bias of the vast majority of publications.

It is no secret that almost all survey and analysis projects of financial and economic activity enterprises in Russia are now one way or another connected with the construction automated systems management. Due 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 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 an enterprise's activities in the right context. Most importantly, though, is the collaborative capability that IDEF0 provides. In my practical activities there were quite a few cases when the model was built with the direct help of employees of various departments. At the same time, the consultant for enough a short time explained to them the basic principles of IDEF0 and taught them how 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 supposed to answer the following questions:

What enters the unit "at the entrance"?

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

Who is responsible for each function?

What guides the performer in the performance of each of the functions?

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

After coordinating draft diagrams within each specific unit, they are assembled by a consultant into a draft enterprise model, in which all input and output elements are linked. At this stage, all the inconsistencies of individual diagrams and their controversial places are fixed. 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 human resources on the part of a consulting company (and these resources, as you know, are very expensive), an IDEF0 model of the enterprise is obtained according to the "As is" principle, and, importantly, it represents the enterprise from the position 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 search for "bottlenecks" in the management of the company and optimize the main processes, transforming the "As is" model into the corresponding "As it should be" representation. 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 imposing on some employees additional responsibilities on the development and practical application of new methodologies. However, in the end, this justifies itself, since an additional one or two hours of work by individual employees over several days can significantly save money on paying for consulting services from a third-party company (which in any case will interrupt 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 from them in my practice.

The conclusion from all this can be drawn as follows: it is absolutely not 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 the design system spaceship, before 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 using its simple and understandable toolkit to solve complex life problems.

Ministry of Education and Science of the Russian Federation

Federal Agency for Education

State educational institution higher professional education

Course work

"System Modeling"

"Development of a model of a greenhouse enterprise using IDEF0, DFD and IDEF3 design methodologies"

1. The purpose of the work

2. Theoretical introduction

3. Description subject area

4. Description of BPwin

4.1 The principle of building an IDEF0 model

4.2 The principle of building a DFD model

4.3 IDEF3 Model Building Principle

5. Simulation

5.1 Greenhouse model

5.2 Mathematical model

6. Benchmarking

6.1 Methodologies

6.2 Comparison of tools

Literature

1. The purpose of the work

The objectives of this coursework were:

application of methods of pre-project survey of the enterprise;

analysis of the obtained materials for subsequent modeling;

development of a process model in the IDEF0 standard;

description of workflow and information processing in the DFD standard;

descriptions of processes in the IDEF3 standard;

development of a mixed process description model based on IDEFO, DFD and IDEF3 standards.

creation of scenarios for the operation of the enterprise;

construction of the structural scheme of the enterprise;

creation of a mathematical model of this enterprise.

comparative analysis

2. Theoretical introduction

When developing automated control systems at the stages of coding and testing, a large number of errors are revealed, the correction of which entails drastic change throughout the system being developed. Such errors are taken into account in modeling and deep, detailed analysis. created projects. Modeling allows you to "see" the project in the development process and create prerequisites for analyzing the behavior of the system depending on the initial conditions.

For proper coordination of the processes occurring in the simulated control system, it is necessary to create a structure, i.e. streamline processes. Modeling the operation of an information system is especially important in the early stages of its creation. Since the correction of errors made at this stage is the most expensive, the benefits at the stage of problem analysis and the development of a logical model for its solution are significant.

In this regard, it is necessary to study and develop the subject area, namely the work of the greenhouse industry. To do this, you need to understand the terminology of this area, collect the necessary regulatory and legal documents, study the samples of documents of this enterprise and trace their movement both within the enterprise and outside it.

The next stage of development is the design stage. Before starting design and implementation, you need to have an accurate and detailed understanding of the requirements for high level. In addition, it is very useful to have a requirements structure that can be used as input to form the system. All this is achieved through analysis and modeling.

In the course of work at the modeling and design stages, it is necessary to obtain a system project containing enough information for its implementation. It is also necessary to analyze the work of the greenhouse industry, as a result of which it is possible to judge the degree of workload of each department, what needs to be automated in the first place and by what means.

The main objectives of modeling in the development of projects are:

representation of the activities of the enterprise and the technologies adopted in it in the form of a hierarchy of diagrams that provide visibility and completeness of their display;

formation on the basis of the analysis of proposals for the reorganization of the organizational and managerial structure;

streamlining information flows (including workflow) within the enterprise;

analysis of requirements and design of specifications of corporate information systems.

3. Description of the subject area

For consideration in this term paper was taken as a basis for the work of greenhouses. This enterprise specializes in the cultivation of agricultural crops. The sale of products is carried out at the request of the customer.

The organization of work is carried out according to the following scheme:

This diagram shows the departments of the enterprise, their functions and interrelationships. Some of the departments can be automated.

At the head of the entire enterprise is the management, represented by the chief and his deputy. Their main function is to control the activities of the enterprise.

Labor protection service, the main function of which is the training of personnel;

The accounting department is engaged in document management;

The production control service carries out full control at all stages of production;

Sector Maintenance engaged in repair work.

Departments, services and jobs of this enterprise are presented in table No. 1:

table number 1

The tasks and functions of our greenhouse industry are shown in table No. 2:

Table number 2

Documentation is presented in tables No. 3:

table number 3

The directory of organizations is presented in table No. 4:

table number 4

The following is a diagram that describes the scenario of the enterprise with the corresponding conclusions for each of the stages: the customer receives an application for the supply of certain greenhouse products to the sales manager. The sales manager processes this application and makes a decision. In parallel, the accountant calculates the cost of providing services. Once all these stages are completed, the process of concluding a contract begins. The sales manager discusses the terms of the contract with the customer and concludes it. After that, the customer makes a payment. Control over the payment is the responsibility of the accounting department. The accountant receives an extract from the bank, and forms an order to start the execution of the order, which is transferred to the technologist. The technologist, in turn, draws up a plan - a schedule of work and keeps records of the necessary funds. After drawing up a plan - a schedule of work, an order is given to the gardener to carry out land work. The gardener carries out land work and harvests. The harvested crop is sent to the customer. Along the way production cycle the head of the enterprise receives reports on the activities of the sales manager, accountant and technologist. The head controls the entire process of the enterprise, and, if necessary, makes comments on the work of his staff in order to improve the production process and the work of the entire enterprise as a whole.

Scheme of the scenario of the enterprise

4. Description of BPwin

BPwin is a small integrated modeling tool that supports several types of models and methods.

To analyze and reorganize business processes, Logic Works offers a top-level CASE tool - BPwin, which supports IDEF0 methodologies ( functional model), IDEF3 (WorkFlow Diagram) and DFD (DataFlow Diagram). The main of the three methodologies is IDEF0. BPwin has a fairly simple and intuitive user interface, enabling the analyst to create complex models with minimal effort.

BPwin automates the tasks associated with building development models, providing the semantic rigor needed to ensure correct and consistent results. This is achieved by using the following methodologies in BPwin: IDEF0, DFD and IDEF3.

But before engaging in this more complex task, it is really necessary to at least "recalculate" all the elements of the business, that is, to create an organizational structure of the company. The next step is to try to graphically depict the relationships between the various elements of the previously defined structure.

It is possible to build mixed models in BPwin, i.e. a model can contain both IDEFO, IDEF3 and DFD diagrams at the same time. A model in BPwin is viewed as a set of activities, each of which operates on some set of data. Work is shown as rectangles, data as arrows.

All works of the model are numbered. The number consists of a prefix and a number. A prefix of any length can be used, but the prefix A is usually used. The context (root) operation of the tree is numbered A0. The decomposition work A0 is numbered Al, A2, A3, etc. The works of decomposition of the lower level have the number of the parent work and the next serial number, for example, the works of decomposition A3 will have the numbers A3.1 A3.2, AZ.3, A3.4, etc.

As a result of the addition of diagrams, IDEFO diagrams, DFD and IDEF3, a mixed model can be created that best describes all aspects of the enterprise. The mixed model job hierarchy can be seen in the Model Explorer window. Works in IDEFO notation are depicted in green, DFD - blue.

BPwin, as well as local integrated systems, practically do not allow you to perform a comprehensive analysis of systems, which is more or less necessary to create small, medium and large PMIS. With their help, you can develop local IS or small subsystems designed to automate individual business chains, i.e. when there is no need for complex analysis enterprises. A typical area of ​​using small integrated tools is solving problems of the so-called “piecewise” automation of an enterprise.

4.1 The principle of building an IDEFO model

The basis of the IDEFO methodology is a graphical language for describing business processes. A model in IDEFO 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.

The IDEFO model assumes the presence of a clearly defined goal of a single subject of modeling and one point of view.

A model can contain four types of charts:

context diagram (each model can have only one context diagram);

decomposition diagrams;

node tree diagrams;

exposure-only charts (FEO).

The context diagram is the top of the tree structure of diagrams and is the most general description of the system and its interaction with the external environment.

This process is called functional decomposition, and the diagrams that describe each fragment and the interaction of fragments are called decomposition diagrams.

The IDEF0 notation and methodology is based on the concept of a "block", that is, a rectangle that expresses some business function. As you know, a rectangle has four sides. In IDEF0, the roles (functional meanings) of all parties are different:

the top side has the meaning of "control";

left - "entrance";

right - "exit";

lower - "mechanism".

The second element of the methodology and notation is the "flow" (in the standard called "interface arc") - an element that describes data, informal control, or anything else that "influences" the function represented by the block. Depending on which side of the block the flow is directed to, it, respectively, is called "input", "output", "control".

The iconic element representing "flow" is an arrow.

Management - this is what controls the activities of the bureau, in this model being developed - these are the laws on individual PU.

The "input" arrows introduce the functions of the input data; in the context diagram, these are the personal data of the employee.

Arrows "exit" - output data. In the context diagram, this is various information that is submitted to the Pension Fund of the Russian Federation.

The "mechanism" arrow is the data influencing the processes. In the diagram, these are personnel and PC.

After the decomposition of the context diagram, each large fragment of the system is decomposed into smaller ones, with each fragment given a name, and so on, until the desired level of description is reached.

After each decomposition session, examination sessions are held - subject matter experts indicate the correspondence of real business processes to the created diagrams.

Found inconsistencies are corrected, and only after passing the examination without comments, you can proceed to the next decomposition session. This is how conformity is achieved.

All intersections on the diagram are numbered, each number has a J prefix. You can edit the properties of the intersection using the Definition Editor dialog.

4.2 The principle of building a DFD model

Data flow diagrams (DFDs) are the primary means of modeling the functional requirements of a system being designed. With their help, these requirements are broken down into functional components (processes) and presented as a network connected by data flows. the main objective such tools are to demonstrate how each process transforms its inputs into outputs, and to identify the relationships between these processes.

Two different notations are traditionally used to depict DFDs: Yodan (Yourdon) and Gane-Sarson (Gane-Sarson). Further, when constructing examples, Yodan notation will be used, all exceptions will be preliminarily specified.

This methodology (Gane/Sarson methodology) is based on the construction of a model of the analyzed IS - designed or actually existing. In accordance with the methodology, the system model is defined as a hierarchy of data flow diagrams (DFD or DFD) that describe the asynchronous process of information transformation from its input into the system to its issuance to the user. Diagrams of the upper levels of the hierarchy (context diagrams) define the main processes or subsystems of the IS with external inputs and outputs. They are detailed using lower-level diagrams. This decomposition continues, creating a multi-level hierarchy of diagrams, until a level of decomposition is reached at which the processes become elementary and it is impossible to detail them further.

Information sources (external entities) generate information flows (data flows) that transfer information to subsystems or processes. Those, in turn, transform information and generate new flows that transfer information to other processes or subsystems, data storage or external entities - consumers of information. Thus, the main components of data flow diagrams are:

external entities;

systems/subsystems;

processes;

data storage devices;

data streams.

4.3 IDEF3 Model Building Principle

IDEF3 can also be used as a process creation method. IDEF3 complements IDEFO and contains everything you need to build models that can later be used for simulation analysis.

Each job in IDEF3 describes a business process scenario and can be part of another job. Since the scenario describes the purpose and scope of the model, it is important that the works be referred to by a verbal noun denoting the process of action, or a phrase containing such a noun.

The point of view of the model must be documented. Usually this is the point of view of the person responsible for the work as a whole. It is also necessary to document the purpose of the model—the questions the model is intended to answer.

Crossroads. The completion of one job may signal the start of several jobs, or one job may wait for the completion of several jobs to start. Crossroads are used to display the logic of how arrows interact when merging and branching, or to display a set of events that can or must be completed before starting the next job. The types of intersections are presented in the table:

Intersection types

Designation	Name	Meaning in case of merging arrows (Fan-in Junction)	Meaning in case arrow junctions (Fan-out Junction)
||&	Asynchronous AND	All preceding processes must be completed	All of the following processes must be running
||&||	Synchronous AND	All preceding processes completed at the same time	All of the following processes run at the same time
||O	Asynchronous OR	One or more antecedent processes must be terminated	One or more of the following processes must be running
||O||	Synchronous OR	One or more predecessor processes completed at the same time	One or more of the following processes run at the same time
||X		Only one antecedent process completed	Only one next process is started

All intersections on the diagram are numbered, each number has a J prefix. You can edit the properties of the intersection using the Definition Editor dialog. Unlike IDEFO and DFD, in IDEF3 arrows can merge and branch only through intersections.

Link object. A link object in IDEF3 expresses some idea, concept, or data that cannot be associated with an arrow, intersection, or job. To add a link object use the |R| – (add a reference object to the diagram - Referent) in the tool palette. The link object is drawn as a rectangle similar to the job rectangle. The name of the reference object is set in the Referent dialog (name editor pop-up menu item), as the name, you can use the name of some arrow from other diagrams or the name of an entity from the data model. Reference objects must be linked to work units or intersections with dotted lines. The official IDEF3 specification distinguishes three styles of reference objects: unconditional, synchronous, and asynchronous. BPwin only supports unconditional link objects. Synchronous and asynchronous reference objects used in object state transition diagrams are not supported.

5. Simulation

5.1 Greenhouse model

Model Navigator - Model Explorer

Context Diagram:

A0 decomposition diagram:

Decomposition diagram A1:

Diagram IDEF3 A11.1:

Data flow diagram A12:

Decomposition diagram A2:

IDEF3 A21.1 diagram:

Decomposition diagram A3:

A4 decomposition diagram:

Decomposition diagram A5:

Decomposition diagram A6:

A63 Data Flow Diagram:

5.2 Mathematical model

For more detailed description work of the greenhouse economy, it is necessary to compile a mathematical model for the product of the enterprise's activity.

This mathematical model will describe the calculation of the price per unit of goods in different conditions.

e - the cost of a unit of goods, determined by the manufacturer, it includes all costs associated with the production of a unit of goods, the main part of this figure is the purchase price of seeds;

v - the purchase price of seeds, this is the price at which the enterprise purchased seeds from the supplier (section "purchase of seeds");

a - labor cost wage and other expenses within the enterprise);

g - fuels and lubricants (fuel and lubricants);

n - taxes (consumer part) are established by the state and have a fixed rate;

k - VAT, value added tax, also has a fixed rate;

r - retail price, this is the amount of money for which the manufacturer sells a unit of his product on the market, as a rule, the retail price is determined by the cost price with a certain percentage of markup;

s - the company's markup per unit of goods, as a rule, each entrepreneur individually determines its amount, in this case it is 40% of the cost, i.e. (e * 40) / 100

o - wholesale price, this is the amount of money offered per unit of goods, when buying from 100 units, in this case there is a 10% discount from the retail price;

os – discount for bulk purchase (os

Mathematical model for calculating the cost per unit of goods produced:

Mathematical model for calculating the retail price per unit of manufactured goods:

Mathematical model for calculating the wholesale price per unit of manufactured goods:

o=v+a+g+n+k+s - os

o=r - (r*10)/100

The calculation of the cost of products at the enterprise "Greenhouse Economy" is carried out by the accounting department, which controls the document flow, takes into account the income and expenses of the enterprise, maintains accounting books, and issues certificates. Based on these formulas obtained in the mathematical model of the enterprise, the accountant can calculate the price of goods, both retail and wholesale.

6. Benchmarking

To model our enterprise, we used 5 methodologies: Dragon, UML, IDEF0, IDEF3, DFD. In our opinion, the UML methodology is the best way to present the model of our enterprise, as it more clearly and accurately reflects the main aspects of the greenhouse industry.

UML diagrams are relatively easy to read.

For example, the "Use Case" diagram, which was used as a result of the design of the Greenhouse implementation system, allows the customer, end user and developer to discuss the functionality and behavior of the system together. "Class Diagram" allows you to describe the structure of the system, it shows the classes of the system, their attributes, methods and dependencies between classes, which can reveal in detail the scenario and organization of the enterprise.

The Dragon methodology also has a very clear structure, but does not have such wide possibilities for modeling various systems.

Visio is the simplest and most accessible process modeling tool. This product has standard, familiar to all control panels in the style of MS Office and is easily integrated with any application of this package, which makes it easier to work with it for inexperienced users. However, time or cost analysis requires the development of reports, which greatly complicates the use of this product. Typical reports are clearly not sufficient for the analysis of business processes. Despite this, Visio is a common tool for describing business processes both in Russia and abroad. Visio supports IDEF and UML formats for describing business processes. It is also possible to independently develop formats.

BPWIN - occupies an intermediate place, distinguished by its simplicity and great analysis capabilities. The functionality of BPWIN is not only to draw diagrams, but also to check the integrity and consistency of the model. BPWIN provides logical clarity in the definition and description of diagram elements, as well as verification of the integrity of relationships between diagrams. The tool provides correction of the most common errors in modeling. In addition, BPWIN supports custom properties that are applied to chart elements to describe specific properties specific to that element. The main limitation of this system is the IDEF standard underlying it, in which there are severe restrictions when building models. This simplifies the task of describing simple procedures, but complicates the description of large processes. 1DEF schemes, when describing complex processes, begin to present countless interconnected schemes that are very similar in appearance, which makes it difficult to understand the process as a whole.

7. Conclusion:

In the course of this course work, all our goals were achieved.

In this regard, we studied the subject area being developed, namely the work of the greenhouse industry. To do this, it was necessary to understand the terminology of this area, collect the necessary regulatory and legal documents, study the samples of documents of our enterprise and trace their movement both within the enterprise and outside it.

As a result of these activities, information was obtained, on the basis of which an initial analysis was carried out and an outline of the projected model was drawn up.

The next stage of development is the design stage. Before you start designing and implementing, you need to have an accurate and detailed understanding of the requirements at a high level. In addition, it is very useful to have a requirements structure that can be used as input to form the system. All this is achieved through analysis and modeling. By performing analysis and modeling, we achieved a separation of tasks, which in the pre-project state we prepared and simplified for subsequent design and implementation activities. We distinguish between problems that must be solved and decisions that must be made in order to cope with them.

As a result of work at the modeling and design stages, we received a system project containing enough information for its implementation.

After analyzing the work of the greenhouse industry, we can judge the degree of workload of each department, what needs to be automated in the first place and by what means.

To facilitate the work, it is possible to introduce new technologies that will facilitate the work in our farm.

Literature:

Rogozov Yu.I., Stukotiy L.N., Sviridov A.S. "Modeling of systems" TRTU, 2004.

S.V. Maklakov “CASE-tools for the development of information systems. BPwin and Erwin "-M.: DialogMifi, 2001.

Maklakov S. "Combining the structural and object approach in the new generation of Computer Associates CASE tools" // Training and Consulting Center. 2002.

One picture is worth a thousand words

folk wisdom

Of course, in theory, the manager should have a functional model of the company’s work, and it doesn’t matter if we are talking about the organization of the warehouse or the IT system (from lead to request). But in reality, it almost never turns out to be, and therefore, in the process of studying and searching for a solution to the task set by the client, I also create a functional model of the company or a certain process (function) on my own.

A few words about the benefits of graphics

As you know, IDEF0 functional models are always graphic diagrams. They have their own characteristics and rules of compilation. We'll talk about this a little later. And now I would like to give a couple of examples of the effectiveness of graphics. Why am I focusing on this? Most likely, after my statement about the need for a functional model of the company’s work, many people thought that this was not necessary, and it was possible to explain in words how this or that function works in the company. This is what I want to talk about.

And to begin with, let's take a short digression into history. Let's go back to the distant 1877, during the Russian-Turkish war. It was then that the printer Sytin first used graphics in describing military operations. Now all this is familiar to us, when describing any battle, cards with arrows appear before our eyes, which clearly show the course of the battle. And in those days, military operations were described in words. For each fight - many, many words. And it was very difficult to understand in the end what was happening.

That is why Sytin's idea was truly revolutionary - he began to print lithographic copies of maps with the designation of fortifications and locations of military units. These cards were called “For Newspaper Readers. Benefit". The idea turned out to be so relevant that the very first print run of the "Help" sold out instantly. And then such applications were in great demand. The reason is obvious. The graphics helped to understand what was almost impossible to make out with the help of words alone.

I can also cite a similar example of the helplessness of verbal descriptions from my own practice. One of my clients asked me to take on the implementation of an ERM system for his company. When I asked if they had some kind of technical task, I received the answer: “Yes, they do. But it has 400 pages.” At the same time, the client complained very much that my colleagues, whom he contacted earlier, either refused the project altogether, or called clearly inflated prices. After I saw that the terms of reference were indeed 400 pages long and consisted solely of a textual description, I understood the reasons for the developers' behavior. Reading such a volume of text, delving into it, understanding all the nuances just to understand the task and name the price is really very difficult.

I offered this client an alternative option - to describe everything that is possible graphically in the form of notations. Showed him examples of modeling. As a result, they are now rethinking their wishes and the design of the terms of reference.

I also know many other examples when graphic modeling of business processes helped both my colleagues, business consultants and developers, and the businessmen themselves

Why is this important to my work

My work is always related to making changes to the existing system. And in order to make changes and get the desired result, you need to study what already exists. And it doesn't matter what exactly we do - we set up or install a CRM system from scratch, we create an effective ERP system, we integrate various systems to increase the automation of work in general. In any case, to begin with, it is necessary to get an idea of ​​the existing scheme of work, and only after that it is possible to propose some changes and think over options for solving the task.

After studying the current state of affairs, I, like any other third-party specialist, create a commercial proposal in which I reveal in as much detail as possible my vision of the current situation, as well as the actions that need to be taken to solve the task, and, of course, the expected result.

Such work survey reports are voluminous, occupying more than one page, which, on the one hand, is necessary, but on the other hand, complicates perception. At first, like many others, I thought that voluminous reports are good, because a person pays for the work and you need to provide him with as much detailed information as possible.

In fact, it is important not to provide volume, but to convey the essence as quickly and fully as possible. Large volumes of text require time, which businessmen often have very little. And the graphics allow me to reduce the volume of my proposal and clearly, in an understandable form, show the solution. As a result, my proposals were significantly reduced, graphics appeared in them, and decisions on the beginning of cooperation began to be made faster.

It is for this reason that I use visual models. As you know, one picture is worth a thousand words. And in the case of describing business processes and options for modernizing the work of a business, this is true. And IDEF0 notations are very well suited here.

But first, let's understand the basic concepts of what notations are, why they are needed, what IDEF0 is, what are the features and advantages of this method.

What is business process description notation

A notation is a format for describing a business process, which is a set of graphic objects used in modeling, as well as modeling rules.

In fact, notations are a special graphic language that allows you to describe the work of a company, visually demonstrate the interaction between different departments, i.e. describe business processes. Notations can be used for process or functional modeling.

In general, notations can be called a programming language in business analysis.

What is IDEF0?

IDEF0 is a functional modeling methodology and graphical notation designed to formalize and describe business processes. A distinctive feature of IDEF0 is its emphasis on object subordination. IDEF0 considers the logical relationships between jobs, not their temporal sequence (workflow). Wikipedia

The IDEF0 standard was developed in 1981 by the US Department of the Air Force for industrial automation. In the process of software development, developers are faced with the need to develop new methods for analyzing business processes. As a result, the IDEF0 functional modeling methodology appeared, in which special IDEF0 notations are used for analysis.

Functional model of the company

The IDEF0 functional model is a set of blocks, each of which is a "black box" with inputs and outputs, controls and mechanisms that are detailed (decomposed) to the required level. The most important function is located in the upper left corner. And the functions are connected with each other with the help of arrows and descriptions of functional blocks. Moreover, each type of arrow or activity has its own meaning. This model allows you to describe all the main types of processes, both administrative and organizational.

Arrows can be:

• Inbox - introductory, which set a specific task.
• Outgoing - displaying the result of the activity.
• Managers (from top to bottom) - control mechanisms (positions, instructions, etc.).
• Mechanisms (from bottom to top) - what is used in order to produce the necessary work.

It would be more accurate to call incoming and outgoing arrows input and output, since in English they are called Input and Output, respectively. But the features of the translation and the usual names already look the way they have. And yet, for a correct understanding of the terms, it is important to remember their meaning in this case. This is also confirmed by the fact that this notation was created primarily for software development, and it is more correct to translate the terms in this point of view.

Arrows are signed using nouns (experience, plan, rules), and blocks are signed using verbs, i.e. they describe the actions that are performed (create a product, conclude a contract, make a shipment).

IDEF0 is a very simple and at the same time visual language for describing business processes. With the help of this standard, the transfer of information between developers, consultants and users is possible. The standard was developed very carefully, it is convenient for design, universal. There are many tools to work with it, for example, VISIO, BPWIN, ERWIN, Bussines studio, etc.

In addition, using IDEF0 to create business models is not only convenient, it is also right. This tool was designed for business intelligence, it has undergone a long and thorough debugging and polishing. Therefore, using IDEF0 to create a functional model without errors is much easier than without using this standard.

As you know, it is best to hammer nails with a hammer. Of course, you can use other tools for this, but a hammer is the most functional and it is easiest to hammer a nail neatly and accurately with it. So with the use of IDEF0 - this tool was created for functional modeling, and with its help you can get the desired result much faster and more accurately.

An example of creating an IDEF0 functional model

In order to understand how to work with functional modeling, I will give an example of the process of writing an article.

The main block is “Write an article”.

Incoming arrows - "Experience", "Information from third-party sources". These are the inputs you need to get started.

The guides for writing an article are the “Publication Plan”, “Publisher Requirements”, “Rules of the Russian Language”.

And in the role of "Mechanisms" are the author, copywriter, proofreader and software. In this case, the author creates an audio material in which he collects all the thoughts and ideas that should be reflected in the article. A copywriter is a person who creates, on the basis of this material, guided by the requirements of the publisher, the publication plan and the rules of the Russian language, the finished text of the article. The proofreader checks the material for errors. And software is the tools that all participants in the process use in their work.

Thus, I set the main parameters of the process, its input, output, as well as everything necessary for the successful implementation of the process. But this is only the basic framework of the process. This describes the general scheme of the company as a whole.

In fact, the process of creating an article, like any business process, can and should be detailed. To do this, I decompose the general “write an article” block into interconnected elements.

In our case, the work is divided into 4 main stages:

1. Prepare audio.
2. Prepare text
3. Prepare text for publication.
4. Place an article in a publication.

The diagram clearly shows at what stage which control elements and which mechanisms are involved.

So, when creating audio, the author uses his knowledge and experience, while being guided by the publication plan and the requirements of the publisher. The copywriter receives an audio recording as input, from which, guided by the rules of the Russian language, he creates a text. The proofreader receives the text and checks it, also guided by the rules of the Russian language. To place an article in a publication, special software is required.

When creating a functional model, the key parameters are the goal and the point of view. Based on them, modeling of the same processes may look somewhat different. For example, in my case, the goal is "to talk about the process of writing an article." And the copywriter's point of view is "writing and publishing an article from the point of view of the process manager."

So, if the same process were described from the point of view of a copywriter, then the input would be an experience and an audio file from the author. Moreover, in this case, Experience would mean the experience of a copywriter, but not a leader or author. Therefore, the first thing to determine when creating a business process model is to choose a point of view and clearly articulate the goal.

Such modeling is not only visual, but also very convenient for making effective management decisions. For example, in the business process described above, there are two separate specialists - a copywriter and a proofreader. If I set the task of optimizing project financing, then thanks to the scheme, I will immediately see where it is and how it can be done. So, a copywriter and a proofreader use approximately the same rules, but the copywriter receives audio and gives the result in the form of text, while the proofreader both accepts and gives text. And therefore, if necessary, I can, say, for half the cost of the duties of a proofreader, offer a copywriter. So I will save money and time on the interaction of different specialists. Of course, I understand all the merits of proofreaders and why it is better to work with individual specialists. But I remind you that I have a task: cost optimization.

Without such a visual tool, it would be more difficult to determine which of the blocks can be removed and thus optimize the work.

How to create IDEF0 notations

There are many different software products that can be used to create notations. Some are designed specifically for functional modeling, others are designed for any work with graphic elements. Where and how you build these models is up to you.

I personally think that at the first stage there is nothing better than regular paper, a simple pencil and an eraser to make adjustments in case of mistakes.

In order to create a notation for existing business processes, i.e. to describe how the company works now, it is necessary to study the principles of work. A third-party specialist (consultant, developer) conducts an interview for this. At the first stage, the head of the company answers the questions, then, in the process of detailing the notation, interviews are conducted with employees responsible for various stages of work.

It is important to understand that as a result, 2 notations will be required. The first will display business processes as they are. You create it on the basis of an interview and coordinate every detail with the company's employees and the manager. It is very important that your vision of existing processes coincides with reality, and this is what requires confirmation at all levels.

The second notation is “as it should be”. It is created on the basis of the first and those changes that you propose to make to the structure of work to optimize and automate the work of the company as part of the task.

IDEF0 requirements

The basic requirements of the IDEF0 standard, in principle, I described above and showed with an example.

1. In the upper left corner is always the main element.
2. All elements must have incoming and outgoing arrows, since for execution it is necessary to receive something at the input (order, task), and after processing at the output, it is necessary to transfer the finished product. Incoming arrows are always on the left, outgoing arrows are always on the right.
3. Above are the control elements, below are the mechanisms necessary to complete the process.
4. If there are several blocks on one sheet (screen), each subsequent block is located to the right and below the previous one.
5. It is necessary to strive to create schemes in such a way that the intersection of arrows is reduced to the necessary minimum.

Common Mistakes

Functional modeling is performed using a variety of tools, including those not intended for modeling. In the latter case, there is no checking for errors and limitations of the standard. The desire to increase visibility and lack of experience often end in errors.

Use of different colors

All elements in the diagram are equally important. In functional modeling, there are no more or less important elements. The disappearance of any will lead to a disruption of the process and a manufacturing defect.

Often when modeling on paper or in different programs, users try to increase visibility by using different colors. This is one of the most common mistakes. In fact, the use of multi-colored arrows and blocks only introduces additional confusion, and also distorts the perception of the scheme.

Your model should be readable in black and white, without any additional color schemes. This approach simultaneously helps to avoid misunderstandings and disciplines the creator of the model, as a result, the readability and literacy of the model increase.

Too many blocks

When compiling a model, they often try to display on one sheet all the nuances of the company's work with all the details. The result is a very large number of blocks with a large number of control arrows. Readability is lost.

The best option is detailing sufficient to understand the issue, and nothing more. Detailed details of the work of each department or even an employee can be revealed when choosing a detailed view of a particular process. And such a structure is created only if it is really necessary for work or decision making.

Violation of the structure when making adjustments

Watch carefully to avoid confusion or processes without incoming, outgoing and other important elements. For example, if in the above example, I see fit to shift the point of view to the copywriter, I will remove the author from the schema. And then the controls "experience of the author and third-party sources", as well as the publication plan become unnecessary. After all, the author uses them. The copywriter works with the audio file. And if they remain in the general scheme, then when detailing, they will lead incomprehensibly where and introduce confusion.

Likewise, if I decide to add a block, it's important to make sure that it also has all the required attributes. Carefulness is very important here, because when modeling complex business processes, changes in one part of the model can lead to changes in another. They must be entered.

Rules for Naming Controls and Blocks

It is important to remember a simple rule: control arrows are called nouns, blocks are called verbs. This is accepted in the IDEF0 standard, and this approach helps to avoid confusion and errors.

Most often, mistakes are made when naming blocks. For example, instead of "Create an article" they write "Create an article." Blocks in this approach are actions, and therefore they should always be verbs.

Benefits of using IDEF0

• The very first benefit is obvious - it is visibility. You yourself begin to understand how this or that system works, and you can also clearly explain where there are “thin spots” in this system and how your solutions will help get rid of them.
• Mutual understanding and lack of disagreement. When discussing the work of the company using the functional model, you have visual and intuitive task blocks with controls. In addition, functional modeling involves the creation, if necessary, of a glossary in which symbols and terms are revealed. As a result, you and your client, manager, and other employees speak the same language when discussing a problem.
• Simplicity and high speed of model creation. Of course, learning to model is not as easy as it seems. After all, a scheme is, in fact, a super-dense presentation of information, which is very good for understanding, but a special approach is required to implement such a presentation. The analyst's brain acts in this case as a very powerful press on the one hand, and a filter on the other. But with experience, this process becomes very fast. As a result, you get a tool that will help you figure out what is happening in a particular system yourself, and with the help of a visual aid created in a short time, illustrate important points to colleagues or customers.
• Discipline and no mistakes. The IDEF0 standard assumes strict frameworks and rules. This approach disciplines, and the habit of acting within the framework of the standard helps to avoid mistakes due to inattention. Any violation of the standard becomes immediately noticeable.

What is the difficulty of using IDEF0

It is important to understand that only in the simplest cases two business analysts will create exactly the same functional models to describe the work of the company. Any model is a reflection of the analyst's experience, the depth of understanding of the business that he seeks to describe, and also, in some way, his personal point of view on this business. Those. a person develops a business model from the point of view of the leader, as if he were the leader.

At the same time, I believe that a business analyst is not quite a profession, every business manager or developer of some systems is engaged in business analytics, who analyzes the business and strives to build the most effective system. It is for these people and for these purposes that the IDEF0 tool is intended.

Therefore, it is very important to constantly consult with the head of the company when compiling a functional business model “as is”, so as not to make mistakes that will automatically entail errors at the stages of decomposition. Also, at subsequent stages, additional approvals from the heads of structural divisions and employees may be required. Only if your functional model "as is" will really reflect the real state of affairs, you can make some changes and suggestions. And to achieve high-quality results in such work, first of all, practical experience and knowledge of the characteristics of a particular type of business is required.

The easiest and fastest way to create diagrams using the idef0 and idef3 graphic notations is to use the freely distributed cross-platform editor for diagrams, flowcharts, network diagrams, UML diagrams and other evil spirits called "Dia". The program has been translated into many languages, including Russian.

You can download the program on its official website: http://projects.gnome.org/dia/. At the time of this writing, the latest version of the Dia program was numbered 0.97.1 - and it has been that way for almost two years now. Despite this, the functionality of the application is excellent.

Building IDEF0 Diagrams

to create diagrams in the idef0 graphic notation, it is enough to select the standard library of Dia elements called "SADT / IDEF0":

If this is your first time encountering idef0, then I highly recommend that you first read these articles about this methodology:

1. Modern methodologies for describing business processes. IDEF0 Methodology - Kovalev Valery Mikhailovich (Magazine "Consultant Director", No. 12, June, 2004)
2. IDEF0 as a Process Modeling Tool - Andrey Dvornikov (Avant Partner Magazine, No. 22(79), August 2005)
3. Experience in using the IDEF0 standard - Sergey Rubtsov

Building IDEF3 Diagrams

With idef3, it's a bit more complicated. Dia does not provide a standard set of elements for constructing a diagram in the idef3 graphic notation, but the program has all the necessary blocks. They just need to be grouped manually. To do this, click on the menu: "File -> categories and objects". In the window that opens, click the "Create" button. Another window will open, in which we select the item "Category Name" and enter "idef3" there. The process of creating a category looks something like this:

Since you just created this category, naturally it is empty. We need to move the necessary elements of the schemes into it. That's why:

Click the "Apply" button, "Close" the window and you're done! We go to "other libraries of elements" and select there the graphic notation "idef3" created by us (it is located in its place alphabetically). By the way, to write in blocks, it is convenient to use the F2 key. Of course, this is not a perfect tool, but this method allows you to create IDEF3 diagrams as close as possible to their exact graphical notation.

If you know other free IDEF3 graphical charting tools, then share it with everyone in the comments.

Workshop on Application of IDEF0 for Functional Description of CAD Software

Workshop on Application of IDEF0 for Functional Description of Software
Part 1.

If we analyze the advertisements for hiring employees of firms involved in software development, then recently there has been an acute shortage of project managers who can competently carry out task setting. The problem is not that they can't formulate the problem, but that they can't properly document the documentation, taking into account modern design standards. The customer alreadyit is not enough to give a few leaves typed in Word. He wants documentation designed in BPWin, ErWin, S-Designer, Power Designer, Rational Rose, etc. Behind each of these CASE tools is a standard. This article is devoted to one of them - IDEF0.

Introduction. When compiling documentation, each project manager considers it "an honor" to come up with something "of his own" - his own "super format" of presenting his ideas. The complexity of projects is growing, the volume of documentation for the project is growing, the documentation goes beyond the working group ... and then it becomes clear that the documentation does not suit the customer or the group of developers who are finalizing the project and maintaining it.

Usually, the project manager is either a class programmer (the lead programmer of the topic - the project), or a person who speaks a foreign language well and is familiar with programming. These are the main selection criteria for the position of project manager. This is the root of the problem. You can be a great programmer or just a good employee, but this has nothing to do with documentation.

Usually, the specification for each type of manager rolls down either to a description of the model of the program itself (architecture of modules, classes, DLL, database structure and its use, etc.) or to a description of user functions (what they should do, what forms should be in program, etc.).

The ideal option is when the customer sets the task. In this case, you can live by the principle "the customer wants", and as long as he is satisfied, you receive money from the customer. But more and more projects are created in the depths of any organization, and then offered to the customer. And in this case, the quality of the documentation, what you have done and what you intend to do, comes to the fore. The documentation in this case is everything...

The IDEF0 (Integrated Definition Function Modeling) standard is designed for functional modeling and has been adopted as a US federal standard. The IDEF0 standard is one of a group of standards widely used to describe any business process. Its use for describing software projects is a very young direction, but the use of IDEF0 guarantees that your partners take you seriously ...

The application of the IDEF group standards (IDEF0, IDEF1, etc.) is the actual condition for obtaining the status of an organization that satisfies ISO9000, ISO9001. These standards for an organization are an opportunity to increase sales of products, an opportunity to prove that it is "on the crest of a wave."

Many programmers use CASE ErWin extensively without knowing that it is based on the IDEF1 standard. It's not just what you like or what your customers like. This is the standard - and that says it all.

Brief basic concepts of the IDEF0 standard. The IDEF0 standard is based on the concept of a function. A function is a controlled action on input data that results in output data, using some mechanism through which this action is carried out.

The IDEF0 standard is based on three basic principles:

1. the principle of functional decomposition - any function can be decomposed (detailed, broken down) into simpler functions;

2. the principle of complexity limitation - the number of blocks in the diagram should be 2...6 (readability condition);

3. The principle of context - business process modeling begins with the construction of a context diagram, which displays only one block - the main function of the modeling system, which limits the boundary area of ​​\u200b\u200bthe modeling system (regulates the initial stage of model building).

IDEF0 diagrams are built using blocks. Each block describes some completed action (function).

The four sides of the block have different purposes. Input data is displayed on the left, output data is displayed on the right, control is displayed on top, mechanism is displayed on the bottom.

Input data - initial resources for the function described by the block (initial information, materials).

Output data - the resulting resources obtained as a result of the execution of the function described by the block (output information, processed source materials).

Control is what affects the process of performing the function described by the block and allows you to influence the result of the action (controls, sensors, people).

The mechanism is that by means of which the given action is carried out (machines, devices, human resources, software).

Interaction between blocks is displayed as arcs (arrows). Sometimes the sides of the block are called directions and the arrows are called flows. Arrows can be signed. Signatures are associated with the corresponding arrow using a zigzag (lightning bolt).

The general view of the implementation of the IDEF0-diagram block is shown in Fig.1.

Fig.1. Implementation of the block used in IDEF0 diagrams.

When decomposing (detailing) a function, the newly formed diagram displays all incoming and outgoing arrows (arcs, flows) associated with the decomposed function. The number of arrows at any level of the diagram and in any direction is not limited. The diagram is called the broken block (function). Only the name of the diagram-context (DC) coincides with the name of the function contained in the diagram.

In essence, diagrams form a tree. Any diagram acts as a DC in relation to the underlying ones.

As an example, consider some abstract function. This function has input data, two heterogeneous types of output data, is controlled by an external influence and is implemented by mechanisms A and B. An example of the main context diagram is shown in Fig. 2, and a detailed (decomposed) version of this function, consisting of two functions (more elementary actions ), shown in Fig.3. In turn, functions 1 and 2 can also be detailed (decomposed).

Fig.2. An example of a basic diagram.

Fig.3. An example of decomposition of the main function.

The diagram is located on a special form, which contains the name of the function, its graphic image, the designation of the diagram with the level of nesting, links to other functions, special information about the author, organization and the described project.

Connections. Arrows or arcs show relationships between blocks. Arrows usually sign. Arrow labels are selected as nouns. For convenience, the arrows are connected to the signatures with lightning bolts. For readability of the IDEF0 diagram, it is recommended that labels be placed either above the arrow or to the right of the arrow.

Typically, wiring starts with data. The input is the data required to execute the function. Questions rarely arise in this area. The output is the data that is the result of executing the function. The simplest situation is when the output is the input to another block. Is it always like this? If the function, processing the input information, forms a control command, this is control. Approximately the same situation when forming the data format function. A data format is a mechanism for conveying information.

The main types of connections between the blocks in the diagram, formed on the basis of the output information, are shown in Fig.1.

Fig.4. Types of connections between blocks in the diagram. Accordingly, a) data communication, b) control communication, c) mechanism communication, d) feedback.

Feedback is a link that forms a ring between blocks of data, control, or format. An example of such a connection is shown in Fig. 2.d. When such a connection appears, check whether your diagram is reduced to a flowchart of the algorithm. The presence of such a connection is not a sign of an error.

Block priority and numbering. All blocks have priority. The priority of blocks depends on the order in which they are executed. Blocks located on the left and on top have the highest priority. Dominant is the horizontal position.

The block numbering (block index on the diagram) in the diagram is determined based on priority. The numbering starts from one. The chart code consists of the letter "A" and a number. DC has the code A-0. The letter "A" means active action (from English active). The diagram, which is a decomposed version of the DC, will have the code A0. Each element in the A0 diagram will be coded from A1 to A6 according to priority. In turn, when decomposing one of the blocks A1...A6, the codes of the blocks of the newly decomposed diagram will consist of the code of the decomposed diagram plus the index of the selected block. Chart block codes are not repeated throughout the entire chart.

By the number of digits in the diagram code, you can determine the level of the diagram - the level of decomposition of the DC. It is customary to consider the DC as the main level, and all the rest from the first level of decomposition and above.

Action sequence types. Data can be processed sequentially or in parallel.

An example of sequential processing is filling out an address book (after all, two addresses cannot be written into it at the same time). Only one instance of data is always processed in each block, changing sequentially after each processing. The blocks are arranged either sequentially horizontally or obliquely from the upper left corner to the lower right.

An example of parallel processing - you can watch TV and eat an apple at the same time. In this case, two actions are performed simultaneously. These actions are not related. Such blocks in the diagram are arranged vertically one above the other.

Often there is a group of actions (blocks) on the diagram, of which only one is executed, depending on some condition. Such actions are called alternative. The condition should be applied to such blocks as a control action (choice of action). It is recommended to introduce a special block into the diagram that handles the condition for selecting an alternative action (block). This block generates separate commands of choice for each block.

The role of a person in IDEF0 diagrams. Who is he: management or mechanism? You decide what functions a person performs in the described task. If the action contained in the block is controlled by a person, then control. If the action is performed by a person, then the mechanism. It all depends on the degree of abstraction of your problem representation.

There are cases when a person (including the same one) for one block will act as a mechanism and control. THAT HAPPENS. For example, a person is writing a letter. It is written by this person, and this person manages the contents of this letter.

control data. Management is a team. If the command contains an informative part (names, conditions, deadlines, etc.), then the informative part of the command is the input data.

The simplest solution is to split the original arrow into two: control and data. These arrows lead to the corresponding sides of the block. Both split arrows must be labeled accordingly.

Sergei Sokolov (Minsk, BSUIR)
Email: