You are on page 1of 12

1 uloga informacionih tehnologija u poslovnim sistemima Razvoj poslovnih informacionih sistema nije posljedica jednog vakuuma u globalnom poslovnom

okruenju. Naime, svaki projekt informacionih sistema treba konzistentno da odgovara i da je usklaen s globalnim poslovnim planovima i ciljevima kompanije. Top do!n pristup u planiranju projekata informacionih sistema zapo"inje na strate#kom nivou management a, kada se utvruje TA treba biti uraeno. $vakav pristup se, zatim, nastavlja na takti"kom nivou management a kada dolazi do transformacije TA u KAKO uraditi. %ona"no, na operativnom nivou management a dolazi do IMPLEMENTACIJE informacionih sistema u skladu s globalnim poslovnim planom. Top do!n pristup po"inje s determiniranjem marketin#kih strategija kompanije, kojim je obuhva&eno utvrivanje najniih tro#kova, diferencijacije'jedinstvenosti proizvoda i'ili usluga, tri#ne ni#e i tri#nih barijera. (vaka od ovih strategija zahtijeva raznovrsan set tehnolo#kih taktika i informacionih sistema. )laniranje informacionih sistema se odvija unutar jednog spektruma koji obuhva&a odravanje, reinenjering, importaciju sistema, pa sve do takti"kog i strate#kog odreivanja prioriteta. $va posljednja faza se moe realizirati posredstvom jednog struktuiranog pristupa nazvanog poslovno informaciono planiranje. )oslovno informaciono planiranje je bazirano na #est koraka kako slijedi* uspostavljanje mission statement a, utvrivanje strate#kih jedinica, definiranje kriti"nih faktora uspjeha, utvrivanje informacionih sistema koji se name&u kao neophodni, status i budu&e projekcije aktualnih industrijskih i tehnolo#kih trendova, kategorizacija potencijalnih projekata informacionih sistema i, kona"no, uspostavljanje strategije razvoja informacionih sistema. )rojekti informacionih sistema se identificiraju u odnosu na doprinos i potporu globalnom poslovnom planu i variraju u svojoj kompleksnosti od onih koji su namjenjeni za odravanje, preko modifikacija, pro#irenja, zamjene pa sve do uvoenja odnosno razvoja novih sistema. %oji &e od ovih projekata informacionih sistema diktirati budu&e aktivnosti i kojim &e se redoslijedom pristupiti u realizaciji ovisi od slijede&ih okolnosti'kondicija* #tednja u odravanju sistema "ime se uticalo na adekvatnost istog, odbijanje projekata koji ne doprinose poslovnom planu, kao i aktualno stanje koje se odnose na resursna ograni"enja +analiti"ari i drugi informati"ki specijalisti, vrijeme, potrebna finansijska sredstva, tehnolo#ke aktualnosti itd.,. $djel za informacione sisteme je taj koji je odgovoran za razvoj ciljanih informacionih sistema. -sto tako, on je taj koji odlu"uje u odabiru orjentacije i odgovornosti pojedinih projekata informacionih sistema, a nije zaduen za njihovu promociju i #irenje primjene. $djel za informacione sisteme je uobi"ajeno organiziran u formi sektora za razvoj sistema, odravanje sistema, ra"unarske i korisni"ke podr#ke. $djel za informacione sisteme se suo"ava s nekoliko najvanijih problema koji se ogledaju u alternacijama pozicije $djela za informacione sisteme unutar organizacije kompanije, koje se ogledaju kroz centralizacija naspram decentralizacija, usklaenost ciljeva $djela za informacione sisteme s globalnim strate#kim ciljevima kompanije, interkonekciju i povezanost heterogenih sistema, struktuirane metodologije, kao i sam transfer tehnologije. Razvoj informacionih sistema je, ve&inom, organiziran kroz timove koji, u posljednje vrijeme, sve vi#e uklju"uju i one eksperte koji su izvan $djela za informacione sisteme. Najvaniji "lan razvojnog tima je sistem analiti"ar.

2 informacije i informacioni sistemi


.ta je entitet nazvan informacija zbog kojih dolazi do dizajna poslovnih sistema, njihovog mjenjanja i'ili zamjene/ 0edan prihvatljiv odgovor bi bio da je informacija, u su#tini, jedno opserviranje dogaaja, +transakcijskih podataka,, konvertovanih i pripremljenih, posredstvom obrade podataka, za neku odreenu namjenu. Takva odreena namjena je, opet, detekcija problema i rje#enje za saniranje istog. )roces dono#enja odluke je vaan segment ciklusa rje#avanja problema. -nformacije posjeduju karakteristike koje variraju u zavisnosti od razli"itih organizacijskih nivoa, kao #to variraju metode kori#tenja informacija. 1ontinuum informacionih sistema zapo"inje od sistema za obradu transakcija 2 T)(, preko sistema za podr#ku management a 2 3-( do ekspertnih sistema 2 45(, sistema za podr#ku procesa odlu"ivanja 2 6(( i izvr#nih informacionih sistema 2 4-(. (truktura za ovakav continuum informacionih sistema je bazirana na ciklusu rje#avanja problema. T)( je zajedni"ki i primjenjiv za ve&inu poslovnih sistema, posjeduju&i jednu standardiziranu strukturu koja obuhvata* izvorni dokument, kodiranje, izbor izmeu 7batch7 ili 7real time7 obrade, metod unosa transakcija, editiranje transakcijskih polja, metod pristupa i uvida u zapise, auriranje zapisa, dokumente o izvr#enoj akciji, izvje#taje s transakcijskim detaljima, izvje#taje o statusima resursa i izvje#taje za management.

3 zivotni ciklus informacionih sistema


(vi sistemi moraju 7 umrijeti7, bez obzira da li se radi o biolo#kom, organizacijskom ili, pak, o informacionom sistemu. 8bog toga, svi sistemi, uklju"uju&i i informacione sisteme, prolaze kroz jedan prediktibilan ciklus aktivnosti tokom njihovog 7ivota7 odnosno postoji jedan ivotni ciklus'vijek sistema. )oslovne kompanije su zainteresirane za dva tipa ivotnih ciklusa informacionih sistema. (trate#ki ivotni ciklus obuhvata razvoj cjelokupne kompanije i na"in na koji koristi informacijske resurse. Takti"ki ivotni ciklus, u svom domenu, podrazumijeva razvoj i zamjenu pojedinih sistema. $vdje se, uglavnom, bavilo takti"kim ciklusima informacionih sistema. 9udu&i da, po prirodi stvari, informacioni sistemi jednom okon"avaju s svojim radom 2 7umiru7, mora se razmi#ljati o njihovoj, eventualnoj, zamjeni. Takvo planiranje njihove zamjene mora blagovremeno zapo"eti. )igg:backing, koji potencira zamjenu informacionih sistema na jedan ureen, sistematiziran na"in, mora postati supervizijski mehanizam dizajnera kojim sprije"ava pani"no dizajniranje novih, zamjenskih sistema, do kojeg moe do&i u koliko se zakasni s ovim aktivnostima. Takti"ki dizajn poslovnih informacionih sistema baziran je na fazama analize sistema, dizajnu sistema i implementaciji sistema. Razvojni tok procedure takti"kog dizajna obuhvata jedanaest odvojenih proceduralnih koraka. Nepredviene okolnosti u nekom od proceduralnih koraka mogu dovesti do reverzibilnog procesa u jednom ili vi#e prethodnih koraka u nekoj od faza (6;1 a. <vedeni su i implementirani novi koncepti i tehnike za razliku od konvencionalnog pristupa dizajniranja informacionih sistema. %ao posljedica implementacije istih dolazi do promjena ne samo u broju proceduralnih koraka nego i do kompozicije i sekvencijalnog redoslijeda u glavnim fazama (6;1 a.

4 alati za razvoj informacionih sistema


%oristi se pet klasa alata u razvoju informacionih sistema* 1. =lati dekompozicije koriste top do!n pristup u kojem se vr#i ra#"lamba sistema na najmanje kohezivne module koji posjeduju labavu konekciju s drugim, sli"nim sistemskim modulima >. =lati toka za prezentiranje toka informacija ili fizi"kih resursa izmeu procesa ?. 3atri"ni alati koji omgu&avaju brzo pretraivanje u svrhe pronalaenja odreenih dijelova podataka @. =lati tranzicije koji pokazuju promjene sistema u vremenu A. =lati naracije u struktuiranim formatima, a kojim se podrazumjevaju formulari, ugovorni dokumenti ili neki upitnici kao alternacije grafi"kim alatima. )rezentirana su "etiri razvojna struktuirana alata 2 hijerarhijski dijagrami, dijagrami toka podataka, dijagrami entitet relacija i rje"nik podataka, s njihovim definicijama i uz njihovo razmatranje posredstvom nekih manjih, tipiziranih primjera. Bijerarhijski dijagram je grafi"ki alat kojim se identificiraju svi zadaci ili procesi u sistemu. Nakon identifikacije pristupa se njihovom grupiranju na razli"ite hijerarhijske nivoe. Cormat i organizacija dijagrama hijerarhije je sli"na formi drvo. 6ijagrami toka podataka prezentiraju tok podataka kroz sistem. )ostoje fizikalni dijagrami toka podataka u kojim su obuhva&ene relevantne fizi"ke lokacije, nakon "ega se kreira njihov logi"ki ekvivalent u formi logi"kih dijagrama toka podataka. 6ijagrami toka podataka su veoma pogodni za komunikaciju analiti"ar korisnik, jer su bazirani na samo "etiri lako razumljiva grafi"ka simbola. $snovna namjena dijagrama toka podataka je pra&enje toka podataka na nivou cijelog sistema. )odaci, kao i procesi predstavljaju kriti"ni aspekt u razumjevanju i definiranju sistema. 3odeliranje podataka je, opet, kriti"an aspekt definiranja zahtjeva i dizajniranje sistema. Cizi"ka realizacija modeliranja podataka se manifestira u dizajn baze podataka. )ostavka i razumjevanje informacijskih zahtjeva i aplikacijska vizija baze podataka predstavlja krucijalni aspekt dizajna i uspje#ne implementacije informacionog sistema. 0edna #iroko prihva&ena i kori#tena tehnika modeliranja podataka je zastupljena kroz dijagrame entitet relacija. Rje"nik podataka je jedan repozitorij'skladi#te svih struktura podataka na 7primitive7 nivou i podatkovnih elemenata unutar jednog sistema. %ako i samo ime sugerira, u su#tini, to je jedan katalog svega #to se eli znati o samoj prirodi podataka unutar sistema. Na taj na"in, obuhva&eni su detalji koji se odnose na tip podataka +numeri"ki, alfanumeri"ki, alfabetski itd.,, duinu podataka, metrika i specifi"ne vrijednosti podataka, sve je mogu&e katalo#ki prezentirati u takvom rje"niku podataka. Rje"nik podataka kombiniran s nivovskim setom dijagrama toka podataka daje veoma detaljizirane specifikacije sistema. 6ijagrami toka podataka, upisi rje"nika podataka i strukturni dijagrami u potpunosti dokumentiraju sve sistemske i programske nivoe nekog sistema. ( druge strane, dijagrami entitet relacija daju jedan specificirani pregled podataka u aplikaciji. ( obzirom da rje"nik podataka u potpunosti opisuje podatke velikog broja, ponekad se to mjeri na stotine, odvojenih upisa, njihovim objedinjavanjem dobiva se, zaista, sveobuhvatan pregled podataka unutar sistema. (vi zajedno, ovih pet razvojnih alata oformljavaju jedan impresivan set alata za analiti"are i dizajnere poslovnih informacionih sistema.

5 alati logickog dizajna-programiranja


Drafi"ki alati su veoma vani za komunikaciju izmeu sistem analiti"ara i programera. $ni obuhvataju logiku sistema, programsku organizaciju, alate za sistemske specifikacije i programske specifikacije. =lati za logiku sistema omogu&avaju neposrednu translaciju sistemskih zahtjeva u programski kod. 6va glavna alata za sistemsku logiku su struktuirani 4ngleski i tabele odluke. =lati za programsku organizaciju dopu#taju analiti"arima da planiraju i rasporeuju zada&e programiranja. Takva dva, naj"e#&e primjenjivana alata su hijerarhijski dijagrami i Earnier'$rr dijagrami. =lati za sistemske specifikacije prikazuju tok od jednog informacionog procesa do drugog ili tok logike unutar jednog ra"unarskog programa. $d ovih alata razmotreni su B-)$ dijagrami i sistemski blok dijagrami. =lati za programske specifikacije prikazuju tok zadataka unutar jednog ra"unarskog programa. $vdje su obuhva&eni programski blok dijagrami i Nassi (hneiderman dijagrami.

6 alati i zivotni ciklus razvoja sistema


-nterpretirano je kako se koriste razvojni alati unutar ivotnog ciklusa razvoja sistema. Na osnovu toga, definirani su slijede&i koraci faza analize i dizajna u okviru ivotnog ciklusa razvoja sistema kako slijedi* 1. 3odel postoje&eg fizikalnog sistema $dreivanje komponenti sistema %reiranje hijerarhijskog dijagrama %onstruiranje nivovskog seta fizikalnih dijagrama toka podataka >. 6eriviranje postoje&eg logi"kog sistema 2 nivovski set logi"kih dijagrama toka podataka ?. (pecificiranje novog sistema =naliza zahtjeva 2 ciljevi $grani"enja 3ission statement projekta ;ogi"ki dijagrami toka podataka novog sistema 3odeliranje podataka pomo&u dijagrama entitet relacija @. %reiranje rje"nika podataka A. -ntegracija novog sistema Fetiri razvojna alata su se pokazala naro"ito zna"ajna za faze analize i dizajna unutar ivotnog ciklusa razvoja sitema. To su* hijerarhijski dijagram, dijagrami toka podataka, dijagram entitet relacija i rje"nik podataka.

8 prototipiranje
)rototipiranje je proces brze izvedbe jednog modela kona"nog soft!are skog sistema. )revashodno se koristi kao jedan komunikacijski alat za dostizanje i zadovoljenje informacijskih zahtjeva korisnika. )rototipiranje je do punog izraaja do#lo pojavom i kori#tenjem programskih jezika "etrvte generacije 2 @D;, koji uvode generatore koda ili aplikacija. )rototipiranje se pokazalo uspje#nim, jer su se njegovom primjenom rije#ili problemi koji su se javljali u konvencionalnom razvoju soft!are skih sistema, kada su se koristili jezici tre&e generacije. Razlikuju se dva tipa okruenja prototipiranja* okruenje generatora aplikacija i okruenje bazirano na setu alata ili tzv. radnoj klupi. Najpoznatiji i najra#ireniji tipovi prototipiranja se poznaju pod imenima iterativni Tip - prototip i prolazni Tip -- prototip. -terativni metod je okarakteriziran mjenjanjem i modificiranjem prototipa u skladu s zahtjevima korisnika sve do izvedbe kona"nog sistema. 6rugi, prolazni metod generira prototip koji slui kao model za izvedbu budu&eg finalnog sistema, koji se kodira u jezicima tre&e generacije ili proceduralnim jezicima. $ba tipa prototipiranja su zasnovana na tri sukcesivne faze* Nivo 1 2 ulaz'izlaz, Nivo > 2 heuristika i Nivo ? 2 adaptacija. )rednosti prototipranja podrazumjevaju manji utro#ak vremena u procesu razvoja sistema, pribliavanju, boljem razumjevanju i kori#tenju istog od strane krajnjeg korisnika, smanjenju ljudskog rada u razvoju sistema, reduciranju zaostataka u izvr#enju proceduralnih aktivnosti i pobolj#anju komunikacije korisnik 2 analiti"ar. Nedostaci prototipiranja se prepoznaju u pothranjivanju nerealnih o"ekivanja kod dijela korisnika, inicijalno pokazuju&i ne#to #to korisnik ne&e dobiti u kona"noj fazi i nerealnom ohrabrivanju korisnika u idejama da sam neposredno razvija sistem uz kori#tenje soft!are a raspoloivih generatora aplikacija. Nisu svi sistemi pogodni za prototipiranje. $d dizajnera se zahtjeva da, prije svega, utvrdi da li sistem o kome se radi posjeduje karakteristike koje "ine prototipiranje opravdanim. )rototipovi pobolj#avaju trening korisnika. Njihovom pojavom mogu&e je kreirati prilagoena okruenja koja odraavaju uvjete i termine svojstvene poimanju korisnika. $sim ovog, prototipovi su omogu&ili trening korisnika ve& u ranim fazama ivotnog ciklusa razvoja sistema 2 (6;1. )rijevremenom orjentacijom i familiziranjem korisnika s sistemom, kao povoljnu okolnost donosi uspostava povratne sprege, posredstvom koje je mogu&e integriranje korisnih prijedloga i sugestija za dizajn sistema od strane korisnika. %arakter migracije prototipnog ka okruenju radnog sistema je ekstenzivan. $vo je zbog toga #to se prototip i radni sistem razlikuju u vi#e dimenzija, predstavljenih kroz primjenu razli"itih programskih jezika, ranga transakcija, dokumentacijskih standarda, ra"unarskih arhitektura, kontrole i za#tite pristupa sistemu i prisustvu radnih procedura. 8bog ovakve vi#edimenzijske razli"nosti, nuno je bilo uvoenje nekoliko odreenih taktika kojim bi se olak#ala prelaz s prototipa ka radnom sistemu. )rototipiranje je mo&an pristup u razvoju poslovnih informacionih sistema. (istemi izgraeni kori#tenjem prototipiranja mogu biti veoma uspje#ni ukoliko se dizajneri striktno pridravaju metodologije, provode&i je kroz analizu i definiranje informacijskih zahtjeva, imaju&i na umu zna"aj prevoenja prototipa u radni informacioni sistem.

9 case i drugi alati za podrsku razvoja sistema


(ve donedavno, sistem analiti"ari su ve&inu svog rada i rezultata svog rada obavljali pomo&u papira i olovke. 3eutim, dolazi do ubrzanijeg razvoja ra"unarskih alata koji sistem analiti"aru pruaju veoma dobru i korisnu podr#ku. %ao predominantan produkt automatiziranog razvoja pokazao se 1=(4 2 1omputer =ided (:stems 4ngineering produkt, koji predstavlja jednu kolekciju i integraciju automatiziranih alata i procedura za podr#ku procesa razvoja sistema. )ostoji pet tipova komponenti, koje se djelimi"no ili potpuno, nalaze u 1=(4 produktima* repozitorij'rje"nik podataka, reinenjering, podr#ka ivotnog ciklusa, podr#ka projekta i kontinuirano pobolj#avanje kvaliteta. $n sadri definicije ekranskih pregleda, izvje#taja, formi i informacionih procesa. Repozitorij, koji predstavlja ki"mu 1=(4 a, meusobno povezuje sve komponente zajedno. %ao takav, on sadri definicije ekranskih pregleda, izvje#taja, formi i informacionih procesa. Reinenjering je sinonim za odravanje sistema. %ombinira povratni i progresivni inenjering, u kome oba sadre programski kod sistema. )odr#ka ivotnog ciklusa uklju"uje grafi"ku podr#ku za strate#ko planiranje, analizu, logi"ki dizajn, fizikalni dizajn i izvedbu. 1=(4 alati se razlikuju po tome kako podravaju ivotni ciklus sistema. Cront end'upper 1=(4 alati podravaju strate#ko planiranje, analizu i logi"ki dizajn. 9ack end'lo!er 1=(4 alati su orjentirani ka procesu dizajna, jer podravaju faze ivotnog ciklusa koje se odnose na fizikalni dizajn i izvedbu. 1=(4 produkt koji uklju"uje i front end i back end performanse nazvan je full life 1=(4. $vom posljednjem, pro#irenom 1=(4 produktu daljim dodavanjem reienjeringa i projektne podr#ke dobiva se tzv. integracijski 1=(4 2 -1=(4. )ored 1=(4 produkata, na raspolaganju su mnogi generatori aplikacija. Deneratori su opredjeljeni za udovoljenje veoma izraenog zahtjeva brzog razvoja aplikacija. =plikacije su definirane kao sistemi s striktno uspostavljenim granicama i ciljevima. )otreba brzog razvoja aplikacija poticala je preusmjerenje ka prototipiranju, participaciji krajnjeg korisnika u proces dizajna, sistemima za podr#ku odlu"ivanja 2 6((, ekspertnim sistemima i informacionim sistemima management a 2 3-(. %ao i realnim, a ne papirnim demonstracijskim sistemima. Deneratori programskog koda predstavljaju jedan drugi alat za podr#ku automatiziranog razvoja sistema. Festo su zastupljeni kao integralni dio nekog 1=(4 produkta. Denerator prototipa je spomenut kao jo# jedan alat automatiziranog razvoja sistema. Denerator prototipa moe biti generiran iz generatora aplikacija, ali kao takav ne posjeduje nivo sofisticiranosti kao oni koji su generirani iz specijaliziranih generatora prototipa. <loga alata automatiziranog razvoja sistema, u svom budu&em razvoju, treba da obuhvati slijede&e oblasti* (manjenje zamornih i repetativnih zada&a Reduciranje zahtjeva za ljudskom memorijom )obolj#anje i pro#irenje komunikacije Reduciranje #uma =lati automatiziranog razvoja sistema &e nastaviti da se razvijaju i napreduju samo ako dostignu slijede&e preduvjete* $bjedinjavaju potencijale ljudske i ra"unarske obrade podataka -ntegriraju produkte unutar kompletnog ivotnog ciklusa <"ine pakete s alatima dostupne #to ve&em broju potencijalnih korisnika <"ine pomak ka davanju zna"aja implementaciji 1=(4 produkata Ne smatraju 1=(4 kao jednu dizajn panaceju

Nau"ile su se dvije stvari iz 1=(4 iskustva do danas. )rva, 1=(4 ne moe kapitalno popraviti lo# dizajn. 6ruga, 1=(4 om se dobiva na kvalitetu, a ne na produktivnosti. %lju" uspjeha upotrebe 1=(4 a se zasniva na realisti"nim o"ekivanjima.

10 sdlc-analiza detekcija sistemskih problema


9ez obzira koliko dobro je informacioni sistem dizajniran ne moe se izbje&i postojanje problema vezanih uz njegov rad. Fak i oni problemi "ija dogaanja su se ocjenjivala malo vjerovatnim u vrijeme dizajna informacionog sistema, nakon izvjesnog vremena rada izau na povr#inu. (vakodnevno ispravljanje i saniranje problema se prepoznaje pod terminom sistemskog odravanja. ( prvim po"etcima deterioracije informacionog sistema, kao rezultat takvog stanja, po"inju da se sve "e#&e javljaju problemi, koji postaju sve kompleksniji i s pogubnijim posljedicama. < povodu toga, sistem analiti"ari moraju da razmatraju razvoj jednog zamjenskog informacionog sistema. Tranzicija izmeu sistemskog odravanja i razvoja zahtjeva jedan struktuirani pristup kojim bi se detektirali problemi informacionih sistema. (am po"etak takvog pristupa se zasniva na klasifikaciji tipi"nih informacijskih problema i simptoma koje prate iste. < tu svrhu treba naro"ito biti pripravan u slijede&im podru"jima* relevantnosti, kompletnosti, korektnosti, sigurnosti, pravovremenosti, ekonomi"nosti, efikasnosti, pouzdanosti i upotrebljivosti. 9acklog ovi transakcija su najzastupljeniji i frustriraju&i problem. 3ogu biti posljedica pove&anog broja'obima transakcija, smanjenja propusnosti'produktivnosti, fluktuacije uposlenika, ispada sistema i varijantnosti transakcija u odnosu na njihovu brzinu pristizanja odnosno akvizicije. Neposredne posljedice backlog ova se manifestiraju u nepostojanju zapisa o finansijskom opticaju, pove&anom obimu gre#aka i pove&anju tro#kova. )ove&anjem ili na neki drugi na"in intenziviranjem unosa transakcija nije mogu&e preduprijediti backlog ove transakcija. $soblje koje opsluuje informacione sisteme odnosno $djel za informacione sisteme detektira probleme istog na nekoliko na"ina* pritubama korisnika, na bazi jurisdikcija top management a, istraivanjem potencijalnih problema odnosno problemskih podru"ja, revizijama i mjerenjima radnih performansi sistema 2 )3(. )3( predstavlja struktuiran pristup za rano i sveobuhvatno otkrivanje problema informacionih sistema. -zveden je u formi jedne kompozicije koja sadrava slijede&e elemente* radne zada&e, postoje&e radno stanje, radne tolerancije, analizu trenda i ogla#avanje problema. %akav god da je izvor problema informacionih sistema, isti mora biti registriran od strane onih koji skrbe o informacionim sistemima 2 to je, obi"no, $djel za informacione sisteme. )otom, sistem analiti"ar je obavezan nastaviti dalja istraivanja, analizirati problematiku i sa"initi preliminarni izvje#taj o problemu. $vakav izvje#taj sadrava detekciju izvora problema, opis problema terminima izvora u kojem je nastao, detaljiziranu analizu i preporuke kako nastaviti s tretmanom problema. Ne treba inicirati proces razvoja novog informacionog sistema sve dok se ne postignu jasni i nedvojbeni indikatori da je postoje&i sistem po"eo deteriorirati. Tako mora biti s obzirom na "injenicu da je razvoj novog sistema skup, zahtjeva puno vremena i naru#ava radno okruenje krajnjeg korisnika. 3eutim, ako su problemi informacionih sistema ozbiljni i ugroavaju rad istog, mora se istraivati mogu&a zamjena sistema. Na"in na koji se takva istraivanja provode, bi&e neposrednim predmetom u nastavku izlaganja.

11 sdlc-analiza inicijalnih istrazivanja


=naliti"ar je taj koji je odreen da provede inicijalno istraivanje problema informacionih sistema koji to zavrijeuju. )roblemi se kategoriziraju u glavne i zna"ajne odnosno minorne probleme, koji se vremenom ponavljaju. $snovna namjena inicijalnog istraivanja je da se utvrdi da li nastaviti s (6;1 procesom odnosno ivotnim ciklusom razvoja sistema. Takva odluka koja se odnosi na nastavak procesa razvoja donosi ozbiljne obaveze i zahtjeve na informati"ke i druge resurse. 8bog toga, faza inicijalnog istraivanja je od kapitalnog zna"aja za sve sudionike u implementaciji i'ili razvoju novog informacionog sistema. (truktura rje#avanja problema prethodno razmatrana u )oglavlju >* 7-nformacije i informacioni sistemi7 je simetri"na baza za koncept inicijalnog istraivanja informacionog sistema. 6akle, jednaka definiranost problema u oba slu"aja kao* 7problem je nepodudarnost +7gap7, izmeu idealnog i stvarnog, postoje&eg sistema7. Dap ovi, identificirani u ranoj fazi ivotnog ciklusa razvoja sistema 2 (6;1, tj. detekcije problema, nisu u potpunosti spremni da budu rje#avani. Takvo stanje se prepu#ta fazi inicijalnog istraivanja da bi se determinirala validnost navodnog problema. < inicijalnom istraivanju, sistem analiti"ari se suo"avaju s nekoliko ograni"enja kao #to su vrijeme, tro#kovi, znanje i iskustvo analiti"ara, poslovna politika i efekat naru#avanja radnog okruenja tokom istranog opserviranja. =naliti"ar mora biti nedvojbeno siguran i uvjeren da istrauje realno okruenje, ne ono izmjenjeno i neuobi"ajeno, #to bi moglo biti zbog njegovog prisustva. (istem analiti"ari, isto tako, mogu biti limitirani u preporukama za rje#avanje odreenih situacija u smislu* +1, ne preduzimati nikakvu akciju jer problem nije validan, +>, suportnim odravanjem sistema sanirati minorne probleme, +?, pobolj#ati i pro#iriti trenani ciklus korisnika, +@, ostaviti rje#avanje problema u budu&em zamjenskom sistemu, i +A, razmotriti najvanije modifikacije sistema, koje uzimaju u obzir i opciju kompletne zamjene istog. Tokom provoenja inicijalnog istraivanja potrebno je primjeniti odreene, prilagoene taktike kako slijedi* (lu#ati, ne drati predavanja Ne prejudicirati rje#enje problema %omparirati iskaze Traiti konfliktnosti u iskazima -spitati logi"ke nekonzistentnosti $pservirati vlastiti u"inak $"ekivati naporan, monoton rad (prije"iti predrasude

%ombiniranjem ovih taktika s skupom istraiva"kih tehnika moe se izvr#iti na na"in klasificiranja u tri kategorije* 1. -nterna ispitivanja >. 4ksterna ispitivanja ?. (inteza -nterna ili direktna ispitivanja obuhva&aju upitnike, intervjue i direktne opservacije. 4ksterna ili indirektna ispitivanja omogu&avaju istraivanja bez naru#avanja rada sistema. 4ksterna ispitivanja uklju"uju tok procedura, dokumentacijsku reviziju, uzorkovanje i tabelarne analize. Tehnike sintetiziranja, koje uvezuju i'ili kompariraju rezultate internih i eksternih ispitivanja uklju"uje dijagrame toka podataka i rje"nike podataka, ispitivaju&i diskrepencije izmeu rezultnih vrijednosti internih i eksternih ispitivanja. Nedostaci tehnika istraivanja se baziraju na nekoliko ograni"enja kao #to su* vrijeme potrebno za njihovo provoenje, tro#kovi istih, promjene sistema tokom samog istraivanja, naru#avanje i prekidi

rada sistema tokom obavljanja mjerenja i formati koji ne omogu&avaju laku komunikaciju s krajnjim korisnikom. =naliti"aru treba jedan metod koji &e ga fokusirati na vjerovatne izvore sistemskih problema i predvidjeti maksimalni nivo vjerovatno&e za brzo izoliranje stvarnog problema. Takav metod se bazira na matrici "ije dvije dimenzije su* aplikacijska kompleksnost i korisni"ki uticaj. =plikacije koje imaju visoku vrijednost po obje dimenzije, imaju prioritet i prve se istrauju, za razliku od aplikacija koje nemaju takve vrijednosti i koje se ostavljaju za kasnija istraivanja. Rje#avanje problema informacionog sistema nezaobilazno zahtjeva dokumentiranje statusa postoje&eg sistema. Takvo dokumentiranje je poznato pod terminom 7opis postoje&eg sistema7. Tokom istraivanja informacijskih problema analiti"ari, nehoti"no, auriraju opis postoje&eg sistema. $tud, ukoliko je problem klasificiran kao ozbiljan, stvaraju se potrebni i dovoljni uvjeti za zapo"injanje slijede&e faze ivotnog ciklusa razvoja sistema 2 (6;1 a. $pis postoje&eg sistema sadrava ulazne i izlazne specifikacije, datoteke, podatkovne elemente, transakcijski obim i veli"inu akcijskog dokumenta, tro#kove i dijagrame toka podataka. Tada je neophodno razlikovati dvije odvojene situacije* ukoliko se problem moe obraditi unutar postoje&eg sistema, aurira se opis postoje&eg sistema i prekida s da ljim radom u okviru ivotnog ciklusa razvoja sistemaG ukoliko to nije slu"aj, nastavlja se s ivotnim ciklusom razvoja sistema 2 (6;1 i prelazi na njegovu slijede&u fazu. $pis postoje&eg sistema se moe uraditi primjenom i kori#tenjem alata struktuiranog razvoja, kao #to su dijagrami toka podataka i rje"nici podataka'data dictionar:.

12 sdlc-analiza zahtjeva
Caza analize zahtjeva u kontekstu ivotnog ciklusa razvoja sistema, (6;1 a, predstavlja najvi#e #to se moe pruiti u osiguranju uvjeta meusobne interakcije i komunikacije izmeu sistemskog osoblja i krajnjih korisnika. $snovna namjena ove faze je da se dokumentira postoje&i sistem, prikupe i spoznaju korisni"ki zahtjevi i vizija 7idealnog7 sistema kakvog trebaju korisnici i poku#a realizirati najve&i doseg takvom sistemu s obzirom na resursna ograni"enja. < opisivanjo postoje&eg sistema, analiti"ari poku#avaju da ustanove dvije stvari. )rva se odnosi na utvrivanje, eventualnih, razlika izmeu na"ina na koji je dizajniran sistem za upotrebu i na"ina kako se on stvarno koristi. Nije rijedak slu"aj da se sistemi koriste na znatno izmjenjen na"in, nego #to je to bilo planirano i predvieno. 6ruga stvar se odnosi na utvrivanje kako postoje&i sistem radi. Naime, analiti"ari poku#avaju, na temelju odreene metrike, da utvrde one karakteristi"ne vrijednosti koje performanse sistema kvantificiraju kao visoke, niske ili prosje"ne vrijednosti istih. Heoma "esto krajnji korisnici budu iznenaeni statisti"kim pokazateljima stvarnog rada postoje&eg sistema. 0edna kontrolna lista s takvim pokazateljima pomae analiti"arima da dokumentiraju postoje&i sistem. %orisni"ka o"ekivanja, koja pretpostavljaju 7idealan7 sistem prema istim, ne mogu se uvijek uzeti u svom punom traenju i vrijednosti zbog nekoliko problema koji se mogu isprije"iti i to kako slijedi* korisni"ka o"ekivanja'zahtjevi se mjenjaju vremenomG korisnici, sasvim "esto, zaboravljaju #ta su zahtjevali na samom po"etku dizajniranja postoje&eg sistemaG mnogi od korisnika nisu, u potpunosti, ni svjesni #ta je to #to oni o"ekuju od sistemaG i na kraju, te#ko je izna&i konsenzus u zahtjevima i o"ekivanjima korisnika i, iz takvih razloga, ista se moraju kombinirati u modus koji najbolje odraava spektar njihovih elja. < dokumentiranju korisni"kih zahtjeva, analiti"ari se moraju boriti od nametanja svojih predrasuda, sugeriraju&i ih korisniku kao njihova vlastita. Rezultati dobiveni procjenjivanjem korisni"kih o"ekivanja definiraju odreene zada&e za sistem, tipove eljenih izvje#taja, potrebe u treningu korisnika, na"in upotrebe metoda dokumentiranja i izvje#tavanja, kao i osjetljivost na tehnologiju i organizaciju rada. =naliti"ari primjenjuju pet op#te prihva&enih metoda analize zahtjeva kako slijedi* intervjue, upitnike, opservacije, analize procedura i dokumentacijske preglede odnosno istraivanja. (vaka od ovih metoda ima svoje ciljeve, prednosti i nedostatke. -ntervjui, upitnici i opserviranja su posebno vane metode, jer se i naj"e#&e koriste. )reliminarni rje"nik podatkovnih elemenata predstavlja klju" za uspje#an dizajn i s njegovim kreiranjem se zapo"inje u ovoj fazi (6;1 a. =naliza zahtjeva vodi do jednog konsenzusa krajnjih korisnika u pogledu kako bi, prema njima, 7idealni7 sistem bio predstavljen i izveden. 3eutim, takav konsenzus mora biti podvrgnut realnim sistemskim ograni"enjima koja se odnose na vrijeme, buet, znanje, tehnologiju i eksterne faktore. Rezultni proizvod ove faze (6;1 a je dokument analize zahtjeva. To je relevantni dokument koji opravdava provedenu analizu i priprema na"in na koji &e se sistem dizajnirati. 6okument analize zahtjeva uklju"uje opis na"ina kojim je analiza provedena, korisni"ke zahtjeve, sistemska ograni"enja i prate&u dokumentaciju. Nakon ovog, do#lo se u mnogo povoljniju situaciju u naporima kako suziti 7gap7 izmeu korisni"kih o"ekivanja i postoje&eg sistema u jedan prihvatljiv i kontrolabilan oblik. 8ato &e se u nastavku pokazati kako determinirati koja alternativa informacionog sistema &e najbolje ispuniti taj 7prazan prostor7 7gap7 izmeu 7idealnog7 i postoje&eg sistema.

13 generiranje alternativa sistemskog rjesenja


(istem dizajner kreira sistemske alternative s isklju"ivim ciljem da eliminira ili minimizira 7gap7 izmeu postoje&eg rada sistema i onog kakav se elio i o"ekivao. 3atrica izvedivosti i dijagram tro#kova su od centralnog zna"aja u evaluiranju sistemskih alternativa. 3eutim, prije toga moraju se kreirati razli"ite alternative informacionih sistema. 9roj potencijalno dizajniranih, a razli"itih poslovni informacionih sistema moe se "initi beskona"nim. 3eutim, postoji jedna struktuirana tehnika koja je sposobna za kreiranje, a zatim reduciranje broja sistemskih alternativa. (istemske odluke se donose na tri razli"ita nivoa* strate#kom, takti"kom i operativnom nivou. =lternative s strate#kog i takti"kog nivoa limitiraju izbore odnosno alternative na operativnom nivou koje su, jedino, pod jurisdikcijom sistem dizajnera. Najkarakteristi"nije strate#ke alternative se zasnivaju na izboru distribuirane ili centralizirane obrade podataka, integrirane ili disperzirane baze podataka i strategije objedinjavanja odnosno migracije postoje&ih sistema umjesto njihove zamjene. $biljeja takti"kih alternativa se baziraju na izboru izmeu zamjene sistema odmah ili kasnije odnosno modifikacije istog i specifi"nosti (6;1 konfiguracije koje obuhva&aju prototipiranje, implementacijski metod i formalni project management. $vakve odluke koje se donose na strate#kom i takti"kom nivou limitiraju potencijalne izbore koje mogu odabrati sistem dizajneri na operativnom nivou, tj. one koji diktiraju tehni"ko funkcioniranje i operativnost informacionog sistema. =lternative s aspekta operativnog nivoa se baziraju na osam+I, tipiziranih formi koje se odnose na ulaz i izlaz sistema odnosno obradu podataka kako slijedi* 1. >. ?. @. A. J. K. I. $n line ili off line unos podataka <lazni mnomoni"ki kod ili ma#inski "itljiva forma unosa podataka 1entralizirani ili decentralizirani unos podataka 9atch ili obrada u realnom vremenu (ekvencijalni ili direktni pristup bazi podataka 0ednokorisni"ka ili vi#ekorisni"ka konfiguracija pristupa sistemu Tradicionalni ili 7turnaround7 dokumenti (truktuirani ili izvje#taji na zahtjev

%ombiniranjem ovih osam+I, tipiziranih formi kreira maksimalno >AJ potencijalnih sistemskih konfiguracija, ali ovaj broj moe biti reduciran po logi"koj osnovi na osam+I, tipiziranih alternativa poslovnih informacionih sistema. Cinalni dizajn moe i dalje biti suavan posredstvom prirodne progresije'razvoja sistema i "injenicom da se dizajneri ne moraju vra&ati unazad da bi se ponovo pozicionirali na prvobitne konfiguracije, ako se od njih odstupilo tokom procesa kori#tenja sistema. Na ovom mjestu u okviru ivotnog ciklusa razvoja sistema 2 (6;1 a, sistem dizajnerima su preostale samo nekoliko konkurentnih alternativa, kao i onih koji zadovoljavaju zahtjevano sistemsko rje#enje izmeu kojih se, na kraju, i vr#i kona"ni odabir. %ona"ni odabir cjelishodne i zadovoljavaju&e alternative informacionog sistema se bazira na primjeni tehnika strukturne evaluacije, o kojim &e vi#e detalja biti prezentirano u slijede&em poglavlju.

14 sdlc-analiza i izbor najpovoljnijeg rjesenja


<poredba alternativa informacionih sistema dovodi do jednog prakti"nog pravila* 7)rvo uporedi tro#kove'cijenu sistema7. 8atim, ukoliko su dva ili vi#e sistema bliski po tro#kovima'cijeni, primjeni kvalitativne, netro#kovne faktore u selekciji najpovoljnijeg sistema.

Nov"ane vrijednosti ili jedinica, +L'<(6,, je vana mjerna jedinica iz, najmanje, tri razloga* 1. (asvim uobi"ajen na"in pra&enja i planiranja poslovanja kompanije predstavljen je kroz sume nov"anih jedinica. %njigovodstvo omogu&ava hronolo#ko pra&enje svih tro#kova i kao takvo &e posluiti kao bazis za budu&e estimacije i prognoze. >. -nformacioni sistemi se uporeuju s svim ostalim segmentima kompanije. Nov"ana jedinica je najbolje sredstvo da se izrazi meusobni omjer i komparativnost. ?. Top management odlu"uje da li ili ne nastaviti s razvojem novog informacionog sistema. <tvrena nov"ana vrijednost izvedbe istog je najbolje pomagalo i indikator kakvu odluku donijeti. =lati koji se koriste za kompariranje informacionih sistema su matrica izvedivosti i dijagram tro#kova. Tro#kovi informacionih sistema su zastupljeni kroz tro#kove hard!are a, soft!are a, ljudi, potro#nog materijala, telekomunikacija i fizi"kih objekata u kojim je smje#ten sistem. Tro#kovi se dijele na jednokratne i rekurentne'operativne tro#kove. 0ednokratni tro#kovi su tro#kovi koji su samo jednom nastali i to tokom izvedbe i'ili razvoja sistema. )odrazumjevaju nabavku hard!are a, programiranja, pripreme fizi"kih lokacija za instalaciju sistema i samu instalaciju. Rekurentni odnosno operativni tro#kovi su tro#kovi svakodnevnog rada informacionog sistema. $buhvataju tro#kove potro#nog materijala i kori#tenja hard!are ske, soft!are ske i telekomunikacijske opreme, +najam,. Tro#kovima novog informacionog sistema trebaju biti pridrueni samo oni tro#kovi koji su upravo i nastali njegovim razvojem, a nikako da se takvim tro#kovima pridruuju tro#kovi reije i sl. $vakva postavka je poznata pod imenom koncepta marginalnih tro#kova. Fetiri metode imaju naj#iru primjenu u kompariranju sistema* analiza balansa izmeu dobitaka i gubitaka, period povrata investicija, period diskontovanog povrata investicija i interna stopa povrata investicija. < slu"ajevima kad, nakon tro#kovne komparacije, su dvije ili vi#e alternativa informacionih sistema skoro jednake, primjenjuju se kvalitativni faktori u daljnoj proceduri izbora. %valitativni faktori predstavljaju benificije ili u#tede koje se ne jedinice, +L'<(6,. %valitativni faktori u svom tretmanu involviraju kojim su obuhva&ene redukcije u gre#kama, pove&anje brzine i 6rugi tip kvalitativnih faktora su strate#ki po svom karakteru, pokazatelje kompanije. 8asnivaju se na zadovoljnosti korisnika, angairanosti korisnika i marketingu informacijskih produkata. mogu lako konvertirati u nov"ane performanse informacionih sistema ta"nosti, pobolj#anoj sigurnosti itd. jer neposredno uti"u na poslovne komercijalnim efektima poslovanja,

(istemska studija je izraena kao jedna kulminacijska forma faze =nalize. 8apravo, to je jedan detaljizirani opis radova i odluka donesenih tokom cjelokupnog procesa analize. %ao zavr#na forma analiti"ke faze prezentira se sistemska studija u zavr#noj proceduri prihvatanja i odobravanja nastavka ivotnog ciklusa razvoja sistema. %ona"no, top management donosi D$'N$ D$ odluku, koja moe biti dono#ene u nekoj od slijede&ih opcija kako slijedi* -. Nastaviti s razvojem novog sistema --. $dustati od novog sistema kao jednoj trenutno neopstojnoj investicijskoj alternativi ---. )onoviti jedan ili vi#e dijelova sistemske studije i naknadno podnijeti za novo razmatranje

You might also like