Întocmirea diagramelor IDEF0. IDEF0: ce este și cum se folosește

Principala dintre cele trei metodologii suportate de BPwin este IDEF0. IDEF0, se referă la familia IDEF, care a apărut la sfârșitul anilor șaizeci sub numele SADT (Structured Analysis and Design Technique). IDEF0 poate fi folosit pentru a modela o gamă largă de sisteme. Pentru sisteme noi, utilizarea IDEF0 are ca scop definirea cerințelor și specificarea funcțiilor pentru dezvoltarea ulterioară a unui sistem care îndeplinește cerințele și implementează funcțiile selectate. S-a aplicat deja sistemele existente IDEF0 poate fi folosit pentru a analiza funcțiile îndeplinite de sistem și pentru a mapa mecanismele prin care sunt îndeplinite aceste funcții. Rezultatul aplicării IDEF0 la un sistem este un model al acelui sistem, constând dintr-un set ordonat ierarhic de diagrame, text de documentație și dicționare legate între ele prin referințe încrucișate. Cele mai importante două componente ale diagramelor IDEF0 sunt funcțiile sau activitățile de afaceri (reprezentate în diagrame ca casete) și datele și obiectele (reprezentate ca săgeți) care leagă activitățile. În acest caz, săgețile, în funcție de ce parte a dreptunghiului de lucru intră sau din ce parte ies, sunt împărțite în cinci tipuri:

Săgeți de intrare (incluse în partea stângă a lucrării) - descriu date sau obiecte care se modifică în timpul execuției lucrării.

Săgețile de control (incluse în limita superioară a lucrării) - descriu regulile și restricțiile în funcție de care este efectuată lucrarea.

Săgeți de ieșire (ieșiți din partea dreaptă a jobului) - descriu date sau obiecte care apar ca urmare a execuției jobului.

Săgețile mecanismului (incluse în partea de jos a lucrării) - reprezintă resursele necesare pentru a finaliza lucrarea, dar nu se modifică în cursul lucrării (de exemplu, echipamente, resurse umane...)

Săgeți de apel (ies din partea de jos a lucrării) - descrie conexiuni între diferite diagrame sau modele, arătând către o diagramă, unde acest lucru luate în considerare mai în detaliu.

Toate locurile de muncă și săgețile trebuie să fie denumite. Prima diagramă din ierarhia diagramei IDEF0 descrie întotdeauna funcționarea sistemului ca întreg. Astfel de diagrame se numesc diagrame de context. Contextul include o descriere a scopului modelării, domeniul de aplicare (o descriere a ceea ce va fi considerat ca o componentă a sistemului și ce ca o influență externă) și punctul de vedere (poziția din care va fi construit modelul) . De obicei, punctul de vedere al persoanei sau obiectului responsabil de funcționarea sistemului simulat în ansamblu este ales ca punct de vedere.

Figura 7.1. Blocuri funcționale și arcuri de interfață

Activitățile din diagrame sunt prezentate ca dreptunghiuri (blocuri funcționale). Fiecare loc de muncă descrie o funcție sau sarcină și este menționat printr-un verb sau o expresie verbală care denotă o acțiune, cum ar fi „Realizarea unui produs”, „Serviciul clienților” etc. Săgețile sunt marcate cu un substantiv și reprezintă obiecte sau informații care leagă lucrările între ele și cu lumea exterioară.

După descrierea contextului, se efectuează o descompunere funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris în aceeași sintaxă ca și sistemul în ansamblu. Apoi fiecare subsistem este împărțit în altele mai mici și așa mai departe până când se atinge nivelul dorit de detaliu. Ca rezultat al unei astfel de partiții, fiecare fragment al sistemului este reprezentat pe o diagramă de descompunere separată.

După ce contextul este descris, se realizează construcția următoarelor diagrame în ierarhie. Fiecare diagramă succesivă este mai mult descriere detaliata(descompunerea) a uneia dintre lucrările din diagrama de mai sus. Un exemplu de descompunere a lucrărilor de context este prezentat în Fig.7.2 și Fig.7.4. Descrierea fiecărui subsistem este realizată de un analist împreună cu un expert în domeniu. De obicei, expertul este persoana care este responsabilă pentru acest subsistem și, prin urmare, cunoaște în detaliu toate funcțiile acestuia. Astfel, întregul sistem este împărțit în subsisteme la nivelul dorit de detaliu și se obține un model care aproximează sistemul cu un anumit nivel de precizie. După ce a primit un model care reflectă în mod adecvat procesele actuale de afaceri (așa-numitul model AS IS), analistul poate vedea cu ușurință toate locurile cele mai vulnerabile din sistem. După aceea, ținând cont de neajunsurile identificate, este posibil să se construiască un model al unei noi organizări a proceselor de afaceri (modelul TO BE).

Una dintre cele mai importante caracteristici ale metodologiei SADT este introducerea treptată a nivelurilor crescânde de detaliu pe măsură ce sunt create diagramele care reprezintă modelul.

Figura 7.2, care prezintă cele trei diagrame și relațiile lor, prezintă structura modelului IDEF0.-. Fiecare componentă a modelului poate fi descompusă într-o diagramă diferită. Fiecare diagramă ilustrează „structura internă” a unui bloc din diagrama părinte.

Figura 7.2 - Un exemplu de diagramă de context

După cum puteți vedea în Figura 7.2, BPwin vă permite să evidențiați activități și săgeți cu culori diferite, precum și să legați numele săgeților la săgețile în sine (o săgeată numită „Raportare”), ceea ce crește vizibilitatea și lizibilitatea diagramei.

Figura 7.3 - Un exemplu de diagramă de descompunere

Desen7 . 4 - Exemplu de diagramă de context

Figura 7.5 - Exemplu de diagramă de descompunere

Ierarhia graficelor

Construcția unui model IDEF0 începe cu reprezentarea întregului sistem sub forma celei mai simple componente - un bloc și arce reprezentând interfețe cu funcții în afara sistemului. Deoarece un singur bloc reprezintă întregul sistem ca întreg, numele dat în bloc este generic. Acest lucru este valabil și pentru arcurile de interfață - ele reprezintă, de asemenea, setul complet de interfețe externe ale sistemului ca întreg.

Apoi blocul care reprezintă sistemul ca un singur modul este detaliat într-o altă diagramă folosind mai multe blocuri conectate prin arcuri de interfață. Aceste blocuri reprezintă principalele subfuncții ale funcției originale. Această descompunere dezvăluie un set complet de subfuncții, fiecare dintre acestea fiind reprezentată ca un bloc, ale căror limite sunt definite de arce de interfață. Fiecare dintre aceste sub-funcții poate fi descompusă într-un mod similar pentru o vedere mai detaliată.

În toate cazurile, fiecare subfuncție poate conține doar acele elemente care sunt incluse în funcția originală. De asemenea, modelul nu poate omite niciun element, adică, după cum sa menționat, blocul părinte și interfețele sale oferă context. Nimic nu poate fi adăugat la el și nimic nu poate fi îndepărtat din el.

Arcuri care intră și ies dintr-un bloc într-o diagramă nivel superior, sunt exact aceleași cu arcele care intră și ies din diagrama de nivel inferior, deoarece blocul și diagrama reprezintă aceeași parte a sistemului.

Figura 7.6 - Structura modelului SADT. Descompunerea diagramei

Figura 7.7 - Conformitatea trebuie să fie completă și consecventă

Unele arce sunt atașate casetelor de diagramă la ambele capete, în timp ce altele au un capăt lăsat neatașat. Arcurile neconectate corespund intrărilor, comenzilor și ieșirilor blocului părinte. Sursa sau destinația acestor arce de limită poate fi găsită numai în diagrama părinte. Capetele neatașate trebuie să se potrivească cu arcurile din diagrama originală. Toate arcurile de graniță trebuie să continue pe diagrama părinte pentru ca aceasta să fie completă și consecventă.

După cum sa menționat, mecanismele (arcurile de pe partea inferioară) arată mijloacele prin care sunt îndeplinite funcțiile. Mecanismul poate fi un om, un computer sau orice alt dispozitiv care ajută la această funcție (figura 7.8).

Orez. 7.8. Exemplu de mecanism

Fiecare bloc din diagramă are propriul său număr. Un bloc al oricărei diagrame poate fi descris în continuare printr-o diagramă de nivel inferior, care, la rândul său, poate fi detaliată cu numărul necesar de diagrame. Astfel, se formează o ierarhie de diagrame.

Pentru a indica poziția oricărei diagrame sau bloc în ierarhie, sunt folosite numerele diagramei. De exemplu, A21 este o diagramă care detaliază caseta 1 din diagrama A2. În mod similar, A2 detaliază caseta 2 din diagrama A0, care este diagrama cea mai de sus a modelului. Figura 7.9 prezintă un arbore diagramă tipic.

Figura 7.9 - Ierarhia diagramelor

Curs 8. MetodologiiDFDȘiIDEF3

Scopul lucrării:

• studierea principiilor de bază ale metodologiei IDEF0,
• crearea unui nou proiect în BPWin,
• formarea unei diagrame de context,
• a face legături.

Descrierea unui sistem folosind IDEF0 se numește model funcțional. Modelul funcțional este destinat să descrie procesele de afaceri existente, care utilizează atât limbaje naturale, cât și limbaje grafice. Pentru a transmite informații despre un anumit sistem, sursa limbajului grafic este însăși metodologia IDEF0.

Metodologia IDEF0 prescrie construirea unui sistem ierarhic de diagrame - descrieri unice ale fragmentelor de sistem. În primul rând, se realizează o descriere a sistemului în ansamblu și a interacțiunii sale cu lumea exterioară (diagrama contextului), după care se efectuează o descompunere funcțională - sistemul este împărțit în subsisteme și fiecare subsistem este descris separat (diagrame de descompunere) . Apoi fiecare subsistem este împărțit în altele mai mici și așa mai departe până când se atinge gradul de detaliu necesar.

Fiecare IDEF0-diagrame a conține blocuri și arce. Blocurile reprezintă funcțiile sistemului simulat. Arcurile leagă blocuri între ele și afișează interacțiunile și relațiile dintre ele.

Blocurile funcționale (lucrările) din diagrame sunt reprezentate prin dreptunghiuri, adică procese numite, funcții sau sarcini care apar într-un anumit timp și au rezultate recognoscibile. Numele lucrării trebuie exprimat ca un substantiv verbal care denotă acțiunea.

IDEF0 necesită ca diagrama să aibă cel puțin trei și nu mai mult de șase casete. Aceste constrângeri mențin complexitatea diagramelor și modelelor la un nivel care poate fi citit, înțeles și utilizat.

Fiecare parte a blocului are un scop specific, bine definit. Partea stângă a blocului este pentru intrări, cea de sus este pentru control, cea din dreapta este pentru ieșiri, cea de jos este pentru mecanisme. O astfel de desemnare reflectă anumite principii de sistem: intrările sunt convertite în ieșiri; controlează limitează sau prescrie condițiile pentru efectuarea transformărilor; mecanismele arată ce și cum funcționează o funcție.

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 ale diagramei. De exemplu, cel mai dominant bloc din diagramă poate fi fie primul dintr-o succesiune de funcții cerute, fie o funcție de planificare sau control care le influențează pe toate celelalte.

Caseta cea mai dominantă este de obicei plasată în colțul din stânga sus al diagramei, în timp ce caseta cea mai puțin dominantă este plasată în colțul din dreapta.

Dispunerea blocurilor pe pagină reflectă definiția autorului a dominației. Astfel, topologia diagramei arată care caracteristici au un impact mai mare asupra celorlalte. Pentru a sublinia acest lucru, analistul poate renumerota blocurile în funcție de ordinea lor de dominanță. Ordinea dominației poate fi indicată printr-un număr plasat în colțul din dreapta jos al fiecărei casete: 1 ar indica cea mai mare dominanță, 2 următorul și așa mai departe.

Interacțiunea lucrărilor cu lumea exterioară și între ele este descrisă sub formă de săgeți reprezentate de linii unice cu săgeți la capete. Săgețile reprezintă unele informații și se numesc substantive.

Tipuri de săgeți

IDEF0 distinge între cinci tipuri de săgeți.

Intrare- obiecte folosite și transformate de lucrare pentru a obține un rezultat (ieșire). Este permis ca lucrarea să nu aibă nicio săgeată de intrare. Săgeata de intrare este desenată ca intrând în partea stângă a jobului.

Control-.informație, gestionarea actiunilor muncă. De obicei, săgețile de control poartă informații care indică ceea ce trebuie să facă. Fiecare job trebuie să aibă cel puțin o săgeată de control, care este afișată ca intrând în partea superioară a jobului.

Ieșire- obiecte în care sunt convertite intrările. Fiecare job trebuie să aibă cel puțin o săgeată de ieșire, care este desenată ca venind din partea dreaptă a jobului.

Mecanism- Resurse care fac treaba. Săgeata mecanismului este desenată ca intrând în fața inferioară a lucrării. La discreția analistului, săgețile mecanismului pot să nu fie afișate pe model.

Apel- o săgeată specială care indică un alt model de lucru. Săgeata de apel este desenată ca venind din partea de jos a lucrării și este folosită pentru a indica faptul că unele lucrări sunt efectuate în afara sistemului simulat.

Orez. 2.1 Tipuri de săgeți

În metodologia IDEF0, sunt necesare doar cinci tipuri de interacțiuni între blocuri pentru a descrie relațiile lor: control, intrare, feedback de control, feedback de intrare, mecanism de ieșire. Relațiile de control și intrare sunt cele mai simple, deoarece reflectă acțiuni directe intuitive și foarte simple.

Orez. 2.2. Comunicare de ieșire

Orez. 2.3. Comunicarea managementului

O relație de control are loc atunci când ieșirea unui bloc afectează direct un bloc cu mai puțină dominanță.

Feedback-ul de control și feedback-ul de intrare sunt mai complexe, deoarece sunt iterative sau recursive. Și anume, rezultatele unui job afectează execuția viitoare a altor joburi, care ulterior vor afecta jobul inițial.

Feedback-ul de control are loc atunci; când ieșirea unui bloc afectează un bloc cu mai multă dominanță.

Relațiile cu mecanismul de ieșire sunt rare. Ele reflectă o situație în care rezultatul unei funcții devine un mijloc pentru un scop pentru alta.

Orez. 2.4. Feedback de intrare

Orez. 2.5. Feedback de management

Legăturile producție-mecanism sunt caracteristice alocării surselor de resurse (de exemplu, instrumentele necesare, personal instruit, spațiu fizic, echipamente, finanțare, materiale).

În IDEF0, un arc rareori descrie un singur obiect. De obicei simbolizează un set de obiecte. Deoarece arcurile reprezintă colecții de obiecte, ele pot avea mai multe puncte de început (surse) și puncte de sfârșit (destinații). Prin urmare, arcurile se pot ramifica și se pot conecta căi diferite. Întregul arc sau o parte a acestuia poate ieși dintr-unul sau mai multe blocuri și se poate termina în unul sau mai multe blocuri.

Ramificarea arcelor, reprezentată ca linii divergente, înseamnă că tot sau o parte din conținutul arcelor poate apărea în fiecare ramură. Un arc este întotdeauna etichetat înaintea unei ramuri pentru a da un nume întregului set. În plus, fiecare ramură a unui arc poate fi sau nu etichetată conform următoarelor reguli:

• ramurile neetichetate conțin greutatea obiectelor specificate în eticheta arcului înainte de ramificare;
• ramurile etichetate după un punct de ramificare conțin toate sau o parte din obiectele specificate în eticheta arcului înainte de ramificare.

Îmbinările arcului în IDEFO, prezentate ca linii care converg împreună, indică faptul că conținutul fiecărei ramuri formează o etichetă pentru arcul rezultat din îmbinarea arcelor originale. După o îmbinare, arcul rezultat este întotdeauna marcat pentru a indica noul set de caracteristici care au apărut după îmbinare. În plus, fiecare ramură poate fi sau nu semnalizată înainte de fuziune, conform următoarelor reguli:

Orez. 2.6. Conexiune ieșire-mecanism

• ramurile neetichetate conțin greutatea obiectelor specificate în eticheta arcului comun după îmbinare;
• ramurile marcate înainte de îmbinare conțin toate sau unele dintre obiectele enumerate în marcajul comun după îmbinare,

Analiza grafică cantitativă

Pentru a efectua o analiză cantitativă a diagramelor, listăm indicatorii modelului:

• numărul de blocuri pe diagramă - N;
• nivel de descompunere a diagramei - L;
• sold grafic - ÎN;
• numărul de săgeți conectate la bloc - A

Acest set de factori se aplică fiecărei diagrame model. Următoarele vor enumera recomandări pentru valorile dorite ale factorilor graficului.

Este necesar să ne străduim să ne asigurăm că numărul de blocuri de pe diagramele nivelurilor inferioare ar fi mai mic decât numărul de blocuri de pe diagramele părinte, adică, cu o creștere a nivelului de descompunere, coeficientul ar scădea. Astfel, scăderea acestui coeficient indică faptul că. că pe măsură ce modelul este descompus, funcțiile ar trebui simplificate, prin urmare, numărul de blocuri ar trebui să scadă.

Graficele trebuie să fie echilibrate. Aceasta înseamnă că în cadrul unei diagrame, situația prezentată în Fig. 2.7: jobul 1 are mult mai multe săgeți de intrare și de control decât cele care ies. Trebuie remarcat faptul că această recomandare poate să nu fie implementată în modelele care descriu Procese 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 săgeată poate ieși - produsul finit.

Orez. 2.7. Un exemplu de grafic dezechilibrat

Să introducem coeficientul de echilibru al diagramei

Este necesar să ne străduim să ky a fost minimul pentru grafic.

Pe lângă analiza elementelor grafice ale diagramei, este necesar să se ia în considerare denumirile blocurilor. Pentru a evalua numele, este alcătuit un dicționar de funcții elementare (triviale) ale sistemului simulat. De fapt, funcțiile de descompunere de nivel inferior a diagramelor ar trebui să se încadreze în acest dicționar. De exemplu, pentru un model de bază de date, funcțiile „găsiți o înregistrare”, „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 vocabularului și compilarea unui pachet de diagrame de sistem, este necesar să se ia în considerare nivelul inferior al modelului. Dacă arată o potrivire între numele blocurilor de diagrame și cuvintele din dicționar, atunci aceasta indică faptul că a fost atins un nivel suficient de descompunere. Coeficientul care reflectă cantitativ acest criteriu poate fi scris ca L*C- produsul nivelului de model prin 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 potrivitele sunt mai valoroase.

Setul de instrumente BPWin

Când porniți BPWin, bara de instrumente principală, paleta de instrumente și Model Explorer apar în mod implicit.

La crearea unui model nou, apare un dialog în care trebuie să specificați dacă modelul va fi creat din nou, sau va fi deschis din depozitul ModelMart, introduceți numele modelului și selectați metodologia în care va fi construit modelul ( Fig. 2.8).

Fig.2.8 Dialog de creare a modelului

BPWin acceptă trei metodologii - IDEF0, IDEF3 și DFD. În BPWin, este posibil să se construiască modele mixte, adică un model poate conține atât diagrame IDEF0, IDEF3 și DFD în același timp. Compoziția paletei de instrumente se schimbă automat la trecerea de la o notație la alta.

Un model în BPWin este văzut ca o colecție de activități, fiecare dintre ele funcționând pe un anumit set de date. Dacă faceți clic pe orice obiect al modelului cu butonul stâng al mouse-ului, apare un meniu contextual pop-up, fiecare articol corespunzător editorului unei proprietăți a obiectului.

Exemplu

Construirea unui model de sistem ar trebui să înceapă cu studiul tuturor documentelor care îl descriu. funcţionalitate. Unul dintre aceste documente este termenii de referință, respectiv secțiunile „Scopul dezvoltării”, „Scopul și obiectivele sistemului” și „Caracteristicile funcționale ale sistemului”.

După studierea documentelor sursă și intervievarea clienților și utilizatorilor sistemului, este necesar să se formuleze scopul modelării și să se determine punctul de vedere asupra modelului. Luați în considerare tehnologia construcției sale pe exemplul sistemului „Serviciul de ocupare a forței de muncă în cadrul universității”, ale cărui principale caracteristici au fost descrise în munca de laborator № 1.

Să formulăm scopul modelării: să descriem funcționarea sistemului, care ar fi de înțeles utilizatorului său, fără a intra în detalii legate de implementare. Vom construi modelul din punctul de vedere al utilizatorilor (student, profesor, administrator, decanat, firmă).

Să începem cu construirea unei diagrame de context IDEF0. Conform descrierii sistemului, funcția principală este de a-și servi clienții prin procesarea cererilor de la aceștia. Astfel, definim singurul loc de muncă diagramă de context ca „Serve System Client”. În continuare, definim datele de intrare și de ieșire, precum și mecanismele și controlul.

Pentru a deservi un client, este necesar să îl înregistrați în sistem, să deschideți accesul la baza de date și să procesați cererea acestuia. Datele de intrare vor fi „nume client”, „parolă client”, „bază de date inițială”, „cerere client”. Executarea unei interogări duce fie la obținerea de informații din sistem, fie la modificarea conținutului bazei de date (de exemplu, la compilare evaluări ale experților), deci rezultatul va fi „rapoarte” și „bază de date modificată”. Procesul de procesare a cererii va fi efectuat de monitorul sistemului sub controlul administratorului.

Diagrama de context

Astfel, definim diagrama de context a sistemului (Fig. 2.9).

Fig 2.9. Diagrama contextului sistemului

Să descompunăm diagrama de context prin descrierea secvenței serviciului clienți:

• Determinarea nivelului de acces la sistem.
• Selectarea subsistemului.
• Acces la un subsistem.
• Modificarea bazei de date (dacă este necesar).

Obținem diagrama prezentată în fig. 2.10.

După ce au finalizat descompunerea diagramei de context, aceștia trec la descompunerea diagramei de la nivelul următor. De obicei, atunci când se iau în considerare nivelul al treilea și inferior, modelele revin la diagramele părinte și le corectează.

Orez. 2.10. Descompunerea lucrării „Deservire, clientul sistemului”

Descompunem secvenţial toate blocurile diagramei rezultate. Primul pas în determinarea nivelului de acces la sistem este determinarea categoriei de utilizatori. După numele clientului se efectuează o căutare în baza de date a utilizatorilor, determinându-se categoria acestuia. Potrivit unei anumite categorii, puterile acordate utilizatorului sistemului sunt clarificate. În continuare, se efectuează procedura de accesare a sistemului, verificând numele și parola de acces. Combinând informații despre permisiuni și nivelul de acces la sistem, se formează un set de acțiuni permise pentru utilizator. Astfel, definirea nivelului de acces la sistem va arăta ca cea prezentată în Fig. 2.11.

Orez. 2.11. Descompunerea lucrării „Determinarea nivelului de acces la sistem”

După parcurgerea procedurii de acces la sistem, monitorul analizează cererea clientului, alegând un subsistem care va procesa cererea. Descompunerea lucrării „Referire la un subsistem” nu corespunde scopului și punctului de vedere al modelului. Utilizatorul sistemului nu este interesat algoritmi interni munca ei. În acest caz, este important pentru el ca alegerea subsistemului să se facă automat, fără intervenția lui, așa că descompunerea apelului la subsistem nu va face decât să complice modelul.

Să descompunem lucrarea „Procesarea cererii clientului”, efectuată de subsistemul pentru procesarea cererilor, determinarea categoriilor și a permisiunilor utilizatorului. Înainte de a căuta un răspuns la o interogare, trebuie să deschideți baza de date (conectați-vă la ea). În general, baza de date poate fi localizată pe server la distanta, așa că poate fi necesar să stabiliți o conexiune cu acesta. Să definim succesiunea de lucru:

• Deschiderea bazei de date.
• Executarea unei cereri.
• Generarea rapoartelor.

După deschiderea bazei de date, trebuie să informați sistemul despre stabilirea unei conexiuni la baza de date, apoi să executați interogarea și să generați rapoarte pentru utilizator (Fig. 2.12).

Trebuie remarcat faptul că „Executarea cererii” include activitatea diferitelor subsisteme. De exemplu, dacă o solicitare include testare, atunci aceasta va fi executată de un subsistem de teste profesionale și psihologice. În etapa de execuție a interogării, poate fi necesară modificarea conținutului bazei de date, de exemplu, la compilarea evaluărilor experților. Prin urmare, este necesar să se prevadă o astfel de posibilitate pe diagramă.

Orez. 2.12.

Ajustarea graficului

La analiza diagramei rezultate se pune întrebarea, după ce reguli se generează rapoartele? Este necesar să existe șabloane preformate care vor fi folosite pentru a selecta din baza de date, iar aceste șabloane trebuie să corespundă interogărilor și să fie predefinite. În plus, clientului ar trebui să i se ofere posibilitatea de a alege forma raportului.

Să corectăm diagrama adăugând săgețile „Șabloane de raport” și „Solicitări de modificare a bazei de date” și săgeata tunel „Client de sistem”. S-a aplicat tunelarea „Clientului de sistem” pentru a nu plasa săgeata pe diagrama de sus, deoarece funcția de selectare a formularului de raport nu este suficient de importantă pentru a-l afișa pe diagrama părinte.

Schimbarea diagramei va presupune ajustarea tuturor diagramelor părinte (Fig. 2.13 - 2.15).

Este recomandabil să descompuneți lucrarea „Execuție interogări” folosind diagrama DFD (lucrare de laborator nr. 3), deoarece metodologia IDEF0 consideră sistemul ca un set de lucrări interconectate, care reflectă slab procesele de prelucrare a informațiilor.

Orez. 2.13. Descompunerea lucrării „Prelucrarea cererii clientului”

Orez. 2.14. Descompunerea lucrării „Deservirea clientului sistemului” (opțiunea 2)

Orez. 2.15. Diagrama contextului sistemului (opțiunea 2)

Să trecem la descompunerea ultimului bloc „Schimbarea bazei de date”. Din punctul de vedere al clientului, aceste sisteme sunt situate într-o singură bază de date. În realitate, există șase baze de date în sistem:

• baza de date a utilizatorilor,
• baza de date a elevilor, (opțiunea 2)
• baza de date a posturilor vacante,
• baza de date de progres,
• baza de date de testare,
• DB de evaluări de experți,
• Rezumat DB.

Conform scopului modelării, este important ca clientul să înțeleagă că datele primite nu sunt actualizate imediat în sistem, ci trec printr-o etapă suplimentară de prelucrare și control. Algoritmul de schimbare poate fi formulat după cum urmează:

• Este determinată baza de date în care vor fi modificate informațiile.
• Operatorul formează un set de date temporar și îl furnizează administratorului.
• Administratorul controlează datele și le introduce în baza de date.

Acest model poate fi implementat într-un mod diferit, oferind posibilitatea de a actualiza baza de date direct la cerere, ocolind procesul de control al datelor. În acest caz, este necesar să se asigure integritatea bazei de date pentru a evita deteriorarea acesteia. În acest caz, diagrama va arăta astfel (Fig. 2.17).

Orez. 2.16. Descompunerea lucrării „Schimbarea bazei de date”

Orez. 2.17. Descompunerea lucrării „Modificarea bazei de date” (opțiunea 2) Pentru prima opțiune prezentată în Fig. 2.12

Efectuarea descompunerii ulterioare „Modificări la baza de date” va complica modelul, explicând modul în care se realizează modificarea fizică a bazei de date în sistem. În acest caz, utilizatorul nu va primi niciunul Informații suplimentare despre activitatea sistemului de servicii de ocupare a forței de muncă. Descompunerea acestei lucrări ar trebui efectuată în procesul de proiectare a unui sistem de baze de date în etapa creării unui model de bază de date logică.

O descompunere a lucrării de execuție a interogării va fi făcută în laboratorul următor, ilustrând aplicarea lui Diagrame DFD pentru a descrie procesele de prelucrare a informaţiei.

Să cheltuim analiza cantitativa modelele prezentate în fig. 2.12 și 2.13, conform metodei descrise mai sus. Luați în considerare comportamentul coeficientului ^ pentru aceste modele. Diagrama părinte „Procesarea cererii unui client” are un coeficient de 4/2 = 2, iar diagramele de descompunere de 3/3 = 1. Valoarea coeficientului scade, ceea ce indică faptul că descrierea funcțiilor este simplificată cu o scădere a nivelului de modelul.

Luați în considerare modificarea coeficientului K b in doua modele.

pentru a doua varianta

Coeficient K b nu își modifică valoarea, prin urmare, echilibrul diagramei nu se modifică.

Presupunem că nivelul de descompunere a diagramelor luate în considerare este suficient pentru a reflecta scopul modelării, iar pe diagramele Nivelului inferior sunt folosite funcții elementare ca denumiri de lucrări (din punctul de vedere al utilizatorului de sistem).

Rezumând exemplul luat în considerare, este necesar să remarcăm importanța luării în considerare a mai multor opțiuni pentru diagrame la modelarea unui sistem. Astfel de opțiuni pot apărea la ajustarea diagramelor, așa cum s-a făcut cu „Procesarea unei cereri de client” sau la crearea unor implementări alternative ale funcțiilor sistemului (descompunerea lucrării „Modificarea bazei de date”). Luarea în considerare a opțiunilor vă permite să selectați cea mai bună și să o includeți în pachetul de diagrame pentru o analiză suplimentară.

Întrebări de control

Listă Intrebari de securitate:

1. Ce este un model în notația IDEF0?
2. Ce înseamnă locuri de muncă în IDEF0?
3. Care este ordinea denumirii lucrărilor?
4. Câte locuri de muncă ar trebui să fie pe o diagramă?
5. Care este ordinea dominantei?
6. Cum sunt aranjate locurile de muncă după principiul dominației?
7. Care este scopul laturilor dreptunghiurilor de lucru din diagrame?
8. Enumerați tipurile de săgeți.
9. Numiți tipurile de relații.
10. Ce sunt săgețile de delimitare?
11. Explicați principiul denumirii săgeților de ramificare și îmbinare.
12. Ce metodologii sunt acceptate de BPWin?
13. Enumerați elementele principale ale ferestrei principale BPWin.
14. Descrieți procesul de creare a unui nou model în BPWin.
15. Cum să faci legătura între locuri de muncă?
16. Cum să setați un nume de job.
17. Descrieți procesul de descompunere a lucrării.
18. Cum se adaugă lucru la diagramă?
19. Cum să rezolvi săgețile tunelizate?
20. Poate un model BPWin să conțină diagrame de metodologii multiple?

În etapele inițiale ale creării unui SI, este necesar să înțelegem cum funcționează organizația care urmează să fie automatizată. Nimeni din organizație nu știe cum funcționează în măsura în care este necesar pentru a crea un IS. Managerul cunoaște bine munca în general, dar nu este capabil să aprofundeze detaliile muncii fiecărui angajat obișnuit. Un angajat obișnuit știe bine ce se întâmplă la locul său de muncă, dar nu știe cum lucrează colegii săi. Prin urmare, pentru a descrie funcționarea întreprinderii, este necesar să se construiască un model. Un astfel de model ar trebui să fie adecvat domeniului subiectului, prin urmare, ar trebui să conțină cunoștințele tuturor participanților la procesele de afaceri ale organizației.

Cel mai convenabil limbaj de modelare a proceselor de afaceri este IDEF0, propus acum mai bine de 20 de ani de Douglas Ross (SoftTech, Inc.) și numit inițial SADT - Structured Analysis and Design Technique. (La începutul anilor 1970, armata SUA a folosit subsetul de modelare a proceselor SADT pentru a implementa proiecte în cadrul programului Integrated Computer-Aided Manufacturing (ICAM). Ulterior, acest subset de SADT a fost adoptat ca standard federal american sub numele IDEF0. Detaliat Specificațiile pentru standardele IDEF pot fi găsite la http://www.idef.com.

În IDEF0, un sistem este reprezentat ca un set de activități sau funcții care interacționează. O astfel de orientare pur funcțională este fundamentală - funcțiile sistemului sunt analizate independent de obiectele pe care operează. Acest lucru vă permite să modelați mai clar logica și interacțiunea proceselor organizației.

Conform modelului din IDEF0 înțelegeți descrierea sistemului (textual și grafic), care ar trebui să dea un răspuns la unele întrebări prestabilite.

Sistemul simulat este considerat un subset arbitrar al Universului. Arbitrar pentru că, în primul rând, noi înșine determinăm în mod speculativ dacă un anumit obiect va fi o componentă a sistemului, sau îl vom considera ca o influență externă și, în al doilea rând, depinde de punctul de vedere asupra sistemului. Sistemul are o graniță care îl separă de restul universului. Interacțiunea sistemului cu lumea exterioară este descrisă ca intrare (ceva care este procesat de sistem), ieșire (rezultatul activității sistemului), control (strategiile și procedurile în care se lucrează) și mecanism (resursele necesare). a efectua munca). În timp ce este sub control, sistemul convertește intrările în ieșiri folosind mecanisme.

Procesul de modelare a oricărui sistem în IDEF0 începe cu definirea contextului, adică cel mai abstract nivel de descriere a sistemului ca întreg. Contextul include definirea subiectului modelării, scopul și punctul de vedere al modelului.

Subiectul este înțeles ca sistemul însuși, în timp ce este necesar să se stabilească exact ce este inclus în sistem și ce se află în afara acestuia, cu alte cuvinte, trebuie să stabilim ce vom considera în continuare componente ale sistemului și ce ca un influență externă. Definirea subiectului sistemului va fi influențată semnificativ de poziția din care este considerat sistemul și de scopul modelării - întrebări la care modelul construit trebuie să răspundă. Cu alte cuvinte, inițial este necesar să se determine aria (Scopul) modelării. Descrierea zonei atât a sistemului în ansamblu, cât și a componentelor sale este baza pentru construirea modelului. Deși se presupune că aria poate fi ajustată în timpul simulării, în general, aceasta ar trebui formulată inițial, deoarece zona este cea care determină direcția simulării și momentul în care modelul trebuie finalizat. La formularea unei zone, trebuie luate în considerare două componente - lățimea și adâncimea. Lățimea înseamnă definirea limitelor modelului - definim ceea ce va fi considerat în interiorul sistemului și ce va fi în exterior. Adâncimea determină la ce nivel de detaliu este complet modelul. Atunci când se determină adâncimea sistemului, nu trebuie să uităm de constrângerile de timp - complexitatea construirii unui model crește exponențial de la adâncimea de descompunere. După definirea limitelor modelului, se presupune că noi obiecte nu trebuie introduse în sistemul modelat; deoarece toate obiectele model sunt interconectate, introducerea unui nou obiect poate să nu fie doar o adunare aritmetică, ci poate schimba relațiile existente. Efectuarea unor astfel de modificări la modelul finit este de obicei un proces care consumă foarte mult timp (așa-numita problemă a „zonei plutitoare”).

Scopul simulării (Scopul). Un model nu poate fi construit fără un scop clar definit. Scopul ar trebui să răspundă la următoarele întrebări:

De ce ar trebui modelat acest proces?

Ce ar trebui să arate modelul?

Ce poate obține cititorul?

Stabilirea obiectivelor permite echipei de analiză să concentreze eforturile în direcția corectă. Exemple de declarații de obiective ar putea fi: „Identificați și definiți problemele curente, permiteți analiza potențialelor îmbunătățiri”, „Identificați rolurile și responsabilitățile angajaților pentru scrierea fișelor postului”, „Descrieți funcționalitatea întreprinderii în scopul scrierii specificațiilor sistemului informatic. ", etc.

Punct de vedere. Deși punctele de vedere ale diferitelor persoane sunt luate în considerare la construirea unui model, modelul ar trebui să fie construit dintr-un singur punct de vedere. Punctul de vedere poate fi reprezentat ca viziunea unei persoane care vede sistemul în aspectul necesar modelării. Punctul de vedere trebuie să fie în concordanță cu scopul simulării. Este evident că descrierea activității întreprinderii din punctul de vedere al finanțatorului și al tehnologului va arăta complet diferit, așa că în timpul simulării este important să rămânem pe punctul de vedere ales. De regulă, se alege punctul de vedere al persoanei responsabile pentru lucrarea modelată în ansamblu. Adesea, atunci când alegeți un punct de vedere pentru un model, este important să documentați puncte de vedere alternative suplimentare. În acest scop, sunt utilizate de obicei diagramele FEO (For Exposition Only).

Modelul IDEF0 presupune prezența unui scop clar definit, a unui singur subiect de modelare și a unui punct de vedere. Pentru a introduce zona, obiectivul și punctul de vedere în modelul IDEF0 în BPwin, selectați elementul de meniu Editați/Proprietățile modelului, care apelează dialogul Proprietăți model (Fig. 4). Marcat Scop ar trebui să introduceți obiectivul și punctul de vedere și marcați Definiție- definirea modelului si descrierea zonei.

Marcat stareÎn același dialog, puteți descrie starea modelului (versiunea schiță, versiunea de lucru, versiunea finală etc.), ora creării și ultima editare (urmărită automat în viitor până la data sistemului). Marcat Sursă Sunt descrise sursele de informații pentru construirea modelului (de exemplu, „Sondajul experților în domeniu și analiza documentației”). Marcaj General servește pentru a introduce numele proiectului și modelului, numele și inițialele autorului și intervalul de timp al modelului - Așa cum esteȘi A FI.

Orez. 4. Dialog pentru setarea proprietăților modelului

Modelele AS-IS și TO-BE. De obicei, se construiește mai întâi un model al organizării existente a muncii - AS-IS (ca atare). Pe baza modelului AS-IS, se ajunge la un consens între diferite unități de afaceri cu privire la „cine a făcut ce” și ce adaugă fiecare unitate de afaceri procesului. Modelul AS-IS vă permite să vă dați seama „ce facem astăzi” înainte de a trece la „ce vom face mâine”. Analiza modelului funcțional vă permite să înțelegeți unde sunt punctele cele mai slabe, care vor fi avantajele noilor procese de afaceri și cât de profunde vor fi aduse structurii existente a organizației de afaceri. Detalierea proceselor de afaceri vă permite să identificați deficiențele organizației, chiar și acolo unde funcționalitatea la prima vedere pare evidentă. Semnele unei activități ineficiente pot fi munca inutilă, negestionată și duplicată, fluxul de lucru ineficient (documentul potrivit nu este la locul potrivit la momentul potrivit), lipsa feedback-ului managementului (lucrarea nu este afectată de rezultatul său), intrare (obiecte sau informațiile sunt utilizate irațional ), etc. Neajunsurile găsite în modelul AS-IS pot fi corectate la crearea unui model TO-BE (cum va fi) - un model al unei noi organizări a proceselor de afaceri. Modelul este necesar de către TO-BE pentru a analiza modalități alternative/mai bune de a lucra și pentru a documenta modul în care compania va face afaceri în viitor.

O greșeală comună de făcut atunci când se creează un model AS-IS trebuie subliniată este crearea unui model idealizat. Un exemplu este crearea unui model bazat pe cunoștințele managerului, și nu a unui anumit executant de muncă. Managerul este familiarizat cu modul în care ar trebui să se desfășoare munca conform manualelor și fișelor postului și adesea nu știe cum realizează subordonații munca de rutină. Rezultatul este un model înfrumusețat, distorsionat, care conține informații false și care nu poate fi folosit în continuare pentru analiză. Un astfel de model se numește SHOULD_BE (cum ar trebui să fie).

Tehnologia de proiectare IS presupune mai întâi crearea unui model AS-IS, analiza acestuia și îmbunătățirea proceselor de business, adică crearea unui model TO-BE, și numai pe baza modelului TO-BE un model de date, un prototip iar apoi sunt construite versiunea finală a IS. Construirea unui sistem bazat pe modelul AS-IS duce la automatizarea întreprinderii conform principiului „lasă totul așa cum este, doar pentru ca computerele să stea”, adică IS automatizează procesele de afaceri imperfecte și dublează, mai degrabă decât înlocuiește, fluxul de lucru existent. Ca urmare, implementarea și funcționarea unui astfel de sistem nu duc decât la costuri suplimentare pentru achiziționarea de echipamente, crearea de software și întreținerea ambelor.

Uneori, actualele modele AS-IS și viitoarele TO-BE sunt foarte diferite, astfel încât trecerea de la starea inițială la cea finală devine neevidentă. În acest caz, este nevoie de un al treilea model care să descrie procesul de tranziție de la starea inițială la cea finală a sistemului, deoarece o astfel de tranziție este și un proces de afaceri.

Rezultatul descrierii modelului poate fi obținut în raport Raport model. Dialogul de configurare a raportului de model este apelat din elementul de meniu Raport/Model de raport. În dialogul de setări, selectați câmpurile necesare și este afișată automat ordinea în care informațiile sunt transmise în raport (Fig. 5).

Orez. 5. Model de raport

IDEF0 Diagrame. Metodologia IDEF0 se bazează pe un limbaj grafic pentru descrierea proceselor de afaceri. Un model în notația IDEF0 este o colecție de diagrame ordonate ierarhic și interconectate. Fiecare diagramă este o unitate de descriere a sistemului și se află pe o foaie separată.

Un model poate conține patru tipuri de diagrame:

diagramă de context (fiecare model poate avea o singură diagramă de context);

diagrame de descompunere;

diagrame arbore de noduri;

diagrame numai pentru expunere (FEO).

Diagrama de context este partea de sus a structurii arborelui diagramei și reprezintă cea mai generală descriere a sistemului și interacțiunea acestuia cu Mediul extern. După descrierea sistemului ca întreg, acesta este împărțit în fragmente mari. Acest proces se numește descompunere funcțională, iar diagramele care descriu fiecare fragment și interacțiunea fragmentelor se numesc diagrame de descompunere. După descompunerea diagramei de context, fiecare fragment mare al sistemului este descompus în altele mai mici și așa mai departe, până la atingerea nivelului dorit de detaliere a descrierii. După fiecare sesiune de descompunere, au loc sesiuni de examinare - experții în materie indică corespondența proceselor reale de afaceri cu diagramele create. Neconcordanțele găsite sunt corectate și numai după ce ați trecut examenul fără 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. Sintaxa pentru descrierea sistemului ca întreg și a fiecărui fragment al acestuia este aceeași pe tot modelul.

Diagrama arborelui nodului arată dependența ierarhică a activităților, dar nu și relațiile dintre activități. În model poate exista un număr arbitrar de mare de diagrame arbore de noduri, deoarece arborele poate fi construit la o adâncime arbitrară și nu neapărat de la rădăcină.

Diagramele de expunere (FEO) sunt construite pentru a ilustra fragmente individuale ale unui model, pentru a ilustra un punct de vedere alternativ sau pentru scopuri speciale.

Un exemplu de creare a unui model funcțional.

De exemplu, sunt luate în considerare activitățile companiei fictive „Computer Word”. Compania se ocupă în principal de asamblarea și vânzarea de computere desktop și laptopuri. Compania nu produce componente pe cont propriu, ci doar asamblează și testează computere.

Principalele tipuri de muncă în companie sunt următoarele:

vânzătorii preiau comenzile clienților;

operatorii grupează comenzile după tipul computerului;

operatorii asamblează și testează calculatoare;

operatorii ambalează calculatoarele conform comenzilor;

depozitarul expediază comenzile către clienți.

Compania folosește un sistem de informații contabile licențiat care vă permite să plasați o comandă, să facturați și să urmăriți plățile pe facturi.

Metodologia de realizare a muncii

1. Rulați BPwin().

2. Dacă apare un dialog Manager de conexiune ModelMart, faceți clic pe butonul Anulare(Anulare).

3. Faceți clic pe butonul . Apare o casetă de dialog Aș dori să(Fig. 6). Introduceți în câmpul de text Nume numele modelului „Activități ale companiei” și selectați Tip − Proces de afaceri (IDEF0). Faceți clic pe butonul Bine.

Orez. 6. Numirea modelului și selectarea tipului de model

4. Se va deschide o casetă de dialog Proprietăți pentru modele noi(Proprietățile noului model) (Fig. 7). Introduceți în câmpul de text Autor(Autor) numele autorului modelului și în câmpul de text Inițialele autorului initialele lui. Apăsați succesiv butoanele aplicaȘi Bine.

5. Se creează automat o diagramă de context goală (Fig. 8).

6. Acordați atenție butonului de pe bara de instrumente. Acest buton activează și dezactivează instrumentul de navigare și navigare - Model Explorer(Model Browser). Model Explorer are trei file - Activități (), Diagrame() Și Obiecte(). În fila Activități făcând clic dreapta pe un obiect din browserul modelului vă permite să selectați opțiuni pentru editarea proprietăților acestuia (Fig. 9).

Orez. 8. Diagrama de context goală

Orez. 9. Făcând clic dreapta pe un obiect din fila Activități, vă permite să utilizați meniul contextual pentru a-i edita proprietățile

7. Accesați meniul Model/Proprietăți model. În fila General căsuță de dialog Proprietățile modeluluiîn câmpul de text numele modelului ar trebui să introduceți numele modelului „Activități ale companiei”, iar în câmpul de text proiect denumirea proiectului „Model de activitate a companiei”, și, în final, în text interval de timp(acoperire de timp) - Așa cum este(Așa cum este) (Fig. 10).

Orez. 10. Fereastra pentru setarea proprietăților modelului

8. Tab Scop căsuță de dialog Proprietățile modeluluiîn câmpul de text Scop(scop) introduceți date despre scopul dezvoltării modelului - „Modelează procesele de afaceri curente (AS-IS) ale companiei”, iar în câmpul de text Punct de vedere(punct de vedere) - „Director” (Fig. 11).

Orez. 11. Introducerea datelor cu privire la scopul modelării și punct de vedere

9. Tab Definiție căsuță de dialog Proprietățile modeluluiîn câmpul de text Definiție(Definiție) Introduceți „Acesta este un model de instruire care descrie activitățile companiei” și în câmpul de text domeniul de aplicare(acoperire) - " Management general afaceri ale firmei: cercetare de piață, achiziție de componente, asamblare, testare și vânzare de produse” (Fig. 12).

10. Accesați diagrama de context și faceți clic dreapta pe dreptunghiul reprezentând, în notație IDEF0, desemnarea grafică condiționată a lucrării. Din meniul contextual, selectați opțiunea Nume(Fig. 13). În fila Nume introduceți numele „Activitatea companiei” (Fig. 14).

11. Tab Definiție căsuță de dialog Proprietățile activitățiiîn câmpul de text Definiție(Definiție) introduceți „Procesele de afaceri curente ale companiei” (Fig. 15). Câmp text Notă(Note) lăsați necompletat.

Orez. 12. Introducerea datelor suplimentare care definesc modelul

Orez. 13. Meniu contextual pentru lucrul cu opțiunea Nume selectată

Orez. 14. Numirea lucrării tale

Orez. 15. Introducerea datelor suplimentare despre muncă

12. Creați ICOM- săgeți pe diagrama de context (Tabelul 1).

Tabelul 1 - Săgeți pentru diagrama contextului

Nume săgeată (SăgeatăNume)	Definiția săgeții (SăgeatăDefiniție)	tip săgeată (Săgeatătip)
Apelurile clientului	Cereri de informatii, comenzi, suport tehnic etc.
Reguli și proceduri	Reguli de vânzare, instrucțiuni de asamblare, proceduri de testare, criterii de performanță etc.
Produse vândute	Calculatoare desktop și laptop
Sistem de contabilitate	Facturare, facturare, procesare comenzi

13. Cu ajutorul butonului, introduceți textul în câmpul diagramei - punct de vedere și obiectiv (Fig. 16).

Orez. 16. Introducerea textului în câmpul diagramei utilizând Editorul de blocuri de text

14. Creați un raport asupra modelului. În meniu Instrumente/Rapoarte/Model de raport(Fig. 17) setați opțiunile de generare a rapoartelor (bifați casetele) și faceți clic pe butonul previzualizare(Previzualizare) (Fig. 18).

Orez. 17. Setarea opțiunilor pentru generarea unui model de raport

Orez. 18. Previzualizarea raportului model

Descompunerea proceselor de producţie după metodologieIDEF0

Lucrări (Activitate)

Activitățile se referă la procese, funcții sau sarcini numite care apar în timp și au rezultate recunoscute. Elementele sunt afișate ca dreptunghiuri. Toate lucrările trebuie să fie denumite și identificate. Numele postului trebuie să fie un substantiv verbal care denotă o acțiune (de exemplu, „Efectuarea unei piese”, „Acceptarea unei comenzi”, etc.). Jobul „Fabricarea unei piese” ar putea avea, de exemplu, următoarea definiție: „Locul de muncă se referă la ciclul complet de fabricație a unui produs, de la controlul calității materiilor prime până la expedierea produsului finit ambalat”. La crearea unui nou model (meniu Fișier/Nou) creează automat o diagramă de context cu o singură lucrare care descrie sistemul în întregime (Fig. 1).

Pentru a introduce numele lucrării, faceți clic dreapta pe lucrare, selectați din meniu editor de nume iar în caseta de dialog care apare, introduceți numele jobului. Dialogul este folosit pentru a descrie alte proprietăți ale lucrării. Proprietățile activității(Fig. 2).

Orez. 1. Un exemplu de diagramă de context

Orez. 2. Editor de proprietăți ale jobului

Diagramele de descompunere conțin lucrări înrudite, de ex. locuri de muncă pentru copii care au un loc de muncă comun de părinte. Pentru a crea o diagramă de descompunere, faceți clic pe butonul .

Apare un dialog Număr de casete de activitate(Fig. 3), în care ar trebui să indicați notarea noii diagrame și numărul de lucrări pe ea. Să alegem o notație IDEF0și faceți clic pe Bine. Apare o diagramă de descompunere (Figura 4). Intervalul admis al numărului de lucrări 2-8. Nu are sens să descompunem un job într-un singur job: diagramele cu mai mult de opt joburi sunt suprasaturate și greu de citit. Pentru a asigura claritatea și o mai bună înțelegere a proceselor care sunt modelate, se recomandă utilizarea de la trei până la șase blocuri pe o diagramă.

Orez. 3. DialogNumăr de casete de activitate

Orez. 4. Un exemplu de diagramă de descompunere

Dacă se dovedește că numărul de joburi nu este suficient, atunci jobul poate fi adăugat la diagramă făcând clic mai întâi pe butonul din paleta de instrumente, apoi pe spațiul liber din diagramă.

Lucrările pe diagrame de descompunere sunt de obicei dispuse în diagonală din colțul din stânga sus până în dreapta jos.

Această ordine se numește ordinea dominației. Conform acestui principiu de aranjare, în colțul din stânga sus este cel mai mult muncă importantă sau munca făcută la timp mai întâi. Mai jos în dreapta sunt sarcini mai puțin importante sau ulterioare. Această aranjare face diagramele mai ușor de citit, iar noțiunea de relații de muncă se bazează pe ea.

Fiecare dintre activitățile din diagrama de descompunere poate fi descompusă pe rând. Diagramele de defalcare a lucrărilor sunt numerotate automat de la stânga la dreapta. Numărul jobului este afișat în colțul din dreapta jos. O linie diagonală mică este afișată în colțul din stânga sus, ceea ce indică faptul că această lucrare nu a fost descompusă. Deci, de exemplu, jobul „Asamblare produs” are numărul 3 și nu a fost încă descompus. Lucrarea „Controlul calității” (numărul 4) are un nivel mai scăzut de descompunere

Săgeți

Interacțiunea lucrărilor cu lumea exterioară și între ele este descrisă sub formă de săgeți. Săgețile reprezintă unele informații și se numesc substantive (de exemplu, „Produs”, „Produs”, „Comandă”).

IDEF0 distinge cinci tipuri de săgeți:

Intrare- materialul sau informația care este folosită sau transformată de lucrare pentru a obține un rezultat (ieșire). Este permis ca lucrarea să nu aibă nicio săgeată de intrare. Fiecare tip de săgeată se apropie sau iese de o anumită latură a dreptunghiului de lucru. Săgeata de intrare este desenată ca intrând în partea stângă a jobului. La descrierea proceselor tehnologice (pentru care a fost inventat IDEF0), nu există probleme în determinarea intrărilor. Într-adevăr, „Materia primă” din Fig. 1. este ceva care este prelucrat în procesul de „Fabricare a produsului” pentru a obține un rezultat. Când modelați IS, când săgețile nu sunt obiecte fizice, ci date, nu totul este atât de evident. De exemplu, la „Primirea unui pacient”, cardul pacientului poate fi atât la intrare, cât și la ieșire, între timp calitatea acestor date se modifică. Cu alte cuvinte, în acest exemplu, pentru a-și justifica scopul, săgețile de intrare și de ieșire trebuie definite cu precizie pentru a indica faptul că datele au fost într-adevăr prelucrate (de exemplu, ieșirea este „Filled Patient Record”). Este adesea dificil de determinat dacă datele sunt introduse sau controlate. În acest caz, indiciu poate fi dacă datele sunt prelucrate/modificate în lucrare sau nu. Dacă se schimbă, atunci cel mai probabil aceasta este o intrare, dacă nu - control.

Control- reguli, politici, proceduri sau standarde care guvernează munca. Fiecare job trebuie să aibă cel puțin o săgeată de control. Săgeata de control este desenată ca intrând în partea superioară a lucrării. Pe fig. 1 săgeți „Sarcina” și „Desen” - control pentru lucrarea „Fabricarea produsului”. Managementul influențează munca, dar nu este transformat de muncă. Dacă scopul lucrării este de a schimba o procedură sau o strategie, atunci o astfel de procedură sau strategie va fi o intrare pentru lucrare. În caz de incertitudine în starea săgeții (control sau intrare), se recomandă trasarea unei săgeți de control.

Ieșire- materialul sau informația care este produsă de post. Fiecare job trebuie să aibă cel puțin o săgeată de ieșire. Munca fără rezultate este lipsită de sens și nu trebuie modelată. Săgeata de ieșire este desenată ca venind din partea dreaptă a lucrării. Pe fig. 1 săgeată „Produs finit” este rezultatul pentru lucrarea „Fabricarea produsului”.

Mecanism- resursele care efectuează munca, cum ar fi personalul uzinei, mașinile, dispozitivele etc. Săgeata mecanismului este desenată ca intrând în marginea de jos a lucrării. Pe fig. 1 săgeată „Personalul întreprinderii” este mecanismul pentru munca „Fabricarea produsului”. La discreția analistului, săgețile mecanismului pot să nu fie afișate în model.

Apel- o săgeată specială care indică un alt model de lucru. Săgeata de apel este desenată ca venind din marginea de jos a lucrării. Pe fig. 1 săgeată „Alt model de lucru” este un apel pentru lucrarea „Face produs”. Săgeata de apel este folosită pentru a indica faptul că unele lucrări sunt efectuate în afara sistemului simulat. În BPwin, săgețile de apel sunt folosite în mecanismul de îmbinare și împărțire a modelelor.

Săgeți de frontieră. Săgețile de pe diagrama de context sunt folosite pentru a descrie interacțiunea sistemului cu lumea exterioară. Ele pot începe de la marginea diagramei și se pot termina la locul de muncă, sau invers. Astfel de săgeți se numesc graniță.

Pentru a adăuga o săgeată de delimitare la intrare, procedați în felul următor:

Săgețile pentru control, ieșire, mecanism și ieșire sunt afișate în același mod. Pentru a desena o săgeată de ieșire, de exemplu, faceți clic pe butonul cu simbolul săgeată din paleta de instrumente, faceți clic pe partea dreaptă a lucrării din partea de ieșire (unde începe săgeata), mutați cursorul în partea dreaptă a ecran până când apare bara întreruptă inițială și faceți clic o dată de-a lungul liniei întrerupte.

Numele săgeților nou adăugate sunt adăugate automat în dicționar ( Dicţionar Arrow).

coduri ICOM. Diagrama de descompunere are scopul de a detalia lucrarea. Spre deosebire de modelele care reprezintă structura unei organizații, lucrul pe o diagramă de nivel superior în IDEF0 nu este un control secundar. Lucrările de nivel inferior sunt aceleași cu lucrările de la nivelul superior, dar mai detaliat. În consecință, limitele lucrării de nivel superior sunt aceleași cu limitele diagramei de descompunere. ICOM(abreviere pentru Intrare, control, ieșire și mecanism) - coduri concepute pentru a identifica săgețile de delimitare. Cod ICOM conține un prefix corespunzător tipului de săgeată ( eu,CU,DESPRE sau M) și numărul de serie. BPwin introduce codurile ICOM automat. Pentru a afișa coduri ICOM, activați opțiunea Afișare coduri ICOM din filă prezentare dialog Proprietățile modelului.

Dicționarul de săgeți este editat folosind un editor special Arrow Dictionary Editor, în care este definită săgeata și se introduce un comentariu legat de aceasta (Fig. 6). Dicționarul de săgeți rezolvă o sarcină foarte importantă. Diagramele sunt create de un analist pentru a conduce o sesiune de examinare, adică pentru a discuta diagrama cu un specialist în materie. În orice domeniu se formează jargonul profesional, iar de foarte multe ori expresiile de jargon au o semnificație neclară și sunt percepute diferit de diferiți specialiști. În același timp, analistul - autorul diagramelor ar trebui să folosească acele expresii care sunt cele mai înțelese de experți. Deoarece definițiile formale sunt adesea greu de înțeles, analistul este obligat să folosească jargonul profesional și, pentru a evita interpretările ambigue, fiecărui concept i se poate da o definiție extinsă și, dacă este necesar, formală în dicționarul de săgeți.

Conținutul dicționarului de săgeți poate fi tipărit ca raport (meniu Raport/Săgeată Raport...) și obținem astfel un dicționar explicativ al termenilor de domeniu utilizați în model.

Orez. 5. DialogProprietăți săgeți

Orez. 6. Dicţionar de săgeţi

Săgeți de frontieră neconectate. Când un job este descompus, săgețile care intră și ies din el (cu excepția săgeții de apel) apar automat pe diagrama de descompunere (migrarea săgeții), dar nu ating joburile. Astfel de săgeți sunt numite nelegate și sunt tratate în BPwin ca o eroare de sintaxă. Pentru a lega săgețile de intrare, de control sau mecanism, intrați în modul de editare a săgeții, faceți clic pe capul săgeții, apoi faceți clic pe segmentul de lucru corespunzător. Pentru a conecta o săgeată de ieșire, intrați în modul de editare a săgeții, faceți clic pe segmentul de ieșire din job, apoi faceți clic pe săgeată.

Săgeți interne. Săgețile interne sunt folosite pentru a lega joburile între ele, adică săgețile care nu ating marginea diagramei încep la o lucrare și se termină la un alt job.

Pentru a desena o săgeată interioară, în modul de desenare a săgeții, faceți clic pe un segment (de exemplu, o ieșire) al unui job și apoi pe un segment (de exemplu, o intrare) al altuia. IDEF0 distinge între cinci tipuri de legături de lucru.

Comunicare de intrare (ieșire-intrare), când săgeata de ieșire a postului superior (denumit în continuare exit) este îndreptată spre intrarea celui inferior.

Controlul comunicației (ieșire-control) când rezultatul postului superior este îndreptat spre controlul celui inferior. Comunicarea managerială arată dominația muncii superioare. Datele sau obiectele de ieșire ale lucrării din amonte nu se modifică în aval.

Feedback de intrare (feedback de ieșire-intrare) când ieșirea lucrării inferioare este direcționată către intrarea celei superioare. O astfel de relație este de obicei folosită pentru a descrie cicluri.

Feedback de control (feedback de ieșire-control) când ieșirea jobului din aval este direcționată către controlul jobului din amonte. Feedback-ul managementului este adesea indicativ al eficacității unui proces de afaceri.

Conexiune ieșire-mecanism (ieșire-mecanism) când rezultatul unei lucrări este trimis la mecanismul alteia. Această relație este cea mai puțin utilizată și indică faptul că un loc de muncă pregătește resursele necesare pentru a realiza un alt loc de muncă.

Săgeți explicite. O săgeată explicită are un singur job ca sursă și un singur job ca destinație.

Săgeți de ramificare și îmbinare. Aceleași date sau obiecte generate de un job pot fi utilizate în mai multe alte joburi simultan. Pe de altă parte, săgețile generate în lucrări diferite pot reprezenta date sau obiecte aceleași sau omogene care sunt utilizate sau procesate în continuare într-un singur loc. Pentru a modela astfel de situații, IDEF0 folosește săgeți de ramificare și îmbinare. Pentru a ramifica o săgeată, în modul de editare a săgeții, faceți clic pe fragmentul de săgeată și pe segmentul corespunzător al lucrării. Pentru a îmbina două săgeți de ieșire, în modul de editare a săgeții, faceți mai întâi clic pe segmentul de ieșire al jobului, apoi pe fragmentul de săgeată corespunzător.

Semnificația săgeților de ramificare și îmbinare este transmisă prin denumirea fiecărei ramuri a săgeților. Există anumite reguli pentru denumirea unor astfel de săgeți. Luați în considerare exemplul săgeților de ramificare. Dacă o săgeată este denumită înainte de ramură și nicio ramură nu este numită după ramură, atunci se presupune că fiecare ramură modelează aceleași date sau obiecte ca și ramura dinaintea ramurii.

Dacă săgeata este numită înainte de ramură, iar după ramură oricare dintre ramuri nu este numită, atunci se presupune că aceste ramuri corespund numelui. Dacă în același timp orice ramură după ramură rămâne nenumită, atunci se presupune că modelează aceleași date sau obiecte ca și ramura dinaintea ramurului.

Nu este permisă situația în care săgeata dinaintea ramurii nu este numită, iar după ramură oricare dintre ramuri nu este numită. BPwin definește o astfel de săgeată ca o eroare de sintaxă.

Regulile de denumire a săgeților de îmbinare sunt complet similare - o săgeată va fi considerată o eroare dacă nu este numită după îmbinare, iar înainte de îmbinare, nici una dintre ramurile sale nu este numită. Pentru a denumi o ramură separată de săgeți de ramificare și îmbinare, selectați o singură ramură din diagramă, apoi apelați editorul de nume și atribuiți un nume săgeții. Acest nume se va potrivi numai cu ramura selectată.

tunelul săgeților. Săgețile de delimitare nou adăugate în diagrama de descompunere de nivel inferior sunt afișate între paranteze drepte și nu apar automat în diagrama de nivel superior.

Pentru a le „trage” în sus, trebuie mai întâi să selectați butonul de pe paleta de instrumente și să faceți clic pe parantezele pătrate ale săgeții de delimitare. Apare un dialog Editor săgeată chenar(Fig. 7).

Orez. 7. DialogEditor săgeată chenar

Dacă faceți clic pe butonul RezolvaFrontierăSăgeată, săgeata migrează la diagrama de nivel superior dacă săgeata este tunelizată de butonul ChangeToTunnel și nu merge la altă diagramă.

Tunnelarea poate fi aplicată pentru a reprezenta săgeți nesemnificative. Dacă este necesar să se înfățișeze date sau obiecte nesemnificative care nu sunt prelucrate sau utilizate de lucrări la nivelul curent pe orice diagramă de nivel inferior, atunci acestea trebuie direcționate către un nivel superior (spre diagrama părinte). Dacă aceste date nu sunt folosite în diagrama părinte, ar trebui direcționate și mai sus, și așa mai departe, ca urmare, o săgeată nesemnificativă va fi desenată la toate nivelurile și va îngreuna citirea tuturor diagramelor în care este prezentă. Calea de ieșire este să faci tunelul săgeții la cel mai de jos nivel. Acest tunel se numește „not-in-the-parent-chart”.

Un exemplu de creare a unei diagrame de descompunere

1. Selectați butonul pentru a merge la nivelul inferior în paleta de instrumente și în caseta de dialog Număr de casete de activitate(fig. 8) setați numărul de lucrări pe diagrama de nivel inferior - 3 - și apăsați butonul Bine.

Orez. 8. Caseta de dialog Număr casetă de activitate

2. Va fi creată automat o diagramă de descompunere (Fig. 9).

Orez. 9. Diagrama de descompunere

Faceți clic dreapta pe lucrarea situată în colțul din stânga sus al zonei de editare a modelului, selectați opțiunea din meniul contextual Numeși introduceți numele jobului. Repetați operația pentru celelalte două lucrări. Apoi introduceți definiția, starea și sursa pentru fiecare lucrare conform datelor din tabelul 1.

Tabelul 1. Operații ale diagramei de descompunere A0

Diagrama de descompunere va lua forma prezentată în Fig. 10.

Fig.10 Diagrama de descompunere după denumirea lucrărilor

3. Pentru a modifica proprietățile joburilor după ce acestea au fost adăugate la diagramă, puteți utiliza dicționarul de job (Fig. 11). Dicționarul este apelat folosind elementul din meniul principal Dicţionar/Activitate.

Orez. 11. DicţionarDicţionar de activitate

Dacă descrieți numele și proprietățile unui job într-un dicționar, îl puteți adăuga la diagramă mai târziu folosind butonul din paleta de instrumente. Nu este posibilă eliminarea unui job din dicționar dacă este folosit în orice diagramă. Dacă lucrarea este eliminată din diagramă, aceasta nu este eliminată din dicționar. Numele și descrierea unei astfel de lucrări pot fi folosite ulterior. Pentru a adăuga un job în dicționar, mergeți la sfârșitul listei și faceți clic dreapta pe ultima linie. Apare o nouă linie în care trebuie să introduceți numele și proprietățile jobului. Pentru a elimina toate numele de job care nu sunt utilizate în model, faceți clic pe ( Epurare(Curat)).

4. Comutați la modul de desenare a săgeților și legați săgețile de delimitare folosind butonul de pe paleta de instrumente, așa cum se arată în fig. 12.

Orez. 12. Săgeți de delimitare conectate pe diagrama A0

5. Faceți clic dreapta pe ramura săgeată de control a lucrării Build and Test Computers și redenumiți-o în Build and Test Rules (Figura 13). Introduceți o definiție pentru noua ramură: „Instrucțiuni de construire, proceduri de testare, criterii de performanță etc.” Faceți clic dreapta pe ramura săgeată a mecanismului de lucru „Vânzări și marketing” și redenumiți-l ca „Sistem de plată” (Fig. 14).

Orez. 13. Săgeată „Construiți și testați reguli”

Orez. 14. Săgeată „Sistem de plată”

6. O metodă alternativă de introducere a numelor și proprietăților săgeților este utilizarea dicționarului de săgeți (apelați dicționarul - meniu Dicţionar/Săgeată). Dacă introduceți numele și proprietățile săgeții în dicționar (Fig. 15), o puteți adăuga la diagramă mai târziu.

Orez. 15. Dicționar de săgeți

O săgeată nu poate fi eliminată din dicționar dacă este folosită în orice diagramă. Dacă eliminați o săgeată din diagramă, aceasta nu este eliminată din dicționar. Numele și descrierea unei astfel de săgeți pot fi folosite ulterior. Pentru a adăuga o săgeată, mergeți la sfârșitul listei și faceți clic dreapta pe ultima linie. Apare o nouă linie în care trebuie să introduceți numele și proprietățile săgeții.

7. Creați noi săgeți interioare așa cum se arată în fig. 16.

Orez. 16. Săgețile interne ale diagramei A0

8. Creați o săgeată părere(Management) „Rezultate de asamblare și testare” care se extinde de la „Asamblare și testare a computerelor” la „Vânzări și marketing”. Schimbați, dacă este necesar, stilul săgeții (grosimea liniei) și setați opțiunea Vârf de săgeată suplimentar(Vărfuri de săgeată opționale) (din meniul contextual). metodă trage si lasa mutați numele săgeților astfel încât să fie mai ușor de citit. Dacă este necesar, instalați din meniul contextual Squiggle(Zagogulin). Rezultatul posibilelor modificări este prezentat în fig. 17.

Orez. 17. Rezultatul editării săgeților de pe diagrama A0

9. Creați o nouă săgeată de ieșire „Materiale de marketing” care iese din lucrarea „Vânzări și marketing”. Această săgeată nu merge automat la diagrama de nivel superior și are paranteze pătrate pe vârf (Fig. 18).

Orez. 18. Materiale de marketing Arrow

10. Faceți clic dreapta pe paranteze pătrate și selectați elementul de meniu Arrow Tunnel(Fig. 19).

În caseta de dialog Editor săgeată chenar(Editor de săgeți de delimitare) selectați o opțiune Rezolvați-l la Border Arrow(Rezolvați ca săgeată de delimitare) (fig. 20).

Orez. 19. ParagrafmeniulArrow Tunnel

Orez. 20. DialogfereastrăEditor săgeată chenar

Pentru săgeata „Materiale de marketing”, selectați o opțiune tunde(Organizați) din meniul contextual. Rezultatul lucrărilor de laborator este prezentat în Fig. 21.

Orez. 21. Rezultatul descompunerii

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

Definiție

IDEF0 (Integration Definition for Function Modeling) - o metodologie de modelare funcțională pentru descrierea funcțiilor unei întreprinderi, oferind un limbaj de modelare funcțional pentru analiză, dezvoltare, reinginerire și integrare sisteme de informare procese de afaceri; sau analiza ingineriei software.

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

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

IDEF0 – integrare Definiție limba 0 - bazat pe SADT și în forma sa originală include atât: definirea unui limbaj de modelare grafică (sintaxă și semantică) cât și o descriere a unei metodologii complete (cuprinzătoare) de dezvoltare a modelelor.

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).

În 1993, IDEF0 a fost adoptat ca standard federal în Statele Unite, iar în 2000 ca standard în Federația Rusă.

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 domeniul modelat.

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

Pentru sistemele în curs de proiectare, IDEF0 poate fi utilizat mai întâi pentru a defini cerințele și funcțiile, iar apoi pentru o implementare care satisface acele cerințe și îndeplinește 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 aceste funcții.

Obiectivele standardului IDEF0

Principalele obiective (obiective) 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ă (consecventă) a funcțiilor unui sistem sau a unui domeniu, precum și a datelor și obiectelor care leagă aceste funcții;

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

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

general(generic) - pentru analiza sistemelor și a disciplinelor;

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) - să reprezinte cerințe funcționale independente de implementările fizice sau organizaționale;

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

Rigiditate si 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ă lipsească sau să existe detalii suplimentare care să depășească cadrul stabilit;

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

conectivitatea structurii de date. (Data Structure Connectivity) – coduri ICOM și utilizarea parantezelor;

etichete și titluri unice (Etichete și titluri unice) - fără titluri duplicate;

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

date arrow constraints branch constraints (Constrângere Data Arrow Branch Constraint) - etichete pentru restricțiile fluxului de date pe ramuri;

separarea datelor în Input și Control (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 (Scopul și punctul de vedere) - toate modelele au o declarație de scop și punct de vedere.

Concepte de bază ale IDEF0

Metodologia se bazează pe patru concepte principale:

bloc funcțional;

arc de interfață;

descompunere;

glosar.

Bloc funcțional(Activity Box) este o funcție specifică în cadrul sistemului considerat.

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

În diagramă, un bloc funcțional este reprezentat printr-un dreptunghi (fig.). Fiecare dintre cele patru laturi ale blocului funcțional are propriul său sens specific (rol), în timp ce:

partea de sus este setată la „Control”;

partea stângă are valoarea „Input” (Input);

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

partea de jos are valoarea „Mecanism” (Mecanism).

Orez. Bloc funcțional

Arc/săgeată de interfață(Săgeată) afișează elementul sistemului care este procesat de blocul funcțional sau care afectează în alt mod funcția reprezentată de acest bloc funcțional. Arcurile de interfață sunt adesea denumite fluxuri sau săgeți.

Cu ajutorul arcurilor 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, vagoane, 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ă respecte niște 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 conceptul de bază al standardului IDEF0. Principiul descompunerii se aplică atunci când un proces complex este defalcat în funcțiile sale constitutive. În acest caz, nivelul de detaliu al procesului este determinat direct de dezvoltatorul modelului.

Descompunerea vă permite să reprezentaț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 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 presupune crearea și menținerea unui set de definiții adecvate, 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 entității elementului. Glosarul completează armonios limbajul grafic vizual, oferind diagramelor informațiile suplimentare necesare.

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

Textul explicativ pentru diagrama de context ar trebui să indice ţintă(Scopul) diagramă ca o scurtă descriere și fix Punct de vedere(punct de vedere).

Definiție și formalizare obiective dezvoltarea modelului IDEF0 este un punct extrem de important. De fapt, scopul determină zonele relevante din sistemul studiat, care trebuie concentrate 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 să detaliați și să studiați elementele individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului.

Inițial metodologie IDEF a fost dezvoltat pentru US Air Force, apoi operat de NASA și abia după ceva timp a început să fie folosit pentru modelarea proceselor de afaceri.

Cele mai populare soiuri ale familiei IDEF, dintre cele folosite în afaceri, sunt notațiile IDEF0Și IDEF3. Trăsătură distinctivă notația este posibilitatea de descompunere, adică. fiecare bloc individual dintr-un proces poate fi la rândul său reprezentat ca un proces separat.

IDEF0

Notaţie IDEF0 folosit de obicei pentru a descrie procese de nivel superior, deși vă permite să descrieți întreaga activitate a companiei. O caracteristică distinctivă a notației este capacitatea de a afișa nu numai intrările și ieșirile fiecărui bloc, ci și „controlul” și „mecanismele”. Impreuna cu caracteristici suplimentare cerințele pentru calificarea analiștilor de afaceri care sunt angajați în procese de modelare în notație sunt, de asemenea, în creștere IDEF0. Deci, de exemplu, nu este întotdeauna evident că „managementul” ar trebui să includă standarde și specificații tehnice, dar nu ar trebui să fie atribuit descrierea postului sau director de producție. Controverse apar și în jurul „mecanismelor” de control al procesului, deoarece fiecare specialist are tendința de a interpreta acest conceptîn felul meu.

În ciuda prezenței unor proprietăți suplimentare, sub formă de „control” al procesului, notația IDEF0 rămâne încă static și nu este capabil să reflecte exact modul în care evoluția procesului se schimbă sub influența chiar a acestui „management”.

Numărul de blocuri pe diagramă IDEF0 de obicei strict limitat de instrumentul de modelare și, de regulă, nu depășește 9. Adesea, acest număr nu este suficient, din cauza căruia procesele deosebit de mari trebuie împărțite în mai multe diagrame, ceea ce provoacă anumite inconveniente.

La construirea proceselor în notație IDEF0 se recomanda trasarea blocurilor nu in ordinea executarii lor, ci in ordinea dominatiei: de la cele mai importante la cele secundare; cu toate acestea, mulți modelatori de business ignoră această recomandare, preferând să aranjeze blocurile în cel mai vizual mod.

În ciuda deficiențelor descrise și a complexității relative a percepției schemelor grafice de către angajații obișnuiți ai întreprinderii, notația IDEF0 rămâne încă unul dintre cei mai populari în rândul consultanților și profesioniștilor din domeniul consultanței în management.

Cel mai faimos produs rusesc care susține construcția proceselor în notație IDEF0, este , această notație este susținută și de Microsoft Visio.

IDEF3

Notaţie IDEF3 folosit mai des pentru a construi procese de nivel inferior, poate fi folosit și la descompunerea blocurilor de proces IDEF0. Spre deosebire de IDEF0 această notație nu suportă afișarea „mecanismelor” și „controlului”, dar afișează succesiunea lucrărilor efectuate de personal. În ciuda asemănării cu notația organigramă, are unele diferențe semnificative. În primul rând, întregul proces este construit nu de sus în jos, ci de la stânga la dreapta și, de regulă, este limitat de numărul de blocuri utilizate pe diagramă. În al doilea rând, notația a fost destinată inițial specialiștilor tehnici, prin urmare conține intersecții speciale, precum „XOR”, „Synchronous OR”, „Asynchronous OR”, „Synchronous AND” și „Asynchronous AND”, familiare programatorilor, dar care necesită suplimentar explicație managerii întreprinderii.