metodika IDEF0. Zápis, princípy modelovania. Základné metodiky pre zememeračské organizácie. Štandard IDEF0 Modely IDEF0 sa vyvíjajú v procese štrukturálneho rozkladu

V tejto časti je implementovaná metodika určovania, klasifikácie a identifikácie procesov (časť ____) na základe metodiky funkčného modelovania IDEF0.

1. Definícia podnikových procesov vo forme IDEF0-modelu

1.1. Definovanie obchodného procesu.

V prvej fáze popisu je potrebné definovať obchodné procesy v organizácii. Kľúčovým prvkom pri definovaní podnikového procesu je vyhlásenie o účele, ktoré odráža dôvod vytvorenia modelu (popisu) podnikového procesu a definuje jeho účel.

Poznámky:

1 Účelom modelu je zachytiť určitý uhol pohľadu, z ktorého sa na činnosť organizácie pozerá a popisuje ju. Pre rôzne účely môžu byť uhly pohľadu odlišné a modely procesov budú odlišné.

Napríklad pri popise procesov v odevnom závode možno formulovať rôzne ciele: optimalizácia organizačnej štruktúry závodu, vytvorenie systému manažérstva kvality, rozšírenie činností atď.

2 Všeobecným cieľom modelov v tomto dokumente je vytvoriť systém manažérstva kvality, ktorý spĺňa požiadavky STB ISO 9000-2001, STB ISO 9001-2001 a STB ISO 9004-2001.

Na identifikáciu obchodných procesov je potrebné určiť nasledovné:

spotrebitelia produktov a/alebo služieb organizácie;
produkty a/alebo služby vyrobené v organizácii a dodávané zákazníkom;
druhov surovín a ich dodávateľov.

POZNÁMKA Pre rôzne typy produktov alebo rôzne kategórie zákazníkov možno zvážiť rôzne obchodné procesy.

Napríklad odevný závod vyrába (šije) dámske kabáty a uzatvára zmluvy so spotrebiteľmi. Spotrebiteľmi produktov sú obchody s dámskym oblečením a obchodné a sprostredkovateľské spoločnosti. Závod nakupuje suroviny od textilných podnikov, ako aj od obchodných a sprostredkovateľských spoločností.

Továreň je uzavretá akciová spoločnosť. Účelom modelu je vytvoriť systém manažérstva kvality. Na základe týchto informácií možno v činnosti odevnej továrne rozlíšiť jeden obchodný proces - „Výroba dámskych kabátov“. Vstupmi do tohto procesu sú: a) externé informácie vrátane požiadaviek spotrebiteľov (obchodov a firiem); b) suroviny a zásoby; c) zdroje. Výstupmi procesu sú: a) šarže hotových výrobkov určených pre spotrebiteľov; b) informácie pre externých spotrebiteľov. Procesná kontrola sa vykonáva na základe regulačných dokumentov upravujúcich výrobné procesy v závode. Vzhľadom na to, že nás zaujíma proces z pohľadu manažérstva kvality, potom ako externý manažment budeme považovať regulačné dokumenty upravujúce túto oblasť, vrátane požiadaviek STB ISO 9000. Mapa obchodného procesu v odevnej továrni je znázornené na obr. 3.

Ryža. 3 Obchodný proces v odevnej továrni

1.2. Popis štruktúry obchodného procesu

Druhým krokom pri definovaní podnikového procesu je popísanie jeho vnútornej štruktúry. Ak to chcete urobiť, musíte určiť:

z akých procesov pozostáva modelovaný obchodný proces;
ako sa tieto procesy navzájom ovplyvňujú.

V modelovaní IDEF0 sa na popis vnútornej štruktúry procesu používa mechanizmus rozkladu.

V súlade s požiadavkami metodiky IDEF0 je pre dekompozíciu obchodného procesu potrebné vytvoriť diagram potomka. Tento diagram by mal predstavovať procesy, ktoré tvoria obchodný proces v rámci systému manažérstva kvality (QMS).

Uvažujme o rozklade obchodného procesu „Výroba dámskych kabátov“ (obr. 3).

S prihliadnutím na ciele modelovania – súlad podnikového procesu s požiadavkami STB ISO 9001-2001, rozklad podnikového procesu zahŕňa 4 bloky procesov, znázornené na obr. 4.

V súlade s požiadavkami STB ISO 9000 obchodný proces „Výroba dámskych kabátov“ zahŕňa nasledujúce procesy:

- uvedomiť si zodpovednosť vrcholového manažmentu za riadenie kvality;

- vykonávať riadenie zdrojov;

- implementovať procesy životného cyklu;

- vykonávať merania, analýzy a zlepšovanie QMS.

POZNÁMKA: Na obrázku 4 nie sú znázornené interakcie medzi funkčnými blokmi predstavujúcimi proces rozkladu „Výroba dámskych kabátov.“ 1.3 Popis interakcií medzi procesmi

Tretím krokom pri definovaní podnikového procesu je popísanie interakcií medzi procesmi. Interakcia medzi procesmi v IDEF0 je opísaná pomocou oblúkov rozhrania a znamená prenos materiálov a/alebo informácií z výstupov jedného procesu na vstupy (riadenia, mechanizmy) iného procesu.

V metodike IDEF0 je akceptovateľných 5 (päť) typov interakcií medzi blokmi v rámci jedného diagramu (tabuľka 1):

kontrola;
výstup - vchod;
spätná väzba na riadenie;
vstupná spätná väzba;
výstupom je mechanizmus.

stôl 1

	Vzťah kontroly: výstup jedného procesu ovplyvňuje vykonávanie iného procesu, t.j. výstupný oblúk bloku 1 je riadiaci pre blok 2. V STB ISO 9001 takáto interakcia definuje riadiacu funkciu „zodpovednosť za riadenie“ vo vzťahu k iným procesom
	Vstupný vzťah: výstup jedného procesu je vstupom do druhého, t.j. výstupný oblúk bloku 1 je vstupný oblúk pre blok 2. Táto interakcia je typická pre akékoľvek procesy v organizácii, napríklad pre procesy životného cyklu
	Spätná väzba riadenia: Výstupy z jedného procesu ovplyvňujú vykonávanie iných procesov, ktorých vykonávanie následne ovplyvňuje vykonávanie pôvodného procesu. Výstupný oblúk bloku 1 je riadiaci oblúk pre blok 2 a výstupný oblúk bloku 2 je riadiaci oblúk pre blok 1. V STB ISO 9001 môže takáto interakcia určiť: - manažérska funkcia "manažérska zodpovednosť"; - funkcia riadenia „riadenie procesov životného cyklu“; - kontrolná funkcia "meranie, analýza a zlepšovanie"
	Vstupná spätná väzba: výstup z jedného procesu je vstupom pre iný proces, ktorého výstup je preň vstupom, t.j. výstupný oblúk bloku 2 je vstupom pre blok 1, ktorého výstup je jeho vstupom. V STB ISO 9001-2001 môže takáto interakcia definovať manažérsku funkciu „riadenie procesov životného cyklu“
	Prepojenie „výstup – mechanizmus“: výstup jedného procesu je mechanizmom pre druhý, t.j. výstupný oblúk bloku 1 je oblúk mechanizmu pre blok 2. Tento typ spojenia sa najčastejšie týka procesov poskytovania zdrojov. V STB ISO 9001 môže takáto interakcia definovať manažérsku funkciu „riadenie zdrojov“

Prax ukazuje, že uvedených päť typov interakcií stačí na určenie interakcií medzi procesmi akejkoľvek zložitosti.

Popis interakcií v rámci funkčného modelu procesu bude úplný, keď budú pre každý funkčný blok definované jeho oblúky rozhrania.

POZNÁMKA – Metodológia IDEF0 špecifikuje, že každý blok v modeli musí obsahovať aspoň jeden oblúk vstupu, výstupu, riadenia a mechanizmu. Existuje krátky zoznam výnimiek z tohto pravidla.

Zvážte interakcie medzi procesmi, ktoré tvoria obchodný proces „Vyrobte dámske kabáty“ (obr. 5).

Proces „Implementácia zodpovednosti vrcholového manažmentu za manažérstvo kvality“ je riadiacim procesom pre všetky ostatné procesy. V súlade s tým je výstup tohto procesu – „Politika, ciele, príručka kvality, programy kvality“ riadiacim vstupom pre všetky ostatné procesy uvedené v diagrame (obr. 5).

Proces „Vykonávať riadenie zdrojov“ má vzťah medzi výstupným mechanizmom a procesmi „Implementácia procesov životného cyklu“ a „Meranie, analýza a zlepšovanie QMS“.

Diagram ukazuje spätnú väzbu: výstup procesu „Merať, analyzovať a zlepšovať QMS“ so vstupom procesu „Implementovať zodpovednosť vrcholového manažmentu za manažérstvo kvality“

Poznámka - Pravidlo úplnosti funkčného modelu IDEF0 presne zodpovedá požiadavkám STB ISO 9001 v tom zmysle, že každý proces musí byť zabezpečený zdrojmi (oblúky mechanizmov v modeli IDEF0), riadený (riadiace oblúky), produkovať výstup (výstupné oblúky), spracovávať materiály a/alebo informácie prichádzajúce na jeho vstupy (vstupné oblúky).

Obr. 5 - Interakcie medzi procesmi

Počet úrovní detailov v procese je určený cieľmi modelovania a špecifikami činností modelovanej organizácie. V rámci tejto metodiky je hlavným účelom procesného modelovania analyzovať súlad procesu s požiadavkami systému manažérstva kvality.

V diagrame A0 (obr. 5) je obchodný proces „Výroba dámskych kabátov“ prezentovaný vo forme 4 procesov. Diagram A0 je prvou úrovňou rozkladu (detailu) pre tento proces. Každý zo 4 prezentovaných procesov je zase možné rozložiť. Na obr. 6 je znázornený rozklad procesu „Implementujte procesy životného cyklu“.

Diagram A3 (obrázok 6) zobrazuje proces Implementácia procesov životného cyklu ako šesť procesov, vrátane Make Procurement, ktoré možno tiež rozložiť (Obrázok 7).

Ryža. 6.- Dekompozícia procesu "Implementujte procesy životného cyklu"

Slovník procesov obsahuje zoznam procesov, objektov, s ktorými sa v rámci procesov zaobchádza, a ich definície.

Slovník je abecedný zoznam pojmov. Každý výraz z tohto zoznamu zodpovedá definícii alebo odkazu na zodpovedajúcu definíciu uvedenú v regulačných dokumentoch organizácie alebo vyšších orgánov, nariadeniach atď.

Napríklad pre diagram A34 (obr. 7) bude fragment slovníka vyzerať takto.

Jeden obrázok vydá za tisíc slov

Ľudová múdrosť

V mojej práci je často potrebné nielen študovať a riešiť určitý problém, ale identifikovať jeho umiestnenie vo všeobecnom modeli práce spoločnosti. Nestačí pochopiť, že určitá jednotka nefunguje správne, je dôležité pochopiť, ako interaguje s ostatnými. V opačnom prípade nie je možné identifikovať všetky existujúce problémy a zvoliť najlepšiu metódu riešenia problému. A na to je potrebné študovať prácu spoločnosti a zostaviť jej funkčný model.

Samozrejme, teoreticky by mal mať manažér funkčný model práce firmy a je jedno, či sa bavíme o organizácii práce skladu alebo o IT systéme od vedenia až po aplikáciu. Ale v skutočnosti to takmer nikdy nedopadne, a preto v procese štúdia a hľadania riešenia problému, ktorý nastolil klient, vytváram aj svojpomocne funkčný model práce firmy alebo určitého procesu (funkcie). .

Pár slov o výhodách grafiky

Ako viete, funkčné modely IDEF0 sú vždy grafické diagramy. Majú svoje vlastné charakteristiky a pravidlá zostavovania. O tom si povieme trochu neskôr. Teraz by som rád uviedol pár príkladov efektivity grafiky. Prečo sa na to zameriavam? S najväčšou pravdepodobnosťou si po mojom tvrdení o potrebe funkčného modelu práce firmy veľa ľudí myslelo, že toto všetko nie je potrebné, dá sa slovami vysvetliť, ako tá či oná funkcia vo firme funguje. To je to, o čom chcem hovoriť.

A na začiatok si spravíme malý exkurz do histórie. Vráťme sa do ďalekého roku 1877, počas rusko-tureckej vojny. Vtedy polygraf Sytin prvýkrát použil grafiku pri opise vojenských operácií. Teraz je nám to všetko známe, pri popise akejkoľvek bitky sa každému pred očami objavia karty so šípkami, ktoré jasne ukazujú priebeh bitky. A v tých časoch sa vojenské akcie popisovali slovami. Pre každý boj je veľa, veľa slov. A bolo veľmi ťažké pochopiť, čo sa nakoniec stalo.

Preto bol Sytin nápad skutočne revolučný – začal tlačiť litografické kópie máp zobrazujúcich opevnenia a rozmiestnenia vojenských jednotiek. Tieto karty sa volali „Pre čitateľov novín. Prínos“. Myšlienka sa ukázala ako taká relevantná, že úplne prvé vydanie „Manuálov“ bolo okamžite vypredané. A potom boli takéto aplikácie veľmi žiadané. Dôvod je zrejmý. Grafika pomohla pochopiť, čo bolo takmer nemožné rozlíšiť iba pomocou slov.

Podobný príklad bezradnosti slovných opisov môžem uviesť z vlastnej praxe. Jeden z mojich klientov veľmi požiadal o implementáciu ERP systému pre svoju spoločnosť. Na otázku, či majú nejakú technickú úlohu, som dostal odpoveď: „Áno, existuje. Ale má 400 strán." Klient sa zároveň veľmi sťažoval, že moji kolegovia, ktorých už skôr kontaktoval, buď od projektu úplne upustili, alebo označili za zjavne premrštené ceny. Potom, čo som videl, že zadávacie podmienky majú skutočne 400 strán a pozostávajú výlučne z textového popisu, pochopil som dôvody správania vývojárov. Čítať taký objem textu, vŕtať sa v ňom, triediť všetky nuansy len preto, aby ste pochopili úlohu a pomenovali cenu, je naozaj veľmi ťažké.

Tomuto klientovi som ponúkol alternatívnu možnosť - popísať všetko, čo sa dá, graficky formou zápisov. Ukázala mu príklady modelovania. Výsledkom je, že teraz prehodnocujú svoje želania a dizajn technickej úlohy.

Poznám aj mnoho ďalších príkladov, kedy grafické modelovanie biznis procesov pomohlo tak mojim kolegom, biznis konzultantom a vývojárom, ako aj samotným biznismenom.

Prečo je to dôležité pre moju prácu

Moja práca vždy súvisí s vykonávaním zmien v existujúcom systéme. A aby ste mohli urobiť zmeny a dosiahnuť požadovaný výsledok, musíte študovať to, čo teraz existuje. A nezáleží na tom, čo presne robíme – nastavíme alebo nainštalujeme CRM systém od nuly, vytvoríme efektívny ERP systém, integrujeme rôzne systémy na zvýšenie automatizácie práce vo všeobecnosti. V každom prípade musíte najskôr získať predstavu o existujúcej schéme práce a až potom môžete navrhnúť nejaké zmeny a premyslieť možnosti riešenia problému.

Po preštudovaní aktuálneho stavu vytváram, ako každý iný špecialista tretej strany, obchodnú ponuku, v ktorej čo najpodrobnejšie zverejňujem svoju predstavu o aktuálnej situácii, ako aj úkony, ktoré je potrebné vykonať, aby vyriešiť úlohu a, samozrejme, očakávaný výsledok.

Takéto správy o prehľade práce sú objemné, zaberajú viac ako jednu stranu, čo je na jednej strane nevyhnutné a na druhej strane komplikuje vnímanie. Najprv som si ako mnohí iní mysleli, že objemné reporty sú dobré, lebo človeku sa platí za prácu a treba mu poskytnúť čo najpodrobnejšie informácie.

Typické chyby

Funkčné modelovanie sa vykonáva pomocou širokej škály nástrojov, vrátane tých, ktoré nie sú určené na modelovanie. V druhom prípade neexistuje žiadna kontrola chýb a obmedzenia normy. Túžba zviditeľniť sa a nedostatok skúseností často končia chybami.

Použitie rôznych farieb

Všetky prvky v diagrame sú rovnako dôležité. Vo funkčnom modelovaní nie sú žiadne viac či menej dôležité prvky. Zmiznutie akéhokoľvek povedie k narušeniu procesu a výrobným chybám.

Používatelia sa často pri modelovaní na papieri alebo v rôznych programoch snažia zvýšiť viditeľnosť pomocou rôznych farieb. Toto je jedna z najčastejších chýb. V skutočnosti použitie farebných šípok a blokov len pridáva zmätok a skresľuje vnímanie diagramu.

Váš model by mal byť čitateľný v čiernej a bielej farbe bez akýchkoľvek ďalších farebných schém. Tento prístup zároveň pomáha predchádzať nedorozumeniam a disciplinuje tvorcu modelu, čo vedie k lepšej čitateľnosti a gramotnosti modelu.

Príliš veľa blokov

Pri zostavovaní modelu sa často snažia zobraziť všetky nuansy práce spoločnosti so všetkými detailmi na jednom hárku. Výsledkom je veľmi veľké množstvo blokov s veľkým počtom ovládacích šípok. V tomto prípade sa stráca čitateľnosť.

Najlepšia možnosť je podrobný, dostatočný na pochopenie problému a nič viac. Detailný detail práce každého oddelenia alebo aj zamestnanca je možné odhaliť pri výbere detailného pohľadu na konkrétny proces. A takáto štruktúra sa vytvára iba vtedy, ak je to skutočne nevyhnutné pre prácu alebo rozhodovanie.

Rozpad konštrukcie pri vykonávaní úprav

Dávajte pozor, aby ste nevytvorili zmätok alebo procesy bez prichádzajúcich, odchádzajúcich a iných dôležitých prvkov. Napríklad, ak vo vyššie uvedenom príklade považujem za vhodné posunúť uhol pohľadu na copywritera, odstránim autora zo schémy. A potom sa kontroly „skúsenosti autora a zdroje tretích strán“ a plán publikovania stanú zbytočnými. Veď ich autor používa. Copywriter pracuje so zvukovým súborom. A ak zostanú vo všeobecnej schéme, potom, keď budú podrobné, povedú, nie je jasné, kam a spôsobia zmätok.

Rovnako, ak sa rozhodnem pridať blok, je dôležité uistiť sa, že má aj všetky požadované atribúty. Starostlivosť je tu veľmi dôležitá, pretože pri modelovaní zložitých obchodných procesov môžu zmeny v jednej časti modelu viesť k zmenám v inej. Musia byť zadané.

Pravidlá pre pomenovanie ovládacích prvkov a blokov

Je dôležité si zapamätať jednoduché pravidlo: ovládacie šípky sa nazývajú podstatné mená, bloky sa nazývajú slovesá. Toto je štandard IDEF0 a tento prístup pomáha predchádzať nejasnostiam a chybám.

Najčastejšie chyby sa robia pri pomenovaní blokov. Napríklad namiesto „Vytvoriť článok“ napíšu „Vytvoriť článok“. Bloky v tomto prístupe sú akcie, a preto musia byť vždy slovesami.

Výhody používania IDEF0

Hneď prvá výhoda je zrejmá – je to viditeľnosť. Vy sami začnete chápať, ako ten či onen systém funguje, a dokážete tiež jasne vysvetliť, kde sú v tomto systéme „úzke miesta“ a ako vám vaše rozhodnutia pomôžu sa ich zbaviť.
Vzájomné porozumenie a nedostatok nezrovnalostí. Pri diskusii o práci spoločnosti pomocou funkčného modelu máte k dispozícii vizuálne a intuitívne bloky úloh s ovládacími prvkami. Okrem toho funkčné modelovanie zahŕňa v prípade potreby vytvorenie slovníka, v ktorom sú uvedené konvencie a termíny. Výsledkom je, že vy a klient, manažér a ďalší zamestnanci hovoríte pri diskusii o probléme rovnakým jazykom.
Jednoduchosť a vysoká rýchlosť tvorby modelu. Naučiť sa modelovať samozrejme nie je také jednoduché, ako to znie. Koniec koncov, schéma je v skutočnosti ultrahustá prezentácia informácií, ktorá je veľmi dobrá na pochopenie, ale na implementáciu takejto prezentácie je potrebný špeciálny prístup. V tomto prípade mozog analytika pôsobí na jednej strane ako veľmi silný lis a na druhej strane ako filter. Ale so skúsenosťami sa tento proces stáva veľmi rýchlym. Získate tak nástroj, ktorý vám pomôže zistiť, čo sa deje v konkrétnom systéme, a pomocou v krátkom čase vytvorenej názornej pomôcky znázorniť kolegom či zákazníkom dôležité body.
Disciplína a nedostatok chýb.Štandard IDEF0 má prísne rámce a pravidlá. Tento prístup je disciplinovaný a zvyk konať v rámci normy pomáha vyhnúť sa chybám z nepozornosti. Akékoľvek porušenie normy je okamžite viditeľné.

Aká je náročnosť používania IDEF0

Je dôležité pochopiť, že iba v najjednoduchších prípadoch dvaja obchodní analytici vytvoria presne rovnaké funkčné modely na popis práce spoločnosti. Akýkoľvek model je odrazom skúseností analytika, hĺbky pochopenia podnikania, ktoré sa snaží opísať, ako aj nejakým spôsobom jeho osobného pohľadu na toto podnikanie. Tie. človek rozvíja biznis model z pohľadu lídra, ako keby bol lídrom.

Zároveň si myslím, že biznis analytik nie je tak celkom povolanie, biznis analytike sa venuje každý biznis líder či vývojár nejakých systémov, ktorý analyzuje biznis a snaží sa vybudovať čo najefektívnejší systém. Práve pre týchto ľudí a na tieto účely je určený nástroj IDEF0.

Preto je veľmi dôležité pri zostavovaní funkčného obchodného modelu „tak, ako je“, neustále konzultovať s vedúcim spoločnosti, aby nedošlo k chybám, ktoré budú automaticky znamenať chyby vo fázach rozkladu. V nasledujúcich fázach môže byť potrebná aj dodatočná koordinácia s vedúcimi štrukturálnych divízií a zamestnancami. Iba ak váš funkčný model „tak ako je“ skutočne odráža skutočný stav vecí, môžete urobiť nejaké zmeny a návrhy. A na dosiahnutie kvalitných výsledkov v takejto práci sú potrebné predovšetkým praktické skúsenosti a znalosť osobitostí konkrétneho druhu podnikania.

Viac článkov na túto tému.

Ďalej zvážte štandardné metódy systémovej štrukturálnej analýzy opísané v sérii amerických federálnych noriem " Definícia Icam", v súlade s . Podrobné informácie o všetkých štandardoch v tejto sérii nájdete na http://www.idef.com.

Štandardné IDEF0(FIPS183) je určený na vytvorenie funkčného modelu, ktorý zobrazuje štruktúru a funkcie systému, ako aj toky informácií a materiálnych objektov, ktoré tieto funkcie spájajú. Tento dokument je návrhom (z iniciatívy Ministerstva obrany USA) vo forme technológie na analýzu zložitých systémov SADT(Structured Analysis and Design Technique), ktorý vyvinula skupina amerických analytikov pod vedením Douglasa Rossa v roku 1973.

Metóda navrhovaná štandardom IDEF0 je určená na funkčné modelovanie, teda modelovanie výkonu funkcií objektu vytvorením popisného grafického modelu, ktorý ukazuje, čo, ako a kto robí v rámci podniku. Funkčný model je štruktúrovaný obraz funkcií výrobného systému alebo prostredia, informácií a objektov, ktoré tieto funkcie spájajú. Model je zostavený dekompozičnou metódou: od veľkých kompozitných štruktúr po menšie, jednoduchšie. Prvky každej úrovne rozkladu predstavujú akcie na spracovanie informácií alebo materiálnych zdrojov za určitých podmienok pomocou špecifikovaných mechanizmov. Každá akcia je za určitých podmienok pomocou časti daných mechanizmov rozložená na menšie operácie na spracovanie určitej časti informácií alebo materiálnych zdrojov. Operácie sa rozkladajú podobne. Výsledkom posledného kroku rozkladu by mal byť model s granularitou, ktorý spĺňa požiadavky stanovené na samom začiatku procesu tvorby modelu.

Metodológia IDEF0 je založená na nasledujúcich princípoch:

1. Systém a model... Model je umelý objekt, ktorý je odrazom (obrazom) systému a jeho komponentov. M simuluje A, ak M odpovedá na otázky o A... Tu M- Model, A- modelovaný objekt (originál). Model je vyvinutý na pochopenie, analýzu a rozhodovanie o rekonštrukcii (reinžinieringu) alebo výmene existujúceho alebo návrhu nového systému. Systém je súbor vzájomne prepojených a interagujúcich častí, ktoré vykonávajú nejakú užitočnú prácu. Časti (prvky) systému môžu byť ľubovoľnou kombináciou rôznych entít vrátane ľudí, informácií, softvéru, zariadení, produktov, surovín alebo energie. Model popisuje, čo sa v systéme deje, ako je riadený, aké entity transformuje, aké nástroje používa na vykonávanie svojich funkcií a čo produkuje.

2. Blokové modelovanie a jeho grafické znázornenie... Hlavným koncepčným princípom metodiky IDEF je reprezentácia akéhokoľvek skúmaného systému ako súboru vzájomne sa ovplyvňujúcich a vzájomne prepojených blokov, ktoré odrážajú procesy, operácie, akcie prebiehajúce v skúmanom systéme. V IDEF0 sa všetko, čo sa deje v systéme a jeho prvkoch, nazýva funkciami. Každá funkcia má priradený blok. Na diagrame IDEF0 (častejšie označovanom ako diagram SADT), ktorý je hlavným dokumentom analýzy a návrhu systémov, je blok obdĺžnik. Rozhrania, cez ktoré blok interaguje s inými blokmi alebo s prostredím mimo modelovaného systému, sú reprezentované šípkami vstupujúcimi alebo vychádzajúcich z bloku. Prichádzajúce šípky ukazujú, aké podmienky musia byť súčasne splnené, aby bola vykonaná funkcia opísaná blokom.

3. Prísnosť a formalizmus... Vývoj modelov IDEF0 si vyžaduje dodržiavanie množstva prísnych formálnych pravidiel, ktoré poskytujú metodológii výhody jednoznačnosti, presnosti a integrity komplexných vrstvených modelov. Tieto pravidlá sú popísané nižšie z hľadiska technológie SADT. Tu je uvedené len to hlavné: všetky fázy a fázy vývoja a úprav modelu by mali byť prísne, formálne zdokumentované, aby počas jeho prevádzky nevznikali žiadne otázky súvisiace s neúplnou alebo nesprávnou dokumentáciou.

4. Iteratívne modelovanie... Vývoj modelu v IDEF0 je iteratívny postup krok za krokom. V každom kroku iterácie vývojár navrhne verziu modelu, ktorá je prediskutovaná, skontrolovaná a následne upravená, po čom sa cyklus opakuje. Takáto organizácia práce prispieva k optimálnemu využitiu znalostí systémového analytika, ktorý vlastní metodiku a techniku IDEF0, a znalostí špecialistov - odborníkov v predmetnej oblasti, do ktorej patrí predmet modelovania.

5. Oddelenie „organizácie“ od „funkcií“... Pri vývoji modelov sa treba vyhnúť prvotnému „naviazaniu“ funkcií skúmaného systému na existujúcu organizačnú štruktúru modelovaného objektu (podnik, firma). To pomáha vyhnúť sa subjektívnemu pohľadu, ktorý vnucuje organizácia a jej vedenie. Organizačná štruktúra by mala vyplývať z použitia (aplikácie) modelu. Porovnanie výsledku s existujúcou štruktúrou umožňuje po prvé posúdiť primeranosť modelu a po druhé navrhnúť riešenia zamerané na zlepšenie tejto štruktúry.

Príklady úloh riešených na základe metodiky modelovania IDEF0:

Analýza a reinžiniering podnikových procesov.

Vývoj kvalitného informačného systému manažmentu dát.

Vývoj predpisov a postupov na zabezpečenie kvality produktov a vytváranie kvalitných systémov spracovania dát. Funkčný model nahrádza tradičné príručky kvality vo forme popisných textových papierových dokumentov – štandardizovanými elektronickými modelmi, ktorých integrita a konzistencia je automaticky zachovaná. V prípade potreby od nich vždy dostanete papierovú správu v bežnej forme.

Navrhovanie informačnej infraštruktúry, postupov a predpisov pre interakciu informácií.

Úlohy analýzy rizík z hľadiska informačnej bezpečnosti.

Uvažujme v súlade s prácou princípy budovania schém pomocou technológie SADT (IDEF0).

Grafický jazyk SADT je jednoduchý a harmonický. Metodika je založená na štyroch hlavných konceptoch.

Prvým z nich je koncept „ funkčný blok". Funkčný blok je graficky znázornený vo forme obdĺžnika (pozri obr. 3.23) a zosobňuje určitú špecifickú funkciu v rámci uvažovaného systému. Podľa požiadaviek normy musí byť názov každého funkčného bloku formulovaný verbálne (napríklad „ produkovať služby", ale nie " produkcia služieb"). Každá zo štyroch strán funkčného bloku má svoj špecifický význam (úlohu), pričom: horná strana má význam „ ovládanie"(Pokr r ol); ľavá strana znamená " vchod» ( vstup); pravá strana znamená " výkon» ( výkon); nevýhodou je " mechanizmus» ( mechanizmus). Každý funkčný blok v rámci jedného uvažovaného systému musí mať svoje jedinečné identifikačné číslo.

metodika IDEF0

metodika IDEF0 predpisuje konštrukciu hierarchického systému diagramov - jednotlivých popisov systémových fragmentov. Najprv sa vykoná popis systému ako celku a jeho interakcie s vonkajším svetom (kontextový diagram), po ktorom sa vykoná funkčný rozklad - systém sa rozdelí na podsystémy a každý podsystém sa opíše samostatne (dekompozičné diagramy) . Potom sa každý podsystém rozdelí na menšie a tak ďalej, kým sa nedosiahne požadovaná úroveň detailov.

Každý IDEF0-grafya obsahuje bloky a oblúky. Bloky predstavujú funkcie simulovaného systému. Oblúky spájajú bloky dohromady a predstavujú interakcie a vzťahy medzi nimi.

Funkčné bloky (práca) v diagramoch sú reprezentované obdĺžnikmi reprezentujúcimi pomenované procesy, funkcie alebo úlohy, ktoré sa vyskytujú v priebehu času a majú rozpoznateľné výsledky. Názov práce musí byť vyjadrený slovným podstatným menom označujúcim činnosť.

IDEF0 vyžaduje, aby diagram mal aspoň tri a nie viac ako šesť blokov. Tieto obmedzenia udržiavajú zložitosť diagramov a modelov na úrovni, ktorá je čitateľná, zrozumiteľná a použiteľná.

Každá strana bloku má špecifický, presne definovaný účel. Ľavá strana bloku je pre vstupy, horná pre ovládanie, pravá pre výstupy a spodná pre mechanizmy. Toto označenie odráža určité systémové princípy: vstupy sa premieňajú na výstupy, kontrolujú limity alebo predpisujú podmienky na vykonávanie konverzií, mechanizmy ukazujú, čo a ako funkcia vykonáva.

Bloky v IDEF0 sú usporiadané podľa dôležitosti, ako to chápe autor diagramu. Toto relatívne poradie sa nazýva dominancia. Dominancia sa chápe ako vplyv, ktorý má jeden blok na ostatné bloky v diagrame. Napríklad najdominantnejším blokom diagramu môže byť buď prvá z požadovanej postupnosti funkcií, alebo plánovacia alebo kontrolná funkcia, ktorá ovplyvňuje všetky ostatné.

Najdominantnejší blok sa zvyčajne nachádza v ľavom hornom rohu diagramu a najmenej dominantný blok je v pravom rohu.

Usporiadanie blokov na stránke odráža autorovu definíciu dominancie. Topológia diagramu teda ukazuje, ktoré vlastnosti majú najväčší vplyv na ostatné. Aby sa to zdôraznilo, analytik môže prečíslovať bloky podľa poradia ich dominancie. Poradie dominancie môže byť označené číslom umiestneným v pravom dolnom rohu každého obdĺžnika: 1 označuje najväčšiu dominanciu, 2 označuje nasledujúcu atď.

Interakcia diel s vonkajším svetom a medzi sebou navzájom je opísaná vo forme šípok, znázornených jednotlivými čiarami so šípkami na koncoch. Šípky predstavujú nejaký druh informácií a sú pomenované podstatné mená.

IDEF0 rozlišuje päť typov šípok.

vchod- predmety používané a premieňané prácou na získanie výsledku (výstupu). Predpokladá sa, že dielo nemusí mať žiadne vstupné šípky. Vstupná šípka je nakreslená ako vstup na ľavú stranu diela.

Kontrola- informácie upravujúce činnosti pracovného miesta. Kontrolné šípky zvyčajne nesú informácie, ktoré naznačujú, že úloha sa má vykonať. Každá úloha musí mať aspoň jednu ovládaciu šípku, ktorá je znázornená ako vstup do hornej strany úlohy.

Výkon- objekty, na ktoré sa konvertujú vstupy. Každá úloha musí mať aspoň jednu výstupnú šípku, ktorá je nakreslená ako vychádzajúca z pravého okraja úlohy.

Mechanizmus- zdroje, ktoré vykonávajú prácu. Šípka mechanizmu je nakreslená ako vstup do spodného okraja diela. Podľa uváženia analytika sa šípky mechanizmu nemusia na modeli objaviť.

Zavolajte- špeciálna šípka ukazujúca na iný model práce. Šípka volania je nakreslená ako vychádzajúca zo spodnej časti diela a používa sa na označenie toho, že nejaká práca sa vykonáva mimo simulovaného systému.

Ryža. 2.1 Typy šípok

V metodológii IDEF0 je potrebných iba päť typov interakcií medzi blokmi na opísanie ich vzťahov: riadenie, vstup, spätná väzba riadenia, spätná väzba vstupu, výstup-mechanizmus. Ovládacie a vstupné odkazy sú najjednoduchšie, pretože odrážajú priame akcie, ktoré sú intuitívne a veľmi jednoduché.

Ryža. 2.2. Ukončite komunikáciu

Ryža. 2.3. Komunikácia manažmentu

Riadiaci vzťah nastane, keď výstup jedného bloku priamo ovplyvňuje menej dominantný blok.

Spätná väzba riadenia a spätná väzba vstupu sú zložitejšie, pretože ide o iteráciu alebo rekurziu. Totiž, odchody z jedného zamestnania ovplyvňujú budúci výkon iných zamestnaní, ktoré následne ovplyvnia pôvodné zamestnanie.

Vtedy dochádza k spätnej väzbe manažmentu; keď výstup nejakého bloku ovplyvňuje blok s veľkou dominanciou.

Vzťahy výstupného mechanizmu sú zriedkavé. Odrážajú situáciu, v ktorej sa výstup jednej funkcie stáva prostriedkom na dosiahnutie cieľa inej.

Ryža. 2.4. Vstupná spätná väzba

Ryža. 2.5. Spätná väzba manažmentu

Vzťahy výstupného mechanizmu sú bežné pri prideľovaní zdrojov (napr. požadované nástroje, vyškolený personál, fyzický priestor, vybavenie, financovanie, materiály).

V IDEF0 oblúk zriedka zobrazuje jeden objekt. Zvyčajne symbolizuje zbierku predmetov. Keďže oblúky predstavujú kolekciu objektov, môžu mať viacero počiatočných bodov (zdrojov) a koncových bodov (cieľov). Preto sa oblúky môžu rozvetvovať a spájať rôznymi spôsobmi. Celý oblúk alebo jeho časť môže vychádzať z jedného alebo viacerých blokov a končiť jedným alebo viacerými blokmi.

Rozvetvujúce sa oblúky, zobrazené ako rozbiehavé čiary, znamenajú, že celý obsah oblúka alebo jeho časť sa môže objaviť v každej vetve. Oblúk je vždy označený pred rozvetvením, aby sa dal názov celej zostave. Okrem toho môže byť každá vetva oblúka označená alebo neoznačená podľa nasledujúcich pravidiel:

neoznačené vetvy obsahujú hmotnosť predmetov špecifikovaných v štítku oblúka pred vetvou;

vetvy označené za bodom rozdvojenia obsahujú všetky alebo časť objektov špecifikovaných v označení oblúka pred rozvetvením.

Zlúčenie oblúkov v IDEFO, znázornené ako zbiehajúce sa čiary, znamená, že obsah každej vetvy vytvorí označenie pre oblúk, ktorý je výsledkom zlúčenia pôvodných oblúkov. Po zlúčení je výsledný oblúk vždy označený príznakom, ktorý označuje novú množinu prvkov po zlúčení. Okrem toho každá pobočka môže alebo nemusí byť označená pred zlúčením podľa nasledujúcich pravidiel:

Ryža. 2.6. Komunikácia výstup-mechanizmus

neoznačené vetvy obsahujú po zlúčení hmotnosť objektov špecifikovaných vo všeobecnom štítku oblúka;

vetvy označené pred zlúčením obsahujú všetky alebo niektoré objekty uvedené vo všeobecnej značke po zlúčení,

počet blokov v diagrame - N;

úroveň rozkladu grafu - L;

bilančný diagram - V;

počet šípok spájajúcich sa s blokom - A

Tento súbor faktorov platí pre každý diagram v modeli. Odporúčania pre požadované hodnoty faktorov grafu budú uvedené nižšie.

Je potrebné usilovať sa o to, aby počet blokov v diagramoch nižších úrovní bol nižší ako počet blokov v nadradených diagramoch, to znamená, že so zvýšením úrovne rozkladu by sa koeficient znižoval. Pokles tohto koeficientu tomu teda nasvedčuje. že ako sa model rozloží, funkcie by sa mali zjednodušiť, preto by sa mal počet blokov zmenšiť.

Grafy musia byť vyvážené. To znamená, že v rámci jedného diagramu je situácia znázornená na obr. 2.7: práca 1 má podstatne viac prichádzajúcich a ovládacích šípok ako odchádzajúcich. Je potrebné poznamenať, že toto odporúčanie sa nemusí dodržiavať v modeloch popisujúcich výrobné procesy. Napríklad pri popise postupu montáže môže blok obsahovať veľa šípok popisujúcich komponenty výrobku a jedna šípka môže ísť von – hotový výrobok.

Ryža. 2.7. Príklad nevyváženého grafu

Uveďme faktor rovnováhy diagramu

Je potrebné sa snažiť Kh bol minimálny pre graf.

Okrem analýzy grafických prvkov diagramu je potrebné zvážiť aj názvy blokov. Na vyhodnotenie názvov je zostavený slovník elementárnych (triviálnych) funkcií modelovaného systému. V skutočnosti by sa do tohto slovníka mali dostať funkcie nižšej úrovne rozkladu diagramov. Napríklad pre databázový model môžu byť základné funkcie „nájsť záznam“, „pridať záznam do databázy“, zatiaľ čo funkcia „registrácia používateľa“ vyžaduje ďalší popis.

Po vytvorení slovnej zásoby a zostavení balíka systémových diagramov je potrebné zvážiť nižšiu úroveň modelu. Ak existujú zhody názvov blokov diagramov a slov zo slovníka, znamená to, že sa dosiahla dostatočná úroveň rozkladu. Koeficient, ktorý kvantitatívne odráža toto kritérium, možno zapísať ako L * C - súčin úrovne modelu počtom zhôd názvov blokov so slovami zo slovníka. Čím nižšia úroveň modelu (vyššie L), tým hodnotnejšie sú náhody.

Po spustení BPWin sa štandardne zobrazí hlavný panel nástrojov, paleta nástrojov a Prieskumník modelov.

Pri vytváraní nového modelu sa zobrazí dialógové okno, v ktorom musíte určiť, či sa model vytvorí nanovo, alebo sa otvorí z úložiska ModelMart, zadajte názov modelu a vyberte metodiku, v ktorej sa model vytvorí ( Obr. 2.8).

Obrázok 2.8 Dialóg na vytvorenie modelu

BPWin podporuje tri metodológie – IDEF0, IDEF3 a DFD. V BPWin je možné zostaviť zmiešané modely, to znamená, že model môže súčasne obsahovať diagramy IDEF0 a IDEF3 a DFD. Zloženie palety nástrojov sa automaticky zmení pri prechode z jedného zápisu na druhý.

Model v BPWin sa považuje za súbor činností, z ktorých každá funguje na súbore údajov. Ak kliknete na ľubovoľný objekt modelu ľavým tlačidlom myši, zobrazí sa kontextové menu, ktorého každá položka zodpovedá editoru vlastnosti objektu.

Vytvorenie modelu systému by malo začať preskúmaním všetkých dokumentov popisujúcich jeho funkčnosť. Jedným z týchto dokumentov sú zadávacie podmienky, a to časti „Účel rozvoja“, „Ciele a ciele systému“ a „Funkčná charakteristika systému“.

Po preštudovaní zdrojových dokumentov a rozhovoroch so zákazníkmi a používateľmi systému je potrebné sformulovať cieľ modelovania a určiť uhol pohľadu na model. Uvažujme o technológii jeho výstavby na príklade systému „Služba zamestnanosti v rámci univerzity“, ktorého hlavné črty boli popísané v laboratórnej práci č.

Sformulujme si cieľ modelovania: popísať fungovanie systému, ktoré by bolo zrozumiteľné pre jeho používateľa, bez toho, aby sme zachádzali do detailov súvisiacich s implementáciou. Model postavíme z pohľadu používateľov (študent, učiteľ, správca, dekanát, firma).

Začnime vytvorením kontextového diagramu IDEF0. Podľa popisu systému je hlavnou funkciou slúžiť svojim zákazníkom vybavovaním požiadaviek od nich. Takto definujeme jedinú prácu kontextového diagramu ako „Obsluhovať klienta systému“. Ďalej definujeme vstupné a výstupné dáta, ako aj mechanizmy a ovládacie prvky.

Pre obsluhu klienta je potrebné ho zaregistrovať v systéme, otvoriť mu prístup do databázy a spracovať jeho požiadavku. Vstupnými údajmi budú „meno klienta“, „heslo klienta“, „zdrojová databáza“, „požiadavka klienta“. Vykonanie dotazu vedie buď k získaniu informácií zo systému, alebo k zmene obsahu databázy (napr. pri vypracovaní odborných posudkov), preto budú výstupnými dátami „reportáže“ a „upravená databáza“. Proces spracovania požiadaviek bude vykonávať monitor systému pod kontrolou správcu.

Definujeme teda kontextový diagram systému (obr. 2.9).

Obrázok 2.9. Kontextový diagram systému

Rozložme kontextový diagram popisujúci postupnosť zákazníckeho servisu:

Určenie úrovne prístupu do systému.

Výber podsystému.

Prístup k subsystému.

Úprava databázy (ak je to potrebné).

Získame schému znázornenú na obr. 2.10.

Po dokončení rozkladu kontextového diagramu prejdite na rozklad diagramu ďalšej úrovne. Pri pohľade na tretiu a nižšiu úroveň sa modely zvyčajne vrátia k nadradeným diagramom a upravia ich.

Ryža. 2.10. Rozklad práce "Služba, klient systému"

Rozložme postupne všetky bloky výsledného diagramu. Prvým krokom pri určovaní úrovne prístupu do systému je určenie kategórie používateľa. Meno klienta sa vyhľadá v užívateľskej databáze, čím sa definuje jeho kategória. Podľa určitej kategórie sú spresnené oprávnenia udelené používateľovi systému. Ďalej sa vykoná postup prístupu do systému, pričom sa skontroluje prístupové meno a heslo. Kombináciou informácií o oprávnení a úrovni prístupu do systému sa pre používateľa vytvorí súbor povolených akcií. Definícia úrovne prístupu do systému teda bude vyzerať tak, ako je znázornené na obr. 2.11.

Ryža. 2.11. Dekompozícia práce "Určenie úrovne prístupu do systému"

Po prejdení procedúry pre prístup do systému monitor analyzuje požiadavku klienta a vyberie subsystém, ktorý požiadavku spracuje. Dekompozícia práce „Addressing a Subsystem“ nezodpovedá cieľu a pohľadu modelu. Používateľa systému nezaujímajú interné algoritmy jeho fungovania. V tomto prípade je pre neho dôležité, že výber subsystému prebehne automaticky, bez jeho zásahu, preto dekompozícia volania do subsystému model len skomplikuje.

Poďme si rozložiť prácu „Spracovanie požiadaviek klienta“ vykonávanú subsystémom spracovania požiadaviek, pričom definujeme kategórie používateľov a oprávnenia. Pred hľadaním odpovede na požiadavku musíte otvoriť databázu (pripojiť sa k nej). Vo všeobecnosti môže byť databáza umiestnená na vzdialenom serveri, takže môže byť potrebné vytvoriť k nej spojenie. Definujme postupnosť práce:

Otvorenie databázy.

Vykonanie žiadosti.

Generovanie správ.

Po otvorení databázy je potrebné informovať systém o nadviazaní spojenia s databázou a následne vykonať požiadavku a vygenerovať reporty pre užívateľa (obr. 2.12).

Je potrebné poznamenať, že "Vykonanie požiadavky" zahŕňa prácu rôznych podsystémov. Napríklad, ak požiadavka obsahuje testovanie, potom bude vykonaná subsystémom odborných a psychologických testov. Vo fáze vykonávania dotazu môže byť potrebné zmeniť obsah databázy, napríklad pri vypracovaní odborných posudkov. Diagram preto musí poskytovať takúto možnosť.

Ryža. 2.12.

Pri analýze výsledného diagramu vyvstáva otázka, aké sú pravidlá pre generovanie reportov? Je potrebné mať vopred vytvorené šablóny, podľa ktorých sa uskutoční výber z databázy, pričom tieto šablóny musia zodpovedať požiadavkám a musia byť vopred určené. Okrem toho by klient mal dostať možnosť vybrať si formu správy.

Opravme diagram tak, že k nemu pridáme šípky „Šablóny výkazov“ a „Žiadosti o zmenu databázy“ a šípku tunela „Systémový klient“. Tunelovanie "System Client" sa používa preto, aby sa šípka neumiestnila na hornom grafe, pretože funkcia výberu formulára správy nie je natoľko dôležitá, aby sa zobrazila na nadradenom grafe.

Zmena diagramu povedie k úprave všetkých rodičovských diagramov (obr. 2.13 - 2.15).

Prácu "Vykonanie dotazu" je vhodné dekomponovať pomocou DFD diagramu (laboratórna práca č. 3), keďže metodika IDEF0 považuje systém za súbor vzájomne prepojených prác, čo slabo odráža procesy spracovania informácií.

Ryža. 2.13. Dekompozícia práce "Spracovanie požiadavky klienta"

Ryža. 2.14. Rozklad práce „Systémová klientská služba“ (možnosť 2)

Ryža. 2.15. Diagram kontextu systému (možnosť 2)

Prejdime k rozkladu posledného bloku „Zmena databázy“. Z pohľadu klienta sú tieto systémy umiestnené v jednej databáze. V systéme je v skutočnosti šesť databáz:

Databáza používateľov,

DB študentov, (možnosť 2)

DB voľných pracovných miest,

Databáza výkonu,

DB testov,

DB odborných posudkov,

DB súhrn.

Podľa účelu modelovania je dôležité, aby klient pochopil, že prijaté dáta nie sú v systéme okamžite aktualizované, ale prechádzajú dodatočnou fázou spracovania a kontroly. Algoritmus zmeny môže byť formulovaný takto:

Je určená databáza, v ktorej sa budú informácie meniť.

Prevádzkovateľ vytvorí dočasný súbor údajov a poskytne ich správcovi.

Správca kontroluje údaje a vkladá ich do databázy.

Tento model je možné implementovať iným spôsobom, pričom poskytuje možnosť aktualizovať databázu priamo na požiadanie, čím sa obíde proces kontroly údajov. V tomto prípade je potrebné zabezpečiť kontrolu integrity databázy, aby nedošlo k jej poškodeniu. V tomto prípade bude diagram vyzerať takto (obr. 2.17).

Ryža. 2.16. Dekompozícia práce "Zmena databázy"

Ryža. 2.17. Dekompozícia práce „Zmena databázy“ (možnosť 2) Pre prvú možnosť, znázornenú na obr. 2.12

Uskutočnenie ďalšej dekompozície „Zmien databázy“ skomplikuje model a vysvetlí, ako sa v systéme vykonáva fyzická zmena databázy. V tomto prípade používateľ nedostane žiadne ďalšie informácie o práci systému služieb zamestnanosti. Túto prácu je vhodné rozložiť v procese návrhu databázového systému vo fáze vytvárania logického databázového modelu.

V ďalšom laboratóriu sa vykoná dekompozícia práce vykonania dotazu, ktorá ilustruje použitie diagramov DFD na popis procesov spracovania informácií.

Urobme kvantitatívnu analýzu modelov znázornených na obr. 2.12 a 2.13 podľa vyššie uvedeného postupu. Uvažujme správanie sa koeficientu ^ pre tieto modely. Nadradený diagram „Spracovanie požiadavky klienta“ má koeficient 4/2 = 2 a diagram rozkladu je 3/3 = 1. Hodnota koeficientu sa znižuje, čo naznačuje zjednodušenie popisu funkcií s poklesom úrovne modelu. .

Zvážte zmenu koeficientu TO b v dvoch modelových variantoch.

pre druhú možnosť

Koeficient TO b nemení svoju hodnotu, preto sa rovnováha diagramu nemení.

Budeme predpokladať, že úroveň dekompozície uvažovaných diagramov je dostatočná na to, aby odrážala účel modelovania, a elementárne funkcie (z pohľadu používateľa systému) sa používajú ako názvy prác na diagramoch nižšej úrovne.

Ak zhrnieme uvažovaný príklad, je potrebné poznamenať, že pri modelovaní systému je dôležité zvážiť niekoľko možností diagramov. Takéto varianty môžu vzniknúť pri opravách diagramov, ako to bolo pri „Spracovaní klientskej požiadavky“ alebo pri vytváraní alternatívnych implementácií systémových funkcií (rozklad práce „Úprava databázy“). Zváženie možností vám umožňuje vybrať si tú najlepšiu a zahrnúť ju do balíka diagramov na ďalšie zváženie.

Účel práce:

štúdium základných princípov metodiky IDEF0,
vytvorenie nového projektu v BPWin,
vytvorenie kontextového diagramu,
vytváranie spojení.

Opis systému pomocou IDEF0 sa nazýva funkčný model. Funkčný model je určený na popis existujúcich obchodných procesov, v ktorých sa používajú prirodzené aj grafické jazyky. Na sprostredkovanie informácií o konkrétnom systéme je zdrojom grafického jazyka samotná metodika IDEF0.

Každý IDEF0-grafy a obsahuje bloky a oblúky. Bloky predstavujú funkcie simulovaného systému. Oblúky spájajú bloky dohromady a predstavujú interakcie a vzťahy medzi nimi.

Najdominantnejší blok sa zvyčajne nachádza v ľavom hornom rohu grafu a najmenej dominantný blok je v pravom rohu.

Typy šípok

IDEF0 rozlišuje päť typov šípok.

Výkon- objekty, na ktoré sa konvertujú vstupy. Každá úloha musí mať aspoň jednu výstupnú šípku, ktorá je nakreslená ako vychádzajúca z pravého okraja úlohy.

Ryža. 2.1 Typy šípok

Ryža. 2.2. Ukončite komunikáciu

Ryža. 2.3. Komunikácia manažmentu

Riadiaci vzťah nastane, keď výstup jedného bloku priamo ovplyvňuje menej dominantný blok.

Vtedy dochádza k spätnej väzbe manažmentu; keď výstup nejakého bloku ovplyvňuje blok s veľkou dominanciou.

Vzťahy výstupného mechanizmu sú zriedkavé. Odrážajú situáciu, v ktorej sa výstup jednej funkcie stáva prostriedkom na dosiahnutie cieľa inej.

Ryža. 2.4. Vstupná spätná väzba

Ryža. 2.5. Spätná väzba manažmentu

Vzťahy výstupného mechanizmu sú bežné pri prideľovaní zdrojov (napr. požadované nástroje, vyškolený personál, fyzický priestor, vybavenie, financovanie, materiály).

neoznačené vetvy obsahujú hmotnosť predmetov špecifikovaných v štítku oblúka pred vetvou;
vetvy označené za bodom vetvy obsahujú všetky alebo časť objektov špecifikovaných v označení oblúka pred vetvou.

Ryža. 2.6. Komunikácia výstup-mechanizmus

neoznačené vetvy obsahujú váhu objektov špecifikovaných v zdieľanom označenom oblúku po zlúčení;
vetvy označené pred zlúčením obsahujú všetky alebo niektoré objekty uvedené vo všeobecnej značke po zlúčení,

Kvantitatívna analýza grafov

Na vykonanie kvantitatívnej analýzy diagramov uvádzame modelové ukazovatele:

počet blokov v diagrame - N;
úroveň rozkladu grafu - L;
bilančný diagram - V;
počet šípok spájajúcich sa s blokom - A

Tento súbor faktorov platí pre každý diagram v modeli. Odporúčania pre požadované hodnoty faktorov grafu budú uvedené nižšie.

Ryža. 2.7. Príklad nevyváženého grafu

Uveďme faktor rovnováhy diagramu

Je potrebné sa snažiť Kh bol minimálny pre graf.

BPWin Toolkit

Po spustení BPWin sa štandardne zobrazí hlavný panel nástrojov, paleta nástrojov a Prieskumník modelov.

Pri vytváraní nového modelu sa zobrazí dialóg, v ktorom uveďte, či sa model vytvorí nanovo, alebo sa otvorí z úložiska ModelMart, zadajte názov modelu a vyberte metodiku, v ktorej sa model vytvorí ( Obr. 2.8).

Obrázok 2.8 Dialóg na vytvorenie modelu

Príklad

Začnime vytvorením kontextového diagramu IDEF0 - Podľa popisu systému je hlavnou funkciou slúžiť svojim zákazníkom spracovaním požiadaviek od nich. Takto definujeme jedinú prácu kontextového diagramu ako „Obsluhovať klienta systému“. Ďalej definujeme vstupné a výstupné dáta, ako aj mechanizmy a ovládacie prvky.

Kontextový diagram

Definujeme teda kontextový diagram systému (obr. 2.9).

Obrázok 2.9. Kontextový diagram systému

Rozložme kontextový diagram popisujúci postupnosť zákazníckeho servisu:

Určenie úrovne prístupu do systému.
Výber podsystému.
Prístup k subsystému.
Úprava databázy (ak je to potrebné).

Získame schému znázornenú na obr. 2.10.

Ryža. 2.10. Rozklad práce "Služba, klient systému"

Ryža. 2.11. Dekompozícia práce "Určenie úrovne prístupu do systému"

Otvorenie databázy.
Vykonanie žiadosti.
Generovanie správ.

Po otvorení databázy je potrebné informovať systém o nadviazaní spojenia s databázou a následne vykonať požiadavku a vygenerovať reporty pre užívateľa (obr. 2.12).

Ryža. 2.12.

Úprava grafu

Zmena diagramu povedie k úprave všetkých rodičovských diagramov (obr. 2.13 - 2.15).

Ryža. 2.13. Dekompozícia práce "Spracovanie požiadavky klienta"

Ryža. 2.14. Rozklad práce „Systémová klientská služba“ (možnosť 2)

Ryža. 2.15. Diagram kontextu systému (možnosť 2)

Prejdime k rozkladu posledného bloku „Zmena databázy“. Z pohľadu klienta sú tieto systémy umiestnené v jednej databáze. V systéme je v skutočnosti šesť databáz: