Metodologii de modelare a domeniului. Metodologie de descriere a proceselor bazată pe metodologia IDEF0 Metodologii IDEF0 de descriere și modelare a proceselor

22.04.2021 Știri

Pentru a vă familiariza mai bine cu standardul IDEF0, trebuie să știți următoarele despre acesta:

  1. Pentru a construi ce tipuri de modele acest standard folosit.
  2. Ce elemente ale limbajului grafic include notația standardului și ce cerințe pentru proiectarea diagramelor există în cadrul standardului.
  3. Ce principii de modelare a proceselor de afaceri sunt utilizate în standard (principiul de descompunere, principiul limitării complexității, principiul tunelului).
  4. Cum puteți evalua diagramele construite în ceea ce privește congestionarea și echilibrul lor?

IDEF0 folosit pentru a crea model functional, afișarea structurii și funcțiilor sistemului, precum și a fluxurilor de informații și a obiectelor materiale transformate de aceste funcții.

Metodologia IDEF0 diferă ușor de schema clasică de descriere a proceselor de afaceri DFD. Principala diferență este clasificarea intrărilor de muncă.

Clasificarea intrarilor si iesirilor muncii

Standardul oferă următoarea tipificare a intrărilor de lucru:

  • Intrare. Intră în lucrarea din stânga și arată fluxurile de informații și materiale care sunt transformate în procesul de afaceri.
  • Control. Intră în lucru de sus și arată fluxuri materiale și informaționale care nu sunt transformate în proces, dar sunt necesare pentru implementarea lui.
  • Mecanism. Intră în lucrare de jos și arată oamenii, mijloacele tehnice, sistemele informaționale etc., cu ajutorul cărora este implementat procesul de afaceri.
  • rezultate ieși din bloc pe dreapta.

Elementele de bază ale diagramei:

Baza limbajului grafic IDEF0, a cărui sintaxă și semantică sunt definite cu o rigoare absolută, este alcătuită din blocuri și săgeți care le conectează, care formează o ierarhie de diagrame detaliate.

Element Afișaj grafic
și sens
Cerințe de înregistrare
Funcţional
bloc
Înfățișat ca dreptunghi.
Reprezintă funcții definite ca activitate, proces, operație, acțiune sau transformare.
1. Trebuie să fie unic
numărul de identificare în colțul din dreapta jos;
2. Titlul trebuie să fie în starea verbală.
Interfațăarc
(săgeată, arc)
Înfățișat ca o săgeată unidirecțională.
Reprezintă date sau obiecte materiale asociate cu funcții.
1. Trebuie să aibă un nume unic.
2.Numele trebuie să fie o formă a unui substantiv.
3.Numai blocurile funcționale pot fi începutul și sfârșitul unui arc.
4. Sursa poate fi doar partea de ieșire a blocului, iar receptorul poate fi oricare dintre cele trei rămase.

IDEF0 - model:

Modelul include următoarele documente, care se referă între ele:

  • Diagrame grafice este componenta principală a modelului IDEF0, care grafic, folosind blocuri și săgeți și conexiunile acestora, afișează informații despre sistemul modelat. Blocurile reprezintă funcții de bază. Aceste funcții pot fi defalcate (descompuse) în părțile lor componente și prezentate în diagrame mai detaliate. Procesul de descompunere continuă până când obiectul este descris la nivelul de detaliu necesar pentru atingerea scopurilor unui anumit proiect.
  • Text;
  • Glosar— Pentru fiecare element al diagramei, se creează și se menține un set de definiții; Cuvinte cheie, explicații care caracterizează obiectul pe care îl reprezintă acest element. Acest set se numește glosar și este o descriere a entității a acestui element. Glosarul completează armonios limbajul grafic vizual, oferind diagramelor informațiile suplimentare necesare.
De exemplu, pentru interfața de control arc „ordin de plată”, glosarul poate conține o listă de câmpuri ale documentului corespunzătoare arcului, setul necesar de vize etc.

Principiul descompunerii la construirea unui model de proces de afaceri

1. Diagrama contextului: scop și punct de vedere

Modelarea proceselor de afaceri începe cu o diagramă de context. Această diagramă se numește A–0 (A minus zero). Pe acesta, sistemul este reprezentat ca un bloc și arce care descriu mediul sistemului. Folosind o diagramă, puteți vedea interacțiunea sistemului simulat cu mediul extern, toate intrările și ieșirile acestuia. Diagrama A–0 stabilește zona de modelare și limitele.

Textul explicativ pentru diagrama de context trebuie să indice ţintă trasarea și înregistrarea Punct de vedere. Punctul de vedere determină nivelul de detaliu, direcția de dezvoltare a modelului și vă permite să descărcați modelul. Astfel, atunci când modelezi, poți evita detalierea și cercetarea. elemente individuale, care nu sunt necesare pe baza punctului de vedere ales asupra sistemului.

2. Detaliu

Blocul care reprezintă întregul sistem este apoi detaliat într-o altă diagramă.

În plus, fiecare funcție a diagramei poate fi detaliată într-o diagramă copil. Fiecare funcție este modelată de un bloc separat. Fiecare bloc părinte este descris în detaliu printr-o diagramă copil la un nivel inferior. Aceasta continuă până când se obține o structură care să permită răspunsul la întrebările formulate în scopul modelării.

Pentru a obține integritatea structurală a modelului, se folosesc următoarele reguli:

  • Toate arcurile de interfață care intră sau emană din acest bloc sunt înregistrate pe diagrama copil.
  • La numerotarea blocurilor, numărul din colțul din dreapta jos al dreptunghiului indică numărul de serie unic al blocului însuși pe diagramă, iar desemnarea din colțul din dreapta indică numărul diagramei copil pentru acest bloc.

Principiul tunelului

Există adesea cazuri când săgețile individuale nu au sens să fie luate în considerare în continuare în diagramele copil sub un anumit nivel în ierarhie sau invers - blocurile individuale nu au sens practic peste un anumit nivel. Pe de altă parte, uneori este nevoie de a scăpa de săgețile „conceptuale” individuale și de a nu le detalia peste un anumit nivel.

Pentru a rezolva astfel de probleme, standardul IDEF0 oferă conceptul tunelare. Desemnarea „tunel” a două paranteze în jurul începutului unei săgeți indică faptul că săgeata nu a fost moștenită de la un bloc părinte funcțional și apare (din „tunel”) doar în această diagramă. La rândul său, aceeași denumire în jurul capătului săgeții din imediata apropiere a blocului receptor înseamnă faptul că în diagrama copil a acestui bloc această săgeată nu va fi afișată și nu va fi luată în considerare.

Principiul limitării complexității

Pentru a limita supraîncărcarea modelelor și a le face mai ușor de înțeles, standardul adoptă restricții adecvate de complexitate:

  • limitând numărul de blocuri funcționale de pe diagramă la trei până la șase. Limita superioară (șase) obligă proiectantul să folosească ierarhii atunci când descrie obiecte complexe, iar limita inferioară (trei) asigură că diagrama corespunzătoare are suficiente detalii pentru a justifica crearea acesteia;
  • limitarea numărului de arce de interfață potrivite pentru un bloc funcțional (ieșind dintr-un bloc funcțional) la patru.

Desigur, nu este deloc necesar să urmați cu strictețe aceste restricții, cu toate acestea, după cum arată experiența, ele sunt foarte practice în munca reală.

Analiza grafică cantitativă: raportul de sold și evaluarea numelui

Analiza cantitativă este utilizată pentru a analiza diagrama din punctul de vedere al congestiei acesteia și al dificultății de percepție. Următorii indicatori sunt utilizați pentru analiză:

  • numărul de blocuri pe diagramă - N;
  • nivel de descompunere a diagramei - L;
  • echilibrul diagramei - ÎN;
  • numărul de săgeți care se conectează la bloc - A.

Factorul de echilibru

Este necesar să ne străduim să ne asigurăm că numărul de blocuri de pe diagramele nivelurilor inferioare este mai mic decât numărul de blocuri de pe diagramele părinte.

De asemenea, diagramele trebuie să fie echilibrate. Aceasta înseamnă că în cadrul aceleiași diagrame nu ar trebui să existe o situație în care să existe semnificativ mai multe săgeți de intrare și săgeți de control decât cele care ies.

Trebuie remarcat faptul că această recomandare pot să nu fie îndeplinite în modelele care descriu procesele de producție. De exemplu, atunci când descrieți o procedură de asamblare, un bloc poate include multe săgeți care descriu componentele unui produs și o singură săgeată care părăsește produsul finit.

Să introducem factorul de echilibru al diagramei:

Este necesar să ne străduim să Q a fost minimă pentru diagramă și a scăzut odată cu creșterea nivelului de descompunere.

Evaluarea numelui

Pe lângă analiza elementelor grafice ale diagramei, este necesar să se ia în considerare denumirile blocurilor. Pentru a evalua numele, este compilat un dicționar de funcții elementare (triviale) ale sistemului modelat. De fapt, în acest dicționar funcţiile nivelului inferior de descompunere a diagramei trebuie să cadă.

De exemplu, pentru un model de bază de date, funcțiile „găsiți o înregistrare” și „adăugați o înregistrare în baza de date” pot fi elementare, în timp ce funcția „înregistrare utilizator” necesită o descriere suplimentară.

După formarea unui dicționar și compilarea unui pachet de diagrame de sistem, este necesar să se ia în considerare nivelul inferior al modelului. Dacă există potriviri între numele blocurilor de diagramă și cuvintele din dicționar, aceasta înseamnă că a fost atins un nivel suficient de descompunere.

Coeficientul care reflectă cantitativ acest criteriu poate fi scris astfel:

L*C

produsul nivelului de model și numărul de potriviri ale numelor de bloc cu cuvintele din dicționar. Cu cât nivelul modelului este mai scăzut (L mai mare), cu atât potrivirile sunt mai valoroase.

  1. Modelare funcțională Sistem informatic folosind tehnologia IDEF CASE.
  2. Descrierea logicii interacțiunii și a succesiunii de lucru.

2. Planul de lecție

  1. Controlul cunoștințelor prin testare (test ISE002).
  2. Dezvoltarea unui model pe mai multe niveluri de activitate a sistemului informatic (model AS - IS) folosind instrumentul BPwin CASE folosind tehnologii IDEF 0Și IDEF 3 :
    • Descrierea proprietăților modelului (Proprietăți model).
    • Crearea primului nivel al modelului funcțional - elaborarea unei diagrame de context.
    • Crearea celui de-al doilea nivel al modelului funcțional - detalierea lucrării contextuale și elaborarea unei diagrame de descompunere.
    • Crearea celui de-al treilea nivel al modelului funcțional - detalierea activității celui de-al doilea nivel care implementează funcția Contabilitatea activității organizatii. Această etapă de dezvoltare permite crearea unei diagrame de descompunere folosind una dintre cele două metodologii - IDEF 0 (prima opțiune) sau IDEF 3 (a doua opțiune). Conform celei de-a 2-a opțiuni, crearea unui scenariu și a unei diagrame de secvență pentru realizarea lucrărilor individuale (Diagrama fluxului de lucru) în procesul de contabilizare a activităților se realizează folosind metodologia IDEF 3.
  3. Dezvoltarea unui dicționar de lucrări și a unui dicționar de săgeți care vă permit să afișați o descriere a fragmentelor corespunzătoare ale modelului.
  1. Modelarea funcțională a unui sistem informațional folosind tehnologie IDEF trebuie efectuată cu ajutorul unui instrument CASE BPwin, care este încărcat de comandă Start/Programe/Computer Associates/BPwin 4.0/BPwin4.0 . Procesele tehnologice ale modelării IDEF sunt prezentate în secțiunea 4 „Informații teoretice pentru lecția practică”.
  2. La elaborarea unei diagrame de context, trebuie luat în considerare faptul că proprietățile modelului pot fi formatate după cum urmează, folosind informații corespunzătoare domeniului de subiect modelat:
    • Numele modelului : Activitățile companiei „Nume”;
    • Proiect (numele proiectului): Modelul de activitate al companiei „Nume”;
    • Nume complet, grup;
    • Domeniul de aplicare (zona de modelare care include scopul modelării, adică întrebări la care modelul construit ar trebui să răspundă) – de exemplu, „Conducerea generală a activității companiei: cercetare de piață, achiziție de componente, testare și vânzare de produse” sau „Aspecte tehnologice, financiare și manageriale ale activităților companiei”;
    • Interval de timp (tip de model) : Așa cum este;
    • Definiție , scopul modelului) : Model educațional care descrie activitățile companiei „Nume”;
    • Punct de vedere (Punct de vedere persoană al cărei punct de vedere este adoptat în timpul dezvoltării) : Șeful întreprinderii și directorul general;
    • stare : FUNCTIONARE;
    • Scop : Modelarea proceselor de afaceri curente ale companiei „Nume” în vederea reglementării activităților acesteia;
    • Sursă (sursă informație): Analiza domeniului si analiza documentelor de intrare;
    • Numele autorului : NUMELE COMPLET.
  3. Facand descompunerea diagramei de context trebuie avut în vedere că ea, fiind al doilea nivel descompunerea modelului de sistem, reprezintă subproces sau munca copilului , implementate în formă lucrare contextuală, care în acest caz acționează ca munca parentală, implementat în formular Diagrama parentală) . Diagrama de descompunere al doilea nivel trebuie să conțină cel puțin trei blocuri funcționale, dintre care unul trebuie să îndeplinească funcția de modelare contabilitatea activitatii organizație, iar restul ar trebui să îndeplinească funcția de modelare procesele de afaceri implementate în sistem.
  4. La fiecare pas de descompunere, ar trebui să monitorizați procesul de mișcare automată a arcurilor de interfață (săgeți) la nivelurile inferioare ale modelului și să încercați să evitați crearea de săgeți tunelizate în mod inutil. Dacă apar, tunelurile ar trebui îndepărtate.
  5. La implementare al treilea nivel descompunere, trebuie avut în vedere că fiecare dintre diagramele de descompunere elaborate este al treilea nivel de descompunere a lucrărilor de al doilea nivel și reprezintă subproces sau munca subsidiara implementate în formă Diagrama copilului lucrări relevante de nivel al treilea. Toate lucrările de al doilea nivel în acest caz acționează ca munca parentală, implementat în formular diagrame părinte(Diagrame parentale).
  6. Descompunerea lucrării de nivel al doilea, modelarea funcției contabile și crearea unui scenariu pentru interacțiunea muncii ar trebui efectuate folosind tehnologia IDEF 3 care folosește ca blocuri funcționale unitatimuncă (Unitatea de lucru, UOW) , precum și cele necesare obiecte de referință (referenți) , care poate fi fie implementat în script din dicționarul cu săgeți, fie creat din nou.
  7. Un dicționar de lucru și un dicționar de săgeți sunt create la fiecare nivel de descompunere a modelului, iar o condiție necesară pentru dezvoltarea lor este prezența unei descrieri de lucru. (activitate)și descrieri ale datelor înregistrate pe arcul de interfață ( săgeată) .
  8. Salvați rezultatele lucrării într-un fișier Function_model IS_Name_ IDEF.bp1 în folderul dvs EU VAD.
  9. Un exemplu de model funcțional generalizat este dat în

4. Informații teoretice pentru lecția practică

4.1. IDEF 0-tehnologie

Metodologia IDEF0 este concepută pentru a modela activitățile unei organizații. În etapa inițială a dezvoltării proiectului, se creează un model conceput pentru a descrie procesele de afaceri și procesele tehnologice existente în întreprindere conform principiului „AS - IS” („As Is”) și, mai important, reprezintă întreprinderea din perspectiva angajaților care lucrează acolo și cunosc în detaliu toate nuanțele, inclusiv cele informale. AS-IS este „ceea ce facem astăzi”, înainte de a trece la „ce vom face mâine”.

Model de activitate sau, cu alte cuvinte, model functional. Model functional tratează sistemul ca pe un set actiuni, in care fiecare acțiune transformă pe unele un obiect sau set de obiecte . Tehnologie IDEF 0 folosește principiul descompunere functionala sisteme (împărțirea sistemului în fragmente). Principiul de descompunereînseamnă că modelul funcțional trebuie construit conform regulii "de sus în jos" , din general tip de model la privat modele. Prin urmare, de obicei, modelul funcțional pentru rezolvarea unei probleme este un set de modele funcționale private .

Modelele funcționale evidențiază acțiunile reprezentându-le ca un element special - bloc. bloc elementul structural principal al modelului funcțional, reprezentare grafică care este diagramă . Numele acțiunii substantiv verbal sau verb . Ca rezultat al descompunerii modelului, este creat un set de diagrame ordonate ierarhic și interconectate. Fiecare diagramă este o unitate de descriere a sistemului și se află pe o foaie separată.

Metodologie IDEF 0 se bazează pe patru concepte de bază: bloc funcțional (nod), arc de interfață, descompunere, glosar.

Bloc funcțional

Conceptul fundamental de tehnologie IDEF 0 este conceptul bloc funcţional. Este destinat să reprezinte un anumit tip Activitate , care reprezintă unele specifice funcţie în cadrul sistemului în cauză. Această funcție înseamnă, la rândul său, o anumită acțiune (set de acțiuni), având un scop fix și conducând la un rezultat final.

Bloc funcțional este reprezentat printr-un dreptunghi, ale cărui laturi au următoarele valori:

  • Partea de sus este managementul.
  • Partea de jos este mecanismul.
  • Partea dreaptă este ieșirea.
  • Partea stângă este intrarea.

Un bloc funcțional are un nume, care este specificat în modul verbal sau un substantiv verbal. Interacțiunea dintre acțiuni iar lumea din jurul lui, inclusiv alte acțiuni, este afișată folosind arce de interfață (săgeți).

Arc de interfață

Arc de interfață afişează un element de sistem care sau prelucrate bloc funcțional sau are un efect diferit la activitatea (funcţia) afişată de acest bloc funcţional. Arc de interfață descris ca o săgeată care indică purtător , asigurand transferul de date sau obiecte de la o activitate la alta. Săgețile descriu interacțiunea lucrărilor cu lumea exterioară și între ele, reprezintă unele informații și sunt numite substantive .

Numele săgeții îl indică rol (setul de roluri posibile este notat cu – ICOM ):

Intrare bloc funcțional – eu nput .

management - C Control .

Ieșire bloc funcțional – O ieșire .

Mecanism - M mecanism .

Intrare) este materialul sau informația care este folosită sau transformată de muncă pentru a produce un rezultat (ieșire). Este posibil să nu existe săgeată de intrare.

Control– reguli, politici, proceduri sau standarde care ghidează munca. Ea influențează munca, dar nu este transformată de muncă. Săgeata este desenată ca intrând în marginea superioară a lucrării. Fiecare bloc funcțional trebuie să aibă cel puțin o săgeată de control.

Este adesea dificil de determinat dacă datele sunt introduse sau controlate. Dacă datele din lucrare sunt modificate sau procesate, atunci aceasta este cel mai probabil intrare, iar dacă nu, este control. Dacă este dificil să determinați starea unei săgeți, se recomandă să desenați o săgeată de control.

Ieșire– materialul sau informația care este produsă de lucrare. Este necesară cel puțin o săgeată de ieșire, care emană din partea dreaptă a lucrării.

Mecanism de execuție (Mecanism)– resursele care efectuează munca (de exemplu, personal, mașini, dispozitive etc.). Săgeata este desenată ca intrând în marginea de jos a lucrării. Este posibil ca săgețile mecanismului să nu fie afișate. În general, blocul funcțional este prezentat în Fig. 2.1.

În fig. 2.1 toate arcurile de interfață sunt afișate ca săgeți denumite. Conform cerințelor standardului, fiecare bloc funcțional trebuie să aibă cel puțin o ieșire și un control, deoarece fiecare sarcină (proces) trebuie să aibă cel puțin o ieșire și cel puțin o regulă pentru rezolvarea acesteia. Este posibil ca arcul de interfață „Mecanism” să nu fie reprezentat.

Din mai multe blocuri funcționale conectate prin arcuri de interfață în modul cerut, a model functional.

Vă rugăm să rețineți că săgețile se pot ramifica pentru a realiza conexiunile necesare între blocurile funcționale.

Log in blocul funcțional poate fi nu numai Ieșire un alt bloc funcțional, dar și al acestuia Control sau chiar mecanism. Ca urmare, modelul funcțional poate conține procese diverse, destul de complexe și neobișnuite pentru rezolvarea problemelor din sistemul informațional.

Crearea de diagrame folosind tehnologia IDEF0

Atunci când se dezvoltă modelul de afaceri al unei organizații, trebuie utilizate trei tipuri de diagrame:

  • Diagrama tip I – Diagrama context (nu poate fi decât unul) – vârful structurii arborescente, care reprezintă cel mai abstract nivel de descriere a sistemului și a interacțiunii acestuia cu mediul extern. Ea definește funcția de context;
  • II tip diagramă – Diagrama de descompunere .

Diagramele de defalcare sunt concepute pentru a detalia lucrul și a conține legate de munca, adica filiale munca care are un comun părintească muncă. Munca de nivel inferior este aceeași cu munca de nivel superior, dar mai detaliat. Diagramele sunt create de un analist pentru a conduce o sesiune de examinare, adică pentru a discuta diagrama cu un specialist în materie.

După fiecare sesiune de descompunere, se desfășoară sesiuni de examinare - experții în materie indică conformitatea proceselor reale de afaceri cu diagramele create. Neconcordanțele găsite sunt corectate și numai după promovarea examenului fara comentarii puteți trece la următoarea sesiune de descompunere. Acest lucru asigură că modelul se potrivește cu procesele de afaceri reale la orice nivel al modelului.

Este necesar să setați numărul de lucrări la cel mult șase (3–6), altfel diagrama este greu de citit (suprasaturată). Limita superioară (șase) forțează proiectantul să folosească ierarhii atunci când descrie obiecte complexe, iar limita inferioară (trei) asigură că diagrama corespunzătoare are suficiente detalii pentru a justifica crearea acesteia.

Într-o diagramă de defalcare, lucrarea care este cea mai importantă și finalizată mai întâi este situată în stânga sus. Lucrarea care este mai puțin importantă sau finalizată mai târziu scade secvenţial.

  • III tip de diagramă – Diagrama arborescentă a nodurilor arată dependența ierarhică a locurilor de muncă, dar nu și relațiile dintre joburi (pot fi atât de multe dintre aceste diagrame, câte doriți, deoarece arborele poate fi construit la orice adâncime și nu neapărat de la rădăcină).

4.2. Procesul tehnologic de modelare IDEF0:


Orez. 2.2

Instrumentul BPWin CASE are un instrument simplu și clar interfața cu utilizatorul pentru a construi modelele funcționale și scenariile necesare. Depinde de tehnologia folosită. În fig. 2.2 arată fereastra BPWin ( Computer Associates B.P.Win ).

Bara de instrumente a ferestrei principale Computer Associates BPwin conține următoarele butoane:

- Creație model nou,

– deschiderea unui model existent,

– salvarea modelului construit,

- imprimare model,

- alegerea scalei,

- scalare,

verificare a ortografiei,

- porniți/dezactivați navigatorul de model,

– porniți/dezactivați Model Mart.

Navigatorul de modele arată compoziția modelului în funcție de nivelul de dezvoltare. Cu ajutorul lui, puteți trece ușor și rapid de la un nivel la altul. Lucrul cu navigatorul de model este similar cu lucrul cu Windows Explorer.

Bara de instrumente specială conține următoarele butoane principale:

Fereastra model este locul pentru crearea unui model funcțional al sistemului studiat. În acesta, blocurile funcționale sunt construite și editate, săgețile sunt desenate și editate și se realizează descompunerea.

Pregătirea modelului

  1. Faceți clic pe butonul de creare a modelului pentru a deschide caseta de dialog B.P.Win(Fig. 2.3):

În caseta de dialog B.P.Win efectuați următoarele acțiuni:

  • alege Proces de afaceri (IDEF0);
  • setați numele modelului și apăsați butonul Bine;
  • La fereastră Proprietăți pentru modelul nou înregistrați numele autorului modelului;
  • apasa butonul Bine .

  1. Echipă Model/Proprietăți model caseta de dialog apel Proprietățile modelului (Fig. 4), în care să se oficializeze proprietățile modelului în conformitate cu recomandările metodologice expuse în secțiunea 2.

Primul nivel de modelare

  1. Proiectați un bloc funcțional în fereastra modelului, parcurgând următorii pași:
    • V meniul contextual comanda de selectare a blocului funcțional Nume… ;
    • în caseta de dialog Proprietățile activității (Fig. 2.5) în tab Nume a stabilit Nume lucru (scurt) plasat în acest bloc funcțional, și în fila Definițieîn câmp Definiție Descriere muncă;
    • în marcaj Font setați fontul Arial Cyr și bifați casetele pentru a permite ca acest font să fie utilizat în toate blocurile funcționale ale diagramei ( Toate activitățile din această diagramă, Toate activitățile din acest model Și Schimbați toate aparițiile acestui font în model ), apoi apăsați butonul Bine.
    • în caseta de dialog Proprietăți săgeți (Fig. 2.7), în tab Nume setați numele săgeții (scurt), iar în filă Definițieîn câmp Definiție introduceți suficiente detalii Descriere scopul acestei săgeți;

    • selectați o comandă din meniul contextual săgeată Font… ;
    • în caseta de dialog Proprietăți săgeți (Fig. 2.8), în tab Font setați fontul Arial Cyrși bifați casetele pentru a utiliza acest font pentru toate săgețile din diagramă ( Toate săgețile din această diagramă, Toate săgețile din acest model, Toate instanțele acestei săgeți Și Schimbați toate aparițiile acestui font în model );

  1. Proiectați o săgeată Ieșire, stânga frontiere dreapta;
  2. Proiectați o săgeată Control , de ce repetați pasul 2, înlocuind stânga frontiere top;
  3. Proiectați o săgeată Mecanism, de ce repeta pasul 2, inlocuind stânga frontiere inferior.

Al doilea nivel de modelare

Orice nivel de modelare

Pentru a crea o descompunere a modelului la orice nivel de modelare, ar trebui să efectuați următorii pași:

  • activați un anumit bloc funcțional făcând clic;
  • repetați pasul 3 pentru nivelul actual al modelului.
  1. Tipul și stilul de design al săgeții pot fi selectate în caseta de dialog Arrow Properties (Fig. 2.9), apelată de comanda Style din meniul contextual săgeată.

  1. Pentru instalare împachetarea cuvintelor Ar trebui, prin evidențierea numelui, să reduceți dimensiunea dreptunghiului, după care acesta va crește automat în jos.
  2. Fiecare săgeată desenată pe o diagramă de nivel superior trebuie să fie neapărat prezentă pe diagramă pentru mai mult de nivel scăzut.
  3. Săgeată nouă desenată pe diagrama de nivel scăzut (nerezolvată ( nerezolvată) săgeată), este plasată între paranteze drepte (tunele), care subliniază absența unei astfel de săgeți la un nivel superior. Pentru a elimina tunelurile:
    • selectați elementul de meniu Arrow Tunnel ;
    • în caseta de dialog Editor săgeată chenar(Editor săgeată limită) selectați opțiunea Rezolvați-l la Border Arrow (Permiteți ca săgeată la margine). Ca urmare, tunelul de la nivelul actual va fi eliminat, iar săgeata va apărea la nivelul anterior, iar dacă nu este primul, atunci este tunelizat (Fig. 2.10).

  1. Pentru a copia săgețile tunelizate de la nivelul inferior în cel superior:
    • click dreapta pe paranteza patrata;
    • selectați elementul de meniu Referință în afara paginii;
    • în caseta de dialog Referință săgeată în afara paginii selectați diagrama pe care să plasați săgeata și setați comutatorul de tip săgeată necesar (Fig. 2.11);

  • apăsați unul dintre butoanele: OK și mergeți la diagramă (mergi la diagrama selectată) sau OK și rămâneți în diagrama curentă (Rămâneți în diagrama curentă).
  • Este inacceptabil să lăsați săgeți de delimitare neconectate ( săgeată de frontieră neconectată) – săgețile transferate automat în diagrama de descompunere din diagrama părinte (mod migrație trăgător). Aceste săgeți nu se referă la joburi și trebuie să fie asociate cu joburi în modul Creare săgeți ( Instrumentul săgeată de prioritate – ).
  • Proiectarea locației și stilului corect al săgeților în mod implicit:
    • executa comanda Model/Proprietăți model;
    • La fereastră Proprietățile modelului(Fig. 2.12) selectați un marcaj Aspect ;
    • bifați caseta (opțional) Spațiează automat săgețile in grup Săgeți
    1. Când creați o săgeată părere asupra managementului ar trebui să setați opțiunea pentru a indica direcția săgeții Extra Arrowhead (din meniul contextual).
    2. Dacă etichetele de pe săgeți sunt prost plasate (foarte departe, etc.), ar trebui să bifați caseta de selectare Squiggle (în meniul contextual) pentru liderul etichetei.
    1. În diagrama de descompunere, în stânga sus este un bloc funcțional, care conține cea mai importantă lucrare care este efectuată mai întâi. Lucrarea care este mai puțin importantă sau finalizată mai târziu scade secvenţial.
    2. Împachetarea cuvintelorîn interiorul lucrării se desfășoară în modul Editor de nume... prin apăsarea unei taste introduce.
    3. O diagonală în colțul din stânga sus al dreptunghiului înseamnă că lucrarea corespunzătoare nu este descompusă.
    4. Pentru a afișa nu numai numărul de joburi secundare care apar automat, ci și prefixele (A), ar trebui să selectați comanda Proprietăți model/model, marcaj Numerotare caseta de selectare (optional) Afișați prefixul(Fig. 2.13).

    1. Pentru a afișa numerele de lucru și numerele de nivel (numere cu două, trei, patru cifre) pentru locurile de muncă pentru copii, selectați comanda Proprietăți model/model, marcaj Numerotare caseta de selectare (optional) Utilizați formatul de numerotare diagramă (Fig. 2.13).
    2. A distinge versiuni diferite din aceeași diagramă, versiunilor individuale ar trebui să li se atribuie numere (C - număr), care pot fi setate în mod arbitrar în meniu Proprietăți diagramă pe marcaj Kit.

    Construirea unui arbore model

      • echipă Diagramă/Adăugați/Arbore de noduri caseta de dialog apel Node Tree Wizard_Pasul 1 din 2 (Fig. 2.14);
      • conduceți un dialog selectând numărul necesar de niveluri de arbore de noduri ( Numărul de niveluri );
      • apasa butonul Gata.

    4.3. Tehnologia IDEF3

    Tehnologie IDEF3 este o metodologie de descriere a procesului care ia în considerare secvență de execuțieȘi relații cauză-efectîntre situaţii şi evenimente. Folosind IDEF3, ele descriu logica executării lucrărilor, ordinea în care sunt începute și finalizate.

    Tehnologia IDEF3 folosește categoria scenarii pentru a simplifica structura descrierilor unui proces complex în mai multe etape. Scenariu (Scenariu) este o secvență repetată de situații sau acțiuni care descriu o clasă tipică de probleme prezente într-o organizație sau sistem și este, de asemenea, o descriere a secvenței de proprietăți ale unui obiect în cadrul procesului luat în considerare. Modelele IDEF0 sunt legate de scenariile IDEF3, deoarece fiecare model IDEF0 poate fi reprezentat ca unul sau mai multe scenarii IDEF3.

    Tehnologia IDEF3 este concepută pentru a oferi colectarea datelor de proces și permite:

    • documentează datele disponibile cu privire la tehnologia de desfășurare a procesului, identificate, să zicem, în cadrul unui sondaj al specialiștilor din domeniu;
    • analizează procesele existente și dezvoltă altele noi;
    • simuleaza situatii prin identificarea situatiilor in care este necesar luarea deciziilor , care afectează ciclul de viață al procesului, de exemplu, modificări ale designului, proprietăților tehnologice sau operaționale ale produsului final;
    • promovează adopția solutii optime la reorganizarea procesului.

    Scenariu în tehnologia IDEF3

    Diagrame de scenarii descrie acțiuni și evenimente care trebuie procesate într-o anumită perioadă de timp. Scriptul este însoțit de o descriere a proceselor și poate fi folosit pentru a documenta fiecare funcție a sistemului. În consecință, scenariile fac parte din analiza sistemului, deoarece fac posibilă analiza în timp a unei situații și descrierea obiectelor care participă la un proces în același timp.

    Când se utilizează tehnologia IDEF3, toate construcțiile se bazează pe două tipuri de diagrame:

    1. Diagrama care descrie succesiunea etapelor procesului.
    2. Diagrama stării obiectului.

    Sunt utilizate următoarele convenții standard:

    Elementul funcțional al comportamentului,

    Transferarea acțiunii de la unul element funcţional comportament (precedent) față de altul (ulterior) ( Precedenta ),

    Tranziția fluxului de date de la job la job ( Fluxul obiectelor ),

    Conectarea datelor la locul de muncă ( Referent ),

    Relația dintre lucrări ( Relațional ),

    Starea obiectului.

    Reglarea secvenței de execuție a unităților de lucru se realizează prin introducerea în diagramă intersecții (Joncţiune) în diverse scopuri.

    Simbol J intersectia poate lua una din următoarele valori:

    • & – fuziune rezultatele tuturor acțiunilor dacă săgețile intră în intersecție; lansa toate acțiunile dacă săgețile îl părăsesc;
    • DESPRE - fuziune acțiunea rezultă dacă cel puțin una dintre acțiunile de intrare este finalizată; lansa cel puțin o acțiune;
    • X - fuziune o singură acțiune dintr-un număr dintre cei care intră în intersecție; lansa doar una dintre acţiunile care ies din ea.

    O ilustrare a utilizării unei răscruce în diagrame care descriu succesiunea etapelor procesului este fig. 2.15. Din aceasta rezultă că o răscruce este un mijloc de construire a unor procese tehnologice ramificate complexe.

    Descrierea tehnologiei care este dezvoltată sau cercetată mai întâi sub formă diagrame care descriu succesiunea etapelor procesului tehnologic , și apoi în formă diagrame de stare a obiectelor oferă o imagine completă a acțiunilor efectuate și a rezultatelor aplicării acestora.

    Job 3 apare atunci când Job 1 și Job 3 sunt terminate

    Iov 1 și Iov 2 apar împreună

    Lucrarea 3 apare atunci când Lucrarea 1 sau Lucrarea 2 sau ambele sunt terminate

    Job 1 și Job 2 apar împreună sau separat

    Lucrarea 3 apare atunci când Lucrarea 1 sau Lucrarea 2 este încheiată

    Are loc Job 1 sau Job 2

    În consecință, managerii și dezvoltatorii de sisteme informatice au în mâinile lor un instrument puternic pentru crearea de scenarii pentru procese complexe de management care necesită studiu și automatizare.

    4.4. Procesul tehnologic de modelare IDEF3

    Pregătirea modelului

    1. Faceți clic pe butonul de creare a modelului.
    2. În caseta de dialog B.P.Win urmează următoarele instrucțiuni:
      • alege Fluxul procesului (IDEF3);
      • setați numele modelului;
      • apasa butonul Bine;
      • în caseta de dialog Proprietăți pentru modelul nou confirmați proprietățile specificate acolo.

    Formalizarea actiunii

    1. Faceți clic pe butonul de acțiune de creare ( Instrumentul casetei de activități ).
    2. Faceți clic pe butonul stâng al mouse-ului în locația dorită din fereastra modelului.
    3. În meniul contextual de acțiune, selectați comanda Nume
    4. În caseta de dialog Proprietățile activității, în marcaj Nume setați numele acțiunii (Fig. 2.16).

    1. În caseta de dialog Proprietățile activitățiiîn marcaj Font a stabilit Arial Cyr, Bine.

    Formatarea datelor

    1. Faceți clic pe butonul de creare a datelor. ( Instrument de referință ).
    2. La locul potrivit pe fereastră Referent faceți clic stânga pentru a încorpora numele datelor din dicționarul de entități create (opțiune Entitate) sau din dicționarul creat de săgeți (opțiunea Săgeată), sau creați-le din nou (opțiune Alte) (Fig. 2.17).

    1. În dialog Fereastra Proprietăți referitor (Fig. 2.18), în tab Font a stabilit Arial Cyr bifați casetele de selectare necesare și faceți clic pe butonul Bine.

    5. Temele pentru următoarea lecție

    1. Gândiți și identificați obiectele materiale sau indivizii, reprezentând surse sau receptori de informații (entități externe).
    2. Gândește-te și dezvoltă-te model relațional datele prelucrate de sistemul informatic:
      • faceți o listă de entități și atributele acestora,
      • arata relatiile dintre entitati.
    3. Bazat pe dezvoltat termeni de referinta gândiți-vă și propuneți profesorului denumirile lucrărilor individuale implementate în sistem în procesul de realizare a fiecăreia dintre lucrările cheie plasate în diagrama de descompunere de nivelul doi.
    4. Executarea paragrafelor Înregistrați 1-3 teme pentru acasă într-un fișier numit „ Informații pentru lecția 3.doc „, realizat în Cuvânt, și prezentat profesorului.
    5. Lucrați prin secțiunea " Informații teoretice pentru pregătirea practică» atelier la a 3-a lecție.

    1.6. Fragment din diagrama arborelui nodului la efectuarea descompunerii blocului de contabilitate a activității conform celei de-a doua opțiuni (IDEF3)

    Dicţionar de activitate

    Nume

    Definiție

    Analiza informațiilor citite din baza de date pentru a satisface criteriile specificate

    Analiza documentelor

    Analiza documentelor însoțitoare și primite pentru conformitatea cu standardele

    Întreținerea bazei de date

    Efectuarea operațiunilor de actualizare a datelor

    ÎN CURS
    LOC DE MUNCA

    Numele funcției de context care definește SCOPUL și LIMITELE simulării

    Prelucrare finală

    Luarea si formularea unei decizii (POZITIV daca datele indeplinesc criteriile specificate si NEGATIV in caz contrar), precum si crearea si prelucrarea documentelor necesare

    Control de calitate
    și testare

    Lucrări care finalizează un proces de fabricație sau dezvoltare

    Procesarea datelor

    Efectuarea de operațiuni de căutare și analiză a datelor și luarea deciziilor pe baza analizei efectuate

    Prelucrarea rezultatelor controlului calității

    Sistematizarea si analiza rezultatelor pentru conformitatea cu standardul

    Prelucrarea rezultatelor testelor

    Analiza rezultatelor pentru funcționalitate, fiabilitate și supraviețuire

    Hârtii

    Primirea documentelor și selectarea informațiilor pentru a fi introduse în baza de date

    Căutarea datelor în tabelele bazei de date pe baza interogărilor create de utilizator

    Reumplerea bazei de date

    Introducerea de date noi în tabelele bazei de date

    Recepția și înregistrarea documentelor

    Recepția și înregistrarea documentelor de însoțire primite

    Productie sau dezvoltare

    Numele procesului cheie de afaceri al companiei (modelul părții de producție a domeniului subiect)

    Lucrul în prima etapă a procesului de afaceri1

    O acțiune care rezumă operațiunile tehnologice din prima etapă a procesului de producție

    Lucrul în etapa a 2-a a procesului de afaceri1

    O acțiune care rezumă operațiunile tehnologice din a doua etapă a procesului de producție

    Lucrul în etapa a 3-a a procesului de afaceri1

    O acțiune care rezumă operațiunile tehnologice din a treia etapă a procesului de producție

    Prelucrarea rezultatelor activităților de producție

    Recepția și analiza documentelor pe baza rezultatelor muncii și controlului în curs

    Editarea bazei de date

    Modificarea înregistrărilor în tabelele bazei de date

    CONTABILITATE DE ACTIVITATE

    Prelucrarea documentației și raportarea (modelul părții de non-producție a domeniului de studiu)

    Dicţionar Arrow

    Nume

    Definiție

    Obiecte care nu îndeplinesc cerințele standardului

    DATE DE INTRARE

    Documente primite și obiecte de procesare

    Date de intrare DB

    Datele care urmează să fie scrise în tabelele bazei de date

    Documentele primite

    Documente care însoțesc obiectele de procesare și documentele care inițiază un proces de afaceri

    IEȘIRE

    Documente trimise, obiecte noi și modificate

    Documente de ieșire

    Documente (formulare, rapoarte, instrucțiuni, declarații, contracte etc.) create în timpul procesului de contabilitate

    Standard de stat

    Standard de stat pentru documentare

    Datele din tabelul bazei de date

    Date citite din tabelele bazei de date

    Date obținute în urma analizei

    Informații destinate procesării documentelor emise și utilizate la luarea deciziilor

    Date care caracterizează rezultatele lucrului cu documente

    Informații care reflectă detaliile (caracteristicile calitative și cantitative) ale obiectelor prelucrate

    Documente privind rezultatele testării și controlului

    Documente care reflectă datele obținute în etapa finală a procesării obiectului

    Descrierea postului

    Instrucțiuni care reflectă responsabilitatile locului de munca interpret

    Cererile utilizatorilor

    Obiecte noi și schimbate

    Obiecte create și modificate în timpul ciclului de producție

    Obiecte baze de date

    Tabele, formulare, interogări, rapoarte, macrocomenzi și module

    Prelucrarea obiectelor

    Obiecte care se modifică în diferite etape ale procesului de producție

    Obiecte procesate la etapa 1

    Obiecte modificate la prima etapă a procesului de producție

    Obiecte procesate în etapa 2

    Obiecte modificate la a 2-a etapă a procesului de producție

    Obiecte procesate în etapa 3

    Obiecte modificate în etapa a 3-a a procesului de producție

    Departamentul de control tehnic verifică obiectul creat pentru conformitatea cu cerințele standardului

    Divizii de companie și profesioniști

    Entități implicate în procesul de producție sau dezvoltare

    REGULI DE EXECUTARE

    Reguli pentru transformarea proceselor și a datelor

    Reguli contabile

    Un sistem de înregistrare și procesare a documentației care însoțește procesul de producție sau dezvoltare

    DECIZIE

    O decizie pozitivă sau negativă luată în funcție de dacă datele analizate îndeplinesc criteriile specificate

    Documente acceptate

    Documente care au fost înregistrate

    Software

    Platforma pe care baza de date în curs de dezvoltare este implementată

    Rezultatele analizei documentului

    Rezultate obținute în urma analizării documentelor primite și însoțitoare pentru conformitatea cu standardele

    Rezultate controlul calității

    rezultatele căutării

    Informații din tabelele bazei de date obținute din solicitările utilizatorilor

    Rezultatele testului

    Datele obținute în etapa finală a prelucrării

    Manualul utilizatorului

    Instrucțiuni și reguli pentru lucrul cu baza de date

    Serviciu de contabilitate

    Departamentele implicate în procesul de contabilitate și documentare

    Documente însoțitoare

    Documente care însoțesc obiectele de procesare primite

    Specialisti profesionisti

    Subiecții implicați în activități de producție

    Instructiuni tehnologice

    Secvența operațiilor proceselor tehnologice

    Cererile utilizatorilor

    Interogări create de utilizator pentru selecție informatie necesara din baza de date și pentru crearea documentelor de ieșire

    MECANISMUL DE EXECUTARE

    Resurse care transformă datele de intrare în date de ieșire

    Intrări noi

    Înregistrări în tabelele bazei de date care au apărut după introducerea datelor noi

    Corecţie

    Subiectul care efectuează examenul

    versiune tipărită

    IDEF0 este astăzi principalul standard pentru modelarea proceselor de afaceri. Este apelată descrierea unui sistem care utilizează IDEF0 model functional . Modelul descrie ce se întâmplă în sistem, cum este controlat, ce entități transformă, ce instrumente folosește pentru a-și îndeplini funcțiile și ce produce.

    La construirea unui model, trebuie precizat scopul modelării, răspunzând la următoarele întrebări:

    · de ce ar trebui modelat acest proces?

    Ce ar trebui să arate modelul?

    · ce poate obține cititorul?

    Exemple de definire a obiectivului: „identificați și definiți problemele curente, fac posibilă analiza potențialelor îmbunătățiri”, „identifică rolurile și responsabilitățile angajaților de a scrie descrierea postului„, „determină posibilitatea de automatizare...”, „reglementează procesul...”, etc.

    Punct de vedere este, de asemenea, unul dintre elementele cheie la construirea unui model. Un punct de vedere poate fi reprezentat ca punctul de vedere al unei persoane care vede sistemul în aspectul necesar modelării. Punctul de vedere trebuie să corespundă scopului modelării.

    Principiul conceptual principal al metodologiei IDEF este reprezentarea oricărui sistem studiat ca un set de blocuri interconectate și interconectate care afișează procesele, operațiunile și acțiunile care au loc în sistemul studiat. În IDEF0, tot ceea ce se întâmplă în sistem și elementele sale este de obicei numit funcții. Fiecare funcție este atribuită bloc.

    Blocurile funcționale din diagrame sunt reprezentate prin dreptunghiuri, reprezentând procese, funcții, locuri de muncă sau operațiuni numite care au loc într-o perioadă de timp și au rezultate recunoscute. În interiorul fiecărui bloc se află numele și numărul acestuia. Numele blocului trebuie să fie un verb activ, o expresie verbală sau un substantiv verbal care denotă o acțiune.

    Blocurile din IDEF0 sunt plasate în ordinea importanței, așa cum a înțeles autorul diagramei. Această ordine relativă se numește dominanță. Dominanța este înțeleasă ca influența pe care o are un bloc asupra altor blocuri din diagramă. Blocul cel mai dominant este de obicei plasat în colțul din stânga sus al diagramei, iar cel mai puțin dominant este în colțul din dreapta.

    Sunt reprezentate interfețele prin care un bloc interacționează cu alte blocuri sau cu un mediu extern sistemului care se modelează săgeți, intrarea sau ieșirea din bloc. Fiecare parte a unui bloc funcțional are o semnificație standard în ceea ce privește relația bloc/săgeată. Aranjamentul standard al săgeților este prezentat în Fig. 1.

    Orez. 1. Contextul IDEF0.

    Săgeți descrieți interacțiunea blocurilor cu lumea exterioară și între ele. Săgețile reprezintă unele informații și sunt numite substantive sau expresii ale unui substantiv.


    Există cinci tipuri de săgeți în IDEF0:

    1. Intrare - material sau informație care este folosită sau transformată de un bloc funcțional pentru a produce un rezultat (ieșire). Este permis ca lucrarea să nu aibă o singură săgeată de intrare.

    2. Guvernare - regulile, politicile, procedurile sau standardele care guvernează unitatea. Controlul afectează blocul, dar nu este transformat de acesta.

    3. Ieșire - material sau informație care este produsă de bloc. Un bloc fără rezultat este lipsit de sens și nu trebuie modelat.

    4. Mecanism - resurse care efectuează blocul, de exemplu, personalul întreprinderii, mașinile, dispozitivele etc. La discreția analistului, săgețile mecanismului pot să nu fie descrise în model.

    5. Apel - o săgeată specială care indică un alt model de lucru. O săgeată de apel este folosită pentru a indica faptul că unele lucrări sunt efectuate în afara sistemului care este modelat.

    Săgețile de pe diagrama de context sunt folosite pentru a descrie interacțiunea sistemului cu lumea exterioară. Săgeți de delimitare- săgeți care încep la marginea diagramei și se termină la lucru sau invers. Săgeți interioare conectați blocurile între ele. Există cinci tipuri de conexiuni de lucru.

    1. Comunicare prin intrare - săgeata de ieșire a blocului superior este îndreptată către intrarea celui de jos (Fig. 2).

    Orez. 2. Relația ieșire-intrare.

    2. Comunicare de control - ieșirea blocului de nivel superior este trimisă la controlul celui de nivel inferior (Fig. 3).

    Orez. 3. Relația ieșire-control.

    3. Feedback de control - ieșirea blocului de nivel inferior este trimisă la controlul celui de nivel superior (Fig. 4).

    Orez. 4. Control Feedback

    4. Feedback de intrare - ieșirea blocului de nivel inferior este trimisă la intrarea celui de nivel superior (Fig. 5).

    Orez. 5. Raportul de feedback de intrare

    5. Conexiune ieșire-mecanism - ieșirea unui bloc este direcționată către mecanismul altuia (Fig. 6).

    Orez. 6 Conexiune ieșire-mecanism.

    În notația IDEF0, descrierea (modelul) sistemului este organizată sub formă de diagrame ordonate ierarhic și interconectate. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii acestuia cu lumea exterioară (diagrama contextului). Diagrama de context include un singur bloc care caracterizează întregul set de procese modelate, fără detalii.

    Orez. 7 Exemplu de diagramă de context IDEF0.

    După care se efectuează o descompunere funcțională (Fig. 8) - acest bloc de activitate (proces mare) este împărțit în subprocese mari - și fiecare subproces este descris separat (diagrame de descompunere). Apoi fiecare subproces este descompus în altele mai mici - și așa mai departe până când se obține detaliul necesar al descrierii.

    Fig.8 Exemplu de diagramă de descompunere IDEF0.

    Cuvinte cheie: analiză structurală și proiectare, model funcțional, bloc funcțional, arc de interfață, diagramă de context, descompunere, glosar, scop, punct de vedere, identificare subproces, descompunere, limitarea complexității, tunel.

    Definiție

    IDEF0 (Integration Definition for Function Modeling) – o metodologie de modelare funcțională pentru descrierea funcțiilor întreprinderii, oferind un limbaj de modelare funcțional pentru analiza, dezvoltarea, reinginerirea și integrarea sistemelor informaționale ale proceselor de afaceri; sau analiza ingineriei software.

    Metodologia IDEF0 este o dezvoltare a metodei de analiză structurală și proiectare SADT (Structured Analysis and Design Technique).

    IDEF0 ca standard a fost dezvoltat în 1981 ca parte a programului ICAM (Integrated Computer Aided Manufacturing).

    IDEF0 – Integrare Definiție limba 0 – se bazează pe SADT și în forma sa originală include simultan: o definiție a unui limbaj de modelare grafică (sintaxă și semantică) și o descriere a unei metodologii cuprinzătoare de dezvoltare a modelului.

    Cea mai recentă revizuire a IDEF0 a fost lansată în decembrie 1993 de către Institutul Național de Standarde și Tehnologie din SUA (NIST).

    IDEF0 a fost adoptat ca standard federal în Statele Unite în 1993 și ca standard în Federația Rusă în 2000.

    Aplicarea IDEF0

    IDEF0 este folosit pentru a crea model functional, adică rezultatul aplicării metodologiei IDEF0 la sistem este modelul funcțional IDEF0.

    Model functional este o reprezentare structurală a funcțiilor, activităților sau proceselor din cadrul sistemului sau domeniului modelat.

    Metodologia IDEF0 poate fi utilizată pentru a modela o gamă largă de sisteme atât automate, cât și manuale.

    Pentru sistemele în curs de proiectare, IDEF0 poate fi utilizat pentru a defini mai întâi cerințele și funcțiile și apoi pentru a crea o implementare care să satisfacă acele cerințe și să îndeplinească acele funcții.

    Pentru sistemele existente, IDEF0 poate fi utilizat pentru a analiza funcțiile îndeplinite de sistem, precum și pentru a ține seama de mecanismele prin care sunt îndeplinite acele funcții.

    Obiectivele standardului IDEF0

    Obiectivele (obiectivele) principale ale standardului:

      documentați și explicați tehnica de modelare IDEF0 și modul de utilizare a acesteia;

      să ofere un mijloc de modelare completă și consecventă a funcțiilor unui sistem sau unui domeniu, precum și a datelor și obiectelor care conectează aceste funcții;

      furnizarea unui limbaj de modelare care este independent de metodele sau instrumentele CASE, dar care poate fi utilizat folosind acele metode și instrumente;

      furnizați un limbaj de modelare care are următoarele caracteristici:

      general(generic) – pentru analiza sistemelor și domeniilor;

      stricte si precise(riguros și precis) – pentru a crea modele corecte, utilizabile);

      scurt(concis) – pentru a facilita înțelegerea, comunicarea, acordul între părțile interesate și verificarea. (pentru a facilita înțelegerea, comunicarea, consensul și validarea);

      abstract(conceptual) – pentru a reprezenta cerințe funcționale independente de implementările fizice sau organizaționale;

      flexibil– pentru a susține diferite faze ciclu de viață proiect.

    Rigurozitate și precizie(Rigor și precizie)

    Regulile IDEFØ necesită suficientă rigoare și precizie pentru a satisface nevoile fără a constrânge excesiv analistul. Regulile IDEFØ includ următoarele:

      controlul detaliilor comunicate la fiecare nivel – de la trei până la șase blocuri funcționale la fiecare nivel de descompunere;

      Context delimitat – nu ar trebui să existe detalii lipsă sau inutile care să depășească cadrul stabilit;

      Conectivitate interfață diagramă – număr de noduri, blocuri funcționale, numere C și expresie de referință de detaliu);

      coerența structurii datelor. (Data Structure Connectivity) – coduri ICOM și utilizarea parantezelor;

      Etichete și titluri unice – fără nume duplicate;

      reguli de sintaxă pentru grafică (Syntax Rules for Graphics) – blocuri funcționale și săgeți;

      restrictions on data arrow branchs (Data Arrow Branch Constraint) – etichete pentru restricții privind fluxurile de date pe ramuri;

      separarea datelor în Input versus Control Separation – o regulă pentru determinarea rolului datelor);

      marcaje cu săgeți de date. Cerințe pentru eticheta săgeată de date (reguli minime de etichetare);

      prezența controlului (control minim al funcției) – toate funcțiile trebuie să aibă cel puțin un control;

      Scop și punct de vedere – toate modelele au o declarație de scop și punct de vedere.

    IDEF0 Concepte de bază

    Metodologia se bazează pe patru concepte principale:

      bloc funcțional;

      arc de interfață;

      descompunere;

      glosar.

    Bloc funcțional(Activity Box) reprezintă o anumită funcție specifică în cadrul sistemului în cauză.

    Conform cerințelor standardului, trebuie formulată denumirea fiecărui bloc funcțional în starea verbală (de exemplu, „produce servicii”).

    În diagramă, un bloc funcțional este reprezentat ca un dreptunghi (Fig.). Fiecare dintre cele patru laturi ale blocului funcțional are propriul său sens specific (rol) și:

      partea de sus este setată la „Control”;

      partea stângă este setată la „Intrare”;

      partea dreaptă este setată la „Ieșire”;

      partea de jos are semnificația „Mecanism”.

    Orez. Bloc funcțional

    Arc/săgeată de interfață(Săgeată) afișează un element de sistem care este procesat de un bloc funcțional sau afectează în alt mod funcția reprezentată de acel bloc funcțional. Arcurile de interfață sunt adesea numite fluxuri sau săgeți.

    Cu ajutorul arcelor de interfață sunt afișate diverse obiecte care, într-o măsură sau alta, determină procesele care au loc în sistem. Astfel de obiecte pot fi elemente ale lumii reale (piese, mașini, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).

    În funcție de ce parte a blocului funcțional se potrivește acest arc de interfață, se numește „incoming”, „outgoing” sau „controlling”.

    Trebuie remarcat faptul că orice bloc funcțional, conform cerințelor standardului, trebuie să aibă cel puțin un arc de interfață de control și unul de ieșire. Acest lucru este de înțeles - fiecare proces trebuie să aibă loc conform unor reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel luarea în considerare a acestuia nu are sens.

    Prezența obligatorie a arcurilor de interfață de control este una dintre principalele diferențe între standardul IDEF0 și alte metodologii ale claselor DFD (Diagrama fluxului de date) și WFD (Diagrama fluxului de lucru).

    Descompunere(Descompunerea) este un concept de bază al standardului IDEF0. Principiul descompunerii este utilizat atunci când un proces complex este împărțit în funcțiile sale componente. În acest caz, nivelul de detaliu al procesului este determinat direct de dezvoltatorul modelului.

    Descompunerea vă permite să prezentați treptat și structurat modelul de sistem sub forma unei structuri ierarhice de diagrame individuale, ceea ce îl face mai puțin supraîncărcat și mai ușor de digerat.

    Ultimul dintre conceptele IDEF0 este glosar(Glosar).

    Pentru fiecare dintre elementele IDEF0 - diagrame, blocuri funcționale, arcuri de interfață - standardul existent necesită crearea și menținerea unui set de definiții corespunzătoare, cuvinte cheie, enunțuri narative etc., care caracterizează obiectul afișat de acest element.

    Acest set se numește glosarși este o descriere a esenței acestui element. Glosarul completează armonios limbajul grafic vizual, oferind diagramelor informațiile suplimentare necesare.

    Modelare. Modelul IDEF0 începe întotdeauna cu o vedere a sistemului ca un întreg – o unitate funcțională cu arcuri de interfață care se extind dincolo de domeniul luat în considerare. Se numește o astfel de diagramă cu un singur bloc funcțional diagrama de context.

    Textul explicativ pentru diagrama de context trebuie să indice ţintă(Scopul) de a construi o diagramă sub forma unei scurte descriere și înregistrată Punct de vedere(Punct de vedere).

    Definiție și formalizare obiective dezvoltarea modelului IDEF0 este un punct extrem de important. De fapt, obiectivul definește zonele relevante din sistemul studiat pe care trebuie să se concentreze mai întâi.

    Punct de vedere determină direcția principală de dezvoltare a modelului și nivelul de detaliu necesar. O fixare clară a punctului de vedere vă permite să descărcați modelul refuzând detalierea și studierea elementelor individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului.

    Majoritatea celor implicați în implementarea proiectelor legate de crearea sau dezvoltarea sistemelor informaționale corporative sunt de acord cu teza conform căreia clientul are nevoie de un sistem informațional care să crească eficiența întreprinderii. Cu toate acestea, clienții și dezvoltatorii de sisteme informatice încă vorbesc limbi diferite: Au înțelegeri diferite despre ceea ce înseamnă creșterea eficienței unei întreprinderi.

    Dezvoltatorii de sisteme informatice înțeleg foarte adesea eficiența crescută ca o creștere a numărului de stații de lucru în rețeaua de calculatoare locale (LAN) a unei întreprinderi, o creștere lățime de bandă LAN, o creștere a numărului de documente, a căror prelucrare se realizează la stații de lucru automate (AWS) etc.

    Prin creșterea eficienței unei întreprinderi, clienții înțeleg o creștere a productivității muncii, o reducere a costurilor și o creștere a calității produselor și serviciilor produse. Recent, noi condiții și concepte noi pătrund rapid în viața clienților: strategie de dezvoltare, competențe de bază, arhitectură de afaceri, reguli de afaceri și multe altele.

    Pentru ca clientul și dezvoltatorul sistemului informatic să se înțeleagă unul pe celălalt, este necesar ca dezvoltatorul să se reorienteze de la rezolvarea problemelor tehnice de creare sau dezvoltare a unui sistem informatic până la rezolvarea problemelor complexe de creștere a eficienței întreprinderii clientului. Cu această abordare, problema iese în prim-plan mod eficient studierea domeniului de activitate al clientului:

    • studiul arhitecturii de afaceri existente, proceselor de afaceri, regulilor de afaceri, fluxurilor de informații;
    • identificarea problemelor, blocajelor care afectează negativ eficiența întreprinderii;
    • dezvoltarea și implementarea măsurilor pentru eliminarea problemelor existente și schimbarea arhitecturii de afaceri a întreprinderii, restructurarea proceselor de afaceri;
    • dezvoltarea unui proiect specific pentru un sistem informatic corporativ, implementarea acestui proiect si suport pe viitor.

    Ca parte a acestei abordări, instrumentele concepute pentru modelarea întreprinderii și reproiectarea proceselor de afaceri sunt concepute pentru a crește eficiența dezvoltatorului de sisteme informatice. Unul dintre reprezentanții acestei familii de instrumente este instrumentele CASE pentru modelarea funcțională a proceselor de afaceri.

    Acest articol oferă o prezentare generală a unei clase de instrumente pentru modelarea funcțională a proceselor de afaceri, axată pe utilizarea metodologiei IDEF0.

    IDEF0 - metodologia de modelare funcțională

    În timpul implementării programului Integrated Computerization of Manufacturing (ICAM), propus la un moment dat de către Forțele Aeriene pentru industria aerospațială din SUA, a fost identificată necesitatea dezvoltării unor metode de analiză a interacțiunii proceselor din sistemele de producție. Pentru a răspunde acestei necesități, a fost dezvoltată metodologia IDEF0 (Modelarea funcției de definiție integrată), care este acum adoptată ca standard federal din SUA. Metodologia a fost aplicată cu succes într-o varietate de industrii, demonstrându-se ca remediu eficient analiza, proiectarea si prezentarea proceselor de afaceri. În prezent, metodologia IDEF0 este utilizată pe scară largă nu numai în Statele Unite, ci în întreaga lume. În Rusia, IDEF0 a fost utilizat cu succes în agențiile guvernamentale (de exemplu, în Inspectoratul Fiscal de Stat), în industria aerospațială (la proiectarea cosmodromului Plesetsk), în Banca Centrală și băncile comerciale din Rusia, în industria petrolului și gazelor. și în alte industrii.

    IDEF0 Concepte de bază

    Metodologia IDEF0 se bazează pe conceptul de bloc care reprezintă o anumită funcție de business. Cele patru laturi ale blocului au roluri diferite: partea stângă are sensul de „intrare”, partea dreaptă are sensul de „ieșire”, partea de sus are sensul de „control”, iar partea de jos are sensul de „ mecanism” (vezi Fig. 1).

    Interacțiunea dintre funcțiile din IDEF0 este reprezentată ca un arc, care afișează fluxul de date sau materiale care provin de la ieșirea unei funcții la intrarea alteia. În funcție de ce parte a blocului este conectat firul, acesta se numește „intrare”, „ieșire”, respectiv „control”.

    IDEF0 Principii de modelare

    IDEF0 implementează trei principii de bază de modelare a proceselor:

    • principiul descompunerii funcționale;
    • principiul limitării complexității;
    • principiul contextului.

    Principiul descompunerii funcționale este o modalitate de modelare a unei situații tipice în care orice acțiune, operație, funcție poate fi descompusă (descompusă) în mai multe pași simpli, operații, funcții. Cu alte cuvinte, o funcție complexă de afaceri poate fi reprezentată ca o colecție de funcții elementare. Prezentând funcțiile grafic, sub formă de blocuri, puteți privi în interiorul blocului și puteți examina în detaliu structura și compoziția acestuia (vezi Fig. 2).

    Principiul limitării complexității. Când lucrați cu diagrame IDEF0, este esențial ca acestea să fie lizibile și lizibile. Esența principiului limitării complexității este că numărul de blocuri din diagramă nu trebuie să fie mai mic de două și nu mai mult de șase. Practica arată că respectarea acestui principiu duce la faptul că procesele funcționale prezentate sub forma unui model IDEF0 sunt bine structurate, de înțeles și ușor de analizat.

    Principiul unei diagrame de context. Modelarea unui proces de afaceri începe cu construirea unei diagrame de context. Această diagramă arată un singur bloc - principala funcție de afaceri a sistemului modelat. Dacă vorbim despre modelarea unei întregi întreprinderi sau chiar a unei mari divizii, funcția principală de afaceri nu poate fi formulată ca, de exemplu, „vânzarea produselor”. Funcția principală de afaceri a sistemului este „misiunea” sistemului, semnificația sa în lumea exterioară. Nu pot formula corect functie principalaîntreprindere fără nicio idee despre strategia sa.

    Atunci când definiți funcția principală de business, trebuie să aveți întotdeauna în vedere scopul modelării și punctul de vedere al modelului. Aceeași întreprindere poate fi descrisă diferit, în funcție de punctul de vedere din care este privită: directorul întreprinderii și inspectorul fiscal văd organizația cu totul diferit.

    Diagrama de context joacă un alt rol în modelul funcțional. Ea „fixează” limitele sistemului de afaceri modelat prin definirea modului în care sistemul modelat interacționează cu mediul său. Acest lucru se realizează prin descrierea arcurilor conectate la un bloc reprezentând funcția principală de afaceri.

    Aplicarea IDEF0

    După ce te-ai familiarizat cu Noțiuni de bazăși principiile modelării funcționale a proceselor de afaceri, întrebarea firească este: cum ajută acest lucru la îmbunătățirea eficienței și calității întreprinderii.

    Construirea modelului CA ESTE. Un sondaj de întreprindere este o parte obligatorie a oricărui proiect pentru crearea sau dezvoltarea unui sistem informațional corporativ. Construirea unui model funcțional AS IS vă permite să înregistrați clar ce procese de afaceri sunt efectuate la întreprindere, ce obiecte informaţionale utilizat la efectuarea proceselor de afaceri și a operațiunilor individuale. Modelul funcțional AS IS este punctul de plecare pentru analiza nevoilor întreprinderii, identificarea problemelor și blocajelor și dezvoltarea unui proiect de îmbunătățire a proceselor de afaceri.

    Reguli de afaceri. Un model de proces de afaceri vă permite să identificați și să definiți cu precizie regulile de afaceri utilizate în activitățile unei întreprinderi.

    În fig. Figura 3 prezintă un fragment dintr-un model funcțional al fluxului de documente. La efectuarea operațiunii „sortare documente” se folosește regula de afaceri: „nu sunt supuse înregistrării: documentele transmise în copie pentru informare, telegrame și scrisori de autorizație pentru călătorii de afaceri și vacanțe...”. Această regulă este înregistrată în instrucțiunile de flux de documente. Modelul funcțional permite nu numai identificarea existenței acestei reguli, ci și determinarea în timpul cărei operațiuni și la ce loc de muncă ar trebui aplicată.

    În cadrul modelului funcțional, regula de afaceri este următoarea: „dacă la recepție se primește un document destinat gestiunii, acesta este supus sortării, în urma căreia, pe baza instrucțiunilor, se stabilește dacă documentul este supus înregistrării sau nu.”

    Dacă această regulă de afaceri nu este luată în considerare la dezvoltarea unui sistem informațional, atunci un astfel de sistem va funcționa inadecvat.

    Foarte des, regulile de afaceri la o întreprindere nu sunt scrise în instrucțiuni: par să existe, dar par să lipsească. Ca urmare, încercările de a schimba ceva în activitățile unei întreprinderi sau departament pot eșua doar pentru că aceste modificări contrazic regulile de afaceri stabilite.

    Obiecte informaționale. Modelul funcțional vă permite să identificați toate obiectele informaționale pe care întreprinderea le operează în activitățile sale. Spre deosebire de modelele de informații (Diagrame de flux de date, IDEF1X), modelul funcțional IDEF0 reflectă exact modul în care obiectele informaționale sunt utilizate în procesele de afaceri.

    Construirea unui model despre CUM VA FI. Crearea și implementarea unui sistem informațional corporativ duce la modificări ale condițiilor de efectuare a operațiunilor individuale, ale structurii proceselor de afaceri și ale întreprinderii în ansamblu. Acest lucru duce la necesitatea de a schimba sistemul de reguli de afaceri utilizate în întreprindere și de a modifica fișele posturilor angajaților. Modelul funcțional AS WILL BE ne permite să determinăm aceste modificări deja în faza de proiectare a viitorului sistem informațional. Utilizarea modelului funcțional CUM SĂ FI permite nu numai reducerea timpului de implementare a sistemului informațional, ci și reducerea riscurilor asociate cu insensibilitatea personalului la tehnologia informației.

    Alocare resurselor. Modelul funcțional vă permite să definiți clar distribuția resurselor între operațiunile procesului de afaceri, ceea ce face posibilă evaluarea eficienței utilizării resurselor.

    Această sarcină este deosebit de relevantă atunci când se creează noi procese de afaceri într-o întreprindere. De exemplu, o companie specializată în dezvoltarea personalizării software, a decis să-și creeze propriul serviciu de vânzări. Un model funcțional al procesului de afaceri pentru vânzarea de software va permite conducerii companiei să determine clar ce resurse trebuie alocate pentru a asigura funcționarea serviciului de vânzări, câți angajați trebuie recrutați pentru a lucra în noul serviciu, ce responsabilități funcționale pe care trebuie să le îndeplinească acești angajați etc.

    Sisteme software IDEF0

    În prezent, există multe instrumente CASE care sprijină modelarea funcțională în standardul IDEF0.

    CONCLUZIE

    Metodologia de modelare funcțională IDEF0 este un instrument destul de simplu care permite dezvoltatorilor de sisteme informaționale corporative să studieze domeniul de activitate al clientului și să rezolve probleme pentru a îmbunătăți eficiența acestei activități.

    Utilizarea modelării funcționale face posibilă rezolvarea nu numai probleme tehnice client legat de tehnologia de informație, dar și probleme legate de domeniul de activitate al clientului. Acest lucru vă permite să transformați un proiect de sistem informatic dintr-un „teanc de hârtie”, pentru care clientul nu dorește să plătească, într-un serviciu care îi poate aduce clientului un efect suplimentar comparabil cu automatizarea ulterioară.