IDEF0 Diagram na príklad počítačovej hry. Pravidlá názvu kontrolných prvkov a blokov. Diagram toku dát A63

Metodika IDEF0

Metodika IDEF0 Predstavuje stavbu hierarchického diagramu systému - jednotné opisy fragmentov systému. Je najprv popis systému ako celku a jeho interakcie s vonkajším svetom (kontextový diagram), po ktorom sa vykonáva funkčný rozklad - systém je rozdelený na subsystémy a každý subsystém je opísaný samostatne (diagramy rozkladu). Potom sa každý subsystém rozdelí na menšie a tak ďalej na dosiahnutie požadovaného stupňa detailu.

Každý IDEF0-diagramyale Obsahuje bloky a oblúky. Bloky zobrazujú funkcie simulovaného systému. Arcs viažu bloky spolu a zobrazuje interakcie a vzájomné vzťahy medzi nimi.

Funkčné bloky (operácie) Diagramy sú zobrazené obdĺžnikovými obdĺžnikmi, čo znamená menované procesy, funkcie alebo úlohy, ktoré sa vyskytujú v určitom čase a majú rozpoznateľné výsledky. Názov práce musí byť vyjadrené exkluzívnymi podstatnými menami označujúcimi akciu.

IDEF0. Vyžaduje, aby sa diagram má aspoň tri a nie viac ako šesť blokov. Tieto obmedzenia podporujú zložitosť grafov a modelov na úrovni prístupnej na čítanie, porozumenie a používanie.

Každá strana bloku má špeciálny, celkom určitý účel. Ľavá strana bloku je určená pre vstupy, top - kontrolovať, správne - pre výstupy, nižšie - pre mechanizmy. Takéto označenie odráža určité zásady systému: vstupy sa konvertujú na výstupy. Kontrolné limity alebo predpisuje podmienky pre vykonávanie transformácií, mechanizmy ukazujú, že a ako fungovanie vykonáva.

Bloky v IDEF0 sú umiestnené podľa stupňa dôležitosti, pretože autor grafu rozumie. Tento relatívny poriadok sa nazýva dominancia. Dominancia je chápaná ako vplyv, ktorý má jeden blok graf na iných blokoch. Napríklad najdôležitejšia jednotka diagram môže byť buď buď prvý z požadovanej sled funkcií, alebo plánovanie alebo kontrolnú funkciu, ktorá ovplyvňuje všetky ostatné.

Najviac dominantnej jednotky je zvyčajne umiestnená v ľavom hornom rohu grafu a definícia dominantného je v pravom rohu.

Umiestnenie blokov na stránke odráža definíciu dominancie autora. Topológia grafu teda ukazuje, ktoré funkcie majú väčší vplyv na zvyšok. Zdôrazniť to, analytik môže prečíslovať bloky v súlade s poradím ich dominancie. Poradie dominancie môže byť označená číslom umiestneným v pravom dolnom rohu každého obdĺžnika: 1 bude indikovať najväčšiu dominanciu, 2 - nasledovné a tak ďalej.

Interakcia diel s vonkajším svetom a spolu je opísaná vo forme šípok zobrazených jednotlivými riadkami so šípkami na koncoch. Šípky sú niektoré informácie a nazývajú sa podstatné mená.

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

vchod- Objekty používané a prevedené pomocou práce na získanie výsledku (výstup). Predpokladá sa, že práca nemusí mať žiadne vstupné šípky. Vstupná šípka je nakreslená ako súčasť ľavej strany práce.

Kontrola -.Information, riadenie pracovných činností. Kontrolné šípky zvyčajne nesú informácie, ktoré naznačujú, že by sa mala vykonať práca. Každá práca by mala mať aspoň jednu kontrolnú šípku, ktorá je znázornená ako súčasť práce.

Výkon - Objekty, v ktorých sú vstupy konvertované. Každá práca by mala mať aspoň jednu výstupnú šípku, ktorá je ťahaná ako odchádzajúca z pravej strany práce.

Mechanizmus - Zdroje vykonávajúce prácu. Šípka mechanizmu je nakreslená ako súčasť spodnej práce práce. Podľa uváženia sa mechanizmus arogancie analytik nemusí zobraziť na modeli.

Zavolať - Špeciálna šípka označujúca iný model práce. Šípka hovorov je nakreslená ako odchádzajúca zo spodnej časti práce a používa sa na označenie, že niektoré práce sa vykonávajú mimo simulovaného systému.

Obr. 2.1Typy šípok

Metodika IDEF0 vyžaduje len päť typov interakcií medzi blokmi na opis ich vzťahov: Kontrola, vstup, spätná väzba na kontrolu, spätnú väzbu na vstup, výstupný mechanizmus. Správa a vstupná komunikácia sú najjednoduchšie, pretože odrážajú priame vplyvy, ktoré sú intuitívne zrozumiteľné a veľmi jednoduché.

Obr. 2.2.Komunikácia v Exit

Obr. 2.3.Komunikácia v oblasti riadenia

Riadiaci pomer sa vyskytuje, keď výstup jedného bloku priamo ovplyvňuje blok s menšou dominanciou.

Spätná väzba na riadenie a spätnú väzbu na vchode sú zložitejšie, pretože je to iterácia alebo rekurzia. Konkrétne, výstupy z jednej práce ovplyvňujú budúcnosť ďalšiu prácu, ktorá bude neskôr ovplyvniť počiatočnú prácu.

Potom sa vyskytuje spätná väzba o manažmente; Keď výstup niektorého bloku ovplyvňuje blok s veľkou dominanciou.

Komunikácia "Out-mechanizmus" sa zriedka. Odrážajú situáciu, v ktorej sa výstup jednej funkcie stáva prostriedkom na dosiahnutie cieľa pre druhého.

Obr. 2.4.Spätná väzba na vchode

Obr. 2.5.Spätná väzba o riadení

Komunikačný mechanizmus komunikácie je charakteristický pre distribúciu zdrojov zdrojov (napríklad 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 súbor objektov. Keďže oblúky predstavujú množiny objektov, môžu mať mnoho počiatočných bodov (zdrojov) a koncových bodov (destinácie). Preto môžu oblúky pobočky a byť spojené rôznymi spôsobmi. Celý oblúk alebo jeho časť môže zanechať jeden alebo viac blokov a končí v jednom alebo viacerých blokoch.

Rozvetvenie oblúka zobrazeného vo forme odlišných línií znamená, že v každej vetve sa môže objaviť všetok obsah oblúka alebo jeho časti. Oblúk je vždy označený pred vetvením, aby sa názov poskytol celému nastaveniu. Okrem toho môže byť každá vetva oblúka označená alebo nie je označená v súlade s nasledujúcimi pravidlami: \\ t

neznesiteľné vetvy obsahujú hmotnostné predmety uvedené v oblúkovej značke pred vekom;

pobočky označené po mieste vetvenia obsahujú všetky objekty alebo ich časť uvedenú v oblúkovej značke pred vekom.

ARC FUNGERS V IDEFO, znázornené ako zbiehajúce spoločne riadky, označuje, že obsah každej pobočky ide na vytvorenie značky pre oblúk, čo je výsledkom fúzie počiatočného oblúka. Po sútoku je výsledný oblúk vždy označený na určenie novej sady objektov, ku ktorým došlo po kombinácii. Okrem toho každá pobočka pred zlúčením sa môže oženiť alebo spadnúť v súlade s nasledujúcimi pravidlami:

Obr. 2.6.Komunikačný výstup

neznesiteľné vetvy obsahujú hmotnostné predmety uvedené v celkovej značke oblúka po zlúčení;

označené pred zlúčením pobočiek obsahujú všetky alebo niektoré objekty z uvedených ako spoločné po zlúčení,

počet blokov na diagrame - N;

Úroveň rozkladu diagramu - L.;

zostatok grafu - V;

počet šípov spojených s blokom - ALE

Tento súbor faktorov patrí ku každému diagramu modelu. Ďalej budú odporúčania uvedené na požadovaných hodnotách faktorov grafu.

Je potrebné sa usilovať o to, aby sa počet blokov v diagramoch nižších úrovní bude pod počtom blokov na materských diagramoch, to znamená, že so zvýšením úrovne rozkladu by sa koeficient zmenšil. To znamená, že pokles tohto koeficientu to hovorí. Čo, ako sa model rozklad rozklad, by sa táto funkcia mala zjednodušiť, preto by sa počet blokov mal znížiť.

Grafy musia byť vyvážené. To znamená, že v rámci toho istého diagramu by nemali byť žiadne situácie znázornené na obr. 2.7: Prevádzka 1 prichádzajúcich šípov a šípov riadenia je oveľa väčšia ako odchádzajúca. Treba poznamenať, že toto odporúčanie sa nesmie vykonávať v modeloch opisujúcich výrobné procesy. Napríklad pri opise montážneho procesu môže množstvo šípok, ktorí opisujú zložky produktu môže obsahovať množstvo produktu a jedna šípka je publikovaná.

Obr. 2.7.Príklad nevyváženého diagramu

Predstavujeme pomer bilancie grafu

Potrebné sa usilovať Kojbolo to minimálne pre graf.

Okrem analýzy grafických prvkov grafu je potrebné zvážiť mená blokov. Ak chcete odhadnúť mená, je vypracovaný slovník základných (triviálnych) funkcií simulovaného systému. Tento slovník by mal v skutočnosti zahŕňať nižšie, úroveň diagramov rozkladu. Napríklad pre model BD je elementárny na "nájsť záznamovú" funkciu, "Pridajte položku do databázy", zatiaľ čo funkcia "Registrácia používateľa" vyžaduje ďalší popis.

Po vytvorení slovníka a zostavovania balíka systémových diagramov je potrebné zvážiť nižšiu úroveň modelu. Ak existuje náhoda názvov blokov diagramov a slov zo slovníka, hovorí to, že sa dosiahne dostatočná úroveň rozkladu. Koeficient, kvantitatívne odráža tento kritérium, môže byť napísané ako L * c -produkt úrovne modelu podľa počtu názvu bloku zodpovedajúcim slovami zo slovníka. Čím nižšia je úroveň modelu (viac ako l), tým viachodnoťuje hodnotu.

Keď spustíte bpwin, zobrazí sa predvolený panel s nástrojmi, paleta nástrojov a model Explorer.

Pri vytváraní nového modelu sa zobrazí dialógové okno, v ktorom by ste mali určiť, či sa model vytvorí, alebo bude otvorený z archívu modeluMart, pridajte názov modelu a vyberte metodiku, v ktorej bude model vybudovaný (obr. 2.8).

Obr. Dialóg o tvorbe modelu

BPWIN podporuje tri metodiky - IDEF0, IDEF3 a DFD. BPWIN je možné stavať zmiešané modely, t.j. model môže obsahovať IDEF0 aj IDEF3 a DFD diagramy. Kompozícia palety nástroja sa automaticky zmení pri prechode z jednej notácie do iného.

Model v BPWIN sa považuje za súbor práce, z ktorých každý pracuje s určitým súborom údajov. Ak kliknete na ľubovoľný objekt modelu pomocou ľavého tlačidla myši, zobrazí sa kontextové kontextové kontextové kontextové kontextové ponuky, pričom každá položka zodpovedá editoru akéhokoľvek majetku objektu.

Budovanie modelu systému by mal začať so štúdiou všetkých dokumentov, ktoré opisujú jeho funkčnosť. Jedným z týchto dokumentov je technická úloha, konkrétne sekcie "priradenie vývoju", "góly a systémové úlohy" a "systémové funkčné špecifikácie".

Po štúdiu zdrojových dokumentov a prieskumu zákazníkov a používateľov systému je potrebné formulovať účel modelovania a určiť bod pohľadu na modeli. Zvážte technológiu svojej výstavby v príklade systému "zamestnanosti v rámci univerzitného" systému, ktorých hlavné schopnosti boli opísané v laboratórnom pracovnom čísle 1.

Formulujeme účel modelovania: Opíšte fungovanie systému, ktorý by bol pre svojho používateľa jasný, bez toho, aby sa dostal do podrobností súvisiacich s implementáciou. Model bude stavať z hľadiska užívateľov (študent, učiteľ, administrátor, dekan, firma).

Začnime s kontextom kontextu IDEF0 Diagram. Podľa opisu systému je hlavnou funkciou zachovať svojich klientov prostredníctvom požiadaviek na spracovanie, prichádzajúce. Takto definujeme jedinú prácu kontextového diagramu ako "slúžiace klientský systém". Ďalej definujeme vstupné a výstupné údaje, ako aj mechanizmy a riadenie.

Aby ste mohli slúžiť klientovi, musíte ho zaregistrovať v systéme, otvoriť prístup k databáze a spracovať jej požiadavku. Ako vstupné údaje sa použije "názov klienta", "Heslo zákazníka", "Source Database", "požiadavka na zákazníka". Vykonanie žiadosti vedie buď na získanie informácií zo systému, alebo na zmenu obsahu databázy (napríklad pri príprave expertných odhadov), takže výstupné údaje budú "prehľady" a "modifikovaná databáza". Proces spracovania požiadaviek bude vykonávať systémový monitor pod kontrolou administrátora.

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

Obrázok 2.9.Kontextový systémový diagram

Odstráňte rozklad kontextového diagramu a popisuje sekvenciu služby klienta:

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

Vyberte podsystém.

Apelovať na subsystém.

Zmeniť databázu (ak je to potrebné).

Získame graf zobrazený na obr. 2.10.

Po ukončení rozkladu kontextového grafu prejdite na rozklad novej úrovne schémy. Zvyčajne, keď zvažuje tretia a nižšia úroveň, model sa vracia do rodičovských diagramov a upraví ich.

Obr. 2.10.Rozklad práce "Service, Client System"

Rozklad Postupne všetky bloky získaného grafu. Prvým krokom pri určovaní úrovne prístupu k systému je definícia kategórie používateľa. Podľa názvu klienta sa vykonáva v databáze používateľa, definuje svoju kategóriu. Podľa konkrétnej kategórie sa zistia, že právomoci poskytnuté užívateľským systémom. Ďalej sa vykoná prístup systému, kontrola názvu a hesla prístupu. Kombinácia informácií o právomocí a úrovne prístupu k systému je pre používateľa vytvorený súbor povolených akcií. Stanovenie úrovne prístupu k systému sa teda bude vyzerať tak, ako je znázornené na obr. 2.11.

Obr. 2.11.Rozklad práce "Stanovenie úrovne prístupu k systému"

Po absolvovaní procesu prístupu k systému monitor analyzuje požiadavku zákazníka výberom subsystému, ktorý bude žiadosť spracovať. Rozklad práce "Odvolanie na subsystém" nespĺňa účel a hľadisko modelu. Systém systému nemá záujem o vnútorné algoritmy svojej práce. V tomto prípade je pre neho dôležité, že výber subsystému sa vykoná automaticky, bez toho, aby bol jeho zásah, preto rozklad odvolania na subsystém bude len komplikovať model.

Rozklady práce "Spracovanie požiadaviek zákazníka", vykonané požiadaním o požiadavky, definovať kategórie a oprávnenia používateľa. Pred vyhľadávaním odpovede na požiadavku musíte otvoriť databázu (pripojiť sa k nemu). Vo všeobecnom prípade môže byť databáza na vzdialenom serveri, takže môže byť potrebné na vytvorenie spojenia s ním. Určite postupnosť práce:

Otvorenie databázy.

Komunikácia.

Vyrovnanie správy.

Po otvorení databázy je potrebné informovať systém na vytvorenie pripojenia z databázy, po ktorej požiadavka a generovanie správ pre používateľa (obr. 2.12).

Treba poznamenať, že "realizácia žiadosti" zahŕňa prácu rôznych subsystémov. Ak napríklad žiadosť obsahuje testovanie, bude vykonaná subsystémom profesionálnych a psychologických testov. V štádiu vykonávania dotazu môže byť potrebné zmeniť obsah databázy, napríklad pri vypracovaní expertných odhadov. Preto je v diagrame potrebné poskytnúť takúto príležitosť.

Obr. 2.12.

Pri analýze výslednej tabuľky vzniká otázka, ktoré pravidlá sú generáciou správ? Je potrebné mať vopred vytvorené šablóny, pre ktoré sa vykoná vzorka databázy, a tieto šablóny musia byť v súlade s požiadavkami a musia byť vopred určené. Okrem toho musí byť klient poskytnúť možnosť vybrať si formulár správy.

Nastavte tabuľku pridaním "prehľadov šablón" a "Žiadosti o zmenu BD" a Tunnel Arrow "Klientský systém". Aplikuje sa tunelovanie "systémového klienta", aby nebrali šípku do top grafu, pretože funkcia výberu tvaru prehľadu nie je dostatočná na to, aby ju zobrazila na rodičovskej grafe.

Zmena diagramu vytiahne nastavenie všetkých rodičovských diagramov (obr. 2.13 - 2.15).

Rozklad práce "Vykonávanie žiadosti" sa odporúča vykonať DFD DIAGRAM (Laboratórne pracovné číslo 3), pretože metodika IDEF0 považuje systém ako súbor vzájomne prepojených prác, čo zle odráža proces spracovania.

Obr. 2.13.Rozklad práce "Spracovanie požiadaviek zákazníka"

Obr. 2.14.Rozklad práce "System Customer Service" (možnosť 2)

Obr. 2.15.Kontextový systémový diagram (možnosť 2)

Poďme sa obrátiť na rozklad poslednej bloku "DB Zmeniť". Z hľadiska klienta sa tieto systémy nachádzajú v jednej databáze. V skutočnosti existuje šesť databáz v systéme:

Používatelia databázy

Databáza študentov (možnosť 2)

BD voľné miesta,

Databáza

Databázové testy

Databázové odborné hodnotenia

Súhrn DB.

Podľa účelu modelovania klienta je dôležité pochopiť, že prijaté údaje nie sú okamžite aktualizované v systéme, ale prejsť dodatočnou fázou spracovania a kontroly. Zmeny algoritmu môžu byť formulované takto:

Databáza je určená, v ktorej sa informácie zmenia.

Prevádzkovateľ je vytvorený dočasný súbor údajov a je poskytovaný administrátorovi.

Správca vykonáva kontrolu údajov a prispieva k databáze.

Tento model je implementovaný iným spôsobom, ktorý poskytuje možnosť aktualizovať databázu priamo na požiadavky, obchádzanie procesu kontroly údajov. V tomto prípade je potrebné zabezpečiť kontrolu nad integritou databázy, aby sa zabránilo poškodeniu. V tomto prípade bude diagram vyzerať takto (obr. 2.17).

Obr. 2.16.Rozklad práce "Zmeniť databázu"

Obr. 2.17.Rozklad práce "Zmeniť databázu" (možnosť 2) pre prvý variant znázornený na obr. 2.12.

Vedenie ďalšieho rozkladu "BD zmien" komplikuje model vysvetľujúci, ako sa vykonáva fyzická zmena v databáze v systéme. Zároveň užívateľ nedostane žiadne ďalšie informácie o práci systému služieb zamestnanosti. Tento pracovný rozklad sa odporúča vykonávať v procese navrhovania databázy systému vo fáze vytvorenia logického modelu databázy.

Rozklad "Vykonanie dotazu" sa bude vykonávať v nasledujúcich laboratórnych prácach, ilustrujúci používanie DFD diagramov na opis procesov spracovania informácií.

Vykonávame kvantitatívnu analýzu modelov znázornených na obr. 2.12 a 2.13 podľa vyššie opísanej metódy. Zvážte správanie koeficientu ^ v týchto modeloch. Rodičovský graf "Spracovanie žiadosti o zákazníka" Koeficient je 4/2 \u003d 2 a diagramy rozkladu 3/3 \u003d 1. Hodnota koeficientu klesá, ktorá označuje zjednodušenie opisu funkcií s poklesom úrovne modelu.

Zvážte zmenu koeficientu Na b. dve možnosti pre modely.

pre druhú možnosť

Koeficient Na b. nemení svoju hodnotu, preto sa zostatok diagramu nezmení.

Predpokladáme, že úroveň rozkladu uvažovaných diagramov je dostatočná na to, aby odrážala účel modelovania a elementárnych funkcií (z hľadiska používateľa systému) sa používajú v diagramoch dolných úrovní ako položky.

Zhrnutie považované za príklad, je potrebné si všimnúť dôležitosť zváženia viacerých variantov diagramov pri modelovaní systému. Takéto možnosti sa môžu vyskytnúť pri nastavení diagramov, ako bolo vykonané s "spracovaním žiadostí o zákazníka" alebo pri vytváraní alternatívnych implementácií systémových funkcií (rozklad práce "Zmeniť databázu"). Zohľadnenie možností vám umožní vybrať si to najlepšie a umožniť jej v balíku diagramu pre ďalšie zváženie.

Publikované na adrese http://www.allbest.ru/

Relevantnosť úlohy automatizácie počítačov a iných zariadení v podniku sa zvyšuje s veľkým parkom počítačov, kancelárskych zariadení, nákupných a iných zariadení. Najväčšia potreba vedieť, kde a ktorá jednotka sa nachádza na rýchle monitorovanie zmien týkajúcich sa vybavenia, dochádza z IT jednotiek. 2.

Osobitný význam, úloha automatizácie účtovníctva vybavenia získava vo veľkých podnikoch. Liečba Všetok čas rastúcich informačných polí sa stal možnosť len s využitím moderných počítačových technológií. 2.

Na organizovanie systému účtovníctva pre technológie v podniku, udržiavanie účtovníctva počítačov a komponentov, teraz nie je možné bez dodatočného softvéru nainštalovaného na počítači. 2.

Hlavným cieľom termínový papier Je vývoj informačný systém Ak chcete zohľadniť počítačové vybavenie podniku, pomocou metodiky funkčného modelovania a grafického notácie IDEF0, DFD DATA DATA GAFTS CHARTS A DOKUMENTÁCIÍ DOKUMENTÁCIÍM IDEF3, pomocou softvéru Computer Associates ALLFUSIONS MODELER R7.3 softvérového produktu. 2.

2.1 Analýza softvéru 8

Úvod

Relevantnosť úlohy automatizácie počítačov a iných zariadení v podniku sa zvyšuje s veľkým parkom počítačov, kancelárskych zariadení, nákupných a iných zariadení. Najväčšia potreba vedieť, kde a ktorá jednotka sa nachádza na rýchle monitorovanie zmien týkajúcich sa vybavenia, dochádza z IT jednotiek.

Osobitný význam, úloha automatizácie účtovníctva vybavenia získava vo veľkých podnikoch. Liečba Všetok čas rastúcich informačných polí sa stal možnosť len s využitím moderných počítačových technológií.

Na organizovanie systému účtovníctva pre technológie v podniku, udržiavanie účtovníctva počítačov a komponentov, teraz nie je možné bez dodatočného softvéru nainštalovaného na počítači.

Hlavným cieľom práce kurzu je vyvinúť informačný systém na účet pre počítačové vybavenie podniku, s použitím metodiky funkčného modelovania a grafickej notácie IDEF0, DFD DATA DATA FLOW CHARPS a IDEF3 Proces Documentation Standards R7.3 Softvérový produkt.

Na dosiahnutie tohto cieľa je potrebné vyriešiť nasledujúce úlohy:

Analýza softvérových produktov;

Štúdium metód navrhovania informačných systémov;

Funkčné modelovanie kontextového diagramu a schémami rozkladu obchodného procesu (IDEF0) "Účtovníctvo pre počítačové podniky";

Projektovanie informačného systému pomocou diagramov dátového toku (DFD);

Použitie metodiky modelovania a dokumentácie dokumentácie procesov IDEF3.

informačný softvér polylinickej dokumentácie

1. Metódy navrhovania informačných systémov

V modernej praxi manažmentu modelovania a výrobných činností je pojem "obchodný proces" vyrába na určenie objektov modelovania. Pri modelovaní obchodných procesov by sa mala venovať pozornosť viacerým faktorom:

Správne vyhlásenie o cieľoch;

Príslušné povedomie zamestnancov organizácie, pokiaľ ide o ciele a výsledky projektu;

Účinné použitie modelových nástrojov;

Prítomnosť firemných štandardov na opis a reguláciu obchodných procesov.

Pre modelovanie obchodných procesov sa používa niekoľko rôznych metód. Ich nadácia je konštrukčné a objektovo orientované prístupy k modelovaniu. Najviac rozvinuté metódy používajú prvky oboch prístupov. Najbežnejšie metódy možno pripísať:

sADT funkčná metóda modelovania (IDEF0);

metóda modelovania procesov IDEF3;

modelovanie dátových tokov DFD;

Z hľadiska obchodného modelovania má každý z prezentovaných prístupov svoje výhody. Objektový prístup vám umožňuje budovať stabilnejšie na zmenu systému, je to lepšie.

existujúcich štruktúr organizácie. Funkčné modelovanie dobre ukazuje v prípadoch, keď je organizačná štruktúra v procese zmeny alebo je všeobecne slabo zarámovaná. Prístup z vykonaných funkcií je intuitívne lepšie pochopiť výkonných umelcov pri prijímaní informácií z nich o ich súčasnej práci.

Funkčná metóda modelovania IDEF0 (modelovanie funkcií) je súbor pravidiel a postupov určených na vytvorenie funkčného modelu objektu objektu. Funkčný model objektu zobrazuje akcie a prepojenia vyrobené.

V súlade s touto metódou by mal obchodný model vyzerať takto:

Najvyššia úroveň modelu by mala odrážať len kontext systému, ktorý je jeho interakcia s vonkajším svetom.

Na druhej úrovni by mal model obsahovať všetky hlavné činnosti podniku, inými slovami tematicky zoskupené podnikateľské podniky a ich vzťah.

Ďalšie podrobnosti o obchodných procesoch sa vykonávajú prostredníctvom obchodných funkcií, to znamená, že súgregáty operácií zoskupených podľa niektorých funkcií.

Opis základných obchodných operácií sa vykonáva pomocou úlohy algoritmu na jeho vykonanie.

MODELOVANIE DFD DATA MODELOVANIE MODELOVANIA (DIALOVÉ DÁTUME DÁTUME DÁTUME) - Diagramy toku údajov. Hlavnými prostriedkami modelovania funkčných požiadaviek na navrhnutý systém.

Modelové komponenty: diagramy; Dátový slovník; Špecifikácie procesov.

Prvky grafu: Dátový tok; skladovanie; Vonkajšej podstaty.

Mechanizmus dátového toku používaný na modelovanie a prenášanie informácií z jednej časti systému do druhého.

Objekt externej jednotky subjekt mimo kontextu systému, ktorý je.

Úložisko je kúsok dátových tokov v čase, ktorý obsahuje údaje, ktoré sa majú uložiť medzi procesmi.

Hlavné výhody:

schopnosť jednoznačne určiť externé subjekty analýzou informačných tokov vo vnútri a mimo systému;

možnosť navrhovania zhora nadol, čo uľahčuje výstavbu modelu "Ako by mal byť";

prítomnosť špecifikácií procesov nižšej úrovne, ktorá umožňuje prekonať logickú neúplnosť funkčného modelu a vybudovať plnú funkčnú špecifikáciu vyvinutého systému;

modely majú veľmi bohatý súbor prvkov primerane odrážajú ich špecifickosť;

tam sú tiež podporované niekoľkými prípadovými nástrojmi Automatické konverzie algoritms pre hierarchiu DFD do konštrukčných kariet, ktoré demonštrujú intersystém, komunikáciu v intrasystému a hierarchii systému

Nevýhody:

potreba procesov riadenia umelých vstupov, pretože kontrolné účinky (toky) a kontrolné procesy z hľadiska DFD sa nelíšia od obvyklého;

Žiadna koncepcia času, t. Nedostatok analýzy časového intervalu pri konverzii údajov (všetky lehoty musia byť zadané v špecifikáciách procesov).

Metóda modelovania procesov IDEF3 (integrovaná definícia metódy zachytávania procesov) - metodika modelovania a štandardnej dokumentácie procesov vyskytujúcich sa v systéme. Spôsob zdokumentovania technologických procesov poskytuje mechanizmus na dokumentovanie a zhromažďovanie informácií o procesoch. IDEF3 ukazuje kauzálne vzťahy medzi situáciami a udalosťami v zrozumiteľnom expertovom formulári pomocou štrukturálnej metódy vyjadrenia vedomostí o tom, ako systém funguje, proces alebo podnik.

Technika opisujúcej sady údajov IDEF3 je súčasťou štrukturálnej analýzy. Na rozdiel od niektorých metód opisov procesov IDEF3 neobmedzuje Analytics nadmerne tuhé syntaxové rámce, ktoré môžu viesť k vytvoreniu neúplných alebo protichodných modelov.

IDEF3 sa môže použiť aj ako spôsob vytvárania procesov. IDEF3 dopĺňa IDEFO a obsahuje všetko, čo potrebujete na vytvorenie modelov, ktoré môžu byť použité na simuláciu simulačnej analýzy.

2. Projektovanie informačného systému "Účtovníctvo počítačových inžinierskych podnikov"

2.1 Analýza softvéru

Analýza takýchto informačných systémov sa vykonáva na identifikáciu v dôstojnosti a nevýhodách, ako aj na porovnanie funkčnosti, rozhrania, dizajnu a pohodlia jeho používania. Nasledujúce existujúce informačné systémy boli nájdené ako:

Vymýšľajte softvér (IT-invent.ru)

Hardvérový inšpektor softvér (Hwinspector.com)

Konfigurácia 1C: Účtovníctvo počítačov a zariadení 8.1 (Odineskin.ru)

Prvá IP, vymýšľajú, nie je len účtovanie počítačov, tlačiarní, programov a komponentov. To je tiež rovnaký účet pre opravy a služby, podporné vybavenie, objednávky dodávateľom, príjmom a pohybe zariadenia, účtovníctvo zmluvných strán, zamestnancov a oveľa viac. Hlavná forma programu IT vymyslieť program je znázornená na obrázku 1.

Obrázok 1 "Vymyslený"

Vymyslieť to, že je to flexibilný a prispôsobiteľný systém, ktorý má intuitívne rozhranie, objasní to, čo je dobre vnímaný užívateľom z hľadiska dizajnu. Program je pomerne multifunkčný. Chcel by som si všimnúť nasledujúce kľúčové funkcie programu:

Podpora databázy MS Access a MS SQL Server.

Multiplayerový režim prevádzky - Všetky pobočky pracujú s jednou základňou.

Možnosť vytvárania a konfigurácie vlastných ďalších vlastností rôznych typov.

Účtovníctvo pre vykonávanie práce akéhokoľvek druhu v rámci organizácie.

Unikátny systém na vytváranie a tlačových etikiet zásob. Podporné tlačiarne čiarových kódov.

Podporná práca s skenerom čiarového kódu. Vyhľadávacie záznamy v databáze na čiarovom kóde.

Udržiavanie histórie zmien v zariadení.

Účtovníctvo pre opravy a preventívne údržbu zariadení a počítačov.

Logická väzba programov a komponentov so zariadením.

Účtovníctvo spotrebného materiálu, komponentov a kancelárií.

Upevňovacie účtovné jednotky pre zamestnancov organizácie. Aktov prijímania.

Udržanie základne dodávateľov, služieb služieb a iných zmluvných strán.

Flexibilné vymedzenie prístupových práv pre používateľov systému.

Konfigurácia e-mailových upozornení udalostí v programe.

Veľký počet vstavaných tlačených formulárov a prehľadov s možnosťou ich upravovať.

Importovať a zobraziť údaje priamo z Active Directory.

Vymyslený program je sieť. Ak chcete pracovať na sieti s jednou databázou, každý užívateľský program má cestu v súbore dbpath.ini, aby ste napísali cestu k pripojeniu do databázového súboru alebo zadajte túto cestu výberom položky "Súbor" Položka ponuky -\u003e "Zvoľte databázu" . Zároveň nemusíte zabudnúť na nastavenie adresára s databázou čítania a písania pre všetkých používateľov programu.

Druhou IP je program hardvéru inšpektor. Program je určený pre automatizované účtovníctvo a inventár počítačového vybavenia a iných zariadení v organizáciách. Jedinečnosť programu hardvérového inšpektora spočíva v schopnosti udržiavať účtovanie nielen aktuálny stav parametrov počítačov a celú históriu života jednotlivých komponentov. Obrázok 2 zobrazuje vizuálnu reprezentáciu zariadení na strome pracovísk.

Obrázok 2 "Hardvérový inšpektor"

Rozhranie je jednoduché, intuitívne. Pokiaľ ide o dizajn, je prijateľný. Program je multifunkčný. Chcel by som označiť nasledujúce kľúčové funkcie:

Podrobné počítače a softvér;

Životný cyklus účtovných objektov;

Nastavenia importu, softvéru, pracovných miest a sieťových nastavení;

Automatizovaný audit pracovných miest;

Sieťový prechod;

Účtovníctvo a plánovanie spotrebného materiálu;

Účtovníctvo žiadostí od užívateľov;

Zásoby účtov;

Flexibilné oddelenie prístupu;

Vyhľadávanie informácií;

Viac ako 30 vstavaných vlastných správ;

Podrobné adresáre vo všetkých aspektoch účtovníctva;

Hardvérový inšpektor, platený. Jedna licencia dáva právo nainštalovať program na ľubovoľnom počte počítačov v rámci jednej miestnej siete, jednej organizácie.

Tretí je, že je to 1C konfigurácia: účtovníctvo počítačov a zariadení 8.1. Účtovníctvo zariadení je založené hlavne na čiarové číslo, teda akákoľvek vyhľadávacia operácia, výber alebo technológia sa stáva oveľa jednoduchšou. S touto konfiguráciou je vhodné zohľadniť a vykonávať inventár počítačov, kancelárskych zariadení a akýchkoľvek iných materiálov (vybavenie, telefóny, nábytok), ako aj automatizovať iné oblasti činnosti.

Obrázok 3 zobrazuje hlavnú formu konfigurácie 1C.

Obrázok 3 "1c: Účtovné počítače a zariadenia 8.1"

Hlavné charakteristiky produktu:

Účtovníctvo pre akúkoľvek techniku, nábytok, softvér,

Účtovníctvo sériových, zoznamov zásobníkov,

Import z Everest Hardware Audit System (Automatický zber údajov)

Najvýhodnejšie používateľské rozhranie

Účtovní dodávatelia

Kritérium		"Hardvérový inšpektor"	Konfigurácia 1C.
Funkčnosť	Multifunkčné	Multifunkčné	Multifunkčné
Rozhranie	Intuitívne pochopiteľné	Jednoduché - intuitívne	Najvhodnejší
		Prijateľný	Štandardný
Americké pohodlie		Jednoduché použitie	Prispôsobené nastavenia
Dôstojnosť	Pracuje v sieti	Pracuje na miestnej sieti Aktualizácia 2 krát mesačne Jedna licencia môže byť nainštalovaná na ľubovoľnom počte počítačov, v jednej lokálnej sieti, jednej organizácii	Konať voľná \u200b\u200bčiara Konzultácie o e-mailoch a ICQ av prípade potreby sa poraďte s telefónom.
nevýhody	Platený program	Platený program	Platený program

Účtovníctvo pre používateľov a pracovať s nimi

Účtovníctvo Spotrebný materiál

Automatické vyhľadávanie pri skenovaní

Prispôsobené nastavenia atď.

Porovnajte vybrané informačné systémy v tabuľke 1 pre tieto kritériá: funkčnosť, rozhranie, dizajn, užívateľské pohodlie, výhody a nevýhody;

Tabuľka 1 - Porovnanie informačných systémov

Záver: Všetky informačné systémy zvažované obsahujú všetky potrebné funkcie pre účtovníctvo počítačových inžinierskych podnikov. Všetky sú multifunkčné, pohodlné a ľahko použiteľné, s intuitívnym rozhraním. Jedinou celkovou nevýhodou všetkých programov je, že sú všetky platené.

2.2 Popis diagramov podnikateľského procesu "Účtovníctvo počítačových inžinierskych podnikov"

2.2.1 Popis IDEF0 graf

Na vytvorenie obchodného procesu sa použil diagram IDEF0. Metodika IDEF0 predpisuje stavbu hierarchického diagramu systému - jednotné opisy systémových fragmentov. Najprv sa vykonáva popis systému ako celku a jeho interakcia s okolitým svetom (kontextový diagram). Boli postavené tri úrovne diagramu:

Kontextový

Funkčný rozklad

Rozklad každej práce

Obrázok 1 - Kontextový diagram "Účtovníctvo počítačových inžinierskych podnikov"

Obrázok 1 zobrazuje kontextový diagram obchodného procesu "Účtovníctvo pre emisné inžinierske podniky". Zobrazuje systém ako celok a jeho interakciu s hlavnými externými prúdmi prúdenia.

Kontextový diagram je označený šípkami.

Typy šípok:

Vstupné informácie na spracovanie:

Počítače - PCS (osobné počítače) sú v podniku

Príslušenstvo - materiály potrebné na aktualizáciu počítačov (grafické karty, základné dosky, spracovatelia, puzdrá, napájacie zdroje, pamäťové moduly)

Výstupné toky:

Správa - Ready Správa o počítačovom inžinierstve

Ovládacie prvky:

Pravidlá sú podmienky, ktoré treba dodržiavať na dosiahnutie cieľa.

Objednávky - Úloha podniku (vykonávanie účtovníctva počítačových zariadení v podniku s pomocou určitých informačných systémov)

Manažéri - riaditelia a hlavní manažéri podnikov.

Vstupné zdroje:

PCS - Počítače, s ktorými sa vykonáva účtovníctvo.

Zamestnanci sú špecialisti, ktorí vykonávajú pokyny priradené k sprievodcovi. Po vytvorení koncepčného modelu sa uskutočnil funkčný rozklad - systém je rozdelený na subsystémy a každý subsystém je popísaný samostatne (rozkladové tabuľky).

Obrázok 2 ukazuje funkčný rozklad pozostávajúci zo štyroch diel.

Obrázok 2 - Funkčný rozklad "Účtovanie počítačových inžinierskych podnikov"

Prideľovali sa tieto druhy práce:

Registrácia doručenia je proces, v ktorom je výrobok pridelený, posielanie skladovania, skladu a posilnenie informácií o produkte v programe.

V práci, dodávka dodávky zahŕňa sedem hraničných strelcov (vstup, kontrola, mechanizmus) a vnútorná šípka (vstupná komunikácia).

Arrow Komunikácia pri vstupe medzi prácou. Dodávka a údržba počítača (počítač);

Vstup so šípkami, výstup, kontrola sa opakujú v nasledujúcich prácach.

Počítačová služba je proces, v ktorom sa vyskytne montáž, opravy a aktualizácie počítačov.

Údržba počítača počítača obsahuje štyri hranice šípok (vstup, riadenie, mechanizmus, výstup) a niekoľko vnútorných šípok (vstupná komunikácia, spätná väzba pre vstup).

Arrow Management - pravidlá, objednávky, hlava;

Arrow Komunikácia vo vstupu medzi dielami počítača a usporiadaním (dátový kryt do databázy), medzi dielami počítača a vykazovaním správy (dáta uzatvorené databázy);

Usporiadanie je proces, v ktorom existuje zosúladenie počítačov na kanceláriách (skrine).

Riadenie šípok - pravidlá, objednávky, hlava;

Šípka mechanizmu - zamestnanci;

Arrow Komunikácia vo vstupu medzi usporiadaním a kompiláciou správy (ID);

Vyhlásenie o vypracovaní - posledná etapa účtovného procesu, ktorá sa skladá z zovšeobecnenia konečných ukazovateľov získaných vykonaním predchádzajúcich bežných účtovných údajov.

Každý subsystém je rozdelený na menšie rozklady a tak ďalej, pred dosiahnutím požadovaného stupňa.

Obrázok 3 zobrazuje diagram, ktorý ukazuje činnosť dodávky dodávok podrobnejšie.

V dôsledku detailu boli pridelené hlavné funkcie. Sekcia "Doručenie" obsahuje sedem hlavných šípok (vstup, výstup, kontrola, mechanizmus).

Vstupná šípka - Počítače a komponenty;

Šípky správy sú pravidlá, objednávky a manažér. Booming šípky;

Šípky mechanizmu, vetvenia - PC, zamestnancov;

Vo všetkých operáciách sa opakujú vstup, kontrola, mechanizmy.

Čísla - Priradenie jednotlivých miestností s počítačmi a komponentmi.

Vstupné šípky - Počítače a komponenty. Arrow Počítače sa opakujú v následnej práci, okrem hlásenia;

Riadenie šípok - pravidlá, objednávky a hlavu;

Šípky mechanizmu - PC a zamestnancov;

Arrow Komunikácia pri vstupe medzi zaradením prác v miestnosti a odosielanie tovaru do skladu (premiestnenie), medzi "priradením miestnosti" a "zostatok" (Úvod do databázy);

Odosielanie tovaru do skladu - tŕň tovaru s pridelenou miestnosťou do skladu.

Ukončiť šípku - počítač;

Riadenie šípok - pravidlá, objednávky a hlavu.

Arrow Komunikácia pri vchode medzi prácou "Posielanie tovaru do skladu" a "Zostatok" (číslo);

Inscenácia o zostatku - Posilnenie informácií do počítača.

Riadenie šípok - pravidlá, objednávky a hlavu;

Šípky mechanizmu - PC a zamestnancov;

Obrázok 4 zobrazuje diagram, podrobnejšie informácie o podrobnostiach.

V dôsledku detailu boli pridelené hlavné funkcie v procese údržby počítača.

Údržba počítača obsahuje 4 hraničné šípky (vstup, výstup, kontrola, mechanizmus). Vnútorné šípky (vstupná spätná väzba, vstupná komunikácia).

Montážne počítače - konfigurácia počítačov pre jednotlivé objednávky vodcov.

Vstupná šípka - Počítače;

Riadenie šípok - pravidlá, objednávky a hlavu;

Šípky mechanizmu - zamestnanci;

Arrow Komunikácia pri vchode medzi prácou: "Montážnymi počítačmi" a "Oprava počítačov" (Počítač);

Oprava počítača je montáž schválená na zlepšenie počítačov.

Vstupná šípka - Počítače;

Arrow Output je databáza;

Riadenie šípok - pravidlá, objednávky a hlavu;

Šípky mechanizmu - zamestnanci;

Šípky vstup, výstup, kontrola, mechanizmus sú vetvenie;

Arrow Komunikácia pri vchode medzi prácou: "Oprava počítačov" a "Upgrade" (komponenty);

Upgrade - Zlepšenie, zlepšenie, aktualizácia počítača.

Arrow Output je databáza;

Riadenie šípok - pravidlá, objednávky a hlavu;

Šípky mechanizmu - zamestnanci;

Arrow Control, mechanizmus sú rozvetvené;

Obrázok 5 zobrazuje diagram "Hlásenie" podrobnejšie. V rozkladu práce zostavovanie správy obsahuje 4 hraničné šípky (vstup, výstup, kontrola, mechanizmy). Vnútorné šípky (vstupná spätná väzba, vstupná komunikácia).

V dôsledku práce boli odvodené nasledujúce funkcie:

Zber údajov - Zber informácií na analýzu a rozhodovanie.

Vstupná šípka - ID priradenia;

Riadenie šípok - pravidlá, objednávky a hlavu;

Šípky vstup, kontrola, mechanizmus sú vetvenie;

Arrow Komunikácia pri vchode medzi prácami: Zber údajov a overenie údajov (záznamy);

Kontrola údajov - Kontrola informácií a odoslanie na správu.

Vstupná šípka - ID priradenie, zvýšenie údajov v databáze;

Produktová šípka - správa;

Riadenie šípok - pravidlá, objednávky a hlavu;

Šípky mechanizmu - Zamestnanci, PC;

Vstupné šípky (ID), kontrola, mechanizmus sú vetvenie;

Spätná väzba so šípkou vo vstupoch z "Kontrola údajov" na "Zber dát" (opätovné kontrolu).

Naučte sa vidieť a pochopiť funkčná štruktúra Tvoja vec!

V súčasnej dobe, v Rusku, záujem o štandardy riadenia všeobecne prijatých na Západe prudko zvýšil, avšak v reálnych postupoch riadenia existuje jeden veľmi demonštračný bod. Mnohí lídri môžu byť stále v poriadku organizačná štruktúra Alebo o schéme existujúcich obchodných procesov. Najpokročilejšie a pravidelne čítanie ekonomických periodíkových manažérov, spravidla, začnú kresliť iba jednu hierarchické grafy, ktoré sú zrozumiteľné len tým, ale v tomto procese zvyčajne rýchlo vstupujú do zablokovania. To isté platí pre zamestnancov a manažérov rôznych služieb a funkčných jednotiek. Vo väčšine prípadov je jediný súbor pravidiel stanovených, v súlade s ktorým by mal podnik fungovať, je súborom individuálnych ustanovení a oficiálne pokyny. Najčastejšie boli tieto dokumenty zostavené ani pred rokom, slabo štruktúrované a nedokončené medzi sebou a ako výsledok, jednoducho prach na regáloch. Takýto prístup bol takýto prístup odôvodnený, pretože počas tvorby ruského trhového hospodárstva bol pojem hospodárskej súťaže prakticky neprítomný a náklady neboli považované za osobitnú potrebu - zisk bol gigantický. V dôsledku toho vidíme v posledných dvoch rokoch úplne vysvetlený obrázok: veľké spoločnostiUzemnenie na začiatku 90. rokov, postupne sa vzdať svojej pozície, až po úplnú starostlivosť z trhu. Je to čiastočne kvôli tomu, že podnik nezaviedol normy riadenia, koncepcia funkčného modelu aktivity a misie bolo úplne neprítomné. S pomocou modelovania rôznych oblastí činnosti je možné účinne analyzovať "úzke miesta" pri riadení a optimalizácii všeobecného obchodného systému. Ale, ako viete, v žiadnom podniku, najvyššia priorita má len tie projekty, ktoré priamo prinášajú zisky, takže hovoríme o prieskume aktivít a jeho reorganizácii len počas hmatateľnej krízy pri riadení spoločnosti.

Na konci 90. rokov, keď sa podľa potreby objavili hospodárska súťaž a ziskovosť podnikov a ziskovosť podnikov sa lídri cítili obrovské ťažkosti pri pokuse o optimalizáciu nákladov tak, aby výrobky zostali súčasne a ziskové a konkurencieschopné. Práve v tomto bode je potrebné mať model činnosti podniku pred vlastnými očami, ktoré by odrážali všetky mechanizmy a zásady vzťahu rôznych subsystémov v rámci jedného podniku.

Samotná koncepcia "modelovacích podnikových procesov" prišla na životnosť väčšiny analytikov súčasne s vzhľadom na trh komplexných softvérových produktov určených na integrovanú automatizáciu podnikového manažmentu. Takéto systémy vždy znamenajú hlboký predprojektový prieskum aktivít spoločnosti. Výsledkom tohto preskúmania je znalecký posudok, v ktorom sú niektoré body vykonané odporúčaniami na odstránenie "úzkych miest" pri riadení činností. Na základe tohto záveru, bezprostredne pred realizáciou projektu systému automatizácie, sa vykonáva takzvaná reorganizácia obchodných procesov, niekedy dosť vážne a bolestivé pre spoločnosť. Toto, a samozrejme, tím vyvinutý už roky je vždy ťažké vynútiť "premýšľať novým spôsobom." Takéto komplexné prieskumy podnikov sú vždy zložité a výrazne odlišné od prípadu úloh. Na riešenie takýchto problémov modelovania komplexných systémov existujú dobre valcované metodiky a normy. Takéto normy zahŕňajú metodiky rodiny IDEF. S pomocou ich pomoci je možné účinne zobraziť a analyzovať modely aktivity širokej škály komplexných systémov v rôznych rezoch. Zároveň je rozvoja a hĺbka prieskumu procesov v systéme určená samotným vývojárom, ktorý umožňuje preťaženie vytvoreného modelu nadmernými údajmi. Momentálne možno pripísať IDEF Nasledujúce normy:

IDEF0 - Metodika funkčného modelovania. Pomocou vizuálnej grafickej IDEF0 sa študoval systém pred vývojármi a analytikmi vo forme množiny vzájomne prepojených funkcií (funkčné bloky - v termínoch IDEF0). Modelovacie nástroje IDEF0 je spravidla prvým krokom v štúdii akéhokoľvek systému;

IDEF1 - Metodika pre modelovanie informácií prúdi vo vnútri systému, čo umožňuje zobraziť a analyzovať ich štruktúru a prepojenie;

IDEF1x (rozšírená IDEF1) - Metodika výstavby relačných štruktúr. IDEF1x sa vzťahuje na typ metodiky "vzťahy entity" (vzťah - vzťah) a spravidla sa používa na simuláciu relačných databáz súvisiacich s posudzovaným systémom;

IDEF2 je metodika dynamického modelovania vývoja systému. Kvôli veľmi vážnym ťažkostiam analýzy dynamických systémov to bolo takmer opustené z tohto štandardu a jeho rozvoj pozastavil na veľmi počiatočné štádium. V súčasnosti však existujú algoritmy a ich počítačové implementácie, čo umožňuje transformovať sadu statických diagramov IDEF0 na dynamické modely postavené na základe "Petri maľované siete" (CPN - Color Petri Siete);

IDEF3 je metodika dokumentov, ktoré sa vyskytujú v systéme, ktorý sa používa, napríklad v štúdii technologických procesov v podnikoch. Použitie IDEF3 opisuje skript a postupnosť operácií pre každý proces. IDEF3 má priamy vzťah s metodikou IDEF0 - každá funkcia (funkčný blok) môže byť reprezentovaný ako samostatný proces IDEF3;

IDEF4 - Metodika pre stavebné objektovo orientované systémy. Prostriedky IDEF4 môžu jasne zobrazovať štruktúru objektov a princípy ich interakcie, čím sa umožní analyzovať a optimalizovať komplexné objektovo orientované systémy;

IDEF5 - Metodika komplexných systémov ontologických výskumov. Použitím metodiky IDEF5 môže byť systémová ontológia opísať s použitím určitého slovníka podmienok a pravidiel, na základe ktorých možno v určitom okamihu vytvorené spoľahlivé obvinenia zo štátu posudzovaného systému. Na základe týchto vyhlásení sa vytvárajú závery o ďalšom rozvoji systému a je optimalizovaný.
V rámci tohto článku považujeme najčastejšie používanú metodiku pre funkčné modelovanie IDEF0.

História štandardu IDEF0

Metodika IDEF0 možno považovať za vývojovú fázu známeho grafického jazyka popisu funkčných systémov SADT (štruktúrovaná analýza a dizajn teqnique). Pred niekoľkými rokmi bola podobná kniha vydaná v malom obehu, venovaná popisu základných princípov budovania SADT diagramov. Historicky, IDEF0, ako štandard bol vyvinutý v roku 1981 ako súčasť rozsiahleho automatizačného programu priemyselné podnikyKtorá ICAM nosila označenie (integrovaná počítačová výrobná výroba) a navrhla oddelenie Vzdušné sily USA. Vlastne, rodina IDEF štandardov zdedená svoje označenie z mena tohto programu (IDEF \u003d ICAM definícia). V procese praktická implementáciaÚčastníci programu ICAM čelia potrebe vyvinúť nové metódy analýzy procesov interakcie v priemyselných systémoch. Súčasne, okrem zlepšeného súboru funkcií na opis podnikových procesov, jedným z požiadaviek na novú normu bola existencia účinnej metodiky interakcie v rámci "analytik-špecialista". Inými slovami, nová metóda Mal by poskytovať skupinovú prácu na vytvorenie modelu, pričom priama účasť všetkých analytikov a špecialistov zapojených do projektu.

V dôsledku vyhľadávania príslušných riešení sa narodila metodika funkčného modelovania IDEF0. Od roku 1981, štandard IDEF0 prešla niekoľkými menšími zmenami, najmä obmedzujúcimi a jeho poslednou redakčnou radou bol vydaný v decembri 1993 Národným inštitútom pre štandardné a americké technológie (NIST).

Hlavné prvky a ideály IDEF0

Grafický jazyk IDEF0 je prekvapivo jednoduchý a harmonický. Metodika je založená na štyroch základných pojmoch.

Prvým z nich je koncepcia funkčného bloku (aktivita). Funkčný blok je graficky zobrazený ako obdĺžnik (pozri obr. 1) a personifikuje určitú špecifickú funkciu v rámci posudzovaného systému. Podľa požiadaviek štandardu by mal byť názov každého funkčného bloku formulovaný vo verbrázii (napríklad "na výrobu služieb", a nie "výrobné služby").

Každá zo štyroch strán funkčného bloku má svoju vlastnú určitú hodnotu (úlohu), zatiaľ čo:

Horná strana má hodnotu "Control";

Ľavá strana je "vstup" (vstup);

Pravá strana je "výstup" (výstup);

Spodná strana má hodnotu "mechanizmus".

Každý funkčný blok v rámci zjednoteného systému by mal mať svoje vlastné jedinečné identifikačné číslo.

Obrázok 1. Funkčný blok.

Druhá metodika "Whale" IDEF0 je koncepcia rozhrania ARC (šípka). Tiež rozhrania oblúky sa často nazývajú prúdy alebo šípky. Rozhranie ARC zobrazuje prvok systému, ktorý je spracovaný funkčným blokom alebo má iný účinok na funkciu zobrazenú týmto funkčným blokom.

Grafické zobrazenie rozhrania ARC je jednosmerná šípka. Každé rozhranie ARC musí mať svoj jedinečný názov (štítok so šípkou). Na žiadosť štandardu musí byť názov normalizáciou podstatného mena.

Používanie rozhrania oblúkov, rôzne objekty displej, do jedného stupňa alebo iného, \u200b\u200bvymedzujúce procesy vyskytujúce sa v systéme. Takéto objekty môžu byť prvkami reálneho sveta (časti, vozne, zamestnancov, atď.) Alebo dátové toky a informácie (dokumenty, údaje, inštrukcie atď.).

V závislosti na tom, ktoré strany vyhovujú tomuto rozhraniu oblúk, sa nazýva "prichádzajúce", \u200b\u200b"odchádzajúci" alebo "kontrola". Okrem toho, "zdroj" (začiatok) a "prijímač" (koniec) každého funkčného oblúka môžu byť iba funkčné bloky a iba výstupná strana bloku môže byť "zdrojom" a ktorýkoľvek z troch zostávajúcich "prijímačov .

Treba poznamenať, že akýkoľvek funkčný blok podľa požiadaviek štandardu by mal mať aspoň jedno kontrolné rozhranie ARC a jeden odchádzajúci. Toto je zrozumiteľné - každý proces by sa mal vyskytnúť podľa niektorých pravidiel (zobrazený kontrolný oblúk) a mal by vytvoriť určitý výsledok (vznikajúci oblúk), inak jeho zmysle nemá zmysel.

Pri budovaní IDEF0 - diagramy je dôležité správne oddeliť oblúky prichádzajúceho rozhrania od manažérov, čo nie je ľahké. Na obrázku 2 je napríklad funkčný blok "spracovanie obrobku".

V skutočnom procese, pracovný, výroba spracovania, sa vydáva na obrobku a technologické pokyny na spracovanie (alebo bezpečnostné predpisy pri práci so strojom). Môže sa zdať chybne, že obrobok a dokument s technologickými smermi sú prichádzajúce objekty, ale nie. V tomto procese je obrobok spracovaný podľa pravidiel, ktoré sa odrážajú v technologických pokynoch, ktoré musia byť zodpovedajúcim spôsobom reprezentovať na kontrolné rozhranie ARC.

Obrázok 2.

Ďalšia vec je, keď je technologické pokyny spracované hlavným technológom a zmeny sa vykonávajú v nich (obr. 3). V tomto prípade sa už zobrazujú v ARC prichádzajúceho rozhrania a kontrolný objekt je napríklad nové priemyselné normy, na základe ktorých sa vykonajú zmeny.

Obrázok 3.

Vyššie uvedené príklady zdôrazňujú externe podobnú povahu prichádzajúcich a kontrolných rozhraní oblúkov, avšak pre systémy tej istej triedy sú vždy určité rozdiely. Napríklad v prípade posudzovania podnikov a organizácií je tu päť hlavných typov zariadení: materiálne toky (časti, tovar, suroviny atď.), Finančné toky (hotovosť a nepeňažné, investície atď.), tok dokumentov (obchodné, finančné a organizačné dokumenty), informačné toky (informácie, informácie o zámere, orálnych zákazkách atď ,) a zdroje (zamestnanci, stroje, stroje atď.). Súčasne, v rôznych prípadoch, prichádzajúce a odchádzajúce rozhrania oblúky môžu zobraziť všetky typy objektov, ktoré sú manažérmi týkajúcimi sa len tokov a informácií a mechanizmov s oblúkovými zdrojmi.

Povinná dostupnosť kontrolných rozhraní oblúkov je jedným z hlavných rozdielov v norme IDEF0 z iných DFD (DAGRAM) a WFD (Diagram pracovného prietoku).

Tretia základná koncepcia IDEF0 je rozklad (rozklad). Princíp rozkladu sa používa pri rozdeľovaní komplexného procesu na zložky jeho funkcie. Zároveň je úroveň detailov procesov určená priamo modelom vývojár.

Rozklad vám umožňuje postupne a štruktúrovaný, aby reprezentoval systémový model vo forme hierarchickej štruktúry jednotlivých diagramov, čo je menej preťažené a ľahko absorbované.

Model IDEF0 vždy začína reprezentovačom systému ako jedno celé číslo - jeden funkčný blok s rozhraním oblúk, ktoré sa rozprestierajú mimo posudzovaného regiónu. Tento diagram s jedným funkčným blokom sa nazýva kontextový diagram a je indikovaný identifikátorom "A-0".

Vo vysvetľovanom texte na kontextový diagram by mal byť cieľ (účel) konštrukcií diagramu špecifikovaný vo forme stručný popis A stanovisko je stanovené.

Definícia a formalizácia účelu rozvíjania IDEF0 - model je mimoriadne dôležitým bodom. Cieľ v skutočnosti určuje zodpovedajúce oblasti v rámci štúdia, na ktorom je potrebné zamerať sa predovšetkým. Napríklad, ak simuláciu aktivít podniku s cieľom ďalej budovať na základe tohto modelu informačného systému, potom sa tento model výrazne líši od toho, ktorý by sme boli vyvinuté pre ten istý podnik, ale v poriadku optimalizovať logistické reťazce.

Z hľadiska určuje hlavné smerovanie vývoja modelu a úrovne potrebných detailov. Jasná fixácia hľadiska vám umožňuje vyložiť model, odmietnuť podrobnosti a štúdium jednotlivých prvkov, ktoré nie sú potrebné, na základe zvoleného hľadiska v systéme. Napríklad funkčné modely toho istého podniku z hľadiska hlavného technológa a finančného riaditeľa sa výrazne líšia v smere ich detailov. Je to spôsobené skutočnosťou, že nakoniec finančný riaditeľ nezaujíma aspekty spracovania surovín na výrobných strojoch a hlavný technológ nemá nič spoločné so systémami finančných tokov. Správna voľba Z hľadiska výrazne znižuje časové náklady na budovanie konečného modelu.

V procese rozkladu, funkčný blok, ktorý v kontextovom diagrame zobrazuje systém ako celok, je podrobne podrobne vystavený podrobnostiam na inom diagrame. Výsledný diagram druhej úrovne obsahuje funkčné bloky, ktoré zobrazujú hlavné subdravy funkčného bloku kontextového diagramu a nazývajú sa dcérskou spoločnosťou (detský diagram) s ohľadom na neho (každý z funkčných blokov patriacich do detského diagramu sa nazýva dieťa Box). Na druhej strane, funkčný blok sa nazýva materský blok vo vzťahu k dcérskej spoločnosti (materský box) a diagram, ktorým patrí, je materský diagram (materský diagram). Každá z podhodnotenia dcérskeho diagramu môže byť ďalej podrobne podrobná podobným rozkladom zodpovedajúceho funkčného bloku. Je dôležité poznamenať, že v každom prípade rozkladu funkčného bloku, všetky oblúky rozhrania zahrnuté v tejto jednotke sú zaznamenané alebo prichádzajúce z neho na dcérsku spoločnosť. Tým sa dosahuje štrukturálna integrita IDEF0 - modelu. Princíp rozkladu je jasne znázornený na obrázku 4. Pozornosť by sa mala venovať vzťahu číslovania funkčných blokov a diagramov - každá jednotka má svoje vlastné jedinečné sériové číslo na diagrame (číslica v pravom dolnom rohu obdĺžnika), A označenie pod pravouhlým uhlom označuje počet dcérskej spoločnosti pre tento blokový diagram. Absencia tohto označenia naznačuje, že rozklad pre tento blok neexistuje.

Často existujú prípady, keď individuálne rozhrania oblúky nemajú zmysel pokračovať v zvážení v detských diagramoch pod určitú určitú úroveň v hierarchii, alebo naopak - oddelené oblúky nemajú praktický význam nad určitú úroveň. Napríklad rozhrania oblúk zobrazujúce "časť" pri vstupe do funkčného bloku "Spracovanie na sústruhu" nemá zmysel premýšľať o vyšších úrovniach - bude len preťažiť diagramy a aby ich zložité na vnímanie. Na druhej strane sa to stane, že sa zbaviť individuálnych "koncepčných" rozhraní rozhrania a nie je detail hlbšie ako určitá úroveň. Na vyriešenie takýchto úloh v norme IDEF0 sa poskytuje koncepcia tunelovania. Označenie "tunel" (Arrow Tunnel) vo forme dvoch okrúhlych konzol okolo začiatku rozhrania ARC indikuje, že tento oblúk nebol zdedený z funkčného rodičovského bloku a objavil sa (z "tunela") len na tomto diagrame. Na druhej strane, rovnaké označenie okolo konca (šípky) rozhrania ARC v bezprostrednej blízkosti jednotky - prijímač znamená, že v dcérskej spoločnosti vo vzťahu k tomuto bloku diagramu sa tento oblúk nezobrazí a uvažuje . Najčastejšie sa deje, že individuálne objekty a zodpovedajúce oblúky rozhrania nie sú považované za niektoré medziprodukty hierarchie - v takom prípade sa najprv ponoria do tunela "a potom, ak je to potrebné," návrat z tunela ".

Posledné koncepty IDEF0 je glosár (slovník). Pre každý z prvkov IDEF0: diagramy, funkčné bloky, rozhrania ARCS existujúci štandard zahŕňa vytváranie a udržiavanie množiny vhodných definícií, kľúčových slov, naratívnych prezentácií atď., Ktoré charakterizujú objekt zobrazený týmto prvkom. Táto sada sa nazýva glosár a je popisom podstaty tejto položky. Napríklad pre Riadiace rozhranie ARC "Regulácia platby" Slovník môže obsahovať zoznam polí príslušného dokumentu ARC, potrebný súbor víz atď. Slovník je harmonicky dopĺňať vizuálny grafický jazyk, dodávateľské diagramy s potrebnými dodatočnými informáciami.

Obrázok 4. Rozklad funkčných blokov.

Princípy obmedzenia zložitosti IDEF0-diagramov

Zvyčajne, IDEF0-model nesú komplexné a koncentrované informácie sama osebe a aby sa obmedzili ich preťaženie a čitateľné, príslušné obmedzenia ťažkostí sa prijímajú v príslušnej norme: \\ t

Obmedzenie počtu funkčných blokov v trojnásobnom grafe. Horná hranica (šesť) spôsobí, že vývojár používal hierarchie pri opise komplexných položiek a dolná hranica (tri) zabezpečuje, že existuje dostatok podrobností o príslušnom diagrame na odôvodnenie jeho vytvorenia;

Obmedzenie počtu vhodných na jeden funkčný blok (objavovanie z jedného funkčného bloku) rozhrania oblúk.
Samozrejme, prísne dodržiavať tieto obmedzenia vôbec voliteľne, ale ako skúsenosti ukazujú, sú veľmi praktické v reálnej práci.

Disciplína skupiny práce na vývoji modelu IDEF0

Štandard IDEF0 obsahuje súbor postupov, ktoré vám umožní rozvíjať a koordinovať model veľkej skupiny ľudí patriacich do rôznych oblastí systému simulovaného systému. Typicky je vývojový proces iteratívny a pozostáva z nasledujúcich podmienených stupňov:

Vytvorenie modelu skupiny špecialistov patriacich do rôznych oblastí činnosti podniku. Táto skupina v termínoch IDEF0 sa nazýva autori (autori). Výstavba počiatočného modelu je dynamickým procesom, počas ktorého autori rozhovor príslušné k štruktúre rôznych procesov. Na základe dostupných ustanovení, dokumentov a prieskumov je vytvorený návrh (modelový návrh) modelu.

Distribúcia návrhu na posúdenie, koordináciu a pripomienky. V tejto fáze existuje diskusia o návrhu modelu so širokou škálou kompetentných osôb (v zmysle čitateľov IDEF0) v podniku. Zároveň je každý z diagramov návrhu modelu kritizovaný a komentovaný písomne \u200b\u200ba komentovaný, a potom odovzdaný autorovi. Autor, zase, tiež písomne \u200b\u200bsúhlasí s kritikou alebo ho odmieta s prezentáciou logiky rozhodnutia a opäť vráti opravený návrh na ďalšie posudzovanie. Tento cyklus pokračuje, kým autori aj čitatelia prídu k spoločnému stanovisku.

Oficiálne schválenie modelu. Schválenie dohodnutého modelu prebieha vedúci pracovnej skupiny, ak autori modelu a čitateľov nemajú nezhody o svojej primeranosti. Konečným modelom je koordinovanou myšlienkou podniku (systému) z daného hľadiska a na daný účel.
Zrozumiteľnosť grafického jazyka IDEF0 robí model celkom čitateľný pre jednotlivcov, ktorí sa nezúčastnili na projekte svojho vytvárania, ako aj účinné na zobrazenie a prezentáciu. V budúcnosti sa na základe konštruovaného modelu môžu organizovať nové projekty zamerané na výrobu zmien v podniku (v systéme).

Vlastnosti národnej praxe aplikácie funkčného modelovania IDEF0

V posledných rokoch rastie záujem o Rusko v metodikách rodiny IDEF. Neustále sledujem, pri pohľade na štatistiku odvolaní na vašu osobnú webovú stránku (http://www.vernikov.ru), ktorý stručne opisuje základné princípy týchto noriem. Záujem o takéto štandardy ako IDEF3-5 by som bol teoretický a IDEF0 je celkom prakticky odôvodnený. V skutočnosti, prvé prípady, ktoré umožňujú vybudovať DFD a IDEF0 diagramy sa objavili na ruskom trhu v roku 1996, súčasne s vydaním populárnej knihy o princípoch modelovania v SADT štandardoch.

Väčšina manažérov však stále považuje praktické uplatnenie modelovania v IDEF štandardoch skôr ako pocta móde ako efektívny spôsob, ako optimalizovať existujúci systém riadenia podnikov. S najväčšou pravdepodobnosťou je to vďaka výraznému znevýhodeniu informácií o praktické uplatnenie Tieto metodiky a nepostrádateľným softvérovým zaujatím absolútnej väčšiny publikácií.

Nie je žiadnym tajomstvom, že takmer všetky projekty prieskumov a analýza finančných a ekonomických aktivít podnikov sú v Rusku, spojené s výstavbou automatizované systémy Kontrolu. Vzhľadom k tomu, IDEF štandardy v chápaní väčšiny stali podmienečne neoddeliteľnou od zavedenia informačných technológií, hoci s ich pomocou, niekedy môžete efektívne vyriešiť dokonca aj malé miestne úlohy, doslova s \u200b\u200bceruzkou a papierom.

Pri vykonávaní komplexných projektov pre podnikové prieskumy, vývoj modelov v norme IDEF0 vám umožňuje jasne a efektívne zobraziť celý mechanizmus aktivity podniku v požadovanej časti. Najdôležitejšou vecou je však možnosť kolektívnej práce, ktorú poskytuje IDEF0. V mojej praktickej aktivite bolo dosť veľa prípadov, keď bola výstavba modelu vykonaná s priamou pomocou zamestnancov rôznych jednotiek. Zároveň ich konzultant na pomerne krátky čas vysvetlil základné princípy IDEF0 a učili sa s vhodným aplikačným softvérom. V dôsledku toho zamestnanci rôznych oddelení vytvorili IDEF diagram činností ich funkčnej divízie, ktoré by mali odpovedať na nasledujúce otázky:

Čo vstupuje do divízie "pri vstupe"?

Aké funkcie a v akej sekvencii sa vykonávajú v divízii?

Kto je zodpovedný za vykonávanie každej funkcie?

Čo sa riadi dodávateľom pri vykonávaní každej funkcie?

Aký je výsledok práce jednotky (na produkte)?

Po koordinácii návrhu diagramov vo vnútri jednotky, zhromažďujú sa konzultantom v návrhu modelu podniku, v ktorom sú spojené všetky vstupné a výstupné prvky. V tomto štádiu sa zaznamenávajú všetky nezrovnalosti jednotlivých diagramov a ich kontroverzné miesta. Ďalej tento model opäť prechádza prostredníctvom funkčných oddelení na ďalšiu koordináciu a vykonanie potrebných úprav. V dôsledku toho, pre pomerne krátky čas a pri prilákaní minimálneho ľudských zdrojov z poradenskej spoločnosti (a tieto zdroje, ako viete, veľmi drahé), ukazuje model IDEF0-model podniku podľa princípu "ako je "a čo je dôležité, predstavuje podnik s pozíciami zamestnancov, ktorí v ňom pracujú a dôkladne poznajú všetky nuansy vrátane neformálneho. V budúcnosti bude tento model prevedený na analýzu a spracovanie pre obchodných analytikov, ktoré budú vyhľadávať "úzke miesta" v riadení spoločnosti a optimalizáciu hlavných procesov, transformuje model "ako je" na zodpovedajúce zastúpenie " ako by to malo byť ". Na základe týchto zmien a konečného uzavretia, ktorý obsahuje odporúčania týkajúce sa reorganizácie systému riadenia.

Samozrejme, takýto prístup si vyžaduje množstvo organizačných opatrení, predovšetkým vedením skúmaného podniku. Je to spôsobené tým, že táto technika vyplýva uloženie niektorých ďalších zodpovedností za rozvoj a praktické uplatňovanie nových metodík. Avšak, to v konečnom dôsledku odôvodňuje, pretože ďalších jeden alebo dve hodiny práce jednotlivých zamestnancov v priebehu niekoľkých dní umožňuje výrazne ušetriť finančné prostriedky na zaplatenie poradenských služieb spoločnosti tretej strany (ktorá v každom prípade odtrhne prácu rovnakých zamestnancov s dotazníkmi a otázkami). Pokiaľ ide o zamestnancov podniku, tak či onak, vyhlásená opozícia na ich časti som sa nestretol v mojej praxi.

Záver z toho všetkého možno vykonať: Absolútne nie nevyhnutne zakaždým, keď si vymyslieť riešenia pre štandardné úlohy. Vždy, keď narazíte na potrebu analyzovať jeden alebo iný funkčný systém (Zo systému navrhovania kozmickej lode, do procesu varenia komplexnej večere) - používajte osvedčené a príležitostné metódy roky. Jednou z týchto metód je IDEF0, ktorá vám umožní riešiť komplexné životné úlohy pomocou vášho jednoduchého a zrozumiteľného Toolkit.

Jeden obrázok stojí tisíce slov

Ľudová múdrosť

V mojej práci je často potrebné preskúmať a vyriešiť určitý problém, ale identifikovať svoju polohu vo všeobecnom modeli práce spoločnosti. Nestačí pochopiť, že určitá divízia funguje nesprá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 vybrať si optimálna metóda Riešenia úlohy. A na to musíte preskúmať prácu spoločnosti a urobiť z neho funkčný model.

Samozrejme, teoreticky by mal byť funkčný model práce spoločnosti v hlave, a nezáleží na tom, je to o organizovaní práce skladu alebo IT systému z Lida pred aplikáciou. Ale v skutočnosti to takmer nikdy nezmení, a preto v procese štúdia a nájsť riešenie úlohy s klientom, vytvorím tiež funkčný model práce spoločnosti alebo určitý proces (funkcia) samostatne .

Niekoľko slov o výhodách grafiky

Ako viete, funkčné modely IDEF0 sú vždy grafické schémy. Majú svoje vlastné funkcie a pravidlá pre kompiláciu. Budeme o tom o tom trochu rozprávame. A teraz by som chcel dať niekoľko príkladov grafickej účinnosti. Prečo sa na to učiním? S najväčšou pravdepodobnosťou, po mojom vyhlásení o potrebe funkčného modelu práce spoločnosti, mnohí ľudia si mysleli, že to bolo všetko voliteľne, môžete tiež vysvetliť, ako to alebo táto funkcia v spoločnosti funguje. To je to, čo chcem hovoriť o tom.

A pre začiatočníkov urobíme malú exkurziu v histórii. Poďme sa vrátiť do vzdialenosti 1877, počas ruskej tureckej vojny. To bolo potom, že polygrafista Sotan prvýkrát aplikoval plán pri opise nepriateľských akcií. Teraz je to všetko pre nás, pri opise akejkoľvek bitky, každý má šípky, ktoré jasne ukazujú priebeh bitky. A v tých dňoch boli vojenské akcie opísané slovami. Pre každý boj - mnoho, mnoho slov. A na konci pochopiť, čo sa stane, bolo to veľmi ťažké.

A pretože myšlienka spoločnosti SETIN bola skutočne revolučná - začal tlačiť litografické kópie kariet s označením opevnenia a umiestnenia vojenských jednotiek. Nazývané tieto karty "pre čitateľov novín. Prospech. " Táto myšlienka sa ukázala byť tak dôležitá, že prvé vydanie "výhod" bolo okamžite rozšírené. A potom takéto aplikácie boli veľmi v dopyte. Dôvod je zrejmý. Harmonogram pomohol pochopiť, čo bolo prakticky nemožné rozobrať niektoré slová.

Podobný príklad bezmocnosti verbálnych popisov môžem tiež viesť z mojej praxe. Jeden z mojich zákazníkov naozaj požiadal, aby prevzal implementáciu ERP systému pre svoju spoločnosť. Na otázku, že majú nejakú technickú úlohu, dostal som odpoveď: "Áno, je. Ale v ňom 400 strán. " Zároveň bol klient veľmi sťažovaný, že moji kolegovia, ktorému sa predložili skôr, alebo zamietol projekt vôbec, alebo nazývali jasne nadhodnotené ceny. Potom, čo som videl, že v technickej úlohe existujú naozaj 400 strán, a skladá sa výlučne z popisu textu, pochopil som príčinu správania vývojárov. Ak chcete čítať tento objem textu, vložiť do nej, pochopiť všetky nuansy len s cieľom pochopiť úlohu a zavolať cenu - to je pravda veľmi ťažké.

Navrhol som, aby tento klient alternatívna možnosť - Popíšte všetko, čo môžete, graficky vo forme notácií. Ukázali mu príklady modelovania. V dôsledku toho teraz prehodnotia svoje želania a návrh technickej úlohy.

Tiež viem mnoho ďalších príkladov, keď grafické modelovanie obchodných procesov pomohlo v práci mojich kolegov, obchodných konzultantov a vývojárov a podnikateľov sám.

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

Moja práca je vždy spojená s vykonaním zmien v existujúcom systéme. A aby ste vykonali zmeny a získali požadovaný výsledok, musíte preskúmať, čo existuje teraz. A nezáleží na tom, čo presne robíme - konfigurujeme alebo nainštalujeme CRM systém od nuly, vytvoriť efektívny ERP systém, ktorý sa zaoberá integráciou rôznych systémov, aby sa zvýšila automatizácia práce ako celku. V každom prípade je potrebné najprv získať myšlienku existujúceho pracovného vzoru a až potom, čo môžete ponúknuť akékoľvek zmeny a premýšľať o možnostiach riešenia pre túto úlohu.

Po štúdiu existujúcej pozície vecí, mám rád akúkoľvek inú špecialistku tretej strany, vytvoriť obchodnú ponuku, v ktorej zverujem svoju víziu v detaile, ako aj akcie, ktoré musia byť implementované na vyriešenie úlohy, A samozrejme, očakávaný výsledok.

Takéto správy o prieskume práce sa získavajú objemom, neobsahujú jednu stránku, že na jednej strane je potrebné, a na druhej strane, komplikuje vnímanie. Spočiatku, ja, rovnako ako mnohí, myslel si, že priestorové správy sú dobré, pretože človek platí za prácu a je potrebné poskytnúť maximálne podrobné informácie.

Typické chyby

Funkčné modelovanie sa vykonáva pomocou širokej škály nástrojov, vrátane nie je určená na modelovanie. V druhom prípade neexistuje overenie o chybách a obmedzeniach normy. Túžba zvýšiť viditeľnosť a nedostatok skúseností často končia chyby.

Použitie rôznych farieb

Všetky položky v diagrame sú rovnako dôležité. S funkčným modelovaním nie sú žiadne viac alebo menej dôležité prvky. Zmiznutie akejkoľvek vôle povedie k porušeniu procesu a výroby manželstva.

Pri modelovaní na papieri alebo v rôznych programoch sa používajú používatelia, ktorí sa snažia zvýšiť viditeľnosť pomocou rôznych farieb. Toto je jedna z najčastejších chýb. V skutočnosti, používanie viacfarebných šípok a blokov je len dodatočný zmätok, a tiež narušuje vnímanie systému.

Váš model by mal byť čítaný v čiernej a bielej, bez ďalších farebných riešení. Tento prístup súčasne pomáha vyhnúť sa nedorozumeniam a disciplínam tvorca modelu, v dôsledku toho, čitateľnosť a gramotnosť modelu sa zvyšuje.

Príliš veľké bloky

Pri vypracovaní modelu sa všetky nuansy spoločnosti so všetkými detailmi často snažia zobraziť na jednom hárku. Výsledkom je veľmi veľký počet blokov s veľkým počtom ovládacích šípok. Čitateľnosť sa stratí.

Optimálnou možnosťou je detaily dostatočné na pochopenie otázky a nič viac. Podrobné údaje o práci každej jednotky alebo dokonca zamestnanca môžu byť zverejnené pri výbere podrobného sledovania procesu. A takáto štruktúra sa vytvára len vtedy, ak naozaj potrebuje pracovať alebo rozhodnúť.

Porušenie štruktúry pri úprave

Opatrne sa uistite, že nevyvoláva zmätok alebo procesy bez prichádzajúcich, odchádzajúcich a iných dôležitých prvkov. Napríklad, ak sa v uvedenom príklade považujem za potrebné presunúť bod pohľadu na copywriter, budem vymazaný z schémy autora. A potom kontrolné prvky "autorské skúsenosti a zdroje tretích strán", ako aj plán publikácie sa stávajú zbytočnými. Koniec koncov, teší to autor. Copywriter pracuje so zvukovým súborom. A ak zostanú v všeobecná schémaPodrobne sa vykoná, nie je jasné, kde sa má zmätok.

Podobne, ak sa rozhodnem pridať nejaký blok, je dôležité uistiť sa, že má tiež všetky potrebné atribúty. Pozoruhodnosť je tu veľmi dôležitá, pretože pri modelovaní komplexných obchodných procesov, zmeny v jednej časti modelu môžu znamenať zmeny iného. Musia byť vykonané.

Pravidlá názvu kontrolných prvkov a blokov

Je dôležité si zapamätať jednoduché pravidlo: Riadiace šípky sa nazývajú nethentné mená, bloky - slovesá. Tak prijaté v norme IDEF0 a tento prístup pomáha vyhnúť sa zmäteniu a chybám.

Najčastejšie sú chyby povolené, keď názvy blokov. Napríklad namiesto "vytvorenia článku" napíšte "vytvorenie článku". Bloky v tomto prístupe sú akcie, a preto by mali byť vždy slovesá.

Výhody pomocou IDEF0.

• Veľmi prvá výhoda je zrejmá - to je viditeľnosť. Začnete pochopiť, ako to alebo tento systém funguje, a môžete tiež jasne objasniť, kde v tomto systéme "jemné miesta" a ako vaše riešenia pomôžu zbaviť sa ich.
• Porozumenie a nedostatok nezrovnalostí. Pri diskusii o práci spoločnosti pomocou funkčného modelu máte vizuálne a zrozumiteľné intuitívne problémy s ovládacími prvkami. Okrem toho funkčné modelovanie zahŕňa vytvorenie glosára, v ktorom sú opísané podmienené oznamovanie a termíny. V dôsledku toho vy a klient, hlava, iní zamestnanci, pri diskusii o probléme, hovoria rovnakým jazykom.
• Jednoduché a vysokorýchlostné modely. Samozrejme, naučte si simuláciu nie je taká jednoduchá, ako sa zdá. Koniec koncov, systém je v skutočnosti prenasledovanie informácií, ktorá je veľmi dobrá na pochopenie, ale vykonávať takéto požadované podanie Špeciálny prístup. Mozgu Analytics pôsobí v tomto prípade ako veľmi silný stlačenie na jednej strane a filter je na druhej strane. Ale so skúsenosťami sa tento proces stáva veľmi rýchlo. V dôsledku toho získate nástroj, ktorý bude pomáhať a rozoberať sa, čo sa deje v konkrétnom systéme, as pomocou vizuálnej príručky vytvorenej v krátkom čase na ilustráciu dôležitých momentov kolegov alebo zákazníkov.
• Disciplína a žiadna chyba. Štandard IDEF0 predpokladá prísny rámec a pravidlá. Tento prístupový disciplíny a zvyk konať v rámci štandardu pomáha vyhnúť sa chybám nepozorovaniu. Akékoľvek porušenie štandardu sa stávajú okamžite zrejmé.

Čo je to ťažkosti s používaním IDEF0

Je dôležité pochopiť, že len v najjednoduchších prípadoch dvaja obchodní analytici vytvoria absolútne identické funkčné modely na opis práce spoločnosti. Akýkoľvek model je odrazom skúseností s analýzou, hĺbkou pochopenia práce podniku, ktorú snaží opísať, rovnako ako nejakým spôsobom, jeho osobné hľadisko na tomto podnikaní. Tí. Osoba vyvíja obchodný model z hľadiska hlavy, ako keby bol tento vodca ten, kto.

Zároveň sa domnievam, že obchodný analytik nie je celkom povolanie, každý obchodný analytics sa zaoberá obchodným analytikom alebo vývojárom niektorých systémov, ktoré analyzuje obchod a snaží sa vybudovať najúčinnejší systém. Je to pre týchto ľudí a na tieto účely je určený nástroj IDEF0.

Preto je veľmi dôležité pri vypracúvaní funkčného obchodného modelu "ako je" neustále poradiť s hlavou spoločnosti, aby nedošlo k chyby, ktoré znamenajú automaticky chyby v etapách rozkladu. Aj v nasledujúcich etapách sa môže vyžadovať dodatočná koordinácia s hlavami štrukturálnych jednotiek a zamestnancov. Iba vtedy, ak váš funkčný model "ako je" skutočne odráža skutočný stav, môžete vykonať nejaké zmeny a návrhy. A na dosiahnutie kvalitatívnych výsledkov v takejto práci sa vyžaduje v prvom rade, praktické skúsenosti a znalosti o charakteristikách konkrétneho typu podnikania.

Ďalšie články na túto tému.

6.2. Účel a zloženie metodiky SADT (IDEF0)

Metodika SADT (Štruktúrovaná analýza a dizajnová technika - metodika štrukturálnej analýzy a dizajnu) je súbor metód, pravidiel a postupov určených na vytvorenie funkčného modelu systému.

Začiatok vývoja tejto metodiky bol položil Douglas Ross (USA) v polovici 60. rokov. Xx v. Odvtedy majú Analytici spoločnosti Softch, Inc. Zlepšil sa SADT a použil ho pri riešení širokej škály problémov. Telefónový sieťový softvér, diagnostika, dlhodobé a strategické plánovanie, automatizovaná výroba a dizajn, konfigurácia počítačových systémov, personálny tréning, financie a logistika - tu sú niektoré z regiónov Účinná aplikácia SADT. Široké spektrum Regióny označujú univerzálnosť a silu metodiky SADT. Program "Integrácia počítačových a priemyselných technológií" (integrovaná počítačová pomocná výroba, ICAM) amerického ministerstva obrany bola uznaná ako SADT Utility. To viedlo k publikácii jeho časti v roku 1981 IDEF0. (Definícia ICAM), ako federálny štandard pre vývoj softvéru. Pod týmto názvom začal SADT aplikovať tisíce špecialistov vo vojenských a priemyselných organizáciách. Najnovšie vydanie Štandard IDEF0 bol prepustený v decembri 1993. Národný inštitút pre americké normy a technológie (Národné štandardy inštitútu a technológie, NIST).

Táto metodika opisujúca funkčný aspekt informačného systému súťaží s metódami zameranými na dátové toky (DFD). Na rozdiel od nich vám IDEF0 umožňuje:

Popíšte akékoľvek systémy, nielen Informačné (DFD je určené na opis softvéru);

Vytvorte popis systému a jeho vonkajšie prostredie pred určením konečných požiadaviek na to. Inými slovami, pomocou tejto metodiky, môžete postupne stavať a analyzovať systém, aj keď je ťažké zabrániť jeho uskutočneniu.

IDEF0 teda môže byť použitý v počiatočných štádiách vytvárania širokého kruhu systémov. Zároveň sa dá použiť na analýzu funkcií. existujúce systémy a rozhodnutie o ich zlepšení.

Základom metodiky IDEF0 je jazyk popisu grafického procesu. Model v notácii IDEF0 je kombináciou hierarchicky objednaných a prepojených diagramov. Každá schéma je jednotka popisu jednotky a nachádza sa na samostatnom liste.

Model (AS-IS, na to - BE alebo by mal byť) 4 typy diagramov [ , ]:

Kontextový diagram;

Diagramy rozkladu;

Diagramy uzlov stromu;

Grafy len na expozíciu (len pre expozíciu, FEO).

Kontextový diagram (Nosný diagram), ktorý je vrcholom stromovej štruktúry grafov, ukazuje účel systému (hlavnú funkciu) a jeho interakciu s vonkajším prostredím. V každom modeli môže byť len jeden kontextový graf. Po opise hlavnej funkcie sa vykonáva funkčná rozklad, t.j., ktorých funkcie sú hlavným.

Ďalej sú funkcie rozdelené na podfunkciu a tak, až kým sa nedosiahne požadovaná úroveň podrobnosti o štúdii systému. Diagramy, ktoré opisujú každý takýto fragment systému diagramy rozkladu . Po každom relácii rozkladu sa konajú odborné zasadnutia - odborníci na predmet ukazujú súlad reálnych procesov na vytvorené diagramy. Zistené nezrovnalosti sa eliminujú, po ktorých začínajú podrobnejšie podrobnejšie procesy.

Schéma uzlov stromov Ukazuje hierarchickú závislosť funkcií (diel), ale nie medzi nimi. Môže to byť niekoľko z nich, pretože strom môže byť postavený na ľubovoľnej hĺbke az ľubovoľného uzla.

Grafov na expozíciu je postavený na ilustráciu jednotlivých fragmentov modelu, aby sa zobrazil alternatívny pohľad na procesy vyskytujúce sa v systéme (napríklad z hľadiska riadenia organizácie).

6.3. IDEF0 Grafické notácie Prvky

Metodika IDEF0 zistila široké rozpoznávanie a aplikáciu, predovšetkým vďaka jednoduchej grafickej notácii používanej na vybudovanie modelu. Hlavnými zložkami modelu sú diagramy. Zobrazujú funkcie systému vo forme obdĺžnikov, ako aj medzi nimi a vonkajším médiom pomocou šípok. Použitie iba dvoch grafických primitívov (obdĺžnik a šípky) vám umožňuje rýchlo vysvetliť pravidlá a princípy konštrukcie diagramov IDEF0 pre ľudí, ktorí sú neznáme k tejto metodike. Táto dôstojnosť vám umožňuje pripojiť a aktivovať aktivity zákazníka na opis obchodných procesov pomocou formálneho a vizuálneho grafického jazyka.

Nasledujúci obrázok zobrazuje hlavné prvky grafického záznamu IDEF0.

Obr. 6.1. IDEF0 Grafické notácie Prvky

Obdĺžnik je práca (proces, činnosť, funkcia alebo úloha) ktorý má pevný cieľ a vedie k určitému konečnému výsledku. Názov práce by mal vyjadriť akciu (napríklad "výrobu detailov", "výpočet prípustných rýchlostí", "tvorba vyhlásenia TSDL č. 3").

Interakcia práce medzi sebou a vonkajším svetom je opísaná vo forme šípok. V IDEF0 rozlišovať 5 Šípky druhov :

- vchod (Anglický vstup) - Materiál alebo informácie, ktoré sa používajú, a je prevedené na operáciu, aby sa dosiahol výsledok (výstup). Vstupuje na otázku "Čo je predmetom spracovania?". Ako záznam môže byť ako materiál objekt (suroviny, detail, skúšobný lístok), a nie mať jasné fyzické kontúry (žiadosť o databázu, otázka učiteľa). Predpokladá sa, že práca nemusí mať žiadne vstupné šípky. Vstupné šípky sú vždy nakreslené do ľavej strany práce;

- kontrola (Anglicky Control) - Manažéri, regulačné a regulačné údaje, ktoré vedie pracovať. Vedenie odpovedá na otázku "V súlade s prácou?". Manažment ovplyvňuje prácu, ale nie je transformovaná tým, t.j. pôsobí ako obmedzenie. Ako riadenie môžu existovať pravidlá, normy, normy, sadzby, ústne pokyny. Šípka ovládania je nakreslená do hornej strany. Ak pri výstavbe diagramu, vzniká otázka, ako opraviť šípku zhora alebo doľava, odporúča sa ho nakresliť ako vstup (na ľavej strane);

- výkon (Eng. Výstup) - materiál alebo informácie, ktoré predstavujú výsledok výkonu. Výstup odpovedá na otázku "Aký je výsledok práce?". Ako výstup môže byť ako objekt materiálu (časť, auto, platobné doklady, vyhlásenie) a nehmotné (vzorka údajov z databázy, odpoveď na otázku, orálne inštrukcie). Výstupné šípy sa odchádzajú z pravej strany práce;

- mechanizmus (Eng. Mechanizmus) - Zdroje, ktoré fungujú. Mechanizmus odpovedá na otázku "Kto pracuje alebo cez čo?". Ako mechanizmus, podnikový personál, študent, stroj, vybavenie, program. Strelci mechanizmu sú čerpané v dolnom riadku práce;

- zavolať (Hovor) - Šípka označuje, že niektoré práce sa vykonávajú mimo posudzovaného bloku. Ukončené šípky sa odchádzajú z dolného aspektu práce.

6.4. Druhy väzieb medzi prácou

Po určení zloženia funkcií a vzťahov medzi nimi sa otázka vzniká na správnom zložení (kombinácii) v moduloch (subsystémy). V tomto prípade je zrejmé, že každá jednotlivá funkcia by mala vyriešiť jednu, prísne definovanú úlohu. V opačnom prípade je potrebné ďalšie rozklad alebo oddelenie funkcií.

Pri kombinácii funkcií v podsystéme je potrebné usilovať sa o zabezpečenie toho, aby vnútorná konektivita (medzi funkciami vo vnútri modulu) bola čo najpodávateľná a externá (medzi funkciami obsiahnutými v rôznych moduloch), ako je to možné, ako je to možné. Spoliehať sa na sémantiku vzťahu metodiky, zavádzame klasifikáciu väzieb medzi funkciami (operácie). Táto klasifikácia je rozšírenie. Typy spojení sú uvedené s cieľom znížiť ich význam (väzbová sila). V príkladoch uvedených v príkladoch sú funkcie pridelené, medzi ktorými existuje typ komunikácie.

1. Hierarchické pripojenie (komunikácia "časť" - "celá") Týka sa medzi funkciou a poddateľnosťami, z ktorých pozostáva.

Obr. 6.2. Hierarchická komunikácia

2. Regulačná (správa, podriadená) Odráža závislosť jednej funkcie od druhého, keď je výstup jednej práce odoslaný na riadenie druhého. Funkcia, z ktorej vydáva kontrolu, by sa mala považovať za regulačnú alebo kontrolnú, a v ktorej obsahuje podriadený. Rozlišovať priamej komunikácie Keď je riadenie prenášané z nadradeného na spodnú (obr. 6.3) a kontrola riadenia Keď sa riadenie prenáša zo spodného prúdu k vyššej (obr. 6.4).

3. Funkčná (technologická) komunikácia Existuje miesto, keď výstup jednej funkcie slúži ako vstupné údaje pre nasledujúcu funkciu. Z hľadiska toku materiálov objektov toto oznámenie Zobrazuje technológiu (postupnosť práce) spracovanie týchto objektov. Rozlišovať priama komunikácia pri vchode Keď sa výstup prenáša z prevádzky proti prúdu na spodnú (obr. 6.5) a vstupná spätná väzba Keď sa výstup prenáša s downstreamom k vyššiemu (obr .6.6).

Obr. 6.5. Priama komunikácia pri vchode	Obr. 6.6. Spätná väzba na vchode

4. Spotrebiteľská komunikácia Existuje miesto, keď výstup jednej funkcie slúži ako mechanizmus pre nasledujúcu funkciu. Jedna funkcia teda spotrebuje zdroje vyrobené druhou.

Obr. 6.7. Spotrebiteľská komunikácia

5. Logická komunikácia Pozoruje sa medzi logicky homogénnymi funkciami. Takéto funkcie spravidla vykonávajú rovnakú prácu, ale rôzne (alternatívne) metódy alebo používanie rôznych zdrojových údajov (materiály).

Obr. 6.8. Logická komunikácia

6. Kolektívna (metodická) komunikácia Prechádza sa medzi funkciami, ktorých algoritmus je určený rovnakou kontrolou. Analógou takejto spojenia je spoločná práca zamestnancov jedného oddelenia (kolegovia), ktorá podáva šéfa, ktorá poskytuje pokyny a objednávky (riadiace signály). Takýto odkaz tiež nastane, keď algoritmy fungovania týchto funkcií sú určené rovnakou metodologickou podporou (SNIP, GOST, oficiálne regulačné materiály atď.), Ktorý slúži ako manažment.

Obr. 6.9. Metodická komunikácia

7. Komunikácia zdroja Vyskytuje sa medzi funkciami, ktoré využívajú rovnaké zdroje na ich prácu. Funkcie závislé od zdrojov nie je spravidla možné vykonať súčasne.

Obr. 6.10. Komunikácia zdroja

8. Informačná komunikácia Prechádza sa medzi funkciami pomocou rovnakých informácií ako vstupných údajov.

Obr. 6.11. Informačná komunikácia

9. Dočasná komunikácia Vyskytuje sa medzi funkciami, ktoré sa musia vykonať súčasne pred alebo súčasne po inej funkcii.

Okrem tých, ktoré sú uvedené na obrázku, sa toto pripojenie vyskytuje aj medzi inými kombináciami riadenia, vstupu a mechanizmov zadaním jednej funkcie.

Obr. 6.12. Dočasná komunikácia

10. Komunikácia Vyskytuje sa, keď špecifický vzťah medzi funkciami malých alebo je úplne neprítomný.

Obr. 6.13. Komunikácia

Z vyššie uvedených druhov odkazov je hierarchická väzba najsilnejšia, čo v skutočnosti určuje kombináciu funkcií v moduloch (subsystémy). Niekoľko slabé, reguluje, funkčné a spotrebiteľské spojenia. Funkcie s týmito pripojeniami sa zvyčajne implementujú v rovnakom podsystéme. Jedným z najslabších sú logické, kolegiálne, zdrojové a informačné spojenia. Funkcie s nimi sú zvyčajne implementované v rôznych podsystémoch, s výnimkou logicky homogénnych funkcií (funkcie spojené s logickým odkazom). Dočasné pripojenie poukazuje na slabú závislosť funkcií navzájom a vyžaduje ich implementáciu v samostatných moduloch.

Pri kombinácii funkcií v moduloch je teda najžiadanejšie prvé päť typov väzieb. Funkcie týkajúce sa posledných piatich pripojení sú lepšie implementované v samostatných moduloch.

IDEF0 má dohody (pravidlá a odporúčania) na vytvorenie diagramov, ktoré sú určené na uľahčenie čítania a preskúmania modelu [,]. Niektoré z týchto pravidiel prípadu podporujú automaticky, iná realizácia by sa mala poskytovať manuálne.

1. Pred budovaním modelu je potrebné určiť, ktorý model (modely) systému bude postavený. To znamená, že definícia jeho typu as-je, ako by mala byť alebo by mala byť, ako aj určovanie polohy, z hľadiska, ktorého model je postavený. "Pohľad" je najlepšie predstaviť ako miesto (pozícia) osoby alebo objektu, v ktorom musíte vidieť, aby ste videli systém v akcii. Napríklad pri budovaní modelu produktu obchodu s potravinami, môžete medzi možnými žiadateľmi, z hľadiska, ktorého sa systém zvažuje, vyberte predajcu, pokladníka, účtovníka alebo riaditeľa. Jeden pohľad je zvyčajne zvolený, najviac plne prijať všetky nuansy systémovej práce, a v prípade potreby pre niektoré diagramy rozkladu, sú vybudované FEO diagramy zobrazujúce alternatívne hľadisko.

2. Na kontextovom diagrame sa zobrazí jeden blok, ktorý označuje účel systému. Odporúča sa zobraziť 2-4 šípky, ktoré pochádzajú z každej strany.

3. Počet blokov na diagramoch rozkladu sa odporúča v rámci 3-6. Ak existujú dva bloky na diagrame rozkladu, potom to zvyčajne nedáva zmysel. V prítomnosti veľké číslo Bloky diagramu sa stávajú nadmernou a ťažkou čítaním.

4. Bloky na diagrame rozkladu by sa mali umiestniť doľava doprava a zhora nadol. Táto poloha vám umožňuje jasnejšie odrážať logiku a sled práce. Okrem toho budú šípky menšie mätúce a majú minimálnu križovatku.

5. Nedostatok funkcie súčasne nie je povolená šípka ovládania a vstupu. To znamená, že spustenie tejto funkcie nie je kontrolované a môže nastať kedykoľvek čas alebo nikdy.

Obr. 6.14. Funkcia bez kontroly a vstupu

Blok s dostupnosťou iba ovládania je možné zobraziť ako hovor v funkčnom programe (postupy) bez parametrov. Ak má blok vstup, je ekvivalentný volaniu funkcie s parametrami. Blok bez kontroly a vstupu je teda rovnocenný s funkciou, že v programe sa nikdy nevyvoláva vykonaním.

Na obr. 6.7-6.12, Zobrazenie fragmentov diagramov IDEF0, tam sú bloky bez protokolovania a kontroly. Nie je potrebné považovať za chybu, pretože je zrejmé, že jedna z týchto šípok by mala byť.

6. Každý blok musí mať aspoň jeden výstup.

Obr. 6.15. Funkcia bez výjazdu

Práca bez výsledku nedáva zmysel a nemali by byť modelované. Výnimkou je práca zobrazená v modeli AS-IS. Ich prítomnosť označuje neefektívnosť a nedokonalosť technologických procesov. Vo vzorovom modeli musia tieto práce chýba.

7. Pri budovaní diagramov minimalizujte počet križovatiek, slučiek a otočení šípok.

8. Spätná väzba a iterácie (cyklické akcie) môžu byť zobrazené pomocou reverzných oblúkov. Inverzné odkazy na vchode sú čerpané "nižšia" slučka, spätná väzba na manažment - "top" (pozri obr. 6.4 a 6.6).

9. Každá jednotka a každá šípka na schémach musí mať nutne meno. Je povolené používať rozvetvenie (rozklad) alebo zlúčenie (zloženie) šípok. Je to spôsobené tým, že rovnaké údaje alebo objekty generované jednou prácou môžu byť použité okamžite v niekoľkých ďalších prácach. Naopak, identické alebo homogénne údaje a objekty generované rôznymi dielami môžu byť použité na jednom mieste.

Obr. 6.16. Šípky pobočiek

Zároveň je možné nastaviť šípku objasnenie po rozvetve (pred zlúčením). Ak sa každá vetva po pobočke nepredstavuje, predpokladá sa, že jeho názov zodpovedá názvu šípky zaznamenanej pred vekom.

Na obr. 6.16 Správa zahrnutá do "Výroba detailov" a "Product Montážne" Bloky majú objasniť hodnoty a sú neoddeliteľnou súčasťou celkovej kontroly "kresieb". Všetky výkresy sa používajú na prácu "kontrolu kvality".

Diagram neumožňuje šípky čerpať, keď pred a po rozvetve nie sú pomenované. Na obr. 6.17 Šípka vstupujúca do bloku "tvorba typických výrokov" nemá názov pred a po rozvetve, čo je chyba.

Obr. 6.17. Nesprávne meno strelca

10. Pri stavebných diagramoch pre lepšiu čitateľnosť je možné použiť tunelovací mechanizmus šípok. Napríklad, aby sa neporiadok horná hladina horných úrovní (rodičovská), na diagramoch rozkladu, oblúk sa umiestni do tunela.

Obr. 6.18. Tunelovacie šípky

V tomto príklade pri budovaní modelu nový rok Matinee Mechanizmus "Dve AX" sa nezobrazí na vyšších schémach, pri čítaní, ktoré môže vzniknúť veľká otázka: "Prečo potrebujete dve osi na novoročnej matinee?".

Podobne môžete vykonávať tunelovanie s inverzným účelom - zabránenie zobrazeniu šípky v diagramoch nižšie úrovne. V tomto prípade sa na konci šípky umiestnia okrúhle zátvorky. Na kontextovom diagrame (pozri obr. 6.21), mechanizmus procesu servisného inžiniera, ktorý je zahrnutý v "definícii povolenej rýchlosti" bloku. Toto rozhodnutie sa vykonáva, pretože inžinier sa priamo zúčastňuje na všetkých prácach zobrazených v diagrame rozkladu tohto bloku (pozri obr. 6.22). Aby ste nezobrazili toto pripojenie a nezával diagram rozkladu, bola prehratá šípka.

11. Na ňom musia byť zobrazené všetky šípky prichádzajúce a opustenie bloku pri budovaní diagramu rozkladu. Vylúčenie je cheesedové šípy. Názvy strelcov prevedených do grafu rozkladu by sa mali zhodovať s názvami uvedenými na schéme na najvyššej úrovni.

12. Ak sú dva šípky prejsť paralelne (od jedného a rovnakej aspektu jednej práce a končia na rovnakom aspekte inej práce), ak je to možné, by ich mali kombinovať a volať jeden termín.

Obr. 6.19. Kombinovanie pripojení

13. Každý blok na diagramoch by mal mať svoje vlastné číslo. Ak chcete zadať polohu akéhokoľvek diagramu alebo bloku v hierarchii, používajú sa čísla grafu. Blok na hornom diagrame je označený 0, bloky na diagramoch druhej úrovne - čísla od 1 do 9 (1, 2, ..., 9), bloky na tretej úrovni - dve číslice, z ktorých prvá označuje počet podrobného bloku z materskej schémy a druhé blokové číslo v poradí na aktuálnom diagrame (11, 12, 25, 63) atď. Kontextový diagram má označenie "A - 0", diagram Rozklady prvej úrovne - "A0", diagramy rozkladu nasledujúcich úrovní - pozostávajú z písmena "A", po ktorom nasleduje počet rozložených blokov (napríklad "A11", "A12", "A25", \\ t "A63"). Obrázok ukazuje typický strom diagramu (diagram stromov uzdením) s číslovaním.

Obr. 6.20. Hierarchické diagramy

V moderných prípadoch sú mechanizmy číslovania automaticky podporované. Prípadové prostriedky tiež poskytujú automatickú konštrukciu diagramov uzne, ktoré obsahujú iba hierarchické väzby. Vertex takéhoto diagramu môže byť akýkoľvek uzol (blok) a môže byť postavený na akomkoľvek hĺbke.

6.6. Príklad konštrukcie modelu IDEF0 pre systém na určenie prípustných rýchlostí

Výpočet prípustných rýchlostí vlakov je časovo náročná inžinierska úloha. Pri prechode vlakom, akúkoľvek stránku, skutočná rýchlosť vlaku by nemala prekročiť maximálnu povolenú. Táto maximálna prípustná rýchlosť je stanovená na základe prevádzkových skúseností a špeciálne vykonaných testov na dynamike pohybu a účinku na cestu železničných koľajových vozidiel. Zlyhanie tejto rýchlosti zaručuje bezpečnosť vlakov pohyb, pohodlné podmienky pre jazdu cestujúcich atď. Sú určené v závislosti od typu železničných koľajových vozidiel (značka lokomotívy a typu vozňov), parametre hornej časti Štruktúra dráhy (typ koľajníc, predradníkov, spanks) a plán (krivky polomerov, prechodové krivky, zvýšenie vonkajšej koľajnice atď.). Spravidla je potrebné určiť aspoň dve (na priame) a päť (v krivkách) rýchlosť, aby sa vytvorili povolené rýchlosti, z ktorých konečná prípustná rýchlosť je vybraná ako najmenšia zo všetkých vypočítaných. Výpočet týchto rýchlostí sa riadi poradím ministerstva núdzových situácií Ruska č. 41 z 12. novembra 2001. "Normy prípustnej rýchlosti pohybu železničných koľajových vozidiel na železničných tratiach kráľa 1520 (1524) mm Federálna železničná doprava ".

Ako je uvedené, stavba modelu IDEF0 začína reprezentáciou celého systému ako najjednoduchší komponent (kontextový diagram). Tento graf zobrazuje priradenie (základná funkcia) systému a potrebných vstupných a výstupných, riadiacich a regulačných informácií, ako aj mechanizmy.

Kontextový diagram pre definíciu prípustných rýchlostí je znázornený na obr.6.21. Ak chcete vytvoriť model, produkt BPWIN 4.0 použili počítačové asociáty.

Obr. 6.21. Kontextový diagram systému na určenie prípustných rýchlostí (metodika IDEF0)

Ako zdrojové informácieNa základe ktorých sa stanoví stanovenie prípustných rýchlostí:

Údaje o projekte nového riadku alebo projektu rekonštrukcie (obsahujú všetky potrebné informácie o realizácii projektu, konkrétne kilomera, osi samostatných položiek, riadkový plán atď.);

Podrobný pozdĺžne profil (obsahuje informácie podobné vyššiemu);

Cesta vzdialenosti pasov (obsahuje informácie podobné vyššie uvedenému, ako aj informácie o hornej štruktúre dráhy (VSP));

Údaje o výsledkoch plánu streľby cesty pasážou;

Vyhlásenie o zvýšení vonkajšej koľajnice v krivkach (obsahuje informácie o ceste cesty).

Časť zdrojových informácií možno prevziať z rôznych zdrojov. Najmä informácie o pláne (parametre kriviek) môžu byť prevzaté z projektu nového riadku alebo projektu rekonštrukcie, podrobného pozdĺžneho profilu, cestovných pasov, atď.

Manažéri údajov sú:

Špecifikujú vedúceho cestnej cesty alebo oddelenia cestnej dopravy a štruktúr ruských železníc na výpočet;

Objednávacie číslo 41 obsahujúce regulačné a referenčné informácie, poriadok a vzorec pre stanovenie prípustných rýchlostí;

Informácie o aktuálnej alebo plánovanej trase (údaje o značkách kontaktných lokomotív a typov automobilov);

Informácie o plánovaných opravách, rekonštrukcii a reorganizácii štruktúr a zariadení.

Výsledok Systémové práce musia byť:

VEDOMOSTI povolené rýchlosti obsahujúce všetky typy vypočítaných rýchlostí a umožnili stanoviť príčinu ich obmedzení;

Vyhlásenie o poradí hlavy cesty na zriadenie prípustných rýchlostí na destilácii a samostatných položkách (objednávka "H") podľa formulára prijatej na ceste. Schválená objednávka "H" oficiálne zakotvila prípustné rýchlosti vlakov;

Typické formy č. 1, 1A a 2, ktoré obsahujú plánované prípustné rýchlosti pre vývoj harmonogramov vlakov.

Rýchlosti obsiahnuté v "H" a typických formách sa môžu líšiť od vypočítaného a zobrazené v trvalej rýchlosti. Je to spôsobené tým, že odrážajú obmedzenia rýchlosti nielen navrhovaním železničných koľajových vozidiel, parametrov VSP a kriviek, ale aj stavom zariadení a konštrukcií (deformácia Zeme Canvas, konektor kontaktných sietí podporuje atď.). Okrem toho sú upravené s prihliadnutím na plánované opravy dráhy, rekonštrukcie a reorganizácie štruktúr a zariadení atď.

Po vytvorení kontextového diagramu je podrobne opísaný pomocou diagramu rozkladu prvej úrovne. Tento diagram zobrazuje funkcie systému, ktorý musí byť implementovaný v rámci hlavnej funkcie. Diagram, pre ktorý sa rozklad uskutočňuje, vo vzťahu k detailom jeho diagramov sa nazýva rodičovský . Rozkladový diagram vo vzťahu k rodičovstvu dcéra .

Diagram rozkladu prvého stupňa pre posudzovaný problém je znázornený na obr. 6.22. Spravidla, pri výstavbe diagramu rozkladu, počiatočná funkcia (rozložená) je rozdelená do 3-8 subfunkcií (blokov). Súčasne sa odporúčajú bloky na diagrame rozkladu, aby boli ponechané vpravo od horného až do dna, takže sekvencia a logika interakcie subfunkcií je lepšie viditeľná.

Obr. 6.22. Graf rozdelenia prvej úrovne (metodika IDEF0)

Priorita funkcií na vyriešenie posudzovaného problému takto: \\ t

Vstup a nastavenie regulačných informácií a údajov na miestach ciest (bloky 1 a 2);

Príprava priradenia výpočtu (blok 3). Uvádza to, pre ktorú miesto a cesta, ako aj značka lokomotívy a typu automobilov, výpočet by sa mal vypočítať;

Výpočet prípustných rýchlostí v súlade s postupom a vzorcami uvedenými v poradí č. 41 (blok 4). Ako počiatočné informácie, údaje o ceste miesta (plán, horná štruktúra cesty atď.) A normy vybrané na základe priradenia výpočtu sa vykonávajú;

Tvorba výrokov prípustných rýchlostí (blok 5). Na základe výsledkov výpočtu sa vytvorí niekoľko typov výstupných dokumentov, ktoré na jednej strane umožňujú odhaliť dôvod obmedzení rýchlosti, na druhej strane pôsobiť ako základ pre prípravu regulovaných dokumentov ; \\ T

Tvorba a príprava projektu objednávky "H" a typické vyhlásenia (bloky 6 a 7).

Po výstavbe prvého diagramu rozkladu pre funkcie uvedené na ňom sú vytvorené individuálne grafy (diagramy rozkladu druhej úrovne). Potom proces rozkladu (konštrukčné diagramy) pokračuje, kým sa ďalej podrobne podrobne opisuje význam. Pre každú atómovú funkciu opisujúcu základnú operáciu (t.j. funkcia, ktorá nemá graf rozkladu) obsahuje podrobnú špecifikáciu, ktorá určuje jeho vlastnosti a algoritmus implementácie. Ako doplnok k špecifikácii môžu byť použité blokové diagramy algoritmov. Proces funkčného modelovania je teda postupne vybudovať hierarchiu funkcií.

6.7. ICOM-kódy

Šípky zahrnuté v bloku a vychádzajú z neho na vrcholovom diagrame sú rovnaké ako šípky obsiahnuté v diagrame dolnej úrovne a vznikajúce, pretože jednotka a diagram predstavujú rovnakú časť systému (pozri obr , A). Výsledkom je, že hranice funkcie najvyššej úrovne sú rovnaké ako hranice grafu rozkladu.

ICOM-kódy (Abbretetura z vstupu, kontroly, výstupu a mechanizmu) sú určené na identifikáciu hraničných šípok. Kód ICOM obsahuje predponu, ktorá zodpovedá typu šípky (I, C, O alebo M) a sekvenčné číslo (pozri obr.).