IDef0 dijagram na primjeru računalne igre. Pravila za imenovanje upravljačkih elemenata i blokova. A63 Dijagram toka podataka

IDEF0 metodologija

IDEF0 metodologija propisuje izgradnju hijerarhijskog sustava dijagrama – pojedinačnih opisa fragmenata sustava. Najprije se provodi opis sustava kao cjeline i njegove interakcije s vanjskim svijetom (kontekstni dijagram), nakon čega se provodi funkcionalna dekompozicija - sustav se dijeli na podsustave i opisuje se svaki podsustav zasebno (dekompozicijski dijagrami). . Zatim se svaki podsustav dijeli na manje, i tako dalje dok se ne postigne željena razina detalja.

Svaki IDEF0 dijagramiA sadrži blokove i lukove. Blokovi prikazuju funkcije modeliranog sustava. Lukovi povezuju blokove i predstavljaju interakcije i odnose među njima.

Funkcionalni blokovi (rad) u dijagramima predstavljeni su pravokutnicima, koji predstavljaju imenovane procese, funkcije ili zadatke koji se odvijaju tijekom određenog vremenskog razdoblja i imaju prepoznatljive rezultate. Naziv djela mora biti izražen kao glagolska imenica koja označava radnju.

IDEF0 zahtijeva da dijagram ima najmanje tri i ne više od šest blokova. Ova ograničenja održavaju složenost dijagrama i modela na razini koja je čitljiva, razumljiva i upotrebljiva.

Svaka strana bloka ima posebnu, vrlo specifičnu svrhu. Lijeva strana bloka je za ulaze, gornja za kontrolu, desna za izlaze, a donja za mehanizme. Ova oznaka odražava određena načela sustava: ulazi se pretvaraju u izlaze, kontroliraju ograničenja ili propisuju uvjete za provođenje transformacija, mehanizmi pokazuju što i kako funkcija obavlja.

Blokovi u IDEF0 raspoređeni su po važnosti, kako ih razumije autor dijagrama. Ovaj relativni poredak naziva se dominacija. Dominacija se shvaća kao utjecaj koji jedan blok ima na druge blokove u dijagramu. Na primjer, najdominantniji blok dijagrama može biti ili prvi u potrebnom nizu funkcija ili funkcija planiranja ili kontrole koja utječe na sve ostale.

Najdominantniji blok obično se nalazi u gornjem lijevom kutu dijagrama, a najmanje dominantan u desnom kutu.

Raspored blokova na stranici odražava autorovu definiciju dominacije. Dakle, topologija dijagrama pokazuje koje značajke imaju veći utjecaj na druge. Kako bi to naglasio, analitičar može prenumerirati blokove prema njihovom redoslijedu dominacije. Redoslijed dominacije može se naznačiti brojem postavljenim u donjem desnom kutu svakog pravokutnika: 1 označava najveću dominaciju, 2 sljedeću, itd.

Interakcija radova s vanjskim svijetom i međusobno opisana je u obliku strelica, prikazanih kao pojedinačne linije sa strelicama na krajevima. Strelice predstavljaju neke informacije i nazivaju se imenicama.

IDEF0 razlikuje pet vrsta strelica.

Ulaz- objekti koji se koriste i transformiraju radom da bi se dobio rezultat (output). Dopušteno je da rad nema jednu ulaznu strelicu. Ulazna strelica se crta kao ulaz na lijevi rub rada.

Kontrolirati-.informacije koje upravljaju radnjama djela. Tipično, kontrolne strelice nose informacije koje pokazuju što posao treba učiniti. Svaki posao mora imati najmanje jednu kontrolnu strelicu, koja je prikazana kao da ulazi u gornji rub posla.

Izlaz- objekti u koje se ulazi pretvaraju. Svaki posao mora imati najmanje jednu strelicu za izlaz, koja se crta tako da izlazi s desnog ruba posla.

Mehanizam- sredstva koja obavljaju posao. Strelica mehanizma je nacrtana kao da ulazi u donji rub rada. Prema odluci analitičara, strelice mehanizma ne smiju biti prikazane na modelu.

Poziv- posebna strelica koja pokazuje na drugi operativni model. Strelica poziva je nacrtana kao da dolazi s dna rada i koristi se za označavanje da se neki rad izvodi izvan sustava koji se modelira.

Riža. 2.1 Vrste strelica

IDEF0 metodologija zahtijeva samo pet tipova interakcija između blokova za opisivanje njihovih odnosa: kontrola, ulaz, povratna sprega kontrole, povratna informacija ulaza, izlazni mehanizam. Upravljačke i ulazne veze su najjednostavnije jer odražavaju izravne utjecaje koji su intuitivni i vrlo jednostavni.

Riža. 2.2. Izlazna komunikacija

Riža. 2.3. Upravljačke komunikacije

Kontrolni odnos se javlja kada izlaz jednog bloka izravno utječe na manje dominantan blok.

Kontrolna povratna informacija i ulazna povratna informacija su složenije jer uključuju iteraciju ili rekurziju. Naime, izlazi iz jednog posla utječu na buduće izvršenje drugih poslova, što naknadno utječe na izvorni posao.

Tada dolazi do povratne sprege upravljanja; kada izlaz nekog bloka utječe na blok s većom dominacijom.

Odnosi izlazni mehanizam su rijetki. Oni odražavaju situaciju u kojoj rezultat jedne funkcije postaje sredstvo za postizanje cilja druge.

Riža. 2.4. Povratne informacije o prijavi

Riža. 2.5. Povratne informacije uprave

Odnosi učinak-mehanizam karakteristični su za raspodjelu izvora resursa (npr. potrebni alati, obučeno osoblje, fizički prostor, oprema, financiranje, materijali).

U IDEF0, luk rijetko predstavlja jedan objekt. Obično simbolizira skup objekata. Budući da lukovi predstavljaju skupove objekata, mogu imati više početnih točaka (izvora) i završnih točaka (odredišta). Stoga se lukovi mogu granati i spajati na različite načine. Cijeli luk ili njegov dio može se protezati od jednog ili više blokova i završavati u jednom ili više blokova.

Lukovi grananja, prikazani zrakastim linijama, znače da se cijeli ili dio sadržaja lukova može pojaviti u svakoj grani. Luk se uvijek označava prije grane kako bi se dao naziv cijelom skupu. Dodatno, svaka grana luka može, ali i ne mora biti označena prema sljedećim pravilima:

neoznačene grane sadrže težinu objekata navedenih u oznaci luka prije grane;

grane označene nakon točke grananja sadrže sve ili dio objekata navedenih u oznaci luka prije grananja.

Spajanja luka u IDEFO-u, prikazana kao linije koje konvergiraju zajedno, pokazuju da sadržaj svake grane ide u obliku oznake za luk koji je rezultat spajanja originalnih lukova. Nakon spajanja, dobiveni luk uvijek je označen kako bi označio novi skup objekata koji proizlaze iz spajanja. Dodatno, svaka grana može ali ne mora biti označena prije spajanja, prema sljedećim pravilima:

Riža. 2.6. Veza izlazni mehanizam

neoznačene grane sadrže težinu objekata navedenih u zajedničkoj oznaci luka nakon spajanja;

grane označene prije spajanja sadrže sve ili neke od objekata navedenih u zajedničkoj oznaci nakon spajanja,

broj blokova na dijagramu - N;

razina dekompozicije dijagrama - L;

ravnoteža dijagrama - U;

broj strelica koje se povezuju s blokom - A

Ovaj skup čimbenika primjenjuje se na svaki dijagram modela. U nastavku će biti navedene preporuke o željenim vrijednostima faktora u dijagramu.

Potrebno je težiti tome da broj blokova na dijagramima nižih razina bude manji od broja blokova na matičnim dijagramima, tj. s povećanjem stupnja dekompozicije koeficijent se smanjuje. Dakle, smanjenje ovog koeficijenta ukazuje na to. da kako se model dekomponira, funkcije bi se trebale pojednostaviti, stoga bi se broj blokova trebao smanjiti.

Dijagrami moraju biti uravnoteženi. To znači da se unutar jednog dijagrama ne bi trebala dogoditi situacija prikazana na slici 1. 2.7: rad 1 ima znatno više dolaznih i kontrolnih strelica nego odlaznih. Treba napomenuti da se ova preporuka ne može slijediti u modelima koji opisuju proizvodne procese. Na primjer, kada se opisuje postupak sklapanja, blok može sadržavati mnogo strelica koje opisuju komponente proizvoda i jednu strelicu koja izlazi - gotov proizvod.

Riža. 2.7. Primjer neuravnoteženog grafikona

Uvedimo koeficijent ravnoteže dijagrama

Potrebno je nastojati da se Q bio minimalan za grafikon.

Osim analize grafičkih elemenata dijagrama, potrebno je razmotriti nazive blokova. Za procjenu naziva sastavlja se rječnik elementarnih (trivijalnih) funkcija modeliranog sustava. Zapravo bi ovaj rječnik trebao uključivati funkcije niže razine dekompozicije dijagrama. Na primjer, za model baze podataka, funkcije "pronađi zapis" i "dodaj zapis u bazu podataka" mogu biti elementarne, dok funkcija "registracija korisnika" zahtijeva daljnji opis.

Nakon formiranja rječnika i sastavljanja paketa dijagrama sustava, potrebno je razmotriti nižu razinu modela. Ako postoje podudaranja između naziva blokova dijagrama i riječi iz rječnika, to znači da je postignuta dovoljna razina dekompozicije. Koeficijent koji kvantitativno odražava ovaj kriterij može se napisati kao L*C- umnožak razine modela i broja podudaranja naziva blokova s riječima iz rječnika. Što je niža razina modela (veći L), to su šibice vrjednije.

Kada pokrenete BPWin, glavna alatna traka, paleta alata i Model Explorer pojavljuju se prema zadanim postavkama.

Prilikom izrade novog modela pojavljuje se dijalog u kojem treba označiti hoće li se model kreirati iznova ili će se otvoriti iz ModelMart repozitorija, upisati naziv modela i odabrati metodologiju po kojoj će se model graditi ( Slika 2.8).

sl.2.8 Dijalog za izradu modela

BPWin podržava tri metodologije - IDEF0, IDEF3 i DFD. U BPWin-u je moguće izgraditi mješovite modele, tj. model može istovremeno sadržavati IDEF0 i IDEF3 dijagrame i DFD. Sastav palete alata mijenja se automatski kada se prebacite s jedne oznake na drugu.

Model u BPWin-u smatra se skupom radova od kojih svaki radi s određenim skupom podataka. Ako kliknete bilo koji objekt modela lijevom tipkom miša, pojavljuje se skočni kontekstni izbornik, čija svaka stavka odgovara uređivaču svojstva objekta.

Izgradnja modela sustava trebala bi započeti proučavanjem svih dokumenata koji opisuju njegovu funkcionalnost. Jedan od tih dokumenata je tehnička specifikacija, odnosno odjeljci „Svrha razvoja“, „Ciljevi i zadaci sustava“ i „Funkcionalne karakteristike sustava“.

Nakon proučavanja izvornih dokumenata i razgovora s kupcima i korisnicima sustava, potrebno je formulirati svrhu modeliranja i odrediti gledište na model. Razmotrimo tehnologiju njegove izgradnje na primjeru sustava "Sveučilišna služba za zapošljavanje", čije su glavne mogućnosti opisane u laboratorijskom radu br.

Formulirajmo cilj modeliranja: opisati funkcioniranje sustava koje bi bilo razumljivo njegovom korisniku, ne ulazeći u detalje vezane uz implementaciju. Model ćemo graditi sa stajališta korisnika (student, nastavnik, administrator, dekanat, tvrtka).

Počnimo izgradnjom IDEF0 kontekstnog dijagrama. Prema opisu sustava, glavna funkcija je služiti svojim klijentima obradom zahtjeva primljenih od njih. Dakle, jedini posao kontekstnog dijagrama definiramo kao "Služiti klijentu sustava." Zatim definiramo ulazne i izlazne podatke, te mehanizme i upravljanje.

Da bi klijent bio uslužan, potrebno ga je registrirati u sustav, otvoriti pristup bazi podataka i obraditi njegov zahtjev. Ulazni podaci bit će "ime klijenta", "lozinka klijenta", "izvorna baza podataka", "zahtjev klijenta". Izvršenje zahtjeva dovodi ili do primanja informacija iz sustava ili do promjene sadržaja baze podataka (primjerice, kod izrade stručnih procjena), pa će izlazni podaci biti “izvješća” i “promijenjena baza podataka”. Proces obrade zahtjeva vršit će monitor sustava pod kontrolom administratora.

Tako definiramo kontekstni dijagram sustava (slika 2.9).

Slika 2.9. Dijagram konteksta sustava

Rastavimo kontekstni dijagram, opisujući redoslijed korisničke usluge:

Određivanje razine pristupa sustavu.

Izbor podsustava.

Pristup podsustavu.

Promjena baze (ako je potrebno).

Dobivamo dijagram prikazan na sl. 2.10.

Nakon što završite dekompoziciju kontekstnog dijagrama, prijeđite na dekompoziciju dijagrama sljedeće razine. Tipično, kada se razmatraju treća i niža razina, modeli se vraćaju na matične dijagrame i prilagođavaju ih.

Riža. 2.10. Dekompozicija rada “Usluga, klijent sustava”

Rastavljamo sekvencijalno sve blokove dobivenog dijagrama. Prvi korak u određivanju razine pristupa sustavu je određivanje kategorije korisnika. Ime klijenta se pretražuje u bazi korisnika, određujući njegovu kategoriju. Prema određenoj kategoriji određuju se ovlasti koje korisnik sustava ima. Zatim se provodi procedura pristupa sustavu uz provjeru pristupnog imena i lozinke. Kombinacijom informacija o ovlastima i razini pristupa sustavu formira se skup dopuštenih radnji za korisnika. Stoga će određivanje razine pristupa sustavu izgledati kao što je prikazano na sl. 2.11.

Riža. 2.11. Dekompozicija rada “Određivanje razine pristupa sustavu”

Nakon završetka procedure pristupa sustavu, monitor analizira zahtjev klijenta, odabirući podsustav koji će obraditi zahtjev. Dekompozicija djela “Apel na podsustav” ne odgovara svrsi i gledištu modela. Korisnika sustava ne zanimaju interni algoritmi njegovog rada. U ovom slučaju mu je bitno da će izbor podsustava biti napravljen automatski, bez njegove intervencije, pa će dekompozicija pristupa podsustavu samo zakomplicirati model.

Dekomponiramo posao “Obrada zahtjeva klijenta”, koji obavlja podsustav za obradu zahtjeva, određujući kategorije i ovlasti korisnika. Prije traženja odgovora na upit morate otvoriti bazu podataka (spojiti se na nju). Općenito, baza podataka može se nalaziti na udaljenom poslužitelju, pa će možda biti potrebno uspostaviti vezu s njom. Odredimo slijed rada:

Otvaranje baze podataka.

Izvršavanje zahtjeva.

Generiranje izvješća.

Nakon otvaranja baze potrebno je obavijestiti sustav da je veza s bazom uspostavljena, zatim izvršiti zahtjev i generirati izvješća za korisnika (Slika 2.12).

Treba napomenuti da “Izvršenje upita” uključuje rad različitih podsustava. Primjerice, ako zahtjev uključuje testiranje, tada će ga izvršiti podsustav stručnih i psiholoških testova. U fazi izvršenja upita može biti potrebno promijeniti sadržaj baze podataka, na primjer, prilikom sastavljanja stručnih procjena. Stoga je u dijagramu potrebno predvidjeti ovu mogućnost.

Riža. 2.12.

Prilikom analize dobivenog dijagrama postavlja se pitanje: koja se pravila koriste za generiranje izvješća? Potrebno je imati unaprijed generirane predloške koji će se koristiti za odabir iz baze, a ti predlošci moraju odgovarati upitima i moraju biti predefinirani. Osim toga, klijentu treba dati mogućnost izbora oblika izvješća.

Prilagodimo dijagram dodavanjem strelica "Predlošci izvješća" i "Zahtjevi za promjenu baze podataka" i strelice tunela "Klijent sustava". Tuneliranje “Klijenta sustava” koristi se kako se strelica ne bi postavljala na gornji dijagram, budući da funkcija odabira forme izvješća nije dovoljno važna da bi se prikazala na roditeljskom dijagramu.

Promjena dijagrama rezultirat će prilagodbama svih matičnih dijagrama (sl. 2.13 - 2.15).

Preporučljivo je dekomponirati rad "Izvršenje upita" pomoću DFD dijagrama (laboratorijski rad br. 3), budući da IDEF0 metodologija smatra sustav skupom međusobno povezanih radova, što ne odražava dobro procese obrade informacija.

Riža. 2.13. Dekompozicija rada “Obrada zahtjeva klijenta”

Riža. 2.14. Dekompozicija posla "Usluga klijenta sustava" (opcija 2)

Riža. 2.15. Dijagram konteksta sustava (opcija 2)

Prijeđimo na dekompoziciju posljednjeg bloka “Promjena baze podataka”. Sa stajališta klijenta, podaci sustava nalaze se u jednoj bazi podataka. U stvarnosti postoji šest baza podataka u sustavu:

korisnička baza podataka,

baza podataka studenata, (opcija 2)

baza slobodnih radnih mjesta,

baza podataka o akademskom uspjehu,

Test baza podataka,

DB stručnih procjena,

DB životopis.

S obzirom na svrhu modeliranja, klijentu je važno razumjeti da se primljeni podaci ne ažuriraju odmah u sustavu, već prolaze kroz dodatnu fazu obrade i kontrole. Algoritam promjene može se formulirati na sljedeći način:

Određuje se baza podataka u kojoj će se podaci mijenjati.

Operater generira privremeni skup podataka i dostavlja ga administratoru.

Administrator kontrolira podatke i unosi ih u bazu.

Ovaj se model može implementirati na drugi način, pružanjem mogućnosti ažuriranja baze podataka izravno na zahtjev, zaobilazeći proces kontrole podataka. U tom slučaju potrebno je osigurati kontrolu integriteta baze podataka kako bi se izbjeglo njeno oštećenje. U ovom slučaju, dijagram će izgledati ovako (Sl. 2.17).

Riža. 2.16. Dekompozicija rada “Promjena baze podataka”

Riža. 2.17. Dekompozicija rada “Promjena baze podataka” (opcija 2) Za prvu opciju, prikazanu na sl. 2.12

Provođenje daljnje dekompozicije “Promjena baze podataka” zakomplicirat će model, objašnjavajući kako se provodi fizička promjena baze podataka u sustavu. U tom slučaju korisnik neće dobiti nikakve dodatne informacije o radu sustava zavoda za zapošljavanje. Preporučljivo je dekomponirati ovaj rad tijekom procesa projektiranja sustava baze podataka u fazi stvaranja logičkog modela baze podataka.

Dekompozicija rada na Izvođenju upita bit će provedena u sljedećem laboratoriju, ilustrirajući korištenje DFD dijagrama za opisivanje procesa obrade informacija.

Provedimo kvantitativnu analizu modela prikazanih na sl. 2.12 i 2.13, prema gore opisanoj metodi. Razmotrimo ponašanje koeficijenta ^ za ove modele. Roditeljski dijagram “Obrada zahtjeva klijenta” ima koeficijent 4/2 = 2, a dekompozicijski dijagram 3/3 = 1. Vrijednost koeficijenta opada, što ukazuje na pojednostavljenje opisa funkcija kako razina model smanjuje.

Razmotrimo promjenu koeficijenta DO b imaju dvije opcije modela.

za drugu opciju

Koeficijent DO b ne mijenja svoju vrijednost, stoga se ravnoteža dijagrama ne mijenja.

Pretpostavit ćemo da je razina dekompozicije razmatranih dijagrama dovoljna da odražava svrhu modeliranja, au dijagramima niže razine elementarne funkcije se koriste kao nazivi rada (sa stajališta korisnika sustava) .

Rezimirajući razmatrani primjer, potrebno je napomenuti važnost razmatranja nekoliko opcija dijagrama pri modeliranju sustava. Takve opcije mogu se pojaviti prilikom prilagođavanja dijagrama, kao što je učinjeno s “Obradom zahtjeva klijenta” ili prilikom stvaranja alternativnih implementacija funkcija sustava (dekompozicija rada “Promjena baze podataka”). Pregled opcija omogućuje vam da odaberete najbolju i uključite je u paket dijagrama za daljnje razmatranje.

Objavljeno na http://www.allbest.ru/

Relevantnost zadatka automatizacije računovodstva računalne i druge opreme u poduzeću povećava se s prisutnošću velike flote računala, uredske opreme, komercijalne i druge opreme. Najveću potrebu da znaju gdje se i koja jedinica nalazi, da promptno prate promjene vezane uz opremu, nameću IT odjeli. 2

Zadatak automatizacije računovodstva opreme od posebne je važnosti u velikim poduzećima. Obrada stalno rastućih količina informacija postala je moguća tek korištenjem suvremenih računalnih tehnologija. 2

Sada je nemoguće organizirati sustav za snimanje opreme u poduzeću, vođenje evidencije računala i komponenti, bez dodatnog softvera instaliranog na računalu. 2

Glavni cilj predmetni rad je razvoj informacijski sistem za računovodstvo računalne opreme poduzeća, korištenjem metodologije funkcionalnog modeliranja i grafičke notacije IDEF0, DFD dijagrama toka podataka i IDEF3 standarda procesne dokumentacije, korištenjem softverskog proizvoda Computer Associates AllFusion Process Modeler r7.3. 2

2.1 Analiza softverski proizvodi 8

UVOD

Sada je nemoguće organizirati sustav za snimanje opreme u poduzeću, vođenje evidencije računala i komponenti, bez dodatnog softvera instaliranog na računalu.

Glavni cilj kolegija je razviti informacijski sustav za računovodstvo računalne opreme poduzeća, korištenjem metodologije funkcionalnog modeliranja i grafičke notacije IDEF0, DFD dijagrama toka podataka i standarda procesne dokumentacije IDEF3, korištenjem Computer Associates AllFusion Process Modeler r7. 3 softverski proizvod.

Za postizanje ovog cilja potrebno je riješiti sljedeće zadatke:

Analiza softverskih proizvoda;

Studij metoda projektiranja informacijskih sustava;

Funkcionalno modeliranje kontekstnog dijagrama i dijagrama dekompozicije poslovnih procesa (IDEF0) “Računovodstvo računalne opreme poduzeća”;

Projektiranje informacijskog sustava pomoću dijagrama toka podataka (DFD);

Korištenje metodologije modeliranja i standarda procesne dokumentacije IDEF3.

informacijski softver za dokumentaciju klinike

1. METODE PROJEKTIRANJA INFORMACIJSKIH SUSTAVA

U suvremenoj praksi modeliranja upravljačkih i proizvodnih aktivnosti, uobičajeno je koristiti izraz "poslovni proces" za označavanje objekata modeliranja. Prilikom modeliranja poslovnih procesa potrebno je obratiti pozornost na niz čimbenika:

Ispravno postavljanje ciljeva;

Odgovarajuća svijest osoblja organizacije o ciljevima i rezultatima projekta;

Učinkovito korištenje alata za modeliranje;

Dostupnost korporativnih standarda za opisivanje i reguliranje poslovnih procesa.

Za modeliranje poslovnih procesa koristi se nekoliko različitih metoda. Temelje se i na strukturnom i na objektno orijentiranom pristupu modeliranju. Najrazvijenije metode koriste elemente obaju pristupa. Najčešće metode uključuju:

metoda funkcionalnog modeliranja SADT (IDEF0);

metoda modeliranja procesa IDEF3;

DFD modeliranje protoka podataka;

Sa stajališta poslovnog modeliranja, svaki od predstavljenih pristupa ima svoje prednosti. Objektni pristup omogućuje vam izgradnju sustava koji je otporniji na promjene i bolje odgovara

postojeće strukture organizacije. Funkcionalno modeliranje dobro funkcionira u slučajevima kada je organizacijska struktura u procesu promjena ili je općenito loše oblikovana. Pristup iz funkcija koje obavljaju izvođači intuitivno bolje razumiju kada od njih primaju informacije o svom trenutnom radu.

Metoda funkcionalnog modeliranja IDEF0 (Function Modeling) – skup pravila i postupaka dizajniranih za izgradnju funkcionalni model objekt bilo kojeg predmetnog područja. Funkcionalni model objekta prikazuje radnje koje on izvodi i veze među njima.

U skladu s ovom metodom, poslovni model bi trebao izgledati ovako:

Najviša razina modela treba odražavati samo kontekst sustava, odnosno njegovu interakciju s vanjskim svijetom.

Druga razina modela treba sadržavati sve glavne aktivnosti poduzeća, odnosno tematski grupirane poslovne procese poduzeća i njihove međusobne odnose.

Daljnja detaljizacija poslovnih procesa provodi se kroz poslovne funkcije, odnosno skupove operacija grupiranih prema određenim obilježjima.

Opis elementarnih poslovnih operacija provodi se određivanjem algoritma za njihovo izvođenje.

Metoda modeliranja protoka podataka DFD (Data Flow Diagrams) - dijagrami protoka podataka. Glavni alat za modeliranje funkcionalnih zahtjeva za projektirani sustav.

Sastavnice modela: dijagrami; rječnik podataka; specifikacije procesa.

Elementi dijagrama: protok podataka; skladištenje; vanjski entitet.

Protok podataka je mehanizam koji se koristi za modeliranje i prijenos informacija iz jednog dijela sustava u drugi.

Vanjski entitet je objekt\subjekt izvan konteksta sustava, koji je.

Pohrana je isječak protoka podataka tijekom vremena koji sadrži podatke koje je potrebno pohraniti između procesa.

Glavne prednosti:

sposobnost jedinstvene identifikacije vanjskih entiteta analizom tokova informacija unutar i izvan sustava;

mogućnost projektiranja od vrha prema dolje, što olakšava konstrukciju modela "kako bi trebalo biti";

prisutnost specifikacija procesa niže razine, što vam omogućuje prevladavanje logičke nepotpunosti funkcionalnog modela i izgradnju potpune funkcionalne specifikacije sustava koji se razvija;

modeli imaju vrlo bogat skup elemenata koji adekvatno odražavaju njihovu specifičnost;

Algoritmi za automatsko pretvaranje DFD hijerarhije u strukturne mape postoje i podržani su brojnim CASE alatima, demonstrirajući veze između sustava, unutar sustava i hijerarhiju sustava

Mane:

potreba za umjetnim unosom upravljačkih procesa, budući da se upravljačke radnje (tijekovi) i upravljački procesi s gledišta DFD-a ne razlikuju od uobičajenih;

nedostatak pojma vremena, tj. nedostatak analize vremenskih intervala pri pretvorbi podataka (sva vremenska ograničenja moraju biti upisana u specifikaciji procesa).

Metoda modeliranja procesa IDEF3 (Integrated DEFinition for Process Description Capture Method) je metodologija modeliranja i standard za dokumentiranje procesa koji se odvijaju u sustavu. Metoda dokumentiranja procesa osigurava mehanizam za dokumentiranje i prikupljanje informacija o procesima. IDEF3 prikazuje uzročno-posljedične odnose između situacija i događaja u stručno čitljivom obliku, koristeći strukturiranu metodu izražavanja znanja o tome kako funkcionira sustav, proces ili poduzeće.

IDEF3 tehnika opisa skupa podataka dio je strukturalna analiza. Za razliku od nekih metodologija opisa procesa, IDEF3 ne ograničava analitičara na pretjerano krutu sintaksu, što može dovesti do nepotpunih ili nedosljednih modela.

IDEF3 se također može koristiti kao metoda stvaranja procesa. IDEF3 nadopunjuje IDEFO i sadrži sve što je potrebno za izgradnju modela koji se kasnije mogu koristiti za analizu simulacija.

2. Dizajn informacijskog sustava “računovodstvo računalne opreme poduzeća”

2.1 Analiza softverskih proizvoda

Analiza takvih informacijskih sustava provodi se kako bi se identificirale prednosti i nedostaci sustava, kao i usporedila funkcionalnost, sučelje, dizajn i jednostavnost korištenja. Pronađeni su sljedeći postojeći informacijski sustavi:

Softver IT Invent (it-invent.ru)

Softver Hardware Inspector (hwinspector.com)

Konfiguracija 1C: Računovodstvo za računala i opremu 8.1 (odineskin.ru)

Prvi IS, IT Invent, nije samo računovodstvo računala, pisača, programa i komponenti. Ovo također uključuje računovodstvo za popravke i održavanje, rad na podršci opremi, narudžbe dobavljačima, primitke i kretanje opreme, računovodstvo za izvođače, zaposlenike i još mnogo toga. Osnovni oblik programa IT Invent prikazan je na slici 1.

Slika 1 "IT Invent"

IT Invent je fleksibilan i prilagodljiv sustav koji ima intuitivno sučelje, koje korisnik dobro percipira u smislu dizajna. Program je prilično multifunkcionalan. Želio bih napomenuti sljedeće ključne značajke programa:

MS Access i MS SQL Server podrška za baze podataka.

Višekorisnički način rada - sve poslovnice rade s jednom bazom podataka.

Sposobnost stvaranja i konfiguriranja vlastitih dodatnih svojstava različitih vrsta.

Računovodstvo obavljanja poslova bilo koje vrste unutar organizacije.

Jedinstveni sustav za izradu i ispis inventarnih naljepnica. Podrška za pisače crtičnog koda.

Podrška za rad sa skenerom crtičnog koda. Pretraživanje zapisa u bazi podataka pomoću crtičnog koda.

Održavanje povijesti promjena opreme.

Računovodstvo za popravke i preventivno održavanje opreme i računala.

Logičko povezivanje programa i komponenti s opremom.

Knjigovodstvo potrošnog materijala, rezervnih dijelova i uredskog materijala.

Dodjeljivanje računovodstvenih jedinica zaposlenicima organizacije. Akti o prijemu i primopredaji.

Održavanje baze podataka dobavljača, uslužnih organizacija i ostalih izvođača.

Fleksibilno razlikovanje prava pristupa za korisnike sustava.

Postavljanje e-mail upozorenja za događaje u programu.

Velik broj ugrađenih tiskanih obrazaca i izvješća s mogućnošću uređivanja istih.

Uvezite i pregledajte podatke izravno iz Active Directoryja.

Program IT Invent je mrežni. Za rad preko mreže s jednom bazom podataka potrebno je da svaki korisnik programa u datoteku "DBPath.ini" upiše put za povezivanje s datotekom baze podataka ili odredi taj put odabirom stavke izbornika "Datoteka" - > "Odabir baze podataka". Istodobno, ne zaboravite postaviti prava čitanja i pisanja u imenik s bazom podataka za sve korisnike programa.

Drugi IS je program Hardware Inspector. Program je namijenjen za automatizirano računovodstvo i popis računalne opreme i druge opreme u organizacijama. Jedinstvenost programa Hardware Inspector leži u mogućnosti praćenja ne samo trenutnog stanja parametara računala, već i cjelokupne životne povijesti pojedinih komponenti. Slika 2 prikazuje vizualni prikaz uređaja u stablu radnog prostora.

Slika 2 "Inspektor hardvera"

Sučelje je jednostavno i intuitivno. Što se tiče dizajna, prihvatljiv je. Program je multifunkcionalan. Želio bih istaknuti sljedeće ključne značajke:

Detaljno računovodstvo računala i softvera;

Životni ciklus knjigovodstvenih objekata;

Uvoz uređaja, softvera, radnih stanica i mrežnih postavki;

Automatizirana revizija radnih mjesta;

Mrežno križanje;

Računovodstvo i planiranje potrošnog materijala;

Računovodstvo za zahtjeve korisnika;

Popis knjigovodstvenih predmeta;

Fleksibilna kontrola pristupa;

Traženje informacija;

Više od 30 ugrađenih prilagođenih izvješća;

Detaljne referentne knjige o svim aspektima računovodstva;

Program Hardware Inspector, plaćen. Jedna licenca daje pravo instaliranja programa na bilo koji broj računala, unutar jedne lokalne mreže, jedne organizacije.

Treći IS je konfiguracija 1C: Računovodstvo za računala i opremu 8.1. Inventar opreme baziran je prvenstveno na barkodiranju, što olakšava bilo kakvu pretragu, odabir ili rad s opremom. Koristeći ovu konfiguraciju, pogodno je uzeti u obzir i izvršiti popise računala, uredske opreme i bilo koje druge materijalne imovine (oprema, telefoni, namještaj), kao i automatizirati druga područja djelovanja.

Slika 3 prikazuje osnovni oblik 1C konfiguracije.

Slika 3 "1C: Računovodstvo za računala i opremu 8.1"

Glavne karakteristike proizvoda:

Računovodstvo za svu opremu, namještaj, softver,

vođenje računa o serijskim i inventarnim brojevima opreme,

Uvoz iz sustava za reviziju hardvera Everest (automatsko prikupljanje podataka)

Najprikladnije korisničko sučelje

Računovodstvo prijava dobavljačima

Kriterij		"Inspektor hardvera"	Konfiguracija 1C
Funkcionalnost	Višenamjenski	Višenamjenski	Višenamjenski
Sučelje	Intuitivno	Jednostavno – intuitivno	Maksimalno povoljno
		Prihvatljiv	Standard
Prilagođenost korisniku		Jednostavan za korištenje	Individualne unaprijed postavljene postavke
Prednosti	Radi preko mreže	Radi preko lokalne mreže Ažurira se 2 puta mjesečno Jedna licenca se može instalirati na bilo koji broj računala, unutar jedne lokalne mreže, jedne organizacije	Valjano besplatna linija konzultacije o e-pošta i ICQ, a po potrebi i konzultacije telefonom.
Mane	Plaćeni program	Plaćeni program	Plaćeni program

Računovodstvo za zahtjeve korisnika i rad s njima

Računovodstvo potrošnog materijala

Automatsko pretraživanje prilikom skeniranja

Individualni skupovi postavki itd.

Usporedimo odabrane informacijske sustave u Tablici 1 prema sljedećim kriterijima: Funkcionalnost, Sučelje, Dizajn, Prilagođenost korisniku, Prednosti i nedostaci;

Tablica 1 - Usporedba informacijskih sustava

Zaključak: Svi razmatrani informacijski sustavi sadrže sve potrebne funkcije za računovodstvo računalne opreme poduzeća. Svi su višenamjenski, praktični i jednostavni za korištenje, s intuitivnim sučeljem. Jedina zajednička mana svih programa je to što se svi plaćaju.

2.2 Opis dijagrama poslovnog procesa „Računovodstvo računalne opreme poduzeća”

2.2.1 Opis IDEF0 dijagrama

Za izradu poslovnog procesa korišten je IDEF0 dijagram. Metodologija IDEF0 propisuje izgradnju hijerarhijskog sustava dijagrama - pojedinačnih opisa fragmenata sustava. Prvo se provodi opis sustava kao cjeline i njegove interakcije s vanjskim svijetom (kontekstni dijagram). Konstruirane su tri razine dijagrama:

Kontekstualno

Funkcionalna dekompozicija

Razlaganje svakog djela

Slika 1 - Kontekstni dijagram "Računovodstvo za računalnu opremu poduzeća"

Slika 1 prikazuje kontekstni dijagram poslovnog procesa "Računovodstvo za računalnu opremu poduzeća." Odražava sustav kao cjelinu i njegovu interakciju s glavnim vanjskim informacijskim tokovima.

Kontekstni dijagram označen je strelicama.

Vrste strelica:

Ulazni podaci za obradu:

Računala – PC (osobna računala) koja se nalaze u poduzeću

Komponente – materijali potrebni za nadogradnju računala (video kartice, matične ploče, procesori, kućišta, napajanja, memorijski moduli)

Izlazni tokovi:

Izvješće – gotovo izvješće o računovodstvu računalne opreme poduzeća

Kontrole unosa:

Pravila su uvjeti koji moraju biti ispunjeni kako bi se postigao cilj.

Nalozi - zadatak dodijeljen poduzeću (provođenje računovodstva računalne opreme u poduzeću pomoću određenih informacijskih sustava)

Menadžeri su direktori i glavni menadžeri poduzeća.

Ulazni resursi:

Računala su računala koja se koriste za vođenje evidencije.

Zaposlenici su stručnjaci koji izvršavaju upute zadane od strane uprave. Nakon konstruiranja konceptualnog modela provedena je funkcionalna dekompozicija - sustav je podijeljen na podsustave te je svaki podsustav zasebno opisan (dekompozicijski dijagrami).

Slika 2 prikazuje funkcionalnu dekompoziciju koja se sastoji od četiri posla.

Slika 2 - Funkcionalna dekompozicija "Računovodstvo računalne opreme poduzeća"

Identificirane su sljedeće vrste rada:

Evidentiranje isporuka je proces u kojem se proizvodu dodjeljuje ID, šalje na čuvanje, u skladište, te se podaci o proizvodu unose u program.

Posao Evidentiranja isporuka uključuje sedam graničnih strelica (ulaz, kontrola, mehanizam) i unutarnju strelicu (ulazni priključak) izlaza.

Spoj strelica na ulazu između radova Evidentiranje isporuka i Računalno održavanje (računalo);

Strelice za ulaz, izlaz, kontrolu ponavljaju se u narednim radovima.

Održavanje računala je proces sastavljanja, popravka i nadogradnje računala.

Rad na održavanju računala uključuje četiri granične strelice (ulaz, kontrola, mehanizam, izlaz) i nekoliko unutarnjih strelica (ulazna komunikacija, ulazna povratna informacija).

Upravljanje strelicama - pravila, naredbe, vođa;

Streličasta veza unosom između radova Održavanje računala i sređivanje (unos podataka u bazu), između radova Održavanje računala i Izrada izvješća (unos podataka u bazu);

Aranžiranje je proces u kojem se računala raspoređuju po uredima (uredima).

Upravljanje strelicama - pravila, naredbe, vođa;

Strelica mehanizma – zaposlenici;

Spoj strelice na ulazu između Dogovora i Izvještaja (dodjeljivanje id-a);

Izrada izvješća je završna faza računovodstvenog procesa koja se sastoji od sumiranja konačnih pokazatelja dobivenih izvođenjem prethodnih tekućih računovodstvenih podataka.

Svaki se podsustav zatim rastavlja na manje dekompozicije, i tako dalje, dok se ne postigne željena razina detalja.

Slika 3 prikazuje dijagram koji detaljnije prikazuje rad Delivery Clearance.

Kao rezultat detaljiranja, identificirane su glavne funkcije. Odjeljak "Registracija isporuke" uključuje sedam glavnih strelica (ulaz, izlaz, kontrola, mehanizam).

Strelica za unos – računala i komponente;

Strelice kontrole su pravila, naredbe i vođa. Razgranate strelice;

Strelice mehanizma, grananje – PC, zaposlenici;

Strelice za ulaz, komande, mehanizmi ponavljaju se u svim radovima.

Dodjeljivanje broja – dodjeljivanje individualnog broja računalu i komponentama.

Strelice za unos – računala i komponente. Računalna strelica se ponavlja u narednim radovima, osim za pripremu izvješća;

Kontrolne strelice – pravila, naredbe i vođa;

Strelice mehanizma – PC i zaposlenici;

Streličasta veza unosom između radova Dodjela broja i Otprema robe na skladište (kretanje), između “Dodjela broja” i “Stavljenje na stanje” (unos u bazu);

Slanje robe u skladište – slanje robe s dodijeljenim brojem u skladište.

Strelica za izlaz – računalo;

Kontrolne strelice - pravila, naredbe i vođa.

Spoj strelica na ulazu između poslova „Otprema robe na skladište“ i „Stavljanje na stanje“ (količina);

Balansiranje – unos informacija u računalo.

Kontrolne strelice – pravila, naredbe i vođa;

Strelice mehanizma – PC i zaposlenici;

Slika 4 je dijagram koji detaljnije opisuje održavanje računala.

Kao rezultat detaljizacije identificirane su glavne funkcije koje se obavljaju tijekom procesa održavanja računala.

Rad na održavanju računala uključuje 4 granične strelice (ulaz, izlaz, kontrola, mehanizam). Interne strelice (ulazna povratna informacija, ulazna komunikacija).

Montaža računala – konfiguracija računala prema individualnim narudžbama voditelja.

Strelica za ulaz – računala;

Kontrolne strelice – pravila, naredbe i vođa;

Strelice mehanizma – Zaposlenici;

Spoj strelica na ulazu između radova: “Sastavljanje računala” i “Popravak računala” (računalo);

Popravak računala – sklapanje računala odobrenih za poboljšanje.

Strelica za ulaz – računala;

Strelica za izlaz – ulazak u bazu podataka;

Kontrolne strelice – pravila, naredbe i vođa;

Strelice mehanizma – Zaposlenici;

Strelice za ulaz, izlaz, kontrolu i mehanizam se granaju;

Spoj strelice na ulazu između radova: “Popravak računala” i “Nadogradnja” (komponente);

Nadogradnja - poboljšanje, poboljšanje, ažuriranje računala.

Strelica za izlaz – ulazak u bazu podataka;

Kontrolne strelice – pravila, naredbe i vođa;

Strelice mehanizma – Zaposlenici;

Kontrolne strelice i mehanizam se granaju;

Slika 5 prikazuje dijagram "Pisanje izvješća" s više detalja. Dekompozicija izrade izvješća o radu uključuje 4 granične strelice (ulaz, izlaz, upravljanje, mehanizmi). Interne strelice (ulazna povratna informacija, ulazna komunikacija).

Kao rezultat rada izvedene su sljedeće funkcije:

Prikupljanje podataka – prikupljanje informacija za analizu i donošenje odluka.

Strelica za unos – dodjela ID-a;

Kontrolne strelice – pravila, naredbe i vođa;

Strelice za ulaz, kontrolu i mehanizam se granaju;

Streličasta veza unosom između radova: Prikupljanje podataka i Provjera podataka (evidencija);

Provjera podataka – provjera podataka i slanje na izvješćivanje.

Strelica za prijavu – dodjela ID-a, unos podataka u bazu podataka;

Strelica za izlaz – izvješće;

Kontrolne strelice – pravila, naredbe i vođa;

Strelice mehanizma – Zaposlenici, PC;

Strelice za ulaz (dodjeljivanje ID-a), kontrolu i mehanizam se granaju;

Strelica za povratne informacije za ulazak iz "Provjera podataka" u "Prikupljanje podataka" (ponovna provjera).

Naučite vidjeti i razumjeti funkcionalna struktura tvoj posao!

Trenutno je u Rusiji došlo do naglog porasta interesa za standarde upravljanja koji su općenito prihvaćeni na Zapadu, međutim, u prava praksa upravljanja postoji jedan vrlo značajan moment. Mnoge menadžere još uvijek može zbuniti izravno pitanje o organizacijska struktura tvrtki ili o shemi postojećih poslovnih procesa. Najnapredniji menadžeri koji redovito čitaju ekonomsku periodiku, u pravilu počinju crtati samo njima razumljive hijerarhijske dijagrame, ali u tom procesu obično brzo dođu u slijepu ulicu. Isto vrijedi i za zaposlenike i voditelje raznih službi i funkcionalnih odjela. U većini slučajeva, jedini skup navedenih pravila prema kojima poduzeće mora poslovati je skup pojedinačnih propisa i opis posla. Najčešće su ti dokumenti sastavljeni prije više od godinu dana, loše su strukturirani i nepovezani jedni s drugima te kao rezultat jednostavno skupljaju prašinu na policama. Za sada je takav pristup bio opravdan, budući da je tijekom formiranja ruske Ekonomija tržišta koncept konkurencije je praktički izostao, a nije bilo posebne potrebe za izračunavanjem troškova - zarada je bila gigantska. Kao rezultat toga, u protekle dvije godine vidjeli smo potpuno razumljivu sliku: velike tvrtke, koji su rasli početkom 90-ih, postupno gube svoje pozicije, sve do potpunog napuštanja tržišta. To je djelomično zbog činjenice da u poduzeću nisu uvedeni standardi upravljanja, koncept funkcionalnog modela djelovanja i misije je potpuno odsutan. Modeliranjem različitih područja aktivnosti možete prilično učinkovito analizirati uska grla u upravljanju i optimizirati cjelokupnu poslovnu shemu. Ali, kao što znate, u svakom poduzeću samo oni projekti koji izravno donose profit imaju najveći prioritet, tako da pitanje ispitivanja aktivnosti i njihove reorganizacije obično dolazi samo tijekom značajne krize u upravljanju tvrtkom.

Krajem 1990-ih, kada je tržište postalo konkurentnije, a profitabilnost poduzeća počela naglo padati, menadžeri su iskusili ogromne poteškoće u pokušaju optimizacije troškova kako bi proizvodi ostali i profitabilni i konkurentni. Upravo u tom trenutku postala je potpuno jasna potreba da pred očima imate model aktivnosti poduzeća koji bi odražavao sve mehanizme i principe međusobnog povezivanja različitih podsustava unutar jednog poslovanja.

Sam koncept "modeliranja poslovnih procesa" ušao je u svakodnevni život većine analitičara istodobno s pojavom na tržištu složenih softverskih proizvoda namijenjenih složenoj automatizaciji upravljanja poduzećem. Takvi sustavi uvijek podrazumijevaju dubinsko predprojektno ispitivanje aktivnosti tvrtke. Rezultat ovog ispitivanja je stručno mišljenje, u kojem se po pojedinim točkama daju preporuke za otklanjanje „uskih grla“ u upravljanju aktivnostima. Na temelju ovog zaključka, neposredno prije projekta implementacije sustava automatizacije, provodi se tzv. reorganizacija poslovnih procesa, ponekad prilično ozbiljna i bolna za tvrtku. To je prirodno; uvijek je teško natjerati tim koji je godinama formiran da "razmišlja na novi način". Takva opsežna istraživanja poduzeća uvijek su složena i značajno se razlikuju od slučaja do slučaja. Za rješavanje takvih problema modeliranja složenih sustava postoje dobro provjerene metodologije i standardi. Ovi standardi uključuju IDEF obitelj metodologija. Uz njihovu pomoć možete učinkovito prikazati i analizirati obrasce aktivnosti širokog spektra složenih sustava u različitim kontekstima. Istodobno, širinu i dubinu ispitivanja procesa u sustavu određuje sam programer, što omogućuje da se kreirani model ne preoptereti nepotrebnim podacima. IDEF obitelj trenutno uključuje sljedeće standarde:

IDEF0 - metodologija funkcionalnog modeliranja. Koristeći vizualni grafički jezik IDEF0, sustav koji se proučava pojavljuje se programerima i analitičarima u obliku skupa međusobno povezanih funkcija (funkcionalnih blokova - u terminima IDEF0). U pravilu, IDEF0 modeliranje je prvi korak u proučavanju bilo kojeg sustava;

IDEF1 je metodologija za modeliranje tokova informacija unutar sustava, koja vam omogućuje prikaz i analizu njihove strukture i odnosa;

IDEF1X (IDEF1 Extended) – metodologija za izgradnju relacijskih struktura. IDEF1X pripada tipu metodologije Entity-Relationship (ER) i obično se koristi za modeliranje relacijskih baza podataka relevantnih za predmetni sustav;

IDEF2 je metodologija za dinamičko modeliranje razvoja sustava. Zbog vrlo ozbiljnih poteškoća analize dinamički sustavi ovaj je standard praktički napušten, a njegov razvoj zaustavljen na samom početno stanje. Međutim, trenutno postoje algoritmi i njihove računalne implementacije koje omogućuju transformaciju skupa statičkih IDEF0 dijagrama u dinamičke modele izgrađene na temelju “obojenih Petrijevih mreža” (CPN - Color Petri Nets);

IDEF3 je metodologija za dokumentiranje procesa koji se odvijaju u sustavu, a koristi se, primjerice, u proučavanju tehnoloških procesa u poduzećima. IDEF3 opisuje scenarij i redoslijed operacija za svaki proces. IDEF3 ima izravan odnos s IDEF0 metodologijom - svaka funkcija (funkcionalni blok) može se prikazati kao zaseban proces pomoću IDEF3;

IDEF4 je metodologija za izgradnju objektno orijentiranih sustava. Alati IDEF4 omogućuju vam vizualni prikaz strukture objekata i osnovnih principa njihove interakcije, čime vam omogućuju analizu i optimizaciju složenih objektno orijentiranih sustava;

IDEF5 je metodologija za ontološka istraživanja složenih sustava. Metodologijom IDEF5 ontologiju sustava moguće je opisati posebnim rječnikom pojmova i pravila na temelju kojih se mogu formirati pouzdani iskazi o stanju promatranog sustava u određenom trenutku. Na temelju ovih izjava donose se zaključci o daljnji razvoj sustava i provodi se njegova optimizacija.
U ovom ćemo članku pogledati najčešće korištenu metodologiju funkcionalnog modeliranja, IDEF0.

Povijest IDEF0 standarda

IDEF0 metodologiju možemo smatrati sljedećom fazom u razvoju dobro poznatog grafičkog jezika za opisivanje funkcionalnih sustava SADT (Structured Analysis and Design Teqnique). Prije nekoliko godina u Rusiji je u malom izdanju objavljena istoimena knjiga posvećena opisu osnovnih principa konstruiranja SADT dijagrama. Povijesno gledano, IDEF0 kao standard razvijen je 1981. godine kao dio opsežnog programa automatizacije industrijska poduzeća, koji je nosio oznaku ICAM (Integrated Computer Aided Manufacturing) a predložio ga je ods. Zračne snage SAD. Zapravo, obitelj IDEF standarda naslijedila je svoju oznaku iz naziva ovog programa (IDEF=ICAM DEFinition). U nastajanju praktična provedba, sudionici ICAM programa suočili su se s potrebom razvoja novih metoda za analizu interakcijskih procesa u industrijskim sustavima. Štoviše, uz poboljšani skup funkcija za opisivanje poslovnih procesa, jedan od zahtjeva za novi standard bila je prisutnost učinkovite metodologije za interakciju unutar okvira "analitičar-specijalist". Drugim riječima, nova metoda trebao osigurati grupni rad na izradi modela, uz izravno sudjelovanje svih analitičara i stručnjaka uključenih u projekt.

Kao rezultat traženja odgovarajućih rješenja nastala je IDEF0 metodologija funkcionalnog modeliranja. Od 1981. IDEF0 standard je doživio nekoliko manjih promjena, uglavnom restriktivne prirode, a njegovo posljednje izdanje je u prosincu 1993. izdao američki Nacionalni institut za standarde i tehnologiju (NIST).

Temeljni elementi i koncepti IDEF0

IDEF0 grafički jezik je iznenađujuće jednostavan i harmoničan. Metodologija se temelji na četiri glavna koncepta.

Prvi od njih je koncept funkcionalnog bloka (Activity Box). Funkcionalni blok je grafički prikazan kao pravokutnik (vidi sliku 1) i predstavlja određenu funkciju unutar sustava koji se razmatra. Prema zahtjevima standarda, naziv svakog funkcionalnog bloka mora biti formuliran u verbalnom raspoloženju (na primjer, "proizvesti usluge", a ne "proizvesti usluge").

Svaka od četiri strane funkcionalnog bloka ima svoje specifično značenje (ulogu), i to:

Gornja strana je postavljena na "Kontrola";

Lijeva strana je postavljena na "Ulaz";

Desna strana je postavljena na "Izlaz";

Donja strana ima značenje "Mehanizam".

Svaki funkcionalni blok unutar pojedinog sustava koji se razmatra mora imati svoj jedinstveni identifikacijski broj.

Slika 1. Funkcijski blok.

Drugi stup IDEF0 metodologije je koncept luka sučelja (Arrow). Lukovi sučelja također se često nazivaju tokovi ili strelice. Luk sučelja predstavlja element sustava koji obrađuje funkcijski blok ili na drugi način utječe na funkciju koju predstavlja taj funkcijski blok.

Grafički prikaz luka sučelja je jednosmjerna strelica. Svaki luk sučelja mora imati svoje jedinstveno ime (Arrow Label). Kao što zahtijeva standard, ime mora biti oblik imenice.

Koristeći lukove sučelja, prikazuju se različiti objekti koji, u jednom ili drugom stupnju, određuju procese koji se odvijaju u sustavu. Takvi objekti mogu biti elementi stvarnog svijeta (dijelovi, automobili, zaposlenici itd.) ili tokovi podataka i informacija (dokumenti, podaci, upute itd.).

Ovisno o tome kojoj strani se ovaj luk sučelja približava, naziva se "dolazni", "odlazni" ili "kontrolni". Osim toga, "izvor" (početak) i "ponor" (kraj) svakog funkcionalnog luka mogu biti samo funkcionalni blokovi, dok "izvor" može biti samo izlazna strana bloka, a "ponor" može biti bilo koji od tri preostala.

Treba napomenuti da svaki funkcionalni blok, prema zahtjevima standarda, mora imati najmanje jedan luk upravljačkog sučelja i jedan odlazni. To je razumljivo - svaki se proces mora odvijati prema nekim pravilima (koje prikazuje kontrolni luk) i mora dati neki rezultat (odlazni luk), inače njegovo razmatranje nema smisla.

Prilikom konstruiranja IDEF0 dijagrama, važno je ispravno odvojiti dolazne lukove sučelja od kontrolnih lukova, što je često teško. Na primjer, slika 2 prikazuje funkcijski blok "Obradi izratka".

U stvarnom procesu radnik koji obavlja obradu dobiva izradak i tehnološke upute za obradu (ili sigurnosna pravila pri radu sa strojem). Možda se pogrešno čini da su i obradak i dokument s tehnološkim uputama ulazni objekti, ali to nije tako. U stvari, u ovom procesu, obradak se obrađuje prema pravilima koja se odražavaju u tehnološkim uputama, koje bi trebale biti predstavljene lukom upravljačkog sučelja.

Slika 2.

Druga je stvar kada tehnološke upute obrađuje glavni tehnolog i u njih se unose izmjene (slika 3). U ovom slučaju, oni su prikazani već dolaznim lukom sučelja, a kontrolni objekt su, na primjer, novi industrijski standardi, na temelju kojih se te promjene rade.

Slika 3.

Gore navedeni primjeri naglašavaju površno sličnu prirodu dolaznih i kontrolnih lukova sučelja, međutim, za sustave iste klase uvijek postoje određene razlike. Na primjer, kada se razmatraju poduzeća i organizacije, postoji pet glavnih vrsta objekata: tokovi materijala(dijelovi, roba, sirovine i dr.), financijski tokovi (gotovinski i negotovinski, investicijski i dr.), tokovi dokumenata (komercijalni, financijski i organizacijski dokumenti), tokovi informacija (informacije, podaci o namjerama, usmeni nalozi i dr.) .) i resursa (zaposlenici, strojevi, strojevi itd.). Štoviše, u različitim slučajevima, sve vrste objekata mogu se prikazati dolaznim i odlaznim lukovima sučelja, upravljajući samo onima koji se odnose na protok dokumenata i informacija, a samo resursima pomoću mehanizama lukova.

Obavezna prisutnost lukova kontrolnog sučelja jedna je od glavnih razlika između IDEF0 standarda i drugih metodologija klasa DFD (Data Flow Diagram) i WFD (Work Flow Diagram).

Treći temeljni koncept IDEF0 standarda je Dekompozicija. Načelo dekompozicije koristi se kada se složeni proces rastavlja na njegove sastavne funkcije. U ovom slučaju, razinu detalja procesa određuje izravno programer modela.

Dekompozicija vam omogućuje postupno i strukturirano predstavljanje modela sustava u obliku hijerarhijske strukture pojedinačnih dijagrama, što ga čini manje preopterećenim i lakšim za probavu.

Model IDEF0 uvijek počinje pogledom na sustav kao jedinstvenu cjelinu — jednu funkcionalnu jedinicu s lukovima sučelja koji se protežu izvan domene koja se razmatra. Takav dijagram s jednim funkcionalnim blokom naziva se kontekstni dijagram, a označava se identifikatorom “A-0”.

Tekst objašnjenja za dijagram konteksta mora naznačiti svrhu konstruiranja dijagrama u obrascu Kratak opis a stajalište je fiksno.

Definiranje i formaliziranje cilja razvoja IDEF0 modela iznimno je važna točka. Zapravo, cilj definira relevantna područja u sustavu koji se proučava na koja se prvo treba usredotočiti. Na primjer, ako modeliramo aktivnosti poduzeća s ciljem izgradnje informacijskog sustava temeljenog na ovom modelu u budućnosti, tada će se ovaj model značajno razlikovati od onog koji bismo razvili za isto poduzeće, ali s ciljem optimizacije opskrbnih lanaca.

Točka gledišta određuje glavni smjer razvoja modela i potrebnu razinu detalja. Jasna fiksacija gledišta omogućuje vam da rasteretite model odbijanjem detaljiziranja i proučavanja pojedinačnih elemenata koji nisu potrebni, na temelju odabranog gledišta na sustav. Na primjer, funkcionalni modeli istog poduzeća sa stajališta glavnog tehnologa i financijskog direktora značajno će se razlikovati u smjeru njihove detaljizacije. To je zbog činjenice da u konačnici financijskog direktora ne zanimaju aspekti obrade sirovina na proizvodnim strojevima, a glavni tehnolog nema potrebe za nacrtanim dijagramima. financijski tokovi. Pravi izbor gledišta značajno smanjuje vrijeme utrošeno na izgradnju konačnog modela.

Tijekom procesa dekompozicije, funkcionalni blok koji predstavlja sustav kao cjelinu u kontekstualnom dijagramu je detaljno prikazan u drugom dijagramu. Rezultirajući dijagram druge razine sadrži funkcionalne blokove koji prikazuju glavne podfunkcije funkcionalnog bloka kontekstnog dijagrama i u odnosu na njega naziva se dijagram djeteta (svaki od funkcionalnih blokova koji pripada dijagramu djeteta naziva se odgovarajući okvir djeteta). S druge strane, funkcionalni blok pretka naziva se roditeljski blok u odnosu na podređeni dijagram (Parent Box), a dijagram kojemu pripada naziva se roditeljski dijagram (Parent Diagram). Svaka podfunkcija dječjeg dijagrama može se dalje detaljizirati sličnom dekompozicijom odgovarajućeg funkcionalnog bloka. Važno je napomenuti da su u svakom slučaju dekompozicije funkcionalnog bloka, svi lukovi sučelja koji ulaze ili izlaze iz ovog bloka fiksirani na dječjem dijagramu. Time se postiže strukturni integritet IDEF0 modela. Princip dekompozicije jasno je prikazan na slici 4. Treba obratiti pozornost na odnos numeriranja funkcionalnih blokova i dijagrama – svaki blok ima svoj jedinstveni redni broj na dijagramu (broj u donjem desnom kutu pravokutnika) , a oznaka u desnom kutu označava broj dijete dijagrama za ovaj blok. Nepostojanje ove oznake znači da za ovaj blok nema dekompozicije.

Česti su slučajevi kada pojedinačni lukovi sučelja nemaju smisla nastaviti se razmatrati u podređenim dijagramima ispod određene razine u hijerarhiji, ili obrnuto - pojedinačni lukovi nemaju praktičnog smisla iznad određene razine. Na primjer, nema smisla prikazivati luk sučelja koji prikazuje "dio" na ulazu u funkcionalni blok "Proces na tokarskom stroju" na dijagramima viših razina - to će samo preopteretiti dijagrame i učiniti ih teškim za razumijevanje. S druge strane, postoji potreba da se riješimo pojedinačnih "konceptualnih" lukova sučelja i da ih ne detaljiziramo iznad određene razine. Za rješavanje takvih problema, standard IDEF0 nudi koncept tuneliranja. Oznaka Arrow Tunnel dviju zagrada oko početka luka sučelja označava da luk nije naslijeđen od funkcionalnog nadređenog bloka i pojavljuje se (iz "tunela") samo u ovom dijagramu. Zauzvrat, ista oznaka oko kraja (strelica) luka sučelja u neposrednoj blizini prijemnog bloka znači činjenicu da ovaj luk neće biti prikazan i razmatran u podređenom dijagramu ovog bloka. Najčešće se događa da se pojedinačni objekti i njihovi odgovarajući lukovi sučelja ne razmatraju na nekim srednjim razinama hijerarhije - u ovom slučaju, prvo se "urone u tunel", a zatim, ako je potrebno, "vrate iz tunela" .

Posljednji od IDEF0 koncepata je Glosar. Za svaki od IDEF0 elemenata: dijagrame, funkcijske blokove, lukove sučelja, postojeći standard podrazumijeva stvaranje i održavanje skupa odgovarajućih definicija, ključnih riječi, narativnih iskaza itd. koji karakteriziraju objekt prikazan ovim elementom. Taj se skup naziva glosar i predstavlja opis suštine danog elementa. Na primjer, za luk kontrolnog sučelja "nalog za plaćanje", glosar može sadržavati popis polja dokumenta koja odgovaraju luku, potreban skup viza itd. Pojmovnik skladno nadopunjuje vizualni grafički jezik, pružajući dijagramima potrebne dodatne informacije.

Slika 4. Dekompozicija funkcionalnih blokova.

Načela za ograničavanje složenosti IDEF0 dijagrama

Tipično, IDEF0 modeli sadrže složene i koncentrirane informacije, a kako bi se ograničila njihova zagušenost i učinili čitljivima, odgovarajuća ograničenja složenosti usvojena su u odgovarajućem standardu:

Ograničite broj funkcionalnih blokova na dijagramu na tri do šest. Gornja granica (šest) tjera dizajnera da koristi hijerarhije pri opisivanju složenih objekata, a donja granica (tri) osigurava da odgovarajući dijagram ima dovoljno detalja koji opravdavaju njegovu izradu;

Ograničenje broja lukova sučelja prikladnih za jedan funkcionalni blok (koji izlaze iz jednog funkcionalnog bloka) na četiri.
Naravno, uopće nije potrebno strogo se pridržavati ovih ograničenja, ali kako iskustvo pokazuje, vrlo su praktični u stvarnom radu.

Disciplina grupnog rada na razvoju IDEF0 modela

Standard IDEF0 sadrži skup postupaka koji omogućuju da se model razvije i dogovori velika grupa ljudi koji pripadaju različitim područjima aktivnosti sustava koji se modelira. Tipično, proces razvoja je iterativan i sastoji se od sljedećih konvencionalnih faza:

Izrada modela od strane grupe stručnjaka vezanih za različita područja poduzeća. Ova grupa se naziva Autori u terminima IDEF0. Izgradnja inicijalnog modela je dinamičan proces tijekom kojeg autori intervjuiraju kompetentne pojedince o strukturi različitih procesa. Na temelju postojećih propisa, dokumenata i rezultata istraživanja izrađuje se Nacrt modela modela.

Distribucija nacrta na pregled, odobrenje i komentar. U ovoj fazi, nacrt modela se raspravlja sa širokim rasponom kompetentnih osoba (u smislu čitatelja IDEF0) u poduzeću. U tom slučaju, svaki od dijagrama nacrta modela se kritizira i komentira u pisanom obliku, a zatim se prenosi autoru. Autor se sa svoje strane također pisanim putem slaže s kritikom ili je odbija, iznoseći logiku odluke, te vraća dorađeni nacrt na daljnje razmatranje. Ovaj ciklus se nastavlja sve dok autori i čitatelji ne postignu konsenzus.

Službeno odobrenje modela. Odobreni model odobrava upravitelj radna skupina u slučaju da autori modela i čitatelji nemaju neslaganja o njegovoj primjerenosti. Konačni model je koherentan pogled na poduzeće (sustav) sa zadane točke gledišta i za zadanu svrhu.
Jasnoća IDEF0 grafičkog jezika čini model potpuno čitljivim čak i osobama koje nisu sudjelovale u projektu njegove izrade, kao i učinkovitim za prikaze i prezentacije. U budućnosti se na temelju izgrađenog modela mogu organizirati novi projekti usmjereni na promjene u poduzeću (u sustavu).

Značajke nacionalne prakse korištenja funkcionalnog modeliranja pomoću IDEF0

Posljednjih godina u Rusiji stalno raste interes za IDEF obitelj metodologija. To neprestano primjećujem gledajući statistiku posjeta mojoj osobnoj web stranici (http://www.vernikov.ru), koja ukratko opisuje osnovna načela ovih standarda. Pritom bih interes za standarde poput IDEF3-5 nazvao teorijskim, a za IDEF0 sasvim praktično opravdanim. Naime, prvi Case alati koji omogućuju konstrukciju DFD i IDEF0 dijagrama pojavili su se na ruskom tržištu još 1996. godine, istovremeno s izdavanjem popularne knjige o principima modeliranja u SADT standardima.

Međutim, većina menadžera još uvijek smatra praktičnu primjenu modeliranja u IDEF standardima više kao danak modi nego kao učinkovit način optimizacije postojećeg sustava upravljanja poslovanjem. Najvjerojatnije je to zbog izraženog nedostatka informacija o praktična aplikacija te metodologije i s neizostavnom softverskom pristranošću za veliku većinu publikacija.

Nije tajna da su gotovo svi projekti istraživanja i analize financijskih i ekonomskih aktivnosti poduzeća u Rusiji na ovaj ili onaj način povezani s izgradnjom automatiziranih sustava upravljanja. Zahvaljujući tome, standardi IDEF-a, prema shvaćanju većine, postali su uvjetno neodvojivi od implementacije informacijske tehnologije, iako uz njihovu pomoć ponekad možete učinkovito riješiti čak i male lokalne probleme, doslovno uz pomoć olovke i papira.

Prilikom izvođenja složenih projekata istraživanja poduzeća, razvoj modela u standardu IDEF0 omogućuje vam jasan i učinkovit prikaz cjelokupnog mehanizma aktivnosti poduzeća u potrebnom kontekstu. Ipak, najvažnija stvar su mogućnosti suradnje koje IDEF0 pruža. U mom praktičnom radu bilo je dosta slučajeva kada je izrada modela obavljena uz izravnu pomoć zaposlenika različitih odjela. Istovremeno, konzultant im je objasnio osnovne principe IDEF0 i naučio ih kako raditi s pripadajućim aplikacijskim softverom u relativno kratkom vremenu. Kao rezultat toga, zaposlenici različitih odjela izradili su IDEF dijagrame aktivnosti svoje funkcionalne jedinice, koji su trebali odgovoriti na sljedeća pitanja:

Što odjel dobiva kao input?

Koje se funkcije i kojim redoslijedom obavljaju unutar odjela?

Tko je odgovoran za obavljanje svake funkcije?

Čime se nositelj rukovodi pri obavljanju svake od funkcija?

Koji je rezultat rada odjela (output)?

Nakon usuglašavanja nacrta dijagrama unutar svakog pojedinog odjela, konzultant ih sklapa u nacrt modela poduzeća koji povezuje sve ulazne i izlazne elemente. U ovoj fazi se bilježe sva odstupanja u pojedinim dijagramima i njihova sporna područja. Zatim ovaj model ponovno prolazi kroz funkcionalne odjele za daljnju koordinaciju i potrebne prilagodbe. Kao rezultat toga, u relativno kratkom vremenu i uz uključivanje minimuma ljudskih resursa konzultantske tvrtke (a ti su resursi, kao što znamo, vrlo skupi), dobiva se IDEF0-model poduzeća na „kao je” i, što je još važnije, predstavlja poduzeće s pozicijama zaposlenika koji u njemu rade i dobro poznaju sve nijanse, uključujući i one neformalne. U budućnosti će se ovaj model prenijeti na analizu i obradu poslovnim analitičarima, koji će tražiti „uska grla“ u upravljanju tvrtkom i optimizirati glavne procese, transformirajući model „Kakav jest“ u odgovarajući „Kakav treba Budi” reprezentacija. Na temelju ovih izmjena donosi se konačni zaključak koji sadrži preporuke za reorganizaciju sustava upravljanja.

Naravno, takav pristup zahtijeva niz organizacijskih mjera, prvenstveno od strane menadžmenta poduzeća koje se istražuje. To je zbog činjenice da ova tehnika uključuje dodjeljivanje dodatnih odgovornosti nekim zaposlenicima za ovladavanje i praktičnu primjenu novih metodologija. No, to se u konačnici opravdava, budući da dodatni sat ili dva rada pojedinih zaposlenika tijekom nekoliko dana mogu značajno uštedjeti novac na plaćanju konzultantskih usluga trećoj tvrtki (što će u svakom slučaju omesti iste zaposlenike iz rada s upitnicima i pitanjima). Što se tiče samih zaposlenika poduzeća, u svojoj praksi nikada nisam naišao na njihovo izraženo protivljenje.

Iz svega ovoga može se izvući sljedeći zaključak: uopće nije potrebno svaki put sami dolaziti do rješenja standardnih problema. Kad god se suočite s potrebom da analizirate jedno ili drugo funkcionalni sustav(od sustava dizajna svemirskog broda do procesa pripreme složene večere) - koristite provjerene i godinama dokazane metode. Jedna od tih metoda je IDEF0, koja vam omogućuje rješavanje složenih životnih problema pomoću svojih jednostavnih i razumljivih alata.

Slika vrijedi tisuću riječi

Narodna mudrost

Često se u mom radu javlja potreba ne samo za proučavanjem i rješavanjem određenog problema, već za utvrđivanjem njegovog mjesta u cjelokupnom modelu poslovanja tvrtke. Nije dovoljno razumjeti da određena jedinica ne radi ispravno, važno je razumjeti kako je u interakciji s drugima. Inače, nemoguće je identificirati sve postojeće probleme i odabrati optimalna metoda rješavanje problema. A za to morate proučiti rad tvrtke i izraditi njen funkcionalni model.

Naravno, u teoriji, voditelj bi trebao imati funkcionalni model rada tvrtke, pri čemu nije bitno radi li se o organizaciji rada skladišta ili informatičkog sustava od vođenja do aplikacije. Ali u stvarnosti se to gotovo nikad ne pokaže, te stoga u procesu proučavanja i pronalaženja rješenja za problem koji postavlja klijent, stvaram i funkcionalni model rada tvrtke odn. određeni proces(funkcionira) samostalno.

Nekoliko riječi o prednostima grafike

Kao što znate, IDEF0 funkcionalni modeli uvijek su grafički dijagrami. Imaju svoje karakteristike i pravila sastavljanja. O ovome ćemo malo kasnije. Sada bih želio dati nekoliko primjera učinkovitosti grafike. Zašto se fokusiram na ovo? Najvjerojatnije, nakon moje izjave o potrebi za funkcionalnim modelom rada tvrtke, mnogi su ljudi mislili da sve to nije potrebno, mogli bi riječima objasniti kako ova ili ona funkcija funkcionira u tvrtki. O tome želim razgovarati.

Počnimo s kratkim izletom u povijest. Vratimo se u daleku 1877. godinu, u vrijeme Rusko-turskog rata. Tada je tiskar Sytin prvi upotrijebio grafiku za opis vojnih operacija. Sada nam je sve to poznato; kada opisujemo bilo koju bitku, pred očima nam se pojavljuju karte sa strelicama koje jasno pokazuju tijek bitke. A u to su se vrijeme vojne akcije opisivale riječima. Za svaku bitku postoji mnogo, mnogo riječi. I na kraju je bilo vrlo teško shvatiti što se događa.

Stoga je Sytinova ideja bila doista revolucionarna - počeo je tiskati litografske kopije karata na kojima su označene utvrde i položaji vojnih jedinica. Te su se kartice zvale “Za čitatelje novina. Džeparac." Ideja se pokazala toliko relevantnom da je prvo izdanje "Pogodnosti" odmah rasprodano. A tada su takve aplikacije bile u velikoj potražnji. Razlog je očit. Grafika je pomogla razumjeti ono što je bilo gotovo nemoguće razumjeti samo riječima.

Sličan primjer bespomoćnosti verbalnih opisa mogu dati i iz vlastite prakse. Jedan od mojih kupaca stvarno me zamolio da preuzmem implementaciju ERP sustava za njegovu tvrtku. Na moje pitanje imaju li kakve tehničke specifikacije, dobio sam odgovor: “Imaju. Ali to je 400 stranica.” Istodobno, klijent se jako bunio da su moji kolege, koje je ranije kontaktirao, ili potpuno odbili projekt ili su naveli očito prenapuhane cijene. Nakon što sam vidio da tehnička specifikacija zapravo ima 400 stranica i da se sastoji samo od tekstualnog opisa, shvatio sam razloge ponašanja programera. Čitanje takvog volumena teksta, zadubljivanje u njega, razumijevanje svih nijansi samo za razumijevanje zadatka i imenovanje cijene zaista je vrlo teško.

Ponudio sam ovog klijenta Alternativna opcija- opisati sve što je moguće grafički u obliku notnih zapisa. Pokazao mu je primjere modeliranja. Kao rezultat toga, sada preispituju svoje želje i dizajn tehničkih specifikacija.

Znam i mnogo drugih primjera gdje je grafičko modeliranje poslovnih procesa pomoglo kako mojim kolegama, poslovnim konzultantima i programerima, tako i samim gospodarstvenicima.

Zašto je to važno za moj rad?

Moj posao uvijek uključuje izmjene postojećeg sustava. A da biste napravili promjene i dobili željeni rezultat, morate proučiti ono što već postoji. I nije važno što točno radimo - postavljanje ili instaliranje CRM sustava od nule, stvaranje učinkovitog ERP sustava, integracija različitih sustava za povećanje automatizacije rada općenito. U svakom slučaju, prvo morate steći ideju postojeća shema rad, a tek nakon toga možete predložiti neke izmjene i razmisliti o mogućnostima rješenja problema.

Nakon proučavanja trenutnog stanja stvari, ja, kao i svaki drugi stručnjak treće strane, izrađujem komercijalni prijedlog u kojem što je moguće detaljnije otkrivam svoju viziju trenutne situacije, kao i radnje koje je potrebno poduzeti da riješiti problem, i, naravno, očekivani rezultat.

Ovakva izvješća o radu su opsežna i zauzimaju više od jedne stranice, što je s jedne strane potrebno, ali s druge strane otežava percepciju. U početku sam, kao i mnogi drugi, mislio da su obimna izvješća dobra, jer čovjek plaća posao i treba mu dati što detaljnije informacije.

Uobičajene pogreške

Funkcionalno modeliranje izvodi se pomoću raznih alata, uključujući i one koji nisu namijenjeni modeliranju. U potonjem slučaju nema provjere pogrešaka niti standardnih ograničenja. Želja za povećanjem vidljivosti i nedostatak iskustva često rezultiraju pogreškama.

Korištenje različitih boja

Svi elementi u dijagramu su jednako važni. U funkcionalnom modeliranju ne postoji više ili manje važni elementi. Nestanak bilo kojeg dovest će do prekida procesa i grešaka u proizvodnji.

Često prilikom modeliranja na papiru ili u raznim programima, korisnici pokušavaju povećati vidljivost koristeći različite boje. Ovo je jedna od najčešćih grešaka. Zapravo, korištenje raznobojnih strelica i blokova samo dodaje dodatnu zbrku i također iskrivljuje percepciju dijagrama.

Vaš bi model trebao biti čitljiv crno-bijelo, bez dodatnih shema boja. Ovakav pristup istovremeno pomaže u izbjegavanju nesporazuma i disciplinira kreatora modela, što rezultira povećanom čitljivošću i pismenošću modela.

Previše blokova

Prilikom izrade modela često pokušavaju na jednom listu prikazati sve nijanse rada tvrtke sa svim detaljima. Rezultat je vrlo velik broj blokova s velikim brojem kontrolnih strelica. U tom slučaju gubi se čitljivost.

Najbolja opcija je dovoljno detalja za razumijevanje problema, i ništa više. Detaljni detalji o radu svakog odjela ili čak zaposlenika mogu se otkriti odabirom detaljnog prikaza pojedinog procesa. A takva se struktura stvara samo ako je doista nužna za rad ili odlučivanje.

Kršenje strukture prilikom podešavanja

Pazite da ne dođe do zabune ili procesa bez ulaznih, izlaznih ili drugih važnih elemenata. Na primjer, ako u gornjem primjeru smatram da je potrebno prebaciti gledište na copywritera, uklonit ću autora iz sheme. I tada kontrolni elementi „iskustvo autora i izvori trećih strana“, kao i plan objave, postaju nepotrebni. Uostalom, autor ih koristi. Tekstopisac radi sa audio datotekom. A ako ostanu unutra opća shema, tada će prilikom detaljiziranja dovesti do nejasnog smjera i izazvati zabunu.

Isto tako, ako odlučim dodati blok, važno je osigurati da on također ima sve potrebne atribute. Ovdje je vrlo važan oprez, jer kod modeliranja složenih poslovnih procesa promjene u jednom dijelu modela mogu dovesti do promjena u drugom. Svakako ih treba uključiti.

Pravila za imenovanje upravljačkih elemenata i blokova

Važno je zapamtiti jednostavno pravilo: kontrolne strelice nazivaju se imenicama, blokovi se nazivaju glagolima. To je prihvaćeno u standardu IDEF0 i ovaj pristup pomaže u izbjegavanju zabune i pogrešaka.

Najčešće se greške prave kod imenovanja blokova. Na primjer, umjesto "Izradite članak", pišu "Izrada članka". Blokovi u ovom pristupu su radnje i stoga bi uvijek trebali biti glagoli.

Prednosti korištenja IDEF0

Prva prednost je očigledna – vidljivost. Vi sami počinjete shvaćati kako funkcionira ovaj ili onaj sustav, a također možete jasno objasniti gdje su "tanke točke" u ovom sustavu i kako će vaša rješenja pomoći da ih se riješite.
Međusobno razumijevanje i odsustvo nesuglasica. Kada razgovarate o radu tvrtke koristeći funkcionalni model, imate vizualne i intuitivne blokove zadataka s kontrolnim elementima. Osim toga, funkcionalno modeliranje uključuje izradu, ako je potrebno, pojmovnika u kojem se otkrivaju konvencije i termini. Kao rezultat toga, vi i klijent, upravitelj i ostali zaposlenici govorite istim jezikom kada razgovarate o problemu.
Jednostavnost i velika brzina izrade modela. Naravno, naučiti modelirati nije tako lako kao što se čini. Na kraju krajeva, dijagram je u biti super-gusta prezentacija informacija, što je vrlo dobro za razumijevanje, ali za implementaciju takve prezentacije potrebno je poseban pristup. Mozak analitičara u ovom slučaju s jedne strane djeluje kao vrlo moćan tisak, a s druge strane filtar. Ali s iskustvom ovaj proces postaje vrlo brz. Kao rezultat toga dobivate alat koji će vam pomoći da sami shvatite što se događa u pojedinom sustavu, a uz pomoć alata kreiranog u kratkom vremenu vizualna pomoć ilustrirati važne točke kolege ili kupci.
Disciplina i bez greške. Standard IDEF0 pretpostavlja stroge granice i pravila. Ovakav pristup stvara disciplinu, a navika postupanja u okviru standarda pomaže u izbjegavanju pogrešaka zbog nepažnje. Svako kršenje standarda postaje odmah vidljivo.

U čemu je poteškoća korištenja IDEF0

Važno je razumjeti da će samo u najjednostavnijim slučajevima dva poslovna analitičara stvoriti potpuno iste funkcionalne modele za opisivanje rada tvrtke. Bilo koji model je odraz analitičarevog iskustva, dubine razumijevanja posla koji želi opisati, a također, na neki način, i njegovog osobnog stajališta o ovom poslu. Oni. osoba razvija poslovni model sa stajališta menadžera, kao da je on menadžer.

Istodobno, smatram da poslovni analitičar nije baš profesija, poslovnom analitikom se bavi svaki voditelj poslovanja ili programer nekih sustava koji analizira poslovanje i nastoji izgraditi što učinkovitiji sustav. Za te ljude i za te svrhe dizajniran je alat IDEF0.

Stoga je prilikom izrade funkcionalnog poslovnog modela "kakav jest" vrlo važno stalno se konzultirati s čelnikom tvrtke kako se ne bi pogriješile koje će automatski dovesti do grešaka u fazama dekompozicije. Također, u kasnijim fazama mogu biti potrebna dodatna odobrenja od voditelja odjela i zaposlenika. Samo ako vaš funkcionalni model "kakav jest" doista odražava stvarno stanje stvari, možete unijeti bilo kakve izmjene i prijedloge. A za postizanje kvalitetnih rezultata u takvom radu potrebno je prije svega praktično iskustvo i poznavanje karakteristika pojedine vrste poslovanja.

Više članaka na ovu temu.

6.2. Svrha i sastav SADT metodologije (IDEF0)

SADT metodologija (Structured Analysis and Design Technique - metodologija strukturne analize i projektiranja) je skup metoda, pravila i postupaka dizajniranih za izgradnju funkcionalnog modela sustava.

Razvoj ove metodologije započeo je Douglas Ross (SAD) sredinom 60-ih. XX. stoljeća Od tada, analitičari sustava u SofTech, Inc. poboljšao SADT i koristio ga za rješavanje širokog spektra problema. Softver telefonske mreže, dijagnostika, dugoročna i Strateško planiranje, računalno potpomognuta proizvodnja i dizajn, konfiguracija računalnih sustava, obuka osoblja, financijsko i logističko upravljanje neka su od područja učinkovita primjena SADT. Širok raspon područja ukazuje na svestranost i snagu SADT metodologije. Program Integrirane računalno potpomognute proizvodnje (ICAM) američkog Ministarstva obrane prepoznao je korisnost SADT-a. To je dovelo do objave dijela 1981. tzv IDEF0 (Icam DEFinition), kao federalni standard za razvoj softvera. Pod tim imenom SADT su počeli koristiti tisuće stručnjaka u vojnim i industrijskim organizacijama. Najnovije izdanje IDEF0 standard objavljen je u prosincu 1993. Nacionalni institut za standarde i tehnologiju (NIST).

Ova metodologija se natječe s metodama usmjerenim na protok podataka (DFD) kada se opisuje funkcionalni aspekt informacijskog sustava. Nasuprot tome, IDEF0 dopušta:

Opišite sve sustave, ne samo informacijske sustave (DFD je namijenjen opisivanju softvera);

Napravite opis sustava i njegovog vanjskog okruženja prije utvrđivanja konačnih zahtjeva za njega. Drugim riječima, pomoću ove metodologije možete postupno graditi i analizirati sustav čak i kada je još uvijek teško zamisliti njegovu implementaciju.

Stoga se IDEF0 može koristiti u ranim fazama izgradnje širokog spektra sustava. Istodobno se može koristiti za analizu funkcija postojeće sustave i razvoj rješenja za njihovo poboljšanje.

Osnova IDEF0 metodologije je grafički jezik za opisivanje procesa. Model u IDEF0 notaciji je zbirka hijerarhijski uređenih i međusobno povezanih dijagrama. Svaki dijagram je jedinica opisa sustava i nalazi se na posebnom listu.

Model (KAKAV JE, BITI ili TREBALO BITI) može sadržavati 4 vrste grafikona [ , ]:

Kontekstni dijagram;

Dijagrami dekompozicije;

Dijagrami čvornog stabla;

Dijagrami samo za izloženost (FEO).

Kontekstni dijagram (dijagram najviše razine), kao vrh strukture stabla dijagrama, pokazuje svrhu sustava (glavnu funkciju) i njegovu interakciju s vanjskim okruženjem. Svaki model može imati samo jedan kontekstni dijagram. Nakon opisa glavne funkcije provodi se funkcionalna dekompozicija, odnosno određuju se funkcije koje čine glavnu.

Zatim se funkcije dijele na podfunkcije i tako dalje dok se ne postigne potrebna razina detalja sustava koji se proučava. Dijagrami koji opisuju svaki takav fragment sustava nazivaju se dijagrami dekompozicije . Nakon svake sesije dekompozicije provode se ispitne sesije - predmetni stručnjaci ukazuju na podudarnost stvarnih procesa sa stvorenim dijagramima. Pronađene nedosljednosti se otklanjaju, nakon čega počinje daljnje detaljiziranje procesa.

Dijagram stabla čvorova pokazuje hijerarhijsku ovisnost funkcija (radova), ali ne i veze među njima. Može ih biti nekoliko, budući da se stablo može graditi na proizvoljnu dubinu i iz proizvoljnog čvora.

Grafikoni izloženosti konstruirani su za ilustraciju pojedinačnih fragmenata modela kako bi se prikazalo alternativno gledište na procese koji se odvijaju u sustavu (na primjer, sa stajališta menadžmenta organizacije).

6.3. Elementi IDEF0 grafičkog zapisa

Metodologija IDEF0 naišla je na široku prihvaćenost i primjenu, prvenstveno zahvaljujući jednostavnoj grafičkoj notaciji korištenoj za izradu modela. Glavne komponente modela su dijagrami. U obliku pravokutnika prikazuju funkcije sustava, kao i veze između njih i vanjskog okruženja putem strelica. Korištenjem samo dvije grafičke primitive (pravokutnik i strelica) možete brzo objasniti pravila i principe IDEF0 dijagrama ljudima koji nisu upoznati s ovom metodologijom. Ova prednost vam omogućuje povezivanje i aktiviranje aktivnosti korisnika u opisivanju poslovnih procesa koristeći formalni i vizualni grafički jezik.

Sljedeća slika prikazuje glavne elemente IDEF0 grafičke notacije.

Riža. 6.1. Elementi IDEF0 grafičkog zapisa

Pravokutnik predstavlja rad (proces, aktivnost, funkcija ili zadatak) , koji ima fiksni cilj i dovodi do nekog konačnog rezultata. Naziv rada treba izražavati radnju (na primjer, “Proizvodnja dijela”, “Izračun dopuštenih brzina”, “Izrada iskaza radnog centra br. 3”).

Interakcija radova između sebe i vanjskog svijeta opisana je u obliku strelica. IDEF0 razlikuje 5 vrsta strijela :

- ulaz (engl. input) - materijal ili informacija koja se radom koristi i transformira da bi se dobio rezultat (output). Unos odgovara na pitanje "Što se obrađuje?" Ulaz može biti ili materijalni objekt (sirovine, dio, ispitna kartica) ili onaj koji nema jasne fizičke konture (upit bazi podataka, pitanje nastavnika). Dopušteno je da rad nema jednu ulaznu strelicu. Strelice za unos uvijek se crtaju ulazeći u lijevi rub rada;

- kontrolirati (engl. control) – kontrolni, regulatorni i normativni podaci koji usmjeravaju rad. Uprava odgovara na pitanje "U skladu s onim što se posao obavlja?" Menadžment utječe na rad, ali se njime ne transformira, tj. djeluje kao ograničenje. Upravljanje može uključivati pravila, standarde, propise, cijene ili usmene upute. Kontrolne strelice su nacrtane ulazeći u gornji rub rada. Ako se pri izradi dijagrama postavlja pitanje kako pravilno nacrtati strelicu odozgo ili slijeva, tada se preporučuje da je nacrtate kao ulaz (strelica s lijeve strane);

- Izlaz (engl. output) – materijal ili informacija koja predstavlja rezultat rada. Izlaz odgovara na pitanje "Što je rezultat rada?" Izlaz može biti ili materijalni objekt (dio, automobil, dokumenti o plaćanju, izvod) ili nematerijalni objekt (uzorkovanje podataka iz baze podataka, odgovor na pitanje, usmene upute). Strelice za izlaz nacrtane su iz desnog ruba rada;

- mehanizam (engleski mehanizam) – resursi koji obavljaju posao. Mehanizam odgovara na pitanje "Tko radi ili kroz što?" Mehanizam može biti osoblje poduzeća, student, stroj, oprema ili program. Strelice mehanizma su nacrtane ulazeći u donji rub rada;

- poziv (engleski call) - strelica označava da se neki dio posla izvodi izvan predmetnog bloka. Iz donjeg ruba rada nacrtane su strelice za izlaz.

6.4. Vrste veza između poslova

Nakon utvrđivanja sastava funkcija i odnosa među njima, postavlja se pitanje njihove pravilne kompozicije (kombinacije) u module (podsustave). To znači da svaka pojedina funkcija mora riješiti jedan, strogo definiran zadatak. U protivnom je potrebna daljnja dekompozicija ili razdvajanje funkcija.

Kod objedinjavanja funkcija u podsustave potrebno je nastojati da unutarnja povezanost (između funkcija unutar modula) bude što jača, a vanjska povezanost (između funkcija uključenih u različite module) što je moguće slabija. Na temelju semantike veza metodike uvest ćemo klasifikaciju veza između funkcija (djela). Ova klasifikacija je proširenje. Vrste veza date su opadajućim redoslijedom njihove važnosti (snage vezivanja). U navedenim primjerima, debele linije označavaju funkcije između kojih postoji vrsta veze koja se razmatra.

1. Hijerarhijska povezanost (odnos “dio” - “cjelina”) odvija se između funkcije i podfunkcija od kojih se ona sastoji.

Riža. 6.2. Hijerarhijski odnos

2. Regulatorna (kontrolna, podređena) veza odražava ovisnost jedne funkcije o drugoj, kada je izlaz jednog rada usmjeren na kontrolu drugog. Funkciju iz koje dolazi upravljanje treba smatrati regulirajućom ili kontrolnom, a funkciju u koju je uključeno treba smatrati podređenom. razlikovati izravna komunikacija s menadžmentom , kada se kontrola prenosi s višeg posla na niži (sl. 6.3), i povratne informacije menadžmenta kada se kontrola prenosi s nižeg na viši (sl. 6.4).

3. Funkcionalna (tehnološka) veza događa se kada izlaz jedne funkcije služi kao ulaz za sljedeću funkciju. Sa stajališta toka materijalnih objekata ovu vezu prikazuje tehnologiju (redoslijed rada) obrade tih predmeta. razlikovati izravna ulazna veza , kada se izlaz prenosi s više operacije na nižu (sl. 6.5), i povratne informacije o prijavi , kada se izlaz prenosi s nižeg na viši (sl. 6.6).


Riža. 6.5. Izravna veza putem ulaza	Riža. 6.6. Povratne informacije o prijavi

4. Komunikacija s potrošačima događa se kada izlaz jedne funkcije služi kao mehanizam za sljedeću funkciju. Dakle, jedna funkcija troši resurse koje proizvodi druga.

Riža. 6.7. Komunikacija s potrošačima

5. Logička veza promatrana između logički homogenih funkcija. Takve funkcije u pravilu obavljaju isti posao, ali na različite (alternativne) načine ili korištenjem različitih ulaznih podataka (materijala).

Riža. 6.8. Logička veza

6. Kolegijalna (metodološka) komunikacija javlja se između funkcija čiji algoritam rada određuje ista kontrola. Analog takve komunikacije je zajednički rad zaposlenika jednog odjela (kolega), podređenih šefu, koji daje upute i naredbe (kontrolni signali). Takva veza također nastaje kada su algoritmi za rad ovih funkcija određeni istom metodološkom podrškom (SNIP, GOST, službeni regulatorni materijali itd.), Koja služi kao kontrola.

Riža. 6.9. Metodička veza

7. Povezivanje resursa javlja između funkcija koje koriste iste resurse za svoj rad. Funkcije ovisne o resursima općenito se ne mogu izvršavati istovremeno.

Riža. 6.10. Povezivanje resursa

8. Informacijska komunikacija javlja se između funkcija koje koriste iste informacije kao ulaz.

Riža. 6.11. Informacijska komunikacija

9. Privremena veza događa se između funkcija koje se moraju izvršiti istodobno prije ili istodobno nakon druge funkcije.

Osim slučajeva prikazanih na slici, ova se veza također pojavljuje između drugih kombinacija kontrole, ulaza i mehanizma koji ulaze u istu funkciju.

Riža. 6.12. Privremena veza

10. Slučajna veza događa se kada postoji mala ili nikakva specifična povezanost između funkcija.

Riža. 6.13. Slučajna veza

Od navedenih vrsta povezanosti najjača je hijerarhijska veza koja, u biti, određuje spajanje funkcija u module (podsustave). Regulatorne, funkcionalne i potrošačke veze su nešto slabije. Funkcije s ovim odnosima obično se implementiraju u jednom podsustavu. Logičke, kolegijalne, resursne i informacijske veze su među najslabijima. Funkcije koje ih imaju u pravilu su implementirane u različite podsustave, s izuzetkom logički homogenih funkcija (funkcija povezanih logičkom vezom). Vremenska komunikacija ukazuje na slabu ovisnost funkcija jedna o drugoj i zahtijeva njihovu implementaciju u zasebnim modulima.

Dakle, kod spajanja funkcija u module, prvih pet tipova veza su najpoželjniji. Funkcije povezane s zadnjih pet poveznica bolje je implementirati u zasebne module.

IDEF0 ima konvencije (pravila i smjernice) za kreiranje dijagrama koji su dizajnirani da olakšaju čitanje i ispitivanje modela [ , ]. Neka od ovih pravila automatski podržavaju CASE alati, dok se druga moraju provoditi ručno.

1. Prije izgradnje modela potrebno je odlučiti koji će se model(i) sustava graditi. To podrazumijeva određivanje njegovog tipa AS-IS, TO-BE ili SHOULD-BE, kao i određivanje pozicije s koje se gledišta model gradi. "Točku gledišta" najbolje je zamisliti kao mjesto (položaj) osobe ili objekta na kojem se mora stajati kako bi se vidio sustav na djelu. Na primjer, prilikom izgradnje modela poslovanja trgovine mješovitom robom možete odabrati prodavača, blagajnika, računovođu ili direktora među mogućim kandidatima iz kojih se sustav promatra. Obično se odabire jedna točka gledišta koja najpotpunije pokriva sve nijanse rada sustava, a ako je potrebno, za neke dijagrame dekompozicije konstruiraju se FEO dijagrami koji prikazuju alternativnu točku gledišta.

2. Kontekstni dijagram prikazuje jedan blok koji prikazuje svrhu sustava. Preporuča se prikazati 2-4 strelice koje ulaze i izlaze sa svake strane.

3. Broj blokova na dijagramima dekompozicije preporučuje se unutar 3–6. Ako dijagram dekompozicije ima dva bloka, tada obično nema smisla. U prisutnosti velika količina blok dijagram postaje prezasićen i težak za čitanje.

4. Blokovi u dekompozicijskom dijagramu trebaju biti poredani slijeva na desno i odozgo prema dolje. Ovaj raspored omogućuje vam da jasnije odražavate logiku i redoslijed rada. Osim toga, rute strelica bit će manje zbunjujuće i imati minimalan broj raskrižja.

5. Nije dopušteno nepostojanje kontrolnih strelica i strelica za unos za funkciju. To znači da se pokretanje ove funkcije ne kontrolira i može se dogoditi u bilo kojem proizvoljnom trenutku ili nikada.

Riža. 6.14. Funkcija bez kontrole i unosa

Blok sa samo kontrolom može se smatrati pozivom u programu funkcije (procedure) bez parametara. Ako blok ima ulaz, onda je to ekvivalentno pozivanju funkcije s parametrima u programu. Dakle, blok bez kontrole i unosa je ekvivalentan funkciji koja se nikada ne poziva na izvršenje u programu.

Na sl. 6.7–6.12, prikazujući fragmente IDEF0 dijagrama, postoje blokovi bez ulaza i kontrole. Ovo se ne bi trebalo smatrati pogreškom, budući da je jedna od ovih strelica predviđena da bude tamo.

6. Svaki blok mora imati najmanje jedan izlaz.

Riža. 6.15. Funkcija bez izlaza

Rad bez rezultata nema smisla i ne treba ga modelirati. Izuzetak su radovi prikazani u modelu KAKVI JESU. Njihova prisutnost ukazuje na neučinkovitost i nesavršenost tehnoloških procesa. U modelu TO-BE te aktivnosti ne bi trebale biti.

7. Prilikom konstruiranja dijagrama, trebali biste smanjiti broj sjecišta, petlji i okreta strelica.

8. Povratne informacije i iteracije (cikličke akcije) mogu se prikazati pomoću stražnjih lukova. Ulazna povratna sprega nacrtana je kao "donja" petlja, upravljačka povratna sprega kao "gornja" petlja (vidi slike 6.4 i 6.6).

9. Svaki blok i svaka strelica na dijagramima moraju imati naziv. Dopušteno je koristiti grananje (razlaganje) ili spajanje (sastavljanje) strelica. To je zbog činjenice da se isti podaci ili objekti koje generira jedan posao mogu koristiti u nekoliko drugih poslova odjednom. Suprotno tome, isti ili homogeni podaci i objekti generirani različitim poslovima mogu se koristiti na istom mjestu.

Riža. 6.16. Razgranate strelice

U ovom slučaju, moguće je dodijeliti kvalificirajuća imena različitim granama strelice nakon grananja (prije spajanja). Ako neka grana nije nazvana po grani, tada se smatra da njen naziv odgovara nazivu strelice koja je ispisana ispred grane.

Dakle, na Sl. 6.16, kontrole uključene u blokove "Proizvodnja dijelova" i "Sastavljanje proizvoda" imaju pojašnjavajuća značenja i sastavni su dio općenitije kontrole "Crteži". Svi crteži se koriste za upravljanje blokom kontrole kvalitete.

Nije dopušteno crtati strelice na dijagramu ako nisu imenovane ispred i iza grane. Na sl. 6.17 strelica uključena u blok "Generacija standardnih izjava" nema naziv prije i iza grane, što je pogreška.

Riža. 6.17. Netočno imenovanje strijela

10. Prilikom konstruiranja dijagrama, mehanizam za tuneliranje strelica može se koristiti za bolju čitljivost. Na primjer, kako se dijagrami gornje razine (roditeljski) ne bi zatrpali nepotrebnim detaljima, u dijagramima dekompozicije početak luka se postavlja u tunel.

Riža. 6.18. Strelica za tuneliranje

U ovom primjeru pri konstruiranju modela dirigiranja novogodišnja zabava mehanizam "dvije osi" neće biti prikazan na dijagramima gornjih razina, pri čitanju kojih se može pojaviti pošteno pitanje: "Zašto su potrebne dvije sjekire na novogodišnjoj zabavi?"

Slično, možete tunelirati sa suprotnim ciljem sprječavanja pojavljivanja strelice na dijagramima niže razine. U ovom slučaju, zagrade se stavljaju na kraj strelice. U kontekstualnom dijagramu (vidi sl. 6.21), mehanizam "Track Service Engineer", uključen u blok "Određivanje dopuštenih brzina", je tuneliran. Ova je odluka donesena budući da je inženjer izravno uključen u sav posao prikazan na dijagramu dekompozicije ovog bloka (vidi sl. 6.22). Kako bi se izbjeglo pokazivanje ove veze i kako bi se izbjeglo zatrpavanje dijagrama dekompozicije, strelica je tunelirana.

11. Sve strelice koje ulaze i izlaze iz bloka, kada se za njega konstruira dekompozicijski dijagram, moraju biti prikazane na njemu. Izuzetak su tunelirane strelice. Nazivi strelica prenesenih na dijagram dekompozicije moraju odgovarati nazivima navedenim na dijagramu najviše razine.

12. Ako dvije strelice idu paralelno (počevši od iste strane jednog djela i završavajući na istoj strani drugog djela), tada ih, ako je moguće, treba spojiti i nazvati jednim izrazom.

Riža. 6.19. Spajanje veza

13. Svaki blok na dijagramima mora imati svoj broj. Brojevi grafikona koriste se za označavanje položaja bilo kojeg grafikona ili bloka u hijerarhiji. Blok na dijagramu najviše razine označen je s 0, blokovi na dijagramima druge razine brojevima od 1 do 9 (1, 2, ..., 9), blokovi na trećoj razini s dva broja, od kojih je prvi označava broj detaljnog bloka iz nadređenog dijagrama, a drugi po redu broj bloka na trenutnom dijagramu (11, 12, 25, 63) itd. Kontekstni dijagram ima oznaku “A - 0”, dijagram dekompozicije prve razine je "A0", dijagrami dekompozicije sljedećih razina označeni su slovom "A" iza kojeg slijedi broj bloka koji se rastavlja (na primjer, "A11", "A12", "A25", " A63"). Slika prikazuje tipični dijagram stabla (dijagram stabla čvorova) s numeriranjem.

Riža. 6.20. Hijerarhija dijagrama

U modernim CASE alatima automatski su podržani mehanizmi numeriranja radova. CASE alati također omogućuju automatsku konstrukciju dijagrama stabla čvorova koji sadrže samo hijerarhijske odnose. Vrh takvog dijagrama može biti bilo koji čvor (blok), a može se graditi do bilo koje dubine.

6.6. Primjer izgradnje IDEF0 modela za sustav za određivanje dopuštenih brzina

Izračunavanje dopuštenih brzina vlakova je inženjerski zahtjevan zadatak. Kada vlak prolazi bilo kojom dionicom, stvarna brzina vlaka ne smije biti veća od najveće dopuštene brzine. Ova najveća dopuštena brzina određena je na temelju iskustva u radu i posebno provedenih ispitivanja dinamike kretanja i utjecaja na kolosijek željezničkog vozila. Neprekoračenje ove brzine jamči sigurnost prometa vlakova, ugodne uvjete vožnje za putnike itd. Određuju se ovisno o vrsti željezničkog vozila (marka lokomotive i tip vagona), parametrima gornjeg ustroja kolosijeka (vrsta tračnice, balast, dijagram pragova) i plan (krivulje radijusa, prijelazne krivulje, vanjske kote tračnica, itd.). U pravilu, za utvrđivanje dopuštenih brzina potrebno je odrediti najmanje dvije (na ravnim crtama) i pet (u zavojima) brzine, od kojih se konačna dopuštena brzina odabire kao najmanja od svih izračunatih. Izračun ovih brzina reguliran je Naredbom Ministarstva željeznica Rusije br. 41 od 12. studenog 2001. "Norme dopuštenih brzina željezničkih vozila na željeznicama kolosijeka 1520 (1524) mm Saveznog željezničkog prometa."

Kao što je navedeno, konstrukcija IDEF0 modela započinje prikazom cijelog sustava u obliku jednostavne komponente (kontekstnog dijagrama). Ovaj dijagram prikazuje svrhu (glavnu funkciju) sustava i potrebne ulazne i izlazne podatke, upravljačke i regulatorne informacije, kao i mehanizme.

Kontekstni dijagram za problem određivanja dopuštenih brzina prikazan je na sl. 6.21. Za izradu modela korišten je proizvod BPwin 4.0 tvrtke Computer Associates.

Riža. 6.21. Kontekstni dijagram sustava za određivanje dopuštenih brzina (IDEF0 metodologija)

Kao popratne informacije, na temelju kojih se određuju dopuštene brzine, koriste se:

Projektni podaci za novu prugu ili projekt rekonstrukcije (sadrži sve podatke potrebne za realizaciju projekta, odnosno kilometražu, osi razdjelnih točaka, plan pruge i sl.);

Detaljan uzdužni profil (sadrži podatke slične onima koji su gore navedeni);

Putovnica duljine kolosijeka (sadrži podatke slične gore navedenim, kao i podatke o gornjem ustroju kolosijeka (VSP));

Podaci o rezultatima snimanja kolosiječnog plana kolosiječnom mjernom kolicom;

Popis kota vanjskih tračnica u krivinama (sadrži podatke o planu kolosijeka).

Neke od pozadinskih informacija mogu se uzeti iz različitih izvora. Konkretno, podaci o planu (parametri krivulje) mogu se preuzeti iz projekta nove pruge ili projekta rekonstrukcije, detaljnog uzdužnog profila, potvrde o udaljenosti kolosijeka itd.

Kontrolni podaci su:

Uputa voditelja službe cestovne pruge ili Odjela za pruge i konstrukcije JSC Ruske željeznice za izračun;

Naredba br. 41, koja sadrži regulatorne i referentne informacije, postupke i formule za određivanje dopuštenih brzina;

Podaci o trenutnom ili planiranom prometu vlakova (podaci o markama lokomotiva u prometu i tipovima vagona koji se koriste);

Podaci o planiranim popravcima kolosijeka, rekonstrukciji i rekonstrukciji građevina i uređaja.

Rezultat rad sustava trebao bi biti:

Popisi dopuštenih brzina, koji sadrže sve vrste izračunatih brzina i omogućuju utvrđivanje razloga za njihovo ograničenje;

Listovi Naloga voditelja ceste o utvrđivanju dopuštenih brzina na dionicama i odvojenim točkama (Nalog "N") prema obrascu prihvaćenom na cesti. Odobrena Naredba “N” službeno utvrđuje dopuštene brzine vlakova;

Standardni obrasci br. 1, 1a i 2 koji sadrže planirane dopuštene brzine za izradu reda vožnje vlakova.

Brzine sadržane u Narudžbi “N” i standardnim obrascima mogu se razlikovati od onih izračunatih i prikazanih u listovima dopuštene brzine. To je zbog činjenice da ona odražavaju ograničenja brzine ne samo na dizajn željezničkog vozila, VSP parametre i krivulje, već i na stanje uređaja i konstrukcija (deformacija kolnika, neusklađenost nosača nadzemne kontaktne mreže itd.). ). Osim toga, prilagođavaju se uzimajući u obzir planirane popravke kolosijeka, rekonstrukciju i rekonstrukciju građevina i uređaja itd.

Nakon što je konstruiran, dijagram konteksta je detaljiziran korištenjem dijagrama dekompozicije prve razine. Ovaj dijagram prikazuje funkcije sustava koje se moraju implementirati unutar osnovne funkcije. Dijagram za koji je izvršena dekompozicija, u odnosu na dijagrame koji ga detaljno opisuju, naziva se roditeljski . Dekompozicijski dijagram s obzirom na svog roditelja naziva se podružnica .

Dijagram dekompozicije prve razine za problem koji razmatramo prikazan je na slici 6.22. U pravilu, kada se konstruira dekompozicijski dijagram, izvorna funkcija (dekomponirana) dijeli se na 3–8 podfunkcija (blokova). U tom slučaju preporuča se raspored blokova na dekompozicijskom dijagramu s lijeva na desno, odozgo prema dolje, kako bi slijed i logika interakcije podfunkcija bili bolje vidljivi.

Riža. 6.22. Dijagram dekompozicije prve razine (IDEF0 metodologija)

Redoslijed izvršavanja funkcija za rješavanje problema koji se razmatra je sljedeći:

Unos i prilagodba regulatornih i referentnih informacija i podataka o dionicama cesta (blokovi 1 i 2);

Izrada računskog zadatka (3. blok). Označava za koju dionicu i kolosijek, kao i marku lokomotive i tip vagona treba izvršiti izračun;

Izračun dopuštenih brzina prema postupku i formulama navedenim u Naredbi br. 41 (blok 4). Početna informacija su podaci o trasi dionice (plan, gornji ustroj kolosijeka i dr.) i standardi odabrani na temelju računskog zadatka;

Formiranje lista dopuštenih brzina (blok 5). Na temelju rezultata izračuna stvara se nekoliko vrsta izlaznih dokumenata koji, s jedne strane, omogućuju prepoznavanje uzroka ograničenja brzine, s druge strane, služe kao temelj za izradu reguliranih dokumenata;

Formiranje i priprema nacrta Naloga “N” i tipskih izjava (blokovi 6 i 7).

Nakon konstruiranja dekompozicijskog dijagrama prve razine, konstruiraju se posebni dijagrami za funkcije naznačene na njemu (dekompozicijski dijagrami druge razine). Zatim se proces dekompozicije (dijagramiranja) nastavlja sve dok daljnje detaljiziranje funkcija ne postane besmisleno. Za svaku atomsku funkciju koja opisuje elementarnu operaciju (tj. funkciju koja nema dijagram dekompozicije) sastavlja se detaljna specifikacija koja definira njezine značajke i algoritam implementacije. Dijagrami toka algoritama mogu se koristiti kao dodatak specifikaciji. Dakle, proces funkcionalnog modeliranja sastoji se od postupne izgradnje hijerarhije funkcija.

6.7. ICOM kodovi

Strelice koje ulaze i izlaze iz okvira u dijagramu najviše razine iste su kao strelice koje ulaze i izlaze iz dijagrama niže razine, jer okvir i dijagram predstavljaju isti dio sustava (vidi sliku 1) I ). Kao posljedica toga, granice funkcije najviše razine jednake su granicama dekompozicijskog dijagrama.

ICOM kodovi (akronim za ulaz, kontrolu, izlaz i mehanizam) namijenjeni su za prepoznavanje graničnih strelica. ICOM kod sadrži prefiks koji odgovara vrsti strelice (I, C, O ili M) i serijski broj (vidi sliku).