Diagramele IDEF0 sunt construite folosind programul BPWin. Acestea sunt destinate modelării grafice a proceselor de afaceri în curs.

Despre metodologia IDEF0

Metodologia IDEF0 este utilizată pe scară largă datorită notației sale grafice simple și ușor de înțeles, care este foarte convenabilă pentru construirea unui model. Locul principal în metodologie este dat diagramelor. Diagramele prezintă funcțiile sistemului prin intermediul dreptunghiurilor geometrice, precum și conexiunile existente între funcții și mediul extern. Legăturile sunt afișate cu ajutorul săgeților. Puteți verifica acest lucru văzând ce oferă diagrama IDEF0, exemple din care puteți găsi în acest articol.

Faptul că doar două primitive grafice sunt utilizate în modelare vă permite să explicați rapid regulile actuale ale interacțiunilor IDEF0 acelor persoane care habar nu au despre asta. Cu diagramele IDEF0, conectarea clientului la procesele în curs se realizează mai rapid datorită utilizarea unui limbaj grafic vizual. Puteți vedea ce oferă diagrama IDEF0, exemple dintre care sunt prezentate mai jos.

Elemente utilizate pentru IDEF0

După cum am menționat deja, sunt utilizate 2 tipuri de primitive geometrice: dreptunghiuri și săgeți. Dreptunghiurile reprezintă anumite procese, funcții, lucrări sau sarcini care au scopuri și conduc la rezultatul indicat. Interacțiunea proceselor între ele și mediul extern este indicată prin săgeți. IDEF0 distinge 5 tipuri diferite de săgeți.

Posibilități de utilizare a IDEF0

Metodologia IDEF0 poate fi aplicată pentru a descrie aspectul funcțional al oricărui sistem informațional.

Tipuri de legături între procesele IDEF0

Este în interesul modelului să creeze astfel de conexiuni ale construcțiilor, astfel încât conexiunile interne să fie cât mai puternice, iar cele externe - cât mai slabe. Acesta este punctul forte al modelării cu IDEF0. Puteți vedea exemple de diagrame pentru dvs. și vă puteți convinge de veridicitatea acestor cuvinte. Pentru a facilita stabilirea conexiunilor, acestea sunt conectate în module. Legăturile externe sunt stabilite între module, iar legăturile interne sunt stabilite în interiorul modulelor. Există mai multe tipuri de legături.

1. Legătura ierarhică („parte” - „întreg”).

2. Manager (de reglementare, subordonat):

2) controlul feedback-ului.

3. Funcționale sau tehnologice:

2) intrare inversă.

3) consumator;

4) logic;

5) metodic sau colegial;

6) resursă;

7) informativ;

8) temporar;

9) aleatoriu.

Blocuri de construcție și legături în diagrame

Metodologia IDEF0 oferă o serie de reguli și linii directoare pentru utilizarea sa și îmbunătățirea calității utilizării. Deci, diagrama afișează un bloc pe care puteți specifica numele sistemului, scopul acestuia. 2-5 săgeți duc la bloc sau dinspre bloc. Mai mult sau mai puțin, dar sunt necesare cel puțin două săgeți pentru intrare/ieșire, iar restul pentru lucrări suplimentare și indicarea lor pe diagramă. Dacă săgețile sunt mai mari de 5, ar trebui să vă gândiți la optimitatea construirii modelului și dacă este posibil să îl faceți și mai detaliat.

Blocuri de construcție în diagramele de descompunere

Numărul de blocuri care vor fi pe o diagramă este recomandat în număr de 3-6. Dacă sunt mai puține dintre ele, atunci este puțin probabil ca astfel de diagrame să aibă o sarcină semantică. Dacă numărul de blocuri este mare, atunci va fi foarte dificil să citiți o astfel de diagramă, având în vedere prezența unor săgeți suplimentare. Pentru a îmbunătăți percepția informațiilor, se recomandă plasarea blocurilor de sus în jos și de la stânga la dreapta. Acest aranjament va reflecta logica executării secvenței de procese. Și, de asemenea, săgețile vor crea mai puțină confuzie, având un număr minim de intersecții între ele.

Dacă lansarea unei anumite funcții nu este controlată în niciun fel, iar procesul poate fi pornit într-un moment arbitrar, atunci o astfel de situație este indicată de absența săgeților care indică controlul și intrarea. Dar prezența unei astfel de situații le poate spune potențialilor parteneri despre o anumită instabilitate și necesitatea de a arunca o privire mai atentă asupra potențialului partener.

Un bloc care are doar o săgeată de intrare indică faptul că procesul primește parametrii de intrare, dar nu are loc niciun control sau reglare în timpul rulării. Un bloc care are doar o săgeată de control este folosit pentru a indica joburile care sunt apelate numai prin ordine specială a sistemului de control. Ele sunt controlate și ajustate în toate etapele lor.

Dar un exemplu de construire a unei diagrame IDEF0 vă poate convinge că cel mai complet și cuprinzător tip este diagrama cu săgeți de intrare și control.

Denumire

Pentru a îmbunătăți experiența vizuală, fiecare bloc și fiecare săgeată ar trebui să aibă propriul nume, care vă va permite să le identificați printre multe alte blocuri și săgeți. Așa arată diagramele exemplu în IDEF0. Sistemul informatic construit cu ajutorul acestora va face posibilă înțelegerea tuturor deficiențelor și complexităților modelelor.

Fuziunea cu săgeți este adesea folosită și apar întrebări cu privire la denumirea lor. Dar fuzionarea este posibilă numai în cazul transferului de date omogene, prin urmare nu sunt necesare nume separate, deși pot fi specificate în BPWin. De asemenea, dacă există o divergență a săgeților, atunci acestea pot fi denumite separat pentru a înțelege ce este responsabil pentru ce.

Dacă nu există niciun nume după ramură, atunci numele este considerat a fi exact așa cum era înainte de ramură. Acesta poate fi cazul dacă două blocuri necesită aceleași informații. Diagrama de context IDEF0, al cărei exemplu poate fi găsit în acest articol, va confirma aceste cuvinte.

Informații cu săgeți

Săgețile care intră și ies din același bloc la construirea unei diagrame de compoziție ar trebui să fie afișate pe acesta. Numele formelor geometrice transferate în diagramă trebuie să repete exact informațiile de cel mai înalt nivel. Dacă două săgeți sunt paralele în raport cu arcurile celeilalte (adică, încep pe marginea unui proces și se termină pe ambele pe o margine a celuilalt proces), atunci poate că ar trebui combinate pentru a optimiza modelul și pentru a alege un nume potrivit, care este perfect afișat în IDEF0 (pot fi vizualizate exemple de diagrame în Visio).

Un exemplu de implementare a metodologiei IDEF0 pe un model specific

Ați învățat deja ce este o diagramă IDEF0, ați văzut parțial exemple și reguli pentru construirea unor astfel de diagrame. Acum ar trebui să trecem la practică. Pentru o mai bună înțelegere, explicația nu se va baza pe un model „general”, ci pe un exemplu specific care vă va permite să înțelegeți mai bine și mai pe deplin caracteristicile lucrului cu IDEF0 în programul BPWin.

Un exemplu este viteza trenului de la punctul A la punctul B. Trebuie avut în vedere faptul că trenul nu poate dezvolta mai mult decât viteza admisă. Această linie este stabilită pe baza experienței de exploatare și a influenței trenurilor pe linie. Trebuie înțeles că scopul trenului este de a livra pasageri, care, la rândul lor, au plătit pentru a ajunge în siguranță și confortabil la destinație. O diagramă IDEF0 este utilă, exemple din care pot fi găsite în acest articol.

Informația inițială este:

1. date ale liniilor de urmărire;
2. pașaportul pe toată distanța;
3. planul de traseu.

Date de control:

1. Direcția șefului, șef serviciu de cale.
2. Informații despre fluxul existent de circulație a trenurilor.
3. Informații despre reparațiile planificate, reconstrucția și schimbarea căilor.

Rezultatul modelului este:

1. Limitarea vitezelor admise cu indicarea motivului limitării.
2. Vitezele admise la conducerea în puncte separate și în timpul transportului trenurilor.

Când este construită diagrama de context, aceasta trebuie detaliată și apoi este creată diagrama compozită, care va fi diagrama de prim nivel. Acesta va afișa toate funcțiile principale ale sistemului. Metodologia și diagrama IDEF0 pentru care se face descompunerea se numesc părinte. Descompunerea IDEF0 se numește descompunere copil.

Concluzie

După descompunerea la primul nivel, se realizează descompunerea celui de-al doilea nivel - și așa mai departe până când descompunerea ulterioară își pierde sensul. Toate acestea sunt realizate pentru a obține cea mai detaliată diagramă grafică a proceselor în curs și planificate. Acesta este un exemplu gata făcut de diagramă IDEF0 prin care puteți naviga chiar acum.

1. Modelarea funcțională a unui sistem informațional folosind tehnologia CASE IDEF.
2. Descrierea logicii interacțiunii și a secvenței 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 CASE BPwin 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. Implementarea acestei etape 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 doua opțiuni, crearea unui scenariu și a unei diagrame de succesiune a execuției lucrărilor individuale (Diagrama fluxului de lucru) în procesul de contabilizare a activităților se realizează folosind metodologia IDEF 3.
3. Elaborarea unui dicționar de lucrări și a unui dicționar de săgeți care permit afișarea descrierii 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 de modelare IDEF sunt descrise în secțiunea 4 „Informații teoretice pentru o lecție practică”.
2. La elaborarea unei diagrame de context, trebuie avut în vedere faptul că proprietățile modelului pot fi formalizate după cum urmează, folosind informații corespunzătoare domeniului simulat:
   • Numele modelului : Activitati ale societatii "Nume";
   • Proiect (numele proiectului): Modelul companiei „Nume”;
   • Nume, grup;
   • Domeniul de aplicare (sfera de aplicare a modelării, inclusiv scopul modelării, adică întrebări la care modelul construit ar trebui să răspundă) - de exemplu, „Gestionarea generală a afacerii firmei: cercetare de piață, achiziție de componente, testare și vânzare de produse” sau „Aspecte tehnologice, financiare și de management ale companiei”;
   • Interval de timp (tip de model) : Așa cum este;
   • Definiție , atribuirea modelului) : Un model de instruire care descrie activitățile companiei „Nume”;
   • Punct de vedere (Punct de vedere – persoana al cărei punct de vedere a fost adoptat în timpul dezvoltării) : sef intreprindere si director general;
   • stare : FUNCTIONARE;
   • Scop : Să modeleze procesele curente de afaceri ale companiei „Nume” în vederea reglementării activităților acesteia;
   • Sursă (o 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, este subproces sau munca copilului , implementat ca lucrare contextuală, care în acest caz acționează ca munca parentală implementat ca Diagrama parentală) ... Diagrama de descompunere de nivel al doilea trebuie să conțină cel puțin trei blocuri funcționale, dintre care unul trebuie să îndeplinească funcția de modelare contabilizarea activitatilor organizațiile, iar restul ar trebui să îndeplinească funcția de modelare procesele de afaceri implementate în sistem.
4. La fiecare pas al descompunerii, 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 copiilor, implementat ca Diagrama copilului lucrare corespunzătoare de al treilea nivel. Toate lucrările de al doilea nivel în acest caz acționează ca munca parentală implementat ca diagrame părinte(Diagrame parentale).
6. Descompunerea lucrării de al doilea nivel, care simulează funcția contabilă, și crearea unui scenariu pentru interacțiunea lucrărilor ar trebui să fie efectuate folosind tehnologia IDEF 3, care foloseşte ca blocuri funcţionale unitatimuncă (Unitatea de lucru, UOW) precum si cele necesare obiecte de referință (referenți) , care poate fi fie introdus în script din dicționarul cu săgeți, fie creat din nou.
7. Dicționarul de lucrări și dicționarul de săgeți sunt create la fiecare nivel al descompunerii modelului, iar o condiție prealabilă pentru dezvoltarea lor este prezența unei fișe de post. (activitate)și descrieri ale datelor capturate pe arcul de interfață ( săgeată) .
8. Salvați rezultatele î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 pentru a descrie procesele de afaceri și procesele tehnologice existente la întreprindere, conform principiului „AS - AS” („Așa cum este”) și, important, reprezintă întreprinderea din perspectiva angajaților care lucrează la ea și cunosc în detaliu toate nuanțele, inclusiv cele informale. AS-IS - „ce facem astăzi” înainte de a sări la „ce vom face mâine”.

Model de activitate sau, cu alte cuvinte, model functional. Model functional vede sistemul ca pe un set actiuni, in care fiecare acţiune transformă 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 uzual vedere model la privat modele. Prin urmare, de obicei, un model funcțional pentru rezolvarea unei probleme este un set de modele funcționale private .

Modelele funcționale disting acțiunile reprezentându-le ca un element special - bloc. bloc – principalul element structural al modelului funcțional, a cărui reprezentare grafică 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 functional... Este menit să reprezinte un anumit tip Activitate , care reprezintă unele specifice funcţie în cadrul sistemului considerat. Această funcție, la rândul său, înseamnă o acțiune (un set de acțiuni), având un scop fix și conducând la un rezultat final.

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

• Partea superioară este controlul.
• Partea inferioară este mecanismul.
• Partea dreaptă este ieșirea.
• Partea stângă este intrarea.

Un bloc funcțional are un nume care este dat într-o dispoziție verbală sau un substantiv verbal. Interacțiunea dintre acțiuni iar lumea din jur, inclusiv cu 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 fie prelucrate bloc funcțional, sau are un efect diferit la activitatea (funcția) mapată de acest bloc funcțional. Arc de interfață este descris ca o săgeată care denotă purtător care asigură 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 indică acest lucru rol (se notează setul de roluri posibile - ICOM ):

Intrare bloc funcțional - eu nput .

management - C control .

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

Mecanism - M mecanism .

Intrare (Intrare) Este material sau informație care este folosită sau transformată de lucrare pentru a obține un rezultat (ieșire). Este posibil ca săgeata de intrare să nu fie prezentă.

Control- regulile, strategiile, procedurile sau standardele care guvernează munca. Afectează munca, dar nu este transformată de muncă. Săgeata este desenată ca intrând în partea 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 se modifică sau sunt procesate, atunci aceasta este cel mai probabil o intrare, iar dacă nu, este un 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 vine din partea dreaptă a lucrării.

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 pentru mecanism 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 soluționarea sa. Este posibil ca arcul de interfață „Mecanism” să nu fie afișat.

Pentru a construi sunt folosite mai multe blocuri funcționale conectate prin arcuri de interfață în modul necesar model functional.

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

La intrare bloc funcțional poate fi nu numai Ieșire altă unitate funcțională, dar și ea 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 în tehnologia IDEF0

Atunci când se dezvoltă un model de afaceri pentru o organizație, trebuie utilizate trei tipuri de diagrame:

• I tip de diagramă - Diagrama context (poate fi doar unul) - partea de sus a structurii arborelui, care este cel mai abstract nivel de descriere a sistemului și a interacțiunii acestuia cu mediul extern. Ea definește funcția de context;
• II tipul diagramei - Diagrama de descompunere .

Diagramele de descompunere sunt destinate detalierii lucrărilor și conțin legate de munca, adica filiale munca avand un comun părintească muncă. Locuri de muncă de nivel scăzut sunt la fel cu locurile de muncă de nivel înalt, dar mai detaliat. Diagramele sunt create de analist pentru a conduce o sesiune de examinare, adică pentru a discuta diagrama cu un specialist în materie.

După fiecare sesiune de descompunere, au loc sesiuni de examinare - experții în domeniu indică corespondența proceselor reale de afaceri cu diagramele create. Discrepanțele găsite sunt corectate și numai după promovarea examenului fara comentarii puteți trece la următoarea sesiune de descompunere. Acesta este modul în care modelul se potrivește cu procesele reale de afaceri la orice nivel al modelului.

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

În diagrama de descompunere, în stânga sus este lucrarea care este cea mai importantă și efectuată prima. Munca care este mai puțin importantă sau efectuată ulterior scade.

• III tip de diagramă - Diagrama arborescentă a nodurilor arată dependența ierarhică a activităților, dar nu și relația dintre activități (pot exista orice număr de aceste diagrame, 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 CASE BPWin are o interfață de utilizator simplă și directă pentru construirea modelelor și scenariilor funcționale necesare. Depinde de tehnologia folosită. În fig. 2.2 arată fereastra BPWin ( Computer Associates BPWin ).

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

	- crearea unui nou model,
	- deschiderea unui model existent,
	- salvarea modelului construit,
	- imprimare model,
	- alegerea scalei,
	- scalare,
	- verificator ortografic,
	- pornirea/dezactivarea navigatorului modelului,
	- activați / dezactivați Model Mart.

Navigatorul de modele arată compoziția modelului în funcție de nivelul de dezvoltare. Cu el, 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 un loc pentru crearea unui model funcțional al sistemului studiat. Blocurile funcționale sunt construite și editate în el, săgețile sunt desenate și editate și se realizează descompunerea.

Pregătirea modelului

1. Apăsați butonul de creare a modelului pentru a deschide caseta de dialog BPWin(fig. 2.3):

În caseta de dialog BPWin efectuați următoarele acțiuni:

• Selectați Proces de afaceri (IDEF0);
• setați numele modelului și faceți clic pe butonul O.K;
• La fereastră Proprietăți pentru modelul nou fixați numele autorului modelului;
• apasa butonul O.K .

1. Echipă Model / Proprietăți model afișează o casetă de dialog Proprietățile modelului (Fig. 4), în care proprietățile modelului sunt formalizate în conformitate cu recomandările metodologice prezentate în Secțiunea 2.

Primul nivel de modelare

1. Proiectați un bloc funcțional în fereastra modelului făcând următoarele:
   • în meniul contextual al blocului funcțional, selectați comanda Nume… ;
   • în caseta de dialog Proprietățile activității (fig. 2.5) în tab Nume cere 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 care permit 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 O.K.

• în caseta de dialog Proprietăți săgeți (fig. 2.7), în fila Nume setați numele săgeții (scurt) și în marcaj Definițieîn câmp Definiție scrie suficient de detaliat Descriere scopul acestei săgeți;

• selectați comanda din meniul contextual al săgeții Font… ;
• în caseta de dialog Proprietăți săgeți (fig. 2.8), în fila 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 Modificați toate aparițiile acestui font în model );

1. Design săgeată Ieșire, stânga limite dreapta;
2. Design săgeată Control , pentru care repetați pasul 2, înlocuind stânga limite superior;
3. Design săgeată Mecanism, de ce repetați pasul 2, înlocuind stânga limite inferior.

Al doilea nivel de modelare

Orice nivel de modelare

Pentru a crea o descompunere a unui model la orice nivel de modelare, urmați acești pași:

• faceți clic pentru a activa un anumit bloc funcțional;
• repetați pasul 3 pentru nivelul actual al modelului.

1. Tipul și stilul săgeții pot fi selectate în caseta de dialog Arrow Properties (Fig. 2.9), invocată de comanda Style din meniul contextual săgeată.

1. Pentru instalare împachetare de cuvinte prin evidențierea numelui, reduceți dimensiunea dreptunghiului, după care va crește automat în jos.
2. Fiecare săgeată desenată pe o diagramă de nivel superior trebuie să fie prezentă pe o diagramă de nivel inferior.
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 ar trebui:
   • 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ă de delimitare). 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 ar trebui:
   • faceți clic dreapta pe paranteze pătrate;
   • selectați elementul de meniu Referință în afara paginii;
   • în caseta de dialog Referință săgeată în afara paginii selectați diagrama pe care trebuie plasată săgeata și setați comutatorul necesar de tip săgeată (Fig. 2.11);

• apăsați unul dintre butoanele: OK și mergeți la diagramă (mergi la graficul 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ţiile trăgător). Aceste săgeți nu ating joburile și trebuie asociate cu joburi în modul Creare săgeți ( Instrumentul săgeată de prioritate – ).

Aspectul și stilul săgeții sunt corecte în mod implicit:

• executa comanda Model / Proprietăți model;
• La fereastră Proprietățile modelului(fig. 2.12) selectați fila Aspect ;
• caseta de selectare (opțiune) Spațiează automat săgețile in grup Săgeți

1. Când creați o săgeată feedback-ul managementului setați opțiunea pentru a indica direcția săgeții Extra Arrowhead (din meniul contextual).
2. Dacă etichetele săgeților nu sunt bine poziționate (foarte departe etc.), bifați caseta de validare Squiggle (în meniul contextual) pentru liderul etichetei.

1. În diagrama de descompunere, în stânga sus, se află un bloc funcțional, care conține cea mai importantă și realizată primă lucrare. Munca care este mai puțin importantă sau efectuată ulterior scade.
2. Înveliș cu cuvinteîn interiorul lucrării se execută în modul Editor de nume... prin apăsarea unei taste introduce.
3. Diagonala din 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 copii care apar automat, ci și prefixele (A), ar trebui să selectați comanda Model / Proprietăți model, marcaj Numerotare, caseta de selectare (opțiune) Afișează 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 Model / Proprietăți model, marcaj Numerotare, caseta de selectare (opțiune) Utilizați formatul de numerotare diagramă (fig. 2.13).
2. Pentru a face distincția între diferitele versiuni ale aceleiași diagrame, 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 arborelui model

• echipă Diagramm / Adăugați / Arborele de noduri afișează o casetă de dialog Node Tree Wizard_Pasul 1 din 2 (fig. 2.14);
• conduceți un dialog selectând numărul necesar de niveluri ale arborelui 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ța de execuțieși relații cauzaleîntre situaţii şi evenimente. Folosind IDEF3, ei descriu logica executării lucrării, succesiunea începutului și sfârșitului acestora.

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 unei secvențe de proprietăți ale unui obiect în cadrul procesului luat în considerare. Modelele IDEF0 sunt asociate cu scripturi IDEF3, deoarece fiecare model IDEF0 poate fi reprezentat ca unul sau mai multe scripturi IDEF3.

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

• documentează datele disponibile privind tehnologia de execuție a procesului, identificate, să zicem, în procesul de intervievare a specialiștilor în domeniu;
• analizează procesele existente și dezvoltă altele noi;
• simuleaza situatii prin identificarea situatiilor in care este necesar luarea deciziilor afectarea ciclului de viață al procesului, de exemplu, o modificare a designului, proprietăților tehnologice sau operaționale ale produsului final;
• ajuta la luarea celor mai bune decizii 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 sistemelor, deoarece fac posibilă analiza în timp a situației și descrierea obiectelor care participă la același proces în același timp.

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

1. Diagramă care descrie secvența pașilor dintr-un proces.
2. Diagrama stării obiectului.

Sunt utilizate următoarele convenții standard:

	element funcțional comportamental,
	Transferul acțiunii de la un element funcțional al comportamentului (anterior) la altul (ulterior) ( Precedenta ),
	Tranziția fluxului de date de la locul de muncă la locul de muncă ( Fluxul obiectelor ),
	Conectarea datelor la locul de muncă ( Referent ),
	Comunicarea între lucrări ( Relațional ),
	Starea obiectului.

Reglarea secvenței de execuție a unităților de lucru se realizează prin introducerea în diagramă răscruce de drumuri (Joncţiune) în scopuri diferite.

Simbol J o intersecție poate lua una dintre următoarele valori:

• & – fuziune rezultatele tuturor acțiunilor dacă săgețile intră în intersecție; lansa toate acțiunile dacă săgețile ies din el;
• O - fuziune rezultatele acțiunilor dacă cel puțin una dintre acțiunile de intrare este finalizată; lansa cel puțin o acțiune;
• X - fuziune doar o acțiune din numărul celor care intră în intersecție; lansa o singură acţiune ieşind din ea.

O ilustrare a utilizării răscrucelor în diagrame de flux de proces este fig. 2.15. Din aceasta rezultă că o intersecție este un mijloc de construire a unor procese tehnologice ramificate complexe.

Descrierea tehnologiei dezvoltate sau investigate sub formă de prima diagrame care descriu succesiunea etapelor procesului tehnologic si apoi in forma diagrame de stare a obiectelor oferă o imagine completă a acțiunilor efectuate și a rezultatelor aplicării acestora.

	Job 3 are loc atunci când Job 1 și Job 3 sunt finalizate.
	Lucrarea 1 și Munca 2 merg împreună
	Job 3 are loc când Job 1 sau Job 2 este terminat, sau ambele.
	Lucrarea 1 și Lucrarea 2 apar împreună sau separat
	Lucrarea 3 apare atunci când Lucrarea 1 sau Lucrarea 2 este încheiată
	Job 1 sau Job 2 în curs

În consecință, în mâinile managerilor și dezvoltatorilor de sisteme informaționale există un instrument puternic pentru crearea scenariilor de procese complexe de management care necesită studiu și automatizare.

4.4. Flux de lucru de modelare IDEF3

Pregătirea modelului

1. Apăsați butonul pentru a crea un model.
2. În caseta de dialog BPWin urmează următoarele instrucțiuni:
   • Selectați Fluxul procesului (IDEF3);
   • setați numele modelului;
   • apasa butonul O.K;
   • în caseta de dialog Proprietăți pentru modelul nou confirmați proprietățile specificate acolo.

Înregistrarea unei acțiuni

1. Apăsați butonul pentru a crea o acțiune ( Instrument caseta de activități ).
2. Faceți clic stânga în locul dorit din fereastra modelului.
3. În meniul contextual al acțiunii, 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 cere Arial Cyr, O.K.

Formatarea datelor

1. Apăsați butonul pentru crearea datelor. ( Instrument de referință ).
2. În locul potrivit al ferestrei 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 de săgeți creat (opțiunea Săgeată), sau creați-le din nou (opțiune Alte) (fig.2.17).

1. Într-un dialog Fereastra Proprietăți Referent (fig. 2.18), în fila Font cere Arial cyr bifați casetele de selectare necesare și faceți clic pe butonul O.K.

5. Temele pentru următoarea lecție

1. Gândiți și definiți obiecte materiale sau indivizi care sunt surse sau receptori de informații (entități externe).
2. Gândiți și dezvoltați un model relațional al datelor procesate de sistemul informațional:
   • faceți o listă de entități și atributele acestora,
   • arată relaţiile dintre entităţi.
3. Pe baza sarcinii tehnice elaborate, gândiți și propuneți profesorului numele lucrărilor individuale care sunt implementate în sistem în procesul de realizare a fiecăreia dintre lucrările cheie plasate în diagrama de descompunere a celui de-al doilea nivel.
4. Executarea p.p. Înregistrați 1-3 teme într-un fișier numit „ Informații pentru a 3-a lecție.doc », Executat în Word, și prezentat profesorului.
5. Pentru a elabora secțiunea " Informații teoretice pentru lecția practică»Un atelier la a 3-a lecție.

1.6. Fragment din diagrama arborelui nodurilor (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 îndeplini criteriile specificate
Analiza documentelor	Analiza documentelor însoțitoare și primite pentru conformitatea cu reglementările
Întreținerea bazei de date	Efectuarea operațiunilor de reîmprospătare a datelor
IMPLEMENTAT MUNCĂ	Numele funcției de context care definește SCOPUL și LIMITELE simulării
Prelucrare finală	Adoptarea și formularea unei decizii (POZITIV dacă datele îndeplinesc criteriile specificate și NEGATIV în caz contrar), precum și crearea și executarea 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 calitatii	Sistematizarea si analiza rezultatelor pentru conformitatea cu standardul
Prelucrarea rezultatelor testelor	Analiza rezultatelor pentru funcționalitate, fiabilitate și supraviețuire
Hârtii	Acceptarea documentelor și selectarea informațiilor care urmează să fie introduse în baza de date
	Căutarea datelor în tabelele bazei de date pe baza interogărilor generate de utilizator
Reumplerea bazei de date	Introducerea de noi date în tabelele bazei de date
Recepția și înregistrarea documentelor	Acceptarea ș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	Acțiune care rezumă operațiunile tehnologice din a treia etapă a procesului de producție
Prelucrarea rezultatelor producției	Recepția și analiza documentelor pe baza rezultatelor lucrărilor și controlului curent
Editarea bazei de date	Modificarea înregistrărilor în tabelele bazei de date
CONTABILITATEA ACTIVITĂȚILOR	Prelucrarea și raportarea documentelor (modelul părții de non-producție a domeniului subiect)

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 procesul contabil
Standard de stat	Standard de stat pentru documente
Date din tabelul DB	Date citite din tabelele bazei de date
Date obţinute în urma analizei	Informații destinate executării documentelor de ieșire și utilizate în luarea unei decizii
Date care caracterizează rezultatele lucrului cu documente	Informații care reflectă detaliile (caracteristicile calitative și cantitative) ale obiectelor prelucrate
Documente de testare si control	Documente care reflectă datele obținute în etapa finală a procesării obiectului
Descrierea postului	Instrucțiuni care reflectă responsabilitățile locului de muncă ale interpretului
Cererile utilizatorilor
Obiecte noi și schimbate	Obiecte create și modificate în timpul implementării ciclului de producție
Obiecte baze de date	Tabele, formulare, interogări, rapoarte, macrocomenzi și module
Prelucrarea obiectelor	Obiecte modificabile în diferite etape ale procesului de producție
Obiecte prelucrate la prima etapă	Obiecte schimbate în prima etapă a procesului de producție
Obiecte prelucrate la a 2-a etapă	Obiecte schimbate la a 2-a etapă a procesului de producție
Obiecte prelucrate în etapa a 3-a	Obiecte schimbate la a 3-a etapă a procesului de producție
	Departamentul de control tehnic care verifică obiectul creat pentru a îndeplini cerințele standardului
Divizii de companie și specialiști profesioniști	Actori implicați în procesul de producție sau în procesul de dezvoltare
REGULI DE PERFORMANȚĂ	Reguli de proces și de transformare a datelor
Reguli contabile	Sistem de contabilitate și înregistrare a documentației care însoțește procesul de producție sau procesul de dezvoltare
DECIZIE	O decizie pozitivă sau negativă luată în funcție de satisfacția datelor analizate cu criteriile specificate
Documente acceptate	Documente care au trecut de înregistrare
Software	Platforma pe baza căreia este implementată baza de date dezvoltată
Rezultatele analizei documentului	Rezultate obținute în urma analizei documentelor primite și însoțitoare pentru conformitatea cu reglementările
Rezultate controlul calității
rezultatele căutării	Informații din tabelele bazei de date obținute prin 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	Entități implicate în activități de producție
Instruire tehnologică	Secvența operațiilor procesului tehnologic
Cererile utilizatorilor	Interogări create de utilizator pentru a selecta informațiile necesare din baza de date și pentru a crea documente de ieșire
MECANISMUL DE EXECUTARE	Resurse pentru conversia intrărilor în ieșiri
Intrări noi	Înregistrări în tabelele bazei de date care au apărut după introducerea datelor noi
Corecţie
	Entitatea care efectuează examinarea

versiune tipărită

Majoritatea celor care sunt 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 vorbesc încă limbi diferite: ei înțeleg diferit ce înseamnă creșterea eficienței unei întreprinderi.

Dezvoltatorii de sisteme informatice înțeleg de foarte multe ori creșterea eficienței ca o creștere a numărului de stații de lucru într-o rețea locală (LAN) a unei întreprinderi, o creștere a lățimii de bandă LAN, o creștere a numărului de documente procesate la stațiile de lucru automatizate (AWP-uri). ), etc.

Prin creșterea eficienței unei întreprinderi, clienții înseamnă o creștere a productivității muncii, o scădere a costurilor și o creștere a calității produselor și serviciilor. Recent, noi condiții și noi concepte au apărut 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 informațional până la rezolvarea unor probleme complexe pentru a îmbunătăți eficiența întreprinderii clientului. Cu această abordare, problema unei modalități eficiente de studiere a sferei de activitate a clientului iese în prim-plan:

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

În cadrul 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 sunt instrumentele CASE pentru modelarea funcțională a proceselor de afaceri.

Acest articol oferă o prezentare generală a unei clase de instrumente funcționale de modelare a proceselor de afaceri concentrate pe utilizarea metodologiei IDEF0.

IDEF0 - Metodologia de modelare funcțională

În cursul implementării programului de informatizare integrată a producției (ICAM), propus la acea vreme de Forțele Aeriene pentru industria aerospațială din SUA, a fost identificată necesitatea dezvoltării unor metode de analiză a interacțiunii proceselor în 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 acceptată ca standard federal din SUA. Metodologia a fost aplicată cu succes într-o mare varietate de industrii, demonstrându-se ca un instrument eficient pentru analiza, proiectarea și 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 unui cosmodrom în Plesetsk), în Banca Centrală și băncile comerciale din Rusia, în industria petrolului și gazelor. industrie și întreprinderi din alte industrii.

Concepte de bază ale IDEF0

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ă este „înăuntru”, dreapta este „în afară”, partea de sus este „control”, partea de jos este „mecanism” (vezi Fig. 1).

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

Principii de modelare în IDEF0

IDEF0 implementează trei principii de bază ale modelării proceselor:

• principiul de descompunere funcțională;
• principiul limitării complexității;
• principiul contextului.

Principiul descompunerii funcționale este o modalitate de modelare a unei situații tipice când orice acțiune, operație, funcție poate fi descompusă (descompusă) în acțiuni, operații, funcții mai simple. Cu alte cuvinte, o funcție complexă de afaceri poate fi reprezentată ca o colecție de funcții atomice. Reprezentând grafic funcțiile, sub formă de blocuri, se poate, parcă, privi în interiorul blocului ș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ă trebuie să fie de cel puțin două și nu mai mult de șase. Practica arată că respectarea acestui principiu duce la faptul că procesele funcționale, prezentate sub forma modelului IDEF0, sunt bine structurate, de înțeles și ușor de analizat.

Principiul diagramei de context. Modelarea unui proces de afaceri începe cu construirea unei diagrame de context. Această diagramă afișează un singur bloc - principala funcție de afaceri a sistemului modelat. Când vine vorba de modelarea unei întregi întreprinderi sau chiar a unei mari divizii, funcția principală a afacerii nu poate fi formulată ca, de exemplu, „vinde produse”. Funcția principală de afaceri a sistemului este „misiunea” sistemului, semnificația sa în lumea înconjurătoare. Este imposibil să formulezi corect funcția principală a unei întreprinderi fără a-i cunoaște strategia.

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

Diagrama de context joacă un alt rol în modelul funcțional. Acesta „fixează” granițele sistemului de afaceri modelat, definind modul în care sistemul modelat interacționează cu mediul său. Face acest lucru prin descrierea arcurilor conectate la un bloc care reprezintă funcția principală de afaceri.

Aplicarea IDEF0

După familiarizarea cu conceptele și principiile de bază ale modelării funcționale a proceselor de afaceri, întrebarea firească este: cum ajută la creșterea eficienței și calității întreprinderii.

Construirea modelului CA ESTE... Un studiu de întreprindere este o parte indispensabilă 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 în mod clar ce procese de afaceri sunt efectuate în întreprindere, ce obiecte de informații sunt utilizate în realizarea 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 procesului de afaceri.

Reguli de afaceri... Modelul de proces de afaceri vă permite să identificați și să definiți cu precizie regulile de afaceri utilizate în activitățile întreprinderii.

În fig. 3 prezintă un fragment al modelului funcțional al fluxului de documente. La efectuarea operațiunii „sortare documente”, se folosește regula de afaceri: „Nu face obiectul înscrierii: documente trimise în copii pentru informare, telegrame și scrisori de autorizație pentru călătorii de afaceri și vacanțe...”. Această regulă este fixată î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 arată astfel: „dacă la recepție a ajuns un document destinat managementului, acesta este supus sortării, în urma căreia, pe baza instrucțiunii, 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.

De foarte multe ori regulile de afaceri la întreprindere nu sunt scrise în instrucțiuni: par să fie acolo, dar nici nu sunt acolo. Ca urmare, încercările de a schimba ceva în activitățile unei întreprinderi sau departament se pot solda cu eșec pur și simplu pentru că aceste modificări sunt contrare regulilor 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ă modul în care obiectele informaționale sunt utilizate în cadrul proceselor de afaceri.

Construirea modelului așa cum va fi... Crearea și implementarea unui sistem informațional corporativ duce la schimbarea condițiilor de efectuare a operațiunilor individuale, a structurii proceselor de afaceri și a întreprinderii în ansamblu. Acest lucru duce la necesitatea schimbării sistemului de reguli de afaceri utilizate în întreprindere, pentru modificarea fișelor de post ale angajaților. Modelul funcțional AȘA COME VA permite determinarea acestor modificări deja în faza de proiectare a viitorului sistem informațional. Aplicarea modelului funcțional așa cum va permite nu numai reducerea timpului de implementare a sistemului informațional, ci și reducerea riscurilor asociate imunității personalului la tehnologiile informaționale.

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 de software personalizat a decis să-și creeze propria forță de vânzări. Un model funcțional al procesului de afaceri pentru vânzarea de software va permite conducerii companiei să determine în mod clar ce resurse trebuie alocate pentru a asigura funcționarea serviciului de vânzări, câți angajați trebuie atrași pentru a lucra în serviciu nou, ce responsabilități funcționale ar trebui să îndeplinească acești angajați etc.

Sisteme software IDEF0

În prezent, există multe instrumente CASE care suportă 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 sfera activităților clientului și să rezolve probleme pentru a îmbunătăți eficiența acestei activități.

Utilizarea modelării funcționale ne permite să rezolvăm nu numai problemele tehnice ale clientului legate de tehnologia informației, ci și problemele legate de domeniul de activitate al clientului. Acest lucru face posibilă transformarea proiectului unui sistem informatic dintr-un „pachet 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ă.

Cunoscută astăzi nu numai în cercuri înguste, abrevierea IDEF0 este prima metodologie care standardizează munca asupra proceselor de afaceri. A fost dezvoltat la mijlocul secolului trecut ca parte a unui proiect aerospațial din Statele Unite și, după ce și-a demonstrat eficacitatea, a devenit un standard federal. La noi în anul 2000 a fost întocmit un document „ Metodologia de modelare funcțională IDEF0. Document de orientare Metodologia de modelare funcțională IDEF0 Ghid Document. Ediție oficială. Gosstandart din Rusia RD IDEF0 - 2000. Dezvoltat de Centrul de Cercetare CALS - Tehnologii „Logistică aplicată”. Adoptat și pus în aplicare prin Decretul Gosstandart al Rusiei 2000, Moscova”, Dar ca standard nu a fost niciodată aprobat. Deși acest lucru nu a împiedicat această metodologie să devină unul dintre cele mai populare instrumente de modelare grafică a proceselor de afaceri din țara noastră. În acest articol, vă invit să revizuiți modelul IDEF0 și să evaluați relevanța actuală a acestei abordări.

Concepte de bază și abrevieri

Să ne dăm seama puțin cu numele elementelor cheie ale metodologiei. Standardul grafic IDEF0 face parte din metodologia SADT (Structured Analysis and Design Technique). IDEF este o abreviere pentru ICAM Definition, iar ICAM este derivat din Integrated Computer Aided Manufacturing, care se traduce prin computerizarea integrată a producției. Metodologia SADT este o întreagă familie de 15 modele diferite, care împreună trebuiau să permită studiul structurii, parametrilor și caracteristicilor sistemelor producție-tehnice și organizațional-economice.

IDEF0 este un model funcțional, care este nucleul tuturor celorlalte structuri, leagă între ele fluxurile de informații și materiale, structura organizațională, acțiunile de control și însăși activitățile companiei. Standardul grafic pentru procesele de modelare se mai numește și notație. Adică, notația este un sistem de cerințe și reguli pentru construirea unui model de activitate într-o formă sau alta. Prin urmare, este adecvat să se numească IDEF0 notația care face parte din metodologia SADT.

Notația IDEF0 este o tehnică destul de riguroasă care a fost dezvoltată inițial, ca standardele de proiectare tehnică, pentru modelarea manuală. Prin urmare, conține cerințe pentru plasarea săgeților, formatul tuturor elementelor, conținutul cadrului de informații pentru diagrama IDEF0 etc. Deoarece activitățile companiei sunt un sistem complex de acțiuni pe mai multe niveluri, există întotdeauna multe scheme, și se impune o sistematizare și o navigare fără ambiguitate prin toate elementele modelului. Acum, acest lucru este realizat în principal de sisteme informatice care acceptă modelarea în această notație. Pe teritoriul Rusiei, cele mai faimoase și disponibile astăzi sunt sistemele AllFusion Process Modeler și Business Studio. Plănuiesc să dedic articole separate revizuirii acestor sisteme.

Bloc funcțional

Elementul central al modelului IDEF0 este funcția, care este afișată pe diagramă ca bloc functional- un dreptunghi, în interiorul căruia acţiunea este indicată sub forma unui substantiv verbal. Acțiunea poate fi foarte diferită ca scară - de la activitățile companiei în general și până la manipularea specifică în special. Exemple: „Producția și vânzarea de vesela ceramică” și „Desen pe produs”.

Elemente obligatorii ale blocului funcțional în IDEF0

Indiferent de scara acțiunilor, toate funcțiile sunt afișate uniform și conțin în mod necesar 4 fluxuri cheie, care sunt alocate rigid părților laterale ale blocului funcțional:

• în stânga - intrări sau resurse utilizate pentru îndeplinirea funcției;
• în dreapta - ieșiri sau rezultate ale execuției funcției;
• în partea de sus - acțiuni de control care determină cum și câte rezultate trebuie produse;
• mai jos - mecanisme care reflectă cine și cu ajutorul a ceea ce ar trebui să facă această muncă.

Această abordare vă permite să economisiți puțin în explicațiile din diagrame și să obțineți o claritate în afișarea fluxurilor, ceea ce face ca întregul model să fie subțire.

Pentru a construi un model funcțional, metodologia IDEF0 necesită respectarea următoarelor reguli.

1. Intrările sunt resurse care își transferă valoarea totală către ieșiri, adică sunt cheltuite pentru a crea un rezultat în totalitate, iar mecanismele sunt resurse care își transferă valoarea doar parțial (echipamente prin amortizare și oameni prin salarii).
2. Managementul este un element necesar al modelului, deoarece leagă toate acțiunile de sistemul de reglementări ale companiei, indicând în mod clar ce reguli și cerințe trebuie respectate în procesul de îndeplinire a funcției. Adesea, acest flux este tratat formal, dar schema își pierde rigoarea și uneori chiar sensul.
3. Fiecare bloc funcțional trebuie să aibă cel puțin o săgeată pe fiecare parte (din moment ce nu poate exista muncă fără resurse sau rezultate, iar o instrucțiune fără executant sau instrucțiune va fi incompletă).

Schema luată în considerare este un „bloc de bază” al abordării IDEF0. Modelarea funcțională implică o tranziție treptată de la general la particular prin descompunere. Descompunerea este o „aprofundare” a funcției luate în considerare, împărțind-o în funcții mai mici. Mai mult, atunci când funcția de nivel superior este prezentată într-o manieră generalizată și după ce este descompusă, este potrivit să o numim proces.

Diagrama de context

La cel mai înalt nivel, compania este prezentată ca o „cutie neagră” în care se desfășoară o anumită activitate, transferând intrări la ieșiri. Acest nivel se numește de obicei „”, adică o diagramă care descrie contextul activităților companiei. În plus, diagrama de context afișează caracteristicile cheie ale întregului model.

1. Scopul este o formulare specifică a scopului modelului, prin care acuratețea construcției modelului poate fi verificată în viitor.
2. Punct de vedere - pe a cărui față este construit modelul, deoarece modelul depinde întotdeauna de autorul său și de focalizarea atenției. Dacă construim un model general al întreprinderii, atunci acesta este de obicei prezentat din punctul de vedere al directorului acesteia.
3. Tipul de model este o indicație a informațiilor afișate pe diagrame. Pot exista 2 opțiuni principale: AS IS ("Așa cum este") sau A FI ("Așa cum va fi"). Această separare este necesară, deoarece putem construi modele atât pentru analiza activității, cât și pentru transformarea acesteia. Trebuie să fim clar conștienți de ceea ce facem și, de asemenea, să transmitem aceste informații altora.

Astfel, diagrama de context conține în cea mai generalizată formă o descriere a activităților companiei, care este pătrunsă de fluxurile care leagă compania de lumea exterioară. Cred că ar trebui să ne oprim și asupra lor mai detaliat.

Fluxuri principale

Experiența a arătat că, în ciuda aparentului simplitate și formalitate a acestui nivel, este adesea necesar să rămâneți la el pentru o lungă perioadă de timp, deoarece toate rezultatele care sunt semnificative pentru proprietar și piață ar trebui să se reflecte aici. O greșeală poate duce la crearea de modele care nu îndeplinesc sarcinile stabilite pentru afacere. Pentru a verifica dacă fluxurile semnificative sunt reflectate, asigurați-vă că toate cele 4 tipuri de flux principale sunt prezente în diagramă.

1. Material: materiale si componente la intrare si produse finite la iesire.
2. Client: un potențial client care intră și un client mulțumit.
3. Financiar: la intrare, acestea sunt de obicei investiții, plăți ale clienților (venituri), împrumuturi și alte venituri; rezultatul este plăți către furnizori, impozite, plăți la împrumuturi și profituri.
4. Informațional: la intrare, acestea sunt toate fluxurile de informații despre mediul extern (condițiile pieței, comportamentul concurenților, inovațiile tehnologice etc.), iar la ieșire, acesta este fluxul de informații pe care compania îl comunică despre ea însăși către lume (toate informațiile publicitare, precum și toate tipurile de raportare în fața autorităților de reglementare).

Vă rugăm să rețineți că o companie este un sistem deschis și nimic nu vine sau pleacă. O companie este capabilă doar să transforme fluxurile de intrare în fluxuri de ieșire, iar dacă o face bine, atunci apare un flux de numerar (profit) suplimentar, care reflectă, într-un fel, calitatea întregului sistem.

(click pentru a mari)

Este bine dacă scoți în evidență fiecare dintre aceste tipuri de fluxuri cu propria ta culoare, astfel încât să poți distinge cu ușurință mișcarea resurselor și să nu ratezi puncte importante. De exemplu, este adesea posibil să se observe absența unui client în fluxurile companiei, prin urmare, lucrul cu acesta se bazează pe un principiu rămas - clientul se simte adesea ca un obstacol pentru angajații companiei, ale căror sarcini sunt concentrate pe procesarea fluxul de documente.

Săgețile de control pot fi reprezentate doar de un singur tip de flux - flux de informații, care poate fi împărțit în 2 subspecii. Primul este documente precum:

• legi și reglementări;
• comenzi, comenzi;
• instructiuni si regulamente;
• planuri;
• documentatia de proiectare etc.

Al doilea este informațiile nedocumentate, care includ cel mai adesea cerințele proprietarilor.

Și, în sfârșit, mecanisme - există doar 2 tipuri de fluxuri: echipamente (material) și performeri (departamente și oameni). Aici nu pot fi documente, la fel cum nu pot fi persoane în punctele de control!

Modelul oferă numerotare continuă pentru navigare. Diagrama de context este numerotată „A-0”. În viitor, fiecare bloc funcțional primește propriul său număr, indiferent cât de adâncă este descompunerea.

Descompunere

După elaborarea fluxurilor diagramei de context, putem trece la descompunere. Trecând la un nivel mai jos, ca și cum am deschide o „cutie neagră”, vedem mai întâi o foaie goală cu săgeți care au fost atașate blocului funcțional.

(click pentru a mari)

Și aici începe modelarea funcțională reală - trebuie să înțelegem ce set de acțiuni poate conecta aceste fluxuri și să ne asigurăm că toate cerințele sunt îndeplinite. Dificultatea constă în faptul că există o mulțime de acțiuni în companie, iar pe diagramă avem dreptul de a afișa nu mai mult de 9 funcții, altfel diagrama va deveni ilizibilă și, în consecință, inutilă.

Nu este întotdeauna ușor să organizezi activități complexe în așa fel încât să rămână vizuale, lizibile și, în același timp, complete. Cel mai adesea, recurg la împărțirea întregii varietăți de procese în blocuri mari principale, dintre care cele mai semnificative sunt următoarele.

1. Crearea unui produs (rezultat).
2. Promovare și vânzare - lucrați cu fluxul de clienți.
3. Sprijinul pentru activitățile de creare a produselor sunt procese secundare care sunt necesare pentru a se conforma cerințelor guvernamentale sau pentru a asigura comoditatea muncii (personal și contabilitate, servicii de transport, curățare a spațiilor etc.).
4. Crearea fluxurilor de management - activitatea de dezvoltare a soluțiilor de management care vor determina cerințele pentru toate procesele companiei.

Figura de mai jos prezintă diagrama de descompunere a exemplului nostru.

(click pentru a mari)

În diagramă, procesele ar trebui să fie aranjate în diagonală - acest lucru se numește principiul dominantei, care presupune aranjarea blocurilor funcționale de la stânga la dreapta și de sus în jos - în ordinea importanței sau în ordine cronologică. Numerotarea blocurilor este aceeași.

Lucrările ulterioare asupra modelului sunt similare cu primul pas - fiecare bloc funcțional al primului nivel este descompus. Numerotarea blocului va conține numărul primului nivel: A1.1… A1n, A2.1… A2.n etc.

Concluzii despre relevanța notației

În cadrul acestui articol, a fost posibil să se afișeze doar conceptele de bază ale IDEF0-notație folosind un scurt exemplu de IDEF0, prin care, desigur, este dificil să judecăm metodologia în ansamblu. Dar destulă experiență în utilizarea acestei notații în practică îmi permite să trag următoarele concluzii.

1. Modelul are un bun potențial de vizualizare, dar, după părerea mea, importanța sa mai mare este în efectul disciplinar. Regulile și limitările încorporate în metodologie ne obligă să dezvoltăm o atitudine sistematică și strictă față de modele, ceea ce are un efect foarte bun asupra calității rezultatului final.
2. Modelul vă permite să construiți fluxuri de comunicare între lucruri care aparent nu sunt puternic conectate: să conectați subsistemele front și back-office cu management, ceea ce este mult mai rău pentru alte notații.
3. Abordarea este simplă și de înțeles pentru majoritatea participanților la proiect. Construirea și citirea diagramelor în această notație este limitată doar de dorința de a aprofunda în complexitatea fluxurilor de afaceri.

Unele dintre argumentele de mai sus fac să credem că această abordare este cea mai bună și singura pentru o modelare completă a activităților. Dar nu uitați că modelul funcțional este conceput doar pentru nivelul superior de modelare. Utilizarea notației IDEF0 pentru proiectarea lucrărilor la nivelul interpreților duce la faptul că schemele sunt pur ilustrative și, pe baza lor, este imposibil să se construiască o reglementare sensibilă, deoarece nu conțin:

• concretizarea evenimentelor de declanșare și oprire a procesului;
• conditii pentru trecerea de la o actiune la alta;
• capacitatea de a afișa vizual toate resursele și performanții fără a supraîncărca diagrama cu săgeți.

Prin urmare, dacă utilizați această notație pentru sarcinile pentru care este destinată (structurarea activităților de nivel superior), atunci IDEF0 este practic singura notație de astăzi care vă permite să faceți acest lucru în mod semnificativ și precis.

În managementul proiectelor, acest standard de modelare este cel mai aplicabil acolo unde este necesar să se conecteze diferite proiecte sau procese cu fluxuri vizuale. În același timp, modelul grafic va face posibilă o distribuire mai rațională a responsabilităților și a resurselor pe sarcini. Logica sarcinilor proiectului, reflectată în diagrame, va ajuta la pregătirea unui program mai bun sub forma unei diagrame Gantt.

Aceste recomandări de standardizare sunt destinate utilizării în analiza și sinteza sistemelor producție-tehnice și organizațional-economice prin metode de modelare funcțională în diverse sectoare ale economiei.
Recomandările conțin o descriere a unui set de instrumente pentru vizualizarea unei game largi de afaceri, producție și alte procese și operațiuni ale unei întreprinderi la orice nivel de detaliu,precum şi metode organizatorice şi metodologice de utilizare a acestor instrumente.

Complicarea constantă a sistemelor de producție-tehnic și organizatoric-economic - firme, întreprinderi, industrii și alte subiecte de producție și activitate economică - și necesitatea analizei acestora în vederea îmbunătățirii funcționării și creșterii eficienței necesită utilizarea unor mijloace speciale de descriere. și analiza unor astfel de sisteme. Această problemă are o relevanță deosebită în legătură cu apariția producției integrate computerizate și a întreprinderilor automatizate.
În Statele Unite, la sfârșitul anilor '70, a fost propus și implementat ICAM - Programul Integrat de Producție Asistată de Computer, care urmărea creșterea eficienței întreprinderilor prin introducerea pe scară largă a tehnologiilor informatice (informaționale).
Implementarea programului ICAM a necesitat crearea unor metode adecvate de analiză și proiectare a sistemelor de producție și modalități de schimb de informații între specialiștii care se ocupă de astfel de probleme. Pentru a răspunde acestei necesități, în cadrul programului ICAM, a fost dezvoltată metodologia de modelare IDEF (Definiția ICAM), care permite studierea structurii, parametrilor și caracteristicilor sistemelor producție-tehnice și organizațional-economice.

Metodologia IDEF

Metodologia generală IDEF constă din trei metodologii specifice de modelare bazate pe reprezentări grafice ale sistemelor:
IDEF0 este folosit pentru a crea un model funcțional care se afișeazăstructura și funcțiile sistemului, precum și fluxurile de informații și materialeobiecte convertite de aceste funcții;
IDEF1 este folosit pentru a construi un model de informații care afișeazăstructura și conținutul fluxurilor de informații necesare pentru a susținefuncțiile sistemului;
IDEF2 vă permite să construiți un model dinamic de variație în timpcomportamentul funcţiilor, informaţiilor şi resurselor sistemului.
Până acum, cele mai răspândite și aplicate metodologii sunt IDEF0 și IDEF1 (IDEF1X).
Metodologia IDEF0, ale cărei caracteristici și aplicare sunt descrise în aceste recomandări, se bazează pe abordarea numită
SADT - Structured Analysis & Design Technique - metoda de analiza structurala si proiectare. Baza acestei abordări și a metodologiei IDEF0 este un limbaj grafic pentru descrierea (modelarea) sistemelor.

Concepte generale

Model IDEF0: O descriere grafică a unui sistem, concepută cu un scop specific și un punct de vedere ales. Un set de documente IDEF0 care descriu funcțiile unui sistem folosind grafice (diagrame), text și un glosar.
Scop: O scurtă declarație a motivului creării modelului.
Punct de vedere: o indicație a oficialului sau departamentului organizației din a cărui poziție este dezvoltat modelul. Există un singur punct de vedere pentru fiecare model.
Glosar: o listă de definiții pentru cuvinte cheie, fraze și abrevieri asociate cu noduri, blocuri, săgeți sau modelul IDEF0 în general.
Text: orice comentariu textual (negrafic) asupra diagramei grafice IDEF0.
Notă de model: un comentariu text care face parte din diagrama IDEF0 și este folosit pentru a înregistra un fapt care nu a găsit un grafic.
Funcție: o activitate, un proces sau o transformare (modedată de blocul IDEF0) identificată printr-o formă de verb sau verb care descrie ceea ce trebuie făcut.
Descompunere: împărțirea unei funcții modelate în funcții componente.

Exemplu de diagramă de context

Diagramă

Diagrama: Partea modelului care descrie descompunerea unui bloc.
Context: Mediul în care funcționează o funcție (sau un set de funcții dintr-o diagramă).
Diagrama de context: O diagramă cu numărul de nod A – n (A minus n) care reprezintă contextul modelului. Diagrama А – 0, constând dintr-un bloc, este o diagramă de context necesară (obligatorie); diagrame cu numere nodale А – 1, А – 2, ..., - diagrame de context suplimentare (n> 0). Diagrama A – 0 (A minus zero): Un tip special de diagramă IDEF0 (contextuală), constând dintr-un bloc care descrie funcția de nivel superior, intrările, ieșirile, controlul și mecanismele acesteia, împreună cu declarația scopului modelul și punctul de vedere din care este construit modelul.
Diagrama copil: O diagramă care detaliază blocul părinte (părinte).
Diagrama părinte: O diagramă care conține un bloc părinte.
Referință nodale: un cod atribuit unei diagrame pentru a o identifica și a o poziționa în ierarhia modelului; se formează din denumirea prescurtată a modelului și numărul nodal al diagramei cu extensii suplimentare.
Numărul nodului diagramei: porțiunea referinței nodale diagramei care corespunde numărului blocului părinte.

Descompunere

Pe diagrama de context A – 0, obiectul de modelare este reprezentat printr-un singur bloc cu săgeți de delimitare care reprezintă legătura obiectului de modelare
cu mediul înconjurător.

Funcția unică prezentată în diagrama de context de nivel superior poate fi descompusă în sub-funcții principale prin crearea de diagrame copil care conțin detaliile blocurilor părinte.

bloc

Bloc: Un dreptunghi care conține un nume și un număr și folosit pentru a descrie o funcție.

Număr bloc: un număr (0-6) plasat în colțul din dreapta jos al blocului și care identifică în mod unic blocul în diagramă.

Nume bloc: un verb sau o schimbare verbală plasată în interiorul blocului și care descrie funcția care se modelează.

Bloc copil: un bloc într-o diagramă copil (copil).

Bloc părinte: un bloc care este descris în detaliu printr-o diagramă copil.

Următoarele reguli de sintaxă sunt setate pentru blocuri:

Dimensiunile blocului trebuie să fie suficient de mari pentru a include numele și numărul blocului.

Blocurile trebuie să fie dreptunghiulare cu unghiuri drepte;

Blocurile trebuie desenate cu linii continue.

Nod

Nod: un bloc care generează blocuri copii; bloc părinte.

Numărul nodului: un cod atribuit unui bloc și care determină poziția acestuia în ierarhia modelului; poate fi folosit ca expresie de referință detaliată.

Arborele de noduri: Reprezentarea relației dintre nodurile părinte și fii ale modelului IDEF0 sub forma unui grafic arbore. Are același sens și conținut ca și lista de noduri.

Lista de noduri: O listă, adesea în trepte, care arată nodurile modelului IDEF0 într-o manieră ordonată. Are același sens și conținut ca arborele de noduri.

Săgeată

Săgeată: o linie direcțională, constând din unul sau mai multe segmente, care simulează un canal deschis sau un canal care transferă date sau obiecte materiale de la o sursă (punctul de pornire al unei săgeți) la un consumator (punctul final cu un „sfârf”).Săgeată de intrare: o clasă de săgeți care reprezintă intrarea unui bloc IDEF0, adică obiecte de date sau materiale pe care funcția le convertește în ieșire. Săgețile de intrare sunt conectate la partea stângă a blocului IDEF0.Săgeată de ieșire: O clasă de săgeți care reprezintă rezultatul unui bloc IDEF0, adică date sau obiecte materiale produse de funcție. Săgețile de ieșire sunt conectate în partea dreaptă a blocului IDEF0.Mecanism cu săgeți: O clasă de săgeți care reprezintă mecanismele IDEF0, adică mijloacele folosite pentru a îndeplini o funcție; Include o carcasă specială pentru săgeți de apel. Săgețile mecanismului comunică cu partea inferioară a blocului IDEF0.Săgeată de control: O clasă de săgeți care în IDEF0 reprezintă controale, adică condiții în care ieșirea blocului va fi corectă. Datele sau obiectele modelate ca controale pot fi transformate printr-o funcție care generează rezultatul corespunzător. Săgețile de control sunt asociate cu partea de sus a blocului IDEF0.

Etichetă săgeată: un substantiv sau un substantiv rotație asociat cu o săgeată sau un segment de săgeată și care definește semnificația acestuia.

Săgeată interioară: o săgeată de intrare, control sau ieșire, ale cărei capete conectează sursa și consumatorul, care sunt blocuri ale aceleiași diagrame. Diferă de săgeata de delimitare.Săgeată de delimitare: o săgeată cu un capăt conectat la o sursă sau chiuvetă, iar celălalt neconectat la niciun bloc din diagramă. Arată legătura diagramei cu alte blocuri ale sistemului și diferă de săgeata interioară.Segment de săgeată: un segment de linie care începe sau se termină pe partea laterală a unui bloc, într-un punct de ramificare sau de îmbinare sau la o margine (capătul săgeții neconectat).Ramificare: împărțirea unei săgeți în două sau mai multe segmente.Îmbinare: îmbină două sau mai multe segmente de săgeată într-un singur segment.Legare / separare: combinarea valorilor săgeților într-o valoare compusă (grupare) sau împărțirea valorilor săgeții (dezlegarea unui „bundle”), exprimată în sintaxa săgeților de fuziune sau ramificare.Tilde: O linie mică întreruptă (onduită) folosită pentru a conecta o etichetă la un anumit segment de săgeată sau la o notă de model la o componentă de diagramă.Cod ICOM: cod pentru a potrivi săgețile de delimitare ale diagramei copil cu săgețile blocului părinte; folosit pentru legături (abrevierea ICOM înseamnă Input - input, Control - control, Output - output, Mechanism - mecanism).

Semantica cutiilor și săgeților

Fiecare parte a blocului funcțional are un scop standard în ceea ce privește comunicarea bloc/săgeată. La rândul său, partea blocului de care este atașată săgeata îi definește în mod unic rolul.

Regulile de sintaxă pentru săgeți sunt următoarele:- Săgețile sparte își schimbă direcția doar la un unghi de 90 °;- Săgețile trebuie desenate în linii continue.
Pot fi folosite linii de grosimi diferite; - Săgețile pot consta numai din linii verticale sau orizontale.
Nu sunt permise linii diagonale; - Capetele săgeților trebuie să atingă marginea exterioară a blocului funcțional,
dar nu trebuie să-l traverseze;

Săgețile trebuie să se atașeze de bloc pe părțile laterale ale acestuia.
Nu este permisă îmbinarea în colțuri.