Dans le diagramme idef0, un tunnel est utilisé. IDEF0 : modélisation fonctionnelle des processus métiers. Historique de la norme IDEF0

Méthodologie IDEF0

Méthodologie IDEF0 prescrit la construction d'un système hiérarchique de diagrammes - des descriptions uniques de fragments du système. Tout d'abord, une description du système dans son ensemble et de son interaction avec le monde extérieur est effectuée (diagramme contextuel), après quoi une décomposition fonctionnelle est effectuée - le système est divisé en sous-systèmes et chaque sous-système est décrit séparément (diagrammes de décomposition) . Ensuite, chaque sous-système est divisé en sous-systèmes plus petits, et ainsi de suite jusqu'à ce que le niveau de détail souhaité soit atteint.

Chaque Diagrammes IDEF0UN contient des blocs et des arcs. Les blocs décrivent les fonctions du système modélisé. Les arcs relient les blocs entre eux et représentent les interactions et les relations entre eux.

Les blocs fonctionnels (travail) dans les diagrammes sont représentés par des rectangles, représentant des processus, des fonctions ou des tâches nommés qui se produisent sur une période donnée et ont des résultats reconnaissables. Le nom de l'œuvre doit être exprimé sous la forme d'un nom verbal désignant l'action.

IDEF0 nécessite que le diagramme comporte au moins trois et pas plus de six blocs. Ces contraintes maintiennent la complexité des diagrammes et du modèle à un niveau lisible, compréhensible et utilisable.

Chaque côté du bloc a un objectif particulier et très spécifique. Le côté gauche du bloc est destiné aux entrées, le haut est au contrôle, le droit est aux sorties et le bas est aux mécanismes. Cette désignation reflète certains principes du système : les entrées sont converties en sorties, contrôlent les limites ou prescrivent les conditions d'exécution des transformations, les mécanismes montrent quoi et comment une fonction exécute.

Les blocs dans IDEF0 sont classés par ordre d'importance, comme l'a compris l'auteur du diagramme. Cet ordre relatif est appelé dominance. La dominance est comprise comme l'influence qu'un bloc a sur les autres blocs du diagramme. Par exemple, le bloc le plus dominant du diagramme peut être soit le premier d’une séquence requise de fonctions, soit une fonction de planification ou de contrôle qui influence toutes les autres.

Le bloc le plus dominant est généralement placé dans le coin supérieur gauche du diagramme, et le bloc le moins dominant est dans le coin droit.

La disposition des blocs sur la page reflète la définition de la domination donnée par l'auteur. Ainsi, la topologie du diagramme montre quelles fonctionnalités ont un plus grand impact sur les autres. Pour souligner cela, l'analyste peut renuméroter les blocs selon leur ordre de dominance. L'ordre de dominance peut être indiqué par un chiffre placé dans le coin inférieur droit de chaque rectangle : 1 indiquerait la plus grande dominance, 2 la suivante, etc.

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

IDEF0 distingue cinq types de flèches.

Entrée- les objets utilisés et transformés par le travail pour obtenir un résultat (output). Il est permis que l'œuvre ne comporte pas une seule flèche d'entrée. La flèche d'entrée est dessinée comme entrant dans le bord gauche de l'œuvre.

Contrôle-.informations qui contrôlent les actions du travail. En règle générale, les flèches de contrôle contiennent des informations indiquant ce qu'une tâche doit faire. Chaque tâche doit avoir au moins une flèche de contrôle, qui est représentée comme entrant dans le bord supérieur de la tâche.

Sortie- les objets dans lesquels les entrées sont converties. Chaque tâche doit avoir au moins une flèche de sortie, qui est dessinée comme émanant du bord droit de la tâche.

Mécanisme- les ressources qui effectuent le travail. La flèche du mécanisme est dessinée comme entrant dans le bord inférieur de l'œuvre. À la discrétion de l'analyste, les flèches du mécanisme peuvent ne pas être représentées sur le modèle.

Appel- une flèche spéciale pointant vers un modèle de fonctionnement différent. La flèche d'appel est dessinée comme venant du bas du travail et est utilisée pour indiquer qu'un travail est effectué en dehors du système modélisé.

Riz. 2.1 Types 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, entrée, retour de contrôle, retour d'entrée, mécanisme de sortie. Les connexions de contrôle et d’entrée sont les plus simples car elles reflètent des influences directes intuitives et très simples.

Riz. 2.2. Communication de sortie

Riz. 2.3. Communication de gestion

Une relation de contrôle se produit lorsque la sortie d’un bloc affecte directement le bloc le moins dominant.

Le retour de contrôle et le retour d’entrée sont plus complexes car ils impliquent une itération ou une récursivité. À savoir, les résultats d’une tâche influencent l’exécution future d’autres tâches, ce qui affecte ensuite la tâche d’origine.

Un retour de contrôle se produit alors ; lorsque la sortie d'un bloc affecte un bloc avec une plus grande domination.

Les relations sortie-mécanisme sont rares. Ils reflètent une situation dans laquelle le résultat d’une fonction devient un moyen pour atteindre une autre.

Riz. 2.4. Commentaires de connexion

Riz. 2.5. Commentaires de la direction

Les relations résultat-mécanisme sont caractéristiques de l'allocation des sources de ressources (par exemple, outils requis, personnel formé, espace physique, équipement, financement, matériaux).

Dans IDEF0, un arc représente rarement un seul objet. Il symbolise généralement un ensemble d'objets. Étant donné que les arcs représentent des collections d’objets, ils peuvent avoir plusieurs points de départ (sources) et points d’arrivée (destinations). Par conséquent, les arcs peuvent se ramifier et se connecter de différentes manières. L'arc entier ou une partie de celui-ci peut s'étendre à partir d'un ou plusieurs blocs et se terminer par un ou plusieurs blocs.

Les arcs de branchement, représentés par des lignes rayonnantes, signifient que tout ou partie du contenu des arcs peut apparaître dans chaque branche. Un arc est toujours étiqueté avant une branche pour donner un nom à l'ensemble. De plus, chaque branche d'un arc peut ou non être étiquetée selon les règles suivantes :

les branches sans étiquette contiennent le poids des objets spécifiés dans l'étiquette de l'arc avant la branche ;

les branches étiquetées après le point de branchement contiennent tout ou partie des objets spécifiés dans l'étiquette d'arc avant la branche.

Les fusions d'arcs dans IDEFO, représentées par des lignes convergeant ensemble, indiquent que le contenu de chaque branche forme une étiquette pour l'arc résultant de la fusion des arcs d'origine. Après une fusion, l'arc résultant est toujours marqué pour indiquer le nouvel ensemble d'objets résultant de la fusion. De plus, chaque branche peut être marquée ou non avant la fusion, selon les règles suivantes :

Riz. 2.6. Connexion du mécanisme de sortie

les branches non étiquetées contiennent le poids des objets spécifiés dans l'étiquette commune de l'arc après la fusion ;

les branches marquées avant la fusion contiennent tout ou partie des objets répertoriés dans le label commun après la fusion,

nombre de blocs sur le diagramme - N ;

niveau de décomposition du diagramme - L;

équilibre du diagramme - DANS;

nombre de flèches se connectant au bloc - UN

Cet ensemble de facteurs s’applique à chaque diagramme modèle. Ce qui suit répertorie les recommandations sur les valeurs souhaitées des facteurs dans le diagramme.

Il faut s'efforcer de faire en sorte que le nombre de blocs sur les diagrammes des niveaux inférieurs soit inférieur au nombre de blocs sur les diagrammes parents, c'est-à-dire qu'à mesure que le niveau de décomposition augmente, le coefficient diminue. Ainsi, la diminution de ce coefficient l’indique. qu'à mesure que le modèle est décomposé, les fonctions doivent être simplifiées et, par conséquent, le nombre de blocs doit diminuer.

Les diagrammes doivent être équilibrés. Cela signifie que dans un diagramme, la situation illustrée sur la figure 1 ne devrait pas se produire. 2.7 : l'œuvre 1 comporte significativement plus de flèches entrantes et de flèches de contrôle que de flèches sortantes. Il convient de noter que cette recommandation peut ne pas être suivie dans les modèles décrivant les processus de production. Par exemple, lors de la description d'une procédure d'assemblage, un bloc peut inclure de nombreuses flèches décrivant les composants d'un produit et une flèche sortant - le produit fini.

Riz. 2.7. Exemple de graphique déséquilibré

Introduisons le coefficient d'équilibre du diagramme

Il faut s'efforcer de Qétait minime pour le graphique.

En plus d'analyser les éléments graphiques du schéma, il est nécessaire de considérer les noms des blocs. Pour évaluer les noms, un dictionnaire des fonctions élémentaires (triviales) du système modélisé est compilé. En fait, ce dictionnaire devrait inclure les fonctions du niveau inférieur de décomposition des diagrammes. Par exemple, pour un modèle de base de données, les fonctions « rechercher un enregistrement » et « ajouter un enregistrement à la base de données » peuvent être élémentaires, tandis que la fonction « enregistrement des utilisateurs » nécessite une description plus détaillée.

Après avoir constitué un dictionnaire et compilé un ensemble de diagrammes système, il est nécessaire de considérer le niveau inférieur du modèle. S'il existe des correspondances entre les noms des blocs de diagramme et les mots du dictionnaire, cela signifie qu'un niveau de décomposition suffisant a été atteint. Le coefficient reflétant quantitativement ce critère peut s’écrire L*C- produit du niveau du modèle et du nombre de correspondances des noms de blocs avec des mots du dictionnaire. Plus le niveau du modèle est bas (L plus grand), plus les correspondances ont de la valeur.

Lorsque vous démarrez BPWin, la barre d'outils principale, la palette d'outils et l'Explorateur de modèles apparaissent par défaut.

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

Figure 2.8 Boîte de dialogue de création de modèle

BPWin prend en charge trois méthodologies : IDEF0, IDEF3 et DFD. Dans BPWin, il est possible de créer des modèles mixtes, c'est-à-dire que le modèle peut contenir simultanément à la fois des diagrammes IDEF0 et IDEF3 et DFD. La composition de la palette d'outils change automatiquement lorsque vous passez d'une notation à une autre.

Un modèle dans BPWin est considéré comme un ensemble de travaux dont chacun fonctionne avec un certain ensemble de données. Si vous cliquez sur n'importe quel objet modèle avec le bouton gauche de la souris, un menu contextuel contextuel apparaît dont chaque élément correspond à l'éditeur d'une propriété de l'objet.

La construction d'un modèle de système doit commencer par l'étude de tous les documents décrivant ses fonctionnalités. L'un de ces documents est la spécification technique, à savoir les sections « But du développement », « Buts et objectifs du système » et « Caractéristiques fonctionnelles du système ».

Après avoir étudié les documents sources et interrogé les clients et utilisateurs du système, il est nécessaire de formuler l'objectif de la modélisation et de déterminer le point de vue sur le modèle. Considérons la technologie de sa construction à l'aide de l'exemple du système « Service d'Emploi Universitaire », dont les principales capacités ont été décrites dans le travail de laboratoire n°1.

Formulons le but de la modélisation : décrire le fonctionnement du système, qui serait compréhensible pour son utilisateur, sans entrer dans les détails liés à la mise en œuvre. Nous construirons le modèle du point de vue des utilisateurs (étudiant, enseignant, administrateur, décanat, entreprise).

Commençons par créer un diagramme de contexte IDEF0. Selon la description du système, la fonction principale est de servir ses clients en traitant les demandes reçues de leur part. Ainsi, nous définissons la seule tâche du diagramme de contexte comme « Servir le client du système ». Ensuite, nous définissons les données d'entrée et de sortie, ainsi que les mécanismes et le contrôle.

Afin de servir un client, il est nécessaire de l'enregistrer dans le système, d'ouvrir l'accès à la base de données et de traiter sa demande. Les données d'entrée seront « nom du client », « mot de passe client », « base de données source », « demande du client ». L'exécution d'une requête conduit soit à recevoir des informations du système, soit à modifier le contenu de la base de données (par exemple, lors de la compilation d'expertises), les données de sortie seront donc des « rapports » et une « 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 de contexte du système (Fig. 2.9).

Graphique 2.9. Diagramme de contexte du système

Décomposons le diagramme de contexte, décrivant la séquence du service client :

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

Sélection du sous-système.

Accès au sous-système.

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

On obtient le schéma présenté sur la Fig. 2.10.

Après avoir terminé la décomposition du diagramme de contexte, procédez à la décomposition du diagramme de niveau suivant. Généralement, lorsqu'on considère le troisième niveau et les niveaux inférieurs, les modèles reviennent aux diagrammes parents et les ajustent.

Riz. 2.10. Décomposition de l'ouvrage « Service, client système »

Nous décomposons séquentiellement tous les blocs du diagramme résultant. La première étape pour déterminer le niveau d'accès au système consiste à déterminer la catégorie d'utilisateurs. Le nom du client est recherché dans la base de données des utilisateurs, déterminant sa catégorie. Selon une certaine catégorie, les pouvoirs accordés à l'utilisateur du système sont déterminés. Ensuite, la procédure d'accès au système est effectuée, en vérifiant le nom d'accès et le mot de passe. En combinant les informations sur les autorités et le niveau d'accès au système, un ensemble d'actions autorisées est formé pour l'utilisateur. Ainsi, la détermination du niveau d'accès au système ressemblera à celle illustrée à la Fig. 2.11.

Riz. 2.11. Décomposition de l'ouvrage « Détermination du niveau d'accès au système »

Après avoir terminé la procédure d'accès au système, le moniteur analyse la demande du client et sélectionne le sous-système qui traitera la demande. La décomposition de l'ouvrage « Appel à un sous-système » ne correspond pas au but et au point de vue du modèle. L'utilisateur du système ne s'intéresse pas aux algorithmes internes de son fonctionnement. Dans ce cas, il est important pour lui que le choix du sous-système se fasse automatiquement, sans son intervention, donc la décomposition de l'accès au sous-système ne fera que compliquer le modèle.

Nous décomposons le travail « Traitement d'une demande client », effectué par le sous-système de traitement des demandes, en déterminant les catégories et les pouvoirs des utilisateurs. Avant de rechercher une réponse à une requête, vous devez ouvrir la base de données (vous y connecter). En général, la base de données peut être située sur un serveur distant, il peut donc être nécessaire d'établir une connexion avec celui-ci. Déterminons la séquence de travail :

Ouverture de la base de données.

Exécution de la demande.

Génération de rapports.

Après avoir ouvert la base de données, vous devez informer le système qu'une connexion à la base de données a été établie, puis exécuter la demande et générer des rapports pour l'utilisateur (Fig. 2.12).

Il convient de noter que « l'exécution des requêtes » inclut le travail de divers sous-systèmes. Par exemple, si la demande comprend des tests, elle sera alors exécutée par le sous-système de tests professionnels et psychologiques. Au stade de l'exécution de la requête, il peut être nécessaire de modifier le contenu de la base de données, par exemple lors de la compilation d'expertises. Il est donc nécessaire de prévoir cette possibilité dans le schéma.

Riz. 2.12.

Lors de l'analyse du diagramme obtenu, la question se pose : quelles règles sont utilisées pour générer des rapports ? Il est nécessaire d'avoir des modèles pré-générés qui serviront à sélectionner dans la base de données, et ces modèles doivent correspondre à des requêtes et doivent être prédéfinis. De plus, le client doit avoir la possibilité de choisir la forme du rapport.

Ajustons le diagramme en ajoutant les flèches « Modèles de rapport » et « Demandes de modification de base de données » ainsi que la flèche du tunnel « Client système ». Le tunneling du « Client Système » est utilisé afin de ne pas placer la flèche sur le diagramme du haut, car la fonction de sélection du formulaire de rapport n'est pas suffisamment importante pour être affichée sur le diagramme parent.

La modification du diagramme entraînera des ajustements à tous les diagrammes parents (Fig. 2.13 - 2.15).

Il est conseillé de décomposer le travail « Query Execution » à l'aide d'un diagramme DFD (travail de laboratoire n°3), puisque la méthodologie IDEF0 considère le système comme un ensemble de travaux interdépendants, ce qui ne reflète pas bien les processus de traitement de l'information.

Riz. 2.13. Décomposition de l'ouvrage « Traitement d'une demande client »

Riz. 2.14. Décomposition du travail « Service client système » (option 2)

Riz. 2.15. Diagramme de contexte système (option 2)

Passons à la décomposition du dernier bloc « Modification de la base de données ». Du point de vue du client, les données du système se trouvent dans une seule base de données. En réalité, il y a six bases de données dans le système :

base de données utilisateurs,

base de données des étudiants, (Option 2)

base de données des postes vacants,

base de données sur les performances académiques,

Base de données de tests,

BD d'expertises,

Reprise de la base de données.

Selon l'objectif de la modélisation, il est important que le client comprenne que les données reçues ne sont pas immédiatement mises à jour dans le système, mais passent par une étape supplémentaire de traitement et de contrôle. L'algorithme de changement peut être formulé comme suit :

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

L'opérateur génère un ensemble de données temporaires et le fournit à l'administrateur.

L'administrateur contrôle les données et les saisit dans la base de données.

Ce modèle peut être mis en œuvre d'une autre manière, en offrant la possibilité de mettre à jour la base de données directement sur demande, en contournant le processus de contrôle des données. Dans ce cas, il est nécessaire de s’assurer du contrôle de l’intégrité de la base de données pour éviter son endommagement. Dans ce cas, le diagramme ressemblera à ceci (Fig. 2.17).

Riz. 2.16. Décomposition de l'ouvrage « Changer la base de données »

Riz. 2.17. Décomposition de l'ouvrage « Changer la base de données » (option 2) Pour la première option, illustrée à la Fig. 2.12

Effectuer une décomposition plus poussée des « Modifications de la base de données » compliquera le modèle, expliquant comment s'effectue la modification physique de la base de données dans le système. Dans ce cas, l'utilisateur ne recevra aucune information supplémentaire sur le fonctionnement du système du service de l'emploi. Il est conseillé de décomposer ce travail lors du processus de conception d'un système de base de données au stade de la création d'un modèle logique de la base de données.

Une décomposition du travail d'exécution de requêtes sera effectuée dans le prochain laboratoire, illustrant l'utilisation de diagrammes DFD pour décrire les processus de traitement de l'information.

Effectuons une analyse quantitative des modèles présentés dans la Fig. 2.12 et 2.13, selon la méthode décrite ci-dessus. Considérons le comportement du coefficient ^ pour ces modèles. Le diagramme parent « Traitement d'une demande client » a un coefficient de 4/2 = 2, et le diagramme de décomposition a 3/3 = 1. La valeur du coefficient diminue, ce qui indique une simplification de la description des fonctions au fur et à mesure du niveau de le modèle diminue.

Considérons l'évolution du coefficient À b avoir deux options de modèle.

pour la deuxième option

Coefficient À b ne change pas sa valeur, donc l'équilibre du diagramme ne change pas.

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

En résumant l'exemple considéré, il est nécessaire de noter l'importance de considérer plusieurs options de diagramme lors de la modélisation d'un système. De telles options peuvent survenir lors de l'ajustement des diagrammes, comme cela a été fait avec « Traitement d'une demande client » ou lors de la création d'implémentations alternatives de fonctions système (décomposition du travail « Modification de la base de données »). L'examen des options vous permet de sélectionner la meilleure et de l'inclure dans un ensemble de diagrammes pour un examen plus approfondi.

Dans cette section, la méthodologie de définition, de classification et d'identification des processus (section ____) est mise en œuvre sur la base de la méthodologie de modélisation fonctionnelle IDEF0.

1. Définition des processus métiers sous la forme d'un modèle IDEF0

1.1. Définition d'un processus métier.

Lors de la première étape de la description, il est nécessaire de définir les processus métiers de l'organisation. L'élément clé dans la définition d'un processus métier est la déclaration d'intention, qui reflète la raison de la création du modèle (description) du processus métier et détermine son objectif.

Remarques:

1 Le but du modèle est de fixer un certain angle sous lequel les activités de l'organisation sont vues et décrites. À des fins différentes, les angles de vue peuvent être différents et les modèles de processus seront différents.

Par exemple, lors de la description des processus dans une usine de confection, divers objectifs peuvent être formulés : optimisation de la structure organisationnelle de l'usine, formation d'un système de gestion de la qualité, expansion des activités, etc.

2 L'objectif général des modèles dans le cadre de ce document est de créer un système de gestion de la qualité répondant aux exigences du STB ISO 9000-2001, du STB ISO 9001-2001 et du STB ISO 9004-2001.

Afin d'identifier les processus métier, il est nécessaire de déterminer les éléments suivants :

les consommateurs des produits et/ou services de l’organisation ;
produits et/ou services produits par l'organisation et fournis aux consommateurs ;
types de matières premières et leurs fournisseurs.

NOTE Différents processus métiers peuvent être pris en compte pour différents types de produits ou différentes catégories de clients.

Par exemple, une usine de vêtements produit (coud) des manteaux pour femmes en concluant des contrats avec les consommateurs. Les consommateurs de ces produits sont les magasins de vêtements pour femmes et les sociétés commerciales et intermédiaires. L'usine achète des matières premières auprès d'entreprises textiles, ainsi que de sociétés commerciales et intermédiaires.

L'usine est une société par actions fermée. Le but de la construction du modèle est de créer un système de gestion de la qualité. Sur la base de ces informations, un processus commercial peut être distingué dans les activités d'une usine de vêtements : « Produire des manteaux pour femmes ». Les entrées de ce processus sont : a) des informations externes, y compris les exigences des consommateurs (magasins et entreprises) ; b) matières premières et matériaux ; c) les ressources. Les résultats du processus sont : a) des lots de produits finis destinés aux consommateurs ; b) informations destinées aux consommateurs externes. Le contrôle des processus est effectué sur la base des documents réglementaires réglementant les processus de production en usine. Considérant que le processus nous intéresse du point de vue de la gestion de la qualité, nous considérerons comme contrôle externe les documents réglementaires réglementant ce domaine, y compris les exigences du STB ISO 9000. Une carte du processus commercial dans une usine de confection est présentée En figue. 3.

Riz. 3 Processus métier dans une usine de confection

1.2. Description de la structure du processus métier

Lors de la deuxième étape de définition d'un processus métier, il est nécessaire de décrire sa structure interne. Pour ce faire, vous devez définir :

de quels processus consiste le processus métier modélisé ;
comment ces processus interagissent les uns avec les autres.

La modélisation IDEF0 utilise un mécanisme de décomposition pour décrire la structure interne d'un processus.

Conformément aux exigences de la méthodologie IDEF0, afin de décomposer un processus métier, il est nécessaire de créer un diagramme enfant. Ce diagramme doit représenter les processus qui composent un processus métier au sein d'un système de gestion de la qualité (QMS).

Considérons la décomposition du processus métier « Produire des manteaux pour femmes » (Fig. 3).

Compte tenu des objectifs de modélisation - conformité du processus métier aux exigences du STB ISO 9001 - 2001, la décomposition du processus métier comprend 4 blocs de processus présentés dans la Fig. 4.

Conformément aux exigences de la norme STB ISO 9000, le processus métier « Produire des manteaux pour femmes » comprend les processus suivants :

– prendre conscience de la responsabilité de la haute direction en matière de gestion de la qualité ;

– assurer la gestion des ressources ;

– mettre en œuvre des processus de cycle de vie ;

– effectuer des mesures, des analyses et des améliorations du QMS.

Remarque – La figure 4 ne montre pas les interactions entre les blocs fonctionnels représentant la décomposition du processus « Produire des manteaux pour femmes ». 1.3. Description des interactions entre les processus

La troisième étape dans la définition d'un processus métier consiste à décrire les interactions entre les processus. L'interaction entre les processus dans IDEF0 est décrite à l'aide d'arcs d'interface et dénote le transfert de matériaux et/ou d'informations des sorties d'un processus vers les entrées (contrôles, mécanismes) d'un autre processus.

Dans la méthodologie IDEF0, 5 (cinq) types d'interactions entre blocs au sein d'un même diagramme sont autorisés (Tableau 1) :

contrôle;
sortie entrée;
retour d'information de la direction ;
commentaires d'entrée ;
sortie - mécanisme.

Tableau 1

	Relation de contrôle : la sortie d'un processus affecte l'exécution d'un autre processus, c'est-à-dire l'arc de sortie du bloc 1 est l'arc de contrôle du bloc 2. Dans la norme STB ISO 9001, une telle interaction définit la fonction de contrôle « responsabilité de gestion » par rapport aux autres processus.
	Relation d'entrée : la sortie d'un processus est l'entrée d'un autre, c'est-à-dire l'arc de sortie du bloc 1 est l'arc d'entrée du bloc 2. Cette interaction est typique de tout processus de l'organisation, par exemple pour les processus de cycle de vie
	Rétroaction de contrôle : les résultats d'un processus affectent l'exécution d'autres processus, dont l'exécution affecte à son tour l'exécution du processus d'origine. L'arc de sortie du bloc 1 est l'arc de contrôle du bloc 2, et l'arc de sortie du bloc 2 est l'arc de contrôle du bloc 1. Dans STB ISO 9001, une telle interaction peut déterminer : – fonction de gestion « responsabilité de la direction » ; – fonction de gestion « gestion des processus du cycle de vie » ; – fonction de gestion « mesure, analyse et amélioration »
	Rétroaction d'entrée : la sortie d'un processus est l'entrée d'un autre processus, dont la sortie est son entrée, c'est-à-dire l'arc de sortie du bloc 2 est l'arc d'entrée du bloc 1 dont la sortie est son entrée. Dans la norme STB ISO 9001-2001, une telle interaction peut définir la fonction de gestion « gestion des processus du cycle de vie ».
	La relation « sortie-mécanisme » : la sortie d’un processus est un mécanisme pour un autre, c’est-à-dire l'arc de sortie du bloc 1 est l'arc du mécanisme du bloc 2. Ce type de connexion fait le plus souvent référence aux processus de mise à disposition de ressources. Dans STB ISO 9001, une telle interaction peut déterminer la fonction de gestion « gestion des ressources »

La pratique montre que les cinq types d'interactions répertoriés sont suffisants pour déterminer les interactions entre des processus de toute complexité.

La description des interactions au sein du modèle de processus fonctionnel sera complète lorsque ses arcs d'interface seront définis pour chaque bloc fonctionnel.

Remarque – La méthodologie IDEF0 stipule que chaque bloc du modèle doit contenir au moins un arc d'entrée, de sortie, de contrôle et de mécanisme. Il existe une courte liste d'exceptions à cette règle.

Considérons les interactions entre les processus qui composent le processus métier « Produire des manteaux pour femmes » (Fig. 5).

Le processus « Mettre en œuvre la responsabilité de la direction en matière de gestion de la qualité » est le processus moteur de tous les autres processus. En conséquence, le résultat de ce processus - « Politique, objectifs, gestion de la qualité, programmes qualité » est l'entrée de contrôle pour tous les autres processus présentés dans le diagramme (Fig. 5).

Le processus « Effectuer la gestion des ressources » a un lien « mécanisme de sortie » avec les processus « Mettre en œuvre les processus du cycle de vie » et « Effectuer les mesures, l'analyse et l'amélioration du QMS ».

Le diagramme montre la boucle de rétroaction : le résultat du processus « Mesurer, analyser et améliorer le système de gestion de la qualité » avec l'entrée du processus « Mettre en œuvre la responsabilité de la haute direction pour la gestion de la qualité »

Remarque – La règle d'exhaustivité du modèle fonctionnel IDEF0 correspond exactement aux exigences de la norme STB ISO 9001 en ce sens que chaque processus doit être doté de ressources (arcs de mécanismes dans le modèle IDEF0), contrôlées (arcs de contrôle), produire des produits de sortie (arcs de sortie), traiter des matériaux et/ou des informations arrivant à ses entrées (arcs d'entrée).

Fig.5 - Interactions entre processus

Le nombre de niveaux de détail du processus est déterminé par les objectifs de la modélisation et les spécificités de l'activité de l'organisation modélisée. Dans le cadre de cette méthodologie, l'objectif principal de la modélisation des processus est d'analyser la conformité du processus aux exigences du système de management de la qualité.

Dans le diagramme A0 (Fig. 5), le processus métier « Produire des manteaux pour femmes » est présenté sous la forme de 4 processus. Le diagramme A0 est le premier niveau de décomposition (détail) de ce processus. Chacun des 4 processus présentés peut à son tour être décomposé. En figue. La figure 6 montre la décomposition du processus « Implémenter les processus du cycle de vie ».

Dans le schéma A3 (Fig. 6), le processus « Mettre en œuvre les processus du cycle de vie » est présenté sous la forme de six processus, dont « Effectuer l'approvisionnement », qui peut également être décomposé (Fig. 7).

Riz. 6.- Décomposition du processus « Mettre en œuvre les processus du cycle de vie »

Le glossaire des processus comprend une liste de processus, d'objets traités au sein de processus et de leurs définitions.

Le glossaire fournit une liste de termes organisés par ordre alphabétique. Chaque terme de cette liste correspond à une définition ou à un lien vers la définition correspondante donnée dans les documents réglementaires de l'organisation ou des autorités supérieures, les règlements, etc.

Par exemple, pour le schéma A34 (Fig. 7), un fragment du glossaire ressemblera à ceci.

Ensuite, nous examinerons les méthodes standard d'analyse structurelle du système décrites par une série de normes fédérales américaines " Icam Définition", conformément à . Des informations détaillées sur toutes les normes de cette série sont disponibles sur http://www.idef.com.

Standard IDEF0(FIPS183) vise à créer un modèle fonctionnel qui décrit la structure et les fonctions d'un système, ainsi que les flux d'informations et d'objets matériels qui relient ces fonctions. Ce document est une conception (à l'initiative du Département américain de la Défense) sous la forme d'un standard technologique pour l'analyse de systèmes complexes. SADT(Structured Analysis and Design Technique), développé par un groupe d'analystes américains dirigé par Douglas Ross en 1973.

La méthode proposée par la norme IDEF0 est destinée à la modélisation fonctionnelle, c'est-à-dire à la modélisation de la performance des fonctions d'un objet, en créant un modèle graphique descriptif montrant quoi, comment et par qui se fait dans le fonctionnement de l'entreprise. Un modèle fonctionnel est une représentation structurée des fonctions d'un système ou d'un environnement de production, des informations et des objets qui relient ces fonctions. Le modèle est construit en utilisant la méthode de décomposition : des grandes structures composites aux plus petites et plus simples. Les éléments de chaque niveau de décomposition représentent des actions de traitement d'informations ou de ressources matérielles dans certaines conditions à l'aide de mécanismes spécifiés. Chaque action est décomposée en opérations plus petites pour traiter une certaine partie d'informations ou de ressources matérielles dans certaines conditions en utilisant une partie des mécanismes spécifiés. Les opérations se déroulent de la même manière. La dernière étape de décomposition doit aboutir à un modèle dont le niveau de détail satisfait aux exigences spécifiées au tout début du processus de création du modèle.

La méthodologie IDEF0 repose sur les principes suivants :

1. Système et modèle. Un modèle est un objet artificiel qui est une représentation (image) d'un système et de ses composants. M des modèles UN, Si M répond aux questions concernant UN. Ici M- modèle, UN– objet modélisé (original). Le modèle est développé pour comprendre, analyser et prendre des décisions concernant la reconstruction (réingénierie) ou le remplacement d'un système existant, ou la conception d'un nouveau système. Un système est un ensemble de parties interconnectées et interagissantes qui effectuent un travail utile. Les parties (éléments) d'un système peuvent être n'importe quelle combinaison de diverses entités, notamment des personnes, des informations, des logiciels, des équipements, des produits, des matières premières ou de l'énergie. Le modèle décrit ce qui se passe dans le système, comment il est contrôlé, quelles entités il transforme, quels outils il utilise pour remplir ses fonctions et ce qu'il produit.

2. Modélisation de blocs et sa représentation graphique. Le principal principe conceptuel de la méthodologie IDEF est la représentation de tout système étudié comme un ensemble de blocs en interaction et interconnectés qui affichent les processus, opérations et actions se produisant dans le système étudié. Dans IDEF0, tout ce qui se passe dans le système et ses éléments est appelé fonctions. Chaque fonction se voit attribuer un bloc. Sur un diagramme IDEF0 (plus souvent appelé diagramme SADT), document principal dans l'analyse et la conception de systèmes, le bloc est un rectangle. Les interfaces par lesquelles un bloc interagit avec d'autres blocs ou avec l'environnement externe au système modélisé sont représentées par des flèches entrant ou sortant du bloc. Les flèches entrantes indiquent quelles conditions doivent être simultanément remplies pour que la fonction décrite par le bloc se produise.

3. Rigueur et formalisme. Le développement de modèles IDEF0 nécessite le respect d'un certain nombre de règles formelles strictes qui garantissent que la méthodologie bénéficie des avantages en termes d'ambiguïté, de précision et d'intégrité des modèles multi-niveaux complexes. Ces règles sont décrites ci-dessous en termes de technologie SADT. Seule la principale est notée ici : toutes les étapes et étapes de développement et d'ajustement du modèle doivent être strictement et formellement documentées afin que lors de son fonctionnement, aucune question ne se pose liée à l'incomplétude ou à l'inexactitude de la documentation.

4. Modélisation itérative. Le développement de modèles dans IDEF0 est une procédure itérative étape par étape. À chaque étape d'itération, le développeur propose une version du modèle, qui est soumise à discussion, révision et édition ultérieure, après quoi le cycle se répète. Cette organisation du travail contribue à l'utilisation optimale des connaissances d'un analyste système maîtrisant la méthodologie et la technique IDEF0, et des connaissances de spécialistes - experts dans le domaine auquel appartient l'objet de modélisation.

5. Séparer « l’organisation » des « fonctions ». Lors du développement de modèles, il convient d'éviter dans un premier temps de « lier » les fonctions du système étudié à la structure organisationnelle existante de l'objet modélisé (entreprise, firme). Cela permet d'éviter un point de vue subjectif imposé par l'organisation et sa direction. La structure organisationnelle doit être le résultat de l'utilisation (de l'application) du modèle. La comparaison du résultat avec la structure existante permet, d'une part, d'évaluer l'adéquation du modèle, et d'autre part, de proposer des solutions visant à améliorer cette structure.

Exemples de problèmes résolus sur la base de la méthodologie de modélisation IDEF0 :

Analyse et réingénierie des processus métiers.

Développement d'un système d'information pour la gestion des données de qualité.

Développement de réglementations et de procédures pour garantir la qualité des produits et créer des systèmes de traitement de données de qualité. Le modèle fonctionnel permet de remplacer les manuels qualité traditionnels sous forme de documents papier descriptifs par des modèles électroniques standardisés, dont l'intégrité et la cohérence sont automatiquement maintenues. Si nécessaire, vous pouvez toujours obtenir d'eux un rapport papier sous la forme habituelle.

Conception de l'infrastructure de l'information, des procédures et des réglementations pour l'interaction de l'information.

Tâches d'analyse des risques en termes de sécurité de l'information.

Considérons, conformément aux travaux, les principes de construction de schémas utilisant la technologie SADT (IDEF0).

Le langage graphique de SADT est simple et harmonieux. La méthodologie repose sur quatre concepts principaux.

Le premier d’entre eux est le concept « bloc fonctionnel" Un bloc fonctionnel est représenté graphiquement sous la forme d'un rectangle (voir Fig. 3.23) et représente une fonction spécifique au sein du système considéré. Selon les exigences de la norme, le nom de chaque bloc fonctionnel doit être formulé sous forme verbale (par exemple, « produire des services", mais non " production de services"). Chacun des quatre côtés du bloc fonctionnel a sa propre signification (rôle) spécifique, tandis que : le côté supérieur a la signification « contrôle" (suite r ol); le côté gauche a la signification " entrée» ( saisir); le côté droit signifie " sortie» ( sortir); le côté inférieur signifie " mécanisme» ( mécanisme). Chaque bloc fonctionnel au sein d'un même système considéré doit avoir son propre numéro d'identification unique.

Objectif du travail :

étudier les principes de base de la méthodologie IDEF0,
créer un nouveau projet dans BPWin,
formation d'un diagramme de contexte,
Faire des connexions.

La description d'un système utilisant IDEF0 est appelée un modèle fonctionnel. Le modèle fonctionnel est conçu pour décrire les processus métiers existants, qui utilisent à la fois des langages naturels et graphiques. Pour transmettre des informations sur un système spécifique, la source du langage graphique est la méthodologie IDEF0 elle-même.

Chaque Diagrammes IDEF0 a contient des blocs et des arcs. Les blocs décrivent les fonctions du système modélisé. Les arcs relient les blocs entre eux et représentent les interactions et les relations entre eux.

Le bloc le plus dominant est généralement placé dans le coin supérieur gauche du diagramme, et le bloc le moins dominant est dans le coin droit.

Types de flèches

IDEF0 distingue cinq types de flèches.

Sortie- les objets dans lesquels les entrées sont converties. Chaque tâche doit avoir au moins une flèche de sortie, qui est dessinée comme émanant du bord droit de la tâche.

Riz. 2.1 Types de flèches

Riz. 2.2. Communication de sortie

Riz. 2.3. Communication de gestion

Une relation de contrôle se produit lorsque la sortie d’un bloc affecte directement le bloc le moins dominant.

Un retour de contrôle se produit alors ; lorsque la sortie d'un bloc affecte un bloc avec une plus grande domination.

Les relations sortie-mécanisme sont rares. Ils reflètent une situation dans laquelle le résultat d’une fonction devient un moyen pour atteindre une autre.

Riz. 2.4. Commentaires de connexion

Riz. 2.5. Commentaires de la direction

les branches sans étiquette contiennent le poids des objets spécifiés dans l'étiquette de l'arc avant la branche ;
les branches étiquetées après le point de branchement contiennent tout ou partie des objets spécifiés dans l'étiquette d'arc avant la branche.

Riz. 2.6. Connexion du mécanisme de sortie

les branches sans étiquette contiennent le poids des objets spécifiés dans l'étiquette de l'arc partagé après la fusion ;
les branches marquées avant la fusion contiennent tout ou partie des objets répertoriés dans le label commun après la fusion,

Analyse quantitative des graphiques

Pour réaliser une analyse quantitative des diagrammes, nous listons les indicateurs du modèle :

nombre de blocs sur le diagramme - N ;
niveau de décomposition du diagramme - L;
équilibre du diagramme - DANS;
nombre de flèches se connectant au bloc - UN

Cet ensemble de facteurs s’applique à chaque diagramme modèle. Ce qui suit répertorie les recommandations sur les valeurs souhaitées des facteurs dans le diagramme.

Riz. 2.7. Exemple de graphique déséquilibré

Introduisons le coefficient d'équilibre du diagramme

Il faut s'efforcer de Qétait minime pour le graphique.

Boîte à outils BPWin

Lorsque vous démarrez BPWin, la barre d'outils principale, la palette d'outils et l'Explorateur de modèles apparaissent par défaut.

Figure 2.8 Boîte de dialogue de création de modèle

Exemple

Commençons par construire un diagramme de contexte IDEF0. Selon la description du système, la fonction principale est de servir ses clients en traitant leurs demandes. Ainsi, nous définissons la seule tâche du diagramme de contexte comme « Servir le client du système ». Ensuite, nous définissons les données d'entrée et de sortie, ainsi que les mécanismes et le contrôle.

Diagramme de contexte

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

Graphique 2.9. Diagramme de contexte du système

Décomposons le diagramme de contexte, décrivant la séquence du service client :

Déterminer le niveau d'accès au système.
Sélection du sous-système.
Accès au sous-système.
Modification de la base de données (si nécessaire).

On obtient le schéma présenté sur la Fig. 2.10.

Riz. 2.10. Décomposition de l'ouvrage « Service, client système »

Riz. 2.11. Décomposition de l'ouvrage « Détermination du niveau d'accès au système »

Ouverture de la base de données.
Exécution de la demande.
Génération de rapports.

Riz. 2.12.

Ajustement du graphique

La modification du diagramme entraînera des ajustements à tous les diagrammes parents (Fig. 2.13 - 2.15).

Riz. 2.13. Décomposition de l'ouvrage « Traitement d'une demande client »

Riz. 2.14. Décomposition du travail « Service client système » (option 2)

Riz. 2.15. Diagramme de contexte système (option 2)

base de données utilisateurs,
base de données des étudiants, (Option 2)
base de données des postes vacants,
base de données sur les performances académiques,
Base de données de tests,
BD d'expertises,
Reprise de la base de données.

La base de données dans laquelle les informations seront modifiées est déterminée.
L'opérateur génère un ensemble de données temporaires et le fournit à l'administrateur.
L'administrateur contrôle les données et les saisit dans la base de données.

Riz. 2.16. Décomposition de l'ouvrage « Changer la base de données »

Riz. 2.17. Décomposition de l'ouvrage « Changer la base de données » (option 2) Pour la première option, illustrée à la Fig. 2.12

Considérons l'évolution du coefficient Kb avoir deux options de modèle.

pour la deuxième option

Coefficient Kb ne change pas sa valeur, donc l'équilibre du diagramme ne change pas.

Questions de contrôle

Liste Questions de sécurité:

Qu'est-ce qu'un modèle en notation IDEF0 ?
Que signifient les emplois dans IDEF0 ?
Quel est l’ordre de dénomination des œuvres ?
Combien d’œuvres doivent être présentes sur un schéma ?
Quel est l'ordre de domination ?
Comment les œuvres sont-elles disposées selon le principe de dominance ?
A quoi servent les côtés des rectangles de travail sur les schémas ?
Énumérez les types de flèches.
Nommez les types de relations.
Comment s’appellent les flèches de frontière ?
Expliquez le principe de dénomination des flèches de branchement et de fusion.
Quelles méthodologies sont prises en charge par BPWin ?
Répertoriez les principaux éléments de la fenêtre principale de BPWin.
Décrivez le processus de création d'un nouveau modèle dans BPWin.
Comment faire des liens entre les œuvres ?
Comment définir un nom de travail.
Décrire le processus de répartition du travail.
Comment ajouter du travail à un diagramme ?
Comment résoudre les flèches tunnelées ?
Un modèle BPWin peut-il contenir des diagrammes de plusieurs méthodologies ?

IDEF0 est aujourd’hui le principal standard de modélisation des processus métiers. La description d'un système utilisant IDEF0 est appelée modèle fonctionnel . Le modèle décrit ce qui se passe dans le système, comment il est contrôlé, quelles entités il transforme, quels outils il utilise pour remplir ses fonctions et ce qu'il produit.

Lors de la construction d'un modèle, il faut indiquer but de la modélisation, en répondant aux questions suivantes :

· pourquoi ce processus devrait-il être modélisé ?

Que doit montrer le modèle ?

· que peut obtenir le lecteur ?

Exemples de définition d'objectifs : « identifier et définir les problèmes actuels, permettre d'analyser les améliorations potentielles », « identifier les rôles et responsabilités des salariés pour la rédaction des descriptions de poste », « déterminer les possibilités d'automatisation... », « réguler le processus ...", etc.

Point de vue est également l'un des éléments clés lors de la construction d'un modèle. Un point de vue peut être représenté comme le point de vue d’une personne qui voit le système sous l’aspect requis pour la modélisation. Le point de vue doit correspondre à l'objectif de la modélisation.

Le principal principe conceptuel de la méthodologie IDEF est la représentation de tout système étudié comme un ensemble de blocs en interaction et interconnectés qui affichent les processus, opérations et actions se produisant dans le système étudié. Dans IDEF0, tout ce qui se passe dans le système et ses éléments est généralement appelé les fonctions. Chaque fonction est attribuée bloc.

Les blocs fonctionnels dans les diagrammes sont représentés par des rectangles, représentant des processus, des fonctions, des tâches ou des opérations nommés qui se produisent sur une période donnée et ont des résultats reconnaissables. À l'intérieur de chaque bloc se trouvent son nom et son numéro. Le nom du bloc doit être un verbe actif, une phrase verbale ou un nom verbal désignant une action.

Les blocs dans IDEF0 sont classés par ordre d'importance, comme l'a compris l'auteur du diagramme. Cet ordre relatif est appelé dominance. La dominance est comprise comme l'influence qu'un bloc a sur les autres blocs du diagramme. Le bloc le plus dominant est généralement placé dans le coin supérieur gauche du diagramme, et le bloc le moins dominant est dans le coin droit.

Les interfaces par lesquelles un bloc interagit avec d'autres blocs ou avec un environnement externe au système modélisé sont représentées. flèches, entrer ou sortir du bloc. Chaque côté d'un bloc fonctionnel a une signification standard en termes de relation bloc/flèche. La disposition standard des flèches est illustrée à la Fig. 1.

Riz. 1. Contexte IDEF0.

Flèches décrire l'interaction des blocs avec le monde extérieur et entre eux. Les flèches représentent certaines informations et sont appelées noms ou expressions d'un nom.

Il existe cinq types de flèches dans IDEF0 :

1. Entrée - matériel ou information utilisé ou transformé par un bloc fonctionnel pour produire un résultat (sortie). Il est permis que l'œuvre ne comporte pas une seule flèche d'entrée.

2. Gouvernance – les règles, politiques, procédures ou normes qui régissent l'unité. Le contrôle affecte le bloc, mais n'est pas transformé par celui-ci.

3. Sortie - matériel ou informations produites par le bloc. Un bloc sans résultat n’a aucun sens et ne doit pas être modélisé.

4. Mécanisme - ressources qui effectuent le blocage, par exemple le personnel de l'entreprise, les machines, les appareils, etc. À la discrétion de l'analyste, les flèches du mécanisme peuvent ne pas être représentées dans le modèle.

5. Appel - une flèche spéciale pointant vers un modèle de travail différent. Une flèche d'appel est utilisée pour indiquer qu'un travail est effectué en dehors du système modélisé.

Les flèches sur le diagramme contextuel sont utilisées pour décrire l'interaction du système avec le monde extérieur. Flèches de délimitation- des flèches qui commencent au bord du diagramme et se terminent à l'ouvrage ou vice versa. Flèches intérieures connectez les blocs les uns aux autres. Il existe cinq types de relations de travail.

1. Communication par entrée - la flèche de sortie du bloc supérieur est dirigée vers l'entrée du bloc inférieur (Fig. 2).

Riz. 2. Relation sortie-entrée.

2. Communication de contrôle - la sortie du bloc de niveau supérieur est envoyée au contrôle de celui de niveau inférieur (Fig. 3).

Riz. 3. Relation sortie-contrôle.

3. Retour de contrôle - la sortie du bloc de niveau inférieur est envoyée au contrôle du bloc de niveau supérieur (Fig. 4).

Riz. 4. Contrôlez les commentaires

4. Retour d'entrée - la sortie du bloc de niveau inférieur est envoyée à l'entrée du bloc de niveau supérieur (Fig. 5).

Riz. 5. Rapport de rétroaction d'entrée

5. Connexion du mécanisme de sortie - la sortie d'un bloc est dirigée vers le mécanisme d'un autre (Fig. 6).

Riz. 6 Connexion du mécanisme de sortie.

En notation IDEF0, la description du système (modèle) est organisée sous forme de diagrammes hiérarchiques et interconnectés. Tout d'abord, une description du système dans son ensemble et de son interaction avec le monde extérieur est réalisée (schéma contextuel). Le diagramme contextuel ne comprend qu'un seul bloc qui caractérise l'ensemble des processus modélisés, sans détails.

Riz. 7 Exemple de diagramme de contexte IDEF0.

Après quoi une décomposition fonctionnelle est effectuée (Fig. 8) - ce bloc d'activité (grand processus) est divisé en grands sous-processus - et chaque sous-processus est décrit séparément (diagrammes de décomposition). Ensuite, chaque sous-processus est décomposé en sous-processus plus petits - et ainsi de suite jusqu'à ce que le détail requis de la description soit atteint.

Fig.8 Exemple de diagramme de décomposition IDEF0.