1.3.9.

IVOTNI CIKLUS INFORMACIONOG SISTEMA

Proces nastajanja i delovanja IS nazivamo ivotni ciklus informacionog sistema.
ivotni ciklus daje eksplicitni prikaz faza nastajanja i menjanja IS.
Zavisno od metodologije razvoja IS u praksi se susreu razliiti ivotni ciklusi
sistema koje okvirno moemo podeliti u sledee dve klase: lenearne i evolucijske.

1.3.10.LINERNI PRISTUP
Linearni pristup (tradicionalni pristup) zasniva se na ideji da se razvoj IS moe
izvriti sprovodjenjem niza faza koje slede jedna za drugom. Kada se zavri jedna faza
prelazi se na sledeu fazu do knanog cilja.
U okviru linearnog pristupa postoje sledee faze:
1.
Planiranje,
2.
Analiza i dizajn,
3.
Implementacija,
4.
Funkcionisanje i odravanje,
5.
Vrednovanje i kontrola.
Nedostaci projektovanja informacionih sistema po linearnom pristupu su:
1.
odloena implementacija,
2.
orijentisanost na procese,
3.
sporost projektovanja i izgradnje,
4.
nezadovoljstvo korisnika,
5.
visoka cena razvoja,
6.
vraanje na prethodne faze,
7.
teko odravanje.
Vraanje na prethodne faze u linearnom pristupu nastaje mimo nae volje kao
posledice propusta i greaka u prethodnim fazama. Tipini uzroci vraanja nazad su
nedovoljno poznavanje sistema, velika sloenost i obimnost sistema. Vraanje nazad je
svakako nepoeljno jer zahteva izmene ve uradjenog, a time i dodatno vreme i sredstva.
Nain da se izbegne kruenje je da se problem uini manje sloenim i obimnim tako
da se IS podeli na dva ili vie relativno nezavisna podsistema koji se dalje razvijaju
nezavisno. Na taj nain za svaki podsistem nastaje poseban ivotni ciklus.
Predloeni pristup moe se primeniti u sluajevima gde se jedinstven sistem moe
adekvatno rastaviti na vie relativno nezavisnih podsistema. Potreba za razbijanje sistema
na podsisteme, kao i mogunost razvoja sistema po delovima utvrdjuje se u fazi
planiranja razvoja IS kao celine kada treba dati odgovor i na pitanje potrebe razvoja
sistema po delovima.
Kada se prihvati koncepcija razvoja IS po delovima, definiu se podsistemi i
pristupa realizaciji svakog od njih. Celovit sistem dobija se naknadnom integracijom
podsistema.
Razvoj IS putem razbijanja sistema na podsisteme i zaseban razvoj svakog od njih
pored toga to doprinosi savladavnju sloenosti i obimnosti sistema ima i niz drugih
prednosti. Pojedini podsistemi bre ulaze u primenu. Nain investiranja je obino
prihvatljiviji: vie manjih investicija koje bre daju rezultat, umesto jedne velike koja
sporije donosi rezultat.
Razvoj IS po delovima potencijalno moe doneti tekoe u integraciji podsistema u
celini. To se pre svega deava ako prvi podsistemi nisu razvijeni tako da se sledei
podsistemi mogu sa njima integrisati pa se mora pristupiti naknadnom menjaju ve
razvijenih podsistema. Slino se moe i rei i za opremu. Oprema nabavljena samo za
potrebe prvih podsistema ne moe zadovoljiti potrebe novih podsistema.
Nain da se izbegnu navedene potekoe u integraciji podsistema je da se definie
jedinstven model podataka za ceo IS, i nabaviti modularna oprema koja dozvoljava
jednostavna proirenja i nadgradnju.
Kod razvoja IS po delovima, ivotni ciklus svakog od podsistema moe ostati
linearan uz eventualna neizbena i nepoeljna povremena kruenja.

Linearni pristup nije primeren u sloenim i nedovoljno definisanim sistemima.

Takodje nije primeren za nedovoljno iskusne projektante sistema. Pogodnije reenje pri
navedenim uslovima je metoda pokuaja i promaaja uz nastojanje da promaaja bude to
manje. U praksi ta se metoda esto naziva metodom prototipa.

1.3.11. EVOLUCIJSKI PRISTUP

Sutina pristupa u razvoju IS prema linearnom ivotnom ciklusu je razvoj u jednom
prolazu (tj. bez vraanja nazad) po definisanim fazama.
Evolicijski pristup razvoja IS zasniva se na radnoj pretpostavci da postoji
mogunost uspenog razvoja IS putem upoznavanja i definisanja sistema samim radom na
njegovom razvoju. Ispravnost pretpostavke, kao i postojanje prihvatljivog naina
ostvarenja utvrdjuje se samim radom na njenoj realizaciji.
Prema evolucijskom pristupu razvoj sistema odvija se po pojedinim funkcijama
sistema. Rad se poinje na nekoj jednostavnoj i dobro poznatoj funkciji ili nekoj od funkcija
za koju se smatra da bi mogla biti kritina u kontekstu razvoja celog sistema.
Bitna odlika evolucijsko pristupa je da rad na razvoju pojedinane funkcije sistema
ujedno slui definisanju problema. Projektant IS i korisnik ue putem rada ta bi i kako bilo
dobro uraditi. Saznanja i iskustvo steeno u razvoju jedne funkcije sistema daju osnovu za
utvrdjivanje i razvoj daljih funkcija IS.
Po evolucijskom pristupu rad na razvoju sistema nastavlja se sve dok se ne iscpe
potrebe ili mogunosti dalje informatizacije funkcija datog sistema.
Realizacija informatizacije funkcije obuhvata izradu predloga reenja i njegovo
vrednovanje u praktinoj (ili probnoj) primeni. Predlog reenja naziva se prototip.
Prototip obino nastaje korienjem alata za brzi razvoj IS u saradnji sa korisnikom.
Do predloga reenja tj. prototipa dolazi se prethodnom analizom i izradom
projekta. Moe se rei da se sama izrada prototipa odvija prema linearnom ivotnom
ciklusu. Medjutim, ovde se analiza i projektovanju posveuje manje panje, ostavljajui da
probni rad programa prototipa pokae kvalitete i nedostatke predloenog reenja.
Ponavljanja prethodnih faza koja se u linearnom pristupu ele izbei ovde postaju sastavni
deo procesa rada na realizaciji odabrane funkcije, a time i celog IS.
Svaka funkcija realizuje se kao predlog (ili prototip), koji se iterativno doradjuje u
skladu sa sugestijom korisnika i saznanjima koja slede iz probnog korienja.
Informacioni sistem smatra se izgradjenim kada nema vie novih funkcija za
informatizaciju.

1.3.12. IZBOR IVOTNOG CIKLUSA

Izbor ivotnog ciklusa IS predstavlja zapravo izbor metode rada na razvoju IS.
Prema linearnom pristupu pretpostavlja se izvravanje pojedinih faza u
projektovanju bez povraaja nazad. Da bi se uspeno realizovao takav pristup potrebno je
da korisnik tano zna ta eli te da to zna precizno izraziti i da projektant tano zna na koji
se nain elje korisnika mogu realizovati.
Medjutim u praksi stvari nisu uvek naklonjene zahtevima linearnog pristupa.
Naime, korisnici esto nemaju uvida u nain odvijanja svih funkcija sistema ili ne
postoji jedinstven stav o potrebi i nainu izvodjenja pojedinih funkcija. Automatizacijom
neke funkcije mogu se otvoriti nove mogunosti u realizaciji drugih funkcija, to korisnik
ne moe unapred znai koje ekrane eli imati, i kako bi te ekrane trebalo oblikovati.
Projektanti IS suoeni su sa stalnom pojavom novih tehnologija koje zahtevaju
eksperimentisanje i sticanje novih iskustava u radu. esta pojava novih proizvoda ne daje
mnogo prilika za sticanje bogatog iskustva u radu sa pojedinim od tih proizvodima.
Iz navedenih razloga, i za korisnika i za projektanta, evlucijski pristup u razvoju IS
izgleda prikladniji od linearnog pristupa.
Jedan od zahteva koji mora da ispuni novi IS jesu zatevi korisnika (koji je obino i
investitor). Ispunjenost korisnikovih zahteva smatra se najbitnijim kriterijem uspenosti
rada na razvoju novog IS.U odnosu na linearni pristup u evolucijskom pristupu dolazi se

bre do opipljivih rezultata rada. Evolucijski pristup jae i neposrednije animira korisnika u
procesu definisanja i razvoj IS.
Vei deo vremena na razvoju IS potroi se na projektovanje i izradu programa.
Dosta je teko unapred precizno predvideti potrebno vreme i sredstva za izradu programa,
to oteava utvrdjivanje vrednosti projekta. Razvoj IS prema evolucijskom pristupu (po
delovima) daje mogunost naruiocu i izvodjau projekta ugovaranje posla po delovima i
korigovanje svoje procene o (ne)isplativosti nastavka saradnje. Kvalitetnim parcijalnim
rezultatima izvodja projekta poveava interes korisnika sistema za nastavak rada na
razvoju IS. Prethodno su navedene neke prednosti evolucijskog pristupa u odnosu na
linearni pristupp u razvoju IS. Medjutim kod velikih IS (npr. Privredna grana, velika radna
organizacija) primena samo evolucijskog pristupa ne bi dala zadovoljavajue rezultate.
Definisanje jedinstvenog modela podataka i osnovnih funkcija sistema treba izvriti
na nivou celog sistema i malo je verovatno da se to moe postii parcijalnom
informatizacijom. Zbog toga se preporuuje da se razvoj sloenih IS zapone globalnom
analizom probleema (ciljeva) i naina njihovog reavanja (tj. izbvodljivost sistema) te
analizom funkcija samog sistema. Dakle treba otpoeti prema linearnom pristupu.
Zbog opsenosti sistema i potrebnih investicija, kao i zbog vanosti to breg
postizanja upotrebljivih rezultata razvoj je prikladno nastaviti prema evolucijskom
pristupu.
Evolucijski pristup u razvoj IS naziva se i metoda pokuaja i promaaja. Medjutimi
to ni u kom sluaju ne treba shvatiti doslovno je doslovna primena takve metode
predstavlja jedan od najgorih naina reavanja problema. Svaki korak evolucije funkcije
treba da obuhvati definiciju i analizu problema, izradu projekta i programsku realizaciju
funkcije. Dakle, evolucija funkcije je iterativna. Medjutim rad na svakom koraku iteracije
treba slediti faze iz linearnog pristupa, jer u suprotnom evolutivni proces moe potrajati
nedopustivo dugo.
Kao zakljuak moemo rei da se linearni i evolucijski pristup u razvoju IS ne
iskljuuje, ve se medjusobno kombinuju kako je opisano. Mogunost primene pojedinog
od tih pristupa zavisi od vie faktora: opsenosti i sloenosti sistema, tehnoloke i
organizacione razvijenosti.

1.3.13. METODA PROTOTIPA

U okviru evolucijskog pristupa razvoja Is vano mesto ima primena metode
prototipa. esto se upraksi evolucijski pristup naziva ili izjednaava sa metodom
prototipa.
Prototipom se naziva prvi primerak nekog proizvoda. Time se pokazuje mogunost
izrade novog proizvoda, daje osnova za utvrdjivanje operativnih karakteristika i cena
korienja proizvoda. Po pravilu takav proizvod nije namenjen upotrebi, ve samo
predtsavlja pokusj koji prethodi izradi upotrebljivog proizvoda.
Izradi IS moe prethodoto izrada njegovog prototipa. Prototip IS realizuje samo
osnovne funkcije IS, zanemarujui pri tome detalje (npr: obrada greaka, izvodjenje
podfunkcija). Obuhvatajui ulaze i izlaze sistema protoitp omoguava korisniku i
investitoru da pre stvarne realizacije ilustruje, demonstrira, omogui ispitivanje
mogunosti realizacije nikih od zahteva korienja budueg IS. Takav prototip moe biti
izradjen u bilo kojoj fazi linearnog pristupa u razvoju Is.
U evolucijskom pristupu prototip predstavlja prvi predlog konanog proizvoda koji
evolucijom na kraju postaje upotrebljiv. Uoava se sutinska razlika uloge prototipa u
prethodna dva sluaja. U prvom se prototip koristi za demonstraciju i istraivanje sistema,
dok se u drugom sluakju protoitp razvija u sam operativni deo tog sistema.
Izrada prototipa zahteva utroak vremena i sredstava. Kada prototip obavlja
funkciju na zadovoljavajui nain logino je da ga je bolje doraditi nego pristupiti izradi
novog reenja. Takva mogunost se najee javlja kada se prototip odnosi na neku
ogranienu manju funkciju sistema.
Zato je ta uloga prototipa namenjena u evolucijskom pristupu razvoju IS, gde se
sistema razvija po pojedinim manjim funkcijama.

Kod linearnog pristupa u razvoju IS prototip se obino primenjuje za demonstraciju

i ispitivanje nekih funkcija sistema na globalnom nivou sistema. Takav prototip je obino
daliko od stvarne i konane realizacije i ne evoluira direktno u gotov proizvod.

1.3.14. ALATI ZA PROJEKTOVANJE INFORMACIONIH SISTEMA

Izloeni metodoloki pristup moe se realizovati runo mada sve njegove prednosti
dolaze do izraaja u projektovanju IS uz pomo raunara, odnosno ukoliko metodologija
obuhvata automatizovana sredstva pomou kojih e se izabrati model i metodoloke
preporuke moi da realizuju i koji e omoguiti analitiarima, projektantima i korisnicima
da:
formiraju BP,
da brzo i potpuno otkriju nekonzistentnost, nepotpunost i protivrenost
opisa,
da pomou rutem izvetaja dokumentuju IS na bilo kom nivou apstrakcije,
na njima najpogodniji nain,
da ugrade razliite automatske i automatizovane metode logikog i fizikog
projektovanja BP i programa budueg IS,
da omogui automatizovano generisanje simulacionih programa pomou
kojih e se evaluirati projekltna reenja u odnosu na raspoloive resurse,
da omogui automatizovano generisanje prototipa budueg IS, da bi se
evaluirala konkretna reenja u odnosu na postavljene zahteve, odnosno prikazalo ta e
korisnik stvarno dobiti,
da poslui kao prirodni semantiki bogat interfejs za komunikaciju korisnika
sa IS,
da aktivno povezan sa IS formira jedan adaptivni (samoorganizujui) IS, koji
e na osnovu izmene okline i merenja svojih performansi, jednostavno i automatizovano
menjati svoju strukturu i svoje karakteristike,
da omogui korisnicima jednostavan i produktivan razvoj sopstvenih
aplikacija.
Raunarom podrano softversko inenjerstvo poznato je danas pod nazivom CASE
(Computer Aided Software Engineering).
Softverski inenjering (software engineering) obuhvata poslove inicijalizacije,
projektovanja, realizacije i prodaje softverskog proizvoda, te rukovanja svim resursima
koji su vezani za taj proizvod. Dakle softverski i nenjering obuhvata iri skup aktivnosti
posebno rukovodnih od samog projektovanja i realizacije IS.
CASE aleti su svi alati zasnovani na primeni raunara kao podrci u procesu
softverskog inenjerstva.
Osnovni ciljevi primene CASE alata su:
poveanje produktivnost projektanata,
skraivanje vremena izrade projekta,
poveanje kvaliteta dobijenog programskog proizvoda.
Primena CASE alata zahteva doslednu primenu metodologije koju podrava alat uz
primenu raunara. Korienje CASE alata je interaktivno, uz naglasak na korienje
raunarske grafike.
Razmotrimo malo detaljnije karakteristike i aspekte primene CASE alata u razvoju
IS.
Horizontalna zastupljenost odredjuje broj pokrivenih podruja u posmatranoj fazi
razvoja IS. Ako je broj pokrivenih podruja vei to je i CASE alat bolji.
Vertikalna zastupljenost odredjuje broj pokrivenih faza razvoja u posmatanom
podruju razvoja IS. Ako je broj pokrivenih faza razvoja vei to je i CASE alat bolji.
Kvalitet horizontalne i vertikalne zastupljenosti se ocenjuje prema stepenu
vertikalne i horizontalne integrisanosti. Vertikalno integrisani CASE alati podravaju jedno
ili vie podruja razvoja IS tako da je mogu jednostavan prelazak iz jedne u drug fazu
razvoja (npr. da se u podruju podataka mogu povezati opisi podataka u fazi analize i
dizajna sistema sa opisima u fazi implementacije).

Horizontalno integrisani CASE alati podravaju jednu ili vie faza razvoja IS tako da
su podruja razvoja medjusobno povezana.
Izbor CASE alata odredjen je pre sveg izborom metodologije projektovanja IS. CASE
alati koji obuhvataju sve faze razvoja IS jednom metodom su retki. ei sluaj je da CASE
alat sadri vie tehnika sa veim ili manjim stepenom integrisanosti.
U praksi je naalost est sluaj da korisnik bez prethodne usbvojene metodologije
projektovanja IS nabavlja CASE proizvod nakon ega na osnovu tehnika koje mu nudi
CASE alat formira metodoligiju projektovanja.
Zavisno od toga da li podravaju samo pojedine zadatke, pojedine faze ili ceo
ivotni ciklus u razvoju IS koriste se sledei termini za blie odredjene CASE alata:
CASE tool (alati za automatizaciju jednog koraka),
CASE toolkit (alati za automatizaciju jedne faze ivotnog ciklusa),
CASE workbench (alti za automatizaciju kompletnog ivotnog ciklusa),
CASE environment (alati sa hardversko podrkom za automatizovano
projektovanje).
Takodje, dananje CASE alate moemo klasifikovati u sledee tipve:
alati za modeliranje struktura podataka,
alati za izradu dijagrama toka podataka i hijerarhije modula,
alati za izradu prototipa korisnikog interfejsa,
generatori koda.
U poslednjih nekoliko godina, velika panja se poklanja izradi CASE alata koji bi
obuhvatali ceo proces projektovanja IS. Primena takvih alata bi doprinela da
projektovanje bude na vreme i efikasno obavljeno, bez preskakanja metodolokih koraka i
prema zahtevima korisnika. Time bi se poveala pouzdanost i kvalitet programskog
proizvoda.

1.3.15 .Metoda BSP za planiranje razvoja informacionog sistema

Prva faza u procesu razvoja IS predstavlja kao to je ve reeno strateko planiranje
IS. U okviru stratekog planiranja sistem se posmatra na najviem nivou hijerarhije sa
definisanjem osnovnih podsistema i njihovih veza, prioriteta njihovog projektovanja i
uvodjenja, to predstavlja plan razvoja IS. Nakon toga pristupa se detaljnom projektovanju
svakog podsistema.
U tradicionalnom pristupu razvoja IS odmah se pristupalo projektovanju i uvodjenju
podssistema (pristup od dna ka vrhu) bez prethodnog projektovanja ope strukture celog
IS to je kasnije uzrokovalo probleme u integraciji podsistema.
Za iradu plana razvoja IS postoji vie metoda ali se najee primenjuje metoda BSP
firme IBM koju emo ovde ukratko izloiti.
Osnovni pristup metode BSP je planiranje i analiza odozgo na dole (top-down),
projektovanje i uvodjenje od dna ka vrhu (bootom-up).
Strateki pristup BSP metode je:
1.
Definisanje opte arhitekture IS na osnovu poslovnih procesa kao relativno
najlabijih komponenti realnog sistema (za razliku od organizacione strukture, naina
upravljanja i odluivanja koji mogu biti relativno brzo promenljivi).
2.
Model podataka kao osnova IS, koji tretira podatke kao posebne resurse u
sistemu.
Ciljevi BSP metode su:
ukljuiti najvie rukovodstvo u izradi plana IS,
ciljevi Is direktno podravaju ciljeve poslovanja,
razumevanje poslovanja sa stanovita najvieg rukovodstva,
pristup odozgo na dole u planiranju IS, implementacija odzdo na gore,
kreiranje plana izgradnje integrisane arhitekture,
aktivno rukovodjenje resursima IS,
podaci su osnovni resurs poslovnog sistema.
BSP metoda predlae sledee aktivnosti koje treba izvesti kod nene primene:
1.
Davanje saglasnosti,
2.
Priprema za sturiju,
3.
Odravanje prvog radnog sastanka,

4.
Definisanje poslovnih procesa,
5.
Definisanje klasa podataka,
6.
Analiza postojeeg IS,
7.
Analiza rezultata problema i koristi,
8.
Definisanje arhitekture IS,
9.
Odredjivanje prioriteta,
10.
Razrada plana realizacije.
Aktivnosti BSP metode izvravaju se u navedenom redosledu. Za svaku pojedinu
aktivnost primenjuje se jedna ili vie razliitih metoda.
BSP metoda nije znaajnije integrisana sa ostalim metodama za izradu glavnih i
izvodjakih projekata te su njeni rezultati zanemareni u kasnijim fazam. Neki rezultati i
nalazi dobijeni primenom BSP metode ponovo se kasnije produbljuju i detaljnije opisuju
to nije uvek potrebno.
1.
Davanje saglasnosti
Da bi se u nekoj organizaciji pristupilo izradi plana razvoja IS, potrebno je:
upoznati najvie rukovodstvo sa ciljem plana razvoja IS,
odabrati projektanta i potpisati ugovor o projektu,
dobiti saglasnost najvieg rukovodstva, de e se dati na raspolaganje:
dokumentacija, izvrioci i dr. (to se vidi iz ponude i ugovora).
2. Priprema za studiju
Izvravaju se sledee aktivnosti:
detaljno definisanje aktivnosti za izradu cele studije,
izrada vremenskog plana izvravanja aktivnosti,
odredjivanje lanova tima i njihovog zaduenja,
upoznavanje realnog sistema,
obuka lanova tima BSP metodi,
odredjivanje ljudi koji e biti intervjuisani,
prikupljanje statuta, pravilnika, ifarnika i sl.
Priprema prvog radnog sastanka.
3. Odravanje prvog radnog sastanka
Prvom radnom sastanku prisustvuju:
lanovi tima iz spoljnih institucija,
lanovi tima iz organizacije,
najvie rukovodstvo organizacije,
ljudi iz organizacije koji e biti intervjuisani,
administrator projekta iz organizacije.
Sastank otvara najvii rukovodilac organizacie koji predstavlja prisutne i izlae
ciljeve sastanka.
Rukovodilac studije izlae sledee teme:
Tema 1.
Ciljevi studije
Oekivani rezultati
Perspektive realizacije studije
Tema 2.
Karakteristike organizacije
Perspektive organizacije
Mogue tekoe u iradi studije
Tema 3.
postojei IS
Prvi radni sastanak mora biti detaljno isplaniran. Na kraju sastanka uesnici mogu
postavljati pitanja.
4.

Definisanje poslovnih procesa

Definisanje poslovnih procesa je jedne od osnovnhi i najvanijih aktivnosti u BSP
metodi. Osnovni rezultat ove aktivnosti treba da bude lista i opis svih procesa i
identifikacija onih koji su kljuni za uspeh cele organizacije.
Poslovni proces je grupa logiki povezanih odluivanja i aktivnosti neophodnih za
upravljanje nekim resursom poslovnog sistema.
Prema BSP metodi daje se preporuka za klasifikacijuu procesa tri grupe:

1.
Procesi planiranja i upravljanja,
2.
Procesi proizvodnje i usluga,
3.
Pomini procesi.
Procesi proizvodnje i usluga i pomoni procesi definiu se preko sledeih faza
ivotnog ciklusa:
Faza 1: Planiranje,
Faza 2: Proizvodnja i tehnologija,
Faza 3: Praenje proizvodnje,
Faza 4: Zatvaranje ciklusa.
Poni procesi su procesi upravljanja osnovnim resursima (materijal, novac, oprema,
kadrovi) koji se koriste u poslovanju.
Sve procese treba kratko opisati tako da je svakom lanu tima sasvim jasan svaki
proces.
Kada se procesi sve tri grupe identifikuju vri se njihova analiza i konsolidacija.
Eleminiu se nekonzistentnosti, kombinuju se slini procesi i grupiu u grupe procesa.
Grupe procesa predstavlja agregaciju slinih procesa. Iskustvo je pokazalo da je i
najsloenijim sistemima dovoljno definisati oko 60 razliitih procesa grupisanih u 4-12
grupa.
Za jednu tipinu proizvodno-poslovnu radnu organizaciju grupe procesa mogu biti:
Planiranje
Proizvodnja
- strategijsko planiranje
- terminiranje i lansiranje
- istraivanje trita
- upravljanje zalihama
- ekonomske analize
- upravljanje proizvodnjom
- predvidjanje
- pakovanje
- planiranje resursa
- odravanje
- kontrola kvaliteta
- otprema
Razvoj proizvoda
- istraivanje
- licence
- projektovanje

Finansije
- finansijsko planiranje
- finansijksa analiza
- raunovodstvo
-lini dohodci

Marketing
Administracija
- predvidjanje prodaje
- kadrovska funkcija
- reklama
- zakoni, zapisnici
- odredjivanje cena
- informisanje
- ugovaranje
- prodaja
- analiza prodaje
Da bi se proverila identifikacija i opis proces, odredili ljudi koji e jo biti
intervjuisani o odredjenim procesima, otkrila eventualna preklapanja u zaduenjima i
odluivanju formira se matrica odnosa poslovnih procesa i organizacije.
5 Definisanje klasa podataka
Klasa podataka je skup logiki povezanih podataka (npr. podaci o kupcu, proizvodu,
narudbi). Jedan od klunih koraka BSP metode je upravo identifikovanje klasa podataka.
Postoje sledea dva pristupa za identifikovanje klasa podataka:
1.
Povezivanje podataka sa poslovnim entitentima,
2.
Na osnovu definisanih poslovnih procesa.
Entitet se definie kao posebnost (objekt, stvar, koncept, dogadjaj), neto to se
jasno razlikuje od drugih entiteta u sistemu. Pri identifikovanju entiteta u poetnoj fazi
pogodno je primeniti postupak generalizacije definiui opte tipove entiteta, delei ih
kasnije postepeno u posebne kategorije. Na najviem nivou generalizacije na primer
entiteti mogu biti:
predmeti poslovanja,
subjekti poslovanja,
partneri u poslovanju,

obaveze u poslovanju,
transakcije za realizaciju poslovanja.
Zatim se na prime, predmeti poslovanja dele na proizvode, opreme i usluge,
subjekti poslovanja su organizacione jedinice, obaveze u poslovanju su ugovori i planovi,
transakcije su trebovanja, narudbe, fakture itd.
Identifikovanje klasa podataka analizom poslovnih procesa postie se
posmatranjem ulaznih i izlaznih podataka procesa. Svaki ulaz i izlaz iz procesa moe biti
klasa podataka. S obzirom da ulazni i izlani izvetaji ne predstavljaju klase podataka
potrebno ih je jasno identifikovati.
Kad se definiu klase podataka formira se matrica odnosa poslovni procesi/klase
podataka kao krajnji rezultat ove aktivnosti.
Matrica procesi/klase podataka predstavlja osnov za dalje projektovanje IS: u njoj
je prvi put sagledan sistem kao celina i moe se nazreti arhitektura budueg IS:
6.
Analiza postojeeg informacionog sistema
U ovoj fazi BSP metode treba analizirati:
kako postojei IS podrava poslovanje,
koliko su pojedine organizacione jedinice podrane postojeim aplikacijama,
kako postojee aplikacije koriste podatke da bi se uoile redundanse.
7.
Analize rezultata, problema i koristi
U ovoj fazi se kroz niz intervjua proveravaju rezultati predhodnih faza utvrdjuju osnovni
poslovni problemi, naini njihovog reavanja, redosled uvodjenja pojedinih modula,
potencijalne koristi. Intervjue treba voditi sa unapred odabranim rukovodiocima i adekvatno
pripremljenim pitanjima. Prilikom intervjua rukovodioce treba upoznati sa identifikovanim
poslovnim procesima, organizacijom i klasama podataka. Za procenu znaaja i potencijalnih
koristi u reavanju pojedinih problema trae se odgovori na niz pitanja kao to su:

Navedite tri najvea problema u ostvarivanju ciljeva u poslovima kojima se bavite?

ta vas spreava da ih reavate?

Koju bi vrednost imalo bolje informisanje za reavanje tih problema?

Koja je najvrednija informacija koju dobijate ili elite?

Problemi se grupiu po kategorijama, procesu uzroka ili po nekom drugom
kriterijumu (mogue je formirati odredjeni skup matrica za pomo u analizi intervjua).
Poto se grupiu problemi se dele na one koji se mogu reiti i one koji nisu reivi podrkom
IS.
8.
Definisanje arhitekture informacionog sistema
Opta arhitektura IS definie se na osnovu odnosa procesa i klasa podataka koji su
utvrdjeni u prethodnim fazama. Matrica procesi/klase podataka se transformie na sledei
nain:

Vrste, imenovane procesima, uredjuju se u skladu sa ivotnim ciklusom

stavljajajui na poetak one procese koji pripadaju prvim fazama ivotnog ciklusa.

Kolone, imenovane klasama, podataka uredjuju se tako da prva kolona bude ona
druga klasa podataka koju kreira prvi proces, sledea koju kreira drugi proces itd.
Na taj nain se dobija po pravilu matrica dijagonalna po blokovima u kojima se
grupiu klase podataka i procesi koji ih kreiraju i koriste. Takvi blokovi predstavljau
podsisteme.
9.
Odredjivanje prioritata
Prema unapred zadatim kriterijumima za svaki podsistem utvrdjuje se vrednost
njegove automatizacije ime se dobija rangiranje podsistema po prioritetu.
Kriterijumi za odredjivanje vrednosti automatizacije podsistema su:
1.
Potencijalna korist(procena iz intervjua)
2.
Uticaj na poslovanje

broj radnika i obuhvaenih organizacionih jedinica,

kvalitativni efekti,

efekti na ostvarenje optih ciljeva.

3.
Procena uspeha realizacije
1.
prihvatljivost,
2.
trajanje implementacije,
3.
raspoloivi resursi.
4.
Potranja

vrednost postojeeg sistema,

veze sa drugim sistemima,
politiki razlozi
Za svaki podsistem i svaki kriterijum odredjuje se ocena od 1 do 10 i izraunava
ukupna ocena za podsistem. Na taj nain podsistem se uredjuje po ukupnoj oceni na
osnovu ega se moe odluiti o redosledu uvodjenja podsistema.
4.
Razrada plana realizacije
Zadnja aktivnost je izrada dugoronog plana realizacije IS na osnovu utvrdjenih
prioriteta, logike uvodjenja pojedinih podsistema, raspoloivih resursa i drugih specifinih
uslova. Plan predstavlja sintezu svih predhodnih istraivanja sa jasnim prikazom najviem
rukovodstvu kako upravljati razvojem IS.
Moe se zakljuiti da nema te organizacije, tog sistema kome nije potreban
dugoroan plan razvoja IS, bez obzira koliko je organizacija velikla, koliko je opremljena
informacionim tehnologijom, kakav IS ima, koji su joj poslovni ciljevi.
Viegodinje upravljanje sistemom na slepo isti pre ili kasnije dovodi do velikih
potekoa.