Page 11 - 003_it

14.1 KONCEPT @IVOTNOG CIKLUSA RAZVOJA SISTEMA 615

FAZA 6: FUNKCIONISANJE. Posle uspe{ne konverzije sistem }e funkcionisati
neodre|en period vremena, sve dok ne postane neadekvatan ili nepotreban, ili
finansijski neprihvatljiv.

FAZA 7: EVALUACIJA POSLE REVIZIJE. Organizacija bi trebalo da procenjuje sve
svoje ve}e projekte sistema po njihovom zavr{etku. Ovim postrevizijama uvodi se
dodatni element discipline u razvojni proces. Ako je implementacija bila uspe{na,
revizija treba da se obavi po stabilizovanju operacija sistema. Ako je projekat pretrpeo
neuspeh, revizija treba da se obavi odmah.
Mnoge organizacije ne sprovode formalnu evaluaciju svojih projekata sistema.
One ne vide potrebu za ulaganje dodatnog napora ako je sistem bio uspe{an i radije
bi da se slu~aj zaboravi ako je bio neuspe{an. Me|utim, ove procene su zna~ajne.
Povratna informacija po izvr{enom upore|ivanju stvarnih performansi sa specifiko-
vanim mo`e da pomogne analiti~arima da nau~e da prave bolje procene u budu}im
projektima. Identifikovanje uzroka neuspeha mo`e da pomogne IS grupama da
izbegnu iste probleme na slede}im sistemima.

FAZA 8: ODR@AVANJE. Svakom sistemu su potrebne dve vrste odr`avanja:
otklanjanje gre{aka i redovno a`uriranje. Gre{ke su mnogo ~e{}e na po~etku,
ali problemi mogu da se pojave i posle vi{e godina. Pored otklanjanja gre{aka,
programerima je potrebno da a`uriraju sisteme da bi se prilagodili promenama u
okru`enju. Primeri se sastoje od prilago|avanja izmenama u poreskom zakonu i
re{avanja problema „Godina 2000”. Ove korekcije i a`uriranja obi~no ne doprinose
dodatnoj funkcionalnosti; one su prosto neophodne da bi se funkcionisanje sistema
zadr`alo na istom nivou.
Dodatna forma odr`avanja dodaje nove karakteristike postoje}im sistemima.
Ovaj posao je donekle sli~an razvoju novih sistema; me|utim, on je komplikovaniji
i manje fleksibilan zato {to nove karakteristike moraju da budu instalirane, tako
da ne remete rad postoje}eg sistema.
Nezavisno od tipa sistema odr`avanje je skupo i dosti`e nivo od 80% organiza-
cijskog IS bud`eta. Zbog toga je va`no da projektovanje i razvojne faze proizvedu
sisteme koji uklju~uju, u inicijalnim verzijama, svu potrebnu funkcionalnost.
Da bi neophodno odr`avanje bilo jednostavnije, projektant bi trebalo da koristi
odgovaraju}e metodologije softverskog in`enjeringa i sa~ini dobru dokumentaciju
za sistem.

Tradicionalne Postoje dva osnovna problema kada su u pitanju metodologije `ivotnog ciklusa
metodologije razvoja sistema. Kao prvo, mnogi projekti sistema do`ive neuspeh, iako upravljanje
nasuprot projektom sadr`i formalan SDLC pristup. Kao drugo, okru`enje se veoma razlikuje
modernim SDLC od onog od pre 30 godina. Informaciona tehnologija je mnogo mo}nija i zahvaljuju}i
metodologijama opremi kao {to su grafi~ki korisni~ki interfejsovi i klijent/server arhitektura, veoma
razlikuje se od ranijih formi programiranja.
Da li ovi problemi zna~e da menad`eri projekata treba da napuste SDLC koncept?
Zapravo ne. Sve faze prikazane na slici 14.1 (strana 610) jo{ uvek su ili apsolutno
potrebne ili krajnje po`eljne za velike projekte. Gore opisane prednosti su jo{ uvek
zna~ajne. Slo`enost sistema koji se i dalje razvija zna~i da je neka forma strukture
~ak potrebnija sada nego pre 30 godina. Me|utim, osnovna organizacija SDLC treba
da se promeni da bi se prilagodila realnosti sada{njeg okru`enja. IS grupe koje raz-
matraju primenu formalne SDLC metodologije i alata koji se koriste za upravljanje
projektima trebalo bi sada da te`e da ostvare slede}e karakteristike: