Page 10 - 003_it
P. 10
614 POGLAVLJE 14 IZGRADNJA INFORMACIONIH SISTEMA
u fazi logi~kih analiza i projektovanja. Analiti~ari jo{ uvek imaju potrebu da iden-
tifikuju korisni~ke zahteve. Me|utim, oni tro{e mnogo vi{e vremena na pore|enje
zahteva sa karakteristikama dostupnog softvera, a manje na projektovanje sistema.
Oni treba da pripreme detaljnu specifikaciju samo kada funkcionalnost koja je
potrebna korisniku nije dostupna preko softvera na tr`i{tu. Oni tako|e moraju
da identifikuju zahteve u pogledu konfiguracije za komercijalne pakete koji nude
{irok opseg opcija za prilago|avanje po `elji.
FAZA 4: STVARNA NABAVKA ILI RAZVOJ. Logi~ki projekat novog sistema
poma`e stvarni razvoj ili nabavku, ba{ kao {to crte`i poma`u izgradnju nove zgrade.
IS osoblje koristi specifikacije za kupovinu hardvera i softvera neophodnog za sistem
i za pravljenje potrebne konfiguracije. Programeri pi{u programe za delove sistema
gde komercijalni izvori nisu odgovaraju}i. Tehni~ko osoblje pravi dokumentaciju i
materijale za obuku. IS osoblje testira sistem, a korisnici bi tako|e trebalo da izvr{e
neke testove pre definitivne implementacije. Testiranjem se identifikuju gre{ke, a
porede se i performanse sistema sa specifikacijama u projektu.
FAZA 5: IMPLEMENTACIJA. Implementacija je o~igledno zna~ajna faza; sistem
mo`e da zataji u ovoj ta~ki ~ak i ako je funkcionalan. Projektni tim bi trebalo
da planira implementaciju vrlo pa`ljivo da bi se izbegli problemi koji mogu da
dovedu do otpora. Korisnicima je potrebna obuka u pogledu mehanizma sistema
da bi se smanjila nervoza i da bi se gubici u proizvodnji u periodu tranzicije sveli
na minimum. Pored razvijanja tehni~kih sposobnosti, obuka bi tako|e trebalo da
poku{a da motivi{e korisnike, na primer, tako {to bi nagla{avala prednosti sistema
za organizaciju.
^ak i pod najpovoljnijim okolnostima, u procesu implementacije izlaze na videlo
gre{ke i drugi neo~ekivani problemi. Tim za implementaciju treba da razre{i ove
probleme {to je mogu}e br`e, da sa~uva kredibilitet u odnosima sa korisnicima i
da nastavi sa konverzijom.
U ve}ini slu~ajeva implementacija novog sistema zahteva konverziju iz prethodnog
sistema. Pristupi konverziji su slede}i:
• Paralelne konverzije. Stari i novi sistem rade istovremeno tokom testiranja,
a zatim se stari sistem ukida. Paralelna konverzija je najsigurniji pristup, ali
i najskuplji.
• Direktno presecanje. Stari sistem se isklju~i, a novi sistem se uklju~i. Ovo
direktno presecanje je najbr`i i najjeftiniji pristup, ali nosi i najve}i rizik.
• Probna konverzija. Novi sistem se implementira na nekoliko lokacija – na
primer, u nekim od ekspozitura u velikom lancu banaka – i vremenom se
pro{iruje na preostale lokacije. Pristup tipa probne konverzije je kao direktno
presecanje za lokaciju na kojoj se obavlja testiranje, ali je za organizaciju u celini
sli~an paralelnoj konverziji. Pri tome su i rizici i tro{kovi relativno mali.
• Fazna (ili modularna) konverzija. Velike sisteme ~esto izgra|uju razli~iti
„moduli”. Na primer, sistem za isporuku porud`bina bi mogao da ima modul
zaliha, modul za obradu porud`bina i modul koji mo`e da prima ra~une. Da
su moduli prvobitno bili projektovani kao relativno nezavisni, bilo bi mogu}e
zamenjivati module jedan po jedan. Fazna konverzija je verovatno bezbednija
nego direktna konverzija ali traje du`e i mo`e da zahteva vi{e testiranja zato
{to je neophodno testirati druge delove sistema svaki put kad se novi modul
implementira.