Lucrări practice privind utilizarea idef0 pentru descrierea funcțională a software-ului CAD. IDEF0. Familiaritatea cu notația și exemplul de utilizare Exemple simple de construcție în idef0

Știați, ce este un experiment de gândire, un experiment gedanken?
Aceasta este o practică inexistentă, o experiență de altă lume, imaginația a ceea ce nu este în realitate. Experimentele gândirii sunt ca niște vise trezite. Ei dau naștere monștrilor. Spre deosebire de un experiment fizic, care este un test experimental de ipoteze, un „experiment de gândire” înlocuiește în mod viclean un test experimental cu concluzii dorite, netestate în practică, manipulând construcții logice care încalcă de fapt logica însăși prin utilizarea premiselor nedemonstrate ca fiind dovedite, adică prin substituire. Astfel, sarcina principală a solicitanților pentru „experimente de gândire” este de a înșela ascultătorul sau cititorul prin înlocuirea unui experiment fizic real cu „păpușa” sa – raționament fictiv în eliberare condiționată fără verificarea fizică în sine.
Umplerea fizicii cu „experimente de gândire” imaginare a dus la apariția unei imagini suprareale absurde, confuze și confuze a lumii. Un adevărat cercetător trebuie să distingă astfel de „împachetări de bomboane” de valorile reale.

Relativiștii și pozitiviștii susțin că „experimentul gândirii” este un instrument foarte util pentru testarea coerenței teoriilor (care apar și în mintea noastră). În aceasta, ei înșală oamenii, deoarece orice verificare poate fi efectuată numai de o sursă independentă de obiectul verificării. Reclamantul însuși al ipotezei nu poate fi un test al propriei afirmații, întrucât motivul în sine a acestei afirmații este absența contradicțiilor în afirmație vizibilă reclamantului.

Vedem acest lucru pe exemplul SRT și GRT, care s-au transformat într-un fel de religie care guvernează știința și opinia publică. Nici o cantitate de fapte care le contrazic nu poate depăși formula lui Einstein: „Dacă un fapt nu corespunde teoriei, schimbați faptul” (Într-o altă versiune, „- Faptul nu corespunde teoriei? - Cu atât mai rău pentru fapt").

Maximul pe care îl poate pretinde un „experiment de gândire” este doar consistența internă a ipotezei în cadrul propriei logici a solicitantului, adesea deloc adevărată. Acest lucru nu testează adecvarea practicii. Acest test poate avea loc numai într-un experiment fizic valabil.

Un experiment este un experiment în sensul că nu este o rafinare a gândirii, ci un test al gândirii. Un gând care este auto-consecvent în sine nu se poate verifica singur. Acest lucru este dovedit de Kurt Gödel.

Ministerul Educației și Științei al Federației Ruse

Agenția Federală pentru Educație

Stat instituție educațională studii profesionale superioare

Lucru de curs

„Modelare de sistem”

„Dezvoltarea unui model de întreprindere cu efect de seră folosind metodologiile de proiectare IDEF0, DFD și IDEF3”

1. Scopul muncii

2. Introducere teoretică

3. Descrierea domeniului subiectului

4. Descrierea BPwin

4.1 Principiul construirii modelului IDEF0

4.2 Principiul construirii unui model DFD

4.3 Principiul construcției modelului IDEF3

5. Simulare

5.1 Model de seră

5.2 Model matematic

6. Analiză comparativă

6.1 Metodologii

6.2 Compararea instrumentelor

Literatură

1. Scopul muncii

Obiectivele acestui curs au fost:

aplicarea metodelor de cercetare pre-proiect a întreprinderii;

analiza materialelor primite pentru modelarea ulterioară;

dezvoltarea unui model de proces în standardul IDEF0;

descrierea fluxului de lucru și a procesării informațiilor în standardul DFD;

descrieri ale proceselor din standardul IDEF3;

dezvoltarea unui model mixt de descriere a proceselor bazat pe standardele IDEFO, DFD și IDEF3.

crearea de scenarii pentru întreprindere;

clădire diagrama structurala intreprinderi;

realizarea unui model matematic a acestei intreprinderi.

analiza comparativa

2. Introducere teoretică

La dezvoltare sisteme automatizate control în etapele de codificare și testare, se dezvăluie un număr mare de erori, a căror corectare atrage după sine o schimbare radicală a întregului sistem în curs de dezvoltare. Astfel de erori sunt luate în considerare la modelare și la analiza aprofundată și detaliată a proiectelor create. Modelarea vă permite să „vedeți” proiectul în procesul de dezvoltare și să creați premisele pentru analizarea comportamentului sistemului în funcție de condițiile inițiale.

Pentru coordonarea corectă a proceselor care au loc în sistemul de control simulat, este necesară crearea unei structuri, i.e. eficientiza procesele. Simularea muncii Sistem informatic deosebit de important în primele etape ale creării sale. Întrucât corectarea greșelilor făcute în această etapă este cea mai costisitoare, beneficiile în etapa analizării problemei și dezvoltării unui model logic pentru soluționarea acesteia sunt semnificative.

În acest sens, este necesar să se studieze și să se dezvolte un domeniu, și anume activitatea economiei cu efect de seră. Pentru a face acest lucru, trebuie să înțelegeți terminologia acestei zone, să colectați reglementările necesare și documente legale, studiază mostrele de documente ale întreprinderii date și urmărește mișcarea acestora atât în interiorul întreprinderii, cât și în afara acesteia.

În procesul de lucru în etapele de modelare și proiectare, este necesară obținerea unui proiect de sistem care să conțină suficiente informații pentru implementarea acestuia. De asemenea, este necesar să se analizeze activitatea economiei cu efect de seră, în urma căreia este posibil să se judece gradul de volum de muncă al fiecărui departament, ce trebuie automatizat în primul rând și prin ce mijloace.

Principalele obiective ale modelării în dezvoltarea proiectelor sunt:

prezentarea activităților întreprinderii și a tehnologiilor adoptate în aceasta sub forma unei ierarhii de diagrame care oferă claritate și completitudine afișării acestora;

formarea pe baza analizei propunerilor de reorganizare a structurii organizatorice si de conducere;

eficientizarea fluxurilor de informații (inclusiv fluxul de lucru) în cadrul întreprinderii;

analiza cerințelor și proiectarea specificațiilor pentru sistemele informaționale corporative.

3. Descrierea domeniului subiectului

Pentru luare în considerare în acest sens termen de hârtie a fost luată ca bază munca economiei cu efect de seră. Această companie este specializată în cultivarea culturilor. Produsele se vinde la cererea clientului.

Organizarea muncii se realizează după următoarea schemă:

Această diagramă prezintă departamentele întreprinderii, funcțiile și interrelațiile acestora. Unele dintre departamente pot fi automatizate.

În fruntea întregii întreprinderi se află conducerea, reprezentată de șef și adjunctul acestuia. Funcția lor principală este de a controla activitățile întreprinderii.

Serviciul de protecție a muncii, a cărui funcție principală este pregătirea personalului;

Departamentul de contabilitate se ocupa de circulatia documentelor;

Serviciul de control al producției, efectuează controlul deplin în toate etapele producției;

Sector întreținere, este angajată în lucrări de renovare.

Departamentele, serviciile și locurile de muncă ale acestei întreprinderi sunt prezentate în tabelul 1:

tabelul nr.1

Sarcinile și funcțiile economiei noastre cu efect de seră sunt prezentate în tabelul 2:

masa 2

Documentația este prezentată în tabelele #3:

tabelul numarul 3

Directorul organizațiilor este prezentat în tabelul 4:

tabelul nr.4

Următoarea este o diagramă care descrie scenariul de lucru al întreprinderii cu concluziile corespunzătoare pentru fiecare dintre etape: clientul primește o cerere de furnizare a anumitor produse ale economiei cu efect de seră către managerul de vânzări. Persoana de vânzări procesează această cerere și ia o decizie. Paralel cu aceasta, contabilul calculează costul furnizării serviciilor. Odată trecute toate aceste etape, începe procesul de contractare. Managerul de vânzări discută termenii contractului cu clientul și încheie încheierea acestuia. După aceea, clientul efectuează plata. Controlul asupra plății este responsabilitatea departamentului de contabilitate. Contabilul primește un extras de la bancă și formează un ordin de începere a executării comenzii, care este transferat tehnologului. Tehnologul, la rândul său, întocmește un plan - un program de lucru efectuat și ține evidența fondurilor necesare. După întocmirea unui plan - un program de lucru, grădinarului i se dă ordin să efectueze lucrări de teren. Grădinarul lucrează la pământ și recoltează. Recolta recoltată este trimisă clientului. În cursul tuturor ciclu de producțieșeful întreprinderii primește rapoarte privind activitățile directorului de vânzări, contabilului și tehnologului. Șeful controlează întregul proces al întreprinderii și, dacă este necesar, face comentarii asupra muncii personalului său pentru a îmbunătăți procesul de producție și munca întregii întreprinderi în ansamblu.

Diagrama scenariului întreprinderii

4. Descrierea BPwin

BPwin este un mic instrument integrat de modelare care acceptă mai multe tipuri de modele și metode.

Pentru a analiza și reorganiza procesele de afaceri, Logic Works oferă un instrument CASE de nivel superior, BPwin, care acceptă IDEF0 ( model functional), IDEF3 (WorkFlow Diagram) și DFD (DataFlow Diagram). Principala dintre cele trei metodologii este IDEF0. BPwin are o interfață de utilizator destul de simplă și intuitivă, care permite analistului să creeze modele complexe cu efort minim.

BPwin automatizează sarcinile asociate modelelor de dezvoltare a clădirilor, oferind rigoarea semantică necesară pentru a asigura rezultate corecte și consecvente. Acest lucru se realizează prin aplicarea următoarelor metodologii în BPwin: IDEF0, DFD și IDEF3.

Dar înainte de a aborda această sarcină mai complexă, este într-adevăr necesar măcar să „recalculăm” toate elementele afacerii, adică să creăm structura organizatorică a companiei. Următorul pas este să încercăm să descriem grafic relațiile dintre diferitele elemente ale structurii definite anterior.

În BPwin, este posibil să se construiască modele mixte, adică modelul poate conține atât diagrame IDEFO, cât și diagrame IDEF3 și DFD. Un model în BPwin este privit ca o colecție de activități, fiecare dintre ele funcționând pe un set de date. Lucrarea este reprezentată ca dreptunghiuri, datele ca săgeți.

Toate lucrările modelului sunt numerotate. Numărul este format dintr-un prefix și un număr. Poate fi folosit un prefix de orice lungime, dar de obicei se folosește prefixul A. Lucrarea contextului (rădăcină) a arborelui este numerotată A0. Lucrarea de descompunere A0 are numerele Al, A2, A3 etc. Lucrările de descompunere de nivel inferior au numărul locului de muncă părinte, iar următorul număr secvenţial, de exemplu, lucrările de descompunere A3 vor avea numerele A3.1 A3.2, A3.Z, A3.4 etc.

Ca rezultat al suplimentării diagramelor, diagramelor IDEFO cu diagrame DFD și IDEF3, poate fi creat un model mixt care descrie cel mai bine toate aspectele întreprinderii. Ierarhia modelelor mixte poate fi văzută în fereastra Model Explorer. Lucrările în notație IDEFO sunt afișate în verde, DFD - în albastru.

BPwin, precum și sistemele locale integrate, practic nu permite efectuarea de analize complexe a sistemelor, ceea ce este mai mult sau mai puțin necesar pentru crearea de PMIS mici, mijlocii și mari. Cu ajutorul lor, este posibil să se dezvolte IS-uri locale sau mici subsisteme concepute pentru a automatiza lanțurile de afaceri individuale, adică atunci când nu este nevoie de o analiză cuprinzătoare a întreprinderii. O zonă tipică de aplicare a instrumentelor integrate mici este rezolvarea problemelor așa-numitei automatizări ale întreprinderii „pe bucăți”.

4.1 Principiul construirii modelului IDEFO

Baza metodologiei IDEFO este un limbaj grafic pentru descrierea proceselor de afaceri. Un model în notație IDEFO 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ă.

Modelul IDEFO presupune prezența unui obiectiv clar formulat a unui singur subiect de modelare și a unui punct de vedere.

Modelul 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 de expunere (FEO).

Diagrama de context este partea de sus a structurii arborelui diagramei și reprezintă cea mai generală descriere a sistemului și a interacțiunii acestuia cu mediul extern.

Acest proces se numește descompunere funcțională, iar diagramele care descriu fiecare fragment și interacțiunea fragmentelor se numesc diagrame de descompunere.

Notarea și metodologia IDEF0 se bazează pe conceptul de „bloc”, adică un dreptunghi care exprimă o anumită funcție a afacerii. După cum știți, un dreptunghi are patru laturi. În IDEF0, rolurile (valorile funcționale) ale tuturor părților sunt diferite:

partea superioară are sensul de „control”;

stânga - „intrare”;

dreapta - „ieșire”;

jos - „mecanism”.

Al doilea element al metodologiei și al notației este „fluxul” (numit „arc de interfață” în standard) – un element care descrie datele, controlul informal sau orice altceva care „influențează” funcția reprezentată de bloc. În funcție de ce parte a blocului este direcționat fluxul, acesta se numește, respectiv, „intrare”, „ieșire”, „control”.

Elementul pictural reprezentând „fluxul” este o săgeată.

Guvernarea este cea care guvernează activitățile biroului, în acest model de dezvoltare, acestea sunt legile cu privire la PU individual.

Săgețile „enter” introduc funcțiile datelor de intrare; în diagrama de context, acestea sunt datele personale ale angajatului.

Săgeți de ieșire - Ieșire. Într-o diagramă de context, acestea sunt diverse informații care sunt prezentate în Fond de pensie RF.

Săgeata „mecanism” reprezintă datele care afectează procesele. În diagramă, acestea sunt personal și PC-uri.

După descompunerea diagramei de context, fiecare fragment mare al sistemului este descompus în altele mai mici, în timp ce fiecărui fragment i se dă un nume și așa mai departe, până la nivelul potrivit detaliile descrierii.

După fiecare sesiune de descompunere, au loc sesiuni de examinare - experții în domeniu 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. Așa se obține conformitatea.

Toate intersecțiile din diagramă sunt numerotate, fiecare număr are un prefix J. Puteți edita proprietățile intersecției folosind dialogul Editor de definiții.

4.2 Principiul construirii unui model DFD

Diagramele de flux de date (DFD) sunt mijloacele principale de modelare a cerințelor funcționale ale unui proiect de sistem. Cu ajutorul lor, aceste cerințe sunt defalcate în componente funcționale (procese) și prezentate ca o rețea conectată prin fluxuri de date. Scopul principal al unor astfel de instrumente este de a demonstra modul în care fiecare proces își transformă intrările în ieșiri, precum și de a dezvălui relația dintre aceste procese.

Două notații diferite sunt folosite în mod tradițional pentru a reprezenta DFD: Yodana (Yourdon) și Gane-Sarson (Gane-Sarson). În plus, la construirea exemplelor, se va folosi notația lui Yodan, toate excepțiile vor fi discutate preliminar.

Această metodologie (metodologia Gane / Sarson) se bazează pe construirea unui model al SI analizat - proiectat sau existent efectiv. În conformitate cu metodologia, modelul de sistem este definit ca o ierarhie de diagrame de flux de date (DFD sau DFD), care descriu procesul asincron de transformare a informațiilor de la intrarea acesteia în sistem până la emiterea acesteia către utilizator. Diagramele nivelurilor superioare ale ierarhiei (diagramele de context) definesc principalele procese sau subsisteme ale SI cu intrări și ieșiri externe. Ele sunt detaliate folosind diagrame de nivel scăzut. Această descompunere continuă, creând o ierarhie pe mai multe niveluri de diagrame, până când se ajunge la un astfel de nivel de descompunere, la care procesul devine elementar și este imposibil să le detaliezi mai departe.

Sursele de informații (entități externe) generează fluxuri de informații (fluxuri de date) care transportă informații către subsisteme sau procese. Acestea, la rândul lor, transformă informațiile și generează noi fluxuri care transferă informații către alte procese sau subsisteme, dispozitive de stocare a datelor sau entități externe - consumatori de informații. Astfel, principalele componente ale diagramelor de flux de date sunt:

entitati externe;

sisteme/subsisteme;

procese;

dispozitive de stocare a datelor;

fluxuri de date.

4.3 Principiul construcției modelului IDEF3

IDEF3 poate fi folosit și ca metodă de creare a proceselor. IDEF3 completează IDEFO și conține tot ce aveți nevoie pentru a construi modele care pot fi folosite ulterior pentru analiza de simulare.

Fiecare lucrare din IDEF3 descrie un scenariu al unui proces de afaceri și poate fi o componentă a unei alte lucrări. Deoarece scenariul descrie scopul și scopul modelului, este important ca lucrările să fie numite cu un substantiv verbal care denotă un proces de acțiune sau o frază care conține un astfel de substantiv.

Punctul de vedere al modelului trebuie documentat. De obicei, acesta este punctul de vedere al persoanei responsabile de lucrare în ansamblu. De asemenea, este necesar să se documenteze scopul modelului - întrebările la care modelul este destinat să răspundă.

Joncţiune. Sfârșitul unei lucrări poate servi drept semnal pentru începerea mai multor lucrări sau o singură lucrare poate aștepta finalizarea mai multor lucrări. Încrucișările sunt folosite pentru a afișa logica interacțiunilor săgeților în timpul îmbinării și bifurcării sau pentru a afișa mai multe evenimente care pot sau ar trebui să fie finalizate înainte de a începe următoarea lucrare. Tipurile de intersecții sunt prezentate în tabel:

Tipuri de intersectii

Desemnare	Nume	Semnificație în cazul îmbinării săgeților (Fan-in Jonction)	Simt în caz săgeți de ramificare (Fan-out Jonction)
\|\|&	SI asincron	Toate procesele din amonte trebuie finalizate	Toate procesele următoare trebuie să ruleze
\|\|&\|\|	SI sincron	Toate procesele din amonte au fost finalizate în același timp	Toate procesele următoare rulează în același timp
\|\| O	SAU asincron	Unul sau mai multe procese din amonte trebuie finalizate	Trebuie să ruleze unul sau mai multe dintre următoarele procese
\|\| O \|\|	SAU sincron	Unul sau mai multe procese din amonte finalizate în același timp	Unul sau mai multe dintre următoarele procese rulează în același timp
\|\| X		S-a încheiat un singur proces în amonte	Începe un singur proces următor

Toate intersecțiile din diagramă sunt numerotate, fiecare număr are un prefix J. Puteți edita proprietățile intersecției folosind dialogul Editor de definiții. Spre deosebire de IDEFO și DFD, săgețile IDEF3 se pot îmbina și ramifica numai prin intersecții.

Obiect de referință. Un obiect de referință din IDEF3 exprimă o idee, concept sau date care nu pot fi asociate cu o săgeată, intersecție sau lucrare. Pentru a adăuga un obiect link, utilizați | R | - (adăugați un obiect link la diagramă - Referent) în paleta de instrumente. Obiectul de referință este desenat ca dreptunghi, similar dreptunghiului de lucru. Numele obiectului link este setat în dialogul Referent (articolul din meniul pop-up Editor de nume), ca nume puteți folosi numele unei săgeți din alte diagrame sau numele unei entități din modelul de date. Obiectele de referință trebuie să fie legate de unități de lucru sau de intersecții cu linii întrerupte. Specificația oficială IDEF3 distinge între trei stiluri de obiecte de referință - necondiționat, sincron și asincron. BPwin acceptă numai obiecte de referință necondiționate. Obiectele de referință sincrone și asincrone utilizate în diagramele de tranziție a stării obiectelor nu sunt acceptate.

5. Simulare

5.1 Model de seră

Model Explorer

Diagrama de context:

Diagrama de descompunere A0:

Diagrama de descompunere A1:

Diagrama IDEF3 A11.1:

Diagrama fluxului de date A12:

Diagrama de descompunere A2:

Diagrama IDEF3 A21.1:

Diagrama de descompunere A3:

Diagrama de descompunere A4:

Diagrama de descompunere A5:

Diagrama de descompunere A6:

Diagrama fluxului de date A63:

5.2 Model matematic

Pentru o descriere mai detaliată a activității economiei cu efect de seră, este necesar să se întocmească un model matematic pentru produsul întreprinderii.

Acest model matematic va descrie calculul prețului unitar în diferite condiții.

e - costul unei unități de mărfuri, determinat de producător, include toate costurile asociate cu producția unei unități de mărfuri, partea principală a acestei cifre este prețul de achiziție al semințelor;

v - prețul de achiziție al semințelor, acesta este prețul la care societatea a achiziționat semințe de la furnizor (secțiunea „achiziționarea semințelor”);

a - cheltuiala cu forța de muncă ( salariuși alte cheltuieli în cadrul întreprinderii);

g - combustibili si lubrifianti (carburanti si lubrifianti);

n - impozitele (partea de consum) se stabilesc de stat si au cota fixa;

k - TVA, taxa pe valoarea adăugată, are și o cotă fixă;

r - prețul de vânzare cu amănuntul, aceasta este suma de bani pentru care producătorul vinde o unitate din produsul său pe piață, de regulă, prețul de vânzare cu amănuntul este determinat de prețul de cost cu un anumit procent din marjă;

s - adaosul companiei pe unitatea de marfă, de regulă, cantitatea acesteia este determinată de fiecare întreprinzător individual, în acest caz este de 40% din prețul de cost, adică (e * 40) / 100

o - pretul cu ridicata, aceasta este suma de bani oferita pe unitatea de marfa, la cumpararea de la 100 unitati, in acest caz este valabila o reducere de 10% din pretul cu amanuntul;

os - reducere pentru achiziții în vrac (os

Model matematic pentru calcularea costului pe unitate de produse fabricate:

Model matematic pentru calcularea prețului de vânzare cu amănuntul pe unitatea de produse fabricate:

Model matematic pentru calcularea prețului cu ridicata pe unitatea de produse fabricate:

o = v + a + g + n + k + s - os

o = r - (r * 10) / 100

Calculul costului produselor la întreprinderea „Sere” este efectuat de departamentul de contabilitate, care controlează fluxul de documente, ia în considerare veniturile și cheltuielile întreprinderii, ține registrele contabile și eliberează certificate. Pe baza acestor formule obținute în modelul matematic al întreprinderii, contabilul poate calcula prețul mărfurilor, atât cu amănuntul, cât și cu ridicata.

6. Analiză comparativă

Pentru a modela întreprinderea noastră, am folosit 5 metodologii: Dragon, UML, IDEF0, IDEF3, DFD. În opinia noastră, cea mai bună opțiune pentru reprezentarea modelului întreprinderii noastre este metodologia UML, deoarece reflectă mai clar și mai precis principalele aspecte ale activității industriei de sere.

Diagramele UML sunt relativ ușor de citit.

De exemplu, diagrama cazurilor de utilizare care a fost utilizată pentru a proiecta sistemul de implementare cu efect de seră permite clientului, utilizatorului final și dezvoltatorului să discute în comun despre funcționalitatea și comportamentul sistemului. „Diagrama de clasă” vă permite să descrieți structura sistemului, demonstrează clasele sistemului, atributele acestora, metodele și dependențele dintre clase, care pot dezvălui în detaliu scenariul și organizarea întreprinderii.

Metodologia Dragon are, de asemenea, o structură foarte clară, dar nu are capacități atât de largi pentru modelarea diferitelor sisteme.

Visio este cel mai simplu și mai accesibil instrument de modelare a proceselor. Acest produs are standard, familiar pentru toate panourile de control în stilul MS Office și se integrează cu ușurință cu orice aplicație din acest pachet, ceea ce face mai ușor pentru utilizatorii fără experiență să lucreze cu el. Cu toate acestea, analiza timpului sau a valorii necesită elaborarea de rapoarte, ceea ce face ca acest produs să fie mult mai dificil de utilizat. Rapoartele tipice nu sunt în mod clar suficiente pentru analiza proceselor de afaceri. În ciuda acestui fapt, Visio este un instrument comun pentru descrierea proceselor de afaceri atât în Rusia, cât și în străinătate. Visio acceptă formatele IDEF și UML pentru descrierea proceselor de afaceri. Dezvoltarea independentă a formatelor este, de asemenea, posibilă.

BPWIN - ocupă un loc intermediar, remarcat prin simplitate suficientă și capacități mari de analiză. Funcționalitatea BPWIN nu se referă doar la desenarea diagramelor, ci și la verificarea integrității și consistenței modelului. BPWIN oferă claritate logică în definirea și descrierea elementelor diagramei, precum și verificarea integrității relațiilor dintre diagrame. Instrumentul oferă corectarea celor mai frecvente erori de modelare. În plus, BPWIN acceptă proprietăți personalizate care sunt aplicate elementelor diagramei pentru a descrie proprietățile specifice ale elementului respectiv. Principala limitare a acestui sistem este standardul IDEF de bază, în care există limitări severe în construcția modelelor. Acest lucru simplifică sarcina de a descrie proceduri simple, dar complică descrierea proceselor mari. Când descriu procese complexe, diagramele 1DEF încep să reprezinte un număr infinit de diagrame interconectate care arată foarte asemănător, ceea ce face dificilă înțelegerea procesului ca întreg.

7. Concluzie:

În cursul acestui curs, toate obiectivele noastre au fost atinse.

În acest sens, am studiat tematica în curs de dezvoltare, respectiv activitatea economiei cu efect de seră. Pentru a face acest lucru, a fost necesar să înțelegem terminologia acestui domeniu, să colectăm documentele de reglementare și legale necesare, să studiem mostre de documente de la compania noastră și să urmăriți mișcarea acestora atât în interiorul întreprinderii, cât și în afara acesteia.

Din aceste activități s-au obținut informații din care s-a realizat o analiză inițială și s-a schițat un model de proiectare.

Următoarea etapă de dezvoltare este etapa de proiectare. Înainte de a începe proiectarea și implementarea, trebuie să aveți o înțelegere precisă și detaliată a cerințelor la un nivel înalt. De asemenea, este foarte util să existe un cadru de cerințe care poate fi folosit ca intrare pentru a modela sistemul. Toate acestea se realizează prin analiză și modelare. Efectuând analize și modelări, am realizat separarea sarcinilor pe care le-am pregătit și simplificat în starea de pre-proiectare pentru activitățile ulterioare de proiectare și implementare. Facem distincție între problemele care trebuie rezolvate și deciziile care trebuie luate pentru a le face față.

Ca urmare a lucrărilor din etapele de modelare și proiectare, am primit un proiect de sistem care conține suficiente informații pentru implementarea acestuia.

După analizarea activității economiei cu efect de seră, putem judeca gradul de volum de muncă al fiecărui departament, ce trebuie automatizat în primul rând și prin ce mijloace.

Pentru a facilita munca, pot fi introduse noi tehnologii care vor facilita munca in ferma noastra.

Literatură:

Rogozov Yu.I., Stukotiy L.N., Sviridov A.S. „Modelarea sistemelor” TRTU, 2004.

S.V. Maklakov „CASE-instrumente pentru dezvoltarea sistemelor informaționale. BPwin și Erwin ”–M .: DialogueMifi, 2001.

Maklakov S. „Combinând abordarea structurală și de obiect în noua generație de instrumente CASE Computer Associates” // Centrul de instruire și consultanță. 2002.

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, a cărei utilizare pentru construirea unui model este foarte convenabilă. 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. Relație 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 către 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 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 percepția vizuală, fiecare bloc și fiecare săgeată ar trebui să aibă propriul nume, care le va identifica 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.

Săgețile de îmbinare sunt adesea folosite și apar întrebări cu privire la denumirea lor. Dar fuzionarea este posibilă numai în cazul transferului omogen de date, 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 față de arcele celeilalte (adică, ele încep la marginea unui proces și se termină ambele la 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.

De exemplu, viteza trenului de la punctul A la punctul B. Trebuie avut în vedere 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 calea ferată. 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:

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

Date de control:

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

Rezultatul modelului este:

Limitarea vitezelor admise cu indicarea motivului limitării.
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.

Cea mai simplă și rapidă modalitate de a crea diagrame folosind notațiile grafice idef0 și idef3 este utilizarea unui editor multiplatform gratuit pentru diagrame, diagrame de flux, diagrame de rețea, diagrame UML și alte deșeuri numite "Dia". Programul a fost tradus în multe limbi, inclusiv rusă.

Puteți descărca programul de pe site-ul său oficial: http://projects.gnome.org/dia/. La momentul scrierii acestui articol, cea mai recentă versiune a Dia a fost numerotată 0.97.1 - și este acea versiune de aproape doi ani. În ciuda acestui fapt, funcționalitatea aplicației este excelentă.

Construirea diagramelor IDEF0

pentru a crea diagrame în notația grafică idef0, este suficient să selectați biblioteca standard de elemente Dia numită "SADT / IDEF0":

Dacă este prima dată când utilizați idef0, atunci vă recomand să citiți mai întâi aceste articole despre această metodologie:

Metodologii moderne pentru descrierea proceselor de afaceri. Metodologie IDEF0 - Kovalev Valery Mikhailovici (revista „Consultant al directorului”, nr. 12, iunie 2004)
IDEF0 ca instrument de modelare a proceselor - Andrey Dvornikov (revista „Avant Partner”, nr. 22 (79), august 2005)
Experiență de utilizare a standardului IDEF0 - Sergey Rubtsov

Construirea diagramelor IDEF3

Idef3 este ceva mai complicat. Nu există un set standard de elemente pentru construirea unei diagrame în notația grafică idef3 din Dia, dar toate blocurile necesare sunt în program. Trebuie doar grupate manual. Pentru a face acest lucru, faceți clic pe meniul: „Fișier -> Categorii și obiecte”. În fereastra care se deschide, faceți clic pe butonul „Creați”. Se va deschide o altă fereastră, în care selectăm elementul „Nume categorie” și introducem acolo „idef3”. Procesul de creare a unei categorii arată astfel:

Deoarece tocmai ați creat această categorie, este în mod natural goală. Trebuie să mutăm elementele schematice necesare în el. De aceea:

Faceți clic pe butonul „Aplicați”, „Închideți” fereastra și gata! Mergem la „alte biblioteci de elemente” și selectăm acolo notația grafică „idef3” pe care am creat-o (este localizată în locul ei alfabetic). Apropo, pentru a scrie în blocuri, este convenabil să folosiți tasta F2. Desigur, acesta nu este un instrument perfect, dar această metodă vă permite să creați diagrame IDEF3 cât mai aproape posibil de notația lor grafică exactă.

Dacă cunoașteți și alte instrumente gratuite pentru construirea de diagrame în notația grafică IDEF3, atunci împărtășiți despre asta tuturor în comentarii.

Învață să vezi și să înțelegi structura funcțională a afacerii tale!

În prezent, în Rusia, interesul pentru standardele de management general acceptate în Occident a crescut brusc, cu toate acestea, în practica reală de management, există un moment foarte indicativ. Mulți directori pot fi încă derutați de o întrebare directă despre structura organizațională a companiei sau structura proceselor de afaceri existente. Cei mai avansați manageri care citesc periodic periodice economice, de regulă, încep să deseneze diagrame ierarhice care sunt de înțeles doar pentru ei, dar chiar și în acest proces ajung de obicei rapid într-o fundătură. Același lucru este valabil și pentru angajații și managerii diferitelor servicii și unități funcționale. În cele mai multe cazuri, singurul set de reguli subliniate, în conformitate cu care întreprinderea trebuie să funcționeze, este un set de reglementări individuale și fișe de post. Cel mai adesea, aceste documente au fost întocmite cu mai bine de un an în urmă, sunt prost structurate și nu sunt interconectate și, ca urmare, pur și simplu adună praf pe rafturi. Deocamdată, o astfel de abordare a fost justificată, deoarece în timpul formării economiei de piață rusă, conceptul de concurență a fost practic absent și nu era nevoie în mod special de a lua în considerare costurile - profitul a fost gigantic. Drept urmare, în ultimii doi ani, am văzut o imagine complet de înțeles: marile companii care au crescut la începutul anilor 90 își pierd treptat pozițiile, până la retragerea lor completă de pe piață. Acest lucru se datorează parțial faptului că întreprinderea nu a implementat standarde de management, conceptul de model funcțional de activitate și misiune a fost complet absent. Cu ajutorul modelării diverselor domenii de activitate, este posibil să se analizeze eficient blocajele în management și să se optimizeze schema generală de afaceri. Dar, după cum știți, la orice întreprindere, doar acele proiecte care aduc profit direct au cea mai mare prioritate, prin urmare, de obicei, doar în timpul unei crize concrete în managementul companiei vorbim despre studiul activităților și reorganizarea acesteia. .

La sfârșitul anilor 90, când piața era suficient de competitivă și profitabilitatea întreprinderilor a început să scadă brusc, managerii au simțit dificultăți enorme în încercarea de a optimiza costurile astfel încât produsele să rămână atât profitabile, cât și competitive. În acest moment s-a manifestat în mod clar nevoia de a avea în fața ochilor un model al activității întreprinderii care să reflecte toate mecanismele și principiile de interconectare a diferitelor subsisteme în cadrul unei singure afaceri.

Însuși conceptul de „modelare a proceselor de afaceri” a intrat în viața de zi cu zi a majorității analiștilor odată cu apariția pe piață a unor produse software complexe concepute pentru automatizarea complexă a managementului întreprinderii. Astfel de sisteme implică întotdeauna o analiză profundă înainte de proiect a activităților companiei. Rezultatul acestui sondaj este o opinie de specialitate, în care paragrafele individuale sunt făcute recomandări pentru eliminarea „gâturilor de sticlă” în managementul activităților. Pe baza acestei concluzii, imediat înainte de implementarea sistemului de automatizare, se realizează așa-numita reorganizare a proceselor de afaceri, uneori destul de gravă și dureroasă pentru companie. Aceasta și, desigur, o echipă care s-a dezvoltat de-a lungul anilor este întotdeauna greu de forțat să „gândească într-un mod nou”. Astfel de anchete complexe ale întreprinderilor sunt întotdeauna sarcini complexe și semnificativ diferite de la caz la caz. Există metodologii și standarde bine încercate pentru rezolvarea unor astfel de probleme de modelare a sistemelor complexe. Aceste standarde includ metodologiile familiei IDEF. Cu ajutorul lor, este posibil să afișați și să analizați eficient modelele activității unei game largi de sisteme complexe în diferite secțiuni. În același timp, amploarea și profunzimea examinării proceselor din sistem sunt determinate de însuși dezvoltatorul, ceea ce permite să nu supraîncărcați modelul creat cu date inutile. În prezent, următoarele standarde pot fi atribuite familiei IDEF:

IDEF0 este o metodologie de modelare funcțională. Cu ajutorul limbajului grafic vizual IDEF0, sistemul studiat se prezintă dezvoltatorilor și analiștilor sub forma unui set de funcții interdependente (blocuri funcționale – în termenii IDEF0). De obicei, modelarea IDEF0 este primul pas în învățarea despre orice sistem;

IDEF1 - o metodologie de modelare a fluxurilor de informații din cadrul sistemului, care vă permite să afișați și să analizați structura și relațiile acestora;

IDEF1X (IDEF1 Extended) este o metodologie pentru construirea structurilor relaționale. IDEF1X se referă la tipul de metodologie „Entity-relationship” (ER – Entity-Relationship) și, de regulă, este utilizat pentru modelarea bazelor de date relaționale legate de sistemul în cauză;

IDEF2 este o metodologie pentru modelarea dinamică a evoluției sistemelor. Din cauza dificultăților foarte serioase de analiză a sistemelor dinamice, acest standard a fost practic abandonat, iar dezvoltarea lui a fost suspendată chiar în stadiul inițial. Cu toate acestea, în prezent există algoritmi și implementările lor computerizate care fac posibilă transformarea unui set de diagrame IDEF0 statice în modele dinamice bazate pe „rețele Petri colorate” (CPN - Color Petri Nets);

IDEF3 este o metodologie de documentare a proceselor care au loc în sistem, care este utilizată, de exemplu, în studiul proceselor tehnologice din întreprinderi. IDEF3 descrie scenariul și fluxul de lucru pentru fiecare proces. IDEF3 are o relație directă cu metodologia IDEF0 - fiecare funcție (bloc funcțional) poate fi reprezentată ca proces separat prin intermediul IDEF3;

IDEF4 este o metodologie pentru construirea de sisteme orientate pe obiecte. Instrumentele IDEF4 vă permit să afișați vizual structura obiectelor și principiile de bază ale interacțiunii lor, permițându-vă astfel să analizați și să optimizați sisteme complexe orientate pe obiecte;

IDEF5 este o metodologie pentru studiul ontologic al sistemelor complexe. Folosind metodologia IDEF5, ontologia unui sistem poate fi descrisă folosind un vocabular specific de termeni și reguli, pe baza căruia se pot forma declarații de încredere despre starea sistemului luat în considerare la un anumit moment în timp. Pe baza acestor afirmații, se formează concluzii despre dezvoltarea ulterioară a sistemului și se realizează optimizarea acestuia.
În acest articol, ne vom uita la cea mai frecvent utilizată metodologie de modelare funcțională IDEF0.

Istoria standardului IDEF0

Metodologia IDEF0 poate fi considerată următoarea etapă în dezvoltarea cunoscutului limbaj grafic pentru descrierea sistemelor funcționale SADT (Structured Analysis and Design Teqnique). În urmă cu câțiva ani, în Rusia a fost publicată o mică ediție a cărții cu același nume, care a fost dedicată descrierii principiilor de bază ale construirii diagramelor SADT. Din punct de vedere istoric, IDEF0 ca standard a fost dezvoltat în 1981 ca parte a unui program extins de automatizare industrială numit ICAM (Integrated Computer Aided Manufacturing) și a fost propus de Forțele Aeriene ale SUA. Familia de standarde IDEF însăși și-a moștenit denumirea de la numele acestui program (IDEF = ICAM DEFinition). În procesul de implementare practică, participanții la programul ICAM s-au confruntat cu necesitatea dezvoltării de noi metode de analiză a proceselor de interacțiune în sistemele industriale. În același timp, pe lângă un set îmbunătățit de funcții pentru descrierea proceselor de afaceri, una dintre cerințele noului standard a fost disponibilitatea unei metodologii eficiente de interacțiune în cadrul „analist-specialist”. Cu alte cuvinte, noua metodă trebuia să ofere lucru în grup la crearea modelului, cu participarea directă a tuturor analiștilor și specialiștilor implicați în proiect.

Ca urmare a căutării soluțiilor adecvate, a luat naștere metodologia de modelare funcțională IDEF0. Din 1981, standardul IDEF0 a suferit mai multe modificări minore, majoritatea de natură limitativă, iar ultima sa revizuire a fost lansată în decembrie 1993 de Institutul Național pentru Standarde și Tehnologie din SUA (NIST).

Elemente și concepte de bază ale IDEF0

Limbajul grafic IDEF0 este surprinzător de simplu și armonios. Metodologia se bazează pe patru concepte principale.

Primul este conceptul de cutie de activități. Un bloc funcțional este reprezentat grafic sub forma unui dreptunghi (vezi Fig. 1) și personifică o anumită funcție în cadrul sistemului în cauză. Conform cerințelor standardului, numele fiecărui bloc funcțional trebuie formulat în modul verbal (de exemplu, „produce servicii”, nu „produce servicii”).

Fiecare dintre cele patru laturi ale unui bloc funcțional are propriul său sens specific (rol), în timp ce:

Partea de sus este Control;

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

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

Dezavantajul este „mecanismul”.

Fiecare bloc funcțional din cadrul unui singur sistem considerat trebuie să aibă propriul său număr unic de identificare.

Figura 1. Bloc funcțional.

A doua „balenă” a metodologiei IDEF0 este conceptul de arc de interfață (Arrow). De asemenea, arcurile de interfață sunt adesea numite fluxuri sau săgeți. Arcul de interfață afișează un element de sistem care este procesat de un bloc funcțional sau afectează în alt mod funcția afișată de acest bloc funcțional.

Afișarea grafică a arcului de interfață este o săgeată unidirecțională. Fiecare arc de interfață trebuie să aibă propriul nume unic (Arrow Label). După cum prevede standardul, numele trebuie să fie un substantiv turnover.

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, mașini, angajați etc.) sau fluxuri de date și informații (documente, date, instrucțiuni etc.).

În funcție de laturile pentru care este potrivit acest arc de interfață, se numește „inbound”, „outbound” sau „control”. În plus, numai blocurile funcționale pot fi „sursa” (începutul) și „chiuveta” (sfârșitul) fiecărui arc funcțional, în timp ce „sursa” poate fi doar partea de ieșire a blocului, iar „chiuveta” poate fi orice dintre cele trei rămase.

De menționat 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ă urmeze niște reguli (afișate de arcul de control) și trebuie să producă un rezultat (arc de ieșire), altfel nu are sens să îl luăm în considerare.

Când construiți IDEF0 - diagrame, este important să separați corect arcurile interfeței de intrare de cele de control, ceea ce adesea nu este ușor. De exemplu, figura 2 prezintă blocul funcțional „Procesează piesa de prelucrat”.

Într-un proces real, lucrătorului care efectuează prelucrarea i se oferă o piesă de prelucrat și instrucțiuni tehnologice pentru prelucrare (sau reguli de siguranță atunci când lucrează cu mașina). Poate fi o greșeală să credem că atât piesa de prelucrat, cât și documentul cu instrucțiuni tehnologice sunt obiecte care intră, dar nu este așa. De fapt, în acest proces, piesa de prelucrat este prelucrată conform regulilor reflectate în instrucțiunile tehnologice, care ar trebui, respectiv, afișate de arcul interfeței de control.

Figura 2.

Un alt lucru este atunci când instrucțiunile tehnologice sunt procesate de tehnologul șef și le sunt aduse modificări (Fig. 3). În acest caz, ele sunt afișate ca un arc de interfață deja primit, iar obiectul de control este, de exemplu, noi standarde industriale, pe baza cărora se fac aceste modificări.

Figura 3.

Exemplele de mai sus subliniază natura aparent similară a arcurilor de interfață de intrare și de ieșire, dar există întotdeauna anumite distincții pentru sistemele din aceeași clasă. De exemplu, în cazul luării în considerare a întreprinderilor și organizațiilor, există cinci tipuri principale de obiecte: fluxuri de materiale (piese, mărfuri, materii prime etc.), fluxuri financiare (numerar și non-numerar, investiții etc.), document fluxuri (documente comerciale, financiare și organizaționale), fluxuri de informații (informații, date de intenție, instrucțiuni orale etc.) și resurse (angajați, mașini, mașini etc.). În acest caz, în diferite cazuri, toate tipurile de obiecte pot fi afișate prin arcuri de interfață de intrare și de ieșire, care controlează doar pe cele legate de fluxurile de documente și informații, iar doar resursele pot fi afișate prin arc-mecanisme.

Prezența obligatorie a arcurilor de interfață de control este una dintre principalele diferențe ale standardului IDEF0 față de alte metodologii ale claselor DFD (Data Flow Diagram) și WFD (Work Flow Diagram).

Al treilea concept de bază al standardului IDEF0 este Descompunerea. Principiul de descompunere este utilizat atunci când descompune un proces complex î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 ca o structură ierarhică a diagramelor individuale, ceea ce îl face mai puțin supraîncărcat și ușor de digerat.

Modelul IDEF0 începe întotdeauna cu o vedere a sistemului ca întreg - un singur bloc funcțional cu arcuri de interfață care se extind dincolo de zona considerată. O astfel de diagramă cu un bloc funcțional se numește diagramă de context și este notă cu identificatorul „A-0”.

Textul explicativ pentru diagrama de context trebuie să indice Scopul construirii diagramei sub forma unei scurte descriere și să stabilească punctul de vedere (Punctul de vedere).

Determinarea și formalizarea obiectivului dezvoltării unui model IDEF0 - este un punct extrem de important. De fapt, scopul identifică zonele relevante din sistemul studiat pe care ar trebui să se concentreze mai întâi. De exemplu, dacă modelăm activitățile unei întreprinderi pentru a construi un sistem informațional pe baza acestui model în viitor, atunci acest model va diferi semnificativ de cel pe care l-am dezvolta pentru aceeași întreprindere, dar cu scopul de optimizare a lanţurilor de aprovizionare.

Punctul 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, renunțând la detalierea și cercetarea elementelor individuale care nu sunt necesare, pe baza punctului de vedere ales asupra sistemului. De exemplu, modelele funcționale ale aceleiași întreprinderi din punctul de vedere al tehnologului șef și al directorului financiar vor diferi semnificativ în direcția detalierii lor. Acest lucru se datorează faptului că, în cele din urmă, CFO nu este interesat de aspectele prelucrării materiilor prime pe mașini de producție, iar tehnologul șef nu are nevoie de scheme desenate ale fluxurilor financiare. Alegerea corectă a punctului de vedere reduce semnificativ timpul petrecut pentru construirea modelului final.

În procesul de descompunere, blocul funcțional, care în diagrama de context afișează sistemul ca întreg, este forat într-o altă diagramă. Diagrama rezultată a celui de-al doilea nivel conține blocuri funcționale care afișează principalele subfuncții ale blocului funcțional al diagramei de context și se numește diagramă Child în raport cu acesta (fiecare dintre blocurile funcționale aparținând diagramei copil se numește, respectiv, Child Box). ). La rândul său, blocul funcțional părinte se numește bloc părinte în raport cu diagrama copil (Parent Box), iar diagrama căreia îi aparține se numește diagramă părinte (Parent Diagram). Fiecare dintre sub-funcțiile diagramei copil poate fi detaliată în continuare printr-o descompunere similară a blocului funcțional corespunzător. Este important de menționat că în fiecare caz de descompunere a unui bloc funcțional, toate arcurile de interfață incluse în acest bloc sau care ies din acesta sunt fixate în diagrama copil. Acest lucru realizează integritatea structurală a modelului IDEF0. Principiul descompunerii este prezentat clar în Figura 4. Ar trebui să acordați atenție relației dintre numerotarea blocurilor funcționale și diagramele - fiecare bloc are propriul său număr de serie unic pe diagramă (numărul din colțul din dreapta jos al dreptunghiului) , iar desemnarea în unghiul drept indică numărul diagramei copil pentru acest bloc... Absența acestei denumiri înseamnă că nu există nicio descompunere pentru acest bloc.

Există adesea cazuri în care arcele individuale de interfață nu au sens să fie luate în considerare în continuare în diagramele copil sub un anumit nivel în ierarhie sau invers - arcele individuale nu au sens practic peste un anumit nivel. De exemplu, nu are sens să reflectăm arcul de interfață care înfățișează un „detaliu” la intrarea în blocul funcțional „Prelucrat pe strung” în diagrame de niveluri superioare - acest lucru va supraîncărca diagramele și le va face dificil de înțeles. Pe de altă parte, este nevoie de a scăpa de arcuri de interfață „conceptuale” separate și de a nu le detalia mai profund de un anumit nivel. Pentru a rezolva astfel de probleme, standardul IDEF0 prevede conceptul de tunel. Desemnarea Arrow Tunnel sub forma a două paranteze în jurul începutului arcului de interfață denotă că acest arc nu a fost moștenit din blocul părinte funcțional și a apărut (din „tunel”) doar în această diagramă. La rândul său, aceeași desemnare în jurul capătului (săgeata) arcului de interfață în imediata apropiere a blocului receptor înseamnă faptul că în diagrama copil a acestui bloc acest arc nu va fi afișat și nu va fi luat în considerare. Cel mai adesea se întâmplă ca obiectele individuale și arcurile lor de interfață corespunzătoare să nu fie luate în considerare la unele niveluri intermediare ale ierarhiei - în acest caz, ele sunt mai întâi „cufundate în tunel” și apoi, dacă este necesar, „întors din tunel”.

Ultimul dintre conceptele IDEF0 este Glosarul. Pentru fiecare dintre elementele IDEF0: diagrame, blocuri funcționale, arcuri de interfață, standardul existent presupune crearea și menținerea unui set de definiții relevante, cuvinte cheie, narațiuni etc. care caracterizează obiectul afișat de acest element. Acest set se numește glosar și este o descriere a esenței acestui element. De exemplu, pentru o interfață de control arc „ordin de plată”, glosarul poate conține o listă de câmpuri ale documentului corespunzătoare arcului, setul necesar de vize etc. Glosarul completează armonios limbajul grafic, oferind diagramelor informațiile suplimentare necesare.

Figura 4. Descompunerea blocurilor funcționale.

Principiile limitării complexității diagramelor IDEF0

De obicei, modelele IDEF0 transportă informații complexe și concentrate, iar pentru a limita aglomerația lor și a le face lizibile, limitele de complexitate corespunzătoare sunt adoptate în standardul corespunzător:

Limitarea numărului de blocuri funcționale din diagramă la trei până la șase. 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;

Limitarea numărului de arcuri de interfață potrivite pentru un bloc funcțional (lăsând un bloc funcțional) la patru.
Desigur, nu este deloc necesar să urmați cu strictețe aceste restricții, cu toate acestea, după cum arată experiența, ele sunt foarte practice în munca reală.

Disciplina muncii de grup privind dezvoltarea modelului IDEF0

Standardul IDEF0 conține un set de proceduri care permit unui grup mare de oameni din diferite zone ale sistemului modelat să dezvolte și să convină asupra unui model. De obicei, procesul de dezvoltare este iterativ și constă din următoarele etape condiționate:

Crearea unui model de către un grup de specialiști în legătură cu diverse domenii ale întreprinderii. Acest grup se numește Autori în ceea ce privește IDEF0. Construirea unui model inițial este un proces dinamic în timpul căruia autorii întreabă oamenii competenți despre structura diferitelor procese. Pe baza prevederilor existente, a documentelor și a rezultatelor sondajului, este creată o schiță de model a modelului.

Distribuirea proiectului spre revizuire, aprobări și comentarii. În această etapă, se discută despre proiectul de model cu o gamă largă de persoane competente (din punct de vedere al cititorilor IDEF0) din întreprindere. În același timp, fiecare dintre diagramele proiectului de model este criticată și comentată în scris, apoi transferată autorului. Autorul, la rândul său, este de acord și în scris cu critica sau o respinge, conturând logica luării deciziei și returnează proiectul revizuit pentru o analiză ulterioară. Acest ciclu continuă până când autorii și cititorii ajung la un consens.

Aprobare model. Modelul aprobat este aprobat de șeful grupului de lucru în cazul în care autorii modelului și cititorii nu au dezacorduri cu privire la adecvarea acestuia. Modelul final este o vedere consistentă a întreprinderii (sistemului) dintr-un punct de vedere dat și pentru un scop dat.
Vizibilitatea limbajului grafic IDEF0 face ca modelul să fie destul de lizibil pentru persoanele care nu au luat parte la proiectul de creare a acestuia, precum și eficient pentru organizarea de spectacole și prezentări. Pe viitor, pe baza modelului construit, pot fi organizate noi proiecte menite să facă schimbări în întreprindere (în sistem).

Caracteristici ale practicii naționale de utilizare a modelării funcționale prin intermediul IDEF0

În ultimii ani, interesul pentru metodologiile familiei IDEF a crescut constant în Rusia. Observ în mod constant acest lucru, uitându-mă la statisticile apelurilor către pagina mea web personală (http://www.vernikov.ru), care descrie pe scurt principiile de bază ale acestor standarde. În același timp, aș numi interesul pentru astfel de standarde precum IDEF3-5 teoretic, iar în IDEF0 destul de practic justificat. De fapt, primele instrumente Case care permit construirea diagramelor DFD și IDEF0 au apărut pe piața rusă în 1996, simultan cu lansarea cărții populare despre principiile modelării în standardele SADT.

Cu toate acestea, majoritatea directorilor încă consideră aplicarea practică a modelării în standardele IDEF ca o declarație de modă, mai degrabă decât o modalitate eficientă de a optimiza sistemul existent de management al afacerii. Cel mai probabil, acest lucru se datorează unei lipse pronunțate de informații cu privire la aplicarea practică a acestor metodologii și a părtinirii software indispensabile a marii majorități a publicațiilor.

Nu este un secret pentru nimeni că aproape toate proiectele de cercetare și analiză a activităților financiare și economice ale întreprinderilor aflate acum în Rusia sunt legate într-un fel sau altul de construcția de sisteme de control automatizate. Datorită acestui fapt, standardele IDEF, după înțelegerea majorității, au devenit condiționat inseparabile de implementarea tehnologiilor informaționale, deși cu ajutorul lor este uneori posibil să se rezolve eficient chiar și mici probleme locale, literalmente cu ajutorul unui creion și hârtie.

Atunci când desfășurați proiecte complexe de anchetă de întreprinderi, dezvoltarea modelelor în standardul IDEF0 vă permite să afișați vizual și eficient întregul mecanism al activității întreprinderii în contextul dorit. Cea mai importantă este însă colaborarea pe care IDEF0 o oferă. În practica mea, au existat destul de multe cazuri când construcția modelului a fost realizată cu ajutorul direct al angajaților din diferite departamente. În același timp, consultantul le-a explicat într-un timp destul de scurt principiile de bază ale IDEF0 și i-a învățat să lucreze cu aplicația software aferentă. Drept urmare, angajații diferitelor departamente au creat diagrame IDEF ale activităților unității lor funcționale, care urmau să răspundă la următoarele întrebări:

Ce merge la unitatea „la intrare”?

Ce funcții și în ce ordine sunt îndeplinite în cadrul unității?

Cine este responsabil pentru fiecare dintre funcții?

După ce se ghidează executantul atunci când îndeplinește fiecare dintre funcții?

Care este rezultatul muncii (ieșirii) unității?

După ce s-au convenit asupra schițelor de diagrame în cadrul fiecărui departament specific, acestea sunt asamblate de către consultant într-un proiect de model de întreprindere, în care toate elementele de intrare și de ieșire sunt legate. În această etapă, sunt înregistrate toate discrepanțele diagramelor individuale și locurile lor controversate. În plus, acest model trece din nou prin departamentele funcționale pentru coordonarea ulterioară și efectuarea ajustărilor necesare. Drept urmare, într-un timp destul de scurt și cu implicarea unui minim de resurse umane de la o firmă de consultanță (și aceste resurse, după cum știți, sunt foarte scumpe), se obține un model IDEF0 al unei întreprinderi conform „ Principiul așa cum este” și, ceea ce este important, reprezintă o întreprindere cu posturi de angajați care lucrează în ea și cunosc temeinic toate nuanțele, inclusiv cele informale. În viitor, acest model va fi transferat pentru analiză și procesare către analiștii de afaceri care vor căuta blocaje în managementul companiei și vor optimiza procesele cheie, transformând modelul „Așa cum este” în vizualizarea corespunzătoare „Așa cum ar trebui să fie”. Pe baza acestor modificări se face o concluzie finală, care conține recomandări pentru reorganizarea sistemului de management.

Desigur, o astfel de abordare necesită o serie de măsuri organizatorice, în primul rând din partea conducerii întreprinderii chestionate. Acest lucru se datorează faptului că această tehnică presupune atribuirea unor responsabilități suplimentare unor personal în elaborarea și aplicarea practică a noilor metodologii. Cu toate acestea, în cele din urmă, acest lucru dă roade, deoarece o oră suplimentară sau două de muncă ale angajaților individuali pe parcursul mai multor zile pot economisi în mod semnificativ bani pentru plata serviciilor de consultanță către o companie terță (care, în orice caz, va rupe munca) a acelorași angajați cu chestionare și întrebări). Cât despre angajații întreprinderii înșiși, într-un fel sau altul, nu am întâlnit nicio opoziție exprimată din partea lor.

Concluzia din toate acestea se poate face astfel: nu este deloc necesar să se vină cu soluții pentru problemele standard de fiecare dată. Ori de câte ori te confrunți cu nevoia de a analiza un anumit sistem funcțional (de la sistemul de proiectare a navelor spațiale până la procesul de pregătire a unei cine complexe) - folosește metode care au fost încercate și testate de-a lungul anilor. Una dintre aceste metode este IDEF0, care vă permite să rezolvați probleme complexe de viață cu ajutorul instrumentelor sale simple și ușor de înțeles.

Ar putea fi util să citiți: