La cloche.

Il y a ceux qui ont lu cette nouvelle devant vous.
Abonnez-vous pour recevoir des articles frais.
E-mail
Nom
Nom de famille
Comment voulez-vous lire la cloche
Sans spam

IDEF0 - Notation de modélisation graphique Utilisé pour créer un modèle fonctionnel Affichage de la structure et de la fonction du système, ainsi que des flux d'informations et des objets de matériau qui lient ces fonctions. La notation d'IDEF0 est l'une des notations de technicien les plus populaires de processus métier.

Le but de la méthodologie est de construire schéma fonctionnel Le système à l'étude décrivant tous les processus nécessaires à la précision suffisante pour la modélisation d'un système individuel.

La méthodologie est basée sur quatre concepts de base: bloc fonctionnel, arc d'interface, décomposition, glossaire.

Bloc de fonctionnement (Boîte d'activité) est spécifique une fonction dans le cadre du système considéré. Selon les exigences standard, le nom de chaque bloc de fonction doit être formulé dans la verbale (par exemple, "pour produire des services"). Dans le diagramme, le bloc de fonction est représenté par un rectangle (Fig. 3.).

Chacun des quatre côtés du bloc de fonction a sa propre valeur définie (rôle), tandis que:

La partie supérieure a la valeur "Control";

Le côté gauche est "entrée" (entrée);

Le côté droit est "sortie" (sortie);

Le côté inférieur a le "mécanisme" de la valeur.

Arc de l'interface (Arrow) affiche l'élément du système traité par le bloc fonctionnel ou a un effet différent sur une fonctionreprésenté par ce bloc de fonction. Les arcs d'interface sont souvent appelés flux ou flèches.

Figure. 3. - Bloc de fonction

Utilisation des arcs d'interface, divers objets affichage, à un degré ou à un autre, les processus de définition se produisant dans le système. Ces objets peuvent être des éléments du monde réel (pièces, wagons, employés, etc.) ou des flux de données et des informations (documents, données, instructions, etc.).

En fonction duquel le côté bloc partiel du bloc fonctionnel convient à cette arc d'interface, il est appelé le "entrant", "sortant" ou "contrôle".

Il convient de noter que tout bloc fonctionnel en fonction des exigences de la norme doit avoir au moins une arc d'interface de contrôle et une sortie sortante. Ceci est compréhensible - chaque processus devrait se produire selon certaines règles (ARC de contrôle affiché) et produire un certain résultat (arc émergent), sinon sa considération n'a aucun sens.

La disponibilité obligatoire des arcs d'interface de contrôle est l'une des principales différences de la norme IDEF0 à partir d'autres DFD (Dagram) et de la DFD (diagramme de flux de travail).

Décomposition (Décomposition) est le concept de base de la norme IDEF0. Le principe de la décomposition est utilisé lors de la division du processus complexe aux composants de celui-ci les fonctions. Dans le même temps, le niveau de détail du processus est déterminé directement par le développeur de modèle.


La décomposition nous permet de représenter progressivement et structuré de représenter le système du système sous la forme d'une structure hiérarchique de diagrammes individuels, ce qui le rend moins surchargé et facilement digestible (fig.4.).

Le dernier des concepts IDEF0 est un glossaire (glossaire). Pour chacun des éléments IDEF0 - des diagrammes, des blocs de fonction, des arcs d'interface - la norme existante implique la création et la maintenance de l'ensemble des définitions appropriées, mots clés, présentations narratives, etc., qui caractérisent l'objet affiché par cet élément. Cet ensemble s'appelle glossaire et est une description de l'essence. cet élément. Le glossaire complète harmonieusement une langue graphique visuelle, fournissant des diagrammes avec les informations supplémentaires nécessaires.

Le modèle IDEF0 commence toujours par une représentation système en tant que bloc unique - un bloc fonctionnel avec des arcs d'interface s'étendant à l'extérieur de la région. Ce diagramme avec un bloc fonctionnel est appelé diagramme contextuel.

Dans le texte explicatif sur le diagramme contextuel doit être spécifié cible (But) construire un graphique sous la forme d'une brève description et fixe point de vue.

Figure. 4. - Diagramme de décomposition des blocs fonctionnels du modèle

La définition et la formalisation des fins de développement d'un modèle IDEF0 constituent un point extrêmement important. En fait, l'objectif détermine les domaines correspondants du système à l'étude, sur lequel il est nécessaire de se concentrer principalement sur.

Le point de vue détermine la principale direction du développement du modèle et le niveau des détails nécessaires.

Une fixation claire du point de vue vous permet de décharger le modèle, de refuser le détail et l'étude d'éléments individuels qui ne sont pas nécessaires, sur la base du point de vue sélectionné sur le système. Bon choix Le point de vue réduit considérablement les coûts de temps de la construction d'un modèle final.

Sélection sous-traités. Dans le processus de décomposition, le bloc de fonction, qui dans le diagramme contextuel affiche le système dans son ensemble, est soumis à des détails sur un autre diagramme. Le diagramme de deuxième niveau résultant contient des blocs fonctionnels qui affichent les sous-conformités principales du bloc fonctionnel du diagramme contextuel et s'appelle une filiale (diagramme enfant) par rapport à celui-ci (chacun des blocs fonctionnels appartenant au diagramme enfant, respectivement, est appelé la boîte enfant).

À son tour, le bloc fonctionnel est appelé le bloc parent par rapport à la filiale (boîte mère) et le diagramme auquel il appartient est un diagramme parent (diagramme parent). Chacune des sous-conformes du diagramme de la fille peut être détaillée par une décomposition similaire du bloc fonctionnel correspondant. Dans chaque cas, la décomposition du bloc de fonction, toutes les arcs d'interface incluses dans cette unité ou émanant de celui-ci sont fixes sur une filiale. Cela atteint l'intégrité structurelle du modèle IDEF0.

Parfois, des arcs d'interface de niveau supérieur distincts ne sont pas logiques de continuer à prendre en compte sur les diagrammes de bas niveau, ni inversement - des arcs inférieurs distincts reflètent sur des niveaux plus élevés - il ne surchargera que des schémas de surcharge et les rendent difficiles à perception. Pour résoudre ces tâches dans la norme IDEF0, le concept de tunneling est fourni. Le désignation "tunnel" (tunnel arrow) sous la forme de deux crochets ronds au début de l'arc d'interface indique que cet arc n'a pas été hérité du bloc-parents fonctionnel et est apparu (à partir du "tunnel") uniquement sur ce diagramme.

À son tour, la même désignation autour de la fin (flèches) de l'interface Arc dans la clôture immédiate du bloc du récepteur signifie que cet ARC sera affiché dans une filiale par rapport à ce schéma de bloc et ne sera pas pris en compte. Le plus souvent, il arrive que des objets individuels et les arcs d'interface correspondants ne soient pas pris en compte à certains niveaux intermédiaires de la hiérarchie - dans ce cas, ils plongent d'abord dans le tunnel, puis, si nécessaire, "retour du tunnel".

Habituellement, le modèle IDEF0 porte des informations complexes et concentrées en soi, et afin de limiter leur surcharge et de rendre lisible, les restrictions de difficulté appropriées sont prises dans la norme.

Il est recommandé de représenter sur le diagramme de trois à six blocs fonctionnels, tandis que le nombre d'arcs d'interface continue adaptés à un bloc de fonction (sur un bloc fonctionnel) ne devrait pas être plus supérieur à quatre.

La norme IDEF0 contient un ensemble de procédures qui vous permettent de développer et de coordonner le modèle d'un grand groupe de personnes appartenant à différents domaines du système du système simulé.

Habituellement, le processus de développement est itératif et consiste en des étapes conditionnelles suivantes.: Créer un modèle d'un groupe de spécialistes appartenant à divers domaines d'activités d'entreprise. Ce groupe dans les termes IDEF0 est appelé auteurs (auteurs). La construction du modèle initial est un processus dynamique au cours de laquelle les auteurs interrogent les personnes compétentes sur la structure de divers processus, créant des modèles des activités des divisions.

Dans le même temps, ils sont intéressés par des réponses aux questions suivantes:

Qu'est-ce qui entre dans la division "à l'entrée"?

Quel genre les fonctions Et dans quelle séquence sont effectuées dans la division?

Qui est responsable de l'exécution de chacun des les fonctions?

Ce qui est guidé par l'entrepreneur lors de l'exécution de chacun des les fonctions?

Quel est le résultat du travail de l'unité (à la sortie)?

Sur la base des dispositions, des documents et des enquêtes disponibles, un projet de modèle (modèle modèle) est créé.

Répartition du projet pour examen, coordination et commentaires. À ce stade, il existe une discussion sur le projet de modèle avec un large éventail de personnes compétentes (dans les termes IDEF0 - lecteurs) à l'entreprise. Dans le même temps, chacun des diagrammes du modèle de modèle est critiqué et commenté par écrit et a commenté, puis transmis à l'auteur. L'auteur, à son tour, convient également par écrit avec la critique ou la rejette avec la présentation de la logique de décision et retourne à nouveau le projet corrigé pour une considération supplémentaire. Ce cycle continue jusqu'à ce que les auteurs et les lecteurs arrivent à une opinion commune.

Approbation officielle du modèle. L'approbation du modèle convenu a lieu par la tête groupe de travail Dans le cas où les auteurs du modèle et des lecteurs n'ont pas de désaccord concernant son adéquation. Le modèle final est une idée coordonnée de l'entreprise (système) d'un point de vue donné et d'un but donné.

La clarté de la langue graphique IDEF0 rend le modèle assez lisible pour les personnes qui n'ont pas participé au projet de sa création, ainsi qu'en efficace pour montrer et présenter des présentations. À l'avenir, sur la base d'un modèle construit, de nouveaux projets peuvent être organisés visant à produire des changements dans le modèle.

Le modèle IDEF0 est recommandé pour une utilisation dans l'entreprise lors de la description des processus opérationnels au niveau supérieur. Lors de la compilation du modèle fonctionnel du processus métier (IDEF0), les fonctions et l'entrée, les flux de sortie des matériaux, des ressources financières et des informations (documents, fichiers) sont décrits.

Les désignations conditionnelles du format IDEF0 sont présentées dans les tableaux 2.3.

Tableau 2. - Symboles de notation IDEF0 graphique

symbole Photo La description
Bloquer Le bloc décrit le processus. Le bloc typique est montré à la Fig. 1. À l'intérieur de chaque bloc est placé son nom et son numéro. Le nom doit être un verbe actif, un chiffre d'affaires verbal ou un nom séparable. Le numéro de bloc est situé dans le coin inférieur droit. Les numéros de bloc sont utilisés pour identifier le diagramme et dans le texte approprié.
Flèche Les flèches indiquent des objets entrants et sortants du processus (données). Chaque côté du bloc fonctionnel comporte une valeur standard en termes de flèche de bloc de communication, à son tour, le côté bloc à laquelle la flèche est jointe détermine de manière unique son rôle. Les flèches incluses dans le côté gauche du bloc - entrées. Les flèches incluses dans le bloc de dessus - contrôle. Flèches quittant le processus droit - sorties, c'est-à-dire Objets de données ou de matériaux fabriqués par le processus. Les flèches connectées au bas du bloc représentent les mécanismes.
Flèches tunneled Les flèches tunnelées signifient que les données notées par ces flèches ne sont pas prises en compte sur le diagramme parent et / ou sur une filiale. La flèche placée dans le tunnel où elle rejoint le bloc signifie que les données exprimées par cette flèche ne sont pas nécessaires au niveau suivant de décomposition. La flèche placée dans le tunnel à l'extrémité libre signifie que les données exprimées par elle sont absentes sur le diagramme parent.
Référence externe Lien externe - lieu, essence ou sujet, qui dépassent les limites du système simulé. Utilisé pour désigner la flèche source ou récepteur en dehors du modèle. En diagrammes, la liaison externe est décrite sous la forme d'un carré, à côté duquel le nom de la liaison externe est affiché.
Liaison interdiagramme Un élément désignant un autre diagramme. Il sert à désigner la flèche vers le diagramme d'un autre processus métier sans afficher les flèches sur le diagramme sus-jacent (lors de l'utilisation de modèles hiérarchiques).

Tableau 3. - Symboles de notation IDEF0 graphique

Méthodologie IDEF0

Méthodologie IDEF0 Prescrit la construction du système de diagramme hiérarchique - des descriptions simples des fragments du système. Il est d'abord une description du système dans son ensemble et son interaction avec le monde extérieur (diagramme contextuel), après quoi une décomposition fonctionnelle est effectuée - le système est divisé en sous-systèmes et que chaque sous-système est décrit séparément (diagrammes de décomposition). Ensuite, chaque sous-système est divisé en plus petit et ainsi de suite pour atteindre le degré de détail souhaité.

Chaque Diagrammes IDEF0mais Contient des blocs et des arcs. Les blocs décrivent les fonctions du système simulé. Arcs Bind Blocks ensemble et affiche les interactions et les interrelations entre eux.

Les blocs fonctionnels (opérations) Les diagrammes sont représentés par des rectangles, ce qui signifie que les processus, fonctions ou tâches nommés qui se produisent dans un certain temps et ont des résultats reconnaissables. Le nom de travail doit être exprimé par les noms exclusifs indiquant l'action.

Idef0. Cela nécessite que le diagramme ait au moins trois et pas plus de six blocs. Ces restrictions soutiennent la complexité des graphiques et des modèles à un niveau accessible à la lecture, à la compréhension et à l'utilisation.

Chaque côté du bloc a un objectif spécial et assez défini. Le côté gauche du bloc est destiné aux entrées, au maximum - à contrôler, à droite - pour les sorties, à faible teneur en mécanismes. Une telle désignation reflète certains principes système: les entrées sont converties en sorties. Contrôle des limites ou prescrit les conditions pour effectuer des transformations, les mécanismes montrent que et comment la fonction fonctionne.

Les blocs de l'IDEF0 sont placés en fonction du degré d'importance que l'auteur du graphique comprend. Cet ordre relatif est appelé domination. La domination est comprise comme une influence qu'un bloc a un graphique sur d'autres blocs. Par exemple, l'unité de diagramme la plus dominante peut être soit la première de la séquence de fonctions souhaitée, soit la fonction de planification ou de contrôle affectant tous les autres.

L'unité la plus dominante est généralement placée dans le coin supérieur gauche de la carte et la définition de la dominante est dans le coin droit.

L'emplacement des blocs de la page reflète la définition de la domination de l'auteur. Ainsi, la topologie du graphique montre quelles fonctions ont un impact plus important sur le reste. Pour souligner cela, l'analyste peut renuméroter des blocs conformément à l'ordre de leur domination. L'ordre de la domination peut être désigné par le nombre situé dans le coin inférieur droit de chaque rectangle: 1 indiquera la plus grande dominance, 2 - les suivantes et ainsi de suite.

L'interaction des œuvres avec le monde extérieur et est décrite ensemble sous la forme de flèches représentées par des lignes simples avec des flèches aux extrémités. Les flèches sont des informations et sont appelées noms.

L'IDEF0 distingue cinq types de flèches.

entrée- Objets utilisés et convertis par des travaux pour obtenir le résultat (sortie). On suppose que le travail peut ne pas avoir de flèche d'entrée. La flèche d'entrée est dessinée dans le cadre du côté gauche du travail.

Contrôler -.Information, gestion des actions de travail. Habituellement, les flèches de contrôle portent des informations indiquant que les travaux doivent être effectués. Chaque travail devrait avoir au moins une flèche de contrôle, qui est décrite dans le cadre du travail.

Production - Objets dans lesquels les entrées sont converties. Chaque travail devrait avoir au moins une flèche de sortie qui est dessinée comme sortant de la face de travail correcte.

Mécanisme - ressources effectuant des travaux. La flèche du mécanisme est dessinée dans le cadre de la ligne de travail inférieure. À la discrétion, le mécanisme de flèche d'analyste peut ne pas être représenté sur le modèle.

Appel - Flèche spéciale indiquant un autre modèle de travail. La flèche d'appel est dessinée comme sortante à partir du bas du travail et est utilisée pour indiquer que certains travaux sont effectués en dehors du système simulé.

Figure. 2.1Types de flèches

La méthodologie IDEF0 ne nécessite que cinq types d'interactions entre les blocs pour décrire leurs relations: contrôle, saisie, retour Contrôle, rétroaction sur l'entrée, mécanisme de sortie. Les communications de gestion et d'entrée sont les plus simples, car elles reflètent des impacts directs intuitivement compréhensibles et très simples.

Figure. 2.2.Communication à la sortie

Figure. 2.3.Communication en gestion

Le rapport de commande survient lorsque la sortie d'un bloc affecte directement un bloc avec moins de dominance.

Les commentaires sur la gestion et les commentaires sur l'entrée sont plus complexes, car il s'agit d'une itération ou de récursivité. À savoir, des résultats d'une œuvre affectent l'avenir d'autres travaux, ce qui affectera ultérieurement le travail initial.

Les commentaires sur la gestion se produisent alors; Lorsque la sortie de certains blocages affecte le bloc avec une grande dominance.

La communication "hors mécanisme" est rarement trouvée. Ils reflètent la situation dans laquelle la production d'une fonction devient un moyen d'atteindre un objectif pour un autre.

Figure. 2.4.Commentaires sur l'entrée

Figure. 2.5Commentaires sur la gestion

La communication de mécanisme de communication est caractéristique de la distribution de sources de ressources (par exemple, les outils requis, le personnel formé, l'espace physique, l'équipement, le financement, les matériaux).

Dans l'IDEF0, l'arc décrit rarement un objet. Habituellement, il symbolise un ensemble d'objets. Étant donné que les arcs représentent des ensembles d'objets, ils peuvent avoir de nombreux points initiaux (sources) et points de terminaison (destinations). Par conséquent, les arcs peuvent brancher et être connectés de différentes manières. L'ensemble de l'arc ou de la partie peut laisser un ou plusieurs blocs et se terminer par un ou plusieurs blocs.

La ramification de l'arc décrit sous la forme de lignes divergentes signifie que tous les contenus de l'arc ou de la partie peuvent apparaître dans chaque branche. L'arc est toujours marqué avant la ramification pour donner le nom à l'ensemble complet. De plus, chaque branche de l'ARC peut être marquée ou non marquée conformément aux règles suivantes:

    les branches insupportables contiennent des objets de poids spécifiés dans l'étiquette d'arc avant la ramification;

    les branches marquées après que le point de ramification contienne tous les objets ou leur partie indiquée dans l'étiquette d'arc avant la ramification.

Les fusions d'arc dans l'IDEFO, décrites comme convergentes de lignes ensemble, indiquent que le contenu de chaque branche va former une étiquette pour un ARC, qui résulte de la fusion de l'arc initial. Après la confluence, l'arc résultant est toujours marqué pour spécifier un nouvel ensemble d'objets survenus après la combinaison. De plus, chaque branche avant la fusion peut se marier ou ne pas tomber conformément aux règles suivantes:

Figure. 2.6.Sortie de communication

    les branches insupportables contiennent des objets de poids spécifiés dans la marque d'arc globale après la fusion;

    marqué avant la fusion des branches contiennent tout ou certains objets de la liste commune après la fusion,

    nombre de blocs sur le diagramme - N;

    niveau de décomposition de diagramme - L.;

    balance de la carte - DANS;

    le nombre de flèches reliant le bloc - MAIS

Cet ensemble de facteurs appartient à chaque diagramme du modèle. Ensuite, les recommandations seront inscrites sur les valeurs souhaitées des facteurs de graphique.

Il est nécessaire de s'efforcer de s'assurer que le nombre de blocs dans les diagrammes des niveaux inférieurs serait inférieur au nombre de blocs sur les diagrammes parents, c'est-à-dire avec une augmentation du niveau de décomposition, le coefficient diminuerait. Ainsi, la diminution de ce coefficient dit que. Quoi, comme la décomposition de décomposition du modèle, la fonction devrait être simplifiée, par conséquent, le nombre de blocs devrait diminuer.

Les graphiques doivent être équilibrés. Cela signifie que dans le cadre du même diagramme, il ne devrait pas y avoir de situations de la Fig. 2.7: Le fonctionnement de 1 flèches entrantes et les flèches de gestion sont beaucoup plus grandes que les sortes. Il convient de noter que cette recommandation ne peut être effectuée dans les modèles décrivant les processus de production. Par exemple, lors de la description de la procédure d'assemblage, une pluralité de flèches décrivant les composants du produit peut inclure une pluralité du produit et une flèche est publiée.

Figure. 2.7.Un exemple d'un diagramme déséquilibré

Nous introduisons le ratio de balance de graphique

Besoin de s'efforcer de Kjc'était minimal pour le graphique.

En plus de l'analyse des éléments graphiques du graphique, il est nécessaire de considérer les noms des blocs. Pour estimer les noms, un dictionnaire des fonctions élémentaires (triviales) du système simulé est établi. En fait, ce dictionnaire devrait inclure le niveau inférieur des diagrammes de décomposition. Par exemple, pour le modèle BD, il est élémentaire de «trouver une entrée», «Ajouter une entrée à la base de données», tandis que la fonctionnalité «Enregistrement de l'utilisateur» nécessite une description supplémentaire.

Après la formation du dictionnaire et la compilation du package de diagrammes système, il est nécessaire de prendre en compte le niveau inférieur du modèle. S'il y a une coïncidence des noms des blocs des diagrammes et des mots du dictionnaire, cela dit que le niveau de décomposition suffisant est atteint. Coefficient, réfléchissant quantitativement ce critère, peut être écrit comme L * c -le produit du niveau de modèle par le nombre de noms de bloc correspondant aux mots du dictionnaire. Plus le niveau du modèle (plus de L) est inférieur, plus la coïncidence de la valeur.

Lorsque vous démarrez un BPWIN, la barre d'outils par défaut, la palette d'outils et l'explorateur de modèle apparaissent.

Lors de la création d'un nouveau modèle, une boîte de dialogue apparaît, dans laquelle vous devez spécifier si le modèle sera créé, ou il sera ouvert à partir du référentiel ModelMart, ajoutez le nom du modèle et sélectionnez une méthodologie dans laquelle le modèle sera construit (Fig. 2.8).

Fig.2.8. Dialogue de création de modèle

BPWIN prend en charge trois méthodologies - IDEF0, IDEF3 et DFD. BPWIN Il est possible de construire des modèles mixtes, c'est-à-dire que le modèle peut contenir des diagrammes IDEF0 et IDEF3 et DFD. La composition de la palette d'outils change automatiquement lors de la commutation d'une notation à une autre se produit.

Le modèle de BPWIN est considéré comme un ensemble de travaux, chacun opérant avec du jeu de données. Si vous cliquez sur n'importe quel objet du modèle avec le bouton gauche de la souris, un menu contextuel contextuel apparaît, chaque élément correspondant à l'éditeur de toute propriété de l'objet.

La construction du modèle système devrait commencer par l'étude de tous les documents qui la décrivent fonctionnalité. L'un de ces documents est une tâche technique, à savoir les sections "attribuant le développement", "buts et tâches système" et "spécifications fonctionnelles du système".

Après avoir étudié les documents source et l'enquête sur les clients et les utilisateurs du système, il est nécessaire de formuler le but de modéliser et de déterminer le point de vue sur le modèle. Considérez la technologie de sa construction sur l'exemple du système «Service d'emploi sous l'université», dont les principales capacités ont été décrites dans le numéro de travail de laboratoire 1.

Nous formulons le but de la modélisation: décrivez le fonctionnement du système, qui serait clair pour son utilisateur, sans entrer dans les détails liés à la mise en œuvre. Le modèle s'appuiera du point de vue des utilisateurs (étudiant, enseignant, administrateur, doyen, ferme).

Commençons par le contexte du diagramme de contexte IDEF0. Selon la description du système, la fonction principale consiste à maintenir ses clients en effectuant des demandes de traitement, de ceux-ci entrant. Ainsi, nous définissons le seul travail du diagramme contextuel en tant que "servant le système client". Ensuite, nous définissons les données d'entrée et de sortie, ainsi que des mécanismes et de la gestion.

Afin de servir le client, vous devez l'enregistrer dans le système, ouvrir l'accès à la base de données et traiter sa demande. Le "nom du client", "mot de passe client", "la base de données source", "demande client" sera utilisé comme données d'entrée. L'exécution de la demande conduit à obtenir des informations du système ou à modifier le contenu de la base de données (par exemple, dans la préparation des estimations d'experts), les données de sortie seront donc "Rapports" et "base de données modifiée". Le processus de traitement des demandes sera effectué par le moniteur système sous le contrôle de l'administrateur.

Ainsi, nous définissons le diagramme contextuel du système (Fig. 2.9).

Figure 2.9.Diagramme de système contextuel

Couper la décomposition du diagramme de contexte, décrivant la séquence de service du client:

    Déterminer le niveau d'accès au système.

    Sélectionnez Sous-système.

    Appel au sous-système.

    Changer la base de données (si nécessaire).

Nous obtenons le graphique décrit à la Fig. 2.10.

Après avoir terminé la décomposition de la carte contextuelle, passez à la décomposition du diagramme de niveau suivant. Habituellement, lorsqu'il envisage les niveaux troisième et inférieurs, le modèle revient aux diagrammes parents et ajustez-les.

Figure. 2.10.Décomposition du travail "Service, système client"

Décomposition séquentiellement tous les blocs du tableau obtenu. La première étape pour déterminer le niveau d'accès au système est la définition de la catégorie utilisateur. Le nom du client est effectué dans la base de données de l'utilisateur, définissant sa catégorie. Selon une catégorie spécifique, les pouvoirs fournis par le système utilisateur sont trouvés. Ensuite, l'accès au système est effectué, vérifiant le nom et le mot de passe de l'accès. Combinant des informations sur les pouvoirs et le niveau d'accès au système, un ensemble d'actions autorisées est formée pour l'utilisateur. Ainsi, la détermination du niveau d'accès au système examinera comme indiqué sur la Fig. 2.11.

Figure. 2.11.Décomposition du travail "Détermination du niveau d'accès au système"

Après avoir passé le processus d'accès au système, le moniteur analyse la demande du client en sélectionnant le sous-système qui traitera la demande. La décomposition du travail «appel au sous-système» ne répond pas à l'objectif et au point de vue du modèle. Le système du système n'est pas intéressé par les algorithmes internes de son travail. Dans ce cas, il est important pour lui que la sélection du sous-système sera faite automatiquement, sans son intervention, la décomposition de l'appel au sous-système ne compliquera que le modèle.

Décomposer le travail "Traitement de la demande du client", exécuté en demandant des demandes, définir des catégories et une autorité utilisateur. Avant de rechercher une réponse à la demande, vous devez ouvrir la base de données (connectez-la). Dans le cas général, la base de données peut être sur un serveur distant, il peut donc être nécessaire d'établir une connexion avec elle. Déterminez la séquence de travail:

    Base de données d'ouverture.

    La communication.

    Génération de rapports.

Après avoir ouvert la base de données, il est nécessaire d'informer le système d'établir une connexion à partir de la base de données, après quoi la requête et génère des rapports pour l'utilisateur (Fig. 2.12).

Il convient de noter que «l'exécution de la demande» inclut le travail de divers sous-systèmes. Par exemple, si la demande comprend des tests, il sera exécuté par le sous-système des tests professionnels et psychologiques. À la phase d'exécution de la requête, il peut être nécessaire de modifier le contenu de la base de données, par exemple pour élaborer des estimations d'experts. Par conséquent, dans le diagramme, il est nécessaire de fournir une telle opportunité.

Figure. 2.12.

Lors de l'analyse du graphique résultant, la question se pose, que les règles sont la génération de rapports? Il est nécessaire d'avoir des modèles préformés pour lesquels un échantillon de la base de données sera effectué et que ces modèles doivent être conformes aux demandes et doivent être prédéterminés. De plus, le client doit recevoir la possibilité de sélectionner un formulaire de rapport.

Ajustez le graphique en ajoutant les "Modèles de rapports" et "Demandes de changement de BD" et la flèche Tunnel "Système client". Le tunneling du "client système" a été appliqué afin de ne pas prendre la flèche sur le graphique supérieur, car la fonction de sélection de forme de rapport n'est pas suffisamment importante pour l'afficher sur la carte mère.

La variation du diagramme tire l'ajustement de tous les schémas parents (Fig. 2.13 - 2.15).

Décomposition du travail "Effectuer une demande" est souhaitable de mener à bien le diagramme DFD (numéro de laboratoire 3), puisque la méthodologie IDEF0 considère le système en tant qu'ensemble de travaux interdépendants, ce qui reflète mal les processus de traitement.

Figure. 2.13.Décomposition du travail "Traitement des demandes du client"

Figure. 2.14.Décomposition du travail "Service clientèle du système" (option 2)

Figure. 2.15.Diagramme de système contextuel (option 2)

Passons à la décomposition du dernier bloc "DB Change". Du point de vue du client, ces systèmes sont situés dans une base de données. En fait, il y a six bases de données dans le système:

    Utilisateurs de la base de données

    Étudiants de base de données (Option 2)

    BD Vacances,

    Base de données

    Tests de base de données

    Évaluations d'experts de la base de données

    DB Résumé.

Selon le but de modéliser le client, il est important de comprendre que les données reçues ne sont pas immédiatement mises à jour dans le système, mais transmettent la phase supplémentaire de traitement et de contrôle. Les changements d'algorithme peuvent être formulés comme suit:

    La base de données est déterminée dans laquelle les informations seront modifiées.

    L'opérateur est formé un jeu de données temporaire et est fourni à l'administrateur.

    L'administrateur effectue le contrôle des données et contribue à la base de données.

Ce modèle est implémenté d'une autre manière, offrant la possibilité de mettre à jour la base de données directement sur les demandes, contourner le processus de contrôle des données. Dans ce cas, il est nécessaire d'assurer le contrôle de l'intégrité de la base de données pour éviter tout dommage. Dans ce cas, le diagramme ressemblera à ceci (Fig. 2.17).

Figure. 2.16.Décomposition de la "base de données de changement" de travail "

Figure. 2.17.Décomposition de la "base de données de changement" de travail (option 2) pour la première variante représentée à la Fig. 2.12.

Conduire la nouvelle décomposition des "changements de BD" compliquera le modèle expliquant comment la modification physique de la base de données dans le système est effectuée. Dans le même temps, l'utilisateur ne recevra aucune information supplémentaire sur le travail du système de services d'emploi. Cette décomposition de travail est souhaitable de mener à bien dans le processus de conception de la base de données du système au stade de la création d'un modèle logique de la base de données.

La décomposition de "l'exécution de la requête" sera effectuée dans les travaux de laboratoire suivants, illustrant l'utilisation de diagrammes DFD pour décrire les processus de traitement d'informations.

Nous effectuons une analyse quantitative des modèles représentés à la Fig. 2.12 et 2.13, selon la méthode décrite ci-dessus. Considérez le comportement du coefficient ^ dans ces modèles. Le graphique parent "Traitement de la demande du client" Le coefficient est 4/2 \u003d 2 et les diagrammes de décomposition 3/3 \u003d 1. La valeur du coefficient diminue, ce qui indique la simplification de la description des fonctions avec une diminution du niveau du modèle.

Envisager de changer le coefficient À b. deux options pour les modèles.

pour la deuxième option

Coefficient À b. ne change pas sa valeur, donc la balance du diagramme ne change pas.

Nous supposons que le niveau de décomposition des diagrammes considérés est suffisant pour refléter le but de la modélisation et des fonctions élémentaires (du point de vue de l'utilisateur du système) sont utilisés dans les diagrammes de niveau inférieur comme éléments.

Résumé de l'exemple considéré, il est nécessaire de noter l'importance de la considération de plusieurs variantes de diagrammes lors de la modélisation du système. Ces options peuvent survenir lors de l'ajustement des diagrammes, comme cela a été effectué avec le "traitement de la demande du client" ou lors de la création d'alternatives implémentations des fonctions du système (décomposition de la base de données "change"). L'examen des options vous permet de choisir le meilleur et de l'activer dans le package de diagramme pour une considération supplémentaire.

Apprenez à voir et à comprendre la structure fonctionnelle de votre entreprise!

À l'heure actuelle, en Russie, l'intérêt pour les normes de gestion généralement acceptées dans l'Ouest a fortement augmenté, cependant, dans les pratiques de gestion réelles, il existe un point de démonstration. De nombreux gestionnaires peuvent toujours être mis à la hauteur d'une question directe sur la structure organisationnelle de la société ou du programme des processus opérationnels existants. Les gestionnaires de périodiques économiques les plus avancés et les plus régulièrement en lecture, en règle générale, ne commencent à ne pas tirer un seul graphique hiérarchique compréhensible que par eux, mais dans ce processus entrent généralement rapidement dans l'impasse. Il en va de même pour les employés et les gestionnaires de divers services et unités fonctionnelles. Dans la plupart des cas, le seul ensemble des règles énoncées, conformément auquel l'entreprise devrait fonctionner, est un ensemble de dispositions individuelles et instructions officielles. Le plus souvent, ces documents ont été compilés il y a un an, faiblement structuré et inachevé entre eux et, par conséquent, ils poussent simplement sur les étagères. Pour le moment, une telle approche était justifiée, car lors de la formation de l'économie de marché russe, le concept de concurrence était pratiquement absent et les coûts n'ont pas été considérés comme un besoin particulier - le profit était gigantesque. En conséquence, nous voyons au cours des deux dernières années un tableau explicatif: les grandes entreprises qui ont cultivé au début des années 90 abandonnent progressivement leurs positions, à la fin des soins du marché. Cela est dû en partie au fait que l'entreprise n'a pas introduit des normes de gestion, le concept de modèle d'activité fonctionnel et la mission était totalement absente. Utilisation de la modélisation différentes régions Les activités peuvent analyser assez efficacement des «goulots d'étranglement» dans la gestion et l'optimisation d'un système commercial commun. Mais comme vous le savez, dans n'importe quelle entreprise, la priorité la plus élevée n'a que les projets qui apportent directement des bénéfices. Nous parlons donc de l'enquête des activités et de sa réorganisation uniquement pendant une crise tangible dans la gestion de la société.

À la fin des années 90, lorsque la concurrence et la rentabilité des entreprises sont apparues sur le marché selon les besoins, les dirigeants ont senti des difficultés énormes lors de la tentative d'optimisation des coûts afin que les produits restent à la fois rentables et rentables. Juste à ce stade, la nécessité d'avoir un modèle de l'activité de l'entreprise avant ses propres yeux, ce qui refléterait tous les mécanismes et principes de la relation de divers sous-systèmes dans une entreprise.

Le concept même des "processus métier de modélisation" est venu à la vie de la plupart des analystes simultanément avec l'apparition du marché des logiciels complexes destinés à l'automatisation intégrée de la gestion des entreprises. Ces systèmes impliquent toujours une enquête approfondie de pré-projet sur les activités de la société. Le résultat de cet examen est un avis d'expert dans lequel des recommandations sur l'élimination sont effectuées par des articles individuels " sièges étroits"Dans la gestion des activités. Sur la base de cette conclusion, directement avant la mise en œuvre du projet du système d'automatisation, la soi-disant réorganisation des processus métiers est effectuée, parfois assez grave et douloureuse pour la société. C'est aussi bien sûr l'équipe. pendant des années, il est toujours difficile de faire "penser de manière nouvelle". Ces enquêtes complètes des entreprises sont toujours complexes et significatives de manière significative du cas de tâches. Pour résoudre ces tâches de modélisation systèmes complexes Il existe des méthodologies et des normes bien laminées. Ces normes incluent les méthodologies de la famille IDEF. Avec leur aide, il est possible d'afficher et d'analyser efficacement des modèles d'activité d'une large gamme de systèmes complexes dans diverses coupes. Dans le même temps, la latitude et la profondeur de l'enquête sur les processus du système sont déterminées par le développeur lui-même, ce qui permet de surcharger le modèle créé par des données excessives. Pour le moment, les normes suivantes peuvent être attribuées à la famille IDEF:

  • IDEF0 - Méthodologie de la modélisation fonctionnelle. À l'aide d'un graphique visuel IDEF0, le système étudié apparaît avant les développeurs et les analystes sous la forme d'un ensemble de fonctions interdépendant (blocs de fonction - dans les termes IDEF0). En règle générale, les outils de modélisation IDEF0 constituent la première étape de l'étude de tout système;
  • IDEF1 - méthodologie de modélisation des flux d'informations à l'intérieur du système, permettant d'afficher et d'analyser leur structure et leur interconnexion;
  • IDEF1X (EDF1 étendue) - Méthodologie de construction de structures relationnelles. IDEF1X fait référence au type de méthodologies de "relation d'entité" (relation d'erty-relation) et, en règle générale, est utilisée pour simuler des bases de données relationnelles liées au système à l'étude;
  • IDEF2 est une méthodologie de modélisation dynamique du développement du système. En raison des très sérieuses difficultés de l'analyse des systèmes dynamiques, elle a presque été abandonnée de cette norme et son développement a été suspendu à la phase initiale. Cependant, il existe actuellement des algorithmes et de leurs implémentations informatiques, permettant de transformer un ensemble de diagrammes IDEF0 statiques en modèles dynamiques construits sur la base de "réseaux peints de Pétri" (Nets de Pétri CPN-Color);
  • IDEF3 est une méthodologie de documentation survenant dans un système utilisé, par exemple, dans l'étude des processus technologiques des entreprises. L'utilisation de IDEF3 décrit le script et la séquence des opérations pour chaque processus. IDEF3 a une relation directe avec la méthodologie IDEF0 - chaque fonction (bloc fonctionnel) peut être représentée comme un processus séparé par IDEF3;
  • IDEF4 - Méthodologie de construction de systèmes orientés objet. Les moyens IDEF4 peuvent clairement afficher la structure des objets et les principes de leur interaction, permettant ainsi d'analyser et d'optimiser des systèmes complexes orientés objet;
  • IDEF5 - Méthodologie des systèmes complexes de recherche ontologique. À l'aide de la méthodologie IDEF5, l'ontologie du système peut être décrite à l'aide d'un certain dictionnaire de termes et de règles, sur la base de quelles allégations fiables de l'état du système à l'étude peuvent être formées à un moment donné. Sur la base de ces déclarations, des conclusions sont formées sur le développement ultérieur du système et il est optimisé.

Dans le cadre de cet article, nous considérons la méthodologie la plus couramment utilisée pour la modélisation fonctionnelle IDEF0.

L'histoire de la norme IDEF0

La méthodologie IDEF0 peut être considérée comme suit la phase de développement de la célèbre description du langage graphique des systèmes fonctionnels Sadt (analyse structurée et conception Teqnique). Il y a plusieurs années, un livre similaire a été libéré dans une petite circulation, consacrée à la description des principes de base de la construction de diagrammes Sadt. Historiquement, IDEF0, à mesure que la norme a été développée en 1981, dans le cadre d'un vaste programme d'automatisation des entreprises industrielles, qui portait une désignation de l'ICAM (fabrication assistée par ordinateur intégrée) et a été proposée par le US US Air Force. En réalité, la famille des normes IDEF a hérité de sa désignation à partir du nom de ce programme (IDEF \u003d ICAM Définition). Dans le processus de mise en œuvre pratique, les participants du programme de l'ICAM ont confronté à la nécessité de développer de nouvelles méthodes d'analyse des processus d'interaction dans les systèmes industriels. Dans le même temps, en plus de l'ensemble des fonctions de décrivant les processus métier, l'une des exigences de la nouvelle norme était l'existence d'une méthodologie efficace d'interaction dans le cadre du "Spécialiste des analystes". En d'autres termes, la nouvelle méthode consistait à fournir des travaux de groupe sur la création d'un modèle, avec la participation directe de tous les analystes et spécialistes employés dans le projet.

À la suite de la recherche des solutions pertinentes, la méthodologie de la modélisation fonctionnelle IDEF0 est née. Depuis 1981, la norme IDEF0 a subi plusieurs changements mineurs, principalement limitant et son dernier comité de rédaction a été publié en décembre 1993 par l'Institut national des Technologies de Standays et américaines (NIST).

Les principaux éléments et idéaux de l'IDEF0

Le langage IDEF0 graphique est étonnamment simple et harmonieux. La méthodologie est basée sur quatre concepts de base:

Le premier d'entre eux est le concept bloc fonctionnel (Boîte d'activité). Le bloc de fonction est graphiquement décrit comme un rectangle (voir Fig. 1) et personnifie une fonction spécifique dans le cadre du système à l'étude. Selon les exigences de la norme, le nom de chaque bloc fonctionnel doit être formulé dans la Verbalation (par exemple, "pour produire des services", et non "Services de production").

Chacun des quatre côtés du bloc de fonction a sa propre valeur définie (rôle), tandis que:

  • La partie supérieure a la valeur "Control";
  • Le côté gauche est "entrée" (entrée);
  • Le côté droit est "sortie" (sortie);
  • Le côté inférieur a le "mécanisme" de la valeur.

Chaque bloc fonctionnel dans le cadre du système unifié considéré devrait avoir son propre numéro d'identification unique.

Figure 1. Bloc de fonction.

La deuxième méthodologie "Whale" IDEF0 est le concept arc d'interface (flèche). En outre, les arcs d'interface sont souvent appelés flux ou flèches. L'arc de l'interface affiche l'élément du système, qui est traité par le bloc de fonction ou a un effet différent sur la fonction affichée par ce bloc fonctionnel.

L'affichage graphique de l'interface Arc est une flèche unidirectionnelle. Chaque arc d'interface doit avoir son propre nom unique (étiquette de flèche). À la demande de la norme, le nom doit être une normalisation du nom.

Utilisation des arcs d'interface, divers objets affichage, à un degré ou à un autre, les processus de définition se produisant dans le système. Ces objets peuvent être des éléments du monde réel (pièces, wagons, employés, etc.) ou des flux de données et des informations (documents, données, instructions, etc.).

Selon lesquelles les parties conviennent à cette interface Arc, elle s'appelle le "entrant", "sortant" ou "contrôle". De plus, la "source" (début) et le "récepteur" (fini) de chaque arc fonctionnel ne peuvent être que des blocs fonctionnels, et seul le côté de sortie du bloc peut être "source", et n'importe lequel des trois "récepteurs restants .

Il convient de noter que tout bloc fonctionnel en fonction des exigences de la norme doit avoir au moins une interface de contrôle ARC et un résultat. Ceci est compréhensible - chaque processus devrait se produire selon certaines règles (ARC de contrôle affiché) et produire un certain résultat (arc émergent), sinon sa considération n'a aucun sens.

Lors de la construction de diagrammes IDEF0 - Il est important de séparer correctement les arcs d'interface entrants des gestionnaires, ce qui n'est souvent pas facile. Par exemple, à la figure 2 montre un bloc fonctionnel "Traitement de la pièce à travailler".

Dans le processus réel, le travail, la production de la production est délivré à la pièce à travailler et à des instructions technologiques pour le traitement (ou la réglementation de la sécurité lorsque vous travaillez avec une machine). Il peut sembler de manière erronée que la pièce et le document avec les directions technologiques sont des objets entrants, mais ce n'est pas le cas. En fait, dans ce processus, la pièce est traitée selon les règles réfléchies dans les instructions technologiques, qui doivent être représentées en conséquence à l'arc de l'interface de contrôle.


Figure 2.

Une autre chose est lorsque les instructions technologiques sont traitées par le technologue principal et les modifications sont faites en eux (Fig. 3). Dans ce cas, ils sont déjà affichés dans l'arc d'interface entrant et l'objet de contrôle est, par exemple, de nouvelles normes industrielles, sur la base des modifications apportées.


Figure 3.

Les exemples ci-dessus soulignent toutefois la nature des arcs d'interface entrante et de contrôle externes, cependant, pour les systèmes de la même classe, il y a toujours certaines distinctions. Par exemple, dans le cas de la prise en compte des entreprises et des organisations, il existe cinq principaux types d'installations: flux matériels (pièces, biens, matières premières, etc.), flux financiers (espèces et non-trésorerie, investissements, etc.), Documents flux (documents commerciaux, financiers et organisationnels), flux d'informations (informations, informations sur l'intention, les commandes orales, etc. .) et des ressources (employés, machines, machines, etc.). Dans le même temps, dans divers cas, les arcs d'interface entrants et sortants peuvent afficher tous les types d'objets qui sont des gestionnaires uniquement liés aux flux et informations, ainsi que des mécanismes avec des ressources des arcs.

La disponibilité obligatoire des arcs d'interface de contrôle est l'une des principales différences de la norme IDEF0 à partir d'autres DFD (Dagram) et de la DFD (diagramme de flux de travail).

Le troisième concept de base de la norme IDEF0 est décomposition (décomposition). Le principe de la décomposition est utilisé lors de la division du processus complexe aux composants de sa fonction. Dans le même temps, le niveau de détail du processus est déterminé directement par le développeur de modèle.

La décomposition vous permet de représenter progressivement et structuré de représenter le modèle de système sous la forme d'une structure hiérarchique de diagrammes individuels, ce qui le rend moins surchargé et facilement absorbé.

Le modèle IDEF0 commence toujours par une représentation système en tant que bloc unique - un bloc fonctionnel avec des arcs d'interface s'étendant à l'extérieur de la région. Ce diagramme avec un bloc fonctionnel est appelé diagramme contextuel et est indiqué par l'identifiant "A-0".

Dans le texte explicatif sur le diagramme contextuel, la cible (but) des constructions du diagramme sous la forme d'une brève description et est fixe point de vue (Point de vue).

Définition et formalisation des fins du développement de l'IDEF0 - Le modèle est un point extrêmement important. En fait, l'objectif détermine les domaines correspondants du système à l'étude, sur lequel il est nécessaire de se concentrer principalement sur. Par exemple, si nous simulons les activités de l'entreprise pour renforcer la base de ce modèle système d'InformationCe modèle diffère considérablement de celui que nous développerons pour la même entreprise, mais déjà afin d'optimiser les chaînes logistiques.

Le point de vue détermine la direction principale du développement du modèle et du niveau des détails nécessaires. Une fixation claire du point de vue vous permet de décharger le modèle, de refuser le détail et l'étude d'éléments individuels qui ne sont pas nécessaires, sur la base du point de vue sélectionné sur le système. Par exemple, les modèles fonctionnels de la même entreprise des points de vue du technologue principal et du directeur financier différeront de manière significative dans la direction de leurs détails. Cela est dû au fait que, à la fin, le directeur financier n'intéresse pas aux aspects du traitement des matières premières dans les machines de production et que le technologue principal n'a rien à voir avec les systèmes de flux financiers. Le choix correct du point de vue réduit considérablement les coûts de temps de la construction d'un modèle final.

Dans le processus de décomposition, le bloc de fonction, qui dans le diagramme contextuel affiche le système dans son ensemble, est soumis à des détails sur un autre diagramme. Le diagramme de deuxième niveau résultant contient des blocs fonctionnels qui affichent les principales sous-conformités du bloc fonctionnel du diagramme de contexte et s'appelle une filiale (diagramme enfant) en ce qui concerne (chacun des blocs fonctionnels appartenant au diagramme d'enfant est appelé respectivement l'enfant. Boîte). À son tour, le bloc fonctionnel est appelé le bloc parent par rapport à la filiale (boîte mère) et le diagramme auquel il appartient est un diagramme parent (diagramme parent). Chacune des sous-conformes du diagramme de la fille peut être détaillée par une décomposition similaire du bloc fonctionnel correspondant. Il est important de noter que dans chaque cas de décomposition du bloc de fonction, toutes les arcs d'interface inclus dans cette unité sont enregistrés ou en provenant d'une filiale. Cela atteint l'intégrité structurelle du modèle IDEF0. Le principe de la décomposition est clairement montré à la figure 4. L'attention doit être portée à la relation de la numérotation des blocs et des diagrammes fonctionnels - chaque unité a son propre numéro de série sur le diagramme (chiffre dans le coin inférieur droit du rectangle), et la désignation sous l'angle droit indique le nombre de filiales pour ce schéma de principe. L'absence de cette désignation suggère que la décomposition de ce bloc n'existe pas.

Il y a souvent des cas où les arcs d'interface individuels n'ont aucun sens de continuer à considérer dans des diagrammes d'enfants inférieurs à un niveau particulier de la hiérarchie, ou inversement - des arcs distincts n'ont pas de sens pratique au-dessus de certains niveaux. Par exemple, une arc d'interface représentant la "pièce" à l'entrée du bloc fonctionnel "Traitement sur le tour" n'a aucun sens de réfléchir à des niveaux plus élevés - il ne surchargera que des schémas de surcharge et les rendre complexes pour la perception. D'autre part, il arrive de se débarrasser des arcs d'interface "conceptuels" individuels et ne les détaille pas plus loin que certains niveaux. Pour résoudre ces tâches dans la norme IDEF0, le concept est fourni. tunneling. Le désignation "tunnel" (tunnel arrow) sous la forme de deux crochets ronds au début de l'arc d'interface indique que cet arc n'a pas été hérité du bloc-parents fonctionnel et est apparu (à partir du "tunnel") uniquement sur ce diagramme. À son tour, la même désignation autour de la fin (flèches) de l'arc de l'interface dans la fermeture immédiate de l'unité - le récepteur signifie que dans une filiale par rapport à ce bloc du diagramme, cet arc ne sera pas affiché et considéré. . Le plus souvent, il arrive que des objets individuels et les arcs d'interface correspondants ne soient pas pris en compte à certains niveaux intermédiaires de la hiérarchie - auquel cas, ils plongent pour la première fois dans le tunnel ", puis, si nécessaire," retourner du tunnel ".

Le dernier des concepts IDEF0 est glossaire (glossaire). Pour chacun des éléments IDEF0: diagrammes, blocs de fonction, arcs d'interface La norme existante implique la création et la maintenance d'un ensemble de définitions, de mots-clés, de présentations narratives appropriées, etc., qui caractérisent un objet affiché par cet élément. Cet ensemble s'appelle glossaire et est une description de l'essence de cet article. Par exemple, pour l'interface de gestion, le "règlement de paiement" de l'interface de gestion peut contenir une liste de champs de l'ARC de document correspondant, l'ensemble de visas nécessaire, etc. Le glossaire complète harmonieusement une langue graphique visuelle, fournissant des diagrammes avec les informations supplémentaires nécessaires.


Figure 4. Décomposition des blocs de fonction.

Principes de la restriction de la complexité des diagrammes IDEF0

Habituellement, le modèle IDEF0 porte des informations complexes et concentrées en soi, et afin de limiter leur surcharge et de rendre lisible, les restrictions de difficulté correspondantes sont prises dans la norme appropriée:

  • Restreindre le nombre de blocs fonctionnels dans un graphique trois-six. La limite supérieure (six) provoque l'utilisation des hiérarchies lors de la description des éléments complexes et la limite inférieure (trois) garantit qu'il y a suffisamment de détails sur le diagramme correspondant pour justifier sa création;
  • Limiter le numéro approprié à un bloc de fonction (émergeant d'un bloc de fonction) Arcs d'interface quatre.

Bien sûr, suivez strictement ces restrictions en option éventuellement, cependant, comme l'expérience de l'expérience, elles sont très pratiques dans le travail réel.

La discipline travail de groupe Sur le développement du modèle IDEF0

La norme IDEF0 contient un ensemble de procédures qui vous permettent de développer et de coordonner le modèle d'un grand groupe de personnes appartenant à différents domaines du système du système simulé. Typiquement, le processus de développement est itératif et comprend les étapes conditionnelles suivantes:

  • Créer un modèle d'un groupe de spécialistes appartenant à divers domaines d'activité de l'entreprise. Ce groupe dans les termes IDEF0 est appelé auteurs (auteurs). La construction du modèle initial est un processus dynamique au cours de laquelle les auteurs interrogent compétent pour la structure de divers processus. Sur la base des dispositions, des documents et des enquêtes disponibles, un projet de modèle (modèle modèle) est créé.
  • Répartition du projet pour examen, coordination et commentaires. À ce stade, il y a une discussion sur un projet de modèle avec un large éventail de personnes compétentes (en termes de lecteurs IDEF0) à l'entreprise. Dans le même temps, chacun des diagrammes du modèle de modèle est critiqué et commenté par écrit et a commenté, puis transmis à l'auteur. L'auteur, à son tour, convient également par écrit avec la critique ou la rejette avec la présentation de la logique de décision et retourne à nouveau le projet corrigé pour une considération supplémentaire. Ce cycle continue jusqu'à ce que les auteurs et les lecteurs arrivent à une opinion commune.
  • Approbation officielle du modèle. L'approbation du modèle convenu a lieu par le responsable du groupe de travail si les auteurs du modèle et des lecteurs n'ont pas de désaccord sur son adéquation. Le modèle final est une idée coordonnée de l'entreprise (système) d'un point de vue donné et d'un but donné.

La clarté de la langue graphique IDEF0 rend le modèle assez lisible pour les personnes qui n'ont pas participé au projet de sa création, ainsi qu'en efficace pour montrer et présenter des présentations. À l'avenir, sur la base d'un modèle construit, de nouveaux projets peuvent être organisés, visant à la production de changements dans l'entreprise (dans le système).

Caractéristiques de l'application de la pratique nationale de la modélisation fonctionnelle par IDEF0

DANS dernières années L'intérêt pour la Russie aux méthodologies de la famille IDEF augmente régulièrement. Je regarde constamment, examinant les statistiques d'appel à votre page Web personnelle (http://consulting.psi.ru), qui décrit brièvement les principes de base de ces normes. Dans le même temps, les intérêts de ces normes que l'IDEF3-5, je serais théorique et IDEF0 est assez pratiquement justifié. En fait, les premiers cas, permettant de construire des diagrammes DFD et IDEF0 sont apparus sur le marché russe en 1996, simultanément avec la libération d'un livre populaire sur les principes de la modélisation des normes SadT.

Cependant, la plupart des gestionnaires considèrent toujours l'application pratique de la modélisation des normes IDEF plutôt comme un hommage à la mode qu'un moyen efficace d'optimiser système existant Gestion d'entreprise. Il est probablement dû au désavantage prononcé des informations sur application pratique Ces méthodologies et avec un biais logiciel indispensable de la majorité absolue des publications.

Il n'est pas secret que presque tous les projets d'enquêtes et d'analyse des activités financières et économiques des entreprises sont maintenant en Russie de toute façon sont associés à la construction systèmes automatisés Contrôler. En raison de cela, les normes IDEF dans la compréhension de la plupart sont devenues d'une insurrabilité de la mise en œuvre. technologies de l'informationBien que avec leur aide, vous pouvez parfois résoudre efficacement les petites tâches locales, littéralement avec un crayon et un papier.

Lors de la conduite de projets complexes pour les enquêtes d'entreprise, le développement de modèles de la norme IDEF0 vous permet d'afficher clairement et efficacement l'ensemble du mécanisme d'activité de l'entreprise dans la section souhaitée. Cependant, la chose la plus importante est la possibilité travail collectiffourni par IDEF0. Dans mon activité pratique, il y avait beaucoup de cas lorsque la construction du modèle a été réalisée avec une aide directe d'employés de diverses unités. Dans le même temps, le consultant pour un moment assez court a expliqué les principes de base de l'IDEF0 et enseigné à travailler avec l'application appropriée logiciel. En conséquence, les employés de divers départements ont créé un diagramme de l'IDEF des activités de leur division fonctionnelle qui auraient dû répondre aux questions suivantes:

  • Qu'est-ce qui entre dans la division "à l'entrée"?
  • Quelles fonctions et dans quelle séquence sont effectuées dans la division?
  • Qui est responsable de l'exécution de chacune des fonctions?
  • Qu'est-ce qui est guidé par l'entrepreneur lors de l'exécution de chacune des fonctions?
  • Quel est le résultat du travail de l'unité (à la sortie)?

Après avoir coordonné les projets de diagramme à l'intérieur de chaque unité, ils sont collectés par le consultant dans le projet de modèle de l'entreprise, dans lequel tous les éléments d'entrée et de sortie sont liés. À ce stade, toutes les incohérences de diagrammes individuels et de leurs lieux controversés sont enregistrées. En outre, ce modèle passe à nouveau dans les départements fonctionnels pour une coordination ultérieure et apportant les ajustements nécessaires. En conséquence, pour une période assez courte et lorsqu'il attire un minimum de ressources humaines de la société de conseil (et ces ressources, comme vous le savez, très coûteux), il s'avère un modèle IDEF0 d'une entreprise en fonction du principe «comme est "et ce qui est important, il représente une entreprise avec les positions des employés qui y travaillent et connaissent parfaitement toutes les nuances, y compris informel. À l'avenir, ce modèle sera transféré à l'analyse et à la transformation aux analystes d'entreprise qui rechercheront des "goulots d'étranglement" dans la gestion de la société et l'optimisation des processus principaux, transformant le modèle "tel quel" à la représentation correspondante " comme cela devrait être". Sur la base de ces changements et la conclusion finale est faite, qui contient des recommandations sur la réorganisation du système de gestion.

Bien entendu, une telle approche nécessite un certain nombre de mesures organisationnelles, principalement par la direction de l'entreprise interrogée. Cela est dû au fait que cette technique implique l'imposition sur certaines responsabilités supplémentaires pour le développement et l'application pratique de nouvelles méthodologies. Cependant, il se justifie finalement, puisque une ou deux heures de travail supplémentaire de chaque employés dans quelques jours permettent de sauvegarder de manière significative des fonds pour payer des services de conseil d'une société tierce (en tout état de cause des travaux de les mêmes employés avec des questionnaires et des problèmes). Quant aux employés de l'entreprise, d'une manière ou d'une autre, une opposition prononcée de leur part que je n'ai pas rencontré dans ma pratique.

La conclusion de tout cela peut être effectuée ce qui suit: absolument pas nécessairement chaque fois que vous inventez des solutions pour des tâches standard. Toujours lorsque vous rencontrez la nécessité d'analyser un système fonctionnel (du système de conception de vaisseau spatial, au processus de préparation d'un dîner intégré) - Utilisez les méthodes éprouvées et laminées pendant des années. L'une de ces méthodes est IDEF0, qui vous permet de résoudre des tâches de vie complexes à l'aide de votre boîte à outils simple et compréhensible.

Le aujourd'hui, non seulement dans des cercles étroits, l'abréviation IDEF0 est la première méthodologie de normalisation des travaux sur les processus métier. Il a été développé au milieu du siècle dernier dans le cadre du projet aérospatial aux États-Unis et montrant son efficacité, est devenu la norme fédérale. Dans notre pays en 2000, un document préparé " Méthodologie de modélisation fonctionnelle IDEF0. Document de pilotage Méthodologie Modélisation fonctionnelle Document d'orientation IDEF0. Officiel d'édition. Norme publique de Russie IDEF0 - 2000 RD. Développé par le Centre de recherche CALS - Technologies logistiques appliquées. Adopté et mis en œuvre par la résolution de la norme d'État de Russie 2000 Moscou", Mais comme la norme qu'il n'a pas été approuvée. Bien que cela n'empêchait pas cette méthodologie de devenir dans notre pays l'un des outils de modélisation graphiques les plus populaires des processus métier. Dans cet article, je vous suggère de considérer le modèle IDEF0 et d'évaluer la pertinence de cette approche à l'heure actuelle.

Concepts de base et abréviations

Raconter un peu avec les noms éléments clé Méthodologie. La norme graphique IDEF0 fait partie de la méthodologie Sadt (technique d'analyse et de conception structurée - méthode et conception de l'analyse structurelle). IDEF est une réduction de la définition de l'ICAM et l'ICAM est formé à partir d'une fabrication assistée par ordinateur intégrée, qui est traduite par une informatisation intégrée de la production. La méthodologie Sadt est toute une famille de 15 différents modèlesLequel dans le complexe aurait dû être autorisé à enquêter sur la structure, les paramètres et les caractéristiques de la production et des systèmes techniques et organisationnels et économiques.

IDEF0 est un modèle fonctionnel situé au cœur de la construction de toutes les autres conceptions, il relie des informations et des flux matériels, la structure organisationnelle, l'exposition de contrôle et la société elle-même. La norme graphique pour les processus de modélisation est également appelée notation. C'est-à-dire que la notation est un système d'exigences et de règles pour la construction d'un modèle d'activité sous une forme ou une autre. Par conséquent, IDEF0 appelé de manière appropriée notation incluse dans la méthodologie Sadt.

La notation de l'IDEF0 est une technique assez stricte, qui a été développée à l'origine, ainsi que les normes de conception technique, pour la modélisation manuelle. Par conséquent, il existe les conditions requises pour le placement des flèches, le format de tous les éléments, le contenu du cadre d'information au diagramme IDEF0, etc., car les activités de la société sont un système d'action multi-niveaux complexe, il y a toujours un De nombreux schémas et systématisation et navigation sans ambiguïtés pour tous les éléments de modèle sont nécessaires. Maintenant ils le font principalement systèmes informatiquesSoutenir la modélisation dans cette notation. Sur le territoire de la Russie, les plus célèbres et abordables d'aujourd'hui sont les systèmes d'allfusion de processus de processus et de studio d'affaires. Je prévois de consacrer ces systèmes à l'enquête de ces systèmes.

Bloc de fonctionnement

L'élément central du modèle IDEF0 est une fonction affichée dans le diagramme sous la forme de bloc fonctionnel - Rectangle, à l'intérieur qui est indiqué sous la forme d'un nom séparable. L'action peut être très différente à l'échelle - des activités de la société en général et de la manipulation spécifique en particulier. Exemples: "Production et vente de plats en céramique" et "dessin une image".

Éléments obligatoires du bloc de fonction dans IDEF0

Quelle que soit l'échelle des actions, toutes les fonctions sont affichées de manière uniforme et contiennent nécessairement 4 flux clés résolus de manière rigide par les parties du bloc de fonction:

  • gauche - entrées ou ressources utilisées pour effectuer une fonction;
  • droit - sorties ou résultats de la fonction;
  • de l'exposition de contrôle ci-dessus, qui déterminent comment et combien il est nécessaire de produire des résultats;
  • du bas - les mécanismes qui reflètent qui et avec l'aide de ce qui devrait effectuer ce travail.

Cette approche vous permet d'économiser un peu sur des explications dans les schémas et de réaliser une ambiguïté dans l'affichage des flux, ce qui donne la légèreté de l'ensemble du modèle.

Pour créer un modèle fonctionnel, la méthodologie IDEF0 nécessite les règles suivantes.

  1. Les entrées sont des ressources qui portent leur coût dans les résultats complètement, c'est-à-dire qu'ils sont consacrés à la création d'un résultat complètement et que les mécanismes sont des ressources qui ne cessent que partiellement (équipement - grâce à une dépréciation et à des salaires).
  2. Le contrôle est l'élément modèle souhaité, car il lie toutes les actions au système de réglementation de la Société, indiquant clairement quelles règles et exigences doivent être respectées pendant la fonction d'exécution de la fonction. Souvent, il est officiellement lié à ce flux, mais le schéma perd une rigueur, et parfois même la signification.
  3. Chaque bloc fonctionnel doit avoir au moins une flèche de chaque côté (puisqu'il ne peut pas fonctionner sans ressources ni résultat, ainsi qu'une instruction incomplète sans artiste ou instructions).

Le régime considéré est la "brique" de l'approche IDEF0. La modélisation fonctionnelle implique une transition progressive d'un commun à la décomposition. La décomposition est une «approfondissement» dans la fonction considérée, la séparant en fonctions plus petites. Dans le même temps, lorsque la fonction haut niveau Présenté généralement et après décomposé, il convient d'appeler le processus.

Diagramme contextuel

Au plus haut niveau, la société est représentée comme une "boîte noire", dans laquelle il existe une sorte d'activité qui traduit les entrées. Ce niveau s'appelle "", c'est-à-dire le schéma décrivant le contexte des activités de la société. De plus, le diagramme contextuel affiche les caractéristiques essentielles de l'ensemble du modèle.

  1. L'objectif est une formulation spécifique de l'objectif du modèle, selon laquelle elle peut être traitée dans la précision ultérieure de la construction du modèle.
  2. Le point de vue - du visage duquel le modèle est construit, car le modèle dépend toujours de son auteur et de son accent. Si nous construisons un modèle général de l'entreprise, il est généralement soumis du point de vue de son directeur.
  3. Le type de modèle est une indication de quelles informations sont affichées dans les schémas. Voici 2 options fondamentales: comme cela est ("tel quel") ou d'être ("Comment ça va"). Une telle séparation est nécessaire, car nous pouvons créer des modèles pour une analyse opérationnelle et sa transformation. Nous devons clairement prendre conscience de ce que nous faisons, ainsi que de transmettre ces informations à d'autres.

Ainsi, le diagramme contextuel contient dans la description la plus généralisée de l'activité de l'entreprise, qui floue des flux de connexion à la société avec le monde extérieur. Je pense qu'ils devraient aussi arrêter un peu plus en détail.

Flux principaux

L'expérience a montré que, malgré la simplicité et la formalité semblables à ce niveau, il doit souvent s'attarder pendant longtemps, car il devrait être reflété ici tous les résultats du propriétaire et du marché. Une erreur peut conduire à la création de modèles qui ne remplissent pas le jeu de tâches avant l'entreprise. Pour vérifier que des flux importants sont reflétés, assurez-vous que votre schéma contient tous les 4 principaux types de flux.

  1. Matériau: matériaux et composants à l'entrée et produits finis à la sortie.
  2. Client: client potentiel à l'entrée et satisfait à la sortie.
  3. Financière: à l'entrée est généralement des investissements, des paiements clients (revenus), des prêts et d'autres revenus; À la sortie - il s'agit de paiements aux fournisseurs, aux taxes, aux paiements de prêts et de bénéfices.
  4. Information: À l'entrée, tous les flux d'informations sur l'environnement externe (conditions de marché, comportement des concurrents, innovation technologique, etc.), et à la sortie - il s'agit d'un flux d'informations que la société se rapporte au monde ( Toutes les informations publicitaires, ainsi que tous les types de rapports avant de contrôler les autorités de contrôle).

Veuillez noter que la société est un système ouvert et rien ne cesse de ne pas disparaître. La société n'est capable que de transformer les flux entrants dans les sorts sortants et, le cas échéant, un flux de trésorerie supplémentaire apparaît (rentable), reflétant dans un sens, la qualité de l'ensemble du fonctionnement du système.

(Cliquez pour agrandir)

Eh bien, si vous sélectionnez chacun de ces types de flux de votre couleur afin que vous puissiez facilement distinguer le mouvement des ressources et ne pas manquer moments importants. Par exemple, il est souvent possible d'observer l'absence d'un client dans les cours d'eau de la société, il est donc construit sur le principe résiduel - le client ressent souvent une interférence pour les employés de la société dont les tâches sont axées sur la transformation du flux de Documents.

Les flèches de gestion ne peuvent être représentées que par 1 vue sur le flux - informations pouvant être divisées en 2 sous-espèces. Le premier est les documents, tels que:

  • lois et normes;
  • commandes, commandes;
  • instructions et règlements;
  • des plans;
  • documentation de conception, etc.

La seconde est des informations sans papiers auxquelles la capacité des propriétaires.

Enfin, les mécanismes ne sont que 2 types de flux: équipement (matériau) et interprètes (divisions et personnes). Il ne peut y avoir de documents, comme cela peut y avoir des gens sur la flèche du contrôle!

Pour la navigation dans le modèle, il existe une numérotation transversale. Le diagramme contextuel est numéroté "A-0". À l'avenir, chaque bloc fonctionnel reçoit son nombre, peu importe la décomposition profonde.

Décomposition

Après avoir étudié les flux du diagramme contextuel, nous pouvons aller à la décomposition. Passer au niveau ci-dessous, comme si vous ouvrez la "boîte noire", nous voyons d'abord page blanche Avec des flèches qui ont été attachées au bloc de fonction.

(Cliquez pour agrandir)

Et ici, la modélisation fonctionnelle commence déjà - nous devons comprendre à quel point un ensemble d'action peut relier ces flux et s'assurer que toutes les exigences sont remplies. La complexité est que beaucoup d'actions sont beaucoup, et dans le régime, nous avons le droit de ne pas afficher plus de 9 fonctions, sinon le régime deviendra illisible et en conséquence inutile.

Il n'est pas toujours facile de composer des activités complexes de manière à ce qu'il reste visuel, lisible et complète en même temps. Le plus souvent, il est recours à la séparation de la grande variété de processus sur les principaux grands blocs, dont les plus importants sont les suivants.

  1. Créer un produit (résultat).
  2. Promotion et vente - Travailler avec un flux de clients.
  3. Assurer la création d'un produit - processus secondaire nécessaires au respect des exigences de l'État ou des emplois (personnel et comptabilité, services de transport, nettoyage des locaux et autres).
  4. Création de flux de gestion - activités de gestion qui identifieront les exigences de tous les processus de l'entreprise.

La figure ci-dessous montre le diagramme de décomposition de notre exemple.

(Cliquez pour agrandir)

Dans le diagramme, les processus doivent être arrangés en diagonale - ceci s'appelle principe de dominationqui implique l'emplacement des blocs fonctionnels de gauche à droite et de haut en bas - en fonction du degré d'importance ou de ordre chronologique. La numérotation de blocs se produit également.

Des travaux supplémentaires sur le modèle sont similaires à la première étape - la décomposition de chaque bloc fonctionnel du premier niveau est réalisée. La numérotation des blocs contiendra le premier numéro de niveau: A1.1 ... A1.N, A2.1 ... A2.N, etc.

Conclusions sur la pertinence de la notation

Dans le cadre de cet article, il a été possible d'afficher uniquement les concepts de base de la notation IDEF0 sur un court exemple de IDEF0, qui, bien sûr, est difficile à juger de la méthodologie dans son ensemble. Mais une expérience assez étendue d'utiliser cette notation en pratique me permet de dessiner les conclusions suivantes.

  1. Le modèle a un bon potentiel de visualisation, mais à mon avis, plus de son importance - dans l'effet disciplinable. Les règles et restrictions introduites dans la méthodologie sont obligées de développer une attitude systématique et stricte à l'égard des modèles, ce qui est très bien affecté par la qualité du résultat final.
  2. Le modèle vous permet de créer des flux de communication entre des choses externes et non très liées: pour relier les sous-systèmes de protection avant et de support avec contrôle, ce qui est bien pire géré à d'autres notations.
  3. L'approche est simple et compréhensible pour la plupart des participants au projet. Les graphiques de construction et de lecture dans cette notation ne sont limités que pour le désir de plonger dans les flux complexes des entreprises.

Certains de ces arguments sont obligés de penser que cette approche est la meilleure et uniquement pour des activités de modélisation complètes. Mais il n'est pas nécessaire d'oublier que le modèle fonctionnel n'est calculé que pour le niveau de modélisation supérieur. L'utilisation de la notation IDEF0 pour concevoir des travaux au niveau des interprètes entraîne le fait que les régimes sont obtenus purement illustratifs et, sur leur base, il est impossible de créer des règlements externes, car ils ne contiennent pas:

  • spécifiez les événements de démarrage et l'arrêt de processus;
  • conditions de transition de certaines mesures à d'autres;
  • capacité à afficher clairement toutes les ressources et les interprètes sans surcharger le schéma de flèche.

Par conséquent, si vous utilisez cette notation pour les tâches pour lesquelles il est destiné (structurant les activités de niveau supérieur), IDEF0 est presque la seule notation aujourd'hui, ce qui vous permet de le rendre significativement et soigneusement.

Dans la gestion de projet, cette norme de modélisation standard est la plus appliquée où vous devez attacher différents projets ou processus avec des flux visuels. Le modèle graphique permettra de distribuer de manière plus rationnelle la responsabilité et les ressources dans des tâches. La logique de la tâche du projet, reflétée dans les régimes, aidera à préparer un meilleur plan de calendrier sous la forme d'une carte Ganta.

La cloche.

Il y a ceux qui ont lu cette nouvelle devant vous.
Abonnez-vous pour recevoir des articles frais.
E-mail
Nom
Nom de famille
Comment voulez-vous lire la cloche
Sans spam