Download pdf - Funkcionalno modeliranje

8/10/2019 Funkcionalno modeliranje

1/51

FUNKCIONALNO

MODELIRANJE

FUNKCIONALNA

DEKOMPOZICIJA

DEFINISANJEZAHTJEVA

KORISNIKA

1

1.1 1.2

TEHNIKI

PREDUSLOVI

1.3


2/51

FUNKCIONALNO MODELIRANJE

Funkcionalno modeliranje omoguujedekomponovanje poslovnih funkcija i

planiranje potrebnih resursa zarealizaciju funkcija.

Funkcionalno modeliranje je vezano za

koritenje IDEFO tehnike.


3/51


4/51

IDEFO funcionalni model

IDEFO funcionalni model se sastoji odhijerarhijskog niza dijagrama koji postepeno

prikazuju sve vie detalja o funkcijama injihovoj meuvezi (interface) sa ostalimdijelovima sistema.

IDEFO modeliranje omoguuje analizu

osobina odreenog poslovnog procesa radinjegovog maksimalnog unapreenja.


5/51

Razlozi za IDEFO funkcionalnomodeliranje

Koristi se kao dokumentacija i upustvo zaopis kompleksnih poslovnih procesa.

Omoguava brze organizacione promjenejer omoguava uvid u kritine aktivnostikoje treba izvesti sa odgovarajuimresursima

Koristi se kao prototipski pristupfunkcionalnom modeliranju gdje se na brz ijednostavan nain provjeravaju alternativneideje.


6/51

Aktivnost:Funkcionalna dekompozicija

FUNKCIONALNA

DEKOMPOZICJA

DEFINISANJEGRANICASISTEMA

DEFINISANJESTABLA

AKTIVNOSTI

1.1

1.1.1 1.1.2

VERIFIKACIJASTABLA

AKTIVNOSTI1.1.3


7/51

Aktivnost:Definisanje granica sistema

Aktivnost Definisanje granicasistema je vezana za nabrajanje

objekata koji e u sljedeemkoraku biti po hijerarhiji povezani ustablo aktivnosti.


8/51


U okviru utvrivanja granica sistematreba jasno definisati ciljeve koji moraju

da sadre sljedee elemente: zato se proces modelira;

ta e proces da prikae;

ta e korisnik modela napraviti sa njim;

emu slui model.


9/51


Slijedea pitanja treba postaviti: koji su zadaci na datom radnom mjestu;

koji je redosljed izvoenja koraka; kako se izvodi kontrola;

koji se resursi koriste.

Dakle, treba identifikovati zadatke svakog

zaposlenog i shvatiti odnose izmeuzadataka. Za ove aktivnosti se koristigrafiki jezik IDEFO.


10/51

Grafiki jezik IDEFO

Grafiki jezik IDEFO opisuje metodufunkcionalne dekompozicije preko skupadijagrama.

Dijagrami se sastoje od pravogaonika kojipredstavljaju neki dio cjeline. Povezani suusmjerenim linijama koje predstavljaju vezeizmeu dijelova.

Postoje tri vrste IDEFO prikaza: grafiki tekstualni i rijenik (glossary).


11/51

Sintaksa grafikog jezika IDEFO

Sintaksu grafikog jezika IDEFO inepravougaonici (boxes), strelice

(arrows) i pravila (rules). Pravougaonici predstavljaju aktivnosti,

definisane kao funkcije, procesi i

transformacije. Svaki pravougaonikima naziv i broj u okviru granicapravougaonika.


12/51

Strelice (Arrows)

Strelica se sastoji od jedne ili vie linija sa vrhomstrelice na jednom kraju.

Strelice mogu biti pravolinijske ili savijene pod

uglom od 90 stepeni i mogu se ravati ili spajati. Strelice predstavljaju podatke ili objekte vezane za

aktivnosti.

Svaka strelica je definisana nazivom (imenicom).

One ne znae samo tok ili sekvencu ve prenosepodatke ili objekte vezane za posmatranu aktivnost.


13/51

Pravougaonik

Aktivnost definisana u okviru pravougaonika ima trikarakteristike: naziv;

vremensku dimenziju;

rezultat rada. Za naziv aktivnosti se koristi aktivan glagol ili

glagolska fraza koja opisuje funkciju.

Broj se koristi da bi bio prepoznat predmet opisa

pravougaonika u pridruenom tekstu.

NAZIVAKTIVNOSTI

1


14/51

Strelice (Arrows)

Pravolinijske strelice Strelica zaokrenuta za

90 stepeni

Ravanje strelica Spajanje strelica


15/51

Pozicija strelica i uloge

Strelice sa lijeve strane pravougaonika se definiu kaoULAZI (INPUT);

Strelice koje ulaze u pravougaonik odozgo se definiu kao

KONTROLE (CONTROL);

Strelice koje izlaze iz pravougaonika na desnoj strani

predstavljaju IZLAZE (OUTPUT);

Strelice na donjoj strani pravougaonika predstavljaju

MEHANIZME. Strelice okrenute prema goreidentifikuju znaenje koje podrava izvrenje aktivnosti.Strelice mehanizma koje su okrenute nadolje definiuse kao strelice POZIVA (CALL ARROWS).


16/51

ICOM DIJAGRAMI

Imajui u vidu englesku notaciju dijagrami se zovu

ICOM dijagrami:I - INPUT, neto to se upotrebljava u aktivnosti;CCONTROL, kontrole ili uslovi izvoenjaaktivnosti;

O - OUTPUT, rezultat izvoenja aktivnosti;M - MEHANIZAM, neto to se koristi uaktivnosti ali se ne mijenja.


17/51

Pozicija strelica i uloge

Naziv aktivnosti

Kontrola

Ulaz Izlaz

Mehanizam Poziv


18/51

Ulazna strelica

Ulazna (Input) strelica predtsvalja materijal ili informaciju koja sekoristi ili transformie radi definisanja izlaza (output). Dozvoljava semogunost da odreene aktivnosti ne moraju imati ulazne strelice.

Kotrolne (Control) strelice reguliu kako, kada i da li e se aktivnostizvesti, odnosno kakvi e biti izlazi (Output). Svaka aktivnost moraimati najmanje jednu kontrolnu strelicu.

Izlazne (Output) strelice su materijali ili infomacije stvoreneaktivnou. Svaka aktivnost mora imati najmanje jednu izlaznu(Output) strelicu.

Strelice mehanizama su izvori koji izvode aktivnosti, a sami se netroe. Mehanizmi mogu biti: ljudi, maine i / ili oprema. Poslobodnoj volji projektanta, strelice mehanizama mogu biti izostavljeneiz aktivnosti.

Strelica poziv (Call) specifini je sluaj strelice mehanizma i onaoznaava da pozivajui pravougaonik nema vlastiti detaljniji dijagram,ve daje detaljniji prikaz izveden na nekom drugom pravougaoniku uistom ili nekom drugom modelu. Imenuju se brojem dekompozicionogdijagrama, koji sadri pozvani pravougaonik zajedno sa brojempozivnog pravougaonika.


19/51

Konteksni dijagram

Konteksni dijagram je definisan jednimpravougaonikom koji predstavlja granicu modelakoji se prouava. U tom sistemu i van njega tekuinformacije preko strelica.

Konteksni dijagam je najvii nivo apstrakcije koji sedekompozicionim dijagramima prevodi u nii nivoapstrakcije. Aktivnost A0 koja se pojavljuje ukontekstnom dijagramu opisuje okvire modela i mora

biti odreena aktivnom glagolskom frazom, kao npr.praenje isplata. Preporuuje se da treba poeti od definisanja izlaznih

strelica, pa se pomjerati prema ulaznim,mehanizmima i kontrolama.


20/51

Kontekstni dijagram

Granice modela se definiu da bi se znalo gdjetreba stati sa modeliranjem. irina modela jevezana za definisanje konteksnog dijagrama

sa oznakom A0 i prvog nivoa dekompozicijekoji nosi oznaku A1.

Dubina modela se definie nivoimadekomponovanja, gdje se definiu nivoidetaljnosti. Dekompozicija ide do mogunostidefinisanja programskih modula koji se moguopisati dijagramima toka podataka, tzv. DataFlow Dijagram (DFD).


21/51


22/51

Aktivnost 1.1.2. Definisanje stabla aktivnosti

Korijen stabla (najvii vor stabla) sadri polaznuaktivnost, dok listovi, tj. vorovi koji nemaju

potomke, sadre aktivnosti ije je rjeavanje relativnojednostavno. Rjeavanjem svih podreenih aktivnosti

iz listova rijeena je i polazna sloena aktivnost. Aktivnost na vrhu (root) uvije je oznaena sa 0.

Brojevi se koriste da bi prikazali koliko detaljasadri aktivnost. Npr. Aktivnost A0 je dekomponovana(razdvojena) na 1,2,3 itd. Aktivnost A1 je

dekomponovana u 11, 12, 13 itd. Nadreena aktivnost se zove roditelj (parent) a

podreene aktivnosti su djeca (childs). Razbijanjeaktivnosti roditelj na svoju djecu treba da ima oddvije do est podreenih aktivnosti. Ako je vie od6 podreenih aktivnosti to znai pokuaj da sesmjesti previe detalja na jedan nivo.


23/51

Aktivnost 1.1.3. Verifikacija stabla aktivnosti

Aktivnost 1.1.3. Verifikacija stabla aktivnosti veoma je vanajer je to strateki momenat, tj. odluka rukovodstva da li je toono to se eli postii reinnjeringom poslovnih procesa.

Ovaj elemenat se mora razmatrati prilikom klasinog nainauvoenja dokumenata za obezbjeenje kvaliteta, postandardu ISO 9000.

Verifikaciono tijelo treba da stalno kontrolie rad strunogtima. Ono ne mora da bude stalnog sastava: u zavisnosti odsadraja koji se verifikuje, ono moe da ima ui ili iri sastav.

Bitno je uestvovanje dijela rukovodstva u izradi projekta. Nakon verifikacije stabla aktivnosti od strane top

menadmenta pristupa se definisanju zahtjeva korisnika kojie da potvrde ili koriguju ovako postavljenu tezu.


24/51

Aktivnost 1.2. Definisanje zahtjeva korisnika

Definisanje zahtjeva

korisnika


iz dokumenata


intervjuom

Definisanje matrice

odnosa

Analiza zahtjeva

korisnika


25/51

Aktivnost 1.2.1. Definisanje zahtjeva iz

dokumenata


dokumenata je pogled odozdo nagore i ima

globalni karakter jer se prikupljaju dokumentiiz cijele firme.

Treba prikupiti:

ulazne dokumente,

izlazne dokumente,

uzorke izvjetaja,

organizacione propise i dr.


26/51


dokumenata

Za prikupljenu dokumentaciju treba dati odgovore na

sljedea pitanja: odakle potiu podaci;

kako su podaci dobijeni;

koliki su maksimum i minimum podataka dobijenih upraksi;

da li se unose tani podaci;

da li se unose kompletni podaci; kako se koriste;

koliko esto se koriste;

koliko je taan taj izlaz danas;


27/51


dokumenata

u kom obliku je prikazan izlaz; kada se izrauje i koliko esto; koliki su obim i broj kopija;

kome se upuuju; ta startuje izlaz; koja se poboljanja mogu uvesti.

Analiza dokumenata analitiaru da formiramiljenje o itkosti tih dokumenata i darazumije korisnikovu terminologiju te da

postavi prava pitanja prilikom intervjua.


28/51

Aktivnost 1.2.2. Definisanje zahtjeva

intervjuom

Aktivnost 1.2.2. Definisanje zahtjeva

intervjuom je pristup odozgo nadole i treba

da omogui definisanje: potreba za informacijama, ciljeva i

problema kako ih vide rukovodioci i neposredni

izvrioci


29/51

Priprema intervjua

Opte pripreme za izvoenje intervjua vezane su zadefinisanje:

liste rukovodilaca za intervjue,

vremenskog rasporeda intervjua, teme za razgovor, potvrde termina, organizacije grupe za intervjue, voenje zapisnika,

priprema panela, opremanje prostorije, izbor optih pitanja i probni intervju.


30/51

Opta pitanja za intervjuisanje

Opta pitanja za intervjuisanje su: koje su nadlenosti i odgovornosti;

ta su osnovni ciljevi i kakve se promjene mogu oekivati

u odreenoj oblasti za slijedeu godinu i dalje; koji su kritini faktori u pogledu odgovornosti upravljanja i

odluivanja;

koji su najvei problemi bili u posljednje vrijeme i ta jebilo potrebno za rijeavanje tih problema;

u kojim procesima se mogu postii poboljanja i koje supotrebe za podacima;

koje su prikupljene informacije najupotrebljivije.


31/51

Izvrioci intervjua

Izvrioci ovog procesa su: poseban tim za intervjue koji priprema i obavlja

intervju, obrauje odgovore i daje analizu intervjua;

poseban tim za katalog aplikacija koji snima i radikatalogizaciju postojeih aplikacija;

eksperti iz domena podsistema ili procesa kojipredlau organizaciono-informaciona rjeenja pojedinihprocesa ili podsistema;

korisnici koji daju informacije o informacionim

potrebama i zahtjevima procesa u koje su ukljueni ikoji ocjenjuju kritinost procesa na osnovudogovorenih mjerila;

koordinacioni odbor.


32/51


33/51

Aktivnost 1.2.3. Definisanje matrice odnosa

Aktivnost 1.2.3. Deffinisanje matrice odnosa treba da

definie matricu veza izmeu aktivnosti idokumenata koji treba da poveu dokumenta

odreena kao ulazne ili izlazne informacije saaktivnostima iz stabla aktivnosti na gornje okvirnom

nivou.

Entiteti na ovom nivou predstavljaju objekat koji se

moe opisati nekim osobinama. Svakom entitetu sepridodaje nain na koji aktivnost koristi taj entitetpreko tzv. CRUD matrice.


34/51

Aktivnost 1.2.3. Definisanje matrice odnosa

Entitet se u okviru neke aktivnosti:

i / ili kreira (CCREATE),

i / ili pretrauje (R RETRIVE), i / ili aurira (U UPDATE),

i / ili brie (D DELETE),

pa otuda i naziv CRUD matrica.


35/51

CRUD matrica za primjer aktivnosti

Praenje isplata

Naziv aktivnosti Naziv entiteta C R U D

Odravanje

podataka oprevodiocima

Odravanje

ifarnikaIzrada

izvjetaja

ISPLATAOSOBA

JEZIKCERTIFIKATODJELJENJE

RMJESTOJEZIK

ODJELJENJERMJESTOISPLATAJEZIKODJELJENJEOSOBA

CERTIFIKAT

C R U DC R U D

RC R U D

R

R

C R U DC R U D

C R U D

RRRR

R


36/51

Aktivnost 1.2.4. Analiza zahtjeva korisnika

Aktivnost 1.2.4. Analiza zahtjeva korisnika

znai da postavke definisane u predhodnim

koracima treba da verfikuje odgovarajuiverfikacioni organ preduzea.

Zadatak verifikacionog tijela je da usvaja

rezultate rada strunog tima u kontrolnim

takama koje predstavljaju okonanjepojednih faza na izradi projekta.


37/51

Aktivnost 1.3. Tehniki preduslovi

Tehniki preduslovi podrazumjevajuraunarski sistem sa definisanim:

sistemom hardver sistemom softver

sistemom dokumentacije Sistem hardver ine: radna memorija, masovna memorija, ulazne

jedinice, izlazne jedinice i centralna procesorska jedinica.

Sistem softver ine: operativni sistemi (UNIX, OPEN / VMS,WINDOWS 2000), zatim jeziki procesori koji se dijele nainterpretere (BASIC) i kompajlere (FORTRAN, PASCAL, C++)

kao i aplikativni softveri u koje spadaju tekst procesori(WORD for WINDOWS) i baze podataka.

Sistem dokumentacije ine dokumentacija za sistem hardver,dokumentacija za sistem softver i ostala dokumentacija.


38/51

Aktivnost 1.3. Tehniki preduslovi

Aktivnost 1.3. Tehniki preduslovi izvodi sekroz tri podreene aktivnosti:

Aktivnost 1.3.1. Definisanje arhitekture sistema Aktivnost 1.3.2. Kadrovske potrebe

Aktivnost 1.3.3. Dinamika realizacije i trokovi


39/51

Aktivnost 1.3.1 Definisanje arhitekture

sistema

Aktivnost 1.3.1 Definisanje arhitekture sistema trebada ukae na osnovne predpostavke koje se morajuispuniti da bi se mogao sprvoditi postupakreinenjeringa poslovnih procesa.

Tehnike i tehnologije raunarstva, komunikacija,pogotovu razvoj Interneta i Intraneta, osnova su zapristupanje sloenom poslu reinenjeringa poslovnihprocesa.

Reinenjering poslovnih procesa treba zasnivati nanajnovijim saznanjima, tenikama i tehnologijama, kaoi principima distribuirane obrade korienja baza

podataka, postizanja kompatibilnosti u mreamaraunara i upotrebama ureaja za prikaz informacija.


40/51

Aktivnost 1.3.1 Definisanje arhitekture

sistema

Reinenjering poslovnih procesa treba zasnivati na najnovijimsaznanjima, tenikama i tehnologijama, kao i principimadistribuirane obrade korienja baza podataka, postizanjakompatibilnosti u mreama raunara i upotrebama ureaja zaprikaz informacija.

Prilaz razmatranja tehniko tehnolokih resursa treba da je usaglasnosti sa otvorenom arhitekturom referentnog modelaorganizacije za standarde, gdje je definisano sedam nivoapovezivanja i komuniciranja raunarske i druge opreme: NIVO 7. APPLICATION (aplikacijski nivo) NIVO 6. PRESENTATION (prezentacijski nivo) NIVO 5. SESSION (nivo sesije)

NIVO 4. TRNSPORT (transportni nivo) NIVO 3. NETWORK (mreni nivo) NIVO 2. DATA LINK (nivo podaciveze) NIVO 1. PHISICAL (fiziki nivo)


41/51

Tehniki tehnoloko preduslovi

Pri izboru opreme treba imati u vidu tehniko -tehnoloke preduslove, koji su sagledavani premastrukturi arhitekture referentnog modela:

kvalitetan komunikacioni sistem visok stepen kompatibilnosti raunarske opreme

otvorenost mrene arhitekture

modularnost opreme krajnijih korisnika

efikasnost sistema upravljanja podacima koritenje softverskih proizvoda za razvoj aplikacije


42/51


43/51

Kompatibilnost raunarske opreme

Kompatibilnost raunarske opreme je neophodna dabi mogla da ini distribuirani sistem, pogotovukompatibilnost centralizovane opreme sa opremom na

mjestima krajnjih korisnika obrade podataka iinformacija.

Neophodna je i kompatibilnost i za ostale nivoe

komuniciranja dva korisnika prema OSI (Open

System Interconnection) referentnom modelu, gdje jeposebno bitna kompatibilnost aplikativnog nivoa i

nivoa predstavljanja podataka i informacija.


44/51

Otvorenost sistema distribuirane obrade

Savremeni sistemi distribuirane obrade zahtjevajuotvorenost mrene arhitekture ovih sistema, satendencijom da se formiraju potpuno distribuiranestrukture i da se obezbjedi to vea integracija svih

raunarskih i drugih ureaja. Osnovni zahtjevi distribuiranim sistemima sagledavaju

se u sklopu doprinosa razvoju informacionih sistemai to prvenstveno radi: pruanja novih kvaliteta krajnjem korisniku,

mogunosti korienja zajednikih resursa, rastereenja centralizovanih resursa, autonomnosti dijelova sistema, vee fleksibilnosti integracije sistema.


45/51

Modularnost raunarske opreme

Za realizaciju postupka reinenjeringa poslovnihprocesa veoma je bitno da se ostvari modularnost

raunarske opreme, posebno opreme na mjestima

krajnjih korisnika.

Raunarska oprema u okviru klijent/serverarhitekture, a za potrebe distribuiranog sistema moese posmatrati u dva osnovna oblika i to kao:

raunarska oprema zajednikih resursa (strana servera) i raunarska oprema krajnjeg korisnika (strana klijenta).


46/51

Efikasnost sistema upravljanja podacima

Osnovni zahtjevi upravljanja podacima su

iskazani kroz potrebu unificiranog

organizovanja i integracije podataka, kao iobezbjeivanja zatite i pouzdanosti podataka.

Prilikom realizacije distribuiranih sistema

treba teiti da se koristi jedinstvenost sistema

upravljanja podacima zbog transparetnostipodataka izmeu raunara, to je bitno zasloene distribuirane sisteme.


47/51

Korienje sistemske podrke za razvojaplikacija

Korienje sistemske podrke za razvojaplikacija je sve nunije, jer se timeobezbjeuje krae vrijeme kreiranja aplikacije,

poveanja uloge krajnjih korisnika i lakeodravanje aplikacija. Tu spadaju:jezici za upite bazama podataka, generatori izvjetaja,

neproceduralni jezici vieg nivoa, generatori aplikacija,parametrizovani namjenski softverski paketi.


48/51

Aktivnost 1.3.2. Kadrovske potrebe

Pod kadrovskim potrebama podrazumjevamo broj potrebnog kadra za realizacijuprojekta reinenjeringa poslovnih procesa i potrebnu obuku za korienjeinformacionih tehnologija.

U sprovoenju reinenjeringa poslovnih procesa potrebni su: rukovodilac, vodei projektant za modeliranje procesa i podataka, vodei projektant softverskih rijeenja, vodei projektant baze podataka, sistem inenjer, referent dokumentacije,

Posebno znaajnu ulogu ima proces obrazovanja kadra i zato treba obezbjeditipregled i sadraj slijedeih kurseva:

kompjutersko opismenjavanje (WINDOWS, MS Word),

integracija IS i zahtjeva sistema kvaliteta (modeliranje procesaBPwin), modeliranje podatakaERwin, generisanje prototipske aplikacije u MS ACCESSu, rad sa tebelamaMS EXSCEL, mreni rad i INTERNET i njegovi servisi.


49/51

Aktivnost 1.3.3. Dianamika realizacije i

trokovi

Kada je rije o dinamici realizacije itrokovima neophodno je korienje nekog odsoftvera za upravljanje projektima (npr. MS

Project).

Trokovi realizacije se posmatraju kao: trokovi razvoja aplikacija,

trokovi tehnikotehnolokih resursa, trokovi eksplatacije.


50/51


51/51

Kao rezultat aktivnosti 1. Funkcionalno

modeliranje trebao bi da proizae dokumentpod nazivom Studija elemenata potrebnih zareinenjering poslovnih procesa na osnovukoje e se sprovesti slijedea aktivnost 2.Informaciono modeliranje.