You are on page 1of 51

FUNKCIONALNO

MODELIRANJE
FUNKCIONALNA

DEKOMPOZICIJA
DEFINISANJE
ZAHTJEVA
KORISNIKA
1
1.1 1.2
TEHNIKI

PREDUSLOVI
1.3
FUNKCIONALNO MODELIRANJE
Funkcionalno modeliranje omoguuje
dekomponovanje poslovnih funkcija i
planiranje potrebnih resursa za
realizaciju funkcija.
Funkcionalno modeliranje je vezano za
koritenje IDEFO tehnike.
IDEFO tehnika
IDEFO je tehnika modeliranja aktivnosti
baziranih na kombinaciji grafike i teksta,
koji su predstavljeni na organizovan i
sistematian nain da bi se poveala
razumljivost koja podrava analizu,
obezbjeuje logiku za potencijalne
izmjene, specificira zahtjeve ili podrava
analizu sistema po nivoima i integrie
aktivnosti.
IDEFO funcionalni model
IDEFO funcionalni model se sastoji od
hijerarhijskog niza dijagrama koji postepeno
prikazuju sve vie detalja o funkcijama i
njihovoj meuvezi (interface) sa ostalim
dijelovima sistema.
IDEFO modeliranje omoguuje analizu
osobina odreenog poslovnog procesa radi
njegovog maksimalnog unapreenja.
Razlozi za IDEFO funkcionalno
modeliranje
Koristi se kao dokumentacija i upustvo za
opis kompleksnih poslovnih procesa.
Omoguava brze organizacione promjene
jer omoguava uvid u kritine aktivnosti
koje treba izvesti sa odgovarajuim
resursima
Koristi se kao prototipski pristup
funkcionalnom modeliranju gdje se na brz i
jednostavan nain provjeravaju alternativne
ideje.

Aktivnost:
Funkcionalna dekompozicija
FUNKCIONALNA

DEKOMPOZICJA
DEFINISANJE
GRANICA
SISTEMA
DEFINISANJE
STABLA
AKTIVNOSTI
1.1
1.1.1 1.1.2
VERIFIKACIJA
STABLA
AKTIVNOSTI
1.1.3
Aktivnost:
Definisanje granica sistema
Aktivnost Definisanje granica
sistema je vezana za nabrajanje
objekata koji e u sljedeem
koraku biti po hijerarhiji povezani u
stablo aktivnosti.
Aktivnost:
Definisanje granica sistema
U okviru utvrivanja granica sistema
treba 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.




Aktivnost:
Definisanje granica sistema
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 izmeu
zadataka. Za ove aktivnosti se koristi
grafiki jezik IDEFO.

Grafiki jezik IDEFO
Grafiki jezik IDEFO opisuje metodu
funkcionalne dekompozicije preko skupa
dijagrama.
Dijagrami se sastoje od pravogaonika koji
predstavljaju neki dio cjeline. Povezani su
usmjerenim linijama koje predstavljaju veze
izmeu dijelova.
Postoje tri vrste IDEFO prikaza:
grafiki
tekstualni i
rijenik (glossary).
Sintaksa grafikog jezika IDEFO
Sintaksu grafikog jezika IDEFO ine
pravougaonici (boxes), strelice
(arrows) i pravila (rules).
Pravougaonici predstavljaju aktivnosti,
definisane kao funkcije, procesi i
transformacije. Svaki pravougaonik
ima naziv i broj u okviru granica
pravougaonika.
Strelice (Arrows)
Strelica se sastoji od jedne ili vie linija sa vrhom
strelice 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 prenose
podatke ili objekte vezane za posmatranu aktivnost.
Pravougaonik
Aktivnost definisana u okviru pravougaonika ima tri
karakteristike:
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.
NAZIV
AKTIVNOSTI
1
Strelice (Arrows)
Pravolinijske strelice Strelica zaokrenuta za
90 stepeni
Ravanje strelica Spajanje strelica
Pozicija strelica i uloge
Strelice sa lijeve strane pravougaonika se definiu kao
ULAZI (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 gore
identifikuju znaenje koje podrava izvrenje aktivnosti.
Strelice mehanizma koje su okrenute nadolje definiu
se kao strelice POZIVA (CALL ARROWS).



ICOM DIJAGRAMI
Imajui u vidu englesku notaciju dijagrami se zovu
ICOM dijagrami:
I - INPUT, neto to se upotrebljava u aktivnosti;
C CONTROL, kontrole ili uslovi izvoenja
aktivnosti;
O - OUTPUT, rezultat izvoenja aktivnosti;
M - MEHANIZAM, neto to se koristi u
aktivnosti ali se ne mijenja.

Pozicija strelica i uloge
Naziv aktivnosti
Kontrola
Ulaz
Izlaz
Mehanizam
Poziv
Ulazna strelica
Ulazna (Input) strelica predtsvalja materijal ili informaciju koja se
koristi ili transformie radi definisanja izlaza (output). Dozvoljava se
mogunost da odreene aktivnosti ne moraju imati ulazne strelice.
Kotrolne (Control) strelice reguliu kako, kada i da li e se aktivnost
izvesti, odnosno kakvi e biti izlazi (Output). Svaka aktivnost mora
imati najmanje jednu kontrolnu strelicu.
Izlazne (Output) strelice su materijali ili infomacije stvorene
aktivnou. Svaka aktivnost mora imati najmanje jednu izlaznu
(Output) strelicu.
Strelice mehanizama su izvori koji izvode aktivnosti, a sami se ne
troe. Mehanizmi mogu biti: ljudi, maine i / ili oprema. Po
slobodnoj volji projektanta, strelice mehanizama mogu biti izostavljene
iz aktivnosti.
Strelica poziv (Call) specifini je sluaj strelice mehanizma i ona
oznaava da pozivajui pravougaonik nema vlastiti detaljniji dijagram,
ve daje detaljniji prikaz izveden na nekom drugom pravougaoniku u
istom ili nekom drugom modelu. Imenuju se brojem dekompozicionog
dijagrama, koji sadri pozvani pravougaonik zajedno sa brojem
pozivnog pravougaonika.
Konteksni dijagram
Konteksni dijagram je definisan jednim
pravougaonikom koji predstavlja granicu modela
koji se prouava. U tom sistemu i van njega teku
informacije preko strelica.
Konteksni dijagam je najvii nivo apstrakcije koji se
dekompozicionim dijagramima prevodi u nii nivo
apstrakcije. Aktivnost A0 koja se pojavljuje u
kontekstnom 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.
Kontekstni dijagram
Granice modela se definiu da bi se znalo gdje
treba stati sa modeliranjem. irina modela je
vezana za definisanje konteksnog dijagrama
sa oznakom A0 i prvog nivoa dekompozicije
koji nosi oznaku A1.
Dubina modela se definie nivoima
dekomponovanja, gdje se definiu nivoi
detaljnosti. Dekompozicija ide do mogunosti
definisanja programskih modula koji se mogu
opisati dijagramima toka podataka, tzv. Data
Flow Dijagram (DFD).

Aktivnost 1.1.2. Definisanje stabla aktivnosti
Na osnovu definisanih granica sistema prelazi se na
slijedeu aktivnost 1.1.2. Definisanje stabla aktivnosti
gdje se uspostavljaju vertikalne (hijerarhijske) veze
izmeu aktivnosti.
Stablo aktivnosti predstavlja hijerarhiju definisanih
aktivnosti, oienu od strelica i omoguuje
funkcionalnu dekompoziciju i uvid u dubinu odvijanja
veza izmeu aktivnosti.
Stablo aktivnosti se definie primjenom metode
rjeavanja problema ODOZGO-NADOLE (TOP-
DOWN), kada se sloena aktivnost rastavlja na vie
podreenih aktivnosti, a zatim se pristupa rjeavanju
jednostavnih podreenih aktivnosti.
Aktivnost 1.1.2. Definisanje stabla aktivnosti
Korijen stabla (najvii vor stabla) sadri polaznu
aktivnost, dok listovi, tj. vorovi koji nemaju
potomke, sadre aktivnosti ije je rjeavanje relativno
jednostavno. 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 detalja
sadri 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). Razbijanje
aktivnosti roditelj na svoju djecu treba da ima od
dvije do est podreenih aktivnosti. Ako je vie od
6 podreenih aktivnosti to znai pokuaj da se
smjesti previe detalja na jedan nivo.


Aktivnost 1.1.3. Verifikacija stabla aktivnosti
Aktivnost 1.1.3. Verifikacija stabla aktivnosti veoma je vana
jer je to strateki momenat, tj. odluka rukovodstva da li je to
ono to se eli postii reinnjeringom poslovnih procesa.
Ovaj elemenat se mora razmatrati prilikom klasinog naina
uvoenja dokumenata za obezbjeenje kvaliteta, po
standardu ISO 9000.
Verifikaciono tijelo treba da stalno kontrolie rad strunog
tima. Ono ne mora da bude stalnog sastava: u zavisnosti od
sadraja 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 koji
e da potvrde ili koriguju ovako postavljenu tezu.
Aktivnost 1.2. Definisanje zahtjeva korisnika
Definisanje zahtjeva
korisnika
Definisanje zahtjeva
iz dokumenata
Definisanje zahtjeva
intervjuom
Definisanje matrice
odnosa
Analiza zahtjeva
korisnika
Aktivnost 1.2.1. Definisanje zahtjeva iz
dokumenata
Aktivnost 1.2.1. Definisanje zahtjeva iz
dokumenata je pogled odozdo nagore i ima
globalni karakter jer se prikupljaju dokumenti
iz cijele firme.
Treba prikupiti:
ulazne dokumente,
izlazne dokumente,
uzorke izvjetaja,
organizacione propise i dr.
Aktivnost 1.2.1. Definisanje zahtjeva iz
dokumenata
Za prikupljenu dokumentaciju treba dati odgovore na
sljedea pitanja:
odakle potiu podaci;
kako su podaci dobijeni;
koliki su maksimum i minimum podataka dobijenih u
praksi;
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;
Aktivnost 1.2.1. Definisanje zahtjeva iz
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 formira
miljenje o itkosti tih dokumenata i da
razumije korisnikovu terminologiju te da
postavi prava pitanja prilikom intervjua.
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
Priprema intervjua
Opte pripreme za izvoenje intervjua vezane su za
definisanje:
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.
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 je
bilo potrebno za rijeavanje tih problema;
u kojim procesima se mogu postii poboljanja i koje su
potrebe za podacima;
koje su prikupljene informacije najupotrebljivije.
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 radi
katalogizaciju postojeih aplikacija;
eksperti iz domena podsistema ili procesa koji
predlau organizaciono-informaciona rjeenja pojedinih
procesa ili podsistema;
korisnici koji daju informacije o informacionim
potrebama i zahtjevima procesa u koje su ukljueni i
koji ocjenjuju kritinost procesa na osnovu
dogovorenih mjerila;
koordinacioni odbor.
Koordinacioni odbor - uloga i zadaci
Koordinacioni odbor koordinira rad posebnih
timova koji sprovode intervjue. Zadaci
koordinacionog tima su:
usvaja predloena organizaciono informaciona
rijeenja,
odreuje mjerila za ocjenu kritinosti procesa,
usvaja analize posebnih timova i
utvruje prioritete razvoja podsistema.
Aktivnost 1.2.3. Definisanje matrice odnosa
Aktivnost 1.2.3. Deffinisanje matrice odnosa treba da
definie matricu veza izmeu aktivnosti i
dokumenata koji treba da poveu dokumenta
odreena kao ulazne ili izlazne informacije sa
aktivnostima iz stabla aktivnosti na gornje okvirnom
nivou.
Entiteti na ovom nivou predstavljaju objekat koji se
moe opisati nekim osobinama. Svakom entitetu se
pridodaje nain na koji aktivnost koristi taj entitet
preko tzv. CRUD matrice.
Aktivnost 1.2.3. Definisanje matrice odnosa
Entitet se u okviru neke aktivnosti:
i / ili kreira (C CREATE),
i / ili pretrauje (R RETRIVE),
i / ili aurira (U UPDATE),
i / ili brie (D DELETE),
pa otuda i naziv CRUD matrica.
CRUD matrica za primjer aktivnosti
Praenje isplata

Naziv aktivnosti Naziv entiteta
C R U D
Odravanje
podataka o
prevodiocima
Odravanje
ifarnika
Izrada
izvjetaja
ISPLATA
OSOBA
JEZIK
CERTIFIKAT
ODJELJENJE
RMJESTO
JEZIK
ODJELJENJE
RMJESTO
ISPLATA
JEZIK
ODJELJENJE
OSOBA
CERTIFIKAT
C R U D

C R U D
R
C R U D
R
R
C R U D
C R U D
C R U D
R
R
R
R
R
Aktivnost 1.2.4. Analiza zahtjeva korisnika
Aktivnost 1.2.4. Analiza zahtjeva korisnika
znai da postavke definisane u predhodnim
koracima treba da verfikuje odgovarajui
verfikacioni organ preduzea.
Zadatak verifikacionog tijela je da usvaja
rezultate rada strunog tima u kontrolnim
takama koje predstavljaju okonanje
pojednih faza na izradi projekta.
Aktivnost 1.3. Tehniki preduslovi
Tehniki preduslovi podrazumjevaju
raunarski 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 na
interpretere (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.

Aktivnost 1.3. Tehniki preduslovi
Aktivnost 1.3. Tehniki preduslovi izvodi se
kroz tri podreene aktivnosti:
Aktivnost 1.3.1. Definisanje arhitekture sistema
Aktivnost 1.3.2. Kadrovske potrebe
Aktivnost 1.3.3. Dinamika realizacije i trokovi


Aktivnost 1.3.1 Definisanje arhitekture
sistema
Aktivnost 1.3.1 Definisanje arhitekture sistema treba
da ukae na osnovne predpostavke koje se moraju
ispuniti da bi se mogao sprvoditi postupak
reinenjeringa poslovnih procesa.
Tehnike i tehnologije raunarstva, komunikacija,
pogotovu razvoj Interneta i Intraneta, osnova su za
pristupanje sloenom poslu reinenjeringa poslovnih
procesa.
Reinenjering poslovnih procesa treba zasnivati na
najnovijim saznanjima, tenikama i tehnologijama, kao
i principima distribuirane obrade korienja baza
podataka, postizanja kompatibilnosti u mreama
raunara i upotrebama ureaja za prikaz informacija.
Aktivnost 1.3.1 Definisanje arhitekture
sistema
Reinenjering poslovnih procesa treba zasnivati na najnovijim
saznanjima, tenikama i tehnologijama, kao i principima
distribuirane obrade korienja baza podataka, postizanja
kompatibilnosti u mreama raunara i upotrebama ureaja za
prikaz informacija.
Prilaz razmatranja tehniko tehnolokih resursa treba da je u
saglasnosti sa otvorenom arhitekturom referentnog modela
organizacije za standarde, gdje je definisano sedam nivoa
povezivanja 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 podaci veze)
NIVO 1. PHISICAL (fiziki nivo)
Tehniki tehnoloko preduslovi
Pri izboru opreme treba imati u vidu tehniko -
tehnoloke preduslove, koji su sagledavani prema
strukturi 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
Kvalitetan komunikacioni sistem
Kvalitetan komunikacioni sistem treba da nezavisi od
raunarske opreme i da obezbjeuje neogranieno
komuniciranje meu svim krajnjim korisnicima i da
posejduje mogunost intergracije informacija u obliku
podataka glasa, teksta, slike i crtea.
Lokalne mree (LAN) predstavljaju komunikacioni
pod sistem za lokalna geografska podruija, a mogu
da se povezuju i sa drugim mreama za prenos
podataka i informacija (MAN, WAN).
Za vea rastojanja koriste se javne mree za prenos
govora i podataka, privatne mree i mree posebnih
najmjena.
Kompatibilnost raunarske opreme
Kompatibilnost raunarske opreme je neophodna da
bi mogla da ini distribuirani sistem, pogotovu
kompatibilnost centralizovane opreme sa opremom na
mjestima krajnjih korisnika obrade podataka i
informacija.
Neophodna je i kompatibilnost i za ostale nivoe
komuniciranja dva korisnika prema OSI (Open
System Interconnection) referentnom modelu, gdje je
posebno bitna kompatibilnost aplikativnog nivoa i
nivoa predstavljanja podataka i informacija.
Otvorenost sistema distribuirane obrade
Savremeni sistemi distribuirane obrade zahtjevaju
otvorenost mrene arhitekture ovih sistema, sa
tendencijom da se formiraju potpuno distribuirane
strukture i da se obezbjedi to vea integracija svih
raunarskih i drugih ureaja.
Osnovni zahtjevi distribuiranim sistemima sagledavaju
se u sklopu doprinosa razvoju informacionih sistema
i to prvenstveno radi:
pruanja novih kvaliteta krajnjem korisniku,
mogunosti korienja zajednikih resursa,
rastereenja centralizovanih resursa,
autonomnosti dijelova sistema,
vee fleksibilnosti integracije sistema.
Modularnost raunarske opreme
Za realizaciju postupka reinenjeringa poslovnih
procesa veoma je bitno da se ostvari modularnost
raunarske opreme, posebno opreme na mjestima
krajnjih korisnika.
Raunarska oprema u okviru klijent/server
arhitekture, a za potrebe distribuiranog sistema moe
se posmatrati u dva osnovna oblika i to kao:
raunarska oprema zajednikih resursa (strana servera) i
raunarska oprema krajnjeg korisnika (strana klijenta).
Efikasnost sistema upravljanja podacima
Osnovni zahtjevi upravljanja podacima su
iskazani kroz potrebu unificiranog
organizovanja i integracije podataka, kao i
obezbjeivanja zatite i pouzdanosti podataka.
Prilikom realizacije distribuiranih sistema
treba teiti da se koristi jedinstvenost sistema
upravljanja podacima zbog transparetnosti
podataka izmeu raunara, to je bitno za
sloene distribuirane sisteme.
Korienje sistemske podrke za razvoj
aplikacija
Korienje sistemske podrke za razvoj
aplikacija je sve nunije, jer se time
obezbjeuje krae vrijeme kreiranja aplikacije,
poveanja uloge krajnjih korisnika i lake
odravanje aplikacija. Tu spadaju:
jezici za upite bazama podataka,
generatori izvjetaja,
neproceduralni jezici vieg nivoa,
generatori aplikacija,
parametrizovani namjenski softverski paketi.
Aktivnost 1.3.2. Kadrovske potrebe
Pod kadrovskim potrebama podrazumjevamo broj potrebnog kadra za realizaciju
projekta reinenjeringa poslovnih procesa i potrebnu obuku za korienje
informacionih 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 obezbjediti
pregled i sadraj slijedeih kurseva:
kompjutersko opismenjavanje (WINDOWS, MS Word),
integracija IS i zahtjeva sistema kvaliteta (modeliranje procesa BPwin),
modeliranje podataka ERwin,
generisanje prototipske aplikacije u MS ACCESS u,
rad sa tebelama MS EXSCEL,
mreni rad i INTERNET i njegovi servisi.

Aktivnost 1.3.3. Dianamika realizacije i
trokovi
Kada je rije o dinamici realizacije i
trokovima neophodno je korienje nekog od
softvera za upravljanje projektima (npr. MS
Project).
Trokovi realizacije se posmatraju kao:
trokovi razvoja aplikacija,
trokovi tehnikotehnolokih resursa,
trokovi eksplatacije.
Specifikacija trokova
Trokovi razvoja:
obuka projektnog tima,
razvoj zajednikih aplikacija,
struna pomo pri razvoju,
razvoj i dopuna sopstvenih aplikacija,
softverski proizvodi za razvoj aplikacija.
Trokovi tehniko-tehnolokih resursa:
raunarska oprema zajednikih resursa,
oprema komunikacionog sistema,
dopuna i kompletiranje raunarske opreme,
pratea oprema i adaptacija prostora.
Trokovi eksplatacije:
odravanje opreme,
potronja elektrine energije,
korienje komunikacionih linija,
amortizacija opreme,
plate radnika.
Kao rezultat aktivnosti 1. Funkcionalno
modeliranje trebao bi da proizae dokument
pod nazivom Studija elemenata potrebnih za
reinenjering poslovnih procesa na osnovu
koje e se sprovesti slijedea aktivnost 2.
Informaciono modeliranje.

You might also like